Partilhar via

Disponibilidade através de redundância - Base de Dados SQL do Azure

  • Artigo

Aplica-se a:Banco de Dados SQL do AzureBanco de Dados SQL no Fabric

Este artigo descreve a arquitetura do Banco de Dados SQL do Azure e do Banco de Dados SQL no Fabric que alcança disponibilidade por meio de redundância local e alta disponibilidade por meio de redundância de zona.

Visão geral

O Banco de Dados SQL do Azure e o Banco de Dados SQL no Fabric são executados 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 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 realizadas continuamente.

Por padrão, o Banco de Dados SQL do Azure alcança disponibilidade por meio de redundância local, assegurando que o seu banco de dados esteja disponível durante:

  • Operações de gerenciamento iniciadas pelo cliente que resultam em um breve tempo de inatividade
  • Operações de manutenção de serviços
  • Problemas com:
    • rack onde as máquinas que suportam o seu serviço estão a funcionar
    • máquina física que hospeda o mecanismo de banco de dados SQL
  • Outros problemas com o mecanismo de banco de dados SQL
  • Outras possíveis interrupções locais não planejadas

A solução de disponibilidade padrão foi projetada para garantir que os dados confirmados 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.

No entanto, para minimizar o impacto em seus dados no caso de uma interrupção em uma zona inteira, você pode obter de alta disponibilidade habilitando a redundância de zona. Sem redundância de zona, os failovers acontecem localmente no mesmo data center, o que pode resultar na indisponibilidade do banco de dados até que a interrupção seja resolvida - a única maneira de recuperar é por meio de uma solução de recuperação de desastres, como failover geográfico por meio de de replicação geográfica ativa, grupos de failoverou uma de restauração geográfica de um backup com redundância geográfica. Para saber mais, consulte a visão geral da continuidade de negócios.

Existem três modelos de arquitetura de disponibilidade:

  • Modelo de armazenamento remoto baseado em uma separação de computação e armazenamento. Ele depende da disponibilidade e da confiabilidade do nível de armazenamento remoto. Essa arquitetura visa aplicativos de negócios orientados a orçamento que podem tolerar alguma degradação de desempenho durante as atividades de manutenção.
  • Modelo de armazenamento local baseado em um cluster de processos do mecanismo de banco de dados. Ele se baseia no fato de que sempre há um quórum de nós de mecanismo de banco 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 Hyperscale 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 o estado de cada componente e realiza transferências automáticas para nós saudáveis 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:

Nível 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) Hiperescala Sim Sim
Básico (DTU) Armazenamento remoto Sim Não
Padrão (DTU) Armazenamento remoto Sim Não
Premium (DTU) Armazenamento local Sim Sim

Para obter mais informações sobre SLAs específicos para diferentes camadas de serviço, consulte SLA do Banco de Dados SQL do Azure.

Disponibilidade através de redundância local

A disponibilidade com redundância local baseia-se no armazenamento do banco de dados em de armazenamento com redundância local (LRS), 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 poderão ser perdidas ou irrecuperáveis. Como tal, para proteger ainda mais seus dados ao usar a opção de disponibilidade localmente redundante, considere usar 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 o Objetivo de Ponto de Recuperação (RPO), que indica que não há perda de dados.

Camadas de serviço básicas, padrão e de uso geral

As camadas de serviço Básico e Padrão do modelo de compra baseado em DTU, , e a camada de serviço de Uso Geral do modelo de compra baseado em vCore, , usam o modelo de disponibilidade de armazenamento remoto tanto para computação sem servidor como para computação provisionada. A figura a seguir mostra quatro nós diferentes com as camadas de computação e armazenamento separadas.

Diagrama mostrando a separação de computação e armazenamento.

O modelo de disponibilidade de armazenamento remoto inclui duas camadas:

  • Uma camada de computação sem estado que executa o processo do motor de base de dados e contém apenas dados transitórios e armazenados em cache, como os bancos de dados tempdb e model no SSD anexado, e cache de planos, pool de buffers e pool de colunas 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 Blobs 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 Blob do Azure não são afetados pela mudança, e os arquivos de dados/log são anexados ao processo do motor de base 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, já 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

A camada de serviço Premium do modelo de compra baseado em DTU e a camada de serviço Business Critical do modelo de compra baseado em vCore usam o modelo de disponibilidade de armazenamento local, que integra recursos de computação (processo do motor de base de dados) e armazenamento (SSD ligado localmente) num único nó. A alta disponibilidade é obtida replicando a computação e o armazenamento para nós adicionais.

Diagrama de um cluster de nós do mecanismo de banco de dados.

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 do SQL Server Always On. 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. Este processo garante que, se a réplica primária ou uma réplica secundária legível avariar por qualquer motivo, haverá sempre uma réplica totalmente sincronizada para a qual fazer a transição. 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 em local inclui a capacidade de redirecionar conexões somente leitura do Azure SQL para uma das réplicas secundárias. Este recurso é chamado de Expansão de Leitura. Ele fornece 100% de capacidade de computação adicional sem custo adicional para descarregar operações somente de leitura, como cargas de trabalho analíticas, da réplica principal.

Camada de serviço de hiperescala

A arquitetura da camada de serviço Hyperscale é descrita em Distributed functions architecture.

