Criar serviços de dados resilientes
Sua organização tem várias cargas de trabalho espalhadas entre ambientes. Todas as cargas de trabalho dependem dos dados que são mantidos seguros de forma rápida. 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ê vê como os backups automatizados e o failover automático no Banco de Dados SQL do Azure ajudam a manter os dados seguros. Você também aprenderá a usar o recurso de replicação geográfica do Azure Cosmos DB para replicar dados de forma transparente para outras regiões e ter os dados acessíveis para leitura e gravação.
Replicar bancos de dados com grupos de disponibilidade Always On
Os grupos de disponibilidade Always On ajudam a obter alta disponibilidade para bancos de dados SQL Server executados em máquinas virtuais.
Você pode armazenar grupos especificados de bancos de dados em réplicas de disponibilidade:
- Sua réplica principal contém bancos de dados primários.
- Sua réplica secundária contém cópias secundárias sincronizadas de seus bancos de dados primários.
Se houver uma falha, a réplica secundária será um destino de failover. A réplica primária é legível e gravável. Os dados são sincronizados entre cada base de dados primária e cada base de dados secundária associada.
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 sobre um cluster de failover do Windows Server que consiste em um grupo de máquinas trabalhando em uníssono. Esta arquitetura oferece-lhe elevada disponibilidade para as cargas de trabalho executadas nesses computadores. Com os grupos de disponibilidade Always On, cada nó (máquina) no 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 grupos de disponibilidade Always On no Azure criando dois conjuntos de disponibilidade: um para nós de cluster de failover do Windows Server e outro para controladores de domínio.
O cluster de failover do Windows Server precisa conter pelo menos três máquinas. Deve haver uma máquina do SQL Server para a réplica primária e outra para a réplica secundária no cluster. Um terceiro servidor deve atuar como testemunha de compartilhamento de arquivos ou você pode usar um compartilhamento de arquivos 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 ativações pós-falha com base nas suas necessidades. Se necessário, você também pode acionar manualmente failovers. O Banco de dados SQL pode fazer failover automático de seus bancos de dados para um servidor secundário em uma região secundária se ocorrer uma falha.
Os bancos de dados secundários de failover automático do Banco de dados SQL podem ser usados como bancos de dados legíveis. Você pode usar esses bancos de dados secundários para atender ao acesso de leitura aos dados de qualquer cliente conectado e distribuir o uso e a demanda entre bancos de dados primários e secundários.
Se você estiver usando políticas automáticas de failover e ocorrer uma falha em pelo menos um banco de dados no grupo de bancos de dados primário, um failover automático será acionado para os bancos de dados secundários. Os pontos finais permanecem os mesmos durante a ativação pós-falha. Quando o problema que causou a falha tiver sido resolvido e estiver pronto, pode voltar à sua localização original. Você pode fazer failover manual de seus grupos para o local original.
Os bancos de dados em um servidor de banco de dados podem ser incluídos em um único grupo de failover automático. Você também pode colocar todos os bancos de dados em um pool elástico em um único grupo de failover. Quando as bases de dados primárias fazem parte de um conjunto elástico, as bases de dados secundárias também são aprovisionadas num conjunto elástico. Esse pool secundário tem o mesmo nome que o pool elástico primário.
Cópia de segurança automatizada da Base de Dados SQL do Azure
O Banco de Dados SQL do Azure pode fazer backups de seus bancos de dados armazenados de 7 a 35 dias. A Base de Dados SQL utiliza o armazenamento georredundante para armazenar as cópias de segurança e fornecer acesso de leitura aos dados numa região diferente. Seus bancos de dados estão seguros, mesmo que algo aconteça com um datacenter.
Você pode estender a retenção de backup por até 10 anos estabelecendo políticas de retenção de longo prazo em bancos de dados únicos 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 criptografia de dados transparente habilitada por padrão.
A Base de Dados SQL cria cópias de segurança automaticamente para si em segundo plano. Ele cria backups de seus bancos de dados em intervalos diferentes, dependendo do tipo de backup. Por exemplo, ele cria os seguintes tipos de backup:
- Backups para logs de transações em um intervalo de 5 a 10 minutos.
- Backups completos de seus bancos de dados todas as semanas. A primeira cópia de segurança completa acontece assim que a base de dados é criada. O tempo que o Banco de dados SQL leva para concluir um backup completo depende do tamanho do banco de dados.
- Backups diferenciais a cada 12 horas para todos os dados que foram alterados desde o último backup completo.
O Banco de dados SQL mantém backups em blobs de armazenamento que fornecem acesso de leitura. Em seguida, ele copia esses backups em 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 estar disponível por até 10 anos. Pode restaurar as bases de dados eliminadas para a altura antes da eliminação e até ao limite de retenção na política de retenção.
A Base de Dados SQL pode restaurar bases 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 se algo acontecer 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 distribuir dados globalmente e dimensionar de forma elástica e rápida.
No Azure Cosmos DB, todos os dados são replicados de forma transparente nas regiões definidas para sua conta do Azure Cosmos DB. O Azure Cosmos DB guarda os dados em contentores que compõem a base de dados e todos os contentores são particionados.
Todas as partições são replicadas em cada região. Dentro de cada região, suas partições são copiadas antes de cada cópia ser distribuída entre domínios de falha.
Os 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.
Deve configurar a base de dados do Azure Cosmos DB para abranger, pelo menos, duas regiões. Quanto mais regiões tiver, mais resiliente os dados se tornam. 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 possa executar operações de leitura e gravação de todas as suas regiões.
Também pode configurar a redundância da zona para algumas regiões. Com a redundância de zona, o Azure Cosmos DB coloca réplicas de dados em várias zonas de disponibilidade em qualquer região, para maior resiliência.