Gerencie atualizações contínuas de aplicativos em nuvem usando a replicação geográfica ativa do Banco de dados SQL

Aplica-se a:Banco de Dados SQL do Azure

Saiba como usar a replicação geográfica ativa no Banco de Dados SQL do Azure para habilitar atualizações contínuas de seu aplicativo na nuvem. Como os upgrades são operações que causam interrupções, eles devem fazer parte do seu planejamento e projeto de continuidade de negócios. Neste artigo, examinamos dois métodos diferentes de orquestrar o processo de atualização e discutimos os benefícios e as compensações de cada opção. Para os fins deste artigo, nos referimos a um aplicativo que consiste em um site conectado a um único banco de dados como sua camada de dados. Nosso objetivo é atualizar a versão 1 (V1) do aplicativo para a versão 2 (V2) sem qualquer impacto significativo na experiência do usuário.

Ao avaliar as opções de atualização, considere estes fatores:

• Impacto na disponibilidade do aplicativo durante as atualizações, como por quanto tempo as funções do aplicativo podem ser limitadas ou degradadas.
• Capacidade de reverter se a atualização falhar.
• Vulnerabilidade do aplicativo se ocorrer uma falha catastrófica não relacionada durante a atualização.
• Custo total em dólares. Esse fator inclui redundância adicional de banco de dados e custos incrementais dos componentes temporários usados pelo processo de atualização.

Atualize aplicativos que dependem de backups de banco de dados para recuperação de desastres

Se seu aplicativo depende de backups automáticos de banco de dados e usa restauração geográfica para recuperação de desastres, ele é implantado em uma única região do Azure. Para minimizar a interrupção do usuário, crie um ambiente de preparo nessa região com todos os componentes do aplicativo envolvidos na atualização. O primeiro diagrama ilustra o ambiente operacional antes do processo de atualização. O ponto de extremidade contoso.azurewebsites.net representa um ambiente de produção do aplicativo Web. Para poder reverter a atualização, você deve criar um ambiente de preparo com uma cópia totalmente sincronizada do banco de dados. Siga estas etapas para criar um ambiente de preparo para a atualização:

1. Crie um banco de dados secundário na mesma região do Azure. Monitore o secundário para ver se o processo de semeadura está concluído (1).
2. Crie um novo ambiente para seu aplicativo Web e chame-o de "Preparo". Ele será registrado no DNS do Azure com a URL contoso-staging.azurewebsites.net (2).

Nota

Essas etapas de preparação não afetarão o ambiente de produção, que pode funcionar no modo de acesso total.

Quando as etapas de preparação estiverem concluídas, o aplicativo estará pronto para a atualização real. O diagrama seguinte ilustra as etapas envolvidas no processo de atualização:

1. Defina o banco de dados primário para o modo somente leitura (3). Esse modo garante que o ambiente de produção do aplicativo Web (V1) permaneça somente leitura durante a atualização, evitando assim a divergência de dados entre as instâncias de banco de dados V1 e V2.
2. Desconecte o banco de dados secundário usando o modo de terminação planejado (4). Essa ação cria uma cópia totalmente sincronizada e independente do banco de dados primário. Esta base de dados será atualizada.
3. Transforme o banco de dados secundário no modo de leitura-gravação e execute o script de atualização (5).

Se a atualização for concluída com êxito, você estará pronto para alternar os usuários para a cópia atualizada do aplicativo, que se torna um ambiente de produção. A comutação envolve mais alguns passos, como ilustrado no diagrama seguinte:

1. Ativar uma operação de permuta entre ambientes de produção e de preparação do aplicativo Web (6). Esta operação alterna as URLs dos dois ambientes. Agora contoso.azurewebsites.net aponta para a versão V2 do site e do banco de dados (ambiente de produção).
2. Se você não precisar mais da versão V1, que se tornou uma cópia de preparo após a troca, poderá encerrar o ambiente de preparo (7).

Se o processo de atualização não for bem-sucedido (por exemplo, devido a um erro no script de atualização), considere que o ambiente de preparo foi comprometido. Para reverter o aplicativo para o estado de pré-atualização, reverta o aplicativo no ambiente de produção para acesso total. O diagrama seguinte mostra as etapas de reversão:

1. Defina a cópia do banco de dados para o modo de leitura-gravação (8). Esta ação restaura a funcionalidade V1 completa da cópia de produção.
2. Execute a análise de causa básica e descomissione o ambiente de preparo (9).

Neste ponto, o aplicativo está totalmente funcional e você pode repetir as etapas de atualização.

Nota

A reversão não requer alterações de DNS porque você ainda não executou uma operação de troca.

A principal vantagem dessa opção é que você pode atualizar um aplicativo em uma única região seguindo um conjunto de etapas simples. O custo em dólares da atualização é relativamente baixo.

A principal contrapartida é que, se ocorrer uma falha catastrófica durante a atualização, a recuperação para o estado de pré-atualização envolve a reimplantação do aplicativo em uma região diferente e a restauração do banco de dados do backup usando a restauração geográfica. Esse processo resulta em tempo de inatividade significativo.

Atualize aplicativos que dependem da replicação geográfica do banco de dados para recuperação de desastres

Se seu aplicativo usa replicação geográfica ativa ou grupos de failover para continuidade de negócios, ele é implantado em pelo menos duas regiões diferentes. Há um banco de dados primário ativo em uma região primária e um banco de dados secundário somente leitura em uma região de backup. Juntamente com os fatores mencionados no início deste artigo, o processo de atualização também deve garantir que:

• O aplicativo permanece protegido contra falhas catastróficas em todos os momentos durante o processo de atualização.
• Os componentes com redundância geográfica do aplicativo são atualizados em paralelo com os componentes ativos.

Para atingir essas metas, além de usar os ambientes de Aplicativos Web, você aproveitará o Gerenciador de Tráfego do Azure usando um perfil de failover com um ponto de extremidade ativo e um ponto de extremidade de backup. O diagrama seguinte ilustra o ambiente operacional antes do processo de atualização. Os web sites contoso-1.azurewebsites.net e contoso-dr.azurewebsites.net representam um ambiente de produção da aplicação com redundância geográfica total. O ambiente de produção inclui os seguintes componentes:

• O ambiente de produção do aplicativo contoso-1.azurewebsites.net Web na região primária (1)
• O banco de dados primário na região primária (2)
• Uma instância em espera do aplicativo Web na região de backup (3)
• O banco de dados secundário replicado geograficamente na região de backup (4)
• Um perfil de desempenho do Gerenciador de Tráfego com um ponto de extremidade online chamado e um ponto de extremidade offline chamado contoso-1.azurewebsites.netcontoso-dr.azurewebsites.net

Para tornar possível reverter a atualização, você deve criar um ambiente de preparo com uma cópia totalmente sincronizada do aplicativo. Como você precisa garantir que o aplicativo possa se recuperar rapidamente caso ocorra uma falha catastrófica durante o processo de atualização, o ambiente de preparo também deve ser redundante geograficamente. As etapas a seguir são necessárias para criar um ambiente de preparo para a atualização:

1. Implante um ambiente de preparo do aplicativo Web na região primária (6).
2. Crie um banco de dados secundário na região primária do Azure (7). Configure o ambiente de preparo do aplicativo Web para se conectar a ele.
3. Crie outro banco de dados secundário com redundância geográfica na região de backup replicando o banco de dados secundário na região primária. (Este método é chamado de replicação geográfica encadeada.) (8).
4. Implante um ambiente de preparo da instância do aplicativo Web na região de backup (9) e configure-o para conectar o banco de dados secundário com redundância geográfica criado em (8).

Nota

Essas etapas de preparação não afetarão o aplicativo no ambiente de produção. Ele permanecerá totalmente funcional no modo de leitura-gravação.

