Asterisk – FailOver

Afin de garantir un niveau de service maximum, il est important de redonder notre serveur de VoIP.

Avec un Asterisk tournant sous Linux, nous pouvons faire appel à Corosync et Pacemaker.

Ces derniers prendront en charge la redondance, sans qu’il soit nécessaire de modifier la configuration d’Asterisk.

 

1) Présentation

 

Tout d’abord, il est important de préciser qu’il nous faudra au minimum 2 serveurs.

L’un sera en mode Master, et l’autre en mode Standby.

C’est-à-dire que le second serveur sera là simplement pour prendre le relais en cas de panne du premier.

 

Afin d’assurer la redondance, nous utiliseront Corosync et Pacemaker.

Corosync permet de gérer le cluster (état des nœuds, groupe de nœuds, etc…).

 

Pacemaker quant à lui permet de gérer les ressources du cluster.

La ressource qui nous intéresse ici est l’IP partagée.

 

En effet, nos deux serveurs vont partager une IP virtuelle.

C’est grâce à cette IP virtuelle que les clients vont se loguer sur le serveur.

 

En cas de panne du serveur 1, c’est le serveur 2 qui prendra le relais, et répondra aux requêtes sur l’IP virtuelle.

 

Nous aurons alors une infrastructure de ce type :

Les clients accèdent au serveur par l’IP 10.0.0.3.

Le serveur 1 étant Master, c’est lui qui reçoit les paquets pour cette IP.

Dans le cas où le serveur 1 tombe en panne, le serveur 2 devient alors Master, et c’est lui qui répond sur l’IP 10.0.0.3.

 

Pour prendre le relais, le serveur en Standby envoie une requête Gratuitous ARP.

Cela lui permet d’annoncer que dorénavant, c’est lui (son adresse MAC) qui possède l’IP en question (ici 10.0.0.3).

Ainsi il recevra les paquets pour 10.0.0.3.

 

Du point de vu d’Asterisk, il n’y a rien à configurer.

La seule contrainte est que la configuration soit la même sur les deux serveurs.

 

2) Installation

 

Commençons par installer les prérequis, c’est-à-dire Corosync et Pacemaker.

 

L’installation est bien évidement à faire sur les deux serveurs.

apt-get install corosync
apt-get install pacemaker

 

Attention, il est important que vos deux serveurs aient chacun un nom d’hôte différent.

Pour changer le Hostname sous Debian, éditer le fichier /etc/hostname.

Redémarrer pour appliquer le changement.

 

Il est important de bien respecter les étapes, et de s’assurer que la configuration est valide.

En effet, la configuration de Corosync et Pacemaker est relativement sensible.

Une simple erreur peut causer un dysfonctionnement.

Prenez donc un maximum de précaution durant la mise en place.

 

Pour cet exemple, mes deux nœuds se nommeront ipbx1 et ipbx2.

 

Ensuite, il faut renseigner les deux hôtes dans le DNS.

A défaut, vous pouvez éditer les fichiers suivants comme suit (à faire sur les deux hôtes) :

• /etc/host.conf
• /etc/hosts

 

host.conf :

multi on
order hosts, bind

 

hosts :

192.168.1.215   ipbx1
192.168.1.213   ipbx2

 

Adapter les IP et les noms d’hôtes à votre configuration.

 

Valider la configuration en lançant un Ping à destination des noms d’hôte.

 

3) Configuration de Corosync

 

Corosync est le composant qui va gérer le cluster.

 

La première étape consiste à créer une clé d’authentification.

Cette dernière va permettre aux nœuds du cluster de s’authentifier entre eux, de manière à garantir la sécurité du service.

Un noud ne possédant pas la clé ne pourra pas s’authentifier.

 

Sur le nœud 1, utiliser la commande suivante pour générer la clé :

corosync-keygen

 

La clé est alors créée dans le dossier /etc/corosync/

 

Il convient maintenant d’exporter la clé sur le nœud numéro 2.

Vous pouvez faire la copie en SCP :

scp /etc/corosync/authkey ipbx2:/etc/corosync/

 

Sur le nœud numéro 2, configurer l’appartenance et les droits sur la clé :

