Staggered upgrade or not
Hi Upgrading from Pacific 16.2.15 to Quincy 17.2.5 Environment: Production Size: 9PB RAW capacity 5 mon/mgr/mds host. 56 storage nodes I’m looking for advice to help me decide between - Staggered upgrade or not. Thanks
My sense is that the default, assuming that you’re containerized, works well on its own, and the staggered path is less common so it may have more snags. ycmv.
On May 8, 2025, at 8:43 AM, Kasper Rasmussen <kasper_steengaard@hotmail.com> wrote:
Hi
Upgrading from Pacific 16.2.15 to Quincy 17.2.5
Environment: Production
Size: 9PB RAW capacity 5 mon/mgr/mds host. 56 storage nodes
I’m looking for advice to help me decide between - Staggered upgrade or not.
Thanks _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
On production environments, I only do staggered upgrades. Has worked great so far for me. Zitat von Anthony D'Atri <aad@dreamsnake.net>:
My sense is that the default, assuming that you’re containerized, works well on its own, and the staggered path is less common so it may have more snags. ycmv.
On May 8, 2025, at 8:43 AM, Kasper Rasmussen <kasper_steengaard@hotmail.com> wrote:
Hi
Upgrading from Pacific 16.2.15 to Quincy 17.2.5
Environment: Production
Size: 9PB RAW capacity 5 mon/mgr/mds host. 56 storage nodes
I’m looking for advice to help me decide between - Staggered upgrade or not.
Thanks _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi, Am 5/8/25 um 14:43 schrieb Kasper Rasmussen:
I’m looking for advice to help me decide between - Staggered upgrade or not.
The staggered upgrade process has the advantage that the restart of the MDS can be exactly scheduled and therefor communicated better. First the cluster gets upgrade for everything including the OSDs. The time needed for upgrading the OSDs cannot be estimated exactly as it depends on the number of OSDs and the data delta occuring during the upgrade. But then you can continue with the MDS and know when that happens. You can schedule it to a time of day when CephFS may not be used as much. Regards -- Robert Sander Linux Consultant Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: +49 30 405051 - 0 Fax: +49 30 405051 - 19 Amtsgericht Berlin-Charlottenburg - HRB 220009 B Geschäftsführer: Peer Heinlein - Sitz: Berlin
Hi Kasper, Any reason why you're targeting v17.2.5? Is it to match the version in use on another cluster? I'm asking this because the recommended path for major upgrades is usually going from latest point release to latest point release like <N>.x.<latest_point_release> to <N+1 or N+2>.x.<latest_point_release> which in your situation would be Pacific v16.2.15 to Quincy v17.2.8. Even though this time, you'd better avoid v17.2.8 due of [1] and upgrade to v17.2.7 if you need to use Quincy. With that said, unless you need to use Quincy, I would recommend going directly from Pacific v16.2.15 to the latest Reef v18.2.7, as this is well-supported and tested. Regards, Frédéric. [1] https://www.mail-archive.com/ceph-users@ceph.io/msg28886.html ----- Le 8 Mai 25, à 14:43, Kasper Rasmussen kasper_steengaard@hotmail.com a écrit :
Hi
Upgrading from Pacific 16.2.15 to Quincy 17.2.5
Environment: Production
Size: 9PB RAW capacity 5 mon/mgr/mds host. 56 storage nodes
I’m looking for advice to help me decide between - Staggered upgrade or not.
Thanks _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Thanks Frederic I was actually not aware that it was possible to skip ahead to reef directly from pacific, but I see now that it is. That will save some work! Br. Kasper
On 9 May 2025, at 11.20, Frédéric Nass <frederic.nass@univ-lorraine.fr> wrote:
Hi Kasper,
Any reason why you're targeting v17.2.5? Is it to match the version in use on another cluster?
I'm asking this because the recommended path for major upgrades is usually going from latest point release to latest point release like <N>.x.<latest_point_release> to <N+1 or N+2>.x.<latest_point_release> which in your situation would be Pacific v16.2.15 to Quincy v17.2.8. Even though this time, you'd better avoid v17.2.8 due of [1] and upgrade to v17.2.7 if you need to use Quincy.
With that said, unless you need to use Quincy, I would recommend going directly from Pacific v16.2.15 to the latest Reef v18.2.7, as this is well-supported and tested.
Regards, Frédéric.
[1] https://www.mail-archive.com/ceph-users@ceph.io/msg28886.html
----- Le 8 Mai 25, à 14:43, Kasper Rasmussen kasper_steengaard@hotmail.com a écrit :
Hi
Upgrading from Pacific 16.2.15 to Quincy 17.2.5
Environment: Production
Size: 9PB RAW capacity 5 mon/mgr/mds host. 56 storage nodes
I’m looking for advice to help me decide between - Staggered upgrade or not.
Thanks _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
participants (5)
-
Anthony D'Atri
-
Eugen Block
-
Frédéric Nass
-
Kasper Rasmussen
-
Robert Sander