Au commencement, il y avait le Mot…

… et le Mot fut écrit… et avant même la naissance d'internet, le Mot est devenu une part critique de nos vies... Oui, c'est exact… E-mail. Bref, en tant que registrar, Gandi fournit des services email pour les noms de domaines enregistrés chez nous. Jusqu'ici, tout va bien… La plateforme originale a été conçue pour être dimensionnable horizontalement afin de supporter plusieurs dizaines, voire centaines de milliers de boites mails. L'un des défis rencontrés fût une architecture pourvue de capacités de stockage dimensionnables tout en permettant les utilisateurs d'accéder à leurs boites sans même vérifier sur quel système de stockage ou d'accès ceux-ci étaient raccordés. Ça ressemble bien à un boulot pour ce bon vieux Network File System (NFS). Du coup, la plateforme originale fut basée sur une infrastructure NFS pour les boites mail.

Les mails entrants étaient reçus sur n'importe lequel des nombreux serveurs entrants tournants sur Postfix. Une fois les mails reçus et passés aux moulinettes antispam et autres filtres, le spool s'occupait alors d'identifier quel filer de stockage contenait la boite mail en question, puis forwardait le mail en utilisant le SMTP au serveur de stockage de backend (lui-même utilisant aussi Postfix) pour la livraison locale.

Lorsque l'utilisateur souhaitait accéder à sa boite mail, il devait accéder à un serveur frontal faisant tourner Dovecot. Les serveurs d'accès devaient avoir un accès "local" à toutes les boites mails via l'utilisation des montages NFS. Le client souhaitait simplement utiliser un client POP ou IMAP pour se connecter au serveur, pour accéder à sa boite mail.

Le mail sortant est plus simple; basiquement, un relais SMTP utilisant une authentification SASL.
Le schéma suivant vous montre un très haut niveau de vue générale de la version originale de la plateforme Mail.

Et ? Qu'est-ce qui a changé ?

Okay – avant de savoir ce qui a changé, regardons d'abord pourquoi nous avions à le faire.

La plateforme originale était jolie et l'architecture fonctionnait très bien à un niveau de trafic modéré, indépendamment du nombre de boites mail. Le risque avec le fait de dimensionner une plateforme basée sur le nombre de boites mail, c'est que c'est très facile à surcharger ou, dans certains cas, mal interpréter les effets induits de ce dimensionnement. Alors que le trafic commençait à augmenter au fil des années, de temps à autre, les serveurs d'accès frontaux avaient à lutter pour accéder au système de fichiers NFS, qui lui, utilise un système de verrouillage pour éviter les corruptions pouvant intervenir dans le cas d'opérations de lecture/écriture multiples sur le même fichier (ou bloc).

Ce graphique représente les volumes moyens pour l'année dernière (notez que les courbes ne sont pas agrégées, donc les éléments sont cumulatifs). L'axe vertical représente le nombre de "messages par minute" (avec un indice max. à 24 000) alors que l'axe horizontal représente les mois (avril à mars).

Alors que les verrouillages augmentaient avec le temps (et rappelez-vous que tous les serveurs avaient un accès à travers tous les systèmes de fichiers), le résultat fut un effet boule de neige qui a engendré de sévères dégradations des performances de l'ensemble de la plateforme – et pas seulement des boites mails présentes sur le serveur de stockage concerné par le verrouillage en cours.  Pendant ce temps, les utilisateurs essayaient de se connecter à leurs boites mail dont le serveur acceptait la connexion et attendait simplement que le verrouillage cesse pour les laisser accéder aux boites.

Donc, les défis étaient simples :

  • Comment supprimer le besoin de NFS et continuer à permettre le dimensionnement horizontal.
  • Comment éviter d'impacter la plateforme Mail complète en cas de problème sur un seul serveur de stockage, et comment minimiser l'impact sur les utilisateurs dans ce cas.
  • Comment maximiser les performances de la plateforme pour permettre le dimensionnement vertical aussi bien qu'horizontal.

Comme il y a très peu de changement sur les éléments du spool SMTP entrant, et que la majorité de la charge était associée au NFS, regardons de plus près les éléments d'accès.

Où est ma boite mail ?

D'accord, donc l'utilisateur se connecte à sa boite mail avec son client préféré (Thunderbird, Outlook Express, Mail.App, Evolution, ou n'importe quoi d'autre dans ce cas…). La connexion du client arrive sur l'un des nombreux serveurs frontaux d'accès Mail sous Dovecot. Comment, du coup, le serveur sait où chercher pour trouver l'email ? À l'origine, le mail était en "local" puisque tout était monté en NFS. Dovecot fait une simple requête en base pour déterminer le chemin d'accès de la boite mail de l'utilisateur. Avec le nouveau système, il n'y a pas de NFS, donc pas de système de fichier "local" où Dovecot pourrait chercher.

