Open Stack

Swift has a modular design, and this allows you the flexibility to deploy to match your needs.

Common deployment patterns are (1) proxy, account, container, object all running on the same hardware (2) proxy on one SKU and account+container+object on another SKU (3) proxy on one SKU, account+container on one SKU, and object on one SKU

I know of production clusters in each of those styles. You would choose one based on your use case, scale, budget, and integration concerns. Specifically to the last point, you need to think about load balancing, SSL termination, identity integration, monitoring and altering, log aggregation, network topologies, etc. There's a ton of factors to consider, but the fundamental design of Swift let's you compose the pieces of the storage engine into a storage system that works very well for you.

--John





On Nov 24, 2013, at 8:56 PM, Pravar Jawalekar <pravar3088 at gmail.com> wrote:

> Dear Stackers!!
> 
> I have one question related to 'how swift is actually deployed in production environment',
> How object/container/auth servers made communicate to actual underlying storage infrastructure?
> I mean do deployment strategy of swift imposes any such restrictions that services for container, object etc. should be running on node where actual storage is present?
> 
> I am sorry if my questions is confusing.
> But please throw some light in this area - although i have gone through deployement documents found on open stack sites but they did not seem to give real picture of swift deployment in real world.
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131124/9173d693/attachment.sig>