Implementación de un conjunto de clústeres

Artículo
10/06/2023

Se aplica a: Windows Server 2019

En este artículo, se proporciona información sobre cómo implementar un conjunto de clústeres para clústeres de conmutación por error de Windows Server mediante PowerShell. Un conjunto de clústeres es un grupo de varios clústeres de conmutación por error agrupados en clústeres. Mediante el uso de un conjunto de clústeres, puede aumentar el número de nodos de servidor en una única nube del Centro de datos definido por software (SDDC) por órdenes de magnitud.

Los conjuntos de clústeres se han probado y admitido hasta 64 nodos de clúster en total. Sin embargo, los conjuntos de clústeres se pueden escalar hasta límites mucho mayores y no están codificados de forma rígida para un límite.

Ventajas

Los conjuntos de clústeres ofrecen las siguientes ventajas:

Aumenta significativamente la escala en la nube del SDDC compatible para ejecutar máquinas virtuales (VM) de alta disponibilidad mediante la combinación de varios clústeres más pequeños en un único tejido grande, al tiempo que se mantiene el límite de errores de software en un único clúster. Puede migrar fácilmente máquinas virtuales a través del conjunto de clústeres.
Aumento de la resistencia. Tener cuatro clústeres de 4 nodos en un conjunto de clústeres proporciona una mejor resistencia que un único clúster de 16 nodos, ya que varios nodos de proceso pueden quedarse inactivos y la producción seguir intacta.
Administración del ciclo de vida del clúster de conmutación por error, incluida la incorporación y retirada de clústeres, sin afectar a la disponibilidad de la máquina virtual del inquilino.
Flexibilidad de máquinas virtuales entre clústeres individuales y un espacio de nombres de almacenamiento unificado.
Cambio fácil de la relación de la carga de trabajo de proceso a almacenamiento en el entorno hiperconvergido.
Ventajas de los dominios de error y los conjuntos de disponibilidad similares a Azure en clústeres individuales en la selección de ubicación inicial de la máquina virtual y la migración posterior.
Se puede usar incluso si el hardware de proceso y almacenamiento entre los nodos de clúster no es idéntico.
Migración en vivo de máquinas virtuales entre clústeres.
Conjuntos de disponibilidad y dominios de error similares a Azure en varios clústeres.
Traslado de máquinas virtuales de SQL Server entre clústeres.

Limitaciones y requisitos

Existen algunos requisitos y limitaciones para usar conjuntos de clústeres:

Todos los clústeres miembros de un conjunto de clústeres deben estar en el mismo bosque de Active Directory (AD).
Los servidores miembros del conjunto deben ejecutar la misma versión del sistema operativo. Las máquinas virtuales no se pueden migrar en vivo entre distintos sistemas operativos. Puede tener un conjunto de clústeres que conste de cualquiera de las siguientes opciones, pero no de varias de ellas a la vez:
- Clúster de conmutación por error de Windows Server 2019 y clúster de conmutación por error de Windows Server 2019
- Clúster de conmutación por error de Windows Server 2019 y Espacios de almacenamiento directo de Windows Server 2019
- Espacios de almacenamiento directo de Windows Server 2019 y Espacios de almacenamiento directo de Windows Server 2019
Se necesita un hardware de procesador idéntico para todos los servidores miembro para que se produzca la migración en vivo entre clústeres miembro. En caso contrario, debe seleccionar CPU Processor Compatibility (Compatibilidad con el procesador de CPU) en la configuración de las máquinas virtuales.
Las máquinas virtuales del conjunto de clústeres se deben migrar manualmente en vivo entre clústeres, no se pueden conmutar por error automáticamente.
Debe usarse la réplica de almacenamiento entre los clústeres miembros para lograr la resistencia del almacenamiento a errores de clúster. Al usar la réplica de almacenamiento, tenga en cuenta que las rutas de acceso UNC del almacenamiento del espacio de nombres no cambiarán automáticamente en la conmutación por error de almacenamiento al clúster de destino de la réplica.
Espacios de almacenamiento directo no funciona entre clústeres miembros de un conjunto de clústeres. En su lugar, Espacios de almacenamiento directo se aplica a un único clúster, y cada clúster tiene su propio grupo de almacenamiento.

Architecture

En el diagrama siguiente se muestra un conjunto de clústeres de alto nivel:

A continuación, se proporciona un resumen de cada uno de los elementos que se muestran:

Clúster de administración

El clúster de administración hospeda el Servidor de archivos de escalabilidad horizontal (SOFS) de alta disponibilidad del plano de administración y la referencia del espacio de nombres para el conjunto de clústeres. Un clúster de administración se desacopla de manera lógica de los clústeres miembros individuales que ejecutan cargas de trabajo de máquina virtual. Esto hace que el plano de administración del conjunto de clústeres sea resistente a los errores localizados en todo el clúster, como la pérdida de alimentación de un clúster miembro.

SOFS de referencia de espacio de nombres del conjunto de clústeres

Se proporciona un espacio de nombres para el conjunto de clústeres con un rol de servidor SOFS que se ejecuta en el clúster de administración. Es similar a un espacio de nombres del Sistema de archivos distribuido (DFSN). Sin embargo, a diferencia de DFSN, los metadatos de referencia del espacio de nombres del conjunto de clústeres se rellenan automáticamente en todos los nodos de clúster sin intervención, por lo que casi no hay ninguna sobrecarga de rendimiento en la ruta de acceso de almacenamiento. Este mecanismo de referencia ligero no participa en la ruta de acceso de E/S.

Cada recurso compartido de referencia de Bloque de mensajes del servidor (SMB) en el SOFS de referencia de espacio de nombres del conjunto de clústeres es de tipo SimpleReferral. Esta referencia permite a los clientes SMB acceder al recurso compartido SMB de destino hospedado en el SOFS del clúster miembro. Las referencias se almacenan en caché de forma permanente en cada uno de los nodos cliente y el espacio de nombres del conjunto de clústeres actualiza dinámicamente las referencias según sea necesario de manera automática. La información de referencia se almacena en caché de forma persistente en cada nodo del conjunto de clústeres, incluso durante los reinicios.

Maestro de conjunto de clústeres

La comunicación entre los clústeres miembros está débilmente acoplada y está coordinada por el recurso maestro del conjunto de clústeres (CS-Master). Al igual que otros recursos del conjunto de clústeres, CS-Master es de alta disponibilidad y resistente a errores de clústeres miembros individuales o a errores de nodos de clústeres de administración. A través de un proveedor de WMI del conjunto de clústeres, CS-Master proporciona el punto de conexión de administración para todas las acciones de administración del conjunto de clústeres.

Clúster miembro

Un clúster miembro ejecuta las cargas de trabajo de máquina virtual y Espacios de almacenamiento directo. Varios clústeres miembros participan en una implementación de conjunto de clústeres, formando un tejido mayor en la nube de SDDC. Los clústeres miembros difieren del clúster de administración en dos aspectos clave: los clústeres miembros participan en las construcciones de dominio de error y conjunto de disponibilidad, y los clústeres miembros tienen un tamaño adecuado para hospedar cargas de trabajo de máquina virtual y Espacios de almacenamiento directo. Las máquinas virtuales que se mueven entre clústeres miembros no se hospedan en el clúster de administración por este motivo.

Trabajo de conjunto de clústeres

CS-Master interactúa con un recurso de clúster de los clústeres miembros llamado nodo de trabajo del conjunto de clústeres (CS-Worker). CS-Worker responde a las solicitudes de CS-Master, incluida la selección de ubicación de máquinas virtuales y el inventario de recursos. Hay una instancia de CS-Worker por cada clúster miembro.

Dominio de error

Un dominio de error es un grupo de hardware y software que pueden producir errores juntos. Aunque puede designar uno o varios clústeres como dominio de error, cada nodo puede participar en un dominio de error de un conjunto de disponibilidad. Los límites de dominio de error se basan en la topología del centro de datos, la arquitectura de red y otras consideraciones.

Conjunto de disponibilidad

