Arda Solutions s.r.l. | The Informal Blog

cluster stars

Nell’attività di tutti i giorni, specialmente in ambienti Enterprise con una policy ben definita riguardo virtualizzazione e strutturazione delle risorse, è difficile trovare cluster di guest sull’infrastruttura virtuale (tipicamente Vsphere).

Il perché è presto detto: gli strumenti (o addons) a corredo dei vari Hypervisor permettono già la gestione dell’HA e in alcuni casi del fault tollerance, ma, a meno di specifiche eccezioni, la necessità alle volte è di monitorare e reagire a fault provenienti dal livello applicativo.

Per questo motivo, alle volte, si preferisce creare, sopra all’infrastruttura virtuale, un cluster con le tecnologie provenienti dal sistema operativo guest.

Esistono però, alternative valide all’utilizzo del clustering guest, che possono far partecipare l’infrastruttura virtuale al failover oppure, in alcuni casi, delegare all’infrastruttura stessa il failover a livello applicativo

Per primo parliamo del modulo facente parte dello stack del clustering RHEL denominato fence_vmware_soap . Questa componente (dalla versione 6 e con vsphere 5.1 che risolve il bug presente nella 5) si preoccupa di gestire il fencing dei nodi sfruttando le api vmware.  In pratica: Ad un azione sollevata dallo strato application del cluster corrisponde una reazione derivata dalla chiamata all’infrastruttura virtuale (che produce normalmente lo switch del nodo e/o il riavvio del nodo in fault)

Le altre 2 caratteristiche invece sono proprie dell’ambiente vmware e sono:

  • L’application Awareness API introdotta nel vsphere 5
  • Il vApp container che, se usato insieme all’Application Awareness permette di introdurre la logica Multi-Tiered

L’Application Awareness è un API introdotta con la versione 5 di vsphere, essa permette di inserire all’interno dei propri script una logica di controllo sul buono stato dei servizi contenuti nella vm e, nel caso ci fosse qualche problema, reagire a questi problemi. Questa funzionalità ha la necessità di essere configurata a livello di VM e con l’HA vmware abilitato (per permettere l’up della vm in standby). Esistono delle chiamate utilizzabili a livello di codice a seconda dell’SDK che utilizzate ma,  nella maggior parte dei casi questa funzionalità viene richiamata da script, è quindi possibile comandare il comportamento di questa API tramite l’eseguibile: vmware-appmonitor. Scriveremo in seguito un nuovo articolo per approfondire l’utilizzo di questa API.

Il vApp è un concetto introdotto di recente che non è direttamente legato all’HA application di vmware ma che ci è piaciuto introdurre per il fatto che, in congiunzione con l’API appena descritta permette di gestire l’HA di tutte le macchine coinvolte nel servizio. Se per esempio abbiamo la classica application a 3 strati: Presentation, business e backend potremo “infilare” queste vm dentro ad una vApp e gestirne:

  • L’ordine di avvio e di spegnimento
  • un pool di IP dedicato
  • Le operazioni comuni delle VM che possono essere eseguite  anche a livello di vApp (shutdown, suspend, clone etc…)
  • l’Export / import OVF

Anche per il vApp provvederemo a fare un articolo di approfondimento.

Questo articolo voleva essere solo una panoramica generale sulle funzionalità che possono essere integrate fra lo strato application e lo strato hypervisor. E’ da tenere in considerazione anche il fatto che qui si è preso a riferimento solo vSphere ma che anche gli altri hypervisor hanno funzionalità simili che esploreremo nel futuro.

Comments on: "Il perché di un cluster in Guest su infrastruttura virtuale" (1)

  1. […] detto in un precedente articolo vi avevamo promesso che avremmo parlato dell’Application awareness, la nuova API introdotta […]

Leave a Reply