Commander setup

Back

LBL®Commander è un prodotto destinato ad ambienti mission-critical pertanto solo personale che ha effettuato il corso ed ha superato l’esame è autorizzato a certificare l’installazione e manutenzione dei prodotti in esercizio. Tutte le persone certificate sono dotate di patentino di riconoscimento rilasciato da TCOGROUP.

LBL®Commander può essere installato in due modalità, assieme a LBL®ADC oppure da solo (alone). In entrambi i casi è necessaria la licenza specifica LBL®Commander Work Flow o LBL®Commander Decision Engine per poterlo utilizzare.

Installazione

Per installare LBL®Commander si deve procede con l’installazione di base disponibile nel manuale di installazione e setup. Per le installazioni MS Windows il riferimento è il manuale LBL_GDG_WINPROTABLE_InstallUpdate_ita/eng.pdf per l’installazione in un sistema LINUX il manuale di riferimento è LBL_GDG_InstallUpdateFrom_ita/eng.pdf.

LBL®Commander introduzione

LBL®Commander introduce un nuovo concetto di alta affidabilità in ambito applicativo andando a ricoprire il ruolo di coordinatore delle attività in un datacenter mission-critical. LBL®Commander è composto da due moduli principali: LBL®Commander Work Flow e LBL®Commander Decision Engine. I due moduli sono stati progettati per lavorare in cooperazione tra loro oppure, nel caso non siano richieste delle operazioni automatiche, è possibile utilizzare il solo componente LBL®Commander Work Flow. LBL®Commander Decision Engine è stato progettato per cooperare con LBL®ADC.

L’architettura generale può essere riassunta nel seguente schema:

La flessibilità dello strumento può essere espressa in differenti architetture. Di seguito un altro esempio di architettura possibile dove le componenti LBL®Commander Decision Engine e Work Flow sono sulla stessa macchina in ogni semisito (HalfSite)….

…oppure uno scenario di Disaster Recovery con take-over manuale e quindi con i soli componenti LBL®Commander Work Flow.

Proprio la caratteristica di separazione delle attività tra LBL®Commander Work Flow, cosa si deve fare, e LBL®Commander Decision Engine, quando deve essere fatto, ci permette di suddividere l’installazione in due fasi controllando prima in maniera manuale tutti i flussi e quindi, se richiesta un’operatività automatica, procedere con l’installazione di LBL®Commander Decision Engine.

Per questo motivo il manuale è diviso in questa sequenza su due capitoli, uno riguardante l’installazione di LBL®Commander Work Flow l’altro riguardante l’installazione di LBL®Commander Decision Engine.

LBL®Commander Work Flow introduzione

L’installazione del modulo LBL®Commander Work Flow necessita di un’analisi preventiva degli obiettivi che si vogliono perseguire in quanto per sua natura LBL®Commander Work Flow è uno strumento in grado di effettuare qualsiasi operazione gli venga schedulata.

Per questo manuale utilizzeremo un esempio di minima dove si gestirà un processo Apache Tomcat nel suo ciclo di vita: Start, Shutdown (N.B.: Quando si parla di shutdwon si intende lo stop delle applicazioni e non del sistema operativo che le ospita). Volendo poi riutilizzare lo stesso esempio anche per la componente LBL®Commander Decisione Engine. Per il momento identificheremo due tipi di job: normalPrimer (innesco primario) e gracefulShutdown (spegnimento controllato delle applicazioni).

LBL®Commander Work Flow progettazione

LBL®Commander Work Flow parte dal presupposto che qualsiasi operazione complessa possa essere scomposta in oggetti elementari.

La prima operazione da effettuare è quindi l’individuazione dei lavori da eseguire (Work Flows) e delle attività all’interno di ogni singolo lavoro (steps).

Volendo ad esempio eseguire lo start di un processo Apache Tomcat dovremo prima di tutto identificare con un nome il tipo di lavoro. In questo caso sceglieremo normalPrimer come nome identificativo del Work Flow di innesco dello start del processo. Sicuramente ad uno start dovrà essere reso possibile eseguire anche uno stop controllato. A questo scopo identificheremo anche un nome per eseguire questa lavoro: gracefulShutdown.

Una volta identificati i lavori da svolgere andremo a verificare per ogni lavoro (Work Flow) gli step caratteristici.

In questo caso per il Work Flow normalPrimer sicuramente dovremo utilizzare uno step che lancerà tomcat (es.: startupTomcat) e uno step che andrà a terminare l’esecuzione di tomcat (es.: shutdownTomcat).

Altra operazione è l’identificazione degli step di terminazione dei Work Flow. Per convenzione un Work Flow può terminare con normalEnd se l’operazione va a buon fine e uno step con nome abEnd (abnormal end) nel caso l’operazione non terminasse con successo.

Come vedremo in seguito gli step normalEnd e abEnd sono abbastanza costanti in tutti i tipi di Work Flow identificando la fine corretta o anomala di un Work Flow.

Una volta identificati gli step tipici del nostro progetto potremo concentrarci sullo sviluppo dei comandi che porteranno alla definizione dei nostri Work Flow.

LBL®Commander Work Flow piano degli indirizzi

Essendo LBL®Commander Work Flow un servizio disponibile sulla rete è necessario effettuare il piano degli indirizzi per poter identificare su quali server e relative reti sarà reso disponibile. Il servizio viene erogato in forma di Remote Workflow Command (RWC) in modalità sicura (HTTP-SSL) autenticata. È possibile identificare uno o più LBL®Monitor che attraverso la loro Web Console possono interagire con LBL®Commander Work Flow. LBL®Commander Work Flow è utilizzato anche da LBL®Commander Decision Engine nel caso siano previsti degli automatismi di innesco a fronte di eventi applicativi.

Il piano degli indirizzi per LBL®Commander Work Flow è molto semplice e si può attuare attraverso una semplice tabella come ad esempio quella proposta di seguito:

Hostname/Address

Port number

Description

legendonebackend

54444

HalfSite A.A

legendtwobackend

54444

HalfSite B.B

NOTA: I nodi/sedi sono identificati da lettere divise da una punteggiatura. La punteggiatura indica la profondità infrastrutturale. La prima lettera indica il contesto con le eventuali relazioni con motori decisionali LBL®Commander Decision Engine. Riportiamo nuovamente lo schema architetturale generale per comodità espositiva.

LBL®Commander Work Flow Web Console

LBL®Commander Work Flow necessita di una o più console, minimo 2 in ambienti mission-critical, per poter essere gestito. È possibile utilizzare la stessa console di amministrazione dell’installazione LBL®Commander Work Flow oppure, come nel disegno, utilizzare altre istanze LBL®Monitor dislocate in differenti server adibiti a console amministrative.

LBL®Commander Work Flow directory e files

LBL®Commander Work Flow utilizza solamente due directory ed un file di configurazione più il file di licenza.

Le directory di default sono:

(LBL_HOME)procsProfiles/A03_LBLGoSurfaceClusterWF/surfaceClusterWFCommandDir

————————————————————————————————————-

(LBL_HOME)/procsProfiles/A03_LBLGoSurfaceClusterWF/conf

contiene la licenza ed il file di configurazione surfaceclusterwf.xml

(LBL_HOME)/procsProfiles/A03_LBLGoSurfaceClusterWF/surfaceClusterWFCommandDir

è la directory di default degli script/eseguibili che verranno avviati dagli step di un Work Flow. Le distribuzioni riportano in questa directory i file batch con in nomi tipici di un flusso di take-over di un sito:

Per ambienti UNIX / Linux:

unix/flushDisk.sh

unix/fractureReplications.sh

unix/fsck.sh

unix/inversionReplication.sh

unix/mountFileSystem.sh

unix/restartApache.sh

unix/selfTest.sh

unix/shutdownApplicationOne.sh

unix/shutdownApplicationThree.sh

unix/shutdownApplicationTwo.sh

unix/startApplicationOne.sh

unix/startApplicationThree.sh

unix/startApplicationTwo.sh

unix/startDatabase.sh

unix/umountFileSystem.sh

unix/waitSynchronization.sh

unix/checkApacheActivity.sh

Per ambienti MS Windows:

windows\lushDisk.bat

windows\fractureReplications.bat

windows\fsck.bat

windows\inversionReplication.bat

windows\mountFileSystem.bat

windows\restartApache.bat

windows\selfTest.bat

windows\shutdownApplicationOne.bat

windows\shutdownApplicationThree.bat

windows\shutdownApplicationTwo.bat

windows\startApplicationOne.bat

windows\startApplicationThree.bat

windows\startApplicationTwo.bat

windows\startDatabase.bat

windows\umountFileSystem.bat

windows\waitSynchronization.bat

windows\checkApacheActivity.bat

Ognuno di questi file contiene un template di minima pronto per essere popolato con gli opportuni comandi della piattaforma interessata. A titolo di esempio di seguito il contenuto dei comandi sopra elencati. Per ragioni di praticità, soprattutto per i batch file MS Windows, all’inizio di ogni comando sul primo parametro viene distinta una modalità interattiva da una modalità batch. Questo è comodo in fase di implementazione perché nella modalità interattiva non viene eseguito l’EXIT che porterebbe su MS Windows all’uscita della finestra di lancio. In questo caso invece verrà visualizzato il return code con il quale sarebbe uscito il batch file all’EXIT.

Ovviamente per quello che riguarda LBL®Commander Work Flow l’unico valore utilizzato è il return code e quindi questi esempi sono solo da intendersi come traccia completamente modificabile.

MS Windows

@ECHO OFF

REM LBL(tm) LoadBalancer

REM

REM This is a commercial software

REM You shall not disclose such Confidential Information and shall use

REM it only in accordance with the terms of the license agreement

REM

REM www.tcoproject.com

REM www.lblloadbalancer.com

REM mailto:info@tcoproject.com

REM

REM LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

REM LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

REM

REM LBL(r)Surface Cluster Template

set LBL_INTERACTIVE_CMD=%1

if “%LBL_INTERACTIVE_CMD%” == “” (set LBL_INTERACTIVE_CMD=false)

echo %LBL_INTERACTIVE_CMD%

set RETURN_OK=0

set RETURN_KO=99

