RSD triplica le prestazioni di Veeam Backup e rende il sistema ERP incredibilmente veloce

Sander Puerto: Salve, buongiorno e buon pomeriggio a tutti, e grazie per essere qui con noi oggi. Mi chiamo Sander Puerto. Sono senior product marketing manager qui in DataCore e sarò il vostro moderatore per la giornata. Vi diamo il benvenuto a questo webcast, durante il quale scoprirete come RSD è riuscita a triplicare le prestazioni dei propri backup e a rendere il proprio sistema ERP incredibilmente veloce.

Prima di iniziare la nostra presentazione, parleremo brevemente di alcuni aspetti organizzativi. Diamo un’occhiata all’ordine del giorno. Bene, faremo le presentazioni. Parleremo del problema. Parleremo della soluzione, dell’esito e dei risultati che RSD è riuscita a ottenere. Poi, verso la fine, parleremo un po’ di cosa sia il software-defined storage e perché dovreste almeno valutarlo o prenderlo in considerazione, e vedremo quali sono i nostri prossimi eventi in programma. Inoltre, alla fine ci sarà una sessione aperta di domande e risposte, nel caso aveste ulteriori domande. Inoltre, vi informo che metteremo in palio una carta regalo Amazon del valore di 200 dollari. Sceglieremo il vincitore alla fine di questo webcast, quindi vi consiglio vivamente di rimanere con noi fino alla fine per scoprire se siete voi i vincitori.

Alla tavola rotonda di oggi partecipano Alan Kerr, senior solutions architect presso StablePath; Jim Barnes, direttore IT presso RSD; e, ovviamente, il sottoscritto. Un’altra cosa che volevo sottolineare è che, mentre procediamo con la discussione, tenete presente che qui c’è una sezione dedicata ai download, o agli allegati, da cui potete scaricare il caso di studio relativo a RSD e anche le slide del webinar che stiamo per esaminare.

Mentre esaminiamo le diapositive, sentitevi liberi di porre le vostre domande. Sia Jim che Alan saranno più che lieti di rispondere alle vostre domande relative alla loro specifica storia di successo. Inoltre, una volta terminato il webcast, riceverete un’e-mail da BrightTALK contenente un link on-demand che vi consentirà di guardare la registrazione, se lo desiderate. Ora passiamo rapidamente a chi è RSD. Per questo, vorrei dare la parola a Jim... Jim, ci sei?

Jim Barnes: Sono qui.

Sander: Jim, potresti dirci qualcosa in più su RSD?

Jim: Sì, mi chiamo Jim. Lavoro alla RSD da circa 17 anni. Siamo un grossista di prodotti per la refrigerazione e di impianti di climatizzazione (HVAC) presenti in oltre 10 stati e contiamo 79 sedi nei 10 stati occidentali, compreso l’Alaska. Questa azienda esiste da 112 anni: ha iniziato come fabbrica di pianoforti e negli anni ’30 è passata al settore della refrigerazione. Sì, ci stiamo espandendo, stiamo crescendo. Ci siamo espansi in Colorado solo un paio d’anni fa. Grazie alle tecnologie di cui disponiamo, siamo riusciti a espanderci in diversi mercati e cose del genere. Siamo un’azienda a conduzione familiare. Ripeto, credo che l’attuale proprietario appartenga alla quarta generazione. Sono lieto che siate qui ad ascoltare la nostra storia.

Sander: Certamente, grazie. Eccellente. È un bel cambiamento, passare dal settore dei pianoforti a quello della climatizzazione. È davvero impressionante. Eccellente. Passiamo ora la parola ad Alan Kerr, che ci parlerà più nel dettaglio di StablePath. Alan?

Alan Kerr: Sì, siamo un’azienda specializzata in ingegneria. Siamo esperti in infrastrutture resilienti e ad alte prestazioni. Il fondatore dell’azienda — un ex direttore IT — l’ha avviata intorno al 2000. Ci occupiamo di infrastrutture resilienti e ad alte prestazioni per aziende di tutte le dimensioni, ma in genere dedichiamo la maggior parte del nostro tempo alle medie imprese. La nostra sede centrale si trova in California, ma operiamo a livello nazionale per chiunque ne abbia bisogno. Ciò include aziende, enti governativi, organizzazioni di beneficenza e così via.

Sander: Ottimo. Quindi la vostra sede principale si trova in California. Avete altre sedi distaccate?

Alan: No, fondamentalmente perché gli ingegneri sono sempre in movimento. Anche se la sede è in California, lavorano sempre presso le sedi dei clienti. Che possono trovarsi in qualsiasi parte del Paese. Quindi non abbiamo sedi centrali fisse da nessuna parte.

Sander: Ottimo. Grazie mille, Alan. Ora che sappiamo esattamente chi sono i nostri relatori di oggi, passeremo subito alla storia di come tutto questo sia nato, di come siano riusciti a individuare la soluzione più adatta alla loro situazione specifica e di quali benefici concreti abbiano ottenuto nel momento stesso in cui hanno implementato questa soluzione nel loro ambiente.

Per cominciare, il problema, per come l’ho capito, era triplice, giusto? C’era un problema di prestazioni insufficienti per il progetto imminente. Avevate anche bisogno di un certo livello di flessibilità per poterlo realizzare. Allo stesso tempo, il vostro sistema ERP richiedeva ridondanza. Jim, potresti dirci qualcosa di più al riguardo, dato che sei stato coinvolto nella ricerca delle soluzioni a questi problemi? Raccontaci un po’ di più su ciò che è successo in quel periodo.

Jim: Sì, circa 8 o 9 anni fa, volevamo davvero entrare nel mondo virtuale. Per come era configurato il nostro sistema di archiviazione, avevamo un Compellent. Avevamo un sistema EMC e all’epoca utilizzavamo lo storage EqualLogic. Il Compellent era la soluzione di storage aziendale che utilizzavamo per il nostro sistema ERP e per Exchange. Quello storage, per quanto limitato, ci permetteva di far funzionare il nostro sistema ERP e Exchange, ma per espanderci e iniziare a gestire un ambiente virtuale, avevamo davvero bisogno di aumentare la capacità di storage a nostra disposizione.

Abbiamo scoperto che gran parte del nostro storage di base era gestito dall’EqualLogic, che è davvero lento. Alcuni degli altri problemi che abbiamo riscontrato riguardavano i Compellent: c’erano due controller, ma solo un unico storage nel backend. Quindi, se quello storage si bloccava o se… abbiamo persino avuto situazioni in cui il guasto di uno dei controller ne bloccava l’altro. Di fatto, a volte questo metteva fuori servizio il nostro storage di primo livello.

Abbiamo quindi iniziato a cercare una soluzione che ci garantisse la velocità di cui avevamo bisogno, il volume di storage necessario per il nostro ambiente ESX e anche la ridondanza che desideravamo, in modo che un eventuale guasto su un singolo dispositivo di storage non compromettesse affatto la produzione. A quel punto Alan è venuto a presentarci l’offerta di DataCore. Ci è voluto un po’ di tempo per renderci conto di cosa si trattasse e comprenderne appieno il funzionamento, ma una volta avviata la migrazione, la transizione è stata molto semplice. Ci ha offerto un’enorme flessibilità. Siamo così riusciti ad avere due appliance di storage separate in configurazione mirror. Potremmo effettivamente perdere un’appliance DataCore e il sistema continuerebbe comunque a funzionare senza interruzioni.

L’altra cosa che ci ha permesso di fare è stata passare al mondo ESX e archiviare le macchine virtuali (VM) sullo storage. Il server ESX si collegava infatti tramite fibra a entrambi gli appliance, a entrambi gli array di storage, e nell’ambiente ESX risultava comunque come un unico appliance. Quindi non importava se spegnevamo un appliance. L’altro avrebbe automaticamente, senza alcun intoppo, continuato a funzionare, mantenendo operativo il nostro ambiente. Questo ci ha garantito una grande flessibilità, ad esempio per eseguire gli aggiornamenti sui server DataCore.

Ci ha inoltre permesso di collegare qualsiasi tipo di storage sul backend e di renderlo disponibile, dato che si tratta semplicemente di un’appliance basata su applicazione. È infatti possibile assegnarle qualsiasi tipo di storage e lei lo gestirà allo stesso modo. Grazie alla cache e a tutte le altre funzionalità gestite dal server DataCore, ha anche accelerato lo storage più lento. All’epoca utilizzavamo dischi rotanti, e la soluzione gestiva una cache che li faceva sembrare molto più veloci di quanto fossero in realtà.

Alan: Volevo aggiungere qualcosa a questo proposito. Ho lavorato con il predecessore di Jim all’implementazione iniziale di DataCore, e loro provenivano da un sistema EMC — avevano utilizzato EMC per un po’ di tempo. Diciamo solo che, in linea di massima, non è stata un’esperienza positiva. Ogni volta che c’era un problema, avevano support . Avevano problemi di disponibilità. C’erano numerosi problemi al riguardo.

All’epoca, quando furono introdotti i primi nodi DataCore, lo storage era molto frammentato. Alcuni dati erano su EMC, altri su Compellent, altri ancora su EqualLogic. Non solo bisognava gestire tre diversi set di dati, ma la possibilità di spostare i dati tra queste diverse piattaforme di storage era praticamente inesistente. In pratica, spegnevano il sistema e copiavano tutto. Questo comportava di per sé tempi di inattività quando, ad esempio, si decideva di spostare i dati da EMC a Compellent. Questo era l’altro motivo, ovvero l’altro problema che stavano cercando di risolvere: come uscire da un modello a silos in cui lo storage e le interfacce erano sparsi ovunque?

Sander: Sì, ottimo. Forniremo al nostro pubblico qualche dettaglio in più su questa storia. Inoltre, per quanto riguarda il progetto in quel momento, stavate cercando di abbandonare i server ciclici per realizzare, in sostanza, qualcosa di più compatto e trasferirlo sugli hypervisor, giusto? Quindi, quei tre diversi silos di archiviazione non rappresentavano le opzioni più ottimali per ciò che stavate cercando di fare. È corretto?

Jim: Sì. La quantità di spazio di archiviazione necessaria per gestire un ambiente virtuale è molto superiore a quella che potremmo permetterci su una soluzione come Compellent, perché si aggiunge… si riusciva a utilizzare molto meno. Con DataCore, è possibile utilizzare uno storage meno costoso pur mantenendo la ridondanza e assicurandosi la quantità di spazio di archiviazione necessaria per gestire un ambiente virtuale. Quando si gestiscono 100 server, lo spazio di archiviazione richiesto è notevole. Con Compellent, il costo associato a tale quantità avrebbe superato di gran lunga quanto l’azienda avrebbe voluto spendere.

Sander: A quel tempo, avevate già implementato i backup con Veeam?

Jim: No, quello è successo molto più tardi. È successo dopo che ci siamo trasferiti a… dopo che abbiamo virtualizzato il nostro ambiente.

Sander: Passiamo ora alla parte relativa alla soluzione, dove so che Alan è stato coinvolto in quelle discussioni. Allora, Alan, raccontaci qualcosa in più su come vedevi la situazione quando sono venuti da te e ti hanno detto: “Questo è ciò che stiamo cercando di fare e questo è ciò che vogliamo ottenere con un budget di X”. Qual è stato il tuo ragionamento in quel momento?

Alan: Probabilmente è stato il contrario. Li ho visti in difficoltà e ho fatto notare che non doveva per forza andare così. Col tempo... voglio dire, all’inizio c’era... ad essere onesti, c’era scetticismo perché EMC è un nome importante. Compellent è una realtà consolidata. È un marchio. DataCore all’epoca non era come quelle aziende. Abbiamo adottato un approccio del tipo “la prova sta nei fatti”, partendo in piccolo. Credo fossero circa 8 terabyte in mirroring.

All’inizio abbiamo realizzato una piccola versione iniziale. Ha avuto un successo tale che abbiamo trasferito il sistema ERP di produzione su quella piattaforma, ma non ne avevamo parlato al capo. Il sistema funzionava già su quella piattaforma e alla fine lui è entrato e ha detto: «Ok, va bene, sembra tutto a posto». Possiamo passare al sistema ERP». E noi gli abbiamo fatto notare – in realtà siamo stati io e Jim a effettuare il trasferimento – «Oh, in realtà sta già funzionando su quella piattaforma da un giorno o due». Lui ha semplicemente detto «Bene» e se n’è andato.

