Estrutura de armazenamento dos servidores de transporte

Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Tópico modificado em: 2009-01-26

Os servidores de Transporte de Borda e de Transporte de Hub são as funções de servidor responsáveis por:

• Entrada e saída de emails da organização.

• Entrada e saída de emails dos servidores de Caixas de Correio.

• Mensagens de voz enviadas por servidores de Unificação de Mensagens.

Para garantir a eficácia da entrega e do fluxo de mensagens em toda a sua organização do Exchange, os servidores de Transporte de Borda e de Transporte de Hub devem ter uma solução de armazenamento estruturada corretamente.

Este tópico contém informações e exemplos para ajudá-lo a determinar os requisitos de E/S (entrada e saída) e capacidade dos servidores de Transporte de Borda e Transporte de Hub.

Requisitos de E/S e Capacidade do Servidor de Transporte de Borda

Os servidores de Transporte de Borda devem ser estruturados de forma a atender aos requisitos de E/S transacional e capacidade de cada organização. É fundamental manter o crescimento correto das filas e rotear emails o mais rápido possível, de forma que os SLAs (acordos de nível de serviço) não sejam prejudicados. Há diversos fatores que afetam a capacidade geral de um servidor de Transporte de Borda:

• Logs de controle de mensagens

• Logs do protocolo

• Banco de dados de email

• Logs de conectividade

• Logs do agente

Deve haver no mínimo 500 MB (megabytes) de espaço livre e de espaço de banco de dados livre na unidade que contém o banco de dados da fila de mensagens; caso contrário, o sistema de transporte ativará a pressão de retorno, que é a capacidade de monitorar recursos do sistema do serviço de transporte do Microsoft Exchange Server 2007.

O valor padrão da pressão de retorno é controlado pelo parâmetro PercentageDatabaseDiskSpaceUsedHighThreshold, que pode ser modificado quando necessário. Para obter mais informações sobre a pressão de retorno e as opções para configurá-la, consulte Compreendendo a pressão de retorno.

Se os logs de controle de mensagens forem habilitados, será necessária capacidade adicional. Os requisitos de capacidade para o controle de mensagens dependem do número de mensagens recebidas pelo servidor de transporte. Se sua organização utiliza o Microsoft Exchange Server 2003, você pode determinar a atual taxa de geração de logs e definir um limite fixo de dias para manter os dados (por exemplo, dez dias). O Microsoft gera 220  MB de logs de controle de mensagens todos os dias úteis (exceto fins de semana) e garante que haja capacidade suficiente para uma semana de logs (cerca de 1,3  GB). O tamanho dos logs do protocolo, de conectividade e do agente depende da atividade. Como ponto de referência, os servidores de transporte em Microsoft geram:

• De 5 a 15  GB de logs do protocolo por dia nos servidores de Transporte de Borda. Garantia de capacidade suficiente para a cota do log do protocolo, que é 15 GB.

• 100 MB de logs de conectividade por dia nos servidores de Transporte de Borda. Garantia de capacidade suficiente para uma semana de logs, que é aproximadamente 600 GB.

• 250 MB de logs do agente por dia nos servidores de Transporte de Borda. Garantia de capacidade suficiente para uma semana de logs, que é aproximadamente 1,5 GB.

Os logs de transações não exigem muita capacidade de disco, porque a criação de log normal é limitada pelo uso de log circular. Como resultado, os logs de transações podem ser incluídos no número LUN (número de unidade lógica) que contém o sistema operacional. O Microsoft usa um espelho de dois discos para esse LUN.

O banco de dados (mail.que) não armazena itens indefinidamente, e a capacidade reservada deve ser o tamanho médio de mensagem multiplicado pela fila máxima, caso a fila tenha atingido seu máximo e o servidor esteja desligado. Uma fila de 500.000 itens com um tamanho médio de mensagem de 50 KB equivale a cerca de 25 GB de dados no banco de dados.

Os servidores de Transporte de Borda que executam verificações de antivírus em mensagens recebidas precisam de espaço suficiente para a quarentena do antivírus. Os requisitos do recurso de E/S de disco dependem da porcentagem (normalmente baixa) de mensagens recebidas que estão infectadas por vírus. A quantidade de mensagens e anexos infectados e o tempo que eles permanecem em quarentena definem o volume de espaço necessário à quarentena. Um GB de espaço em disco é um bom ponto de partida, embora cada organização tenha suas próprias necessidades.

