Se necesita con urgencia un artículo sobre "Investigación en simulación de redes de comunicación"

1

Título: Investigación sobre plataforma de simulación basada en red de sensores inalámbricos

1 Introducción

Las redes de sensores (WSN) están cambiando. Cada día que pasa, las soluciones y protocolos de red se vuelven cada vez más complejos y el tamaño de la red es cada vez mayor. Para los investigadores de redes, la importancia de dominar la simulación de redes es evidente. La simulación de WSN puede estudiar aplicaciones de WSN, incluidos sistemas operativos y pilas de protocolos de red, en un entorno controlado. Puede simular una gran cantidad de nodos, observar interacciones impredecibles entre nodos causadas por interferencias y ruidos impredecibles y obtener detalles detallados entre nodos. mejorar la tasa de éxito de la red después de que el nodo se ponga en funcionamiento y reducir el trabajo de mantenimiento de la red después de que se ponga en funcionamiento. Actualmente, las herramientas de simulación utilizadas para redes de sensores inalámbricos incluyen principalmente NS2, TinyOS, OPNET, OMNET, etc. TinyOS está desarrollado específicamente para las características de las redes de sensores inalámbricos.

2. Introducción a la simulación de redes de sensores inalámbricos

En una red de sensores, un único nodo de sensores tiene dos características sobresalientes. Una característica es que su concurrencia es muy intensiva; otra característica es que los nodos de sensores son altamente modulares, lo que hace que la simulación de redes de sensores inalámbricos necesite resolver problemas como escalabilidad y eficiencia de simulación, distribución y características asincrónicas, dinámica y plataformas de simulación integrales. .

En tercer lugar, las herramientas de simulación más utilizadas para redes de sensores inalámbricos

Las herramientas de simulación más utilizadas para redes de sensores inalámbricos incluyen NS2, OPNET, OMNET y TinyOS. A continuación se muestra una breve introducción a sus respectivos rendimientos y características.

3.1 NS2

NS es una herramienta de simulación basada en el tiempo extensible, configurable y programable, que se desarrolla sobre la base de simuladores reales. En el diseño de NS, se utilizaron dos lenguajes de programación, C y OTCL. C es un lenguaje que se ejecuta relativamente rápido pero convierte lentamente, por lo que C se usa para implementar el protocolo de red y escribir el motor de simulación subyacente de NS. OTCL es un lenguaje de secuencias de comandos que se ejecuta lentamente pero convierte rápidamente y es solo un complemento de C. Por lo tanto, OTCL se utiliza para configurar varios parámetros en la simulación y establecer la estructura general de la simulación. El script OTCL define la topología de la red llamando a varias propiedades y métodos en el motor, configura el nodo de origen y el nodo de destino para establecer enlaces, genera el cronograma de todos los eventos, ejecuta y rastrea los resultados de la simulación y también puede realizar el procesamiento estadístico correspondiente o aprovechando los resultados. NS puede proporcionar una red cableada. Muchos protocolos en NS están muy cerca de códigos reales y su autenticidad y confiabilidad son muy altas.

3.2 OPNET

OPNET es un producto de software de simulación de red desarrollado por MIL3 Company basándose en los resultados de la investigación del MIT. Las características principales de OPNET incluyen los siguientes aspectos: (1) Al utilizar tecnología orientada a objetos, las propiedades de los objetos se pueden configurar arbitrariamente y cada objeto pertenece a una clase con comportamientos y funciones correspondientes. Se pueden cumplir diferentes requisitos del sistema definiendo nuevos. clases (2) OPNET proporciona componentes y módulos de procesamiento para diversas redes de comunicación y sistemas de información (3) OPNET utiliza modelado de interfaz gráfica para proporcionar a los usuarios un mecanismo de modelado de tres capas (capa de red, capa de nodo, capa de proceso) para describir el proceso; sistema real (4) OPNET utiliza máquinas de estados finitos a nivel de proceso para modelar otros protocolos y procesos. El modelo de usuario y el modelo integrado de OPNET generarán automáticamente el lenguaje C para lograr una simulación ejecutable de alta eficiencia y eventos altamente discretos. proceso (OPNET tiene muchos analizadores de rendimiento incorporados que recopilarán automáticamente los datos de resultados del proceso de simulación; (6) OPNET predefine casi todos los modelos comerciales de uso común, como distribución uniforme, distribución de Poisson, distribución de Olam, etc.

Versión 3.3 OMNET.

OMNET es una herramienta de simulación de eventos discretos orientada a objetos que proporciona soporte de simulación basada en procesos y eventos. OMNET adopta un método de modelado híbrido y utiliza la red ned (red) única de OMNET. descripción) lenguaje y C para construcción.

