Usando la Teoría de Control

Usando la Teoría de Control para conseguir los
objetivos para un buen nivel de servicio en la
administración del rendimiento
Un enfoque bastante usado para lograr los objetivos de nivel de servicio para un
sistema objetivo (por ejemplo un servidor de correo) es el de agregar un controlador
que manipule los parámetros tuning (ajuste) del sistema objetivo. Nosotros
describimos una metodología para diseñar esos controladores para sistemas software
que se construyan en base a la teoría de control clásica. El enfoque clásico procede
en dos pasos: la identificación del sistema y el diseño del controlador. En la
identificación del sistema, nosotros construimos un modelo matemático del sistema
objetivo. Tradicionalmente, esto se basó en enfoques de los “principios básicos”,
usando un conocimiento detallado del sistema objetivo. Estos modelos pueden ser
difíciles de construir, y muy complejos para validarse, usarse, y mantenerse. En
nuestra metodología, un modelo estadístico (ARMA) se ajusta a las medidas históricas
del sistema a ser controlado. Estos modelos son más fáciles de obtener y usar y nos
permite aplicar las técnicas de diseño de control – teórico a una mayor clase de
sistemas. Cuando se aplicó a un servidor groupware de Lotus, obtuvimos ajustes del
modelo con R² entre 75% y 98%.
En el diseño del controlador, un análisis de los modelos nos lleva a un controlador que
conseguirá los objetivos de nivel de servicio. Nosotros reportamos un análisis de un
sistema de lazo cerrado usando una ley de control integral con Lotus Notes como el
sistema objetivo. El objetivo es mantener una referencia del tamaño de la cola. Usando
un análisis lugar de raíces de la teoría de control, nosotros somos capaces de predecir
la ocurrencia (o ausencia) de oscilaciones inducidas por el controlador en la respuesta
del sistema. Estas oscilaciones no son deseables porque aumentan la variabilidad, así
no podremos alcanzar los objetivos de nivel de servicio. Nosotros implementamos este
controlador para un sistema real Lotus Notes, y observamos una notable
correspondencia entre la conducta de un sistema real y las predicciones del análisis.
Esto nos permite seleccionar el parámetro propicio para el controlador del análisis.
1. Introducción
La dependencia a los sistemas TI es muy común y por eso se ha enfocado en el
incremento de la atención de la administración del nivel de servicio, especialmente
consiguiendo un tiempo de respuesta y objetivos de rendimiento. Un enfoque
comúnmente usado es la de tomar un sistema objetivo existente y agregar un
controlador que tenga acceso a las métricas y a los parámetros tuning (ajuste) del
sistema. Basado en la información de realimentación presente en las métricas, el
controlador manipula los parámetros de ajuste para conseguir los objetivos de nivel de
servicio deseados. Ejemplos de sistemas software de lazo cerrado abundan: el
despachador de red (network dispatcher), que ajusta a los parámetros de balanceo de
carga en los clusters de los servidores web; el administrador de carga de trabajo del
Almacenamiento Virtual Múltiple (Multiple Virtual Storage), que ajusta las locaciones
de memoria y otros parámetros de ajuste de otros sistemas operativos para alcanzar
los objetivos de tiempo de respuesta y objetivos de rendimiento; y programadores

compartidos justos, que ajustan los parámetros de ajuste nice de UNIX para alcanzar
las fraccionadas locaciones de la CPU.
Mientras una considerable atención se ha enfocado a los mecanismos software
necesitados para habilitar sistemas de lazo cerrado (ejemplo: instrumentación y
acceso de control de ajuste), menos atención se le ha dado a la evaluación rigurosa al
comportamiento del controlador. Los científicos de computación usan frecuentemente
simulaciones para entender y evaluar la conducta del controlador. Sin embargo, los
estudios de simulación pueden consumir mucho tiempo, ser caro, y propenso a
errores.
El diseño de un lazo cerrado o sistemas de control de realimentación es también
estudiado extensamente en otras disciplinas de ingeniería, como la ingeniería
mecánica y la aeronáutica. En estas disciplinas de ingeniería, los diseñadores
generalmente emplean teoría de control lineal. Que usa las relaciones de entrada –
salida de sistemas lineales para estudiar las propiedades del controlador como:
stability (entradas finitas que producen salidas finitas), bias (que tan bien los objetivos
son alcanzados), y settling time (cuanto se demora para alcanzar el estado estable).
Esta teoría provee de robustos y rigurosos principios matemáticos para el diseño y
análisis de sistemas de lazo cerrado.
La meta de nuestro trabajo es la de desarrollar una metodología para, y evaluar el
valor de, aplicar la teoría de control a la evaluación de controladores usados para la
administración de nivel de servicios o sistemas software. Mientras esto no es una idea
nueva en sí, nosotros creemos que nuestro enfoque permite la aplicación de esas
técnicas a una mayor variedad de sistemas que el enfoque tradicional. En este artículo
(paper), nosotros demostramos el poder de un análisis teórico de control a un
controlador para realizar el control de admisión de un servidor workgroup Lotus Notes.
Una principal preocupación de aplicar la teoría de control lineal a sistemas
computacionales es que la suposición de un sistema lineal encaja poco a las
realidades de las colas en un sistema computacional, que son casi siempre no
lineales. Si bien hay una teoría bien desarrollada de control no lineal, que es más difícil
de aplicar, este no se generaliza a través de sistemas y provee una menor visión.
Nuestra perspectiva es más pragmática. Nosotros planteamos la pregunta “¿Podemos
construir y analizar las propiedades de un sistema software de lazo cerrado de la vida
real usando una suposición de sistema linear? Incluso en ingeniería mecánica,
disciplina donde la teoría de control está bien establecida, la linealidad no se cumple
(ejemplo: corrientes de fluido turbulentas). Más bien, el éxito de la teoría de control
lineal ha ocurrido por la creatividad en su aplicación.
La metodología de diseño de controlador clásico consiste en dos pasos:
Identificación del Sistema: Construir una función de transferencia que relaciona
valores de entradas pasadas y presentes a valores de salidas pasadas y presentes.
Estas funciones de transferencia constituyen un modelo del sistema.
Diseño del controlador: Basado en las propiedades de la función de transferencia y
los objetivos deseados, se elige una ley de control particular. Las técnicas de la teoría

de control son usadas para predecir como el sistema de comportará una vez que el
controlador elegido se agregue.
En trabajos anteriores en la aplicación de técnicas de control teóricas a sistemas
computacionales han sido usados generalmente los principios básicos para realizar la
identificación del sistema. Por ejemplo, el trabajo de control de congestión construye
ecuaciones de estados de transición basados en conocimiento detallado de (o
suposiciones acerca) protocolo, carga de trabajo, pérdidas, etc. Desafortunadamente,
hay varias deficiencias con un enfoque de “principios básicos”. Primero, para sistemas
complejos, es difícil construir un modelo proveniente de los “principios básicos”,
porque se hacen suposiciones irrealistas. Esta dificultad ha sido una principal barrera
para aplicar la teoría de control a sistemas computacionales. Segundo, los modelos de
los “principios básicos” emplean información detallada acerca del sistema objetivo. Ya
que estos detalles pueden cambiar frecuentemente (ejemplo: con cada versión de
software), un enfoque de “principios básicos” puede requerir una participación experta
de manera continua. Esto es caro e impráctico. Tercero, el enfoque de “principios
básicos” no se dirige a una validación de modelo. Sin la validación de modelo, no es
claro como las ideas obtenidas usando la teoría de control se relacionan con el
sistema estudiado.
Más que proceder con los “principios básicos”, nosotros defendemos un enfoque
empírico para la identificación del sistema. Aquí, los parámetros de entrada y salida
necesitan ser identificados, como antes. Pero más que derivar las funciones de
transferencia basadas en conocimiento de “principios básicos”, un modelo
autorregresivo de media móvil (ARMA) es construido, y las técnicas estadísticas
estándar son empleadas para estimar los parámetros ARMA. Este enfoque trata al
sistema como una caja negra, y así no está afectado por la complejidad del sistema o
la falta de conocimiento experto. Además, los cambios en el sistema objetivo pueden
ser fácilmente acomodados reestimando parámetros del modelo. En este artículo,
mostramos que el enfoque trabaja bien para el servidor Notes: R² entre 75% y 98%.
Para la ley del controlador, usamos un controlador integral saturado. El
comportamiento de este controlador está determinado por un parámetro, llamado gain
(ganancia). La teoría de control nos dice que la ganancia debería ser larga para
obtener una respuesta rápida a las entradas cambiantes, pero si es muy larga, puede
conducir a comportamientos no deseados en el sistema, como las oscilaciones
inducidas por el controlador. La meta del análisis, entonces, es identificar cuán grande
puede ser la ganancia sin causar esos comportamientos no deseados. La forma
particular de los modelos nos permite usar técnicas estándar de la teoría de control
para realizar los análisis. Nuestros resultados demuestran que hay una considerable
correspondencia entre las predicciones hechas por la teoría de control y el
comportamiento observado de un servidor Notes. En particular, somos capaces de
identificar los valores de ganancia factibles para satisfacer los objetivos de control.
El resto de este artículo está organizado de la siguiente manera. La sección 2 describe
el servidor Notes y cómo este sistema objetivo está embebido dentro de un lazo
cerrado para alcanzar los objetivos de nivel de servicio. La sección 3 detalla nuestro
enfoque a la identificación de sistemas. La sección 4 habla acerca del diseño de
controladores y usos de estudios empíricos para acceder a la exactitud de los

conocimientos obtenidos a partir de la teoría de control. Nosotros brindamos un
resumen y proponemos trabajos futuros en la sección 5. Finalmente, en la sección 6
discutimos trabajos relacionados.
2. Lotus Notes y su control de lazo cerrado
Esta sección describe las características relevantes del servidor Lotus Notes y provee
más detalles en como el control de lazo cerrado es obtenido de su sistema objetivo.
Arquitecturalmente, Lotus Notes es un sistema cliente – servidor. Software cliente
convierte la actividad de usuario de alto nivel (clics del mouse, etc.) en llamadas a
procedimientos remotos (RPCs) que son enviados al servidor. El servidor mantiene
una cola de estos RPC en progreso. Una vez que un RPC es servido, una entrada es
hecha en el log del servidor, y una respuesta apropiada es enviado al cliente. Los
clientes operan de una manera síncrona, esperando por una petición previa para
completar antes de enviar una petición nueva. El protocolo cliente / servidor es
orientado a sesión. Una nueva sesión es empezada después de una inicialización de
sesión RPC es aceptada por el servidor. Nosotros usamos el término carga ofrecida
para referirnos a la carga impuesta al servidor por peticiones de clientes. En el caso de
clientes homogéneos, la carga ofrecida es expresada en términos del número de
clientes. Nuestra métrica de nivel de servicio es la longitud de la cola de peticiones
RPC en progreso, a partir de ahora referido como tamaño de cola.
El parámetro tuning (ajuste) SERVER_MAXUSERS regula el número de usuarios
permitidos de acceder al servidor en cualquier momento. Este es un control a nivel de
sesión (opuesto a controles RPC de nivel de paquetes). Esto opera rechazando RPCs
de inicialización de sesión una vez que el número de usuarios conectados supere a
SERVER_MAXUSERS. Como tal, este parámetro tiene un algún efecto complejo en la
longitud de la cola. En particular, cambiando SERVER_MAXUSERS no tiene efecto
hasta que un RPC de inicialización de sesión llega, entonces sesiones existentes no
son afectadas.
Desafortunadamente, nosotros no tenemos mediciones directas de tipos de RPC y
longitud de cola. En vez, obtenemos estos valores a partir de un sensor de medida que
saca muestras del log del servidor a una ratio de una vez por minuto. El cálculo de la
longitud de la cola es realizada contando los RPCs que estuvieron activos en el
anterior quantum de tiempo. Sin embargo, ya que los RPCs que están esperando en la
cola no están presentes en el log, este enfoque desestima la verdadera longitud de
cola y el verdadero ratio de RPC. Esto hace de la medición tener pérdidas. Podemos
mejorar la aproximación retardando uno o más unidades de tiempo antes de reportar
las medias ya que al hacerlo permite a más RPCs completarse y así darnos una
cuenta más precisa de los RPCs que se están ejecutando.