Para a maioria das implantações do servidor de Transporte de Borda, é recomendável adicionar um fator extra de 20% ao tamanho do banco de dados (depois de todos os outros fatores terem sido considerados). Esse valor corresponderá às estruturas internas do banco de dados e garantirá espaço adequado, caso ocorra algum aumento ou alteração no fluxo de emails que resulte no crescimento do banco de dados.

Exemplo de capacidade de um servidor de Transporte de Borda

Neste exemplo, os logs de transações são armazenados na partição do sistema operacional (C:), que é hospedada por um controlador RAID (matriz redundante de discos independentes) de cache e alimentado por bateria. Os requisitos de capacidade são pequenos (no intervalo de vários megabytes).

O processo para determinar a capacidade de um servidor de Transporte de Borda tem duas etapas. Primeiro, calcule o tamanho do banco de dados e, em seguida, determine o tamanho do log de transações.

Etapa 1: Tamanho do banco de dados

Considere um servidor de Transporte de Borda que receba uma média de cinco mensagens por segundo (com um tamanho médio de 50 KB) por um período de 24 horas e uma fila máxima de 500.000 itens. Depois de todos os outros fatores, 20% adicionais são incluídos, e o tamanho total do disco passa a ser de 58 GB, como mostra a tabela a seguir.

Tamanho do banco de dados

Etapa 2: Tamanho do log de transações

Para determinar o tamanho do log de transações, considere E/S transacional, outras E/S de disco e E/S do banco de dados por segundo (IOPS) por mensagem.

E/S transacional

Se o servidor tiver memória suficiente, as mensagens recebidas serão armazenadas em memória RAM e no log de transações, o que minimiza o impacto no disco. Quando não há recursos de memória suficientes, somente os primeiros 128 KB da mensagem são armazenados na memória e no log de transações. O restante da mensagem é armazenado no banco de dados. Durante a conversão de conteúdo, os dados são transmitidos para um local temporário para o processamento. Este local temporário é especificado pela configuração TemporaryStoragePath no arquivo EdgeTransport.exe.config. Por padrão, o valor TemporaryStoragePath é definido como "C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Temp."

É importante colocar o diretório temporário no mesmo LUN do banco de dados. É igualmente importante definir o cache do controlador de armazenamento como 50% de leitura e 50% de gravação. Quando não houver uma fila em expansão, algumas operações de E/S do disco serão operações de leitura. Se houver alguma fila, a mensagem talvez não esteja no cache do banco de dados, o que exige mais E/S do disco.

Outras E/Ss de disco

Além da E/S transacional, pode haver outras E/Ss de disco no sistema. Por exemplo:

• A habilitação do controle de mensagens requer uma sobrecarga adicional de 2% a 5% na E/S do disco.

• A habilitação dos logs do protocolo e de conectividade gera uma pequena sobrecarga na E/S do disco que depende do volume de mensagens recebidas.

• A habilitação dos logs do agente padrão gera uma pequena sobrecarga adicional na E/S do disco, embora, se houver agentes personalizados em uso, mais recursos de disco serão necessários.

• As operações de anti-spam e antivírus ocorrem na memória, o que demanda mais recursos da CPU.

Teste os servidores de Transporte de Borda com todos os serviços em execução durante o teste a ser usado na produção.

IOPS do banco de dados por mensagem

Durante o teste interno no Microsoft, foi usado um tamanho médio de mensagem de 60 KB. Muitas organizações dimensionam seus servidores de transporte com uma taxa de mensagens específica; por exemplo, 20 mensagens por segundo. Essa taxa de mensagem exigiria 140 (20 × (4,5 + 2,5)) E/Ss de banco de dados e 220 (20 × 11) E/Ss de log.

Quando uma fila se forma, mais leituras são necessárias, particularmente no caso de RAID-1/0, porque todo disco físico responde às solicitações de leitura, como indica a tabela a seguir.

IOPS do banco de dados por mensagem

Aplicando diretrizes de dimensionamento à sua estrutura de hardware para um servidor de Transporte de Borda

Depois que tiver seus requisitos de capacidade e E/S transacional para um servidor de Transporte de Borda, você poderá aplicá-los à estrutura de hardware proposta. Para as configurações de processador e memória, consulte Planejando Configurações do Processador e Planejando Configurações de Memória. Durante a elaboração de um servidor de Transporte de Borda, é importante haver memória RAM suficiente (cada mensagem precisa de 8 ou 9 KB de memória) no sistema para evitar o cache temporário de corpos de mensagens em fila no disco.

