Open Stack

Hey Alejandro,

While this probably isn't the answer your looking for, I will give you my 0.02.

Someone might be able to make you feel a little bit better, but I wouldn't take anyones word directly that you will be ok because obviously your installation, setup, and use case are all custom to you.

You need to do one (or both) of the following:

1) Look at your current usage pattern, utilizing metrics (swift-informant or what have you) and then extrapolate your usage and load to see what it would be like at X * volume, obviously you want enough capacity in the end result where your not close to your breaking point.

2) Actually test your load, Simulate the queries/benchmark against your current or a test cluster (depending obviously on your tolerance for failure of a prod cluster), and find out for sure how much load you can handle.

Obviously your going to a large order of magnitude larger traffic, so the scale won't be linear but it will give you a much better idea. If you really want someone to tell you if you will be ok, you need to give specific metrics around disk, memory, load, etc usage. Also you might want to look at going to a newer version of swift.

Thanks,
Josh Pasqualetto
Sonian DevOps

On Oct 24, 2012, at 10:56 AM, Alejandro Comisario wrote:

> Guys ??
> Anyone ??
> 
> 
> 
> Alejandro Comisario 
> #melicloud CloudBuilders
> Arias 3751, Piso 7 (C1430CRG) 
> Ciudad de Buenos Aires - Argentina
> Cel: +549(11) 15-3770-1857
> Tel : +54(11) 4640-8443
> 
> 
> On Mon, Oct 15, 2012 at 11:59 AM, Kiall Mac Innes <kiall at managedit.ie> wrote:
> While I can't answer your question (I've never used swift) - it's worth mentioning many of the openstack folks are en-route/at the design summit.
> 
> Also - you might have more luck on the openstack-operators list, rather than the general list.
> 
> Kiall
> 
> On Oct 15, 2012 2:57 PM, "Alejandro Comisario" <alejandro.comisario at mercadolibre.com> wrote:
> Its worth to know that the objects in the cluster, are going to be from 200KB the biggest and 50KB the tiniest.
> Any considerations regarding this ?
> 
> -----
> alejandrito
> 
> On Thu, Oct 11, 2012 at 8:28 PM, Alejandro Comisario <alejandro.comisario at mercadolibre.com> wrote:
> Hi Stackers !
> This is the thing, today we have a 24 datanodes (3 copies, 90TB usables) each datanode has 2 intel hexacores CPU with HT and 96GB of RAM, and 6 Proxies with the same hardware configuration, using swift 1.4.8 with keystone.
> Regarding the networking, each proxy / datanodes has a dual 1Gb nic, bonded in LACP mode 4, each of the proxies are behind an F5 BigIP Load Balancer ( so, no worries over there ).
> 
> Today, we are receiving 5000 RPM ( Requests per Minute ) with 660 RPM per Proxies, i know its low, but now ... with a new product migration, soon ( really soon ) we are expecting to receive about a total of 90.000 RPM average ( 1500 req / s ) with weekly peaks of 200.000 RPM ( 3500 req / s ) to the swift api, witch will be 90% public gets ( no keystone auth ) and 10% authorized PUTS (keystone in the middle, worth to know that we have a 10 keystone vms pool, connected to a 5 nodes galera mysql cluster, so no worries there either ) 
> 
> So, 3500 req/s divided by 6 proxy nodes doesnt sounds too much, but well, its a number that we cant ignore.
> What do you think about this numbers? does this 6 proxies sounds good, or we should double or triple the proxies ? Does anyone has this size of requests and can share their configs ?
> 
> Thanks a lot, hoping to ear from you guys !
> 
> -----
> alejandrito
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20121024/3de06186/attachment.html>