Muita RAM livre, NVMe Intel P4500 e tudo extremamente lento - a história da adição malsucedida de uma partição swap

Neste artigo falarei sobre uma situação que ocorreu recentemente com um dos servidores da nossa nuvem VPS, que me deixou perplexo por várias horas. Tenho configurado e solucionado problemas de servidores Linux há cerca de 15 anos, mas este caso não se encaixa na minha prática - fiz várias suposições falsas e fiquei um pouco desesperado antes de poder determinar corretamente a causa do problema e resolvê-lo .

Preâmbulo

Operamos uma nuvem de médio porte, que construímos em servidores padrão com a seguinte configuração - 32 núcleos, 256 GB de RAM e um drive PCI-E Intel P4500 NVMe de 4 TB. Gostamos muito dessa configuração porque ela elimina a necessidade de se preocupar com a sobrecarga de E/S, fornecendo a restrição correta no nível do tipo de instância de VM. Porque NVMe Intel P4500 tem um desempenho impressionante, podemos fornecer simultaneamente provisionamento completo de IOPS para máquinas e armazenamento de backup para um servidor de backup com zero IOWAIT.

Somos um daqueles velhos crentes que não usam SDN hiperconvergente e outras coisas elegantes e modernas para armazenar volumes de VM, acreditando que quanto mais simples o sistema, mais fácil será solucioná-lo nas condições de “o guru principal se foi para as montanhas." Como resultado, armazenamos volumes de VM no formato QCOW2 em XFS ou EXT4, que é implantado sobre LVM2.

Também somos forçados a usar o QCOW2 pelo produto que usamos para orquestração - Apache CloudStack.

Para realizar um backup, tiramos uma imagem completa do volume como um instantâneo LVM2 (sim, sabemos que os instantâneos LVM2 são lentos, mas o Intel P4500 também nos ajuda aqui). Nós fazemos lvmcreate -s .. e com a ajuda dd enviamos a cópia de backup para um servidor remoto com armazenamento ZFS. Aqui ainda somos um pouco progressistas - afinal, o ZFS pode armazenar dados em formato compactado e podemos restaurá-los rapidamente usando DD ou obtenha volumes de VM individuais usando mount -o loop ....

Você pode, é claro, remover não a imagem completa do volume LVM2, mas montar o sistema de arquivos no RO e copiar as próprias imagens QCOW2, no entanto, nos deparamos com o fato de que o XFS ficou ruim com isso, e não imediatamente, mas de forma imprevisível. Realmente não gostamos quando os hosts do hipervisor “travam” repentinamente nos finais de semana, à noite ou nos feriados devido a erros que não estão claros quando ocorrerão. Portanto, para XFS não usamos montagem de snapshot em RO para extrair volumes, simplesmente copiamos todo o volume LVM2.

A velocidade do backup para o servidor de backup é determinada, no nosso caso, pelo desempenho do servidor de backup, que é de cerca de 600-800 MB/s para dados incompressíveis; um outro limitador é o canal de 10 Gbit/s com o qual o servidor de backup está conectado para o aglomerado.

Nesse caso, cópias de backup de 8 servidores hipervisores são carregadas simultaneamente em um servidor de backup. Assim, os subsistemas de disco e rede do servidor de backup, sendo mais lentos, não permitem sobrecarregar os subsistemas de disco dos hosts hipervisores, uma vez que eles simplesmente não são capazes de processar, digamos, 8 GB/s, que os hosts hipervisores podem facilmente produzir.

O processo de cópia acima é muito importante para a história futura, incluindo os detalhes - usando um drive Intel P4500 rápido, usando NFS e, provavelmente, usando ZFS.

História de backup

