Realtà o finzione: affidarsi allo stesso fornitore di soluzioni di storage per garantire l’alta disponibilità

Vorrei ringraziarvi per aver partecipato oggi a questo webinar dal titolo “Realtà o finzione: utilizzare lo stesso fornitore di soluzioni di storage per garantire l’alta disponibilità”, presentato da DataCore. Il relatore di oggi è Steve, direttore dell’architettura delle soluzioni presso DataCore.

Steve Hunsaker: Grazie Whitney, ti siamo davvero grati per tutto quello che hai fatto per noi; non vedevamo l’ora che arrivasse questo momento e siamo entusiasti di parlare con [loro] per i prossimi 45 minuti di questo “Vero o falso?”, e vi svelerò subito il segreto: ovviamente, è falso. [Risate] Ricordo chiaramente quella volta in cui mi trovavo nel mio data center, appoggiato a una parete, a osservare tutta la mia infrastruttura, tutte le mie risorse, e ho iniziato a pensare: «Beh, ho switch ridondanti e router ridondanti, eppure i miei dati non sono ridondanti, e questo non va bene». Quindi, è finzione, e spero, nel breve tempo a nostra disposizione, di spiegare perché è così, cosa fa DataCore, come ci riusciamo, e alcune delle nostre funzionalità e capacità; ho – ovviamente ho una presentazione PowerPoint, che devo fare. [Risate] Ma ho una lavagna bianca dietro di me e una telecamera che passerà su di essa per illustrare insieme questi concetti; per favore, fatemi sapere se avete domande: vi risponderò in tempo reale. Inoltre, tenete presente che potete sempre scrivermi all’indirizzo Steve.Hunsaker@datacore.com

Va bene. Comincio subito, senza giri di parole. Partendo dal presupposto che non è necessario fare un confronto diretto, ho pensato che fosse meglio iniziare dai nostri modelli di implementazione, per poi parlare di tutto ciò che siamo in grado di fare, della flessibilità che il nostro prodotto offre, di cosa facciamo e di chi siamo; tutto questo verrà fuori man mano che andremo avanti.

Probabilmente disponete tutti di array di storage e, come sapete, questi possono essere basati su Fibre Channel, ISCSI o NFS. SANsymphony un prodotto di storage a blocchi, quindi dobbiamo concentrarci principalmente su Fibre Channel e ISCSI. Partendo da sinistra, abbiamo un modello di storage tradizionale in cui in genere si dispone di un array di storage all’interno del proprio data center e la maggior parte – direi nel 99% dei casi – degli array di storage richiede ovviamente l’acquisto di una marca e di un modello identici per trasferire i dati in un’altra sede. Ed è per questo che il titolo di questo webinar è “Realtà o finzione”, perché ciò che vi proponiamo è che non è necessario farlo. Ora, questo potrebbe sembrare un po’ antiquato, e in effetti lo è, perché lo facciamo da 21 anni. Ma man mano che esamineremo questi modelli di implementazione, penso che vedrete come ci siamo evoluti, come si è evoluto il settore, e questo non ha fatto altro che amplificare la nostra capacità di offrire al settore alcune caratteristiche e funzionalità davvero uniche.

Poi abbiamo la convergenza, dove posso prendere lo storage locale e costruirci una SAN di classe enterprise, offrendo ISCSI Fibre Channel o ISCSI ; e poi c’è l’iperconvergenza, che è questa, sapete, parola d’ordine degli ultimi tempi e di cui probabilmente siete tutti stufi di sentire parlare, ma in realtà è la storia che si ripete ancora una volta, con le applicazioni che tornano allo storage locale. E poi c’è l’ibrido convergente, che è qualcosa che cerchiamo di proporre come un nuovo approccio: non solo le applicazioni possono tornare e lo storage può essere gestito sullo stesso host di tutti gli altri guest, ma potreste avere ancora altri server fisici, sotto forma di Linux, Oracle o Unix, o altro – magari un cluster Hyper-V, o forse un altro cluster VMware a cui possiamo anche fornire dischi. Ne parlerò più approfonditamente in seguito. Ma questi sono alcuni modelli di implementazione da tenere in considerazione mentre portiamo avanti questo progetto.

