If we want to keep the existing LRC (which would be great), the important part is the internal state of the system. So as Patrick alludes to, we *could* create a single cluster that is stretched across old and new labs, and then use CRUSH rule changes to move everything into the new space. I'm not sure this is easier than simply shipping the existing nodes intact and then using them to seed a new LRC in-place, if we have a solution to store what we need in the lab until that shipping happens. To keep the historical aging of the cluster, we do need the existing LRC nodes to be part of it when we generate the cluster, though — we can't merge them later in any meaningful way. I'm not sure if that changes your perception of how reasonable those options are, David. -Greg On Mon, Mar 24, 2025 at 9:17 AM Patrick Donnelly <pdonnell@redhat.com> wrote:
On Mon, Mar 24, 2025 at 12:02 PM David Galloway <David.Galloway@ibm.com> wrote:
Buy new LRC gear, migrate what’s necessary, integrate old Sepia gear into “new” LRC
I don't think we necessarily need to keep the old sepia LRC nodes. As long as we migrate everything to new hardware it should be good. I think the LRC can just steal 3-6 nodes from the hardware we already plan to purchase (for the upstream lab).
I think the troublesome part will be the RADOS replication to the new site. Will we have the VPN straddling the two sites at some point?
-- Patrick Donnelly, Ph.D. He / Him / His Red Hat Partner Engineer IBM, Inc. GPG: 19F28A586F808C2402351B93C3301A3E258DD79D _______________________________________________ Sepia mailing list -- sepia@ceph.io To unsubscribe send an email to sepia-leave@ceph.io