Quindi si è trattato semplicemente di analizzare le loro esperienze quotidiane, parlare con alcuni dei loro amministratori e capire quali problemi stavano affrontando in termini di disponibilità, support e prestazioni, per poi mettere a punto, diciamo, un pacchetto di dimensioni contenute con cui iniziare. Da lì in poi il tutto si è semplicemente evoluto fino a diventare il modo in cui RSD gestirà lo storage d’ora in poi.

Sander: Per quanto riguarda l'hardware, cosa hai deciso di utilizzare all'epoca?

Alan: L’installazione iniziale prevedeva server Hewlett-Packard con array MSA sul back-end. Tutto era… gli array MSA non avevano alcun controller. In pratica erano sistemi di archiviazione di tipo JBOD. Questo era nella fase iniziale. È rimasto in funzione per quanto, sette anni? Quindi il sistema iniziale è rimasto in funzione probabilmente per 7 anni. Non abbiamo avuto alcuna interruzione in quel periodo. Poi, nell’ultimo anno e mezzo circa, forse…

Jim: Sì, circa un anno fa.

Alan: Sì, probabilmente circa un anno fa siamo poi passati a un Lenovo per i server e a un sistema di archiviazione Violin sul back-end, che è un vecchio flash .

Sander: Quindi stai dicendo che l'HP è durato così a lungo?

Alan: In realtà è ancora in produzione.

Sander: Wow, questa sì che è affidabilità.

Jim: Sì, abbiamo trasferito l’ambiente di produzione che utilizzavamo quando siamo passati all’hardware su… quindi, facciamo un piccolo passo indietro, perché abbiamo… abbiamo parlato di ciò che abbiamo qui nel nostro ambiente di produzione, ma anche a Peoria, in Arizona, abbiamo due server DataCore, e replichiamo tutti i nostri dati da qui a Peoria. E in effetti lo fa in tempo reale.

Man mano che si scrive un’e-mail o si redige una fattura, i dati vengono immediatamente trasferiti al nostro sito di disaster recovery. In realtà ne abbiamo due lì che si replicano a vicenda. Quindi ne abbiamo due qui in produzione che si replicano a vicenda, e ne abbiamo due a Peoria che si replicano a vicenda. Abbiamo semplicemente utilizzato l’hardware che usavamo in produzione e lo abbiamo trasferito lì, e funziona alla grande.

Alan: Allora, l’installazione iniziale prevedeva 2 nodi sul lato di produzione, ovvero i nodi HP a cui abbiamo appena fatto riferimento. Sul lato remoto c’erano vecchie apparecchiature Dell che erano state messe fuori servizio sul lato di produzione e trasferite lì. Abbiamo quindi constatato che, se avessimo effettuato aggiornamenti o operazioni simili sul lato remoto, ovviamente il disaster recovery si sarebbe interrotto in tali scenari. Pertanto, quando abbiamo posizionato i nodi sul lato di produzione, abbiamo deciso di prendere quell’hardware che ovviamente stava ancora gestendo tutto, fino al momento in cui lo abbiamo sostituito, e di collocarlo sul lato del ripristino di emergenza. Così ora, quando effettuiamo aggiornamenti su entrambi i lati, non interrompiamo effettivamente il funzionamento dell’ambiente. L’ambiente rimane attivo 24 ore su 24, 7 giorni su 7, indipendentemente dal fatto che stiamo effettuando manutenzione o altro, praticamente.

Jim: L’altra cosa che, secondo me, ha semplificato la mia vita come amministratore di questo sistema è che possiamo… beh, proprio come qualsiasi software, proprio come qualsiasi tipo di server, i server devono essere aggiornati. Questi funzionano su Windows, quindi utilizziamo Windows Server 2016 su cui gira DataCore. Dobbiamo eseguire gli aggiornamenti di Windows, come tutti sappiamo. Dobbiamo eseguire gli aggiornamenti di DataCore. Possiamo effettuare questi aggiornamenti, e in effetti li eseguiamo durante il giorno. Mettiamo uno dei server fuori linea, arrestiamo il servizio DataCore, e l’ambiente del server non se ne accorge minimamente. L’ambiente ESX non se ne accorge minimamente. Il nostro sistema ERP… nessuno si accorge nemmeno che mettiamo uno di questi nodi fuori linea quando lo facciamo. Lo facciamo durante il giorno: eseguiamo l’aggiornamento di Windows, quello di DataCore e poi li rimettiamo in funzione. La sincronizzazione viene ripristinata e tutto torna a funzionare come se nulla fosse successo. Questo limita davvero anche il tempo che il personale deve trascorrere in sede dopo l’orario di lavoro e gli orari di lavoro prolungati. Quindi questo è un altro vantaggio concreto per il mio personale: non dobbiamo lavorare così tante notti fino a tardi.

Sander: È una cosa positiva, no? Un enorme vantaggio.

Alan: Insomma, stiamo per raggiungere i 9 anni di operatività ininterrotta del nostro sistema di archiviazione di produzione.

Jim: Sì, da quando abbiamo questi array di storage… non ho mai subito perdite… o meglio, i due nodi non sono mai stati fuori servizio contemporaneamente. Quindi, in ogni momento, lo storage è sempre disponibile.

Sander: Ottimo. Quindi al momento avete 2 copie in produzione e altre 2 nel DR. È corretto? Quindi avete 4 copie dei vostri dati?

Jim: Esatto.

Sander: Oltre ai backup?

Jim: Sì, e poi utilizziamo anche Veeam per eseguire il backup su disco e poi trasferire i dati dal disco al nastro.

Alan: Allora abbiamo dati continui.

Jim: E poi abbiamo la protezione continua dei dati, che gira su DataCore. La protezione continua dei dati consente, in mancanza di un termine migliore, di effettuare dei rollback. Offre un intervallo di tempo — quindi, dipende da quanto spazio di archiviazione si dedica a questa funzione. Consente di avere da un giorno a cinque giorni, o qualunque durata si imposti, durante i quali è possibile selezionare una linea temporale, tornare indietro nel tempo e creare un snapshot e una copia di quel volume a partire da quel momento specifico e ripristinarli da lì. Ad esempio, se un ransomware crittografa i dati, è possibile tornare indietro a prima dell’attacco e i dati saranno nuovamente disponibili.

Alan: Così non finisci come Baltimora.

