Alta disponibilidade para a Instância Gerenciada SQL do Azure

  • Artigo

Aplica-se a:Instância Gerenciada SQL do Azure

Este artigo descreve a alta disponibilidade na Instância Gerenciada SQL do Azure.

Importante

A configuração com redundância de zona está em pré-visualização pública para a camada de serviço de Uso Geral e geralmente disponível para a camada de serviço Crítica de Negócios.

Descrição geral

O objetivo da arquitetura de alta disponibilidade na Instância Gerenciada SQL do Azure é minimizar o impacto nas cargas de trabalho do cliente das operações de gerenciamento iniciadas pelo cliente que resultam em um breve tempo de inatividade, operações de manutenção de serviço e interrupções não planejadas. Para obter mais informações sobre SLAs específicos para diferentes camadas de serviço, consulte Instância Gerenciada SQL do Azure. A alta disponibilidade é o conceito que o protege contra impactos que têm como escopo o

  • zona de disponibilidade que forma o datacenter (no caso de região multizona),
  • rack onde os nós que alimentam o seu serviço estão em execução,
  • nó em si,
  • camada de aplicação.

Para minimizar o impacto em caso de interrupções regionais ou maiores, você pode usar uma das técnicas disponíveis cobertas com nossa visão geral da continuidade de negócios.

A Instância Gerenciada SQL é executada na versão estável mais recente do Mecanismo de Banco de Dados do SQL Server no sistema operacional Windows com todos os patches aplicáveis. A Instância Gerenciada SQL lida automaticamente com tarefas críticas de manutenção, como patches, backups, atualizações do Windows e do mecanismo SQL e eventos não planejados, como falhas subjacentes de hardware, software ou rede. Quando uma instância é corrigida ou faz failover, o tempo de inatividade não é afetado se você empregar a lógica de repetição em seu aplicativo. A Instância Gerenciada SQL pode se recuperar rapidamente mesmo nas circunstâncias mais críticas, garantindo que seus dados estejam sempre disponíveis. A maioria dos usuários não percebe que as atualizações são executadas continuamente.

A solução de alta disponibilidade foi projetada para garantir que os dados comprometidos nunca sejam perdidos devido a falhas, que as operações de manutenção não afetem sua carga de trabalho e que a instância não seja um único ponto de falha em sua arquitetura de software.

Existem dois modelos diferentes de arquitetura de alta disponibilidade com base na camada de serviço:

  • O modelo de armazenamento remoto é baseado em uma separação de computação e armazenamento na camada de serviço de uso geral que depende da alta disponibilidade e confiabilidade do armazenamento remoto e da alta disponibilidade de clusters de computação gerenciados pelo Azure Service Fabric. Este modelo de alta disponibilidade destina-se a aplicações empresariais orientadas para o orçamento que podem tolerar alguma degradação do desempenho durante as atividades de manutenção.
  • O modelo de armazenamento local é baseado em um cluster de processos do mecanismo de banco de dados que dependem de um quórum de nós de mecanismo de banco de dados disponíveis na camada de serviço Crítica para os Negócios que têm armazenamento local. Esse modelo de armazenamento local tem como alvo aplicativos de missão crítica que têm uma alta taxa de transações e exigem alto desempenho de E/S. A arquitetura de alta disponibilidade garante um impacto mínimo no desempenho da sua carga de trabalho durante as atividades de manutenção.

Disponibilidade localmente redundante

A disponibilidade localmente redundante baseia-se no armazenamento de nós de computação e dados em um único datacenter na região primária e protege seus dados em caso de falha local, como uma rede de pequena escala ou falha de energia. Se ocorrer um desastre de grande escala, como incêndio ou inundação, em uma região, todas as réplicas de uma conta de armazenamento ou dados nos nós de computação poderão ser perdidos ou irrecuperáveis. Como tal, para proteger ainda mais seus dados ao usar a opção de disponibilidade localmente redundante, considere o uso de uma opção de armazenamento mais resiliente para seus backups de banco de dados.

Nível de serviço de uso geral

A camada de serviço de uso geral usa a arquitetura de disponibilidade de armazenamento remoto. A seguinte figura mostra quatro nós diferentes com as camadas de computação e de armazenamento separadas.

Diagram showing separation of compute and storage.

O modelo de disponibilidade de armazenamento remoto inclui duas camadas:

  • Uma camada de computação sem estado que executa o processo do mecanismo de banco de dados e contém apenas dados transitórios e armazenados em cache, como os tempdb bancos de dados e no SSD conectado, e planeja cache, pool de buffers e model pool columnstore na memória. Esse nó sem estado é operado pelo Azure Service Fabric que inicializa o mecanismo de banco de dados, controla a integridade do nó e executa failover para outro nó, se necessário.
  • Uma camada de dados com estado com os arquivos de banco de dados (.mdf e .ldf) armazenados no Armazenamento de Blobs do Azure. O Armazenamento de Blobs do Azure tem recursos internos de disponibilidade e redundância de dados. A disponibilidade com redundância local baseia-se no armazenamento de dados em LRS (armazenamento com redundância local), que copia os dados três vezes em um único datacenter na região principal. Ele garante que todos os registros no arquivo de log ou página no arquivo de dados serão preservados mesmo se o processo do mecanismo de banco de dados falhar.

Sempre que o mecanismo de banco de dados ou o sistema operacional for atualizado ou uma falha for detetada, o Azure Service Fabric moverá o processo do mecanismo de banco de dados sem estado para outro nó de computação sem estado com capacidade livre suficiente. Os dados no armazenamento de Blob do Azure não são afetados pela mudança e os arquivos de dados/log são anexados ao processo do mecanismo de banco de dados recém-inicializado. Esse processo garante alta disponibilidade, mas uma carga de trabalho pesada pode sofrer alguma degradação de desempenho durante a transição, uma vez que o novo processo do mecanismo de banco de dados começa com cache frio.

Nível de serviço crítico para os negócios

A camada de serviço Business Critical usa o modelo de disponibilidade de armazenamento local, que integra recursos de computação (processo do mecanismo de banco de dados) e armazenamento (SSD conectado localmente) em um único nó. A alta disponibilidade é obtida replicando a computação e o armazenamento para nós adicionais.

Diagram of a cluster of database engine nodes.

Os arquivos de banco de dados subjacentes (.mdf/.ldf) são colocados no armazenamento SSD conectado para fornecer E/S de latência muito baixa para sua carga de trabalho. A alta disponibilidade é implementada usando uma tecnologia semelhante aos grupos de disponibilidade Always On do SQL Server. O cluster inclui uma única réplica primária acessível para cargas de trabalho de clientes de leitura-gravação e até três réplicas secundárias (computação e armazenamento) que contêm cópias de dados. A réplica primária envia constantemente as alterações para as réplicas secundárias sequencialmente para garantir que os dados persistam em um número suficiente de réplicas secundárias antes de confirmar cada transação. Esse processo garante que, se a réplica primária ou uma réplica secundária legível ficar indisponível por qualquer motivo, uma réplica totalmente sincronizada estará sempre disponível para failover. O failover é iniciado pelo Azure Service Fabric. Quando uma réplica secundária se torna a nova réplica primária, outra réplica secundária é criada para garantir que o cluster tenha um número suficiente de réplicas para manter o quórum. Após a conclusão do failover, as conexões SQL do Azure são redirecionadas automaticamente para a nova réplica primária (ou réplica secundária legível com base na cadeia de conexão).

Como um benefício extra, o modelo de disponibilidade de armazenamento local inclui a capacidade de redirecionar conexões SQL do Azure somente leitura para uma das réplicas secundárias. Esse recurso é chamado de Expansão de Leitura. Ele fornece 100% de capacidade de computação adicional sem custo adicional para descarregar operações somente leitura, como cargas de trabalho analíticas, da réplica principal.

Disponibilidade com redundância de zona

A disponibilidade com redundância de zona baseia-se na colocação de réplicas de nó de computação e armazenamento em três zonas de disponibilidade do Azure na região primária. Cada zona de disponibilidade é uma localização física separada com energia, refrigeração e rede independentes,

Por padrão, o cluster de nós para o modelo de disponibilidade de armazenamento local é criado no mesmo datacenter. Com a introdução das Zonas de Disponibilidade do Azure, a Instância Gerenciada do SQL pode colocar réplicas diferentes de uma instância Crítica de Negócios em diferentes zonas de disponibilidade na mesma região. Da mesma forma, os nós de computação sem estado de uma camada de serviço de uso geral são colocados em uma zona de disponibilidade diferente, enquanto o armazenamento com monitoração de estado está usando a configuração ZRS (armazenamento redundante de zona).

Para eliminar um único ponto de falha, o anel de controle também é duplicado em várias zonas como três anéis de gateway (GW). O roteamento para um anel de gateway específico é controlado pelo Azure Traffic Manager (ATM). Ao selecionar uma configuração com redundância de zona, você pode tornar suas instâncias críticas para os negócios ou de uso geral resilientes a um conjunto muito maior de falhas, incluindo interrupções catastróficas do datacenter, sem alterações na lógica do aplicativo. Você também pode converter qualquer instância de uso geral ou crítica de negócios existente em configuração com redundância de zona.

Como as instâncias com redundância de zona têm réplicas em diferentes datacenters com alguma distância entre elas, o aumento da latência da rede pode aumentar o tempo de confirmação da transação e, portanto, afetar o desempenho de algumas cargas de trabalho OLTP. Você sempre pode retornar à configuração de zona única desativando a configuração de redundância de zona. Esse processo é uma operação on-line semelhante à atualização regular do objetivo da camada de serviço. No final do processo, a instância é migrada de um anel redundante de zona para um anel de zona única ou vice-versa.

A versão com redundância de zona da arquitetura de alta disponibilidade é ilustrada pelo diagrama a seguir:

Diagram of the zone-redundant high availability architecture.

Considere o seguinte ao usar redundância de zona:

  • Para obter informações atualizadas sobre as regiões que oferecem suporte a configurações com redundância de zona, consulte Suporte de serviços por região.
  • Para disponibilidade redundante de zona, escolher uma janela de manutenção diferente da padrão está atualmente disponível em regiões selecionadas.

Regiões suportadas para instâncias críticas de negócios

A redundância de zona para a Instância Gerenciada SQL Crítica para Negócios é suportada nas seguintes regiões:

Américas Europa Médio Oriente África Ásia-Pacífico
Sul do Brasil França Central Catar Central Norte da África do Sul Leste da Austrália
Canadá Central Norte da Itália Israel Central Índia Central
E.U.A. Central Alemanha Centro-Oeste Leste do Japão
E.U.A. Leste Leste da Noruega Coreia do Sul Central
E.U.A. Leste 2 Europa do Norte Sudeste Asiático
E.U.A. Centro-Sul Sul do Reino Unido Ásia Leste
E.U.A. Oeste 2 Suécia Central
EUA Oeste 3 Norte da Suíça
Polónia Central

Regiões suportadas para instâncias de uso geral

Nota

A configuração com redundância de zona está em pré-visualização pública para a camada de serviço de uso geral.

Américas Europa Médio Oriente África Ásia-Pacífico
Sul do Brasil França Central Catar Central Norte da África do Sul Leste da Austrália
E.U.A. Leste Norte da Itália Israel Central Índia Central
E.U.A. Leste 2 Alemanha Centro-Oeste Leste do Japão
E.U.A. Centro-Sul Leste da Noruega Coreia do Sul Central
E.U.A. Oeste 2 Europa do Norte Sudeste Asiático
EUA Oeste 3 Sul do Reino Unido Ásia Leste
Suécia Central
Norte da Suíça
Polónia Central

Testar a resiliência a falhas do aplicativo

A alta disponibilidade é uma parte fundamental da plataforma SQL Managed Instance que funciona de forma transparente para seu aplicativo de banco de dados. No entanto, reconhecemos que talvez você queira testar como as operações automáticas de failover iniciadas durante eventos planejados ou não planejados afetariam um aplicativo antes de implantá-lo na produção. Pode ativar manualmente uma ativação pós-falha ao chamar uma API especial para reiniciar uma instância gerida. No caso de uma instância redundante de zona, a chamada de API resultaria no redirecionamento de conexões de cliente para o novo primário em uma zona de disponibilidade diferente da zona de disponibilidade do primário antigo. Portanto, além de testar como o failover afeta as sessões de banco de dados existentes, você também pode verificar se ele altera o desempenho de ponta a ponta devido a alterações na latência da rede. Como a operação de reinicialização é intrusiva e um grande número deles pode sobrecarregar a plataforma, apenas uma chamada de failover é permitida a cada 15 minutos para cada instância gerenciada.

Um failover pode ser iniciado usando PowerShell, API REST ou CLI do Azure:

PowerShell API REST CLI do Azure
Invoke-AzSqlInstanceFailover Instância gerenciada SQL - Failover az sql mi failover pode ser usado para invocar uma chamada de API REST da CLI do Azure

Conclusão

A Instância Gerenciada SQL do Azure apresenta uma solução interna de alta disponibilidade que é profundamente integrada à plataforma Azure. O serviço depende do Service Fabric para detetar falhas e recuperar, do armazenamento de Blob do Azure para proteger dados e das Zonas de Disponibilidade para maior tolerância a falhas. E para a camada de serviço Business Critical, a Instância Gerenciada SQL usa a tecnologia de grupo de disponibilidade Always On do SQL Server para replicação e failover de banco de dados. A combinação dessas tecnologias permite que os aplicativos aproveitem plenamente os benefícios de um modelo de armazenamento misto e ofereça suporte aos SLAs mais exigentes.

Próximos passos