No os lo perdáis y aprovechar para daros una vuelta por la web de IDG donde hay otros muchos videos como el del también compañero Paulo Díaz que trata sobre como dar el salto a la nube.

https://www.idg.es/cio/video/El-papel-de-la-virtualizaci%C3%B3n-en-la-nube-privada/vid3036-cloud%20computing.htm

https://www.idg.es/cloudprivada/VideoCloudComputing.aspx?id=2983

Un saludo.

Continuando con la serie de artículos que empecé con el articulo sobre como escoger un host equilibrado, los procesadores y la memoria, hoy os hablare del almacenamiento y la idea es cerrar esta serie con un articulo sobre redes.

En un entorno no virtualizado la carga del almacenamiento se distribuye entre la SAN y el almacenamiento local de los servidores, mientras que en un entorno virtualizado lo mas probable es que la SAN absorba prácticamente toda la carga.

Desgraciadamente la virtualización no siempre va acompañada de un análisis adecuado y gracias a la potencia de las tecnologías de hoy en día podemos tener la sensación de que la virtualización es un saco que lo aguanta todo, que no hay que tener cuidado, sin embargo mas tarde o mas temprano tendremos que poner la atención en diferentes elementos de nuestra plataforma si es que quieres que esta pueda seguir asumiendo carga y mantener el rendimiento dentro de unos parámetros aceptables.

La verdad es que con mucho considero el almacenamiento el aspecto mas complicado de la virtualización, la cantidad de elementos que intervienen es amplísima empezando por las cabinas en constante evolución gracias a un mercado súper-competitivo en el que como dice mi compañero David Cervigón cuyo conocimiento sobre estos temas es mas que envidiable “en el almacenamiento todo esta por hacer”.

En cuanto al almacenamiento en la virtualización existen dos corrientes de pensamiento básicas:

1) Estandarizar una configuración determinada, llenarla mientras aguante, escalar cuando sea necesario para mantener un rendimiento aceptable

Contras:

-Hay cargas que es complicado virtualizar de esta forma, especialmente las que hagan uso intensivo de disco.

-Las implicaciones terminan apareciendo desde el punto de vista de backups/recuperaciones, rendimiento no predecible, etc.

-Para mitigar en cierta forma el problema se puede terminar moviendo frecuentemente los discos de las VMs lo que al final es menos eficiente que pensar en ello desde el principio

-A medio o largo plazo se termina teniendo que replantearse el almacenamiento o comprar sistemas mas potentes que nos den margen durante mas tiempo

PROS:

-Es un sistema simple y rápido a primera vista

-Puede funcionar sin problemas en muchos entornos cuyas infraestructuras de almacenamiento están sobredimensionadas.

2) Estandarizar las configuraciones apropiadas para obtener desde el principio un rendimiento predecible y optimizado, lo que requiere conocer y analizar diferentes aspectos del almacenamiento

Contras:

-Requiere algo mas de tiempo y conocimientos para el análisis

-Puede suponer un mayor numero de volúmenes y espacio consumido al principio de los proyectos

PROS:

-Una vez realizado el trabajo inicial es fácil de mantener

-Evita problemas con el tiempo siendo una arquitectura predecible

-El rendimiento general es mejor y sostenible

Si me preguntarais por mi opinión personal os diría que en general soy partidario de la segunda opción,.

Dado que este tema es difícil de entender solo escuchando una sesión técnica cosa que hago muy a menudo, he decido escribir este post de forma que pueda servirme de apoyo al explicarlo y esperando que os sea de utilidad a todos los que terminéis aquí por alguna razón.

Aviso: Cada cabina es un mundo y el numero de combinaciones entre discos, arquitecturas, conectividad y parametrización es infinita así que todas las cifras que muestro en este articulo son para los sistemas específicos en los que he realizado las pruebas o de aquellos cuya información he visto reflejada en diferentes pruebas realizadas por Microsoft o los fabricantes, cada entorno insisto tendrá sus propias cifras. En este articulo hablaremos también de como averiguar las cifras actuales de tu entorno y como realizar mediciones del impacto de los cambios que hagas.

Que vamos a ver en este articulo:

• Conceptos generales sobre almacenamiento
  • Patrones de uso
  • El tipo de interface de disco
  • El Disco
  • Las LUNs y las cabinas
  • El RAID y el tamaño de banda
  • Formateando nuestros discos (GPT vs MBR, el “unit allocation size”)
  • Evitando problemas de alineamiento
  • Conoce tu hardware
  • Aprende a probar el rendimiento del almacenamiento
• El almacenamiento en Hyper-V
  • Haciendo las cosas bien: la importancia del análisis
  • De físico a virtual
  • Encriptación y compresión
  • Arranque desde SAN
  • ¿Que dispositivos de almacenamiento puedo usar con Hyper-V?
  • MPIO
  • Usando iSCSI
  • Tipos de discos en las maquinas virtuales
  • Todo lo que tienes que saber sobre CSV y otros tipos de discos en los hosts
  • Diseñar los discos duros virtuales de las VM
  • Los limites de Hyper-V para hosts y VMs
  • ¿Necesitas aun mas rendimiento?

Conceptos generales sobre el almacenamiento

Para que podáis sacar el mayor partido del articulo tengo que asegurarme de que conocéis algunos conceptos fundamentales del almacenamiento que muchas veces son pasados por alto, conocerlos os será igual de útil en entornos físicos que virtuales incluso con diferentes fabricantes de virtualización.

Patrones de uso

Dentro de un servidor existen a parte del sistema operativo aquellos servicios responsabilidad del servidor.

Cada uno de estos servicios hace un uso diferente del disco duro, de esta forma no es lo mismo el uso de un disco duro de un servidor de base de datos de un ERP que de un servidor de ficheros.

En base a estos diferentes tipos de uso podemos hablar de unos patrones que están formados por los siguientes elementos:

Escritura/lectura: Por ejemplo un servidor de ficheros suele ser un 80% lectura contra un 20% escritura, mientras que un servidor web generalmente será un 100% lectura.

Secuencial/aleatorio: Un servidor de streaming de video será 100% secuencial y normalmente todos los servidores que muevan grandes volúmenes de datos en bloque tenderán a ser secuenciales y los datos se leerán o escribirán de seguido, por ejemplo una base de datos será en muchas ocasiones aleatoria pues los datos estarán muy dispersos.

Tamaño de la operación: Por ejemplo muchas veces un sistema determinado como por ejemplo Exchange o SQL Server suelen siempre leer del disco bloques del mismo tamaño por ejemplo dependiendo del producto 8KB,32KB o 64KB, mientras que un servidor de ficheros solicitara bloques de muy diferentes tamaños donde a lo mejor las solicitudes de bloques de 64KB suponen el 10% de las operaciones y las de 16KB el 4% y así.

A cada operación de lectura o escritura a realizar la llamamos IO, las IO por segundo serán las IOPS.

En este articulo vamos a ver muchos parámetros que afectan al rendimiento del almacenamiento el primer paso para tomar buenas decisiones es entender el patrón de uso de tus servidores lo que puedes empezar haciendo con el performance monitor y tantas otras herramientas.

La siguiente tabla muestra ejemplos de algunos patrones estándar:

El tipo de interface

Es cierto que iSCSI esta creciendo mucho y creo que todos estamos muy contentos con iSCSI, solo tengo que decir que cuando vayamos a utilizar iSCSI tenemos que hacerlo de forma adecuada aislando y dimensionando adecuadamente las redes de iSCSI, utilizando Jumbo frames y otras optimizaciones que nos harán sacar el máximo partido de esta tecnología que nos aporta tanta flexibilidad.

Es muy común encontrarnos con fibra óptica (FC) que también es estupenda.

Para vuestro conocimiento aquí tenéis una tabla con el rendimiento teórico de diferentes tipos de arquitectura de almacenamiento.

Hoy en día empezamos también a ver interfaces de 10 Gigabit que usados para iSCSI o FCOE pueden dar rendimientos fantásticos como veis en el siguiente grafico:

El disco

Muchas SAN nos permiten elegir diferentes tipos de discos y luego poder crear diferentes grupos de discos con ellos.

Las ultimas cabinas de algunos fabricantes incluso son capaces de juntar en el mismo grupo diferentes tipos de discos y mover los bloques de datos a aquellos discos donde mejor estén, teniendo en cuenta la frecuencia de uso y patrón del mismo.

A la hora de escoger los discos estaremos impactando dos cosas principalmente; coste y rendimiento.

Un aspecto determinante a la hora de escoger el disco son las revoluciones del mismo (RPM), las velocidades mas comunes en entorno de servidores son 7200, 10000 y 15000RPM.

Las revoluciones tienen además otras connotaciones en los discos como podéis ver en las siguientes imágenes, esto implica por tanto que no solo los discos giran mas rápido sino que los platos son mas pequeños y las agujas se tienen que desplazar menos.

El siguiente grafico muestra el numero de operaciones en disco aleatorias de 8K que he obtenido en diferentes discos según sus revoluciones (en este grafico mas es mejor).

Si a alguno os intriga cuantas IOPS tiene un disco de estado solido (SSD) podríamos decir que hay quien las sitúa entorno a las 6000!!

El siguiente grafico os muestra la diferencia entre discos de 15K RPM y 10K RPM de tipo SCSI en el escenario concreto de lecturas secuenciales de bloques de 8K, añado también un disco SATA de 10K para que veáis también el impacto que tiene SATA vs SCSI. (En este grafico mayor latencia es peor mientras que mas lecturas por segundo es mejor).

Esto no significa que todos los discos tengan que ser de 15K por que son mejores, simplemente que debemos entender la diferencia y en ocasiones elegir que conviene mas.

Las LUNs y las cabinas

Una LUN (Logical Unit Number) es un disco virtual proporcionado por la SAN y que presentamos a uno o mas hosts.

Fijaros que digo “virtual” esto es así porque la LUN no tiene por que representar un disco físico conectado a la cabina, normalmente todas las cabinas reúnen grandes grupos de discos físicos incluso de diferente configuración y sobre estos generan estas unidades repartiendo los bloques que las componen entre los diferentes discos físicos, de esta forma se obtiene mejor rendimiento.

Algunas SAN aportan funcionalidades adicionales, como crear las LUN usando un modo que se llama “thin”, lo que hace que la unidad vaya ocupando espacio en la SAN a medida que se vaya usando, este tipo de LUNs están creciendo en popularidad, sin embargo os tengo que decir que dependiendo de la cabina esto puede suponer una pequeña penalización y os sugiero que establezcáis un baseline comparando el rendimiento de la misma carga con una LUN “thin” y otra normal de forma que conozcáis el impacto exacto en vuestro entorno a la hora de tomar vuestras decisiones.

Otra funcionalidad de algunas SAN muy interesante es la llamada deduplicación con la cual la SAN ahorra el espacio de los bloques que se encuentren almacenados en la SAN mas de una vez, como esto se realiza a nivel de bloque los ahorros pueden ser muy importantes ya que por ejemplo en un entorno VDI la mayor parte de los discos duros virtuales puede ser prácticamente igual. Una vez mas con esta funcionalidad recomiendo hablar con el fabricante para entender las buenas practicas que recomiende y tener especial cuidado con el impacto que esto tiene en la CPU y resto de recursos de nuestra cabina.

A medida que aumentamos discos en un grupo de discos de las SAN también aumentamos el numero de operaciones de entrada y salida (IOPS) que nos da la cabina.

El siguiente grafico muestra los datos para un fabricante determinado.

Las cabinas también avanzan a un ritmo tremendo así con cada versión y modelo los fabricantes añaden mas cache, mejores firmwares y elementos que aumentan el rendimiento, por eso elegir la cabina y comparar varias tiene mucha importancia.

El siguiente grafico muestra la diferencia entre dos cabinas del mismo fabricante pero de diferente gama, con discos con las mismas RPM e igual numero de discos (240)

El RAID

Otra aspecto a comentar es el nivel de RAID, como sabéis RAID tiene diferentes niveles, 0,1,2,3,4,5,6,5E, 6E, 0+1, 1+0, 30, 100, 50 y un buen numero mas de combinaciones y especificaciones propietarias, siendo los mas comunes de encontrar los raid 1 y 5 y limitando cada cabina que RAIDs puedes configurar.

RAID 1: Los datos se escriben en dos discos, generalmente mejora lecturas dado que puedes leer de dos sitios pero degrada la escritura por la misma razón aunque el rendimiento de escrituras pequeñas es muy bueno.

Dado que por cada disco perdemos otro es un RAID muy caro

RAID 5: Buen rendimiento en lecturas pero malo en pequeñas escrituras, es mas barato por que pierdes menos discos que con RAID 1, en caso de fallo de un disco todo el rendimiento se ve afectado.

Fijaros en que puntualizo el aspecto de escrituras pequeñas dado que tiene mucha importancia de forma especial en discos que por ejemplo dediquéis a logs, en general las escrituras se ven perjudicadas por el RAID, el siguiente grafico muestra la penalización en discos de 15K RPM:

Los RAID tienen repercusiones tanto a nivel de tolerancia a fallos permitiendo al sistema sobrevivir a la perdida de algún disco que componga el RAID como a nivel de rendimiento, cada nivel tiene ventajas y desventajas, unos favorecen las lecturas otros las escrituras, unos las cargas secuenciales y otros las aleatorias incluso se puede hablar de impacto en CPU o diferencias según la cantidad de datos que se quieran mover en las operaciones.

Muchas cabinas implementan siempre cierto nivel de RAID a bajo nivel y normalmente esto no se puede elegir, por otra parte algunas cabinas ya no dejan elegir el nivel de RAID individual para las LUN, deciros que ese uso de cierto nivel de RAID a bajo nivel en muchas cabinas no esta reñido con que la LUN tenga además un nivel de RAID adicional.

Es cierto que las caches de las controladoras puede alterar estos rendimientos. En cualquier caso debéis hacer vuestras propias mediciones para entender las diferencias entre RAIDs que os da vuestra SAN.

Aunque todo es discutible, por norma general podríamos decir que RAID 1 es adecuado para los discos de sistema operativo y logs transaccionales mientras que RAID 5 o RAID 10 es mejor para discos de datos.

Hay mil recursos en internet para aquellos que tengáis dudas sobre RAID, yo de momento solo quiero que os quedéis con las diferencias de rendimiento entre cada uno.

Tamaño de banda

Cuando generas un RAID podríamos decir que los discos se parten en bandas o franjas, estas franjas tienen un tamaño y aunque no todas las cabinas permiten especificarlo este parámetro también tiene impacto en el rendimiento.

El siguiente grafico os muestra el impacto en el rendimiento del tamaño de franja con tres opciones de tamaño teniendo como base la prueba las lecturas aleatorias de bloques de 8K.

