Estrutura do Armazenamento do Servidor de Caixa de Correio

 

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

Tópico modificado em: 2009-04-03

Ter capacidade suficiente é essencial. Quando um disco de banco de dados ficar sem espaço, o banco de dados ficará offline. Quando um disco de log de transações ficar sem espaço, ele fará com que todos os bancos de dados nesse grupo de armazenamento fiquem offline. A configuração de espaço adicional é muitas vezes difícil de ser feita rapidamente e executar a compactação offline para recuperar espaço pode levar muito tempo. Na maior parte dos casos, ficar sem espaço em disco resulta em uma interrupção de disponibilidade de um ou mais bancos de dados por um período de tempo que geralmente excede a maior parte dos RTOs (objetivos de tempo de recuperação).

Este tópico fornece as seguintes informações:

• Calculadora de armazenamento de caixas de correio do Exchange 2007

• Capacidade do LUN do banco de dados

• Capacidade do LUN de log

• E/S transacional

• Previsão do IOPS da linha de base do Exchange 2007

• E/S não transacional

• LUNs e discos físicos

• Impacto da replicação contínua no projeto de armazenamento

Calculadora de armazenamento de caixas de correio do Exchange 2007

A Exchange Server 2007 Calculadora de Requisitos de Armazenamento da Função de Servidor Caixas de Correio (calculadora de armazenamento) permite determinar os requisitos de armazenamento (desempenho e capacidade de E/S) e um layout de LUN (número de unidade lógica) ideal, com base em um conjunto de fatores de entrada. Vários fatores de entrada precisam ser considerados antes de se projetar uma solução de armazenamento ideal para um servidor Caixa de Correio do Exchange 2007. Esses fatores de entrada são discutidos posteriormente neste tópico.

A calculadora de armazenamento permite entrar valores específicos à sua organização e fornece recomendações para os requisitos de E/S, os requisitos de capacidade e o layout LUN ideal.

Para obter mais informações sobre a calculadora de armazenamento, incluindo detalhes sobre como usá-la, consulte Exchange 2007 Mailbox Server Role Storage Requirements Calculator (onde você também pode fazer download da calculadora) no blog Equipe do Exchange.

Capacidade do LUN do banco de dados

Vários pontos de dados que serão usados para determinar como dimensionar um LUN de banco de dados. Além disso, há outros fatores a serem considerados. Depois que todos os fatores tiverem sido considerados e calculados, recomendamos que você inclua um fator de sobrecarga adicional para o LUN do banco de dados de 20 por cento. Esse valor considerará os outros dados que residem no banco de dados que não são necessariamente vistos durante o cálculo dos tamanhos da caixa de correio e o espaço em branco. Por exemplo, a estrutura de dados (tabelas, exibições e índices internos) no banco de dados contribui para o tamanho geral do banco de dados. Por exemplo, se depois de ler as seguintes subseções você determinar que precisa de 120 GB, recomendamos que configure 144 GB, representando uma sobrecarga de segurança de 20% para esse LUN de banco de dados do grupo de armazenamento.

Cota de caixa de correio

A primeira métrica a ser compreendida é o tamanho da caixa de correio. Saber a quantidade de dados que um usuário final tem permissão de armazenar em sua caixa de correio permite que você determine quantos usuários podem ser hospedados no servidor. Embora os tamanhos de caixa de correio e cotas finais possam mudar, ter um objetivo em mente é a primeira etapa na determinação de sua capacidade necessária. Por exemplo, se você tiver 5.000 usuários em um servidor com uma cota de caixa de correio de 250 MB, precisará de, pelo menos, 1,25 terabytes (TB) de espaço em disco. Se um limite fixo não for definido nas cotas de caixa de correio, será difícil estimar de quanta capacidade você precisará.

Espaço em branco do banco de dados

O tamanho do banco de dados no disco físico não é simplesmente o número de usuários multiplicado pela cota de usuário. Quando a maioria dos usuários não estiver próxima de sua cota de caixa de correio, os bancos de dados consomem menos espaço, e espaço em branco não é um problema de capacidade. O próprio banco de dados sempre terá páginas livres, ou espaço em branco, distribuídos em seu interior. Durante a manutenção online, itens marcados para remoção do banco de dados são removidos, liberando essas páginas. A porcentagem de espaço em branco está em constante alteração, tendo a maior porcentagem imediatamente após a manutenção online e a menor logo antes da manutenção online.

O tamanho do espaço em branco do banco de dados pode ser aproximado pela quantidade de email enviada e recebida pelos usuários com caixas de correio no banco de dados. Por exemplo, se você tiver cem caixas de correio de 2 GB (total de 200 GB) em um banco de dados cujos usuários enviam e recebem uma média de 10 MB de email por dia, o espaço em branco será de aproximadamente 1 GB (100 * 10 MB por caixa de correio).

O espaço em branco pode crescer além dessa aproximação se a manutenção online não puder concluir uma passagem completa. É importante que as atividades operacionais tenham tempo suficiente para manutenção online a ser executada toda noite, para que uma passagem completa possa ser concluída em uma semana ou menos.

Dumpster do banco de dados

Cada banco de dados tem um dumpster que armazena itens excluídos temporariamente. Por padrão, os itens são armazenados por 14 dias no Microsoft Exchange Server 2007. Isso inclui itens que foram removidos da pasta Itens Excluídos. Por padrão, comparando-se com o Exchange Server 2003, o Exchange 2007 aumenta a sobrecarga consumida pelo dumpster de banco de dados porque os itens excluídos são agora armazenados pelo dobro do tempo. A quantidade real no dumpster dependerá do tamanho de cada item e das configurações de retenção específicas da sua organização.

Depois que o período de retenção tiver passado, esses itens serão removidos do banco de dados durante um ciclo de manutenção online. Conseqüentemente, um estado regular será atingido onde seu tamanho de dumpster será equivalente a duas semanas de mensagens de entrada/saída, como uma porcentagem de seu tamanho de banco de dados. A porcentagem exata depende da quantidade de emails excluídos e dos tamanhos de caixas de correio individuais.

O dumpster acrescenta uma porcentagem de sobrecarga ao banco de dados dependendo do tamanho da caixa de correio e da taxa de entrega de mensagem para essa caixa de correio. Por exemplo, com uma taxa de entrega de mensagem constante de 52 MB por semana, uma caixa de correio de 250 MB de perfil muito pesado armazenaria aproximadamente 104 MB no dumpster, acrescentando uma sobrecarga de 41%. Uma caixa de correio de 1 GB armazenando os mesmos 104 MB no dumpster acrescentaria 10 por cento de sobrecarga.

Tamanho real da caixa de correio

Com o tempo, as caixas de correio do usuário atingirão a cota da caixa de correio, de modo que uma quantidade de email equivalente às mensagens de entrada precisará ser excluída para permanecer abaixo da cota de caixa de correio. Isso significa que o dumpster aumentará até o tamanho máximo equivalente a duas semanas de mensagens de entrada/saída. Se a maioria dos usuários não tiver atingido a cota de caixa de correio, apenas parte das mensagens de entrada/saída será excluída, por isso o crescimento será dividido entre o dumpster e o aumento no tamanho de caixa de correio. Por exemplo, uma caixa de correio com perfil de mensagem muito pesado de 250 MB que recebe 52 MB de mensagens por semana (com mensagens com tamanho médio de 50KB) consumirá também 104 MB no dumpster (41%) e 7,3 MB em espaço em branco, de uma caixa de correio com tamanho total de 360 MB. Outro exemplo é uma caixa de correio de perfil de mensagem muito pesado de 2 GB que recebe 52 MB de emails por semana, o que consumirá 104 MB no dumpster (5%) e 7,3 MB em espaço em branco, de uma caixa de correio com tamanho total de 2,11 GB. Cinqüenta caixas de correio de 2 GB em um grupo de armazenamento equivaleriam a 105.6 GB.

A seguir, está uma fórmula para o tamanho do banco de dados usando uma caixa de correio de 2 GB:

Tamanho da caixa de correio = cota da caixa de correio + espaço em branco + (mensagens de entrada semanais × 2)

Tamanho da caixa de correio = 2,048 MB + (7.3 MB) + (52 MB × 2)

2,159 MB = 2,048 MB + 7.3 MB + 104 MB (5% maior que a cota)

Depois de determinado o tamanho real projetado da caixa de correio, você poderá usar o valor para determinar o número máximo de usuários por banco de dados. Obtenha o tamanho projetado da caixa de correio e divida-o pelo tamanho máximo recomendado de banco de dados. Isso ajudará a determinar quantos bancos de dados serão necessários para manipular a conta do usuário projetada, considerando bancos de dados completamente preenchidos. Lembre-se de que, devido à E/S não transacional ou devido às limitações de hardware, poderá ser necessário modificar o número de usuários colocados em um único servidor. Alguns administradores preferirão usar mais bancos de dados para reduzir ainda mais o tamanho do banco de dados. Esse método pode ser auxiliado com janelas de backup e de restauração às custas de mais complexidade no gerenciamento de mais bancos de dados por servidor.

Indexação de conteúdo

A indexação de conteúdo cria um índice ou catálogo que permite aos usuários finais pesquisar com facilidade e rapidez os itens de email em vez de vasculhar manualmente a caixa de correio. O Exchange 2007 cria um índice de aproximadamente 5 por cento do tamanho total do banco de dados, que é colocado no mesmo LUN do banco de dados. Uma capacidade adicional de 5 por cento precisa ser fatorada no tamanho do LUN do banco de dados para indexação de conteúdo.

Manutenção

Um banco de dados que precisa ser reparado ou compactado offline precisará de capacidade igual ao tamanho do banco de dados de destino mais 10 por cento. Se você alocar espaço suficiente para um banco de dados único, um grupo de armazenamento ou um conjunto de backup, será necessário espaço adicional disponível para executar essas operações.

Grupo de Armazenamento de Recuperação

Se você planeja usar um grupo de armazenamento de recuperação como parte dos planos de recuperação de desastre, será necessária capacidade suficiente disponível para manipular todos os bancos de dados que você quiser restaurar simultaneamente nesse servidor.

Backup em disco

Muitos administradores executam backups de streaming online para um destino de disco. Se sua estrutura de backup e restauração envolver backup em disco, será necessário haver capacidade suficiente disponível no servidor para hospedar o backup. Dependendo do tipo de backup que você usar, essa capacidade poderá ser tão pequena quanto o banco de dados e os logs, ou tão grande quanto o banco de dados e todos os logs desde o último backup completo.

Capacidade do LUN de log

Os arquivos de log de transações são um registro de todas as transações executadas pelo mecanismo do banco de dados. Todas as transações são gravadas no log primeiro e depois lentamente gravadas no banco de dados. Ao contrário das versões anteriores do Exchange, os arquivos de logs de transações no Exchange 2007 tiveram o tamanho reduzido de 5 MB para 1 MB. Essa alteração foi feita para oferecer suporte aos recursos de replicação contínua e para minimizar a quantidade de perda de dados se o armazenamento principal falhar.

A tabela a seguir pode ser usada para estimar o número de logs de transação que serão gerados em um servidor Caixa de Correio do Exchange 2007 em que o tamanho médio das mensagens é de 50 KB.

Número de logs de transação gerados para cada perfil de caixa de correio

Perfil da caixa de correio	Perfil da mensagem	Logs gerados/caixa de correio
Light	5 enviados/20 recebidos	6
Média	10 enviados/40 recebidos	12
Pesada	20 enviados/80 recebidos	24
Muito Pesada	30 enviados/120 recebidos	36
Extra pesada	40 enviados/160 recebidos	48

As orientações a seguir foram estabelecidas para mostrar como o tamanho das mensagens afeta a taxa de geração de logs:

• Se o tamanho médio das mensagens dobra para 100 KB, os logs gerados por caixa de correio aumenta por um fator de 1.9. Esse número representa a porcentagem do banco de dados que contém os anexos e as tabelas de mensagens (corpos das mensagens e anexos).

• Portanto, quando o tamanho da mensagem dobra para mais de 100 KB, o mesmo acontece com a taxa de geração de logs por caixa de correio.

Por exemplo:

• Se você tem um perfil pesado de caixa de correio e um tamanho médio de mensagens de 100 KB, os logs gerados por caixa de correio são 24 × 1,9 = 46.

• Se você tem um perfil pesado de caixa de correio e um tamanho médio de mensagens de 200 KB, os logs gerados por caixa de correio são 24 × 3.8 = 91.

Fatores de backup e restauração

A maior parte das empresas que executam um backup completo noturno irá alocar a capacidade de cerca de 3 dias de arquivos de log em um grupo de armazenamento no LUN do log de transações. Isso é feito para evitar que uma falha de backup faça com que a unidade de log seja preenchida, o que desmontaria o grupo de armazenamento.

O tamanho do LUN de log é de certa forma dependente de sua estrutura de backup e restauração. Por exemplo, se sua estrutura permitir que você retorne duas semanas e repita todos os logs gerados desde então, você precisará de duas semanas de espaço de arquivo de log. Se sua estrutura de backup incluir backups diferenciais diários e semanais completos, o LUN do log precisará ser maior do que uma semana inteira de logs para permitir o backup e a repetição durante a restauração.

Operações de movimentação de caixa de correio

A movimentação de caixas de correio é um fator de capacidade principal para implantações grandes de caixa de correio. Muitas grandes empresas movem uma porcentagem de seus usuários noturna ou semanalmente para bancos de dados, servidores ou sites diferentes. Se sua organização fizer isso, você poderá achar necessário fornecer capacidade extra para o LUN de log a fim de acomodar as migrações de usuário. Embora o servidor de origem registre as exclusões de registro, que são pequenas, o servidor de destino deve gravar todos os dados transferidos em logs de transação. Se você gerar 10 GB de arquivos de log em um dia, e mantiver um buffer de 3 dias de 30 GB, mover cinqüenta caixas de correio de 2 GB (100 GB) preencheria seu LUN de log de destino e causaria inatividade. Em casos como esses, você pode ter que alocar capacidade adicional para que os LUNs de log se adeqüem às suas práticas de movimentação de caixa de correio.

Fator de crescimento do log

Para a maioria das implementações, recomendamos que você adicione um fator de sobrecarga de 20% ao tamanho do log (depois que todos os outros fatores tiverem sido considerados) quando criar o LUN do log, a fim de garantir que há capacidade necessária em momentos de geração de logs inesperados.

Exemplo de planejamento da capacidade das caixas de correio

O exemplo a seguir ilustra o dimensionamento apropriado para um ambiente em que haja quatro mil caixas de correio de perfil pesado de 1 GB em um único servidor de caixas de correio clusterizadas em um ambiente de CCR (replicação contínua em cluster). Essas caixas de correio recebem uma média de 52 MB de email por semana, com um tamanho médio de mensagem de 50 KB. A tabela a seguir fornece valores de exemplo que determinam o tamanho real da caixa de correio.

