Modelo de compra vCore – Instância Gerenciada de SQL do Azure

  • Artigo

Aplica-se a:Instância Gerenciada de SQL do Azure

Este artigo analisa o modelo de compra de vCores para a Instância Gerenciada de SQL do Azure.

Visão geral

Um vCore (núcleo virtual) representa uma CPU lógica e oferece a opção para escolher as características físicas do hardware (por exemplo, o número de núcleos, a memória e o tamanho do armazenamento). O modelo de compra baseado em vCore fornece flexibilidade, controle, transparência do consumo de recursos individual e uma forma simples de mover os requisitos de carga de trabalho local para a nuvem. Esse modelo otimiza o preço e permite que você escolha recursos de computação, memória e armazenamento de acordo com suas necessidades de carga de trabalho.

No modelo de compra baseado em vCore, seus custos dependem da escolha e do uso de:

  • Camada de serviço
  • Configuração de hardware
  • Recursos de computação (o número de vCores e a quantidade de memória)
  • Armazenamento de banco de dados reservado
  • Armazenamento de backup real

O modelo de compra vCore (núcleo virtual) usado pela Instância Gerenciada de SQL do Azure fornece os seguintes benefícios:

  • Controle sobre a configuração do hardware para corresponder melhor aos requisitos de computação e de memória da carga de trabalho.
  • Preços com descontos para o AHB (Benefício Híbrido do Azure) e a RI (instância reservada).
  • Maior transparência nos detalhes de hardware que potencializam a computação, para facilitar o planejamento de migrações de implantações locais.
  • Granularidade de dimensionamento mais alta com vários tamanhos de computação disponíveis.

Computação

A computação de Instância Gerenciada de SQL fornece uma quantidade específica de recursos de computação que são provisionados continuamente, de modo independente da atividade da carga de trabalho, e são cobrados pela quantidade de computação provisionada com um preço fixo por hora.

Como três réplicas adicionais são alocadas automaticamente na camada de serviço Comercialmente Crítico, o preço é aproximadamente 2,7 vezes mais alto do que na camada de serviço Uso Geral. Da mesma forma, o preço de armazenamento mais alto por GB na camada de serviço Comercialmente Crítico reflete os limites maiores de E/S e a menor latência do armazenamento SSD local.

Em instâncias na camada de serviço Uso Geral, é possível economizar em custos de computação e licenciamento interrompendo sua instância quando ela não está sendo usada. Faça uma revisão da seção Parar e iniciar uma instância para saber mais.

Armazenamento de dados e de log

Os fatores a seguir afetam a quantidade de armazenamento usada para arquivos de log e dados e se aplicam às camadas Uso Geral e Comercialmente Crítico.

  • Na camada de serviço de uso geral, o tempdb usa o armazenamento SSD local, e esse custo de armazenamento é incluído no preço do vCore.
  • Na camada de serviço Comercialmente Crítico, tempdb compartilha o armazenamento SSD local com dados e arquivos de log, e o custo de armazenamento tempdb está incluído no preço do vCore.
  • O tamanho de armazenamento máximo de uma Instância Gerenciada de SQL precisa ser especificado em múltiplos de 32 GB.

Importante

Nas duas camadas de serviço, a cobrança é feita de acordo com o tamanho máximo do armazenamento configurado para uma instância gerenciada.

Para monitorar o tamanho total de armazenamento consumido da instância para a Instância Gerenciada de SQL, use a métricastorage_space_used_mb. Para monitorar o atual tamanho de armazenamento alocado e usado de dados individuais e arquivos de log em um banco de dados usando o T-SQL, use a exibição sys.database_files e a função FILEPROPERTY(... , 'SpaceUsed').

Armazenamento de backup

O armazenamento de backups de bancos de dados é alocado para dar suporte às funcionalidades da Instância Gerenciada de SQL. Esse armazenamento é separado do armazenamento de arquivos de dados e de log e é cobrado separadamente.

  • PITR (restauração pontual): o consumo de armazenamento depende da taxa de alteração do banco de dados e do período de retenção configurado para backups. Você pode configurar um período de retenção separado para cada banco de dados entre 1 e 35 dias para a Instância Gerenciada de SQL. Uma quantidade de armazenamento de backup igual ao tamanho de dados máximo configurado é fornecida sem encargos extras.
  • LTR (retenção de longo prazo): você tem a opção de configurar a retenção de longo prazo de backups completos por até 10 anos. A configuração escolhida determina a quantidade de armazenamento que será usada para backups de LTR.

Camadas de serviço

Geralmente, a camada de serviço define a arquitetura de armazenamento, os limites de espaço e de E/S e as opções de continuidade de negócios relacionadas à disponibilidade e à recuperação de desastre.

A Instância Gerenciada de SQL do Azure tem duas camadas de serviço:

Para obter uma comparação em detalhes sobre as camadas de serviço, faça uma revisão dos limites de recursos, mas use a tabela a seguir para obter uma breve visão geral:

Categoria Uso Geral Uso Geral de Última Geração Comercialmente Crítico
Mais adequado para A maioria das cargas de trabalho comerciais. Oferece opções de armazenamento e de computação voltadas para o orçamento, equilibradas e escalonáveis. Cargas de trabalho de negócios orientadas para o orçamento que necessitam de maior capacidade, produtividade aprimorada e flexibilidade de recursos. Oferece aos aplicativos de negócios a maior resiliência a falhas usando várias réplicas isoladas e fornece o desempenho de E/S mais elevado.
Número máximo de vCores 80 128 128
Tamanho do armazenamento máximo para a instância 16 TB 32 TB 16 TB
Número máximo de bancos de dados por instância 100 500 100
Réplicas somente leitura 0 0 1
Réplicas para disponibilidade Nós em espera para alta disponibilidade Nós em espera para alta disponibilidade Três réplicas de alta disponibilidade, uma também é uma réplica de escala de leitura
Preço/cobrança O vCore, o armazenamento reservado e o armazenamento de backup são cobrados.
A IOPS não é cobrada		 vCore, armazenamento reservado, armazenamento de backup e IOPS (acima da cota gratuita) são cobrados. O vCore, o armazenamento reservado e o armazenamento de backup são cobrados.
A IOPS não é cobrada.

Observação

Para obter mais informações sobre o SLA (Contrato de Nível de Serviço), confira SLA para Instância Gerenciada de SQL do Azure.

Uso Geral

O modelo de arquitetura da camada de serviço de uso geral é baseado na separação entre computação e armazenamento. Esse modelo de arquitetura baseia-se na alta disponibilidade e na confiabilidade do Armazenamento de Blobs do Azure, que replica os arquivos de banco de dados de modo transparente e garante que não haja perda de dados se ocorrer uma falha na infraestrutura subjacente.

A figura a seguir mostra quatro nós no modelo de arquitetura padrão com as camadas de computação e armazenamento separadas.

Separação de computação e armazenamento

No modelo de arquitetura da camada de serviço de uso geral, há duas camadas:

  • Uma camada de computação sem estado que está executando o processo sqlservr.exe e contém apenas dados temporários e armazenados em cache (por exemplo, cache de plano, conjunto de buffers, conjunto de columnstore). Este nó sem estado é operado pelo Azure Service Fabric, que inicializa o processo, controla a integridade do nó e executa o failover para outro local, quando necessário.
  • Uma camada de dados com estado, com arquivos de banco de dados (.mdf/.ldf) que são armazenados no Armazenamento de Blobs do Azure. O Armazenamento de Blobs do Azure garante que não haja perda de dados de nenhum registro colocado em qualquer arquivo de banco de dados. O Armazenamento do Azure tem disponibilidade/redundância de dados interna, que garante que cada registro no arquivo de log ou cada página no arquivo de dados sejam preservados mesmo quando o processo do SQL Server falha.

Sempre que o mecanismo de banco de dados ou o sistema operacional é atualizado, alguma parte da infraestrutura subjacente falha ou, caso seja detectado algum problema crítico no processo do sqlservr.exe, o Azure Service Fabric move o processo sem estado para outro nó de computação sem estado. Há um conjunto de nós sobressalentes que fica esperando a execução do novo serviço de computação se ocorrer um failover do nó primário a fim de minimizar o tempo de failover. Os dados na camada de armazenamento do Azure não são afetados e os arquivos de dados/log são anexados ao processo recém-inicializado. Esse processo garante 99,99% de disponibilidade por padrão. Pode haver alguns impactos no desempenho em cargas de trabalho pesadas que estão na versão piloto devido ao tempo de transição e ao fato de o novo nó ser iniciado com cache frio.