Como veis configurar apropiadamente el tamaño de franja nos proporciona un potencial beneficio en rendimiento nada desdeñable.

La gran pregunta es ¿como decido el tamaño de franja adecuado?, pues bien como con todo lo que tiene que ver con almacenamiento no hay una respuesta única.

Para tomar una decisión tendremos que entender esos patrones de uso de los que hablábamos al principio del articulo y buscar si los fabricantes de los sistemas que vayan a utilizar los discos nos han hecho alguna recomendación especifica, por ejemplo en el caso de Exchange 2010 el tamaño recomendado es de 256.

Un tamaño de banda pequeño suele favorecer la transferencia mientras que uno grande favorece que se puedan realizar múltiples operaciones en paralelo a lo largo de varios discos en la misma franja lo que beneficia a las bases de datos.

El tamaño de la banda tiene también un efecto multiplicador de IOPS una única IO que al llegar a la controladora de la cabina tenga que responderse con datos que estén en mas de una banda se convertirá en varias IOs vistas desde la SAN.

Las cabinas establecen normalmente un valor optimizado de forma general por el fabricante muchos clientes no se preocupan del tamaño de la franja hasta que no tienen que superar un problema de rendimiento, es algo a vuestra elección.

Formateando nuestros discos (GPT vs MBR y unit allocation size)

Cuando vamos a formatear un disco duro se nos pregunta si queremos hacerlo con un esquema de particionamiento GPT o con MBR.

MBR es él esquema estándar de toda la vida, nos permite 4 particiones primarias por volumen y un tamaño máximo de 2TB.

GPT podríamos decir que permite un tamaño casi ilimitado, pero que Windows limita a 256TB por partición con un máximo de 128 particiones.

GPT también añade algunas funcionalidades y otras restricciones (mas detalles en: https://msdn.microsoft.com/en-us/windows/hardware/gg463524 )

Yo por defecto aunque GPT tiene algunas ventajas os recomiendo usar MBR siempre salvo que necesitéis mas de 2TB y en ese caso mirar que no tengáis ninguna peculiaridad en los requisitos de vuestra configuración que os pueda dar algún problema.

El “unit allocation size” , cluster size o tamaño de bloque es otro de los parámetros que se nos pide a la hora de formatear un disco.

Este parámetro representa la menor cantidad de espacio en disco que un fichero puede consumir de forma contigua, el valor por defecto es 4096 bytes, por lo tanto cada vez que se accede al disco se producen tantas operaciones como bloques de este tamaño se tengan que leer para completar el volumen de datos pedidos.

Por ejemplo imaginar una carga como SQL Server donde podemos leer bloques de 64KB (65.536 bytes) si nuestra configuración de bloque es la configuración por defecto 4096 bytes, el sistema tendrá que usar muchas operaciones de 4096 bytes para completar los 64KB sin embargo si tuviéramos un tamaño de bloque de 64KB seria una sola operación.

Puedes saber el tamaño de bloque de un disco con el comando “fsinfo”

Modificar el tamaño de bloque según el patrón de uso puede tener un impacto que a veces no podemos dejar pasar por alto, el siguiente grafico os muestra como afecta el tamaño de bloque a la cantidad de MB por segundo que puede mover un servidor:

Por cierto como es lógico un tamaño de bloque muy grande repercute en menos espacio libre en disco.

Evitando problemas de alineamiento

Hasta ahora habéis visto en este articulo muchos parámetros relativos al almacenamiento, creo que todos los básicos al menos.

Ahora nos falta el que mas impacto puede tener y que se ve afectado por varios de los vistos hasta ahora, este otro aspecto es el que denominamos alineamiento.

Tratare de simplificar tanto como pueda al explicaros el problema de alineación.

Como hemos visto el sistema trata de escribir y leer en bloques de un tamaño ajustando este tamaño a las cargas reducimos las operaciones de disco necesarias para leer o escribir el volumen de datos que sea necesario, el asunto es que estos bloques de información son escritos físicamente en los bloques del disco (sectores) que aunque ya no siempre es así son de 512 bytes, si ambos elementos no están alineados, la lectura de un bloque en vez de producir una IO producirá varias a nivel físico.

Para alinear un disco es necesario que coincida el primer bloque con el comienzo de un sector, para conseguir esto se establece un “offset” o desplazamiento que es un espacio perdido (y algunas otras cosas) a partir del cual se empieza a escribir y que vale para alinear el disco.

Una correcta alineación de los discos puede suponer hasta un 30% de aumento de rendimiento.

Este articulo trata en el fondo de Hyper-V que siempre corre sobre Windows Server 2008 o superior, en Windows Server 2008 por defecto se emplea una alineación de 1024K.

Algunos sistemas podrían funcionar mejor con otros offsets, para averiguar si es tu caso consulta primero la información del fabricante de la cabina por si hace alguna recomendación.

Para saber cual es el offset de una unidad puedes usar WMI ( https://support.microsoft.com/kb/929491 )

Conoce tu hardware

Cabinas y controladoras tienen muchas veces parámetros que pueden mejorar sustancialmente el rendimiento.

Por ejemplo muchas controladoras incorporan caches que están configurados por defecto para un patrón de uso estándar, modificar este parámetro para adaptarlo al uso que preveas, puede traerte mejoras de rendimiento muy apreciables.

Aprende a probar el rendimiento de tus configuraciones de almacenamiento

La mejor forma de alcanzar las mejores combinaciones de parámetros es ser capaz de medir el rendimiento con cada combinación que quieras probar.

Una manera de hacerlo es con la herramienta IOMeter: https://sourceforge.net/projects/iometer/

Hay herramientas especificas para cargas como Exchange (Jet Stress) o SQL Server (SQL IO) que te permiten simular la presión de IO exacta de tus requisitos para estas cargas.

Es un proceso laborioso, si quieres sacarle partido resérvate el tiempo adecuado y prepárate una buena hoja de calculo para ir apuntando los resultados y las conclusiones de cada prueba

El almacenamiento en Hyper-V

Lo primero felicitarse si has llegado hasta aquí ahora si me he explicado adecuadamente tienes en la cabeza los conceptos que necesitas para entender el rendimiento del almacenamiento y por tanto podemos hablar ya de las peculiaridades de la virtualización con respecto a el.

Haciendo las cosas bien: La importancia del análisis

Has visto como para cada patrón de uso hay unos parámetros que benefician su rendimiento y otros que lo perjudican.

La virtualización ha venido de la mano de la estandarización en la parametrización del almacenamiento, mientras que hace años a la hora de poner un servidor de bases de datos en una gran empresa un DBA cualificado junto con un técnico de almacenamiento especializado en el fabricante de la cabina analizaban los mejores parámetros y se definían las LUNs adecuadas, RAIDs, tamaños de cluster, bandas, etc, etc. ahora generamos grandes LUNs en las cabinas todas con los mismos parámetros y colocamos encima decenas de discos duros virtuales.

Las cabinas son cada vez mas rápidas, los discos mejores, todo con mas cache y en general las cargas no tienen por que ser tan exigentes a nivel de IO, sin embargo cuando nos aproximamos a la capacidad en IOPS de la SAN, ponemos cada vez mas VMs o virtualizamos cargas importantes a nivel de IOPS nos podemos encontrar con problemas de rendimiento y entonces empiezan a surgir todas estas cosas de las que estamos hablando. ¿no es mejor hacerlo bien desde el principio?, es mas complicado pero también mas profesional y efectivo a medio y largo plazo.

Si hemos visto que para cada patrón de uso hay unas configuraciones mas optimizadas y convenientes, al hablar de virtualización la mejor configuración será aquella en la que la configuración de los volúmenes de los hosts venga dada por los patrones de uso de los discos duros virtuales que pongamos sobre ellos.

De físico a virtual, la importancia del almacenamiento

Es común convertir servidores de físicos a virtuales (P2V) y es curioso como al hacerlo nos olvidamos en muchas ocasiones de que estamos virtualizando servidores con varios discos con configuraciones que fueron optimizadas para la carga especifica del servidor.

Debemos de tener en cuenta estas configuraciones ya sea para reproducirlas al virtualizar o para obviarlas tendrás sus repercusiones

Si escogemos obviarlas y poner por ejemplo todo sobre la misma LUN, debemos asumir la posible perdida de rendimiento que habrá que sumar a la perdida de rendimiento que posiblemente obtendremos por virtualizar.

Encriptación y compresión de discos y Hyper-V

Los discos duros en el host sobre los que pongas los discos virtuales pueden ser encriptados con Bitlocker por supuesto perderas algo de rendimiento pero puede haber entornos en lo que no haya opción.

EFS esta soportado dentro de las VMs pero no en el host.

No se debe de ninguna forma usar compresión de discos en volúmenes usados para almacenar discos duros virtuales.

Arranque desde SAN

En ocasiones se decide que los host no tengan discos duros locales o que estos no sean usados para albergar el sistema operativo de los servidores, esto se consigue haciendo que el host arranque directamente desde la SAN.

Esta decisión normalmente se toma para salvaguardar el sistema operativo y sus configuraciones en la SAN o incluso para replicar esta configuración a otro CPD, hay que decir que esta configuración esta soportada para el host con iSCSI y FC.

Como opinión personal decir que estas configuraciones tienen sus requisitos y complejidad y que en general encuentro que Hyper-V no se beneficia de este sistema debido a que el host es un elemento altamente prescindible que incluso pude arrancar de VHD.

En cuanto a los ahorros de coste por arranque en SAN es algo que podríamos discutir también durante mucho tiempo especialmente por los requerimientos y el coste de cada elemento además de la complejidad añadida.

También es posible hacer que las VM arranquen desde SAN a través de iSCSI y PXE usando una tarjeta de red legacy y soluciones especificas de terceras partes como emBoot o Doubletake.

¿Que dispositivos de almacenamiento puedo usar con Hyper-V?

Cualquier hardware valido para Windows Server 2008 R2 es valido para Hyper-V R2 no hay un proceso especifico para Hyper-V debido a su arquitectura con lo cual te beneficias de poder usar una enorme cantidad de hardware, ¿quien saca un dispositivo de almacenamiento que no funcione con Windows Server?, no es algo muy comun…

MPIO

MPIO como sabéis os permite acceder por varios caminos al almacenamiento lo que aporta tolerancia a fallos y en algunos casos además mejoras en el rendimiento.

Se puede usar MPIO sin problemas en Hyper-V de hecho usarlo es nuestra recomendación, estudia las guías de configuración de tu fabricante para Windows server 2008 o 2008 R2 y sigue sus instrucciones.

Cuando uses iSCSI a través de tarjetas de red estándar no caigas en el error de configurar un teaming para tener MPIO en el acceso iSCSI, debes usar MPIO exactamente igual.

Haz pruebas con las diferentes configuraciones de MPIO (LB, HA, etc) entender como afectan al rendimiento y la alta disponibilidad en tu entorno te hará tomar las mejores decisiones.

El siguiente grafico te muestra como con ciertas configuraciones de MPIO se ganan IOPS al añadir caminos.

Usando iSCSI

Cuando vayas a usar iSCSI sigue las siguientes buenas practicas:

• Monta una red separada
• Usa Jumbo frames y usa el tamaño de paquete a 9K como ves en la siguiente captura, reducirás la sobrecarga de usar jumbo frames hasta en un 84%
  • En R2 los virtual switchs de Hyper-V soportan Jumbo Frames y las tarjetas de red virtuales también, eso si tienes que instalar los IC en las VM.
  • Jumbo frames tiene que estar configurado en todos los elementos de la red por los que pase el paquete; tarjetas de red virtuales, virtual switchs, puntos de red, switchs fisicos, etc.
    • Puedes probarlo con “ping –n 1 –l 8000 –f [otra IP dentro de la red iSCSI]”
• Dedica tarjetas de red específicamente a iSCSI
• Salvo en el caso de un guest cluster presenta siempre el almacenamiento iSCSI a los hosts y luego úsalo en las VMs como requieras con un VHD o directamente con passthrough (lo explico mas adelante)

Tipos de discos en las maquinas virtuales

A la hora de crear los discos duros de una maquina virtual tenemos que tomar varias decisiones, la primera es si crear el disco dentro de una controladora de disco virtual IDE o virtual SCSI, obviamente esto no tiene nada que ver con que por debajo el almacenamiento sea SCSI.

El disco de arranque de la VM siempre tiene que ser IDE, si conviertes una VM de VMWare que arranque desde SCSI SCVMM convertirá automáticamente todo para que funcione sobre IDE.

A partir de ese primer disco de arranque mi recomendación es que siempre crees una controladora virtual SCSI como mínimo en cada VM y el resto de discos los montes sobre esta controladora.

Si tienes una VM que requiere el máximo de rendimiento y tiene varios discos, puedes poner varias controladoras SCSI en la VM y balancear los discos entre ellas.

Con IC instalados en la VM el rendimiento de los discos es igual sean IDE o SCSI pero en las controladoras SCSI puedes añadir discos en caliente.

SCSI virtual requiere de los integration components y esta soportado en:

• Windows XP Prof x64
• Windows Server 2003, 2008 y 2008R2
• Windows Vista y Windows 7
• Suse Linux

Si una VM tiene muchos discos distribúyelos entre varias controladoras virtuales SCSI para un mejor rendimiento.

Los discos de una maquina virtual pueden ser de diferentes tipos y las maquinas virtuales estén o no estén en clúster pueden tener discos de diferentes tipos;

-VHD Fijos:

-Al crearlos reservan en el disco duro del host/cluster en el que se encuentren tanto espacio como configures

-En R2 el tiempo necesario para crear un disco VHD fijo se ha reducido mucho con respecto a la primera versión de Hyper-V

-Dan un muy buen rendimiento que puede llegar a suponer entre el 90 y 96% del rendimiento que experimentarías en físico con cualquier tipo de carga

-VHD Dinámicos:

-Crecen en bloques de 2MB por defecto a medida que se van usando, cada vez que crece llena de ceros el bloque produciendo tanto el crecimiento como esta operación una serie de IOPS que pondrán en cola otras IOPS

-En RTM crecían en bloques de 512, el rendimiento era diferente y peor, al migrar VMs de RTM a R2 mantienes este tamaño de bloque.

-Algunos productos no están soportados cuando corren sobre discos dinámicos, por ejemplo Exchange.

-Se recupera el tamaño al compactarlos lo que requiere parar la VM o desmontar el disco, te recomiendo que antes de compactar el disco lo desfragmentes.

-El rendimiento de los discos duros es peor que el de los fijos, podemos decir que por ejemplo en escrituras aleatorias de 4K el rendimiento será de aproximadamente un 85% de lo que seria en una maquina física sobre un disco normal, sin embargo en escrituras secuenciales de 64K obtendrías hasta un 94% del nativo.

-Estos discos tienden a fragmentarse mas que los normales

-Los discos dinámicos son propensos a problemas de alineación

-Cuando se usan discos dinámicos especialmente si hay varios en la misma LUN hay que ser tremendamente cuidadoso con la monitorización del espacio libre en esa LUN, si no hay espacio libre suficiente, todas las VMs afectadas se pausaran.

-Estos discos en producción siendo usados por cargas que provoquen muchas IOPS suelen actuar de multiplicadores de IOPS en ocasiones incluso x4.

-VHD Diferenciales

-Otro tipo de discos que esta mas escondido son los discos diferenciales, la razón por la que están algo escondidos es en mi opinión por que son muy peligrosos si no se entienden bien y manejan con cuidado.

-En los discos diferenciales existe un disco al que denominamos padre o raíz que es de solo lectura, dependiendo de el hay un numero variable de discos virtuales fijos o dinámicos cada uno de los cuales solo contiene las diferencias con respecto al disco padre.

De esta forma imaginar que tenemos un disco padre en el que instalamos un Windows 7 y le hacemos un sysprep, luego generamos 10 diferenciales a partir de el e instalamos una actualización, cada uno de los diferenciales solo ocupara tanto como los bloques que haya modificado el proceso de sysprep al arrancar la maquina virtual y la instalación de la actualización.

Los ahorros en espacio son muy considerables pero la gestión es mas complicada y hay que analizar cuantos diferenciales puede tener un padre para no perder rendimiento.

Debemos de entender que el disco padre no debe modificarse bajo ningún concepto y que a nivel de rendimiento el disco padre soporta muchísimas lecturas por lo que hay que dimensionarlos adecuadamente, este tipo de sistemas se beneficia muchísimo de los discos de estado solido para ubicar el disco padre.

Puede haber una cadena de discos de este tipo, con R2 no se experimenta una perdida de rendimiento al encadenar discos diferenciales si bien considero que el reto administrativo si que se multiplica exponencialmente.

Estos tipos de discos son la base del funcionamiento las instantáneas de Hyper-V

-Passthrough

Por ultimo los discos passthrough en los cuales la VM accede al almacenamiento directamente sin existir un VHD atacando directamente el NTFS.

-El rendimiento es lo mas cercano que puede ser al rendimiento de un disco duro en una maquina física

-La VM accede directamente al hardware de forma no filtrada

-Los hosts no ven el disco, les aparece offline

-Passthrough se puede usar con VMs en cluster sin problemas

-Si paras la VM y pones el disco online en el host ves el contenido del disco de forma normal.

-No se pueden sacar instantáneas desde Hyper-V en maquinas con discos passthrough

-Normalmente desde el punto de vista de una VM un disco de este tipo puede dar aproximadamente entre un 93% y 98% del rendimiento que se obtendría del mismo disco usado por una maquina física.

-Usar estos discos es menos productivo y cómodo que los discos VHD fijos, úsalos cuando te sea estrictamente necesario, por recomendación de soporte de aquello que vayas a virtualizar o por que la pequeña diferencia de rendimiento contra un disco fijo te sea necesaria.

-Al añadir un disco passthrough a una VM seleccionas el disco físico (offline)

Los siguientes gráficos te muestra las diferencias de rendimiento entre los diferentes tipos de disco (menos es mejor):

Una vez mas no se trata por regla de coger el “mejor” tipo siempre dado que no existe un “mejor” tipo de disco para todo, en este articulo encontraras un punto llamado “Diseñar los discos duros virtuales de las VM” donde os comentare mis recomendaciones para tomar la elección adecuada.

El formato VHD

VHD es un formato que Microsoft a “abierto” y su especificación esta disponible, otras plataformas ya lo usan activamente como formato para virtualizar.

Todo lo que tienes que saber sobre CSV y otros tipos de discos en los hosts

En un servidor que no forme parte de un cluster podremos tener discos duros locales o SAN en los que ubiquemos VHDs o que sean usados como passthrough por las VM, en cualquier caso los mismos consejos de todo el articulo son igualmente validos, alineamiento, patrón de uso, RAID y tamaño de bloque serán aspectos a tener en cuenta.

CSV (Cluster Shared Volumes) nos permite sobre una misma LUN tener discos virtuales de varias VMs en cluster pudiendo estar cada una de esas VMs corriendo en diferentes nodos.

Por tanto CSV nos da principalmente una ventaja de administración ya que no tendremos que estar solicitando continuamente LUNs en la SAN para cada VM.

CSV también ahorra espacio ya que en vez de tener que dejar espacio libre en cada LUN para los ficheros de las VMs, BINs, etc podemos tener cierto ahorro por la economía de escala que implica tener mas VMs sobre la misma LUN, sin embargo hay que tener mucho cuidado de mantener espacio libre en los CSV.

CSV también hace que las live migration sean mas rápidas por razones que explico mas tarde.

Finalmente como punto a favor CSV incorpora funcionalidades de resistencia ante fallos en el acceso a la SAN que pueden resultar interesantes y de las que hablo también mas adelante en este mismo articulo.

En el lado negativo hay que decir que CSV requiere que si quieres usar backups de las maquinas virtuales a nivel de hosts pienses en el backup cuidadosamente y evalúes si tu herramienta de backup soporta CSV y si tu cabina dispone de un proveedor de instantáneas hardware, en cualquier caso tal vez puedas evaluar nuestro producto de backups System Center Data Protection Manager 2010 (DPM) para simplificar y optimizar el proceso.

Otro aspecto a tener en cuenta es que cuando usas CSV si hay problemas de rendimiento es difícil aislar que VM lo provoca.

En general te recomendaría que las VMs cuyas IOPS las consideres mas criticas las aísles en sus propias LUNs.

En un servidor que es miembro de un cluster podemos tener varios tipos de discos compartidos (presentados a todos los nodos del cluster):

-Discos que son usados para albergar uno o mas VHD de una misma VM

-Discos CSV que pueden contener uno o mas VHD de una o mas VMs

-Discos que serán usados como passthrough por una VM

Estos tres tipos de discos pueden ser combinados de cualquier forma.

Una misma VM puede tener discos en diferentes tipos de disco de cluster, juntando discos VHD en CSV con discos VHD sobre LUNs dedicadas y además teniendo también algún disco passthrough.

En contra de lo que mucha gente opina CSV no es un requisito para Live Migration (mover maquinas virtuales de nodo en caliente sin perdida de servicio) cualquier tipo de almacenamiento en cluster es compatible con Live Migration.

Sin embargo hay que decir que debido a que al mover una VM cuyo almacenamiento este localizado sobre CSV no es necesario arbitrar reservas en la SAN ni cambiar propiedades una Live Migration sobre CSV tarda menos desde el punto de vista de normalidad dentro de la VM que sobre LUNs dedicadas.

Cuando se hace una live migration de una VM con LUNs dedicadas hay un momento en el que hay que cambiar la propiedad del disco en ese momento la VM no puede escribir en disco generándose colas dentro de la VM, este proceso dura unos segundos y si estamos usando VHD nos beneficiamos de la mecánica de cache que tiene este formato, sin embargo si usamos discos passthrough no tendremos esta cache, usando CSV este proceso es prácticamente imperceptible.

Si por ejemplo estamos en un geocluster el arbitraje de la propiedad del disco puede tardar algo mas, conviene hacer pruebas de estos tiempos para ver si las cargas se ven afectadas, por ejemplo SQL Server o Exchange son muy quisquillosos cuando no pueden escribir en disco por mas de unos segundos.

CSV no impone un limite a las IOPS que soporta, cuanto mas IOPS aporte la cabina mas tendrá el CSV, sin embargo se percibirá mejor rendimiento si repartimos las VMs entre varios hosts, dado que al final cada host solo tiene unas estructuras de acceso tanto físicas como lógicas a las LUNs y estas pueden suponer un cuello de botella.

A medida que añadimos mas y mas VMs al mismo CSV incrementamos el numero de IOPS que reclamamos de esa LUN a la vez que conservamos las mismas estructuras de acceso podemos entrar en un problema de contención, por eso debemos ser muy conscientes del aumento de requisito de IOPS.

En cuanto a CSV no debéis pensar en el como un saco que lo aguanta todo, es importante seguir algunas recomendaciones:

• Configura siempre una red especifica para CSV (explicado en este articulo mas adelante)
• En general depende de la cabina pero una posible recomendación es que para virtualización de servidores estandarices un numero de VHDs por CSV, 10-15 es un buen numero o estandariza un tamaño razonable 500GB es una buena cifra, esto te obligara a balancear la carga entre varios CSV.
• Para virtualización de escritorios puedes usar tamaños mayores para tus volúmenes CSV
• Especializa los CSV según sus configuraciones (ver el siguiente punto “Diseñar los discos duros virtuales de las VM”)
• Monitoriza adecuadamente los CSV (colas, espacio libre, eventos de CSV y cluster) SCOM es fantastico para esto pues los Management packs del hardware, la SAN, Windows Server, failover cluster, hyper-v y SCVMM te darán la visión completa e incluyen las reglas especificas para entender CSV.
• Cada volumen CSV tiene un nodo que actúa de owner del volumen, este nodo realiza algunas acciones especiales sobre los volúmenes y además es el nodo que en principio soportara la carga de redirección en caso de que se tenga que producir por esta razón es bueno mantener distribuidos entre los nodos del cluster el ownership de los volúmenes.

Como decía antes CSV nos da también funcionalidad de tolerancia a fallos supongamos el siguiente ejemplo:

• Un cluster de dos nodos A y B
• Las VM se encuentran sobre un CSV
• El nodo B pierde conexión con la SAN por todos los caminos
• Sin CSV las maquinas virtuales fallarían al no poder escribir en disco y arrancarían en el otro servidor a través del cluster
• Con CSV el nodo B accede a los discos a través de una conexión de red con el nodo A (la red que se use es configurable)
• Las VMs siguen funcionando con normalidad hasta que un administrador corrija la situación.

A este comportamiento lo llamamos redirección CSV y la primera vez que un administrador de Hyper-V lo escucha es normal que muestre cierta inquietud.

Para empezar si tienes SCOM, eres avisado a través de una alerta de que se ha producido esta redirección, si no tienes SCOM lo veras en la consola de cluster.

Durante la redirección podríamos decir que el rendimiento depende de la calidad de la red entre los nodos, pero incluso con una tarjeta dedicada de 1GB el rendimiento es suficiente para pasar por esta situación excepcional y de contingencia, por supuesto si es de mas mejor.

Si la red de CSV se cae en lo que se esta usando se usara automáticamente otra tarjeta de red si es posible.

Puedes configurar que red se usara por defecto para CSV usando powershell: https://technet.microsoft.com/es-es/library/ff182335(WS.10).aspx

En las capturas a continuación puedes ver el proceso de fallo y como afecta a una VM con SQL Server con carga:

1) El volumen CSV funciona adecuadamente

2) Un nodo pierde conexión con la SAN por todos los caminos, el otro nodo coge la pertenencia del volumen si es que no la tiene ya y este nodo empieza a trabajar con el CSV en redirección

