Noções Básicas Sobre Fatores de Alta Disponibilidade

 

Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Tópico modificado em: 2015-03-09

Ao planejar uma arquitetura de banco de dados e um servidor de Caixa de Correio de disponibilidade alta, as decisões de projeto devem ser consideradas, como:

• Você implantará várias cópias de banco de dados?

• Quantas cópias do banco de dados serão implantadas?

• Você terá uma arquitetura que forneça resiliência de site?

• Qual tipo de modelo de resiliência de servidor de Caixa de Correio você implantará?

• Quantos servidores de Caixa de Correio serão implantados?

• Como você distribuirá as cópias de banco de dados?

• Qual modelo de backup será usado?

• Qual arquitetura de armazenamento será usada?

O Microsoft Exchange Server 2010 permite implantar sua infraestrutura de servidor de Caixa de Correio usando servidores de Caixa de Correio autônomos ou configurados para resiliência de caixa de correio. Os servidores de caixa de correio configurados para resiliência de caixa de correio empregam um grupo de disponibilidade de banco de dados (DAG) com várias cópias de banco de dados eficientemente distribuídas em todo o DAG. Ao implantar várias cópias do banco de dados, você poderá:

• Projetar uma solução que diminua a razão mais comum para fazer um backup. Cópias de bancos de dados oferecem proteção contra falhas no data center, software e hardware.

• Aumentar o tamanho dos bancos de dados para até 2 terabytes, pois o seu mecanismo de recuperação é outra cópia do banco de dados e não uma restauração do backup.

• Considerar alternativas de arquitetura de armazenamento a uma configuração RAID tradicional, como JBOD, se você implantar três ou mais cópias de banco de dados. A combinação de JBOD e discos menos caros pode resultar em reduções de custos para a sua organização.

Distribuir bancos de dados ativos por todos os servidores que fazem parte de um grupo de disponibilidade de banco de dados (DAG), para maximizar a eficiência do seu hardware.

Para mais informações detalhadas, consulte Planejamento da alta disponibilidade e resiliência do site e Understanding Backup, Restore and Disaster Recovery.

Conteúdo

Planejando o número de cópias de banco de dados a serem implantadas

Tipos de cópia de banco de dados

Resiliência do site

Planejando o modelo de resiliência de servidor de Caixa de Correio

Planejando o número de servidores de Caixa de Correio a serem implantados

Planejando o layout de cópia de banco de dados

Planejando a arquitetura de modelo de backup

Planejando a arquitetura de modelo de armazenamento

Procurando tarefas de gerenciamento relacionadas à alta disponibilidade? Consulte Gerenciando a alta disponibilidade e resiliência do site.

Planejando o número de cópias de banco de dados a serem implantadas

Como discutido em Noções Básicas Sobre Cópias do Banco de Dados de Caixa de Correio, um membro do DAG pode hospedar uma cópia de cada banco de dados de caixa de correio, com um máximo de 100 bancos de dados por servidor na Enterprise Edition do produto (contagem de cópias ativas e passivas para esse limite). Isso significa que há um limite de 1.600 bancos de dados com suporte por um DAG de 16 membros (100 cópias de banco de dados por servidor × 16 servidores por DAG ÷ 1 cópia por banco de dados = 1.600 bancos de dados por DAG).

Em uma configuração de alta disponibilidade, não há nenhum valor para implantar uma única cópia de um banco de dados porque ele não fornece redundância de dados. Você usa uma fórmula para determinar o número de bancos de dados que um DAG específico pode suportar. Por exemplo, se você escolher D para ser o número de bancos de dados sendo implantados, C para ser o número de cópias de cada banco de dados e S para ser o número de servidores, o seguinte se aplicará:

• D × C = número total de cópias de banco de dados no DAG

• (D × C) ÷ S = cópias de banco de dados por servidor

Dica

O número resultante de bancos de dados por servidor deve ser 100 ou menos quando se utiliza o Enterprise Edition e 5 ou menos quando se utiliza Standard Edition.

