Hola a todos, en este articulo hablaremos acerca de configuraciones avanzadas de HA y algunas recomendaciones y buenas practicas.
En primer lugar debemos destacar que el factor más importante para que HA funcione correctamente es la comunicacion de lo que se conoce como HeartBeat. El HeartBeat es básicamente un ping que cada host realiza contra el Default Gateway (o la IP definida en el parámetro das.isolationaddress) y contra los demás hosts en el cluster.
Respecto al diseño de red definido en nuestra plataforma VMware, hay dos aspectos fundamentales relacionados con HA, que son la redundancia de red y la resolución de nombres.
Redundancia de red
El riesgo más comun en un cluster HA es que un host sea decladado como "Aislado" o "Isolated", lo cual por defecto provoca que las MV de dicho host sean apagadas. Este comportamiento permite que HA pueda reiniciar las MV's en otro host que se encuente funcionando correctamente. Escenarios con puntos unicos de falla (unico switch fisico, o unica NIC fisica para administración, etc.), pueden provocar situaciones en que un host sea declarado como aislado.
Debemos esforzarnos para que nuestro diseño de red evite situaciones en que nuestros hosts puedan ser declarados como Aislados en la red. Para esto, debemos asegurarnos de que existe una completa redundancia de la conexión a la Management Network (ESXi) o Service Console (ESX) de cada host en nuestra plataforma VMware. Esto lo podemos lograr de 2 formas:
- Configurar más de una VMNIC (Nic Virtual) en el vSwitch que contiene la Management Network o Service Console Este metodo utiliza NICs redudantes en una unica red. Es significativamente más simple al momento de configurar, pero es necesario asegurar de que hay redundancia en la red física (cada NIC del Teaming está conectada a un Switch fisico distinto), con el fin de evitar un evento de aislamiento en el caso de la caída, por ejemplo, de un Switch físico.
- Agregar una segunda Management Network o Service Console en un vSwitch separado, en una subred separada. Esta opción tiene una configuración más compleja, pero puede ofrecer mayores niveles de disponibilidad si cada vSwitch que contenga una Management Network o Service Console cuenta con al menos dos NICs en Teaming.
La Management Network o Service Console debe tener un Default Gateway que todos los hosts puedan alcanzar. Los Hosts utilizaran este Default Gateway para decidir si se encuentra o no aislado en la red. En caso de que la subred donde se encuentra la Management Network o Service Console no posee un Gateway, se deberia configurar el parametro avanzado de HA, das.isolationaddress (dirección de aislamiento), especificando una dirección IP que pueda ser alcanzada utilizando Ping.
Si se utiliza una segunda Management Network o Service Console en una subred separada, entonces se debe especificar una segunda dirección para aislamiento para la segunda subred con el parametro avanzado de HA, das.isolationaddress2 (Se pueden definir múltiples direcciones de aislamiento).
Si la red sufre de problemas de intermitencia, entonces se recomienda aumentar el tiempo de reacción ante falla, configurado por defecto en 15 segundos, aumentandolo con el parametro avanzado de HA das.failuredetectiontime. Este parametro se debe manejar con precaución, ya que al extender el tiempo por defecto, cuando un host falle, habrá que esperar mucho más tiempo para que el resto de los hosts restauren las MVs. Adicionalmente, VMware recomienda que este parametro sea configurado en 60 segundos (60000 ms) para una unica Management Network o Service Console con dos VMNICs, y al menos 20 segundos (20000 ms) si se usan dos Management Networks o Service Consoles separadas.
Por otro lado, se debe minimizar el numero de dispositivos de red entre los hosts, debido a que cada "salto" provoca pequeñas demoras o latencias en el trafico de HeartBeat.
Resolución de nombres
HA confia fuertamente en la resolución de nombres, por lo que cada host debe tener acceso a servidores DNS correctamente configurados, donde todos los hosts tengan registros hosts (A) que puedan ser resueltos por cada host. Se recomienda evitar el uso del archivo host local para la resolución de nombres, debido a que estos son propensos a errores, y su administración en Cluster cada vez más grandes se vuelve inmanejable con el tiempo.
Se recomienda fuertemente que el servicio de DNS sea redundante, para evitar falsos positivos en HA que puedan provocar un failover.
Recomendaciones adicionales
Adicionalmente a lo ya expuesto, se especifican las siguientes recomendaciones:
- Si se realizará alguna tarea de mantención en los dispositivos de red utilizados por los hosts ESX/ESXi en un cluster HA, o se realizará algun trabajo sobre la configuración de red de los hosts, se debiera deshabilitar temporalmente el monitoreo de los hosts en la configuración del Cluster, con el fin de evitar falsos positivos y posibles operaciones de failover.
- Personalizar la política de reinicio de las máquinas virtuales según las necesidades existentes. Esto mejora las opciones de que los servidores más críticos sean reiniciados exitosamente si el control de admisión no se encuentra habilitado, o si los recursos restantes luego de un evento de HA no son suficientes para encender todas las máquinas virtuales.
- Configurar alarmas en vCenter, con una advertencia por e-mail, que alerte cuando se ha producido un evento de HA.
- Respecto a puertos utilizados por HA, los siguientes puertos deben estar abiertos entre todos los hosts del mismo cluster. Cuando HA es habilitado en el cluster, estos puertos son abiertos automáticamente en el firewall de cada host, sin embargo, si existe algun dispositivo firewall (ya sea físico o virtual) entre los hosts, entonces estos deben ser configurados para que permitan el trafico por estos puertos:
- Puertos entrantes: TCP/UDP 8042-8045
- Puertos salientes: TCP/UDP 2050-2250
- Si el cluster está configurado con DRS, entonces hay que asegurarse que que todos los hosts utilicen exactamente los mismos nombres para los Port Groups utilizados por las máquinas virtuales. Si esto no se cumple, las operaciones de vMotion fallarán.
Para más información sobre recomendaciones VMware pueden revisar el KB1006421.
Espero que esta información les haya sido de utilidad. Saludos a todos!
0 comentarios:
Publicar un comentario