Arquitetura de funções distribuídas em hiperescala

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure

A camada de serviço Hyperscale utiliza uma arquitetura com níveis de armazenamento e computação altamente escaláveis e separados. Este artigo descreve os componentes que permitem que os clientes dimensionem rapidamente bancos de dados Hyperscale enquanto se beneficiam de backups quase instantâneos e logs de transações altamente escaláveis.

Gorjeta

Preços simplificados para o SQL Database Hyperscale em breve. Consulte o blog de preços do Hyperscale para obter detalhes.

Visão geral da arquitetura de hiperescala

Os mecanismos de banco de dados tradicionais centralizam as funções de gerenciamento de dados em um único processo: mesmo os chamados bancos de dados distribuídos em produção hoje têm várias cópias de um mecanismo de dados monolítico.

Os bancos de dados de hiperescala seguem uma abordagem diferente. A hiperescala separa o mecanismo de processamento de consultas, onde a semântica de vários mecanismos de dados diverge, dos componentes que fornecem armazenamento de longo prazo e durabilidade para os dados. Desta forma, a capacidade de armazenamento pode ser dimensionada sem problemas, na medida do necessário. O limite de armazenamento inicialmente suportado é de 100 TB.

Toda a comunicação de rede entre componentes Hyperscale usa a infraestrutura de rede do Azure com redundância interna.

Réplicas secundárias de alta disponibilidade e réplicas nomeadas são nós de computação opcionais que podem ser adicionados sob demanda. Ambos compartilham os mesmos componentes de armazenamento, portanto, nenhuma cópia de dados é necessária para criar uma nova réplica. Uma réplica geosecundária pode ser adicionada sob demanda na mesma região do Azure ou em uma região diferente. Para proteção de dados e redundância, as réplicas secundárias geográficas têm componentes de armazenamento separados daqueles usados pela réplica primária.

O diagrama a seguir ilustra a arquitetura funcional de hiperescala:

Diagram showing Hyperscale's compute tier.

Um banco de dados Hyperscale contém os seguintes tipos de componentes: nós de computação, servidores de página, o serviço de log e o armazenamento do Azure.

Computação

O nó de computação é onde o mecanismo relacional vive. O nó de computação é onde ocorre o processamento de linguagem, consulta e transação. Todas as interações do usuário com um banco de dados Hyperscale acontecem por meio de nós de computação. Os nós de computação podem ser configurados para usar computação sem servidor ou provisionada.

Os nós de computação têm caches locais baseados em SSD chamados Resilient Buffer Pool Extension (RBPEX Data Cache). O RBPEX Data Cache é um cache de dados inteligente de baixa latência que minimiza a necessidade de buscar dados de servidores de página remotos.

Os bancos de dados de hiperescala têm um nó de computação primário onde a carga de trabalho de leitura-gravação e as transações são processadas. Até quatro nós de computação secundária de alta disponibilidade podem ser adicionados sob demanda. Eles atuam como nós de espera ativa para fins de failover e podem servir como nós de computação somente leitura para descarregar cargas de trabalho de leitura quando desejado. As réplicas nomeadas são nós de computação secundários projetados para habilitar vários cenários adicionais de OLTP de expansão de leitura e para oferecer melhor suporte a cargas de trabalho de Processamento Transacional e Analítico Híbrido (HTAP). Um nó de computação geosecundário pode ser adicionado para fins de recuperação de desastres e para servir como um nó de computação somente leitura para descarregar cargas de trabalho de leitura em uma região diferente do Azure.

No serverless, a réplica primária e quaisquer réplicas de alta disponibilidade ou réplicas nomeadas são dimensionadas automaticamente de forma independente com base em seu uso. O intervalo de dimensionamento automático de computação para a réplica primária e quaisquer réplicas nomeadas são configurados independentemente. O intervalo de dimensionamento automático de todas as réplicas de alta disponibilidade é herdado da configuração de dimensionamento automático especificada pela réplica primária associada ou pela réplica nomeada.

O mecanismo de banco de dados em execução em nós de computação Hyperscale é o mesmo que em outras camadas de serviço do Banco de Dados SQL do Azure. Quando os usuários interagem com o mecanismo de banco de dados em nós de computação Hyperscale, a área de superfície suportada e o comportamento do mecanismo são os mesmos que em outras camadas de serviço, exceto por limitações conhecidas.

Servidor de páginas

Os servidores de página são sistemas que representam um mecanismo de armazenamento escalonado. Cada servidor de páginas é responsável por um subconjunto das páginas no banco de dados. Cada servidor de página também tem uma réplica que é mantida para redundância e disponibilidade.

O trabalho de um servidor de páginas é servir páginas de banco de dados para os nós de computação sob demanda e manter as páginas atualizadas à medida que as transações atualizam dados. Os servidores de página são mantidos atualizados reproduzindo registros de log de transações do serviço de log.

Os servidores de página também mantêm caches baseados em SSD para melhorar o desempenho. O armazenamento de longo prazo de páginas de dados é mantido no Armazenamento do Azure para durabilidade.

Serviço de registo

O serviço de log aceita registros de log de transações que correspondem a alterações de dados da réplica de computação primária. Em seguida, os servidores de página recebem os registros de log do serviço de log e aplicam as alterações às respetivas fatias de dados. Além disso, as réplicas secundárias de computação recebem registros de log do serviço de log e reproduzem apenas as alterações nas páginas que já estão em seu pool de buffers ou cache RBPEX local. Todas as alterações de dados da réplica de computação primária são propagadas através do serviço de log para todas as réplicas de computação secundárias e servidores de página.

Por fim, os registros de log de transações são enviados para o armazenamento de longo prazo no Armazenamento do Azure, que é um repositório de armazenamento virtualmente infinito. Esse mecanismo elimina a necessidade de truncamento frequente de log. Os motivos comuns para o crescimento de logs, como backups de log perdidos ou replicação lenta de dados para réplicas secundárias, não se aplicam ao Hyperscale. O serviço de log tem memória local e caches SSD para acelerar o acesso aos registros de log.

Armazenamento do Azure

O Armazenamento do Azure contém todos os arquivos de dados em um banco de dados. Os servidores de página mantêm os arquivos de dados no Armazenamento do Azure atualizados. Esse armazenamento também é usado para fins de backup e pode ser replicado entre regiões com base na opção de redundância de armazenamento.

Os backups são implementados usando instantâneos de armazenamento de arquivos de dados. As operações de restauração usando snapshots são rápidas, independentemente do tamanho dos dados. É possível restaurar uma base de dados para qualquer ponto no tempo dentro deste período de retenção de cópia de segurança.

O Hyperscale suporta redundância de armazenamento configurável. Ao criar um banco de dados Hyperscale, você pode escolher entre os seguintes tipos de armazenamento padrão do Azure:

  • Armazenamento localmente redundante (LRS)
  • Armazenamento com redundância entre zonas (ZRS)
  • Armazenamento georredundante com acesso de leitura (RA-GRS)
  • Armazenamento com georredundância de zona com acesso de leitura (RA-GZRS)

As opções de armazenamento com redundância de zona estão disponíveis em regiões do Azure com zonas de disponibilidade.

A opção de redundância de armazenamento selecionada é usada durante o tempo de vida do banco de dados, tanto para redundância de armazenamento de dados quanto para redundância de armazenamento de backup.

Conteúdos relacionados