Figura 1: Control de lazo cerrado de Lotus Notes
Los administradores de Notes están muy interesados en el control de longitud de la
cola lo que constituye una manera de manejar el equilibrio entre los tiempos de
respuesta y rendimientos. La figura 1 muestra cómo se construye un sistema de lazo
cerrado para controlar longitud de la cola de Notes. Notes proporciona una interfaz
para manipular los parámetros de ajuste tales como SERVER_MAXUSERS. Nosotros
utilizamos la medición del sensor antes mencionadas para obtener valores de longitud
de la cola. El administrador especifica un valor deseado, o el valor de referencia, para
la longitud de la cola. El valor de referencia especifica una política de gestión que el
sistema de lazo cerrado trata de lograr. El controlador tiene como entrada el control
de errores, que es la diferencia entre el valor de referencia y el valor medido de la
longitud de la cola. Dependiendo de los valores actuales (y pasados) del error,
SERVER_MAXUSERS se ajusta. El algoritmo que determina el valor de
SERVER_MAXUSERS se llama la ley de control.
3. Identificación del sistema y validación
En esta sección describe nuestro enfoque de la identificación de sistemas y su
aplicación a Lotus Notes. La identificación de sistemas comprende de tres partes. La
primera, construcción diagrama de bloques, que identifica los componentes
funcionales importantes y sus relaciones de entrada - salida. La segunda, forumlación
Administrator: Administrador
Reference Value: Valor de referencia
Controller: Controlador
Tuning control: Control de afinación
Server: Servidor
Users: Usuarios
Server log: Log del servidor
Sensor: Sensor
Queue Length: Tamaño de la cola

de la función de transferencia, los modelos de las relaciones de entrada – salida de
cada elemento en el diagrama de bloques. La forma particular de los modelos que
construimos (funciones de transferencia lineales) es importante porque nos permite
aprovechar un gran conjunto de técnicas de análisis que están disponibles en la teoría
de control. En tercer lugar, estimación de parámetros y su evaluación, que evalúa la
calidad del modelo desarrollado.
3.1 Construcción del diagrama de bloques
Un diagrama de bloques muestra los componentes de un sistema y el flujo de
información entre ellas. La Figura 1 proporciona un punto de partida para modelar el
servidor Notes. Aquí, las tasas de RPC y SERVER_MAXUSERS son entradas, y
longitud de la cola es la salida. Esto se muestra en la Figura 2 (a).
Modelos del servidor Notes (lazo abierto)
Hay dos problemas con los anteriores. En primer lugar, está incompleta ya que las
mediciones de pérdidas no se consideran. Por lo tanto, debe ser incluido un
componente del sensor por separado.
El segundo problema es más complicado. Desde SERVER_MAXUSERS tiene un
efecto indirecto en las tasas de RPC, las dos entradas no son independientes. Por lo
tanto esto no es un sistema lineal. Para solucionar esto, se divide la región de
funcionamiento del servidor Notes en dos regiones. En el primero,
SERVER_MAXUSERS excede la carga ofrecida y por lo que el parámetro de ajuste no
RPC rate: tasa de RPC
MaxUsers: Usuarios máximos
Actual Queue Length: longitud de cola real
Notes Server: Servidor Notes

tiene efecto. En el segundo, SERVER_MAXUSERS es menor que la que la carga
ofrecida y SERVER_MAXUSERS usuarios son permitidos en el sistema. Nos
centramos en la segunda región operativa. Aquí, el valor de la carga ofrecida no es
relevante (siempre y cuando nos quedemos en esta región) y, por tanto, puede ser
ignorada. En otras palabras, no hay necesidad de considerar las tasas de RPC como
una entrada.
¿Podemos adecuar el modelo del servidor Notes si SERVER_MAXUSERS es la única
entrada en la función de transferencia? Para responder esta pregunta, la Figura 3
traza una longitud de cola cuando la carga ofrecida es de 300 usuarios y
SERVER_MAXUSERS es incrementado por 20 cada 20 minutos. (Estos datos son
obtenidos usando la disposición experimental descrita en la sección 4.4) El impacto de
SERVER_MAXUSERS es claro, sugiriendo que sería suficiente. Una evaluación más
cuantitativa se establece en la Sección 3.3.
Esto se traduce en el diagrama de bloques en la figura 2 (b). Tenga en cuenta que se
trata de un sistema de entrada y salida única.
Figura 3: Efecto de SERVER_MAXUSERS sobre la longitud de la cola
Offered load: carga ofrecida
Max Users: Máxima cantidad de usuarios
Time: Tiempo

