01
Classez la conséquence avant de choisir la mémoire
Commencez par le chemin des données plutôt que par la famille de processeurs. Demandez-vous si une valeur incorrecte en mémoire pourrait être validée dans une base de données, écrite dans les métadonnées de stockage, signée, répliquée vers d'autres nœuds ou utilisée pour prendre une décision irréversible. Plus la sortie est durable et difficile à valider, plus le cas pour ECC est fort. Un exécuteur de build jetable dont les artefacts sont vérifiés indépendamment présente une conséquence différente d'un primaire de base de données ou d'un hôte de stockage.
La disponibilité et l'intégrité sont distinctes. Redémarrer un service sans état peut être peu coûteux, mais émettre silencieusement un artefact incorrect peut ne pas l'être. Inversement, ECC ne rend pas un hôte hautement disponible. Enregistrez la perte de données maximale acceptable, l'interruption et la conséquence d'erreur non détectée comme trois exigences distinctes.
Classez la conséquence avant de choisir la mémoire| Question de décision | Preuves à collecter | Implication |
|---|
| L'état de la mémoire peut-il devenir durable ? | Écritures, caches, index et chemins de signature | Préférez la correction d'erreur explicite et le rapport |
|---|
| La sortie peut-elle être reproduite ? | Hachages indépendants, réexécutions ou données sources | Un non-ECC peut être acceptable lorsque la conséquence est faible |
|---|
| Un hôte est-il un domaine de défaillance ? | Conception de réplique et de restauration | ECC nécessite toujours redondance et récupération |
|---|
| ECC est-il une exigence de politique ? | Exigence client, audit ou logiciel | Vérifiez la configuration livrée avant de commander |
|---|
02
Vérifiez le chemin mémoire complet
ECC est une propriété du chemin implémenté, pas d'une étiquette DIMM isolée. Le contrôleur mémoire du processeur, la carte mère, les paramètres du firmware et les modules installés doivent prendre en charge le mode prévu. Le système d'exploitation a également besoin d'un chemin de rapport approprié pour que les événements corrigés et non corrigés atteignent la surveillance. Ne déduisez pas ECC d'un nom de processeur de classe serveur, et ne traitez pas un champ d'inventaire générique comme preuve que la correction est active.
Pour une entrée de catalogue explicitement étiquetée ECC, conservez cette spécification avec le dossier de commande. Si la liste indique seulement DDR4 ou DDR5, demandez une confirmation lorsque ECC est obligatoire. Après le provisionnement, inspectez les preuves du micrologiciel et du système d'exploitation appropriées à la plateforme. L'EDAC Linux, lorsqu'il est pris en charge par le matériel et le pilote, distingue les événements corrigés des événements non corrigés du contrôleur mémoire ; l'absence d'un compteur ne prouve pas à elle seule qu'aucun événement ne s'est produit ou que le rapport est disponible.
03
Transformez les événements mémoire en actions opérateur
Définissez la réponse avant l'alerte. Capturez une base de référence après le déploiement, conservez les compteurs d'événements corrigés et non corrigés, et joignez l'emplacement de l'hôte, du socket ou du module lorsque la plateforme l'expose. Un événement corrigé signifie que le mécanisme a détecté et corrigé une erreur ; c'est une preuve opérationnelle utile, pas une raison d'ignorer un schéma croissant ou répété. Un événement non corrigé nécessite une évaluation rapide de la charge de travail et de l'intégrité des données même si la machine continue de fonctionner.
Définissez l'escalade en fonction de la récurrence, de la concentration et des conséquences sur la charge de travail au lieu de publier un seuil universel. Les fournisseurs de matériel et les plateformes diffèrent, et un seul chiffre ne peut pas tous les couvrir. Le manuel doit indiquer qui draine les charges de travail, quand les diagnostics sont collectés, comment les données sont vérifiées et quelles preuves sont requises avant de remettre l'hôte en service.
04
Sachez ce que ECC ne couvre pas
ECC ne remplace pas les sommes de contrôle du système de fichiers, la validation d'application, les répliques ou les sauvegardes versionnées. Il ne peut pas à lui seul corriger un bug logiciel, une mauvaise écriture déjà acceptée comme valide, des informations d'identification compromises, la suppression, une défaillance de contrôleur ou la perte du châssis. Les diagnostics de mémoire peuvent trouver certaines pannes présentes mais ne peuvent pas certifier qu'une panne future ne se produira jamais.
Le résultat attendu de cet exercice est un court enregistrement de décision : classe de conséquence, exigence ECC, preuve de configuration, source de surveillance et réponse aux incidents. Cet enregistrement est plus utile qu'une affirmation générale selon laquelle chaque charge de travail nécessite ECC ou que la mémoire non ECC est sans risque.
Réponses directes
Questions sur ce guide
Une seule erreur de mémoire corrigée signifie-t-elle que le serveur doit être remplacé ?
Pas automatiquement. Préservez l'événement, son emplacement et son schéma de récurrence, consultez les directives de la plateforme et appliquez la politique de risque de la charge de travail. Une concentration répétée est une preuve différente d'un rapport isolé, mais aucun ne doit être caché.
Un logiciel peut-il rendre la mémoire non-ECC équivalente à ECC ?
Les vérifications logicielles et les travaux reproductibles peuvent réduire les conséquences, mais ils ne donnent pas à la mémoire ordinaire la détection et la correction au niveau du contrôleur décrites par ECC. Utilisez-les comme contrôles supplémentaires, pas comme un mécanisme identique.