OVHcloud Web Hosting Status

Current status
Legend
  • Operational
  • Degraded performance
  • Partial Outage
  • Major Outage
  • Under maintenance
Mailproxy
Incident Report for Web Cloud
Resolved
Depuis 11h10 nous constations des ralentissements sur mailproxy qui est le point d'entrée de notre infrastructure mail.

Des délais de livraison de mail sont à prévoir.

Update(s):

Date: 2017-02-24 10:43:37 UTC
La situation est redevenu normal.
Nous n'avons pas eu besoin de passer par l'instance MySQL.
Le service a été dégradé durant 10min (70% du traffic était géré).
Pas de perte de service, ni d'emails, un délai de 30min maximum.

Date: 2017-02-24 10:26:07 UTC
L'insert est en cours mais la livraison est stable.
200k de messages en attentent

Date: 2017-02-24 10:20:41 UTC
La livraison est perturbé.
Nous avons couper les écritures sur les bases.
On dump et importe les datas sur l'instance de MySQL.

Date: 2017-02-24 10:13:07 UTC
Nous avons constaté que depuis 11h le problème se reproduit.
Nous faisons le nécessaire pour minimiser l'impact sur la distribution des mails.


Date: 2017-02-23 23:23:41 UTC
Bonjour,

La réception des emails a été très dégradé aujourd’hui.
Nous avons eu un incident sur l’infrastructure MailProxy, elle permet de livrer les emails.
Cette infrastructure est composée de 4 types de serveurs :
- Les serveurs « input » en front de l’infrastructure, ils permettent de faire les premières vérifications et d’encaisser la charge venant de l’extérieur.
- Les serveurs « anti-virus/anti-spam » qui comme leurs noms l’indiquent ils se chargent de la détection des spam et des virus.
- Les serveurs « output » en sortie, ils permettent de faire les dernières vérifications et d’envoyer les messages vers la bonne destination. Ils sont conçus pour stocker une grande quantité de messages en cas de défaillance de l’infrastructure de destination.
- Les serveurs « SQL », ils contiennent la configuration pour chaque adresse email sur la destination, le niveau de vérification et les actions à mettre en œuvre. Nous utilisons des bases MySQL répliqué avec le système Galera.

C’est sur ces serveurs « SQL » que le problème est survenu ce qui a impacté l’ensemble de l’infrastructure.
A 10h50 environ, nous avons constaté une lenteur au niveau de la livraison, les messages commençaient à s’accumuler sur les 3 niveau de l’infrastructure.
Nous avons analysé les graphiques de monitoring sur les I/O des disques, le nombre de connexion entrantes, la charge, la mémoire, … et c’est sur les graphiques des serveurs « SQL » que nous avons constaté un nombre anormal de thread en cours.
A 11h, nous avions 500k de messages en attentes sur les serveurs.
Nous identifions un serveur « SQL » générant ce grand nombre de thread, nous décidons de redémarrer le service SQL.
A 11h20, nous avons 750k de messages en attentes.
Nous voyons que les serveurs « SQL » génèrent chacun leurs tours ces threads ralentissant l’ensemble de l’infrastructure. Nous redémarrons les serveurs un par un.
A 12h, 1300k messages en attentent.
Le service est meilleur mais reste dégradé et instable. Nous ajustons la configuration et diagnostiquons le problème.
A 13h, 1200k messages en attentent.
Le service est de plus en plus instable, nos ajustements de configuration ne solutionnent pas le problème.
Nous décidons de commander un serveur disponible le plus rapidement possible avec une « grosse » configuration pour mettre un serveur MySQL basique pour gérer le service.
Nous prenons une instance cloud HG-120-SSD.
A 13h25, 1500k messages en attentent.
Nous installons le serveur (OS, sécurité, réseau et les programmes nécessaire).
Nous coupons les écritures sur les serveurs « SQL » et faisons un dump, puis nous le réimportons dans le serveur MySQL.
A 14h, 1000k messages en attentent.
Nous lançons les tests du serveur et préparons l’infrastructure pour utiliser ce serveur.
A 14h40, 2000k messages en attentent.
Les serveurs « SQL » sont devenus très instables, nous mettons le serveur MySQL au fur et à mesure dans l’infrastructure.
A 15h, 2200k messages en attentent, ce sera le plus gros pic de message sur l’infrastructure.
L’ajout du serveur MySQL pour la moitié des serveurs de l’infrastructure permet de stabiliser les serveurs « SQL » qui peuvent gérer l’autre moitié.
A 15h45, 1600k messages en attentent les serveurs « input » ont rattrapés leurs retards.
A 16h25, 1200k messages en attentent les serveurs « anti-virus/anti-spam» ont rattrapés leurs retards.
A 18h45, 200k messages en attentent les serveurs « output » ont rattrapés leurs retards a l’exception de 2 serveurs moins performants (en cours de remplacement).
A 20h45, tout est revenu à la normal.

Nous allons changer ce système Galera par un autre système (benchmark dans les prochains jours). En attendant, nous gardons le serveur MySQL et automatisons l’installation d’un nouveau au cas où.

Nous sommes désolés pour cet incident, aucun email n’a été perdu, juste des délais important ont été constaté.

Date: 2017-02-23 14:50:18 UTC
La situation est stabilisé depuis 1h environ , les mails en attente sont en cours de livraison.

Date: 2017-02-23 11:24:03 UTC
Actuellement nous constatons une accumulation des mails.
Nous travaillons toujours au rétablissement de la situation.
Posted Feb 23, 2017 - 10:17 UTC