3) Vemos como la tarjeta de red dedicada a CSV aumenta drásticamente su uso unos 120Mbps, en otros casos he visto llegar a los 700Mbps de transferencia

4) SCOM detecta la situación y nos avisa primero desde el management pack del hardware en este caso HP

Y a continuación desde el Management pack de failover cluster

5) En todo momento podemos ver desde el host el rendimiento de CSV redirigido:

6) En lo que dure la redirección el rendimiento de IO cambiara dentro de la VM siendo en general menos sostenido pero usable

La redirección de CSV se produce por SMB2 lo que requiere que en los adaptadores de red que vayan a ser usados por CSV dejes activados el cliente para redes microsoft y el compartir impresoras y archivos.

Los adaptadores de red usados por CSV de todos los nodos tienen que estar en la misma subnet

Durante el backup de un volumen CSV también se realiza una redirección, es importante que lo tengáis en cuenta pudiendo usar proveedores de instantánea Hardware para minimizar el tiempo de redirección, en caso de usar DPM incluso con el proveedor de instantáneas software se pueden realizar configuraciones adicionales que minimizan el impacto de la redirección durante los backups.

Indudablemente usar volúmenes CSV de un tamaño de 500Gb en contra de volúmenes de 2TB por ejemplo hace que el numero de VMs que entran en redirección ante la perdida de un volumen se ve reducido al igual que los tiempos de backup de todo el volumen.

Sin usar CSV puedes poner mas de un VHD en una LUN de cluster, pero tienes que asegurarte de no poner nunca VHDs de mas de una VM si lo haces a parte de no estar soportado conseguirás que al mover una VM afectes a la otra inevitablemente.

Diseñar los discos duros virtuales de las VM

En la primera parte de este articulo hemos hablado de los patrones de carga y de como los diferentes parámetros de configuración del almacenamiento afectaban al rendimiento.

La clave para un buen diseño del almacenamiento en la virtualización es mantener un alineamiento entre los requisitos de la carga en la VM, la configuración de los parámetros del disco virtual y los parámetros del disco en el host.

De esta forma un cluster tendrá que tener diferentes tipos de discos físicos según las cargas que deba soportar.

Podemos diferenciar claramente entre cuatro tipos de necesidades:

• Discos duros de sistemas operativos:
  • Si la VM no es 2008 alinear manualmente antes de instalar, para ello puedes crear el VHD desde el host y luego usarlo para la VM
  • Dejar el tamaño de cluster por defecto
  • En producción siempre VHD fijos
  • Sobre CSV siguiendo las buenas practicas que te he indicado en este articulo sobre CSV
  • La LUN de este CSV debería ser RAID 1 preferiblemente
  • En general discos SATA o bajas RPM son factibles
• Discos de logs transaccionales
  • Sobre CSV de forma general, si el disco esta sometido a una carga que se considere especial usar una LUN dedicada o un disco passthrough como ultima opción solo si un disco VHD fijo sobre LUN dedicada no cumpliera con tus requisitos de IOPS
  • En cualquier caso la LUN debería ser RAID 1 nunca RAID 5
  • El tamaño de bloque tanto del disco duro virtual en caso de usarse como del disco sobre el que este podría ser de 32K o 64K
  • Si la VM no es 2008 alinear manualmente antes de instalar, para ello puedes crear el VHD desde el host y luego usarlo para la VM
  • Tener en cuenta el Nº de discos de este tipo que se situaran por CSV, en función de ello calcular las IOPS y tomar las decisiones de RPM y tamaño de banda de forma acorde