3.2 Formulación de la Función de Transferencia
Nosotros debemos ser más precisos acerca de cuantificar las relaciones de entrada –
salida. En todo momento, suponemos que el tiempo es discreto con tamaños de
intervalo uniformes. Consideremos un sistema lineal con entrada x(t) y salida y(t). Por
las relaciones de entrada-salida, nos referimos a un modelo ARMA de la forma:
(1)
donde (n,m) es el orden del modelo y ai; bj son constantes que son estimados a partir
de los datos. Cuando los valores para n, m, ai, bi son especificados, esto es la función
de transferencia del sistema lineal. Para propósitos de análisis, es más conveniente
convertir las funciones de transferencia a partir de un dominio de tiempo a un dominio
z (frecuencia), donde z es un número complejo. Esto es, lo que queremos para usar
, el cual es conocido como la transformada z.
La transformada z tiene varias propiedades útiles. Por ejemplo, considere dos
sistemas lineales que transforma A(z) y B(z). Luego la transformación del sistema
formado conectando estos dos en serie es A(z)B(z). Si las salidas de los dos sistemas
son sumados, entonces el sistema combinado tiene la transformación A(z) + B(z).
También, si las entradas a A(z) es multiplicado por k, entonces la transformada
asociada es kA(z).
Aplicando estos principios a la ecuación. (1) y suponiendo que n ≥ m (que es una
restricción típica), se obtiene la transformada z:
(2)
Usamos la forma general de la función de transferencia en la ecuación. (2) para
determinar el N(z), la función de transferencia para el Servidor Notes, y S(z), la función
de transferencia del componente del sensor. Sea q(t) el valor de la longitud de la cola
en el tiempo t y u(t) el valor de SERVER_MAXUSERS. Tenga en cuenta que q(t) es la
longitud de la cola real, no el producido por el sensor. Para N(z), se vuelve un buen
ajuste si n = 1 y m = 0 (ver Tabla 1). Es decir,
Este es un modelo de primer orden ya que max(n, m) = 1.
Modelando S(z) es un poco más complicado. Sea m(t) la longitud de la cola medida
como salida por el sensor. Como se señaló anteriormente, la salida del sensor es con
pérdida, por lo general en m(t) subestima la longitud de la cola real q(t). Una vez más
usamos un modelo de primer orden:

Cuya transformación es:
Sin embargo, esto no es suficiente. Recuerde que para obtener una estimación precisa
de q(t), podemos retrasar d unidades de tiempo para que RPCs de larga duración
presentes durante el tiempo t completen su ejecución. Para modelar este efecto, se
define m(t) tal que: . En el dominio z, esto es simplemente
Juntando esto con la ecuación anterior, obtenemos:
Tenga en cuenta que en el modelado de N(z) y S(z), hemos tratado a los componentes
como cajas negras, y no han utilizado ningún detalle sobre su funcionamiento interno.
3.3 Parámetros de Estimación y Evaluación del modelo.
Dadas las formas funcionales de N(z) y S(z), debemos estimar sus parámetros.
Nuestro enfoque es estadístico. En primer lugar, las mediciones del sistema objetivo
se obtienen al variar los parámetros de entrada de forma controlada, como los datos
de la Figura 3. Luego, utilizamos la regresión de los mínimos cuadrados para estimar
ai, bj para diferentes valores de (n, m): En general, el ajuste del modelo se mejora a
medida que (n, m) se incrementan. Buscamos un modelo que tiene un ajuste
adecuado y de bajo orden.
Tabla 1: Valores y Coeficientes del Modelo R²
¿Qué tan bien estas funciones de transferencia caracterizan las relaciones de entrada-
salida en el sistema real? Una forma de responder a esta pregunta es utilizar la
métrica R², la fracción de la variabilidad de la variable de salida que se explica por la
función de transferencia. Resulta que un modelo de primer orden provee un buen
ajuste para los dos N(z) y S(z). La Tabla 1 reporta los valores de ai, bj y R² para estas
Delay: Retraso
Notes Server: Servidor Notes
Sensor: Sensor

funciones de transferencia. Para el Servidor Notes, R² es bastante grande, casi el
98%! Este es un excelente ajuste. La calidad de este modelo puede ser estudiado a
fondo mediante el trazado de los valores observados de longitud de la cola frente a las
predichas por el modelo, que se muestra en la Figura 4. Tenga en cuenta que casi
todas las observaciones se encuentran cerca de la línea de pendiente unidad donde el
valor previsto es igual al valor real.
Figura 4: Comparando las predicciones del modelo N(z) con los valores observados
Para la función de transferencia del sensor, R² es menor, aunque sigue siendo
aceptable. Tenga en cuenta que a medida que d aumenta también lo hace R², y se
aproxima a 1. Ambos efectos son esperados ya que con mayores retrasos, los valores
medidos se aproximan al valor real.
4. Diseño del controlador y Evaluación
Una vez completada la identificación del sistema, el siguiente paso es diseñar y
evaluar uno o más controladores. Comenzaremos describiendo cómo construir el
controlador de una ley de control. Esto se hace bajo el supuesto de que el sistema es
lineal. Desafortunadamente, la linealidad no siempre se cumple. Por lo tanto, un es
necesario un análisis preliminar para determinar las condiciones en que la linealidad
es razonable. A continuación, utilizamos la teoría de control para obtener información
sobre el comportamiento del controlador, en especial la presencia de oscilaciones
inducidas por controlador. Estas predicciones se evaluaron usando las mediciones de
un servidor Notes real.
Predicted Queue Length: Tamaño de la cola
predichas
Observed Queue Length: Tamaño de la cola
observadas