Quando escolher essa camada de serviço

A camada de serviço Uso Geral é uma camada padrão na Instância Gerenciada de SQL do Azure que foi projetada para a maioria das cargas de trabalho genéricas. Se você precisar de um mecanismo de banco de dados totalmente gerenciado com um SLA padrão e latência de armazenamento entre 5 e 10 ms, a camada Uso Geral será a opção ideal para você.

Uso Geral de Última Geração

Observação

No momento, a atualização da camada de serviço Uso Geral de Última Geração está em preview. Para obter uma introdução, use a atualização da camada de serviço Uso Geral de Última Geração para as instâncias novas e existentes qualificadas.

A camada de serviço Uso Geral de Última Geração é uma atualização da arquitetura da camada de serviço Uso Geral existente que oferece as seguintes características principais:

  • Projetada para empresas com requisitos de desempenho elevados, ao mesmo tempo que oferta um custo da linha de base semelhante ao da camada de serviço Uso Geral.
  • Atualizações significativas de desempenho, escalabilidade e flexibilidade de recursos na camada de serviço Uso Geral.
  • Usa discos gerenciados em vez de blobs de páginas, o que melhora drasticamente as métricas de desempenho de armazenamento.
  • Fornecimento de 3 IOPS gratuitas para cada GB de armazenamento reservado.
  • Oferecimento de suporte para até 500 bancos de dados por instância e tamanho do armazenamento máximo de 32 TB.

Como a camada de serviço Uso Geral de Última Geração corresponde a uma atualização da camada de serviço Uso Geral existente, independentemente da camada de serviço usada pela instância, o demonstrativo de cobrança reflete a camada de serviço Uso Geral.

Modelo de arquitetura

A camada de serviço Uso Geral de Última Geração corresponde a uma atualização da camada de serviço Uso Geral existente que usa uma camada de armazenamento remoto atualizada para armazenar dados de instância e arquivos de registros em log nos discos gerenciados em vez de nos blobs de páginas. Isso significa que a atualização da camada de serviço Uso Geral de Última Geração oferta latência de armazenamento, IOPS e produtividade mais rápidas do que a camada de serviço Uso Geral existente, com limites maiores para armazenamento, número de vCores e número máximo de bancos de dados. Além disso, como as cotas de desempenho são compartilhadas por toda a instância, não é mais necessário redimensionar arquivos individuais para aprimorar o desempenho. O custo da linha de base da camada de serviço Uso Geral de Última Geração é semelhante ao da camada de serviço Uso Geral, entretanto, é possível usar controles deslizantes para aumentar o desempenho de operações de E/S, os quais serão cobrados separadamente.

A camada de serviço Uso Geral de Última Geração ajuda a reduzir custos com a oferta de IOPS gratuitas que compreende três IOPS para cada GB de armazenamento reservado. O preço do armazenamento inclui um valor de IOPS mínimo. Se você ultrapassar o valor mínimo, terá cobranças da seguinte forma: 1 IOPS = preço de armazenamento (por região) dividido por três.

Por exemplo:

  • Se o custo de 1 GB de armazenamento é US$ 0,115, então 1 IOPS = 0,115/3 = US$ 0,038 por IOPS.
  • Uma instância de 1.024 GB receberá 3.072 IOPS gratuitamente. É possível escolher aumentar o número de IOPS até os limites da VM por um custo adicional.

Quando escolher essa camada de serviço

Escolha esta camada de serviço se os seus negócios forem orientados para o orçamento, mas as métricas de desempenho e os limites da camada de serviço Uso Geral forem insuficientes.

