Implementación de un testigo en la nube para un clúster de conmutación por error

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

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 en el cuórum de clúster. En este tema se proporciona información general sobre la característica 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 más información, consulte Configuración de un testigo de clúster.

Introducción al testigo en la nube

En la ilustración siguiente se muestra una configuración de cuórum de clúster de conmutación por error extendido de varios sitios con Windows Server 2016. En esta configuración de ejemplo (figura 1), hay 2 nodos en 2 centros de datos (denominados Sitios). Tenga en cuenta que es posible que un clúster abarque más de 2 centros de datos. Además, cada centro de datos puede tener más de 2 nodos. Una configuración típica del cuórum de clúster en esta configuración (Acuerdo de Nivel de Servicio de conmutación automática por error) da un voto a cada nodo. Se da un voto adicional al testigo de cuórum para permitir que el clúster siga ejecutándose incluso si alguno de los centros de datos experimenta un corte de energía. La matemática es sencilla: hay 5 votos totales y necesita 3 votos para que el clúster siga ejecutándose.

con 2 nodos en otros dos sitios Testigo de recurso compartido de archivos mediante un testigo de recursocompartido de archivos como testigo de cuórum

Si se produce una interrupción del suministro eléctrico en un centro de datos, para dar la misma oportunidad a que el clúster de otro centro de datos lo mantenga en ejecución, se recomienda hospedar el testigo de cuórum en una ubicación que no sea la de los dos centros de datos. Esto suele significar requerir un tercer centro de datos independiente (sitio) para hospedar un servidor de archivos que realiza la copia de seguridad del recurso compartido de archivos, que se usa como testigo de cuórum (testigo de recurso compartido de archivos).

La mayoría de las organizaciones no tienen un tercer centro de datos independiente que hospedará el servidor de archivos que realice la copia de seguridad del testigo del recurso compartido de archivos. Esto significa que las organizaciones hospedan principalmente el servidor de archivos en uno de los dos centros de datos, lo que, por extensión, convierte ese centro de datos en el centro de datos principal. En un escenario en el que se produce una interrupción del suministro eléctrico en el centro de datos principal, el clúster podría bajar, ya que el otro centro de datos solo tendría 2 votos, que está por debajo de la mayoría de quórum de 3 votos necesarios. Para los clientes que tienen un tercer centro de datos independiente para hospedar el servidor de archivos, es una sobrecarga mantener el servidor de archivos de alta disponibilidad con el testigo del recurso compartido de archivos. Hospedar máquinas virtuales en la nube pública que tienen el servidor de archivos para el testigo de recurso compartido de archivos que se ejecuta en el sistema operativo invitado es una sobrecarga considerable en términos de instalación y mantenimiento.

Testigo en la nube es un nuevo tipo de testigo de cuórum de clúster de conmutación por error que usa Microsoft Azure como punto de conciliación (consulte la ilustración siguiente). Usa Azure Blob Storage para leer y escribir un archivo de blob que, a continuación, se usa como punto de conciliación en caso de resolución de cerebro dividido.

Este enfoque tiene importantes ventajas:

• Usa Microsoft Azure (no es necesario para un tercer centro de datos independiente).
• Usa blobs de Azure estándar Storage (sin sobrecarga de mantenimiento adicional de las máquinas virtuales hospedadas en la nube pública).
• Se puede Azure Storage misma cuenta de almacenamiento para varios clústeres (un archivo de blob por clúster; identificador único de clúster usado como nombre de archivo de blob).
• Baja cantidad de $cost a la cuenta de Storage (datos pequeños escritos por archivo de blob, archivo de blob actualizado solo una vez cuando cambia el estado de los nodos del clúster).
• Tipo de recurso testigo en la nube integrado.

extendido de varios sitios con testigo en la nube como testigo de cuórum Clústeresextendidos de varios sitios con testigo en la nube como testigo de cuórum

Como se muestra en la ilustración anterior, no hay ningún tercer sitio independiente que sea necesario. El testigo en la nube, al igual que cualquier otro testigo de cuórum, obtiene un voto y puede participar en los cálculos de cuórum.

Testigo en la nube: escenarios admitidos para el tipo de testigo único

Si tiene una implementación de clúster de conmutación por error, donde todos los nodos pueden acceder a Internet (por extensión de Azure), se recomienda configurar un testigo en la nube como recurso de testigo de cuórum.

Algunos de los escenarios que se admiten para el uso del testigo en la nube como testigo de cuórum son los siguientes:

