[cisco-voip] UC on UCS - platform selection: quantity vs quality

Fri Dec 14 12:20:54 EST 2012

Inline...

-Ryan
> 
> On Dec 14, 2012, at 11:49 AM, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
> 
> 
> I don't begin to pretend to understand the nuances of VMware or how it's virtual servers can impact other servers, however, the OVAs and the doc wiki should be updated accordingly to allow for a half decent cookie cutter approach to building out the requirements. Design and redundancy aside, if the doc wiki says that you can load as many OVAs on a server as long as you follow the rules, you should be able to do so with a reasonable amount of certainty. Otherwise, the doc wiki should be updated to include updates such as: don't use up all your cores, have a few to spare, etc. 

The docwiki can only so far because the rules vary by UC application.  There is an effort underway to get everyone to play by the same rules but that's much easier said than done.   The one big rule that governs CPUs and their utilization is the "No Hardware Oversubscription".  This means you decide what apps you want to virtualize, how to size those apps, then determine how much hardware you need.  Redundancy is certainly a component in that calculation.  

> 
> Also, no where does the doc wiki talk about CPU utilization on the servers, while I wouldn't want to purposely run all my VMs at 80% CPU utilization, considering there is a 1-to-1 vCPU:pCore relationship, and there is CPU reservations, why should that matter? Again, I might be showing my naivete here, but if one server's CPU utilization can affect the other servers on the VM infrastructure, something's amiss.

CPU reservations only get you a specific amount of mHz.  The only app that actually has cpu affinity is Unity.  Without cpu affinity then the app doesn't care which core it's running on, but the reservation takes care of guaranteeing that the host has the cpu resources available to the guest (and prevents guests from starting up if their reservation requirements cannot be met).  If all your VMs get cpu reservations (or affinity) then one app misbehaving won't impact the others.  As soon as you start oversubscribing then one guest taking up all of the hosts resources most certainly will impact other guests running on the host.   VMware lets you do all kinds of cool things but just because you can do something doesn't mean you should.  

> 
> With respect to design and redundancy, I agree, but there should be some base and resources to work from. In our case, we (will) have redundant servers for each purpose, so if one box were to go down, the other box would carry the full load. Aside from the publisher (which you can't replicate in any design), everything would have it's active/active pair.
> 
> Now, the one question that is still in the air is UCCx. There were some (unwritten?) requirements that stated that both UCCx boxen had to be on the same building/network/switch (whatever). I'm hoping that requirement is lifted in v9.x and we can span the UCCx HA pair across high speed, low latency data centres. If not, it might mean purchasing a small C-Series box just to hold one of the UCCx HA members.
> 
> Thanks again for the comments, they're helpful.
> 
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
> (519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Cooking with unix is easy. You just sed it and forget it. 
>                               - LFJ (with apologies to Mr. Popeil)
> 
> 
> From: "Nick Matthews" <matthnick at gmail.com>
> To: "Lelio Fulgenzi" <lelio at uoguelph.ca>
> Cc: "Terry Oakley" <Terry.Oakley at rdc.ab.ca>, "cisco-voip" <cisco-voip at puck.nether.net>
> Sent: Tuesday, December 11, 2012 5:32:05 PM
> Subject: Re: [cisco-voip] UC on UCS - platform selection: quantity vs quality
> 
> A lot of it is IOPS from how many hard drive spindles you have. I believe a good portion of the UC app suites are IO bound.
> 
> Realistically there is a lot of overhead with UC on UCS - the 'standard' ships with 48 GB memory which you'll probably never use.  
> 
> I view it more as risk mitigation. I had a customer with 2 C-series that hit a Vmware issue that brought down the entire box.  They have a 3 node cluster, 1 pub 2 subs. Well, both subs were on the same Vmware box and they were the only CTI subscribers for UCCX. So even though everything is redundant, you have to be very careful about VM placement. As well, with 2 boxes rather than 4 the co-residency restrictions will be more severe as you have more applications that have to agree on the co-res details.
> 
> But that's why they call it design and not science. There's good reasons for wanting 2 boxes instead of 4 and it's dependent on your environment.  Or you could just host it all in the cloud, I'm told it's a cool place.
> 
> -nick
> 
> 
> 
> On Mon, Dec 10, 2012 at 10:49 AM, Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
> Thanks Terry. That would be great.
> 
> While I understand there are doc based specs and real life, I'm a little concerned with the push to multiple chassis. There's quite a bit of overheard per chassis, including the additional VMware license and support costs. If there are concerns with running too many apps on one box, why don't they list that anywhere in the specs, i.e. for every 5 servers, reserve one free CPU, or something like that. They do that with the Unity Connection spec, so it's easy to do it with others.
> 
> Anyways, I'll wait to hear back.
> 
> 
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
> (519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Cooking with unix is easy. You just sed it and forget it. 
>                               - LFJ (with apologies to Mr. Popeil)
> 
> 
> From: "Terry Oakley" <Terry.Oakley at rdc.ab.ca>
> To: "Lelio Fulgenzi" <lelio at uoguelph.ca>, "cisco-voip" <cisco-voip at puck.nether.net>
> Sent: Monday, December 10, 2012 10:42:55 AM
> Subject: RE: [cisco-voip] UC on UCS - platform selection: quantity vs quality
> 
> 
> We are just starting to look at upgrading from HP hardware to UC on UCS so will forward our supports ‘recommendations’ once they arrive.   Currently they are just getting the stats together but should have something in 2 weeks but am curious to see how they match up to your supports recommendations.
>  
> Terry
>  
>  
> Terry Oakley
> Telecommunication Coordinator, | Information Technology Services
> 100 College Blvd | Red Deer, AB T4N 5H5
> Tel (403) 342-3521 | Terry.Oakley at rdc.ab.ca
> <image001.jpg>
>  
>  
>  
> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Lelio Fulgenzi
> Sent: December-10-12 7:55 AM
> To: cisco-voip
> Subject: [cisco-voip] UC on UCS - platform selection: quantity vs quality
>  
> 
> I had some interesting feedback from my SE after he discussed our UC on UCS requirements with his support network. Basically, the feedback was, rather than two UCS C260s, I should get four UCS 240s. This was to provide maximum hardware/software redundancy and maximum performance.
> 
> While I understand the additional hardware/software redundancy, I'm not 100% convinced about the maximum performance. I mean we read through the requirements on the wiki, ensured we had the required CPUs for each application, and there was quite a bit of harddisk, cpu and memory to spare. I'd rather minimize the amount of time managing the hardware and also reduce costs as much as possible.
> 
> I understand the C240s are the new M3 specs, and the C260s are the older M2 specs, but I'm guessing those too will be updated soon. 
> 
> What sort of feedback are others getting who are investigating UC on UCS chasis servers?
> 
> 
> 
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
> (519) 824-4120 x56354 (519) 767-1060 FAX (ANNU)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Cooking with unix is easy. You just sed it and forget it. 
>                               - LFJ (with apologies to Mr. Popeil)
> 
> 
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20121214/ec7dd61b/attachment.html>