set returnCode=%RETURN_OK%

REM

REM action

REM

REM

REM exit

REM

:end_procedure

if “%LBL_INTERACTIVE_CMD%” == “true” (goto end_echo_return_code)

:end_exit_return_code

exit %returnCode%

:end_echo_return_code

ECHO EXIT=%returnCode%

:end

Solaris / Linux

#!/bin/sh

# LBL(tm) LoadBalancer

#

# This is a commercial software

# You shall not disclose such Confidential Information and shall use

# it only in accordance with the terms of the license agreement

#

# www.tcoproject.com

# www.lblloadbalancer.com

# mailto:info@tcoproject.com

#

# LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

# LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

#

# LBL(r)Surface Cluster Template

LBL_INTERACTIVE_CMD=${1:-‘false’}

RETURN_OK=0

RETURN_KO=99

returnCode=$RETURN_OK

#

# action

#

#

# exit

#

test “$LBL_INTERACTIVE_CMD” != “true” && exit $returnCode

test “$LBL_INTERACTIVE_CMD” = “true” && echo exit=$returnCode

È possibile effettuare le stesse operazioni anche direttamente dalla console web attraverso le seguenti operazioni:


Commander-> Wirkflow Managers -> Scelta del modulo

Scelta del workflow

Scelta dello step da editare es.:

Editing dello script:

Edit

LBL®Commander Work Flow implement batch files

Il primo passo quindi nell’implementazione e installazione di un Work Flow è l’analisi degli step da eseguire e quindi la scrittura e test dei singoli step per poi passare al loro inserimento in un flusso di lavoro.

Per i nostri scopi copieremo un qualsiasi batch distribuito in:

MS Windows

cd (LBL_HOME)\procsProfiles\A03_LBLGoSurfaceClusterWF\surfaceClusterWFCommandDir

copy selfTest.bat tomcatStartup.bat

Unix / Linux

cd (LBL_HOME)/procsProfiles/A03_LBLGoSurfaceClusterWF/surfaceClusterWFCommandDir

cp selfTest.sh tomcatStartup.sh

Per entrambe le piattaforme, ma specialmente su MS Windows, è importante accertarsi che i comandi eseguiti nei batch file non eseguano degli exit autonomi, impliciti o espliciti. Per fare questa prova è sufficiente utilizzare un unico punto di uscita nei propri batch e verificare con apposita segnalazione l’avvenuto passaggio (comune pratica di buona programmazione).

Nei nostri specifici casi andremo a popolare i nostri nuovi batch file con le operazioni di start per Tomcat.

Di seguito i file di start con evidenziate le linee di comando utilizzate per eseguire lo start e lo stop delle istanze tomcat.

MS Windows tomcat startup:

@ECHO OFF

REM LBL(tm) LoadBalancer

REM

REM This is a commercial software

REM You shall not disclose such Confidential Information and shall use

REM it only in accordance with the terms of the license agreement

REM

REM www.tcoproject.com

REM www.lblloadbalancer.com

REM mailto:info@tcoproject.com

REM

REM LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

REM LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

REM

REM LBL(r)Surface Cluster Template

set LBL_INTERACTIVE_CMD=%1

if “%LBL_INTERACTIVE_CMD%” == “” (set LBL_INTERACTIVE_CMD=false)

echo %LBL_INTERACTIVE_CMD%

set RETURN_OK=0

set RETURN_KO=99

set returnCode=%RETURN_OK%

REM

REM action

REM

setlocal

set JAVA_HOME=C:\work1\bin\java\jdk1.6.0_07

cd C:\work1\bin\Servers\apache-tomcat-6.0.14_8484\bin

call startup.bat

set returnCode=%ERRORLEVEL%

REM ATTENZIONE TORNA 1 ANCHE QUANDO OK

REM

REM exit

REM

:end_procedure

if “%LBL_INTERACTIVE_CMD%” == “true” (goto end_echo_return_code)

:end_exit_return_code

exit %returnCode%

:end_echo_return_code

ECHO EXIT=%returnCode%

:end

In questo caso durante i test ci siamo accorti che lo start di tomcat in ambiente Windows torna sempre 1 anche se l’operazione è andata a buon fine. Abbiamo preferito non modificare tale comportamento ma evidenziarlo a livello di commento e quindi riportare la logica, come vedremo in seguito, sullo step di esecuzione di questo batch. In questo modo abbiamo documentato questo comportamento sul flusso e non abbiamo aggiunto logica all’interno del programma di lancio. Inoltre non avendo modificato i file relativi all’applicativo porterà un indubbio vantaggio nelle manutenzioni successive che non devono tenere conto di modifiche da riportare nuovamente agli applicativi ad ogni aggiornamento.

Se proviamo ad eseguire da command line questo comando si otterrà questo risultato:



La stessa implementazione è stata introdotta nel comando di tomcatShutdown.bat con il comando di shutdown:

Echo dell’exit code

Start con echo del return code

REM LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

REM

REM LBL(r)Surface Cluster Template

set LBL_INTERACTIVE_CMD=%1

if “%LBL_INTERACTIVE_CMD%” == “” (set LBL_INTERACTIVE_CMD=false)

echo %LBL_INTERACTIVE_CMD%

set RETURN_OK=0

set RETURN_KO=99

set returnCode=%RETURN_OK%

REM

REM action

REM

setlocal

set JAVA_HOME=C:\work1\bin\java\jdk1.6.0_07

cd C:\work1\bin\Servers\apache-tomcat-6.0.14_8484\bin

call shutdown.bat

set returnCode=%ERRORLEVEL%

REM ATTENZIONE TORNA 1 ANCHE QUANDO OK

REM

REM exit

REM

:end_procedure

if “%LBL_INTERACTIVE_CMD%” == “true” (goto end_echo_return_code)

:end_exit_return_code

exit %returnCode%

:end_echo_return_code

ECHO EXIT=%returnCode%

:end

Solaris / Linux

In ambiente Solaris e Linux le implementazioni da effettuare sono le stesse ovviamente con le differenze dovute al linguaggio di script utilizzato ed eventuali differenze di comportamento.

Di seguito l’esempio con l’impostazione dei batch file tomcatStartup.sh:

#!/bin/sh

# LBL(tm) LoadBalancer

#

# This is a commercial software

# You shall not disclose such Confidential Information and shall use

# it only in accordance with the terms of the license agreement

#

# www.tcoproject.com

# www.lblloadbalancer.com

# mailto:info@tcoproject.com

#

# LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

# LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

#

# LBL(r)Surface Cluster Template

LBL_INTERACTIVE_CMD=${1:-‘false’}

RETURN_OK=0

RETURN_KO=99

returnCode=$RETURN_OK

#

# action

#

JAVA_HOME=/TCOProject/bin/java; export JAVA_HOME

cd /TCOProject/bin/tomcat/apache-tomcat-6.0.24/bin/

./startup.sh

returnCode=$?

#

# exit

#

test “$LBL_INTERACTIVE_CMD” != “true” && exit $returnCode

test “$LBL_INTERACTIVE_CMD” = “true” && echo exit=$returnCode

tomcatShutdown.sh

#

# LBL(r)Surface Cluster Template

LBL_INTERACTIVE_CMD=${1:-‘false’}

RETURN_OK=0

RETURN_KO=99

returnCode=$RETURN_OK

#

# action

#

JAVA_HOME=/TCOProject/bin/java; export JAVA_HOME

cd /TCOProject/bin/tomcat/apache-tomcat-6.0.24/bin/

./shutdown.sh

returnCode=$?

#

# exit

#

test “$LBL_INTERACTIVE_CMD” != “true” && exit $returnCode

test “$LBL_INTERACTIVE_CMD” = “true” && echo exit=$returnCode

Come si può notare una differenza tra lo start su MS Windows e Solaris / Linux è il return code che in questo caso torna 0 se l’operazione è andata a buon fine.

Effettuando le operazioni da command line si otterrà il seguente risultato:

Con i limiti di questi esempi e a conclusione di questo capitolo possiamo constatare che abbiamo cominciato a scrivere la nostra libreria di “oggetti” riutilizzabili su diverse piattaforme per diversi progetti. Resta ora da determinare l’utilizzo di questi oggetti all’interno di flussi logici di lavoro.

LBL®Commander Work Flow build Work Flows

Una volta ultimati ed eseguiti i test dettagliati dei comandi di base per la realizzazione dei nostri flussi di lavoro resta da implementare la logica di contesto nei Work Flow che vogliamo realizzare.

La parametrizzazione del Workflow inizia dall’impostazione dell’indirizzo dove verranno accettati i comandi: Tipicamente non dovrà essere effettuata nessuna modifica perché il sistema è già predisposto ad accettare comandi nell’indirizzo di management.

Commander->WorkFlow Managers -> Scelta del workflow

Un altro valore interessante è il valore: exclusiveRunWorkFlow=”false

Questo parametro indica se l’intero Work Flows Engine può avere nello stesso momento più Work Flow in stato di running. Per i nostri scopi l’impostazione a “false”, cioè più Work Flow possono essere lanciati contemporaneamente, è l’opzione corretta. È da ricordare che comunque il Work Flows Engine non permette, indipendentemente da questo parametro, di lanciare contemporaneamente uno stesso Work Flow. In altre parole se il Work Flow con nome normalPrimer in stato di Running non può essere ulteriormente lanciato mentre può essere lanciato contemporaneamente il Work Flow gracefulShutdown. Nel caso fosse stato impostato exclusiveRunWorkFlow=”true” e il Work Flow normalPrimer fosse in stato di Running non riusciremmo a lanciare nessun altro Work Flow compreso gracefulShutdown, fino al termine di normalPrimer.

Una volta terminata l’impostazione per poter rendere accessibile dall’esterno l’utilizzo del sistema Workflow si passa al paragrafo successivo che contiene i Work Flow con le azioni suddivise in singoli step.

Nel nostro caso dovremo arrivare ad avere due Work Flow per poter eseguire lo start e lo stop del processo Tomcat come da specifiche che ci siamo posti inizialmente.

