Pianificare volumi in cluster Azure Stack HCI e server Windows

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

Questo articolo fornisce indicazioni su come pianificare i volumi del cluster per soddisfare le esigenze di prestazioni e capacità dei carichi di lavoro, tra cui la scelta del file system, il tipo di resilienza e le dimensioni.

Nota

Spazi di archiviazione diretta non supporta un file server per l'uso generale. Se è necessario eseguire il file server o altri servizi generici in Spazio di archiviazione diretta, configurarlo nelle macchine virtuali.

Revisione: Informazioni sui volumi

I volumi sono in cui vengono inseriti i file necessari, ad esempio file VHD o VHDX per le macchine virtuali Hyper-V. I volumi combinano le unità nel pool di archiviazione per introdurre la tolleranza di errore, la scalabilità e i vantaggi delle prestazioni di Spazi di archiviazione diretta, la tecnologia di archiviazione definita dal software dietro Azure Stack HCI e Windows Server.

Nota

Il termine "volume" viene usato per fare riferimento congiuntamente al volume e al disco virtuale, inclusa la funzionalità fornita da altre funzionalità predefinite di Windows, ad esempio Volumi condivisi cluster (CSV) e ReFS. La comprensione di queste distinzione a livello di implementazione non è necessaria per pianificare e distribuire correttamente Spazi di archiviazione diretta.

Tutti i volumi sono accessibili da tutti i server nel cluster contemporaneamente. Dopo aver creato, vengono visualizzati in C:\ClusterStorage\ in tutti i server.

Scelta del numero di volumi da creare

È consigliabile rendere il numero di volumi un numero multiplo di server nel cluster. Ad esempio, se si dispone di 4 server, si avranno prestazioni più coerenti con 4 volumi totali rispetto a 3 o 5. Ciò consente al cluster di distribuire il volume "proprietà" (un server gestisce l'orchestrazione dei metadati per ogni volume) uniformemente tra i server.

È consigliabile limitare il numero totale di volumi a 64 volumi per cluster.

Scelta del file system

È consigliabile usare il nuovo file system resiliente (ReFS) per Spazi di archiviazione diretta. ReFS è il primo file system progettato per la virtualizzazione e offre molti vantaggi, tra cui accelerazioni delle prestazioni drammatiche e protezione predefinita contro il danneggiamento dei dati. Supporta quasi tutte le funzionalità NTFS principali, tra cui Deduplicazione dati in Windows Server versione 1709 e versioni successive. Per informazioni dettagliate, vedere la tabella di confronto delle funzionalità ReFS.

Se il carico di lavoro richiede una funzionalità che ReFS non supporta ancora, è possibile usare invece NTFS.

Suggerimento

I volumi con file system diversi possono coesistere nello stesso cluster.

Scelta del tipo di resilienza

I volumi in Spazi di archiviazione diretta offrono resilienza per la protezione da problemi hardware, ad esempio errori di unità o server e per consentire la disponibilità continua in tutta la manutenzione del server, ad esempio gli aggiornamenti software.

Nota

Quali tipi di resilienza è possibile scegliere sono indipendenti dai tipi di unità disponibili.

Con due server

Con due server nel cluster è possibile usare il mirroring bidirezionale oppure usare la resilienza annidata.

Il mirroring bidirezionale mantiene due copie di tutti i dati, una copia nelle unità in ogni server. L'efficienza di archiviazione è del 50%. per scrivere 1 TB di dati, è necessario almeno 2 TB di capacità di archiviazione fisica nel pool di archiviazione. Il mirroring bidirezionale può tollerare in modo sicuro un errore hardware alla volta (un server o un'unità).

La resilienza annidata offre resilienza dei dati tra i server con mirroring bidirezionale, quindi aggiunge resilienza all'interno di un server con mirroring bidirezionale o parità con mirroring accelerato. L'annidamento offre resilienza dei dati anche quando un server viene riavviato o non disponibile. L'efficienza di archiviazione è del 25% con mirroring bidirezionale annidato e circa il 35-40% per la parità con mirroring accelerato annidato. La resilienza annidata può tollerare in modo sicuro due errori hardware alla volta (due unità o un server e un'unità sul server rimanente). A causa di questa resilienza dei dati aggiunta, è consigliabile usare la resilienza annidata nelle distribuzioni di produzione di cluster a due server. Per altre informazioni, vedere Resilienza annidata.