Figura 5: Sistema con su controlador
El punto de partida para el diseño del controlador es una ley de control que describe
cómo funciona el controlador. Nos centramos en el control integral, una técnica
ampliamente utilizada que es un enfoque razonable para el servidor Notes. Sólo una
ley de control se considera ya que nuestro objetivo es demostrar el valor de nuestra
metodología.
Una expresión del tiempo-dominio de la ley de control integral es
(3)
donde u(t) es el nuevo valor de control en el tiempo t, y e(t) = r(t) - m(t) es el error de
control. El parámetro Ki > 0 se llama gain (ganancia). Intuitivamente, esta ley de
control dicta que SERVER_MAXUSERS debe ser ajustada en forma incremental en
función de su valor anterior y el error de control de ganancia ponderada. De la
definición de una función de transferencia, tenemos
(4)
Para un controlador integral, la intuición es que los valores Ki altos conducen a una
respuesta más rápida. Sin embargo, la atención es necesaria ya que mayores valores
de Ki pueden causar oscilaciones o incluso inestabilidades.
Hay un problema traducción directa de esta ley de control en software que se utiliza
para el control de Lotus Notes. En concreto, si es demasiado grande,
SERVER_MAXUSERS se establece en un valor que puede causar un error de
software. Para evitar estas situaciones, limitamos el rango de SERVER_MAXUSERS
mediante la ampliación de la ley de control: Estos
controladores saturados no son lineales. Por lo tanto, nuestro modelo está restringido
a las regiones en las que estos límites no son alcanzados.
Utilizando los principios de transformaciones z discutidas anteriormente, tenemos

Resolviendo estas ecuaciones, tenemos la siguiente función de transferencia para el
sistema en la Figura 5:
(5)
4.2 Análisis preliminar
Ya que nuestro modelo ha sido desarrollado bajo el supuesto de que Min ≤ u(t) ≤ Max,
cualquier análisis basado en el modelo es necesariamente restringido a esta región
también. Nosotros realizamos un análisis preliminar para determinar los valores de Ki
para que se mantenga.
Nuestro enfoque es el siguiente. Dividimos la región de control en tres partes: u(t) =
Max, u(t) = Min y Max < u(t) < Min. Llamamos a estos estados como Max, Min, e
Intermedio, respectivamente. Buscamos entender las condiciones en que los valores
de control estarán en los estados Min y Max. Si nos quedamos fuera de estas
regiones, entonces las suposiciones de nuestro análisis se deberían mantener.
La Figura 6 muestra las transiciones de estado obtenidos a partir de la ley de
control. Vemos que a medida que , todas las transiciones están entre los
estados 1 y Max. Está claro que queremos evitar grandes Ki.
¿Qué tan grande puede ser Ki sin encontrar estados Min o max? Sea ε el mayor error
que se produce una vez que el sistema de lazo cerrado se encuentra en
funcionamiento. Entonces, si
nunca hacemos transición a estados extremos. En nuestros estudios empíricos de un
sistema Notes sin control, la longitud de las colas van aproximadamente desde 20 a
100 si d = 0 y 60 a 140 si d = 2. Así que, si no hay bias (sesgo), a continuación en
cualquier caso, ε = 40. Establecemos Max = 200 para que iguale a la carga ofrecida, y
Min = 1. Eso nos da: Ki < 5.
4.3 Estudios Analíticos
En esta subsección se utiliza la teoría de control clásica para evaluar el sistema de
lazo cerrado descrito por la ecuación (5). Sabemos por la teoría de control que Ki debe
ser lo más grande

Figura 6: Análisis Preliminar: transiciones de estado de control
como fuese posible para dar una respuesta rápida. El problema que se trata aquí es
de predecir cuándo Ki será tan grande que hay oscilaciones inducidas por
controlador. Esta predicción se hace mediante el estudio de propiedades de la función
de transferencia para el sistema de lazo cerrado, que es la ecuación (5).
En primer lugar, algunos antecedentes son necesarios para entender la lógica de este
análisis. Tenga en cuenta que las funciones de transferencia que consideramos
pueden ser expresadas como el cociente de dos polinomios en z. Las raíces del
numerador se llaman sus ceros y las raíces del denominador son sus polos. En
concreto, si A(z) y B(z) son dos polinomios de z y H(z) = es una función de
transferencia, entonces los ceros son los valores de z donde A (z) = 0 y los polos son
donde B(z) = 0.
Los polos y ceros de una función de transferencia proveen una idea de la estabilidad y
oscilaciones inducidas por controlador. Recordemos que z es un número imaginario. Si
alguno de los polos de H(z) se encuentran fuera del círculo unitario, entonces H(z) es
inestable. Es decir, una entrada acotada produce una salida acotada. Este es el
resultado de la asignación del dominio de z para el dominio del tiempo: la ecuación de
dominio del tiempo se expresa en términos de una serie geométrica en la cual los
polos son elevados a la potencia t. Así, si un polo tiene una magnitud que supera uno,
se convierte en no acotada cuando t se hace grande.

Otro dato de interés hace referencia a los polos cuando Im(z) ≠ 0. Estos polos
contienen términos de dominio de tiempo de la forma donde Esta es
una sinusoide y así se presentan oscilaciones que aumentan la variabilidad de q(t).
El gráfico de lugar de raíces proporciona una manera sistemática para estudiar la
ubicación de los polos en el plano complejo. La figura 7 muestra el gráfico de lugar de
las raíces para una respuesta a escala unitaria (cambio de unidad en el parámetro de
ajuste) del sistema descrito por la ecuación (5). Considerar el gráfica más a la
izquierda, que se ocupa de d = 0. El eje horizontal del gráfico corresponde a Re(z) y el
eje vertical es Im(z). Para proporcionar un marco de referencia, hay un círculo unitario
con centro en 0. Las X indican los polos de G(z)N(z)S(z), y las o’s indican sus ceros. El
lugar de raíces es la curva dentro del círculo unitario que traza los polos a medida que
Ki 0 a ∞. Dado que todos los polos se encuentran dentro del círculo unitario, no hay
ningún problema con la estabilidad. Además, observe que para grandes Ki (por
ejemplo: 0.1 y 1), los polos se encuentran en el eje real. Por lo tanto, no hay un
componente Sinusoidal asociados con la respuesta al escalón de esas gain
(ganancias). Sin embargo, para Ki más grandes (por ejemplo, 5 y 50), hay un
componente imaginario no-cero a los polos. Esto sugiere la presencia de oscilaciones
inducidas por controlador que aumentan la varianza de la longitud de la cola.
Consideremos ahora el gráfico del lugar de raíces para d = 2, que es el gráfico
derecho de la figura 7. Mientras que Ki = 0.1 se encuentra en el eje real, los polos para
las otras ganancias son componentes imaginarios no ceros. Por lo tanto, esperamos
oscilaciones inducidas por controlador que se traducen en una mayor variabilidad en la
longitud de cola.
Figura 7: Gráfico de lugar de raíces para retraso = 0 y retraso = 2
Delay Root Locus: Retraso de lugar de raíces
Imag Axis: Eje imaginario
Real Axis: Eje Real

