para milhões. Francisco Gleicon

Tamanho: px

Começar a partir da página:

Download "E-mail para milhões. Francisco Freire @ffreire Gleicon Moraes @gleicon"

Wagner Frade Campelo
8 Há anos
Visualizações:

1 para milhões Francisco Gleicon

2 Construir um sistema de s escalável para milhões de acessos/ usuários.

3 Como Era:

4 Como era: Recebimento Entrada DB SMTP MX (Qmail) MySQL QMQP MTA (Qmail) NFS Storage QMAIL; Apenas 1 filtro (Externo); MX sem fila local; MX sem fila fallback; Erros de backend repassados para fora; Sem limites; Balanceamento por LVS; Servidores consultando DB sem cache; MTA sem alta disponibilidade; MTA sempre com filas de entrega;

backend repassados para fora; Sem limites; Balanceamento por LVS; Servidores

5 Como era: Leitura DB MySQL Usuário Backend (Qmail / Dovecot / Courier) Storage Pop3 / Imap NFS QMAIL; Usuário acessa diretamente o backend; Sem Limitações; Acesso a banco sem cache; Falta de logs completos; Balanceamento por LVS; Sem SSL; Bugs e mais bugs; 2 tipos de imap rodando; o Dovecot (143) o Courier (144)

Acesso a banco sem cache; Falta de logs completos; Balanceamento por LVS; Sem

6 Como era: Webmail Usuário DB MySQL Webmail HTTP PERL; CGI; NFS; NFS Storage

7 Por onde começar?

8 POSTFIX; Diminuir a entrada de lixo; Não voltar erros para fora; Melhorar tracking de problemas; Alterações mínimas da estrutura; Diminuir carga no banco com CDB; Implementação da fallback; Implementação de limitações; POSTFIX; Implementação rápida; Redução bruta da entrada de lixo; Problemas para entrega via QMQP; Demanda reprimida; Sobrecarga nos backends; 10x consumo de banda Problemas com DNS Recebimento (MX) Teoria Prática

limitações; POSTFIX; Implementação rápida; Redução bruta da entrada de lixo; Problemas para entrega via

9 Entrada Recebimento (MX) SMTP CDB MX (Postfix) Fallback (Postfix) Cache QMQP DB MySQL MTA (Qmail) NFS Storage

10 Recebimento (MX) Muito cuidado com capacity, picos de recebimento, podem e irão acontecer. Fila fallback recebe o excedente.

11 Webmail Teoria Prática Acessar via IMAP; Utilizar PHP; Roundcube; Mod_php; Slaves de banco locais; Pool único; Independente de backend; Sobrecarga nos backends; Adaptação de usuários; Adaptação de capacity; Mudança cultural; Primeiros problemas globais;

Independente de backend; Sobrecarga nos backends; Adaptação de

12 Usuário Webmail DB MySQL (local) Webmail HTTP / HTTPS Ganho de latência com database local; Ganho de eficiência com mod_php; Ganho de eficiência com acesso via IMAP; Replication IMAP DB MySQL Backend (Qmail / Dovecot / Courier) NFS Storage

mod_php; Ganho de eficiência com acesso via IMAP;

13 Leitura (Pop3 / Imap) Teoria Prática Adicionar camada global; Evitar acesso direto ao backend; Fail2ban / Limites; Padronização; Dovecot apenas; Cache no acesso ao banco; Melhor balanceamento; SSL; Novos problemas globais; Adaptação de capacity; Aprendizado; Melhor utilização do banco; Maior estabilidade; Melhor administração; SSL;

banco; Melhor balanceamento; SSL; Novos problemas globais; Adaptação de capacity;

14 Usuário Leitura (Proxy) Pop3(s) / Imap(s) Cache Frontend (Proxy) Pop3 / Imap DB MySQL Backend (Qmail / Dovecot / Courier) NFS Storage

15 MTA Teoria Prática Dovecot; Cache; Suporte ao mesmo formato (maildir); Novos mailboxes = mdbox; Lmtp; Alta disponibilidade + director; Melhora considerável na estabilidade; Migração dolorida (+cache); Melhor uso de storage; Maior disponibilidade; Menos filas;

director; Melhora considerável na estabilidade; Migração

