Otimize o desempenho em VMs Linux das séries Lsv3, Lasv3 e Lsv2

Artigo
02/17/2024

Atenção

Este artigo faz referência ao CentOS, uma distribuição Linux que está se aproximando do status de Fim da Vida Útil (EOL). Por favor, considere o seu uso e planeje de acordo. Para obter mais informações, consulte as diretrizes de Fim da Vida Útil do CentOS.

Aplica-se a: ✔️ Linux VMs ✔️ Conjuntos de escala uniforme

As Máquinas Virtuais do Azure (VMs do Azure) das séries Lsv3, Lasv3 e Lsv2 dão suporte a várias cargas de trabalho que precisam de alta E/S e taxa de transferência no armazenamento local em uma ampla variedade de aplicativos e setores. A série L é ideal para Big Data, SQL, bancos de dados NoSQL, data warehousing e grandes bancos de dados transacionais, incluindo Cassandra, MongoDB, Cloudera e Redis.

Várias compilações estão disponíveis no Azure Marketplace devido ao trabalho com parceiros no Linux. Essas compilações são otimizadas para o desempenho das séries Lsv3, Lasv3 e Lsv2. As compilações disponíveis incluem as seguintes versões e versões posteriores de:

Ubuntu 16.04
RHEL 8.0 e clones, incluindo CentOS, Rocky Linux e Alma Linux
Debian 9
SUSE Linux 15 [en]
Oracle Linux 8.0

Este artigo fornece dicas e sugestões para garantir que suas cargas de trabalho e aplicativos alcancem o desempenho máximo projetado nas VMs.

Arquitetura do chipset AMD EPYC™

As VMs das séries Lasv3 e Lsv2 usam processadores de servidor AMD EPYC™ baseados na microarquitetura Zen. A AMD desenvolveu o Infinity Fabric (IF) para EPYC™ como interconexão escalável para seu modelo NUMA que pode ser usado para comunicações on-die, on-package e multi-package. Em comparação com o QPI (Quick-Path Interconnect) e o UPI (Ultra-Path Interconnect) usados nos modernos processadores monolíticos da Intel, a arquitetura de matriz pequena NUMA da AMD pode trazer benefícios e desafios de desempenho. Os efeitos reais das restrições de largura de banda e latência da memória podem variar dependendo do tipo de cargas de trabalho em execução.

Dicas para maximizar o desempenho

Se você estiver carregando um GuestOS Linux personalizado para sua carga de trabalho, a Rede Acelerada será desativada por padrão. Se você pretende habilitar a Rede Acelerada, habilite-a no momento da criação da VM para obter o melhor desempenho.
Para obter o máximo desempenho, execute vários trabalhos com profundidade de fila profunda por dispositivo.
Evite misturar comandos de administração NVMe (por exemplo, consulta de informações NVMe SMART, etc.) com comandos de E/S NVMe durante cargas de trabalho ativas. Os dispositivos NVMe Lsv3, Lasv3 e Lsv2 são apoiados pela tecnologia Hyper-V NVMe Direct, que muda para o "modo lento" sempre que algum comando de administração NVMe estiver pendente. Os usuários de Lsv3, Lasv3 e Lsv2 podem ver uma queda drástica no desempenho de E/S NVMe se isso acontecer.
Não é recomendado que os usuários do Lsv2 confiem nas informações NUMA do dispositivo (todas as 0) relatadas de dentro da VM para unidades de dados para decidir a afinidade NUMA para seus aplicativos. A maneira recomendada para um melhor desempenho é distribuir cargas de trabalho entre CPUs, se possível.
A profundidade máxima de fila suportada por par de filas de E/S para dispositivos NVMe de VM Lsv3, Lasv3 e Lsv2 é 1024. Recomenda-se que os usuários de Lsv3, Lasv3 e Lsv2 limitem suas cargas de trabalho de benchmarking (sintético) à profundidade da fila 1024 ou inferior para evitar o acionamento de condições completas da fila, o que pode reduzir o desempenho.
O melhor desempenho é obtido quando a E/S é feita diretamente para cada um dos dispositivos NVMe brutos sem particionamento, sem sistemas de arquivos, sem configuração RAID, etc. Antes de iniciar uma sessão de teste, verifique se a configuração está em um estado fresco/limpo conhecido executando blkdiscard em cada um dos dispositivos NVMe. Para obter o desempenho mais consistente durante o benchmarking, é recomendável pré-condicionar os dispositivos NVMe antes do teste, emitindo gravações aleatórias em todos os LBAs dos dispositivos duas vezes, conforme definido na Especificação de teste de desempenho empresarial de armazenamento de estado sólido SNIA.

Utilizando armazenamento NVMe local

O armazenamento local no disco NVMe de 1,92 TB em todas as VMs Lsv3, Lasv3 e Lsv2 é efêmero. Durante uma reinicialização padrão bem-sucedida da VM, os dados no disco NVMe local persistem. Os dados não persistem no NVMe se a VM for reimplantada, deslocalizada ou excluída. Os dados não persistem se outro problema fizer com que a VM ou o hardware em que ela está sendo executada não se torne íntegro. Quando o cenário acontece, todos os dados no host antigo são apagados com segurança.

Também há casos em que a VM precisa ser movida para uma máquina host diferente, por exemplo, durante uma operação de manutenção planejada. Operações de manutenção planejadas e algumas falhas de hardware podem ser antecipadas com Eventos Agendados. Use os Eventos Agendados para se manter atualizado sobre quaisquer operações de manutenção e recuperação previstas.

No caso de um evento de manutenção planejada exigir que a VM seja recriada em um novo host com discos locais vazios, os dados precisam ser ressincronizados (novamente, com todos os dados no host antigo sendo apagados com segurança). Esse cenário ocorre porque as VMs das séries Lsv3, Lasv3 e Lsv2 atualmente não oferecem suporte à migração ao vivo no disco NVMe local.

Existem dois modos de manutenção planeada.

Manutenção padrão controlada pelo cliente de VM

A VM é movida para um host atualizado durante uma janela de 30 dias.
Os dados de armazenamento local Lsv3, Lasv3 e Lsv2 podem ser perdidos, portanto, é recomendável fazer backup dos dados antes do evento.

Manutenção automática

Ocorre se o cliente não executar a manutenção controlada pelo cliente ou devido a procedimentos de emergência, como um evento de dia zero de segurança.
Destina-se a preservar os dados do cliente, mas há um pequeno risco de congelamento ou reinicialização de uma VM.
Os dados de armazenamento local Lsv3, Lasv3 e Lsv2 podem ser perdidos, portanto, é recomendável fazer backup dos dados antes do evento.

Para quaisquer eventos de serviço futuros, use o processo de manutenção controlada para selecionar o horário mais conveniente para a atualização. Antes do evento, faça backup de seus dados em armazenamento premium. Após a conclusão do evento de manutenção, você pode retornar seus dados para o armazenamento NVMe local de VMs Lsv3, Lasv3 e Lsv2 atualizado.

Os cenários que mantêm dados em discos NVMe locais incluem:

A VM está em execução e íntegra.
A VM é reinicializada no local (por você ou pelo Azure).
A VM é pausada (interrompida sem deslocalização).
A maioria das operações de manutenção planejadas.

Os cenários que apagam dados com segurança para proteger o cliente incluem:

A VM é reimplantada, interrompida (deslocalizada) ou excluída (por você).
A VM torna-se não íntegra e tem que reparar o serviço para outro nó devido a um problema de hardware.
Algumas das operações de manutenção planejadas que exigem que a VM seja realocada para outro host para manutenção.

Perguntas mais frequentes

Seguem-se perguntas frequentes sobre estas séries.

Como começo a implantar VMs da série L?

Como qualquer outra VM, use o Portal, a CLI do Azure ou o PowerShell para criar uma VM.

Uma única falha de disco NVMe faz com que todas as VMs no host falhem?

Se uma falha de disco for detetada no nó de hardware, o hardware estará em um estado de falha. Quando esse problema ocorre, todas as VMs no nó são automaticamente desalocadas e movidas para um nó íntegro. Para VMs das séries Lsv3, Lasv3 e Lsv2, esse problema significa que os dados do cliente no nó com falha também são apagados com segurança. O cliente precisa recriar os dados no novo nó.

Preciso alterar as configurações de blk_mq?

O RHEL/CentOS 7.x usa automaticamente o blk-mq para os dispositivos NVMe. Não são necessárias alterações de configuração ou definições.

Próximos passos

Consulte as especificações de todas as VMs otimizadas para desempenho de armazenamento no Azure