RAID vs JBOD: la migliore opzione di storage per i backup degli hypervisor

Quando si configura lo storage su server locali o dispositivi NAS (Network Attached Storage), RAID e JBOD sono le due opzioni più comuni. Entrambe prevedono l’unione di più unità in un unico volume, ma differiscono in modo significativo per quanto riguarda la distribuzione, la protezione dei dati e l’accesso ai dati. La scelta di una configurazione errata può comportare un calo delle prestazioni o la perdita di dati. Questo articolo illustra le differenze tra JBOD e RAID e individua i tipi di storage ottimali per i backup e gli archivi dati delle macchine virtuali.

NAKIVO per il backup di VMware vSphere

Protezione completa dei dati per le macchine virtuali VMware vSphere e opzioni di ripristino istantaneo. Destinazioni di backup sicure onsite, offsite e nel cloud. Funzioni anti-ransomware.

Rileva la soluzione

RAID vs JBOD: differenze fondamentali

Il RAID (Redundant Array of Independent Disks) combina più unità fisiche in un’unica unità logica per migliorare le prestazioni, garantire la ridondanza o entrambe le cose. I diversi livelli RAID offrono diversi compromessi tra velocità e protezione dei dati, adatti a scenari diversi.

Il RAID 0 (Striping) combina i dischi per migliorare le prestazioni. I dati vengono suddivisi in blocchi distribuiti tra le unità disco e accessibili in parallelo, aumentando la velocità di lettura e scrittura. Non vi è ridondanza: se un’unità si guasta, tutti i dati vanno persi. Per il RAID 0 sono obbligatori almeno due dischi.

RAID 1 (Mirroring) è un livello RAID affidabile con ridondanza al 100%. I dati vengono duplicati su due unità; questa configurazione garantisce un elevato livello di protezione dei dati, ma la capacità di storage viene dimezzata (ad esempio, se si utilizzano due unità da 10 TB in RAID 1, la capacità utilizzabile è di 10 TB). Per il RAID 1 sono obbligatori almeno due dischi.

RAID 10 (1+0) combina prestazioni elevate con una ridondanza del 100%. Le coppie di dischi in mirroring (1) vengono raggruppate in striping (0), rendendo questo livello particolarmente adatto ai server. Il RAID 10 richiede almeno 4 dischi. L’array viene creato in questo ordine:

RAID 1 esegue il mirroring → RAID 0 distribuisce i dati in striping tra i mirror.

RAID 5 (Striping + Parità) bilancia prestazioni, capacità e ridondanza. I dati vengono distribuiti in striping su più dischi insieme alle informazioni di parità, che possono essere utilizzate per il ripristino dei dati e la ricostruzione dell’array. La configurazione è progettata per tollerare il guasto di un disco grazie alla parità distribuita: un disco di parità equivalente per il RAID 5 e due per il RAID 6. Per il RAID 5 è obbligatorio utilizzare almeno 3 dischi.

RAID 6 è simile al RAID 5 ma utilizza la doppia parità, consentendo all’array di sopravvivere teoricamente al guasto di due dischi. Per il RAID 6 sono obbligatori almeno 4 dischi.

JBOD (Just a Bunch of Disks) non è un livello RAID. Descrive una configurazione in cui più dischi operano in modo indipendente o sono combinati senza logica RAID né ridondanza.

Esistono due forme di JBOD:

1. Dischi indipendenti (vero JBOD): ogni disco appare separatamente. Ad esempio, un JBOD con tre unità si presenta così:
1. Unità 1 (2 TB)
2. Unità 2 (4 TB)
3. Unità 3 (1 TB)
2. Spanning/concatenazione : Più dischi vengono uniti in un unico grande volume logico (chiamato anche disk spanning, modalità lineare o concatenazione). In questo caso, un insieme di dischi da 2 TB + 4 TB + 1 TB appare come un unico volume da 7 TB. I file su un volume JBOD esteso riempiono il primo disco e poi si estendono a quello successivo. Poiché l’estensione scrive in modo sequenziale, i nuovi file cercano di riempire il blocco di indirizzi logici disponibile più basso.

