Partilhar via

Fiabilidade na Instância Gerida SQL do Azure

Azure SQL Managed Instance é um motor de base de dados totalmente gerido como plataforma como serviço (PaaS). Ele fornece quase 100% compatibilidade de recursos com o SQL Server. O Azure SQL Managed Instance gere a maioria das funções de gestão de bases de dados, como atualização, patches, backups e monitorização sem envolvimento do utilizador. Corre na versão mais recente e estável do motor de base de dados SQL Server e num sistema operativo atualizado com alta disponibilidade incorporada.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer suporte à resiliência e à recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar a Azure SQL Managed Instance resiliente a uma variedade de potenciais interrupções e problemas, incluindo falhas transitórias, interrupções em zonas de disponibilidade e interrupções regionais. Descreve também como pode usar backups para recuperar de outros tipos de problemas, como gerir a manutenção de serviços e destaca algumas informações chave sobre o acordo de nível de serviço (SLA) Azure SQL Managed Instance.

Recomendações de implantação de produção para confiabilidade

Para a maioria das implantações de produção da Instância Gerenciada SQL, considere as seguintes recomendações:

Visão geral da arquitetura de confiabilidade

As instâncias gerenciadas do SQL de uso geral são executadas em um único nó gerenciado pelo Azure Service Fabric . Sempre que o mecanismo de banco de dados ou o sistema operacional é atualizado ou uma falha é detetada, a Instância Gerenciada do SQL trabalha com o Service Fabric para mover o processo do mecanismo de banco de dados sem estado para outro nó de computação sem estado que tenha capacidade livre suficiente. Os arquivos de banco de dados são armazenados no Armazenamento de Blobs do Azure, que tem recursos internos de redundância. Os arquivos de dados e de log são desanexados do nó de computação original e anexados ao processo do mecanismo de banco de dados recém-inicializado.

As instâncias gerenciadas SQL críticas para os negócios usam várias réplicas em um cluster. O cluster inclui dois tipos de réplicas:

  • Uma única réplica primária pode ser acessada para cargas de trabalho de leitura e escrita dos clientes.

  • Até cinco réplicas secundárias (computação e armazenamento) que contêm cópias de dados

A réplica primária envia contínua e sequencialmente as alterações para as réplicas secundárias, o que garante 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, uma réplica totalmente sincronizada estará sempre disponível para failover.

A instância gerenciada do SQL e o Service Fabric iniciam o failover entre réplicas. Depois que 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 para a réplica secundária legível, com base na cadeia de conexão.

Redundancy

Por padrão, a Instância Gerenciada SQL obtém redundância espalhando nós de computação e dados por um único datacenter na região primária. Essa abordagem protege seus dados durante os seguintes períodos de inatividade esperados e inesperados:

  • Operações de gerenciamento iniciadas pelo cliente que resultam em um breve tempo de inatividade

  • Operações de manutenção de serviços

  • Rede de pequena escala ou falhas de energia

  • Problemas e interrupções do datacenter que envolvem os seguintes componentes:

    • O rack onde funcionam as máquinas que alimentam o seu serviço

    • A máquina física que hospeda a máquina virtual (VM) que executa o Mecanismo de Banco de Dados SQL.

    • A VM que executa o Mecanismo de Banco de Dados SQL

  • Problemas com o Mecanismo de Banco de Dados SQL

  • Possíveis interrupções localizadas não planejadas

Para obter mais informações sobre como a Instância Gerenciada SQL fornece redundância, consulte Disponibilidade por meio de redundância local e de zona.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

A Instância Gerenciada SQL lida automaticamente com tarefas de manutenção críticas, como patches, backups e atualizações do Windows e do Mecanismo de Banco de Dados SQL. Ele também lida com eventos não planejados, como falhas subjacentes de hardware, software ou rede. A Instância Gerenciada SQL pode se recuperar rapidamente, mesmo nas circunstâncias mais críticas, o que garante que seus dados estejam sempre disponíveis. A maioria dos usuários não percebe que as atualizações são realizadas continuamente.

Quando uma instância é corrigida ou faz failover, o tempo de inatividade tem efeito mínimo se você empregar a lógica de repetição em seu aplicativo. Você pode testar a resiliência do seu aplicativo a falhas transitórias.

Resiliência a falhas na zona de disponibilidade

Observação

A redundância de zona não está atualmente disponível para a camada de serviço de uso geral de próxima geração.

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

Ao habilitar uma configuração com redundância de zona , você pode garantir que sua instância gerenciada SQL seja resiliente a um grande conjunto de falhas, incluindo interrupções catastróficas do datacenter, sem alterações na lógica do aplicativo.

A Instância Gerenciada SQL alcança redundância de zona colocando nós de computação sem estado em diferentes zonas de disponibilidade. Ele depende do ZRS com estado anexado a qualquer nó que contenha atualmente o processo ativo do Mecanismo de Banco de Dados SQL. Se ocorrer uma interrupção, o processo do Mecanismo de Base de Dados SQL torna-se ativo em um dos nós de cálculo sem estado, que acessará os dados no armazenamento com estado.

A instância SQL gerida alcança a redundância zonal colocando réplicas da sua instância SQL gerida em várias zonas de disponibilidade. Para eliminar um único ponto de falha, o anel de controle também é duplicado em várias zonas. O tráfego do plano de controle é roteado para um balanceador de carga que também é implantado em zonas de disponibilidade. O Azure Traffic Manager controla o roteamento de tráfego do plano de controle para o balanceador de carga.

Requerimentos

  • Apoio regional: A redundância de zonas para SQL Managed Instance é suportada em regiões selecionadas. Para obter mais informações, consulte Regiões suportadas.

  • Redundância de armazenamento de backup: Para ativar a redundância de zonas para a sua instância gerida por SQL, defina a redundância do armazenamento de backup para ZRS ou armazenamento redundante por zona geográfica (GZRS).

Custo

Ao ativar a redundância de zona, há um custo adicional para a sua instância SQL gerida e para os backups com redundância de zona. Para obter mais informações, veja os Preços.

Você pode economizar dinheiro comprometendo-se a usar recursos de computação com desconto por um período de tempo, o que inclui instâncias redundantes de zona na camada de serviço Crítica de Negócios. Para obter mais informações, consulte Reservas para instância gerenciada do SQL.

Configurar o suporte à zona de disponibilidade

Esta seção explica como configurar o suporte à zona de disponibilidade para suas instâncias gerenciadas SQL:

  • Habilite a redundância de zona: Para saber como configurar a redundância de zona em instâncias novas e existentes, consulte Configurar redundância de zona.

    Todas as operações de dimensionamento para Instância Gerenciada SQL, incluindo a habilitação de redundância de zona, são operações online e exigem tempo de inatividade mínimo ou nulo. Para obter mais informações, consulte Duração das operações de gerenciamento.

  • Desativar redundância de zona: Você pode desabilitar a redundância de zona seguindo as mesmas etapas para habilitar a redundância de zona. Esse processo é uma operação on-line semelhante a uma atualização regular do objetivo da camada de serviço. No final do processo, a instância é migrada da infraestrutura com redundância de zona para a infraestrutura de zona única.

Comportamento quando todas as zonas estão íntegras

Esta seção descreve o que esperar quando sua instância gerenciada SQL é configurada para ser redundante de zona e todas as zonas de disponibilidade estão operacionais:

  • Roteamento de tráfego entre zonas: Durante as operações normais, as solicitações são roteadas para o nó que executa a camada de computação da Instância Gerenciada SQL.

  • Replicação de dados entre zonas: Os arquivos de banco de dados são armazenados no Armazenamento do Azure usando o ZRS, que é anexado a qualquer nó que contenha atualmente o processo ativo do Mecanismo de Banco de Dados SQL.

    As operações de gravação são síncronas e não são consideradas completas até que os dados sejam replicados com êxito em todas as zonas de disponibilidade. Essa replicação síncrona garante forte consistência e zero perda de dados durante falhas de zona. No entanto, isso pode resultar em latência de gravação um pouco maior em comparação com o armazenamento com redundância local.

  • Roteamento de tráfego entre zonas: Durante as operações normais, as solicitações são roteadas para a réplica primária da instância gerenciada pelo SQL.

  • Replicação de dados entre zonas: A réplica primária envia contínua e sequencialmente as alterações para as réplicas secundárias em diferentes zonas de disponibilidade. Esse processo garante que os dados sejam mantidos em um número suficiente de réplicas secundárias antes de confirmar cada transação. Essas réplicas estão localizadas em diferentes zonas de disponibilidade. 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.

    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. Esse aumento pode afetar o desempenho de algumas cargas de trabalho OLTP (Online Transaction Processing). A maioria dos aplicativos não é sensível a essa latência extra.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando sua instância gerenciada SQL é configurada para ser redundante de zona e uma ou mais zonas de disponibilidade não estão disponíveis:

  • Deteção e resposta: A Instância Gerenciada SQL é responsável por detetar e responder a uma falha em uma zona de disponibilidade. Você não precisa fazer nada para iniciar um failover de zona.
  • Solicitações ativas: Quando uma zona de disponibilidade não está disponível, todas as solicitações que estão sendo processadas na zona de disponibilidade defeituosa são encerradas e devem ser repetidas. Para tornar as suas aplicações resilientes a este tipo de problemas, consulte a orientação Resiliência a falhas transitórias .

  • Reencaminhamento do tráfego: A Instância Gerenciada SQL funciona com o Service Fabric para mover o mecanismo de banco de dados para um nó de computação sem estado adequado que esteja em uma zona de disponibilidade diferente e tenha capacidade livre suficiente. Após a conclusão do failover, novas conexões são redirecionadas automaticamente para o novo nó de computação primário.

    Uma carga de trabalho pesada pode sofrer alguma degradação de desempenho durante a transição de um nó de computação para o outro nó de computação porque o novo processo do mecanismo de banco de dados começa com um cache frio.

  • Reencaminhamento do tráfego: A Instância Gerenciada do SQL funciona com o Service Fabric para selecionar uma réplica adequada em outra zona de disponibilidade para se tornar a réplica primária. Depois que 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 novas conexões são redirecionadas automaticamente para a nova réplica primária ou para a réplica secundária legível, com base na cadeia de conexão.

  • Tempo de inatividade esperado: Pode haver uma pequena quantidade de tempo de inatividade durante um failover de zona de disponibilidade. O tempo de inatividade é normalmente inferior a 30 segundos, o que a sua aplicação deverá tolerar se seguir as orientações de Resiliência a falhas transitórias .

  • Perda de dados esperada: Não há perda de dados esperada para transações confirmadas durante um failover de zona de disponibilidade. As transações em curso precisam ser tentadas novamente.

Recuperação de zona

Quando a zona de disponibilidade se recupera, a Instância Gerenciada do SQL funciona com o Service Fabric para restaurar operações na zona recuperada. Não é necessária a intervenção do cliente.

Teste de falhas de zona

A plataforma SQL Managed Instance gerencia o roteamento de tráfego, failover e failback para instâncias com redundância de zona. Como esse recurso é totalmente gerenciado, você não precisa iniciar ou validar processos de falha da zona de disponibilidade. No entanto, você pode validar o tratamento de falhas do seu aplicativo.

Resiliência a falhas em toda a região

Uma Instância Gerenciada SQL individual é implantada em uma única região. No entanto, você pode implantar uma instância gerenciada SQL secundária em uma região separada do Azure e configurar um grupo de failover.

Grupos de tolerância a falhas

Os grupos de failover replicam automaticamente geograficamente seus dados e podem fazer failover automática ou manualmente se ocorrer uma falha regional, com base na política de failover.

Esta seção resume as principais informações sobre grupos de failover, mas é importante revisar a visão geral e as práticas recomendadas dos grupos de failover para saber mais sobre como eles funcionam e como configurá-los.

Políticas de failover

Ao criar um grupo de failover, você seleciona a política de failover, que especifica quem é responsável por detetar uma interrupção e executar um failover. Você pode configurar dois tipos de políticas de failover:

  • Failover gerenciado pelo cliente (recomendado): Ao usar uma política de failover gerenciada pelo cliente, você pode decidir se deseja executar um failover, que não incorre em perda de dados, ou um failover forçado, que pode incorrer em perda de dados. O failover forçado é usado como um método de recuperação durante interrupções quando a instância principal não pode ser acessada.

  • Failover gerenciado pela Microsoft: O failover gerenciado pela Microsoft só é usado em situações excecionais para acionar um failover forçado.

Importante

Use opções de failover gerenciadas pelo cliente para desenvolver, testar e implementar seus planos de DR. Não confie no failover gerenciado pela Microsoft, que só pode ser usado em circunstâncias extremas. Um failover gerenciado pela Microsoft será provavelmente iniciado para uma região inteira. Ele não pode ser iniciado para grupos de failover individuais, instâncias gerenciadas pelo SQL, assinaturas ou clientes. O failover pode ocorrer em momentos diferentes para diferentes serviços do Azure. Recomendamos a utilização de failover gerido pelo cliente.

Suporte de região

Você pode selecionar qualquer região do Azure para as instâncias gerenciadas do SQL dentro do grupo de failover. Devido à alta latência das redes de longa distância, a replicação geográfica usa um mecanismo de replicação assíncrona. Para reduzir os atrasos da rede, selecione regiões com conexões de baixa latência. Para obter mais informações sobre latência entre regiões do Azure, consulte Estatísticas de latência de ida e volta da rede do Azure.

Custo

Quando você cria várias instâncias gerenciadas pelo SQL em regiões diferentes, você é cobrado por cada instância gerenciada pelo SQL.

No entanto, se sua instância secundária não tiver nenhuma carga de trabalho de leitura ou aplicativos conectados a ela, você poderá economizar nos custos de licenciamento designando a réplica como uma instância em espera. Para obter mais informações, consulte Configurar uma réplica de espera sem necessidade de licença para instância SQL gerida.

Para obter mais informações sobre os preços da Instância Gerenciada SQL, consulte Informações sobre preços de serviço.

Configurar suporte a várias regiões

Para saber como configurar um grupo de failover, consulte Configurar um grupo de failover para instância gerenciada do SQL.

Planejamento e gerenciamento de capacidade

Durante um failover, o tráfego é redirecionado para uma instância secundária gerenciada pelo SQL. É importante que sua instância gerenciada SQL secundária esteja pronta para receber tráfego. Crie uma instância secundária gerenciada pelo SQL com a mesma camada de serviço, geração de hardware e tamanho de computação que a instância principal.

Para obter mais informações sobre como dimensionar instâncias gerenciadas SQL em um grupo de failover, consulte Dimensionar instâncias.

Comportamento quando todas as regiões estão saudáveis

Esta seção descreve o que esperar quando instâncias gerenciadas pelo SQL são configuradas para usar grupos de failover de várias regiões e todas as regiões estão operacionais:

  • Roteamento de tráfego entre regiões: Durante as operações normais, as solicitações de leitura-gravação vão para a única instância primária na região primária.

    Os grupos de failover também fornecem um ponto de extremidade de ouvinte somente leitura separado. Durante operações normais, esse ponto de extremidade se conecta à instância secundária para rotear o tráfego somente leitura especificado na cadeia de conexão.

    Para obter mais informações sobre como os grupos de failover enviam tráfego para cada instância e como você pode direcionar o tráfego para um ponto de extremidade de ouvinte somente leitura, consulte Visão geral e práticas recomendadas de grupos de failover.

  • Replicação de dados entre regiões: Por padrão, os dados são replicados de forma assíncrona da instância primária para a instância gerenciada SQL secundária.

    Como a replicação geográfica é assíncrona, se você executar um failover forçado, é possível ocorrer perda de dados. Você pode monitorar o atraso de replicação para entender a possível perda de dados durante um failover forçado. Para obter mais informações, consulte Lista de verificação de DR.

    Se você precisar eliminar a perda de dados da replicação assíncrona durante failovers, configure seu aplicativo para bloquear o thread de chamada até confirmar que a última transação confirmada foi transmitida e protegida no log de transações do banco de dados secundário. Essa abordagem requer desenvolvimento personalizado e degrada o desempenho do seu aplicativo. Para obter mais informações, consulte Evitar a perda de dados críticos.

Comportamento durante uma interrupção regional

Esta seção descreve o que esperar quando instâncias gerenciadas pelo SQL são configuradas para usar grupos de failover de várias regiões e há uma interrupção na região primária:

  • Deteção e resposta: A responsabilidade pela deteção e resposta depende da política de failover usada pelo grupo de failover.

    • Política de failover gerenciada pelo cliente: Você é responsável por detetar a falha em uma região e acionar um failover ou failover forçado para a instância secundária no grupo de failover.

      Se você executar um failover, a Instância Gerenciada do SQL aguardará a sincronização dos dados com a instância secundária antes de executar o procedimento de failover.

      Se executar um failover forçado, a Instância Gerenciada do SQL trocará imediatamente a instância secundária para o papel principal, sem esperar que as alterações recentes se propaguem da instância primária. Esse tipo de failover pode incorrer em perda de dados.

    • Política de failover gerenciada pela Microsoft: Os failovers gerenciados pela Microsoft são executados em circunstâncias excecionais. Quando a Microsoft aciona um failover, o grupo de failover executa automaticamente um failover forçado para a instância secundária no grupo de failover. No entanto, recomendamos o uso de uma política de failover gerenciada pelo cliente para cargas de trabalho de produção para que você possa controlar quando o failover ocorre.

  • Solicitações ativas: Quando ocorre um failover, todas as solicitações que estão sendo processadas são encerradas e devem ser repetidas. Para tornar as suas aplicações resilientes a este tipo de problemas, veja Resiliência a falhas transitórias.

  • Perda de dados esperada: A quantidade de perda de dados depende de como você configura seu aplicativo. Para obter mais informações, consulte Visão geral e práticas recomendadas de grupos de failover.

  • Tempo de inatividade previsto: Pode haver um breve período de inatividade durante o processo de transição do grupo de failover. O tempo de inatividade é normalmente inferior a 60 segundos.

  • Reencaminhamento do tráfego: Depois que o grupo de failover conclui o processo de failover, o tráfego de leitura-gravação é roteado para a nova instância primária automaticamente. Se seus aplicativos usarem os pontos de extremidade do grupo de failover em suas cadeias de conexão, eles não precisarão modificar suas cadeias de conexão após o failover.

