CURSO SISTEMAS DISTRIBUIDOS

Transcripción

1 CURSO SISTEMAS DISTRIBUIDOS 1

2 1. Introducción: 1.1. Fundamentos: Qué es un Sistema Distribuido? Antes de definir lo que es un Sistema Distribuido, vamos a definir un término más general: La Computación Distribuida, podemos definirla de muchas maneras, este término se utiliza indiscriminadamente para referirse a cualquier sistema en el que múltiples agentes autónomos, cada uno con capacidades de cómputo individual, se comunican entre sí y afectan mutuamente su comportamiento. Los agentes, usualmente llamados procesadores, procesos o nodos, pueden ser desde computadoras completas hasta autómatas celulares con capacidad de cómputo y memoria muy limitados que se pueden comunicar mediante mensajes. La Computación Distribuida hace referencia a cualquier evento en el cual se maneja un sistema en una red de computadoras y trata de describir las tendencias hacia la funcionalidad distribuida: sistemas distribuidos, procesamiento distribuido, bases de datos distribuidas y cualquier otro término computacional que sea distribuido. Podemos decir entonces, que la Computación Distribuida se refiere a los servicios que provee un Sistema de Computación Distribuido. Una de las primeras caracterizaciones de un Sistema Distribuido fue realizada por Enslow, ya en 1978, que le atribuye las siguientes propiedades: o Está compuesto por varios recursos informáticos de propósito general, tanto físicos como lógicos, que pueden asignarse dinámicamente a tareas concretas. o Estos recursos están distribuidos físicamente, y funcionan gracias a una red de comunicaciones. o Hay un sistema operativo de alto nivel, que unifica e integra el control de los componentes. o El hecho de la distribución es transparente, permitiendo que los servicios puedan ser solicitados especificando simplemente su nombre (no su localización). o El funcionamiento de los recursos físicos y lógicos está caracterizado por una autonomía coordinada. A pesar del tiempo transcurrido, esta definición sigue siendo, en esencia, válida. Así, para Coulouris un sistema distribuido es aquél que está compuesto por varias computadoras autónomas conectadas mediante una red de comunicaciones y equipadas con programas que les permitan coordinar sus actividades y compartir recursos. Bal ofrece una definición muy similar: ``Un sistema de computación distribuida está compuesto por varios procesadores autónomos que no comparten memoria principal, pero cooperan mediante el paso de mensajes sobre una red de comunicaciones''. Y según Schroeder, todo sistema distribuido tiene tres características básicas: 2

3 o Existencia de varias computadoras. En general, cada una con su propio procesador, memoria local, subsistema de entrada/salida y quizás incluso memoria persistente. o Interconexión. Existen vías que permiten la comunicación entre las computadoras, a través de las cuales pueden transmitir información. o Estado compartido. Las computadoras cooperan para mantener algún tipo de estado compartido. El funcionamiento correcto del sistema se describirse como el mantenimiento de una serie de invariantes globales que requiere la coordinación de varias computadoras. Como lo hemos observado, el término de Computación Distribuida se define de varias maneras y lo mismo se aplica al término de Sistema Distribuido, así que en lugar de seguir dando más definiciones de estos términos, nos concentraremos en el análisis de las características más importantes de los, de esta manera podremos construir una definición propia de lo que es un Sistema Distribuido al finalizar este capítulo. Una característica muy importante es que las diferencias entre las computadoras y las maneras en que estas se comunican no son transparentes para el usuario final, esto mismo aplica para la organización interna del sistema distribuido. Otra característica importante es que los usuarios y las aplicaciones pueden interactuar con un Sistema Distribuido de manera consistente y uniforme, sin importar donde y cuando se lleve a cabo la interacción. Todo Sistema Distribuido bebe también ser relativamente fácil poder expandir, lo cual se logra al tener computadoras independientes, pero al mismo tiempo esconder las funciones de dichas computadoras en el sistema. Normalmente un sistema distribuido debe de estar siempre disponible a pesar de que ciertas partes que lo conforman puedan no estar funcionando. Los usuarios y las aplicaciones no deben de notar en ningún momento que estas partes están siendo reemplazadas o reparadas, o que se han agregado nuevas partes al sistema para poder dar servicio a más usuarios o aplicaciones. Características de un Sistema Distribuidos: Cualquier diseñador de sistemas debe tener los conocimientos necesarios para enfrentarse a todas las complicaciones que pueden surgir al momento de considerar los requerimientos para el desarrollo de un sistema distribuido. A continuación explicaremos cada una de las características de los Sistemas Distribuidos, según Coulouris son estas características, los desafíos que presentan los sistemas distribuidos. a) Heterogeneidad: Al hablar de heterogeneidad nos referimos a la variedad y diferencia que podemos encontrar en los elementos que componen una red de computadoras sobre la que se ejecuta un sistema distribuido, dicha heterogeneidad no sólo se aplica a las redes y al hardware de las computadoras, sino también a los 3

4 sistemas operativos, los lenguajes de programación y las implementaciones en las que trabajan los diferentes desarrolladores. Un ejemplo de esto lo podemos ver muy claro en Internet, ya que es una red que esta conformada por muchos tipos de redes (Figura 1) cuyas diferencias se encuentran enmascaradas, puesto que todas las computadoras que se conectan a este utilizan los protocolos de Internet para comunicarse una con otra, así una computadora conectada a una red Ethernet puede comunicarse con otra computadora conectada a una red TokenRing, basta con que se haga una implementación de los protocolos de Internet para cada una de esas redes. Figura 1. Un esquema clásico de la conexión a Internet Otro ejemplo lo podemos ver en los lenguajes de programación y en las aplicaciones escritas por diferentes programadores; en el caso de los lenguajes de programación es importante tener en cuenta las diferencias que puede haber en la representación de los caracteres y estructuras de datos como cadenas de caracteres y registros, las cuales pueden variar y pueden ocasionar conflictos entre programas que necesitan comunicarse entre ellos. De igual manera dos programas que son desarrollados por programadores diferentes tienen que utilizar estándares comunes para la comunicación en red y para la representación de los datos elementales y las estructuras de datos en los mensajes, ya que si no se cuenta con dichas similitudes, los programas no podrán comunicarse entre sí aunque se hayan desarrollado en el mismo lenguaje de programación. Un término que no podemos dejar de mencionar al hablar de heterogeneidad es el de Middleware (Figura 2); este término se aplica a la capa de software que provee una abstracción de programación, así como un enmascaramiento de la heterogeneidad subyacente de las redes, hardware, sistemas operativos y lenguajes de programación; además, el Middleware proporciona un modelo computacional uniforme al alcance de programadores de servidores y 4

5 aplicaciones distribuidas que permite la invocación sobre objetos remotos, notificación de eventos remotos, acceso a bases de datos remotas y procesamiento distribuido de transacciones. Algunos ejemplos de Middleware son CORBA y Java RMI. Figura 2. Un sistema distribuido organizado como Middleware Otro término importante para este apartado es el de código móvil, que se emplea para referirse al código que pude ser enviado de una computadora a otra para que esta última la ejecute, un ejemplo de un código móvil son los applets de java, que son enviados del servidor a la computadora del cliente para que este los ejecute en su explorador de Internet. Al implementar un código de este tipo podemos encontrarnos con el problema de que el conjunto de instrucciones (a nivel máquina) de una computadora puede no ser el apropiado para otra máquina, por ejemplo, un usuario de una PC puede enviar un archivo ejecutable a un usuario de Linux y este último no será capaz de ejecutar dicho archivo. Para solucionar este problema se han creado lo que se conocen como máquinas virtuales, las cuales proveen un modo de crear código ejecutable sobre cualquier hardware, ya que el compilador de un lenguaje concreto generará un código para una máquina virtual y esta se encargará de traducir dicho código al apropiado para un hardware particular, así, un compilador de Java producirá un código para la máquina virtual de Java, y esta última sólo necesitará ser implementada una sola vez para cada máquina en la que se va a ejecutar. b) Extensibilidad y Apertura: La extensibilidad y la apertura son dos características de un sistema distribuido que están ampliamente ligadas la una con la otra. Algunos autores dicen que un sistema abierto debe de ser extensible y otros sostienen que un sistema extensible puede ser etiquetado como un sistema abierto. De cualquier manera lo que es importante saber y tener en cuenta es que un sistema distribuido debe de contar con ambas características. Un sistema distribuido abierto es un sistema que ofrece servicios desarrollados de acuerdo a reglas estandarizadas que describen la sintaxis y la semántica de dichos servicios. Por ejemplo, en una red de computadoras, estas reglas son las que regulan el formato, contenido y significado de los mensajes que se envían y se reciben a través de dicha red. Estas reglas son 5

6 formalizadas en protocolos. En el caso de los sistemas distribuidos, los servicios se especifican generalmente a través de interfaces que por lo general son descritas en un Lenguaje de Definición de Interfaz (IDL por sus siglas en ingles), dicho lenguaje especifica los nombres de las funciones que están disponibles así como los parámetros de entrada, los valores de salida y los posibles errores que pueden obtenerse al invocarse dichas funciones. Si la definición de una interfaz se hace de manera adecuada, esta permitirá que dos procesos puedan comunicarse entre sí, siempre y cuando ambos procesos cuenten con la misma interfaz. Esto también permite que cada dos desarrolladores independientes construyan su propia implementación de dichas interfaces, lo cual conlleva al desarrollo de dos sistemas distribuidos desarrollados por separado que operan de la misma manera. Una especificación se considera adecuada cuando es completa y neutral. Completa significa que todo lo necesario para hacer una implementación de la interfaz ha sido especificado y que no será necesario que el propio desarrollador sea quien agregue detalles específicos de la implementación. Neutral significa que las especificaciones no deben tener ninguna tendencia hacia como se debe de hacer la implementación de dicha especificación. La completitud y la neutralidad son muy importantes para la interoperabilidad y la portabilidad, que son características que complementan la apertura de un sistema distribuido. La interoperabilidad, también conocida como compatibilidad, caracteriza el grado en el que la implementación de sistemas o componentes de diferentes fabricantes pueden coexistir y trabajar juntos, siempre y cuando se utilicen los servicios como este especificado por el estándar común bajo el cual dichos sistemas fueron desarrollados. La portabilidad por su parte caracteriza a que nivel puede ser ejecutada una aplicación desarrollada para un sistema distribuido A sobre un sistema distribuido B que implementa las mismas interfaces del sistema A, pero sin hacerle modificaciones. Uno de los principales objetivos que se persiguen al desarrollar un sistema operativo abierto, es que este sea flexible, lo que implica que dicho sistema puede ser integrado por diferentes componentes (tanto de hardware como de software), posiblemente de diferentes proveedores, que nuevos componentes pueden agregarse al sistema y que componentes existentes pueden ser reemplazados sin afectar el funcionamiento de los componentes ya existentes, en otras palabras, un sistema distribuido abierto debe de ser extensible. Para lograr la flexibilidad en un sistema distribuido abierto es necesario que el sistema este organizado en módulos o componentes relativamente pequeños y fáciles de reemplazar, esto implica que además de definir las especificaciones y la documentación de las interfaces de alto nivel a las que tienen acceso los usuarios y las aplicaciones, también es necesario definir las especificaciones de las interfaces de las partes internas que componen el sistema y describir de que manera interactúan entre sí. 6

7 c) Seguridad: La gran mayoría de la información que maneja un sistema distribuido tiene un alto valor para los usuarios de dicho sistema, y es por eso que la seguridad de la información juega un papel clave al momento de desarrollar dicho sistema. La seguridad de la información es todo lo que concierne a asegurar que no ocurrirán cosas malas con los mensajes que envían los clientes para solicitar información a un servidor, y por su puesto, con la información que estos reciben como respuesta a sus peticiones. No basta con asegurar que estos mensajes serán transmitidos de forma oculta, sino que también hay que asegurar que la información sea entregada únicamente a quien debe de ser entregada y que esto se hará siempre de forma correcta y en el momento en que se requiere. La seguridad es relativa a la amenaza que cada sistema afronta, afecta a todos los puntos del sistema y debe de ser fácil de obtener. La seguridad debe ofrecer los siguientes servicios: o Confidencialidad, es decir, el manejo privado de la información: proteger la información de ser accedida por usuarios no autorizados. o Autentificación, o capacidad de asegurar la identidad de un usuario. o Integridad, que asegura que la información que empleamos no ha sido manipulada, alterada o corrompida desde el origen. o No repudio, de una operación de emisión y recepción de información por parte de los agentes. o Control de acceso a la información y/o recursos administrados por un sistema. o Disponibilidad de los recursos necesarios de un sistema cuando estos sean requeridos, lo que protege la información contra interferencia con los procedimientos de acceso a los recursos. El alto valor de que tiene la información es la razón principal por la que esta se puede ver amenazada de muchas formas, entre las principales podemos encontrar: Interrupción: Destruye la información o la inutiliza. Ataca la disponibilidad. Interceptación: Obtiene acceso a información. Ataca la confidencialidad. 7

8 Modificación: Modifica la información. Ataca la integridad. Fabricación: Falsifica la información. Ataca la autenticidad. Para defenderse de este tipo de amenazas se han desarrollado diversas técnicas de encriptación, firmas digitales, implementación de barreras perimetrales (firewalls), modelos de seguridad internos y externos, etc. Sin embargo, estas técnicas parecen no ser suficientes para evitar que intrusos logren interferir con el flujo de información óptimo de un sistema, ya que encuentran formas de brincarse las barreras de seguridad de muchas organizaciones y además siguen ideando nuevas formas de atacar y amenazar la información, un ejemplo de estos nuevos ataques son los ataques de denegación de servicio. Estos ataques consisten en bombardear un servicio con un gran número de peticiones simultáneas (y por lo general inútiles) de modo que el sistema se colapse, obstaculizando el servicio a los usuarios que desean utilizarlo. Como hoy en día la capacidad de los sistemas distribuidos ha crecido mucho, en ocasiones resulta muy difícil o incluso imposible bloquear el servicio utilizando una sola computadora atacante, por lo que ahora se han desarrollado los ataques de denegación de servicio distribuidos, los cuales hacen uso de miles o incluso millones de computadoras para generar las peticiones al sistema que se desea bloquear, por lo que bloquear un ataque de esta magnitud resulta sumamente complicado. Si bien no podemos asegurar que un sistema distribuido sea cien por ciento seguro, es importante contar con un esquema de seguridad lo más robusto posible, que a pesar de no ser inmune a todo tipo de ataques, si será capaz de frenar la gran mayoría de dichos ataques. Algunas recomendaciones muy útiles para los desarrolladores, administradores e implementadotes de un sistema distribuido se presentan a continuación: 8

9 o Efectuar un análisis de riesgos Esto se suele mencionar en la literatura como el primer paso a realizarse cuando se plantea la seguridad en un sistema. La idea es muy sencilla: trazar todos los elementos que conforman nuestro sistema (hardware y software) y observar cuáles involucran más o menos riesgo. Esto desembocará en un plan de seguridad cuyo objetivo es disminuir el riesgo total del sistema, que se puede modelar como la suma de los riesgos de sus componentes: RIESGO TOTAL = RIESGO (componente 1) + RIESGO (componente 2)... El riesgo de cada componente está en función directa a las pérdidas que ocasionaría el que éste deje de operar, así como en función de cuán vulnerable es dicho componente en este momento. Por ejemplo, una base de datos de clientes involucra un gran riesgo debido al gran valor que la información representa para una organización; pero una simple PC Windows de la misma organización conectada directamente al Internet (sin firewall/proxy de por medio) también lo representa, debido a que puede ser objeto de un ataque desde el exterior, con el posible riesgo de fácil propagación hacia otros computadores de nuestra red. o Lo más valioso debe alejarse de lo más vulnerable En la fórmula del "riesgo" propuesta arriba, es evidente que los componentes de nuestro sistema con alto valor y alta vulnerabilidad serán de lejos los que presenten mayor riesgo. Sin embargo, en muchos casos no es sencillo disminuir el valor de cierto componente (y por tanto la pérdida en caso de problemas), y tampoco se puede eliminar completamente la vulnerabilidad del mismo (por ejemplo, si está de cara a Internet.) En este caso lo que conviene es separar o dividir este componente en dos partes suficientemente alejadas e independientes a fin de que el riesgo total disminuya. Por ejemplo, los portales de comercio electrónico deben dar cara a Internet (siendo vulnerables en principio) y a la vez manejar información muy costosa (como transacciones con tarjeta de crédito.) Esto los convierte en un sistema de alto riesgo. Sin embargo es casi universal la separación que se efectúa entre los componentes dedicados a dar cara a Internet (como los Web Servers) y los componentes que manipulan la información comercial (generalmente sistemas DBMS.) En términos prácticos, esto significa que el hacker no puede acceder directamente al DBMS (lo que sería catastrófico), y sólo podría atacar al Web Server, lo que en principio no acarrea mayores consecuencias. o Mantener las cosas simples Un sistema complejo es más difícil de asegurar y potencialmente proporciona una mayor cantidad de puertas abiertas a los atacantes. En general, es recomendable intentar dividir el problema mediante la 9