Sander: Ottimo. Ho qui una domanda dal pubblico. La domanda è: «A che distanza si trova il vostro sito di DR dalla vostra infrastruttura di produzione?»

Jim: Sono circa 350-400 miglia. Si tratta del tragitto da Peoria, in Arizona, a Lake Forest.

Sander: Che tipo di connessione avete tra le due sedi?

Jim: Al momento utilizziamo un circuito MPLS da 50 meg e riutilizziamo gli Steelhead di Riverbed per la deduplicazione.

Alan: E stiamo pensando di cambiare anche questo.

Jim: Sì, in effetti mi sto preparando a valutare un approccio diverso per farlo. Stiamo valutando la possibilità di realizzare una connessione di livello 2 tra le sedi, portandola a 200 MB, e poi installare un Riverbed Steelhead più potente per ottenere una maggiore larghezza di banda.

Alan: Questo ci consentirà, in futuro, di far funzionare le macchine virtuali su entrambe le piattaforme in qualsiasi momento, a nostra discrezione.

Jim: Sì, in effetti potremmo ancora avere dei sistemi di produzione in funzione nel nostro sito di ripristino di emergenza. Quindi questo ci offre quella vera—

Sander: Quindi ora si tratta di un ambiente multisito ad alta disponibilità.

Alan: Sì, è proprio questa la direzione verso cui si sta andando; l'idea è che non abbia importanza su quale piattaforma sia in esecuzione una macchina virtuale.

Sander: Ottimo. Un’altra cosa: per quanto riguarda il tipo di larghezza di banda di cui disponete e le variazioni dei dati che si verificano quotidianamente affinché la replica possa avvenire, come sta andando?

Jim: Sì, come ho detto, in realtà avviene in tempo reale. In DataCore c’è infatti un piccolo indicatore che mostra: “ok, ti sta inviando questa quantità di dati” e “questo è il ritardo che hai”. Di solito il ritardo non supera mai i 2 o 3 secondi. L'unico momento in cui si verifica è quando si avvia una nuova replica, oppure, ad esempio, quando si spegne un nodo per effettuare degli aggiornamenti: noterai che potrai osservare la velocità con cui si sta replicando nuovamente e la quantità di dati coinvolti. È in quei momenti che lo noterai, ma normalmente puoi controllare lì e non c'è mai alcun ritardo.

Alan: Ne abbiamo parlato proprio stamattina, mentre stavamo valutando la possibilità di realizzare la connessione di livello 2 e cercando di stabilire quanta larghezza di banda stiamo utilizzando. La quantità di... voglio dire, nelle ultime 4 settimane, la quantità di dati che lo storage ha inviato, o ha tentato di inviare, attraverso la linea da 50 megabit è stata di poco superiore ai 20 terabyte. Grazie agli appliance di deduplicazione e ad alcune modifiche apportate a DataCore per renderlo più suscettibile alla deduplicazione, abbiamo risparmiato circa 18,5 terabyte sulla linea. Quindi abbiamo inviato solo 1,4 terabyte nelle ultime quattro settimane. Grazie al rapporto di deduplicazione che stiamo ottenendo e all’efficienza con cui DataCore rende possibile la deduplicazione, è questo che ci dà quella sensazione di tempo reale sul... sapete, ecco perché non c’è mai alcun ritardo su nessuno dei volumi.

Sander: Ho un’altra domanda da porvi, sempre in relazione a questo stesso argomento. Notiamo una notevole ridondanza tra l’alta disponibilità in loco, le soluzioni di DR, il CDP e i backup snelli. Quindi, Jim, forse potresti spiegarci perché è così fondamentale per la tua azienda, per la tua organizzazione, disporre di più copie dei dati. In che modo ciò va a vantaggio del tuo modello di business?

Jim: Quello che sappiamo è che ci sono molti modi diversi in cui i tuoi dati possono smettere di funzionare. Non esiste un'unica soluzione per il backup e il ripristino. Ci sono molte opzioni diverse. Come ho detto, se si viene colpiti da un ransomware, sarà opportuno utilizzare il CDP per ripristinare lo stato precedente. Se invece si verifica un danneggiamento dei dati, si potrebbe optare per il backup Veeam per il ripristino, a meno che i dati non siano sensibili al fattore tempo.

L’altra cosa è che, in caso di vero e proprio disastro, i dati che avete qui nella sede centrale andranno… dobbiamo presumere che andranno persi. E per alcune cose potreste dover risalire fino ai nastri. Se state pensando all’archiviazione, dovete gestire dati finanziari o simili, per cui è necessario recuperare qualcosa di 7 anni fa che non state conservando in nessun altro modo. Bisogna ricorrere ai nastri. Quindi è importante avere quello che io chiamo il “modello a tre livelli”. Credo che lo si utilizzi per... si vuole avere la copia originale. Si vuole averla su disco e si vuole averla su nastro. Con DataCore, si ottiene quella quarta opzione rappresentata dal CDP, ovvero il rollback. Ora, questa sarà una funzionalità da utilizzare per un ripristino a breve termine, perché non si recupereranno i dati di un’intera settimana. Non si recupereranno quelli di un mese. Si recupereranno quelli relativi a pochi giorni o forse a una settimana.

Ogni situazione di ripristino è decisamente diversa dalle altre, ed è fondamentale essere sempre pronti. Bisogna essere preparati ad affrontare qualsiasi situazione, per poter ripristinare i dati nel modo più efficiente possibile. Il ripristino da nastro richiede un’eternità, mentre se si utilizza il backup Veeam, il CDP o uno snapshot— è possibile creare anche snapshots questo strumento — il processo è molto più rapido. Quindi, prima di avviare un progetto o effettuare un aggiornamento, è possibile snapshot uno snapshot . Se qualcosa non va per il verso giusto, basta ripristinare da quello snapshot e si torna alla situazione precedente. Ogni scenario presenta le proprie sfide, ed è assolutamente indispensabile disporre di questi diversi metodi di backup e ripristino.

