Exportar (0) Imprimir
Expandir Tudo

Soluções testadas do Exchange 2010: 32400 Caixas de Correio em três sites executando Hyper-V em servidores blade Unified Compute System da Cisco e armazenamento EMC CLARiiON

 

Tópico modificado em: 2012-03-05

Rob Simpson, gerente de programa, Microsoft Exchange; Boris Voronin, Sr. Engenheiro de soluções, soluções Exchange engenharia, EMC; Mike Mankovsky, arquiteto de soluções da Microsoft, Cisco

De Junho de 2011

Nas soluções testadas do Exchange 2010, a Microsoft e os parceiros participantes de servidores, armazenamento e redes examinam cenários comuns de clientes e pontos importantes de decisões de design contemplados pelos clientes que pretendem implantar o Microsoft Exchange Server 2010. Nesta série de white papers, fornecemos exemplos de soluções bem projetadas e econômicas do Exchange 2010 implantadas em hardware oferecido por alguns de nossos parceiros de servidores, armazenamento e redes.

Este documento pode ser baixado no Centro de Download da Microsoft.

Microsoft Exchange Server 2010 com Service Pack 1 (SP1)

Windows Server 2008 R2

Windows Server 2008 R2 Hyper-V

Conteúdo

Este documento oferece um exemplo de como criar, testar e validar uma solução Exchange Server 2010 executando a tecnologia Windows Server 2008 R2 Hyper-V em um ambiente de cliente com 32.400 caixas de correio implantadas em servidores blade Cisco Unified Computing System e soluções de armazenamento EMC CLARiiON. Um dos principais desafios na criação de ambientes grandes do Exchange 2010 é examinar as opções disponíveis atualmente em servidores e armazenamento e fazer as escolhas certas em hardware para obter o melhor valor em relação à vida prevista para a solução. Seguindo a metodologia passo a passo deste documento, trataremos dos pontos importantes de decisões de design que ajudam a lidar com esses desafios essenciais, garantindo que os requisitos principais dos negócios do cliente sejam atendidos. Depois que determinamos a solução ideal para esse cliente, a solução passa por um processo padrão de validação que garante seu correto funcionamento em cargas de trabalho de produção simuladas para cenários de operação normal, manutenção e falha.

Return to top

As tabelas a seguir resumem os principais componentes de hardware e do Exchange desta solução.

Componentes do Exchange

Componente do Exchange Valor ou descrição

Contagem de caixa de correio de destino

32400

Tamanho médio de caixa de correio de destino

2 gigabytes (GB) (thin provisionados em 600 megabytes (MB) de tamanho inicial)

Perfil-alvo médio da mensagem

100 mensagens por dia

Contagem de cópias de banco de dados

3

Backup do VSS (serviço de cópias de sombra de volume)

Nenhum

Resiliência de site

Sim

Número de sites

3

Modelo de DAG (grupo de disponibilidade de banco de dados)

Distribuição ativa/ativa (vários DAGs)

Virtualização

Hyper-V

Contagem de servidor do Exchange

4 máquinas virtuais (VMs)

Contagem de servidor físico

2

Componentes de hardware

Componente de hardware Valor ou descrição

Parceiro de servidor

Cisco

Modelo de servidor

M200

Tipo de servidor

Lâmina

Processador

Intel Xeon X 5570

Parceiro de armazenamento

EMC

Modelo de armazenamento

CX4-480

Tipo de armazenamento

SAN (rede de área de armazenamento)

Tipo de disco

SAS 450 GB 15.000 3,5 "

Parceiro de balanceamento de carga

Cisco

Modelo de balanceamento de carga de hardware

Ás

Return to top

Uma das primeiras etapas mais importantes ao criar soluções do Exchange é resumir com precisão os requisitos comerciais e técnicos essenciais para que decisões de design corretas sejam tomadas. As seções a seguir descrevem as necessidades do cliente para esta solução.

Return to top

Determine os requisitos de perfil de caixa de correio da forma mais precisa possível, porque esses requisitos podem afetar todos os outros componente do design. Caso não tenha experiência com o Exchange, você terá que fazer algumas suposições. Caso já possua um ambiente do Exchange, você pode usar a ferramenta Microsoft Exchange Server Profile Analyzer para obter ajuda com a coleta da maior parte das informações. As tabelas a seguir resumem os requisitos de perfil de caixa de correio para esta solução.

Requisitos de contagem de caixa de correio

Requisito de contagem de caixa de correio Valor

Contagem de caixa de correio (número total de caixas de correio incluindo caixas de correio de recurso)

30000

Porcentagem (%) de crescimento projetado em contagem de caixas de correio (aumento projetado em contagem de caixas de correio ao longo da vida da solução)

8%

Esperado de caixa de correio simultaneidade % (número máximo de caixas de correio ativas a qualquer momento)

100%

Contagem de caixa de correio de destino (contagem de caixa de correio, incluindo o crescimento x esperado simultaneidade)

32400

Requisitos de tamanho de caixa de correio

Requisito de tamanho de caixa de correio Valor

Média de caixa de correio de tamanho em MB

600 MB

Média de tamanho de arquivo de caixa de correio em MB

Não se aplica

Crescimento projetado (%) em tamanho de caixas de correio em MB (aumento projetado em tamanho de caixas de correio ao longo da vida da solução)

230%

Tamanho de média de caixa de correio de destino em MB

2.048 MB

Requisitos de perfil de caixa de correio

Requisito de perfil de caixa de correio Valor

Meta de perfil de mensagens (número total médio de mensagens enviadas somadas às recebidas por usuário por dia)

100 mensagens por dia

Tamanho médio da mensagem de destino em quilobytes (KB)

75

% no modo em cache do MAPI

100

% no modo online MAPI

0

% no modo em cache do Outlook em qualquer lugar

0

% no Outlook Web App do Microsoft Office (Outlook Web Access no Exchange 2007 e em versões anteriores)

0

% no Exchange ActiveSync

0

Return to top

Ao tomar decisões de design sobre alta disponibilidade e resiliência de sites, é importante entender a distribuição dos usuários de caixa de correio e datacenters.

A tabela a seguir resume a distribuição geográfica das pessoas que vão utilizar o sistema do Exchange.

Distribuição geográfica do povo

Requisito de site de usuário de caixa de correio Valor

Número de grandes sites que contém os usuários de caixa de correio

3

Número de usuários de caixa de correio no site 1

10800

Número de usuários de caixa de correio no site 2

10800

Número de usuários de caixa de correio no site 3

10800

A tabela a seguir resume a distribuição geográfica de datacenters com potencial para suportar a infraestrutura de email do Exchange.

Distribuição geográfica dos data centers

Requisito de site do Datacenter Valor

Número total de datacenters

3

Número de caixas de correio ativas na proximidade de datacenter 1

10800

Número de caixas de correio ativas na proximidade de datacenter 2

10800

Número de caixas de correio ativas na proximidade de datacenter 3

10800

Requisito para Exchange residem em mais de um data center

Sim

Return to top

Também é importante definir os requisitos de proteção de dados e servidores para o ambiente, porque esses requisitos darão apoio às decisões de design sobre alta disponibilidade e resiliência de sites.

A tabela a seguir identifica as necessidades de proteção de servidor.

Requisitos de proteção de servidor

Requisito de proteção do servidor Valor

Número de falhas VM dentro do site ou servidor simultâneo

1

Número de VM falhas durante a falha no local ou servidor simultâneo

0

A tabela a seguir identifica as necessidades de proteção de dados.

Requisitos de proteção de dados

Requisito de proteção de dados Valor ou descrição

Requisito para manutenção de backup dos bancos de dados do Exchange fora do ambiente do Exchange (por exemplo, uma solução de backup de terceiros)

Não

Requisito para manutenção de cópias dos bancos de dados do Exchange dentro do ambiente do Exchange (por exemplo, uma proteção de dados nativa do Exchange)

Sim

Requisito para manter várias cópias de dados de caixa de correio no data center primário

Sim

Requisito para manter várias cópias de dados de caixa de correio em um data center secundário

Não

Requisito para manter uma cópia de qualquer banco de dados do Exchange desfasada

Não

Lag período de cópia em dias

Não se aplica

Número de destino de cópias de bancos de dados

3

Excluídos itens de janela de retenção de pasta em dias

14

Return to top

Esta seção inclui informações que geralmente não são coletadas como parte dos requisitos dos clientes, mas que são essenciais para o design e para a abordagem na validação do design.

Return to top

A tabela a seguir descreve as metas de pico de utilização de CPU para condições normais de operação, e para condições de falha de servidor de site ou manutenção de servidor.

Alvos de utilização do servidor

Assunção de concepção de utilização da CPU do servidor de destino Valor

Normal de funcionamento para servidores de caixa de correio

<70%

Normal de funcionamento para servidores de acesso para cliente

<70%

Normal de funcionamento para servidores de transporte de Hub

<70%

Funcionamento normal para várias funções de servidor (servidores de Acesso para Cliente, Transporte de Hub e Caixa de Correio)

<70%

Normal de funcionamento para várias funções de servidor (servidores de acesso para cliente e transporte de Hub)

<70%

Falha de nó para servidores de caixa de correio

<80%

Falha de nó para servidores de acesso para cliente

<80%

Falha de nó para servidores de transporte de Hub

<80%

Falha de nó para várias funções de servidor (servidores de Acesso para Cliente, Transporte de Hub e Caixa de Correio)

<80%

Falha de nó para várias funções de servidor (servidores de acesso para cliente e transporte de Hub)

<80%

Falha no local para os servidores de caixa de correio

<80%

Falha no local para os servidores de acesso para cliente

<80%

Falha no local para os servidores de transporte de Hub

<80%

Falha de site para várias funções de servidor (servidores de Acesso para Cliente, Transporte de Hub e Caixa de Correio)

<80%

Falha no local para várias funções de servidor (servidores de acesso para cliente e transporte de Hub)

<80%

Return to top

As tabelas a seguir resumem algumas suposições de E/S (entrada/saída) e configuração de dados feitas na criação da configuração do armazenamento.

Suposições de configuração de dados

Assunção de configuração de dados Valor ou descrição

Factor de sobrecarga de dados

20%

Caixa de correio se move por semana

1%

Dedicado manutenção ou restauração número de unidade lógica (LUN)

Não

Espaço livre de LUN

20%

Compressão habilitado de envio de logs

Sim

Faça envio de criptografia ativada

Sim

Suposições de configuração I/O

Assunção de configuração I/O Valor ou descrição

Factor de sobrecarga de I/O

20%

Requisitos adicionais de E/S

Nenhum

Return to top

A seção a seguir fornece uma metodologia passo a passo para desenvolver esta solução. Essa metodologia utiliza as suposições de design e requisitos do cliente e passa pelos pontos essenciais de decisões de design que precisam ser tomadas na criação de um ambiente do Exchange 2010.

Return to top

Ao criar um ambiente do Exchange 2010, muitos pontos de decisões de design para estratégias de alta disponibilidade afetam outros componentes do design. Recomendamos que a definição da estratégia de alta disponibilidade seja a primeira etapa do processo de design. Recomendamos fortemente a análise das seguintes informações antes de dar início a essa etapa:

Se você tiver mais de um datacenter, decida se a infraestrutura do Exchange será implantada em um único datacenter ou se será distribuída por dois ou mais datacenters. Os SLAs (contratos de nível de serviço) de recuperação da organização devem definir o nível de serviço necessário após uma falha de um datacenter principal. Esta informação deve constituir a base para esta decisão.

* Ponto de decisão design *

Nesta solução, existem três locais de data center físico. O SLA declara que a resiliência de datacenter é necessária para todos os serviços de missão crítica, incluindo o email. O design do Exchange 2010 será baseado em uma implantação multissite, com resiliência de site para os dados e o serviço de mensagens.

Nesta etapa, verificamos se todos os usuários de caixa de correio estão localizados principalmente em um site ou se estão distribuídos por muitos sites, e se esses sites estão associados a datacenters. Se estiverem distribuídos por muitos sites e houver datacenters associados a esses sites, será preciso determinar se há um requisito para a manutenção da afinidade entre os usuários de caixa de correio e o datacenter associado a esse site.

* Ponto de decisão design *

Neste exemplo, cada um dos três datacenters está colocalizado em escritórios regionais. Há o desejo de se manter a afinidade entre a localização do usuário e a localização da cópia ativa principal de sua caixa de correio durante condições normais de operação.

Como o cliente decidiu implantar a infraestrutura do Exchange em mais de uma localização física, ele precisa determinar qual modelo de distribuição de banco de dados é mais adequado às necessidades da organização. Existem três modelos de distribuição do banco de dados:

  • Distribuição ativa/passiva   Cópias ativas de banco de dados de caixa de correio são implantadas no datacenter principal e apenas as cópias passivas de banco de dados são implantadas em um datacenter secundário. O datacenter secundário funciona como um datacenter de reserva e nenhuma caixa de correio ativa é hospedada no datacenter em condições normais de operação. Caso haja uma interrupção que afete o datacenter principal, uma alternância manual para o datacenter secundário é realizada e os bancos de dados ativos são hospedados nele até que o datacenter principal volte a ficar online.

    Distribuição de ativo/passivo.

    Distribuição ativa-passiva de banco de dados
  • Distribuição ativa/ativa (DAG único)   Bancos de dados de caixas de correio ativas são implantados no datacenter primário e no datacenter secundário. Uma cópia passiva correspondente está localizada no centro de dados alternativo. Todos os servidores de caixa de correio são membros de um único DAG. Nesse modelo, a conexão WAN (rede de longa distância) entre dois datacenters é um ponto de falha único em potencial. A perda da conexão WAN faz com que os servidores de Caixa de Correio em um dos datacenters entrem em estado de falha devido à perda de quorum.

    Distribuição ativa/ativa (DAG único)

    DAG individual para distribuição ativa-ativa de banco de dados
  • Distribuição ativa/ativa (vários DAGs)   Este modelo utiliza vários DAGs para que a conectividade WAN não seja um ponto único de falha. Um DAG tem cópias ativas de banco de dados no primeiro datacenter e suas cópias passivas de banco de dados correspondentes no datacenter secundário. O segundo DAG tem cópias ativas de banco de dados no segundo datacenter e suas cópias passivas de banco de dados correspondentes no primeiro datacenter. Caso ocorra perda de conectividade WAN, as cópias ativas de cada site continuam proporcionando disponibilidade de banco de dados aos usuário de caixa de correio locais.

    Distribuição ativa/ativa (vários DAGs)

    Distribuição ativa-ativa com vários DAGs

* Ponto de decisão design *

Neste exemplo, como os bancos de dados de caixas de correio ativas serão implantados nas três localizações de datacenter, o modelo de distribuição de datacenter será ativo/ativo com vários DAGs. Há algumas considerações adicionais de design na implantação de um modelo de distribuição ativo/ativo de banco de dados, e vamos tratar deles em uma etapa posterior.

O Exchange 2010 inclui vários recursos novos e alterações importantes que, quando implantados e configurados corretamente, podem oferecer proteção de dados nativa que elimina a necessidade de fazer backups tradicionais de dados. Os backups são tradicionalmente usados para recuperação de desastres, recuperação de itens excluídos acidentalmente, armazenamento de dados a longo prazo e recuperação do banco de dados pontual. O Exchange 2010 pode lidar com todos esses cenários sem a necessidade de backups tradicionais:

  • Recuperação de desastre   Em caso de falha de hardware ou software, várias cópias de banco de dados em um DAG possibilitam alta disponibilidade com failover rápido e sem perda de dados. Os DAGs podem ser estendidos até vários sites e fornecer resiliência diante de falhas no datacenter.

  • Recuperação de itens excluídos acidentalmente   Com a nova pasta Itens Recuperáveis no Exchange 2010 e a diretiva de retenção que pode ser aplicada a ela, é possível reter todos os dados excluídos e modificados durante um período especificado, para que a recuperação desses itens seja mais fácil e rápida. Para obter mais informações, consulte Diretiva e conformidade no envio e recebimento de mensagensInformações sobre itens recuperáveis e Noções Básicas Sobre Marcas e Diretivas de Retenção.

  • Armazenamento de dados a longo prazo , por vezes, backups também servem um propósito arquivamento. A fita costuma ser usada para preservar instantâneos pontuais de dados por longos períodos, segundo os requisitos de conformidade. Os novos recursos de arquivamento, pesquisa em várias caixas de correio e retenção de mensagens do Exchange 2010 fornecem um mecanismo para preservar dados de maneira acessível ao usuário final com eficiência durante longos períodos. Para obter mais informações, consulte Noções Básicas Sobre Arquivos PessoaisNoções Básicas Sobre Pesquisa em Várias Caixas de Correio e Noções Básicas Sobre Marcas e Diretivas de Retenção.

  • Instantâneo de banco de dados pontual   Se uma cópia pontual anterior dos dados de caixa de correio for um requisito para a organização, o Exchange garantirá a capacidade de criação de uma cópia com retardamento em um ambiente de DAG. Isso pode ser útil no raro caso de haver um dano lógico que se replique pelos bancos de dados no DAG, o que resulta em uma necessidade de retornar a um momento anterior. Isso também poderá ser útil se um administrador excluir acidentalmente caixas de correio ou dados do usuário.

Existem motivos técnicos e vários problemas a serem considerados antes do uso dos recursos integrados ao Exchange 2010 em substituição aos backups tradicionais. Antes de tomar essa decisão, consulte Understanding Backup, Restore and Disaster Recovery.

* Ponto de decisão design *

Neste exemplo, com a implementação atual do Exchange, o uso principal da solução de backup tradicional é a recuperação de itens de e-mail excluídos acidentalmente. Oitenta por cento das solicitações de recuperação de itens únicos são para mensagens de um período inferior a quinze dias. Portanto, o período de retenção de itens excluídos será de 14 dias. Como os backups tradicionais de VSS não são exigidos para a restauração de itens únicos e não atendem ao objetivo de tempo de recuperação, os recursos de proteção de dados nativa do Exchange e da pasta Itens Excluídos serão usados como estratégia de resiliência de banco de dados.

A próxima decisão importante ao definir sua estratégia de resiliência de banco de dados é determinar o número de cópias de banco de dados a serem implantadas. É altamente recomendável implantar pelo menos três cópias de um banco de dados de caixa de correio antes de eliminar formas tradicionais de proteção do banco de dados, como backups RAID ou tradicionais baseados em VSS.

Antes de tomar essa decisão, consulte Noções Básicas Sobre Cópias do Banco de Dados de Caixa de Correio.

* Ponto de decisão design *

Neste exemplo, como uma solução tradicional de backup de VSS não está sendo implantada, um mínimo de três cópias de banco de dados serão implantadas para garantir que os requisitos de objetivo de tempo de recuperação e objetivo de ponto de recuperação sejam atendidos. Duas cópias serão colocadas no datacenter principal e uma terceira cópia será colocada em um datacenter alternativo para oferecer resiliência de site.

Existem dois tipos de cópias de banco de dados:

  • Cópia de banco de dados de alta disponibilidade   Cópia de banco de dados configurada com um tempo de retardo de repetição igual a zero. Como o nome sugere, as cópias de banco de dados de alta disponibilidade são mantidas atualizadas pelo sistema, podem ser ativadas automaticamente pelo sistema e são usadas para fornecer alta disponibilidade para os dados e o serviço de caixa de correio.

  • Cópia de banco de dados com retardamento   Cópia de banco de dados configurada para retardar a repetição do log de transações por um período. As cópias de banco de dados com retardamento são projetadas para fornecer proteção em um ponto no tempo e podem ser usadas para recuperação de corrupções de lógica de armazenamento, erros administrativos (por exemplo, exclusão ou limpeza de uma caixa de correio desconectada) e erros de automação (por exemplo, limpeza em grande quantidade de caixas de correio desconectadas).

* Ponto de decisão design *

Neste exemplo, todas as três cópias de banco de dados de caixa de correio serão implantadas como cópias de alta disponibilidade. O SLA não requer uma desfasados cópia dos dados. Como não há histórico de corrupção lógica e nenhum outro aplicativo é usado para manipular dados de mensagens, a cópia com retardamento não é necessária. Só haveria outra necessidade para uma cópia com retardamento: oferecer a capacidade de recuperação de itens únicos excluídos. Mas é muito mais fácil e econômico atender a esse requisito com o recurso de retenção da pasta Itens Excluídos.

Exchange 2010 foi reprojetado para resiliência de caixa de correio. A proteção automática de failover agora é fornecida no nível do banco de dados de caixa de correio, e não no nível do servidor. As cópias ativas e passivas de banco de dados podem ser distribuídas estrategicamente pelos servidores de Caixa de Correio em um DAG. Determinar quantas cópias de banco de dados você planeja ativar por servidor é um aspecto importante para o planejamento de capacidade do Exchange 2010. Diferentes modelos de distribuição de banco de dados podem ser implantados, mas geralmente recomendamos um destes:

  • Design para todas as cópias ativadas   Neste modelo, a função de servidor Caixa de Correio é dimensionada para acomodar a ativação de todas as cópias de banco de dados no servidor. Por exemplo, um servidor de caixa de correio pode hospedar quatro cópias de banco de dados. Em condições normais de operação, o servidor pode ter duas cópias ativas de banco de dados e duas cópias passivas de banco de dados. Em um evento de falha ou manutenção, todas as quatro cópias de banco de dados se tornam ativas no servidor de Caixa de Correio. Essa solução é geralmente implantada em pares. Por exemplo, ao implantar quatro servidores, o primeiro par é composto pelos servidores MBX1 e MBX2, e o segundo pelos servidores MBX3 e MBX4. Além disso, ao projetar para esse modelo, cada servidor de Caixa de Correio deve ser dimensionado para menos de 40% dos recursos disponíveis em condições normais de operação. Em uma implantação com resiliência de site com três cópias de banco de dados e seis servidores, esse modelo pode ser implantado em conjuntos de três servidores, com o terceiro servidor residindo no datacenter secundário. Este modelo oferece um bloco de construção de três servidores para soluções usando um modelo de resiliência de site ativo/passivo.

    O modelo pode ser usado nos cenários a seguir:

    • Configuração multissite ativa/passiva onde os domínios de falha (por exemplo, racks, compartimentos de blades e matrizes de armazenamento) exigem um fácil isolamento das cópias de banco de dados no datacenter principal

    • Configuração multissite ativa/passiva onde o crescimento previsto pode garantir uma fácil adição de unidades lógicas de escala

    • Configurações que não precisam sobreviver à perda simultânea de dois servidores de Caixa de Correio no DAG

    Este modelo exige que os servidores sejam implantados em pares para implantações de site único e em trios para implantações multissite. A tabela a seguir ilustra um layout de banco de dados de exemplo para este modelo.

    Design para todas as cópias ativado

    Estratégia de resiliência do servidor de caixa de correio

    Na tabela anterior, a seguir se aplica:

    • C1 = cópia ativa (valor de preferência de ativação de 1) durante operações normais

    • C2 = cópia passiva (valor de preferência de ativação de 2) durante operações normais

    • C3 = cópia passiva (valor de preferência de ativação de 3) durante o evento de falha do site

  • Design para cenários de falha direcionados   Neste modelo, a função de servidor Caixa de Correio é criada para acomodar a ativação de um subconjunto das cópias de banco de dados no servidor. A quantidade de cópias de banco de dados no subconjunto vai depender do cenário de falha específico para o qual você está criando. O principal objetivo deste design é distribuir igualmente a carga de banco de dados ativo pelos servidores de Caixa de Correio no DAG.

    O modelo deve ser usado nos cenários a seguir:

    • Todas as configurações de site único com três ou mais cópias do banco de dados

    • Configurações que precisam sobreviver à perda simultânea de dois servidores de Caixa de Correio no DAG

    O design de DAG para este modelo exige de 3 a 16 servidores de Caixa de Correio. A tabela a seguir ilustra um layout de banco de dados de exemplo para este modelo.

    Design para cenários de falha direcionados

    Estratégia de resiliência do servidor de caixa de correio

    Na tabela anterior, a seguir se aplica:

    • C1 = cópia ativa (valor de preferência de ativação de 1) durante operações normais

    • C2 = cópia passiva (valor de preferência de ativação de 2) durante operações normais

    • C3 = cópia passiva (valor de preferência de ativação de 3) durante operações normais

* Ponto de decisão design *

Em uma etapa anterior, decidimos implantar um modelo de distribuição ativo/ativo de banco de dados com vários DAGs. Como cada DAG no modelo tem uma configuração ativa/passiva com apenas duas cópias de banco de dados de alta disponibilidade no datacenter principal, uma estratégia de resiliência de servidor de Caixa de Correio com design para todas as cópias que estão sendo ativadas é a melhor opção.

Um DAG é o componente básico da estrutura de alta disponibilidade e resiliência de site integrada ao Exchange 2010. Um DAG é um grupo de até 16 servidores de Caixa de Correio que hospeda um conjunto de bancos de dados replicados e oferece recuperação automática no nível de banco de dados diante de falhas que afetem servidores ou bancos de dados individuais.

Um DAG é um limite para replicação de banco de dados de caixa de correio, failovers e alternâncias de banco de dados e servidor e para um componente interno chamado Active Manager. Active Manager é um componente do Exchange 2010, que gere trocas e failovers. Active Manager é executado em cada servidor em um DAG.

Do ponto de vista do planejamento, você deve tentar minimizar a quantidade de DAGs implantados. Você deve considerar mais do que um DAG se:

  • Você implanta mais de 16 servidores de caixa de correio.

  • Você tem usuários de caixa de correio ativa em vários sites (configuração de site ativo/ativo).

  • Exigem limites administrativos de DAG-nível separados.

  • Você tem servidores de Caixa de Correio em domínios separados. (DAG é domínio vinculado).

* Ponto de decisão design *

Em uma etapa anterior, decidimos implantar um modelo de distribuição ativo/ativo de banco de dados. Um único DAG com usuários de caixa de correio ativa em cada site poderia ser implantado. Porém, caso os membros do DAG de um site percam temporariamente a conectividade com membros do DAG no outro site, o cluster desse site perderá quorum e deixará de funcionar corretamente. Por esse motivo, serão implantados três DAGs. Cada DAG conterá servidores de Caixa de Correio do datacenter principal que hospedará as cópias principais e secundárias de banco de dados. Cada DAG também conterá servidores em um dos datacenters alternativos que hospedarão a terceira cópia de banco de dados. O design resultante é de três DAGs ativos-passivos com cada datacenter hospedando as cópias principais e secundárias de um DAG, além das terceiras cópias de outro DAG.

Nesta etapa, deve-se determinar a quantidade mínima de servidores de Caixa de Correio necessários para suportar o design de DAG. A quantidade pode ser diferente da quantidade de servidores necessários para suportar a carga de trabalho, portanto a decisão final sobre a quantidade de servidores é tomada em uma etapa posterior.

* Ponto de decisão design *

Em uma etapa anterior, decidimos implantar três DAGs ativos/passivos, e projetar uma estratégia de resiliência de servidor para todas as cópias que estão sendo ativadas. Cada DAG tem que ser implantado em incrementos de três servidores (dois no site principal e um em um site alternativo). Como três DAGs foram implantados, a quantidade mínima de servidores necessários para suportar o design de DAG é nove. A solução terá 9, 18 ou 27 servidores, dependendo da quantidade de servidores necessários para suportar a carga de trabalho. A tabela a seguir descreve as configurações possíveis.

Número de servidores de caixa de correio por DAG

Data center principal DAG1 Data center secundário DAG1 Data center principal DAG2 Data center secundário DAG2 Data center principal DAG3 Data center secundário DAG3 Contagem total de servidor de caixa de correio

2

1

2

1

2

1

9

4

2

4

2

4

2

18

6

3

6

3

6

3

27

ObservaçãoObservação:
Em um modelo de DAG com três nós, se os dois nós do datacenter principal forem perdidos, o cluster perderá quorum e a ativação automática. A terceira cópia no datacenter secundário fornecerá a disponibilidade adicional de dados, mas a recuperação do serviço no datacenter secundário será uma operação manual.

Return to top

Muitos fatores influenciam os requisitos de capacidade de armazenamento para a função de servidor caixa de correio. Para obter informações adicionais, recomendamos que você examine Noções Básicas Sobre o Banco de Dados de Caixa de Correio e Fatores de Capacidade de Log.

As etapas a seguir descrevem como calcular os requisitos de capacidade de caixa de correio. Esses requisitos serão usados para decidir quais opções de solução de armazenamento atendem aos requisitos de capacidade. Uma seção posterior trata dos cálculos adicionais necessários para projetar corretamente o layout de armazenamento da plataforma de armazenamento escolhida.

A Microsoft criou uma calculadora de requisitos para a função de servidor Caixa de Correio que faz a maior parte do trabalho por você. Para fazer o download da calculadora, consulte E2010 Mailbox Server Role requisitos calculadora. Para obter mais informações sobre o uso da calculadora, consulte Exchange 2010 Mailbox Server Role Requirements Calculator (em inglês).

Antes de tentar determinar seus requisitos totais de armazenamento, é necessário saber qual será o tamanho da caixa de correio no disco. Uma caixa de correio cheia com cota de 1 GB exige mais do que 1 GB de espaço em disco, porque deve-se levar em conta o limite de proibição de envio/recebimento, a quantidade de mensagens que o usuário envia ou recebe por dia, a janela de retenção da pasta Itens Excluídos (com ou sem registro de versão de calendário e recuperação de item único ativados) e a média de variações diárias de banco de dados por caixa de correio. A caixa de correio do servidor papel requisitos calculadora faz estes cálculos para você. Você também pode usar as seguintes informações para fazer cálculos manualmente.

Os seguintes cálculos são usados para determinar o tamanho em disco da caixa de correio para uma caixa de correio com limite de 2 GB nesta solução:

  • Espaço em branco = 100 mensagens por dia x 75 ÷ 1024 MB = 7,3 MB

  • Dumpster = (100 mensagens por dia x 75 ÷ 1024 MB x 14 dias) + (2,048 MB x 0,012) + (2,048 MB x 0,058) = 246 MB

  • Tamanho de caixa de correio no disco = limite de caixa de correio + espaço + dumpster

    = 2048 + 7.3 + 246

    = 2.301 MB

Nesta etapa, a capacidade de armazenamento de alto nível necessária para todos os bancos de dados de caixa de correio é determinada. A capacidade calculada inclui tamanho do banco de dados, tamanho do índice do catálogo e 20% de espaço livre.

Para determinar a capacidade de armazenamento necessária para todos os bancos de dados, use as seguintes fórmulas:

  • Tamanho do banco de dados = (número de caixas de correio x tamanho de caixa de correio no disco x fator de crescimento de sobrecarga do banco de dados) + (20% de sobrecarga de dados)

    = (32400 × 2301 × 1) + (14910480)

    = 89.462.880 MB

    = 87.366 GB

  • Tamanho do índice de banco de dados = 10% do tamanho do banco de dados

    = 87366 × 0.10

    = 8.737 GB

  • Capacidade de banco de dados total = (tamanho de banco de dados) + (tamanho de índice) ÷ 0,80 para adicionar espaço livre no volume 20%

    = (87366 + 8737) ÷ 0.8

    = 120.128 GB

Para garantir que o servidor de 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. Considerando que essa arquitetura está usando a resiliência da caixa de correio e os recursos de recuperação de item único como arquitetura de backup, a capacidade do log deve alocar três vezes a taxa de geração diária de registro, caso uma cópia com falha não seja reparada em três dias. (Qualquer cópia com falha impede que o truncamento de registro ocorra.) Caso o servidor não torne a ficar online dentro de três dias, você pode querer remover temporariamente a cópia para permitir que o truncamento ocorra.

Para determinar a capacidade de armazenamento necessária para todos os logs de transações, use as seguintes fórmulas:

  • Tamanho dos arquivos de log = (tamanho do arquivo de log × quantidade de logs por caixa de correio por dia × quantidade de dias necessários para substituição de infraestrutura com falhas × quantidade de usuários de caixa de correio) + (1% de sobrecarga de movimentação de caixa de correio)

    = (1 MB × 20 × 4 × 32400) + (32400 × 0,01 × 2048 MB)

    = 3.255.552 MB

    = 3.179 GB

  • Capacidade total de log = tamanho dos arquivos de log ÷ 0,80 para adicionar 20% de espaço livre no volume

    = (3179) ÷ 0.80

    = 3974

A tabela a seguir resume os requisitos de capacidade de armazenamento de alto nível para esta solução. Em uma etapa posterior, essas informações serão usadas para a escolha da solução de armazenamento a ser implantada. Em etapas posteriores, será feita uma análise mais detalhada dos requisitos específicos de armazenamento.

Resumo dos requisitos de capacidade de armazenamento

Requisitos de espaço em disco Valor

Tamanho médio de caixa de correio no disco (MB)

2301

Capacidade de banco de dados necessário (GB)

120128

Capacidade do registo necessário (GB)

3974

Capacidade total necessário (GB)

124102

Capacidade total necessária para três cópias do banco de dados (GB)

372306

Capacidade total necessária para três cópias do banco de dados (terabytes)

364

Capacidade total necessária para cada site (terabytes)

122

Return to top

Ao projetar um ambiente do Exchange, você deve compreender os fatores de desempenho de log e banco de dados. Recomendamos a leitura de Noções Básicas de Banco de Dados e Log de Fatores de Desempenho.

Como essa é uma das principais métricas de E/S transacionais necessárias para dimensionar o armazenamento de forma adequada, você deve entender a quantidade de E/S de banco de dados por segundo (IOPS) consumida por cada usuário de caixa de correio. As operações de E/S sequenciais puras não são faturadas no cálculo de IOPS por servidor de Caixa de Correio porque os subsistemas de armazenamento podem lidar com E/S sequenciais de forma muito mais eficiente do que com as E/S aleatórias. Essas operações incluem manutenção de banco de dados em segundo plano, E/S transacional de log e E/S de replicação de log. Nesta etapa, será calculada a IOPS total necessária para suportar todos os usuários de caixa de correio, desta forma:

  • Estimado IOPS por usuário de caixa de correio = 0,10

  • IOPS total necessária = IOPS por usuário de caixa de correio x quantidade de caixas de correio x fator de sobrecarga de E/S

    = 0.10 × 32400 × 1.2

    = 3888

ObservaçãoObservação:
Para determinar o perfil de IOPS para um perfil de mensagens diferente, consulte a tabela “Cache de banco de dados e IOPS por caixa de correio estimada com base na atividade da mensagem” em Noções Básicas de Banco de Dados e Log de Fatores de Desempenho.

Como esta é uma implantação multissite, é preciso considerar os requisitos de IOPS por site para dimensionar o armazenamento de forma correta para cada site. Em uma etapa anterior, foi decidido que cada site hospedaria as cópias principais e secundárias de banco de dados do DAG principal e a cópia terciária de banco de dados de um DAG alternativo. Nesse modelo, o pior cenário possível seria uma falha em um único site onde 10.800 caixas de correio do DAG principal e 10.800 caixas de correio do DAG alternativo estejam ativas no armazenamento desse site. Use o seguinte cálculo:

  • IOPS total necessária por site = IOPS por usuário de caixa de correio x quantidade de caixas de correio x fator de sobrecarga de E/S

    = 0.10 × 21600 × 1.2

    = 2592

Return to top

O Exchange 2010 inclui melhorias no desempenho, na confiabilidade e na alta disponibilidade que permitem às organizações executar o Exchange em uma ampla variedade de opções de armazenamento.

Ao examinar as opções de armazenamento disponíveis, ser capaz de equilibrar os requisitos de desempenho, capacidade, gerenciabilidade e custos é essencial para a obtenção de uma solução de armazenamento bem-sucedida para o Exchange.

Para obter mais informações sobre a escolha de uma solução de armazenamento para o Exchange 2010, consulte Design do Armazenamento do Servidor de Caixa de Correio.

Return to top

Há uma ampla variedade de opções de armazenamento disponíveis para o Exchange 2010. Para reduzir a lista de opções, determine se é preferível implantar uma solução de armazenamento anexado diretamente (DAS, incluindo o uso de disco local) ou uma solução SAN. Há diversas razões para se optar por um ou outro. Converse com seu fornecedor de armazenamento para determinar qual solução atende aos requisitos de seu negócio e de TCO (custo total de propriedade).

* Ponto de decisão design *

Neste exemplo, uma infraestrutura de SAN é implantada, e a SAN é usada para armazenar todos os dados do ambiente. Uma solução de armazenamento de SAN continuará sendo usada, e serão exploradas opções para a implantação do Exchange 2010.

Return to top

Use as etapas a seguir para escolher uma solução de armazenamento.

Neste exemplo, o armazenamento EMC foi usado por muitos anos, e uma solução de armazenamento EMC será usada para a implantação do Exchange 2010. A EMC Corporation oferece alto desempenho storage arrays como CLARiiON e simétrica.

A família EMC CLARiiON fornece vários níveis de armazenamento, como unidades flash corporativas, Fibre Channel e Serial ATA (SATA), que reduzem os custos porque vários níveis podem ser gerenciados com uma única interface de gerenciamento.

O CLARiiON Virtual Provisioning oferece benefícios que vão além do provisionamento dinâmico tradicional, incluindo gerenciamento simplificado de armazenamento e maior utilização de capacidade. É possível apresentar uma grande quantidade de capacidade a um host e consumir o espaço conforme a necessidade a partir de um pool compartilhado.

O CLARiiON CX4 Series oferece quatro modelos com níveis flexíveis de capacidade, funcionalidade e desempenho. As características de cada modelo são descritas na tabela a seguir.

Recursos CLARiiON CX4 Series

Feature CX4 modelo 120 CX4 modelo 240 CX4 modelo 480 CX4 modelo 960

Discos máximos

120

240

480

960

Processadores de armazenamento

2

2

2

2

Memória física por processador de armazenamento

3 GB

4 GB

8 GB

16 GB

Cache de gravação máximo

600 MB

1,264 GB

4,5 GB

10,764 GB

Máximo de iniciadores por sistema

256

512

512

1024

Hosts de alta disponibilidade

128

256

256

512

Tamanho de fator de forma mínima

6U

6U

6U

9U

Máximo de LUNs padrão

1024

1024

4096

4096

Snapshots do SnapView

Sim

Sim

Sim

Sim

Clones do SnapView

Sim

Sim

Sim

Sim

Cópia de SAN

Sim

Sim

Sim

Sim

MirrorView/S.

Sim

Sim

Sim

Sim

MirrorView/A.

Sim

Sim

Sim

Sim

RecoverPoint/S

Sim

Sim

Sim

Sim

RecoverPoint/A.

Sim

Sim

Sim

Sim

Neste exemplo, discos Fibre Channel de 450 GB e 15.000 RPMs foram selecionados, fornecendo bom desempenho de E/S e capacidade para satisfazer os requisitos iniciais de usuários do Exchange.

ObservaçãoObservação:
Desde a época do teste, os preços dos discos de 600 GB e 10.000 RPMs caíram e também seriam uma boa opção para esta implantação.

Neste exemplo, a solução precisa fornecer 122 terabytes de armazenamento utilizável e 2.592 IOPS. Qualquer opção da tabela anterior atenderá aos requisitos de IOPS, portanto a decisão será baseada nos requisitos de capacidade. O CLARiiON CX4 modelo 240 só fornece aproximadamente 100 terabytes de capacidade utilizável com discos de 450 GB em uma configuração de RAID-5. O EMC CLARiiON CX4 modelo 480 foi selecionado porque fornece a capacidade e o desempenho de E/S necessários para suportar todos os requisitos do Exchange 2010.

Return to top

Dimensionar a memória corretamente é uma etapa importante na criação de um ambiente íntegro do Exchange. Recomendamos a leitura de Noções Básicas Sobre Configurações de Memória e Desempenho do Exchange e Noções Básicas Sobre o Cache do Banco de Dados de Caixa de Correio.

Return to top

O ESE (mecanismo de armazenamento extensível) usa o cache do banco de dados para reduzir operações de E/S. Em geral, quanto maior for o cache do banco de dados disponível, menos E/S será gerada em um servidor de Caixa de Correio do Exchange 2010. No entanto, chega um ponto no qual adicionar cache de banco de dados não traz mais uma redução expressiva de IOPS. Sendo assim, adicionar grandes quantidades de memória física ao seu servidor do Exchange sem determinar a quantidade ideal exigida de cache de banco de dados pode resultar em custos mais altos com benefícios mínimos ao desempenho.

As estimativas de IOPS realizadas em uma etapa anterior presumem uma quantidade mínima de cache de banco de dados por caixa de correio. Essas quantidades mínimas são resumidas na tabela “Estima o IOPS por caixa de correio com base na atividade de mensagens e no cache do banco de dados da caixa de correio” em Noções Básicas Sobre o Cache do Banco de Dados de Caixa de Correio.

A tabela a seguir descreve o cache de banco de dados por usuário para vários perfis de mensagem.

Cache do banco de dados por usuário

Mensagens enviadas ou recebidas por caixa de correio por dia (tamanho médio de mensagem em torno de 75 KB) Cache do banco de dados por usuário (MB)

50

3 MB

100

6 MB

150

9 MB

200

12 MB

Nesta etapa, serão determinados os requisitos de memória de alto nível para todo o ambiente. Em uma etapa posterior, o resultado será usado para determinar a quantidade de memória física necessária para cada servidor de Caixa de Correio. Use o seguinte cálculo:

  • Cache de banco de dados = perfil específico de banco de dados cache x número de usuários de caixa de correio

    = MB 6 × 32400

    = 194.400 MB

    = 190 GB

Return to top

O planejamento de capacidade do servidor de Caixa de Correio mudou significativamente desde as versões anteriores do Exchange, devido ao novo modelo de resiliência de banco de dados de caixa de correio oferecido no Exchange 2010. Para obter mais informações, consulte Planejamento da Capacidade do Processador do Servidor de Caixa de Correio.

Nas etapas seguintes, serão calculados os requisitos de megaciclo de alto nível para cópias ativas e passivas de banco de dados. Esses requisitos serão usados em uma etapa posterior para determinar a quantidade de servidores de Caixa de Correio necessária para suportar a carga de trabalho. Observe que a quantidade de servidores de Caixa de Correio exigida também depende do modelo de resiliência do servidor de Caixa de Correio e do layout de cópia de banco de dados.

O uso de requisitos de megaciclo para determinar a quantidade de usuários de caixa de correio que um servidor de Caixa de Correio do Exchange pode suportar não é uma ciência exata. Diversos fatores podem levar a resultados inesperados de megaciclo em ambientes de teste e produção. Os megaciclos só devem ser usados para determinar a quantidade aproximada de usuários de caixa de correio que um servidor de Caixa de Correio do Exchange pode suportar. É sempre preferível ser conservador em vez de agressivo durante a fase de planejamento de capacidade no processo de design.

Os seguintes cálculos se baseiam em estimativas de megaciclo publicadas, conforme o resumo da tabela seguinte.

Estimativas Megacycle

Mensagens enviadas ou recebidas por caixa de correio por dia Megaciclos por caixa de correio para o banco de dados de caixa de correio ativa Megaciclos por caixa de correio para o banco de dados de caixa de correio passiva remota Megaciclos por caixa de correio para caixa de correio passiva local

50

1

0.1

0.15

100

2

0.2

0.3

150

3

0.3

0.45

200

4

0.4

0.6

Nesta etapa, serão calculados os megaciclos necessários para suportar as cópias ativas de banco de dados, usando:

  • Megaciclos de caixa de correio ativa necessários = perfil específico megaciclos × número de usuários de caixa de correio

    = 2 × 32400

    = 64800

Em um design com três cópias de cada banco de dados, há uma sobrecarga de processador associada ao envio de logs necessários para manter as cópias de banco de dados nos servidores remotos. Essa sobrecarga geralmente é de 10% dos megaciclos da caixa de correio ativa para cada cópia remota sendo atendida. Calcule os requisitos, usando o seguinte:

  • Megaciclos de cópia remota necessários = megaciclos específicos do perfil × quantidade de usuários de caixa de correio x quantidade de cópias remotas

    = 0.1 × 32400 × 2

    = 6480

Em um design com três cópias de cada banco de dados, há uma sobrecarga de processador associada à manutenção das cópias passivas locais de cada banco de dados. Nesta etapa, serão calculados os megaciclos de alto nível necessários para suportar cópias passivas locais de banco de dados. Esses números serão refinados em uma etapa posterior para que correspondam à estratégia de resiliência do servidor e ao layout de cópia de banco de dados. Calcule os requisitos, usando o seguinte:

  • Megaciclos necessários de caixa de correio passiva local = megaciclos específicos do perfil × quantidade de usuários de caixa de correio x quantidade de cópias passivas

    = 0.3 × 32400 × 2

    = 19440

Calcule os requisitos totais, usando o seguinte:

Total de megaciclos necessários = passivo remoto, caixa de correio ativa + local passiva

= 64800 + 6480 + 19440

= 90720

Megaciclos por caixa de correio em média = 90720 ÷ 32400 = 2.8

Return to top

A tabela a seguir resume a quantidade necessária aproximada de cache de banco de dados e megaciclos para esse ambiente. Essas informações serão usadas em etapas posteriores para determinar quais servidores serão implantados na solução.

Requisitos de caixa de correio resumo

Requisitos de CPU da caixa de correio Valor

Total de megaciclos necessários para todo o ambiente

97200

Cache de banco de dados total necessária para todo o ambiente

190 GB

Return to top

Você pode usar as etapas a seguir para determinar o modelo de servidor.

Nesta solução, a plataforma de servidor preferida é o Cisco Unified Computing System, uma plataforma de datacenter que une computação, rede, acesso a armazenamento e virtualização em um sistema criado para reduzir o custo total de propriedade (TCO) e aumentar a flexibilidade. O sistema integra uma malha de rede unificada Ethernet 10 gigabit com baixa latência a servidores de classe empresarial com arquitetura x86. Com uma abordagem de sistemas voltada para arquitetura, tecnologia, parcerias e serviços, o Cisco Unified Computing System otimiza os recursos do datacenter, dimensiona a entrega de serviços e reduz a quantidade de dispositivos que exigem configuração, gerenciamento, energia, resfriamento e cabeamento.

O Cisco Unified Computing System é um sistema de servidor blade composto por quatro componentes de sistema principais. Esses componentes de sistema são a interconexão de malha, o chassi, os extensores de malha (módulos de E/S) e os servidores blade.

Os seguintes modelos de servidor blade são opções possíveis para esta solução.

Opção 1: B200 Blade Server

O Cisco Unified Computing System B200 Blade Server é um servidor blade de meia largura e dois soquetes. O sistema usa dois processadores Intel Xeon série 5500 ou 5600, até 96 GB de memória DDR3, duas unidades de disco SAS opcionais e intercambiáveis com fator forma pequeno e um único conector mezanino para taxa de transferência de E/S de até 20 gigabits por segundo (Gbps). O servidor equilibra simplicidade, desempenho e densidade para virtualização de nível de produção e outras cargas de trabalho principais de datacenter.

Opção 2: B250 Blade Server

O Cisco Unified Computing System B250 Extended Memory Blade Server é um servidor blade de largura inteira e dois soquetes com tecnologia de memória estendida da Cisco. O sistema suporta dois processadores Intel Xeon série 5500 ou 5600, até 384 GB de memória DDR3, duas unidades de disco SAS opcionais e intercambiáveis de fator forma pequeno e duas conexões de mezanino para taxa de transferência de E/S de até 40 Gbps. O servidor aumenta o desempenho e capacidade para virtualização e dataset grandes cargas de trabalho.

Opção 3: B440 Blade Server

O Cisco Unified Computing System B440 Blade Server foi projetado para mover aplicativos empresariais como bancos de dados com muitas transações e grandes conjuntos de dados, programas de ERP (planejamento de recursos empresariais) e DSS (sistemas de suporte a decisões). Movido pelos recursos de desempenho escalável e confiabilidade dos processadores Intel Xeon série 7500, o Cisco Unified Computing System B440 ajuda a ampliar o escopo da virtualização de carga de trabalho e unifica aplicativos independentes de desempenho intensivo em uma infraestrutura simplificada e integrada. O Cisco Unified Computing System B440 suporta até 32 núcleos de processamento e 256 GB de memória principal, com taxa de transferência de E/S combinada de até 40 Gbps.

O Cisco Unified Computing System B200 com processadores Intel Xeon X5570 foi selecionado porque o servidor blade tinha o equilíbrio ideal entre poder de processamento, capacidade de memória e fator forma para esta implantação. A plataforma de servidor com dois soquetes costuma ser uma boa escolha para implantações do Exchange 2010, com base em todos os fatores relevantes, incluindo escalabilidade e custo. O Cisco Unified Computing System B250 suporta uma configuração de memória mais alta e uma taxa de transferência de E/S mais alta, mas isso não é necessário para a solução.

ObservaçãoObservação:
Desde a época do teste, os preços dos discos de 600 GB e 10.000 RPMs caíram e também seriam uma boa opção para esta implantação.

Return to top

Em etapas anteriores, foram calculados os megaciclos necessários para suportar a quantidade de usuários de caixa de correio ativa. Nas etapas seguintes, serão determinados quantos megaciclos disponíveis o processador e o modelo do servidor podem suportar, para determinar a quantidade de caixas de correio ativas que cada servidor pode suportar.

Como os requisitos de megaciclo se baseiam em um modelo de processador e em um servidor de linha de base, será preciso ajustar os megaciclos disponíveis para o servidor em relação à linha de base. Para fazer isso, são usados parâmetros de comparação de desempenho mantidos pela SPEC (Standard Performance Evaluation Corporation). A SPEC é uma corporação sem fins lucrativos formada para estabelecer, manter e endossar um conjunto padronizado de comparações que podem ser aplicadas à mais nova geração de computadores de alto desempenho.

Para ajudar a simplificar o processo de obtenção do valor de comparação de seu servidor e de seu processador, recomendamos o uso da ferramenta Exchange Processor Query. Essa ferramenta automatiza as etapas manuais para determinar o valor de avaliação SPECint 2006 do processador planejado. Para executar essa ferramenta, seu computador deve estar conectado à Internet. A ferramenta usa seu modelo de processador planejado como informação de entrada, e realiza uma consulta ao site da Web da Standard Performance Evaluation Corporation, retornando todos os dados de resultados de testes para o modelo específico de processador. A ferramenta também calcula um valor de classificação SPECint 2006 médio com base na quantidade de processadores que você pretende usar em cada servidor de Caixa de Correio. Use o seguinte cálculo:

  • Processador = Intel X 5570 2,93 GHz (gigahertz)

  • Resultados SPECint_rate2006 valor = 256

  • Resultados SPECint_rate2006 valor por núcleo de processador = 256 ÷ 8

    = 32

Nas etapas anteriores, foram calculados os megaciclos exigidos para todo o ambiente com base em estimativas de megaciclo por caixa de correio. Essas estimativas foram medidas em um sistema de linha de base (HP DL380 G5 x5470 3,33 GHz, 8 núcleos) com valor SPECint_rate2006 igual a 150 (para um servidor com oito núcleos), ou 18,75 por núcleo.

Nesta etapa, é necessário ajustar os megaciclos disponíveis para o servidor e o processador escolhido em relação ao processador de linha de base para que os megaciclos necessários possam ser usados para o planejamento de capacidade.

Para determinar os megaciclos da plataforma Cisco B200-M1 Intel X5570 de 2,93 GHz, utilize as seguintes fórmulas:

  • Megaciclos ajustados por núcleo = (nova plataforma por valor de núcleo) × (hertz por núcleo da plataforma de linha de base) ÷ (linha de base por valor de núcleo)

    = (32 × 3330) ÷ 18.75

    = 5683

  • Ajustado megaciclos por servidor = megaciclos ajustados por núcleo x número de núcleos

    = 5683 × 8

    = 45466

Agora que os megaciclos ajustados por servidor são conhecidos, é necessário fazer o ajuste para a meta de utilização máxima do processador. Em uma seção anterior, a decisão foi de não exceder 80% de utilização do processador durante cargas de trabalho de pico ou cenários de falha. Use o seguinte cálculo:

  • Ajustado megaciclos disponíveis = megaciclos disponíveis por utilização máxima do processador do servidor × alvo

    = 45466 × 0.80

    = 36372

Cada servidor tem uma capacidade útil de 36,372 megaciclos.

Return to top

Você pode usar as etapas a seguir para determinar a quantidade necessária de servidores físicos de Caixa de Correio.

Para determinar a quantidade de caixas de correio ativas suportadas por um servidor de Caixa de Correio, use o seguinte cálculo:

  • Número de caixas de correio ativas = megaciclos disponíveis por de servidor ÷ megaciclos por caixa de correio

    = 36372 ÷ 2.8

    = 12990

Cada DAG tem 10,800 caixas de correio ativas. Para determinar a quantidade mínima necessária de servidores de Caixa de Correio para suportar todas as caixas de correio em um DAG, use o seguinte cálculo:

  • Quantidade necessária de servidores = contagem total de caixas de correio por DAG ÷ caixas de correio ativas por servidor

    = 10800 ÷ 12990

    = 0.83

No mínimo um servidor de Caixa de Correio é necessário para cada DAG para suportar a carga de trabalho de 10.800 caixas de correio.

Em uma etapa anterior, a decisão foi de projetar para todas as cópias que estão sendo ativadas em um DAG ativo/passivo. Este modelo exige que as funções de servidor Caixa de Correio sejam implantadas em grupos de três para cada DAG.

Número de servidores de caixa de correio e DAGs

Data center principal DAG1 Data center secundário DAG1 Data center principal DAG2 Data center secundário DAG2 Data center principal DAG3 Data center secundário DAG3 Contagem total de servidor de caixa de correio

2

1

2

1

2

1

9

4

2

4

2

4

2

18

6

3

6

3

6

3

27

Com base no design de DAG, são necessários no mínimo três servidores de Caixa de Correio físicos em cada DAG ou um total de nove servidores de Caixa de Correio físicos para todos os três DAGs.

Return to top

Use as etapas a seguir para determinar a quantidade de caixas de correio ativas por servidor de Caixa de Correio em cenários de operação normal ou falha.

Para determinar a quantidade de caixas de correio ativas hospedadas por servidor de Caixa de Correio em operação normal, use o seguinte cálculo:

  • Quantidade de caixas de correio por servidor = contagem total de caixas de correio no DAG ÷ quantidade de servidores de Caixa de Correio no datacenter principal

    = 10800 ÷ 2

    = 5400

Se um servidor de Caixa de Correio no datacenter principal falhar, as 5.400 caixas de correio ativas no servidor que falhou se tornarão ativas no servidor que restou. Nesse cenário, o servidor de caixa de correio restante terá 10,800 caixas de correio ativas.

Se o datacenter principal ficar offline, as 10.800 caixas de correio ativas no datacenter principal serão ativadas no datacenter secundário. Nesse cenário, o único servidor no datacenter secundário terá 10.800 caixas de correio ativas.

Return to top

Ao determinar a quantidade de funções de servidor Acesso para Cliente e de funções de servidor Transporte de Hub a implantar em ambientes com quantidades menores de servidores, considere a possibilidade de implantar as duas funções na mesma máquina física. Isso reduz a quantidade de máquinas físicas a gerenciar, a quantidade de sistemas operacionais de servidores a atualizar e manter e a quantidade de licenças do Windows e do Exchange que precisam ser adquiridas. Outro benefício de combinar as funções de servidor Acesso para Cliente e Transporte de Hub é simplificar o processo de design. Ao implantar funções isoladas, recomendamos a implantação de um processador lógico de servidor de Transporte de Hub para cada quatro processadores lógicos de servidor de Caixa de Correio, e a implantação de três processadores lógicos de servidor de Acesso para Cliente para cada quatro processadores lógicos de Caixa de Correio. Isso pode causar confusão, especialmente somado à necessidade de fornecer servidores de Acesso para Cliente e Transporte de Hub suficientes durante cenários de múltiplas falhas de servidores físicos e de manutenção. Ao implantar servidores de Acesso para Cliente e Transporte de Hub em servidores físicos ou VMs, é possível implantar um servidor de Acesso para Cliente e Transporte de Hub de combinação para cada servidor de Caixa de Correio do site.

* Ponto de decisão design *

Nesta solução, a decisão foi colocalizar as funções de servidor Acesso para Cliente e Transporte de Hub na mesma máquina física. Isso reduzirá a quantidade de sistemas operacionais a gerenciar, além de facilitar o planejamento para a resiliência de servidor.

Return to top

Em uma etapa anterior, foi determinado que três servidores de Caixa de Correio eram necessários em cada site (dois servidores de Caixa de Correio do DAG hospedando caixas de correio ativas para esse site e um servidor de Caixa de Correio de um DAG alternativo dando suporte à resiliência de site em caso de falha do datacenter principal desse DAG).

É recomendável implantar um servidor de Acesso para Cliente e Transporte de Hub de combinação para cada servidor de Caixa de Correio, como mostra a tabela a seguir.

Número de físicos servidores de combinação de acesso para cliente e transporte de Hub necessários

Configuração de função do servidor Taxa de núcleo de processador recomendada

Mailbox:Função combinada de servidor Acesso para Cliente e Transporte de Hub

1:1

Quando houver mais de um DAG representado no mesmo site, é necessário examinar o pior cenário de falha para poder determinar a quantidade de servidores de combinação de Acesso para Cliente e Transporte de Hub necessários. Nesta solução, o pior cenário de falha seria perder um dos dois servidores de Caixa de Correio no DAG principal e ter uma falha de site simultânea onde as caixas de correio ativas de outro site agora estejam hospedadas no mesmo site. Nesse caso, haverá 21.600 caixas de correio ativas no site sendo executadas em dois servidores de Caixa de Correio e, portanto, serão necessários pelo menos dois servidores de combinação de Acesso para Cliente e Transporte de Hub em cada site, como mostra a figura a seguir.

Servidores de acesso para cliente e transporte de Hub

tbd

Return to top

Até agora, foi determinado que 15 servidores físicos são necessários para suportar as funções de servidor Caixa de Correio, Transporte de Hub e Acesso para Cliente para 32.400 caixas de correio ativas em três datacenters, como mostrado na figura a seguir.

Número necessário de servidores físicos

tbd

Return to top

Vários fatores são importantes ao considerar a virtualização do servidor para o Exchange. Para obter mais informações sobre as configurações suportadas para virtualização, consulte Requisitos de sistema do Exchange 2010.

Considere o uso de virtualização com Exchange pelas seguintes razões:

  • Caso preveja a subutilização das capacidades do servidor e deseje uma melhor utilização, você pode adquirir menos servidores em decorrência da virtualização.

  • Você pode querer usar o NLB (Balanceamento de Carga de Rede do Windows) ao implantar as funções de servidor Acesso para Cliente, Transporte de Hub e Caixa de Correio no mesmo servidor físico.

  • Caso sua organização esteja utilizando a virtualização em toda a infraestrutura de servidor, você pode querer usar a virtualização com o Exchange para estar de acordo com a política padrão corporativa.

Para determinar se a virtualização deve ser usada nesse ambiente, considere a utilização esperada do processador e determine se a subutilização dos servidores é provável.

Para determinar a utilização da CPU de 5,400 caixas de correio ativas em um único servidor de Caixa de Correio, use o seguinte cálculo:

  • Processador porcentagem (pico normal funcionamento) = megaciclos necessários ÷ disponíveis megaciclos

    = (5400 × 2.8) ÷ 45466

    = 33.2%

Para determinar a utilização da CPU de 10.800 caixas de correio ativas em um único servidor de Caixa de Correio, use o seguinte cálculo:

  • Porcentagem processador (condições de falha do pico) = megaciclos necessários ÷ disponíveis megaciclos

    = (10800 × 2.8) ÷ 45466

    = 66.5%

* Ponto de decisão design *

Como as projeções são de que o servidor fique abaixo de 80% de utilização no pior cenário de falha, pode haver uma oportunidade de redução na contagem de servidores com o uso da virtualização. Isso será explorado mais nas etapas a seguir.

Return to top

Nas etapas a seguir, você irá determinar se a virtualização pode ser usada para reduzir a quantidade de servidores físicos exigidos nesta solução. Microsoft Hyper-V será usado como plataforma de virtualização.

No momento do teste, o Microsoft Hyper-V suportou um máximo de quatro processadores virtuais por VM. No design físico, a função de servidor Caixa de Correio para o DAG principal foi implantada em dois servidores físicos, com um total de 16 processadores lógicos. Ao adicionar a virtualização, a função de servidor Caixa de Correio do DAG principal é implantada em quatro VMs, cada uma com quatro processadores virtuais para um total de 16 processadores virtuais.

No design físico, a função de servidor Caixa de Correio para o DAG alternativo foi implantada em um único servidor físico, com oito processadores lógicos. Ao adicionar a virtualização, a função de servidor Caixa de Correio do DAG alternativo é implantada em duas VMs, cada uma com quatro processadores virtuais para um total de oito processadores virtuais.

No design físico, o servidor de combinação de Acesso para Cliente e Transporte de Hub foi implantado em dois servidores físicos, com um total de 16 processadores lógicos. Ao adicionar a virtualização, os servidores de combinação de Acesso para Cliente e Transporte de Hub são implantados em quatro VMs, cada uma com quatro processadores virtuais para um total de 16 processadores virtuais.

Ao usar servidores raiz do Hyper-V com oito processadores lógicos, uma prática recomendada é implantar uma VM de servidor de Caixa de Correio e uma VM de servidor de combinação de Acesso para Cliente e Transporte de Hub em cada servidor raiz do Hyper-V.

Agora a solução tem 10 VMs sendo executadas em cinco servidores físicos em cada site, como mostra a figura a seguir.

Máquinas virtuais

tbd

Com base nos cálculos de etapas anteriores, foi possível prever que quatro servidores físicos seriam suficientes para atender aos requisitos de megaciclo do pior caso de carga de trabalho. Nesta etapa, a contagem de servidores físicos será reduzida de cinco para quatro, e os servidores de Caixa de Correio do DAG alternativo serão redistribuídos entre os quatro servidores físicos restantes. Para manter a simetria nos quatro servidores físicos, mude as duas VMs de servidor de Caixa de Correio (com quatro processadores virtuais) para quatro VMs de servidor de Caixa de Correio (com dois processadores virtuais).

Isso resulta em 12 VMs sendo executadas em quatro servidores físicos em cada site, como mostram as figuras a seguir.

Máquinas virtuais

tbd

Máquinas virtuais

tbd

Esta etapa cobre a estimativa da quantidade de processadores virtuais exigidos para cada VM. Nas etapas seguintes, cálculos serão realizados para verificar essas suposições.

Cada uma das quatro VMs de servidor de Caixa de Correio no DAG principal suportará 25% das 10.800 caixas de correio ativas no DAG em condições normais de operação, ou 2.700 caixas de correio cada. Caso ocorra uma falha do servidor, a VM de servidor de Caixa de Correio terá que suportar 5.400 caixas de correio ativas.

Caso ocorra uma falha de site, cada uma das quatro VMs de servidor de Caixa de Correio no DAG principal suportará 25% das 10.800 caixas de correio ativas no DAG, ou 2.700 caixas de correio cada. Nesse cenário, as caixas de correio serão executadas na terceira cópia e na cópia final do banco de dados. Caso ocorra uma falha do servidor ou da VM, a VM sobrevivente não terá que suportar 5.400 caixas de correio ativas. O número máximo de caixas de correio será sempre 2.700.

Faz sentido que as VMs no DAG alternativo tenham metade dos processadores virtuais das VMs no DAG principal. Nessa solução, atribua quatro processadores virtuais às VMs no DAG principal e dois processadores virtuais às VMs no DAG alternativo.

Se uma taxa entre processadores lógicos e virtuais de 1:1 for mantida, obtém-se dois processadores virtuais para cada servidor de combinação de Acesso para Cliente e Transporte de Hub. Como é desejável mantar uma taxa de núcleos de servidor de Caixa de Correio de 1:1 para núcleos de servidor de combinação de Acesso para Cliente e Transporte de Hub, atribua quatro processadores virtuais a cada servidor de combinação de Acesso para Cliente e Transporte de Hub. Isso leva a um cenário no qual a quantidade de processadores virtuais excede a quantidade de processadores físicos no servidor raiz. Isso é conhecido como oversubscription. Na maioria das circunstâncias, recomendamos que você não use o excesso de assinatura. No entanto, nessa solução, as VMs de servidor de Caixa de Correio no DAG alternativo só serão usadas durante um evento de falha de site. Porque este é um evento de baixa ocorrência, um ligeiro excesso de assinatura está tudo bem.

A tabela a seguir mostra as alocações propostas processador virtual.

Alocação de processador virtual

Máquina virtual Contagem de processadores virtuais

Combinação de acesso para cliente e transporte de Hub

3

Caixa de correio (DAG primária)

4

Caixa de correio (DAG alternativo)

2

Total

9

Return to top

Em etapas anteriores, foram calculados os megaciclos necessários para suportar a quantidade de usuários de caixa de correio ativa. Nas etapas seguintes, serão determinados quantos megaciclos disponíveis o processador e o modelo do servidor podem suportar, para determinar a quantidade de caixas de correio ativas que cada servidor virtual pode suportar.

Return to top

Ao implantar VMs no servidor raiz, considere os megaciclos necessários para suportar o hipervisor e a pilha de virtualização. Essa sobrecarga varia de servidor para servidor e sob diferentes cargas de trabalho. Uma estimativa conservadora de 10% dos megaciclos disponíveis será usada, como mostra o seguinte cálculo:

  • Ajustado megaciclos disponíveis = megaciclos disponíveis × 0.90

    = 45466 × 0.90

    = 40919

Cada servidor tem uma capacidade utilizável para VMs de 40,919 megaciclos.

A capacidade utilizável por processador lógico é 5,115 megaciclos.

Return to top

Em uma etapa anterior, a alocação de processadores virtuais para os três tipos de VM foi determinada, como mostra a tabela a seguir.

Alocação de processador virtual

Máquina virtual Contagem de processadores virtuais

Combinação de acesso para cliente e transporte de Hub

3

Caixa de correio (DAG primária)

4

Caixa de correio (DAG alternativo)

2

Total

9

Como há nove processadores virtuais em execução em um servidor raiz com oito processadores lógicos, a capacidade de megaciclo de um processador virtual não é igual à capacidade de megaciclo de um processador lógico. Nesta etapa, calcule os megaciclos disponíveis por processador virtual:

  • Megaciclos por processador virtual = megaciclos por processador lógico x (quantidade de processadores lógicos ÷ quantidade de processadores virtuais)

    = 5115 × (8 ÷ 9)

    = 4547

Nesta etapa, para determinar os megaciclos disponíveis por VM, consulte a tabela a seguir.

Megaciclos disponíveis por VM

Máquina virtual Contagem de processadores virtuais Megaciclos por processador virtual Megaciclos disponíveis

Combinação de acesso para cliente e transporte de Hub

3

4547

13641

Caixa de correio (DAG primária)

4

4547

18188

Caixa de correio (DAG alternativo)

2

4547

9094

Como as suposições de design afirmam que não se deve exceder 80% de utilização do processador, ajuste os megaciclos disponíveis para refletir a meta de 80%, como mostra a tabela a seguir.

Destino disponíveis megaciclos por VM

Máquina virtual Megaciclos disponíveis Utilização máxima do processador Destino disponíveis megaciclos

Combinação de acesso para cliente e transporte de Hub

13641

80%

10913

Caixa de correio (DAG primária)

18188

80%

14550

Caixa de correio (DAG alternativo)

9094

80%

7275

Return to top

Para verificar a capacidade da CPU das VMs de servidor de caixa de correio principal, acompanhe as etapas a seguir.

O pior caso de carga de trabalho do servidor de Caixa de Correio principal ocorre durante um cenário de falha ou manutenção de servidor no qual 5.400 caixas de correio estejam ativas no servidor de Caixa de Correio principal e a segunda e a terceira cópias remotas estejam em manutenção (por exemplo, após um evento de recuperação no qual as cópias passivas estejam sendo atualizadas, mas as caixas de correio ativas não tenham sido movidas de volta para o servidor de destino). Nesta etapa, serão determinados os requisitos de megaciclo para a VM de servidor de Caixa de Correio principal, com o seguinte cálculo:

  • Megaciclos de caixa de correio necessários = (quantidade de usuários de caixa de correio x megaciclos específicos do perfil) + quantidade de cópias remotas de banco de dados x (quantidade de usuários de caixa de correio x megaciclos específicos do perfil x 10%)

    = (5400 × 2) + 2 × (5400 × 2 × 0.1)

    = 10800 + 2160

    = 12960

Nesta etapa, vamos determinar se há mais megaciclos disponíveis do que a quantidade exigida. São necessários 12.960 megaciclos e há 14.550 disponíveis, portanto a VM de servidor de Caixa de Correio principal tem capacidade suficiente para suportar 5.400 caixas de correio ativas.

Return to top

Para verificar a capacidade da CPU das VMs de servidor de Caixa de Correio secundária, acompanhe as etapas a seguir.

O pior caso de carga de trabalho do servidor de Caixa de Correio secundária ocorre durante um cenário de falha de site no qual 2.700 caixas de correio estejam ativas no servidor de Caixa de Correio secundária e a segunda e a terceira cópias remotas estejam em manutenção (por exemplo, após o site original voltar a ficar online onde as cópias originais principais e secundárias estejam sendo atualizadas, mas as caixas de correio ativas não tenham sido movidas de volta para o site original). Nesta etapa, serão determinados os requisitos de megaciclo para a VM de servidor de Caixa de Correio secundária, com o seguinte cálculo:

  • Megaciclos de caixa de correio necessários = (quantidade de usuários de caixa de correio x megaciclos específicos do perfil) + quantidade de cópias remotas de banco de dados x (quantidade de usuários de caixa de correio x megaciclos específicos do perfil x 10%)

    = (2700 × 2) + 2 × (2700 × 2 × 0.1)

    = 5400 + 1080

    = 6480

Nesta etapa, vamos determinar se há mais megaciclos disponíveis do que a quantidade exigida. São necessários 6.480 megaciclos e há 7.275 disponíveis, portanto a VM de servidor de Caixa de Correio secundária tem capacidade suficiente para suportar 2.700 caixas de correio ativas.

Return to top

Use as etapas a seguir para determinar a memória exigida por VM de servidor de Caixa de Correio principal.

Em uma etapa anterior, foi determinado que os requisitos de cache de banco de dados para todas as caixas de correio eram de 190 GB, e que o cache médio necessário por caixa de correio ativa era de 6 MB.

Para projetar para o pior cenário de falha, calcule o cache de banco de dados necessário com base em 5.400 caixas de correio ativas nas VMs de servidor de Caixa de Correio restantes:

  • Memória necessária para cache de banco de dados = número de caixas de correio ativas x cache médio por caixa de correio

    = 5400 × 6 MB

    = 32.400 MB

    = 31,6 GB

Nesta etapa, consulte a tabela a seguir para determinar a configuração de memória recomendada.

Requisitos de memória

Memória física do servidor (RAM) Tamanho do cache de banco de dados (apenas função de servidor caixa de correio)

24 GB

17,6 GB

32 GB

24,4 GB

48 GB

39,2 GB

A configuração de memória recomendada para suportar um cache de banco de dados de 31.6 GB para uma função de servidor Caixa de Correio é de 48 GB.

