A Instância Gerenciada do Banco de Dados SQL do Azure tornou-se amplamente disponível no final de 2018. Desde então, muitas organizações começaram a migrar para a Instância Gerenciada para obter os benefícios de um ambiente gerenciado. As organizações estão aproveitando os backups gerenciados, muitos recursos de segurança integrados, um SLA de tempo de atividade de 99,99% e um ambiente sempre atualizado, onde não são mais responsáveis por corrigir o SQL Server ou o sistema operacional.
Um tamanho não sempre cabe tudo. A instância gerenciada fornece duas camadas para desempenho. O Propósito Geral A camada é projetada para aplicativos com requisitos típicos de desempenho e latência de E/S e fornece HA integrado. O Crítico para os Negócios A camada foi projetada para aplicativos que exigem baixa latência de E/S e requisitos de HA mais altos. O Business Critical também fornece dois secundários não legíveis e um secundário legível. O secundário legível é uma ótima maneira de distribuir a carga de trabalho do primário, o que pode diminuir o nível de serviço necessário para o primário, diminuindo o gasto geral da instância.
Quando a instância gerenciada foi lançada, você podia escolher entre os processadores Gen4 e Gen5. Gen4 ainda é descrito na documentação, mas essa opção não está disponível agora. Para este artigo, abordarei apenas as configurações usando os processadores Gen5.
Cada camada de serviço suporta de 4 a 80 CPUs lógicas — também conhecidas como núcleos virtuais ou vCores. A memória é alocada em aproximadamente 5,1 GB por vCore. O Uso Geral fornece até 8 TB de armazenamento Azure Blob de alto desempenho, enquanto o Business Critical fornece até 4 TB de armazenamento SSD local super-rápido.
Memória
Com apenas 5,1 GB de memória por vCore, uma instância com menos vCores pode ter problemas. As opções para configurações de vCore são 4, 8, 16, 24, 32, 40, 64 e 80 vCores. Se você fizer as contas em cada uma das opções de vCore (
(number of vCores) × (5.1 GB) ), você obterá as seguintes combinações de núcleo/memória:4 vCores = 20.4 GB 8 vCores = 40.8 GB 16 vCores = 81.6 GB 24 vCores = 122.4 GB 32 vCores = 163.2 GB 40 vCores = 204.0 GB 64 vCores = 326.4 GB 80 vCores = 408.0 GB
Para muitas organizações que ajudei na transição do local para a instância gerenciada, observei uma redução significativa na memória. As configurações locais típicas seriam 4 vCores e 32 GB de memória ou 8 vCores e 64 GB. Ambos representam uma redução de mais de 30% na memória. Se a instância já estava sob pressão de memória, isso pode causar problemas. Na maioria dos casos, conseguimos otimizar a instância local para ajudar a aliviar a pressão da memória antes de migrar para a instância gerenciada, mas em alguns casos, o cliente teve que optar por uma instância vCore mais alta para aliviar a pressão da memória .
Armazenamento
O armazenamento é um pouco mais difícil de planejar e fazer considerações, devido à necessidade de considerar vários fatores. Para armazenamento, você precisa levar em conta o requisito geral de armazenamento para o tamanho do armazenamento e as necessidades de E/S. Quantos GBs ou TBs são necessários para a instância do SQL Server e quão rápido o armazenamento precisa ser? Quantas IOPS e quanta taxa de transferência a instância local está usando? Para isso, você deve basear sua carga de trabalho atual usando perfmon para capturar MB/s médios e máximos e/ou tirar instantâneos de sys.dm_io_virtual_file_stats para capturar a utilização da taxa de transferência. Isso lhe dará uma ideia de que tipo de E/S e taxa de transferência você precisa no novo ambiente. Vários clientes com quem trabalhei perderam essa parte vital do planejamento da migração e encontraram problemas de desempenho devido à seleção de um nível de instância que não suportava sua carga de trabalho.
Isso é fundamental para a linha de base porque, com servidores locais, é comum ter armazenamento fornecido de uma SAN super-rápida com recursos de alta taxa de transferência para máquinas virtuais de tamanho menor. No Azure, seus limites de IOPS e taxa de transferência são determinados pelo tamanho do nó de computação e, no caso de Gerenciar instância, é determinado pelo número de vCores alocados. Para uso geral, há um limite de 30 a 40 mil IOPS por instância ou de 500 a 12.500 IOPS por arquivo, dependendo do tamanho do arquivo. A taxa de transferência por arquivo também é baseada no tamanho que varia de 100 MiB/s para arquivos de até 128 GB e até 480 MiB/s para arquivos de 4 TB e maiores. Em Business Critical, o IOPS varia de 5,5K a 110K por instância ou 1.375 IOPS por vCore.
Os consumidores também devem considerar a taxa de transferência de gravação de log para a instância. O uso geral é de 3 MB/s por vCore com um máximo de 22 MB/s para a instância e o Business Critical é de 4 MB/s por vCore com um máximo de 48 MB/s para toda a instância. Em minha experiência de trabalho com clientes, muitos excederam em muito esses limites de taxa de transferência de gravação. Para alguns, foi um espetáculo e, para outros, eles conseguiram otimizar e modificar seu sistema para diminuir a carga.
Além de precisar conhecer a taxa de transferência geral e os requisitos de E/S, o tamanho do armazenamento também está vinculado ao número de vCores escolhidos. Para Uso Geral:
4 vCores = 2 TB max
8 - 80 vCores = 8 TB max
Para Negócios Críticos:
4 – 16 vCores = 1 TB
24 vCores = 2 TB
32 - 80 vCores = 4 TB
Para uso geral, quando você chegar a 8 vCores, poderá maximizar o armazenamento disponível, o que funciona bem para quem precisa apenas de uso geral. Mas quando você precisa de Business Critical, as coisas podem ser mais desafiadoras. Trabalhei com muitos clientes que têm vários TBs alocados para VMs com 4, 8, 16 e 24 processadores lógicos. Para qualquer um desses clientes, eles teriam que aumentar pelo menos 32 vCores apenas para atender aos requisitos de armazenamento, uma opção cara. O Banco de Dados SQL do Azure tem um problema semelhante com o tamanho máximo do banco de dados e a Microsoft apresentou uma opção de hiperescala. Esperamos que isso se torne uma opção para a instância gerenciada em algum momento para abordar os limites de armazenamento de maneira semelhante.
O tamanho do tempdb também está correlacionado ao número de vCores. Na camada de uso geral, você obtém 24 GB por vCore (até 1.920 GB) para os arquivos de dados, com um limite de tamanho de arquivo de log tempdb de 120 GB. Para a camada Business Critical, o tempdb pode crescer até o tamanho de armazenamento de instâncias atualmente disponível.
OLTP na memória
Para aqueles que estão atualmente aproveitando o OLTP na memória (ou planejam), observe que ele só é compatível com a camada de serviço Business Critical. A quantidade de espaço disponível para tabelas na memória também é limitada por vCores:
4 vCores = 3.14 GB
8 vCores = 6.28 GB
16 vCores = 15.77 GB
24 vCores = 25.25 GB
32 vCores = 37.94 GB
40 vCores = 52.23 GB
64 vCores = 99.90 GB
80 vCores = 131.86 GB
Conclusão
Ao planejar uma migração para a Instância Gerenciada de SQL do Azure, há várias considerações a serem consideradas antes de decidir migrar. Primeiro, você precisa entender completamente seus requisitos de memória, CPU e armazenamento, pois isso determinará o tamanho da instância. Tão importante quanto é saber quais são seus requisitos de E/S de armazenamento. O IOPS e a taxa de transferência para a camada de uso geral estão diretamente vinculados aos vCores e ao tamanho dos arquivos do banco de dados. Para Business Critical está vinculado ao número de vCores. Se você tiver uma carga de trabalho muito intensa de E/S, o Business Critical é a camada de serviço mais atraente, pois fornece números mais altos de IOPS e taxa de transferência. O desafio com o Business Critical é a capacidade de armazenamento mais baixa e o suporte apenas a 1 TB para toda a instância até 16 vCores.
Com planejamento adequado e possível desconsolidação de instâncias maiores para instâncias gerenciadas menores, essa oferta pode ser uma opção de migração muito viável para muitas organizações. O atrativo são os benefícios de ter backups gerenciados, HA integrado com um SLA de 99,99%, recursos e opções de segurança adicionados e não ter que se preocupar em aplicar patches em um SO ou instância do SQL Server.