16 Novo ambiente Recebimento Recebimento Qmqp Lmtp Leitura Backend (Qmail / Dovecot / Courier) Webmail Leitura Backend (Dovecot) Webmail NFS Pop3 / Imap NFS Imap Storage Storage

17 Acesso ao banco Master Webmail Cache Frontend Slave Backend

18 Evolução de Storage (V1) Produção 2TB Archive 2TB /home{%d}/{%login} mv + ln -s /home{%d}/{%login} FreeBSD Sem backup; Sem HA; Pouco espaço; UFS + async; Único dataset; Arquivamento manual com link simbólico;

19 Evolução de Storage (V2) Produção 7TB /storage/{%h}/{%h}/{%login} OpenIndiana ZFS; Backup cruzado; Sem HA; Snapshot; 8 datasets; Sem arquivamento; ZFS send;

20 Evolução de Storage (V3) Produção +PB /storage/{%h}/{%h}/{%login} Isilon; Backup cruzado; HA; Tiering; Snapshot; OneFS; 1 dataset; Sem arquivamento;

21 Boas práticas Red Hat AS 3 -> Debian squeeze (Wheezy) Qmail -> Postfix / Dovecot LVS nat -> LVS DR / F5 / Haproxy MySQL 4x -> Percona 5x Master/Slave -> Master/Slave/Cluster Provisionamento via raid -> Closed-loop / Cfengine Vdeliver -> Sieve Diversas linguagens -> Python Servidor de logs Métricas (+leela)

22 Sem eles não seria possível... Mailfromd ( Postfix milter rápido e escalável o suficiente para aplicarmos regras de negócio como por exemplo: Análise de headers e conteúdo de mensagens. Redis ( Key/Value database extremamente rápido, usamos e abusamos de "sorted sets". Todos os nossos contadores e muita informação de cache está nele. Único contra é usar apenas 1 core da máquina. Twenproxy (Nutcracker) ( Proxy para redis/memcache. Com ele resolvemos o problema do redis usar apenas 1 core da máquina e utilizando shard conseguimos escalar o ambiente conforme necessidade. Haproxy ( De longe, o melhor proxy tcp que encontramos, utilizamos nele tanto o balanceamento de banco de dados quanto HTTP. Python ( Linguagem de programação que adotamos, fácil aprendizado e conseguimos utilizá-lo em diversos items da estrutura, policy, scripts, dashboard (django) e mais.

23 Números (10/04/2014) Estrutura: Servidores (Físicos e Virtuais): 595 Storage utilizado: 2.5PB Domínios: 450K Mailboxes: 6M Destinations: 10M+ MX: Mensagens recebidas: 160MMensagens recebidas (facebook): 7M Conexões barradas: 450M Spam detectados: 54M Frontend: Total de autenticações: 260M Média de usuários ativos (imap): 200k Média de usuários ativos (pop3): 20k Webmail: Conexões simutâneas: 100K

24 Monitoração

25 Relatórios de performance Estatísticas por cluster; Detecção de problemas; KPI's internas;

26 Mudanças na equipe ~ 1MM mailboxes/sysadmin Sysadmins programando em Python e Go Ciclos rápidos de correção de elementos da arquitetura Rápida adaptação a outras plataformas e OSs Sysadmins originais -> Gerentes e lideres técnicos Logs e métricas em todo lugar

27 Antes "Há 5 anos atrás, até 15 minutos não era considerado atraso" "Possuímos pessoas especializadas em olhar filas" "Não era possível uma análise mais completa por falta de logs" "Tinhamos o equivalente a pelo menos 1 crise por dia" "Estrema demora para o provisionamento de um novo servidor" "Precisamos migrar nosso serviço para o GMAIL"

28 Hoje "Se o não chega em 5 minutos temos clientes reclamando" "Fila hoje possui a prioridade máxima de incidentes" "Temos logs de tudo e os guardamos para sempre" "Temos crises esporádias, com visibilidade a rápida atuação" "Simples provisionamento de novos servidores" "Hoje estamos recebendo clientes que eram do GMAIL!"

29 Dúvidas?

Documentos relacionados

ChasqueMail e-mail da UFRGS

ChasqueMail e-mail da UFRGS Éverton Didoné Foscarini, Rui de Quadros Ribeiro {foscarini,rui.ribeiro}@cpd.ufrgs.br Apresentação Everton Foscarini Diretor Dep. Sustentação no CPD da UFRGS Sysadmin na UFRGS