Deploy de Storage Spaces Direct – Parte 3
Microsoft
Deploy de Storage Spaces Direct – Parte 3
Microsoft

Deploy de Storage Spaces Direct – Parte 3

¡Saludos, comunidad de WitcherIT!

Vamos a continuar con la serie de post sobre Storage Spaces Direct (S2D). Esta vez veremos cómo hacer el deploy en un cluster virtual. Este tipo de implementación ofrece almacenamiento compartido virtual en un conjunto de máquinas virtuales sobre una nube privada o pública. Esto nos permite utilizar soluciones de alta disponibilidad de aplicaciones.

Primero, veremos algunos requisitos previos antes de ir directo a meter las manos, así que les pido algo de paciencia porque ya llegaremos a lo interesante.

Requerimientos para un Cluster virtual

Las siguientes consideraciones se aplican al implementar Storage Spaces Direct en un entorno virtualizado:

  • Mínimo de dos nodos y máximo de tres nodos.
  • Las implementaciones de dos nodos deben configurar un witness (Cloud Witness o File Share Witness).
  • Las implementaciones de tres nodos pueden tolerar un nodo inactivo y la pérdida de uno o más discos en otro nodo.
  • La configuración de las máquinas virtuales que se van a implementar en fault domains:
    • Azure – Configure the Availability Set.
    • Hyper-V – Se debe configurar la separación de las máquinas virtuales entre nodos: AntiAffinityClassNames.
    • VMware – Se debe crear una regla de VM-VM Anti-Affinity rule para separar las VMs en los host ESXi. Las VMs deben usar el adaptador SCSI paravirtual (PVSCSI).
  • Se requiere un mínimo de dos discos virtuales por máquina virtual.
  • Deshabilitamos la funcionabilidad de reemplazo automático de unidades de disco con el siguiente cmdlet de PowerShell:
    • Get-storagesubsystem clus* | set-storagehealthsetting -name “System.Storage.PhysicalDisk.AutoReplace.Enabled” -value “False”
  • Para proporcionar una mayor resistencia a la posible latencia de almacenamiento de discos VHD/VHDX/VMDK en clústeres virtuales, debemos aumentar el valor de tiempo de Storage Spaces I/O:
  • Para esto vamos a la siguiente ruta desde regedit: HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\spaceport\\Parameters\\HwTimeout
  • El equivalente decimal de 7530 hexadecimal es 30000, que son 30 segundos. El valor predeterminado es 1770 hexadecimal o 6000 decimal, que son 6 segundos. Cambiamos el valor a 7530.

Las siguientes características no se admiten cuando se usa Storage Spaces Direct en un cluster virtual:

  • Host level virtual disk snapshot/restore – Se recomienda usar un software de backup para respaldar los datos sobre Storage Spaces Direct volumes.
  • Host level virtual disk size change – No podemos modificar el tamaño de los discos, en vez de eso, podemos agregar más discos a las máquinas virtuales. Se recomienda utilizar discos virtuales del mismo tamaño y características que los discos virtuales actuales.

Detalles del laboratorio

Para este laboratorio, trataré de mostrar de la manera más simple que me es posible la implementación de Storage Spaces Direct. En este laboratorio usaré 3 servidores Windows Server 2022 Data Center virtuales sobre mi servidor ESXi.

Las características de mi servidor (para esta demostración) serán las siguientes:

  • CPU: 4 vCPU
  • Memoria: 12 GB
  • Disk : 90GB OS Boot, 2x 100GB S2D
  • Network: 2x vNIC (Management Network, Heartbeat Network)
  • Controladora: VMware Paravirtual SCSI

Desde la vista administrador de discos de cada uno de mis servidores, puedo ver los discos agregados de 100 GB.

Creamos los registros DNS necesarios para nuestros 3 host y para el Cluster.

Conectar servidores al dominio

Para poder administrar Storage Spaces Direct, será necesario agregar nuestro servidores a un dominio y usar una cuenta de dominio de Servicios de Active Directory que esté en el grupo Administradores de cada servidor.

$ Add-Computer -NewName “hyper01” -DomainName “witcherit.local” -Credential “witcherit.local\Administrator” -Restart -Force

Si nuestra cuenta de administrador de almacenamiento no es miembro del grupo Administradores de dominio, podemos realizarlo con el siguiente comando de PowerShell.

$ Net localgroup Administrators witcherit.local\Administrator /add

Podemos validar o agregar directamente nuestro usuario usando Windows Computer Management. Para esto, abrimos un “Run” pulsando las teclas “Windows Key + R“

Ejecutamos el comando: compmgmt.msc

Vamos a Local Users and Groups > Groups > Administrators.

Para este ejemplo, tendré 3 servidores con la siguiente configuración base:

  • Servidores agregados al dominio
  • 2 tarjetas de red
    • 1 NIC de Management Network
    • 1 NIC de Heartbeat Network

Servidor: Hyper01

