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

Aplica-se a:Instância Gerenciada SQL do 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.

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.

Para obter mais detalhes, revise os limites de recursos.

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:

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

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

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

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

Nomes de SKU

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.