• Discos de bases de datos
  • Sobre CSV de forma general, si el disco esta sometido a una carga que se considere especial usar una LUN dedicada o un disco passthrough como ultima opción solo si un disco VHD fijo sobre LUN dedicada no cumpliera con tus requisitos de IOPS
  • En cualquier caso la LUN debería ser RAID 5 o 10
  • El tamaño de bloque tanto del disco duro virtual en caso de usarse como del disco sobre el que este debería ser de 64K o ser evaluado de forma especifica pero siempre en sintonía
  • Si la VM no es 2008 alinear manualmente antes de instalar, para ello puedes crear el VHD desde el host y luego usarlo para la VM
  • Tener en cuenta el Nº de discos de este tipo que se situaran por CSV, en función de ello calcular las IOPS y tomar las decisiones de RPM y tamaño de banda de forma acorde
• Discos de ficheros
  • Sobre CSV
  • RAID 5
  • Si la VM no es 2008 alinear manualmente antes de instalar, para ello puedes crear el VHD desde el host y luego usarlo para la VM
  • En general el tamaño de bloque por defecto es valido debiendo ser el mismo para el disco físico que para el virtual
  • En general discos SATA o bajas RPM son factibles

Los limites de Hyper-V para hosts y VMs

Cada maquina virtual en Hyper-V puede tener 4 discos duros IDE y 4 controladoras SCSI, cada una de ellas con hasta 256 discos duros.

El tamaño máximo de un VHD es de 2TB.

No hay limite a los volúmenes CSV o normales que puede tener un cluster o servidor, dependiendo el numero máximo de las limitaciones que tenga el hardware y los drivers, en general podemos decir que cada target de almacenamiento puede sostener unas 255 LUNs y Windows a su vez unos 255 Targets.

¿Necesitas aun mas rendimiento?

Si has agotado todo hasta aquí aun queda algo mas, hay mas parámetros de almacenamiento que se pueden tocar si bien deben de manejarse con cuidado y siempre probando el impacto que tienen.

Encontraras todos estos parámetros en la guía de tuning de Windows Server 2008: https://msdn.microsoft.com/en-us/windows/hardware/gg463392

En algunos casos si el sistema operativo de las VM es mas antiguo te conviene ver las guías de tuning de esos sistemas operativos por ejemplo en Windows Server 2003 modificar esta clave de registro: NTFSDisableLastAccessUpdate HKLM\System\CurrentControlSet\Control\FileSystem\ (REG_DWORD) puede suponer una reducción de IOPS aunque tiene otras connotaciones que debes entender.

Conclusiones

Muchas infraestructuras de virtualización funcionan sin haber nunca reparado nadie en aspectos como los que hemos hablado en este articulo pero también es cierto que muchas de ellas mas tarde o temprano empiezan a tener problemas de rendimiento.

Hacer bien las cosas desde el principio y ser conocedores en profundidad de aquellos aspectos en los que estamos involucrados nos hace mejores profesionales y a nuestros clientes o empresas les garantiza que sus plataformas de virtualización serán escalables y predecibles.

Un saludo a todos!

Daniel Matey

Introducción

NUMA viene de “Non uniform Memory Access o Non Uniform Memory Architecture” una forma simple de entender NUMA es decir que en un servidor multiprocesador que pueda usar NUMA este generara unos grupos llamados nodos formados por uno o mas procesadores y una cantidad de memoria, normalmente los procesadores dentro de un nodo comparten físicamente un bus de sistema y un canal de entrada salida con el sistema.

Los diferentes nodos están conectados entre si por un bus de interconexión.

El sistema tratara de correr los hilos en los procesadores asociados a la memoria donde el hilo trata de acceder.

Las APIs del sistema permiten además a las aplicaciones ser conscientes de NUMA lo que puede redundar en mejoras de rendimiento, la virtualización es una de las cargas que mas puede beneficiarse de NUMA por esta razón Microsoft invirtió en Hyper-V de cara a extraer lo máximo de NUMA.

Gracias a esta arquitectura los procesadores pueden usar la memoria dentro de su nodo NUMA de forma mucho mas rápida que la que esta en otros nodos, esto redunda en un mayor numero de ciclos de reloj disponibles para otras actividades lo que implica un mejor rendimiento del sistema, cuantas mas VMs tiene un servidor de Hyper-V mayores son los beneficios de NUMA.

NUMA nació de la necesidad de incorporar funcionalidades en el hardware que permitieran un incremento mas lineal del rendimiento a medida que los servidores cada vez tenían mas procesadores.

En sistemas no NUMA todos los procesadores tienen el mismo derecho a acceder a los recursos de memoria e I/O cuantos mas procesadores tienen estos sistemas menos eficiente son en el uso rápido de los recursos.

Una maquina no NUMA funciona así:

Mientras que una NUMA organizara los recursos en nodos como os he contado:

La inquietud por NUMA en la virtualización viene cuando una VM necesita recursos de mas de un nodo NUMA debido a que el uso de esos recursos será mas lento que si usa recursos locales a su nodo.

Preocuparse por NUMA no es algo común, muchos administradores no conocen de su existencia, no es algo que debamos hacer en el día a día en una instalación normal, sin embargo en ciertas situaciones entender NUMA puede ayudarnos a comprender por que un sistema no rinde como nos gustaría o como optimizar mejor un host de virtualización.

NUMA es lo suficientemente inteligente como para ser consciente de  por ejemplo agrupar los cores de un mismo procesador en vez de cores de diferentes procesadores.

No se si ha habido cambios al respecto pero la ultima vez que lo revise los procesadores AMD crean un nodo por procesador mientras que en Intel puede variar.

Por ultimo deciros que los nodos NUMA puedes estar contenidos en grupos, cada grupo tiene un máximo de 64 procesadores lógicos (cores o hilos si usas hyperthreading) el numero máximo de grupos es 4 numerados del 0 al 3, en sistemas con menos de 64 procesadores lógicos veras un solo grupo NUMA con los nodos que sean necesarios.

AVISO: Antes de seguir es necesario que te insista en que preocuparte por NUMA no es necesario salvo que quieras optimizar un sistema hasta las ultimas consecuencias y necesites hasta la ultima gota de rendimiento y aun en ese caso hay otras muchas cosas de las que preocuparse por optimizar antes que NUMA.

Os voy a explicar NUMA para vuestro conocimiento de Hyper-V, ten en cuenta que en general la penalización de rendimiento por falta de afinamiento de NUMA es muy pequeña.

La optimización de NUMA es especialmente interesante y productiva cuando hablamos de hosts de Hyper-V muy estáticos que normalmente siempre tienen las mismas VMs, en sistemas mas dinámicos optimizar NUMA no es sencillo y en algunos casos no es posible.

Algunos servidores incluyen una alternativa a NUMA llamada SUMA si es tu caso no la actives, Hyper-V y Windows Server se benefician de NUMA, SUMA esta pensada para sistemas que no sean capaces de aprovechar estas capacidades.

No conozco ningún estudio que mida el impacto de usar recursos de otros nodos en virtualización pero si hay estudios sobre el impacto de NUMA en otras cargas.

Que vamos a ver en este articulo

• Como saber si mi servidor esta usando NUMA y que nodos tengo
• ¿Por que me tiene que preocupar NUMA en un host de virtualización?
• NUMA y la memoria dinámica
• La afinidad de las VMs a nodos NUMA
• ¿Puedo evitar que los recursos de una VM se extiendan a mas de un nodo NUMA?

Como saber si mi servidor esta usando NUMA y que nodos tengo

Una forma de ver los nodos NUMA que tienes y con que recursos cuentan son los contadores de Hyper-V con respecto a NUMA:

¿Por que me tiene que preocupar NUMA en un host de virtualización?

Cuando un hilo corre sobre un procesador que esta en el mismo nodo que la memoria a la que quiere acceder entonces el rendimiento es fantástico, cuando por el contrario esta situación no se da, el rendimiento es algo peor, no es el fin del mundo y la mayoría de los sistemas se enfrentan a esta condición a diario sin conocimiento de sus administradores.

Cuantificar esta penalización en un % es muy difícil dado el numero de factores que entran en juego, la cifra depende mucho del tipo de carga, podemos decir que una VM con muchos procesadores y con mucha RAM es mas susceptible de este problema y que en caso de darse, si la VM ejecuta cargas que hacen uso intensivo de operaciones de memoria o de operaciones SMP entonces la VM se vera aun mas afectada.

Los host de virtualización gestionan unas cargas muy dinámicas en cuanto a recursos, una VM puede usar memoria dinámica o en cualquier momento una VM con mas de un procesador puede verse afectada por la imposibilidad de encontrar tiempo libre de tantos procesadores como necesite dentro del mismo nodo NUMA.

En un sistema NUMA, por defecto cada VM tiene un nodo preferido, Hyper-V siempre trata de asignar memoria del mismo nodo a la VM.

Hyper-V establece este nodo preferido cada vez que  la VM arranca, como Hyper-V no puede predecir la carga que la VM tendrá es posible que con el tiempo esta VM requiera recursos que estén en otros nodos y esto conducirá a lo que denominamos fragmentación NUMA.

Desde el performance monitor puedes ver también en que nodo NUMA esta corriendo cada VM y en el contador “Remote physical pages” os dais cuenta de si se esta usando memoria de otros nodos.

NUMA y la memoria dinámica

Aunque NUMA afecta a la red y a los procesadores también, os voy a contar el ejemplo de la memoria dinámica por que es el mas fácil de entender:

Hyper-V siempre tratara de ubicar toda la memoria de una VM en un único nodo NUMA.

Pero si no es posible tendrá que usar memoria de varios nodos NUMA, esto puede pasar en el arranque de una VM, pero la probabilidad aumenta de que pase en ejecución cuando usas memoria dinámica, tu VM seguirá funcionando igual de bien, pero el rendimiento bajara un poquito.

Usar memoria dinámica aumenta las probabilidades de que una VM tenga que repartirse entre varios nodos NUMA lo normal será, insisto que esto no nos preocupe salvo en condiciones muy extremas.

La afinidad de las VMs a nodos NUMA

Es posible configurar que las maquinas virtuales tengan afinidad con un nodo NUMA, obviamente esto es algo que se debe de analizar cautelosamente debido a la cantidad de implicaciones que tiene en la gestión de los recursos.

Cuando se cambia el nodo preferido para una VM, es necesario reiniciarla.

Para hacerlo lo mejor es que emplees el script que se explica en el siguiente post de un compañero: https://blogs.msdn.com/b/tvoellm/archive/2008/09/28/looking-for-that-last-once-of-performance_3f00_-then-try-affinitizing-your-vm-to-a-numa-node-.aspx 

¿Puedo evitar que los recursos de una VM se extiendan a mas de un nodo NUMA?

No logro dar ahora con ninguna maquina con este evento, pero en el event viewer de los servidores encontraras eventos indicándote si en en algún momento se ha tenido que usar recursos de otro nodo para servir por ejemplo la memoria pedida por una ampliación realizada a través de memoria dinámica.

En Hyper-V R2 SP1 se ha añadido la posibilidad de evitar que una VM use recursos de mas de un nodo.

Activar esta opción tiene claras connotaciones como que por ejemplo se reducirá el numero de VMs que podremos correr en el host o se limitara la memoria RAM máxima que pueda tener una VM en función de la que este disponible en el nodo NUMA en la que corra.

Cuando activas este parámetro desde el punto de vista de los recursos del host es como si dividieras tu servidor en servidores de virtualización mas pequeños

Conclusiones

No creo que sea muy común que os tengáis que preocupar por NUMA, pero conocer de su existencia no os hará daño

La memoria es uno de los aspectos mas críticos que pueden existir a la hora de virtualizar, entender la arquitectura de memoria de Hyper-V nos permitirá comprender como aprovechar mejor nuestros recursos y obtener el mejor rendimiento posible.

Que vamos a ver en este articulo

• Escogiendo la memoria física del servidor
• Limites de memoria en Hyper-V
• La reserva de memoria del host
• El fichero de paginación (host y VM)
• Los ficheros .BIN
• Entender la memoria dinámica en profundidad
• Monitorizar la memoria
• Gestionando la memoria dinámica
• Conceptos avanzados: la memoria y los grupos NUMA
• Conclusiones

Escogiendo la memoria física del servidor

Hace poco veíamos en un articulo en este blog, lo importante que es equilibrar adecuadamente la configuración del host para poder obtener el mejor coste por VM posible. (La importancia del equilibrio en la elección del host- Impacto en el coste por VM)

Esta claro que la cantidad de memoria es el parámetro mas importante sobre la memoria, si bien la velocidad y la latencia de la memoria son siempre importantes en un host de virtualización lo normal seria sacrificar si es necesario estos otros aspectos con el fin de obtener mas cantidad de memoria al mismo precio.

La evolución de los procesadores también juega a vuestro favor ya que cada procesador presiona mas al resto de los componentes para evolucionar y así por ejemplo cuando salió la serie de XEON 5500 de Intel se podia llegar a rebajar la latencia en la memoria casi un 50% con respecto al XEON 5400.

Se puede conseguir mas memoria a menor precio comprando memoria mas lenta y de igual forma podemos tener memoria mas rápida al mismo precio reduciendo la cantidad de memoria.

Yo no soy un experto en hardware pero segun la información que puedes encontrar en internet, para que podáis tener criterio, diremos por ejemplo que la memoria DDR-3 a 1333MHZ  puede mover 35GBps, mientras que a 800MHZ moverá 25GBps, evidentemente son cifras muy altas, algunos otros buses en el sistema serán un cuyo de botella mas tarde y puede que al final estas cifras se rebajen a 8GBps reales, debemos tener en cuenta en cualquier caso que en un servidor físico toda esa velocidad esta al servicio de un único sistema, mientras que en un servidor de virtualización estará al servicio de hasta 384 VMs por servidor con Hyper-V.

Sin embargo os recomiendo evaluar cuidadosamente la elección de memoria, por ejemplo muchos fabricantes ofrecen diferentes módulos de memoria con los servidores, la elección que hagamos puede tener impacto en el rendimiento de la memoria ya que por ejemplo algunos módulos de memoria pueden forzar al sistema a rebajar la velocidad del bus para todos los módulos y por tanto seria un desperdicio de dinero conjugar memoria rápida con memoria lenta.

Si piensas ampliar la memoria del servidor en un futuro ten en cuenta los bancos de memoria que quedan libres en el servidor con la configuración de memoria que selecciones.

Limites de memoria en Hyper-V

Como sabéis Hyper-V se puede instalar de dos formas:

Con la versión dedicada y gratuita “Hyper-V Server” que contiene todas las funcionalidades de Hyper-V pero ningún derecho de licencias.

Como un rol de Windows Server que activaras sobre una instalación full o core del sistema operativo, beneficiándote de las ventajas de licenciamiento que esto conlleva, de esta forma por ejemplo al usar Hyper-V como rol de un Windows Server Datacenter que se licencia por socket todas las VMs que montes tendrán los derechos de Windows Server incluidos.