Em cada nó do hipervisor, temos uma pequena partição SWAP de 8 GB e “lançamos” o próprio nó do hipervisor usando DD da imagem de referência. Para o volume do sistema em servidores, usamos 2xSATA SSD RAID1 ou 2xSAS HDD RAID1 em um controlador de hardware LSI ou HP. Em geral, não nos importamos com o que está dentro, já que o volume do nosso sistema opera em modo “quase somente leitura”, exceto para SWAP. E como temos muita RAM no servidor e é 30-40% gratuito, não pensamos em SWAP.

Processo de backup. Esta tarefa é mais ou menos assim:

#!/bin/bash

mkdir -p /mnt/backups/volumes

DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)

lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snap

Note-se a ionice -c3, na verdade, isso é completamente inútil para dispositivos NVMe, já que o agendador IO para eles está definido como:

cat /sys/block/nvme0n1/queue/scheduler
[none] 

Porém, temos vários nós legados com RAIDs SSD convencionais, para eles isso é relevante, então eles estão migrando COMO ESTÁ. No geral, este é apenas um trecho de código interessante que explica a futilidade ionice no caso de tal configuração.

Preste atenção na bandeira iflag=direct para DD. Usamos IO direto ignorando o cache do buffer para evitar a substituição desnecessária de buffers de IO durante a leitura. No entanto, oflag=direct não o fazemos porque encontramos problemas de desempenho do ZFS ao usá-lo.

Temos usado esse esquema com sucesso há vários anos, sem problemas.

E então começou... Descobrimos que um dos nós não tinha mais backup e o anterior estava rodando com um IOWAIT monstruoso de 50%. Ao tentar entender por que a cópia não ocorre, encontramos o seguinte fenômeno:

Volume group "images" not found

Começamos a pensar “chegou o fim do Intel P4500”, porém, antes de desligar o servidor para substituir o drive, ainda foi necessário realizar um backup. Corrigimos o LVM2 restaurando os metadados de um backup do LVM2:

vgcfgrestore images

Lançamos um backup e vimos esta pintura a óleo:

Novamente ficamos muito tristes - estava claro que não poderíamos viver assim, pois todos os VPSs sofreriam, o que significa que nós também sofreríamos. O que aconteceu não está completamente claro - iostat mostrou IOPS lamentável e o IOWAIT mais alto. Não houve outras ideias além de “vamos substituir o NVMe”, mas um insight ocorreu bem a tempo.

Análise da situação passo a passo

Revista histórica. Alguns dias antes, neste servidor foi necessário criar um grande VPS com 128 GB de RAM. Parecia haver memória suficiente, mas por segurança, alocamos outros 32 GB para a partição swap. O VPS foi criado, completou com sucesso a sua tarefa e o incidente foi esquecido, mas a partição SWAP permaneceu.

Recursos de configuração. Para todos os servidores em nuvem, o parâmetro vm.swappiness foi definido como padrão 60. E o SWAP foi criado no SAS HDD RAID1.

O que aconteceu (de acordo com os editores). Ao fazer backup DD produziu muitos dados de gravação, que foram colocados em buffers de RAM antes de serem gravados no NFS. Núcleo do sistema, guiado por políticas swappiness, estava movendo muitas páginas de memória VPS para a área de troca, que estava localizada em um volume HDD RAID1 lento. Isso fez com que o IOWAIT crescesse muito fortemente, mas não devido ao IO NVMe, mas devido ao IO HDD RAID1.

Como o problema foi resolvido. A partição swap de 32 GB foi desativada. Isso levou 16 horas; você pode ler separadamente sobre como e por que o SWAP desliga tão lentamente. As configurações foram alteradas swappiness para um valor igual a 5 por toda a nuvem.

Como isso poderia não acontecer?. Em primeiro lugar, se o SWAP estivesse em um dispositivo SSD RAID ou NVMe, e em segundo lugar, se não houvesse um dispositivo NVMe, mas um dispositivo mais lento que não produzisse tal volume de dados - ironicamente, o problema acontecia porque aquele NVMe é muito rápido.

Depois disso, tudo começou a funcionar como antes - com zero IOWAIT.

Fonte: habr.com