2

SISTEMAS OPERATIVOS DE RED Y SISTEMAS OPERATIVOS DISTRIBUIDOS

Posted by DARKBLADE on 16:30



SISTEMAS OPERATIVOS DE RED (NOS)


DEFINICION DE SISTEMA OPERATIVO DE RED (NOS)


Un sistema operativo de red (Network Operating System) es un componente software de una computadora que tiene como objetivo coordinar y manejar las actividades de los recursos del ordenador en una red de equipos. Consiste en un software que posibilita la comunicación de un sistema informático con otros equipos en el ámbito de una red. Dependiendo del fabricante del sistema operativo de red, tenemos que el software de red para un equipo personal se puede añadir al propio sistema operativo del equipo o integrarse con él. Netware de Novell es el ejemplo más familiar y famoso de sistema operativo de red donde el software de red del equipo cliente se incorpora en el sistema operativo del equipo. El equipo personal necesita ambos sistema operativos para gestionar conjuntamente las funciones de red y las funciones individuales.



Características de los Sistemas Operativos de Red
En general, se puede decir que un Sistema Operativo tiene las siguientes características:
o Conveniencia. Un Sistema Operativo hace más conveniente el uso de una computadora.
o Eficiencia. Un Sistema Operativo permite que los recursos de la computadora se usen de la manera más eficiente posible.
o Habilidad para evolucionar. Un Sistema Operativo deberá construirse de manera que permita el
desarrollo, prueba o introducción efectiva de nuevas funciones del sistema sin interferir con el servicio.
o Encargado de administrar el hardware. El Sistema Operativo se encarga de manejar de una mejor manera los recursos de la computadora en cuanto a hardware se refiere, esto es, asignar a cada
proceso una parte del procesador para poder compartir los recursos.
o Relacionar dispositivos (gestionar a través del kernel). El Sistema Operativo se debe encargar de comunicar a los dispositivos
periféricos, cuando el usuario así lo requiera.
o Organizar datos para acceso rápido y
seguro.
o Manejar las
comunicaciones en red. El Sistema Operativo permite al usuario manejar con alta facilidad todo lo referente a la instalación y uso de las redes de computadoras.
o Procesamiento por bytes de flujo a través del
bus de datos.
o Facilitar las entradas y salidas. Un Sistema Operativo debe hacerle fácil al usuario el acceso y manejo de los dispositivos de Entrada/Salida de la computadora.
o Técnicas de recuperación de errores.
o Evita que otros usuarios interfieran. El Sistema Operativo evita que los usuarios se bloqueen entre ellos, informándoles si esa aplicación esta siendo ocupada por otro usuario.
o Generación de
estadísticas.
o Permite que se puedan compartir el hardware y los datos entre los usuarios.
· Sistemas Operativos de red.
· Son aquellos sistemas que mantienen a dos o más
computadoras unidas através de algún medio de comunicación (fisico o no), con el objetivo primordial de poder compartir los diferentes recursos y la información del sistema.
· El primer Sistema Operativo de red estaba enfocado a equipos con un procesador Motorola 68000, pasando posteriormente a procesadores Intel como Novell Netware.
· Los Sistemas Operativos de red mas ampliamente usados son: Novell Netware, Personal Netware,
LAN Manager, Windows NT Server, UNIX, LANtastic.



SISTEMAS OPERATIVOS DISTRIBUIDOS (OSD)


Definición y objetivos de un sistema distribuido


Existen muchas definiciones y no siempre coincidentes. Nosotros diremos que un sistema distribuido es un cojunto de computadores independientes que se presenta a los usuarios como un sistema único. En esta definición cabe destacar dos aspectos. Uno, el hardware. La definición habla de máquinas autónomas, es decir, que pueden operar sin la supervisión de ninguna otra. Dos, el software, que debe conseguir que los usuarios del sistema lo vean como una máquina central convencional única.

Concepto de Sistemas Operativos distribuidos.
Permiten distribuir trabajos, tareas o procesos, entre un conjunto de procesadores. Puede ser que este conjunto de procesadores esté en un equipo o en diferentes, en este caso es trasparente para el usuario. Existen dos esquemas básicos de éstos. Un sistema fuertemente acoplado es a es aquel que comparte la memoria y un reloj global, cuyos tiempos de acceso son similares para todos los procesadores. En un sistema débilmente acoplado los procesadores no comparten ni memoria ni reloj, ya que cada uno cuenta con su memoria local.



Los sistemas distribuidos deben de ser muy confiables, ya que si un componente del sistema se compone otro componente debe de ser capaz de reemplazarlo.



