La ridondanza in ambito sistemistico è sinonimo di affidabilità. In questo post spiegherò come creare un Web cluster (Apache) Active/Standby su CentOS 6 utilizzando keepalived. Schema di rete

Entrambi i nodi sono connessi in LAN, utilizzando un IP della classe 192.168.1.0/24 (eth0),  rispettivamente 192.168.1.3 per il nodo master e 192.168.1.4 per il nodo slave, mentre keepalived sta in ascolto su un due interfacce di rete configurate in bonding (bond0, formata da eth1 ed eth2).  L’IP virtuale del cluster è 192.168.1.2.

Installazione e configurazione di keepalived

Per prima cosa installiamo il suddetto demone su entrambi i server mediante yum:

[root@node1 ~]# yum install keepalived

[root@node2 ~]# yum install keepalived

Ad installazione completata possiamo procedere con la sua configurazione, editando il file /etc/keepalived/keepalived.conf, il cui contenuto, per il nodo 1, dovrà essere il seguente:

global_defs {
  notification_email {
    vostro.indirizzo@email.it
  }
  notification_email_from node1@localhost.localdomain
  smtp_server localhost
  smtp_connect_timeout 30
}

vrrp_script chk_httpd {
   script "killall -0 httpd"      # verify the pid existance
   interval 2                     # check every 2 seconds
   weight 2                       # add 2 points of prio if OK
}

vrrp_instance VI_1 {
   interface bond0               # interface to monitor
   state MASTER
   virtual_router_id 54          # Assign one ID for this route
   priority 101                  # 101 on master, 100 on backup
   advert_int 1
   smtp_alert
   virtual_ipaddress {
       192.168.1.2               # the virtual IP
   }
   track_script {
       chk_httpd
   }
}

mentre per il nodo 2 la configurazione è questa:

global_defs {
  notification_email {
    vostro.indirizzo@email.it
  }
  notification_email_from node2@localhost.localdomain
  smtp_server localhost
  smtp_connect_timeout 30
}

vrrp_scrip chk_httpd {
   scrip "killall -0 httpd"               # verify the pid existance
   interval 2                             # check every 2 seconds
   weight 2                               # add 2 points of prio if OK
}

vrrp_instance VI_1 {
   interface bond0               # interface to monitor
   state MASTER
   virtual_router_id 54          # Assign one ID for this route
   priority 100                  # 101 on master, 100 on backup
   advert_int 1
   smtp_alert
   virtual_ipaddress {
       192.168.1.2                # the virtual IP
   }
   track_scrip {
       chk_httpd
   }
}

Si può facilmente notare come la priorità del nodo master (nodo 1) sia superiore a quella del nodo slave (priorità assegnata mediante la direttiva priority).

Affinchè il servizio Apache rimanga in ascolto su entrambi i nodi anche quando l’IP virtuale del cluster (192.168.1.2) non è fisicamente allocato sulla macchina, è necessario fare un po’ di kernel tuning, lanciando il seguente comando:

[root@node1 ~]# echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind

[root@node2 ~]# echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind

e successivamente editando il file /etc/sysctl.conf per rendere la suddetta direttiva permanente, ovvero anche dopo eventuali riavvii delle macchine, inserendo quanto segue:

net.ipv4.ip_nonlocal_bind = 1

Prove di funzionamento

Basta stoppare il servizio httpd sul nodo master:

[root@node1 ~]# service httpd stop

e successivamente verificare che l’IP virtuale del cluster sia “migrato” sul nodo slave, lanciando su quest’ultimo il comando:

[root@node2 ~]# ip addr | grep 192.168.1.2

A questo punto ritiriamo su httpd sul nodo master:

[root@node1 ~]# service httpd start

e lanciamo

[root@node1 ~]# ip addr | grep 192.168.1.2

per verificare che l’IP virtuale sia “ritornato” sulla macchina principale.

Alla prossima.