Alan: In realtà ho dovuto affrontare questa questione quando abbiamo parlato per la prima volta di DataCore, del mirroring, dell’aggiunta del CDP e di alcune di queste altre funzioni. La realtà è che, se li metto in mirroring, occupo di nuovo lo stesso spazio. Se utilizzo il CDP, occupo ora una percentuale aggiuntiva di spazio. Quindi la domanda che si poneva inizialmente – e questo ancora una volta prima che Jim prendesse il comando – era: perché ho bisogno di tutte queste copie dei miei dati? La mia risposta all’epoca era che si tratta dell’unica cosa che la compagnia assicurativa non può restituirti. Può fornirti altro software e altro hardware. Può darti un altro edificio. Può darti dei server. Può darti i soldi per stipulare un contratto per una nuova linea di comunicazione. Ma l’unica cosa che non può darti sono i tuoi dati. O li hai, o non li hai.

Da quel momento in poi, la politica prevede che tutto in questo ambiente venga sottoposto a mirroring. Ne abbiamo almeno un’altra copia fisica all’interno dell’ambiente. Oltre a ciò, occorre decidere: questo dato viene gestito tramite CDP? Viene salvato su nastro? Ne viene eseguito il backup? Quanto è importante questo materiale? Ma come requisito minimo, viene sottoposto a mirroring.

Jim: Sì, in effetti mi viene in mente un episodio. È successo probabilmente 5 o 6 anni fa. Avevamo uno dei nostri volumi di Exchange. Gestiamo infatti circa 5 database diversi per il nostro Exchange, e uno di quei database — proprio uno solo — si è danneggiato. Una volta capito cosa fosse successo, siamo riusciti a eseguire un rollback solo su quel singolo volume del database, perché in DataCore li avevamo separati: ogni database ha il proprio volume. Siamo riusciti a eseguire il rollback e snapshot uno snapshot , ricollegare il database a Exchange, anche prima di averne una copia completa, e siamo riusciti a rimettere online quel database mentre veniva effettivamente riscritto nella copia completa.

Una volta creato uno snapshot, ovviamente c’è una procedura che deve essere completata affinché diventi un vero e proprio database attivo e non rimanga solo uno snapshot. Siamo riusciti a collegare lo snapshot server Exchange ancora prima che tale procedura fosse completata, lasciando poi che il processo si svolgesse in background, e siamo riusciti a recuperare il database non appena ci siamo resi conto che era danneggiato — e che dovevamo ripristinare la versione precedente entro 5 minuti.

Alan: Inoltre, abbiamo verificato che non abbiamo perso alcun dato nel farlo. Dal momento in cui abbiamo deciso di tornare indietro — di eseguire un rollback ed eliminare la versione danneggiata — credo che ci siano voluti, dall’inizio alla fine, forse 5 minuti.

Sander: Quindi stai dicendo che non hai dovuto ricorrere al backup Veeam, ma hai utilizzato invece il CDP di DataCore?

Jim: Sì, per questo abbiamo usato DataCore CDP, perché sapevamo che — ripeto — se fossimo tornati a un altro prodotto, a quel punto avremmo perso dei dati, dato che saremmo tornati alla situazione della sera prima. Tutte le e-mail ricevute quella mattina prima del danneggiamento sarebbero andate perse.

Alan: Sì, Veeam non era abbastanza granulare.

Jim: Sì, quindi si torna alla stessa domanda: perché avere tutti questi diversi sistemi di backup? Beh, ognuno ha i propri vantaggi specifici, e il CDP ci ha permesso di individuare il momento in cui è iniziato il danneggiamento, di ripristinare lo stato immediatamente precedente a quell’evento e di farlo senza perdere nessuna delle e-mail ricevute questa mattina, prima che si verificasse il danneggiamento.

Sander: Eccellente. Mi piace molto. È davvero impressionante, perché la maggior parte dei data center — o meglio ancora, la maggior parte degli amministratori IT — avrebbe dovuto ricorrere immediatamente al backup di quella mattina e, come hai detto tu, avrebbe perso diverse ore di dati. È fantastico sentirlo. Un’altra cosa veloce: avevi accennato alla storia di un elettricista che ha commesso un errore durante un intervento di ricablaggio. Puoi raccontarci qualcosa di più su come è successo e se DataCore ti ha permesso di continuare a lavorare senza interruzioni?

Jim: Sì, in quella situazione c’era un elettricista che stava facendo dei lavori di cablaggio. Ora lo chiamiamo Sparky. In realtà stava aggiungendo alcune prese e ha fatto saltare circa metà degli interruttori del nostro data center. Questo ha messo fuori uso una parte piuttosto consistente del sistema. Grazie al modo in cui abbiamo separato i DataCore all’interno del data center, ovviamente su interruttori diversi e in parti diverse del data center, siamo riusciti a… credo che uno dei due sia andato in blackout, ma l’altro è rimasto attivo. Quindi quei dati… non ci siamo mai trovati in una situazione… tornando al punto di partenza… non ci siamo mai trovati in una situazione in cui entrambi i server DataCore fossero fuori uso contemporaneamente. Siamo quindi riusciti a ripristinare l’alimentazione e a riavviare il sistema. Una volta riavviato, il sistema ha risincronizzato tutto dal DataCore rimasto attivo, senza perdere alcun dato né subire conseguenze durature.

Sander: Fantastico. Ora, se avessi avuto un’interruzione del servizio di 5 o 6 ore, quali sarebbero state le conseguenze per la tua attività? In che modo avrebbe influito sulla tua attività?

Jim: Beh, sì, penso che se le filiali non riescono a emettere ordini e non possono aiutare i clienti, ci sia sempre un costo economico in gioco — e non solo economico. Sai, c’è anche una questione di fiducia con i clienti. Quando entrano in negozio, vogliono essere sicuri di poter ottenere ciò di cui hanno bisogno. Quindi, il fatto di essere operativi e in grado di aiutare i clienti è una questione di fiducia.

Sander: Ottimo. Apprezzo molto tutti i vostri contributi. Ho un’altra domanda dal pubblico riguardo al processo di migrazione. Mi è stato chiesto quanto sia stata difficile la migrazione dal vecchio sistema di archiviazione a DataCore?

Jim: Il processo che si segue quando si migrano i dati da qualsiasi sistema di archiviazione esistente verso DataCore consiste essenzialmente nel collegare il sistema di archiviazione a DataCore, dopodiché si attiva la cosiddetta modalità “passthrough”. Ciò consente di trasferire i dati in DataCore durante questa fase; in pratica, i dati passano attraverso DataCore, ma rimangono ancora sul sistema di archiviazione esistente. Successivamente si esegue il mirroring su un altro server, quindi si effettua il failover dal sistema di archiviazione esistente (quello vecchio) a quello di mirroring, un po’ come quando si spegne un server e se ne avvia uno nuovo: è un suo mirror. Infine, si esegue il mirroring di ritorno sulla seconda copia. Abbiamo effettivamente effettuato la migrazione senza che i sistemi subissero alcun downtime. Non abbiamo mai dovuto spegnere nulla per effettuare questa migrazione. Quindi, in realtà, tutto è avvenuto mentre i sistemi erano attivi e in funzione.

