¿Cuál es el valor agregado de instalar los controladores suministrados por Dell / HP / IBM / etc.?

Administro un par de cientos de servidores Linux, la mayoría de los cuales son HP, si no están virtualizados. Históricamente, hemos instalado el paquete de soporte HP ProLiant (PSP) desde antes de comenzar a trabajar aquí. La PSP viene con cosas útiles (?) Como la página de inicio de HP System Management, que nunca he usado, pero algunos de mis colegas lo hacen regularmente, y un montón de controladores.

Algunos de estos controladores, como el módulo de kernel de iLO, no se encuentran en el kernel original que utilizamos, por lo que puede ser útil instalarlos. Sin embargo, otros controladores, como los controladores cciss y qla2xxx que suministra HP, no son tan útiles: están en el núcleo de inventario y lo han estado durante bastante tiempo. Sobrescribir los controladores de stock probablemente anulará el soporte de nuestro proveedor en varios subsistemas del núcleo, no en todo el núcleo. Por otro lado, HP podría no admitir ciertos problemas si no utiliza sus controladores.

Tiendo a inclinarme a no instalar los controladores de HP, pero ¿qué piensas: hay una razón tentadora para instalar los controladores cciss, qla2xxx, e1000, tg3, bnx2 (etc.) de HP y sobrescribir los controladores provistos en el paquete de kernel de stock?

Editar: 'la razón tentadora para instalar' debe ser lo suficientemente grande como para mitigar la desagradable calidad de los paquetes de PSP, lo que significa que tengo que volver a empaquetarlos todos manualmente para poder instalarlos a través de un método centralizado como RH Satellite.

Tenemos muchos servidores Red Hat y hemos considerado instalar la PSP. El problema siempre se reduce a la compatibilidad con el núcleo de erratas de HP en comparación con lo que está vigente en los canales de Red Hat. Tuvimos la experiencia de que la versión de Red Hat de los controladores estaba más actualizada que la proporcionada por PSP. En otra ocasión, la PSP nos limitó a una versión de un núcleo de erratas, lo que no nos hizo muy felices. Ahora, hubo ocasiones en que Red Hat no registró mensajes por problemas con el hardware. Lo cual es bastante malo en los servidores de producción, tener servidores caídos o bloqueados sin ninguna información o registros de la causa no es divertido. En este punto tenemos un híbrido, hemos elegido los paquetes que no necesitan una versión específica del núcleo para funcionar; como hp-health, hpacucli y el monitoreo tal. Creo que si HP / Red Hat y el resto son tan ajustados, deberían trabajar juntos e incluirlos en la distribución de Red Hat. No tiene sentido que haya incluso un paquete de soporte independiente de la distribución misma.

SIEMPRE instalamos la PSP con nuestras máquinas HP, principalmente para alimentar adecuadamente a HP SIM con la información correcta. Esto permite que SIM administre centralmente el código de BIOS / controlador y, lo que es más importante, habilita la advertencia de 'falla previa' en todo el sistema y el reemplazo de hardware. Específicamente, si un componente de hardware está a punto de fallar, nos alertará, llamará directamente a HP para la parte y el hombre con un nuevo bit aparecerá para reemplazarlo antes de que incluso falle.

Respuesta agnóstica del vendedor.

Debe comunicarse con el proveedor de hardware y preguntarles cuáles son las repercusiones de soporte si instala sus controladores frente a los controladores del sistema operativo. ¿Compraste el sistema operativo de ellos? ¿Son compatibles si no están ejecutando Windows, Red Hat, SUSE, lo que sea?

Por lo general, el valor agregado en sí es tal como usted lo implica: características adicionales de administración del servidor. La mayoría de las veces, en mi experiencia, estas características no son tan útiles si está automatizando su entorno con algo más que las herramientas suministradas por el proveedor, o una de sus marcas afiliadas (es decir, IBM y Tivoli, HP y OpenView, etc.).

Por lo que vale, automatizamos la instalación del software de la consola remota Dell 2950 que permitió la conexión al dispositivo DRAC a través de VNC y la GUI de administración de almacenamiento para los MD3000. Ambos se recomiendan, y fue más fácil automatizar que explicarle a Dell "no, no usamos esa basura, usamos lo que viene con el sistema operativo". Especialmente porque estábamos usando CentOS en lugar de Red Hat.

Aquí, en el mundo de Windows, encontramos que Dell no ofrecerá soporte a menos que esté utilizando sus controladores, y generalmente cuando abre una llamada, lo primero que hacen es insistir en que instale la última versión de los controladores antes de que toquen el servidor . No sé si esto se aplica a Linux porque no sé qué soporte de Linux ofrecen, pero lo comprobaría.

JR

PS No creo que he vez encontrado el fallo que se debe a no usar un controlador de Dell. Eso sí, nunca he sabido que los controladores de Dell causen un problema. Ir junto con Dell parece el camino de menor resistencia :-)

En primer lugar, los servidores HP están certificados por Red Hat y Suse, y de todos modos puede obtener soporte completo de Red Hat a través de HP, de modo que no se preocupe por las garantías en ningún caso.

En segundo lugar, la administración de energía es una gran razón para instalar los controladores más recientes. Si tiene un servidor, tal vez no sea gran cosa, si tiene varios chasis de hoja completa, gran cosa.

En tercer lugar, como comenté anteriormente, HP System Insight Manager (o Dell OpenManage).

Cuarto, si tiene un entorno de administración de parches y tiene que actualizar los parches dentro de un cierto período de tiempo, el seguimiento de ellos a través de SIM realmente ayuda.

Si está utilizando SIM, debería poder impulsar nuevos controladores a través de eso, en lugar de volver a empaquetarlos (descargo de responsabilidad: sé que esto funciona en Windows pero no soy un administrador de Linux, así que YMMV). Además, HP, como Dell, siempre le indicará que actualice todo a la vista antes de proceder con un caso de soporte.