• Clústeres de varios sitios extendidos de recuperación ante desastres (consulte la ilustración anterior).
• Clústeres de conmutación por error sin almacenamiento compartido (SQL Always On, etc.).
• Clústeres de conmutación por error que se ejecutan dentro del sistema operativo invitado hospedado Microsoft Azure rol de máquina virtual (o cualquier otra nube pública).
• Clústeres de conmutación por error que se ejecutan dentro del sistema operativo invitado Virtual Machines hospedada en nubes privadas.
• Storage clústeres con o sin almacenamiento compartido, como clústeres de servidores de archivos de escalabilidad horizontal.
• Clústeres de sucursales pequeños (incluso clústeres de 2 nodos)

A partir Windows Server 2012 R2, se recomienda configurar siempre un testigo, ya que el clúster administra automáticamente el voto del testigo y los nodos votan con cuórum dinámico.

Configuración de un testigo en la nube para un clúster

Para configurar un testigo en la nube como testigo de cuórum para el clúster, complete los pasos siguientes:

1. Creación de una cuenta de Azure Storage para su uso como testigo en la nube
2. Configure el testigo en la nube como testigo de cuórum para el clúster.

Creación de una cuenta de Azure Storage para su uso como testigo en la nube

En esta sección se describe cómo crear una cuenta de almacenamiento y cómo ver y copiar las direcciones URL del punto de conexión y las claves de acceso de esa cuenta.

Para configurar el testigo en la nube, debe tener una cuenta de Azure Storage válida que se pueda usar para almacenar el archivo de blob (usado para el arbitraje). El testigo en la nube crea un contenedor conocido msft-cloud-witness en la cuenta de almacenamiento de Microsoft. El testigo en la nube escribe un único archivo de blob con el identificador único del clúster correspondiente que se usa como nombre de archivo del archivo de blob en este contenedor msft-cloud-witness. Esto significa que puede usar la misma cuenta de Microsoft Azure Storage para configurar un testigo en la nube para varios clústeres diferentes.

Cuando se usa la misma cuenta de Azure Storage para configurar el testigo en la nube para varios clústeres diferentes, se crea automáticamente un solo contenedor msft-cloud-witness. Este contenedor contendrá un archivo de un blob por clúster.

Para crear una cuenta de Azure Storage

1. Inicie sesión en Azure Portal.
2. En el menú Concentrador, seleccione Nuevo - > Datos + Storage - Storage > cuenta.
3. En la página Crear una cuenta de almacenamiento, haga lo siguiente:

   1. Escriba un nombre para la cuenta de almacenamiento.
      Los nombres de las cuentas de almacenamiento deben tener entre 3 y 24 caracteres, y solo pueden incluir números y letras en minúscula. El nombre de la cuenta de almacenamiento también debe ser único dentro de Azure.

   2. En Tipo de cuenta seleccione Uso general.
      No se puede usar una cuenta de almacenamiento de blobs para un testigo en la nube.

   3. En Rendimiento, seleccione Estándar.
      No se puede usar Azure Premium Storage para un testigo en la nube.

   4. En Replicación,seleccione Almacenamiento con redundancia local (LRS) o Almacenamiento con redundancia de zona (ZRS) según corresponda.
      Los clústeres de conmutación por error usan el archivo de blob como punto de arbitraje, lo cual requiere algunas garantías de coherencia al leer los datos. Por lo tanto, debe seleccionar Almacenamiento con redundancia local como Tipo de replicación cuando el testigo en la nube es para un clúster que reside en el entorno local, o bien es un clúster de Azure que no se implementa en distintas zonas de disponibilidad de la misma región. Cuando los nodos del clúster se encuentran en la misma región pero en una zona de disponibilidad diferente, use Almacenamiento con redundancia de zona como Tipo de replicación.

Visualización y copia de las claves de acceso de almacenamiento de la cuenta de Azure Storage

Cuando se crea una cuenta de Microsoft Azure Storage, esta se asocia a dos claves de acceso que se generan automáticamente: la clave de acceso primaria y la secundaria. Para crear por primera vez un testigo en la nube, use la clave de acceso primaria. No hay ninguna restricción respecto a la clave que se va a usar para el testigo en la nube.

Visualización y copia de las claves de acceso de almacenamiento

En Azure Portal, vaya a su cuenta de almacenamiento, haga clic en Toda la configuración y luego en Claves de acceso para ver, copiar y volver a generar las claves de acceso de la cuenta. La hoja Claves de acceso también incluye cadenas de conexión preconfiguradas mediante las claves principal y secundaria que puede copiar para usarlas en las aplicaciones (consulte la figura 4).

Figura4: Storage claves de acceso

Visualización y copia de los vínculos de las direcciones URL del punto de conexión

