- ceph-users - lists.ceph.io

Worst thing that can happen if I have size= 2
by Mario Giammarco 06 Feb '21

06 Feb '21

Hello, Imagine this situation: - 3 servers with ceph - a pool with size 2 min 1 I know perfectly the size 3 and min 2 is better. I would like to know what is the worst thing that can happen: - a disk breaks and another disk breaks before ceph has reconstructed second replica, ok I lose data - if network goes down and so monitors lose quorum do ceph still write on disks? What else? Thanks, Mario

16 28

mon db high iops
by Seena Fallah 05 Feb '21

05 Feb '21

Hi all, My monitor nodes are getting up and down because of paxos lease timeout and there is a high iops (2k iops) and 500MB/s throughput on /var/lib/ceph/mon/ceph.../store.db/. My cluster is in a recovery state and there is a bunch of degraded pgs on my cluster. It seems it's doing a 200k block size io on rocksdb. Is that okay?! Also is there any solution to fix these downtimes for monitors? Thanks for your help!

2 4

NVMe and 2x Replica
by Adam Boyhan 05 Feb '21

05 Feb '21

I know there is already a few threads about 2x replication but I wanted to start one dedicated to discussion on NVMe. There are some older threads, but nothing recent that addresses how the vendors are now pushing the idea of 2x. We are in the process of considering Ceph to replace our Nimble setup. We will have two completely separate clusters at two different sites that we are using rbd-mirror snapshot replication. The plan would be to run 2x replication on each cluster. 3x is still an option, but for obvious reasons 2x is enticing. Both clusters will be spot on to the super micro example in the white paper below. It seems all the big vendors feel 2x is safe with NVMe but I get the feeling this community feels otherwise. Trying to wrap my head around were the disconnect is between the big players and the community. I could be missing something, but even our Supermicro contact that we worked the config out with was in agreement with 2x on NVMe. Appreciate the input! [ https://www.supermicro.com/white_paper/white_paper_Ceph-Ultra.pdf | https://www.supermicro.com/white_paper/white_paper_Ceph-Ultra.pdf ] [ https://www.redhat.com/cms/managed-files/st-micron-ceph-performance-referen… ] [ https://www.redhat.com/cms/managed-files/st-micron-ceph-performance-referen… | https://www.redhat.com/cms/managed-files/st-micron-ceph-performance-referen… ] [ https://www.samsung.com/semiconductor/global.semi/file/resource/2020/05/red… | https://www.samsung.com/semiconductor/global.semi/file/resource/2020/05/red… ]

12 22

ceph-volume deactivate errs out with "findmnt: invalid option -- M"
by Frank Schilder 05 Feb '21

05 Feb '21

Hi all, I'm experimenting with ceph-volume on Centos7, ceph mimic 13.2.10. When I execute "ceph-volume deactivate ..." on a previousy activated OSD, I get this error: # ceph-volume lvm deactivate 12 0bbf481c-6a3d-4724-9a27-3a845eb05911 stderr: /usr/bin/findmnt: invalid option -- 'M' stderr: Usage: Help summary of findmnt at the bottom. I could hack a script together that forwards this call to findmnt and translates the option. Can anyone tell me if this is a bug or if I'm running with the wrong version? In the mean time, is ceph-volume deactivate just unmounting /var/lib/ceph/osd/ceph-ID directories, or is there more to it (no dmcrypt in use)? Thanks! # findmnt --help Usage: findmnt [options] findmnt [options] <device> | <mountpoint> findmnt [options] <device> <mountpoint> findmnt [options] [--source <device>] [--target <mountpoint>] Options: -s, --fstab search in static table of filesystems -m, --mtab search in table of mounted filesystems -k, --kernel search in kernel table of mounted filesystems (default) -p, --poll[=<list>] monitor changes in table of mounted filesystems -w, --timeout <num> upper limit in milliseconds that --poll will block -A, --all disable all built-in filters, print all filesystems -a, --ascii use ASCII chars for tree formatting -c, --canonicalize canonicalize printed paths -D, --df imitate the output of df(1) -d, --direction <word> direction of search, 'forward' or 'backward' -e, --evaluate convert tags (LABEL,UUID,PARTUUID,PARTLABEL) to device names -F, --tab-file <path> alternative file for --fstab, --mtab or --kernel options -f, --first-only print the first found filesystem only -i, --invert invert the sense of matching -l, --list use list format output -N, --task <tid> use alternative namespace (/proc/<tid>/mountinfo file) -n, --noheadings don't print column headings -u, --notruncate don't truncate text in columns -O, --options <list> limit the set of filesystems by mount options -o, --output <list> the output columns to be shown -P, --pairs use key="value" output format -r, --raw use raw output format -t, --types <list> limit the set of filesystems by FS types -v, --nofsroot don't print [/dir] for bind or btrfs mounts -R, --submounts print all submounts for the matching filesystems -S, --source <string> the device to mount (by name, maj:min, LABEL=, UUID=, PARTUUID=, PARTLABEL=) -T, --target <string> the mountpoint to use -h, --help display this help and exit -V, --version output version information and exit Available columns: SOURCE source device TARGET mountpoint FSTYPE filesystem type OPTIONS all mount options VFS-OPTIONS VFS specific mount options FS-OPTIONS FS specific mount options LABEL filesystem label UUID filesystem UUID PARTLABEL partition label PARTUUID partition UUID MAJ:MIN major:minor device number ACTION action detected by --poll OLD-TARGET old mountpoint saved by --poll OLD-OPTIONS old mount options saved by --poll SIZE filesystem size AVAIL filesystem size available USED filesystem size used USE% filesystem use percentage FSROOT filesystem root TID task ID ID mount ID OPT-FIELDS optional mount fields PROPAGATION VFS propagation flags FREQ dump(8) frequency in days [fstab only] PASSNO pass number on parallel fsck(8) [fstab only] For more details see findmnt(8). ================= Frank Schilder AIT Risø Campus Bygning 109, rum S14

1 1

can't query most pgs after restart
by Jeremy Austin 05 Feb '21

05 Feb '21

I was in the middle of a rebalance on a small test cluster with about 1% of pgs degraded, and shut the cluster entirely down for maintenance. On startup, many pgs are entirely unknown, and most stale. In fact most pgs can't be queried! No mon failures. Would osd logs tell me why pgs aren't even moving to an inactive state? I'm not concerned about data loss due to the shutdown (all activity to the cluster had been stopped), so should I be setting some or all OSDs " osd_find_best_info_ignore_history_les = true"? Thank you, -- Jeremy Austin jhaustin(a)gmail.com

2 2

Re: Worst thing that can happen if I have size= 2
by Dan van der Ster 05 Feb '21

05 Feb '21

On Thu, Feb 4, 2021 at 10:30 PM huxiaoyu(a)horebdata.cn <huxiaoyu(a)horebdata.cn> wrote: > > >IMO with a cluster this size, you should not ever mark out any OSDs -- > >rather, you should leave the PGs degraded, replace the disk (keep the > >same OSD ID), then recover those objects to the new disk. > >Or, keep it <40% used (which sounds like a waste). > > Dear Dan, > > I particularly like your idea of " leave the PGs degraded, and replace the disk with the same OSD ID ". This is a wonderful thing i really want to do. > > Could you please share some more details on how to achieve this, or some scripts already being tested? Hi Samuel, To do this you'd first set a config so that down osds aren't automatically marked out, either by setting `mon_osd_down_out_interval` to a really large value, or perhaps mon_osd_down_out_subtree_limit = osd would work too. Then when the osd fails, PGs will become degraded. You just zap, then replace, then recreate the OSD. Here are the ceph-volume commands for that: * ceph-volume lvm zap --osd-id 1234 --destroy * (then you might need `ceph osd destroy 1234`) * (then replace the drive) * ceph-volume lvm create <according to your hw> --osd-id 1234 Cheers, Dan > > thanks a lot, > > Samuel > > > > ________________________________ > huxiaoyu(a)horebdata.cn > > > From: Dan van der Ster > Date: 2021-02-04 11:57 > To: Mario Giammarco > CC: Ceph Users > Subject: [ceph-users] Re: Worst thing that can happen if I have size= 2 > On Thu, Feb 4, 2021 at 11:30 AM Mario Giammarco <mgiammarco(a)gmail.com> wrote: > > > > > > > > Il giorno mer 3 feb 2021 alle ore 21:22 Dan van der Ster <dan(a)vanderster.com> ha scritto: > >> > >> > >> Lastly, if you can't afford 3x replicas, then use 2+2 erasure coding if possible. > >> > > > > I will investigate I heard that erasure coding is slow. > > > > Anyway I will write here the reason of this thread: > > In my customers I have usually proxmox+ceph with: > > > > - three servers > > - three monitors > > - 6 osd (two per server) > > - size=3 and min_size=2 > > > > I followed the recommendations to stay safe. > > But one day one disk of one server has broken, osd where at 55%. > > What happened then? > > Ceph started filling the remaining OSD to maintain size=3 > > OSD reached 90% ceph stopped all. > > Customer VMs froze and customer lost time and some data that was not written on disk. > > > > So I got angry.... size=3 and customer still loses time and data? > > You should size the osd fullness config in such a way that failure you > expect would still leave sufficient capacity. > In our case, we plan so that we could lose and re-replicate an entire > rack and still have enough space left. -- (IOW, with 5-6 racks, we > start to add capacity when the clusters reach ~70-75% full) > > In your case, the issue is more extreme: > Because you have 3 hosts, 2 osds each, and 3 replicas: when one OSD > fails and is marked out, you are telling ceph that *all* of the > objects will need to be written to the last remaining disk on that > host with the failure. > So unless your cluster was under 40-50% used, that osd is going to > become overfull. (But BTW, ceph will get backfillfull on the loaded > OSD before stopping IO -- this should not have blocked your user > unless they *also* filled the disk with new data at the same time). > > IMO with a cluster this size, you should not ever mark out any OSDs -- > rather, you should leave the PGs degraded, replace the disk (keep the > same OSD ID), then recover those objects to the new disk. > Or, keep it <40% used (which sounds like a waste). > > -- dan > > > > > > > > > > > > > > > > >> > >> Cheers, Dan > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On Wed, Feb 3, 2021, 8:49 PM Mario Giammarco <mgiammarco(a)gmail.com> wrote: > >>> > >>> Thanks Simon and thanks to other people that have replied. > >>> Sorry but I try to explain myself better. > >>> It is evident to me that if I have two copies of data, one brokes and while > >>> ceph creates again a new copy of the data also the disk with the second > >>> copy brokes you lose the data. > >>> It is obvious and a bit paranoid because many servers on many customers run > >>> on raid1 and so you are saying: yeah you have two copies of the data but > >>> you can broke both. Consider that in ceph recovery is automatic, with raid1 > >>> some one must manually go to the customer and change disks. So ceph is > >>> already an improvement in this case even with size=2. With size 3 and min 2 > >>> it is a bigger improvement I know. > >>> > >>> What I ask is this: what happens with min_size=1 and split brain, network > >>> down or similar things: do ceph block writes because it has no quorum on > >>> monitors? Are there some failure scenarios that I have not considered? > >>> Thanks again! > >>> Mario > >>> > >>> > >>> > >>> Il giorno mer 3 feb 2021 alle ore 17:42 Simon Ironside < > >>> sironside(a)caffetine.org> ha scritto: > >>> > >>> > On 03/02/2021 09:24, Mario Giammarco wrote: > >>> > > Hello, > >>> > > Imagine this situation: > >>> > > - 3 servers with ceph > >>> > > - a pool with size 2 min 1 > >>> > > > >>> > > I know perfectly the size 3 and min 2 is better. > >>> > > I would like to know what is the worst thing that can happen: > >>> > > >>> > Hi Mario, > >>> > > >>> > This thread is worth a read, it's an oldie but a goodie: > >>> > > >>> > > >>> > http://lists.ceph.com/pipermail/ceph-users-ceph.com/2016-December/014846.ht… > >>> > > >>> > Especially this post, which helped me understand the importance of > >>> > min_size=2 > >>> > > >>> > > >>> > http://lists.ceph.com/pipermail/ceph-users-ceph.com/2016-December/014892.ht… > >>> > > >>> > Cheers, > >>> > Simon > >>> > _______________________________________________ > >>> > ceph-users mailing list -- ceph-users(a)ceph.io > >>> > To unsubscribe send an email to ceph-users-leave(a)ceph.io > >>> > > >>> _______________________________________________ > >>> ceph-users mailing list -- ceph-users(a)ceph.io > >>> To unsubscribe send an email to ceph-users-leave(a)ceph.io > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io >

1 0

replace OSD failed
by Tony Liu 04 Feb '21

04 Feb '21

Hi, With 15.2.8, run "ceph orch rm osd 12 --replace --force", PGs on osd.12 are remapped, osd.12 is removed from "ceph osd tree", the daemon is removed from "ceph orch ps", the device is "available" in "ceph orch device ls". Everything seems good at this point. Then dry-run service spec. ``` # cat osd-spec.yaml service_type: osd service_id: osd-spec placement: hosts: - ceph-osd-1 data_devices: rotational: 1 db_devices: rotational: 0 # ceph orch apply osd -i osd-spec.yaml --dry-run +---------+----------+------------+----------+----------+-----+ |SERVICE |NAME |HOST |DATA |DB |WAL | +---------+----------+------------+----------+----------+-----+ |osd |osd-spec |ceph-osd-3 |/dev/sdd |/dev/sdb |- | +---------+----------+------------+----------+----------+-----+ ``` It looks as expected. Then "ceph orch apply osd -i osd-spec.yaml". Here is the log of cephadm. ``` /bin/docker:stderr --> relative data size: 1.0 /bin/docker:stderr --> passed block_db devices: 1 physical, 0 LVM /bin/docker:stderr Running command: /usr/bin/ceph-authtool --gen-print-key /bin/docker:stderr Running command: /usr/bin/ceph --cluster ceph --name client.bootstrap-osd --keyring /var/lib/ceph/bootstrap-osd/ceph.keyring osd tree -f json /bin/docker:stderr Running command: /usr/bin/ceph --cluster ceph --name client.bootstrap-osd --keyring /var/lib/ceph/bootstrap-osd/ceph.keyring -i - osd new b05c3c90-b7d5-4f13-8a58-f72761c1971b 12 /bin/docker:stderr Running command: /usr/sbin/vgcreate --force --yes ceph-a3886f74-3de9-4e6e-a983-8330eda0bd64 /dev/sdd /bin/docker:stderr stdout: Physical volume "/dev/sdd" successfully created. /bin/docker:stderr stdout: Volume group "ceph-a3886f74-3de9-4e6e-a983-8330eda0bd64" successfully created /bin/docker:stderr Running command: /usr/sbin/lvcreate --yes -l 572318 -n osd-block-b05c3c90-b7d5-4f13-8a58-f72761c1971b ceph-a3886f74-3de9-4e6e-a983-8330eda0bd64 /bin/docker:stderr stderr: Volume group "ceph-a3886f74-3de9-4e6e-a983-8330eda0bd64" has insufficient free space (572317 extents): 572318 required. /bin/docker:stderr --> Was unable to complete a new OSD, will rollback changes ``` Q1, why VG name (ceph-<id>) is different from others (ceph-block-<id>)? Q2, where is that 572318 from? Since all HDDs are the same model, VG "Total PE" of all HDDs is 572317. Has anyone seen similar issues? Anything I am missing? Thanks! Tony

1 2

Multisite reshard stale instances
by Szabo, Istvan (Agoda) 04 Feb '21

04 Feb '21

Hi, I found 6-700 stale instances with the reshard stale instances list command. Is there a way to clean it up (or actually should I clean it up)? The stale instance rm doesn't work in multisite. Thank you ________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses.

1 0

log_meta log_data was turned off in multisite and deleted
by Szabo, Istvan (Agoda) 04 Feb '21

04 Feb '21

Hi, Is there a way to reinitialize the stored data and make it sync from the logs? Thank you ________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses.

1 0

Re: Using RBD to pack billions of small files
by Loïc Dachary 04 Feb '21

04 Feb '21

Hi Frederico, On 04/02/2021 05:51, Federico Lucifredi wrote: > Hi Loïc, > I am intrigued, but am missing something: why not using RGW, and store the source code files as objects? RGW has native compression and can take care of that behind the scenes. Excellent question! > > Is the desire to use RBD only due to minimum allocation sizes? I *assume* that since RGW does have specific strategies to take advantage of the fact that objects are immutable and will never be removed: * It will be slower to add artifacts in RGW than in an RBD image + index * The metadata in RGW will be larger than an RBD image + index However I have not verified this and if you have an opinion I'd love to hear it :-) Cheers > > Best -F > > > -- "'Problem' is a bleak word for challenge" - Richard Fish > _________________________________________ > Federico Lucifredi > Product Management Director, Ceph Storage Platform > Red Hat > A273 4F57 58C0 7FE8 838D 4F87 AEEB EC18 4A73 88AC > redhat.com <http://redhat.com> TRIED. TESTED. TRUSTED. > > > On Sat, Jan 30, 2021 at 10:01 AM Loïc Dachary <loic(a)dachary.org <mailto:loic@dachary.org>> wrote: > > Bonjour, > > In the context Software Heritage (a noble mission to preserve all source code)[0], artifacts have an average size of ~3KB and there are billions of them. They never change and are never deleted. To save space it would make sense to write them, one after the other, in an every growing RBD volume (more than 100TB). An index, located somewhere else, would record the offset and size of the artifacts in the volume. > > I wonder if someone already implemented this idea with success? And if not... does anyone see a reason why it would be a bad idea? > > Cheers > > [0] https://docs.softwareheritage.org/ <https://docs.softwareheritage.org/> > > -- > Loïc Dachary, Artisan Logiciel Libre > > > > > > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io <mailto:ceph-users@ceph.io> > To unsubscribe send an email to ceph-users-leave(a)ceph.io <mailto:ceph-users-leave@ceph.io> > -- Loïc Dachary, Artisan Logiciel Libre

3 3