Diagrama mostrando a arquitetura funcional Hyperscale.

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 coberto, bancos de dados tempdb e model, etc. no SSD conectado, e planeje cache, 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 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 estado formada pelo nó de computação que executa o processo do serviço Log, a zona de receção de logs 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 de redundância para o log de transações, garantindo a durabilidade dos dados para transações confirmadas.
  • Uma camada de armazenamento de dados com 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 disponibilidade de dados e redundância de recursos 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 realiza transferências automáticas 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.

Alta disponibilidade através de redundância de zona

A disponibilidade com redundância de zona garante que seus dados estejam espalhados por três zonas de disponibilidade do Azure na região primária. Cada zona de disponibilidade é um local físico separado com alimentação, refrigeração e rede independentes.

A disponibilidade com redundância de zona está disponível para bases de dados nas camadas de serviço Business Critical, General Purpose e Hyperscale do modelo de compra baseado em vCore e apenas na camada de serviço Premium do modelo de compra baseado em DTU . As camadas de serviço Basic e Standard não suportam redundância de zona.

Embora cada camada de serviço implemente redundância de zona de forma diferente, todas as implementações garantem um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) com perda zero de dados comprometidos após o failover.

Nível de serviço de uso geral

A configuração com redundância de zona para o nível de serviço de Uso Geral é oferecida tanto para computação serverless quanto para computação provisionada para bancos de dados no modelo de compra com base em vCores. Esta 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 Propósito 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 ZRS os dados e 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 sqlservr.exe e contém apenas dados transitórios e armazenados em cache, como os bancos de dados tempdb e model no SSD anexado, e cache de planos, pool de buffers e pool columnstore na memória. Este nó sem estado é operado pelo Azure Service Fabric, que inicializa sqlservr.exe, controla a integridade do nó e, se necessário, realiza a comutação para outro nó. Para bases de dados de Uso Geral, sem servidor e provisionados com redundância de zona, existem nós com capacidade ociosa prontamente disponíveis em outras Zonas de Disponibilidade para transferência em caso de falha.

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:

Diagrama de configuração redundante de zona para fins gerais.

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
    • (Ásia-Pacífico) Leste do Japão
    • (Á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) Norte da Europa
    • (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) EUA centrais
    • (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
  • A redundância de disponibilidade por zona atualmente permite escolher uma janela de manutenção diferente do padrão 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 Basic e Standard no modelo de aquisição DTU.

Níveis de serviço Premium e Business Critical

Quando a Redundância de Zona está habilitada para a camada de serviço Premium ou Business Critical, as réplicas são colocadas em zonas de disponibilidade diferentes 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 Azure Traffic Manager. Uma vez que a configuração com redundância de zona nas camadas de serviço Premium ou Business Critical utiliza as suas réplicas existentes para as distribuir por diferentes zonas de disponibilidade, pode-se habilitá-la sem custos adicionais. 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 existente no nível Premium ou Business Critical, ou pools elásticos, para uma 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:

Diagrama da arquitetura de alta disponibilidade com redundância de zona.

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 a seção 'Suporte a serviços por região ' em.
  • Para disponibilidade redundante de zona, escolher uma janela de manutenção diferente do padrão está atualmente disponível em regiões selecionadas.

Camada de serviço de hiperescala

É possível configurar redundância de zona para bancos de dados na camada de serviço Hyperscale. Para saber mais, reveja Criar base de dados Hyperscale redundante para zonas.

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 suporte de redundância de zonas para os hardwares Hyperscale PRMS e MOPRMS está disponível nas regiões aqui listadas .

A disponibilidade com redundância de zona é suportada tanto em bases de dados autónomas Hyperscale como em pools elásticos Hyperscale. Para obter mais informações, consulte pools elásticos de hiperescala.

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

Diagrama mostrando a arquitetura subjacente de bancos de dados Hyperscale redundantes de zona.

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 base de dados, restauração point-in-time , ou crie uma réplica geográfica para atualizar a configuração de redundância 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, o da operação de cópia de será um tamanho de operação de dados.

  • A escolha de uma janela de manutenção diferente do padrão encontra-se disponível atualmente em regiões selecionadaspara a disponibilidade redundante de zona.

  • 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 de 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 banco de dados master. Da mesma forma, os dados de alguns DMVs, por exemplo, sys.resource_stats, também são armazenados no banco de dados master.

Quando um banco de dados com uma configuração com redundância de zona é criado em um servidor lógico, o banco de dados master 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 banco de dados master, como logons e regras de firewall, ainda estão disponíveis. Tornar a zona de banco de dados master 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 banco de dados de master associado ao servidor não é redundante de zona.

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

Use o comando de exemplo a seguir para verificar o valor da propriedade "ZoneRedundant" para master 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 talvez você queira testar como as operações automáticas de failover iniciadas durante eventos planejados ou não planejados afetariam um aplicativo antes de implantá-lo na 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 uma base de dados de Uso Geral provisionada ou sem servidor, com redundância de zona, ou um pool elástico, a chamada da API resultaria no redirecionamento das conexões do cliente para o novo principal numa Zona de Disponibilidade diferente da Zona de Disponibilidade do principal 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 de HA/DR do .

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

Tipo de implantação PowerShell REST API Azure CLI
Base de dados Invoke-AzSqlDatabaseFailover Alternância de banco de dados Pode usar o comando az rest para invocar uma chamada de API REST a partir do Azure CLI.
Piscina elástica Invoke-AzSqlElasticPoolFailover Conjunto elástico de failover 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. 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.

Conteúdo relacionado

Para saber mais, consulte: