Beaucoup de RAM libre, NVMe Intel P4500 et tout est extrêmement lent - l'histoire de l'ajout infructueux d'une partition d'échange

Dans cet article, je vais parler d'une situation survenue récemment avec l'un des serveurs de notre cloud VPS, qui m'a laissé perplexe pendant plusieurs heures. Je configure et dépanne des serveurs Linux depuis environ 15 ans, mais ce cas ne correspond pas du tout à ma pratique - j'ai fait plusieurs fausses hypothèses et j'étais un peu désespéré avant de pouvoir déterminer correctement la cause du problème et le résoudre. .

Préambule

Nous exploitons un cloud de taille moyenne, que nous construisons sur des serveurs standard avec la configuration suivante : 32 cœurs, 256 Go de RAM et un lecteur PCI-E Intel P4500 NVMe de 4 To. Nous aimons vraiment cette configuration car elle élimine le besoin de s'inquiéter de la surcharge d'E/S en fournissant la restriction correcte au niveau du type d'instance de VM. Parce que NVMe Intel P4500 a des performances impressionnantes, nous pouvons simultanément fournir à la fois un provisionnement complet d'IOPS aux machines et un stockage de sauvegarde sur un serveur de sauvegarde avec zéro IOWAIT.

Nous faisons partie de ces vieux croyants qui n'utilisent pas le SDN hyperconvergé et d'autres choses élégantes et à la mode pour les jeunes pour stocker les volumes de VM, estimant que plus le système est simple, plus il est facile de le dépanner dans les conditions de « le gourou principal est parti ». Aux montagnes." En conséquence, nous stockons les volumes de VM au format QCOW2 dans XFS ou EXT4, qui est déployé au-dessus de LVM2.

Nous sommes également obligés d'utiliser QCOW2 par le produit que nous utilisons pour l'orchestration - Apache CloudStack.

Pour effectuer une sauvegarde, nous prenons une image complète du volume sous forme d'instantané LVM2 (oui, nous savons que les instantanés LVM2 sont lents, mais l'Intel P4500 nous aide ici aussi). Nous faisons lvmcreate -s .. et avec l'aide dd nous envoyons la copie de sauvegarde à un serveur distant avec stockage ZFS. Ici, nous sommes encore un peu progressistes - après tout, ZFS peut stocker des données sous forme compressée et nous pouvons les restaurer rapidement en utilisant DD ou obtenez des volumes de VM individuels en utilisant mount -o loop ....

Vous pouvez bien sûr non pas supprimer l'image complète du volume LVM2, mais monter le système de fichiers dans le RO et copiez les images QCOW2 elles-mêmes, cependant, nous avons été confrontés au fait que XFS est devenu mauvais à cause de cela, et pas immédiatement, mais de manière imprévisible. Nous n'aimons vraiment pas que les hôtes de l'hyperviseur « restent » soudainement le week-end, la nuit ou les jours fériés en raison d'erreurs dont on ne sait pas exactement quand elles se produiront. Par conséquent, pour XFS, nous n'utilisons pas le montage d'instantanés dans RO pour extraire des volumes, nous copions simplement l'intégralité du volume LVM2.

La vitesse de sauvegarde sur le serveur de sauvegarde est déterminée dans notre cas par les performances du serveur de sauvegarde, qui sont d'environ 600-800 Mo/s pour les données incompressibles ; un autre limiteur est le canal 10 Gbit/s avec lequel le serveur de sauvegarde est connecté. au cluster.

Dans ce cas, des copies de sauvegarde de 8 serveurs hyperviseurs sont téléchargées simultanément sur un serveur de sauvegarde. Ainsi, les sous-systèmes de disque et de réseau du serveur de sauvegarde, étant plus lents, ne permettent pas aux sous-systèmes de disque des hôtes hyperviseurs de surcharger, car ils ne sont tout simplement pas capables de traiter, disons, 8 Go/s, ce que les hôtes hyperviseurs peuvent facilement produire.

Le processus de copie ci-dessus est très important pour la suite de l'histoire, y compris les détails - en utilisant un lecteur Intel P4500 rapide, en utilisant NFS et, probablement, en utilisant ZFS.

Histoire de sauvegarde