Entre los diferentes Sistemas Operativos distribuidos que existen tenemos los siguientes: Sprite, Solaris-MC, Mach, Chorus, Spring, Amoeba, Taos, etc.



Aspectos de los Sistemas Operativos distribuidos:
· Colección de sistemas autónomos capaces de comunicación y cooperación mediante interconexiones hardware y software .
· Gobierna operación de un S.C. y proporciona abstracción de máquina virtual a los usuarios.
· Objetivo clave es la transparencia.
· Generalmente proporcionan medios para la compartición global de recursos.
· Servicios añadidos: denominación global, sistemas de archivos distribuidos, facilidades para distribución de cálculos (a través de comunicación de procesos internodos, llamadas a procedimientos remotos, etc.).



Caracteristicas de Sistemas Distribuidos

Hasta aquí nos hemos dedicado a hacer un repaso del hardware sobre el que puede construirse un sistema distribuido y del tipo de software que da al usuario del mismo una vista o apariencia más o menos integrada. En el resto del capítulo vamos a detenernos en los aspectos que hay que considerar en la construcción de un sistema para que pueda ser entendido como realmente distribuido. Estos aspectos son la transparencia, la flexibilidad, la fiabilidad, las prestaciones y la escalabilidad.

Trasparencia

Se dice que un sistema distribuido es trasparente cuando es visto tanto por el usuario como por el programador como un sistema convencional de tiempo compartido. La trasparencia total es difícil de lograr. Parcialmente, el concepto de transparencia puede ser aplicado a varios aspectos de un sistema distribuido.

La transparecia a la ubicación consiste en que los nombres de los recursos no estén ligados a las máquinas concretas. Por ejemplo, en un sistema que sea transparente a la localidad, no se permiten en una llamada al sistema open nombres como maquina1/home/pipo/agenda. La transparencia a la migración es un concepto un tanto más elaborado. Consiste en que los recursos, si bien su nombre no depende de su localización, cuando esta cambia, el nombre del recurso cambia. Consideremos un sistema con dos servidores de ficheros. Los usuarios ven el directorio raíz del primer servidor como el directorio /libros y el segundo como /articulos. Supongamos que en el servidor segundo tenemos el directorio actaInf93, que los usuarios ven como /artículos/actaInf93. El administrador del sistema puede considerar que los artículos del directorio actaInf93, que han sido compilados y editados en una publicación única, deben ser considerados como un libro, de modo que son migrados al otro servidor en el directorio actaInf93. Ahora, el usuario no ve el directorio /articulos/actaInf93 y sí percibe que ha aparecido el directorio /libros/actaInf93. Este cambio en la ubicación física de un directorio ocasiona que el nombre del directorio cambie de nombre. Se puede decir que este sistema de ficheros no es transparente a la migración.

Para aumentar la seguridad de los sistemas, en ocasiones se replican ciertos recursos. La transparencia a la replicación consiste en que el nombre de los recursos debe ser independientes de la réplica concreta. En el ejemplo anterior, el directorio /actaInf93 puede residir en los dos servidores para mayor seguiridad. Sin embargo cada réplica tendría un nombre asociado, bien /artículos/actaInf93, bien /libros/actaInf93. Un sistema de ficheros transparente a la replicación sería aquel en el cual varios servidores dispuestos en un anillo lógico mantuviesen la misma jerarquía de directorios, pero los ficheros no se encuentran en todas las máquinas. El sistema decide en qué máquinas replicar un fichero. Cuando se produce un acceso a un fichero por parte de un proceso, la petición se dirige al primer servidor. Si no está el fichero, la solicitud se redirije al siguiente, etc. El primer servidor que mantenga el fichero atenderá la petición. Lo importante es que el nombre del fichero es independiente de si el fichero está replicado o no, cuántas veces y en qué máquinas.

Otro aspecto de la transparencia es la denominada transparencia a la concurrencia. En ocasiones, en un sistema de tiempo compartido dos procesos acceden al mismo registro de un fichero. El que dicha posibilidad exista no debe influir en la forma que es accedido el fichero en el proceso de usuario. Este sistema de acceso debiera se transparente a la concurrencia.

Sin duda alguna, la transparencia más difícil de alcanzar es la transparencia al paralelismo. Cuando se dispone de más de una UCP, los problemas se pueden descomponer en procesos, cada uno de ellos ejecutando en una UCP y comunicándose a través de mensajes. Esta aproximación exige del programador que conozca de cúantas UCP dispone su sistema y conozca que su programa admite una descomposición en actividades que pueden ser ejecutadas en paralelo. Sería ideal que el compilador del programa y el sistema operativo llevasen a cabo dicha descomposición. Desgraciadamente, el estado actual de los conocimientos en nos sitúa aún muy lejos de lograr la transparencia al paralelismo.

