Misure di Business Continuity per tempi volubili

Credo che il pubblico lo troverà molto attuale. Di solito è così… sicuramente qui nel sud della Florida. In questo periodo dell’anno, iniziamo a preoccuparci maggiormente del tempo. Anche se immagino che molti di voi siano stati al nord di qui e in altre località dell’emisfero settentrionale, il tempo sembra aver assunto un ruolo un po’ più cruciale nelle nostre riflessioni. Pertanto, il consiglio che segue ha lo scopo di aiutarvi fondamentalmente a mantenere i vostri piani di continuità operativa, adattandovi a quei cambiamenti inevitabili, ma imprevedibili, che sicuramente sconvolgeranno la vostra routine.

Ciò richiede che effettuiamo un’autovalutazione davvero obiettiva dei rischi, in particolare di quelli che hanno effetti a cascata, poiché questi tendono ad avere una grande influenza sull’efficacia con cui è possibile rafforzare le misure di sicurezza. Molti di questi rischi comportano conseguenze che sono in gran parte prevenibili.

E quindi, lo scopo del nostro intervento è quello di condividere con voi alcune delle esperienze che abbiamo maturato in un paio di decenni di attività in questo settore e di illustrarvi alcune delle scelte tattiche che potete adottare per far fronte agli sconvolgimenti ricorrenti che si profilano all’orizzonte.

Allora, la prima cosa che vorrei fare è aiutarvi con un rapido test. Questo test serve fondamentalmente a capire in che modo la vostra strategia di continuità operativa e di ripristino in caso di emergenza potrebbe essere compromessa se, nel corso del prossimo anno circa, doveste apportare qualche cambiamento significativo.

La struttura dei vostri sistemi di archiviazione, i fornitori, ovvero i produttori, o magari la topologia — ad esempio, se state valutando di passare da una classica SAN a tre livelli a un sistema iperconvergente. Mettete quindi tutto questo nel contesto del modo in cui attualmente gestite la continuità operativa e il disaster recovery, e considerate anche in che modo le condizioni meteorologiche potrebbero influenzare le vostre scelte.

Il tempo, in particolare, è cambiato con una certa regolarità, sorprendendo molti di noi. Credo che persino i meteorologi stiano un po’ scuotendo la testa di fronte a ciò che sta accadendo qui. Ma è assolutamente vero — a prescindere da quali si ritengano siano le cause — che l’intensità e la frequenza di questi cambiamenti meteorologici sono diventate molto più marcate.

E zone in cui, un tempo, si sarebbe pensato: «Wow, da queste parti non si vedono mai tempeste così strane né fenomeni così insoliti», vengono improvvisamente colpite da gravi danni: uragani, inondazioni, tornado e altri disastri naturali.

Questo, quindi, porta la questione in primo piano ed è proprio una di quelle cose; ma, a parte questo — davvero, a parte le cause di forza maggiore e tutto il resto di cui ci occupiamo — vorrei concentrarmi su questioni più banali e più legate alle nostre azioni, che dovreste prendere in considerazione.

Ora, immagino che alcuni di voi stiano già cercando nuove attrezzature. Mi avete spinto a rinnovare l’hardware dei vostri server e dei vostri sistemi di archiviazione e, mentre valutate le possibilità disponibili sul mercato, alcune cose attirano la vostra attenzione. La chiamano la “sindrome dell’oggetto luccicante”.

È proprio quando si valuta quanto possa essere allettante una funzionalità completamente nuova. Ora, quello che vorrei fare è riflettere su questo aspetto dal punto di vista di: se si apportasse quel cambiamento, se si introducesse quella nuova attrezzatura, in che modo influirebbe sul modo in cui affrontate la continuità operativa e quali difficoltà, in particolare, vi causerebbe tale transizione?

Questi sono proprio gli aspetti su cui vogliamo soffermarci, soprattutto se, tra un anno, guarderete indietro con un po’ di distacco, rifletterete su ciò che avete fatto e vi chiederete: «Wow, ho preso delle buone decisioni?». Avete preso delle buone decisioni in quel momento o avete agito con scarsa lungimiranza? Ed è proprio a questo che vogliamo prepararvi, affinché possiate anticipare alcune di queste situazioni e possiate davvero sentirvi soddisfatti di quelle decisioni tra un anno.

Ma perché dovrebbe interessarci? Perché tendono a essere molto dirompenti. Alcune delle misure lungimiranti e di modernizzazione che potreste adottare potrebbero avere conseguenze nascoste, e tali conseguenze tendono ad avere molto a che fare con il modo in cui attualmente replicate i dati verso il sito di disaster recovery. Forse anche con il modo in cui create snapshots i vostri backup e con la procedura di failover da una sede all’altra.

Quindi, in questa immagine, quello che stiamo mostrando è il data center primario che utilizza una qualche forma di, diciamo, replica sincrona verso il sito di DR. Considerando l’approccio attuale, in che modo la situazione cambierebbe se si sostituisse parte dell’apparecchiatura che gestisce tale replica? E in che modo ciò modificherebbe la procedura di fallback e di ripristino del lato primario?

Poiché si tratta di procedure consolidate nei vostri piani BCDR, queste possono essere notevolmente compromesse da qualsiasi scelta prendiate in futuro. Quindi, in realtà, ciò che vogliamo fare è evitare che vi troviate in una situazione in cui vi ritroviate a dire: “Caspita, non me l’aspettavo. Avevo preso una decisione di getto che sembrava isolata e in quel momento mi era sembrata la scelta giusta, ma non avevo considerato quali sarebbero state le conseguenze a lungo termine». Vogliamo quindi mettervi nelle condizioni giuste per affrontare la questione e far sì che tutto sia ben chiaro.

Allora, per il nostro primo sondaggio, vorrei semplicemente farmi un’idea di massima. Quanti strumenti diversi utilizza attualmente la vostra organizzazione per proteggere i dati critici in un sito di ripristino di emergenza?

Questo ci darà un'idea della situazione: se avete, magari, nemmeno un sito di disaster recovery, oppure ne avete uno o due, solo un paio, oppure ne avete una manciata, al fine di disporre di una copia aggiuntiva dei vostri dati critici in un altro luogo, da cui poterli recuperare qualora dovesse succedere qualcosa al data center primario.

Allora, vediamo i voti che stanno arrivando. La prima cosa che noto è che c’è un… sta appena iniziando a salire. Aspettate un attimo. Più tardi farò un secondo sondaggio, anch’esso collegato a questo, che mi aiuterà a inquadrare il rest conversazione, così saprò in che direzione indirizzarla.

Quindi, al momento stiamo constatando che circa un terzo di voi non dispone nemmeno di un sito di ripristino di emergenza (DR). Wow, questo di per sé è un po’ sorprendente, ma dovete capire che, dal punto di vista del budget, al momento potrebbe essere fuori dalla vostra portata. Speriamo quindi di potervi fornire alcuni spunti su come affrontare la questione.

Circa un altro terzo di voi dichiara di utilizzare un solo strumento. Circa il 28% indica di utilizzare uno strumento. Attualmente, circa il 14% dichiara di utilizzare due strumenti e, sorprendentemente, un quarto di voi ne utilizza diversi.

Quindi, tutto questo significa che hai un bel da fare nel cercare di capire quali siano — e come coordinare — questi diversi elementi del tuo piano di ripristino di emergenza, dato che, in pratica, potrebbero essere isolati gli uni dagli altri. Ma c’è una buona soluzione che può aiutarti in questo.

Allora, andiamo avanti. La prima cosa che voglio sottolineare a questo proposito è che, forse, per alcuni di voi il motivo per cui operate in questo modo è che state utilizzando funzionalità integrate, ad esempio, nella vostra SAN, ovvero nell’array di rete di archiviazione. Quel dispositivo, quel controller di archiviazione intelligente, vi fornisce parte della protezione dei dati e dei servizi di replica.

Quindi, se alcuni di voi hanno risposto “due” o “più”, il motivo per cui potreste averlo fatto è che forse avevate due modelli di archiviazione nella vostra SAN. E ciascuno di essi utilizza una tecnica di replica diversa. In definitiva, entrambi cercano di copiare i dati sul sito di DR, ma potrebbero utilizzare protocolli diversi o meccanismi proprietari specifici per farlo.

Questo, di per sé, crea alcune difficoltà. Il secondo aspetto è che, essendo presenti nell’array, quelle capacità sono isolate e non possono essere condivise. Pertanto, è necessario valutare in modo esplicito quali dati collocare in una posizione e quali nell’altra e, col passare del tempo, man mano che il valore di quei dati cambia, potrebbe essere necessario rivedere leggermente tali decisioni.

Quindi, tenendo presente questo, ciò che DataCore vi offrirà principalmente in questo caso è un modo per consolidare tali servizi di protezione dei dati. In questo modo si ottiene una certa uniformità. Anziché fare affidamento sulle funzionalità di un array specifico o di un dispositivo di storage specifico, ad esempio, eleviamo sostanzialmente il livello a cui tali funzioni vengono eseguite. In questo modo, qualsiasi sistema di storage che si integri nell’infrastruttura, sia quello attuale che quello futuro, beneficerà della stessa procedura operativa.

È possibile attuare una strategia di BCDR a livello di infrastruttura senza doversi preoccupare di una marca o di un modello specifico. È proprio questo il punto su cui vogliamo soffermarci. E il modo in cui lo realizziamo è attraverso un insieme continuo di misure di protezione. Ovvero, un insieme di funzionalità che coprono l’intera gamma di strategie che userete per proteggere le informazioni.

