Cet article est les prémisses d’une série d’articles à venir sur Asterisk et sur sa mise en place via des solutions haute disponibilité (HA). Asterisk est un PABX open source pour systèmes GNU/Linux, publié sous licence GPL. Il permet, entre autres, la messagerie vocale, les conférences, les files d’attente, les agents d’appels, les musiques d’attente et bon nombre de fonctionnalités qui le placent au niveau des PBX les plus complexes.
Au sein des très grandes installations, il est courant de répartir les fonctionnalités sur plusieurs serveurs. L’un sera dédié au traitement des appels et celui-ci sera épaulé par des serveurs secondaires traitant d’autres tâches comme la base de données, les boîtes vocales ou les conférences. Pour des installations plus petites, un serveur suffisamment costaud est capable de gérer l’ensemble assez facilement et sera épauler par un serveur de backup.
Asterisk implémente les protocoles H.320, H.323 et SIP, ainsi que IAX (Inter-Asterisk eXchange). Ce protocole rend possible la communication entre un serveur est un client mais aussi la communication entre deux serveurs Asterisk en utilisant le port 4569 (en UDP) permettant de renvoyer les appels à partir d’un serveur Asterisk au travers d’IAX.
Il comprend de base un nombre très élevé de fonctions pour répondre à la majorité des besoins en téléphonie permettant ainsi de remplacer totalement, par le biais de cartes FXO/FXS, un PABX propriétaire, et d’y adjoindre des fonctionnalités de ToIP pour le transformer en IPPBX. Certains modules tiers permettent de visualiser ou paramétrer le PBX via une interface web ou via un client léger. Asterisk est extensible par des scripts ou des modules écrit en Perl, en Python, en C, voir en PHP permettant aux développeurs de l’adapter au maximum à ses besoins.
Les serveurs Asterisk en entreprise joue un rôle indispensable puisque l’ensemble de la téléphonie repose dessus. Il est donc vital d’avoir une solution haute disponibilité. Pour ce faire, certaines règles doivent être respectées, je vous en livre quelques une, mais elles sont loin d’être exhaustives.
- Ne JAMAIS monter un serveur Asterisk en production hors d’un cluster. Si votre serveur venait à flancher, ce serait la catastrophe. Un minimum de deux serveurs est nécessaire en fonction de la charge qui sera demandé. Cela permet de pouvoir mettre un serveur à jour pendant que l’autre/les autres continuent à fonctionner et d’assurer la continuité de service en cas de panne importante.
- Il est nécessaire d’effectuer des backups réguliers de vos serveurs. Il existe aujourd’hui bon nombres de solutions de clichés instantanés (même gratuites). Prévoyez aussi un plan de reprise après incident ! On ne sait jamaisÂ
- Monitorer vos serveurs en utilisant des outils adéquats par exemple Cacti, Nagios/Centreon, Zabbix, HP OpenView…Certains sont gratuits et permettent de monitorer et/ou gérer les pannes de façon efficace avec les remontées d’alarmes, voir même de les anticiper.
- Utiliser des outils de réplication/hronisation pour garder vos différents serveurs à jour.
- Heartbeat : Afin de pouvoir tester les nodes du cluster, chacune des machines va vérifier si les autres répondent toujours en prenant le pouls des autres. Si une machine cesse de fonctionner, les autres assurent le service.
- DRBD : C’est un module pour le kernel implémentant un périphérique en mode bloc qui en plus d’écrire l’information sur le disque physique de la machine, la transmet à son homologue miroir qui se trouve sur l’autre (ou les autres serveurs). Cette solution permet la mise en miroir d’un disque complet.
- RSYNC/CSYNC2 : Cette solution permet d’effectuer une hronisation dans un intervalle de temps relativement court. Ce type de solution convient car les données ne changeant pas trop fréquemment. Attention cependant si elle est utilisée dans une très grosse installation la limitation de R devient évidente. Même en hronisant les serveurs toutes les 2 minutes, nous risquons de perdre des données modifiées durant cet intervalle. Attention dans certains cas, R peut mettre vos serveurs à genoux. Cette solution est beaucoup plus facile à gérer et plus pratique si l’objectif est d’avoir un miroir sur simplement quelques répertoires
- Forcer la rotation de serveur tous les jours pour vérifier le bon fonctionnement. Si votre cluster est constitué d’un système Actif/Passif, forcer le failover chaque nuit, cela permettra de s’assurer que les deux serveurs fonctionnent. Il est aberrant de voir des systèmes sans rotation jusqu’au jour ou la bascule est faite, mais ça ne fonctionne pas…
Cela conclu cette introduction à Asterisk, dans les prochains articles, nous rentrerons plus dans la partie technique en mettant les mains dans le cambouis. Il sera nécessaire d’avoir de solides compétences des systèmes GNU/Linux afin de pouvoir effectuer ses manipulations. Si ce n’est pas le cas, Google regorge de bons nombres de tutoriaux en tout genre afin de se faire la mainÂ
[...] the original post here:Â Asterisk en entreprise Related ArticlesBookmarksTags The Difference Between PHP Echo and Print Few other web [...]
[...] cette introduction à Asterisk, passons maintenant à la partie concrète de la mise en place de notre solution haute [...]