Alta disponibilidade para o Banco de Dados SQL do Azure

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure

Este artigo descreve a arquitetura de alta disponibilidade no Banco de Dados SQL do Azure.

Descrição geral

O objetivo da arquitetura de alta disponibilidade no Banco de Dados SQL do Azure é minimizar o impacto nas cargas de trabalho do cliente de operações de manutenção de serviço e interrupções. Para obter informações sobre SLAs específicos para diferentes camadas de serviço, consulte SLA para o Banco de Dados SQL do Azure.

O Banco de Dados SQL é executado 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. O Banco de dados SQL lida automaticamente com tarefas de manutenção críticas, como patches, backups, atualizações do Windows e do mecanismo SQL e eventos não planejados, como falhas subjacentes de hardware, software ou rede. Quando um banco de dados ou pool elástico no Banco de dados SQL é corrigido ou faz failover, o tempo de inatividade não é impactante se você empregar a lógica de repetição em seu aplicativo. O Banco de dados SQL pode se recuperar rapidamente, mesmo nas circunstâncias mais críticas, garantindo que seus 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 comprometidos nunca sejam perdidos devido a falhas, que as operações de manutenção não afetem sua carga de trabalho e que o banco de dados não seja um único ponto de falha em sua arquitetura de software.

Existem três modelos arquitetónicos de alta disponibilidade:

  • Modelo de armazenamento remoto baseado em uma separação de computação e armazenamento. Ele depende da alta disponibilidade e confiabilidade do nível de armazenamento remoto. Esta arquitetura visa aplicações empresariais orientadas para o orçamento que podem tolerar alguma degradação do desempenho durante as atividades de manutenção.
  • Modelo de armazenamento local baseado em um cluster de processos do mecanismo de banco de dados. Baseia-se no facto de existir sempre um quórum de nós de motores de base de dados disponíveis. Essa arquitetura tem como alvo aplicativos de missão crítica com alto desempenho de E/S, alta taxa de transação e garante um impacto mínimo no desempenho de sua carga de trabalho durante as atividades de manutenção.
  • Modelo de hiperescala que usa um sistema distribuído de componentes altamente disponíveis, como nós de computação, servidores de página, serviço de log e armazenamento persistente. Cada componente que suporta um banco de dados Hyperscale fornece sua própria redundância e resiliência a falhas. Os nós de computação, os servidores de página e o serviço de log são executados no Azure Service Fabric, que controla a integridade de cada componente e executa failovers para nós íntegros disponíveis conforme necessário. O armazenamento persistente usa o Armazenamento do Azure com seus recursos nativos de alta disponibilidade e redundância. Para saber mais, consulte Arquitetura de hiperescala.

Em cada um dos três modelos de disponibilidade, o Banco de dados SQL oferece suporte a opções de redundância local e zonal. A redundância local fornece resiliência dentro de um datacenter, enquanto a redundância zonal melhora ainda mais a resiliência, protegendo contra interrupções de uma zona de disponibilidade dentro de uma região.

A tabela a seguir mostra as opções de disponibilidade com base nas camadas de serviço:

Escalão de serviço Modelo de alta disponibilidade disponibilidade localmente redundante Disponibilidade com redundância de zona
Uso geral (vCore) Armazenamento remoto Sim Sim
Crítica de negócios (vCore) Armazenamento local Sim Sim
Hiperescala (vCore) Hyperscale Sim Sim
Básico (DTU) Armazenamento remoto Sim No
Padrão (DTU) Armazenamento remoto Sim No
Premium (DTU) Armazenamento local Sim Sim

Disponibilidade localmente redundante

A disponibilidade com redundância local baseia-se no armazenamento do banco de dados no LRS (armazenamento com redundância local), que copia os dados três vezes em um único datacenter na região principal e protege os dados em caso de falha local, como uma rede de pequena escala ou falha de energia. O LRS é a opção de redundância de menor custo e oferece a menor durabilidade em comparação com outras opções. Se ocorrer um desastre de grande escala, como incêndio ou inundação, em uma região, todas as réplicas de uma conta de armazenamento usando o LRS podem ser perdidas ou irrecuperáveis. Como tal, para proteger ainda mais seus dados ao usar a opção de disponibilidade localmente redundante, considere o uso de uma opção de armazenamento mais resiliente para seus backups de banco de dados. Isso não se aplica a bancos de dados Hyperscale, onde o mesmo armazenamento é usado para arquivos de dados e backups.

A disponibilidade localmente redundante está disponível para todos os bancos de dados em todas as camadas de serviço e RPO (Recovery Point Objetive, objetivo de ponto de recuperação), que indica que a quantidade de perda de dados é zero.

Níveis de serviço básicos, padrão e de uso geral

As camadas de serviço Basic, Standard e General Purpose usam o modelo de disponibilidade de armazenamento remoto para computação sem servidor e provisionada. A seguinte figura mostra quatro nós diferentes com as camadas de computação e de armazenamento separadas.

Diagram showing separation of compute and storage.

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 armazenados em cache, como os tempdb bancos de dados e no SSD anexado, e planeja cache, pool de buffers e model pool columnstore na memória. Esse nó sem estado é operado pelo Azure Service Fabric que inicializa o mecanismo de banco de dados, controla a integridade do nó e executa failover para outro nó, se necessário.
  • Uma camada de dados com estado com os arquivos de banco de dados (.mdf e .ldf) armazenados no Armazenamento de Blob do Azure. O Armazenamento de Blobs do Azure tem recursos internos de disponibilidade e redundância de dados. Ele garante que todos os registros no arquivo de log ou página no 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 detetada, 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 Blob do Azure não são afetados pela mudança e os arquivos de dados/log são anexados ao processo do mecanismo de banco de dados recém-inicializado. Esse processo garante alta disponibilidade, mas uma carga de trabalho pesada pode sofrer alguma degradação de desempenho durante a transição, uma vez que o novo processo do mecanismo de banco de dados começa com cache frio.

Nível de serviço Premium e Crítico para os Negócios

As camadas de serviço Premium e Business Critical usam o modelo de disponibilidade de armazenamento local, que integra recursos de computação (processo do mecanismo de banco de dados) e armazenamento (SSD conectado localmente) em um único nó. A alta disponibilidade é obtida replicando a computação e o armazenamento para nós adicionais.

Diagram of a cluster of database engine nodes.

Os arquivos de banco de dados subjacentes (.mdf/.ldf) são colocados no armazenamento SSD conectado para fornecer E/S de latência muito baixa à sua carga de trabalho. A alta disponibilidade é implementada usando uma tecnologia semelhante aos grupos de disponibilidade Always On do SQL Server. O cluster inclui uma única réplica primária acessível para cargas de trabalho de clientes de leitura-gravação e até três réplicas secundárias (computação e armazenamento) contendo cópias de dados. A réplica primária envia constantemente as alterações para as réplicas secundárias em ordem e 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 falhar por qualquer motivo, sempre haverá uma réplica totalmente sincronizada para fazer failover. O failover é iniciado pelo Azure Service Fabric. Quando 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. Quando um failover é concluído, as conexões SQL do Azure são redirecionadas automaticamente para a nova réplica primária ou réplica secundária legível.

Como um benefício extra, o modelo de disponibilidade de 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 100% de capacidade de computação adicional sem custo adicional para descarregar operações somente leitura, como cargas de trabalho analíticas, da réplica principal.

Camada de serviços do Hyperscale

A arquitetura da camada de serviço Hyperscale é descrita em Arquitetura de funções distribuídas.

Diagram showing Hyperscale functional architecture.

O modelo de disponibilidade no Hyperscale inclui quatro camadas:

  • Uma camada de computação sem estado que executa os processos do mecanismo de banco de dados e contém apenas dados transitórios e armazenados em cache, como cache RBPEX não cobrindo e model bancos de dados, etc. no SSD conectado, e cache tempdb de plano, pool de buffer e pool columnstore na memória. Essa camada sem estado inclui a réplica de computação primária e, opcionalmente, várias réplicas de computação secundárias, que podem servir como destinos de failover.
  • Uma camada de armazenamento sem estado formada por servidores de página. Essa camada é o mecanismo de armazenamento distribuído para os processos do mecanismo de banco de dados em execução nas réplicas de computação. Cada servidor de página contém apenas dados transitórios e armazenados em cache, como cobrir o cache RBPEX no SSD conectado e páginas de dados armazenadas em cache na memória. Cada servidor de página tem um servidor de página emparelhado em uma configuração ativo-ativo para fornecer balanceamento de carga, redundância e alta disponibilidade.
  • Uma camada de armazenamento de log de transações com monitoração de estado formada pelo nó de computação que executa o processo do serviço Log, a zona de aterrissagem do log de transações e o armazenamento de longo prazo do log de transações. A zona de aterrissagem e o armazenamento de longo prazo usam o Armazenamento do Azure, que fornece disponibilidade e redundância para o log de transações, garantindo a durabilidade dos dados para transações confirmadas.
  • Uma camada de armazenamento de dados com monitoração de estado com os arquivos de banco de dados (.mdf/.ndf) armazenados no Armazenamento do Azure e atualizados pelos servidores de página. Essa camada usa recursos de disponibilidade e redundância de dados do Armazenamento do Azure. Ele garante que todas as páginas de um arquivo de dados serão preservadas mesmo se os processos em outras camadas da arquitetura Hyperscale falharem ou se os nós de computação falharem.

Os nós de computação em todas as camadas de Hiperescala são executados no Azure Service Fabric, que controla a integridade de cada nó e executa failovers para nós íntegros disponíveis conforme necessário.

Para obter mais informações sobre alta disponibilidade no Hyperscale, consulte Database High Availability in Hyperscale.

Disponibilidade com redundância de zona

A disponibilidade com redundância de zona baseia-se no armazenamento do banco de dados no ZRS (armazenamento com redundância de zona), que copia os dados em três zonas de disponibilidade do Azure na região primária. Cada zona de disponibilidade é uma localização física separada com energia, refrigeração e rede independentes,

A disponibilidade com redundância de zona está disponível para bancos de dados nas camadas de serviço de uso geral, premium, crítica para negócios e hiperescala do modelo de compra vCore, e não para as camadas de serviço Basic e Standard do modelo de compra baseado em DTU. A disponibilidade com redundância de zona garante o RPO (Recovery Point Objetive, objetivo de ponto de recuperação), que indica que a quantidade de perda de dados é zero.

Nível de serviço de uso geral

A configuração com redundância de zona para a camada de serviço de uso geral é oferecida para computação sem servidor e provisionada para bancos de dados no modelo de compra vCore. Essa configuração utiliza as Zonas de Disponibilidade do Azure para replicar bancos de dados em vários locais físicos dentro de uma região do Azure. Ao selecionar redundância de zona, você pode tornar seus bancos de dados únicos e pools elásticos novos e existentes sem servidor e provisionados para fins gerais resilientes a um conjunto muito maior de falhas, incluindo interrupções catastróficas do datacenter, sem alterações na lógica do aplicativo.

A configuração com redundância de zona para a camada de uso geral tem duas camadas:

  • Uma camada de dados com estado com os arquivos de banco de dados (.mdf/.ldf) armazenados no ZRS (armazenamento com redundância de zona). Usando o ZRS , os dados e os arquivos de log são copiados de forma síncrona em três zonas de disponibilidade do Azure fisicamente isoladas.
  • Uma camada de computação sem estado que executa o processo de sqlservr.exe e contém apenas dados transitórios e armazenados em cache, como os tempdb bancos de dados e no SSD conectado, e planeja cache, pool de buffers e model pool columnstore na memória. Esse nó sem estado é operado pelo Azure Service Fabric que inicializa sqlservr.exe, controla a integridade do nó e executa failover para outro nó, se necessário. Para bancos de dados de uso geral provisionados e sem servidor com redundância de zona, os nós com capacidade ociosa estão prontamente disponíveis em outras zonas de disponibilidade para failover.

A versão com redundância de zona da arquitetura de alta disponibilidade para a camada de serviço de uso geral é ilustrada pelo diagrama a seguir:

Diagram of Zone redundant configuration for General Purpose.

Considere o seguinte ao configurar seus bancos de dados de uso geral com redundância de zona:

  • Para a camada de uso geral, a configuração com redundância de zona está geralmente disponível nas seguintes regiões:
    • (África) África do Sul Norte
    • (Ásia-Pacífico) Leste da Austrália
    • (Ásia-Pacífico) Ásia Oriental
    • Leste do Japão (Ásia-Pacífico)
    • (Ásia-Pacífico) Coreia Central
    • (Ásia-Pacífico) Sudeste Asiático
    • (Ásia-Pacífico) Índia Central
    • (Ásia-Pacífico) China Norte 3
    • (Ásia-Pacífico) Norte dos Emirados Árabes Unidos
    • (Europa) França Central
    • (Europa) Alemanha Centro-Oeste
    • (Europa) Itália Norte
    • (Europa) Europa do Norte
    • (Europa) Leste da Noruega
    • (Europa) Polónia Central
    • (Europa) Europa Ocidental
    • (Europa) Sul do Reino Unido
    • (Europa) Suíça Norte
    • (Europa) Suécia Central
    • (Médio Oriente) Israel Central
    • (Médio Oriente) Catar Central
    • (América do Norte) Canadá Central
    • (América do Norte) Leste dos EUA
    • (América do Norte) Leste dos EUA 2
    • (América do Norte) Centro-Sul dos EUA
    • (América do Norte) Oeste dos EUA 2
    • (América do Norte) Oeste dos EUA 3
    • (América do Sul) Brasil Sul
  • Para disponibilidade redundante de zona, escolher uma janela de manutenção diferente da padrão está atualmente disponível em regiões selecionadas.
  • A configuração com redundância de zona só está disponível no Banco de dados SQL quando o hardware da série padrão (Gen5) é selecionado.
  • A redundância de zona não está disponível para as camadas de serviço Básico e Standard no modelo de compra de DTU.

Níveis de serviço Premium e Business Critical

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, o Banco de Dados SQL pode colocar diferentes réplicas de um banco de dados Premium ou Business Critical em diferentes zonas de disponibilidade na mesma região. Para eliminar um único ponto de falha, o anel de controle também é duplicado em várias zonas como três anéis de gateway (GW). O roteamento para um anel de gateway específico é controlado pelo Gerenciador de Tráfego do Azure. Como a configuração com redundância de zona nas camadas de serviço Premium ou Business Critical não cria redundância de banco de dados adicional, você pode habilitá-la sem custo extra. Ao selecionar uma configuração com redundância de zona, você pode tornar seus bancos de dados Premium ou Business Critical e pools elásticos resilientes a um conjunto muito maior de falhas, incluindo interrupções catastróficas do datacenter, sem alterações na lógica do aplicativo. Você também pode converter qualquer banco de dados Premium ou Business Critical existente ou pools elásticos em configuração com redundância de zona.

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

Diagram of the zone-redundant high availability architecture.

Considere o seguinte ao configurar seus bancos de dados Premium ou Business Critical com redundância de zona:

  • Para obter informações atualizadas sobre as regiões que oferecem suporte a bancos de dados com redundância de zona, consulte Suporte de serviços por região.
  • Para disponibilidade redundante de zona, escolher uma janela de manutenção diferente da padrão está atualmente disponível em regiões selecionadas.

Camada de serviços do Hyperscale

É possível configurar redundância de zona para bancos de dados na camada de serviço Hyperscale. Para saber mais, consulte Criar banco de dados Hyperscale com redundância de zona.

A habilitação dessa configuração garante resiliência no nível da zona por meio da replicação entre zonas de disponibilidade para todas as camadas de hiperescala. Ao selecionar redundância de zona, você pode tornar seus bancos de dados Hyperscale resilientes a um conjunto muito maior de falhas, incluindo interrupções catastróficas do datacenter, sem alterações na lógica do aplicativo. Todas as regiões do Azure que têm Zonas de Disponibilidade dão suporte ao banco de dados Hyperscale redundante de zona.

O diagrama a seguir demonstra a arquitetura subjacente para bancos de dados Hyperscale redundantes de zona:

Diagram showing the underlying architecture of zone redundant Hyperscale databases.

Considere as seguintes limitações:

  • A configuração redundante de zona só pode ser especificada durante a criação do banco de dados. Essa configuração não pode ser modificada depois que o recurso é provisionado. Use cópia de banco de dados, restauração point-in-time ou crie uma réplica geográfica para atualizar a configuração redundante de zona para um banco de dados Hyperscale existente. Ao usar uma dessas opções de atualização, se o banco de dados de destino estiver em uma região diferente da origem ou se a redundância de armazenamento de backup do banco de dados do destino for diferente do banco de dados de origem, a operação de cópia será um tamanho de operação de dados.

  • Para disponibilidade redundante de zona, escolher uma janela de manutenção diferente da padrão está atualmente disponível em regiões selecionadas.

  • Atualmente, não há suporte para réplicas nomeadas.

  • Atualmente, não há nenhuma opção para especificar redundância de zona ao migrar um banco de dados para o Hyperscale usando o portal do Azure. No entanto, a redundância de zona pode ser especificada usando o Azure PowerShell, a CLI do Azure ou a API REST ao migrar um banco de dados existente de outra camada de serviço do Banco de Dados SQL do Azure para o Hyperscale. Aqui está um exemplo com a CLI do Azure:

    az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true

  • Pelo menos 1 réplica de computação de alta disponibilidade e o uso de armazenamento de backup com redundância de zona ou geozona são necessários para habilitar a configuração redundante de zona para Hyperscale.

