¿Es necesario grabar RAM para hardware de clase de servidor?

31

Teniendo en cuenta el hecho de que muchos sistemas de clase de servidor están equipados con RAM ECC , ¿es necesario o útil grabar los DIMM de memoria antes de su implementación?

Me encontré con un entorno en el que toda la RAM del servidor se coloca a través de un largo proceso de quemado / prueba de esfuerzo. Esto ha retrasado las implementaciones del sistema en ocasiones y afecta el tiempo de entrega del hardware.

El hardware del servidor es principalmente Supermicro , por lo que la RAM proviene de una variedad de proveedores; no directamente del fabricante, como Dell Poweredge o HP ProLiant .

¿Es este un ejercicio útil? En mi experiencia pasada, simplemente utilicé la RAM del proveedor fuera de la caja. ¿No deberían las pruebas de memoria POST capturar la memoria DOA? Respondí a los errores de ECC mucho antes de que un DIMM realmente fallara, ya que los umbrales de ECC generalmente eran el disparador para la colocación de la garantía.

  • ¿Quemas tu RAM?
  • Si es así, ¿qué método (s) utiliza para realizar las pruebas?
  • ¿Ha identificado algún problema antes de la implementación?
  • ¿El proceso de quemado ha resultado en una estabilidad adicional de la plataforma en lugar de no realizar ese paso?
  • ¿Qué haces al agregar RAM a un servidor en ejecución existente?
ewwhite
fuente

Respuestas:

25

Encontré un documento de Kingston que detalla cómo funcionan con Server Memory, creo que este proceso, normalmente, sería el mismo para la mayoría de los fabricantes conocidos. Los chips de memoria, así como todos los dispositivos semiconductores, siguen un patrón particular de confiabilidad / falla que se conoce como la curva de la bañera:

ingrese la descripción de la imagen aquí

El tiempo se representa en el eje horizontal, comenzando con el envío de fábrica y continuando a través de tres períodos de tiempo distintos:

  • Fallas tempranas de la vida: La mayoría de las fallas ocurren durante el período de uso temprano. Sin embargo, a medida que pasa el tiempo, el número de fallas disminuye rápidamente. El período de fracaso de la vida temprana, que se muestra en amarillo, es de aproximadamente 3 meses.

  • Vida útil: durante este período, las fallas son extremadamente raras. El período de vida útil se muestra en azul y se estima en más de 20 años.

  • Fallas al final de la vida útil: finalmente, los productos semiconductores se desgastan y fallan. El período de fin de vida se muestra en verde

Ahora, debido a que Kingston notó que las altas tasas de falla ocurrirían los primeros tres meses (después de estos tres meses, la unidad se considera buena hasta que sea EOL unos 15-20 años después). Diseñaron una prueba usando una unidad llamada KT2400 que prueba brutalmente los módulos de memoria del servidor durante 24 horas a 100 grados centígrados a alto voltaje, mediante el cual se ejercitan continuamente todas las celdas de cada chip DRAM; Este alto nivel de pruebas de esfuerzo tiene el efecto de envejecer los módulos por al menos tres meses (como se señaló antes del período crítico en el que la mayoría de los módulos muestran fallas).

Los resultados fueron:

En marzo de 2004, Kingston comenzó una prueba de seis meses en la que se probó el 100 por ciento de la memoria de su servidor en el KT2400. Los resultados fueron monitoreados de cerca para medir el cambio en las fallas. En septiembre de 2004, después de compilar y analizar todos los datos de la prueba, los resultados mostraron que las fallas se redujeron en un 90 por ciento. Estos resultados excedieron las expectativas y representan una mejora significativa para una línea de productos que ya estaba en la cima de su clase.

Entonces, ¿por qué la grabación en memoria no es útil para la memoria del servidor? Simplemente, porque ya lo hizo su fabricante!

