Client (08): Resource Pool

Un resource Pool (necesita habilitarse DRS) es una abstracción lógica que nos permite gestionar los recursos de un host/cluster. DRS está disponible en vSphere Enterprise y Enterprise Plus

  • Los Resource Pool se pueden agrupar en jerarquías y usar para particionar los recursos de CPU y memoria disponibles, es decir, permite al administrado dividir y asignar recursos a máquinas virtuales y otros resources pool
  • Un Resource Pool (RP) puede contener “Childs RP”, máquinas virtuales o ambos.
  • Los RP en el nivel más alto se les llama “Parent Resource Pool
  • Los RP y máquinas virtuales que están en el mismo nivel se les llama “Siblings” y en caso de contención, compiten por los recursos (shares) solo los objetos de su mismo nivel

Las VM/ RP que están al mismo nivel, competirán a la vez por los recursos basándose en los shares, y a partir de ahí hacia abajo. Esto significa que RP1 y RP2 son los primeros para competir por los recursos y luego las VM de cada RP1 competirán por los recursos de su respectivo Resource Pool


Se puede crear una configuración jerárquica de resource pools, por ejemplo, dividirlo por empresas o por recursos a asignar a las VM

  • Un RP tendrá los límites que tenga el padre

 

Para que usar Resource Pools

  • Se puede utilizar para garantizar (reservations) o limitar (limit) los recursos a las VM
  • Vender recursos fuera y dentro de una organización
  • Isolation: Si queremos test/dev/Prod podemos usar los RP para garantizar / limitar recursos
  • Si queremos priorizar Resource pool usando shares, la cantidad de VM es muy importante para la configuración de shares (shares= numer VM * Ratio deseado).

 

Por cada Resource Pool podemos especificar “reservations“, “shares” y “limits” y si la “reservation” debe ser expandida a su “Parent RP“. Una vez creado un RP, sus recursos estarán disponibles a las VMo child resource pool

Resource Pool nos proporciona un mejor control de los recursos del Cluster usando Limits, shares y Reservations sobre el uso de CPU y RAM


 

Limites, reservation y shares en un resource Pool

Al igual que en las VM, podemos configurar limites, reservation y shares en un Resource pool. Esos recursos son los que disfrutaran las VM/RP que estén dentro del RP

Shares:

Nos proporciona la importancia relativa del objeto respecto de otros objetos de su mismo nivel (sibling). Si una VM tiene el triple de shares que otra VM que este en su mismo nivel, disfrutara del triple de los recursos, en caso de contención de recursos. Sin contención, los shares no se aplican


Por defecto asigna estas cantidades


Es importante saber que si colgando de un RP (por ejemplo, el Parent Cluster) tenemos un “child RP” y 3 VM en el mismo nivel (sibling) entre todos se reparten los recursos.

Vemos en la imagen como RP1 y las 3 VM (1) cuelgan al mismo nivel, tienen el mismo share (4000), por lo que tendrá cada objeto un acceso del 25 % a los recursos en caso de contención

Ahora las VM que cuelgan en el RP1, en el nivel 2, solo tienen acceso al 25% total del cluster (el de su RP), por lo que cada una de ellas tendrá solo realmente el 8,3% de acceso total a los recursos del cluster (ya que tienen el mismo share)


Limits

Los limites especifica el uso máximo de un recurso, y aunque tenga la reservation expandible y pueda coger más recursos de su paren RP, si tenemos marcado un límite, de ahí no podrá pasar la VM o RP.

Un ESX puede asignar más memoria que la reservation (si esta expandible) pero nunca asignar más del límite, incluso si no se están usando los recursos

Vemos que el RP “desarrollo” tiene una reserva de CPU de 3000 Mhz (3 Ghz), tiene habilitado la reservation “expandable“, lo que implica podría pedir recursos a su “parent RP” hasta 11865 mhz, pero como le hemos puesto un límite de 6000 Mhz, de ahí no podrá pasar


Aquí se refleja como lo máximo que podrá tener son 6000 MHZ (3000 de configured Reservation y otros 3000 cogidos de su parent)


 

Si arranco la VM Test04, que tiene reservado 800 Mhz, se los quita de “available reservation” y los 800 Mhz aparecen en “used reservation”



Cuando calculemos el Limite en un RP, tomar en cuenta la reservation y memory overhead


Reservations:

Las reservations garantizan un mínimo de recursos. Por ejemplo, si tenemos 4 VM que pertenecen a un RP con 4 Gb RAM configuradas como reservations, el resource pool garantiza que esos 4 GB los podrán usar las 4 VM.

Esto significa que si VM1 usa solo 0.5 GB, VM2 y VM3 usan 1 GB cada una, la VM4 podría usar 1.5GB

Ejemplo:

En esta imagen tenemos un cluster que proporciona 200 Gb de RAM, con una ratio de 4:1 hablando de shares (irrelevante pasa reste ejemplo). Si configuramos una reservation de 40 GB en RP2, son para él y nadie más, dejando el resto de memoria accesible basándose en shares si hubiese contención


