Creare un cluster HCI Azure Stack usando Windows PowerShell

Si applica a: Azure Stack HCI, versione 22H2

Important

Azure Stack HCI ora fa parte di Azure Locale. Tuttavia, le versioni precedenti di Azure Stack HCI, ad esempio 22H2 continueranno a fare riferimento Azure Stack HCI e non rifletteranno la modifica del nome. Altre informazioni.

Warning

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 di Azure Locale, vedere Informazioni sulla distribuzione di Azure Locale.

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

Note

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 del server, tutti che risiedono in un singolo sito.
  • Cluster esteso con almeno quattro nodi del 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 singolo.

Note

I cluster estesi non sono supportati in una configurazione a server singolo.

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, clusterS1 viene usato come nome e si usano gli stessi quattro nodi del server estesi tra i siti Site1 e Site2.

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

Prima di iniziare

Prima di iniziare, assicurarsi di:

Utilizzo di 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 e i moduli PowerShell di RSAT (Remote Server Administration Tools) per Hyper-V e Failover Clustering. 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 i ruoli e le funzionalità necessari.

Passaggio 1.1: Connettersi ai server

Per connettersi ai server, è prima necessario disporre della 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 ci si vuole connettere. Verrà richiesta una password dopo aver eseguito il comando seguente in ogni server.

Per 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 questa operazione:

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

Enter-PSSession -ComputerName $myServer1 -Credential $user

Tip

Quando si eseguono comandi di PowerShell dal PC di gestione, è possibile che venga visualizzato un errore come WinRM non è in grado di elaborare la richiesta. Per risolvere questo problema, usare PowerShell per aggiungere ogni server all'elenco Host attendibili nel computer di gestione. Questo elenco supporta i caratteri jolly, come Server*, ad 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 effettuato l'accesso a ciascun nodo del server con l'account amministratore locale <ServerName>\Administrator.

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

Usare il Enter-PSSession cmdlet per connettersi a ogni server ed eseguire il 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 o, meglio ancora, aggiungere il gruppo usato per gli amministratori. A tale scopo, è possibile usare il comando seguente:

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à necessari Windows in ogni server per il cluster. Devono essere installati i seguenti ruoli:

  • BitLocker
  • Collegamento del Data Center
  • Raggruppamento di Failover
  • Server di File
  • Modulo FS-Data-Deduplication
  • Hyper-V
  • Hyper-V PowerShell
  • modulo RSAT-Clustering-PowerShell
  • modulo RSAT-AD-PowerShell
  • NetworkATC
  • 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", "Storage-Replica" -IncludeAllSubFeature -IncludeManagementTools

Per eseguire il comando in tutti i server del 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", "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: Preparazione per la configurazione del cluster

Verificare quindi che i server siano pronti per il clustering.

Come controllo della integrità, è consigliabile eseguire i 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 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 eventuali partizioni precedenti e altri dati.

Note

Escludere dallo script tutte le unità rimovibili collegate a un nodo server. Se si esegue questo script in locale da un nodo del server, ad esempio, non si vuole cancellare l'unità rimovibile usata 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: Testare la configurazione del cluster

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 assicurarsi 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 all'assenza di dischi disponibili per il server di controllo del cluster. Il witness del cluster viene creato nelle fasi successive.

Note

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, la replica del nome del cluster tramite DNS nel dominio può richiedere del tempo, soprattutto se i server del gruppo di lavoro vengono appena aggiunti a Active Directory. Anche se il cluster potrebbe essere visualizzato in Windows Admin Center, potrebbe non essere ancora disponibile per la connessione.

Verificare che tutte le risorse del cluster siano online:

Get-Cluster -Name $ClusterName | Get-ClusterResource

Se la risoluzione del cluster non riesce dopo un certo periodo di tempo, nella maggior parte dei casi è possibile connettersi usando il nome di uno dei server in 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 specifici.