10 simplificación de la configuración, para así identificar los puntos o rutas de control vulnerables para incrementar la seguridad. La seguridad debe estar en todos los niveles. Esto se puede expresar más sencillamente como: no confiar el sistema a un único mecanismo de seguridad. La información fluye a través de los distintos componentes y/o capas del sistema y son muchas las instancias en las que se puede mejorar su seguridad. La recomendación estipula que utilicemos todas estas instancias a pesar de que en principio puedan parecer redundantes. Por lo general los administradores tienden a preocuparse por un único punto de acceso desde donde supuestamente hay una gran probabilidad de ser atacados (por ejemplo, la conexión a Internet.) Por tanto se invierte esfuerzo y dinero en controlar este único punto bajo la asunción de que es la única puerta de entrada a los maleantes y que por tanto, tras asegurarla, todo el sistema quedará seguro. Esto tiene dos problemas: Muchos ataques o "vulnerabilidades" se originan (de forma inocente o intencional) desde dentro de la organización. El sistema que controla la "puerta" siempre puede fallar. Esto obliga a implementar la seguridad no en un único punto evidentemente vulnerable, sino en todos los lugares por donde fluye la información al interior de cada componente involucrado. Encriptar tanto como sea posible La encriptación es un tema complejo pero cuya implementación resulta cada vez más sencilla conforme aparecen más productos. Los cambios del año pasado en la legislación norteamericana con respecto a la exportación de productos que encriptan, son un incentivo claro para que los desarrolladores y vendedores se interesen más en el tema. En general, los canales de comunicación más vulnerables o de mayor cercanía al público requieren una encriptación "más fuerte", es decir, más difícil de descifrar por los curiosos o atacantes. Cierta información conlleva más riesgo que otra, y por tanto requerirá un nivel de encriptación diferenciado. Las herramientas capaces de hacer esto son muchas, dependiendo del contexto en que nos encontremos. Por ejemplo, los sistemas DBMS más avanzados incorporan la encriptación como una opción normal para los datos almacenados, generalmente bajo esquemas propietarios. La tecnología de encriptación de información destinada a pasar a través de la red ha evolucionado bastante, haciéndose popular el término VPN para hacer referencia a canales que encriptan la información de un modo más o menos 10

11 transparente. Hay soluciones propietarias así como estándares relativamente implementados como IP Sec. Ciertas aplicaciones estándares han recibido soluciones de encriptación también estándar. El caso del Web encriptado bajo SSL (HTTPS) junto con la industria de certificados digitales es el caso más conspicuo. De igual modo los estándares para correo electrónico PGP (o derivados) y S/MIME son integrados cada vez con mayor frecuencia en las aplicaciones de los usuarios finales. En nuestra organización deberíamos encriptar todo lo que sea posible. La razón de esto es evidente si de lo que se trata es de enviar un mensaje privado por Internet. Sin embargo, al interior de la organización la encriptación puede ayudar también. Naturalmente hay que sopesar los inconvenientes que trae la encriptación en términos de incomodidad de uso, costo de licencias, ciclos de CPU, etcétera; con el hecho de que cierta información es definitivamente de carácter público y por tanto no tiene sentido que esté encriptada. Además de estas hay muchas más recomendaciones de seguridad que podemos mencionar, por ejemplo: no confiar en la autenticación estándar, no usar la configuración "estándar", educar a los usuarios, ejecutar sólo los servicios imprescindibles, mantenerse al día con las actualizaciones y hacer chequeos regulares, establecer planes de contingencia y sistemas de respaldo, mantener contacto con el proveedor de líneas de comunicación, no permitir conexiones directas desde la red interna a Internet, hacer uso de una red perimétrica o zona desmilitarizada, prácticas de programación segura, vigilancia, establecimiento de políticas, etc. d) Escalabilidad: La escalabilidad es una de las características más importantes para los desarrolladores de un sistema distribuido. Se dice que un sistema es escalable si logra conservar su efectividad cuando hay el número de recursos y el número de usuarios incrementa significativamente. La escalabilidad de un sistema pude medirse en tres aspectos diferentes: Con respecto a su tamaño: lo que significa que se pueden agregar más usuarios y más recursos al sistema de una manera muy fácil. Con respecto a su localización o área de implementación: lo que significa que tanto los usuarios como los recursos pueden estar en locaciones remotas y separadas el uno del otro. Con respecto a su administración: lo que significa que puede ser fácil de administrar a pesar de que se utiliza en diferentes organizaciones independientes que cuentan con diferentes políticas de seguridad y que hacen un uso particular del sistema. Desafortunadamente, un sistema que es escalable en uno o más de estos aspectos por lo general afecta el rendimiento del sistema conforme al crecimiento del mismo. 11

