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

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

• Base de Dados SQL do Azure
• Instância Gerida do SQL no Azure

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

Descrição geral

Um núcleo virtual (vCore) representa uma CPU lógica e oferece a opção de 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 oferece flexibilidade, controle, transparência do consumo de recursos individuais e uma maneira direta de traduzir 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 com base em suas necessidades de carga de trabalho.

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

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

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

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

Computação

A computação da Instância Gerenciada SQL fornece uma quantidade específica de recursos de computação que são continuamente provisionados independentemente da atividade da carga de trabalho e fatura a quantidade de computação provisionada a um preço fixo por hora.

Como três réplicas adicionais são alocadas automaticamente na camada de serviço Business Critical, o preço é aproximadamente 2,7 vezes maior do que na camada de serviço de uso geral. Da mesma forma, o preço de armazenamento mais alto por GB na camada de serviço Business Critical reflete os limites de E/S mais altos e a menor latência do armazenamento SSD local.

Para instâncias na camada de serviço de uso geral, é possível economizar em custos de computação e licenciamento interrompendo sua instância quando você não a estiver usando. Revise Parar e inicie uma instância (visualização) para saber mais.

Armazenamento de dados e logs

Os fatores a seguir afetam a quantidade de armazenamento usada para dados e arquivos de log e se aplicam às camadas de uso geral e críticas para os negócios.

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

Importante

Em ambas as camadas de serviço, você é cobrado pelo tamanho máximo de armazenamento configurado para uma instância gerenciada.

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

Armazenamento de cópias de segurança

O armazenamento para backups de banco de dados é alocado para dar suporte aos recursos da Instância Gerenciada SQL. Esse armazenamento é separado do armazenamento de dados e arquivos de log e é cobrado separadamente.

• Restauração point-in-time (PITR): 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 SQL. Uma quantidade de armazenamento de backup igual ao tamanho máximo de dados configurado é fornecida sem custo extra.
• Retenção de longo prazo (LTR): 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 quanto armazenamento será usado para backups LTR.

Escalões de serviço

As opções da camada de serviço no modelo de compra vCore incluem Propósito Geral e Crítico de Negócios. O nível de serviço geralmente define a arquitetura de armazenamento, os limites de espaço e E/S e as opções de continuidade de negócios relacionadas à disponibilidade e à recuperação de desastres.

Categoria	Fins Gerais	Negócios Críticos
Melhor para	A maioria das cargas de trabalho de negócios. Oferece opções de computação e armazenamento equilibradas, dimensionáveis e orientadas para orçamentos.	Oferece aos aplicativos de negócios a mais alta resiliência a falhas usando várias réplicas isoladas e fornece o mais alto desempenho de E/S.
Réplicas somente leitura	0	1
Réplicas para disponibilidade	Uma réplica para alta disponibilidade	Três réplicas de alta disponibilidade, 1 também é uma réplica em escala de leitura
Réplicas somente leitura com grupos de failover habilitados	Uma réplica adicional somente leitura. Duas réplicas legíveis no total, que incluem a réplica primária.	Duas réplicas somente leitura adicionais, três réplicas somente leitura no total. Quatro réplicas legíveis no total, que incluem a réplica primária.
Preços/faturação	vCore, armazenamento reservado e armazenamento de backup são cobrados. IOPS não é cobrado	vCore, armazenamento reservado e armazenamento de backup são cobrados. IOPS não é cobrado.
Modelos de desconto	Instâncias reservadas Benefício Híbrido do Azure (não disponível em subscrições de desenvolvimento/teste) Subscrições de desenvolvimento/teste Enterprise e Pay-As-You-Go	Instâncias reservadas Benefício Híbrido do Azure (não disponível em subscrições de desenvolvimento/teste) Subscrições de desenvolvimento/teste Enterprise e Pay-As-You-Go

Para obter mais detalhes, revise os limites de recursos.

Nota

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

Fins Gerais

O modelo de arquitetura para a camada de serviço de uso geral é baseado em uma separação de computação e armazenamento. Esse modelo de arquitetura depende da alta disponibilidade e confiabilidade do armazenamento de Blob do Azure que replica arquivos de banco de dados de forma 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.

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

