Product
Post-mortem do Mailgun de setembro de 2014
Isso foi relatado em 2 de outubro de 2014.
Queremos apresentar a você um relatório completo sobre os problemas de conectividade que afetaram alguns de nossos clientes do Mailgun nos últimos dias.
A situação
A Rackspace, nossa empresa controladora e provedora de hospedagem, comunicou-nos na sexta-feira, 26 de setembro, que realizaria reinicializações em instâncias de nuvem no data center de Chicago (ORD) que poderiam afetar a infraestrutura do Mailgun, entre o domingo, 28 de setembro, às 11:00 UTC e a segunda-feira, 29 de setembro, às 11:00 UTC. Você pode ler a explicação da Rackspace sobre as reinicializações aqui: http://www.rackspace.com/blog/an-apology/
O Mailgun opera vários ambientes em múltiplos data centers usando a configuração de nuvem híbrida da Rackspace, que emprega balanceadores de carga da F5 e que são usados como o gateway primário para todas as conexões de entrada e saída em nossos data centers. Em caso de interrupções ou manutenções nesses ambientes, o Mailgun redireciona o tráfego de forma contínua a partir dos ambientes afetados usando os pools de IP virtuais da F5, sem afetar os clientes nem alterar o DNS. Isso nos dá mais controle sobre o tráfego, o que nos permite aumentar ou diminuir gradualmente as proporções de balanceamento de carga nos IPs virtuais e distribuir o tráfego entre os ambientes.
O plano
Para evitar impactos para os clientes como resultado das reinicializações das instâncias de nuvem de ORD, nós nos preparamos para transferir o tráfego desse ambiente e fizemos todas as mudanças necessárias para isso. No sábado, 27 de setembro, às 18:50 UTC, notamos que todas as réplicas de banco de dados, bem como o fluxo de tráfego interno entre os ambientes de todas as regiões, estavam interrompidos e começaram a relatar esgotamento de tempo limite.
Não conseguimos determinar a causa raiz dos esgotamentos de tempo limite antes do início das reinicializações das instâncias de nuvem em ORD e, consequentemente, não pudemos transferir o tráfego a tempo de evitar impactos para os clientes.
O que de fato aconteceu
As reinicializações das instâncias de nuvem em ORD começaram à 01:10 UTC na segunda-feira, 30 de setembro, e resultaram nos seguintes problemas entre 01:10 UTC e 11:29 UTC:
- Falhas intermitentes de conexão
- Eventos perdidos entre 02:30 UTC e 07:00 UTC
- Aproximadamente 100.000 e-mails duplicados enviados
Todas as mensagens relatadas como aceitas durante essa interrupção foram entregues.
Uma parte dos clientes do Mailgun continuou passando por perda intermitente de conexão e taxas de falha até a tarde de terça-feira, 30 de setembro.
Trabalhamos com a equipe de redes corporativas da Rackspace na investigação e finalmente conseguimos identificar a origem do problema.
A manutenção da nuvem serviu de gatilho para a condição de erro nos servidores F5 do Mailgun, que começaram a relatar o Path MTU com valor 296 para os IPs nas redes do Mailgun, que foi armazenado em cache por todos os F5s dos clientes dedicados da Rackspace que usam o Mailgun.
Os F5s dos clientes dedicados da Rackspace armazenaram em cache o MTU de 296, mas os servidores por trás dos F5s só eram capazes de enviar pacotes com o mínimo de 512 MTU, o que serviu de gatilho para a perda de pacotes, pois o F5 do Mailgun forçou o MTU com o valor menor.
A equipe de redes da Rackspace limpou os caches dos F5s do Mailgun e dos F5s de alguns clientes dedicados da Rackspace, e configurou o novo IP virtual para os serviços do Mailgun. O Mailgun alterou as configurações de DNS, o que forçou a limpeza dos caches nos F5s remotos. Essa solução alternativa resolveu os problemas restantes para os clientes dedicados da Rackspace que usam o Mailgun.
Continuamos trabalhando com a Rackspace para investigar a causa raiz do problema. Neste ponto, podemos afirmar que ele está relacionado a um valor excepcionalmente baixo de path MTU, que foi originalmente armazenado em cache e forçado pelos balanceadores de carga F5 do Mailgun.
Daqui para frente
Nós levamos o tempo de atividade a sério e pedimos desculpas a todos os clientes do Mailgun que foram afetados por esse problema. Assim que concluirmos nossa análise de causa raiz sobre o problema do F5, tomaremos medidas para garantir que, quando nossa infraestrutura de nuvem passar por manutenção, não haja impacto para os clientes do Mailgun.
