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, inclusa la scelta del file system, del tipo di resilienza e delle 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 Storage Space Direct, configurarlo nelle macchine virtuali.
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 le 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 diretta, la tecnologia di archiviazione software-defined dietro Azure Stack HCI e Windows Server.
Nota
Il termine "volume" viene usato per fare riferimento congiuntamente al volume e al disco virtuale al suo interno, incluse le funzionalità fornite da altre funzionalità di Windows predefinite, ad esempio Volumi condivisi cluster (CSV) e ReFS. La comprensione di queste distinzioni a livello di implementazione non è necessaria per pianificare e distribuire correttamente Spazi di archiviazione diretta.
Tutti i volumi sono accessibili da tutti i server del cluster contemporaneamente. Dopo la creazione, vengono visualizzati in C:\ClusterStorage\ in tutti i server.
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 ReFS (Resilient File System) 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.
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 abilitare la disponibilità continua in tutta la manutenzione del server, ad esempio gli aggiornamenti software.
Nota
Quali tipi di resilienza è possibile scegliere è indipendente 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 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 modo sicuro due errori hardware alla volta (due unità o un server e un'unità nel server rimanente). Grazie a questa maggiore resilienza dei dati, è consigliabile usare la resilienza annidata nelle distribuzioni di produzione di cluster a due server. Per altre info, vedi 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 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 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 a tre vie, la doppia parità (spesso detta "codifica di cancellazione") o combinare i due con parità accelerata con 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à è più a elevato utilizzo di calcolo, 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.
| Tipo di resilienza | Efficienza della capacità | Velocità |
|---|---|---|
| Mirror |  Specchio a tre vie: 33% Mirror bidirezionale: 50% |
 Prestazioni più elevate |
| Parità accelerata con mirror |  Dipende dalla proporzione di mirror e parità |
 Molto più lento rispetto allo specchio, ma fino a due volte più veloce come doppia parità Ideale per scritture e letture sequenziali di grandi dimensioni |
| Parità doppia |  4 server: 50% 16 server: fino all'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 molte operazioni di I/O al secondo casuali miste, ad esempio database SQL Server o 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 Il file server di scalabilità orizzontale (SoFS), l'infrastruttura VDI (Virtual Desktop Infrastructure) o altri che non creano un numero elevato di traffico di I/O casuale veloce e/o che 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 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à. Scrive prima il terreno nella parte con mirroring e viene gradualmente spostato 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 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 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.
Suggerimento
Se si osserva una brusca diminuzione delle prestazioni di scrittura durante l'inserimento dei dati, potrebbe indicare che la parte mirror non è sufficientemente grande o che la parità accelerata con mirroring non è adatta al 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 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à. Questo avviene automaticamente. Per altre informazioni, vedere Informazioni sulla cache in Spazi di archiviazione diretta. In tali distribuzioni, tutti i volumi si trovano infine nello stesso tipo di unità, ovvero le unità di capacità.
Nelle distribuzioni con tutti e tre i tipi di unità, solo le unità NVMe (FastEst Drive) 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 su all-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 e sul provider di software Volsnap, come avviene con i carichi di lavoro del file server, limitando le dimensioni del volume a 10 TB miglioreranno le prestazioni e l'affidabilità. Le soluzioni di backup che usano l'API RCT Hyper-V più recente e/o la clonazione di blocchi ReFS e/o le API di backup SQL native eseguono prestazioni ottimali fino a 32 TB e oltre.
Orma
La dimensione di un volume si riferisce 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à di archiviazione fisica totale 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 le dimensioni.
I footprint dei volumi devono rientrare nel pool di archiviazione.
Capacità di riserva
Lasciare una certa capacità nel pool di archiviazione non allocato offre spazio ai volumi per ripristinare "sul posto" le unità dopo che le unità hanno esito negativo, migliorando la sicurezza e le prestazioni dei dati. Se è disponibile una capacità sufficiente, un ripristino immediato sul posto 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 di più a propria discrezione, ma questa raccomandazione minima garantisce un ripristino parallelo immediato, sul posto, 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, 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.
Nota
Nei cluster con unità di tutti e tre i tipi (NVMe + SSD + HDD), è consigliabile riservare l'equivalente di un'unità SSD più un HDD per server, fino a 4 unità di ognuna.
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 questo 128 TB nel pool di archiviazione, abbiamo messo da parte quattro unità, o 8 TB, in modo che le riparazioni sul posto possano verificarsi senza fretta di 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 di aver bisogno della distribuzione per ospitare alcune macchine virtuali Hyper-V altamente attive, ma abbiamo anche un sacco di archiviazione ad accesso sporadico, ovvero file e backup obsoleti che è necessario conservare. Poiché sono disponibili quattro server, è possibile creare quattro volumi.
Le macchine virtuali verranno ora inserite 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. Inserire l'archiviazione ad accesso sporadico 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, è possibile renderli tutti 12 TB.
Volume1 e Volume2 occupano ogni efficienza di 12 TB x 33,3% = 36 TB di capacità di archiviazione fisica.
Volume3 e Volume4 occupano ogni 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.
Suggerimento
Non è necessario creare immediatamente tutti i volumi. È sempre possibile estendere i volumi o creare nuovi volumi in un secondo momento.
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. Si tratta di un comportamento previsto.
Utilizzo
Vedere Creazione di volumi in Azure Stack HCI.
Passaggi successivi
Per ulteriori informazioni, vedere anche: