Condividi tramite


Resilienza annidata per Spazi di archiviazione diretta

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:

  • Your cluster runs one of these operating systems: Azure Stack HCI, version 22H2 or later, Windows Server 2019 or later; and
  • 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

Volumes that use nested resiliency can stay online and accessible even if multiple hardware failures happen at the same time, unlike classic two-way mirroring resiliency. 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.

Diagramma che mostra la disponibilità di archiviazione.

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. For details, see the Capacity efficiency following section.

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, within each server, local resiliency is provided by RAID-5, or single parity, to protect against the loss of any single drive. Then, further resiliency is provided by RAID-1, or two-way mirroring, between the two servers to protect against the loss of either server.

Diagramma che mostra RAID 5+1.

Resiliency options

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.

    Diagramma che mostra il mirroring bidirezionale nidificato.

  • 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à. This is similar to how mirror-accelerated parity works—with the difference being that mirror-accelerated parity requires four servers in the cluster and storage pool, and uses a different parity algorithm.

    Diagramma che mostra la parità nidificata con accelerazione mirror.

Capacity efficiency

Capacity efficiency is the ratio of usable space to volume footprint. 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 10% mirror 20% mirror 30% mirror
    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.

    Diagramma che mostra il compromesso tra un mirroring bidirezionale e la parità accelerata con mirroring annidato.

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.

Note

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.

Tip

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 NestedMirror livello e specificare le dimensioni. For example:

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

    Se le unità di capacità sono unità a stato solido (SSD), passare -StorageTierFriendlyNames a *OnSSD.

  • Parità con accelerazione mirror nidificata

    Per utilizzare la NestedMirror parità con accelerazione mirror nidificata, fare riferimento ai modelli e NestedParity ai 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, 400GB
    

    Se le unità di capacità sono unità a stato solido (SSD), passare -StorageTierFriendlyNames a *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.

Gestione dei volumi in Windows Admin Center.

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. To extend this protection to cache drives, there's another consideration: because cache drives often provide read and write caching for multiple capacity drives, the only way to ensure you can tolerate the loss of a cache drive when the other server is down is to not cache writes, but that impacts performance.

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.

Note

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"

Once set to True, the cache behavior is:

Situation Cache behavior Può tollerare la perdita dell'unità cache?
Entrambi i server attivi Letture e scritture nella cache, prestazioni complete Yes
Server inattivo, primi 30 minuti Letture e scritture nella cache, prestazioni complete No (temporarily)
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à?

Yes, just specify the -MediaType of each tier accordingly during step 1 above. 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:

  1. Ritirare le unità nel server della posta in uscita
  2. Aggiungere il nuovo server, con le relative unità, al cluster
  3. Lo storage pool verrà ribilanciato
  4. Rimuovere il server della posta in uscita e le relative unità

For details see the Remove servers article.

Next steps