Ho partecipato recentemente a un evento Symantec, in cui veniva illustrato il loro prodotto Application HA.
Dopo una breve introduzione su VMware HA (dove non è mancata la oramai famigerata domanda “Meglio installare vCenter in fisico o virtuale?”), è stato illustrato il nuovo funzionamento di HA di vSphere 5, in particolare di come questo sistema sia stato aperto alla possibilità di monitorare le applicazioni ospitate in una virtual machine, sfruttando le API offerte da VMware.
Symantec ha quindi rilasciato Application HA proprio per sfruttare questa funzione. La soluzione permette di monitorare le applicazioni e identificarne eventuali failures, e coordina il recovery delle stesse, riavviando le applicazioni internamente alla singola VM, oppure coordinandosi con VMware HA per ulteriori attività.
Ad esempio, in seguito a un evento di VMware HA la virtual machine potrebbe riavviarsi correttamente su un altro host ESXi, ma l’applicazione contenuta potrebbe avere problemi; esempio classico un database crollato a causa di un nodo ESXi fallito che potrebbe essere in uno stato inconsistente.
Uno scenario interessante è l’integrazione prevista con BackupExec 2012, per cui l’escalation di Application HA, in caso di impossibilità di risolvere un problema sia riavviando l’applicazione che la VM, può richiedere a BackupExec di ripristinare una versione precedente della VM.
Un ulteriore step è l’integrazione con SRM, in modo da avere piani di recovery non solo a livello di VM, ma anche delle applicazioni ospitate. Non ho potuto però ulteriormente approfondire questo aspetto.
Per quanto riguarda la parte pratica, lato VMware bisogna attivare nelle configurazioni del cluster HA, nel pannello VM Monitoring, la modalità “VM and Application Monitoring”, che per default è invece impostata su “Disabled”:
Andiamo quindi ad impostare la sensibilità del monitoraggio. Anche in presenza di Application HA, questo valore continua a influenzare la gestione delle failure del sistema operativo.
Predisposto VMware, si passa alla configurazione di Application HA, che consiste nell’installazione del software su una virtual machine Windows (anch’essa monitorabile tramite un suo agent!) e la configurazione per farla dialogare con vCenter, e facendo poi il push da vCenter del componente guest sulle varie VM che vogliamo monitorare.
Una cosa interessante è il fatto che l’applicazione funziona tramite Flash, ma non installa nessun plugin su vCenter. Questo ne rende possibile un suo utilizzo anche con la vCenter Appliance.
Il lab che ho potuto provare in prima persona mi ha lasciato particolarmente soddisfatto, il prodotto è già maturo (d’altra parte, per stessa ammissione delle persone Symantec, è una derivazione della parte di monitoring di Veritas Cluster…) e offre interessanti scenari di utilizzo. La possibilità di monitorare in modo dettagliato diversi applicativi o di crearsi monitoraggi custom è molto potente. Ho provato ad esempio l’agent per MSSQL, ed è possibile verificare lo stato del database usando delle query SQL oltre al mero controllo di servizi. Questo livello di granularità è sicuramente gradito in quegli ambienti dove oltre a garantire l’affidabilità dell’infrastruttura voglio garantire quella applicativa. Pensiamo ad un servizio di e-commerce, dove il buon funzionamento viene verificato non solo controllando il servizio database, ma anche verificando che le tabelle necessarie siano interrogabili!
E’ possibile svilupparsi autonomamente moduli custom; symantec inoltre mette a disposizione il sito SORT (https://sort.symantec.com/agents) dove è possibile caricare i propri agent, o scaricare quelli creati da altri.
La licenza è per virtual machine e vale 500 euro. Non sono pochi, ma ovviamente prevede un uso per ambienti critici o comunque particolari dove l’uptime delle applicazioni è fondamentale e quindi il prezzo è giustificabile.
Il limite attuale è costituito dal monitoraggio di una singola applicazione per VM: sinceramente, considerando la tendenza delle piattaforme virtualizzate ad “atomizzare” i workload (1 VM per servizio erogato), non lo vedo sinceramente come un grande problema, ma sicuramente in alcuni scenari potrebbe essere un vincolo; questo limite verrà comunque eliminato a detta di Symantec con la successiva versione.
Un’altra limitazione che ho visto è la necessità, come accadeva per Veritas Cluster, di avere un canale di comunicazione tra la Console e i vari Guest Agents, specificatamente sulle porte tcp 5634 (monitoring) 14152-14153 (heartbeat). In ambienti multi-tenancy o con parecchie reti, abilitare il passaggio di questo traffico potrebbe risultare non banale.