Cela fait une différence, cela n'aura de sens que si vous avez besoin des fonctionnalités RAS (fiabilité, disponibilité et service) sur les appareils x4 ou x8 et comprenez les compromis pour vos besoins. Plus de détails peuvent être expliqués dans le livre blanc Dell Serveurs Dell ™ PowerEdge ™ 2009 - Mémoire .
De plus, la configuration et la mise en page avec des détails spécifiques au R710 sont disponibles sur le guide technique du PowerEdge R710 - (Google ceci parce que je n'ai pas la réputation de lien).
Le problème important à noter est la différence entre l'ECC sur la puce et l '"ECC avancé" fourni par le BIOS de Dell pour la correction de données de périphérique unique (SDDC). Vous aurez un impact sur les performances des deux. L'ECC se remettra des erreurs pendant les écritures sur la puce. Cependant, SDDC va plus loin et organisera les bits de sorte qu'une puce entière puisse échouer et être toujours récupérable. Voir un exemple et des détails Chipset SDDC E7500
La question est de savoir si vos performances et / ou votre fiabilité sont de la plus haute importance dans votre utilisation spécifique de la machine. Si une défaillance de puce entraîne une perte de données critiques ou d'utilisation sur cette machine et qu'elle n'est pas redondante dans la mise en œuvre, Advanced ECC peut être un excellent moyen de procéder. Cependant, vous le faites avec un impact sur les performances qui peut être plus important pour vous.
J'ai implémenté les deux sur le terrain sur les serveurs Dell PowerEdge pour les implémentations uniques de Microsoft SQL Server. Si je peux vous être plus utile, faites un commentaire pour me le faire savoir.
J'espère que cela pourra aider.
EDIT: Écart de couverture / implémentations ECC
Oui, il existe un écart de couverture même si vous implémentez les deux. Étant donné que vous utilisez spécifiquement un cluster de serveurs à haute disponibilité, à mon humble avis, vous devez utiliser l'ECC avancé. Votre impact sur les performances est minime par rapport aux avantages pour les appareils en cluster. Selon Crucial, vous n'avez qu'une diminution de 2% des performances sur la mémoire ECC en général.
L'écart serait plus spécifique aux types d'erreurs qui se produisent et à la façon dont chacun traite les erreurs. Dans votre situation spécifique, cela ne devrait pas se traduire par une perte de données. Comme il s'agit d'un SGBD d'entreprise et que les erreurs, les problèmes de concurrence, etc. sont gérés au niveau du logiciel afin d'éviter la perte de données. Un historique détaillé des modifications dans un SGBD correctement configuré est conservé et le logiciel qui l'utilise peut généralement être configuré pour que la transaction soit annulée en cas d'erreur grave.
Implémentations ECC
ECC tentera de corriger toute erreur de bit dans la lecture / écriture de la mémoire. Cependant, si l'erreur est plus importante, même ECC ne pourra pas récupérer, entraînant une perte potentielle de données. Il y a aussi plus de discussion sur ECC à ServerFault / Qu'est-ce que la RAM ECC et pourquoi est-ce mieux?
Selon Wikipedia sur ECC_Memory
La mémoire ECC maintient un système de mémoire efficacement exempt d'erreurs sur un seul bit ...
SDDC
Si vous vous référez au document du chipset E7500 ci-dessus (notez que les 55xx / 56xx d'Intel nécessitent une connexion / un partenariat mais l'idée est similaire, c'est pourquoi je n'ai pas créé de lien à l'origine), qui décrit le SDDC et comment cela est rendu possible. Fondamentalement, il utilise une technique pour organiser les mots écrits en mémoire qui garantit que tous sont écrits de manière à ce que chaque mot ne contienne qu'une erreur sur un seul bit, c'est-à-dire que le mot doit être récupérable à partir de l'erreur sur un seul bit (comme ci-dessus). Maintenant que c'est par mot, il pourrait potentiellement récupérer des erreurs jusqu'à 4 bits sur les appareils x4 (1 par mot) et jusqu'à 8 erreurs sur les appareils x8 (toujours 1 par mot) en corrigeant les erreurs de chaque mot.
Des erreurs supplémentaires, davantage d'erreurs de bits, une défaillance totale de la mémoire, une défaillance de canal, une défaillance de bus, etc. peuvent toujours causer des problèmes horribles, mais c'est pourquoi vous avez un cluster et un SGBD d'entreprise.
En bref, si vous avez tout activé et qu'il y a trop d'erreurs binaires pour que les algorithmes de correction d'erreur puissent les corriger, vous aurez toujours une erreur, c'est-à-dire un écart de couverture d'erreur. Ceux-ci peuvent cependant être exceptionnellement rares.