Explicar as opções de alta disponibilidade e recuperação de desastre

Concluído

Além de sua alta disponibilidade interna, a plataforma Azure oferece duas opções para fornecer níveis mais altos de disponibilidade para VM e para algumas cargas de trabalho de PaaS. Os Conjuntos de Disponibilidade e Zonas de Disponibilidade protegem suas cargas de trabalho da atividade de manutenção planejada e de possíveis falhas de hardware.

Opções de alta disponibilidade

A maioria das soluções de alta disponibilidade do SQL Server estão disponíveis em VMs (máquinas virtuais) do Azure. Em uma solução somente Azure, todo o sistema HADR é executado no Azure. Em uma configuração híbrida, parte da solução é executada no Azure e a outra parte é executada localmente em sua organização. A flexibilidade do ambiente do Azure permite que você se mova parcial ou completamente para o Azure para atender aos requisitos de orçamento e HADR de seus sistemas de banco de dados do SQL Server.

Zonas de Disponibilidades

As Zonas de Disponibilidade são locais físicos exclusivos dentro de uma região. Cada zona é composta por um ou mais data centers equipados com energia, resfriamento e rede independentes. Nas regiões do Azure compatíveis com as Zonas de Disponibilidade, durante a criação da VM, você pode optar por usá-la e especificar em qual zona você quer que a máquina virtual resida. Há três Zonas de Disponibilidade em cada região do Azure com suporte. As Zonas de Disponibilidade fornecem alta disponibilidade contra falhas do datacenter ao implantar várias VMs em diferentes zonas. Além disso, elas também fornecem um meio para a Microsoft realizar a manutenção (usando um agrupamento chamado domínio de atualização) dentro de cada região, atualizando apenas uma zona por vez. Você pode distribuir seu ecossistema de máquina virtual entre as três zonas na região. Utilizar as Zonas de Disponibilidade em conjunto com as máquinas virtuais do Azure eleva o tempo de atividade para quatro noves (99,99%), que equivalem a um máximo de 52,60 minutos de tempo de inatividade por ano. Você pode identificar quais regiões do Azure são compatíveis com as Zonas de Disponibilidade em docs.microsoft.com. Se as Zonas de Disponibilidade estiverem disponíveis em sua região e seu aplicativo for compatível com a latência mínima entre zonas, elas fornecerão o nível mais alto de disponibilidade para seu aplicativo.

Azure Availability Zones

Na imagem acima, você pode ver a configuração da zona de disponibilidade. Ao implantar uma VM em uma região com uma zona de disponibilidade, você verá a opção de implantar na Zona 1, 2 e 3. Essas zonas são representações lógicas de data centers físicos, o que significa que a implantação na Zona 1 em uma assinatura não quer dizer que a Zona 1 representa o mesmo datacenter em outra assinatura.

Conjuntos de Disponibilidade

Os conjuntos de disponibilidade são semelhantes às Zonas de Disponibilidade, mas, em vez de distribuir cargas de trabalho entre os datacenters em uma região, eles disseminam as cargas de trabalho entre os servidores e racks em um datacenter. Como quase todas as cargas de trabalho no Azure são virtuais, você pode usar conjuntos de disponibilidade para garantir que as duas VMs que contêm os membros do Grupos de Disponibilidade Always On não estejam em execução no mesmo host físico. Os conjuntos de disponibilidade podem fornecer até 99,95% de disponibilidade e devem ser usados quando as Zonas de Disponibilidade não estiverem disponíveis em uma região ou um aplicativo não tolerar a latência dentro da zona.

AG (Grupos de Disponibilidade) Always On

Os Grupos de Disponibilidade Always On podem ser implementados entre duas ou mais instâncias (até um máximo de nove) do SQL Server em execução em máquinas virtuais do Azure ou em um data center local e no Azure. Em um grupo de disponibilidade, as transações de banco de dados são confirmadas na réplica primária e, em seguida, as transações são enviadas de forma síncrona ou assíncrona para todas as réplicas secundárias. A distância física entre os servidores (isto é, se eles estão ou não na mesma região do Azure) determina qual modo de disponibilidade você deve escolher. Em geral, se a carga de trabalho exigir a menor latência possível ou se as réplicas secundárias estiverem espalhadas geograficamente, o modo de disponibilidade assíncrono será recomendado. Se as réplicas estiverem dentro da mesma região do Azure e os aplicativos conseguirem suportar algum nível de latência, o modo de confirmação síncrono deverá ser considerado. O modo síncrono ajudará a garantir que cada transação seja confirmada em uma ou mais réplicas secundárias antes de permitir que o aplicativo continue. Grupos de Disponibilidade Always On fornecem alta disponibilidade e recuperação de desastre, pois um único grupo de disponibilidade é compatível com os modos de disponibilidade síncrono e assíncrono. A unidade de failover de um grupo de disponibilidade é um grupo de bancos de dados, e não a instância inteira.

