SISTEMAS DISTRIBUIDOS TEMA 1: FUNDAMENTOS DE LOS SISTEMAS DISTRIBUIDOS

Transcripción

1 SISTEMAS DISTRIBUIDOS TEMA 1: FUNDAMENTOS DE LOS SISTEMAS DISTRIBUIDOS DAVID RODRÍGUEZ HERNÁNDEZ FECHA DE REVISIÓN: 15 Nviembre 2008 ZAMORA (CURSO 2008/2009)

2 Nta imprtante: Este dcument n pretende reemplazar al material prpuest pr la UNED para la asignatura Sistemas Distribuids. Su finalidad es presentar de una frma esquematizada ls cntenids de la asignatura, para facilitar el estudi de la misma. Es cnveniente dispner de la bibligrafía prpuesta pr la Universidad para su estudi cmplet. Cualquier sugerencia, cmentari crrección sbre este dcument, envíel a david.rgh@gmail.cm para pder realizar ls cambis necesaris.

3 INTRODUCCIÓN Qué es un sistema distribuid? N es más que aquel sistema cuys cmpnentes (tant sftware cm hardware) se encuentran lcalizads en distintas cmputadras unidas a través de una red y que se cmunican y crdinan entre sí mediante el pas de mensajes. Esta definición tiene algunas implicacines, cm la cncurrencia; es decir, varis usuaris trabajand desde sus prpis rdenadres pueden tener acces simultáne a ls misms recurss del sistema. Est es imprtante, ya que el sistema debe pder gestinar bien la crdinación entre ests access. Además, cm cada rdenadr funcina aparte del rest (aunque cnectads entre sí tds), n existe una nción glbal del tiemp, manteniend cada un sus prpis registrs. Así pues, debe pder sincrnizarse de alguna frma. Se mantiene relativamente un cncept de individualidad, inclus en ls falls. Si un de ls rdenadres falla, el rest de rdenadres del sistema debe pder seguir trabajand. Qué es un recurs? Es alg que se cmparte entre ls rdenadres de la red. Puede ser alg físic, cm un disc dur y su capacidad de almacenamient; n, cm un ficher una base de dats.

4 EJEMPLOS DE SISTEMAS DISTRIBUIDOS Pdems mencinar ls siguientes: Internet: Quizás el más cncid. Se cmpne de diverss tips de cmputadres intercnectads. Ésts se cmunican mediante el pas de mensajes, que debe ser psible pr ls mecanisms de cmunicación. Alguns servicis de este sistema sn la WWW (Wrld Wide Web) (Cuidad: n cnfundir WWW cn Internet), el crre electrónic la transferencia de fichers (FTP). Ls usuaris se cnectan a Internet gracias a un ISP (Internet Service Prvider), que prprcina la cnexión de su cmputadr cn la intranet de la empresa que actúa cm ISP. Esta intranet, a su vez, tiene acces a Internet. Intranets: Cnsiste en una prción de Internet, administrada pr separad. Suele pertenecer a una empresa, que establece ls límites necesaris para mantener su plítica. Ls ISP s pseen intranets que utilizan para cnectar a sus clientes a Internet, a través de un ruter. Además, puede frecer sus prpis servicis, que pueden estar inaccesibles desde fuera de la intranet (ej: almacenamient y visualización de dats clínics de ls pacientes de un hspital). Suelen dispner también de un crtafuegs, que filtra ls mensajes de entrada y salida de la intranet cn el fin de prtegerse de prgramas ncivs. Una intranet también puede estar aislada cmpletamente de Internet, siend sól accesible desde dentr de la misma (en este cas, n es necesari el us de un crtafuegs). Cmputación móvil y ubicua: Ls rdenadres (entiéndase de sbremesa) n sn ls únics que se cnectan a ls sistemas distribuids. Pc a pc van prliferand el us de dispsitivs móviles, cm ls rdenadres prtátiles, ls teléfns móviles, las PDA s Ests dispsitivs pueden viajar entre redes, de frma que n están cnectads siempre a la misma red. Est se cnce cm cmputación móvil. La cmputación ubicua cnsiste en integrar el us de la infrmática y ls dispsitivs inteligentes en la vida rdinaria, de frma que el usuari ls use de una frma ttalmente natural. La rama más avanzada es la dmótica (viviendas autmatizadas) que tantas veces se han vist en películas de ciencia-ficción, per cuya realidad n está tan alejada cm pudiera creerse. La vivienda está dtada de dispsitivs inteligentes capaces de reaccinar a su entrn (ej: cntrlar la iluminación de una sala en función de la actividad detectada).

5 RECURSOS COMPARTIDOS Y WEB Ls usuaris están muy acstumbrads a cmpartir ls recurss dispnibles. Esta cmpartición puede ser abierta a td el mund, cm pr ejempl ls dats de un servidr web en Internet; puede ser cerrada en un grup delimitad de usuaris, cm pr ejempl dcuments en un sistema CSCW (Cmputer-Supprted Cperative Wrking). Ls mecanisms necesaris vienen determinads pr el patrón de cmpartir y pr la distribución gegráfica de ls usuaris. Un servici es una parte de un sistema que gestina una clección de recurss relacinads y presenta su funcinalidad a ls usuaris y aplicacines cliente (ej: un servici de impresión). Un servidr es un prces que acepta y respnde a las peticines enviadas pr prcess cliente. Esta cmunicación se realiza a través de mensajes. A esta slicitud se le denmina invcación de la peración. Se llama invcación remta a la interacción existente desde la slicitud hasta la respuesta del servidr. Un servidr también puede hacer las veces de cliente, cntactand cn trs servidres (téngase en cuenta que la denminación cliente y servidr se aplica a ls prcess, n a ls cmputadres (aunque clquialmente se les denmine a ls prpis cmputadres)). Un ejempl de cliente es un navegadr web. WORLD WIDE WEB La WWW es un sistema para la publicación y acces a servicis a través de Internet. Su nacimient tuv lugar en el CERN (Suiza), dnde se cncibió cm un mecanism para el intercambi de dcuments entre una cmunidad de físics. La Web prprcina una estructura de hipertext, de frma que un dcument puede cntener enlaces y referencias a tr dcument recurs. Ls recurss dispnibles están distribuids pr td el mund y es una estructura muy cmpleja (telaraña). Además, es un sistema abiert, de frma que se pueden agregar nuevs servicis cn facilidad, sin alterar la estructura ya existente. Para establecer las cmunicacines existen estándares públics. Aunque ahra exista una serie de recurss dispnibles; si se inventa un nuev tip de recurs, puede publicarse inmediatamente en la Web y ls navegadres pdrán leerl cn la simple inclusión de algún plug-in aplicación. La Web está basad en tres cmpnentes básics: HTML: HyperText Markup Language. Especifica el text e imágenes del dcument y su presentación al usuari. Puede cntener cabeceras, párrafs, tablas, imágenes, enlaces a trs dcuments recurss Puede verse un ejempl gráfic en la página 10 del libr base. El códig HTML se escribe a man bien se utiliza un editr WYSIWYG (What Yu See Is What Yu Want). Las etiquetas se escriben siempre entre ls símbls < y > y suelen estar pareadas, es decir, tienen una etiqueta inicial y tra final similar. URL: Universal Resurce Link. Se trata de un identificadr que refiere de frma universal y unívca a un recurs cncret de la Web. Se cmpne de un esquema y de la lcalización

