Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a:
Instância Gerida do Azure SQL
Este artigo analisa o modelo de compra vCore para Instância Gerenciada SQL do Azure.
Visã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:
- Camada de serviço
- Configuração de 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 atual
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 do Benefício Híbrido do Azure (AHB) e 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 mais alto do que na camada de serviço General Purpose. 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. Reveja Pare e inicie a instância 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,
tempdbusa armazenamento SSD local e esse custo de armazenamento está incluído no preço do vCore. - Na camada de serviço Business Critical, o
tempdbpartilha o armazenamento SSD local com dados e arquivos de log, e o custo de armazenamento dotempdbestá incluído no preço 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 monitorizar o tamanho total do armazenamento de instâncias consumido para uma 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
Armazenamento de backup
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.
- de 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.
Níveis de serviço
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.
A Instância Gerenciada SQL do Azure tem duas camadas de serviço:
- Finalidade geral. Você pode optar por usar a camada de serviço atualizada de uso geral de nova geração (visualização).
- Crítico para o negócio.
Para obter uma comparação detalhada entre as camadas de serviço, revise limites de recursos, mas use a tabela a seguir para obter uma breve visão geral:
| Categoria | Uso Geral | de uso geral de próxima geração | Crítico para o Negócio |
|---|---|---|---|
| Melhor para | A maioria das cargas de trabalho empresariais. Oferece opções de computação e armazenamento orientadas para o orçamento, equilibradas e escaláveis. | Cargas de trabalho empresariais focadas no orçamento que necessitam de maior capacidade, melhor desempenho e flexibilidade de recursos. | 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. |
| Número máximo de vCores | 80 | 128 | 128 |
| Tamanho máximo de armazenamento de instância | 16 TB | 32 TB | 16 TB |
| máximo de bancos de dados por instância | 100 | 500 | 100 |
| Réplicas somente leitura | 0 | 0 | 1 |
| réplicas para disponibilidade | Nodos de espera para alta disponibilidade | Nodos de espera para alta disponibilidade | Três réplicas de alta disponibilidade, sendo uma também uma réplica em escala de leitura |
| Preços e Faturação |
vCore, armazenamento reservado e armazenamento de backup são cobrados. IOPS não é cobrado |
vCore, armazenamento reservado, armazenamento de backup e IOPS (acima da cota gratuita) são cobrados. |
vCore, armazenamento reservado e armazenamento de backup são cobrados. IOPS não é cobrada. |
Observação
Para obter mais informações sobre o Contrato de Nível de Serviço (SLA), consulte SLA para Instância Gerenciada SQL do Azure.
Finalidade Geral
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 executa o processo
sqlservr.exee contém apenas dados transitórios e em cache (por exemplo – cache de plano, pool de buffers, pool de armazenamento em colunas). Este nó sem estado é operado pelo Azure Service Fabric, que inicializa o processo, controla a integridade do nó e realiza a transferência 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 de sqlservr.exe, o Azure Service Fabric moverá o processo sem estado para outro nó de computação sem estado. Há um conjunto de nós sobressalentes que está à espera para executar um novo serviço de computação caso ocorra um failover do nó primário, minimizando assim 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% disponibilidade por padrão. Pode haver impactos no desempenho de cargas de trabalho pesadas que estão em voo devido ao tempo de transição e ao fato de o novo nó começar 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ê.
Próxima Geração de Propósito Geral
Observação
A atualização da camada de serviço de próxima geração de uso geral está em visualização atualmente. Para começar, use a atualização para a camada de serviço de uso geral de próxima geração para instâncias novas e existentes qualificadas.
A camada de serviço de uso geral de próxima geração é uma atualização arquitetônica da camada de serviço de finalidade geral existente que oferece as seguintes características principais:
- Projetado para empresas com requisitos de desempenho mais altos, oferecendo o mesmo custo de linha de base que a camada de serviço de uso geral
- Upgrades significativos de desempenho, escalabilidade e flexibilidade de recursos em relação à camada de serviço de uso geral
- Usa discos gerenciados em vez de blobs de página, que melhoram drasticamente as métricas de desempenho de armazenamento
- 3 IOPS grátis para cada GB de armazenamento reservado
- Suporte de até 500 bancos de dados por instância e um tamanho máximo de armazenamento de 32 TB
Como a camada de serviço Próxima Geração de Finalidade Geral é uma atualização para a camada de serviço de Finalidade Geral existente, independentemente da camada de serviço que a sua instância utiliza, a sua fatura reflete a camada de serviço de Finalidade Geral.
Modelo arquitetónico
A camada de serviço de Propósito Geral de Próxima Geração é uma atualização para a camada de serviço de Propósito Geral existente que usa uma camada de armazenamento remoto atualizada para armazenar dados de instância e arquivos de log em discos gerenciados em vez de blobs de página. Isso significa que a atualização da camada de serviço de uso geral de próxima geração oferece latência, IOPS e taxa de transferência de armazenamento mais rápidas do que a camada de serviço de uso geral existente, com limites maiores para armazenamento, o número de vCores e o 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 melhorar seu desempenho. O custo base da camada de serviço de Finalidade Geral de Próxima Geração é o mesmo da camada de serviço de Finalidade Geral, mas pode usar barras deslizantes para aumentar o desempenho de E/S, que é cobrado separadamente.
A camada de serviço de uso geral de próxima geração oferece suporte à memória flexível (visualização), que permite que você escolha a quantidade de memória que deseja alocar para sua instância. Esta é uma melhoria significativa em relação à camada de serviço de uso geral, que tem uma alocação de memória fixa com base no número de vCores selecionados. A memória flexível está atualmente disponível para instâncias localmente redundantes em hardware da série premium.
A camada de serviço de uso geral de última geração ajuda a reduzir os custos, oferecendo IOPS gratuitas a três IOPS para cada GB de armazenamento reservado. O preço do armazenamento inclui o IOPS mínimo. Se você ultrapassar o mínimo, será cobrado da seguinte forma: 1 IOPS = preço de armazenamento (por região) dividido por três.
Por exemplo:
- Se 1 GB de armazenamento custar 0,115, então 1 IOPS = 0,115/3 = 0,038 por IOPS.
- Uma instância de 1.024 GB recebe 3072 IOPS gratuitamente. Você pode optar por aumentar suas IOPS até o limite de VM por um custo adicional.
Quando escolher esta camada de serviço
Escolha esta camada de serviço se a sua empresa for orientada para o orçamento, mas as métricas de desempenho e os limites da camada de serviço de uso geral forem insuficientes.
Os principais motivos pelos quais você deve escolher a camada de serviço de Uso Geral de Próxima geração em vez da camada de Finalidade Geral são:
- Melhor desempenho para o mesmo custo de base
- Latência, taxa de transferência e IOPS melhoradas
- Maior capacidade de armazenamento
- Mais flexibilidade para a sua computação
- Você precisa de mais de 100 bancos de dados para uma única instância
- Você precisa de mais de 16 TB de armazenamento reservado
Negócios Críticos
O modelo de camada de serviço crítica para os negócios é baseado num cluster de processos do motor de base de dados. Este modelo de arquitetura utiliza um quórum de nós permanentemente disponíveis do motor do banco de dados para minimizar os impactos no desempenho da sua carga de trabalho, mesmo durante as operações 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 motor de base de dados do SQL Server quanto os arquivos subjacentes .mdf/.ldf são colocados no mesmo nó, com armazenamento SSD conectado localmente, proporcionando baixa latência na sua carga de trabalho. A alta disponibilidade é implementada usando tecnologia semelhante aos grupos de disponibilidade do SQL Server Always On.
Cada instância é um cluster de nós do motor de base de dados que contém cópias de todos os bancos de dados na instância. Há um banco de dados primário acessível para as cargas de trabalho do cliente e três bancos de dados secundários que contêm cópias dos dados, preparados para serem usados em caso de falha. 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 base de dados do SQL Server – uma réplica secundária torna-se a réplica primária e uma nova réplica secundária é criada para garantir que haja réplicas suficientes no cluster. A carga de trabalho é redirecionada automaticamente para o novo nó primário.
Além disso, o cluster Business Critical tem uma capacidade interna de expansão de leitura integrada que oferece uma réplica gratuita somente leitura, usada para executar consultas somente leitura (como relatórios) que não afetarão o desempenho da carga de trabalho na 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 I/O – cargas de trabalho que precisam de uma resposta rápida da camada de armazenamento (1-2 milissegundos em média) devem usar o nível crítico para os negócios.
- Carga de trabalho com relatórios e consultas analíticas que podem ser redirecionadas para a réplica secundária gratuita de apenas leitura.
- 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 utiliza réplicas de bases de dados em segundo plano, o serviço tira partido do reparo automático de páginas disponível com espelhamento de e grupos de disponibilidade para ajudar a mitigar a corrupção dos 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 Business Critical em uma configuração de zona de multidisponibilidade fornece resiliência a falhas zonais e um SLA de maior disponibilidade.
de recuperação geográfica rápida - Se um de grupo de failover de 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% de horas implantadas.
Ao especificar a camada de serviço em modelos ou scripts, a camada é fornecida usando seu nome. Aplica-se o seguinte quadro:
| Equipamento | Designação |
|---|---|
| Finalidade Geral | Finalidade Geral |
| Negócios Críticos | Negócio Crítico |
Alta disponibilidade
Por padrão, a Instância Gerenciada SQL do Azure alcança disponibilidade por meio de redundância local, assegurando que a sua instância esteja disponível durante operações de manutenção, interrupções no data center e outros problemas relacionados ao motor do banco de dados SQL. No entanto, para minimizar uma possível interrupção em uma zona inteira que afete seus dados, você pode obter de alta disponibilidade habilitando redundância de zona. Sem redundância de zona, os failovers acontecem localmente no mesmo data center, o que pode resultar na indisponibilidade da instância até que a interrupção seja resolvida - a única maneira de recuperar é por meio de uma solução de recuperação de desastres, como por meio de um grupo de failover
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 especificações e limitações de configuração de hardware, consulte Características de configuração de hardware.
Na sys.dm_user_db_resource_governance visualização de 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).
Selecione 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 SQL.
Na guia Noções básicas, selecione o link Configurar banco de dados na seção Computação + armazenamento, e depois selecione o hardware desejado.
Para alterar o hardware de uma Instância Gerenciada SQL existente
Na página Instância Gerenciada SQL, selecione Computação + armazenamento em Configurações :
Na página Computação + Armazenamento, pode-se modificar o hardware em geração de hardware utilizando os controles deslizantes para vCores e armazenamento.
Ao especificar o parâmetro de hardware em modelos ou scripts, o hardware é fornecido usando seu nome. Aplica-se o seguinte quadro:
| Equipamento | Designação |
|---|---|
| Série Standard (Gen5) | Gen5 |
| Série Premium | G8IM |
| Série premium otimizada para memória | G8IH |
Nomes de SKU
Observação
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:
| Referência de Produto | Camada de serviço | Equipamento |
|---|---|---|
| GP_Gen5 | Finalidade Geral | Série-padrão |
| GP_G8IM | Finalidade Geral | Série Premium |
| GP_G8IH | Finalidade Geral | Série Premium otimizada para desempenho de memória |
| BC_Gen5 | Negócios Críticos | Série-padrão |
| BC_G8IM | Negócios Críticos | Série Premium |
| BC_G8IH | Negócios Críticos | Série Premium otimizada para desempenho de 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 otimizado para memória da série premium encontra-se em fase de pré-visualização e tem uma disponibilidade limitada por região. Para obter mais informações, consulte limites de recursos do SQL Managed Instance do Azure.