Perguntas e respostas do ExchangeAumentos misteriosos do tamanho dos anexos, replicação de pastas públicas e muito mais

Henrik Walther

P A infra-estrutura do sistema de mensagens de nossa organização baseia-se no Exchange Server 2007. Temos um limite de tamanho de mensagens relativamente restrito, definido como 12 MB em toda a organização.

Temos observado um comportamento estranho, que parece ter relação com o tamanho dos arquivos anexados a uma mensagem. Quando se envia uma mensagem de email a um usuário externo com, digamos, um anexo de 11 MB, a mensagem é entregue ao destinatário como esperado. Mas se a mensagem (incluindo o anexo) for encaminhada de volta ao remetente na rede interna, este recebe uma notificação de falha na entrega (NDR), indicando que a mensagem é maior do que o atual limite do sistema ou que a caixa de correio do destinatário está cheia.

Após um exame detalhado do problema, vimos que, em algum ponto depois de a mensagem sair da organização, o tamanho dos anexos cresce aproximadamente 30%. A pergunta é: por que o tamanho dos anexos aumenta quando se envia e recebe mensagens de email pela Internet? E o mais importante: esse comportamento é esperado?

R Em poucas palavras, a resposta é sim. Geralmente, esse é o comportamento esperado, não só no Exchange Server 2007, mas também em todas as versões do Exchange Server, bem como em qualquer outro sistema de mensagens que tenha suporte a MIME (Multipurpose Internet Mail Extensions) e use Base64 para codificar os anexos. Quando um usuário interno do Exchange envia uma mensagem a um destinatário interno à organização do Exchange, a mensagem não requer nenhuma conversão de conteúdo. Isso significa que não haverá aumento no tamanho da mensagem nem dos anexos quando forem entregues. Por outro lado, as mensagens enviadas a destinatários externos talvez requeiram conversão de conteúdo.

Uma mensagem SMTP padrão (também conhecida como mensagem de texto sem formatação) consiste no envelope e no conteúdo da mensagem — o cabeçalho e o corpo da mensagem. Esses elementos são baseados em texto US-ASCII de 7 bits, sem formatação. Quando uma mensagem contém elementos que não são de texto US-ASCII sem formatação, eles precisam ser codificados. Para lidar com esse conteúdo que não é de texto, inclusive os anexos, a codificação é feita usando o MIME. Tanto o Exchange 2007 quanto as versões anteriores do Exchange Server usam o algoritmo de Base64 para codificar os anexos. E a desvantagem do padrão Base64 é que ele aumenta os anexos em 33%.

No Exchange 2007, exceto quando se usa o Outlook Web Access, a maior parte da conversão de conteúdo relativa a transporte é executada no servidor de Transporte de Hub. Para obter uma explicação detalhada, consulte o tópico "Compreendendo a conversão de conteúdo" em technet.microsoft.com/library/bb232174.

P Estamos no meio da transição do Exchange 2003 para o Exchange 2007. Mudamos todas as caixas de correio dos usuários para os servidores de caixa de correio do Exchange 2007, que foram todos configurados usando replicação contínua em cluster (CCR). No momento, estamos replicando todas as pastas públicas do servidor de pastas públicas do Exchange 2003 herdado para um servidor de caixa de correio baseado em CCR. Durante os testes, no entanto, descobrimos que, quando ocorre um failover com perdas no cluster CCR, o banco de dados de pastas públicas não é colocado online no outro nó. Também não conseguimos montá-lo manualmente após o failover.

Temos um ambiente de laboratório que espelha a infra-estrutura do Exchange 2007 no ambiente de produção, e os testes mostram que o problema também ocorre nele. Não vimos esse problema em nenhum dos bancos de dados de caixa de correio em nenhum dos clusters CCR em que ocorreu failover com perdas, de modo que o problema parece ter relação com os bancos de dados de pastas públicas em clusters CCR. Como queremos redundância real de todos os bancos de dados, inclusive o de pastas públicas, você tem alguma idéia do que poderia causar esse comportamento?

R No Exchange 2007, os métodos de replicação usados pelo CCR e pela replicação de pastas públicas são duas coisas muito diferentes. Por isso, não é recomendável combinar múltiplos bancos de dados de pastas públicas em uma organização do Exchange com servidores de caixas de correio baseados em CCR, caso os bancos de dados de pastas públicas estejam hospedados em um servidor de caixas de correio baseado em CCR. Você pode fazer isso durante a transição, e o grupo de produtos Exchange oferece suporte à existência de um banco de dados de pastas públicas hospedado em um servidor de caixas de correio baseado em CCR e, por exemplo, um servidor Exchange 2003 legado. Mas é altamente recomendável que você remova o banco de dados de pastas públicas do servidor de caixas de correio baseado em CCR depois que todos os dados das pastas públicas estiverem replicados.

A situação pela qual você está passando em seu ambiente de mensagens do Exchange é normal. Quando você tem múltiplos bancos de dados de pastas públicas e um deles está hospedado em um servidor de caixas de correio baseado em CCR, o banco de dados de pastas públicas nesse servidor não será colocado online durante um failover com perdas (isto é, uma interrupção não programada).

Na verdade, o banco de dados de pastas públicas só pode ser colocado online depois que o nó anteriormente ativo é ativado novamente. Além disso, todos os arquivos de log de transações do grupo de armazenamento em que está hospedado o banco de dados de pastas públicas devem estar disponíveis.

Se não houver essa opção, a primeira linha de defesa deve ser restaurar o armazenamento de pasta pública do último backup em boas condições, passar pelos logs disponíveis e propagar novamente o outro nó a partir do banco de dados restaurado. Como alternativa, o armazenamento de pasta pública pode ser criado do zero. Nesse caso, o nó ativo original deve ser recuperado e deve ser criado um novo banco de dados de pastas públicas, e os dados da pasta pública devem ser replicados a partir de outro servidor de pastas públicas da organização do Exchange.

O que talvez pareça estranho é que, quando é executada uma interrupção sem perdas (programada), o banco de dados de pastas públicas é colocado online. Esse é o comportamento esperado. Para obter mais informações, consulte "Replicação contínua de cluster e banco de dados de pasta pública", em "Planejando a replicação contínua em cluster".

P Todos os servidores de caixa de correio de nossa infra-estrutura de sistema de mensagens baseada no Exchange 2007 foram configurados usando CCR. Estamos muito satisfeitos com o funcionamento do CCR, mas esperamos que você possa responder a uma pergunta.

Na manutenção online executada todas as noites, uma das tarefas é a desfragmentação online. Como assegurar que os bancos de dados do nó passivo de um cluster CCR sejam desfragmentados durante a manutenção online?

R A tarefa de desfragmentação online, que exclui todos os itens marcados para remoção e transforma o espaço usado por eles em espaço em branco, gerará novos arquivos de log de transações durante o processo. Todos os arquivos de log de transações do nó CCR ativo serão replicados no nó passivo, fazendo com que as alterações realizadas nos bancos de dados também o sejam no nó passivo.

Com isso em mente, programe sua janela de manutenção online de modo que não entre em conflito com sua janela de backup, pois isso força a interrupção da desfragmentação online. Aliás, a desfragmentação não precisa necessariamente ser concluída todos os dias nem todas as semanas, nem mesmo todas as quinzenas. No passado, a orientação do grupo de produtos Exchange especificava que se devia fazer a desfragmentação completa pelo menos a cada quinzena. Mas isso mudou no Exchange Server 2007 SP1, já que o ambiente de cada organização é diferente. Para obter mais detalhes sobre essa nova orientação, veja a postagem no Blog da equipe do Microsoft Exchange.

P Estamos planejando usar o CCR do Exchange 2007 para conseguir redundância real de nossos servidores de caixas de correio. No momento, estamos analisando como o dumpster de transporte é usado em combinação com o CCR para garantir que, durante um failover com perdas, não haja perda de mensagens do nó CCR ativo para o nó passivo. Você conhece alguma armadilha no dumpster de transporte à qual devemos ficar atentos?

R Em um servidor de caixas de correio do Exchange 2007 que use CCR, o dumpster de transporte garante perda mínima de um nó para outro durante um failover com perdas. Isso é conseguido entregando-se novamente mensagens que tenham sido enviadas recentemente ao servidor de caixas de correio. Durante um failover com perdas, existe uma chance real de perder alguns arquivos de log de transações e, por isso, dados reais também podem ser perdidos. Como foi apontado, o dumpster de transporte entrega novamente as mensagens que foram enviadas recentemente ao servidor de caixas de correio e com isso garante que os dados perdidos durante o failover sejam restaurados. No entanto, como somente as mensagens são entregues via servidor de Transporte de Hub em que reside o dumpster de transporte, dados como tarefas e itens de calendário criados em um momento próximo ao failover com perdas serão perdidos.