12 Problemas de la Escalabilidad Cuando se necesita escalar un sistema a un nivel más alto es muy común que surja algún tipo de problema. Si consideramos la escalabilidad con respecto al tamaño de un sistema, nos encontramos con las limitaciones que presentan los servicios, los datos y los algoritmos centralizados. En muchos sistemas distribuidos es común encontrar servicios centralizados, es decir, que son implementados en un mismo servidor, lo que puede ocasionar un problema muy obvio: este servidor puede convertirse en un cuello de botella si el número de usuarios crece, y a pesar de tener una capacidad de procesamiento y almacenamiento virtualmente ilimitada, la comunicación con este servidor puede llegar a tener un límite y eventualmente impedir el crecimiento del sistema. Desafortunadamente el uso de un sólo servidor puede ser inevitable, ya que por lo general tenemos servicios que trabajan con información muy sensible y que tiene que ser lo más segura posible, por lo que el tener esta información almacenada en diferentes servidores puede llegar a poner la información en riesgo y hacer el sistema más vulnerable. De la misma manera, el almacenamiento centralizado de la información puede ser un grave problema para un sistema distribuido, ya que a pesar de que un sólo servidor nos puede ofrecer la capacidad de almacenamiento que necesitamos, es muy poco probable que dicho servidor permita el acceso simultáneo a miles o incluso millones de usuarios que desean consultar la información almacenada en él. Un ejemplo de esto es el Sistema de Nombre de Dominio, que a pasar de poder almacenar todos los registros en una sola base de datos de varios gigabytes, no podría dar una respuesta a los millones de usuarios de Internet que accedan este servicio simultáneamente. El uso de algoritmos centralizados es en teoría la solución óptima a un problema de computación distribuida, sin embargo, en la práctica podemos ver que el uso de este tipo de algoritmos en un sistema distribuido grande no es una buena idea, ya que colectar y transportar los datos de entrada y salida del sistema hacia un sólo punto en el que se computan dichos datos pudiese sobrecargar parte de la red con todos los mensajes que necesita enviar y recibir, además de que el computo de toda la información en una sola máquina tiene más riesgo a fallos y puede resultar más tardada. La solución a este problema es el uso de algoritmos descentralizados, los cuales cuentan con ciertas características que los diferencian de los algoritmos centralizados, entre las que podemos mencionar: Ninguna máquina tiene información completa del estado del sistema. Cada máquina toma decisiones propias basándose solamente en información local. Problemas o fallos de una máquina no arruinan el procesamiento de todo el algoritmo. 12

13 No necesariamente se cuenta con un reloj global (algoritmos no sincronizados). A pesar de que en una LAN pudiese sincronizarse la ejecución de un algoritmo descentralizado, este mismo procedimiento pudiese ser muy complicado o incluso imposible si el algoritmo esta distribuido en una red más amplia, por lo que no se debe de depender en la existencia de un reloj global para hacer posible la ejecución de un algoritmo de este tipo. Por otro lado tenemos los problemas de la escalabilidad con respecto a la localización o área de implementación de un sistema distribuido. Una de las principales razones por las cuales resulta difícil escalar los sistemas distribuidos que existen actualmente, es que dichos sistemas fueron diseñados para trabajar redes de acceso locales (LANs) y que están basados en una comunicación síncrona. En este tipo de comunicación el cliente hace la solicitud de un servicio y hace un bloqueo de la comunicación hasta que recibe la respuesta. Este acercamiento por lo general trabaja bien en LANs en las que la comunicación entre dos máquinas por lo general no toma más de algunos cientos de microsegundos. En el caso de las WANs, tenemos que tomar en cuenta que la comunicación entre los procesos pudiese tomar varios cientos de milisegundos, lo que representa un alentamiento muy considerable del sistema. Otro problema a considerar es que la comunicación en una WAN es poco confiable y en la gran mayoría de los casos es punto a punto, al contrario de las redes locales que generalmente son muy confiables y permiten hacer difusiones o transmisiones de tipo broadcast, lo que hace mucho más fácil el desarrollo de sistemas distribuidos. La escalabilidad con respecto a la localización o área de implementación esta directamente relacionada con los problemas de soluciones centralizadas comentados anteriormente. Si tenemos un sistema con muchos componentes centralizados, es muy claro que la escalabilidad del área de implementación será imitada gracias a los problemas de desempeño y confiabilidad que trae consigo la implementación en un área de redes extensa. Además, los componentes centralizados también provocan el desperdicio de recursos de red. Finalmente, podemos mencionar los problemas que acarrea la escalabilidad de la administración de un sistema distribuido. Este problema se da cuando un sistema distribuido de expande a otro dominio, que por lo general contará con diferentes políticas de uso y pago de recursos, administración y seguridad. Por lo general cuando esto pasa se deben de tomar al menos dos tipos de medidas de seguridad: El sistema distribuido tiene que protegerse de ataques malignos provenientes del nuevo dominio, y restringir el acceso a los servicios y datos que no están a disponibilidad de los usuarios del mismo. 13

14 El nuevo dominio tiene que protegerse de ataques malignos provenientes del sistema distribuido. Básicamente, el nuevo dominio no sabe que tipo de información puede esperar del código enviado por el nuevo dominio por lo que pudiera decidir limitar los permisos de acceso a dicho código. Técnicas de Escalabilidad Una vez que mencionamos ya los problemas de la escalabilidad, analizaremos algunas maneras de solucionar dichos problemas. Como los problemas de escalabilidad de los sistemas distribuidos se manifiestan como problemas de rendimiento causados por la capacidad limitada de servidores y de las redes de comunicaciones, existen solamente tres técnicas de escalabilidad: eliminar la latencia de las comunicaciones, distribución y replicación. Eliminar la latencia de las comunicaciones es útil en el caso de querer lograr la escalabilidad geográfica de un sistema, la idea básica es simple: tratar de evitar la espera de respuestas a las peticiones que se hagan a servicios remotos lo más que se pueda. Esencialmente, esto significa que se tiene que construir la aplicación que realiza las peticiones de tal manera que use solamente métodos de comunicación asíncronos, es decir, que el cliente envía la petición al servidor, mientras espera la respuesta el cliente aprovecha ese tiempo para realizar tareas locales más importantes y cuando recibe la respuesta del servidor, el proceso que se estaba realizando se interrumpe y se atiende la respuesta recibida. Esta solución parece fácil, sin embargo, hay muchas aplicaciones que no pueden hacer un uso efectivo de la comunicación asíncrona, por ejemplo, aplicaciones interactivas en las que el usuario no tiene nada mejor que hacer más que esperar la respuesta del servidor, por que esta se tiene que dar lo más rápido que sea posible. En dichos casos, es mucho mejor solucionar el problema de la latencia reduciendo el tráfico generado entre el cliente y el servidor cuando se comunican entre sí; esto lo podemos lograr moviendo parte de la computación que normalmente se hace del lado del servidor al cliente, para que así sea el mismo proceso que hace la solicitud del servicio quien tenga que procesarlo. Otra técnica importante para lograr la escalabilidad es la distribución, que consiste en tomar un elemento, separarlo en partes pequeñas y distribuir esas partes en todo el sistema. Un ejemplo de un sistema distribuido que hace uso de la distribución es el servicio de nombre de dominio (DNS), el cual esta distribuido en diferentes servidores que permiten el acceso a la misma información a todos los usuarios, sin necesidad de tener un sólo servidor que proporcione este servicio. En la mayoría de los casos, los problemas de escalabilidad los vemos reflejados en el rendimiento del sistema, por lo que generalmente la replicación de los componentes del sistema distribuido puede resultar ser una buena idea. La replicación aumenta la disponibilidad de los componentes del sistema y además ayuda a balancear la carga entre los componentes que se replican, con lo que se logra una mejora del rendimiento del sistema. Si consideramos un sistema que se encuentra distribuido en una red muy 14

15 extensa, el hecho de tener una copia de algún componente más cerca, también mejora el rendimiento del sistema puesto que soluciona los problemas de latencia de las comunicaciones que ya mencionamos anteriormente. Una forma especial de replicación es el Cacheo, el cual consiste en guardar una copia de algún recurso (por lo general, de datos) de forma temporal en un lugar cercano al cliente, para que éste lo pueda acceder más fácilmente. En contraste con la replicación, el cachear un recurso es una decisión que es tomada por el cliente, y no por los diseñadotes del sistema. Un problema muy serio que puede traer el cacheo, es que las copias que se hacen del recurso (o de datos) pueden no actualizarse a su debido tiempo, por lo que al haber varias copias diferentes del mismo recurso, lo que provoca problemas de consistencia dentro del sistema; el nivel de inconsistencia que pueda ser tolerado por un sistema depende del uso que se le da a al recurso que se esta replicando, en el caso de páginas Web estáticas, por ejemplo, pudiese ser bastante tolerable, sin embargo, en el caso de páginas dinámicas o de sistemas en tiempo real, la replicación puede traer consigo muchos problemas. e) Tratamiento de Fallos: El fallo tanto del hardware como el software es algo prácticamente inevitable, y por más confiable que pueda parecer algún componente, siempre es importante estar preparado para cuando este falle. En un sistema centralizado por lo general el fallo de cualquier componente del sistema provoca que todos los servicios que este ofrece dejen de funcionar, en cambio, en un sistema distribuido, los fallos son parciales, puesto que solo afectan a los servicios que el componente que fallo este prestando, mientras que otros servicios que prestan otros componentes siguen funcionando. El tratamiento de fallos en un sistema distribuido es una tarea difícil, pero que se puede lograr si se utilizan las técnicas adecuadas, según el sistema que se desee proteger. Algunas de las técnicas más comunes son: Detección de Fallos: obviamente no es posible tratar un fallo si este no se ha detectado, sin embargo, la detección de un fallo dentro de un sistema distribuido puede no ser tan sencillo como parece, recordemos que además de componentes de hardware y software, los sistemas distribuidos operan gracias a la transmisión de mensajes, y el funcionamiento del sistema depende en gran parte de estas transmisiones de datos entre los diferentes componentes; un fallo en la transmisión de datos entre componentes no es fácil detectar, pero es algo que podemos esperar (dependiendo del medio por el que se haga la transmisión y otras condiciones) y al saber que existe la posibilidad de ese fallo, podemos monitorear y aplicar técnicas que aseguren que dicha transmisión siempre sea correcta. Enmascaramiento de Fallos: una vez que un fallo es detectado, es importante encontrar la manera para que un usuario del sistema no note dicho fallo y que pueda seguir utilizando el sistema de manera normal, esto es, ocultar los fallos 15

