Client (07B): Porque usar Custom Shares y no Shares estandar

Sabemos que los shares se usan cuando hay contención a un recurso, y se pueden aplicar a:

  • Nivel de máquina Virtual. Cuando están dentro de un RP y ese RP no puede asignar más recursos físicos, entonces dependiendo de los shares de las VM tendrán más acceso a los recursos del Resource Pool, por ejemplo, un resource Pool con una reservation de 10 Gb y si memoria expandible.

    Todas las VM tendrán un el mismo peso relativo al acceder a los recursos en contención, un 12 %


  • A nivel de Resource Pool: Vemos que el padre del Resource Pool es el Cluster, el cual tiene disponible 16872 Mb de RAM, ya que como los Resource Pool no tienen Reservations pues pone 0 en “Reserved Capacity”.

Se supone que queremos que en caso de contención, los objetos de RP “producción” (High shares) tengan el doble acceso que el RP “SAP/Clientes” (normal shares) y cuatro veces más que RP “Desarrollo”. Nuestro Cluster es de 16872 MB.

Usando los Shares por defecto que creemos correctos, nos queda el acceso a los recursos.

  • Producción: 44% de 16872 = 7423 Mb
  • SAP: 22% de 16872 = 3711 Mb para los objetos de este RP
  • Clientes: 22% de 16872 = 3711 Mb para los objetos de este RP
  • Desarrollo: 11% de 16872= 1855 Mb para los objetos de este RP


Esto está bien si tuviéramos el mismo número de máquinas virtuales en cada RP, por ejemplo 10 VM en cada Resource pool

  • Producción: 7423 Mb: cada máquina tendría un 10 % de share es decir 742 mb
  • SAP: 3711 Mb: cada máquina tendría un 10 % de share es decir 371 mb
  • Clientes: 3711 Mb: cada máquina tendría un 10 % de share es decir 371mb
    • Desarrollo: 1855 Mb: cada máquina tendría un 10 % de share es decir 185 mb

Pero como los Resources Pool no están balanceados (cada RP tiene distinto número de VM), el peso real de las máquinas virtuales

  • Producción : 7423 / 10 vm = 742 mb por máquina virtual
  • SAP: 3711/ 4 vm = 927 mb por máquina virtual
    • Clientes: 3711 / 8 vm = 463 mb por máquina virtual
    • Desarrollo: 1855 / 1 vm = 1855 mb por máquina virtual

¡¡¡ No puede ser que en caso de contención la máquina de desarrollo tenga más acceso a los recursos, y las máquinas de producción, tenga menos que las de desarrollo e incluso la de los clientes !!!

Como solucionarlo:

Para esto se utilizan los Custom Shares, en vez los de por defecto High, Normal, Low

Para solucionarlo el truco es mantener el resource pool balanceado con matemáticas y “Custom Shares” y nunca usar los valores por defecto de High, Normal y Low. Para ello decidimos primero el peso de los Shares de las VM y ponerlo nosotros los valores y no dejar que lo haga VMware por nosotros

Si queremos que las VM de producción tengan un share de 200, las de “SAP/clientes” un share de 100, y las de desarrollo un share de 50 (un ratio de 4:2:1) debemos cambiar el resource pool shares de esta form, es decir un peso relativo de 4:2:1

  • Producción à      [90 VMs] * [200 shares] = 18.000 shares de RAM por CPU     à 18000 / 90 = 200 shares por vm
  • SAP à         [4 VM] * [100 shares] = 400 shares de RAM por CPU    à 400 / 4 = 100 shares por vm
  • Clientes à     [8 VM] * [100 shares] = 800 shares de RAM por CPU    à 800 / 8 = 100 shares por vm
  • Desarrollo à     [1 VM] * [50 shares] = 50 shares de RAM por CPU    à 50 / 1= 50 shares por vm

Nota: también podemos usar en vez del ratio [200 | 100 | 50] otro con la misma proporciona [4 | 2 | 1] , [100 | 50 | 25], da lo mismo


Vemos que automáticamente asigna el % de shares para que las VM que viven dentro de cada Resource pool tengan el peso relativo de 4:2:1 que queremos realmente. La reservation de CPU y RAM es otra cosa distinta

Otro ejemplo


En este escenario, Los Resource Pool compiten por los recusros entre ellos (ya que estan al mismo nivel), y las maquina virtuales dentro de un Resource Pool individual compiten contra las otras VM de ese RP. La VM de distintos RP no compite entre ellas

Se supone que si yo pongo a nivel de Resource Pool un ratio de 4:1, las VM de RP Gold tendrán 4 veces más acceso a los recursos que el RP bronce en caso de contención. Pero realmente para las VM que están dentro no es así. Esto solo sería así si hubiera el mismo número de VM en cada RP

Para saber el número total de shares de RAM del cluster

Cuando hablamos de Shares de VM se calcula con valor de 20 (high), 10 (normal), 5(low)

• 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

Calculamos cuanto shares tendrán cada VM de ambos RP.

Vemos que no nos cuadra, de hecho, tienen más recursos las VM del RP bronze si usamos los shares estándar (high, normal, low)

• RP Gold: 4.096.000 shares / 320 VM’s = 12.800 shares por VM

• RP Bronze: 1.024.000 shares / 40 VM’s = 25.600 shares por VM

Y si queremos saber cuánta memoria tendrá cada VM con los shares estandar

• RP Gold: 80% de 200 Gb = 160 Gb. Entonces 160 Gb / 320 VM’s = 0,5 Gb de RAM por VM en caso contención

• RP Bronze; 20% de 200 Gb = 40 Gb. Entonces 40 GB / 40 VM’s = 1 Gb de RAM por VM en caso contención

