Dominios de fallo en Hyper-V R2 SP1 y cosas que tienes que conocer sobre los clusters

 

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!