Si va fino all’estremo, ovvero quando i dati critici richiedono RPO e RTO pari a zero, con mirroring sincrono. E tale mirroring sincrono può avvenire sia su scala locale, cioè a pochi a piedi di distanza l’una dall’altra, dove sono presenti due copie. Tuttavia, più probabilmente in questi contesti, si tratta piuttosto di cluster estesi e cluster metropolitani, e vi mostrerò alcune illustrazioni al riguardo. Una caratteristica correlata a questa funzionalità è la capacità di eseguire automaticamente il failover sull’altra copia, qualora si verificasse un problema con quella primaria.

Pertanto, questi sistemi funzionano in quella che viene definita una configurazione "active-active", per cui non si verifica mai alcuna interruzione nell'accesso ai dati, né alcuna perdita di dati nel caso in cui si verifichi un guasto totale di metà dell'infrastruttura di archiviazione.

Si accenna anche ad alcuni aspetti relativi alla resilienza a tre livelli, nel caso in cui si voglia andare un passo oltre. E poi c’è una seconda categoria che ho inserito in questo ambito, che riguarda i guasti a livello regionale: mi riferisco a un’intera area metropolitana che potrebbe essere colpita da terremoti, inondazioni e pericoli ancora più gravi.

Ed è qui che advanced site recovery in gioco misure come la replica asincrona e advanced site recovery , con cui si cerca di allontanare il più possibile la seconda copia e di poterla ripristinare tempestivamente. E poi ci sono alcuni... e, tra l’altro, in quel caso, si tratta fondamentalmente di alcuni compromessi. E tali compromessi riguardano la gestione di un’immagine più coerente in caso di crash, piuttosto che un RPO o un RTO pari a zero. Potrebbero esserci, potenzialmente, alcuni elementi da ripristinare e si verificherà un leggero intoppo nel funzionamento.

E poi ci sono altre funzionalità, come la protezione continua dei dati (CDP) e snapshots, che in pratica consentono di ottenere un punto nel tempo ben definito. Forse alcuni di voi non conoscono ancora la CDP. Si tratta di un modo per creare una sorta di DVR (registratore video digitale) di tutti i dati critici relativi alle operazioni di I/O, che è possibile rivedere a ritroso nel tempo.

Supponiamo, ad esempio, che siate stati colpiti da qualcosa come un ransomware. Potreste effettivamente tornare indietro nel tempo per quanto riguarda i vostri dati, arrivare direttamente al momento in cui si è verificato l’attacco e ripristinare lo stato precedente alla crittografia dei dati. In questo modo, potreste praticamente mandare al diavolo chi sta cercando di estorcervi un riscatto. Si tratta quindi di funzionalità interessanti da approfondire.

Ciò significa che io, o voi, possiamo mantenere lo stesso processo BCDR mentre si aggiorna l'attrezzatura. Sappiamo che l'aggiornamento dell'hardware e, in alcuni casi, del firmware e di tutto il resto, può comportare una situazione piuttosto instabile, nonostante tutte le migliori pratiche.

Quindi, in sostanza, quello che stiamo dicendo è che nel corso degli anni abbiamo sviluppato dei meccanismi che consentono di rimuovere le vecchie apparecchiature, sostituirle con quelle nuove — per quanto riguarda la configurazione dell’infrastruttura di archiviazione — e farlo dietro le quinte, durante una giornata lavorativa, nei normali orari di funzionamento, senza dover interrompere il servizio. E tutto questo è possibile anche se si sceglie un produttore diverso o un modello di prodotto diverso, che fosse incompatibile con quello precedente.

Quindi, la migrazione dei dati dal vecchio sistema a quello nuovo avviene in background, senza interruzioni. È possibile eseguire questa operazione con la frequenza richiesta dalla propria organizzazione, ma il punto è che le procedure operative rimangono invariate, anche se si sceglie un luogo diverso in cui archiviare i dati. Ecco, questa è proprio la conclusione di quell’animazione.

È vero anche questo, quindi… alcuni di noi pensano: «Beh, ok, ma io non gestisco SAN, o meglio… le SAN fanno parte, in un certo senso, di ciò che ho gestito finora, ma sto iniziando a considerare soluzioni come i sistemi iperconvergenti e mi chiedo: in che modo questo mi aiuterebbe in tal senso, nel passaggio a questa soluzione?»

Parte del fascino di ciò che sta facendo DataCore, ancora una volta, consiste nel fatto che, elevando il livello a cui vengono forniti questi servizi di protezione dei dati, la topologia non ha più importanza. Pertanto, in molti dei nostri clienti, si osserva che questi ultimi stanno compiendo i primi passi verso l’HCI utilizzando soluzioni iperconvergenti nel proprio sito di disaster recovery, o addirittura all’altra estremità dei propri cluster metropolitani. Da un lato, hanno quindi creato un ambiente con i classici array SAN esterni. Dall’altro, stanno replicando tali informazioni su una nuova infrastruttura, che comprende solo server di base con storage interno su cui è in esecuzione il software DataCore, e che funge anche da host per le macchine virtuali che effettueranno il failover.

