Crash du Master et du Slave le 09 novembre 2011

Nicolas Bondier, 2011-11-09
Switzernet

Description du problème

Le 09 novembre 2011, aux alentours de 8h00 du matin, le Master (Serveur Radius, MySQL) en charge de l’authentification des clients, du routage des appels et de la facturation ne répond plus aux requêtes RADIUS et MySQL. La connections ssh est down et il est impossible d’y accéder depuis internet.

Tous les serveurs Porta-SIP, ne pouvant plus s’identifier auprès du serveur RADIUS, voient leur CPU augmenter violement et ne peuvent plus authentifier aucun appel entrant ou sortant. Le nombre de clients concerné est évalué à environ 2000.

Graphe d’utilisation du CPU pour les serveurs Porta-SIP proche de 100%:

Dans le même temps, le Slave (Réplication de la base de donnée MySQL et Interface Web d’administration) ne reçoit plus aucune information de la part du Serveur master.

Le nombre d’appels par minute n’est plus mis à jour comme le montre le nombre anormalement constant d’appels pendant cette période :

Résolution du problème

Rétablir un service minimum

Les serveurs Astrad, qui sont développés en interne (contrairement aux serveurs Porta-SIP), continuent à acheminer les appels entrants et sortants sans passer par l’authentification RADIUS du Master si celui-ci ne répond plus, grâce à leur propre base de données. Ces serveurs supportent environ 2000 clients.

Dès les premières minutes, nous migrons (par DNS) les clients de deux serveurs Porta-SIP vers deux serveurs Astrad sans clients. Le nombre de clients concernés par la migration est de l’ordre de 500, ramenant le nombre de clients ne pouvant plus passer d’appels à environ 1500.

Les appels entrants sont routés aléatoirement vers des serveurs SIP qui connaissent le(s) serveur(s) sur lequel est enregistré le destinataire de l’appel. Hors certains de ces serveurs sont des serveurs Porta-SIP. Nous avons donc supprimé ces serveurs de la liste des serveurs utilisés pour recevoir les appels entrant et les avons remplacés par des serveurs Astrad qui peuvent transmettre les appels.

A ce moment tous les appareils enregistrés sur les serveurs Astrad sont capables d’émettre et recevoir des appels.

Récupération du Master et Slave

Un peu plus tard, un contact aux Etats-Unis part redémarrer le Master. (Il est 2 heures du matin heure US).

Celui-ci redémarre et nous décidons de redémarrer également le serveur Slave, dont le pourcentage d’utilisation du processeur est élevé. Ce dernier refuse de démarrer. Après plusieurs heures et une réparation des disques durs, il redémarre enfin et redevient opérationnel.

Dans le même temps, le Master crash encore une fois, entre temps nous avons pu voir un pourcentage CPU très élevé, de l’ordre de 100%, et les processus en cause. Nous le redémarrons et supprimons les processus qui sont impliqués dans le crash.

Au stade actuel, les serveurs Porta-SIP peuvent de nouveau communiquer avec le serveur RADIUS et font passer les appels. Il est environ 15h00 (heure locale). Nous modifions les processus incriminés dans le crash du serveur et les relançons. Après une heure de monitoring des serveurs tout semble fonctionner correctement.

Monitoring des serveurs Porta-SIP lors de la reprise du Master :

Reprise de tous les serveurs et acheminement des appels :

Reprise des réplications MySQL

Plusieurs bases de données, utilisés par les serveurs Astrads sont une réplication de certaines informations la base de données du Master (comptes utilisateurs, routes, etc..). La réplication permet à ces bases de données de rester à jour lorsqu’elles sont utilisées par les serveurs Astrad.

Lors des différents crashs du Master, la réplication MySQL avec ces bases de données a été coupée violement, empêchant une reprise automatique. Il a fallu manuellement redéfinir la position des pointeurs de réplication afin qu’elle puisse reprendre. Il est environ 16h00 lorsque la réplication a repris.

Reprise de la réplication MySQL :

Problèmes avec les CDRs des Astrads pendant le période sans Master

Nous avons détecte un problème de facturation que affect quelques utilisateurs que on été enregistres sur les serveurs Astrad et que on fait des appels pendent le période en que le Master été down. Pendant cette période il y des appels que on étés factures plusieurs fois comme est décrit dans le lien suivant (en anglais). Cette appelles iront être remboursés.

http://ftp.switzernet.com/3/public/111110-cdrcomparisionwhilemasterwasdown/

Fin de la panne

Tout est rentré dans l’ordre aux alentours de 16h, bien que tous les serveurs aient été capables de faire suivre les appels à partir de 15h environ

Nous nous excusons pour le dérangement occasionné en ce jour.

* * *