Por exemplo, vamos considerar que você tenha um DAG com 6 servidores e 84 bancos de dados de caixa de correio, com 3 cópias de cada banco de dados. (Observe que 6 servidores são um inteiro múltiplo de 3 cópias.) O seguinte se aplica:

• 84 bancos de dados × 3 cópias = 252 bancos de dados no total

• 252 bancos de dados ÷ 6 servidores = 42 cópias de bancos de dados por servidor

Em outro exemplo, você tem um DAG com 4 servidores e 136 bancos de dados de caixa de correio, com 3 cópias de cada banco de dados. O seguinte se aplica:

• 136 bancos de dados × 3 cópias = 408 bancos de dados no total

• 408 bancos de dados ÷ 4 servidores = 102 cópias de bancos de dados por servidor

Como 102 é maior que 100, o cenário proposto não é um projeto de DAG válido.

Voltar ao início

Tipos de cópia de banco de dados

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

• Cópias de banco de dados com disponibilidade alta

• Cópias de banco de dados com retardamento

As cópias de banco de dados de disponibilidade alta são as configuradas com um tempo de retardo de repetição de zero. Como o próprio nome diz, as cópias de banco de dados de disponibilidade alta são mantidas atualizadas pelo sistema, podem ser automaticamente ativadas pelo sistema e são usadas para fornecer alta disponibilidade para dados e serviço de caixa de correio.

As cópias de banco de dados com retardamento são as configuradas 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).

Em geral, as cópias de banco de dados com retardamento não são ativadas devido ao algoritmo de seleção de melhor cópia do Active Manager. Como as cópias de banco de dados com retardamento são implantadas para reduzir os riscos operacionais, elas não deverão ser ativadas. Se ativadas e se uma solicitação de montagem for emitida, a reprodução do log começará, reproduzindo todos os arquivos de log necessários para atualizar o banco de dados e deixá-lo em um estado de desligamento limpo, dessa forma, ocorrerá a perda do recurso de ponto no tempo.

Para mais informações sobre como bloquear a ativação no nível de servidor de Caixa de Correio ou suspender a ativação para uma ou mais cópias a fim de impedir que uma cópia de banco de dados (como a de banco de dados com retardamento) seja ativada automaticamente, consulte Set-MailboxServer e Suspend-MailboxDatabaseCopy.

Voltar ao início

Resiliência do site

O ambiente pode ser composto por vários data centers. Como parte do seu projeto do Exchange 2010, determine se você implantará a infraestrutura do Exchange em um único data center ou a distribuirá entre dois ou mais data centers. Os acordos de nível de serviço (SLAs) de recuperação de sua organização deverão definir qual nível de serviço será necessário após a falha de um data center principal.

Caso a sua implantação do Exchange seja implantada entre vários data centers para suporte aos objetivos de resiliência de site, considere qual modelo de distribuição do usuário se aplica. Há dois tipos de modelos de distribuição de usuário, com base na localidade de caixa de correio com relação ao data center:

• Modelo de distribuição de usuário ativo/passivo

• Modelo de distribuição de usuário ativo/ativo

Se as caixas de correio estiverem localizadas principalmente em um data center único (ou se os usuários acessarem seus dados por meio de um único data center) e houver uma solicitação de SLA de que os usuários devem continuar acessando seus dados por meio do data center principal durante as operações normais, sua arquitetura será um modelo de distribuição do usuário ativo/passivo.

Se as caixas de correio do usuários ficarem dispersas em data centers e houver um requisito de SLA de que os usuários devem continuar acessando seus dados por meio do data center principal durante as operações normais, sua arquitetura será um modelo de distribuição do usuário ativo/ativo.

Em um modelo de distribuição de usuário ativo/passivo, você pode implantar sua arquitetura como mostrada na seguinte figura, em que as caixas de correio ativas são hospedadas a partir do data center principal, mas as cópias de banco de dados são implantadas no data center secundário.

Modelo de distribuição de usuário ativo/passivo com dois data centers

A arquitetura mostrada na seguinte figura poderá ser usada potencialmente para um modelo de distribuição do usuário ativo/ativo.

Modelo de distribuição de usuário ativo/ativo com dois data centers

Entretanto, existe um risco com a arquitetura mostrada na figura anterior. A rede de longa distância (WAN) é um ponto de falha único para o DAG. A perda da WAN resultará na perda de quórum para os membros do DAG no segundo data center. Nesse exemplo, o cluster de failover do Windows tem um total de cinco votos (quatro membros do DAG mais o servidor testemunha), o que exige que três votos estejam disponíveis sempre para que o cluster de failover continue operacional. Três dos votos estão localizados no data center de Redmont e dois deles estão no data center de Portland. A perda da conexão da WAN faz com que o data center de Portland hospede apenas dois dos votos, o que não é suficiente para manter o quórum. O data center de Redmont tem três votos e assim pode manter o quórum e continuar atendendo as caixas de correio ativas (assim que os três votos estiverem operacionais).

Para reduzir esse risco dos modelos de distribuição do usuário ativo/ativo, recomendamos implantar dois DAGs, como mostrado na seguinte figura.

Dois DAGs para o modelo de distribuição do usuário ativo/ativo

O DAG1 hospeda as caixas de correio ativas do data center de Redmond e é implementado como um modelo de distribuição do usuário ativo/passivo, com as cópias de banco de dados passivas implantadas no data center de Portland. O DAG2 hospeda as caixas de correio ativas do data center de Portland e é implementado como um modelo de distribuição do usuário ativo/passivo, com as cópias de banco de dados passivas implantadas no data center de Redmond.

Essa arquitetura pode sobreviver à perda da WAN:

• No data center de Redmond, os membros do servidor de Caixa de Correio para DAG2 falham devido à perda de quórum, mas os membros do servidor de Caixa de Correio ativos para DAG1 permanecem operacionais, atendendo aos usuários.

• No data center de Portland, os membros do servidor de Caixa de Correio para DAG1 falham devido à perda de quórum, mas os membros do servidor de Caixa de Correio ativos para DAG2 permanecem operacionais, atendendo aos usuários.

Para mais informações, consulte Planejamento da alta disponibilidade e resiliência do site.

Voltar ao início

Planejando o modelo de resiliência de servidor de Caixa de Correio

Um aspecto-chave do planejamento da capacidade do servidor de Caixa de Correio do Exchange 2010 é determinar quantas cópias do banco de dados você planeja ativar por servidor, quando configuradas para resiliência de caixa de correio. Uma variedade de projetos é possível, mas dois modelos são recomendados, como descrito nas seções seguintes.

Projetos para todas as cópias ativadas de banco de dados

Você pode projetar a arquitetura do seu servidor para manipular 100 por cento de todas as cópias de banco de dados hospedadas se tornando ativas. Por exemplo, se o seu servidor hospedar 35 cópias de banco de dados, você faz o projeto com processador e memória para acomodar todos os 35 bancos de dados se tornando ativos durante o horário de pico da atividade do usuário. Essa solução é geralmente implantada em pares. Por exemplo, se forem implantados quatro servidores, um par será os servidores 1 e 2, e o segundo par será os servidores 3 e 4. Além disso, durante o projeto desse cenário, você dimensiona cada servidor para não mais do que 40% dos recursos disponíveis para operações em tempo de execução normais.

Dos dois modelos discutidos neste tópico, esse modelo tem uma contagem de servidores mais alta.

Projeto para cenários de falha direcionados

Você pode projetar a arquitetura do servidor para manipular a carga da caixa de correio ativa durante o pior caso de falha que você pretende acomodar. Há vários fatores para considerar neste modelo, incluindo a resiliência de site; armazenamento RAID versus JBOD; tamanho do DAG; e número de cópias do banco de dados. Esse modelo de planejamento de capacidade oferece um equilíbrio entre custos, disponibilidade e características de desempenho de cliente.

Considerando que as cópias de banco de dados sejam distribuídas aleatória e uniformemente:

• Projete falha de servidor de membro único automática nas configurações do DAG de dois ou três membros, com duas cópias de banco de dados com disponibilidade alta por banco de dados de caixa de correio.

• Projete falha de servidor com dois membros (ativação manual após segunda falha) nas configurações do DAG de três membros, com três cópias de banco de dados com disponibilidade alta por banco de dados de caixa de correio.

• Projete falha de servidor com dois membros automática, em que o DAG tem quatro ou mais membros e três ou mais cópias de banco de dados com disponibilidade alta por banco de dados de caixa de correio.

Se você selecionar esse modelo de planejamento de capacidade, recomendamos enfaticamente que você restrinja o número de bancos de dados que podem ser ativados por servidor, para que o servidor único não fique sobrecarregado e proporcione uma experiência ruim ao cliente.

Você pode restringir o número de banco de dados, definindo a configuração máxima de banco de dados ativos. Você pode configurar esse limite no Shell de Gerenciamento do Exchange, executando Set-MailboxServer -MaximumActiveDatabases. Configure esse limite em cada servidor no DAG, para corresponder ao máximo aos bancos de dados ativos com o suporte de sua implantação.

Para mais informações, consulte Exemplos de design do grupo de disponibilidade do banco de dados.

Voltar ao início

Planejando o número de servidores de Caixa de Correio a serem implantados

Ao determinar o número de servidores de Caixa de Correio a serem implantados, use um múltiplo do número de cópias de banco de dados sendo implantadas. Por exemplo, se você quiser implantar três cópias de banco de dados, comece o projeto com 3, 6, 9, 12 ou 15 servidores.

Após determinar o ponto de partida do número de servidores no DAG, dimensione os membros do DAG corretamente com base no número de caixas de correio, no modelo de projeto de falhas e em outras restrições de projeto que possam aumentar ou reduzir o número necessário de servidores de Caixa de Correio.

Uma restrição de projeto que muitas organizações têm é um número máximo de caixas de correio que podem ser armazenadas em um servidor. Por exemplo, se uma organização tiver 20.000 caixas de correio e apenas 25% delas forem afetadas durante um evento de falha, o número máximo de caixas de correio que poderá ser implantado em um único servidor será 5.000. Isso exige a implantação de no mínimo quatro servidores de Caixa de Correio.

O modelo de armazenamento e o hardware de servidor selecionados podem também causar o ajuste do número de caixas de correio ou cópias de banco de dados que você implanta por servidor, o que pode afetar o número total de servidores de Caixa de Correio.

Servidores com várias funções versus servidores com função autônoma

No Exchange Server 2007, as funções de servidor de Acesso para Cliente e Transporte de Borda devem estar em servidores separados dos servidores de Caixa de Correio em cluster. No Exchange 2010, os servidores de Caixa de Correio em cluster não existem mais, portanto essa restrição não mais se aplica. As funções de servidor de Acesso para Cliente e de Transporte de Borda podem ser hospedadas em membros do DAG, fornecendo opções de implantação aprimoradas.

Na implantação de servidores com várias funções (Caixa de Correio, Acesso para Cliente e Transporte de Borda no mesmo servidor), a maioria das arquiteturas é simplificada. Com exceção dos servidores de Transporte de Borda e de Unificação de Mensagens, todos os servidores do Exchange 2010 podem ser idênticos. Esses servidores podem ter o mesmo processo de instalação de hardware e software e as mesmas opções de configuração. A consistência entre os servidores pode simplificar a administração da implementação do Exchange.

O servidor de várias funções (em ambientes de escala alta) permite um uso mais eficiente de servidores com vários núcleos, o que proporciona recursos de megaciclos altos. Cada função, quando implantada individualmente, tem um máximo recomendado de dois soquetes de processador ocupados. Quando as funções são combinadas, o número máximo recomendado de soquetes de processador é quatro. Os servidores podem ter cargas de trabalho maiores, o que pode reduzir o número geral de servidores em uma organização. A implantação de menos servidores reduz o custo de gerenciamento desses servidores, porque o servidor com várias funções muda o custo de uma despesa operacional recorrente para uma despesa de capital única. Uma contagem de servidores reduzida pode resultar em potência significativa e reduções do espaço do data center, o que pode reduzir também as despesas operacionais recorrentes.