Flexibilidad

Este aspecto se refiere a la forma en que debe ser construido el sistema operativo. Conviven dos escuelas de pensamiento que son las del kernel monolítico y las del sistema operativo basado en microkernel. La primera sostiene que los servicios del sistema deben residir en el sistema operativo y la segunda que es preciso extraer todos los servicios posibles fuera del núcleo del sistema operativo y disponerlos en procesos de usuario, logrando un mayor estructura e independencia en los servicios, que pueden residir en máquinas diferentes. Hoy en día el kernel monolítico domina el mundo de los sistemas operativos, pero parece que el futuro se impondrá la filosofía microkernel, debido a su mayor flexibilidad. Para obtener un servicio, un proceso de usuario envía un mensaje al servidor adecuado. El kernel sólo se ocupa de realizar el paso del mensaje y es el proceso de usuario quien realiza el trabajo cuado recibe el mensaje. Es la facilidad para añadir, suprimir y modificar los servicios los que que da la flexibilidad al sistema microkernel. Por ejemplo, puede fácilmente disponerse de dos sistemas de ficheros, UNIX, donde los discos mantienen la asignación de los ficheros en i-nodos y MS-DOS, donde los discos mantienen la FAT. Con un kernel monolítico, el sistema de ficheros es el que es y no puede modificarse. La única ventaja de los kernel monolíticos sobre los microkernels es su mayor velocidad debido a la ausencia de tráfico de mensajes. Sin embargo, en los sistemas operativos distribuidos existen otros factores a considerar además del tráfico de mensajes que minimizan el impacto de estos en las prestaciones del sistema global, de modo que en un futuro previsible se impondrán los sistemas microkernel.

Fiabilidad

Una de las motivaciones originales para tratar de construir sistemas distribuidos fue el aumento de la fiabilidad del sistema. En un sistema con cien UCP's el fallo de uno de ellas no tendrá consecuencias graves, por que su trabajo será realizado por las otras. En un sistema en el que el sistema de ficheros se reparte en cuatro servidores, cada uno de ellos con una probabilidad de que en un instante dado sea inoperativo de 0.05, la probabilidad de que el sistema de ficheros completo no sea operativo es de 0.054 = 0.000006. No obstante, esta es sólo parte de la verdad. Una cita muy famosa de Leslie Lamport define un sistema distribuido como aquel en el que nunca se puede hacer nada porque siempre necesita de un servicio que presta una máquina que uno nunca sabe donde está que se ha estropeado. Así, el ejemplo anterior puede interpretarse del siguiente modo. Ya que la probabilidad de que uno de los servidores esté disponible es del 0.95, la probabilidad de que un proceso que necesite acceder a los cuatro servidores pueda ejecutarse es de 0.954 = 0.84.

La fiablilidad tiene varios aspectos. Uno es la disponibilidad, que es la fracción de tiempo en que el sistema es operativo. La disponibilidad aumenta cuando no es preciso que muchos componentes críticos del sistema necesiten estar operativos simultáneamente, pero desde luego la clave para garantizar la disponibilidad es la replicación de los componentes, sean software o hardware. Si uno falla, otro estará disponible. La redundancia, no obstante, acarrea otros problemas. Entre ellos está la consistencia de los datos. A mayor número de copias, mayor es la probabilidad de que se produzcan inconsistencias, especialmente si al número de escrituras es muy alto.

Otro aspecto de la fiablidad es el de la seguridad de los datos, que deben ser protegidos contra accesos no autorizados que los corrompan o eliminen. La problema de seguridad crece en los sistemas distribuidos debido al aumento del número de mensajes que circulan por las líneas de comunicación, que pueden ser interceptados e impostados por máquinas ajenas al sistema. Supongamos un sistema distribuido formado por las máquinas A, B, C y D. Si la máquina F tiene acceso a las líneas de comunicación, F puede enviar un mensaje a A solicitándola un servicio como puede ser el acceso a determinado registro de datos confidencial. En el campo del mensaje que determina la máquina fuente siempre puede insertar el nombre de la máquina B. La máquina A no tiene medio de saber que el mensaje ha sido impostado y contesta a la máquina B. Este mensaje también es interceptado o leído por la máquina F.

Prestaciones
Por muy brillantemente que hayan sido resueltos los objetivos de transparencia y fiabilidad de un sistema operativo distribuido, este no tendrá éxito si es lento. La velocidad de los sistemas distribuidos viene comprometida por el tráfico de mensajes en las líneas de comunicación. En una red local, el envío de un mensaje puede llevar alrededor de un milisegundo. La mayoría de este tiempo se gasta en la ejecución de los protocolos de comunicacióne en ambos extremos de la línea. El aumento de velocidad pasa necesariamente por minimizar el número de mensajes intercambiados. Por una parte, el descomponer un problema en actividades que pueden ser ejecutadas en paralelo y asignarlas a distintos procesadores es la mejor manera de resolver el problema de forma eficiente. Por otra parte, a mayor número de procesadores, mayor es el número de mensajes intercambiados. Aparece así el concepto de la granularidad de los cálculos. El problema de sumar cuatro enteros puede ser descompuesto en dos subproblemas. El primero es sumar los dos primeros números y el segundo el sumar los dos últimos. Desde luego no merece la pena el solicitar un servicio remoto para sumar dos enteros por que el costo de las comunicaciones es incomparablemente mayor que el ahorro de tiempo conseguido en su ejecución simultánea. En general, se puede decir que un sistema operativo distribuido dará pocas prestaciones en problemas de granularidad fina, es decir aquellos en que muestran muchos cálculos pequeños que se comunican intensamente. Si son apropiados en la resolución de problemas de granularidad gruesa, aquellos que exiben unos pocos bloques de cálculo independientes y pocas necesidades de comunicación.

Escalabilidad
A pesar de los progresos de los últimos años, con sistemas concretos y desarrollados, el diseño de sistemas operativos distribuidos es un campo aún poco conocido e investigado. Los actuales sistemas abarcan como máximo unos cientos de máquinas. A medida que la informática se introduce en las actividades cotidianas y el ordenador se introduce en los hogares, comienzan a perfilarse sistemas de miles de millones de máquinas. La pregunta que se plantea es la siguiente. ¿Los métodos y algoritmos utilizados en los sistemas operativos distribuidos actuales son apropiados, es decir, escalan adecuadamente cuando el número de componentes aumenta en órdenes de magnitud?

Aunque se sabe aún muy poco acerca de estos enormes sistemas futuros, una cosa parece estar clara: hay que evitar componentes, estructuras de datos -tablas, etc- y algoritmos que operen de forma centralizada. En cuanto a los componentes o máquinas, es posible tener un único servidor que atienda a cuatro cientos millones de hispanohablantes, pero más vale repartir su carga de trabajo entre otros servidores a fin de paliar los esfectos de una interrupción del servicio. En cuanto a las tablas, se puede mantener los números de teléfono de cuatrocientos millones de personas en una sóla máquina. Supongamos un registro de 50 caracteres. El listado total requiere un almacenamiento de 50 * 4 * 108 = 20 * 109 = 20 Gbytes, que puede soportar incluso una única unidad de disco. No obstante, concentrar las peticiones en está máquina saturaría no sólo su UCP sino las líneas de comununicación que salen y entran en el sistema.

Centralizar algoritmos tampoco es una buena idea. En un sistema distribuido grande, una cantidad enorme de mensajes debe ser encaminada a lo largo de muchas líneas y máquinas. La forma más eficiente de hacer esto es recabar periódicamente toda la información de la carga de todas las líneas y máquinas en una máquina central. Con la información obtenida esta máquina calculará todas las rutas óptimas empleando un algoritmo de teoría de teoría de grafos. Sus resultados serán después extendidos al resto de las máquinas del sistema. Una máquina única prestando servicios a demasiados clientes hemos visto que es inadecuada. En general, algoritmos que exijan el requerir información a todos los componentes, realizar cálculos con la información recabada y después distribuir los resultados deben ser evitados. Sólo deben usarse algoritmos descentralizados, que tienen las siguientes características.

· 1. Ninguna máquina tiene información completa acerca de todo el sistema.
· 2. Las máquinas toman decisiones basadas sólamente en información local.
· 3. El fallo de una de las máquinas no malogra el algoritmo.
· 4. No existe un reloj común.

Este último aspecto quizás se entienda peor. En una red local, las máquinas se pueden sincronizan en un intervalo del milisegundo, pero sincronizar máquinas a nivel nacional, por ejemplo, es más complicado.












Autor: Lic. Marcos Guadalupe Ventura Osorio 261-v TESCI 2009

2 Comments


GRACIAS LIC. ME FACILITO LA TAREA <3

Publicar un comentario en la entrada

Copyright © 2009 SISTEMAS OPERATIVOS II All rights reserved. Theme by Laptop Geek. | Bloggerized by FalconHive.