Realización de tareas posteriores a la implementación en un clúster compatible con bastidores

Después de implementar un clúster compatible con bastidores, ya sea a través de Azure Portal o mediante la plantilla de implementación de Azure Resource Manager, debe completar un conjunto de tareas posteriores a las implementaciones. En este artículo se describen las tareas típicas necesarias una vez que el clúster compatible con el bastidor se ha implementado correctamente y todas las máquinas están en funcionamiento.

Compruebe el estado del clúster

Siga estos pasos para comprobar el estado del clúster:

1. En Azure Portal, vaya a la página Información general del recurso local de Azure.
2. En la pestaña Propiedades , en Configuraciones, revise el valor tipo de clúster :

   • El clúster consciente de bastidor indica que el recurso local de Azure es un clúster de este tipo.

   • Estándar indica que el recurso local de Azure es un clúster de un solo bastidor estándar.

     

Comprobación del estado de las máquinas

Siga estos pasos para comprobar el estado de las máquinas del clúster:

1. En Azure Portal, vaya a la página de recursos de Azure Local.

2. En Infraestructura, seleccione Máquinas.

3. Compruebe que las máquinas se agrupan por zona de disponibilidad local.

   

(Opcional) Cambiar el testigo de cuórum a un testigo local

De forma predeterminada, el clúster compatible con bastidor usa un testigo en la nube. Si la configuración lo requiere, puede cambiarla a un testigo local. Para obtener más información, consulte Implementación de un testigo de cuórum.

(Opcional) Creación de volúmenes de cargas de trabajo

Para configuraciones de clústeres compatibles con bastidores de 2+2 y más grandes, la implementación a través de Azure Portal solo admite el modo Express . En este modo, los componentes de infraestructura, los volúmenes de carga de trabajo y las rutas de acceso de almacenamiento se crean automáticamente para cada volumen.

Esta es una salida de ejemplo de un clúster compatible con bastidores de 4+4:

Si desea crear volúmenes de cargas de trabajo personalizados en lugar de los creados durante la implementación del clúster, puede crear volúmenes reflejados de 2 o 4 vías mediante el aprovisionamiento fijo o fino. Antes de agregar los nuevos volúmenes, debe eliminar las rutas de acceso de almacenamiento y los volúmenes existentes.

Después de crear nuevos volúmenes de carga de trabajo, debe crear rutas de acceso de almacenamiento para los nuevos volúmenes. Para obtener instrucciones detalladas, consulte Creación de la ruta de acceso de almacenamiento para Azure Local.

#Create a four-copy volume on the storage pool, fixed provisioned:
New-Volume -FriendlyName “FourCopyVolumeFixed” -StoragePoolFriendlyName "SU1_Pool" -FileSystem CSVFS_ReFS -Size 500GB -ResiliencySettingName Mirror -PhysicalDiskRedundancy 3 -ProvisioningType Fixed           

#Create a four-copy volume on the storage pool, thinly provisioned:
New-Volume -FriendlyName “FourCopyVolumeThin” -StoragePoolFriendlyName "SU1_Pool" -FileSystem CSVFS_ReFS -Size 500GB -ResiliencySettingName Mirror -PhysicalDiskRedundancy 3 -ProvisioningType Thin

#Create a two-copy volume on the storage pool, fixed provisioned:
New-Volume -FriendlyName “TwoCopyVolumeFixed” -StoragePoolFriendlyName "SU1_Pool" -FileSystem CSVFS_ReFS -Size 500GB -ResiliencySettingName Mirror -PhysicalDiskRedundancy 1 -ProvisioningType Fixed

#Create a two-copy volume on the storage pool, thinly provisioned:
New-Volume -FriendlyName “TwoCopyVolumeThin” -StoragePoolFriendlyName "SU1_Pool" -FileSystem CSVFS_ReFS -Size 500GB -ResiliencySettingName Mirror -PhysicalDiskRedundancy 1 -ProvisioningType Thin

Validación de los volúmenes

Para comprobar si el volumen está configurado como Rack Level Nested Mirror (RLNM), use el siguiente comando:

spaceutil get-space -name <volume name>

Este comando devuelve detalles sobre el volumen, incluidos los NestedFdType parámetros y MaxFdType .

En la tabla siguiente se muestra la salida esperada para cada configuración:

Esta es una salida de ejemplo de un volumen con reflejo RLNM 4-way habilitado:

spaceutil get-space -name userstorage_1

Id                     : <ID>>
PoolId                 : <PoolID>>
Name                   : UserStorage_1
Description            : ASProtected;ASUser;
Usage                  : Data
DeviceNumber           : -1
InstancePath           : (null)
Health                 : Unknown
OperationalState       : Detached
IsManualAttach         : True
IsClustered            : True
Priority               : 5
DetachReason           : Policy
ProvisionedCapacity    : 4.30 TB
AllocatedCapacity      : 38.0 GB
FootprintOnPool        : 152 GB
Security               : O:BAG:SYD:(A;;FX;;;WD)(A;;FA;;;SY)(A;;FA;;;BA)
ProvisioningType       : Thin
AllocationSize         : 256 MB
MediaType              : Unknown
MinFdType              : Drive
NestedFdType           : Node
MaxFdType              : Rack
ScopeType              : Unknown
NumberOfScopes         : 0
NumberOfMetadataDrives : 0
ResiliencyType         : Mirror
FaultTolerance         : 3
NumberOfCopies         : 4
NumberOfGroups         : 1
NumberOfColumns        : 8
Interleave             : 256 KB
WriteCacheSize         : 0
WriteCacheReserveSize  : 0
ReadCacheSize          : 0
MinimumLogicalCopies   : 1
IsTiered               : False
Flags                  :
SnapshotId             :
ReserveId              :
MaxIops                : 0
MaxIoBandwidth         : 0

Pasos siguientes

• Adición y reparación de nodos a un clúster compatible con bastidores
• Aprovisionamiento de máquinas virtuales en una zona de disponibilidad local

Esta característica está disponible en Azure Local 2510 y versiones posteriores.