Preparat per a la CPU: l’assassí d’hipervisors silenciosos

CPU Ready és una cosa que potser no coneixeu. En una primera impressió, pot semblar una cosa bona, però malauradament no ho és. CPU Ready ha estat afectant entorns virtuals durant més temps del que sabíem de què es tractava. VMware ho defineix com el 'Percentatge de temps que la màquina virtual estava preparada, però no s'ha pogut programar per executar-se a la CPU física. El temps de preparació de la CPU depèn del nombre de màquines virtuals de l'amfitrió i de les càrregues de la CPU '. Hyper-V només ha començat recentment a proporcionar aquest comptador (processador Hyper-V Hypervisor Virtual Temps d'espera de la CPU per enviament) i és possible que altres hipervisors encara no proporcionin aquesta mètrica.

Per entendre què és CPU Ready, haurem d’entendre com els hipervisors programen les CPU virtuals (vCPU) a les CPU físiques (pCPU). Quan es necessita temps de vCPU en una màquina virtual, cal programar vCPU (s) contra pCPU (s) perquè les ordres / processos / fils puguin executar-se contra la pCPU. En un món ideal, no hi ha conflictes de recursos ni colls d’ampolla quan això passi. Quan una sola màquina virtual de vCPU necessita programar temps contra una pCPU, hi ha disponible un nucli de pCPU i la CPU Ready és molt mínima en aquest món ideal. És important tenir en compte que CPU Ready sempre existeix, però en un món ideal és molt mínim i no es nota.

Al món real, un dels avantatges de la virtualització és que podeu apostar que moltes de les vostres màquines virtuals no augmentaran totes les seves CPU virtuals al mateix temps i, si són màquines virtuals d’ús molt baix, fins i tot podeu fer suposicions de quant podeu carregueu el vostre amfitrió físic en funció de l’ús de la CPU i l’ús de RAM. En el passat, es feien recomanacions per tenir una proporció de 4 vCPU a 1 pCPU o fins i tot una relació de 10: 1 en funció de la càrrega de treball. Per exemple, és possible que tingueu un processador quad core únic, però que tingueu 4 màquines virtuals amb vCPU cadascuna per proporcionar-vos 16 vCPU a 4 pCPU o 4: 1. El que començaven a veure els enginyers és que els entorns eren terriblement lents i no sabien per què. L’ús de RAM semblava correcte, fins i tot l’ús de la CPU als ordinadors físics és molt baix, per sota del 20%. La latència d’emmagatzematge era extremadament baixa, tot i que les màquines virtuals eren extremadament lentes.

El que passava en aquest escenari era CPU Ready. Hi havia una cua del vCPU preparada per ser programada, però no hi havia cap pCPU disponible per programar. L'hipervisor aturaria la programació i provocaria latència a la màquina virtual convidada. És un assassí silenciós que fins als darrers anys no hi havia moltes eines per detectar. En una màquina virtual de Windows, trigaria a arrencar-se per sempre i, en acabar, quan feu clic al menú d’inici, trigaria una vegada a aparèixer. Fins i tot podeu tornar-hi a fer clic pensant que no va acceptar el vostre primer clic i, quan finalment es posi al dia, obtindreu un doble clic. A Linux, la màquina virtual pot arrencar en mode de només lectura o fins i tot canviar els sistemes de fitxers al mode de només lectura en algun moment més tard.

Llavors, com combatem la CPU Ready? Hi ha algunes maneres que us poden ajudar. El primer és controlar les mètriques de CPU Ready. A VMware, no es recomana passar per sobre del 10%, però per experiència personal, els usuaris comencen a notar per sobre del 5-7% en funció del tipus de màquina virtual i del que s’executi.

A continuació faré servir alguns exemples de VMware ESXi 5.5 per mostrar CPU Ready. Amb la línia d’ordres, executeu “esxtop”. Premeu 'c' per visualitzar la CPU i hauríeu de veure una columna ' % RDY ”Per a CPU Ready. Podeu prémer majúscules ' V ”Per a la visualització només de màquina virtual.

Aquí podeu veure que% RDY és una mica elevat per a un entorn força inutilitzat. En aquest cas, el meu ESXi 5.5 està executant una màquina virtual de prova a la part superior de VMware Fusion (hipervisor Mac), de manera que s’espera que sigui una mica de gamma alta, ja que estem executant una màquina virtual a un hipervisor a sobre d’un altre hipervisor.

Al client vSphere, podeu extreure la màquina virtual específica i fer clic a la pestanya Rendiment. Des d'allà, feu clic a 'Opcions del gràfic'

Dins de les opcions de gràfics, seleccioneu CPU, en temps real (si teniu vCenter, és possible que tingueu altres opcions de temps que no pas en temps real). Des d'allà, als comptadors, seleccioneu 'A punt'. És possible que hàgiu de desseleccionar un comptador diferent, ja que la visualització només permet dos tipus de dades en un moment donat.

Tingueu en compte que aquest valor és un resum de llest versus un percentatge. Aquí hi ha un enllaç a un article de VMware KB sobre com convertir les mètriques resumides en un percentatge. - https://kb.vmware.com/kb/2002181

En comprar maquinari, més nuclis ajuden a disminuir l’impacte de CPU Ready. La hipertereografia també ajuda. Tot i que Hyperthreading no proporciona un segon nucli complet per a cada nucli primari, normalment és suficient per permetre la programació de la vCPU a pCPU i ajudar a mitigar el problema. Tot i que els hipervisors comencen a allunyar-se de la recomanació de la proporció de vCPU a pCPU, normalment es pot fer bé en un entorn d’ús moderat amb 4: 1 i anar-hi. Quan comenceu a carregar màquines virtuals, observeu la latència de la CPU, la CPU Ready i la sensació i el rendiment generals. Si teniu algunes màquines virtuals molt impactants, us recomanem que les segregueu en altres clústers i que utilitzeu una proporció més baixa i que les mantingueu lleugeres. D'altra banda, per a les màquines virtuals on el rendiment no és clau i està bé que funcionin lentament, podeu subscriure-us molt més.

La mida adequada de les màquines virtuals també és una eina enorme per combatre la CPU Ready. Molts proveïdors recomanen especificacions sobre el que pot necessitar la màquina virtual. Tradicionalment, més CPU i més nuclis = més potència. El problema en un entorn virtual és que l'hipervisor ha de programar totes les vCPU a pCPU aproximadament al mateix temps i bloquejar les pCPU pot ser problemàtic. Si teniu una màquina virtual de 8 vCPU, heu de bloquejar 8 PCU per permetre que es programin al mateix temps. Si la màquina virtual de vCPU només utilitza el 10% del total de vCPU en un moment donat, és millor que feu baixar el compte de vCPU a 2 o 4. És millor executar una màquina virtual a un 50-80% de CPU amb menys vCPU que un 10% a més vCPU. Aquest problema es deu en part perquè el programador de la CPU del sistema operatiu està dissenyat per utilitzar tants nuclis com sigui possible, mentre que si estigués entrenat per maximitzar els nuclis abans d’utilitzar-ne més, pot ser que tingui menys problemes. Una màquina virtual de grans dimensions pot tenir un bon rendiment, però pot ser un 'veí sorollós' per a altres màquines virtuals, de manera que sol ser un procés on heu de passar per totes les màquines virtuals del clúster a la 'mida adequada' per tal de veure alguns guanys de rendiment.

Moltes vegades heu entrat a punt per a CPU i és difícil començar a dimensionar bé les màquines virtuals o actualitzar a processadors amb més nuclis. Si us trobeu en aquesta situació, afegir més hosts al vostre clúster us pot ajudar a repartir la càrrega a més hosts. Si teniu amfitrions amb més nuclis / processadors que altres, també us pot ajudar lligar màquines virtuals de vCPU elevades a aquests amfitrions de nucli superiors. Voleu assegurar-vos que el vostre amfitrió físic tingui almenys el mateix nombre de nuclis si no més que la màquina virtual, en cas contrari serà molt lent / difícil programar l'excés de vCPU a pCPU, ja que cal bloquejar-lo aproximadament al mateix temps .

Finalment, el vostre hipervisor pot admetre reserves i límits a la màquina virtual. De vegades, les tesis es configuren accidentalment. La configuració agressiva d'aquests pot fer que la CPU estigui preparada quan de fet hi hagi recursos subyacents disponibles. Normalment és millor utilitzar les reserves i els límits amb moderació i només quan sigui absolutament necessari. En la seva major part, un clúster de mida adequada equilibrarà adequadament els recursos i normalment no són necessaris.

En resum, la millor defensa contra CPU Ready és saber que existeix i com comprovar-ho. A continuació, podeu determinar sistemàticament els millors passos de mitigació per al vostre entorn tenint en compte l’anterior. En la seva major part, la informació d’aquest article s’aplica universalment a qualsevol hipervisor, tot i que les captures de pantalla i els gràfics s’apliquen específicament a VMware.