Um servidor de Transporte de Borda usa um banco de dados ESE (Extensible Storage Engine). Para garantir resiliência e bom desempenho, é aconselhável separar os arquivos de log e de banco de dados em seus próprios discos físicos em ambientes nos quais haja uma fila grande. Em implementações menores com requisitos mais baixos de E/S de disco, pode ser viável colocar os logs de transações e o banco de dados no mesmo LUN. O servidor de Transporte de Borda, como o servidor de Caixas de Correio, requer tempos de resposta de E/S inferiores a 20 milissegundos.

É importante usar controladores RAID de cache e alimentados por bateria, e realizar a manutenção do banco de dados toda noite. Verifique também se o tipo de disco escolhido garantirá o equilíbrio certo de capacidade e desempenho.

Exemplo de dimensionamento de estrutura de hardware para um servidor de Transporte de Borda

Este exemplo ilustra como estruturar seu armazenamento em função das mensagens esperadas por segundo. Neste exemplo, há um servidor de Transporte de Log que administra 20 mensagens por segundo, o que requer 140 IOPS para o LUN do banco de dados e 220 IOPS para o LUN do log. Sempre acrescente um fator de crescimento de 20% para o desempenho de E/S do disco para os dias mais movimentados. O layout do disco é RAID10. Para obter os resultados de dimensionamento do hardware, consulte a tabela a seguir.

Dimensionamento do hardware

Este exemplo tem um requisito de capacidade de LUN do banco de dados de cerca de 70 GB para uma semana de dados. Dobre o requisito de capacidade para 140 GB se precisar de duas semanas de dados. A utilização de discos físicos de 146 GB permite um LUN de 292 GB em uma configuração RAID10.

Requisitos de E/S e capacidade do servidor de Transporte de Hub

Os servidores de Transporte de Hub também devem ser estruturados de forma a atender aos requisitos de E/S transacional e de capacidade da organização. Assim como o servidor de Transporte de Borda, deve haver espaço livre no banco de dados e um mínimo de 500 MB de espaço livre na unidade de disco que contém o banco de dados de filas de mensagens; caso contrário, o sistema de transporte ativará a pressão de retorno. Você pode modificar o valor padrão do parâmetro PercentageDatabaseDiskSpaceUsedHighThreshold nos servidores de Transporte de Hub.

A capacidade para o log de controle de mensagens depende do número de mensagens recebidas pelo servidor de transporte. Se, no momento, sua organização utiliza o Exchange 2003, você pode determinar a atual taxa de geração de logs e definir um limite fixo de dias para manter os dados (por exemplo, dez dias). O Microsoft gera 700 MB de logs de controle de mensagens todos os dias úteis (exceto nos fins de semana) nos servidores de Transporte de Hub e garante que haja capacidade suficiente para uma semana de logs (cerca de 4,5 GB).

O tamanho dos logs do protocolo variam de acordo com a atividade. O Microsoft gera 2,7 GB de logs do protocolo por dia nos servidores de Transporte de Hub, e garante que haja capacidade suficiente para uma semana de logs, o que é cerca de 16 GB.

Os logs de transações não exigem muita capacidade de disco, porque a criação de log normal é limitada pelo uso de log circular. Como resultado, os logs de transações podem ser incluídos no LUN do sistema operacional. O Microsoft usa um espelho de dois discos para esse LUN.

O banco de dados (mail.que) não armazena itens indefinidamente, e a capacidade reservada deve ser o tamanho médio de mensagem multiplicado pela fila máxima, caso a fila tenha atingido seu máximo e o servidor esteja desligado. Uma fila de 500.000 itens com um tamanho médio de mensagem de 50 KB equivale a cerca de 25 GB de dados no banco de dados.

Para a maioria das implantações do servidor de Transporte de Hub, é recomendável adicionar um fator de sobrecarga adicional de 20% ao tamanho do banco de dados depois de todos os outros fatores terem sido considerados.

Dumpster de Transporte

É necessária consideração especial com os servidores de Transporte de Hub em sites que contêm:

• Servidores de caixas de correio clusterizadas implantados em um ambiente de CCR (replicação contínua em cluster) que usa o Exchange Server 2007 RTM ou o Exchange 2007 SP1.