Dal punto di vista visivo, dal punto di vista ottico, si tratta di un cambiamento davvero radicale, ma dal punto di vista operativo sembrano identici. Si applicano le stesse tecniche di failover e le stesse tecniche di ripristino, proprio come se avessimo sistemi simili su entrambe le estremità.

Ora, ci sono alcuni aspetti specifici da evitare. Li chiamerò qui “cose da non fare”, ma in sostanza il messaggio è: “Alla luce di ciò che sapete ora, dovreste evitare a tutti i costi di affidarvi a un array hardware per la protezione dei vostri dati”. Perché questo vi costringerà ad adottare determinati comportamenti che causeranno sconvolgimenti a valle.

Quindi, in pratica, si compromette: ogni volta che lo si fa, si compromette l’utilità e non è possibile superare il confine del “box”, e per confine del “box” intendo l’hardware fisico su cui gira il sistema. Inoltre, si tende ad accorciare prematuramente la vita utile di quell’apparecchiatura perché, quando viene installata una nuova apparecchiatura che non utilizza la stessa tecnica di replica, ci si ritrova sostanzialmente a dover fare una scelta o a ritrovarsi nella situazione di: “Oh, sto usando due o tre modi diversi per far funzionare il tutto”, e questo non è gestibile nel lungo periodo.

Il secondo errore da evitare è scegliere una strategia di DR specifica per la propria topologia. Quindi, o si dice: «Beh, faccio sempre così e mi aspetto di avere sempre una SAN alla base», oppure: «Mi aspetto che sia rigorosamente iperconvergente». Entrambe queste posizioni possono essere, come diciamo noi, altrettanto miopi. Non vi offrono l’opportunità di separare chiaramente il ruolo dello storage da quello di calcolo, e potreste risentire di tantissime variabili in termini di qualità del servizio. Quindi, liberarvi da questi vincoli è l’essenza del nostro messaggio.

Vorrei citare un ottimo esempio di un cliente che ha adottato questa strategia e lo ha fatto sin dall’inizio. Lo fa ormai da oltre nove anni: si tratta del Maimonides Medical Center. Si occupa dell’assistenza ai pazienti in condizioni critiche nell’area di New York e, ovviamente, non può permettersi alcun periodo di inattività, né programmato né imprevisto.

Quindi, quello che hanno fatto è stato attuare una trasformazione completa: a un certo punto, l’intero data center era situato in un’unica sede all’interno dell’ospedale. Successivamente, hanno suddiviso il data center in due siti attivi-attivi, uno presso l’ospedale principale e l’altro presso la struttura MIS, a pochi isolati di distanza.

E per tutto questo tempo hanno mantenuto due copie attive, con i dati conservati in due luoghi distinti, come abbiamo descritto, in modo che ogni volta che si verificava un intervento di manutenzione o si verificava un guasto in uno dei siti, gli altri subentrassero senza alcuna interruzione. Lo fanno ormai da quasi un decennio senza alcun tempo di inattività legato allo storage. A questo punto potrebbe essere già un decennio.

Si tratta di una configurazione di dimensioni considerevoli, pari a un petabyte. Esiste un’ampia comunità di clinici, personale medico e dottori che fa affidamento su questo sistema e utilizza una vasta gamma di applicazioni. E, in sostanza, affermano che questo è il modo in cui gestiscono la loro attività. Alcuni esempi sono illustrati visivamente; credo che chi ha una maggiore familiarità con gli aspetti tecnici, in particolare con le reti, possa apprezzare la seconda immagine.

Questo progetto è destinato a un cliente che utilizza apparecchiature Dell di diverse generazioni. Nel sito principale, quello occidentale, utilizzavano Compellent, mentre nel cluster metropolitano utilizzano EqualLogic. Tuttavia, poiché normalmente questi due sistemi non sono in grado di comunicare tra loro — infatti, non lo fanno — nessuno dei due dispone delle stesse funzionalità. Quindi, ciò che fa DataCore è razionalizzare l’utilizzo di queste risorse e standardizzare gli strumenti utilizzati per eseguire le copie tra di esse, indipendentemente dalla piattaforma sottostante.

Hanno semplicemente fatto quella scelta e, quando si presenterà il prossimo 3par – ovvero quando entrerà in gioco qualcos’altro che vorranno integrare qui – sia che decidano di passare a HP o di rimanere nella famiglia Dell, quelle saranno scelte che potranno fare in qualsiasi momento, perché non sono rilevanti ai fini della loro procedura. Si tratta semplicemente del luogo in cui i dati vengono archiviati alla fine della giornata e da cui vengono recuperati.

Questo vi offre anche un quadro un po’ più chiaro di alcuni dei percorsi ridondanti che dovreste adottare. Quindi, se siete preoccupati per l’esistenza di un singolo punto di guasto, dovete pianificare con cura una parte della struttura del cablaggio, in particolare per quanto riguarda i collegamenti tra i siti e quelli agli switch. E questo fa parte delle migliori pratiche che i nostri partner autorizzati possono offrirvi.

Ecco un’altra configurazione. Anche in questo caso si tratta del settore sanitario, dove tendono ad essere molto più attenti alla gestione dei dati in questo modo. In questo caso, l’ospedale, o centro medico, gestisce tre sedi. Quindi, le due sedi a Manhattan, sulla destra, sono i centri di elaborazione principali. E poi hanno la loro sede di riserva: questa si trova a Secaucus, nel New Jersey.

Quella è stata una scelta molto importante da parte loro, perché quando la supertempesta Sandy ha colpito questa zona, allagando l’area di Manhattan e causando anche ingenti interruzioni di corrente, oltre a tutto il resto che stava accadendo qui, quei siti sono stati in grado, come si vede a destra, di passare alla sede di Secaucus, situata su un terreno più elevato, che fortunatamente era rimasta all’asciutto.

Ora, per noi diportisti non è una cosa positiva, ma sicuramente per i data center è una situazione davvero vantaggiosa, che ha permesso loro di mantenere operativa l’attività. Ciò ha garantito il funzionamento dei loro servizi critici di gestione dei dati. Ovviamente, per farlo hanno dovuto riorganizzare un sacco di altre cose, ma dal punto di vista informatico erano ben protetti.

E una volta ripristinata la situazione in quelle strutture di Manhattan, potrebbero semplicemente premere un interruttore e, di fatto, tornare a quella configurazione. Quindi, in questo caso, le due strutture si affidano a un sito comune, stanno entrambe facendo la stessa cosa. Stanno effettuando sia il mirroring sincrono verso quel sito sia la loro relazione reciproca.

In alcuni casi — sempre più spesso, in effetti — mi rendo conto che serve una terza copia. E il motivo per cui serve questa terza copia è interessante. Ci sono due modi in cui ciò potrebbe verificarsi — e mi riferisco specificatamente a una terza copia vicina — che sia anche sincronizzata in modo speculare.

Quindi, in questo caso, ciò che si sta cercando di fare è garantire che, quando se ne perde uno — in questa immagine ho i nodi a ovest, quello centrale a est e la terza copia sul nodo a nord — alcuni si trovino in un ambiente campus, all’interno della stessa area metropolitana. Quando dobbiamo mettere fuori servizio uno di questi sistemi per un certo periodo di tempo — manutenzione preventiva, aggiornamento o altro — ciò che tende ad accadere, se si dispone solo di due di questi sistemi, a seconda di come sono stati dimensionati, è che se il sistema ovest si affidasse esclusivamente a quello est per subentrare, quest’ultimo potrebbe risultare un po’ lento se non fosse stato dimensionato in modo adeguato per gestire il carico in eccesso.

A quel punto, in pratica, ti ritrovi con questa singola unità che ti rende un po’ più vulnerabile, perché se quel nodo dovesse smettere di funzionare, nell’ambito di un guasto a catena, anche quello verrebbe a mancare. Quindi, per mantenere un ambiente ad alta disponibilità, anche quando uno di quei nodi viene messo fuori servizio, si ricorre a questa resilienza a tre vie.

E questo ti dà una sorta di tranquillità, del tipo: «Ehi, sì, posso accettarlo. Sono disposto a eseguire la manutenzione preventiva con maggiore frequenza, sapendo di poter sempre contare sul supporto degli altri due nodi, e so che i miei utenti non noteranno alcun problema: non subiremo alcun calo di prestazioni mentre effettuo il passaggio». È davvero un ottimo approccio per garantire che tutto funzioni come ci si aspetta.

Volevo anche condividere con voi alcune immagini che mostrano cosa succede dietro le quinte, dal punto di vista della console amministrativa. Ed è proprio questa la prospettiva che si ha quando si ha il controllo dell’intero sistema.

Da qui, coordiniamo il processo di replica in corso e siamo in grado di individuare quali sistemi potrebbero essere stati messi fuori servizio per manutenzione. Possiamo analizzare l’andamento delle prestazioni in modo indipendente dal dispositivo, dal fornitore e dalla topologia.

Abbiamo una visione a 360 gradi della nostra strategia di protezione dei dati, senza doverci occupare delle sfumature specifiche di nessuno di quei modelli o marchi. È proprio questo l’aspetto davvero importante della questione. L’abbiamo imparato una volta e continuiamo ad applicare la stessa tecnica in ogni situazione, anche quando le circostanze cambiano.

Il risultato finale è questo: man mano che sviluppate la vostra infrastruttura e iniziate ad abbandonare quelle che potevano essere strutture a compartimenti stagni con topologie diverse, per arrivare a un approccio uniforme che standardizzi tali pratiche di BCDR, nonostante la diversità degli elementi che compongono questi diversi compartimenti.

Quindi, al centro di questo schema, ciò su cui vorrei richiamare la vostra attenzione potrebbe essere, ad esempio, il vostro sistema di archiviazione, dove girano le vostre principali applicazioni di primo livello. Potrebbe utilizzare le classiche grandi SAN esterne che servono sia macchine bare-metal che macchine virtualizzate. E, sempre più spesso, ho notato anche l’utilizzo di container nell’ambito delle attività di sviluppo; si tratta in tutti i casi di client a tutti gli effetti che utilizzano lo spazio di archiviazione proveniente da quelle aree di archiviazione esterne.

In questo caso, DataCore funge da livello di livellamento, ovvero il livello di virtualizzazione dello storage, che raggruppa tali array di storage esterni e li presenta come una visione d’insieme del percorso.

Sul lato sinistro, potresti anche aver selezionato, ad esempio, una VDI (infrastruttura desktop virtuale), dove desideri verificare come si comportano questi cluster iperconvergenti. E, anche in quel caso, abbiamo comunque scelto di utilizzare lo stesso software DataCore per facilitare la gestione del nostro BCDR.

Lo stesso vale per il nostro storage secondario: ciò che vedete nel sito di DR, nell’ufficio remoto e nella filiale è una funzione software simile, o la stessa funzione software, ma con topologie leggermente diverse. E i ROBO, i ROBO assomigliano più a un cluster iperconvergente, mentre il sito di DR in questo caso doveva essere un po’ più potente. Sembra più un’infrastruttura convergente, in cui c’è ancora la separazione tra lo spazio esterno in cui gli utenti archiviano i dati e lo storage del provider sottostante, ma non ci affidiamo a grandi array per ottenere questo risultato.

In pratica, abbiamo già implementato l'archiviazione locale e messo in comune quelle risorse, ovvero i vassoi esterni, ma non abbiamo più bisogno di controller intelligenti in quel contesto perché quella funzione è stata assorbita dalle funzionalità di DataCore, come vi mostrerò più avanti in un grafico.

In sostanza, quindi, ciò che stiamo dicendo è che il software offre la possibilità di scegliere l’indipendenza dalla topologia, con diverse modalità di implementazione che possono cambiare nel tempo. Si potrebbe iniziare dalla parte sinistra di questo schema, dove si raggruppano e si virtualizzano gli array di storage, per poi ridimensionare il sistema man mano che tali array vengono dismessi o giunge al termine la loro vita utile. Li sostituite semplicemente con lo storage interno a questi server, server x86, che fungono da controller di storage.

E poi, nella terza fase della transizione, potrete effettivamente trasferire le macchine virtuali e i carichi di lavoro direttamente su quegli stessi server. A quel punto potrebbe essere necessario potenziarli, ma potrete sicuramente passare in modo fluido da sinistra a destra, con l’obiettivo di ridurre la complessità della vostra infrastruttura, pur mantenendo lo stesso insieme di procedure.

E poi magari più avanti potresti ripensarci e dire: «Caspita, non è stata una gran bella idea. In realtà volevo separare il mio host dallo spazio di archiviazione e creare una sorta di soluzione ibrida».

Per offrire il software che lo renda possibile, disponiamo essenzialmente di tre edizioni. C'è la classe enterprise, la versione all-inclusive con il set di funzionalità più completo, poi abbiamo una sorta di versione di fascia media, l'edizione ST, nonché un'edizione pensata per le grandi opportunità di storage secondario che avete nella comunità adiacente, grandi file server e simili, dove non vorrete spendere lo stesso prezzo per terabyte che spendereste per i vostri carichi di lavoro più critici. Quindi, tutte queste licenze possono funzionare; sono tutte licenze software che si eseguono su un server x86 e possono essere utilizzate in qualsiasi di queste topologie.

Ecco una panoramica più ampia della struttura. Finora, in questa conversazione, ci siamo concentrati sulla parte relativa ai servizi di protezione dei dati. Aspetti quali il mirroring sincrono, la replica, snapshots il CDP, ma esistono numerosi altri servizi che ci si aspetterebbe e di cui si avrebbe bisogno da un’infrastruttura di storage, sia che riguardino il provisioning, sia che riguardino la creazione di grafici e gli avvisi, o ancora la comprensione, dal punto di vista analitico, di quali siano i futuri requisiti di capacità e, eventualmente, gli adeguamenti alla qualità del servizio.

Quindi, tutti questi elementi costituiscono una parte intrinseca di ciò che offre lo stack software, e non importa in che modo ci si colleghi. Che si utilizzi fibre channel iSCSI qualsiasi altro protocollo di storage sul back-end. Potrebbe trattarsi NVMe esigenze di velocità elevata e bassa latenza, e si collegheranno alcune di quelleflash NVMe direttamente a questi server DataCore. Oppure potreste utilizzare dischi collegati direttamente o persino avere parte di quella capacità ospitata nel cloud. Ciò che conta non è la vostra scelta, ma il fatto che state semplicemente assegnando a quei diversi nodi responsabilità specifiche in base ai carichi di lavoro che vi aspettate da loro.

Detto questo, vorrei lanciare un secondo sondaggio. Ora che avete un quadro più chiaro di ciò a cui stiamo mirando, mi piacerebbe molto capire quale delle seguenti modifiche, se doveste esprimere un giudizio in questo momento, alla vostra infrastruttura di archiviazione dei dati avrebbe un impatto maggiore sulla vostra strategia di BCDR.

Se vi venisse detto all’improvviso (A) che, nei prossimi sei mesi, abbiamo deciso — siamo convinti — di spostare la nostra sede di DR sul cloud. In alcuni casi, per chi di voi non disponeva di una sede di DR, ne creeremo una sul cloud: che impatto avrebbe su di voi?

Oppure forse state pensando di aggiungere un flash alla vostra SAN esistente. Valutate se le tecniche che state utilizzando per la replica cambierebbero in modo significativo a seguito di tale scelta. Non intendo a livello concettuale, ma nella pratica. Come cambierebbe il vostro piano BCDR? E se doveste passare improvvisamente a un sistema iperconvergente, magari affiancandolo al vostro storage attuale, funzionerebbe in modo molto, molto diverso? Immagino di sì, quindi vorrei sentire la tua opinione in merito.

Allora, Carlos, non riesco a vedere i risultati del secondo sondaggio. Non so se tu riesci a vederli.

Carlos Nieves: Li vedo, Augie, e in questo momento circa il 68% degli elettori ha scelto l’opzione “Spostare la propria infrastruttura DR sul cloud”. Circa il 10% ha scelto “Aggiungere unflash alla propria SAN esistente”. Il rest ha scelto rest un sistema iperconvergente in aggiunta o in sostituzione dell’attuale sistema di storage”.

Augie Gonzalez: Ok, quindi quello che vorrei che faceste – una volta che avremo finito qui oggi – è che rifletteste un po’ per conto vostro: il fatto che io debba compiere questa mossa, quanto è rilevante? Quali ripercussioni ha sulle procedure, sulla formazione e sulle attività di audit che devo svolgere sul mio piano BCDR, e come posso evitare che questo si traduca in un cambiamento così catastrofico nel modo in cui gestisco le mie misure di sicurezza? A proposito, grazie per i vostri contributi.

DataCore è qui per aiutarvi. È qui per supportarvi su diversi fronti. Oggi, nell’ambito di questo webcast, ci concentriamo in particolare sulla continuità operativa e sul disaster recovery, ma in realtà ogni volta che state pensando di espandere o rinnovare il vostro sistema di storage, potrebbe essere un’ottima occasione per riconsiderare il vostro approccio alle tecniche di conservazione di copie di sicurezza in un’altra sede.

Siamo inoltre strettamente coinvolti in iniziative di consolidamento intraprese da diverse organizzazioni, che mirano a ridurre la varietà delle apparecchiature, a mettere in comune tali risorse e a gestirle in modo uniforme; possiamo quindi fornirvi assistenza in questo ambito, nonché a livello periferico, sia che gestiate uffici remoti o filiali integrati al data center principale, sia che cerchiate di creare un accordo reciproco tra i siti di ripristino di emergenza (DR), utilizzando il data center principale come sito di ripristino o le strutture ROBO.

Oppure, a livello di edge, è necessario inviare parte di quei dati in back-end. Si utilizzano le stesse tecniche, quindi possiamo fornirvi un valido supporto in questo ambito. Nello specifico, per voi come singoli individui, ci sono diverse responsabilità per le quali possiamo darvi una mano.

Quindi, se il vostro obiettivo è garantire la continuità operativa, possiamo aiutarvi a raggiungerlo anche man mano che l’hardware invecchia e viene sostituito da nuove apparecchiature. E credo che questa sia probabilmente la priorità assoluta; uno degli strumenti che offriamo a tal fine è la possibilità di migrare i dati in modo trasparente, così che, man mano che le apparecchiature vengono sostituite, possiamo effettuare il passaggio, dismettere quelle vecchie, trasferire le informazioni su quelle nuove e nessuno si accorgerà di ciò che è stato fatto.

Al punto che quell’attrezzatura è apparsa in un luogo diverso rispetto a quello previsto, non solo per quanto riguarda il fornitore e il modello, ma anche la sede è cambiata. E tutto questo senza incorrere in punti di guasto o interruzioni di servizio; pertanto, è possibile che lo scenario preveda effettivamente gravi interruzioni, ad esempio in un edificio del campus, ma i sistemi continuano chiaramente a funzionare.

