Monitorización de redes WAN y el modelo centrado en Internet

Cuando pensamos en monitorización de redes WAN solemos partir de lo básico: el comportamiento de los enlaces de comunicación remota incidirá de forma directa en el rendimiento de nuestras aplicaciones.

Así pues, entendemos que si el tráfico sobre el enlace de comunicaciones experimenta altos niveles de latencia esto repercutirá negativamente en el tiempo de respuesta que observan nuestros usuarios al momento de acceder a las aplicaciones.

En esta línea, en abril de 2018 Network Computing publicó un artículo exponiendo las siete causas más comunes para la generación de latencia en una red.

Nos resultó interesante que, de las siete razones, cuatro de ellas corresponden a situaciones que tienen que ver con el diseño, administración y comportamiento de los enlaces de comunicaciones:

Número de saltos o distancia entre origen y destino.
Presencia de cuellos de botella.
No se implementa QoS, o su configuración es deficiente.
Implementación de esquemas no óptimos de enrutamiento.

Siendo como somos personal de monitorización, de inmediato nos dijimos: a ver esas razones, vamos a establecer un procedimiento de monitorización para cada una.

Sin embargo, luego pensamos que no estaría de más reflexionar sobre la monitorización de redes WAN a la luz de los problemas señalados por Network Computing, pero también en función de cómo ha evolucionado el diseño de este tipo de redes.

Digamos que si deseamos saber si un enlace de comunicaciones presenta o no una situación de “cuello de botella”, podemos utilizar Pandora FMS para:

Monitorizar vía SNMP al enrutador en cuestión, de manera de disponer de información sobre el rendimiento general de este dispositivo.
Definir la interface del enrutador sobre la que se desea monitorizar la condición de cuello de botella.
Obtener información sobre la tecnología WAN que se utiliza; es decir, nos preguntaríamos si se trata de un enlace MPLS o un backbone MetroEthernet, etc.
Echar mano del conocimiento que se tiene del comportamiento del enlace y de la aplicación. Es decir verificaríamos los registros de mediciones previas, siempre y cuando existan por supuesto.
Definir qué significa para nosotros un cuello de botella. Podríamos decir que estamos a punto de tener un cuello de botella cuando, por un tiempo específico, tenemos un porcentaje de ancho de banda utilizado muy alto y el tiempo de respuesta de la aplicación es muy bajo.
Monitorizar el porcentaje de uso del ancho de ancho de banda. Aquí podríamos utilizar el protocolo SNMP o el protocolo NetFlow si el dispositivo lo soporta, o incluso podríamos validar qué información suministra nuestro proveedor del servicio.

En este artículo se detalla cómo podemos monitorizar ancho de banda con Pandora FMS.

Definir también el tiempo de respuesta de la aplicación o aplicaciones que generan tráfico sobre el enlace en cuestión.
Definir una alarma que nos prevenga de una situación de cuello de botella, correlacionando las tres variables: el porcentaje de ancho de banda utilizado, el tiempo de respuesta de la aplicación y el tiempo durante el cual ambas condiciones coinciden en estadios anormales.
Evaluar el comportamiento de este esquema de monitorización por un periodo de tiempo que debe abarcar al menos un ciclo de negocio completo, y si funciona bien replicarlo para los diferentes puertos con el mismo tipo de enlace y la misma aplicación.
Establecer una estructura de visibilidad que nos permita monitorizar en función del esquema anterior todos los enlaces considerando todas las sedes de nuestra organización, tanto regionales como centrales.

Con este ejemplo se refleja bien el procedimiento que solemos seguir para hacer monitorización de redes WAN, sacando provecho de las facilidades que nos ofrece Pandora FMS y que podemos resumir así:

Identificar los elementos físicos involucrados, así como las tecnologías implementadas en los enlaces en cuestión, considerando todo el conocimiento acumulado previamente sobre el comportamiento de los dispositivos y enlaces.
Generar la lógica asociada a la evaluación.
Definir un conjunto de variables que deseamos medir y sus umbrales de comportamiento. Definir e implementar el procedimiento para obtener información sobre estas variables.
Implementar umbrales y alarmas.
Probar y si funciona trasladar a todos enlaces con condiciones semejantes, definiendo un esquema de visualización global.

Ahora bien, esta línea de pensamiento pareciera ser ideal para un esquema de red WAN basada en enlaces privados.

Es decir aquel esquema donde nosotros somos los dueños del enrutador, hemos negociado y contratado un servicio de comunicaciones, hemos acumulado conocimiento sobre el rendimiento tanto del enlace como de la aplicación y además somos los responsables de la administración de toda la plataforma.

Pero cabe preguntarse: ¿Esta forma de abordar la monitorización de redes WAN es realmente viable cuando contamos con un esquema basado en la nube o diseñado por software?

¿Qué debemos cambiar en nuestra forma de enfrentar el reto de monitorización de redes WAN cuando el diseño de estas redes contempla otros servicios más allá de los enlaces privados?

Esquema WAN Centrado en Internet

El esquema de comunicaciones remotas basado en enlaces privados sin duda sigue vigente y probablemente tarde mucho o jamás desaparezca por completo.

Las razones básicas para mantener este tipo de esquema parte de que se trata de plataformas operativas en las cuales el comportamiento de los enlaces es altamente estable y su rendimiento es altamente predecible.

Sin embargo, no podemos negar que hay una tendencia a la migración a tecnologías asociadas a la nube, a SD-WAN, a recurrir a plataformas como SaaS, IaaS, etc.

En resumen, somos testigos de la incorporación del esquema WAN que se ha dado por llamar ¨Centrado en Internet¨.

¿Razones para esta tendencia? Múltiples; desde cosas generales como costes basados en “cuánto usas, cuánto pagas”, el aumento de trabajadores móviles y menores tiempos de implementación, hasta cosas más específicas como una mejor relación coste/beneficio para oficinas pequeñas, por ejemplo.

Aquí no pretendemos exponer razones a favor de uno u otro modelo; partimos de aceptar la tendencia y queremos reflexionar sobre cómo debemos adaptar nuestra forma de asumir la monitorización.

¿Cómo adaptar la monitorización?

Dependiendo de que enfrentemos el proyecto de monitorización de redes WAN de una plataforma centrada en Internet o de una plataforma híbrida, debemos contemplar los siguientes elementos:

Eliminar nuestro apego al hardware

Ya lo dijimos en el artículo en el que analizábamos los retos del SD-WAN, en este mismo blog

Los administradores de red solemos tener una conexión muy fuerte con el hardware; normalmente configuramos cada switch, enrutador y firewall comando a comando.
Esta forma de trabajo nos da un conocimiento profundo sobre plataforma pero tiene el problema de que es muy laboriosa, es propensa a errores y puede ralentizar los cambios.
En un esquema WAN centrado en Internet quizás no conozcamos nunca los equipos con los que se instrumenta un servicio de comunicaciones o no tengamos acceso a los mismos.
Por lo tanto, la idea es pensar menos en equipos, configuraciones, y comandos y pensar más en reglas, servicios, experiencia de los usuarios y compromisos de rendimiento por parte de los proveedores.

Identificar todos proveedores y servicios involucrados

En una plataforma WAN basada en enlaces privados, el grupo de administradores regularmente es responsable de todos los servicios que sustentan el acceso de los usuarios a una aplicación en particular.

Servicios como el acceso a una cuenta de usuario, administración de perfiles, DNS, NAT, Gateway, IPS, etc. Al tener todos los servicios bajo control es más sencillo, en teoría al menos, poder tener una visión global de las dependencias que pudieran afectar el rendimiento de una aplicación dada.

Ahora bien, para todos estos servicios existe también la tendencia de contratarlos en la nube. O puede pasar que nuestro proveedor de un servicio, como SaaS, subcontrate a otras empresas para ofrecer un servicio de Gateway, por ejemplo.

Esta situación nos lleva a que, al momento de requerir monitorizar un servicio WAN, debamos ampliar nuestro espectro de alcance más allá del comportamiento del enlace como tal, e incluir todo el universo de dependencias que están siendo suplidas en la nube.

Data obtenida de los proveedores

En una plataforma WAN centrada en Internet regularmente se contratan los servicios a un número mayor de proveedores.

Al punto de que muchos autores plantean que, en presencia de redes WAN centradas en Internet o modelos híbridos, los administradores de redes WAN deben concentrar sus esfuerzos en lograr lo que llaman “Gobernabilidad de la nube”.

Esta gobernabilidad está retada entonces por un mayor número de compromiso de servicio y más heterogeneidad en las condiciones de los convenios.

La monitorización en particular puede complicarse, dado que podemos suponer que un proveedor puede ofrecer data sobre el rendimiento de su servicio en formatos completamente distintos a los utilizados por otro proveedor.

Además, podemos esperar también mayor variabilidad en el rendimiento real de cada oficina regional, por ejemplo, ya que este rendimiento de seguro estará sustentado por proveedores distintos con servicios desiguales.

Una buena estrategia puede contemplar:

Intentar sacar el mayor provecho de cada negociación, estableciendo como condición para el cierre de un convenio acuerdos de colaboración en términos de monitorización y reporte de problemas.
Definir los procedimientos de monitorización basados en un enfoque centrado en la experiencia de nuestros usuarios en el uso de sus aplicaciones.
Mantenernos atentos al hecho de que lo que funciona para los usuarios de una oficina regional no necesariamente aplica de forma directa a los usuarios de otra, a pesar de que finalmente accedan a la misma aplicación.

Con todos estos cambios, es válido preguntarnos si la monitorización de redes WAN, tal como la ejercemos hoy día, será relevante a mediano plazo o si difuminará dentro de la monitorización de aplicaciones y la gobernabilidad de la nube.

Quizás debamos cambiar nuestro enfoque sobre el tema, tal como lo planteamos en este artículo.

Sin embargo, el conocimiento sobre los protocolos de comunicaciones, sobre los servicios asociados (DNS, IPS, etc.), nuestra experticia en SNMP, Netflow y, sobre todo, el esfuerzo dedicado a implementar herramientas de monitorización, entender cómo funcionan, cómo se adaptan a nuestras necesidades, cómo se acoplan a otros sistemas, cómo hacer análisis y optimización, eso de seguro permanecerá vigente y será siempre un valor importante.

En función de lo cual, les invitamos a compartir sus experiencias en este interesante mundo de la monitorización de redes WAN y a revisar todas las facilidades que ofrece una herramienta como Pandora FMS, visitando este enlace.