Nos señalan, además, que para d = 2, el polo en Ki = 5 se encuentra fuera del círculo
unitario. Esto sugiere un problema de estabilidad. Por supuesto, el sistema no se
puede volver inestable ya que hemos acotado el rango de valores que es asignado a
SERVER_MAXUSERS. Sin embargo, ganancias grandes pueden causar otro
problema - un ciclo límite en el que el parámetro de ajuste sólo toma valores en
. Discutimos esta cuestión en la Sección 4.4. El análisis revela que si
queremos introducir un retraso a fin de obtener información de longitud de cola más
exactas, esto limita severamente el rango de valores de ganancia que podemos
utilizar, y por lo tanto limita la capacidad de respuesta del sistema de control. Por lo
tanto, tenemos una forma rigurosa de la negociación fuera de exactitud para recencia
en los datos del sensor.
4.4 Evaluaciones Empíricas
Aquí, presentamos los resultados empíricos para varios valores de Ki utilizados en un
controlador integral en un sistema real con una carga de trabajo sintética. Nosotros
estudiamos cómo las predicciones hechas por la teoría de control se comparan con el
comportamiento del sistema real.
El banco de pruebas para nuestros experimentos consiste de un generador de carga
de trabajo, nivel de producto servidor Notes, un sensor que se ejecuta en el servidor
Notes, y un controlador que se ejecuta en una tercera máquina (para no perturbar el
servidor Notes). El generador de carga de trabajo simula la actividad de varios clientes
mediante la ejecución de n copias de un script idéntico que envía RPCs al servidor.
Estos scripts se ejecutan en varias ocasiones con un retraso de un minuto entre las
ejecuciones. El script fue seleccionado de la suite NotesBench, un estándar para la
generación de carga de trabajo. Durante el experimento, la carga ofrecida al servidor
(es decir, el número de usuarios que intentan a las solicitudes de emisión) se mantiene
constante a 200 usuarios. La longitud de la cola de referencia se establece
inicialmente en 10, y después de 60 minutos se cambia a 25.
Figura 8: Ejecución de un sistema sin control (SERVER_MAXUSERS > carga ofrecida)

Consideremos ahora el comportamiento del sistema de lazo cerrado si el controlador
está deshabilitado. Esto se efectúa mediante la modificación de la ley de control tal
que SERVER_MAXUSERS se establece a carga ofrecida. La figura 8 muestra el
resultado de ambos d = 0 y d = 2. En la anterior, la longitud de la cola se mantiene
alrededor de 80. En el último, es de aproximadamente 100. Estos resultados son
consistentes con el hecho de que d = 0 tiene más pérdidas que d = 2. También vemos
variabilidad sustancial en ambos casos, con cambios en longitud de la cola de 40 que
es común. Esta variabilidad viene, en gran parte, de tener tiempos aleatorios entre
ejecuciones de script.
Tenga en cuenta además que parece existir un patrón oscilatorio en la longitud de la
cola que se alterna entre valores pequeños y grandes. Para entender por qué, tenga
en cuenta que la duración de un script también de un minuto. Además, recuerdan que
los clientes operan de forma síncrona en el que sólo una petición puede ser
sobresaliente. Así, se tiende a alternar entre conjuntos de clientes que están
ejecutando y los que están a la espera de ejecución. Por lo tanto, incluso sin un
controlador modificando SERVER_MAXUSERS, está presente una variabilidad
significativa.
La figura 9 muestra el efecto del controlador para Ki ε {0.1, 1, 5} y retrasos de 0 y 2. La
figura consiste de 12 gráficos presentadas en dos columnas. La columna de la
izquierda es d = 0 y la columna de la derecha es d = 2: Hay tres partes en la
figura. Cada parte considera un único valor de Ki. Por ejemplo, la parte (a) consiste en
las dos primeras filas de los gráficos. La longitud de la cola de los gráficos de la
primera fila (y el valor de referencia) en función del tiempo. La segunda fila muestra el
valor del control al mismo tiempo que el gráfico de la longitud de la cola. La parte (b)
hace lo mismo para Ki = 1, y la parte (c) muestra Ki = 5.
Considere la parte (a). Si bien hay un transitorio inicial, la longitud de la cola converge
al valor de referencia. Hay una cierta variabilidad, pero la variación es
considerablemente menor que en la Figura 8. Esta observación es válida para ambos
d = 0 y d = 2: Estos resultados son consistentes con el análisis de lugar de raíces que
se encuentra Im(z) = 0 para Ki = 1, donde z es un polo de la función de transferencia
del sistema de lazo cerrado.
Consideremos ahora la parte (b) en el que gain (ganancia) se ha incrementado por un
factor de diez. Comenzamos con d = 0. Aquí, la variabilidad es sustancialmente mayor
que para Ki = 0.1. Sin embargo, no parece ser una oscilación inducida por
controlador. También los valores de longitud de la cola seguirán centradas en el valor
de referencia que sugiere que el bias (sesgo) es pequeño. La situación para d = 2 no
es tan bueno. Hay un ciclo pronunciado en los valores de longitud de la cola, un ciclo
que corresponde a un ciclo en los valores del control. Esto sugiere una oscilación
inducida por el controlador. Nos damos cuenta que el análisis de lugar de raíces
Delay: Retraso
Queue length: Longitud de la cola
Time: Tiempo

