Otro de los proyectos implementados mientras trabajé en la Gerencia de Telecomunicaciones y Teleprocesos de la Dirección General de la Función Pública del Gobierno de Córdoba, implicaba el monitoreo de los enlaces de WAN que interconectaban las distintas dependencias de Gobierno con el "Supercentro". Como mencioné en un post anterior, la gerencia tenía entre sus responsabilidades el monitoreo de lo vinculado a las redes de datos y a la telefonía. También mencioné que por decisión política de esa gestión de Gobierno, todos los sistemas y servicios informáticos se concentraron en un solo lugar, conocido como "Supercentro".
Cuando el monitoreo no existía, la típica reacción ante un problema era que las distintas áreas le echaran la culpa/fardo/soga a alguna de las otras áreas de Gobierno, deslindando responsabilidades. Esta espada de Damocles iba recorriendo las distintas áreas (telecomunicaciones, infraestructura, base de datos, área de desarrollo, etc.) hasta que el problema se solucionaba "solo", y todo volvía a la "normalidad".
Demás está decir que los problemas surgían a toda hora, por cuanto la infraestructura informática de Gobierno era (¿es?) un verdadero zoológico de proveedores, marcas, modelos, etc. Era notoria la diversidad de servicios de red que podían detectarse si alguien ejecutaba un sniffer convenientemente ubicado en la topología de la red de datos.
El mecanismo más razonable para determinar de manera fehaciente la causa de un problema, era implementar una herramienta de monitoreo, que entre otras cosas permitiera la alerta temprana de problemas en la red y/o los servidores y posiblitara que los responsable pudiera ser proactivos para encontrar una solución.
Implementación de "Big Brother"
Recordemos la época en cuestión era el año 2000, donde aún no existía Nagios u otras herramientas más o menos elaboradas para monitoreo (sobre Linux, por lo menos). Yo tenía experiencia con SNMP, pero evitaba utilizar HP Open View o algún otro programa propietario similar, con el agregado de que me molestaba tener que ir personalmente hasta la pantalla del equipo para determinar el estado de situación de la red.En base a algunos artículos aparecidos en la Linux Journal hasta ese entonces, teníamos conocimiento del programa "Big Brother", que aún existe. A priori, por el hecho de que fuera de código abierto y accesible mediante un navegador, reunía mis preferencias de mínima para un sistema de esta naturaleza.
El primer paso fue el monitoreo de los enlaces entre Gobierno y sus dependencias. Esto nos permitiría impedir que futuros problemas arrastrara a nuestra área, siempre que esta herramienta así lo demostrara.
Como parte de la desmesura que implicó la concentración abrupta de todos los sistemas en el Supercentro, se estableció un esquema de enlace duplicado con todas las dependencias de Gobierno. Los proveedores de los enlaces, con un buen criterio, debían ser de distintos proveedores. En la práctica, estos proveedores eran Telecom y Techtel. Telecom proveía lineas digitales de 512 kbps, y Techtel, líneas inhalámbricas de 1Mbps (estos valores de ancho de banda fueron mutando en el tiempo, aunque se mantenía la relación 2 a 1). Algunas dependencias del interior de la provincia no tenían cobertura de Techtel, así que el segundo proveedor redundante era Impsat, que utilizaba enlaces satelitales.
Para no complicar el tema de la gestión de los equipos, el encargado de la administración iba a ser un solo proveedor, y la gente de Techtel se propuso como candidato para ello (la gente de Telecom, con astucia, decidió apartarse de lo que a todas luces pintaba como un futuro caos). El mecanismo para "balancear la carga" entre ambos enlaces era mediante la utilización del protocolo "HRSP" entre ambos enlaces, que en principio iba a permitir que el tráfico se distribuyera de manera homogénea.
Demás está decir que había pocas esperanzas para un funcionamiento óptimo del balanceo de carga, en donde ambos enlaces fueran utilizados de la manera más eficiente posible. No solo era complicado imaginar un uso proporcional del ancho de banda en ambos enlaces, sino que este análisis ni siquiera era adecuado, por cuanto los demás valores que definen la calidad de una comunicación (latencia, por ejemplo), diferían notoriamente ya que la tecnología empleada en ambos enlaces era distinta. Lo cierto era que Techtel cobraba un plus por "balanceo de carga", y nunca lo pudieron hacer funcionar correctamente: el enlace de Techtel era el principal, y el enlace de Telecom entraba en acción cuando el enlace principal se caía (o sea, ruteo dinámico liso y llano).
El costo de cada enlace eran elevado. La cantidad de dependencias conectadas por duplicado eran aproximadamente unas 100. Entre las dependencias podemos encontrar: Dirección de Rentas, Catastro, etc., de indudable peso en el funcionamiento del estado provincial. Otras dependencias conectadas eran Teatro Real, Museo Caraffa, etc., que requerían del doble enlace porque poseían 1 (una) PC con algunos sistemas (como el de Rentas por ejemplo), que hubiese permitido que alguien realizara un trámite de Rentas en el mencionado teatro, por ejemplo. Esto último es un despropósito injustificable por donde se lo mire.
Obviando estas consideraciones que exceden lo técnico, realizamos las primeras pruebas con Big Brother, y empezó a dar sus frutos. Hubo que realizar algunas modificaciones para que el programa funcione mejor. Por ejemplo, la cantidad de enlaces monitoreados era tan grande, que el comando ping que utilizaba por debajo para chequear conectividad empezó a hacer agua por el timeout que posee. Esto se solucionó reemplazando ping por fping.
Con los primeros resultados, quedó en evidencia que los enlaces de Techtel poseían intermitencias (la jerga difundida en Gobierno lo identificaba como "micro-corte", aunque no tenían nada de "micro"). Esto fue solucionado luego de algún tiempo (un par de años) cuando ya era indisimulable para el proveedor. En el medio, se puso en duda la precisión de la herramienta, la intencionalidad de los clientes (o sea, nosotros), etc. La solución al problema fue lograda cuando Techtel migró sus enlaces, reemplazando la abusada frecuencia de 2.4 Ghz, por una frecuencia exclusiva arriba de los 5 Ghz.
Este primer uso permitió que nuestra área quedara fuera de las posteriores repartos de responsabilidades ante un nuevo problema, ya que este programa, de fácil acceso para cualquiera, demostraba (o no) que los enlaces de datos no eran la fuente del inconveniente.
Implementación de "MRTG"
Teniendo en cuenta el background que ya tenía en SNMP, parecía lógico que chequearamos la utilización del ancho de banda. Para ello recurrimos a MRTG. De manera similar a Big Brother, este programa es de código abierto y genera información accesible mediante un navegador. En la aspecto técnico la cuestión parecía sencilla, aunque en el formal las cosas son más complicadas.Lamentablemente hubo reticencia, particularmente de Telecom, para habilitar el servicio de SNMP en algunos equipos, aduciendo razones de "seguridad". Como parte del monitoreo, teníamos interés en determinar la utilización del enlace a Internet, para lo cual se debía habilitar el servicio de SNMP en el router, de esa forma podíamos consultar los contadores de las interfaces WAN. El encargado de seguridad de Telecom procedía a ignorar mis pedidos en ese sentido, ya que si de él dependía, el equipo mejor hubiera estado apagado para lograr una seguridad "casi" perfecta. Poco importaba que, a pesar de su excesivo celo, y a pesar de que el Supercentro tenía control de acceso con guardia policial durante todo el día, igualmente el "naranjita" de calle Ituzaingó ingresaba para utilizar los sanitarios, sin ningún tipo de control adicional más que su sola imagen. A pesar de este tipo de consideraciones "relajadas" en cuestiones de seguridad, Telecom seguía siendo inflexible para con los accesos "virtuales" a sus equipos. Esto nos forzó a habilitar el servicio de SNMP mediante un disimulado proceso de recovery en el router, el cual cumplió su función por varios años, hasta que fue descubierto. Otros proveedores, como Advance (Telefónica), no solo que habilitaron el servicio sin mayores trabas, sino que el esquema de atención al cliente fue inusualmente eficaz, escalando la consulta al nivel 2 de soporte rápidamente, en cuanto determinaron que el requerimiento excedía sus facultades.
Una vez que el servicio de SNMP fue habilitado, procedí a realizar algunas modificaciones en el código de Big Brother, habilitando un enlace en el código html generado, que permitiera relacionar ambos programas. MRTG dejaba en evidencia que el enlace de Telecom estaba principalmente ocioso. Por otra parte, los "traps" de SNMP dejaban también en claro que las caídas de los enlaces de Techtel debido a desconexiones en el medio inalámbrico, eran mucho más frecuentes que lo que pudiera detectar un chequeo de conectividad, que suele tener una cadencia de 5 minutos (los "traps" de SNMP nunca se perdían, ya que encontraban su camino por el enlace de Telecom, cuando el enlace de Techtel se caía, y dejaban en evidencia que los "macro-cortes" eran mucho más frecuentes que lo que pudiera acusar Big Brother).
Interfaz de la información
La pantalla principal de "Big Brother" mostraba un agrupamiento de enlaces en base al proveedor o a la geografía, como se muestra a continuación:
o en el caso de Techtel:
Para cada enlace listado, se puede acceder a información específica del mismo:
El botón "HISTORY" provee un histórico de las últimas 36 horas:
La barra de imagen que muestra las caídas en las últimas 36 horas no es la original del producto, porque por la cantidad de cortes que tenía un enlace, a veces el gráfico generado era una cebra ininteligible roja y verde. La imagen se regeneró con mayor nivel de detalle gracias a un script externo y el uso de la librería GD.
En la página del enlace en cuestión, se pueden observar las modificaciones realizadas al código generado, que permitían relacionar un enlace con su gemelo del otro proveedor, o con la dirección de LAN del router. La opción "Gráfico Comparativo" mostraba el histórico de los tres puntos de monitoreo asociados a una dependencia:
Desde la opción del listado de los enlaces se puede acceder a la opción del "gráfico de carga" que muestra la pantalla de MRTG asociada:
Ese ejemplo muestra el nivel de uso de los enlaces de algunas dependencias de Gobierno.
Al final de cada listado de proveedor, existían otros agregados:
El "Registro de Reclamos", permitía que el encargado de mesa de ayudas pudiera dejar asentada la información de un reclamo efectuado al proveedor, si se constataba un problema en un enlace. Esa información iba a quedar disponible para que cualquier otra persona vinculada pudiera seguir el estado del reclamo. La pantalla del registro de reclamos se veía como sigue:
y una vez seleccionado el enlace:
entre la información de utilidad para la gente de mesa de ayudas, estaba: teléfono de la dependencia, contacto técnico de informática en el lugar, que permitía constatar el problema (y descartar otras causas, como corte de luz, por ejemplo), y los números de linea y referencia necesarios para generar el reclamo en el proveedor. Esta información estaba almacenada en una base de datos tipo gdbm.
En cuanto a la opción "Enlaces Inestables" del listado para cada proveedor, se accedía a un script que generaba un "ranking" de enlaces más inestables en las últimas 24 horas, en función de la información de Big Brother (este desarrollo fue hecho casi por necesidad, para demostrar la intestabilidad de los enlaces inalámbricos):
Como es habitual, los scripts agregados están desarrollados en perl. Además, las imágenes en este último caso fueron generadas con el apoyo de la librería GD y el módulo perl correspondiente.
Conclusión
Como en el caso del post anterior, se utilizaron aplicaciones de código abierto para facilitar tareas de gestión, de fácil implementación y acceso para su uso compartido entre múltiples personas, y a costo cero. El servidor con HP-UX y HP Open View instalado en supercentro siguió en su ostracismo, tal como sucedía anteriormente, pero ahora plenamente justificado.La contundencia con que Big Brother provee la información útil (un simple vistazo general permite determinar si hay problemas, en base al color de la pantalla), permitió que todos los involucrados se familiarizaran rápidamente con su uso. Con el tiempo, y gracias a la existencia de programas cliente de Big Brother existentes tanto para Linux como para Windows, se agregó el monitoreo a los servidores basados en Windows, detectado de esta manera la caída de servicios, los errores en logs, etc.
Al igual que en el caso del tarifador, ese sistema cayó en desuso en cuanto no hubo nadie más que realizara las tareas de configuración, desarrollo y mantenimiento mínimas que requieren productos de esta naturaleza. Probablemente en reemplazo se haya vuelto a recurrir al uso del chamán, para que con sus huesos de pollo intentara determinar la causa de los problemas existentes de ahí en más.
