VCAP – Sección 4 – implementar y manejar soluciones complejas de HA

Que tal gente, vamos a continuar con las serie de estudio para VCAP, esta vez nos toca hablar de HA , las distintas configuraciones complejas o mas que complejas en mi punto de vista configuraciones especificas como controles de admisión, tamaños de slot ,etc.

Identificar los tres tipos de control de admisión

Para empezar vamos a aclarar el concepto de que es admission control, vCenter es el encargado de asegurarse que en el caso de un evento de falla (caida de un servidor sea por harware , red, etc) se cumplan con los recursos necesarios para poder iniciar las VMs afectadas.

  • Host Failures – en este mecanismo para el control de admisión se utiliza un concepto llamado “slot size”, este slot size es una división lógica de los recursos de un cluster para poder en base a este, garantizar suficientes recursos en el caso de una falla. El tamaño de este slot size se calcula en base a la reservación de CPU y de RAM más grande que una VM  tenga en el cluster (teniendo en cuenta que el mas restrictivo será en el cual se basará) Ej.


Tenemos un cluster con 3 Hosts ESX, cada uno con los recursos que se tienen en esta imagen, nuestra VM de mayor tamaño

tiene reservado 2 GHZ de CPU y 4 GB de memoria RAM. El tamaño de slot que tendríamos en este cluster sería de 2GHZ y 4GB

de RAM + Overhead.

 

Es importante tener en cuenta que en el caso de no tener reservaciones de CPU y/o RAM para el cálculo del tamaño de nuestro slot HA se basará en el valor mas alto de overhead que una VM tenga, y por default el tamaño de slot de CPU seria de 256 mhz. Recordemos que el overhead de memoria es la cantidad de memoria que el vmkernel requiere para poder virtualizar dicha VM:

¿Porque es importante el termino de slot size?

Cuando nosotros tenemos configurado Host failures para nuestro cluster de HA, el host con mayor cantidad de “slots” será tomado como referencia en el caso de falla, es decir, si en nuestro cluster se presenta una falla HA tiene que asegurarse que se cuentan con la cantidad de slots necesarios para cubrir el host con mayor cantidad de slots (esto pensado en el caso que el host mas grande fallara).

Ej.

Nuestro cluster anterior tomando en cuenta que nuestra VM mas grande tiene 2GHZ de CPU reservados y 4GB de RAM reservados y utilizando un ejemplo de tener 2 vCPUs tendríamos un overhead de 242.51 MB de RAM, por lo cual nuestro slot seria de 2 GHZ y 4338 MB de RAM (siendo la cantidad de slots de Memoria mas restrictivos por lo cual se toman como referencia):

En este caso si nosotros configuramos  HA para tolerar una falla de 1 host se tomaría como referencia el host de mayor tamaño (14 slots) y los hosts que siguen funcionales deben ser capaces de cumplir con la cantidad de recursos de este host. Es por eso que muchas veces nos encontramos con errores como el siguiente:

En el caso que los hosts no cumplan con la cantidad de slots necesarios para poder contener las VMs que fallaron junto con el o los hosts caídos. Es por eso que como mejor practica debemos considerar tener servidores con la misma cantidad de recursos en cuanto a CPU y RAM se refiere.

Un punto muy importante que debemos tener en cuenta siempre que comenzamos a configurar nuestras VMs es el hecho de ser conservadores con las reservaciones, debido a que recordando que HA toma la reservación más alta para realizar el cálculo de slots y en el caso de tener un tamaño de slot muy grande nuestra capacidad para consolidar será mucho mas conservadora.

Existe momentos en los cuales nosotros queremos encender una VM y el vCenter nos da un aviso en el cual se nos dice que no se cuentan con los recursos para encender dicha VM, esto pasa cuando los recursos se encuentran segregados en el cluster. vamos a ver un ejemplo:

En este ejemplo tenemos una VM con 2 GHZ CPUy 16 GB de  RAM

Se presenta una caída en el servidor donde residía esta VM, en dicho servidor la VM estaba ocupando

4 slots para poderse ejecutar. Por lo cual no se puede encender, esto sucedería igualmente en el caso

de tratar de iniciar dicha vm si estuviera apagada.

 

  • Percentage of cluster resources reserved – este método para el control de admisión se incluyo con vSphere, básicamente aquí nosotros diremos que cantidad de recursos (del total en el cluster) queremos asegurar en el caso de presentarse la caída de uno o mas hosts. Se calculan los recursos totales que tenemos el cluster, después se le restan los recursos reservados por VMs y esto se divide entre el total de recursos totales, el resultado de esta operación nos dará el consumo actual de recursos en nuestro cluster. Vamos a ver un ejemplo:

En este caso tenemos si nosotros configuramos nuestro cluster con un 20% reservado de recursos HA realizaría los siguientes cálculos

para poder estar constantemente verificando si se viola ese porcentaje ( En este ejemplo

se tiene 1 vCPU por VM, teniendo un overhead de 165.98MB para las VMs con 4GB de RAM y 334.96MB para la VM de 16GB):

( 32 GHZ– 12GHZ)/32GHZ= 62.5%  de CPU disponible

(64GB – 38GB)/64GB=  ~40.6% de RAM disponible

En este caso todavía  no llegamos al límite de un 20% por lo cual podríamos ser capaces de encender VMs sin problemas.

 

En el ejemplo anterior todas las VMs tenían reservaciones tanto de CPU  como de RAM, en el caso que no se tuviera ninguna reservación se calcula el valor default de 256 Mhz de CPU y el overhead que tiene cada una de las VMs. Es por eso que debemos de considerar nuevamente nuestras reservaciones, y también para configurar un porcentaje de recursos debemos tener en cuenta la VM de mayor tamaño y claro esta configurar las prioridades de inicio de VMs para que el porcentaje de recursos garantizados sea capaz de cumplir con aquellos requerimientos de nuestras VMs mas criticas.

  • Specify a failover Host – este es el ultimo “mecanismo” para el control de admisión, me refiero a este método como “mecanismo” debido a que es el simple hecho de definir host que estará en stand-by recibir VMs en el caso de alguna falla de uno o mas hosts en el cluster. Este método esta pensado para aquellas empresas que por regulación requieren tener hardware en stand-by para catástrofes.

Identificar opciones de Heartbeat y dependencias

Por Heartbeat entendemos la comunicación que se tiene entre los hosts que conforman un cluster de HA, el agente de HA (AAM) se comunica con todos los demás agentes en los distintos servidores ESX, esta comunicación se realiza entre nodos primarios y nodos secundarios, en cuanto se pierde la comunicación después de 15 segundos se comienzan las acciones de failover.

¿Qué opciones tengo para proporcionar redundancia?

  • Redundancia del heartbeat network con nic teaming – en el caso de ESX este heartbeat network será el service console y en el caso de ESXi es el management network.
  • Agregar un segundo portgroup para el heartbeat – en el caso que nosotros quisiéramos configurar un portgroup adicional para la comunicación de heartbeat esto es posible, simplemente en los parámetros avanzados de HA ingresamos la línea  “das.allowNetwork#” y en el campo del valor introducimos el nombre del portgroup a utilizar:

  • Utilizar redes de VMotion – podemos configurar una opción avanzada para permitir a los hosts que forman parte de nuestro cluster utilizar NICs que han sido asignadas para el trafico de VMotion, esto lo logramos con el parámetro “das.allowVmotionNetworks”:

Calcular la cantidad de fallas de hosts en nuestro cluster HA

Básicamente en este caso estaríamos hablando del primer método de admisión, lo que tendríamos que hacer seria calcular el tamaño de nuestros slots. Para saber hasta que número mínimo de hosts podrían soportar la carga completa de las VMs que estamos ejecutando, siempre manteniendo prioridades de re inicio según la criticidad de las VMs.

Desde la versión 4.1 de vSphere se agrega información de nuestro cluster, donde podemos ver el tamaño de nuestros slots:

Configuración de “isolation response”

Tenemos tres respuestas de nuestros hosts en el caso que se pierda la comunicación (heartbeat) con los demás hosts del cluster:

  • Power off – se realizara un apagado de la VM, pero en este caso se realiza un “hard stop”. El problema que tenemos aquí es la posibilidad de corrupción de datos.
  • Shutdown – el apagado de las VMs se realiza a través de las VMware tools, por lo cual se trata de un “clean shutdown” debido a que es un apagado desde el sistema operativo. Por default se esperará 5 minutos a que dicha VM se apague, en caso contrario se realizara un power off de la misma.
  • Leave powered on – en este caso las VMs continuaran ejecutándose. Esta opción nos puede ayudar para prevenir falsos positivos en el caso de almacenamiento ip.

En el caso de utilizar “leave powered on” y que algún host este marcado como “isolated” , los demás hosts del cluster solo podrán realizar el reinicio de VMs en el caso que dicho host este en verdad fuera de servicio, es decir, que no solo se haya perdido la comunicación de heartbeat. Esto debido al lock que cada host crea en los vmdks de las vms.

En la versión 4 update 2 de vSphere ya no sufrimos de un evento conocido como “split brain” en el cual un host se ha marcado como “isolated” debido a que se perdió la comunicación de heartbeat con el, pero en realidad este host continuaba arriba y tenia acceso al almacenamiento y continuaba ejecutando la vm y como los demás nodos del cluster tenian a dicho host como isolated intentaban iniciar las VMs y se creaba un efecto de ping pong entre los hosts. En la versión 4 U2 los hosts ESX/ESXi  en el momento que en verdad se haya perdido comunicación con el almacenamiento se darán cuenta que el lock en el VMFS se ha perdido por lo cual ellos automáticamente realizaran un “power off” de las VMs para prevenir esta situación de split brain. Por lo cual si nosotros manejamos una versión de vSphere anterior al update 2 es recomendable configurar el isolation response de “power off”.

Tenemos algunas opciones avanzadas en cuanto a isolation response se refieren:

  • das.maxvmrestartcount – esta opción nos permitirá definir la cantidad de intentos que se realizarán para iniciar una VM en el caso que el host donde resida este marcado como isolated, por default es de 5, y en el caso que solo se haya perdido la comunicación de heartbeat pero el host continúe ejecutando la VM estos intentos fallaran debido al lock que se tiene sobre el vmdk.
  • das.failuredetectiontime – por default a los 15 segundos que un servidor no se ha comunicado a través de heartbeat con los demás nodos del cluster se comenzará el reinicio de las VMs. Este parámetro nos permite aumentar el tiempo en el cual se marca un host como fuera de servicio. Las mejores prácticas nos dictan configurar este parámetro a 20000 – 30000 (ms).
  • das.isolationaddress# – este parámetro nos permite configurar IPs adicionales para que nuestros hosts ESX/ESXi determinen si están fuera, por default para determinar que no tienen comunicación existe el heartbeat, en el caso que este se pierda, se realiza un ping a la gateway de nuestra service console. La IPs adicionales que configuremos deben de poder ser accesadas desde el portgroup de nuestro Service console o del portgroup adicional configurado para la comunicación de heartbeat (das.allowNetwork).

Configurar el tamaño de slot manualmente

En el caso que nosotros tengamos algunas pocas VMs que difieren de nuestra configuración estándar y debido a ellas el tamaño de nuestro slot se ve aumentado nosotros podemos ingresar parámetros avanzados de nuestro cluster para definir manualmente el tamaño de nuestro slot:

  • das.vmCpuMinMHz – define el tamaño mínimo de slot en CPU.
  • das.vmMemoryMinMB – define el tamaño mínimo de memoria del slot.
  • das.slotCpuInMHz – define el tamaño máximo que se podrá tener de slot para el CPU.
  • das.slotMemInMB – define el tamaño máximo de RAM para el slot.

Entender interacciones entre DRS y HA

