Resilienza annidata per Spazi di archiviazione diretta
Si applica a: Azure Stack HCI, versioni 22H2 e 21H2; Windows Server 2022 e Windows Server 2019
La resilienza annidata è una funzionalità di Spazi di archiviazione diretta in Azure Stack HCI e Windows Server. Consente a un cluster a due server di resistere a più errori hardware contemporaneamente senza perdita di disponibilità di archiviazione, in modo che gli utenti, le app e le macchine virtuali continuino a essere eseguiti senza interruzioni. Questo articolo illustra il funzionamento della resilienza annidata, fornisce istruzioni dettagliate per iniziare e rispondere alle domande più frequenti.
Prima di iniziare
Prendere in considerazione la resilienza annidata se:
- Il cluster esegue uno di questi sistemi operativi: Azure Stack HCI, versione 21H2, Azure Stack HCI, versione 20H2, Windows Server 2022 o Windows Server 2019; E
- Il cluster ha esattamente due nodi server.
Non è possibile usare la resilienza annidata se:
- Il cluster viene eseguito Windows Server 2016; o
- Il cluster ha solo un singolo nodo server o ha tre o più nodi del server.
Perché la resilienza annidata
I volumi che usano la resilienza annidata possono rimanere online e accessibili anche se si verificano più errori hardware contemporaneamente, a differenza della resilienza con mirroring bidirezionale classica. Ad esempio, se due unità hanno esito negativo contemporaneamente o se un server scende e un'unità non riesce, i volumi che usano la resilienza annidata rimangono online e accessibili. Per l'infrastruttura iperconvergente, questo aumenta il tempo di attività per le app e le macchine virtuali; per i carichi di lavoro del file server, ciò significa che gli utenti hanno accesso senza interruzioni ai file.
Il compromesso è che la resilienza annidata ha un'efficienza di capacità inferiore rispetto al mirroring bidirezionale classico, il che significa che si ottiene uno spazio leggermente meno utilizzabile. Per informazioni dettagliate, vedere la sezione Efficienza della capacità seguente.
Funzionamento
Questa sezione fornisce lo sfondo sulla resilienza annidata per Spazi di archiviazione diretta e descrive le due nuove opzioni di resilienza e l'efficienza della capacità.
Ispirazione: RAID 5+1
RAID 5+1 è una forma stabilita di resilienza di archiviazione distribuita che offre uno sfondo utile per comprendere la resilienza annidata. In RAID 5+1, all'interno di ogni server, la resilienza locale viene fornita da RAID-5 o da parità singola, per proteggersi dalla perdita di qualsiasi singola unità. La resilienza viene quindi fornita da RAID-1 o mirroring bidirezionale tra i due server per proteggere dalla perdita di un server.
Opzioni di resilienza
Spazi di archiviazione diretta in Azure Stack HCI e Windows Server offre due opzioni di resilienza implementate nel software, senza la necessità di hardware RAID specializzato:
Specchio bidirezionale annidato. All'interno di ogni server, la resilienza locale viene fornita dal mirroring bidirezionale e quindi viene fornita ulteriore resilienza tramite mirroring bidirezionale tra i due server. È essenzialmente un mirror a quattro vie, con due copie in ogni server che si trovano su dischi fisici diversi. Il mirroring bidirezionale annidato offre prestazioni senza compromessi: le scritture passano a tutte le copie e le letture provengono da qualsiasi copia.
Parità accelerata con mirroring annidato. Combinare il mirroring bidirezionale annidato, dall'immagine precedente, con parità annidata. All'interno di ogni server, la resilienza locale per la maggior parte dei dati viene fornita dall'aritmetica bit per bit singolo, ad eccezione delle nuove scritture recenti che usano il mirroring bidirezionale. Quindi, maggiore resilienza per tutti i dati viene fornita dal mirroring bidirezionale tra i server. Le nuove scritture nel volume passano alla parte mirror con due copie su dischi fisici separati in ogni server. Come parte mirror del volume si riempie in ogni server, i dati meno recenti vengono convertiti e salvati nella parte di parità in background. Di conseguenza, ogni server dispone dei dati per il volume in un mirror bidirezionale o in una singola struttura di parità. Questo è simile al funzionamento della parità accelerata con mirroring , con la differenza che la parità con accelerazione mirror richiede quattro server nel cluster e nel pool di archiviazione e usa un algoritmo di parità diverso.
Efficienza della capacità
L'efficienza della capacità è il rapporto tra spazio utilizzabile e footprint del volume. Descrive il sovraccarico della capacità attribuibile alla resilienza e dipende dall'opzione di resilienza scelta. Come esempio semplice, l'archiviazione dei dati senza resilienza è efficiente per il 100% della capacità (1 TB di dati richiede 1 TB di capacità di archiviazione fisica), mentre il mirroring bidirezionale è efficiente del 50% (1 TB di dati richiede 2 TB di capacità di archiviazione fisica).
Il mirror bidirezionale annidato scrive quattro copie di tutto. Ciò significa che per archiviare 1 TB di dati, è necessaria una capacità di archiviazione fisica di 4 TB. Anche se la sua semplicità è attraente, l'efficienza della capacità dello specchio bidirezionale del 25% è la più bassa di qualsiasi opzione di resilienza in Spazi di archiviazione diretta.
La parità accelerata con mirroring annidato ottiene un'efficienza di capacità superiore, intorno al 35%-40%, che dipende da due fattori: il numero di unità di capacità in ogni server e la combinazione di mirror e parità specificate per il volume. Questa tabella fornisce una ricerca per le configurazioni comuni:
Unità di capacità per server Specchio del 10% Specchio del 20% Specchio del 30% 4 35.7% 34.1% 32.6% 5 37.7% 35.7% 33.9% 6 39.1% 36.8% 34.7% 7+ 40.0% 37.5% 35.3% Di seguito è riportato un esempio di matematica completa. Si supponga di avere sei unità di capacità in ognuno di due server e si vuole creare un volume di 100 GB costituito da 10 GB di mirroring e 90 GB di parità. Il mirror bidirezionale locale del server è 50,0% efficiente, ovvero il 10 GB di dati mirror richiede 20 GB per archiviare in ogni server. Mirroring in entrambi i server, il suo footprint totale è 40 GB. La parità singola locale del server, in questo caso, è 5/6 = 83,3% efficiente, ovvero il 90 GB di dati di parità richiede 108 GB per archiviare in ogni server. Mirroring in entrambi i server, il footprint totale è pari a 216 GB. Il footprint totale è quindi [(10 GB / 50,0%) + (90 GB / 83,3%)] × 2 = 256 GB, per l'efficienza complessiva della capacità del 39,1%.
Si noti che l'efficienza della capacità del mirroring bidirezionale classico (circa il 50%) e la parità accelerata con mirroring annidato (fino al 40%) non sono molto diverse. A seconda dei requisiti, l'efficienza della capacità leggermente inferiore potrebbe essere utile per l'aumento significativo della disponibilità dell'archiviazione. È possibile scegliere resilienza per volume, quindi è possibile combinare volumi di resilienza annidati e volumi mirror a due vie classici all'interno dello stesso cluster.
Creare volumi di resilienza annidati
È possibile usare i cmdlet di archiviazione familiari in PowerShell per creare volumi con resilienza annidata, come descritto nella sezione seguente.
Passaggio 1: Creare modelli di livello di archiviazione (solo Windows Server 2019)
Windows Server 2019 richiede di creare nuovi modelli di livello di archiviazione usando il New-StorageTier cmdlet prima di creare volumi. È sufficiente eseguire questa operazione una sola volta e quindi ogni nuovo volume creato può fare riferimento a questi modelli.
Nota
Se si esegue Windows Server 2022, Azure Stack HCI 21H2 o Azure Stack HCI 20H2, è possibile ignorare questo passaggio.
Specificare le -MediaType unità di capacità e, facoltativamente, l'oggetto -FriendlyName desiderato. Non modificare altri parametri.
Ad esempio, se le unità di capacità sono unità disco rigido (HDD), avviare PowerShell come amministratore ed eseguire i cmdlet seguenti.
Per creare un livello NestedMirror:
New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedMirrorOnHDD -ResiliencySettingName Mirror -MediaType HDD -NumberOfDataCopies 4
Per creare un livello NestedParity:
New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedParityOnHDD -ResiliencySettingName Parity -MediaType HDD -NumberOfDataCopies 2 -PhysicalDiskRedundancy 1 -NumberOfGroups 1 -FaultDomainAwareness StorageScaleUnit -ColumnIsolation PhysicalDisk
Se le unità di capacità sono unità a stato solido (SSD), impostare invece su -MediaTypeSSD e modificare su -FriendlyName*OnSSD. Non modificare altri parametri.
Suggerimento
Verificare che Get-StorageTier i livelli siano stati creati correttamente.
Passaggio 2: Creare volumi annidati
Creare nuovi volumi usando il New-Volume cmdlet .
Mirror bidirezionale annidato
Per usare il mirror bidirezionale annidato, fare riferimento al modello di
NestedMirrorlivello e specificare le dimensioni. Ad esempio:New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume01 -StorageTierFriendlyNames NestedMirrorOnHDD -StorageTierSizes 500GBSe le unità di capacità sono unità SSD (Solid State Drive), passare
-StorageTierFriendlyNamesa*OnSSD.Parità accelerata con mirroring annidata
Per usare la parità con accelerazione mirror annidata, fare riferimento sia ai
NestedMirrorNestedParitymodelli di livello che a quello e specificare due dimensioni, una per ogni parte del volume (mirror first, parità secondo). Ad esempio, per creare un volume di 500 GB annidato al 20% di mirroring bidirezionale e all'80% di parità annidata, eseguire:New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume02 -StorageTierFriendlyNames NestedMirrorOnHDD, NestedParityOnHDD -StorageTierSizes 100GB, 400GBSe le unità di capacità sono unità SSD (Solid State Drive), passare
-StorageTierFriendlyNamesa*OnSSD.
Passaggio 3: Continuare in Windows Admin Center
I volumi che usano la resilienza annidata vengono visualizzati in Windows Admin Center con etichette chiare, come nello screenshot seguente. Dopo averli creati, è possibile gestirli e monitorarli usando Windows Admin Center proprio come qualsiasi altro volume in Spazi di archiviazione diretta.
Facoltativo: estendere le unità della cache
Con le impostazioni predefinite, la resilienza annidata protegge dalla perdita di più unità di capacità contemporaneamente o da un server e da un'unità di capacità contemporaneamente. Per estendere questa protezione alle unità cache, esiste un'altra considerazione: poiché le unità cache spesso forniscono memorizzazione nella cache di lettura e scrittura per più unità di capacità, l'unico modo per garantire che sia possibile tollerare la perdita di un'unità cache quando l'altro server è inattivo per non memorizzare nella cache le scritture, ma che influiscono sulle prestazioni.
Per risolvere questo scenario, Spazi di archiviazione diretta offre la possibilità di disabilitare automaticamente la memorizzazione nella cache di scrittura quando un server in un cluster a due server è inattivo e quindi riabilitare la memorizzazione nella cache di scrittura dopo il backup del server. Per consentire il riavvio della routine senza impatto sulle prestazioni, la memorizzazione nella cache di scrittura non viene disabilitata fino a quando il server non è stato disattivato per 30 minuti. Una volta disabilitata la memorizzazione nella cache di scrittura, il contenuto della cache di scrittura viene scritto nei dispositivi di capacità. Successivamente, il server può tollerare un dispositivo cache non riuscito nel server online, anche se le letture dalla cache potrebbero essere ritardate o non riuscite in caso di errore di un dispositivo della cache.
Nota
Per un sistema fisico della cache (tipo di supporto singolo), non è necessario considerare la disabilitazione automatica della memorizzazione nella cache di scrittura quando un server in un cluster a due server è inattivo. È necessario prendere in considerazione questa operazione solo con la cache SBL (Storage Bus Layer), necessaria solo se si usano dischi HDD.
(Facoltativo) Per disabilitare automaticamente la memorizzazione nella cache di scrittura quando un server in un cluster a due server è inattivo, avviare PowerShell come amministratore ed eseguire:
Get-StorageSubSystem Cluster* | Set-StorageHealthSetting -Name "System.Storage.NestedResiliency.DisableWriteCacheOnNodeDown.Enabled" -Value "True"
Una volta impostato su True, il comportamento della cache è:
| Situazione | Comportamento cache | Può tollerare la perdita di unità della cache? |
|---|---|---|
| Entrambi i server sono in modalità up | Letture e scritture nella cache, prestazioni complete | Sì |
| Server inattivo, primi 30 minuti | Letture e scritture nella cache, prestazioni complete | No (temporaneamente) |
| Dopo i primi 30 minuti | Solo letture della cache, prestazioni interessate | Sì (dopo la scrittura della cache nelle unità di capacità) |
Domande frequenti
Risposte alle domande frequenti sulla resilienza annidata.
È possibile convertire un volume esistente tra mirroring bidirezionale e resilienza annidata?
No, i volumi non possono essere convertiti tra tipi di resilienza. Per le nuove distribuzioni in Azure Stack HCI, Windows Server 2022 o Windows Server 2019, decidere in anticipo il tipo di resilienza più adatto alle proprie esigenze. Se si esegue l'aggiornamento da Windows Server 2016, è possibile creare nuovi volumi con resilienza annidata, eseguire la migrazione dei dati e quindi eliminare i volumi meno recenti.
È possibile usare la resilienza annidata con più tipi di unità di capacità?
Sì, è sufficiente specificare l'oggetto di ogni livello di conseguenza durante il -MediaTypepassaggio 1 precedente. Ad esempio, con NVMe, SSD e HDD nello stesso cluster, nvme fornisce la cache mentre le ultime due forniscono capacità: impostare il NestedMirror livello su -MediaType SSD e il NestedParity livello su -MediaType HDD. In questo caso, l'efficienza della capacità di parità dipende solo dal numero di unità HDD e sono necessarie almeno 4 di esse per server.
È possibile usare la resilienza annidata con tre o più server?
No, usare la resilienza annidata solo se il cluster ha esattamente due server.
Quante unità è necessario usare la resilienza annidata?
Il numero minimo di unità necessarie per Spazi di archiviazione diretta è quattro unità di capacità per ogni nodo del server, più due unità cache per ogni nodo del server (se presente). Questo è invariato da Windows Server 2016. Non esiste un altro requisito per la resilienza annidata e anche la raccomandazione per la capacità riservata rimane invariata.
La resilienza annidata cambia il funzionamento della sostituzione delle unità?
No.
La resilienza annidata cambia il funzionamento della sostituzione dei nodi del server?
No. Per sostituire un nodo del server e le relative unità, seguire questo ordine:
- Ritirare le unità nel server in uscita
- Aggiungere il nuovo server, con le relative unità, al cluster
- Il pool di archiviazione ribilancia
- Rimuovere il server in uscita e le relative unità
Per informazioni dettagliate, vedere l'articolo Rimuovere i server .