VMware Site Recovery Manager (SRM) - Parte 1

Indice

1. Cos'è SRM: orchestratore DR per ambienti vSphere

2. Architettura SRM: componenti chiave, flussi di comunicazione, REST API

3. Recovery, failover, reprotect: come funziona l'orchestrazione

4. Topologie DR supportate (active-passive, bidirectional, shared recovery site, active-active con storage replicato, SRM for Hyperscalers, DRaaS su VMware Cloud)

5. Integrazioni (vRealize Orchestrator, NSX Multisite e NSX Federation)

6. Licensing (tipi di licenze, limitazioni e note)

Introduzione

VMware Site Recovery Manager (SRM) è una soluzione di business continuity e disaster recovery che orchestrates the recovery process in vSphere environments. In pratica SRM non si limita alla sola replica dello storage: coordina l’intero flusso di failover e failback, gestendo inventari, reti, politiche di protezione e automazione dei workflow. Ciò include la possibilità di eseguire test di recovery in isolamento, failover pianificati o di emergenza e persino il reprotect automatico (ribaltamento del flusso di replica). In questo modo SRM riduce drasticamente gli errori manuali e il Recovery Time Objective (RTO), andando ben oltre la semplice sincronizzazione dei dati.

Cos'è SRM: orchestratore DR per ambienti vSphere

SRM è il disaster recovery orchestrator di VMware per ambienti vSphere. A differenza di una soluzione che replica solo lo storage, SRM automatizza l’intero piano di recupero: definisce gruppi di protezione (Protection Groups), pianifica il boot order delle VM, personalizza gli indirizzi IP in uscita, e gestisce le dipendenze applicative. In questo modo un’intera infrastruttura virtuale può essere spenta in sicurezza in un sito primario ed essere avviata nell’altro secondo uno script prestabilito. Ad esempio, la funzionalità Reprotect di SRM inverte automaticamente i ruoli tra sito primario e sito secondario al termine del failover: viene invertita la replica storage e il piano di recovery originale si ribalta, rendendo il sito iniziale nuovamente il sito di recupero. In sostanza SRM funge da orchestratore centrale, coordinando repliche array-based o vSphere Replication, test in reti isolate e perfino failback in produzione, con una singola interfaccia e API dedicate.

Architettura SRM: componenti chiave, flussi di comunicazione, REST API

Un deployment SRM tipico prevede due siti: un Protected Site (produzione) e un Recovery Site. In ciascun sito è presente un’istanza di SRM installata come appliance virtuale, insieme a un vCenter Server locale. I due SRM vengono accoppiati (site pairing) in modo che comunichino fra loro: ciascun SRM opera come un servizio registrato nel vCenter locale ed è abilitato dalla coppia di credenziali dell’SSO di vCenter. Ogni appliance SRM è basata su Photon OS, include un database embedded e fornisce un’interfaccia di gestione semplificata: ad esempio, è possibile amministrarla via browser all’indirizzo https://<IP_o_FQDN_SRM>/5480 per compiti come l’aggiornamento o il link a vCenter. L’appliance SRM espone anche una REST API Gateway con autenticazione, permettendo di automatizzare operazioni di pairing, protezione, recupero, replica e monitoraggio.

In termini di componenti: SRM si interfaccia sia a VMware vSphere Replication (replica host-based) sia ad Array-Based Replication via i Storage Replication Adapter (SRA). Gli SRA sono plugin forniti dal vendor di storage che traducono le chiamate SRM in comandi di replica sul SAN. Ad esempio uno Storage Replication Adapter “translates SRM requests into commands that the storage array can execute”. Il risultato è che SRM scopre i dispositivi replicati (Array Pairs) e li mappa in “Datastore Groups” consultando il vCenter. Una volta accoppiati i siti, SRM utilizza le API di vCenter Single Sign-On per comunicare in modo sicuro ed eseguire i task (spegnimenti, avvii, riconfigurazioni IP, ecc.) durante le operazioni di test o failover.

Un aspetto fondamentale dell’architettura SRM è l’uso di mappature di inventario (inventory mappings). Queste definiscono dove risiederanno le VM recuperate sul sito di DR: ad esempio mapping di cluster/host, cartelle VM, network e politiche di storage. SRM mantiene delle placeholder VM sui datastores di recovery: questi oggetti senza dischi allegati rappresentano ciascuna VM protetta. In caso di failover la placeholder VM viene rimpiazzata dal clone replicato della VM reale, assicurando così che il recovery plan ripristini le VM al corretto percorso e con i corretti payload di memoria e dischi.

Recovery, failover, reprotect: come funziona l'orchestrazione

Lo schema di automazione in SRM si basa sui Recovery Plan. Un recovery plan aggrega gruppi di protezione (Protection Groups) e definisce l’ordine di avvio delle VM, le politiche di sincronizzazione e i comandi personalizzati. È possibile eseguire il piano in modalità test per simulare il failover senza impattare la produzione: SRM mette in piedi un ambiente di rete isolato sul sito di recovery, ospitando le VM in placeholder per verifica. In test mode SRM può creare reti di test isolate (switch standard senza uplink) o usare port group dedicati, garantendo che i workload ripristinati non interferiscano con la produzione. Al termine del test si esegue un’operazione di cleanup che elimina VM e risorse create.

Nella modalità di recovery vero e proprio, SRM procede in modo sequenziale: effettua eventuali sincronie finali, forza lo shutdown controllato delle VM sul sito protetto (in caso di planned migration) e poi avvia le VM replicate sul sito di recovery secondo l’ordine definito. In questo processo le placeholder VM vengono sostituite dalle VM recuperate, caricate dai datastore replicati. Grazie ai mapping definiti, SRM rialloca CPU/host, storage e rete alle VM recuperate, e personalizza gli indirizzi IP se necessario per adattarsi alla subnet di destinazione.

Dopo il failover è possibile eseguire un failback. SRM offre la funzione reprotect, che “storage and VM replication is reversed” e inverte il piano di recovery originale. In pratica si crea un recovery plan inverso: il sito secondario diventa quello primario, e viceversa, permettendo di riportare rapidamente le VM al sito originario (ad esempio dopo la risoluzione di un guasto o per manutenzione). Questo flusso di rifailover (“failback”) è automatizzato da SRM, rendendo semplice il ripristino dello stato normale. In conclusione, SRM automatizza l’intero ciclo DR: dal test, al failover, al reprotect, minimizzando errori umani e riducendo i tempi di inattività.

Topologie DR supportate

SRM supporta diverse topologie di disaster recovery per adattarsi a esigenze differenti. Le principali sono:

• Active-Passive (siti attivi-passivi): un sito (Primary) contiene i workload in produzione, e l’altro (Recovery) resta in stand-by con risorse dedicate. È il modello più semplice: le risorse DR sono pre-allocate ma inattive fino al failover. Ha il vantaggio della semplicità ma richiede costi maggiori per mantenere hardware pronto.

• Bidirectional (siti attivi bidirezionali): entrambi i siti ospitano workload differenti, e ognuno agisce come DR dell’altro. In caso di failover di sito A, il sito B scende parte delle macchine A e viceversa. Questo modello sfrutta le risorse in maniera efficiente (poiché entrambi i siti sono parzialmente attivi) ed è più economico del modello dedicato. SRM gestisce due recovery plan distinti (A→B e B→A). Durante un failover bidirezionale, carichi non critici possono essere sospesi per liberare risorse.

• Shared Recovery Site (sito condiviso): più siti protetti (anche fino a 10) vengono associati a un singolo sito di recovery condiviso. Questo è utile in scenari ROBO (remote office) o multi-tenant cloud: diversi uffici o clienti proteggono le VM su un unico data center di DR, che ospita un’istanza SRM per ogni sito protetto. La topologia è one-to-many: il sito shared deve avere sufficiente capacità a livello aggregato, ma permette di risparmiare sui costi totali di recovery (in media non tutti i siti falliscono simultaneamente).

• Active-Active con storage replicato (stretched cluster): entrambi i siti sono attivi e condividono storage replicato in tempo reale (es. vSAN Stretched Cluster o SAN Metro). In questo scenario le VM sono sempre attive su entrambi i siti, e SRM non è necessario per il normale bilanciamento o vMotion cross-site. Tuttavia in caso di separazione di rete (split-brain) o guasto totale, SRM può comunque coordinare un recovery plan. Questo modello offre RTO minimi (quasi zero) grazie alla sincronizzazione sincrona, ma richiede una configurazione SAN complessa.

• SRM for Hyperscalers: SRM è supportato anche su soluzioni VMware gestite in cloud pubblici (“Hyperscalers”). Ad esempio VMware on Azure (AVS), Google Cloud VMware Engine (GCVE) o Oracle Cloud VMware Solution (OCVS) sono integrati come topologie supportate, estendendo il concetto di sito primario e di DR anche a questi ambienti cloud VMware.

• DRaaS su VMware Cloud (VMC on AWS): con VMware Site Recovery (basato su SRM) è possibile fornire DR-as-a-Service. In questa topologia, il sito protetto on-prem include SRM e vSphere Replication, mentre il sito di recovery è nel cloud VMC on AWS: VMware gestisce alberi, provisioning, patching e scaling del sito di DR, offrendo un’alternativa di DR nel cloud pubblico. Questa modalità è particolarmente utile per chi non dispone di un secondo data center fisico.

Ogni topologia ha pregi e difetti: Active-Passive è semplice ma meno efficiente in termini di costi, Bidirectional sfrutta meglio le risorse ma può richiedere squeeze dinamico, Shared Recovery conviene in multi-sede o in DRaaS, e Active-Active richiede infrastruttura avanzata (storage stretch) ma garantisce disponibilità continua.

Integrazioni

SRM si integra strettamente con altri prodotti VMware per estendere le capacità di orchestrazione:

• vRealize Orchestrator (vRO): SRM espone un plugin per vRO che permette di automatizzare operazioni comuni via workflow predefiniti. Ad esempio è possibile con vRO automatizzare la creazione di una VM protetta, la formazione di un Protection Group o l’esecuzione di Recovery Plan con un click. Per casi d’uso complessi (multi-step o eventi esterni) si può scrivere un workflow personalizzato usando l’API SRM REST.

• NSX Multisite e NSX Federation: SRM supporta il recupero di reti virtuali estese tramite NSX. Con NSX Multisite si gestiscono più siti da un unico cluster NSX-T: in questo modo le reti vengono replicate come entità unificate. Con NSX Federation si hanno più manager NSX con un/global manager, offrendo un “single pane of glass” su ambienti dislocati. A partire da NSX-T Federation 3.2.0, SRM consente di recuperare qualsiasi VM di management o compute senza limitazioni. In pratica, se l’ambiente utilizza NSX-T per networking e sicurezza, l’integrazione con SRM permette che i segmenti, le politiche di firewall e i load balancer siano anch’essi orchestrati durante il DR. Ad esempio, un NSX Federation consente che le VM mantengano IP e politiche simili dopo il failover, semplificando il ripristino di reti complesse.

In sintesi, si ricorre a vRO quando serve estendere la logica di orchestrazione con script o interazioni personalizzate; si sfrutta NSX Multisite/Federation per gestire le reti virtuali su più data center. La scelta dipende dallo stack: in un ambiente vSphere puro si può non usare NSX, ma in infrastrutture di rete software-defined l’integrazione SRM-NSX è altamente consigliata per recuperare anche i servizi di rete contestualmente alle VM.

Licensing: panoramica dei modelli disponibili

Il licensing di SRM è basato sul numero di VM protette. In passato esisteva un’opzione “per CPU”, ma oggi il modello principale è per VM. Viene definita protetta qualsiasi VM inclusa in un Protection Group di SRM. Esistono due principali edizioni: SRM Standard (incluso in vSphere Essentials Plus o in piccole installazioni) e SRM Enterprise (parte di suite avanzate). Le differenze tipiche sono i limiti di scala e le funzionalità incluse: per esempio SRM Standard supporta fino a 75 VM protette per sito, mentre Enterprise non ha limiti sul numero di VM. Inoltre, SRM Standard permette solitamente solo vSphere Replication, mentre l’edizione Enterprise abilita anche la replica array-based.

In termini pratici: in un setup unidirezionale (failover da A a B) servono licenze solo per le VM protette nel sito A, mentre in scenari bidirezionali occorrono licenze per le VM protette in entrambi i siti. Dopo un failover il concetto resta lo stesso: le licenze “per VM” originarie del sito primario possono essere riutilizzate nel sito di DR per il periodo di recupero. Se si prevede di gestire un failback, è bene ricordare che, nel momento in cui le VM vengono reprotette, quelle diventano “protette” al nuovo sito di origine e richiedono quindi una licenza (ma spesso le licenze mobili del modello per-VM vengono spostate con la VM stessa).

Inoltre, SRM Standard ha una particolarità di licensing: è possibile proteggere 75 VM per sito (150 totali tra due siti). Oltre questi limiti è necessario passare all’edizione Enterprise. (In pratica, SRM Enterprise può anche essere abilitato con licenze per-CPU come parte di vCloud Suite, ma il modello per-VM rimane il più usato.)

In sintesi, le linee guida sul licensing SRM sono: licenziare tutte le VM protette al sito di produzione, garantire vSphere/vCenter a entrambi i siti, e scegliere l’edizione (Standard vs Enterprise) in base alle scala e funzionalità richieste.

Conclusione

La scelta della topologia DR più adatta dipende da criteri come costi, performance attese e complessità operativa. SRM semplifica l’intero ciclo di vita del disaster recovery: dalla definizione delle politiche di protezione alla simulazione dei test, fino all’esecuzione automatica di failover e failback. L’automazione avanzata riduce errori e velocizza il Recovery Time Objective, mentre le integrazioni con vRO e NSX estendono il controllo di rete e processi. In conclusione, SRM fornisce una piattaforma centralizzata per orchestrare il DR in ambienti vSphere, mettendo a disposizione flussi di recovery completi e topologie flessibili secondo le esigenze di business.