Pianificare volumi in cluster Azure Stack HCI e Windows Server

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, inclusa la scelta del file system, del tipo di resilienza e delle dimensioni.

Revisione: Che cosa sono i volumi

I volumi consentono di inserire i file necessari per i carichi di lavoro, ad esempio i file VHD o VHDX per Hyper-V macchine virtuali. I volumi combinano le unità nel pool di archiviazione per introdurre i vantaggi di tolleranza di errore, scalabilità e prestazioni di Storage Spaces Direct, la tecnologia di archiviazione software-defined alla base di Azure Stack HCI e Windows Server.

Tutti i volumi sono accessibili da tutti i server del cluster contemporaneamente. Once created, they show up at C:\ClusterStorage\ on all servers.

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 otterranno 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) in modo uniforme 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 file system principale 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 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.

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 abilitare la disponibilità continua durante la manutenzione del server, ad esempio gli aggiornamenti software.

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 sulle unità in ogni server. L'efficienza di archiviazione è del 50 per cento; per scrivere 1 TB di dati, sono necessari 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 server con mirroring bidirezionale, quindi aggiunge resilienza all'interno di un server con mirroring bidirezionale o parità accelerata con mirroring. L'annidamento offre resilienza dei dati anche quando un server viene riavviato o non è disponibile. L'efficienza di archiviazione è del 25% con il mirroring bidirezionale annidato e circa il 35-40% per la parità accelerata con mirroring annidato. La resilienza annidata può tollerare in sicurezza due guasti hardware alla volta (due unità o un server e un'unità sull'altro server). Grazie a questa maggiore resilienza dei dati, è consigliabile usare la resilienza annidata nelle distribuzioni di produzione di cluster a due server. For more info, see Nested resiliency.

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 significa mantenere tre copie di tutti i dati, una copia sui dischi 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 (dischi o server) alla volta. Se 2 nodi non sono disponibili, il pool di archiviazione perde il quorum, poiché 2/3 dei dischi non sono disponibili e i dischi virtuali non sono accessibili. Tuttavia, un nodo può essere inattivo e uno o più dischi in un altro nodo possono avere esito negativo e i dischi virtuali rimangono online. Ad esempio, se si riavvia un server quando improvvisamente un'altra unità o un altro 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 il mirroring triplo, la doppia parità (spesso detta "codifica di cancellazione") o combinare i due con parità accelerata dal mirroring.

La parità doppia garantisce 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% dell'efficienza di archiviazione con sette server e continua fino all'80,0% dell'efficienza di archiviazione. Il compromesso è che la codifica della parità richiede più capacità di calcolo, il che può limitare le prestazioni.

Il tipo di resilienza da usare dipende dai requisiti di prestazioni e capacità per l'ambiente. Ecco una tabella che riepiloga le prestazioni e l'efficienza di archiviazione di ogni tipo di resilienza.

Resiliency type	Capacity efficiency	Speed
Mirror	Specchio a tre vie: 33% Two-way-mirror: 50%	Highest performance
Mirror-accelerated parity	Dipende dalla proporzione di mirror e parità	Molto più lento del mirroring, ma fino a due volte più veloce rispetto alla doppia parità Ideale per scritture e letture sequenziali di grandi dimensioni
Dual-parity	4 server: 50% 16 server: fino a 80%	Latenza di I/O più elevata e utilizzo della CPU nelle scritture Ideale per scritture e letture sequenziali di grandi dimensioni

Quando le prestazioni sono più importanti

I carichi di lavoro con requisiti di latenza rigorosi o che richiedono un numero elevato di operazioni di I/O al secondo casuali miste, ad esempio database SQL Server o macchine virtuali sensibili alle prestazioni Hyper-V, devono essere eseguiti su volumi che usano il mirroring per ottimizzare le 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 VDI (Virtual Desktop Infrastructure) o altri che non creano un numero elevato di traffico I/O casuale veloce e/o che non richiedono prestazioni ottimali possono anche usare 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 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 il mirroring e la doppia parità. Le operazioni di scrittura vengono inizialmente collocate nella porzione con mirroring e vengono successivamente trasferite nella parte di parità. Ciò accelera l'ingestione e riduce l'utilizzo delle risorse quando arrivano scritture di grandi dimensioni, consentendo alla codifica di parità, che richiede molte risorse di calcolo, di avvenire in un periodo di tempo più lungo. Quando si determinano le dimensioni delle porzioni, considerare che la quantità di scritture che si verificano contemporaneamente (ad esempio, un backup giornaliero) deve adattarsi comodamente nella sezione specchio. Ad esempio, se si inseriscono 100 GB una volta al giorno, prendere in considerazione l'uso del mirroring per 150 GB a 200 GB e la doppia parità per il resto.

L'efficienza di archiviazione risultante dipende dalle proporzioni scelte.

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à. Questo avviene automaticamente. Per altre informazioni, vedere Informazioni sulla cache in Spazi di archiviazione diretta. In tali implementazioni, tutti i volumi si trovano infine nello stesso tipo di unità, ovvero unità di disco per la 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.

Scelta della dimensione dei volumi

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

Footprint

La dimensione di un volume si riferisce alla capacità utilizzabile, la quantità di dati che può archiviare. This is provided by the -Size parameter of the New-Volume cmdlet and then appears in the Size property when you run the Get-Volume cmdlet.

Size is distinct from volume's footprint, the total physical storage capacity it occupies on the storage pool. L'impronta dipende dal tipo di resilienza ad essa associato. Ad esempio, i volumi che usano il mirroring a tre vie hanno un footprint tre volte le dimensioni.

Le impronte dei volumi devono stare nel pool di archiviazione.

Reserve capacity

Lasciare una certa capacità non allocata nel pool di archiviazione consente ai volumi di riparare "sul posto" dopo il guasto dei dischi, migliorando la sicurezza dei dati e le prestazioni. Se è disponibile una capacità sufficiente, un ripristino immediato e parallelo sul posto può riportare i volumi a piena resilienza anche prima che le unità guaste vengano sostituite. Avviene automaticamente.

È consigliabile riservare l'equivalente di un'unità di capacità per server, fino a 4 unità. È possibile riservare di più a propria discrezione, ma questa raccomandazione minima garantisce che un ripristino parallelo immediato, sul posto, possa riuscire dopo il guasto di qualsiasi unità.

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

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, abbiamo messo da parte quattro unità, ovvero 8 TB, in modo che le riparazioni sul posto possano verificarsi senza fretta di sostituire le unità dopo che si guastano. Ciò lascia 120 TB di capacità di archiviazione fisica nel pool con cui è possibile creare volumi.

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

Supponiamo che la nostra implementazione debba ospitare alcune macchine virtuali Hyper-V altamente attive, ma abbiamo anche molta archiviazione a freddo, ovvero vecchi file e backup che abbiamo bisogno di conservare. Poiché sono disponibili quattro server, è possibile creare quattro volumi.

Let's put the virtual machines on the first two volumes, Volume1 and Volume2. Scegliamo ReFS come file system (per la più veloce creazione e i checkpoint) e il mirroring a tre vie per la resilienza per massimizzare le prestazioni. Let's put the cold storage on the other two volumes, Volume 3 and Volume 4. Abbiamo scelto NTFS come file system (per la deduplicazione dei dati) e la doppia parità per la resilienza del sistema per massimizzare la capacità.

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

Volume1 and Volume2 each occupy 12 TB x 33.3 percent efficiency = 36 TB of physical storage capacity.

Volume3 and Volume4 each occupy 12 TB x 50.0 percent efficiency = 24 TB of physical storage capacity.

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

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

Per semplicità, in questo esempio vengono utilizzate unità decimali (base-10), vale a dire 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 viene visualizzato come 116,41 TiB. Questo è previsto.

Usage

See Creating volumes.

Next steps

Per altre informazioni, vedere anche:

• Scelta delle unità per Storage Spaces Direct
• Tolleranza di errore ed efficienza di archiviazione