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 banco 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 failovers manualmente. 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. Pode utilizar estas bases de dados secundárias para fornecer acesso de leitura para dados de quaisquer clientes a estabelecer ligação e espalhar a utilização e procura entre as bases de dados primária e secundária.
Se estiver a utilizar políticas de ativação pós-falha automática e ocorrer uma falha em, pelo menos, uma base de dados no grupo da base de dados primária, será acionada uma ativação pós-falha automática para as bases de dados secundárias. 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. Este pool 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.
Pode estender a retenção das cópias de segurança para um máximo de 10 anos, ao estabelecer políticas de retenção de longo prazo em bases de dados individuais ou conjuntos 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, cria:
- 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 para todos os dados que foram alterados desde o último backup completo a cada 12 horas.
O Banco de dados SQL mantém backups em blobs de armazenamento que fornecem acesso de leitura. Em seguida, 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 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 esse recurso, o Azure Cosmos DB coloca réplicas de dados em várias zonas de disponibilidade em qualquer região, para maior resiliência.