MANEJO DE LOS PROCESOS DENTRO DE EL
SISTEMA DISTRIBUIDO AMOEBA.
Erwing Paúl Solórzano Larrea
Universidad Politécnica Salesiana, Guayaquil
erwing1394@gmail.com
Abstract--- Los sistemas distribuidos
consisten en una gran colección de
computadoras separadas físicamente y
conectadas entre sí por una red de
comunicaciones, cada máquina posee sus
componentes de hardware y software pero
que aparecen ante el mundo como una sola,
la pregunta que nos hacemos es: ¿Puede ser
posible para un procesador dentro de un
sistema distribuido escribir una palabra en
la memoria de otro procesador en un
tiempo relativamente corto, que resulte
imprescindible al elegir implementar este
tipo de sistemas? En este documento
analizaremos la manera en que los sistemas
distribuidos manejan sus procesos,
presentando ejemplos y soluciones, para
mostrar el funcionamiento de un sistema
existente, tomaremos como referencia al
sistema AMOEBA.
I.- Introducción
Cuando utilizamos un sistema distribuido,
normalmente una estación de trabajo es
utilizada por una solo persona, pero cuando
nadie las está usando, están disponibles como
recursos de cómputo para otras estaciones de
trabajo. Junto con procesadores dedicados
específicamente a la ejecución de programas
de usuario, las estaciones de trabajo inactivas
forman un grupo de procesadores. En los
servidores compartidos se les proporcionan a
las máquinas un sistema de archivos
distribuido, servicio de nombres, puertas de
enlace a Internet, acceso a impresoras, etc.
El problema clave que distingue estos sistemas
es el grano de la computación, que puede ser
aproximadamente expresado como el tiempo
de cálculo, dividido por el tiempo de
comunicación. Si es que esta cantidad se
encuentra por debajo de 10, podemos decir que
tenemos un sistema estrechamente acoplado.
Si está entre 10 y 100 tenemos un sistema
vago acoplado, si está por encima de 100, el
sistema apenas está acoplado.
Ya en la vida real el que determina el tiempo
que se requiere para poder establecer una
comunicación, es el hardware de
comunicación junto con el sistema operativo.
Dentro de un sistema conformado por un gran
número de CPUs en un solo plano y además
con memoria compartida, hay mucha
posibilidad en que un procesador pueda
escribir un dato en la memoria de otro en tan
solo microsegundos. Si analizamos
procesadores que realicen la comunicación por
medio de una red de área local usando
mensajes veremos que necesitan de
milisegundos para enviar un mensaje y tener
una respuesta. Ahora, si usamos redes de área
amplia, tener tiempos de comunicación de
cientos de milisegundos e incluso más, sería
algo común.
Estos parámetros de hardware dan lugar a dos
tipos de sistemas distribuidos, cada uno con
sus propias características. Estos sistemas
difieren en términos de cómo los usuarios ven
el sistema, cuánta autonomía tienen los
procesadores individuales, cómo se reparten
los problemas entre los procesadores, cómo
migra el trabajo entre los procesadores, cómo
se equilibra la carga, cómo la comunicación
entre procesos se realiza, ya sea que el sistema
sea homogéneo o heterogéneo, y finalmente
qué tan confiable es el sistema total y cuáles
son los modos de falla.
Por un lado tenemos a los sistemas débilmente
acoplados, donde la compartición de los
recursos necesaria para proveer un servicio
integral de cómputo, está dada por algunas de
las computadoras de la red y estas son
accesadas por medio del software del sistema
que corre en todas estas máquinas, usando la
red para coordinar su trabajo y para trasmitir
los datos entre ellas.
1
En otras palabras, para el usuario, todo el
sistema parece un tradicional sistema de
tiempo compartido multiusuario, en lugar de
una red de máquinas independientes
Por el otro lado tenemos los sistemas
fuertemente acoplados, estos integran a varios
procesadores dentro de un sistema de hardware
integrado bajo el control de un solo sistema
operativo. El sistema operativo asigna los
procesadores y los espacios de memoria a las
tareas de los usuarios y les permite que estas
corran concurrentemente.
El hardware de entorno incluye memoria
compartida o una conexión de alta velocidad
entre los distintos procesadores y unidades de
memorias del sistema con un solo sistema
unificado de direccionamiento.
Muchas veces los diseñadores del sistema
buscan la transparencia mediante el uso de
múltiples procesadores con miles de CPU,
pero si no se programa el paralelismo
explícitamente, será difícil mantener ocupados
a todos los procesadores.
Para ayudar a la comprensión definiremos al
paralelismo como ejecutar más instrucciones
en menos tiempo, aunque las instrucciones
sigan tardando lo mismo en ejecutarse.
El paralelismo en software es considerado
como el caso ideal de la ejecución de las
instrucciones que forman parte de un
programa, ya que no toma en cuenta las
limitantes del hardware con que el mismo va
ser ejecutado.
Paralelismo en hardware es la ejecución de un
programa tomando en consideración el
hardware con que va a ser ejecutado.
En estos sistemas en muy común preguntarse
si el paralelismo que se ha proporcionado es
explícito o implícito. Esta cuestión tiene
implicaciones que son importantes para los
aspectos en torno a la confiabilidad del
sistema. Ya que si el sistema detecta al usuario
como un solo procesador virtual, ya no habría
mucho por hacer con respecto a la
confiabilidad a nivel del usuario. Ésta tiene
que ser manejada por el sistema.
En otra manera, si los usuarios pudieran
controlar el paralelismo explícitamente, es
posible que la redundancia se utilice para
aumentar la confiabilidad.
Para citar un ejemplo: Ciertos sistemas de
archivos distribuidos nos ofrecen micro
transacciones. Empieza con el usuario
iniciando la transacción, especifica que esta
pueda leer y escribir archivos para que por
último se confirme la transacción. El sistema
luego ejecuta la transacción completa hasta su
finalización o falla, dejando todos los archivos
en su estado original. Ese sistema de archivos
está diseñado para poder utilizar múltiples
procesadores y discos internamente, pero con
respecto a la confiabilidad, no hay algo que el
usuario pueda hacer. En un ejemplo diferente
tomemos como referencia un sistema con un
rack de procesadores, los cuales se pueden
asignar dinámicamente a procesos solicitados.
Un proceso puede solicitar procesadores,
configurarlos para que trabajen en el mismo
problema y luego aceptar la mayoría de
respuestas cuando todos hayan regresado.
Aquí podemos decir que el paralelismo es
explícito. La conclusión que podemos sacar de
estos ejemplos es que los sistemas con un
paralelismo explícito suelen ser más flexibles,
la desventaja es que así mismo ameritan más
trabajo por parte del usuario.
2.- SISTEMA OPERATIVO DISTRIBUIDO
AMOEBA
Este es un sistema distribuido que se puede
ejecutar en diferentes tipos y marcas de
computadora. La intención es que se deba
ejecutar en una red con al menos cinco
computadoras. A pesar de lo que es hoy
técnicamente posible ejecutar la ameba con
sólo un procesador, no es una forma
satisfactoria para el uso del sistema. De un
sistema autónomo (con máquinas secundarias
de tal vez más) la máquina principal tiene que
estar equipado con al menos 64 MB de RAM
(128 MB recomendado) y 500 MB de espacio
en disco. Es, después de todo, un sistema
operativo distribuido.
Para obtener buenos resultados desde el
sistema que debe tener un equipo distinto del
servidor de archivos, una estación de trabajo
por usuario (para ejecutar la interfaz de
usuario) y un grupo de procesadores de la
piscina para realizar el trabajo real y ejecutar
varios servidores.
2
El sistema Amoeba argumenta que el cliente
procesa la comunicación con los servicios a
través de transacciones/mensajes y usa
capacidades para lograr acceder a los servicios
así como a los objetos que estos servicios
implementan.
2.1 MANEJO DE LOS PROCESOS EN
AMOEBA.
Las capacidades que anteriormente hemos
mencionado, se utilizan como protección, así
como una forma principal de atender
solicitudes y realizar operaciones en objetos.
Si el cliente envía una solicitud, el sistema
usará el puerto para determinar qué servicio
manejará la solicitud, luego se procede a
buscar un servidor para ese servicio a través de
una operación de localización. El servidor
utilizará la parte privada de la capacidad para
que el objeto sea identificado, una vez
realizada la solicitud, el servidor devolverá
una respuesta, Los servicios en su mayoría son
ejecutados en el espacio del usuario. El kernel
de Amoeba solo brinda el mínimo servicio, por
ejemplo: facilidades de transacción de
mensajes, gestión de procesos y vías de acceso
a periféricos. Por ejemplo el servicio de
archivos, es un servicio de espacio de usuario
sin privilegios especiales, excepto el del
conocimiento de las capacidades para llegar a
los discos en donde se almacenan los archivos.
Las transacciones de mensajes están
realizando bloqueo y el sistema no
proporciona almacenamiento en búffer.
Cuando un servidor llama una get-request
(puerto, capacidad, buffer de solicitud), (el
puerto identifica el servidor al sistema), el
servidor está bloqueado hasta que llegue una
solicitud. El servidor devuelve una respuesta
con put-reply (replybuffer), que no bloquea.
Cuando el cliente llama una transacción
(capacidad, requestbuffer, replybuffer),
bloquea hasta que la respuesta del servidor es
recibida.
En caso de falla, se le dice al cliente que no se
pudo llegar al servidor, o que no se recibió
respuesta.
En el primer caso, el cliente puede volver a
intentarlo de forma segura; En este último
caso, el cliente tendrá que averiguar si la falla
ocurrió antes, durante o después de la
ejecución de la solicitud (a menos que la
solicitud fuera impotente; en este caso, la
solicitud siempre se puede repetir de forma
segura). Cuando un cliente falla durante una
transacción, la respuesta se pierde.
Una solicitud de kernel es solo una solicitud de
una operación en un objeto mantenido por el
grano, una solicitud de kernel, o una llamada
al sistema, es una transacción con el Servicio
de Kernel.
Por lo tanto, en principio, Amoeba podría
tener solo las llamadas del sistema para hacer
transacciones de mensajes. En la práctica, sin
embargo, es más eficiente implementar
algunas de las solicitudes de servicio de kernel
muy frecuentes como llamadas ordinarias del
sistema.
Las transacciones de Amoeba al estar
bloqueadas, no nos permite usarlas para poder
crear paralelismo. Amoeba usa procesos
paralelos para lograrlo. Mejor dicho procesos
paralelos ligeros, llamados tareas. Para
mejorar la eficiencia, un espacio de
direcciones puede ser compartido por varias
tareas. Esto se considera como un clúster.
Las tareas son fáciles de crear, programar y
destruir, con el fin de que los programadores
usen tareas para pequeñas unidades de trabajo.
3. EL SERVIDOR DE KERNEL
El objetivo del kernel de Amoeba es buscar la
abstracción mediante los clústers, segmentos y
tareas. Al clúster lo podemos definir como un
espacio de direcciones virtuales, el cual consta
de un número de segmentos y muchos hilos de
control, conocidas también como tareas. En
son de la eficiencia las tareas comparten un
espacio de direcciones, pueden intercambiar
información entre sí de manera en la memoria
compartida, y dado que tienen poco contexto,
el cambio de tareas se logra hacer más rápido.
El concepto de tareas se utiliza en varios
sistemas distribuidos por módem, en
particular, V [1], Mesa [4] y Topaz. *
3.1. SEGMENTOS
Es un objeto gestionado por un servicio de
Kernel, se crean utilizando una llamada
seg_map para asignarles un espacio de
dirección de clúster. Los segmentos no se
pueden compartir entre clústeres. En la figura
1.1. hemos representado las llamadas de
3
gestión de segmentos, para una mejor
comprensión. El Servicio de Kernel también puede gestionar
clústeres, los cuales mediante una solicitud
LLAMADAS DE SISTEMA CreateCluster hacia el servidor del kernel,
pueden ser creados. El parámetro de la
sid -= seg_map(segment, address, length, how)
seg_unmap(sid) solicitud es un clúster-descriptor el cual
seg__grow(sid, newlength) describe el estado inicial del clúster
seg_info() describiendo el estado de sus tareas, el espacio
de direcciones en el que se ejecutarán estas
tareas y el procesador en el que el clúster debe
TRANSACCIONES
ejecutar. En la figura 1.2 hemos ilustrado un
Seg Create(kemelcap, incap, outcap) descriptor de clúster para ayudar a la
Seg_Read(capability, offset, buffer, count) comprensión.
Seg_Write(capability, offset, buffer, count)
length = Seg_Length(capability)
Seg_Delete(capability) Descriptor de Host