Disponibilidade redundante da zona do banco de dados

No Banco de Dados SQL do Azure, um servidor é uma construção lógica que atua como um ponto administrativo central para uma coleção de bancos de dados. No nível do servidor, você pode administrar logons, método de autenticação, regras de firewall, regras de auditoria, políticas de deteção de ameaças e grupos de failover. Os dados relacionados a alguns desses recursos, como logins e regras de firewall, são armazenados no master banco de dados. Da mesma forma, os master dados de alguns DMVs, por exemplo sys.resource_stats, também são armazenados no banco de dados.

Quando um banco de dados com uma configuração com redundância de zona é criado em um servidor lógico, o master banco de dados associado ao servidor também é automaticamente tornado redundante de zona. Isso garante que, em uma interrupção zonal, os aplicativos que usam o banco de dados não sejam afetados porque os recursos dependentes do master banco de dados, como logons e regras de firewall, ainda estão disponíveis. Tornar a master zona do banco de dados redundante é um processo assíncrono e levará algum tempo para ser concluído em segundo plano.

Quando nenhum dos bancos de dados em um servidor é redundante de zona, ou quando você cria um servidor vazio, o master banco de dados associado ao servidor não é redundante de zona.

Você pode usar o Azure PowerShell ou a CLI do Azure ou a API REST para verificar a ZoneRedundant propriedade do master banco de dados:

Use o comando de exemplo a seguir para verificar o valor da propriedade "ZoneRedundant" para master o banco de dados.

Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"

Testar a resiliência a falhas do aplicativo

A alta disponibilidade é uma parte fundamental da plataforma do Banco de dados SQL que funciona de forma transparente para seu aplicativo de banco de dados. No entanto, reconhecemos que possa querer testar de que forma as operações de ativação pós-falha automáticas e iniciadas durante eventos planeados ou não planeados afetam a aplicação antes de a implementar para produção. Você pode acionar manualmente um failover chamando uma API especial para reiniciar um banco de dados ou um pool elástico. No caso de um banco de dados de uso geral provisionado ou sem servidor com redundância de zona ou pool elástico, a chamada de 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. Portanto, 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 da rede. Como a operação de reinicialização é intrusiva e um grande número delas pode sobrecarregar a plataforma, apenas uma chamada de failover é permitida a cada 15 minutos para cada banco de dados ou pool elástico.

Para saber mais sobre a alta disponibilidade e a recuperação de desastres do Banco de Dados SQL do Azure, consulte a Lista de verificação HA/DR.

Um failover pode ser iniciado usando PowerShell, API REST ou CLI do Azure:

Tipo de implementação PowerShell API REST CLI do Azure
Base de Dados Invoke-AzSqlDatabaseFailover Failover de banco de dados az rest pode ser usado para invocar uma chamada de API REST da CLI do Azure
Conjunto elástico Invoke-AzSqlElasticPoolFailover Failover de pool elástico az rest pode ser usado para invocar uma chamada de API REST da CLI do Azure

Importante

O comando Failover não está disponível para réplicas secundárias legíveis de bancos de dados Hyperscale.

Conclusão

A Base de Dados SQL do Azure apresenta uma solução de alta disponibilidade incorporada que está profundamente integrada com a plataforma Azure. Ele depende do Service Fabric para deteção e recuperação de falhas, do armazenamento de Blob do Azure para proteção de dados e das zonas de disponibilidade para maior tolerância a falhas. Além disso, o Banco de dados SQL usa a tecnologia de grupo de disponibilidade Always On do SQL Server para sincronização de dados e failover. A combinação dessas tecnologias permite que os aplicativos aproveitem plenamente os benefícios de um modelo de armazenamento misto e ofereça suporte aos SLAs mais exigentes.

Próximos passos