In questo post viene illustrata una delle feature più interessanti, in scenari enterprise, di Microsoft Velocity: parliamo dell'alta affidabilità o High Availability (HA).
Nel primo post di questa serie, è stato introdotto il concetto di cluster, ovvero un gruppodi server che erogano il servizio di cache distribuita. Ciascun server è soggetto a aggiornamento, manutenzione e, più raramente, a guasti che ne pregiudicano temporaneamente il funzionamento. Grazie alla HA, Microsoft Velocity consente, in maniera trasparente, di gestire queste situazioni di "guasto". La soluzione adottata da Velocity consiste nella creazione di una copia secondaria (attualmente una sola copia) di ciascun oggetto caricato in cache. La copia viene memorizzata su di un server differente da quello contenente l'"originale".
Per abilitate la HA, occorre specificare il parametro –Secondaries1 durante la creazione di una named cache, come di seguito illustrato:
new-cache -CacheName DemoCacheHA -Secondaries 1
Fig.1 Duplicazione degli oggetti in cache, con HA abilitata.
Il rilevamento dell'indisponibilità di un server, appartenente al cluster di velocity, è il primo step attuato dalla tecnologia interna di clustering (Fabric), per rimediare alla situazione. Appena intercettato il "guasto", Velocity inizia la duplicazione di tutti gli oggetti originariamente esistenti sul server che ha abbandonato il cluster, quest'ultimo infatti, ritornerà operativo nel suo insieme, solo quando gli oggetti appartenenti ad una cache HA-Enabled saranno stati duplicati sugli altri server ancora disponibili.
Fig.2 Ridistribuzione delle nuove copie degli oggetti in cache.
Sebbene dal punto di vista implementativo, abilitare la HA sia semplicemente questione di specificare il parametro -Secondaries 1 in fase di creazione di una namedCache, dal punto di vista delle prestazioni si ottiene un lieve decadimento in fase di ADD/PUT/REMOVE. Condizione necessaria per finalizzare queste operazioni è infatti creare (o rimuovere) una copia "secondaria" dell'oggetto, su un cache host differente dal primo utilizzato.
Il concetto di HA è trasparente anche rispetto alle regions (descritte in questo post).
Velocity, nella sua attuale versione CTP3, richiede almeno 3 cache hosts per ottenere la HA, nel caso in cui si disponga di soli 2 cache hosts, sarebbe sufficiente che uno di questi si guasti per compromettere l'intero cluster, in termini di alta affidabilità.
E' evidente che, nell'ottica di ottenere l'alta affidabilità, la scelta del configuration store di Velocity basato su SQL Server è da preferire rispetto al network share (basato su SQL Server CE).
Il ripristino dell’operatività del server non è immediato, occorre tenere presente che tra il verificarsi del guasto e l’istante in cui il cluster torna operativo, si verificano diversi eventi e Velocity intraprende diverse azioni, in sintesi avviene quello che è meglio noto come “ritardo di propagazione”.
Supponiamo t0 l’istante in cui un server abbandona il cluster, ad esempio in seguito ad un guasto, Velocity controllerà ad intervalli stabiliti, che tutti i cache host siano “alive” e disponibili, raggiungiendo così l’istante t1. Nel caso in cui un cache host es. Server2 non risponda più, Velocity impiegherà un certo numero di secondi (timeout di comunicazione) per classificarlo come “non disponibile”, raggiungendo l’istante t2. Da qui in poi, per tutti gli oggetti inizialmente contenuti nel cache host Server2 ed appartenenti ad una named cache con HA abilitata, inizierà il processo di duplicazione ed elevamento di eventuali copie da “secondarie” a “primarie” come illustrato in Fig.1 e Fig.2.
Quando tutti gli oggetti saranno stati duplicati, il cluster tornerà nuovamente operativo.
Nel caso in cui, invece, si effettui uno stop manuale di un cache host da con il comando Powershell:
stop-cachehost –hostName Server2 –cachePort 22233
Velocity sarà subito informato dell’indisponibilità del cache host Server2, così t0 + t1 saranno quasi pari a 0, contraiamente a quanto avviente in caso di un guasto improvviso, dove solo lo scadere di un timeout di comunicazione tra cache host potrà confermarlo.
posted @ lunedì 20 luglio 2009 23:32