[cisco-voip] CPU Reservations

[Ryan Huff]

Adam,

You'd probably be less likely to have an "issue" if the host's aggregate compute resources are at least 30%-35% below subscribed capacity (but no guarantees). Real time traffic on the software such as mtp, moh,.. etc (I think UCOS even has some files that internally communicate via real time or near real time) can be a diva at times. There are two things that come to mind that I have always seen give issue to real time traffic without fail;


  *   latency and jitter, albeit spatial or mechanical such as distance or clock cycles
  *   unreliable or latent synchronization (I'd humbly suggest this is anything over 5 hops from a cesium clock, but Cisco says 3 so we'll go with that)

I've found that if you violate either of these, you can be in for a wild ride. The symptoms are often obscure, inconsistent and seemingly unrelated to any other known issues; a small delay in voice that randomly pops up here or there for one or two phones, a presence HA pair that randomly fails over for no apparent reason, some phones not showing call history, SIP trunks going out of service.. etc. These issues can be very difficult to troubleshoot because there won't "appear" to be anything wrong.

Its "hit or miss" at best with the CPU reservations (on a host that is not already over subscribed) I'd say; if the UC VM has to wait (delay) on cycle time, even for a fraction of a second, it may or may not cause you an issue... just depends on what the server was trying to do at the time, and if it involved real time traffic. If you've got UC VMs in the mix with HA / clustering, then the VMs will be even less tolerant of asking for cycle time rather than it just being available.

The safest path is to guarantee (reserve) the require resources to the UC VM, even though it may not ever (or nearly never) use the full capacity (because having cycle time readily available and having to ask the scheduler for cycle time that is available is not the same thing).

Think of it like insurance, you're not paying for it because you don't need it (actual waste), you're paying because of that one time you do need it and don't know it.

Thanks,

Ryan
________________________________
From: cisco-voip <cisco-voip-bounces at puck.nether.net> on behalf of Pawlowski, Adam <ajp26 at buffalo.edu>
Sent: Monday, July 8, 2019 11:57 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] CPU Reservations


Hi all,



It’s been a bit since I’ve asked this question, if I have here before.



Do we all run our UC appliances in VMWare with the full CPU MHz and core reservations prescribed by Cisco, in production? Or, if you have information on hand regarding the actual resource usage, have any of you taken on resizing the VM reservations?



The various documents are very much so clear that oversubscription isn’t supported, but, it also talks about vCPU to cores which I’m told doesn’t really play out in VMWare as it’s a MHz reservation that can be scheduled in to available hardware.



There are various statements peppered in about running your own VM environment with best practices – but also the 1:1 pcore:vcore comments.



Is anyone turning these knobs? Has anyone stepped over that pcore:vcore line when it appears there are enough resources?



I’m looking for thoughts or unforeseen consequences that we can use to back somewhat of the case as to why we need to continue to fund hardware at scale which is largely idle.



Adam




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190709/7a5bf542/attachment.htm>