Visão geral das operações de gerenciamento na Instância Gerenciada SQL do Azure

Aplica-se a:Azure SQL Managed Instance

Este artigo fornece uma visão geral das diferentes operações que ocorrem ao gerenciar a Instância Gerenciada SQL do Azure. As operações de gerenciamento são operações executadas no back-end quando você cria, atualiza ou exclui uma instância.

Para obter uma descrição detalhada das etapas e da duração estimada de cada operação de gestão, consulte a duração das operações de gestão.

O que são operações de gestão?

O gerenciamento da Instância Gerenciada SQL do Azure envolve as seguintes operações:

• Criar: as operações que ocorrem quando você cria pela primeira vez uma nova instância gerenciada pelo SQL. Isso inclui a criação do grupo de máquinas virtuais (VM) subjacentes e a implantação do processo do Mecanismo de Banco de Dados SQL.
• Atualização: operações que ocorrem quando você altera as propriedades de uma instância gerenciada SQL existente, como dimensionamento de computação ou armazenamento, alteração da camada de serviço ou atualização da configuração da instância. Fazer atualizações geralmente envolve o redimensionamento do grupo de VMs, bem como a propagação de dados e, em seguida, o failover para um novo processo do Mecanismo de Banco de Dados SQL.
• Excluir: operações que ocorrem quando você exclui uma instância gerenciada SQL existente, incluindo a limpeza de recursos como o grupo de VMs associado à instância.

Para obter uma descrição detalhada das etapas e da duração estimada de cada operação de gestão, consulte a duração das operações de gestão.

As operações de gerenciamento de instâncias gerenciadas SQL são realizadas por meio dos seguintes processos subjacentes:

• Operações de grupo de máquinas virtuais (VM): operações que envolvem a criação e o gerenciamento do grupo de VMs subjacente que hospeda a instância gerenciada pelo SQL. Isso inclui redimensionar o grupo de VMs, criar novos grupos de VMs e gerenciar as máquinas virtuais dentro desses grupos.
• Semeadura: A inicialização e sincronização de dados entre processos do Mecanismo de Banco de Dados SQL, geralmente para preparar um failover.
• Failover: operações que envolvem o failover do tráfego para outro processo do Mecanismo de Banco de Dados SQL, no mesmo grupo de VMs ou num novo.

Operações de grupo VM

Para dar suporte a implantações em redes virtuais do Azure e fornecer isolamento e segurança para os clientes, a Instância Gerenciada do SQL depende de clusters virtuais. O cluster virtual representa um conjunto dedicado de máquinas virtuais (VMs) isoladas implantadas dentro da sub-rede da rede virtual e organizadas em grupos de VMs. Essencialmente, cada instância gerenciada SQL implantada em uma sub-rede vazia resulta em um novo cluster virtual que cria o primeiro grupo de VMs.

As operações de gerenciamento subsequentes em instâncias gerenciadas pelo SQL podem afetar os grupos de VMs subjacentes. As alterações que afetam os grupos de VM subjacentes podem afetar a duração das operações de gerenciamento, já que a implantação de mais máquinas virtuais no cluster virtual vem com uma sobrecarga que você precisa considerar ao planejar novas implantações ou atualizações para instâncias existentes.

Para obter informações detalhadas sobre a arquitetura de cluster virtual, consulte Arquitetura de cluster virtual.

Semeadura

A semeadura desempenha um papel crítico na operação da Instância Gerenciada SQL do Azure, particularmente durante a instalação e a replicação de bancos de dados. A semeadura é o processo que inicializa e sincroniza dados entre os processos do Mecanismo de Banco de Dados SQL, que é uma parte crucial do gerenciamento de instâncias. Embora muitas vezes seja a etapa mais demorada em operações longas, mas bem-sucedidas, a semeadura serve como uma pedra angular para estabelecer um ambiente de instância gerenciado SQL saudável e funcional.

Para obter uma duração estimada das operações de semeadura, consulte Duração das operações de gerenciamento.

O processo de semeadura normalmente envolve os seguintes estágios, independentemente da camada de serviço:

• Inicialização: o sistema identifica o banco de dados de origem e destino e inicia várias tarefas que preparam os processos do Mecanismo de Banco de Dados SQL para transferência de dados.
• Transferência de dados: os pacotes de dados reais são transferidos da origem para o processo do Mecanismo de Banco de Dados SQL de destino, que inclui uma cópia completa ou parcial do banco de dados, dependendo do cenário.
• Sincronização: Uma vez concluída a transferência inicial de dados, o sistema sincroniza quaisquer atualizações ou alterações subsequentes através da replicação de blocos de log de transações para garantir a integridade dos dados.
• Validação e finalização: o processo é finalizado e o processo do Mecanismo de Banco de Dados SQL de destino é validado para confirmar a replicação e a propagação bem-sucedidas. O failover ocorre para que o tráfego seja encaminhado para o novo processo do Motor de Base de Dados SQL.