C'est à cet instant qu'une option très utile de Dovecot entre en scène : la fonction proxy. En l'utilisant, le serveur frontal s'occupe de l'authentification de l'utilisateur, vérifie quel serveur de stockage héberge la boite mail, puis initie une connexion "client" proxyfiée directement avec le serveur de stockage qui tourne, lui-même, sous Dovecot. Si le client se connecte en utilisant l'IMAP, alors la connexion proxy sera aussi IMAP.
De la même manière, si le client utilise POP3, alors la connexion proxy sera POP3. Le serveur de stockage n'a pas besoin de re-authentifier la connexion.

Il y a plusieurs bénéfices avec cette architecture :

  • La suppression du NFS supprime également l'effet de bord des locks NFS
  • Puisque le serveur backend de stockage a la boite mail physiquement attachée en local, il n'y a pas de conflit dans le filesystem, et donc pas besoin de locks. De plus, maintenant que les baies de stockage sont en hautes performances, les accès aux boites mails sont beaucoup plus rapides.
  • Les serveurs frontaux n'ont plus à faire d'opérations couteuses en I/O sur les disques locaux, et consomment donc considérablement moins de CPU (en fait, techniquement, il n'y a aucune vraie raison pour que les frontaux aient leurs propres disques. Cela pourrait même réduire les coûts de dimensionnement horizontal de pouvoir utiliser des serveurs sans disque…).

Et que se passe t'il si un Filer lache ?

Afin de répondre à l'autre partie du défi, et de limiter l'impact en cas de défaillance d'un composant pour le moins d'utilisateurs possible, le concept original de stockage dimensionnable pour tenir le maximum de boites mail possible a dû être abandonné. Après tout, si un filer tombe, toutes les boites mails associées seraient également hors ligne.

Du coup, l'idée ici est d'augmenter le nombre de serveurs de stockage, et de répartir les boites mails plus finement entre eux. De cette manière, en cas de défaillance du serveur de stockage, beaucoup moins de boites mails sont affectées.

Le second aspect pour minimiser l'impact d'une défaillance d'un composant est  lui aussi assez simple. Avec la version précédente de la plateforme (vous vous rappelez des locks NFS ?), une connexion d'un client mail à sa boite était juste répondu par le serveur d'accès et attendait simplement de pouvoir accéder au système de fichiers. L'effet pour l'utilisateur est que son client mail se plante là et éventuellement, se fait time out.

En utilisant l'arrangement proxy IMAP/POP3, si le serveur de stockage actuel est tombé, le serveur frontal répondra immédiatement au client mail avec un message "Temporarily Unavailable", et la connexion TCP sera fermée.

Les baies de disques sont elles-mêmes bien entendu redondantes. Le seul réel point de faiblesse (SPoF) potentiel est le serveur qui contrôle les baies de disque, car à cause d'une limitation technique des baies, il n'est pas possible d'avoir un double contrôleur si l'on utilise des volumes séparés et en miroir RAID via deux baies de disques. Cela serait possible si les volumes n'étaient pas en miroir entre baies, mais ce serait plus risqué puisqu'il n'y aurait pas de copie "backup" des données en cas de défaillance d'une baie… Nous considérons donc que le risque d'avoir un seul contrôleur de serveurs de disque est un risque acceptable, étant donné que nous en avons un autre de disponible, prêt à être monté. L'image ci-dessous illustre la solution de stockage des mails



Mais...on a rien vu en fait ?

Si vous êtes dans cette catégorie, c'est que le pari est réussi ! C'était le postulat absolu du début : tout changer sans impacter nos clients et sans perdre de données.

Alors, comment s'est passée la migration ?  Bon, bien sûr déjà, le processus a duré plusieurs semaines, pendant les périodes où l'activité était la plus faible. Nous avons opéré unité de stockage après unité de stockage, en migrant via plusieurs itérations de rsync. À la dernière, nous avons mis la base de données à jour pour indiquer à la boite son nouvel emplacement.

Au fur et à mesure des semaines, un effet secondaire appréciable a tout de suite été détecté avec le retrait du NFS de la plateforme, la charge sur les serveurs d'accès a graduellement diminué, ce que vous pouvez voir sur le graphique ci-dessous.  Maintenant que NFS a disparu, la charge serveur est quasi nulle.  Les 2 graphiques ont une échelle relative qui donne une moyenne sur la période. Le premier est sur 6 mois alors que le deuxième montre la moyenne sur les 5 dernières semaines.



Voilà, J'espère que ce (petit) article vous a donné une bonne idée de ce à quoi ressemble notre nouvelle plateforme Gandi Mail, ses nombreux avantages en terme de performance et de robustesse.