20 Gb, apenas 20Gb e nada mais que 20Gb.
Se você ficou surpreso com a resposta seca e direta, então é hora de ler o artigo. Vou tentar explicar como cheguei a esse “número mágico”.
Toda mensagem é importante e desde que os grandes players do mercado criaram as “caixas infinitas” há a percepção de que ela é ilimitada e que não é mais necessário se preocupar com o seu tamanho, mas essa premissa não é correta.
Os sistemas de gerenciamento dos grandes players subdivide a “caixa infinita” em caixas menores para garantir sua integridade e isso é feito de maneira imperceptível para o usuário. Pelo menos esse é o meu palpite porque não temos acessos detalhados às tecnologias que eles utilizam.
O fato é que caixas postais grandes degradam o sistema e deixam o ambiente lento e propenso a falhas graves. O armazenamento de mensagens é feito utilizando índices de posicionamento e bases de dados que se tornam mais propensos a falhas à medida que crescem. Assim, quanto maior uma caixa postal maior o risco de corrupção das tabelas de índices e, portanto, de haver perda de dados.
É importante entender que perder os índices implica, na maioria dos casos, perder a caixa postal completa e não apenas algumas mensagens. Assim começa a ficar claro o tamanho do risco envolvido.
Quando as mensagens são armazenadas localmente em clientes de e-mail são utilizados arquivos PST e similares que são, na verdade, bancos de dados locais. Gerenciar arquivos de dados com 30, 40, 100Gb de tamanho exige muito do computador.
Quando as mensagens são armazenadas no servidor e acessadas via IMAP ou webmail elas são organizadas utilizando tecnologias próprias e que diferem entre os Softwares de servidores de e-mail disponíveis no mercado.
O Zimbra utiliza uma base de dados MySQL para manter o caminho de armazenamento do arquivo da mensagem no disco. Além disso é armazenada na base MySQL o assunto e a parte inicial da mensagem. O objetivo é utilizar essas informações para “montar” a tela inicial do usuário sem precisar ler as mensagens diretamente do disco. O acesso à base de dados é centenas de vezes mais rápido do que o acesso ao disco, evitando assim, sobrecarga de I/O no disco e tornando o ambiente todo mais rápido e eficiente.
Sempre que a caixa postal é acessada às mensagens da INBOX são indexadas e apresentadas ao cliente, significando, no caso do Zimbra, uma consulta na base de dados MySQL. Quanto mais mensagens na INBOX mais carga sobre o servidor e mais lentidão. Dica de ouro: estimule seus usuários a manter uma caixa de entrada minimalista.
Em uma matéria publicada em 2005 no blog Techno Community da Microsoft eles falam sobre o tamanho recomendado de uma caixa de e-mail. Depois de várias explicações eles sugerem que as caixas não devem ter mais de 5000 mensagens para poder garantir sua integridade geral. É curioso que eles foquem na quantidade de mensagens e não no tamanho da caixa como um todo, mas faz sentido: o que importa mesmo é a quantidade de itens nos índices e isso não tem haver com o tamanho das mensagens.
Segue o link para quem quiser ler o tal artigo: Recommended Mailbox Size Limits
Apesar do artigo ser de 2005 os seus princípios não mudaram: quanto mais mensagens, maiores os índices e portanto mais carga no servidor ao entregar as mensagens aos clientes. Se por um lado os computadores e discos melhoraram de desempenho, por outro lado o aumento no uso do IMAP e de usuários de Webmail forçam o sistema. Por isso as premissas do artigo da Microsoft são válidas até hoje.
É muito importante configurar o Zimbra para o “index” dos volumes em um disco de alto desempenho. Mas cuidar do tamanho das caixas postais é essencial, assim como educar os usuários a manter suas pastas INBOX com poucas mensagens.
Tendo em mente essa quantidade máxima de 5000 mensagens podemos dizer com segurança que uma caixa postal de 20Gb de tamanho armazenará muito mais do que isso, permitindo assim uma folga na quantidade de mensagens que um usuário pode manter sem correr maiores riscos. O ajuste de quantidade para tamanho se baseia na facilidade de entendimento do usuário e de controle por parte dos administradores do serviço de e-mail.
Apesar da orientação e das boas práticas, muitas vezes nos deparamos com situações onde a quantidade de mensagens que precisam ser armazenadas é uma condição obrigatória. Caixas postais corporativas que são compartilhadas por muitos usuários, como “vendas”, “financeiro” ou “contato”, caixas postais de tribunais e juízes ou de departamentos jurídicos das organizações, são bons exemplos.
Essas caixas costumam armazenar muito conteúdo por prazos de tempo muito longos para permitir que acordos legais e/ou comerciais possam ser resgatados ao longo do tempo quando necessário.
Entende-se o motivo pelo qual essa caixas postais terminam sendo usadas como arquivo de mensagens antigas ao mesmo tempo que continuam em produção, sendo utilizadas cotidianamente. Mas essa é a receita para um desastre anunciado: haverá corrupção de dados e perdas que poderão ser irrecuperáveis. Como diz o ditado, não é “se”, mas “quando” isso vai acontecer.
Há outros três momentos críticos em que as caixas postais grandes costumam sofrer perdas irreparáveis: queda súbita de energia, restauração de backup e migrações.
Quando acontece uma interrupção súbita de energia todos os índices que estava em memória são perdidos e precisam ser gerados do zero quando o sistema é inicializado. As caixas postais grandes tem índices maiores e portanto mais propensas a corrupção permanente, o que significa que não será mais possível ler a caixa postal. É possível fazer uma recuperação forense das mensagens mas trata-se de um processo altamente especializado, demorado, caro e com resultados imperfeitos.
O processo de restauração de backup é similar ao processo de migração: faz-se o “dump” das caixas postais para restauração local no caso do backup, ou para restauração no novo servidor no caso da migração. O “dump” resulta em um arquivo compactado que tem todo conteúdo da caixa, como mensagens, contatos, compromissos… e quanto maior a caixa, maior é o arquivo resultante. Em geral não há problemas para fazer o backup ou “dump”, mas sim no momento de restaurá-lo.
Importar um arquivo de 5, 10 ou 20Gb é um procedimento corriqueiro, mas fazer o mesmo com um arquivo de 80 ou 100Gb tem implicações graves sobre o desempenho do servidor, impacto sobre a base de dados e tempo de escrita em disco. Na prática o que acontece é a leitura e descompactação desse arquivo pelo Zimbra que depois vai importar cada registro, mensagem, compromisso via SOAP. Quanto maior a caixa postal, maior o risco do processo ser abortado durante a importação por erros de leitura, timeout e/ou esgotamento de memória. O resultado é uma restauração parcial apenas da parte que se conseguiu ler antes do erro.
O hardware envolvido, a carga geral do sistema, o tamanho da caixa e o desempenho do disco contarão como variáveis que poderão influenciar no sucesso ou não da importação de caixas postais grandes, seja para restauração de backup, seja para migrações.
Sabendo de tudo isso qual é a forma sugerida de se lidar com caixas postais grandes? Dividi-las em caixas de até 20Gb compartilhando-as com a caixa principal através do recurso de compartilhamento de caixas postais do Zimbra. Uma ideia é criar caixas postais auxiliares com nomes contendo anos, assim:
[email protected] = 20Gb
[email protected] = 20Gb
[email protected] = 20Gb
[email protected] = 20Gb
[email protected] = 20GbAs contas com “_ANO” são compartilhadas com a conta principal, ficando disponíveis de forma fácil pois aparecem no cliente de e-mail como uma pasta extra. Fica evidente que a ideia é separar as mensagens por ano de envio.
Dessa forma o conteúdo fica disponível, porém armazenado em caixas postais menores de fácil mobilidade, reindexação e restauração em caso de necessidade.
Existe um zimlet administrativo feito pelo Barry de Graaf que implementa o compartilhamento de caixas via interface administrativa: Zimbra Shared Mailbox Toolkit
Esperamos que este conteúdo ajude administradores de servidores de e-mail e usuários a chegarem a um consenso no uso racional dos recursos computacionais, para melhorar o desempenho geral do ambiente, garantir integridade e portanto evitar perdas de dados importantes.
Quem sabe em um futuro o limite seguro do tamanho de caixas aumenta. Ainda me lembro da época em que a recomendação era de no máximo 10Mb… sim Megas =)
Saudações Livres!