Exemplo de valores para determinar o tamanho real da caixa de correio no disco

Tamanho da caixa de correio	Tamanho do dumpster (2 semanas)	Espaço em branco	Tamanho total do disco
1 GB	104 MB (2 × 52 MB)	7,3 MB	1.11 GB (+ 11%)

Nesse ambiente, cada usuário consumirá 1,11 GB de espaço em disco. Como o tamanho máximo recomendado de banco de dados em um ambiente de CCR é de 200 GB, o servidor poderá hospedar no máximo 180 caixas de correio por banco de dados. Para oferecer suporte a 4.000 caixas de correio, é necessário ter 23 bancos de dados e, nesse ambiente, haveria também 23 grupos de armazenamento. Como um ambiente de CCR exige um banco de dados por grupo de armazenamento, cada banco de dados ficará em seu próprio grupo de armazenamento. Isso resulta em uma contagem final de caixa de correio por grupo de armazenamento de 174. Com base no número de caixas de correio e no tamanho real das caixas de correio, o tamanho do banco de dados é de 193 GB, como mostrado na tabela a seguir.

Requisitos de capacidade do banco de dados

Caixas de correio por banco de dados	Número total de bancos de dados	Requisitos de tamanho do banco de dados
174	23	193 GB

Para garantir que o servidor Caixa de Correio não sustente nenhuma parada como resultado de problemas de alocação de espaço, os logs de transação também precisam ser dimensionados para acomodar todos os logs que serão gerados durante o conjunto de backups. Muitas organizações usam um plano diário de estratégia completa de backup para três vezes a taxa de geração de logs diária, no caso de esse backup falhar. Ao usar um backup semanal completo e, em seguida, um backup diferencial ou incremental, pelo menos uma semana de capacidade de logs será necessária para manipular a caixa de restauração. Sabendo-se que uma caixa de correio de perfil de mensagens muito pesado gera 42 logs de transações por dia, um servidor de 4.000 caixas de correio vai gerar 168.000 logs de transação por dia. Isso significa que cada grupo de armazenamento vai gerar 7.304 logs. Dez por cento das caixas de correio são movidas por semana em um dia (sábado) e o regime de backup inclui backups semanais completos e incrementais diários. Além disso, o servidor pode tolerar três dias sem truncamento de logs. Conforme mostrado na tabela a seguir, esse servidor requer 38.8 GB de espaço para cada grupo de armazenamento.

Requisitos de capacidade do log

Logs por grupo de armazenamento	Tamanho do arquivo de log	Tamanho do log diário	Tamanho para movimentação da caixa de correio	Tamanho da restauração incremental	Requisitos de tamanho do log
7,304	1 MB	7,13 GB	17 GB (17 * 1 GB)	21,4 GB (3 * 7.13 GB)	38,8 GB (17.4 + 21.4)

O LUN do log de transações precisa ser grande o suficiente para manipular os logs gerados pela operação de movimentação da caixa de correio e ter espaço suficiente para restaurar uma semana inteira de logs.

E/S transacional

E/S transacional é a E/S de disco causada por usuários que usam o servidor. Por exemplo, receber, enviar e excluir itens provoca E/S de disco. Os usuários do Microsoft Outlook que não estão usando o Modo Cache do Exchange são diretamente afetados por latência de disco ruim, e essa é uma das preocupações mais importantes no design do armazenamento. Para armazenamento, os requisitos da E/S transacional foram reduzidos e, com a replicação contínua, a alta disponibilidade não significa mais ter que usar o caro armazenamento do Fibre Channel (embora essa ainda seja uma boa solução).

Compreendendo a IOPS

Em versões anteriores do Exchange Server, uma das métricas fundamentais necessárias para dimensionamento do armazenamento é a quantidade de E/S de banco de dados por segundo (IOPS) consumida por cada usuário. Para medir sua IOPS de usuário, use a quantidade de E/S (de leituras e gravações) no LUN de banco de dados de um grupo de armazenamento e a divida pelo número de usuários nesse grupo de armazenamento. Por exemplo, 1.000 usuários causando 1.000 E/S no LUN do banco de dados significa que você tem uma IOPS de 1,0 por usuário.

Medir IOPS de linha de base

Se você estiver usando uma versão anterior do Exchange Server, e tiver calculado sua IOPS de linha de base, lembre-se de que o Exchange 2007 afetará sua linha de base de duas maneiras.

• O número de usuários no servidor afetará o cache de banco de dados geral por usuário.

• A quantidade de RAM influencia o tamanho que seu cache de banco de dados pode atingir e um cache de banco de dados maior resulta em mais acertos de leitura de cache, reduzindo assim sua E/S de leitura de banco de dados.

O fundamental é que saber sua IOPS em um servidor específico não é suficiente para planejar uma empresa inteira, pois a quantidade de RAM, o número de usuários e o número de grupos de armazenamento provavelmente serão diferentes em cada servidor. Depois que você tiver seus números de IOPS reais, sempre aplique um fator de sobrecarga de E/S de 20 por cento em seus cálculos para adicionar algum espaço extra. Você não deseja uma experiência de usuário ruim só porque a atividade é um pouco mais pesada que o normal.

Cache de banco de dados

Um sistema operacional Windows Server de 64 bits executando a versão de 64 bits do Exchange 2007 aumenta substancialmente o espaço de endereçamento virtual e permite que o Exchange aumente seu cache de banco de dados, reduza a E/S de leitura do banco de dados e habilite até 50 bancos de dados por servidor.

A redução de leitura do banco de dados depende da quantidade de cache de banco de dados disponível para o servidor e do perfil de mensagem do usuário. Para obter orientações sobre memória e grupos de armazenamento, consulte Planejando Configurações do Processador. Seguir a orientação nesse tópico pode resultar em até 70 por cento de redução de E/S transacional com o Exchange 2003. A quantidade de cache de banco de dados por usuário é um fator fundamental na redução de E/S real.

A tabela a seguir demonstra o aumento no cache de banco de dados real por usuário ao comparar o padrão de 900 MB no Exchange 2003 com os 5 MB de cache de banco de dados por usuário no Exchange 2007. É esse cache de banco de dados adicionais que permite mais acertos de leitura no cache, reduzindo assim as leituras de banco de dados no nível de disco.

Tamanhos de cache de banco de dados com base na contagem de caixas de correio

Contagem de caixas de correio	Caixa de correio/cache de banco de dados (MB) do Exchange 2003	Caixa de correio/cache de banco de dados (MB) do Exchange 2007	Aumento do cache do banco de dados no Exchange 2003
4,000	0.225	5	23 vezes
2,000	0.45	5	11 vezes
1,000	0.9	5	6 vezes
500	1.8	5	3 vezes

Previsão do IOPS da linha de base do Exchange 2007

Os dois maiores fatores que podem ser usados para prever o IOPS do banco de dados do Exchange 2007 são a quantidade de cache do banco de dados por usuário e o número de mensagens que cada usuário envia e recebe por dia. A fórmula a seguir baseia-se em um trabalhador padrão que usa o Office Outlook 2007 no Modo Cache do Exchange; seu teste demonstrou uma precisão de +/- 20%. Outros tipos de clientes e cenários de uso podem levar a resultados incorretos. As previsões são válidas apenas para tamanhos de cache do banco de dados do usuário entre 2 MB e 5 MB. A fórmula não foi validada com usuários enviando e recebendo cerca de 150 mensagens por dia. O tamanho médio da mensagem para validação da fórmula foi de 50 KB, mas o tamanho da mensagem não é um fator fundamental para IOPS.

A tabela a seguir fornece valores estimados para IOPS por usuário que você pode usar para prever os requisitos de IOPS de linha de base do Exchange 2007.

Cache do banco de dados e IOPS estimado por usuário com base no perfil do usuário e na atividade da mensagem

Tipo de usuário (perfil de uso)	Envio/recebimento por dia de tamanho de mensagem de aproximadamente 50 quilobytes (KB)	Cache do banco de dados por usuário	IOPS estimado por usuário
Light	5 enviados/20 recebidos	2 MB	0.11
Média	10 enviados/40 recebidos	3,5 MB	0.18
Pesada	20 enviados/80 recebidos	5 MB	0.32
Muito Pesada	30 enviados/120 recebidos	5 MB	0.48
Extra pesada	40 enviados/160 recebidos	5 MB	0.64

Para estimar o tamanho do cache do banco de dados, subtraia 2.048 MB, ou 3.072 MB ao usar LCR, da quantidade total de memória instalada no servidor Exchange e divida a quantidade pelo número de usuários. Por exemplo, para um servidor com 3.000 usuários e 16 GB de RAM, deduza 2 GB para o sistema, mantendo 14 GB de RAM ou 4.66 MB por usuário (14 GB ÷ 3.000 = 4.66 MB).

Sabendo-se que o tamanho médio do cache do banco de dados por usuário é 4.66 MB e que o número médio de mensagens enviadas e recebidas por dia é 60, é possível estimar as leituras e gravações do banco de dados.

• Leituras de banco de dados   Multiplique as 60 mensagens por dia por 0,0048, o que resulta em 0.288. Em seguida, eleve a soma de caches do banco de dados por caixa de correio (4.66 MB) à -0,65a. potência (5 ^ -0.65), o que resulta em 0,3622. Finalmente, multiplica os dois números, o que resulta em 0,104 leitura de bancos de dados por usuário (0.288 × 0.3622 = 0.104).

• Gravação do banco de dados   Multiplique o número de mensagens por usuário (60) por 0,00152, resultando em 0,0912 gravação do banco de dados por usuário.

A fórmula a ser usada é:

((0.0048 × M) × (D ^ -0.65)) + (0.00152 × M) = IOPS total do banco de dados

em que M é o número de mensagens e D é o cache do banco de dados, por usuário. O IOPS total do banco de dados por usuário é a adição das leituras e das gravações, que nesse exemplo é 0,189 IOPS:

((0.0048 × 60) × (4.66 ^ -0.65)) + (0.00152 × 60) = 0.189

O gráfico a seguir demonstra a redução de leitura e gravação do banco de dados obtida quando se executa o Exchange 2007 com 4.000 caixas de correio de 250 MB, simulando o Outlook 2007 no Modo Cache do Exchange e a memória de servidor recomendada.

Redução em IOPS no Exchange Server 2007, comparada com o Exchange Server 2003

Efeito de clientes em modo online

Diferentemente dos clientes do Modo Cache do Exchange, todas as operações cliente do Modo Online ocorrem no banco de dados. Como resultado, as operações de E/S de leitura aumentarão no banco de dados. Portanto, as orientações a seguir foram estabelecidas para casos em que a maioria dos clientes opera em Modo Online:

• Clientes de Modo Online de 250 MB aumentarão as operações de leitura do banco de dados a um fator de 1,5 quando comparados com clientes do Modo em Cache do Exchange. Abaixo de 250 MB, o impacto é pequeno.

• Quando o tamanho da caixa de correio dobra, o IOPS de leitura do banco de dados também dobra (assumindo-se que a distribuição de itens iguais entre pastas principais permaneça a mesma).

O gráfico a seguir ilustra o IOPS basedo em tamanho da caixa de correio.

O IOPS de leitura de banco de dados aumenta à medida que o tamanho da caixa de correio aumenta

Testes comprovaram também que o aumento da cache do banco de dado para mais de 5 MB por caixa de correio não reduzirá os requisitos de E/S de leitura do banco de dados de forma significativa. O gráfico a seguir mostra caixas de correio de 2 GB usando clientes de Modo Online e o efeito que o aumento da cache para mais de 5 MB tem sobre a redução dos requisitos de E/S de leitura do banco de dados.

O IOPS de leitura de banco de dados diminui à medida que o tamanho da caixa de correio aumenta

Como resultado desses dados, podem ser feitas duas considerações:

• Implantar clientes de modo em cache, onde adequado. Consulte a seção "Contagem de itens por pasta" a seguir para obter mais informações.

• Certifique-se de que os requisitos de E/S sejam considerados ao criar o armazenamento do banco de dados.

Para obter fatores IOPS adicionais, como clientes de terceiros, consulte Optimizing Storage for Exchange Server 2003 (página em inglês).

Taxas de leitura/gravação do banco de dados

No Exchange 2003, a taxa de leitura/gravação do banco de dados era geralmente 2:1 ou 66% de leituras. Com o Exchange 2007, o cache do banco de dados maior diminui o número de leituras do banco de dados em disco fazendo com que as leituras diminuam como uma porcentagem da E/S total. Se você seguir nossas diretrizes de memória recomendadas e usar o Modo Cache do Exchange, a taxa de leitura/gravação deverá ser mais próxima de 1:1, ou 50% de leituras.

Ao usar o Outlook no modo Online, ou ao usar mecanismos de busca do computador, a taxa de leitura/gravação será ligeiramente aumentada no lado da leitura (dependendo do tamanho da caixa de correio). Ter mais gravações como porcentagem da E/S total tem implicações específicas quando se escolhe um tipo de RAID que tenha custos significativos associados às gravações, como RAID5 ou RAID6. Para obter mais informações sobre como selecionar a solução RAID apropriada para seus servidores, consulte Tecnologia de armazenamento.

Taxa de log por banco de dados

No Exchange 2003, um log de transações para um grupo de armazenamento exige aproximadamente 10% de E/S do que exigem os bancos de dados no grupo de armazenamento. Por exemplo, se o LUN de banco de dados estiver usando 1.000 E/S, o LUN do log usará aproximadamente 100 E/S. Com a redução nas leituras de banco de dados no Exchange 2007, somada ao tamanho de arquivo de log menor e a capacidade de ter mais grupos de armazenamento, a taxa de gravação de log por banco de dados é de aproximadamente 3:4. Por exemplo, se o LUN de banco de dados estiver consumindo 500 E/Ss de gravação, o LUN de log consumirá aproximadamente 375 E/Ss de gravação.

Depois de medir ou prever a E/S do log de transações, aplique um fator de sobrecarga de E/S de 20% para garantir o espaço extra adequado para períodos de maior atividade que os períodos normais. Além disso, ao usar a replicação contínua, os logs de transações fechados devem ser lidos e enviados para um segundo local. Essa sobrecarga é um adicional de 10 por cento em leituras de log. Se o log de transações de um grupo de armazenamento estiver consumindo 375 E/Ss de gravação, você pode esperar um adicional de 37,5 E/Ss de leitura ao usar a replicação contínua.

Contagem de itens por pasta

Compreendendo o impacto no desempenho causado por altas contagens de item e de exibições restritas explica como o número de itens em suas pastas críticas e o tipo e o modo de cliente sendo usado podem afetar o desempenho de disco para alguns usuários.

