¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
  1. Libros
  2. Redes informáticas
  3. Metrología y medidas de rendimiento
Extrait - Redes informáticas Guía práctica para la gestión, seguridad y supervisión
Extractos del libro
Redes informáticas Guía práctica para la gestión, seguridad y supervisión Volver a la página de compra del libro

Metrología y medidas de rendimiento

Metrología y métricas de red

1. Definición de metrología

La metrología es una parte integrante de la supervisión. En términos generales, se refiere a la ciencia de la medición que se aplica en muchos campos, incluidas las redes informáticas. Más allá de la simple medición, la metrología se dedica a garantizar las medidas y a interpretarlas. Los usuarios se quejan de la lentitud de la red, del escaso rendimiento al descargar archivos de la nube o de una aplicación que tarda demasiado en responder. ¿Cómo se pueden resolver estos problemas sin datos cuantificables y comparables? ¿Cómo se mide el tiempo de respuesta de una aplicación? ¿Cómo se mide el ancho de banda? ¿En qué unidad(es)? ¿Cómo asegurarse de que un proveedor de servicios presta un servicio de acuerdo con los SLA contractuales?

Si no implementamos los medios para medir el rendimiento de una red o de una aplicación, será difícil evaluar su calidad. Por lo tanto, es imposible pensar en cómo mejorar el rendimiento actual o futuro sin evaluarlo realmente según unas métricas bien definidas. Es fácil aceptar que la percepción de un usuario sobre la velocidad de acceso a una aplicación es un factor que hay que tener en cuenta, pero no es matemáticamente comparable y sigue siendo bastante subjetivo.

Esta percepción de lentitud debe matizarse con una medida precisa, que podría ser el tiempo que se tarda en mostrar la página de inicio de un sitio de intranet tras la identificación de un usuario, por ejemplo, y que por tanto puede evaluarse en segundos. Este valor podría cuantificarse en varios momentos del día para evaluar el tiempo medio de respuesta durante los periodos de mayor o menor uso. Estos promedios también podrían utilizarse, por ejemplo, para evaluar las consecuencias de cambios en el código de la aplicación por parte del equipo de desarrollo, la modificación en el sistema operativo en el que se basa la aplicación o cambios en la configuración de un activo de red. Al final, todo lo que se mide se vuelve comparable.

El peligro de la metrología (y de la supervisión en general) es el deseo de querer medirlo todo, de obtener tantas métricas como...

Medir y optimizar el caudal

1. Caudal bruto y de una aplicación

Los operadores están acostumbrados a expresar las velocidades de transmisión de una conexión de tipo xDSL en términos de velocidad ATM. Así, una conexión ADSL2 anunciada a 28 Mbit/s para descarga no representa realmente la velocidad real medida, incluso si no tenemos en cuenta la inevitable atenuación de la señal, que depende de la distancia del abonado. De hecho, una prueba de caudal nos dará un resultado de unos 22 Mbit/s, que es lo que los operadores llaman velocidad IP, es decir, la velocidad de transmisión o caudal disponible sin tener en cuenta el caudal adicional utilizado por uno o varios protocolos de nivel inferior al IP, como el ATM (ver capítulo Cambio en empleos relacionados con las redes, sección Evolución hacia las redes ATM). De hecho, no hay que olvidar que, para la transmisión de datos, estos se encapsulan en diferentes protocolos que utilizan encabezados de diferentes tamaños, potencialmente variables. Por lo tanto, estos encabezados consumen un caudal adicional (ya que aumenta el número de bits que hay que transmitir).

Cuando hablamos de velocidad de transmisión, tenemos que especificar a qué nivel de la capa OSI nos referimos; de forma predefinida estamos acostumbrados a referirnos a la velocidad IP. Pero si la aplicación en cuestión utiliza TCP en lugar de UDP, e IPv6 en lugar de IPv4, la transmisión de un archivo tardará más, porque las cabeceras TCP e IPv6 de nuestro ejemplo son más grandes. Sabiendo que también existe un tamaño máximo para un paquete determinado llamado MTU (Maximum Transfer Unit; Unidad de transferencia máxima), lo que significa que más allá de este valor los datos se fragmentan y por lo tanto se utilizan más bits para los encabezados, ya que se usan más paquetes.

El error sería hacer el siguiente cálculo: una aplicación transfiere un archivo de 25 MB, utilizando un enlace de 100 Mbits (12,5 MB por segundo), la transmisión durará exactamente 2 s. En realidad, hay que tener en cuenta los protocolos utilizados y las posibles fragmentaciones en función del tamaño de los datos enviados y de la MTU.

Consideremos aquí el envío de datos...

Medir tiempos de respuesta

1. Medir la latencia y fluctuación

a. Ping

El protocolo ICMP, mediante la generación de mensajes Echo Request y las correspondientes respuestas Echo Reply, permite verificar, por un lado, la conectividad de red entre dos máquinas en una WAN o LAN (mediante el comando ping) y también, indirectamente, obtener valores de latencia de todas las redes atravesadas. La latencia es una de las métricas de red definidas en este capítulo, en la sección Métricas de red.

Así, el resultado de un comando ping a un destinatario alcanzable va acompañado del tiempo transcurrido entre el envío de la solicitud ICMP y la respuesta correspondiente, es decir, el tiempo de ida y vuelta en la red o RTT. La latencia se obtiene dividiendo este valor entre 2. En general, la latencia sigue siendo simétrica, aunque el camino de ida recorrido por un paquete IP puede diferir del camino de vuelta.

La latencia depende del medio utilizado y de su longitud. Las latencias más bajas se consiguen en los medios basados en fibra, mientras que las más altas suelen encontrarse en conexiones inalámbricas como las de satélite o 5G.

Aquí vemos una tabla que muestra los valores de RTT «habituales» en una conexión WAN durante una prueba de ping entre dos máquinas, en función del tipo de conexión utilizado:

MEDIO FÍSICO

RTT medio esperado

ADSL (cobre)

Entre 30 ms y 80 ms

Fibra óptica

Entre 2 ms y 25 ms

Conexión por cable (coaxial)

Entre 15 ms y 40 ms

5G

Entre 1 ms y 3 ms

4G

Entre 40 ms y 60 ms

3G

Entre 90 ms y 130 ms

Wimax

Entre 65 ms y 85 ms

Satélite

Entre 500 ms y 900 ms

images/cap07_img06.png

RTT obtenido a través del resultado del comando ping. La latencia en esta captura es de 7 ms para un RTT de 14 ms.

La latencia también se puede evaluar en relación con el uso de protocolos de nivel más alto que ICMP, concretamente a nivel de transporte a través de TCP o UDP. Esto puede hacerse usando la utilidad echoping descrita en la sección Metodología de pruebas de rendimiento de este capítulo.

b. Traceroute

La variación de la latencia se explica principalmente por el conjunto de medios utilizados entre el emisor y el receptor. Cuanto mayor sea la distancia por recorrer, mayor...

Herramientas especializadas de supervisión metrológica

1. Almacenar mediciones

a. Problemas de almacenamiento de datos metrológicos

Los requisitos de rendimiento y almacenamiento de los datos recolectados son específicos del campo de la metrología. Los datos deben ser almacenados rápidamente, en tiempo real y con una marca de tiempo, utilizando un mínimo de espacio en disco para una medición determinada. Las bases de datos o los sistemas de archivos que se utilizan deben estar adaptados para recibir un gran número de escrituras secuenciales o incluso simultáneas con alta frecuencia. A la hora de leer, interpretar y presentar los datos, un sistema tradicional de gestión de bases de datos (SGBD) no es necesariamente adecuado. Por ello, con vistas a su optimización, los editores están desarrollando estructuras de datos y SGBD específicos, denominados TSDB (Time Series Database), adaptados al almacenamiento de datos metrológicos con el fin de acelerar su procesamiento. Una serie de tiempos («time series») es, de hecho, una serie de tuplas de tiempo (o intervalo)/valor medido.

Estas TSDB tienen en cuenta el hecho de que los datos nunca llegan a intervalos de tiempo regulares, por lo que son capaces de suavizar los datos recolectados ponderándolos a lo largo de un intervalo determinado antes de almacenarlos realmente y estamparles una marca de tiempo. Por supuesto, esto supone una pérdida de precisión, pero ¿necesitamos saber, por ejemplo, que para t=0 s, la velocidad de datos registrada en una interfaz de red es de 100 kbit/s, 102 kbit/s para t=1 s y 101 kbit/s para t=2 s?

El administrador está más interesado en observar las tendencias y los promedios durante un periodo de tiempo más largo: promedios de los últimos cinco minutos, del último cuarto de hora, de la última hora, etc.

b. Herramientas generalizadas para almacenar datos metrológicos

InfluxDB

InfluxDB es un sistema de TSDB de código abierto desarrollado por la empresa InfluxData. Está especializado en el trabajo en tiempo real y dispone de una API para aceptar datos a través de HTTP/TCP o UDP. Actualmente es uno de los productos más utilizados y además es gratuito.