Avantages de la mémoire RAM DDR5 ECC pour les applications critiques

La plupart des spécifications d'hébergement indiquent la capacité et la vitesse de la mémoire vive (RAM). Elles n'expliquent pas ce que signifie ECC ni pourquoi c'est important pour les charges de travail de production. Cette omission coûte cher aux entreprises qui ne découvrent la corruption silencieuse des données qu'après coup.

Le serveur dédié ExtremeInMotion Hosting est livré avec 192 Go de mémoire vive DDR5 ECC. Ces deux éléments sont importants chacun de leur côté. Cet article explique ce que chacun apporte, quelles applications ont besoin des deux et comment cette combinaison change les performances économiques pour les charges de travail qui sollicitent beaucoup les bases de données.

Ce que fait vraiment la RAM ECC

Le problème : les erreurs de bits DRAM

La mémoire DRAM (Dynamic Random-Access Memory) stocke les bits sous forme de charges électriques dans de minuscules condensateurs. Les rayons cosmiques, les émissions de particules alpha provenant de traces de matières radioactives dans le boîtier de la puce et les interférences électriques provoquent parfois des inversions de bits : un 0 stocké devient un 1, ou l'inverse. Ce n'est pas un problème théorique.

Une étude de l'équipe infrastructure de Google, publiée en 2009 et reprise depuis par d'autres gros opérateurs, a montré des taux d'erreur d'environ 25 000 à 75 000 erreurs par milliard d'heures d'utilisation des appareils sur de grandes flottes de serveurs. Pour un seul serveur de 192 Go qui tourne en continu, ça donne environ une erreur logicielle tous les 1 à 4 ans. Certaines études ont montré que les modules DDR5 à plus haute densité ont des taux d'erreur un peu plus élevés que les DDR4, ce qui rend l'ECC plus utile pour les capacités plus élevées, et pas moins.

Correction d'erreurs à un seul bit

La mémoire RAM ECC ajoute des bits de données supplémentaires à chaque mot mémoire (en général 8 bits supplémentaires par mot de 64 bits) et un circuit de détection et de correction d'erreurs de type code de Hamming. Quand une erreur d'un seul bit se produit, le circuit ECC repère le bit qui a basculé, le corrige avant que les données n'arrivent au processeur et enregistre l'événement. L'application ne voit jamais l'erreur. Le système continue de fonctionner normalement.

Sans ECC, ce simple bit inversé corrompt les données en mémoire. Ce qui se passe ensuite dépend entièrement du bit qui a été inversé et de ce qu'il stockait. Les conséquences possibles vont d'un plantage du processus (relativement bénin) à une corruption silencieuse des données écrites sur le disque (grave), en passant par une panique du noyau qui met tout le serveur hors ligne.

Détection d'erreurs multibits

L'ECC standard (SECDED : Single-Error Correcting, Double-Error Detecting) corrige les erreurs à un seul bit et détecte (mais ne peut pas corriger) les erreurs à deux bits. Quand une erreur à deux bits est détectée, le système déclenche une exception de vérification de la machine. Ça provoque généralement un arrêt du système, ce qui est préférable à l'écriture silencieuse de données corrompues. Pour les applications où un redémarrage imprévu n'est pas possible, les implémentations ECC avancées et la mémoire à correction Chipkill offrent une correction multibit plus puissante.

Quelles applications sont les plus à risque sans ECC ?

Bases de données

Les serveurs de bases de données sont les plus à risque quand on utilise de la RAM non ECC. Un bit qui change dans un pool de tampons de base de données peut abîmer une page d'index, une page de données ou une entrée de journal des transactions. Si l'index est abîmé, ça peut causer des échecs de requêtes ou des résultats de requêtes incorrects qui peuvent ne pas apparaître avant des jours ou des semaines. Si la page de données est abîmée, ça écrit des données incorrectes sur le disque pendant un point de contrôle, ce qui rend l'abîmement permanent même après le redémarrage du serveur.

