Pianificazione dei volumi in Spazi di archiviazione Direct

Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Questo argomento fornisce indicazioni su come pianificare i volumi in Spazi di archiviazione Direct per soddisfare le esigenze di prestazioni e capacità dei carichi di lavoro, inclusa la scelta del file system, del tipo di resilienza e delle dimensioni.

Revisione: Informazioni sui volumi

I volumi sono la posizione in cui inserire i file necessari per i carichi di lavoro, ad esempio file VHD o VHDX per macchine virtuali Hyper-V. I volumi combinano le unità nel pool di archiviazione per introdurre i vantaggi di tolleranza di errore, scalabilità e prestazioni di Spazi di archiviazione Direct.

Nota

In tutta la documentazione per Spazi di archiviazione Direct viene utilizzato il termine "volume" per fare riferimento congiuntamente al volume e al disco virtuale al suo interno, incluse le funzionalità fornite da altre funzionalità Windows incorporate, ad esempio Volumi condivisi cluster e ReFS. La comprensione di queste distinzioni a livello di implementazione non è necessaria per pianificare e distribuire Spazi di archiviazione Direct.

Diagramma che illustra i volumi.

Tutti i volumi sono accessibili da tutti i server del cluster contemporaneamente. Una volta creati, vengono visualizzati in C:\ClusterStorage \ in tutti i server.

Screenshot di una finestra Esplora file che mostra i volumi Archiviazione cluster.

Scelta del numero di volumi da creare

È consigliabile rendere il numero di volumi un multiplo del numero di server nel cluster. Ad esempio, se si dispone di 4 server, si oderanno prestazioni più coerenti con 4 volumi totali rispetto a 3 o 5. In questo modo il cluster può distribuire il volume "proprietà" (un server gestisce l'orchestrazione dei metadati per ogni volume) in modo uniforme tra i server.

È consigliabile limitare il numero totale di volumi a:

Windows Server 2016 Windows Server 2019
Fino a 32 volumi per cluster Fino a 64 volumi per cluster

Scelta del file system

È consigliabile usare il nuovo file system resiliente (ReFS) per Spazi di archiviazione Direct. ReFS è il file system principale progettato appositamente per la virtualizzazione e offre molti vantaggi, tra cui accelerazione delle prestazioni significativi e protezione incorporata dal danneggiamento dei dati. Supporta quasi tutte le principali funzionalità NTFS, tra cui Deduplicazione dati in Windows Server, versione 1709 e 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 NTFS.

Suggerimento

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

Scelta del tipo di resilienza

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

Nota

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

Con due server

Con due server nel cluster, è possibile usare il mirroring bidiredire usare. Se si esegue Windows Server 2019, è anche possibile usare la resilienza annidata.

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

Diagramma che illustra il concetto di archiviazione dei dati mirror bidirevi.

La resilienza annidata (disponibile solo in Windows Server 2019) garantisce la resilienza dei dati tra i server con mirroring bidiredirezione, quindi aggiunge resilienza all'interno di un server con mirroring bidirezione o parità accelerata con mirroring. L'annidamento garantisce la resilienza dei dati anche quando un server viene riavviato o non è disponibile. L'efficienza di archiviazione è pari al 25% con mirroring bidiredato annidato e circa il 35-40% per la parità con accelerazione mirror annidata. La resilienza annidata può tollerare in modo sicuro due errori hardware alla volta (due unità o un server e un'unità nel server rimanente). A causa di questa maggiore resilienza dei dati, è consigliabile usare la resilienza annidata nelle distribuzioni di produzione di cluster a due server, se si esegue Windows Server 2019. Per altre informazioni, vedere Resilienza annidata.

Diagramma che illustra il concetto di parità con accelerazione speculare 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 sulle unità in ogni server. L'efficienza di archiviazione è del 33,3%: per scrivere 1 TB di dati, sono necessari almeno 3 TB di capacità di archiviazione fisica nel pool di archiviazione. Il mirroring a tre vie può tollerare in modo sicuro almeno due problemi hardware (unità o server) alla volta. Se 2 nodi diventano non disponibili, il pool di archiviazione perderà il quorum, poiché 2/3 dei dischi non sono disponibili e i dischi virtuali non saranno accessibili. È tuttavia possibile che un nodo sia in stato insoddetto e che uno o più dischi in un altro nodo non riescano e che i dischi virtuali rimangano online. Ad esempio, se si riavvia un server quando improvvisamente si verifica un errore in un'altra unità o server, tutti i dati rimangono al sicuro e sempre accessibili.

Diagramma che illustra il concetto di archiviazione dei dati mirror a tre livelli.

<a name="with-four-or-more-servers">Con quattro o più server

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

La doppia parità 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, sono necessari 4 TB di capacità di archiviazione fisica nel pool di archiviazione. Questo aumenta fino al 66,7% di efficienza di archiviazione con sette server e continua fino all'80,0% di efficienza di archiviazione. Il compromesso è che la codifica della parità è più a elevato utilizzo di calcolo, il che può limitarne le prestazioni.

Diagramma che illustra il concetto di archiviazione dei dati a doppia parità.

Il tipo di resilienza da usare dipende dalle esigenze del carico di lavoro. Di seguito è riportata una tabella che riepiloga i carichi di lavoro più adatti per ogni tipo di resilienza, nonché le prestazioni e l'efficienza di archiviazione di ogni tipo di resilienza.

Tipo di resilienza Efficienza della capacità speed Carichi di lavoro
Mirror Archiviazione efficienza che mostra il 33%
Mirror a tre livelli: 33%
Mirroring bidirede: 50%
Prestazioni che mostrano il 100%
Prestazioni massime
Carichi di lavoro virtualizzati
Database
Altri carichi di lavoro ad alte prestazioni
Parità accelerata con mirror Archiviazione efficienza che mostra circa il 50%
Dipende dalla proporzione di mirror e parità
Prestazioni che indicano circa il 20%
Molto più lento rispetto al mirror, ma fino al doppio della velocità della doppia parità
Ideale per operazioni di scrittura e lettura sequenziali di grandi dimensioni
Archiviazione e backup
Infrastruttura desktop virtualizzata
Doppia parità Archiviazione'efficienza che mostra circa l'80%
4 server: 50%
16 server: fino all'80%
Prestazioni che indicano circa il 10%
Latenza di I/O più elevata & utilizzo della CPU nelle operazioni di scrittura
Ideale per operazioni di scrittura e lettura 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 necessitano di numerose operazioni di I/O al secondo casuali miste, ad esempio database SQL Server o macchine virtuali Hyper-V sensibili alle prestazioni, devono essere eseguiti in volumi che usano il mirroring per ottimizzare le prestazioni.

Suggerimento

Il mirroring è più veloce di qualsiasi altro tipo di resilienza. Il mirroring viene utilizzato 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 file server tradizionali, VDI (Virtual Desktop Infrastructure) o altri che non creano un elevato traffico di I/O casuale e/o non richiedono prestazioni ottimali, possono anche usare la doppia parità, a propria discrezione. La parità aumenta inevitabilmente l'utilizzo della CPU e la latenza di I/O, in particolare nelle scritture, rispetto al mirroring.

Quando i dati vengono scritti in blocco

I carichi di lavoro che scrivono in passaggi sequenziali di grandi dimensioni, ad esempio destinazioni di archiviazione o di backup, hanno un'altra opzione nuova in Windows Server 2016: un volume può combinare mirroring e doppia parità. Le scritture vengono spostate per prime nella parte con mirroring e vengono gradualmente spostate 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 per un tempo più lungo. Quando si ridimensionano le parti, si consideri che la quantità di scritture che si verificano contemporaneamente (ad esempio un backup giornaliero) deve adattarsi perfettamente alla parte mirror. Ad esempio, se si ingeriscono 100 GB una volta al giorno, è consigliabile usare il mirroring da 150 GB a 200 GB e la doppia parità per il resto.

L'efficienza di archiviazione risultante dipende dalle proporzioni selezionate. Vedere questa demo per alcuni esempi.

Suggerimento

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

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ò si verifica automaticamente: per altre informazioni, vedere Informazioni sulla cache in Spazi di archiviazione Direct. In tali distribuzioni, tutti i volumi si trovano infine nello stesso tipo di unità, 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 nel livello SSD, interamente nel livello HDD o se si estende su questi due livelli.

Importante

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

Scelta delle dimensioni dei volumi

È consigliabile limitare le dimensioni di ogni volume a:

Windows Server 2016 Windows Server 2019
Fino a 32 TB Fino a 64 TB

Suggerimento

Se si usa una soluzione di backup basata sul servizio Copia Shadow del volume (VSS) e sul provider software Volsnap, come è comune con i carichi di lavoro di file server, la limitazione delle 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 a blocchi ReFS e/o le API di backup SQL native hanno prestazioni fino a 32 TB e oltre.

Impronta

Le dimensioni di un volume si riferiscono alla capacità utilizzabile, alla quantità di dati che può archiviare. Questo valore 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à di archiviazione fisica totale che occupa 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 più grande.

I footprint dei volumi devono rientrare nel pool di archiviazione.

Diagramma che mostra che le dimensioni del volume si adattano al pool di archiviazione.

Riservare capacità

Lasciare una certa capacità nel pool di archiviazione non allocato offre ai volumi spazio per ripristinare "sul posto" in caso di errore delle unità, migliorando la sicurezza e le prestazioni dei dati. Se la capacità è sufficiente, una riparazione parallela immediata sul posto può ripristinare la resilienza completa dei volumi anche prima della sostituzione delle unità non riuscite. Questa operazione viene eseguita automaticamente.

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

Diagramma che illustra il concetto di capacità di riserva.

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 1 TB di unità di capacità, impostare 3 x 1 = 3 TB come riserva. Se sono disponibili 4 o più server e 1 TB di unità di capacità, 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'unità SSD più un disco rigido per server, fino a 4 unità ciascuna.

Esempio: Pianificazione della capacità

Si consideri un cluster a quattro server. Ogni server ha alcune unità cache più sedici unità da 2 TB per la capacità.

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

Da questi 128 TB nel pool di archiviazione vengono impostate quattro unità, o 8 TB, in modo che le riparazioni sul posto possano verificarsi senza alcuna fretta di sostituire le unità in caso di errore. 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 di aver bisogno della distribuzione per ospitare alcune macchine virtuali Hyper-V altamente attive, ma che sia disponibile anche un'elevata quantità di spazio di archiviazione a freddo: file e backup vecchi che è necessario conservare. Poiché sono disponibili quattro server, è possibile creare quattro volumi.

Inserire 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 la resilienza per ottimizzare le prestazioni. Inserire l'archiviazione a freddo sugli altri due volumi, volume 3 e volume 4. Si sceglie NTFS come file system (per Deduplicazione dati) e doppia parità per la resilienza per ottimizzare la capacità.

Non è necessario rendere tutti i volumi delle stesse dimensioni, ma per semplicità, ad esempio, è possibile impostarli tutti su 12 TB.

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

Volume3 e Volume4 occuperanno ciascuno 12 TB x 50,0% di efficienza = 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.

Diagramma che mostra un esempio di quattro volumi che si adattano esattamente alla capacità di archiviazione fisica disponibile nel pool.

Suggerimento

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

Per semplicità, in questo esempio vengono utilizzate unità decimali (base 10), ovvero 1 TB = 1.000.000.000.000 di byte. Tuttavia, le quantità di archiviazione Windows 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 viene visualizzato come 116,41 TiB. Si tratta di un comportamento previsto.

Uso

Vedere Creazione di volumi in Spazi di archiviazione Direct.

Riferimenti aggiuntivi