Criar uma arquitetura de dados distribuída geograficamente
A parte final do projeto de arquitetura da nossa aplicação a ser considerada é a camada de armazenamento de dados. Queremos garantir que os dados são legíveis e graváveis com todas as funcionalidades após uma falha ao nível da região.
No portal de rastreamento de remessa, optamos por usar o Azure Front Door para enviar todas as solicitações para os Serviços de Aplicativo na região Leste dos EUA. Se a região Leste dos EUA falhar, o Front Door detetará a falha e enviará solicitações para duplicar componentes dos Serviços de Aplicativo na região Oeste dos EUA. Na nossa arquitetura original de região única, armazenamos dados relacionais na base de dados SQL do Azure e dados semiestruturados no Cosmos DB. Agora, queremos entender como podemos garantir que ambos os bancos de dados permaneçam disponíveis se a região Leste dos EUA falhar.
Aqui, aprendemos como replicar dados entre regiões e como garantir que o failover possa ocorrer rapidamente, se necessário.
Base de Dados SQL do Azure
Para criar uma implementação multirregional da base de dados SQL do Azure com o objetivo de armazenar dados relacionais, podemos utilizar:
- Georreplicação ativa
- Grupos de ativação pós-falha automática
Georreplicação ativa
A Base de Dados SQL do Azure pode replicar automaticamente uma base de dados e todas as respetivas alterações de uma base de dados para outra com a funcionalidade de georreplicação ativa. Apenas o servidor lógico primário aloja uma cópia gravável da base de dados. Podemos criar até quatro outros servidores lógicos que alojam cópias só de leitura da base de dados.
Para o portal de rastreamento de remessa, crie um banco de dados secundário na região Oeste dos EUA e configure a replicação geográfica da região Leste dos EUA. Quando ocorre uma falha regional, o Front Door redireciona as solicitações do usuário para os Serviços de Aplicativo na região Oeste dos EUA. Os Serviços de Aplicativo e o Azure Functions podem obter acesso aos dados relacionais porque uma cópia já foi replicada para a região Oeste dos EUA.
Esta alteração é automática, mas lembre-se de que a base de dados secundária na região E.U.A. Oeste é só de leitura. Se um utilizador tentar modificar dados, por exemplo, ao criar um novo envio, poderão surgir erros. Podemos iniciar manualmente um failover para o oeste dos EUA assim que notarmos o problema no portal do Azure. Se quisermos automatizar este processo, os nossos programadores podem escrever código que chama o método failover na API REST da Base de Dados SQL do Azure.
Nota
As instâncias geridas da Base de Dados SQL do Azure não suportam a georreplicação ativa. As instâncias geridas são concebidas para simplificar a migração de dados de um servidor local do SQL Server enquanto mantêm a segurança. Se você usar uma instância gerenciada, considere usar grupos de failover.
Grupos de ativação pós-falha automática
Um grupo de ativação pós-falha automática é um grupo de bases de dados em que os dados são replicados automaticamente de um servidor primário para um ou mais servidores secundários. Esta estrutura é como a georreplicação ativa e utiliza o mesmo método de replicação de dados. No entanto, podemos automatizar a resposta a uma falha ao definir uma política.
Para o portal de envio, criamos um banco de dados secundário na região Oeste dos EUA. Em seguida, adicionamos uma política que executa o failover da réplica primária do banco de dados para o oeste dos EUA se ocorrer uma falha catastrófica na região leste dos EUA. Se isso acontecer, a réplica E.U.A. Oeste irá tornar-se automaticamente na base de dados primário gravável e todas as funcionalidades serão mantidas.
Considere utilizar um grupo de ativação pós-falha automática se quiser automatizar a ativação pós-falha da base de dados gravável sem escrever o código personalizado para a acionar. Além disso, use grupos de failover automático se seu banco de dados for executado em uma instância gerenciada do Banco de Dados SQL do Azure.
Importante
A replicação subjacente à replicação geográfica ativa e aos grupos de failover automático é assíncrona. Quando é aplicada uma alteração à réplica primária, é enviada uma confirmação ao cliente. Neste momento, a transação é considerada concluída e a replicação ocorre. Se ocorrer uma falha, as últimas alterações feitas na base de dados primária podem não ter sido replicadas na secundária. Tenha em atenção que, após um desastre, as alterações mais recentes da base de dados podem ser perdidas.
Azure Cosmos DB
Nossa configuração é menos complexa com o Azure Cosmos DB porque foi projetada como um sistema de banco de dados em nuvem multirregional. O Cosmos DB é uma base de dados de vários modelos, capaz de armazenar dados relacionais, dados semiestruturados e outras formas de dados. Mesmo que executemos o Cosmos DB numa única região, os dados são replicados para várias instâncias entre diferentes domínios de falhas para obter a melhor disponibilidade.
Quando criamos uma conta multirregional do Cosmos DB, podemos escolher entre os seguintes modos:
Contas multirregionais com várias regiões de escrita.
Nesse modo, todas as cópias do banco de dados são sempre graváveis. Se uma região falhar, não será necessária uma ativação pós-falha.
Contas multirregionais com uma única região de escrita.
Neste modo, apenas a região primária contém bases de dados graváveis. Os dados replicados para as regiões secundárias são só de leitura. As atualizações são desativadas por predefinição quando a região primária falha. No entanto, podemos selecionar ativar a ativação pós-falha automática para que o Cosmos DB efetue automaticamente a ativação pós-falha da cópia primária e gravável da base de dados para outra região.
Importante
No Cosmos DB, a replicação de dados é síncrona. Quando é aplicada uma alteração, a transação não é considerada concluída até ser replicada para um quórum de réplicas. Em seguida, é enviada uma confirmação ao cliente. Quando ocorre uma falha, nenhuma alteração recente é perdida porque a replicação já ocorreu.