C'est pour ça que le matériel des bases de données d'entreprise (Oracle Exadata, appareils IBM Db2, systèmes SAP HANA d'entreprise) utilise la mémoire RAM ECC comme spécification de base depuis des années. C'est un must pour les systèmes où l'intégrité des données est super importante.

Systèmes financiers et transactionnels

Un bit inversé dans un calcul financier en mémoire peut changer un montant en dollars de la valeur du bit inversé. Un bit inversé dans le bit 20 d'un entier 32 bits représentant un montant en dollars change la valeur de 1 048 576 $. La probabilité que ça arrive est faible, mais les conséquences d'une corruption non détectée dans les données financières sont tellement graves que le risque n'est pas acceptable.

Ça surprend pas mal d'organisations qui utilisent des applications financières sur du matériel grand public sans ECC sans problème. Le fait qu'on ne remarque pas d'erreur ne veut pas dire qu'il n'y en a pas ; la journalisation ECC permettrait de voir si des erreurs ont été corrigées en silence.

Informatique scientifique et de recherche

Les simulations scientifiques qui tournent pendant des heures ou des jours accumulent les résultats de milliards d'opérations en virgule flottante. Un seul résultat intermédiaire corrompu se propage tout au long du calcul. Sans ECC, les chercheurs peuvent finir une simulation de plusieurs jours pour finalement se rendre compte que le résultat est faux, sans pouvoir savoir où l'erreur s'est produite.

Caches en mémoire

Redis et Memcached stockent toutes les données dans la RAM. Si un bit est inversé dans les données mises en cache, les applis reçoivent des données corrompues. Pour une appli web qui met en cache les résultats des requêtes de base de données, ça veut dire que les utilisateurs reçoivent des données incorrectes sans s'en rendre compte. Selon ce qui a été corrompu, ça peut être sans conséquence (le corps d'un article mis en cache) ou avoir des conséquences importantes (un ensemble d'autorisations utilisateur mis en cache ou un prix mis en cache).

DDR5 vs DDR4 : la question de la performance

Bande passante mémoire

La DDR4 à 3200 MT/s avec 4 canaux mémoire offre une bande passante maximale théorique d'environ 102 Go/s. La DDR5-4800 avec 4 canaux offre environ 153 Go/s. Cette augmentation théorique de 50 % de la bande passante se traduit par des différences de performances réelles dans les charges de travail limitées par la bande passante mémoire.

Type de mémoire	La vitesse	Bande passante à 4 canaux	Latence (CAS)
DDR4-3200	3 200 MT/s	~102 Go/s	22-26 ns en général
DDR5-4800	4 800 MT/s	~153 Go/s	28-34 ns en général
DDR5-6400 (à venir)	6 400 MT/s	~204 Go/s	Environ 32 à 38 ns

La DDR5 a une latence un peu plus élevée que la DDR4 en nanosecondes absolues, à cause des changements dans la façon dont la DDR5 gère l'adressage des banques et les cycles de rafraîchissement. Pour les charges de travail où la latence est super importante, comme les petites requêtes OLTP où un seul accès à la mémoire détermine le temps de réponse, c'est un truc à noter. Pour les charges de travail limitées par la bande passante (analyse de gros ensembles de données, traitement vidéo, simulation scientifique), l'amélioration de la bande passante compense largement.

Charges de travail où la bande passante DDR5 est importante

• Grands pools de tampons de base de données : MySQL et PostgreSQL des analyses de tables volumineuses ou des pages d'index à partir du pool de tampons profitent d'une bande passante plus élevée quand les ensembles de données de travail sont volumineux.
• Analyse en mémoire : les Spark DataFrames, les opérations Pandas sur de gros ensembles de données et les outils similaires sont souvent limités par la bande passante mémoire plutôt que par la puissance de calcul quand les ensembles de données sont énormes.
• Calcul scientifique : les opérations matricielles , les transformations de Fourier et l'analyse par éléments finis sont des tâches classiques qui demandent beaucoup de mémoire et de bande passante, et c'est là que la DDR5 est vraiment au top.
• Traitement vidéo : les images vidéo 4K non compressées en couleur 10 bits ont besoin d'une bande passante mémoire constante pour être traitées en temps réel ; la DDR5 offre la marge nécessaire.

Capacité de 192 Go : pourquoi ça change la donne

La combinaison de la protection ECC et d'une capacité de 192 Go ouvre la voie à des catégories de charges de travail qui ne sont pas possibles sur des systèmes avec moins de mémoire :

Base de données complète en mémoire

Une PostgreSQL avec un ensemble de données de 100 Go stocké entièrement dans shared_buffers tourne complètement en mémoire après le préchauffage. Chaque requête va dans le cache tampon plutôt que sur le disque. Les E/S disque ne sont importantes que pour les écritures WAL et les opérations de nettoyage. La latence des requêtes dépend plus du CPU que des E/S.

Sur un serveur de 64 Go, cette même base de données de 100 Go oblige à vider et relire tout le temps des pages depuis le disque. La différence de performance n'est pas linéaire. Les applis qui tournaient avec un temps de requête moyen de 200 ms sur un serveur de 64 Go ont souvent un temps de requête de 20 à 40 ms sur un système où le jeu de travail tient dans la mémoire.

Grandes couches de mise en cache

Redis, avec 80 à 100 Go de données, tourne bien sur un système de 192 Go avec l'appli et le système d'exploitation. Du coup, pas besoin d'un serveur Redis séparé pour les charges de travail de mise en cache à mémoire élevée. L'infrastructure réduite (un serveur au lieu de deux) élimine aussi les allers-retours réseau entre l'appli et le cache, ce qui réduit généralement la latence d'accès au cache de 0,3 à 1 ms (réseau + TCP) à moins de 0,1 ms (boucle de retour).

Plusieurs zones d'isolement

Un serveur de 192 Go peut gérer en même temps une base de données de production (60 Go de mémoire tampon), un environnement de test (20 Go), une couche de mise en cache Redis (40 Go), des services d'application (20 Go) et une marge de manœuvre pour le système d'exploitation (16 Go) sans qu'aucune charge de travail ne pèse sur les autres. Cette consolidation n'est pas possible sur des configurations de mémoire plus petites sans sacrifier les performances.

ECC dans le contexte de la sauvegarde et du RAID

Une idée fausse courante, c'est que le RAID et les sauvegardes régulières rendent l'ECC inutile. Ils ne protègent pas contre le même type de panne.

• RAID : protège contre les pannes physiques du disque. Ne protège pas contre la corruption de la mémoire qui s'écrit en même temps sur les deux disques en miroir.
• Sauvegardes : protège-toi contre les suppressions accidentelles, les ransomwares et les pannes catastrophiques de disque dur. Une sauvegarde de données corrompues, c'est une sauvegarde de données corrompues.
• ECC : protège contre les erreurs de bits en mémoire avant qu'elles n'atteignent le stockage. Détecte les erreurs que le RAID et les sauvegardes ne peuvent pas détecter.

Les trois couches de protection servent à différents modes de défaillance. Un serveur de base de données de production a besoin des trois : une mémoire RAM ECC pour l'intégrité de la mémoire, un système RAID pour la tolérance aux pannes des disques et des sauvegardes hors site pour la reprise après sinistre. InMotion HostingPremier CareInMotion Hosting combine un espace de stockage automatisé de 500 Go pour les sauvegardes avec l'option Extreme Dedicated Server, couvrant ainsi deux des trois couches.

Pour commencer

Pour les serveurs de bases de données de production, les applications financières et toute charge de travail où la corruption silencieuse des données n'est pas acceptable, la mémoire RAM ECC n'est pas une option. Le serveur dédié Extreme l'inclut comme spécification de base à un prix qui rivalise avec les configurations de serveurs dédiés non ECC de nombreux fournisseurs.