On Wed, Sep 24, 2014 at 11:17 AM, Craig Lewis <clewis at centraldesktop.com> wrote: > Yehuda, are there any potential problems there? I'm wondering if duplicate > bucket names that don't have the same contents might cause problems? Would > the second cluster be read-only while replication is running? I might have missed part of the original requirements. This sync assumes that B starts as a clean slate. No writes are allowed to it while data is being copied into it. Once ready, all writes to A should be quiesced. Once sync completes, they would then need to reconfigure their system to make B the primary zone. Yehuda > > Robin, are the mtimes in Cluster B's S3 data important? Just wondering if > it would be easier to move the data from B to A, and move nodes from B to A > as B shrinks. Then remove the old A nodes when it's all done. > > > On Tue, Sep 23, 2014 at 10:04 PM, Yehuda Sadeh <yehuda at redhat.com> wrote: >> >> On Tue, Sep 23, 2014 at 7:23 PM, Robin H. Johnson <robbat2 at gentoo.org> >> wrote: >> > 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. >> >> You need to setup a second rgw zone, and use the radosgw sync agent to >> sync data to the secondary zone. That will preserve mtimes and ACLs. >> Once that's complete you could then turn the secondary zone into your >> primary. >> >> Yehuda >> _______________________________________________ >> ceph-users mailing list >> ceph-users at lists.ceph.com >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > >
 |