Bueno despues de varios posts cortos aqui va uno largo que llevo preparando tiempo.La documentacion de VMware acerca de VMware HA deja bastante que desear y realmente es un producto que muchas veces necesitas conocer más a fondo para resolver problemas que te encuentras, por eso veo necesario tener una pequeña guía (técnica) de cómo funciona VMware HA:
VMware HA monitoriza constantemente todos los ESX de un cluster y detecta las caidas de estos. En cada host hay un agente corriendo que mantiene el heartbeat con los demas hosts del cluster. La perdida del heartbeat inicia el proceso de reiniciar las maquinas virtuales en los otros hosts proporcionando de esta forma un fail over de las maquinas virtuales con una parada minima(downtime = tiempo de reinicio) de servicio.
Es importante resaltar que HA es reactivo, es decir actua cuando ocurre algo y NO usa Vmotion y DRS es proactivo: usa vmotion y actua para que no ocurra nada o para que no se de la situacion en la que pueda ocurrir.
El hecho de que las VMs se inicien en un host o en otro cambió en el VC2 y el VC2.1: El primero lo hacia alfabeticamente, es decir la VM se iniciaba en el siguente host alfabeticamente que tuviese recursos, en cambio en el VC2.1 el host que iniciara la VM sera el host que tenga mayor capacidad(sin reservar) para levantarla. Una vez que HA ha realizado el paso de VMs, el DRS entra en juego y verá si es necesario mover las VMs.
VMware HA no controla la caida individual de una VM, ésto puede tratarse con una alarma, ya sea con el Virtual Center o con un software de monitorizacion externo.
Arquitectura:
La creacion y administracion de los clusters de HA se hace a traves del VC. El servidor de administracion del Virtual Center instala un
agente en cada host del cluster de forma que cada host pueda comunicarse con los otros y mantener la informacion del estado de los hosts y poder asi decidir que hacer en caso de caida de otro hosts.
En cada cluster hay un host que es el
primario(suele ser el primero) que actua como controlador y es el que inica las accciones de failover. De hecho, cuando se introduce un nuevo nodo al cluster, éste ultimo necesita comunicarse con el primario para completar la configuracion. Si el nodo primario cae, HA inmediatamente promociona uno de los nodos a primario.
Actualmente AAM no permite mas de 4 hosts y el parametro de max number of failures se refiere al maximo numero de primarios que podria haber en un cluster.
- Cuando queremos quitar un nodo del cluster lo podemos poner en
Maintenance Mode y apagar las VMs o migrar
(vmotion) sus VMs (si DRS esta activado, éste nos lo propondrá o lo hara directamente).
- Cuando se añade un nuevo nodo al cluster, todas las VMs se ponen a
default: Restart Prioriy = Medium e Isolation Response = PowerOff
Nota: Para apagar temporalmente HA ponemos el ESX en maintenance mode y para apagar temporalmente DRS lo configuramos como partially automated.
El agenteVC
(vpxa) se comunica con las
VMs y VMAP (este ultimo contiene la lista de que hosts estan corriendo que VMs). El agente
AAM (HA agent) monitoriza AAM en otros hosts (heartbeat via red SC), para evitar el split brain cuando los nodos se quedan aislados, cada nodo tiene una direccion a la que hace ping para ver si esta aislado (option
das.isolationaddress ).
[Mas opciones avanzadas:
http://pubs.vmware.com/vi35/resmgmt/wwhelp/wwhimpl/common/html/wwhelp.htm?context=resmgmt&file=vc_cluster_das.10.9.html] Los requesitos para que funcione HA son:
- Capacidad de encender la VM desde cualquier host
- Acceso a recursos comunes(red, SAN)
- Resolucion de DNs en el cluster(tiene muchisima dependencia /etc/hosts y /etc/resolv.conf)
Parametros a Configurar:
Orden de reinicio de las VMs: Establece que prioridad de reinicio tienen las VMs. Se debe establecer a Disabled si no queremos que se use HA en dicha VM.
Admision Control: Aqui se prioriza el uptime o que las maquinas tengan sus recursos siempre.
Isolation response: Que hacer si se queda aislado el host: el power off de las VM liberará el lock de los discos.
Nota: Cuando se añade un nuevo nodo al cluser, todas las VMs se ponen a default: Restart Prioriy = Medium e Isolation Response = PowerOff
¿Que ocurre si el VC Server se cae?
El Virtual Center Management Server(servidor del VC) no es un unico punto de fallo porque si cayera el VC Server los clusteres de HA siguen pudiendo reiniciar las maquinas virtuales en otro host en caso de caida de uno de los hosts de forma que el
funcionamiento general sigue pero la informacion de que recursos estan disponibles será la del estado del cluster antes de caer el VC Server.
Si entramos con el VIC a un ESX y cambiamos algo mientra el VC esta caido entonces eso cambios si tienen efecto y cuando repongamos el VC los verá.(En cambio si el VC no esta caido y modificamos algo con el VIC a traves de un ESX , el VC no lo verá y tendrá desactualizado su
VMap etc...)
VMware HA esta continuamente monitorizando qué recursos hay para ser capaz de reiniciar las maquinas en diferentes hosts en caso de caida de uno de ellos. El agente AAM
se ejecuta en la service console de los hosts y mantiene una base de datos en memoria de los nodos del cluster usando los heartbeats para coordinar los nodos que estan activos y los que no (los que no son activos son los que estan sin red o en maintenance mode).
El hecho de que una maquina virtual pueda ser levantada en otro servidor ESX(host) es posible gracias a la tecnologia de
locking de la pila de almacenamiento del ESX que les permite a varios ESX acceder a un mismo disco simultaneamente.
¿Que ocurre cuando un host se cae? (Cronologia del Fail-Over)
Todo el proceso dura 15 segundos despues de que el host se quede aislado y no mande mas heartbeats:
t=0s: Un host deja de tener conectividad(o se queda aislado en la red) y deja de mandar heartbearts. El nodo intanta hacer pings a la isolation address para ver si efectivamnete esta aislado.(la verification address es el
default gw de la interfaz de la service console, para cambiarla hay que cambiar el parametro
das.isolationaddress en advanced parameters). Si no puede hacer ping a su isolation address entonces el nodo sabe que esta aislado y no que los otros nodoas se han caido.
t menor que 12s: Si antes de 12 segundos vuelve la conectividad, todo vuelve a la normalidad. Los demas hosts marcaran al hosts con problemas de red
como activo y no pasará nada. El host
no se marcará a si mismo como aislado.
t entre 12s y 15s: El host se marca como aislado(isolated) y empieza a apagar sus maquinas para liberar locks(respuesta por defecto y configurable).
Si justo la conectividad vuelve en este momento las maquinas virtuales se apagaran(si esta conf por defecto) pero no se levantarán(reiniciarán) en otros hosts porque los otros no le han marcado todavia al host como caido(failed). El apagado de las maquinas es hard.
t=15s: Los demas hosts declaran el host como caido(
failed) y en consecuencia adquieren el lock de las maquinas virtuales y las levantan(si asi lo hemos configurado, si no la VM seguira corriendo en el host aislado y el mecanismo de locking prevendrá que no se inicie en otro sitio).
http://kb.vmware.com/selfservice/viewContent.do?language=en_US&externalId=2956923
¿Que ocurre si Current failover capacity != Configured failover capacity? (Red Cluster)
Esto ocurre cuando han fallado mas hosts que los previstos.
Las VMs con mayor prioridad haran el fail over las primeras. Para la version 3.02 de ESX y anteriores, el valor de HA Failover Capacity se calcula así: El valor de Failover Capacity está determinado por el valor del slot que tiene el cluster. El slot es calculado con una combinacion de la CPU y Memoria total que hay en los hosts.
Ejemplo:
Tenemos 4 hosts y el valor CONFIGURADO de Failover Capacity es 1 Los hosts tienen esta memoria: ESX1 = 16 GB
ESX2 = 24 GB
ESX3 = 32 GB
ESX4 = 32 GB
En el cluster tenemos 24 VMs configuradas y funcionando. De las 24, hay que determinar cual es la que mas "configured memory" tiene. Por ejemplo pongamos 2GB. Las demas tienen menos o igual a 2GB de memoria configurada. Con esto ya podemos hacer el cálculo:
1. Escojemos el host ESX que tenga menor memoria RAM intalada. En este caso es ESX1 y tiene 16 GB
2. Dividimos este valor por el mayor valor de la memoria RAM de nuestras maquinas virtuales(2GB en el ejemplo). Nos sale 8 (16 / 2). Esto significa que tenemos 8 slots disponibles(como minimo) en cada ESX.
3. Como tenemos 4 hosts y la failover capacity configurada es de 1, nos podriamos quedar con 3 hosts en la peor situacion(que cayera uno). Por ello el numero total de VMs que podemos encender en esos 4 hosts es 24 VMs. ( 8 slots x 3 hosts en el caso peor = 24 VMs)
4. Si el numero total de VMs excede 24 entonces nos dará: "Insufficient resources to satisfy HA failover" y el el valor de "current failover capacity" será puesto a 0. Si el numero de VMs encendidas es menor que 24 no obtendriamos este mensaje.
Nota: Si se sigue viendo el mensaje despues de bajar el numero de maquinas encendidas, chequea las reservations de CPU y Memory en las VMs y en los resource pools porque esto puede modificar el calculo. Se debe evitar reservations de CPU y memoria innecesarias en las VMs porque esto puede causar que ocurran estos tipos de errores dado que tenemos que asegurar que el recurso esta disponible.
Para que el Virtual Center deje de estar en una situacion en la que los recursos son insuficientes para satisfacer VMware HA posdemos hacer lo siguente:1.- Marcar "Allow Virtual Machines to be powered on even if they violate availability constraints" en la confiduracion del cluster. En este caso se ignoran los calculos anteriormente descritos y se intentará encender el maximo numero de VMs posibles en caso failover. Con esta opcion se puede establecer la restart priority (en "Virtual Machine Options") en la configuracion del cluster, de esta forma, las VM prioritarias seran encendidas antes y posteriormente las menos prioritarias hasta en punto en el que ya no se pueda encender ninguna VM más
2.- Si tenenmos una VM que tiene configuarada una gran cantidad de memoria, podemos o bien rebajar su memoria configurada o bien sacarla del cluster y ejecutarla en otro ESX standalone. Esto incrementará el numero de slots disponibles con el hardware que tenemos.
3.- Incrementar la cantidad de memoria en los servidores de forma que haya mas slots disponilbes con las reservatiosn de RAM actuales.
4.- Quitar las reservas de CPU en todas las VM que sean mayores que la velocidad maxima de los procesadores fisicos.
Nota: El calculo descrito arriba es muy limitado como se puede ver y va a ser revisado en las siguentes versiones del Virtual Center.
Troubleshooting:
- Conectividad
IP: pings desde todos a todos y con el nombre corto y el FQDN. Pings al VC server
- DNS!!!:
- Se pueden resolver los nombres cortos(sin el dominio) en cada ESX de los otros ESX
- El FQDN es menor de 29 caracteres?
- Mirar el /etc/hosts y /etc/resolv.conf poner en esos ficheros el "hostname.FQDN" tambien.
- Se puede editar el nsswitch.conf y cambiar: "hosts: dns files". Asi mira primero en dns y si estan caidos en local.
- Que la red y el almacenamiento sea visible por los nodos.
- Que no haya habido usuarios que hayan accedido con el VIC al host en concreto bypasseando al Virtual Center y hayan cambiado las reservations.
- Logs: /opt/LGTOaam512/log/* y /opt/LGTOaam512/vmsupport/* .
Principalmente aam_config_util_listprimaries.log (hosts primarios) y aam_config_util_listnodes.log
Errores y problemas tipicos:
"Could not find a primary host to configure DAS on" A host that was removed from the VC inventory still appears on the internal list of hosts for this cluster.
Workaround: create a new cluster and add hosts to this new cluster.
Resolved in ESX Server 3.0.1 and VC
2.0.1."Configuring HA failed" or "while using HA, the vm did not failover".Size of Fully Qualified Domain Name (FQDN) or short host name.
Workaround:
If the host short name is more than 29 characters, change the HOSTNAME entry in /etc/sysconfig/network to the shorter name.
If using an FQDN that is greater than 29 characters:
• Change the FQDN to less than or equal to 29 characters.
• Remove the existing cluster.
• Create a new cluster.
• Add all the hosts back to the cluster.
HA Configuration Fails Check DNS, FQDN
You have just added a new host to the cluster
• Check /opt/LGTOaam512/log/aam_config_util_addnode.log
• /var/log/vmware/vpx/vpxa.log
• In VC, right click on the host that shows the HA problem and click reconfigure for HA.
• Were all the hosts responding?
• If not –new host cannot communicate with any of the primary hosts.
• Solution:• Disconnect all the hosts that are not responding before you can add the new host.
• The new host becomes the first primary host.
• When the other hosts become available again, their HA service is reconfigured. ESX Server is running slowly.
Top command shows vmware-hostd using a lot of resources
vmware-hostd Uses a Lot of CPU or Has Generated a Core Dump Why DRS / HA cluster that contains VMs originally built on an ESX Server 2.x host.
Fix: To adjust resource allocation for vmware-hostd: For each VM, right click it and go to Edit Properties. Select Resources. Ensure you "touch" each CPU and memory resource:
• Restart hostd: type: service mgmt-vmware restart
• Set resources to the settings you want.
"HA service doesn't start up" or "HA error on the host, after booting successfully after host failure"Due to problem rejoining the rest of the cluster
Fix: use the ReconfigureHA task on the host to correctly configure the HA service on the host.
Deploying a VM from a template into a cluster, the updated BIOS settings are lost.Affects HA/DRS clusters but not DRS-only clusters.
Fix: Change the BIOS setting in the affected deployed VM.
Entradas