Embora o conceito de várias funções seja eficiente, as funções de servidor autônomas ainda poderão ser apropriadas. Por exemplo, as implantações de função autônomas podem ser apropriadas em certos ambientes virtualizados ou quando determinadas arquiteturas de hardware (por exemplo, uma infraestrutura de servidores blade em que não é possível isolar o hardware corretamente) estiverem em uso.

Ao implantar servidores com várias funções, você deverá projetar a arquitetura de processador e memória corretamente. A partir de uma perspectiva de processador, você deverá garantir que a função de servidor de Caixa de Correio não consuma mais do que 40% dos megaciclos disponíveis durante o modo de falha, deixando 40% para as funções de servidor de Transporte de Hub e Acesso para Cliente. Para assegurar que a memória adequada esteja disponível para todas as funções de servidor, siga a orientação de memória definida em Noções Básicas Sobre o Cache do Banco de Dados de Caixa de Correio.

Para mais informações, consulte Noções Básicas Sobre Várias Configurações de Função de Servidor no Planejamento da Capacidade.

Voltar ao início

Planejando o layout de cópia de banco de dados

Como parte do projeto de alta disponibilidade, você precisará projetar um layout de cópia de banco de dados balanceado. Os seguintes princípios de projeto devem ser usados ao se planejar o layout de cópia de banco de dados:

• Garanta a redução das várias falhas de cópia de banco de dados de um banco de dados de caixa de correio específico isolando cada cópia Por exemplo, não coloque mais de uma única cópia de banco de dados de um banco de dados de caixa de correio específica no mesmo rack de servidor de banco de dados ou na mesma matriz de armazenamento. Caso contrário, um falha de rack ou de matriz ocorrerá em caso de falha de várias cópias do mesmo banco de dados, o que afeta a disponibilidade do banco de dados.

• Projete o layout das cópias de banco de dados de modo consistente e distribuído para assegurar que os bancos de dados de caixa de correio ativos sejam distribuídos uniformemente após uma falha. A soma das preferências de ativação de cada cópia de banco de dados em qualquer servidor específico deverá ser igual ou quase igual, porque isso resulta em uma distribuição igual aproximadamente após a falha, considerando que a replicação esteja íntegra e atualizada.

Para mais informações, consulte Design de layout de cópia de banco de dados.

Voltar ao início

Planejando a arquitetura de modelo de backup

O Exchange 2010 inclui vários recursos e alterações de arquitetura que, quando implantados e configurados corretamente, podem oferecer proteção de dados nativa que elimina a necessidade de fazer backups tradicionais de seus dados. Use a seguinte tabela para decidir se precisa continuar utilizando um modelo de backup tradicional ou se é possível implementar os recursos de proteção de dados nativos no Exchange 2010.

Problema	Atenuação
Falhas de software	Resiliência de caixa de correio (várias cópias de banco de dados)
Falhas de hardware	Resiliência de caixa de correio (várias cópias de banco de dados)
Falhas de site ou de data center	Resiliência de caixa de correio (várias cópias de banco de dados)
Exclusão acidental ou proposital de itens	Recuperação de item único e retenção de item excluído com uma janela que atende ou excede o SLA de recuperação de itens
Cenários de danos físicos	Restauração de página única (cópias de banco de dados com disponibilidade alta)
Cenários de danos lógicos	Recuperação de item único Assistente de Reparo de Calendário Movimentações da caixa de correio Cmdlet New-MailboxRepairRequest Backup de ponto no tempo
Erros administrativos	Backup de ponto no tempo
Erros de automação	Backup de ponto no tempo
Administradores não autorizados	Backup de ponto no tempo (isolado)
Requisitos de conformidade corporativos ou regulamentares	Backup de ponto no tempo (isolado)