Un conjunto de disponibilidad se usa para configurar la redundancia deseada de las cargas de trabajo en clúster en los dominios de error mediante la agrupación e implementación de cargas de trabajo. En el caso de una aplicación de dos niveles, debe configurar al menos dos máquinas virtuales en un conjunto de disponibilidad para cada nivel, lo que garantiza que cuando un dominio de error de un conjunto de disponibilidad se quede fuera de servicio, la aplicación tendrá al menos una máquina virtual en cada nivel hospedada en un dominio de error diferente.

Creación de un conjunto de clústeres

Use PowerShell en el siguiente flujo de trabajo de ejemplo para crear un conjunto de clústeres con dos clústeres. El nombre del conjunto de clústeres es CSMASTER.

Nombre del clúster	Nombre de SOFS de infraestructura
SET-CLUSTER	SOFS-CLUSTERSET
CLUSTER1	SOFS-CLUSTER1
CLUSTER2	SOFS-CLUSTER2

Use un equipo cliente de administración que ejecute Windows Server 2022 o Windows Server 2019.
Instale las herramientas de clúster de conmutación por error en el servidor de clúster de administración.
Cree dos miembros de clúster con al menos dos volúmenes compartidos de clúster (CSV) en cada clúster.
Cree un clúster de administración (físico o invitado) que abarque los clústeres miembros. Esto garantiza que el plano de administración del conjunto de clústeres siga estando disponible a pesar de los posibles errores del clúster miembro.
Para crear el conjunto de clústeres:
```
New-ClusterSet -Name CSMASTER -NamespaceRoot SOFS-CLUSTERSET -CimSession SET-CLUSTER
```
Nota:

Si usa una dirección IP estática, debe incluir -StaticAddress x.x.x.x en el comando New-ClusterSet.

Para agregar miembros de clúster al conjunto de clústeres:

Add-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER -InfraSOFSName SOFS-CLUSTER1
Add-ClusterSetMember -ClusterName CLUSTER2 -CimSession CSMASTER -InfraSOFSName SOFS-CLUSTER2

Para enumerar todos los clústeres miembros del conjunto de clústeres:
```
Get-ClusterSetMember -CimSession CSMASTER
```
Para enumerar todos los clústeres miembros del conjunto de clústeres, incluidos los nodos del clúster de administración:
```
Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterNode
```
Para enumerar todos los nodos de servidor de todos los clústeres miembros:
```
Get-ClusterSetNode -CimSession CSMASTER
```
Para enumerar todos los grupos de recursos en el conjunto de clústeres:
```
Get-ClusterSet -CimSession CSMASTER | Get-Cluster | Get-ClusterGroup
```
Para comprobar que el conjunto de clústeres contiene un recurso compartido SMB (siendo ScopeName el nombre del servidor de archivos de infraestructura) en el SOFS de infraestructura para cada volumen CSV del miembro de clúster:
```
Get-SmbShare -CimSession CSMASTER
```
Revise los archivos de registro de depuración del conjunto de clústeres, el clúster de administración y cada miembro de clúster:
```
Get-ClusterSetLog -ClusterSetCimSession CSMASTER -IncludeClusterLog -IncludeManagementClusterLog -DestinationFolderPath <path>
```
Configure Kerberos con delegación restringida entre todos los miembros del conjunto de clústeres.
Configure el tipo de autenticación de la migración en vivo de las máquinas virtuales entre clústeres en Kerberos en cada nodo del conjunto de clústeres:
```
foreach($h in $hosts){ Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos -ComputerName $h }
```
Agregue el clúster de administración al grupo de administradores locales en cada nodo del servidor miembro del clúster en el conjunto de clústeres:
```
foreach($h in $hosts){ Invoke-Command -ComputerName $h -ScriptBlock {Net localgroup administrators /add <management_cluster_name>$} }
```

Creación de máquinas virtuales de conjunto de clústeres

Después de crear el conjunto de clústeres, el siguiente paso es crear máquinas virtuales. Debe realizar las siguientes comprobaciones con antelación:

Comprobación de la memoria disponible en cada nodo de servidor de clúster
Comprobación del espacio en disco disponible en cada nodo de servidor de clúster
Comprobación de los requisitos de almacenamiento de máquinas virtuales específicos en términos de velocidad y rendimiento

