Open Stack

Actually it was 1M hosts and  Ivthink 45 million vms.  It was meant to
be across all regions.  Jason Seats set the number arbitrarily, but it
is a good target to not let us forget about scaling while we design.

I think eventually all loads will be more ephemeral.  So, I think I
agree with your numbers, if you are talking about a single availability
zone.

On 12/30/2010 11:25 AM, Erik Carlin wrote:
> You are right.  The 1M number was VMs not hosts.  At least, that was from
> one scale discussion we had within Rackspace.  I'm not sure what the
> "official" nova target limits are and I can't find anything on launchpad
> that defines it.  If there is something, could someone please send me a
> link.
> 
> I'm am certain that Google can manage more than 10K physical servers per
> DC. Rackspace does this today.
> 
> If I combine what I know about EC2 and Cloud Servers, I would set the ROM
> scale targets as:
> 
> ABSOLUTE
> 1M VMs
> 50K hosts
> 
> RATE
> 500K transactions/day (create/delete server, list servers, resize server,
> etc. - granted, some are more expensive than others)
> That works out to ~21K/hr but it won't be evenly distributed.  To allow
> for peak, I would say something like 75K/hour or ~21/sec.
> 
> Thoughts?
> 
> Erik
> 
> 
> On 12/30/10 9:20 AM, "Pete Zaitcev" <zaitcev at redhat.com> wrote:
> 
>> On Wed, 29 Dec 2010 19:27:09 +0000
>> Erik Carlin <erik.carlin at rackspace.com> wrote:
>>
>>> The 1M host limit still seems reasonable to me. []
>>
>> In my opinion, such numbers are completely out of whack. Google's Chubby
>> article says that the busiest Chubby has 90,000 clients (not hosts!) and
>> the biggest datacenter has 10,000 systems. They found such numbers
>> pushing the border of unmanageable. Granted they did not use
>> virtualization, but we're talking the number of boxes in both cases.
>>
>> So to reach 1M hosts in a Nova instance you have to have it manage
>> 100 datacenters. There are going to be calls for federation of Novas
>> long before this number is reached.
>>
>> Sustaining a high flap rate is a worthy goal and will have an
>> important practical impact. And having realistic sizing ideas is
>> going to help it.
>>
>> -- Pete
> 
> 
> 
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace. 
> Any dissemination, distribution or copying of the enclosed material is prohibited.
> If you receive this transmission in error, please notify us immediately by e-mail
> at abuse at rackspace.com, and delete the original message. 
> Your cooperation is appreciated.
> 
> 
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20101230/456626f7/attachment.sig>