Open Stack

OK.. In a sunny day scenario, in my 4 replica configuration, and with a
region 1 write affinity, I do see the 3rd copy in the r1 hand off location
deleted upon async replication to zone 1 and zone 2 within region 2.

In a rainy day scenario with no region 2 storage servers available upon new
file upload, i do not see the region 1 hand off object deleted upon region
2 restore and subsequent sync.

Am I missing something within my configuration?



On Wed, Sep 17, 2014 at 11:25 AM, Drudy, Gerry <Gerry.Drudy at hp.com> wrote:

>  The object in the handoff location should get removed once it is
> successfully copied to the primary locations. Check object-replicator error
> logs like “Error syncing handoff partition”.
>
>
>
> Gerry.
>
>
>
>
>
> *From:* Brent Troge [mailto:brenttroge2016 at gmail.com]
> *Sent:* 17 September 2014 16:48
> *To:* John Dickinson
> *Cc:* openstack at lists.openstack.org
> *Subject:* Re: [Openstack] SWIFT - Write Quorum
>
>
>
>
>
> If an object write is sent to a hand off location, is that object deleted
> from that hand off location once the primary write location is written to?
> In my testing, I forced a new object write to hand off locations. Once I
> brought the primary locations back online, the object is then written to
> all primary locations however the object still resides in the handoff
> location.
>
> Please advise.
>
> Thanks!
>
>
>
> On Tue, Sep 9, 2014 at 12:41 PM, Brent Troge <brenttroge2016 at gmail.com>
> wrote:
>
>  Thanks John.. I truly appreciate your clear and concise answers.
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Sep 9, 2014 at 12:09 PM, John Dickinson <me at not.mn> wrote:
>
> Well listings is slightly different than being able to read the data if
> you already know the object name.
>
> Assuming no failures in the system, the container listings will be up to
> date before the end-user gets a 2xx response. That is, create a new object,
> then immediately do a listing, and you'll see the object in that listing.
>
> However, we can pretty safely assume that there will be failures at some
> point (especially if it's a larger cluster). In that case, the end-user
> will still get a 2xx response because the data was durably flushed to disk,
> but the container listing update may fall back to an asynchronous update.
> In that case, you may or may not get the object in a container listing
> until container replication has completed. But you'll still be able to read
> the object directly if you know the name.
>
> --John
>
>
>
> On Sep 9, 2014, at 9:15 AM, Brent Troge <brenttroge2016 at gmail.com> wrote:
>
> > Thanks..  My understanding is that an object will not be listed within a
> container until it completes replication throughout the cluster. Thats what
> I meant by 'listing'
> >
> > But you corrected that mis-understanding.  Such that, with respect to my
> 3 write requirement, an object will be available  in each region once I
> receive a 200 upon file ingest.
> >
> >
> >
> >
> >
> > On Tue, Sep 9, 2014 at 10:02 AM, John Dickinson <me at not.mn> wrote:
> > I'm not sure what the question is.
> >
> > If you are looking to have a successful response after it's written
> twice in a cluster with 4 replicas, no. Swift's quorum calculation is
> (replicas DIV 2 + 1). This means that for 4 replicas, you have a quorum
> size of 3. What I would suggest you look in to is the write_affinity
> setting so that you can do a full-quorum (at least) write to the local
> region and then asynchronously replicate to the other region. See
> http://docs.openstack.org/developer/swift/admin_guide.html#geographically-distributed-clusters
> and
> https://swiftstack.com/blog/2012/09/16/globally-distributed-openstack-swift-cluster/
> .
> >
> > If you are looking to ensure that there is at least one replica in each
> region, then yes. The quorum size of three (see above) will ensure that,
> without any write_affinity settings, you'll have at least one replica in
> each region and two in another before the client gets a 2xx success
> response code to the PUT request.
> >
> > --John
> >
> >
> >
> > On Sep 9, 2014, at 6:59 AM, Brent Troge <brenttroge2016 at gmail.com>
> wrote:
> >
> > >
> > >
> > > If I configure Swift to use 4 replicas across two regions(two replicas
> per region), is it possible to only list a newly ingested object if it has
> written at least twice? The goal is to only list a new object only if it
> has a presence in each region.
> > >
> > > west coast
> > > region 1 - zone 1
> > > region 1 - zone 2
> > >
> > > east coast
> > > region 2  - zone 1( 3?)
> > > region 2 -  zone 2( 4?)
> > >
> > > Thanks!
> > >
> > >
> > > _______________________________________________
> > > Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > > Post to     : openstack at lists.openstack.org
> > > Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
> >
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140917/a6d8095c/attachment.html>