Quando as etapas de preparação estiverem concluídas, o ambiente de preparo estará pronto para a atualização. O diagrama seguinte ilustra estas etapas de atualização:

1. Defina o banco de dados primário no ambiente de produção para o modo somente leitura (10). Esse modo garante que o banco de dados de produção (V1) não será alterado durante a atualização, evitando assim a divergência de dados entre as instâncias de banco de dados V1 e V2.

-- Set the production database to read-only mode
ALTER DATABASE [<Prod_DB>]
SET READ_ONLY

2. Termine a replicação geográfica desconectando o secundário (11). Essa ação cria uma cópia independente, mas totalmente sincronizada, do banco de dados de produção. Esta base de dados será atualizada. O exemplo a seguir usa Transact-SQL, mas o PowerShell também está disponível.

-- Disconnect the secondary, terminating geo-replication
ALTER DATABASE [<Prod_DB>]
REMOVE SECONDARY ON SERVER [<Partner-Server>]

3. Execute o script de atualização em relação contoso-1-staging.azurewebsites.neta , contoso-dr-staging.azurewebsites.nete o banco de dados primário de preparo (12). As alterações do banco de dados serão replicadas automaticamente para o secundário de preparo.

Se a atualização for concluída com êxito, você estará pronto para alternar os usuários para a versão V2 do aplicativo. O diagrama seguinte ilustra os passos envolvidos:

1. Ative uma operação de permuta entre ambientes de produção e preparo do aplicativo Web na região primária (13) e na região de backup (14). V2 do aplicativo agora se torna um ambiente de produção, com uma cópia redundante na região de backup.
2. Se você não precisar mais do aplicativo V1 (15 e 16), poderá desativar o ambiente de preparação.

Se o processo de atualização não for bem-sucedido (por exemplo, devido a um erro no script de atualização), considere que o ambiente de preparo está em um estado inconsistente. Para reverter o aplicativo para o estado de pré-atualização, reverta para o uso da V1 do aplicativo no ambiente de produção. As etapas necessárias são mostradas no diagrama seguinte:

1. Defina a cópia do banco de dados primário no ambiente de produção para o modo de leitura-gravação (17). Esta ação restaura a funcionalidade V1 completa no ambiente de produção.
2. Execute a análise da causa básica e repare ou remova o ambiente de preparo (18 e 19).

Neste ponto, o aplicativo está totalmente funcional e você pode repetir as etapas de atualização.

Nota

A reversão não requer alterações de DNS porque você não executou uma operação de troca.

A principal vantagem dessa opção é que você pode atualizar o aplicativo e sua cópia com redundância geográfica em paralelo sem comprometer a continuidade dos negócios durante a atualização.

A principal contrapartida é que ele requer redundância dupla de cada componente de aplicação e, portanto, incorre em um custo em dólar mais alto. Também envolve um fluxo de trabalho mais complicado.

Resumo

Os dois métodos de atualização descritos no artigo diferem em complexidade e custo em dólar, mas ambos se concentram em minimizar por quanto tempo o usuário está limitado a operações somente leitura. Esse tempo é definido diretamente pela duração do script de atualização. Não depende do tamanho do banco de dados, da camada de serviço escolhida, da configuração do site ou de outros fatores que você não possa controlar facilmente. Todas as etapas de preparação são dissociadas das etapas de atualização e não afetam o aplicativo de produção. A eficiência do script de atualização é um fator-chave que determina a experiência do usuário durante as atualizações. Portanto, a melhor maneira de melhorar essa experiência é concentrar seus esforços em tornar o script de atualização o mais eficiente possível.

Conteúdos relacionados

• Visão geral da continuidade de negócios.
• Crie bancos de dados secundários legíveis usando replicação geográfica ativa.
• Use grupos de failover para habilitar o failover transparente e coordenado de vários bancos de dados.
• Configure ambientes de preparo no Serviço de Aplicativo do Azure.
• Gerencie um perfil do Azure Traffic Manager.