Uma maneira de reduzir a E/S é usar o Outlook 2007 no Modo Cache do Exchange. A sincronização da caixa de correio inicial é uma operação cara, mas, com o tempo, conforme o tamanho da caixa de correio aumenta, a carga do subsistema do disco é transferida do servidor Exchange para o cliente Outlook. Isso significa que ter um grande número de itens em uma Caixa de Entrada de usuário ou um usuário pesquisando uma caixa de correio terá pouco efeito no servidor. Isso também significa que os usuários do Modo Cache do Exchange com grandes caixas de correio podem precisar de computadores mais rápidos do que aqueles com pequenas caixas de correio (dependendo do limite de usuário individual para desempenho aceitável). Ao implantar computadores clientes que executam o Outlook 2007 no Modo Cache do Exchange, considere o seguinte em relação aos tamanhos de /.OSTda caixa de correio:

• Até 5 gigabytes (GB): Esse tamanho deve fornecer uma boa experiência de usuário na maioria dos hardwares.

• Entre 5 GB e 10 GB: Geralmente, esse tamanho é dependente do hardware. Portanto, se tiver uma unidade de disco rígido rápida e muita RAM, sua experiência será melhor. No entanto, unidades de disco rígido mais lentas, como unidades que existem geralmente em computadores portáteis ou SSDs antigas, se experimenta a pausa de aplicativo aplicativo quando as unidades respondem.

• Mais de 10 GB: Esse é o tamanho no qual pausas curtas começam a ocorrer na maioria dos hardwares.

• Muito grande, como 25 GB ou maior: Esse tamanho aumenta a frequência das pausas curtas, especialmente durante o download de novos emails. Alternativamente, você pode usar os grupos Enviar/Receber para sincronizar manualmente seu email.

Se experimentar problemas relacionados ao desempenho do Outlook 2007 no Modo Cache do Exchange, consulte o artigo 940226 da Base de Dados de Conhecimento da Microsoft, Como solucionar problemas de desempenho do Outlook 2007.

Tanto o Outlook Web Access como o Outlook no modo Online armazenam índices e pesquisam na cópia dos dados do servidor. Para caixas de correio de tamanho moderado, isso resulta em aproximadamente dobrar a IOPS por caixa de correio de um cliente do Modo Cache do Exchange de tamanho comparável. A IOPS por caixa de correio para caixas de correio grandes é ainda maior. A primeira vez que você classificar uma exibição de uma nova maneira, um índice será criado, causando muitas E/S de leitura no LUN de banco de dados. Classificações subseqüentes em um índice ativo são baratas.

Um cenário desafiador ocorre quando um usuário foi além do número de índices que o Exchange vai armazenar; número que, no Exchange 2007, é igual a 11. Quando o usuário escolhe classificar um novo caminho, criando assim um décimo segundo índice, isso provoca E/S de disco adicional. Como o índice não está armazenado, o custo de E/S do disco ocorre toda vez que a classificação é feita. Devido à alta E/S que pode ser gerada nesse cenário, é altamente recomendável armazenar no máximo 20.000 itens em pastas fundamentais, como as pastas Caixa de Entrada e Itens Enviados. A criação de mais pastas de nível superior, ou subpastas dentro das pastas Caixa de Entrada e Itens Enviados, reduz enormemente os custos associados à criação desse índice, contanto que o número de itens em qualquer outra pasta não exceda 20.000. Para obter mais informações sobre como as contagens de itens afetam o desempenho do servidor Caixa de Correio, consulte Recommended Mailbox Size Limits e Compreendendo o impacto no desempenho causado por altas contagens de item e de exibições restritas (página em inglês).

Para obter mais informações sobre os aprimoramentos disponíveis, consulte o artigo 968009 da Base de Dados de Conhecimento Microsoft, Aprimoramentos do Outlook 2007 na atualização cumulativa de fevereiro de 2009.

E/S não transacional

A E/S transacional ocorre em resposta à ação de usuário direta e geralmente tem a prioridade mais alta e é o foco da estrutura de armazenamento. A redução na E/S transacional torna a E/S não transacional mais importante. Com grandes caixas de correio, particularmente no caso da caixa de correio de 2 GB, muitas empresas não estão dobrando a capacidade do usuário, mas em alguns casos a aumentando em dez vezes. Um exemplo seria a mudança de 200 MB para 2 GB. Quando você tiver um aumento significativo na quantidade de dados no disco, deverá então levar em consideração a E/S não transacional ao planejar a estrutura de armazenamento.

Indexação de conteúdo

No Exchange 2007, as mensagens são indexadas conforme são recebidas, causando pouca sobrecarga de E/S de disco. A pesquisa do índice no Exchange 2007 é aproximadamente 30 vezes mais rápida do que no Exchange 2003.

Gerenciamento de Registros de Mensagens

O Gerenciamento de registros de mensagens (MRM) é um novo recurso no Exchange 2007 que ajuda os administradores e usuários a gerenciar suas caixas de correio. Diretivas podem ser definidas para mover ou excluir emails que atendam a limites específicos, como idade. O MRM é um rastreamento agendado que é executado no banco de dados em uma operação de leitura síncrona similar ao backup e à manutenção online. O custo de disco de MRM depende do número de itens que exigem ação (por exemplo, excluir ou mover).

Recomendamos que o MRM não seja executado ao mesmo tempo que o backup ou a manutenção online. Se você usar a replicação contínua, poderá descarregar backups de VSS (Serviço de Cópias de Sombra de Volume) na cópia passiva, permitindo mais tempo para a manutenção online e o MRM para que eles não afetem um o outro ou os usuários.

Manutenção online

Muitas ações são tomadas quando o banco de dados executa a manutenção online, como a remoção permanente de itens excluídos e a execução da desfragmentação online do banco de dados. A manutenção provoca leituras, enquanto a desfragmentação online provoca tanto leituras quanto gravações. A quantidade de tempo necessária para concluir a manutenção é proporcional ao tamanho do banco de dados e pode ser um fator limitador no tamanho que os bancos de dados podem atingir. Para obter mais informações sobre manutenção online, consulte Processos do armazenamento em segundo plano - Parte I.

Backup e restauração

Diferentes métodos de backup e restauração estão disponíveis ao administrador. A métrica fundamental com o backup e a restauração é a taxa de transferência, ou o número de megabytes por segundo que podem ser copiados para e de seus LUNs de produção. Depois de determinar a taxa de transferência, você precisará decidir se ela é suficiente para atender ao acordo de nível de serviço (SLA) de backup e restauração. Por exemplo, se você precisar concluir o backup dentro de quatro horas, poderá ser necessário adicionar mais hardware para conseguir isso. Dependendo de sua configuração de hardware, é possível que haja ganhos que possam ser atingidos alterando o tamanho da unidade de alocação. Isso pode ajudar com backups online de streaming e com a verificação de integridade do Exchange Server Database Utilities (Eseutil.exe) que ocorre durante um backup de VSS.

Com 2.000 usuários em um servidor, a mudança de uma caixa de correio de 200 MB para uma de 2 GB aumenta o tamanho do banco de dados em dez vezes. Muitos administradores não estão acostumados a ter que lidar com quantidades grandes de dados em um único servidor. Considere um servidor com 2.000 caixas de correio de 2 GB. Com a sobrecarga descrita anteriormente, isso representa mais de 4 TB de dados. Presumindo-se que você atinja uma velocidade de backup de 175 GB/hora (48 MB/min), seriam necessárias pelo menos 23 horas para fazer o backup do servidor. Uma alternativa para servidores que não usam LCR ou CCR seria executar um backup completo de 1/7 dos bancos de dados a cada dia e um backup incremental no restante, conforme explicado na tabela a seguir.