16 del sistema y encargarse de que los servicios que se ofrecen al cliente nunca sean interrumpidos. Son muchos ejemplos del enmascaramiento de fallos, en el caso de un mensaje que se corrompió al ser enviado, una manera de ocultar el fallo es haciendo la solicitud de reenvío del mensaje, y de esta manera el usuario nunca notará que hubo un problema. Otro ejemplo lo dan las técnicas de redundancia que explicaremos más adelante, pero que básicamente consiste en tener disponibles varios elementos que puedan dar el mismo servicio y que en caso de que uno falle, otro este en la disponibilidad de realizar el trabajo en su lugar, esto puede darse cuando fallan componentes de un servidor (discos duros, tarjetas de red, etc.), o incluso cuando fallan las conexiones a la red o los sistemas de bases de datos. Tolerancia a Fallos: es importante saber cuando un sistema puede llegar a tener ciertos problemas sin que estos afecten de manera grave al usuario de los servicios proporcionados, para así, ignorar la ocurrencia de dichos fallos cuando la aplicación lo soporte, o bien, hacer saber al cliente que hay un problema en lugar de gastar tiempo y recursos innecesarios para corregirlo cuando probablemente el problema no se pueda arreglar rápido y el cliente termine por abortar el proceso; Pretender arreglar de manera inmediata todos los problemas que puedan surgir en un sistema puede resultar incluso dañino para el mismo sistema, puesto que hay problemas que mientras son arreglados pueden afectar el rendimiento de otros componentes del sistema que sí están trabajando. Recuperación Frente a Fallos: Una vez que fue detectado un fallo y que se ha decidido arreglarlo, hay que encontrar la mejor manera de hacerlo, y además, de recuperar el estado del sistema antes de que ocurriera el fallo; esto requiere del software adecuado para poder reconstruir o bien retractar los cambios que no fueron completados al momento en que fue interrumpido el sistema, un ejemplo de esto lo podemos ver en los sistemas manejadores de bases de datos, que se sirven de una bitácora de las transacciones que se realizan y de acuerdo a esta bitácora se decide reconstruir o retractar las transacciones hechas sobre la base de datos antes de que se interrumpiera el funcionamiento de la misma. Redundancia: un sistema distribuido puede lograr ser tolerante a fallos gracias a la utilización de componentes redundantes dentro del sistema. La redundancia se logra con la replicación de dichos componentes y con la habilidad del sistema de recurrir a los componentes de respaldo en caso de que el componente de uso primario falle, todo esto por supuesto, sin que el usuario se percate de lo que esta sucediendo. La redundancia se puede dar en muchas partes del sistema: componentes internos de los servidores, servidores de aplicaciones, de Web, de archivos, de correo o de bases de datos, sistemas de almacenamiento, conexiones a la red de comunicación, etc. Es muy importante tomar en cuenta que todos los componentes que estén replicados en el sistema deben mantenerse actualizados para evitar problemas de consistencia, y además, la actualización de la información entre dichos componentes no debe de tener un efecto significativo para las necesidades de transmisión de datos del sistema. 16

17 Las técnicas antes mencionadas no son las únicas, pero si las más utilizadas, estas técnicas deben de proporcionar las herramientas necesarias para aumentar el grado de disponibilidad de cualquier sistema distribuido, ya que al saber como tratar un fallo del sistema, también es posible encontrar la manera de reconfigurar el sistema para que los servicios que este proporciona no sean interrumpidos, o que en el peor de los casos sólo sean afectados los servicios proporcionados por los componentes afectados. f) Concurrencia: El control de concurrencia trata con los problemas de aislamiento y consistencia del procesamiento de transacciones. El control de concurrencia de un sistema distribuido asegura que la consistencia de los datos que se almacenan y que se procesan en el sistema se mantienen en un ambiente distribuido multiusuario. Si las transacciones son internamente consistentes, la manera más simple de lograr este objetivo es ejecutar cada transacción sola, una después de otra. Sin embargo, esto puede afectar mucho el desempeño de un sistema distribuido dado que el nivel de concurrencia se reduce al mínimo. El nivel de concurrencia, es decir, el número de transacciones simultáneas activas, es probablemente el parámetro más importante en sistemas distribuidos. Por lo tanto, los mecanismos de control de concurrencia buscan encontrar un balance entre el mantenimiento de la consistencia de los datos y el mantenimiento de un alto nivel de concurrencia. Si no se hace un adecuado control de concurrencia, se pueden presentar dos anomalías. En primer lugar, se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en los datos almacenados. En segundo término, pueden presentarse recuperaciones de información inconsistentes. Las técnicas que se utilizan para asegurar un control de concurrencia de un sistema distribuido, como hilos, semáforos, candados, etc., se discutirán más adelante, en la parte de análisis de la arquitectura de clienteservidor. g) Transparencia: Se dice que un sistema distribuido es transparente, cuando este es capaz de presentarse ante los usuarios y las aplicaciones como si fuese un sistema que corre en una sola computadora, y no como un sistema cuyos procesos y recursos están distribuidos físicamente en varias computadoras. Tipos de Transparencia: Según el Manual de Referencia ANSA y el Modelo de Referencia para el Procesamiento Distribuido Abierto de la Organización Internacional de Estándares (ISO 1995), el concepto de transparencia de puede aplicar a 8 aspectos diferentes de un sistema distribuido: o Transparencia de Acceso: oculta las diferencias entre la representación de los datos y la manera en que los recursos son accedidos. 17

18 o Transparencia de Ubicación: oculta la localización de los recursos y permite el acceso a los mismos sin la necesidad de conocer su localización. o Transparencia de Migración: oculta que un recurso o un cliente del sistema sea reubicado, lo que permite hacer dichas reubicaciones sin afectar la operación de los usuarios y los servicios. o Transparencia de Recolocación: oculta que un recurso o un cliente del sistema pueda moverse a una ubicación diferente mientras están en uso. o Transparencia de Replicación: oculta la existencia de múltiples ejemplares del mismo recurso. o Transparencia de Concurrencia: oculta que un recurso sea compartido por varios usuarios sin interferir entre ellos mismos. o Transparencia Frente a Fallos: oculta el fallo y recuperación de un recurso dentro del sistema, dejando que los usuarios terminen sus tareas a pesar de los fallos de hardware o software que pudieran presentarse. o Transparencia de Persistencia: oculta si un recurso (de software) esta almacenado en memoria o en disco. Desde el punto de vista de los usuarios, la transparencia se logra cuando: o Sus pedidos se satisfacen con ejecuciones en paralelo en distintas máquinas. o Se utilizan una variedad de servidores de archivos. o El usuario no necesita saberlo ni notarlo. La transparencia desde el punto de vista de los programas significa diseñar la interfaz de llamadas al sistema de modo que no sea visible la existencia de varios procesadores. No es transparente un sistema donde el acceso a los archivos remotos se realice mediante: El establecimiento explícito de una conexión en la red con un servidor remoto. El envío posterior de mensajes, donde el acceso a los servicios remotos será distinto al acceso a los servicios locales. Con todo esto en mente es posible diseñar un sistema que cuente con las características necesarias para lograr la transparencia en tantos aspectos como sea posible. Los dos más importantes son la transparencia de acceso y la transparencia de ubicación, la primera se relaciona con la forma en que representamos los datos en un sistema distribuido, es importante presentar al usuario o a los programadores el acceso indistinto a recursos locales o remotos, sin que este se de cuenta de la ubicación de los mismos, lo que al mismo tiempo nos conduce a tener transparencia de ubicación dentro del sistema. 18