6 específica. El primer puede ser mailt, ftp y el segund puede ser una dirección de crre electrónic, una dirección web Cm ya se dij antes, pueden intrducirse nuevs tips de recurss, que pasarán a utilizar un esquema prpi. Evidentemente, ls navegadres deben incluir ( instalar cn ells) una aplicación que pueda leer el nuev tip de recurs. El esquema de URL más cncid es, prbablemente, el HTTP. Es de la frma: En la página 12 del libr base se pueden encntrar alguns ejempls de URL. Las URL HTTP pueden incluir anclas (#), que hacen referencia a una parte cncreta del dcument, permitiend al usuari ir directamente a esa parte. Para publicar un nuev recurs, el usuari debe clcar el ficher en una carpeta accesible del servidr; de frma que se puede psterirmente cmpner la URL adecuada y publicarla en tr dcument. HTTP: HyperText Transfer Prtcl. Sus principales características sn: Interaccines petición-respuesta: El cliente realiza una slicitud al servidr del recurs que quiere y éste busca dich recurs y se l devuelve en un mensaje (si n existe, le devlverá un errr). Tips de cntenid: El cliente especifica, junt cn su slicitud, el tip de archivs que prefiere (pr ejempl, puede preferir un frmat GIF y n un JPEG); de frma que el servidr l puede tener en cuenta a la hra de respnder a la petición (en la respuesta incluirá el tip de cntenid para que el cliente sepa cóm prcesarl; esta infrmación se cnce cm tips MIME). Pueden verse alguns ejempls en la página 13 del libr base. Un recurs pr slicitud: Pr cada recurs desead, se realizará una slicitud distinta (ej: un dcument cn 9 imágenes necesitará 10 slicitudes (una pr cada imagen y tra pr el prpi dcument)). Est es así en la versión 1.0 de HTTP. Cntrl de acces simple: Cualquier usuari cn una cnexión de red a un servidr web tendrá acces a cualquiera de ls recurss publicads en dich servidr. Sin embarg, un servidr puede ser cnfigurad para limitar el acces (pr ejempl, mediante un sistema de cntraseñas). Td l anterir ha hech referencia a dcuments estátics, dnde si hay algún cambi se realiza de frma permanente para tds ls psibles clientes. Sin embarg, determinads dcuments requieren un frmat persnalizad (pr ejempl, la cnfirmación de ls dats persnales de una persna en una tienda nline). Pr tra parte, alguns dcuments se cmpnen de frmularis (ej: la página de registr de un siti web) que deben pder prcesar ls dats intrducids (est es, se envían dichs dats al servidr). Para pder presentar ests dats se necesita un prgrama que genere el códig dinámic de ls resultads. Se le suele cncer cm CGI (Cmmn Gateway Interface). Este prgrama se ejecuta en el servidr.

7 Sin embarg, trs tips de códig, cm el Javascript, se descargan junt al dcument y se ejecutan en el cliente (ej: validación básica de dats de frmulari mdificar algunas partes del dcument), l cual acrta el tiemp de espera; aunque es bastante limitad. Para salvar esta limitación, tenems ls applets, que sn prgramas escrits en Java y que se descargan al cliente, dnde se ejecutan. Ls applets pueden tener acces a la red (ej: chat incrustad en una página web). El éxit de la Web es la facilidad de publicación de recurss. Sin embarg, tiene alguns incnvenientes, cm pr ejempl ls enlaces rts (si se mdifica un recurs puede que ls enlaces hacia él queden inútiles) la cnfusión que puede supner a un usuari seguir demasiads enlaces. Pr tra parte, HTML es un lenguaje muy limitad en un mund en el que se requiere un intercambi de muchs tips de dats estructurads cada vez más creciente. Además, ls servidres pueden tener demasiads access simultánes, cn l que se ralentiza el acces a ls usuaris.

8 DESAFÍOS HETEROGENEIDAD Las redes y cmputadres accesibles pr Internet sn muy hetergénes (variads y diferentes). Esta hetergeneidad se aplica a redes, hardware, sistemas perativs, lenguajes de prgramación y diferentes implementacines. Ls prtcls de Internet permiten la intercnexión entre ells. Téngase en cuenta que distint hardware puede tener distinta representación para un tip de dat, al igual que distints lenguajes de prgramación. En cuant a las implementacines, se necesita el acuerd de una serie de estándares. El middleware es un tip de sftware que permite encapsular la implementación de las aplicacines, permitiend que ds prgramas distints en redes distintas puedan cmunicarse entre sí. Alguns ejempls sn CORBA y Java RMI. Es una herramienta útil además para ls desarrlladres, para pder crear aplicacines distribuidas utilizand las invcacines remtas que prprcina el middleware. Se cnce cm códig móvil a aquel que puede enviarse desde un cmputadr a tr y ejecutarse en el destin. El prblema es que dich códig puede n ser entendid pr el destin para su ejecución. Est queda slucinad mediante las máquinas virtuales; es decir, se crea códig para una máquina virtual en lugar de para un hardware cncret. Esta máquina virtual (pr ejempl, JVM (Java Virtual Machine)) traduce el códig para el hardware en cuestión (esta slución n se puede aplicar de md general a trs lenguajes). EXTENSIBILIDAD Cnsiste en el grad en que se puede extender y reimplementar cn variacines. En un sistema distribuid está determinad pr el grad en que se pueden añadir nuevs servicis de cmpartición de recurss y publicarls. Para ell, la dcumentación debe estar dispnible para ls desarrlladres. Ls prtcls de Internet tienen su dcumentación en ls llamads RFC (Request Fr Cmments), aunque n sn ls únics. Se cnce cm sistema distribuid abiert a aquel sistema diseñad para dar sprte a la cmpartición de recurss. La extensión del sistema puede ser pr hardware pr sftware. Sus interfaces están publicadas y ests sistemas se basan en la prvidencia de un mecanism de cmunicación unifrme. Cm ya se dij antes, puede cnstruirse cn hardware y sftware hetergénes, utilizand para ell estándares. SEGURIDAD Esta prpiedad es vital, pues ls recurss pueden tener un gran valr. Tiene 3 cmpnentes: cnfidencialidad (impedir access n autrizads), integridad (n se mdifican ls dats) y dispnibilidad (impide el blque del acces). En las peticines, se transmite infrmación sensible pr la red, que debe tener una cierta seguridad, además de asegurarse de que el interlcutr es quien dice ser. Las técnicas de encriptación pueden dar esta seguridad. Sin embarg, tenems ests trs prblemas:

9 Ataques de Denegación de Servici: DOS. Cnsiste en bmbardear un servidr a base de peticines, de manera que éste n puede atenderlas y queda clapsad, impidiend su us a ls usuaris. Seguridad del códig móvil: La transmisión de códig pr la red supne un riesg para quien l recibe. N sn pcs ls que han sid infectads pr códig malign que estaba adjunt en un crre electrónic. ESCALABILIDAD Para que un sistema sea escalable, debe cnservar su efectividad cuand se aumenta significativamente ls recurss y usuaris. Un ejempl de un sistema escalable es el prpi Internet. Un prblema existente es el cste de ls recurss físics, necesaris cuand la demanda de ls recurss (sftware) aumenta. Pr ejempl, añadir servidres redundantes que puedan balancear la carga de trabaj de las peticines. Además, extender un sistema puede supner una pérdida de prestacines, la cual debe ser cntrlada y minimizada. Un recurs puede verse desbrdad cn la extensión. Pr ejempl, las direccines IP actuales (IPv4) sn limitadas y se agtan cn el rápid crecimient de usuaris, l que requiere una ampliación (IPv6). La carga debería estar bien balanceada, para evitar prblemas de cuells de btella. TRATAMIENTO DE FALLOS Ls sistemas fallan, es una realidad. Deben minimizarse sus efects. Alguns falls sn detectables, l cual permite prevenirls y evitar que sucedan. Pr ejempl, las sumas de cmprbación (checksum) permiten detectar dats crrupts de un archiv. Otrs falls pueden cultarse al usuari (pr ejempl, mediante la redundancia de discs se lgra que un dat crrupt sea servid pr el disc que cntiene el crrect). N tds ls falls pueden cultarse enmascararse, y supndría un gast elevad. Pr ell, se admite una cierta tlerancia según el sistema. Es muy imprtante también dispner de un buen sistema de recuperación de falls, de frma que ls dats puedan vlver a un estad cnsistente tras un fall (ej: rllback). CONCURRENCIA Una cnsecuencia directa de la cmpartición de recurss es la psibilidad del acces cncurrente de varis usuaris a un mism recurs. Aunque pdría atenderse cada petición pr separad, cnllevaría a una pérdida de prductividad (thrughput). Pr ell se utilizan threads para ejecutar cncurrentemente el cntenid de un bjet en que se encapsula el recurs en cuestión. Las peracines realizadas deben estar bien sincrnizadas. TRANSPARENCIA Cnsiste en cultar al usuari la separación de ls cmpnentes distribuids, de frma que perciba una sla unidad. Tenems ls siguientes tips de transparencia: De acces: Se accede de la misma frma a recurss lcales que a remts. Pr ejempl, las carpetas de una GUI se muestran igual tant si sn lcales cm remtas.

10 De ubicación: N se requiere cncer la lcalización de un recurs para acceder a él. De cncurrencia: Varis prcess pueden realizar peticines simultáneas sbre el mism recurs. De replicación: Puede utilizarse varias (miles) de cpias de un recurs para aumentar las prestacines (el usuari n es cnsciente de ell). Frente a falls: Oculta ls falls a ls usuaris y a las aplicacines de usuari, permitiend que cntinúen su tarea. De mvilidad: Permite reubicar recurss sin que el usuari l nte (accede de la misma frma). De prestacines: Permite recnfigurar el sistema para balancear las cargas según el estad. Al escalad: Permite ampliar el sistema sin alterar la estructura ni ls algritms. De ests, ls más imprtantes sn ls 2 primers. Pr ejempl, un URL tiene transparencia de ubicación, ya que da igual la lcalización física del recurs, ya que el URL designa un identificadr únic que lueg debe traducirse. Sin embarg, n tiene transparencia de mvilidad, ya que si se reubica el recurs, sus enlaces quedan inútiles. Pueden verse varis ejempls en la página 23 del libr base.

11 MODELOS ARQUITECTÓNICOS Se cnce cm arquitectura del sistema a la estructura de cmpnentes del mism. De una manera simplista, se pdría desglsar un sistema distribuid en servidres, clientes e iguales. Ls ds primers ya se explicarn en ls apartads anterires. Ls iguales sn aquells prcess que cperan entre sí pnerse un pr encima del tr. Recrdems que puede realizarse códig móvil, que se descargan del servidr al cliente para ejecutarse allí. CAPAS DE SOFTWARE Ls sistemas distribuids se estructuran en capas, cm puede verse en la figura de la página 30. Se cnce cm platafrma al nivel de hardware y las capas más bajas del sftware. Su función es servir a las capas superires cn independencia del cmputadr utilizad. Una parte de la platafrma es el sistema perativ, que actúa de interfaz cn las capas superires. Se cnce cm middleware a una capa de hardware que permite realizar una intercnexión entre capas de frma hmgénea; es decir, enmascara las capas inferires para que la capa superir n tenga que precuparse de la implementación de éstas. Prprcina blques útiles que sirven para que ls cmpnentes sftware puedan interactuar cn ls sistemas distribuids. Cm ejempls de middleware, pdems nmbrar las llamadas a prcedimients remts (RPC) (fuern de ls primers), CORBA, RMI, DCOM. También puede prprcinar servicis para que las aplicacines de servicis ls utilicen (ej: CORBA frece funcines cm la gestión de nmbres, seguridad, transaccines, almacenamient persistente ). Muchas aplicacines dependen del middleware para su crrect funcinamient, per alguns aspects de la cnfiabilidad aún requieres sprte al nivel de aplicación (puede verse un ejempl en la página 31). El funcinamient crrect depende de las cmprbacines en ls diverss niveles, n sl en el middleware. ARQUITECTURAS DE SISTEMA Una de las características principales de un sistema distribuid es el repart de tareas entre sus cmpnentes. A cntinuación verems ls mdels arquitectónics principales. Es cnveniente acmpañar esta parte cn las ilustracines del libr base desde la página 32 hasta la 39: Mdel cliente-servidr: Es la más cmún e imprtante hy en día. Además, es muy intuitiv: varis prcess cliente realizan peticines a un prces servidr. Recuérdese que esta denminación se aplica a una petición cncreta, pr l que un servidr en una petición puede hacer las veces de cliente en tra distinta (cntactand cn tr servidr distint) (pr ejempl, un buscadr acepta peticines de ls usuaris (servidr) per realiza cnsultas a trs servidres para buscar ls resultads (cliente) (esta búsqueda la hace un prgrama llamad escaladr (crawler)). Servicis prprcinads pr múltiples servidres: Un servici puede cmpnerse de varis servidres que interaccinan entre sí para realizar el servici. Pueden repartirse ls bjets replicarls. Un ejempl es la Web, dnde un usuari puede utilizar un navegadr para acceder

12 a un recurs en cualquiera de ls servidres. La replicación prprcina una mayr dispnibilidad y tlerancia a falls. Servidres prxy y cachés: Cuand se slicita un recurs, se almacena en la caché, de frma que queda dispnible de una frma much más rápida si se vuelve a slicitar. Si n está actualizada, se busca el recurs en el servidr riginal y se actualiza la caché. Est es muy emplead actualmente pr ls navegadres web. Ls servidres prxy prprcinan una caché cmpartida a clientes de un más sitis, cn l que se mejra la dispnibilidad y las prestacines y evita sbrecargas en la red. Prcess de igual a igual : Peer t Peer. Tds ls prcess funcinan de frma simétrica e interactúan entre ells para cperar para llevar a cab una determinada tarea. En este cas n existe prces servidr. VARIACIONES EN EL MODELO DE CLIENTE-SERVIDOR Pdems distinguir las siguientes variacines: Códig móvil: Ya hems hablad antes de est. Un ejempl de códig móvil es un applet de Java. Cn ell se puede extender la funcinalidad de la aplicación cliente (ej: navegadr web) añadiend tras que n realiza de frma básica. Recuérdese que el códig móvil es un riesg de seguridad para el cmputadr destin; aunque ls navegadres suelen limitar el acces de dich códig a ls recurss lcales. Agentes móviles: Se trata de un prces que, para llevar a cab su tarea, se traslada entre varis cmputadres (ej: una aplicación que reclecte infrmación una aplicación que pueda instalar cmpnentes en varis cmputadres). Igualmente representan un riesg para ls cmputadres visitads. Cmputadres de red: Se caracteriza prque descarga su SO y cualquier aplicación necesaria desde un servidr remt. Aunque la ejecución es lcal, la gestión real de ls archivs se da en el servidr. Clientes ligers: Es una capa de aplicación cn una interfaz de ventanas sbre un cmputadr lcal que ejecuta prgramas de aplicación en un cmputadr remt. Se diferencia del anterir en que n se descarga el códig de las aplicacines, sin que se ejecutan en el servidr (servidr de cómput). Su mayr prblema está en aplicacines gráficas cn una interacción fuerte (ej: CAD), que ralentiza excesivamente su us. La mayría de variantes de UNIX usan el sistema de ventanas X-11. En la página 37 del libr pueden verse alguns ejempls. Dispsitivs móviles y enlace espntáne a red: Recrdems que hay infinidad de dispsitivs que pueden cnectarse a la red: PDA, móviles, chips de dmótica Un sistema distribuid puede dar sprte para la cmputación móvil que permite a ests dispsitivs cnectarse a ls recurss lcales y remts. Se cnce cm enlace a red espntáne a aplicacines que usan cnexines de una manera más infrmal (ej: PDA cn gelcalización servicis lcales cm la Web). Véanse varis ejempls en la página 38. Las características esenciales sn: Cnexión fácil a la red lcal: Cuand se clca un dispsitiv en un nuev entrn, se recnfigura autmáticamente para facilitar la cnexión.

13 Integración fácil cn servicis lcales: Un dispsitiv que se mueva entre redes existentes de dispsitivs, detecta autmáticamente qué servicis prprcinan ls dispsitivs a ls que se cnecta. Un ejempl cmún sn ls servicis bluetth de un teléfn móvil: detecta ls servicis que prprcinan trs dispsitivs bluetth cercans. Td est cnlleva sus prblemas, cm puede ser la descnexión tempral, pr ejempl, si se atraviesa un túnel, en la que el usuari debería pder seguir trabajand. Además, hay prblemas de seguridad pr la prximidad de la cnexión de trs dispsitivs (en el ejempl del bluetth, tr teléfn cercan pdría acceder al nuestr si n se establecen medidas de seguridad). Se cnce cm servici de detección servici de descubrimient a aquel servici que se encarga de aceptar y almacenar detalles de ls servicis dispnibles en la red a la que está cnectad, así cm respnder cnsultas de trs dispsitivs. Est, pr ejempl, l hacems cada vez que en nuestr teléfn slicitams hacer un barrid en busca de dispsitivs cercans. Tiene ds interfaces: INTERFACES Y OBJETOS Servici de admisión: Acepta slicitudes de ingres en el servidr y almacena ls detalles del slicitante en la base de dats del servici de descubrimient. Servici de búsqueda: Acepta cnsultas acerca de ls dispsitivs dispnibles y realiza una búsqueda en la base de dats de aquells servicis registrads que cinciden cn ls parámetrs intrducids. Se cnce cm definición de interfaz a la especificación del cnjunt de funcines que se puede invcar sbre el prces en cuestión. En ls lenguajes rientads a bjets, ls prcess pueden encapsular un gran númer de bjets y cmunicarse cn trs prcess a través de estas interfaces (a través de invcacines remtas), esta es la aprximación aprtada pr CORBA y Java cn el RMI. REQUISITOS DE DISEÑO PARA ARQUITECTURAS DISTRIBUIDAS Cuand cmenzó a extenderse la dispnibilidad de redes de cmputadres de prestacines medias, la cmpartición de recurss se asumió cm nrmal. Per cmpartir dats en gran escala aún es un ret. En cuant a las prestacines, pdems cnsiderar ls siguientes punts: Capacidad de respuesta: Respnsiveness. Cuand se implica un servici remt, el tiemp de respuesta está influenciad pr ls retards de tds ls cmpnentes implicads, así cm el middleware, la cmunicación entre ls sistemas y el códig del prces. Esta cmunicación resulta lenta cuand ls dats a transmitir sn elevads (n es l mism un párraf de text que una imagen). Prductividad: Thrughput. Es la rapidez a la que se realiza el trabaj cmputacinal. Es imprtante la prductividad de las capas de sftware que intervienen en el prces. Balance de cargas cmputacinales: Es imprtante distribuir de frma crrecta la carga. Pr ejempl, el us de applets libera al servidr de su ejecución, delegándla en el cliente. Un únic servici puede ser prprcinad pr un cnjunt de servidres.

14 Respect a la calidad del servici, se ve afectada pr la fiabilidad, la seguridad y las prestacines. También es imprtante la facilidad de adaptación (adaptability). Ls ds primers sn crítics. Muchs sistemas tienen determinads dats que deben transferirse en un tiemp determinad (ej: detectr de hums que permite activar el sistema de extinción de incendis). La calidad del servici (QS, Quality f Service) es la capacidad del sistema para satisfacer ests tiemps límite. Una excesiva carga en el sistema deterira sus prestacines y, pr tant, la calidad. Se debe garantizar que ls recurss crítics estén reservads para las aplicacines que requieren QS. Pr l que respecta al us de caché y de replicación, ya habíams cmentad las ventajas de la caché para disminuir ls tiemps de respuesta. Ésta almacena ls recurss que se han utilizad, de frma que el siguiente servici que use dichs recurss se ejecuta más rápid, al n tener que esperar el enví desde el servidr riginal. En la Web, esta caché puede ser del navegadr del prxy (si existe). Si el recurs n está actualizad (se valida cn el servidr riginal) será entnces cuand se vuelva a recurrir al servidr para btener la última actualización. Ls recurss de la caché y el prxy suelen tener uns tiemps de expiración, que permite cmprbar si un recurs está bslet, realizand un cálcul cn su edad en cntrapsición al tiemp de expiración. Pr últim, la fiabilidad es un requisit crucial. De este requisit pueden llegar a depender vidas, aspects ecnómics, seguridad de dats persnales etc. Pdems analizar alguns aspects imprtantes: Tlerancia frente a falls: Se puede cnseguir fiabilidad mediante redundancia. Ls recurss pueden estar duplicads en múltiples servidres, pr l que se lgran varis camins de cmunicación y que las aplicacines se recnfiguren autmáticamente para cnectar a un a tr. Es alg csts y limitad. Las aplicacines críticas (ej: cntrl aére) requieren un alt grad de fiabilidad, pr l que el cste de mantenimient es muy elevad. En las cmunicacines se lgra fiabilidad cn tras técnicas, cm el us de recncimients (ACK) para las transmisines. Seguridad: Ls dats y prcess deben estar prtegids cntra ataques y accesible únicamente a ls usuaris autrizads (ej: base de dats de un hspital: ls histriales deben estar a salv de cualquier vulneración de la seguridad (pr ejempl, impidiend descargar el histrial cmplet a un terminal)).

15 MODELOS FUNDAMENTALES Tds ls mdels descrits anterirmente cmparten el hech de que se cmpnen de prcess que se cmunican mediante mensajes pr la red y siguen ls principis de diseñ que hems cmentad. Un mdel tiene sól l esencial para entender y raznar sbre alguns aspects del cmprtamient del sistema y debe tratar de definir las entidades del sistema y su interacción, además de las características que les afectan. Ns permite cncer las premisas sbre ls sistemas, y así pdems valrar si sn válidas sbre una implementación cncreta. Así, pdems raznar sbre la interacción entre ls prcess del sistema (cmunicación pr pas de mensajes) (debe reflejar ls retrass y la precisión de crdinación), ls falls que están definids y clasificads pr el mdel (permite analizarls y diseñar sistemas tlerantes) y la seguridad (se definen y clasifican ls psibles ataques cn el fin de pder cmbatirls). Veams alguns mdels simples: MODELO DE INTERACCIÓN Ls sistemas se cmpnen de prcess que interactúan entre sí. La interacción puede incluir clientes y servidres, y también puede realizarse entre iguales. Se cnce cm algritm distribuid a la definición de ls pass que hay que llevar a cab pr cada prces, incluyend ls mensajes de transmisión entre ells. Es cmplicad cncer tds ls psibles estads de ls algritms distribuids, ya que depende much de ls falls de ells misms y de ls prcess cn ls que se cmuniquen. A ls prcess que interactúan, les afectan ds factres principalmente. Pr una parte, tenems las prestacines de ls canales de cmunicación. Hay varias pcines de canales. Se debe tener en cuenta la latencia (retarde entre el enví de un mensaje y la recepción de su respuesta), el anch de banda (si se usan varis canales, el anch de banda tiene que ser cmpartid, l que disminuye las prestacines) y la fluctuación (variación del tiemp invertid en cmpletar el repart de una serie de mensajes (es imprtante para ls dats multimedia (n debe presentar demasiada fluctuación))). Pr tra parte, tenems ls reljes de cmputadres y events de temprización. Cada cmputadr tiene su prpi relj, que casi siempre presentará derivas cn respect a ls reljes del rest de cmputadres. Se cnce cm tasa de deriva del relj a la prprción de deriva de un relj cn tr de referencia que se cnsidere perfect. Una frma de crregir ls tiemps del relj es mediante un receptr GPS, que realice lecturas del tiemp de un sistema GPS; per es una slución cara para cada cmputadr (cm alternativa, puede haber un servidr que se encargue de est y transmita el tiemp al rest de cmputadres). En este mdel pdems encntrar ds variantes: Sistemas distribuids síncrns: En ests sistemas, el tiemp de ejecución de cada etapa de un prces tiene límites superir e inferir cncids, el tiemp de recepción de un mensaje también tiene un límite cncid, al igual que el límite de la tasa de deriva. Se pueden sugerir valres de límites parecids, per es cmplicad ser realista. Deberían pderse garantizar ls límites. Pr ejempl, puede utilizarse timeuts para marcar el fall de un prces.

16 Sistemas distribuids asíncrns: Pr ejempl, Internet. N tiene límites en la velcidad de prcesamient, ls retardes de transmisión de mensajes y en las tasas de deriva de relj. En este n se presupne nada acerca de ls intervals de tiemp de cualquier ejecución. Debid a que actualmente es muy imprtante la cmpartición de recurss y de canales de cmunicación, casi tds ls sistemas actuales sn asíncrns. Per, cm ya dijims, determinadas situacines requieren de un sistema síncrn (ej: transmisión multimedia). Muchas veces ns interesa saber el rden de ls events mensajes (véase el ejempl de las páginas del libr base). Cm ls sistemas distribuids n pueden sincrnizarse de una frma perfecta, tenems el mdel de tiemp lógic, que permite inferir el rden sin recurrir a ls reljes (véase el ejempl de la página 50). MODELO DE FALLO Pueden fallar tant ls prcess cm el canal de cmunicacines. Tenems la siguiente clasificación de falls: Falls pr misión: N se lgran realizar accines que se supne que se pueden hacer. Falls pr misión de prcess: Fracasa la ejecución de un prces se termina inesperadamente (crash). En un sistema síncrn, ests falls se detectan mediante timeuts (el prces n respnde en el tiemp establecid), per en un asíncrn, ese timeut puede significar simplemente que tarda más de la cuenta. Se cnce cm fall-parada cuand ls trs prcess pueden asegurar cn certeza el fall. Falls pr misión de cmunicacines: Se prduce cuand el canal de cmunicacines n realiza el transprte de un mensaje (pierde ls mensajes). El prblema suele estar en el buffer de salida de entrada (falta de espaci), pr l que pdems tener falls pr misión de enví y falls pr misión de recepción. En la figura 2.11 (página 52) puede verse la clasificación de falls pr misión. Falls arbitraris: ( fall bizantin). Puede currir cualquier tip de errr. En el prces se miten pass deseables para el prcesamient se realizan pass n intencinads de prcesamient. Ests falls n pueden detectarse pr la respuesta a las invcacines. Pueden currir crrupción de dats, enví de mensajes n existentes, repetición de mensajes Falls de temprización: Se dan en ls sistemas síncrns. Superan ls límites de tiemp establecids (véase la clasificación de la figura 2.12 (página 53)). En ls asíncrns n pdems hablar de falls de temprización, prque el exces puede deberse simplemente a un retard en la cmunicación. En las cmunicacines multimedia, es imprescindible evitar este tip de errres. Enmascaramient de falls: Ls falls pueden ser enmascarads (cultads) si sabems de anteman l que puede suceder (ej: se rmpe un disc per tenems trs redundantes que l sustituyan inmediatamente). El enmascaramient puede darse cultand el fall cnvirtiéndl en tr más aceptable (ej: la suma de cheque detecta errres arbitraris (mensajes crrupts) y puede cnvertirls en falls pr misión). Fiabilidad y cmunicación un a un: Se cnce cm cmunicación fiable a aquella que es válida (cualquier mensaje en el buffer de salida llegará al buffer de entrada) e íntegr (n se duplican ni alteran mensajes). Las amenazas a esta integridad prvienen de prtcls que

17 retransmitan mensajes per que n rechace duplicads usuaris malintencinads que duplican alteran mensajes. MODELO DE SEGURIDAD Debe darse asegurand y prtegiend ls prcess y canales de cmunicación. Veams cada aspect un pr un: Prtección de bjets: Ls bjets del servidr tienen una serie de derechs de acces, que determinan quién puede invcar qué peracines del servidr. Ls beneficiaris de ests derechs sn ls usuaris. Cada invcación y cada resultad está asciad a la autridad cn la que se rdena, llamada principal (puede ser un usuari un prces (en el ejempl de la página 55 (Figura 2.13) la invcación prviene de un usuari y el resultad de un servidr)). El servidr debe verificar la identidad y derechs del principal que invca a la peración. El cliente debe cmprbar la identidad del principal que le envía el resultad. Asegurar prcess y sus interaccines: El enví de mensajes está expuest a ataques. Asimism, las interfaces de ls servidres y prcess parejs también están expuestas. Debe prtegerse de psibles ataques. El enemig: Debe cncebirse al enemig en ls peres cass (envía mensajes a cualquier prces, tiene tds ls derechs ), para hacer un mdel de seguridad fiable. Inclus se debe prever que el enemig pueda ser un cmputadr que pertenece a la prpia red. Amenazas a prcess: Un prces puede recibir mensajes de trs prcess de ls que n pueda averiguar su identidad. Inclus aunque el mensaje llevase identidad (ej: dirección IP), la misma pdría estar falseada pr el atacante. Est representa una amenaza para el crrect funcinamient de ls servidres y clientes (el atacante puede hacerse pasar pr un cliente que envíe una petición pr un servidr que envíe un resultad fals). Amenazas a ls canales de cmunicación: Ls mensajes que se transmiten pueden ser interceptads en el trayect, prvcand que el atacante ls elimine, ls altere ls sustituya pr un mensaje prpi (véase la Figura 2.14 (página 55)). Inclus pdría almacenarse el mensaje para ejecutarl psterirmente repetidas veces (ej: petición de transferencia de diner). Deben utilizarse canales segurs. Vencer amenazas de seguridad: Veams algunas técnicas: Criptgrafía y secrets cmpartids: El secret cmpartid se basa en un dat que sól ambs cmpnentes de la cmunicación cncen y que se transmite para cmprbar la crrecta identidad del interlcutr. La criptgrafía permite encriptar ls mensajes; es decir, cdificándls de tal frma que sól se puedan recuperar mediante claves secretas cnsistentes en númers grandes difíciles de deducir). Autenticación: L anterir frma la base de la autenticación; es decir, incluir un fragment encriptad cn el suficiente cntenid del mensaje cm para asegurar su autenticidad. El destinatari desencripta este fragment y l cmpara cn la parte crrespndiente n encriptada (deben cincidir). Canales segurs: Es un canal que cmunica ds prcess y que cada un de ells cnce bien la identidad del tr. Además, asegura la privacidad y la integridad y en

18 cada mensaje se incluye un sell tempral que evita que sea reenviad rerdenad. Ejempls de canales segurs sn las VPN y el SSL. Otras psibilidades de amenaza de un enemig: Ya habíams vist anterirmente estas tras ds psibilidades: Denegación de servici: Cnsiste en el enví excesiv de invcacines sin sentid, l que sbrecarga ls recurss físics afectads. Puede lgrar retrasar impedir actuacines legítimas de trs usuaris. Códig móvil: El códig móvil puede cnvertirse en un caball de Trya que pne en riesg al destinatari. Aquí hay muchas psibilidades de ataque, pr l que debe tenerse especial cuidad. Aplicacines de ls mdels de seguridad: Aunque la imprtancia de la seguridad es alg evidente, n siempre se tma en cuenta. El us de las técnicas cnlleva un cste adicinal y ls análisis deben ser muy rigurss, ya que las amenazas pueden llegar desde muchs sitis. Pr ell es necesari un mdel de seguridad, que clasifique y analice ls riesgs a ls que el sistema está expuest.