Según el conocido experto en el campo de la informática E. Tanenbaum, no existe una definición generalmente aceptada y al mismo tiempo estricta de un sistema distribuido. Algunos ingenios argumentan que distribuido es tan sistema informático, en el que un mal funcionamiento de una computadora, cuya existencia los usuarios ni siquiera sospechaban antes, lleva a la terminación de todo su trabajo. Una parte significativa de los sistemas de computación distribuida, desafortunadamente, satisface esta definición, pero formalmente se refiere solo a sistemas con un punto único de vulnerabilidad ( punto único de fallo).

A menudo, al definir un sistema distribuido, la atención se centra en la división de sus funciones entre varias computadoras. Con este enfoque, cualquiera se distribuye sistema informático donde el procesamiento de datos se divide entre dos o más computadoras. Según la definición de E. Tanenbaum, un sistema distribuido de forma algo más estrecha se puede definir como un conjunto de computadoras independientes conectadas por canales de comunicación, que, desde el punto de vista de un usuario de algún software, parecen un todo único.

Este enfoque para definir un sistema distribuido tiene sus inconvenientes. Por ejemplo, todo lo que se utiliza en un sistema distribuido de este tipo. software podría funcionar en una sola computadora, pero desde el punto de vista de la definición anterior, dicho sistema ya no se distribuirá. Por lo tanto, el concepto de sistema distribuido probablemente debería basarse en el análisis del software que forma dicho sistema.

Como base para describir la interacción de dos entidades, considere el modelo general de interacción cliente-servidor, en el que una de las partes (el cliente) inicia el intercambio de datos enviando una solicitud a la otra parte (el servidor). El servidor procesa la solicitud y, si es necesario, envía una respuesta al cliente (Fig. 1.1).

Arroz. 1.1.

La interacción en el marco del modelo cliente-servidor puede ser sincrónica, cuando el cliente está esperando que el servidor procese su solicitud, o asincrónica, en la que el cliente envía una solicitud al servidor y continúa su ejecución sin esperar a que el servidor respuesta. El modelo de cliente y servidor se puede utilizar como base para describir varias interacciones. Para este curso, la interacción de las partes constituyentes del software que forma un sistema distribuido es importante.

Arroz. 1.2.

Considere una cierta aplicación típica, que, de acuerdo con los conceptos modernos, se puede dividir en los siguientes niveles lógicos (Fig. 1.2): interfaz de usuario(PI), lógica de aplicación (LP) y acceso a datos (DD), trabajando con la base de datos (DB). El usuario del sistema interactúa con él a través de la interfaz de usuario, la base de datos almacena datos que describen el dominio de la aplicación y la capa lógica de la aplicación implementa todos los algoritmos relacionados con área temática.

Dado que, en la práctica, diferentes usuarios del sistema suelen estar interesados ​​en acceder a los mismos datos, la separación más simple de las funciones de dicho sistema entre varias computadoras será la separación de las capas lógicas de la aplicación entre una parte del servidor de la aplicación. , que es responsable de acceder a los datos, y las partes del cliente ubicadas en varias computadoras, implementando la interfaz de usuario. La lógica de la aplicación puede asignarse al servidor, a los clientes o compartirse entre ellos (Figura 1.3).

Arroz. 1.3.

La arquitectura de las aplicaciones basadas en este principio se denomina cliente-servidor o de dos niveles. En la práctica, estos sistemas a menudo no se clasifican como distribuidos, pero formalmente pueden considerarse los representantes más simples de los sistemas distribuidos.

El desarrollo de la arquitectura cliente-servidor es una arquitectura de tres niveles, en la que la interfaz de usuario, la lógica de la aplicación y el acceso a los datos se separan en componentes independientes del sistema que pueden ejecutarse en computadoras independientes (Fig. 1.4).

Arroz. 1.4.

La solicitud del usuario en dichos sistemas es procesada secuencialmente por la parte cliente del sistema, el servidor lógico de la aplicación y el servidor de la base de datos. Sin embargo, un sistema distribuido generalmente se entiende como un sistema con una arquitectura más compleja que uno de tres niveles.

En el capítulo anterior, analizamos los sistemas multiprocesador estrechamente acoplados con memoria compartida, estructuras de datos del kernel compartidas y un grupo compartido desde el cual se invocan los procesos. Sin embargo, a menudo es deseable asignar procesadores de tal manera que sean autónomos del entorno operativo y las condiciones operativas para fines de intercambio de recursos. Supongamos, por ejemplo, que un usuario de una computadora personal necesita acceder a archivos ubicados en una máquina más grande, pero al mismo tiempo mantener el control sobre la computadora personal. Si bien algunos programas, como uucp, admiten la transferencia de archivos de red y otras funciones de red, su uso no quedará oculto al usuario, ya que el usuario es consciente de que está utilizando la red. Además, cabe señalar que programas como los editores de texto no funcionan con archivos borrados, como ocurre con los normales. Los usuarios deben tener el conjunto estándar de funciones del sistema UNIX y, aparte del posible cuello de botella en el rendimiento, no deben sentir el cruce de los límites de la máquina. Entonces, por ejemplo, el trabajo de las funciones del sistema para abrir y leer con archivos en máquinas remotas no debería diferir de su trabajo con archivos que pertenecen a sistemas locales.

La arquitectura del sistema distribuido se muestra en la Figura 13.1. Cada computadora que se muestra en la figura es una unidad autónoma que consta de una CPU, memoria y periféricos. El modelo no se rompe a pesar de que la computadora no tiene un sistema de archivos local: debe tener dispositivos periféricos para comunicarse con otras máquinas, y todos los archivos que le pertenecen se pueden ubicar en otra computadora. La memoria física disponible para cada máquina es independiente de los procesos que se ejecutan en otras máquinas. A este respecto, los sistemas distribuidos se diferencian de los sistemas multiprocesador estrechamente acoplados que se analizaron en el capítulo anterior. En consecuencia, el núcleo del sistema en cada máquina funciona independientemente de las condiciones operativas externas del entorno distribuido.

Figura 13.1. Modelo de sistema de arquitectura distribuida

Los sistemas distribuidos, bien descritos en la literatura, se clasifican tradicionalmente en las siguientes categorías:

Sistemas periféricos, que son grupos de máquinas que tienen una fuerte similitud y están asociados con una máquina (generalmente más grande). Los procesadores periféricos comparten su carga con el procesador central y le reenvían todas las llamadas al sistema operativo. El objetivo de un sistema periférico es aumentar el rendimiento general de la red y proporcionar la capacidad de asignar un procesador a un solo proceso en un entorno operativo UNIX. El sistema se inicia como un módulo separado; A diferencia de otros modelos de sistemas distribuidos, los sistemas periféricos no tienen autonomía real, excepto en los casos relacionados con el despacho de procesos y la asignación de memoria local.

Sistemas distribuidos como "Newcastle", que permiten la comunicación remota mediante los nombres de archivos remotos en la biblioteca (el nombre se toma del artículo "The Newcastle Connection" - ver). Los archivos eliminados tienen una lista de materiales (nombre distinguido) que, en la ruta de búsqueda, contiene caracteres especiales o un componente de nombre opcional que precede a la raíz del sistema de archivos. La implementación de este método no implica realizar cambios en el kernel del sistema y, por lo tanto, es más simple que los otros métodos discutidos en este capítulo, pero menos flexible.

Los sistemas distribuidos son completamente transparentes, en los que los nombres distinguidos estándar son suficientes para hacer referencia a archivos ubicados en otras máquinas; Depende del kernel reconocer estos archivos como eliminados. Las rutas de búsqueda de archivos especificadas en sus nombres compuestos cruzan los límites de la máquina en los puntos de montaje, sin importar cuántos de esos puntos se formen cuando los sistemas de archivos se montan en discos.

En este capítulo, veremos la arquitectura de cada modelo; toda la información proporcionada no se basa en los resultados de desarrollos específicos, sino en información publicada en varios artículos técnicos. Esto supone que los módulos de protocolo y los controladores de dispositivos son responsables del direccionamiento, el enrutamiento, el control de flujo y la detección y corrección de errores; en otras palabras, que cada modelo es independiente de la red que se utiliza. Los ejemplos de uso de funciones del sistema que se muestran en la siguiente sección para sistemas periféricos funcionan de manera similar para sistemas como Newcastle y para sistemas completamente transparentes, que se discutirán más adelante; por lo tanto, los consideraremos en detalle una vez, y en las secciones dedicadas a otros tipos de sistemas, nos centraremos principalmente en las características que distinguen estos modelos de todos los demás.

13.1 PROCESADORES PERIFÉRICOS

La arquitectura del sistema periférico se muestra en la Figura 13.2. El objetivo de esta configuración es mejorar el rendimiento general de la red reasignando los procesos en ejecución entre la CPU y los procesadores periféricos. Cada uno de los procesadores periféricos no tiene ningún otro dispositivo periférico local a su disposición además de los que necesita para comunicarse con la unidad central de procesamiento. El sistema de archivos y todos los dispositivos están a disposición del procesador central. Suponga que todos los procesos de usuario se ejecutan en el procesador periférico y no se mueven entre procesadores periféricos; una vez transferidos al procesador, permanecen en él hasta su finalización. El procesador periférico contiene una versión ligera del sistema operativo, diseñado para manejar llamadas locales al sistema, gestión de interrupciones, asignación de memoria, trabajar con protocolos de red y con un controlador de dispositivo para la comunicación con el procesador central.

Cuando el sistema se inicializa en el procesador central, el núcleo carga el sistema operativo local en cada uno de los procesadores periféricos a través de líneas de comunicación. Cualquier proceso que se ejecute en la periferia está asociado con un proceso satélite que pertenece al procesador central (ver); cuando un proceso que se ejecuta en un procesador periférico llama a una función del sistema que requiere los servicios del procesador central únicamente, el proceso periférico se comunica con su satélite y la solicitud se envía al procesador central para su procesamiento. El proceso satélite realiza una función del sistema y envía los resultados al procesador periférico. La relación entre un proceso periférico y su satélite es similar a la relación cliente-servidor que discutimos en detalle en el Capítulo 11: el proceso periférico actúa como un cliente de su satélite, que apoya las funciones de trabajar con el sistema de archivos. En este caso, el proceso del servidor remoto tiene un solo cliente. En la sección 13.4 veremos los procesos del servidor con múltiples clientes.

Figura 13.2. Configuración del sistema periférico

Figura 13.3. Formatos de mensaje

Cuando un proceso periférico llama a una función del sistema que se puede procesar localmente, el kernel no necesita enviar una solicitud al proceso satélite. Entonces, por ejemplo, para obtener memoria adicional, un proceso puede llamar a la función sbrk para ejecución local. Sin embargo, si se requieren los servicios del procesador central, por ejemplo, para abrir un archivo, el kernel codifica la información sobre los parámetros pasados ​​a la función llamada y las condiciones de ejecución del proceso en un mensaje enviado al proceso satélite (Figura 13.3). El mensaje incluye un letrero del cual se deduce que la función del sistema es realizada por el proceso satélite en nombre del cliente, los parámetros pasados ​​a la función y los datos sobre el entorno de ejecución del proceso (por ejemplo, códigos de identificación de usuario y grupo), que son diferente para diferentes funciones. El resto del mensaje son datos de longitud variable (por ejemplo, un nombre de archivo compuesto o datos que se escribirán con la función de escritura).

El proceso satélite espera solicitudes del proceso periférico; cuando se recibe una solicitud, decodifica el mensaje, determina el tipo de función del sistema, la ejecuta y convierte los resultados en una respuesta enviada al proceso periférico. La respuesta, además de los resultados de la ejecución de la función del sistema, incluye el mensaje de error (si lo hay), el número de señal y una matriz de datos de longitud variable que contiene, por ejemplo, información leída de un archivo. El proceso del periférico se suspende hasta que se recibe una respuesta, luego de recibirla, descifra y transmite los resultados al usuario. Este es el esquema general para manejar llamadas al sistema operativo; ahora pasemos a una consideración más detallada de las funciones individuales.

