Integrazione Avamar con VMware



A cura di Luca Musumeci, il


Integrazione Avamar con VMware

Si sente dire spesso che il mondo dell’IT è in fase di trasformazione. Vero, sta radicalmente cambiando in tutti i suoi aspetti. Oggi l’IT viene sempre più visto come servizio da fornire attraverso le infrastrutture, il modello operativo e le applicazioni. Tale cambiamento consta fondamentalmente di tre step:

Fase 1: Trasformare l'infrastruttura esistente in un'infrastruttura Cloud. Questo passaggio è alla base di un'infrastruttura veramente dinamica. In questa fase, la virtualizzazione è il mezzo per raggiungere ciò che viene chiamato il "software-defined data center".

Fase 2: Trasformare il modello operativo, ovvero fornire l'IT come un servizio. L’IT deve agire e operare come un fornitore di servizi.

Fase 3: Creare applicazioni per il Cloud. E quindi sfruttare il “Big Data” per costruire applicazioni analitiche e predittive.

La trasformazione è lunga, ma la necessità di adattarsi sarà sempre più importante in quanto il ritmo del business continua ad accelerare, così come la sua complessità. La trasformazione non è certo un processo semplice. Si tratta di un viaggio che necessita pazienza, investimenti e un sforzo collettivo da parte di tutti i fattori chiamati in causa.

Come abbiamo detto, queste trasformazioni avvengono attraverso la ridefinizione di infrastrutture, applicazioni e operazioni. Aumentare le entrate e ridurre i costi operativi per il business, fornendo una moltitudine di servizi sono gli obiettivi chiave per molte organizzazioni IT.

Ciò richiede servizi che siano allo stesso modo interessanti e significativi per il business e possano essere forniti sia all’interno che all’esterno dell’organizzazione. Tra i servizi di punta di un’organizzazione IT c’è sicuramente quello preposto alla sicurezza ed all’integrità dei dati. Migliorando il backup ed il ripristino, l’IT può aiutare a fornire business a valore aggiunto. EMC Avamar con la sua deduplica a lunghezza variabile lato client accelera il viaggio verso la virtualizzazione fornendo backup e recupero estremamente veloce ed efficiente per l’ambiente VMware.

Vediamo come.

Due metodi di backup e ripristino:

  • Guest-Level Backup & Recovery;
  • Image-level Backup & Recovery

 

Guest-Level Backup & Recovery

 

Con questa opzione di backup, il software client Avamar è installato sulla singola macchina virtuale. La configurazione del backup per questo metodo è identico a quella di una macchina fisica. Gli agenti di backup vengono installati sulle macchine virtuali e inviano i dati all’applicazione di backup per la conservazione.

Con questa modalità è possibile avere:

  • Supporto per il backup delle applicazioni all'interno delle macchine virtuali;
  • Backup coerenti con le applicazioni;
  • Supporto per i ripristini parziali o a livello di file;
  • Metodi di backup identici per le macchine fisiche e virtuali;
  • Nessun requisito di scripting avanzato lato VMware;
  • Procedure di backup invariate giorno per giorno.

Di contro, dal momento che ogni macchina virtuale ha installato un client di backup separato, gli hosts ESX che ospitano un gran numero di macchine virtuali potrebbero avere problemi di risorse, in particolare memoria. Non sarà ovviamente possibile effettuare un restore a livello di immagine.
Il ripristino completo del sistema è effettuato in due step.

 

Image-Level Backup & Recovery

 

Avamar è strettamente integrato con “vStorage APIs for Data Protection (VADP)” per i backup agentless. VADP è un framework di VMware che permette di eseguire backup off-host efficienti e centralizzati di macchine virtuali vSphere. Introdotto in vSphere 4.0, VADP sostituisce il “VMware
Consolidated Backup (VCB)” per i backup delle macchine virtuali. Dal momento che VADP è direttamente integrato con Avamar, non è necessario scaricare ed installare nessun software aggiuntivo.

I backup ei ripristini incrementali sono supportati tramite l'uso del Change Block Tracking (CBT).

Avamar può eseguire il backup delle macchine virtuali VMware senza l'utilizzo di agenti di backup all'interno di ogni macchina virtuale. Tutto ciò grazie ad un server proxy che si integra con il  vCenter per montare le immagini dei VMDK di una particolare macchina virtuale.

Con questo metodo, la deduplica viene applicata a livello di vmdk.
L’esecuzione di un backup a livello di immagine dà la possibilità di eseguire un ripristino bare metal o ripristino su una diversa o medesima istanza della VM. Non è richiesto alcun tempo di inattività della macchina virtuale. Con questa tipologia di backup è possibile anche il ripristino a livello di singolo file e/o di singola cartella.

I pro:

  • Eseguire il backup e ripristino senza l’installazione di agenti su singole macchine virtuali;
  • Eseguire backup da una posizione centralizzata, scaricando in tal modo il processo di backup dagli host ESX;
  • Eseguire backup in qualsiasi momento, perché i backup sono “non-disruptive”;
  • La possibilità di eseguire il backup in qualsiasi momento, offre una maggiore flessibilità nella programmazione delle finestre di backup e restore.

I contro:

  • Richiede almeno ESX 4.0;
  • Richiede una moderata quantità di conoscenze di VMware per impostare e configurare una efficiente strategia di backup e ripristino;
  • I backup consumano le risorse del server ESX, tra cui la CPU, RAM e disco;
  • Per il file level restore dà un'immagine di backup per Windows e per Linux, a partire da
    Avamar 6.1.

 

Perché CBT?

 

A partire da Avamar 6.0, il supporto per “vSphere Changed Block Tracking (CBT)” permette il backup ed il ripristino più veloce, grazie all’introduzione del rilevamento delle modifiche incrementali sulle macchine virtuali. Quando Avamar effettua il backup richiede solo la trasmissione dei blocchi modificati dall’ultima snapshot effettuata.

 

Backup & Recovery with CBT

 

L'agent Avamar è installato sui Proxy Avamar (integrati con vCenter) in tal modo il processo di backup è scaricato dalle virtual machine. Attraverso vSphere, ogni VM è dinamicamente montata sul proxy consentendo di Avamar il backup di numerose macchine virtuali in pochi minuti. Con CBT, VMware presenta solo i blocchi modificati all'agent Avamar, questo blocco a sua volta viene suddiviso in segmenti di lunghezza variabile e ulteriormente sottoposto a valutazione: se o meno un segmento univoco. Solo i segmenti unici sono inviati sulla rete, ottenendo la velocizzazione del backup ed il risparmio sulla banda disponibile.

Anche il processo di ripristino sfrutta CBT per il recupero più veloce. Avamar consente il ripristino della VM originale, su una VM esistente o su una nuova VM, direttamente dalla propria interfaccia utente. 

L'API VMware vStorage determina i blocchi modificati. Poi il Proxy legge solo questi blocchi modificati, effettua la deduplica e invia i blocchi unici ad Avamar per la conservazione.

Prima di Avamar 6.0 le operazioni di ripristino erano del tipo ''all-or-nothing''. Quando si ripristinava una particolare immagine VM da un backup Avamar, l'intero VMDK doveva essere inviato attraverso la rete e quindi restorato. Non era possibile effettuare il restore a partire dai blocchi modificati dopo l'ultimo backup.

Il restore con CBT è simile al backup in quanto utilizza le API VMware vStorage per determinare i blocchi modificati. Quindi, solo i blocchi modificati vengono letti e ripristinati sulla VM originale.
Il software Avamar valuterà automaticamente il carico di lavoro tra i due metodi di ripristino (ripristino completo dell’immagine, o un recupero sfruttando CBT) ed eseguirà il metodo che
prevederà tempi rapidissimi di ripristino per il particolare scenario o l'ambiente.

 

Considerazione sulle snapshot

 

Per impostazione predefinita, le snapshot di VMware vengono create sul datastore dove si trovano la macchina virtuale e i suoi file di configurazione. Per minimizzare il tempo richiesto per il rilevamento e la rimozione di una snapshot è bene pianificare i backup per una macchina virtuale quando c'è meno attività di I/O in corso sul datastore dove la macchina virtuale risiede.

E’ “best-practice” mantenere uno spazio libero di almeno il 20% su tutti i datastore per la gestione di snapshot. È importante garantire che ci sia abbastanza spazio per tutti i dischi collegati alla macchina virtuale.

 

Continua a leggere





Un universo bilanciato e sicuro



A cura di Giorgio Benvegna, il


Un universo bilanciato e sicuro

Un “vecchio” testo universitario di reti, nel capitolo relativo allo stato applicativo dello stack ISO/OSI introduceva il paragrafo relativo alle metodologie per il miglioramento delle prestazioni di internet nel seguente modo: “La popolarità del Web è sempre stata la sua rovina. Server, router e linee sono spesso sovraccarichi. Molte persone hanno iniziato a chiamare il WWW con il nome World Wide Wait" (“wait” in inglese significa “aspettare” - Reti di calcolatori Andrew S. Tanenbaum quarta edizione).

Dopo questa esternazione, iniziava l’elenco di metodologie che avevano la prerogativa di migliorare l’affidabilità e le prestazioni di Internet, quale l’utilizzo della cache nei browser e nei proxy, il mirroring dei server con conseguente scelta, ad arbitrio dell’utente, del “mirror” a cui collegarsi. Se si pensa a quello che internet è oggi, risulta evidente che la popolarità non è stata la sua rovina, ma sicuramente è stata ed è una problematica alla quale porre attenzione.

Nella storia recente di internet si è potuto assistere a vere e proprie piccole catastrofi dovute al sottodimensionamento di server, che dovevano in intervalli ristretti di tempo fare fronte ad un numero di richieste anomalo e che hanno avuto anche importanti riscontri mediatici. I miei conterranei, sicuramente ricorderanno il recente “flop day”, termine con il quale è stata declinata la vicenda del “click day”, iniziativa della Regione Sicilia che ha lasciato con l’amaro in bocca migliaia di ragazzi che ambivano ad un tirocinio presso un’azienda e che ha imbarazzato non poco i vertici della politica Siciliana fallendo miseramente e inesorabilmente dietro l’inadeguatezza dell’infrastruttura scelta.

Spesso i problemi che l’IT si trova ad affrontare non sono infrastrutturali, le risorse quali banda e potenza elaborativa, pur essendo presenti non sono utilizzate in modo adeguato, e il problema di bilanciare le richieste viene affidato a metodi e strumenti improvvisati e non affidabili. Il load balancing, in italiano bilanciamento del carico, è una tecnica informatica che consiste nel distribuire il carico di elaborazione di uno specifico servizio, ad esempio la fornitura di un sito web, tra più server. Si aumentano in questo modo la scalabilità e l'affidabilità dell'architettura nel suo complesso. Quindi, bilanciando le richieste di applicazione su più server, si impedisce ad un application server di diventare un single point of failre, in modo da migliorare la disponibilità delle applicazioni e la reattività complessiva. Ad esempio, quando un application server non è disponibile, il bilanciamento del carico indirizza semplicemente tutte le nuove richieste di applicazione ad altri server disponibili.

L’impiego dei bilanciatori di carico, permette anche di migliorare l'utilizzo delle risorse elaborative e massimizzarne la disponibilità. È il metodo più semplice per scalare verso l’alto l’infrastruttura; all’aumentare della domanda applicativa, nuovi server possono essere facilmente aggiunti al pool di risorse, e il bilanciamento del carico inizierà immediatamente l'invio di richieste al nuovo server. Le tecniche di bilanciamento di carico di prima generazione, sebbene rappresentino valide soluzioni per migliorare la disponibilità e la scalabilità dell'infrastruttura di un'organizzazione, la espongono a una serie di rischi legati a problematiche di sicurezza. I prodotti di nuova generazione forniscono un approccio molto più efficiente ed efficace. Questi apparati fisici e virtuali strettamente integrati forniscono non solo le funzionalità di base di bilanciamento del carico, ma anche i massimi livelli di sicurezza e prestazioni per le applicazioni Web critiche di business di oggi.

La necessità di garantire sicurezza ai massimi livelli per i datacenter non è mai stata così alta. Alle sfide e ai problemi tradizionali, inclusi i numerosi requisiti normativi, all’aumento degli attacchi mirati e alla continua erosione dei modelli di sicurezza perimetrali, si è ora aggiunta la necessità di dover considerare architetture cloud aziendali altamente dinamiche e reti flat con un minor numero di potenziali punti di criticità. Aggiungete la sempre crescente necessità di fare di più con meno risorse e diventa chiaro che la base per una maggiore sicurezza deve essere costruita utilizzando l’infrastruttura esistente del datacenter. Un prodotto sicuramente interessante da questo punto di vista è sicuramente Citrix NetScaler, un ottimo controller di distribuzione delle applicazioni (ADC) per realizzare reti cloud aziendali, che rappresenta un’ottima soluzione al problema.

NetScaler, oltre ad essere un componente strategico presente già in migliaia di datacenter aziendali, offre un portafoglio completo di feautures essenziali per la sicurezza dei datacenter, minimizzando la necessità di investire in un ampio numero di soluzioni di sicurezza costose e autonome. Esso infatti non solo fornisce sicurezza per applicazioni importanti e critiche, sicurezza per reti/infrastrutture e gestione delle identità e degli accessi, ma supporta anche un ampio ecosistema di prodotti di partner per coprire gli ambiti di sicurezza complementari.

Continua a leggere





Disaster Recovery & Business Continuity


Come prevenire il rischio e gestire le emergenze aziendali


A cura di Giorgio Benvegna, il


Disaster Recovery & Business Continuity

Disaster recovery e business continuity sono processi che aiutano le organizzazioni a prepararsi ad affrontare eventi distruttivi che potrebbero includere un’eruzione vulcanica, un terremoto o semplicemente la mancanza di corrente o di connettività causate da un escavatore nel parcheggio o un malfunzionamento software dovuto ad un virus informatico. Sebbene i due processi siano differenziabili da un punto di vista funzionale, che non verrà approfondito in questo articolo, essi hanno molti aspetti in comune. Il ripristino dell’emergenza è il processo attraverso il quale si riprende l’attività dopo un evento distruttivo. Data la tendenza umana all’ottimismo, molti dirigenti tendono a ignorare il “disaster recovery”, proprio perché il “disaster” sembra un evento improbabile.

L’accezione “Business continuity”, suggerisce un approccio diverso, esso infatti riporta al concetto di continuità operativa, ovvero, fare in modo di poter continuare a fare soldi, non solo dopo una calamità naturale, ma anche in caso di eventi minori, che sono più probabili e che le aziende si trovano ad affrontare nel corso della loro vita. Nonostante queste distinzioni, i due termini sono spesso sposati sotto l'acronimo BC/DR a causa delle loro molte considerazioni comuni. Ma cosa dovrebbe includere un piano di DR/BC? L’ideale sarebbe che i piani di BC/DR comprendessero anche delle procedure su come i dipendenti dovrebbero comunicare tra di loro e con l’azienda, dove dovrebbero recarsi e come dovrebbero continuare a svolgere il loro lavoro.

Il livello di dettaglio e il focus del piano possono variare notevolmente da caso a caso in funzione di vari parametri, come le dimensioni aziendali, il tipo di attività svolta e il modo in cui l’azienda opera. Per alcune aziende, questioni come la logistica della “supply chain” sono cruciali e rappresentano il focus del piano rispetto al resto dei processi IT, per altri, la tecnologia dell'informazione può svolgere un ruolo fondamentale e il piano di BC/DR può privilegiare il recupero dei sistemi. Ma il punto critico è che nessun elemento dovrebbe essere ignorato, i comparti aziendali dovrebbero sviluppare piani convergenti e lavorare insieme per determinare quali processi, quali sistemi e unità di business sono più importanti per l'azienda. Insieme, essi dovrebbero decidere quali persone hanno la responsabilità di dichiarare il verificarsi di un evento distruttivo e attivare le procedure necessarie ad attenuarne gli effetti. Il piano dovrebbe stabilire un processo per l'individuazione e la comunicazione con i dipendenti dopo un evento catastrofico; esso dovrebbe anche tenere conto del fatto che molti di questi lavoratori potrebbero avere problemi più seri da affrontare rispetto a tornare a lavoro. In sintesi, un buon piano di Business continuity richiede accortezza e pianificazione.

 

 



Ma da dove è possibile cominciare? Il primo passo è quello di svolgere una Business Impact Analysis (BIA). Questo tipo di analisi, ha l’obiettivo di individuare i sistemi più importanti del business e dei processi e l'effetto che un’interruzione di tali servizi avrebbe sul business dell’azienda. Maggiore è l'impatto stimato, maggiore dovrebbe essere il budget utilizzato per ripristinare un determinato sistema o un determinato processo in modo più rapido possibile. Ad esempio, un’azienda di servizi con più sedi potrebbe decidere di destinare tutto il budget per fare in modo di avere i sistemi informatici completamente ridondanti. Ciò consentirebbe di ripristinare l’operatività nel giro di poche ore in un altro luogo.

Questo approccio sarebbe poco utile per un’azienda manifatturiera che avrebbe ben altre priorità e potrebbe rimandare di qualche ora o giorno la disponibilità dei sistemi IT. Una BIA aiuterà comunque le aziende ad impostare una sequenza di ripristino per determinare quali parti del business devono essere ripristinate prima. Ma quali sono quindi gli assiomi che un piano di DR/BC dovrebbe rispettare? Il focus dovrebbe essere sicuramente orientato alle persone, quindi dovrebbe essere previsto un piano di successione per la catena di coordinamento e dovrebbero essere assegnati ruoli specifici ai dipendenti che si occuperanno di attivare le politiche definite dal piano di emergenza. Prevedere luoghi di incontro e piani di comunicazione da attuare in caso di crisi sia per i top manager che per propagare le indicazioni a dipendenti, clienti e mondo esterno. Inoltre, individuare un mezzo alternativo di comunicazione in caso di guasto alla rete, eseguire dei test periodici di continuità operativa abbastanza realistici. Un altro aspetto importante, riguarda la possibilità di eseguire dei test dei piani di disaster recovery. La possibilità di effettuare un test non distruttivo dell’ambiente di recovery dovrebbe essere assolutamente una prerogativa da perseguire. La possibilità di eseguire questi test permette inoltre di individuare problemi e debolezze che difficilmente salterebbero fuori in altro modo.

 

 



Ad esempio, alcune aziende hanno scoperto che mentre il backup dei propri server o data center venivano eseguiti in modo puntuale, venivano trascurati piani di backup per i computer portatili e dispositivi mobili senza quindi effettuare una corretta valutazione dell'importanza dei dati memorizzati su questi dispositivi che a causa della loro natura appunto “portatile” possono essere facilmente persi o danneggiati. Non ci vuole un evento catastrofico per distruggere mesi di lavoro, se i dipendenti usano tenere dati critici o insostituibili in giro sui portatili. Anche semplicemente rivedere il piano di azione spesso permette di fare emergere questioni del genere che non erano state pienamente affrontate prima.

Vale la pena ribadire un concetto: i sistemi informativi sono certamente centrali per le operazioni di business di oggi. Tuttavia, un piano BC/DR solo IT non è sufficiente. Comprendere la gamma completa delle attività, delle persone, dei sistemi e dei processi che rappresentano i business principali di un’azienda è la chiave del successo di un progetto di BC/DR. Oggi più che mai sempre più organizzazioni stanno creando programmi e/o dipartimenti di Enterprise Risk Management e questi problemi sono sempre più sentiti anche dalle imprese più piccole che hanno più (e meno costose) opzioni per il ripristino dell’emergenza di quelle più grandi. In definitiva, il problema va affrontato come qualunque altro problema di sicurezza o di gestione del rischio. Quanto rischio può tollerare la vostra azienda, e quanto è disposta a spendere per mitigare diversi rischi? Nel pianificare l'imprevisto, le aziende devono valutare il rischio rispetto al costo della creazione di un piano di emergenza.

Continua a leggere





Dentro Avamar


Global Client Deduplication


A cura di Luca Musumeci, il


Dentro Avamar

Mi è spesso capitato, per lavoro, di parlare di Avamar. Penso sia una grande soluzione che, grazie alla sua architettura, rivoluziona radicalmente il concetto di backup.
Avamar è stato uno dei primi prodotti a portare sul mercato una vera soluzione di deduplica basata su disco.
Spesso si associa Avamar al solo concetto di deduplica, ma è vero che Avamar fa anche due cose a livello di client sostanzialmente uniche. Non è solo la deduplica, ma è la durata e l'utilizzo delle risorse del client Avamar che sono impressionanti. Non solo la deduplica riduce la quantità di dati da sottoporre a backup del 99%, ma, in molti casi, la durata di un backup di Avamar è del 90% inferiore alla durata di un backup tradizionale.
Chi è attento alla crescente quantità di dati e l'impatto sulle finestre di backup/restore, questa è una caratteristica di fondamentale importanza. Questo post ha lo scopo di rispondere a una domanda lecita: se Avamar sta facendo deduplica a livello di client, come può deduplicare a livello "globale"? Come può la deduplica essere cross-client nell'architettura Avamar?
La risposta è che Avamar utilizza un algoritmo di deduplica a segmentazione variabile.
La deduplica a lunghezza variabile è un metodo di segmentazione intelligente di un file in subfile. Come suggerisce il suo nome, la lunghezza dei segmenti varia, creando così rapporti di deduplica più elevati. La prima volta che il client Avamar esegue il processo di deduplica i dati del sistema sottoposti a backup vengono spezzati in segmenti (chunks). Questi chunks sono di lunghezza variabile, la cui dimensione dipende dal tipo di dati e da dove, all'interno della struttura del dato, risiede il segmento. La dimensione del blocco dell'inizio di un file può essere differente dalla dimensione del segmento della metà del file. Non a caso, questa variabile è in parte responsabile dei rapporti molto elevati di deduplica che Avamar può raggiungere.
Quando tutti i segmenti a lunghezza variabile sono stabiliti, a questi viene applicato un algoritmo SHA-1 (secure hash algorithm). Così ogni segmento ottiene un ID hash univoco che può essere utilizzato per identificare il segmento in futuro. Ogni hash associato ad un segmento su un client è in realtà memorizzato in due luoghi: una volta sul client (in un file chiamato p-cache.dat) e una volta sul server (come parte dei meta-dati che il server conserva).
Ed è questa la chiave! Prima che i dati effettivi vengano inviati al server per il backup, vengono inviati gli hash per quei chunks. In sostanza, il client chiede al server: avete già questo blocco di dati? Se il server determina che sta già mantenendo un blocco di dati che è presente sul client confrontando gli hash, allora non c'è bisogno per il client di inviare i dati al server. Solo quando il chunks è globalmente univoco, quindi  non presente e non già inviato da nessun client, i dati vengono trasmessi al server per il backup. Normalmente, questi hash sono raggruppati in grandi gruppi dal client per ridurre la complessità del processo di backup e ridurre il numero di pacchetti IP generati durante un backup.
Quindi, per esempio, se ho effettuato il backup di una presentazione e un collega esegue il backup della stessa presentazione il giorno successivo, il server informa l’agent che i chunks associati con la presentazione sono già presenti sul server e non sarà necessario eseguire il backup di nuovo. Tutto ciò che verrà inviato saranno i meta-dati associati con la presentazione in modo da permettere la reidratazione del dato per il restore.
In questo modo Avamar è in grado di eseguire i backup in locale, ma deduplica a livello globale. Il risultato è la riduzione del traffico di rete tra client di backup e il server Avamar di ben il 99% o più. A sua volta, questo rende Avamar estremamente efficace per il backup di uffici remoti e ambienti desktop/laptop.

Continua a leggere





 1