Open Stack

Hello, Duncan,

You are right. It's not simple multiplier game. 

The performance or scalability bottleneck is mainly impacted from two aspect: request concurrency to the cloud, and the volume of the objects (including VM,Volume,Port,etc).

We can discuss that in a scenario: there are 1 million VMs in the cloud, and one cascading OpenStack manages 100 cascaded OpenStacks, the concurrency of request and data volume will be distributed evenly among cascaded OpenStacks. Let's suppose the concurrency of request is 1000 TPS.

For the cascaded layer: TPS is 10, and the VM instance object table contains 10K VMs (or more, for some record deleted but stay there). It's much easier to install and tune performance in such scale.

For the cascading layer: TPS is 1000, and the VM instance object table contains 1 million VMs (or more, for some record deleted but stay there). In the cascading layer, only 100 proxy nodes to be managed by the cascading OpenStack. If we scale one OpenStack to manage a 1 million VMs cloud, and suppose one compute nodes can run 20 VMs, then there are 50k compute nodes.

The challenge to scale the cascading OpenStack is smaller than one normal OpenStack instance to manage a cloud with 1 million VMs. The following performance advantage is obviously:

1. Reduce scheduling burden. Nova,Cinder scheduling only according to availability zone.
2. Nova,Cinder Host status and resources track task is much light weight
3. Reduce temporary status update to the DB. There are lots of internal state update messages during VM/volume creation. The number of exchanged message / DB access for one VM/Volume creation will be reduced greatly by batch periodic polling the VM/Volume stabl status from the cascaded OpenStack.
4. Less L2 population and L3 DVR router update nodes involved. Because the L2/L3 proxy delegates one cascaded OpenStack, and often VMs of one tenant/network will be limitedly located in one or two or three cascaded OpenStacks, the L2 population and L3 DVR population traffic will be greatly reduced in the cascading level
5. Ceilometer data will be collected in distributed ceilometers. I mentioned for 1 million level cloud, it's roughly estimated 20GB/minute data will be generated(based on current sampling way).   

But, The performance enhancement by cascading is not simple multiplier to a cascaded OpenStack scalability, although it provide a way to scale a cloud easier. 

That's because, the concurrency and latency for DB query is not easy to achieve linear growth with more resources to put into, even if we split DB and tables. For big table, RDBMS cannot realize very good CRUD performance. And also, the concurrency will heavily be affected by the ceiling of message bus.

Therefore, and as what we have discussed, the scalability of one OpenStack instance is always necessary and it's the fundamental for OpenStack cascading.

Best Regards
Chaoyi Huang ( Joe Huang )


-----Original Message-----
From: Duncan Thomas [mailto:duncan.thomas at gmail.com] 
Sent: Friday, October 10, 2014 3:37 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

On 9 October 2014 07:49, henry hly <henry4hly at gmail.com> wrote:
> Hi Joshua,
>
> ...in fact hierarchical scale
> depends on square of single child scale. If a single child can deal 
> with 00's to 000's, cascading on it would then deal with 00,000's.

That is faulty logic - maybe the cascading solution needs to deal with global quota and other aggregations that will rapidly break down your scaling factor, or maybe there are few such problems can the cascade part can scale way better than the underlying part. They are two totally different scaling cases, so and suggestion that they are anything other than an unknown multiplier is bogus.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev