I dati sono la vostra risorsa più importante, ma ogni set di dati richiede un livello di protezione diverso. Trattare tutti i dati allo stesso modo nel vostro piano di continuità operativa può comportare rischi e costi finanziari per l'organizzazione. Ma come implementare un processo flessibile di protezione dei dati che copra diversi fornitori e architetture di archiviazione?
Scopri come DataCore può aiutarti ad affrontare questa sfida e a garantire il giusto livello di protezione per i tuoi dati più critici.
Trascrizione del webcast
Sandro Lima: Mi chiamo Sandro Lima e sono direttore dello sviluppo tecnico commerciale presso DataCore Software. Oggi parleremo di come DataCore possa aiutarvi a gestire un insieme eterogeneo di dati nell’ambito delle vostre pratiche di continuità operativa. Abbiamo preparato alcuni contenuti interessanti, quindi entriamo subito nel vivo dell’argomento. Va bene. Non c’è bisogno di sottolineare quanto siano importanti i dati critici, giusto? Il fatto è che non è possibile trattare tutti i dati allo stesso modo e attribuire loro la stessa importanza nei vostri piani di continuità operativa e di disaster recovery. Quello che dovete fare è comprendere il potenziale impatto e i rischi associati a ciascun insieme di dati, in modo da fornire a ciascuno di essi i livelli di protezione adeguati.
E dal punto di vista dell’archiviazione dei dati, l’unico modo per farlo è disporre di un’ampia gamma di funzionalità in grado di garantire queste adeguate misure di protezione dei dati, giusto? A seconda dei requisiti RTO e RPO dei vostri dati. Fornirò [incomprensibile 0:01:27] ulteriori dettagli su ciascuna di queste – o su alcune di queste – funzionalità, ma ora vorrei solo evidenziare alcune delle sfide che potreste dover affrontare quando cercate di implementare questa ampia gamma di funzionalità nell’intera infrastruttura di archiviazione.
Problema: presenza di più fornitori di soluzioni di archiviazione
Quindi, il primo, ed è molto comune, è quello di avere più fornitori di soluzioni di storage. Non è raro, infatti, che un’azienda abbia due o più fornitori diversi di [array] di storage, e ciò che accade [è] che ciascuno di essi abbia funzionalità diverse e, il più delle volte, non comunichino tra loro; di conseguenza, anche quando potrebbero fornire la stessa funzionalità, ad esempio in questo caso, immaginiamo di avere i fornitori uno, due e tre, che offrono tutti Snapshot, per esempio, ma anche in questo caso hanno configurazioni diverse, interfacce diverse, e si finisce per dover creare tre processi distinti, gestendoli separatamente nel proprio piano BCDR. Questo non fa che aumentare la complessità.
Problema: modelli di archiviazione diversi
Quindi, la seconda sfida [che anche voi – molto comune, tra l’altro] è rappresentata dai diversi modelli di storage. Ci sono aziende che utilizzano array di storage tradizionali – [sfruttando] array di storage tradizionali, collegati tramite SAN (Storage Area Network); altre che adottano un modello più [convergente], sfruttando il collegamento diretto e lo storage interno; altre ancora che optano per soluzioni iperconvergenti o con ingombro minimo e implementazione semplice, ma ciò che osserviamo molto frequentemente nella nostra base clienti è uno scenario ibrido, in cui le aziende dispongono di modelli di ogni tipo, compreso cloud l’archiviazione o il disaster recovery. Quindi, combinando diversi fornitori di storage con diversi modelli di storage, è facile capire come la situazione diventi davvero complessa quando si tratta di implementare tutte queste funzionalità nell’intera infrastruttura di storage.
Ma la questione non finisce qui. Infatti, anche se si mette a punto un piano BCDR ben progettato e ben testato, il problema è che l’ambiente è in continua evoluzione. Per tutta la durata di vita del data center, la tecnologia viene aggiornata, giusto? Quindi, si introducono nuovi fornitori, nuove architetture, nuove tecnologie. Bisogna gestire fusioni e acquisizioni e poi, all’improvviso, ci si trova a dover integrare e adottare altri fornitori, architetture, procedure [del personale] e tutto il resto. Possono verificarsi cambiamenti nel data center, come un trasferimento fisico o un ampliamento. Forse la vostra azienda vuole sfruttare cloud aggressivo per la replica o per il disaster recovery. E l’elenco potrebbe continuare all’infinito, giusto? Il punto è che le cose cambiano continuamente e il vostro piano BCDR deve essere sufficientemente flessibile da adattarsi a questi cambiamenti nel tempo.
Soluzione: DataCore
Va bene. Quindi, in questo scenario, [avete] diversi fornitori, diversi – diversi fornitori, diversi modelli di storage e un ambiente in continua evoluzione. Quindi, come potete comunque raggiungere il nostro obiettivo di avere questa ampia gamma di funzionalità costantemente disponibili su tutta la vostra infrastruttura di storage? Noi di DataCore crediamo che tutto parta dall’avere un insieme molto completo di servizi [avanzati] forniti attraverso un’unica piattaforma. Ed è esattamente ciò che offre DataCore, giusto? Abbiamo il mirroring sincrono, la replica sincrona, la protezione continua dei dati di cui parleremo tra un attimo, snapshots molti altri servizi di dati di livello enterprise che possono essere implementati in tutta la vostra infrastruttura di storage in modo estremamente coerente. E con questa piattaforma è possibile integrare e gestire qualsiasi tipo di storage: Direct-Connect, SAN… come potete vedere in basso, abbiamo ISCSI, Fibre Channel, NVME, Direct-Attached e cloud, giusto?
E a livello superiore, dove [si] trovano gli utenti, possiamo fornire questo storage a diversi tipi di host: dai servizi finanziari agli hypervisor, alle macchine virtuali e ai container. Questo è quindi il primo passo: disporre di un’ampia gamma di servizi dati accessibili tramite un’unica piattaforma. Un secondo passo, importante quanto il primo, è il modello di implementazione, ed è proprio qui che la natura «soft-defined» di DataCore consente di implementarlo su qualsiasi modello. Possiamo quindi implementare DataCore come controller di storage, sia per lo storage primario che secondario, in uno scenario iperconvergente; è possibile installarlo sul cloud o in un sito di disaster recovery. Non importa quale modello abbiate oggi o prevediate di adottare in futuro: saremo in grado di supportare qualsiasi fornitore utilizziate ora o in futuro, e voi potrete gestirlo con DataCore.
E ora possiamo vedere un'immagine di ciò che stavo [disegnando], ovvero, in sostanza, la disponibilità di questa serie coerente di servizi [ad ampio raggio] in tutto il vostro data center. Quindi, probabilmente ora potete rendervi conto di come ciò possa semplificare i vostri processi e la progettazione dei vostri piani di continuità operativa e di ripristino di emergenza.
Funzionalità di DataCore
Allora, ora parliamo un po’ più nel dettaglio di alcune di queste funzionalità, va bene? La prima riguarda i dati: questo aspetto è fondamentale, giusto? Stiamo parlando di un RTO compreso tra microsecondi e millisecondi e di un RPO pari a zero. Ciò significa che non si può verificare alcuna perdita di dati e che l’accesso ai dati è ininterrotto. In queste situazioni, il mirroring sincrono e [incomprensibile 0:08:36] sono [fondamentali], giusto? Allora, approfondiamo un po’ l’argomento: il mirroring sincrono consente di avere due copie dei dati su due nodi che agiscono come un unico sistema. Quindi, non appena uno dei due diventa indisponibile, il secondo è [pronto] a diventare primario, evitando qualsiasi interruzione dei dati. E il sistema garantisce che questi dati siano sempre sincronizzati.
Quindi, questo diagramma illustra come funziona, ed è molto semplice: abbiamo due nodi, tre [host] in alto; immaginate di avere due dischi in servizio: il VD uno, ad esempio, sul lato sinistro, è gestito principalmente dal nodo uno, con il nodo due come secondario. Entrambi sono attivi e sincronizzati, quindi ogni volta che il nodo uno diventa indisponibile, il nodo due può subentrare e, nell’host, non si riscontra alcuna interruzione nell’accesso ai dati. Un altro esempio di mirroring sincrono è quello che chiamiamo cluster estesi o [meta]-cluster. In pratica, si tratta di due nodi che non si trovano nello stesso luogo, ma a diverse miglia di distanza in posizioni diverse. Pertanto, purché si disponga di un collegamento a bassa latenza che li colleghi entrambi, è possibile ottenere tutti i vantaggi del mirroring sincrono: nessuna perdita di dati, nessuna interruzione dell’accesso ai dati, ma con una ridondanza aggiuntiva, poiché trovarsi in luoghi separati significa disporre di risorse [incomprensibile 0:10:25] indipendenti e di chiamate indipendenti; si ottengono quindi i vantaggi del mirroring sincrono con una ridondanza aggiuntiva. Questo sarebbe quindi un secondo scenario. Pertanto, il mirroring sincrono con [fillover] automatico sarebbe l’ideale per i dati più frequenti che devono essere disponibili in ogni momento e non ammettono alcuna perdita di dati.
Un terzo esempio potrebbe essere quello di avere una terza copia dei dati. Quindi, in questo caso, si hanno due nodi configurati in modalità HA [alta disponibilità], e poi si può avere una terza copia dei dati, ma questa sarebbe in modalità standby, giusto? Questo diventa molto utile, ad esempio, quando si deve mettere fuori servizio un nodo per manutenzione, ma i dati sono così critici che non è possibile perdere l’accesso HA agli stessi. Quindi, ciò che si può fare in questo caso è spegnere il nodo uno per manutenzione, ad esempio, e avviare manualmente il nodo tre, che formerà così una coppia HA con il nodo due. Quando il nodo uno torna operativo, il sistema torna semplicemente a fare affidamento su di esso e tutto torna alla normalità. Questo offre quindi la flessibilità necessaria per eseguire queste finestre di manutenzione senza compromettere l’HA dei dati.
Va bene, andiamo avanti. Allora, il secondo modello è quello in cui gli RTO sono compresi tra pochi secondi e alcuni minuti, ma [come vedete] avete RPO rigorosi; in questo caso, la replica [asincrona] sarà la soluzione più adatta. Per spiegare un po’ meglio [di cosa si tratta], la replica sincrona consiste nella capacità del disco primario di trasmettere in streaming tutte le modifiche attraverso la rete verso una sede remota, giusto? Questa immagine illustra lo scenario più comune per la replica sincrona, ovvero la creazione di siti di DR (Disaster Recovery). Come vedete a sinistra, ci sono due nodi configurati in modalità HA (High Availability), con mirroring sincrono tra di essi, quindi in HA, mentre tutte le modifiche vengono replicate in modo asincrono verso il sito di DR. E ogni volta che si verifica un problema nel data center primario, è possibile attivare la seconda copia presente nel sito di DR e procedere al ripristino da quella. Un altro esempio, anch’esso molto comune, di utilizzo della replica è quello dello storage secondario. A volte, infatti, si desidera disporre di una copia separata dei propri dati, ma non si vuole archiviarla sullo storage primario, veloce e costoso; in questi casi è possibile utilizzare la replica asincrona per trasferire tutte queste modifiche verso uno storage secondario, più lento ma più economico.
Va bene, allora andiamo avanti. Il nostro terzo caso è quello in cui si hanno RTO che vanno da pochi minuti a ore o addirittura giorni, giusto? E in questo caso, snapshots i backup sono all’ordine del giorno. Quindi… ma un caso particolare è quando si desiderano comunque questi RTO non troppo rigidi, ma si hanno RPO molto rigidi, e in questo caso il CDP – che sta per “protezione continua dei dati” – può essere davvero la soluzione ideale. Lasciatemi spiegare un po’ meglio cos’è la CDP. La CDP consente di registrare e documentare costantemente tutte le modifiche che avvengono sui dischi. Un’analogia comune che usiamo è quella con un DVR – ovvero un videoregistratore digitale – quindi immaginate di registrare tutto ciò che accade in tempo reale e di poter riavvolgere fino a qualsiasi punto nel tempo per creare un’immagine in quel preciso istante.
Un esempio molto interessante – e che purtroppo sta diventando sempre più comune – è la protezione contro il ransomware. Immaginate questo: il CDP vi permette di proteggere questi dischi critici e, in caso di attacco ransomware, potete praticamente tornare indietro fino al secondo esatto precedente all’evento e ripristinare i dati da quel punto. In questo modo, la perdita di dati è praticamente pari a zero e il ripristino avviene molto rapidamente. Un’altra pratica che osserviamo tra i clienti è quella di non limitarsi a creare un’immagine per il ripristino, ma di creare anche altre immagini nel corso del tempo, fondamentalmente a fini forensi e di analisi, ovvero per indagare e cercare di capire come si sia verificata l’infezione in primo luogo. Ma questo non è l’unico caso d’uso del CDP. Abbiamo anche, ad esempio, la protezione contro la cancellazione accidentale dei file.
Va bene. E l'ultimo punto riguarda snapshots. Quindi, snapshots sono molto comuni, quindi tutti sanno snapshots: consentono di catturare un’immagine del disco in un determinato momento. Tuttavia, ci sono alcuni vantaggi aggiuntivi quando si utilizzano snapshots DataCore. Il primo vantaggio è che l’operazione avviene a livello di storage. È possibile creare snapshots livello di host, ma ciò dipende dal [software utilizzato] e richiede risorse dall’host, giusto? Ebbene, effettuandole a livello di storage, possiamo renderle completamente trasparenti per l’host. Questo è il primo vantaggio. Il secondo è che DataCore offre la possibilità di creare snapshots[differenziali]. Si tratta di snapshots molto leggeri snapshots è possibile acquisire. Pertanto, se si desidera acquisire snapshots frequenza, questi snapshots differenziali snapshots un’ottima opzione.
In terzo luogo, se desiderate uno snapshot completo, ovvero una copia o un’immagine completa del disco, potete farlo: DataCore vi offre la possibilità di archiviare questo snapshot qualsiasi altro sistema di storage. Pertanto, non è necessario, ad esempio, se state creando uno snapshot [vostri] dati ad alta attività, archiviare lo snapshot e consumare risorse su questo sistema di storage veloce e costoso. Potete quindi spostarla su un altro sistema di archiviazione, magari di un altro fornitore, e archiviare snapshots le snapshots .
Bene, per oggi è tutto; se siete interessati a saperne di più, sul nostro sito web è disponibile una pagina dedicata alla continuità operativa, ricca di risorse; inoltre, vorrei sottolineare che, oltre a queste [poche] funzionalità di cui abbiamo parlato oggi, ce ne sono molte altre, soprattutto in termini di prestazioni ed efficienza, quindi visitate [il nostro] sito web DataCore e cercate questo link: troverete spiegazioni e dettagli su tutte le funzionalità di DataCore.
Iniziamo mettendo la pietra angolare del data center software-defined di nuova generazione
Altre risorse
- Solution Brief: Mantenere le pratiche collaudate di continuità operativa nonostante gli inevitabili cambiamenti nell'infrastruttura di archiviazione dei dati
- PDF del webcast: Pratiche di continuità operativa per set di dati eterogenei
- Articolo del blog: Pianificazione della continuità operativa: fattori legati allo storage spesso trascurati
- Business continuity: ridurre i downtime
- Video: Temete che l'hardware di archiviazione possa minare le fondamenta dei vostri piani di continuità operativa e di ripristino di emergenza?