Não há propagação de dados na camada de serviço General Purpose, exceto quando o utilizador altera a camada de serviço para Business Critical. As operações de gerenciamento na camada de serviço de uso geral envolvem desanexar o armazenamento remoto do antigo processo do Mecanismo de Banco de Dados SQL e anexá-lo ao novo processo do Mecanismo de Banco de Dados SQL.

Por outro lado, a camada de serviço Business Critical , projetada para cargas de trabalho de alto desempenho, requer armazenamento local e a codependência de camadas de computação e armazenamento. Consequentemente, quase todas as operações e cenários nessa camada de serviço exigem semeadura para garantir a disponibilidade e a consistência dos dados.

Se a semeadura é acionada ou não, depende do cenário específico e da camada de serviço, como:

• Níveis de serviço de Uso Geral e Uso Geral de Nova Geração :
  • Mudar para a camada de serviço Crítica para os Negócios – os dados devem ser transferidos do armazenamento remoto para o armazenamento local usado na camada de serviço de Uso Geral.
  • Habilitando ou desabilitando a redundância de zona – os dados devem ser copiados de ou para as regiões redundantes da zona.
• Nível de serviço crítico para os negócios :
  • Dimensionamento do armazenamento: Como o armazenamento está fisicamente conectado à máquina local, cada alteração de armazenamento requer a criação de um novo grupo de VMs, portanto, os dados devem ser transferidos da máquina antiga para a nova máquina (em todas as 4 réplicas).
  • Dimensionamento de vCores: Toda operação de dimensionamento de computação requer a criação de um novo grupo de VMs, portanto, os dados devem ser copiados da máquina antiga para a nova máquina (em todas as 4 réplicas).
  • Alterando hardware ou janela de manutenção: se já existir um grupo de VMs na sub-rede com uma configuração correspondente, esse grupo de VMs será redimensionado. Se esta for uma nova configuração, um novo grupo de VMs será criado. Os dados devem ser copiados do grupo de VMs antigo para o novo grupo de VMs (em todas as 4 réplicas).
  • Alterar a camada de serviço: os dados devem ser copiados do armazenamento local para o armazenamento remoto usado na camada de serviço de uso geral.
  • Habilitando ou desabilitando a redundância de zona – os dados devem ser copiados de ou para as regiões redundantes da zona.

Velocidades de semeadura

Os seguintes fatores afetam a duração do processo de semeadura:

• Tamanho do banco de dados: bancos de dados maiores exigem mais tempo para transferir dados e sincronizar entre os processos do Mecanismo de Banco de Dados SQL.
• Dependências de rede: A largura de banda e a latência da rede podem influenciar significativamente as velocidades de propagação.
• Operações de backup e restauração: as operações de backup contínuas no processo do Mecanismo de Banco de Dados SQL de origem podem influenciar a preparação de dados para enviar a outro processo do Mecanismo de Banco de Dados SQL.
• Carga de trabalho da instância: a carga de trabalho da instância durante a propagação pode causar restrição e prolongar significativamente o processo.

Embora a maioria desses fatores esteja além do seu controle, você pode gerenciar o tráfego de instâncias para otimizar significativamente as velocidades de propagação. A semeadura usa os mesmos recursos de computação de instância que gerenciam o tráfego da instância. O tráfego intenso durante a semeadura pode reduzir a disponibilidade do vCore, resultando em capacidade insuficiente para o processo de semeadura, causando limitação.

O tráfego intenso durante a distribuição pode afetar a sincronização, uma vez que a distribuição é projetada para empacotar e transferir todos os dados armazenados atualmente em uma só operação. As alterações de dados subsequentes ao antigo processo do Mecanismo de Banco de Dados SQL, que ocorrem após o início da propagação, devem ser sincronizadas incrementalmente com o novo processo do Mecanismo de Banco de Dados SQL através da replicação de blocos de log de transações, antes que o failover possa ocorrer. Se a instância estiver sob carga pesada, o processo de inicialização pode ter dificuldade em manter o ritmo com os dados recebidos, levando a atrasos e possíveis falhas na fase de sincronização. O alto tráfego contínuo no antigo processo do Mecanismo de Banco de Dados SQL após o início da propagação pode levar a uma situação em que a fase de sincronização nunca é concluída, pois novos dados continuam chegando e devem ser transferidos. Isso pode resultar num ciclo perpétuo de transferência de dados que impede a comutação para o novo processo do Motor de Base de Dados SQL.

