Hello Istvan, Upon further reflection, I believe the script could also be utilized to facilitate the removal of nodes/OSDs, not just for adding new ones. The key point is that you shouldn't remove the OSDs and purge them immediately after running the script, as you did previously. Instead, once you've run the script and your cluster has returned to HEALTH_OK status, you should: 1. Wait for the balancer to remap all PGs (until no further optimizations are occurring). 2. Allow all data to evacuate from these old OSDs. You can verify this by checking the 'ceph osd df tree' command - it should show "0" in the PGS column for these OSDs. Only after completing steps 1 and 2 should you proceed to take the OSDs out and purge them. This approach will ensure a smoother transition and maintain data integrity throughout the process. Cheers, Frédéric. ----- Le 9 Sep 24, à 17:15, Frédéric Nass frederic.nass@xxxxxxxxxxxxxxxx a écrit : > Hi Istvan, > > This can only ease when adding new storage capacity to the cluster (and maybe > when data migration is involved like when changing cluster's topology or crush > rules?). > > When adding new nodes, PGs will be remapped to make use of the new OSDs, which > will trigger some data migration. The problem is that all OSDs will try to move > some data to the new OSDs at the same time, resulting in significant load on > the cluster and specific contentions that may have a negative impact clients > I/O. > > That's where Dan's / DigitalOcean script comes in. It remaps the PGs to only use > the OSDs (from the 'ACTING' set) where the data is already located (it didn't > move yet), and forget about the new OSDs (that appeared in the 'UP' set when > the new hardware was added to the cluster), relying on 'upmap' balancer to > further do its job and gradually remap the PGs to use the new OSDs, in a more > gradual way and less contention-prone manner. > > Won't help with the OSD removal scenario you've described - if I'm not mistaken > - since the data these OSDs hold will still have to move to others OSDs when > you take them 'out'. > > Cheers, > Frédéric. > > ----- Le 9 Sep 24, à 15:56, Istvan Szabo, Agoda Istvan.Szabo@xxxxxxxxx a écrit : > >> Hi, >> >> I've played around a bit with these scripts, finally I went with the pgremapper >> one because it's documented better and no need multiple run but I'd like to get >> some confirmation about the functionality from someone who used it because it >> was too fast. >> >> What I've tested is the cancel-backfill (pgremapper cancel-backfill --yes) >> option as written in the documentation: >> https://github.com/digitalocean/pgremapper which is based on the >> upmap-remapped.py >> >> It made me 2 questions, hopefully someone can answer: >> >> Q1 regarding osd removal: >> What I've done in test env: >> >> 1. Set the flags: ceph osd set nobackfill;ceph osd set norebalance >> 2. Reweight all the osds that I want to remove: for i in {36..43};do ceph osd >> reweight $i 0.0;done >> 3. Run the tool and wait couple of minutes to get back the prompt: pgremapper >> cancel-backfill --yes >> 4. Unset flags: ceph osd unset norebalance;ceph osd unset nobackfill >> 5. When cluster health ok, I removed the osds: for num in {36..43}; do ceph osd >> out osd.$num;systemctl disable ceph-osd@$num;systemctl purge $num >> --yes-i-really-mean-it;umount /var/lib/ceph/osd/ceph-$num;done >> >> 1. >> >> >> In theory here I'm missing a lot of chunks so how I know that all the data >> actually recovered/regenerated somewhere else in the cluster? Because it was >> too fast. If the ceph balancer status says no more optimization that is >> considered to be the done signal? >> >> Q2 regarding the process: >> Could this tool be used for removal actually or only extension? Reweight can be >> up and down however they say augment which for me extension. >> "Example - Cancel all backfill in the system as a part of an augment >> This is useful during augment scenarios, if you want to control PG movement to >> the new nodes via the upmap balancer (a technique based on this CERN >> talk<https://www.slideshare.net/Inktank_Ceph/ceph-day-berlin-mastering-ceph-operations-upmap-and-the-mgr-balancer>." >> >> Thank you >> >> ________________________________ >> From: Szabo, Istvan (Agoda) <Istvan.Szabo@xxxxxxxxx> >> Sent: Monday, September 9, 2024 2:07 PM >> To: Janne Johansson <icepic.dz@xxxxxxxxx> >> Subject: Re: Re: Somehow throotle recovery even further than basic >> options? >> >> Let me try to understand, so this actually move pg by pg to the new osds which >> means will not push the osds on the same hosts too hard due to 1 pg at a time. >> Am I correct? >> >> Also if something goes wrong, is it possible to stop this script and let it go >> as is or if I want it faster, can I? >> As I see this can be used during rebalance also, just need to stop rebalance, >> run the script and unset rebalance. >> >> ________________________________ >> From: Janne Johansson <icepic.dz@xxxxxxxxx> >> Sent: Saturday, September 7, 2024 2:00 PM >> To: Eugen Block <eblock@xxxxxx> >> Cc: ceph-users@xxxxxxx <ceph-users@xxxxxxx> >> Subject: Re: Somehow throotle recovery even further than basic >> options? >> >> Email received from the internet. If in doubt, don't click any link nor open any >> attachment ! >> ________________________________ >> >> The pgremapper (and the python one) will allow you to mark all the PGs >> that a new disk gets as an empty-misplaced PG to be correct where they >> currently are. This means that after you run one of the remappers, the >> upmap will tell the cluster to stay as it is even though new empty >> OSDs have arrived with correct crush weights and all. >> >> So you set norebalance, add N+1 new OSDs, the cluster shudders for a >> short while when the new-empty PGs are created on the new drives, then >> you have lots and lots of misplaced PGs which norebalance prevents >> from starting backfills on. >> >> Then you run the remapper and "fix" the upmap so all the current >> placements are considered "correct", and hence the PGs that were >> supposed to move stop being misplaced. After this, you remove >> "norebalance" to allow moves to start happening. >> >> By now, no movement (or at least very few PGs) should occur. What >> happens next is that the balancer notices there actually is more >> space, and figures out the optimal result is more or less the same as >> above where lots of PGs should go to the new OSDs, but it does this >> with the max-misplaced-ratio in mind, and it will "move" the PGs by >> just unsetting their upmap entry that forced them to want to stay in >> place, so as time passes, it moves a few PGs at a time, and moves them >> by removing the upmaps from them so that most of the time your other >> OSDs will look perfectly healthy and will continue to do all the >> scrubs and things a healthy OSD should do and which it will not do if >> it has a long queue of backfills waiting to eat up all the slots for >> non-client IO. >> >> While you can do soft additions with increasing crush weights, this >> potentially causes lots of more movements since an OSD host with OSDs >> going from 0.1 to 0.2 weight might not place all PGs in the same spot >> in those two cases, so you could have movement within the host and so >> on from the recalculated pseudorandom placements on every increase. >> >> Den lör 7 sep. 2024 kl 00:15 skrev Eugen Block <eblock@xxxxxx>: >>> >>> I can’t say anything about the pgremapper, but have you tried >>> increasing the crush weight gradually? Add new OSDs with crush initial >>> weight 0 and then increase it in small steps. I haven’t used that >>> approach for years, but maybe that can help here. Or are all OSDs >>> already up and in? Or you could reduce the max misplaced ratio to 1% >>> or even lower (default is 5%)? >>> >>> Zitat von "Szabo, Istvan (Agoda)" <Istvan.Szabo@xxxxxxxxx>: >>> >>> > Forgot to paste, somehow I want to reduce this recovery operation: >>> > recovery: 0 B/s, 941.90k keys/s, 188 objects/s >>> > To 2-300Keys/sec >>> > >>> > >>> > >>> > ________________________________ >>> > From: Szabo, Istvan (Agoda) <Istvan.Szabo@xxxxxxxxx> >>> > Sent: Friday, September 6, 2024 11:18 PM >>> > To: Ceph Users <ceph-users@xxxxxxx> >>> > Subject: Somehow throotle recovery even further than >>> > basic options? >>> > >>> > Hi, >>> > >>> > 4 years ago we've created our cluster with all disks 4osds (ssds and >>> > nvme disks) on octopus. >>> > The 15TB SSDs still working properly with 4 osds but the small 1.8T >>> > nvmes with the index pool not. >>> > Each new nvme osd adding to the existing nodes generates slow ops >>> > with scrub off, recovery_op_priority 1, backfill and recovery 1-1. >>> > I even turned off all index pool heavy sync mechanism but the read >>> > latency still high which means recovery op pushes it even higher. >>> > >>> > I'm trying to somehow add resource to the cluster to spread the 2048 >>> > index pool pg (in replica 3 means 6144pg index pool) but can't make >>> > it more gentle. >>> > >>> > The balancer is working in upmap with max deviation 1. >>> > >>> > Have this script from digitalocean >>> > https://github.com/digitalocean/pgremapper, is there anybody tried >>> > it before how is it or could this help actually? >>> > >>> > Thank you the ideas. >>> > >>> > ________________________________ >>> > 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. >>> > _______________________________________________ >>> > ceph-users mailing list -- ceph-users@xxxxxxx >>> > To 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 >>> >>> >>> _______________________________________________ >>> ceph-users mailing list -- ceph-users@xxxxxxx >>> To unsubscribe send an email to ceph-users-leave@xxxxxxx >> >> >> >> -- >> May the most significant bit of your life be positive. >> _______________________________________________ >> ceph-users mailing list -- ceph-users@xxxxxxx >> To unsubscribe send an email to ceph-users-leave@xxxxxxx >> >> ________________________________ >> 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. >> _______________________________________________ >> ceph-users mailing list -- ceph-users@xxxxxxx >> To 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 _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |