Alpha: 25% - Método Hashing: src-dst-ip – Tiempo de Simulación: 5 horas
A continuación se presentan los resultados de esta simulación para un escenario con la consideración de las perturbaciones de tráfico del escenario descrito en la sección 4.2.6, inicialmente con un ajuste del 75% en los valores de las observaciones de tráfico utilizadas por el módulo “LeastLoad_Analysis”, y a continuación con el ajuste de un 95% en los valores de las observaciones utilizadas por el mismo módulo. Escenario: 75% de los valores considerados en los cálculos del módulo “LeastLoad_Analysis”:
Figura 140. Ocupación Outbound de enlaces de salida (Alpha 25% - 75% valores procesados por LeastLoad_Analysis).
Figura 141. Frecuencias de observaciones de ocupación enlaces de salida tráfico saliente (Alpha 25%).
Figura 142. Ocupación Inbound de enlaces de salida (Alpha 25% - 75% valores procesados por LeastLoad_Analysis).
Figura 143. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante (Alpha 25%).
Figura 144. Estadística “Estado de Sistema” para el Escenario de Simulación No. 5 con análisis de muestras al 75%.
Figura 145. Retardo de Procesamiento Nodal (Alpha 25%). Figura 146. CDF Retardo de Procesamiento Nodal (Alpha 25%).
Escenario: 95% de los valores considerados en los cálculos del módulo “LeastLoad_Analysis”
Figura 147. Ocupación Outbound de enlaces de salida (Alpha 25% - 95% valores procesados por LeastLoad_Analysis).
Figura 148. Frecuencias de observaciones de ocupación enlaces de salida tráfico saliente (Alpha 25%).
Figura 149. Ocupación Inbound de enlaces de salida (Alpha 25% - 95% valores procesados por LeastLoad_Analysis).
Figura 150. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante (Alpha 25%).
Figura 151. CDF Retardo de Procesamiento Nodal (Alpha 25%).
Al comparar la Figura 140 y la Figura 147, para la característica de ocupación del canal lógico con tráfico saliente, y la Figura 142 y la Figura 149, para la característica de ocupación del canal lógico con tráfico entrante, se identifica que…
Para el ajuste al 75%, el modelo reacciona de forma consistente a la sucesión de perturbaciones de tráfico (Figura 140 y Figura 142) y la Figura 144 evidencia la permanencia del Switch en modo “Recuperación” alcanzando la condición de balance y la ocupación del canal en estado estable en el largo término.
Para el ajuste al 95%, el modelo, con una operación transitoriaen modo “Recuperación” incitada por el ingreso de perturbaciones de tráfico, trata de acercar rápidamente las ocupaciones de todos los enlaces para alcanzar la condición de balance de forma temprana (Figura 147 y Figura 149). En el largo término, la implementación trata de sostener la condición de balance del canal lógico mientras se alcanza la ocupación del canal de estado estable, demostrando la eficiencia del modelo bajo este ajuste y revalidando el conjunto de modificaciones sugeridas en la sección 4.2.4.
5.
CONCLUSIONES
Con respecto a los objetivos propuestos para este proyecto de grado, se tienen inicialmente…
Simular un entorno de red basado en el modelado y verificación de desempeño del método de balanceo de carga estático de hashing de bits soportado en EtherChannel, en la herramienta de simulación OPNET Modeler 14.5 (1).
Identificar y desarrollar una arquitectura de balanceo de carga sobre enlaces físicos basada en la filosofía dinámica Least Load (Menor Carga) que permita influenciar la decisión de balanceo sobre enlaces EtherChannel de forma autónoma y consistente (2).
Simular un entorno de red basado en el modelado y verificación de desempeño de la arquitectura de balanceo de carga dinámica propuesta, en la herramienta de simulación OPNET Modeler 14.5 (3).
De acuerdo con (2), se desarrolló una arquitectura totalmente modular para responder a los objetivos y necesidades del proyecto, la cual es presentada en la Figura 152. A partir de esta arquitectura, se efectúa la implementación de un modelo de nodo en la herramienta de simulación OPNET Modeler (Figura 24) con la parametrización requerida de manera que la implementación contara con la habilidad para presentar diferentes escenarios funcionales requeridos de acuerdo a los objetivos. Así, un único ajuste en el modelo de red, diseñado para ambientar la simulación del desempeño del modelo de la arquitectura propuesta, permite simular el método de asignación de carga de EtherChannel (Hashing de Bits) (1), así como la operación conjunta objeto de la arquitectura de conmutación propuesta (2-3). El núcleo de esta arquitectura (conjunto modular “RRD_Algorithm”, módulo “LeastLoad_Analysis”, módulo “WeightsLoad_Settings” junto a la serie de modificaciones ejecutadas durante los escenarios de simulación alternos) está desarrollado bajo una total adhesión a la filosofía “LeastLoad” al tratar de forma preferente los enlaces menos cargados con un mayor volumen de créditos de recuperación, de acuerdo al método de asignación de carga Round Robin Deficit. El diseño y funcionalidad de los módulos “Collector” posibilita la consideración de procedimientos de asignación de carga dinámicos que automatizan los modelos de compartición de carga equitativa en el grupo de enlaces del canal agregado.
Figura 152. Diagrama de bloques de la arquitectura del nodo de conmutación propuesto
La arquitectura propuesta presenta un alto grado de modularidad en su diseño lo cual ofrece flexibilidad para adicionar nuevas capacidades vía inserción de módulos, modificar la funcionalidad de subsistemas específicos existentes en respuesta a nuevas necesidades, así como optimizar la arquitectura. En adición, su diseño de interfaz y la documentación de soporte permiten su integración con otros modelos de nodo y su consideración en trabajos futuros.
La consideración de un proceso de validación general de toda la arquitectura propuesta, para garantizar la operación global del modelo y un comportamiento cercano a expectativas de diseño, fue un aspecto de relevancia en la ejecución de este proyecto. Uno de los últimos aspectos del simulador que fueron asimilados durante la etapa de validación de la arquitectura, es el OPNET Simulation Debugger (ODB), que es una herramienta de simulación controlada en modo gráfico que permite verificar el flujo de paquetes y señalización en el modelo objeto de simulación. Sin el uso de este tipo de herramientas, es muy difícil garantizar la aproximación de un modelo a la expectativa funcional, incluso si un nodo o módulo específico está realizando correctamente los procedimientos para los cuales fue desarrollado. Como puede verificarse en los capítulos Desarrollos y Anexos, hay un uso extensivo de la herramienta ODB en el proceso de validación del modelo desagregado, para lo cual fueron desarrollados varios modelos de prueba que pretenden evidenciar y comparar la respuesta de un módulo específico frente a unas entradas conocidas con respecto a la expectativa funcional derivada de los objetivos de su programación.
Con respecto a la simulación del método de asignación de carga de la tecnología EtherChannel (1), de acuerdo a expectativa, se evidencia que son notorios los efectos de desbalance sobre el canal agregado dadas las preferencias por ciertos índices de enlace que el método en mención puede tomar basado en la información de cabeceras de los paquetes. Bajo este método, se verifican enlaces que, bajo ciertas condiciones de tráfico y configuraciones de direccionamiento, pueden ser omitidos del proceso de asignación de carga. De acuerdo al capítulo Análisis de Resultados, se realizó la ejecución de unos escenarios de simulación alternos adicionales que consideran una serie de modificaciones con aspectos no contemplados en el diseño inicial del modelo propuesto, con respecto a resultados de simulaciones preliminares (3). Los resultados antes y después de modificación demuestran una habilidad mejorada del modelo de la arquitectura para tratar de restablecer el balance en el canal agregado. La modificación documentada asigna el máximo peso de recuperación para enlaces con ocupaciones cercanas a cero durante un ciclo de evaluación, y modela un comportamiento muestral más exclusivo por parte del módulo “LeastLoad_Analysis” para considerar cambios de estado. Los efectos son un comportamiento altamente reactivo al desbalance y la aparición temprana del efecto balanceador Round Robin Deficit en la ocupación de los enlaces (Figura 153 a Figura 156).
Figura 153. Ocupación promedio de enlaces de salida para tráfico
saliente Método de Asignación de Carga Hashing de Bits. Figura 154. Diagrama de Frecuencias de observaciones de ocupación Método de Asignación de Carga Hashing de Bits.
Figura 155. Ocupación promedio de enlaces de salida para tráfico saliente, después de modificación, Método de Asignación de Carga
Propuesto (alpha 25%).
Figura 156. Diagrama de Frecuencias de observaciones de ocupación Método de Asignación de Carga Propuesto (alpha 25%).
Así mismo, la relativa baja variabilidad en el comportamiento del tráfico de ingreso al modelo llevó a la simulación de otro escenario alterno con perturbaciones de tráfico (Figura 122 a Figura 139). Aun así, el efecto balanceador aparece de forma temprana y el resultado en el largo término es una condición de balance generalizada con una mejor respuesta del sistema bajo la consideración de la media acotada de tráfico por interfaz física calculada dentro del rango intercuartil. Se supone mejor desempeño de esta configuración ante modelos de tráfico de ingreso con variaciones de corto término (ráfaga).
Al revisar los resultados de la simulación en los diferentes escenarios propuestos, pueden verificarse tiempos prolongados de recuperación de la condición de balance estipulada para el modelo. Sin embargo, hay ya un buen escenario de balance relativo en el canal agregado mucho antes de alcanzar la condición mencionada, lo que propone un trabajo posterior para revaluar esa condición para operación óptima. Los resultados de la estadística “Estado de Sistema” muestran un constante ingreso del Switch en el modo “Recuperación” ya que se tiene una ventana de 30 segundos para verificar el canal lógico, y si el análisis resulta que aún no se alcanza la condición de balance, el Switch puede permanecer en ese estado por muchos ciclos de análisis. Este proceso recurrente disminuye el desempeño de la simulación, y se propondría para trabajos futuros la consideración de una ventana de recuperación variable automática basada en las condiciones de tráfico detectadas, de manera que minimice el número de conmutaciones del modo operacional del Switch y mejore el desempeño de la arquitectura propuesta.
Uno de los resultados encontrados en la simulación del modelo de la arquitectura propuesta fue un Retardo de Procesamiento Nodal incrementado de hasta 75ms, con respecto a similar resultado para la simulación del modelo de conmutación de EtherChannel. Dos de los aspectos que quedaron bastante claros de esta experiencia y a su vez proponen una serie de desafíos de diseño, necesaria en este tipo de simulación, es la naturaleza DES de la herramienta OPNET, y el cuidado que debe tenerse con todos los procesos que intervienen en la Lista de Eventos de la simulación. Las primeras ejecuciones de la simulación del modelo mostraban tiempos de simulación excesivamente largos así como situaciones en las cuales en determinado momento se bloqueaba la simulación y el equipo de cómputo. Una verificación en el log de esas simulaciones mostró un crecimiento desmesurado en la utilización de la memoria RAM del equipo de cómputo. Sobre el particular, la lectura de la bibliografía, así como algunos consejos de estudiantes que ya se han enfrentado a la situación en mención, son concluyentes en dos aspectos que apuntan a una adecuada administración de la simulación DES: asegurar la destrucción de todo paquete o entidad de datos que ya haya cursado por el sistema de red, por medio de sumideros o procedimientos de Kernel; y el cuidado con los procesos iterativos que, por su objeto, producen mensajes de señalización o paquetes de datos. La implementación del algoritmo de Round Robin Deficit es uno de esos procesos que produce excesiva señalización cuando encuentra reiteradamente subcolas vacías. Durante ese proceso, esa señalización copa la Lista de Eventos y no permite que otros procesos la accedan para ingresar o retirar entidades de datos o interrupciones, lo que detiene el tiempo de simulación y dispara el consumo de memoria RAM. Así, una solución fue la consideración de un retardo en la atención de subcolas RRD consecutivas de 5ms, el cual da la oportunidad a que otros procesos accedan la Lista de Eventos y pueda avanzar el tiempo de simulación. Esta consideración mejoró de forma importante la evolución del tiempo de las simulaciones y la obtención de los resultados presentados en este documento. Sin embargo, en este modelo se verifica que hasta dos ciclos de Round Robin pueden requerirse para atender un paquete que accede al método y para un sistema de 8 subcolas, se evidenció que el retardo de procesamiento nodal está acotado a 80ms con un 95% de probabilidad de encontrar todo el retardo por debajo de 75ms, en contraste con el retardo de procesamiento nodal para el método de EtherChannel con retardos no superiores a 3.1ms. Por tanto, podría el lector llevarse una sensación incorrecta del desempeño de la arquitectura propuesta sobre este aspecto (poniendo en desventaja el modelo asociado), pero debe aclararse que en gran medida este retardo es necesario dada la necesidad de simular en un ambiente DES. Por tanto, esta situación no es un problema si parte de la labor de validación y simulación se efectúa en un sistema real con desagregación hardware de los procesos que conforman el sistema, así un conjunto de módulos que producen paquetes y señalización en un parte del sistema no debe afectar otra parte del mismo.
Durante la búsqueda de referencias bibliográficas acerca de los conceptos y guía de usuario de desarrollo de modelos en OPNET Modeler, la mayor parte del trabajo encontrado en la Internet y bibliografía disponible aborda aspectos relacionados con análisis de desempeño y modelado de redes por medio de la
aplicación OPNET Guru Academic Edition. Otros trabajos relacionados con el modelado de protocolos de red y nodos, por medio de la herramienta OPNET Modeler, permiten acceso a alguna información descriptiva de los modelos de red y de nodo, sin mayor detalle acerca de las interrelaciones entre módulos o procesos de diseño o construcción de modelos específicos. En adición, la compañía OPNET Inc, que tradicionalmente ofrecía buen soporte sobre sus aplicaciones, fue adquirida por Riverbed, la cual solo ofrece soporte a desarrolladores bajo contrato, y la documentación disponible con el aplicativo hace énfasis en los procedimientos de Kernel integrados mas no en ejercicios de modelado y modificación de modelos existentes. Estos aspectos dificultan el aprendizaje y asimilación de la herramienta. Sobre el particular, de manera alterna hay varios foros y comunidades en Google enfocados en la resolución de problemas encontrados en las diferentes etapas de los procesos de modelado y simulación. Sin embargo, muchas de las situaciones encontradas durante el diseño y desarrollo del modelo objeto de este proyecto de grado fueron superadas por medio de prueba y error, mucha inversión en sentido común y cotejando algunas conclusiones de la lectura de una u otra fuente relacionada. En este trabajo fueron de suma importancia los contenidos y aportes de las referencias bibliográficas [10], [11], [13] y [14], donde abordan una construcción conceptual progresiva y ejemplos de complejidad incremental que orientan adecuadamente acerca de cómo realizar tareas específicas acerca del proyecto propio.
Uno de los aspectos de relevancia verificados en la herramienta OPNET Modeler es el soporte de
simulación híbrida, la cual propone parte del trabajo de modelado en análisis matemático y otra parte en DES, el cual mejora de forma importante el desempeño de las simulaciones. Muchos de los cálculos matemáticos de relevancia en el modelado de la arquitectura propuesta fueron realizados en C++ sin la consideración de las herramientas suministradas por OPNET, que, aunque de enfoque similar, consumen recursos que finalmente afectan la ejecución de la simulación. Ciertamente es muy importante la experiencia previa en programación y el dominio de algún lenguaje próximo en sintaxis y semántica a Proto-C, como PERL en mi caso, que permita la explotación de las prestaciones de la simulación híbrida. Dada la orientación de la herramienta OPNET, cada nodo, estructura o módulo en el sistema es modelado como un objeto, y las fuentes en mención dan cuenta de la susceptibilidad de estos objetos de ser instanciados y utilizados en muchas partes de un modelo de red o nodo con comportamientos distintos de acuerdo a parametrización. Así, un desarrollador podría instanciar un módulo completo del cual no dispone (que hace parte de un modelo de nodo diferente) y que responde funcionalmente a una necesidad de su proyecto, e instalarlo en otro modelo de nodo realizando las conexiones necesarias del módulo en mención (Packet Streams, Statistics Wires) y debe funcionar! Aparentemente este no es el caso y una situación similar impidió la integración de la capa MAC de Ethernet en las interfaces de los nodos de conmutación propuestos, con el resultado de no poder considerar medios del tipo Ethernet así como prescindir de la utilización de las herramientas de simulación de tráfico de red (Application Servers, Application Configs, Application Profiles) disponibles en el modelo de red en OPNET Modeler, ya que estas características son disponibles desde nodos servidor y estaciones de trabajo Ethernet. Por esta razón, la estrategía de modelado se amplió al diseño y depuración de estaciones de trabajo, generadores de tráfico y medios de comunicaciones, que en conjunto posibilitaran una infraestructura y tráfico para validar el modelo de la arquitectura propuesta de conmutación. No hay mayor documentación OPNET sobre la integración de esta tecnología de red en modelos de nodos. Por tanto, se espera que trabajos futuros puedan ahondar sobre el particular, con un enfoque distinto (tomando un modelo de nodo predefinido OPNET con soporte Ethernet ya existente y modificando sus capas superiores, con el objeto de integrar la metodología de conmutación propuesta). Este desarrollo es de suma importancia para una validación más decisiva de la parametrización “alpha” de la arquitectura, ya que podrá someterse el modelo a comportamientos de protocolo prestablecidos en OPNET que por naturaleza contemplan tráfico en ráfagas y podrá verificarse con mayor eficacia la validez de la media muestral acotada de rango intercuartil como configuración aceptada y óptima para un rápido restablecimiento de la condición de balance del canal agregado. En adición, la consideración de medios y métodos Ethernet en la arquitectura serán necesarios para un mayor acercamiento del modelo propuesto a la operación de una implementación real en capa 2. A partir de la realización de la serie de trabajos propuestos, a futuro se propondrá un proyecto de prototipado de la arquitectura revisada en un ambiente hardware basado en NetFPGAs e infraestructura de conmutación Cisco de manera que puedan verificarse sus características funcionales y de compatiblidad
así como el nivel de desempeño en un escenario que involucre tráfico real, aplicaciones de alto uso de ancho de banda y en tiempo real, y conexiones del tipo GigabitEthernet y 10GigabitEthernet.
Con respecto al cumplimiento del siguiente objetivo propuesto: Verificar el desempeño del método de balanceo de carga y de la arquitectura propuesta en general frente a variaciones discretas de α como parámetro de la medición de tendencia central de ocupación de enlaces físicos EtherChannel y probar la validez de la Media de Rango InterCuartil.
Se generaron tres escenarios de simulación con parametrizaciones alpha α 5%, 15% y 25% para condiciones de tráfico similares, encontrando que el mejor comportamiento lo exhibe la consideración de la media acotada de rango intercuartil (25%) (Figura 155 y Figura 156) en las mediciones y cálculos por parte de los módulos “Collector”, puesto que suprime suficientes aberrantes de tráfico y comportamiento en ráfagas que eventualmente podrían llevar a la arquitectura modelada a tomar decisiones de restablecimiento de balance innecesarias. Las aseveraciones realizadas sobre el particular se derivan del comportamiento muestral de las observaciones de la variable Ocupación y las características gráficas de ocupación de los enlaces del canal agregado antes y después de las modificaciones sugeridas en los tres