Para obter uma duração estimada das operações de semeadura, consulte Duração das operações de gerenciamento.

Infraestrutura e avisos do Azure

A semeadura é um processo que não pode ser quantificado com precisão ou estritamente previsto, pois depende dos serviços compartilhados do Azure. As operações de transferência e propagação de dados dependem de vários serviços e infraestrutura internos do Azure, que são compartilhados em todo o ecossistema do Azure. Esses serviços são utilizados por vários outros serviços não relacionados no Azure. Todos os serviços dentro do ecossistema do Azure competem pelos recursos disponíveis, o que leva a flutuações na disponibilidade momentânea influenciadas por vários fatores. Embora a Microsoft possa fornecer uma gama na qual a capacidade de infraestrutura opera, fazer previsões precisas é um desafio.

Alternância em caso de falha

O failover de instância é o momento em que o tráfego é roteado de um processo antigo do Mecanismo de Banco de Dados SQL para um novo processo do Mecanismo de Banco de Dados SQL dentro do grupo de nós em um grupo de VMs que engloba a instância gerenciada pelo SQL. O failover é uma parte crucial da maioria das operações de gestão, especialmente ao atualizar uma instância. O curto momento de conexões interrompidas enquanto o tráfego é redirecionado para o novo processo do Mecanismo de Banco de Dados SQL é conhecido como failover.

Sua instância só fica indisponível durante o failover, quando o tráfego é redirecionado para o novo processo do Mecanismo de Banco de Dados SQL. Na camada de serviço Business Critical , sua instância fica indisponível por até 20 segundos, enquanto na camada de serviço de uso geral , sua instância pode ficar indisponível por até 2 minutos. Todas as operações em segundo plano que ocorrem para preparar o failover devido a uma operação de gestão, como a repropagação de bases de dados na camada de serviço Essencial para os Negócios, acontecem em segundo plano e não afetam a disponibilidade da sua instância.

As diferenças arquitetônicas entre as camadas de serviço são explicadas detalhadamente na disponibilidade.

Impacto cruzado nas operações de gestão

As operações de gerenciamento em uma instância gerenciada pelo SQL podem afetar as operações de gerenciamento de outras instâncias colocadas dentro da mesma sub-rede:

• As operações de restauração de longa duração em um cluster virtual colocam outras operações no mesmo cluster virtual em espera, como operações de criação ou dimensionamento.

  Exemplo: Se houver uma operação de restauração de longa duração e também uma solicitação de escala que reduza o grupo de VMs, a solicitação de redução levará mais tempo para ser concluída, pois aguarda a conclusão da operação de restauração antes de poder continuar.

• Uma operação subsequente de criação ou dimensionamento de instância é suspensa por uma criação de instância iniciada anteriormente ou uma escala de instância que iniciou um redimensionamento do grupo de VMs.

  Exemplo: Se existirem múltiplos pedidos de criação e/ou escala na mesma sub-rede sob o mesmo grupo de VM, e um deles iniciar uma redimensionação do grupo de VM, todos os pedidos submetidos 1+ minutos após o pedido inicial duram mais do que o esperado, pois estes pedidos devem esperar que o redimensionamento seja concluído antes de retomar.

• As operações de criação/dimensionamento enviadas em uma janela de 1 minuto são agrupadas em lote e executadas em paralelo.

  Exemplo: Apenas um redimensionamento de cluster virtual é executado para todas as operações enviadas em uma janela de 1 minuto (medida a partir do momento em que a primeira solicitação de operação é enviada). Se outra solicitação for enviada mais de 1 minuto após o envio da primeira, ela aguardará a conclusão do redimensionamento do cluster virtual antes do início da execução.

Monitorizar operações de gestão

Para saber como monitorar o progresso e o status da operação de gerenciamento, consulte Monitorando as operações de gerenciamento da Instância Gerenciada SQL do Azure.

Cancelar operações de gerenciamento

Para saber como cancelar a operação de gerenciamento, consulte Cancelando operações de gerenciamento da Instância Gerenciada SQL do Azure.

Conteúdo relacionado

• Guia de início rápido: criar de instância gerenciada SQL do Azure
• Comparação de recursos: Banco de Dados SQL do Azure e Instância Gerenciada SQL do Azure
• Arquitetura de conectividade para a Instância Gerenciada SQL do Azure
• Arquitetura de cluster virtual - Instância Gerenciada SQL do Azure
• Migração de instância gerenciada SQL usando o Serviço de Migração de Banco de Dados