Open Stack

And consider well your networking: available bandwidth, redundancy,
how front-end client traffic and back-end traffic share or don't share
resources.  Red Hat, Inc in their storage products typically advocates
keeping internal-to-swift network traffic off of NICs handling client
traffic.

Networking can make or break your deployment.

On Mon, Nov 25, 2013 at 12:39 AM, John Dickinson <me at not.mn> wrote:
> 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
>
>
> _______________________________________________
> 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
>