OMNET se compone principalmente de seis partes: biblioteca del núcleo de simulación, compilador de lenguaje de descripción de red, compilador de red de gráficos, interfaz gráfica de usuario del programa de simulación, interfaz de usuario de línea de comandos del programa de simulación y herramienta de salida de vectores gráficos. NED es el lenguaje de descripción de topología del modelo principal de OMNET, que se puede utilizar para describir un modelo de red. Una descripción de red incluye los siguientes componentes: declaraciones de entrada, definiciones de canales, definiciones de módulos del sistema, definiciones de módulos simples y definiciones de módulos compuestos. NED se utiliza para describir la red y generar un archivo NED, que el compilador de C no puede utilizar directamente. primero. Los archivos NED deben compilarse en archivos .cpp utilizando la herramienta de compilación NEDC proporcionada por OMNET. Finalmente, se utiliza un compilador de C para conectar estos archivos y el programa de módulo simple diseñado por el usuario en un programa ejecutable.

3.4 TinyOS

TinyOS es un sistema operativo especialmente desarrollado para sensores. El lenguaje de programación de TinyOS es NESC (lenguaje C para sistemas integrados en red).

El lenguaje NesC es una extensión del lenguaje C y pretende combinar la idea de componenteización/modularización con el modelo de ejecución basado en eventos de TinyOS. Hay dos tipos de componentes nesC: módulos y configuraciones. El módulo compila principalmente el código y el archivo de configuración de conexión conecta principalmente los componentes y módulos en un todo.

El programa TinyOS adopta un diseño modular, por lo que su núcleo de programa suele ser muy pequeño, lo que puede superar las limitaciones de los recursos de almacenamiento de los sensores, permitiendo que TinyOS se ejecute de manera efectiva en redes de sensores inalámbricos y realice el trabajo de administración correspondiente. Las características de TinyOS se reflejan principalmente en los siguientes aspectos:

(1) Arquitectura basada en componentes. Los componentes de TinyOS generalmente se pueden dividir en las siguientes tres categorías: componentes de abstracción de hardware, componentes integrales y componentes de software de alto nivel. Los componentes de abstracción de hardware asignan hardware físico a modelos de componentes de TinyOS. Los componentes de hardware sintéticos simulan el comportamiento del hardware de alto nivel. Los módulos de software avanzados completan el control, el enrutamiento y la transmisión de datos. }

(2) Arquitectura basada en eventos. Los controladores de eventos se dividen en controladores de hardware y controladores de eventos de software. El controlador de eventos de hardware significa que el hardware emite una interrupción y luego ingresa a la función de procesamiento de interrupciones. Los controladores de software envían eventos mediante la palabra clave singal.

(3) Modelo de concurrencia de tareas y eventos. Las tareas se utilizan en aplicaciones que no tienen requisitos de tiempo estrictos. Las tareas son iguales, es decir, se ejecutan en orden y no pueden adelantarse entre sí. TinyOS procesa tareas basándose en una cola FIFO simple. Los eventos se utilizan en aplicaciones en las que el tiempo es crítico, donde pueden tener prioridad sobre las tareas y otros eventos.

(4) Funcionamiento en división de fases. En TinyOS, debido a que las tareas no pueden adelantarse entre sí, TinyOS no proporciona ninguna operación de bloqueo. Para completar una operación larga lo más rápido posible, generalmente se logra separando la demanda de esta operación de la finalización de esta operación para obtener una mayor eficiencia de ejecución.