Para explicar cómo funciona el sistema periférico, considere una serie de funciones: getppid, open, write, fork, exit y signal. La función getppid es bastante sencilla ya que trata con formularios simples de solicitud y respuesta que se intercambian entre el periférico y la CPU. El núcleo del procesador periférico genera un mensaje que tiene un signo, del cual se deduce que la función solicitada es la función getppid, y envía la solicitud al procesador central. El proceso satélite en el procesador central lee el mensaje del procesador periférico, descifra el tipo de función del sistema, la ejecuta y obtiene el identificador de su padre. Luego genera una respuesta y la pasa a un proceso periférico pendiente en el otro extremo de la línea de comunicación. Cuando el procesador periférico recibe una respuesta, la pasa al proceso que llamó a la función del sistema getppid. Si el proceso periférico almacena datos (como el ID de proceso del padre) en la memoria local, no tiene que comunicarse con su compañero en absoluto.

Si se llama a la función de sistema abierto, el proceso periférico envía un mensaje a su compañero, que incluye el nombre del archivo y otros parámetros. Si tiene éxito, el proceso complementario asigna un índice y un punto de entrada a la tabla de archivos, asigna una entrada en la tabla de descriptores de archivos de usuario en su espacio y devuelve el descriptor de archivos al proceso periférico. Todo este tiempo, en el otro extremo de la línea de comunicación, el proceso periférico está esperando una respuesta. No tiene ninguna estructura a su disposición que pueda almacenar información sobre el archivo que se está abriendo; El descriptor devuelto por open es un puntero a una entrada en el proceso complementario en la tabla de descriptores de archivos de usuario. Los resultados de ejecutar la función se muestran en la Figura 13.4.

Figura 13.4. Llamar a la función abierta desde un proceso periférico

Si se realiza una llamada a la función de escritura del sistema, el procesador periférico genera un mensaje que consta de un signo de la función de escritura, un descriptor de archivo y la cantidad de datos a escribir. Luego, desde el espacio del proceso periférico, copia los datos al proceso satélite a través de la línea de comunicación. El proceso de satélite descifra el mensaje recibido, lee los datos de la línea de comunicación y los escribe en el archivo correspondiente (el descriptor contenido en el mensaje se usa como un puntero al índice del cual y el registro sobre el cual se usa en la tabla de archivos ); todas estas acciones se realizan en el procesador central. Al final del trabajo, el proceso satélite envía al proceso periférico un mensaje que confirma la recepción del mensaje y contiene la cantidad de bytes de datos que se han copiado correctamente en el archivo. La operación de lectura es similar; el satélite informa al proceso periférico sobre el número de bytes realmente leídos (en el caso de leer datos de un terminal o de un canal, este número no siempre coincide con la cantidad especificada en la solicitud). Para realizar una u otra función, puede ser necesario enviar mensajes de información varias veces a través de la red, lo que está determinado por la cantidad de datos enviados y el tamaño de los paquetes de red.

La única función que debe cambiarse mientras se ejecuta en la CPU es la función del sistema de bifurcación. Cuando un proceso ejecuta esta función en la CPU, el kernel selecciona un procesador periférico para él y envía un mensaje a un proceso especial, el servidor, informando a este último que va a comenzar a descargar el proceso actual. Suponiendo que el servidor ha aceptado la solicitud, el kernel usa un fork para crear un nuevo proceso periférico, asignando una entrada de tabla de proceso y un espacio de direcciones. El procesador central descarga una copia del proceso que llamó a la función de bifurcación al procesador periférico, sobrescribiendo el espacio de direcciones recién asignado, genera un satélite local para comunicarse con el nuevo proceso periférico y envía un mensaje al periférico para inicializar el contador del programa para el nuevo proceso. El proceso satélite (en la CPU) es un descendiente del proceso que se llama bifurcación; un proceso periférico es técnicamente un descendiente del proceso del servidor, pero lógicamente es un descendiente del proceso que llamó a la función de bifurcación. El proceso del servidor no tiene una conexión lógica con el hijo cuando se completa la bifurcación; El único trabajo del servidor es ayudar a descargar al niño. Debido a la fuerte conexión entre los componentes del sistema (los procesadores periféricos no tienen autonomía), el proceso periférico y el proceso satélite tienen el mismo código de identificación. La relación entre procesos se muestra en la Figura 13.5: la línea continua muestra la relación padre-hijo y la línea de puntos muestra la relación entre pares.

Figura 13.5. Ejecutando una función de bifurcación en la CPU

Cuando un proceso ejecuta la función de bifurcación en el procesador periférico, envía un mensaje a su satélite en la CPU, que luego ejecuta la secuencia completa de acciones descritas anteriormente. El satélite selecciona un nuevo procesador periférico y hace los preparativos necesarios para descargar la imagen del proceso antiguo: envía una solicitud al proceso periférico padre para leer su imagen, en respuesta a lo cual la transferencia de los datos solicitados comienza en el otro extremo. del canal de comunicación. El satélite lee la imagen transmitida y la sobrescribe en el descendiente periférico. Cuando finaliza la descarga de la imagen, el proceso satélite se bifurca, crea su hijo en la CPU y pasa el valor del contador del programa al hijo periférico para que este sepa desde qué dirección iniciar la ejecución. Obviamente, sería mejor si el hijo del proceso complementario se asignara al hijo periférico como padre, pero en nuestro caso, los procesos generados pueden ejecutarse en otros procesadores periféricos, no solo en el que se crearon. La relación entre los procesos al final de la función de bifurcación se muestra en la Figura 13.6. Cuando el proceso periférico termina su trabajo, envía un mensaje correspondiente al proceso satélite, y ese también termina. Un proceso complementario no puede iniciar un cierre.

Figura 13.6. Ejecución de una función de bifurcación en un procesador periférico

Tanto en sistemas multiprocesador como monoprocesador, el proceso debe responder a las señales de la misma manera: el proceso completa la ejecución de la función del sistema antes de verificar las señales o, por el contrario, al recibir la señal, inmediatamente sale del estado suspendido y Interrumpe bruscamente el trabajo de funcionamiento del sistema, si este es acorde con la prioridad con la que fue suspendido. Dado que el proceso del satélite realiza funciones del sistema en nombre del proceso periférico, debe responder a las señales en coordinación con este último. Si, en un sistema monoprocesador, una señal hace que un proceso cancele la función, el proceso complementario en un sistema multiprocesador debería comportarse de la misma manera. Lo mismo puede decirse del caso en el que la señal pide al proceso que finalice su trabajo mediante la función de salida: el proceso periférico finaliza y envía el mensaje correspondiente al proceso satélite, que, por supuesto, también finaliza.

Cuando un proceso periférico llama a la función del sistema de señales, almacena la información actual en tablas locales y envía un mensaje a su satélite informándole si la señal especificada debe recibirse o ignorarse. Al proceso del satélite no le importa si intercepta la señal o la acción predeterminada. La reacción de un proceso a una señal depende de tres factores (Figura 13.7): si se recibe una señal mientras el proceso está ejecutando una función del sistema, si se hace una indicación usando la función de señal para ignorar la señal, si la señal ocurre en el mismo procesador periférico o en algún otro. Pasemos a considerar las diversas posibilidades.

algoritmo sighandle / * algoritmo de procesamiento de señales * /

si (el proceso actual es el compañero de alguien o tiene un prototipo)

si (se ignora la señal)

si (la señal vino durante la ejecución de una función del sistema)

poner una señal frente al proceso del satélite;

enviar un mensaje de señal a un proceso periférico;

else (/ * proceso periférico * /

/ * si se recibió una señal durante la ejecución de una función del sistema o no * /

enviar una señal al proceso del satélite;

algoritmo satellite_end_of_syscall / * terminación de una función del sistema llamada por un proceso periférico * /

información de entrada: ausente

pie de imprenta: ninguno

si (se recibió una interrupción durante la ejecución de una función del sistema)

enviar mensaje de interrupción, señal al proceso periférico;

else / * la ejecución de la función del sistema no fue interrumpida * /

enviar respuesta: habilita la bandera que muestra la llegada de la señal;

Figura 13.7. Procesamiento de señales en el sistema periférico

Suponga que un proceso periférico ha suspendido su trabajo mientras el proceso satélite realiza una función del sistema en su nombre. Si la señal se produce en otro lugar, el proceso del satélite la detecta antes que el proceso periférico. Son posibles tres casos.

1. Si, en espera de algún evento, el proceso satélite no entró en el estado de suspensión, del cual saldría al recibir una señal, realiza la función del sistema hasta el final, envía los resultados de la ejecución al proceso periférico y muestra cuál de las señales recibió.

2. Si el proceso ordena ignorar este tipo de señal, el satélite continúa siguiendo el algoritmo de ejecución de la función del sistema sin salir del estado suspendido por longjmp. En la respuesta enviada al proceso periférico, no habrá mensaje de señal recibida.

3. Si al recibir una señal el proceso satélite interrumpe la ejecución de una función del sistema (por longjmp), informa al proceso periférico de ello y le informa del número de la señal.

El proceso periférico busca información sobre la recepción de señales en la respuesta recibida y, si las hay, procesa las señales antes de salir de la función del sistema. Por lo tanto, el comportamiento de un proceso en un sistema multiprocesador corresponde exactamente a su comportamiento en un sistema monoprocesador: o sale sin salir del modo kernel, o llama a una función de procesamiento de señal personalizada, o ignora la señal y completa con éxito la función del sistema.

Figura 13.8. Interrumpir durante la ejecución de una función del sistema

Por ejemplo, suponga que un proceso periférico llama a una función de lectura desde un terminal conectado al procesador central y detiene su trabajo mientras el proceso satélite realiza la función (figura 13.8). Si el usuario presiona la tecla de interrupción, el núcleo de la CPU envía una señal al proceso satélite. Si el satélite estaba en un estado suspendido, esperando una parte de los datos del terminal, inmediatamente sale de este estado y finaliza la función de lectura. En respuesta a una solicitud de un proceso periférico, el satélite proporciona un código de error y un número de señal correspondiente a la interrupción. El proceso periférico analiza la respuesta y, dado que el mensaje dice que ha llegado una interrupción, se envía la señal a sí mismo. Antes de salir de la función de lectura, el núcleo periférico comprueba la señalización, detecta una señal de interrupción del proceso del satélite y la procesa como de costumbre. Si, como resultado de recibir una señal de interrupción, el proceso periférico termina su trabajo usando la función de salida, esta función se encarga de matar el proceso satélite. Si el proceso periférico intercepta las señales de interrupción, llama a la función de manejo de señales definida por el usuario y devuelve un código de error al usuario al salir de la función de lectura. Por otro lado, si el satélite ejecuta la función del sistema de estadísticas en nombre del proceso periférico, no interrumpirá su ejecución cuando reciba una señal (la función de estadísticas está garantizada para salir de cualquier pausa, ya que tiene un tiempo de espera de recursos limitado ). El satélite completa la ejecución de la función y devuelve el número de señal al proceso periférico. El proceso periférico se envía una señal a sí mismo y la recibe a la salida de la función del sistema.

Si se produce una señal en el procesador periférico durante la ejecución de una función del sistema, el proceso periférico no podrá saber si pronto volverá al control del proceso satélite o este último entrará en un estado de suspensión indefinidamente. El proceso periférico envía un mensaje especial al satélite, informándole de la aparición de una señal. El núcleo de la CPU descifra el mensaje y envía una señal al satélite, cuya reacción a la recepción de la señal se describe en los párrafos anteriores (terminación anormal de la ejecución de la función o su finalización). El proceso periférico no puede enviar un mensaje al satélite directamente porque el satélite está ocupado realizando una función del sistema y no está leyendo datos de la línea de comunicación.

Refiriéndose al ejemplo de lectura, debe tenerse en cuenta que el proceso periférico no tiene idea de si su compañero está esperando una entrada del terminal o está realizando otras acciones. El proceso periférico envía un mensaje de señal al satélite: si el satélite está en un estado suspendido con una prioridad interrumpible, inmediatamente sale de este estado y finaliza la función del sistema; de lo contrario, la función se lleva a cabo con éxito.

Por último, considérese el caso de la llegada de una señal en un momento no asociado a la ejecución de una función del sistema. Si una señal se originó en otro procesador, el satélite la recibe primero y envía un mensaje de señal al proceso periférico, ya sea que la señal se refiera al proceso periférico o no. El núcleo periférico descifra el mensaje y envía una señal al proceso, que reacciona ante él de la forma habitual. Si la señal se originó en el procesador periférico, el proceso realiza acciones estándar sin recurrir a los servicios de su satélite.

Cuando un proceso periférico envía una señal a otros procesos periféricos, codifica un mensaje de llamada de interrupción y lo envía al proceso satélite, que ejecuta la función llamada localmente. Si algunos de los procesos para los que está destinada la señal están ubicados en otros procesadores periféricos, sus satélites recibirán la señal (y reaccionarán a ella como se describe anteriormente).

13.2 TIPO DE COMUNICACIÓN NEWCASTLE

En la sección anterior, consideramos un tipo de sistema estrechamente acoplado, que se caracteriza por enviar todas las llamadas a las funciones del subsistema de administración de archivos que surgen en el procesador periférico a un procesador remoto (central). Pasamos ahora a considerar los sistemas con una conexión más débil, que consisten en máquinas que realizan llamadas a archivos ubicados en otras máquinas. En una red de computadoras personales y estaciones de trabajo, por ejemplo, los usuarios a menudo acceden a archivos ubicados en una máquina grande. En las siguientes dos secciones, veremos las configuraciones del sistema en las que todas las funciones del sistema se realizan en subsistemas locales, pero al mismo tiempo es posible acceder a archivos (a través de las funciones del subsistema de administración de archivos) ubicados en otras máquinas.

Estos sistemas utilizan una de las dos rutas siguientes para identificar los archivos eliminados. En algunos sistemas, se agrega un carácter especial al nombre del archivo compuesto: el componente de nombre que precede a este carácter identifica la máquina, el resto del nombre es el archivo en esa máquina. Entonces, por ejemplo, el nombre distinguido

"sftig! / fs1 / mjb / rje"

identifica el archivo "/ fs1 / mjb / rje" en la máquina "sftig". Este esquema de identificación de archivos sigue la convención uucp para transferir archivos entre sistemas similares a UNIX. En otro esquema, los archivos eliminados se identifican agregando un prefijo especial al nombre, por ejemplo:

/../sftig/fs1/mjb/rje

donde "/../" es un prefijo que indica que el archivo se borró; el segundo componente del nombre de archivo es el nombre de la máquina remota. Este esquema utiliza la conocida sintaxis de nombres de archivo de UNIX, por lo que, a diferencia del primer esquema, los programas de usuario no necesitan adaptarse al uso de nombres con una construcción inusual (ver).

Figura 13.9. Formulación de solicitudes al servidor de archivos (procesador)

Dedicaremos el resto de esta sección a un modelo de un sistema que utiliza un enlace de Newcastle, en el que el núcleo no se preocupa por reconocer archivos borrados; esta función está completamente asignada a las subrutinas de la biblioteca C estándar, que en este caso desempeñan el papel de la interfaz del sistema. Estas rutinas analizan el primer componente del nombre del archivo, que en ambos métodos de identificación descritos contiene un signo de la lejanía del archivo. Esta es una desviación de la rutina en la que las rutinas de la biblioteca no analizan los nombres de los archivos. La figura 13.9 muestra cómo se formulan las solicitudes a un servidor de archivos. Si el archivo es local, el kernel del sistema local procesa la solicitud normalmente. Considere el caso opuesto:

open ("/../ sftig / fs1 / mjb / rje / file", O_RDONLY);

La subrutina abierta en la biblioteca C analiza los dos primeros componentes del nombre de archivo distinguido y sabe buscar el archivo en la máquina remota "sftig". Para tener información sobre si el proceso tuvo previamente una conexión con una máquina dada, la subrutina inicia una estructura especial en la que recuerda este hecho, y en caso de una respuesta negativa, establece una conexión con el servidor de archivos que se ejecuta en el remoto. máquina. Cuando el proceso formula su primera solicitud de procesamiento remoto, el servidor remoto confirma la solicitud, si es necesario, registra en los campos los códigos de identificación de usuario y grupo y crea un proceso satélite que actuará en nombre del proceso cliente.

Para cumplir con las solicitudes del cliente, el satélite debe tener los mismos permisos de archivo en la máquina remota que el cliente. En otras palabras, el usuario "mjb" debe tener los mismos derechos de acceso a los archivos locales y remotos. Desafortunadamente, es posible que el código de identificación del cliente "mjb" pueda coincidir con el código de identificación de otro cliente en la máquina remota. Por lo tanto, los administradores del sistema en las máquinas que se ejecutan en la red deben asegurarse de que a cada usuario se le asigne un código de identificación que sea único para toda la red, o realizar la conversión de código al momento de formular una solicitud de servicio de red. Si esto no se hace, el proceso complementario tendrá los derechos de otro cliente en la máquina remota.

Un tema más delicado es la obtención de derechos de superusuario en relación con el trabajo con archivos remotos. Por un lado, el cliente superusuario no debería tener los mismos derechos sobre el sistema remoto para no inducir a error los controles de seguridad del sistema remoto. Por otro lado, algunos de los programas, si no se les otorgan derechos de superusuario, simplemente no podrán funcionar. Un ejemplo de un programa de este tipo es el programa mkdir (consulte el Capítulo 7), que crea un nuevo directorio. El sistema remoto no permitiría que el cliente creara un nuevo directorio porque los derechos de superusuario no están vigentes en el momento de la eliminación. El problema de crear directorios remotos sirve como una razón seria para revisar la función del sistema mkdir en la dirección de expandir sus capacidades para establecer automáticamente todas las conexiones necesarias para el usuario. Sin embargo, sigue siendo un problema común que los programas setuid (como el programa mkdir) obtengan privilegios de superusuario sobre los archivos remotos. Quizás la mejor solución a este problema sería establecer características adicionales para los archivos que describan el acceso a ellos por parte de superusuarios remotos; desafortunadamente, esto requeriría cambios en la estructura del índice del disco (en términos de agregar nuevos campos) y crearía demasiado desorden en los sistemas existentes.

Si la subrutina abierta tiene éxito, la biblioteca local deja una nota correspondiente sobre esto en una estructura accesible para el usuario que contiene la dirección del nodo de red, el ID de proceso del proceso satélite, el descriptor de archivo y otra información similar. Las rutinas de lectura y escritura de la biblioteca determinan, según el descriptor de archivo, si el archivo se elimina y, de ser así, envía un mensaje al satélite. El proceso del cliente interactúa con su compañero en todos los casos de acceso a funciones del sistema que requieren los servicios de una máquina remota. Si un proceso accede a dos archivos ubicados en la misma máquina remota, usa un satélite, pero si los archivos están ubicados en diferentes máquinas, ya se usan dos satélites: uno en cada máquina. También se utilizan dos satélites cuando dos procesos acceden a un archivo en una máquina remota. Al invocar la función del sistema vía satélite, el proceso genera un mensaje que incluye el número de función, el nombre de la ruta de búsqueda y otra información necesaria, similar a la incluida en la estructura del mensaje en el sistema con procesadores periféricos.

El mecanismo para realizar operaciones en el directorio actual es más complejo. Cuando el proceso selecciona un directorio remoto como el actual, la rutina de la biblioteca envía un mensaje al satélite, que cambia el directorio actual, y la rutina recuerda que el directorio es eliminado. En todos los casos en los que el nombre de la ruta de búsqueda comienza con un carácter que no sea una barra inclinada (/), la subrutina envía el nombre a la máquina remota, donde el proceso de satélite lo enruta desde el directorio actual. Si el directorio actual es local, la rutina simplemente pasa el nombre de la ruta de búsqueda al núcleo del sistema local. La función chroot del sistema en un directorio remoto es similar, pero pasa desapercibida para el kernel local; estrictamente hablando, el proceso puede ignorar esta operación, ya que solo la biblioteca registra su ejecución.

Cuando un proceso llama a la bifurcación, la rutina de la biblioteca apropiada envía mensajes a cada satélite. Los procesos de los satélites se ramifican y envían sus identificadores secundarios al cliente principal. El proceso del cliente ejecuta la función del sistema fork, que transfiere el control al niño que genera; el niño local está en diálogo con el niño satélite remoto cuyas direcciones son almacenadas por la rutina de la biblioteca. Esta interpretación de la función de bifurcación facilita que los procesos satélite controlen los archivos abiertos y los directorios actuales. Cuando el proceso que trabaja con archivos remotos sale (llamando a la función de salida), la subrutina envía mensajes a todos sus satélites remotos para que ellos hagan lo mismo cuando reciban el mensaje. En los ejercicios se analizan ciertos aspectos de la implementación de las funciones del sistema ejecutivo y de salida.

La ventaja de un enlace de Newcastle es que el acceso de un proceso a archivos remotos se vuelve transparente (invisible para el usuario), sin la necesidad de realizar cambios en el kernel del sistema. Sin embargo, este desarrollo tiene una serie de desventajas. En primer lugar, durante su implementación, es posible una disminución en el rendimiento del sistema. Debido al uso de la biblioteca C extendida, el tamaño de la memoria utilizada por cada proceso aumenta, incluso si el proceso no tiene acceso a archivos remotos; la biblioteca duplica las funciones del kernel y requiere más espacio de memoria. Aumentar el tamaño de los procesos alarga el período de inicio y puede crear más contención por los recursos de memoria, creando condiciones para una descarga y paginación de tareas más frecuentes. Las solicitudes locales se ejecutarán más lentamente debido al aumento en la duración de cada llamada al kernel, y el procesamiento de solicitudes remotas también se puede ralentizar, el costo de enviarlas a través de la red aumenta. El procesamiento adicional de solicitudes remotas a nivel de usuario aumenta el número de cambios de contexto, descarga e intercambio de operaciones. Finalmente, para acceder a archivos remotos, los programas deben recompilarse utilizando las nuevas bibliotecas; los programas antiguos y los módulos de objetos entregados no podrán trabajar con archivos remotos sin él. Todas estas desventajas están ausentes en el sistema que se describe en la siguiente sección.

13.3 SISTEMAS DE ARCHIVOS DISTRIBUIDOS "TRANSPARENTES"

El término "asignación transparente" significa que los usuarios de una máquina pueden acceder a los archivos de otra máquina sin darse cuenta de que están cruzando los límites de la máquina, tal como lo hacen en su máquina cuando cambian de un sistema de archivos a otro atravesando los puntos de montaje. Los nombres con los que los procesos se refieren a archivos ubicados en máquinas remotas son similares a los nombres de archivos locales: no contienen caracteres distintivos. En la configuración que se muestra en la Figura 13.10, el directorio "/ usr / src" que pertenece a la máquina B está "montado" en el directorio "/ usr / src" que pertenece a la máquina A. el mismo código fuente del sistema, que tradicionalmente se encuentra en el "/ directorio usr / src ". Los usuarios que se ejecutan en la máquina A pueden acceder a los archivos ubicados en la máquina B utilizando la sintaxis familiar para escribir nombres de archivos (por ejemplo: "/usr/src/cmd/login.c"), y el núcleo decide si el archivo es remoto o local. . Los usuarios que se ejecutan en la máquina B tienen acceso a sus archivos locales (sin saber que los usuarios de la máquina A pueden acceder a los mismos archivos), pero, a su vez, no tienen acceso a los archivos ubicados en la máquina A. Por supuesto, otras opciones son posibles, en en particular, aquellos en los que todos los sistemas remotos están montados en la raíz del sistema local, de modo que los usuarios puedan acceder a todos los archivos en todos los sistemas.

Figura 13.10. Sistemas de archivos después del montaje remoto

Las similitudes entre montar sistemas de archivos locales y permitir el acceso a sistemas de archivos remotos han provocado la adaptación de la función de montaje a los sistemas de archivos remotos. En este caso, el kernel tiene una tabla de montaje de formato extendido a su disposición. Al ejecutar la función de montaje, el núcleo organiza una conexión de red con una máquina remota y almacena la información que caracteriza esta conexión en la tabla de montaje.

Un problema interesante tiene que ver con los nombres de ruta que incluyen "..". Si un proceso crea el directorio actual desde un sistema de archivos remoto, entonces el uso de caracteres ".." en el nombre probablemente devolverá el proceso al sistema de archivos local en lugar de acceder a los archivos por encima del directorio actual. Volviendo nuevamente a la Figura 13.10, observe que cuando un proceso perteneciente a la máquina A, habiendo seleccionado previamente el directorio actual "/ usr / src / cmd" ubicado en el sistema de archivos remoto, ejecutará el comando

el directorio actual será el directorio raíz de la máquina A, no la máquina B. El algoritmo namei que se ejecuta en el kernel del sistema remoto, después de recibir la secuencia de caracteres "..", comprueba si el proceso de llamada es un agente del cliente proceso y, si es así, establece si el cliente está tratando el directorio de trabajo actual como la raíz del sistema de archivos remoto.

La comunicación con una máquina remota toma una de dos formas: una llamada a procedimiento remoto o una llamada a función del sistema remoto. En la primera forma, cada procedimiento del kernel que trata con índices comprueba si el índice apunta a un archivo remoto y, de ser así, envía una solicitud a la máquina remota para realizar la operación especificada. Este esquema encaja naturalmente en la estructura abstracta de soporte para sistemas de archivos de varios tipos, descrita en la parte final del Capítulo 5. Por lo tanto, un acceso a un archivo remoto puede iniciar la transferencia de varios mensajes a través de la red, el número de los cuales es determinado por el número de operaciones implícitas en el archivo, con el correspondiente aumento en el tiempo de respuesta a la solicitud, teniendo en cuenta el tiempo de espera aceptado en la red. Cada conjunto de operaciones remotas incluye al menos acciones para bloqueo de índice, recuento de referencias, etc. Para mejorar el modelo, se propusieron varias soluciones de optimización relacionadas con la combinación de varias operaciones en una consulta (mensaje) y el almacenamiento en búfer de los datos más importantes (cm. ).

Figura 13.11. Abrir un archivo remoto

Considere un proceso que abre un archivo remoto "/usr/src/cmd/login.c", donde "src" es el punto de montaje. Al analizar el nombre del archivo (usando el esquema namei-iget), el kernel detecta que el archivo está eliminado y envía una solicitud a la máquina host para obtener el índice bloqueado. Habiendo recibido la respuesta deseada, el kernel local crea una copia del índice en la memoria correspondiente al archivo remoto. Luego, el kernel verifica los derechos de acceso necesarios al archivo (para leer, por ejemplo) enviando otro mensaje a la máquina remota. El algoritmo abierto continúa de acuerdo con el plan descrito en el Capítulo 5, enviando mensajes a la máquina remota según sea necesario, hasta que se completa el algoritmo y se libera el índice. La relación entre las estructuras de datos del kernel al completar el algoritmo abierto se muestra en la Figura 13.11.

Si el cliente llama a la función del sistema de lectura, el kernel del cliente bloquea el índice local, emite un bloqueo en el índice remoto, una solicitud de lectura, copia los datos en la memoria local, emite una solicitud para liberar el índice remoto y libera el índice local . Este esquema es consistente con la semántica del kernel monoprocesador existente, pero la frecuencia de uso de la red (múltiples llamadas a cada función del sistema) reduce el rendimiento de todo el sistema. Sin embargo, para reducir el flujo de mensajes en la red, se pueden combinar varias operaciones en una sola solicitud. En el ejemplo con la función de lectura, el cliente puede enviar al servidor una solicitud de "lectura" general, y el servidor mismo decide tomar y liberar el índice cuando se ejecuta. La reducción del tráfico de red también se puede lograr mediante el uso de búferes remotos (como comentamos anteriormente), pero se debe tener cuidado para garantizar que las funciones del archivo del sistema que utilizan estos búferes se ejecuten correctamente.

En la segunda forma de comunicación con una máquina remota (una llamada a una función del sistema remoto), el kernel local detecta que la función del sistema está relacionada con un archivo remoto y envía los parámetros especificados en su llamada al sistema remoto, que ejecuta la función y devuelve los resultados al cliente. La máquina cliente recibe los resultados de la ejecución de la función y sale del estado de llamada. La mayoría de las funciones del sistema se pueden realizar utilizando solo una solicitud de red y recibiendo una respuesta después de un tiempo razonable, pero no todas las funciones encajan en este modelo. Entonces, por ejemplo, al recibir ciertas señales, el núcleo crea un archivo para el proceso llamado "núcleo" (Capítulo 7). La creación de este archivo no está asociada con una función específica del sistema, pero termina realizando varias operaciones como crear un archivo, verificar permisos y realizar una serie de escrituras.

En el caso de la función de sistema abierto, la solicitud para ejecutar la función enviada a la máquina remota incluye la parte del nombre del archivo que queda después de excluir los componentes del nombre de la ruta de búsqueda que distinguen el archivo remoto, así como varias banderas. En el ejemplo anterior de abrir el archivo "/usr/src/cmd/login.c", el kernel envía el nombre "cmd / login.c" a la máquina remota. El mensaje también incluye credenciales, como códigos de identificación de usuarios y grupos, que son necesarios para verificar los permisos de archivos en una máquina remota. Si se recibe una respuesta de la máquina remota que indica una función abierta exitosa, el kernel local busca un índice libre en la memoria de la máquina local y lo marca como el índice de archivo remoto, almacena información sobre la máquina remota y el índice remoto, y asigna rutinariamente una nueva entrada en la tabla de archivos. Comparado con el índice real en la máquina remota, el índice propiedad de la máquina local es formal y no viola la configuración del modelo, que es básicamente la misma que la configuración utilizada al llamar al procedimiento remoto (Figura 13.11). Si una función llamada por un proceso accede a un archivo remoto por su descriptor, el kernel local sabe por el índice (local) que el archivo es remoto, formula una solicitud que incluye la función llamada y la envía a la máquina remota. La solicitud contiene un puntero al índice remoto mediante el cual el proceso satélite puede identificar el archivo remoto en sí.

Habiendo recibido el resultado de ejecutar cualquier función del sistema, el kernel puede recurrir a los servicios de un programa especial para procesarlo (al finalizar el cual el kernel terminará de trabajar con la función), debido a que el procesamiento local de resultados se usa en un sistema monoprocesador no siempre es adecuado para un sistema con varios procesadores. Como resultado, son posibles cambios en la semántica de los algoritmos del sistema, destinados a proporcionar soporte para la ejecución de funciones remotas del sistema. Sin embargo, al mismo tiempo, circula un flujo mínimo de mensajes en la red, asegurando el tiempo mínimo de respuesta del sistema a las solicitudes entrantes.

13.4 MODELO DISTRIBUIDO SIN PROCESOS DE TRANSFERENCIA

El uso de procesos de transferencia (procesos satélite) en un sistema distribuido transparente facilita el seguimiento de los archivos eliminados, pero la tabla de procesos del sistema remoto está sobrecargada con procesos satélite que están inactivos la mayor parte del tiempo. En otros esquemas, se utilizan procesos de servidor especiales para procesar solicitudes remotas (ver y). El sistema remoto tiene un conjunto (grupo) de procesos de servidor que asigna de vez en cuando para procesar las solicitudes remotas entrantes. Después de procesar la solicitud, el proceso del servidor regresa al grupo y entra en un estado listo para procesar otras solicitudes. El servidor no guarda el contexto del usuario entre dos llamadas, porque puede procesar solicitudes de varios procesos a la vez. Por tanto, cada mensaje que llega de un proceso cliente debe incluir información sobre su entorno de ejecución, a saber: códigos de identificación de usuario, directorio actual, señales, funciones, etc.

Cuando un proceso abre un archivo remoto, el kernel remoto asigna un índice para los enlaces posteriores al archivo. La máquina local mantiene una tabla descriptiva de archivos personalizada, una tabla de archivos y una tabla de índice con un conjunto regular de registros, con una entrada de tabla de índice que identifica la máquina remota y el índice remoto. En los casos en que una función del sistema (por ejemplo, leer) utiliza un descriptor de archivo, el kernel envía un mensaje que apunta al índice remoto asignado previamente y transfiere información relacionada con el proceso: código de identificación del usuario, tamaño máximo de archivo, etc. proceso de servidor a su disposición, la interacción con el cliente toma la forma descrita anteriormente, sin embargo, la conexión entre el cliente y el servidor se establece solo durante la duración de la función del sistema.

El uso de servidores en lugar de procesos por satélite puede dificultar la gestión del tráfico de datos, las señales y los dispositivos remotos. Se deben poner en cola grandes cantidades de solicitudes a una máquina remota en ausencia de un número suficiente de servidores. Esto requiere un protocolo de capa superior al que se usa en la red principal. En el modelo de satélite, por otro lado, se elimina la sobresaturación porque todas las solicitudes de los clientes se procesan sincrónicamente. Un cliente puede tener como máximo una solicitud pendiente.

El procesamiento de señales que interrumpen la ejecución de una función del sistema también es complicado cuando se utilizan servidores, ya que la máquina remota tiene que buscar el servidor apropiado que atienda la ejecución de la función. Incluso es posible que, debido a la ocupación de todos los servidores, una solicitud de una función del sistema esté pendiente de procesamiento. Las condiciones para el surgimiento de la competencia también surgen cuando el servidor devuelve el resultado de la función del sistema al proceso de llamada y la respuesta del servidor incluye el envío de un mensaje de señalización correspondiente a través de la red. Cada mensaje debe estar marcado para que el sistema remoto pueda reconocerlo y, si es necesario, terminar los procesos del servidor. Al utilizar satélites, se identifica automáticamente el proceso que maneja el cumplimiento de la solicitud del cliente, y en caso de que llegue una señal, no es difícil verificar si la solicitud ha sido procesada o no.

Finalmente, si una función del sistema llamada por el cliente hace que el servidor se detenga indefinidamente (por ejemplo, al leer datos de un terminal remoto), el servidor no puede procesar otras solicitudes para liberar el grupo de servidores. Si varios procesos acceden a dispositivos remotos a la vez y si el número de servidores está limitado desde arriba, existe un cuello de botella bastante tangible. Esto no sucede con los satélites, ya que se asigna un satélite a cada proceso de cliente. Otro problema con el uso de servidores para dispositivos remotos se tratará en el ejercicio 13.14.

A pesar de las ventajas que proporciona el uso de procesos satelitales, la necesidad de entradas libres en la tabla de procesos en la práctica se vuelve tan aguda que, en la mayoría de los casos, los servicios de los procesos del servidor todavía se utilizan para procesar solicitudes remotas.

Figura 13.12. Diagrama conceptual de interacción con archivos remotos a nivel de kernel

13.5 CONCLUSIONES

En este capítulo, hemos considerado tres esquemas para trabajar con archivos ubicados en máquinas remotas, tratando los sistemas de archivos remotos como una extensión del local. Las diferencias arquitectónicas entre estos diseños se muestran en la Figura 13.12. Todos ellos, a su vez, se diferencian de los sistemas multiprocesador descritos en el capítulo anterior en que los procesadores aquí no comparten memoria física. Un sistema de procesador periférico consta de un conjunto de procesadores estrechamente acoplados que comparten los recursos de archivo del procesador central. Una conexión del tipo Newcastle proporciona acceso oculto ("transparente") a archivos remotos, pero no por medio del kernel del sistema operativo, sino mediante el uso de una biblioteca C especial. Por este motivo, todos los programas que pretendan utilizar este tipo de enlace deben ser recompilados, lo que, en general, es un serio inconveniente de este esquema. La lejanía de un archivo se indica mediante una secuencia especial de caracteres que describen la máquina en la que se encuentra el archivo, y este es otro factor que limita la portabilidad de los programas.

En sistemas distribuidos transparentes, se utiliza una modificación de la función del sistema de montaje para acceder a archivos remotos. Los índices del sistema local se marcan como archivos remotos y el kernel local envía un mensaje al sistema remoto que describe la función del sistema solicitada, sus parámetros y el índice remoto. La comunicación en un sistema distribuido "transparente" se admite de dos formas: en forma de llamada a un procedimiento remoto (se envía un mensaje a la máquina remota que contiene una lista de operaciones asociadas con el índice) y en forma de llamada a una función del sistema remoto (el mensaje describe la función solicitada). La parte final del capítulo analiza cuestiones relacionadas con el procesamiento de solicitudes remotas utilizando procesos y servidores satelitales.

13.6 EJERCICIOS

*una. Describir la implementación de la función del sistema de salida en un sistema con procesadores periféricos. ¿Cuál es la diferencia entre este caso y cuando el proceso finaliza al recibir una señal no detectada? ¿Cómo debería el kernel volcar el contenido de la memoria?

2. Los procesos no pueden ignorar las señales SIGKILL; Explique qué sucede en el sistema periférico cuando el proceso recibe dicha señal.

* 3. Describir la implementación de la función del sistema ejecutivo en un sistema con procesadores periféricos.

* 4. ¿Cómo debería el procesador central distribuir los procesos entre los procesadores periféricos para equilibrar la carga general?

* 5. ¿Qué sucede si el procesador periférico no tiene suficiente memoria para acomodar todos los procesos que se le descargan? ¿Cómo se debe realizar la descarga e intercambio de procesos en la red?

6. Considere un sistema en el que se envían solicitudes a un servidor de archivos remoto si se encuentra un prefijo especial en el nombre del archivo. Deje que el proceso llame a execl ("/../ sftig / bin / sh", "sh", 0); El ejecutable está en una máquina remota, pero debe estar ejecutándose en el sistema local. Explique cómo se migra el módulo remoto al sistema local.

7. Si el administrador necesita agregar nuevas máquinas a un sistema existente con una conexión como Newcastle, ¿cuál es la mejor manera de informar a los módulos de la biblioteca C sobre esto?

*ocho. Durante la ejecución de la función ejecutiva, el kernel sobrescribe el espacio de direcciones del proceso, incluidas las tablas de la biblioteca utilizadas por el enlace de Newcastle para rastrear enlaces a archivos remotos. Después de ejecutar la función, el proceso debe conservar la capacidad de acceder a estos archivos mediante sus descriptores antiguos. Describe la implementación de este punto.

* 9. Como se muestra en la sección 13.2, llamar a la función de sistema de salida en sistemas con una conexión de Newcastle da como resultado un mensaje que se envía al proceso complementario, lo que obliga a este último a terminar. Esto se hace a nivel de rutinas de biblioteca. ¿Qué sucede cuando un proceso local recibe una señal que le dice que salga en modo kernel?

* 10. En un sistema con un enlace de Newcastle, donde los archivos remotos se identifican prefijando el nombre con un prefijo especial, ¿cómo puede un usuario, especificando ".." (directorio principal) como componente de nombre de archivo, atravesar el punto de montaje remoto?

11. Sabemos por el Capítulo 7 que varias señales hacen que el proceso vuelque el contenido de la memoria en el directorio actual. ¿Qué debería suceder si el directorio actual es del sistema de archivos remoto? ¿Qué respuesta daría si el sistema utiliza una relación como la de Newcastle?

* 12. ¿Qué implicaciones tendría para los procesos locales si se eliminaran del sistema todos los procesos de servidor o satélite?

*trece. Considere cómo implementar el algoritmo de enlace en un sistema distribuido transparente, cuyos parámetros pueden ser dos nombres de archivos remotos, así como el algoritmo exec, asociado con la realización de varias operaciones de lectura internas. Considere dos formas de comunicación: una llamada a procedimiento remoto y una llamada a función del sistema remoto.

* 14. Al acceder al dispositivo, el proceso del servidor puede entrar en el estado suspendido, del cual será eliminado por el controlador del dispositivo. Naturalmente, si el número de servidores es limitado, el sistema ya no podrá satisfacer las solicitudes de la máquina local. Cree un esquema confiable en el que no todos los procesos del servidor se suspendan mientras se espera que se complete la E / S relacionada con el dispositivo. La función del sistema no terminará mientras todos los servidores estén ocupados.

Figura 13.13. Configuración del servidor de terminales

*15. Cuando un usuario inicia sesión en el sistema, la disciplina de línea de terminal almacena la información de que el terminal es un terminal de operador que lidera un grupo de procesos. Por esta razón, cuando el usuario presiona la tecla "interrupción" en el teclado del terminal, todos los procesos del grupo reciben la señal de interrupción. Considere una configuración de sistema en la que todos los terminales están conectados físicamente a una máquina, pero el registro de usuario está lógicamente implementado en otras máquinas (Figura 13.13). En cada caso, el sistema crea un proceso getty para el terminal remoto. Si las solicitudes a un sistema remoto son procesadas por un conjunto de procesos del servidor, tenga en cuenta que cuando se ejecuta el procedimiento de apertura, el servidor deja de esperar una conexión. Cuando se completa la función de apertura, el servidor vuelve al grupo de servidores, cortando su conexión con la terminal. ¿Cómo se dispara una señal de interrupción presionando la tecla "interrupción" enviada a las direcciones de los procesos incluidos en el mismo grupo?

*dieciséis. Compartir memoria es una característica inherente a las máquinas locales. Desde un punto de vista lógico, la asignación de un área común de memoria física (local o remota) se puede realizar para procesos pertenecientes a diferentes máquinas. Describe la implementación de este punto.

* 17. Los algoritmos de paginación del proceso y de paginación que se analizan en el Capítulo 9 suponen el uso de un buscapersonas local. ¿Qué cambios se deben realizar en estos algoritmos para poder admitir dispositivos de descarga remota?

*Dieciocho. Suponga que la máquina (o red) remota experimenta un bloqueo fatal y el protocolo de capa de red local registra este hecho. Desarrolle un esquema de recuperación para un sistema local que realiza solicitudes a un servidor remoto. Además, desarrolle un esquema de recuperación para un sistema de servidor que ha perdido contacto con los clientes.

*diecinueve. Cuando un proceso accede a un archivo remoto, es posible que el proceso atraviese varias máquinas en busca del archivo. Tome el nombre "/ usr / src / uts / 3b2 / os" como ejemplo, donde "/ usr" es el directorio que pertenece a la máquina A, "/ usr / src" es el punto de montaje de la raíz de la máquina B, " / usr / src / uts / 3b2 "es el punto de montaje de la raíz de la máquina C. Caminar a través de varias máquinas hasta su destino final se denomina salto múltiple. Sin embargo, si hay una conexión de red directa entre las máquinas A y C, el envío de datos a través de la máquina B sería ineficaz. Describir las características de la implementación del "multishopping" en un sistema con conexión Newcastle y en un sistema distribuido "transparente".

V grandes explotaciones decenas de miles de usuarios trabajan en filiales. Cada organización tiene sus propios procesos de negocio internos: aprobación de documentos, emisión de instrucciones, etc. Al mismo tiempo, algunos procesos van más allá de los límites de una empresa y afectan a los empleados de otra. Por ejemplo, el jefe de la oficina central emite una orden a la subsidiaria o un empleado de la subsidiaria envía un acuerdo para su aprobación con los abogados de la empresa matriz. Esto requiere una arquitectura compleja que utiliza múltiples sistemas.

Además, dentro de una compania Se utilizan muchos sistemas para resolver diferentes problemas: un sistema ERP para operaciones contables, instalaciones separadas de sistemas ECM para documentación organizativa y administrativa, para estimaciones de diseño, etc.

El sistema DIRECTUM ayudará a asegurar la interacción de diferentes sistemas tanto dentro del holding como a nivel de una organización.

DIRECTUM proporciona herramientas convenientes para la construcción arquitectura distribuida gestionada organizar y resolver las siguientes tareas:

• organización de procesos de negocio de extremo a extremo y sincronización de datos entre varios sistemas de la misma empresa y en el holding;
• proporcionando acceso a datos de diferentes instalaciones de sistemas ECM. Por ejemplo, buscar un documento en varios sistemas especializados: con documentación financiera, con documentación de diseño y presupuesto, etc.
• administración de muchos sistemas y servicios desde un único punto de gestión y creación de una cómoda infraestructura de TI;
• distribución conveniente del desarrollo a los sistemas de producción distribuidos.

Componentes de una arquitectura distribuida administrada

Mecanismos de interconexión (DCI)

Los mecanismos de DCI se utilizan para organizar procesos comerciales de un extremo a otro y sincronizar datos entre diferentes sistemas dentro de una o varias organizaciones (holding).

La solución conecta los procesos comerciales locales existentes en las empresas en un único proceso de un extremo a otro. Los empleados y sus gerentes trabajan con la interfaz ya familiar de tareas, documentos y libros de referencia. Al mismo tiempo, las acciones de los empleados son transparentes en cada etapa: pueden ver el texto de la correspondencia con una empresa relacionada, ver el estado de aprobación de documentos con la organización matriz, etc.

Varias instalaciones de DIRECTUM y otras clases de sistemas (ERP, CRM, etc.) se pueden conectar a DCI. Como regla general, las instalaciones se dividen por áreas de negocio, teniendo en cuenta la ubicación territorial o legal de las organizaciones y otros factores.

Junto con DCI, los componentes de desarrollo se suministran con una descripción detallada y ejemplos de código, gracias a los cuales un desarrollador puede crear un algoritmo para los procesos comerciales de su organización.

Los mecanismos DCI son capaces de transmitir grandes cantidades de datos y soportar cargas máximas. Además, brindan tolerancia a fallas en caso de fallas de comunicación y la protección de los datos transmitidos.

Búsqueda federada

Con la búsqueda federada, puede encontrar las tareas o documentos que necesita a la vez en todos los sistemas DIRECTUM individuales. Por ejemplo, inicie una búsqueda simultáneamente en el sistema de trabajo y en el sistema con documentos archivados.

La búsqueda federada le permite:

• ver a través del cliente web el progreso de aprobación de un documento saliente en una subsidiaria;
• buscar acuerdos celebrados con una contraparte en todas las filiales, por ejemplo, para la preparación de negociaciones. En este caso, puede ir a las tareas en las que se adjuntan los contratos;
• verificar el estado de ejecución de la orden enviada desde la organización matriz a la subsidiaria, o los documentos y tareas creados en ella;
• encontrar documentos simultáneamente en varios sistemas con diferentes especializaciones, por ejemplo, con documentos organizativos y administrativos y con contratos;
• encontrar documentos contables primarios para auditoría o conciliación con una contraparte inmediatamente en el sistema de trabajo y en el sistema con un archivo de documentos;
• intercambiar enlaces a resultados de búsqueda con colegas.

El administrador puede cambiar las búsquedas estándar, agregar nuevas y también personalizar qué sistemas serán visibles para el usuario.

Centro de administración de servicios de DIRECTUM

El sistema DIRECTUM resuelve muchas tareas diferentes: interacción de empleados, almacenamiento de documentos, etc. Esto es posible gracias al funcionamiento confiable de sus servicios. Y en las grandes empresas, asignan instalaciones completas del sistema DIRECTUM con su propio conjunto de servicios para una tarea específica, por ejemplo, para almacenar documentos de archivo. Las instalaciones y los servicios se implementan en varios servidores. Esta infraestructura necesita ser administrada.

El Centro de administración de servicios de DIRECTUM es un único punto de entrada administrativo para configurar, monitorear y administrar los servicios y sistemas de DIRECTUM. El Centro es un sitio para herramientas de administración para el servidor de sesiones, el servicio de flujo de trabajo, el servicio de eventos, el servicio de almacenamiento de archivos, los servicios de entrada y transformación, la búsqueda federada y la ayuda web.

La conveniente configuración visual de los sistemas y servicios remotos simplifica el trabajo del administrador. No necesita ir a cada servidor y realizar cambios manualmente en los archivos de configuración.

Los servicios se detienen y habilitan con un solo clic. El estado de los servicios se muestra instantáneamente en la pantalla.

La lista de configuraciones se puede reponer y filtrar. De forma predeterminada, el sitio solo muestra la configuración básica. Al mismo tiempo, para todas las configuraciones, puede ver consejos con recomendaciones para el llenado.

El sistema DIRECTUM organiza eficazmente el trabajo de las organizaciones distribuidas y proporciona a los usuarios un intercambio transparente de documentos, tareas y registros de directorio.

Cada componente de una arquitectura distribuida administrada se puede utilizar por separado, pero juntos pueden aportar un mayor valor comercial a su organización.

Actualmente, todos los SI desarrollados con fines comerciales cuentan con una arquitectura distribuida, lo que implica el uso de redes de área global y / o local.

Históricamente, la arquitectura de servidor de archivos fue la primera en generalizarse, ya que su lógica es simple y es más fácil transferir a dicha arquitectura los IS que ya están en uso. Luego se transformó en una arquitectura servidor-cliente, que se puede interpretar como su continuación lógica. Los sistemas modernos utilizados en la red global INTERNET se relacionan principalmente con la arquitectura de objetos distribuidos (ver Fig. III‑15 )

Se puede imaginar que IS consta de los siguientes componentes (Fig. III-16)

III.03.2. a Aplicaciones de servidor de archivos.

Históricamente es la primera arquitectura distribuida (Fig. III-17). Está organizado de manera muy simple: solo hay datos en el servidor y todo lo demás pertenece a la máquina cliente. Dado que las redes locales son bastante baratas, y debido al hecho de que con una arquitectura de este tipo, el software de aplicación es autónomo, esta arquitectura se utiliza a menudo en la actualidad. Podemos decir que esta es una variante de la arquitectura cliente-servidor, en la que solo los archivos de datos se encuentran en el servidor. Diferentes computadoras personales interactúan solo por medio de un almacén de datos común, por lo tanto, los programas escritos para una computadora son más fáciles de adaptar a dicha arquitectura.

Pros:

Ventajas de una arquitectura de servidor de archivos:

Facilidad de organización;

No contradice los requisitos necesarios para que la base de datos mantenga integridad y confiabilidad.

Congestión en la red;

Respuesta impredecible a una solicitud.

Estas desventajas se explican por el hecho de que cualquier solicitud a la base de datos conduce a la transferencia de importantes cantidades de información a través de la red. Por ejemplo, para seleccionar una o varias filas de las tablas, toda la tabla se descarga en la máquina cliente y el DBMS ya selecciona allí. El tráfico de red significativo está especialmente cargado de la organización del acceso remoto a la base de datos.

III.03.2. b Aplicaciones cliente-servidor.

En este caso, existe una distribución de responsabilidades entre el servidor y el cliente. Dependiendo de como se separen se distinguen gordo y cliente ligero.

En el modelo de cliente ligero, todo el trabajo de la aplicación y la gestión de datos se realiza en el servidor. La interfaz de usuario en estos sistemas "migra" a una computadora personal, y la propia aplicación de software realiza las funciones de un servidor, es decir, ejecuta todos los procesos de la aplicación y gestiona los datos. El modelo de cliente ligero también se puede implementar donde los clientes son computadoras o estaciones de trabajo. Los dispositivos de red ejecutan el navegador de Internet y la interfaz de usuario implementada dentro del sistema.

Principal falla modelos de cliente ligero: alta carga de servidor y red. Todos los cálculos se realizan en el servidor y esto puede generar un tráfico de red significativo entre el cliente y el servidor. Hay suficiente potencia informática en las computadoras modernas, pero prácticamente no se usa en el modelo / cliente ligero del banco.

Por el contrario, el modelo de cliente pesado utiliza el poder de procesamiento de las máquinas locales: la aplicación en sí se coloca en la computadora del cliente. Un ejemplo de este tipo de arquitectura son los sistemas de cajeros automáticos, en los que el cajero automático es el cliente y el servidor es la computadora central que atiende la base de datos de cuentas de los clientes.

III.03.2. c Arquitectura cliente-servidor de dos y tres niveles.

Todas las arquitecturas discutidas anteriormente son de dos niveles. Se diferencian entre el nivel del cliente y el nivel del servidor. Estrictamente hablando, el IC consta de tres niveles lógicos:

· Nivel de usuario;

Nivel de aplicación:

· Capa de datos.

Por lo tanto, en un modelo de dos niveles, donde solo están involucrados dos niveles, existen problemas de escalabilidad y rendimiento si se elige el modelo de cliente ligero, o problemas de administración del sistema si se elige el modelo de cliente pesado. Estos problemas se pueden evitar si aplicamos un modelo que consta de tres niveles, donde dos de ellos son servidores (Fig. III-21).

Servidor de datos

De hecho, el servidor de aplicaciones y el servidor de datos pueden estar ubicados en la misma máquina, pero no pueden realizar las funciones entre sí. Lo bueno del modelo de tres niveles es que separa lógicamente la ejecución de la aplicación y la gestión de datos.

Cuadro III-5 Aplicación de diferentes tipos de arquitecturas

Arquitectura	Apéndice
Cliente ligero de dos niveles	1 Sistemas heredados en los que no es aconsejable separar la ejecución de aplicaciones y la gestión de datos. 2 Compute aplicaciones intensivas con poca gestión de datos. 3 Aplicaciones con gran cantidad de datos, pero poca computación.
Cliente grueso de dos niveles	1 Aplicaciones en las que el usuario requiere un procesamiento intensivo de datos, es decir, visualización de datos. 2 Aplicaciones con un conjunto relativamente constante de funciones de usuario aplicadas a un entorno de sistema bien gestionado.
Servidor-cliente de tres niveles	1 Grandes aplicaciones con células y miles de clientes 2 Aplicaciones en las que tanto los datos como los métodos de procesamiento cambian con frecuencia. 3 Aplicaciones que integran datos de múltiples fuentes.

Este modelo es adecuado para muchos tipos de aplicaciones, pero limita a los desarrolladores de sistemas de información que deben decidir dónde proporcionar los servicios, brindar soporte para la escalabilidad y desarrollar herramientas para conectar nuevos clientes.

III.03.2. d Arquitectura de objetos distribuidos.

Un enfoque más general lo proporciona una arquitectura de objetos distribuidos, de los cuales los objetos son los componentes principales. Proporcionan un conjunto de servicios a través de sus interfaces. Otros objetos envían solicitudes sin diferenciar entre cliente y servidor. Los objetos se pueden ubicar en diferentes computadoras en la red e interactuar a través de middleware, similar al bus del sistema, que le permite conectar diferentes dispositivos y mantener la comunicación entre dispositivos de hardware.

…

Administrador de controladores ODBC

Conductor 1

Conductor K

DB 1

DB K

Trabajando con SQL

…

La arquitectura ODBC incluye componentes:

1. Aplicación (por ejemplo, IS). Realiza tareas: solicita una conexión a la fuente de datos, envía consultas SQL a la fuente de datos, describe el área de almacenamiento y el formato para consultas SQL, maneja errores y notifica al usuario sobre ellos, confirma o revierte transacciones, solicita una conexión al fuente de datos.

2. Administrador de dispositivos. Carga controladores según demanda de las aplicaciones, ofrece una única interfaz para todas las aplicaciones y la interfaz de administrador de ODBC es la misma e independientemente del DBMS con el que interactuará la aplicación. El Administrador de controladores proporcionado por Microsoft es una biblioteca de carga dinámica (DLL).

3. El controlador depende del DBMS. Un controlador ODBC es una biblioteca de vínculos dinámicos (DLL) que implementa funciones ODBC e interactúa con una fuente de datos. Un controlador es un programa que procesa una solicitud para una función específica de un DBMS (puede modificar solicitudes de acuerdo con el DBMS) y devuelve el resultado a la aplicación. Todo DBMS que admita la tecnología ODBC debe proporcionar a los desarrolladores de aplicaciones un controlador para ese DBMS.

4. La fuente de datos contiene la información de control especificada por el usuario, información sobre la fuente de datos y se utiliza para acceder a un DBMS específico. En este caso, se utilizan los medios del sistema operativo y la plataforma de red.

Modelo dinámico

Este modelo asume muchos aspectos, para los cuales se utilizan al menos 5 diagramas en UML, ver págs. 2.04.2- 2.04.5.

Considere el aspecto de la gestión. El modelo de gobernanza complementa los modelos estructurales.

Independientemente de cómo se describa la estructura del sistema, consta de un conjunto de unidades estructurales (funciones u objetos). Para que funcionen como un todo, deben estar controlados y no hay información de control en los diagramas estáticos. Los modelos de control diseñan el flujo de control entre sistemas.

Hay dos tipos principales de control en los sistemas de software.

1. Gestión centralizada.

2. Gestión basada en eventos.

La gestión centralizada puede ser:

· Jerárquico- sobre la base del principio de "devolución de llamada" (así es como funcionan los programas educativos con mayor frecuencia)

· Modelo de despachador que se utiliza para sistemas en paralelo.

V modelos de despachador se supone que uno de los componentes del sistema es un despachador. Gestiona tanto la puesta en marcha como la parada de los sistemas y la coordinación del resto de procesos del sistema. Los procesos pueden ejecutarse en paralelo entre sí. Un proceso se refiere a un programa, subsistema o procedimiento que se está ejecutando actualmente. Este modelo también se puede aplicar en sistemas secuenciales, donde el programa de control llama a subsistemas individuales dependiendo de algunas variables de estado (a través del operador caso).

Gestión de eventos asume la ausencia de cualquier subrutina responsable de la gestión. El control se realiza mediante eventos externos: presionar un botón del mouse, presionar un teclado, cambiar las lecturas del sensor, cambiar las lecturas del temporizador, etc. Cada evento externo se codifica y se coloca en la cola de eventos. Si se proporciona una reacción a un evento en la cola, entonces se llama al procedimiento (subrutina), que realiza la reacción a este evento. Los eventos a los que reacciona el sistema pueden ocurrir en otros subsistemas o en el entorno externo del sistema.

Un ejemplo de tal gestión es la organización de aplicaciones en Windows.

Todos los modelos estructurales descritos anteriormente se pueden implementar mediante la gestión centralizada o la gestión basada en eventos.

Interfaz de usuario

Al desarrollar un modelo de interfaz, se deben tener en cuenta no solo las tareas del software diseñado, sino también las características del cerebro asociadas con la percepción de la información.

III.03.4. a Características psicofísicas de una persona asociadas a la percepción y procesamiento de información.

La parte del cerebro, que convencionalmente se puede llamar un procesador de percepción, constantemente, sin la participación de la conciencia, procesa la información entrante, la compara con la experiencia pasada y la almacena.

Cuando una imagen visual nos llama la atención, la información que nos interesa llega a la memoria a corto plazo. Si nuestra atención no fue atraída, entonces la información en el almacenamiento desaparece, siendo reemplazada por las siguientes porciones.

En cada momento, el foco de atención se puede fijar en un punto, por lo que si es necesario rastrear simultáneamente varias situaciones, entonces el foco se mueve de un objeto rastreado a otro. Al mismo tiempo, la atención se dispersa y algunos detalles pueden pasarse por alto. También es significativo que la percepción se base en gran medida en la motivación.

Cuando cambia el encuadre, el cerebro se bloquea por un tiempo: domina una nueva imagen, resaltando los detalles más significativos. Esto significa que si necesita una respuesta rápida del usuario, no debe cambiar las imágenes de forma abrupta.

La memoria a corto plazo es el cuello de botella en el sistema de procesamiento de información de una persona. Su capacidad es de 7 ± 2 objetos desconectados. La información no reclamada se almacena en él durante no más de 30 segundos. Para no olvidarnos ninguna información importante, solemos repetirla, actualizando la información en la memoria a corto plazo. Así, a la hora de diseñar interfaces, hay que tener en cuenta que a la inmensa mayoría les resulta difícil, por ejemplo, recordar e introducir números que contengan más de cinco dígitos en otra pantalla.

Aunque la capacidad y el tiempo de almacenamiento de la memoria a largo plazo son ilimitados, el acceso a la información no es fácil. El mecanismo para extraer información de la memoria a largo plazo es de naturaleza asociativa. Para mejorar la memorización de la información, se ata a los datos que la memoria ya almacena y facilita su obtención. Dado que el acceso a la memoria a largo plazo es difícil, es aconsejable esperar que el usuario no recuerde la información, sino que el usuario la reconocerá.

III.03.4. b Criterios básicos para evaluar interfaces

Numerosas encuestas y encuestas realizadas por empresas líderes en desarrollo de software han demostrado que los usuarios valoran en una interfaz:

1) facilidad de masterización y memorización: estime específicamente el tiempo de masterización y la duración de la preservación de la información y la memoria;

2) la velocidad para lograr resultados cuando se usa el sistema, que está determinada por la cantidad de comandos y configuraciones ingresadas o seleccionadas por el mouse;

3) satisfacción subjetiva con el funcionamiento del sistema (facilidad de uso, fatiga, etc.).

Además, para los usuarios profesionales que trabajan constantemente con el mismo paquete, el segundo y tercer criterio pasan rápidamente al primer lugar, y para los usuarios no profesionales que trabajan con software periódicamente y realizan tareas relativamente simples: el primero y el tercero.

Desde este punto de vista, hoy en día las mejores características para los usuarios profesionales son las interfaces con navegación gratuita, y para los usuarios no profesionales, las interfaces de manipulación directa. Durante mucho tiempo se ha notado que al realizar una operación de copia de archivos, en igualdad de condiciones, la mayoría de los profesionales usan shells como Far, mientras que los no profesionales usan Windows "arrastrar y soltar".

III.03.4. c Tipos de interfaces de usuario

Se distinguen los siguientes tipos de interfaces de usuario:

Primitivo

Navegación libre

Manipulación directa.

La interfaz es primitiva

Primitivo se denomina interfaz que organiza la interacción con el usuario y se utiliza en modo consola. La única desviación del proceso secuencial que proporcionan los datos es recorrer varios conjuntos de datos.