Grupos de Disponibilidade Always On também podem se usados para fins de recuperação de desastre. Você pode implementar até nove réplicas de um banco de dados em regiões do Azure e ampliar essa arquitetura ainda mais usando Grupos de Disponibilidade Distribuídos. Os Grupos de Disponibilidade garantem que uma cópia viável dos seus bancos de dados esteja em outro local além da região primária. Ao fazer isso, você ajuda a garantir que seu ecossistema de dados esteja protegido contra desastres naturais, bem como alguns desastres causados por pessoas.

Always On Availability Group Configuration

A imagem acima mostra um diagrama lógico de um Grupos de Disponibilidade Always On em execução em um Cluster de Failover do Windows Server. Há uma réplica primária e quatro secundárias. Nesse cenário, todas as cinco réplicas poderiam ser síncronas, ou alguma combinação de réplicas síncronas e assíncronas. Lembre-se de que a unidade de failover é o grupo de bancos de dados, e não a instância. Embora uma instância de cluster de failover forneça HA no nível da instância, ela não fornece recuperação de desastre.

Instâncias de Cluster de Failover do SQL Server

Se for necessário proteger a instância inteira, será possível usar uma FCI (instância de cluster de failover) do SQL Server, que fornece alta disponibilidade para uma instância inteira, em uma única região. Uma FCI não fornece recuperação de desastre sem ser combinada com outro recurso, como grupos de disponibilidade ou envio de logs. As FCIs também precisam de armazenamento compartilhado que pode ser fornecido no Azure usando o armazenamento de arquivos compartilhado ou usando Espaços de Armazenamento Diretos no Windows Server.

Para cargas de trabalho do Azure, os grupos de disponibilidade são a solução preferencial para implantações mais recentes, pois a demanda de armazenamento compartilhado das FCIs aumenta a complexidade das implantações. No entanto, para migrações de soluções locais, uma FCI pode ser necessária para a compatibilidade dos aplicativos.

Opções de Recuperação de Desastre

Embora a plataforma Azure ofereça 99,9% de tempo de atividade por padrão, os desastres ainda podem ocorrer e afetam o tempo de atividade do aplicativo. É importante que você tenha um plano de recuperação de desastre adequado em vigor ao realizar qualquer tipo de migração. O Azure oferece vários métodos para garantir que seu SQL Server em uma máquina virtual esteja protegido em caso de desastre. Há dois componentes para essa proteção. Primeiro, há opções de plataforma do Azure, como armazenamento replicado geograficamente para backups e Azure Site Recovery, que é uma solução abrangente de recuperação de desastre para todas as suas cargas de trabalho. Em segundo lugar, há ofertas específicas do SQL Server, como backups e Grupos de Disponibilidade.

Backups de SQL Server nativos

Os backups são considerados a essência de qualquer administrador de banco de dados, e isso não muda quando se trabalha com uma solução de nuvem. Com o SQL Server em uma máquina virtual do Azure, você tem controle granular de quando os backups ocorrem e onde eles são armazenados. Você pode usar trabalhos do SQL Agent para fazer backup diretamente em uma URL vinculada ao armazenamento de Blobs do Azure. O Azure fornece a opção de usar o GRS (armazenamento com redundância geográfica) ou o RA-GRS (armazenamento com redundância geográfica com acesso de leitura) para garantir que os arquivos de backup sejam armazenados com segurança no cenário geográfico.

Além disso, como parte do provedor de serviços de VM do SQL do Azure, você pode ter seus backups gerenciados automaticamente pela plataforma.

Backup do Azure para SQL Server

A solução de Backup do Azure requer que um agente seja instalado na máquina virtual. O agente se comunica com um serviço do Azure que gerencia backups automáticos de seus bancos de dados do SQL Server. O Backup do Azure também fornece um local central que você pode usar para gerenciar e monitorar os backups a fim de garantir o cumprimento de qualquer métrica RPO/RTO especificada.

Azure Backup for SQL Server Architecture

Como mostrado acima, a solução de Backup do Azure é uma solução de backup empresarial abrangente que fornece retenção de dados de longo prazo, gerenciamento automatizado e proteção adicional de dados. Essa opção custa mais do que simplesmente executar seus próprios backups ou usar o provedor de recursos do Azure para SQL Server, mas oferece um conjunto de recursos de backup mais completo.

Azure Site Recovery

O Azure Site Recovery é uma solução de baixo custo que executará a replicação no nível do bloco da sua máquina virtual do Azure. Esse serviço oferece várias opções, incluindo a capacidade de testar e verificar sua estratégia de recuperação de desastre. Essa solução é melhor usada em ambientes sem estado (por exemplo, servidores Web) em comparação com máquinas virtuais de banco de dados transacionais.

O Azure Site Recovery tem suporte para uso com o SQL Server, mas lembre-se de que você precisará definir um ponto de recuperação maior, o que significa que haverá possível perda. Nesse caso, o RTO essencialmente será o RPO.

Azure Site Recovery Architecture

  1. A VM é registrada no Azure Site Recovery
  2. Os dados são replicados continuamente para o cache
  3. O cache é replicado para a conta de armazenamento de destino
  4. Durante o failover, a máquina virtual é adicionada ao ambiente de destino