Alan: È successo tutto durante il giorno.

Jim: È tutto durante il giorno.

Sander: Wow, è davvero impressionante. È incredibile sentire le storie che i nostri clienti ci raccontano continuamente. Sono a dir poco straordinarie. E sentirti parlare di tutto questo mi fa capire ancora una volta quali siano i veri vantaggi: non solo la tecnologia, ma i benefici che siamo in grado di offrire ai nostri utenti finali, non solo per migliorare la gestione delle loro attività, ma anche per facilitare il vostro lavoro. Quindi grazie per tutti questi feedback.

Passiamo alla diapositiva successiva. Se Alan potesse — o se entrambi poteste — fornirci qualche dettaglio in più su ciascuno di questi punti. Ora disponete di un’unica piattaforma che gestisce tutti i vostri servizi dati, mentre prima avevate diversi silos. E stiamo parlando di una distanza di circa 400 miglia, nonostante la quale ottenete quelle prestazioni. Raccontateci qualcosa in più su queste prestazioni per il vostro ERP. In che modo sono migliorate?

Alan: Una delle cose che è cambiata nel tempo è che il sistema ERP era ospitato su un server dedicato, mentre lo storage era gestito da DataCore. Prima ancora, era ospitato su EMC e Compellent, di cui abbiamo parlato. Una delle cose che volevamo garantire era che il database alla base del sistema ERP fosse un database Progress. Volevamo assicurarci che, una volta migrato su una macchina virtuale, funzionasse correttamente.

A un certo punto si è deciso che RSD avrebbe coinvolto direttamente Progress per effettuare un test sul sistema. I risultati — e in realtà ho avuto un’esperienza simile con un altro cliente che utilizzava Progress nello stesso ambiente — in entrambi i casi la reazione è stata: “Come avete ottenuto questi numeri? Perché noi non vediamo numeri del genere”. Cosa state facendo per renderlo così veloce? Questo è stato praticamente il via libera per procedere e trasferire il sistema da un hardware fisico dedicato (bare metal) alla virtualizzazione, portandolo alla configurazione attuale.

Sander: Alan, da chi proveniva quel feedback? Dal fornitore del software?

Alan: Sì, il fornitore del database software, ovvero Progress. Erano curiosi di sapere come fossimo riusciti a raggiungere quei numeri, perché quando vanno a esaminare queste cose altrove, non hanno mai visto cifre del genere prima d’ora. In realtà ho ricevuto lo stesso commento anche da un altro cliente che ha effettuato lo stesso test direttamente con Progress. Noi non eravamo coinvolti in quel caso. Erano loro a eseguire i test che fanno di solito, ovvero i test di carico.

Sander: Per caso ti ricordi i numeri, magari?

Alan: No, stiamo parlando di anni fa ormai.

Sander: È successo parecchio tempo fa. Ottimo. Jim, abbiamo accennato un po’ a Veeam. Possiamo approfondire un po’ l’argomento? Mi sembra di capire che all’inizio non aveste Veeam, ma che a un certo punto l’abbiate acquisito; su quale tipo di supporto eseguivate i backup?

Jim: Sì, quando abbiamo iniziato a usare Veeam, utilizzavamo uno storage economico e ci limitavamo a eseguire i backup su quello. Durante questo processo di aggiornamento, abbiamo deciso di utilizzare — avevamo dell’hardware in più proveniente dal nostro ambiente di produzione dopo l’aggiornamento — un server in più e un po’ di storage. Abbiamo deciso di provare a utilizzare DataCore per eseguire i backup di Veeam su una piattaforma DataCore, invece di utilizzare, credo fosse uno storage JBOD, il Synology. Una volta che ho coinvolto il tecnico che si occupa dei backup Veeam per me — lui conosceva bene i dati e ha analizzato i tempi necessari per eseguire i backup sullo storage Synology —, una volta che abbiamo iniziato a eseguire i backup su DataCore con tutte le sue...

Alan: Il punto fondamentale era la capacità di memorizzazione nella cache, che consentiva di acquisire i dati molto più velocemente. Se ricordo bene, quando l'abbiamo analizzata, la velocità era triplicata.

Jim: Sì, quindi l'abbiamo fatto. Ha detto che l'esecuzione dei backup su quel server era circa tre volte più veloce rispetto a quella su Synology.

Alan: E aveva tutti i dati. Ce li ha presentati sotto forma di grafico, perché ci stava lavorando e aveva eseguito diversi tipi di backup con Veeam, provenienti da macchine diverse. Ha fatto una sorta di ampia analisi comparativa dei diversi modi in cui venivano effettuati i backup di produzione, e il risultato era significativamente più veloce. Quindi, alla fine, la decisione è stata semplicemente quella di lasciarlo su quel nodo DataCore separato.

L'hardware risale a quando abbiamo trasferito, diciamo, le vecchie apparecchiature di produzione al sito di disaster recovery. Non abbiamo trasferito tutti gli array, ma non avevamo bisogno di così tanto spazio nel sito di disaster recovery. Quindi, in un certo senso, li abbiamo recuperati e li abbiamo collocati dietro questo nodo, essenzialmente come destinazione di backup. Per quanto riguarda le licenze, le abbiamo semplicemente estese un po' e li abbiamo inclusi come nodo.

Ora la gestione delle licenze è piuttosto semplice, perché dipende esclusivamente dallo spazio a disposizione. Tutto qui. È l’unico aspetto da considerare. Quindi, quando raggiungiamo una cifra elevata — insomma, quando superiamo una soglia massima stabilita internamente che ci indica che abbiamo bisogno di più spazio —, non ci resta che ordinare altre licenze.

Sander: Dal punto di vista hardware, è necessario acquistare un altro alloggiamento? Come funziona?

