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 <m...@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 <pravar3...@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@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@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@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
