In that case, Yiping, I would *definitely* recommend putting those servers into at least two pools. The processors used in Gen8 and Gen9 servers can not currently be joined into the same pool, and you actually need to be very sensitive to the processor steppings. Dundee should fix that, but no current version of CloudStack supports Dundee (and neither does Citrix at the moment).
-tim On Wed, Mar 9, 2016 at 12:38 PM, Yiping Zhang <yzh...@marketo.com> wrote: > Hi, Tim: > > Thanks for very detailed reply. > > These are Gen8 HP blades and all my new servers will be Gen9. That’s why > I’d like to combine them into one maxed out cluster. I have only two guest > VLAN’s and roughly 400 VM instances for this 10 hosts cluster. So I think > performance wise I should be OK. > > Yiping > > > > On 3/8/16, 4:28 PM, "Tim Mackey" <tmac...@gmail.com> wrote: > > >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 > >> > > >> >