Alan: Dal punto di vista della produzione, tutti i dati relativi a Violin sono deduplicati. Quindi, man mano che aggiungiamo nuovi dati, dobbiamo comunque procurarci le licenze DataCore, ma sul back-end, proprio perché sono deduplicati, la crescita è estremamente lenta. Pertanto, non prevediamo alcun aumento per molto tempo, almeno da quel punto di vista. Quindi, se dovessimo aggiungere qualcosa, si tratterebbe solo di DataCore, ovvero delle licenze software. Per quanto riguarda il backup, non credo che avremo bisogno di altro, ma se dovesse servire, acquisteremmo semplicemente un altro array di tipo JBOD e lo collegheremmo sul retro: probabilmente è così che procederemmo.

Jim: Sì, se stai esaurendo lo spazio di archiviazione e si tratta di un sistema tradizionale a dischi rotanti, devi ovviamente aggiungere hardware. Il bello di DataCore è che puoi aggiungere… puoi continuare a utilizzare… noi utilizziamo i D2700. Puoi aggiungere un array di archiviazione diverso e a DataCore non importa di che tipo sia. Basta semplicemente renderlo disponibile e lui se ne occuperà. Quindi non importa se si utilizza uno storage HP o uno EqualLogic. È possibile collegare un Compellent. È possibile collegare un EMC. È possibile collegare qualsiasi cosa si desideri. Lo gestirà allo stesso modo. Grazie alla cache di cui dispone, anche se si tratta di uno storage lento, ne aumenterà la velocità.

Alan: C'è però una cosa da notare quando si confronta l'attuale ambiente di produzione con quello precedente. La cosa importante è che non stiamo proprio "barando", giusto? Il nuovo ambiente di produzione, con tutti gli SSDs significativamente più veloce rispetto a quello vecchio, perché uno degli amministratori qui presenti ha osservato che tutto è molto scattante. Si tratta di una persona che non fa affermazioni del genere alla leggera.

DataCore funziona bene se lo si utilizza con componenti di buona qualità, e se lo si utilizza con componenti eccellenti, funziona alla grande. L’ambiente attuale di cui dispongono – come ho detto, non prevediamo di ampliarlo per un po’ di tempo, semplicemente perché abbiamo già prestazioni più che sufficienti e spazio a sufficienza. Se dovessimo espanderlo, sarebbe solo una questione di spazio. Non è certamente una questione di prestazioni. Potremmo caricarlo molto, molto di più di quanto non stia facendo oggi.

Sander: Quindi, quello che stai dicendo è che, a seconda del caso d'uso, bisogna investire nell'hardware adeguato per soddisfare tali esigenze, giusto?

Alan: Esatto. Ad esempio, se si considera la parte relativa ai backup di cui stiamo parlando, si tratta ovviamente di hardware di fascia molto più bassa rispetto al resto, ma grazie al software DataCore il risultato è piuttosto soddisfacente, soprattutto perché è stato progettato appositamente e il RAID e tutto il resto sono integrati in modo tale da essere destinati esclusivamente ai backup. Quindi funziona alla grande in quell’ambiente ed è conveniente dal punto di vista economico.

Per quanto riguarda gli aspetti legati alla produzione, abbiamo inserito alcuni elementi che si potrebbero definire migliori. Ciò significa che, in sostanza, non dovremo mai discutere delle prestazioni per capire perché qualcosa sia lento. Era proprio questo l’obiettivo che volevamo raggiungere: l’unica domanda che ci poniamo è: “Abbiamo spazio a sufficienza?”. Ed è proprio così che è stato progettato.

Sander: Ottimo. Per quanto riguarda la tua connessione in questi nove anni, che tipo di connessione utilizzi?

Jim: Su DataCore abbiamo sempre usato Fibre Channel. Sì, stiamo utilizzando la velocità a 8 gig.

Sander: Da DataCore al tuo host ESX, che tipo di connessione hai?

Jim: Anche quella è fibra.

Sander: Ottimo. Quindi sì, avete sicuramente una buona infrastruttura di base che vi garantisce tutta la larghezza di banda di cui avete bisogno.

Alan: Beh, uno dei motivi per cui abbiamo scelto la fibra è proprio l’idea che non dovremo mai discutere sul perché qualcosa funzioni o meno, perché Fibre Channel funziona Fibre Channel .

Sander: Almeno per quanto mi riguarda, sarebbe sempre la mia scelta preferita, ma vediamo che anche iSCSI bene, giusto? Ripeto, dipende tutto dal tipo di...

Alan: Nell’ambiente DataCore, abbiamo collegato i nostri iSCSI a determinati volumi, come ad esempio i desktop degli amministratori. Recuperiamo file e cose del genere. Lo facciamo di tanto in tanto, ma dal punto di vista della produzione, se si parla esclusivamente di connettività di produzione, in questo ambiente si utilizza esclusivamente Fibre Channel. Utilizziamo iSCSI , ad esempio, serve temporaneamente un po’ di spazio in più. Inoltre, storicamente, lo utilizzavamo per alcune attività di tipo amministrativo, per fornire spazio agli amministratori.

Sander: Ho una domanda da porre, e forse Alan potrebbe rispondere. Su quale piattaforma operativa gira DataCore? È Linux, Windows o un sistema proprietario?

Alan: Funziona su Windows, e il motivo è che è l’unico kernel in tempo reale disponibile — ovvero disponibile in commercio. Linux non dispone di un kernel in tempo reale, quindi al momento non lo utilizziamo. La situazione potrebbe cambiare in futuro, quando ne sarà disponibile uno. Inoltre, se si dispone di un server Windows, non esiste dispositivo di archiviazione al mondo con cui non funzioni. Quindi si ha la massima flessibilità su qualsiasi cosa si voglia collegarci. Ora abbiamo questa possibilità almeno come opzione da prendere in considerazione quando valutiamo di espandere o modificare qualsiasi aspetto hardware del sistema.

Sander: Grazie per la risposta. Passiamo subito alla diapositiva successiva per parlare dei risultati: solo un breve riassunto. Siete riusciti a ottenere quella flessibilità necessaria per continuare a utilizzare alcune delle soluzioni di storage più recenti nel sito di DR, a realizzare tutto ciò che desideravate nel sito di produzione, a disporre di tutta la ridondanza di cui avevate bisogno e a rendere più efficiente in termini di costi il vostro investimento negli array di storage. Nel complesso, sembra che siamo riusciti a soddisfare tutte le esigenze. Vuoi aggiungere qualcosa, Alan?