chown root:root /etc/corosync/authkey
chmod 400 /etc/corosync/authkey

 

 

Poursuivons la configuration en éditant la configuration de Corosync.

Le fichier à éditer est /etc/corosync/corosync.conf

Ce fichier possède déjà une configuration d’exemple.

Il suffit d’éditer deux paramètres :

nodeid et bindnetaddr.

 

Reproduisez donc la configuration suivante sur le nœud 1 (adapter l’IP selon votre configuration) :

totem {
        version: 2
        token: 3000
        token_retransmits_before_loss_const: 10
        join: 60
        consensus: 3600
        vsftype: none
        max_messages: 20
        clear_node_high_bit: yes
        secauth: off
        threads: 0
        nodeid: 1
        rrp_mode: none

        interface {
                ringnumber: 0
                bindnetaddr: 192.168.1.0
                mcastaddr: 226.94.1.1
                mcastport: 5405
       }
}

 

Sur le nœud numéro 2, utiliser la même configuration, mais modifier le paramètre nodeid pour le mettre à 2.

Libre à vous de personnaliser cette configuration.

 

Pour terminer, il faut démarrer Corosync.

Pour cela, éditer le fichier /etc/default/corosync comme ceci (sur les deux nœuds) :

START=yes

 

Enfin, lancer Corosync avec le script de démarrage (sur les deux nœuds) :

/etc/init.d/corosync start

 

4) Configuration de Pacemaker

 

L’exécution de la commande crm configure show devrai vous indiquer la présence des 2 nœuds :

A présent il convient d’ajouter la ressource qui nous intéresse : l’IP partagée (adapter l’IP à votre configuration).

crm
configure
primitive failover-ip ocf:heartbeat:IPaddr params ip=192.168.1.217 op monitor interval=2s

 

Quitter l’interface de configuration avec la commande end, et valider les changements avec y.

 

A présent, vous pouvez valider la configuration avec la commande crm_mon —one–shot.

Pour tester le bon fonctionnement, lancer un ping sur l’IP virtuelle, et couper l’interface réseau du serveur Master.

 

Pour connaitre l’identité du serveur qui assure le rôle de Master, vous pouvez initier uen connexion SSH sur l’IP virtuelle.

 

5) Synchroniser les configurations

 

Afin d’avoir un service fonctionnel quel que soit le serveur qui assure le rôle de Master, il faut synchroniser les configurations Asterisk.

 

Pour cela, copier les fichiers du serveur A vers le serveur B.

scp /etc/asterisk/users.conf ipbx2:/etc/asterisk/users.conf
scp /etc/asterisk/voicemail.conf ipbx2:/etc/asterisk/voicemail.conf
scp /etc/asterisk/sip.conf ipbx2:/etc/asterisk/sip.conf
scp /etc/asterisk/extensions.conf ipbx2:/etc/asterisk/extensions.conf

 

Faites de même pour tous les fichiers que vous avez édités.

Attentions aux ressources annexes telles que les MOH, etc…

 

A présent, vous pouvez connecter les clients aux serveurs à l’aide de l’IP virtuelle.

 

6) Redondance de la connexion à l’ITSP

 

A présent, nous avons une configuration redondante, et la bascule s’effectue correctement.

Il n’y a donc aucun problème pour les appels en interne.

Mais qu’en est-il du lien vers l’opérateur ?

 

Il y a plusieurs possibilités.

 

Si vous avez dupliqué la configuration SIP, vos deux Asterisk sont alors connectés à l’ITSP.

Ce qui veut dire qu’en cas d’appel (si les deux serveurs sont UP, c’est l’Asterisk le plus rapide qui prendra l’appel.

Ce ne sera donc pas nécessairement le Master.

 

Cette configuration peut se révéler fonctionnelle, mais elle n’est pas forcement idéale.

 

Autre possibilité, utiliser un Trunk de « secours » sur l’Asterisk de Standby.

 

Ou encore, configurer le Trunk du serveur Standby seulement en cas de panne.

Cela implique une intervention manuelle, mais permet de se relier proprement à l’ITSP.