Con tre server

Con tre server, è consigliabile usare il mirroring a tre vie per migliorare la tolleranza di errore e le prestazioni. Il mirroring a tre vie mantiene tre copie di tutti i dati, una copia nelle unità in ogni server. L'efficienza di archiviazione è 33,3 per cento: per scrivere 1 TB di dati, è necessario almeno 3 TB di capacità di archiviazione fisica nel pool di archiviazione. Il mirroring a tre vie può tollerare almeno due problemi hardware (unità o server) alla volta. Se 2 nodi non sono disponibili, il pool di archiviazione perderà il quorum, poiché non sono disponibili 2/3 dei dischi e i dischi virtuali non saranno accessibili. Tuttavia, un nodo può essere inattivo e uno o più dischi in un altro nodo possono avere esito negativo e i dischi virtuali rimarranno online. Ad esempio, se si riavvia un server quando improvvisamente un'altra unità o un server ha esito negativo, tutti i dati rimangono sicuri e continuamente accessibili.

Con quattro o più server

Con quattro o più server, è possibile scegliere per ogni volume se usare mirroring a tre vie, doppia parità (spesso chiamata "codifica di cancellazione") o combinare i due con parità accelerata con mirroring.

La parità doppia offre la stessa tolleranza di errore del mirroring a tre vie, ma con una migliore efficienza di archiviazione. Con quattro server, l'efficienza di archiviazione è del 50,0%. per archiviare 2 TB di dati, è necessario 4 TB di capacità di archiviazione fisica nel pool di archiviazione. Ciò aumenta fino al 66,7% dell'efficienza di archiviazione con sette server e continua fino al 80,0% dell'efficienza di archiviazione. Il compromesso è che la codifica di parità è più a elevato utilizzo di calcolo, che può limitare le prestazioni.

Quale tipo di resilienza usare dipende dalle esigenze del carico di lavoro. Ecco una tabella che riepiloga i carichi di lavoro adatti a ogni tipo di resilienza, nonché l'efficienza delle prestazioni e dell'archiviazione di ogni tipo di resilienza.

Tipo di resilienza	Efficienza della capacità	speed	Carichi di lavoro
Mirror	Specchio a tre vie: 33% Mirror bidirezionale: 50%	Prestazioni massime	Carichi di lavoro virtualizzati Database Altri carichi di lavoro ad alte prestazioni
Parità accelerata con mirror	Dipende dalla proporzione dello specchio e della parità	Molto più lento rispetto allo specchio, ma fino a due volte più veloce della doppia parità Ideale per scritture e letture sequenziali di grandi dimensioni	Archiviazione e backup Infrastruttura desktop virtualizzata
Doppia parità	4 server: 50% 16 server: fino al 80%	Latenza di I/O massima & utilizzo della CPU nelle scritture Ideale per scritture e letture sequenziali di grandi dimensioni	Archiviazione e backup Infrastruttura desktop virtualizzata

Quando le prestazioni sono più importanti

I carichi di lavoro con requisiti di latenza rigorosi o che richiedono un sacco di operazioni di I/O al secondo casuali miste, ad esempio i database SQL Server o le macchine virtuali Hyper-V sensibili alle prestazioni, devono essere eseguiti su volumi che usano il mirroring per ottimizzare le prestazioni.

Suggerimento

Il mirroring è più veloce di qualsiasi altro tipo di resilienza. Viene usato il mirroring per quasi tutti gli esempi di prestazioni.

Quando la capacità è più importante