(5)Hilo ligero. Los subprocesos livianos (tareas en TinyOS) se programan en modo FIFO, lo que no permite la preferencia entre subprocesos livianos; los subprocesos de procesamiento de hardware (llamados procesadores de hardware en TinyOS), es decir, interrumpen los subprocesos de procesamiento y pueden interrumpir los subprocesos livianos de alto nivel del usuario. subprocesos y subprocesos de procesamiento de interrupciones de baja prioridad para responder rápidamente a las interrupciones de hardware.

(6) Mensajes activos. Cada mensaje mantiene una capa de aplicación y un controlador. Cuando el nodo de destino recibe este mensaje, pasará los datos del mensaje como parámetros al procesador de la capa de aplicación para su procesamiento. El procesador de la capa de aplicación generalmente completa la operación de descomprimir los datos del mensaje, procesar el cálculo o enviar mensajes de respuesta.

Las plataformas de simulación comunes en el sistema operativo TinyOS incluyen TOSSIM y Avrora.

(1)TOSSIM (TinyOS Simulación) es un simulador que admite aplicaciones basadas en TinyOS para ejecutar en PC. TOSSIM ejecuta el mismo código que el hardware del sensor y el compilador de simulación puede compilar y generar programas de simulación directamente desde la lista de componentes de la aplicación Tinyos.

(2) Avrora es una herramienta que proporciona análisis de simulación para programas escritos en el lenguaje de microcontrolador AVR en nodos Atmel y Mica2. Sus características principales son las siguientes: 1) Proporciona simulación de ciclo preciso para el microcontrolador AVR para permitir que los programas estáticos se ejecuten con precisión. Puede emular controladores de dispositivos integrados en el chip y proporcionar interfaces convencionales para programas externos al chip. 2) Se puede agregar código de monitoreo para informar el rendimiento en ejecución del programa de simulación, o se pueden recopilar datos estadísticos y generar informes después de la simulación. 3) Se proporciona un conjunto de monitores básicos para analizar el programa, que ayuda a analizar el método de ejecución y; Uso de recursos del programa Condición. 4) Avrora puede usar gdb para depurar programas; 5) Avrora puede proporcionar diagramas de flujo de programas para expresar claramente la estructura y organización de los programas de código de máquina; 6) Avrora proporciona herramientas para analizar el consumo de energía y configurar equipos; tamaño cargado; 7) Avrora se puede utilizar para limitar el espacio máximo de pila de un programa. Proporcionará algunos informes informativos sobre la estructura de pila más grande actualmente en el programa, así como algunos informes informativos sobre el consumo de espacio y tiempo.

3.5 Comparación de rendimiento

TinyOS utiliza modelos de comportamiento para simular protocolos entre capas; el programa de simulación se trasplanta al nodo sin codificación secundaria.

A través del análisis y comparación del software de simulación anterior, podemos ver claramente las características y el alcance de aplicación de cada software de simulación. Podemos elegir el software de simulación adecuado según las necesidades de la investigación, para que nuestro aprendizaje. y la investigación puede obtener el doble de resultados con la mitad de esfuerzo.

Conclusión

La tecnología de simulación de redes proporciona un método científico y eficaz para la planificación y optimización de redes de comunicaciones. La simulación de redes se ha desarrollado en mi país solo en los últimos años, pero la tecnología de simulación de redes extranjeras ya está bastante madura. Debemos aprender con valentía de las tecnologías avanzadas extranjeras y promover el rápido desarrollo de la tecnología de simulación de redes nacionales.

Referencia

1 Yu Haibin, Zeng Peng et al. Redes de sensores inalámbricos inteligentes. Science Press, 2006, P283 ~ P303,

2 Shi Huaiwei, Li, Tecnología de simulación de redes y práctica de aplicaciones OPNET, Aplicación de sistemas informáticos, 2006.3.

3, Wu, basado en Simulación del protocolo TCP/IP de OMNeT, Revista de la Universidad Lanzhou Jiaotong (Edición de Ciencias Naturales), agosto de 2005.

4 Yuan Honglin, Xu Chen, Zhang Guoan, TOSSIM: Entorno de simulación de redes de sensores inalámbricos, sensores e instrumentos, volumen 22, número 7-1, 2006

2

Investigación sobre modelado de simulación de servidores virtuales en clúster

Fuente: Aplicación de tecnología electrónica Autor: Li Jindi y Ye Yuning