Windows Server Enterprise y Datacenter soportan al igual que Hyper-V server hasta 2TB de memoria, sin embargo Hyper-V solo puede trabajar de forma soportada con 1TB de memoria.

Una maquina virtual puede tener 64GB de memoria, aunque el uso que haga de ellos dependerá por supuesto del sistema operativo que corra dentro de la VM.

La reserva de memoria del host

El host y la partición padre requieren de memoria para funcionar y es muy importante asegurarnos de que tienen la memoria que requieren.

A parte de la propia memoria requerida por el sistema operativo de la partición padre, tenemos que tener en cuenta la memoria que consuma en pico los agentes de antivirus, monitorización, backup, etc.

Debemos de considerar que es mejor que paginen las VM que que pagine el host, aunque como repetiré varias veces en este articulo la paginación es un enemigo natural de la consolidación de VMs.

De esta forma a grandes rasgos te recomiendo lo siguiente:

• Hyper-V requiere 300MB para si mismo
• El sistema en la partición padre requiere 512MB
• Suma la memoria máxima de los agentes que instales en el servidor, antivirus, monitorización, etc
• Por cada VM suma 32MB
• Por cada GB que tenga una VM por encima del primero suma otros 8MB

Suma todo esto y será la cantidad de memoria que tienes que reservar en el host.

Desde SCVMM en las propiedades del host configura la cantidad adecuada:

El resto de memoria que quede en el host será la memoria que podrás usar para las VMs, esto es así por que la memoria de las VM es de un tipo especial denominado “non-paged-pool memory” esto supone una garantía de rendimiento dado que nos garantiza que las VM siempre usaran RAM y no paginación en disco. El host puede paginar pero no por la RAM que usen las VMs.

En este articulo hablaremos también de la memoria dinámica y como esto nos ayudara a obtener el máximo de la memoria del host.

La memoria dinámica supone retos adicionales a la hora de mantener unos recursos determinados para el propio funcionamiento del host incluso configurando las reservas tradicionales que os acabo de contar, por eso con el SP1 ha habido algunos cambios en cuanto a las reservas y ahora Hyper-V calcula por si solo una cantidad de memoria y la reserva al host, esta reserva no puede verse atacada por la memoria dinámica.

Para el calculo de esta reserva especial Hyper-V tiene en cuenta diferentes aspectos como la cantidad total de memoria, la arquitectura de NUMA en el servidor (luego hablare de NUMA) , si el host tiene SLAT o no y por supuesto la memoria usada por las VMs y el overhead que estas producen en el host.

Este calculo que realiza Hyper-V puede no ser correcto para vuestro entorno dado que no tiene en cuenta cosas como el antivirus, los agentes, etc., si realizáis vuestro propio calculo siguiendo las directrices que os he dado antes podéis modificar el calculo de Hyper-V cambiando el valor de la clave de registro memoryreserve dentro de HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization poner este valor muy bajo será muy negativo para el rendimiento así que solo modificarlo si lo habéis analizado adecuadamente.

Cuando se cambia este valor por norma general hay que reiniciar el servidor (no es necesario en todos los supuestos pero os lo recomiendo).

El fichero de paginación

En el host:

Un servidor de Hyper-V siempre es un servidor de 64 bits (x64) la forma "genérica” de calcular el tamaño recomendado para el fichero de paginación de un servidor x64 la podéis encontrar en el siguiente enlace: https://support.microsoft.com/default.aspx?scid=kb;EN-US;889654 

Veis que en dicho documento se habla de varios métodos para determinar el tamaño si en tu caso no requieres poder realizar volcados de memoria completos puedes reducir el fichero de paginación al mínimo usando el método 2 explicado en el documento.

Ten en cuenta que un volcado de memoria de un servidor con 256GB de RAM dura lo suyo y que además por defecto necesitarías un gran disco duro solo para sostener el fichero de paginación con una configuración típica.

En las VMs:

El mismo articulo aplica a las maquinas virtuales, pero ten en cuenta lo siguiente:

-Si un sistema operativo pagina es por que le falta memoria RAM.

-Si un sistema pagina, consume operaciones de entrada y salida (I/O) en disco

Cuando virtualizas muchas VMs en un mismo servidor y sistema de almacenamiento las I/O deben de ser de las cosas que mas te preocupen.

Si una VM pagina en disco tendrá un impacto al que seguramente podrás sobrevivir, si por ejemplo tienes 1000 VDIs y has dimensionado mal la memoria y un porcentaje importante de estas VMs pagina entonces el rendimiento general será realmente penoso.

Si bien la memoria dinámica que veremos mas tarde en este articulo te ayuda con este aspecto también, esto no quita que tengas que ser muy cuidadoso a la hora de calcular la memoria real que necesitas.

Aun con memoria dinámica si no has calculado bien puedes quedarte sin memoria con la que jugar y entonces veras cifras negativas de memoria disponible en las VMs y por tanto estarás sufriendo paginación:

Por favor monitoriza adecuadamente todas tus VM para darte cuenta si paginan y ajusta la RAM convenientemente para evitar la paginación en la medida de lo posible.

Hay consideraciones adicionales para el fichero de paginación cuando vas usar memoria dinámica, las explico mas tarde cuando trate este tema en este articulo.

Si el rendimiento de la paginación es critico para una VM, puedes usar un VHD fijo adicional para la paginación, esto te dará mas rendimiento extra.

Los ficheros .BIN

En cualquier momento puede ser necesario realizar operaciones que tienen repercusiones con respecto a la memoria de una VM, como por ejemplo pausar una VM o sacar una instantánea.

Hyper-V es un sistema tremendamente protector que intenta a toda costa evitarte problemas especialmente los de estabilidad.

Por esto Hyper-V reserva en el disco espacio para poder respaldar la memoria de la VM  en disco y esto lo hace a través del fichero .BIN que veras que en ocasiones ocupa tanto como la memoria asignada a la maquina virtual.

Este comportamiento es el normal y no se puede evitar, no es necesario que hagas backups de estos ficheros.

La memoria dinámica tiene implicaciones también para los ficheros BIN, mas tarde en este articulo os hablare de ello.

Entender la memoria dinámica en profundidad

Cuando configuras una maquina virtual hay dos formas de configurar su memoria, estáticamente o dinámicamente.

Configuración de memoria estática

Cuando se configura una VM con memoria estática será necesario contar con toda esa memoria RAM libre en el host para poder arrancar la maquina virtual, si el host no tiene suficiente memoria RAM recibiremos un error que nos impedirá arrancar la VM en este host, pudiéndolo intentar en otro nodo del cluster si es que estamos en un cluster.

En la siguiente captura del performance monitor ves como la RAM usada en el host crece automáticamente por el valor de la RAM configurada en una VM en cuanto esta arranca.

De esta forma si configuramos todas las VM de un host con memoria estática la suma de la cantidad de memoria RAM de todas las VM mas la memoria RAM no paginada usada por el HOST nunca podrá superar la RAM total del HOST.

Configuración de memoria dinámica

Normalmente los servidores o escritorios virtualizados no usan el 100% de la memoria asignada durante todo el tiempo, de hecho a ninguno nos gusta que ninguna de nuestras maquinas este al 90% de uso de memoria de forma constante ¿verdad?.

Hyper-V a través de la memoria dinámica nos permite aprovechar de forma inteligente la memoria no usada en las maquinas virtuales redistribuyendo esta memoria a las maquinas virtuales que la necesitan dentro del host.

Lo mejor de este sistema es que no afecta al rendimiento de forma perceptible, no entraña riesgos y no te requiere de ningún cambio de configuración en el sistema operativo de la VM para aprovechar todo su potencial. Además es gratis!.

Tal vez el único punto negativo es que la memoria dinámica (en adelante DM) no funciona con maquinas virtuales Linux.

Podéis usar DM en servidores Windows Server 2008 R2 SP1 con Hyper-V o con la versión gratuita de Hyper-V; Hyper-V Server 2008 R2 SP1.

Las maquinas virtuales en las que activéis DM pueden ser Windows Server 2003, 2008 y 2008 R2 tanto en 32 como en 64-bit.

También podéis usar DM en Vista y Windows 7 versiones enterprise y ultimate en 32 y 64-bit.

Cosas importantes que tenéis que saber también sobre la DM son:

-Que si usáis SCVMM y SCOM los PRO-TIPs y Live Migration son absolutamente conscientes de la memoria dinámica, seréis avisados cuando haya problemas de memoria y las VMs se pueden mover solas si queréis para aliviar la presión en los nodos, Live Migration se encarga de liberar RAM en el destino si es necesario y posible para hacer hueco a la VM.

-Hyper-V nunca paginara para crear RAM de donde no hay por lo que nunca tendréis problemas de rendimiento.

Cuando configuramos una VM con memoria dinámica indicamos 3 parámetros iniciales:

La memoria de arranque será la cantidad de memoria que la VM reclamara al HOST para arrancar y una vez la VM arranque estará completamente bloqueada para su uso.

Hay dos formas de tomar la decisión de cuanta memoria asignar como memoria de arranque:

1) Podemos usar la tabla de memoria mínima necesaria por sistema operativo, a continuación os pongo esta tabla con este valor para todos los sistemas operativos soportados con memoria dinámica:

Si bien esta forma de hacerlo es la mejor cuando buscamos maximizar todo lo posible el potencial de la DM, desde mi punto de vista no es el mejor enfoque aunque es una opinión personal.

2) Desde mi punto de vista es mejor tomar la decisión basándonos en los datos de la monitorización, si sabemos que un servidor emplea habitualmente 1.2GB no tiene sentido configurarlo con una memoria mínima de 512 MB, será mejor configurar una memoria mínima cercana al uso real.

Creo que esto nos permite un mejor y mas realista dimensionamiento de los sistemas a la vez que evita al host operaciones innecesarias.

El siguiente parámetro a configurar es la memoria máxima, si bien en algunos sitios se ha leído que lo mejor es configurar la memoria máxima al máximo permitido por Hyper-V (64GB) o bien al máximo permitido por el sistema operativo de la VM si es menos de 64GB, en mi opinión personal  tenemos que configurar un valor que consideramos apropiado a la carga que existe dentro de la VM y al coste que queramos repercutir a ese servicio.

Por ejemplo es muy lógico configurar una VM VDI Windows 7 con 768MB de arranque y 2GB de RAM Máxima

El siguiente parámetro es el buffer, podemos entender esta parámetro fácilmente viéndolo como el que especifica a Hyper-V que cantidad de memoria tiene que darle de una sola vez a la VM cada vez que es necesario.

Si configuramos el buffer a un 10% y una VM que tiene ocupados 1GB requiere mas RAM, Hyper-V tratara de darle 100MB si están disponibles bien como memoria libre en el host  o bien como memoria que puede liberarse por falta de uso en otras VMs con DM.

Si ponemos el buffer a un valor muy bajo se le entregara memoria a la VM en bloques pequeños por lo que la VM no tendera a tener mucha memoria libre, sin embargo un buffer mayor dejara holgura en la VM lo que puede ser beneficioso para algunas cargas que usan caches en RAM.

Deciros que si es posible atender una solicitud de memoria Hyper-V lo hace de forma activa e inmediata en cuanto una VM lo solicita.

¿como añade y quita memoria Hyper-V?

Hyper-V gestiona la DM a través de varios componentes nuevos introducidos en SP1.

Hyper-V añade la memoria gracias los componentes de integración (IC) que sabéis que tenéis que instalar en todas las VM que ponéis en Hyper-V por eso cuando actualizáis vuestros Hyper-V R2 a SP1 tenéis que actualizar los IC de todas las VM para que puedan usar DM.

Dentro de los IC de la VM hay un elemento que se encarga de comunicar a Hyper-V la presión de memoria que hay dentro de la VM, a este componente le llamamos “Dynamic Memory VSC” donde VSC significa Virtual Service Consumer.

Hyper-V tiene otro componente análogo llamado “Dynamic Memory VSP” donde VSP significa Virtual Service Provider este componente se encarga de escuchar la información de los VSC sobre la presión de memoria dentro de las VMs.

Finalmente Hyper-V tiene otro componente denominado “Memory Balancer” este componente se encarga de seguir la presión de memoria de todas las VMs con la información que le pasa el VSC y si es necesario y se puede reclama la memoria no usada y también asigna memoria a las maquinas que lo necesiten.

Al añadir memoria se usa una funcionalidad que aportan los IC para añadir memoria en caliente lo que dispara el sistema de Plug and play para detectar la nueva memoria dentro del sistema operativo de la VM.

Si os dais cuenta DM funciona en sistemas operativos que no soportan de serie la funcionalidad de añadir memoria en caliente, esto es gracias como os digo a los IC.

Quitar memoria es un poco mas difícil de entender, principalmente por que DM en realidad si lo vemos desde el punto de vista del sistema operativo de la VM nunca quita la memoria aunque en realidad la memoria física ya no esta disponible para la VM.  veamos como es esto…

La DM en Hyper-V a la hora de quitar memoria usa una técnica denominada “balloning” o balón de memoria.

Cuando Hyper-V decide quitarle memoria a una VM por que no la usa esta memoria libre se prepara dentro de la VM y entonces gracias a un driver introducido por los IC Hyper-V hincha el balón de memoria dentro de la VM usando memoria no paginada, este balón indica al sistema operativo que esa  memoria esta siendo usada por el driver de forma que el sistema operativo ya no la usa para nada mas e Hyper-V puede por detrás retirar esa memoria física y asignársela a otra VM.

Si usáis la herramienta rammap de sysinternals veréis lo bien que se ve como el driver bloquea la memoria.

La reclamación de la memoria no se realiza inmediatamente en cuanto la VM no la necesita salvo que otras VMs estén reclamando esa memoria y no haya mas memoria libre en el sistema.

Con el fin de optimizar el proceso y evitar esperas, Hyper-V recolecta la memoria libre cada 5 minutos.

Otro parámetro que se puede configurar es la prioridad o peso que tendrá esta VM respecto a otras a la hora de reclamar memoria.

Ya he comentado varias veces en este blog lo que opino de las reservas y prioridades, si lo vais a usar analizarlo cuidadosamente y forzaros a revisarlo periódicamente para ver si el criterio sigue aplicando.

Presión de memoria y banda de presión:

Para entender cuando una VM pide memoria tenemos que entender el concepto de presión de memoria

Expresamos la presión de memoria como un %, este porcentaje se calcula dividiendo el valor de “current commit charge”  por el valor de la memoria física, el porcentaje restante hasta el total de la memoria RAM física que ve la VM es el valor que llamamos “free buffer”

Podéis ver el valor de “current commit charge”  de muchas formas una de ellas es desde el process explorer.

Cuando la presión es superior al 100% la VM estará paginando mucho y el “free buffer” será negativo.

