VMware vCloud Hybrid Service

VMware vCloud Hybrid Service

" Il Management non ha intenzione di spendere un solo Euro in infrastruttura nell'immediato futuro "

" Fortunatamente sono abbastanza snello con i costi operativi e tutto sommato ancora competitivo se mi paragono con i costi dell'outsourcing tradizionale "

" Meno male che c'e' la crisi altrimenti il Management avrebbe gia' esternalizzato nel Cloud applicazioni Business Critical come la posta e SAP "

Queste sono solo alcune delle frasi "tranchant" e francamente un po' contradditorie che mi sono sentito dire ultimamente da un affranto responsabile di infrastrutture IT di una importante realta' produttiva italiana che ho reincontrato dopo alcuni anni. Mi ha raccontato di essere sotto forti pressioni per "mantenere elevati SLAs" e contemporaneamente "ridurre il piu' possibile i costi vivi del DataCenter".

Di tentativi negli ultimi anni la sua azienda ne ha fatti tanti, l'Outsourcing di una parte importante del prorio Datacenter ha inizialmente alleviato le pressioni sullo spending ma a distanza di solo un paio di anni questi saving non sono piu' sufficienti.

Eppoi c'e' il problema delle dozzine di sedi remote, per lo piu' ambienti produttivi, non presidiati, che non conviene virtualizzare perche' relativamente piccoli, da gestire e backuppare giornalmente per garantire "... che non si fermino i camion nel piazzale !".

"Niente di nuovo sul fronte occidentale" verrebbe da dire, ma queste frasi mi hanno colpito soprattutto per l'esclusione a priori di una seria valutazione di un provider di servizi XaaS.

Certo, un approccio piu' auspicabile sarebbe stato quello di trasformare il proprio modello di erogazione qualche anno fa', prima che la crisi di quel settore colpisse duro, per renderlo piu' efficiente e competitivo. Si e' deciso pero' di scegliere la strada piu' "facile", ed ora trasformare l'IT nel bel mezzo di una crisi risulta doppiamente difficile per le complessita' intrinseche imposte dall'urgenza di risparmio, ergo le consequenze di cui sopra.

Dopotutto se nel corso degli anni si e' raggiunto un alto livello di efficenza nel governo delle applicazioni critiche per il business ma non ci si puo' piu' permettere di sostenere i costi legati al mantenimento in vita degli "n" DataCenters necessari ad erogare questi servizi, perche' non valutare con serenita' uno IaaS provider ?

Possibile che l'unica via d'uscita passi necessariamente per la perdita di controllo dei workload da parte dell'IT ?

Una soluzione c'e' e si chiama VMware vCloud Hybrid Service.

EMC Recoverpoint: RPO zero anche su asincrono!

Il Dilemma: Sincrono o Asincrono ?

Chiunque intenda affrontare la tematica del Disaster Recovery si trova davanti ad un bivio: come effettuare la replica dei dati? sincrona o asincrona?
Alcune aziende hanno la fortuna di disporre di ben tre siti: Primario o sito di produzione, Secondario o sito con copia sincrona (spesso chiamato anche campus, o sito di business continuity) e Terziario o sito con copia asincrona (per molti noto come replica geografica). Quest'ultima soluzione è senza dubbio la più completa, ma non la più economica sia in termini di costi di realizzazione che di costi ricorrenti e di esercizio. La maggior parte delle aziende ha due siti per cui si trova a risolvere il dilemma. Alla base di questa scelta sta il compromesso tra la L'obiettivo di RPO (quanti dati posso perdere al massimo in caso di disastro), quanto ritardo le mie applicazioni possono tollerare sulle operazioni di scrittura.
A questo si aggiunge la distanza che il sito di DR debba avere in modo da fornirmi sufficienti garanzie. Ricordo un ex collega che alla domanda "a quale distanza deve essere posto il nostro sito di DR" rispondeva "deve stare su una differente zolla della tettonica".

EMC Recoverpoint e Axxana Phoenix

Ancora una volta EMC Recoverpoint mette in evidenza le sue unicità rispetto ai software di replica tradizionale, ma in questo caso grazie ad una soluzione sviluppata insieme ad un partner tecnologico. Axxana è una societa' israeliana non a caso come l'azienda che sviluppò Recoverpoint prima dell'acquisizione da parte di EMC (Kashya). Axxana Phoenix è una soluzione rivenduta da EMC come prodotto EMC Select e totalmente integrata con la gestione di Recoverpoint. Nasce dall'idea di un ingegnere areonautico che si ispira agli FDR (flight data recorder) conosciuti volgarmemte con nome di "scatola nera". Partendo da questo concetto gli israeliani inventano L'Enterprise Data Recorder. Per spiegare di cosa si tratta riprendiamo brevemente l'architettura Recoverpoint (per maggiori dettagli si faccia riferimento al post Recoverpoint su questo BLOG).
Come è possibile vedere dalla figura seguente, Recoverpoint utilizza una tecnica di replica basata su journal, dove alcune transazioni vengono mantenute in una cache sul sito primario, prima di essere raggruppate, deduplicate, compresse e spedite al sito di DR.

Da un sistema NAS ad uno Scale Out NAS.

Cosa è un sistema NAS? 

Il Network-Attached Storage è un sistema che consente di immagazzinare i dati al fine di permettere il file sharing ad altissime prestazioni. L’esigenza di un sistema NAS è nata per risolvere il problema della proliferazione dei file server; infatti il sistema NAS consente il consolidamento di più file server.

Le componenti di un NAS sono rappresentate in figura:

Un sistema NAS utilizza un proprio Sistema Operativo ottimizzato per workload tipici in ambienti file. Questo permette di migliorare l’efficienza e la flessibilità, di semplificare il management grazie alla centralizzazione in un unico sistema di gestione, di avere un’alta disponibilità del dato grazie a meccanismi nativi di clustering e di replica e aumenta i livelli di sicurezza usufruendo di meccanismi di autenticazione e autorizzazione più comuni ed in linea con gli standard di sicurezza. Le componenti principali di un sistema NAS sono la NAS Head e lo Storage. La prima comunica direttamente con i client attraverso la rete IP con protocolli come CIFS e NFS, mentre lo storage è connesso alla componente NAS Head mediante una connessione FC. La NAS Head ha una propria CPU e memoria, uno o più NIC Cards, ed è ottimizzata per gestire le funzionalità tipiche del NAS.

Cosa è un Scale Out NAS? 

Immaginiamo di avere più sistemi NAS all’interno di un unico cluster tutti gestiti dallo stesso Sistema Operativo.

Ottimizzare la Virtual Desktop Infrastructure con le Tecnologie Flash EMC

Le soluzioni EMC VDI basate su tecnologia Flash sono in grado di portare il desktop computing ad alti livelli di prestazioni, efficienza e semplicità. Queste potenti soluzioni soddisfano le mutevoli esigenze di un azienda e del suo business, consentendo in qualsiasi momento, ovunque e a qualsiasi dispositivo di accedere alle applicazioni desktop e ai relativi servizi.

In questa infografica vediamo come le soluzioni EMC VDI con tecnologia flash trasformano il "virtual desktop computing", consentendo prestazioni elevate per organizzazioni di tutte le dimensioni attraverso diverse possibilità di scelta per il cliente.

Link:

EMC XtremIO for Virtual Desktop Infrastructure (VDI)

EMC Virtual Desktop Infrastructure Services-Service overview

Sizing EMC VNX Series for VDI

VCE Virtual Desktop Infrastructure Solutions

Virtual Desktop (VDI) – Elastic Converged Storage, ScaleIO

Luigi De Meo
Advisory Systems Engineer
twitter: @geniusbee

VSPEX Sizer: un Tool per tradurre requisiti applicativi in una soluzione infrastrutturale

EMC da diverso tempo, sta puntando molto sulle soluzioni di Converged Infrastructure. VSPEX è senza dubbio la massima espressione di questa scelta.

Per i nostri clienti e Partner tuttavia, può risultare complicato tradurre i requisiti applicativi in configurazioni infrastrutturali.

E' per questo motivo che EMC ha messo a disposizione un tool che permette di raccogliere i requisiti dei nostri clienti e trasformarli in una soluzione Converged Infrastructure: il nuovissimo VSPEX Sizer.

