Web Client (07A): Shares

Los shares nos permiten priorizar máquinas virtuales dentro de un Resource Pool respecto a otras máquinas virtuales o RP del mismo nivel.

Solo se usan cuando hay contención en un recurso dado.

Si una VM tiene el doble de shares que otra VM, podrá acceder el doble de recursos en un resource pool o Parent Pool (host/cluster)

Los shares solo tienen sentido con VM o con Resources Pool “siblings “hermanos”, es decir, que estén en el mismo nivel

Según cambiamos el share (LOW, NORMAL, HISGH, CUSTOM) el “Shared Value” se modifica y por lo tanto el “% shares” que ocupa en el resource Pools. En este ejemplo DC01 le pusimos un share de High (el doble de normal), por lo que tendrá doble acceso a los recursos en caso únicamente de conten cion CPU en este caso

% Shares

Nos indica el porcentaje de acceso al resource Pool en caso de contención, nos lo muestra en porcentaje. Solo visible con el vsphere Client, no con el Web Client

Tengo un Resource Pool “Padre” en el cual hay 3 VM. Si no configuro ningún share, por ejemplo, en CPU, vemos que todos tienen un 33 % de acceso a la CPU

Si a la VM XP02 le pondo a la CPU un “shares values” de High, es decir, 200, (recordar que el ratio es 4:2:1 à high:normal:low) tendrá el doble de acceso a los recursos (50%) en caso de contención, con respecto a XP03 y 04 (25%) por eso cambia

CPU/MEM/Storage “Shares Values”

Es la prioridad que damos a las VM (a nivel CPU, Mem y datastore) y que se modifica en resource settings

No obstante, en el vCenter nos aparecerán los “shares vaules” con distinto numero dependiendo de cómo configuremos los “Shares” de CPU, memoria y Datastore como en la imagen anterior

Shares Values a nivel de VM

  • CPU: los shares a nivel de CPU tienen en cuenta el número de CPU de la VM. Si la VM solo tiene una CPU este es el valor
    • Low= 500
    • Normal =1000
    • High= 2000

Nota: si tuvieran dos vCPU los valores seria low (1000), normal (2000), High (4000)

 

  • Memoria: los shares values lo determina la memoria asignada en la máquina virtual (la del wizard de creación, no reservation) multiplicado por 5, 10, 0 20
    • Low: 5 * memory RAM 5*1024 = 5120 de shares (cuatro veces menos acceso que un High)
    • Normal: 10 * memory RAM 10*1024 = 10240 de share values (la mitad de acceso que un High)
    • High: 20 * memory RAM 20*1024 = 20480 de share values

    Si una VM tiene 354 Mb el low sera 384 *5 = 1920, el normal 384*10=3840 y high 384*20 = 7680

    Supongamos que tenemos un cluster con 200 Ghx/200 Gb RAM, y tengo dos RP con un ratio 4:1

Para saber el número de shares de RAM que tiene un clúster se calcula con valor de 20 (high), 10 (normal), 5 (low) que es estándar y no adecuado si no tenemos el mismo numor de VM dentro de cada Poo

  • 204.800 mb (200gb) * 20 shares = 4.096.000 Vm’s shares total en el cluster
  • 204.800 mb (200gb) * 5 shares = 1.024.000 Vm’s shares total en el cluster

 

  • Almacenamiento: Si múltiples VM acceden al mismo Datastore y en la misma LUN, usaríamos los shares para priorizar el acceso a disco. Por defecto el share es de 1000 (como en CPU)

Es editable a nivel de Máquina virtual. En la setting de la VM > expandimos el disco


Si todas las VM que están en un datastore estuvieran en normal (1000) sus discos, los 5 VM tendrán un 20% de acceso a los recursos


Pero si pongo algunas en Low y High cambia el porcentaje


 

NOTA: Requiere configurar el SIOC a nivel del Datastore para que funcione los SHARES con el almacenamiento para todas las VM independientemente del host en el que este alojado.


 

 

Shares Values a nivel de Resource Pool

También podemos asignar Shares a un resource pool, el cual competirá por los recursos en casos de contención con otros Resource Pool.

Se edita en “edit resource settings


à

