On Tue, Sep 23, 2014 at 03:12:53PM -0600, John Nielsen wrote: > Keep Cluster A intact and migrate it to your new hardware. You can do > this with no downtime, assuming you have enough IOPS to support data > migration and normal usage simultaneously. Bring up the new OSDs and > let everything rebalance, then remove the old OSDs one at a time. > Replace the MONs one at a time. Since you will have the same data on > the same cluster (but different hardware), you don't need to worry > about mtimes or handling RBD or S3 data at all. The B side already has data however, and that's one of the merge problems (see below re S3). > Make sure you have top-level ceph credentials on the new cluster that > will work for current users of Cluster B. > > Use a librbd-aware tool to migrate the RBD volumes from Cluster B onto > the new Cluster A. qemu-img comes to mind. This would require downtime > for each volume, but not necessarily all at the same time. Thanks, qemu-img didn't come to mind as an RBD migration tool. > Migrate your S3 user accounts from Cluster B to the new Cluster A > (should be easily scriptable with e.g. JSON output from > radosgw-admin). It's fixed now, but didn't used to be possible to create all the various keys. > Check for and resolve S3 bucket name conflicts between Cluster A and > ClusterB. None. > Migrate your S3 data from Cluster B to the new Cluster A using an > S3-level tool. s3cmd comes to mind. s3cmd does not preserve mtimes, ACLs or CORS data; that's the largest part of the concern. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robbat2 at gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
 |