Network ATC può automatizzare l'implementazione della configurazione di rete desiderata se si specificano uno o più tipi di intento per le schede di rete. Per altre informazioni su tipi di finalità specifici, vedere Tipi di traffico di rete.

Passaggio 4.1: Esaminare gli adattatori fisici

In uno dei nodi del cluster, eseguire Get-NetAdapter per esaminare gli adattatori fisici. Assicurarsi che ogni nodo del cluster abbia adattatori fisici con lo stesso nome e che riportino 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: Convalida della distribuzione dell'intento

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 vedere lo stato di provisioning dell'intent, eseguire il comando Get-NetIntentStatus:

Get-NetIntentStatus -ClusterName $ClusterName -Name Cluster_ComputeStorage

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

Lo stato dovrebbe visualizzare l'esito positivo in pochi minuti. Se lo stato di esito positivo non si verifica o viene visualizzato un errore del parametro di stato, controllare la presenza di problemi nel Visualizzatore eventi.

Note

Al momento, Network ATC non configura gli indirizzi IP per le schede gestite. Una volta che Get-NetIntentStatus riporta lo stato "completato", è necessario aggiungere gli indirizzi IP agli adattatori.

Passaggio 5: Configurare siti (cluster esteso)

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

Note

Se si è configurato Active Directory siti e servizi in anticipo, 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"

Usa il Get-ClusterFaultDomain cmdlet per verificare che entrambi i siti siano stati creati nel 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, il che significa 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 a freddo, le macchine virtuali vengono inserite nel sito preferito

  • Voto a quorum

    • Con un quorum dinamico, la ponderazione del sito passivo (replicato) viene ridotta per prima per garantire che il sito preferito rimanga attivo, a parità di tutte le altre condizioni. Inoltre, i nodi del server vengono rimossi per primi dal sito passivo durante il nuovo raggruppamento dopo eventi quali guasti di connettività di rete asimmetrica.

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

Il sito preferito può anche essere configurato a livello di ruolo o gruppo del cluster. In questo caso, è possibile configurare un sito preferito diverso per ogni gruppo di macchine virtuali, in modo che un sito sia attivo e preferito 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 intent a partire dalla versione 22H2. Per distribuire un intento di Stretch clustering con Network ATC, eseguire il comando seguente:

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

Una finalità stretch può anche essere combinata con altre finalità, durante la distribuzione con Network ATC.

SiteOverrides

Seguendo i passaggi 5.1-5.3, è possibile aggiungere i siti già creati allo stretch intent distribuito con Network ATC. Network ATC gestisce questa operazione usando SiteOverrides. Per creare un siteOverride, eseguire:

 $siteOverride = New-NetIntentSiteOverrides

Una volta creato il siteOverride, è possibile impostare qualsiasi proprietà per il siteOverride. Assicurati che la proprietà name di siteOverride abbia esattamente lo stesso nome del sito presente in ClusterFaultDomain. Una mancata corrispondenza dei nomi tra ClusterFaultDomain e siteOverride determina che siteOverride non viene applicato.

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ù siteOverrides al tuo intento, esegui:

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 "Cluster1 Storage Pool".

  • Crea un disco della cronologia delle prestazioni del cluster: Crea un disco virtuale della cronologia delle prestazioni del 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 le cache di Spazi di archiviazione diretta: se è disponibile più di un tipo di supporto (unità) per Spazi di archiviazione diretta, vengono usati quelli più veloci come dispositivi di cache (per la lettura e la 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, il cmdlet Enable-ClusterStorageSpacesDirect eseguirà anche:

  • Verificare se i siti sono configurati
  • Determinare quali nodi si trovano in quali siti
  • Determina l'archiviazione disponibile per ogni nodo
  • Verifica se la funzionalità Storage Replica è installata su 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 multinodo. È 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, è necessario completare altre attività importanti:

Passaggi successivi

  • Last updated on