Trascrizione del webcast
Signor Chadwell: Buongiorno a tutti. Buongiorno, buon pomeriggio, ovunque vi troviate. Vorrei ringraziare tutti per aver partecipato alla serie “DataCore Storage Success Stories”. Oggi siamo lieti di presentarvi Architectural Nexus e di illustrarvi come riesca a garantire prestazioni applicative elevate rispettando tempi e budget. Questo è il primo appuntamento della serie, quindi grazie a tutti per la vostra partecipazione. Non vediamo l’ora di presentarvi uno dei nostri clienti e uno dei nostri partner, poiché oggi abbiamo una storia davvero interessante e unica da raccontarvi.
Questo intervento è in un certo senso dedicato ad altre persone che potrebbero trovarsi ad affrontare determinate sfide nel proprio contesto. Non vedo l’ora di approfondire ulteriormente l’argomento oggi con il mio panel. Presenterò il nostro partner e il nostro cliente e parlerò un po’ di più di DataCore e di come la nostra soluzione abbia potuto contribuire a questa trasformazione. Approfondiremo la storia per capire esattamente quali fossero le sfide che il nostro cliente, Architectural Nexus, ha dovuto affrontare, la soluzione adottata, l’esito e i risultati ottenuti.
Ne parleremo tra poco, così potrete vedere l’ordine del giorno di oggi. Detto questo, vi presenterò un po’ più nel dettaglio alcuni dei relatori presenti e vi fornirò qualche informazione in più sulle aziende. Per quanto mi riguarda, mi chiamo Michael Chadwell. Sono il responsabile dei canali qui negli Stati Uniti e sono lieto di essere affiancato da Kent Hanson, direttore IT di Architectural Nexus. Steve Hunsaker, qui di DataCore, è il nostro direttore dell’ingegneria dei sistemi. E Jonathan Kendrick di USI, che è il nostro partner del mese e ci sta aiutando con questo cliente, consentendo a Kent di superare alcune sfide.
Vorrei solo sottolineare alcune regole di organizzazione per tutti i partecipanti alla chiamata. Oggi si terrà una tavola rotonda. Vorrei assicurarmi che tutti si sentano liberi di inserire qualche domanda nella finestra della chat, che vedrete sulla destra. La presentazione di oggi verrà registrata e sarà disponibile on demand; al termine del webinar riceverete un’e-mail da BrightTALK.
Vi faccio inoltre notare che nella presentazione di oggi sono presenti anche alcuni allegati che potete portare a casa con voi. C'è un white paper che descrive questo caso d'uso in modo un po' più dettagliato. Detto questo, procedo ad aprire i lavori. E, come parte del panel, vorrei presentarvi Kent Hanson. Kent, se non ti dispiace, raccontaci qualcosa in più sul tuo ruolo e su Architectural Nexus e sull'azienda stessa, per favore.
Signor Hanson: Certo. Allora, salve a tutti. Mi chiamo Kent Hanson. Sono il direttore IT di Architectural Nexus, come già detto. Siamo uno studio di architettura con sede a Salt Lake City e abbiamo un ufficio a Sacramento. Abbiamo iniziato la nostra attività nel 1985. Di recente ci siamo concentrati molto sull’edilizia sostenibile e sulla sfida dell’edilizia sostenibile. Quindi, per passare dalle parole ai fatti, abbiamo costruito il nostro ufficio a Sacramento, che è stato il primo edificio a ottenere la certificazione “Living”.
E ciò significa, se non sapete cosa sia la certificazione “Living Certified”, che non diamo nulla alla città e non prendiamo nulla dalla città. Produciamo tutta la nostra energia. Raccogliamo l’acqua piovana e la filtriamo per tutti gli usi all’interno dell’edificio. Non restituiamo nulla alla città in termini di acque reflue o altro. Tutto viene compostato in loco. Si tratta quindi di un vero e proprio “edificio vivente” e produciamo il 125% dell’energia che consumiamo. Questo ci ha portato ad aiutare altri clienti, supportandoli nello sviluppo e nella gestione del loro modello energetico per ridurre, se così si può dire, il consumo energetico necessario al funzionamento di un edificio. Aiutiamo aziende in tutti gli Stati Uniti. Ecco, questo è ciò che facciamo.
La nostra sfida, quindi, non era solo quella di realizzare un edificio certificato “Living Building”, ma anche di poter lavorare e svolgere il nostro lavoro, che richiede elaborazioni molto complesse e un elevato utilizzo di risorse informatiche. Detto questo, restituisco la parola.
Signor Chadwell: Sì, sì, assolutamente. Non vedo l’ora di approfondire l’argomento; molti di voi qui in conferenza, alcuni dei quali lavorano in studi di architettura o in ambienti che gestiscono grandi quantità di dati, ne sono interessati. Lasceremo quindi che sia Kent a parlarne un po’ più approfonditamente tra un minuto. Vorrei ora cedere la parola e presentare il nostro partner presente alla teleconferenza che lavora a stretto contatto con Architectural Nexus: Jonathan, se non ti dispiace. Presentati, raccontaci qualcosa in più su Universal Systems e magari dicci cosa ti entusiasma di più di questa giornata.
Signor Kendrick: Grazie mille. Mi chiamo Jonathan Kendrick e sono il direttore dello sviluppo commerciale presso Universal Systems Incorporated, ovvero USI. Siamo specializzati nella produzione e nella realizzazione di prodotti OEM per una vasta gamma di clienti diversi; talvolta li aiutiamo a personalizzarli con il proprio marchio, ma disponiamo anche di un nostro marchio, la linea Universal. A tal proposito, non ci consideriamo semplicemente dei produttori, ma ci piace fornire soluzioni e aiutare i nostri clienti ad affrontare qualsiasi problema possano incontrare, aiutandoli a progettare l’architettura più adatta al loro ambiente.
Ed è proprio qui che riprendiamo la storia di come Kent ed io ci siamo avvicinati a DataCore e abbiamo iniziato a utilizzarlo nel suo ambiente. Sarei negligente se non dicessi che, in qualità di produttore OEM, abbiamo avuto l’opportunità di valutare molte soluzioni di storage diverse, soluzioni preconfigurate, dispositivi. Abbiamo valutato attentamente molte soluzioni diverse e, alla fine, è stata proprio la combinazione di funzionalità e la possibilità di integrare DataCore in qualsiasi ambiente per creare soluzioni scalabili sia a livello hardware che software, in grado di soddisfare le esigenze dei clienti, a farci scegliere senza esitazione di collaborare con DataCore circa otto anni fa. Abbiamo quindi realizzato numerose architetture basate su questa soluzione di storage e sviluppato alcune funzionalità integrate con quel prodotto.
Signor Chadwell: Fantastico. Sì, grazie mille Jonathan. Sto già ricevendo domande nella chat e sono lieto di annunciare che Jonathan di USI ci sta aiutando a promuovere e organizzare un incontro del gruppo utenti DataCore a Salt Lake all’inizio del mese prossimo, il 7 febbraio. Sono davvero felice di averti con noi. Sono lieto che tu e Kent possiate parlare di come siamo riusciti a realizzare qualcosa di davvero straordinario qui ad Architectural Nexus. Prima di addentrarmi un po’ di più nei dettagli, vorrei solo presentare Steve Hunsaker, il nostro esperto interno di software-defined storage qui a DataCore.
Steve, ti va di raccontare a tutti un po’ più brevemente chi siamo e poi approfondiremo un po’ di più la discussione con Kent?
Signor Hunsaker: Certamente. Grazie a tutti per essere qui. Mi chiamo Steve Hunsaker, sono il direttore della Solution Architecture per le Americhe e sono lieto di fornirvi ulteriori informazioni su DataCore e sul nostro prodotto. In parole povere, da 21 anni forniamo software che consente ai clienti di utilizzare il proprio hardware. In questo caso, USI ha fornito loro un dispositivo Supermicro. Poiché operiamo in questo settore da 21 anni, riteniamo di essere dei veri esperti in materia.
Siamo stati i pionieri della tecnologia che, nel corso del tempo, ha portato da quella che inizialmente chiamavamo “architettura guidata dal software” alla categoria in cui il settore ha deciso di inserirci, denominata software-defined storage. Siamo presenti in tutto il mondo. Abbiamo molti clienti soddisfatti. Credo che il tasso di rinnovo del 95% parli da sé. Una base clienti straordinaria, soddisfatta non solo di ciò che siamo in grado di offrire in termini di prestazioni e costi, ma anche desiderosa di rinnovare e continuare a usufruire della licenza perpetua che offriamo. La nostra sede centrale si trova a Fort Lauderdale, in Florida.
In realtà è proprio lì che mi trovo in questo momento, a incontrare persone di ogni tipo che hanno energia e passione, e ho davvero la sensazione che siamo uno dei pochi produttori al mondo in grado di navigare in acque libere, innovare davvero il mercato e proporre iniziative sociali come questa che realizziamo per Kent. Vorrei semplicemente ringraziare Kent. Lavoro con lui da alcuni anni. È una persona fantastica e non vedo l’ora di assistere a questa presentazione.
Signor Chadwell: Grazie a tutti, ragazzi. Questo conclude la tavola rotonda di oggi. Come ha sottolineato Steve, siamo grati di poter contare su un partner locale come USI. Ecco perché siamo al 100% un’azienda orientata al canale. Consideriamo la nostra soluzione come quel livello di archiviazione intelligente che può essere utilizzato in vari settori. E collaboriamo con i migliori partner di canale possibili, che dispongano di quella presenza capillare a livello regionale e di quella conoscenza approfondita necessarie per lavorare a stretto contatto con i propri clienti, comprendere a fondo l’evoluzione del mercato ed essere davvero leader di pensiero e consulenti di fiducia, proprio come vedrete qui ad Architectural Nexus.
Allora, entriamo un po’ nel dettaglio, va bene? Parliamo di questa storia di successo nel campo dello storage. Giusto. Parliamo del problema e entriamo subito nel vivo. Allora, Kent, penso che sarebbe utile se ci raccontassi un po’ di più della sfida che hai dovuto affrontare. So che hai detto di aver iniziato... credo fosse verso la fine degli anni ’80. Con l’esplosione dei dati, quali sono state le conseguenze per te, per la tua azienda e, in sostanza, cosa ha spinto questa collaborazione a risolvere questa sfida?
Signor Hunsaker: Allora, quando ho iniziato a lavorare per quella che oggi è Architectural Nexus, credo che il nostro intero backup su nastro fosse di 35 gigabyte. All’epoca erano tantissimi dati. Oggi un singolo progetto supera facilmente quella cifra, vista la mole di dati che viene generata durante la realizzazione di un progetto. Man mano che siamo cresciuti, siamo arrivati al punto in cui sulla nostra rete c’erano tutte queste “isole di dati” e gestirle è diventato piuttosto difficile; è diventato quindi evidente che dovevamo passare a una soluzione SAN. Abbiamo quindi iniziato a valutare diversi prodotti. Ricordo che compro hardware da Jonathan da... da quanto tempo, Jonathan? Probabilmente da 16 anni ormai?
Signor Kendrick: Sì, sì.
Signor Hunsaker: È passato un bel po’ di tempo. Ricordo di aver chiesto a Jonathan: un giorno ne stavamo parlando e io gli dissi: “Sì, compreremo una SAN”, e lui mi rispose: “Beh, dovresti davvero dare un’occhiata a DataCore”. Questo è successo probabilmente otto anni fa. All’epoca, non capivo bene il concetto di “software-defined”. Così, per la nostra fonte di dati primaria, abbiamo scelto uno dei concorrenti di DataCore.
Alla fine abbiamo optato per la SAN e l’abbiamo utilizzata per circa un anno, ma proprio mentre stavamo acquistando la SAN, ci siamo trovati nella situazione di avere quattro sedi diverse – anzi, probabilmente erano cinque all’epoca – e avevamo bisogno che gli utenti potessero lavorare contemporaneamente sullo stesso progetto e aprire i file; così abbiamo iniziato a chiederci: “Come possiamo farlo?” Fu proprio in quel periodo che Autodesk annunciò che era possibile utilizzare Revit, un software di gestione delle informazioni di progetto, su Citrix. Così abbiamo iniziato a valutare Citrix.
Quindi avevamo l’altra SAN in funzione, con VMware in esecuzione su di essa, e poi abbiamo iniziato a orientarci verso Citrix. Avevamo già investito un sacco di soldi in questo computer. Era costoso e funzionava, ma ora ci trovavamo in una situazione in cui avevamo bisogno che questi team lavorassero su questi progetti e dovevamo avere — lo definirei un team virtuale, se volete. Avremmo avuto persone a Sacramento che lavoravano su progetti a Salt Lake e viceversa, e diversi disegnatori si sarebbero alternati con orari diversi, avendo così, come dire, un po’ di tempo libero a disposizione.
Beh, come facciamo a farli lavorare a Sacramento? Come facciamo a farli lavorare al progetto a Salt Lake, alla stesura dei documenti e tutto il resto? Quindi Citrix è diventata la soluzione più ovvia. Quando abbiamo iniziato a esaminare Citrix e i requisiti necessari, ci siamo resi conto che avevamo bisogno di uno storage veloce. Così siamo andati a comprare, in pratica, una serie di dischi rigidi da 15.000 RPM. Mi sembra di ricordare che ne abbiamo acquistati sei o otto al primo tentativo. E funzionava davvero bene con uno o due utenti. In realtà si poteva arrivare anche a circa 10 utenti senza che nessuno si lamentasse, ma quando abbiamo iniziato a spingerlo oltre quel limite, cavolo, le lamentele si sentivano oltre i confini dello Stato.
È stato davvero un peccato che le cose si siano rallentate così in fretta. Mi sono ritrovato di nuovo a parlare con Jonathan di altro hardware e lui ha tirato fuori di nuovo DataCore. Ho pensato: “Beh, e Jonathan, a suo merito, proviamo a fare un progetto pilota. Che male può fare?”. Va bene. Vieni qui, fai un progetto pilota, e lui è venuto e ha portato a termine il suo progetto pilota. E le lamentele si sono in qualche modo placate. Sono scomparse e siamo riusciti ad aggiungere altre persone alla SAN.
In sostanza, si trattava di integrare un software su un hardware che avevamo già acquistato: era hardware di classe enterprise, ma non era una SAN. Tuttavia, acquistando DataCore e integrandolo su quella struttura, improvvisamente è diventata una SAN e all’epoca non mi rendevo conto di quanto fosse potente. Man mano che iniziavamo a crescere, sempre più persone chiedevano: «Ehi, posso avere un desktop lì?», «Posso avere un desktop lì?».
Un giorno, non so quanto tempo fa, ho iniziato a notare che gli IOPS sulla nostra SAN raggiungevano regolarmente i 55.000 IOPS. Poi, un giorno, con mia grande sorpresa, abbiamo registrato 372.000 IOPS sulla nostra SAN. Su questa piccola SAN, che era quasi un ripensamento, la cosa mi ha lasciato davvero a bocca aperta. Allo stesso tempo, quindi, i dati stavano esplodendo sul nostro Compellent e dovevamo iniziare a espanderlo. Mi sto spostando, sto un po’ saltellando qui. Quindi, se avete bisogno che faccia un backup, fate pure.
Signor Chadwell: No, no, no, va benissimo.
Signor Hunsaker: La cosa strana è che abbiamo dovuto aggiornare i dati sull’altra nostra SAN. Mi scusi. Avevamo bisogno di aggiungere più spazio di archiviazione perché stavamo esaurendo i terabyte. Così ho chiamato il nostro rivenditore e gli ho detto: «Ehi, fammi un preventivo per passare dai nostri dischi da 2 terabyte a quelli da 4 terabyte». E quando ho ricevuto il preventivo, sono quasi caduto dalla sedia perché era superiore a quanto avevo pagato per DataCore e per i dischi rigidi nella mia SAN DataCore. In effetti, il preventivo indicava un prezzo quattro volte superiore a quello di mercato di un disco rigido. Li ho richiamati e ho detto: “Credo ci sia stato un errore”, ma loro mi hanno risposto: “No, questi sono… devi capire, sono dischi rigidi di prima scelta, appena usciti dalla produzione, il meglio del meglio”.
Beh, se sto ricevendo il meglio del meglio, perché si guastano con una frequenza doppia rispetto alla mia SAN DataCore? Per ogni disco che perdevo su DataCore, ne perdevo due sull’altra SAN e dovevo sostituirli. E li stavamo sottoponendo a un carico di lavoro maggiore. La situazione è peggiorata un po’, quindi ho detto: “Sapete una cosa? Per ora rimandiamo tutto”. Spostiamo i dati da parte e li archiviamo in un’altra area.
Abbiamo avviato un processo di archiviazione a tal fine. Poi è arrivato il momento in cui — non molto tempo fa — mi è stato comunicato che la nostra SAN, quella del concorrente, era giunta a fine vita e sarebbe passata in support dovevo sostanzialmente sostituire l’intero parco hardware.
Signor Chadwell: Fermiamoci qui, Kent. Vorrei solo ricapitolare ciò che ho sentito e sentire anche il parere di Steve su alcuni di questi aspetti. Penso che questa storia sia davvero interessante perché hai detto che, man mano che la tua attività cresceva, la collaborazione era un aspetto fondamentale; e affinché le persone potessero scaricare file e lavorare su progetti in città diverse, in aree geografiche diverse, questi file diventavano sempre più grandi e questo rappresentava essenzialmente un peso — tutto ricadeva su di te e sul tuo team, che dovevate occuparvi della produzione.
E dopo aver implementato DataCore e seguendo le indicazioni di USI, i vostri collaboratori — e in particolare il vostro architetto, che come molti sanno non è certo una risorsa da poco —. Prima stavamo lì ad aspettare di scaricare, aprire o salvare i file, mentre ora, all’improvviso, sono in grado di collaborare più velocemente, voi siete in grado di —
Signor Hunsaker: Vorrei soffermarmi un attimo su questo punto, perché è davvero interessante. Un tempo aprivamo file AutoCAD, sapete, file da uno, due, tre megabyte, che si aprivano, su cui si poteva lavorare e che si potevano salvare e così via. Ora, con Revit, dato che tutto viene elaborato e può essere trasformato in modelli 3D e quant’altro, apriamo file che vanno dai 300 ai 500 megabyte. Non è raro arrivare anche a 600 megabyte.
Quando clicchi su “Apri” quel file, beh, potrebbero esserci da sei a otto persone che aprono quel file da 600 o 500 meg. Si tratta di una grande quantità di dati che vengono trasferiti e prelevati dal disco rigido all’improvviso. Molto di più rispetto a uno o due meg che venivano trasferiti in precedenza. Quindi è diventato un vero problema. Una situazione del tipo “sbrigati e aspetta”. Era —
Signor Chadwell: Stavo proprio per passare la parola a Steve. Steve, quali sono le implicazioni dal punto di vista della densità, o perché il software riesce a gestirlo così bene con un’architettura come questa?
Signor Hunsaker: Credo che si torni al punto di partenza, ovvero al fatto che il nostro software è a licenza perpetua. Ne siete proprietari per sempre. Per dirla in parole semplici, se si considera Kent e la sua acquisizione di Compellent, state acquistando — ammettiamolo, ragazzi. Per gli array di storage che si possono acquistare sul mercato, in realtà state pagando per il loro software e non per l’hardware.
In realtà, però, stavano cercando di far pagare a Kent il prezzo del loro hardware. Il punto è che utilizzano tutti hardware standard. Probabilmente non producono nulla di tutto ciò. Si limitano ad attribuire un prezzo al proprio array grazie al loro software, ed è così che guadagnano. Quindi, in questo caso, poiché DataCore è stato progettato proprio per garantire la massima flessibilità, la SAN di DataCore è in grado di integrare o aggregare qualsiasi sistema di archiviazione Fibre Channel, iSCSI Direct Attach in un unico pool.
Quindi non importa se si utilizza uno storage a collegamento diretto o un array Compellent, XYZ o ABC. È possibile espanderlo utilizzando l’ambiente a disposizione, aumentare la capacità con dischi standard come ha indicato Kent, scalare in modo molto efficace e, per quanto riguarda la tua domanda...
Signor Hanson: Non si perde nulla in termini di prestazioni.
Signor Hunsaker: Esatto. E credo sia importante, Kent, che tu metta in evidenza l’aumento di quel rapporto di consolidamento.
Signor Hanson: Stavo proprio per dire che ora che siamo passati completamente a DataCore, sono io a decidere. Sono io a decidere quando il mio hardware giunge a fine vita. Non qualcun altro. Ha senso? Posso andare a comprare tutti i dischi rigidi che voglio e posso usarli per tutto il tempo che desidero, e a DataCore non importa. Posso chiamarli e chiedere assistenza per il loro software su dischi che hanno 10 anni e mi aiuteranno comunque. Solo perché il produttore della SAN dice: «Ehi, sei a fine vita, sei fuori dal support capite cosa intendo dire?
Signor Chadwell: Oh, assolutamente. Jonathan, vorrei proprio farti questa domanda. In che modo questo aiuta la tua attività, giusto? In qualità di rivenditore e consulente per i clienti strategici, in che modo questa storia ti è d’aiuto?
Signor Kendrick: Beh, ad essere sincero, potrebbe danneggiare anche la mia attività perché, se potessi rivendere il software più volte, avrei maggiori entrate. Si tratta di un flusso di entrate completamente diverso che non stiamo sfruttando perché non addebitiamo alcun costo ai nostri clienti. Ad essere sincero, probabilmente guadagneremmo molto di più se, dal punto di vista del rivenditore, vendessimo qualsiasi altro marchio oltre a DataCore. Ma non offriremmo ai nostri clienti la soluzione migliore. Non li aiuteremmo a gestire il loro budget e non forniremmo loro una soluzione completamente scalabile di cui abbiano il pieno controllo.
Signor Chadwell: Sì, e creando quel rapporto di fiducia che hai con Kent, come ha detto lui stesso, è lui a decidere quando è il momento di rinnovare l'hardware. Sai che tornerà da te, vero?
Signor Kendrick: È vero. Quindi ci occupiamo della parte hardware e forniamo assistenza, ma poiché DataCore prevede una licenza perpetua, non gli rivendo la parte software; raggruppando hardware e software in un unico pacchetto, gli consentiamo di trarne vantaggio ogni volta che aggiorna l’hardware, beneficiando ripetutamente di un costo di proprietà ridotto. Kent, nella tua situazione, probabilmente hai già aggiornato l’hardware: è la seconda volta o sarebbe già la terza?
Signor Hanson: Credo di sì, sì. Quando abbiamo iniziato questo progetto, raggiungevamo 385.000 IOPS — per la precisione erano più circa 370.000 IOPS, ma all’epoca utilizzavamo dischi da 15.000 RPM. Attualmente, il nostro primo livello — e questo è un altro argomento di cui potremmo parlare, ovvero le caratteristiche chiave e ciò che abbiamo effettivamente ottenuto utilizzando DataCore — è ora l’FSC. Tutto, ogni scrittura e ogni lettura, se non è memorizzata nella cache della RAM, passa direttamente all’FSB; quando ci siamo resi conto che ciò accadeva senza alcun costo aggiuntivo, abbiamo deciso di acquistare le unità SSD. Immagino che quella sia stata la spesa necessaria; ci siamo assicurati di avere la licenza necessaria da DataCore e le abbiamo installate. È un’operazione piuttosto semplice da eseguire.
Signor Chadwell: E se posso aggiungere qualcosa a questo proposito, lei ha menzionato che abbiamo inserito alcuni SSD, ma non è solo per la parte di archiviazione. Qualunque tecnologia venga sviluppata, anche qualcosa che non è ancora stato inventato, purché si possa collegare a uno slot PSI Express, abbiamo la possibilità di potenziare quel dispositivo mentre è ancora in funzione. Non è un dispositivo chiuso che si mette in un armadio e di cui ci si dimentica. Possiamo migliorarlo continuamente man mano che il settore propone componenti più veloci.
Signor Hanson: Allora parliamone, perché il nostro prossimo passo – visto che abbiamo gli SSD – è NVMe sto valutando quando e dove, a che punto, passare a questa tecnologia. Quindi, come dicevo, arriva qualcuno e dice: «Ehi, devo aprire questo file da 500 megabyte» e, con la soluzione della concorrenza, gran parte di quel file verrebbe caricata direttamente dal disco; si trattava di un disco veloce, ma ci voleva comunque molto tempo per aprirlo. Quando si apre quel primo file, DataCore – e correggimi se sbaglio, Steve, non voglio dare a nessuno informazioni errate – ma DataCore memorizza quel file nella cache della RAM.
Credo che la quantità di cache che avevo nel SAN della concorrenza fosse di 8 gig o qualcosa del genere. Non era elevata. La quantità di cache che ho nel mio DataCore è di 64 gigabyte. Questo perché è definito dal software. Sono io a scegliere quale sia. Quindi, quando arriva il primo utente, apre il file. Se si tratta di un file utilizzato di recente, verrà prelevato dal RAID SSD e caricato nella cache. Quando arriva l’utente successivo, se quel file è ancora in cache, lo preleva direttamente dalla RAM; ho osservato, su base regolare, che il nostro server di produzione trasmette 3 gigabyte, ovvero 2,4 gigabyte di dati, sulla nostra rete da 10 gigabit verso il nostro Citrix affinché gli utenti possano aprirli.
Quindi, quando si parla di “software-defined”, la granularità e il controllo a disposizione vanno ben oltre ciò che si ottiene con queste soluzioni preconfezionate. Tornando al nostro concorrente – e voi potete interrompermi in qualsiasi momento – ci siamo trovati in una situazione in cui avevamo acquistato – credo fossero 26 o 24 terabyte di dati. Beh, non ci stavamo nemmeno avvicinando a quella cifra, così li ho chiamati e ho detto: «Ehi, che sta succedendo?»
Mi hanno guardato e mi hanno detto: “Beh, per trasferire i tuoi dati dal livello uno al livello tre, dobbiamo fare uno snapshot giornaliero, salvarlo snapshot poi iniziare a migrare i dati durante la notte”. Beh, il fatto che ciò consumasse spazio di archiviazione di cui avevo bisogno per i miei dati di produzione è stato lo stimolo che mi ha spinto a chiedere un upgrade del nostro disco rigido. Quindi, per riuscire a ricavare più spazio di archiviazione dalla nostra SAN, ho dovuto eliminare alcune di queste snapshots.
Beh, basta dare un’occhiata a ciò che offre DataCore. Sai una cosa? Non ho bisogno di uno snapshot eseguire il tiering. Lo fa al volo, mentre si leggono e si scrivono i dati. E man mano che i blocchi più vecchi vengono consultati e utilizzati sempre meno, li sposta automaticamente su dischi più lenti e meno costosi. Tuttavia, se volessi creare snapshot , potrei scrivere uno script in DataCore che crei snapshot volumi ogni volta che lo desidero e lo archivi su volumi diversi, se lo volessi. Quindi non ho perso la possibilità di snapshot non perdo nemmeno spazio di archiviazione grazie al tiering automatico dei miei dati.
Questo è diventato un punto a nostro favore quando abbiamo iniziato a confrontare davvero le due soluzioni. E poi ci siamo resi conto che DataCore offre una funzionalità chiamata “protezione continua dei dati ”, che permette effettivamente di — ad esempio, sulla mia SAN DataCore, potrei tornare indietro a qualsiasi momento delle ultime due settimane per ripristinare un volume ed estrarre i dati da esso in qualsiasi momento e punto.
Signor Chadwell: Qualcuno mi ha detto che l’audio si era interrotto, ma io riesco a sentire tutti. Oh, ok. Siamo di nuovo in linea. Va bene. Volevo assicurarmi che non avessimo perso l’audio. Non volevo interromperti, Kent. Visto che l’ho fatto, Steve, potresti forse approfondire un po’ di più ciò di cui sta parlando Kent riguardo allo spostamento dei diversi livelli di archiviazione e alla memorizzazione nella cache della RAM, e cosa ciò comporti? Insomma, so che Kent ne ha già parlato brevemente, ma forse potresti spiegarci un po’ meglio cosa succede dietro le quinte.
Signor Hunsaker: Certo. SANsymphony è il nome del nostro prodotto, non utilizza il disco per la cache, il che, a mio avviso, ci rende piuttosto unici in questo settore. Infatti, utilizziamo la RAM per la cache delle operazioni di lettura e scrittura. Ovviamente poi bisogna trasferire i dati dalla memoria volatile e scriverli su disco. Quindi, come diceva Kent, si tratta di questi livelli di archiviazione.
Infatti, possiamo inserire unità con prestazioni diverse nello stesso pool, il che è in un certo senso in contrasto con la tradizione. E ora è possibile creare la propria struttura a livelli, dalla più veloce alla più lenta. Quando effettuiamo il de-staging e poi scriviamo su disco, scriviamo sul livello uno e il nostro auto-tiering avviene in tempo reale.
Non si ricorre a un processo automatizzato né a una pianificazione per stabilire quando o come spostare tali blocchi di archiviazione, indipendentemente dal fatto che vengano promossi o retrocessi all’interno della struttura a livelli. Allora, Kent, ci spieghi come gestisce il tiering automatico?
Signor Hanson: Per quanto ci riguarda, abbiamo tre livelli di dati e, come sapete, in DataCore è possibile arrivare fino a 15 livelli. Quando dico che siete voi a decidere quando le vostre unità diventano obsolete, avete a disposizione 15 livelli su cui lavorare. Allora, in breve: cos’è il tiering automatico? Il tiering automatico consiste nell’utilizzare i dati a livello di byte, distribuendo le unità virtuali su diversi tipi di supporti.
Quindi, ad esempio, il primo livello per noi è rappresentato dagli SSD. E credo che abbiamo otto unità SSD. Poi passiamo al livello successivo, costituito da unità da 10.000 rpm. Ne abbiamo diversi terabyte. E poi, quando i dati diventano troppo vecchi e vengono spostati verso il basso, finiscono su unità SATA a 7.200 rpm. Quindi gestiamo tre livelli e, se si volesse considerare la RAM come un livello, non so se sarebbe necessariamente così, quindi per ora diciamo semplicemente che gestiamo tre livelli di archiviazione.
Devi capire che, supponiamo tu abbia un file di grandi dimensioni o, non so, magari un database di Exchange molto grande o qualcosa del genere, e quel database di Exchange, in teoria, potrebbe passare dal nostro disco SSD, scendere verticalmente attraverso il nostro disco da 10.000 rpm e poi arrivare persino al nostro disco da 7.200 rpm, a seconda di quali blocchi o quali byte vengono continuamente scritti e letti. Quindi memorizza i dati che vengono continuamente utilizzati, spostandoli automaticamente sullo spazio di archiviazione più veloce a vostra disposizione. Quello è il livello uno.
E sei tu a decidere come farlo. Mettiamo che domani io vada da te e ti dica: “Ehi, Jonathan, mi serve un gruppo di NVME ” e lo colleghiamo? Beh, allora vado lì e lo collego come “stat attached” o in qualunque altro modo io voglia collegarlo, e poi dico: “Questo è il mio nuovo livello uno”. A quel punto DataCore riorganizza tutti i miei dati in modo che io abbia un livello uno, un livello due, un livello tre e poi avrei un livello quattro con i miei dischi a 7.200 rpm. Questo risponde alla tua domanda? È quello che stavi cercando?
Signor Hunsaker: Sì, penso che sia un’osservazione molto perspicace. E vorrei chiederle di spingersi forse ancora un po’ oltre dal punto di vista degli utenti, degli architetti o, in fin dei conti, di quelli che chiameremo i suoi clienti e i suoi progetti. In che modo questo migliora la loro vita dal punto di vista dell’applicazione? Cosa significa per loro?
Signor Hanson: Supponiamo di avere un progetto e che queste persone stiano lavorando a un progetto creando file grafici, file di modelli Revit di grandi dimensioni; i dati presenti nella directory del progetto vengono automaticamente archiviati in modo gerarchico su quei livelli, su quei tre livelli. Tuttavia, quando accedono e aprono quel file Revit, il sistema lo sta caricando. Se si tratta di un file che è stato aperto negli ultimi due giorni, non restiamo lì ad aspettare che quel file venga caricato sei volte dal disco, magari un disco lento. Viene caricato nella cache RAM e, quando la persona successiva lo apre, viene trasmesso via rete alla massima velocità consentita dalla tecnologia informatica per farglielo arrivare.
Signor Hunsaker: Ottimo. A proposito, avevo una domanda veloce. Erano solo curiosi di sapere quale fosse la configurazione del server che ospitava le metriche con DataCore?
Signor Hanson: Qual era la configurazione del server? Quali erano i parametri di DataCore? In altre parole, vuole sapere quali erano le specifiche della CPU, della RAM e tutto il resto?
Signor Hunsaker: Citrix, la configurazione di Citrix, Kent.
Signor Hanson: Oh, la configurazione Citrix era un E5 e ha una frequenza di 3,3 gigahertz. Non conosco il modello esatto.
Signor Chadwell: Credo fossero i 2670, due E5 2670, ce n'erano due in ciascuno.
Signor Hanson: Sì, e avevamo da 512 gigabyte di RAM a 768 gigabyte di RAM per server.
Signor Hunsaker: E poi, Kent, abbiamo anche un’altra domanda rivolta alla controparte: qual era la configurazione DataCore dei server?
Signor Hanson: I server DataCore sono basati su server Supermicro, ma non ricordo più i numeri esatti dei modelli. Sono processori da 2,6 gigahertz, della serie E5. Dispongono di 10 unità, quindi abbiamo una SAN attiva. In realtà gestiamo due SAN e, tra l’altro, il costo di gestione di queste due SAN è inferiore a quanto ci costerebbe sostituire completamente e aggiornare la SAN della concorrenza. Gestiamo queste due SAN a un costo inferiore a quello che ci costerebbe fare ciò. E sono in configurazione attiva-attiva.
A metà giornata, posso spegnere una SAN e nessuno se ne accorge grazie al modo in cui funziona DataCore. Ma su quelle due unità principali – le chiamo così perché eseguono il software DataCore vero e proprio – abbiamo due dischi in mirror che avviano il server principale di DataCore e poi otto SSD da due pollici e mezzo in mirror, che costituiscono il mio livello uno. C’è poi un collegamento SAP a un [J Bod] ed entrambi questi server si collegano a due diversi J Bod composti da unità da due pollici e mezzo. Da lì, il collegamento prosegue verso un altro collegamento SAP nel J Bod con unità da tre pollici e mezzo.
Signor Chadwell: Se posso fare un'osservazione, Kent, so che abbiamo effettuato un paio di ampliamenti, due o tre per la precisione, in cui abbiamo aggiunto scaffali, installato diverse scatole, spostato il tuo livello uno, spostato le unità disco, sostituitole, e tu vai avanti così da sei anni. E, se posso farti una domanda – anche se potrebbe essere rischioso perché non conosco la risposta esatta – sei mai rimasto fuori uso?
Signor Hanson: Non con DataCore.
Signor Chadwell: Ecco, proprio questo speravo che dicesse.
Signor Hanson: Sì, non con DataCore. Per quanto riguarda la manutenzione e cose del genere, con DataCore puoi dire: “Me ne occupo io”, “il lato sinistro o quello destro”, oppure puoi avere fino a… quanti sono, Steve, 16 nodi o qualcosa del genere, e puoi anche espanderti orizzontalmente, ma noi ne gestiamo solo due.
Signor Hunsaker: Sì.
Signor Hanson: Sono molto potenti.
Signor Chadwell: Su Scuzzy o su Fibre Channel? Ci era stata posta una domanda.
Signor Hanson: Utilizziamo Fiber Channel. Utilizziamo Fiber Channel. Quindi, a dire il vero, utilizziamo entrambe le tecnologie. La connessione tra i due server, dove avviene il mirroring, è a 10 gig [ice scuzzy]. E poi abbiamo il Fiber Channel che collega i server VMR.
Signor Kendrick: Sai, Kent, vorrei solo ricordarti una storia. Non so se te la ricordi o meno. È successo quattro o cinque anni fa: mi hai chiamato nel bel mezzo della giornata solo per dirmi che stavi controllando i log di DataCore e avevi notato che alcuni utenti avevano raggiunto picchi di 325.000 IOPS, eppure nessuno ti aveva chiamato, nessuno si era lamentato, non c’era stato alcun rallentamento. Nessuno si era nemmeno accorto che stavate affrontando un picco di traffico così intenso.
Signor Hanson: Giusto. Giusto. Sì, me lo ricordo. Per completezza di informazione, 325.000 IOPS non era un valore tipico di tutti i giorni. Di tanto in tanto si raggiungevano picchi elevati, ma in quel caso il valore era eccezionalmente alto. Il nostro ritmo operativo tipico, a seconda delle circostanze, non era insolito che raggiungesse valori compresi tra 25.000 e 55.000 IOPS.
Signor Chadwell: Direbbe che è giusto? Adoro ascoltare storie del genere, ma quando penso a una storia del genere, capisce, lei parla di un aumento delle prestazioni: sembra che, in primo luogo, questo le permetta di dormire sonni tranquilli, aiuti la sua azienda a crescere, giusto, e che voi possiate effettivamente affrontare più progetti man mano che assumete nuovi architetti e continuate a costruire questi “edifici viventi”. In sostanza, vi aiuta ad avere la stabilità necessaria per raggiungere quelle prestazioni. La componente di alta disponibilità, giusto, quindi garantire la continuità operativa. Jonathan ha appena sottolineato che sono passati circa sei anni e non ci sono stati down o interruzioni con DataCore in esecuzione sul backend. E dal punto di vista dell’efficienza dei costi —
Signor Hanson: Il punto è che abbiamo operato per sei anni senza alcuna interruzione di servizio utilizzando hardware standard. Per quanto ci riguarda, se ci sono dubbi, la SAN della concorrenza di cui ho parlato o a cui ho fatto riferimento, vi dico fin da ora che non fa più parte del nostro sistema — tecnicamente è ancora presente nei nostri dati, ma è disattivata. Non la utilizziamo nemmeno più.
Abbiamo adottato DataCore in modo completo. Il ROI e il costo totale di proprietà sono decisamente inferiori e, a mio parere, si tratta di una soluzione migliore. L’unica cosa che faremo in futuro sarà migrare a DataCore. I nostri prossimi passi quest’anno saranno valutare la replica asincrona per replicare i dati fuori dalla nostra rete, in modo che tutti possano comprenderne il funzionamento. Abbiamo una rete VGP e un generatore di grandi dimensioni.
Anche in caso di interruzione di corrente, restiamo operativi. Abbiamo subito diverse interruzioni di corrente, ma siamo sempre online. Abbiamo il VGP. Abbiamo due diversi provider Internet che ci garantiscono il servizio e quindi il nostro prossimo passo è creare cloud nostro cloud privato cloud replicare i nostri dati con DataCore verso i nostri siti remoti. Quindi, per noi, DataCore diventerà sempre più parte integrante della nostra produzione aziendale e faremo sempre più affidamento su di esso.
Se ci si ferma a riflettere sul concetto di “software-defined”, cosa succede quando si desidera trasferire i propri dati su Microsoft Azure o si vuole gestire una SAN su Amazon? Beh, se si utilizza un’architettura software-defined, c’è un’opportunità in questo senso e forse potresti parlarne un po’ con Steve. Credo che ora sia supportato, vero, Steve, l’esecuzione di quel software in quegli ambienti?
Signor Hunsaker: Esatto. Perché il nostro software è semplicemente un software che si installa su un server Windows; non importa dove si trovi il server Windows, che sia nel vostro garage o presso un cloud .
Signor Hanson: Se ti crei una SAN virtuale tutta tua, Microsoft ti definisce un cloud forse Amazon, immagino. Quindi, se vuoi sperimentare diverse SAN, ti consiglierei di provare i prodotti della concorrenza, ma se cerchi una soluzione unica, io punterei su DataCore.
Signor Chadwell: Abbiamo ricevuto alcune domande. Credo che finora siamo riusciti a illustrare abbastanza bene la situazione. Quindi, chiunque di voi abbia domande, non esiti a continuare a inserirle nella chat. Una delle domande riguarda l’esperienza nell’utilizzo di array di grandi dimensioni, come gli EMC VNX, in combinazione con DataCore?
Signor Hanson: No, non direttamente, ma direi che, grazie alla cache e all’algoritmo, credo che il processo risulterebbe più veloce. Un rappresentante di DataCore mi ha riferito che uno dei concorrenti voleva utilizzare DataCore come soluzione di tipo "active-active", poiché non era in grado di implementare una configurazione "active-active". Poteva gestire solo una configurazione "active-passive". Ma se si utilizzava DataCore come soluzione front-end, era possibile ottenere una configurazione "active-active". Quindi, personalmente non ho alcuna esperienza con EMC o VNX, ma credo che il sistema funzionerebbe più velocemente.
Signor Kendrick: Abbiamo esperienza in merito e sì, è assolutamente possibile: si può utilizzare un sistema EMC o Unity, oppure qualsiasi altra soluzione si desideri come storage. Non voglio anticipare nulla, ma so che uno dei maggiori clienti di DataCore – non si tratta di un cliente con cui ho avuto a che fare personalmente – utilizza EMC, non è così?
Signor Chadwell: Esatto. Sì. Non sapevo se volessi aggiungere qualcos’altro a questo proposito, Steve, o se per te va bene così. Hai qualcosa da aggiungere prima che passi alla prossima domanda?
Signor Hanson: No, è semplice. Qualsiasi cosa che sia Fiber Channel, iScuzzy o un’attività diretta può funzionare con DataCore; noi continuiamo a fornire le nostre funzionalità e i rispettivi prodotti sottostanti continuano a offrire le loro migliori caratteristiche, e tutto va bene. Ci sei ancora?
Signor Kendrick: E per poterlo far funzionare nel caso in cui il primo sito smetta di funzionare; inoltre, utilizzeremo hardware standard e realizzeremo una soluzione basata su super microbox, risparmiando così il costo dell’acquisto del terzo EMC.
Signor Chadwell: Stiamo ricevendo tantissime domande. Qualche suggerimento su come mantenere lo spazio di archiviazione in buone condizioni per evitare che si verifichino problemi gravi?
Signor Hanson: Chi vuole che…?
Signor Hunsaker: Mi permetto di intervenire. Sono lieto di rispondere a questa domanda. Se per voi va bene, vedendo che stanno arrivando altre domande, cercherò di affrontarne il maggior numero possibile in un colpo solo. Il software di DataCore risiede su un server Windows, quindi potete gestirlo come preferite con Windows Update. Abbiamo un ottimo support che può guidarvi alla scoperta delle modifiche apportate da Microsoft a Windows tramite gli [hotpicks] e aiutarvi a capire se dovete preoccuparvene o meno. In altre parole, vi aiuta a capire quanto dovreste stare al passo con le ultime novità.
Penso a quanto detto da Kent riguardo alla possibilità di testare e aggiornare, che si tratti di un driver, di un firmware o di qualcos’altro, e forse Kent potresti approfondire questo aspetto. Ma poter gestire questa parte da uno dei due lati è molto rassicurante e ci dà fiducia, sapendo che non si rischia di mandare in tilt l’intera SAN, poiché i dati sono conservati in due luoghi distinti. Quindi risponderei a questa domanda dicendo che non c’è alcun problema a occuparsi di driver, firmware e aggiornamenti di Windows. DataCore rilascia pacchetti di aggiornamenti per i server alcune volte all’anno. Quindi, ovviamente, stiamo apportando alcuni miglioramenti e rilasciando anche nuove funzionalità.
E poi ho visto una domanda sulle licenze. Sono lieto di occuparmene. Va bene, Michael, se mi lancio a capofitto su queste domande?
Signor Chadwell: Sì, sì.
Signor Hunsaker: Invece di prendersi il tempo necessario per riprendersi.
Signor Chadwell: Mi stanno chiedendo se sarà possibile ottenere una copia di questo documento in seguito, quindi sì, potrete scaricarlo. Continui pure.
Signor Hunsaker: Certo. Concediamo le licenze in base ai terabyte di capacità utilizzabile. Quindi, se avete 50 terabyte che volete utilizzare, vi forniremmo un preventivo per 100 perché replichiamo quei 50 su un altro server e il totale arriva a 100. Come si posiziona DataCore rispetto a Datrium? Datrium è molto diverso, in quanto fornisce un driver che mette a disposizione lo storage per DM Ware. Noi invece siamo in grado – e non credo che Datrium possa farlo – di prendere un dispositivo Fibre Channel, uno iSCSI e uno storage a connessione diretta, e aggregarli tutti insieme. E, come abbiamo già illustrato, di classificarli automaticamente per livello.
Leggiamo, scriviamo e memorizziamo nella RAM, e siamo quindi in grado non solo di gestire alcune delle altre questioni a cui si è accennato – essendo iperconvergenti, il che, secondo la nostra definizione, significa fornire spazio di archiviazione proprio all’host su cui mi trovo – ma anche, mentre lo facciamo, di rendere perfettamente disponibile quel disco a un ambiente esterno allo stesso tempo, cosa che non credo Datrium sia in grado di fare.
Vediamo un po'.
Signor Chadwell: DataCore funziona su qualsiasi tipo di hardware o ce ne sono alcuni su cui non funziona?
Signor Hunsaker: L’ho visto. Sì. Quindi, qualsiasi server x86 funziona molto bene con noi. Per quanto riguarda marchi come Lenovo, Supermicro, HP e Dell, disponiamo di alcuni documenti che indicano ciò che non funziona. Probabilmente è un buon approccio, piuttosto che pubblicare semplicemente un elenco di tutto ciò che funziona: in questo modo è più facile individuare le eccezioni. Saremo ben lieti di fornirvi qualsiasi ambiente di test di cui potreste aver bisogno. Abbiamo una versione di prova del software valida per 30 giorni che è completamente funzionante.
Offriamo sconti alle organizzazioni no profit. Sul nostro sito web sono disponibili architetture di riferimento realizzate per diversi produttori di hardware per server, praticamente tutti. Il nostro sistema funziona su Windows Server, quindi per poterlo eseguire su VMware o Linux dovremmo utilizzare una macchina virtuale.
[Ken] Il provisioning è in realtà una tecnologia che abbiamo inventato noi e per la quale deteniamo un brevetto, quindi sì, support il provisioning support e lo offriamo. In altre parole, i nostri dischi virtuali possono avere dimensioni superiori a quelle del disco fisico sottostante. Mi sono dimenticato qualcos’altro? Sì, Kent.
Signor Hanson: Vorrei solo aggiungere che DataCore – ed è proprio in quel momento che mi sono davvero convinto – non è certo un novellino nel settore dello storage. Credo, e correggetemi se sbaglio, che tutto sia iniziato alla NASA anni fa, no? Hanno iniziato proprio alla NASA. Credo che l’ingegnere abbia iniziato alla NASA e da lì abbia sviluppato l’azienda. Insomma, è sul mercato da molto tempo.
Signor Hunsaker: Esatto.
Signor Hanson: Di grande, grande fiducia.
Signor Hunsaker: Michael, c’è qualche domanda su cui vorresti che approfondissi?
Signor Chadwell: Sì, ne riceverete tutti una copia. I fattori di differenziazione rispetto ai principali concorrenti. Mi soffermerò un po’ su questo punto. Credo che oggi abbiate intuito che, essendo una soluzione esclusivamente software, possiamo funzionare su qualsiasi hardware. Idealmente, otterrete un costo più vantaggioso. Noi vi aiuteremo sicuramente in questo senso. L’aspetto dell’efficienza di cui Kent ha appena parlato. Prestazioni aggiuntive, ma soprattutto – e qualcuno ha chiesto quali siano i settori o i mercati verticali in cui abbiamo successo – praticamente qualsiasi ambiente ad alta intensità di dati.
In particolare, qualsiasi ambiente mission-critical, ad alta disponibilità o che richieda continuità operativa. Quando penso ai settori verticali, mi vengono in mente gli ospedali, dato che abbiamo oltre 2.000 ospedali che si affidano a DataCore per garantire che i loro dati siano sempre disponibili e sempre operativi. Quando l’uragano Sandy ha colpito, abbiamo avuto effettivamente un ospedale il cui data center è stato sommerso dall’acqua. Si tratta di una struttura a New York e, per fortuna, grazie all’architettura active-active, il loro altro data center dall’altra parte dell’Hudson era effettivamente attivo e pienamente funzionante.
Quell’ospedale continuava ad accogliere pazienti; il personale riusciva a eseguire le risonanze magnetiche e a gestire tutti gli altri interventi chirurgici, i problemi e le complicazioni causati dalla tempesta. Altri ospedali, invece, erano fuori uso. È una situazione che vediamo spesso
Richiedete un preventivo. Non esitate a contattarci: credo che i nostri recapiti siano riportati da qualche parte qui. Vi invieremo sicuramente i nostri recapiti. Sono proprio qui, in quest’ultima diapositiva: info@datacore.com. Non esitate a inviare un messaggio a chiunque di noi sia presente a questo webcast. Per quanto mi riguarda, il mio indirizzo è michael.chadwell@datacore.com.
Vorrei anche affrontare… com’era l’ultima domanda qui… c’è qualcos’altro che avrei dovuto menzionare, Steve?
Signor Hunsaker: No, voglio dire, ci sono alcune domande a cui probabilmente potremmo rispondere. Non so se sappiamo chi le abbia poste, ma ci sono molte cose a cui non abbiamo ancora risposto, ragazzi, e apprezzo il vostro contributo. Il mio indirizzo e-mail è steve.hunsaker@datacore.com.
Signor Chadwell: Sì, e come già detto, questa è in un certo senso la prima puntata di una serie web. Vi invitiamo quindi a seguirci anche nella prossima puntata. Il 26 febbraio ospiteremo un altro cliente che vi spiegherà come utilizza DataCore con un altro dei nostri partner, che opera principalmente nella regione centrale, in collaborazione con Customer First Basis Consulting. Non vediamo l’ora di avervi con noi anche in quell’occasione. Risponderemo inoltre a tutte le ulteriori domande che ci sono state poste oggi. Riceverete una copia della presentazione odierna.
Kent, non potrò mai ringraziarti abbastanza per esserti unito a noi e aver chiacchierato con noi oggi. Jonathan, è sempre un piacere averti qui e apprezzo tutto il lavoro che hai svolto con noi nel corso degli anni. E Steve, ci aiuti davvero a consolidare la nostra autorevolezza nel campo dello storage definito dal software. Non potrò mai ringraziare abbastanza i relatori per oggi. E grazie a voi ragazzi per aver partecipato virtualmente. Non vedo l’ora di continuare a lavorare con voi e di rimanere in contatto. Vi invitiamo a consultare anche gli allegati e i link presenti nel webcast. Sentitevi liberi di scaricare il materiale che vi interessa. Per chi avesse richiesto ulteriori risorse, sono disponibili il caso di studio e alcuni altri documenti più tecnici. Detto questo, mi rendo conto che siamo arrivati allo scoccare dell’ora. Vorrei ringraziarvi e augurare a tutti un meraviglioso rest settimana. A te la parola, Carlos.
Carlos: Vorrei annunciare il vincitore della carta regalo Amazon da 200 dollari. Il vincitore è [John Casella] del Pulte Group. Ti contatteremo a breve e, ancora una volta, grazie a tutti per aver partecipato. Buona giornata.
Signor Chadwell: Grazie a tutti.
Signor Hunsaker: Fantastico. Grazie a tutti.