I carichi di lavoro che scrivono raramente, ad esempio data warehouse o archiviazione a freddo, devono essere eseguiti su volumi che usano la doppia parità per ottimizzare l'efficienza di archiviazione. Alcuni altri carichi di lavoro, ad esempio Scale-Out File Server (SoFS), l'infrastruttura desktop virtuale (VDI) o altri che non creano un sacco di traffico I/O casuale a deriva rapida e/o non richiedono prestazioni ottimali possono anche usare la doppia parità, a discrezione dell'utente. La parità aumenta inevitabilmente l'utilizzo della CPU e la latenza I/O, in particolare nelle scritture, rispetto al mirroring.

Quando i dati sono scritti in blocco

I carichi di lavoro che scrivono in passaggi sequenziali di grandi dimensioni, ad esempio destinazioni di archiviazione o backup, hanno un'altra opzione: un volume può combinare mirroring e doppia parità. Scrive prima la terra nella parte con mirroring e viene gradualmente spostata nella parte di parità in un secondo momento. Ciò accelera l'inserimento e riduce l'utilizzo delle risorse quando arrivano scritture di grandi dimensioni consentendo la codifica della parità a elevato utilizzo di calcolo in un periodo di tempo più lungo. Quando si ridimensionano le parti, considerare che la quantità di scritture che si verificano contemporaneamente (ad esempio un backup giornaliero) deve adattarsi comodamente nella parte mirror. Ad esempio, se si inseriscono 100 GB al giorno, è consigliabile usare il mirroring per 150 GB a 200 GB e la parità doppia per il resto.

L'efficienza di archiviazione risultante dipende dalle proporzioni scelte. Per alcuni esempi, vedere questa demo .

Suggerimento

Se si osserva una brusca diminuzione delle prestazioni di scrittura attraverso l'inserimento dei dati, può indicare che la parte mirror non è abbastanza grande o che la parità con accelerazione mirroring non è adatta per il caso d'uso. Se, ad esempio, le prestazioni di scrittura diminuiscono da 400 MB/s a 40 MB/s, è consigliabile espandere la parte mirror o passare al mirror a tre vie.

Informazioni sulle distribuzioni con NVMe, SSD e HDD

Nelle distribuzioni con due tipi di unità, le unità più veloci forniscono la memorizzazione nella cache mentre le unità più lente forniscono capacità. Ciò avviene automaticamente: per altre informazioni, vedere Informazioni sulla cache in Spazi di archiviazione diretta. In tali distribuzioni, tutti i volumi si trovano in definitiva nello stesso tipo di unità, ovvero le unità di capacità.

Nelle distribuzioni con tutti e tre i tipi di unità, solo le unità più veloci (NVMe) forniscono la memorizzazione nella cache, lasciando due tipi di unità (SSD e HDD) per fornire capacità. Per ogni volume, è possibile scegliere se risiede interamente sul livello SSD, interamente sul livello HDD o se si estende su due.

Importante

È consigliabile usare il livello SSD per posizionare i carichi di lavoro più sensibili alle prestazioni in tutti i flash.

Scelta delle dimensioni dei volumi

È consigliabile limitare le dimensioni di ogni volume a 64 TB in Azure Stack HCI.

Suggerimento

Se si usa una soluzione di backup che si basa sul servizio Copia shadow del volume (VSS) e sul provider software Volsnap, come è comune con i carichi di lavoro del file server, limitare le dimensioni del volume a 10 TB migliorerà le prestazioni e l'affidabilità. Le soluzioni di backup che usano l'API RCT Hyper-V più recente e/o la clonazione del blocco ReFS e/o le API di backup SQL native eseguono fino a 32 TB e oltre.

Impronta

Le dimensioni di un volume fanno riferimento alla capacità utilizzabile, la quantità di dati che può archiviare. Viene fornito dal parametro -Size del cmdlet New-Volume e quindi viene visualizzato nella proprietà Size quando si esegue il cmdlet Get-Volume .

Le dimensioni sono distinte dal footprint del volume, la capacità totale di archiviazione fisica occupata nel pool di archiviazione. Il footprint dipende dal tipo di resilienza. Ad esempio, i volumi che usano il mirroring a tre vie hanno un footprint tre volte la loro dimensione.

I footprint dei volumi devono essere inseriti nel pool di archiviazione.

Riservare la capacità