Il risultato finale per lo start dovrà essere simile a quando descritto di seguito dove sul capitolo <workFlow> si potranno vedere i parametri name=”normalPrimer”, il nome di quel particolare work flow, la descrizione sintetica ed il nome dello step con cui iniziare il flusso di lavoro startName=”startupTomcat”:

I parametri relativi ad ogni step sono abbastanza intuitivi e quindi ci soffermeremo solo su alcuni di essi. Una completa trattazione di ogni singolo parametro e del loro comportamento si può trovare nella Reference Guide.

<!– ******************************************************************* **

START WORK FLOW NORMAL PRIMER

** ******************************************************************* –>

<workflow name=”normalPrimer”

description=”Start Apache Tomcat Primary”

startName=”startupTomcat”>

<step enable=”true”

name=”startupTomcat”

description=”Start Apache Tomcat primary”

waitBeforeExecute=”1000″

sysCommandTimeOut=”600000″

evaluateReturnCode=”true”

command=”tomcatStartup.bat”

maxRetry=”3″

gotoWhenFalse=”abEnd”>

<returncode value=”0″

description=”ok”

result=”true”/>

<returncode value=”1″

description=”ok”

result=”true”/>

</step>

<!– *********************************************************** **

END FUNCTIONS

** *********************************************************** –>

<step enable=”true”

commitWorkFlow=”true”

name=”normalEnd”

description=”Normal end”

waitBeforeExecute=”10000″

evaluateReturnCode=”false”

gotoWhenTrue=”normalEnd”

gotoWhenFalse=”normalEnd”>

</step>

<step enable=”true”

name=”abEnd”

description=”Abnormal end”

evaluateReturnCode=”true”

waitBeforeExecute=”10000″

gotoWhenTrue=”abEnd”

gotoWhenFalse=”abEnd”>

<returncode value=”0″

description=”KO FOR ABNORMAL END”

result=”false”/>

</step>

</workflow>

I parametri significativi su cui soffermarci sono il comando che verrà eseguito nello step command=”tomcatStartup.bat”, e lo step “normalEnd” con il parametro commitWorkFlow=”true”. Quest’ultimo parametro indica che lo step è un punto di consistenza e quindi non produrrà log dopo la prima volta. In questo caso lo step entra in un loop senza possibilità di uscita e questo è un comportamento voluto. Come vedremo in seguito questo comportamento è stato sfruttato per non dare la possibilità di doppia esecuzione dello stesso workFlow nello stesso momento. È buona norma in produzione mettere in loop il workFlow effettuando periodicamente un HealthCheck del servizio, ad esempio attraverso wget in questo caso, ed uscire per return code con eventuali azioni di riparazione come potrebbe essere un restart o la segnalazione del problema.

Già da questo momento è possibile avviare LBL®Commander Work Flow e verificarne l’effetto. Per poter essere visualizzato dalla Web Console è necessario aver impostato il file monitor.xml con i riferimenti al server LBL®Commander Work Flow che si vuole visualizzare come specificato nel paragrafo visto in precedenza.

Seguendo gli HiperLink è possibile verificare step per step il percorso effettuato dal Work Flow una volta avviato:

E’ consigliato già da questo momento effettuare il run per verificarne gli effetti ed il funzionamento. In caso di Work Flow complessi è possibile effettuare il run uno step alla volta utilizzando il pulsante “Step action” sulla destra di ogni step.

Se i test di questo primo Work Flow sono andati a buon fine è possibile passare allo sviluppo del prossimo Work Flow per l’esecuzione dello shutdown controllato del servizio Apache Tomcat.

<!– ******************************************************************* **

START WORK FLOW GRACEFUL SHUTDOWN

** ******************************************************************* –>

<workflow name=”gracefulShutdown”

description=”Graceful shutdown Apache Tomcat”

startName=”shutdownTomcat”>

<step enable=”true”

name=”shutdownTomcat”

description=”Graceful shutdown Apache Tomcat”

waitBeforeExecute=”1000″

sysCommandTimeOut=”600000″

evaluateReturnCode=”true”

command=”tomcatShutdown.bat”

maxRetry=”3″

gotoWhenFalse=”abEnd”>

<returncode value=”0″

description=”ok”

result=”true”/>

<returncode value=”1″

description=”ok”

result=”true”/>

</step>

<!– *********************************************************** **

END FUNCTIONS

** *********************************************************** –>

<step enable=”true”

commitWorkFlow=”true”

name=”normalEnd”

description=”Normal end”

waitBeforeExecute=”10000″

evaluateReturnCode=”false”

gotoWhenTrue=”normalEnd”

gotoWhenFalse=”normalEnd”>

</step>

<step enable=”true”

name=”abEnd”

description=”Abnormal end”

evaluateReturnCode=”true”

waitBeforeExecute=”10000″

gotoWhenTrue=”abEnd”

gotoWhenFalse=”abEnd”>

<returncode value=”0″

description=”KO FOR ABNORMAL END”

result=”false”/>

</step>

</workflow>

Attraverso la propria interfaccia di amministrazione eseguendo lo Stop e lo Start del processo LBL®Commander Work Flow è possibile gestire anche questo nuovo Work Flow.

Seguendo l’Hyperlink del nuovo Work Flow se ne può verificare il percorso:

In maniera molto semplice è possibile ora gestire da remoto lo start e lo stop del processo Apache Tomcat.

LBL®Commander Work Flow distribuited events (@RWC)

Dalla versione 7.1 è possibile eseguire all’interno di uno step in un workflow un ulteriore comando di start workflow remoto (@RWC). Questa funzionalità permette al “Sistema Commander Work Flow” di eseguire delle operazioni distribuite. Con questa funzionalità è possibile quindi propagare un processo di WorkFlow dagli strati più alti ai più bassi o viceversa su diverse piattaforme per eseguire quindi operazioni articolate su tutte le componenti che formano l’applicazione. La disponibilità applicativa infatti è la somma di disponibilità di molti strati, dalla disponibilità dei dati, sistemi di memorizzazione di massa, alla disponibilità di servizi di database, alla disponibilità di servizi di directory fino ad arrivare alla disponibilità dei servizi applicativi forniti dagli application server e alla disponibilità di connettività.

Questi servizi sono su sistemi fisicamente separati, a volte anche geograficamente, e nasce quindi la necessità di “governare” in maniera distribuita ma coordinata tutti questi elementi. Pensiamo ad esempio di indurre un restart applicativo mirato. Per eseguire un’operazione di questo tipo bisogna identificare le risorse che concorrono a rendere disponibile il servizio e quindi una volta determinato quale sia il componente in “avaria” verificare la possibilità di ripristinare l’operatività. Una attività così articolata deve essere governata da procedure ben definite e collaudate in modo che possano essere scientificamente ripetibili. Con l’introduzione della funzionalità @RWC in uno step di un WorkFlow è possibile da un WorkFlow principale eseguire queste operazioni in maniera Centralizzata, Mirata, Localizzata, Automatizzabile.

  1. Centralizzata

    Centralizzata perché in un unico LBL®Commander Work Flow Server è possibile indicare dei WorkFlow di management che innescano WorkFlow sui sistemi remoti.
  2. Mirata

    E’ possibile definire dei WorkFlow specializzati per innescare azioni di mantenimento sui singoli servizi
  3. Localizzata

    Ogni singolo sistema di WorkFlow localizza le proprie gestioni del ciclo di vita applicativo
  4. Automatizzabile

    Attraverso LBL®Commander Decision Engine è possibile automatizzare tutte le operazioni per fornire servizi di Business Continuity e/o Disaster Recovery.

Anche in questo caso una particolare attenzione deve essere posta nella semplicità di implementazione e utilizzo con tracciabilità documentata e implicita.

Per effettuare un’operazione di @RWC è sufficiente inserire nel parametro “command” di un paragrafo “<step>” la keyword riservata @RWC seguita dalle indicazioni di dove si vuole eseguire il comando (hostName) e cosa si vuole eseguire (workFlow). Se si volesse quindi eseguire il RWC di “startHealthCheckAndRestart” sul sistema “dbserver” sarebbe sufficiente indicare:

command=”@RWC hostName=dbserver workFlow=startHealthCheckAndRestart”

Il login e la password non sono presenti perché utilizzano LBL®Autonomous Delegated Authentication.

I parametri login e password verranno utilizzati anche in futuro per eseguire nuovi Inner Command.

La parametrizzazione completa del comando @RWC permette di eseguire tutte le operazioni di start, dallo start di un intero WorkFlow allo start di un WorkFlow con partenza da uno Step prefissato allo start di un singolo step.

Il comando completo con tutti i parametri è il seguente:

@RWC hosname=nome sistema o indirizzo bersaglio del RWC

[portNumber=port number sistema di SCWF] default 54444

[uriPath=Uripath del sistema SCWF] default /SCWFCommand

workFlow=workflow name

[step=nome dello step da lanciare, se “” dal primo] default “”

[command=runWorkFlow|stopWorkFlow] default “runWorkFlow”

[frhd=se true esegue solo lo step indicato] default false

Es. 1: start workflow dallo step secondStep

command=”@RWC hostName=dbserver workFlow=startHealthCheckAndRestart step=secondStep”

Es. 2: start workflow del solo step secondStep

command=”@RWC hostName=dbserver workFlow=startHealthCheckAndRestart step=secondStep frhd=true”

E’ utile osservare che il lancio di un @RWC su sistemi remoti non produce un significativo codice di ritorno. @RWC notifica come errore solamente se non riesce a produrre uno start della procedura. Ogni procedura remota deve essere autoconsistente per disegno in modo che solo la disponibilità applicativa sia il fattore discriminante della funzionalità.

LBL®Commander Work Flow Remote Batch

Questo servizio permette di eseguire lo start di batch remoti per eseguire HealthCheck distribuiti in sicurezza. Si compone di un servizio Web, che risponde per default alla porta 5994, in grado di interpretare un file xml di profilo per il lancio di eseguibili o batch file.

L’installazione deve prevedere i seguenti step:

1- Verifcare che sia stata impostata la licenza d’uso LBL®Commander Work Flow

(LBL_HOME)/lib/confSurfaceClusterWF/license.xml

2- Impostazione La configurazione del servizio

3- Eseguire lo start del servizio verificando il log con l’avvenuto listen all’indirizzo porta indicato:

4- Scrittura e verifica del batch

Esempio vai.bat (windows systems):

echo %0 %1 %2 %3 %4 >>C:\logvai.txt

AA=%1

exit 0

Esempio vai.sh (UNIX/Linux systems)

echo startBatch $@ >>/tmp/logStartBatch.txt

exit 0

5- Impostazione del profilo di lancio in

(LBL_HOME)/lib/webroot_remotebatch/webapps/RemoteBatch/

Il file di profilo ha il seguente formato:

<startBatch>

<params remoteBatchTimeOut=”10000″

remoteBatchCheckRate=”300″

allowURIParams=”false” debug=”false”/>

<legacyCommand>T:\work0\tmp\vai.bat 11 </legacyCommand>

</startBatch>

Essendo interpretato al momento del richiamo, esattamente come una pagina HTML, i cui valori potranno essere cambiati dinamicamente a caldo.

Il nome del file deve essere uguale al paragrafo principale. Nel caso sopra descritto il file si dovrà chiamare startBatch ed avere una estensione come: xml; txt, etc. (mime type text/html).

I parametri sono pochissimi e abbastanza intuitivi. Di seguito una descrizione dettagliata. Per approfondimenti sul singolo parametro si rimanda alla documentazione Reference Guide.

remoteBatchTimeOut=: valore di default “10000”

E’ il tempo di attesa prima di rilasciare il processo batch/eseguibile.

remoteBatchCheckRate=: valore di default “300”

E’ il tempo di attesa tra un tentativo e l’altro dopo aver aspettato

remoteBatchTimeOut. Dopo 3 tentativi il lancio del batch viene dichiarato fallito.

allowURIParams=:valore di default “false”

Se true permette di inserire ulteriri parametri da URI. Il default e’ false per motivi di sicurezza. Se non impostato o impostato a false eventuali parametri impostati nell’URIPath verranno ignorati.

debug=: valore di default “false”

se true esegue un log warning con i valori di start del processo e del risultato ottenuto.

<legacyCommand>=: valore di default “null”

E’ il batch da lanciare. Per motivi di sicurezza questo valore non puo’ essere vuoto.

Il lancio del batch avverrà tramite richiesta di una URL che riporti il nome del file descrittore da interpretare per il lancio del batch/eseguibile.

E’ possibile indicare ulteriori parametri durante il lancio del programma nella URL stessa come nell’esempio di seguito:

http://localhost:5994/RemoteBatch/startBatch.txt?parameters=2222 3333 4444

In questo caso il lancio del batch sarà così composto nella parte parametri:

T:\work0\tmp\vai.bat 11 2222 3333 4444

Per verificare l’esecuzione del batch si può utilizzare un semplice browser e impostare l’indirizzo es.:

http://wileubuntudbenchbackend:5994/RemoteBatch/startBatch.xml

L’errore di interpretazione XML è relativo al corpo del messaggio che riporta solamente il codice di ritorno del batch/eseguibile. Per codice di ritorno uguale a 0 il Response Code HTTP sarà 200 OK. Per codici di ritorno del batch/eseguibile diversi da 0 il response Code HTTP sarà 500 Internal Server Error.

6- Impostazione lo start automatico del servizio (da “manual” a “automatic”)

ATTENZIONE

Quanto contenuto nel batch o nelle varie composizioni dei parametri sono a cura del batch stesso. Il servizio LBL non controllerà la correttezza del batch o varie composizioni dei parametri che saranno completamente a cura dell’implementatore

LBL®Commander Work Flow with Decision Engine

LBL®Commander Work Flow può essere accoppiato alle funzionalità LBL®Commander Decision Engine di start automatico in coincidenza con eventi di failure applicativo.

Per default LBL®Commander Decision Engine utilizza 3 Work Flow che contraddistinguono i processi di avvio, stop e switch di un ambiente operativo.

I tre momenti sono stati identificati in:

  1. normalPrimer

avvio normale delle applicazioni sul nodo principale

  1. gracefulShutdown

stop delle applicazioni in modalità controllata. Questa operazione viene innescata da LBL®Commander Decision Engine sul nodo/sito dove è stato rilevato un evento di failure prima di far prendere il controllo ad un altro nodo/sito. Questo è da considerarsi un tentativo in quanto il nodo/sito potrebbe non essere più dispinibile.

  1. takeControl

è l’insieme di processi che devono essere avviati in un nodo/sito secondario per prendere il controllo applicativo.

N.B.: Dalla versione 7.1 è possibile identificare un momento intermedio che intercorre tra la rilevazione dell’avaria e la decisione di eseguire uno spostamento dei servizi. Questo momento, chiamato restartWorkFlow è stato implementato per eseguire, prima dello spostamento dei servizi, un restart nel sito primario delle componenti che si ritiene essere più soggetti in una infrastruttura a criticità. Molto spesso infatti il restart controllato delle sole componenti critiche permette di avere un bassissimo impatto nell’operatività e una migliore gestione degli eventi critici senza ricorrere allo spostamento delle operazioni su altro sito/sistema con conseguente azione successiva di ripristino dell’operatività.

Questi momenti, d’ora in avanti chiamati workFlow, devono essere disponibili per poter utilizzare LBL®Commander Decision Engine. I nomi dei singoli Work Flow possono essere modificati in base alle necessità. È inoltre importante sapere che una istanza LBL®Commander Work Flow può contenere più volte queste azioni con nomi diversi in base alle applicazioni che si vogliono controllare da diversi LBL®Commander Decision Engine. In altre parole se in un nodo coesistono più ambiti applicativi in contesti diversi e se ne vuole pilotare separatamente la possibilità di fail-over è sufficiente inserire ulteriori Work Flow con nomi diversi per l’esecuzione delle azioni relative a quell’ambito applicativo.

Se si vuole procedere con l’installazione di LBL®Commander Decision Engine è quindi necessario inserire un nuovo Work Flow ai due già creati nei capitoli precedenti: takeControl.

In questo caso di minima questo nuovo Work Flow sarà esattamente uguale al normalPrimer e cioè innescherà lo start di Apache Tomcat. Nella distribuzione sono presenti alcuni esempi, simili per i sistemi operativi Unix/Linux e MS Windows. Gli esempi sono un “template” sul quale costruire le proprie implementazioni.

Si deve quindi procedere con la creazione del Work Flow “takeControl” per poi poterlo utilizzate come evento da LBL®Commander Decision Engine.

Di seguito il frammento del file surfaceclusterwf.xml con il Work Flow takeControl:

<!– ******************************************************************* **

START WORK FLOW TAKE CONTROL START

** ******************************************************************* –>

<workflow name=”takeControl”

description=”Take control Start Apache Tomcat Tomcat”

startName=”startupTomcat”>

<step enable=”true”

name=”startupTomcat”

description=”Take control Start Apache Tomcat Tomcat”

waitBeforeExecute=”1000″

sysCommandTimeOut=”600000″

evaluateReturnCode=”true”

command=”tomcatStartup.bat”

maxRetry=”3″

gotoWhenFalse=”abEnd”>

<returncode value=”0″

description=”ok”

result=”true”/>

<returncode value=”1″

description=”ok”

result=”true”/>

</step>

<!– *********************************************************** **

END FUNCTIONS

** *********************************************************** –>

<step enable=”true”

commitWorkFlow=”true”

name=”normalEnd”

description=”Normal end”

waitBeforeExecute=”10000″

evaluateReturnCode=”false”

gotoWhenTrue=”normalEnd”

gotoWhenFalse=”normalEnd”>

</step>

<step enable=”true”

name=”abEnd”

description=”Abnormal end”

evaluateReturnCode=”true”

waitBeforeExecute=”10000″

gotoWhenTrue=”abEnd”

gotoWhenFalse=”abEnd”>

<returncode value=”0″

description=”KO FOR ABNORMAL END”

result=”false”/>

</step>

</workflow>

Dopo aver eseguito stop e start del server LBL®Commander Work Flow il risultato finale dovrebbe essere simile a questo esempio:

In un ambiente con due nodi speculari è sufficiente eseguire l’installazione dell’immagine LBL®Commander Work Flow eseguendo uno zip della directory (LBL_HOME) e quindi modificare solamente i riferimenti all’host.

LBL®Commander Decision Engine introduzione

LBL®Commander Decision Engine è un cluster geografico progettato per rendere automatiche le operazioni di Fail-Over in ambienti mission-critical. Questo modulo può essere considerato come il modulo “pensante” per automatizzare la gestione di procedure (Work Flow d’ora in avanti) posti su altri Server sia in ambito locale sia in ambito geografico. LBL®Commander Decision Engine lavora in cooperazione con LBL®Commander Work Flow per l’avvio di Remote Workflow Command (RWC).

L’architettura generale può essere riassunta nel seguente schema:

La flessibilità dello strumento può essere espressa in differenti architetture. Di seguito un altro esempio di architettura possibile dove le componenti LBL®Commander Decision Engine e Work Flow sono sulla stessa macchina in ogni nodo/sito….

…oppure uno scenario di Disaster Recovery con take-over automatico

LBL®Commander Decision Engine piano degli indirizzi/risorse

La progettazione di una infrastruttura basata su LBL®Commander Decision Engine si struttura nei seguenti aspetti fondamentali:

  1. Individuazione delle risorse che identificano la rete pubblica
  2. Individuazione delle risorse che identificano la rete di backend
  3. Individuazione degli altri motori decisionali che concorrono al quorum
  4. Individuazione delle risorse Applicative

Questi quattro elementi ci portano ad elaborare un piano degli indirizzi/risorse applicative che descrivono il contesto operativo.

La prima tabella del piano indirizzi serve ad identificare degli indirizzi/servizi che possono essere eletti a bersaglio per la determinazione della raggiungibilità della rete pubblica. Il numero minimo consigliato di bersagli è 3 (tre) l’ottimale è 5 (cinque). La logica è che se tutti i bersagli non sono raggiungibili allora la rete pubblica viene dichiarata “down”. Un esempio di tabella indirizzi/servizi è di seguito sintetizzata:

Il gestore di HealthCheck è stato progettato per gestire diverse modalità di HealthCheck in base ai parametri che gli vengono forniti. Se gli viene fornito il solo parametro Address eseguirà un “ping”, se gli viene fornito anche il parametro “port” eseguirà una connect e disconnect TCP/IP, se gli forniamo anche l’URIPath eseguirà una GET HTTP e controllerà il response-code che dovrà essere 200 (OK) per terminare correttamente. È possibile inoltre indicare se il servizio HTTP bersaglio è in modalità SSL con un ulteriore parametro.

Public Network Health Check

Address

Port Number

URIPath

SSL

Description

192.168.43.143

System A1 public

192.168.43.146

System A2 public

192.168.43.151

System A3 public

Una tabella simile deve essere compilata per i servizi di backend:

Backend Network Health Check

Address

Port Number

URIPath

SSL

Description

192.168.45.143

System A1 public

192.168.45.146

System A2 public

legendonebackend

54444

/HealthCheck

true

Commander WF A.A

legendtwobackend

54444

/HealthCheck

true

Commander WF B.B

In quest’ultimo esempio si possono osservare degli health check più complessi in HTTPS afferenti ai servizi LBL®Commander Work Flow che verranno utilizzati per l’automazione delle procedure.

La tabella successiva identifica gli altri motori decisionali che concorrono al Quorum. Il Quorum decisionale, cioè le condizioni che permettono ad una istanza LBL®Commander Decision Engine di poter prendere una decisione, è relativo alla possibilità di raggiungere almeno un altro LBL®Commander Decision Engine. Nel caso non fosse raggiungibile nessun altro LBL®Commander Decision Engine il nodo si dichiarerebbe isolato e quindi impossibilitato a prendere una decisione autonoma. La tabella che descrive gli altri motori decisionali (peers) avrà la seguente forma:

LBL®Commander Decision Engine peers

URL

Description

https://legendoneprivate:54445/

HalfSite A

https://legendtwoprivate:54445/

HalfSite B

https://legendquorumprivate:54445/

Quorum Site

Il numero di LBL®Commander Decision Engine devono essere tre (3) per la determinazione del quorum. Un numero inferiore di istanze LBL®Commander Decision Engine porterebbe a non decidere in mancanza di una delle due istanze ed un numero superiore potrebbe portare ad avere delle isole decisionali (split brain decisionale). Un’altra considerazione è relativa alla rete di Heart-Beat che non deve essere necessariamente privata ma può essere condivisa con altre applicazioni potendo arrivare a lavorare anche in ambito geografico (internet).

I file di configurazione di ogni nodo riporteranno sempre solo due (2) dei tre riferimenti della tabella non dovendo mai riportare il riferimento a se stesso.

LBL®Commander Decision Engine Web Console

LBL®Commander Decision Engine necessita di una o più console, minimo 2 in ambienti mission-critical, per poter essere gestito. È possibile utilizzare la stessa console di amministrazione dell’installazione LBL®Commander Decision Engine oppure, come nel disegno, utilizzare altre istanze LBL®Monitor dislocate in differenti server adibiti a console amministrative. Dalle stesse console possono essere gestite sia le istanze LBL®Commander Decision Engine che le istanze LBL®Commander Work Flow.



LBL®Commander Decision Engine directory e files

LBL®Commander Decision Engine utilizza solamente 3 directory ed un file di configurazione se escludiamo il file di licenza.

Le directory di default sono:

(LBL_HOME)/procsProfiles/A03_LBLGoSurfaceClusterDE/conf

(LBL_HOME)/procsProfiles/A03_LBLGoSurfaceClusterDE/surfaceClusterDEStatus

(LBL_HOME)/lib/notificationDir

————————————————————————————————————-

(LBL_HOME)/procsProfiles/A03_LBLGoSurfaceClusterDE/conf

Contiene la licenza ed il file di configurazione surfaceclusterde.xml

(LBL_HOME)/procsProfiles/A03_LBLGoSurfaceClusterDE/surfaceClusterDEStatus

E’ la directory di default per la persistenza dei flag di stato. In questa directory vengono creati i file che identificano le risorse dichiarate down e quindi non più utilizzabili anche dopo un successivo restart del motore decisionale o dell’intero sistema.

(LBL_HOME)/lib/notificationDir

E’ la directory di notifica a LBL®ADC di indisponibilità del servizio. Viene gestita automaticamente da LBL®Commander Decision Engine creando un file con le seguenti caratteristiche:

outOfOrder.SCDEGroup_00000

| | +————–> Numero identificatore della sequenza di

| | Fail-Over in ordine di inserimento.

| | Questo valore deve essere inserito

| | nell’apposito parametro

| | <endp associateName=”SCDEGroup_0000”…

| | in iproxy.xml

| +——————————–> Nome del gruppo del Cluster di controllo

| dell’applicazione

+————————————————> Identificatore di notifica Out Of Order

LBL®Commander Decision Engine surfaceclusterde.xml

Una volta ultimata la raccolta dei dati di ambiente si può iniziare ad impostare il file di configurazione del Cluster.

L’impostazione dei file di configurazione deve essere effettuata su tutti e tre i nodi dove è stata installata l’immagine LBL®Commander Decision Engine atraverso una delle sue distribuzioni.


La prima operazione da effettuare è quindi porre in cluster tutti i moduli decision engine e agire sulle variabili per differenziare i comportamenti:

Il file contiene due paragrafi principali, uno per la gestione del Server LBL®Commander Decision Engine mentre gli altri sono funzionali alla gestione dei Cluster applicativi.

Nella pagina di seguito sono riportati i paragrafi evidenziati con una cornice blue per i parametri relativi alla gestione del Server LBL®Commander Decision Engine ed in rosso i paragrafi relativi alla gestione di un singolo Cluster Applicativo. È possibile nello stesso LBL®Commander Decision Engine gestire più Cluster semplicemente duplicando il paragrafo <decisionEngine> e impostando un diverso groupName con il nome di questo nuovo cluster.

LBL(tm) LoadBalancer is built on TCOProject(tm) SoftwareLibrary

LBL and TCOProject are trademarks of F.Pieretti. All rights reserved.

</copyright>

<surfaceclusterde>

<params

frequency=”10000″

address=”solu6bench001monitor”

port=”54445″

addressHeartBeat=”solu6bench001private”

portHeartBeat=”54445″

sysCommandRemoteURL=”https://localhost:5992/SysCommand”>

</params>

<decisionEngineMgr>

<decisionEngine enable=”true”

groupName=”SCDEGroup”

description=”SCDE halfSite A”

frequency=”10000″

firstThinkingTime=”45000″>

<!– *******************************************************

PEERS DECISION ENGINES NODES (Min 3 nodes)

** ******************************************************* –>

<decisionEnginesPeers>

<peer enable=”true”

description=”HalfSite B”

URL=”https://solu6bench002private:54445/” login=”admin” password=”adminadmin”/>

<peer enable=”true”

description=”QuorumSite”

URL=”https://wilelbloneprivate:54445″ login=”admin” password=”adminadmin”/>

</decisionEnginesPeers>

<!– *******************************************************

APPLICATIONS SERVICES AND ASSOCIATED SURFACE WORK FLOW SERVER

** ******************************************************* –>

<healthCheckServicesPolicy description=”Services switch policy”

surfaceClusterWorkFlowLogin=”admin”

surfaceClusterWorkFlowPassword=”adminadmin”

waitTimeAfterNormalPrimer=”180000″

waitTimeAfterFlagBroken=”60000″

waitTimeBeforeTakeControl=”180000″

waitTimeAfterTakeControl=”900000″

applicationLostTime=”30000″>

<failOverService enable=”true”

description=”HalfSite A.A”

surfaceClusterWorkFlowURL=”https://wileubuntudbenchbackend:54444/”>

<healthCheck enable=”true”

description=”primary application HalfSite A.A”

address=”wileubuntudbenchbackend”

port=”8080″ uriPath=”/” SSL=”false”/>

</failOverService>

<failOverService enable=”true”

description=”HalfSite B.B”

surfaceClusterWorkFlowURL=”https://roadubuntudbenchbackend:54444/”>

<healthCheck enable=”true”

description=”Secondary application HalfSite B.B”

address=”roadubuntudbenchbackend”

port=”8080″ uriPath=”/” SSL=”false”/>

</failOverService>

</healthCheckServicesPolicy>

<!– *******************************************************

PUBLIC HEALTH CHECK

** ******************************************************* –>

<healthCheckPublicPolicy>

<healthCheck address=”192.168.43.104″ port=”22″ description=”wilecoyote”/>

<healthCheck address=”192.168.43.103″ port=”22″ description=”roadrunner”/>

<healthCheck address=”192.168.43.101″ description=”gundam”/>

</healthCheckPublicPolicy>

<!– *******************************************************

BACKEND HEALTH CHECK

** ******************************************************* –>

<healthCheckBackendPolicy>

<healthCheck address=”192.168.45.104″ port=”22″ description=”wilecoyote”/>

<healthCheck address=”192.168.45.103″ port=”22″ description=”roadrunner”/>

<healthCheck address=”192.168.45.101″ description=”gundam”/>

<healthCheck enable=”true” address=”wileubuntudbenchbackend” port=”54444″

uriPath=”/HealthCheck” SSL=”true”

description=”Surface Cluster Work Flow A.A”/>

<healthCheck enable=”true” address=”roadubuntudbenchbackend” port=”54444″

uriPath=”/HealthCheck” SSL=”true”

description=”Surface Cluster Work Flow B.B”/>

</healthCheckBackendPolicy>

</decisionEngine>

</decisionEngineMgr>

<sysobserver>

<service name=”syslog” id=”syslogsurfaceclusterde”/>

</sysobserver>

</surfaceclusterde>

</serviceconf>

Identificatore del gruppo di cluster

Decision Engines

Peers

Applications management

Public

HealthCheck

Backend

HealthCheck

L’impostazione del primo paragrafo prevede l’impostazione degli indirizzi per la gestione del Server e per il controllo remoto.

Di seguito quanto proposto nella distribuzione per il paragrafo <params>:

<params

frequency=”10000″

address=”___hostnameMonitor___”

port=”54445″

addressHeartBeat=”___hostnameHeartBeat___”

portHeartBeat=”54445″

sysCommandRemoteURL=”https://localhost:5992/SysCommand”>

</params>

frequency è la frequenza di verifica dello stato del cluster.

address è l’indirizzo pubblico su cui effettuare le operazioni di controllo mentre addressHeartBeat è un secondo indirizzo, normalmente afferente alla rete di HeartBeat, per le operazioni tra nodi peers. I due indirizzi possono coincidere ed in questo caso è necessario modificare la porta per la convivenza.

Una volta impostati i parametri generali si passa alla configurazione del cluster applicativo. Il primo paragrafo da impostare è sicuramente il paragrafo relativo all’identificazione del Cluster.

<decisionEngineMgr>

<decisionEngine enable=”true”

groupName=”SCDEGroup”

description=”SCDE halfSite A”

frequency=”10000″

firstThinkingTime=”45000″

applicationLostTime=”30000″>

Ogni paragrafo <decisionEngine> delimita un Cluster Applicativo. Possono esserci più <decisionEngine> e quindi più gestioni di cluster applicativi differenti contemporaneamente.

enable=:default=”false” UM=boolean

Abilita o disabilita l’interpretazione di questo paragrafo nell’istanza.

groupName=: valore di default=”SCDEGroup”

E’ il nome del gruppo di Decision Engine. E’ importantissimo in quanto i motori di decisione contenuti su un’istanza si distinguono da questo nome.

description=: valore di default=”description: groupName”

E’ la descrizione di questo decision engine. Deve essere sintetica ma esaustiva.

frequency=: valore di default=”<params frequency>” UM=Millisecondi

E’ la frequenza di verifica cambiamenti di stato. Se non specificata viene assunta la frequenza del paragrafo <params>

firstThinkingTime=: valore di default=”45000” UM=Millisecondi

E’ il tempo di attesa di inizializzazione e prime verifiche. Superato questo tempo di attesa il motore decisionale evidenzierà un messaggio. Il motore decionale non procede comunque anche oltrepassato questo tempo iniziale e attende la totale inizializzazione degli stati.

applicationLostTime=: valore di default=”30000” UM=Millisecondi

E’ il tempo di attesa da quando l’applicazione in verifica è stata dichiarata in stato di down. Questo è un valore molto importante perché superato questo periodo di tempo e l’applicazione risultasse ancora non raggiungibile e verificato il quorum di switch si innescherà la procedura di recovery. I 30” sono il minimo per evitare falsi positivi.

Il paragrafo <decisionEnginePeers> delimita le informazioni relative agli altri due Decision Engine che concorrono alle decisioni.

<decisionEnginesPeers>

<peer enable=”true”

description=”HalfSite ___A_or_B___”

URL=”https://___hostnameHeartBeat___:54445/”/>

<peer enable=”true”

description=”QuorumSite”

URL=”https://___hostnameHeartBeat___:54445″/>

</decisionEnginesPeers>

I parametri sono molto semplici e necessitano solo delle informazioni relative alla connessione e autenticazione.

enable=:default=”false” UM=boolean

Abilita o disabilita l’interpretazione di questo paragrafo nell’istanza.

URL=:default=”” UM=URL W3c

E’ l’URL di connessione al servizio paritetico attraverso la rete di HeartBeat.

description=:default=”description peer: URL”

descrizione sintica ma esaustiva del servzio.

Il paragrafo relativo ai servizi applicativi è il cuore del Cluster in quanto identifica i servizi applicativi con le relative modalità di HealthCheck Questo paragrafo include anche i Work Flow che devono essere innescati per le azioni di Fail-Over.

<!– *******************************************************

APPLICATIONS SERVICES AND ASSOCIATED SURFACE WORK FLOW SERVER

** ******************************************************* –>

<healthCheckServicesPolicy description=”Services switch policy”

waitTimeAfterNormalPrimer=”180000″

waitTimeAfterFlagBroken=”60000″

waitTimeBeforeTakeControl=”180000″

waitTimeAfterTakeControl=”900000″

applicationLostTime=”30000″

normalPrimerWorkFlow=”normalPrimer”

gracefulShutdownWorkFlow=”gracefulShutdown”

takeControlWorkFlow=”takeControl”>

<failOverService enable=”true”

description=”HalfSite A.A”

surfaceClusterWorkFlowURL=”https://___hostnameBackend_A_A___:54444/”>

<healthCheck enable=”true”

description=”primary application HalfSite A.A”

address=”___hostnameBackend_A_A___”

port=”80″

uriPath=”/”

SSL=”false”/>

</failOverService>

<failOverService enable=”true”

description=”HalfSite B.B”

surfaceClusterWorkFlowURL=”https://___hostnameBackend_B_B___:54444/”>

<healthCheck enable=”true”

description=”Secondary application HalfSite B.B”

address=”___hostnameBackend_B_B___”

port=”80″

uriPath=”/”

SSL=”false”/>

</failOverService>

</healthCheckServicesPolicy>

I parametri nel paragrafo <healthCheckServicesPolicy> sono relativi alla gestione. I parametri sono intuitivi e riprendendo parte del documento di reference guide e si possono riassumere in:

description=:default=””

Descrizione generale del servizio posto in alta affidabilità.

waitTimeAfterNormalPrimer=:default=”180000” UM=Millisecondi

E’ il tempo di attesa dopo aver avviato il primo servizio disponibile (normal startup). Superato questo tempo il decision engine comincerà a verificare se il servizio è arrivato allo stato di attività. In caso contrario verranno avviate le procedure di recovery. Se l’applicazione va in up prima di questo valore il Decision Engine si mette immediatamente in verifica.

waitTimeAfterFlagBroken=:default=”60000” UM=Millisecondi

E’ il tempo di attesa dopo l’impostazione del flag persistente per la propagazione agli altri peer.

waitTimeBeforeTakeControl=:default=”180000” UM=Millisecondi

E’ il tempo di attesa prima di effettuare il take control serve a lasciare il tempo per un eventuale graceful shutdown del servizio precedentemente attivo se la risorsa è ancora raggiungibile.

waitTimeAfterTakeControl=:default=”900000” (15′) UM=Millisecondi

E’ il tempo di attesa dopo il take control serve ad aspettare la conclusione del completo take control prima di ritornare a verificare lo stato di attivita’ e quindi decidere se e’ andato a buon fine oppure ritentare con altra risorsa se disponibile. Se l’applicazione va in up prima di questo valore il Decision Engine si mette immediatamente in verifica. Questo tempo è variabile in dipendenza del tipo di recovery e dalla quantità di dati se presente un database.

applicationLostTime=:default=”<decisionEngine applicationLostTime>” UM=Mill.

E’ il tempo di attesa dopo il take control serve ad aspettare la conclusione del completo take control prima di ritornare a verificare lo stato di attivita’ e quindi decidere se e’ andato a buon fine oppure ritentare con altra risorsa se disponibile. Se l’applicazione va in up prima di questo valore il Decision Engine si mette immediatamente in verifica. Questo tempo è variabile in dipendenza del tipo di recovery e dalla quantità di dati se presente un database.

normalPrimerWorkFlow=:default=”normalPrimer” UM=Work Flow name

E’ il nome del Work Flow che sarà innescato se viene determinato lo startup iniziale del servzio..

gracefulShutdownWorkFlow=:default=”gracefulShutdown”UM=Work Flow name

E’ il nome del Work Flow che sarà innescato se vine determinato il down del servizio e immediatamente prima di effettuare l’azione di recovery.

takeControlWorkFlow=:default=”takeControl”UM=Work Flow name

E’ il nome del Work Flow che sarà innescato dopo l’avvio del gracefulShutdownWorkFlow per avviare l’azione di recovery.

<!– *******************************************************

APPLICATIONS SERVICES AND ASSOCIATED SURFACE WORK FLOW SERVER

** ******************************************************* –>

<healthCheckServicesPolicy description=”Services switch policy”

waitTimeAfterNormalPrimer=”180000″

waitTimeAfterFlagBroken=”60000″

waitTimeBeforeTakeControl=”180000″

waitTimeAfterTakeControl=”900000″

applicationLostTime=”30000″

normalPrimerWorkFlow=”normalPrimer”

gracefulShutdownWorkFlow=”gracefulShutdown”

takeControlWorkFlow=”takeControl”>

<failOverService enable=”true”

description=”HalfSite A.A”

surfaceClusterWorkFlowURL=”https://___hostnameBackend_A_A___:54444/”>

<healthCheck enable=”true”

description=”primary application HalfSite A.A”

address=”___hostnameBackend_A_A___”

port=”80″

uriPath=”/”

SSL=”false”/>

</failOverService>

<failOverService enable=”true”

description=”HalfSite B.B”

surfaceClusterWorkFlowURL=”https://___hostnameBackend_B_B___:54444/”>

<healthCheck enable=”true”

description=”Secondary application HalfSite B.B”

address=”___hostnameBackend_B_B___”

port=”80″

uriPath=”/”

SSL=”false”/>

</failOverService>

</healthCheckServicesPolicy>

<failOverService> identifica in sequenza di inserimento i servizi nei loro server. L’ordine di inserimento identifica anche la priorità dei servizi. I parametri proposti da template di distribuzione sono pochissimi ma in realtà si possono impostare moltissimi parametri tipici per questa applicazione in quel particolare nodo/sito. Si rimanda al documento Reference Guide per una completa trattazione.

enable=:default=”false” UM=boolean

Abilita o disabilita l’interpretazione di questo paragrafo nell’istanza.

description=:default=””

Descrizione puntuale del servizio posto in alta affidabilità. Si consiglia, nei limiti del possibile, di utilizzare la nomenclatura LBL®Surface Clsuter es.: HalfSite A.A piuttosto che HalfSite B.B con la breve ma esaustiva descrizione del servizio.

surfaceClusterWorkFlowURL=:default=”https://”

E’ l’URL dell’istanza LBL®Commander Work Flow afferente a questo servzio applicativo.

<!– *******************************************************

APPLICATIONS SERVICES AND ASSOCIATED SURFACE WORK FLOW SERVER

** ******************************************************* –>

<healthCheckServicesPolicy description=”Services switch policy”

waitTimeAfterNormalPrimer=”180000″

