HYPERV Replica

 Ecco un po di appunti sparsi sulla replica HyperV tra host in gruppo di lavoro, ed in particolare sulla gestione.

La replica hyperv puo avvenire tra host in dominio o in gruppo di lavoro (workgroup). Tra host in gruppo di lavoro, come nel nostro caso, e necessaria una parte preliminare piu articolata, che consiste nella creazione dei certificati, che vanno poi installati sui rispettivi host.

La scelta di lasciare gli host hyperV in gruppo di lavoro e’ relativa alla sicurezza, x evitare che con le credenziali di dominio si possa accedere anche agli host ed agli storage dove sono salvate le VM.

E’ possibile generare i certificati da qualsiasi PC o server.

Nel nostro caso ho generato i certificati dal mio PC, con Windows 10. I certificati coinvolti solo quella della CA authority (il mio PC, in questo caso) ed i due certifcati creati per l’host HYPERV_A e per HYPERV_B.

GENERAZIONE DEI CERTIFICATI

Ecco i comandi da eseguire per generarli (powershell):

GENERAZIONE DEL CERTIFICATO CA

New-SelfSignedCertificate -Type "Custom" -KeyExportPolicy "Exportable" -Subject "CN=HyperVCA" -CertStoreLocation "Cert:\LocalMachine\My" -KeySpec "Signature" -KeyUsage "CertSign" -NotAfter (Get-Date).AddMonths(240)

In risposta al comando viene restituito il thumbprint del certificato ed il common name. Dovremo utilizzare il thumbprint nei comandi successivi

689A1887D9891AFE4B756118C8E04DC23E6DFE44  CN=HyperVCA

GENERAZIONE CERTIFICATO HYPERV_A

New-SelfSignedCertificate -type "Custom" -KeyExportPolicy "Exportable" -Subject "CN=HYPERV_A" -CertStoreLocation "Cert:\LocalMachine\My" -KeySpec "KeyExchange" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2") -Signer "Cert:LocalMachine\My\689A1887D9891AFE4B756118C8E04DC23E6DFE44" -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -NotAfter (Get-Date).AddMonths(240)

GENERAZIONE CERTIFICATO HYPERV_B

New-SelfSignedCertificate -type "Custom" -KeyExportPolicy "Exportable" -Subject "CN=HYPERV_B" -CertStoreLocation "Cert:\LocalMachine\My" -KeySpec "KeyExchange" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2") -Signer "Cert:LocalMachine\My\689A1887D9891AFE4B756118C8E04DC23E6DFE44" -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -NotAfter (Get-Date).AddMonths(240)

1CC38C74D619838E8D6DA1708ED79CAB2FAF0D8A  CN=HYPERV_A

106EB8002EFB7424254959DBD49EAC2F22F80E69  CN=HYPERV_B

ESPORTAZIONE DEI CERTIFICATI

Per esportare i certificati , aprire la console dei certificati (mmc – certificate snapin – computer – Cartella personal). Dentro dovrebbero esserci tutti e tre i certificati creati sopra. Esportare il certificato della CA come .cer (non esportare la chiave privata), mentre esportare quelli relativi agli host con la chiave privata, in formato .pfx (verrà chiesto di usare una password, necessaria successivamente per importarli).

IMPORTAZIONE CERTIFICATI SULL’HOST

I certificati quindi vanno importati sugli host.

HYPERV_A

HYPERVCA, HYPERV_A

HYPERV_B

HYPERVCA, HYPERV_B

Eseguire questi comandi per importarli

certutil -addstore -f Root "C:\hypervcert\HypervCA.cer"

certutil -f -p 11111111 -importpfx "c:\hypervcert\HYPERV_A_11111111.pfx"

– Disabilitare la verifica della revoca dei certificati digitando nel prompt dei comandi di tutti gli host Hyper-V:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\FailoverReplication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

IMPOSTAZIONI PRELIMINARI DELLA REPLICA

Affinché tutto il processo di replica funzioni correttamente (failover e replica inversa), è necessario configurare entrambi gli host come replica. Infatti, nel funzionamento normale una VM viene replicata dall’host principale verso l’host di replica. Quando viene effettuato un failover i ruoli degli host rispetto alla VM si invertono, facendo diventare host di replica quello che era l’host principale e viceversa.

FIREWALL

E inoltre importante che la porta 443 del firewall sia aperta e che la risoluzione dei nomi, soprattutto se attiva l’autenticazione tramite certificato, funzioni correttamente.

RISOLUZIONE NOMI

Affinché l’autenticazione tramite certificato funzioni correttamente, è fondamentale che il nome host venga sempre risolto correttamente. Per questo motivo ho preferito mettere il nome host dei rispettivi dentro al file hosts di Windows in system32\drivers\etc\.

IMPOSTAZIONI REPLICA

IMPOSTAZIONE HOST

Nella impostazioni di HYPERV scegliere CONFIGURAZIONE REPLICA, ABILITAZIONE REPLICA e USA AUTENTICAZIONE BASATA SU CERTIFICATI (HTTPS). In caso di host in dominio può andare bene anche la kerberos. Tenere presente che usando i certificati e’ possibile cifrare il traffico di replica e con Kerberos no.

REPLICA VM

Dopo aver configurato gli host occorre attivare la replica per le singole VM. Tasto destro sulla VM e scegliere abilitazione replica. Seguire la configurazione guidata. Quando parte la replica, è possibile scegliere come vogliamo fare la prima sincronizzazione (ES: tramite rete)

OPZIONI REPLICA

Le opzioni di replica disponibili da host primario e host di replica sono leggermente diverse

HOST PRIMARIO

FAILOVER PIANIFICATO

In caso di manutenzione dell’host primario, attiva la replica sul secondario. Per funzionare la macchina principale deve essere spenta. Questo consente di fare un ultimo allineamento della replica, senza che vengano persi dati. E’ possibile decidere se accendere o no la VM di replica.

SOSPENDI REPLICA

Mette in pausa la replica tra i 2 host

VISUALIZZA STATO REPLICA

Controlla lo stato della reòlica

RIMUOVI REPLICA

Cancella la replica definitivamente

 

HOST REPLICA

FAILOVER

Si tratta dell’unplanner failover. Consente di attivare la replica in caso di blocchi improvvisi dell’host primario o VM principale. E’ una procedura di emergenza.

TEST FAILOVER

Verifica il corretto funzionamento della replica. Viene creata una macchina con il suffisso TEST, per verificare che tutto funzioni correttamente.

ESTENDI REPLICA

Consente di estendere la replica ad un terzo host

SOSPENDI REPLICA

Mette in pausa la replica tra i 2 host

VISUALIZZA STATO REPLICA

Controlla lo stato della reòlica

RIMUOVI REPLICA

Cancella la replica definitivamente

GESTIONE REPLICA – COME FARE UN FAILOVER

La funzione più utile è il planned failover (PFO) utile per “attivare” le VM sull’host di replica quando è necessario effettuare una manutenzione sull’host principale. In sintesi il processo del PFO e’ il seguente:

VM1_HYPERV_A su host HYPERV_A e replicata su HYPERV_B, come VM01_HYPERV_B

A regime la macchina in produzione è VM1_HYPERV_A ed è replicata su VM01_HYPERV_B.

Attivo il PFO: spengo VM1_HYPERV_A, le ultime modifiche sono riportate su VM01_HYPERV_B.

Si accende VM01_HYPERV_B e da ora in poi è lei la macchina di produzione.

In questo momento VM1_HYPERV_A e’ spenta e sto facendo le operazioni di manutenzione necessarie su HYPERV_A (l’host).

Dopo aver terminato le operazioni di manutenzione ho riacceso l’host HYPERV_A e sono pronte a riaccendere VM1_HYPERV_A. Per farlo ho la possibilità di invertire la replica o annullare il failover.

REPLICA INVERSA

Inverte il senso di replica. In pratica trasmettiamo le modifiche di VM01_HYPERV_B (produzione) a VM01_HYPER01 (ex produzione). Per concludere e riportare tutto alle condizioni iniziali, rieseguire un PFO ed una nuova REPLICA INVERSA.

ANNULLA FAILOVER

Consente di tornare indietro alla situazione precedente al failover. Se annulliamo il failover VM01_HYPERV_A ritornerà ad essere la VM di produzione e VM01_HYPERV_B tornerà ad essere la replica. Tutte le modifiche avvenute su VM01_HYPERV_B andranno perdute. Operazione caldamente SCONSIGLIATA in casi di domain controller, database ecc. ecc.

NOTE

La replica HYPERV è essenzialmente una soluzione di disaster recovery e non propriamente di backup o business continuity come un cluster. Per fare un failover pianificato (PFO) è OBBLIGATORIO spegnere le VM. La soluzione più indolore e rapida consiste nel tenere spenta la macchina di replica. Se non la si accende e’ possibile effettuare un ANNULLA FAILOVER senza perdere nulla in termini di informazioni, ed e’ molto veloce. E’ molto importante tenere presente il discorso dei checkpoint (production e standard), per evitare di perdere dati o introdurre errori.

 

 

 

ABILITARE AMMINISTRAZIONE REMOTA DEGLI HOST HYPERV DA UN CLIENT

E’ possibile installare la console Hyperv sul proprio PC per gestire direttamente gli host hyperv senza collegarsi direttamente al server. Per farlo occorre eseguire una serie di comandi:

SERVER

Sul server HYPERV al quale collegarsi eseguire i seguenti comandi

-        netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=Yes

-        netsh advfirewall firewall set rule group="Remote Event Log Management" new enable=Yes

FACOLTATIVO

-        netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes

-        netsh advfirewall firewall set rule group="Remote Volume Management" new enable=Yes

CLIENT

Siccome stiamo parlando di server in workgroup, probabilmente non useranno gli stessi DNS del client. Per questo motivo il primo passaggio e' quello di aggiungere i nomi dei server al file hosts (C:\windows\system32\drivers\etc)

Dalla macchina CLIENT da cui connettersi al server in questione eseguire i seguenti comandi

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "HYPERV"

Enable-WSManCredSSP -Role client -DelegateComputer "HYPERV"

NOTA

Se il comando sopra non dovesse funzionare, si puo provare con quello sotto, generico per tutti gli host ed in seconda battuta restringerlo solo agli host necessari

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "*" - questo comando funziona x tutti gli host

N.B. Nel mio caso sul CLIENT ho dovuto avviare manualmente il servizio "Gestione remota Windows (WS-Management)" affinche il primo comando avesse esito positivo

AGGIUNTA DEGLI HOST IN GPEDIT.MSC

Configurazione computer > Modelli amministrativi > Sistema > Delega di credenziali > Consenti delega credenziali nuove solo con autenticazione server NTLM

wsman/HYPERV

A questo punto e' necessario aprire la console di HYPERV, aggiungere l'host a cui collegarsi e cliccare sulla casella "CONNETTI COME ALTRO UTENTE" ed inserirlo nel formato HYPERV\username

 

HYPERV CHECKPOINT

In HyperV esistono 2 tipologie di checkpoint: standard (crash consistent) e produzione (application consistent). E’ consigliato di usare i checkpoint standard solo in ambiente di test xche possono creare problemi con active directory e DB. In produzione è necessario utilizzare i checkpoint di produzione. Questi ultimi sono APPLICAZION CONSISTENT (il checkpoint effettua una richiesta ai provider VSS del guest). Con PFO non si presenta il problema perché viene effettuato lo switch a VM spenta. Nella situazione di un UNPLANNED FAILOVER (che si fa in situazioni di emergenza), bisogna cercare di ripristinare un APPLICATION CHECKPOINT, soprattutto se ci sono in ballo DB, AD ecc. ecc.

 

 

REFERENCE

https://itlabz10.tk/archives/1041

https://itlabz10.tk/archives/1025