La administración de rendimiento implica la optimización del tiempo de respuesta del servicio de red y la administración de la coherencia y la calidad de los servicios de red individuales y totales. El servicio más importante es la necesidad de medir el tiempo de respuesta de usuario/aplicación. Para la mayoría de los usuarios, el tiempo de respuesta es el factor de éxito del rendimiento crítico. Esta variable da forma a la percepción del éxito de la red tanto por los usuarios como por los administradores de aplicaciones.
La planificación de la capacidad es el proceso mediante el cual se determinan los requisitos de los recursos de red futuros con el fin de evitar un impacto en el rendimiento o la disponibilidad de las aplicaciones vitales para la empresa. En el área de planificación de capacidad, la línea de base de la red (CPU, memoria, búferes, octetos de entrada y salida, etc.) puede afectar al tiempo de respuesta. Por lo tanto, tenga en cuenta que los problemas de rendimiento a menudo se relacionan con la capacidad. En las redes, se trata normalmente del ancho de banda y los datos que deben esperar en las colas antes de que puedan transmitirse a través de la red. En las aplicaciones de voz, este tiempo de espera afecta casi con certeza a los usuarios porque factores como el retraso y la fluctuación afectan a la calidad de la llamada de voz.
Otro problema importante que complica la gestión del rendimiento es que, aunque la alta disponibilidad de la red es fundamental tanto para las grandes empresas como para las redes de proveedores de servicios, la tendencia es buscar ganancias económicas a corto plazo con el riesgo de que a largo plazo se produzcan (a menudo imprevistos) costes más elevados. Durante cada ciclo presupuestario, los administradores de red y el personal de implementación de proyectos se esfuerzan por encontrar un equilibrio entre el rendimiento y la rápida implementación. Además, los administradores de redes se enfrentan a retos que incluyen un rápido desarrollo de productos para hacer frente a los estrechos mercados, las tecnologías complejas, la consolidación empresarial, los mercados competitivos, el tiempo de inactividad no programado, la falta de experiencia y, a menudo, la insuficiencia de herramientas.
A la luz de estos retos, ¿cómo encaja el rendimiento en el marco de gestión de la red? La función principal de un sistema de administración de red ideal es optimizar las capacidades operativas de una red. Una vez que se acepta como objetivo final de la gestión de redes, el objetivo principal de la gestión de redes es mantener el funcionamiento de la red en el máximo rendimiento.
Un sistema de administración de red ideal incluye estas operaciones principales:
Informa al operador de un deterioro inminente del rendimiento.
Proporciona un ruteo alternativo sencillo y soluciones alternativas cuando se produce un deterioro del rendimiento o una falla.
Proporciona las herramientas necesarias para identificar las causas del deterioro o la falla del rendimiento.
Sirve como estación principal para la resistencia y supervivencia de la red.
Comunica el rendimiento en tiempo real.
Basada en esta definición para un sistema ideal, la administración del rendimiento se convierte en esencial para la administración de la red. Estos problemas de administración del rendimiento son fundamentales:
Rendimiento del usuario
Rendimiento de las aplicaciones
Planificación de capacidad
Administración proactiva de fallas
Es importante tener en cuenta que con las aplicaciones más recientes, como las de voz y vídeo, el rendimiento es la variable clave del éxito y, si no puede lograr un rendimiento uniforme, el servicio se considera de bajo valor y falla. En otros casos, los usuarios simplemente sufren un rendimiento variable con tiempos de espera intermitentes de las aplicaciones que disminuyen la productividad y la satisfacción del usuario.
En este documento se detallan los problemas más importantes de la gestión del rendimiento, entre los que se incluyen factores de éxito fundamentales, indicadores clave del rendimiento y un mapa de procesos de alto nivel para la gestión del rendimiento. También analiza los conceptos de disponibilidad, tiempo de respuesta, precisión, utilización y planificación de capacidad e incluye un breve debate sobre el papel del análisis proactivo de fallos en la gestión del rendimiento y el sistema de administración de red ideal.
Los principales factores de éxito determinan los requisitos para las mejores prácticas de implementación. Para calificar como factor crítico de éxito, un proceso o procedimiento debe mejorar la disponibilidad o la ausencia del procedimiento debe disminuir la disponibilidad. Además, el factor crítico del éxito debe ser mensurable para que la organización pueda determinar el grado de éxito.
Nota: Consulte Indicadores de Gestión del Rendimiento para obtener información detallada.
Estos son los factores de éxito fundamentales para la gestión del rendimiento:
Recopile una línea de base para los datos de la red y de la aplicación.
Realice un análisis de hipótesis sobre su red y sus aplicaciones.
Realizar informes de excepciones para problemas de capacidad.
Determine la sobrecarga de administración de red para todos los servicios de administración de red propuestos o potenciales.
Analice la información de capacidad.
Revise periódicamente la información de capacidad tanto para la red como para las aplicaciones, así como la línea de base y la excepción.
Disponer de procedimientos de actualización o ajuste configurados para manejar los problemas de capacidad de forma reactiva y a largo plazo.
Los indicadores de rendimiento proporcionan el mecanismo mediante el cual una organización puede medir los factores críticos del éxito. Los indicadores de rendimiento para la planificación del rendimiento incluyen:
Documentar los objetivos empresariales de administración de redes. Esto podría ser un concepto formal de operaciones para la administración de redes o una declaración menos formal de las características y objetivos requeridos.
Crear objetivos de nivel de servicio detallados y mensurables.
Proporcione documentación de los acuerdos de nivel de servicio con gráficos que muestren el éxito o el fracaso de cómo se cumplen estos acuerdos a lo largo del tiempo.
Recopile una lista de las variables para la línea de base, como el intervalo de sondeo, la sobrecarga de administración de red incurrida, los posibles umbrales de disparador, si la variable se utiliza como disparador para una trampa y el análisis de tendencias utilizado contra cada variable.
Celebrar una reunión periódica que examine el análisis de la base de referencia y las tendencias.
Tenga documentada una metodología de análisis de hipótesis. Esto debería incluir la modelización y la verificación, cuando proceda.
Cuando se exceden los umbrales, desarrolle documentación sobre la metodología utilizada para aumentar los recursos de red. Un elemento a documentar es la línea de tiempo necesaria para introducir ancho de banda WAN adicional y una tabla de costes.
Estos pasos proporcionan un flujo de procesos de alto nivel para la administración del rendimiento:
Antes de definir las variables de rendimiento y capacidad detalladas para una red, debe analizar el concepto general de funcionamiento para la administración de redes dentro de su organización. Cuando define este concepto general, proporciona una base empresarial sobre la que puede crear definiciones precisas de las funciones deseadas en su red. Si no puede desarrollar un concepto operativo para la gestión de redes, puede provocar una falta de objetivos o objetivos que cambian constantemente debido a las demandas de los clientes.
Normalmente, el concepto de operaciones de administración de red se genera como el primer paso en la fase de definición del sistema del programa de administración de red. El propósito es describir las características generales del sistema deseadas desde el punto de vista operacional. El uso de este documento es para coordinar los objetivos empresariales generales (no cuantitativos) de las operaciones de red, ingeniería, diseño, otras unidades empresariales y los usuarios finales. El objetivo de este documento es formar las actividades de planificación operativa de largo alcance para la administración y el funcionamiento de la red. También proporciona orientación para la elaboración de toda la documentación de definición subsiguiente, como los acuerdos sobre el nivel de los servicios. Evidentemente, este conjunto inicial de definiciones no puede centrarse demasiado en la gestión de problemas específicos de la red, sino en los elementos que hacen hincapié en la importancia para la organización en general y en relación con los costes que también deben gestionarse. Algunos objetivos son:
Identifique las características esenciales para un uso eficiente de la infraestructura de red.
Identifique los servicios/aplicaciones que admite la red.
Inicie la gestión de servicios de extremo a extremo.
Inicie las métricas basadas en el rendimiento para mejorar el servicio general.
Recopile y distribuya información de administración del rendimiento.
Respalde la evaluación estratégica de la red con los comentarios de los usuarios.
En otras palabras, el concepto de operaciones de administración de redes debe centrarse en los objetivos generales de la organización y en su filosofía para alcanzar esos objetivos. Los ingredientes principales consisten en las definiciones de más alto nivel de la misión, los objetivos de la misión, los objetivos del sistema, la participación de la organización y la filosofía operacional general.
Como administrador de red, está en condiciones de unificar las expectativas de rendimiento a menudo inconsistentes de sus usuarios. Por ejemplo, si el requisito principal para la red es la transferencia de archivos grandes de una ubicación a otra, desea centrarse en el alto rendimiento y menos en los tiempos de respuesta de los usuarios interactivos. Tenga cuidado de no limitar su visión del rendimiento a menos que considere una variedad de problemas. Por ejemplo, al probar una red, observe los niveles de carga que se utilizan. La carga a menudo se basa en paquetes muy pequeños y el rendimiento en paquetes muy grandes. Cualquiera de estas pruebas de rendimiento puede producir una imagen muy positiva, pero en función de la carga de tráfico de la red, es posible que las pruebas no presenten una imagen real del rendimiento. Estudiar el rendimiento de la red en el mayor número posible de condiciones de carga de trabajo y documentar el rendimiento.
Además, aunque muchas organizaciones de administración de redes disponen de técnicas de alarma eficaces para notificar a los técnicos sobre una falla del dispositivo, es mucho más difícil definir e implementar un proceso de evaluación para el rendimiento integral de las aplicaciones. Por lo tanto, mientras que el centro de operaciones de red (NOC) puede responder rápidamente a un router o switch desconectado, las condiciones de red que podrían socavar el rendimiento de la red y afectar a la percepción del usuario podrían pasar fácilmente desapercibidas hasta que esa percepción se vuelva negativa. Por difícil que sea, este segundo proceso puede ofrecer inmensas ventajas tanto a la organización empresarial como a la gestión de la red.
Por último, asegúrese de no crear expectativas poco realistas sobre el rendimiento de su red. Normalmente, se crean expectativas poco realistas cuando se malinterpretan los detalles de los protocolos de red o de las aplicaciones. A menudo, un rendimiento deficiente no es culpa de la red, sino más bien de un diseño de aplicaciones deficiente. La única manera de documentar y medir el rendimiento de las aplicaciones es tener una línea de base del rendimiento de la red antes de la instalación de la aplicación.
El primer paso de la gestión del rendimiento, la planificación continua de la capacidad y el diseño de la red es definir las funciones o servicios necesarios. Este paso requiere que comprenda las aplicaciones, los flujos de tráfico básicos, los recuentos de usuarios y sitios, y los servicios de red requeridos. El primer uso de esta información es determinar la importancia de la aplicación para los objetivos organizativos. También puede aplicar esta información para crear una base de conocimientos para su uso en el diseño lógico con el fin de comprender los requisitos de ancho de banda, interfaz, conectividad, configuración y dispositivo físico. Este paso inicial permite a los arquitectos de red crear un modelo de red.
Cree objetivos de escalabilidad de soluciones para ayudar a los ingenieros de redes a diseñar redes que cumplan los requisitos de crecimiento futuros y garantizar que los diseños propuestos no experimenten limitaciones de recursos debido al crecimiento o la extensión de la red. Las restricciones de recursos pueden incluir:
Tráfico general
Volumen
Número de rutas
Número de circuitos virtuales
Recuentos de vecinos
Dominios de difusión
Rendimiento del dispositivo
Capacidad de medios
Los planificadores de red deben determinar la duración requerida del diseño, las extensiones o sitios esperados requeridos durante la vida útil del diseño, el volumen de nuevos usuarios y el volumen o cambio de tráfico esperado. Este plan ayuda a garantizar que la solución propuesta cumpla los requisitos de crecimiento durante la vida útil prevista del diseño.
Si no investiga la escalabilidad de la solución, es posible que se vea obligado a implementar cambios de diseño reactivos importantes. Este cambio de diseño puede incluir jerarquía adicional, actualizaciones de medios o actualizaciones de hardware. En las organizaciones que dependen de ciclos presupuestarios bastante precisos para las compras de hardware más importantes, estos cambios pueden ser un obstáculo importante para el éxito general. En términos de disponibilidad, las redes pueden experimentar limitaciones de recursos inesperadas que causan períodos de no disponibilidad y medidas reactivas.
La interoperabilidad y la evaluación de la interoperabilidad pueden ser factores críticos en la instrumentación de nuevas soluciones. La interoperabilidad puede referirse a diferentes proveedores de hardware o a diferentes topologías o soluciones que deben combinarse durante o después de una implementación de red. Los problemas de interoperabilidad pueden incluir la señalización de hardware a través de la pila de protocolos para el ruteo o el transporte de problemas. Los problemas de interoperabilidad pueden ocurrir antes, durante o después de la migración de una solución de red. La planificación de interoperabilidad debe incluir la conectividad entre los diferentes dispositivos y los problemas de tipología que pueden ocurrir durante las migraciones.
La comparación de soluciones es la práctica en la que se comparan diferentes diseños potenciales en relación con otras prácticas de requisitos de soluciones. Esta práctica ayuda a garantizar que la solución es la más adecuada para un entorno determinado y que el sesgo personal no impulsa el proceso de diseño. La comparación puede incluir diferentes factores como el coste, la resistencia, la disponibilidad, el riesgo, la interoperabilidad, la capacidad de gestión, la escalabilidad y el rendimiento. Todos ellos pueden tener un efecto significativo en la disponibilidad general de la red una vez que el diseño está implementado. También puede comparar medios, jerarquía, redundancia, protocolos de ruteo y capacidades similares. Cree un gráfico con factores en el eje X y soluciones potenciales en la ayuda del eje Y para resumir las comparaciones de soluciones. La comparación detallada de soluciones en un entorno de laboratorio también ayuda a investigar objetivamente las nuevas soluciones y funciones en relación con los diferentes factores de comparación.
Como parte del concepto de operaciones de administración de redes, es esencial definir los objetivos para la red y los servicios soportados de una manera que todos los usuarios puedan entender. Las actividades que siguen a la elaboración del concepto operacional se ven muy influidas por la calidad de ese documento.
Estos son los objetivos de rendimiento estándar:
Tiempo de respuesta
Utilización
Rendimiento de procesamiento
Capacidad (velocidad de rendimiento máxima)
Aunque estas mediciones pueden ser triviales para una LAN simple, pueden ser muy difíciles en una red de campus conmutada o en una red empresarial de varios proveedores. Cuando se utiliza un concepto bien pensado del plan de operaciones, cada uno de los objetivos de rendimiento se define de una manera medible. Por ejemplo, el tiempo de respuesta mínimo para la aplicación "x" es de 500 Ms o menos durante las horas pico de oficina. Esto define la información para identificar la variable, la forma de medirla y el período de tiempo en el que la aplicación de administración de red debe centrarse.
Los objetivos de disponibilidad definen el nivel de servicio o los requisitos de nivel de servicio para un servicio de red. Esto ayuda a garantizar que la solución cumple los requisitos de disponibilidad final. Defina las diferentes clases de servicio para una organización en particular y detalle los requisitos de red para cada clase que sean adecuados para el requisito de disponibilidad. Las diferentes áreas de la red también pueden requerir diferentes niveles de disponibilidad. Un objetivo de mayor disponibilidad podría requerir una mayor redundancia y procedimientos de soporte. Cuando define un objetivo de disponibilidad para un servicio de red determinado y mide la disponibilidad, su organización de red puede comprender los componentes y los niveles de servicio necesarios para lograr los SLA proyectados.
Defina los objetivos de manejabilidad para asegurarse de que la administración general de la red no carece de funcionalidad de administración. Para establecer objetivos de capacidad de administración, debe comprender el proceso de soporte y las herramientas de administración de red asociadas para su organización. Los objetivos de capacidad de gestión deben incluir el conocimiento de cómo las nuevas soluciones encajan en el modelo de herramientas y soporte actual con referencias a cualquier posible diferencia o nuevos requisitos. Esto es fundamental para la disponibilidad de la red, ya que la capacidad de admitir nuevas soluciones es fundamental para el éxito de la implementación y para cumplir los objetivos de disponibilidad.
Los objetivos de capacidad de administración deben descubrir toda la información importante de las herramientas de red o MIB necesaria para admitir una red potencial, la formación necesaria para admitir el nuevo servicio de red, los modelos de personal para el nuevo servicio y cualquier otro requisito de soporte. A menudo, esta información no se descubre antes de la implementación y la disponibilidad general se ve afectada por la falta de recursos asignados para admitir el nuevo diseño de red.
Los SLA y las métricas de rendimiento ayudan a definir y medir el rendimiento de las nuevas soluciones de red para garantizar que cumplen los requisitos de rendimiento. El rendimiento de la solución propuesta podría medirse con herramientas de supervisión del rendimiento o con un simple ping en la infraestructura de red propuesta. Los SLA de rendimiento deben incluir el volumen de tráfico promedio esperado, el volumen pico de tráfico, el tiempo promedio de respuesta y el tiempo máximo de respuesta permitidos. Esta información se puede utilizar más adelante en la sección de validación de soluciones y, en última instancia, ayuda a determinar el rendimiento y la disponibilidad necesarios de la red.
Un aspecto importante del diseño de red es la definición del servicio para usuarios o clientes. Las empresas llaman a estos acuerdos de nivel de servicio mientras que los proveedores de servicios se refieren a ellos como gestión de nivel de servicio. La administración del nivel de servicio normalmente incluye definiciones de tipos de problemas y de gravedad y responsabilidades del soporte técnico, como la ruta de escalado y el tiempo antes de escalar en cada nivel de soporte, el tiempo para empezar a trabajar en el problema y el tiempo para cerrar los objetivos en función de la prioridad. Otros factores importantes son qué servicio se proporciona en el área de planificación de capacidad, administración proactiva de fallas, notificación de administración de cambios, umbrales, criterios de actualización y sustitución de hardware.
Cuando las organizaciones no definen los niveles de servicio por adelantado, se hace difícil mejorar o obtener los requisitos de recursos identificados en una fecha posterior. También resulta difícil entender qué recursos agregar para ayudar a admitir la red. En muchos casos, estos recursos sólo se aplican después de que se detectan problemas.
La gestión del rendimiento es un término general que incorpora la configuración y la medición de distintas áreas de rendimiento. En esta sección se describen estos seis conceptos de gestión del rendimiento:
La mayoría de las intranets corporativas tienen suficiente ancho de banda. Sin embargo, sin datos adecuados, es posible que no pueda descartar la congestión de la red como factor que contribuye a un rendimiento deficiente de las aplicaciones. Una de las pistas para la congestión o los errores es si el rendimiento deficiente es intermitente o depende de la hora del día. Un ejemplo de esta condición es cuando el rendimiento es adecuado por la noche, pero muy lento por la mañana y durante las horas punta.
Una vez definido el concepto de operaciones de administración de red y los datos de implementación necesarios, es necesario recopilar estos datos a lo largo del tiempo. Este tipo de recopilación es la base de la línea de base de la red.
Realice una línea de base de la red actual antes de la implementación de una nueva solución (aplicación o cambio de IOS) y después de la implementación para medir las expectativas establecidas para la nueva solución. Esta base de referencia ayuda a determinar si la solución cumple los objetivos de rendimiento y disponibilidad, así como la capacidad de referencia. Un informe de línea de base típico de router/switch incluye problemas de capacidad relacionados con la CPU, la memoria, la administración del búfer, la utilización de enlaces/medios y el rendimiento. Hay otros tipos de datos de línea de base que también puede incluir, en función de los objetivos definidos en el concepto de operaciones. Por ejemplo, una línea de base de disponibilidad demuestra una mayor estabilidad/disponibilidad del entorno de red. Realice una comparación básica entre entornos antiguos y nuevos para verificar los requisitos de la solución.
Otra línea de base especializada es la línea de base de la aplicación, que es valiosa cuando se realizan tendencias en los requisitos de la red de las aplicaciones. Esta información se puede utilizar para fines de facturación o presupuestación en el ciclo de actualización. Las líneas de base de las aplicaciones también pueden ser importantes en el área de disponibilidad de las aplicaciones en relación con los servicios preferidos o las cualidades del servicio por aplicación. La información de línea de base de la aplicación consiste principalmente en el ancho de banda utilizado por las aplicaciones por período de tiempo. Algunas aplicaciones de administración de red también pueden ofrecer una base del rendimiento de las aplicaciones. Un desglose del tipo de tráfico (Telnet o FTP) también es importante para la planificación. En algunas organizaciones, se supervisa la presencia de áreas de la red con recursos limitados más importantes para los usuarios más activos. Los administradores de red pueden utilizar esta información para presupuestar, planificar o ajustar la red. Al ajustar la red, puede modificar la calidad del servicio o los parámetros de cola para el servicio de red o la aplicación.
Una de las métricas principales utilizadas por los administradores de red es la disponibilidad. La disponibilidad es la medida del tiempo durante el cual un sistema de red o una aplicación está disponible para un usuario. Desde el punto de vista de la red, la disponibilidad representa la fiabilidad de los componentes individuales de una red.
Por ejemplo, para medir la disponibilidad, puede coordinar las llamadas telefónicas del soporte técnico con las estadísticas recopiladas de los dispositivos administrados. Sin embargo, las herramientas de disponibilidad no pueden determinar todos los motivos del error.
La redundancia de red es otro factor a tener en cuenta cuando se mide la disponibilidad. La pérdida de redundancia indica la degradación del servicio en lugar de una falla total de la red. El resultado podría ser un tiempo de respuesta más lento y una pérdida de datos debido a los paquetes perdidos. También es posible que los resultados aparezcan en otras áreas de medición del rendimiento, como la utilización y el tiempo de respuesta.
Por último, si cumple con un SLA, debe tener en cuenta las interrupciones programadas. Estas interrupciones pueden ser el resultado de movimientos, adiciones y cambios, cierres de instalaciones u otros eventos que quizá no desee notificar. No se trata sólo de una tarea difícil, sino también de una tarea manual.
El tiempo de respuesta de la red es el tiempo necesario para que el tráfico viaje entre dos puntos. Los tiempos de respuesta más lentos de lo normal, observados a través de una comparación de línea de base o que exceden un umbral, podrían indicar congestión o una falla de red.
El tiempo de respuesta es la mejor medida del uso de la red del cliente y puede ayudarle a medir la eficacia de su red. Independientemente de cuál sea el origen de la respuesta lenta, los usuarios se sienten frustrados por el retraso del tráfico. En las redes distribuidas, muchos factores afectan al tiempo de respuesta, como:
Congestión de red
Ruta a destino menos de la deseable (o ninguna ruta en absoluto)
Dispositivos de red con poca potencia
Errores de red, como una tormenta de difusión
Errores de ruido o CRC
En las redes que emplean colas relacionadas con QoS, la medición del tiempo de respuesta es importante para determinar si los tipos correctos de tráfico se mueven a través de la red como se esperaba. Por ejemplo, cuando se implementa tráfico de voz sobre redes IP, los paquetes de voz deben entregarse a tiempo y a una velocidad constante para mantener una buena calidad de voz. Puede generar tráfico clasificado como tráfico de voz para medir el tiempo de respuesta del tráfico tal como aparece para los usuarios.
Puede medir el tiempo de respuesta para ayudar a resolver las batallas entre los servidores de aplicaciones y los administradores de red. A menudo se presume que los administradores de red son culpables cuando una aplicación o servidor parece ser lento. El administrador de la red debe probar que la red no es el problema. La recopilación de datos del tiempo de respuesta proporciona un medio indiscutible para probar o refutar que la red es la fuente de problemas de las aplicaciones.
Siempre que sea posible, debe medir el tiempo de respuesta tal como parece para los usuarios. Un usuario percibe la respuesta como la hora a partir de la que presionan Intro o hacen clic en un botón hasta que se muestra la pantalla. Este tiempo transcurrido incluye el tiempo necesario para que cada dispositivo de red, la estación de trabajo del usuario y el servidor de destino procesen el tráfico.
Desafortunadamente, la medición a este nivel es casi imposible debido al número de usuarios y a la falta de herramientas. Además, al incorporar tiempo de respuesta del usuario y del servidor, proporciona poco valor cuando determina el crecimiento futuro de la red o la resolución de problemas de red.
Puede utilizar los dispositivos de red y los servidores para medir el tiempo de respuesta. También puede utilizar herramientas como ICMP para medir las transacciones, aunque no tiene en cuenta los retrasos introducidos en un sistema mientras las capas superiores lo procesan. Este enfoque resuelve el problema del conocimiento del rendimiento de la red.
A un nivel simplista, puede ajustar el tiempo de respuesta a los pings desde la estación de administración de red a los puntos clave de la red, como una interfaz de mainframe, el punto final de una conexión de proveedor de servicios o las direcciones IP de usuario clave, para medir el tiempo de respuesta. El problema con este método es que no refleja con exactitud la percepción del usuario del tiempo de respuesta entre su máquina y la máquina de destino. Simplemente recopila información e informa del tiempo de respuesta desde la perspectiva de la estación de administración de la red. Este método también oculta los problemas de tiempo de respuesta salto a salto en toda la red.
Una alternativa al sondeo centrado en el servidor es distribuir el esfuerzo más cerca del origen y el destino que desea simular para medir. Utilice sondeadores de administración de red distribuidos e implemente la funcionalidad de Agente de garantía de servicio (SAA) de Cisco IOS. Puede habilitar SAA en los routers para medir el tiempo de respuesta entre un router y un dispositivo de destino como un servidor u otro router. También puede especificar un puerto TCP o UDP, que fuerza al tráfico a ser reenviado y dirigido de la misma manera que el tráfico que simula.
Con la integración de voz, vídeo y datos en redes multiservicio, los clientes implementan la priorización de QoS en su red. Las mediciones simples de ICMP o UDP no reflejan con precisión el tiempo de respuesta, ya que las diferentes aplicaciones reciben diferentes prioridades. Además, con el switching de etiquetas, el routing de tráfico puede variar en función del tipo de aplicación contenido en un paquete específico. Por lo tanto, un ping ICMP podría recibir diferentes prioridades en la forma en que cada router lo maneja y podría recibir rutas diferentes y menos eficientes.
En este caso, la única manera de medir el tiempo de respuesta es generar tráfico que se asemeje a la aplicación o tecnología de interés particular. Esto obliga a los dispositivos de red a gestionar el tráfico como lo harían para el tráfico real. Es posible que pueda alcanzar este nivel con SAA o mediante el uso de sondas de detección de aplicaciones de terceros.
La precisión es la medida del tráfico de interfaz que no da lugar a errores y puede expresarse en términos de un porcentaje que compara la tasa de éxito con la velocidad total de paquetes durante un período de tiempo. Primero debe medir la tasa de error. Por ejemplo, si dos de cada 100 paquetes producen errores, la tasa de error sería del 2% y la tasa de precisión sería del 98%.
Con tecnologías de red anteriores, especialmente en el área extensa, un cierto nivel de errores era aceptable. Sin embargo, con las redes de alta velocidad y los servicios WAN actuales, la transmisión es considerablemente más precisa y las tasas de error se acercan a cero a menos que haya un problema real. Algunas causas comunes de errores de interfaz son:
Cableado fuera de especificación
Interferencia eléctrica
Hardware o software defectuoso
Utilice una tasa de precisión reducida para iniciar una investigación más estrecha. Es posible que descubra que una interfaz en particular presenta problemas y decide que los errores son aceptables. En este caso, debe ajustar el umbral de precisión para esta interfaz para reflejar dónde la tasa de error es inaceptable. La tasa de error inaceptable podría haberse notificado en una línea de base anterior.
Las variables descritas en esta tabla se utilizan en fórmulas de precisión y de tasa de error:
Notación | Descripción |
---|---|
Δ ifInErrors | El delta (o diferencia) entre dos ciclos de sondeo que recolectan el objeto ifInErrors snmp, que representa el recuento de paquetes entrantes con un error. |
Δ ifInUcastPkts | El delta entre dos ciclos de sondeo que recolectan el objeto ifInUcastPkts snmp, que representa el conteo de paquetes unicast entrantes. |
Δ ifInNUcastPkts | El delta entre los dos ciclos de sondeo que recolectan el objeto ifInNUcastPkts snmp, que representa el conteo de paquetes no unidifusión entrantes (multidifusión y difusión). |
La fórmula para la tasa de error se suele expresar como un porcentaje:
Tasa de error = (Δ ifInErrors) *100
—
(Δ ifInUcastPkts + (Δ ifInNUcastPkts)
Observe que los errores salientes no se consideran en las fórmulas de velocidad de error y precisión. Esto se debe a que un dispositivo nunca debe colocar de forma consciente los paquetes con errores en la red, y las tasas de error de la interfaz saliente nunca deberían aumentar. Por lo tanto, el tráfico entrante y los errores son las únicas medidas de interés para los errores y la exactitud de la interfaz.
La fórmula para la precisión toma la tasa de error y la resta de 100 (nuevamente, en la forma de un porcentaje):
Precisión = 100 - (Δ ifInErrors) *100
—
(Δ ifInUcastPkts + (Δ ifInNUcastPkts)
Estas fórmulas reflejan errores y precisión en términos de contadores genéricos de la interfaz MIB II (RFC 2233). El resultado se expresa en términos de un porcentaje que compara los errores con el total de paquetes vistos y enviados. La tasa de error resultante se resta de 100, lo que produce la tasa de precisión. Una tasa de precisión del 100% es perfecta.
Dado que las variables MIB II se almacenan como contadores, debe tomar dos ciclos de sondeo y calcular la diferencia entre los dos (de ahí el Delta utilizado en la ecuación).
La utilización mide el uso de un recurso concreto a lo largo del tiempo. La medida suele expresarse en forma de un porcentaje en el que se compara el uso de un recurso con su capacidad operacional máxima. Mediante las medidas de utilización, puede identificar la congestión (o la congestión potencial) en toda la red. También puede identificar recursos infrautilizados.
La utilización es la principal medida para determinar cuán completos son los conductos de red (links). Mida las mediciones de capacidad de CPU, interfaz, cola y otras medidas relacionadas con el sistema para determinar el grado en que se consumen los recursos del sistema de red.
La alta utilización no es necesariamente mala. La baja utilización podría indicar flujos de tráfico en lugares inesperados. A medida que las líneas se sobreutilizan, los efectos pueden volverse significativos. La sobreutilización ocurre cuando hay más tráfico en cola para pasar por una interfaz de lo que puede manejar. Los saltos repentinos en la utilización de los recursos pueden indicar una condición de falla.
A medida que una interfaz se congestiona, el dispositivo de red debe almacenar el paquete en una cola o descartarlo. Si un router intenta almacenar un paquete en una cola completa, el paquete se descarta. Los paquetes descartados se producen cuando el tráfico se reenvía desde una interfaz rápida a una interfaz más lenta. Esto se indica en la fórmula Q = u / (1-u) donde u es utilización, y Q es la profundidad promedio de cola (tráfico aleatorio asumido). Por lo tanto, los altos niveles de utilización en los links dan como resultado un alto promedio de profundidad de cola, lo que es una latencia predecible si conoce el tamaño del paquete. Algunos de los proveedores de informes de red indican que puede pedir menos ancho de banda y pagar menos por su WAN. Sin embargo, las implicaciones de latencia aparecen cuando se ejecutan links WAN con una utilización del 95%. Además, a medida que las redes se migran a VoIP, es posible que los administradores de red necesiten cambiar sus políticas y ejecutar enlaces WAN con una utilización aproximada del 50%.
Cuando se descarta un paquete, el protocolo de capa más alta podría forzar una retransmisión del paquete. Si se descartan varios paquetes, puede producirse un tráfico de reintento excesivo. Este tipo de reacción puede dar lugar a copias de seguridad en dispositivos más adelante. Para resolver este problema, puede establecer diferentes grados de umbrales.
La medida principal utilizada para la utilización de la red es la utilización de la interfaz. Utilice las fórmulas descritas en esta tabla en función de si la conexión que mide es semidúplex o dúplex completo:
Notación | Descripción |
---|---|
Δ ifInOctets | El delta (o diferencia) entre dos ciclos de sondeo que recolectan el objeto ifInOctets snmp, que representa el recuento de octetos entrantes de tráfico. |
Δ ifOutOctets | El delta entre dos ciclos de sondeo que recolectan el objeto ifOutOctets snmp que representa el conteo de octetos salientes del tráfico. |
ifSpeed | La velocidad de la interfaz según se informa en el objeto ifSpeed snmp. Tenga en cuenta que ifSpeed podría no reflejar con precisión la velocidad de una interfaz WAN. |
Las conexiones LAN compartidas tienden a ser semidúplex principalmente porque la detección de contención requiere que un dispositivo escuche antes de transmitir. Las conexiones WAN suelen ser dúplex completo porque la conexión es punto a punto; ambos dispositivos pueden transmitir y recibir al mismo tiempo ya que saben que sólo hay otro dispositivo que comparte la conexión.
Dado que las variables MIB II se almacenan como contadores, debe tomar dos ciclos de sondeo y calcular la diferencia entre los dos (de ahí el Delta utilizado en la ecuación).
Para medios semidúplex, utilice esta fórmula para la utilización de la interfaz:
(Δ ifInOctets + Δ ifOutOctets) * 8 * 100
—
(número de segundos en Δ) * ifSpeed
Para los medios de dúplex completo, el cálculo de la utilización es más complejo. Por ejemplo, con una conexión serial T-1 completa, la velocidad de línea es de 1.544 Mbps. Esto significa que una interfaz T-1 puede recibir y transmitir 1.544 Mbps para un ancho de banda combinado posible de 3.088 Mbps.
Cuando calcule el ancho de banda de la interfaz para las conexiones de dúplex completo, puede utilizar esta fórmula en la que toma el mayor de los valores de entrada y salida y genera un porcentaje de utilización:
max(Δ ifInOctets, (Δ ifOutOctets) * 8 * 100
—
(número de segundos en Δ) * ifSpeed
Sin embargo, este método oculta la utilización de la dirección que tiene el menor valor y proporciona resultados menos precisos. Un método más preciso es medir la utilización de entrada y la utilización de salida por separado, como:
Utilización de entrada = Δ ifInOctets * 8 * 100
—
(número de segundos en Δ) * ifSpeed
Y
Utilización de salida = Δ ifOutOctets * 8 * 100
—
(número de segundos en Δ) * ifSpeed
Aunque estas fórmulas se simplifican en cierta medida, no tienen en cuenta la sobrecarga asociada a un protocolo determinado. Existen fórmulas más precisas para manejar los aspectos únicos de cada protocolo. A modo de ejemplo, RFC 1757 contiene fórmulas de utilización de Ethernet que tienen en cuenta la sobrecarga de paquetes. Sin embargo, el equipo de alta disponibilidad ha descubierto que las fórmulas generales que se presentan aquí se pueden utilizar de forma fiable tanto en interfaces LAN como WAN en la mayoría de los casos.
Como se ha indicado anteriormente, la planificación de la capacidad es el proceso en el que se determinan los posibles requisitos futuros de recursos de red para evitar un impacto en el rendimiento o la disponibilidad de las aplicaciones vitales para la empresa. Consulte Administración de Capacidad y Rendimiento: Informe técnico sobre prácticas recomendadas para obtener información más detallada sobre este tema.
El análisis de fallos proactivo es esencial para la gestión del rendimiento. El mismo tipo de datos que se recopila para la administración del rendimiento se puede utilizar para el análisis de fallos proactivo. Sin embargo, el momento y el uso de estos datos difieren entre la administración proactiva de fallas y la administración del rendimiento.
La gestión proactiva de fallos es la forma en que el sistema de gestión de redes ideal puede alcanzar los objetivos que ha determinado. La relación con la administración del rendimiento se realiza a través de la línea de base y las variables de datos que se utilizan. La gestión proactiva de fallos integra eventos personalizados, un motor de correlación de eventos, la notificación de problemas y el análisis estadístico de los datos de referencia para vincular la gestión de fallos, el rendimiento y los cambios en un sistema de gestión de red ideal y eficaz.
Cuando el sondeo de datos de rendimiento se realiza normalmente cada 10, 15 o incluso 30 minutos, el reconocimiento de una condición de falla debe realizarse en un intervalo de tiempo mucho más corto. Un método de administración proactiva de fallas es el uso de alarmas RMON y grupos de eventos. Puede establecer umbrales en los dispositivos que no son consultados por dispositivos externos, por lo que los umbrales son mucho más cortos. Otro método, que no se aborda en este documento, es el uso de un sistema de administración distribuida que permite sondear a nivel local con agregación de datos a un administrador de gerentes.
Umbral es el proceso en el que se definen puntos de interés en flujos de datos específicos y se generan eventos cuando se activan umbrales. Utilice los datos de rendimiento de la red para establecer esos umbrales.
Hay varios tipos diferentes de umbrales, algunos de los cuales son más aplicables a ciertos tipos de datos. Los umbrales sólo se aplican a los datos numéricos, por lo que los datos textuales se convierten en valores numéricos discretos. Incluso si no conoce todas las cadenas de texto posibles para un objeto, puede enumerar las cadenas "interesantes" y asignar todas las demás cadenas a un valor establecido.
Hay dos clases de umbrales para las dos clases de datos numéricos: continua y discreta. Los umbrales continuos se aplican a los datos continuos o de series temporales, como los almacenados en contadores o indicadores SNMP. Los umbrales discretos se aplican a los objetos enumerados o a cualquier dato numérico discreto. Los objetos booleanos se enumeran con dos valores: true o false. Los datos discretos también se pueden llamar datos de eventos porque los eventos marcan la transición de un valor a otro.
Los umbrales continuos pueden desencadenar eventos cuando el objeto de serie temporal cruza el valor especificado del umbral. El valor del objeto se eleva por encima del umbral o cae por debajo de él. También puede ser útil establecer umbrales separados de aumento y caída. Esta técnica, conocida como mecanismo de histéresis, ayuda a reducir el número de eventos generados a partir de esta clase de datos. El mecanismo de histéresis trabaja para reducir el volumen de eventos generados por umbrales en datos de series temporales rápidamente variables. Este mecanismo se puede utilizar con cualquier técnica de umbral en datos de series temporales.
El volumen de eventos se reduce mediante una alarma que se genera para realizar un seguimiento del valor de un objeto. Los umbrales de subida y caída se asignan a esta alarma. La alarma sólo se activa cuando se cruza el umbral ascendente. Una vez que se cruza este umbral, no se vuelve a generar una alarma ascendente hasta que se cruza el umbral descendente. Y el mismo mecanismo evita la generación de umbrales descendentes hasta que el umbral ascendente se cruza de nuevo. Este mecanismo puede reducir drásticamente el volumen de eventos y no elimina la información requerida para determinar si existe una falla.
Los datos de las series temporales se pueden representar como contadores, donde cada nuevo punto de datos se agrega a la suma de los puntos de datos anteriores, o como un indicador, donde los datos se representan como una velocidad a lo largo de un intervalo de tiempo. Existen dos formas diferentes de umbrales continuos aplicables a cada tipo de datos: umbrales continuos absolutos y umbrales continuos relativos. Utilice umbrales contínuos absolutos con indicadores y umbrales continuos relativos con contadores.
Para determinar los valores de umbral para su red, complete estos pasos:
Seleccione los objetos.
Seleccione los dispositivos e interfaces.
Determine los valores de umbral para cada objeto u tipo de objeto/interfaz.
Determine la gravedad del evento generado por cada umbral.
Se requiere una cantidad justa de trabajo para determinar qué umbrales utilizar en qué objetos (y para qué dispositivos e interfaces). Afortunadamente, si ha recopilado una línea de base de datos de rendimiento, ya ha realizado una parte importante de ese trabajo. Además, la NSA y el programa de servicio de alta disponibilidad (HAS) pueden hacer recomendaciones que le ayuden a establecer objetos y a crear rangos. Sin embargo, debe adaptar estas recomendaciones para su red en particular.
Como ha recopilado datos de rendimiento para la red, el programa HAS recomienda que agrupe las interfaces por categorías. Esto simplifica la configuración de umbrales, ya que es posible que deba determinar umbrales para el tipo de medios de cada categoría en lugar de para cada dispositivo y objeto de ese dispositivo. Por ejemplo, desea establecer diferentes umbrales para redes Ethernet y FDDI. Se suele pensar que puede ejecutar redes FDDI con una utilización más cercana al 100% que un segmento Ethernet compartido. Sin embargo, la Ethernet de dúplex completo se puede ejecutar mucho más cerca del 100% de utilización porque no están sujetas a colisiones. Es posible que desee establecer los umbrales para colisiones muy bajas para links dúplex completo porque nunca debería ver una colisión.
También puede considerar la combinación de la importancia de la interfaz y la categoría/gravedad del tipo de umbral. Utilice estos factores para establecer la prioridad del evento y, por lo tanto, la importancia del evento y su atención por parte del personal de operaciones de red.
No se puede insistir demasiado en la agrupación y categorización de dispositivos de red e interfaces. Cuanto más pueda agrupar y categorizar, más fácil podrá integrar los eventos de umbral en su plataforma de administración de red. Utilice la línea de base como recurso principal para esta información. Consulte Administración de Capacidad y Rendimiento: Informe técnico sobre prácticas recomendadas para obtener más información.
La organización debe tener un sistema de administración de red implementado que sea capaz de detectar los valores de umbral definidos e informar sobre los valores durante periodos de tiempo especificados. Utilice un sistema de administración de red RMON que pueda archivar los mensajes de umbral en un archivo de registro para su revisión diaria o una solución de base de datos más completa que permita buscar excepciones de umbral para un parámetro determinado. La información debe estar disponible para el personal y el administrador de operaciones de red de forma continua. La implementación de administración de red debe incluir la capacidad de detectar fallas o rastros de software/hardware, confiabilidad de la interfaz, CPU, utilización de enlaces, pérdidas de colas o búfer, volumen de difusión, transiciones de portadora y reinicios de interfaz.
Una última área de administración proactiva de fallas que se superpone con la administración del rendimiento son las métricas de las operaciones de red. Estas métricas proporcionan datos valiosos para la mejora de los procesos de administración de fallos. Como mínimo, estas métricas deben incluir un desglose de todos los problemas que se produjeron durante un período determinado. El desglose debe incluir información como:
Número de problemas que se producen por prioridad de llamada
Tiempo mínimo, máximo y promedio para cerrar cada prioridad
Desglose de los problemas por tipo de problema (hardware, caída de software, configuración, alimentación, error de usuario)
Desglose del tiempo de cierre para cada tipo de problema
Disponibilidad por grupo de disponibilidad o SLA
Con qué frecuencia cumplió o no los requisitos de SLA
El soporte técnico suele tener un sistema de generación de informes con la capacidad de generar métricas o informes. Otro medio para recopilar estos datos es el uso de una herramienta de vigilancia de la disponibilidad. Los indicadores generales deben estar disponibles mensualmente. La mejora del proceso basada en el debate debe implementarse para mejorar los requisitos de los acuerdos de nivel de servicio perdidos o para mejorar la forma en que se manejan ciertos tipos de problemas.
Los indicadores de rendimiento brindan el mecanismo por el cual una organización mide los factores de éxito críticos.
Este documento podría ser un concepto formal de operaciones para la administración de redes o una declaración menos formal de las características y objetivos requeridos. Sin embargo, el documento debe ayudar al administrador de red a medida que miden el éxito.
Este documento es la estrategia de administración de redes de la organización y debe coordinar los objetivos empresariales generales (no cuantitativos) de las operaciones de red, ingeniería, diseño, otras unidades empresariales y los usuarios finales. Este enfoque permite a la organización formar actividades de planificación a largo plazo para la gestión y el funcionamiento de la red, que incluye el proceso de presupuestación. También proporciona orientación para la adquisición de herramientas y la ruta de integración necesaria para lograr los objetivos de administración de red, como los SLA.
Este documento estratégico no puede centrarse de manera demasiado estricta en la gestión de problemas específicos de la red, sino en los temas importantes para la organización en general, que incluyen cuestiones presupuestarias. Por ejemplo:
Identificar un plan integral con objetivos alcanzables.
Identifique cada servicio o aplicación empresarial que requiera soporte de red.
Identifique las métricas basadas en el rendimiento necesarias para medir el servicio.
Planifique la recopilación y distribución de los datos de métricas de rendimiento.
Identifique el soporte necesario para la evaluación de la red y los comentarios de los usuarios.
Tener objetivos de nivel de servicio documentados, detallados y medibles.
Para documentar correctamente los SLA, debe definir completamente las métricas del objetivo del nivel de servicio. Esta documentación debe estar disponible para que los usuarios la evalúen. Proporciona el bucle de retroalimentación para asegurarse de que la organización de administración de red siga midiendo las variables necesarias para mantener el nivel de acuerdo de servicio.
Los SLA son documentos "vivos" porque el entorno empresarial y la red son dinámicos por naturaleza. Lo que funciona hoy para medir un SLA podría quedar obsoleto mañana. Sólo cuando instituyen un bucle de información de los usuarios y actúan sobre esa información, las operaciones de red pueden mantener los números de alta disponibilidad requeridos por la organización.
Esta lista incluye elementos como intervalo de sondeo, sobrecarga de administración de red incurrida, posibles umbrales de activación, si la variable se utiliza como disparador para una trampa y análisis de tendencia utilizado contra cada variable.
Estas variables no se limitan a las métricas necesarias para los objetivos de nivel de servicio mencionados anteriormente. Como mínimo, deben incluir estas variables: estado del router, estado del switch, información de ruteo, datos específicos de la tecnología, utilización y retraso. Estas variables se sondean periódicamente y se almacenan en una base de datos. A continuación, se pueden generar informes con estos datos. Estos informes pueden ayudar al personal de planificación y operaciones de administración de redes de estas maneras:
Los problemas reactivos pueden resolverse con mayor rapidez con una base de datos histórica.
Los informes de rendimiento y la planificación de la capacidad requieren este tipo de datos.
Los objetivos de nivel de servicio pueden medirse en función de ellos.
El personal de gestión de redes debería celebrar reuniones para examinar periódicamente informes específicos. Esto proporciona información adicional, así como un enfoque proactivo para los problemas potenciales en la red.
Estas reuniones deberían incluir tanto personal operacional como de planificación. Esto ofrece una oportunidad para que los planificadores reciban un análisis operacional de los datos de referencia y de tendencia. También pone al personal operacional "en el proceso" para algunos de los análisis de planificación.
Otro tipo de elemento que se incluirá en estas reuniones son los objetivos de nivel de servicio. A medida que se aproximan los umbrales objetivos, el personal de gestión de redes puede tomar medidas para evitar que se pierda un objetivo y, en algunos casos, estos datos pueden utilizarse como justificación presupuestaria parcial. Los datos pueden mostrar dónde se van a violar los objetivos del nivel de servicio si no se toman las medidas adecuadas. Además, dado que estos objetivos han sido identificados por los servicios y aplicaciones empresariales, es más fácil justificarlos desde el punto de vista financiero.
Realice estos exámenes cada dos semanas y celebre una reunión analítica más exhaustiva cada seis o doce semanas. Estas reuniones le permiten abordar tanto cuestiones a corto como a largo plazo.
Un análisis de hipótesis implica modelar y verificar las soluciones. Antes de agregar una nueva solución a la red (ya sea una nueva aplicación o un cambio en la versión de Cisco IOS), documente algunas de las alternativas.
La documentación para este análisis incluye las preguntas principales, la metodología, los conjuntos de datos y los archivos de configuración. El punto principal es que el análisis de hipótesis es un experimento que otra persona debería poder recrear con la información proporcionada en el documento.
Esta documentación incluye ancho de banda WAN adicional y una tabla de costes que ayuda a aumentar el ancho de banda para un tipo de link determinado. Esta información ayuda a la organización a comprender cuánto tiempo y dinero cuesta aumentar el ancho de banda. La documentación formal permite a los expertos en rendimiento y capacidad descubrir cómo y cuándo aumentar el rendimiento, así como la línea temporal y los costos de tal esfuerzo.
Examinar periódicamente esta documentación, tal vez como parte del examen trimestral del desempeño, para asegurarse de que se mantenga actualizada.
La única forma de lograr los objetivos del sistema de gestión de redes ideal es integrar activamente los componentes de la gestión del rendimiento en el sistema. Este objetivo debe incluir el uso de métricas de tiempo de respuesta y disponibilidad vinculadas a un sistema de notificación cuando se exceden los umbrales. Tendría que incluir el uso de una base de referencia para la planificación de la capacidad que tuviera vínculos con un modelo heurístico para el aprovisionamiento y la presentación de informes de excepciones. Podría tener un motor de simulación o modelado integrado que permita actualizar el modelo en tiempo real y proporcionar un nivel de planificación y resolución de problemas a través de simulaciones de software.
Si bien gran parte de este sistema podría parecer un ideal imposible que nunca podría lograrse, cada uno de los componentes está disponible actualmente. Además, las herramientas para integrar estos componentes también existen en programas como MicroMuse. Debemos seguir trabajando en pro de este ideal, ya que hoy es más realista que nunca.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
02-Dec-2013 |
Versión inicial |