Contabilización y
Programación

FIGURA 1.1. Llamadas de sistemas y transacciones

para gestión de segmentos Administrador de
excepciones
La diferencia fundamental entre las llamadas Numero de segmentos
al sistema y las transacciones es que las
llamadas al sistema son manejadas por el Descriptores de mapeo
kernel local y, por lo tanto, solo pueden usarse .
para manipular objetos locales, Sin embargo, .
.
las transacciones están dirigidas a un servicio
que puede ser tanto local como remoto. Para
esto, la transacción Seg_Read se utilizará para
leer el contenido de segmentos remotos. Número de tareas
La llamada seg_map primero crea un nuevo
segmento, luego lo inicializa al contenido del Descripción de tareas
segmento señalado por la capacidad segment, El .
parámetro how especifica las opciones de .
.
asignación, como la asignación de solo lectura,
que al final puede ser afectado por llamadas FIGURA 1.2. Descriptor de
como seg_grow. La llamada devuelve un entero clúster
llamado identificador de segmento que
representa el segmento mapeado. Este entero
se usa en llamadas a seg_unmap y seg_grow.

Un segmento al no estar mapeado, se eliminará

del espacio de direcciones de un clúster, pero
continúa existiendo como un objeto dentro de
la memoria. Seg_unmap devuelve la capacidad
(capability) de este objeto para una mejor
relación con las transacciones de
administración del segmento, Seg_info nos
devuelve información acerca del mapa de
memoria actual del clúster que realizó la
llamada.