Questo comportamento sequenziale funziona perfettamente in teoria, dove i file riempiono un disco prima che il sistema passi a quello avanti. In pratica, i file vengono continuamente creati, modificati ed eliminati, specialmente sui server e sui sistemi sottoposti a carico elevato. Di conseguenza, in una configurazione JBOD estesa è raro che i dati rimangano confinati in modo ordinato su un singolo disco.

Quando un file viene eliminato, i blocchi corrispondenti vengono contrassegnati come liberi nel file system. Queste eliminazioni creano spazi vuoti tra i file rimanenti. Le nuove operazioni di scrittura potrebbero quindi risultare frammentate, con i relativi blocchi sparsi su più dischi del volume JBOD esteso. Se un disco del volume si guasta, qualsiasi file con blocchi su quel disco va perso — anche se altre parti risiedono su unità integre.

Quando viene scritto un nuovo file di grandi dimensioni, la prima parte potrebbe riempire uno spazio vuoto sul Disco 1, mentre le parti rimanenti possono essere suddivise tra lo spazio libero sequenziale sul Disco 2 e sul Disco 3. I dati risultano frammentati sia logicamente (all’interno di NTFS) che potenzialmente fisicamente (su più dischi). I nuovi file più piccoli potrebbero semplicemente riempire uno spazio vuoto lasciato da un’eliminazione su uno dei dischi esistenti.

Nota: JBOD, LVM e i volumi NTFS estesi (spanned) creano tutti un unico grande volume che si estende su più dischi, ma differiscono per il livello di astrazione, la flessibilità, il dominio di guasto e le capacità di gestione. LVM, utilizzato nei sistemi basati su Linux, offre un approccio più avanzato, dinamico e flessibile. JBOD opera a livello di file system (ad esempio, NTFS), mentre LVM introduce un livello di gestione dei volumi tra i dischi fisici e il file system. Ciò consente a LVM di supportare il ridimensionamento dinamico dei volumi, le scritture non sequenziali e il RAID 1 software (mirroring dei dischi).

La deframmentazione, supportata da NTFS, può ridurre la frammentazione e migliorare le possibilità di ripristinare i file dai dischi integri in un volume JBOD se un disco si guasta dopo il completamento del processo di deframmentazione. Tuttavia, la deframmentazione comporta un carico elevato su tutte le unità e richiede molto tempo su volumi di grandi dimensioni. Se un disco si guasta durante la deframmentazione, i file potrebbero andare persi o l’intero volume potrebbe smettere di funzionare.

Nota: La deframmentazione applica le operazioni di deframmentazione alle unità disco rigido ma non alle unità a stato solido.

Le principali differenze tra JBOD e RAID sono:

• Il RAID è progettato per garantire ridondanza, prestazioni o entrambe. La configurazione è più complessa e i requisiti hardware sono più elevati. Se un disco si guasta, il RAID richiede tempo per ricostruire l’array.
• Il JBOD offre la massima capacità utilizzabile e supporta l’unione di unità di dimensioni diverse in un unico volume. La configurazione è semplice, ma non offre ridondanza né tolleranza ai guasti.

Quando si confrontano il RAID e il JBOD, il parallelo più vicino è tra il RAID 0 e il JBOD spanning, poiché nessuno dei due offre ridondanza. In questo articolo, “JBOD” si riferisce alla forma spanning/concatenazione, salvo diversa indicazione.

Confronto delle prestazioni di backup e ripristino

JBOD non migliora le prestazioni, indipendentemente da come viene utilizzato. Solo il RAID può aumentare la velocità.

In una configurazione JBOD spanning , i dati riempiono un disco prima di essere scritti su quello successivo:

• Un file memorizzato interamente sul Disco 1 viene letto e scritto alla velocità nativa del Disco 1.
• Un file che si estende su più dischi è limitato dal disco più lento. L’aumento del tempo di ricerca tra i dischi e una maggiore latenza possono rendere il JBOD più lento di un singolo disco autonomo.

Il JBOD offre la massima capacità senza alcun guadagno in termini di prestazioni, parallelismo o striping.

Le prestazioni RAID dipendono dal livello (tipo) di RAID configurato.

Il RAID 0 (Striping) offre le prestazioni più elevate poiché i dati vengono suddivisi su più dischi e vi si accede in parallelo. Ad esempio, con due unità in RAID 0, le operazioni di lettura e scrittura sequenziali possono raggiungere una velocità fino a 2 volte superiore a quella di un singolo disco. Se si utilizzano due dischi rigidi da 200 MB/s, la configurazione JBOD offre fino a 200 MB/s, mentre il RAID 0 può raggiungere fino a 400 MB/s.

RAID 1 (Mirroring) conserva dati identici su due unità. Le operazioni di lettura sono spesso più veloci: un controller può leggere da entrambi i dischi e raggiungere fino a 2 volte la velocità di un singolo disco in implementazioni ottimali. La velocità di scrittura è equivalente a quella di un singolo disco, poiché ogni scrittura deve essere eseguita su entrambe le unità.

RAID 10 (Striped Mirrors) combina RAID 1 e RAID 0, offrendo eccellenti prestazioni in termini di operazioni di input/output al secondo (IOPS).

• Letture: fino a N × velocità del disco.
• Scritture: solitamente circa la metà delle prestazioni del RAID 0 (ma comunque significativamente più veloce di un singolo disco).

Il RAID 10 offre la migliore combinazione di prestazioni e ridondanza tra i livelli RAID e supera il JBOD in tutti i parametri di prestazione.

RAID 5 (Striping + Parità singola) richiede tre o più dischi. Le prestazioni di lettura e scrittura differiscono:

• Letture: Veloce, anche se non quanto il RAID 0 (parallelizzazione pari a N–1 dischi).
• Scritture: più lente a causa del calcolo della parità e della penalità di scrittura “”.

Le velocità di scrittura su RAID 5 sono in genere circa la metà di quelle del RAID 0 a parità di numero di dischi.

Il RAID 5 supera il JBOD nei carichi di lavoro con un’elevata attività di lettura, ma nei carichi di lavoro con un’elevata attività di scrittura può risultare più lento del RAID 0 e, in alcuni casi, leggermente più lento del JBOD.

Il RAID 6 (doppia parità) si comporta in modo simile al RAID 5, ma comporta una penalizzazione in scrittura ancora maggiore:

• Letture: paragonabili a quelle del RAID 5.
• Scritture: in genere le più lente tra i livelli RAID comuni.

Le prestazioni in lettura superano comunque quelle del JBOD, mentre quelle in scrittura potrebbero risultare inferiori.

In sintesi :

• RAID 0 offre le prestazioni grezze più elevate.
• RAID 10 offre il miglior equilibrio tra prestazioni e affidabilità.
• JBOD è adatto a grandi volumi di storage in cui velocità e ridondanza non sono prioritarie.

Tenete presenti queste caratteristiche quando scegliete RAID o JBOD come storage di origine o destinazione per le operazioni di backup e ripristino.

Nota: Evitate di utilizzare il “fake RAID”, una funzione integrata nelle schede madri dotate di porte SATA e configurabile tramite le impostazioni UEFI/BIOS. Questa forma ibrida di RAID software si basa sulla CPU dell’host. Il “fake RAID” non funziona in Linux e richiede driver speciali su Windows. Non offre l’affidabilità di un vero RAID hardware e non è possibile accedere ai dati SMART mentre il “fake RAID” è abilitato. In caso di problemi, ciò può comportare la perdita di dati. Quando il RAID hardware non è un’opzione, prendere in considerazione alternative RAID software autentiche come LVM di Linux, mdadm o ZFS.

Prestazioni e affidabilità del RAID

Le prestazioni sono importanti, ma l’affidabilità diventa altrettanto importante quando l’obiettivo è la protezione dei dati e il ripristino. Ogni livello RAID offre un profilo diverso, con RAID 5 e RAID 6 che meritano particolare attenzione.

RAID 0 è veloce in lettura, scrittura e archiviazione dei backup utilizzati nelle operazioni di ripristino. Tuttavia, se un disco si guasta, tutti i backup presenti sull’array vanno persi. Lo stesso rischio si applica ai dati primari archiviati su RAID 0 quando non esiste un backup separato.

