Questo è un mio articolo già pubblicato su Wazi
Il connettore mod_jk funge da collante tra il server HTTP Apache e un Java application server come Tomcat o JBoss. Mentre la maggior parte degli amministratori si concentrano sull’ottimizzazione di Apache o del server Java, una impostazione ottimale di mod_jk può anche migliorare l’esperienza degli utenti.
Per essere precisi, mod_jk connette il server web Apache alla porta AJP di un server Java. Apache Jserv Protocol è una versione binaria del HTTP che è ottimizzata per la comunicazione su TCP tra il server HTTP Apache e l’Apache Tomcat o altri software.
Mod_jk è disponibile per molte distribuzioni di Linux, quindi è possibile installarlo con il vostro gestore di pacchetti, o se si preferisce, è possibile scaricarlo dal sito ufficiale, dove vengono rilasciate nuove versioni come sorgenti e pacchetti binari. Il file mod_jk.so è il modulo di Apache HTTP server che si installa con la versione di Apache che si sta utilizzando. Una volta fatto ciò, è necessario configurare mod_jk nel file httpd. conf in modo che si possa utilizzarlo.
Modificare il file e aggiungere la direttiva per caricare mod_jk:
LoadModule jk_module percorso oer il file /mod_jk.so
quindi, impostare il percorso al file di configurazione Workers, dove è possibile definire molte più opzioni per mod_jk. Dovrebbe essere nella stessa directory del file httpd. conf:
JkWorkersFile percorso /httpd/conf/workers.properties
Mod_jk utilizza la memoria condivisa per memorizzare le informazioni di configurazione e le informazioni di runtime dei workers per il bilanciamento del carico. Grazie ad esso tutti i child Apache
- condividono le stesse informazioni di stato per i membri del bilanciamento del carico(OK, ERROR, etc.)
- condividono le informazioni sul carico dei singoli workers
- condividono le informazioni sulle parti di configurazioni modificabili a runtime.
JkShmFile /path/to/log/httpd/mod_jk.shm
La prossima direttiva dice ad Apache dove mettere i log di mod_jk. Questo percorso dovrebbe essere nella stessa directory dei log access_log del demone HTTPD:
JkLogFile /path/to/log/httpd/mod_jk.log
Questa configura il livello dei log a debug, error, or info:
JkLogLevel level
Configura il formato timestamp all’interno del file:
JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"
La prossima direttiva mappa un worker in una URL. I worker rappresentano istanze di Tomcat che sono in ascolto per richieste. Con la direttiva, diciamo che ogni richiesta che viene mandata alla URL http://mysite.com/tomcat/ deve essere reindirizzata tramite mod_jk a worker1, che configureremo fra un attimo. Più attributi JkMount possono essere utilizzati contemporaneamente per il Worker stesso o più Worker:
JkMount /tomcat/* worker1
Configurazione del Worker
Per definire i Tomcat worker specificati nel file httpd.conf, creare il file /percorso/al/httpd/conf/workers.properties. Come semplice esempio di configurazione, possiamo configurare l’ambiente del mod_jk e definire la lista dei worker; in questa lista abbiamo solo un worker con nome “worker1”:
workers.tomcat_home=/tomcat workers.java_home=$JAVA_HOME ps=/ worker.list=worker1
Adesso definiamo i parametri che il tomcat utilizzerà il protocollo AJP13 e diamo il suo indirizzo e porta:
worker.worker1.port=8009 worker.worker1.host=192.168.1.1 worker.worker1.type=ajp13
Possiamo anche usare un esempio un po’ più complesso che utilizza un server Apache HTTP per bilanciare il carico delle richieste per tre istanze di Tomcat. Dobbiamo modificare il file httpd.conf per dire con la direttiva JkMount di usare un worker particolare, che chiameremo “ldbalance”:
JkMount /tomcat/* ldbalance
Il file /percorso/a/httpd/conf/workers.properties deve ora contenere queste 3 direttive
workers.tomcat_home=/tomcat workers.java_home=$JAVA_HOME ps=/ worker.list=worker1,worker2,worker3
Quando definiamo ogni worker, aggiungiamo la direttiva lbfactor, che specifica il “peso” di questo worker quando si bilancia – che è il lavoro che ci aspettiamo possa svolgere questo worker, o quota di lavoro del worker rispetto agli altri bilanciati assieme ad esso. Se un lavoratore ha ad esempio un lbfactor cinque volte superiore rispetto a un altro, riceverà cinque volte più richieste.
worker.worker1.port=8009 worker.worker1.host=192.168.1.1 worker.worker1.type=ajp13 worker.worker1.lbfactor=1 worker.worker2.port=8009 worker.worker2.host=192.168.1.2 worker.worker2.type=ajp13 worker.worker2.lbfactor=1 worker.worker3.port=8009 worker.worker3.host=192.168.1.3 worker.worker3.type=ajp13 worker.worker3.lbfactor=1
Dobbiamo anche definire un worker speciale per il bilanciamento del carico con tipo “lb” e specificare i nostri tre worker in bilanciamento. L’impostazione sticky (appiccicoso) specifica che le richieste con gli ID di sessione devono essere indirizzate sempre allo stesso Tomcat Worker; Se sticky_session è impostato su True o 1, le sessioni sono “appiccicose”. Quando Tomcat utilizza un gestore di sessione che può rendere persistenti i dati di sessione tra più istanze di Tomcat, come Memcached, Terracotta o quello incorporato, è necessario impostare sticky_session su False.
worker.ldbalance.type=lb worker.ldbalance.balanced_workers=worker1,worker2,worker3 worker.ldbalance.sticky_session=1
Direttive Particolari
Finora tutto quello che abbiamo visto è abbastanza standard. Ora diamo un’occhiata ad alcuni dei parametri di configurazione meno utilizzati di mod_jk . È possibile utilizzare direttive di connessione (connect) con qualsiasi worker per garantire che la comunicazione tra mod_jk e un’istanza remota di Tomcat stia funzionando. Iniziamo con il tempo in secondi che mod_jk attende per una risposta dal Tomcat:s
socket_timeout value
Se impostato a zero, che è l’impostazione predefinita, il mod_jk attenderà una quantità infinita di tempo su tutte le operazioni sui socket. Non è una buona idea, perché quando si ha un problema su uno dei worker di back-end, si avranno un sacco di connessioni che partono da Apache appese in attesa di una risposta, cosa che potrebbe mangiare tutte le connessioni disponibili. Impostare questo valore a 30 secondi o meno se sapete che il vostro Tomcat risponde rapidamente.
socket_connect_timeout value
Questo è un timeout in millisecondi, per stabilire una connessione. Il valore predefinito è il valore di socket_timeout moltiplicato per 1.000. Se l’host remoto non risponde alla prima connessione all’interno del timeout specificato, mod_jk genererà un errore e riproverà. Socket_connect_timeout funziona su più piattaforme, anche se socket_timeout non è supportato dal sistema operativo. Utilizzare socket_connect_timeout, perché in qualche situazione di errore della rete il rilevamento di un guasto durante la definizione della connessione può richiedere diversi minuti a causa della ritrasmissione del TCP. A seconda della qualità della rete, un timeout tra 1000 e 5000 millisecondi dovrebbe andare bene.
ping_mode value
Questa proprietà del worker determina in che condizioni le connessioni stabilite devono essere esaminate per assicurarsi che stiano ancora funzionando. Mod_jk sonda con un pacchetto vuoto di AJP13 (chiamato CPing) e si aspetta di ricevere una risposta appropriata (CPong) all’interno di un timeout. Il ping_mode può essere impostato in una combinazione di caratteri per decidere in quali situazioni sono utilizzati questi pacchetti di prova:
- C: connect mode, timeout configurato a ping_timeout (vedi sotto) sovrascritto da connect_timeout
- P: prepost mode, timeout configurato a ping_timeout sovrascritto da prepost_timeout
- I: interval mode, timeout configurato a ping_timeout, intervallo configurato con connection_ping_interval
- A: all, tutti i modi
Il setup suggerito è quello con A (tutti i modi) e configurare un ping_timeout:
ping_timeout value
Questa proprietà imposta il timeout in millisecondi utilizzato quando si aspetta la risposta CPong di una sonda di connessione CPing. Il valore predefinito è 10000 o 10 secondi. In generale è abbastanza buono, ma si può abbassare il valore se sapete che il vostro back-end dovrebbe rispondere in un tempo più veloce di 10 secondi. Si prega di notare che se si abilita il ping_mode bisogna porre attenzione anche per il timeout di altri parametri nell’elenco di cui sopra che potrebbero influenzare la presente direttiva. Il mio suggerimento è di utilizzare solo ping_timeout se possibile.
Questi parametri di configurazione impostano limiti ragionevoli per le connessioni che fà mod_jk. È necessario anche impostare ping_mode su un valore uguale a quello che si imposta nella direttiva di timeout di connessione nel file server. xml per il Tomcat (o direttiva equivalente per altri server) in modo da non avere una “mezza connessione” appesa in una delel due estremità. Anche se si verifica un problema di connessione, se avete impostato la proprietà con ping_mode = A, la cattiva connessione verrà rilevata e chiusa.
Direttive sulla salute del Back-End
Queste direttive definiscono come mod_jk viene a sapere se il server di back-end è vivo o morto e come gestire questo evento.
fail_on_status valore
Impostare questa proprietà con il valore di un codice di stato HTTP che causerà ad un worker di essere messo in stato offline se restituitao da un Servlet Container. Questo dice a mod_jk di dichiarare un back-end morto fine a quando non viene restituito un codice di stato HTTP specifico. A partire da mod_jk 1.2.25 si può anche dire al bilanciatore di carico di non mettere un worker in stato di errore anche se una risposta restituita da uno dei codici di stato di solito avrebbe messo il worker in questo stato. Per farlo inserire un segno meno davanti a questi codici di stato:ad esempio worker.xxx.fail_on_status=-404,-500,503 con questa direttiva ho rimosso come codici di stato di errore 404 e 500, mentre 503 mette ancora il back-end in stato di errore.
Come ulteriore esempio, io uso
worker.xxx.fail_on_status=302,404,500,503,
perché nel mio ambiente quei codici significano che un deploy/undeploy di unna applicazione non ha funzionato e quindi non è trovata nessuna pagina (codice 404), e voglio mettere il back-end in stato di errore, quando questo accade.
recover_time valore
Il tempo di recupero è il tempo in secondi che il bilanciatore del carico non tentare di utilizzare un worker dopo che è andato in stato di errore. Trascorso questo tempo un worker in stato di errore viene contrassegnato come recovering e sarà tentata una nuova richiesta. Il valore predefinito è 60, quindi se il vostro worker di back-end è in errore, ci vorranno 60 secondi prima che il worker ricevi una nuova richiesta. Di solito è consigliato impostare questa soglia ad un valore inferiore ai 30 secondi, in modo che un recovering back-end possa essere rimesso in linea abbastanza velocemente. Questo può essere importante per i grandi siti web dove è normale avere alcune pagine di errore e non si vuole mettere il back-end fuori linea per troppo tempo.
Questa è una panoramica ad alcune delle proprietà meno comuni che è possibile utilizzare per ottimizzare mod_jk. Ho dato alcuni suggerimenti per valori appropriati, ma i limiti tra il bene e il male dipendono sopratutto dalle vostre applicazioni. Ad esempio, per il vostro sito potrebbe essere normale vedere un errore 404, e non si desidera impostare come “rotto” un back-end che dà questa risposta. Ma ora sapete queste proprietà esiste, ed è possibile utilizzarla per ottimizzare la comunicazione tra server web e il server Java.
Popular Posts:
- None Found