waitTimeAfterFlagBroken=”60000″

waitTimeBeforeTakeControl=”180000″

waitTimeAfterTakeControl=”900000″

applicationLostTime=”30000″

normalPrimerWorkFlow=”normalPrimer”

gracefulShutdownWorkFlow=”gracefulShutdown”

takeControlWorkFlow=”takeControl”>

<failOverService enable=”true”

description=”HalfSite A.A”

surfaceClusterWorkFlowURL=”https://___hostnameBackend_A_A___:54444/”>

<healthCheck enable=”true”

description=”primary application HalfSite A.A”

address=”___hostnameBackend_A_A___”

port=”80″

uriPath=”/”

SSL=”false”/>

</failOverService>

<failOverService enable=”true”

description=”HalfSite B.B”

surfaceClusterWorkFlowURL=”https://___hostnameBackend_B_B___:54444/”>

<healthCheck enable=”true”

description=”Secondary application HalfSite B.B”

address=”___hostnameBackend_B_B___”

port=”80″

uriPath=”/”

SSL=”false”/>

</failOverService>

</healthCheckServicesPolicy>

I parametri relativi al paragrafo <healthCheck> indicano le modalità di HealthCheck delle applicazioni. Possono esserci più paragrafi <healthChekh> ed il fallimento di uno solo di questi HealthCheck determina lo stato di verifica di raggiungimento del quorum decisionale per lo switch. Ovviamente se alla verifica successiva ed entro i limiti del parametro applicationLostTime l’HealthCheck dovesse tornare ad essere positivo tutti i Decision Engine ritorneranno in normale verifica facendo rientrare lo stato di criticità.

enable=:default=”false”

Se true questo paragrafo namespace è attivo. Se false il paragrafo non viene preso in considerazione.

description=:default=””

Descrizione sintetica dell’HealthCheck.

address=: valore di default=””

E’ l’indirizzo su cui viene effettuato l’health check..

port=: valore di default=”0”

E’ la porta su cui risponde il servizio di health check. Se <=0 verrà eseguito un check ICMP

SSL=: valore di default=”false”

Se impostato a true esegue l’healt check del servzio attraverso una connessine SSL (HTTPS).

uriPath=: valore di default=””

E’ l’URIPath su cui risponde il servizio di health check. Se non presente verrà eseguito un health check TCP con connessione.

LBL®Commander Decision Engine Start/Stop/Manage Status

LBL®Commander Decision Engine è un motore decisionale pensato per avere pochissima manutenzione e soprattutto un bassissimo impatto operativo. Il management delle operazioni è completamente affidato alle interfacce Web utilizzabili attraverso una qualsiasi istanza LBL®Monitor opportunamente istruita. Dopo aver impostato i parametri di contesto allo start LBL®Commander Decision Engine esegue l’inizializzazione degli stati per verificare le condizioni di stato applicativo e di ambiente.

E’ possibile verificare questi stati attraverso l’interfaccia Web:

In questa fase vengono avviati in parallelo i controlli applicativi e di ambiente. Una volta ultimati i controlli lo stato del nodo LBL®Commander Decision Engine cambia dando l’esatta immagine dello stato dell’ambiente su cui è stato impostato il controllo applicativo.

Appena terminata l’inizializzazione se tutto l’ambiente è stato impostato nella maniera corretta e non ci sono anomalie riscontrate ad un successivo refresh sarà visualizzata la seguente situazione:

Nessun quadrante di stato deve essere colorato di rosso o giallo. La colorazione rossa indica una anomalia importante mente una colorazione gialla indica una anomalia che non compromette la facoltà decisionale.

Per verificare se le impostazioni effettuate sono corrette è sufficiente seguire gli HiperLink come in questo caso: groupName->SCDEGroup

Questa visualizzazione ci evidenzia su quale nodo è attiva l’applicazione. In questo caso il sito applicativo primario (A.A) è up and running mentre correttamente il sito secondario non ha l’applicazione attiva. Questa ovviamente è la condizione normale, se fosse attiva anche l’applicazione sul sito secondario (B.B) saremmo in una situazione di Split Brain applicfativo. Volendo simulare questa condizione proviamo ora a eseguire lo start dell’istanza Apache Tomcat anche sul sito secondario…

Su LBL®Commander Work Flow del sito secondario eseguiamo lo start manuale di Apache Tomcat…

Immediatamente tutte le istanze LBL®Commander Decision Engine rilevano l’anomalia segnalandola sui log attraverso e-mail e post HTTP. Inoltre in questa situazione LBL®Commander Decision Engine si pone in stato di inconsistenza e quindi di impossibilità a prendere una decisione.

LBL®Commander Decision Engine è stato progettato per lavorare in contesti geografici e mantiene un comportamento decisionale conservativo identificando le situazioni in cui non gli è possibile prendere delle decisioni autonome per insufficienza di informazioni o identificando situazioni di inconsistenza.

Sempre attraverso l’interfaccia Web operiamo su LBL®Commander Work Flow per ripristinare la situazione ed eliminare la segnalazione di stato SPLIT BRAIN:

Eseguiamo il Work Flow “gracefulShutdown” nel sito secondario…

…le istanze LBL®Commander Decision Engine rilevano l’avvenuto ripristino di una situazione coerente…

Proviamo ora a generare un problema eseguendo uno stop forzato dell’istanza Apache Tomcat sul sito primario….

Immediatamente le istanze LBL®Commander Decision Engine rileveranno il problema…


regolati da lease-time completamente impostabili in relazione all’applicazione e all’ambiente operativo le istanze LBL®Commander Decision Engine verificano se la condizione anomala è una condizione di effettivo evento di errore oppure è stata causata da un evento sporadico e una volta verificata la persistenza dell’evento di errore e verificata la condizione per poter prendere delle decisioni “autonome” le istanze LBL®Commander Decision Engine pongono definitivamente in stato di “Failure” il nodo/sito fonte del problema…

tutte le decisioni prese dalle istanze LBL®Commander Decision Engine sono parte di un sofisticato motore decisionale con rilevazione parallela degli eventi provenienti dall’ambiente circostante ed in ogni momento le azioni si susseguiranno in maniera autonoma ma coerente in tutti i nodi decisionali….

…una volta che i nodi decisionali superstiti raggiungono la coerenza di informazioni relative alla dichiarazione esplicita di “down” dell’applicazione in autonomia ed in concorrenza cercano di ripristinare una situazione applicativa di operatività…

…le operazioni che seguono la dichiarazione di “down” del sito primario sono un ultimo tentativo di eseguire comunque sul sito primario uno shutdown controllato per cercare se possibile di minimizzare i problemi dovuti a un take-over forzato.

…dopo aver eseguito lo shutdown controllato delle applicazioni nel sito primario LBL®Commander Decision Engine attende per un tempo ragionevole che il nodo/sito primario abbiano potuto effettuare le loro operazioni di spegnimento controllato….

….ed in ogni caso superato il tempo limite viene forzato il take-over dei servizi sul nodo/sito secondario…. attesa dello startup dell’applicazione sul sito secondario.

ritorno alla normalità operativa e ovviamente segnalando lo stato di errore del sito secondario…

LBL®Commander Decision Engine ripristino guidato applicativo

LBL®Commander Decision Engine è un motore decisionale pensato per avere pochissima manutenzione e soprattutto un bassissimo impatto operativo. Il management delle operazioni è completamente affidato alle interfacce Web utilizzabili attraverso una qualsiasi istanza LBL®Monitor opportunamente istruito. Ad un evento di failure applicativo LBL®Commander Decision Engine utilizza degli indicatori persistenti e distribuiti sui diversi nodi come traccia dell’evento.

Per ripristinare la situazione alla normalità operativa con il sito principale attivo ed il sito secondario in replica è sufficiente operare attraverso le interfacce Web di LBL®Commander Decision Engine e LBL®Commander Work Flow.

Volendo ad esempio ripristinare l’operatività sul sito principale dell’istanza Apache Tomcat è sufficiente eseguire lo stop logico dei motori decisionali per quel gruppo di applicazioni….

Lo stop dei motori decisionali non influisce minimamente con le istanze LBL®Commander Work Flow ed è quindi possibile in qualsiasi momento fermare i motori decisionali.

Fermando i motori decisionali è possibile gestire in maniera guidata attraverso le istanze LBL®Commander Work Flow le attività di ripristino senza dover intervenire direttamente sui nodi ma attivando le procedure (Work Flow) previste per il ripristino.

Dovendo ripristinare manualmente la situazione iniziale con Apache Tomcat in esecuzione sul nodo/sito principale una volta fermati logicamente i motori decisionali è sufficiente andare sul sito secondario ed effettuare le operazioni in senso contrario: gracefulShutdown dell’applicazione sul sito secondario e quindi takeControl sul sito principale.

Prima di effettuare le operazioni sui nodi/siti applicativi assicurarsi che tutte le istanze LBL®Commander Decision Engine relative al gruppo applicativo, SCDEGroup in questo caso, siano nello stato di STOPPED:

A questo punto una volta appurato che i motori decisionali per il gruppo applicativo sono stati posti in stato di STOPPED si potrà procedere con il ripristino della condizione iniziale.

Da questo momento in poi l’operatività è stata ripristinata da un punto di vista operativo.

Ci resta solo da riportare i motori decisionali in uno stato utile al prossimo evento di failure… Ritornando sulle istanze LBL®Commander Decision Engine fermate all’inizio del processo di ripristino si noterà che sulla destra è stata resa disponibile una X. Questo pulsante serve ad eliminare tutti i flag persistenti di indicazione di failure sui nodi/sedi. Eseguire il clean dei flag di persistenza su tutti i nodi LBL®Commander Decision Engine.

La situazione dovrebbe apparire in tutti i nodi nella seguente situazione: 0 BrokenApps e il pulsante X non più abilitato. ATTENZIONE: Accertarsi che tutti i motori decisionali siano stati ripuliti dei flag di persistenza. I flag di persistenza vengono propagati automaticamente su tutti i nodi e quindi nel caso ne permanga anche sono uno nei tre nodi LBL®Commander Decision Engine anche tutti gli altri nodi all’avvio lo erediterebbero causando un nuovo “takeControl” del sito secondario.