Una delle cose che penso – e questo è un mio famoso motto – è che, in realtà, DataCore sta allo storage come VMware sta ai server. Ricordo chiaramente di essere stato ansioso, nervoso, persino titubante all’idea di passare da un server fisico a uno virtuale, e questo potrebbe sembrare una cosa di 15 anni fa, ma onestamente ci è voluto un po’ più di tempo perché il settore e voi stessi riconoscesse il fatto che anche lo storage può essere virtualizzato; quello che ho pensato di fare è sottolineare alcuni dei vantaggi che la virtualizzazione dei server mi ha offerto, e uno dei motivi per cui non tornerei mai indietro. Probabilmente non torneremmo mai indietro. Apprezziamo tutti il fatto di poter avviare virtualmente un server che offre mobilità, ridondanza e alta disponibilità; tutti questi vantaggi sono davvero preziosi e non potremmo fare a meno di essi.

E vedo che sta succedendo la stessa cosa con lo storage. Non vorrei davvero che fosse diversamente. Sono proprio queste le ragioni per cui virtualizzerei il mio storage. Creare e offrirvi la possibilità di spostare questi dischi virtuali, anziché le macchine virtuali; ora i dischi virtuali possono essere sostituiti e spostati mentre lo storage sottostante viene sostituito, aggiornato o ampliato, e ci sono tutti i tipi di... sapete, la mentalità è che dobbiamo sempre aumentare la capacità, i dati crescono continuamente, ci sarà sempre uno storage migliore, più veloce, il settore cercherà sempre di spingere sulle prestazioni e tendiamo a usare termini di marketing come “evitare il vendor lock-in”, e questo ci permette di essere più flessibili, di gestire lo storage sottostante fornendo al contempo la disponibilità, i cinque-nove, i sei-nove, di disponibilità dello storage mentre il vostro storage è in manutenzione o viene sostituito, grazie a ciò che stiamo mettendo in campo.

Quindi, questo è, in poche parole, e questa è probabilmente l’ultima diapositiva su cui ci soffermeremo a lungo, ma vorrei spiegare la struttura di questa diapositiva partendo dal basso e procedendo verso l’alto. In questo modo – e poi disegnerò la stessa cosa sulla lavagna, così potrete vedere, per così dire, attraverso immagini e diagrammi come funziona il tutto. Quindi, DataCore SANsymphony è il nome del nostro prodotto. Siamo un’azienda che si occupa esclusivamente di software. Abbiamo sì un’appliance, ma in realtà siamo un’azienda di software, e il nome del software è SANsymphony. SANsymphony offre SANsymphony l’orchestrazione di diversi array di storage, indipendentemente dal fatto che siano NVMe o meno NVMe e se sarò un buon relatore, tirerò fuori il mio pennarello – che si tratti NVMe Fibre Channel, ISCSI, SAS o SATA, o del cloud; cerchiamo di esaminarli con calma.

Posso utilizzare NVMe di un server, un LUN Fibre Channel proveniente da un altro array o un numero qualsiasi di LUN Fibre Channel, un ISCSI , un disco di tipo SAS o SATA all’interno dell’apparecchio, oppure uno JBOD collegato, nonché un dispositivo cloud , e posso sfruttare tutti questi protocolli di storage per riunirli in un unico pool aggregato. E questo è un concetto interessante di per sé. Se, ad esempio, dispongo di cinque terabyte NVMe, un LUN Fibre Channel da cinque terabyte, un ISCSI da cinque terabyte e uno shelf SAS-JBOD da cinque terabyte, ciò significa che posso creare un unico pool da 20 terabyte a partire da ciascuno di questi quattro elementi che lo compongono. E poi, all’interno di quel pool, posso iniziare a sfruttare le caratteristiche e le funzionalità illustrate man mano che saliamo lungo questa diapositiva o questa immagine. Posso quindi classificare automaticamente i blocchi di storage all’interno di quel pool, promuovendo e declassando le cosiddette “piccole unità di allocazione di storage” (little storage allocation units) su e giù per la struttura a livelli, come indicato in [rosso]. Pertanto, utilizziamo un algoritmo basato sulla frequenza di lettura e procediamo alla promozione e al declassamento su e giù per quella struttura a livelli.

Ed è proprio per questo che, come sapete, tradizionalmente non si sarebbe mai e poi mai pensato di combinare
un disco di NVMe con un SATA a 5400 RPM, ma con noi è possibile, grazie a quell’auto-tiering in tempo reale. Lo facciamo in tempo reale, non secondo una pianificazione o qualcosa del genere. Ma ecco il punto, e lasciatemi concentrarmi sulla risposta "fictizia" al titolo della nostra discussione di oggi. Indipendentemente da ciò che avete, posso eseguire il mirroring sincrono di quel pool, utilizzando qualcosa che chiamiamo disco virtuale. Quindi, creo un disco virtuale sopra quel pool, e ora se ho – non sono un grande fan, sapete, di citare nomi di fornitori, ma se ho uno o più LUN Fibre Channel, o ISCSI , e li ho aggregati tutti insieme, anche con qualche disco interno, questo rappresenta un pool che ora posso replicare su un altro pool composto magari da uno storage completamente diverso. Ed è proprio questo il punto, la risposta e il motivo per cui affermiamo che il titolo è assolutamente di fantasia.

Insomma, ci sono tantissime caratteristiche e funzionalità; non voglio soffermarmi troppo su questo aspetto, ma sappiate solo che abbiamo delle funzionalità davvero interessanti. E poi, man mano che andiamo avanti e parliamo dei nostri metodi di accesso, posso prendere questi dischi virtuali e renderli disponibili tramite Fibre Channel, ISCSI, NFS SMB, e in questo modo tutti i nostri host esterni sono in grado di utilizzare lo storage che stiamo mettendo a disposizione. Allora, lasciatemi cancellare i miei disegni e tornare indietro di un paio di diapositive, per rivedere ancora una volta i modelli di implementazione, in modo da assicurarci di capire bene dove stiamo andando. Quindi, se posso iniziare dall’estrema destra e soffermarmi nuovamente sull’ibrido, ciò che stiamo dicendo – ora che forse avete compreso un po’ meglio ciò che stiamo facendo – è che DataCore non solo può risiedere come appliance virtuale, ad esempio su un hypervisor VMware, integrando tutti i LUN Fibre Channel e tutti i ISCSI provenienti dallo storage esistente nei vostri ambienti, ma è anche in grado di utilizzare tutti i dischi locali, il JBOD collegato a quel server, prendendo tutto quello storage, raggruppandolo in un unico pool, e quindi fornendo storage al cluster ESX su cui mi trovo e agli ospiti virtuali, le macchine che risiedono su quella stessa macchina; sono anche in grado, allo stesso tempo, di presentare unSMB Fibre Channel oSMB agli host esterni. Ecco quindi il vostro approccio ibrido.

Ora, lasciatemi andare alla lavagna e assicurarmi che questo – ho regolato la telecamera come si deve qui – e comincio a disegnare alcune cose per voi – e a spiegare come realizziamo questo mirroring sincrono. Dovreste riuscire a vedere questo schema qui sulla mia lavagna. Allora, cominciamo. Allora, ho un array, che è Fibre Channel, e tenete presente che potrebbe trattarsi di un gran numero di LUN. Ho un altro array, che potrebbe essere ISCSI, e potrei avere qualche NVMe locale, oltre a qualche JBOD collegato a esso, come le diverse soluzioni di storage che posso avere a mia disposizione. Ho un host, che chiameremo – per ora chiamiamolo semplicemente DataCore; non voglio entrare troppo nei dettagli, ma potrebbe trattarsi di un host ESX con una nostra macchina virtuale, oppure potremmo essere semplicemente un nodo a sé stante in un contesto più tradizionale. Il punto è che posso prendere ciascuno di questi elementi, raggrupparli in un pool e, come ho detto, eseguire il mirroring su un altro sistema.

