Projetando serviços disponíveis globalmente usando o Banco de Dados SQL do Azure

Aplica-se a:Banco de Dados SQL do Azure

Ao criar e implantar serviços de nuvem com o Banco de Dados SQL do Azure, você usa grupos ativos de replicação geográfica ou failover para fornecer resiliência a interrupções regionais e falhas catastróficas. O mesmo recurso permite criar aplicativos distribuídos globalmente otimizados para acesso local aos dados. Este artigo discute padrões de aplicativos comuns, incluindo os benefícios e compensações de cada opção.

Nota

Se você estiver usando bancos de dados Premium ou Business Critical e pools elásticos, poderá torná-los resilientes a interrupções regionais convertendo-os em configuração de implantação redundante de zona. Consulte Bancos de dados com redundância de zona.

Cenário 1: Usando duas regiões do Azure para continuidade de negócios com tempo de inatividade mínimo

Nesse cenário, os aplicativos têm as seguintes características:

• O aplicativo está ativo em uma região do Azure
• Todas as sessões de banco de dados exigem acesso de leitura e gravação (RW) aos dados
• A camada da Web e a camada de dados devem ser colocadas para reduzir a latência e o custo de tráfego
• Fundamentalmente, o tempo de inatividade é um risco de negócios maior para esses aplicativos do que a perda de dados

Nesse caso, a topologia de implantação de aplicativos é otimizada para lidar com desastres regionais quando todos os componentes do aplicativo precisam fazer failover juntos. O diagrama abaixo mostra essa topologia. Para redundância geográfica, os recursos do aplicativo são implantados nas regiões A e B. No entanto, os recursos da Região B não são utilizados até que a Região A falhe. Um grupo de failover é configurado entre as duas regiões para gerenciar a conectividade, a replicação e o failover do banco de dados. O serviço Web em ambas as regiões é configurado para acessar o banco de dados por meio do failover-group-name> do ouvinte <de leitura-gravação.database.windows.net (1). O Azure Traffic Manager está configurado para usar o método de roteamento prioritário (2).  

Nota

O Azure Traffic Manager é usado ao longo deste artigo apenas para fins de ilustração. Você pode usar qualquer solução de balanceamento de carga que ofereça suporte ao método de roteamento prioritário.

O diagrama a seguir mostra essa configuração antes de uma interrupção:

Após uma interrupção na região primária, o Banco de dados SQL deteta que o banco de dados primário não está acessível e dispara o failover para a região secundária com base nos parâmetros da política de failover automático (1). Dependendo do SLA do aplicativo, você pode configurar um período de cortesia que controla o tempo entre a deteção da interrupção e o failover em si. É possível que o Gerenciador de Tráfego do Azure inicie o failover de ponto de extremidade antes que o grupo de failover acione o failover do banco de dados. Nesse caso, o aplicativo Web não pode se reconectar imediatamente ao banco de dados. Mas as reconexões serão automaticamente bem-sucedidas assim que o failover do banco de dados for concluído. Quando a região com falha é restaurada e on-line novamente, a primária antiga se reconecta automaticamente como uma nova secundária. O diagrama abaixo ilustra a configuração após o failover.

Nota

Todas as transações confirmadas após o failover são perdidas durante a reconexão. Depois que o failover for concluído, o aplicativo na região B poderá se reconectar e reiniciar o processamento das solicitações do usuário. Tanto o aplicativo Web quanto o banco de dados primário estão agora na região B e permanecem colocalizados.

Se ocorrer uma interrupção na região B, o processo de replicação entre o banco de dados primário e o secundário será suspenso, mas o vínculo entre os dois permanecerá intacto (1). O Gerenciador de Tráfego deteta que a conectividade com a Região B está interrompida e marca o aplicativo Web de ponto de extremidade 2 como Degradado (2). O desempenho do aplicativo não é afetado nesse caso, mas o banco de dados fica exposto e, portanto, com maior risco de perda de dados caso a região A falhe sucessivamente.

Nota

Para recuperação de desastres, recomendamos a configuração com implantação de aplicativos limitada a duas regiões. Isso ocorre porque a maioria das geografias do Azure tem apenas duas regiões. Essa configuração não protege seu aplicativo de uma falha catastrófica simultânea de ambas as regiões. Em um caso improvável de tal falha, você pode recuperar seus bancos de dados em uma terceira região usando a operação de restauração geográfica. Para obter mais informações, consulte Diretrizes de recuperação de desastres do Banco de Dados SQL do Azure.

Quando a interrupção é atenuada, o banco de dados secundário ressincroniza automaticamente com o principal. Durante a sincronização, o desempenho do primário pode ser afetado. O impacto específico depende da quantidade de dados que o novo primário adquiriu desde o failover.

Nota

Depois que a interrupção for atenuada, o Gerenciador de Tráfego começará a rotear as conexões para o aplicativo na Região A como um ponto final de prioridade mais alta. Se você pretende manter o principal na Região B por um tempo, você deve alterar a tabela de prioridade no perfil do Gerenciador de Tráfego de acordo.

O diagrama a seguir ilustra uma interrupção na região secundária:

As principais vantagens deste padrão de design são:

• O mesmo aplicativo Web é implantado em ambas as regiões sem nenhuma configuração específica da região e não requer lógica adicional para gerenciar o failover.
• O desempenho do aplicativo não é afetado pelo failover, pois o aplicativo Web e o banco de dados estão sempre colocalizados.

A principal contrapartida é que os recursos do aplicativo na Região B são subutilizados na maioria das vezes.

Cenário 2: Regiões do Azure para continuidade de negócios com preservação máxima de dados

Esta opção é mais adequada para aplicações com as seguintes características:

• Qualquer perda de dados é um alto risco comercial. O failover do banco de dados só pode ser usado como último recurso se a interrupção for causada por uma falha catastrófica.
• O aplicativo suporta somente leitura e leitura-gravação modos de operações e pode operar em "modo somente leitura" por um período de tempo.

Nesse padrão, o aplicativo alterna para o modo somente leitura quando as conexões de leitura-gravação começam a receber erros de tempo limite. O aplicativo Web é implantado em ambas as regiões e inclui uma conexão com o ponto de extremidade do ouvinte de leitura-gravação e uma conexão diferente com o ponto de extremidade do ouvinte somente leitura (1). O perfil do Gerenciador de Tráfego deve usar o roteamento prioritário. O monitoramento do ponto final deve ser habilitado para o ponto de extremidade do aplicativo em cada região (2).

O diagrama a seguir ilustra essa configuração antes de uma interrupção:

Quando o Gerenciador de Tráfego deteta uma falha de conectividade com a região A, ele alterna automaticamente o tráfego do usuário para a instância do aplicativo na região B. Com esse padrão, é importante que você defina o período de carência com perda de dados para um valor suficientemente alto, por exemplo, 24 horas. Ele garante que a perda de dados seja evitada se a interrupção for atenuada dentro desse período. Quando o aplicativo Web na região B é ativado, as operações de leitura-gravação começam a falhar. Nesse ponto, ele deve alternar para o modo somente leitura (1). Nesse modo, as solicitações são automaticamente roteadas para o banco de dados secundário. Se a interrupção for causada por uma falha catastrófica, muito provavelmente não poderá ser atenuada dentro do período de carência. Quando expira, o grupo de failover dispara o failover. Depois disso, o ouvinte de leitura-gravação fica disponível e as conexões com ele param de falhar (2). O diagrama a seguir ilustra as duas etapas do processo de recuperação.

Nota

Se a interrupção na região primária for atenuada dentro do período de carência, o Gerenciador de Tráfego detetará a restauração da conectividade na região primária e alternará o tráfego do usuário de volta para a instância do aplicativo na região A. Essa instância do aplicativo retoma e opera no modo de leitura-gravação usando o banco de dados primário na região A, conforme ilustrado pelo diagrama anterior.

Se ocorrer uma interrupção na região B, o Gerenciador de Tráfego detetará a falha do ponto final web-app-2 na região B e marcará como degradada (1). Enquanto isso, o grupo de failover alterna o ouvinte somente leitura para a região A (2). Essa interrupção não afeta a experiência do usuário final, mas o banco de dados principal é exposto durante a interrupção. O diagrama a seguir ilustra uma falha na região secundária:

Depois que a interrupção é atenuada, o banco de dados secundário é imediatamente sincronizado com o primário e o ouvinte somente leitura é alternado de volta para o banco de dados secundário na região B. Durante a sincronização, o desempenho do primário pode ser ligeiramente afetado, dependendo da quantidade de dados que precisam ser sincronizados.

Este padrão de design tem várias vantagens:

• Evita a perda de dados durante as interrupções temporárias.
• O tempo de inatividade depende apenas da rapidez com que o Traffic Manager deteta a falha de conectividade, que é configurável.

A desvantagem é que o aplicativo deve ser capaz de operar no modo somente leitura.

Planejamento de continuidade de negócios: escolha um design de aplicativo para recuperação de desastres na nuvem

Sua estratégia específica de recuperação de desastres na nuvem pode combinar ou estender esses padrões de design para melhor atender às necessidades de seu aplicativo. Como mencionado anteriormente, a estratégia escolhida é baseada no SLA que você deseja oferecer aos seus clientes e na topologia de implantação do aplicativo. Para ajudar a orientar sua decisão, a tabela a seguir compara as opções com base no RPO (Recovery Point Objetive, objetivo de ponto de recuperação) e no tempo de recuperação estimado (ERT).

Padrão	RPO	ERT
Implantação ativo-passiva para recuperação de desastres com acesso a banco de dados colocalizado	Acesso < de leitura-gravação 5 seg	Tempo de deteção de falhas + DNS TTL
Implantação ativa-ativa para balanceamento de carga de aplicativos	Acesso < de leitura-gravação 5 seg	Tempo de deteção de falhas + DNS TTL
Implantação ativo-passiva para preservação de dados	Acesso < somente leitura 5 seg	Acesso somente leitura = 0
	Acesso de leitura-gravação = zero	Acesso de leitura-gravação = Tempo de deteção de falhas + período de carência com perda de dados

Próximos passos

• Para obter uma visão geral e cenários de continuidade de negócios, consulte Visão geral de continuidade de negócios
• Para saber mais sobre a replicação geográfica ativa, consulte Replicação geográfica ativa.
• Para saber mais sobre grupos de failover, consulte Grupos de failover.
• Para obter informações sobre replicação geográfica ativa com pools elásticos, consulte Estratégias de recuperação de desastres do pool elástico.