Creare un cluster Azure Stack HCI usando Windows PowerShell

  • Articolo

Si applica a: Azure Stack HCI, versioni 22H2 e 21H2

Avviso

Le istruzioni di distribuzione fornite in questo articolo si applicano a una versione precedente, Azure Stack HCI, versione 22H2. Per le nuove distribuzioni, è consigliabile usare la versione più recente disponibile a livello generale, Azure Stack HCI, versione 23H2. Per istruzioni sulla distribuzione, vedere Informazioni sulla distribuzione di Azure Stack HCI versione 23H2.

Questo articolo illustra come usare Windows PowerShell per creare un cluster iperconvergente di Azure Stack HCI che usa Spazi di archiviazione diretta. Se si usa la creazione guidata cluster in Windows Admin Center per creare il cluster, vedere Creare il cluster con Windows Admin Center.

Nota

Se si esegue un'installazione a server singolo di Azure Stack HCI 21H2, usare PowerShell per creare il cluster.

È possibile scegliere tra due tipi di cluster:

  • Cluster standard con uno o due nodi server, tutti residenti in un singolo sito.
  • Cluster esteso con almeno quattro nodi server che si estendono su due siti, con due nodi per sito.

Per lo scenario a server singolo, completare le stesse istruzioni per il server.

Nota

I cluster stretch non sono supportati in una singola configurazione del server.

In questo articolo viene creato un cluster di esempio denominato Cluster1 composto da quattro nodi server denominati Server1, Server2, Server3 e Server4.

Per lo scenario del cluster esteso, si usa ClusterS1 come nome e si usano gli stessi quattro nodi server estesi tra siti Site1 e Site2.

Per altre informazioni sui cluster estesi, vedere Panoramica dei cluster estesi.

Per testare Azure Stack HCI con hardware minimo o senza hardware aggiuntivo, è possibile consultare la Guida alla valutazione di Azure Stack HCI. In questa guida viene illustrata l'esperienza di Azure Stack HCI usando la virtualizzazione annidata all'interno di una macchina virtuale di Azure. In alternativa, provare l'esercitazione Creare un lab basato su VM per Azure Stack HCI per creare un ambiente lab privato personalizzato usando la virtualizzazione annidata in un server scelto per distribuire macchine virtuali che eseguono Azure Stack HCI per il clustering.

Prima di iniziare

Prima di iniziare, assicurarsi di:

Tramite Windows PowerShell

È possibile eseguire PowerShell in locale in una sessione RDP in un server host oppure eseguire PowerShell in remoto da un computer di gestione. Questo articolo illustra l'opzione remota.

Quando si esegue PowerShell da un computer di gestione, includere il -Name parametro o -Cluster con il nome del server o del cluster che si sta gestendo. Inoltre, potrebbe essere necessario specificare il nome di dominio completo (FQDN) quando si usa il -ComputerName parametro per un nodo server.

Sono necessari i cmdlet RSAT (Remote Server Administration Tools) e i moduli di PowerShell per Hyper-V e Clustering di failover. Se i cmdlet e i moduli non sono già disponibili nella sessione di PowerShell nel computer di gestione, è possibile aggiungerli usando il comando seguente: Add-WindowsFeature RSAT-Clustering-PowerShell.

Passaggio 1: Configurare i server

Prima di tutto, connettersi a ognuno dei server, aggiungerli a un dominio (lo stesso dominio in cui si trova il computer di gestione) e installare ruoli e funzionalità necessari.

Passaggio 1.1: Connettersi ai server

Per connettersi ai server, è prima necessario avere connettività di rete, essere aggiunti allo stesso dominio o a un dominio completamente attendibile e disporre delle autorizzazioni amministrative locali per i server.

Aprire PowerShell e usare il nome di dominio completo o l'indirizzo IP del server a cui si vuole connettersi. Dopo aver eseguito il comando seguente in ogni server, verrà richiesto di richiedere una password.