Return to top

Use as etapas a seguir para determinar a memória exigida por VM de servidor de Caixa de Correio secundária.

Em uma etapa anterior, foi determinado que os requisitos de cache de banco de dados para todas as caixas de correio eram de 190 GB, e que o cache médio necessário por caixa de correio ativa era de 6 MB.

Para projetar para o pior cenário de falha, calcule o cache de banco de dados necessário com base em 2.700 caixas de correio ativas residindo nas VMs de servidor de Caixa de Correio secundárias:

  • Memória necessária para cache de banco de dados = número de caixas de correio ativas x cache médio por caixa de correio

    = 2700 × 6 MB

    = 16.200 MB

    = 15,8 GB

Nesta etapa, consulte a tabela a seguir para determinar a configuração de memória recomendada.

Requisitos de memória

Memória física do servidor (RAM) Tamanho do cache de banco de dados (apenas função de servidor caixa de correio) Tamanho do cache de banco de dados (várias funções de servidor, por exemplo, funções de servidor Transporte de Hub e Caixa de Correio)

24 GB

17,6 GB

14 GB

32 GB

24,4 GB

20 GB

48 GB

39,2 GB

32 GB

A configuração de memória recomendada para suportar um cache de banco de dados de 15.8 GB para uma função de servidor Caixa de Correio é de 24 GB.

Return to top

Para determinar a configuração de memória para a VM de servidor de combinação de Acesso para Cliente e Transporte de Hub, consulte a tabela a seguir.

Configurações de memória para servidores Exchange 2010 baseadas em funções de servidor instaladas

Função de servidor Exchange 2010 Mínimo suportado Máximo recomendado

Função combinada de servidor Acesso para Cliente e Transporte de Hub (funções de servidor Acesso para Cliente e Transporte de Hub sendo executadas no mesmo servidor físico)

4 GB

2 GB por núcleo (mínimo de 8 GB)

Como a VM de servidor de combinação de Acesso para Cliente e Transporte de Hub tem três processadores virtuais, 6 GB de memória são alocados para cada VM de servidor de combinação de Acesso para Cliente e Transporte de Hub.

Return to top

Para determinar a memória exigida por servidor raiz do Hyper-V, use o seguinte cálculo:

  • Memória do servidor raiz = memória do sistema operacional raiz + memória da VM de servidor de combinação de Acesso para Cliente e Transporte de Hub + memória da VM de servidor de Caixa de Correio principal + memória da VM de servidor de Caixa de Correio secundária

    = 4 GB + 6 GB + 48 GB + 24 GB.

    = 82 GB

O requisito de memória física para o servidor raiz é 82 GB. Para se alinhar a configurações recomendadas de memória física, o servidor será populado com 96 GB.

Return to top

Em uma etapa anterior, foi determinado que a solução conteria três DAGs, e que cada DAG abrangeria dois dos três locais físicos. Agora que foram determinados quantos servidores de Caixa de Correio são necessários para suportar a carga de trabalho e os requisitos de DAG, prossiga com o design do DAG.

Design de DAG

TBD

Return to top

Use as etapas a seguir para criar layout de cópia do banco de dados.

Para determinar a quantidade ideal de bancos de dados do Exchange a implantar, use a calculadora de requisitos para função de servidor Caixa de Correio do Exchange 2010. Digite as informações apropriadas na guia de entrada e selecione Sim para Calcular automaticamente a quantidade de banco de dados / DAG. Para o campo de limite de tamanho de caixa de correio, use a cota de caixa de correio totalmente provisionada de 2.048 MB.

Bancos de dados do Exchange no DAG

tbd

Sobre o Requisitos da função guia, aparece o número recomendado de bancos de dados. Para esta solução, a calculadora recomenda que cada DAG tenha um mínimo de 24 bancos de dados exclusivos.

* Ponto de decisão design *

Seguindo as recomendações da calculadora, serão implantados 24 bancos de dados por DAG.

Como há 24 bancos de dados exclusivos por DAG e oito servidores no DAG, cada um dos quatro servidores no site principal hospedará seis cópias ativas de banco de dados durante condições normais de operação.

Comece adicionando as cópias ativas de banco de dados aos quatro servidores, como mostra a tabela a seguir.

Layout de banco de dados durante condições normais de funcionamento

Database MBX1 MBX2 MBX3 MBX4

DB1-6

A1

DB7-12

A1

DB13-18

A1

DB19-24

A1

Na tabela anterior, a seguir se aplica:

  • A1 = cópia do banco de dados ativo

Em uma etapa anterior, foi determinado que a estratégia de resiliência do servidor de Caixa de Correio seria projetada para eficiência operacional. Servidores de caixa de correio seriam implantadas em pares.

Como há quatro servidores de Caixa de Correio no DAG, os servidores 1 e 2 serão um par e os servidores 3 e 4 serão um par. Nesta etapa, as cópias passivas de banco de dados (P1) serão adicionadas ao servidor alternativo em cada par, como mostra a tabela a seguir.

Layout de banco de dados durante condições normais de funcionamento com cópias passivas

Database MBX1 MBX2 MBX3 MBX4

DB1-6

A1

P1

DB7-12

P1

A1

DB13-18

A1

P1

DB19-24

P1

A1

Na tabela anterior, a seguir se aplica:

  • A1 = cópia do banco de dados ativo

  • P1 = cópia passiva do banco de dados

Durante um evento de falha ou manutenção do servidor, as cópias P1 são ativadas no servidor alternativo. A tabela a seguir ilustra isso quando MBX2 e MBX4 estão inativas para manutenção.

Layout de cópia do banco de dados durante condições de falha ou manutenção de servidor no site

tbd

Na tabela anterior, a seguir se aplica:

  • A1 = cópia do banco de dados ativo

  • P1 = cópia passiva do banco de dados

Nesta etapa, adicione uma terceira cópia de banco de dados aos membros do DAG no datacenter secundário para oferecer resiliência de site, como mostra a tabela a seguir.

Cópias de banco de dados adicionadas ao data center secundário para oferecer suporte a resiliência de site

Database SiteA MBX1 SiteA MBX2 SiteA MBX3 SiteA MBX4 Site B MBX5 Site B MBX6 Site B MBX7 Site B MBX8

DB1-6

A1

P1

P2

DB7-12

P1

A1

P2

DB13-18

A1

P1

P2

DB19-24

P1

A1

P2

Na tabela anterior, a seguir se aplica:

  • A1 = cópia do banco de dados ativo

  • P1 = cópia passiva de banco de dados local

  • P2 = cópia passiva de banco de dados remoto

Em caso de falha do datacenter principal, as cópias P2 serão ativadas no site secundário, como mostra a tabela a seguir. Observe que até que o site principal volte a ficar online, haverá apenas uma cópia do banco de dados.

Layout de banco de dados durante condições de falha do site

tbd

Na tabela anterior, a seguir se aplica:

  • A1 = cópia do banco de dados ativo

  • P1 = cópia passiva do banco de dados

  • P2 = cópia passiva do banco de dados

Return to top

O modo DAC (Coordenação de Ativação de Datacenter) é usado para controlar o comportamento de ativação de um DAG quando ocorre uma falha catastrófica que afeta o DAG (por exemplo, uma falha completa de um dos datacenters). Quando o modo DAC não está habilitado e ocorre uma falha que afeta vários servidores no DAG, e a maioria dos membros do DAG é restaurada após a falha, o DAG é reiniciado e tenta montar bancos de dados. Em uma configuração com vários datacenters, esse comportamento poderá causar a síndrome do cérebro dividido, uma condição que ocorre quando todas as redes falham, e os membros do DAG não podem receber sinais de pulsação um do outro. A síndrome do cérebro dividido também pode ocorrer quando a conectividade de rede é danificada entre os data centers. A síndrome da divisão é evitada exigindo-se sempre a disponibilidade e a interação da maioria dos membros do DAG (e, no caso dos DAGs com um número par de membros, o servidor testemunha do DAG) para que o DAG esteja operacional. Para obter mais informações, consulte Noções básicas sobre o modo Coordenação de Ativação de Datacenter.

* Ponto de decisão design *

O modo DAC será ativado para todos os três DAGs no ambiente para impedir a ocorrência da síndrome do cérebro dividido.

Return to top

No Exchange 2010, o DAG usa um conjunto mínimo de componentes do clustering de failover do Windows. Um desses componentes é o recurso de quorum, que oferece um meio de arbitragem ao determinar o estado do cluster e tomar decisões de associação. É essencial que cada membro do DAG tenha uma visão consistente de como o cluster subjacente do DAG está configurado. O quorum funciona como o repositório definitivo de todas as informações de configuração relacionadas ao cluster. O quorum também é usado como um desempate para evitar a síndrome do cérebro dividido. A síndrome do cérebro dividido é uma condição que ocorre quando os membros do DAG não conseguem se comunicar entre si, embora estejam disponíveis e operantes. A síndrome do cérebro dividido é evitada exigindo-se sempre a disponibilidade e a interação da maioria dos membros do DAG (e, no caso dos DAGs com um número par de membros, o servidor testemunha do DAG) para que o DAG esteja operacional.

Servidor testemunha é um servidor fora de um DAG que hospeda a testemunha de compartilhamento de arquivos, e que é usado para atingir e manter um quorum quando o DAG tiver um número par de membros. Os DAGs com um número ímpar de membros não usam um servidor testemunha. Na criação de um DAG, a testemunha de compartilhamento de arquivos é adicionada por padrão a um servidor de Transporte de Hub (sem a função de servidor Caixa de Correio instalada) no mesmo site que o primeiro membro do DAG. Se seu servidor de Transporte de Hub estiver em execução em uma VM que resida no mesmo servidor raiz das VMs executando a função de servidor Caixa de Correio, é recomendável mover a localização da testemunha de compartilhamento de arquivos para outro servidor de alta disponibilidade. A testemunha de compartilhamento de arquivos pode ser movida para um controlador de domínio, mas devido às implicações de segurança, faça isso apenas como último recurso.

Em soluções nas quais o DAG compreenda vários sites, é recomendável definir uma testemunha de compartilhamento de arquivos alternativa para o site secundário. Isso permitirá ao cluster manter quorum durante um evento de falha de site com o modo DAC ativado.

* Ponto de decisão design *

Como foi decidida a implantação de três DAGs, e todos os DAGs conterão membros em vários sites, é necessário definir três diretórios testemunha e três diretórios testemunha alternativos. Estes diretórios serão localizados em servidores de arquivos dentro de cada site.

Return to top

Ao planejar a organização do Exchange 2010, uma das decisões mais importante a tomar é como organizar o namespace externo da organização. Um namespace é uma estrutura lógica normalmente representada por um nome de domínio no DNS (Sistema de Nomes de Domínio). Ao definir seu namespace, é preciso considerar os diversos locais de seus clientes e os servidores que hospedam as caixas de correio deles. Além das localizações físicas dos clientes, é preciso avaliar como eles se conectam ao Exchange 2010. As respostas a essas perguntas vão determinar quantos namespaces você deve ter. Seus namespaces normalmente se alinharão a sua configuração DNS. Recomendamos que cada site do Active Directory em uma região que tenha um ou mais servidores de Acesso para Cliente voltados para a Internet tenha um namespace exclusivo. Ele normalmente é representado no DNS por um registro A, como por exemplo, mail.contoso.com ou mail.europe.contoso.com.

Para obter mais informações, consulte Compreendendo Namespaces de Servidor de Acesso para Cliente.

Há várias maneiras de organizar seus namespaces externos, mas geralmente seus requisitos podem ser atendidos com um dos seguintes modelos de namespace:

  • Modelo consolidado datacenter este modelo consiste em um único local físico. Todos os servidores se localizam no site e há um único namespace, como por exemplo, mail.contoso.com.

  • Namespace único com sites proxy   Este modelo consiste em vários sites físicos. Apenas um site contém um servidor de Acesso para Cliente voltado para a Internet. Os outros sites não estão expostos à Internet. Há apenas um namespace para os sites desse modelo, mail.contoso.com.

  • Namespace único e vários sites   Este modelo consiste em vários sites físicos. Cada site pode ter um servidor de Acesso para Cliente voltado para a Internet. Como alternativa, pode haver apenas um site com servidores de Acesso para Cliente voltados para a Internet. Há apenas um namespace para os sites desse modelo, mail.contoso.com.

  • Namespaces regionais   Este modelo consiste em vários sites físicos e vários namespaces. Por exemplo, um site localizado na cidade de Nova York teria o namespace mail.usa.contoso.com, um site localizado em Toronto teria o namespace mail.canada.contoso.com e um site localizado em Londres teria o namespace mail.europe.contoso.com.

  • Várias florestas   Este modelo consiste em várias florestas com vários namespaces. Uma organização com este modelo poderia ser formada por duas empresas parceiras, como Contoso e Fabrikam. Os namespaces podem incluir mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.fabrikam.com e mail.europe.fabrikam.com.

* Ponto de decisão design *

Para este cenário, o modelo de namespaces regionais foi selecionado porque é o mais apropriado para organizações com caixas de correio ativas em vários sites.

A vantagem deste modelo é a redução do uso de proxies, visto que uma porcentagem maior dos usuários poderão se conectar a um servidor de Acesso para Cliente no mesmo site do Active Directory que seu servidor de Caixa de Correio. Isso melhorará a experiência do usuário final e o desempenho. Usuários que possuam caixas de correio em um site sem um servidor de Acesso para Cliente voltado para a Internet usarão proxy.

Esta solução também tem os seguintes requisitos de configuração:

  • É necessário gerenciar vários registros DNS.

  • É necessário obter, configurar e gerenciar vários certificados.

  • O gerenciamento da segurança é mas complexo, porque cada site voltado para a Internet requer um computador com o Microsoft Forefront Threat Management Gateway ou outra solução de proxy reverso ou firewall.

  • Os usuários precisam se conectar aos seus próprios namespaces regionais. Isso pode resultar em mais chamados de suporte e treinamento.

Return to top

No Exchange 2010, o serviço de Acesso para Cliente do RPC e o serviço de Catálogo de Endereços do Exchange foram introduzidos na função de servidor Acesso para Cliente para aprimorar a experiência dos usuários de caixa de correio quando a cópia ativa de banco de dados de caixa de correio for movida para outro servidor de Caixa de Correio (por exemplo, durante falhas de banco de dados de caixa de correio e eventos de manutenção). Os pontos de extremidade da conexão para acesso de caixa de correio a partir do Microsoft Outlook e de outros clientes MAPI foram movidos da função de servidor Caixa de Correio para a função de servidor Acesso para Cliente. Portanto, tanto as conexões internas quanto externas do Outlook agora precisam passar por balanceamento de carga em todos os servidores de Acesso para Cliente do site para que alcancem tolerância a falhas. Para associar o ponto de extremidade MAPI a um grupo de servidores de Acesso para Cliente em vez de a um servidor de Acesso para Cliente específico, você pode definir uma matriz de servidores de Acesso para Cliente. Você só pode configurar uma matriz por site do Active Directory, e uma matriz não pode compreender mais de um site do Active Directory. Para obter mais informações, consulte Noções Básicas Sobre o Acesso para Cliente RPC e Understanding Load Balancing in Exchange.

* Ponto de decisão design *

Como esta é uma implantação de três sites com quatro servidores executando a função de servidor Acesso para Cliente em cada site, haverá um total de três matrizes de servidor de Acesso para Cliente. Uma solução de balanceamento de carga de hardware será usada para distribuir a carga pelas matrizes de servidor de Acesso para Cliente em cada site.

Return to top

Use as etapas a seguir para determinar uma modelo de balanceamento de carga de hardware.

Neste exemplo, o fornecedor preferido é a Cisco, porque a linha de produtos ACE (Cisco Application Control Engine) opera com o Cisco Unified Computing System selecionado para os componentes de servidor, rede e conectividade de armazenamento da solução.

A linha de produtos Cisco ACE proporciona uma solução de datacenter expansível e altamente disponível da qual o ambiente de aplicativos do Exchange 2010 pode se beneficiar. Cisco ACE produtos oferecem interoperabilidade, com as seguintes vantagens:

  • Desempenho, escalabilidade, throughput e a disponibilidade dos aplicativos

  • Design baseado em padrões

  • Arquitetura virtual com dispositivo de particionamento

  • Administração baseada em função e gerenciamento centralizado

  • Serviços de segurança por meio de inspeção profunda de pacotes, listas de controle de acesso (ACLs), encaminhamento invertido de unicast e conversão de endereços de rede (NAT)/conversão de endereços de porta.

A linha de produtos Cisco ACE inclui dois modelos de balanceamento de carga de hardware diferentes que atendem às necessidades da solução de datacenter altamente disponível e expansível apropriada para o ambiente de aplicativos do Exchange 2010. São eles o aparelho Cisco ACE 4710 e o módulo de serviço integrado nas plataformas de roteamento Cisco Catalyst 6500/Cisco 7600.

O aparelho Cisco ACE 4710 oferece taxa de transferência de até 4 Gbps em um fator forma de 1RU (uma unidade de rack), atualizável por meio de licenças de software, oferecendo escalabilidade e proteção para os investimentos a longo prazo. Em sua base, o 4710 é um chassi de rack 1U com uma placa aceleradora Cavium Nitrox Octeon, oferecendo quatro portas Ethernet gigabit que podem ser agrupadas com o uso do Cisco EtherChannel e conectadas a um comutador. Por padrão, o Cisco ACE 4710 suporta virtualização com um dispositivo de administrador e cinco dispositivos de usuários, largura de banda de 1 Gbps, 1.000 transações de protocolo SSL por segundo e 100 megabits por segundo (Mbps) de compactação. A solução pode ser expandida sem a necessidade de novos equipamentos, por meio das seguintes atualizações de licença de software:

  • Taxa de transferência   A taxa de transferência padrão de 1 Gbps pode ser aumentada para 2 ou 4 Gbps.

  • Dispositivos virtuais   A quantidade de dispositivos virtuais pode ser aumentada de 5 para 20.

  • Transações de protocolo SSL por segundo   O valor de transações de protocolo SSL por segundo pode ser aumentado de 1.000 para 5.000 ou 7.000.

  • Compactação   A compactação pode ter sua taxa de transferência aumentada para 500 Mbps, 1 Gbps ou 2 Gbps.

  • Controle de acesso baseado em função   O gerenciamento centralizado baseado em função é oferecido pela interface gráfica do Application Network Manager ou pela interface de linha de comando (CLI).

  • Alta disponibilidade não há suporte para configurações redundantes (dispositivo intra e inter-context).

O módulo Cisco ACE para comutadores Cisco Catalyst 6500 Series ou roteadores Cisco 7600 Series oferece até 16 Gbps de taxa de transferência em um fator forma de módulo com um slot, e assim como o aparelho ACE 4710, pode ser atualizado por meio de licenças de software. Até quatro módulos Cisco ACE podem ser instalados em um único comutador Cisco Catalyst 6500 Series ou roteador Cisco 7600 Series. Cada um pode suportar os processos comerciais de várias unidades independentes de negócios, tirando proveito da vasta gama de opções de conectividade disponíveis para o comutador ou roteador. O administrador do sistema determina os requisitos de aplicativo e atribui os serviços de rede apropriados como contextos virtuais. Cada contexto contém seu próprio conjunto de políticas, interfaces, recursos e administradores:

  • Taxa de transferência   Os serviços de balanceamento de carga oferecem até 16 Gbps de capacidade de taxa de transferência e 345.000 conexões de camada 4 por segundo.

  • Dispositivos virtuais   A quantidade de dispositivos virtuais pode ser aumentada de 5 para 250.

  • Transações de protocolo SSL por segundo   As transações de protocolo SSL por segundo podem ser aumentadas para 15.000 sessões de SSL por meio de licenciamento em módulos ACE20 e para 30.000 em módulos ACE30.

  • Compressão compactação pode ser aumentada para 6 Gbps em módulos de ACE30.

  • Controle de acesso baseado em função   O gerenciamento centralizado baseado em função é oferecido pela interface gráfica do Application Network Manager ou pela interface de linha de comando (CLI).

  • Alta disponibilidade   Não há suporte para configurações redundantes (intrachassi, interchassi e intercontexto).

O aparelho Cisco ACE 4710 foi selecionado porque oferece disponibilidade de aplicativos maximizada, segurança abrangente de aplicativos, arquitetura virtualizada e valor e proteção do investimento:

  • Disponibilidade de aplicativos maximizada   O Cisco ACE 4710 ajuda a garantir a continuidade dos negócios e o serviço aos usuários finais, aprimorando a disponibilidade por meio de balanceamento de carga de camada 4 e alternância de conteúdo de camada 7, o que também minimiza os efeitos de falhas de aplicativos ou dispositivos.

  • Segurança abrangente de aplicativos   O Cisco ACE 4710 age como uma última linha de defesa para o servidor, oferecendo proteção contra ameaças a aplicativos e ataques de negação de serviço (DoS) com recursos como inspeção profunda de pacotes, segurança de rede e protocolo e recursos de controle de acesso altamente expansíveis.

  • Arquitetura virtualizada   A arquitetura virtualizada é um elemento principal do design do Cisco ACE e uma proposição de venda única em contraste a outras soluções no mercado. Os gerentes de TI podem configurar até 20 dispositivos virtuais em um único aparelho Cisco ACE 4710. As vantagens são uma menor quantidade de dispositivos para gerenciar enquanto as implantações de aplicativos aumentam, uso de energia e gastos com resfriamento sensivelmente menores e um tempo para serviço mais rápido para novos aplicativos.

Return to top

Uma solução de armazenamento bem projetada é um aspecto essencial de uma implantação bem-sucedida da função de servidor Caixa de Correio do Exchange 2010. Para obter mais informações, consulte Design do Armazenamento do Servidor de Caixa de Correio.

A tabela a seguir resume os requisitos de armazenamento que foram calculados ou determinados em uma etapa anterior do design.

Resumo dos requisitos de espaço em disco

Requisitos de espaço em disco Valor

Tamanho de caixa de correio no disco para uma caixa de correio de 2 GB (MB)

2301

Capacidade de banco de dados total necessário (GB)

120128

Capacidade do registo total necessário (GB)

3974

Capacidade total necessário (GB)

124102

Capacidade total necessária para três cópias do banco de dados (GB)

372306

Capacidade total necessária para três cópias do banco de dados (terabytes)

364

Capacidade total necessária por local (terabytes)

122

Muitos clientes querem aumentar expressivamente suas cotas de caixa de correio ao migrar para o Exchange 2010. No entanto, pode demorar algum tempo para que os tamanhos de caixa de correio cresçam de várias centenas de megabytes para vários gigabytes. Nesse caso, pode ser útil para algumas organizações adiar as compras de armazenamento adicional até algum momento futuro, quando o espaço de armazenamento em disco deve custar mais barato.

Muitos fornecedores de armazenamento oferecem algum tipo de solução de provisionamento dinâmico para que seja possível apresentar ao servidor do Exchange mais capacidade de armazenamento do que está disponível fisicamente, e em seguida adicionar dinamicamente armazenamento físico para atender ao crescimento da demanda sem interrupções ou tempo de inatividade. Isso reduz o TCO por meio da redução da alocação inicial de capacidade de armazenamento e simplifica o gerenciamento, reduzindo as etapas necessárias para dar suporte ao crescimento.

A implementação de provisionamento dinâmico do armazenamento unificado EMC é fornecida por seu recurso de provisionamento virtual, que suporta modo de espera ativo, modo de espera proativo, expansão de pool dinâmico sem interrupções e a capacidade de migrar entre LUNs dinâmicos e LUNs tradicionais não dinâmicos sem tempo de inatividade. Essa flexibilidade separa o provisionamento virtual de armazenamento unificado EMC das implementações típicas de provisionamento dinâmico.

* Ponto de decisão design *

A atual implementação do Exchange tem uma cota definida de caixa de correio de 200 MB. Depois da migração para o Exchange 2010, estima-se que os tamanhos de caixa de correio cresçam aproximadamente 300% nos primeiros 12 a 18 meses. O plano é adquirir armazenamento suficiente para acomodar um tamanho médio de caixa de correio de 600 MB. Ao longo da vida da implementação do Exchange 2010, o tamanho médio de caixa de correio deve se aproximar dos 2 GB. Como é caro pagar por cotas de caixa de correio de 2 GB, o provisionamento dinâmico será implementado, de modo que uma cota inicial de caixa de correio de 600 MB possa ser implantada. O armazenamento físico subjacente será expandido nos ciclos orçamentários subsequentes para atender à demanda prevista.

Ao utilizar o provisionamento dinâmico no armazenamento unificado de EMC para implantações do Exchange 2010, uma prática recomendada é separar os arquivos de log dos arquivos de banco de dados. Caso preveja o crescimento do tamanho das caixas de correio mas não do perfil de mensagens (mensagens enviadas/recebidas por dia), você terá que aumentar de forma incremental os LUNs de banco de dados, mas não os LUNs de log. Pode ser útil posicionar os logs em LUNs com provisionamento dinâmico.

A separação dos LUNs de banco de dados e log também oferece a flexibilidade de posicioná-los em tipos diferentes de disco ou de utilizar níveis diferentes de RAID.

* Ponto de decisão design *

Seguindo uma prática recomendada de EMC, os bancos de dados e logs serão separados em LUNs diferentes. Como espera-se que o perfil de mensagens permaneça praticamente constante nos próximos três anos, não há vantagens em posicionar logs em LUNs com provisionamento dinâmico.

Como os backups e restaurações baseados em VSS operam no nível do LUN, a quantidade de bancos de dados por LUN geralmente é determinada pela estratégia de backup. Em uma etapa anterior, decidimos não incluir backups baseados em VSS como parte da estratégia de resiliência de banco de dados. A decisão sobre a quantidade de bancos de dados por LUN será baseada em outros fatores. Como prática recomendada, geralmente recomenda-se implantar um único banco de dados por LUN. Ter mais de um banco de dados por LUN pode resultar no seguinte:

  • Um banco de dados sobrecarregado afetar um banco de dados saudável

  • Uma operação de propagação em um banco de dados afetar um banco de dados saudável

  • I/O passiva do banco de dados, afetar a bancos de dados ativos

* Ponto de decisão design *

Como não há requisitos à implantação de mais de um banco de dados por LUN, o design de armazenamento será baseado em um modelo de apenas um banco de dados por LUN.

Em uma etapa anterior, identificamos que cada servidor de Caixa de Correio principal suportaria seis bancos de dados ativos e seis bancos de dados passivos. Haverá um total de 24 LUNs para cada servidor de Caixa de Correio de datacenter principal, conforme indica a tabela seguinte.

Número de LUNs exigido por servidor de caixa de correio

Tipos de LUN LUNs por servidor

Banco de dados ativo LUNs

6

Log ativo LUNs

6

Banco de dados passivo LUNs

6

Log passiva de LUNs

6

Total de LUNS

24

Em uma etapa anterior, identificamos que cada servidor de Caixa de Correio secundária suportaria seis bancos de dados passivos. Haverá um total de 12 LUNs para cada servidor de Caixa de Correio de datacenter secundário, conforme indica a tabela seguinte.

Número de LUNs exigido por servidor de caixa de correio

Tipos de LUN LUNs por servidor

Banco de dados passivo LUNs

6

Log passiva de LUNs

6

Total de LUNS

12

Para simplificar as demais etapas de design do armazenamento, adote uma abordagem de bloco de construção. Nesta solução, cada banco de dados oferece suporte a caixas de correio ativas 450. Cada servidor de Caixa de Correio suporta 6 bancos de dados ou 2.700 caixas de correio ativas em 6 LUNs de banco de dados e 6 LUNs de log. Um bloco de construção de 12 LUNs com suporte a incrementos de 2.700 caixas de correio será usado.

Nesta etapa, será calculada a IOPS transacional necessária para suportar os 2.700 usuários de caixa de correio ativa no bloco de construção. Em uma etapa subsequente, os requisitos de IOPS serão usados para determinar as quantidades mínimas e máximas de fusos a implantar para o bloco de construção com base na cota de caixa de correio inicial e totalmente provisionada. Use o seguinte cálculo:

  • IOPS transacional total necessária para bloco de construção = IOPS por usuário de caixa de correio x quantidade de caixas de correio x fator de sobrecarga de E/S

    = 0.10 × 2700 × 20%

    = 324 IOPS

Em uma etapa anterior, o tamanho de caixa de correio em disco para um limite de cota de caixa de correio de 2.048 MB foi calculado em 2.301 MB. Como o provisionamento dinâmico será usado, calcule o tamanho inicial da caixa de correio no disco. Esse valor será usado em etapas posteriores para determinar os requisitos iniciais de capacidade.

Os seguintes cálculos são usados para determinar o tamanho inicial em disco da caixa de correio para esta solução baseada em uma cota de caixa de correio de 600 MB:

  • Espaço em branco = 100 mensagens por dia x 75 ÷ 1024 MB = 7,3 MB

  • Dumpster = (100 mensagens por dia x 75 ÷ 1024 MB x 14 dias) + (600 MB x 0,012) + (600 MB x 0,058) = 144,2 MB

  • Tamanho de caixa de correio no disco = limite de caixa de correio + espaço + dumpster

    = 600 MB + 7,3 MB + 144.2 MB.

    = 752 MB

Para determinar a capacidade inicial de armazenamento para 2.700 caixas de correio com uma cota inicial de caixa de correio de 600 MB, use os seguintes cálculos:

  • Capacidade de arquivos de banco de dados = (número de caixas de correio x tamanho de caixa de correio no disco x fator de crescimento de sobrecarga do banco de dados) + (20% de sobrecarga de dados)

    = (2700 × 752 × 1) + (406080)

    = 2.436.480 MB

    = 2.379 GB

  • Capacidade de catálogo de banco de dados = 10% da capacidade de arquivos de banco de dados

    = 238 GB

  • Capacidade de banco de dados total = (tamanho de arquivos de banco de dados) + (tamanho de índice) ÷ 0,80 para oferecer 20% de espaço livre no volume

    = (2379 + 238) ÷ 0.8

    = 3.271 GB

Os seis bancos de dados no bloco de construção exigem 3,271 GB de capacidade de armazenamento inicial.

Para determinar a capacidade de armazenamento totalmente provisionado exigido para 2.700 caixas de correio com uma cota de caixa de correio de 2.048 MB, use os seguintes cálculos:

  • Capacidade de arquivos de banco de dados = (número de caixas de correio x tamanho de caixa de correio no disco x fator de crescimento de sobrecarga do banco de dados) + (20% de sobrecarga de dados)

    = (2700 × 2301 × 1) + (1242540)

    = 7.455.240 MB

    = 7.281 GB

  • Capacidade de catálogo de banco de dados = 10% da capacidade de arquivos de banco de dados

    = 728 GB

  • Capacidade de banco de dados total = (tamanho de arquivos de banco de dados) + (tamanho de índice) ÷ 0,80 para oferecer 20% de espaço livre no volume

    = (7281 + 728) ÷ 0.8

    = 10.011 GB

Os seis bancos de dados no bloco de construção exigem 10.011 GB de capacidade de armazenamento totalmente provisionado.

Para determinar a capacidade de armazenamento de log exigido para 2.700 caixas de correio no bloco de construção, use os seguintes cálculos:

  • Capacidade exigida de log de bloco de construção = quantidade de usuários de caixa de correio x quantidade de logs por caixa de correio por dia x tamanho do log x (quantidade de dias necessários para substituição da infraestrutura que falhou) + (porcentagem de sobrecarga de movimentação de caixa de correio)

    = (2700 × 20 × 1024 × 4) + (2700 × 0.01 × 2048)

    = 216.054 MB

    = 211 GB

  • Total capacidade de log = log capacidade ÷ 0,80 para dar espaço livre no volume 20%

    = 211 ÷ 0.80

    = 264

Os seis conjuntos de logs no bloco de construção exigem 264 GB de capacidade de armazenamento.

ObservaçãoObservação:
Como os volumes de log não têm provisionamento dinâmico, a capacidade de armazenamento calculada representa os requisitos de capacidade de log de um ambiente totalmente provisionado.

Nesta etapa, determine o número de eixos necessários para suportar os requisitos de IOPS. Na próxima etapa, será determinada a contagem de eixos que atende aos requisitos de capacidade.

Em uma etapa anterior, foi determinado que a IOPS necessária para suportar o bloco de construção de 2.700 caixas de correio era igual a 324. Nesta etapa, calcule a quantidade de discos necessários para atender aos requisitos de IOPS, usando o seguinte cálculo:

  • Contagem de discos = (IOPS de usuário x taxa de leitura) + penalidade de escrita (IOPS de usuário x taxa de escrita) ÷ capacidade de IOPS do tipo de disco escolhido

    = (324 × 0.6) + 4 × (324 × 0.4) ÷ 155

    = 4.6

Os requisitos de IOPS podem ser atendidos por cinco discos em uma configuração de RAID-5.

ObservaçãoObservação:
Esses cálculos são específicos para esta solução EMC. Consulte seu fornecedor de armazenamento para obter orientações sobre os requisitos de eixo para a solução de armazenamento escolhida.

Em uma etapa anterior, foi determinado que o bloco de construção de 2.700 caixas de correio de uma caixa de correio provisionada inicialmente com 600 MB exigia uma capacidade de armazenamento de 3,271 GB. A capacidade utilizável por um eixo de 450 GB em uma configuração de RAID-5 no CX4 modelo 480 é de aproximadamente 402 GB. Para determinar o número de discos necessários, use o seguinte cálculo:

  • Contagem de disco = (total capacidade necessária) ÷ (capacidade utilizável por eixo com RAID-5)

    = 3271 GB ÷ 402 GB

    = 8.1

Os requisitos de capacidade do banco de dados inicial podem ser atendidos com nove discos.

As práticas recomendadas da EMC para a implantação de armazenamento no armazenamento unificado da EMC usando provisionamento dinâmico consistem em configurar pools dinâmicos de RAID-5 em uma quantidade de discos que seja múltipla de cinco. Reserve dez discos para um bloco de construção de 2.700 caixas de correio. Assim haverá espaço para crescimento futuro.

Em uma etapa anterior, foi determinado que o bloco de construção de 2.700 caixas de correio de uma caixa de correio provisionada inicialmente com 2.048 MB exigia uma capacidade de armazenamento de 10.011 GB. A capacidade utilizável por um eixo de 450 GB em uma configuração de RAID-5 no CX4 modelo 480 é de aproximadamente 402 GB. Para determinar o número de discos necessários, use o seguinte cálculo:

  • Contagem de disco = (total capacidade necessária) ÷ (capacidade utilizável por eixo com RAID-5)

    = 10,011 GB ÷ 402 GB

    = 24.9

Os requisitos de capacidade de banco de dados totalmente provisionado podem ser atendidos com 25 discos.

Em uma etapa anterior, foi determinado que o bloco de construção de 2.700 caixas de correio exigia uma capacidade de armazenamento de log de 264 GB. O uso de duas unidades de 450 GB em uma configuração de RAID-1/0 em um CX4-480 proporciona 402 GB de capacidade de armazenamento utilizável. A configuração proposta de dois discos atende aos requisitos de capacidade de log do bloco de construção de 2.700 caixas de correio.

Agora que a quantidade de eixos necessária para suportar os requisitos de IOPS e de capacidade do bloco de construção foi determinada, é preciso determinar a melhor maneira de provisionar LUNs na matriz para esse bloco de construção ao usar provisionamento dinâmico ou virtual.

Há três modelos principais que podem ser usados durante a criação de pools dinâmicos para uso com o Exchange:

  • Pool de armazenamento único   Um grande pool de armazenamento para todos os logs e bancos de dados do Exchange é o método mais simples, e oferece a melhor utilização do espaço. No entanto, um único pool dinâmico não é recomendado quando várias cópias do mesmo banco de dados estão localizadas na mesma matriz física.

  • Um pool de armazenamento por servidor   Um pool de armazenamento para cada servidor de Caixa de Correio do Exchange proporciona maior detalhamento ao implantar LUNs na matriz. Se projetado corretamente, ele proporciona o isolamento das cópias de bancos de dados em conjuntos separados de eixos e pode minimizar quaisquer problemas de contenção de discos que possam surgir durante atividades como seeding/reseeding, backup e manutenção online (manutenção de banco de dados em segundo plano). Porém, dependendo da quantidade de servidores de Caixa de Correio que você possuir, esse modelo pode resultar em muitos pools dinâmicos, que podem ser mais difíceis de gerenciar.

  • Um pool de armazenamento por cópia de banco de dados   Um pool de armazenamento por cópia de banco de dados garante que cada cópia seja isolada em um conjunto diferente de eixos na matriz. Como a maioria das organizações implanta entre duas e quatro cópias de bancos de dados, a quantidade de pools dinâmicos é mantida em um número gerenciável. Nesse modelo, vários servidores de Caixa de Correio têm LUNs de banco de dados no mesmo pool dinâmico. É possível que atividades como seeding/reseeding, backup e manutenção on-line (manutenção de banco de dados em segundo plano) em um servidor de Caixa de Correio afetem o desempenho em outro servidor de Caixa de Correio.

* Ponto de decisão design *

Embora os benefícios do modelo de um pool de armazenamento por servidor sejam atraentes, isso levaria a oito pools dinâmicos em cada site, em um total de 24 pools dinâmicos. Para manter as coisas simples, o modelo de um pool de armazenamento por cópia de banco de dados será usado, resultando em três pools dinâmicos em cada site e garantindo que cada cópia de banco de dados resida em um conjunto exclusivo de eixos. Isso também garante que o isolamento de eixo de cópia de banco de dados seja mantido em qualquer evento no qual seja necessário adicionar armazenamento para acomodar o crescimento.

O primeiro pool dinâmico conterá um bloco de construção de 2.700 caixas de correio de cada um dos quatro servidores de Caixa de Correio de datacenter principal do site. Em uma etapa anterior, foi determinado que dez eixos eram necessários para suportar os requisitos de IOPS e capacidade do bloco de construção. O primeiro pool thin suporte a caixas de correio ativas 10,800 exigirá 40 eixos.

O segundo pool dinâmico também conterá um bloco de construção de 2.700 caixas de correio de cada um dos quatro servidores de Caixa de Correio do datacenter principal do site. O segundo pool thin suporte a caixas de Correio passivas 10,800 exigirá 40 eixos.

O terceiro pool dinâmico também conterá um bloco de construção de 2.700 caixas de correio de cada um dos quatro servidores de Caixa de Correio do datacenter secundário do site (os servidores de um DAG alternativo que suportam as cópias de bancos de dados resilientes do site). O terceiro pool thin suporte a caixas de Correio passivas 10,800 exigirá 40 eixos.

Um total de 120 eixos por site são necessários para suportar os requisitos iniciais de capacidade de banco de dados.

O primeiro pool dinâmico conterá um bloco de construção de 2.700 caixas de correio de cada um dos quatro servidores de Caixa de Correio de datacenter principal do site. Em uma etapa anterior, foi determinado que 25 eixos eram necessários para suportar os requisitos de IOPS e capacidade totalmente provisionada do bloco de construção. O primeiro pool thin suporte a caixas de correio ativas 10,800 exigirá 100 eixos.

O segundo pool dinâmico também conterá um bloco de construção de 2.700 caixas de correio de cada um dos quatro servidores de Caixa de Correio do datacenter principal do site. O segundo pool thin suporte a caixas de Correio passivas 10,800 exigirá 100 eixos.

O terceiro pool dinâmico também conterá um bloco de construção de 2.700 caixas de correio de cada um dos quatro servidores de Caixa de Correio do datacenter secundário do site (os servidores de um DAG alternativo que suportam as cópias de bancos de dados resilientes do site). O terceiro pool thin suporte a caixas de Correio passivas 10,800 exigirá 100 eixos.

Um total de 300 eixos por site são necessários para suportar os requisitos de capacidade totalmente provisionada de banco de dados.

Em uma etapa anterior, foi determinado que cada bloco de construção de 2.700 caixas de correio exigia dois eixos para suportar os requisitos de LUN de log.

Há quatro blocos de construção suportando bancos de dados de caixas de correio ativas nos servidores de Caixa de Correio do datacenter principal. O log de LUN suporte a caixas de correio ativas 10,800 exigirá oito eixos.

Há quatro blocos de construção suportando bancos de dados de caixas de correio passivas nos servidores de Caixa de Correio do datacenter principal. O log de LUN suporte a caixas de Correio passivas 10,800 exigirá oito eixos.

Há quatro blocos de construção suportando bancos de dados de caixas de correio passivas nos servidores de Caixa de Correio do datacenter secundário. O log de LUN suporte a caixas de Correio passivas 10,800 exigirá oito eixos.

Para suportar os requisitos de LUN de log em um único site são necessários 24 eixos.

Nesta etapa, verifique se a contagem total de eixos necessários pode ser suportada pela matriz de armazenamento escolhida, usando o seguinte cálculo:

  • Total de eixos exigidos por site = eixos necessários para LUNs de banco de dados + eixos necessários para LUNs de log

    = 120 + 24

    = 144

Um CX4-480 com gabinetes de matriz de 10 discos tem 150 eixos e atende aos requisitos.

Nesta etapa, calcule a quantidade total de eixos necessários para suportar o ambiente totalmente provisionado, usando o seguinte cálculo:

  • Total de eixos exigidos por site = eixos necessários para LUNs de banco de dados + eixos necessários para LUNs de log

    = 300 + 24

    = 324

Um CX4-480 com gabinetes de matriz de 22 discos tem 330 eixos e atende aos requisitos.

Return to top

A seção anterior forneceu informações sobre as decisões de projeto tomadas quando uma solução do Exchange 2010 é considerada. A seção a seguir fornece uma visão geral da solução.

Return to top

Esta solução consiste em um total de 36 servidores do Exchange 2010, implantados em uma topologia multissite. Doze dos 36 servidores estão executando tanto a função de servidor Acesso para Cliente quanto a função de servidor Transporte de Hub. Os outros 24 servidores estão executando a função de servidor caixa de correio. Há uma matriz de servidores de Acesso para Cliente com quatro servidores de combinação de Transporte de Hub e Acesso para Cliente em cada site. Existem três DAGs, cada um com oito servidores de caixa de correio. Servidores de arquivos em cada site hospedam os servidores testemunha primário e secundário de compartilhamento de arquivos para cada DAG.

Diagrama da solução lógica

tbd

Return to top

Cada um dos três sites contém quatro servidores blade Cisco B200 conectados a uma matriz de armazenamento EMC CLARiiON CX4 modelo 480 por meio de comutadores redundadtes Cisco Fabric Interconnect 6120 e Cisco MDS 9134. Redundantes Cisco Nexus 5010 Ethernet switches fornecem a infra-estrutura de rede subjacente. O tráfego de cliente passa por um balanceamento de carga na matriz de servidores de Acesso para Cliente em cada site através de dispositivos redundantes de balanceamento de carga Cisco ACE 4710.

Diagrama de solução física

tbd

Return to top

A tabela a seguir resume o hardware de servidor físico usado nesta solução.

Resumo do Cisco Unified sistema de computação

Item Descrição

Servidor blade

M1 4 × B200

Processadores

2 × Intel Zeon x 5570 (2,93 GHz)

Memória

96 GB RAM (12 × 8 GB DIMM)

Adaptador de rede convergida

M71KR-Q (2 × 10 gigabit Ethernet e Fibre Channel de 2 × 4 Gbps)

Armazenamento interno lâmina

Disco de GB SAS 10.000 RPM 2 × 146 (RAID-1)

Chassi

5108 (6RU)

Extensor de tecido

2 × 2104XP

Interconexão de tecido

2 × 6120XP

Módulo de expansão de interconexão de tecido

2 × 8 portas 4 Gbps Fibre Channel

A tabela a seguir resume o hardware de armazenamento e rede usado nesta solução.

Switches LAN e SAN

Item Descrição

switch do 10 gigabit Ethernet (GbE)

2 × Nexus 5010 (8 portas 1 GbE/10 GbE fixas, 12 portas 10 GbE fixas, bridge de datacenter)

Switch Fibre Channel

2 × MDS 9134 (32 4 Gbps portas fixas)

A tabela a seguir fornece informações sobre o software usado nesta solução.

Resumo para a solução de software

Item Descrição

Servidores de host hipervisor

Windows Server 2008 R2 Hyper-V Enterprise

VMs do Exchange Server

Windows Server 2008 R2 Enterprise

Função de servidor caixa de correio do Exchange Server 2010

Enterprise Edition RU2

Função de servidor Transporte de Hub do Exchange Server 2010 e acesso para cliente

Standard Edition RU2

Vários caminho e equilíbrio i/O

EMC PowerPath

Return to top

A tabela a seguir resume a configuração de servidor de combinação de Acesso para Cliente e Transporte de Hub usada na solução.

Configuração de servidor de acesso para cliente e transporte de Hub

Componente Valor ou descrição

Física ou virtual

VM do Hyper-V

Processadores virtuais

3

Memória

8 GB

Armazenamento

Disco rígido virtual no volume do sistema operacional de servidor raiz

Sistema operacional

Windows Server 2008 R2

Versão do Exchange

Exchange Server 2010 Standard Edition

Nível de atualização do Exchange

Exchange 2010 Update Rollup 2

Software de terceiros

Nenhum

Return to top

A tabela a seguir resume a configuração do servidor de Caixa de Correio principal (hospedando a cópia principal e a cópia secundária de banco de dados no site principal para o DAG) usada na solução.

Configuração do servidor de Caixa de Correio principal

Componente Valor ou descrição

Física ou virtual

VM do Hyper-V

Processadores virtuais

4

Memória

53 GB

Armazenamento

Disco rígido virtual no volume do sistema operacional de servidor raiz

   

Sistema operacional

Windows Server 2008 R2

Versão do Exchange

Exchange Server 2010 Enterprise Edition

Nível de atualização do Exchange

Exchange 2010 Update Rollup 2

Software de terceiros

Nenhum

A tabela a seguir resume a configuração do servidor de Caixa de Correio secundária (hospedando a cópia terciária de banco de dados no site secundário para o DAG) usada na solução.

Configuração do servidor de Caixa de Correio secundária

Componente Valor ou descrição

Física ou virtual

VM do Hyper-V

Processadores virtuais

2

Memória

24 GB

Armazenamento

Disco rígido virtual no volume do sistema operacional de servidor raiz

Sistema operacional

Windows Server 2008 R2

Versão do Exchange

Exchange Server 2010 Enterprise Edition

Nível de atualização do Exchange

Exchange 2010 Update Rollup 2

Software de terceiros

Nenhum

Return to top

Os diagramas a seguir resumem o layout de cópia de banco de dados usado na solução durante condições normais de operação.

Layout de cópia do banco de dados: 1

tbd

Layout de cópia do banco de dados: 2

tbd

Layout de cópia do banco de dados: 3

tbd

Return to top

A tabela a seguir fornece informações sobre o hardware de armazenamento usado nesta solução.

Armazenamento unificado da EMC NS-480 (integrado CLARiiON CX4-480)

Item Descrição

Armazenamento

3 CLARiiON CX4-480 (1 por site)

Conectividade de armazenamento (Fibre Channel, SAS, SATA, iSCSI)

Fibre Channel

Cache de armazenamento

32 GB (600 MB de cache de leitura e 10,160 MB cache por porta de armazenamento de gravação)

Número de controladores de armazenamento

2 por estrutura de armazenamento

Número de portas de armazenamento disponíveis ou usados

8 (4 por porta de armazenamento) disponíveis por estrutura de armazenamento, 4 usadas (2 por porta de armazenamento)

Largura de banda máxima de conectividade de armazenamento para host

8 × 4 Gbps

Número total de discos testados em solução

432 (360 para bancos de dados) e 72 para logs de 3 sites

Número máximo de eixos que podem ser hospedados no armazenamento

480 em um único storage array

Return to top

Cada matriz de armazenamento CX4 modelo 480 usada na solução foi configurada conforme ilustra a tabela a seguir.

Configuração de armazenamento

Componente Valor ou descrição

Gabinetes de armazenamento total

3

Compartimentos de armazenamento total por site

1

Totais discos por gabinete

150

Pools de armazenamento total por gabinete

3

Discos totais por pool de armazenamento (inicial)

40

Discos totais por banco de dados de LUN (inicial)

10

Discos totais por LUN de log

2

Totais discos usados por gabinete

144

Tamanho LUN para banco de dados (inicial)

4.020 GB

Tamanho LUN para logs

402 GB

RAID nível para bancos de dados

5

RAID nível para logs

1/0

A tabela a seguir ilustra como o armazenamento disponível foi projetado e alocado entre os três sistemas de armazenamento CX4 modelo 480.

Configuração de armazenamento entre sistemas de armazenamento 480 CX4 modelo

Data center DAG Database Matriz1 Matriz2 Matriz3

1

1

DB1-24

C1, C2

C3

2

2

DB25-48

C3

C1, C2

3

3

DB49-72

C3

C1, C2

Return to top

Antes de implantar uma solução do Exchange em um ambiente de produção, confirme se a solução foi projetada, dimensionada e configurada corretamente. Essa validação precisa incluir testes funcionais para garantir que o sistema esteja operando conforme o desejado, além de testes de desempenho para garantir que o sistema possa lidar com a carga de usuário desejada. Esta seção descreve a abordagem e a metodologia de testes usadas para validar o projeto de servidor e armazenamento da solução. Em particular, os testes a seguir serão definidos em detalhe:

  • Testes de desempenho

    • Validação de desempenho de armazenamento (Jetstress)

    • Validação de desempenho do servidor (Loadgen)

  • Testes funcionais

    • Validação de transição para o banco de dados

    • Validação de transição para o servidor

    • Validação de failover de servidor

    • Validação de transição para o Datacenter

Return to top

O nível de desempenho e confiabilidade do subsistema de armazenamento conectado à função de servidor Caixa de Correio do Exchange tem impacto expressivo sobre a integridade total da implantação do Exchange. Além disso, um desempenho fraco do armazenamento resulta em alta latência de transações, refletindo-se principalmente em uma experiência ruim para o cliente no acesso ao sistema do Exchange. Para garantir a melhor experiência de cliente possível, valide a configuração e o dimensionamento do armazenamento através do método descrito nesta seção.

Para validar a configuração e o dimensionamento do armazenamento do Exchange, a ferramenta Jetstress do Microsoft Exchange Server é recomendada. A ferramenta Jetstress foi projetada para simular uma carga de trabalho de E/S do Exchange no nível do banco de dados, interagindo diretamente com o ESE, que também é conhecido como Jet. O ESE é a tecnologia de banco de dados que o Exchange usa para armazenar dados de mensagens na função de servidor Caixa de Correio. O Jetstress pode ser configurado para testar a taxa de transferência de E/S máxima disponível ao subsistema de armazenamento segundo as restrições de desempenho obrigatórias do Exchange. Ou o Jetstress pode aceitar um perfil de destino de contagem de usuários e IOPS por usuário, e validar que o subsistema de armazenamento seja capaz de manter um nível aceitável de desempenho com o perfil de destino. A duração do teste é ajustável, e ele pode ser executado por um período mínimo para validar o desempenho adequado ou por um período prolongado com o objetivo adicional de validar a confiabilidade do subsistema de armazenamento.

A ferramenta Jetstress pode ser obtida pelo Centro de Download da Microsoft nos seguintes locais:

A documentação incluída com o instalador do Jetstress descreve como configurar e executar um teste de validação do Jetstress no hardware do seu servidor.

Existem dois tipos principais de configurações de armazenamento:

  • Cenários de disco interno ou DAS

  • Cenários de SAN

Em cenários de DAS ou discos internos, há apenas um servidor acessando o subsistema de disco, e portanto os recursos de desempenho do subsistema de armazenamento podem ser validados de forma isolada.

Em cenários de SAN, o armazenamento utilizado pela solução pode ser compartilhado por muitos servidores e a infraestrutura que conecta os servidores ao armazenamento também pode ser uma dependência compartilhada. Isso exige testes adicionais, porque o impacto de outros servidores na infraestrutura compartilhada deve ser simulado de forma adequada para a validação do desempenho e da funcionalidade.

Os casos de teste para validação de armazenamento a seguir foram executados contra a solução e devem ser considerados pontos de partida para a validação do armazenamento. Implantações específicas podem ter outros requisitos de validação que sejam atendidos com testes adicionais, portanto esta lista não pretende ser exaustiva:

  • Validação de pior cenário de alternância de banco de dados   Neste caso de teste, espera-se que o nível de E/S seja atendido pelo subsistema de armazenamento caso ocorra o pior cenário de alternância (o maior número possível de cópias ativas na menor quantidade de servidores). Dependendo do fato do subsistema de armazenamento ser DAS ou SAN, pode ser necessário executar o teste em vários hosts para garantir que a carga da solução de ponta a ponta no subsistema de armazenamento possa ser sustentada.

  • Validação do desempenho do armazenamento em cenário de falha e recuperação de armazenamento (por exemplo, substituição e reconstrução de um disco que falhou)   Neste caso de teste, o desempenho do subsistema de armazenamento durante um cenário de falha e reconstrução é avaliado para garantir que o nível necessário de desempenho seja mantido para uma experiência ideal de cliente do Exchange. A mesma limitação aplica-se para DAS vs. Implantação de SAN: Se vários hosts dependerem de um subsistema de armazenamento compartilhado, o teste deverá incluir carga desses hosts para simular o efeito completo da falha e da reconstrução.

A ferramenta Jetstress produz um arquivo de relatório depois de cada teste é concluído. Para ajudá-lo a analisar o relatório, use as diretrizes em Jetstress 2010 Test Summary Reports.

Mais especificamente, você deve usar as diretrizes da tabela a seguir ao examinar dados na tabela de Resultados de testes do relatório.

Análise de resultados Jetstress

Instância do contador de desempenho Diretrizes para o teste de desempenho

Banco de dados de e/S lê latência média (MS)

O valor médio deve ser inferior a 20 milissegundos (ms) (0,020 segundos), e os valores máximos devem ser inferiores a 50 ms.

Latência média (MS) de gravações de Log de e/S

As gravações de log em disco são sequenciais, portanto as latências médias de gravação devem ser inferiores a 10 ms, com máximo inferior a 50 ms.

% tempo do processador

A média deve ser inferior a 80%, e o máximo deve ser inferior a 90%.

Páginas de transição adaptadas/s (Windows Server 2003, Windows Server 2008, Windows Server 2008 R2)

A média deve ser inferior a 100.

O arquivo de relatório mostra várias categorias de E/S realizadas pelo sistema do Exchange:

  • Desempenho de E/S transacional   Esta tabela reporta a E/S que representa a atividade de usuário em relação ao banco de dados (por exemplo, E/S gerada pelo Outlook). Os dados são gerados subtraindo a E/S de replicação de log e a E/S de manutenção em segundo plano da E/S total medida durante o teste. Esses dados proporcionam a IOPS real de banco de dados gerada e as medições de latência de E/S necessárias para determinar se um teste de desempenho do Jetstress falhou ou teve êxito.

  • Desempenho de E/S de manutenção de banco de dados em segundo plano   Esta tabela relata a E/S gerada pela manutenção em andamento em segundo plano do banco de dados do ESE.

  • Desempenho de E/S de replicação de log   Esta tabela relata a E/S gerada pela replicação de log simulada.

  • Desempenho de E/S total   Esta tabela relata a E/S total gerada durante o teste do Jetstress.

Return to top

Depois de validar o desempenho e a confiabilidade do subsistema de armazenamento, certifique-se de que todos os componentes do sistema de mensagens sejam validados juntos para funcionalidade, desempenho e escalabilidade. Isso significa subir na pilha para validar a interação de software de cliente com o produto Exchange, além de quaisquer produtos do lado do servidor que interajam com o Exchange. Para garantir que a experiência de cliente de ponta a ponta seja aceitável e que a solução inteira possa sustentar a carga de usuário desejada, o método descrito nesta seção pode ser aplicado para validação de projeto de servidor.

Para validação de desempenho e escalabilidade de solução de ponta a ponta, recomenda-se a ferramenta Load Generator (Loadgen) do Microsoft Exchange Server. O Loadgen foi projetado para produzir uma carga de trabalho de cliente simulada em uma implantação do Exchange. Essa carga de trabalho pode ser usada para avaliar o desempenho do sistema do Exchange, e também para a análise do efeito de várias alterações na configuração da solução geral enquanto o sistema estiver sob carga. O Loadgen é capaz de simular a atividade de cliente dos seguintes itens: Microsoft Office Outlook 2007 (online e em cache), Office Outlook 2003 (online e em cache), POP3, IMAP4, SMTP, ActiveSync e Outlook Web App (conhecido no Exchange 2007 e em versões anteriores como Outlook Web Access). Ele pode ser usado para gerar uma carga de trabalho de protocolo único, ou esses protocolos de cliente podem ser combinados para gerar uma carga de trabalho de vários protocolos.

A ferramenta Loadgen pode ser obtida pelo Centro de Download da Microsoft nos seguintes locais:

A documentação incluída com o instalador do Loadgen descreve como configurar e executar um teste do Loadgen em uma implantação do Exchange

Ao validar o projeto do servidor, teste o pior cenário com a carga de trabalho de pico prevista. Com base em diversos conjuntos de dados da TI da Microsoft e de outros clientes, a carga de trabalho de pico geralmente é o dobro da carga de trabalho média do restante do dia de trabalho. Isso é chamado para a relação de carga de trabalho de pico-a-média.

Monitor de Desempenho

Captura de tela do monitor de desempenho

Neste instantâneo do Monitor de Desempenho, que exibe vários contadores que representam a quantidade de trabalho do Exchange realizado ao longo do tempo em um servidor de Caixa de Correio de produção, o valor médio de operações de RPC por segundo (a linha realçada) é de 2.386 quando a média é calculada para o dia inteiro. A média para esse contador durante o período de pico das 10:00 às 11:00 é de 4.971, proporcionando uma taxa de pico-a-média de 2,08.

Para garantir que a solução do Exchange seja capaz de sustentar a carga de trabalho gerada durante a média de pico, modifique as configurações do Loadgen para gerar uma quantidade constante de carga no nível de média de pico, em vez de espalhar a carga de trabalho por todo o dia de trabalho simulado. Os módulos de simulação com base em tarefas do Loadgen (assim como os módulos de simulação do Outlook) utilizam um perfil de tarefas que define a quantidade de vezes em que cada tarefa ocorrerá para um usuário comum em um dia simulado.

A quantidade total de tarefas que precisam ser executadas durante um dia simulado é calculada como a quantidade de usuários multiplicada pela soma das contagens de tarefas no perfil de tarefas configurado. Em seguida, o Loadgen determina a taxa na qual deve executar tarefas para o conjunto configurado de usuários, dividindo a quantidade total de tarefas a serem executadas no dia simulado pela duração do dia simulado. Por exemplo, se o Loadgen tiver que executar 1.000.000 de tarefas em um dia simulado, e um dia simulado equivaler a oito horas (28.800 segundos), o Loadgen terá que executar 1.000.000 ÷ 28.800 = 34,72 tarefas por segundo para atender à definição de carga de trabalho necessária. Para aumentar a quantidade de carga até a média de pico desejada, divida a duração padrão do dia simulado (oito horas) pela taxa de pico-a-média (2) e use-a como a nova duração de dia simulado.

Usando o exemplo de taxa de tarefa novamente, tarefas de 1.000.000 ÷ 14,400 = 69.44 por segundo. Isso reduz a duração do dia simulado pela metade, o que dobra a carga de trabalho real em relação ao servidor e atinge nossa meta de carga de trabalho de média de pico. A duração da execução do teste não é ajustada na configuração do Loadgen. A duração da execução especifica a duração do teste, e não afeta a taxa na qual as tarefas serão executadas no servidor do Exchange.

Os casos de teste para validação de design de servidor a seguir foram executados contra a solução e devem ser considerados pontos de partida para a validação do design do servidor. Implantações específicas podem ter outros requisitos de validação que sejam atendidos com testes adicionais, portanto esta lista não pretende ser exaustiva:

  • Condições normais de operação   Neste caso de teste, o design básico da solução é validado com todos os componentes em estado normal de operação (sem falhas simuladas). A carga de trabalho desejada é gerada em relação à solução, e o desempenho geral da solução é validado contra as métricas seguintes.

  • Manutenção ou falha de um único servidor (no site)   Neste caso de teste, um único servidor é desativado para simular uma falha inesperada do servidor ou uma operação de manutenção planejada para o servidor. A carga de trabalho que normalmente seria tratada pelo servidor indisponível passa a ser tratada por outros servidores na topologia da solução, e o desempenho total da solução é validado.

Os dados de desempenho do Exchange têm alguma variação natural nas execuções dos testes e entre execuções de testes. É recomendável obter uma média de diversas execuções para suavizar a variação. Para as soluções testadas do Exchange, um mínimo de três execuções separadas de testes com durações de oito horas foram concluídas. Foram recolhidos dados de desempenho para a duração total de oito horas de ensaio. Os dados de resumo de desempenho foram obtidos a partir de um período estável de três a quatro horas (excluindo as duas primeiras horas do teste e a última hora do teste). Para cada função de servidor do Exchange, os dados de resumo de desempenho recebem uma média entre servidores para cada execução de teste, proporcionando um valor médio único para cada ponto de dados. Os valores de cada execução receberam uma média, proporcionando um único ponto de dados para todos os servidores de uma função de servidor em todas as execuções de teste.

Antes de analisar os contadores de desempenho ou iniciar sua análise de validação de desempenho, verifique se a carga de trabalho que você esperava executar correspondeu à carga de trabalho que de fato foi executada. Embora existam muitas maneiras de determinar se a carga de trabalho simulada correspondeu à carga de trabalho simulada, a maneira mais fácil e consistente é analisar a taxa de entrega de mensagens.

Cada perfil de mensagens consiste na soma da quantidade média de mensagens enviadas por dia à quantidade média de mensagens recebidas por dia. Para calcular a taxa de entrega de mensagens, selecione a quantidade média de mensagens recebidas por dia na tabela a seguir.

Taxa de entrega de mensagem do pico

Perfil da mensagem Mensagens enviadas por dia Mensagens recebidas por dia

50

10

40

100

20

80

150

30

120

200

40

160

O exemplo a seguir presume que cada servidor de Caixa de Correio tenha 5.000 caixas de correio ativas com um perfil de 150 mensagens por dia (30 mensagens enviadas e 120 mensagens recebidas por dia).

Taxa de entrega de mensagem de pico de 5.000 caixas de correio ativas

Descrição Cálculo Valor

Perfil da mensagem

Número de mensagens recebidas por dia

120

Número de caixas de correio por servidor de caixa de correio ativas

Não se aplica

5000

Total de mensagens recebidas por dia para cada servidor de caixa de correio

5000 × 120

600000

Total de mensagens recebidas por segundo por servidor de caixa de correio

600000 ÷ 28800

20.83

Total de mensagens ajustado para o pico de carga

20.83 × 2

41.67

São esperadas 41,67 mensagens entregues por segundo em cada servidor de Caixa de Correio executando 5.000 caixas de correio ativas com um perfil de mensagens de 150 mensagens por dia durante a carga de pico.

A taxa real de entrega de mensagens pode ser medida com o seguinte contador em cada servidor de Caixa de Correio: MSExchangeIS Mailbox(_Total)\Mensagens entregues/s. Se a taxa de entrega de mensagens medida estiver entre uma e duas mensagens por segundo da taxa de entrega de mensagens de destino, é sinal de que o perfil de carga desejado foi executado com êxito.

Esta seção descreve os contadores do Monitor de Desempenho e os limites usados para determinar se o ambiente do Exchange foi dimensionado corretamente e se é capaz de operar em um estado íntegro por longos períodos de carga de trabalho de pico. Para obter mais informações sobre contadores relevantes para o desempenho do Exchange, consulte Contadores e limites de desempenho e escalabilidade.

Para validar o critério de desempenho e integridade de um servidor raiz do Hyper-V e os aplicativos em execução em VMs, você deve ter um conhecimento básico sobre a arquitetura do Hyper-V e como ela afeta o monitoramento do desempenho.

Hyper-V tem três componentes principais: a pilha de virtualização, o hipervisor e dispositivos. A pilha de virtualização manipula dispositivos emulados, gerencia VMs e fornece E/S. O hipervisor agenda processadores virtuais, gerencia interrupções, fornece temporizadores e controla outras funções no nível de chip. O hipervisor não manipula dispositivos ou E/S (por exemplo, não há drivers para o hipervisor). Os dispositivos são parte do servidor raiz ou são instalados em servidores convidados como parte de serviços de integração. Como o servidor raiz tem visão total do sistema e controla as VMs, ele também proporciona informações de monitoramento através da Windows Management Instrumentation (WMI) e dos contadores de desempenho.

Processador

Ao validar a utilização de processador físico no servidor raiz (ou na VM convidada), o contador padrão Processador\% Tempo do Processador não é muito útil.

Em vez disso, você pode examinar o contador Processador Lógico do Hipervisor do Hyper-V\% Tempo Total de Execução Esse contador mostra a porcentagem de tempo de processador gasto em tempo de execução do convidado e do hipervisor e deve ser usado para medir a utilização total do processador para o hipervisor e todas as VMs em execução no servidor raiz. O contador não deve exceder 80 por cento ou a meta de utilização máxima na qual seu design se baseia.

 

Contador Destino

Processador Lógico do Hipervisor do Hyper-V\% Tempo Total de Execução

<80%

Se estiver interessado na porcentagem de tempo do processador gasto servindo às VMs convidadas, você pode examinar o contador Processador Lógico do Hipervisor do Hyper-V\% Tempo de Execução do Convidado. Se estiver interessado na porcentagem de tempo do processador gasto no hipervisor, você pode examinar o contador Processador Lógico do Hipervisor do Hyper-V\% Tempo de Execução do Hipervisor. O contador deve estar abaixo de 5%. O contador Processador Virtual Raiz do Hipervisor do Hyper-V\% Tempo de Execução do Convidado mostra a porcentagem de tempo do processador gasto na pilha de virtualização. Esse contador também deve ser abaixo de 5%. Esses dois contadores podem ser usados para determinar qual porcentagem de seu tempo disponível de processador físico está sendo usada para suportar a virtualização.

 

Contador Destino

Processador Lógico do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<80%

Processador Lógico do Hipervisor do Hyper-V\% Tempo de Execução do Hipervisor

<5%

Processador Virtual Raiz do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<5%

Memória

Certifique-se de que o servidor raiz do Hyper-V tenha memória suficiente para suportar a memória alocada para as VMs. O Hyper-V reserva automaticamente 512 MB (isso pode variar com versões diferentes do Hyper-V) para o sistema operacional raiz. Se não houver memória suficiente, o Hyper-V impedirá a última VM de ser iniciada. De modo geral, não se preocupe em validar a memória em um servidor raiz do Hyper-V. Em vez disso, preocupe-se em garantir que haja memória suficiente alocada para as VMs para suportar as funções do Exchange.

Aplicativo saúde

Uma maneira fácil de determinar se todas as VMs estão em um estado íntegro é analisar os contadores do Resumo de integridade de máquina virtual do Hyper-V.

 

Contador Destino

Resumo de Integridade do Virtual Machine do Hyper-V\Integridade OK

1

Resumo de Integridade do Virtual Machine do Hyper-V\Integridade Crítica

0

Servidores de Caixa de Correio

Ao validar se um servidor de Caixa de Correio foi dimensionado corretamente, concentre-se no processador, na memória, no armazenamento e na integridade dos aplicativos do Exchange. Esta seção descreve a abordagem para validar cada um desses componentes.

Processador

Durante o processo de design, a capacidade de megaciclos ajustada da plataforma do processador ou servidor foi calculada. Em seguida, foi determinada a quantidade máxima de caixas de correio ativas que podiam ser suportadas pelo servidor sem exceder 80 por cento da capacidade disponível de megaciclos. Também foi determinada a utilização projetada da CPU durante condições normais de operação e vários cenários de manutenção e falha de servidor.

Durante o processo de validação, verifique se o pior cenário de carga de trabalho não excede 80% dos megaciclos disponíveis. Verifique também se a utilização real da CPU se aproxima das utilização de CPU esperada durante condições normais de operação e vários cenários de manutenção e falha de servidor.

Para implantações físicas do Exchange, use o contador Processador(_Total)\% Tempo do Processador e verifique se o contador é inferior a 80% em média.

 

Contador Destino

Processador(_Total)\% Tempo do Processador

<80%

Para implantações virtuais do Exchange, o contador Processador(_Total)\% Tempo do Processador é medido na VM. Neste caso, o contador não é medir a utilização da CPU física. Ele é medir a utilização da CPU virtual fornecido pelo hipervisor. Portanto, ele não oferece uma leitura precisa do processador físico e não deve ser usado para fins de validação de design. Para obter mais informações, consulte Hyper-v: Clocks lie... which performance counters can you trust? (página em inglês)

Para validar implantações do Exchange em execução no Microsoft Hyper-V, use o contador Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado. Ele oferece um valor mais preciso da quantidade de CPU física que está sendo utilizada pelo sistema operacional convidado. Esse contador deve ser menor que 80% em média.

 

Contador Destino

Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<80%

Memória

Durante o processo de design, foi calculada a quantidade de cache de banco de dados necessária para suportar a quantidade máxima de bancos de dados ativos em cada servidor de Caixa de Correio. Em seguida, foi determinada a configuração ideal de memória física para suportar os requisitos de cache de banco de dados e memória do sistema.

Validar se um servidor de Caixa de Correio do Exchange tem memória suficiente para suportar a carga de trabalho de destino não é uma tarefa simples. O uso de contadores de memória disponível para exibição da memória física restante não é útil porque o gerenciador de memória do Exchange foi projetado para usar quase toda a memória física disponível. O arquivo de informações (store.exe) reserva uma grande porção de memória física ao cache de banco de dados. O cache de banco de dados é usado para armazenar páginas de banco de dados na memória. Quando uma página é acessada na memória, as informações não precisam ser recuperadas do disco, reduzindo a E/S de leitura. O cache de banco de dados também é usado para otimizar a E/S de escrita.

Quando uma página do banco de dados é modificada (também conhecida como página suja), ela permanece no cache por um certo período. Quanto mais tempo ela permanece em cache, maiores são as chances de ser modificada várias vezes antes que as alterações possam ser escritas no disco. Manter páginas sujas no cache também faz com que várias páginas sejam escritas no disco na mesma operação (processo conhecido como união de escrita). O Exchange usa a maior quantidade possível de memória disponível do sistema, e é por isso que não há uma grande quantidade de memória disponível em um servidor de Caixa de Correio do Exchange.

Pode ser difícil saber se a configuração de memória de seu servidor de Caixa de Correio do Exchange foi subdimensionada. De um modo geral, o servidor de Caixa de Correio continuará funcionando, mas seu perfil de E/S pode ser muito maior que o esperado. Uma E/S mais alta pode aumentar as latências de leitura e escrita no disco, podendo afetar a integridade dos aplicativos e a experiência de usuário do cliente. Na seção resultados, não há qualquer referência aos contadores de memória. Possíveis problemas de memória serão identificados nas seções de resultados de validação do armazenamento e integridade dos aplicativos, onde problemas relacionados à memória podem ser detectados com mais facilidade.

Armazenamento