Un secondo scenario di ripristino prevede la ricostruzione dell’array direttamente sui dischi stessi, senza ripristinare i dati da supporti esterni. Tutti i livelli RAID, ad eccezione del RAID 0, offrono funzionalità di autoriparazione che consentono di ricostruire l’array utilizzando i dati ridondanti o di parità presenti sui dischi rimanenti integri. Una volta sostituito il disco guasto, il processo di ricostruzione si avvia automaticamente.

RAID 1 con due dischi è in grado di sopportare il guasto di un disco ed è altamente affidabile. La ricostruzione è veloce e non è obbligatorio effettuare il calcolo della parità.

Il RAID 10 tollera il guasto di un singolo disco e può persino sopravvivere al guasto di due dischi, a condizione che i dischi guasti appartengano a coppie di mirroring diverse. L’affidabilità e la tolleranza ai guasti sono elevate e le ricostruzioni sono veloci poiché non è obbligatorio effettuare alcun calcolo della parità (a differenza del RAID 5).

Il RAID 5 può teoricamente resistere al guasto di un disco, mentre il RAID 6 può resistere al guasto di due dischi, ma l’affidabilità effettiva di questi livelli è inferiore a quanto sembri. Il rischio di un guasto totale dell’array aumenta significativamente durante il processo di ricostruzione. Il RAID 5, in particolare, merita un’attenta valutazione, nonostante la sua ridondanza dichiarata.

Il RAID 5 è stato sviluppato nel 1987, quando la capacità dei dischi era bassa (circa 20 MB) e la probabilità di una ricostruzione riuscita dopo il guasto di un singolo disco era elevata, date le velocità di ricostruzione dell’epoca. Le unità moderne hanno ormai capacità di 30 TB e oltre. Sebbene le capacità siano cresciute di diversi ordini di grandezza, le velocità delle unità meccaniche non hanno tenuto il passo, specialmente per gli HDD.

Quando un’unità si guasta in un RAID 5, l’array entra in uno stato degradato. In linea di principio, i dati rimangono accessibili dopo la ricostruzione dell’array. La quantità di dati da ricostruire è pari alla capacità di un disco, utilizzando i dati di parità distribuiti sui dischi rimanenti integri. Durante la ricostruzione, le prestazioni dei dischi dell’array subiscono un calo significativo poiché il controller deve eseguire ulteriori calcoli di parità e controlli di coerenza.

Dopo la sostituzione di un disco guasto, il controller RAID avvia la ricostruzione. Legge i dati rimanenti dai dischi integri e, sulla base delle informazioni di parità, scrive il contenuto ricostruito sul nuovo disco. I tempi di ricostruzione sono spesso lunghi e dipendono dal numero di dischi, dalla CPU del controller, dalla quantità di dati presenti nell’array e da fattori simili. Se il server continua a gestire carichi di lavoro ad alta intensità di I/O durante la ricostruzione, sia le prestazioni dell’array che la velocità di ricostruzione diminuiscono, prolungando ulteriormente il processo.

Poiché le capacità delle unità hanno una scalabilità maggiore delle loro velocità (soprattutto per gli HDD), i tempi di ricostruzione del RAID 5 continuano ad aumentare. Ad esempio, il ripristino di un array RAID 5 composto da cinque dischi HDD da 4 TB su un server molto sollecitato può richiedere più di un giorno, mentre gli array costituiti da dischi da 20 TB possono richiedere diversi giorni. Moltiplicate ulteriormente queste cifre per dischi da 30 TB.

Durante una ricostruzione RAID 5, l’array funziona di fatto senza ridondanza, proprio come un RAID 0. Anche una piccola interruzione — un errore di lettura del disco, un’interferenza di segnale, un problema al cavo — può causare il fallimento della ricostruzione. Se un secondo disco si guasta durante questa finestra temporale, tutti i dati presenti sull’array vanno persi.

Il parametro Bit Error Ratio (BER) viene utilizzato dai vendor per stimare l’affidabilità dei dischi. Il BER per i dischi di classe desktop è pari a 10^14, mentre i dischi di classe Enterprise raggiungono i 10^15. Il valore 10^14 indica che la probabilità di un errore di lettura irrecuperabile non è superiore a 1 su 100.000.000.000.000 di bit (14 zeri). 10^14 bit equivalgono a 11 TB di dati. Ciò significa che dopo aver letto circa 11 TB da un HDD di classe desktop, la probabilità che si verifichi almeno un errore di lettura a livello di bit è vicina al 100%. In pratica, le unità spesso si guastano prima di quanto suggerirebbe il loro Mean Time to Failure (MTTF) teorico.

