April 2020 - ceph-users - lists.ceph.io

Bluestore compression parameters in ceph.conf not used in mimic 13.2.8?
by Frank Schilder 01 Apr '20

01 Apr '20

Dear all, I have two observations regarding bluestore compression config: 1) ceph.conf settings seem to be ignored. 2) The SSD default values seem not to save space using compression. To 1) We are running a mimic 13.2.8 cluster with OSDs deployed under mimic 13.2.2. Back then the interpretation of compression parameters was messed up, which has been fixed along the way from 13.2.2 to 13.2.8. To get it to work properly under 13.2.2 I needed to include these settings in ceph.conf: [osd] bluestore compression mode = aggressive bluestore compression min blob size hdd = 262144 and then also enable compression on all pools that should use compression. These settings are still present in ceph.conf, but they seem to be ignored when populating the config data base on mon startup or querying config parameters: # ceph config get osd.16 bluestore_compression_min_blob_size_hdd 131072 However: # ceph tell osd.16 config get bluestore_compression_min_blob_size_hdd 262144 and: # ceph config show osd.16 NAME VALUE SOURCE OVERRIDES IGNORES bluestore_compression_min_blob_size_hdd 262144 file This is really confusing. Is this intended? Which values will be used when deploying new OSDs? In general, it would really be helpful if one could query daemon/parameter groups as in " ceph config get osd bluestore_compression_min_blob_size_hdd" to get a list right away. To 2) In a long-long-ago discussion about how compression works, I was told that a blob of bluestore_compression_min_blob_size will be compressed and then distributed over a number of allocations of bluestore_min_alloc_size. The defaults for HDD and SSD are: bluestore_compression_min_blob_size_hdd 131072 bluestore_min_alloc_size_hdd 65536 bluestore_compression_min_blob_size_ssd 8192 bluestore_min_alloc_size_ssd 16384 If this explanation of the compression method is correct, these defaults allow up to 50% savings for HDD, but, erm, 0% for SSD as the uncompressed blob will use the same amount of space as the compressed one as both will require the same allocation size. Did something change here? Are compressed blobs now co-located in allocations? Thanks for your help, ================= Frank Schilder AIT Risø Campus Bygning 109, rum S14

2 2

osd can not start at boot after upgrade to octopus
by Lomayani S. Laizer 01 Apr '20

01 Apr '20

Hello, I have upgraded nautilus cluster to octopus few days ago. the cluster was running ok and even after to octopus everything was running ok the issue came when i rebooted the servers for updating the kernel. Two servers out of 6 osd's servers osd cant start. No error reported in ceph-volume.log and ceph-volume-systemd.log Starting osd with /usr/bin/ceph-osd -f --cluster ceph --id 30 --setuser ceph --setgroup ceph works just fine. the issue is starting osd in systemd ceph-volume-systemd.log 16:36:28,193][systemd][WARNING] failed activating OSD, retries left: 30 [2020-03-31 16:36:28,196][systemd][WARNING] command returned non-zero exit status: 1 [2020-03-31 16:36:28,196][systemd][WARNING] failed activating OSD, retries left: 30 [2020-03-31 16:41:25,054][systemd][INFO ] raw systemd input received: lvm-28-7f4113c8-c5cf-4f70-9f7a-7a32de9d6587 [2020-03-31 16:41:25,054][systemd][INFO ] raw systemd input received: lvm-30-8a70ad95-1c79-4502-a9a3-d5d7b9df84b6 [2020-03-31 16:41:25,054][systemd][INFO ] raw systemd input received: lvm-31-a8efb7db-686b-4789-a9c4-01442c28577f [2020-03-31 16:41:25,096][systemd][INFO ] parsed sub-command: lvm, extra data: 28-7f4113c8-c5cf-4f70-9f7a-7a32de9d6587 [2020-03-31 16:41:25,096][systemd][INFO ] parsed sub-command: lvm, extra data: 30-8a70ad95-1c79-4502-a9a3-d5d7b9df84b6 [2020-03-31 16:41:25,054][systemd][INFO ] raw systemd input received: lvm-33-7d688fc1-ed7b-45ae-ac0e-7b1787e0b64f [2020-03-31 16:41:25,096][systemd][INFO ] parsed sub-command: lvm, extra data: 31-a8efb7db-686b-4789-a9c4-01442c28577f [2020-03-31 16:41:25,068][systemd][INFO ] raw systemd input received: lvm-29-3e52d340-5416-46e6-b697-c15ca85f6883 [2020-03-31 16:41:25,096][systemd][INFO ] parsed sub-command: lvm, extra data: 33-7d688fc1-ed7b-45ae-ac0e-7b1787e0b64f [2020-03-31 16:41:25,068][systemd][INFO ] raw systemd input received: lvm-32-3841a62d-d6bc-404a-8762-163530b2d5d4 [2020-03-31 16:41:25,096][systemd][INFO ] parsed sub-command: lvm, extra data: 29-3e52d340-5416-46e6-b697-c15ca85f6883 [2020-03-31 16:41:25,096][systemd][INFO ] parsed sub-command: lvm, extra data: 32-3841a62d-d6bc-404a-8762-163530b2d5d4 [2020-03-31 16:41:25,108][ceph_volume.process][INFO ] Running command: /usr/sbin/ceph-volume lvm trigger 29-3e52d340-5416-46e6-b697-c15ca85f6883 ceph-volume.log 2-163530b2d5d4 [2020-03-31 17:17:23,679][ceph_volume.process][INFO ] Running command: /bin/systemctl enable --runtime ceph-osd@31 [2020-03-31 17:17:23,863][ceph_volume.process][INFO ] Running command: /bin/systemctl enable --runtime ceph-osd@30 [2020-03-31 17:17:24,045][ceph_volume.process][INFO ] Running command: /bin/systemctl enable --runtime ceph-osd@33 [2020-03-31 17:17:24,241][ceph_volume.process][INFO ] Running command: /bin/systemctl enable --runtime ceph-osd@32 [2020-03-31 17:17:24,449][ceph_volume.process][INFO ] Running command: /bin/systemctl enable --runtime ceph-osd@28 [2020-03-31 17:17:24,629][ceph_volume.process][INFO ] Running command: /bin/systemctl enable --runtime ceph-osd@29 [2020-03-31 17:17:24,652][ceph_volume.process][INFO ] stderr Created symlink /run/systemd/system/ceph-osd.target.wants/ceph-osd(a)31.service → /lib/systemd/system/ceph-osd@.service. [2020-03-31 17:17:24,664][ceph_volume.process][INFO ] stderr Created symlink /run/systemd/system/ceph-osd.target.wants/ceph-osd(a)30.service → /lib/systemd/system/ceph-osd@.service. [2020-03-31 17:17:24,872][ceph_volume.process][INFO ] Running command: /bin/systemctl start ceph-osd@31 [2020-03-31 17:17:24,875][ceph_volume.process][INFO ] stderr Created symlink /run/systemd/system/ceph-osd.target.wants/ceph-osd(a)33.service → /lib/systemd/system/ceph-osd@.service. [2020-03-31 17:17:25,072][ceph_volume.process][INFO ] stderr Created symlink /run/systemd/system/ceph-osd.target.wants/ceph-osd(a)32.service → /lib/systemd/system/ceph-osd@.service. [2020-03-31 17:17:25,075][ceph_volume.process][INFO ] Running command: /bin/systemctl start ceph-osd@30 [2020-03-31 17:17:25,282][ceph_volume.process][INFO ] Running command: /bin/systemctl start ceph-osd@33 [2020-03-31 17:17:25,497][ceph_volume.process][INFO ] stderr Created symlink /run/systemd/system/ceph-osd.target.wants/ceph-osd(a)28.service → /lib/systemd/system/ceph-osd@.service. [2020-03-31 17:17:25,499][ceph_volume.process][INFO ] Running command: /bin/systemctl start ceph-osd@32 [2020-03-31 17:17:25,520][ceph_volume.process][INFO ] stderr Created symlink /run/systemd/system/ceph-osd.target.wants/ceph-osd(a)29.service → /lib/systemd/system/ceph-osd@.service. [2020-03-31 17:17:25,705][ceph_volume.process][INFO ] Running command: /bin/systemctl start ceph-osd@28 [2020-03-31 17:17:25,887][ceph_volume.process][INFO ] Running command: /bin/systemctl start ceph-osd@29 -- Lomayani

2 2

No reply or very slow reply from Prometheus plugin - ceph-mgr 13.2.8 mimic
by Paul Choi 01 Apr '20

01 Apr '20

Hello, We are running Mimic 13.2.8 with our cluster, and since upgrading to 13.2.8 the Prometheus plugin seems to hang a lot. It used to respond under 10s but now it often hangs. Restarting the mgr processes helps temporarily but within minutes it gets stuck again. The active mgr doesn't exit when doing `systemctl stop ceph-mgr.target" and needs to be kill -9'ed. Is there anything I can do to address this issue, or at least get better visibility into the issue? We only have a few plugins enabled: $ ceph mgr module ls { "enabled_modules": [ "balancer", "prometheus", "zabbix" ], 3 mgr processes, but it's a pretty large cluster (near 4000 OSDs) and it's a busy one with lots of rebalancing. (I don't know if a busy cluster would seriously affect the mgr's performance, but just throwing it out there) services: mon: 5 daemons, quorum woodenbox0,woodenbox2,woodenbox4,woodenbox3,woodenbox1 mgr: woodenbox2(active), standbys: woodenbox0, woodenbox1 mds: cephfs-1/1/1 up {0=woodenbox6=up:active}, 1 up:standby-replay osd: 3964 osds: 3928 up, 3928 in; 831 remapped pgs rgw: 4 daemons active Thanks in advance for your help, -Paul Choi

4 13

Multiple CephFS creation
by Jarett DeAngelis 01 Apr '20

01 Apr '20

Hi guys, This is documented as an experimental feature, but it doesn’t explain how to ensure that affinity for a given MDS sticks to the second filesystem you create. Has anyone had success implementing a second CephFS? In my case it will be based on a completely different pool from my first one. Thanks. J

4 8