Archivos de Tags: hardware

ConnectX4 LX: Molan, hasta que se atascan

nVidia (nacida Mellanox) dice en sus notas de actualización de firmware que es un «rare case». Pero a todos nos mira un tuerto de vez en cuando, y ese día no fue de extrañar que un Dell r630 dejara de ver sus dos puertos SFP28 (en la tarjeta rNDC, pero esto es irrelevante; es PCIe, al fin y al cabo).

En lugar de los SFP28, nos gratificó con un arranque bastante lento y un críptico error en syslog:

mlx5_core 0000:01:00.0: mlx5_function_setup:995:(pid 252450): Firmware over 120000 MS in pre-initializing state, aborting
mlx5_core 0000:01:00.0: probe_one:1484:(pid 252450): mlx5_init_one failed with error code -16

Los dispositivos, en consecuencia, no aparecieron en el sistema operativo, convirtiendo este servidor en un nada práctico pisapapeles.

¿Y qué es lo que pasaba? Una bonita tarde de domingo escarbando (con el dueño del servidor cerca de un desfibrilador), reveló esta perla en las notas de versión del firmware:

- Fixed a rare case where the the device hanged while running the sw reset flow under heavy stress and with many open resources.

Bueno, no era mucho, pero tras haber rearrancado mil veces el servidor y hasta haberlo apagado y encendido, no quedaba mucho más que pudiera ser. Bien fuera este caso o un primo hermano, suele merecer la pena actualizar el firmware de los diferentes subsistemas: El mantenimiento de firmware suele consistir casi siempre en correcciones de errores, siendo la introducción de errores nuevos relativamente infrecuente.

Con Dell hemos topado

En general, Dell hace las cosas bastante bien y el Open Manage Enterprise, que permite actualizar firmwares sin dolor y masivamente, por sus muchos defectos, es una herramienta de lo más útil. Si el servidor en cuestión está integrado, claro. Lo cual no era este caso porque es un servidor de un cliente; y, para añadir insulto a la ofensa, ni la iDRAC, ni el lifecycle controller local veían posible actualizar el firmware. Decían que ese dispositivo no está en el sistema. Lo sabrán ellos.

Total.

  • Descargar las herramientas de gestión de firmware de nVidia;
  • Descargar el firmware de Dell para la tarjeta en cuestión;
  • Desempaquetar el firmware del putrefacto .EXE que suministra Dell (unzip es suficiente).
  • Averiguar gracias a lspci -vv cuál de los tres firmwares sin más explicación es el correcto para la tarjeta rNDC (lspci da el nombre de la pieza, que forma parte del nombre del archivo de uno de los tres .bin que el paquete de Dell incluye en payload/). Como para unas prisas:
# lspci -vv | grep PN
        [PN] Part number: 0R887V
        [PN] Part number: 0R887V
# ls networkfirmware900n0/payload/ | grep 0R887V
fw-ConnectX4Lx-rel-14_31_1014-0R887V-UEFI-14.24.13-FlexBoot-3.6.403.bin
  • Quemar
# flint -d 01:00.0 -i networkfirmware900n0/payload/fw-ConnectX4Lx-rel-14_31_1014-0R887V-UEFI-14.24.13-FlexBoot-3.6.403.bin b
  • Rearrancar el firmware
# mlxfwreset -d 01:00.0 reset

Y listo, a funcionar. Rearrancamos y actualizamos todo, ya que estamos, hacemos un bonito artículo por si alguien se ve en las mismas, y nos acabamos el café.

El flujo de aire en los equipos de red

Es una vieja pelea, de esas que acaban por diluírse en el tiempo, poco a poco, con cambios que se van sucediendo y que acaban por hacer el problema irrelevante.

Los servidores, por una herencia que se remonta al diseño de los PCs originales, absorben aire frío por la parte delantera (donde están normalmente los botones, los dispositivos de almacenamiento, y las lucecitas) y los echan caliente por la trasera (donde están generalmente los conectores, enchufe y cerca de donde se sitúan las fuentes de alimentación).

Los switches de red, por su parte, empezaron por ventilarse de un lado al otro. ¿Por qué? Fácil: Es por donde había hueco. 48 puertos RJ-45 ocupan prácticamente todo el frontal de 1U en un armario de 19″. ¿Y los routers? Pues como Cisco decidió en su día: Pusieron en el frontal los conectores de red, en la trasera el de alimentación… Y empezaron a bufar hacia el lado contrario que los servidores.

Cuando la densidad fue creciendo en los centros de datos, la cosa empezó a ser un problema. Todo el mundo copió a los fabricantes pioneros como Cisco, y el resultado es que a 2016, los equipos de Mikrotik hacen lo que hacía Cisco en los 90: Coger aire del frontal, donde está su pantallita, sus luces y sus conectores, y echarlo hacia «atrás», que es donde está la fuente y el conector de alimentación.

Y con ello, los routers, definitivamente, quedan sólidamente establecidos con flujos de aire exactamente al revés que los servidores: Del lado donde están los conectores, al otro. Mientras que los servidores, fieles a su larga tradición, siguen enviando el aire del «otro» lado, al de los conectores.

En un centro de datos clásico, donde lo que hay es aire frío a cascoporro, cada equipo está montado como cayó, y los flujos de aire no están definidos, eso no es un problema. Pero, ¿qué ocurre en un centro de datos moderno, con separación de pasillo frío y caliente? Pues muy sencillo. Como de lo que más hay es servidores, se puede elegir entre tres alternativas para los equipos de red:

  1. Ponerlos con los conectores al mismo lado que los servidores, y que se frían por estar «respirando» aire caliente;
  2. Ponerlos con un flujo de aire correcto y pasar el resto de la vida moviendo cables de un lado a otro del armario;
  3. Arreglar el bendito problema de una vez, invirtiendo el flujo de aire para hacerlo igual que el de los servidores.

Así que, sin discurrir mucho más, vamos a examinar la alternativa 3.

Empezaremos por hacer notar que algunos fabricantes como Cisco o Juniper, en su infinita sabiduría, hace poco empezaron a fabricar switches (algunos, no todos) que se pueden pedir con los flujos de aire en un sentido o en otro, o incluso dar la vuelta a voluntad. Esto es perfecto para un entorno de centro de datos, sobre todo si hablamos de switches con 48 puertos y por tanto 48 cables que no hay que pasar de un lado al otro del armario y, lo que es más engorroso, mantenerlos.

Sin embargo, si vamos a ver los populares routers de Mikrotik, veremos que, ocupados en detalles sin importancia como crear equipos de una relación precio/potencia de otro mundo, siguen haciendo lo que Cisco en los años 90: Mover el aire al revés que los servidores.

Arreglemos, pues, ese problema.

En los CCR1036, la cosa es fácil. Solo tienen dos ventiladores, exactamente delante del disipador del procesador. Dos tornillos por cada uno, se les da la vuelta y problema resuelto.IMG_8714

En los CCR1072, la cosa es ligeramente más complicada. Llevan seis ventiladores: Cuatro delante del disipador del procesador (que se invierten de manera análoga a como se hace en los 1036) y uno en cada una de las dos fuentes de alimentación. En su infinita sabiduría, Mikrotik ha decidido que los tornillos de la carcasa de la fuente de alimentación sean T-5 (o por ahí), es decir, tirando a rarillos. Nada que no pueda resolver un juego de destornilladores «de precisión», que el chino de la esquina suministrará sin problema ninguno. Hay que desmontar completamente la fuente, sacando la PCB fuera, para acceder todos los tornillos. Pero hecho esto, y rutado el cable del ventilador por un lateral, se acabaron los problemas.

Por cierto, que todos los tornillos dentro de la fuente son los habituales Phillips del número 2. Y nos quejamos cuando Apple hizo aquella jugadita del «pentatorx»…IMG_8716

En el momento de escribir esto, he efectuado la operación en varios 1036 y un par de 1072. Como estos son los más grandes, parecen más interesantes. Pues bien, con el flujo de aire corregido, y cursando 1 Gbps de tráfico, la CPU se mantiene en unos tranquilizadores 50C y 54C; y eso, teniendo justo debajo un par de Catalyst con el flujo de aire al revés.