Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Si applica a: Azure Stack HCI, versioni 22H2 e successive; 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 di due server di resistere a più errori hardware contemporaneamente senza perdita di disponibilità di archiviazione, in modo che utenti, app e macchine virtuali continuino a funzionare senza interruzioni. Questo articolo illustra il funzionamento della resilienza annidata, fornisce istruzioni dettagliate per iniziare e risponde 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 22H2 o successiva, Windows Server 2019 o versione successiva; e
- Il cluster dispone esattamente di due nodi server.
Non è possibile usare la resilienza annidata se:
- Il cluster esegue Windows Server 2016; o
- Il cluster dispone di un solo nodo server o di tre o più nodi server.
Perché la resilienza nidificata
I volumi che usano la resilienza annidata possono rimanere online e accessibili anche se si verificano più errori hardware contemporaneamente, a differenza della classica resilienza del mirroring bidirezionale . Ad esempio, se si verifica un errore di due unità contemporaneamente o se un server si arresta e un'unità si guasta, i volumi che utilizzano la resilienza nidificata rimangono online e accessibili. Per l'infrastruttura iperconvergente, ciò 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, il che significa che si ottiene uno spazio utilizzabile leggermente inferiore. Per informazioni dettagliate, vedere la sezione Efficienza della capacità seguente.
Come funziona
Questa sezione fornisce informazioni di base sulla resilienza annidata per Spazi di archiviazione diretta e descrive le due nuove opzioni di resilienza e la relativa efficienza della capacità.
Ispirazione: RAID 5+1
RAID 5+1 è una forma consolidata di resilienza dello storage distribuito che fornisce informazioni utili per comprendere la resilienza nidificata. In RAID 5+1, all'interno di ogni server, la resilienza locale è fornita da RAID-5, o parità singola, per la protezione contro la perdita di qualsiasi singola unità. Quindi, un'ulteriore resilienza è fornita da RAID-1, o mirroring bidirezionale, tra i due server per la protezione contro la 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:
Specchio a due vie nidificato. All'interno di ogni server, la resilienza locale viene fornita dal mirroring bidirezionale e quindi un'ulteriore resilienza viene fornita dal mirroring bidirezionale tra i due server. Si tratta essenzialmente di un mirror a quattro vie, con due copie su ciascun server che si trovano su dischi fisici diversi. Il mirroring bidirezionale nidificato offre prestazioni senza compromessi: le scritture vengono eseguite su tutte le copie e le letture provengono da qualsiasi copia.
Parità con accelerazione mirror nidificata. Combinare la speculazione bidirezionale nidificata, dall'immagine precedente, con la parità nidificata. All'interno di ogni server, la resilienza locale per la maggior parte dei dati viene fornita dall'aritmetica di parità bit per bit singolo, ad eccezione delle nuove scritture recenti che utilizzano il mirroring bidirezionale. Quindi, un'ulteriore resilienza per tutti i dati è fornita dal mirroring bidirezionale tra i server. Le nuove scritture nel volume passano alla parte mirror con due copie su dischi fisici separati su ciascun server. Man mano che la parte mirror del volume si riempie su ciascun server, i dati più vecchi vengono convertiti e salvati nella parte di parità in background. Di conseguenza, ogni server dispone dei dati per il volume in un mirroring bidirezionale o in una singola struttura di parità. Questa operazione è simile al funzionamento della parità con accelerazione mirror, con la differenza che la parità con accelerazione mirror richiede quattro server nel cluster e nel pool di archiviazione e utilizza un algoritmo di parità diverso.
Efficienza della capacità
L'efficienza della capacità è il rapporto tra lo spazio utilizzabile e l'ingombro del volume. Descrive il sovraccarico della capacità attribuibile alla resilienza e dipende dall'opzione di resilienza scelta. Ad esempio, l'archiviazione dei dati senza resilienza è efficiente al 100% (1 TB di dati occupa 1 TB di capacità di archiviazione fisica), mentre il mirroring bidirezionale è efficiente al 50% (1 TB di dati occupa 2 TB di capacità di archiviazione fisica).
Il mirroring bidirezionale nidificato 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à è interessante, l'efficienza della capacità del mirroring bidirezionale annidato di 25% è la più bassa di qualsiasi opzione di resilienza in Spazi di archiviazione diretta.
La parità con accelerazione mirror nidificata consente di ottenere una maggiore efficienza della capacità, circa 35%-40%, che dipende da due fattori: il numero di unità di capacità in ogni server e la combinazione di mirror e parità specificata per il volume. Nella tabella seguente viene fornita una ricerca per le configurazioni comuni:
Unità di capacità per server Specchio da 10% Specchio da 20% Specchio da 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% Quello che segue è un esempio della matematica completa. Si supponga di avere sei unità di capacità in ciascuno dei due server e di voler creare un volume da 100 GB composto da 10 GB di mirror e 90 GB di parità. Il mirroring bidirezionale locale del server ha un'efficienza di 50,0%, il che significa che i 10 GB di dati mirror richiedono 20 GB per l'archiviazione in ogni server. Eseguito il mirroring su entrambi i server, l'ingombro totale è di 40 GB. La parità singola locale del server, in questo caso, è 5/6 = 83,3% efficiente, il che significa che i 90 GB di dati di parità richiedono 108 GB per l'archiviazione in ogni server. Rispecchiato su entrambi i server, il suo ingombro totale è di 216 GB. L'ingombro totale è quindi [(10 GB / 50,0%) + (90 GB / 83,3%)] × 2 = 256 GB, per un'efficienza complessiva della capacità di 39,1%.
Si noti che l'efficienza della capacità del mirroring bidirezionale classico (circa 50%) e la parità con accelerazione mirror nidificata (fino a 40%) non sono molto diverse. A seconda delle esigenze, l'efficienza della capacità leggermente inferiore può valere un aumento significativo della disponibilità di archiviazione. È possibile scegliere la resilienza per volume, in modo da poter combinare volumi di resilienza annidati e volumi mirror bidirezionali classici all'interno dello stesso cluster.
Creare volumi di resilienza nidificati
È 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 la creazione di nuovi modelli di livello di archiviazione usando il cmdlet prima di New-StorageTier creare i volumi. È necessario eseguire questa operazione una sola volta, quindi ogni nuovo volume creato può fare riferimento a questi modelli.
Annotazioni
Se si esegue Windows Server 2022, Azure Stack HCI, versione 21H2 o Azure Stack HCI, versione 20H2, è possibile ignorare questo passaggio.
Specificare le -MediaType unità di capacità e, facoltativamente, le -FriendlyName unità desiderate. 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 in -FriendlyName*OnSSD. Non modificare altri parametri.
Suggerimento
Verificare che i livelli siano Get-StorageTier stati creati correttamente.
Passaggio 2: Creare volumi nidificati
Creare nuovi volumi usando il New-Volume cmdlet.
Specchio a due vie nidificato
Per utilizzare il mirroring bidirezionale nidificato, fare riferimento al modello di
NestedMirrorlivello e specificare le dimensioni. Per esempio:New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume01 -StorageTierFriendlyNames NestedMirrorOnHDD -StorageTierSizes 500GBSe le unità di capacità sono unità a stato solido (SSD), passare
-StorageTierFriendlyNamesa*OnSSD.Parità con accelerazione mirror nidificata
Per utilizzare la
NestedMirrorparità con accelerazione mirror nidificata, fare riferimento ai modelli eNestedParityai modelli di livello e specificare due dimensioni, una per ogni parte del volume (prima mirror, seconda parità). Ad esempio, per creare un volume da 500 GB con 20% mirroring bidirezionale annidato e 80% parità annidata, eseguire:New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume02 -StorageTierFriendlyNames NestedMirrorOnHDD, NestedParityOnHDD -StorageTierSizes 100GB, 400GBSe le unità di capacità sono unità a stato solido (SSD), passare
-StorageTierFriendlyNamesa*OnSSD.
Passaggio 3: Continuare nell'interfaccia di amministrazione di Windows
I volumi che usano la resilienza annidata vengono visualizzati nell'interfaccia di amministrazione di Windows con un'etichettatura chiara, come nello screenshot seguente. Una volta creati, è possibile gestirli e monitorarli usando Windows Admin Center come qualsiasi altro volume in Spazi di archiviazione diretta.
Facoltativo: estendi alle unità cache
Con le impostazioni predefinite, la resilienza nidificata protegge dalla perdita di più unità di capacità contemporaneamente o di un server e un'unità di capacità contemporaneamente. Per estendere questa protezione alle unità cache, c'è un'altra considerazione: poiché le unità cache spesso forniscono la memorizzazione nella cache di lettura e scrittura per unità con più capacità, l'unico modo per assicurarsi di poter tollerare la perdita di un'unità cache quando l'altro server è inattivo è non memorizzare nella cache le scritture, ma ciò influisce sulle prestazioni.
Per risolvere questo scenario, Spazi di archiviazione diretta offre la possibilità di disabilitare automaticamente la memorizzazione nella cache in scrittura quando un server in un cluster a due server è inattivo e quindi di riabilitare la memorizzazione nella cache in scrittura dopo il backup del server. Per consentire i riavvii di routine senza influire sulle prestazioni, la cache in scrittura non viene disabilitata fino a quando il server non è rimasto inattivo per 30 minuti. Una volta disabilitata la cache di scrittura, il contenuto della cache di scrittura viene scritto nei dispositivi di capacità. Successivamente, il server può tollerare un errore del dispositivo di cache nel server online, anche se le letture dalla cache potrebbero essere ritardate o non riuscire se un dispositivo di cache si guasta.
Annotazioni
Per un sistema fisico con tutta la cache (tipo di supporto singolo), non è necessario prendere in considerazione la disabilitazione automatica della cache in scrittura quando un server in un cluster a due server è inattivo. È necessario considerare questo aspetto solo con la cache SBL (Storage Bus Layer), che è necessaria solo se si utilizzano HDD.
(Facoltativo) Per disabilitare automaticamente la memorizzazione nella cache in 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 dell'unità cache? |
|---|---|---|
| Entrambi i server attivi | 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 | Letture della cache, prestazioni compromesse | Sì (dopo che la cache è stata scritta nelle unità di capacità) |
Domande frequenti
Trova le risposte alle domande frequenti sulla resilienza nidificata.
È 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 quale tipo di resilienza si adatta meglio 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 precedenti.
È possibile usare la resilienza annidata con più tipi di unità di capacità?
Sì, basta specificare il di ogni livello di conseguenza durante il -MediaTypepassaggio 1 sopra. Ad esempio, con NVMe, SSD e HDD nello stesso cluster, NVMe fornisce la cache mentre gli ultimi 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 ne sono necessarie almeno 4 per server.
È possibile usare la resilienza annidata con tre o più server?
No, usare la resilienza annidata solo se il cluster dispone esattamente di due server.
Quante unità sono necessarie per usare la resilienza annidata?
Il numero minimo di unità necessarie per Spazi di archiviazione diretta è di quattro unità di capacità per ogni nodo del server, più due unità cache per ogni nodo del server (se presenti). Questo è invariato rispetto a Windows Server 2016. Non esistono altri requisiti per la resilienza nidificata e anche la raccomandazione per la capacità di riserva è invariata.
La resilienza annidata modifica il funzionamento della sostituzione dell'unità?
No
La resilienza nidificata modifica il funzionamento della sostituzione dei nodi del server?
No Per sostituire un nodo server e le relative unità, attenersi alla seguente ordinanza:
- Ritirare le unità nel server della posta in uscita
- Aggiungere il nuovo server, con le relative unità, al cluster
- Lo storage pool verrà ribilanciato
- Rimuovere il server della posta in uscita e le relative unità
Per informazioni dettagliate, vedere l'articolo Rimuovere i server .