Disponibilidade por meio de redundância - Banco de Dados SQL do Azure
Aplica-se a: 
Banco de Dados SQL do Azure Banco de Dados SQL no Microsoft Fabric
Este artigo descreve a arquitetura do Banco de Dados SQL do Azure e do Banco de Dados SQL no Fabric, que alcançam disponibilidade por meio de redundância local e alta disponibilidade por meio de redundância entre zonas.
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 cuida automaticamente de tarefas de manutenção críticas, como aplicação de patch, backups, atualizações do SQL do Azure e do Windows, bem como eventos não planejados, como hardware subjacente, software ou falhas de rede. Quando um banco de dados ou pool elástico no Banco de Dados SQL é corrigido ou falha, o tempo de inatividade não é perceptível se você empregar a lógica de repetição no seu aplicativo. O Banco de Dados SQL pode se recuperar rapidamente, até 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 de modo contínuo.
Por padrão, o Banco de Dados SQL do Azure alcança disponibilidade por meio de redundância local, disponibilizando seu banco de dados durante:
- Operações de gerenciamento iniciadas pelo cliente que resultam em um curto tempo de inatividade
- Operações de manutenção de serviços
- Problemas com:
- o rack onde os computadores que acionam seu serviço estão sendo executados
- o computador físico que hospeda o mecanismo de banco de dados de SQL
- Outros problemas com o mecanismo de banco de dados de SQL
- Outras possíveis interrupções locais não planejadas
A solução de alta disponibilidade padrão foi projetada para garantir que os dados confirmados nunca sejam perdidos devido a falhas, para que as operações de manutenção não afetem sua carga de trabalho e para que o banco de dados não seja um ponto único 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 alcançar alta disponibilidade habilitando a redundância de zona. Sem redundância de zona, os failovers ocorrem localmente no mesmo data center, o que pode resultar na não disponibilidade 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 desastre, como failover geográfico por meio da replicação geográfica ativa, grupos de failover ou uma restauração geográfica de um backup com redundância geográfica. Para saber mais, revise a visão geral da continuidade dos negócios.
Há três modelos de arquitetura de alta disponibilidade:
- Modelo de armazenamento remoto que se baseia em uma separação de computação e armazenamento. Ele se baseia na alta disponibilidade e na confiabilidade da camada de armazenamento remoto. Essa arquitetura destina-se a aplicativos de negócios orientados para o orçamento que podem tolerar alguma degradação de desempenho durante atividades de manutenção.
- Modelo de armazenamento local que se baseia em um cluster de processos do mecanismo de banco de dados. Ele conta com o fato de que sempre há um quorum de nós do mecanismo de bancos de dados disponíveis. Essa arquitetura destina-se a aplicativos de missão crítica com alto desempenho de E/S, alta taxa de transações, e garante o impacto mínimo no desempenho da 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 dá suporte a um banco de dados de Hiperescala fornece sua redundância e resiliência a falhas. Os nós de computação, servidores de página e 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 de alta disponibilidade e redundância nativos. Para obter mais informações, confira Arquitetura de Hiperescala.
Em cada um dos três modelos de disponibilidade, o Banco de Dados SQL dá suporte a opções de redundância local e redundância zonal. A redundância local fornece resiliência em 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 seguinte tabela mostra as opções de disponibilidade com base nas camadas de serviço:
| Camada de serviço | Modelo de alta disponibilidade | Disponibilidade com redundância local | Disponibilidade com redundância de zona |
|---|---|---|---|
| Uso geral (vCore) | Armazenamento remoto | Sim | Sim |
| Comercialmente Crítico (vCore) | Armazenamento local | Yes | Yes |
| Hiperescala (vCore) | Hiperescala | Sim | Yes |
| Básico (DTU) | Armazenamento remoto | Sim | No |
| Standard (DTU) | Armazenamento remoto | Sim | No |
| Premium (DTU) | Armazenamento local | Yes | Sim |
Para obter mais informações sobre SLAs específicos para diferentes camadas de serviço, confira SLA para Banco de Dados SQL do Azure.
Disponibilidade por meio de redundância local
A disponibilidade com redundância local baseia-se no armazenamento do banco de dados no LRS (armazenamento com redundância local), que copia seus dados três vezes em um único datacenter na região primária e protege os dados em caso de falha local, como uma falha na rede de pequena escala ou 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. Caso ocorra um desastre em larga escala na região, como um incêndio ou uma inundação, todas as réplicas da conta de armazenamento que use o LRS poderão ser perdidas ou se tornarem irrecuperáveis. Dessa forma, para proteger ainda mais seus dados ao usar a opção de disponibilidade com redundância local, considere usar uma opção de armazenamento mais resiliente para os backups de banco de dados. Isso não se aplica a bancos de dados de hiperescala, em que 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 (RPO, Objetivo de Ponto de Recuperação), que indica que a quantidade de perda de dados é zero.
Camadas de serviço Básica, Standard e de Uso Geral
As camadas de serviço Básica e Standard do Modelo de compra baseado em DTU e a camada de serviço Uso Geral do Modelo de compra baseado em vCore usam o modelo de disponibilidade de armazenamento remoto para a computação sem servidor e provisionada. A figura a seguir mostra quatro nós diferentes com as camadas de computação e armazenamento separadas.
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 em cache, como os bancos de dado
tempdbemodelno SSD anexado e cache de planos, pool de buffer e pool columnstore na memória. Este nó sem estado é operado pelo Microsoft Azure Service Fabric, que inicializa o mecanismo de banco de dados, controla a integridade do nó e executa o failover para outro nó, se necessário. - Uma camada de dados com estado, com arquivos de banco de dados (
.mdfe.ldf) que são armazenados no Armazenamento de Blobs do Azure. O Armazenamento de Blobs do Azure possui recursos internos de redundância e disponibilidade de dados. Ele garante que todos os registros no arquivo de log ou na página do 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 detectada, 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 Blobs do Azure não são afetados pela movimentação, e os arquivos de dados/log são anexados ao processo do mecanismo de banco de dados recém-inicializado. Esse processo garante a alta disponibilidade, mas uma carga de trabalho pesada pode enfrentar degradação do desempenho durante a transição, uma vez que o novo processo do mecanismo de banco de dados começa com o cache frio.
Camada de serviço Premium e Comercialmente Crítico
A camada de serviço Premium do Modelo de compra baseado em DTU e a camada de serviço Comercialmente Crítico do Modelo de compra baseado em vCore usam o modelo de disponibilidade de armazenamento local, que integra os recursos de computação (processo do mecanismo de banco de dados) e o armazenamento (SSD anexado localmente) em um nó individual. A alta disponibilidade é obtida com a replicação da computação e do armazenamento para nós adicionais.
Os arquivos de banco de dados subjacentes (.mdf/.ldf) são colocados no armazenamento SSD anexado para fornecer uma E/S de latência muito baixa para sua carga de trabalho. A alta disponibilidade é implementada usando tecnologia semelhante ao SQL Server Grupos de Disponibilidade AlwaysOn. O cluster inclui uma única réplica primária que é acessível para cargas de trabalho de leitura/gravação do cliente e até três réplicas secundárias (computação e armazenamento) que contêm cópias de dados. A réplica primária envia constantemente alterações para as réplicas secundárias em ordem e garante que os dados sejam persistidos 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 para leitura falhar por qualquer motivo, sempre haverá uma réplica totalmente sincronizada para realizar o failover. O failover é iniciado pelo Azure Service Fabric. Depois que a réplica secundária se torna a nova réplica primária, outra réplica secundária é criada para garantir que o cluster tenha o número suficiente de réplicas para manter o quorum. Depois que um failover for concluído, as conexões do SQL do Azure serã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 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 uma capacidade de computação adicional de 100%, sem custo adicional, para operações somente leitura fora do carregamento, como cargas de trabalho analíticas, da réplica primária.
Tipo de serviço de Hiperescala
A arquitetura da camada de serviço de Hiperescala é descrita na Arquitetura de funções distribuídas.
O modelo de disponibilidade em Hiperescala inclui quatro camadas:
- Uma camada de computação sem estado que executa os processos do mecanismo de banco de dados e que contém somente dados transitórios e armazenados em cache, como o cache RBPEX sem cobertura, os bancos de dados
tempdbemodeletc. no SSD anexado, e cache de planos, pool de buffers e pool columnstore na memória. Essa camada sem estado inclui a réplica de computação primária e, opcionalmente, algumas 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 em cache, como o cache RBPEX com cobertura no SSD anexado, e páginas de dados armazenadas em cache na memória. Cada servidor de página tem um servidor de páginas emparelhado em uma configuração ativo-ativo para fornecer balanceamento de carga, redundância e alta disponibilidade.
- Uma camada de armazenamento do log de transações com estado formada pelo nó de computação que executa o processo do serviço de log, a zona de destino do log de transações e o armazenamento de longo prazo do log de transações. A zona de destino 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 as transações confirmadas.
- Uma camada de armazenamento de dados com estado nos arquivos de banco de dados (.mdf/.ndf) armazenados no Armazenamento do Azure e atualizados por servidores de página. Essa camada usa recursos de redundância e disponibilidade de dados do Armazenamento do Azure. Ele garante que todas as páginas em um arquivo de dados sejam preservadas, mesmo se os processos em outras camadas de falha de arquitetura de Hiperescala ou 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 em Hiperescala, consulte Alta Disponibilidade do Banco de Dados em Hiperescala.
Alta disponibilidade por meio 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 energia, resfriamento e rede independentes.
A disponibilidade com redundância de zona pode ser usada nos bancos de dados nas camadas de serviço de Uso Geral, Comercialmente Crítico e Hiperescala do Modelo de compra baseado em vCore, e somente a camada de serviço Premium do Modelo de compra baseado em DTU. As camadas de serviço Básica e Standard não são compatíveis com a redundância de zona.
Ao passo que cada camada de serviço implementa a redundância de zona de forma diferente, todas as implementações garantem um objetivo de ponto de recuperação (RPO) com perda zero de dados confirmados após o failover.
Camada de serviço de Uso Geral
A configuração com redundância de zona para a camada de serviço Uso Geral é oferecida para a computação sem servidor e provisionada para banco de dados no modelo de compra vCore. Essa configuração utiliza Zonas de Disponibilidade do Azure para replicar bancos de dados em vários locais físicos em uma região do Azure. Ao selecionar a redundância de zona, você pode tornar os pools elásticos e os bancos de dados individuais de uso geral sem servidor e provisionados novos e existentes resilientes a um conjunto muito maior de falhas, como interrupções catastróficas do datacenter, sem nenhuma alteração na lógica de aplicativo.
A configuração com redundância de zona da camada de serviço de uso geral tem duas camadas:
- Uma camada de dados com estado, com arquivos de banco de dados (.mdf/.ldf) que são armazenados no ZRS (armazenamento com redundância de zona). Com o uso do ZRS, os arquivos de log e de dados são copiados de maneira síncrona em três zonas de disponibilidade fisicamente isoladas do Azure.
- Uma camada de computação sem estado que executa o processo sqlservr.exe e contém apenas dados transitórios e em cache, como os bancos de dado
tempdbemodelno SSD anexado e cache de planos, pool de buffers e pool columnstore na memória. Este nó sem estado é operado pelo Microsoft Azure Service Fabric, que inicializa sqlservr.exe, controla a integridade do nó e executa o failover para outro nó, se necessário. Para bancos de dados de uso geral sem servidor e provisionado com redundância de zona, os nós com capacidade sobressalente 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 da camada de serviço de uso geral, é ilustrada pelo seguinte diagrama:
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á em disponibilidade geral nas seguintes regiões:
- (Africa) Norte da África do Sul
- (Pacífico Asiático) Leste da Austrália
- (Pacífico Asiático) Leste da Ásia
- (Pacífico Asiático) Leste do Japão
- (Pacífico Asiático) Coreia Central
- (Pacífico Asiático) Sudeste da Ásia
- (Pacífico Asiático) Índia Central
- (Pacífico Asiático) Norte da China 3
- (Ásia-Pacífico) Norte dos EAU
- (Europa) França Central
- (Europa) Centro-Oeste da Alemanha
- Norte da Itália (Europa)
- (Europa) Norte da Europa
- Leste da Noruega (Europa)
- (Europa) Polônia Central
- (Europa) Oeste da Europa
- (Europa) Sul do Reino Unido
- (Europa) Norte da Suíça
- (Europa) Suécia Central
- (Oriente Médio) Israel Central
- (Oriente Médio) 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) Sul do Brasil
- Para disponibilidade redundante de zona, a escolha de uma janela de manutenção diferente do padrão está atualmente disponível em regiões selecionadas.
- A configuração com redundância de zona só estará disponível no Banco de Dados SQL quando o hardware série padrão (Gen5) for selecionado.
- A redundância de zona não está disponível para as camadas de serviço Básica e Standard no modelo de compra de DTU.
Camadas de serviço Premium e Comercialmente Crítico
Quando a Redundância de Zona está habilitada para a camada de serviço Premium ou Comercialmente Crítico, as réplicas são colocadas em zonas de disponibilidade diferentes na mesma região. Para eliminar um ponto único de falha, o anel de controle também é duplicado entre várias zonas como três GW (anéis de gateway). O roteamento para um anel de gateway específico é controlado pelo Gerenciador de Tráfego do Azure. Como a configuração de zona redundante nas camadas de serviço Premium ou Comercialmente Crítico usa suas réplicas existentes para colocar em diferentes zonas de disponibilidade, você pode habilitá-la sem custo adicional. Ao selecionar uma configuração com redundância de zona, você pode tornar os pools elásticos e os bancos de dados Premium ou Comercialmente Crítico resilientes a um conjunto muito maior de falhas, incluindo interrupções catastróficas do datacenter, sem nenhuma alteração na lógica de aplicativo. Além disso, é possível converter quaisquer pools elásticos ou bancos de dados Premium ou Comercialmente Crítico existentes para a configuração com redundância de zona.
A versão com redundância de zona da arquitetura de alta disponibilidade é ilustrada pelo seguinte diagrama:
Considere o seguinte ao configurar os bancos de dados Premium ou Comercialmente Crítico com redundância de zona:
- Para obter informações atualizadas sobre as regiões que dão suporte a bancos de dados com redundância de zona, confira Suporte a serviços por região.
- Para disponibilidade redundante de zona, a escolha de uma janela de manutenção diferente do padrão está atualmente disponível em regiões selecionadas.
Tipo de serviço de Hiperescala
É possível configurar a redundância de zona para bancos de dados na camada de serviço Hiperescala. Para saber mais, examine Criar banco de dados de Hiperescala com redundância de zona.
A habilitação dessa configuração garante a resiliência no nível da zona por meio da replicação Zonas de Disponibilidade para todas as camadas de Hiperescala. Ao selecionar a redundância de zona, é possível tornar seus bancos de dados de Hiperescala resilientes a um conjunto muito maior de falhas, como interrupções catastróficas do datacenter, sem nenhuma alteração na lógica de aplicativo. Todas as regiões do Azure que têm Zonas de Disponibilidade dão suporte ao banco de dados de Hiperescala com redundância de zona. A redundância de zona para hardware PRMS e MOPRMS de hiperescala é permitida nas regiões listadas aqui.
A disponibilidade com redundância de zona é suportada em bancos de dados autônomos de Hiperescala e pools elásticos de Hiperescala. Para obter mais informações, consulte Pools elásticos de Hiperescala.
O diagrama a seguir demonstra a arquitetura subjacente para bancos de dados de Hiperescala com redundância de zona:
Considere as seguintes limitações:
A configuração com redundância 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 ponto a ponto ou crie uma réplica geográfica para atualizar a configuração com redundância de zona para um banco de dados de Hiperescala 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 da operação de dados.
Para disponibilidade redundante de zona, a escolha de uma janela de manutenção diferente do padrão está atualmente disponível em regiões selecionadas.
Atualmente, não há nenhuma opção para especificar a redundância de zona ao migrar um banco de dados para a Hiperescala usando o portal do Azure. Porém, a redundância de zona não pode ser especificada usando Azure PowerShell, CLI ou API REST ao migrar um banco de dados existente de outra camada de serviço do Banco de Dados SQL do Azure para a Hiperescala. 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 uma réplica de computação de alta disponibilidade e o uso do armazenamento de backup com redundância de zona ou com redundância de zona geográfica são necessários para habilitar a configuração com redundância de zona para Hiperescala.
Disponibilidade com redundância de zona do banco de dados
No Banco de Dados SQL do Azure, um servidor é um constructo lógico 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étodos de autenticação, regras de firewall, regras de auditoria, políticas de detecção de ameaças e grupos de failover. Os dados relacionados a alguns desses recursos, como logons e regras de firewall, são armazenados no banco de dados master. Da mesma forma, os dados de algumas 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 passa a ter redundância de zona automaticamente. Isso garante que, em uma interrupção zonal, os aplicativos que usam o banco de dados permaneçam inalterados porque os recursos dependentes do banco de dados master, como logons e regras de firewall, ainda estão disponíveis. A conversão do banco de dados master em um banco de dados com redundância de zona é um processo assíncrono e demora um pouco para ser concluído em segundo plano.
Quando nenhum dos bancos de dados em um servidor tiver redundância de zona ou quando você criar um servidor vazio, o banco de dados master associado ao servidor não terá redundância de zona.
Você pode usar o Azure PowerShell, a CLI do Azure ou a API REST para verificar a propriedade ZoneRedundant do banco de dados master:
Use o comando de exemplo a seguir para verificar o valor da propriedade "ZoneRedundant" do banco de dados master.
Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"
Testar a resiliência de falha do aplicativo
A alta disponibilidade é uma parte fundamental da plataforma de Banco de Dados SQL que funciona de maneira transparente para o aplicativo de banco de dados. No entanto, reconhecemos que talvez você queira testar como as operações de failover automático iniciadas durante os eventos planejados ou não planejados afetariam um aplicativo antes de implantá-lo na produção. Você pode disparar um failover manualmente chamando uma API especial para reiniciar um banco de dados ou um pool elástico. No caso de um pool elástico ou um banco de dados de Uso Geral sem servidor ou provisionado com redundância de zona, a chamada à API resultará no redirecionamento das conexões de cliente para o novo primário em uma zona de disponibilidade diferente da zona de disponibilidade do primário antigo. Assim, 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 de rede. Como a operação de reinicialização é intrusiva e o excesso da mesma 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 recuperação de desastre do Banco de Dados SQL do Azure, revise a Lista de verificação HA/DR.
Um failover pode ser iniciado usando o PowerShell, a API REST ou CLI do Azure:
| Tipo de implantação | PowerShell | API REST | CLI do Azure |
|---|---|---|---|
| Banco de dados | Invoke-AzSqlDatabaseFailover | Failover do banco de dados | az rest pode ser usado para invocar uma chamada à API REST de CLI do Azure |
| Pool elástico | Invoke-AzSqlElasticPoolFailover | Failover de pool elástico | az rest pode ser usado para invocar uma chamada à API REST de CLI do Azure |
Importante
O comando Failover não está disponível para réplicas secundárias legíveis de bancos de dados de Hiperescala.
Conclusão
O Banco de Dados SQL do Azure apresenta uma solução de alta disponibilidade interna, que está profundamente integrada com a plataforma Azure. Ele depende do Service Fabric para detecção de falha e recuperação, do armazenamento de Blobs do Azure para proteção de dados e de 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 percebam em sua totalidade os benefícios de um modelo de armazenamento misto e deem suporte aos SLAs mais exigentes.
Conteúdo relacionado
Para saber mais, confira: