Partilhar via

Fiabilidade no Azure SQL Managed Instance

Azure SQL Managed Instance é um motor de base de dados totalmente gerido como plataforma como serviço (PaaS). Oferece quase 100% de compatibilidade de funcionalidades com 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. Funciona 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 se usa Azure, fiabilidade é uma responsabilidade partilhada. 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 o Azure SQL Managed Instance resiliente a uma variedade de potenciais falhas 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 implementações em produção do SQL Managed Instance, considere as seguintes recomendações:

  • Siga as orientações fornecidas na lista de verificação de alta disponibilidade e recuperação de desastres (DR).
  • Habilite a redundância de zona.
  • Configure backups automatizados e use o armazenamento com redundância de zona (ZRS) ou o armazenamento com redundância geográfica (GRS) para backups.
  • Planeje testar regularmente seus backups e processos de restauração.

Visão geral da arquitetura de confiabilidade

As instâncias de SQL geridas de uso geral correm num único nó que é gerido pelo Azure Service Fabric. Sempre que o motor da base de dados ou o sistema operativo são atualizados, ou é detetada uma falha, a SQL Managed Instance trabalha com o Service Fabric para mover o processo do motor de base de dados sem estado para outro nó de computação sem estado que tenha capacidade livre suficiente. Os ficheiros da base de dados são armazenados no Armazenamento de Blobs do Azure, que tem funcionalidades de redundância incorporadas. 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 SQL empresariais críticas geridas 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.

SQL Managed Instance e Service Fabric iniciam o *failover* entre as 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 ligações SQL do Azure são automaticamente redirecionadas para a nova réplica primária ou para a réplica secundária disponível para leitura, conforme a cadeia de ligação.

Redundancy

Por padrão, o SQL Managed Instance garante a redundância ao espalhar nós de computação e dados por um único centro de dados na região principal. 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 aloja a máquina virtual (VM) que executa a Database Engine SQL.

    • A VM que executa o Motor de Base de Dados SQL

  • Problemas com o SQL Database Engine

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

Para mais informações sobre como SQL Managed Instance proporciona redundância, consulte Disponibilidade através 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.

Todas as aplicações alojadas na cloud devem seguir as orientações de tratamento de falhas transitórias do Azure quando comunicarem com quaisquer APIs, bases de dados e outros componentes alojados na cloud. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

O SQL Managed Instance trata automaticamente de tarefas críticas de manutenção, como patches, backups e atualizações do Windows e SQL Database Engine. Ele também lida com eventos não planejados, como falhas subjacentes de hardware, software ou rede. O SQL Managed Instance pode recuperar rapidamente mesmo nas circunstâncias mais críticas, garantindo que os seus dados estão 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.

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.

O SQL Managed Instance alcança redundância de zonas ao colocar nós de computação sem estado em diferentes zonas de disponibilidade. Baseia-se num ZRS com estado que está ligado ao nó que atualmente contém o processo ativo do SQL Database Engine. Se ocorrer uma falha, o processo SQL Database Engine torna-se ativo num dos nós de computação sem estado, que então acede aos dados no armazenamento com estado.

O SQL Managed Instance alcança redundância de zonas ao colocar réplicas da sua SQL managed instance em múltiplas 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. Gestor de Tráfego do Azure controla o encaminhamento do tráfego do plano de controlo para o balanceador de carga.

Requerimentos

  • Suporte à região: 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, incluindo instâncias com redundância de zona na camada de serviço Business Critical. Para mais informações, consulte Reservas para SQL Managed Instance.

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 escalabilidade para SQL Managed Instance, incluindo ativar a redundância de zonas, são operações online e requerem pouco ou nenhum tempo de inatividade. 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:

  • Encaminhamento de tráfego entre zonas: Durante as operações normais, os pedidos são encaminhados para o nó que executa a sua camada de computação SQL Managed Instance.

  • Replicação de dados entre zonas: Os ficheiros da base de dados são armazenados no Armazenamento do Azure usando o ZRS, que está ligado ao nó que atualmente contém o Mecanismo de Base de Dados SQL ativo.

    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. Este processo garante que, caso a réplica primária ou uma réplica secundária legível se torne indisponível por qualquer motivo, uma réplica totalmente sincronizada esteja 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: SQL Managed Instance é responsável por detetar e responder a uma falha numa zona de disponibilidade. Você não precisa fazer nada para iniciar um failover de zona.
  • Notificação: a Microsoft não o notifica automaticamente quando uma zona está inativa. No entanto, pode usar Azure Resource Health para monitorizar a saúde de um recurso individual, e pode configurar alertas Resource Health para o notificar de problemas. Também pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Saúde do Serviço para o notificar de problemas.
  • 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 .

  • Redirecionamento de tráfego: SQL Managed Instance trabalha com o Service Fabric para mover o motor da base de dados para um nó de computação sem estado adequado, que está numa zona de disponibilidade diferente e tem 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.

  • Redirecionamento de tráfego: SQL Managed Instance trabalha com o Service Fabric para selecionar uma réplica adequada noutra zona de disponibilidade que se torne a réplica principal. 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 ligações são automaticamente redirecionadas para a nova réplica primária, ou para a réplica secundária legível, com base na cadeia de ligaçã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 recupera, a SQL Managed Instance trabalha com o Service Fabric para restaurar as operações na zona recuperada. Não é necessária a intervenção do cliente.

Teste de falhas de zona

A plataforma SQL Managed Instance gere o encaminhamento de tráfego, falha e recuperação 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 SQL Managed Instance individual é implementada numa única região. No entanto, pode implementar uma instância SQL gerida secundária numa região Azure separada e configurar um grupo 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 contingência (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 Azure. Recomendamos a utilização de failover gerido pelo cliente.

Requerimentos

  • Suporte de região: Pode selecionar qualquer região do Azure para as instâncias SQL geridas 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 mais informações sobre latência entre regiões do Azure, consulte estatísticas de latência da rede do Azure de ida e volta.

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 mais informações, consulte Configurar uma réplica em espera sem licença para SQL Managed Instance.

Para mais informações sobre preços SQL Managed Instance, consulte Informações de preços de serviços.

Configurar suporte a várias regiões

Para aprender a configurar um grupo de failover, consulte Configure um grupo de failover para SQL Managed Instance.

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, este endpoint liga-se à instância secundária para encaminhar o tráfego de apenas leitura especificado na cadeia de ligaçã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 realizar um failover, a SQL Managed Instance espera que os dados sincronizem com a instância secundária antes de realizar o procedimento de failover.

      Se realizar um failover forçado, o SQL Managed Instance muda imediatamente a instância secundária para o papel principal sem esperar que as alterações recentes se propaguem a partir do principal. 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.

  • Notificação: a Microsoft não o notifica automaticamente quando uma zona está inativa. No entanto, pode usar Azure Resource Health para monitorizar a saúde de um recurso individual, e pode configurar alertas Resource Health para o notificar de problemas. Também pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Saúde do Serviço para o notificar de problemas.

  • 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 os seus aplicativos utilizarem os terminais de grupo de failover nas suas cadeias de conexão, não precisarão modificar essas cadeias após o failover.

Recuperação da região

Os grupos de failover não retornam automaticamente à região principal quando esta é restaurada, sendo, por isso, da sua responsabilidade iniciar o failback.

Para grupos de failover geridos pelo cliente, pode iniciar um failback para a região principal assim que esta for restaurada. Para grupos de failover geridos pela Microsoft, o processo de failback é automático. Para mais informações, veja Failback para a região primária.

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.

O SQL Managed Instance faz automaticamente backups completos, diferenciais e de registos de transações das suas bases de dados. Para mais informações sobre os tipos de backups, a sua frequência, capacidades de restauro, custos de armazenamento e encriptação de backup, consulte Backups automatizados em SQL Managed Instance.

O SQL Managed Instance fornece backups automatizados incorporados e também suporta backups iniciados pelo utilizador, apenas com cópia, para bases de dados de utilizadores. Para obter mais informações, consulte Backups apenas de 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.

Restauração Geográfica

A capacidade de restauração geográfica é uma solução básica de DR que permite restaurar cópias de segurança para uma região Azure diferente. 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 iniciados pelo usuário e somente de cópia, e armazená-los numa conta de armazenamento que utilize replicação de objeto blob para replicar para uma conta de armazenamento noutra região.

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

Quando a SQL Managed Instance realiza manutenção na sua instância, a SQL managed instance permanece totalmente disponível, mas pode ser sujeita a pequenas 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.

O SQL Managed Instance permite-lhe especificar uma janela de manutenção 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 mais informações, consulte Janela de manutenção em SQL Managed Instance.

Contrato de nível de serviço

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

Para SQL Managed Instance, o SLA de disponibilidade só se aplica quando a sua rede virtual do Azure está corretamente configurada para não impedir o tráfego de gestão. 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 mais informações sobre a configuração de rede necessária para SQL Managed Instance, consulte requisitos de rede.

Conteúdo relacionado

  • Last updated on