En la versión 4.1 DRS y HA actúan de manera mas cercana, debido a que en el caso de la perdida de algún Host , HA podrá pedir a DRS que se trate de balancear un cluster para poder iniciar las VMs fallidas. Con balancear me refiero a tratar de consolidar los recursos esparcidos entre los hosts sobrantes para poder tener mayor cantidad de slots continuos libres, para que tengamos problemas de contar con los recursos pero que estos se encuentren esparcidos entre distintos hosts por lo cual no se puedan iniciar las VMs.

Con la versión 4.1 de vSphere en el caso que nuestro cluster tenga activado DPM y algunos hosts ESX/ESXi se encuentren en standby mode HA podrá solicitar a DRS que los hosts sean sacados de stanby mode para balancear el cluster y poder recibir la carga que se ejecutaba en los hosts fallados.

También con la versión 4.1 de vSphere, DRS normalizará cualquier configuración de shares especifica a las VMs que han fallado en algún host, ya que en el momento de realizar el re inicio de las VMs estas son colocadas en el resource pool “root” que viene siendo directamente el cluster con lo cual se podría tener una o varias VMs con un valor de shares claramente mayor o menor a las demás VMs. Cuando me refiero a “normalizar” quiero decir configurar el valor estandar de shares que es “1000”.

En el caso que se tenga una falla en nuestro cluster se tomarán en cuenta las reglas de afinidad y anti afinidad definidas en el cluster de DRS para el inicio de las VMs fallidas, por lo cual les recomiendo leer mi post anterior

VCAP – Sección 3 – implementar y mantener soluciones complejas de DRS

Crear soluciones de HA que aseguren una correcta distribución de nodos primarios entre sitios

Aquí básicamente debemos de tener en cuenta el diseño de nuestra arquitectura para observar posibles puntos de falla, en el caso de blade centers en un mismo enclosure podemos tener una cantidad grande de navajas (servidores) por lo cual nuestros nodos primarios podrían quedar alojados en un mismo enclosure lo que nos lleva a un problema muy grande, en el caso de la pérdida total de este enclosure se pierde también la capacidad de nuestro cluster para reiniciar VMs fallidas. Es por eso que debemos ir agregando servidores ESX/ESXi a nuestro cluster de manera bien pensada para poder distribuir los nodos primarios entre distintos enclosures (los primeros 5 hosts agregados serán primarios).

Nosotros podemos saber que hosts tienen el papel  de primarios utilizando una linea de comando del agente aam:

/opt/vmware/aam/bin/# ./Cli

AAM>ln

Tenemos otro método para determinar los roles de nuestros hosts

cat /var/log/vmware/aam/aam_config_util_listnodes.log

Duncan epping en su blog nos muestra un parámetro avanzado y uso del cli de aam para promover o decidir que nodos serán primarios, solo que estos no son métodos soportados por VMware.

  • das.preferredPrimaries – aquí podemos designar que hosts serán primarios (por FQDN o IP).

Para promover un nodo utilizando el cli de AAM

AAM>promoteNode esxi01

Para degradar un nodo primario a secundario

AAM>demoteNode esxi01

En el caso que nuestros nodos primarios ya estén decididos y se encuentren distribuidos de forma incorrecta podemos promover nodos secundarios con un métodos soportado por VMware.

  • Cuando ingresamos un nodo primari0 a modo mantenimiento, un nodo secundario es promovido.
  • Cuando removemos un nodo primario de nuestro cluster, un nodo secundario es promovido.

Analizar la capacidad de nuestro cluster HA para poder determinar su tamaño óptimo

Básicamente aquí solo queda tomar en cuenta los máximos que tenemos en la versión 4.1 para clusters de HA/DRS:

  • Hasta 32 hosts por cluster
  • Hasta 320 VMs por host.
  • Hasta 3000 VMs en un cluster.

Referencias:

http://www.yellow-bricks.com/vmware-high-availability-deepdiv/

http://www.vmware.com/files/pdf/techpaper/VMW-Server-WP-BestPractices.pdf

http://www.vmware.com/pdf/vsphere4/r41/vsp_41_availability.pdf

Leave a Reply