Sur chaque nœud hyperviseur, nous avons une petite partition SWAP de 8 Go, et nous « déployons » le nœud hyperviseur lui-même en utilisant DD à partir de l’image de référence. Pour le volume système sur les serveurs, nous utilisons 2xSATA SSD RAID1 ou 2xSAS HDD RAID1 sur un contrôleur matériel LSI ou HP. En général, nous ne nous soucions pas du tout de ce qu'il y a à l'intérieur, puisque notre volume système fonctionne en mode « presque lecture seule », à l'exception de SWAP. Et comme nous avons beaucoup de RAM sur le serveur et qu'elle est gratuite à 30-40 %, nous ne pensons pas au SWAP.

Processus de sauvegarde. Cette tâche ressemble à ceci :

#!/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

Faites attention à ionice -c3, en fait, cette chose est complètement inutile pour les périphériques NVMe, puisque le planificateur d'E/S pour eux est défini comme :

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

Cependant, nous avons un certain nombre de nœuds existants dotés de RAID SSD conventionnels, pour eux, cela est pertinent, ils se déplacent donc AS IS. Dans l’ensemble, ce n’est qu’un morceau de code intéressant qui explique la futilité ionice dans le cas d'une telle configuration.

Faites attention au drapeau iflag=direct pour DD. Nous utilisons des E/S directes en contournant le cache de tampons pour éviter le remplacement inutile des tampons d'E/S lors de la lecture. Cependant, oflag=direct ce n'est pas le cas car nous avons rencontré des problèmes de performances ZFS lors de son utilisation.

Nous utilisons ce système avec succès depuis plusieurs années sans problème.

Et puis ça a commencé... Nous avons découvert qu'un des nœuds n'était plus sauvegardé, et que le précédent fonctionnait avec un IOWAIT monstrueux de 50%. En essayant de comprendre pourquoi la copie ne se produit pas, nous avons rencontré le phénomène suivant :

Volume group "images" not found

Nous avons commencé à penser que « la fin est venue pour l'Intel P4500 », mais avant d'éteindre le serveur pour remplacer le disque, il était encore nécessaire d'effectuer une sauvegarde. Nous avons corrigé LVM2 en restaurant les métadonnées à partir d'une sauvegarde LVM2 :

vgcfgrestore images

Nous avons lancé une sauvegarde et vu cette peinture à l'huile :

Encore une fois, nous étions très tristes - il était clair que nous ne pouvions pas vivre ainsi, car tous les VPS souffriraient, ce qui signifie que nous souffririons aussi. Ce qui s'est passé n'est absolument pas clair - iostat a montré des IOPS pitoyables et l'IOWAIT le plus élevé. Il n’y avait pas d’autres idées que « remplaçons NVMe », mais une idée s’est produite juste à temps.

Analyse de la situation étape par étape

Revue historique. Quelques jours plus tôt, sur ce serveur il fallait créer un gros VPS avec 128 Go de RAM. Il semblait y avoir suffisamment de mémoire, mais par mesure de sécurité, nous avons alloué 32 Go supplémentaires pour la partition d'échange. Le VPS a été créé, a accompli sa tâche avec succès et l'incident a été oublié, mais la partition SWAP est restée.

Fonctionnalités de configuration. Pour tous les serveurs cloud, le paramètre vm.swappiness a été défini par défaut 60. Et SWAP a été créé sur SAS HDD RAID1.

Que s'est-il passé (selon les éditeurs). Lors de la sauvegarde DD produisait beaucoup de données d'écriture, qui étaient placées dans des tampons RAM avant d'écrire sur NFS. Cœur du système, guidé par la politique swappiness, déplaçait de nombreuses pages de mémoire VPS vers la zone d'échange, située sur un volume HDD RAID1 lent. Cela a conduit à une croissance très forte d'IOWAIT, mais pas à cause de l'IO NVMe, mais à cause de l'IO HDD RAID1.

Comment le problème a été résolu. La partition d'échange de 32 Go a été désactivée. Cela a pris 16 heures ; vous pouvez lire séparément comment et pourquoi SWAP s'éteint si lentement. Les paramètres ont été modifiés swappiness à une valeur égale à 5 partout dans le cloud.

Comment cela pourrait-il ne pas arriver ?. Premièrement, si SWAP était sur un périphérique SSD RAID ou NVMe, et deuxièmement, s'il n'y avait pas de périphérique NVMe, mais un périphérique plus lent qui ne produirait pas un tel volume de données - ironiquement, le problème est survenu parce que ce NVMe est trop rapide.

Après cela, tout a commencé à fonctionner comme avant - avec zéro IOWAIT.

Source: habr.com