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 <[email protected]> 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     : [email protected]
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Reply via email to