Load balancing and HA for multiple applications with Apache, HAProxy and keepalived
sembra un articolo interessante leggerlo
http://backreference.org/2012/04/25/load-balancing-and-ha-for-multiple-applications-with-apache-haproxy-and-keepalived/
Multi apache sulla stessa macchina
Centos
In questa pagina di novell.com eseguono apache sulla stessa macchina che ascolta sempre sulla porta 80 ma da due ip differenti.
Io in una centos ho configurato in modo che ci siano più istanze su porte differenti.
Ecco i comandi che ho eseguito in una centos 6
cd /etc
cp -pr httpd/ httpd-a
cp -p /etc/sysconfig/httpd /etc/sysconfig/httpd-a
rm logs
ln -s /var/log/httpd-a/ logs
cp -r /usr/lib64/httpd/ /usr/lib64/httpd-a
rm modules
ln -s /usr/lib64/httpd-a/modules/ modules
mkdir /var/run/httpd-a
rm run
ln -s /var/run/httpd-a/ run
dentro http.conf ho cambiato
la server root /etc/httpd-a e la listen port
Non ho modificato /var/www perchè in quel momento non mi serviva farlo
Eseguendo il comando apache con il file di configurazioni modificato si può fare una prova per vedere se tutto funziona correttamente.
apachectl -f /etc/httpd-a/conf/httpd.conf
Conviene però avviarlo come script.
Per lo script ho copiato e modificato /etc/init.d/httpd-a cambiando le directory dove deve lavorare
Inoltre va modificato pure /etc/sysconfig/httpd-a , perchè ha una variabile OPTIONS commentata che quindi si riferisce al file di default httpd.conf . Questo ovviamente impediva l'avvio corretto per il semplice problema della porta già impegnata. Cambiando la variabile il problema è risolto
OPTIONS="-f /etc/httpd-a/conf/httpd.conf"
Ubuntu 10.04
Ho copiato tutta la directory di /etc/apache in /etc/apache-koha modificato tutto a partire dal file apache2.conf mettendo i riferimenti giusti e poi creando in /etc/init.d/apache-koha questo file di conf.
#!/bin/sh
start() {
echo "Starting apache-koha services: "
export APACHE_ENVVARS=/etc/apache-koha/envvars
apache2ctl -f /etc/apache-koha/apache2.conf
RETVAL=$?
echo
}
stop() {
echo "Shutting down apache koha services: "
kill `cat /var/run/apache-koha.pid`
RETVAL=$?
echo
}
viewlog(){
echo -n "View access log of apache-koha services: "
echo -n "press CTRL+C to exit "
tail -f /var/log/apache-koha/access.log
}
status(){
echo "Stato di apache-koha tramite comando top"
ps aux | grep apache-koha | grep root
}
case "$1" in
start)
start
;;
stop)
stop
;;
viewlog)
viewlog
;;
restart|reload)
stop
start
;;
status)
status
RETVAL=$?
;;
*)
echo $"Usage: $0 {start|stop|restart|status|viewlog}"
exit 1
esac
exit $RETVAL
È fondamentale la riga export APACHE_ENVVARS=/etc/apache-koha/envvars perchè del comando apachectl è l'unico parametro che non viene impostato dentro apache2.conf. Da li legge le var d'ambiente come quella del pid in modo da non confondere le cose.
Ubuntu 12.04
C'è qualche differenza con la versione 10.04
Ho copiato tutta la directory come sopra, ho modificato dentro apache.conf questo parametro
ServerRoot "/etc/apache2-omega"
Nel file envars ho modificato così le variabili
# envvars - default environment variables for apache2ctl
# this won't be correct after changing uid
unset HOME
APACHE_DIR_NAME="apache2-omega"
# Since there is no sane way to get the parsed apache2 config in scripts, some
# settings are defined via environment variables and then used in apache2ctl,
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
export APACHE_PID_FILE=/var/run/$APACHE_DIR_NAME.pid
export APACHE_RUN_DIR=/var/run/$APACHE_DIR_NAME
export APACHE_LOCK_DIR=/var/lock/$APACHE_DIR_NAME
# Only /var/log/apache2 is handled by /etc/logrotate.d/apache2.
export APACHE_LOG_DIR=/var/log/$APACHE_DIR_NAME
Bisogna creare la directory per i file di log altrimenti schianta all'avvio
cd /var/log/
mkdir apache2-omega
chown root:adm apache2-omega/
chmod o-rx apache2-omega/
Conviene copiare anche i parametri di configurazione dei moduli per avere diversi profili
Apache Module mod_proxy_balancer
http://httpd.apache.org/docs/current/misc/rewriteguide.html
http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html
Load balancer scheduler algorithm
Ci sono al momento 3 algoritimi di load balancing.
- Request Counting
- Weighted Traffic Counting
- Pending Request Counting
Sono controllati attraverso il lbmethon value del Balancer definition (vedere ProxyPass per approfondimenti)
Load balancer stickyness (vischiosità)
Il balancer supporta stickyness. Quando una richiesta è proxied verso diversi backend la richiesta di uno stesso utente deve essere servita sempre dallo stesso backend. Alcuni load balancer implementano questa funzionalità mappando indirizzi ip con backend. Questo approccio soffre del problema di distribuzione di carico se i client stanno tutti dietro lo stesso proxy. Inoltre c'è un errore se il client usa un ip dinamico che cambia durante la sessione, mancanza di stickyness.
Il modulo mod_proxy_balancer implementa stickyness tramite due alternative coockies e url encoding. I cokie possono essere forniti dal backend o dal server apache steso. L'url encoding viene solitamente fatto dal backend.
Examples of a balancer configuration
Vediamo un esempio tra due backend
<Proxy balancer://mycluster>
BalancerMember http://192.168.1.50:80
BalancerMember http://192.168.1.51:80
</Proxy>
ProxyPass /test balancer://mycluster
Un altro esempio di come fornire load balancig with stickyness usando il mod_headers perfino sei il backend serv non setta un cookie di sessione adatto.
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
<Proxy balancer://mycluster>
BalancerMember http://192.168.1.50:80 route=1
BalancerMember http://192.168.1.51:80 route=2
ProxySet stickysession=ROUTEID
</Proxy>
ProxyPass /test balancer://mycluster
Request Counting Algorithm
Vediamo il primo algoritmo di bilanciamento.
Abilitato tramite il lbmethod=byrequests , distribuisce le richieste tra i workers per assicurare che ognuno condivide un numero di richieste. Il funzionamento è il seguente
lbfactor è un parametro che indica quanto il workers deve lavorare, in pratica una specie di quota di lavoro.
Ibstatus è quanto è urgente che questo worker raggiunga la sua quota di lavoro.
Il worker è un membro del load balancer, solitamente un host remoto che serve uno dei protocolli supportati.
Distribuiamo a ogni workers la sua quota di lavoro. Così la sommo di tutti i Ibstatus non cambia (*) e distribuiamo le richieste come desideriamo.
Se alcuni workers sono disabilitati gli altri continuano ad essere schedulati correttamente. Qui vi è l'algoritmo di scheduling
Sotto nella pagina originale c'è un esempio di come i worker vengono schedulati in caso di guasto.
for each worker in workers
worker lbstatus += worker lbfactor
total factor += worker lbfactor
if worker lbstatus > candidate lbstatus
candidate = worker
candidate lbstatus -= total factor
Weighted Traffic Counting Algorithm
Abilitato tramite il parametro lbmethod=bytraffic lo scheduler è molto simile al Request Counting con i seguenti cambi:
lbfactor è quanto traffico in byte vogliamo sia manipolato, quindi invece di contare il numero di richieste si conta il corrispettivo in traffico.
Un load balancer configurato in questa maniera vuol dire
worker a b c
lbfactor 1 2 1
che b processa il doppio del traffico in input e output di a e c
Pending Request Counting Algorithm
Abilitato tramite lbmethod=bybusyness tiene conto di quante richieste ogni worker ha assegnato al momento presente. Una nuova richiesta viene assegnata al worker con il numero di richieste attive più basso.
In caso di apache poco utilizzati per distribuire si usa il primo algoritmo.
Questo algoritmo è disponibile da apache 2.2.10 e successivi