Per lavoro ho da poco avuto l'occasione di collaborare con uno dei numerosi partner di VMware e con delle persone di VMware stessa per la progettazione e la successiva realizzazione di un'installazione del prodotto per la gestione dei piani di continuità operativi, il Site Recovery Manager | SRM.
La filosofia alla base del prodotto ha un fascino innegabile per chi mastica di informatica... immaginate la possibilità di trasferire un'intera infrastruttura virtuale in un altro luogo con pochi click... mistico!
In effetti... dopo aver predisposto tutta la struttura fisica per accogliere i server da proteggere, dopo aver disegnato un'infrastruttura di rete parallela e averla configurata sul sito di destinazione e dopo aver configurato tutte le repliche a livello di storage per avere i dati "attivi" anche sulla SAN presente nel sito di Recovery... sono solo pochi click per effettuare un test o il vero e proprio "spostamento della produzione".
Tutto meraviglioso ma... VMware (da un certo punto di vista correttamente) non ha previsto in nessuna delle versioni fino ad ora rilasciate dell'SRM un automatismo per effettuare dei test e per inviare dei report relativi al risultato degli stessi...
Ci tengo a precisare che la modalità di test è ovviamente prevista e funziona in maniera egregia permettendo di evidenziare delle eventuali mancanze o problematiche senza dover interrompere le repliche dei dati ma operando su delle snapshot che alla fine del test verranno rimosse ed eliminate lasciando l'ambiente pronto per qualunque evenienza.
Si sa però che un buon piano di Disaster Recovery funziona solo se testato abbondantemente in modo da evitare sgradevoli sorprese al momento in cui realmente dovesse essere necessario spostare il sito produttivo, ma si sa anche che il tempo è realmente difficile da trovare per effettuare dei test...
E allora ecco che dalla nuova versione di PowerCLI (5.5 R2) esce la soluzione al mio (e forse non soltanto mio) problema...
Sui blog di VMware trovo una serie di post che descrivono proprio quello che fa al caso mio:
Il buon Ken esplora con una discreta dovizia di particolari tutti i metodi che possono essere utilizzati via PowerCLI in abbinata all'SRM. Dapprima descrive le modalità di collegamento al Server che ospita l'applicativo e poi snocciola i vari comandi per listare i recovery plan e lanciare il test o il cleanup o il recovery vero e proprio. Infine descrive come ottenere uno stringato resoconto delle ultime operazioni compiute su uno specifico Recovery Plan (un mini-report lo definirei io).
Visto quello che si poteva fare non mi restava che mettere insieme il tutto in una serie di script per farli lanciare poi dallo schedulatore di Windows una volta a settimana :-)
Per una questione di semplicità di scrittura degli script e per meglio gestire le schedulazioni ne ho creati tre diversi: uno per far partire il test del Recovery Plan, uno che notifica l'ultimo risultato dello stesso Recovery Plan e un ultimo che si premura di fare il Cleanup per rimettere l'ambiente in "ordine" per il test della settimana successiva.
Il primo script quindi si occupa di far partire il test del Recovery Plan che ci interessa.
#Add PowerCLI Snapin
Add-Pssnapin VMware.VimAutomation.Core
#Connect to vCenter
connect-viserver "vCenter.local" -User 'Administrator' -Password 'xxxxxxxxxx'
#Set variables (and connect to SrmServer)
$SrmConnection=Connect-SrmServer -User 'Administrator' -Password 'xxxxxxxxxx'
$SrmApi = $SrmConnection.ExtensionData
$ProtectionGroups = $SrmApi.Protection.ListProtectionGroups()
$RPmode = [VMware.VimAutomation.Srm.Views.SrmRecoveryPlanRecoveryMode]::Test
#Define Recovery Plan to test ( to find the correct one use the $srmapi.recovery.listplans()[<number>].getInfo() command)
$RPmoref = $SrmApi.Recovery.ListPlans()[0]
#Start the test with last storage replication
$RPmoref.Start($RPmode)
Per trovare il corretto Recovery Plan (identificato da un numero nel comando) sfruttiamo - dopo aver dichiarato le variabili presenti nello script nella specifica sezione - il comandino:
$srmapi.recovery.listplans()[X].getInfo()
Provando a lanciare il comando più volte variando la "X" con un numero da 0 a "il numero dei recovery plan che avete definito -1" :-) vi verrà restituita una riga con una dicitura che riporterà il nome con cui avete battezzato il Recovery Plan permettendovi di individuarlo.
Scoperto il "magic number" (per comodità nei miei script di esempio uso lo 0 ) lo utilizzeremo anche negli altri script partendo da quello che invia una mail con il risultato dell'ultimo test effettuato sullo specifico Recovery Plan:
#Add PowerCLI Snapin
Add-Pssnapin VMware.VimAutomation.Core
#Remove last result file
rm "c:\scripts\last_result.txt"
#Connect to vCenter
connect-viserver "vCenter.local" -User 'Administrator' -Password 'xxxxxxxxxx'
#Set variables
$SrmConnection=Connect-SrmServer -User 'Administrator' -Password 'xxxxxxxxxx'
$SrmApi = $SrmConnection.ExtensionData
$PlanMoref = $SrmApi.Recovery.Listplans()[0].moref
$HistoryMoref = $SrmApi.Recovery.GetHistory($PlanMoref)
#Send last result output to file
$HistoryMoRef.GetRecoveryResult(0) | Select Name, RunMode, Description, StartTime, StopTime, ResultState, WarningCount | Format-List | out-file "c:\scripts\last_result.txt"
#Send e-mail
$smtpServer = "mail.local"
$smtpFrom = "srm_from_DR@local"
$smtpTo = "it_admin@local"
$messageSubject = "Last Recovery Test Result"
$body = (get-content "c:\scripts\last_result.txt" | out-string)
send-mailmessage -from "$smtpFrom" -to "$smtpTo" -subject "$messageSubject" -body "$body" -smtpServer "$smtpServer"
Per far partire questo script l'ho inserito come comando lanciato dallo stesso Recovery Plan alla fine di tutte le operazioni.
Ricordatevi che per far partire uno script in Poweshell/PowerCLI è necessario usare la seguente sintassi (dopo aver selezionato "Command on SRM Server"):
C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -file c:\script\report_script.ps1
Verificato (dalla mail ricevuta) che il test si sia concluso senza errori non resta che dare una ripulita all'infrastruttura prima del prossimo test...
Nulla di più semplice, sempre bene in mente il "magic number" che identifica il nostro Recovery Plan in test e:
Add-Pssnapin VMware.VimAutomation.Core
#Connect to vCenter
connect-viserver "vCenter.local" -User 'Administrator' -Password 'xxxxxxxxxx'
#Set variables
$SrmConnection=Connect-SrmServer -User 'Administrator' -Password 'xxxxxxxxxx'
$SrmApi = $SrmConnection.ExtensionData
$ProtectionGroups = $SrmApi.Protection.ListProtectionGroups()
$RPmode = [VMware.VimAutomation.Srm.Views.SrmRecoveryPlanRecoveryMode]::CleanupTest
#Define Recovery Plan to cleanup ( to find the correct one use the command: $srmapi.recovery.listplans()[<number>].getInfo()
$RPmoref = $SrmApi.Recovery.ListPlans()[0]
#Start the cleanup
$RPmoref.Start($RPmode)
Anche in questo caso schedulato con lo Scheduler di Windows.
A qualcuno potrebbe sorgere il dubbio del perché schedulare il cleanup... è arrivata la mail e quindi so che devo collegarmi al vCenter, poi all'SRM andare sui Recovery Plans e lanciare il cleanup... se avete avuto questo dubbio avete perso la premessa fatta all'inizio... TROVARE IL TEMPO :-)
Scriptando anche il cleanup mi garantisco che il test della settimana successiva potrà partire correttamente anche se in quella precedente non ho trovato i 10 minuti per andare a cancellare il vecchio test...
Spero con questo post di aver semplificato la vita a qualche altro Amministratore di Sistemi alle prese con il Site Recovery Manager.