Hyper-V ve la presión de memoria de la VM dentro del contexto de lo que denominamos banda de presión, esta banda tiene unas marcas de agua que establecen la presión mínima y máxima dentro de la VM, los datos de presión mínima y máxima se establecen en base a la información histórica de presión de memoria dentro de la VM.

Si la presión actual se mantiene entre el mínimo y el máximo la memoria ni se quitara ni pondrá.

La memoria se quita cuando la presión de memoria esta por debajo de la presión mínima y se pide memoria cuando se excede la presión máxima.

Para que la DM funcione adecuadamente es necesario que la maquina virtual tenga bien configurada la paginación, si el fichero de paginación no es suficientemente grande Hyper-V no podrá añadir mas memoria a la VM.

Permíteme un ejemplo que voy a simplificar mucho para que entendáis esto ultimo: una VM tiene en este momento 1GB asignado, esta usando 950MB y un proceso pide 100MB, lo primero que es necesario es que el sistema operativo dentro de la VM le de esos 100MB y para eso tendrá que paginar los 50 que faltan, justo después Hyper-V detectara la condición y le añadirá memoria a la VM, pero si no hay espacio en el fichero de paginación no será posible todo esto.

Otra cosa a tener en cuenta es que el sistema operativo dentro de la VM si esta configurado para establecer dinámicamente el tamaño del fichero de paginación lo hará en función de la cifra de RAM que configuramos como memoria de arranque, esto implica que si queremos que dentro de una VM se pueda ejecutar un volcado de memoria completo será necesario configurar el tamaño del fichero de paginación manualmente al tamaño máximo de memoria que pueda tener la VM.

Es común preguntarnos si debemos usar o no la DM en nuestras VMs, la respuesta seria que si en la gran mayoría de los casos, solo evitaremos su uso en aquellas VMs que tengan cargas donde el fabricante explícitamente no soporte este tipo de tecnológicas o donde no tengan sentido por ser cargas como bases de datos que tienden a usar toda la RAM disponible como cache de datos, en este blog tenéis un articulo sobre DM en servidores de Exchange y SQL server: ¿Puedo usar la memoria dinámica de Hyper-V con Exchange y SQL Server- 

Hay un ultimo aspecto que comentaros sobre la memoria dinámica y es que el fichero .BIN puede crecer al incrementarse la cantidad de memoria debido a una operación de adición de memoria.

