Niente è impossibile da capire, se lo spieghi bene!

Evoluzione dell’alta affidabilità su Linux: creare un cluster Tomcat utilizzando la soluzione nativa, Heartbeat e Pacemaker

di | 24 gennaio 2011

        

Tomcat è un Application Server: un contenitore di applicazioni sviluppate attraverso il linguaggio di programmazione Java. Tomcat viene impiegato generalmente per l’esposizione di web service e questa sua attitudine, in caso di applicazioni critiche per importanza, deve essere obbligatoriamente associata all’alta affidabilità. Esso nativamente supporta un modello di cluster, che consente a diverse istanze di condividere le sessioni, in modo da garantire la sopravvivenza del servizio: se quindi un’istanza smette di funzionare, il suo ruolo viene assunto dall’istanza sopravvissuta.
Ma chi si occupa del controllo delle istanze stesse?
Questo articolo descrive un caso di studio relativo ad un cluster nativo Tomcat le cui istanze vengono gestite da Heartbeat attraverso il Cluster Resource Manager Pacemaker.

Installazione di Java

Java è essenziale per il funzionamento di Tomcat ed è anche il primo software da configurare per ottenere il risultato prefissato in questo articolo. Per prima cosa quindi sarà necessario scaricare il pacchetto di installazione dal sito ufficiale di SUN presso il link http://www.java.com/it/download/linux_manual.jsp?locale=it&host=www.java.com.
Ottenuto il file jre-6u23-linux-i586.bin, il cui nome potrà variare a seconda della versione, questo va eseguito:

# chmod +x jre-6u23-linux-i586.bin 
# ./jre-6u23-linux-i586.bin

L’esecuzione del file creerà una cartella nominata jre1.6.0_23 che sarà possibile spostare in un path consono, ad esempio /usr/local, per il quale potrà essere creato un link simbolico:

# mv jre1.6.0_23 /usr/local
# ln -s /usr/local/jre1.6.0_23 /usr/local/java

In questo modo sarà possibile far riferimento al path /usr/local/java per il raggiungimento degli eseguibili java ed inoltre, in caso di installazioni di versioni diverse di Java, basterà cambiare il puntamento del link simbolico.

Installazione di Tomcat

L’installazione di Tomcat viene descritta in maniera generalista, indipendente quindi dalla distribuzione utilizzata.
Per prima cosa quindi è necessario scaricare l’ultima versione dell’application server Tomcat, andando sul sito ufficiale di Tomcat (http://tomcat.apache.org/download-70.cgi) oppure scaricando il pacchetto da uno dei mirror:

# wget http://it.apache.contactlab.it/tomcat/tomcat-7/v7.0.6/bin/apache-tomcat-7.0.6.tar.gz -o /tmp/apache-tomcat-7.0.6.tar.gz

una volta terminato lo scaricamento, è possibile decomprimere il pacchetto in un path di sistema, ad esempio (e per convenzione) /usr/local:

# cd /usr/local
# tar -xzvf /tmp/apache-tomcat-7.0.6.tar.gz
# ln -s apache-tomcat-7.0.6 tomcat

L’ultimo comando lanciato crea un link simbolico, in modo che in futuro per accedere alla directory di Tomcat sarà sufficiente utilizzare il percorso /usr/local/tomcat.

Installazione di Heartbeat e Pacemaker

L’installazione dell’apparato cluster offerto dal progetto Linux-ha non verrà descritta in questo articolo, in quanto ampiamente trattata nei precedenti articoli della serie, in particolare nella puntata confronto pratico tra Heartbeat classico ed Heartbeat con Pacemaker.

Configurazione di Tomcat

La configurazione prevede due fasi: la prima relativa alle credenziali di accesso, la seconda relativa alle impostazioni per il clustering.
All’interno del file /usr/local/tomcat/conf/tomcat-users.xml sono definite le utenze di accesso alle diverse componenti dell’application server, in particolare, per permettere all’utente tomcat di gestire l’installazione di nuove applicazioni attraverso l’interfaccia web disponibile, il contenuto del file dovrà essere il seguente:

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
  <role rolename="tomcat"/>
  <role rolename="manager-gui"/>
  <user username="tomcat" password="tomcat" roles="manager,manager-gui,tomcat"/>
</tomcat-users>

Inutile dire come il campo password debba essere modificato in base alla password scelta.
L’abilitazione del cluster Tomcat, data la natura introduttiva dell’articolo, verrà fatta nella modalità più semplice, così come illustrato dalla documentazione ufficiale di Tomcat (http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html), abilitando cioè la seguente riga all’interno del file /usr/local/tomcat/conf/server.xml:

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>

La configurazione preliminare dell’application server è così completa.

Configurazione di Heartbeat e Pacemaker

Appena avviato il demone Heartbeat:

# /etc/init.d/heartbeat start

è possibile definire le configurazioni preliminari del cluster:

# crm configure property stonith-enabled="false"
# crm configure property no-quorum-policy="ignore"
# crm configure primitive ping ocf:pacemaker:ping params host_list="192.168.0.254" name="ping" op monitor interval="10s" timeout="60s" op start timeout="60s" op stop timeout="60s"
# crm configure clone ping_clone ping meta globally-unique="false"

Come spiegato nei precedenti articoli queste configurazioni preliminari indicano di non utilizzare stonith, ignorare l’assenza di quorum e creare una risorsa ping che controlli la connettività in entrambi i nodi attraverso il clone della risorsa stessa.
Maggiori informazioni e spiegazioni approfondite si trovano nella seconda parte del secondo articolo della serie.
In particolare l’ultima definizione, ossia la risorsa clonata per il controllo della connettività, favorisce lo spunto per la configurazione della risorsa Tomcat per la quale esiste un resource agent apposito: http://www.linux-ha.org/doc/re-ra-tomcat.html. Essendo obiettivo del progetto la gestione per mezzo di Pacemaker delle istanze di Tomcat, ed essendo le istanze di Tomcat in tutto e per tutto simili su entrambi nodi, queste potranno essere assimilate ad un’unica risorsa clonata.
Nel dettaglio, la configurazione sarà la seguente:

1
2
3
crm configure primitive cluster_tomcat ocf:heartbeat:tomcat params java_home="/usr/local/java/" catalina_home="/usr/local/tomcat/" op monitor interval="60s" timeout="30s" op start interval="0" timeout="60s" op stop interval="0" timeout="120s"
crm configure clone cluster_tomcat_clone cluster_tomcat meta globally-unique="false" target-role="Started"
crm configure location cluster_tomcat_on_connected_node cluster_tomcat_clone -inf: not_defined ping or ping lte 0

Nel dettaglio:

  1. Viene definita la risorsa cluster_tomcat i cui parametri sono il path in cui è installato Java (java_home) ed il path di tomcat stesso (catalina_home);
  2. La risorsa cluster_tomcat viene clonata dalla nuova risorsa cluster_tomcat_clone. Così come per la risorsa ping_clone che risiederà su ciascun nodo definito, anche questa avrà lo stesso comportamento;
  3. Viene definita una location, ossia un vincolo che obbliga la risorsa clonata a funzionare unicamente sui nodi la cui connettività è comprovata (nodi su cui cioè la risorsa ping esiste e restituisce un risultato positivo);

A questo punto, la situazione del cluster dovrebbe essere la seguente:

============
Last updated: Mon Jan 24 10:17:05 2011
Stack: Heartbeat
Current DC: tomcatcluster-nodo2 (b091eddc-aa64-4d7d-8407-65a7dddafbdf) - partition with quorum
Version: 1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3
2 Nodes configured, unknown expected votes
2 Resources configured.
============
 
Online: [ tomcatcluster-nodo1 tomcatcluster-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ tomcatcluster-nodo1 tomcatcluster-nodo2 ]
 Clone Set: cluster_tomcat_clone
     Started: [ tomcatcluster-nodo1 tomcatcluster-nodo2 ]

Ed entrambe le istanze di Tomcat dovrebbero essersi avviate su ciascun nodo. E’ possibile verificarlo provando ad accedere all’interfaccia web di amministrazione presente su ciascun nodo:

http://tomcatcluster-nodo1:8080/manager/html
http://tomcatcluster-nodo2:8080/manager/html

Entrambi link dovrebbero essere funzionanti e richiedere uno username con password per accedervi. Una volta inserite le credenziali definite in fase di configurazione di Tomcat, sarà visibile l’interfaccia di amministrazione delle applicazioni.

Analisi dei log

L’avvio dei servizi Tomcat da parte del cluster può essere seguito dai file di log dell’application server stesso, all’interno dei quali è possibile verificare se il cluster nativo di Tomcat viene attivato correttamente.

# cat /usr/local/tomcat/logs/catalina.out
...
INFO: Cluster is about to start
...
INFO: Setting cluster mcast soTimeout to 500
...
INFO: Server startup in 3153 ms
...
21-gen-2011 17.05.47 org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
INFO: Replication member added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{192, 168, 0, 1}:4000,{192, 168, 0, 2},4000, alive=1259, securePort=-1, UDP Port=-1, id={101 64 89 59 2 -44 67 123 -73 23 4 -50 -57 105 8 58 }, payload={}, command={}, domain={}, ]
...

Il server è avviato e certamente ha considerato la configurazione, includendo l’host (memberAdded) 192.168.0.52 nel cluster.

Configurazione applicazione di Test

La configurazione può dirsi completa. E’ possibile quindi installare una semplice applicazione di test per verificare nell’effettivo il funzionamento delle sessioni condivise. Per fare ciò è sufficiente creare un’applicazione configurata con il parametro “” che indica al cluster di sfruttare la configurazione cluster per la condivisione delle sessioni.
L’applicazione TestSession, scaricabile dal portale è stata configurata proprio a questo scopo:

TestSession

Una volta scaricato il file TestSession.war, attraverso la console Tomcat e su ciascun nodo, sarà possibile installare l’applicazione nella sezione “WAR file to deploy”, selezionando il fie “war” scaricato e premendo il tasto “deploy”. Se l’esito sarà “OK”, entrambe le applicazioni saranno disponibili attraverso l’indirizzo:

http://tomcatcluster-nodo1:8080/TestSession
http://tomcatcluster-nodo2:8080/TestSession

E’ possibile dunque avviare i test.

Test di funzionamento

Il principio di funzionamento del cluster è quello di rispondere alle richieste. Generalmente in questo tipo di architettura, gli Application Server risiedono dietro a bilanciatori, cioè apparati hardware o software che distribuiscono il carico attraverso batterie di macchine che offrono servizi.
L’architettura di test predisposta non prevede l’utilizzo di un bilanciatore, a per simulare il bilanciamento del carico tra i due host sarà sufficiente inserire nel file /etc/hosts della propria macchina queste due righe:

192.168.0.1 tomcatcluster
#192.168.0.2 tomcatcluster

Come scritto in precedenza quindi, l’applicazione potrà essere chiamata come segue, senza far riferimento all’IP:

http://tomcatcluster:8080/TestSession/

Il test funzionerà in modo che chiamato l’url relativo al quale si passa un parametro, ad esempio:

http://tomcatcluster:8080/TestSession/session.jsp?aaa=111

la pagina visualizzi quanto segue:

Server info
 
    * Name: tomcatcluster-nodo1
    * Address: 192.168.0.1
 
Session Attributes
 
    * aaa = 111

Ovviamente le chiamate successive con parametri differenti aggiungeranno nuovi attributi.
Nella fattispecie, chiamare:

http://tomcatcluster:8080/TestSession/session.jsp?bbb=222

produrrà:

Server info
 
    * Name: tomcatcluster-nodo1
    * Address: 192.168.0.1
 
Session Attributes
 
    * aaa = 111
    * bbb = 222

Il test a questo punto è semplicissimo, modificando il file /etc/hosts in modo che appaia come segue:

#192.168.0.1 tomcatcluster
192.168.0.2 tomcatcluster

Di fatto il secondo nodo ora sarà quello attivo. Richiamando nuovamente lo script:

http://tomcatcluster:8080/TestSession/session.jsp?ccc=333

Si otterrà il seguente output:

Server info
 
    * Name: tomcatcluster-nodo2
    * Address: 192.168.0.2
 
Session Attributes
 
    * aaa = 111
    * bbb = 222
    * ccc = 333

Da notare come nel Server info ora il nodo sia tomcatcluster-nodo2, mentre i dati di sessione sono stati mantenuti.

Il corretto funzionamento è verificabile anche accedendo singolarmente a ciascun tomcat ai link presenti nella pagina manager nella colonna “Sessions”, dove vengono elencate le sessioni, che ovviamente hanno lo stesso codice su entrambi gli Application server.

Conclusioni

Terminata questa carrellata di concetti e test una cosa è chiara: come sempre questo è solo l’inizio. Sono moltissimi gli ambiti in cui soluzioni come (o simili) a quella presentata possono essere messe in produzione per ottenere infrastrutture stabili, sicure e funzionali. Sempre e comunque altamente affidabili.

Clustering Heartbeat Linux HA Pacemaker Tomcat

Stampa questo articolo Stampa questo articolo