Como se calcula

  • CPU: Se calcula igual que la CPU de una VM pero multiplicados por 4 vCPU. Si creamos un Resource Pool con un Shares “Normal”, que en teoría son 1000, pero que lo multiplica por 4, es decir 4000
    • Low: 2 vCPU * 1000= 2000
    • Normal: 4 vCPU *1000 = 4000
    • High= 8 vCPU * 1000= 80000

 

  • Memoria: si el share está establecido en “Normal” se le aplica 163840 (16 Gb), la mitad si es low y el doble si es high
    • Low: = 81920
    • Normal= 163840
    • High= 327680

 

 

 

USO DE SHARES CORRECTOS EN RESOURCE POOLS “USAR CUSTOM SHARES”

– Tenemos un Cluster con 100 Gb RAM y 100 vCPU

– Tenemos un Resource Pool de producción “RP1” con 90 máquinas y un RP2 de desarrollo con 10 máquinas virtuales

– Yo quiero que en caso de contención las VM de producción tengan 4 veces más acceso a los recursos

Enfoque 1: no usar los custom Shares

Estos enfoques solo van bien
en el caso de que el número de maquina virtuales en los Resource pool sean idénticos

En circunstancias normales pensaríamos en poner al RP1 un share “high” y a RP un share “low”, es decir 4 veces más

Si mi Cluster tiene un 100 % de recursos de memoria:

  • Al “RP1 High” le corresponden el 80 % de la RAM, es decir 80 Gb del cluster
  • Al “RP2 Low” le corresponde el 20 % de la RAM, es decir 20 Gb del clúster

Coe este diseño lo estamos enfocando mal

– En “RP1 High”: 80 Gb de RAM para 90 máquinas. Entonces 80gb / 90 VM = 0,88 Gb Ram para cada VM

– En “RP2 Low”: 20 Gb de RAM para 10 máquinas. Entonces 20 GB / 10 VM = 2 GB para cada VM

 

REPITO: Este enfoque solo van bien
en el caso de que el número de maquina virtuales en los Resource pool sean idénticos

Enfoque 2 (CORRECTO): usar Custom Shares en el Resource Pool

Si yo quiero que producción tenga 4 veces más que desarrollo, me digo a mi mismo,

Como quiero que las VM de producción tengan 4 veces más de recursos, por ejemplo, las VM de producción pueden tener unos shares de 200 y las de producción 50 para desarrollo (o también 4 para producción y 1 para desarrollo).

Da igual el número, el caso es la diferencia de 4, la fórmula es:

Tengo que aplicar la formula

  • RP1 High (Producción): 90 VM * 200 shares= 18.000 shares a configurar en “RP1 high” // también vale 90 * 4 = 360
  • RP2 Low (Desarrollo) 10 VM * 50 shares= 500 shares a configurar en “RP2 Low” // también vale 10 * 1 = 10

Si tengo en un resource pool 18000 shares / 90 VM sales a 200 shares por VM, y el otro Resource pool de desarrollo tiene 500 shares / 10 VM sale a 50 shares por VM, es decir 4 veces mas

 

Con el enfoque correcto. En un cluster de 100 Gb quedaría 97,2 % para producción y 2.7 % desarrollo

Esta fórmula lo saco con una regla de tres:

  • si 18500 shares (18000 +500) es el 100 % entonces 18000 shares es… = 97.2% (18000*100)/ 18500
  • si 18500 shares (18000 +500) es el 100 % entonces 500 shares es… = 2.7 % (500*100)/ 18500

Cuanto le corresponde a cada VM en caso contencion

  • El 97,2 % de 100 Gb = 97,2 GB para el “RP1 High”, è 97.2 GB / 90 VM = 1.08 GB para cada VM
  • El 2,7 % de 100 Gb = 2,7 GB para el “RP1 Low”, è 2,7 GB / 10 VM = 0.27 Gb para cada VM

Si multiplicamos 0,27 (gb) *4 veces más recursos = 1,08 que es la memoria de producción, es decir 4 veces mas.

Mas fácil de calcular si ponemos custom shared de 4 y otro de 1

  • RP1 High (Producción): 90 VM * 4 shares= 360 shares a configurar en “RP1 high”
  • RP2 Low (Desarrollo) 10 VM * 1 shares= 10 shares a configurar en “RP2 Low

360 shares entre 90 VM son 4 shares por VM, y 10 sares entre 10 VM son 1 share por VM, es decir el ratio 4:1 de nuestra organización

Be the first to comment

Leave a Reply