P Estamos planejando uma migração entre florestas de uma organização do Exchange 2003 para uma do Exchange 2007, em uma nova floresta do Active Directory. Estudamos intensamente a documentação sobre migração entre florestas, "Como fazer a transição de uma topologia de floresta única para uma topologia entre florestas", que indica que se deve criar uma relação de confiança de floresta e não uma relação de confiança externa entre as florestas. Por que não pode ser usada uma relação de confiança externa?

R Embora a documentação do Exchange 2007 na TechNet diga que você deve usar uma relação de confiança de floresta em vez de uma relação de confiança externa, isso não significa que você não possa usá-la. Na verdade, uma relação de confiança externa funciona bem na migração do Exchange entre florestas, mas há uma desvantagem. Ao criar uma caixa de correio vinculada (ver Figura 1), você precisa especificar uma conta com as permissões adequadas para acessar o controlador de domínio da floresta confiável, pois não é possível usar as credenciais do usuário conectado, independentemente das permissões atribuídas a ele.

fig01.gif

Figura 1 Especificando uma conta na página da Conta Mestra durante a criação de uma caixa de correio vinculada

P Nossa organização acaba de fazer a migração para o Exchange 2007, e até agora estamos muito satisfeitos com a nova versão, com uma possível exceção. Quando usávamos o Exchange 2003 SP2, podíamos configurar nosso ambiente de modo que o nome simples para exibição da caixa de correio de um usuário era mostrado como remetente de uma mensagem de saída. Para nossa tristeza, não conseguimos encontrar um recurso similar no Exchange 2007. Não diga que esse recurso não existe no Exchange 2007!

R Esse recurso estava, de fato, ausente no Exchange 2007 RTM, até o pacote cumulativo de atualizações 4 (RU4) do Exchange 2007 SP1 ser lançado, em outubro de 2008. Com o RU4 do SP1, você pode novamente, como fazia no Exchange 2003 SP2, configurar o Exchange de modo a mostrar o nome simples para exibição nas mensagens de saída. Isso pode ser conseguido com o cmdlet Set-RemoteDomain do Windows PowerShell, com o parâmetro –UseSimpleDisplayName. Por exemplo, para habilitar os nomes simples para exibição em mensagens de saída enviadas ao domínio contoso.com, use o comando mostrado na Figura 2.

fig02.gif

Figura 2 Usando nomes simples para exibição em mensagens de saída

P Qual é a prática recomendada para desfragmentar as cópias de bancos de dados no nó passivo de servidor de caixas de correio baseado em CCR do Exchange 2007? O Exchange se confundirá se os bancos de dados em um dos nós no CCR forem desfragmentados, mas os do outro nó não forem?

R Se for necessária uma desfragmentação offline, ela sempre deverá ser executada no nó ativo do cluster CCR, nunca no nó passivo. Leve em consideração também que, se você fizer uma desfragmentação offline de um ou mais bancos de dados no nó ativo, será necessária uma nova propagação desses bancos de dados para o nó passivo.

Isso significa, por exemplo, que se você tem um banco de dados de 200 GB (ao replicar em uma rede de 1 GB e usando CCR, o tamanho recomendado do banco de dados é 200 GB), a desfragmentação levará várias horas (uma boa estimativa é 2 a 4 GB por hora). Mas, depois da conclusão do processo de desfragmentação, você também precisará replicar 200 GB de dados para o nó passivo. Se o envio do arquivo de log estiver sendo feito pela rede pública, isso poderá afetar o desempenho geral da rede para os usuários finais.

Na maioria dos casos, o motivo para realizar uma desfragmentação offline é remover todos os espaços em branco do banco de dados, para reduzir seu tamanho. Raramente isso é necessário, já que o espaço em branco será reutilizado antes que haja um crescimento no banco de dados. E isso realmente não importa quando você tem espaço disponível no banco de dados ou no disco, não é mesmo?

Caso você tenha muitos gigabytes de espaço em branco em um banco de dados e queira removê-los, é muito melhor levar todas as caixas de correio para um novo banco de dados.

Henrik Walther é Microsoft Certified Master: Exchange 2007 e MVP em Exchange com mais de 14 anos de experiência na atividade de TI. Ele trabalha como arquiteto de tecnologia para a Interprise Consulting (um Microsoft Gold Partner com base na Dinamarca) e como redator técnico da Biblioso Corporation (uma empresa com sede nos EUA, especializada em documentação gerenciada e serviços de localização).