Criar serviços de dados resilientes
Sua organização tem várias cargas de trabalho distribuídas entre os ambientes. Todas as cargas de trabalho dependem de dados mantidos seguros e em tempo hábil. Você pode tomar várias medidas para criar resiliência para seus dados.
Nesta unidade, você aprenderá como os grupos de disponibilidade Always On ajudam a replicar seus dados. Você verá como os backups automatizados e o failover automático do Banco de Dados SQL do Azure ajudam a manter os dados seguros. Você também aprenderá como usar o recurso de replicação geográfica do Azure Cosmos DB para replicar os dados de maneira transparente para outras regiões e ter os dados acessíveis para leitura e gravação.
Replicar os bancos de dados com os grupos de disponibilidade Always On
Os grupos de disponibilidade Always On ajudam você a obter alta disponibilidade para os bancos de dados do SQL Server em execução em máquinas virtuais.
Você pode armazenar grupos especificados de bancos de dados em réplicas de disponibilidade:
- A réplica primária contém os bancos de dados primários.
- A réplica secundária mantém cópias secundárias sincronizadas dos bancos de dados primários.
Em caso de falha, a réplica secundária será um destino de failover. Sua réplica primária é legível e gravável. Os dados são sincronizados entre cada banco de dados primário e cada banco de dados secundário associado.
Você também pode definir réplicas secundárias como legíveis. Dessa forma, os clientes podem acessar seus dados de vários bancos de dados, e o aumento da demanda é distribuído entre várias réplicas.
Os grupos de disponibilidade Always On são executados em um cluster de failover do Windows Server que consiste em um grupo de computadores funcionando em harmonia. Essa arquitetura oferece alta disponibilidade para as cargas de trabalho executadas nesses computadores. Com os grupos de disponibilidade Always On, cada nó (computador) do cluster hospeda uma réplica, seja primária ou secundária. Cada réplica contém um grupo de bancos de dados.
Você pode configurar os grupos de disponibilidade Always On no Azure criando dois conjuntos de disponibilidade: um para os nós de cluster de failover do Windows Server e outro para os controladores de domínio.
O cluster de failover do Windows Server precisa conter, pelo menos, três computadores. Deve haver um computador do SQL Server para a réplica primária e outro para a réplica secundária no cluster. Um terceiro servidor deve funcionar como uma testemunha de compartilhamento de arquivo ou você poderá usar um compartilhamento de arquivo do Azure como testemunha.
Failover para o Banco de Dados SQL do Azure
Você pode usar grupos de failover automático do Banco de Dados SQL para configurar o failover e a replicação de grupos de bancos de dados em um servidor do Banco de Dados SQL. Agrupe políticas definidas que podem executar failovers com base em suas necessidades. Se necessário, você também pode disparar os failovers manualmente. O Banco de Dados SQL pode fazer failover automaticamente dos seus bancos de dados para um servidor secundário em uma região secundária em caso de falha.
Os bancos de dados secundários de failover automático do Banco de Dados SQL podem ser usados como bancos de dados para leitura. Você pode usar esses bancos de dados secundários para atender ao acesso de leitura a dados de todos os clientes que se conectam e espalhar o uso e a demanda entre bancos de dados primários e secundários.
Se você estiver usando políticas de failover automático e uma falha ocorrer em pelo menos um banco de dados em seu grupo de banco de dados primário, um failover automático será disparado para os bancos dos dados secundários. Os pontos de extremidade permanecem os mesmos durante o failover. Quando o problema que causou a falha for resolvido e você estiver pronto, faça failback para a localização original. Você pode fazer failover manualmente dos seus grupos para a localização original.
Os bancos de dados de um servidor de banco de dados podem ser incluídos em um só grupo de failover automático. Você também pode colocar todos os bancos de dados em um pool elástico em um só grupo de failover. Quando os bancos de dados primários fazem parte de um pool elástico, seus bancos de dados secundários também são provisionados em um pool elástico. Esse pool tem o mesmo nome que o pool elástico primário.
Backup automatizado para o Banco de Dados SQL do Azure
O Banco de Dados SQL do Azure pode fazer backups dos bancos de dados armazenados entre 7 e 35 dias. O Banco de Dados SQL usa o armazenamento com redundância geográfica para armazenar backups e fornece acesso de leitura aos seus dados em uma região diferente. Seus bancos de dados estarão seguros mesmo se algo acontecer com um data center.
Você pode estender a retenção de backups por até 10 anos, estabelecendo políticas de retenção de longo prazo em bancos de dados individuais ou pools elásticos. Todos os backups de banco de dados no Banco de Dados SQL são criptografados em repouso. Todos os bancos de dados SQL criados têm a Transparent Data Encryption habilitada por padrão.
O Banco de Dados SQL faz backups automaticamente em segundo plano. Ele cria backups de seus bancos de dados em intervalos diferentes, dependendo do tipo de backup. Por exemplo, ele cria:
- Backups para logs de transações em um intervalo de cinco a dez minutos.
- Backups completos dos bancos de dados toda semana. O primeiro backup completo acontece assim que o banco de dados é criado. O tempo necessário para o Banco de Dados SQL concluir um backup completo depende do tamanho do banco de dados.
- Backups diferenciais de todos os dados alterados desde o último backup completo a cada 12 horas.
O Banco de Dados SQL mantém os backups em blobs de armazenamento que fornecem acesso de leitura. Em seguida, ele copia esses backups para um datacenter emparelhado.
Os bancos de dados podem ser restaurados para uma versão de backup. Se você configurou a retenção de longo prazo, esse backup pode ficar disponível por até dez anos. Você pode restaurar bancos de dados excluídos de volta ao tempo antes da exclusão e até o limite de retenção em sua política de retenção.
O Banco de Dados SQL pode restaurar bancos de dados para uma região geográfica diferente. Esse processo é feito por meio da restauração geográfica, que permite a recuperação de bancos de dados de uma região para outra, caso algo aconteça com uma região inteira.
Replicação geográfica com o Azure Cosmos DB
O Azure Cosmos DB é um serviço de banco de dados multimodelo de baixa latência que permite a distribuição de dados globalmente e a escala elástica e rápida.
No Azure Cosmos DB, todos os dados são replicados de maneira transparente nas regiões que você definiu para sua conta do Azure Cosmos DB. O Azure Cosmos DB salva os dados dentro de contêineres que compõem seu banco e todos os seus contêineres são particionados.
Todas as partições são replicadas em cada região. Em cada região, suas partições são copiadas antes de cada cópia ser distribuída entre os domínios de falha.
Seus dados são replicados pelo menos quatro vezes. Você pode configurar uma conta do Azure Cosmos DB e configurar seu banco de dados do Azure Cosmos DB para ser distribuído em cinco regiões. Quando você configura esse banco de dados para cinco regiões, o Azure Cosmos DB garante que você tenha, pelo menos, 4 x 5 cópias de todos os seus dados.
Você deve configurar seu banco de dados Azure Cosmos DB para abranger pelo menos duas regiões. Quanto mais regiões você tiver, mais resiliente seus dados se tornarão. Você também deve definir explicitamente seu banco de dados do Azure Cosmos DB para ter várias regiões de gravação, para que você possa executar operações de leitura e gravação de todas as suas regiões.
Você também pode configurar a redundância de zona para algumas regiões. Com esse recurso, o Azure Cosmos DB coloca as réplicas de dados em várias zonas de disponibilidade de qualquer região, para proporcionar resiliência adicional.