Servidor: Hyper02

Servidor: Hyper03

Conexión a servidores remotamente

Si vamos a realizar la implementación de forma remota desde un sistema de administración, es posible que obtengamos un error WinRM. Para solucionar este problema, usamos Windows PowerShell para agregar cada servidor a la lista de hosts de confianza en el equipo de administración:

Para este ejemplo, realizaré la instalación desde el servidor hyper01

Si queremos dar permisos a todos los host, usamos el siguiente comando (Solo usar en laboratorios):

$ Set-Item WSMan:\localhost\Client\TrustedHosts -Value “*”

Si queremos permitir una lista concreta de host podemos usar “.Server*“.

$ Set-Item WSMAN:\Localhost\Client\TrustedHosts -Value hyper0* -Force

Podemos verificar la lista de hosts de confianza con el comando:

$ Get-Item WSMAN:\Localhost\Client\TrustedHosts

Instalar roles y características

El siguiente paso será poder instalar los roles en cada uno de los servidores. A continuación procederemos a instalar los siguientes roles:

  • Failover Clustering
  • Hyper-V
  • Hyper-V-PowerShell

Para instalar a través de PowerShell en un solo servidor usamos el siguiente comando:

$ Install-WindowsFeature -Name “Hyper-V”, “Failover-Clustering”, “Hyper-V-PowerShell” -IncludeManagementTools

Para ejecutar el comando en todos los servidores del clúster al mismo tiempo, usamos el siguiente script modificando las variables que se adapten a su entorno:

# Fill in these variables with your values $ServerList = “hyper01”, “hyper02”, “hyper03” $FeatureList = “Hyper-V”, “Failover-Clustering”, “Hyper-V-PowerShell”   # This part runs the Install-WindowsFeature cmdlet on all servers in $ServerList, passing the list of features into the script block with the “Using” scope modifier so you don’t have to hard-code them here. Invoke-Command ($ServerList) {     Install-WindowsFeature -Name $Using:Featurelist -IncludeManagementTools }

Salida de la ejecución del script.

Configuración de Storage Spaces Direct

Debemos asegurarnos de que las unidades estén vacías: sin particiones antiguas ni otros datos. Ejecutamos el script que detallo un poco más abajo, sustituyendo los nombres por los de nuestros servidores para eliminar todas las particiones antiguas u otros datos.

Nota: Este script eliminará permanentemente cualquier dato en cualquier unidad que no sea la unidad de arranque del sistema operativo. Este comando es tomado desde la documentación oficial de Microsoft.

!Importante!

Si ejecutamos este script con discos que tengan datos vamos perder su contenido, mucho cuidado!!!

