> - IIUC, if a root SSD fails, there is pretty much >no way to rebuild a new>node with the same OSDs and avoid data >shuffling - is this correct?You can still rebuild the node and add old OSDs and avoid shuffling. Might need to enable NOOUT flag while you work on configuration of new node.>- If the hardware, fails - I assume replacing >the part and rebooting in>time will bring back the node as is - is this >right? Sounds correct.>- If the root drive fails, is there a way to bring >up a new host with the>same OSDs in the same order but with a >different host name / ip address?Should be possible as each OSD authenticate with its own credentials which should not count on the IP address change. But IP should be in the same subnet as the cluster.>FWIW we are using rook, so I am wondering if >the crush map can be>configured with some logical labels instead >of host names for this purpose That should be possible.>-Assuming we use a shared SSD with >partitions for WAL/ Metadata for the>whole node - if this drive fails, I assume we >have to recover the entire>node. Correct? I remember seeing a note that >this pretty much renders all>the relevant OSDs useless.Thats correct. If DB/WAL is lost, you would have to recover osd which has db broken. >Semi-related: What is the ideal ratio of SSDs >for WAL/metadata to count>of OSDs? I remember seeing pdfs from >Redhat showing a 1:10 ratio, The>mailing list has references to 1:3 or 1:6. I am >trying to figure out what>the right number is. It depends. The recommendation is 1-4% of OSD size for DB. But it depends on how many tiny objects you would have which would mainly occupy rocksdb (db).Надіслано з пристрою Galaxy -------- Оригінальне повідомлення --------Від: Subu Sankara Subramanian <subu.zsked@xxxxxxxxx> Дата: 12.11.21 18:41 (GMT+02:00) Кому: ceph-users@xxxxxxx Тема: Handling node failures. Folks, New here - I tried searching for this topic in the archive, couldn't findany since 2018 or so. So starting a new thread. I am looking at the impactof node failures. I found this doc:https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/4/html/operations_guide/handling-a-node-failure- I have a few questions about this:- IIUC, if a root SSD fails, there is pretty much no way to rebuild a newnode with the same OSDs and avoid data shuffling - is this correct?- If the hardware, fails - I assume replacing the part and rebooting intime will bring back the node as is - is this right?- If the root drive fails, is there a way to bring up a new host with thesame OSDs in the same order but with a different host name / ip address?FWIW we are using rook, so I am wondering if the crush map can beconfigured with some logical labels instead of host names for this purpose- Is this possible? ( I am evaluating if I can bring up a new node backwith the original host name itself - at least the cloud K8s clusters makethis impossible).- Assuming we use a shared SSD with partitions for WAL/ Metadata for thewhole node - if this drive fails, I assume we have to recover the entirenode. Correct? I remember seeing a note that this pretty much renders allthe relevant OSDs useless.-- Semi-related: What is the ideal ratio of SSDs for WAL/metadata to countof OSDs? I remember seeing pdfs from Redhat showing a 1:10 ratio, Themailing list has references to 1:3 or 1:6. I am trying to figure out whatthe right number is.Thanks. Subu_______________________________________________ceph-users mailing list -- ceph-users@xxxxxxxxx unsubscribe send an email to ceph-users-leave@xxxxxxx _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |