Alta disponibilidad de clústeres de servidores: DNS y conmutación por error

Alta disponibilidad La alta disponibilidad sigue siendo uno de los componentes más difíciles de un clúster, incluso a medida que la virtualización madura. El clúster de servidores puede iniciar una alta disponibilidad, que es una función de hipervisor que limita el tiempo de inactividad cuando una máquina virtual falla. VMware vSphere, Microsoft Hyper-V y Citrix XenServer ofrecen capacidades de alta disponibilidad que mitigan las tareas de recuperación de desastres en la infraestructura virtual.

Demasiadas personas implementan proyectos de virtualización sin entender la alta disponibilidad. Para empeorar las cosas, el administrador ignoró la alta disponibilidad durante la implementación del clúster de servidores, lo que llevó al descubrimiento de que cambió de una solución a un problema a un problema que debe resolverse.

De hecho, el rendimiento de alta disponibilidad resuelve algunos de los problemas. Es un servicio simple que reinicia una máquina virtual después de una falla del host, sin importar qué hipervisor utilice. La disponibilidad continua es un objetivo ideal, pero las máquinas virtuales aún experimentan algún tiempo de inactividad.

La alta disponibilidad generalmente está relacionada con la migración en caliente, como XenMotion, vMotion, pero no lo es. He visto muchos problemas en el clúster de servidores después de la primera falla del host, debido a la confusión entre los dos Concepto

La tecnología de alta disponibilidad se está volviendo más inteligente, pero tenga en cuenta que los siguientes problemas pueden bloquear su clúster de servidores.

Cómo afecta el DNS a la alta disponibilidad

En combinación con VMware HA, la resolución del Servidor de nombres de dominio (DNS) puede convertirse en un problema grave. Para permitir que los nodos del clúster del servidor se comuniquen entre sí, VMware es responsable de la resolución de DNS. Por lo general, esto no es un problema. Pero hoy en día muchas personas de TI están acostumbradas a que DNS sea un concepto de servicio, sin necesidad de administrar.

Parte de la razón de esta política de no intervención son las capacidades dinámicas de DNS de Windows. Muchos administradores no toman el DNS en serio como lo hacían antes, porque el DNS dinámico ahora automatiza la mayoría de las tareas. Pero los servidores VMware no usan DNS dinámico.

Si usa VMware HA en un clúster de servidores, asegúrese de que la dirección IP de la red de administración y los nombres de host asociados estén todos en DNS. Realice cambios o agregue adjuntos al entorno virtual. Se requiere operación manual y mantenimiento. Si el DNS no está configurado correctamente, VMware tendrá sugerencias obvias, pero es fácil ignorar este aviso si se encuentra demasiado tarde.

La resolución de DNS en un clúster de servidores de varios sitios

Los problemas de resolución de DNS también pueden afectar a los clústeres de múltiples sitios de Hyper-V. El servicio de clústeres de conmutación por error de Windows de Hyper-V ahora abarca subredes. De alguna manera, esta arquitectura es buena porque ya no necesita usar tecnologías de red complejas para administrar en diferentes ubicaciones. Por otro lado, las máquinas virtuales que realizan una conmutación por error al segundo sitio generalmente necesitan procesar nuevas subredes.

Esto no es un gran problema desde el lado del servidor, pero causa problemas para el cliente. El cliente está configurado con un valor de tiempo de vida que determina el tiempo que tarda en almacenar en caché los informes de DNS. Estos informes son obsoletos después de la conmutación por error. En la recuperación de desastres físicos, por lo general no es un problema, ya que es posible que tenga que lidiar con problemas más importantes, como "¡El centro de datos está fallando!" Pero en una arquitectura virtual, cuando una máquina virtual migra accidentalmente a otro sitio reemplazable, Hubo un problema.

Los problemas de alta disponibilidad no aparecen específicamente en los clústeres de Hyper-V. Los clústeres de servidores que inician la recuperación de desastres para máquinas virtuales en diferentes subredes experimentan problemas similares.

Importancia de los comandos de conmutación por recuperación

El problema del DNS resalta el hecho de que el comando de recuperación es importante en la administración del clúster de servidores. Algunos comandos de recuperación de fallas de organización de clústeres de servidores son mejores que otros. Por ejemplo, VMware HA permite que el clúster del servidor maneje los comandos de failback. Otros, como Hyper-V, los administradores determinan manualmente dónde migrará la máquina virtual después de una falla.

Lo que no desea ver es que la máquina virtual se traslada a un nodo de clúster de servidor inapropiado, como al otro extremo del clúster de múltiples sitios, o a un nodo sobrecargado. Preste especial atención a sus comandos de recuperación de fallas para garantizar una carga de clúster equilibrada.

¿Qué debo hacer con el aislamiento del host?

El aislamiento del host se produce cuando el host del clúster del servidor todavía está en línea, pero ya no puede comunicarse con otros nodos. El problema con el aislamiento del host es que el host aislado todavía ejecuta la máquina virtual. En los eventos de cuarentena de VMware HA, estas máquinas virtuales normalmente se ejecutan en diferentes conmutadores virtuales sin verse afectadas por la cuarentena. El clúster puede querer recuperar estas máquinas virtuales fuera de la cuarentena, pero no se puede lograr si un host aislado carece de los archivos de disco de la máquina virtual.

Hay varias formas de solucionar este problema. Obviamente, es mejor recordar el host aislado nuevamente en línea. Pero si no puede hacer esto, debe apagar la máquina virtual y dejar que los nodos de clúster sobrevivientes pasen por alto las máquinas virtuales. Preste atención a la configuración de respuesta de aislamiento de la solución de alta tecnología para determinar qué configuración satisface sus necesidades específicas. Muchas características le permiten optar por continuar ejecutando o apagar una máquina virtual cuando el host está aislado.

La alta disponibilidad es un componente útil en la infraestructura virtual, pero no evita las configuraciones importantes en el clúster de servidores para administrar el balanceo de carga. De lo contrario, habrá muchos problemas difíciles.