Una volta appurato che tutti i nodi LBL®Commander Decision Engine sono allineati dal punto di vista flag di persistenza (a zero) è sufficiente riavviarli senza un particolare ordine di avvio…


Dopo lo start del primo motore decisionale si avrà una Wrong Condition determinata dal fatto che è il solo motore decisionale operativo…

Già da questo avvio però viene rilevata l’operatività delle applicazioni sul sito principale….

Avviando quindi il secondo motore decisionale si ripristinerà la situazione in cui i motori sono in grado di prendere delle decisioni autonome….

Lo stato dell’HeartBeat di colore giallo indica che non tutti i motori decisionali sono operativi ma che già da questo momento le due istanze possono prendere delle decisioni autonome….

Lo start anche del terzo motore decisionale riporta tutto allo stato iniziale….

LBL®Commander Restart phase

Dalla release 7.1 LBL®Commander Decision Engine gestisce una fase intermedia tra la rilevazione dell’avaria e lo switch in un altro nodo/sito dell’operatività. Questa fase intermedia, opzionale, comanda un Restart per verificare se con un intervento meno invasivo dello switch over si riesce a ristabilire il funzionamento originale.

Questa fase è stata introdotta verificando sul campo che molto spesso è sufficiente un restart degli application server o del Database, o di entrambi, per risolvere i problemi che si erano manifestati.

L’implementazione di questa fase prevede come prima cosa lo sviluppo dei Workflow di restart e quindi la loro impostazione sui motori decisionali.

  • Sviluppo del Workflow di Restart

Lo sviluppo del Workflow di Restart prevede di eseguire uno stop “graceful” dell’ambiente operativo con successivo start al termine del quale si verificherà nuovamente l’operatività applicativa complessiva. Questa fase è contraddistinta da due importanti considerazioni, la prima è sicuramente che il restart non sia già stato eseguito in un momento relativamente vicino per non innescare restart a catena, l’altra considerazione è quella di eseguire comunque un fail-over se tutte le procedure di restart non fossero andate a buon fine.

La soluzione per non innescare restart a catena è molto semplice da implementare in quanto in uno Step di LBL®Commander Work Flow è possibile impostare un’attesa prima di eseguire lo Step. Con questo parametro è sufficiente inserire un’attesa nell’ultimo Step del Workflow di Restart per non incorrere in restart multipli. Il calcolo del tempo di attesa prima di rendere disponibile nuovamente il Workflow ad un altro eventuale comando di Restart deve essere effettuato come di seguito:

La formula è ovviamente orientativa e tende ad evidenziare che il tempo totale di attesa nell’ultimo Step di un Workflow di Restart deve essere superiore al tempo di attesa della promozione del fail-over su altro nodo/sito. Utilizzando questo semplice accorgimento si è sicuri di non incorrere in Split Brain causati dallo start contemporaneo delle applicazioni sui due siti e si è anche sicuri di non incorrere in Restart multipli a catena di una applicazione ormai compromessa.

Si può allungare il tempo totale di attesa nell’ultimo Step a piacere. Se ad esempio l’applicazione che si vuole verificare richiede normalmente un restart ogni due giorni, si può dedurre che provocare un ulteriore Restart a causa di rilevazione di malfunzionamenti nell’arco delle 6 ore successive al precedente Restart possa essere considerato come un problema al “sistema” e non all’applicazione.

Al rilevamento di un ulteriore evento di failure e conseguente comando di Restart, ad opera dei Server LBL®Commander Decision Engine, nella finestra temporale delle 6 ore dal precedente Restart, essendo il Workflow ancora in attesa nell’ultimo Step non verrà ulteriormente eseguito. Scaduto il tempo di lease, impostatto in LBL®Commander Decision Engine, della dichiarazione di failure applicativa verrà promosso il fail over su un altro nodo/sito.

Per sviluppare il Workflow di Restart è probabilmente sufficiente utilizzare parte degli Step del Workflow di gracefulShutdown e parte degli Step del Workflow normalPrimer evidenziando maggiormente la riusabilità dei moduli di script precedentemente creati.

Negli ultimi Step, normalmente normalEnd o abEnd sarà sufficiente inserire il parametro waitBeforeExecute=”21600000

  • Impostazione del Restart in LBL®Commander Decision Engine

L’impostazione della fase di Restart nei parametri dei motori decisionali è molto semplice perché aggiunge solamente i nuovi parametri applicationLostTimeBeforeRestart e restartWorkFlow rispettivamente il tempo di lease tra la rilevazione dell’avaria e il momemnto del Retsart ed il nome del Workflow di Restart da richiamare. Di seguito un frammento di file parametri surfaceclusterde.xml (per maggiori dettagli vedere il documento di Reference Guide):

LBL®Commander Decision Engine Split Brain Assassin

Questo servizio gestisce, in ambienti cluster distribuiti e paritetici (stretch cluster), eventuali possibilità di Split Brain.

LBL®SCDE Split Brain Assassin ha pochissimi parametri ed è quindi utilizzabile con grande semplicità. Semplicità necessaria in questi casi.

Di norma LBL®SCDE Split Brain Assassin sarà configurato nei nodi che hanno le istanze LBL®ADC. Questo perché lo scopo principale di LBL®SCDE Split Brain Assassin è quello di notificare allo strato ADC di escludere l’accesso ad alcuni servizi fino ad escludere l’intero traffico eliminando ogni possibile interazione con il backend.

Il servizio LBL®SCDE Split Brain Assassin sarà attivato per ultimo, dopo aver installato e configurato lo strato di bilanciamento LBL®Commander Decision Engine, LBL®Commander Work Flow e provato tutto l’insieme. Solo allora si valuterà la possibilità di Split Brain geografici, vedi LBL®White Paper per una esaustiva spiegazione, e si procederà con l’installazione e avvio di LBL®SCDE Split Brain Assassin.

I passi necessari per la configurazione di LBL®SCDE Split Brain Assassin sono così sintetizzati:

1- Verifcare che sia stata impostata la licenza d’uso LBL®Commander Decision Engine

(LBL_HOME)/lib/confSurfaceClusterDE/license.xml

2- Impostazione del file di configurazione del servizio

(LBL_HOME)/lib/confSurfaceClusterDE/splitbrainassassin.xml

Ci sono due paragrafi principali, il primo è, come di norma, il paragrafo <params>. Questo paragrafo definisce i comportamenti generici come la frequenza di HealthCheck e alcuni parametri di default.

Per prima cosa bisogna identificare i bersagli motivo di health check. Questi bersagli vengono facilmente identificati nei due nodi LBL®SCDE, il paritetico ed il Quorum. LBL®SCDE Split Brain Assassin solamente in mancanza di entrambi i bersagli (o tutti i bersagli se più di due) notificherà l’evento critico a LBL®ADC tramite impostazione dei file di notifica.

LBL®SCDE Split Brain Assassin può essere impostato per notificare a LBL®ADC una completa disconnessione di tutti i servizi, attraverso l’eliminazione degli indirizzi virtuali, oppure per escludere solo parte dei servizi interessati all’evento.

Esempio del file di configurazione: splitbrainassassin.xml

<splitbrainassassin>

<params

frequency=”10000″

createConnectionTimeOut=”4000″

numRetryConnection=”3″>

</params>

<decisionEnginesPeers>

<peer enable=”true”

description=”Sys 001″

URL=”https://peerOne:54445/” <==== Modificare

healthCheckUriPath=”/HealthCheck?decisionEngine=SCDEGroup”/>

<peer enable=”true”

description=”Sys 002″

URL=”https://peerTwo:54445/” <==== Modificare

healthCheckUriPath=”/HealthCheck?decisionEngine=SCDEGroup”/>

<notification fileName=”lib/notificationDir/outOfOrder.systemsMonitorGroup” description=”All vips”/>

<notification fileName=”lib/notificationDir/outOfOrder.gr1″ enable=”false”/>

<notification fileName=”lib/notificationDir/outOfOrder.gr2″/>

<notification fileName=”lib/notificationDir/outOfOrder.gr3″/>

<notification fileName=”lib/notificationDir/outOfOrder.gr4″/>

</decisionEnginesPeers>

<sysobserver>

<service name=”syslog” id=”syslogsplitbrainassassin”/>

</sysobserver>

</splitbrainassassin>

</serviceconf>

3- Eseguire lo start del processo e verificare i log:

3- Impostazione lo start automatico del servizio

(LBL_HOME)/lib/confMonitor/A03_LBLGoSurfaceClusterWFRemoteBatch.xml

<A03_LBLGoSurfaceClusterDESplitBrainAssassin>

<!–

start: automatic (default), manual

–>

<process enable=”true”

description=”LBL(r)Commander Split Brain Assassin”

start=”automatic” <===== Modificare da “manual” ad “automatic”

numberTryStartOnFailure=”-1″

waitBeforeKill=”60000″

waitBeforeKillOnFailure=”10000″>

<start osName=”Windows”>

<env>CLASSPATH=.;lib;lib\LBLADC.jar</env>

4- Eseguire la stessa operazione negli altri nodi di bilanciamento…

NOTA:

Per avere un test più attendibile è possibile aggiungere degli HealthCheck su altri servizi. A questo scopo nell’esempio di seguito si è provveduto a verificare anche un servizio di HelthCheck offerto da LBL Commander Work Flow Remote Batch.

<peer enable=”true”

description=”Sys 002″

URL=”https://peerTwo:54445/

healthCheckUriPath=”/HealthCheck?decisionEngine=SCDEGroup”/>

<peer enable=”true”

description=”Sys 002″

URL=”https://peerTwo:5994/” <==== Modificare

healthCheckUriPath=”/RemoteBatch/startBartch.xml”/> <=== modificare

ATTENZIONE

Una volta che LBL®SCDE Split Brain Assassin ha impostato i file di notifica questinon verranno più eliminati. Per eliminare i file di notifica è necessario spegnere il processo LBL®SCDE Split Brain Assassin attrraverso la WebConsole.

Questo comportamento serve a garantire la coerenza dell’instradamento anche dopo un eventuale ripristino della rete.

Sei interessato alle nostre soluzioni?