Quindi, proviamo a configurare questi due nodi: ora ho DataCore 1, con tutto il suo storage, e ho DataCore 2 con tutto il suo storage. Non importa – non devono necessariamente corrispondere – ricordate che si tratta di un’ipotesi – e poi posso utilizzare percorsi di mirroring, che si spera siano ridondanti, e questi percorsi di mirroring possono essere sia Fibre Channel che ISCSI. Ne sto disegnando due, perché ovviamente possono essere ridondanti; certamente, vogliamo che lo siano. Possono essercene di più; possono essere collegati tramite uno switch, uno switch in fibra ottica o uno switch Ethernet, oppure possono essere collegati direttamente da nodo a nodo. Allora, cosa sono questi nodi? Questi nodi sono qualsiasi server x86. Quindi, in sostanza, ciò che stiamo dicendo è che potete utilizzare – potete scegliere un Lenovo, un Super Micro, un Dell, un HP e così via, a vostra discrezione – e installare DataCore su quel nodo; ora disponiamo di due controller di storage che aggregano tutto lo storage sottostante e sono in grado di eseguire il mirroring.

Ecco, questi sono i percorsi. Ora creiamo quello che viene chiamato “disco virtuale”, e ve lo mostrerò tra un secondo nella nostra interfaccia grafica. Ora abbiamo un disco virtuale riconosciuto da entrambi questi nodi. In altre parole, abbiamo separato i due controller di storage. Quindi, questo percorso di mirroring potrebbe trovarsi a una certa distanza, e vogliamo che la latenza su quei percorsi di mirroring sia inferiore a cinque millisecondi. Ma il punto è che ora i miei dati sono suddivisi e dispongo di una vera alta disponibilità (HA) – attiva-attiva, dal sito B al sito A, o, insomma, come preferite – e sì, abbiamo clienti che hanno entrambi i nodi nello stesso rack, nello stesso armadio, nella stessa stanza, ma abbiamo anche clienti in cui si trovano in stanze diverse, o in edifici diversi all’interno del campus. O in città diverse. Abbiamo suddiviso i dati e disponiamo di una vera alta disponibilità (HA). Quindi, un mirroring sincrono è in realtà, se volete pensarla in questo modo, un RAID 1. Ed è un vero mirroring. Quindi, qualunque cosa accada a questo disco, viene scritta su entrambe le parti. Ricordate che ho detto che questo disco può essere fornito tramite Fibre Channel, ISCSI, ecc.

Beh, se ho un cluster DSX a cui ho assegnato quel data store, questo apparirà in ESX come data store. E quel data store, quando vi si scrive, utilizzerà le tre modalità NPIO (round-robin, “most–recently-used” o percorso fisso) e deciderà quale percorso seguire. Ma ESX vede sicuramente tutti i percorsi che gli ho assegnato per quel data store. Quindi, in un ambiente in buone condizioni, quando tutti i percorsi sono presenti e tutto è in modalità active-active, il diritto potrebbe essere assegnato – uno dei – diciamo, per esempio, al percorso a sinistra di DataCore 1. Ebbene, è qui che entriamo nel vivo della questione e diventiamo un po’ più tecnici su come manteniamo il mirror sincrono. Quel diritto viene ricevuto nella RAM. Questo è un aspetto fondamentale, perché alcuni dei prodotti concorrenti sul mercato utilizzano un disco o una qualche forma di disco per memorizzare in cache i dati in scrittura e in lettura. Noi utilizziamo la RAM per memorizzare in cache sia i dati in scrittura che quelli in lettura. Quel diritto viene inviato attraverso il mirror – uno dei percorsi di mirroring – e viene ricevuto dall’altra parte nella RAM; quindi inviamo un riconoscimento SCSI standard ANSI T-10 e lo rimandiamo [AK] nel processo inverso attraverso il – di ritorno [incomprensibile 0:20:10] il percorso di mirroring, di ritorno alla VM ESX che si trova a destra.