Como vemos si en un RP tengo configurada una reservation de 12 Gb, para por ejemplo 4 VM que cuelgan de ella, y la VM1 tiene una reservation de 3 GB, quedaran disponibles 9 Gb para las máquinas virtuales (las 4) y en caso de contención entrara en lugar los shares

Esta es una solución estática para garantizar que una VM de un RP no se quedara sin memoria en caso de contención de recursos, esa porción es para ella y nada más.


Expandable Reservation:

Toma prestados recursos de sus resources Pool padres en el caso de que no tenga recursos suficientes para dar a sus objetos. El límite de lo que puede coger de sus Parents lo marca la pestaña Limit.


En este caso tiene reservado 3000 Mhz y como es expandible puede pedir a su parent pero no más de 8000 mhz


 

 

Ejemplo como funciona las reservations

Por ejemplo, si tenemos un RP “Produccion” con una reservation de 3000 Mhz, y expandible (lo cual puede coger recursos del parent root cluster)

01.-
Vemos que los recursos máximos de este RP aunque ponga ilimitado, su máximo es 11865, que es los recursos máximos que tiene el cluster disponible (se hubiera cientos de VM arrancadas consumiendo recursos, o VM con reservas, este límite bajaría


NOTA: aquí vemos el límite del cluster (11,87 ghz) que es el Max Limit de la imagen anterior



 

02.-
dentro del Resource Pool hay 4 VM con una CPU reservada cada una de 800 Mhz, Observamos que en el RP tenemos 3 Ghz reservados (configured reservation) y que no se ha usado la reserva, porque aún no hemos arrancado ninguna VM




 

03.-
Arrancamos 3 VM que están dentro del RP, y tendremos un total de 2400 Mhz usándose (3 * 800Mhz) , por lo que sin problemas ya que tiene el RP reservado 3000 Mhz.

Nos descuenta los 2400 Mhz (lo pone en “used reservation”), por lo que en teroria al RP solo le quedarían 600 Mhz libres para dar (available reservation), pero como tenemos los recursos del RP respecto a la CPU como “reservation espandable” le quedan 9465 Mhz (available reservation), es decir, todo lo que le queda al cluster



04.-
Si arrancamos la cuarta VM “test04”, en total las VM consumirían 3,2 Ghz de CPU, superando los 3 Ghz configurados en el RP, y como tenemos habilitado la “expandible reservations“, lo que hace es que el RP “producción” busca más recursos en su “parent RP” para satisfacer los 200 Mhz que le falta.

Si no estuviera activado, la cuarta VM no arrancaría



 

05.-
Deshabiltamos la expandible reservation al RP para ver como cambia

Si no tuviera la reservation expandible. La cuarta VM no arrancara


 

 

Aquí lo vemos


Si la intento arrancar, no puede


 

Propiedades de los resource Pool

Reservation: los recursos de CPU reservados para IBM. Mínimo va a tener 3 Ghz de CPU disponibles para las VM que este en este RP

Expandable Reservation: si está activado, y un resource pool ha llegado a su tope de reservation, le permite pedir a su “parent RP” (en nuestro caso un cluster) si tiene recursos disponibles y así hacer uso de ellos.

Si esta desactivado, el límite de este RP lo establece su Reservation.

Si estuviera habilitado, y no queremos que coga todo lo disponible del parent RP, podremos limitar con “Limit”

Limit: El límite que puede pedir al padre a través de la reservation expandible. Si tiene reservado 5000 y tengo la expandible reservation activada (no como en el dibujo) con un límite de 9021, este RP podrá llegar como máximo a 9021 mhz pidiendo prestado 4021 Mhz a su parent en caso de que con los 5000 no tuviera suficiente

 

Relación de las settings Resource pool con Resource Allocation de un Resource Pool

En el entorno grafico podemos ver las reservas de un resource pool e interpretar su relación con las settings del RP

  • CPU

  • Memoria

Con el vsphere client es un poco más exacto

  • Mhz: le reserva 3080 para las VM que contenga este RP, y como esta activada la “Expandable Reservation” en caso de quedarse sin los 3080 Mhz, este RP podrá pedir a su Parent la cantidad marca da en “Limit”, que este caso es ilimitada y vendrá dada por lo recursos de MHz que tenga libre su parent.
  • MB: reservo 1 Gb, y al no poner la memoria expandible, cuando este RP se quede sin ese GB, no podrán pedir más recursos a su paren (el cluster), y la VM no arrancaría,

    Aunque ponga 2000 como límite, ya que este límite solo es válido en caso de activar la Expandable Reservation

 

Pestaña Sumary /Utilization de un resource Pool

Podemos ver een el Web Client la utilización del Resource Pool (summary en client normal)


 

 

El vsphere client seria:


 

Anidacion de Resources pool (como funciona)

01..- Creamos un Resource Pool llamado “PADRE”

  • CPU: que tiene una reserva de 2 GHz y como NO es expandible (fixed) pues ese será el máximo que tendrá. No cogerá del cluster



 

  • Memory: Reservamos 256 Mb y como NO es expandible solo podrá reservar 256, aunque su límite será el que se defina



 

02.- Creamos dos Resource Pool “Hijo1” e “Hijo2” dentro de Padre

  • Hijo_01: Podríamos configurarle una reserva de hasta 2 Ghz o 500 mb RAM (lo de su parent), pero vamos a configurar a nivel de CPU una reserva de 1700 Mhz de CPU y 125 Mb de RAM, por lo que su pool “parent” solo podrá servir a otros pool 300 Mhs y 375 Mb de RAM


 

Automáticamente se ha ajustado los recursos que le quedan el resource Pool


 

  • Hijo_02: vemos que solo tiene disponible lo que le queda por ofrecer a su parent (300 Mhz y 375 RAM)


Así nos queda al final:

  • El Ressorce Pool “Padre” solo le quedan 0,15 Ghz que ofrecer, y como la reservation no es expandable (fixed) no puedo coger de su parente (que seria el cluster)


Con la memoria es igual. Solo le quedan libre 75 MB porque a dado 425 mb a “hijo_01” e “Hijo_02”


  • El Resource Pool “Hijo_01” se configuro con una reserva de 1700 Mhz (1,70 ghz) pero como la “reservation type” es expandable, le permite coger los 150 Mhz (0,15 ghz) que le quedan libre a “Padre”


Con la memoria pasa igual, tiene asignado 125 Mb, pero puede coger 75 mb mas que son los que le quedan libres al “padre”


 

  • El Resource Pool “Hijo_02”: Esta igual, puede coger los 150 Mhz (0,15 ghz) que le quedan libres al parent, y con la memoria igual, podría coger hasta 375 mb, es decir lo 75 Mb que le quedan libre al “padre”. El Resopurce pool Hijo que antes los coga, se quedara con ello y el otro se quedara sin ello



Diseñar bien los Resource Pool

Es común comenter el error de crear un RP de producción, con por ejemplo, 4 veces mas de acceso a los recursos que un RP de desarrollo. El problema viene por que no se ajusta el RP en función del numero de VM que están dentro

Como vemos en el ejemplo tenemos un RP de producción con un share de 8000, y el de desarrollo con 2000, es decir un ratio de 4:1.

Todas las VM que están dentro de los RP tienen los mismos shares.

  • Como vemos las maquinas del RP de desarrollo (naranja) que tiene asigna el 20% de los recursos, como solo tiene 3 VM, cada una recibirá el 6,66 de recursos del cluster (20/3=6,6)
  • sin embargo, el RP de producción (azul) que tiene el 80% de recursos, como tiene 30 VM cada VM recibirá 2,66 recursos del cluster (80/30=2,66)


La solución para esto sería usar

  • Custom Shares en lo Resource Pool basandonos en el numero de VM

    Para calcular el share, multiplicarioamos en nº de VM por el ratio, asi nos dara el share a poner en el RP. Por ejemplo, si queremos asignar este ratio de 4:1, es decir 2000 y 8000 la formula seria

    • Producción: 30 vm * 8000 = 240.000 shares a configurar en el Resource Pool de produccion
    • Desarrollo: 3 vm * 2000= 6.000 shares a configurar en el Resource Pool de desarrollo

    Si dividimos 240.000 shares entre 30 VM, nos dara los 8000 shares que disfrutara cada VM de produccion

  • Script para definir custom shares basandose en la cantidad de VMs/vCPUs en el resource pool
  • Usar resource Pool Reservations
  • Usar resource pool limits

 

Acceso a los recursos en contención de RP anidados (shares)

01..- Tenemos dos Resource pool con 1000 (engineering) y 2000 (finance) de share, lo que significa que un RP tendrá el 33% de recursos y el otro 67 % de los recursos más o menos

02..- Tenemos 2 VM dentro de cada RP, una con 1000 (33%) y la otra 2000 de shares (67%)

  • Como en el RP “engineering” tiene el 33 % CPU física,
    • VM “eng test” tendrá el 33% (share 1000) del 33% de PCPU (engineering pool), es decir, el 11% de CPU total del host    //33 pcpu*33%= 11%
    • La VM “eng-prod” tendrá el 67% (share 2000) del 33% PCPC (finance pool), es decir, el 22% del total CPU del host    //33 pcpu*67%=22%
  • Como el RP “Finance pool” tiene asignado el 67% de CPU física
    • Fin-test-VM: tendrá el 33% (share 1000) del 67% de PCPU, es decir el 22% de total CPU     // (33*67%=22%
    • Fin-Prod: tendrá el 67% (share 2000) del 67% de PCPU, es decir, el 45% de total de la CPU // (67*67%=44%

       


 

 


 

Be the first to comment

Leave a Reply