Apache Cluster

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.

  1. Request Counting
  2. Weighted Traffic Counting
  3. 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

Exported Environment Variables



Salvo diversa indicazione, il contenuto di questa pagina è sotto licenza Creative Commons Attribution-ShareAlike 3.0 License