Lucas Kauffman
fuente
10
El fabricante del chip, y tal vez incluso el vendedor del servidor, pueden probar algunos chips. Pero los componentes mst solo se prueban en muestras en estos días para reducir los costos. Incluso si alguna vez se probaron sus chips o DIMM completos, eso no le dice si los contactos o PCB de alguna manera se ajustaron o se estropearon durante el ensamblaje o el envío. Hemos tenido un problema de memoria de MemTEst86 para encontrar problemas con la memoria de dos servidores diferentes, listos para usar de dos proveedores de servidores de "nivel 1" diferentes. Si hubieran llegado a producción, ECC podría habernos salvado, pero el resultado podría haber sido la corrupción silenciosa de la base de datos.
rmalayter
77
Esta curva de bañera no es solo para semiconductores. La mayoría de los componentes construidos con algún grado de control de calidad que siguen: discos duros, unidades SSD, fuentes de alimentación (principalmente a causa de los condensadores), ventiladores, etc.
voretaq7
66
Esta es una de las razones por las que nunca compro garantías extendidas en productos electrónicos. El dispositivo (o componente) fallará en los primeros meses o durará el resto de su vida útil. Esto también demuestra por qué es tan importante eliminar las manzanas podridas lo antes posible para que pueda navegar sin problemas lo antes posible.
Atari911
@rmalayter ¿De todos modos recomendarías quemar la RAM?
ewwhite
2
@ewwhite Sí, lo probaría. Solo lleva unas horas arrancar memtest86 y dejar que compruebe 384 GB de RAM. También grabamos en todos los subsistemas de almacenamiento usando IOmeter por la misma razón. Hubo varios controladores o unidades RAID que murieron en nosotros durante el encendido durante los últimos años, a pesar de que inicialmente funcionaron bien durante la instalación del sistema operativo. A veces era un problema de firmware malo, a veces RAM defectuosa de la memoria caché en el controlador RAID, a veces era "quién sabe, ¡RMA!"
rmalayter
30

No.

El objetivo de grabar en hardware es enfatizarlo hasta el punto de catalizar una falla en un componente.

Hacer esto con discos duros mecánicos obtendrá algunos resultados, pero no va a hacer mucho por la RAM. La naturaleza del componente es tal que los factores ambientales y la edad tienen muchas más probabilidades de ser la causa de fallas que la lectura y escritura en la RAM (incluso en su ancho de banda máximo durante unas pocas horas o días).

Suponiendo que su RAM es de una calidad lo suficientemente alta como para que la soldadura no se derrita la primera vez que realmente comienza a usarla, un proceso de quemado no lo ayudará a encontrar defectos.

Shane Madden
fuente
15

Compramos blades y, en general, compramos un bloque razonablemente grande de ellos a la vez, por lo que los instalamos e instalamos durante DÍAS antes de que nuestros puertos de red estén listos / seguros. Por lo tanto, usamos ese tiempo para usar memtest durante aproximadamente 24 horas, a veces más si dura un fin de semana; una vez hecho esto, pulverizamos el ESXi básico e IP está listo para que se aplique su perfil de host una vez que la red está activa. Así que sí, lo probamos, más por oportunidad que por necesidad, pero ha detectado algunos DIMM DOA antes, y no soy yo quien lo hace físicamente, así que no me cuesta ningún esfuerzo. Estoy a favor

Chopper3
fuente
3
Una "prueba de oportunidad" tiene sentido, dada la posibilidad de que lo haga. Si va a retrasar las implementaciones, puedo arriesgarme a tener un DIMM malo y una luz ECC :-)
voretaq7
2
Si integra la prueba en el plan de implementación, entonces se ha ganado el tiempo, si solo hace todo lo más rápido posible, está preparándose para las críticas en una fecha posterior. Administración de brazo fuerte siempre que puedas :)
Chopper3
@ Chopper3 Entonces, si estabas estableciendo una política, ¿lo haces siempre? , Hacer nunca? o hacerlo cuando puedas? .
ewwhite
@ewwhite: diría esto último, aunque tendemos a diseñar eso en el plan de implementación estándar, por lo que es muy probable que cada vez.
Chopper3
11

Bueno, supongo que depende exactamente de cuáles sean sus procesos. SIEMPRE ejecuto MemTest86 en la memoria antes de ponerlo en un sistema (servidor o no). Después de tener un sistema en funcionamiento, los problemas causados ​​por una memoria defectuosa pueden ser difíciles de solucionar.

En cuanto a "prueba de esfuerzo" en realidad la memoria; Todavía tengo que ver por qué esto sería útil a menos que esté probando para fines de overclocking.