3.2. CLUSTERS

4
4. MANEJO DE LOS PROCESOS
El intérprete de comandos es aquel que puede
crear y administrar un proceso, pero así mismo
otro proceso puede crear uno nuevo, lo único
que se requiere es la capacidad que permite
realizar la comunicación con un kernel de
Amoeba. La mayoría de los usuarios tendrán
acceso a la capacidad de creación de clúster
para el Kernel de Amoeba ejecutándose por su
cuenta en su puesto de trabajo; es decir, si un
usuario quiere, puede crear nuevos procesos
desde su estación de trabajo.
Las capacidades para crear procesos en los
procesadores de grupo se mantendrán
típicamente por un servicio de "Grupo de
procesadores" el cual será un agente para
ejecutar programas en nombre de los procesos
del usuario.
El equilibrio de carga es posible de alcanzar
mediante el servicio del grupo de
procesadores, si es que este asigna
procesadores de grupo juiciosamente.
4.1. MIGRACIÓN DE LOS PROCESOS
Aunque los clústeres rara vez se trasladan a un
nuevo host después de iniciarse, la migración
es un concepto central en los mecanismos de
gestión del proceso en Amoeba. Cargar nuevos
clústeres en la memoria, hacer puntos de
control, realizar volcados de núcleos, y la
depuración remota son situaciones similares a
realizar la migración de un clúster. Si podemos
migrar un clúster de una máquina a otra,
entonces la descarga, los puntos de control, la
depuración, etc., deberían ser algo sencillo..
El equilibrio de carga mediante la migración
del clúster es un área poco conocida y es
dudoso si es muy útil con el tipo actual de
estaciones de trabajo y redes.
Migrar un clúster de cinco megabytes, por
ejemplo, tomará al menos siete segundos,
porque ese es el tiempo que tarda un protocolo
de transporte rápido para copiar el contenido
de memoria a través de un Ethernet de 10
Mbit; Programas de 5 megabytes están muy
poco frecuentes, especialmente como
candidatos para la migración: Los clúster de
larga vida son generalmente grandes también.
Lo que hace que la migración termine siendo
muy cara, pero la ganancia de una operación
de migración debe ser grande para que tenga
sentido realizarla.
Pero muy aparte de esto, estoy seguro de que
la migración puede llegar a ser útil. Cuando en
una estación de trabajo el propietario se
desconecta por la noche, la estación de trabajo
puede convertirse en un procesador de grupo y
proporcionar servicio de ejecución de procesos
al resto del sistema. Pero, cuando el usuario
propietario vuelve a iniciar sesión por la
mañana, los clúster de invitados que se estén
ejecutando, serán migrados a una estación de
trabajo diferente.
Los kernel implementan el mecanismo de
migración del clúster. No implementan una
política; se toma la decisión de migrar un
clúster y dónde migrarlo en un mayor nivel de
servicio. No analizaremos cómo se toma esta
decisión. El proceso que ordena la migración
se llamará Process Server.
Cuando un clúster se mueve de una máquina a
otra, el kernel de la antigua máquina pone a
disposición el contenido de la memoria y el
descriptor del clúster al kernel de la nueva
máquina. El núcleo de la nueva máquina carga
el clúster en la memoria y lo inicia.
Llamaremos a estos núcleos Viejo anfitrión y
Nuevo anfitrión.
Analizaremos la migración de un clúster desde
el punto donde el Servidor de Procesos (SP)
haya decidido migrar el clúster hacia el nuevo
anfitrión. El SP tiene que establecer diversos
parámetros para manejar las señales del clúster
como depurador del clúster.
Todo comienza cuando, el SP le envía una
señal al clúster que hace que el viejo anfitrión
lo congele en sus pistas y envíe un descriptor
de clúster al SP (Process Server actúa como el
depurador para este clúster), después de esto el
SP envía el clúster descriptor al Nuevo
anfitrión en una solicitud de tipo RunCluster.
El Nuevo anfitrión, cuando recibe la solicitud
RunCluster crea los segmentos que sean
necesarios, los inicializa enviando solicitudes
Seg_Read al Viejo anfitrión y los asigna en el
espacio de direcciones del nuevo clúster,
Ahora que tenemos al cliente (Nuevo
anfitrión) y al servidor (Viejo anfitrión)
podremos enviar y recibir desde la memoria
asignada.
5
Los contenidos de la memoria de un clúster se
pueden copiar a través de Ethernet. Cuando
termina la copia del contenido del segmento, el
nuevo anfitrión iniciará el clúster y enviará
una respuesta al SP que alberga la capacidad
del nuevo clúster. SP luego elimina el clúster
anterior con una solicitud tipo DeleteCluster
hecha al viejo anfitrión.
Dejemos en claro que cuando la migración
estaba en progreso, el clúster aún existía en su
host anterior en estado 'congelado', el kernel
respondió con una alerta a todos los mensajes
que llegaban al clúster congelado: "Intenta más
tarde, este clúster está congelado". Después de
haber eliminado este clúster, esos mensajes
pueden llegar a aparecer en cierto momento,
aunque el kernel ahora va a responder con algo
tipo: 'Este puerto es desconocido en esta
dirección". El remitente luego tendrá que
proceder a realizar una operación de tipo
localización para poder encontrar el nuevo
paradero del clúster y así reestablecer la
comunicación.
El protocolo para tratar las transacciones de
mensajes durante la migración es más
perspicaz en comparación a lo descrito aquí,
pero tomaría demasiado espacio para
describirlo a la perfección. En pos de la
eficiencia en torno a las transacciones de
mensajes de Amoeba, el cliente y el servidor
necesitan usar puertos de comunicación únicos
para que la localización no proporcione una
dirección del servidor incorrecta, por ejemplo.
5. CONCLUSIONES
En este artículo hemos ido construyendo un
conjunto coherente de primitivas para gestión
de procesos que incluye la manera en que se
manejan los procesos, la migración de
clústeres y puntos de control, todo esto implica
de mucho cuidado, no solo de los mecanismos
que se ocupan directamente de la gestión de
procesos, sino también con todo el entorno
circundante. En esta sección, se intentará
nombrar algunas de las consideraciones de
diseño del sistema que facilitaron la
investigación.
El kernel de Amoeba proporciona un mínimo
de funciones: gestión de procesos y
comunicación entre procesos. Por lo tanto,
también hay una cantidad mínima de estados
que tiene que migrar cuando se migra un
clúster. La sencillez en los mecanismos de
comunicación entre procesos de Amoeba
también ha sido vital para el éxito de nuestra
investigación. Primero, las entidades
comunicantes se nombran usando un
mecanismo de nomenclatura independiente de
la ubicación que utiliza un servicio de
localización subyacente para que descubra
dinámicamente dónde deben enviarse los
paquetes. Ninguno de los aparatos de
migración tienen que preocuparse por re-
enrutar mensajes, si no hay direcciones de
reenvío deben de ser dejadas atrás; Los
antiguos anfitriones pueden olvidarse de la
existencia de un clúster inmediatamente
después de completar la migración.
Amoeba con sus protocolos simples,
contribuye enormemente a la portabilidad de
clústers. Ya que posee pocos estados en los
que se puede estar por arbitrarios períodos de
tiempo además de que es fácil poder migrar un
clúster en estos estados, usando los mensajes
tipo: "Estoy congelado, no me molestes"
descritos anteriormente. Si el protocolo se
encuentra en cualquiera de los otros estados, el
kernel de Amoeba puede esperar hasta que el
protocolo alcance un estado tipo ‘migrable'.
La conclusión más importante a la que hemos
llegado es que de hecho si es posible construir
un mecanismo que termine siendo simple y a
su vez que sea suficiente para lograr realizar
tareas como: descargas, migraciones, manejo
de excepciones, checkpointing, y depuración.
REFERENCIAS
1. - Process Management in a Distributed
Operating System, (1988) Sape J. Mullender
Centre for Mathematics & Computer Science.
2. - Diseño de un Software de Intermediación
de Comunicación para Sistemas Distribuidos
de Tiempo Real Críticos en Java, Revista
Iberoamericana de Automática e Informática
industrial 10 (2013).
3. - José M. García Carrasco, Fco. José Quiles
Flor, Departamento de Informática
Escuela Universitaria Politécnica de Albacete.
4. - D. R. Cheriton and W. Zwaenepoel,
(October 1983). The Distributed V Kernel and
its Performance for Diskless Workstations,
6
Proc. Ninth ACM Symp. on Operating
Systems Principles, 128–140.