Réalités matérielles, limites de ressources et surveillance approfondie des performances
Lorsqu'un NAS QNAP semble lent, l'investigation commence par ce que son matériel peut faire. Ensuite, on examine à quoi le NAS consacre ses ressources, et seulement après, on s'intéresse aux files d'attente plus profondes : les processus bloqués sur les E/S et les machines virtuelles qui se disputent le processeur.
- Attentesà quoi sert ce matériel
- Base de référencearrêtez les extras, surveillez la RAM et le SWAP
- États Dprocessus bloqués sur les E/S
- vCPUthreads, surréservation, vol (steal)
- GraphiquesBlackBox et Pulse, bien lire
01Attentes matérielles et réalité
Les serveurs QNAP sont construits avec des pièces qui correspondent à leur prix. QNAP fournit toujours des mises à jour de firmware pour des unités vieilles de plus de dix ans, mais cela ne signifie pas qu'un NAS ancien ou d'entrée de gamme peut faire tourner toute la gamme d'applications d'aujourd'hui sans compromis. Les logiciels s'alourdissent au fil de leur développement ; le matériel reste ce qu'il était.
Un NAS économique est conçu pour un partage de fichiers fluide. S'attendre à ce qu'il fasse tourner des machines virtuelles ou de lourdes bases de données sans problème, c'est mal comprendre ce qu'il est. Vérifiez ce que votre processeur et votre mémoire peuvent réellement faire, et assumez votre choix de matériel. La tâche principale du NAS est de travailler avec des fichiers ; tout le reste est un complément qui s'exécute dans la limite des ressources restantes.
02Branche 1 : la base de référence, en isolant les services
Lorsque le NAS ralentit, surtout lorsque sa mémoire s'épuise et qu'il commence à utiliser le SWAP (ce qui ralentit fortement toutes les opérations), la première étape de diagnostic consiste à isoler les services.
- Connectez-vous à QTS ou QuTS hero.
- Ouvrez l'App Center et arrêtez les applications et services non essentiels un par un. Workbench n'arrête pas les applications à votre place.
- Surveillez le système dans le Moniteur de ressources de QTS ou dans Pulse de Workbench (bureau Utilities, menu Démarrer → Monitoring → Pulse ; administrateurs uniquement). Son cockpit s'actualise toutes les deux secondes : utilisation du CPU avec une barre par CPU logique, RAM utilisée par rapport au total avec le cache de pages dans une bande distincte, une barre SWAP lorsque le NAS a du swap, la charge sur 1 minute et la file d'attente d'exécution. Regardez la charge du CPU et le SWAP utilisé diminuer.
- Trouver la base de référence : continuez à arrêter des services jusqu'à ce que la fonction principale du NAS, le partage de fichiers fluide, soit pleinement rétablie.
Il s'agit de la base de référence de votre matériel. À partir de là, démarrez les autres applications une par une, strictement dans la limite des ressources dont dispose encore le matériel.
03Branche 2 : états D et goulots d'étranglement cachés
Parfois, le problème ne vient pas d'un CPU surchargé ou d'un manque de RAM. Le système peut se bloquer avec un processeur loin d'être à pleine charge lorsque des processus sont en veille ininterruptible, l'état D. Selon les propres termes de Workbench, un processus à l'état D est bloqué en attente d'E/S du noyau (disque, un système de fichiers réseau, un pilote figé) et ne peut même pas être tué tant que cette E/S n'est pas terminée. Quand de nombreux processus sont en D, c'est qu'ils font la queue, généralement derrière des E/S disque lentes, et l'appareil se fige.
Cette file d'attente pénalise surtout un NAS qui héberge des machines virtuelles (Virtualization Station, KVM). Une mauvaise allocation des ressources à ce niveau se traduit par des paquets réseau perdus et de longs délais d'E/S.
- Pulse signale les Processes in D-state (I/O) dès qu'un processus est en D, et le marque comme critique au-delà de deux. Sur son onglet Processes, D + Z n'affiche que les processus bloqués (D) et zombies (Z) ainsi que leurs parents.
- BlackBox enregistre le NAS toutes les 20 secondes dès que le paquet fonctionne ; il n'y a rien à activer. Il conserve l'utilisation du CPU, l'iowait et l'horloge par cœur, la charge, la file d'attente d'exécution et les Blocked (D) ; la mémoire utilisée et disponible, le cache de pages, le swap et les OOM kills ; par interface le trafic, les rejets et les retransmissions TCP ; par disque l'await, la profondeur de la file d'attente et l'utilisation ; les températures et les ventilateurs ; et par VM son CPU, ses vCPU, sa mémoire et ses E/S disque. Il conserve chaque échantillon de 20 secondes pendant un jour, puis des résumés par minute pendant une semaine, par cinq minutes pendant un mois et par heure pendant un an.
- Deux décomptes D différents. Les Blocked (D) de BlackBox représentent le décompte par le noyau des tâches bloquées ; Pulse compte les processus qu'il voit à l'état D. Les deux valeurs peuvent différer.
- iowait, pas PSI. Les noyaux de QNAP sont compilés sans les informations de blocage sous pression (Pressure Stall Information) : Workbench mesure donc le délai d'E/S par l'iowait.
04Allocation CPU : pCPU, lCPU et vCPU
Avant d'attribuer des ressources à une VM, connaissez la topologie :
- pCPU (physical CPU) : les cœurs physiques du processeur du NAS.
- lCPU (logical CPU) : les cœurs vus par le système d'exploitation, Hyper-Threading inclus. L'Hyper-Threading ne double pas les performances ; en règle générale, il ajoute environ 30 % de débit.
- vCPU (virtual CPU) : les cœurs virtuels attribués aux VM.
Pulse compte les CPU logiques : lorsqu'il indique 12 cores sur un Xeon W-1250 à six cœurs et douze threads, il s'agit de threads.
Le piège de la surréservation (oversubscription). Attribuer 128 vCPU à des VM sur un processeur à 32 cœurs suppose qu'ils ne seront jamais tous occupés en même temps. Lorsque c'est le cas, l'hyperviseur ne peut pas planifier les vCPU assez rapidement, et les VM se bloquent en attendant du temps CPU, ce qui se traduit à l'intérieur d'un invité par du « steal time » (temps volé). Pulse le signale côté hôte :
- vCPU over-subscription (information) lorsque les VM en cours d'exécution ont plus de vCPU que le NAS n'a de CPU logiques ;
- VMs contending for CPU (avertissement) lorsque, en plus de cela, l'hôte est occupé à plus de 75 % ou que sa file d'attente d'exécution est plus longue que son nombre de threads. Sa note sur ce NAS : Over-subscribed (17 vCPUs / 12 cores) AND the host is busy (84%, queue 11) — your VMs are likely contending for physical cores NOW. This is CPU theft, host-side.
- Le steal time est mesuré à l'intérieur de l'invité. Sur le NAS, il vaut zéro par principe ; la propre note de Workbench indique que vous ne pouvez pas voir le vol d'un invité depuis l'hôte. Évaluez la contention sur le NAS d'après le nombre de vCPU comparé au nombre de threads, le pourcentage d'occupation et la file d'attente d'exécution, et lisez le steal à l'intérieur de la VM (la colonne
stdetopouvmstatdans un invité Linux).
05Surveillance des machines virtuelles
Workbench ne demande d'installer aucun agent dans une VM. Il mesure le NAS sur lequel il s'exécute, et cela inclut les machines virtuelles hébergées par le NAS :
- Ouvrez Pulse, l'onglet VM : chaque VM en cours d'exécution avec ses vCPU, % CPU, mémoire, RSS, état et identifiant de processus, et la ligne de titre Hosting 4 VM(s), 17 vCPUs.
- Ouvrez BlackBox (Menu Démarrer → Monitoring), passez à Heat map (carte thermique) et activez la ligne Virtual machines : le CPU de chaque VM tout au long de la journée, à côté des températures et de l'await des disques. Ses graphiques conservent également les vCPU, la mémoire et les E/S disque de chaque VM, ainsi que le démarrage et l'arrêt de chaque VM.
- Pour suivre l'accessibilité réseau d'une VM, ajoutez son adresse dans BlackBox sous Settings → Monitored hosts : BlackBox enregistre alors son aller-retour (round trip) et sa perte de paquets.
- À l'intérieur de la VM, surveillez son steal time avec les propres outils de l'invité.
La fenêtre Virtual Machines · LOCAL (Local NAS → Virtual Machines) affiche la configuration de chaque VM à partir de Virtualization Station : ses vCPU, sa topologie, son jeu de CPU, son modèle de CPU, ses disques et ses cartes réseau. À son ouverture, elle lance les dumps de diagnostic de QNAP lui-même vers le cache de Workbench ; elle ne modifie aucun paramètre.
06Lecture des graphiques : les états critiques
- État D élevé et délai d'E/S. Des processus sont en attente sur les disques. Le rapport hebdomadaire de BlackBox nomme cela Processes waiting on storage (un iowait au 95e centile de 20 % ou plus est un avertissement, 40 % ou plus critique) et désigne le disque le plus occupé ; Slow array member signale un disque dont l'await est le double de celui des autres disques de la grappe et d'au moins 50 ms (critique à 200 ms), et Disk with no headroom un disque occupé à 90 % ou plus pendant deux heures. Le remède correspond au conseil de l'auteur : déplacez la VM vers un volume SSD, vérifiez l'état de santé des disques (le guide des performances), et vérifiez qu'aucun autre processus ne sature le RAID.
- Forte file d'attente CPU. Le processeur du NAS est en surréservation : Pulse indique VMs contending for CPU, et le rapport hebdomadaire Virtual machine hogging the host signale une VM qui utilise 150 % d'un cœur ou plus (300 % critique). Donnez moins de vCPU aux VM : commencez avec un ou deux par VM et ajoutez-en davantage uniquement lorsque l'invité en a besoin.
- Bridage thermique (Thermal throttling). Une température CPU élevée, puis une horloge plus basse et des délais plus longs, signifient que le processeur surchauffe. Le rapport hebdomadaire l'appelle CPU thermal throttling : un cœur fonctionnant à 60 % ou moins de sa propre horloge habituelle alors que le CPU est occupé à au moins 60 %. Sur la carte thermique, 65 °C est ambre et 80 °C rouge. Le propre conseil de Workbench : nettoyez la poussière du dissipateur thermique, des ventilateurs et des entrées d'air, vérifiez que les ventilateurs tournent, et améliorez la circulation de l'air ou abaissez la température de la pièce ; une vitesse de ventilateur plus élevée dans QTS aide également.
07Bonnes pratiques KVM : le modèle CPU
- Hôte / passthrough (recommandé) : transmet le processeur du NAS lui-même à la VM, avec chaque jeu d'instructions dont il dispose (AVX, par exemple). Cela offre les meilleures performances et la surcharge la plus faible sur un seul NAS.
- Un modèle émulé (un CPU Intel ou AMD générique) : masque le processeur de l'hôte. C'est utile dans un cluster, pour déplacer des VM en cours d'exécution entre des hôtes physiquement différents ; sur un seul NAS, il ne fait que réduire les performances.
La fenêtre Virtual Machines · LOCAL montre le modèle de CPU attribué à chaque VM (par exemple Westmere) et sa topologie ; Workbench ne juge pas ce choix.
08Connaissances de base : surallocation des ressources (overcommit)
Comment ne pas écraser les performances des VM quand le NAS est à la limite de ses capacités. Le ratio de vCPU par rapport aux cœurs physiques (pCPU) est le premier chiffre à calculer :
| Ressource | Gain | Risque | Conseil |
|---|---|---|---|
| CPU (vCPU : pCPU) | plus de VM, marge de manœuvre peu coûteuse pour de courtes pointes | à saturation, le steal et les files d'attente ralentissent chaque VM | production 2:1–4:1, VM critiques jusqu'à 2:1 ; hôte en dessous de 80 % |
| RAM (ballooning, Dynamic Memory) | mémoire déplacée à la volée, utile pour les VM inactives | le swap de l'hôte entraîne une chute drastique des performances | ne laissez jamais l'hôte swapper des pages actives ; réservez de la mémoire pour les VM critiques |
| Stockage (thin) | espace économisé, disques créés en un instant | un datastore plein arrête les VM immédiatement | alertes à 75–85 % ; récupérez l'espace (UNMAP) ; données critiques plutôt en « thick » |
Règle générale. L'overcommit est sûr sous une charge légère et inégale avec une surveillance active, et dangereux lors des pics sans marge de manœuvre. Gardez une réserve.
Astuces
- Commencez avec 1 vCPU par VM et ajoutez-en davantage uniquement lorsque la charge le nécessite. Plus de vCPU que nécessaire signifie plus de surcharge pour le planificateur, pas plus de vitesse.
- Comptez les cœurs physiques, pas les threads. Ne donnez pas à l'ensemble des VM plus de vCPU que l'hôte n'a de cœurs.
- Gardez le CPU de l'hôte en dessous de 80 %. Au-dessus de 90 %, les VM se disputent les cycles et le steal augmente à l'intérieur des invités.
- Lisez « top » dans l'invité : %wa est l'attente d'E/S (un goulot d'étranglement disque), %st est le steal (trop de surallocation), %id est la capacité de réserve.
- %wa élevé ? Stockage plus rapide ou un SSD. %st élevé ? Moins de vCPU ou moins de VM.
- VirtIO pour le disque et le réseau, beaucoup plus rapide que l'émulation. Le passthrough PCIe ou GPU uniquement lorsque c'est vraiment nécessaire : l'appareil appartient alors à une seule VM en exclusivité.
Un snapshot de VM n'est pas une sauvegarde
Un snapshot n'enregistre que la différence par rapport à son point de base (les modifications apportées aux disques, et avec un état sauvegardé, également la mémoire). Si la base ou la chaîne de snapshots est endommagée, les snapshots deviennent eux aussi inutilisables. Pour une véritable protection, sauvegardez des images de VM complètes : un export, HBS ou un support distinct.