Ci sono anche alcuni vantaggi collaterali, ovvero la possibilità di sfruttare la capacità di dispositivi che altrimenti potrebbero essere considerati isolati. Quindi, invece di dire: «Beh, ho questa “isola” di archiviazione e ho preso alcune decisioni esplicite su quali applicazioni utilizzarci», posso effettivamente raggruppare e aggregare le risorse a mia disposizione, per quanto diverse possano essere, e trattarle come un pool di risorse da cui attingere in base ai picchi e ai valori del mio consumo.

Infine, c'è la capacità di autenticare effettivamente gli utenti. Si stabilisce chi merita un servizio ad alta priorità, chi si cerca di impedire che diventi un utente non autorizzato e chi riceve un servizio di livello intermedio. Tutti questi aspetti fanno parte delle capacità di intelligence di cui stiamo parlando.

Se c’è una cosa che voglio farvi capire, è di non lasciare che queste dipendenze nascoste mettano a rischio il vostro piano di BCDR. Che si tratti della sede, della topologia o dei fornitori, tenetele d’occhio. Tenete d’occhio… capite, l’impatto che qualsiasi cambiamento in quel contesto potrebbe avere su di voi.

E, dal nostro punto di vista, alla luce delle valutazioni che abbiamo ricevuto dai nostri clienti. Alcuni di questi esempi – come, ad esempio, quello del Comune di Carmel – sono illustrati in un webcast davvero interessante. Utilizzano DataCore dal 2010. Quindi, quanti anni sono? Nove? Inoltre, non si sono verificati tempi di inattività durante tutto questo periodo, nonostante i vari cambiamenti che, ovviamente, si sono susseguiti nel corso degli anni.

Considerateci quindi come un fornitore indipendente di software in grado, come nessun altro, di preservare la vostra strategia BCDR ben strutturata, consentendovi al contempo di modernizzarla e di generare risparmi per l’organizzazione, poiché non sarete costretti a rinunciare a soluzioni che sono state improvvisamente smantellate e sostituite.

E, se voleste condividere rapidamente alcune di queste informazioni, ad esempio con alcuni dei vostri colleghi che potrebbero non essere disposti a seguire un webcast della durata di circa 45 minuti, date loro un'occhiata veloce a questi indicatori.

Lì troverete diverse risorse, ma ci sono anche alcuni video di circa due minuti che vi daranno un’idea precisa di ciò di cui stiamo parlando e illustreranno cosa intendiamo per “dipendenze a cascata”, quindi vi consiglio vivamente di guardarli.

E con questo, penso che ora vorremmo passare in rassegna le nostre domande, per vedere cosa abbiamo qui. E lascia che sia io a esaminarle, Carlose, scusami.

Allora, la prima domanda è: «Funziona bene con Office 365?». È una domanda interessante. Office 365 è un software in cloud, quindi c’è già un’infrastruttura dietro le quinte che se ne occupa.

In quel caso dovresti affidarti al fornitore SaaS e, in generale, la situazione sfuggirebbe al tuo controllo se utilizzassi la versione in hosting. Se invece utilizzassi Office in locale su server locali, allora sì, sarebbe sicuramente d’aiuto.

Questa è la seconda domanda, ovvero: «Ci sono requisiti di archiviazione particolari per utilizzare il vostro software?». L’ho interpretata come: «Ci sono aspetti di compatibilità particolari di cui dobbiamo tenere conto e che potrebbero impedirci di farlo?». E no, il software è fondamentalmente progettato per comunicare con dispositivi di archiviazione standard utilizzando i protocolli più diffusi, che si tratti di SAS, SATA o NVMe. Li supporta tutti in modo nativo: la maggior parte di essi si basa fondamentalmente sul protocollo SCSI utilizzato per la trasmissione dei dati.

Consideriamo l’host, lo spazio di archiviazione e il modo tradizionale in cui avviene la connessione. È completamente compatibile, quindi non dobbiamo soddisfare requisiti particolari per farlo.

C'è un'altra domanda qui: «Come viene determinato il prezzo del software?». Ho già accennato un po' alla risposta. Dipende fondamentalmente dalla capacità: quanto spazio è gestito da DataCore. Quanta è la capacità utilizzabile a cui possiamo attingere e, in base a questo, applichiamo un prezzo per terabyte.

Maggiore è il volume che ci affidate, minore sarà il prezzo per terabyte; inoltre, le tre edizioni che vi ho mostrato prima, EN, ST e LS, definiscono semplicemente un insieme di funzionalità. In alcuni casi sono tutte integrate, mentre in altri si tratta di un set di funzionalità più personalizzato, adatto alla fascia media e ai casi in cui le prestazioni non sono un fattore determinante: è la versione LS. Questo è tutto.

Non vedo altre domande. Abbiamo ancora un paio di minuti a disposizione, se volete, dopodiché passerò la parola a Carlos.