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

  • Artigo

Cuidado

Este artigo faz referência ao CentOS, uma distribuição do Linux que está se aproximando do status de EOL (fim da vida útil). Considere seu uso e planeje adequadamente. Para obter mais informações, veja as Diretrizes sobre fim da vida útil do CentOS.

Aplica-se a: ✔️ VMs do Linux ✔️ Conjuntos de dimensionamento uniformes

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

Vários builds estão disponíveis no Azure Marketplace devido ao trabalho com parceiros no Linux. Esses builds são otimizados para o desempenho das séries Lsv3, Lasv3 e Lsv2. Os builds 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
  • 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 para as VMs.

Arquitetura do chipset AMD EYPC™

As VMs das séries Lasv3 e Lsv2 usam processadores de servidor AMD EPYC™ com base na microarquitetura do Zen. A AMD desenvolveu a Infinity Fabric (IF) para EPYC™ como interconexão escalonável para seu modelo NUMA que poderia ser usado para comunicações na matriz, no pacote e em vários pacotes. Em comparação com o QPI (Quick-Path Interconnect) e o UPI (Ultra-Path Interconnect) usados em processadores em matriz monolítica modernos da Intel, a arquitetura de matriz pequena de vários NUMA do AMD pode proporcionar benefícios de desempenho, bem como desafios. O impacto real da largura de banda de memória e das restrições de latência pode 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, observe que a rede acelerada estará 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 desempenho máximo, execute vários trabalhos com profundidade de fila profunda por dispositivo.
  • Evite misturar comandos de administrador do NVMe (por exemplo, consulta de informações SMART do NVMe etc.) com os comandos de E/S do NVMe durante as cargas de trabalho ativas. Os dispositivos NVMe da série Lsv2, Lsv3 e Lasv3 são apoiados pela tecnologia Hyper-V NVMe Direct, que muda para o "modo lento" sempre que qualquer comando de administração do NVMe estiver pendente. Os usuários das séries Lsv3, Lasv3 e Lsv2 poderão ter uma queda significativa no desempenho de E/S do NVMe, se isso acontecer.
  • Os usuários da série Lsv2 não devem confiar nas informações NUMA do dispositivo (todas 0) relatadas de dentro da VM para unidades de dados para decidir a afinidade NUMA para seus aplicativos. A maneira recomendada para melhor desempenho é distribuir cargas de trabalho entre CPUs, se possível.
  • A profundidade máxima de fila com suporte por par de filas de E/S para o dispositivo NVMe da VM das séries Lsv3, Lasv3 e Lsv2 é 1024. Os usuários da série Lsv3, Lasv3 e Lsv2 devem limitar suas cargas de trabalho de parâmetro de comparação (sintéticas) para a profundidade de fila de 1024, ou inferior, para evitar o disparo 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 de NVMe brutos sem particionamento, nenhum sistema de arquivos, nenhuma configuração de RAID etc. Antes de iniciar uma sessão de teste, verifique se a configuração está em um estado novo/limpo conhecido executando blkdiscard em cada um dos dispositivos NVMe. Para obter o desempenho mais consistente durante o parâmetro de comparação, é recomendável pré-condicionar os dispositivos NVMe antes de testar emitindo gravações aleatórias em todos os LBAs de todos os dispositivos duas vezes, conforme definido na Especificação de Teste de Desempenho Corporativo do Armazenamento de Estado Sólido do SNIA.

Como utilizar o armazenamento de NVMe local

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

Também haverá casos em que a VM precisará ser movida para um computador host diferente, por exemplo, durante uma operação de manutenção planejada. As operações de manutenção planejada e algumas falhas de hardware podem ser antecipadas com os Eventos Agendados. Use os Eventos Agendados para manter-se atualizado das operações previstas de manutenção e recuperação.

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 precisarão ser ressincronizados (novamente, com todos os dados no host antigo sendo apagados com segurança). Isso ocorre porque as VMs das séries Lsv3, Lasv3 e Lsv2 atualmente não dão suporte à migração ao vivo no disco NVMe local.

Há dois modos de manutenção planejada.

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

  • A VM é movida para um host atualizado durante uma janela de 30 dias.
  • Os dados de armazenamento local das séries 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 executa a manutenção controlada por ele ou no caso de 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 um congelamento ou reinicialização da VM.
  • Os dados de armazenamento local das séries Lsv3, Lasv3 e Lsv2 podem ser perdidos; portanto, é recomendável fazer backup dos dados antes do evento.

Para qualquer evento de serviço futuro, use o processo de manutenção controlada para selecionar um horário mais conveniente para a atualização. Antes do evento, você pode fazer backup de seus dados no armazenamento Premium. Após a conclusão do evento de manutenção, você poderá retornar seus dados para o armazenamento de NVMe local das VMs das séries Lsv3, Lasv3 e Lsv2 atualizadas.

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 (parada sem desalocação).
  • A maioria das operações de serviço de manutenção planejada.

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

  • A VM é reimplantada, parada (desalocada) ou excluída por você.
  • A VM se torna não íntegra e tem de reparar o serviço para outro nó devido a um problema de hardware.
  • Um pequeno número de operações de serviço de manutenção planejada que exige que a VM seja realocada para outro host para manutenção.

Perguntas frequentes

A seguir estão as perguntas frequentes sobre essas séries.

Como começo a implantação de VMs da série L?

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

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

Se uma falha de disco for detectada no nó de hardware, o hardware estará em um estado de falha. Quando isso ocorre, todas as VMs no nó são automaticamente desalocadas e movidas para um nó íntegro. Para VMs 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?

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

Próximas etapas

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