predijo ambos resultados en que: (a) no hay polo con un componente imaginario
distinto de cero para Ki = 1, d = 0 y (b) existe un polo de Ki = 1 d = 2.
¿Cuál es la razón de las oscilaciones en la longitud de la cola? Principalmente, este es
el resultado de un exceso de compensación. Es decir, Ki = 1 es tan grande para la e(t)
en d = 2 que los errores positivos grandes hacern que el controlador aumente
SERVER_MAXUSERS y este a su vez hace que el siguiente e(t) sea tan negativa que
SERVER_MAXUSERS sea muy reducido, y así sucesivamente. Esto es evidente en el
gráfico de u(t) en la Figura 9 parte (b).
En la parte (c), gain (ganancia) es cincuenta veces más grande que en la parte (a). La
variabilidad es muy grande, incluso mayor que en un sistema sin control. De hecho,
hay oscilaciones que están claramente relacionadas con cambios en u(t). Recordemos
que el análisis de lugar de raíces predice la presencia de oscilaciones inducidas por
controlador para este caso.
Es instructivo considerar un ejemplo extremo, uno que claramente viola la restricción
de Ki < 5 que se estableció en nuestro análisis preliminar. La figura 10 muestra los
resultados de los estudios realizados para Ki = 50. Aquí, vemos un ciclo límite fuerte
para el valor de control, y el gráfico de longitud de la cola resultante muestra grandes
oscilaciones. De hecho, cambiando el valor de referencia no tiene ningún impacto
aparente en el comportamiento del sistema. En cambio, el control oscila entre valores
extremos de una manera disfuncional.
La Tabla 2 cuantifica estos resultados para la región donde el valor de referencia r(t) =
25. Varias métricas se presentan: longitud de la cola media, la desviación estándar de
la longitud de la cola, y el error RMS (root-mean-square). La longitud media de cola se
relaciona con el bias (sesgo) en lo que estamos interesados en la diferencia entre este
número y 25, el valor de referencia. La desviación estándar de la longitud de la cola
refleja la variabilidad en el sistema. El error RMS (Root-mean-squared) con respecto al
valor de referencia cuantifica cuán extremos se vuelve el bias (extremo).
Tabla 2: Estadísticas de rendimiento del controlador
Delay: Retraso
Mean:Media
St. Dev:Desviación estándar
RMS Error: Error media cuadrática de raíces

Figura 9: Efecto del controlador en un sistema real
Delay: Retraso
MaxUsers:Máxima Cantidad de Usuarios
Time: Tiempo

Figura 10: Controlador (inestable) con Ki grande
Tenga en cuenta que las desviaciones estándar son pequeñas para los valores de (Ki,
d) que el lugar de las raíces identificado sólo tenía valor de polos reales. Por otra
parte, las desviaciones estándar son grandes para los valores de (Ki, d) que tienen los
polos complejos. También se observa que para mayores Ki, d, hay un problema con
los bias (sesgo). Esto se indica con grandes valores de RMS y la diferencia entre la
longitud de cola media y el valor de referencia de 25. Esto valida nuestro análisis que
para grandes retrasos, no podemos tener un sistema de respuesta rápida (grandes Ki),
de lo contrario el sistema rápidamente se vuelve inestable.
5. Resumen y trabajos futuros:
La dependencia a los servicios TI ha creado un gran interés en las técnicas
automatizadas para alcanzar los objetivos de nivel de servicio para sistemas objetivos
(por ejemplo, servidores web, servidores de correo electrónico). Con el fin de diseñar
sistemas que respondan dinámicamente basados en retroalimentación de su estado
actual, un enfoque de uso común es la de crear un controlador que manipule los
parámetros de ajuste del sistema objetivo para lograr estos objetivos. Sin embargo, un
Delay: Retraso
QL: Longitud de la cola
Reference:Referencia
MaxUsers:Máxima Cantidad de Usuarios
Time: Tiempo

análisis riguroso del comportamiento de un sistema de lazo cerrado es a menudo
insuficiente. Si no se tiene cuidado en el diseño del controlador, entonces las
oscilaciones inducidas por controlador pueden surgir y eso puede degradar la calidad
del servicio prestado.
En este artículo, hemos demostrado una metodología para la construcción y análisis
de los sistemas de lazo cerrado. Nuestro punto de partida es la teoría del control
clásica, un enfoque ampliamente utilizado en otras disciplinas de ingeniería. Mientras
que otros han utilizado la teoría de control para analizar los sistemas informáticos y de
comunicaciones, su trabajo no ha proporcionado un enfoque general para el modelado
de sistemas de control ni tiene incluido una validación empírica. Le proponemos un
enfoque estadístico de identificación de sistemas que es de aplicación más general
que el enfoque de principios básicos convencional, y también tiene el potencial de
adaptarse a los cambios en el sistema subyacente (como nuevas versiones de
software).
Hemos aplicado esta metodología para el control de lazo cerrado de un servidor de
Lotus Notes, donde un controlador manipula los parámetros de ajuste de
SERVER_MAXUSERS de Notes. Para la identificación del sistema, utilizamos la
regresión de mínimos cuadrados para estimar los parámetros de los modelos ARMA
para los componentes del sistema. El ajuste de estos modelos es bastante bueno: R²
no sea inferior al 75%, y tan alto como 98%. Curiosamente, encontramos que es
importante para modelar el hecho de que las longitudes de cola son tomados como
muestra en el servidor ya que esto puede introducir retrasos que afectan al
rendimiento del controlador.
Ilustramos el valor de un análisis de control teórico mediante la aplicación a un
controlador integral para el servidor Notes, una técnica popular en la teoría de
control. Para garantizar la exactitud del software, sin embargo, nos vemos obligados a
limitar el rango de u(t). Esto hace que el controlador de vuelva a ser no lineal.
Con un control integral, el problema de diseño consiste en determinar un valor
adecuado para el gain (ganancia) Ki. De la teoría de control, sabemos que tener un
gran gain (ganancia) hace que el sistema se más sensible. Sin embargo, un gain
(ganancia) demasiado grande puede causar inestabilidad. El estudio de esta la teoría
de control clásica requiere que nos limitemos a las regiones lineales de operación del
controlador. Por lo tanto, usamos un análisis de estado simple para estimar los valores
de gain (ganancia) para que la linealidad se mantenga.
Nuestro análisis basado en la teoría de control permite comprender mejor esta
solución sobre el valor de gain (ganancia). El análisis de lugar de raíces, que se utiliza
comúnmente en la teoría del control clásica, nos permite predecir en qué valores de Ki
causa oscilaciones inducidas por el controlador. Nuestros estudios empíricos utilizando
un sistema Notes real confirma estas predicciones. Es decir, en todos los casos donde
el análisis del lugar de raíces predice una oscilación inducida por controlador está
presente, esto sucede en nuestros estudios empíricos. Y en todos los casos en lugar
de las raíces predice que no debería haber ninguna oscilación, estas oscilaciones
están ausentes en nuestros resultados empíricos. Por lo tanto, podemos elegir un
valor para Ki que permite al sistema ser más sensible y sin embargo no estar sujeto a

