Compartilhar via


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

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

Este artigo fornece uma visão geral das diferentes operações que ocorrem ao gerenciar a Instância Gerenciada de 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 gerenciamento, examine a duração das operações de gerenciamento.

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

O gerenciamento da Instância Gerenciada de 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 de SQL. Isso inclui a criação do grupo de máquinas virtuais (VM) subjacente 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 de 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. Geralmente, fazer atualizações envolve redimensionar o grupo de VM, propagar dados e depois fazer failover para um novo processo do Mecanismo do Banco de Dados SQL.
  • Excluir: operações que ocorrem quando você exclui uma instância gerenciada de SQL existente, incluindo a limpeza de recursos como o grupo de VM associado à instância.

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

As operações de gerenciamento da Instância Gerenciada de SQL são realizadas por meio dos seguintes processos subjacentes:

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

Operações de grupo de VM

Para dar suporte a implantações nas redes virtuais do Azure e fornecer isolamento e segurança para clientes, a Instância Gerenciada de SQL depende de clusters virtuais. O cluster virtual representa um conjunto dedicado de VMs (máquinas virtuais) isoladas implantadas dentro de sua sub-rede de rede virtual e organizadas em grupos de VMs. Essencialmente, cada instância gerenciada de 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 de SQL podem afetar os grupos de VM subjacentes. As alterações que afetam os grupos de VM subjacentes podem afetar a duração das operações de gerenciamento, pois 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 do cluster virtual, consulte a arquitetura do cluster virtual.

Propagação

O seeding desempenha um papel crítico na operação do SQL Managed Instance do Azure, especialmente durante a configuração e a replicação de bancos de dados. A semeadura é o processo que inicializa e sincroniza dados em todos os processos do Mecanismo de Banco de Dados SQL, sendo uma parte crucial do gerenciamento de instâncias. Embora, frequentemente, 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 gerenciada de SQL que seja íntegro e funcional.

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

O processo de semeadura geralmente envolve os seguintes estágios, independentemente do nível de serviço:

  • Inicialização: o sistema identifica o banco de dados de origem e de 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: após a conclusão da transferência inicial de dados, o sistema sincroniza as atualizações ou alterações subsequentes por meio 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 roteado para o novo processo do Mecanismo de Banco de Dados SQL.

Não há propagação de dados na camada de serviço de Uso Geral , exceto quando você altera a camada de serviço para a camada de serviço Comercialmente Crítico . As operações de gerenciamento na camada de serviço de Uso Geral envolvem desanexar o armazenamento remoto do processo antigo 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 Crítico para o Negócio, projetada para cargas de trabalho de alto desempenho, requer armazenamento local e a codependência das camadas de computação e armazenamento. Consequentemente, quase todas as operações e cenários nessa camada de serviço exigem propagação para garantir a disponibilidade e a consistência dos dados.

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

  • Camadas de serviço Geral e de Próxima Geração de Uso Geral :
    • Alterando para a camada de serviço Comercialmente Crítico – os dados devem ser transferidos do armazenamento remoto para o armazenamento local usado na camada de serviço de Uso Geral.
    • Habilitar ou desabilitar a redundância de zona – os dados devem ser copiados para ou das regiões com redundância de zona.
  • Camada de serviço Comercialmente Crítico:
    • Dimensionamento do armazenamento: como o armazenamento está fisicamente anexado ao computador local, cada alteração de armazenamento requer a criação de um novo grupo de VMs, portanto, os dados devem ser transferidos do computador antigo para o novo computador (em todas as 4 réplicas).
    • Dimensionamento de vCores: cada operação de dimensionamento de computação requer a criação de um novo grupo de VMs, portanto, os dados devem ser copiados do computador antigo para o novo computador (em todas as 4 réplicas).
    • Alterando a janela de hardware ou manutenção: se já existir um grupo de VMs na sub-rede com uma configuração correspondente, esse grupo de VM será redimensionado. Se essa for uma nova configuração, um novo grupo de VM será criado. Os dados devem ser copiados do grupo de VM antigo para o novo grupo de VMs (em todas as quatro réplicas).
    • Alteração da 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.
    • Habilitar ou desabilitar a redundância de zona – os dados devem ser copiados para ou das regiões com redundância de zona.

