Remember that there are 3 copies of each container, too. The proxy is setting a header in each PUT to the object server. The object server reads the header to know which container server to update. Failure scenarios are handled better this way.
All ok: proxy sends PUT to 3 object servers. All 3 servers successfully store the object and then each update one of the 3 container servers. Proxy returns success to the client. Failure A: proxy sends PUT to 3 object servers. 2 object servers successfully store the object and each update one of the container servers. Object replication makes sure the object is updated on the 3rd node, and container replication makes sure the listing is updated on the 3rd container server. Because 2 copies of the object were written, the proxy returns a 2xx to the client. Failure B: proxy sends PUT to the 3 object servers. All 3 servers successfully store the object and then each update one of the 3 container servers. Except this time one of the updates to the container servers fails. That object server will queue the update for later async update, and replication will also eventually put it there. Proxy returns success to the client. Failure B: proxy sends PUT to the 3 object servers, All 3 servers successfully store the object, but none of the container updates are successful. Each object server queues the async update for the container, and the container listing gets updated when the container servers become available again. Proxy returns success to the client. One of the main reasons to move the container listing update to the objects servers (out of the proxy server) is to allow more safety when containers servers aren't available. Since each request is to only one proxy, if a single proxy fails after writing the object but before updating the container, the container update is forever lost. Hope this explains the design decisions and the differences in the code you are seeing. --John On Sep 28, 2011, at 6:39 PM, Caitlin Bestler wrote: > The ObjectController class in objs/server.py contains a container_update > method to update the > Object entry in the Container after an Object has been updated. > > Since multiple Object Servers will update the same object this struck me > as curious, surely doing > It in the Proxy Server would be more efficient. > > Only in proxy/server.py the _connect_put_node would seem to update the > Container after an > Object has been put in the Proxy Server itself. > > Can someone explain the difference between these two sections of code, > and why any of the > work is being done in each Object Server? > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
