Design de layout de cópia de banco de dados

 

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

Tópico modificado em: 2010-11-11

Ao projetar uma solução altamente disponível para servidores de Caixa de Correio, é necessário garantir alta disponibilidade dos diversos componentes da infraestrutura, incluindo:

• Serviços de infraestrutura, como Active Directory e Sistema de Nomes de Domínio (DNS)

• Servidores membros do grupo de disponibilidade de banco de dados (DAG)

• Componentes individuais de armazenamento, como discos, controladores de armazenamento e racks de armazenamento

• Componentes individuais de rede, como roteadores, comutadores e agregadores

• Racks de servidor e de armazenamento

• Barramentos de energia

• Datacenters

Cada uma destas áreas de componentes representa possíveis pontos de falha, que às vezes são chamadas de domínios de falha. Como resultado, o nível de disponibilidade de seu DAG depende, em última análise, de como você projeta a solução para isolar e minimizar os efeitos negativos que uma falha em um desses domínios pode ter sobre o ambiente de DAG. Para obter independência entre os domínios de falha, cada um destes domínios deve ter uma cópia do banco de dados. Além disso, como uma falha resultaria em indisponibilidade de várias cópias, apenas uma cópia é necessária por domínio de falha.

Por exemplo, considere um cenário em que há duas cópias de um banco de dados. Cada cópia é armazenada em um conjunto separado de discos, mas ambas estão localizadas na mesma matriz de armazenamento. Se a matriz de armazenamento falhar ou se tornar indisponível por qualquer motivo, ambas as cópias estarão indisponíveis. Neste exemplo, o domínio de falha é a matriz de armazenamento. Apenas uma única cópia de cada banco de dados da caixa de correio deve residir na matriz. Caso contrário, se a matriz falhar, várias cópias (talvez todas) do banco de dados estarão indisponíveis.

Ao planejar a sua arquitetura de caixa de correio, considere os seguintes pontos de design adicionais:

• Serão implantadas várias cópias do banco de dados?

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

• Haverá uma arquitetura resiliente de site?

• Que tipo de modelo de resiliência do servidor de Caixa de Correio será implantado?

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

• Qual modelo de backup será usado?

• Qual arquitetura de armazenamento será usada?

Para obter mais informações sobre como planejar estas questões, consulte Noções Básicas Sobre Fatores de Alta Disponibilidade.

Índice

Layouts de cópia de banco de dados desbalanceada

Projetando um layout de cópia de banco de dados balanceada

Distribuição do banco de dados ativo no cenário de exemplo durante falhas de servidor

Cenários de design

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

Layouts de cópia de banco de dados desbalanceada

Para compreender como as cópias de banco de dados devem ser distribuídas em um DAG, considere um design de DAG que a Contoso, Ltd está planejando para sua solução de servidor de Caixa de Correio altamente disponível. A Contoso está criando um DAG composto por:

• 4 servidores de Caixa de Correio

• 20 bancos de dados de caixa de correio

• 2 cópias de cada banco de dados de caixa de correio

Todos os servidores são implantados em um único datacenter e cada servidor tem seu armazenamento dedicado e é implantado em seu próprio rack de servidor.

A Contoso exige que duas cópias altamente disponíveis do banco de dados (por exemplo, não defasadas) estejam sempre disponíveis e que a solução sobreviva a duas interrupções simultâneas de membros do DAG que afetem negativamente a disponibilidade dos bancos de dados.

Com base nestas exigências, o layout de cópia de banco de dados usado é mostrado na figura a seguir.

Layout inicial de cópia de banco de dados

Inicialmente, o design parece correto porque distribui as cópias ativas de cada banco de dados pelos quatro membros do DAG. Entretanto, há preocupações com esse design. O layout não é otimizado do ponto de vista de recursos de servidor. Por exemplo, quando um único servidor falha, o resultado é uma distribuição desigual dos bancos de dados, como é mostrado na figura a seguir.

Layout de cópia de banco de dados após falha de um servidor

A falha de Server4 resulta na ativação dos bancos de dados DB16 a DB20 em Server1, em vez de serem distribuídos pelos outros três servidores restantes. O resultado é uma distribuição desigual dos bancos de dados de caixa de correio ativados e uma utilização desigual dos recursos de servidor. Em comparação com os outros dois servidores restantes (Server2 e Server3), a utilização de Server1 dobrou.

Outra preocupação é que o DAG não contém cópias suficientes para sobreviver a duas interrupções simultâneas de servidores em todos os casos. Outra falha de servidor poderia resultar em indisponibilidade de 50% dos bancos de dados. Se Server1 e Server4 falhassem ou se tornassem indisponíveis simultaneamente, 10 bancos de dados estariam indisponíveis, como é mostrado na figura a seguir.

Layout de cópia de banco de dados após dupla falha de servidor

Esse design não atende à exigência básica de ser capaz de sobreviver a uma dupla falha de servidor. Para sobreviver a uma dupla falha de servidor e manter todos os bancos de dados ativos, uma terceira cópia deve ser implantada e um novo layout deve ser desenvolvido.

Voltar ao início

Projetando um layout de cópia de banco de dados balanceada

Para projetar um layout de cópia de banco de dados balanceada, talvez seja necessário rever várias decisões de projeto para obter o design ideal. Use os seguintes princípios de design ao planejar o layout de cópia de banco de dados:

• Para minimizar as falhas múltiplas de cópias de bancos de dados de caixa de correio, é importante isolar cada cópia das demais e colocá-las em domínios de falha diferentes. Por exemplo, não coloque mais de uma cópia de um banco de dados de caixa de correio específico no mesmo rack de servidor ou na mesma matriz de armazenamento.

• Faça o layout de cópias de banco de dados de modo consistente e distribuído para garantir que os banco de dados de caixa de correio ativos estejam uniformemente distribuídos após uma falha. A soma das preferências de ativação de cada cópia do banco de dados em qualquer servidor específico deve ser igual ou quase igual. Isso resulta em uma distribuição aproximadamente igual após uma falha, presumindo-se que a replicação esteja íntegra e atualizada.

Blocos de construção

Para respeitar os princípios de projeto citados, recomendamos colocar as cópias do banco de dados em uma disposição específica que garanta que todas as cópias estejam distribuídas simetricamente pelo maior número possível de servidores. A disposição das cópias do banco de dados é baseada em um conceito de bloco de construção.

O primeiro bloco de construção (conhecido como bloco de construção de nível 1) é baseado no número de servidores de Caixa de Correio que hospedarão cópias de banco de dados ativas. Presuma que esse número é N. N define não apenas o número de servidores de Caixa de Correio, mas também o número de bancos de dados no bloco de construção. Uma cópia de banco de dados ativa é distribuída em cada servidor, formando um padrão diagonal. Como no exemplo anterior, há 4 servidores de Caixa de Correio e 20 bancos de dados de caixa de correio. O tamanho do primeiro bloco de construção de nível 1 é 4, como é mostrado na figura a seguir.

Bloco de construção de nível 1

O mesmo padrão é repetido para cada conjunto de blocos de construção de nível 1 restante. Como há 20 bancos de dados, há cinco conjuntos de blocos de construção de nível 1, como é mostrado na figura a seguir.

Cinco blocos de construção de nível 1 para 20 bancos de dados

