Bonjour,
Connaissez-vous des outils (en cli) pour faire des diagnostiques du hardware d’un serveur baremetal.
Ce qui m’intéresse le plus c’est :
- Processeur
- Ram
- Disque dur
- Carte réseau
Merci d’avance.
En général les carte d’administration à distance des serveurs fournissent cette fonctionnalité. Dans le cas des cartes idrac (que je connais mieux), tu peux voir l’état du matériel via l’interface ou lancer une ‘collecte’ qui te permettra d’analyser l’état de ton serveur via une collecte de logs faite par l’interface d’administration.
Sinon les outils classiques
Ram → memtest
Disques dur → smartctl
Cartes réseau → ethtool
1 « J'aime »
mon preferé dmidecode ca liste le hardware.
sudo dmidecode | perl -ne 'print if /^Memory Device$/ ... /^[^\s]/'|grep -v Handle
sudo dmidecode | less
pour les disque dur il y a pas mal de truc spécifique aux cartes … voir le-vert
http://hwraid.le-vert.net/
pour les raid software
cat /proc/mdstat
mdadm --detail --scan
man mdadm
sur OS moderne
inxi -Fx
sinon ipmiutil ou ipmitool pour les list hardware
lshw
pour l’etat des disques smartmontools (la commande smartctl )
sudo smartctl -a -f brief /dev/sda
pour les HBA :
systool -c fc_host -v
1 « J'aime »
Après pour bench ou exercer:
proc → stress
nw → iperf
hdd → fio
Pour le CPU, il existe CPU burn. C’est un jeu d’instruction qui va faire énormément chauffer le CPU et donc déclencher la sécurité du CPU si il est mal refroidi. Cela permet de verifier que le CPU est bien refroidi. Je ne trouve pas le site original aussi le projet n’est peut être plus maintenu. J’ai trouvé ce repo qui semble contenir le nécessaire, mais qui est un peu vieillissant:
A toute fins utile, j’ai trouvé un version Go de cpuburn, il ne faut surtout pas utiliser ça, car le Go ne permet de controller le scheduling à un bas niveau, aussi je doute de son efficacité.
attention, il y a deux types de memtest, un qui s’execute sous l’OS et qui est très limité dans ses tests puisque il n’a pas un accès direct à la RAM. en effet, c’est le kernel via la MMU qui distribue la RAM au userland, aussi le memtest pour Linux ne sais pas quelle est la veritable adresse de ce qu’il gère, et bien sur il ne teste la RAM utilisée par le kernel puisque il n’y a pas accès.
L’ideal est de prendre un test de mémoire bootable sur un OS type DOS qui donne le plein contrôle du hardware au programme et lancer le test. L’inconvenient est qu’il faut arrêter le serveur.
Sinon, il peut y avoir de traces dans les logs kernel. J’ai eu dernierement un hardware qui plantait chez online, et j’ai pu retrouver une trace du kernel panic dans le logs avec ceci:
[ 4200.714077] Disabling lock debugging due to kernel taint
[ 4200.714084] core: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 0: 9000000020000003
[ 4200.714086] core: [Hardware Error]: TSC 6b76ee7a624
[ 4200.714090] core: [Hardware Error]: PROCESSOR 0:406d8 TIME 1679390727 SOCKET 0 APIC 0 microcode 12d
[ 4200.714092] core: [Hardware Error]: Run the above through 'mcelog --ascii'
[ 4200.714094] core: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 0: 9000000020000003
[ 4200.714096] core: [Hardware Error]: TSC 6b76ee7a624
[ 4200.714099] core: [Hardware Error]: PROCESSOR 0:406d8 TIME 1679390727 SOCKET 0 APIC 0 microcode 12d
[ 4200.714101] core: [Hardware Error]: Run the above through 'mcelog --ascii'
[ 4200.714103] core: [Hardware Error]: Machine check: Neither restart nor error IP
[ 4200.714105] Kernel panic - not syncing: Fatal machine check
On comprendz pas très clairement qu’il y a un probleme hardware sur la ram, car l’erreur est relative à une bank Machine Check Exception: 4 Bank 0: 9000000020000003 et je ne connais que la ram qui utilise la terminologie de bank.
1 « J'aime »
Pour memtest, beaucoup de Linux le mettent dans le menu du bootloader GRUB (donc hors OS)
Par ailleurs, les tests materiels du contructeur sont disponibles via l’invite de boot sur les ordinateurs ou serveurs
Sinon, une remarque sur lshw, la commande permet de voir les pilotes utilisés, ce qui est parfois utile
sudo lshw -C video
*-display
description: VGA compatible controller
produit: SVGA II Adapter
fabricant: VMware
identifiant matériel: 2
information bus: pci@0000:00:02.0
version: 00
bits: 32 bits
horloge: 33MHz
fonctionnalités: vga_controller bus_master rom
configuration : driver=vmwgfx latency=64
ressources : irq:18 portE/S:d000(taille=16) mémoire:e0000000-e7ffffff mémoire:e8000000-e81fffff mémoire:c0000-dffff
Enfin redondant avec d’autres outils mais bon, certains préfèreront. Pour lister de manière ordonnée les materiels
lstopo
J’oubliais…
En plus des commandes ipmi via les ipmitools génériques déjà cité, tu as -spécifique aux serveurs Dell- l’utilitaire CLI racadm. Il est assez complet. Il dépend de la version de la carte de gestion (6 très vieux, 7, 8, ou 9 pour les plus récentes) et du type de carte (Basic, Express, Enterprise).
Tu peux, entre autre, suivre l’état du matériel avec cette commande.
Je ne connais pas l’équivalent chez d’autres constructeurs notamment HP. Ça m’intéresserait de savoir s’ils ont un équivalent à racadm.
chez HPE il y a ILO avec une série d’outils similaire que l’on retrouve ici
1 « J'aime »
Qu’est-ce que tu appelles diagnostic ?
Si c’est pour diagnostiquer une panne potentielle, c’est assez difficile si tu n’es pas sur du matériel pro, avec les outils cités plus haut. En dehors du memtest pour la ram, je ne connais rien.
Par contre, tu peux aussi vouloir stresser les ressources matérielles pour déclencher la panne.
Pour un cpu, cpuburn n’est pas suffisant. Il vaut mieux un pipeline avec un programme de compression multithread qui va aussi stresser le cache du cpu et en même temps la ram.
Pour le réseau, iperf3 ou un netcat dans un pipeline (un qui écoute et envoie vers /dev/null et l’autre qui envoie depuis /dev/zero (/dev/random n’étant en général pas assez rapide)
Pour voir les débits dans ces différents pipeline, tu ajoutes PV (pipe viewer) dans le pipeline.
Oui c’est exactement ça.
J’ai une suspicion de panne materiel sur un serveur physique.
Quels sont les symptômes ?
fumée noire ou fumée blanche ?