Interfaz de menú.

A diferencia de la interfaz primitiva, permite al usuario seleccionar una operación de una lista especial que muestra el programa. Estas interfaces asumen la implementación de muchos escenarios de trabajo, cuya secuencia de acciones es determinada por los usuarios. La organización en forma de árbol del menú sugiere que es difícil encontrar un elemento en menús de más de dos niveles.

Principios para la creación de un sistema de procesamiento de información para toda la empresa

La historia del desarrollo de la tecnología informática (y, en consecuencia, el software) comenzó con sistemas autónomos separados. Los científicos e ingenieros estaban preocupados por la creación de las primeras computadoras y principalmente estaban desconcertados sobre cómo hacer que funcionaran estos enjambres de tubos de vacío. Sin embargo, esta situación no duró mucho: la idea de combinar la potencia informática era bastante obvia y estaba en el aire, saturada con el zumbido de los gabinetes metálicos de los primeros ENIAK y Marcas. Después de todo, la idea de combinar los esfuerzos de dos o más computadoras para resolver tareas complejas e insoportables para cada una de ellas por separado se encuentra en la superficie.

Arroz. 1. Esquema de computación distribuida

Sin embargo, la implementación práctica de la idea de conectar computadoras en clústeres y redes se vio obstaculizada por la falta de soluciones técnicas y, en primer lugar, por la necesidad de crear estándares y protocolos de comunicación. Como saben, las primeras computadoras aparecieron a fines de la década del cuarenta del siglo XX, y la primera red informática ARPANet, que conectó varias computadoras en Estados Unidos, recién en 1966, casi veinte años después. Por supuesto, tal combinación de capacidades informáticas de la arquitectura distribuida moderna se parecía muy vagamente, pero sin embargo fue el primer paso en la dirección correcta.