Ao adicionar uma segunda cópia de banco de dados, você a coloca diferentemente para cada conjunto de blocos de construção. Como um servidor já hospeda a cópia ativa, há N – 1 servidores disponíveis para hospedar a segunda cópia do banco de dados. Usando cada um desses N – 1 servidores uma vez, você tem uma distribuição totalmente simétrica que forma o novo bloco de construção maior. Assim, o tamanho do novo bloco de construção (conhecido como bloco de construção de nível 2) é N × (N – 1) bancos de dados. Isso significa que a segunda cópia de banco de dados para o primeiro banco de dados é colocada no segundo servidor e cada segunda cópia subsequente é implantada em um padrão diagonal no bloco de construção. Após o padrão ser concluído no conjunto de blocos de construção de nível 1, a posição inicial da segunda cópia para o próximo bloco é deslocada em um para que a segunda cópia comece no terceiro servidor.

No exemplo, o tamanho do bloco de construção agora é 4× (4 – 1) = 4× 3 = 12, o que significa que cada conjunto de blocos de construção de nível 2 é formado por 12 bancos de dados. Para o conjunto 1 de blocos de construção de nível 1 (DB1 a DB4), a segunda cópia para DB1 é colocada em Server2, enquanto que para o conjunto 2 de blocos de construção de nível 1 (DB5 a DB8), a segunda cópia para DB5 é colocada em Server3. A posição do servidor inicial para cada conjunto de blocos de construção de nível 1 é deslocada do conjunto de blocos de construção de nível 1 anterior em um servidor. Esse layout é mantido colocando a segunda cópia de DB9 em Server4. Isto garante que uma falha em Server1 ativa as segundas cópias em todos os outros três servidores restantes, em vez de ativar vários bancos de dados no mesmo servidor.

Bloco de construção de nível 2 com três blocos de construção de nível 1

Esse padrão é repetido para cada segundo conjunto de blocos de construção restante. Como há 20 bancos de dados, há dois conjuntos de blocos de construção de nível 2 neste exemplo. Observe que a segunda cópia de DB13 é colocada em Server2.

Bloco de construção de nível 2 com dois blocos de construção de nível 1 restantes

Para entender melhor esta lógica, compare o posicionamento da cópia do banco de dados para DB1, DB5 e DB9. Cada um desses bancos de dados possui uma cópia ativa hospedada em Server1. Se Server1 falhar, é desejável ter segundas cópias do banco de dados ativadas em diferentes servidores restantes para obter uma distribuição de carga uniforme. É possível alcançar esta situação colocando uma segunda cópia do banco de dados de DB1 em Server2, uma segunda cópia do banco de dados de DB5 em Server3 e uma segunda cópia do banco de dados de DB9 em Server4. A partir de DB13, simplesmente repita o padrão. As demais cópias do banco de dados são adicionadas em um padrão diagonal, como é mostrado na figura a seguir.

Posicionamento de cópia de banco de dados para distribuição uniforme

Observe que o segundo bloco de construção (DB13 a DB20) contém apenas 8 bancos de dados, não 12. Como resultado, este design não será totalmente simétrico se ocorrer uma única falha. Para fornecer uma distribuição totalmente simétrica, planeje sua arquitetura de forma que o número de bancos de dados seja um múltiplo do tamanho do maior bloco de construção. (Neste exemplo, os números ideais são 24, 36, 48 ou 60 bancos de dados, e assim por diante.)

Ao adicionar uma terceira cópia de banco de dados, você deve colocá-la novamente de forma diferente para cada grupo, que agora terá N × (N – 1) bancos de dados. Como agora há apenas N – 2 servidores disponíveis para o posicionamento da terceira cópia de banco de dados, isso gera N – 2 variações. O tamanho do novo bloco de construção (conhecido como bloco de construção de nível 3) passa a ser N × (N – 1) × (N – 2) bancos de dados. Portanto, a terceira cópia de banco de dados para o primeiro banco de dados é colocada no terceiro servidor, e cada terceira cópia subsequente é implantada em um padrão diagonal de acordo com a posição inicial nesse novo bloco de construção. Após o padrão ser concluído no conjunto de blocos de construção de nível 1, a posição inicial é deslocada em um para que a terceira cópia seja colocada na quarta posição.