Explica el principio de funcionamiento de los servidores virtuales en clúster y tres métodos de equilibrio de carga , a través de ejemplos se analizan métodos de simulación y modelado para servidores virtuales, se crean modelos de entrada y de sistema para probar y simular el rendimiento del sistema, y ​​sus distribuciones de probabilidad se verifican en función de gráficos Q-Q y funciones de distribución acumulativa.

Palabras clave: servidor virtual de clúster equilibrio de carga simulación modelado distribución de probabilidad

Con el rápido crecimiento del tráfico de Internet y el tráfico de datos, están surgiendo nuevas aplicaciones una tras otra. Aunque la potencia de procesamiento y la intensidad informática de los servidores Intelel han aumentado en consecuencia, el crecimiento del volumen de negocios ha superado las estimaciones anteriores, por lo que los sistemas de servidores construidos según la configuración óptima en el pasado no pueden soportarlo. En este caso, abandonar el equipo existente y simplemente actualizar el hardware desperdiciará los recursos existentes. Por lo tanto, los servicios de red actuales y futuros no sólo deben proporcionar contenido más rico, mejor interactividad y mayor seguridad, sino también soportar un mayor volumen de tráfico, lo que requiere mayor rendimiento, mayor disponibilidad, buena escalabilidad y excelente rentabilidad. Por lo tanto, la tecnología de servidor virtual en clúster y el mecanismo de equilibrio de carga surgieron según lo exigieron los tiempos.

Los servidores virtuales en clúster pueden reunir algunos servidores reales para formar un todo escalable, altamente disponible y confiable. El equilibrio de carga se basa en la estructura de red existente y proporciona un método económico, eficaz y transparente para establecer un sistema de clúster de servidores, ampliar el ancho de banda de los equipos y servidores de la red, aumentar el rendimiento y mejorar las capacidades de procesamiento de datos de la red.

Mejorar la flexibilidad y disponibilidad de la red. Utilizando el mecanismo de equilibrio de carga, se puede asignar una gran cantidad de acceso simultáneo o tráfico de datos a múltiples dispositivos de nodo para su procesamiento respectivamente. La capacidad de procesamiento del sistema mejora enormemente y el tiempo de espera del usuario se reduce considerablemente.

En las aplicaciones reales, cuantos más servidores virtuales contengan servidores reales, mayores serán los indicadores de rendimiento de todo el servidor (como retraso de respuesta, rendimiento, etc.). ), pero el precio es más alto. Los canales u otras partes del grupo también pueden entrar en saturación. Por lo tanto, es necesario diseñar el modelo de simulación del servidor virtual basado en la aplicación real y determinar el tipo de distribución de probabilidad y los parámetros de las variables aleatorias basándose en los datos medidos del sistema real. Verifique la distribución de probabilidad de los indicadores de rendimiento, como la respuesta o el retraso de propagación, mediante métodos como diagramas Q-Q y funciones de distribución acumulativa, y analice de antemano el estado operativo y las características de rendimiento del servidor mediante software y herramientas de simulación (como Automod), haciendo que el rendimiento general del sistema de clúster estable y mejorando La objetividad y confiabilidad del diseño del servidor virtual reducen el riesgo de inversión en la construcción del servidor.

1 Arquitectura del servidor virtual del clúster

En términos generales, es necesario establecer un mecanismo de camuflaje de protocolo de Internet, es decir, camuflaje de IP, en el servidor virtual del clúster y luego crear un puerto IP. mecanismo de reenvío, y luego se proporcionan las configuraciones relevantes en el servidor real. La Figura 1 muestra la arquitectura general de un servidor virtual en clúster. Los servidores virtuales de cluster suelen incluir: RealServers y Load Balmlcer.

Debido a que el método de traducción de direcciones de red del servidor virtual se basa en el camuflaje de IP, no existen requisitos especiales para el sistema operativo del servidor real en segundo plano, que puede ser un sistema operativo Windows, Lmux o otros sistemas operativos.

El equilibrador de carga es la única entrada al sistema del clúster de servidores. Cuando llega una solicitud de un cliente, el equilibrador seleccionará un servidor entre los servidores reales en función de la carga real del servidor y el algoritmo de programación establecido, luego reenviará la solicitud al servidor seleccionado y registrará la situación de programación. Cuando lleguen otros mensajes para esta solicitud, este mensaje también se reenviará al servidor previamente seleccionado. Debido a que todas las operaciones se realizan en el espacio central del sistema operativo, la sobrecarga de programación es muy pequeña, por lo que el balanceador de carga tiene un alto rendimiento. La estructura de todo el clúster de servidores es transparente para los clientes, solo ven un único servidor virtual.

Existen muchas soluciones para implementar clústeres de equilibrio de carga, una de las cuales es Linux Virtual Server LVS (Linux Virtual Server). LVS utiliza tres tecnologías para implementar el equilibrio de carga: traducción de direcciones de red, enrutamiento directo y túnel IP.

Según los estándares del IETF, la traducción de direcciones de red permite que toda una organización aparezca en Internet con una dirección IP pública. El equilibrador de carga reescribe la dirección de destino del mensaje de solicitud mediante la traducción de la dirección de red y programa la solicitud al servidor real back-end de acuerdo con el algoritmo de programación preestablecido cuando el mensaje de respuesta del servidor real pasa por el equilibrador, la dirección de origen del; Se reescribe el mensaje, la dirección de la red privada interna se traduce a una dirección IP de red legal y luego se devuelve al cliente para completar todo el proceso de programación de carga.

La programación y gestión de conexiones de respuesta enrutadas directas es la misma que la traducción de direcciones de red, pero sus mensajes se reenvían directamente al servidor real. En la respuesta de enrutamiento directo, el ecualizador no modifica ni encapsula el mensaje IP, sino que cambia la dirección MAC de la trama de datos a la dirección MAC del servidor seleccionado y luego envía la trama de datos modificada a la LAN. Debido a que la dirección MAC de la trama de datos es el servidor seleccionado, el servidor definitivamente puede recibir la trama de datos y obtener el mensaje IP de ella. Cuando el servidor descubre que la dirección de destino del mensaje está en el dispositivo de red local, procesa el mensaje, luego responde con el mensaje de acuerdo con la tabla de enrutamiento y lo devuelve directamente al cliente.

El túnel IP es una tecnología que encapsula un mensaje IP dentro de otro mensaje IP. Esta tecnología puede encapsular paquetes de datos enviados a una determinada dirección de puerto y reenviarlos a otra dirección IP. Los usuarios utilizan la tecnología de túnel IP para empaquetar y reenviar mensajes de solicitud al servidor back-end, y los mensajes de respuesta se pueden devolver directamente desde el servidor back-end al cliente.

De esta manera, el balanceador de carga solo es responsable de programar las solicitudes y las respuestas se devuelven directamente al cliente sin procesar los paquetes de respuesta. Esto mejorará en gran medida el rendimiento de todo el sistema del clúster y reducirá efectivamente la carga del balanceador de carga. La tecnología de túnel IP requiere que todos los servidores admitan túnel IP o IP. Protocolo de encapsulación.

2 Determinación del retraso de los mensajes del servidor virtual del clúster

Al utilizar un sistema real con 5 servidores reales y utilizar tecnología de traducción de direcciones de red para implementar un servidor virtual Linux, los mensajes de solicitud y respuesta pueden Se obtendrá el archivo de marca de tiempo. Con base en estos archivos, se pueden calcular los datos necesarios para el modelado de simulación del servidor virtual del clúster.

Para determinar el tipo de distribución y los parámetros de las variables aleatorias, es necesario calcular los siguientes retrasos: (1) retraso en el transporte); desde el cliente al equilibrador de carga (2) retraso en la respuesta); ; del balanceador de carga; (3) ) Retraso de propagación desde el balanceador de carga al servidor real; (4) Retraso de respuesta del servidor real (5) Retraso de propagación desde el servidor real al balanceador de carga; balanceador de carga al servidor real; (7) Desde Retraso de propagación desde el balanceador de carga al cliente.

El tiempo de retraso anterior se describe en detalle en el archivo de marca de tiempo generado por el sistema real. El archivo contiene el siguiente contenido:

Cuando una solicitud de servicio llega al sistema de servidor virtual del clúster, genera un paquete de solicitud de sincronización con un número de secuencia único, reenvía el mensaje a un servidor real y se comunica entre los El servidor y el cliente establecen una conexión entre los dos extremos, y cada conexión tiene un número de puerto único; el servidor procesa el paquete de solicitud de confirmación a través de la conexión hasta que el servidor recibe el paquete de solicitud completo. Para cada tipo de mensaje de solicitud, el sistema da un mensaje de respuesta correspondiente. Por lo tanto, en diferentes archivos de marcas de tiempo de mensajes, si dos registros tienen el mismo número de puerto, tipo de mensaje y número de secuencia, son el mismo mensaje de solicitud o respuesta, y la simulación del sistema de servidor virtual del clúster se puede obtener restando las marcas de tiempo relevantes. datos necesarios para el modelado. Estos retrasos se pueden calcular con un programa C.

3 Modelo de simulación del sistema

Como se muestra en la Figura 2, el modelo de simulación del sistema de servidor virtual de clúster real mencionado anteriormente, todos los mensajes entregados o procesados ​​en el balanceador de carga, cada canal y cinco servidores reales son mensajes de solicitud o respuesta.

4 Determinación del modelo de variable aleatoria

Para utilizar variables aleatorias para simular servidores virtuales de clúster, es necesario determinar la distribución de probabilidad de sus variables aleatorias para que se puedan muestrear estas distribuciones. en el modelo de simulación para obtener las variables aleatorias requeridas deseadas.

4.1 Descripción general de los datos de latencia del servidor virtual real

En el equilibrador de carga del servidor virtual real, cada canal y cinco servidores reales, los mensajes de solicitud y respuesta tienen un cierto retraso. Algunas estadísticas de retraso de mensajes se muestran en la Tabla 1.

Se puede ver en los datos de la Tabla L que los valores medianos y medios de los retrasos de los mensajes son muy diferentes, por lo que la distribución de probabilidad es asimétrica el coeficiente de variación no es igual a l; la distribución de probabilidad no será una distribución exponencial, que puede ser una distribución gamma u otras distribuciones.

4.2 Distribución de probabilidad de variables aleatorias

La Figura 3 es un histograma del retraso de propagación del mensaje del canal entre el primer servidor real y el balanceador de carga, donde t es el tiempo de retraso del mensaje, h (t) es el número de intervalos de retardo de mensajes. Puede verse en la Figura 3 que los datos del retardo de propagación de paquetes en el canal obedecen aproximadamente a la distribución γ o distribución lognormal.

Se requieren dos parámetros para describir la distribución γ: el parámetro de forma α y el parámetro de escala (Scahj). La relación entre estos dos parámetros y la media m y la varianza v no es lineal:

La descripción de la distribución lognormal también requiere el parámetro de forma σ y el parámetro de escala μ, que están relacionados con la media m y la varianza v. La relación de la varianza v también es no lineal:

Las ecuaciones (1) a (4) se pueden obtener mediante el MLE (método de estimación de máxima verosimilitud (MLE) o el método de descenso más pronunciado. La Tabla 2 muestra que a través de estos 2. Los parámetros de distribución de probabilidad de retraso de paquetes en el canal desde el primer servidor real hasta el equilibrador de carga obtenidos mediante el método se pueden utilizar para verificar y determinar aún más la probabilidad de retraso en la propagación de mensajes en el canal anterior.

Utilizando los parámetros de la Tabla 2, se puede obtener la función de distribución acumulativa de la distribución γ, como se muestra en la Figura 4, donde t es el tiempo de retraso del mensaje y F (t) es la función de distribución acumulativa del retraso del mensaje. A modo de comparación, la distribución experimental también se representa en la figura. Los gráficos Q-Q de la distribución γ y la distribución lognormal se muestran en la Figura 5.

Como se puede ver en las Figuras 4 y 5, la distribución γ es muy consistente con la distribución de datos del retardo de propagación de paquetes en este canal. Los histogramas de retardo de mensajes de otros canales tienen formas similares. Después del cálculo y análisis, la distribución de probabilidad de los retrasos en la propagación de mensajes en estos canales también obedece aproximadamente a la distribución γ.

Con base en los datos de la Tabla 1 y los histogramas asociados, es difícil determinar la distribución teórica de los retrasos de los mensajes en el balanceador de carga y los servidores reales. Por lo tanto, se adopta la distribución experimental como modelo.

Simulación del modelo 5

Después de establecer el modelo de simulación del sistema del servidor virtual del clúster como se muestra en la Figura 1 y determinar las características de distribución de sus variables aleatorias, puede utilizar el software de simulación desarrollado. de Brooks Automation Automod ingresa el modelo y realiza análisis de simulación en el servidor virtual del clúster a través de la programación en el entorno de Automod.

Durante el proceso de simulación de Automod, los recursos proporcionados por el software se pueden utilizar directamente como unidades para procesar diversos datos de mensajes. Las actividades de cola de mensajes en varias partes del sistema se pueden implementar directamente a través de la cola; crear un generador de carga, que es equivalente a que un cliente use un servidor virtual en Inlemtet.

El uso de variables de atributos de Automod puede resolver el problema de la función de procesamiento de mensajes bidireccional del balanceador de carga. El equilibrador de carga utiliza un algoritmo de programación por turnos, es decir, suponiendo que todos los servidores reales tienen el mismo rendimiento de procesamiento, programa solicitudes a diferentes servidores en secuencia.

Los modelos de simulación de validación se pueden comparar de dos maneras: (1) el balanceador de carga, el número de respuestas en cola o mensajes propagados en cada servidor y canal real (2) los servidores reales y la utilización de la CPU del balanceador de carga; . Por ejemplo, cuando se utilizan respuestas reales o se propagan mensajes para retrasar datos, si se establece una cantidad menor de recursos en el modelo de simulación de Automod, durante el proceso de simulación encontrará que la mayor parte de la carga está bloqueada en la cola del servidor real. es decir, la capacidad real de procesamiento de mensajes del servidor es demasiado baja para compararla con la situación real del sistema. Si se establece una mayor cantidad de recursos, significa que la capacidad de procesamiento paralelo del servidor aumentará y la utilización del servidor real aumentará; y habrá poca carga o ninguna tarjeta en la cola del servidor real. Por lo tanto, los recursos del modelo de simulación en Automod se pueden ajustar según la situación real.

Si aumentas la tasa de generación de carga del generador de carga en Automod, equivale a aumentar el número de visitas de usuarios. Al observar la tasa de retención de carga en la cola, puede descubrir la capacidad máxima de procesamiento de mensajes del sistema, así como posibles cuellos de botella en varias partes del sistema al responder mensajes. Por ejemplo, si la tasa de generación de carga se duplica, aunque el sistema aún puede procesar todos los mensajes, la utilización promedio de cada servidor real alcanzará aproximadamente 80. Obviamente, el "cuello de botella" del mensaje de respuesta del sistema en este momento es el servidor real, por lo que es necesario agregar un nuevo servidor real al sistema.

A través de un sistema de servidores virtuales reales que incluye cinco servidores reales. Recopile y calcule datos de muestra para simulación y modelado. Determine la distribución de probabilidad de las variables aleatorias del sistema en función de la mediana, la media, el coeficiente de variación y el histograma de los retrasos de los mensajes del sistema. Los parámetros específicos de la distribución de probabilidad del canal se obtienen utilizando el método de estimación de máxima verosimilitud y el método de descenso más pronunciado. Con base en el diagrama Q-Q y la función de distribución acumulativa, la forma de distribución de probabilidad del canal se verifica y finalmente se determina. Utilice el software Automod para modelado y programación de simulación. Con la ayuda de los resultados de la simulación se puede descubrir la máxima potencia de procesamiento y los posibles "cuellos de botella" del servidor virtual. Al localizar los "cuellos de botella" del sistema de manera oportuna, el sistema se puede estudiar y mejorar más a fondo de manera específica, mejorando efectivamente el rendimiento del sistema. Los métodos de simulación utilizados también se pueden utilizar para modelado de simulación o análisis en otros campos.

En el modelo de simulación, para comparar diferentes sistemas de servidores virtuales, es necesario agregar más métodos de equilibrio de carga y algoritmos de programación. Los datos de muestra también deben ampliarse aún más para evitar la autocorrelación de los retrasos en los mensajes.