Implementación de un testigo en la nube para un clúster de conmutación por error
El testigo en la nube es un tipo de testigo de cuórum de clúster de conmutación por error que usa Microsoft Azure para proporcionar un voto sobre el cuórum de clúster. Este artículo contiene información general sobre la característica de testigo en la nube, los escenarios que admite e instrucciones sobre cómo configurar un testigo en la nube para un clúster de conmutación por error. Para obtener más información, consulte Configuración de un testigo del clúster.
¿Qué es el testigo en la nube?
Antes de comenzar, debe recordar qué son los cuórums de clúster y los testigos de cuórum. Para ello, lea Descripción del cuórum de clúster y grupo.
Ahora, empecemos echando un vistazo a una configuración de ejemplo de un cuórum de clúster de conmutación por error extendido en varios sitios para Windows Server, que se muestra en el diagrama siguiente.
Este ejemplo es una configuración simplificada con dos nodos en dos centros de datos locales. En los clústeres típicos, cada nodo tiene un voto, un testigo de recurso compartido de archivos proporciona un voto adicional al testigo de cuórum. Este voto adicional permite al clúster seguir ejecutándose aunque uno de los centros de datos se desactive. En el ejemplo, el cuórum de clúster tiene cinco posibles votos y solo necesita tres votos para continuar ejecutándose.
Sin embargo, puede observar que, además de los dos centros de datos, también hay un tercer centro de datos denominado testigo de recurso compartido de archivos. Este centro de datos se mantiene separado de los otros dos sitios y hospeda un servidor de archivos que realiza una copia de seguridad del recurso compartido de archivos del sistema. El testigo de recurso compartido de archivos funciona como testigo de cuórum en esta configuración del cuórum de clúster, lo que garantiza que el sistema siga ejecutándose aunque uno de los centros de datos se apague inesperadamente.
Tener un testigo de recurso compartido de archivos proporciona redundancia suficiente para mantener la alta disponibilidad del servidor de archivos. Sin embargo, debe recordar que hospedar el testigo de recurso compartido de archivos en otro servidor de un sitio independiente requiere configuración, mantenimiento regular y conectividad independiente con los demás sitios.
El testigo en la nube es diferente de las configuraciones tradicionales del testigo de cuórum de clúster, ya que usa una máquina virtual de Azure en la nube como testigo de cuórum en lugar de un centro de datos físico. El testigo en la nube usa Azure Blob Storage para leer y escribir un archivo de blob que el sistema usa como voto decisivo para lograr el cuórum. En el diagrama siguiente se muestra una configuración de ejemplo que usa el testigo en la nube.
Como puede ver, las configuraciones del testigo en la nube no requieren un tercer centro de datos independiente. El testigo en la nube, como cualquier otro testigo de cuórum, obtiene un voto adicional y ayuda a evitar apagados totales si uno de los otros centros de datos se desactiva. Sin embargo, no necesita un sitio adicional para almacenar el testigo de cuórum. El testigo en la nube tampoco necesita el mantenimiento físico regular necesario para un centro de datos local.
Junto con la redundancia, hay otras ventajas para usar la característica de testigo en la nube:
No es necesario usar un centro de datos adicional independiente para lograr el cuórum.
El uso de Azure Blob Storage elimina la sobrecarga de mantenimiento adicional que suele ser necesaria para hospedar máquinas virtuales en la nube pública.
Puede usar la misma cuenta de Azure Storage para varios clústeres. Los únicos requisitos son que solo use un blob por clúster y asigne al archivo de blob el nombre del identificador único del clúster.
Reduzca los costos continuos de la cuenta de almacenamiento, ya que el archivo de blob no necesita muchos datos y se actualiza solo cuando cambia el estado del nodo de clúster.
Azure incluye un tipo de recurso de testigo en la nube integrado.
Requisitos previos
Debe tener una cuenta de Azure con una suscripción activa y una cuenta de almacenamiento de uso general de Azure válida para configurar el testigo en la nube. Es en esta cuenta de almacenamiento donde el testigo en la nube crea el contenedor msft-cloud-witness para almacenar el archivo de blob necesario para el arbitraje de la votación.
Nota:
El testigo en la nube no es compatible con los siguientes tipos de cuentas de Azure Storage:
- Blob Storage
- Azure Premium Storage
También puede usar esta cuenta y el contenedor msft-cloud-witness que el testigo en la nube crea automáticamente para configurar el testigo en la nube en varios clústeres diferentes. Cada clúster tiene su propio archivo de blob que almacena en el contenedor.
Al crear la cuenta de Azure Storage, si el clúster para el que configura el testigo en la nube es local o está en Azure en las mismas zonas de disponibilidad y región de Azure, seleccione Almacenamiento con redundancia local (LRS) al configurar el campo Replicación. Si el clúster está en la misma región de Azure, pero en zonas de disponibilidad diferentes, seleccione Almacenamiento con redundancia de zona (ZRS) en su lugar.
Debe usar uno de los siguientes escenarios admitidos:
Recuperación ante desastres para clústeres de varios sitios extendidos, como se muestra en ¿Qué es el testigo en la nube?
Clústeres de conmutación por error sin almacenamiento compartido, como Always On de SQL.
Clústeres de conmutación por error que se ejecutan dentro de un sistema operativo invitado hospedado en el rol de máquina virtual de Microsoft Azure o en cualquier otra nube pública.
Clústeres de conmutación por error hechos de máquinas virtuales hospedadas en nubes privadas que se ejecutan dentro de un sistema operativo invitado.
Clústeres de almacenamiento con o sin almacenamiento compartido, como clústeres de servidores de archivos de escalabilidad horizontal.
Clústeres de sucursales pequeñas, incluso clústeres de 2 nodos.
Se recomienda configurar siempre un testigo si usa Windows Server 2012 R2 y versiones posteriores. Los clústeres de versiones posteriores de Windows Server administran automáticamente el voto de testigo y sus nodos votan con cuórum dinámico.
También debe asegurarse de que todos los firewalls entre el clúster de conmutación por error y el servicio de cuenta de Azure Storage permiten el tráfico procedente del puerto 443, también conocido como puerto HTTPS. El testigo en la nube usa la interfaz REST HTTPS para el servicio Azure Storage. Por lo tanto, debe tener abierto el puerto 443 en todos los nodos del clúster de conmutación por error para que el testigo en la nube funcione según lo previsto.
Al crear una cuenta de Azure Storage, Azure la asocia a las claves de acceso primaria y secundaria generadas automáticamente. Al configurar el testigo en la nube por primera vez, se recomienda usar la clave de acceso primaria. Después, puede usar la clave de acceso primaria o secundaria.
Configuración del testigo en la nube como testigo de cuórum para el clúster
Puede configurar el testigo en la nube mediante el flujo de trabajo de configuración de cuórum integrado en la aplicación Administrador de clústeres de conmutación por error o mediante PowerShell.
A fin de usar el flujo de trabajo de configuración de cuórum para configurar el testigo en la nube:
Abra el Administrador de clústeres de conmutación por error.
Haga clic con el botón derecho en el nombre del clúster.
Vaya a Más acciones>Configurar las opciones del cuórum de clúster, como se muestra en la captura de pantalla siguiente para iniciar el flujo de trabajo de configuración de cuórum de clúster.
En la página Seleccionar opción de configuración de cuórum, seleccione Seleccionar el testigo de cuórum.
En la página Seleccionar testigo de cuórum, seleccione Configurar un testigo en la nube.
En la página Configurar testigo en la nube, escriba la información siguiente:
Nombre de la cuenta de Azure Storage.
Clave de acceso asociada a la cuenta de almacenamiento.
Si va a crear un testigo en la nube por primera vez, use la clave de acceso primaria.
Si va a girar la clave de acceso primaria, use la clave de acceso secundaria en su lugar.
Nota:
En lugar de almacenar las claves de acceso directamente, el clúster de conmutación por error genera un token de seguridad de acceso compartido (SAS) para almacenarlas de forma segura en su lugar. El token solo es válido siempre que la clave de acceso a la que se asocia siga siendo válida. Al girar la clave de acceso primaria, debe actualizar los testigos en la nube en todos los clústeres mediante esa cuenta de almacenamiento con la clave secundaria para poder volver a generar la clave primaria.
Opcionalmente, puede escribir el nombre de otro servidor existente en el campo Nombre del servidor de punto de conexión si tiene previsto usar otro punto de conexión de servicio de Azure para el testigo en la nube, como Azure China.
Si la configuración se realiza correctamente, debería poder ver el nuevo testigo en la nube en el menú de acordeón Administrador de clústeres de conmutación por error, como se muestra en la captura de pantalla siguiente.
Consideraciones sobre el proxy con el testigo en la nube
El testigo en la nube de Azure usa HTTPS (puerto predeterminado 443) para establecer la comunicación saliente con el servicio de blobs de Azure. Azure usa .core.windows.net como punto de conexión. Debe asegurarse de que este punto de conexión esté incluido en cualquier lista de permisos de firewall que utilice entre el clúster y Azure Storage. Si se necesita un proxy para acceder a Azure Storage, configure los servicios HTTP de Windows (WinHTTP) con la configuración de proxy necesaria. El clúster de conmutación por error usa WinHTTP para la comunicación HTTPS.
Para usar el comando netsh para configurar un servidor proxy predeterminado, siga los pasos que se indican a continuación:
Nota:
- Esto cambiará la configuración de proxy predeterminada para WinHTTP. Cualquier aplicación, incluidos los servicios de Windows, que use WinHTTP puede verse afectada.
Abra una línea de comandos con privilegios elevados:
- Vaya a Inicio y escriba cmd.
- Haga clic con el botón derecho en el símbolo del sistema y seleccione Ejecutar como administrador.
Escriba el siguiente comando y presione Entrar:
netsh winhttp set proxy proxy-server="<ProxyServerName>:<port>" bypass-list="<HostsList>"Por ejemplo:
netsh winhttp set proxy proxy-server="192.168.10.80:8080" bypass-list="<local>; *.contoso.com"
Consulte Sintaxis, contextos y formatos de comandos netsh para obtener más información.