Aller au contenu
EuroVPSEuroVPS

Que vérifier sur un nouveau serveur avant qu'il porte la production

Les contrôles de réception d'un nouveau serveur dédié : mémoire, disques, cache RAID, détection du flash, liens agrégés, double alimentation et accès distant, avec les commandes.

Par EuroVPS Engineering

5 min de lecture
Que vérifier sur un nouveau serveur avant qu'il porte la production

Un nouveau serveur dédié arrive en général avec un système d'exploitation, un identifiant et une hypothèse : que tout ce que vous avez payé est présent, en bonne santé et configuré pour servir. La plupart du temps, c'est presque vrai. L'écart entre presque et complètement est l'origine des bases de données lentes, des liens réseau inactifs et des pannes surprises. Voici le contrôle de réception que nous pensons que chaque serveur mérite avant de porter la production, avec les commandes pour le faire vous-même.

Pourquoi le contrôle de réception est sauté

Un serveur qui démarre a l'air terminé. Le système d'exploitation ne se plaint pas d'un module mémoire qu'il ne voit pas, d'un cache RAID qui tourne sans sa batterie, ni d'un bond qui envoie chaque paquet par un seul lien. Chacun de ces défauts est invisible à l'usage normal et coûteux plus tard, et chacun prend quelques minutes à vérifier le premier jour. Après la mise en production, les mêmes contrôles exigent une fenêtre de maintenance.

Mémoire : toute, équilibrée, sans erreur

Confirmez que le système voit chaque module que vous avez commandé, et qu'ils sont disposés de façon équilibrée sur les canaux mémoire de chaque processeur. Une disposition déséquilibrée fonctionne, mais plus lentement qu'elle ne le devrait.

dmidecode -t memory | grep -E 'Size|Locator' | grep -v 'No Module'
free -h
ras-mc-ctl --errors

Des erreurs mémoire corrigées dans les premiers jours de la vie d'un serveur sont une raison de remplacer un module maintenant, tant que c'est facile, pas une curiosité à surveiller.

Disques et contrôleur RAID

Lisez la santé de chaque disque, y compris ceux cachés derrière un contrôleur RAID matériel, et l'état du cache d'écriture du contrôleur :

smartctl -a /dev/sda
smartctl -a -d megaraid,0 /dev/sda    # a drive behind a MegaRAID-family controller
storcli64 /c0 show all                # Dell PERC and LSI family
ssacli ctrl all show config detail    # HPE Smart Array

Cherchez des compteurs non nuls de secteurs réalloués, en attente ou d'erreurs média sur n'importe quel disque. Un disque neuf avec une erreur corrigée est un disque dont la correction d'erreurs travaille déjà dur. Sur le contrôleur, confirmez que le disque logique est au niveau RAID commandé, que le cache est en mode write-back et que la batterie ou le module de cache sur flash se déclare en bonne santé. Un contrôleur retombé en write-through à cause de sa batterie peut donner à une baie de SSD la sensation d'un disque rotatif.

Puis mesurez le débit sur le volume vide avant qu'il contienne des données, avec un outil comme fio, pour disposer d'une référence à comparer plus tard.

Le flash est-il traité comme du flash ?

Les contrôleurs RAID matériels ne transmettent souvent pas l'indicateur solid state au noyau, si bien qu'un volume bâti sur des SSD est signalé comme disque rotatif et reçoit des réglages prévus pour des plateaux :

lsblk -d -o NAME,ROTA,SCHED,MODEL
cat /sys/block/sda/queue/read_ahead_kb

Si ROTA affiche 1 sur un volume que vous savez être du flash, confirmez d'abord le type de média depuis le contrôleur, puis corrigez-le avec une règle udev pour que cela survive aux redémarrages :

# /etc/udev/rules.d/60-ssd-tunings.rules
ACTION=="add|change", KERNEL=="sda", ATTR{queue/rotational}="0"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/scheduler}="mq-deadline"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/read_ahead_kb}="16"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/nr_requests}="1024"
udevadm control --reload && udevadm trigger --action=change /sys/block/sda

N'appliquez pas cela à un volume sur disques durs. Un read ahead court convient au flash et pénalise les lectures séquentielles sur plateaux.

Réseau : deux liens, tous deux actifs

Un serveur avec deux ports agrégés n'en utilise souvent qu'un. Le hash d'émission par défaut du pilote de bonding Linux ne regarde que les adresses MAC, et dans un datacenter, où un hôte parle à une poignée de MAC de passerelles et de pairs, cela peut placer presque tous les flux sur le même lien.

cat /proc/net/bonding/bond0
ethtool -S <first port> | grep -E 'tx_packets|rx_packets'
ethtool -S <second port> | grep -E 'tx_packets|rx_packets'

Vérifiez que les deux membres sont up, que LACP s'est associé au switch, et que la politique de hash est celle que vous vouliez. Sous charge, les compteurs des deux membres doivent croître à des rythmes comparables. Pour la plupart des serveurs, hacher sur les adresses IP et les ports répartit bien mieux le trafic :

nmcli con mod bond0 bond.options "mode=802.3ad,miimon=100,lacp_rate=slow,xmit_hash_policy=layer3+4"

Alignez le côté switch là-dessus, pour que le trafic soit réparti de la même façon dans les deux sens. Puis débranchez un câble, confirmez que le serveur reste joignable, rebranchez-le, et répétez avec l'autre.

Alimentation, heure et accès distant

ipmitool sdr type "Power Supply"
chronyc tracking
getenforce

Les deux alimentations doivent être présentes et sous tension, et elles doivent être alimentées par des arrivées électriques différentes. Un serveur avec deux alimentations branchées sur la même arrivée a un point de défaillance unique avec des étapes en plus. Confirmez que le contrôleur hors bande (iLO, iDRAC ou IPMI) est joignable sur son réseau d'administration et licencié pour la console distante dont vous aurez besoin. Si SELinux fait partie de votre standard, confirmez qu'il est en enforcing avant l'installation de la première application, pas après.

Écrivez-le

Le dernier contrôle est la documentation : numéro de série, position dans le rack, chaque port avec son adresse MAC et ce à quoi il se connecte, chaque adresse IP, les deux arrivées électriques et les identifiants de câbles.

Comment nous le faisons

Nos serveurs dédiés sont des plateformes HPE ProLiant et Dell PowerEdge, avec une administration hors bande sur un réseau isolé. Chaque build RAID passe un contrôle de santé des disques et un test de débit avant livraison. Le flash derrière un contrôleur RAID reçoit les réglages ci-dessus, en fonction du type de média lu sur les disques. Chaque bond hache sur les adresses et les ports, avec le switch aligné. Nous vérifions les compteurs par port pour prouver que les deux liens transportent du trafic.

Si vous avez un serveur déjà en production qui n'a jamais eu ce contrôle, il n'est pas trop tard, et nous serons heureux de le passer en revue avec vous.

CTA

Parler à un ingénieur

Related

Articles liés : Serveurs bare metal sur HPE et Dell · Ingénierie de la performance et de la capacité · Stockage SAN entreprise sur HPE 3PAR, all-flash

Publié le 28 septembre 2026.

Toutes les notes de terrain