El comando Get-ClusterSetOptimalNodeForVM identifica el clúster y el nodo óptimos del conjunto de clústeres y, a continuación, implementa la máquina virtual en él. En el siguiente ejemplo, se crea una nueva máquina virtual con:

4 GB disponibles
Un procesador virtual
10 % de CPU mínima disponible

# Identify the optimal node to create a new virtual machine
$memoryinMB=4096
$vpcount = 1
$targetnode = Get-ClusterSetOptimalNodeForVM -CimSession CSMASTER -VMMemory $memoryinMB -VMVirtualCoreCount $vpcount -VMCpuReservation 10
$secure_string_pwd = convertto-securestring "<password>" -asplaintext -force
$cred = new-object -typename System.Management.Automation.PSCredential ("<domain\account>",$secure_string_pwd)

# Deploy the virtual machine on the optimal node
Invoke-Command -ComputerName $targetnode.name -scriptblock { param([String]$storagepath); New-VM CSVM1 -MemoryStartupBytes 3072MB -path $storagepath -NewVHDPath CSVM.vhdx -NewVHDSizeBytes 4194304 } -ArgumentList @("\\SOFS-CLUSTER1\VOLUME1") -Credential $cred | Out-Null

Start-VM CSVM1 -ComputerName $targetnode.name | Out-Null
Get-VM CSVM1 -ComputerName $targetnode.name | fl State, ComputerName

Cuando haya terminado, se mostrará en qué nodo de clúster se implementó la máquina virtual. En el ejemplo anterior, se mostraría como:

State         : Running
ComputerName  : 1-S2D2

Si no hay suficiente memoria, capacidad de CPU o espacio en disco disponible para agregar la máquina virtual, recibirá el siguiente error:

Get-ClusterSetOptimalNodeForVM : A cluster node isn't available for this operation.

Una vez creada la máquina virtual, se muestra en el administrador de Hyper-V, en el nodo especificado. Para agregarla como una máquina virtual de conjunto de clústeres y agregarla al clúster, use este comando:

Register-ClusterSetVM -CimSession CSMASTER -MemberName $targetnode.Member -VMName CSVM1

Cuando haya finalizado, la salida será:

Id  VMName  State  MemberName  PSComputerName
--  ------  -----  ----------  --------------
 1  CSVM1     On   CLUSTER1    CSMASTER

Si ha creado un clúster con máquinas virtuales existentes, estas se deben registrar en el conjunto de clústeres. Para registrar todas las máquinas virtuales a la vez, use:

Get-ClusterSetMember -Name CLUSTER3 -CimSession CSMASTER | Register-ClusterSetVM -RegisterAll -CimSession CSMASTER

A continuación, agregue la ruta de acceso de la máquina virtual al espacio de nombres del conjunto de clústeres.

Por ejemplo, suponga que se agrega un clúster existente al conjunto de clústeres con máquinas virtuales preconfiguradas que residen en el Volumen compartido de clúster (CSV) local. La ruta de acceso del VHDX sería similar a C:\ClusterStorage\Volume1\MYVM\Virtual Hard Disks\MYVM.vhdx1.

Se necesita una migración de almacenamiento, ya que las rutas de acceso CSV son, por diseño, locales a un solo clúster miembro y, por tanto, no serán accesibles para la máquina virtual una vez que se migren en vivo entre clústeres miembros.

En este ejemplo, CLUSTER3 se agrega al conjunto de clústeres mediante Add-ClusterSetMember con el servidor de archivos de escalabilidad horizontal SOFS-CLUSTER3. Para mover la configuración y el almacenamiento de la máquina virtual, el comando es:

Move-VMStorage -DestinationStoragePath \\SOFS-CLUSTER3\Volume1 -Name MyVM

Una vez completado, puede recibir una advertencia:

WARNING: There were issues updating the virtual machine configuration that may prevent the virtual machine from running. For more information view the report file below.
WARNING: Report file location: C:\Windows\Cluster\Reports\Update-ClusterVirtualMachineConfiguration '' on date at time.htm.

Esta advertencia puede omitirse porque no se han realizado cambios físicos en la configuración de almacenamiento del rol de máquina virtual. La ubicación física real no cambia; solo lo hacen las rutas de acceso de configuración.

Para obtener más información sobre Move-VMStorage, vea Move-VMStorage.

La migración en vivo de una máquina virtual dentro de un conjunto de clústeres implica lo siguiente:

Set-VMHost -UseAnyNetworkForMigration $true

A continuación, para mover una máquina virtual de conjunto de clústeres de CLUSTER1 a NODE2-CL3 en CLUSTER3, por ejemplo, el comando sería:

Move-ClusterSetVM -CimSession CSMASTER -VMName CSVM1 -Node NODE2-CL3

Este comando no mueve los archivos de almacenamiento ni de configuración de la máquina virtual y no es necesario, ya que la ruta de acceso a la máquina virtual permanece como \\SOFS-CLUSTER1\VOLUME1. Una vez que se ha registrado una máquina virtual con la ruta de acceso del recurso compartido del servidor de archivos de la infraestructura, no es necesario que las unidades y la máquina virtual estén en el mismo nodo que la máquina virtual.

Creación de un servidor de archivos de escalabilidad horizontal de infraestructura

Hay un rol de clúster SOFS de infraestructura en un clúster. El rol de SOFS de infraestructura se crea especificando el parámetro de conmutador -Infrastructure en el cmdlet Add-ClusterScaleOutFileServerRole. Por ejemplo:

Add-ClusterScaleoutFileServerRole -Name "my_infra_sofs_name" -Infrastructure

Cada volumen CSV creado desencadena de forma automática la creación de un recurso compartido SMB con un nombre generado automáticamente basado en el nombre del volumen CSV. No se pueden crear ni modificar directamente los recursos compartidos SMB con un rol de SOFS, aparte de mediante operaciones de creación y modificación de volúmenes CSV.

En las configuraciones hiperconvergidas, un SOFS de infraestructura permite que un cliente SMB (host de Hyper-V) se comunique con disponibilidad continua (CA) con el servidor SMB de SOFS de infraestructura. Esta CA de bucle invertido de SMB hiperconvergido se logra mediante máquinas virtuales que acceden a sus archivos de disco virtual (VHDX) donde se reenvía la identidad de máquina virtual propietaria entre el cliente y el servidor. Este reenvío de identidad permite el uso de las ACL para archivos VHDx igual que en configuraciones de clúster hiperconvergidas estándar como antes.

Una vez creado un conjunto de clústeres, el espacio de nombres del conjunto de clústeres se basa en un SOFS de infraestructura en cada uno de los clústeres miembro y, además, en un SOFS de infraestructura en el clúster de administración.

En el momento en que se agrega un clúster miembro a un conjunto de clústeres, puede especificar el nombre de un SOFS de infraestructura en ese clúster si ya existe uno. Si el servidor SOFS de infraestructura no existe, se crea un nuevo rol de SOFS de infraestructura en el nuevo clúster miembro. Si ya existe un rol de SOFS de infraestructura en el clúster miembro, la operación Agregar cambia implícitamente su nombre al nombre especificado según corresponda. El conjunto de clústeres no usa los servidores SMB existentes ni los roles de SOFS que no son de infraestructura en los clústeres miembros.

Cuando se crea el conjunto de clústeres, tiene la opción de usar un objeto del equipo AD existente como raíz del espacio de nombres en el clúster de administración. La creación del conjunto de clústeres crea el rol de clúster de SOFS de infraestructura en el clúster de administración o cambia el nombre del rol de SOFS de infraestructura existente. El SOFS de infraestructura del clúster de administración se usa como SOFS de referencia del espacio de nombres del conjunto de clústeres.

Creación de dominios de error y conjuntos de disponibilidad

Se pueden configurar dominios de error y conjuntos de disponibilidad similares a Azure en un conjunto de clústeres. Esto es beneficioso para las selecciones de ubicaciones iniciales de máquinas virtuales y las migraciones entre clústeres.

En el ejemplo siguiente hay cuatro clústeres en un conjunto de clústeres. Dentro del conjunto, se crea un dominio de error con dos de los clústeres y un segundo dominio de error con los otros dos. Estos dos dominios de error componen el conjunto de disponibilidad.

