Una mirada profunda a vCenter High Availability

vCenter High Availability (VCHA) se presentó en vSphere 6.5 en noviembre de 2016. Desde entonces, el Equipo Técnico de Mercadotecnia ha invertido mucho tiempo creando contenido y hablando sobre VCHA.

Gran parte de ese contenido se puede encontrar en vSphere Central. Incluso con todo ese contenido, todavía hay algunas preguntas comunes y conceptos erróneos con respecto a esta característica. En esta publicación analizaremos las diferencias entre la implementación básica y la avanzada, las consideraciones de implementación y los aspectos operativos de VCHA.

Básico vs Avanzado

Una de las preguntas más comunes que recibimos y los conceptos erróneos de los que hemos encontrado es que, para obtener todas las características de VCHA, necesita implementar usando el flujo de trabajo avanzado. Esto es absolutamente falso. De hecho, VCHA es exactamente el mismo independientemente de cómo se implemente. Recomendamos encarecidamente que utilice Básico para implementar VCHA si es posible. Creemos que en retrospectiva, puede haber sido mejor llamar a estos como "Automatizados" (Básicos) y "Manuales" (Avanzados).

Con Básicos VMware vCenter hace la configuración por usted: agregando la segunda tarjeta de red virtual, clonando, redimensionando el "Witness VM" y configurando las reglas anti afinidad de el Distributed Resource Scheduler "DRS".

Con la configuración avanzada, debe hacer todo ese trabajo manualmente. Además, digamos que necesita hacer algo que requiera la destrucción del clúster de VCHA, como cambiar certificados, cambiar la IP de vCenter Server o restaurar vCenter Server. Si utilizamos el flujo de trabajo avanzado para configurar VCHA, entonces tenemos que rehacer bastante. Si se usó Básico, puede hacer que VCHA vuelva a funcionar tras 30 segundos de trabajo.

Tal vez piense: "Ok, entonces, ¿cuándo debo usar Advanced?". Advanced está ahí en el caso de que vCenter Server se esté ejecutando en un clúster de administración que se encuentra en un dominio de Single Sign On (SSO) diferente. Por ejemplo, supongamos que tenemos un Compute vCenter en un dominio de SSO, pero vCenter se ubica en el inventario del dominio de administración de vCenter y SSO de administración, que necesitaremos para usar la implementación avanzada.

Si ese Compute vCenter Server está en el mismo dominio de SSO que el vCenter Server de gestión en el que está habilitando VCHA, puede utilizar Básico. Una razón final por la que puede considerar usar Advanced es si va a dividir sus nodos VCHA en diferentes sitios. Ahondaremos más acerca de esto en un momento.

La clave es que muchos clientes deberían poder usar Básico y no tener que lidiar con el trabajo manual del flujo de trabajo avanzado. Recuerde que el resultado es el mismo. VCHA es VCHA independientemente de cómo se implemente, por lo que no asuma que necesita usar Advanced.

Protección de vCenter Server con VCHA

Este tema es probablemente el que paso más tiempo cuando hablo con los clientes. Este es un tema algo complicado, así que trataré de dividirlo en partes consumibles. Primero, probemos y comprendamos las fallas que VCHA nos está ayudando a proteger. Una conmutación ejecutada por VCHA propiciada por una falla en el vCenter desde el nodo Activo a Pasivo, puede realizarse una recuperación debida a las siguientes fallas:

• Falla completa del host
• Aislamiento de la red
• Fallas de almacenamiento
• Falla en el servicio o de la aplicación vCenter Server en sí mismo
• Falla del sistema operativo de vCenter (Photon 1.0)

Dados las posibles fallas enumeradas aquí arriba y la capacidad de VCHA para recuperarse de ellos, VCHA puede ser una solución sólida de Alta Disponibilidad (HA) sólida para vCenter Server. Sin embargo, hay un elemento adicional que quizás se esté preguntando:

¿Qué sucede si tiene varias ubicaciones y desea proteger vCenter Server de una falla completa del sitio? Bueno, esto es de hecho posible pero con algunos puntos a tomar en cuenta. El punto más importante que se debe tener en cuenta al usar VCHA para proteger vCenter Server de una falla en el sitio, es que VCHA es en gran medida una solución de Alta Disponibilidad y no de Recuperación de Desastres.

VCHA, si está configurado correctamente, recuperará su dispositivo vCenter Server a un nodo alternativo que se ejecuta en otra ubicación. Sin embargo, todas las cargas de trabajo y "hosts" permanecerán en el sitio fallido sin alguna otra orquestación para Recuperación de Desastres. Por lo tanto, recomendaríamos utilizar una estrategia de orquestación de Recuperación de Desastres completa para proteger vCenter Server de las fallas del sitio en lugar de solo VCHA.

Algunos otros puntos importantes son, que existe el requisito de tiempo de ida y vuelta (Round Trip Time) de 10 ms entre los tres nodos, junto con la comprensión de los impactos de la red de VCHA. Si no hay un a red Capa 2 "alargada" (ya sea a través de una tecnología convencional como Overlay Transport Virtualization (OTV) de Cisco o una superposición como Virtual Extensible LAN o VXLAN), entonces la dirección IP de vCenter Server debe cambiar durante un evento de conmutación producida por un error o "failover".

Con VCHA esta parte está automatizada para usted, pero lo que no está automatizado es el Servidor de Nombre de Dominio o DNS. El "Registro A" de vCenter Server está controlado por el servicio DNS que se esté utilizando en su entorno y evento. Si puede automatizar la actualización de ese "Registro A" en la nueva dirección IP, aún existe la posibilidad real de que haya problemas transitorios debido a el "Time To Live" o DNS TTL, la propagación y el almacenamiento en caché.

Es posible que estos mecanismos transitorios de DNS incluso puedan impedir que su nodo pasivo se inicie correctamente, lo que hace que nos parece que esto no se trate de una solución de HA en primer lugar.

Si ha ampliado las redes L2 entre los sitios, esto no se debe debatir, ya que puede evitar la necesidad de cambiar la dirección IP de vCenter Server, así como el registro DNS durante una conmutación provocada por en error.

Recuerde también que para dividir los nodos entre los sitios, debe usar el flujo de trabajo Avanzado. Esto significa que cada vez que actualice, reemplace certificados o necesite volver a implementar el clúster de VCHA, tendrá que desmontar y clonar manualmente las máquinas virtuales, moverlas a donde necesiten ejecutarlas, cambiar el tamaño del testigo y volver a configurar todo las reglas para Distributed Resource Scheduler. Es mucho trabajo, así que vale la pena tenga esto en cuenta por adelantado.

Sin embargo, hay un escenario en el que creemos que la división de los nodos de VCHA en diferentes sitios puede funcionar. Si está ejecutando VMware vSphere® Metro Storage Cluster (vMSC), entonces la configuración es mucho mejor para VCHA. La conectividad Capa 2 entre los sitios es un requisito para los clústeres así como para el almacenamiento vMSC.

Esto hace que sea mucho más fácil obtener los nodos donde necesitan ir y no es necesario agregar la complejidad de un cambio de IP y DNS. Puede reconfigurar sus reglas de Distributed Resource Scheduler para que los nodos estén anclados a ciertos grupos de host en cada lado. Sin embargo, aún necesitará usar el flujo de trabajo avanzado en este escenario porque necesita un tercer sitio para la Máquina Virtual Testigo (Witness VM) y usar el flujo de trabajo avanzado es la única forma de que el ésta llegue a ese tercer sitio.

La única excepción es si tiene un tercer sitio que haya "estirado" la Capa 2 de los otros dos sitios. De lo contrario, aunque suene más simple, todavía tiene algo de trabajo para usted.

Conclusión

Recuerde: vCenter High Availability es una solución de Alta Disponibilidad y no una solución de Recuperación de Desastres. Esto se evidencia por el hecho de que VCHA solo protege al vCenter Server y no las cargas de trabajo o los hosts físicos en donde éstas se ejecutan. También hay una buena cantidad de trabajo para que la configuración de VCHA funcione en todos los sitios, así como un esfuerzo operativo adicional para mantenerla, por ejemplo: tener que usar el flujo de trabajo avanzado.

Al implementar VCHA intente usar el flujo de trabajo Básico siempre que sea posible, para que la solución sea más fácil de mantener e implementar. Proteja vCenter Server dentro de un sitio ya que es mucho más probable que sufra una falla de hardware, red o almacenamiento que una falla total del sitio.

En otra entrada de este Blog Tecnológico, hablaremos más sobre algunos de los aspectos operativos, como copia de seguridad y restauración, parches y actualizaciones al clúster de VCHA.