El papel del ingeniero de redes está evolucionando, pero antes de poner los ojos en blanco y decir: "Oh, no, no es otro artículo sobre automatización de redes", escúchame. Hay algunos artículos excelentes que exploran cómo la automatización de la red es parte de este cambio, pero desde que dejé el mundo VAR hace un par de años y trabajé internamente en algunas empresas más grandes, mi trabajo diario real parece enfocarse más y más más en una cosa: análisis.
El análisis es la recopilación e interpretación de datos, y el análisis de red es la recopilación y el análisis de datos de nuestra infraestructura de red, especialmente en lo que respecta al rendimiento de la aplicación. Siempre he estado en roles de ingeniero de redes relativamente tradicionales, por lo que no me preocupa analizar datos simplemente porque me encantan los datos. En cambio, quiero usar esa información para encontrar patrones, correlaciones y algo significativo y accionable para mejorar la red de alguna manera.
El cambio para mí en los últimos dos años ha requerido que me concentre menos en cómo configurar un cambio de núcleo del centro de datos y más en descubrir qué sucede realmente en la red día a día. Esto ha tenido que ver específicamente con la solución de problemas de entrega de aplicaciones, seguridad de la información y planificación de capacidad deficientes. Y todo ello requería análisis de datos de red.
Poco después de tomar un puesto en una gran empresa, recibí un correo electrónico de un científico que administraba los clústeres de computación de alto rendimiento de su equipo. Casi a la misma hora todas las noches, fallaba la transmisión de datos a nuestros clientes externos y luego tardaba varios minutos en recuperarse. Estos científicos recopilaron una gran cantidad de datos atmosféricos a lo largo del día que luego analizaron para los clientes que compraron los informes, los datos sin procesar o ambos. Algunos de estos clientes eran instituciones científicas muy grandes que extraían esta información extremadamente urgente a través de FTP.
La aplicación que administraba el clúster residía en un servidor bare metal que se ubicaba en la parte superior del bastidor y se conectaba al clúster a través de alguna conectividad propietaria, pero también estaba conectado a la LAN con fines de administración y para entregar los informes completos. La falla estaba ocurriendo con varios clientes, por lo que descarté que el problema fuera de su parte. Tenía que estar en el nuestro. Algo estaba sucediendo en uno de nuestros hosts, el controlador de clúster o en algún lugar de nuestra ruta de red.
El científico principal se hizo cargo del incidente y verificó si la aplicación y los servidores funcionaban correctamente. Todo parecía estar bien por su parte, por lo que sospechó que había un problema en la red. No pudimos identificar fácilmente ninguna actividad de red que hubiera entrado en conflicto, así que comencé observando la configuración de todos los dispositivos de red en la ruta. Inicié sesión en conmutadores, cortafuegos y enrutadores, pero no vi nada malo.
¿Qué estaba pasando aquí? Los registros revelarían la respuesta. Usando el software que teníamos en ese momento vi que estábamos recopilando muy poca información de muy pocos dispositivos. No había mucho más que mirar. Necesitábamos algún tipo de información significativa. Claro, podría haber hurgado en los dispositivos toda la noche para ver qué estaba pasando en tiempo real, pero sabía que no podría correlacionar nada fácilmente. En cambio, configuré nuestra herramienta de recopilación de datos para recopilar de todo en la red. Configuré SNMP en algunos dispositivos, NETFLOW en otros, y para aquellos que no admitían ninguno, configuré la herramienta de recopilación para hacer ping continuamente a esas direcciones IP y escanear sus puertos abiertos.
Después de unos días de llamadas telefónicas, buscar en Google y conversar con el científico principal, un cliente se impacientó y se enojó mucho porque sus importaciones fallaron casi todas las noches. Esto se convirtió en un tema de alto perfil y una prioridad para mí. Dediqué más espacio de almacenamiento al software de recopilación de datos y lo dejé funcionar durante una semana. Cuando analicé los resultados, detecté un aumento inusual en la CPU del controlador de la aplicación aproximadamente a la misma hora todas las noches, la hora en que comenzó el problema. Este fue un buen comienzo, pero no había ninguna razón que el científico principal pudiera encontrar en el servidor que pudiera causar esto. Los enlaces de la red no experimentaron congestión inusual, y ninguno de nuestros conmutadores en la ruta mostró nada inusual en absoluto.
Debido a que nuestra herramienta de recopilación era mediocre, tuve que pasar bastantes horas estudiando detenidamente todos estos nuevos datos. Mi compañero de trabajo me ayudó escribiendo un script para buscar la utilización de CPU, enlace y memoria y luego presentarlo en un formato gráfico a través de algún tipo de conector de correo electrónico inteligente. Después de todo ese tiempo y esfuerzo, apareció una bandera roja que nos indicaba un interruptor de acceso que tenía un pico de CPU todas las noches. Inicié sesión en el interruptor y vi que el tiempo de actividad reflejaba un probable reinicio en el fatídico momento de la noche anterior.
Antes de irme del trabajo, reemplacé el interruptor, me aseguré de que la dirección IP fuera uno de los widgets en nuestro panel de monitoreo y configuré un ping persistente simple. Mi compañero de trabajo escribió una secuencia de comandos para enviarnos un correo electrónico si caían los pings, y configuramos el software de monitoreo para enviar una alerta si la CPU se disparaba. Para nuestra consternación, a la mañana siguiente recibimos correos electrónicos notificándonos que los pings cayeron y notificaciones del software de recopilación que la CPU aumentó. Revisamos el interruptor, estaba encendido. Revisé el tiempo de actividad: mostré un reinicio en medio de la noche. Estábamos seguros de que la respuesta estaba en los datos. Pero fue muy tedioso extraerlo y tomó demasiado tiempo para nuestro cliente. En algún lugar debe haber un patrón o una correlación que no habíamos encontrado, así que seguimos buscando. Necesitábamos una mejor manera de hacer esto, pero por ahora, usamos el software y los scripts personalizados lo mejor que pudimos. Entonces encontramos algo. Un dispositivo desconocido en una dirección IP desconocida se volvió muy hablador sobre cuándo se reinició el conmutador. No era una dirección duplicada y no estaba en la misma subred, pero era algo que sucedía a la misma hora todas las noches.
Rastrear el dispositivo fue fácil. No estaba en DNS, pero era una reserva en DHCP. Resultó ser el controlador del aire acondicionado de respaldo que se activaba todas las noches. Esto normalmente no sería un problema, pero cuando bajamos a la sala de servidores encontramos que la unidad de CA estaba conectada a la misma PDU que el interruptor. No había nada más en la PDU, y no fue algo que hayamos visto antes.
Cuando la unidad de aire acondicionado se encendió, hubo suficiente drenaje en el circuito que el interruptor se reinició. Al menos esa era nuestra teoría. Movimos el interruptor a una PDU diferente y llamamos a la gente de HVAC. El interruptor no se reinició esa noche y, por lo que entiendo, la gente de HVAC encontró un problema con un sensor y el electricista solucionó el problema de energía.
Resolver esto requirió recopilar una gran cantidad de datos y analizarlos de manera inteligente. Ahí es donde mis colegas ingenieros de redes y yo nos encontramos estos días trabajando en TI empresarial. Claro, hay una actualización ocasional del firewall o el reemplazo del conmutador MDF, pero principalmente estoy recopilando y analizando datos tratando de solucionar problemas de rendimiento de la aplicación o trabajando en una tarea de seguridad de la información.
No creo que el papel de un ingeniero de redes esté cambiando tanto que necesitemos convertirnos en programadores y científicos de datos, pero lo que sí veo es una tendencia creciente a ser muy hábil para saber cómo recopilar y analizar una gran cantidad de datos dinámicos y información efímera.
NetBrain anunció recientemente una tecnología muy prometedora que tiene como objetivo abordar este desafío analítico: lo llaman Ejecutable Runbooks. Básicamente, un Runbook ofrece una forma de recopilar y analizar automáticamente los datos de la red. Dado que estos RunbookLos s pueden ser adaptados (tanto por programadores como por no programadores) y pueden usarse para realizar análisis para cualquier función de red. El siguiente ejemplo es un Runbook que fue escrito para analizar el diseño de enrutamiento OSPF.