Alan: No. Penso che a un certo punto stessimo soddisfacendo esigenze che inizialmente non erano state nemmeno identificate come realizzabili. Ad esempio, il recupero dei dati senza alcuna perdita. Prima ancora di attivare il CDP, l’aspettativa era che, in caso di danneggiamento dei dati, ci sarebbe stata una perdita, perché bisognava tornare a un altro punto nel tempo, che fosse uno snapshot un recupero da nastro o qualche altro meccanismo dal backup del giorno precedente.  Molte di queste cose sono ora diventate requisiti che inizialmente non c’erano.

Sander: Ottimo. C’era una domanda su Veeam. Jim, magari potresti dire due parole al riguardo. Conosco già la risposta, ma lascio a te il compito di rispondere. Abbiamo ancora 8 minuti, quindi se potessi dedicare qualche secondo a rispondere… la domanda è: «Su cosa avete basato la vostra decisione di scegliere Veeam invece di altre soluzioni?»

Jim: Credo che prima usassimo… in realtà utilizziamo due soluzioni separate… prima usavamo anche Backup Exec. Avevamo un ambiente misto, ma una volta passati alla virtualizzazione – una volta raggiunto un ambiente virtuale al 99% – la flessibilità di Veeam e alcune delle sue funzionalità – ad esempio, usiamo Veeam anche per replicare le macchine virtuali a Peoria. Quindi, mentre utilizziamo DataCore per trasferire i dati a Peoria, usiamo anche Veeam per replicare l’intera macchina virtuale a Peoria, il che ci permette di averla in un ambiente virtuale su un server ESX, pronta per essere avviata, semplicemente lì in uno stato di spegnimento. Quindi Veeam ci offre la possibilità di disporre di quei server. Ora, non è in tempo reale come DataCore, ma per i server che non... sapete, per cui i dati non cambiano molto, lo useremo: server di stampa e cose del genere. Lo useremo.

Il server è lì pronto per essere acceso. Questa è una delle caratteristiche che apprezziamo di più. Inoltre, è davvero efficace nella deduplicazione. In questo modo si consuma molto meno spazio di archiviazione anche per i backup. Insomma, per noi è stato un ottimo prodotto. Lo troviamo di gran lunga migliore rispetto a Backup Exec, che era il software che utilizzavamo in precedenza.

Sander: Fantastico. Grazie per la risposta, Jim. Sembra proprio un’ottima combinazione: Jim si occupa delle macchine virtuali e DataCore gestisce effettivamente gli enormi terabyte di dati. Sono quindi complementari l’uno all’altro.

Jim: Certo, certo. Sì.

Sander: Va bene, ottimo. Vorrei soffermarmi rapidamente su… insomma, approfondire un po’ di più software-defined storage . In pratica, quello che stiamo facendo è creare un livello di intelligenza che vi consenta di attivare tutti questi servizi dati che probabilmente il vostro hardware tradizionale non offre in modo nativo. Quindi ora non solo avete a disposizione tutti questi servizi dati, ma sono applicabili a qualsiasi storage fisico presente sotto DataCore. Ora potete gestire l’intero storage da un’unica interfaccia. Non si tratta solo di gestione e servizi, ma anche della possibilità di consolidare tutti i vostri array.

Come avete sentito dalla storia di Jim, creiamo diverse copie ridondanti: che si tratti di 2 o 3 copie, che vogliate avere un piano di ripristino di emergenza (DR) in una sede fisica o nel cloud— e rendiamo disponibili tutte queste opzioni. Vi offriamo la massima flessibilità, e si tratta di funzionalità collaudate. Jim ha parlato del CDP e di alcune altre soluzioni. Quindi è sicuramente qualcosa che incoraggerei tutti i presenti a valutare.

Operiamo nel settore ormai da 20 anni e vantiamo oltre 10.000 clienti in tutto il mondo, che continuano a sceglierci: il nostro tasso di rinnovo è del 95%. Se volete venire nella soleggiata Florida, la nostra sede si trova a Fort Lauderdale. Saremo sicuramente lieti di parlare con chiunque possa trarre vantaggio dai nostri servizi. Ci piace aiutare. È questo il nostro lavoro, ed è per questo che abbiamo vinto per ben 5 volte il premio come prodotto di archiviazione dell’anno. Se avete bisogno di ulteriori informazioni, potete inviarci un’e-mail all’indirizzo info@datacore.com.

A dire il vero, vorrei soffermarmi brevemente su questo punto. Riteniamo che lo storage abbia la capacità di evolversi, giusto? Ebbene, software-defined storage tale evoluzione e offre la flessibilità necessaria per espandere il proprio ambiente da diverse postazioni, con diversi modelli di implementazione e diverse architetture, pur continuando a utilizzare lo stesso software, ovvero quello di DataCore.

Anche in questo caso, avete la possibilità di scaricare queste presentazioni, così potrete rivedere le diapositive e valutare se si tratta di qualcosa che possa esservi d’aiuto in questo momento, vista la vostra situazione attuale. Ecco alcune citazioni di Jim. Vorrei ringraziare entrambi — Jim e Alan — per essere qui oggi. Apprezzo molto tutti i vostri contributi.

Bene, ora procediamo con la scelta del vincitore. Abbiamo ancora 3 minuti a disposizione e stiamo per scegliere il vincitore. Datemi solo qualche secondo. Vediamo chi è il fortunato vincitore di una carta regalo Amazon da 200 dollari. La vincitrice è Railene Schubert. Riceverai un’e-mail con tutte le informazioni necessarie per scaricare la carta regalo. Quindi, congratulazioni!

Ancora una volta, se queste storie vi piacciono, vi incoraggio a continuare a partecipare a tutti questi webinar. Il prossimo si terrà il 26 maggio alle 14:00. Avremo con noi il nostro partner di Tri Delta. Parleremo della YMCA di Long Island e ascolteremo la loro storia. Probabilmente sarà molto diversa da quella di Jim, ma dovete esserci se volete vedere esattamente cosa sta facendo DataCore per queste organizzazioni.

Sono di nuovo Sander di DataCore. Ricordate che potete scaricare sia la presentazione che il caso di studio. Basta andare alla sezione degli allegati e potrete scaricarli. Grazie per l’attenzione. Alla prossima e buona giornata.