19 Como no se sabe donde están localizados los recursos, tampoco se debe de saber si estos se mueven a una nueva ubicación, se este o no utilizando el sistema, esto es lo que se conoce como transparencia de Migración y Recolocación respectivamente. Ejemplos de transparencia de acceso, ubicación y migración es el sistema de nombre de dominio utilizado por los usuarios de Internet, estos utilizan un nombre de dominio como dominio.com para acceder este sitio, sin importar en donde este localizado el sitio de Internet, el usuario podrá acceder al servidor en el que se este hospedando la página, y si se decide mover este sitio a otro servidor, basta con redireccionar al cliente al servidor adecuado, sin que el cliente lo note. Por su lado, si el cliente esta accediendo al sitio desde una conexión inalámbrica dentro de su lugar de trabajo y esta en movimiento, es posible seguir proporcionando servicios sin interrupciones al cliente siempre y cuando el sistema sea transparente a la recolocación y permita que el cliente siga conectado a pesar de cambiar su ubicación física. Por otro lado, la replicación juega un papel muy importante dentro de un sistema distribuido, en el caso de los nombre de domino, los servidores DNS trabajan en un sistema de replicación distribuida organizado jerárquicamente que hace posible el acceso simultáneo a millones de usuarios que requieren de la información que contiene esta base de datos, sin embargo, la transparencia de la replicación en el sistema consiste en esconder que existen varias copias de un mismo recurso, y por lo general implica que dentro del mismo sistema se cuenta con transparencia de ubicación, puesto que de otra manera sería imposible acceder a las copias de los recursos con que se cuenta. La idea de un sistema distribuido es poder proporcionar a sus usuarios un servicio simultáneo a un mismo recurso; es entonces muy común que varios usuarios intenten hacer uso del mismo recurso al mismo tiempo y que traten de competir por el uso de dicho recurso; en estos casos la transparencia de concurrencia nos ayuda a ocultar al usuario que además de él, hay otros usando o intentando usar el mismo recurso. El reto más interesante de esta parte del diseño de un sistema distribuido es que también se tiene que considerar la consistencia de los datos que se almacenarán en el sistema, por lo que habrá que tomar decisiones en cuanto a las técnicas de candados y de uso de semáforos a utilizarse para lograr tener un sistema concurrente y a su vez consistente. La transparencia frente a fallos consiste en esconder cualquier falla que ocurra en el sistema para que el usuario pueda hacer uso del mismo a pesar de que alguno de sus componentes no este trabajando como es debido, uno de los retos más desafiantes de esta tarea es saber distinguir entre recursos que están fallando y recursos que simplemente están siendo accedidos por muchos usuarios y cuya respuesta puede alentarse. Es importante tener un buen esquema de replicación y de balanceo de cargas para evitar estas situaciones, pero al ser prácticamente inevitables es necesario considerar que hacer cuando el sistema esta en una situación como la antes mencionada, y 19

20 sobre todo determinar que tipo de respuesta enviar al cliente para que este no se de cuenta de las fallas del sistema. Grado de Transparencia: A pesar de que la transparencia es una característica generalmente deseable para cualquier sistema distribuido, hay situaciones en las que el pretender enmascarar todos los aspectos relacionados con la distribución de los componentes del sistema puede no ser lo más óptimo; en algunas ocasiones es mejor hacer del conocimiento del usuario que el sistema esta compuesto por varios elementos y que por más óptima que sea la transmisión de mensajes o la distribución y replicación de componentes, habrá cierto tiempo de respuesta mínimo entre cada transacción que es imposible evitar. Hay también una relación directa entre el nivel de transparencia y el rendimiento de un sistema distribuido, por lo que lo ideal es encontrar un bien equilibrio entre ambos factores. Por ejemplo, si pretendemos garantizar la transparencia de replicación en un sistema, es necesario que el usuario sepa que para garantizar la consistencia de la información es necesario actualizar todos los componentes replicados cuando se hace un cambio, por lo que el acceso al sistema puede verse interrumpido por algunos segundos mientras esta operación se lleva a cabo. Es muy importante considerar la transparencia como uno de los principales objetivos del diseño e implementación de un sistema distribuido, sin embargo, es importante tener en consideración otros factores que pueden ser afectados por la transparencia, principalmente el desempeño general del sistema Ventajas y Factores de Distribución: En general, los sistemas distribuidos exhiben algunas ventajas sobre los sistemas centralizados que se describen enseguida. a) Factores Estratégicos: Hoy en día, los clientes, proveedores y compañías se encuentran generalmente en diferentes localidades alejados los unos de los otros. Debido a que todos estos utilizan computadoras, las redes de información que los unen y que les permiten interactuar pueden ofrecer a las empresas mayor competitividad. b) Costos de Equipo: El cociente precio/desempeño de la suma del poder de los procesadores separados, contra el poder de uno solo centralizado, es mejor cuando están distribuidos, esto lo podemos calcular con base al costo promedio de MIPs (Millones de Instrucciones por Segundo), el cual es mucho mayor en 20