Neste exemplo, o bloco de construção agora tem 4 × (4 – 1) × (4 – 2) = 4 × 3 × 2 = 24, o que significa que cada conjunto de blocos de construção de nível 3 é formado por 24 bancos de dados. Para produzir o padrão de posicionamento simétrico de bancos de dados, posicione a terceira cópia de banco de dados de DB1 em Server3 (que é o primeiro servidor disponível, porque Server1 hospeda a primeira cópia e Server2 hospeda a segunda cópia) e desloque cada cópia adicional em um até chegar ao final do conjunto 1 de blocos de construção de nível 1. Para o próximo conjunto de blocos de construção, posicione novamente a terceira cópia de banco de dados no próximo servidor disponível (Server4) e continue da mesma forma até alcançar DB12, que marca o fim do conjunto 1 de blocos de construção de nível 2. Para DB13 a DB20, siga o mesmo padrão, mas desloque o posicionamento da terceira cópia de banco de dados em um para que ela não termine nos mesmos servidores de DB1 a DB12.

Layout balanceado com três cópias de banco de dados e quatro servidores

Novamente, para entender melhor esta lógica, compare o posicionamento das cópias de banco de dados para os bancos de dados DB1 a DB13. Esses bancos de dados têm a cópia de banco de dados ativa hospedada em Server1 e a segunda cópia de banco de dados hospedada em Server2. Se esses servidores falharem, é desejável ter terceiras cópias do banco de dados ativadas em diferentes servidores restantes para obter uma distribuição de carga uniforme. É possível alcançar esta situação colocando a terceira cópia do banco de dados de DB1 em Server3 e a terceira cópia do banco de dados de DB13 em Server4. Pares semelhantes são formados por DB2 e DB14, DB3 e DB15, e assim por diante. A partir de DB25, simplesmente repita o padrão (este exemplo não contempla tantos bancos de dados).

Observe que o terceiro bloco de construção (DB1 a DB20) contém apenas 20 bancos de dados, não 24. Como resultado, este design não será totalmente simétrico se ocorrer uma dupla falha. Novamente, para fornecer uma distribuição totalmente simétrica, planeje sua arquitetura de forma que o número de bancos de dados seja um múltiplo do tamanho do maior bloco de construção. (Neste exemplo, os números ideais são 24, 48 ou 72 bancos de dados, e assim por diante.)

Ao adicionar uma quarta cópia de banco de dados, você deve colocá-la novamente de forma diferente para cada grupo, que agora terá N × (N – 1) × (N – 2) bancos de dados. O novo bloco de construção passa a ter N × (N – 1) × (N – 2) × (N – 3) bancos de dados. Isto segue a mesma abordagem lógica e garante que uma distribuição uniforme dos bancos de dados no novo bloco de construção caso três servidores falhem.

O exemplo para quatro servidores deixa apenas uma variação para posicionar a quarta cópia de banco de dados (resta apenas um servidor disponível). Portanto, o tamanho do bloco de construção realmente permanece em 24. Isto também fica claro ao usar a fórmula para o tamanho do bloco de construção: 4 × 3 × 2 × (4 – 3) = 4 × 3 × 2 × 1 = 24.

Conforme você continua a adicionar mais cópias de bancos de dados, o bloco de construção continua a crescer, de modo que a fórmula geral para o tamanho do bloco de construção é Perm(N,M) = N × (N – 1) … (N – M + 1) = N!/(N – M)! = CNMM!, onde N = número de servidores e M = número de cópias de bancos de dados. Isto se tornará óbvio quando você compreender que a distribuição totalmente simétrica das cópias de bancos de dados é alcançada selecionando todas as permutações possíveis de M cópias de bancos de dados nos N servidores disponíveis.

Há diversas advertências quanto ao uso dessa metodologia:

• A implantação de um número de bancos de dados que não seja um múltiplo do tamanho do maior bloco de construção resulta em uma distribuição assimétrica dos bancos de dados ativos durante eventos de falha.

• A implantação de arquiteturas para minimizar várias falhas de domínio pode resultar em uma distribuição assimétrica dos bancos de dados ativos durante eventos de falha. Isso ocorre porque as definições de domínio de falha impõem restrições ao posicionamento das cópias de banco de dados, o que quebra a simetria do padrão.

• A implantação de soluções resilientes de site que resultem em um banco de dados fora do site sobre eventos pode resultar em distribuição assimétrica dos bancos de dados ativados no datacenter secundário durante eventos de falha no servidor do datacenter primário.

Voltar ao início

Distribuição do banco de dados ativo no cenário de exemplo durante falhas de servidor

Usando o exemplo anterior, no caso de falha de um único servidor (por exemplo, uma falha de Server4), os bancos de dados de caixa de correio ativos são distribuídos como é mostrado na figura a seguir. A segunda cópia, indicada como Ativa em laranja, é ativada para DB4, DB8, DB12, DB16 e DB20.

Cópia de banco de dados ativa após falha de um único servidor

Se ocorrer uma dupla falha de servidor (a terceira cópia é ativada para vários bancos de dados e indicada como Ativa em verde), os dois servidores restantes, Server1 e Server3, terão um número igual de bancos de dados de caixa de correio ativados.

Cópia de banco de dados ativa após dupla falha de servidor

Porém, como o número de bancos de dados neste exemplo não é múltiplo do maior tamanho de bloco de construção (24 bancos de dados), nem todos os eventos de dupla falha de servidor resultarão em uma distribuição simétrica.

Distribuição de cópia de banco de dados ativa após dupla falha de servidor diferente

Voltar ao início

Cenários de design

Para entender o princípio do design do layout de cópia de banco de dados, incluindo a fórmula matemática associada, considere dois outros layouts de arquitetura.

Cenário de design: solução resiliente do site para distribuição de usuário ativo/passivo

Neste cenário, a Contoso decide implantar a seguinte arquitetura:

• O DAG é estendido para dois datacenters, operando em modelo de distribuição de usuário ativo/passivo.

• Cada servidor é implantado em um rack de servidor separado.

• O armazenamento de cada servidor é isolado do armazenamento do outro servidor no datacenter.

• Há quatro servidores de Caixa de Correio por datacenter.

• Há um total de 24 bancos de dados de caixa de correio.

• O que se pretende é ter quatro cópias de bancos de dados altamente disponíveis e sobreviver a uma falha dupla de servidor ou uma falha única de datacenter.

Neste exemplo, o bloco de construção de nível 1 é 4, os bancos de dados são agrupados em unidades de quatro e as cópias ativas são distribuídas pelos quatro servidores no bloco de construção.

Distribuição uniforme da primeira cópia em um bloco de construção

Para cada servidor que hospeda cópias ativas, a segunda cópia do banco de dados é distribuída tão uniformemente quanto possível por todos os demais servidores membros, continuando com o padrão diagonal porque cada cópia é isolada da outra. Neste exemplo, o bloco de construção de nível 2 passa a ser 12, que se torna o conjunto de repetição a cada 12 bancos de dados.

Distribuição uniforme de uma segunda cópia por um bloco de construção

Como essa solução resiliente de site é para um modelo de distribuição de usuário ativo/passivo com um número igual de servidores e cópias de banco de dados em ambos os datacenters, a terceira cópia de banco de dados é colocada em um padrão diagonal em Server5 e Server6, usando o valor 4 do bloco de construção de nível 1. Isto garante que Server5 e Server6 espelhem o posicionamento da primeira cópia de banco de dados de Server1 a Server4.

Distribuição uniforme da terceira cópia no segundo bloco de construção