• Os servidores de caixas de correio que executam o Exchange 2007 (SP1) com um ou mais grupos de armazenamento habilitados para LCR.

Ao implantar algum dos ambientes anteriores, verifique se você estruturou seu servidor de Transporte de Hub com capacidade suficiente para armazenar mensagens com tamanho adequado aos grupos de armazenamento deste site, de forma que as mensagens possam ser recuperadas caso ocorra alguma paralisação inesperada do nó ativo. Esse recurso é conhecido como dumpster de transporte.

A sobrecarga de E/S do dumpster de transporte é semelhante à do crescimento de filas. Dois parâmetros podem ser usados para controlar o tempo de permanência de uma mensagem no dumpster de transporte: MaxDumpsterSizePerStorageGroup e MaxDumpsterTime. O valor padrão para MaxDumpsterSizePerStorageGroup é 18 MB. Para dimensionar o dumpster de transporte corretamente para o seu ambiente, aumente em 50% o maior tamanho aceitável para mensagens. Por exemplo, se a cota de mensagem for 10 MB, convém definir MaxDumpsterSizePerStorageGroup como 15 MB. Se houver mais de um servidor de Transporte de Hub no mesmo site do serviço de diretório do Active Directory do servidor de caixas de correio clusterizadas no ambiente CCR ou em um ambiente LCR que execute o Exchange 2007 SP1, o armazenamento agregado para os grupos de armazenamento desse servidor de caixas de correio clusterizadas abrangerá todos os servidores de Transporte de Hub. Por exemplo, se você tem quatro servidores de Transporte de Hub com um dumpster de transporte de 15 MB, esse grupo de armazenamento terá um dumpster de transporte de 60 MB.

Para organizações com limites de tamanho de mensagem, é recomendável definir MaxDumpsterSizePerStorageGroup com um valor que seja 1,5 vezes o tamanho médio das mensagens enviadas dentro da organização. Além disso, se não for definido um tamanho máximo de mensagem, você não poderá garantir a recuperação da mensagem após um failover não agendado em um ambiente CCR ou após a ativação de uma cópia passiva em um ambiente LCR que execute o Exchange 2007 SP1.

É recomendável definir MaxDumpsterTime como 7 dias, que é o valor padrão.

A capacidade consumida pelo dumpster de transporte deve ser o número de grupos de armazenamento multiplicado pelo tamanho máximo do dumpster de transporte. Se o tamanho máximo do dumpster de transporte for 15 MB, e o servidor de Transporte de Hub atender 100 grupos de armazenamento em um ambiente LCR (Exchange 2007 SP1) ou CCR (Exchange 2007 RTM ), devem ser alocados 1,5 GB para o dumpster de transporte.

Exemplo de dimensionamento de dumpster de transporte

Neste exemplo, os logs de transações estão no disco que contém a partição do sistema operacional (C:), que é hospedada por um controlador RAID de cache e alimentado por bateria. Os requisitos de capacidade serão pequenos (no intervalo de megabytes). Para obter os resultados de dimensionamento, consulte as tabelas a seguir.

O processo de determinar a capacidade necessária para o recurso de dumpster de transporte tem duas etapas. Primeiro, calcule o tamanho do banco de dados e, em seguida, determine o tamanho do log de transações.

Etapa 1: Tamanho do banco de dados

Considere um servidor de Transporte de Hub que receba uma média de cinco mensagens por segundo durante um período de 24 horas, com uma fila máxima de 500.000 itens.

Dimensionamento do dumpster de transporte

Etapa 2: Tamanho do log de transações

Para determinar o tamanho do log de transações, considere E/S transacional, outras E/Ss de disco e IOPS do banco de dados por mensagem.

E/S transacional

A mesma orientação sobre E/S transacional indicada acima para servidores de Transporte de Borda se aplica aos servidores de Transporte de Hub. Como mencionado anteriormente, é especialmente importante definir as configurações de cache no seu controlador de armazenamento da seguinte maneira: 50% de leitura, 50% de gravação.

E/S de dumpster de transporte

Quando o dumpster de transporte é habilitado, a E/S de disco aumenta. Embora as gravações no banco de dados aumentem, as leituras também ocorrem, o que nos servidores de produção do Microsoft representa aproximadamente três leituras por mensagem.

Outras E/Ss de disco

A mesma orientação sobre E/S de disco indicada anteriormente para servidores de Transporte de Borda se aplica aos servidores de Transporte de Hub. É fundamental testar os servidores de Transporte de Hub com todos os serviços em execução durante o teste a ser usado na produção.

IOPS do banco de dados por mensagem

Em testes internos no Microsoft, com um tamanho médio de mensagem de 40 KB, a habilitação do dumpster de transporte requer mais recursos de disco no servidor de Transporte de Hub. Muitas empresas dimensionam seus servidores de transporte com uma taxa de mensagens específica; por exemplo, 20 mensagens por segundo. Se o dumpster de transporte estiver habilitado, serão necessárias 200 E/Ss do banco de dados (20 × (7 + 3)) e 140 E/Ss de log (20 × 7) para atender a uma taxa de 20 mensagens recebidas por segundo. Com o dumpster de transporte desabilitado, serão necessárias 40 E/Ss do banco de dados (20 × 2) e 40 E/Ss de log (20 × 2) para atender a uma taxa de 20 mensagens recebidas por segundo.

Quando uma fila se forma, mais leituras são necessárias, principalmente no caso de RAID10, pois todo disco físico responde às solicitações de leitura. Para obter mais informações, consulte a tabela a seguir.

Dimensionamento do log de transações

Aplicando diretrizes de dimensionamento à sua estrutura de hardware para um servidor de Transporte de Hub

Depois que tiver seus requisitos de capacidade e E/S transacional para um servidor de Transporte de Hub, você poderá aplicá-los à estrutura de hardware proposta. Para as configurações de processador e memória dos servidores de Transporte de Hub, consulte Planejando Configurações do Processador e Planejando Configurações de Memória. Durante a elaboração de um servidor de Transporte de Hub, é importante que haja memória RAM suficiente (cada mensagem precisa de 8 ou 9 KB de memória) no sistema para evitar o cache temporário de corpos de mensagens em fila no disco.

Um servidor de Transporte de Hub usa um banco de dados ESE. Para garantir bom desempenho, é importante separar os arquivos de log e os arquivos de banco de dados em seus próprios discos físicos em ambientes nos quais haja uma fila grande ou quando o dumpster de transporte for utilizado. Para implantações menores com requisitos mais baixos de E/S de disco, pode ser viável colocar os logs de transações e o banco de dados no mesmo LUN. O servidor de Transporte de Hub, como o servidor de Transporte de Borda, requer tempos de resposta de E/S inferiores a 20 milissegundos.

Exemplos de dimensionamento de estrutura de hardware para servidor de Transporte de Hub

É importante estruturar seu armazenamento em função das mensagens esperadas por segundo. Neste exemplo, um servidor de Transporte de Hub administra 20 mensagens por segundo com o dumpster de transporte desabilitado, o que requer 40 IOPS para o LUN do banco de dados e 40 IOPS para o LUN do log. Sempre acrescente um fator de crescimento de 20% para o desempenho de E/S do disco para os dias mais movimentados. O layout de disco seria RAID1. Este exemplo tem um requisito de capacidade de LUN do banco de dados de cerca de 55 GB para uma semana de dados. Dobre o requisito de capacidade para 110 GB se precisar de duas semanas de dados. A utilização de discos físicos de 140 GB garante um LUN de banco de dados de 140 GB em uma configuração RAID1 e um LUN de log de 140 GB em uma configuração RAID1. Para verificar os resultados, consulte a tabela a seguir.

Dimensionamento de hardware para um servidor de Transporte de Hub para administrar 20 mensagens por segundo com o dumpster de transporte desabilitado

Neste exemplo, há um servidor de Transporte de Hub com o dumpster de transporte habilitado para administrar 20 mensagens por segundo. Essa configuração requer 200 IOPS para o LUN do banco de dados e 140 IOPS para o LUN do log, além dos 20% de fator de crescimento extra. O layout do disco é RAID10. Este exemplo tem um requisito de capacidade de LUN do banco de dados de aproximadamente 55 GB para uma semana de dados, ou 110 GB se houver necessidade de duas semanas de dados. A utilização de discos físicos de 140 GB garante um LUN do banco de dados de 280 GB em uma configuração RAID10 e um LUN do log de 140 GB em uma configuração RAID1.

Dimensionamento de hardware para um servidor de Transporte de Hub para administrar 20 mensagens por segundo com o dumpster de transporte habilitado