una oscilación inducida por controlador. Además, el análisis aclara el efecto de los
retrasos inducidos por el sensor.
Tenga en cuenta que tanto la identificación de sistemas y el diseño del controlador se
llevan a cabo fuera de línea, basado en datos que han sido recogidos de ejecuciones
producidas o controladas del sistema objetivo. Esto nos permite utilizar una gran
cantidad de datos, realizar más análisis consumidoras de tiempo e incluso consultar a
los expertos de dominio. Suponemos que el sistema evoluciona lentamente, en todo
caso, por lo que el modelo no tiene por qué ser estimado con frecuencia. Un esquema
de detección Changepoint en línea puede ser empleado para monitorear activamente
el sistema y activar el parámetro de reestimación cuando se requiera. Adaptación en
línea del objetivo que se encuentra dentro de los límites del modelo estimado se lleva
a cabo por el controlador.
Aún hay mucho trabajo. Nuestro enfoque para la identificación de regiones lineales de
operación es muy aproximado. Un mejor enfoque sería utilizar la descripción de
funciones, una técnica utilizada en la teoría de control no lineal. En este artículo nos
hemos limitado a una ley de control simple con el fin de demostrar el valor de este
enfoque. Tenemos la intención de estudiar controladores más complejos para evaluar
si la teoría de control proporciona información útil en cuanto a su operación. En
términos más generales, estamos interesados en la aplicación de nuestra metodología
a otras situaciones de administración de nivel de servicio para perfeccionar nuestra
metodología y de evaluar su valor.
6. Trabajo Relacionado
La aplicación de la teoría de control para el análisis de sistemas software ha sido
prevalente sobre todo en el campo de redes. La atención se centra generalmente en la
congestión y los algoritmos de control de flujo para los protocolos sin reservas. Un
análisis de alto nivel se hace por Chiu et al. para obtener una convergencia óptima y
políticas de equidad para evitar la congestión. Keshav proporciona un análisis más
detallado para realizar el control de flujo en una red con un conjunto muy específico de
suposiciones acerca de la infraestructura de redes y protocolos. Ellos usan la
transformada z y el análisis de lugar de raíces, y se encaran también con una no
linealidad en su sistema introducido por términos Max y Min. Mientras que el análisis
no lineal no se lleve a cabo, sugieren utilizar el segundo método de Liapunov. El
trabajo de Benmohamed et al. para redes de conmutación de paquetes, y prorrogado
por Mascolo et al. para ATM también siguen el enfoque de principios básicos. Ambos
artículos tienen un modelo de sistema muy detallado y hacen algunos análisis
sofisticados. Sin embargo, no está claro cómo sus ideas se generalizan a otros
sistemas. Un trabajo más reciente incluye Mascolo et al. y Shor et al., los cuales
aplican ideas teóricas de control para analizar el comportamiento de control de
congestión en TCP.
Los investigadores han aplicado la teoría del control a los sistemas orientados a la
calidad de servicio, como planificadores para Sistemas Operativos, sistemas
distribuidos multimedia y caché Qos-aware. En particular, Lu et al. también un
controlador de investigar su comportamiento está controlado por un parámetro, y
muestran efectos similares de inestabilidad cuando gain (ganancia) del controlador es

muy alta. Su metodología de diseño del controlador funciona al revés del objetivo de
control, pero no presentan un análisis analítico del comportamiento de su
controlador. Como nota de motivación, Goel et al. han reconocido la necesidad de
construir herramientas y algoritmos generales para hacer frente a los sistemas
basados en retroalimentación. Nos proveen de un conjunto de herramientas de
software llamado SWiFT para la construcción y reconfiguración dinámica de esos
sistemas.
En un enfoque algo diferente al modelado de sistemas, algunos investigadores (por
ejemplo, Bigus) usan redes neuronales para el modelado de sistemas. Si bien este
enfoque también nos permite tratar el sistema de destino como una caja negra, los
modelos resultantes no son tan transparentes como los modelos ARMA. Si bien las
NNs son no lineales y pueden modelar sistemas más complejos, no somos capaces de
aprovechar alguna de las herramientas de análisis de la teoría de control para el
diseño o el análisis de los controladores.
- et al. significa “y otros autores”

Usando la Teoría de Control

Más contenido relacionado

Similar a Usando la Teoría de Control

Más de Daniel Carpio Contreras

Último

Usando la Teoría de Control