[Openstack-operators] Rados Gateway to Swift migration

Xav Paice xavpaice at gmail.com
Tue Oct 4 22:02:42 UTC 2016


On Tue, 2016-10-04 at 21:56 +0000, Fox, Kevin M wrote:
> OpenStack really needs a way to have a control api for selecting a swift "flavor", and letting you have multiple swift endpoints within, so swift the software, radowgw, and vendor endpoints can all co'exist.
> 

Just thinking about it, we use haproxy and the url for requests does
include the project id, so we might be able to regex the requests and
direct to the appropriate backend.  It could make for complex support
issues in the meantime, but a much smoother migration.

> Kevin
> ________________________________________
> From: Xav Paice [xavpaice at gmail.com]
> Sent: Tuesday, October 04, 2016 2:45 PM
> To: Curtis
> Cc: OpenStack Operators
> Subject: Re: [Openstack-operators] Rados Gateway to Swift migration
> 
> On Tue, 2016-10-04 at 07:18 -0600, Curtis wrote:
> > On Mon, Oct 3, 2016 at 3:31 PM, Xav Paice <xavpaice at gmail.com> wrote:
> > > Hi,
> > >
> > > We're in the process of migrating our object storage from Rados Gateway
> > > to Swift, and I was wondering if anyone has experiences with the data
> > > migration steps from one to the other?
> > >
> > > In particular, we're currently copying each object and container one by
> > > one, but the process of inspecting each and every object is incredibly
> > > slow.  The logic we have is kind of rsync-like, so we can repeat and
> > > iterate until it's close, but the final go-live cutover will still take
> > > many hours to complete.  Ideas on how to get over that would be very
> > > much appreciated!
> >
> > Could you load balance to on backend or another based on whether or
> > not the account has been migrated yet? I haven't thought that through
> > completely...
> >
> 
> That would be the preferable situation, migrating one customer at a
> time, but we couldn't figure out how to achieve that goal without
> writing some kind of middleware/proxy type of thing, or being clever
> with haproxy.  We may yet have to go down that route, but I'm hoping
> not!
> 
> 
> > Thanks,
> > Curtis.
> >
> > >
> > > Many thanks
> > >
> > >
> > > _______________________________________________
> > > OpenStack-operators mailing list
> > > OpenStack-operators at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> >
> >
> 
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





More information about the OpenStack-operators mailing list