La aparición de redes de área local a lo largo del tiempo condujo al desarrollo de una nueva área de desarrollo de software: la creación de aplicaciones distribuidas. Tuvimos que hacer esto desde cero, como dicen, pero, afortunadamente, las grandes empresas, cuya estructura empresarial requería tales soluciones, inmediatamente mostraron interés en tales aplicaciones. Fue en la etapa de creación de aplicaciones distribuidas corporativas cuando se formaron los requisitos básicos y se desarrollaron las principales arquitecturas de dichos sistemas, que aún se utilizan en la actualidad.

Gradualmente, los mainframes y terminales evolucionaron hacia una arquitectura cliente-servidor, que era esencialmente la primera versión de una arquitectura distribuida, es decir, un sistema distribuido de dos niveles. De hecho, fue en las aplicaciones cliente-servidor donde parte de las operaciones computacionales y la lógica empresarial se transfirieron al lado del cliente, que, de hecho, se convirtió en lo más destacado, el sello distintivo de este enfoque.

Fue durante este período cuando se hizo evidente que las principales ventajas de las aplicaciones distribuidas son:

· Buena escalabilidad: si es necesario, la potencia informática de una aplicación distribuida se puede aumentar fácilmente sin cambiar su estructura;

· La capacidad de gestionar la carga: los niveles intermedios de una aplicación distribuida permiten gestionar los flujos de solicitudes de los usuarios y redirigirlos a servidores menos cargados para su procesamiento;

· Globalidad: una estructura distribuida le permite seguir la distribución espacial de los procesos comerciales y crear estaciones de trabajo de clientes en los puntos más convenientes.

Con el paso del tiempo, pequeñas islas de redes universitarias, gubernamentales y corporativas se expandieron, fusionándose en sistemas regionales y nacionales. Y luego apareció en escena el jugador principal: Internet.

Los elogios elogiosos sobre la World Wide Web han sido durante mucho tiempo un lugar común para las publicaciones sobre temas informáticos. De hecho, Internet ha jugado un papel fundamental en el desarrollo de la computación distribuida y ha hecho de esta área bastante específica del desarrollo de software el foco de un ejército de programadores profesionales. En la actualidad, amplía significativamente el uso de aplicaciones distribuidas, lo que permite a los usuarios remotos conectarse y hacer que las funciones de la aplicación estén disponibles en todas partes.

Esta es la historia del problema. Ahora echemos un vistazo a qué son las aplicaciones distribuidas.

Paradigma de computación distribuida

Imagine una instalación de fabricación, una empresa comercial o un proveedor de servicios bastante grande. Todas sus divisiones ya cuentan con sus propias bases de datos y software específico. La oficina central de alguna manera recopila información sobre las actividades actuales de estos departamentos y proporciona a los gerentes información sobre la base de la cual toman decisiones de gestión.

Vayamos más allá y supongamos que la organización que estamos considerando se está desarrollando con éxito, abriendo sucursales, desarrollando nuevos tipos de productos o servicios. Además, en la última reunión, los ejecutivos de mentalidad progresista decidieron organizar una red de estaciones de trabajo remotas desde las que los clientes pudieran recibir información sobre el cumplimiento de sus pedidos.

En la situación descrita, solo queda sentir lástima por el jefe del departamento de TI si no se ocupó de construir un sistema general de gestión de flujo de negocios con anticipación, porque sin él será muy difícil garantizar el desarrollo efectivo de la organización. Además, no se puede prescindir de un sistema de procesamiento de información para toda la empresa, diseñado teniendo en cuenta la carga creciente y, además, correspondiente a los principales flujos comerciales, ya que todos los departamentos deben realizar no solo sus tareas, sino también, si es necesario, procesar las solicitudes. de otros departamentos e incluso (¡pesadilla para un director de proyecto!) clientes.

Por lo tanto, estamos listos para formular los requisitos básicos para las aplicaciones modernas a escala empresarial dictadas por la organización misma del proceso de producción.

Separación espacial. Las divisiones de la organización están dispersas en el espacio y, a menudo, tienen un software mal unificado.

Cumplimiento estructural. El software debe reflejar adecuadamente la estructura de información de la empresa; debe corresponder a los principales flujos de datos.

Orientación a información externa. Las empresas modernas se ven obligadas a prestar mayor atención al trabajo con los clientes. Por lo tanto, el software empresarial debe poder trabajar con un nuevo tipo de usuario y sus necesidades. Dichos usuarios tienen a sabiendas derechos limitados y tienen acceso a un tipo de datos estrictamente definido.

Todos los requisitos anteriores para el software empresarial se cumplen mediante sistemas distribuidos; el esquema de distribución de cálculo se muestra en la Fig. una.

Por supuesto, las aplicaciones distribuidas no están libres de fallas. En primer lugar, son costosos de operar y, en segundo lugar, la creación de tales aplicaciones es un proceso laborioso y complejo, y el costo de un error en la etapa de diseño es muy alto. No obstante, el desarrollo de aplicaciones distribuidas está progresando bien: el juego vale la pena, porque dicho software ayuda a mejorar la eficiencia de la organización.

Entonces, el paradigma de la computación distribuida implica la presencia de varios centros (servidores) para almacenar y procesar información, implementando varias funciones y espaciados. Estos centros, además de las solicitudes de los clientes del sistema, también deben atender las solicitudes de los demás, ya que en algunos casos, la solución de la primera tarea puede requerir el esfuerzo conjunto de varios servidores. Para gestionar solicitudes complejas y el funcionamiento del sistema en su conjunto, se requiere un software de control especializado. Y finalmente, todo el sistema debe estar "inmerso" en algún tipo de entorno de transporte que asegure la interacción de sus partes.

Los sistemas informáticos distribuidos tienen propiedades comunes como:

· Capacidad de gestión: implica la capacidad del sistema para controlar eficazmente sus componentes. Esto se logra mediante el uso de software de control;

· Rendimiento - proporcionado debido a la posibilidad de redistribuir la carga en los servidores del sistema usando el software de control;

Escalabilidad: si es necesario aumentar físicamente la productividad, un sistema distribuido puede integrar fácilmente nuevos recursos informáticos en su entorno de transporte;

· Extensibilidad: se pueden agregar nuevos componentes (software de servidor) con nuevas funciones a las aplicaciones distribuidas.

El acceso a los datos en aplicaciones distribuidas es posible desde el software del cliente y otros sistemas distribuidos se pueden organizar en varios niveles, desde el software del cliente y los protocolos de transporte hasta la protección de los servidores de bases de datos.

Arroz. 2. Los principales niveles de la arquitectura de una aplicación distribuida

Las propiedades enumeradas de los sistemas distribuidos son razón suficiente para soportar la complejidad de su desarrollo y el alto costo de mantenimiento.

Arquitectura de aplicaciones distribuidas

Considere la arquitectura de una aplicación distribuida que le permite realizar funciones complejas y variadas. Las diferentes fuentes proporcionan diferentes opciones para crear aplicaciones distribuidas. Y todos tienen derecho a existir, porque tales aplicaciones resuelven la más amplia gama de problemas en muchas áreas temáticas, y el desarrollo incontenible de herramientas y tecnologías de desarrollo impulsa la mejora continua.

Sin embargo, existe la arquitectura más general de una aplicación distribuida, según la cual se divide en varias capas lógicas, capas de procesamiento de datos. Las aplicaciones, como sabes, están diseñadas para procesar información, y aquí podemos distinguir tres funciones principales de ellas:

· Presentación de datos (nivel de usuario). Aquí los usuarios de la aplicación pueden ver los datos necesarios, enviar una solicitud de ejecución, ingresar nuevos datos en el sistema o editarlos;

· Procesamiento de datos (nivel intermedio, middleware). En este nivel, se concentra la lógica empresarial de la aplicación, se controlan los flujos de datos y se organiza la interacción de las partes de la aplicación. Es la concentración de todas las funciones de control y procesamiento de datos en un nivel lo que se considera la principal ventaja de las aplicaciones distribuidas;

· Almacenamiento de datos (capa de datos). Este es el nivel del servidor de la base de datos. Los propios servidores, bases de datos, herramientas de acceso a datos y varias herramientas auxiliares se encuentran aquí.

Esta arquitectura a menudo se denomina arquitectura de tres o tres niveles. Y muy a menudo sobre la base de estas "tres ballenas" se crea la estructura de la aplicación desarrollada. Siempre se debe tener en cuenta que cada nivel se puede subdividir en varios subniveles. Por ejemplo, el nivel de usuario se puede dividir en la interfaz de usuario real y las reglas para validar y procesar los datos de entrada.

Por supuesto, si tenemos en cuenta la posibilidad de dividir en subniveles, entonces cualquier aplicación distribuida puede incluirse en la arquitectura de tres niveles. Pero aquí no se puede ignorar otro rasgo característico inherente a las aplicaciones distribuidas: la gestión de datos. La importancia de esta característica es obvia porque es muy difícil crear una aplicación distribuida en el mundo real (con todas las estaciones cliente, middleware, servidores de bases de datos, etc.) que no gestiona sus solicitudes y respuestas. Por lo tanto, una aplicación distribuida debe tener otra capa lógica: la capa de gestión de datos.

Arroz. 3. Distribución de la lógica empresarial en los niveles de una aplicación distribuida.

Por lo tanto, es recomendable dividir el nivel intermedio en dos independientes: el nivel de procesamiento de datos (ya que es necesario tener en cuenta la importante ventaja que brinda: la concentración de reglas comerciales para el procesamiento de datos) y el nivel de gestión de datos. Este último proporciona control sobre la ejecución de solicitudes, mantiene el trabajo con los flujos de datos y organiza la interacción de las partes del sistema.

Por lo tanto, hay cuatro capas principales de una arquitectura distribuida (ver Fig.2):

· Presentación de datos (nivel de usuario);

· Reglas de lógica empresarial (capa de procesamiento de datos);

· Gestión de datos (capa de gestión de datos);

· Almacenamiento de datos (capa de almacenamiento de datos).

Tres de los cuatro niveles, excluyendo el primero, están directamente involucrados en el procesamiento de datos, y la capa de presentación de datos le permite visualizarlos y editarlos. Con la ayuda de esta capa, los usuarios reciben datos de la capa de procesamiento de datos, que, a su vez, recupera información de los repositorios y realiza todas las transformaciones de datos necesarias. Después de ingresar nueva información o editar los datos existentes, los flujos de datos se dirigen hacia atrás: desde la interfaz de usuario a través de la capa de reglas comerciales hasta el repositorio.

Otra capa, la gestión de datos, se mantiene al margen de la red troncal de datos, pero garantiza el buen funcionamiento de todo el sistema, gestionando solicitudes y respuestas y la interacción de partes de la aplicación.

