Product
Post mortem de Mailgun de septiembre de 2014
Se publicó este informe el 2 de octubre de 2014.
Queremos ofrecerte un informe completo sobre los problemas de conectividad que han afectado a algunos de nuestros clientes de Mailgun en los últimos días.
La situación
Rackspace, nuestra empresa matriz y proveedor de alojamiento, nos comunicó el viernes 26 de septiembre que iba a reiniciar las instancias en la nube del centro de datos de Chicago (ORD). Esto podía afectar a la infraestructura de Mailgun entre el domingo 28 de septiembre a las 11:00 UTC y el lunes 29 de septiembre a las 11:00 UTC. Puedes leer la explicación de Rackspace sobre los reinicios aquí: http://www.rackspace.com/blog/an-apology/
Mailgun opera varios entornos en múltiples centros de datos mediante la configuración de nube híbrida de Rackspace. Esta configuración emplea balanceadores de carga de F5 y se utiliza como puerta de enlace principal para todas las conexiones entrantes y salientes en nuestros centros de datos. En caso de interrupciones o mantenimientos en estos entornos, Mailgun redirige el tráfico de los entornos afectados de forma segura mediante grupos de IP virtuales de F5, sin afectar al cliente ni realizar cambios de DNS. Esto nos da un mayor control sobre el tráfico, lo que nos permite aumentar o reducir gradualmente las tasas de balanceo de carga en las IP virtuales y distribuir el tráfico entre los entornos.
El plan
Para evitar que el cliente se viera afectado a causa de los reinicios de las instancias en la nube de ORD, nos preparamos para desviar el tráfico de este entorno e hicimos todos los cambios necesarios para ello. El sábado 27 de septiembre, a las 18:50 UTC, notamos que todas las réplicas de bases de datos, así como el flujo de tráfico interno entre los entornos de todas las regiones, se habían interrumpido y empezaban a generar informes de tiempo de espera agotado.
No pudimos determinar la causa principal de los tiempos de espera agotados antes de que empezaran los reinicios de las instancias en la nube en ORD y, por consiguiente, no pudimos desviar el tráfico a tiempo para evitar repercusiones en el cliente.
Lo que ocurrió realmente
Los reinicios de las instancias en la nube en ORD empezaron a la 1:10 UTC del lunes 30 de septiembre y provocaron los siguientes problemas entre la 1:10 UTC y las 11:29 UTC:
- Fallos de conexión intermitentes
- Pérdida de eventos entre las 2:30 UTC y las 7:00 UTC
- Envío de aproximadamente 100 000 emails duplicados
Todos los mensajes notificados como aceptados durante esta interrupción se han entregado.
Una parte de los clientes de Mailgun siguió experimentando pérdidas de conexión intermitentes y tasas de fallo durante la tarde del martes 30 de septiembre.
Colaboramos en la investigación con el equipo de redes empresariales de Rackspace y finalmente pudimos identificar el origen del problema.
El mantenimiento en la nube sirvió de disparador para la condición de error en los servidores F5 de Mailgun, que empezaron a generar un informe de la Path MTU con el valor 296 para las IP de las redes de Mailgun. Además, todos los F5 de los clientes dedicados de Rackspace que usaban Mailgun lo almacenaron en caché.
Los F5 de los clientes dedicados de Rackspace almacenaron en caché una MTU de 296, pero los servidores situados detrás de los F5 solo podían enviar paquetes con un mínimo de 512 de MTU. Esto actuó como disparador de la pérdida de paquetes, ya que el F5 de Mailgun impuso la MTU de menor valor.
El equipo de redes de Rackspace borró las memorias caché de los F5 de Mailgun y de los F5 de algunos clientes dedicados de Rackspace, y configuró la nueva IP virtual para los servicios de Mailgun. Mailgun cambió los ajustes de DNS, lo que forzó el borrado de las cachés en los F5 remotos. Esta solución temporal resolvió los problemas restantes para los clientes dedicados de Rackspace que usaban Mailgun.
Seguimos trabajando con Rackspace para investigar la causa principal del problema. Llegados a este punto, podemos decir que está relacionado con un valor inusualmente bajo de Path MTU que los balanceadores de carga F5 de Mailgun almacenaron en caché e impusieron originalmente.
De cara al futuro
Nos tomamos muy en serio el tiempo de actividad y pedimos disculpas a todos los clientes de Mailgun que se vieron afectados por este problema. Una vez que hayamos completado nuestro análisis de la causa principal del problema de los F5, tomaremos medidas para garantizar que no haya ninguna repercusión en los clientes de Mailgun cuando nuestra infraestructura en la nube se someta a mantenimiento.