• Uma camada de computação sem estado que está executando o sqlservr.exe processo e contém apenas dados transitórios e armazenados em cache (por exemplo: cache de plano, pool de buffers, pool de armazenamento de coluna). Esse nó sem estado é operado pelo Azure Service Fabric que inicializa o processo, controla a integridade do nó e executa failover para outro local, se necessário.
• Uma camada de dados com estado com arquivos de banco de dados (.mdf/.ldf) armazenados no armazenamento de Blob do Azure. O armazenamento de Blob do Azure garante que não haverá 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 todos os registros no arquivo de log ou página no arquivo de dados serão preservados, mesmo se o processo falhar.

Sempre que o mecanismo de banco de dados ou o sistema operacional for atualizado, alguma parte da infraestrutura subjacente falhar ou, se algum problema crítico for detetado no processo, o sqlservr.exe Azure Service Fabric moverá o processo sem estado para outro nó de computação sem monitoração de estado. Há um conjunto de nós sobressalentes que está aguardando para executar um novo serviço de computação se ocorrer um failover do nó primário para 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. Este processo garante 99,99% de disponibilidade por defeito. Pode haver alguns impactos no desempenho de cargas de trabalho pesadas que estão em voo devido ao tempo de transição e ao fato de que o novo nó começa com cache frio.

Quando escolher esta camada de serviço

A camada de serviço de Propósito Geral é a camada de serviço padrão na Instância Gerenciada SQL do Azure 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 de uso geral é a opção para você.

Crítico para a Empresa

O modelo de camada de serviço Crítica para os Negócios é baseado em um cluster de processos do mecanismo de banco de dados. Esse modelo de arquitetura depende de um quórum de nós do mecanismo de banco de dados sempre disponíveis para minimizar os impactos no desempenho de sua carga de trabalho, mesmo durante as atividades de manutenção. O Azure atualiza e corrige o sistema operacional subjacente, os drivers e o mecanismo de banco de dados do SQL Server de forma transparente, com tempo de inatividade mínimo para os usuários finais.

No modelo Business Critical, a computação e o armazenamento são integrados em cada nó. A replicação de dados entre processos do mecanismo de banco de dados em cada nó de um cluster de quatro nós alcança alta disponibilidade, com cada nó usando SSD conectado localmente como armazenamento de dados.

Tanto o processo do mecanismo de banco de dados do SQL Server quanto os arquivos .mdf/.ldf subjacentes são colocados no mesmo nó com armazenamento SSD conectado localmente, fornecendo baixa latência à sua carga de trabalho. A alta disponibilidade é implementada usando tecnologia semelhante aos grupos de disponibilidade Always On do SQL Server.

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 envia constantemente as alterações para os nós secundários para garantir que os dados estejam disponíveis em réplicas secundárias se o nó primário falhar 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 nova réplica secundária é criada para garantir que haja nós suficientes no cluster. A carga de trabalho é redirecionada automaticamente para o novo nó primário.

Além disso, o cluster Business Critical tem um recurso interno de Expansão de Leitura que fornece uma réplica somente leitura gratuita usada para executar consultas somente leitura (como relatórios) que não afetarão o desempenho da carga de trabalho em sua réplica principal.

Quando escolher esta camada de serviço

A camada de serviço Business Critical foi projetada para aplicativos que exigem respostas de baixa latência do armazenamento SSD subjacente (1-2 ms em média), recuperação mais rápida se a infraestrutura subjacente falhar ou precisam descarregar relatórios, análises e consultas somente leitura para a réplica secundária legível gratuita do banco de dados primário.

Os principais motivos pelos quais você deve escolher a camada de serviço Crítica para os Negócios em vez da camada de Uso Geral são:

• Requisitos de baixa latência de E/S – cargas de trabalho que precisam de uma resposta rápida da camada de armazenamento (1 a 2 milissegundos em média) devem usar a camada crítica para os negócios.
• Carga de trabalho com relatórios e consultas analíticas que podem ser redirecionadas para a réplica secundária somente leitura gratuita.
• Maior resiliência e recuperação mais rápida de falhas. Em caso de falha do sistema, os bancos de dados na instância primária são colocados off-line 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 avançada contra corrupção de dados. Como a camada Business Critical usa réplicas de bancos de dados nos bastidores, o serviço aproveita o reparo automático de páginas disponível com espelhamento e grupos de disponibilidade para ajudar a mitigar a corrupção de dados. Se uma réplica não puder ler uma página devido a um problema de integridade de dados, uma nova cópia da página será recuperada de outra réplica, substituindo a página ilegível sem perda de dados ou tempo de inatividade do cliente. Essa funcionalidade estará disponível na camada de Propósito Geral se a instância gerenciada tiver uma réplica geosecundária.
• Maior disponibilidade - A camada Crítica de Negócios em uma configuração de zona de multidisponibilidade fornece resiliência a falhas zonais e um SLA de maior disponibilidade .
• Recuperação geográfica rápida - Se um grupo de failover estiver configurado, a camada Crítica de Negócios terá um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) garantido de 5 segundos e um RTO (Recovery Time Objetive, objetivo de tempo de recuperação) de 30 segundos por 100% das horas implantadas.

Ao especificar a camada de serviço em modelos ou scripts, a camada é fornecida usando seu nome. Aplica-se o seguinte quadro:

Hardware	Nome
Fins Gerais	GeneralPurpose
Crítico para a Empresa	Negócio Crítico

Configurações de hardware

As opções de configuração de hardware no modelo vCore incluem série padrão (Gen5), série premium e série premium otimizada 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 especificidades e limitações da configuração de hardware, consulte Características de configuração de hardware.

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

Selecionando uma configuração de hardware

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

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

Para obter informações detalhadas, consulte Criar uma instância gerenciada do SQL.

Na guia Noções básicas, selecione o link Configurar banco de dados na seção Computação + armazenamento e selecione o hardware desejado:

Para alterar o hardware de uma instância gerenciada SQL existente

O portal do Azure

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

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

PowerShell

Use o seguinte script do PowerShell:

Set-AzSqlInstance -Name "managedinstance1" -ResourceGroupName "ResourceGroup01" -ComputeGeneration Gen5

Para obter mais detalhes, verifique o comando Set-AzSqlInstance .

A CLI do Azure

Use o seguinte comando da CLI:

az sql mi update -g mygroup -n myinstance --family Gen5

Para obter mais detalhes, verifique o comando az sql mi update .

Ao especificar o parâmetro de hardware em modelos ou scripts, o hardware é fornecido usando seu nome. Aplica-se o seguinte quadro:

Hardware	Nome
Série padrão (Gen5)	Gen5
Série premium	G8IM
Série premium otimizada para memória	G8IH

Nomes de SKU

Nota

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

SKU	Escalão de Serviço	Hardware
GP_Gen5	Fins Gerais	Série-padrão
GP_G8IM	Fins Gerais	Série premium
GP_G8IH	Fins Gerais	Série Premium otimizada para memória
BC_Gen5	Crítico para a Empresa	Série-padrão
BC_G8IM	Crítico para a Empresa	Série premium
BC_G8IH	Crítico para a Empresa	Série Premium otimizada para memória

Disponibilidade de hardware

Série padrão (Gen5) e série premium

O hardware das séries padrão (Gen5) e premium está disponível em todas as regiões públicas do mundo.

O hardware da série premium otimizado para memória está em pré-visualização e tem disponibilidade regional limitada. Para obter mais informações, consulte Limites de recursos da Instância Gerenciada SQL do Azure.

Próximos passos

• Para começar, consulte Criando uma instância gerenciada do SQL usando o portal do Azure
• Para obter detalhes sobre preços, consulte
  • Página de preços de instância única da Instância Gerenciada SQL do Azure
  • Página de preços dos pools de Instâncias Gerenciadas SQL do Azure
• Para obter detalhes sobre os tamanhos específicos de computação e armazenamento disponíveis nas camadas de serviço de Uso Geral e Críticas para os Negócios, consulte Limites de recursos baseados em vCore para a Instância Gerenciada SQL do Azure.