Mémoire ECC sur un serveur dédié : à quoi elle sert et comment la surveiller sous Linux

La mémoire ECC sur un serveur dédié

Quand une machine serveur tourne en production 24 heures sur 24, une erreur mémoire silencieuse peut corrompre une base de données, planter un serveur virtuel ou provoquer un kernel panic sans raison apparente. La mémoire ECC (Error-Correcting Code) est la parade standard sur tout serveur physique : elle détecte et corrige les erreurs de bits en temps réel, sans intervention de l'administrateur et sans interruption de service. Sur les serveurs dédiés comme sur les VPS, la fiabilité du matériel hardware conditionne celle de tout ce qui tourne dessus : système d'exploitation, bases de données, serveurs virtuels et services réseau.

Ce guide s'adresse aux administrateurs qui gèrent un serveur dédié Linux et veulent comprendre ce que la mémoire ECC corrige (erreur d'un bit), ce qu'elle détecte sans corriger (erreur de deux bits), pourquoi elle équipe tous les serveurs dédiés Xeon Gold de notre offre d'hébergeur et comment surveiller les erreurs mémoire avec le sous-système EDAC du noyau et l'outil rasdaemon.

Comment fonctionne la mémoire ECC

La mémoire non-ECC (celle des PC de bureau) stocke les données sans aucun mécanisme de vérification. Si un bit bascule (un 0 devient un 1 ou l'inverse) à cause d'un rayon cosmique, d'une micro-décharge électrique ou du vieillissement d'une cellule DRAM, le système ne s'en aperçoit pas. Il utilise la donnée corrompue comme si de rien n'était.

La mémoire ECC ajoute des bits de contrôle supplémentaires à chaque mot mémoire (typiquement 8 bits de parité pour chaque bloc de 64 bits de données). Le contrôleur mémoire du processeur recalcule ces bits à chaque lecture et compare le résultat au code stocké. Ce contrôle hardware est transparent pour le système d'exploitation : il se produit à chaque accès mémoire, sans surcoût logiciel.

Le mécanisme le plus répandu est SECDED (Single Error Correction, Double Error Detection), basé sur un code de Hamming étendu :

En résumé : l'ECC corrige silencieusement les erreurs d'un bit (de loin les plus fréquentes) et détecte sans corriger les erreurs de deux bits, ce qui permet au système de réagir plutôt que de travailler sur des données corrompues.

Pourquoi l'ECC est la norme sur serveur

Sur un PC de bureau, une erreur mémoire provoque au pire un plantage d'application. Sur un serveur physique en production, les conséquences sont plus lourdes car une seule machine peut héberger de nombreux services et clients :

• Une base de données (MySQL, PostgreSQL, Redis) écrit des données corrompues sur le SSD ;
• Un hyperviseur (Proxmox VE, VMware ESXi) propage l'erreur à plusieurs serveurs virtuels ;
• Un serveur de jeu (FiveM, Minecraft, Rust) plante de manière aléatoire et inexpliquée ;
• Un serveur web (Apache, Nginx) sert des pages corrompues aux visiteurs ;
• Un serveur DNS résout des noms de domaine avec des réponses erronées ;
• Un NAS ou un système de fichiers (ZFS, ext4) perd l'intégrité de ses métadonnées et de l'espace disque utilisé ;
• Un serveur de sauvegardes écrit des fichiers de backup tronqués, rendant les restaurations impossibles.

C'est la raison pour laquelle l'ECC est la norme sur les plateformes serveur, aussi bien sous Linux que sous Windows Server. Tous les processeurs Intel Xeon et AMD EPYC supportent la RAM DDR4 ECC. Le Xeon Gold 6230 qui équipe les serveurs dédiés Xeon Gold ElypseCloud dispose de 6 canaux mémoire par processeur (12 canaux en configuration bi-processeur), chacun capable de gérer de la DDR4-2933 ECC. Les configurations vont de 32 Go à 512 Go de RAM ECC, avec la flexibilité de choisir la capacité adaptée à votre usage. Même la gamme Xeon E5, positionnée comme option budget, embarque de la mémoire ECC. Sur un hébergement mutualisé, la mémoire ECC du serveur physique protège toutes les instances, mais l'administrateur n'a aucune visibilité sur les compteurs d'erreurs. Un serveur dédié donne un accès root complet à ces compteurs.

ECC et virtualisation : protéger les serveurs virtuels

Sur un serveur dédié qui fait tourner un hyperviseur comme Proxmox VE, la mémoire ECC protège à la fois l'hôte et toutes les machines virtuelles (VM). Chaque serveur virtuel partage la même RAM physique : une erreur mémoire non corrigée sur l'hôte peut corrompre n'importe quelle VM sans que son système d'exploitation invité ne puisse intervenir.

Dans un cluster de haute disponibilité, la surveillance de la mémoire ECC prend une importance particulière. Quand les compteurs d'erreurs corrigibles augmentent sur un noeud, c'est le signal pour planifier la migration des serveurs virtuels vers un autre noeud du cluster avant une panne. Sans migration préventive, une erreur non corrigible (UE) peut provoquer un arrêt brutal de toutes les VM hébergées sur ce noeud, avec un impact direct sur la bande passante réseau (le basculement d'urgence génère un pic de trafic) et sur la disponibilité des services.

Pour dimensionner un serveur Proxmox VE avec des dizaines de VM et de conteneurs, la fiabilité de la RAM est un prérequis. C'est aussi vrai pour un serveur qui fait tourner plusieurs serveurs de jeu en parallèle : chaque instance FiveM, Minecraft ou Rust est un processus en mémoire que l'ECC protège individuellement.

EDAC : le sous-système mémoire du noyau Linux

Sous Linux, la détection des erreurs ECC est gérée par EDAC (Error Detection And Correction), un sous-système intégré au noyau. EDAC communique avec le contrôleur mémoire du processeur et expose les compteurs d'erreurs via sysfs. Ce mécanisme est disponible sur toutes les distributions serveur courantes (Debian, Ubuntu, Rocky Linux, AlmaLinux) sans paquet supplémentaire.

Connectez-vous en SSH à votre serveur dédié avec un compte disposant des droits root (ou utilisez sudo) et vérifiez qu'EDAC est chargé :

ls /sys/devices/system/edac/mc/

Si le répertoire existe et contient des dossiers mc0, mc1, etc., le pilote EDAC est actif. Chaque mcN correspond à un contrôleur mémoire (un par processeur en configuration bi-processeur Xeon Gold). Sur un serveur bi-processeur NUMA, vous verrez typiquement mc0 et mc1.

Les compteurs d'erreurs sont accessibles directement depuis le terminal SSH :

cat /sys/devices/system/edac/mc/mc0/ce_count
cat /sys/devices/system/edac/mc/mc0/ue_count

• ce_count : nombre d'erreurs corrigibles (Correctable Errors). L'ECC les a corrigées à la volée, aucune donnée n'a été perdue.
• ue_count : nombre d'erreurs non corrigibles (Uncorrectable Errors). Le contrôleur mémoire a détecté un problème qu'il ne peut pas réparer.

Un compteur ce_count à zéro (ou très bas) est normal. Un compteur ue_count supérieur à zéro indique un problème hardware sérieux qui nécessite une action immédiate.

Installer et configurer rasdaemon

Les compteurs sysfs donnent un instantané, mais ne conservent pas d'historique et ne précisent pas quelle barrette DIMM est en cause. rasdaemon est le daemon de référence pour la journalisation des erreurs RAS (Reliability, Availability, Serviceability) sous Linux. Il écoute les événements de trace du noyau (tracepoint ras:mc_event) et les stocke dans une base SQLite locale.

Sur Debian 12 ou Ubuntu 24.04 LTS, connectez-vous en SSH et exécutez :

sudo apt update
sudo apt install rasdaemon

rasdaemon se lance automatiquement comme service systemd. Vérifiez qu'il tourne :

sudo systemctl status rasdaemon

Les événements sont enregistrés dans la base /var/lib/rasdaemon/ras-mc_event.db et dans le journal systemd. Pour consulter les logs :

sudo journalctl -u rasdaemon --no-pager | tail -20

Utiliser ras-mc-ctl pour interroger les erreurs

ras-mc-ctl est l'utilitaire en ligne de commande livré avec rasdaemon. Il simplifie la lecture des compteurs EDAC et de la base d'erreurs.

Vérifier que les pilotes EDAC sont chargés :

sudo ras-mc-ctl --status

Afficher le nombre d'erreurs corrigibles et non corrigibles par contrôleur :

sudo ras-mc-ctl --error-count

Afficher un résumé des erreurs enregistrées dans la base :

sudo ras-mc-ctl --summary

Lister toutes les erreurs stockées dans la base SQLite :

sudo ras-mc-ctl --errors

Afficher la disposition mémoire vue par EDAC (contrôleurs, canaux, rangées) :

sudo ras-mc-ctl --layout

Ces commandes permettent d'identifier précisément quel slot DIMM, quel canal et quel contrôleur mémoire sont en cause. Sur un serveur bi-processeur, localiser la barrette fautive est essentiel pour savoir quel noeud NUMA est affecté.

Que faire quand le compteur d'erreurs monte

Des erreurs corrigibles occasionnelles (quelques CE sur plusieurs mois) sont normales et ne nécessitent pas d'intervention. La mémoire ECC fait exactement ce pour quoi elle est conçue : elle corrige le bit erroné et le serveur continue de tourner.

En revanche, certains signaux exigent une réaction :

Après une erreur non corrigible, vérifiez systématiquement vos sauvegardes (backup) : la corruption a pu toucher des données en cours d'écriture sur le SSD ou l'espace disque. Si votre serveur fait tourner des serveurs virtuels, migrez-les vers un autre noeud le temps du remplacement matériel. Pour les bases de données, lancez les commandes de vérification d'intégrité (CHECK TABLE sous MySQL, pg_amcheck sous PostgreSQL).

Pour surveiller les compteurs en continu sur un serveur de production, intégrez la sortie de ras-mc-ctl --error-count dans votre outil de monitoring et d'alertes. Un script qui compare les compteurs à chaque exécution et alerte en cas d'augmentation est un complément simple et efficace à la surveillance des ressources CPU et mémoire.

ECC et hébergement : l'infrastructure derrière la fiabilité

Quand vous louez un serveur dédié chez un hébergeur, la mémoire ECC est un des éléments hardware qui différencient un serveur professionnel d'un assemblage grand public. Chez ElypseCloud, tous les serveurs dédiés sont hébergés en datacenter Equinix PA6 à Paris, avec de la RAM DDR4 ECC d'origine, une adresse IP dédiée (IPv4 + IPv6), un firewall configurable, un SSD de 1 To et une bande passante de 1 ou 10 Gbit/s.

Votre espace de gestion sur manager.elypsecloud.com permet de redémarrer le serveur, de suivre la consommation réseau et de gérer vos adresses IP. En cas de doute sur le comportement matériel de votre machine serveur, l'équipe d'infogérance peut intervenir sur le hardware (remplacement de DIMM, diagnostic carte mère) sans que vous ayez à vous déplacer au datacenter. C'est un avantage par rapport au housing, où la gestion matérielle reste à votre charge.

La flexibilité des configurations mémoire (de 32 à 512 Go) permet d'adapter le serveur à votre charge : un serveur web avec quelques sites et un serveur DNS tourne confortablement avec 32 ou 64 Go, tandis qu'un hyperviseur qui fait tourner un cluster de serveurs virtuels aura besoin de 256 ou 512 Go. Dans tous les cas, chaque gigaoctet est protégé par l'ECC.

ECC vs non-ECC : tableau comparatif

Vérifier que l'ECC est bien active sur votre serveur

Pour confirmer que votre serveur dédié utilise bien de la mémoire ECC et que la correction d'erreurs est active, connectez-vous en SSH et exécutez :

sudo dmidecode -t memory | grep -i "error correction"

La sortie attendue pour un serveur avec RAM ECC :

Error Correction Type: Single-bit ECC

Si vous voyez None, la machine n'a pas de mémoire ECC ou le BIOS ne l'a pas activée. Sur tous les serveurs dédiés Xeon Gold ElypseCloud, la mémoire DDR4 ECC est installée et activée d'origine.

Pour afficher le détail de chaque barrette installée (taille, vitesse, fabricant) :

sudo dmidecode -t memory | grep -E "Size|Speed|Manufacturer|Locator"

Sur les serveurs équipés du Xeon Gold 6230, les barrettes tournent en DDR4-2933 MHz, réparties sur les 12 canaux mémoire de la configuration bi-processeur.

Conclusion

La mémoire ECC est un composant discret mais fondamental de la fiabilité d'un serveur dédié. Elle corrige silencieusement les erreurs de bits les plus courantes et signale celles qu'elle ne peut pas réparer, avant qu'une corruption de données ne se propage aux sauvegardes et aux disques. Sous Linux, le sous-système EDAC et l'outil rasdaemon rendent cette surveillance accessible en quelques commandes depuis une connexion SSH.

Surveiller les compteurs d'erreurs mémoire fait partie de l'administration normale d'un serveur physique, au même titre que surveiller le CPU, l'espace disque et le réseau. Que vous fassiez tourner un serveur web, un cluster de machines virtuelles ou des serveurs de jeu, un serveur dont les compteurs ECC sont propres est un serveur dont les données sont fiables. Pour mettre en place des sauvegardes et de la haute disponibilité sur votre infrastructure, consultez notre guide dédié. Pour sécuriser le reste de votre installation, sécurisez votre serveur dédié dès les premiers réglages.