Quindi, stiamo effettivamente rispecchiando il diritto su entrambi i lati in quella modalità attiva-attiva. Nel caso in cui si verifichi un disastro, indipendentemente da ciò che accade a qualsiasi componente sulla sinistra – lasciatemi prendere la mia penna rossa – indipendentemente dal disastro e da quale componente si guasti, ESX vede quei percorsi come inattivi, o forse no – forse i percorsi sono a posto, forse il problema è lo storage sottostante; il punto è che avete un altro lato attivo con quel mirroring sincrono o la vera disponibilità RAID 1 dall’altra parte. Quindi sì, è necessario disporre di storage qui e di storage qui. Se servono 100 terabyte di capacità, è necessario disporre di 100 terabyte qui e di 100 terabyte qui. Ecco come realizziamo questo aspetto teorico di non richiedere che su entrambi i lati sia presente lo stesso fornitore di storage.

Lasciatemi cambiare inquadratura e ora vi mostro la nostra interfaccia grafica. Bene. Passo ora alla nostra interfaccia grafica, a cui mi sono collegato tramite desktop remoto, e in questa schermata vedete i miei tre server DataCore. Ho un gruppo di server denominato “Demo Lab”, che contiene tre motori DataCore, ovvero server. support a 64 all’interno di una singola unità organizzativa o gruppo di server. Questa è la SAN 1, e mi sono preso la libertà di creare il mio ambiente dimostrativo qui, quindi vi prego di tenerne conto. Al suo interno, però, ho dischi fisici di ogni tipo, e il punto che sto cercando di dimostrare è che ho – potrei avere un LUN Fibre Channel, potrei avere un ISCSI , oppure potrei avere dischi interni presenti all’interno del server. Questi dischi fisici possono essere utilizzati per creare pool, e questo è il prossimo elemento fondamentale. Quindi, ho questi dischi fisici e vi sto mostrando i pool a cui sono già stati assegnati; poi ho i miei pool qui, dove ho il Disk Pool 1, ho il CDP, e questi pool sono costituiti da quei dischi fisici.

Ora, ci ho provato davvero, e vi porterò un po’ più avanti con questo argomento – mi piace la nostra flessibilità e la nostra potenza, e voglio dimostrarvelo: ho infatti un membro del pool di dischi che è in realtà un LUN mirrorato e agile, ovvero un LUN 3PAR. Quindi, abbiamo effettivamente la possibilità di mettere in mirroring i LUN e quella coppia di dischi fisici in mirroring rappresenta un disco a sé stante, all’interno del pool di dischi, il che è semplicemente incredibilmente resiliente e fantastico. Ho un pool di dischi, poi ho dei dischi del pool virtuale, dove ho, in questo caso, ne ho uno chiamato ESXi che ho creato e, come potete vedere da questa schermata, presenta una serie di percorsi che sono attivi e connessi e vi mostra chi sono gli iniziatori e le destinazioni, il che sottolinea il fatto che DataCore SANsymphony, quel server che ho disegnato alle mie spalle, il server di cui stiamo parlando, è sia un iniziatore che una destinazione simultaneamente. Quindi, avvio i sistemi di back-end e metto a disposizione il loro storage, e poi fungo da destinazione per gli iniziatori del settore, come ESX, Hyper-V, ecc., e posso fornire loro lo storage.

E tutto questo è determinato dalla natura delle porte del server. Quindi, ho effettivamente cercato di mettere in pratica alcune best practice qui nel mio laboratorio, dove ho due percorsi front-end e due percorsi mirror. E come vi ho detto, sto barando perché a casa mia non ho tutto quello spazio di archiviazione come back-end. [Risate] Ma se aveste uno storage back-end, avreste due percorsi back-end.

Quindi, per essere del tutto sincero e mostrarvi come funziona, si tratta di ISCSI, quindi sto trasmettendo su 229.1, 91.1, e vi mostro da dove sto leggendo, così potete vedere: questo è l’indirizzo IP e l’IQN di cui stiamo parlando. Ora lo cancellerò e riporterò il puntatore sulla freccia; ora abbiamo due percorsi front-end, due mirror, e sto facendo tutto tramite ISCSI. Se vi mostrassi il lato dell’adattatore fisico, potreste vedere che in realtà ho – e mi piace farlo perché sono un po’ ossessivo-compulsivo – ma ho inserito il – Microsoft non ha ancora capito come inserire l’indirizzo IP come una delle colonne qui, e se qualcuno sa come farlo, me lo faccia sapere. Ma io li chiamo semplicemente con il loro indirizzo IP e il loro nome, così posso tenerne traccia, e in effetti ne ho, quanti, sei – sei [nick] che sono tutti basati sull’IP e li ho chiamati in base ai loro ruoli e alle loro funzionalità. Quindi, questo vi mostra il funzionamento di come tutto ciò avviene e come riusciamo a realizzarlo.

Quindi, queste porte di mirroring trasferiscono solo quei diritti specifici di DataCore attraverso quel canale verso l’altro nodo o gli altri nodi DataCore per fornire quel RAID 1, quell’approccio di mirroring sincrono, in modo che, se uno qualsiasi di questi dovesse guastarsi, i dati sarebbero comunque disponibili. Su un disco virtuale, ho quindi la possibilità di disporre di molte delle caratteristiche e funzionalità, come vi abbiamo mostrato nel grafico in cui la maggior parte – la parte principale del mio set di funzionalità – si trova proprio qui con il disco virtuale. Quindi, posso creare altri dischi virtuali – dividerli e disattivarli, il che è fondamentalmente possibile, poiché si tratta di una coppia in mirroring che mi permette di separarli o dividerli e renderli due entità singole; posso sostituire lo storage e spostarlo, configurare un profilo di storage e, nel settore, ci piace usare termini come “pin” : voglio “fissare” questo disco su un SSD o magari il contrario; so che in realtà non verrà mai utilizzato, quindi voglio “fissarlo” nei livelli di archiviazione inferiori.

Posso attivare il CDP, che è una funzionalità fantastica, che mi permette di avere un registro e di tornare indietro a un secondo preciso nel tempo; inoltre, entro un determinato periodo, in base ad altri elementi della vostra infrastruttura, non posso semplicemente, sapete, dire quanti giorni ci vorranno nel vostro caso, ma supponiamo che siano 14 giorni: avete la possibilità di tornare indietro a un secondo preciso, proprio come nel ripristino del log sequenziale. È esattamente lo stesso principio, in cui abbiamo un journal che tiene traccia di tutte le operazioni. Posso utilizzare snapshots e scattare una foto snapshot quell’archivio; posso replicarlo mentre viene duplicato, per poi replicarlo in modo asincrono in un luogo distante, capisci, a distanza. Magari su Azure, Google, AWS o nel garage del signor Frost, non lo so. Ma il punto è che possiamo replicarlo mentre viene duplicato in una terza sede e fornirti un po’ di DR.

Posso raggrupparli e distribuirli a host diversi, e ve lo mostrerò subito. Allora, questo disco virtuale ESX contiene alcune informazioni e le metterò in evidenza qui per un attimo. Vedrete che è aggiornato, è verde – fatemi prendere il mio evidenziatore – ho un “aggiornato” verde su SAN 1, ho "aggiornato" in verde su SAN 2 e, in effetti, ho "aggiornato" anche su SAN 3; come potete vedere, l’accesso all’host è disabilitato, perché quando realizziamo un mirroring a tre vie – che è pensato per tutti voi che vi occupate di sistemi mission-critical e avete bisogno di una disponibilità al 99,9999% o 99,99999%, non sto scherzando – possiamo creare un RAID a tre vie tra questi diversi pool di storage, garantendo davvero un’elevata disponibilità dei vostri dati. Ma non utilizziamo una configurazione attiva-attiva su tutti e tre; utilizziamo una configurazione attiva-attiva-passiva. Quindi, nel caso in cui uno qualsiasi di questi dovesse guastarsi, passiamo allo stato attivo su quel terzo. Lasciatemi cancellare i miei schemi e passare al punto successivo che volevo mostrarvi.

Allora, qui nella scheda delle impostazioni, voglio prestare particolare attenzione a questo perché si tratta dell’ID del mio dispositivo SCSI, il mio NAA, e vedrete che AF29 sono le mie ultime quattro cifre. Lasciatemi accedere al mio server ESX e vi mostro come appare, così vedrete che non mi sto inventando nulla, e vi guiderò passo dopo passo. Se riesco a ricordarmi la password. Oh no. E vedrete che ho dello spazio di archiviazione – già che ci siamo, ricordate quando vi ho detto che abbiamo i percorsi ISCSI tutto il resto? Lasciatemi prendere il mio pennarello – ecco tutte le porte front-end; il motivo per cui ne abbiamo sei è che ho due porte front-end provenienti da ciascuno dei tre host DataCore; quindi, con quel mirroring a tre vie, ESX le vede tutte [collegate], è in grado di usarne quattro di quelle sei, o meglio, tutte e sei – DataCore semplicemente non negozia l’accesso all’host, ma eccole lì tutte e sei [che passano], quindi ho creato una ridondanza completa, ed è così che ISCSI configurato ISCSI . E poi, sullo storage stesso, vedrete che il numero NAA è AF29, esattamente come quello che vi ho mostrato sulla console DataCore: AF29.

Quindi, ecco come gestiamo i dischi fisici: solo per fare un breve riassunto, i dischi fisici – che siano Fibre Channel, ISCSI, collegati direttamente o interni – diventano dischi fisici nel nostro ambiente; siamo quindi in grado di utilizzare qualsiasi combinazione di questi dischi fisici per creare pool; una volta creato un pool, posso creare dischi virtuali su di essi e disporre di un’incredibile quantità di funzionalità all’interno di quel disco virtuale. Sono collegato tramite le porte del server, tramite Fibre Channel o ISCSI i miei mirror, il mio front-end e il mio back-end; la mia configurazione è interamente ridondante e solida, e poi eseguo il mirroring su altri nodi all’interno di quel gruppo di server.

[Lasciatemi] tornare alla mia presentazione PowerPoint e poi, molto rapidamente, ricapitolare: sosteniamo che non dovreste essere vincolati a un unico fornitore e che, in questo 2019, dovreste sentirvi liberi di utilizzare diverse soluzioni di storage. Uno dei principali punti di forza e degli aspetti da considerare: abbiamo avuto un cliente che utilizzava esclusivamente lo stesso sistema di storage, e quando quel fornitore ha effettuato un aggiornamento del firmware, il cliente ha eseguito l’aggiornamento causando il blocco di tutti i propri array, poiché l’aggiornamento non è andato a buon fine. Quindi – in realtà, se il vostro business si basa su dati mission-critical e ad alta disponibilità, è davvero saggio disporre di diverse soluzioni di storage nel vostro ambiente, in modo che, quando si verifica un scenario del genere, non si metta tutto fuori uso.