Os principais motivos pelos quais você deve escolher a camada de serviço Uso Geral de Última Geração em vez da camada Uso Geral são:

  • Melhor desempenho pelo mesmo custo da linha de base
  • Latência, produtividade e IOPS aprimoradas
  • Maior capacidade de armazenamento
  • Mais flexibilidade para a computação
  • Você precisar de mais de 100 bancos de dados para uma instância única
  • Você precisar de mais de 16 TB de armazenamento reservado

Comercialmente Crítico

O modelo de camada de serviço Comercialmente Crítico se baseia em um cluster de processos de mecanismo de banco de dados. Esse modelo de arquitetura se baseia no quorum de nós de mecanismo de banco de dados sempre disponíveis para minimizar o impacto no desempenho na sua carga de trabalho, mesmo durante as atividades de manutenção. O Azure atualiza e aplica patches subjacentes ao sistema operacional, aos drivers e ao mecanismo de banco de dados do SQL Server de modo transparente com mínimo tempo de inatividade para usuários finais.

No modelo Comercialmente Crítico, a computação e o armazenamento são integrados em cada nó. A replicação de dados entre os processos do mecanismo de banco de dados em cada nó de um cluster de quatro nós resulta em alta disponibilidade, com cada nó usando o SSD anexado localmente como armazenamento de dados.

Cluster de nós de mecanismo de banco de dados

O processo do mecanismo de banco de dados do SQL Server e arquivos .mdf/.ldf subjacentes são colocados no mesmo nó, com armazenamento SSD conectado localmente, fornecendo baixa latência para sua carga de trabalho. A alta disponibilidade é implementada usando tecnologia semelhante ao SQL Server Grupos de Disponibilidade AlwaysOn.

Cada instância é um cluster de nós do mecanismo de banco de dados que contém cópias de todos os bancos de dados em uma instância, com um banco de dados primário acessível para cargas de trabalho do cliente e três bancos de dados secundários contendo cópias dos dados, prontos para failover. O nó primário efetua constantemente push de alterações para nós secundários para garantir que os dados estejam disponíveis em réplicas secundárias, caso o nó primário falhe por qualquer motivo.

O failover é tratado pelo mecanismo de banco de dados do SQL Server – uma réplica secundária se torna o nó primário e uma réplica secundária nova é criada para garantir que existam nós suficientes no cluster. A carga de trabalho é automaticamente redirecionada para o novo nó primário.

Além disso, o cluster Comercialmente Crítico tem a funcionalidade interna de Expansão de Leitura que fornece uma réplica somente leitura gratuita que pode ser usada para executar consultas somente leitura (por exemplo, relatórios) que não afetam o desempenho da carga de trabalho da sua réplica primária.

Quando escolher essa camada de serviço

A camada de serviço Comercialmente Crítico foi projetada para aplicativos que requerem respostas de baixa latência do armazenamento SSD subjacente (de 1 a 2 ms em média), recuperação mais rápida se a infraestrutura subjacente falhar ou precisar transferir relatórios, análise e consultas somente leitura para a réplica secundária para leitura gratuita do banco de dados primário.

Estes são os principais motivos pelos quais você deve escolher a camada de serviço Comercialmente Crítico em vez da camada de Uso Geral:

  • Requisitos de baixa latência de E/S – cargas de trabalho que precisam de uma resposta rápida da camada de armazenamento (de 1 a 2 ms em média) devem usar a camada de serviço Comercialmente Crítico.
  • Carga de trabalho com consultas analíticas e de relatório que podem ser redirecionadas para a réplica somente leitura secundária gratuita.
  • Resiliência superior e recuperação mais rápida de falhas. Caso haja falha do sistema, os bancos de dados na instância primária ficarão offline e uma das réplicas secundárias se tornará imediatamente a nova instância primária de leitura/gravação, pronta para processar consultas. Não há necessidade de o mecanismo de banco de dados analisar e refazer transações do arquivo de log ou carregar dados em buffers de memória.
  • Proteção de corrupção de dados avançada. Como a camada Comercialmente Crítico usa réplicas de bancos de dados nos bastidores, o serviço aproveita o reparo automático de página disponível com grupos de disponibilidade e espelhamento para ajudar a reduzir os dados corrompidos. Se uma réplica não conseguir ler uma página devido a um problema de integridade dos dados, uma nova cópia da página será recuperada de outra réplica, substituindo a página ilegível sem perda de dados nem tempo de inatividade do cliente. Essa funcionalidade estará disponível na camada Uso Geral se a instância gerenciada tiver uma réplica geográfica secundária.
  • Disponibilidade mais alta: a camada Comercialmente Crítico na configuração de múltiplas zonas de disponibilidade fornece resiliência para falhas zonais e um SLA de maior disponibilidade.
  • Recuperação geográfica rápida: quando o grupo de failover for configurado, a camada de serviço Comercialmente Crítico terá um RPO (objetivo de ponto de recuperação) garantido de cinco segundos e um RTO (objetivo de tempo de recuperação) de 30 segundos para 100% das horas implantadas.

