VMware Site Recovery Manager (SRM) - Parte 2

Indice

• Introduzione

• Prerequisiti vSphere/vCenter per SRM

• Deploy OVF dell’appliance SRM: parametri critici

• Appliance Management Interface (:5480): gestione servizi e aggiornamenti

• Registrazione su vCenter: solution user, certificati, estensioni e ruoli

• Site pairing: regole, wizard, requisiti

• Hardening minimo: SSH, certificati, aggiornamenti

• Conclusione

Introduzione

VMware Site Recovery Manager (SRM) è una soluzione di disaster recovery integrata per ambienti vSphere: in pratica orchestri­zione dei flussi di recupero in caso di disastro. A partire dalla versione, SRM è fornito esclusivamente come appliance virtuale basata su Photon OS, con database embedded e SRA (Storage Replication Adapter) containerizzato. L’appliance SRM semplifica notevolmente l’installazione, la manutenzione e l’aggiornamento del sistema, eliminando la vecchia versione Windows dell’installer e riducendo i costi complessivi. In questo articolo descriviamo i requisiti fondamentali e i passaggi di configurazione necessari per installare e configurare SRM in modo coerente e chiaro.

Prerequisiti vSphere/vCenter per SRM

Per implementare SRM è necessario disporre di un’infrastruttura vSphere preesistente in ogni sito coinvolto. In particolare, è richiesto un server vCenter (appliance) sia nel sito di produzione che in quello di recupero. Entrambi i vCenter devono essere almeno in versione 7.0 o successive, così come gli host ESXi comunicanti con essi. SRM supporta le edizioni Standard, Enterprise, Enterprise Plus ed Essentials Plus di vSphere. In pratica, per avviare il deploy dell’appliance SRM serve una coppia di vCenter attivi (uno in ogni site) con i relativi nodi ESXi compatibili.

Nell’architettura tipica, ogni sito include un vCenter Server Appliance collegato a uno (o più) host ESXi, più l’appliance SRM installata su un host dello stesso cluster. I due siti SRM devono infine comunicare tra di loro. Il diagramma ASCII seguente illustra lo scenario base con due siti, ciascuno dotato di vCenter e di SRM:

Dal punto di vista di sicurezza, entrambi i vCenter fanno parte di uno stesso dominio SSO o di domini SSO affidati, e SRM utilizza il vCenter Single Sign-On per autenticarsi e operare. In vSphere 7.0 in poi, si consiglia di usare l’Enhanced Linked Mode se servono più vCenter gestiti in un unico dominio SSO, ma in ogni caso SRM richiede un solo vCenter locale per sito di recupero.

Deploy OVF dell’appliance SRM: parametri critici

Una volta soddisfatti i prerequisiti, si procede al deploy della Appliance SRM tramite OVF. Durante il wizard di import è essenziale configurare correttamente tutti i parametri richiesti. In particolare verrà chiesto di specificare: nome della VM SRM; configurazione CPU (2 o 4 vCPU a seconda della dimensione dell’ambiente); password di root (OS) e password dell’utente admin (interfaccia appliance); password del database interno; indirizzo NTP e parametri di rete (DNS, default gateway, indirizzo IP e subnet mask). Una volta completata questa configurazione, l’appliance risulta pronta per il primo avvio.

A livello hardware, le specifiche minime dell’appliance SRM richiedono risorse modeste (tipicamente una o due CPU virtuali, qualche decina di GB di disco e almeno 4–8 GB di RAM), ma possono variare in base all’installazione e alle dimensioni del database interno. Ad esempio, per ambienti più grandi si può aumentare la memoria e la capacità del disco. In ogni caso l’installazione dell’OVF avviene come con qualunque altra macchina virtuale: il template SRM è preconfigurato e contiene già il sistema operativo Photon OS e il database preinstallati.

Appliance Management Interface (:5480): gestione servizi e aggiornamenti

Dopo il deploy, la gestione post-installazione dell’appliance SRM avviene tramite l’Appliance Management Interface, accessibile via browser all’indirizzo https://<IP_o_FQDN_SRM>:5480 . Questa interfaccia dedicata consente le operazioni chiave sulla VM SRM: avviare o arrestare i servizi SRM, registrare l’appliance con vCenter, applicare aggiornamenti software, e gestire le impostazioni di sistema (password, certificati, SSH). In pratica, ogni volta che serve fermare o far ripartire i servizi interni di SRM (per manutenzione o troubleshooting), lo si può fare comodamente da qui.

Per quanto riguarda gli aggiornamenti, l’Appliance Management Interface permette due modalità: installare un update a partire da un file ISO scaricato manualmente (da caricare via CD-ROM virtuale) oppure scaricare e installare direttamente gli aggiornamenti dal repository online VMware (se l’appliance ha accesso a Internet). In entrambi i casi, il processo è guidato via UI e assicura che l’appliance resti aggiornata. Riassumendo: la console su :5480 è il nodo di controllo principale per monitorare lo stato di SRM e mantenerne il software aggiornato senza ricorrere a linea di comando.

Registrazione su vCenter: solution user, certificati, estensioni e ruoli

Il passaggio successivo è registrare l’appliance SRM con il vCenter Server locale. Durante questa operazione SRM crea un account di servizio speciale (detto solution user) nel dominio Single Sign-On di vCenter, basato su credenziali certificate. Il solution user è il mezzo con cui SRM si autentica in vCenter per eseguire operazioni di failover/test, come interrogare l’inventario, personalizzare indirizzi IP delle VM, e avviare task sul vCenter. Il certificato del solution user viene generato automaticamente durante la registrazione, garantendo comunicazioni sicure tra SRM e vCenter.

Nel dettaglio, il wizard di registrazione richiede di fornire l’indirizzo del Platform Services Controller (o direttamente del vCenter con SSO embedded in 7.x) e le credenziali di un amministratore SSO (ad esempio administrator@vsphere.local). SRM si collega dunque al PSC e presenta la lista dei vCenter disponibili; si seleziona quello locale e si avvia la registrazione. Durante il processo SRM crea un’estensione unica nel vCenter per sé stesso, registra il servizio nel dominio SSO, e popola il vCenter con ruoli e privilegi dedicati a SRM. Al termine, SRM è in grado di dialogare con vCenter come un client integrato: viene creato un plug-in nella Web Client che consente anche di accedere direttamente alla console SRM dal client vSphere, e compariranno ruoli predefiniti (e relative privilege) per operare su Recovery Plan, Protection Group e altre risorse SRM.

Site pairing: regole, wizard, requisiti

Fatta la registrazione in locale, si procede a creare il pairing fra i due siti SRM (quello protetto e quello di recovery). SRM funziona sempre in coppia: ogni server SRM del sito di produzione si accoppia a uno e un solo SRM nel sito di recupero. Questa relazione 1:1 garantisce che le attività di protezione e failover siano coordinate tra i due siti. Per configurare il pairing serve un account con privilegi di administrator SSO sul sito remoto (ad esempio administrator@vsphere.local del vCenter di destinazione) e – importantissimo – i due SRM devono avere lo stesso extension ID di vCenter (di solito creato in fase di registrazione).

Nel client SRM (che si può aprire da vSphere Client o direttamente via browser su https://<IP_SRM>/dr), si clicca “New Site Pair” e si sceglie il tipo di pairing desiderato. Nel wizard si seleziona il vCenter locale ed eventualmente si indicano i parametri del PSC remoto (se i due vCenter sono in domini SSO diversi). Viene richiesto poi di inserire le credenziali dell’amministratore SSO del sito di destinazione, in modo che SRM possa connettersi e creare l’accoppiamento. Infine si seleziona dall’elenco l’appliance SRM remota con lo stesso extension ID e si completa il pairing. Una volta fatto, i due siti SRM risultano collegati: saranno mostrati come “paired” e potranno scambiarsi dati di configurazione (protection group, recovery plan, inventory mapping, ecc.).

Esempio di diagramma ASCII per illustrare il site pairing:

In sintesi, dopo il pairing ogni oggetto protetto (VM, datastore, rete) avrà il proprio equivalente nell’altro sito e SRM potrà orchestrare il failover. È importante ricordare che, per ogni site protetto, può esistere un solo site di recovery collegato (modello one-to-one).

Hardening minimo: SSH, certificati, aggiornamenti

Una volta attivi i servizi SRM, è consigliabile applicare alcune misure di sicurezza minime. Per prima cosa, se l’accesso SSH all’appliance non è necessario, va disabilitato: nella stessa Appliance Management Interface si trova l’opzione per abilitare/disabilitare l’accesso SSH alla shell (sotto tab Access). Mantenere SSH chiuso limita la superficie di attacco.

In secondo luogo, SRM è fornito con certificati self-signed di default. È buona pratica sostituirli con certificati firmati da un’autorità attendibile. Sempre nell’interfaccia di gestione (tab Certificates), si può generare una CSR o caricare un certificato di terze parti firmato. Questo garantirà che i client vSphere riconoscano l’appliance senza warning di sicurezza.

Infine, non va dimenticata la regolare applicazione di patch: come già visto, l’appliance SRM permette di caricare gli aggiornamenti tramite ISO o repository online. Assicurarsi periodicamente di installare questi aggiornamenti chiude falle note ed evita problemi di compatibilità. In breve, disabilitare servizi non necessari (SSH), installare certificati attendibili e mantenere l’appliance aggiornata contribuisce a un hardening di base efficace per SRM.

Conclusione

Abbiamo visto come installare e configurare SRM partendo dai prerequisiti base fino alle configurazioni di pairing e sicurezza. I punti chiave sono avere un vCenter 7.0+ in ciascun sito, usare la nuova Appliance SRM con OVA configurato correttamente, registrarla con vCenter (solution user, estensione e ruoli) e infine accoppiare i siti tramite il wizard Site Pair. Con questo approccio discorsivo e i dettagli tecnici derivati dalle slide ufficiali, l’implementazione di SRM risulta più chiara: ricordando sempre di disabilitare SSH inutile, installare certificati firmati e applicare gli aggiornamenti. Seguendo questi passaggi, gli amministratori di infrastrutture virtuali possono garantire un’attivazione di SRM solida e pronta per gestire piani di ripristino affidabili.