Atari911
fuente
¿Qué te dice MemTest86? ¿Ha encontrado problemas de RAM antes de instalarlo en un servidor utilizando este método?
ewwhite
44
He encontrado muchos errores con MemTest86 + que los diagnósticos de BIOS y memoria de Windows no encontrarán. Lo recomiendo altamente. Sí, ECC encontrará los mismos errores, pero un memtest lo ayudará a encontrarlos antes de tiempo.
Owen Johnson
66
MemTest le informará si hay fallas en el interior de la memoria. Lo hace almacenando patrones de bytes, así como conjuntos aleatorios de bytes en la memoria en un intento de desencadenar un error. El programa puede ejecutar un "pase" para hacerle saber si la memoria es buena, pero generalmente ejecuto varios pases durante la noche solo para asegurarme. Lo bueno de MemTest es que me dice si la memoria es mala antes de implementar el sistema. Ha desencadenado un RMA muchas veces y me ha ahorrado muchos dolores de cabeza. Una vez que se despliega la máquina, es un dolor en el @ss para RMA la memoria.
Atari911
2
@OwenJohnson Generalmente, cuando ejecuta MemTest86 (+), espera activar esos errores de ECC antes de poner la máquina en producción :-)
voretaq7
6

No, pero he visto personas que sí. Sin embargo, nunca los vi ganar nada de eso, creo que tal vez sea una resaca o una superstición.

Personalmente, soy como tú en que las tasas de error de ECC son más útiles para mí, suponiendo que la RAM no sea DOA, pero de todos modos lo sabrías.

Sirex
fuente
6

Para ram no ECC, ejecutar 30 minutos en memtest86 + es útil ya que generalmente no hay un método confiable para detectar errores de bit cuando el sistema está en ejecución.
La revisión azul no se considera un método confiable ...
Y la RAM ligeramente escamosa a menudo no se muestra de inmediato, solo después de que el sistema ha visto una carga de memoria completa y luego solo si los datos en esa RAM fueron el código que se usó y Luego se estrelló. La corrupción de datos puede pasar desapercibida durante largos períodos de tiempo.

Para ECC ram no hará nada que el controlador de memoria no hará, por lo que realmente no tiene sentido. Es solo una pérdida de tiempo.

En mi experiencia, las personas que insisten en quemar son usualmente viejos que siempre lo han hecho así y que lo siguen haciendo por costumbre sin pensar realmente que las cosas son ciertas.
O son jóvenes que siguen el procedimiento prescrito escrito por esos viejos.

Tonny
fuente
¿Mal conocimiento transmitido de generación en generación?
ewwhite
@ewwhite Sí, hasta donde yo sé. Y tengo un Bsc. en tecnología de hardware, así que se supone que debo saber de lo que estoy hablando :-)
Tonny
a excepción de todos los incidentes de personas que realmente encontraron errores, como se muestra en el hilo. Además, si no es obvio, hay una diferencia en intercambiar las partes antes de poner un servidor en producción o reemplazar ram en un servidor de base de datos que se ejecuta en 24x7. A menos que pretenda que es un "error Grown" y todos los demás son viejos y hacen cosas de culto de carga, pero aún así causará pérdidas tener un servidor de productos fuera de línea.
Florian Heigl
1
@FlorianHeigl No abogo por quemar en RAM por el simple hecho de hacerlo, pero nunca respaldaré poner un servidor en producción, sin que sea sometido a pruebas de estrés durante al menos 24 horas. La RAM no suele ser el problema. Discos duros, controladores RAID, tarjetas IPMI, fuentes de alimentación, CPU, VRM ... Lo he visto todo. (Y a menudo el servidor sobrevive a la instalación inicial muy bien. Es la carga y / o la salud lo que lo hace cuando realmente tiene que funcionar).
Tonny
3

Depende.

Si está implementando 50 000 nuevas RAM, y sabe que este hardware en particular tiene una tasa de falla del 0.01% después de operar menos de un día, estadísticamente hablando habrá varios de ellos que fallarán en su primer día. Quemarse para atrapar eso. Con implementaciones en esa escala, se espera un fracaso, no una situación excepcional.

Sin embargo, si está desplegando solo un par de cientos de elementos, es muy probable que las estadísticas estén de su lado, ya que debe ser bastante desafortunado para obtener piezas fallidas.

Lie Ryan
fuente
Usted tiene un punto. Btu seamos sinceros, la mayoría de nosotros nunca haremos implementaciones tan grandes. (A menos que esté creando un nuevo centro de datos de Google). La mayoría de nosotros normalmente implementamos como máximo de 5 a 10 servidores al mismo tiempo. El más grande que hice personalmente fue 16 nodos ESX (grupos de 4x 4 nodos), cada uno con 8 DIMM. Eso fue hace 3 años y desde entonces 1 DIMM falló (hace 2 meses). Tuve que reemplazar 5 fuentes de alimentación en esas mismas máquinas. Primero 1 después de una semana ya. Pero como estos son HP Proliants, más o menos lo esperábamos. (HP y fuentes de alimentación ... No me hagas empezar ...)
Tonny