Ao especificar a camada de serviço em modelos ou scripts, a camada é fornecida usando seu nome. A seguinte tabela se aplica:

Hardware Nome
Uso Geral GeneralPurpose
Comercialmente Crítico Comercialmente Crítico

Configuração de hardware

As opções de configuração de hardware no modelo vCore incluem as séries Standard (Gen5), Premium e Premium com otimização para memória. A configuração de hardware geralmente define os limites de computação e memória e outras características que afetam o desempenho da carga de trabalho.

Para obter mais informações sobre as limitações e as especificações de configuração de hardware, confira Características de configuração de hardware.

Na exibição de gerenciamento dinâmico sys.dm_user_db_resource_governance, a geração de hardware para instâncias que usam processadores Intel® SP-8160 (Skylake) será exibida como Gen6, enquanto a geração de hardware para instâncias que usam o Intel® 8272CL (Cascade Lake) será exibida como Gen7. As CPUs Intel® 8370C (Ice Lake) usadas pelas gerações de hardware das séries premium e premium otimizado para memória são exibidas como Gen8. Os limites de recursos para todas as instâncias da série Standard (Gen5) são os mesmos, independentemente do tipo de processador (Broadwell, Skylake ou Cascade Lake).

Selecionar uma configuração de hardware

Você pode selecionar uma configuração de hardware no momento da criação da instância ou alterar o hardware de uma instância existente.

Para selecionar uma configuração de hardware ao criar uma Instância Gerenciada de SQL

Para obter informações detalhadas, confira Criar uma Instância Gerenciada de SQL.

Na guia Básico, selecione o link Configurar banco de dados na seção Computação + armazenamento e selecione o hardware desejado:

configurar Instância Gerenciada de SQLPara alterar a configuração de hardware de uma Instância Gerenciada de SQL existente

Na página Instância Gerenciada de SQL, selecione Computação + armazenamento em Configurações:

A captura de tela mostra a página Computação e Armazenamento para a instância gerenciada de SQL.

Na página Computação + armazenamento, você pode alterar seu hardware em Geração de hardware usando os controles deslizantes para vCores e armazenamento.

Ao especificar o parâmetro de hardware em modelos ou scripts, o hardware é fornecido usando o respectivo nome. A seguinte tabela se aplica:

Hardware Nome
Série Standard (Gen 5) Gen5
Série Premium G8IM
Série Premium otimizado para memória G8IH

Nomes de SKU

Observação

Ao especificar hardware e nível de serviço em modelos ou scripts, você pode especificá-los de forma independente ou pode fornecer um nome de SKU. Ao especificar o nome do SKU, aplica-se a seguinte tabela:

SKU Camada de Serviço Hardware
GP_Gen5 Uso Geral Série Standard
GP_G8IM Uso Geral Série Premium
GP_G8IH Uso Geral Série Premium com otimização de memória
BC_Gen5 Comercialmente Crítico Série Standard
BC_G8IM Comercialmente Crítico Série Premium
BC_G8IH Comercialmente Crítico Série Premium com otimização de memória

Disponibilidade de hardware

Série Standard (Gen5) e série Premium

O hardware das séries Standard (Gen5) e Premium está disponível em todas as regiões públicas no mundo inteiro.

O hardware da série Premium com otimização para memória está em versão prévia e tem disponibilidade regional limitada. Para obter mais informações, confira Limites de recursos da Instância Gerenciada de SQL do Azure.

Próximas etapas