In questo esempio si presuppone che i server siano denominati Server1, Server2, Server3 e Server4:

Enter-PSSession -ComputerName "Server1" -Credential "Server1\Administrator"

Ecco un altro esempio di fare la stessa cosa:

$myServer1 = "Server1"
$user = "$myServer1\Administrator"

Enter-PSSession -ComputerName $myServer1 -Credential $user

Suggerimento

Quando si eseguono comandi di PowerShell dal PC di gestione, è possibile che venga visualizzato un errore come WinRM non può elaborare la richiesta. Per risolvere questo problema, usare PowerShell per aggiungere ogni server all'elenco Host attendibili nel computer di gestione. Questo elenco supporta caratteri jolly, ad Server* esempio.

Set-Item WSMAN:\Localhost\Client\TrustedHosts -Value Server1 -Force

Per visualizzare l'elenco Host attendibili, digitare Get-Item WSMAN:\Localhost\Client\TrustedHosts.

Per svuotare l'elenco, digitare Clear-Item WSMAN:\Localhost\Client\TrustedHost.

Passaggio 1.2: Aggiungere il dominio e aggiungere account di dominio

Nel passaggio precedente è stato connesso a ogni nodo del server con l'account <ServerName>\Administratoramministratore locale .

Per procedere, è necessario aggiungere i server a un dominio e usare l'account di dominio presente nel gruppo Administrators locale in ogni server.

Usare il cmdlet per connettersi a ogni server ed eseguire il Enter-PSSession cmdlet seguente, sostituendo il nome del server, il nome di dominio e le credenziali di dominio:

Add-Computer -NewName "Server1" -DomainName "contoso.com" -Credential "Contoso\User" -Restart -Force

Se l'account amministratore non è membro del gruppo Domain Admins, aggiungere l'account amministratore al gruppo Administrators locale in ogni server oppure aggiungere il gruppo usato per gli amministratori. È possibile usare il comando seguente per eseguire questa operazione:

Add-LocalGroupMember -Group "Administrators" -Member "king@contoso.local"

Passaggio 1.3: Installare ruoli e funzionalità

Il passaggio successivo consiste nell'installare i ruoli e le funzionalità di Windows necessari in ogni server per il cluster. Ecco i ruoli da installare:

  • BitLocker
  • Data Center Bridging
  • Clustering di failover
  • File Server
  • Modulo FS-Data-Deduplicazione
  • Hyper-V
  • PowerShell di Hyper-V
  • Modulo RSAT-Clustering-PowerShell
  • Modulo RSAT-AD-PowerShell
  • NetworkATC
  • NetworkHUD
  • Limite larghezza di banda SMB
  • Replica di archiviazione (per cluster estesi)

Usare il comando seguente per ogni server (se si è connessi tramite Desktop remoto omettere il -ComputerName parametro qui e nei comandi successivi):

Install-WindowsFeature -ComputerName "Server1" -Name "BitLocker", "Data-Center-Bridging", "Failover-Clustering", "FS-FileServer", "FS-Data-Deduplication", "FS-SMBBW", "Hyper-V", "Hyper-V-PowerShell", "RSAT-AD-Powershell", "RSAT-Clustering-PowerShell", "NetworkATC", "NetworkHUD", "Storage-Replica" -IncludeAllSubFeature -IncludeManagementTools

Per eseguire il comando in tutti i server nel cluster contemporaneamente, usare lo script seguente, modificando l'elenco di variabili all'inizio per adattarsi all'ambiente:

# Fill in these variables with your values
$ServerList = "Server1", "Server2", "Server3", "Server4"
$FeatureList = "BitLocker", "Data-Center-Bridging", "Failover-Clustering", "FS-FileServer", "FS-Data-Deduplication", "Hyper-V", "Hyper-V-PowerShell", "RSAT-AD-Powershell", "RSAT-Clustering-PowerShell", "NetworkATC", "NetworkHUD", "FS-SMBBW", "Storage-Replica"