Velocidades de propagação

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 processos do Mecanismo de Banco de Dados SQL.
  • Dependências de rede: a largura de banda e a latência de rede podem influenciar significativamente as velocidades de propagação.
  • Operações de backup e restauração: operações de backup em andamento no processo do Mecanismo de Banco de Dados SQL de origem podem influenciar a preparação de dados para enviar para 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 gravemente o processo.

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

O alto tráfego durante a propagação pode afetar a sincronização de dados, pois a propagação é projetada para empacotar e transferir todo o dado atualmente armazenado em uma única operação. As alterações de dados subsequentes no antigo processo do Mecanismo de Banco de Dados SQL que chegam após o início da propagação devem ser sincronizadas incrementalmente com o novo processo por meio da replicação de blocos do log de transações, antes que o failover possa ocorrer. Se a instância estiver sob carga pesada, a replicação poderá ter dificuldades para manter-se atualizada com os dados de entrada, 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 em um ciclo perpétuo de transferência de dados que impede a transição para o novo processo do Sistema de Gerenciamento de Banco de Dados SQL.

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

Avisos e infraestrutura do Azure

A propagação é um processo que não pode ser quantificado 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 internos do Azure e da infraestrutura, 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 no ecossistema do Azure competem por recursos disponíveis, o que leva a flutuações na disponibilidade momentânea influenciada por vários fatores. Embora a Microsoft possa fornecer um intervalo no qual a capacidade de infraestrutura opera, fazer previsões precisas é um desafio.

Failover

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 VM que abrange a instância gerenciada de SQL. O failover é uma parte crucial da maioria das operações de gerenciamento, especialmente ao atualizar uma instância. O breve momento de conexões interrompidas enquanto o tráfego é redirecionado para o novo processo do Mecanismo de Banco de Dados SQL é chamado de 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 Comercialmente Crítico , 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 de back-end que ocorrem para se preparar para failover devido a uma operação de gerenciamento, como a repropagação de bancos de dados na camada de serviço Comercialmente Crítico, ocorrem em segundo plano e não afetam a disponibilidade da sua instância.

Importante

Para operações de atualização que não são concluídas no local, mas que resultam no reanexamento do banco de dados (como dimensionamento de vCores, dimensionamento de memória, alteração de hardware ou janela de manutenção), o tempo de failover dos bancos de dados na camada de serviço Uso Geral de Próxima Geração é ajustado de acordo com o número de bancos de dados, até 10 minutos. Embora a instância fique disponível após 2 minutos, alguns bancos de dados poderão estar disponíveis após um atraso. A duração do failover é medida desde o momento em que o primeiro banco de dados fica offline até o momento em que o último banco de dados fica online. A camada de serviço uso geral de próxima geração aumenta o número máximo de bancos de dados por instância de 100 para 500.

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

Operações de gerenciamento com impacto cruzado

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

  • 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 escalonamento.

    Exemplo: Se houver uma operação de restauração de execução prolongada 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 enquanto aguarda a conclusão da operação de restauração antes que ela possa continuar.

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

    Exemplo: Se houver várias solicitações de criação e/ou escala na mesma sub-rede no mesmo grupo de VM e uma delas iniciar um redimensionamento de grupo de VM, todas as solicitações que foram enviadas mais de 1 minutos após a solicitação de operação inicial durarem mais do que o esperado, pois essas solicitações deverão aguardar a conclusão do redimensionamento antes da retomada.

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

    Exemplo: Somente 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 da redimensionamento do cluster virtual antes do início da execução.

Importante

As operações de gerenciamento que são colocadas em espera devido a outra operação em andamento são retomadas automaticamente quando as condições para prosseguir são atendidas. Nenhuma ação do usuário é necessária para retomar as operações de gerenciamento temporariamente em pausa.

Monitorar operações de gerenciamento

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

Cancelar operações de gerenciamento

Para saber como cancelar a operação de gerenciamento, consulte Canceling Azure SQL Managed Instance management operations.