Quindi, è pura finzione. E abbiamo questi modelli di implementazione: in realtà non c’è un modello di implementazione che non siamo in grado di realizzare. Posso utilizzare dischi locali, array esterni, gestirli dall’alto verso il basso, da sinistra a destra, da un lato all’altro: non fa differenza. Rappresentiamo il meglio della virtualizzazione dello storage e abbiamo sicuramente imparato la lezione: non torneremmo mai più ad avere server fisici. E, onestamente, non tornerò mai più ad avere un array di storage fisico. Abbiamo dei vantaggi di cui siamo consapevoli, per entrambe le parti; disponiamo di una suite completa di funzionalità di classe enterprise; abbiamo spiegato i protocolli di storage partendo dalle basi fino ad arrivare agli utenti finali; non ci sono agenti speciali o simili che debbano essere installati sugli host [bare metal] o sugli hypervisor, poiché forniamo un disco a blocchi SCSI standard del settore.

E infine, forse, la parte superiore di questa diapositiva mostra un’immagine tipica di un array, in cui ho due controller, entrambi all’interno dello stesso chassis in lamiera. E certamente, come spiega quest’area rossa qui, non posso separare quei controller. Non sarei nel pieno possesso delle mie facoltà mentali se provassi a separarli. Eppure, quei controller di storage si definiscono “HA”. Non so se li definirei tali. Li definirei [a tolleranza di guasto], perché certamente ci sono due controller. Ma questi due controller utilizzano lo stesso backplane condiviso di dischi, quindi il punto singolo di guasto si trova a livello dei dischi; e sì, potrebbero essere configurati in RAID, ma sono comunque tutti nello stesso posto. Quindi, se volete l’esatto contrario di questo, e separare completamente quei controller a distanza, tenendoli almeno in stanze diverse, DataCore è la risposta che fa per voi.

E certamente, sapete, è piuttosto stimolante e – fa riflettere – e offre una grande flessibilità: man mano che escono nuovi sistemi di archiviazione, se ho bisogno di maggiore capacità, posso collegare dei dispositivi a un server, posso trasferire i dati su un JBOD, procurarmi un altro array; non vi controlliamo, né vi chiediamo né vi diciamo come – e quale sistema di archiviazione acquistare, ma tieni presente che ti stiamo fornendo quel software che ti permette di prendere quelle decisioni aziendali e di risparmiare un bel po’ di soldi sull’acquisto di sistemi di archiviazione privi di software, perché, ammettiamolo, la maggior parte degli array di archiviazione nel nostro settore non produce nemmeno l’hardware: sono semplicemente aziende di software proprio come noi, che hanno integrato il proprio software con l’hardware su cui sono basati. Potrebbero fornire solo pochi servizi di storage, quindi valutate la flessibilità offerta e, certamente, quando disponete di alta disponibilità (HA) in due sedi diverse, non avete un singolo punto di guasto; avete quel RAID 1 in cui, se perdo un lato, non è tutto perduto, perché ho la possibilità di disporre comunque dei dati sull’altro lato.

Stiamo per concludere. Probabilmente sono un po’ in anticipo, ma vorrei ringraziarvi per aver partecipato e vorrei chiedere a Whitney se… non ho visto comparire nessuna domanda. Whitney, hai visto qualche domanda da parte del pubblico?

Whitney: Avevamo alcune domande su come contattarvi, sul follow-up e sulle informazioni relative a DataCore, quindi le ho gestite nella sezione delle domande. Ma domande specifiche relative ad aspetti tecnici a cui non sono in grado di rispondere? No.

Hunsaker: Ok. Bene, vi prego: sia chi è ancora in linea, sia chi guarderà questo video in un secondo momento, non esitate a contattarmi. Il mio indirizzo e-mail è Steve.Hunsaker@datacore.com. Sono sempre lieto di interagire, discutere e trovare modi creativi per affrontare il tema dello storage, e naturalmente di capire come lo gestite nel vostro ambiente, imparando gli uni dagli altri.