Recuperação da região

Os grupos de failover não retornam automaticamente para a região principal quando ela é restaurada e, portanto, é sua responsabilidade iniciar um failback.

Teste para falhas regionais

Você pode testar o failover de um grupo de failover.

O teste de um grupo de failover é apenas uma parte da execução de um drill de DR. Para obter mais informações, consulte Executar exercícios de DR.

Backup e restauração

Faça backups de seus bancos de dados para se proteger contra vários riscos, incluindo perda de dados. Os backups podem ser restaurados para recuperar de perda acidental de dados, corrupção ou outros problemas. Os backups não são a mesma coisa que a replicação geográfica, têm finalidades diferentes e mitigam riscos diferentes.

A Instância Gerenciada SQL faz automaticamente backups completos, diferenciais e de log de transações de seus bancos de dados. Para obter mais informações sobre os tipos de backups, sua frequência, recursos de restauração, custos de armazenamento e criptografia de backup, consulte Backups automatizados na instância gerenciada SQL.

A Instância Gerenciada SQL fornece backups automatizados internos e também oferece suporte a backups somente cópia iniciados pelo usuário para bancos de dados de usuários. Para obter mais informações, consulte Backups somente cópia.

Replicação de backup

Ao configurar backups automatizados para sua instância gerenciada pelo SQL, você pode especificar como os backups devem ser replicados. Os backups configurados para serem armazenados no ZRS têm um nível mais alto de resiliência. Recomendamos que você configure seus backups para usar um dos seguintes tipos de armazenamento:

  • ZRS para resiliência dentro da região, se a região tiver zonas de disponibilidade

  • GZRS para melhorar a resiliência de seus backups entre regiões se a região tiver zonas de disponibilidade e estiver emparelhada com outra região

  • GRS se a sua região não suporta zonas de disponibilidade, mas tem uma região emparelhada

Para obter mais informações sobre diferentes tipos de armazenamento e seus recursos, consulte Redundância de armazenamento de backup.

Restauro geográfico

O recurso de restauração geográfica é uma solução básica de DR que permite restaurar cópias de backup para uma região diferente do Azure. O backup geográfico normalmente requer uma quantidade significativa de tempo de inatividade e perda de dados. Para alcançar níveis mais altos de capacidade de recuperação se ocorrer uma interrupção regional, você deve configurar grupos de failover.

Se você usa a restauração geográfica, precisa considerar como disponibilizar seus backups na região secundária:

  • Se a região principal estiver emparelhada, use o armazenamento de backup GZRS ou GRS para oferecer suporte à restauração geográfica para a região emparelhada.

  • Se sua região principal não estiver emparelhada, você poderá criar uma solução personalizada para replicar seus backups para outra região. Considere usar backups somente cópia iniciados pelo usuário e armazená-los em uma conta de armazenamento que use replicação de objeto blob para replicar para uma conta de armazenamento em outra região.

Resiliência à manutenção de serviços

Quando a Instância Gerenciada SQL executa manutenção em sua instância, a instância gerenciada SQL permanece totalmente disponível, mas pode estar sujeita a breves reconfigurações. Os aplicativos cliente podem observar breves interrupções de conectividade quando ocorre um evento de manutenção. As suas aplicações clientes devem seguir a orientação Resiliência a falhas transitórias para minimizar os efeitos.

A Instância Gerenciada SQL permite especificar uma janela de manutenção que geralmente é usada para atualizações de serviço e outras operações de manutenção. Configurar uma janela de manutenção pode ajudá-lo a minimizar quaisquer efeitos secundários, como failovers automáticos, durante o horário comercial. Você também pode receber uma notificação antecipada da manutenção planejada.

Para obter mais informações, consulte Janela de Manutenção na Instância Gerida do SQL.

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte Acordos de Nível de Serviço (SLAs) para serviços online.

Para a Instância Gerenciada do SQL, o SLA de disponibilidade só se aplica quando sua rede virtual do Azure está configurada corretamente para não impedir o tráfego de gerenciamento. Essa configuração inclui tamanho de sub-rede, NSGs (grupos de segurança de rede), rotas definidas pelo usuário (UDRs), configuração de DNS e outros recursos que afetam o gerenciamento e o uso de recursos de rede. Para obter mais informações sobre a configuração de rede necessária para a Instância Gerenciada SQL, consulte Requisitos de rede.

Conteúdo relacionado

  • Last updated on