En el ejemplo siguiente, CLUSTER1 y CLUSTER2 se encuentran en el dominio de error FD1 y CLUSTER3 y CLUSTER4 están en el dominio de error FD2. El conjunto de disponibilidad es CSMASTER-AS.

Para crear los dominios de error, los comandos son:

New-ClusterSetFaultDomain -Name FD1 -FdType Logical -CimSession CSMASTER -MemberCluster CLUSTER1,CLUSTER2 -Description "First fault domain"

New-ClusterSetFaultDomain -Name FD2 -FdType Logical -CimSession CSMASTER -MemberCluster CLUSTER3,CLUSTER4 -Description "Second fault domain"

Para asegurarse de que se han creado correctamente, se puede ejecutar Get-ClusterSetFaultDomain, cuya salida se muestra para FD1:

PS C:\> Get-ClusterSetFaultDomain -CimSession CSMASTER -FdName FD1 | fl *

PSShowComputerName    : True
FaultDomainType       : Logical
ClusterName           : {CLUSTER1, CLUSTER2}
Description           : First fault domain
FDName                : FD1
Id                    : 1
PSComputerName        : CSMASTER

Ahora que se han creado los dominios de error, se crea el conjunto de disponibilidad:

New-ClusterSetAvailabilitySet -Name CSMASTER-AS -FdType Logical -CimSession CSMASTER -ParticipantName FD1,FD2

Para validar que se ha creado, use:

Get-ClusterSetAvailabilitySet -AvailabilitySetName CSMASTER-AS -CimSession CSMASTER

Al crear nuevas máquinas virtuales, use el parámetro -AvailabilitySet para determinar el nodo óptimo para la selección de ubicación. Este es un ejemplo:

# Identify the optimal node to create a new VM
$memoryinMB=4096
$vpcount = 1
$av = Get-ClusterSetAvailabilitySet -Name CSMASTER-AS -CimSession CSMASTER
$targetnode = Get-ClusterSetOptimalNodeForVM -CimSession CSMASTER -VMMemory $memoryinMB -VMVirtualCoreCount $vpcount -VMCpuReservation 10 -AvailabilitySet $av
$secure_string_pwd = convertto-securestring "<password>" -asplaintext -force
$cred = new-object -typename System.Management.Automation.PSCredential ("<domain\account>",$secure_string_pwd)

Eliminación de un clúster de un conjunto

Hay ocasiones en las que es necesario quitar un clúster de un conjunto de clústeres. Como procedimiento recomendado, todas las máquinas virtuales del conjunto de clústeres deben sacarse fuera del clúster con antelación. Se puede hacer con los comandos Move-ClusterSetVM y Move-VMStorage.

Si no se sacan primero las máquinas virtuales fuera del clúster, todas las máquinas virtuales del conjunto de clústeres restantes hospedadas en el clúster que se va a quitar simplemente se convertirán en máquinas virtuales de alta disponibilidad enlazadas a ese clúster, suponiendo que tengan acceso a su almacenamiento. Los conjuntos de clústeres también actualizan automáticamente su inventario, ya que no hacen el seguimiento del mantenimiento de un clúster quitado ni de las máquinas virtuales que se ejecutan en él, y eliminan el espacio de nombres y todas las referencias a los recursos compartidos hospedados en el clúster quitado.

Por ejemplo, el comando para quitar el clúster CLUSTER1 de un conjunto de clústeres es:

Remove-ClusterSetMember -ClusterName CLUSTER1 -CimSession CSMASTER

Copia de seguridad de estado del sistema

La copia de seguridad del estado del sistema realizará una copia de seguridad del estado y los metadatos del clúster. Con Copias de seguridad de Windows Server, puede restaurar solo la base de datos de clúster de un nodo si es necesario o realizar una restauración autoritativa para revertir toda la base de datos del clúster en todos los nodos. En el caso de los conjuntos de clústeres, se recomienda realizar primero una restauración autoritativa para los clústeres miembros y, después, para el clúster de administración. Para más información sobre la copia de seguridad del estado del sistema, vea Copia de seguridad del estado del sistema y equipo sin sistema operativo.

Pasos siguientes

Más información sobre Réplica de almacenamiento.