L'uscita di una capacità nel pool di archiviazione non associata offre spazio per ripristinare "sul posto" le unità dopo l'esito negativo delle unità, migliorando la sicurezza e le prestazioni dei dati. Se esiste una capacità sufficiente, un ripristino parallelo immediato può ripristinare i volumi con resilienza completa anche prima che le unità non riuscite vengano sostituite. Avviene automaticamente.

È consigliabile riservare l'equivalente di un'unità di capacità per server, fino a 4 unità. È possibile riservare più a discrezione, ma questa raccomandazione minima garantisce un ripristino immediato, sul posto, parallela può avere esito positivo dopo l'errore di qualsiasi unità.

Ad esempio, se si dispone di 2 server e si usano unità di capacità da 1 TB, impostare 2 x 1 = 2 TB del pool come riserva. Se si dispone di 3 server e unità di capacità di 1 TB, impostare 3 x 1 = 3 TB come riserva. Se si dispone di 4 o più server e unità di capacità di 1 TB, impostare 4 x 1 = 4 TB come riserva.

Nota

Nei cluster con unità di tutti e tre i tipi (NVMe + SSD + HDD), è consigliabile riservare l'equivalente di un SSD più un HDD per server, fino a 4 unità di ognuna.

Esempio: Pianificazione della capacità

Prendere in considerazione un cluster a quattro server. Ogni server dispone di alcune unità cache più 2 TB di unità per la capacità.

4 servers x 16 drives each x 2 TB each = 128 TB

Da questo 128 TB nel pool di archiviazione, abbiamo messo a parte quattro unità o 8 TB, in modo che le riparazioni sul posto possano verificarsi senza alcuna corsa per sostituire le unità dopo che hanno esito negativo. Ciò lascia 120 TB di capacità di archiviazione fisica nel pool con cui è possibile creare volumi.

128 TB – (4 x 2 TB) = 120 TB

Si supponga che sia necessaria la distribuzione per ospitare alcune macchine virtuali Hyper-V altamente attive, ma abbiamo anche un sacco di archiviazione ad accesso sporadico, ovvero file e backup precedenti che è necessario conservare. Poiché sono disponibili quattro server, è possibile creare quattro volumi.

Verranno inserite le macchine virtuali nei primi due volumi, Volume1 e Volume2. Si sceglie ReFS come file system (per la creazione e i checkpoint più veloci) e il mirroring a tre vie per ottimizzare le prestazioni. Si inserisce l'archiviazione a freddo negli altri due volumi, Volume 3 e Volume 4. Si sceglie NTFS come file system (per Deduplicazione dati) e la doppia parità per la resilienza per ottimizzare la capacità.

Non è necessario rendere tutti i volumi la stessa dimensione, ma per semplicità, ad esempio, possiamo renderli tutti 12 TB.

Volume1 e Volume2 occupano 12 TB x 33,3% di efficienza = 36 TB di capacità di archiviazione fisica.

Volume3 e Volume4 occupano ogni efficienza di 12 TB x 50,0% = 24 TB di capacità di archiviazione fisica.

36 TB + 36 TB + 24 TB + 24 TB = 120 TB

I quattro volumi si adattano esattamente alla capacità di archiviazione fisica disponibile nel pool. Risposta esatta.

Suggerimento

Non è necessario creare subito tutti i volumi. È sempre possibile estendere i volumi o creare nuovi volumi in un secondo momento.

Per semplicità, questo esempio usa unità decimali (base-10) in tutto, ovvero 1 TB = 1.000.000.000.000 byte. Tuttavia, le quantità di archiviazione in Windows vengono visualizzate in unità binarie (base-2). Ad esempio, ogni unità da 2 TB viene visualizzata come 1.82 TiB in Windows. Analogamente, il pool di archiviazione da 128 TB appare come 116.41 TiB. Si tratta di un comportamento previsto.

Utilizzo

Vedere Creazione di volumi in Azure Stack HCI.

Passaggi successivi

Per ulteriori informazioni, vedere anche:

• Scelta delle unità per Spazi di archiviazione diretta
• Tolleranza di errore ed efficienza di archiviazione