Criar serviços globalmente disponíveis usando o banco de dados SQL do Azure

APLICA-SE A: Banco de Dados SQL do Azure

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

Observação

Se estiver utilizando bancos de dados Premium ou Comercialmente Crítico e pools elásticos, será possível torná-los resilientes a interrupções regionais convertendo-os para configuração de implantação com redundância de zona. Veja Bancos de dados com redundância de zona.

Cenário 1: Usando duas regiões do Azure para continuidade dos 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 do banco de dados exigem acesso de leitura e gravação (RW) nos dados
  • A camada da Web e a camada de dados devem estar colocalizadas para reduzir a latência e o custo de tráfego
  • Essencialmente, o tempo de inatividade é um risco maior de negócios para esses aplicativos do que a perda de dados

Nesse caso, a topologia de implantação do aplicativo é 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 o failover, a replicação e a conectividade do banco de dados. O serviço Web em ambas as regiões é configurado para acessar o banco de dados por meio do ouvinte de leitura/gravação <failover-group-name>.database.windows.net (1). O Gerenciador de Tráfego do Azure é configurado para usar o método de roteamento de prioridade (2).

Observação

O Gerenciador de Tráfego do Azure é usado neste artigo apenas para fins ilustrativos. Você pode usar qualquer solução de balanceamento de carga que dê suporte ao método de roteamento de prioridade.

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

Cenário 1. Configuração antes da interrupção.

Após uma interrupção na região primária, o Banco de Dados SQL detecta que o banco de dados primário não está acessível e dispara um 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 carência que controla o tempo entre a detecção de interrupção e o failover em si. É possível que o Gerenciador de Tráfego do Azure inicie o failover do ponto de extremidade antes que o grupo de failover dispare o failover do banco de dados. Nesse caso, o aplicativo Web não pode se reconectar ao banco de dados imediatamente. Porém, as reconexões terão êxito automaticamente assim que o failover do banco de dados for concluído. Quando a região com falha é restaurada e colocada online novamente, o primário antigo se reconecta automaticamente como um novo secundário. O diagrama abaixo ilustra a configuração após o failover.

Observação

Todas as transações confirmadas após o failover são perdidas durante a reconexão. Após a conclusão do failover, o aplicativo da região B consegue se reconectar e reiniciar o processamento das solicitações do usuário. O aplicativo Web e o banco de dados primário agora estão na região B e permanecem colocalizados.

Cenário 1. 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 secundário será suspenso, mas o vínculo entre os dois permanecerá intacto (1). O Gerenciador de Tráfego detecta que a conectividade com a região B está interrompida e marca o aplicativo Web do 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, corre um risco maior de perda de dados, no caso de falha da região A em sucessão.

Observação

Para a recuperação de desastre, recomendamos a configuração com implantação de aplicativo limitada a duas regiões. Isso ocorre porque a maioria das regiões geográficas do Azure tem somente duas regiões. Essa configuração não protege o aplicativo contra uma falha catastrófica simultânea nas duas regiões. Caso ocorra essa falha improvável, você poderá recuperar seus bancos de dados em uma terceira região usando a operação de restauração geográfica.

Depois que a interrupção é atenuada, o banco de dados secundário é sincronizado novamente de forma automática com o primário. 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.

Observação

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 de extremidade de prioridade mais alta. Se você pretende manter o primário na região B por um tempo, altere a tabela de prioridade no perfil do Gerenciador de Tráfego de acordo.

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

Cenário 1. Configuração após uma interrupção na região secundária.

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

  • O mesmo aplicativo Web é implantado em ambas as regiões sem nenhuma configuração específica à região e não exige nenhuma 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 sempre estão co-localizados.

A principal desvantagem é 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 dos negócios com preservação máxima de dados

Essa opção é mais adequada para aplicativos com as seguintes características:

  • Qualquer perda de dados é um risco comercial elevado. O failover de banco de dados só poderá ser usado como último recurso, se a interrupção for causada por uma falha catastrófica.
  • O aplicativo oferece suporte aos modos somente leitura e leitura/gravação de operações e pode operar em “modo somente leitura” por um período de tempo específico.

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 nas duas 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 de prioridade. O monitoramento de ponto de extremidade deve ser habilitado para o ponto de extremidade do aplicativo em cada região (2).

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

Cenário 2: Configuração antes da interrupção.

Quando o Gerenciador de Tráfego detecta uma falha de conectividade na região A, ele alterna automaticamente o tráfego de usuário para a instância do aplicativo na região B. Com esse padrão, é importante definir o período de cortesia com perda de dados com um valor suficientemente alto, por exemplo, 24 horas. Ele garante que a perda de dados é impedida se a interrupção é 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 encaminhadas automaticamente para o banco de dados secundário. Se a interrupção for causada por uma falha catastrófica, muito provavelmente, ela não poderá ser atenuada dentro do período de carência. Quando ele expirar, o grupo de failover disparará 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 os dois estágios do processo de recuperação.

Observação

Se a interrupção na região primária é atenuada dentro do período de cortesia, o Gerenciador de Tráfego detecta a restauração da conectividade na região primária e alterna o tráfego do usuário novamente para a instância do aplicativo na região A. Essa instância do aplicativo é retomada e opera no modo leitura/gravação usando o banco de dados primário na região A, conforme ilustrado no diagrama anterior.

Cenário 2: Estágios da recuperação de desastre.

Se ocorrer uma interrupção na região B, o Gerenciador de Tráfego detectará a falha do aplicativo Web do ponto de extremidade 2 na região B e o marcará como Degradado (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 primário fica exposto durante a interrupção. O seguinte diagrama ilustra uma falha na região secundária:

Cenário 2: Interrupção da região secundária.

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

Esse padrão de design apresenta várias vantagens:

  • Ele evita a perda de dados durante as interrupções temporárias.
  • O tempo de inatividade depende somente da velocidade com a qual o Gerenciador de Tráfego detecta a falha de conectividade, o que pode ser configurado.

A desvantagem é que o aplicativo deve poder operar no modo somente leitura.

Cenário 3: relocação de aplicativo para outra região geográfica sem perda de dados e tempo de inatividade quase zero

Neste cenário, o aplicativo tem as seguintes características:

  • Os usuários finais acessam o aplicativo em geografias diferentes
  • O aplicativo inclui cargas de trabalho somente leitura que não dependem de uma sincronização completa com as últimas atualizações
  • O acesso de gravação aos dados deve ter suporte na mesma geografia para a maioria dos usuários
  • A latência de leitura é crítica para a experiência do usuário final

Para atender a esses requisitos, você precisa garantir que o dispositivo do usuário sempre se conecte ao aplicativo implantado na mesma geografia para as operações somente leitura, como procura de dados, análise etc. Por outro lado, as operações OLTP são processadas na mesma geografia na maior parte do tempo. Por exemplo, durante as horas do dia, as operações OLTP são processadas na mesma geografia, mas fora do horário comercial, elas podem ser processadas em uma geografia diferente. Se a atividade do usuário final geralmente ocorre durante o horário comercial, você pode garantir o desempenho ideal para a maioria dos usuários na maior parte do tempo. O diagrama a seguir mostra essa topologia.

Os recursos do aplicativo devem ser implantados em cada geografia em que há demanda de uso substancial. Por exemplo, se o aplicativo for usado ativamente nos Estados Unidos, na União Europeia e no Sudeste da Ásia, ele deverá ser implantado em todas essas geografias. O banco de dados primário deve ser dinamicamente alternado de uma geografia para a próxima ao final do horário de trabalho. Esse método é chamado de “seguir o sol”. A carga de trabalho OLTP sempre se conecta ao banco de dados por meio do ouvinte de leitura/gravação <failover-group-name>.database.windows.net (1). A carga de trabalho somente leitura se conecta ao banco de dados local diretamente usando o ponto de extremidade do servidor de bancos de dados <server-name>.database.windows.net (2). O Gerenciador de Tráfego é configurado com o método de roteamento de desempenho. Isso garante que o dispositivo do usuário final seja conectado ao serviço Web na região mais próxima. O Gerenciador de Tráfego deve ser configurado com o monitoramento de ponto de extremidade habilitado para cada ponto de extremidade do serviço Web (3).

Observação

A configuração do grupo de failover define qual região é usada para failover. Como o novo primário está em uma geografia diferente, o failover resulta em uma latência mais longa para cargas de trabalho OLTP e somente leitura até que a região afetada fique online novamente.

Cenário 3: Configuração com o primário no Leste dos EUA.

No final do dia, por exemplo, às 23h no horário local, os bancos de dados ativos devem ser alternados para a próxima região (Norte da Europa). Essa tarefa pode ser totalmente automatizada por meio dos Aplicativos Lógicos do Azure. A tarefa envolve as seguintes etapas:

  • Alternar o servidor primário no grupo de failover para o Norte da Europa usando o failover amigável (1)
  • Remover o grupo de failover entre o Leste dos EUA e o Norte da Europa
  • Criar um novo grupo de failover com o mesmo nome mas entre o Norte da Europa e o Leste da Ásia (2).
  • Adicionar o primário no Norte da Europa e o secundário no Leste da Ásia a esse grupo de failover (3).

O seguinte diagrama ilustra a nova configuração após o failover planejado:

Cenário 3: Fazendo a transição do primário para o Norte da Europa.

Se uma interrupção ocorrer no Norte da Europa, por exemplo, o failover automático de banco de dados será iniciado pelo grupo de failover, o que resulta efetivamente na movimentação do aplicativo para a próxima região antes do prazo (1). Nesse caso, o Leste dos EUA é a única região secundária restante até que o Norte da Europa fique online novamente. As duas regiões restantes atendem aos clientes em todas as três geografias alternando funções. Os Aplicativos Lógicos do Azure precisam ser ajustados de acordo. Como as demais regiões recebem o tráfego adicional de usuário da Europa, o desempenho do aplicativo é afetado pela latência adicional e por um aumento do número de conexões do usuário final. Depois que a interrupção for atenuada no Norte da Europa, o banco de dados secundário será imediatamente sincronizado com o primário atual. O seguinte diagrama ilustra uma interrupção no Norte da Europa:

Cenário 3: Interrupção no Norte da Europa.

Observação

Reduza o tempo em que a experiência do usuário final na Europa é degradada pela latência longa. Para fazer isso, você deve implantar de forma proativa uma cópia do aplicativo e criar os bancos de dados secundários em outra região local (Europa Ocidental) como uma substituição da instância do aplicativo offline no Norte da Europa. Quando o último ficar online novamente, você pode decidir se deseja continuar usando a Europa Ocidental ou remover a cópia do aplicativo de lá e voltar a usar o Norte da Europa.

Os principais benefícios desse design são:

  • A carga de trabalho do aplicativo somente leitura acessa os dados na região mais próxima em todos os momentos.
  • A carga de trabalho do aplicativo de leitura/gravação acessa os dados na região mais próxima durante o período de atividade mais alto em cada geografia
  • Como o aplicativo é implantado em várias regiões, ele pode sobreviver a uma perda de uma das regiões, sem nenhum tempo de inatividade significativo.

Mas há algumas desvantagens:

  • Uma interrupção regional resulta no impacto da geografia pela latência mais longa. As cargas de trabalho de leitura/gravação e somente leitura são atendidas pelo aplicativo em outra geografia.
  • As cargas de trabalho somente leitura devem se conectar a um ponto de extremidade diferente em cada região.

Planejamento de continuidade de negócios: escolher um design de aplicativo para recuperação de desastre em nuvem

A estratégia específica de recuperação de desastre em nuvem pode combinar ou estender esses padrões de design para atender da melhor forma às necessidades do aplicativo. Como mencionado anteriormente, a estratégia escolhida é baseada no SLA que você deseja oferecer a 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 (objetivo de ponto de recuperação) e no ERT (tempo de recuperação estimado).

Padrão RPO ERT
Implantação ativa-passiva para recuperação de desastres com acesso de banco de dados colocalizado Acesso de leitura/gravação < 5 s Tempo de detecção de falha + TTL do DNS
Implantação ativa-ativa para balanceamento de carga de aplicativo Acesso de leitura/gravação < 5 s Tempo de detecção de falha + TTL do DNS
Implantação ativa-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 detecção de falha + período de carência de perda de dados

Próximas etapas