Category 2: Practice

Los Resource pools permiten asignar CPU y memoria dinámicamente. El clúster VMware DRS ofrece una herramienta extraordinaria para la gestión de recursos de una forma mucho más centralizada.

El uso de resource pools, límites, reservas y shares es considerado por VMware una mejor práctica para garantizar el uso de los recursos que las máquinas virtuales requieren. Asimismo, es muy recomendable garantizar a cada usuario los permisos necesarios, y no más de los necesarios, para que puedan cumplir con su obligación, que no es otra que la administración del entorno virtual.

¿Qué es un Resource Pool con memoria reservada?

Un resource pool es una abstracción lógica (contenedor) el cual permite asignar recursos de CPU y memoria de forma más dinámica y eficiente. Por tanto, los recursos de un servidor ESXi o un clúster DRS pueden ser divididos y asignados más eficientemente.

Los beneficios de un resource pool son los siguientes: 1. Facilidad de delegación y control de acceso.

Los resource pools pueden ser creados a nivel de servidor ESXi o clúster VMware DRS, pudiendo ser editados y modificados dinámicamente.

El indicador amarillo durante el ajuste de los recursos en un resource pool, muestra la cantidad recomendada para ese recurso.

El memory overhead de las máquinas virtuales también consume memoria en el resource pool y, por lo tanto, esta memoria es incluida en la reserva del resource pool. Aunque VMware recomienda el uso y las buenas prácticas dentro de los resource pool, no es aconsejable crear una jerarquía de más de tres resource pools. La profundidad máxima de esta jerarquía en los resource pools es de 8. Esto crearía un nivel de “burocracia” excesivo en cuanto al control de acceso se refiere.

Aviso: El número máximo de resource pools por host es de 1.600

Cambiando los recursos desde el Resource Allocation

Puesto que todas las máquinas virtuales acceden directamente a los recursos físicos, estas no sabrán qué hacer cuando todas las máquinas virtuales estén accediendo a los mismos recursos, es decir, cuando haya contención en tu sistema. Por consiguiente, vSphere™ incluye un mecanismo para controlar que máquina virtual accede a que recursos y por cuanto tiempo y prioridad.

Cuando la memoria o la CPU de un servidor ESXi está en overcommitted, es decir, las máquinas virtuales están configuradas con más memoria y ciclos de reloj de CPU de lo que dispone físicamente el servidor ESXi, necesitamos tener un mecanismo para garantizar los accesos.

Limit: Es el valor consumido de ciclos de reloj de CPU o memoria física del servidor ESXi del cual no es posible pasarse.

Reservation: Este valor es definido en Mhz para CPU y MB para memoria RAM y representa un valor que debe estar disponible cuando la máquina virtual se enciende.

Shares: Es un valor que especifica la prioridad relativa o la importancia de acceso de una máquina virtual a un recurso determinado. Los shares compiten entre el límite y la reserva.

Por consiguiente, con estos tres parámetros podemos definir SLAs - de las siglas en inglés Sevice Level Agreement - para todas y cada una de nuestras máquinas virtuales. Los shares, limits y reservation también están disponibles a nivel de resource pool.

Nota que cuando no hay contención entre máquinas virtuales, el cambio de la configuración de los shares no tiene ningún efecto. No obstante, cuando hay contención entre dos máquinas virtuales a nivel de CPU y defines unos shares más altos a una máquina virtual, estarás dando una prioridad más alta a esta máquina virtual sobre la otra.

Es posible cambiar el valor de los shares de CPU y la reserva de memoria desde la pestaña Resource Allocation a nivel de Cluster o a nivel de host ESXi cuando este no está configurado en un clúster.

Asimismo, también es posible modificar en "caliente" la reserva de CPU y el tipo de reserva, Fixed o Expandible.

Cuando una máquina virtual, con la configuración en shares de memoria en custom, es añadida a un resource pool, es posible que recibas un warning que indica que la máquina virtual obtendrá un porcentaje muy alto del total de los shares para la memoria. Cambia la configuración de los shares de custom a high, medium o low para evitar este warning.

Cuando añades un servidor vSphere™ ESXi a un clúster y la opción de DRS no está habilitada, los resource pools que estaban en el servidor vSphere ESX/ESXi son eliminados. Asimismo, si creas un clúster sin la opción de DRS, no podrás crear resource pools a nivel de clúster.

Cambio dinámico de los Resource Pools

Es posible incluir más de una máquina virtual en un mismo resource pool. En este caso, todas las máquinas virtuales del resource pool competirán por los mismos recursos físicos especificados en el resource pool.

En el caso de que el resource pool no haya sido configurado con la opción Explandable Reservation, el rendimiento de las máquinas virtuales puede llegar a verse afectado.

Para incrementar el rendimiento de alguna máquina crítica que este dentro de dicho resource pool, puedes aumentar el límite de CPU del mismo. Los resource pools que están en un mismo nivel son llamados Sibling Pools.

¿Qué tamaño deberían tener mis LUNs de almacenamiento?

VMware tiene dos métodos bien diferenciados a la hora de configurar el tamaño correcto para las LUNs de almacenamiento. El método predictivo o el método adaptivo.

El método adaptivo utiliza menos LUNs pero LUNs más grandes mientras que el método predictivo, utiliza varias LUNs con diferentes tipos de RAID para adaptarse mejor a las características de E/S de las diferentes aplicaciones.

Una buena práctica a la hora de configurar las LUNs, es crear LUNs de unos 800GB de tamaño y añadir entre 15-20 máquinas virtuales comprobando el rendimiento.

Pero puede ser que cuando vas a añadir la máquina virtual número 5 se crea un cuello de botella a nivel de LUN. Por eso es muy importante que antes de añadir una nueva máquina virtual a una LUN, monitorices a nivel de E/S el delay de dicha LUN. Si el rendimiento aun es óptimo, mete otra máquina virtual y vuelve a monitorizar el rendimiento. Si el rendimiento sigue siendo bueno, sigue metiendo más máquinas virtuales.

Cuando detectes que el rendimiento no es bueno, y antes de que se genere un cuello de botella en tu LUN, crea otro datastore y empieza a meter nuevas máquinas virtuales en tu nueva LUN y vuelve a empezar con el proceso descrito.