Mercury mail plate-forme faute examen


Si vous avez éprouvé un blip avec votre email de mercure a accueilli dernièrement, nous avons voulu prendre un moment pour passer en revue les événements récents ; pour décrire ce qui s’est passé, pourquoi et ce que nous faisons pour répondre à la plus grande fait aller de l’avant.

Première mise, mercure lui-même. Beaucoup d’utilisateurs ont interrogé la redondance du système. D’un point de vue architectural, mercure est l’un de nos plateformes plus complexes et les plus stables. Nous savons comment ultra email important est aux sites Web et les entreprises du peuple, si le système est conçu partir du sol pour la tolérance aux pannes maximale. Cela signifie que chaque composant du système est répliqué plusieurs fois afin que si une pièce s’avère défectueuse, l’autre reprend en toute transparence.

Chaque partie du processus de courrier est éclaté dans un service distinct de micro et à tourner répliqué plusieurs fois. Authentification du courrier, filtrage anti-spam, webmail traitement, traitement SMTP et IMAP/POP traitement que tous fonctionnent comme des services complètement indépendants de micro, chacun à son tour alimenté par plusieurs différentes machines virtuelles. Nous avons souvent voir une de ces machines virtuelles n’absolument pas, n’ayant aucun impact à l’expérience de l’utilisateur final.

Va de même pour le stockage de courrier électronique sur le mercure. À un moment donné, nous hébergeons double chiffre téraoctets de données email ; Cela signifie que nous nous appuyons sur les équipements de stockage très spécialisées, ligues en dehors de la configuration de disque vous pourriez reconnaître dans votre ordinateur portable ou PC. Disques sont ajoutés à l’appareil par paires, alors que lorsque les données sont écrites sur le périphérique de stockage se faite de telle manière qu’un disque dans le couple peut échouer sans impact. Le système utilise également des disques de secours – live des disques vierges dans l’appareil de stockage que détecter les pannes et copier les données immédiatement à eux-mêmes en cas de défaillance d’un paire de disque. Les données sont réparties également sur la plus grande baie de disques, pour une plus grande tolérance aux pannes : l’appareil peut supporter plusieurs pannes de disque simultanée n’ayant aucun impact sur les performances. Aucun un seul disque ne stocke votre courrier électronique. Enfin, nous courons aussi deux de ces appareils, pour séparer le stockage des e-mails à travers deux grandes piscines.

Donc ce qui s’est passé récemment et pourquoi la dégradation du service ? Le 23 mars, un de nos pools de stockage ont franchi une ligne magique de toutes sortes. L’utilisation du stockage de l’appareil se soit glissée au-dessus de la barre des 80 % (toujours l’espace disque libre de 20 %), et notre service est devenu touché. Les périphériques de stockage utilisent ZFS – une structure de fichiers spécialisés pour les applications de stockage à grande échelle. Avant la barre des 80 %, ZFS écrit simplement données à la fin de l’espace disque libre contiguë. Supérieur à 80 %, ZFS bascule vers un modèle différent et commence à calculer où poches d’espace libre pouvant exister sur le disque – et plutôt écrit à ceux vide les taches sur le disque. Cela augmente la charge sur le système en raison de la surcharge de traitement considérablement et est l’événement que nous avons rencontrés le 23.

dans des circonstances normales, nous ajoutons simplement un stockage plus long avant que cela devient un problème. Les appareils de stockage permettent pour nous déployer nouveau stockage à tout moment sans déconnecter le système. Menant à l’événement du 23 un système de contrôle interne a échoué, et finalement nous n’avons pas place la ligne magique embrouillage. Dès que nous l’avons fait, nous avons travaillé avec nos fournisseurs pour envoyer les nouveaux disques directement à nous. Compte tenu de la nature unique des disques, aucun n’était disponible dans notre région immédiate, et comme tel, ils devaient être express par messagerie à travers le pays. Cela a pris du temps, mais nous avons eu des disques installés par le soir de la 23e et services restaurés opération normale par la suite.

L’impact de la ZFS basé lentement vers le bas signifie que l’accès est devenu intermittent pour certains utilisateurs. L’ensemble du système Mercure courriel dans son ensemble devient surchargé progressivement lorsqu’il ne peut pas accéder au stockage back-end assez rapidement. Le principal impact de cela signifie connexion temps morts pour les utilisateurs accèdent au système. Il n’est cependant moyenne nous ne rebondissent pas e-mail, le système est toujours réception de courriels très bien et d’écriture sur le disque, bien que lentement.

Après le 23, nous avons pensé que nous avions le principal problème résolu, mais nous avons rencontré des problèmes supplémentaires avec le périphérique de stockage un peu plus d’une semaine plus tard. Un petit nombre d’utilisateurs a recommencé à des problèmes de connexion de rapport. Encore une fois, nous avons vu augmenter la charge sur le système et fait un certain nombre de réglages de configuration que nous avons cru contribuerait à la situation. Comme nous sommes allés au vendredi descendre la 31 charge sur le système, un accès amélioré et a été en grande partie irréprochable par le week-end du 1er avril et le 2.

