Resilienza annidata per Spazi di archiviazione diretta

Si applica a: Azure Stack HCI, versioni 22H2 e 21H2; Windows Server 2022 e Windows Server 2019

Importante

Azure Stack HCI is now part of Azure Local. La ridenominazione della documentazione del prodotto è in corso. Tuttavia, le versioni precedenti di Azure Stack HCI, ad esempio 22H2 continueranno a fare riferimento ad Azure Stack HCI e non rifletteranno la modifica del nome. Altre informazioni.

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 risponde alle domande più frequenti.

Operazioni preliminari

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 del server.

Non è possibile usare la resilienza annidata se:

• Il cluster esegue Windows Server 2016; o
• Il cluster ha solo un nodo server singolo 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 classica del mirroring bidirezionale. Ad esempio, se due unità hanno esito negativo contemporaneamente o se un server si arresta 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 ininterrotto ai propri file.

Il compromesso è che la resilienza annidata ha un'efficienza di capacità inferiore rispetto al mirroring bidirezionale classico, ovvero si ottiene uno spazio leggermente meno utilizzabile. Per informazioni dettagliate, vedere la sezione Efficienza della capacità seguente.

Funzionamento

In questa sezione vengono fornite informazioni generali sulla resilienza annidata per Spazi di archiviazione diretta e vengono descritte le due nuove opzioni di resilienza e l'efficienza della capacità.

Ispirazione: RAID 5+1

RAID 5+1 è una forma consolidata di resilienza di archiviazione distribuita che fornisce informazioni utili 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 un'unità singola. La resilienza viene quindi fornita da RAID-1 o dal mirroring bidirezionale tra i due server per proteggersi dalla perdita di uno dei due 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:

• Mirror bidirezionale annidato. All'interno di ogni server, la resilienza locale viene fornita dal mirroring bidirezionale e quindi viene fornita ulteriore resilienza dal mirroring bidirezionale tra i due server. Si tratta essenzialmente di un mirror a quattro vie, con due copie in ogni server che si trovano in 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à con accelerazione mirror annidata. 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 a bit per bit singolo, ad eccezione delle nuove scritture recenti che usano il mirroring bidirezionale. La resilienza per tutti i dati viene quindi 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. Quando la parte mirror del volume viene riempita in ogni server, i dati meno recenti vengono convertiti e salvati nella parte di parità in background. Di conseguenza, ogni server ha i dati per il volume in mirror bidirezionale o in una singola struttura di parità. Questo è simile al funzionamento della parità accelerata con mirroring , con la differenza che la parità accelerata con mirroring 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 di capacità attribuibile alla resilienza e dipende dall'opzione di resilienza scelta. Come semplice esempio, 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 al 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, sono necessari 4 TB di capacità di archiviazione fisica. Anche se la sua semplicità è accattivante, l'efficienza della capacità del mirror bidirezionale annidata del 25% è la più bassa di qualsiasi opzione di resilienza in Spazi di archiviazione diretta.

• La parità con accelerazione mirror annidata consente di ottenere un'efficienza di capacità superiore, circa il 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	Mirror 10%	Mirror 20%	Mirror 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 è efficiente del 50,0%, vale a dire che i 10 GB di dati mirror richiedono 20 GB per l'archiviazione in ogni server. Con mirroring in entrambi i server, il footprint totale è di 40 GB. La parità singola locale del server, in questo caso, è 5/6 = 83,3% efficiente, vale a dire che i 90 GB di dati di parità richiedono 108 GB per archiviare in ogni server. Con mirroring in entrambi i server, il footprint totale è di 216 GB. Il footprint totale è quindi [(10 GB / 50,0%) + (90 GB / 83,3%)] × 2 = 256 GB, per un'efficienza complessiva della capacità del 39,1%.

  Si noti che l'efficienza della capacità del mirroring bidirezionale classico (circa il 50%) e la parità con accelerazione mirror annidata (fino al 40%) non sono molto diverse. A seconda dei requisiti, l'efficienza della capacità leggermente inferiore può essere utile per un aumento significativo della disponibilità dell'archiviazione. È possibile scegliere la resilienza per volume, in modo da poter combinare volumi di resilienza annidati e volumi mirror classici bidirezionali 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. Questa operazione deve essere eseguita 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 l'oggetto -MediaType delle unità di capacità e, facoltativamente, di -FriendlyName propria scelta. 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à SSD (Solid State Drive), impostare invece su -MediaType SSD e impostare 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 NestedMirror modello di livello e specificare le dimensioni. Ad esempio:

  New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume01 -StorageTierFriendlyNames NestedMirrorOnHDD -StorageTierSizes 500GB
  

  Se le unità di capacità sono unità SSD (Solid State Drive), passare -StorageTierFriendlyNames a *OnSSD.

• Parità con accelerazione mirror annidata

  Per usare la parità con accelerazione mirror annidata, fare riferimento ai NestedMirror modelli di livello e NestedParity e specificare due dimensioni, una per ogni parte del volume (mirror first, parity second). Ad esempio, per creare un volume di 500 GB con mirroring bidirezionale annidato del 20% e pari all'80% annidato, eseguire:

  New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume02 -StorageTierFriendlyNames NestedMirrorOnHDD, NestedParityOnHDD -StorageTierSizes 100GB, 400GB
  

  Se le unità di capacità sono unità SSD (Solid State Drive), passare -StorageTierFriendlyNames a *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. Una volta creati, è possibile gestirli e monitorarli usando Windows Admin Center esattamente 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, è necessario tenere presente 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 scrivere nella cache, ma che influisce 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 i riavvii di routine senza alcun 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à. In seguito, 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 RIGIDI.

(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 su	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	Sola lettura della cache, prestazioni interessate	Sì (dopo che la cache viene scritta 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 -MediaType passaggio 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 nodo del server, più due unità cache per nodo server (se presenti). Questo valore è invariato rispetto a Windows Server 2016. Non esiste alcun altro requisito per la resilienza annidata e anche la raccomandazione per la capacità di riserva è 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:

1. Ritirare le unità nel server in uscita
2. Aggiungere il nuovo server, con le relative unità, al cluster
3. Il pool di archiviazione ribilancia
4. Rimuovere il server in uscita e le relative unità

Per informazioni dettagliate, vedere l'articolo Rimuovere i server .

Passaggi successivi

• Panoramica di Spazi di archiviazione diretta
• Comprendere la tolleranza di errore in Spazi di archiviazione diretta
• Pianificare volumi in Spazi di archiviazione diretta
• Creare volumi in Spazi di archiviazione diretta