Introducción

Este capítulo está dedicado a la alta disponibilidad. Su objetivo es describir las posibles ofertas en términos de alta disponibilidad con Windows Server 2016. Aumentar la disponibilidad de los servicios que se ofrecen es un reto permanente en cualquier departamento informático.

Existen una serie de factores que favorecen esto:

Homogeneizar los servidores que se basan en una instalación y una configuración idénticas (véase el capítulo Despliegue de servidores y puestos de trabajo).
Centralizar la configuración por GPO (consulte el capítulo Dominio Active Directory).
Salvaguardar y mantener actualizados los servidores (consulte el capítulo El ciclo de vida de su infraestructura).
Replicar los archivos ofimáticos (consulte el capítulo Arquitectura distribuida de acceso a los recursos).
Duplicar los servicios de infraestructura de red (controladores de dominio, servidores DNS, DHCP...).
Utilizar la versión Core de Windows Server 2016 para limitar los tiempos de indisponibilidad debidos a instalaciones o actualizaciones de seguridad.
Virtualizar el servicio y hospedar la máquina virtual en un clúster Hyper-V.

Una vez llevadas a cabo todas estas acciones, algunos servicios críticos siguen dependiendo de un servidor único que, tarde o temprano, fallará o será necesario reiniciar tras haber instalado algún...

Elecciones de arquitectura

1. Las distintas arquitecturas

Tras los términos de alta disponibilidad se esconden dos tipos de soluciones distintas:

Soluciones de tipo activo/pasivo.
Soluciones de tipo activo/activo.

La primera solución aumenta la disponibilidad del servicio haciendo bascular los recursos de un servidor a otro en caso de existir algún problema (solución altamente disponible). La segunda solución permite tener varios servidores que responden a las solicitudes al mismo tiempo (reparto de carga) y que pueden tolerar la pérdida de algún miembro (solución altamente disponible).

Las soluciones de tipo activo/activo pueden parecer, a primera vista, más interesantes, aunque son, generalmente, mucho más complejas y deben considerarse para dar respuesta a un problema concreto de reparto de carga. En un entorno Microsoft, las soluciones son las siguientes:

Solución activo/pasivo: clúster de conmutación por error (MSCS - Microsoft Cluster Service).
Solución activo/activo: clúster de reparto de carga de red (NLB, Network Load Balancing).

Una aplicación destinada a los usuarios debe ser compatible con una solución de alta disponibilidad. Dejando a parte los "grandes" desarrolladores de software, es habitual que un proveedor de aplicaciones no haya probado, jamás, su aplicación en un entorno de alta disponibilidad y que no pueda, por tanto, asegurar su funcionamiento. Como mínimo, cabe analizar los siguientes puntos:

¿Puede residir el conjunto de datos en volúmenes compartidos y, por tanto, diferentes a las unidades locales C:, D...?
¿Deben replicarse algunas claves de registro entre ambos servidores?
¿La aplicación utiliza algún dispositivo de protección física (dongle instalado en un puerto USB o paralelo, por ejemplo) o se requiere una conexión física que no se puede duplicar ni conectarse sobre dos servidores?
¿Los clientes pueden utilizar un nombre NetBIOS/DNS y una dirección IP distintos del de la máquina física (nombre/IP virtuales)?
¿Cuáles son los mecanismos para detectar un fallo en la aplicación y decidir bascular al otro nodo?

Caso 1: solución activo/pasivo

Un único servidor hospeda un mismo recurso en un momento determinado. No existe ninguna necesidad de sincronizar...

Reparto de carga (clúster NLB)

El reparto de carga resulta indispensable cuando no basta con un único servidor para gestionar toda la carga de la aplicación o mantener unos tiempos de respuesta aceptables. Si no existen requisitos suplementarios de disponibilidad, se recomienda agregar, en primer lugar, recursos hardware al primer servidor antes de considerar una solución con varios servidores.

El reparto de carga no supone una capacidad de carga lineal. Si un servidor es capaz de dar servicios a 200 usuarios, dos servidores no tienen por qué, necesariamente, ser capaces de dar servicio a 400 usuarios. Todo va a depender de la naturaleza de la carga y del comportamiento de las sesiones TCP generadas. La noción de afinidad permite conservar a un usuario sobre el mismo nodo mientras dure su interacción. De este modo, se disminuyen los cambios de sesión de usuario sobre los servidores. Para ello, la granja calcula un hash a partir de la dirección IP del cliente y su destino. Si todos los clientes se presentan con la misma dirección IP (por ejemplo, cuando se ubican tras un firewall con reglas NAT), serán redirigidos hacia el mismo servidor, anulando, de este modo, el reparto de carga.

El reparto no se realiza en función de la carga de los servidores. Si algunos usuarios saturan uno de los nodos, seguirá recibiendo el mismo número de usuarios que los demás nodos. Si la carga entre los nodos no es del todo uniforme, deberá desarrollar una rutina encargada de drenar los nodos a partir de cierta carga.

1. Requisitos previos de una solución NLB

Si bien la instalación de la funcionalidad de reparto de carga de red es sencilla, conviene respetar ciertos requisitos previos para obtener el mejor rendimiento posible. La primera etapa consiste en instalar las últimas actualizaciones del sistema operativo. En efecto, sería una pena hacerlo justo una vez puesto en producción el clúster... si bien no debería producirse ninguna parada del servicio en este caso.

Los servidores que participan del clúster no deben ser controladores de dominio. No obstante, es necesario que sean miembros del mismo dominio Active Directory y que estén en la misma subred para un clúster NLB monositio.

Es posible implementar un clúster NLB en multisitio, pero es necesario que la latencia de red entre los sitios...

Clúster de conmutación por error

La tecnología de clúster de conmutación por error tiene un enfoque distinto al de NLB. Su objetivo consiste en mantener los recursos en línea de forma permanente e ininterrumpida. Cada recurso se instancia sobre un único servidor a la vez, aunque varios servidores pueden estar activos al mismo tiempo sobre recursos diferentes. Para garantizar un buen funcionamiento, la capa de clúster verifica una serie de puntos:

¿Funcionan la dirección IP y el nombre virtual?
¿Funciona el acceso al almacenamiento?
¿El nodo es capaz de comunicarse con los demás nodos (no está aislado)?
¿Los servicios que hay que mantener activos son funcionales?

Si se detecta algún incidente sobre alguno de los puntos anteriores, el clúster bascula el conjunto de recursos necesarios para el funcionamiento del (de los) servicio(s) sobre otro nodo.

Como mínimo, un clúster posee al menos un grupo (el ”grupo clúster”) que contiene:

Una dirección IP virtual.
Un nombre virtual.
Potencialmente, un volumen que forma parte de un quórum, o un disco testigo.

Windows Server 2012 R2 añade una funcionalidad, Directory-Detached Cluster, que permite crear un clúster para bascular la carga sin crear una cuenta de equipo para el clúster en Active Directory, pero los nodos deberán pertenecer al dominio y estar en la misma subred.

Windows Server 2016 va más allá en las posibilidades de construir un clúster, porque los nodos ya no tienen obligación de estar en el mismo dominio o ser miembros de un dominio:

Single-domain cluster: esto se corresponde con la construcción habitual de un clúster, es decir, todos los nodos en el mismo dominio Active Directory y en la misma subred.
Multi-domain cluster: los nodos que componen el clúster provienen de dominios Active Directory diferentes. Los dominios Active Directory deben tener una relación de aprobación entre ellos.
Workgroup cluster: todos los nodos del clúster están en un grupo de trabajo (por tanto, no relacionados con un dominio).
Mixed cluster (Workgroup y Domain cluster): unos nodos pueden venir de un dominio y otros pueden estar en un grupo de trabajo.

La creación de un clúster sin cuenta de equipo en Active Directory bloquea el uso de la autenticación...

Conclusión

Ahora, conoce las ventajas e inconvenientes de una solución de alta disponibilidad y/o de reparto de carga. Tiene las cartas en su mano para preparar su solución y gestionarla una vez puesta en producción. Como con muchas otras soluciones, no debe esperar a tener alguna necesidad tecnológica concreta (una caída de algún servidor, por ejemplo) para validar su buen funcionamiento. Debe planificar pruebas de forma regular, con el objetivo de asegurar su correcto funcionamiento del día D. A diferencia de la mayoría de proyectos, es precisamente si ningún usuario se da cuenta de nada (comportamiento transparente), cuando podremos decir que el proyecto ha sido un éxito.

Alta disponibilidad