Tali requisiti sono facilmente collezionabili anche da persone che non si occupano di infrastruttura. Gli input che VSPEX Sizer richiede infatti, sono molto vicini ai nostri interlocutori applicativi.

Il vantaggio di questo approccio consiste nel trovare una soluzione infrastrutturale che possa rappresentare al meglio la richiesta applicativa, senza necessariamente essere esperti nelle best practice della configurazione storage e backup dell'applicazione stessa.

Gli ambienti facilmente traducibili in configurazioni architetturali sono le più diverse: Microsoft Applications, Oracle, Virtualized Environment, Exchange e SharePoint.

Qui di seguito un piccolo esempio di come vengano semplicemente tradotti i requisiti per l'applicazione Exchange in una configurazione storage e backup ottimizzata per Next Generation VNX.

Come potete notare diventa estremamente semplice ed immediato passare da requisiti di business (quante e quali mailbox mi servono per gestire la posta dei miei utenti) in requisiti infrastrutturali (quanto spazio storage e quante performance mi servono per avere un livello di servizio adeguato).

Per concludere: avete visto la semplicità e il dettaglio ottenibile dal VSPEX Sizer per tradurre un requisito applicativo in una soluzione infrastrutturale. I nostri Presales EMC e i Partner autorizzati sono ovviamente a disposizione dei nostri clienti per supportare nuovi progetti.

Il link alla guida operativa (in formato PDF)

Il link al VSPEX Sizer.

--

Umberto Galtarossa

@umberoot

Atmos Cloud Storage / Active-Active by design

Una delle funzionalità fondamentali imposte da un mercato globale è la possibilità di accedere al “dato” da qualsiasi dispositivo ed in qualunque punto del mondo, questo aspetto apre nuove sfide tecnologiche per le quali le architetture IT “classiche” in generale, e storage in particolare, potrebbero non essere la migliore risposta possibile, in alcuni casi.

Un esempio potremmo essere noi stessi che spesso siamo in giro per l’Europa o per il mondo e vogliamo accedere a dati da un dispositivo mobile in ogni momento. Un cloud storage nasce proprio per ospitare dati che debbano soddisfare tale esigenza (oltre che molte altre)..

Atmos può essere una buona risposta dal momento che consente di avere una soluzione scale-out disegnata per essere in configurazione “attivo-attivo”.  Questo vuol dire che le operazioni di lettura e\o scrittura possono avvenire su qualunque nodo, in qualunque sito esso sia, locale o “public”.

Con un approccio di questo tipo è possibile limitare al massimo (o addirittura eliminare in toto) le operazioni di configurazione per accedere al dato in modo ubiquo o per rispondere a disastri dei siti produttivi. Questo risultato è possibile grazie ai meccanismi di Replication e GeoParity.

Atmos replica sincrona e asincrona

Atmos supporta due tipi di replica: sincrona e asincrona. Tali meccanismi di replica possono essere applicati in modo disgiunto o anche in concomitanza a seconda del livello di protezione che si vuole rispettare. 

Queste repliche, o copie, possono essere usate per rispondere alle esigenze di disponibilità, disaster recovery, distribuzione di contenuti e prestazioni di lettura. Le repliche garantiscono che i dati siano disponibili, nonostante eventuali guasti hardware; che gli utenti, indipendentemente dalla loro ubicazione, possano avere una copia dei dati accedibile nel sito più vicino rispetto alla loro posizione geografica.

È importante determinare quante e quali tipi di repliche devono essere definiti per ciascuna classe di oggetto. Il concetto di policy associate al singolo oggetto non è banale.. è possibile definire con semplici tag differenti politiche di protezione, replica, accesso..

Atmos permette di ottenere il meglio dalla propria architettura se l’applicazione (o le applicazioni) che devono sfruttare le sue risorse sono in grado di farlo al meglio e nella maniera più smart possibile (integrazione delle API CAS od utilizzo dei protocolli “web based” REST ed S3).

In una replica sincrona Atmos scrive il dato per il numero di volte imposto dalla policy di protezione prima che l’applicazione venga aggiornata con la conferma di scrittura, questo ovviamente diventa un problema se la scrittura deve avvenire attraverso una rete WAN.