Commenti [43]
  • 25 gennaio 2011 | 10:50
    Paolo Mancuso

    Ottimo veramente, complimenti per l’articolo….

  • 25 gennaio 2011 | 10:57
    Raoul Scarazzini

    Grazie dei complimenti Paolo, se ti è piaciuto questo articolo, non perdere i prossimi su KVM in alta affidabilità con Heartbeat e Pacemaker.

    A presto!

  • 10 febbraio 2011 | 10:25
    Davide

    Ciao, complimenti per l’articolo è molto utile; vorrei se possibile fare una richiesta; avrei intenzione di mettere su 2 server ubuntu al fine di creare un cluster in alta disponibilità per squid per circa 500 client, utilizzando heartbeat e pacemaker, solo che allo stato attuale non sono ancora riuscito a realizzarlo, per cui se fosse possibile potreste scrivere un articolo al fine di realizzare tale progetto per chiarirmi così le idee?
    Grazie!

  • 10 febbraio 2011 | 10:55
    Raoul Scarazzini

    Ciao Davide e grazie per i complimenti. Sicuramente a breve nuovi articoli proseguiranno la serie cluster, ed il tema che proponi è di sicuro interesse, perciò contaci!
    Considera se vuoi iniziare a fare delle prove, che la filosofia di base per realizzare quanto chiedi è molto simile a quanto descritto in questo articolo: si potrebbero gestire i due processi Squid come illustrato qui con Tomcat ed attraverso la configurazione del proxy, condividere la cache (è un’opzione supportata da Squid).
    Ancora più interessante potrebbe essere il bilanciamento di carico a monte dei due proxy, magari fatto ancora in Linux con LVS.
    Facci sapere se fai delle prove e stai certo, la pulce nell’orecchio ce l’hai messa.

    A presto! ;-)

  • 11 febbraio 2011 | 13:35
    Davide

    Grazie per la risposta! in realtà tempo fa ho già effettuato delle prove, basandomi su un vostro vecchio articolo titolato “Evoluzione dell’alta affidabilità su Linux: confronto pratico tra Heartbeat classico ed Heartbeat con Pacemaker”; ho messo quindi su 2 server ubuntu con servizio heartbeat e pacemaker insieme, i due server erano configurati con indirizzamento statico tramite crm, successivamente ho configurato l’ip virtuale tra i due in modo da permettere, in caso di down di uno, lo spostamento del servizio attivo sull’altro e viceversa, infine ho configurato il servizio squid per entrambi impostando la dovuta regola sul crm di heratbeat;

    ma effettuando i successivi test mi sono accorto che, il servizio ip virtuale ha funzionato a dovere, mentre l’alta disponibilità del servizio squid no; ho provato in lungo e in largo su forum vari senza trovare risposta, per cui ben venga scrivere un bel articolo in cui si spiega in maniera chiara la corretta messa in funzione di un servizio tanto utile, specie quando bisogna assicurare assoluta continuità del servizio internet a un numero considerevole di client.

    Inoltre se posso dare una mano alla creazione di questo articolo…..ben volentieri!
    ;)

  • 11 febbraio 2011 | 16:12
    Paolo Mancuso

    Ciao, i tuoi articoli sono molto interessanti. Vorrei sapere se puoi darmi una mano riguardo ad una problematica che sto affrontando.
    Su heatbeat se volessi far partire un script che si trova nella /home/nomeutente/nomeScript.sh cosa devo fare? Ti ringrazio per l’aiuto….e buon lavoro continua cosi.

  • 14 febbraio 2011 | 11:11
    Raoul Scarazzini

    Ciao Davide,
    quello che non capisco della tua configurazione è: se squid è in una configurazione active/active, che bisogno c’è di aspettarsi il failover del servizio? Non vorrei aver frainteso la tua configurazione, ma se come ti ho scritto rispetti la topologia descritta nell’articolo, quindi Heartbeat/Pacemaker che gestiscono l’avvio ed il monitoring di Tomcat (o Squid che sia) ed il servizio stesso (Tomcat o Squid) configurato in modo che ciascuna istanza veda l’altra, allora non hai bisogno di un virtual IP né di gestire il failover.
    L’unico reale problema che c’è in questa topologia è il puntamento da parte dei client: o davanti c’è un bilanciatore (che quindi distribuisce il carico tra i due squid), oppure ciascuno squid è configurato manualmente su tutti i client, senza però aver alta affidabilità.

    Spero di aver chiarito quali sono i punti oscuri nella questione. Detto questo: se vuoi iniziare a scrivere per MMUL sei il benvenuto. La regola, come più volte detto, è una sola: gli articoli devono descrivere soluzioni realmente riproducibili. Far capire, agendo. Tutto qua, scrivi a info@miamammausalinux.org per farti creare un profilo!

  • 14 febbraio 2011 | 11:18
    Raoul Scarazzini

    Ciao Paolo,
    esiste un resource agent creato appositamente per gestire eseguibili generici che si chiama “anything” http://www.linux-ha.org/doc/re-ra-anything.html il cui scopo è proprio quello di avviare e monitorare processi generici, il cui requisito deve essere unicamente quello di rimanere in esecuzione con un determinato PID, non uscire quindi una volta completate le operazioni. In sostanza, il processo deve comportarsi come un demone.
    Vice versa, se necessiti di eseguire determinati script a determinati orari conviene che ti orienti su crontab. Se questi script devono essere eseguiti sul nodo attivo (in una configurazione active/passive classica), allora dovrai gestire l’analisi del nodo attivo tramite lo script stesso.

    Spero di esser stato chiaro… A presto!

  • 14 febbraio 2011 | 21:37
    Davide

    Ciao Raoul,
    cerco di essere un pò più chiaro; la configurazione è la seguente, c.a 500 client che accedono ad internet unicamente attraverso server proxy, i server proxy fisici sono 2, ed entrambi con indirizzo ip statico privato configurato ed univoco, i client devono puntare ad un terzo indirizzo ip, il virtuale tra i due server;

    tutto ciò al fine di assicurare la continuità del servizio proxy anche in caso di guasto o blocco del servizio su uno dei due nodi server.

    Quindi in pratica il servizio squid resta attivo su entrambi i nodi e heartbeat/pacemaker non dovrebbero fare altro che monitorare tale stato sia del servizio ip virtuale e sia del servizio squid, al fine di mantenere il servizio attivo sul primo nodo attivo dei due.

    Questo è ciò che vorrei realizzare, ma che ancora non sono riuscito a fare, quindi ben vengano i vostri utili consigli….e chissà che non diventi un caso pratico da divulgare!
    A presto!

  • 15 febbraio 2011 | 00:08
    Raoul Scarazzini

    Ok Davide, ora è tutto chiaro. Quanto vuoi fare si può realizzare in due modi:

    1) Usando un bilanciatore software, soluzione non immediata, ma sicuramente performante (utilizzando LVS), potresti seguire la guida di MMUL “Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord” riapplicandola per Squid:

    Parte 1, 2, 3 e 4

    2) Utilizzando un indirizzo IP clonato sulle due istanze, così come viene spiegato nel documento “Clusters From Scratch” che dice:

    Cloned IPaddr2 resources use an iptables rule to ensure that each request only processed by one of
    the two clone instances. The additional meta options tell the cluster how many instances of the clone we want
    (one “request bucket” for each node) and that if all other nodes fail, then the remaining node should hold all of
    them. Otherwise the requests would be simply discarded.

    La dichiarazione sarà simile alla seguente:

    configure clone SquidBalancedIP SquidIP meta globally-unique=”true” clone-max=”2” clone-node-max=”2”

    La scelta, come sempre con Linux, è tua!

  • 17 febbraio 2011 | 15:38
    Paolo Mancuso

    Ciao Raul ti ringrazio per la risposta, solo che non sono riuscito a trovare il resourc agent che mi hai indicato nelle pagina, sembra che la pagina sia stata rimossa…comunque l’idea è proprio quella di avere un agent che faccia avviare il programma che si comporta come un demone….non sò dove andarlo a prendere…e purtroppo ne capisco poco di programmazione lsb…:(

  • 17 febbraio 2011 | 15:43
    Raoul Scarazzini

    Confermo che la pagina è stata mossa in questo nuovo link: http://www.linux-ha.org/doc/man-pages/re-ra-anything.html con questa dovresti essere a posto!

    Considera che la patch sul parametro workdir l’ho postata proprio io, quindi assicuro che funziona ;-)

  • 17 febbraio 2011 | 16:52
    Paolo Mancuso

    Raoul ti ringrazio ancora, ma scusa l’ignoranza…ritornando alla domanda originaria. Se ho un’eseguibile che attiva un processo e che sta sulla /home/utente/nomescripts.sh come faccio a metterlo su con heartbeat? Ti ringrazio per la pazienza ma mi piacerebbe capire…

  • 18 febbraio 2011 | 09:11
    Raoul Scarazzini

    Paolo, ecco un esempio su come configurare una risorsa generica in Heartbeat/Pacemaker:

    primitive cluster-batch-auth-server-ip ocf:custom:anything \
    	params user="jboss" binfile="/usr/java/latest/bin/java" cmdline_options="-Xms128m -Xmx521m com/myapp" workdir="/myapp/" \
    	op monitor interval="10s" timeout="20s" depth="0" \
    	op start interval="0" timeout="20s" \
    	op stop interval="0" timeout="20s"

    Si riferisce ad un programma java, ma è applicabile a qualsiasi altro tipo di programma, purché questo rimanga caricato, funzioni cioè come un demone.

  • 18 febbraio 2011 | 13:27
    Davide

    Ciao Raoul, quanto prima vedrò di effettuare le prove seguendo il tuo consiglio e ti farò sapere!
    Grazie!

  • 24 febbraio 2011 | 10:17
    Paolo Mancuso

    Ciao Raoul, volevo chiederti ancora chiarimenti in merito alle istruzioni che mi hai dato. Queste presuppongo se non sbaglio l’utilizzo di pacemaker giusto?….

  • 24 febbraio 2011 | 10:22
    Raoul Scarazzini

    Assolutamente sì!

  • 15 marzo 2011 | 14:16
    Paolo Mancuso

    Ciao Raoul, sono riuscito a creare uno script per l’avvio di un servizio che si trova sotto la cartella /home/utente/applicazione/bin, e sono riuscito a fare in modo che heartbeat, nella configurazione senza pacemaker,lo riconsca e lo avvii alla sua partenza. Purtroppo, e credo che questo sia un limite di HB, se la risorsa viene killata manualmente heartbeat non se ne accorge e non riparte sull’altro nodo. E’ possibile secondo te aggirare l’ostacolo?La mia versione di Heartbeat è la 2. Eventulamente potresti darmi le risorse per installare su una centos 4.8 heartbeat più aggiornato + pacemaker? Ci ho provato e mi spuntano un sacco di errori riguardo a delle dipendenze…..Ti ringrazio.

  • 15 marzo 2011 | 15:01
    Raoul Scarazzini

    Ciao Paolo,
    se usi Heartbeat SENZA Pacemaker l’unica via che hai per effettuare monitoring dei servizi erogati è utilizzare strumenti come MON che ti permettono di monitorare lo stato delle risorse.
    Ovviamente tale strumento va configurato secondo le specifiche del caso relative al tuo progetto.

  • 21 marzo 2011 | 13:10
    Davide

    Ciao Raoul,
    eccomi di nuovo qui, ti aggiorno con tutte le prove che ho effettuato; allora sono riuscito a mettere su il servizio heartbeat con pacemaker, configurando 3 risorse, la prima per il ping verso un ip generico sempre attivo, in modo da far capire a hertbeat che la connettività di rete va bene; la seconda per la risorsa IP vip che fa partire l’ip virtuale condiviso tra i due host, ed infine la risorsa cluster squid;

    le prime due funzionano a dovere, mentre la terza, quella che dovrebbe attivarmi il processo squid nel primo o nel secondo host, non funziona; heartbeat non riesce a far partire squid, di seguito il resoconto del comando “crm status”:

    Last updated: Mon Mar 21 12:52:49 2011
    Stack: Heartbeat
    Current DC: proxy-1 - partition with quorum
    Version: 1.0.9-unknown
    2 Nodes configured, unknown expected votes
    3 Resources configured.
    ============
     
    Online: [ proxy-1 proxy-2 ]
     
     Clone Set: ping_clone
         Started: [ proxy-1 proxy-2 ]
     cluster-ip     (ocf::heartbeat:IPaddr2):       Started proxy-1
     
    Failed actions:
        cluster-squid_start_0 (node=proxy-2, call=5, rc=-2, status=Timed Out): unknown exec error
        cluster-squid_start_0 (node=proxy-1, call=5, rc=-2, status=Timed Out): unknown exec error

    Non so più che pesci prendere, spero che tu riesca ad illuminarmi.
    Grazie!

  • 21 marzo 2011 | 13:38
    Raoul Scarazzini

    Ciao Davide,
    due domande:

    1) che resource agent hai utilizzato per il servizio squid?
    2) cosa dicono i log? Trovi qualcosa di illuminante nel momento in cui il servizio fallisce il suo avvio?

    A presto.

  • 21 marzo 2011 | 17:12
    Davide

    Ciao Raoul,
    grazie per la celere risposta!
    Il resource agent utilizzato è quello fornito da heartbeat, prelevato dalla directory “/usr/lib/ocf/resource.d/heartbeat/Squid”;

    inoltre, per i log, non ho trovato nulla d’interessante.

    Una cosa ho notato, che se faccio un riavvio del sistema, ad avvio completato, il processo squid risulta correttamente avviato, dopo qualche secondo però, quando parte anche heartbeat, sincronizzando i due host, il processo si chiude, ed appare il messaggio di errore che ti ho riportato sopra…..mah!

    Ciao
    Dav

  • 21 marzo 2011 | 17:23
    Raoul Scarazzini

    Questo non è corretto. Se Squid deve essere gestito dal cluster non ha senso che il sistema lo avvii automaticamente. Devi disabilitare l’avvio automatico di Squid e lasciare che sia il cluster ad occuparsi di tutto.

    Credo sia decisamente normale che trovando il processo già avviato il cluster dia errore, cosa ne pensi ;-)

  • 22 marzo 2011 | 12:01
    Davide

    Nulla di fatto purtroppo;
    come suggerito ho disabilitato l’avvio automatico al boot del servizio squid su entrambi i nodi, ma continuo a riscontrare lo stesso problema, di seguito il log estrapolato dal nodo 1:

    ---------------------------------------------
    Mar 22 11:20:02 proxy-1 crmd: [7521]: info: do_lrm_rsc_op: Performing key=17:3:0:28b5e648-efaf-46e7-897b-ffdb29713675 op=cluster-squid_start_0 )
    Mar 22 11:20:02 proxy-1 lrmd: [7518]: info: rsc:cluster-squid:9: start
    Mar 22 11:20:02 proxy-1 squid[7754]: Squid Parent: child process 7756 started
    Mar 22 11:20:02 proxy-1 Squid[7713]: INFO: squid:Waiting for squid to be invoked
    Mar 22 11:20:06 proxy-1 Squid[7713]: INFO: squid:Waiting for squid to be invoked
    Mar 22 11:20:07 proxy-1 Squid[7713]: INFO: squid:Waiting for squid to be invoked
    Mar 22 11:20:13 proxy-1 Squid[7713]: INFO: squid:Waiting for squid to be invoked
    Mar 22 11:20:22 proxy-1 lrmd: [7518]: WARN: cluster-squid:start process (PID 7713) timed out (try 1).  Killing with signal SIGTERM (15).
    Mar 22 11:20:22 proxy-1 lrmd: [7518]: WARN: operation start[9] on ocf::Squid::cluster-squid for client 7521, its parameters: crm_feature_set=[3.0.1] squid_conf=[/etc/squid3/squid.conf] CRM_meta_timeout=[20000] squid_exe=[/usr/sbin/squid3] squid_pidfile=[/var/run/squid3.pid] squid_port=[3366] : pid [7713] timed out
    Mar 22 11:20:22 proxy-1 crmd: [7521]: ERROR: process_lrm_event: LRM operation cluster-squid_start_0 (9) Timed Out (timeout=20000ms)
    Mar 22 11:20:23 proxy-1 attrd: [7520]: info: find_hash_entry: Creating hash entry for fail-count-cluster-squid
    Mar 22 11:20:23 proxy-1 attrd: [7520]: info: attrd_trigger_update: Sending flush op to all hosts for: fail-count-cluster-squid (INFINITY)
    Mar 22 11:20:23 proxy-1 crmd: [7521]: info: do_lrm_rsc_op: Performing key=4:4:0:28b5e648-efaf-46e7-897b-ffdb29713675 op=cluster-squid_stop_0 )
    Mar 22 11:20:23 proxy-1 lrmd: [7518]: info: rsc:cluster-squid:11: stop
    Mar 22 11:20:23 proxy-1 attrd: [7520]: info: attrd_perform_update: Sent update 22: fail-count-cluster-squid=INFINITY
    Mar 22 11:20:23 proxy-1 attrd: [7520]: info: find_hash_entry: Creating hash entry for last-failure-cluster-squid
    Mar 22 11:20:23 proxy-1 attrd: [7520]: info: attrd_trigger_update: Sending flush op to all hosts for: last-failure-cluster-squid (1300789224)
    Mar 22 11:20:23 proxy-1 attrd: [7520]: info: attrd_perform_update: Sent update 25: last-failure-cluster-squid=1300789224
    Mar 22 11:20:24 proxy-1 Squid[8118]: INFO: squid:stop_squid:311:  stop NORM 1/5
    Mar 22 11:20:25 proxy-1 Squid[8118]: INFO: squid:stop_squid:311:  stop NORM 2/5
    Mar 22 11:20:27 proxy-1 Squid[8118]: INFO: squid:stop_squid:311:  stop NORM 3/5
    Mar 22 11:20:28 proxy-1 Squid[8118]: INFO: squid:stop_squid:311:  stop NORM 4/5
    Mar 22 11:20:29 sspa-proxy-1 Squid[8118]: INFO: squid:stop_squid:311:  stop NORM 5/5
    Mar 22 11:20:29 proxy-1 Squid[8118]: INFO: squid:stop_squid:318:  try to stop by SIGKILL:7754
    Mar 22 11:20:30 proxy-1 Squid[8118]: INFO: squid:stop_squid:318:  try to stop by SIGKILL:
    Mar 22 11:20:30 proxy-1 lrmd: [7518]: info: RA output: (cluster-squid:stop:stderr) kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
    Mar 22 11:20:31 proxy-1 crmd: [7521]: info: process_lrm_event: LRM operation cluster-squid_stop_0 (call=11, rc=0, cib-update=18, confirmed=true) ok
    -----------------------------------------------

    ed ecco quello estrapolato dal nodo 2:

    -----------------------------------------------
    Mar 22 11:20:01 proxy-2 pengine: [3427]: notice: native_print:      cluster-squid#011(ocf::heartbeat:Squid):#011Stopped
    Mar 22 11:20:01 proxy-2 pengine: [3427]: notice: RecurringOp:  Start recurring monitor (10s) for cluster-squid on proxy-1
    Mar 22 11:20:01 proxy-2 pengine: [3427]: notice: LogActions: Start cluster-squid#011(proxy-1)
    Mar 22 11:20:02 proxy-2 crmd: [3422]: info: te_rsc_command: Initiating action 17: start cluster-squid_start_0 on proxy-1
    Mar 22 11:20:23 proxy-2 crmd: [3422]: WARN: status_from_rc: Action 17 (cluster-squid_start_0) on proxy-1 failed (target: 0 vs. rc: -2): Error
    Mar 22 11:20:24 proxy-2 crmd: [3422]: WARN: update_failcount: Updating failcount for cluster-squid on proxy-1 after failed start: rc=-2 (update=INFINITY, time=1300789224)
    Mar 22 11:20:24 proxy-2 crmd: [3422]: info: abort_transition_graph: match_graph_event:272 - Triggered transition abort (complete=0, tag=lrm_rsc_op, id=cluster-squid_start_0, magic=2:-2;17:3:0:28b5e648-efaf-46e7-897b-ffdb29713675, cib=0.183.18) : Event failed
    Mar 22 11:20:24 proxy-2 crmd: [3422]: info: match_graph_event: Action cluster-squid_start_0 (17) confirmed on proxy-1 (rc=4)
    Mar 22 11:20:24 proxy-2 pengine: [3427]: WARN: unpack_rsc_op: Processing failed op cluster-squid_start_0 on proxy-1: unknown exec error (-2)
    Mar 22 11:20:24 proxy-2 pengine: [3427]: notice: native_print:      cluster-squid#011(ocf::heartbeat:Squid):#011Started proxy-1 FAILED
    Mar 22 11:20:24 proxy-2 pengine: [3427]: notice: RecurringOp:  Start recurring monitor (10s) for cluster-squid on proxy-1
    Mar 22 11:20:24 proxy-2 pengine: [3427]: notice: LogActions: Recover resource cluster-squid#011(Started proxy-1)
    Mar 22 11:20:24 proxy-2 crmd: [3422]: info: te_rsc_command: Initiating action 4: stop cluster-squid_stop_0 on proxy-1
    Mar 22 11:20:24 proxy-2 attrd: [3421]: info: find_hash_entry: Creating hash entry for fail-count-cluster-squid
    Mar 22 11:20:24 proxy-2 attrd: [3421]: info: find_hash_entry: Creating hash entry for last-failure-cluster-squid
    Mar 22 11:20:31 proxy-2 crmd: [3422]: info: match_graph_event: Action cluster-squid_stop_0 (4) confirmed on proxy-1 (rc=0)
    Mar 22 11:20:31 proxy-2 pengine: [3427]: WARN: unpack_rsc_op: Processing failed op cluster-squid_start_0 on proxy-1: unknown exec error (-2)
    Mar 22 11:20:31 proxy-2 pengine: [3427]: notice: native_print:      cluster-squid#011(ocf::heartbeat:Squid):#011Stopped
    Mar 22 11:20:31 proxy-2 pengine: [3427]: info: get_failcount: cluster-squid has failed INFINITY times on proxy-1
    Mar 22 11:20:31 proxy-2 pengine: [3427]: WARN: common_apply_stickiness: Forcing cluster-squid away from proxy-1 after 1000000 failures (max=1000000)
    Mar 22 11:20:31 proxy-2 pengine: [3427]: notice: RecurringOp:  Start recurring monitor (10s) for cluster-squid on proxy-2
    Mar 22 11:20:31 proxy-2 pengine: [3427]: notice: LogActions: Start cluster-squid#011(proxy-2)
    Mar 22 11:20:32 proxy-2 crmd: [3422]: info: te_rsc_command: Initiating action 19: start cluster-squid_start_0 on proxy-2 (local)
    Mar 22 11:20:32 proxy-2 crmd: [3422]: info: do_lrm_rsc_op: Performing key=19:5:0:28b5e648-efaf-46e7-897b-ffdb29713675 op=cluster-squid_start_0 )
    Mar 22 11:20:32 proxy-2 lrmd: [3419]: info: rsc:cluster-squid:9: start
    Mar 22 11:20:32 proxy-2 squid[3712]: Squid Parent: child process 3714 started
    Mar 22 11:20:32 proxy-2 Squid[3671]: INFO: squid:Waiting for squid to be invoked
    Mar 22 11:20:43 proxy-2 Squid[3671]: INFO: squid:Waiting for squid to be invoked
    Mar 22 11:20:52 proxy-2 lrmd: [3419]: WARN: cluster-squid:start process (PID 3671) timed out (try 1).  Killing with signal SIGTERM (15).
    Mar 22 11:20:52 proxy-2 lrmd: [3419]: WARN: operation start[9] on ocf::Squid::cluster-squid for client 3422, its parameters: crm_feature_set=[3.0.1] squid_conf=[/etc/squid3/squid.conf] CRM_meta_timeout=[20000] squid_exe=[/usr/sbin/squid3] squid_pidfile=[/var/run/squid3.pid] squid_port=[3366] : pid [3671] timed out
    Mar 22 11:20:52 proxy-2 crmd: [3422]: ERROR: process_lrm_event: LRM operation cluster-squid_start_0 (9) Timed Out (timeout=20000ms)
    Mar 22 11:20:52 proxy-2 crmd: [3422]: WARN: status_from_rc: Action 19 (cluster-squid_start_0) on proxy-2 failed (target: 0 vs. rc: -2): Error
    Mar 22 11:20:53 proxy-2 crmd: [3422]: WARN: update_failcount: Updating failcount for cluster-squid on proxy-2 after failed start: rc=-2 (update=INFINITY, time=1300789253)
    Mar 22 11:20:53 proxy-2 crmd: [3422]: info: abort_transition_graph: match_graph_event:272 - Triggered transition abort (complete=0, tag=lrm_rsc_op, id=cluster-squid_start_0, magic=2:-2;19:5:0:28b5e648-efaf-46e7-897b-ffdb29713675, cib=0.183.26) : Event failed
    Mar 22 11:20:53 proxy-2 attrd: [3421]: info: attrd_trigger_update: Sending flush op to all hosts for: fail-count-cluster-squid (INFINITY)
    Mar 22 11:20:53 proxy-2 crmd: [3422]: info: match_graph_event: Action cluster-squid_start_0 (19) confirmed on proxy-2 (rc=4)
    Mar 22 11:20:53 proxy-2 attrd: [3421]: info: attrd_perform_update: Sent update 24: fail-count-cluster-squid=INFINITY
    Mar 22 11:20:53 proxy-2 attrd: [3421]: info: attrd_trigger_update: Sending flush op to all hosts for: last-failure-cluster-squid (1300789253)
    Mar 22 11:20:53 proxy-2 attrd: [3421]: info: attrd_perform_update: Sent update 27: last-failure-cluster-squid=1300789253
    Mar 22 11:20:53 proxy-2 pengine: [3427]: WARN: unpack_rsc_op: Processing failed op cluster-squid_start_0 on proxy-2: unknown exec error (-2)
    Mar 22 11:20:53 proxy-2 pengine: [3427]: WARN: unpack_rsc_op: Processing failed op cluster-squid_start_0 on proxy-1: unknown exec error (-2)
    Mar 22 11:20:53 proxy-2 pengine: [3427]: notice: native_print:      cluster-squid#011(ocf::heartbeat:Squid):#011Started proxy-2 FAILED
    Mar 22 11:20:53 proxy-2 pengine: [3427]: info: get_failcount: cluster-squid has failed INFINITY times on proxy-1
    Mar 22 11:20:53 proxy-2 pengine: [3427]: WARN: common_apply_stickiness: Forcing cluster-squid away from proxy-1 after 1000000 failures (max=1000000)
    Mar 22 11:20:53 proxy-2 pengine: [3427]: notice: RecurringOp:  Start recurring monitor (10s) for cluster-squid on proxy-2
    Mar 22 11:20:53 proxy-2 pengine: [3427]: notice: LogActions: Recover resource cluster-squid#011(Started proxy-2)
    Mar 22 11:20:53 proxy-2 pengine: [3427]: WARN: unpack_rsc_op: Processing failed op cluster-squid_start_0 on proxy-2: unknown exec error (-2)
    Mar 22 11:20:53 proxy-2 pengine: [3427]: WARN: unpack_rsc_op: Processing failed op cluster-squid_start_0 on proxy-1: unknown exec error (-2)
    Mar 22 11:20:53 proxy-2 pengine: [3427]: notice: native_print:      cluster-squid#011(ocf::heartbeat:Squid):#011Started proxy-2 FAILED
    Mar 22 11:20:53 proxy-2 pengine: [3427]: info: get_failcount: cluster-squid has failed INFINITY times on proxy-1
    Mar 22 11:20:53 proxy-2 pengine: [3427]: WARN: common_apply_stickiness: Forcing cluster-squid away from proxy-1 after 1000000 failures (max=1000000)
    Mar 22 11:20:53 proxy-2 pengine: [3427]: info: get_failcount: cluster-squid has failed INFINITY times on proxy-2
    Mar 22 11:20:53 proxy-2 pengine: [3427]: WARN: common_apply_stickiness: Forcing cluster-squid away from proxy-2 after 1000000 failures (max=1000000)
    Mar 22 11:20:53 proxy-2 pengine: [3427]: info: native_merge_weights: cluster-ip: Rolling back scores from cluster-squid
    Mar 22 11:20:53 proxy-2 pengine: [3427]: info: native_color: Resource cluster-squid cannot run anywhere
    Mar 22 11:20:53 proxy-2 pengine: [3427]: notice: LogActions: Stop resource cluster-squid#011(proxy-2)
    Mar 22 11:20:53 proxy-2 crmd: [3422]: info: te_rsc_command: Initiating action 3: stop cluster-squid_stop_0 on proxy-2 (local)
    Mar 22 11:20:53 proxy-2 crmd: [3422]: info: do_lrm_rsc_op: Performing key=3:7:0:28b5e648-efaf-46e7-897b-ffdb29713675 op=cluster-squid_stop_0 )
    Mar 22 11:20:53 proxy-2 lrmd: [3419]: info: rsc:cluster-squid:10: stop
    Mar 22 11:20:54 proxy-2 Squid[4109]: INFO: squid:stop_squid:311:  stop NORM 1/5
    Mar 22 11:20:55 proxy-2 Squid[4109]: INFO: squid:stop_squid:311:  stop NORM 2/5
    Mar 22 11:20:56 proxy-2 Squid[4109]: INFO: squid:stop_squid:311:  stop NORM 3/5
    Mar 22 11:20:57 proxy-2 Squid[4109]: INFO: squid:stop_squid:311:  stop NORM 4/5
    Mar 22 11:20:58 proxy-2 Squid[4109]: INFO: squid:stop_squid:311:  stop NORM 5/5
    Mar 22 11:20:58 proxy-2 Squid[4109]: INFO: squid:stop_squid:318:  try to stop by SIGKILL:3712
    Mar 22 11:20:59 proxy-2 Squid[4109]: INFO: squid:stop_squid:318:  try to stop by SIGKILL:
    Mar 22 11:20:59 proxy-2 lrmd: [3419]: info: RA output: (cluster-squid:stop:stderr) kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
    Mar 22 11:21:00 proxy-2 crmd: [3422]: info: process_lrm_event: LRM operation cluster-squid_stop_0 (call=10, rc=0, cib-update=43, confirmed=true) ok
    Mar 22 11:21:00 proxy-2 crmd: [3422]: info: match_graph_event: Action cluster-squid_stop_0 (3) confirmed on proxy-2 (rc=0)
    Mar 22 11:36:02 proxy-2 pengine: [3427]: WARN: unpack_rsc_op: Processing failed op cluster-squid_start_0 on proxy-2: unknown exec error (-2)
    Mar 22 11:36:02 proxy-2 pengine: [3427]: WARN: unpack_rsc_op: Processing failed op cluster-squid_start_0 on proxy-1: unknown exec error (-2)
    Mar 22 11:36:02 proxy-2 pengine: [3427]: notice: native_print:      cluster-squid#011(ocf::heartbeat:Squid):#011Stopped
    Mar 22 11:36:02 proxy-2 pengine: [3427]: info: get_failcount: cluster-squid has failed INFINITY times on proxy-1
    Mar 22 11:36:02 proxy-2 pengine: [3427]: WARN: common_apply_stickiness: Forcing cluster-squid away from proxy-1 after 1000000 failures (max=1000000)
    Mar 22 11:36:02 proxy-2 pengine: [3427]: info: get_failcount: cluster-squid has failed INFINITY times on proxy-2
    Mar 22 11:36:02 proxy-2 pengine: [3427]: WARN: common_apply_stickiness: Forcing cluster-squid away from proxy-2 after 1000000 failures (max=1000000)
    Mar 22 11:36:02 proxy-2 pengine: [3427]: info: native_merge_weights: cluster-ip: Rolling back scores from cluster-squid
    Mar 22 11:36:02 proxy-2 pengine: [3427]: info: native_color: Resource cluster-squid cannot run anywhere
    Mar 22 11:36:02 proxy-2 pengine: [3427]: notice: LogActions: Leave resource cluster-squid#011(Stopped)
    -----------------------------------------------

    Grazie per la tua pazienza!

  • 22 marzo 2011 | 12:05
    Raoul Scarazzini

    Sembra che il processo Squid non venga monitorato dal cluster. In poche parole lui lo avvia, ma non riesce a controllarne l’effettiva vitalità.

    Prova a postare anche la tua configurazione e vediamo se ne viene fuori qualcosa.

  • 22 marzo 2011 | 12:40
    Davide

    Allora, di seguito la conf del file ha.cf

    -------------------------------------------
    autojoin none
    keepalive 1
    deadtime 10
    warntime 5
    initdead 20
    mcast eth0 239.0.0.43 694 1 0
    bcast eth1
    node    proxy-1
    node    proxy-2
    crm respawn
    logfacility local0
    -----------------------------------------------

    e invece di seguito lo script Squid utilizzato da heartbeat:

    -----------------------------------------------
    #!/bin/bash
    #
    # Description:  Manages a Squid Server provided by NTT OSSC as an 
    #               OCF High-Availability resource under Heartbeat/LinuxHA control
    #
    # This program is free software; you can redistribute it and/or
    # modify it under the terms of the GNU General Public License
    # as published by the Free Software Foundation; either version 2
    # of the License, or (at your option) any later version.
    #
    # This program is distributed in the hope that it will be useful,
    # but WITHOUT ANY WARRANTY; without even the implied warranty of
    # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    # GNU General Public License for more details.
    #
    # You should have received a copy of the GNU General Public License
    # along with this program; if not, write to the Free Software
    # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
    # 02110-1301, USA.
    #
    # Copyright (c) 2008 NIPPON TELEGRAPH AND TELEPHONE CORPORATION
    #
    #######################################################################
    # OCF parameters:
    #   OCF_RESKEY_squid_exe    : Executable file
    #   OCF_RESKEY_squid_conf   : Configuration file
    #   OCF_RESKEY_squid_pidfile: Process id file
    #   OCF_RESKEY_squid_port   : Port number
    #   OCF_RESKEY_debug_mode   : Debug mode
    #   OCF_RESKEY_debug_log    : Debug log file
    #   OCF_RESKEY_squid_stop_timeout:
    #                             Number of seconds to await to confirm a
    #                             normal stop method
    #
    #   OCF_RESKEY_squid_exe, OCF_RESKEY_squid_conf, OCF_RESKEY_squid_pidfile
    #   and OCF_RESKEY_squid_port must be specified. Each of the rests
    #   has its default value or refers OCF_RESKEY_squid_conf to make
    #   its value when no explicit value is given.
    ###############################################################################
     
    : ${OCF_FUNCTIONS_DIR=${OCF_ROOT}/usr/lib/heartbeat}
    . ${OCF_FUNCTIONS_DIR}/ocf-shellfuncs
     
    usage() 
    {
    	cat &lt;&lt;-!
    usage: $0 action
     
    action:
            start       : start a new squid instance
     
            stop        : stop the running squid instance
     
            status      : return the status of squid, run or down
     
            monitor     : return TRUE if the squid appears to be working.
     
            meta-data   : show meta data message
     
            validate-all: validate the instance parameters
    !
    	return $OCF_ERR_ARGS
    }
     
    metadata_squid()
    {
        cat &lt;&lt;END
     
     
     
    1.0
     
     
    The resource agent of Squid.
    This manages a Squid instance as an HA resource.
     
    Manages a Squid proxy server instance
     
     
     
     
     
    This is a required parameter. This parameter specifies squids
    executable file.
     
    Executable file
     
     
     
     
     
    This is a required parameter. This parameter specifies a configuration file
    for a squid instance managed by this RA.
     
    Configuration file
     
     
     
     
     
    This is a required parameter. This parameter specifies a process id file
    for a squid instance managed by this RA.
     
    Pidfile
     
     
     
     
     
    This is a required parameter. This parameter specifies a port number
    for a squid instance managed by this RA. If plural ports are used,
    you must specifiy the only one of them.
     
    Port number
     
     
     
     
     
    This is an omittable parameter.
    On a stop action, a normal stop method is firstly used.
    and then the confirmation of its completion is awaited for
    the specified seconds by this parameter.
    The default value is 10.
     
    Number of seconds to await to confirm a normal stop method
     
     
     
     
     
    This is an optional parameter.
    This RA runs in debug mode when this parameter includes 'x' or 'v'.
    If 'x' is included, both of STDOUT and STDERR redirect to the logfile
    specified by "debug_log", and then the builtin shell option 'x' is turned on.
    It is similar about 'v'.
     
    Debug mode
     
     
     
     
     
    This is an optional and omittable parameter.
    This parameter specifies a destination file for debug logs
    and works only if this RA run in debug mode.  Refer to "debug_mode"
    about debug mode. If no value is given but it's requied, it's made by the
    following rules: "/var/log/" as a directory part, the basename of
    the configuration file given by "syslog_ng_conf" as a basename part,
    ".log" as a suffix.
     
    A destination of the debug log
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    END
     
    	return $OCF_SUCCESS
    }
     
    get_pids()
    {
    	SQUID_PIDS=( )
     
    	# Seek by pattern
    	SQUID_PIDS[0]=$(pgrep -f "$PROCESS_PATTERN")
     
    	# Seek by pidfile
    	SQUID_PIDS[1]=$(awk '1{print $1}' $SQUID_PIDFILE 2&gt;/dev/null)
     
    	if [[ -n "${SQUID_PIDS[1]}" ]]; then
    		typeset exe
    		exe=$(ls -l "/proc/${SQUID_PIDS[1]}/exe")
    		if [[ $? = 0 ]]; then
    			exe=${exe##*-&gt; }
    			if ! [[ "$exe" = $SQUID_EXE ]]; then
    				SQUID_PIDS[1]=""
    			fi
    		else
    			SQUID_PIDS[1]=""
    		fi
    	fi
     
    	# Seek by port
    	SQUID_PIDS[2]=$(
    		netstat -apn |
    		awk '/tcp.*[0-9]+\.[0-9]+\.+[0-9]+\.[0-9]+:'$SQUID_PORT' /{
    			sub("\\/.*", "", $7); print $7; exit}')
    }
     
    are_all_pids_found()
    {
    	if 
    		[[ -n "${SQUID_PIDS[0]}" ]] &amp;&amp;
    		[[ -n "${SQUID_PIDS[1]}" ]] &amp;&amp;
    		[[ -n "${SQUID_PIDS[2]}" ]]
    	then
    		return 0
    	else
    		return 1
    	fi
    }
     
    are_pids_sane()
    {
    	if [[ "${SQUID_PIDS[1]}" = "${SQUID_PIDS[2]}" ]]; then
    		return $OCF_SUCCESS
    	else
    		ocf_log err "$SQUID_NAME:Pid unmatch"
    		return $OCF_ERR_GENERIC
    	fi
    }
     
    is_squid_dead()
    {
    	if 
    		[[ -z "${SQUID_PIDS[0]}" ]] &amp;&amp;
    		[[ -z "${SQUID_PIDS[2]}" ]]
    	then
    		return 0
    	else
    		return 1
    	fi
    }
     
    monitor_squid()
    {
    	typeset trialcount=0
     
    	while true; do
    		get_pids
     
    		if are_all_pids_found; then
    			are_pids_sane
    			return $OCF_SUCCESS
    		fi
     
    		if is_squid_dead; then
    			return $OCF_NOT_RUNNING
    		fi
     
    		ocf_log info "$SQUID_NAME:Inconsistent processes:" \
    			"${SQUID_PIDS[0]},${SQUID_PIDS[1]},${SQUID_PIDS[2]}"
    		(( trialcount = trialcount + 1 ))
    		if (( trialcount &gt; SQUID_CONFIRM_TRIALCOUNT )); then
    			ocf_log err "$SQUID_NAME:Inconsistency of processes remains unsolved"
    			return $OCF_ERR_GENERIC
    		fi
    		sleep 1
    	done
    }
     
    start_squid()
    {
    	typeset status
     
    	monitor_squid
    	status=$?
     
    	if [[ $status != $OCF_NOT_RUNNING ]]; then
    		return $status
    	fi
     
    	set -- "$SQUID_OPTS"
    	ocf_run $SQUID_EXE -f "$SQUID_CONF" "$@"
    	status=$?
    	if [[ $status != $OCF_SUCCESS ]]; then
    		return $OCF_ERR_GENERIC
    	fi
     
    	while true; do
    		get_pids
    		if are_all_pids_found &amp;&amp; are_pids_sane; then
    			return $OCF_SUCCESS
    		fi
    		ocf_log info "$SQUID_NAME:Waiting for squid to be invoked"
    		sleep 1
    	done
     
    	return $OCF_ERR_GENERIC
    }
     
    stop_squid()
    {
    	typeset lapse_sec
     
    	if ocf_run $SQUID_EXE -f $SQUID_CONF -k shutdown; then
    		lapse_sec=0
    		while true; do
    			get_pids
    			if is_squid_dead; then
    				rm -f $SQUID_PIDFILE
    				return $OCF_SUCCESS
    			fi
    			(( lapse_sec = lapse_sec + 1 ))
    			if (( lapse_sec &gt; SQUID_STOP_TIMEOUT )); then
    				break
    			fi
    			sleep 1
    			ocf_log info "$SQUID_NAME:$FUNCNAME:$LINENO: " \
    				"stop NORM $lapse_sec/$SQUID_STOP_TIMEOUT"
    		done
    	fi
     
    	while true; do
    		get_pids
    		ocf_log info "$SQUID_NAME:$FUNCNAME:$LINENO: " \
    			"try to stop by SIGKILL:${SQUID_PIDS[0]} ${SQUID_PIDS[2]}"
    		kill -KILL ${SQUID_PIDS[0]} ${SQUID_PIDS[2]}
    		sleep 1
    		if is_squid_dead; then
    			rm -f $SQUID_PIDFILE
    			return $OCF_SUCCESS
    		fi
    	done
     
    	return $OCF_ERR_GENERIC
    }
     
    status_squid()
    {
    	return $OCF_SUCCESS
    }
     
     
    validate_all_squid()
    {
    	ocf_log info "validate_all_squid[$SQUID_NAME]"
    	return $OCF_SUCCESS
    }
     
    : === Debug ${0##*/} $1 ===
     
    if [[ "$1" = "meta-data" ]]; then
    	metadata_squid
    	exit $?
    fi
     
    SQUID_CONF="${OCF_RESKEY_squid_conf}"
    if [[ -z "$SQUID_CONF" ]]; then
    	ocf_log err "SQUID_CONF is not defined"
    	exit $OCF_ERR_CONFIGURED
    fi
     
    SQUID_NAME="${SQUID_CONF##*/}"
    SQUID_NAME="${SQUID_NAME%.*}"
     
    DEBUG_LOG="${OCF_RESKEY_debug_log-/var/log/squid_${SQUID_NAME}_debug}.log"
     
    DEBUG_MODE=""
    case $OCF_RESKEY_debug_mode in
    	*x*) DEBUG_MODE="${DEBUG_MODE}x";;
    esac
    case $OCF_RESKEY_debug_mode in
    	*v*) DEBUG_MODE="${DEBUG_MODE}v";;
    esac
     
    if [ -n "$DEBUG_MODE" ]; then
    	PS4='\d \t \h '"${1-unknown} "
    	export PS4
    	exec 1&gt;&gt;$DEBUG_LOG 2&gt;&amp;1
    	set -$DEBUG_MODE
    fi
     
    SQUID_EXE="${OCF_RESKEY_squid_exe}"
    if [[ -z "$SQUID_EXE" ]]; then
    	ocf_log err "SQUID_EXE is not defined"
    	exit $OCF_ERR_CONFIGURED
    fi
    if [[ ! -x "$SQUID_EXE" ]]; then
    	ocf_log err "$SQUID_EXE is not found"
    	exit $OCF_ERR_CONFIGURED
    fi
     
    SQUID_PIDFILE="${OCF_RESKEY_squid_pidfile}"
    if [[ -z "$SQUID_PIDFILE" ]]; then
    	ocf_log err "SQUID_PIDFILE is not defined"
    	exit $OCF_ERR_CONFIGURED
    fi
     
    SQUID_PORT="${OCF_RESKEY_squid_port}"
    if [[ -z "$SQUID_PORT" ]]; then
    	ocf_log err "SQUID_PORT is not defined"
    	exit $OCF_ERR_CONFIGURED
    fi
     
    SQUID_OPTS="${OCF_RESKEY_squid_opts}"
     
    SQUID_PIDS=( )
     
    SQUID_CONFIRM_TRIALCOUNT="${OCF_RESKEY_squid_confirm_trialcount-3}"
     
    SQUID_STOP_TIMEOUT="${OCF_RESKEY_squid_stop_timeout-5}"
    SQUID_SUSPEND_TRIALCOUNT="${OCF_RESKEY_squid_suspend_trialcount-10}"
     
    PROCESS_PATTERN="$SQUID_EXE -f $SQUID_CONF"
     
    COMMAND=$1
     
    case "$COMMAND" in
    	start)
    		ocf_log debug  "[$SQUID_NAME] Enter squid start"
    		start_squid
    		func_status=$?
    		ocf_log debug  "[$SQUID_NAME] Leave squid start $func_status"
    		exit $func_status
    		;;
    	stop)
    		ocf_log debug  "[$SQUID_NAME] Enter squid stop"
    		stop_squid
    		func_status=$?
    		ocf_log debug  "[$SQUID_NAME] Leave squid stop $func_status"
    		exit $func_status
    		;;
    	status)
    		status_squid
    		exit $?
    		;;
    	monitor)
    		#ocf_log debug  "[$SQUID_NAME] Enter squid monitor"
    		monitor_squid
    		func_status=$?
    		#ocf_log debug  "[$SQUID_NAME] Leave squid monitor $func_status"
    		exit $func_status
    		;;
    	validate-all)
    		validate_all_squid
    		exit $?
    		;;
    	*)
    		usage
    		;;
    esac
     
    # vim: set sw=4 ts=4 :
    -----------------------------------------------

    Ciao e grazie ancora!

  • 22 marzo 2011 | 15:15
    Raoul Scarazzini

    Posta anche l’output di crm configure show…

  • 22 marzo 2011 | 15:36
    Davide

    Ok!

    node $id="578d50ed-5ed2-416e-87ff-352d9c30b773" proxy-1
    node $id="6cb310c1-7f2f-43f2-8d91-1cdf2ed936ea" proxy-2
    primitive cluster-ip ocf:heartbeat:IPaddr2 \
            params ip="**********" nic="eth0:0" \
            op monitor interval="10s" timeout="20s" \
            op start interval="0" timeout="20s" broadcast="***********" \
            op stop interval="0" timeout="20s"
    primitive cluster-squid ocf:heartbeat:Squid \
            params squid_exe="/usr/sbin/squid3" squid_conf="/etc/squid3/squid.conf" squid_pidfile="/var/run/squid3.pid" squid_port="*****" \
            op monitor interval="10s" timeout="30s" depth="0"
    primitive ping ocf:pacemaker:ping \
            params host_list="************" name="ping" \
            op monitor interval="10s" timeout="60s" \
            op start interval="0" timeout="60s" \
            op stop interval="0" timeout="60s"
    group cluster-proxy cluster-ip cluster-squid
    clone ping_clone ping \
            meta globally-unique="false"
    location cluster_on_connected_node cluster-proxy \
            rule $id="cluster_on_connected_node-rule" -inf: not_defined ping or ping lte 0
    property $id="cib-bootstrap-options" \
            dc-version="1.0.9-unknown" \
            cluster-infrastructure="Heartbeat" \
            no-quorum-policy="ignore" \
            stonith-enabled="false"
  • 22 marzo 2011 | 16:06
    Raoul Scarazzini

    Domande:

    1) Squid lanciato a mano funziona?
    2) Su quali interfacce è in ascolto di default il proxy in squid.conf?
    3) I log di squid in fase di startup che dicono?

  • 22 marzo 2011 | 16:21
    Davide

    1)
    Lanciando squid attraverso lo script:
    /etc/init.d/squid3 start

    non riscontro problemi, ed il servizio si avvia e funziona correttamente;

    2)
    squid ascolta l’interfaccia eth0 con ip privato configurato;

    3)
    l’unico log inerente al processo squid che parte è:
    squid[25884]: Squid Parent: child process 25886 started

    di fatto lanciando un “ps aux” mi accorgo che il processo è correttamente avviato.

  • 22 marzo 2011 | 16:55
    Raoul Scarazzini

    Sembra decisamente un problema di monitor. Dando un’occhiata veloce alla man page del resource agent sembra che basi tutto sulla porta. Sei certo della corrispondenza? In alternativa ho visto che si può attivare anche il debug mode dei log, in modo da approfondire i perché dei malfunzionamenti.
    Detto questo, se tutto ti sembra corretto, il mio consiglio è quello di aprire un post sulla mailing list di heartbeat (http://lists.linux-ha.org/mailman/listinfo/linux-ha) oppure sul canale IRC (irc://irc.freenode.org#linux-ha) magari è semplicemente un BUG.

  • 23 marzo 2011 | 15:23
    Davide

    Beh, tutto sembra corrispondere lato configurazione, per cui credo proprio che seguirò il tuo consiglio….grazie

  • 23 marzo 2011 | 16:18
    Raoul Scarazzini

    Ciao Davide,
    mi è venuta in mente anche questa cosa che potresti fare:

    # cd /usr/lib/ocf/resource.d/heartbeat
    # export OCF_RESKEY_squid_exe="/usr/sbin/squid3"
    # export OCF_RESKEY_squid_conf="/etc/squid3/squid.conf"
    # export OCF_RESKEY_squid_pidfile="/var/run/squid3.pid"
    # export OCF_RESKEY_squid_port="*****"
    # ./Squid start

    e vedi che succede, in pratica simuli l’impiego del resource agent da parte del cluster mediante una chiamata manuale.

    E’ utile per vedere se ci sono evidenti cose che non funzionano, in alternativa torna valido il suggerimento di prima ;-)

  • 23 marzo 2011 | 16:52
    Davide

    Fatto, ecco il risultato:

    Squid[30536]: WARN: Use of @HA_LIBHBDIR@/ocf-shellfuncs is deprecated.
    Squid[30536]: WARN: Please use /usr/lib/ocf/resource.d//heartbeat/.ocf-shellfuncs instead.
    Squid[30536]: WARN: Note that the $OCF_ROOT environment variable points to /usr/lib/ocf
    Squid[30536]: WARN: We recommend using the $OCF_ROOT environment variable
    Squid[30536]: WARN: Please fix /etc/ha.d/resource.d/Squid at your earliest convenience
    Squid[30536]: DEBUG: [squid] Enter squid start
    Squid[30536]: INFO: squid:Waiting for squid to be invoked
    Squid[30536]: INFO: squid:Waiting for squid to be invoked
    Squid[30536]: INFO: squid:Waiting for squid to be invoked
    Squid[30536]: INFO: squid:Waiting for squid to be invoked
    Squid[30536]: INFO: squid:Waiting for squid to be invoked
    Squid[30536]: INFO: squid:Waiting for squid to be invoked
    Squid[30536]: INFO: squid:Waiting for squid to be invoked
    Squid[30536]: INFO: squid:Waiting for squid to be invoked
    Squid[30536]: INFO: squid:Waiting for squid to be invoked
    Squid[30536]: INFO: squid:Waiting for squid to be invoked
    Squid[30536]: INFO: squid:Waiting for squid to be invoked
    Squid[30536]: INFO: squid:Waiting for squid to be invoked
    Squid[30536]: INFO: squid:Waiting for squid to be invoked

    e continua così….

  • 23 marzo 2011 | 16:55
    Davide

    E ripetendo il comando ottengo:

    Squid[31755]: WARN: Use of @HA_LIBHBDIR@/ocf-shellfuncs is deprecated.
    Squid[31755]: WARN: Please use /usr/lib/ocf/resource.d//heartbeat/.ocf-shellfuncs instead.
    Squid[31755]: WARN: Note that the $OCF_ROOT environment variable points to /usr/lib/ocf
    Squid[31755]: WARN: We recommend using the $OCF_ROOT environment variable
    Squid[31755]: WARN: Please fix /etc/ha.d/resource.d/Squid at your earliest convenience
    Squid[31755]: DEBUG: [squid] Enter squid start
    Squid[31755]: INFO: squid:Inconsistent processes: 30553,30555,
    Squid[31755]: INFO: squid:Inconsistent processes: 30553,30555,
    Squid[31755]: INFO: squid:Inconsistent processes: 30553,30555,
    Squid[31755]: INFO: squid:Inconsistent processes: 30553,30555,
    Squid[31755]: ERROR: squid:Inconsistency of processes remains unsolved
    Squid[31755]: DEBUG: [squid] Leave squid start 1

    Ciao

  • 23 marzo 2011 | 17:20
    Raoul Scarazzini

    Ok, osservando il codice del resource agent, il messaggio “Inconsistency of processes remains unsolved” viene prodotto quando il PID di squid non viene trovato, ma il processo non risulta morto. Pertanto pare decisamente un problema del resource agent (anche se non sono sceso nei dettagli dello script).
    Una volta di più ti consiglio di riferti a IRC o alla mailing list, magari trovi proprio l’autore di quel RA.

  • 24 marzo 2011 | 15:55
    Paolo Mancuso

    Ciao Raoul rieccomi, vole chiederti:
    Se avessi fatto dei casini con heartbeat e i suoi files di configurazione come posso fare per partire da un ambiente pulito senza formattare la macchina? Sono su una macchina centos4.8
    Ed inoltre esiste una versione più avanti della 2.1.3 che non sia la 3 di heartbeat? Grazie sempre per la tua disponibilità…

  • 24 marzo 2011 | 16:11
    Raoul Scarazzini

    Ciao Paolo,
    per ripartire da zero, su entrambi i nodi stoppa il processo heartbeat e rimuovi i file cib:

    # rm -rf /var/lib/heartbeat/crm/*

    In questo modo, all’avvio successivo, tutto verrà creato da zero.

    Per le relase di Heartbeat bisognerebbe verificare sul sito di CentOS, ma dubito che la 4.8 non monti l’ultima 2.x disponibile.

  • 24 marzo 2011 | 16:26
    Paolo Mancuso

    ci provo.grazie

  • 4 ottobre 2011 | 16:49
    Francesco

    mi sorge un dubbio,
    se volessi creare un cluster attivo/passivo
    con Heartbeat e Pacemaker,
    con i dati condivisi su iscsi,
    utilizzando stonith per garantire l’integrita’
    posso fare a meno di DRBD?

  • 4 ottobre 2011 | 16:55
    Raoul Scarazzini

    Ciao Francesco,
    DRBD è un mezzo per avere dati replicati fra le due macchine, se a monte hai device iSCSI (presumibilmente con uno storage) che sono visti da entrambe le macchine hai la stessa condizione, garantita per di più dallo stonith.

    A presto.

  • 23 febbraio 2013 | 02:09
    Massimiliano

    Perdonami, però il clustering degli application server non si fa così.
    Gli application server (weblogic, websphere, jboss, tomcat) dispongono tutti di un clustering applicativo, che offre molte più possibilità rispetto al cluster del sistema operativo.
    1) è un peccato tenere un nodo spento quando puoi usarli entrambi contemporaneamente o uno solo in caso di failure di un nodo.
    2) usando linux-ha o red hat cluster, in caso di switch da un nodo all’altro, perdi tutte le sessioni (perché non riesci a garantire stickiness delle sessioni) e saranno create nuove sessioni. Il cluster applicativo garantisce la continuità della sessione su tutti i nodi del cluster.
    3) Davanti avrai comunque qualcosa… difficilmente punterai direttamente sugli application dall’esterno: Web server, LVS, HA-Proxy, varnish…. quel che ti piace… sarà questo a garantirti l’alta affidabilità.

  • 23 febbraio 2013 | 11:35
    Raoul Scarazzini

    Ciao Massimiliano,
    sono d’accordo al 100% su tutto quello che hai scritto.
    L’esempio trattato nell’articolo era volto essenzialmente a presentare una via per immettere sotto cluster un servizio. E’ chiaro che la via per porre sotto cluster gli application server deve essere nativa (sfruttando le componenti interne dei vari Tomcat o JBoss) e/o scalabile (quindi più application sotto bilanciatore).
    Il progetto relativo a quest’articolo era riferito unicamente alla vitalità del servizio, per il quale non era necessario mantenere le sessioni vive e che per tipologia si prestava allo scopo in quanto i due host risiedevano in due reti geograficamente distanti.
    Ad ogni modo grazie per l’intervento che sono sicuro chiarirà le idee ai lettori.

    A presto!

Commenta






sette + = 8

Seguici:
Archivi