Exemplo de uma rotina semanal de backup

Tipo de backup	Dia 1	Dia 2	Dia 3	Dia 4	Dia 5	Dia 6	Dia 7
Inteiro	BD 1-2	BD 3-4	BD 5-6	BD 7-8	BD 9-10	BD 11-12	BD 13-14
Incremental	BD 3-14	BD 1-2 BD 5-14	BD 1-4 BD 7-14	BD 1-6 BD 9-14	BD 1-8 BD 11-14	BD 1-10 BD 13-14	BD 1-12

Como pode ser visto na tabela anterior, a quantidade total de dados com backup noturno é de aproximadamente 650 GB, o qual poderia ser concluído em 3,7 horas, supondo uma velocidade de 175 GB/hora. Algumas soluções podem alcançar mais ou menos transferência. No entanto, caixas de correio grandes podem exigir diferentes metodologias.

Com LCR e CCR, a cópia passiva é a primeira linha de defesa. Só será possível restaurar a partir do backup se as cópias ativa e passiva falharem ou não estiverem disponíveis. A recuperação de vários dias de logs incrementais pode somar-se ao período de tempo necessário para recuperação. Por essa razão, o backup incremental é raramente usado em uma solução de recuperação rápida, como clones de CCR ou VSS. Com um clone de VSS, a recuperação dos dados é rápida e adicionar um pouco de tempo aos logs de repetição pode ser aceitável para manter os tempos de backup dentro do SLA de backup.

Backup online de streaming

Com backups de streaming, é recomendável que você separe a E/S de streaming (origem e destino) para que vários grupos de armazenamento com backup simultâneo não entrem em competição pelos mesmos recursos de disco. Seja o destino disco ou fita, haverá um limite de taxa de transferência nos discos físicos e controladores únicos de cada solução de hardware. Pode ser necessário isolar alguns grupos de armazenamento um do outro para maximizar o número de operações de backup simultâneas e a taxa de transferência para minimizar o tamanho da janela de backup. A tabela a seguir ilustra um exemplo de dois backups simultâneos de 14 bancos de dados.

Exemplo de uma rotina de backups simultâneos

Número de backup	LUN 1	LUN 2	LUN 3	LUN 4	LUN 5	LUN 6	LUN 7
Primeiro backup	grupo de armazenamento (SG) 1	SG 2	SG 3	SG 4	SG 5	SG 6	SG 7
Segundo backup	SG 8	SG 9	SG 10	SG 11	SG 12	SG 13	SG 14

Você pode´r executar backups ao mesmo tempo, um para cada LUN, se isolar os LUNs de grupos de armazenamento uns dos outros, conforme ilustrado na tabela anterior. Os trabalhos de backup devem ser concluídos no primeiro grupo de armazenamento em cada LUN antes de o segundo grupo de armazenamento começar o backup, isolando os fluxos de backup. Dois trabalhos de backup de streaming nos mesmos discos físicos podem não ter o dobro da velocidade, mas deverão ser mais rápidos do que um único trabalho de backup de streaming em termos de megabytes por segundo.

Backup de VSS

O Exchange 2007 usa o VSS incluído no Windows Server 2003 para fazer cópias de sombra de volume de bancos de dados e arquivos de log de transações. Para obter mais informações sobre VSS, incluindo técnicas de clone e instantâneo, consulte Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003 (página em inglês). Uma novidade no Exchange 2007 é a capacidade de fazer backups de VSS da cópia passiva de grupos de armazenamento que estão em execução em um ambiente de LCR ou de CCR. Nesses ambientes, a obtenção de um instantâneo de VSS da cópia passiva remove a carga do disco nas LUNs ativos durante a fase de integridade da soma de verificação do backup e a cópia subseqüente para a fita ou o disco. Além disso, libera mais tempo nos LUNs ativos para executar a manutenção online, o MRM e outras tarefas.

LUNs e discos físicos

Em muitos casos, o disco físico ou o LUN (número da unidade lógica) que o sistema operacional reconhece é separado do hardware usado para apresentar o disco ao sistema operacional. Por motivos de desempenho e recuperação, sempre foi fundamental separar os arquivos de log de transações dos arquivos de bancos de dados tanto no nível da LUN quanto no nível do disco físico. Misturar E/S aleatória e seqüencial no mesmo disco físico reduz significativamente o desempenho e, do ponto de vista da recuperação, separar os arquivos de log e os arquivos de banco de dados de um grupo de armazenamento garante que uma falha catastrófica de um conjunto de discos físicos não cause a perda dos arquivos de banco de dados e de log.

No Exchange 2007, é uma prática recomendada colocar todos os bancos de dados em um grupo de armazenamento na mesma LUN física. Colocar no máximo um banco de dados em cada grupo de armazenamento também é uma prática recomendada. A E/S do banco de dados do Exchange é aleatória e a maioria dos subsistemas de armazenamento é beneficiada quando os discos físicos são executados com a mesma carga de trabalho. Muitas matrizes de armazenamento são projetadas para que vários discos físicos sejam primeiro reunidos em um grupo de discos e, em seguida, LUNs sejam criados a partir do espaço disponível nesse grupo de discos e distribuídos igualmente entre todos os discos físicos. É aceitável que os discos físicos que estão executando backup em uma LUN de banco de dados do grupo de armazenamento também faça backup de outras LUNs que hospedam bancos de dados para outros grupos de armazenamento e servidores. Do mesmo modo, não é fundamental isolar a LUN do log de transações de cada grupo de armazenamento em eixos físicos separados, mesmo que a perda de E/S seqüencial tenha um ligeiro impacto no desempenho.

Caso o máximo de 50 grupos de armazenamento estejam configurados em um único servidor, cada grupo de armazenamento deverá ter seu próprio LUN do log de transações e o LUN de banco de dados. Isso excede o número de letras de unidade disponíveis e é necessário usar os pontos de montagem de volume do sistema de arquivos NTFS. Cinqüenta grupos de armazenamento configurados para replicação contínua exigem 200 LUNs, o que pode exceder alguns máximos de matrizes de armazenamento, especialmente no caso de LCR (replicação contínua local), em que todos os 200 LUNs devem ser apresentados em um único servidor. Conforme aumenta o número de LUNs, o monitoramento se torna ainda mais importante, porque quando o espaço em disco acabar, o grupo de armazenamento se desmontará.

Estrutura do LUN

Em muitos casos, o LUN que o sistema operacional reconhece é removido do hardware físico que está na verdade por trás desse disco. Sempre foi essencial separar logs de transação do banco de dados tanto no LUN quanto no nível de disco físico com fins de desempenho e capacidade de recuperação. Em algumas matrizes de armazenamento, a mistura de E/S aleatória e seqüencial nos mesmos discos físicos pode reduzir o desempenho. Da perspectiva de recuperação, separar logs de transações e bancos de dados de um grupo de armazenamento garante que uma falha catastrófica de um determinado conjunto de discos físicos não causa perda de logs de transações e do banco de dados.

A E/S do banco de dados do Exchange é aleatória, e a maior parte dos subsistemas de armazenamento se beneficia quando os discos físicos estão executando a mesma carga de trabalho. Muitas matrizes de armazenamento use armazenamento virtual para que vários discos físicos sejam primeiro reunidos em um grupo de discos e, em seguida, LUNs sejam criados a partir do espaço disponível nesse grupo de discos e distribuídos igualmente entre todos os discos físicos. Quando a replicação contínua não estiver sendo usada, é aceitável que os discos físicos que estejam executando backup de um LUN de banco de dados do grupo de armazenamento também façam backup de outros LUNs que hospedem bancos de dados para outros grupos de armazenamento e servidores. Do mesmo modo, não é fundamental isolar o LUN do log de transações de cada grupo de armazenamento em eixos físicos separados, mesmo que a perda de E/S seqüencial afete ligeiramente o desempenho. É importante separar os LUNs de log e de banco de dados do mesmo grupo de armazenamento em discos físicos separados. Não é realista dedicar dois ou quatro discos físicos de 500 GB ao LUN do log de transações de um único grupo de armazenamento quando você precisar de 30 IOPS e 5 por cento da capacidade.

Embora haja muitas formas de projetar LUNs no Exchange 2007, recomendamos as duas estruturas a seguir para limitar a complexidade:

• Dois LUNs por grupo de armazenamento

• Dois LUNs por conjunto de backup

Dois LUNs por grupo de armazenamento

Criar dois LUNs (um para logs e um para bancos de dados) para um grupo de armazenamento era a prática recomendada padrão do Exchange 2003. Com o Exchange 2007, e no caso máximo de 50 grupos de armazenamento, o número de LUNs que você configurar depende de sua estratégia de backup. Se seu RTO é pequeno, ou se você usa clones de VSS para recuperação rápida, pode ser recomendável colocar cada grupo de armazenamento em seu próprio LUN de log de transações e LUN de banco de dados. Como essa abordagem excederá o número de letras de unidade disponíveis, os pontos de montagem de volume deverão ser usados.

Algumas das vantagens desta estratégia são:

• Permite o VSS com base em hardware em um nível de grupo de armazenamento, fornecendo backup e restauração de grupo de armazenamento único.

• Flexibilidade para isolar o desempenho entre grupos de armazenamento.

• Maior confiabilidade. Um problema de capacidade, dano ou vírus em uma único LUN só afetará um grupo de armazenamento.

Alguns dos problemas desta estratégia são:

• 50 grupos de armazenamento usando replicação contínua exigem 200 LUNs, o que pode exceder alguns máximos de matrizes de armazenamento, especialmente no caso de LCR (replicação contínua local), em que todas os 200 LUNs precisam ser apresentados a um único servidor.

• Um LUN separado para cada grupo de armazenamento gera mais LUNs por servidor, aumentando os custos administrativos.

Dois LUNs por conjunto de backup

Um conjunto de backup é o número de bancos de dados dos quais é feito backup completo em uma noite. Uma solução que executa um backup completo em 1/7 dos bancos de dados à noite pode reduzir a complexidade colocando todos os grupos de armazenamento dos quais o backup será feito no mesmo LUN de banco de dados e log. Isso pode reduzir o número de LUNs no servidor.

Algumas das vantagens desta estratégia são:

• Administração de armazenamento simplificada, pois há menos LUNs a serem gerenciados.

• Pode reduzir potencialmente o número de trabalhos de backup.

Alguns dos problemas desta estratégia são:

• Capacidade limitada de realizar backup e restaurações de VSS baseados em hardware.

• Limitação do dimensionamento dessa estratégia em capacidade, devido ao limite de 3 TB em uma partição MBR (registro mestre de inicialização).

Pontos de montagem de volume

Há muitos casos, como clusters de cópia única (SCCs) com vários nós, em que mais LUNs são necessários do que há letras de unidade disponíveis. Nesses casos, você deve usar pontos de montagem de volume. As letras de unidade são um recurso herdado do MS-DOS para reconhecer partições ou discos, e é recomendável evitar usar muitas delas. É muito mais fácil colocar todos os LUNs de log de transações e banco de dados em um ponto de montagem de volume para simplificar a administração. Se você tiver 20 grupos de armazenamento, cada um com um banco de dados, será difícil lembrar-se da letra da unidade que hospeda o banco de dados 17. A tabela a seguir ilustra um exemplo de uso de pontos de montagem de volume.

Exemplo de layout de pasta usando pontos de montagem de volume

Logs de transações (L:)	Bancos de dados (P:)
L:\SG1LOG	P:\SG1DB
L:\SG2LOG	P:\SG2DB
L:\SG3LOG	P:\SG3DB
L:\SG4LOG	P:\SG4DB

Neste exemplo, L: e P: são LUNs ancorados, que hospedam todos os LUNs de logs e de bancos de dados, respectivamente. Cada pasta nessas unidades é um ponto de montagem de volume em um LUN separado.

VSS baseado em hardware

Ao usar VSS baseado em hardware, há algumas recomendações para colocar dados do Exchange nos LUNs. Para uma solução de VSS baseada em hardware, cada LUN de log de transações e LUN de banco de dados só deverá hospedar os arquivos do conjunto de backup escolhido. Se desejar restaurar um grupo de armazenamento sem afetar nenhum outro grupo de armazenamento, você precisará de um LUN de log de transações e um LUN de banco de dados para cada grupo de armazenamento. Se estiver disposto a colocar outros bancos de dados e grupos de armazenamento offline para restaurar um banco de dados único, você poderá colocar vários grupos de armazenamento em um único LUN de log de transações e LUN de banco de dados.

VSS baseado em software

Ao usar VSS baseado em software, particularmente com grandes caixas de correio e replicação contínua, seu backup é uma estratégia em duas etapas. Primeiro, você obtém um instantâneo do VSS e, em seguida, transmite os arquivos simples para disco ou fita.

Confiabilidade do LUN

É sempre importante colocar os logs de transações e bancos de dados de um grupo de armazenamento em discos físicos separados porque ao fazer isso a confiabilidade é aumentada. Com a replicação contínua, é também importante separar os LUNs ativos e passivos em armazenamento completamente separado. Com CCR e LCR, você deseja resiliência de armazenamento no caso de uma falha catastrófica do armazenamento principal.

Exemplo de LUN

Considere o seguinte cenário, que é criado com base no exemplo anterior de capacidade e aplica essas informações à criação de um LUN. Nesse exemplo, o regime de backup é um backup diário completo. Você quer habilitar a indexação de conteúdo e colocá-la no LUN do banco de dados. Cinco por cento de 193 GB é aproximadamente 10 GB. Você precisa adicionar isso ao tamanho final do LUN. O fator de crescimento para 193 GB deve ser de 20 por cento do tamanho final do banco de dados. 20% de 193 GB é aproximadamente 39 GB. Os resultado são mostrados nas tabelas a seguir.

Exemplo de valores para determinar o tamanho do LUN do banco de dados

Tamanho do banco de dados	Fator de crescimento	Indexação de conteúdo	Tamanho da LUN do banco de dados
193 GB	39 GB	10 GB	241 GB

Cada grupo de armazenamento cria 7.13 GB de logs por dia, e você deseja armazenar pelo menos 3 dias de logs.

Exemplo de valores para determinar o tamanho do LUN do log

Logs (1 dia)	Logs (3 dias)
7,13 GB	21,4 GB

Mover Caixa de Correio

Nossa exemplo de organização move 10 por cento de suas caixas de correio por semana e executam todos os movimentos aos sábados. Assim, o LUN do log deverá manipular a carga inteira um dia. Uma estratégia para a movimentação da caixa de correio usada no Microsoft é distribuir os usuários de entrada igualmente em cada um dos grupos de armazenamento. Isso significa que o servidor de exemplo com 4.000 usuários moverá aproximadamente 400 usuários por sábado. Com 23 grupos de armazenamento, cada grupo de armazenamento deverá receber 17 caixas de correio de 1 GB, conforme mostrado na tabela a seguir.

