El trabajo en equipo puede ser la herramienta empresarial más poderosa del planeta. Para respaldar esto, compartiré una gran historia de lo que sucede cuando los equipos ad hoc de todo el mundo se unen espontáneamente para resolver problemas críticos de los clientes.
Soy Gerente Técnico de Cuentas (TAM) de Red Hat. Hace unos meses, un cliente me contactó acerca de una interrupción importante cuando la unidad de arranque del sistema falló simultáneamente en docenas de sistemas de hipervisor en cuatro sitios diferentes. La interrupción eliminó cientos de máquinas virtuales y tensó los sitios de respaldo en los EE. UU.
Esto lleva al primer misterio. ¿Cómo pueden fallar simultáneamente docenas de unidades de arranque del sistema para múltiples hipervisores en múltiples sitios? También trae consigo un objetivo: hacer que esos sitios vuelvan a funcionar lo más rápido posible, porque el tiempo de inactividad cuesta dinero.
Después de que el proveedor de hardware reemplazó la unidad de arranque fallida y actualizó el firmware del sistema en todos los sitios afectados, llegó el momento de recuperarse.Nuestro plan: reinstalar un paquete especial de Red Hat Enterprise Linux (RHEL) llamado Hipervisor de virtualización de Red Hat (RHV-H) Conéctese desde el metal desnudo al almacenamiento central existente. RHV-H es un dispositivo que proporciona suficiente RHEL para alojar máquinas virtuales, administrado por un motor central llamado RHV-M. Necesitamos configurar RHV-M como una máquina virtual alojada en el entorno que va a administrar. Esta configuración se denomina motor autohospedado.
El primer sitio ejecutaba un motor autohospedado en un hipervisor que aún no se había actualizado, pero que tenía un disco de arranque dañado. ¿Tal vez podamos salvar este entorno construyendo otro hipervisor y migrando el motor autohospedado a él? Sam, del equipo de soporte de virtualización, nos ayudó, pero sin un disco de arranque que funcionara en el hipervisor que aún estaba en funcionamiento, el esfuerzo de rescate resultó ser inútil. Así que lo cerramos y reconstruimos el primer sitio desde cero.Sam nos ayudó a resolver este problema.
Mientras miraba uno de los sistemas afectados pasar por la autoprueba de encendido (POST), noté el nombre de la unidad de arranque del fabricante. El mensaje POST dice que el «disco» de arranque es un conjunto de unidades de estado sólido (SSD), no un disco duro giratorio.
[ Download the whitepaper to learn how IT modernization can help alleviate technical debt. ]
Más tarde, tuve una conversación con varios miembros del equipo de soporte mejorado de Red Hat y mencioné al proveedor de SSD. Segundos después, Jacob compartió un artículo en el que afirmaba que un error de firmware convirtió un lote de SSD producido antes de marzo de 2020 en ladrillos inútiles después de 40 000 horas. Los fabricantes de SSD y los proveedores de sistemas que utilizan estos SSD escribieron avisos, emitieron parches y capturaron los sistemas más afectados.
Pero no todos.
Esto explica las fallas simultáneas. Esta no es la primera vez que un firmware defectuoso falla en un sistema de almacenamiento. Y puede que no sea el último.
Armado con la experiencia del primer sitio, el cliente y yo comenzamos a reconstruir el siguiente sitio. Pero 4 de cada 10 tarjetas de interfaz de red (NIC) no aparecen en las listas de NIC activas de algunos hipervisores.es enloquecedor porque lspci El comando muestra todas las tarjetas de red.
Esto lleva al siguiente misterio. RHEL ve las tarjetas originales en el bus PCI, ¿por qué la red no las activa? ¿Qué los hace diferentes del primer sitio, todas las NIC funcionan como se esperaba? Sara y Theresa, del equipo de redes, revisaron los registros y encontraron el siguiente mensaje:
ixgbe 0000:07:00.0: failed to load because an unsupported SFP+ or QSFP module type was detected.Esto conduce a una Artículos de la base de conocimientos Con respecto a los transceptores conectables (SFP) de factor de forma pequeño no admitidos en NIC Intel de 10 GB. La industria de las redes ofrece innumerables opciones para conectores de 10 GB, y los proveedores de NIC sufrirían la pesadilla logística de construir tarjetas que admitan todos los conectores posibles. Por lo tanto, los proveedores de NIC usan SFP para emparejar tarjetas con una lista cada vez mayor de conectores de fibra o cobre. Pero Intel solo admite unas pocas opciones de SFP, y los SFP con estas NIC no se encuentran en la lista compatible de Intel. El primer sitio debe usar un SFP compatible. Esa es la diferencia.
[ Get a hands-on introduction to daily life as a developer crafting code on OpenShift in the O’Reilly eBook OpenShift for Developers. ]
El artículo de KB proporciona algunas sugerencias para resolver el problema al cargar ixgbe Controlador NIC con parámetros especiales para permitir SFP no compatibles. Descargue y vuelva a cargar manualmente el controlador con parámetros especiales. Sin embargo, todas las sugerencias para cargarlo automáticamente de esta manera al inicio fallan.
Es hora de ser creativo. Necesitamos una forma de descargar y recargar automáticamente el controlador al inicio con los parámetros correctos. Esto requiere un archivo de unidad systemd. Albert trabajó con el equipo de soporte mejorado de Red Hat para proporcionar un borrador escondido en un repositorio de Git. Personalicé el borrador de Albert para adaptarlo a esta situación y, después de algunas pruebas, todo funcionó. Luego, actualicé el artículo de KB con la nueva estrategia.
Aún no hemos terminado. Otros podrían estar sentados en la misma bomba de relojería cuando los SSD de firmware defectuosos colapsaron esos sitios.Entonces, registré el problema de SSD Otro artículo de la base de conocimientos E incluye un enlace a un boletín de proveedores con actualizaciones de firmware.
Pero dado que los proveedores de sistemas enmascaran los SSD originales con sus propios números de modelo y versión, ¿quién sabe si sus SSD originales se ven afectados? Dwight descubrió un método que funcionó para al menos un producto de servidor de un proveedor y editó el artículo original según su sugerencia. Otros miembros del equipo también proporcionaron aclaraciones en ediciones posteriores.
Mientras tanto, los cuatro sitios han vuelto a sus operaciones normales.
En muchas organizaciones, la gente habla de encontrar formas de derribar muros, fomentar el trabajo en equipo y dar rienda suelta a la creatividad. Ese es el secreto: no necesitas fórmulas secretas.Necesita un grupo de personas, incluidos los gerentes, hasta el CEO, que son deseoso de abrazar la apertura.
La transparencia es buena. Lo mismo ocurre con la rendición de cuentas que genera confianza con un liderazgo inclusivo. Porque un equipo con un buen sentido de responsabilidad mutua y confianza mutua puede lograr mucho más de lo que un individuo puede hacer solo. Muchos libros ofrecen consejos sobre cómo hacer que funcione.Recomiendo empezar desde gran juego de negocios La Organización Abierta de Jack Stack y Jim Whitehurst.
Como TAM, siempre confío en la cultura de trabajo en equipo de Red Hat para brindar excelentes soluciones a mis clientes. Porque, para ser honesto, no soy lo suficientemente inteligente como para hacerlo yo mismo. No lejos.
Gracias a Jennifer, Vicki, Tyler y otros que ayudaron a pulir este artículo. Trabajo en equipo, ganar-ganar. El trabajo en equipo no es gran cosa para una organización abierta porque es una parte natural del trabajo de todos. Por eso es importante el trabajo en equipo.