Toutefois, viennent l’après-midi du lundi 3 avril, et la demande accrue pour le courrier électronique (de lundi un des moments plus fréquentés pour accès au courrier électronique) le système de stockage recommença à surcharger. Tout comme l’événement des utilisateurs 23 a commencé à recevoir des erreurs de connexion à nouveau.

À ce stade, le système était bien sous la marque d’utilisation de stockage de 80 % après les récents ajouts de matériel, et malgré les multiples réglages de configuration, nous étions aux prises réduire la charge sur le système. Comme nos autres avenues de réduire la charge a commencé à diminuer, nous avons commencé à assurer la liaison avec les fournisseurs de l’équipement de stockage sur quelles options pourraient être ouvert à nous.

En attendant leur réponse et l’examen de la situation, nous avons continué à améliorer meilleur effort au système pour réduire la charge sur le pool touché de disques. Nous avons commencé à regarder les boîtes aux lettres spécifiques et utilisateurs à travers le système – ceux avec l’utilisation de la plus grande, et comment nous pouvions travailler avec ces comptes pour peut-être diminuer globalement de charger. Étonnamment, nous sommes tombés sur une boîte aux lettres avec quelque 2 millions e-mails stockés. E-mails sont simplement stockés comme des petits fichiers sur le disque. Théoriquement, 2 millions de fichiers dans un répertoire est cédé sous le ZFS file limites, par ordres de grandeur en fait, mais encore nous avons voulu réduire la charge sur le pool touché.

L’énorme quantité de fichiers signifie enlever 2 millions d’entre eux était un processus durant la nuit, mais charge a été améliorée immédiatement le processus terminé. Dans l’intervalle, nous avions également conseillé aux utilisateurs avec des boîtes de réception particulièrement grande de même réduire le nombre de leur boîte de réception ; Si l’accès par webmail par exemple, chaque email est lu par le système avant du charger dans le navigateur. L’ensemble du travail a commencé à vraiment faire un impact sur la performance et de premières heures mardi 4 avril, nous avons commencé à voir les performances des disques considérablement améliorée et l’accès. La plupart des utilisateurs ont été maintenant retomber sur leurs pieds.

Deux événements de compoundage finaux étaient masqués par les problèmes de stockage globale. Dans la lutte contre ces grands événements plus petits articles peuvent être difficiles à repérer parmi l’embardée volume de charge d’appui que nous recevons. En bref ordre puis, un nouveau hack déploie sa présence ressentie sur certains comptes et spam quittait un sous-ensemble des comptes en gros volume, cela a causé quelques noires SMTP et mail retards de livraison. Nous avons également vu une corruption des fichiers de dovecot-utilisateurs pourraient avoir accès à leur webmail, mais trouveraient un appareil iOS, refusant obstinément de se connecter. Celles-ci nécessitent simplement une configuration rapide, reconstruite au niveau de l’utilisateur de fixer – et encore – entraîner aucune perte de courrier électronique, juste accéder aux questions.

Alors que faire ensuite ? Malgré la vacille, mercure reste un système compétent et capable. Certaines des limitations de notre application ZFS étaient certes nouvelles pour nous, mais avec la connaissance en main, nous prenons des mesures pour aller de l’avant comme suit :

* importante nouvelle capacité du disque a été déployée sur les baies de stockage, pour aider à lutter contre les contraintes de capacité pour l’avenir immédiat.

* suivi de l’utilisation du stockage de l’appareil a déjà été remaniés et de nouveaux processus mis en œuvre. Nous sommes également en train d’ajouter des coffres d’échec encore plus dans le processus et les outils de surveillance.

* nous passeront en revue l’utilisation de certains comptes d’utilisateurs et peu être déploiement de nouvelles limitations sur l’utilisation de la plate-forme. Rien de ce qui aura un impact tout usage standard du mercure, mais empêchera tout cas extrême bord provoquant des événements délétères.

* un troisième bassin de stockage sur disque est prévu.

* nous avons aussi une plate-forme ceph en interne, qui est récemment déplacé d’alpha à statut beta. Bien que pas tout à fait prêt pour l’utilisation des heures de grande écoute, nous sommes l’évaluation ceph pour notre long terme stockage a besoin et sont actuellement très optimiste sur les capacités.

Nous tenons à remercier toutes les personnes touchées pour leur patience et leur compréhension. Nous savons email est critique, nous avons nous-mêmes utilise du mercure et s’appuient sur elle critique trop. Lorsque ces événements se produisent que nous travaillons autour de l’horloge pour les atténuer, mieux nous pouvons.

Si vous avez des questions sur l’événement ou vos services affectés ou des pensées nouvelles, s’il vous plaît n’envoyez pas un email m’a marqué la FAO personnellement – Stuart ; Je serai heureux de discuter de tout cela plus en détail directement avec vous.