# This part runs the Install-WindowsFeature cmdlet on all servers in $ServerList, passing the list of features in $FeatureList.
Invoke-Command ($ServerList) {
    Install-WindowsFeature -Name $Using:Featurelist -IncludeAllSubFeature -IncludeManagementTools
}

Riavviare quindi tutti i server:

$ServerList = "Server1", "Server2", "Server3", "Server4"
Restart-Computer -ComputerName $ServerList -WSManAuthentication Kerberos

Passaggio 2: Prep per la configurazione del cluster

Verificare quindi che i server siano pronti per il clustering.

Come controllo di integrità, prendere in considerazione l'esecuzione dei comandi seguenti per assicurarsi che i server non appartengano già a un cluster:

Usare Get-ClusterNode per visualizzare tutti i nodi:

Get-ClusterNode

Usare Get-ClusterResource per visualizzare tutti i nodi del cluster:

Get-ClusterResource

Usare Get-ClusterNetwork per visualizzare tutte le reti del cluster:

Get-ClusterNetwork

Passaggio 2.1: Preparare le unità

Prima di abilitare Spazi di archiviazione diretta, assicurarsi che le unità permanenti siano vuote. Eseguire lo script seguente per rimuovere tutte le partizioni precedenti e altri dati.

Nota

Escludere dallo script tutte le unità rimovibili collegate a un nodo server. Se si esegue questo script in locale da un nodo server, ad esempio, non è necessario cancellare l'unità rimovibile che potrebbe essere in uso per distribuire il cluster.

# Fill in these variables with your values
$ServerList = "Server1", "Server2", "Server3", "Server4"

Invoke-Command ($ServerList) {
    Update-StorageProviderCache
    Get-StoragePool | ? IsPrimordial -eq $false | Set-StoragePool -IsReadOnly:$false -ErrorAction SilentlyContinue
    Get-StoragePool | ? IsPrimordial -eq $false | Get-VirtualDisk | Remove-VirtualDisk -Confirm:$false -ErrorAction SilentlyContinue
    Get-StoragePool | ? IsPrimordial -eq $false | Remove-StoragePool -Confirm:$false -ErrorAction SilentlyContinue
    Get-PhysicalDisk | Reset-PhysicalDisk -ErrorAction SilentlyContinue
    Get-Disk | ? Number -ne $null | ? IsBoot -ne $true | ? IsSystem -ne $true | ? PartitionStyle -ne RAW | % {
        $_ | Set-Disk -isoffline:$false
        $_ | Set-Disk -isreadonly:$false
        $_ | Clear-Disk -RemoveData -RemoveOEM -Confirm:$false
        $_ | Set-Disk -isreadonly:$true
        $_ | Set-Disk -isoffline:$true
    }
    Get-Disk | Where Number -Ne $Null | Where IsBoot -Ne $True | Where IsSystem -Ne $True | Where PartitionStyle -Eq RAW | Group -NoElement -Property FriendlyName
} | Sort -Property PsComputerName, Count

Passaggio 2.2: Configurazione del cluster di test

In questo passaggio assicurarsi che i nodi del server siano configurati correttamente per creare un cluster. Il Test-Cluster cmdlet viene usato per eseguire test per verificare che la configurazione sia adatta per funzionare come cluster iperconvergente. Nell'esempio seguente viene usato il -Include parametro, con le categorie specifiche di test specificate per garantire che i test corretti siano inclusi nella convalida.

Test-Cluster -Node $ServerList -Include "Storage Spaces Direct", "Inventory", "Network", "System Configuration"

Passaggio 3: Creare il cluster

È ora possibile creare un cluster con i nodi del server convalidati nei passaggi precedenti.

Quando si crea il cluster, potrebbe essere visualizzato un avviso che indica che "There were issues while creating the clustered role that may prevent it from starting. For more information, view the report file below." è possibile ignorare in modo sicuro questo avviso. Questo avviso è dovuto a nessun disco disponibile per il server di controllo del cluster. Il server di controllo del cluster viene creato in passaggi successivi.

