Share via

Alta disponibilidade da Instância Gerenciada de SQL do Azure

  • Artigo

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

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

Importante

A configuração com redundância de zona está em visualização pública para a camada de serviço de Uso Geral e em disponibilidade geral para a camada de serviço Comercialmente Crítico.

Visão geral

O objetivo da arquitetura de alta disponibilidade na Instância Gerenciada de SQL do Azure é minimizar o impacto sobre as cargas de trabalho do cliente por meio de 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 as SLAs específicas para diferentes camadas de serviço, examine Instância Gerenciada de SQL do Azure.

A alta disponibilidade é uma proteção contra impactos em:

  • Zona de disponibilidade que forma o datacenter (no caso de uma região com várias zonas)
  • Rack no qual os nós que impulsionam o serviço estão em execução
  • Nó em si
  • Camada de aplicativo

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

A Instância Gerenciada de SQL do Azure é 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 de SQL do Azure cuida automaticamente de tarefas de manutenção críticas, como aplicação de patch, backups, atualizações do SQL do Azure e do Windows, bem como eventos não planejados, como hardware subjacente, software ou falhas de rede. Ao aplicar patch ou fazer failover de uma instância, o tempo de inatividade não será perceptível se você empregar a lógica de repetição no aplicativo. A Instância Gerenciada de SQL pode se recuperar rapidamente, até mesmo nas circunstâncias mais críticas, garantindo que os 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 confirmados 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 ponto único de falha em sua arquitetura de software.

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

  • O modelo de armazenamento remoto se baseia em uma separação entre a computação e o armazenamento nas camadas de serviço Uso Geral e Uso Geral de Última Geração que depende da alta disponibilidade e confiabilidade do armazenamento remoto e da alta disponibilidade de clusters de computação gerenciados pelo Azure Service Fabric. Esse modelo de alta disponibilidade destina-se a aplicativos de negócios orientados para o orçamento que podem tolerar alguma degradação de desempenho durante atividades de manutenção.
  • O modelo de armazenamento local é baseado em um cluster de processos de mecanismo de banco de dados que dependem de um quorum de nós de mecanismo de banco de dados disponíveis na camada de serviço Business Critical que possuem armazenamento local. Esse modelo de armazenamento local destina-se a 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 com redundância local

A disponibilidade com redundância local baseia-se em armazenar os nós de computação e os dados em um único datacenter na região primária e protege os dados em caso de falha local, como uma falha na rede de pequena escala ou de energia. Caso ocorra um desastre em larga escala na região, como um incêndio ou uma inundação, todas as réplicas da conta de armazenamento ou dados dos nós de computação poderão ser perdidos ou se tornarem irrecuperáveis. Dessa forma, para proteger ainda mais seus dados ao usar a opção de disponibilidade com redundância local, considere usar uma opção de armazenamento mais resiliente para os backups de banco de dados.

Camada de serviço de Uso Geral

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

Diagrama mostrando a separação de computação e armazenamento.

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 em cache, como os bancos de dado tempdb e model no SSD anexado e cache de planos, pool de buffer e pool columnstore na memória. Este nó sem estado é operado pelo Microsoft Azure Service Fabric, que inicializa o mecanismo de banco de dados, controla a integridade do nó e executa o failover para outro nó, se necessário.
  • Uma camada de dados com estado, com arquivos de banco de dados (.mdf e .ldf) que são armazenados no Armazenamento de Blobs do Azure. O Armazenamento de Blobs do Azure possui recursos internos de redundância e disponibilidade de dados. A disponibilidade com redundância local baseia-se em armazenar os dados no LRS (armazenamento com redundância local), que copia seus dados três vezes em um único datacenter na região primária. Ele garante que todos os registros no arquivo de log ou na página do 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 detectada, 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 Blobs do Azure não são afetados pela movimentação, e os arquivos de dados/log são anexados ao processo do mecanismo de banco de dados recém-inicializado. Esse processo garante a alta disponibilidade, mas uma carga de trabalho pesada pode enfrentar degradação do desempenho durante a transição, uma vez que o novo processo do mecanismo de banco de dados começa com o cache frio.

Camada de serviço Uso Geral de Última Geração

Observação

No momento, a atualização da camada de serviço Uso Geral de Última Geração está em preview.

O Uso Geral de Última Geração corresponde a uma atualização da arquitetura da camada de serviço Uso Geral existente que usa uma camada de armazenamento remoto atualizada que armazena dados de instância e arquivos de registros em log em discos gerenciados em vez de em blobs de páginas.

Camada de serviço comercialmente crítica

A camada de serviço Comercialmente Crítico usa o modelo de disponibilidade de armazenamento local, que integra os recursos de computação (processo do mecanismo de banco de dados) e o armazenamento (SSD anexado localmente) em um nó individual. A alta disponibilidade é obtida com a replicação da computação e do armazenamento para nós adicionais.

Diagrama de um cluster de nós de mecanismo de banco de dados.

Os arquivos de banco de dados subjacentes (.mdf/.ldf) são colocados no armazenamento SSD anexado para fornecer uma E/S de latência muito baixa para sua carga de trabalho. A alta disponibilidade é implementada usando tecnologia semelhante ao SQL Server Grupos de Disponibilidade AlwaysOn. O cluster inclui uma única réplica primária que é acessível para cargas de trabalho de leitura/gravação do cliente 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 sejam mantidos 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 o failover. O failover é iniciado pelo Azure Service Fabric. Depois que a réplica secundária se torna a nova réplica primária, outra réplica secundária é criada para garantir que o cluster tenha o número suficiente de réplicas para manter o quorum. Após a conclusão do failover, as conexões do Azure SQL 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 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 uma capacidade de computação adicional de 100%, sem custo adicional, para operações somente leitura fora do carregamento, como cargas de trabalho analíticas, da réplica primária.

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 é um local físico separado com energia, resfriamento 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 de SQL pode posicionar réplicas diferentes da instância Comercialmente Crítico 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 estado está usando a configuração armazenamento redundante de zona (ZRS).

Para eliminar um ponto único de falha, o anel de controle também é duplicado entre várias zonas como três GW (anéis de gateway). O roteamento para um anel de gateway específico é controlado pelo ATM (Gerenciador de Tráfego do Microsoft Azure). Ao selecionar uma configuração com redundância de zona, você pode tornar as instâncias do tipo Comercialmente Crítico ou Uso Geral resilientes a um conjunto muito maior de falhas, incluindo interrupções catastróficas do datacenter, sem nenhuma alteração na lógica de aplicativo. Além disso, é possível converter quaisquer instâncias Comercialmente Crítico ou Uso Geral existentes na configuração com redundância de zona.

Como a instância com redundância de zona tem réplicas em diferentes datacenters com alguma distância entre eles, a latência de rede aumentada pode aumentar o tempo de confirmação da transação e, desse modo, afetar o desempenho de algumas cargas de trabalho OLTP. Você sempre poderá retornar à configuração de única zona desabilitando a configuração com redundância de zona. Esse processo é uma operação online semelhante à atualização do objetivo da camada de serviço normal. No final do processo, a instância será migrada de um anel com redundância de zona para um anel de única zona ou vice-versa.

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

Diagrama da arquitetura de alta disponibilidade com redundância de zona.

Considere o seguinte ao usar a redundância de zona:

  • A redundância de zona não está disponível para a camada de serviço Uso Geral de Última Geração.
  • Para obter informações atualizadas sobre as regiões que dão suporte a configurações com redundância de zona, confira Suporte a serviços por região.
  • Para disponibilidade redundante de zona, a escolha de uma janela de manutenção diferente do padrão está atualmente disponível em regiões selecionadas.

Regiões com suporte para instâncias Comercialmente Crítico

A redundância de zona para instância gerenciada de SQL Comercialmente Crítico tem suporte nas seguintes regiões:

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

Regiões com suporte para instâncias de uso geral

Observação

Configuração com redundância de zona está em Visualização Pública para a camada de serviço de uso geral.

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

Testar a resiliência de falha do aplicativo

A alta disponibilidade é uma parte fundamental da plataforma Instância Gerenciada de SQL que funciona de maneira transparente para o aplicativo de banco de dados. No entanto, reconhecemos que talvez você queira testar como as operações de failover automático iniciadas durante os eventos planejados ou não planejados afetariam um aplicativo antes de implantá-lo na produção. Você pode disparar um failover manualmente chamando uma API especial para reiniciar uma instância gerenciada. No caso de uma instância com redundância de zona, a chamada à 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. Assim, 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 de rede. Como a operação de reinicialização é intrusiva e o excesso da mesma 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 o PowerShell, a API REST ou CLI do Azure:

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

Conclusão

A Instância Gerenciada de SQL do Azure apresenta uma solução de alta disponibilidade interna, que está profundamente integrada com a plataforma Azure. O serviço depende do Service Fabric para detectar falhas e recuperá-las, do armazenamento de Blob do Azure para proteger os dados e das Zonas de Disponibilidade para maior tolerância a falhas. Para a camada de serviço Comercialmente Crítico, a Instância Gerenciada de 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 percebam em sua totalidade os benefícios de um modelo de armazenamento misto e deem suporte aos SLAs mais exigentes.

Próximas etapas