Como essa solução resiliente de site é para um modelo de distribuição de usuário ativo/passivo com um número igual de servidores e cópias de banco de dados em ambos os datacenters, a quarta cópia de banco de dados é colocada em um padrão diagonal em Server5 e Server6, usando o valor 12 do bloco de construção de nível 2. Isto garante que Server5 e Server6 espelhem o posicionamento da segunda cópia de banco de dados de Server1 a Server4.

Distribuição uniforme de uma quarta cópia no segundo bloco de construção

Se ocorrer uma falha única de servidor, os três servidores restantes no datacenter primário terão um número igual de bancos de dados de caixa de correio ativados (8 por servidor).

Distribuição das cópias de banco de dados ativas após falha única de servidor

Se ocorrerem duas falhas simultâneas de servidor, os dois servidores restantes no datacenter primário terão um número igual de bancos de dados de caixa de correio ativados (10 por servidor), enquanto 4 bancos de dados serão ativados no datacenter secundário.

Distribuição das cópias de banco de dados ativas após dupla falha de servidor

Cenário de design: vários domínios de falha

Neste exemplo, a Wingtip Toys decide implantar a seguinte arquitetura:

• Todos os servidores são implantados em um único datacenter.

• Os servidores são agrupados em unidades de três.

• Cada um dos três servidores é colocado no mesmo rack com seu armazenamento.

• Há um total de 3 racks e 9 servidores.

• Há um total de 18 bancos de dados de caixa de correio.

• O que se pretende é ter três cópias de bancos de dados altamente disponíveis e sobreviver à falha de dois servidores membros ou à falha de um rack.

Neste exemplo, como o bloco de construção de nível 1 é 6, os bancos de dados são agrupados em unidades de 6 e as cópias ativas são distribuídas pelos seis servidores no bloco de construção.

Layout de cópia de banco de dados para o bloco de construção de nível 1

Para cada servidor que hospeda cópias ativas, a segunda cópia do banco de dados é distribuída tão uniformemente quanto possível por todos os demais servidores membros, garantindo-se também que duas cópias do mesmo banco de dados não serão colocadas no mesmo rack de servidor. Neste exemplo, em vez da fórmula do bloco de construção de nível 2, N × (N – 1), a fórmula N × (N – 2) é usada para garantir que duas cópias do mesmo banco de dados não sejam colocadas no mesmo rack. Isto significa que o conjunto de bloco de construção de nível 2 é 6 × 4 = 24.

Layout de cópia de banco de dados para a primeira e segunda cópias

A terceira cópia do banco de dados é colocada em um padrão diagonal por todos os servidores, garantindo novamente que várias cópias do mesmo banco de dados não sejam colocadas no mesmo rack de servidor. Neste exemplo, em vez da fórmula do bloco de construção de nível 3, em que N × (N – 2), a fórmula N × (N – 2) × (N – 4) é usada para garantir que duas cópias do mesmo banco de dados não sejam colocadas no mesmo rack. Isto significa que o conjunto de bloco de construção de nível 3 é 6 × 4 x 2 = 48.

Layout de cópia de banco de dados para primeira, segunda e terceira cópias

Se ocorrer uma falha única de servidor, os cinco servidores restantes no datacenter primário terão um número quase igual de bancos de dados de caixa de correio ativados. Quatro servidores terão 10 bancos de dados ativados por servidor, enquanto um servidor (o parceiro de rack) terá 8 bancos de dados ativados.

Contagem e layout de bancos de dados ativos após falha única de servidor

Se ocorrerem duas falhas de servidor simultâneas (em racks diferentes), os quatro servidores restantes terão um número quase igual de bancos de dados de caixa de correio ativados.

Contagem e layout de bancos de dados ativos após falha dupla de servidor (racks diferentes)

Se dois servidores falharem simultaneamente (no mesmo rack), os quatro servidores restantes terão um número igual de bancos de dados de caixa de correio ativados.

Contagem e layout de bancos de dados ativos após falha dupla de servidor (no mesmo rack)

Voltar ao início

 © 2010 Microsoft Corporation. Todos os direitos reservados.