Migrar uma instância do SQL Server local para uma máquina virtual do Azure (VM) é um método comum para migrar para o Azure. Os profissionais de TI estão familiarizados com o escopo do tamanho das VMs em relação à vCPU, memória e capacidade de armazenamento. A Microsoft oferece vários tipos e tamanhos de VM para as necessidades de uma organização. Você verá os tipos referenciados como
Family no Portal do Azure ao dimensionar uma VM. Tipos e tamanhos de VM
A Microsoft ajudou a simplificar as coisas criando vários tipos de máquinas virtuais. Os tipos são voltados para definir as máquinas por finalidade. Os vários tipos são:
- Uso geral – Proporção balanceada de CPU/memória, bancos de dados pequenos e médios
- Otimizado para computação – alta proporção de CPU para memória, servidores da Web de tráfego médio e servidores de aplicativos
- Memória otimizada – alta proporção de memória para CPU, servidores de banco de dados relacionais, caches médios a grandes e análises na memória
- Armazenamento otimizado – Alta taxa de transferência de disco e E/S
- GPU – renderização gráfica pesada e edição de vídeo
- Computação de alto desempenho – Máquinas virtuais de CPU mais rápidas e poderosas
Dentro de cada tipo/família existem vários tamanhos para escolher. Os tamanhos oferecem opções para o número de vCPUs, RAM e discos de dados. O número de discos de dados determinará o IOPS máximo (IOPS significa operações de entrada/saída por segundo.) e o tamanho geral determinará a quantidade de armazenamento temporário disponível. Certos tamanhos também dão suporte ao armazenamento premium, que deve ser um requisito para um SQL Server de produção.
Opções de imagem de VM
Ao selecionar uma imagem para o SQL Server, você tem várias opções. Você pode optar por selecionar apenas o SO, como Linux ou Windows, ou pode optar por selecionar uma imagem com o SO e o SQL Server já instalados. Atualmente prefiro escolher a imagem apenas com o SO para poder instalar o SQL Server e configurá-lo do jeito que eu gosto. Quando você escolhe a imagem da galeria com o SQL Server pré-instalado, todos os componentes incluídos no ISO dessa versão são instalados e nem sempre preciso do Integration Services ou do Analysis Services instalado.
Considerações de dimensionamento de VM
A seleção de uma VM do Azure pode parecer simples, com a escolha de um tamanho com base no número de vCPU, memória e armazenamento suficiente para manter seus bancos de dados, mas vejo clientes com problemas de desempenho relacionados ao armazenamento. A tendência comum é escolher uma VM baseada exclusivamente em vCPU, memória e capacidade de armazenamento sem comparar os requisitos atuais de E/S e taxa de transferência. Ao criar uma VM do Azure no Portal do Azure, você pode filtrar as opções com base no seguinte:
- Tamanho
- Geração
- Família
- RAM/memória
- Suporte de armazenamento premium
- Número de vCPU
- Disco efêmero do sistema operacional
Depois de selecionar suas opções de filtro, se houver, você verá uma lista de servidores disponíveis. Na lista, ele exibe o tamanho da VM, oferta, família, vCPU, RAM, número de disco de dados suportado, IOPS máximo, armazenamento temporário (D:), se o disco premium é suportado e custo estimado. Eu filtrei o seguinte no disco premium suportado e tamanho começando com a letra E para otimizar a memória.
O que não é exibido, no entanto, é a quantidade de taxa de transferência permitida por VM. A taxa de transferência mede a taxa de transferência de dados de e para a mídia de armazenamento em megabytes por segundo.
A taxa de transferência pode ser calculada usando a seguinte fórmula
MB/s =IOPS * KB por IO / 1.024
Usando esta fórmula, KB por IO seria o tamanho do seu bloco. Se você estiver formatando seus dados e unidades de log em 64k, a fórmula para as VMs E2s_v3, E4-2s_v3 e E8-2s_v3 com 3.200, 6.400 e 12.800 IOPS seria:
MB/s =3.200 * 64/1.024 ou 200 MB/s
MB/s =6.400 * 64/1.024 ou 400 MB/s
MB/s =12.800 * 64/1.024 ou 800 MB/s
Os cálculos de taxa de transferência com base no IOPS de cada VM com tamanho de bloco de 64k não são tão ruins. Esses números não levam em consideração nenhuma penalidade de gravação para RAID. Eu testei cada uma dessas VMs usando o CrystalDiskMark. Os números que obtive para o rendimento não estavam nem perto do que os cálculos estavam estimando.
Teste comparativo
Provisionei três máquinas virtuais da mesma família, porém de tamanhos diferentes, e cada uma com 2 vCPU. As especificações das máquinas virtuais foram:
- E2s_v3 – 2 vCPU – 16 GB de RAM – 3.200 IOPS – Suporta até 4 discos de dados
- E4-2s_v3 – 2 vCPU – 32 GB de RAM – 6.400 IOPS – Suporta até 8 discos de dados
- E8-2s_v3 – 2 vCPU – 64 GB de RAM – 12.800 IOPS – Suporta até 16 discos de dados
- Disco de dados P60 – SSD Premium – 16.000 IOPS
Em cada VM, provisionei um disco premium P60 com capacidade de 8 TB. Esse disco anunciou 16.000 IOPS que, com um tamanho de bloco de 64k, poderia dar suporte a uma taxa de transferência de 1.000 MBps, no entanto, a documentação do Azure afirma que o disco fornece uma taxa de transferência de 500 MBps.
CrystalDiskMark é uma ferramenta de benchmark de unidade de disco de código aberto para Windows e é baseada na ferramenta Diskspd da Microsoft. A ferramenta mede o desempenho sequencial e aleatório de leituras e gravações.
Na parte superior da ferramenta há alguns menus suspensos. O número 5 é o número de iterações do teste que serão executados. O próximo é 1GiB, este é o tamanho do arquivo de teste. Para um teste de produção real, isso deve ser grande o suficiente para ajudar a evitar atingir o cache. A versão 7.0 suporta um arquivo de até 64 GiB. A última é a unidade na qual você deseja realizar o teste.
Depois de fazer sua seleção, você pode clicar em Todos para iniciar a série de testes. O teste passará por várias operações de leitura/gravação sequenciais e aleatórias. Tenha cuidado se você planeja fazer benchmark de servidores de produção reais. Esse teste sobrecarrega seu disco e pode afetar drasticamente uma carga de trabalho de produção. Após o expediente ou durante uma janela de manutenção seria preferível.
Optei por executar 5 iterações do teste com um arquivo de 32 GiB no disco P60 que era a unidade E:.
A VM E2s_v3 atingiu o máximo de 50 MBps, o que é muito menos do que os 200 MB que calculamos.
A VM E4-2s_v3 atingiu o máximo de 100 MBps em vez de 400 MBps.
A VM E8-2s_v3 atingiu no máximo 200 MBps em vez dos 800 MBps estimados.
Por que diminuir a taxa de transferência?
Com base em meus cálculos anteriores, 3.200 IOPS em um tamanho de bloco de 64k devem produzir uma taxa de transferência de 200 MB, mas não vi números próximos disso até ter um disco de 16.000 IOPS em uma VM que suporta até 12.800 IOPS. O raciocínio é que cada tamanho de VM tem um limite de taxa de transferência. Se você examinar a documentação da família de VMs otimizada para memória, verá que a taxa de transferência máxima de disco sem cache do E2s é de 3.200 IOPS/48 MBps, a taxa de transferência máxima de disco sem cache do E4s é de 6.400 IOPS/96 MBps e a taxa de transferência máxima de disco sem cache do E8s a taxa de transferência é de 12.800 IOPS/192 MBps. Esses números coincidem com os resultados que obtive usando o CrystalDiskMark.
Mesmo que você possa alocar discos muito grandes que tenham bastante IOPS e que suportem números de alta taxa de transferência, o tamanho da VM pode muito bem estar limitando sua taxa de transferência.
A comparação de suas necessidades atuais de taxa de transferência deve ser uma grande prioridade antes de migrar qualquer carga de trabalho do SQL Server para o Azure.
Conclusão
Entendo que o IOPS é uma unidade de medida fornecida pelos fabricantes de discos e fornecedores de armazenamento, e tudo bem. No entanto, quando se trata de testar o armazenamento, tendemos a nos concentrar mais nos números de taxa de transferência. É apenas um problema de matemática, mas a menos que você esteja no negócio de benchmarking de armazenamento e fazendo os cálculos de IOPS para taxa de transferência com base no tamanho do bloco, pode ser confuso.
O que é preocupante para mim é o fato de que a restrição de taxa de transferência não é clara quando você seleciona um tamanho de VM. A unidade de medida para E/S de armazenamento é IOPS. A 3.200 IOPS com um tamanho de bloco de 64k, eu poderia ter cerca de 200 MBps, mas minha VM estava limitada a 48 MBps. Muitos profissionais de TI descobriram que têm problemas de desempenho de disco e dimensionaram seu armazenamento para um disco maior e mais rápido (mais IOPS) esperando melhor desempenho, apenas para descobrir que isso não resolveu o problema. O problema é que o tamanho da VM estava limitando sua taxa de transferência. Escalar para uma VM de tamanho maior resolveria o problema, mas isso tem um custo. No meu exemplo, o E4 custou o dobro do E2, mas dobrou a memória e a taxa de transferência, mantendo a mesma vCPU. O E8 foi o dobro do custo do E4 e dobrou o rendimento e a memória, mantendo a mesma vCPU. Manter a mesma contagem de vCPU significa que eu não teria um aumento no custo da licença principal do SQL Server.
Por fim, você precisa comparar seus requisitos de taxa de transferência atuais e certificar-se de dimensionar a VM do Azure ou qualquer VM adequadamente para suas necessidades. Não se concentre apenas em um benchmark de seu armazenamento local, analise o que sua carga de trabalho precisa e dimensione de acordo.
