<< Torna agli Approfondimenti Tematici
|
|
1. Introduzione
Le tecnologie di disaster recovery sono ad oggi un problema ancora molto complesso. Una buona soluzione deve poter ripristinare tutte le applicazioni importanti in un diverso sito geografico con le medesime infrastrutture di calcolo, di storage e di rete ad esse associate. In questo scenario molto probabilmente la parte più delicata risulta essere proprio la rete. In genere ad esempio sarà molto conveniente ripristinare le applicazioni mantenendo gli stessi indirizzi IP in quanto dovranno essere mantenute tutta una serie di dipendenze strutturali legate ad essi (sicurezza, bilanciamenti, risoluzioni DNS, continuità delle comunicazioni tra le varie applicazioni, ecc.). Realizzare questo obiettivo non è facile, presuppone la capacità di estendere i domini L2 tra i due siti utilizzando ad esempio complesse tecnologie di rete quali VPLS (Virtual Private LAN Service) su reti MPLS.
In questo articolo vedremo brevemente come tramite l'azione combinata di SRM 6.1 e NSX 6.2 un piano di disaster recovery completo ed efficiente possa essere gestito interamente attraverso il software. Con questa soluzione di integrazione tra due suoi importanti prodotti nella sua celebre piattaforma di virtualizzazione (vSphere) VMware realizza un ulteriore passo avanti verso un'architettura completa di Software Defined Data Center (SDDC).
2. Il Disaster Recovery
Una qualsiasi organizzazione può essere esposta ad una serie di minacce che possono determinare perdite più o meno gravi a seconda del grado di vulnerabilità dell'organizzazione stessa rispetto alla minaccia considerata. Normalmente per questi scenari sono stimabili dei rischi di varia entità dipendente dal grado di esposizione, risultato della combinazione della probabilità del verificarsi di un evento negativo e dell'impatto prodotto dall'evento stesso.
Naturalmente li Disaster Recovery si articolerà in una serie di processi operativi, gestionali e organizzativi che investono l'azienda a vari livelli. Si tratterà di una vera e propria infrastruttura consistente in un insieme di tecnologie e di processi il cui scopo è quello di poter ripristinare le applicazioni e i dati necessari all'azienda per continuare ad erogare tutti quei servizi che hanno subìto un'interruzione improvvisa a seguito di eventi disastrosi.
Poichè l'obiettivo fondamentale è la continuità di business sarà in genere importante fornire dei parametri che misurino il grado di questa continuità e di conseguenza la bontà della soluzione di Disaster Recovery adottata. Le principali metriche utilizzate sono: RTO (Recovery Time Objective), che esprime il massimo intervallo temporale ammissibile di indisponibilità dei sistemi in seguito ad un disastro; RPO (Recovery Point Objective), che esprime (in unità di tempo) l’ammontare massimo di dati che possono essere persi in seguito ad un disastro.
E' anche evidente che al diminuire di RTO e RPO la soluzione di Disaster Recovery diventa sempre più costosa. Tali costi vanno ovviamente confrontati con le perdite subite temporaneamente o definitivamente a causa dell'indisponibilità dei servizi. Quindi un compito fondamentale nella formulazione di un buon piano di Disaster Recovery è quello della corretta determinazione dei parametri RTO e RPO necessari.
Dal punto di vista delle tecnologie adottate queste si possono mettere in relazione diretta proprio con i suddetti parametri. Si può andare ad esempio dall'uso di semplici tecnologie di backup, con valori di RTO di alcune ore e di RPO di un giorno, a quello di replicazioni sincrone, con RTO di pochi minuti e RPO tendente a zero.
3. VMware Site Recovery Manager
Il Site Recovery Manager (SRM) è il prodotto di VMware che consente di progettare ed eseguire automaticamente dei completi piani di Disaster Recovery nell'ambito delle risorse gestite da un datacenter virtuale basato su vSphere. La sua architettura completamente integrata con il vCenter, di cui costituisce un'estensione, si basa sulla gestione della replicazione di risorse tra un sito protetto e un sito di recovery. Con SRM è possibile costruire dei piani di recovery e testarne il funzionamento, eseguire i processi di failover in risposta ad un evento disastroso o pianificare delle migrazioni controllate, infine è possibile eseguire i failback riportando le risorse sul sito protetto.
Un elemento chiave di SRM sono i meccanismi di replicazione, con cui le risorse vengono ridondante sul sito di recovery. Le tecniche utilizzate per replicare sono di due tipi, tra loro indipendenti e complementari: la Array-based Replication e la vSphere Replication. La prima soluzione sfrutta le capacità di replicazione native del sistema di storage in utilizzo, coordinate da SRM per mezzo di uno Storage Replication Adapter (SRA) fornito dal produttore dello storage. Normalmente in questo caso le replicazioni essendo demandate al sistema di storage sono molto performanti, sincrone o asincrone. La seconda soluzione è invece completamente eseguita dai componenti dell'infrastruttura vSphere (l’hypervisor e un’appliance specifica) ed è quindi agnostica rispetto ai sistemi di storage utilizzati. In tal caso si ha il vantaggio di replicare la singola macchina virtuale anzichè l'intero datastore anche se, di contro, le performance saranno inferiori (ad esempio le replicazioni saranno necessariamente asincrone) e completamente a carico del vSphere. E' da sottolineare però che si tratta di una soluzione interamente software.
Alle due soluzioni di replicazione sono ovviamente associati diversi valori dei due parametri RPO e RTO sopra descritti.
E' bene citare almeno tre importanti funzionalità di SRM:
- Planned Migration: E' un processo di migrazione delle macchine virtuali pianificata, molto utile per scenari di Disaster Avoidance o di gestione e manutenzione del datacenter; la migrazione pianificata è senza perdita di dati in quanto viene eseguita con tutte le risorse disponibili, con i due siti collegati e funzionanti e con la replica disponibile.
- Automated Failback: Quando in seguito ad un failure viene ricostruito l'ambiente produttivo sul sito di recovery è possibile rovesciare le replicazioni e il piano di recovery in modo da mettere automaticamente sotto protezione il nuovo sito funzionante (nel caso che il vecchio sito protetto sia di nuovo disponibile).
- Controllo della sequenza di startup/shutdown delle virtual machines: La procedura che ripristina tutte le virtual machine nel sito di recovery può contenere delle priorità, cioè le indicazioni di quali VM avviare prima, e delle dipendenze, cioè quali VM far partire in subordine ad altre.
Figura 1: Architettura generale del Site Recovery Manager.
(Clicca per ingrandire)
4. VMware NSX
Come è stato già più ampiamente descritto da un precedente articolo di questa stessa rubrica il prodotto VMware NSX è sostanzialmente una piattaforma software integrata con vSphere che è in grado di costruire all'interno del datacenter una completa infrastruttura di rete virtualizzata, totalmente indipendente dalla rete di trasporto fisica sottostante. La sua realizzazione si poggia su due elementi fondamentali:
- Una tecnica di Network Overlay che permette di creare dei domini L2 indipendenti dalle generiche caratteristiche L2/L3 della rete fisica di accesso al datacenter. Nel caso di NSX questa tecnica fa uso delle VXLAN (RFC 7348).
- Il posizionamento delle funzioni di data plane per il Logical Switching (LS), il Distributed Logical Routing (DLR) e il Distributed Firewall (DFW) all'interno dell'hypervisor di ciascun host ESXi del datacenter, realizzando così funzioni di rete e di security distribuite, flessibili e altamente scalabili.
VMware NSX in pochi anni ha subito vari interessanti miglioramenti attraverso i rilasci delle versioni 6.x (attualmente siamo in 6.3) ma in particolare per gli scopi attinenti alle strategie di Disaster Recovery, quelle che ci interessano in questo articolo, la caratteristica più interessante è certamente quella denominata Cross-vCenter, introdotta dalla versione 6.2.
Figura 2: NSX impone una struttura di rete logica sopra la struttura di rete fisica.
(Clicca per ingrandire)
In tutte le versioni precedenti alla 6.2 l'infrastruttura di NSX si sovrapponeva a quella di vSphere con un limite ben preciso, stabilendo cioè una relazione uno a uno tra il gestore delle risorse vSphere (l'appliance vCenter) e il gestore delle risorse NSX (l'appliance NSX Manager). Questo significava poter costruire delle strutture di logical switching, logical routing e di security, separate per ciascun vCenter. Poichè una soluzione di Disaster Recovery si articola tipicamente in due siti geografici separati, ciascuno amministrato dal suo vCenter, è facile capire le difficoltà intrinseche ad una tale limitazione.
La soluzione Cross-vCenter della versione 6.2 consente proprio di superare questo limite dell'ambito di manovra di NSX. In un ambiente multi-vCenter viene mantenuta la relazione uno a uno tra NSX manager appliance e vCenter appliance ma il pool degli NSX managers viene strutturato gerarchicamente nominando un primario e centralizzando le funzioni di control plane dell'intera infrastruttura. Il risultato è un'architettura di virtual networking a due livelli: quella che si relaziona ancora al singolo vCenter tramite il corrispondente NSX manager e quella che si relazione all'intero ambiente multi-vCenter attraverso la gestione del primario. A questo nuovo livello è possibile costruire degli oggetti di networking (Logical Switches, Distributed Logical Routers e Distributed Firewall) di tipo Universale, cioè con un ambito di operatività che abbraccia tutta l'infrastruttura. Questo comporta ad esempio la possibilità di creare dei domini L2 che si possono estendere al massimo possibile, attraversando tutti gli host indipendentemente dal vCenter a cui sono stati registrati.
Figura 3: La soluzione Cross-vCenter di NSX 6.2 consente la definizione di oggetti “Universal”.
(Clicca per ingrandire)
5. Le integrazioni tra SRM e NSX per il Disaster Recovery
Come già detto nell’introduzione mentre una soluzione di Disaster Recovery tradizionale punta al recupero di tutti i carichi di lavoro sul sito secondario in termini di risorse di calcolo e di storage, il recupero delle infrastrutture di rete e di security costituisce certamente un problema più complesso. In particolare le difficoltà sono le seguenti: replicare la stessa topologia di rete L2 e L3 tra i due siti, replicare le stesse politiche di sicurezza tra i due siti. La seconda difficoltà è legata al fatto che le policies di sicurezza dipendono in buona parte dall'indirizzamento IP, questo significa che da una parte il remapping degli indirizzi comporterebbe una riformulazione delle regole di sicurezza e dall'altra la capacità di conservare tra i due siti esattamente gli stessi indirizzamenti è strettamente legata alla possibilità di estendere con una qualche tecnologia fisica i segementi L2 su tutto il datacenter.
E’ proprio nella soluzione di queste difficoltà che risiede il grosso vantaggio dell’uso concomitante di SRM con l’infrastruttura di rete virtuale creata da NSX. Infatti in uno scenario di Full Failure attraverso la funzionalità di Cross-vCenter descritta nella sezione precedente NSX 6.2 è in grado di preservare esattamente le stesse reti L2 in quanto gli Universal Logical Switch hanno un ambito di estensione che può comprendere sia il sito protetto che il sito di recovery. Questo consente di fatto di recuperare nel sito secondario l'intera topologia logica di networking, dunque tutti i servizi di rete inclusi i DLR e le regole di firewall (DFW). Gli automatismi utilizzati migliorano in definitiva i parametri RPO e RTO.
E’ importante anche osservare che in una soluzione DR che comprende NSX è possibile gestire con un buon livello di continuità (basso RTO) anche uno scenario di Partial Failure delle risorse del sito protetto in quanto le risorse sopravvissute e quelle ripristinate sul sito secondario possono continuare a comunicare sulla stessa topologia di rete. Infine si ottengono grandi vantaggi anche nella gestione delle più semplici strategie di Disaster Avoidance e di Planned Migration in quanto in tali casi è possibile sfruttare i vantaggi dell’uso della cosiddetta Long-distance vMotion, la migrazione a caldo delle Virtual Machine su una rete di vMotion L3 con caratteristiche di link geografico (RTT massimo di 150 ms e banda minima di 250 Mbps) messa a disposizione da vSphere 6.x.
Figura 4: L’integrazione tra SRM e NSX garantisce la conservazione dell’indirizzo IP delle VM.
(Clicca per ingrandire)
Ovviamente questa integrazione si traduce anche in automatismi di configurazione. Ad esempio su SRM 6.1 è possibile definire un Network Mapping tra il sito primario (protected) e il sito secondario (recovery) in modo tale che le macchine virtuali ripristinate possano connettersi ad una rete L2 stabilita dal piano di recovery. La rete può essere una VLAN (Distributed Virtual Portgroup) o una VXLAN (NSX Logical Switch). In quest’ultimo caso il mapping è automaticamente individuato e configurato da SRM sulla stessa rete L2 di provenienza messa a disposizione da NSX. E’ chiaro il vantaggio di questo automatismo sulle operazioni di pianificazione.
Figura 5: Network Mapping implicito eseguito automaticamente da SRM sui Logical Switch Universali di NSX.
(Clicca per ingrandire)
6. Descrizione di uno scenario di integrazione
Proviamo ora a descrivere uno scenario di integrazione tra SRM e NSX.
Lo scenario è costituito da due siti indipendenti collegati tra loro da una qualsiasi rete L3. Sulla rete fisica di accesso al datacenter nei due siti non ci sono richieste particolari se non quella del supporto di una MTU=1600 per consentire a VMware NSX di costruire e trasportare correttamente la rete logica. Anche per le risorse di storage non ci sono richieste o restrizioni, i sistemi di storage nei due siti possono essere di qualunque tipo (tra quelli supportati da vSphere) e completamente indipendenti tra loro.
Entrambi i siti sono dotati di host e cluster vSphere, tipicamente un cluster di management e uno o più cluster computazionali. Ciascun sito ha un vCenter che lo gestisce, un SRM server e una vSphere Replication Appliance. Il datacenter complessivamente ha una infrastruttura NSX Cross-vCenter, con un NSX Manager Primario (e lo Universal Controller Cluster) sul sito Protetto e un NSX Manager Secondario sul sito di Recovery. Su questa infrastruttura viene definita una Universal Transport Zone, uno o più Universal Logical Switches e uno Universal DLR. Su ciascun sito è presente un NSX Edge per il routing N-S.
I componenti dell'ambiente sotto protezione (virtual machines) vengono posizionati sullo Universal Logical Switch connesso allo Universal DLR. Le politiche di sicurezza vengono implementate utilizzando le regole dello Universal DFW. Questo assicura che l'intera rete logica per le risorse sotto protezione si estenda senza soluzione di continuità su entrambi i siti. L'estensione del dominio L2 su entrambi i siti garantisce lo stesso schema di indirizzamento e quindi la conservazione degli indirizzi IP all'evento di failure. Di conseguenza si conserveranno intatte anche le politiche di sicurezza.
Poichè le configurazioni degli oggetti di tipo Universal sono eseguiti sul Primario ma sincronizzati sul Secondario la perdita del Primario (e dello Universal Controller Cluster) in un failure del sito protetto non ha conseguenze sulle configurazioni della rete logica delle risorse sotto protezione. Il Secondario può essere promosso a Primario e gestire il deployment di un nuovo Universal Controller Cluster.
Una delle caratteristiche di un datacenter interconnesso su due site che richiede una certa attenzione per essere adeguatamente trattato è il problema del routing Nord-Sud, ovvero del routing di ingresso/uscita al/dal datacenter. A questo scopo NSX 6.2 introduce una funzionalità chiamata Site Egress Traffic Localization che consente al traffico di uscire sempre dal router del suo stesso site attraverso l'uso di un parametro preassegnato al site detto Locale-ID. A tal fine dovrà essere distribuita un'appliance DLR per lo Universal Distributed Router su ciascun sito e farla parlare con una corrispondente NSX Edge Gateway appliance sullo stesso sito (che a sua volta parlerà con il suo router fisico di uscita dal datacenter). La soluzione a questo punto consiste nell'associare un identificativo univoco del site (Locale-ID) alle rotte costruite su quel site e comunicate al Controller Cluster. Quest'ultimo le ridistribuirà agli host rispettando l'associazione al sito (ogni host riceverà dal controller tutte e sole le rotte relative al proprio sito).
Figura 6: Schema di datacenter interconnesso su due sites che illustra il Local Egress.
(Clicca per ingrandire)
In uno scenario di Disaster Recovery del tipo descritto sopra si possono distinguere due approcci per controllare il traffico N-S (il traffico di ingresso/uscita al/dal datacenter):
- Redirezione del traffico in base al Locale-ID. Viene creato un Edge per ogni sito, uno Universal DLR, un Logical Router Control VM per ogni sito collegato al rispettivo Edge da uno Universal Logical Switch di transito, uno per ogni sito, definendo due LIF (Logical Interface) distinte. Ogni Logical Router Control VM stabilisce il peering OSPF/BGP con il rispettivo Edge nel suo sito. Tutti gli host del datacenter (di entrambi i siti) ricevono lo stesso Local-ID, quello del sito protetto (Primary NSX Manager), dunque il traffico in uscita passerà esclusivamente dal sito protetto. Una route prefix list (di tipo deny) non consente al Logical Router Control VM del sito protetto di annunciare le rotte interne, dunque il traffico in ingresso viene dirottato interamente sul sito protetto.
- Redirezione del traffico attraverso l'uso dei costi e del routing dinamico. Viene creato un Edge per ciascun sito, uno Universal DLR, ma un solo Logical Router Control VM (sul sito protetto) collegato ad entrambi gli Edges attraverso un unico Universal Logical Switch di transito. In questo caso ovviamente non viene utilizzato il Local-ID nè una route prefix list. Invece il Logical Router Control VM stabilisce il peering con entrambi gli Edges e scambia rotte con entrambi. Quello che determina il fatto che il traffico in ingresso e in uscita passino per il sito protetto è la scelta delle metriche sulle rotte. Queste dovranno essere stabilite in modo tale che i best path siano sempre quelli che passano per l'Edge del sito protetto.
In relazione ai due approcci descritti sopra e ai pro e contro di ciascuno di essi si possono distinguere due scenari di Disaster Recovery:
- Planned Migration/Partial Application Failover. E' possibile costruire dei piani di recovery parziali, che cioè attivino solo alcune risorse nel sito di recovery e non tutte. Un piano del genere ovviamente è utilizzabile anche per una migrazione pianificata. In questi casi le risorse si trovano a utilizzare nei due diversi siti la stessa infrastruttura logica di rete senza discontinuità. Il routing in ingresso e in uscita continuerà comunque ad essere garantito attraverso il sito protetto (che è ancora funzionante) sia nel caso dell’approccio che fa uso del Local-ID e della funzionalità di Local Egress, sia nel caso dell’approccio che fa uso del routing dinamico.
- Full Application Failover. In risposta ad un failure completo di tutte le risorse del sito protetto tutte le applicazioni dovranno essere ripristinate sul sito di recovery. In questo caso l'approccio che utilizza il Locale-ID e la funzionalità di Local Egress è preferibile. Si ottiene un routing corretto ridefinendo un Local-ID per il nuovo sito (gestito dall'appliance NSX Manager Secondary) e ridefinendo al contempo anche le prefix list per il routing in ingresso in modo appropriato. Lo scenario che invece rende più appropriato l'approccio del routing dinamico è quello del failure dell'uplink di uscita dal sito protetto (NSX Edge o i router fisici, o i collegamenti tra essi). In questo caso le rotte sia di ingresso che di uscita dal sito vengono perse dal DLR locale al sito, non vengono più comunicate al controller cluster che a sua volta non le comunica più ai singoli host. Le uniche rotte che sopravvivono sono quelle che redirezionano verso il gateway del sito di recovery, su cui a questo punto potrebbe risultare conveniente migrare tutte le risorse (best path).
7. Conclusioni
Nell’affrontare il problema generale di un piano di Disaster Recovery abbiamo messo in luce la difficoltà di preservare nel sito di recovery la topologia di rete con i piani di indirizzamento e conseguentemente le politiche di sicurezza del sito sotto protezione. Nell’integrazione tra i prodotti SRM e NSX abbiamo individuato la soluzione migliore a questo problema. Il punto chiave di questa soluzione sta nella capacità di NSX di preservare intatti i domini L2 sul sito di recovery al momento del failure del sito protetto. Su questi stessi domini SRM posizionerà automaticamente le VM ripristinate offrendo loro esattamente lo stesso ambiente di rete e lo stesso contesto di sicurezza. E’ importante sottolineare che gli oggetti di NSX perduti nel failure non compromettono l’azione del piano di recovery attuato da SRM in quanto sono tutti oggetti del control plane, le funzioni di data plane permangono intatte e funzionanti perchè vengono svolte interamente dagli host (hypervisor). La separazione tra control plane e data plane è cruciale in quanto permette di ripristinare i componenti di NSX nel sito secondario mentre l’infrastruttura continua regolarmente a funzionare.