Explicar as opções de alta disponibilidade e recuperação de desastres
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 algumas cargas de trabalho PaaS. As zonas de disponibilidade e os conjuntos de disponibilidade protegem as suas cargas de trabalho contra atividades de manutenção planeadas e potenciais falhas de hardware.
Opções de elevada disponibilidade
A maioria das soluções de alta disponibilidade do SQL Server está disponível em máquinas virtuais (VMs) do Azure. Em uma solução somente do 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ê mude parcial ou completamente para o Azure para satisfazer os requisitos de orçamento e HADR de seus sistemas de banco de dados do SQL Server.
Zonas de Disponibilidade
As zonas de disponibilidade são locais físicos exclusivos dentro de uma região. Cada zona é composta por um ou mais centros de dados equipados com alimentação, arrefecimento e rede independentes. Nas regiões do Azure que dão suporte a Zonas de Disponibilidade, você pode especificar em qual zona deseja que a máquina virtual resida quando optar por usar Zonas Disponíveis durante a criação da VM. Existem três Zonas de Disponibilidade em cada região do Azure suportada. As zonas de disponibilidade fornecem alta disponibilidade contra falhas de data center quando você implanta várias VMs em zonas diferentes. Além disso, eles também fornecem um meio para a Microsoft executar a manutenção (usando um agrupamento chamado domínio de atualização) dentro de cada região, atualizando apenas uma zona a qualquer momento. Você pode espalhar seu ecossistema de máquina virtual em três zonas na região. A utilização de Zonas de Disponibilidade em conjunto com suas máquinas virtuais do Azure aumenta seu tempo de atividade para quatro noves (99,99%), o que equivale a um máximo de 52,60 minutos de tempo de inatividade por ano. Você pode identificar quais regiões do Azure oferecem suporte a Zonas de Disponibilidade em docs.microsoft.com. Se as Zonas de Disponibilidade estiverem disponíveis em sua região e seu aplicativo puder suportar a latência mínima entre zonas, as Zonas de Disponibilidade fornecerão o mais alto nível de disponibilidade para seu aplicativo.
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ê terá 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 uma implantação na Zona 1 em uma assinatura, não significa que a Zona 1 representa o mesmo data center em outra assinatura.
Conjuntos de Disponibilidade
Os conjuntos de disponibilidade são semelhantes às zonas de disponibilidade, exceto que, em vez de espalhar cargas de trabalho entre data centers em uma região, eles espalham cargas de trabalho entre servidores e racks em um data center. 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 seus membros do Grupo de Disponibilidade Always On não estejam sendo executadas 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 puder tolerar latência intrazona.
Grupos de disponibilidade Always On (AG)
Os grupos de disponibilidade Always On podem ser implementados entre duas ou mais (até um máximo de nove) instâncias 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 para a 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 (ou seja, se eles estão ou não na mesma região do Azure) dita qual modo de disponibilidade você deve escolher. Geralmente, se a carga de trabalho exigir a menor latência possível ou se as réplicas secundárias estiverem dispersas geograficamente, recomenda-se o modo de disponibilidade assíncrona. Se as réplicas estiverem na mesma região do Azure e os aplicativos puderem suportar algum nível de latência, o modo de confirmação síncrona deve ser considerado. O modo síncrono ajudará a garantir que cada transação seja confirmada para um ou mais secundários antes de permitir que o aplicativo continue. Os grupos de disponibilidade Always On fornecem alta disponibilidade e recuperação de desastres, porque um único grupo de disponibilidade pode oferecer suporte aos modos de disponibilidade síncrona e assíncrona. A unidade de failover para um grupo de disponibilidade é um grupo de bancos de dados e não a instância inteira.
Os Grupos de Disponibilidade Always On também podem ser usados para fins de recuperação de desastres. Você pode implementar até nove réplicas de um banco de dados em regiões do Azure e ampliar ainda mais essa arquitetura usando os Grupos de Disponibilidade Distribuída. Os Grupos de Disponibilidade garantem que uma cópia viável do(s) seu(s) banco(s) de dados esteja em outro local além da região principal. Ao fazer isso, você ajuda a garantir que seu ecossistema de dados esteja protegido contra desastres naturais, bem como alguns causados pelo homem.
A imagem acima mostra um diagrama lógico de um Grupo de Disponibilidade Always On, em execução em um Cluster de Failover do Windows Server. Há uma réplica primária e quatro réplicas secundárias. Nesse cenário, todas as cinco réplicas podem 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 em um nível de instância, ela não fornece recuperação de desastre.
Instâncias de Cluster de Failover do SQL Server
Se precisar proteger a instância inteira, você pode 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 desastres sem ser combinada com outro recurso, como grupos de disponibilidade ou envio de logs. As FCIs também exigem armazenamento compartilhado que pode ser fornecido no Azure usando o armazenamento de arquivos compartilhados 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 preferida para implantações mais recentes, porque a exigência de armazenamento compartilhado de FCIs aumenta a complexidade das implantações. No entanto, para migrações de soluções locais, uma FCI pode ser necessária para suporte a aplicativos.
Opções de recuperação de desastres
Embora a plataforma Azure ofereça 99,9% de tempo de atividade por padrão, desastres ainda podem ocorrer e afetar o tempo de atividade do aplicativo. É importante que você tenha um plano de recuperação de desastres adequado quando estiver executando qualquer tipo de migração. O Azure oferece-nos vários métodos para garantir que o seu SQL Server numa máquina virtual está protegido em caso de desastre. Esta proteção tem duas componentes. Primeiro, há opções de plataforma do Azure, como armazenamento replicado geograficamente para backups e o Azure Site Recovery, que é uma solução abrangente de recuperação de desastres para todas as suas cargas de trabalho. Em segundo lugar, há ofertas específicas do SQL Server, como grupos de disponibilidade e backups.
Backups nativos do SQL Server
Os backups são considerados a alma de qualquer administrador de banco de dados e não é diferente quando se trabalha com uma solução em 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 oferece a opção de usar o armazenamento com redundância geográfica (GRS) ou o armazenamento com redundância geográfica de acesso de leitura (RA-GRS) para garantir que seus arquivos de backup sejam armazenados com segurança em todo o cenário geográfico.
Além disso, como parte do provedor de serviços de VM SQL do Azure, você pode ter seus backups gerenciados automaticamente pela plataforma.
Azure Backup para SQL Server
A solução de Backup do Azure requer que um agente seja instalado na máquina virtual. Em seguida, 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 para garantir o cumprimento de quaisquer métricas de RPO/RTO especificadas.
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 de dados adicional. 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 em nível de bloco da sua máquina virtual do Azure. Este serviço oferece várias opções, incluindo a capacidade de testar e verificar sua estratégia de recuperação de desastres. Essa solução é melhor usada para ambientes sem monitoração de estado (por exemplo, servidores Web) versus 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 mais alto, o que significa perda potencial. Neste caso, o seu RTO será essencialmente o seu RPO.
- A VM está registrada no Azure Site Recovery
- Os dados são replicados continuamente para cache
- O cache é replicado para a conta de armazenamento de destino
- Durante o failover, a máquina virtual é adicionada ao ambiente de destino