O dano lógico é geralmente um cenário que requer um backup de ponto no tempo. Entretanto, com o Exchange 2010, há várias opções disponíveis que podem reduzir a necessidade de um backup de ponto no tempo:

• Com a recuperação de item único, se o usuário alterar certas propriedades de um item em qualquer pasta de caixa de correio, uma cópia do item será salva na pasta de Itens Recuperáveis antes de a modificação ser gravada no banco de dados. Se a modificação da mensagem resultar em uma cópia corrompida, o item original poderá ser restaurado.

• O Assistente de Reparo de Calendário (CRA) detecta automaticamente e corrige inconsistências que ocorrem em itens de reunião únicos e recorrentes de caixas de correio hospedadas nesse servidor de Caixa de Correio de modo que os destinatários não percam os anúncios de reunião ou contem com informações pouco confiáveis sobre reuniões.

• Durante as movimentações de caixa de correio, o serviço de Replicação de Caixa de Correio do Microsoft Exchange detecta itens corrompidos e não move esses itens para o banco de dados de caixa de correio de destino.

• O Exchange 2010 Service Pack 1 (SP1) introduz o cmdlet New-MailboxRepairRequest, que pode corrigir danos em pastas de pesquisa, contagens de item, exibições de pasta e problemas de pasta pai/filho.

Um backup de ponto no tempo pode ser um backup tradicional ou uma cópia de banco de dados com retardamento, sendo que ambos fornecem os mesmos recursos. A opção entre os dois depende do seu SLA de recuperação. O SLA de recuperação define o objetivo de ponto de recuperação (se ocorrer um desastre, os dados deverão ser restaurados dentro um certo tempo), bem como por quanto tempo o backup deve ser mantido. Se o SLA de recuperação for de 14 dias ou menos, uma cópia de banco de dados com retardamento poderá ser utilizada. Se o SLA de recuperação for maior do que 14 dias, um backup tradicional deverá ser usado. Para o administrador não autorizado e para os cenários de conformidade regulamentar ou corporativo, o backup de ponto no tempo é geralmente mantido separadamente da infraestrutura de mensagens e da equipe de TI de mensagens, que dita uma solução de backup tradicional.

Se você optar por manter um backup de ponto no tempo, vários aspectos do projeto poderão mudar:

• A implantação de cópias de banco de dados com retardamento tem implicações de armazenamento. Espaço adicional deve ser alocado para os logs de transação na cópia de banco de dados com retardamento devido às configurações de ReplayLagTime. Além disso, o posicionamento da cópia de banco de dados com retardamento poderá afetar sua arquitetura de armazenamento. (Para mais detalhes, consulte "Planejando a arquitetura do modelo de armazenamento" mais adiante neste tópico.)

• A implantação de uma solução de backup tradicional tem implicações no layout do número de unidade lógica (LUN), dependendo do tipo de solução Serviço de Cópias de Sombra de Volume (VSS), porque as soluções de cópia de VSS baseadas em hardware precisam de dois LUNs por arquitetura de banco de dados.

Dependendo da arquitetura de armazenamento, a utilização de uma solução de backup tradicional pode exigir redução significativa dos tamanhos das caixas de correio do usuário para que ocorra o atendimento dos SLAs de backup e tempo de restauração.

Na implantação de proteção de dados nativos do Exchange, você habilita o registro em log circular nos bancos de dados de caixa de correio. Na habilitação do registro em log circular, verifique se há capacidade suficiente no sistema para que a solução possa suportar eventos de desastre que impeçam o truncamento de log. No mínimo, você deverá garantir que exista pelo menos três dias de capacidade de log de transações (excluindo os requisitos de cópia com retardamento). Para obter mais informações sobre o registro em log circular funciona com replicação contínua, consulte Understanding Backup, Restore and Disaster Recovery.

Para obter mais informações sobre os backups de planejamento, consulte:

• Noções Básicas Sobre a Arquitetura do LUN do Exchange 2010