# Fill in these variables with your values
$ServerList = “hyper01”, “hyper02”, “hyper03”
  foreach ($server in $serverlist) {    
Invoke-Command ($server) {   
      # Check for the Azure Temporary Storage volume
        $azTempVolume = Get-Volume -FriendlyName “Temporary Storage” -ErrorAction SilentlyContinue
        If ($azTempVolume) {
            $azTempDrive = (Get-Partition -DriveLetter $azTempVolume.DriveLetter).DiskNumber   
      }         
  # Clear and reset the disks
        $disks = Get-Disk | Where-Object {
            ($_.Number -ne $null -and $_.Number -ne $azTempDrive -and !$_.IsBoot -and !$_.IsSystem -and $_.PartitionStyle -ne “RAW”)   
      }        
$disks | ft Number,FriendlyName,OperationalStatus
        If ($disks) {
            Write-Host “This action will permanently remove any data on any drives other than the operating system boot drive!`nReset disks? (Y/N)”            
$response = read-host            
if ( $response.ToLower() -ne “y” ) { exit }              

$disks | % {
            $_ | Set-Disk -isoffline:$false
            $_ | Set-Disk -isreadonly:$false
            $_ | Clear-Disk -RemoveData -RemoveOEM -Confirm:$false -verbose
            $_ | Set-Disk -isreadonly:$true            
$_ | Set-Disk -isoffline:$true         }          

#Get-PhysicalDisk | Reset-PhysicalDisk            

}        
Get-Disk | Where-Object {            
($_.Number -ne $null -and $_.Number -ne $azTempDrive -and !$_.IsBoot -and !$_.IsSystem -and $_.PartitionStyle -eq “RAW”)        
} | Group -NoElement -Property FriendlyName    
}
}

Salida de la ejecución del script usando máquinas virtuales.

Validar el clúster

En este paso, ejecutará la herramienta de validación de clústeres para asegurarse de que los nodos de servidor están configurados correctamente para crear un Storage Spaces Direct. Cuando se ejecuta la validación de clúster (Test-Cluster), se ejecutan las pruebas que comprueban que la configuración parece adecuada para funcionar correctamente como failover cluster.

Podemos validar los servidores que serán parte del clúster usando Storage Spaces Direct Cluster con el comando:

$ Test-Cluster -Node hyper01, hyper02, hyper03 -Include “Storage Spaces Direct”, “Inventory”, “Network”, “System Configuration”

Crear nuevo clúster

Desde la consola de Server Manager vamos a Tools > Failover Cluster Manager para poder comenzar con la creación de nuestro nuevo cluster.

Dentro de la consola vamos a la opción “Create Cluster“.

Comenzamos con Wizard de creación de un nuevo cluster.

Agregamos nuestros servidores usando la opción “Browse..“.

Seleccionamos un nombre para nuestro Cluster y la red por la cual administraremos nuestro Cluster.

Confirmamos la configuración, pero nos aseguramos de dejar desmarcada la casilla “Add all eligible storage to the cluster“.

Esperamos que termine la configuración del clúster.

Una vez finalizada la configuración, pulsamos “Finish“.

Habilitar Storage Spaces Direct

Una vez que tengamos nuestro clúster creado, debemos ejecutar desde PowerShell el siguiente comando:

$ Enable-ClusterStorageSpacesDirect

Detalles del comando

  • Create a pool: Crea un único grupo grande que tiene un nombre como “S2D en el clúster1”.
  • Configures the Storage Spaces Direct caches: Si hay más de un tipo de medio (unidad) disponible para el uso de Espacios de almacenamiento directo, habilita los dispositivos de caché más rápidos (lectura y escritura en la mayoría de los casos).
  • Tiers: Crea dos niveles como niveles predeterminados. Uno se llama “Capacidad” y el otro se llama “Rendimiento“. El cmdlet analiza los dispositivos y configura cada nivel con la combinación de tipos de dispositivos y resistencia.

Puede demorar un par de minutos, así que paciencia.

Para este ejemplo, tengo un Warning por no tener configurados discos para caché.

Si vamos a la consola de Failover Cluster Manager podemos validar la creación de nuestro nuevo pool.

Creación de volúmenes

En este punto veremos cómo crear un nuevo volumen desde PowerShell haciendo uso del cmdlet New-Volume para creación de nuevos volúmenes. Este único cmdlet crea automáticamente el disco virtual, lo particiona y lo formatea, crea el volumen con el nombre correspondiente y lo agrega a los volúmenes compartidos del clúster, todo en un solo paso.

El cmdlet New-Volume tiene cuatro parámetros que siempre tendremos que proporcionar información:

  • FriendlyName: Cualquier nombre que deseemos, por ejemplo, “Datastore01“
  • FileSystem: Ya sea CSVFS_ReFS (recomendado para todos los volúmenes; necesario para mirror-accelerated parity volumes) o CSVFS_NTFS
  • StoragePoolFriendlyName: El nombre del storage pool, por ejemplo, “S2D en ClusterName“
  • Size: El tamaño del volumen, por ejemplo “10TB” o “100Gb“

Creación de volúmenes con 1 a 3 servidores

Una forma simple que encontré en la documentación de Microsoft es si la implementación solo tiene uno o dos servidores, espacios de almacenamiento directo usará automáticamente la creación de reflejo bidireccional para la resistencia. Si la implementación solo tiene tres servidores, utilizará automáticamente la creación de reflejos tridireccionales.

$ New-Volume -FriendlyName “Datastore01” -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D* -Size 100gb

Si revisamos ahora desde nuestra consola de Failover Cluster Manager podremos ver el disco que creamos con el comando anterior.

Creación de volúmenes con 4+ servidores

Si contamos con cuatro o más servidores, podemos usar el parámetro opcional ResiliencySettingName para elegir el tipo de resiliencia. En mi caso no cuento con 4 servidores así que solo mostraré los comandos.

  • ResiliencySettingName: Ya sea Mirror o Parity.

En este ejemplo se crearan dos volúmenes:

  • Volume2: Usa three-way mirroring
  • Volume3: Usa la paridad dual (a menudo denominada “erasure coding”).

$ New-Volume -FriendlyName “Volume2” -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D* -Size 100Gb -ResiliencySettingName Mirror

$ New-Volume -FriendlyName “Volume3” -FileSystem CSVFS_ReFS -StoragePoolFriendlyName S2D* -Size 1TB -ResiliencySettingName Parity

Cabe mencionar que la creación de volúmenes que revisamos en este post es solo una pequeña pincelada, ya que este apartado es mucho más complejo y contempla muchas variables más. Si quieren indagar más sobre esto pueden revisar el siguiente link: Create volumes on Azure Stack HCI and Windows Server clusters

Lista de post de esta serie:

  • Storage Spaces Direct (S2D) – Parte 1
  • Storage Spaces Direct (S2D) – ¿Por Qué Preocuparse por la Tolerancia a Fallos? – Parte 2
  • Deploy de Storage Spaces Direct – Parte 3

Espero que esta información pueda ser de ayuda, y cualquier duda o sugerencia la dejan en los comentarios. Saludos.

Leave a Reply

Your email address will not be published. Required fields are marked *