Solución: usar Shares Custom.

Como es un ratio de 4:1 elegimos uno. Por ejemplo 20 a 5, aunque puede ser “4 a 1” o “100 a 25”

• 320 VM’s * 20 shares = 6400 shares de RAM en el RP Gold. o Si hacemos 6400 shares /320 vm’s = 20 Shares cada VM

• 40 VM’s * 5 shares = 200 shares de RAM en el RP Gold. o Si hacemos 200 shares / 40 VM’s = 5 shares cada VM

Otro ejemplo.
Tenemos un Cluster con 100 vCPU y 100 GB de RAM (
102400 mb), sabemos que en cálculo de shares para VM es:


Este cálculo es lo que nos da shares para cada VM con los shares por defecto High, Normal Default

Formula calculo RAM: [Cluster RAM in MB] * [20 high | 10 normal | 5 low]

  • Shares High (Mem * 20 shares)    à 102.400 mb * 20 = 2.048.000 shares / 90 vm = 22.755
  • Shares Normal (Mem * 10 shares)    à 102.400 mb * 10 = 1.024.000 shares
  • Shares Low (Mem * 5 shares)    à 102.400 mb * 5 = 512.000 shares / 10 vm = 51.200

Formula calculo CPU: [Cluster CPU CORES] * [2000 high | 1000 normal | 500 low]

  • Shares High (100 vCPU * 2000 shares) = 200.000 shares / 90 vm = 2.222
  • Shares Normal (100 vCPU * 1000 shares) = 100.000 shares
  • Shares Low (100 vCPU * 500 shares) ) = 50.000 shares / 10 vm = 5.000

Basándonos en el dibujo tenemos un Resource Pool High con 90 máquinas virtuales y otro RP “low” con 10 máquinas, por lo que producción tiene el 80 % de los shares. Sin embargo, cuando dividimos los estos shares para el resource Pool entre las máquinas que viven el estos Resources Pool, vemos el problema en la imagen.

Las VM del RP “dev/test” tienen más shares disponibles el RP de producción y eso no puede ser así

Como solucionarlo

Si queremos que producción tenga el doble que Test usamos la formula

  • Producción: [90 VMs] * [100 shares] = 9.000 shares de RAM y CPU a poner en el Resource pool
  • Dev/Test: [10 VMs] * [50 shares] = 500 shares de RAM y CPU

Resource Pool con Varias CPU


Ya tenemos establecidas nuestras prioridades, entonces vamos a construir la estructura de Resources pool. La estructura consistirá de 3 ‘Parent Resources pool’ con 2 ‘Child Resource Pool’ cada una, y cuyo nombre tiene el numero de vCPU que tiene cada VM dentro del RP.

Esta la estructura

RP-High (parent) à 4000 shares

  • RP-High-vCPU1 (47 máquinas virtuales)
  • RP-High-vCPU2 (31 máquinas virtuales)

RP-Normal (parent) à 2000 shares

  • RP-Normal-vCPU1
  • RP-Normal-vCPU2

RP-Low (parent) – 100 shares

  • RP-Low-vCPU1
  • RP-Low-vCPU2

Sabiendo que máquinas virtuales con múltiples CPU’s van a requerir más recursos del Hypervisor, es importante calcular los shares acordes a esta circunstancia

Básicamente, dentro del “parent resource pool”, querremos separar nuestras VMs con 1 vCPU y ubicarlas en su correspondiente “child resource pool“, y hacer lo mismo con cada VM que tenga 2 vCPU

Para calcular los shares,

debemos empezar desde la parte inferior y subir. La ecuación se basa en:

  • El número de máquinas virtuales dentro del Pool
  • El valor asignado a la prioridad
  • El número de CPU virtuales que cada máquina mantiene dentro del pool

La fórmula seria: nº VM * valor prioridad * vCPU

Una vez que todos los Child resource pools se han calculado y asignado un share value, cada Child share se suma para darnos el número total de shares a asignar al Parent pool.

Es decir, si la suma de los shares del pool “rp-high-vCPU1 y 2” nos da 30.000 shares, el parent pool “RP-High” tendrá configurado 30. 000 shares

Esta es la ecuacion

Share Count = [# VM in pool × Priority Value shares] × vCPU count 

RP-High = tiene 68 VM divididos en dos RP

  • RP-High-vCPU1 = 47 virtual machines
  • RP-High-vCPU2 = 21 virtual machines

Usando la ecuación y sabiendo que “RP-High-vCPU1 Shares” + “RP-High-vCPU2 Shares” = RP-High Total Shares) nos da

  • RP-High-vCPU1 = [47 VM × 4000 shares] × 1 vCPU = 188.000 Total Shares
  • RP-High-vCPU2 = [21 VM × 4000 shares] × 2 vCPU = 168.000 Total Shares

Por lo tanto, el número de shares del RP-High será 188.000 + 168.000= 365.000 total shares

Nota que, aunque RP-High-vCPU1tiene mas shares (188.000), si divides los 188.000 shares entre el número de VM’s en el resoource pool (188000 /47= 4000) vemos que el valor del share por VM (4000) es más bajo que el valor del share por VM en el pool RP-High-vCPU2 (168.000 / 21 = 8000). Eso es debido a las 2 vCPU

Ahora añadimos estos 2 valores juntos para asignar los shares a nuestro parent pool (RP-High)

RP-High = 356000 total shares

  • RP-High-vCPU1 = 188000 total shares (47 * 4000 *1)
  • RP-High-vCPU2 = 168000 total shares (21.* 4000 * 2)

Be the first to comment

Leave a Reply