Al crear una cuenta de almacenamiento, se generan las siguientes direcciones URL con el formato: https://<Storage Account Name>.<Storage Type>.<Endpoint>

El testigo de la nube siempre usa Blob como tipo de almacenamiento. Azure usa .core.windows.net como punto de conexión. Al configurar el testigo de la nube, es posible que se configure con un punto de conexión diferente según el escenario (por ejemplo, el centro de datos de Microsoft Azure en China tiene un punto de conexión diferente).

Visualización y copia de los vínculos de las direcciones URL del punto de conexión

En la Azure Portal, vaya a la cuenta de almacenamiento, haga clic en Toda la configuración y, a continuación, haga clic en Propiedades para ver y copiar las direcciones URL del punto de conexión (consulte la figura 5).

Ilustración5: Vínculos de dirección URL del punto de conexión del testigo en la nube

Para obtener más información sobre cómo crear y administrar Azure Storage, consulte Acerca de las Azure Storage.

Configuración del testigo en la nube como testigo de cuórum para el clúster

La configuración del testigo en la nube está bien integrada en el Asistente para configuración de cuórum existente integrado en el Administrador de clústeres de conmutación por error.

Para configurar el testigo en la nube como testigo de cuórum

1. Inicie Administrador de clústeres de conmutación por error.

2. Haga clic con el botón derecho en el clúster - Más acciones - Configurar el cuórum >>>> clúster (consulte la figura 6). Esto inicia el asistente para configurar el cuórum de clúster.

   el cuórum Configuración en la Administrador de clústeres de conmutación por error de interfazde usuario 6. Clúster de cuórum Configuración

3. En la página Seleccionar configuraciones de cuórum, seleccione Seleccionar el testigo de cuórum (consulte la figura 7).

   Figura7. Selección de la configuración de cuórum

4. En la página Seleccionar testigo de cuórum, seleccione Configurar un testigo en la nube (consulte la figura 8).

   nube Figura8. Selección del testigo de cuórum

5. En la página Configurar testigo en la nube, escriba la siguiente información:

   1. (Parámetro obligatorio) Nombre de la cuenta de Azure Storage.

   2. (Parámetro obligatorio) Clave de acceso correspondiente a la cuenta de almacenamiento.

      1. Al crear por primera vez, use la clave de acceso principal.
      2. Al rotar la clave de acceso principal, use la clave de acceso secundaria.

   3. (Parámetro opcional) Si piensa usar otro punto de conexión de servicio de Azure (por ejemplo, el servicio Microsoft Azure en China), actualice el nombre del servidor del punto de conexión.

      Figura9: Configuración del testigo en la nube

6. Tras la configuración correcta del testigo en la nube, puede ver el recurso de testigo recién creado en el complemento Administrador de clústeres de conmutación por error (consulte la figura 10).

   nube Ilustración10: Configuración correcta del testigo en la nube

Configuración del testigo en la nube mediante PowerShell

El comando Set-ClusterQuorum PowerShell tiene nuevos parámetros adicionales correspondientes al testigo en la nube.

Puede configurar Cloud Witness con el cmdlet Set-ClusterQuorum mediante el siguiente comando de PowerShell:

Set-ClusterQuorum -CloudWitness -AccountName <StorageAccountName> -AccessKey <StorageAccountAccessKey>

En caso de que necesite usar un punto de conexión diferente (poco frecuente):

Set-ClusterQuorum -CloudWitness -AccountName <StorageAccountName> -AccessKey <StorageAccountAccessKey> -Endpoint <servername>

Azure Storage account considerations with Cloud Witness

Al configurar un testigo en la nube como testigo de cuórum para el clúster de conmutación por error, tenga en cuenta lo siguiente:

• En lugar de almacenar la clave de acceso, el clúster de conmutación por error generará y almacenará de forma segura un token de seguridad de acceso compartido (SAS).
• El token de SAS generado es válido siempre que la clave de acceso siga siendo válida. Al rotar la clave de acceso principal, es importante actualizar primero el testigo en la nube (en todos los clústeres que usan esa cuenta de almacenamiento) con la clave de acceso secundaria antes de volver a generar la clave de acceso principal.
• El testigo en la nube usa la interfaz REST HTTPS del servicio de cuentas de Azure Storage. Esto significa que requiere que el puerto HTTPS esté abierto en todos los nodos del clúster.

Consideraciones de proxy con testigo en la nube

El testigo en la nube usa HTTPS (puerto predeterminado 443) para establecer la comunicación saliente con Azure Blob service. Asegúrese de que el puerto de salida HTTPS sea accesible a través del proxy de red.

Consulte también

• Novedades de los clústeres de conmutación por error de Windows Server