Yiping,

Here's the detailed answer ....

>From the XenServer perspective, there are a number of factors which go into
how various configuration limits are arrived at. Most of the time, they
aren't hard limits (for example I know of users with more than 16 hosts in
a pool). What the XenServer team do is for a given metric they determine
the point at which overall scalability is reduced to a target threshold.
That then becomes the "configuration limit" for a given release, and we
retest with every version.

In the case of the "hosts per pool" limit, we need to ensure that all
operations we have can be performed without impairment with a given number
of hosts in a pool. We've kept the same maximum number of hosts in a pool
for a very long time (close to ten years so far), and that's a direct
reflection of how much we've increased individual host scalability.

>From a CloudStack perspective, there have been a number of serious scale
limits which have pushed XenServer. Hundreds of VLANs is one example that
Ahmad cites, but its also a case of the number of VMs and needing to manage
all those VM objects.  iirc, the eight host recommendation came from some
large deployment requirements. If you don't have a need for 100s of VLANs
per pool, or aren't running 100s of VMs per host, you likely will be able
to get more than eight hosts per pool.

>From an operations perspective, I would look closely at your pool size and
ask the question of why you want to such a large pool.  I'd argue having
two pools of five hosts is more efficient in CloudStack than a single pool
of ten hosts, plus if something should happen to one pool, the remaining
pool will continue to be available.  CloudStack is very efficient at
managing resource pools, so many of the reasons traditional server admins
cite for wanting large pool sizes aren't as relevant in CloudStack.

Of particular note is how you scale. With a ten host pool size, that's your
scalability block size, so as you grow you'll want to increase capacity in
chunks of ten hosts. With a smaller pool size, you'd be able to add
capacity in much smaller chunks.

-tim

On Tue, Mar 8, 2016 at 5:24 PM, Ahmad Emneina <aemne...@gmail.com> wrote:

> IIRC, its just a recommendation. I think it stemmed from performance
> impact, due to numerous VLAN's present, in environments with lots of
> tenants.
>
> On Tue, Mar 8, 2016 at 2:10 PM, Yiping Zhang <yzh...@marketo.com> wrote:
>
> > Hi, all:
> >
> > The CloudStack doc recommends that for XenServer, do not put more than 8
> > hosts in a cluster, while the Citrix XenServer doc says that XenServer
> 6.5
> > can natively support 16 hosts in a cluster (resource pool).
> >
> > I am wondering why CloudStack is recommending a smaller cluster size than
> > that XenServer can natively support?  If I create a cluster with 10
> > XenServers, what could go wrong for me ?  Has any one tried with CS
> cluster
> > with >8 XenServer hosts ?
> >
> > My environment is CS 4.5.1 (soon to be upgraded to 4.8.0) on RHEL 6.7 and
> > XenServer 6.5, using NetApp volumes for both primary and secondary
> storages.
> >
> > Yiping
> >
>

Reply via email to