Exemplo de valores para determinar o tamanho do LUN do log da caixa de correio de movimentação

Logs (3 dias)	Movimentações da caixa de correio	Tamanho da LUN do log
21,4 GB	17.64 GB (17 usuários de 1 GB)	46.6 GB (38.8 GB + 20%)

Com esse layout, você nunca moverá mais que 17 usuários para um grupo de armazenamento em um único dia. Portanto, pode ser mais vantajoso aumentar o tamanho do LUN do log, no caso de precisar movimentar mais do que 10 por cento em algum dia específico.

Impacto da replicação contínua no projeto de armazenamento

A replicação contínua é um recurso novo do Exchange 2007, no qual o os arquivos de log e de banco de dados de um grupo de armazenamento são copiados para um local secundário. Conforme novos logs de transações vão sendo fechados ou preenchidos, eles são copiados para um local secundário, validados e repetidos em uma cópia passiva do banco de dados. Para alcançar a resiliência de armazenamento, recomendamos que a cópia passiva seja colocada em uma matriz de armazenamento totalmente isolada das LUNs de produção ao vivo. Como você depende da cópia passiva para tratar da carga de produção caso haja uma falha, o armazenamento dela deve corresponder, em capacidade e desempenho, à solução de armazenamento usada pela cópia ativa do grupo de armazenamento.

Cada grupo de armazenamento pode conter apenas um banco de dados ao usar a replicação contínua, de modo que cada cópia do banco de dados exigirá quatro LUNs. Cada banco de dados será seu próprio grupo de armazenamento, que precisará de uma LUN de banco dados e log separados para a cópia ativa e uma LUN de banco de dados e log separado para a cópia passiva.

A prática recomendada é:

• Separar o armazenamento em LUNs individuais no nível do hardware e não criar múltiplas partições lógicas para uma LUN dentro do sistema operacional.

• Separar os logs de transações e os bancos de dados e hospedá-los em discos físicos separados para aumentar a tolerância a falhas.

• Separar as LUNs ativas e passivas em matrizes de armazenamento totalmente diferentes, para que o armazenamento não seja um ponto de falha único.

• Se você estiver hospedando grupos ou bancos de dados de armazenamento de vários servidores de caixas de correio clusterizadas na mesma matriz de armazenamento, deverá verificar se cada LUN está incorporada usando discos físicos separados.

Seu projeto de armazenamento também deve maximizar a tolerância a falhas, separando os controladores de armazenamento em um bus PCI (Interconexão de Componente Periférico). Além disso, você deve projetar o armazenamento da cópia passiva para que seja compatível com o armazenamento usado pela cópia ativa tanto em termos de capacidade quanto de desempenho. O armazenamento da cópia passiva é a primeira linha de defesa no caso de uma falha catastrófica do armazenamento da cópia ativa, e no failover, a cópia passiva se tornará uma cópia ativa. Colocar os LUNs da cópia passiva em hardwares de armazenamento completamente diferentes garante que nenhuma ação executada contra a cópia passiva afete as cópias ativas.

Com a replicação contínua, ocorre mais E/S transacional. Esse fator deve ser levado em consideração ao decidir o tamanho do servidor. O log de transações ativo, que é uma gravação seqüencial, também deve ler o log depois que ele tiver sido fechado e copiá-lo para a pasta de quarentena das LUNs do log de transações de réplica. O log deve ser então inspecionado no local da réplica e movido para seu destino final na LUN de réplica. Finalmente, o log é lido e tocado no banco de dados. Tanto as LUNs de logs ativos quanto as de réplica precisam ler e gravar, em contraste com a atividade que é quase 100 por cento de gravação seqüencial encontrada em um servidor de Caixa de Correio autônomo. Essa alteração de comportamento pode exigir uma avaliação das configurações de cache de seu controlador de armazenamento. As configurações recomendadas são 25% para leitura e 75% para gravação em um controlador de armazenamento auxiliado por bateria.

Replicação contínua e tamanho de banco de dados

É possível um tamanho máximo de banco de dados maior quando a replicação contínua é usada. Recomendamos usar os seguintes tamanhos máximos de bancos de dados para o Exchange 2007:

• Bancos de dados hospedados em um servidor de Caixa de Correio sem replicação contínua: 100 GB

• Bancos de dados hospedados em um servidor de Caixa de Correio com replicação contínua e Gigabit Ethernet: 200 GB

  Dica

  Bancos de dados grandes também podem exibir tecnologia de armazenamento mais recente para maior largura de banda para acomodar situações de reparo.

  Importante

  O tamanho máximo real para bancos de dados deve ser ditado pelo SLA vigente em sua organização. A determinação do banco de dados de maior tamanho cujo backup e restauração poderão ser feitos dentro do período especificado no SLA da organização é a forma de determinar o tamanho máximo de seus bancos de dados.

Opções de armazenamento em LCR

LCR permite o envio de logs em um único servidor. No caso de uma falha catastrófica do armazenamento que hospeda a cópia ativa dos arquivos de bancos de dados ou de log, o administrador pode ativar manualmente a cópia passiva do banco de dados. O armazenamento da cópia passiva deve ser totalmente separado do armazenamento da cópia ativa. Além disso:

• Placas de controlador devem estar em um barramento PCI diferente.

• Cada solução de armazenamento deve ter sua própria fonte de energia ininterrupta (UPS).

• Cada solução de armazenamento deve estar em um circuito de alimentação separado.

Opções de armazenamento em CCR

CCR permite o envio de logs para um nó passivo em um cluster de failover ativo/passivo. Ao enviar os logs e manter a cópia passiva em um servidor completamente diferente, o impacto operacional no nó ativo é diminuído e você obtém tolerância a falhas no servidor.

Em implantações CCR geograficamente dispersas, a cópia passiva pode estar em um nó que esteja em um local físico diferente do nó ativo, fornecendo resiliência do site. Embora as informações do artigo Diretivas de implantação para replicação de dados em vários sites do Exchange Server (página em inglês) ainda sejam aplicáveis, a tecnologia baseada em recebimento por trás da replicação contínua significa que a alta latência não afetará a experiência do usuário. Esse é um nítido contraste em relação à solução em cluster geograficamente dispersa em que a latência sincronizada de replicação afeta negativamente o servidor ativo. Com a CCR, o processo de replicação pode ser executado em segundo plano, aumentando o tempo durante o qual a cópia ativa e a passiva não estão sincronizadas. No entanto, se um desastre afetar a cópia ativa, todas as mensagens que não tiverem sido replicadas para o nó passivo serão recuperáveis, devido ao recurso de dumpster do servidor de Transporte de Hub.

Opções do armazenamento de cluster de cópia única

O hardware usado para um SCC única deve ser listado na categoria Cluster do Catálogo de servidor Windows. O hardware usado para um SCC geograficamente disperso deve ser listado na categoria Cluster Disperso Geograficamente do Catálogo de servidor Windows para ter suporte.

Um servidor de caixas de correio clusterizadas que usa armazenamento compartilhado tem as mesmas considerações fundamentais de armazenamento que um servidor autônomo. Ao usar replicação sincronizada, a latência do disco pode ser aumentada artificialmente pelo processo de replicação. Deve-se tomar cuidado para maximizar os pontos de replicação dentro da matriz de armazenamento. Para obter mais informações sobre replicação para SCCs, consulte Deployment Guidelines for Exchange Server Multi-Site Data Replication (página em inglês).