Por separado, es necesario considerar la opción de ver los datos en el modo "solo lectura". En este caso, la capa de procesamiento de datos no se utiliza en el esquema general de transferencia de datos, ya que no es necesario realizar ningún cambio. Y el flujo de información en sí mismo es unidireccional, desde el nivel de almacenamiento hasta el nivel de presentación de datos.

Estructura física de aplicaciones distribuidas

Pasemos ahora a las capas físicas de las aplicaciones distribuidas. La topología de un sistema distribuido implica la división en varios servidores de bases de datos, servidores de procesamiento de datos y una colección de clientes locales y remotos. Todos ellos se pueden ubicar en cualquier lugar: en el mismo edificio o en otro continente. En cualquier caso, las partes de un sistema distribuido deben estar conectadas mediante líneas de comunicación confiables y seguras. En cuanto a la velocidad de transferencia de datos, depende en gran medida de la importancia de la conexión entre las dos partes del sistema en términos de procesamiento y transmisión de datos y, en menor medida, de su lejanía.

Distribución de la lógica empresarial en los niveles de aplicaciones distribuidas.

Ahora es el momento de pasar a una descripción detallada de los niveles de un sistema distribuido, pero primero digamos algunas palabras sobre la distribución de la funcionalidad de la aplicación en todos los niveles. La lógica empresarial se puede implementar en cualquiera de los niveles de la arquitectura de tres niveles.

Los servidores de bases de datos no solo pueden almacenar datos en bases de datos, sino que también pueden contener parte de la lógica empresarial de la aplicación en procedimientos almacenados, activadores, etc.

Las aplicaciones cliente también pueden implementar reglas de procesamiento de datos. Si el conjunto de reglas es mínimo y se reduce principalmente a procedimientos para comprobar la exactitud de la entrada de datos, estamos ante un cliente "ligero". Por el contrario, un cliente pesado contiene una gran proporción de la funcionalidad de la aplicación.

El nivel de procesamiento de datos está destinado a implementar la lógica comercial de la aplicación, y todas las reglas básicas para el procesamiento de datos se concentran aquí.

Por tanto, en el caso general, la funcionalidad de la aplicación se "difumina" en toda la aplicación. Toda la variedad de distribución de la lógica empresarial en los niveles de aplicación se puede representar como una curva suave que muestra la proporción de reglas de procesamiento de datos concentradas en un lugar específico. Las curvas de la Fig. 3 son de naturaleza cualitativa, pero no obstante le permiten ver cómo los cambios en la estructura de la aplicación pueden afectar la distribución de las reglas.

Y la práctica confirma esta conclusión. Después de todo, siempre hay un par de reglas que deben implementarse en los procedimientos almacenados del servidor de la base de datos, y muy a menudo es conveniente transferir algunas operaciones iniciales con datos al lado del cliente, al menos para evitar el procesamiento de solicitudes incorrectas. .

Capa de presentación

La capa de presentación de datos es la única disponible para el usuario final. Esta capa simula las estaciones de trabajo cliente de una aplicación distribuida y el software correspondiente. Las capacidades de la estación de trabajo cliente están determinadas principalmente por las capacidades del sistema operativo. Según el tipo de interfaz de usuario, el software de cliente se divide en dos grupos: clientes que utilizan capacidades de GUI (por ejemplo, Windows) y clientes web. Pero en cualquier caso, la aplicación cliente debe proporcionar las siguientes funciones:

· Recibiendo información;

· Presentación de datos para que los vea el usuario;

· Edición de datos;

· Verificación de la exactitud de los datos ingresados;

· Guardar los cambios realizados;

· Manejo de excepciones y visualización de información sobre errores para el usuario.

Es deseable concentrar todas las reglas comerciales en el nivel de procesamiento de datos, pero en la práctica esto no siempre es posible. Luego hablan de dos tipos de software cliente. El cliente ligero contiene un conjunto mínimo de reglas comerciales, mientras que el cliente pesado implementa una parte importante de la lógica de la aplicación. En el primer caso, la aplicación distribuida es mucho más fácil de depurar, modernizar y expandir, en el segundo, puede minimizar los costos de crear y mantener la capa de administración de datos, ya que algunas de las operaciones se pueden realizar en el lado del cliente, y solo la transferencia de datos recae en el middleware.

Capa de procesamiento de datos

La capa de procesamiento de datos combina las partes que implementan la lógica empresarial de la aplicación y es un intermediario entre la capa de presentación y la capa de almacenamiento. Todos los datos pasan a través de él y sufren cambios en él, debido a la solución del problema (ver Fig. 2). Las funciones de este nivel incluyen las siguientes:

· Procesamiento de flujos de datos de acuerdo con las reglas comerciales;

· Interactuar con la capa de presentación de datos para recibir solicitudes y devolver respuestas;

· Interacción con la capa de almacenamiento de datos para enviar solicitudes y recibir respuestas.

Muy a menudo, la capa de procesamiento de datos se equipara con el middleware de una aplicación distribuida. Esta situación es totalmente cierta para un sistema "ideal" y sólo parcialmente para aplicaciones reales (ver Fig. 3). En cuanto a este último, el middleware para ellos contiene una gran proporción de reglas de procesamiento de datos, pero algunas de ellas se implementan en servidores SQL en forma de procedimientos almacenados o disparadores, y algunas están incluidas en el software del cliente.

Este "desenfoque" de la lógica empresarial está justificado, ya que permite simplificar algunos de los procedimientos de procesamiento de datos. Tomemos un ejemplo clásico de declaración de pedido. Puede incluir los nombres de solo aquellos productos que están en stock. Por lo tanto, al agregar un determinado artículo al pedido y determinar su cantidad, se debe restar el número correspondiente del resto de este artículo en el almacén. Obviamente, la mejor manera de implementar esta lógica es a través del servidor de base de datos, ya sea un procedimiento almacenado o un disparador.

Capa de gestión de datos

La capa de administración de datos es necesaria para garantizar que la aplicación siga siendo coherente, resistente y confiable, tenga la capacidad de modernizarse y escalar. Garantiza la ejecución de las tareas del sistema; sin él, partes de la aplicación (servidores de bases de datos, servidores de aplicaciones, middleware, clientes) no podrán interactuar entre sí y las conexiones interrumpidas durante un aumento de la carga no se podrán restaurar.

Además, se pueden implementar varios servicios del sistema de la aplicación a nivel de gestión de datos. Después de todo, siempre hay funciones comunes a toda la aplicación que son necesarias para el funcionamiento de todos los niveles de la aplicación, por lo tanto, no pueden ubicarse en ninguno de los otros niveles.

Por ejemplo, un servicio de marca de tiempo proporciona todas las partes de una aplicación con marcas de tiempo del sistema que las mantienen sincronizadas. Imagine que una aplicación distribuida tiene un servidor que envía tareas a los clientes con una fecha límite específica. Si se incumple el plazo, la tarea debe registrarse con el cálculo del tiempo de retraso. Si las estaciones de trabajo del cliente están ubicadas en el mismo edificio que el servidor, o en una calle adyacente, no hay problema, el algoritmo de contabilidad es simple. Pero, ¿qué sucede si los clientes se encuentran en diferentes zonas horarias, en otros países o incluso en el extranjero? En este caso, el servidor debe poder calcular la diferencia teniendo en cuenta las zonas horarias al enviar tareas y recibir respuestas, y los clientes deberán agregar información de servicio sobre la hora local y la zona horaria a los informes. Si se incluye un servicio de tiempo único en una aplicación distribuida, entonces este problema simplemente no existe.

Además del servicio de una sola vez, el nivel de gestión de datos puede contener servicios para almacenar información general (información sobre la aplicación en su conjunto), generar informes generales, etc.

Entonces, las funciones de la capa de administración de datos incluyen:

· Gestionar partes de una aplicación distribuida;

· Gestión de conexiones y canales de comunicación entre partes de la aplicación;

· Control de los flujos de datos entre clientes y servidores y entre servidores;

· Control de carga;

· Implementación de servicios del sistema de la aplicación.

Cabe señalar que, a menudo, la capa de gestión de datos se crea sobre la base de soluciones listas para usar suministradas al mercado de software por varios fabricantes. Si los desarrolladores han elegido la arquitectura CORBA para su aplicación, entonces incluye un Object Request Broker (ORB), si la plataforma es Windows, tienen una variedad de herramientas a su servicio: tecnología COM + (desarrollo de la tecnología Microsoft Transaction Server, MTS), tecnología de procesamiento de colas de mensajes MSMQ, tecnología Microsoft BizTalk, etc.

Capa de almacenamiento de datos

El nivel de almacenamiento reúne los servidores SQL y las bases de datos que utiliza la aplicación. Proporciona una solución a las siguientes tareas:

· Almacenar datos en una base de datos y mantenerlos en funcionamiento;

· Procesamiento de solicitudes del nivel de procesamiento de datos y devolución de resultados;

· Implementación de una parte de la lógica empresarial de una aplicación distribuida;

· Gestión de bases de datos distribuidas mediante herramientas administrativas de servidores de bases de datos.

Además de las funciones obvias: almacenar datos y procesar consultas, una capa puede contener una parte de la lógica comercial de la aplicación en procedimientos almacenados, disparadores, restricciones, etc. Y la estructura misma de la base de datos de la aplicación (tablas y sus campos, índices, claves foráneas, etc.)) existe una implementación de la estructura de datos con la que trabaja la aplicación distribuida, y la implementación de algunas reglas de lógica empresarial. Por ejemplo, el uso de una clave externa en una tabla de base de datos requiere la creación de una restricción correspondiente sobre la manipulación de datos, ya que los registros de la tabla principal no se pueden eliminar si hay registros correspondientes vinculados por la clave externa de la tabla.

La mayoría de los servidores de bases de datos admiten una variedad de procedimientos de administración, incluida la gestión de bases de datos distribuidas. Estos incluyen replicación de datos, archivo remoto, herramientas para acceder a bases de datos remotas, etc. La capacidad de usar estas herramientas debe tenerse en cuenta al desarrollar la estructura de su propia aplicación distribuida.

La conexión a las bases de datos de SQL Server se realiza principalmente con el software cliente del servidor. Además, también se pueden utilizar varias tecnologías de acceso a datos, por ejemplo, ADO (ActiveX Data Objects) o ADO.NET. Pero al diseñar un sistema, es necesario tener en cuenta que las tecnologías de acceso a datos funcionalmente intermedias no pertenecen al nivel de almacenamiento de datos.

Extensiones de nivel base

Los niveles anteriores de arquitectura de aplicaciones distribuidas son básicos. Forman la estructura de la aplicación creada como un todo, pero al mismo tiempo, por supuesto, no pueden proporcionar la implementación de ninguna aplicación: las áreas temáticas y las tareas son demasiado vastas y diversas. Para tales casos, la arquitectura de una aplicación distribuida se puede ampliar con capas adicionales que están diseñadas para reflejar las características de la aplicación que se está creando.

Entre otras, hay dos de las extensiones de nivel base más utilizadas.

La capa de interfaz empresarial se encuentra entre la capa de interfaz de usuario y la capa de procesamiento de datos. Oculta a las aplicaciones del cliente los detalles de la estructura y la implementación de las reglas comerciales de la capa de procesamiento de datos, proporcionando una abstracción del código de la aplicación del cliente de las características de implementación de la lógica de la aplicación.

Como resultado, los desarrolladores de aplicaciones cliente utilizan un cierto conjunto de funciones necesarias, un análogo de una interfaz de programación de aplicaciones (API). Esto hace que el software del cliente sea independiente de la implementación de la capa de procesamiento de datos.

Por supuesto, al realizar cambios serios en el sistema, no puede prescindir de alteraciones globales, pero el nivel de la interfaz empresarial le permite no hacer esto a menos que sea absolutamente necesario.

La capa de acceso a datos se encuentra entre la capa de almacenamiento de datos y la capa de procesamiento de datos. Le permite hacer que la estructura de la aplicación sea independiente de una tecnología de almacenamiento de datos específica. En tales casos, los objetos de software de la capa de procesamiento de datos envían solicitudes y reciben respuestas utilizando los medios de la tecnología de acceso a datos elegida.

Al implementar aplicaciones en la plataforma Windows, la tecnología de acceso a datos ADO se usa con mayor frecuencia porque proporciona una forma universal de acceder a una amplia variedad de fuentes de datos, desde servidores SQL hasta hojas de cálculo. Para las aplicaciones en la plataforma .NET, se utiliza la tecnología ADO.NET.