• Noções Básicas Sobre o Banco de Dados de Caixa de Correio e Fatores de Capacidade de Log

• Noções Básicas Sobre Reparo de Calendário

• Informações sobre itens recuperáveis

Voltar ao início

Planejando a arquitetura de modelo de armazenamento

O Exchange 2010 fornece flexibilidade no projeto de armazenamento. O Exchange 2010 inclui melhorias no desempenho, na confiabilidade e na disponibilidade alta, o que permite que as organizações executem o Exchange em inúmeros dispositivos de armazenamento. A criação de melhorias em entrada/saída (E/S) de disco apresentadas no Exchange 2007, a versão mais recente do Exchange, requer menos desempenho de armazenamento e é mais tolerante a falhas de armazenamento.

Selecione uma plataforma de armazenamento que garanta que você esteja balanceando os requisitos de capacidade com os requisitos de E/S e garanta que a solução forneça latência de disco aceitável e uma experiência do usuário em que há resposta.

RAID ou JBOD

Determine se deve ser implementada a plataforma de armazenamento usando a tecnologia RAID ou uma abordagem JBOD (considerando que a plataforma de armazenamento permita configurações JBOD). A partir de uma perspectiva do Exchange, JBOD significa ter o banco de dados e seus logs associados armazenados em um único disco. Para implantar em JBOD, é preciso implantar no mínimo três cópias de banco de dados com disponibilidade alta. A utilização de um único disco é um ponto de falha único, porque, quando o disco falha, a cópia de banco de dados que reside nesse disco é perdida. Ter um mínimo de três cópias de banco de dados garante tolerância a falhas, basta ter duas cópias adicionais caso essa cópia (ou disco) falhe. Entretanto, o uso de três cópias de banco de dados com disponibilidade alta, bem como o uso de cópias de banco de dados com retardamento, pode afetar o projeto de armazenamento. A tabela a seguir mostra diretrizes para considerações de RAID e JBOD.

Considerações de RAID ou JBOD

Servidores de data center	Duas cópias com disponibilidade alta (total)	Três cópias com disponibilidade alta (total)	Duas ou mais cópias com disponibilidade alta por data center	Uma cópia com retardamento	Duas ou mais cópias com retardamento por data center
Servidores de data center principais	RAID	RAID ou JBOD (2 cópias)	RAID ou JBOD	RAID	RAID ou JBOD
Servidores de data center secundários	RAID	RAID (1 cópia)	RAID ou JBOD	RAID	RAID ou JBOD

Para implantar em JBOD com os servidores de data center principais, você precisa de três ou mais cópias de banco de dados com disponibilidade alta no DAG. Caso ocorra a mistura de cópias com retardamento no mesmo servidor que hospeda cópias de banco de dados com disponibilidade alta (por exemplo, sem o uso de servidores de cópia de banco de dados com retardamento dedicados), você precisará de pelos menos duas cópias de banco de dados com retardamento.

Para que os servidores de data center secundários usem JBOD, você deverá ter pelo menos duas cópias de banco de dados com disponibilidade alta no data center secundário. A perda de uma cópia no data center secundário não resultará na solicitação de nova propagação pela WAN ou na necessidade de ter um único ponto de falha caso o data center secundário seja ativado. Caso ocorra a mistura de cópias de banco de dados com retardamento no mesmo servidor que hospeda cópias de banco de dados com disponibilidade alta (por exemplo, sem o uso de servidores de cópia de banco de dados com retardamento dedicados), você precisará de pelos menos duas cópias de banco de dados com retardamento.

Para servidores de cópia de banco de dados com retardamento dedicados, você deverá ter pelo menos duas cópias de banco de dados com retardamento em um data center para usar JBOD. Caso contrário, a perda de disco resultará na perda de cópia de banco de dados com retardamento, bem como na perda do mecanismo de proteção.

Para mais informações, consulte Compreendendo a Configuração de Armazenamento.

Voltar ao início

 © 2010 Microsoft Corporation. Todos os direitos reservados.