Con gli HDD di classe Enterprise, la situazione migliora di un ordine di grandezza: la probabilità cumulativa di errore di lettura raggiunge quasi il 100% dopo la lettura di circa 110 TB di dati. Dato che gli HDD disponibili in commercio nel 2026 supereranno i 30 TB per unità, un BER di 10^15 non sembra più particolarmente rassicurante per gli array di grandi dimensioni. La probabilità di guasto è inferiore per i dischi con capacità inferiore e superiore per quelli con capacità maggiore.

È importante tenere presente che gran parte dei dati archiviati sugli array di dischi è costituita da dati inattivi — a cui si accede raramente, spesso inutilizzati per 1-2 anni. Poiché i sistemi non eseguono una scansione continua di ogni settore del disco per verificarne lo stato di integrità e la coerenza, alcuni file potrebbero trovarsi su blocchi che non sono più leggibili. Questo danneggiamento latente rimane invisibile fino a quando la ricostruzione del RAID 5 non lo porta alla luce — a quel punto diventa fatale.

L’uso del RAID 5 non è consigliato, specialmente nei sistemi di produzione o per i dati critici per l’azienda. Se il RAID 5 è comunque obbligatorio, non abbinarlo a controller a basso costo o a dischi di fascia consumer. Optate per controller RAID di livello Enterprise e unità con indici di affidabilità più elevati. Il RAID 6 offre prestazioni leggermente migliori rispetto al RAID 5, ma il rischio di perdita di dati rimane significativo.

I dati archiviati su un array RAID 5 dovrebbero sempre essere sottoposti a backup su un supporto di storage esterno per proteggersi da eventuali guasti dell’array. Lo stesso principio applica agli array RAID 0 e JBOD.

Affidabilità e prestazioni del JBOD

In una configurazione JBOD spanning, se un disco si guasta, qualsiasi file con blocchi presenti sull’unità danneggiata diventa illeggibile e irrecuperabile. Solo i file memorizzati interamente su unità integre possono essere potenzialmente ripristinati.

In configurazioni specifiche, il guasto di un singolo disco può causare il malfunzionamento dell’intero volume JBOD, anche se la maggior parte dei dati risiede su dischi integri, analogamente a quanto accade con il RAID 0. Il motivo risiede nei metadati del file system: se strutture critiche come la Master File Table (MFT) risiedono sull’unità guasta, il sistema operativo non è più in grado di mappare gli indirizzi logici ai blocchi fisici, rendendo inaccessibili i dati presenti sui dischi integri. Se il modello di scrittura della configurazione JBOD è sconosciuto, considerare lo storage come privo di tolleranza ai guasti.

Prestazioni RAID per VMware e Hyper-V

Lo storage RAID offre prestazioni più elevate, ma non tutti i livelli RAID sono adatti agli archivi dati delle VM o allo storage delle VM.

RAID 0 è veloce ma non sicuro. Il guasto di un singolo disco causa tempi di inattività fino a quando le VM interessate non vengono ripristinate dal backup o sottoposte a failover su repliche preesistenti delle VM. L’utilizzo di RAID 0 in un archivio dati di macchine virtuali richiede una solida strategia di backup e replica. L’uso di RAID 0 senza misure aggiuntive di protezione dei dati è fortemente sconsigliato negli ambienti di produzione. Può essere accettabile per carichi di lavoro temporanei, come laboratori e ambienti di test.

RAID 1 funziona bene per lo storage delle macchine virtuali in VMware, Hyper-V e altre piattaforme di virtualizzazione. Le prestazioni sono adeguate e la ridondanza dei dati al 100% previene i tempi di inattività dopo il guasto di un singolo disco, mentre l’array viene ricostruito. Il RAID 1 è una scelta ragionevole per ambienti virtuali di piccole dimensioni con un numero limitato di VM.

Il RAID 10 offre le massime prestazioni e affidabilità. Elevati valori di IOPS, bassa latenza, operazioni di lettura e scrittura veloci, solida tolleranza ai guasti e ricostruzioni rapide lo rendono il livello RAID consigliato per VMware, Hyper-V e altre piattaforme di virtualizzazione in ambienti di produzione.

RAID 5 offre prestazioni di lettura moderate, ma le prestazioni di scrittura sono più lente. Nonostante alcuni vantaggi in termini di lettura in condizioni di funzionamento normale, il RAID 5 non dovrebbe essere utilizzato per archiviare VM o dati mission-critical. Come discusso in precedenza, il rischio di ricostruzione è elevato e il degrado delle prestazioni durante la ricostruzione è grave.

RAID 6 offre prestazioni di lettura simili al RAID 5, ma scritture più lente. L’affidabilità risulta leggermente superiore rispetto al RAID 5, ma ne permangono tutti i punti deboli. Il RAID 6 non è consigliato per l’archiviazione di VM o dati critici.

Prestazioni JBOD per VMware e Hyper-V

A differenza dello storage di backup, lo storage per VM presenta requisiti prestazionali molto più rigorosi. I carichi di lavoro delle VM sono altamente sensibili a IOPS, latenza e throughput. In questo contesto, RAID e JBOD si comportano in modo molto diverso e persino la scelta del livello RAID influisce in modo significativo sulle prestazioni delle VM su quell’array.

I carichi di lavoro delle VM generano numerose operazioni di lettura e scrittura di piccole dimensioni e richiedono un elevato numero di IOPS, in particolare per i dischi virtuali che ospitano sistemi operativi, database e file server. I file di swap, il paging, gli snapshot e i dischi delta generano una forte amplificazione delle operazioni di scrittura. Durante il normale funzionamento delle VM sono comuni picchi periodici di I/O.

Poiché il JBOD è una delle configurazioni di storage più lente, non è consigliato per VMware, Hyper-V o altri file di VM, specialmente in ambienti di produzione.

Considerazioni sullo storage per VMware e Hyper-V

Entrambe le piattaforme VMware e Hyper-V dipendono fortemente dalle prestazioni e dalla coerenza dello storage, ma differiscono nel modo in cui accedono allo storage, ottimizzano i carichi di lavoro e proteggono i dati.

VMware vSphere è più sensibile alle prestazioni dello storage a causa del modo in cui VMFS, vMotion, snapshot e DRS interagiscono con gli archivi dati. I tipi di storage supportati da VMware vSphere sono:

• Storage Area Network (SAN): iSCSI, Fibre Channel, FCoE
• Network Attached Storage (NAS): NFS v3/v4.1
• Directly Attached Storage (DAS): RAID locale, NVMe, SSD
• vSAN (storage iperconvergente)
• Archivio dati sul cloud (vVols, condivisioni NFS)

NFS fornisce uno storage condiviso a livello di file, mentre iSCSI e DAS operano a livello di blocco.

Gli archivi dati VMFS sono il tipo di storage per macchine virtuali più utilizzato negli ambienti VMware vSphere grazie alla loro affidabilità, praticità e facilità di configurazione. VMFS è un file system a cluster che consente a più host VMware ESXi di accedere contemporaneamente agli stessi archivi dati, blocchi e file — un requisito fondamentale per le configurazioni a cluster. Le caratteristiche principali degli archivi dati VMFS di VMware includono:

• Ottimi per carichi di lavoro ad alto IOPS
• Supportano l’accesso di più host allo stesso archivio dati
• È obbligatorio un elevato throughput dello storage di backend
• Sono disponibili il thin provisioning e il thick provisioning
• Offrono prestazioni ottimali con RAID 10 per l’avvio delle VM e le attività di scrittura

I datastore VMFS possono essere creati su dischi locali (compresi gli array RAID locali tramite DAS) o su LUN iSCSI esposti da dispositivi SAN e NAS sulla rete. In entrambi i casi, il RAID viene in genere configurato sul dispositivo SAN o NAS sottostante per garantire prestazioni e affidabilità. Il RAID può essere utilizzato anche per configurare condivisioni file NFS su un file server.

Si applicano i principi di selezione del livello RAID descritti in precedenza. Gli SSD offrono le prestazioni più elevate, mentre gli HDD sono adeguati per carichi di lavoro meno esigenti. Il RAID 10 è la scelta ottimale per lo storage delle macchine virtuali VMware, con il RAID 1 come alternativa accettabile. VMware ESXi supporta solo il RAID hardware per lo storage collegato localmente.

Microsoft Hyper-V utilizza NTFS o ReFS sui Cluster Shared Volumes (CSV); il suo comportamento di storage differisce in modo significativo da quello di VMware vSphere. I tipi di archiviazione supportati in Hyper-V sono:

• DAS: array RAID (i più comuni)
• SAN: iSCSI/Fibre Channel
• SMB 3.0/3.02 (Scale-Out File Server — SOFS)
• Storage Spaces/Storage Spaces Direct (S2D)
• Archiviazione sul cloud basata su Azure

SMB è un protocollo di condivisione file nativo degli ambienti Microsoft.

Hyper-V memorizza VHDX i file dei dischi virtuali su volumi NTFS/ReFS collegati direttamente, su Cluster Shared Volumes (CSV) e su condivisioni file SMB 3.0. I CSV consentono a più host di accedere contemporaneamente allo stesso LUN, il che è obbligatorio per la configurazione del cluster. Hyper-V su Windows Server supporta RAID hardware, RAID simulato e RAID software. Le raccomandazioni relative al RAID per Hyper-V corrispondono a quelle per VMware: il RAID 10 è l’opzione migliore per gli host che eseguono carichi di lavoro delle macchine virtuali, mentre il RAID 1 rappresenta un’alternativa ragionevole. Il RAID hardware rimane l’implementazione preferita.

Costi di storage ed espansione

Il RAID aumenta generalmente i costi di storage perché la ridondanza riduce la capacità utilizzabile: si paga per più hardware rispetto allo spazio effettivo che si ottiene. Ad esempio:

• RAID 0: nessuna riduzione di capacità
• RAID 1: 50% di capacità utilizzabile (due unità in mirroring tra loro)
• RAID 10: 50% di capacità utilizzabile (strisce in mirroring)
• RAID 5: Perdita di capacità pari a un disco (N dischi → N−1 utilizzabili)
• RAID 6: perdita di capacità pari a due dischi (N dischi → N−2 utilizzabili)

Per ottenere le massime prestazioni e affidabilità è obbligatorio un controller RAID di alta qualità (dotato di batteria e cache), che comporta un costo elevato.

JBOD è l’opzione più economica poiché non richiede dischi aggiuntivi per la ridondanza né hardware di controllo speciale. È possibile aggiungere un numero qualsiasi di dischi per creare un volume di grandi dimensioni, a differenza del RAID 1, che è limitato a due unità. Il JBOD funziona anche con unità miste — di diversi vendor, capacità e velocità — ma questa flessibilità va a discapito delle prestazioni e dell’affidabilità.

È proprio in termini di espansione che le due configurazioni divergono nettamente. La maggior parte delle configurazioni RAID non può essere ampliata facilmente o supporta solo un’espansione limitata. In genere è necessario sostituire tutti i dischi membri con unità più capienti ma di pari capacità, oppure configurare un array RAID separato, il che è obbligatorio per le porte libere sul controller RAID o per un controller aggiuntivo. I controller RAID avanzati possono espandere il RAID 10 aggiungendo coppie di dischi. Il RAID 5 e il RAID 6 possono essere ampliati tramite l’aggiunta di dischi, ma il processo è rischioso e richiede molto tempo.

Il JBOD offre la massima flessibilità e il percorso di espansione più semplice. È possibile aggiungere un’unità in qualsiasi momento, indipendentemente dal produttore, dalla capacità, dal modello o da altri parametri. I nuovi dischi diventano immediatamente disponibili, senza necessità di ricostruzione o calcolo della parità.

Ottimizzazione delle prestazioni di backup con NAKIVO

Il JBOD può fungere da storage espandibile e a basso costo per i backup. La velocità di backup è in genere limitata dalla connessione di rete, con un sovraccarico aggiuntivo dovuto alla compressione e alla crittografia, il che significa che i limiti di velocità grezza del JBOD raramente costituiscono il collo di bottiglia. Ciononostante, ricordatevi del Regola di backup 3-2-1 e mantenete copie di backup aggiuntive che possano salvarvi in caso di guasto dello storage di backup primario.

Anche con livelli RAID affidabili come RAID 1 e RAID 10, i dati su questi array devono comunque essere sottoposti a backup. Il RAID 1 tollera il guasto di un disco, mentre il RAID 10 può sopravvivere a due guasti, a condizione che i dischi guasti appartengano a coppie di mirroring diverse. Tuttavia, la ridondanza non costituisce una protezione contro ogni tipo di guasto. La cancellazione accidentale, gli attacchi ransomware, il danneggiamento del software e i disastri fisici possono distruggere i dati o il server stesso. Il RAID a specchio è una forma di ridondanza, non un sostituto di un adeguato strategia di backup.

NAKIVO Backup & Replication include un’ampia gamma di funzionalità progettate per rendere la protezione dei dati veloce, sicura, affidabile e comoda.

• Backup di macchine virtuali senza agenti per VMware vSphere, Microsoft Hyper-V, Proxmox VE e Nutanix AHV. Per il backup dei dati a livello di host vengono utilizzate le API native dell’hypervisor.
• Trasferimento dei dati senza LAN : NAKIVO Backup & Replication seleziona automaticamente la modalità di trasferimento dati ottimale, come VMware Hot Add o Direct SAN Access, per ridurre il carico di rete e accelerare i backup.
• Accelerazione di rete : I dati vengono compressi prima di essere inviati in rete allo storage di backup di destinazione, migliorando la velocità di trasferimento e riducendo l’ingombro di storage.
• Pianificazione e automazione dei backup : Opzioni flessibili programmazione e conservazione consentono l’esecuzione automatica dei processi di backup, con un risparmio di tempo.
• Supporto per le appliance di deduplicazione : L’utilizzo di appliance di deduplicazione supportate e dei relativi protocolli nativi di trasferimento dati massimizza la velocità di backup e riduce al minimo l’utilizzo dello spazio di storage di backup. Le appliance supportate includono EMC Data Domain (DD Boost), HPE StoreOnce (Catalyst) e NEC HYDRAstor (Universal Express).
• Backup incrementale : Vengono trasferiti solo i dati modificati dall’ultimo backup completo o backup incrementale , consentendo di risparmiare tempo e migliorare le prestazioni rispetto ai backup esclusivamente completi.
• Tracciamento delle modifiche nativo per VMware e Hyper-V : Tracciamento delle modifiche dei blocchi di VMware (CBT) e Hyper-V Resilient Change Tracking (RCT) accelerano i backup incrementali.
• Esclusione dei dati di swap : I file e le partizioni di swap memorizzano dati temporanei del sistema operativo e aggiungono un volume superfluo ai backup. NAKIVO Backup & Replication li esclude, migliorando la velocità di backup e risparmiando spazio di archiviazione.
• Troncamento dei registri : I sistemi di database creano file di log per garantire la coerenza delle transazioni e fornire supporto per il ripristino. Questi log possono diventare molto grandi. La funzione di troncamento dei registri mantiene i backup più compatti.

Conclusione

Nonostante il basso costo e la scalabilità, lo storage JBOD non è adatto a dati critici o carichi di lavoro che richiedono prestazioni elevate. Il guasto di un singolo disco può causare la perdita dei dati. Il JBOD può fungere da storage di backup, ma solo se esiste almeno una copia di backup aggiuntiva su uno storage separato. I RAID 5 e RAID 6 dovrebbero essere evitati per i dati importanti. I RAID 10 e RAID 1 rimangono le opzioni più affidabili; il RAID 10 offre le prestazioni più elevate, rendendolo ideale per lo storage di VM con ridondanza completa. Anche con il miglior livello RAID, il backup dei dati dall’array rimane fondamentale, poiché molti casi di perdita di dati si verificano senza che si verifichi alcun guasto all’array.

Prova NAKIVO Backup & Replication

Richiedi una prova gratuita per scoprire tutte le funzionalità di protezione dei dati offerte dalla soluzione. 15 giorni gratuiti. Nessuna limitazione in termini di funzionalità o capacità. Non è obbligatoria alcuna carta di credito.

PROVA GRATUITAMENTE