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.

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
• As camadas de Web e de dados devem estar co-localizadas 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 está configurado para aceder à base de dados através do ouvinte <failover-group-name>.database.windows.net de leitura-escrita (1). O Azure Traffic Manager está configurado para usar o método de roteamento prioritário (2).

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 Gestor de Tráfego do Azure inicie o failover do ponto de extremidade antes que o grupo de failover acione o failover da base 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 está novamente online, o primário antigo se reconecta automaticamente como um novo secundário. O diagrama abaixo ilustra a configuração após o failover.

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 Traffic Manager deteta que a conectividade com a Região B está interrompida e marca a aplicação web do ponto de extremidade 2 como Degradado (2). O desempenho do aplicativo não é afetado neste caso, mas o banco de dados fica exposto e, portanto, com maior risco de perda de dados caso a região A falhe sucessivamente.

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.

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.
• A aplicação suporta modos de operação de leitura e escrita e pode operar em modo de leitura por um período de tempo.

Neste padrão, o aplicativo altera para o modo de leitura apenas quando as conexões de leitura e gravação começam a receber erros de tempo de espera. A aplicação web é implantada em ambas as regiões geográficas e inclui uma conexão com o endpoint do listener de leitura e escrita e uma conexão diferente com o endpoint do listener 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 aciona a alternância. 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.

Se ocorrer uma interrupção na região B, o Gestor de Tráfego detecta a falha do ponto de extremidade web-app-2 na região B e marca-a como degradada (1). Enquanto isso, o grupo de failover comuta o ouvinte de leitura apenas 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 de atenuada a interrupção, o banco de dados secundário é imediatamente sincronizado com o primário e o ouvinte somente leitura é revertido para o banco de dados secundário na região B. Durante a sincronização, o desempenho do primário poderá 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).

Conteúdo relacionado

• Continuidade de negócios no Banco de Dados SQL do Azure
• Replicação Geográfica Ativa
• Visão geral dos grupos de failover & práticas recomendadas (Banco de Dados SQL do Azure)
• Estratégias de recuperação de desastres para aplicativos que usam pools elásticos do Banco de Dados SQL do Azure