Si no hay espacio para que el .BIN crezca no se podrá añadir mas memoria (https://support.microsoft.com/kb/2504962)

Si usas Windows Server 2008 SP2 y ves que no se incrementa la memoria de la VM por encima de la memoria de arranque, evalúa este articulo de la KB: https://support.microsoft.com/kb/2230887 

Monitorizar la memoria

Básicamente tenemos dos grupos de contadores, los contadores del balanceador de memoria que nos hablan de la memoria que el host tiene disponible y de las operaciones de añadir y quitar memoria y por otra parte los contadores relativos a cada VM que nos hablan de la memoria que se quita y se pone y de la presión de memoria que experimenta la VM.

Gestionando la memoria dinámica:

Cuando salió la versión RC de System Center Virtual Machine Manager 2008 R2 SP1 realice una serie de artículos en este blog sobre la gestión de la memoria dinámica, os dejo aquí los enlaces por si tenéis inquietudes sobre estos aspectos:

Gestionando la memoria dinamica I- Actualizando SCVMM R2 a SP1 (RC)

Gestionando la memoria dinamica II- Actualizando los agentes de SCVMM

Gestionando la memoria dinamica III- Integración SCVMM R2 SP1 y SCOM

Gestionando la memoria dinamica IV- La consola de SCVMM R2 SP1

Gestionando la memoria dinamica VI- Controlando la presión

Gestionando la memoria dinamica VI (b)- Controlando la presión (Informe personalizando SCOM)

Conceptos avanzados: la memoria y los grupos NUMA

Mi próximo post en este blog será sobre NUMA y por tanto os emplazo a el para entender las repercusiones de NUMA en la arquitectura de memoria de Hyper-V.

Conclusiones

Mientras que puede parecer que la memoria es un concepto muy sencillo y realmente lo es, hay un montón de cosas como ves en este articulo con son interesantes de entender si quieren alcanzar un nivel mas profundo de conocimiento sobre la virtualización con Hyper-V.

Gracias a la gestión de memoria de Hyper-V y a la memoria dinámica esperamos que podáis aprovechar al máximo vuestros hosts sin tener que preocuparos por ningún riesgo para el rendimiento.

Espero que el articulo os sea interesante.

Un saludo!

1. Instalaras en producción todos los management packs que encuentres

Tienes que ir poco a poco, cada management pack requiere sus ajustes, suelen ser muy pocos, pero si montas muchos management packs de golpe se te acumulara el trabajo de parametrización.

2. Nunca leerás una guía de configuración de un management pack

Si montas un management pack y no sigues la guía de configuración recibirás alertas falsas y esto te dará mas trabajo, lee siempre cuidadosamente la guía de configuración y no des por terminada el despliegue del management pack hasta que termines con ella.

3. Cerraras la misma alerta 1000 veces sin plantearte de donde sale

Cerrar las alertas tal cual salen es como barrer en el desierto, algunas reglas o monitores pueden requerir de alguna parametrización adicional para cumplir con tus criterios y peculiaridades de tus sistema a lo mejor para ti un 30% de falta de espacio en un disco concreto no es un problema, hazte el mejor favor que te puedes hacer a ti y a tus compañeros y si la alerta no debe preocuparte no la cierres simplemente, parametrizala para que no vuelva a salir.

4. Nunca instalaras las actualizaciones acumulativas de SCOM y si lo haces lo harás sin leer las instrucciones que lo acompañan.

Mantener SCOM actualizado es muy importante cada actualización te quita trabajo evitando alertas falsas, problemas con agentes, etc, actualiza tu SCOM y hazlo siempre leyendo las instrucciones algunas actualizaciones requieren que siguas algunos pasos en los SQL.

5. Guardaras todas tus personalizaciones en el management pack por defecto

Créate tus propios management packs y guarda en ellos tus personalizaciones, crear un management pack propio por cada uno que importas te da la mayor granularidad y es algo que te llevara un minuto.

6. No te familiarizaras con los “overrides” ni con la parametrización básica de reglas y monitores

Los overrides son la herramienta mas potente que tienes para la parametrización de los management packs que importas, debes de sentirte cómodo con ellos y usarlos con criterio de esa forma evitaras invertir tiempo en cerrar alertas que no reflejan la realidad de tu entorno por falta de parametrización.

7. No usaras los favoritos ni crearas tus propias vistas

Los management packs incorporan muchas veces decenas de vistas algunas de ellas con mucha información en la misma vista, cuando encuentras una vista que es especialmente interesante para ti lo mejor es que la guardes en los favoritos para encontrarla mas tarde con facilidad.

Para ser mas productivo créate tus propias vistas, las vistas de “dashboard” son especialmente útiles para ver de un vistazo la información que te resulta útil para tu instalación  e inquietudes.

8. No crearas tus propios diagramas (aplicación distribuida)

Crear tus propios diagramas de aplicación distribuida para cada servicio que monitorizas te ayudara a forzarte a entender como funcionan tus servicios en realidad y a ver si te falta algún management pack o si tienes que añadir alguna regla o monitor creada por ti mismo

9. No usaras el “poner en mantenimiento”

Cada vez que reinicias un servidor o sabes que hay un problema con algún elemento usar el modo mantenimiento te evita a ti y a tus compañeros un montón de alertas y sustos.

10. No definirás una metodología de trabajo con SCOM

La mejor forma de hacer bien las cosas es siempre pensarlas, define una forma de trabajar con SCOM, como trabajaras tu y tus compañeros con las reglas, quien tiene que resolverlas cuando se puede cerrar una alerta, que informes mirareis para ir mejorando poco a poco las cosas, las normas para meter un nuevo management pack, etc.

Conclusiones

Gracias a los management packs, SCOM 2007 R2 alcanza un nivel de profundidad y calidad de la monitorización ejemplares, sin embargo monitorizar los complejos servicios que se prestan hoy en día es un reto complicado y aunque SCOM te lo ponga mas fácil que otros productos es necesario que sigas unas pequeñas directrices para alcanzar el éxito.

En este blog puedes encontrar algunos artículos que te ayudaran:

Tomando las riendas de tu SCOM

Trabajando con Alertas en SCOM desde el punto de vista del operador

Una forma sencilla de hacer modelos de salud con SCOM

Haciendo cuadros de mando y mapas de servicio de SCOM (the easy way)

Un saludo a todos!

En un mercado en el que cada vez queremos consolidar mas servidores y escritorios sobre los servidores físicos, la demanda obliga a Intel y AMD a sacar procesadores con mas cores, además últimamente estamos viviendo el resurgir del hyperthreading.

En este articulo simplemente vamos a tratar de entender mejor algunos conceptos importantes sobre como pensar y usar los procesadores en nuestros servidores de virtualización y cual es el impacto de crear VMs con mas de un procesador.

En adelante usare la siguientes abreviaturas:

VM= Maquina virtual

VP= Procesador virtual (el procesador dentro de una VM)

HT= Hyperthreading

LP= Procesador lógico (es el hilo en si de proceso equivale a un core si no se tiene HT, si un core tiene HT cada core son dos LPs)

Que vamos a ver en este articulo

Los puntos que trataremos serán los siguientes:

• Escoger un procesador
• Cores y mas cores
• El retorno del Hyperthreading
• Entender los procesadores virtuales y como Hyper-V funciona a nivel de proceso
• Reservas y NUMA
• Consideraciones con respecto al análisis de la consolidación de servidores y el uso de procesador

Escoger un procesador

Hoy en día hay infinidad de procesadores y cuando compramos un servidor en muchas ocasiones últimamente solo se esta mirando Nº de procesadores y Nº de cores, sin embargo hay muchos aspectos muy importantes.

Es una obviedad pero cada procesador tiene un rendimiento diferente, en Internet podemos encontrar varias paginas donde nos muestran estas diferencias, que como veis en la siguiente imagen pueden ser realmente muy significativas:

El rendimiento que obtengamos de los procesadores especialmente los multi core y mas cuando los empleamos para virtualizar puede estar muy influenciado por los componentes que rodean a cada core, la cache el chipset y los buses son elementos muy importantes, la calidad de la placa madre y las especificaciones del servidor deben tener importancia a la hora de escoger nuestro procesador.

Cuando compramos un servidor podemos elegir gran cantidad de opciones de procesador que debemos pensar cuidadosamente para extraer el máximo de nuestra inversión:

Además los procesadores pueden incorporar funcionalidades como SLAT que pueden ser mas que criticas si por ejemplo estamos hablando de servidores de virtualización sobre los que tendremos maquinas virtuales VDI o servidores de Terminales, si no estamos al tanto de estos aspectos es mas que interesante dejarse aconsejar por un experto antes de realizar el pedido.

Como vimos en otro post el procesador es un aspecto muy importante a la hora de mejorar el coste por VM (La importancia del equilibrio en la elección del host- Impacto en el coste por VM )

Cores y mas cores

Aunque nos pueda sorprender un poco no es lo mismo el rendimiento de dos procesadores que de un procesador de 2 cores, si bien el numero de procesadores suele tener mas peso en el precio que el Nº de cores y además no podríamos conseguir los ratios de consolidación que queremos sin usar muchos cores.

En cualquier caso es algo que debemos saber aunque sea solo por hablar con criterio, la siguiente imagen muestra un análisis efectuado para evaluar el rendimiento de procesadores multi-core con cargas OLTP.

Intel realizo hace tiempo un informe comparing_multicore_server_virtualization_07-2601w.pdf en el que podemos encontrar también información muy interesante especialmente en los diferentes consumos energéticos que experimentan los procesadores multi-core :

Tener en cuenta también que la gestión de energía del sistema operativo tiene impacto en el rendimiento de la virtualización, si tenéis servidores host con cargas muy variables podéis experimentar un aumento del rendimiento ajustando los planes de ahorro de energía.

El retorno del Hyperthreading

Otro aspecto que cada vez aparece mas es el de Hyperthreading (HT) gracias a HT un solo core puede correr 2 hilos a la vez, Intel lo explica así:

“ HT adds circuitry and functionality into a traditional processor to enable one physical processor to appear as two separate logical processors. The added circuitry enables the processor to maintain two separate architectural states and separate APIC which provides multi-processor interrupt management and incorporates both static and dynamic symmetric interrupt distribution across all processors. The shared resources include items such as cache, registers, and execution units to execute two separate programs or two threads simultaneously ”

Y AMD a su vez dijo:

“So – cores are like bikes, threads are the riders. Running more threads increases throughput for applications as long as you have available cores. If you have threads waiting to be scheduled and no available cores – you have a bottleneck.”

De cara a Hyper-V los cores con HT cuentan como 2 procesadores, sin embargo debemos tener en cuenta que Hyper-V soporta hasta 64 procesadores en el host así que si tenemos mas de 32 cores en el servidor tenemos que deshabilitar HT para no superar ese limite de 64.

Hyper-V ha sido diseñado para beneficiarse de HT y el rendimiento de tus VMs será mejor con el que sin el.

Es difícil hacer una recomendación general pero creo que la mas acertada seria decir que uséis HT como una ventaja pero que no lo tengáis en cuenta a la hora de dimensionar.

Por ejemplo sabemos que Microsoft en VDI con Windows 7 soporta hasta 12 procesadores virtuales por procesador lógico, en el caso de un core con HT esto contara como dos LP, a esto lo denominamos ratio VP:LP, bien usar HT para dimensionar nos llevaría a pensar que podemos correr 24VP por core y esto desde mi punto de vista es excesivo, si leéis los posts de diferentes grupos de producto como SQL, Exchange, etc os daréis cuenta de que es mejor dimensionar con respecto a los cores sin HT y luego emplear HT como una ventaja añadida.

Entender los procesadores virtuales y como Hyper-V funciona a nivel de proceso

Se que es básico pero permitirme decirlo; en un host de Hyper-V nunca debemos de correr ninguna carga que no sea Hyper-V.

Es un error poner por ejemplo un DC en el servidor de Hyper-V, si necesitas el DC ponlo en una VM sobre el Hyper-V, es muchísimo mejor.

Hyper-V ha sido diseñado para gestionar los recursos no para competir por ellos.

Obviamente no nos queda mas remedio que poner ciertas cosas en la partición padre tales como el antivirus o los agentes de System Center.

En Hyper-V 2008 R2 SP1 como sabéis solo es posible de forma soportada configurar maquinas virtuales con un máximo de 4 procesadores virtuales VP, esto además depende también del sistema operativo de la VM ya que algunas solo soportan 1 o 2 procesados como máximo.

Por desgracia es muy común que los administradores seleccionen siempre mas de 1 procesador virtual para sus maquinas pensando que esto supone un aumento de rendimiento.

En mi opinión ninguna VM tiene que tener mas de 1 procesador si no lo usa y esto bien se puede saber por que estemos convirtiendo un servidor y sepamos que esta usando exhaustivamente mas de 1 procesador o bien por que tengamos una monitorización adecuada y los datos nos arrojen esta necesidad de mas de un procesador.

Antes que nada hay que tener en cuenta que no todas las cargas se benefician de un mayor numero de procesadores pero si que tanto para el sistema operativo dentro de la VM como para el host que la soporta tener mas de un procesador (SMP) supone una carga añadida.

Podemos decir que en Hyper-V un VP nunca esta ligado de forma estática a un LP, asignar un VP a una VM solo indica que le estamos dando un tiempo de proceso.

Si que es cierto que Hyper-V mantiene en cada VP un atributo de “procesador lógico preferido”  y por defecto tratara de ejecutar el hilo sobre ese LP.

Simplificando, cuando una VM tiene mas de un procesador, cada vez que la VM necesita “proceso” el host tiene que encontrar disponibilidad de tiempo simultanea en el numero de procesadores que tenga la VM, esto como podéis entender es mas complicado cuanto mas VPs tienen las VMs y cuanto mas VMs tiene un host.

Por ejemplo muy común usar 2 procesadores para VDI cuando la mayor parte del tiempo las apps no saben usarlo y lo mas normal serán patrones de carga como este:

Moraleja: usa mas de un procesador en las VM solo cuando sea necesario.

Para los mas avanzados de vosotros os diré además que cuando ponemos VMs con 4 micros estamos aumentando las posibilidades de que la VM tenga que estar ejecutándose en mas de un nodo NUMA lo que cambia mucho como funciona a bajo nivel la asignación de procesadores.

Hay otros aspectos a tener en cuenta a la hora de configurar los VP de una VM:

Si un cluster tiene nodos con diferentes tipos de procesadores es muy importante marcar siempre la casilla “allow migration to a virtual machine host with a different processor” para que las Live Migration funcionen. (Podéis hacerlo por script en todas las VMs del cluster).

Un parámetro que causa mucha confusión es el de CPU Type en SCVMM, este parámetro no es para limitar los MHZ de las CPU en la VM lo que es imposible dado que Hyper-V usa virtualización por hardware y el procesador se expone a la VM tal y como es físicamente.

Este parámetro simplemente nos vale para darle una pista a SCVMM sobre como creemos que esta VM usa el procesador si mucho o si poco, mi recomendación es que si no lo vais a usar cuidadosamente y a reevaluar periódicamente lo dejéis en todas las VM al máximo.

SCVMM usa esta información como parámetro del algoritmo de intelligent placement por ejemplo cuando queremos mover una VM de servidor indicándonos cual es el mejor servidor para esta VM en base a este y otros muchos criterios.

Aquí tenéis un post de un compañero sobre como afecta este parámetro al algoritmo de Intelligent placement (https://blogs.technet.com/b/mghazai/archive/2009/12/02/what-is-cpu-type-in-scvmm-2008-r2-vm-processor-hardware-profile.aspx )

Reservas y NUMA

Hyper-V tiene una arquitectura muy avanzada y a diferencia de otras plataforma de virtualización es mucho mas moderna, esto hace que no sea necesario contar con el truco de asignar una VP a un LP generando una afinidad, Hyper-V ejecutara los hilos de los VP en el LP que sea mas apropiado en cada momento.

Solo cuando existe un ratio 1:1 entre VPs y LPs Hyper-V tiende a mantener cierta afinidad entre los VPs y LPs sin embargo es un escenario poco común y difícil de mantener en un cluster cuyas ventajas además no son importantes.

Siempre lo digo; yo no soy amigo de las reservas en virtualización, las infraestructuras virtualizadas son muy dinámicas y los sistemas dentro de las empresas también, esto implica que lo que en un momento es super importante a los X meses deja de serlo y nadie se acuerda de que se configura la VM como super prioritaria.

Sin embargo a veces puede ser necesario y para eso en SCVMM tenemos las prioridades tanto de procesador como de memoria:

Mas fuertes aun son los parámetros que podemos configurar desde la propia consola de Hyper-V, por favor usarlas con cuidado y criterio y nunca juntéis las de SCVMM con la de Hyper-V.

Como veis en la captura es posible configurar limites o reservas para los procesadores virtuales, si se pone el limite de procesador a 0 la VM no arranca que le ha pasado a mas de 1.

Para los mas avanzados de vosotros que sepáis lo que es NUMA y como configurarlo debemos de ser cuidadosos también con esto, si por ejemplo el servidor genera grupos NUMA cada 2 procesadores crear una VM de 4VP no será muy eficiente aunque funcionara bien, espero poner un post sobre NUMA en mas detalle dentro de poco para aquellos que no lo conozcan.

De forma muy sencilla puedo explicar NUMA diciendo que podemos generar ciertos grupos que establezcan una afinidad entre recursos hardware, es posible vincular VMs a grupos NUMA lo que desde luego no recomiendo para todo el mundo pero que en situaciones extremas puede tener importancia.

Consideraciones con respecto al análisis de la consolidación de servidores y el uso de procesador

Es curioso que cuando se va a virtualizar un servidor pensemos automáticamente que si el servidor a consolidar tiene 4 micros la VM resultante tiene que tener 4 micros.

Digo que es curioso por que en mucha ocasiones el servidor físico tiene 1.3GHZ por ejemplo y lo vamos a poner sobre micros XEON a 2.8GHZ que es como 3 veces mas rendimiento procesador a procesador en muchos casos.

Conclusiones

Los procesadores son una parte fundamental de nuestra plataforma de virtualización como profesionales entender y analizar adecuadamente los aspectos relacionados con ellos garantiza que la calidad de nuestras arquitecturas y dimensionamientos esten a la altura de lo que esperan los clientes.

Un saludo a todos!

Introducción:

Ojala todas las CMDB fueran la de System Center Service Manager (SCSM) todo seria muy sencillo como vimos en este post: https://blogs.technet.com/b/dmatey/archive/2010/12/10/la-cmdb-en-system-center.aspx

Sin embargo SCSM lleva poco tiempo aun en el mercado y es por tanto mas que común que nos encontremos con CMDBs materializadas en productos de BMC, HP y otros.

A medida que la madurez en el gobierno de IT crece, la CMDB se convierte cada vez en un elemento mas importante y es entonces donde se empiezan a requerir cada vez mas integraciones con la CMDB.

System Center esta pensado para ser un elemento estratégico para las empresas en la eficiencia y ahorro de costes en gestión de los sistemas así que como no, también os facilita este tipo de integraciones.

Que vamos a ver en este articulo:

Os voy a enseñar dos ejemplos que atienden a dos necesidades muy comunes:

1- Agrupar servidores o componentes de servicio en SCOM en base a atributos de dichos servidores en la CMDB

2-Alimentar atributos de las VMs en SCVMM en base a sus atributos en la CMDB

No quiero hacerlo usando SCSM que seria lo mas fácil así que como no tengo una CMDB de CA, BMC o HP a mano voy a hacerlo con una simple base de datos.

Ejemplo 1: Agrupando objetos en SCOM en base a sus atributos en la CMDB

En la CMDB cada servidor esta relacionado con el servicio que presta, seria fantástico poder usar esta información en SCOM para realizar diagramas de forma automática o aplicar configuraciones de monitorización en base a este atributo.

Para conseguir nuestro objetivo de la forma mas sencilla y potente vamos a usar Opalis (cuya próxima versión será System Center Orchestator), ya hemos hablado mucho de Opalis en este blog para los que no lo conozcáis aquí tenéis una introducción

Opalis que esta incluido sin cargo adicional en la suite de System Center incluye conectores, llamados integration packs o IPs para las CMDB mas importantes así como IPs genéricos que harán el trabajo si no existe un integration pack para vuestra CMDB o estáis usando simplemente una BD genérica como CMDB.

Como decía no tenemos una CMDB a mano que no sea la de SCSM así que voy a usar una CMDB falsa en una BD.

Desde Opalis podría conectarme sin problemas a otras CMDB, por ejemplo aquí tenéis algunas de las acciones que podemos usar para integrarnos con la CMDB de BMC:

Como siempre hay muchas formas de hacerlo, cuando lo hacemos en producción la forma mas elegante es crear un management pack y extender el objeto de SCOM con las propiedades del servicio y el owner por ejemplo.

Para este articulo lo voy a hacer mas sencillo.

1-Crear un management pack en SCOM:

2- Crear los atributos

Le damos al atributo el nombre que queramos

Lo vamos a guardar en nuestro management pack, como target seleccionaremos Windows Computer, como esta clase esta dentro de un management pack sellado no podemos utilizarla tal cual, al seleccionarla en el asistente este creara automáticamente una copia de esta clase en nuestro management pack y extenderá sus atributos con el nuevo atributo que estamos creando.

Ahora tenemos que indicar que es lo que queremos mirar en el registro, en nuestro caso nos vamos a crear un valor propio que será una cadena donde diremos el servicio según lo que indique la CMDB, así que esa será el valor que miraremos en el registro.

60 segundos es demasiada frecuencia pero para una demo es lo mas adecuado, en producción una vez al día será mas que suficiente para la mayoría de los casos.

Hacemos lo mismo creando un atributo para el owner del servidor.

Desde la consola de SCOM en discovered inventory ya podemos ver que todos los servidores tienen los nuevos atributos, obviamente vacíos.

Ahora es el momento de ponernos con Opalis.

Creamos una nueva política.

El primer objeto de nuestro workflow va a ser un Monitor Date/Time que nos permita correr automáticamente el workflow una vez al día como queremos.

El segundo será la query a la BD

A partir de ahí lo que haremos será:

• En cada maquina que exista en la CMDB:

• Mirar si existe la clave en el registro
• Si no existe crearla
• Guardar el valor del servicio
• Indicar en el eventlog del servidor de Opalis si ha habido algún error o se ha terminado con éxito

El workflow terminara como veis:

Con este workflow cada servidor en la CMDB tendrá alimentado en el registro quien es su dueño y a que servicio pertenece.

Ahora solo necesitamos crearnos los grupos en el SCOM, podríamos hacerlo también desde Opalis cada vez que se encuentre un servicio en la CMDB que no esta en SCOM pero lo voy a hacer a mano para este ejemplo.

Vamos a crear una pequeña jerarquía de grupos como ya visteis en este articulo sobre crear modelos de salud:

Vamos a usar miembros dinámicos por supuesto, si no nos valdría para nada.

Como veis en cuanto seleccionamos nuestra clase ya nos salen los atributos.

Ahora simplemente vamos a crearnos un grupo que contenga como hijos todos los grupos que vienen de la CMDB

Listo, si Opalis ha hecho su trabajo ya podréis ver el diagrama del grupo

Fijaros como en el diagrama la salud no sube por la jerarquía, para conseguirlo tendréis que crear los monitores adecuados como explico aquí: articulo sobre crear modelos de salud:

Es estupendo por que ya podemos usar estos grupos para overrides, permisos, como objetivos de reglas, etc., seguro que os da mucho juego.

También podemos crearnos nuestras vistas:

Ejemplo 2: Incorporar a SCVMM información de la CMDB

Otra necesidad muy común es reflejar información en las VMs que esta registrada en la CMDB, voy a usar como ejemplo el centro de coste.

El workflow de Opalis queda así:

En esencia es un workflow muy parecido al que ya explique aquí: https://blogs.technet.com/b/dmatey/archive/2010/12/06/extendiendo-ssp-2-0-en-la-nube-privada-ii-integrando-ssp-y-scvmm-con-opalis.aspx

Ahora ya podras ver tus VMs agrupadas por servicio, ejecutar acciones en todas las VM de un servicio, o sacar informes sobre el uso de los recursos por servicio:

Conclusiones:

Se me ocurren muchas otras formas de conseguir este mismo objetivo con System Center, os he mostrado una y espero que con ello hayáis visto lo flexible y potente que es System Center y como incorporar la información de la CMDB a nuestras herramientas de gestión puede facilitarnos mucho las cosas en el día a día.

Un saludo a todos!

Hace días que quería felicitar a Miguel por el fantástico trabajo que esta realizando tanto desde la consultora Zerkana ayudando a sus clientes a avanzar en tantos y tantos aspectos como desde el punto de vista de la comunidad de IT PRO en su labor de MVP.

Esta dedicación y los conocimientos de los que hace gala le han valido ser nuevo MVP por un año mas y además el que ahora lo sea de la categoría de Microsoft MVP - Virtual Machine: Systems Administation.

Si alguno no lo conocéis Miguel mantiene un estupendo blog: https://undercpd.blogspot.com/ 

Felicidades Miguel!!

Hoy en este post si me lo permitís voy a hacer un ejercicio muy simple, incluso simplista buscando daros algo mas en lo que pensar cuando evaluéis comprar un servidor para virtualizar.

Es realmente muy común adquirir el “servidor de oferta“ o basar la decisión simplemente en el montante final. De esta forma por ejemplo es frecuente encontrar casos de nuevos servidores con 4 procesadores de 6 cores y 64Gb de RAM por ejemplo.

Analicemos muy superficialmente este caso usando solo el coste del servidor para determinar el coste por VM, lo que es obviamente incorrecto pero valido como base para este ejemplo:

Nota: Para obtener el coste del servidor he empleado el P.V.P. de un conocido fabricante, emplearemos modelos en Rack donde es mas fácil calcular el coste por VM que en servidores blade.

Muy posiblemente el coste que reflejo pueda variar debido a que tal vez un experto en hardware pueda encontrar mas adecuadas otras opciones, pero insisto esto es un ejercicio rápido.

El precio de este servidor según la web para la opciones que he seleccionado (4U, 4 micros de 6 cores con 64Gb de RAM) es de 16.894€

Para hacer el calculo sencillo, vamos a pensar en que nuestro objetivo es virtualizar 96 maquinas con la misma configuración: 1 procesador y 2 GB de RAM con un uso medio realista esperado en pico de 60% de memoria y 25% de procesador, lo que bien podría ser un escenario VDI.

Cuando decimos que esperamos que una VM consuma un 25% de procesador una vez mas estamos simplificando dado que cada modelo de procesador nos da un rendimiento diferente y los ratios deben de calcularse en base al procesador del host.

Un 25% vendría a decir que el ratio que esperamos de consolidación de procesadores virtuales por core es de 4:1, Hyper-V soporta 8:1 como máximo cuando hablamos de servidores y 12:1 cuando hablamos de escritorios.

ahora si pensamos en un core de 2.2 GHZ con 12 procesadores virtuales corriendo encima y todas las VMs requiriendo procesador podemos ver una vez mas simplificando que cada VM obtendría algo parecido a 183MHZ, no es así, por que el reparto del procesador no se efectúa de esta forma pero a efectos de comprensión debemos comprender que los procesadores dan lo que dan y los ratios deben ser realistas.

Nota: Usando memoria dinámica de forma conservadora y buscando nunca impactar el rendimiento ni entrar en una excesiva presión de memoria obtenemos estas cifras, habrá quien os diga que se puede ser mucho mas agresivo con el calculo de la memoria, pero ese es otro debate y creo que ya esta todo escrito en internet (ASLR, Large Memory Pages, carga en el host, impacto, etc.):

Como veis lo que mas ha impactado en el coste de las VMs es que tenemos capacidad de procesador sobrante en el servidor pero no podemos poner mas VMs por falta de memoria incluso usando memoria dinámica como he hecho en el ejemplo

Vamos a tener que poner dos hosts por que en uno solo no caben las 96 así que cada VM nos sale a 351,9€ solo en la partida de hardware, por suerte Hyper-V es gratuito y no tenemos que añadir el coste del Hypervisor aunque sin duda habrá que añadir otras cosas, conectividad, licencias dentro de las VMs, costes de mantenimiento e instalación, almacenamiento, etc.

Si en vez de VDI estuviéramos hablando de virtualizar servidores, usar el rol de Hyper-V en Windows Server Estándar, Enterprise o Datacenter tiene ventajas de licenciamiento ya que por ejemplo en el caso de este ultimo, Windows Server Datacenter se licencia por socket y da derechos a las licencias de todos los Windows Server que corran sobre ese socket, lo que sin duda os permitirá reducir el coste total de propiedad de vuestros servidores.

Añadamos a este mismo servidor mas memoria, llevándolo a 128Gb

El coste por VM baja a 216,3€, el servidor a aumentado su precio, con 128Gb de RAM nos cuesta 20.767€.

La memoria nos ha costado 3.873€ Pero solo necesitamos un servidor y nos han cabido las 96VMs que queríamos.

Por lo tanto para conseguir 96VMs con la primera configuración necesitamos 2 servidores lo que nos llevaría a  una inversión en hardware de 33.788€. Con la configuración de 128GB de RAM lo podremos hacer solo con 20.767€, creo que merece la pena pensar en ello, ¿Verdad?

Vamos a hacer otro experimento, cojamos un servidor de 2U y 2 procesadores con el máximo de cores disponibles en este fabricante.

Un servidor de 2U y 2 procesadores de 12 cores con 128GB de RAM nos sale por 8.145€, el servidor es algo peor en cuanto a rendimiento por core, buses, caches y otros elementos pero por ese precio creo que merecería la pena probarlo si el fabricante nos dejara uno .

El coste por VM es de 84,8€ e igualmente en un solo host nos han cabido todas las VMs.

De esta forma nos damos cuenta del tremendo impacto en el TCO (Coste total de propiedad) que tiene la elección del host, Aunque os pueda parecer una obviedad es común encontrarnos con estas situaciones.

Como decía antes esta claro que hay que empezar a sumar otras partidas de las que hablare en otros posts como las redes, el storage y las licencias de las VMs, lo que desde luego no tenéis por que añadir si usáis Hyper-V es el coste del hypervisor.

En este post vamos a hablar de los siguientes temas:

• Dominios de fallo, clusters, geo-clusters y clusters gemelos distribuidos geográficamente
• Reservas de clusters y overcommit (sobrecarga)
• Arranque en orden de VMs y su importancia en clusters saturados
• Configurar los dueños posibles de una VM en un cluster
• Evitar que unas VMs coincidan con otras
• Las VMs y el modo persistente

Aunque es difícil encontrar una definición estandarizada, se puede decir que en arquitectura denominamos dominio de fallo a aquellos conjuntos de elementos ante cuyo fallo queremos estar preparados.

Así por ejemplo cuando montamos un cluster para un servicio nuestro dominio de fallo de mayor entidad seria el nodo del clúster.

Cuando un nodo del cluster cae, los nodos restantes se encargaran de absorber las VMs del nodo caído.

Para ello es importante que el cluster tenga capacidad libre para absorber es carga,la mejor forma de conseguir tener esta garantía es a través de SCVMM que se encargara de auditar esto por nosotros.

SCVMM se encarga de calcular que los clusters tengan capacidad suficiente para mantener las máquinas virtuales operativas en caso de fallo de un número concreto de nodos, cuando esta capacidad no puede ser garantizada el cluster entra en “over committed” o sobrecarga en español y SCVMM no permitirá crear nuevas máquinas virtuales o realizar otras acciones que tengan relación con los recursos.

SCVMM realiza estos cálculos de sobrecarga cuando:

· Se añaden o quitan VMs o se produce un refresco o discovery.

· Falla o se quita un nodo del cluster

· Se añade un nodo al cluster

· Se cambian las reservas

Una adecuada monitorización del capacity planning de los clusters será la manera más adecuada de evitar la posibilidad de overcommit de un cluster.

Por defecto SCVMM guarda la capacidad de un nodo por cluster, fijaros que digo la capacidad y no que impida usar uno de los nodos, aunque exista esta reserva todos los nodos pueden tener VMs funcionando.

Si se ajusta a 0 SCVMM no controlara la sobrecarga y ante el fallo de un nodo podrían quedar VMs no disponibles.

En ocasiones tendremos que poner números mayores a 1, especialmente en el caso de clusters distribuidos geográficamente de los que hablaremos mas tarde en este mismo articulo.

Es común que nos equivoquemos al pensar en como SCVMM debe calcular esta capacidad reservada, usualmente pensamos que si tenemos 4 nodos con 10GB de RAM debería de guardar 10GB de RAM como reserva, sin embargo esto dependerá de muchos factores que nos pueden dar otro resultado, especialmente si las VM tienen configuraciones muy dispares.

Así por ejemplo si en un cluster de 4 nodos con 10Gb de RAM por nodo tuviéramos una VM de 6GB y otra de 8GB SCVMM tendría que calcular que el clúster debe tener 14GB de RAM libre contando con un bloque contiguo de 6GB y otro de 8GB no solo simplemente 10GB con el fin de permitir la caída de un nodo.

Otro aspecto que tenemos que tener en cuenta es como reacciona el cluster ante una caída de un nodo.

Una vez que un nodo cae, todas las VMs que están configuradas para arrancar de nuevo lo intentan en el siguiente nodo, donde unas podrán arrancar y otras no por falta de recursos las VMs que tengan que recorrer mas nodos antes de conseguir arrancar estarán sin dar servicio durante mas tiempo.

Esto se puede evitar con el uso de nodos pasivos que no tengan VMs y configurando el orden de los nodos en las propiedades de la VM en el cluster:

En caso de que queramos que un nodo concreto no sea mostrado al crear VMs o al moverlas, con el fin de permita que las VMs puedan arrancar más rápidamente al garantizar que tenemos nodos completamente disponibles y que por lo tanto las VMs no tendrán que ir nodo por nodo buscando recursos podremos usar la opción “This host is available for placement” que en caso de estar desactivada causara este comportamiento.

En un cluster distribuido geográficamente, también llamado geo-cluster o multi-site cluster los nodos se encuentran distribuidos por mas de un CPD, con lo que nuestro dominio de fallo será este CPD o site, esto nos dará cobertura adicional a fallos de líneas, SANs, etc.

Este tipo de dominios de fallo por CPD pueden ser a su vez de dos tipos Activo-Activo y Activo-Pasivo.

Hace tiempo era muy común que las empresas tuvieran un CPD “frio” orientado a poder ejecutar los sistemas críticos si el CPD principal tenia un problema grabe, normalmente estos CPD se encuentran muy alejados del CPD principal buscando también evitar que un desastre de cualquier tipo pueda afectar a los dos CPD.

La distancia entre los dos CPD siempre a supuesto un problema de comunicaciones especialmente por la latencia y la imposibilidad en muchos casos de extender VLANs por unos u otros motivos, de igual forma la replicación síncrona del almacenamiento también se ve limitada por las distancias.

La estrategia de CPD frio no basada en virtualización supone un coste hoy en día difícil de justificar especialmente si tenemos cantidad de sistemas duplicados con complicados procesos de puesta en marcha, mantenimiento y operación.

La virtualización hizo que los CPD fríos fueran mas baratos de mantener dado que las mismas VMs de producción podían correr en este segundo CPD si hiciera falta, los simulacros eran mas sencillos, etc.

Como los CPD fríos no suelen tener las VLANs extendidas y por otras razones también, suele hacer falta algún software especializado que “orqueste” el plan de recuperación y se encargue de hablar con la SAN, arrancar las VMs en orden, cambiar IPs hablar con la electrónica, DNSs, esto se puede hacer tanto con System Center como con soluciones de terceros.

Los CPD activos-activos son la mejor solución suelen estar próximos, replicados síncronamente y con las VLANs extendidas de forma que las VM se pueden mover libremente entre un CPD y otro, este tipo de configuración se ha vuelto muy común entre la gran-gran empresa yo he montado estas soluciones en bancos, periódicos, aseguradoras, etc. y cada vez lo vemos en empresas de menor tamaño a medida que las soluciones de replicación se hacen mas económicas.

En este tipo de clusters configuraremos la reserva de nodos de SCVMM a la mitad de los nodos, pues queremos poder sobrevivir sin problemas a la caída de un CPD completo.

La replicación del almacenamiento se puede hacer por software o por hardware siendo este ultimo el mas frecuente aunque también el mas costoso económicamente.

Cuando se emplea una replicación de este tipo, puede funcionar de forma totalmente transparente para el cluster o bien requerir de configuraciones adicionales.

Por ejemplo en la imagen a continuación veis como para que funcione la replicación usando la solución CLX de HP es necesario introducir un recurso especial en el grupo de recursos de la maquina virtual, dentro de ese recurso configuramos los CPD y que nodos y cabinas están en cada CPD, luego se establecen las prioridades adecuadas y este recurso será el encargado de comunicarse con las cabinas y determinar cual es la que tiene los discos de esta VM en escritura/lectura.

A la hora de escoger una solución de replicación es importante tener en cuenta si soporta o no CSV, en muchos casos estas soluciones se basan en que la replicación es en un solo sentido por LUN mientras que CSV por su naturaleza requiere que sea bidireccional estando las LUN operativas en ambos CPDs.

Si la solución de replicación no soporta CSV no quedara otra que asignar al menos una LUN por VM.

Mucha gente piensa que Live Migration requiere CSV pero esto no es cierto aunque si muy recomendable, dado que si no se usa CSV hay que cambiar la reserva persistente en la SAN lo que implica que la VM no puede escribir en disco durante el tiempo que dure el arbitraje, en algunas soluciones de geo-cluster el cambio de la propiedad del disco dura un poco mas de lo normal, hay que tener esto especialmente en cuenta si estamos hablando de VMs con mucha carga transaccional, si este tiempo se alarga demasiado podríamos tener problemas con los servicios dentro de las VM por ejemplo caerse una BD de SQL Server por no poder escribir en el disco durante segundos.

En ocasiones algunas empresas cuentan con CPDs adicionales “frios” asíncronos por naturaleza y necesidad, separados geográficamente por grandes distancias, una forma de conseguir esto es usar System Center Data Protection Manager para replicar los cambios en las VMs por ejemplo cada 30 minutos.

Sin embargo debemos tener en cuenta que aunque el geo-cluster es estupendo, no es para todo por varias razones:

• El Geo-Cluster es el mas caro de los clusters, deberían ser simétricos por lógica aunque no es obligatorio, esto hace que por cada nodo mas que necesitamos tenemos que comprar un segundo para equilibrar los CPD y permitir la caída de todo el CPD.
• La replicación es costosa hay casos en que se paga por host, en otros por GB y por lo tanto cualquier crecimiento o el volumen de partida impacta mucho en el coste
• Muchas VMs usan sus propios mecanismos de HA a nivel de servicio tales como balanceos de carga, clusters de guests, mirrors de SQL, CCR de Exchange, controladores de dominio, etc, lo que hace que el geo-cluster no sea necesario para VMs que no sean “únicas” e imprescindibles de cara al servicio que presten.

Es vital que seamos conscientes de que usar un cluster de virtualización o soluciones equivalentes de otros fabricantes de virtualización con funcionalidades de alta disponibilidad nos aporta tolerancia a fallos en el hardware y puede que en el almacenamiento y las redes, donde nunca nos aporta tolerancia a fallos en a nivel de servicio.

Si dentro de una VM hay un servicio y este se corrompe, cae o falla, mover la VM de nodo o CPD nunca arreglara el problema, por esa razón hay que seguir usando sistemas de tolerancia a fallos a nivel de servicio como por ejemplo un cluster de SQL Server.

Así nos encontramos con que en ocasiones lo mas eficiente es contar con un geo-cluster y lo que llamo “clusters gemelos” que serian 2 clusters uno en cada CPD donde repartiremos simétricamente esos servidores que disponen de otros mecanismos de tolerancia a fallos.

En los clusters gemelos es posible permitir incluso la sobrecarga dado que todas las VMs son prescindibles en un momento dado.

En cualquier caso dejar la reserva a 1 nodo nos permitirá reducir el coste total de propiedad del cluster con cada nodo que añadamos y además disfrutaremos de la comodidad de live migration.

Otra casuística de los clusters es que en ocasiones deseamos que unas maquinas virtuales arranquen antes que otras, por ejemplo las que aporten los appliances de almacenamiento o controladores de dominio, también querremos que las VM de bases de datos arranquen antes que los frontales web por ejemplo.

Esto lo podemos conseguir con el delay start tal y como veis en la siguiente captura, donde también podéis configurar si queréis que la VM arranque sola o no, en clusters muy saturados a veces las VM menos importantes pueden ser configuradas para arrancar las ultimas con lo que puede ser que no arranquen por falta de recursos o incluso para que no arranquen solas:

Otra cosa que se puede querer evitar que unas VMs coincidan con otras a través de lo que se denomina reglas de anti-afinidad.

Si os interesa esta funcionalidad mi compañero y maestro Jedi David Cervigón lo explico hace ya mucho tiempo en su fantástico blog: https://blogs.technet.com/b/davidcervigon/archive/2009/03/05/c-mo-evitar-que-dos-grupos-coincidan-en-el-mismo-nodo-de-un-cluster.aspx 

Comentaros también la posibilidad de limitar las VM a unos nodos concretos del cluster desmarcando los nodos como dueños posibles de la VM en el cluster:

Creo que para un solo post es suficiente ya hare otro sobre diseño de las redes de un cluster y el almacenamiento.

Espero que hayáis aprendido alguna cosa.

Un saludo a todos!