Nota

Se i server usano indirizzi IP statici, modificare il comando seguente per riflettere l'indirizzo IP statico aggiungendo il parametro seguente e specificando l'indirizzo IP: -StaticAddress <X.X.X.X>;.

$ClusterName="cluster1" 
New-Cluster -Name $ClusterName –Node $ServerList –nostorage

Dopo aver creato il cluster, è possibile che il nome del cluster venga replicato tramite DNS nel dominio, soprattutto se i server del gruppo di lavoro vengono appena aggiunti ad Active Directory. Anche se il cluster potrebbe essere visualizzato in Windows Admin Center, potrebbe non essere ancora disponibile per la connessione.

Una buona verifica per assicurarsi che tutte le risorse del cluster siano online:

Get-Cluster -Name $ClusterName | Get-ClusterResource

Se la risoluzione del cluster non ha esito positivo dopo qualche tempo, nella maggior parte dei casi è possibile connettersi usando il nome di uno dei server cluster anziché il nome del cluster.

Passaggio 4: Configurare la rete host

Microsoft consiglia di usare Network ATC per distribuire la rete host se si esegue Azure Stack HCI versione 21H2 o successiva. In caso contrario, vedere Requisiti di rete host per requisiti e informazioni specifiche.

Network ATC può automatizzare la distribuzione della configurazione di rete prevista se si specificano uno o più tipi di finalità per le schede. Per altre informazioni sui tipi di finalità specifici, vedere: Tipi di traffico di rete.

Passaggio 4.1: Esaminare schede fisiche

In uno dei nodi del cluster eseguire Get-NetAdapter per esaminare le schede fisiche. Assicurarsi che ogni nodo nel cluster abbia gli stessi adattatori fisici denominati e che segnalano lo stato "Up".

Get-NetAdapter -Name pNIC01, pNIC02 -CimSession $ClusterName | Select Name, PSComputerName

Se un nome di adattatore fisico varia tra i nodi del cluster, è possibile rinominarlo usando Rename-NetAdapter.

Rename-NetAdapter -Name oldName -NewName newName

Passaggio 4.2: Configurare una finalità

In questo esempio viene creata una finalità che specifica la finalità di calcolo e archiviazione. Per altri esempi di finalità, vedere Semplificare la rete host con Network ATC .

Eseguire il comando seguente per aggiungere i tipi di finalità di archiviazione e calcolo a pNIC01 e pNIC02. Si noti che si specifica il -ClusterName parametro .

Add-NetIntent -Name Cluster_ComputeStorage -Compute -Storage -ClusterName $ClusterName -AdapterName pNIC01, pNIC02

Il comando deve restituire immediatamente dopo una verifica iniziale.

Passaggio 4.3: Convalidare la distribuzione delle finalità

Eseguire il Get-NetIntent cmdlet per visualizzare la finalità del cluster. Se si dispone di più finalità, è possibile specificare il Name parametro per visualizzare i dettagli solo di una finalità specifica.

Get-NetIntent -ClusterName $ClusterName

Per visualizzare lo stato del provisioning della finalità, eseguire il Get-NetIntentStatus comando:

Get-NetIntentStatus -ClusterName $ClusterName -Name Cluster_ComputeStorage

Si noti il parametro di stato che mostra Provisioning, Convalida, Esito positivo, Errore.

Lo stato deve visualizzare l'esito positivo in pochi minuti. Se lo stato dell'esito positivo non si verifica o viene visualizzato un errore del parametro di stato, controllare il visualizzatore eventi per i problemi.

Nota

In questo momento, Network ATC non configura gli indirizzi IP per una delle schede gestite. Al Get-NetIntentStatus termine dello stato dei report, è necessario aggiungere indirizzi IP alle schede.

Passaggio 5: Configurare i siti (cluster esteso)

Questa attività si applica solo se si sta creando un cluster esteso tra due siti con almeno due server in ogni sito.

Nota

Se in precedenza sono stati configurati siti e servizi di Active Directory, non è necessario creare manualmente i siti, come descritto nella sezione successiva.

Passaggio 5.1: Creare siti

Nel cmdlet seguente, FaultDomain è semplicemente un altro nome per un sito. Questo esempio usa "ClusterS1" come nome del cluster esteso.

New-ClusterFaultDomain -CimSession $ClusterName -FaultDomainType Site -Name "Site1"

New-ClusterFaultDomain -CimSession $ClusterName -FaultDomainType Site -Name "Site2"

Usare il Get-ClusterFaultDomain cmdlet per verificare che entrambi i siti vengano creati per il cluster.

Get-ClusterFaultDomain -CimSession $ClusterName

Passaggio 5.2: Assegnare nodi server

Successivamente, si assegnano i quattro nodi del server ai rispettivi siti. Nell'esempio seguente, Server1 e Server2 vengono assegnati a Site1, mentre Server3 e Server4 vengono assegnati a Site2.

Set-ClusterFaultDomain -CimSession $ClusterName -Name "Server1", "Server2" -Parent "Site1"

Set-ClusterFaultDomain -CimSession $ClusterName -Name "Server3", "Server4" -Parent "Site2"

Usando il Get-ClusterFaultDomain cmdlet, verificare che i nodi si trovino nei siti corretti.

Get-ClusterFaultDomain -CimSession $ClusterName

Passaggio 5.3: Impostare un sito preferito

È anche possibile definire un sito preferito globale, ovvero che le risorse e i gruppi specificati devono essere eseguiti nel sito preferito. Questa impostazione può essere definita a livello di sito usando il comando seguente:

(Get-Cluster).PreferredSite = "Site1"

La specifica di un sito preferito per i cluster estesi offre i vantaggi seguenti:

  • Avvio a freddo : durante un avvio sporadico, le macchine virtuali vengono posizionate nel sito preferito

  • Voto quorum

    • Con un quorum dinamico, il peso viene ridotto dal sito passivo (replicato) per assicurarsi che il sito preferito superi se tutte le altre cose sono uguali. Inoltre, i nodi del server vengono eliminati dal sito passivo prima durante il raggruppamento dopo eventi come errori di connettività di rete asimmetrica.

    • Durante una suddivisione quorum di due siti, se il server di controllo del cluster non può essere contattato, il sito preferito viene automaticamente eletto per vincere. I nodi del server nel sito passivo e quindi eliminare l'appartenenza al cluster consentendo al cluster di sopravvivere a una perdita simultanea del 50% dei voti.

Il sito preferito può essere configurato anche a livello di ruolo o gruppo del cluster. In questo caso, è possibile configurare un sito preferito diverso per ogni gruppo di macchine virtuali che consente l'attivazione e la preferenza di un sito per macchine virtuali specifiche.

Passaggio 5.4: Configurare Stretch Clustering con Network ATC

Dopo la versione 22H2, è possibile usare Network ATC per configurare Stretch clustering. Network ATC aggiunge Stretch come tipo di finalità dalla versione 22H2. Per distribuire una finalità con Stretch clustering con Network ATC, eseguire il comando seguente:

Add-NetIntent -Name StretchIntent -Stretch -AdapterName "pNIC01", "pNIC02"

Una finalità di estensione può essere combinata anche con altre finalità, quando si distribuisce con Network ATC.

SiteOverrides

In base alla procedura 5.1-5.3, è possibile aggiungere i siti predefiniti alla finalità estesa distribuita con Network ATC. Network ATC gestisce questa operazione usando SiteOverrides. Per creare un siteOverride, eseguire:

 $siteOverride = New-NetIntentSiteOverrides

Dopo aver creato il sitoOverride, è possibile impostare qualsiasi proprietà per il sitoOverride. Assicurarsi che la proprietà name del sitoOverride abbia lo stesso nome, come il nome del sito in ClusterFaultDomain. Una mancata corrispondenza dei nomi tra ClusterFaultDomain e il sitoOverride comporta l'applicazione del sitoOverride.

Le proprietà che è possibile impostare per un determinato sitoOverride sono: Name, StorageVlan e StretchVlan. Ad esempio, si creano 2 siteOverrides per i due siti- site1 e site2 usando:

$siteOverride1 = New-NetIntentSiteOverrides
$siteoverride1.Name = "site1"
$siteOverride1.StorageVLAN = 711
$siteOverride1.StretchVLAN = 25

$siteOverride2 = New-NetIntentSiteOverrides
$siteOverride2.Name = "site2"
$siteOverride2.StorageVLAN = 712
$siteOverride2.StretchVLAN = 26

È possibile eseguire $siteOverride1, $siteOverride2 nella finestra di PowerShell per assicurarsi che tutte le proprietà siano impostate nel modo desiderato.

Infine, per aggiungere uno o più sitiOverride alla finalità, eseguire:

Add-NetIntent -Name StretchIntent -Stretch -AdapterName "pNIC01" , "pNIC02" -SiteOverrides $siteOverride1, $siteOverride2

Passaggio 6: Abilitare Spazi di archiviazione diretta

Dopo aver creato il cluster, usare il Enable-ClusterStorageSpacesDirect cmdlet, che abiliterà Spazi di archiviazione diretta e eseguirà automaticamente le operazioni seguenti:

  • Creare un pool di archiviazione: Crea un pool di archiviazione per il cluster con un nome simile a "Pool di archiviazione Cluster1".

  • Creare un disco Cronologia prestazioni cluster: Crea un disco virtuale Cronologia prestazioni cluster nel pool di archiviazione.

  • Creare volumi di dati e log: Crea un volume di dati e un volume di log nel pool di archiviazione.

  • Configurare Spazi di archiviazione diretta cache: se è disponibile più di un tipo di supporto (unità) per Spazi di archiviazione diretta, consente il più veloce come dispositivi cache (lettura e scrittura nella maggior parte dei casi).

  • Creare livelli: Crea due livelli come livelli predefiniti. Uno è denominato "Capacità" e l'altro "Prestazioni". Il cmdlet analizza i dispositivi e configura ogni livello con una combinazione di tipi di dispositivi e resilienza.

Per lo scenario a server singolo, l'unico FaultDomainAwarenessDefault è PhysicalDisk. Enable-ClusterStorageSpacesDirect il cmdlet rileva un singolo server e configura automaticamente FaultDomainAwarenessDefault come PhysicalDisk durante l'abilitazione.

Per i cluster estesi, anche il Enable-ClusterStorageSpacesDirect cmdlet:

  • Verificare se i siti sono configurati
  • Determinare quali nodi sono in quali siti
  • Determina l'archiviazione disponibile per ogni nodo
  • Verifica se la funzionalità replica di archiviazione è installata in ogni nodo
  • Crea un pool di archiviazione per ogni sito e lo identifica con il nome del sito
  • Crea volumi di dati e log in ogni pool di archiviazione- uno per sito

Il comando seguente abilita Spazi di archiviazione diretta in un cluster a più nodi. È anche possibile specificare un nome descrittivo per un pool di archiviazione, come illustrato di seguito:

Enable-ClusterStorageSpacesDirect -PoolFriendlyName "$ClusterName Storage Pool" -CimSession $ClusterName

Ecco un esempio di disabilitazione della cache di archiviazione in un cluster a nodo singolo:

Enable-ClusterStorageSpacesDirect -CacheState Disabled

Per visualizzare i pool di archiviazione, usare il comando seguente:

Get-StoragePool -CimSession $ClusterName

Dopo aver creato il cluster

Dopo aver creato il cluster, sono necessarie altre attività importanti:

Passaggi successivi