Spesso le repliche asincrone vengono utilizzate proprio per avere una ulteriore copia in un sito (RMG) remoto per fini di sicurezza, DR o per migliorare le prestazioni di lettura richieste da utenti geograficamente vicini alla replica. 

Il numero, la posizione e il tipo di replica per ogni singolo oggetto possono essere controllati utilizzando tag di metadati associati all'oggetto stesso. Attraverso tale politica, ad ogni replica può essere assegnato un posto specifico (es. - "sameAs" o "diverse da "Milan"), oppure si può utilizzare il "tag $ client", ovvero il dato viene scritto sul nodo Atmos che ha risposto al client applicativo. In questo modo i dati possono essere classificati così da avere la protezione adeguata per singola applicazione, invece di operare con una politica di protezione generic anche per dati critici.

Atmos GeoParity

GeoParity è un’opzione di replica basata su policy, che offre eccellenti caratteristiche di affidabilità dei dati. Concettualmente GeoParity è simile ad un RAID, il dato viene scisso in contenuto informative vero e proprio ed una serie di metadati che contribuiscono alla sua ricostruzione in caso di perdita di una o più parti. La differenza è che GeoParity utilizza uno schema di codifica più complesso per i frammenti di ridondanza in modo tale che il dato possa essere ricostruito anche a fronte della perdita di un numero elevato (fino a 6) di frammenti originali. Atmos è in grado di posizionare i frammenti di dato e metadato in dischi, nodi, e potenzialmente anche RMG, diversi in modo da garantirsi una protezione molo elevata.

GeoParity: come funziona

Atmos implementa GeoParity con l'algoritmo Cauchy Reed-Solomon, e utilizza due diverse implementazioni. Il primo è una configurazione 9/12, in cui un oggetto è diviso in 9 frammenti di dati e 3 frammenti di metadato. Questo permette di supportare  fino a 3 errori dovuti, ad esempio, alla perdita di dischi contemporanea. L’overhead è del 33%, rispetto al 100% per una configurazione RAID-1, o 25% per una configurazione RAID-5.

La seconda configurazione è un'opzione di 10/16, in cui ci sono 10 frammenti di dati e 6 frammenti di metadato. Questa configurazione tollera fino a 6 errori contemporanei, ha un sovraccarico di archiviazione del 60%, ma con un maggiore costo in termini di prestazioni rispetto alla configurazione 9/12.

Esiste un MD5 checksum intrinseco che viene calcolato ad ogni operazione di scrittura. Una volta che un client richiede l'oggetto, il checksum viene calcolato nuovamente e controllato con quello memorizzato per verificare la bontà del dato.

Configurazioni consigliate per un / Architettura Attivo Attivo

Per esempio, si consideri il sistema di seguito. i dati sono memorizzati utilizzando uno schema di 9/12 GeoParity e costituiscono il contenuto informative di un sito web di e-commerce. In base alla mia ricerca , quando navigo per cercare un oggetto da acquistare, sono diretto alla copia più vicina in modo da avere una risposta ottimale.

Tuttavia, cosa succede se il sito locale è indisponibile? Ad esempio, per un intervento di manutenzione.

Con un'architettura attivo / attivo e GeoParity invece di vedere il classico messaggio "Sito temporaneamente non disponibile", il sistema Atmos avrebbe riconosciuto che il sito era giù ed in modo trasparente mi avrebbe reindirizzato ad un sito remoto dove avrei potuto  continuare a navigare. Tutto questo viene fatto automaticamente senza modificare l'applicazione, senza alcuna azione da parte dell'amministratore e nessun impatto sulla navigazione (al massimo una latenza superiore e quindi un tempo di risposta non ottimizzato).

Abbiamo visto a grandi linee perché Atmos può essere una soluzione ottimale per rispondere alle esigenze di cui abbiamo parlato all'inizio dell’articolo; nel prossimo post vedremo quali sono i passi per installare e cominciare ad utilizzare una versione virtuale di una appliance Atmos.

Per maggior informazioni su Atmos:

• un white paper sull'architettura di Atmos.
• la pagina dedicata ad Atmos sul sito EMC.

Marco Del Plato