Se seu servidor de Caixa de Correio do Exchange apresentar problemas de desempenho, esses problemas podem estar relacionados ao armazenamento. Os problemas de armazenamento podem ser decorrentes de uma quantidade insuficiente de discos para suportar os requisitos de E/S de destino, de uma infraestrutura de conectividade de armazenamento mal projetada ou sobrecarregada ou de fatores que alterem o perfil de E/S de destino, como memória insuficiente, conforme discutido anteriormente.

A primeira etapa na validação do armazenamento é verificar se as latências de banco de dados estão abaixo dos limites de destino. Nas versões anteriores, contadores de disco lógico determinados leitura de disco em latência de gravação. No Exchange 2010, o servidor de Caixa de Correio do Exchange que você está monitorando provavelmente terá um misto de cópias ativas e passivas de banco de dados de caixa de correio. As características de i/O de cópias do banco de dados ativo e passivo são diferentes. Como o tamanho da E/S é muito maior em cópias passivas, geralmente há latências muito mais altas em cópias passivas. As metas de latência para bancos de dados passivos são de 200 ms, dez vezes mais altas que as metas em cópias ativas de banco de dados. Isso não é muito preocupante, porque latências altas em bancos de dados passivos não afetam a experiência de cliente. Mas se estiver usando contadores de disco lógicos e tradicionais para medir latências, você deverá analisar os volumes individuais e os volumes separados contendo bancos de dados ativos e passivos. Em vez disso, recomendamos o uso dos novos contadores do Banco de Dados do MSExchange no Exchange 2010.

Ao validar latências nos servidores de Caixa de Correio do Exchange 2010, é recomendável o uso dos contadores na tabela a seguir para bancos de dados ativos.

 

Contador Destino

Banco de dados do MSExchange\Latência média de leituras (anexadas) do banco de dados de E/S

<20 MS

Banco de dados do MSExchange\Latência média de gravações (anexadas) do banco de dados de E/S

<20 MS

Banco de dados do MSExchange\Latência média de gravações do log de E/S

<1 MS

É recomendável o uso dos contadores na tabela a seguir para bancos de dados passivos

 

Contador Destino

Banco de dados do MSExchange\Latência média de leituras (de recuperação) do banco de dados de E/S

<200 MS

Banco de dados do MSExchange\Latência média de gravações (de recuperação) do banco de dados de E/S

<200 MS

Banco de dados do MSExchange\Latência média de leitura do log de E/S

<200 MS

ObservaçãoObservação:
Para exibir esses contadores no Monitor de Desempenho, ative os contadores avançados de banco de dados. Para obter mais informações, consulte How to Enable Extended ESE Performance Counters (em inglês).

Ao validar latências de disco para implantações do Exchange em execução no Microsoft Hyper-V, tenha em mente que os contadores de Latência Média de Banco de Dados de E/S (assim como muitos contadores com base em tempo) podem não ser precisos porque o conceito de tempo na VM é diferente do conceito de tempo no servidor físico. O exemplo a seguir mostra que a Latência Média de Leituras (Anexadas) de Banco de Dados de E/S é de 22,8 na VM e de 17,3 em um servidor físico para a mesma carga de trabalho simulada. Se os valores dos contadores com base em tempo estiverem acima dos limites de destino, seu servidor pode estar em operação correta. Analise todos os critérios de integridade para tomar uma decisão quanto à integridade do servidor quando sua função de servidor Caixa de Correio for implantada em uma VM.

Valores de contadores de latência de disco para servidores de caixa de correio virtuais e físicos

Contador Servidor de caixa de correio virtual Servidor de caixa de correio físico

Banco de dados do MSExchange /

Leituras de Banco de Dados de E/S (Anexadas) / Latência Média

22.792

17.250

Leituras de banco de dados de e/S (anexadas) / seg

17.693

18.131

Leituras de Banco de Dados de E/S (Recuperação) / Latência Média

34.215

27.758

Gravações (Recuperação) do Banco de Dados de E/S/s

10.829

  8.483

Gravações de Banco de Dados de E/S (Anexadas) / Latência Média

  0.944

  0.411

Gravações de banco de dados de e/S (anexadas) / seg

10.184

10.963

MSExchangeIS

   

Latência Média de RPC

   1.966

   1.695

Operações RPC/s

334.371

341.139

Pacotes RPC/s

180.656

183.360

Caixa de Correio MSExchangeIS

Mensagens Entregues/s

2.062

2.065

Mensagens Enviadas/s

0.511

0.514

Além de latências de disco, revise o contador de falha de página de Database\Database/s. Este contador indica a taxa de falhas de página que não podem ser reparadas porque não há nenhuma página disponível para alocação a partir do cache de banco de dados. Esse contador deve ser 0 em um servidor íntegro.

 

Contador Destino

Banco de dados\Paralisações de falhas de página do banco dedados /s

<1

Além disso, analise o contador Paralisações de Registro de Log\Banco de Dados/s, que indica o número de registros do log que não podem ser adicionados aos buffers de log por segundo porque estes estão cheios. Esse contador deve ser menor que 10% em média.

 

Contador Destino

Banco de dados\Paralisações de registro de log /s

<10

Integridade do aplicativo do Exchange

Mesmo que não haja nenhum problema evidente com o processador, a memória e os discos, é recomendável monitorar os contadores padrão de integridade de aplicativos para garantir que o servidor de Caixa de Correio do Exchange esteja em estado íntegro.

O contador MSExchangeIS\Latência Média de RPC oferece o melhor indicador para determinar se outros contadores com latências altas de banco de dados estão realmente afetando a integridade do Exchange e a experiência do cliente. Com frequência, latências médias altas de RPC estão associadas a uma grande quantidade de solicitações RPC, que devem ser sempre inferiores a 70.

 

Contador Destino

MSExchangeIS\Latência Média de RPC

<10msec em média

MSExchangeIS\Solicitações RPC

<70 em todos os momentos

Em seguida, certifique-se de que a camada de transporte é saudável. Quaisquer problemas no transporte ou decorrentes do transporte que afetem a camada de transporte podem ser detectados com o contador MSExchangeIS Mailbox(_Total)\Mensagens em Fila para Envio. Este contador deve ser sempre inferior a 50. Pode haver um aumento temporário no contador, mas o valor do contador não deve crescer com o tempo, nem deve se manter por mais de 15 minutos.

 

Contador Destino

Caixa de Correio do MSExchangeIS(_Total)\Mensagens em Fila para Envio

<50 em todos os momentos

Em seguida, certifique-se de que a manutenção das cópias de banco de dados esteja em estado íntegro. Quaisquer problemas com envio de logs ou repetição de logs podem ser identificados usando os contadores Replicação do MSExchange(*)\CopyQueueLength e Replicação do MSExchange(*)\ReplayQueueLength. O comprimento da fila de cópia indica a quantidade de arquivos de log de transações que aguardam para serem copiados para a pasta de arquivos de log de cópia passiva e deve ser sempre inferior a 1. O comprimento da fila de repetição indica a quantidade de arquivos de log de transações que aguardam para serem repetidos na cópia passiva e deve ser inferior a 5. Valores mais altos não afetam a experiência do cliente, mas resultam em tempos de montagem de armazenamento mais longos quando é realizado um handoff, um failover ou uma ativação.

 

Contador Destino

Replicação do MSExchange(*)\CopyQueueLength

<1

Replicação do MSExchange(*)\ReplayQueueLength

<5

Servidores de Acesso para Cliente

Para determinar se um servidor de Acesso para Cliente está íntegro, analise a integridade do processador, da memória e dos aplicativos. Para uma lista alargada de contadores importantes, consulte Contadores de servidor de Acesso para Cliente.

Processador

Para implantações físicas do Exchange, use o processador (_ total) \ contador % tempo do processador. Esse contador deve ser menor que 80% em média.

 

Contador Destino

Processador(_Total)\% Tempo do Processador

<80%

Para validar implantações do Exchange em execução no Microsoft Hyper-V, use o contador Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado. Ele oferece um valor preciso da quantidade de CPU física que está sendo utilizada pelo sistema operacional convidado. Esse contador deve ser menor que 80% em média.

 

Contador Destino

Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<80%

Aplicativo saúde

Para determinar se a experiência de cliente MAPI é aceitável, use o contador MSExchange RpcClientAccess\Latência Média de RPC. O contador deve estar abaixo de 250 ms. Latências altas podem ser associadas com um grande número de solicitações RPC. O contador do MSExchange RpcClientAccess\RPC pedidos deve ser abaixo de 40 em média.

 

Contador Destino

MSExchange RpcClientAccess\Latência média de RPC

<250 MS

MSExchange RpcClientAccess\Solicitações RPC

<40

Servidores de transporte

Para determinar se um servidor de transporte está íntegro, analise a integridade do processador, do disco e dos aplicativos. Para uma lista alargada de contadores importantes, consulte Contadores do Servidor de Transporte.

Processador

Para implantações físicas do Exchange, use o processador (_ total) \ contador % tempo do processador. Esse contador deve ser menor que 80% em média.

 

Contador Destino

Processador(_Total)\% Tempo do Processador

<80%

Para validar implantações do Exchange em execução no Microsoft Hyper-V, use o contador Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado. Ele oferece um valor preciso da quantidade de CPU física que está sendo utilizada pelo sistema operacional convidado. Esse contador deve ser menor que 80% em média.

 

Contador Destino

Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<80%

Disco

Para determinar se o desempenho do disco é aceitável, use o \ média de disco lógico (*). Disco s/Leitura e Escrita para os volumes contendo os logs de transporte e o banco de dados. Ambos esses contadores devem ser inferior a 20 ms.

 

Contador Destino

Disco Lógico(*)\Média Disco s/Leitura

<20 MS

Disco Lógico(*)\Média Disco s/Gravação

<20 MS

Aplicativo saúde

Para determinar se um servidor de Transporte de Hub foi dimensionado corretamente e se está sendo executado em um estado íntegro, examine os contadores de Filas do MSExchangeTransport descritos na tabela a seguir. Todas essas filas terão mensagens em vários momentos. Certifique-se de que o comprimento da fila não seja mantido e não cresça por um certo período. A ocorrência de comprimentos maiores de fila pode indicar um servidor de Transporte de Hub sobrecarregado. Ou podem haver problemas de rede ou um servidor de Caixa de Correio sobrecarregado incapaz de receber novas mensagens. É necessário conferir outros componentes do ambiente do Exchange para verificar.

 

Contador Destino

MSExchangeTransport Queues (_ total) \Comprimento entrega

<3000

MSExchangeTransport Queues(_total)\Comprimento da Fila de Entrega Remota Ativa

<250

MSExchangeTransport Queues(_total)\Comprimento da Fila de Entrega da Caixa de Correio Ativa

<250

MSExchangeTransport Queues(_total)\Comprimento da Fila de Repetição de Entrega de Caixa de Correio

<100

Filas de Transporte do MSExchange(_total)\Comprimento da Fila de Envio

<100

Return to top

É possível usar as informações dos cenários a seguir para testes de validação funcional.

Return to top

Uma alternância de banco de dados é o processo por meio do qual um banco de dados ativo individual é trocado por outra cópia do banco de dados (uma cópia passiva), e essa cópia do banco de dados torna-se a nova cópia ativa de banco de dados. Alternâncias de banco de dados podem acontecer dentro de datacenters e entre eles. Uma alternância de banco de dados pode ser realizada pelo Console de Gerenciamento do Exchange (EMC) ou pelo Shell de Gerenciamento do Exchange.

Para validar se uma cópia passiva de um banco de dados pode ser ativada com êxito em outro servidor, execute o comando a seguir.

Move-ActiveMailboxDatabase <DatabaseName> -ActivateOnServer <TargetServer>

Critérios de sucesso: O banco de dados de caixa de correio ativa é montado no servidor de destino especificado. Esse resultado pode ser confirmado com a execução do comando a seguir.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Return to top

Uma alternância de servidor é o processo pelo qual todos os bancos de dados ativos em um membro do DAG são ativados em um ou mais outros membros do DAG. Assim como a alternância de banco de dados, uma alternância de servidor pode ocorrer tanto dentro de um datacenter quanto entre datacenters, e pode ser iniciada usando-se o EMC e o Shell.

  • Para validar se todas as cópias passivas de bancos de dados em um servidor podem ser ativadas com êxito em outros servidores que hospedem uma cópia passiva, execute o comando a seguir.

    Get-MailboxDatabase -Server <ActiveMailboxServer> | Move-ActiveMailboxDatabase -ActivateOnServer <TargetServer>
    

    Critérios de sucesso: Os bancos de dados de caixa de correio ativa são montados no servidor de destino especificado. Isso pode ser confirmado por executando o seguinte comando.

    Get-MailboxDatabaseCopyStatus <DatabaseName>
    
  • Para validar se uma cópia de cada banco de dados ativo será ativada com êxito em outro servidor de Caixa de Correio hospedando cópias passivas dos bancos de dados, desative o servidor realizando a ação a seguir.

    Desligue o servidor ativo atual.

    Critérios de sucesso: Os bancos de dados de caixa de correio ativa são montados em outro servidor de Caixa de Correio no DAG. Isso pode ser confirmado por executando o seguinte comando.

    Get-MailboxDatabaseCopyStatus <DatabaseName>
    

Return to top

Um failover de servidor ocorre quando o membro do DAG não é mais capaz de prestar serviços à rede MAPI ou quando o serviço do Cluster de um membro do DAG não é mais capaz de contatar os demais membros do DAG.

Para validar se uma cópia de cada banco de dados ativo será ativada com êxito em outro servidor de Caixa de Correio hospedando cópias passivas dos bancos de dados, desligue o servidor realizando uma das ações a seguir:

  • Pressione e mantenha pressionado o botão ligar/desligar no servidor até que o servidor seja desligado.

  • Desconecte os cabos de alimentação do servidor, causando o desligamento do servidor.

Critérios de sucesso: Os bancos de dados de caixa de correio ativa são montados em outro servidor de Caixa de Correio no DAG. Isso pode ser confirmado por executando o seguinte comando.

Get-MailboxDatabase -Server <MailboxServer> | Get-MailboxDatabaseCopyStatus

Return to top

Um datacenter ou uma falha no site são gerenciados de maneira diferente dos tipos de falhas que podem causar failover em um servidor ou banco de dados. Em uma configuração de alta disponibilidade, a recuperação automática é iniciada pelo sistema, e a falha normalmente deixa o sistema de mensagens em um estado totalmente funcional. Por outro lado, uma falha em um datacenter é considerada um evento de recuperação de desastres. Por isso, a recuperação deve ser realizada e concluída manualmente para que o serviço do cliente seja restaurado, e a interrupção seja encerrada. O processo realizado é denominado alternância de datacenter. Assim como em muitos cenários de recuperação de desastres, o planejamento e a preparação antecipados para uma alternância de datacenter podem simplificar o processo de recuperação e reduzir a duração da interrupção.

Para obter mais informações, incluindo etapas detalhadas para a realização da alternância de datacenter, consulte Switchovers do Datacenter.

Há quatro etapas básicas que devem ser concluídas para a realização de uma alternância de datacenter após a decisão inicial de ativar o segundo datacenter:

  1. Encerrar um datacenter parcialmente em execução (falha).

  2. Validar e confirmar os pré-requisitos para o segundo data center.

  3. Ative os servidores de caixa de correio.

  4. Ative os servidores de acesso para cliente.

As seções a seguir descrevem as etapas usadas para validar uma transição para o datacenter.

Quando o DAG estiver em modo DAC, as ações específicas para encerrar quaisquer membros do DAG sobreviventes no datacenter principal dependem do estado do datacenter que falhou. Execute um dos procedimentos a seguir:

  • Se os servidores de Caixa de Correio no datacenter que falhou continuarem acessíveis (geralmente não é o caso), execute o comando a seguir em cada servidor de Caixa de Correio.

    Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename>
    
  • Se os servidores de Caixa de Correio no datacenter que falhou estiverem inacessíveis mas o Active Directory estiver operando no datacenter principal, execute o comando a seguir em um controlador de domínio.

    Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly
    
ObservaçãoObservação:
Uma falha na desativação dos servidores de Caixa de Correio do datacenter com falha ou na execução bem-sucedida do comando Stop-DatabaseAvailabilityGroup nos servidores criará a probabilidade de ocorrência da síndrome do cérebro dividido nos dois datacenters. Talvez seja necessário desligar individualmente os computadores por meio de dispositivos de gerenciamento de energia, a fim de satisfazer esse requerimento.

Critérios de sucesso: Todos os servidores de caixa de correio no site com falha são um estado parado. Para fazer essa verificação, execute o comando a seguir a partir de um servidor no datacenter que falhou.

Get-DatabaseAvailabilityGroup | Format-List

O segundo datacenter deve ser atualizado para representar quais servidores do datacenter principal foram interrompidos. De um servidor no data center secundário, execute o seguinte comando.

Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly

A finalidade desta etapa é informar aos servidores no datacenter secundário quais servidores de Caixa de Correio estão disponíveis para uso na restauração do serviço.

Critérios de sucesso: Todos os servidores de caixa de correio no data center com falha são um estado parado. Para fazer essa verificação, execute o comando a seguir a partir de um servidor no datacenter secundário.

Get-DatabaseAvailabilityGroup | Format-List

Antes de ativar os membros do DAG em um datacenter secundário, é recomendável verificar se os serviços de infraestrutura no datacenter secundário estão prontos para ativação do serviço de mensagem.

Quando o DAG estiver em modo DAC, as etapas para a conclusão da ativação dos servidores de Caixa de Correio no segundo datacenter são as seguintes:

  1. Pare o serviço de cluster em cada membro de DAG no data center secundário. É possível usar o cmdlet Stop-Service para interromper o serviço (por exemplo, Stop-Service ClusSvc) ou usar net stop clussvc em um prompt de comando elevado.

  2. Para ativar os servidores de Caixa de Correio no datacenter secundário, execute o comando a seguir.

    Restore-DatabaseAvailabilityGroup -Identity <DAGname> -ActiveDirectorySite <insertsitename>
    

    Se esse comando for executado com êxito, os critérios do quorum serão reduzidos para os servidores do datacenter secundário. Se o número de servidores nesse datacenter for um número par, o DAG passará a usar o servidor testemunha alternativo conforme identificado pela configuração do objeto do DAG.

  3. Para ativar os bancos de dados, execute um dos seguintes comandos.

    Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinPrimarySite>
    

    ou

    Move-ActiveMailboxDatabase -Server <DAGMemberInSecondarySite> -ActivateOnServer <DAGMemberinPrimarySite>
    
  4. Verifique os logs de eventos e analise todas as mensagens de erro e aviso para garantir que o site secundário esteja íntegro. Quaisquer problemas indicados devem ser acompanhados e corrigidos antes da montagem dos bancos de dados.

  5. Para montar os bancos de dados, execute o comando a seguir:

    Get-MailboxDatabase <DAGMemberInSecondarySite> | Mount-Database
    

Critérios de sucesso: Os bancos de dados de caixa de correio ativa são montados em servidores de Caixa de Correio no site secundário. Para confirmar, execute o comando a seguir.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Os clientes se conectam a pontos de extremidade de serviço para acessar serviços e dados do Exchange. Ativar os servidores de Acesso para Clientes voltados para a Internet, portanto, envolve alterar os registros DNS para apontar para os novos endereços IP que serão configurados para os novos pontos de extremidade de serviço. Os clientes se conectarão automaticamente aos novos pontos de extremidade de serviço, de duas maneiras:

  • Os clientes continuarão a tentar a conexão e devem se conectar automaticamente após o TTL expirar para a entrada original do DNS e após a entrada expirar do cache DNS do cliente. Os usuários também podem executar o comando ipconfig /flushdns a partir de um prompt de comando para limpar manualmente seu cache DNS. Ao usar o Outlook Web App, pode ser necessário fechar e reiniciar o navegador da Web para limpar o cache DNS usado pelo navegador. No Exchange 2010 SP1, o problema de cache do navegador da Web pode ser minimizado com a configuração do parâmetro FailbackURL no diretório virtual owa do Outlook Web App.

  • Os clientes que estão iniciando ou reiniciando executarão uma pesquisa de DNS na inicialização e obterão o novo endereço IP do ponto de extremidade de serviço, que será um servidor de Acesso para Cliente ou uma matriz no segundo datacenter.

Para validar o cenário com Loadgen, execute as seguintes ações:

  1. Altere a entrada de DNS da matriz de servidor de Acesso para Cliente de modo que aponte para o endereço IP virtual do balanceamento de carga de hardware do site secundário.

  2. Execute o ipconfig /flushdns comando em todos os servidores Loadgen.

  3. Reinicie o teste Loadgen.

  4. Verifique se os servidores de Acesso para Cliente no site secundário estão atendendo à carga.

Para validar o cenário com um cliente do Outlook 2007, execute o seguinte procedimento:

  1. Altere a entrada de DNS da matriz de servidor de Acesso para Cliente de modo que aponte para o endereço IP virtual do balanceamento de carga de hardware do site secundário.

  2. Execute o comando ipconfig /flushdns no cliente ou espere até que o TTL expire.

  3. Aguarde o cliente Outlook para reconectar.

Return to top

O processo de restauração de serviço de um datacenter com falha prévia é denominado failback. As etapas utilizadas na realização do failback de um datacenter são similares às etapas para a realização da alternância de um datacenter. Uma distinção significativa é que os failbacks dos datacenters são programados, e a duração da interrupção costuma ser muito menor.

É importante que o failback não seja realizado até que as dependências da infraestrutura do Exchange tenham sido reativadas, estejam em funcionamento e estáveis e tenham sido validadas. Se essas dependências não estiverem disponíveis ou íntegras, provavelmente, o processo de failback acarretará uma interrupção maior do que o necessário, e é possível que o processo falhe totalmente.

A função de servidor Caixa de Correio deve ser a primeira função a ser restaurada no datacenter primário. As seguintes etapas detalham o processo de failback da função de servidor Caixa de Correio (presumindo que o DAG esteja em modo DAC).

  1. Para reincorporar os membros do DAG ao site principal, execute o comando a seguir.

    Start-DatabaseAvailabilityGroup -Identity <DatabaseAvailabilityGroupIdParameter> -ActiveDirectorySite <insertsitename>
    
  2. Para verificar o estado das cópias de banco de dados no datacenter principal, execute o comando a seguir.

    Get-MailboxDatabaseCopyStatus
    

Após os servidores de Caixa de Correio do datacenter primário serem incorporados ao DAG, eles precisam de um tempo para sincronizar suas cópias do banco de dados. Dependendo da natureza da falha, da extensão da interrupção e das decisões tomadas pelo administrador durante a interrupção, pode ser necessário reenviar as cópias do banco de dados. Por exemplo, se durante a interrupção, você remover as cópias do banco de dados do datacenter principal com falha para permitir o truncamento do arquivo de log para as cópias ativas restantes no datacenter secundário, será necessário um novo seeding. Neste momento, cada banco de dados pode ser sincronizado individualmente. Depois que uma cópia replicada do banco de dados no datacenter principal estiver íntegra, é possível prosseguir para a próxima etapa.

  1. Durante o processo de alternância do datacenter, o DAG foi configurado para usar um servidor testemunha alternativo. Para reconfigurar o DAG para que use um servidor testemunha no datacenter principal, execute o comando a seguir.

    Set-DatabaseAvailabilityGroup -Identity <DAGName> -WitnessServer <PrimaryDatacenterWitnessServer>
    
  2. Os bancos de dados que são reativados no datacenter principal devem estar desmontados no datacenter secundário. Execute o seguinte comando.

    Get-MailboxDatabase | Dismount-Database
    
  3. Depois que os bancos de dados forem desmontados, os URLs do servidor de Acesso para Cliente devem ser movidos do datacenter secundário para o datacenter principal. Para fazer isso, altere o registro DNS dos URLs para que apontem para o servidor de Acesso para Cliente ou matriz no datacenter principal.

    ImportanteImportante:
    Não passe para a próxima etapa até que os URLs do servidor de Acesso para Cliente tenham sido movidos e a TTL do DNS e das entradas de cache tenham expirado. Ativar os bancos de dados no datacenter principal antes de mover os URLs do servidor de Acesso para Cliente para o datacenter principal resultará em uma configuração inválida (por exemplo, um banco de dados montado que não tem servidores de Acesso para Clientes em seu site do Active Directory).
  4. Para ativar os bancos de dados, execute um dos seguintes comandos.

    Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinSecondSite>
    

    ou

    Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>
    
  5. Para montar os bancos de dados, execute o comando a seguir:

    Get-MailboxDatabase <insertcriteriatoselectDBs> | Mount-Database
    

Critérios de sucesso: Os bancos de dados de caixa de correio ativa foram montados em servidores de Caixa de Correio no site principal. Para confirmar, execute o comando a seguir.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Return to top

O teste foi conduzido no Microsoft Enterprise Engineering Center, um laboratório de validação de soluções corporativas de primeira linha no campus principal da Microsoft em Redmond, Washington.

Com mais de 125 milhões de dólares em hardware e parcerias fortes em andamento com os maiores fabricantes de equipamentos originais (OEMs), praticamente todos os ambientes de produção podem ser replicados no EEC. O EEC oferece um ambiente que permite ampla colaboração entre clientes, parceiros e engenheiros de produto da Microsoft. Isso ajuda a garantir que as soluções de ponta a ponta da Microsoft atendam às altas expectativas dos clientes.

Return to top

A seção a seguir resume os resultados dos testes de validação funcional e de desempenho.

Return to top

A tabela a seguir resume os resultados de teste de validação funcional.

Resultados da validação funcional

Caso de teste Resultado Comments

Alternância de banco de dados

Bem sucedido

Concluído sem erro

Alternância de servidor

Bem sucedido

Concluído sem erro

Falha do servidor

Bem sucedido

Concluído sem erro

Falha no local

Bem sucedido

Concluído sem erro

Return to top

O teste contra todos os discos por site em um único quadro de armazenamento mostra que o CX4-480 lida com pouco mais de 8.000 IOPS transacionais do Exchange 2010 em oito VMs do Exchange configuradas com o perfil de usuário de 150 mensagens a 0,15 IOPS e um espaço adicional de 20%. O desempenho excedeu a linha de base de destino de 5.832 IOPS necessária para esta configuração e proporcionou algum espaço adicional para cargas de pico. As latências de disco estavam todas dentro dos parâmetros aceitáveis, de acordo com as práticas recomendadas da Microsoft para o desempenho do Exchange 2010.

Resultados de validação de projeto de armazenamento

E/S de banco de dados Valores-alvo 4 Servidores de caixa de correio em condições normais de funcionamento (2.700 usuários por servidor de caixa de correio) 4 Servidores de caixa de correio em uma condição de transição (5.400 usuários por servidor de caixa de correio) Total

Alcançado transacional IOPS (leituras de banco de dados de e/S/s + gravações de banco de dados de e/S/s)

1944 / 3888

3576 IOPS

4488 IOPS

8064 IOPS

Leituras de banco de dados de e/S/s

Não se aplica

2193

2729

4922

Gravações de banco de dados de e/S/s

Não se aplica

1439

1703

3142

Banco de dados de e/S lê latência média (MS)

<20 MS

14

18

16

Latência média (MS) de gravações de banco de dados de e/S

Não é um bom indicador de latência de cliente porque escreve de banco de dados são assíncronas

14

18

16

   

Gravações de Log de E/s

Não se aplica

1238

1560

2798

Log de e/S lê latência média (MS)

<10 MS

2

2

2

Return to top

As seções a seguir resumem os resultados de validação de design do servidor para os casos de teste.

LoadGen validação: cenários de teste

Teste Descrição

Operação normal

Uma carga simultânea de 100% para 10.800 usuários foi simulada em um site, com cada servidor de Caixa de Correio lidando com 2.700 usuários.

Falha de servidor único ou manutenção de servidor único (no site)

A falha de um único servidor de host do Hyper-V por site foi simulada. Uma carga simultânea de 100% foi executada contra um único host do Hyper-V com uma VM lidando com 5.400 usuários. Apenas três combinado de acesso para cliente e servidores de transporte de Hub manipulados a carga.

Falha no local

Uma falha de site foi simulada, e imagens secundárias em VMs de servidor de Caixa de Correio em espera foram ativadas. Uma carga simultânea de 100% foi executada contra 21.600 usuários em um único site.

Este caso de teste representa a carga de trabalho de pico durante condições normais de funcionamento. As condições normais de operação se referem a um estado no qual todos os bancos de dados ativos e passivos residem nos servidores nos quais se pretendia executá-los. Como este caso de teste não representa o pior cenário de carga de trabalho, ele não é o teste de validação de desempenho principal. Ele oferece um bom indicador de como será a operação do ambiente fora de um evento de falha ou manutenção do servidor. Neste teste, o objetivo foi validar todo o ambiente do Exchange em condições normais de operação com uma carga de pico. Todas as VMs Exchange estavam operando em condições normais. LoadGen foi configurado para simular a carga de pico. Esperava-se que o perfil de ação de 150 mensagens em execução em modo de pico gerasse o dobro de mensagens enviadas e entregues por segundo.

A taxa de entrega de mensagens verifica essa carga de trabalho testada correspondeu a carga de trabalho de destino. A taxa de entrega de mensagens é um pouco maior do que a meta, resultando em uma carga um pouco mais alta do que o perfil desejado.

 

Contador Destino Resultado testado

Taxa de entrega de mensagens por caixa de correio

15.0

15.2

As tabelas a seguir mostram os resultados da validação das VMs de servidor de caixa de correio principal.

Processador

Utilização do processador é abaixo de 70%, conforme o esperado.

 

Contador Destino Resultado testado

Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<70%

69

Armazenamento

Os resultados de armazenamento são bons. Todas as latências estão sob os valores de destino.

 

Contador Destino Resultado testado

Banco de dados do MSExchange\Latência média de leituras (anexadas) do banco de dados de E/S

<20 MS

19

Banco de dados do MSExchange\Latência média de gravações (anexadas) do banco de dados de E/S

<20 MS

<Lê média

18

Banco de dados\Paralisações de falhas de página do banco dedados /s

0

0

Banco de dados do MSExchange\Latência média de gravações do log de E/S

<20 MS

5

Banco de dados\Paralisações de registro de log /s

0

0

Aplicativo saúde

O Exchange tem muita integridade, e todos os contadores usados para determinar a integridade dos aplicativos estão bem abaixo dos valores desejados.

 

Contador Destino Resultado testado

MSExchangeIS\Solicitações RPC

<70

3.0

MSExchangeIS\Latência Média de RPC

<10 MS

2.0

Caixa de Correio do MSExchangeIS(_Total)\Mensagens em Fila para Envio

0

2.0

As tabelas a seguir mostram os resultados da validação das VMs de servidor de Caixa de Correio secundária.

Processador

Utilização do processador é abaixo de 70%, conforme o esperado.

 

Contador Destino Resultado testado

Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<70%

26

Armazenamento

Os resultados de armazenamento são bons. Todas as latências estão sob os valores de destino.

 

Contador Destino Resultado testado

Banco de dados do MSExchange\Latência média de leituras (de recuperação) do banco de dados de E/S

<100 MS

0

Banco de dados do MSExchange\Latência média de gravações (de recuperação) do banco de dados de E/S

<100 MS

<Lê média

16

Banco de dados\Paralisações de falhas de página do banco dedados /s

0

0

Banco de dados do MSExchange\Latência média de gravações do log de E/S

<20 MS

3

Banco de dados\Paralisações de registro de log /s

0

0

Aplicativo saúde

Os servidores de Caixa de Correio secundária só estão mantendo as terceiras cópias passivas de banco de dados, portanto os indicadores padrão de integridade do Exchange não se aplicam a este cenário.

 

Contador Destino Resultado testado

MSExchangeIS\Solicitações RPC

<70

Não se aplica

MSExchangeIS\Latência Média de RPC

<10 MS

Não se aplica

Caixa de Correio do MSExchangeIS(_Total)\Mensagens em Fila para Envio

0

Não se aplica

As tabelas a seguir mostram os resultados da validação das VMs de servidor de Acesso para Cliente e Transporte de Hub.

Processador

Utilização do processador é baixa, como esperado.

 

Contador Destino Resultado testado

Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<70%

48

Armazenamento

Os resultados de armazenamento com boas aspecto. As latências muito baixas não devem ter nenhum impacto sobre o transporte de mensagem.

 

Contador Destino Resultado testado

Disco Lógico/Físico(*)\Média Disco s/Leitura

<20 MS

0.001

Disco Lógico/Físico(*)\Média Disco s/Gravação

<20 MS

0.005

Aplicativo saúde

Os valores baixos de latência média de RPC confirmam um servidor de Acesso para Cliente íntegro sem impacto na experiência do cliente.

 

Contador Destino Resultado testado

MSExchange RpcClientAccess\Latência média de RPC

<250 MS

8

MSExchange RpcClientAccess\Solicitações RPC

<40

3

Os contadores de Filas de Transporte estão todos bem abaixo da meta, confirmando que o servidor de Transporte de Hub está íntegro e que é capaz de processar e entregar as mensagens exigidas.

 

Contador Destino Resultado testado

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Entrega Agregada (Todas as Filas)

<3000

2.5

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Entrega Remota Ativa

<250

0

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Entrega de Caixa de Correio Ativa

<250

2.3

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Envio

<100

0

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Repetição de Entrega de Caixa de Correio

<100

0.3

As tabelas a seguir mostram os resultados da validação do servidor raiz Hyper-V.

Processador

Conforme o esperado, a utilização do processador é muito baixa e está bem abaixo dos limites de destino.

 

Contador Destino Resultado testado

Processador Lógico do Hipervisor do Hyper-V(_total)\% Tempo de Execução do Convidado

<75%

66

Processador Lógico do Hipervisor do Hyper-V(_total)\% Tempo de Execução do Hipervisor

<5%

2

Processador Lógico do Hipervisor do Hyper-V(_total)\% Tempo de Execução Total

<80%

68

Processador Virtual Raiz do Hipervisor do Hyper-V(_total)\% Tempo de Execução do Convidado

<5%

3

Aplicativo saúde

Os contadores do Resumo de Integridade de Máquina Virtual indicam que todas as VMs estão em estado íntegro.

 

Contador Destino Resultado testado

Resumo de Integridade do Virtual Machine do Hyper-V\Integridade Crítica

0

0

Neste teste, o objetivo foi validar todo o ambiente do Exchange em condições de operação de manutenção ou falha do servidor raiz físico do Hyper-V com uma carga de pico. Todas as VMs em execução em um dos servidores raiz do Hyper-V no site foram desativados para simular uma condição de manutenção de host. Isso resultou em imagens de bancos de dados (cópias) sendo movidas para outras VMs de servidor de Caixa de Correio, o que criou uma condição operacional de 5.400 usuários por VM de servidor de Caixa de Correio. Apenas metade dos servidores combinados de Acesso para Cliente e Transporte de Hub processou o acesso para cliente e a entrega de email.

A taxa de entrega de mensagem real foi no alvo.

 

Contador Destino Resultado testado

Taxa de entrega de mensagem por servidor

30

30

As tabelas a seguir mostram os resultados da validação das VMs de servidor de caixa de correio principal.

Processador

Utilização do processador é pouco mais de destino. Este caso de teste representa um cenário de falha ou manutenção em carga de pico, e portanto seria um evento de baixa ocorrência. Você não gostaria que a utilização do processador permanecesse tão alta por um longo período.

 

Contador Destino Resultado testado

Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<80%

83

Armazenamento

Resultados de armazenamento olhar aceitáveis. A média de leitura latência é pouco mais de destino. A latência de gravação do banco de dados média é superior ao preferencial. Isso ocorre durante o pior cenário de falha sob carga de pico, um evento de baixa ocorrência. As altas latências não levam os contadores de integridade de aplicativos além da meta, portanto a experiência de usuário ainda deve ser aceitável. Você não gostaria que a latência permanecesse tão alta por um longo período.

 

Contador Destino Resultado testado

Banco de dados do MSExchange\Latência média de leituras (anexadas) do banco de dados de E/S

<20 MS

20.5

Banco de dados do MSExchange\Latência média de gravações (anexadas) do banco de dados de E/S

<20 MS

23

Banco de dados\Paralisações de falhas de página do banco dedados /s

0

0

Banco de dados do MSExchange\Latência média de gravações do log de E/S

<20 MS

8

Banco de dados\Paralisações de registro de log /s

0

0

Aplicativo saúde

Os contadores de mostraram que o Exchange ainda é razoavelmente saudável. Alguns enfileiramento de mensagens sob carga de pico está começando a ocorrer. Você não gostaria que isso continuar por um longo período de tempo.

 

Contador Destino Resultado testado

MSExchangeIS\Solicitações RPC

<70

9.0

MSExchangeIS\Latência Média de RPC

<10 MS

2.0

Caixa de Correio do MSExchangeIS(_Total)\Mensagens em Fila para Envio

0

77

As tabelas a seguir mostram os resultados da validação das VMs de servidor de Caixa de Correio secundária.

Processador

Utilização do processador é abaixo de 70%, conforme o esperado.

 

Contador Destino Resultado testado

Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<70%

21

Armazenamento

Os resultados de armazenamento são bons. Todas as latências estão sob os valores de destino.

 

Contador Destino Resultado testado

Banco de dados do MSExchange\Latência média de leituras (de recuperação) do banco de dados de E/S

<100 MS

0

Banco de dados do MSExchange\Latência média de gravações (de recuperação) do banco de dados de E/S

<100 MS

<Lê média

21

Banco de dados\Paralisações de falhas de página do banco dedados /s

0

0

Banco de dados do MSExchange\Latência média de gravações do log de E/S

<20 MS

3

Banco de dados\Paralisações de registro de log /s

0

0

Aplicativo saúde

Os servidores de Caixa de Correio secundária só estão mantendo as terceiras cópias passivas de banco de dados, portanto os indicadores padrão de integridade do Exchange não se aplicam a este cenário.

 

Contador Destino Resultado testado

MSExchangeIS\Solicitações RPC

<70

Não se aplica

MSExchangeIS\Latência Média de RPC

<10 MS

Não se aplica

Caixa de Correio do MSExchangeIS(_Total)\Mensagens em Fila para Envio

0

Não se aplica

As tabelas a seguir mostram os resultados da validação das VMs de servidor de Acesso para Cliente e Transporte de Hub.

Processador

A utilização do processador está abaixo de 80%, conforme o esperado.

 

Contador Destino Resultado testado

Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<80%

74

Armazenamento

Os resultados de armazenamento com boas aspecto. As latências muito baixas não devem ter nenhum impacto sobre o transporte de mensagem.

 

Contador Destino Resultado testado

Disco Lógico/Físico(*)\Média Disco s/Leitura

<20 MS

0.001

Disco Lógico/Físico(*)\Média Disco s/Gravação

<20 MS

0.008

Aplicativo saúde

Os valores baixos de latência média de RPC confirmam um servidor de Acesso para Cliente íntegro sem impacto na experiência do cliente.

 

Contador Destino Resultado testado

MSExchange RpcClientAccess\Latência média de RPC

<250 MS

18

MSExchange RpcClientAccess\Solicitações RPC

<40

14

Os contadores de Filas de Transporte estão todos bem abaixo da meta, confirmando que o servidor de Transporte de Hub está íntegro e que é capaz de processar e entregar as mensagens exigidas.

 

Contador Destino Resultado testado

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Entrega Agregada (Todas as Filas)

<3000

49

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Entrega Remota Ativa

<250

0

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Entrega de Caixa de Correio Ativa

<250

43

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Envio

<100

53

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Repetição de Entrega de Caixa de Correio

<100

4

As tabelas a seguir mostram os resultados da validação do servidor raiz Hyper-V.

Processador

A utilização do processador está próxima aos limites de destino, o que é esperado para o cenário de falha ou manutenção sob carga de pico.

 

Contador Destino Resultado testado

Processador Lógico do Hipervisor do Hyper-V(_total)\% Tempo de Execução do Convidado

<75%

77

Processador Lógico do Hipervisor do Hyper-V(_total)\% Tempo de Execução do Hipervisor

<5%

2

Processador Lógico do Hipervisor do Hyper-V(_total)\% Tempo de Execução Total

<80%

79

Processador Virtual Raiz do Hipervisor do Hyper-V(_total)\% Tempo de Execução do Convidado

<5%

3

Aplicativo saúde

Os contadores do Resumo de Integridade de Máquina Virtual indicam que todas as VMs estão em estado íntegro.

 

Contador Destino Resultado testado

Resumo de Integridade do Virtual Machine do Hyper-V\Integridade Crítica

0

0

O teste simula uma falha de site alternando os bancos de dados ativos no site principal para os bancos de dados passivos no site secundário, resultando em 21.600 caixas de correio ativas em um site. As quatro VMs de servidor de caixa de correio principal no site sobrevivente estão executando uma carga de trabalho normal de 2.700 caixas de correio ativas cada. As quatro VMs de servidor de caixa de correio secundária no site sobrevivente estão executando agora 2.700 caixas de correio ativas cada. Cada servidor de raiz do Hyper-V hospeda caixas de correio ativas 5.400.

A taxa de entrega de mensagens é um pouco maior do que a meta, resultando em uma carga um pouco mais alta do que o perfil desejado.

 

Contador Destino Resultado testado

Taxa de entrega de mensagem por servidor

15

15.1

As tabelas a seguir mostram os resultados da validação das VMs de servidor de caixa de correio principal.

Processador

As VMs de servidor de caixa de correio principal estão executando uma carga de trabalho normal, e estão sob a meta de utilização do processador, conforme o esperado.

 

Contador Destino Resultado testado

Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<70%

63

Armazenamento

Os resultados de armazenamento são bons. Todas as latências estão sob os valores de destino.

 

Contador Destino Resultado testado

Banco de dados do MSExchange\Latência média de leituras (anexadas) do banco de dados de E/S

<20 MS

12

Banco de dados do MSExchange\Latência média de gravações (anexadas) do banco de dados de E/S

<20 MS

13

Banco de dados\Paralisações de falhas de página do banco dedados /s

0

0

Banco de dados do MSExchange\Latência média de gravações do log de E/S

<20 MS

4

Banco de dados\Paralisações de registro de log /s

0

0

Aplicativo saúde

O Exchange tem muita integridade, e todos os contadores usados para determinar a integridade dos aplicativos estão bem abaixo dos valores desejados.

 

Contador Destino Resultado testado

MSExchangeIS\Solicitações RPC

<70

3.0

MSExchangeIS\Latência Média de RPC

<10 MS

2.0

Caixa de Correio do MSExchangeIS(_Total)\Mensagens em Fila para Envio

0

3

As tabelas a seguir mostram os resultados da validação das VMs de servidor de Caixa de Correio secundária.

Processador

Utilização do processador é apenas sobre o destino de 80 por cento. O valor está acima do ideal, mas não parece afetar outros contadores de integridade do Exchange. Como este teste representa a carga de pico durante um evento de baixa ocorrência de falha de site, não há problema. Não seria bom manter esse nível de utilização de processador por um longo período.

 

Contador Destino Resultado testado

Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<80%

84

Armazenamento

Os resultados de armazenamento são bons. Todas as latências estão sob os valores de destino.

 

Contador Destino Resultado testado

Banco de dados do MSExchange\Latência média de leituras (anexadas) do banco de dados de E/S

<20 MS

17

Banco de dados do MSExchange\Latência média de gravações (anexadas) do banco de dados de E/S

<20 MS

<Lê média

12

Banco de dados\Paralisações de falhas de página do banco dedados /s

0

0

Banco de dados do MSExchange\Latência média de gravações do log de E/S

<20 MS

3

Banco de dados\Paralisações de registro de log /s

0

0

Aplicativo saúde

Os contadores de mostram a troca é saudável. Há uma pequena quantidade de enfileiramento de mensagens.

 

Contador Destino Resultado testado

MSExchangeIS\Solicitações RPC

<70

3

MSExchangeIS\Latência Média de RPC

<10 MS

2

Caixa de Correio do MSExchangeIS(_Total)\Mensagens em Fila para Envio

0

106

As tabelas a seguir mostram os resultados da validação das VMs de servidor de Acesso para Cliente e Transporte de Hub.

Processador

A utilização do processador está abaixo de 80%, conforme o esperado.

 

Contador Destino Resultado testado

Processador Virtual do Hipervisor do Hyper-V\% Tempo de Execução do Convidado

<70%

63

Armazenamento

Os resultados de armazenamento com boas aspecto. As latências muito baixas não devem ter nenhum impacto sobre o transporte de mensagem.

 

Contador Destino Resultado testado

Disco Lógico/Físico(*)\Média Disco s/Leitura

<20 MS

0.002

Disco Lógico/Físico(*)\Média Disco s/Gravação

<20 MS

0.003

Aplicativo saúde

Os valores baixos de latência média de RPC confirmam um servidor de Acesso para Cliente íntegro sem impacto na experiência do cliente.

 

Contador Destino Resultado testado

MSExchange RpcClientAccess\Latência média de RPC

<250 MS

9

MSExchange RpcClientAccess\Solicitações RPC

<40

7

Os contadores de Filas de Transporte estão todos bem abaixo da meta, confirmando que o servidor de Transporte de Hub está íntegro e que é capaz de processar e entregar as mensagens exigidas.

 

Contador Destino Resultado testado

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Entrega Agregada (Todas as Filas)

<3000

5

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Entrega Remota Ativa

<250

0

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Entrega de Caixa de Correio Ativa

<250

4

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Envio

<100

0

\Filas MSExchangeTransport(_total)\Comprimento da Fila de Repetição de Entrega de Caixa de Correio

<100

1

As tabelas a seguir mostram os resultados da validação do servidor raiz Hyper-V.

Processador

Utilização do processador é sobre o destino de 80 por cento. Como este teste representa a carga de pico durante um evento de baixa ocorrência de falha de site, não há problema. Não seria bom manter esse nível de utilização de processador por um longo período.

 

Contador Destino Resultado testado

Processador Lógico do Hipervisor do Hyper-V(_total)\% Tempo de Execução do Convidado

<75%

85

Processador Lógico do Hipervisor do Hyper-V(_total)\% Tempo de Execução do Hipervisor

<5%

2

Processador Lógico do Hipervisor do Hyper-V(_total)\% Tempo de Execução Total

<80%

87

Processador Virtual Raiz do Hipervisor do Hyper-V(_total)\% Tempo de Execução do Convidado

<5%

3

Aplicativo saúde

Os contadores do Resumo de Integridade de Máquina Virtual indicam que todas as VMs estão em estado íntegro.

 

Contador Destino Resultado testado

Resumo de Integridade do Virtual Machine do Hyper-V\Integridade Crítica

0

0

Return to top

Este white paper oferece um exemplo de como criar, testar e validar uma solução Exchange 2010 para ambientes de cliente com 32.400 caixas de correio em vários sites implantada em hardware Cisco e EMC. A metodologia passo a passo deste documento cobre os pontos importantes de decisões de design que ajudam a lidar com desafios essenciais, garantindo que os requisitos principais dos negócios sejam atendidos.

Return to top

Para obter a documentação completa do Exchange 2010, consulte Exchange Server 2010.

Para obter informações adicionais relacionadas com a Cisco e a EMC, consulte os seguintes recursos:

Este documento é fornecido "na forma em que se encontra". As informações e os pontos de vista expressos neste documento, incluindo URLs e outras referências a sites na Internet, estão sujeitos a alteração sem aviso prévio. Você assume o risco de usá-lo.

Este documento não lhe dá nenhum direito legal a qualquer propriedade intelectual de qualquer produto Microsoft. Você pode copiar e usar este documento para fins de referência, internos.

Return to top

 
Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft