Sistemas Informáticos 2

Sistemas Informticos II
Pedro Valero
Vctor de Juan
Eduardo Miravalls
UAM - Curso 2014 - 2015 C2
14 de junio de 2016 13:23
Apuntes UAM
Doble Grado Mat.Inf.
Cdigo en Github
Pedro Valero, Vctor de Juan, Eduardo Miravalls
ndice general
I
Middleware
I.1 Network Operating System (NOS) . . . . . . . . .
I.2 Servicios de transporte . . . . . . . . . . . . . . . .
I.2.1 API directa . . . . . . . . . . . . . . . . . . .
I.2.2 Sockets . . . . . . . . . . . . . . . . . . . . .
I.3 Modelos de servicios distribuidos . . . . . . . . . .
I.3.1 RPC - Remote Procedure Calls . . . . . . .
I.3.2 Web Services (SOAP-WSDL-UDDI) . . . .
I.3.3 REST . . . . . . . . . . . . . . . . . . . . . .
I.3.4 Comuncacin mediante colas de mensajes
I.4 Services Oriented Architecture SOA . . . . . . . .
I.4.1 ESB - Enterprise Services Bus . . . . . . . .
I.4.2 RMI - Remote Method Invocation . . . . .
I.4.3 Java RMI . . . . . . . . . . . . . . . . . . . .
I.5 Servicios de directorio global . . . . . . . . . . . .
I.5.1 Namespaces . . . . . . . . . . . . . . . . . .
I.5.2 Servicios de tiempo . . . . . . . . . . . . . .
I.5.3 Seguridad . . . . . . . . . . . . . . . . . . .
I.6 Problemas . . . . . . . . . . . . . . . . . . . . . . .
II Colas
II.1 Teora . . . . . . . . . . . . . . . . . . .
II.1.1 Distribuciones no Poissonianas
II.1.2 Redes de colas . . . . . . . . . .
II.2 Problemas . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
4
4
6
6
9
12
14
16
16
17
20
21
21
23
25
26
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
46
47
47
III Aspectos operacionales de los sistemas distribuidos: Disponibilidad

III.1 Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III.2 Teora de la disponibilidad . . . . . . . . . . . . . . . . . . . . . . .
III.2.1 Disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . .
III.2.2 Fiabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III.2.3 Distribucin de los fallos . . . . . . . . . . . . . . . . . . .
III.2.4 Mantenibilidad . . . . . . . . . . . . . . . . . . . . . . . . .
III.2.5 Componentes en serie frente a Componentes en paralelo .
III.3 Mejoras de la disponibilidad . . . . . . . . . . . . . . . . . . . . . .
III.3.1 Arquitecturas que incrementan la disponibilidad . . . . .
III.4 Redundancia en los sistemas de comunicaciones . . . . . . . . . .
III.4.1 Rapid Spanning Tree Protocol, RSTP . . . . . . . . . . . . .
III.4.2 Deteccin de fallos en RSTP . . . . . . . . . . . . . . . . . .
III.4.3 Redundancia en la conexin de servidores a nivel 2 . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
79
81
81
82
83
84
84
85
86
86
88
88
88
Documento compilado el 14 de junio de 2016 a las 13:23
1 de 112
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
III.4.4 Redundancia de las WAN . . . . . . . . . . . . . . . . . . . . . . .

III.4.5 Redundancia en los sistemas de almacenamiento de la informacin
III.4.6 Redundancia en los sistemas de proceso . . . . . . . . . . . . . . .
III.5 Recuperacin ante desastres . . . . . . . . . . . . . . . . . . . . . . . . . .
III.5.1 Arquitecturas de CPDs orientadas a la recuperacin ante desastres
III.5.2 Resumen de tipos de clusters . . . . . . . . . . . . . . . . . . . . .
III.6 Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ndice alfabtico
89
91
93
95
97
98
99
111
Captulo I
Middleware
Para este tema es importante tener claros varios conceptos que vamos a ir definiendo y
explicando poco a poco.
Middleware
Definicin I.1 Middleware. Conjunto de aplicaciones encargadas de enlazar los componentes

de un sistema distribuido.
Este conjunto de aplicaciones est dividido en el protocolo especfico del servicio con el
que estamos trabajando (ODBC, HTTP, SMTP...), el protocolo de transporte (TCP/IP) y
una capa intermedia llamada Network Operating System (NOS).
I.1.
Network Operating System (NOS)
Network
Operating
System
Definicin I.2 Network Operating System. Es una extensin del sistema operativo que
proporciona transparencia al cliente, para que ste realice las llamadas como si fueran locales.
RM-ODP
Algunas de las maneras de proporcionar transparencia del NOS segn RM-ODP (Open
Distributed Processing Reference Model) son
Ubicacin: Ocultar dnde reside cada recurso (y permite que ste se mueva,
incluso mientras est siendo utilizado).
Persistencia: Ocultar tanto la activacin y desactivacin de objetos como sus fallos
y recuperaciones mediante la replicacin.
Concurrencia: Ocultar la utilizacin de recursos concurrentes.
Otras caractersticas deseables para un NOS seran
Prestaciones: Escalar el tamao y reconfigurar el sistema para mejorar sus
prestaciones segn vara la carga de trabajo.
Espacio de nombres:
3 de 112
SSO: Single Sign On - Un nico usuario y contrasea para todo el sistema.

Tiempo: Todos los componentes deben estar sincronizados.
Protocolos: Idntica interfaz de programacin para todos los protocolos de
transporte.
Debido a que la representacin interna de los datos es dependiente del ordenador
(hardware o sistema operativo) es necesario definir un mecanismo para que,
independientemente de la plataforma, la comunicacin sea posible. Algunos mtodos
son utilizar estndares de codificacin de caracteres (ISO-8859-1,UTF-8), XML,
sistemas propios de aplicaciones (RPC,XDR) o un estndar Abstract Synyax Notation
(con una gramtica y reglas para codificar los datos).
I.2.
Servicios de transporte
Una vez hablado del NOS, vamos a ver unos conceptos de servicios de transporte del
middleware.
Lo primero es recordar que hay 2 modelos de interaccin, sncrono o asncrono.
Adems de estos modelos, las interacciones pueden ser de tres tipos.
R: Peticin. (El cliente hace una peticin sin esperar respuesta, por ejemplo para
cerrar la conexin)
RR: Peticin Respuesta.
RRA: Peticin Respuesta ACK.
I.2.1.
APIs directas
API directa
Definicin I.3 APIs directas. API viene de Application Programming Interface (Interfaz de
programacin de aplicaciones).
La utilizacin de APIs directas es la utilizacin de una interfaz de programacin para acceder a
unos servicios (proporcionados por la aplicacin).
Habitualmente son servicios de nivel de transporte o sesin. La ubicacin de extremos
no es transparente para el programa, ya que necesitas saber dnde est la interfaz para
poder utilizarla. Para ver un ejemplo de API, consultar: API de OneDrive.
I.2.2.
Sockets
Son la leche porque proporcionan mucha transparencia: podemos comunicarnos entre

procesos sin tener ni idea de nada, simplemente es como escribir en un fichero (de
hecho, si recordamos de Redes II un socket es directamente un descriptor de fichero en
Linux).
4
Aunque ya deberamos saberlo, incluimos un par de esquemas (sacados de las

transparencias) en los que vemos cmo establecer una comunicacin orientada a
conexin (I.1) y una comunicacin no orientada a conexin (I.2)
Figura I.1: Comunicacin orientada a conexin.
Figura I.2: Comunicacin No Orientada a conexin.
I.3.
Modelos de servicios distribuidos
La base de este curso es cmo dar servicio a muchos clientes. Si tenemos una web a la
que se conectan 10 personas, nos vale con cualquier ordenador, pero Cunta gente usa
google? Ni de coa google tiene un nico servidor haciendo todo, tiene que tener los
servicios distribuidos. A lo largo de esta seccin iremos viendo muchas de las maneras
de llevar esto a cabo.
I.3.1.
RPC - Remote Procedure Calls
Este modelo se basa en realizar llamadas a funciones como si fueran locales, as el

procesamiento de esa funcin no se realiza en local sino en remoto y nos ahorramos
recursos de procesamiento.
Stub
Para el funcionamiento de RPCs necesitamos unos componentes intermedios llamados

Stub. En el siguiente diagrama se entiende perfectamente el funcionamiento de los
RPCs.
Figura I.3: Funcionamiento de una llamada RPC.

Observacin: La espera del cliente es bloqueante.
Observacin: Una ventaja realmente interesante de esto es la transparencia de
representacin de los datos. RPC (y los stubs intermedios) permiten que un cliente
que utiliza Big Endian pueda pasarle los parmetros a una funcin que se ejecute
en un servidor que utiliza Little Endian. Esta transformacin de los datos de un
Marshalling
sistema de codificacin al otro se llama Marshalling (el codificarlos para enviar)
Unmarhsalling y Unmarhsalling (descodificarlos al recibirlos). Ambos stubs tienen que hacer
marshalling y unmarshalling al enviar y recibir mensajes respectivamente.
Problemas de RPC
No existe el paso de parmetros por referencia.
Hay que conocer de antemano dnde est el servidor exctamente y en qu puerto
escucha.
Para saber el puerto en el que el servidor est escuchando, ste tiene que
registrarse en un PortMapper al que el cliente pregunta por el puerto.
PortMapper
Tras un Time Out No se sabe si la llamada se ha ejecutado o no. Para intentar

mitigar este problema en algunos casos, encontramos estrategias distintas en las
llamadas RPC:
Ejecucin Exactamente una vez.
Ejecucin Como mximo una vez.
Operaciones
de
RPC
idempotentes
Ejecucin Al menos una vez.

Para solventar esto es necesario tambin saber si las operaciones son operaciones
de RPC idempotentes (se pueden ejecutar cualquier nmero de veces) o no1 .
1
Por ejemplo un clculo 4 + 4 lo puedes ejecutar todas las veces que quieras, pero un insert en una base
de datos no
Es necesaria una representacin de datos compartida por los stubs.

Seguridad. Y si el servidor ha sido comprometido y me va a devolver datos que
me hagan mal?
Sun RPC
SUN RPC: Una de las implementaciones ms comunes de RPC es Sun RPC. Vamos
a estudiarla un poco ms en detalle.
Tiene 3 componentes:
XDR
XDR Lenguaje de definicin de tipos de datos. Tiene una sintaxis similar a C, pero
es slo de definicin de datos, no de programacin
Especificacin de RPC: Genera los stubs y el fichero de interfaz (para ser incluido
al programar)
Librera de implementacin
Slo por si interesa, incluimos un esquema de cmo funciona y qu ficheros se generan
en la codificacin de un servicio utilizando RPC.
Figura I.4: Compilacin y generacin de cdigo para Sun RPC.
Algunas diferencias entre RPCs

Apollo RPC
Parmetros: Aunque en general soporten mltiples parmetros (Apollo RPC por

ejemplo), Sun RPC slo tiene un nico parmetro, tanto de entrada como de salida
(obviamente pueden ser estructuras).
Marshalling: En general lo hace el RPC, aunque en Sun RPC el marshalling que
se realiza es mnimo. Es responsabilidad del usuario tener cuidado con eso.
NDR
NIDL
Comentamos que Apollo RPC tiene su propio lenguaje de representacin de datos,

Network Data Representation NDR (como el XDR de Sun RPC). Apollo tiene tambin un
lenguaje de representacin de interfaces NIDL (Network Interface Definition Language).
I.3.2.
Web Services (SOAP-WSDL-UDDI)
Es un modelo de uso de la Web. La idea es tener servidores que ofrecen servicios

(localizar geogrficamente a travs de la IP, ofrecer informacin de finanzas...) y que
cualquiera puede requerir esos servicios. Qu diferencia tiene con RPC? Que en
RPC el programador tiene que codificar el lado del servidor y tener conciencia de
como funciona, mientras que con los WebServices, el programador que est haciendo
un cliente puede utilizar los servicios que le proporciona un servidor que otro
programador haya hecho en cualquier otro momento.
Aade un nivel ms de transparencia, ya que el programador del cliente no tiene ni
idea de cmo funciona el WebService.
La funcin del middleware aqu es proporcionar funcionalidad para publicar los
servicios que ofreces y descubrir los nuevos servicios que vayan surgiendo. Adems,
tiene que permitir que los servidores soliciten servicios tambin (multi-tier).
OASIS
Complementos de los Web Services OASIS (Organization for the Advancement of

Structured Information Standards) est trabajando (y ha trabajado) en estandarizar una
serie de complementos tiles para la mejor utilizacin de los Web Services y una serie
de familia de especificaciones:
Complementos:
Seguridad.
Fiabilidad.
Addresing: describir las direcciones de emisor y receptor de un mensaje
dentro del propio mensaje.
Transaction.
WSRL
WSRL - Web Services Resource Framework.

WS-Resource (Conjunto de un recurso y un Web Service a travs del cual se
accede a l.
WS-ResourceProperties
WS-ResourceLifetime
WS-BaseFaults (mecanismo extensible para gestionar errores)
WS-ServiceGroup
Los WebServices necesitan de 3 protocolos estndares. En el siguiente grfico se
muestran los componentes y protocolos de comunicacin utilizados en los WebServices.
Figura I.5: Componentes de un WS para su funcionamiento.

I.3.2.1.
SOAP
SOAP
Definicin I.4 SOAP. (siglas de Simple Object Access Protocol) Es un protocolo estndar que
define cmo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de
datos XML.
Es independiente de la plataforma y el lenguaje de programacin y, aunque se puede usar en
distintos sistemas de mensajes y sobre distintos protocolos de transporte, su uso principal es
transportar RPCs sobre HTTP.
Un mensaje SOAP es un documento XML ordinario con una estructura definida en la
especificacin del protocolo. Dicha estructura la conforman las siguientes partes:
Envelope (obligatoria): Raz que da la estructura, es la parte que identifica al
mensaje SOAP como tal.
Header: Esta parte es un mecanismo de extensin ya que permite enviar
informacin relativa a cmo debe ser procesado el mensaje. Es una herramienta
para que los mensajes puedan ser enviados de la forma ms conveniente para las
aplicaciones. El elemento "Header" se compone a su vez de "Header Blocks" que
delimitan las unidades de informacin necesarias para el header.
10
Body (obligatoria): Contiene la informacin relativa a la llamada y la respuesta.

Fault: Bloque que contiene informacin relativa a errores que se hayan producido
durante el procesado del mensaje y el envio desde el "SOAP Sender" hasta el
"Ultimate SOAP Receiver"
I.3.2.2.
WSDL
WSDL
Definicin I.5 WSDL. WSDL son las siglas de Web Services Description Language, un formato
XML que se utiliza para describir servicios Web.
WSDL describe la interfaz pblica de los servicios Web. Est basado en XML y describe la forma
de comunicacin, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios
para interactuar con los servicios listados en su catlogo. Las operaciones y mensajes que soporta
se describen en abstracto y se ligan despus al protocolo concreto de red y al formato del mensaje
Estructura de una declaracin WSDL

definitions: Elemento raz que contiene el resto. Define su nombre y los espacios
de nombres que utiliza.
types: Tipos de datos utilizados entre cliente y servidor. Usa W3C XML Schema
(XSD) por defecto.
message: Declaraciones de mensajes empleados para peticiones y respuestas y los
elementos que los forman.
portType: Operaciones soportadas y encadenamiento de mensajes que implica su
ejecucin.
binding: Modo en que los mensajes se transmiten sobre un protocolo de RPC, con
extensiones especficas para SOAP.
service: Contiene la informacin de la direccin en la que se localiza el servicio.
I.3.2.3.
UDDI
UDDI
Definicin I.6 UDDI. UDDI son las siglas del catlogo de negocios de Internet denominado
Universal Description, Discovery and Integration. El registro en el catlogo se hace en XML.
UDDI es una iniciativa industrial abierta (sufragada por la OASIS) entroncada en el contexto
de los servicios Web.
Consta de 3 partes: modelo de datos (esquema XML), la API (RPCs con SOAP para
registrar y buscar servicios) y los Cloud Services (los servidores que proporcionan el
servicio).
El registro de un negocio en UDDI distingue tres categoras de datos:
11
Pginas blancas. Direccin, contacto y otros identificadores conocidos.

Pginas amarillas. Categorizacin industrial basada en taxonomas.
Pginas verdes. Informacin tcnica sobre los servicios que aportan las propias
empresas.
UDDI es uno de los estndares bsicos de los servicios Web cuyo objetivo es ser
accedido por los mensajes SOAP y dar paso a documentos WSDL, en los que se
describen los requisitos del protocolo y los formatos del mensaje solicitado para
interactuar con los servicios Web del catlogo de registros.
Ventajas e inconvenientes de los Web Services
Ventajas
Aportan interoperabilidad entre aplicaciones de software independientemente de
sus propiedades o de las plataformas sobre las que se instalen.
Los servicios Web fomentan los estndares y protocolos basados en texto, que
hacen ms fcil acceder a su contenido y entender su funcionamiento.
Permiten que servicios y software de diferentes compaas ubicadas en diferentes
lugares geogrficos puedan ser combinados fcilmente para proveer servicios
integrados.
Inconvenientes
Para realizar transacciones no pueden compararse en su grado de desarrollo
con los estndares abiertos de computacin distribuida como CORBA (Common
Object Request Broker Architecture).
Su rendimiento es bajo si se compara con otros modelos de computacin
distribuida, tales como RMI (Remote Method Invocation), CORBA o DCOM
(Distributed Component Object Model). Es uno de los inconvenientes derivados
de adoptar un formato basado en texto. Y es que entre los objetivos de XML no se
encuentra la concisin ni la eficacia de procesamiento.
Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en firewall
cuyas reglas tratan de bloquear o auditar la comunicacin entre programas a
ambos lados de la barrera.
I.3.3.
REST
REST
Definicin I.7 REST. Si bien el trmino REST se refera originalmente a un conjunto de

principios de arquitectura, en la actualidad se usa en el sentido ms amplio para describir
cualquier interfaz web simple que utiliza XML y HTTP, sin las abstracciones adicionales de
los protocolos basados en patrones de intercambio de mensajes como el protocolo de servicios web
SOAP.
12
Es posible disear sistemas de servicios web de acuerdo con el estilo arquitectural REST de
Fielding y tambin es posible disear interfaces XMLHTTP de acuerdo con el estilo de llamada
a procedimiento remoto (RPC), pero sin usar SOAP.
Estos dos usos diferentes del trmino REST causan cierta confusin en las discusiones tcnicas,
aunque RPC no es un ejemplo de REST.
URI
WADL
Al trabajar con REST se considera que el sistema se compone de recursos, es decir,

elementos que deben ser accedidos en el sistema distribudo y a los que se accede a
travs de su identificador global URI.
La idea es utilizar los mtodos de HTTP para acceder a los recursos y servicios del
servidor. El servidor define su interfaz normalmente utilizando WADL Web Application
Description Language. El programador del cliente tiene que saberse la especificacin
concreta, y saber qu objetos recibe qu peticiones.
Para entender mejor REST, miramos el ejemplo de la API de onedrive:
Figura I.6: API de OneDrive utilizando REST.

Aqu estn descritas las posibilidades que existen en el servidor de OneDrive. Con simples peticiones HTTP podemos funcionar. La peticin https://api.onedrive.com/v1.0/drive/
(un GET de HTTP normal) nos devolvera el directorio con las carpetas que tiene el
usuario con el que nos hayamos autenticado antes. Cmo autenticarse? Con una peticin POST con los datos pertinentes. Y cmo nos devuelve los datos? Lo ms habitual
es en formato JSON aunque tambin puede ser en XML.
La utilizacin de HTTP y JSON/XML hace posible la programacin de clientes en
cualquier plataforma y es una comunicacin ms ligera que SOAP. Un inconveniente
es que es menos transparente2 .
REST es una arquitectura, no un estndar.
2
transparente en el sentido de que no te enteras de nada. Para utilizar REST tienes que saber ms del
servicio que utilizas.
13
I.3.4.
MOM
Comuncacin mediante colas de mensajes
Definicin I.8 MOM. Message Oriented Middleware.

Es un proceso asncrono en el que se genera un mensaje, se encola y se sigue lo que se
estaba. Como mandar un correo electrnico, que se encola en la bandeja de entrada y tu sigues
trabajando.
Las conexiones en colas de mensajes pueden ser 1-1, 1-N, N-1 y N-M.
Situaciones ideales
Conexiones no permanentes y costosas.
Mltiples servidores procesando mensajes de clientes.
Llegada de mensajes impredecibles o en rfagas
Sistemas de tipo publicacin/suscripcin.
Observacin: Permite balanceo automtico de carga en un sistema distribuido. Se

pueden procesar los mensajes con prioridades, no necesariamente FIFO.
Vamos a ver algunos ejemplos de gestores de colas.
I.3.4.1.
IBM Web Sphere MQ
Es el MOM ms extendido. Es multiplataforma y multiprotocolo.

IBM Sphere
MQ
IBM Sphere MQ est formado por

Gestores de colas, encargados de manejar el envo y recepcin de los mensajes,
adems de crear y gestionar el resto de los elementos.
Tiene una API con
Message Queuing Interface (MQI)
Application Messagin Interface (AMI)
Java Messaging Services (JMS)
Colas de mensajes de mltiples tipos.
Canales de comunicacin: Conexiones unidireccionales entre gestores de colas.
A continuacin mostramos un esquema de funcionamiento de un sistema de mensajera
de colas:
14
Figura I.7: Sistema de mensajera de colas.

Vemos que se distinguen 3 tipos de colas, las locales (del propio sistema) y las remotas,
que el sistema reconoce que pertenecen a otro sistema y entonces el mensaje tiene que
ser enviado al sistema al que pertenece la cola remota.
Adems de estos 3 tipos de colas (locales, remotas y de transmisin) podemos definir en
nuestras colas un par de propiedades: persistentes o temporales (en el almacenamiento
de los mensajes) y estticas (definidas permanentemente) o dinmicas (creadas por
aplicaciones). Las colas dinmicas se crean a partir de una cola modelo.
Tambin existen las colas de activacin, y de cartas muertas (con mensajes que no se
han podido entregar)
En resumen, los tipos de colas pueden ser:
Local - remota.
Persistente - temporal.
Esttica - dinmica.
Activacin.
Cartas muertas.
Transmisin.
Ejemplo: Una de las utilidades de MOM son los servicios de publicacin/suscripcin. A

continuacin incluimos un esquema que muestra perfectamente cmo funcionan este tipo de
sistemas.
15
Figura I.8: Sistema publicador/suscriptor.
I.4.
Services Oriented Architecture SOA
I.4.1.
ESB - Enterprise Services Bus
Extendiendo el modelo de publicador/suscriptor tenemos un ESB. El ESB acta

como proceso centralizador de solicitudes de los clientes (normalmente mensajes o
solicitudes de ejecucin de acciones tipo RPC Web Services) para su distribucin a
los servidores.
Figura I.9: Enterprise Service Bus.

A continuacin, estudiamos las ventajas e inconvenientes que puede tener un sistema
como este:
Ventajas:
Adaptacin rpida en entornos existentes.
Flexibilidad. Fcil de adaptar a nuevos requerimientos.
16
Basado en estndares.
Existencia de tipos de servicios y APIs predefinidas y listas para su uso.
Convierte tareas de programacin en configuracin (manipulacin de datos, por
ejemplo).
Facilita la gestionabilidad del sistema, al proporcionar un punto nico de control
para todos los intercambios.
Inconvenientes:
Posible punto nico de fallo.
Fcil saturacin del ESB a cargas altas de comunicacin.
Sin una planificacin correcta de APIs y conectores no evita la conexin lgica
punto a punto entre clientes y servidores, slo la fsica.
Requiere ms sistemas en ejecucin, para soportar el propio ESB.
Introduccin de un elemento adicional en la cadena de procesamiento, con lo cual
el rendimiento se puede ver afectado.
Escasas ventajas para entornos sencillos. Estas se ven ms en situaciones
complejas, con muchos tipos de clientes y servidores.
I.4.2.
RMI - Remote Method Invocation
Igual que en programacin estructurada podamos ejecutar funciones remotamente

(con RPC), con la programacin orientada a objetos (POO) tambin podemos tener
localmente una referencia a un objeto remoto y ejecutar mtodos del objeto remoto.
Para ello es necesario disponer de un middleware espefcico, con unos mdulos de
comunicacin y de referencia remota.
Figura I.10: Esquema de funcionamiento de RMI.

En RMI tambin es necesario realizar marshalling y unmarshalling. El componente
encargado de hacerlo es el esqueleto (del objeto remoto).
17
El otro componente que merece mencin es el mdulo de la referencia remota. El objeto

que tiene el cliente es una referencia que el mdulo de referencias remotas se encarga
de traducir la referencia local (a algo remoto) a una referencia remota (al objeto remoto).
CORBA
OMG
DCOM
Aparte del RMI de Java, existen otras alternativas, como CORBA (Common Object
Request Broker Architecture) creada por OMG (Object Management Group) y DCOM
(Distributed Component Object Model) creada por Microsoft.
I.4.2.1.
OMA
OMA
Definicin I.9 OMA. Object Management Architecture.

Establece 2 modelos. Un modelo de objetos y uno de referencias.
Vamos a ver el modelo de referencias.
Figura I.11: Esquema de funcionamiento del modelo de referencias de OMA.
Object Request Broker, ORB: Bus de comunicacin entre objetos.

Common Object Services: Gestin del ciclo de vida, persistencia, resolucin de
nombres, tiempo, control de concurrencia, seguridad...
Common Facilities: Colecciones de componentes, con funciones de tipo general,
pero orientados a aplicaciones finales en vez de al sistema.
Domain Interfaces: Coleccin de componentes/objetos comunes especficos para
reas de aplicaciones: comercio electrnico, telecomunicaciones, banca, salud,
fabricacin...
Application Interfaces: Interfaces especficas de aplicaciones concretas.
ORB
Definicin I.10 ORB. Object Request Broker Bus de comunicacin entre objetos.
18
Es un middleware avanzado que es la repera y permite :

Permite llamadas estticas y dinmicas a objetos. Incluye descubrimiento dinmico de
objetos.
Describir las interfaces independientemente del lenguaje de programacin. El lenguaje de
descripcin se llama IDL (Interface Description Language)
IDL
Enlace directo de aplicaciones escritas en mltiples lenguajes de alto nivel (no

necesariamente orientados a objetos).
Sistema auto-descrito. Genera meta-informacin consultable dinmicamente.
Soporte de seguridad,transacciones y autenticacin de las comunicaciones
Polimorfismo en la ejecucin de funciones asociadas a un mismo mensaje.
IDL
Definicin I.11 IDL. Interface description language.

Del cdigo IDL se crean los stubs necesarios (cliente y servidor3 ) y los ficheros
de definiciones. Adems, se genera cdigo fuente del lenguaje elegido, definido en
CORBA.
Este es el esquema de desarrollo de un sistema con CORBA.
Figura I.12: Esquema del desarrollo de CORBA.
I.4.2.2.
Microsoft
COM
Microsoft COM
Definicin I.12 Microsoft COM. Microsoft Component Object Model - Plataforma de objetos
3
Los stubs de servidor se llaman skeletons
19
de microsoft.
DDE
OLE
DCOM
Esta plataforma de objetos ha ido mejorandose y evolucionando a lo largo del

tiempo. Primero fue DDE (Dynamic Data Exchange) que mejor la comunicacin entre
aplicaciones con OLE (Object Linking and Embedding) hasta llegar a COM, con su
versin de objetos distribuida DCOM y por ltimo, al integrarlo con MTS y MSMQ se
ha llegado a COM+
MTS
Definicin I.13 MTS. Microsoft Transaction Server
MSMQ
Definicin I.14 MSMQ. Microsoft Message Queueing
MIDL
DCE
Caractersticas Un objeto COM es un objeto en el mismo sentido que en CORBA, es

independiente del lenguaje de programacin y cada objeto tiene una o varias interfaces.
Estas interfaces se definen con el Lenguaje de Definicin de Interfaces de Microsoft
(en ingls MIDL). Este lenguaje est basado en el IDLI.10 del Distributed Computing
Environment (DCE) que utiliza Apollo RFC.
Los sistemas COM se organizan en componentes COM que son mdulos binarios
(ejecutables o libreras dinmicas). Estos mdulos pueden contener uno o varios objetos
COM, una interfaz grfica e incluso otro componente4
Funcionalidades
Transparencia de la localizacin de los objetos.
SCM
Activacin de los objetos a distancia (a travs del SCM (Service Control Manager)
NTLMP
SAM
Seguridad en las comunicaciones (NTLMP (NT Lan Manager Protocol) y SAM

(Security Access Manager)
Descubrimiento dinmico de interfaces (no hay que recompilar todo cuando en
un objeto se incluya una interfaz para que podamos utilizarlo)
Reutilizacin de objetos por agregacin y contenencia (no herecia)
I.4.3.
Java RMI
Vamos a ver ahora cmo implementa Java la idea de Remote Method Invocation.
Existe desde Java 1.1 y es ms sencillo que CORBA. La arquitectura est basada en 3
niveles: Proxy, Referencia Remota (gestiona las referencias remotas) y Transporte (JRMP
- Java remote Method Protocol). Sobre estas 3 capas se construye el cliente y el servidor.
Cabe mencionar que el proxy del servidor se denomina esqueleto.
4
Si un componente incluye a otro, el grande se llama componente ActiveX
20
Observacin: No hay soporte para objetos programados en otro lenguaje (como si

permitan las anteriores opciones)
Para programar con Java RMI hay que seguir los siguientes pasos:
Definir las interfaces remotas (extendiendo java.rmi.Remote)
Implementar las clases remotas
Crear proxy y esqueleto compilando con rmi
Crear la aplicacin como servidor de la clase remota
Crear la instancia
Se registra en el servicio de nombres.
Arrancar RMIRegistry y el servidor de la clase remota.
Ya podemos crear clientes con referencias remotas a objetos de la clase
implementada.
Paso de parmetros
Todos los parmetros son de entrada salvo el retorno del mtodo.
Admite objetos remotos como parmetros (que obviamente se pasan por
referencia)
Admite objetos locales como parmetros slo si son serializables (que se pasan
por valor)
I.5.
Servicios de directorio global
Reflejan la composicin del sistema en todo momento, gestionando el estado de los

sistemas que pertenecen a l (pertenencia dinmica) y gestionando las aplicaciones que
contiene cada sistema. Estos sistemas tienen que ser Cliente/Servidor para poder ser
gestionados por un servicio de directorio global.
Estos servicios se encargan de resolver las transparencia con la ubicacin y cada entrada
tiene todos los datos asociados al elemento como el estado y la ubicacin fsica5 , aparte
de otras variables (estadsticas por ejemplo).
I.5.1.
Namespaces
Namespaces
Estos servicios de directorio globales utilizan namespaces, es decir, espacios de

nombres, de modo que los elementos se pueden reconocer por un nombre en un
directorio.
5
El servicio de directorio tiene que conocer las ubicaciones fsicas y las direcciones para poder ofrecer
transparencia a los sistemas que lo utilicen
21
Los nombres deben ser nicos (normalmente asignados por una autoridad dentro del
dominio) y no deben contener informacin de la localizacin fsca, as se garantiza
mejor la transparencia a la ubicacin.
Este es un ejemplo de un espacio de nombres jerrquico
Figura I.13: Espacio de nombres jerrquico.

Estos espacios de nombres se pueden utilizar tambin orientndolo a objetos, de
tal manera que cada entrada es una instancia de un objeto. Tambin se pueden
tener distintas copias para cada dominio o distribuirlo organizndolo en servicios
administrados separadamente ya que el acceso dentro de un dominio slo requiere un
nombre local.
X.500
Estndar X.500
estndar
Vamos a definir unas cuantas siglas6 necesarias para explicar este
XDS
Definicin I.15 XDS. APIs de X/Open Direcrory Service
DUA
Definicin I.16 DUA. Directory User Agent
DAP
Definicin I.17 DAP. Direcroty Access Protocol
DSA
Definicin I.18 DSA. Directory System Agent
DSP
Definicin I.19 DSP. Direcroty System Protocol

6
Por si acaso no llevamos ya suficientes
22
Los clientes contienen el DUA y se comunicacn con los servidores utilizando DAP.
Los servidores contienen el DSA y se comunican entre servicores utilizando DSP.
Al directorio en s se accede con las APIs de XDS.
Figura I.14: Esquema de funcionamiento del estndar X.500.

LDAP
Existe una alternativa al DAP que es el LDAP (Lightweigth Directory Access Protocol).
Este protocolo no requiere espefcicamente de un directorio X.500, puede utilizarse con
Microsoft Active Directory.
Esto es un protocolo de comunicaciones, no es una especificacin de directorio ni una
API de programacin. No confundirse.
I.5.2.
Servicios de tiempo
Es bsico y fundamental que cuando tenemos un sistema distribuido todos los relojes
estn perfectamente sincronizados. Para ello existen los servicios de tiempo que vamos
a estudiar a continuacin.
Sincronizar 2 personas sus relojes es fcil, porque los 2 ven en el mismo instante de
tiempo los 2 relojes. 2 ordenadores separados no pueden ver los relojes a la vez, ya
que el mensaje con la hora que tiene cada uno tarda en llegar, es por ello que cada
ordenador mantiene un componente de inexactitud y que es necesario sincronizar
peridicamente cuando ese componente de inexactitud supere un umbral definido7
Mantener sincronizado el tiempo es imporescindible para la consistencia y para la
seguridad.
Timer ticks
UTC
Para lograr esta sincronizacin existen proveedores de tiempo (timer ticks) que
pueden sincronizar por radio y actualizar el reloj del administrador de nuestro sistema
distribuido. Podemos conectar ms de un servidor a estos proveedores.
Una vez tenemos definidos los servidores de nuestro servicio con la hora buena
(sincronizados con los timer ticks) el resto de nuestros servidores realizan consultas
para sincronizar sus relojes. El formato utilizado es UTC (Universal Time Coordinated)
que cuenta desde el principio del calendario gregoriano.
7
Tal vez nos podemos permitir 0.01 segundos de desincronizacin, pero no podemos permitirnos 0.05
23
I.5.2.1.
NTP
NTP
Y cmo implementamos o utilizamos un servicio de tiempo? Con el NTP Network Time

Protocol, que define una arquitectura para un servicio de tiempo y un protocolo para
distribuir la informacin del tiempo.
Precisin en la sincronizacin a UTC.
Fiabilidad
Actualizaciones frecuentes (por lo que ser necesario que sea resistente a alto
nivel de carga)
La red de servidores est organizada jerrquicamente. El primer estrato recibe UTC de
fuentes fsicas de tiempo (llamadas estrato 0 en wikipedia) y el estrato 2 sincroniza con
los primeros. El resto de la red sincroniza con el estrato 2.
Veamos un ejemplo de los clculos necesarios para sincronizar dos servidores.
Ejemplo: El esquema de la comunicacin (intercambio de mensajes) entre los dos servidores

que se van a sincronizar es:
Nuestro objetivo es calcular o, que es la diferencia de tiempos entre ambos relojes. Observando
el esquema, podemos deducir las ecuaciones:
Ti3 + o + t = Ti2
(I.1)
(I.2)
Ti + o = Ti1 + t
Tampoco conocemos t n t0 , pues no sabemos el tiempo que ha tardado el mensaje en ser

transmitido. Si sumamos las dos ecuaciones y despejamos o de la nueva ecuacin nos queda:
o=
Ti2 + Ti1 Ti Ti3 t0 t

+
2
2
{z
}
|
oi
As, tenemos o escrito como la suma de un valor conocido ms una desviacin. Puesto que todos
los tiempos son positivos, tenemos que t + t0 > t0 t por lo que podemos acotar o mediante:
d
z }|i {
z }|i {
0
t +t
t0 + t
oi
o oi +
2
2
24
Tolerancia
mnima de
reloj
Parece que a la diferencia t 2+t se le llama tolerancia mnima de reloj. Esta tolerancia se obtiene
restando las 2 ecuaciones iniciales.
Ti3 + o + t Ti o = Ti2 Ti1 t0 = t + t0 = di = Ti1 + Ti + Ti2 Ti3 (I.3)
I.5.3.
Seguridad
Aunque es un tema superimportante (porque en un sistema distribuido se complican

las cosas) y tiene un tema dedicado explcitamente a esto, no se va a ver en este curso
porque ...
25
I.6.
Problemas
Ejercicio 1.1: Disear, a nivel de bloques, un sistema por el cual un middleware pudiera
soportar redundancia en un servidor de archivos planos (tipo disco compartido) de modo
transparente a la aplicacin y los servidores que intervienen en la conexin.
Ejercicio 1.2: Uno de los principales problemas que tiene que tratar cualquier middleware
que comunique ordenadores de distinto tipo es la transparencia del formato de representacin
interno de los datos en cada componente de la red. Estudiar las ventajas e incovenientes de
cada una de estas tres posibles alternativas en distintas situaciones de sistemas distribuidos:
Convertir todos los datos al formato interno de uno de los componentes de la red.
Convertir todos los datos a un formato intermedio de intercambio.
No realizar ninguna conversin en el Middleware, y dejar que cada aplicacin realice
las conversiones que considere oportunas.
Dejuan opina que:

Convertir todos los datos a un formato intermedio requiere que tanto el cliente como el
servidor realicen una conversin. Si pensamos en trminos de idiomas entre personas
se entiende muy fcilmente. Si yo hablo ruso y tu chino, para qu vamos a aprender
los 2 espaol?
Mejor ser que yo aprenda chino o tu ruso, es decir, convertir todos los datos al formato
de uno de los componentes require menos trabajo (por lo menos a los componentes que
no tienen que convertir nada).
En cuanto a no realizar ninguna conversin, la ventaja que presenta es que el
middleware es un software ms ligero porque tiene menos funciones, pero presenta la
gran desventaja de que a los desarrolladores les obliga a conocer las representaciones
internas de los datos de los componentes del sistema distribuido y les aade una
complejidad innecesaria.
Ejercicio 1.3:
En un sistema de comunicaciones mediante RPCs, estudiar el lugar
adecuado para introducir la funcin de conversin del formato de representacin de los datos
descrita en el problema anterior. Nota: Basarse en la figura I.3.
Dejuan opina que:

Suponiendo que el formato elegido sea el del servidor, el cliente tendra que realizar el
marshalling al enviar un RPC en el momentos 2 (al enviar) y el unmarshalling en el 10 (al
26
recibir) de la imagen, cuando el Client stub codifica y descodifica8 respectivamente el

mensaje para drselo al nivel de transporte.
Ejercicio 1.4:
Sugerir alguna alternativa al servicio portmapper empleado en la
comunicacin mediante RPCs para conocer la direccin (puerto) del servidor con el que se
desea comunicar, basado en alguno de los servicios que puede desempear un middleware.
Dejuan opina que:

RM-ODP define que el NOS I.2 (una de las 3 capas del middleware) puede proporcionar
transparencia ofreciendo un servicio de nombres y transparencia a la ubicacin,
movilidad y reubicacin.
Si se definiera un espacio de nombres o se incluyera la funcionalidad de conocer los
puertos en el NOS solucionaramos la necesidad del portmapper
Ejercicio 1.5: Un determinado sistema distribuido requiere que cada servidor autentique
la conexin de sus clientes mediante la introduccin de un identificador de usuario y una
contrasea. Supuesto que posee un middleware genrico, disear sobre l un servicio que
permita a las aplicaciones clientes realizar una validacin nica de usuario y contrasea,
independientemente del nmero de servicios que sea necesario utilizar.
Dejuan opina que:

No entiendo bien la pregunta. Para disearlo en serio hara falta ms informacin.
Por middleware genrico tampoco entiendo qu incluye. Una de las caractersticas
deseables del NOS es Single Sign On, SSO, un nico usuario y contrasea para todos los
servicios. Si el middleware genrico que tenemos incluye un NOS con SSO, entonces
tendramos que aadir la funcionalidad de permitir inicio de sesin distribuido,
sabiendo que el usuario y la contrasea es la misma para todo el sistema.
Hecho por Pedro. Se aceptan correcciones.
Entiendo que lo que piden es describir una arquitectura o procedimiento que te permita
llevar a cabo esta tarea.
Suponiendo que tenemos un sistema con varios servidores, podemos hacer que uno de
ellos sea el encargado de la autenticacin de los usuarios. Una vez que este servidor
comprueba que tienes permisos de acceso te devuelve un identificador y el mismo
identificador codificado con su clave privada (a modo de firma).
Cada vez que el cliente conecte con alguno de los servidores, enviar este identificador
junto con la firma con lo que el servidor destino slo tendr que coger su clave para
comprobar que el cliente ya est loggeado.
Al margen de las claves que permitan relacionarse a un servidor con otro a travs
del cliente de modo seguro, seran necesarias ms pares de claves de modo que la
8
tal vez codifica y descodifica no son las palabras adecuadas
27
comunicacin cliente-servidor tambin fuese segura.
Ejercicio 1.6: Partiendo del esquema de comunicacin entre programas a travs de la

interfaz socket (I.2), ampliar el esquema correspondiente al programa servidor para que sea
capaz de atender conexiones simultneas de varios programas clientes.
Sugerencia: Utilizar una tarea en el servidor por cada conexin.
Dejuan opina que:

La interfaz de socket a la que se refiere el enunciado (la de la pgina 12 de las
transparencias) es socket no orientado a conexin.
Para poder atender simultneamente conexiones, habra que crear hilos antes del
rcvfrom() para que atendieran a los diversos clientes.
Ejercicio 1.7:
Un sistema de control de inventario central recibe los movimientos de
mercanca que se realizan en su red de almacenes, y de ellos debe ser capaz en todo momento
de conocer la cantidad de cada producto que existe en toda la red. Proponer el mecanismo
de comunicaciones que se considere ms adecuado para realizar estos envos, considerando
distintos casos:
a) Todos los sistemas operan simultneamente, y disponen de enlaces de comunicaciones
dedicados.
b) Todos los sistemas operan simultneamente, pero los enlaces de que disponen son
conmutados.
c) Los sistemas tienen distinto horario de funcionamiento.

Entendemos que tenemos un sistema de varios servidores (conectados, obviamente,
a muchos clientes pero eso no nos importa) y queremos que estn correctamente
sincronizados estos servidores, de modo que si un cliente compra algo, el stock de todos
se reduzca.
A PARTADO A )
Si tienen enlaces de comunicacin dedicados es posible que cada servidor informe al
resto en tiempo real de todos los cambios que se experimentan, de modo que todos los
servidores pudieran tener siempre informacin actualizada.
A PARTADO B )
Si los enlaces son conmutados, al mandar un servidor un mensaje, el enlace queda
bloqueado, por lo que una comunicacin en tiempo real no sera viable. No se
exactamente qu se debera hacer aqu
28
A PARTADO C )
Por definicin, parece que lo ptimo es el empleo de una cola de mensajes donde los
servidores informan de los cambios. Cuando un servidor arranque, antes de empezar a
trabajar, actualiza su informacin en base a los mensajes de la cola.
Ejercicio 1.8: Nombrar casos de comunicacin entre aplicaciones en los que sea preferible
emplear colas no persistentes en lugar de colas persistentes. Razonar la respuesta.
Dejuan opina que:

Recordamos que persistencia en colas significa que persistan los mensajes de la cola, no
la cola en s. (La persistencia de la cola se llama temporalidad).
Si eres el de misin imposible y quieres que los mensajes con la misin que mandas se
autodestruyan, puede ser interesante implementar una cola no persistente.
En general puede ser interesante cuando no te preocupe preservar o no los mensajes,
puesto que hacer la cola persistente implica un coste extra que puedes ahorrar.
No creo que haya ningn momento en que te interese perder la informacin,
simplemente puede darse el caso de que no rente el coste necesario para mantener esos
mensajes en caso de fallo.
Ejercicio 1.9:
Enumerar las ventajas e inconvenientes que puede tener sustituir un
mecanismo de comunicacin entre procesos interno de un sistema operativo (eras de
memoria compartidas, archivos, named pipes, etc.) por colas locales de MQSeries para
comunicar dos aplicaciones en el mismo ordenador. Justificar brevemente cada una de ellas.

Para empezar es posible que no nos interese emplear colas de mensajes. Si necesitamos
que una aplicacin espere hasta que la otra finalice el proceso nos interesar emplear
mecanismos de comunicacin como los sockets en lugar de colas.
Puestos a que nos interese el empleo de colas, las colas de MQSeries tienen el problema
de que implican ms carga de trabajo para el sistema operativo, pues en el fondo sern
otro programa que se est ejecutando en el mismo host.
Una posible ventaja del empleo de colas MQSeries es que, si tienen appis adecuadas
para distintos lenguajes de programacin, puede ser ms sencilla la comunicacin con
ellas, pues las llamadas al sistema no son igual de sencillas en todos los lenguajes.
Frente al empleo de reas de memoria compartidas o sistemas de archivos, se tiene la
ventaja de que las colas de mensajes, y en concreto las de MQSeries, permiten gestionar
fcilmente el control de los mensajes ledos y los destinatarios de los mismos.
29
Ejercicio 1.10: Un sistema de directorio de nombres jerrquico consta de un nodo raz, que
denominaremos A, y tres nodos secundarios que dependen de l, que denominaremos B, C
y D, respectivamente. No existe replicacin de la informacin en ninguno de los servidores
de nombres de la estructura, de modo que cada servidor slo contiene la informacin de
las estaciones que dependen de l. Expresar el flujo de mensajes que debe tener lugar para
que una estacin del nodo B, que denominaremos B1, pueda recuperar la informacin de
directorio de una estacin dependiente del nodo C, denominada C1.

1 B1 pregunta a B por C1
2 B no conoce a C1 (slo conoce a las estaciones que dependen de l), as que manda
a B1 a preguntar a A, pasndole su direccin IP
3 B1 pregunta a A por C1 y A reconoce que estar asociado a C por que le enva a
B1 la direccin de C. Dejuan opina que A debera preguntar a C y a D a ver de
quin es C1, porque A slo conoce los que dependen de l, no?
Pedro manda a de Juan y a aquellos que tengan esta duda a mirar el ejercicio 20,
que resolvi la profesora y en el que se observa que tu no buscas C1 a pelo sino
que lo buscas conociendo su nombre completo. Es decir, ests buscando A.C.C1
4 B1 pregunta a C por C1 y este, puesto que C1 depende de l, lo conoce y le dice a
B1 la direccin de C1
5 B1 conecta con C1
Ejercicio 1.11:
Determinar la tolerancia mnima de reloj que es necesario considerar
debido a la propagacin de la informacin por el medio fsico en un sistema que sincronice
desde un servidor de tiempo central los relojes de todas sus estaciones en los siguientes casos:
a) Entorno de red de rea local de un tamao mximo de 500 m.
b) Entorno de red de rea extendida, mxima distancia de 600 Km.
c) Entorno de red transocenica por cable coaxial, mxima distancia entre nodos de 10.000
Km.
d) Red VSAT (Very Small Aperture Terminal, red de comunicaciones va satlite) con nodo
de retransmisin en un satlite en la rbita geoestacionaria (36.000 Km. sobre el ecuador).
Notas: - Considerar la velocidad de propagacin de un campo electromagntico en un

cable aproximadamente igual a 2/3 de la velocidad de la luz en el vaco.
- No se consideran efectos de elementos intermedios de la comunicacin, ni a nivel fsico
(amplificadores, regeneradores de seal) ni a niveles superiores (puentes o routers).
30

Me niego a hacer los clculos, hacemos cuentas para obtener el tiempo de transporte
y atendiendo a las cuentas realizadas en el ejemplo I.5.2.1, vemos que la tolerancia
0
0
mnima es t+t
2 donde t y t son los tiempos de transporte del mensaje en ambas
direcciones.
Dejuan se anima a hacer las cuentas
Recordamos que la velocidad de la luz es c = 3 108 m/s, con lo que vp = 2 108 m/s.
A PARTADO A )
t=
500m
d
=
= 2.5 106 s
vp
2 108 m/s
A PARTADO B )
t=
600Km
d
=
= 3 103 s
vp
2 108 m/s
t=
d
106 m
=
= 5 102 s
vp
2 108 m/s
t=
d
36 106 m
= 1.8 101 s
=
vp
2 108
A PARTADO C )
A PARTADO D )
Ejercicio 1.12:
A efectos de asignacin de nombres a los distintos recursos que lo
componen, un determinado sistema distribuido se encuentra dividido en distintos dominios
administrativos, organizados de modo jerrquico segn al esquema:
31
Los nodos en cursiva representan ordenadores, y los nodos en negrita, los dominios.
Cada dominio tiene un servidor de nombres propio, que reside en un ordenador cuyo
nombre coincide con el del dominio, con capacidad de almacenamiento local de resultados
de consultas a otros dominios (cache). Inicialmente se supone que todas las caches de los
dominios se encuentran vacas.
a) Poner los nombres completos en el dominio global de cada uno de los ordenadores
representados en cursiva en la figura.
b) Detallar los mensajes que sern necesarios y entre qu sistemas deben circular para que el
ordenador atlas localice el servidor salarios en el directorio a partir de su nombre en la red.
c) Inmediatamente despus de la anterior consulta, el ordenador axis necesita establecer una
conexin con salarios. Indicar el flujo de mensajes que ocurrir para que pueda localizarlo
en el directorio.
d) Supuesto que el sistema de nombres que se emplea sigue el estndar X.500, nombrar:
Ordenadores que contendrn un Directory User Agent.
Ordenadores que contendrn un Directory System Agent.
Tres parejas de ordenadores entre las que se emplear un Directory Access Protocol.
Tres parejas de ordenadores entre las que se emplear un Directory System Protocol.
e) Proponer un sistema de comunicaciones (peer to peer orientado a conexin, no orientado
a conexin, Remote Procedure Calls, colas de mensajes) para producir los intercambios de
mensajes de resolucin de nombres en el directorio, y razonar la respuesta.

A PARTADO A )
No pienso escribirlos todos. Es trivial. Por ejemplo, en el caso del host hrcules su
nombre completo en el dominio global sera empresa/tcnico/pruebas/hrcules
A PARTADO B )
Equivalente al ejercicio 10.
1 Atlas pregunta a desarrollo por salarios
2 Desarrollo pregunta a tcnico por salarios
3 Tcino pregunta a empresa por salarios
4 Empresa pregunta a gestin por salarios
5 Gestin pregunta a administracin y a direccin (segn Dejuan) por salarios
32
6 Administracin enva a gestin la direccin de salarios

7 El mensaje recorre la cadena en direccin contraria hasta llegar a atlas
A PARTADO C )
Suponiendo que los servidores guardan en la cach informacin de las consultas
recientes, el servidor desarrollo ya tiene guardado en cach la direccin de salarios, por
lo que le responde directamente a axis
A PARTADO D )
Directory User Agent:
Los que estn en cursiva
Directory System Agent
Los que estn en negrita
Directory Acces Protocol
axis-atlas
atlas-hrcules
salarios-bigboss
Directory System Protocol
desarrollo-tcinico
empresa-gestin
administracin-direccin
A PARTADO E )
La cola de mensajes no tiene sentido pues necesitamos obtener respuestas en tiempo
real.
Peer to peer tampoco termina de encajar con la lgica del sistema, pues hay un claro
comportamiento jerrquico y cada host pregunta de forma nica a otro host y no
pregunta a un tercero hasta no obtener su respuesta.
El mtodo ms interesante sera RPC donde cada host establece comunicacin directa
con aquel con el que quiere comunicarse. Adems no tenemos que preocuparnos por la
representacin interna de los datos por lo que cada no podra estar programado en un
lenguaje completamente diferente.
A Dejuan no le gusta RPC porque no necesitamos ejecutar funciones que se encuentren
en otros servidores, simplemente queremos hacer una pequea consulta por lo que lo
que ms le convence es peer to peer (porque no slo hablas con el de arriba sino tambin
con los que puedan tener debajo) y como no son muy frecuentes las consultas (debido
a la cach) opina que lo ideal sera no orientado a conexin.
33
Ejercicio 1.13:
Se desea realizar un servidor para una red de rea local que acte
como punto focal de recepcin de alarmas que se produzcan en las estaciones de trabajo
ante situaciones de diversos tipos (conexin de estacin, fallos de programas, errores en
disco,introducciones de contraseas equivocadas, etc.).
a) Enumerar los mecanismos de comunicaciones que se pueden emplear para enlazar los
clientes con el servidor para realizar esta funcin u otras similares.
b) Valorar el empleo de cada uno de los mecanismos anteriores para realizar la aplicacin, y
elegir la que se considere ms apropiada a este caso, razonando la respuesta.
c) Si el prototipo de funcin que se desea utilizar en las estaciones clientes para enviar una
alerta es el siguiente:
long
char
char
char
long
);
alerta (
tipo_alerta,
// Tipo de alerta que se ha producido
nivel_gravedad,
// Nivel de gravedad de la misma
* datos_adicionales,// Texto informativo dado por el cliente
* codigo_accion
// Accin recomendada por el servidor
// para resolver la situacin.
en la que el valor que retorna la funcin indica si se ha completado correctamente o no la

funcin, tanto por motivos de la red como del servidor, definir:
Una estructura de mensaje apropiada para la comunicacin entre cliente y servidor.
Explicar el proceso de Parameter Marshalling que ser necesario realizar en el cliente
antes del envo del mensaje. (Sugerencia: emplear C o pseudocdigo, comentado).
Explicar el proceso de Parameter Unmarshalling que ser necesario realizar en el
cliente al recibir el mensaje de contestacin. (Igual sugerencia).

A PARTADO A )
Puestos a enumerar tendramos: WS, P2P, RPC y colas de mensajes como principales
opciones. Dejuan opina que RPC no es un mecanismo de comunicacin sino de
ejecucin de servicios remotos, con lo que no lo considera una opcin. Por otro lado,
dentro de WS no hay que olvidarse de una arquitectura REST.
A PARTADO B )
Vamos a analizar cada posibilidad por separado
WS
Sera fcil de emplear pero bastante lento para la comunicacin. Adems requiere
comunicacin sncrona lo cual puede no ser demasiado interesante a la hora de
que muchos servidores enven mensajes a un nico punto.
34
Dejuan opina que no tiene mucho sentido utilizar un WS, ya que el servidor
no ofrece ningn servicio, simplemente tiene que ser informado. Es por ello
que aunque utilizramos REST tiene poco sentido. Incluso aunque REST es
muy til en este caso ya que es vlido para sistemas heterogneos. Adems, la
comunicacin sera muy sencilla basndonos en peticiones POST de HTTP. Esta
opcin si permitira comunicacin asncrona.
P2P
No encaja con la idea del trabajo a desarrollar puesto que tenemos una clara
jerarqua con un nico nodo con el que nos queremos comunicar. Adems fuerza
a que todas las estaciones de servicio acuerden un mismo lenguaje, pues no est
ideado para host heterogneos.
RPC
til para trabajar con host heterogneos pues el propio middleware se encargar
del marshalling y unmarshalling. Establece conexin directa entre los dos hosts
que se quieren comunicar.
Colas de mensajes
Independiente de la plataforma sobre la que se implemente cada estacin de
trabajo salvo por el formato de los mensajes, que se debe acordar previamente.
Permite la comunicacin asncrona, cosa que no permitan ninguna de las
anteriores opciones.
Puesto que queremos que cada estacin de servicio enve la alarma y siga trabajando
en detectar posibles fallos y, presumiblemente, habr diferentes categoras de alarmas,
lo ms interesante sera el empleo de colas de mensajes que ayudan a la organizacin
jerrquica de los errores y evitan la saturacin del ordenador central.
A PARTADO C )
Basta con que el mensaje tenga 2 campos, cada uno de los cuales se corresponde
a uno de los strings que forman parte de la alerta. El tipo del mensaje ser el tipo
de alerta y la prioridad ser el nivel de gravedad.
El marshalling ser el proceso de escribir el mensaje a partir de una variable de
tipo alerta.
El unmarshalling ser justo el proceso contrario, a partir de un mensaje se
construye una variable de tipo alerta.
Ejercicio 1.14:
A continuacin se presentan cuatro casos de sistemas servidores.
a. Servidor de archivos Unix para una red de ordenadores personales en MS-DOS. Los
clientes deben ver el disco del servidor como si fuera un disco local.
35
b. Servidor de envo diferido de fax. El servidor del que se dispone permite a los clientes
conectados a l a travs de una red de comunicaciones enviar un fax desde su estacin,
compartiendo una nica lnea de telfono y aprovechando las horas de menor coste de
las llamadas telefnicas.
c. Servidor de emulacin de terminales. Permite a sistemas clientes ASCII acceder al
ordenador servidor, que trabaja con cdigo EBCDIC, como si se encontraran en una
pantalla local del mismo.
d. Servidor de validacin de contraseas para una red de ordenadores homognea.
Recibir un identificador de usuario y contrasea, debidamente cifrados, y contestar
al cliente nicamente si ambos son correctos, enviando un mensaje de reconocimiento.
Para cada uno de ellos se pide:
Elegir razonadamente el mecanismo de transporte (peer to peer orientado a conexin,
peer to peer no orientado a conexin, RPCs, colas de menajes) que sera aconsejable
utilizar para conectar a ellos los sistemas clientes.
Indicar, si es necesario, las funciones adicionales que habra que implementar sobre
el protocolo elegido para garantizar que el middleware resultante garantizara la
transparencia de acceso del sistema distribuido.
a. Puesto que los ordenadores sern heterogneos (ordenadores personales en MSDOS pero servidor de archivos UNIX) ser necesario un proceso de marshalling y
unmarshalling. Un nico fichero puede estar repartido entre mltiples servidores
pero los clientes no deben notarlo.
Adems necesitamos un acceso rpido y ligero, por lo que lo ms interesante sera
el uso de RPC.
b. Puesto que el envo del fax no se realizar en el instante exacto en que se
selecciona la opcin sino que se aprovecharn las horas de menor coste de las
llamadas telefnicas, lo ms apropiado sera el empleo de una cola de mensajes.
El cliente que quiera mandar un fax deja un mensaje en el servidor y este, cuando
la lnea est desocupada, tomara un mensaje de la cola y enviar el fax pedido.
c. Es necesaria comunicacin fiable sin prdida de paquetes o los comandos que se
ejecuten podran llegar incompletos dando lugar a resultados inesperados. Por
tratarse de sistemas heterogneos (unos emplean ASCII y otros EBCDIC) sera
recomendable el uso de RPC que se encarga del unmarshalling y marshalling de
manera transparente a los usuarios.
La solucin de la profesora dice que no merece la pena el RPC puesto que la
funcionalidad de traduccin necesaria es muy sencilla. Por tanto emplean P2P
orientada a conexin
d. Los dos sistemas tienen que estar conectados a la vez. La red es homognea,
luego no es necesario traduccin de datos para garantizar transparencia de acceso.
Puesto que la funcionaldiad es muy elemental no merece la pena RPC.
36
Slo tenemos un mensaje y una respuesta por lo que no merece la pena crear una
conexin y las llamadas son sncronas.
La solucin ms apropiada es comunicacin P2P no orientada a conexin.
Ejercicio 1.15: Se desea construir un servidor de objetos distribuidos para implementar

un diccionario on-line con hipertexto. Cada palabra definida por el diccionario es un objeto.
Los objetos estn almacenados en archivos. Cada archivo tiene una tabla con los nombres de
los objetos que contiene y un puntero al lugar donde est almacenado. Cada objeto contiene
informacin sobre su tamao, los atributos que posee y los tipos de datos correspondientes,
que pueden ser:
a. Vectores de enteros
b. Vectores de strings.
El servidor asigna a cada cliente un hilo y se comunica con l mediante una tubera (pipe)
a) Qu operaciones posibles realizar el servidor, y qu informacin debe enviarle el cliente
para solicitarlas?
b) Qu informacin debe devolver el servidor?
c) Definir una estructura de mensajes adecuada, para que un objeto pase a travs de la
tubera.

A PARTADO A )
Puesto que se trata de un diccionario on-line, el servidor deber hacer las funciones de
bsqueda de objetos a partir de su nombre.
A PARTADO B )
Para cada palabra que se busque se debern devolver los datos de dicha palabra.
A PARTADO C )
Se pueden escribir los atributos del objeto separados por el smbolo ;. Para los vectores
separamos cada elemento del siguiente mediante una coma, , y un vector del otro con
;
Ejercicio 1.16: (Coulouris 10.7) Un servidor B de NTP recibe un mensaje del servidor
A a las 16:34:23.480 llevando una marca de tiempo 16:34:13:430 y lo responde. A recibe
el mensaje a las 16:34:15.725, llevando una marca de tiempo 16:34:25.7 de B. Estimar la
deriva entre B y A y la precisin de la estimacin.
37

El esquema que tenemos para el ejercicio es el que hemos visto en teora:
Con la misma nomenclatura de la imagen tenemos:
Ti3 = 430
(I.4)
Ti2 = 10050
(I.5)
Ti1 = 12270
(I.6)
Ti = 2995
(I.7)
donde los tiempos los hemos tomado midiendo desde las 16:34:13, para hacer los
nmeros ms pequeos y manejables (trabajando en milisegundos). Hay una pequea
errata: Ti2 = 10480 porque medimos desde 16:34:13 y para que fuera 10050 tendramos
que estar midiendo desde 16:34:13:430
Nuestro objetivo es calcular o, que es la diferencia de tiempos entre ambos relojes.
Observando el esquema, podemos deducir las ecuaciones:
Ti3 + o + t = Ti2
(I.8)
(I.9)
Ti + o = Ti1 + t
Tampoco conocemos t n t0 , pues no sabemos el tiempo que ha tardado el mensaje en ser

transmitido. Si sumamos las dos ecuaciones y despejamos o de la nueva ecuacin nos
queda:
Ti2 + Ti1 Ti Ti3 t0 t
o=
+
2
2
|
{z
}
oi
As, tenemos o escrito como la suma de un valor conocido ms una desviacin. Puesto
que todos los tiempos son positivos, tenemos que t + t0 > t0 t por lo que podemos
acotar o mediante:
d
d
z }|i {
z }|i {
0
0
t +t
t +t
oi
o oi +
2
2
As, podemos decir que la deriva es: oi = 9447.5ms con una precisin de 172.5ms9
9
Para obtener t+t restamos las dos ecuaciones del sistema
38
Ejercicio 1.17: Los protocolos de comunicaciones pueden ser orientados a conexin o

no orientados a conexin. Describir los pros y los contras de cada uno de ellos para su
utilizacin como medio de transporte de un sistema distribuido, e identificar el tipo ms
adecuado para realizar accesos a un servidor iterativo o a un servidor concurrente.
Orientado a conexin: TCP

Ventajas:
Confiable: se garantiza recepcin del mensaje.
Garantiza entrega de mensajes en el orden correcto.
Incorpora control de flujo.
No hay lmite en el tamao de los mensajes.
Desventajas:
Mayor sobrecarga de procesamiento (mantener conexin).
Mayor informacin de protocolo en las cabeceras.
Limitado a la comunicacin 1 a 1.
No orientado a conexin: UDP
Ventajas:
Comunicacin 1 a N utilizando broadcast y multicast.
Menos sobrecarga (no hay que mantener conexin).
Menor informacin de protocolo en las cabeceras.
Desventajas:
No hay informacin sobre mensajes consecutivos.
Posible prdida de mensajes o duplicidad de los mismos.
Mensajes de tamao limitado.
No hay control de flujo.
Una vez hemos analizado estas ventajas e inconvenientes de ambos protocolos,
podemos decidir cul de ellos es ms ventajoso utilizar en cada uno de los casos
planteados:
Servidor Concurrente:
Generalmente utilizan protocolos orientados a conexin.
Cuando se recibe una nueva peticin de conexin se crea un nuevo proceso
o hilo que se encargar de gestionarla.
39
Ejemplos: servidores web (HTTP), servidores de acceso remoto (Telnet),

servidores FTP.
Excepciones: servidor TFTP (usa protocolo UDP)
Servidor Iterativo:
Generalmente utilizan protocolos NO orientados a conexin.
Servidores del tipo peticin / respuesta que no almacenan estado.
Ejemplos: servidores DNS o servidores DHCP.
Excepciones: servidor Daytime (utiliza protocolo TCP).
Ejercicio 1.18:
Los servidores de un sistema distribuido pueden ser de dos tipos: sin
estado (stateless), es decir, que no recuerdan la historia de peticiones anteriores realizadas
por el cliente; o con estado (statefull), en caso contrario. Identificar el tipo de protocolo de
transporte ms adecuado (orientado o no orientado a conexin) para realizar los accesos a
cada uno de estos tipos de servidores.
Para los servidores statefull, por su facilidad para identificar mensajes consecutivos
de un mismo cliente, son ms apropiados los protocolos orientados a conexin. Si se
usasen protocolos no orientados a conexin habra que incluir un campo adicional en
cada mensaje para asociarlos a un mismo cliente.
No obstante, existen algunas excepciones, como DHCP que utiliza UDP pero guarda
un estado asociado a cada cliente (qu direccin IP tiene asignada)
Los servidores stateless no guardan informacin alguna asociada a cada cliente.
Generalmente son del tipo peticin respuesta donde no se guarda informacin asociada
a cada cliente ni importa el orden de los mensajes enviados.
Un ejemplo son los servidores DNS, servidores web o NTP. Un cliente solicita una
pagina web, sin importar qu pginas web ha solicitado anteriormente. Ya que no hace
falta identificar mensajes consecutivos de un mismo cliente son ms apropiados los
protocolos no orientados a conexin como UDP pues tienen menos sobrecarga.
Como en todo dentro de la informtica existen expeciciones como son los servidores
web o los servidores web que utilizan TCP, probablemente debido a la limitacin en el
tamao del mensaje en UDP.
Ejercicio 1.19: Un servicio de autenticacin en una red de rea local funciona mediante un
mecanismo de comunicacin basado en Remote Procedure Calls, RPCs genricas. Dispone
de las siguientes funciones:
Autenticacin de usuario: Recibe como parmetros un identificador de usuario y su
contrasea, y devuelve un cdigo de retorno 0 si usuario y contrasea son correctos,
y -1 en caso contrario.
40
Cambio de contrasea: Recibe como parmetros un identificador de usuario, su

contrasea actual y la nueva contrasea que se desea registrar. Devuelve un cdigo
de retorno 0 si se ha realizado correctamente la actualizacin, y -1 en caso contrario.
Obtencin de lista de privilegios asociados a un usuario: Recibe como parmetro un
identificador de usuario. Si dicho usuario existe en el sistema, devuelve un cdigo de
retorno 0 y dos listas de longitud variable: la primera con todos los atributos definidos
en el sistema para el usuario, separados por espacios; y la segunda con los nombres de
todos los servidores de la red a los que tiene acceso, tambin separados por espacios. Si
el usuario no existe, devuelve un cdigo de retorno -1.
Los identificadores de usuario, contraseas, atributos de usuario y nombres de servidores
son cadenas de caracteres ASCII que tienen un tamao mximo de 16 caracteres.
Suponiendo que la red es homognea (el mismo tipo de sistema para clientes y
servidor), proponer una estructura de mensaje de peticin y una estructura de
mensaje de respuesta para la comunicacin entre client stub y server stub adecuado a
las tres RPCs. (Describir la estructura en pseudocdigo o en lenguaje C, de modo que
quede suficientemente clara).
Introducir los cambios necesarios en el mensaje de peticin de la RPC de autenticacin
de usuario para soportar una red no homognea (clientes y servidor de distintos tipos).
Comentar los problemas de seguridad que presenta el diseo elegido para esta
aplicacin, y proponer alternativas para resolverlo.
Olakase
Ejercicio 1.20:
Los ordenadores de una empresa estn conectados siguiendo el
modelo cliente servidor, de acuerdo con la siguiente organizacin jerrquica de dominios
administrativos:
Las hojas del rbol representan ordenadores, los restantes nodos dominios. Cada dominio
tiene un servidor de nombres que reside en un ordenador, cuyo nombre coincide con el del
dominio, con capacidad de almacenamiento local de resultados de consultas a otros dominios
(cache). Se supone que al principio las caches estn todas vacas.
41
a) Escribir los nombres completos en el dominio global de todos los ordenadores situados en
las hojas del rbol.
b) Detallar los mensajes necesarios para que el ordenador jupiter localice el servidor
seguridad en el directorio a partir de su nombre en la red.
c) Inmediatamente despus de la consulta anterior, el ordenador saturno desea localizar el
servidor seguridad. Indicar el flujo de mensajes correspondiente.
d) Suponemos que el sistema de nombres utiliza el estndar X500. Decir qu ordenadores
contienen un Directory User Agent y cules contienen un Directory System Agent.
e) Escribir tres parejas de ordenadores entre los que se utilice el Directory Access Protocol.
f) Escribir tres parejas de ordenadores entre los que se utilice el Directory System Protocol.
g) Para cada uno de los cuatro servidores (ficheros, impresora, correo y seguridad) elegir
razonadamente el mecanismo de transporte aconsejable para conectar a ellos los ordenadores
clientes: peer to peer orientado a conexin, peer to peer no orientado a conexin, RPC o
MOM.
A PARTADO A )
ficheros.servicio1.empresa
impresora.servicio1.empresa
correo.servicio2.empresa
seguridad.servicio2.empresa
jupiter.gestion.empresa
saturno.gestion.empresa
A PARTADO B )
42
A PARTADO C )
A PARTADO D )
Directory User Agent
ficheros, impresora, correo, seguridad, jupiter, saturno
Directory System Agent
empresa, servicio1, servicio2, gestion
A PARTADO E )
fichero servicio1
correo servicio2
seguridad gestion
A PARTADO F )
43
servicio1 empresa
servicio2 empresa
gestion empresa
A PARTADO G )
TO BE CONTINUED...
Me da mucha pereza y no estoy seguro de lo que quieren pero creo que habra que
pensar que para la impresora nos interesa cola de mensajes, para el correo igual, para
la parte de seguridad posiblemente necesitemos RTP, para la de ficheros TCP si es
slo escritura directa, o incluso UDP y para la parte de gestin pues no sabemos nada
porque no tenemos detalles.
44
Captulo II
Colas
II.1.
Teora
Para estudiar el rendimiento de sistemas, usamos teora de colas. Tendremos inters en

varios parmetros, a saber:
Tasa de llegadas
Tasa de llegadas Denotada por , es el nmero de llegadas por unidad de tiempo.
Tasa de servicio
Tasa de servicio Denotada por , es el nmero de clientes servidos por unidad de

tiempo.
Intensidad
de trfico
Intensidad de trfico Se denota por u, y muestra la relacin entre la tasa de

llegadas y la de servicio:
Ts
u= =
Ta
Factor
de
utilizacin
Factor de utilizacin , es la probabilidad de que el sistema est activo en un

tiempo dado.
Nmero medio de clientes en el sistema

Nmero medio de clientes en cola
Nmero medio de clientes en el sistema Denotado por L, no merece mucha ms

explicacin.
Nmero medio de clientes en cola En un alarde de originalidad, se denota por
Lq .
Anlogamente, se define el tiempo medio de estancia y el tiempo medio de espera
en cola como W y Wq .
A partir de aqu, podemos encontrar relaciones. Por ejemplo, es fcil ver que el tiempo
total de estancia en el sistema ser el tiempo de espera en cola ms el tiempo que se
tarda en servir al usuario, de tal forma que
W = Wq + Ts
(II.1)
Por otra parte, el Teorema de Little nos da una relacin entre esos tiempos de espera y
el nmero de clientes.
45 de 112
Teorema II.1 (Teorema de Little). Sea W el tiempo medio de estancia en el sistema, L el

nmero medio de clientes en el sistema y la tasa de llegadas. Se tiene entonces que
L = W
(II.2)
Lq = Wq
(II.3)
y, anlogamente para la cola, que
Demostracin. Hay varias pruebas disponibles en Internet, como esta.

Es fcil ver que, juntando esas tres ecuaciones anteriores (II.1), (II.2) y (II.3) se tiene que
L = Lq + Ts = Lq +
(II.4)
Para modelar las colas, se utiliza la notacin A/B/c/K/N/Z, donde A y B son las
distribuciones del tiempo de llegadas y servicio respectivamente, c el nmero de
servidores del sistema, K la capacidad mxima, N el nmero total de clientes y Z la
forma de servicio. Normalmente, K = N = y Z = F IF O, as que se omiten. Segn
estos parmetros existen frmulas para sacar todos los parmetros, que podis ver en
el formulario de la asignatura.
II.1.1.
Distribuciones no Poissonianas
La mayora de las frmulas de la asignatura se basan en distribuciones exponenciales

para hacer los clculos. Una forma de identificarlas es mediante el siguiente coeficiente:
Coeficiente
cuadrtico
de variacin
Definicin II.1 Coeficiente cuadrtico de variacin. Dada una variable aleatoria X, se define
su coeficiente cuadrtico de variacin como
C2 =
V (X)
E (X)2
Segn el valor de ese coeficiente se puede tratar de sacar el tipo de distribucin, tal y
como se ve en la tabla II.1.
C2
(0, 0.7)
(0.7, 1.3)
(1.3, )
Distr.
Erlang-m
Poisson
Hiperexponencial
Tabla II.1: Distribuciones segn coeficiente de variacin

Una vez identificada la distribucin, se puede usar el modelo M/G/1 para la
distribucin con

(II.5)
E S 2 = V (S) + E (S)2
46
II.1.2.
Redes de colas
Cuando montamos varias colas, tenemos algunas definiciones que nos ayudan al
modelado.
Red de colas
abiertas
Definicin II.2 Red de colas abiertas. Se dice que un conjunto de K colas es una red de colas
abiertas si los clientes llegan en procesos de Poisson independientes, con tiempos de servicio
distribuidos exponencialmente y si, tras el proceso enPcada sistema j, el cliente pasa a la cola i
con probabilidad pij o bien sale con probabilidad 1 K
i=1 pji .
Se tiene que la tasa de llegadas a cada servidor es
j = j +
K
X
(II.6)
i pij
i=1
A partir de aqu hay varios teoremas que nos ayudan
Teorema II.2 (Teorema de Burke). La salida en estado estacionario de un sistema M/M/c

con parmetro de entrada es tambin un proceso de Poisson de parmetro .
Teorema II.3 (Teorema de Jackson). Dada una red de colas abierta, la probabilidad de un
estado dado (entiendo como estado un vector (n1 , . . . , nK ) donde ni es el nmero de clientes
en el sistema i) est dada por el producto de las probabilidades de cada uno de los sistemas.
Esto es,
K

Y
P (N1 , . . . , Nk ) = (n1 , . . . , nK ) =
P {Ni = ni }
(II.7)
i=1
II.2.
Problemas
Ejercicio 2.1: Los mensajes llegan a un servidor de descifrado de manera poissoniana

con un ritmo medio de llegada de 360 mensajes por minuto. Los tiempos de descifrado son
proporcionales a la longitud de los mensajes, los cuales se distribuyen aproximadamente
de forma exponencial, con una longitud media de 1500 bytes. La velocidad del servidor de
descifrado es de 10Kbyte/s. Cul es el tiempo medio de espera de respuesta por mensaje?
Cul es el nmero medio de mensajes en el sistema de descifrado?
47
El nmero de mensajes por unidad de tiempo es la tasa de llegadas, que deberemos

escribir en unidades del Sistema Internacional:
= 360min1 = 6s1
Por otro lado tenemos que si la longitud del mensaje es una variable aleatoria que
sigue una distribucin exponencial y el tiempo de procesamiento es proporcional a la
longitud, el tiempo de servicio ser una variable aleatoria exponencial de media:
Ts =
1500bytes
= 0.15s
10000bytes/s
A partir de aqu podemos calcular la tasa de servicio:

=
1
= 6.66s1
Ts
Se trata de un sistema M/M/1 de modo que podemos calcular el nmero medio de

mensajes en el sistema a partir, nicamente, del factor de utilizacin segn la frmula:
L=
/
/
=
=
=
= 9.09
1
1 /
( )/
Ejercicio 2.2: Se tiene un servidor en Internet que recibe un trfico de Poisson a un ritmo
medio P peticiones/s. El tiempo que tarda en atender una peticin se encuentra distribuido
exponencialmente, siendo capaz de procesar S peticiones/s.
Debido al xito del servidor, a los quince das de su aparicin en Internet su trfico se ha
multiplicado por un factor K. Para resolver el problema, se cambia de ordenador, solicitando
uno de potencia K veces superior al actual.
Calcular el nuevo nmero medio de clientes en el sistema servidor, y el nuevo tiempo de
permanencia en el sistema tras la ampliacin del servidor en funcin de los valores anteriores
al cambio.

Tras el xito del servidor pasamos a tener una tasa de llegadas:
=K P
Al cambiar la potencia del ordenador multiplicndola por K estamos reduciendo el
tiempo de servicio segn ese mismo factor y multiplicando la tasa de servicio por K:
=SK
Se trata de un sistema M/M/1 donde el nmero de clientes en el sistema slo depende
del factor de utilizacin del mismo que, en este caso, no ha cambiado.
48
Por tanto seguimos teniendo el mismo nmero medio de clientes en el sistema que
antes de producirse los cambios.
Para calcular el nuevo tiempo de permanencia nos apoyamos en el Teorema de Little
que nos permite escribir
L
W =
puesto que L no ha cambiado y se ha hecho K veces mayor, el tiempo medio de

permanencia en el sistema se ha reducido en un factor de K.
Ejercicio 2.3:
Se desea disear un servidor para satisfacer un trfico de Poisson con
un tiempo medio entre peticiones de 10 s. El servicio a proporcionar tiene una duracin
distribuida exponencialmente con media de 16 s. Calcular:
a) El nmero mnimo de servidores para satisfacer el trfico requerido.
b) Con dicho nmero de servidores, el tiempo medio de espera en cola por peticin.
c) El tiempo medio de espera en cola, en caso de independizar cada servidor, asignndole una
cola de espera a cada uno de ellos, y repartiendo el trfico entre ellos de modo aleatorio para
que cada uno reciba la mitad del total.

A PARTADO A )
Si nos llega una peticin cada 10 segundos, tenemos una tasa de llegadas de
= 0.1s1
Dado que el tiempo medio de servicio es de 16s y tenemos c servidores, la tasa de
servicio es, en cada servidor:
= 0.0625
Si queremos que el sistema no colapse, necesitamos que el factor de utilizacin sea
menor que 1, es decir:
=
< 1 = < c = c > 1.6

c
necesitamos 2 servidores para satisfacer el trfico requerido

A PARTADO B )
Para este ejercicio nos apoyamos fuertemente en el formulario. Nos encontramos ante
un sistema M/M/2 y para calcular el tiempo de espera en cola debemos calcular el
nmero de clientes en el sistema con ayuda de las frmulas. Una vez obtenido este
valor aplicamos el Teorema de Little para calcular el tiempo medio de estancia en el
sistema y le restamos el tiempo medio de servicio.
49
Vamos a ello:
= 0.8
2
p0 =
c1
X
(/)n
n=0
n!
(/)c
c!(1 )
p2 = p0
cc
c!
n
Pq =
Finalmente
L=

2.56 1
= 1 + 1.6 +
= (9)1 = 0.11
0.4
= 0.11 2 0.64 = 0.14

pc
= 0.71
1
Pq
+ c = 4.44
1
Aplicando Little nos queda

W =
L
= 44.4
Puesto que el tiempo de servicio es de 8s, el tiempo medio de espera en cola asciende a
W Ts = 24.4s
A PARTADO C )
Este caso es equivalente al ejercicio anterior con K = 0.5 por lo que tenemos
Wn =
Wo
= 88.8s
K
, lo que implica
W Ts = 56.8s
Ejercicio 2.4: Se quiere disear un servidor de emisin de certificados en Internet para

que sea capaz de atender una media de 10 peticiones por segundo con un tiempo medio
de respuesta de 0.1s. Sabiendo que el programa de generacin del certificado es siempre el
mismo, independientemente del cliente, y requiere la ejecucin de 10.000 instrucciones de
cdigo mquina, calcular la potencia de ordenador (en MIPS) necesaria para su ejecucin,
suponiendo despreciable cualquier otra carga en el mismo.

Queremos ejecutar 10.000 instrucciones de cdigo en 0.1s deberemos tener una potencia
de 0.1M IP S
50
Dejuan opina que esa solucin sera para 1 peticin al segundo, pero como
queremos soportar una carga 10 veces mayor, entonces hara falta procesa 1MIPS (Mil
Instrucciones Por Segundo)
Ejercicio 2.5: Una fraccin p del trfico de salida procedente de un servidor con tiempo
de servicio distribuido exponencialmente con media Ts se realimenta a su entrada. El trfico
nuevo llega al servidor con un ritmo medio R. Calcular el factor de utilizacin del servidor
y el tiempo medio de estancia en el sistema.

Empezamos calculando la tasa de llegadas:
= R + p = =
La tasa de servicio es
=
R
1p
1
Ts
As el factor de utilizacin sera

=
R Ts
=
1p
Sabiendo que es un sistema M/M/1 podemos calcular el nmero medio de clientes en

el sistema como:
R Ts
L=
=
1
1 p R Ts
Aplicando ahora el Teorema de Little podemos calcular el tiempo medio de estancia en
el servidor como:
Ts
L
W = =
(1 p R Ts )(1 p)
Ejercicio 2.6:
En una determinada red de rea local se dispone de un servidor de
comunicaciones, que acta como encaminador de mensajes de aplicacin entre la dicha red y
una red remota, a la que se encuentra conectado a travs de una lnea dedicada de velocidad
2 106 bps.
A la red de rea local hay conectados un nmero muy grande de terminales clientes, que
envan mensajes cuyo tamao se encuentra distribuido exponencialmente con un valor
medio de 1 KByte.
Se puede considerar que los mensajes llegan al servidor siguiendo un ritmo de Poisson. Se
pide:
51
a) Si el servidor de comunicaciones recibe un promedio de 180 peticiones/s, calcular tiempo

medio que transcurre desde que un mensaje es recibido en el servidor hasta que llega al punto
destino.
b) Calcular el nmero mximo de peticiones por segundo que se estarn procesando si se sabe
que el tamao medio de memoria que ocupa la cola de mensajes en espera de ser procesados
es de 10 KBytes.

En este ejercicio el tiempo de procesamiento de mensaje por parte del servidor es el
tiempo que tarda dicho servidor en enviar el mensaje a travs del enlace descrito.
A PARTADO A )
Tenemos una tasa de peticiones
= 180s1
Sabiendo el tamao medio de los mensajes y la capacidad de transmisin de la lnea

dedicada, podemos calcular el tiempo de servicio
Ts = tamao/velocidad = 0.0041s
lo que nos da una tasa de servicio de
=
1
= 244.14s1
Ts
A partir de aqu podemos calcular el factor de utilizacin del sistema

=
= 0.74
y, puesto que estamos ante un sistema M/M/1 podemos calcular el nmero medio de
clientes en el sistema como
L=
= 2.85
1
y a partir del Teorema de Little calculamos el tiempo medio de estancia en el sistema,
que es el dato pedido
L
W = = 0.016s
A PARTADO B )
Ahora nos encontraramos ante un sistema M/M/1/K siendo K el nmero mximo de
clientes en el sistema que se calcula como el nmero mximo de clientes en cola +1 (el
que se est procesando).
Puesto que conocemos el tamao de la cola y el tamao de los mensajes, podemos
calcular K = 10 mensajes. Es decir, tenemos un sistema M/M/1/10 y nos piden
calcular L, el nmero medio de clientes en el sistema.
52
Los valores de y calculados en el apartado anterior siguen siendo vlidos, pues no

han cambiado las condiciones de llegada y procesamiento de mensajes.
Procedemos pues a calcular L:
L=
/ 1 (K + 1)(/)K + K(/)K+1
/ 1 (3)(/)2 + 2(/)3
=
=
1 /
1 (/)K+1
1 /
1 (/)3
=
0.74 0.17
= 0.81
0.26 0.6
Dejuan opina que:

Seguimos estando en un M/M/1 porque no est limitado el tamao de la cola.
Simplemente se nos dice que el nmero medio de clientes en cola, si los mensajes son
de 1KB es
10Kb
Lq =
= 10
1Kb
no se mantiene del ejercicio anterior, porque si nos piden el nmero mximo de
peticiones por segundo, lo que tendremos que hallar es 1 . Lo que si se mantiene es
, porque el Ts es el mismo.
Utilizando que
Lq =
2
2
10 =
= = 229s1
( )
250(250 )
Ejercicio 2.7: Deseamos instalar un servidor de envo de mensajes ("busca") a una

serie de abonados. El nmero de abonados, que suponemos muy grande, enva mensajes
a nuestro servidor, desde donde se envan a su destino mediante un sistema de transmisin
por radio. Los mensajes llegan segn un proceso de Poisson con una tasa de llegadas L. El
tiempo de servicio (total del proceso y envo del mensaje) se puede considerar distribuido
exponencialmente con valor medio S. El esquema de bloques del servicio es el siguiente:
a) Calcular el tiempo medio que transcurre desde que un mensaje llega al sistema hasta que
es servido a su destino.
1
La verdad es que no estoy del todo convencido tampoco de que haya que hayar ..., pero si que
entiendo que es el mismo
53
b) La tarifa del servicio es de P Euros por mensaje transmitido, pero se proporciona un

descuento de D Euros por cada segundo que el mensaje tarde en llegar a su destino. Calcular
los ingresos medios esperados por mensaje transmitido.
c) Calcular a partir de qu tasa de peticiones el tiempo de espera ser tal que el mensaje se
deba transmitir gratuitamente (se supone que nunca se aplica un descuento mayor que el
coste de transmisin del mensaje).

A PARTADO A )
Tenemos las tasas de llegadas y servicio
=L =
1
S
A partir de estos datos calculamos el factor de utilizacin

=
=LS
Puesto que nos encontramos ante un sistema M/M/1 podemos calcular el nmero de
clientes en el sistema a partir del factor de utilizacin:
Lc =
L
=
1
SL
Por ltimo calculamos el tiempo medio de estancia en el sistema a partir del teorema
de Little:
Lc
LS
W =
=
S Lc
A PARTADO B )
Los ingresos medios sern el precio por mensaje por el nmero medio de mensajes que
se manipulan menos el dinero que se devuelve por segundo de retraso multiplicado
por el retraso habitual de procesamiento de los mensajes.
Nos queda la frmula
Ingresos = P Lc D W
A PARTADO C )
Basta con igualar los ingresos a 0:
P Lc = D W P Lc =
LS
S Lc
Ahora simplemente despejamos Lc y a partir de ah despejamos que usaremos para

calcular .
54
Ejercicio 2.8: Una red de una entidad financiera consta de una serie de terminales
remotos, en nmero que podemos considerar muy grande, conectados mediante lneas
telefnicas alquiladas full duplex a un multiplexor de terminales. Dicho multiplexor entrega
los mensajes recibidos a un servidor, que ejecuta los programas transaccionales necesarios
para atender al mensaje recibido, y devuelve los resultados al cliente a travs del mismo
multiplexor. El esquema de bloques del servicio es el siguiente:
Los mensajes de las oficinas llegan al multiplexor segn un proceso de Poisson con una tasa
de llegadas total de 3s1 (es decir, incluyendo las peticiones de todos los servidores) y su
longitud media es de 1 Kbyte. El tiempo de servicio del multiplexor por mensaje (total del
proceso y envo del mensaje) se puede considerar distribuido exponencialmente con valor
medio 250 ms.
a) Calcular la ocupacin media en memoria de la cola de mensajes en espera de servicio del
multiplexor
b) Calcular la tasa de llegadas al servidor.
c) Los mensajes que llegan al servidor son de tres tipos bsicos. El tiempo de proceso en el
servidor depende del tipo de mensaje recibido, de acuerdo a la siguiente tabla:
Tipo mensaje
Probabilidad
Tiempo de proceso
0.5
0.1
0.3
0.2
0.2
0.4
Estos tiempos incluyen lo que tarda el mensaje de respuesta en llegar al terminal remoto.
Esta transmisin del mensaje de respuesta se supone que no afecta al tiempo de proceso del
multiplexor ni a la comunicacin por la lnea que lo une con el terminal.
Calcular el tiempo medio de estancia en el servidor de las solicitudes.
55

A PARTADO A )
Tenemos una tasa de llegadas = 3 y un tiempo de servicio por parte del multiplexor
de 250ms lo que nos da una tasa de servicio = 4.
Analizando por separado el multiplexor, tenemos un sistema M/M/1 de modo que
calculamos y lo usamos para calcular el nmero medio de clientes L.
= 0.75
L=
=3
1
=
A PARTADO B )
La tasa de llegadas al servidor es exactamente la misma que la tasa de llegadas al
multiplexor. Cada mensaje que llega a este ltimo es enviado al servidor
A PARTADO C )
El tiempo de servicio en el servidor se puede calcular como una suma ponderada de
los tiempos de servicio de cada tipo de mensaje.
Ts = 0.5 0.1 + 0.3 0.2 + 0.2 0.4 = 0.19 = =
1
= 5.26
Ts
Volvemos a tener un sistema M/M/1. Calculamos , a partir de ah L y por ltimo

empleamos el Teorema de Little para calcular el tiempo medio de estancia en el sistema.
= 0.57 = L =
= 1.33 = W = = 0.44s
Ejercicio 2.9: El servidor de fecha y hora de una red resuelve cada peticin en un tiempo
que se puede suponer distribuido exponencialmente con media 100 ms. La red se compone
de un nmero muy grande de clientes que realizan peticiones, cuya llegada al servidor se
considera que sigue un proceso de Poisson.
a. Calcular el nmero mximo de peticiones por segundo que se podrn satisfacer para
obtener un tiempo medio de respuesta del servidor menor o igual que 1 s.
b. Calcular el tiempo medio de servicio necesario para poder satisfacer el doble de
peticiones reduciendo el tiempo de respuesta a la mitad.

56
a. Nos piden calcular el nmero mximo de peticiones por segundo que se pueden
satisfacer, es decir, tenemos que calcular .
Sabemos que el tiempo medio de servicio es de 100 ms, por lo que tendremos que
=
1
1
1
=
=
= 10s1
Ts
100ms
0.1s
El tiempo de servicio es el tiempo medio de estancia en el sistema y queremos que

sea menor que 1, por lo que:
W =
1
=
=
< 1 = > + 1
(1 )
por lo que el sistema no podr atender ms de 9 peticiones por segundo.

b. Ahora queremos que =18 reduciendo el tiempo de respuesta a la mitad.
Sustituyendo en la ecuacin anterior tenemos:
W <
Ejercicio 2.10:
1
1
= > + 2 = > 20 = Ts <
= 50ms
2
20
Un servidor web de aplicaciones se compone de los siguientes elementos
La llegada de solicitudes al sistema se puede considerar como un proceso de Poisson, con

una tasa de llegadas de 6 peticiones por segundo. Existe un nmero muy grande de clientes,
de modo que el nmero de peticiones pendientes de servicio no afecta al ritmo de llegada de
nuevas peticiones.
El servidor Web atiende las peticiones de pginas estticas e imgenes, empleando para ello
un tiempo que se puede considerar distribuido exponencialmente con un valor medio de 50
ms. Se considera que el servidor procesa las peticiones de modo iterativo, es decir, de una en
una.
Un 10 % de las peticiones procesadas por el servidor web requieren que, adicionalmente
al proceso realizado por dicho servidor, se ejecute un programa externo. Esta ejecucin se
realiza en un servidor de aplicaciones, cuyo tiempo de servicio tambin se puede considerar
distribuido exponencialmente con un valor medio de 1 s. Tambin en este caso se considera
que el servidor procesa las peticiones de modo iterativo.
a. Calcular el tiempo medio de estancia en el sistema de las peticiones que atiende
nicamente el servidor Web, justificando el modelo de clculo elegido.
57
b. Calcular el tiempo medio de estancia en el sistema de las peticiones que necesitan ser
atendidas por ambos servidores, justificando el modelo de clculo elegido.
c. Calcular el tiempo medio de estancia en el sistema total.
d. Realizando medidas sobre el sistema en produccin se descubre que el tiempo de
servicio del servidor web no sigue una distribucin exponencial, sino una distribucin
cuyo coeficiente cuadrtico de variacin es igual a 5. Justificar la validez o invalidez
del modelo empleado en los apartados anteriores, indicando las alternativas si no se
considera vlido.

a. Para esta parte podemos suponer que el sistema se acaba al salir del servidor de
modo que nos encontramos ante un sistema M/M/1 bastante sencillo. Vamos
a calcular el tiempo medio de estancia en ese sitema reducido como hacemos
siempre.
= 0.9 6 = 5.42 , Ts = 50ms = =
L=
= 20 = = = 0.27
Ts
= 0.37 = W = = 0.07s
1
b. Puesto que no tenemos retroalimentacin, la tasa de llegadas a este segundo

sistema sera del 10 % de la tasa de llegadas al Servidor Web. Calculamos este
nuevo y repetimos los clculos del apartado anterior.
= 0.1 6 = 0.6, Ts = 1s = =
L=
= 1 = = = 0.6
Ts
L
= 1.5 = W = = 15s
1
c.
W = Ws1 + p Ws2 = 1.57s
d. El modelo empleado no ser vlido ya que para serlo el coeficiente cuadrtido de
variacin debera ser muy prximo a 1, cosa que no se cumple.
A fin de ajustar las estimaciones deberamos repetir los clculos considerando una
distribucin de tipo hiperexponencial
Al considerar slo las peticiones que slo requeran procesamiento por parte del servidor web, la tasa
de llegadas se reduce
58
Ejercicio 2.11: Un middleware orientado a colas de mensajes (MOM) recibe mensajes en

una cola local de todos los ordenadores que componen la red de modo aleatorio. La llegada
de mensajes al MOM se puede considerar como un proceso de Poisson, con una tasa de
llegadas de 10 peticiones por segundo. Existe un nmero muy grande de clientes, de modo
que el nmero de peticiones pendientes de servicio no afecta al ritmo de llegada de nuevas
peticiones. La longitud de los mensajes que se recibe es de 25Kbytes. El tamao disponible
para almacenar mensajes en la cola se supone ilimitado. Los mensajes recibidos en esta cola
son procesados por dos servidores. El tiempo de servicio en cualquiera de ellos se puede
considerar distribuido exponencialmente con un valor medio de 50 ms. Tan pronto como
uno de los servidores est libre, tomar el primer mensaje de la cola y lo procesar sin
interrupciones.
a. Calcular el tamao medio, en Kbytes, que tendr la cola de mensajes en el MOM.
b. Calcular el tiempo medio de estancia en el sistema de las peticiones de los clientes.
c. Calcular cul es la probabilidad de que el tamao de la cola de mensajes sea mayor de
100 Kbytes.

Los datos que podemos extraer del enunciado son:
= 10
Longitud de mensaje 25Kb
Colas infinitas
2 servidores con tiempo de servicio exponencial
Ts = 50ms
Antes de hacer ningn clculo, reconocemos que se trata de un modelo M/M/2
a. Para calcular el tamao medio de la cola de mensajes basta con calcular el nmero
medio de mensajes en la cola y multiplicarlo por el tamao de cada mensaje.
Por el teorema de Little tenemos
Lq = Wq
Pero sabemos que el tiempo de estancia en el sistema es la suma del tiempo de
servicio ms el tiempo de espera en cola, de modo que
Lq = Wq = (W Ts )
y aplicando nuevamente el teorema de Little para calcula W tenemos:

L 1
= L c
Lq =

59
Empezamos calculando el factor de utilizacin del sistema:

=
Ts
=
= 10 25ms = 0.25
2
2
Calculemos ahora el nmero medio de unidades en el sistema:

L=
Pq
+ c
1
pero antes necesitamos conocer Pq :

Pq =
pc
1
y para ello necesitamos pc siendo c = 2.

Para calcular p2 tenemos que emplear la frmula:

cc n
p2 = p0
c! c
para lo que necesitamos conocer p0 .
p0 =
0.52 3
1 + 0.5 +
2 0.75
!1
=
1
= 0.6
1.64
Una vez tenemos esto podemos calcular p2 .

4
cc n
= 0.6 (0.25)2 = 0.075
p2 = p0
c! c
2
Con este valor procedemos a calcular Pq :
Pq =
pc
0.075
=
= 0.1
1
0.75
Y ya estamos en condiciones de calcular L:

L=
Pq
0.1 0.25
+ c =
+ 2 0.25 = 0.53
1
0.75
Ahora calculamos Lq
Lq = L c = 0.53 2 0.25 = 0.03
Y por ltimo multiplicamos por el tamao de cada mensaje:
Tamao medio = 0.03 25Kb = 0.75KB
b. El tiempo medio de estancia en el sistema puede calcularse, a partir del Teorema
de Little, como:
L
0.53
W = =
= 0.053
10
60
c. La probabilidad de que el tamao de la cola de mensajes sea mayor de 100 Kb

equivale a la probabilidad de tener ms de 4 mensajes en la cola que, a su vez,
equivale a la probabilidad de que haya ms de 6 clientes en el sistema.
Vamos a calcular esta probabilidad:
P {N (t) 7} =
X
n=6
X
cc
cc
1
0.6 2 6.10 105
cc
p0 n = p0 6
=
=
n6 = p0 7
c!
c!
c! 1
0.75
n=6
= 9.76 105
Ejercicio 2.12:
Para dar servicio de consultas a base de datos en una red se dispone
de dos ordenadores. El primero, que llamaremos A, tiene un tiempo medio de servicio de
100 ms., pero por construccin slo admite 5 peticiones en espera de servicio. El segundo,
que llamaremos B, tiene un tiempo medio de servicio de 500 ms., pero admite un nmero
ilimitado de peticiones en cola de espera. Los tiempos de servicio de ambos servidores se
pueden considerar distribuidos exponencialmente. La arquitectura que se decide para dar el
servicio coloca los dos servidores en paralelo. Las peticiones sern procesadas por el servidor
A, excepto en el caso de que ste se encuentre al mximo de su capacidad (5 peticiones en
cola mas una en servicio), en cuyo caso la peticin ser pasada al servidor B. La llegada
de consultas al sistema se puede considerar como un proceso de Poisson, con una tasa de
llegadas de 9 peticiones por segundo. Existe un nmero muy grande de clientes, de modo
que el nmero de peticiones pendientes de servicio no afecta al ritmo de llegada de nuevas
peticiones.
Calcular el tiempo medio de estancia en el sistema de las peticiones que son procesadas
por el servidor A.
Calcular el tiempo medio de estancia en el sistema total compuesto por los servidores
A y B.

El sevidor A un sistema M/M/1/K con K = 6, 5 clientes en cola + 1 siendo
procesado. Para calcular el tiempo medio de estancia en el sistema emplearemos
las frmulas del formulario para hallar L, el nmero medio de clientes en el
sistema. Una vez hayamos calculado este valor aplicaremos el teorema de Little
para conocer W. Vamos a ello.
A = 9, A =
LA =
1
= 10
TSA
/ 1 (K + 1)(/)K + K(/)K+1
=
1 /
1 (/)K+1
/ 1 (7)(/)6 + 6(/)7
=
= 2.5
1 /
1 (/)7
61
WA =
L
L
=
0
(1 pk )
Para calcular pk necesitamos conocer previamente p0 . Vamos a por ambos valores

1 /
= 0.19 = pk = p0
p0 =
1 (/)k+1
k
= 0.1
As nos queda:
WA =
2.5
= 0.3s
9(1 0.1)
Tenemos que estudiar ahora el subsistema compuesto por el servidor B. Para

conocer la tasa de llegadas al servidor B debemos conocer previamente la
probabilidad de que se llene el servidor A.
6
6
1 /
p6 = p0
=
= 0.1
7
1 (/)
Puesto que slo llegan peticiones al servidor B cuando se satura el A tenemos

B = p6 A = 0.91 B =
1
= 2 = = 0.46
TSb
Este segundo servidor se trata de un sistema M/M/1 de modo que calculamos

mediante la frmula L a partir de y con el teorema de Little obtenemos WB
LB =
LB
= 0.85 = WB =
= 0.94
1
B
Una vez conocido este valor, podemos calcular el tiempo medio de estancia en el
sistema como:
W = (1 p6 )WA + p6 WB = 0.346s
Ejercicio 2.13:
Un sistema de registro de incidencias se compone de una red de 5 terminales que realizan
la entrada de datos manual, y un servidor, que recibe solicitudes tipo RPC para validar los
datos introducidos en el cliente y almacenarlos en una base de datos. El tiempo que dicho
servidor emplea para realizar las operaciones mencionadas se puede considerar distribuido
exponencialmente con un valor esperado de 15 s. Cuando un cliente genera una peticin,
queda inactivo a la espera de recibir la respuesta del servidor. Una vez recibida dicha
respuesta, el tiempo que tarda en generar una nueva peticin es aleatorio y tambin se
encuentra distribuido exponencialmente, con un valor medio de 1 minuto. Proponer un
modelo de colas vlido para este problema, y calcular la ocupacin media del servidor y el
tiempo medio de estancia en el sistema de las peticiones que son procesadas.
Debemos emplear un modelo M/M/1//5. Como el cliente no dice nada acerca de la

mxima capacidad de clientes en el sistema, suponemos capacidad infinita.
62
Si el tiempo medio de servicio es de 15 segundos tenemos que

=
1
= 0.07s1
Ts
Puesto que cada cliente realiza de media una peticin por minuto, tenemos que
=
1
= 0.017s1
60s
Puesto que slo hay un servidor, el factor de utilizacin del mismo es
= 1 p0 = 1
X
n=0
M!
(M n)!
n 1

= 0.801
que es la ocupacin media del servidor que nos pedan calcular: 80,1 %
Para calcular el tiempo medio de estancia en el sistema empezamos calculando
L=M
0
= 1.796 clientes
Ahora aplicamos el Teorema de Little:

W =
L
L
=
= 33.63 segundos
0
Ejercicio 2.14: Basndose en los conceptos de teora de colas expuestos en las clases de
teora, hallar la distribucin de probabilidad del nmero de unidades en el sistema para un
modelo de colas en el cual:
La llegada de clientes al sistema sigue un proceso de Poisson con tasa de llegadas .
El tiempo de servicio est distribuido exponencialmente con media 1/.
Existen c servidores para atender las peticiones.
El nmero total de unidades en el sistema est limitado a un mximo de K, siendo
K>c.
El nmero de clientes se puede considerar infinito.
A partir de dicha distribucin, calcular el nmero medio de unidades en el sistema, el
factor de servicio, la tasa efectiva de llegadas al sistema, el tiempo medio de estancia
en el sistema, el tiempo medio de estancia en cola y el nmero medio de unidades en
cola de espera.
63
Ejercicio 2.15: Un servidor de transacciones recibe peticiones de acuerdo a un proceso de

Poisson con una tasa de llegadas . La estructura del servidor se muestra en la siguiente
figura:
Las transacciones emplean un tiempo de proceso distribuido exponencialmente con media

1/1 . Tras este tiempo, la ejecucin del programa se completa con una probabilidad 1q, o requiere acceder a un servidor de base de datos y continuar su proceso. Suponer
que la recuperacin de la informacin de la base de datos requiere un tiempo distribuido
exponencialmente con media 1/2 .
a. Justificar adecuadamente los modelos de colas que se deben emplear para modelizar el
sistema.
b. Calcular el tiempo medio de estancia en el sistema de las peticiones de los clientes.

a. Se trata de una red de colas donde cada cola sigue un modelo M/M/1
b. Primero tenemos que calcular las tasas de llegadas:
1 = + q = =
1q
2 = q1
Ahora podemos calcular el factor de utilizacin de cada uno de los subsistemas:
1 =
=
1
1 (1 q)
2 =
2
q
=
2
2 (1 q)
A partir de estos valores calculamos L1 y L2 y por ltimo calculamos el tiempo

medio de estancia en el sistema como:
P
Li
L1 + L2
W = P
=
i
Puesto que no tenemos datos numricos no terminamos de realizar las cuentas,

pues no aportarn informacin nueva.
64
Ejercicio 2.16: El tiempo que emplea un determinado servidor de control de accesos de

una red en procesar una solicitud de autenticacin de un usuario se puede considerar como
una variable aleatoria con distribucin exponencial de valor esperado 235 ms. Debido a
su construccin, tiene una cola de espera limitada, de modo que rechaza cualquier nueva
solicitud que reciba cuando ya se encuentra procesando una y hay otras dos en espera. Si
se supone que el nmero de clientes del servidor es muy grande, y que las peticiones que
realizan siguen un ritmo de Poisson con una tasa de 5 peticiones por segundo, calcular la
probabilidad de que se rechace una solicitud, la ocupacin media del servidor y el tiempo
medio de estancia en el sistema de las peticiones que son procesadas
Estamos ante un modelo M/M/1/K siendo K = 3. Tenemos la tasa de llegadas = 5

y la tasa de servicio = 1/Ts = 4.25.
La probabilidad de que se rechace una solicitud es la probabilidad de que haya tres o
ms clientes en el sistema:
2
P(rechazo) = 1 p0 p1 p2 = 1 p0 p0
=
1 /
1 /
1 /
=1
4
4
1 (/)
1 (/) 1 (/)4
2
= 0.313
La ocupacin media del servidor es la tasa de utilizacin y se calcula con la frmula:

k
=
k+1 = 0.807
1
Es decir, el servidor estar activo el 80.7 % del tiempo.
Para el tiempo medio de estancia en el servidor aplicamos el teorema de Little con lo
que obtenemos
W =
1 / 1 4(/)3 + 3(/)4
L
= 0.496 segundos
=
1 /
1 (/)4
Ejercicio 2.17: En una instalacin se tiene un problema con el tiempo de respuesta de

un servidor de RPCs. El ordenador en el que reside dicho servicio tiene 2 CPUs dedicadas
exclusivamente a procesar las peticiones, de modo que cualquiera de ellas puede atender
cualquier peticin en cualquier estado, y un sistema de disco nico. El trfico de llegada al
servidor se puede suponer de Poisson, con un valor medio de R peticiones por segundo.
El proceso que se efecta en el servidor necesita realizar un nmero variable de accesos
a disco. Se ha estimado que cada peticin emplea un tiempo de proceso en alguna de las
CPUs que se encuentra distribuido exponencialmente con un valor medio T1. Transcurrido
este periodo, la peticin necesita acceder a disco con una probabilidad p, o finaliza en caso
contrario.
65
El acceso al nico disco del sistema emplea un tiempo distribuido exponencialmente, con un
valor medio de T2. Una vez realizado el acceso a disco, la peticin volver siempre a la cola
de entrada en espera nuevamente de que alguna de las CPUs est libre para continuar el
proceso.
El tamao de las colas de espera en cualquier parte del sistema se puede considerar infinito.
Datos numricos: R = 2s1 ; p = 0.8; T1 = 20 ms.; T2 = 100 ms.
a. Dibujar el diagrama de bloques del sistema, indicando en l los puntos de
encolamiento, tasas de peticiones recibidas en cada punto y tiempos de servicio de
cada uno de los elementos que lo componen.
b. Calcular el nmero medio de unidades en cola en el sistema total.
c. Calcular el tiempo medio de estancia en el sistema de una peticin.
d. A partir de los resultados obtenidos, identificar los cuellos de botella del sistema,
y realizar sugerencias sobre las modificaciones que sera necesario introducir en el
mismo para reducir el tiempo medio de estancia en l.

Est mal, tengo que corregirlo. Debera considerarse M/M/2 y no M/M/1 con doble
potencia
a. Se trata de una red de colas M/M/1
b. El nmero medio de unidades en cola ser la suma del nmero medio de
unidades en cada una de las colas.
Las tasas de llegadas de cada cola son:
1 = R + p 1 = 1 p 1 = R = 1 =
2 = p R + p 2 = 2 p 2 = p R = 2 =
R
= 10s1
1p
pR
= p 10s1 = 8s1
1p
Conocemos ya los tiempos de servicio de cada subsistema de modo que

podemos calcular las tasas de servicio:
1 =
1
= 100s1
T1 /2
2 =
1
= 10s1
T2
Conocidos estos valores podemos calcular el factor de utilizacin de cada

subsistema y con l el nmero medio de clientes en cada subsistema:
1 =
1
1
= 0.1 = L1 =
= 0.11
1
1 1
66
2 =
2
2
= 0.8 = L2 =
=4
2
1 2
Aplicando el teorema de Little podemos calcular el tiempo de estancia en cada

subsistema:
L1
W1 =
= 0.011s
1
L2
W2 =
= 0.5s
2
Sabiendo que el tiempo medio de estancia en el subsistema es la suma del
tiempo medio de espera en cola ms el tiempo medio de servicio, podemos
calcular el tiempo medio de espera en cola de cada subsistema es que:
T C1 = W1 T 1/2 = 1ms = 0.001s
T C2 = W2 T 2 = 400ms = 0.4s
Aplicando nuevamente el teorema de little podemos calcular el nmero medio de
clientes en cada cola:
Lq1 = 1 T C1 = 0.01
Lq2 = 2 T C2 = 3.2
El nmero medio de clientes en cola en el sistema total ser la suma del nmero
medio de clientes en cada una de las colas, es decir, tenemos que
Lq = Lq1 + Lq2 = 3.21clientes
c. El tiempo medio de estancia en el sistema de una peticin se calcula de la
siguiente forma:
P
Li
W = P
= 2.06s
i
Tambin podramos calcularlo como:
W = W1 + pW2 + pW = W =
W1 + pW2
= 2.06s
1p
Estamos teniendo en cuenta el hecho de que no todas las peticiones pasan por
ambos subsistemas al multiplicar por p.
Por otro lado estamos considerando la recursividad a la hora de calcular la tasa
de llegadas a cada uno de los subsistemas, dato en que nos hemos basado para
calcular los tiempos medios de estancia.
d. A partir de estos datos podemos observar que el cuello de botella en el sistema es
el acceso al disco que, por ser disco nico y tener tiempo de acceso 5 veces mayor
que el tiempo de procesamiento en cada una de las 2 CPUs, lleva 10 veces ms
tiempo que el procesamiendo de la peticin.
Habra que disminuir este tiempo mediante una sustitucin del disco por uno
ms rpido, permitiendo mltiples accesos simultenos al disco o aumentando el
nmero de discos.
67
Ejercicio 2.18: Se ha detectado que el cuello de botella en una aplicacin se produce al leer
del disco. Para solucionarlo, se plantean dos alternativas:
Comprar un disco con tiempo de acceso menor, pero ms caro. En este caso, se encolan
las peticiones cuando el disco se encuentre ocupado.
Poner dos discos en espejo (mirroring) que tendrn un tiempo de acceso mayor que el
anterior, pero ms baratos. En este caso, se accede indistintamente a cualquiera de los
dos discos cuando se produce una peticin, dependiendo de cul est libre, encolndose
todas las peticiones en una cola comn.
(Datos numricos: tiempo medio de acceso disco rpido: 10 ms; tiempo medio de acceso de
cada disco lento: 15 ms. En ambos casos se supone distribucin exponencial).
Suponiendo que la aplicacin es la nica que realiza los accesos a disco, que las peticiones de
lectura se producen segn un proceso de Poisson, y que las colas se pueden suponer infinitas:
a. Calcular para ambos casos el nmero medio de peticiones por segundo que se podrn
satisfacer para obtener un tiempo medio de lectura igual a 100 ms.
b. Calcule la tasa de peticiones para la que ambos casos dan el mismo rendimiento, y el
tiempo medio de lectura para este caso.

a. Tenemos que calcular en ambos casos conociendo 1 = 100s1 y 2 = 66, 7s1
y sabiendo que queremos obtener un tiempo de servicio W = 0.1s
Con las frmulas tenemos que en cada caso el tiempo se calcula como:
Servidor ms potente: M/M/1
W =
1
L
=
= 0.1 = = 90s1
1 1
Dos servidores: M/M/2

Pq
L
2
W = =
+ =
2 2
1
1+/(1)++2 /(2(1))
(1 )(2 2 )
2
+
Despejamos 2 y somos los amos

b. Bsicamente tenemos que igualar las dos ecuaciones W escritas anteriormente y
encontrar el que las hace iguales. Evidentemente me estoy perdiendo algo, pues
me salen ecuaciones mucho ms complicadas de lo que deberan.
68
Ejercicio 2.19: Un servidor de validacin de firmas que se encuentra en una determinada

red procesa mensajes de modo iterativo. Los mensajes de solicitud que recibe tienen un
tamao medio de 100 bytes, y se puede suponer que su llegada al servidor sigue un proceso
de Poisson. El tiempo de proceso de cada mensaje es aleatorio, sabindose que su valor medio
es 10 ms. y que su distribucin de probabilidades se puede considerar exponencial.
La monitorizacin de la red nicamente nos permite conocer el tamao medio de la ocupacin
que tiene en memoria la cola donde se almacenan los mensajes pendientes de procesar, que
es de 325 bytes.
a) Calcular el tiempo medio total que transcurre desde que llega un mensaje de peticin al
servidor y este termina de procesarlo.
b) En los acuerdos de nivel de servicio de este servidor se establece que El tiempo que debe
transcurrir desde que llegue un mensaje de peticin al servidor y este termine de procesarlo
debe ser inferior a 80 ms en el 90 % de las peticiones. Explicar razonadamente si se cumple
o no este punto del acuerdo de nivel de servicio. En caso negativo, sugerir cualitativamente
soluciones que permitiran resolver el problema.

A PARTADO A )
Un mensaje de 100 bytes tarda una media de 10 ms en procesarse, lo que indica que se
procesa a una velocdiad de 10 bytes/ms.
Puesto que en media la cola ocupa 325 bytes, la media de tiempo que tardar un
mensaje en ser procesado ser la suma de su tiempo de proceso ms el tiempo de espera
en cola, siendo este ltimo similar al tiempo de proceso de los 325 bytes de mensajes
que habr antes de l.
As, el tiempo medio pedido es:
W = 32.5ms + 10ms = 42.5ms
A PARTADO B )
Est claro que en media se cumplen los requisitos, pero para comprobar que se cumple
el porcentaje hay que calcular el percentil. De la frmula de la distribucin (que aparece
en el chuletario), queremos:
()t
0.9 = 1e
= 10.9 = e
()t
1
= t =
ln
1
0.1

= W ln(1p) = 97.86ms
Recordando lo que significa el percentil. De cada 100 peticiones, la 80 tarda 97ms.

Como 97 > 80 no se cumplira el contrato. Si aumentramos la potencia del servidor,
reduciendo W podramos cumplir el requisito.
80ms = W ln(0.1) W = 34.74ms
69
1
Utilizando W = +
podramos sacar y con ello la tasa de servicio necesaria.
(Entiendo que a este tipo de razonamiento se refiere con sugerir cualitativamente
soluciones)
Ejercicio 2.20: Se desea disear un Directory System Agent X.500, que denominaremos
DSA1, en el que se espera recibir, a travs del protocolo DAP, un trfico que se puede suponer
de Poisson con un valor medio de 50 peticiones / s.
a) Suponiendo que el tiempo de servicio del servidor de nombres se encuentra distribuido
exponencialmente, calcular la capacidad media que debe tener el servidor, en peticiones por
segundo, para que el 95 % de las peticiones que reciba tengan un tiempo total de estancia en
el sistema de menos de 10 ms.
b) Cuando al procesar una peticin recibida DSA1 no tiene los datos necesarios para
resolverla, redirige la peticin a otro Directory System Agent de nivel superior, que
denominaremos DSA2, mediante protocolo DSP. Esto ocurre, en promedio, en un 25 % de
las peticiones que procesa. Este nuevo servidor contesta directamente al cliente que realizaba
la peticin.
Se sabe que DSA2 recibe consultas de muchos ms servidores, componiendo el total de
ellas un trfico de Poisson con una media de 200 peticiones / s. Su tiempo de servicio, que
tambin se puede considerar distribuido exponencialmente, hace que sea capaz de procesar
un promedio de 300 peticiones / s.
Si se desea que el tiempo medio de respuesta de una peticin realizada a DSA1,
independientemente de quin la procese, sea igual o inferior a 6 ms, determinar cul sera
la capacidad media que debera tener DSA1 para poder cumplir este requerimiento. Qu
condicin es ms restrictiva para el sistema, esta o la establecida por el primer apartado?
Cul elegiramos en nuestro diseo si DSA1 debe cumplir ambas?
Hecho por Guille. Se aceptan correcciones.

A PARTADO A )
Sabiendo que la funcin de distribucin del tiempo de espera es FW (t) = 1 e()t ,
despejamos:
0.95 = 1 e(50)0.010
0.05 = e(50)0.010
log 0.05 = ( 50) 0.010
log 0.05
= 50
0.010
log 0.05
= 50
180.103
0.010
Luego la tasa de servicio tiene que ser de 180.103 peticiones por segundo o superior.
A PARTADO B )
70
Vamos a suponer que el tiempo que tarda DSA1 en redirigir la peticin es despreciable.
Tenemos que calcular primero cul es el tiempo medio de espera de peticiones a DSA2.
Sabiendo que es un M/M/1, tenemos que
W2 =
1
300
200
300
= 0.01 s
Sabemos que el tiempo total de estancia ser una media ponderada entre los de DSA1
y DSA2, luego
W = 0.75W1 + 0.25W2
, as que si queremos que ese tiempo sea igual o inferior a 6 milisegundos, despejamos
y vemos que
0.006 0.75W1 + 0.25 0.01 =
0.0035
W1 = 0.0046 W1
0.75
Dejuan opina que: 0.006 W1 + 0.25 0.01 ya que todas las peticiones a DSA1 van a
tener que ser procesadas por l, y si no puede hacer nada con ellas, las redirige. Con
1
= = 335.
estos clculos: W1 0.0035, es decir 3.5ms. Ahora despejamos W =
Fin de la sugerencia
Tenemos unos 4 milisegundos para responder en DSA1. Vamos a despejar ahora para
sacar la tasa de servicio :
W1 =
L1
W1 =
1
1
W1 =
W1 = 1 + W1
1 + W1
=
W1
Sustituyendo, nos queda 264.285. Dado que esta condicin nos da una tasa de
servicio ms grande, elegiramos esta para cumplir los dos requisitos que se nos piden.
Ejercicio 2.21: Un determinado bufete de abogados tiene, entre otras actividades, un

servicio de generacin de informes legales sobre los asuntos que sus clientes le plantean.
Para ayudar al personal del bufete en la gestin de dicho servicio se dispone de un sistema
de gestin de flujo de trabajo.
El flujo de trabajo que siguen las peticiones recibidas es el siguiente:
1 Un primer empleado, que denominaremos E1, verifica que las peticiones son correctas,
recopila informacin asociada a ellas y las clasifica para su posterior proceso en dos
71
grupos distintos: civil o penal. Se reciben en promedio un 25 % de peticiones de

tipo penal y un 75 % de tipo civil. Este proceso de revisin, acopio de informacin
y clasificacin se realiza en un tiempo medio de 1 da. Cada grupo de peticiones es
enviado, a travs del sistema de gestin de flujo de trabajo, a un grupo de empleados
distintos.
2 Las peticiones de tipo civil son recibidas por el empleado C1, que es el encargado de
elaborar el informe. Este empleado tarda un tiempo medio de 4 das en realizar un
informe. Tras la realizacin del informe, el empleado C2 revisa el trabajo del primero,
determinando si el informe es correcto, y puede seguir su curso, o si necesita un
trabajo posterior, en cuyo caso lo devuelve anotado a la bandeja de entrada de C1
para que realice las correcciones oportunas. C2 emplea un tiempo medio de 2 das en
realizar esta revisin, y se sabe que, en promedio, la mitad de los informes que recibe
C2 necesitan volver a C1 para ser modificados.
3 Las peticiones de tipo penal siguen un proceso idntico a las de tipo civil, pero las
realizan los empleados P1 y P2. P1 emplea en el primer proceso un tiempo medio de
10 das por peticin, mientras que P2 emplea solamente 4 das. El porcentaje promedio
de documentos que son devueltos a P1 es de un 25 %.
4 Tras ser aceptado un informe de cualquiera de los dos grupos, pasa al departamento
de acabado final, donde el empleado E2 realiza su impresin en calidad, encuadernado
y envo al cliente que lo solicit. En este proceso se emplean 0.25 das.
En la empresa se recibe un promedio de una peticin cada D das laborables. El sistema de
flujo de trabajo realiza el encolamiento de las solicitudes y los informes elaborados en su paso
a travs del proceso establecido.
Para realizar los clculos que se piden a continuacin, suponer que todos los tiempos
indicados son variables aleatorias distribuidas exponencialmente.
a. Dibujar el esquema del sistema de control de flujo de trabajo establecido, visto como
una red de colas, en la que cada empleado es el servidor que procesa las peticiones
recibidas. Calcular las tasas de servicio de cada uno de los servidores, y las tasas
de peticiones que recibe cada uno de ellos, indicando las suposiciones que haya sido
necesario realizar para poder obtener dichos valores.
b. Calcular el tiempo medio que tarda el bufete en realizar un informe desde que es
recibida la solicitud del cliente.

a. A la hora de realizar el esquema del sistema suponemos que las colas son infinitas
puesto que un empleado puede tener una pila de trabajo pendiente tan grande
como sea necesaria.
La tasa de servicio se calcula igual para todos los servidores, mediante la frmula:
=
72
1
Ts
La siguiente tabla recoge los resultados:

Servidor/Empleado
Tasa de servicio () [s1 ]
E1
0.000011574
C1
0.000002894
C2
0.000005787
P1
0.000001157
P2
0.000002894
E2
0.000046296
La tasa de llegadas de cada servidor es:

Servidor/Empleado
Tasa de llegadas () [s1 ]
E1
1/D
C1
3/(2D)
C2
C1 = 3/(2D)
P1
1/(3D)
P2
P1 = 1/(3D)
E2
0.5 C1 + 0.75 P1 = 1/D
Para los servidores C1 y P1 hemos calculado la tasa de llegadas como sigue

C1 =
P1 =
0.75
0.75
3
+ C1 0.5 = C1 =
=
D
D 0.5
2D
0.25
0.25
1
+ P1 0.25 = P1 =
=
D
D 0.75
D3
b. Vamos a considerar los subsistemas de procesamiendo de peticiones civiles

y penales de manera independiente, puesto que tienen retroalimentacin, y
calculamos su tiempo medio de servicio.
Con los datos que ya tenemos calculados, podemos conocer el factor de
utilizacin y el nmero medio de clientes de cada uno de los servidores. A partir
de este nmero, aplicamos el teorema de Little para obtener el tiempo medio de
estancia en cada uno de estos servidores. Finalmente, para calcular el tiempo total
slo debemos sumar los tiempos ponderados.
La siguiente tabla recoge los valores calculados segn acabamos de indicar:
73
S/E
= / = T
L = /(1-) [clientes]
W = L/ [s/cliente]
E1
1/D
1/(D 1)
D/(D 1)
C1
6/D
6/(D 6)
4D/(D 6)
C2
3/D
3/(D 3)
2D/(D 3)
P1
10/(3D)
10/(3D 10)
30D/(3D 10)
P2
4/(3D)
4/(3D 4)
12D/(3D 4)
E2
1/(4D)
1/(4D 1)
D/(4D 1)
Finalmente procedemos a calcular el tiempo medio de estancia en el sistema, que

ser el tiempo medio que tarde el bufete en realizar un informe:
P
P
Li
Li
P
W =
=
1/D
i
Ejercicio 2.22: Se realizan medidas sobre el tiempo que emplea en procesar peticiones
un servidor de aplicaciones, descubriendo que su distribucin de probabilidades se puede
aproximar por una funcin de Pareto de parmetros tm=5 ms y k=3. Partiendo de estos
datos:
a. Si el servidor recibe un trfico de Poisson con un valor medio de 100 peticiones/s,
calcule el valor medio del tiempo de respuesta del servidor a las peticiones del usuario.
b. Si la salida del servidor de aplicaciones se recibe a la entrada de un servidor de registro
de trfico que tiene un tiempo de servicio distribuido exponencialmente, y que es capaz
de procesar un promedio de 10000 peticiones/s, comentar qu modelo de sistema de
colas sera adecuado para representar el comportamiento de este servidor. Escribir el
modelo elegido en notacin de Kendall.
Nota: La funcin de densidad de una distribucin de Pareto viene dada por la frmula:
f (t) = k
tkm
tk+1
para t > tm

a. Primero tenemos que calcular el tiempo medio de servicio. Para ello calculamos
la esperanza de la distribucin que nos dan:
Z
Ts =
3t
1, 25 107
= 1, 875 107 s
t4
A partir de aqu podemos calcular la tasa de servicio

=
1
= 5.33 106 s1
Ts
74
Calculamos ahora el factor de utilizacin y con l el nmero medio de clientes en

el sistema, pues estamos empleando un modelo M/G/1
=
2 E[S 2 ]
= 1, 875 105 = L =
= 1, 875 103
2(1 )
Con esto podemos calcular el tiempo medio de respuesta apoyndonos en el

teorema de Little:
L
W = = 1.875 104
b. Deberamos utilizar una red de colas con dos servidores siendo el primero M/G/1
y el segundo G/M/1 donde G es la distribucin de Pareto.
Ejercicio 2.23: Un sistema de proceso de transacciones emplea un monitor de proceso de

tipo hbrido. Mantiene una cola de llegada de solicitudes que son atendidas en cualquiera
de los dos procesos que mantiene permanentemente activos para este fin. Las solicitudes de
ejecucin de transacciones llegan al sistema siguiendo un proceso de Poisson, con una tasa
de llegadas de 50 peticiones / s. El tiempo de ejecucin de una transaccin es independiente
del resto de los procesos que se encuentre ejecutando el sistema. Dicho tiempo se puede
considerar distribuido exponencialmente, con un valor medio de 0.02 s.
a. Calcular el tiempo medio de estancia en el sistema de cada peticin, justificando
adecuadamente el modelo de clculo elegido.
b. Un anlisis ms detallado del sistema nos permite medir la varianza del tiempo de
ejecucin de la transaccin, que resulta ser de 0.00036. Justificar razonadamente la
validez o no del modelo elegido en el caso anterior, proponiendo, en caso de que no sea
vlido, modelos alternativos de clculo.
Ejercicio 2.24: Un sistema de proceso de transacciones emplea un monitor de proceso

de tipo simple, necesitando un proceso por cada transaccin en ejecucin. Por motivos
de rendimiento del sistema, el mximo nmero de procesos que se le permite ejecutar
simultneamente es de 5. Las solicitudes de ejecucin de transacciones llegan al sistema
siguiendo un proceso de Poisson, con una tasa de llegadas de 100 peticiones / s. El tiempo
de ejecucin de una transaccin es independiente del resto de los procesos que se encuentre
ejecutando el sistema. Dicho tiempo se puede considerar distribuido exponencialmente, con
un valor medio de 0.01 s.
a. Calcular la probabilidad de que se rechace una solicitud de transaccin por no haber un
proceso libre para ejecutarla, justificando adecuadamente el modelo de clculo elegido.
b. Calcular el tiempo medio de estancia en el sistema de una peticin.
75
Ejercicio 2.25: Un sistema distribuido construido bajo el modelo J2EE consta de dos capas:
la capa de servicio Web, compuesta por un servidor, y la capa de servidores de aplicaciones,
que consta de dos elementos que procesan en paralelo. El reparto de peticiones desde el
servidor web a los servidores de aplicaciones se realiza de manera aleatoria y no es necesario
guardar datos de los usuarios entre una peticin y la siguiente.
El servidor web tiene cola de peticiones finita. Admite un mximo de 6 peticiones, que se
procesan en secuencia. En los servidores de aplicaciones se puede considerar que no hay
lmite para el nmero de peticiones que admiten. Se reciben las peticiones siguiendo un
proceso de Poisson a un ritmo promedio de 200 peticiones por segundo. Los tiempos de
servicio de los servidores de ambas capas se puede considerar que siguen una distribucin
exponencial, con valor medio de 3 ms en el caso del servidor web y 9 ms en cualquiera de los
servidores de aplicaciones.
a. Dibujar el esquema del sistema propuesto, e identificar las tasas de entrada efectivas
en cada una de las capas. (No las calcule en este apartado, slo exprese las frmulas
bsicas que las relacionan con la tasa de entradas total).
b. Calcular la fraccin de peticiones que se rechazan del sistema.
c. Calcular el tiempo medio de respuesta para las peticiones que no son rechazadas del
sistema.
d. Identificar las soluciones ms eficaces para mejorar el tiempo medio de respuesta
calculado anteriormente.
Ejercicio 2.26:
Una empresa dispone de un monitor de proceso de transacciones que
controla el acceso a una base de datos. El monitor recibe solicitudes con una frecuencia media
de dos veces por segundo segn una distribucin de Poisson. Si el monitor est atendiendo
alguna peticin, las solicitudes que lleguen esperan en una cola cuya capacidad mxima es
de ocho solicitudes. Si la cola est llena, la solicitud es rechazada y debe ser enviada de nuevo
por el ordenador cliente. Desde que el monitor acepta una transaccin hasta que la da por
terminada, transcurre un tiempo distribuido exponencialmente cuya esperanza matemtica
es de 500 milisegundos.
a) Qu modelo, segn la notacin de Kendall, ser aplicable a este sistema?
b) Calcular el tiempo medio de estancia en el sistema de las peticiones de autenticacin de
los clientes.
c) Qu pasara si se ampliase la cola del monitor para darle una capacidad ilimitada?

He corregido el apartado B). Al aplicar Little hay que tener en cuenta la tasa de llegadas
efectiva
A PARTADO A )
76
El modelo sera M/M/1/9, ya que como mucho puede haber 9 clientes en el sistema (ocho
en la cola y una en el monitor).
A PARTADO B )
Segn nos dicen en el enunciado, tenemos que = 2 s1 . Por otra parte, Ts = 0.5 s as
que = T1s = 2 s1 . Dado que = , podemos usar la frmula simplificada que nos
dice que
K
9
L=
= = 4.5
2
2
y por lo tanto el tiempo medio de estancia es
W =
siendo
L
L
4.5
=
=
= 2.5 s
0
(1 pK )
2(1 p9 )
9
1
p9 = p0
=4
= 0.1
K +1
A PARTADO C )
En ese caso el modelo sera M/M/1, que al tener factor de utilizacin =
tendra un estado estable y la cola crecera hasta el infinito.
= 1 no
Ejercicio 2.27: El proceso de generacin de un ticket en el Ticket Granting Server de

una determinada implementacin de Kerberos requiere la ejecucin en serie de dos procesos
independientes: Proceso A: valida el ticket de la solicitud recibida. Su tiempo de ejecucin
est distribuido exponencialmente, con valor medio de 98 ms. En promedio, se sabe que
considera no vlidos un 10 % de los tickets recibidos, de modo que no pasan al proceso B ms
que un 90 % del total. Proceso B: genera un nuevo ticket para el servidor solicitado. Tiene
un tiempo de ejecucin distribuido exponencialmente, con valor medio de 80 ms. Ambos
procesos son independientes y con colas de espera suficientemente grandes, de modo que no
se producen prdidas de peticiones. Ambos ejecutan las peticiones de manera iterativa.
El servidor recibe peticiones de generacin de tickets de acuerdo a un proceso de Poisson,
con tasa media de llegadas de 10 peticiones / s.
a. Determinar el modelo de colas adecuado para cada uno de los sistemas, y calcular la
expresin genrica del tiempo medio de estancia en el sistema, a partir de la funcin
de distribucin de probabilidad del modelo nacimiento-muerte.
b. Calcular el tiempo medio de estancia en el conjunto del sistema de las peticiones
aceptadas por el primer servidor.
c. Detectar cul es el cuello de botella de este sistema, y ajustar el valor medio del tiempo
de servicio en l para eliminarlo, de modo que el tiempo de estancia en el sistema total
se reparta por igual entre ambos procesos.
Recordemos que =
77
Ejercicio 2.28:
Una empresa decide poner en alta disponibilidad su servidor de
autenticacin de usuarios de la manera ms econmica que sea posible. Para ello, duplica
el servidor, y para lograr el balanceo de carga entre ambos servidores realiza un sencillo
programa. Dicho programa se instala en un tercer servidor, cuya direccin IP ser a la que
accedan a los usuarios. El programa de balanceo no admite encolamiento de las peticiones
que recibe de los clientes, de modo que si se encuentra procesando una de ellas, rechaza todas
las peticiones adicionales que le lleguen.
a. Si el tiempo de proceso del balanceo se encuentra distribuido exponencialmente con
un valor medio de 2 ms., y el servidor recibe peticiones siguiendo un trfico de Poisson
con un valor medio de 250 peticiones / s., calcular la probabilidad de que una peticin
que reciba sea rechazada.
b. Cada uno de los servidores de autenticacin tiene un tiempo de servicio con una
distribucin uniforme entre 5 y 10 ms., y su cola de espera de peticiones no est
limitada. Calcular el tiempo medio de estancia en el conjunto del sistema balanceadorservidor de autenticacin de las peticiones no rechazadas.

a. Nos encontramos ante un modelo de colas de tipo M/M/1/1 con = 250s1 y
= 500s1 .
La probabilidad de que una peticin sea rechazada es la probabilidad de que slo
haya una unidad en el sistema:
p1 = 1 p0 = 1
1 /
= 0.33
1 (/)2
Es decir, tendremos un 33 % de posibilidades de que el sistema

b. Suponemos que el balanceador enva las peticiones a ambos servidores de forma
alterna, de modo que tenemos un 50 % de posibilidades de que una peticin dada
acabe en cada uno de los dos servidores.
Puesto que tenemos un sistema M/M/1/1, la tasa efectiva de llegadas ser
0 = (1 1 ) = 167.5s1 por lo que la tasa de llegadas a cada uno de los dos
servidores ser s = 83.75s1 .
Ahora cada uno de los servidores se trata de un M/M/1, donde podemos calcular
el tiempo de servicio como:
W =
L
E[S 2 ]
83.75 3 107
0.4
=
+ =
+
= 8.05 103 segundos
2(1 )
2(1 0.6)
83.75
78
Captulo III
Aspectos operacionales de los

sistemas distribuidos:
Disponibilidad
III.1.
Introduccin
A lo largo de este tema vamos a estudiar la teora de la disponibilidad de los sistemas

distribuidos as como algunas arquitecturas que permiten obtener un incremento de la
misma.
Para empezar debemos definir qu es la disponibilidad.
Disponibilidad
Definicin III.1 Disponibilidad. La disponibilidad de un sistema es la probabilidad de que este

se encuentre operativo en un instante de tiempo determinado.
Hay dos motivos por los que un sistema puede no estar disponible:
1 Paradas no planificadas
Este tipo de paradas se deben a fallos en los equipos o en los programas que
implementan los servicios.
Requieren tratamiento estadstico, pues no habr dos iguales. Los sistemas que
las minimizan se llaman de Alta Disponibilidad (High Availability, HA)
Algunas de las causas ms frecuentes por las que se producen este tipo de paradas
son:
Extensin del tiempo destinado a operaciones planificadas.
Error humano.
Fallo en aplicacin.
Fallo del sistema operativo.
Fallo hardware.
Errores de configuracin del software.
79 de 112
2 Paradas planificadas
Son requeridas por la aplicacin para su correcto funcionamiento: Rearranques
programados, copias de seguridad, cambios de configuracin...
Por ser previsibles permiten un tratamiento sistemtico. Los sistemas que las
minimizan se denominan de Operacin Continua (Continuous Operation, CO)
Algunas de las causas ms frecuentes por las que se producen este tipo de paradas
son:
Copias de seguridad.
Reemplazar o actualizar hardware.
Reemplazar o actualizar aplicaciones.
Actualizar sistema operativo.
Instalacin de parches
Evidentemente, un sistema ideal sera de Alta Disponibilidad y de Operacin Continua.
No obstante, a mayor disponibilidad del sistema mayor es el coste del mismo y su
mantenimiento. Por tanto, es necesario valorar el nivel de disponibilidad requerido
para un funcionamiento aceptable e invertir lo necesario para conseguirlo sin tratar de
superarlo.
Antes de seguir estudiando el tema de la disponibilidad, vamos a ver una serie de
definiciones de trminos que aparecern a lo largo de los apuntes y que es necesario
precisar.
Fiabilidad
(Reliability)
Definicin III.2 Fiabilidad (Reliability). Probabilidad de que un componente o sistema

contine funcionando en un determinado instante en el tiempo.
Elasticidad
o Resiliencia
(Resiliency)
Definicin III.3 Elasticidad o Resiliencia (Resiliency). Capacidad de un sistema para

adaptarse a condiciones externas imprevistas (fallos, aumento de carga...) para continuar
cumpliendo sus parmetros de calidad.
Mantenibilidad
(Serviceability)
Definicin III.4 Mantenibilidad (Serviceability). Es la probabilidad de realizar una

reparacin satisfactoria en un tiempo determinado.
Sistemas
tolerantes
a
fallos
(FaultTolerant
Systems)
Definicin III.5 Sistemas tolerantes a fallos (Fault-Tolerant Systems). Sistemas que

contienen componentes hardware dobles de modo que el fallo de uno de ellos no suspende su
operacin.
80
Clusters
de
alta
disponibilidad (High
Availability
Clusters)
Definicin III.6 Clusters de alta disponibilidad (High Availability Clusters). Conjunto

de nodos de servicio que comparten conexiones externas (red, discos...) y estn gestionados por
un software especial que permite proporcionar servicio sin interrupciones ante el fallo de alguno
de sus componentes.
Clusters
de
alto
rendimiento
(High Performance
Clusters)
Recuperacin
ante desastres
(Disaster
Recovery)
Definicin III.7 Clusters de alto rendimiento (High Performance Clusters). Conjunto de

nodos de servicio que comparten una misma carga de trabajo.
Definicin III.8 Recuperacin ante desastres (Disaster Recovery). Capacidad de una

instalacin de recuperar la operatividad tras un evento de gran magnitud, bien de tipo local
(edificio), urbano (ciudad) o regional (rea extendida con infraestructuras comunes).
III.2.
Teora de la disponibilidad
III.2.1.
Disponibilidad
La disponibilidad, A, de un sistema se estima a partir de la medida del tiempo que ha

estado operativo, Top , en un intervalo de tiempo, Ttot , suficientemente grande.
A=
Top
Ttot
Pero esta medida no da una idea global de la disponibilidad del sistema, pues un mismo
valor puede obtenerse de la misma forma.
Por ejemplo, no es lo mismo que un sistema est disponible 99 horas de cada 100 que 99
segundos de cada 100. Incluso si dos datos se han obtenido dividiendo los datos en las
mismas unidades y estamos, por ejemplo, en 99 horas de cada 100 de actividad, puede
ser que el sistema haya fallado una nica vez en esas 99 horas y tardase una hora en
recuperarse o que el sistema falle cada media hora tardando poco en recuperarse.
Por ello se utilizan otras medidas para estudiar la disponibilidad del sistema.
Tiempo medio entre fallos
Tiempo medio hasta el

fallo
Tiempo
medio de reparacin/recuperacin
Definicin III.9 Tiempo medio entre fallos.

En ingls Mean Time Between Failures, MTBF, es valor esperado del tiempo que transcurre
entre dos fallos consecutivos de un equipo.
Definicin III.10 Tiempo medio hasta el fallo.

En ingls Mean Time To Failure, MTTF, es el valor esperado del tiempo de vida de un equipo
o sistema, medida de su Fiabilidad (Reliability).
Definicin III.11 Tiempo medio de reparacin/recuperacin.
81
En ingls Mean Time To Repair/Restore, MTTR, es el valor esperado del tiempo que se tarda
en sustituir un equipo averiado o recuperar un fallo de software.
A partir de estos valores se calcula la disponibilidad segn la frmula:
A=
MTTF
MTTF
=
M T BF
MTTF + MTTR
Para pasar de la primera a la segunda frmula se emplea la relacin lgica M T BF =

M T T F + M T T R, es decir, el tiempo que transcurre entre dos fallos es la suma del
tiempo que tarda en recuperarse el sistema tras un fallo ms el tiempo que tarda en
volver a fallar.
III.2.2.
Fiabilidad
La fiabilidad de un componente o sistema en el tiempo es la probabilidad de que el

sistema contine funcionando en un instante de tiempo. Si denominamos T al tiempo
de vida del componente, su fiabilidad viene dada por la expresin:
R(t) = P{T > t}
La vida del componente, T , es una variable aleatoria, cuya funcin de distribucin es
FT (t) = P{T t}
Evidentemente ambas variables probabilidades deben sumar siempre 1, R(t) + FT (t) =
1 y derivando obtenemos que sus funciones de densidad son iguales pero de signo
contrario.
Una vez hemos definido estas variables podemos definir el tiempo medio hasta fallo
como la esperanza de vida de un componente:
Z
M T T F = E[T ] =
f FT0 (t)dt
Ahora, sabiendo algo de probabilidad, podemos calcular la probabilidad de que un

sistema falle antes de un instante, x, sabiendo que funcionaba en un instante t < x.
FT (x|T > t) = P{T x|T > t} =
=
P{(T x) (T > t)}

P{t < T x}
=
=
P{T > t}
P{T > t}
FT (x) FT (t)
1 FT (t)
y derivando con respecto a x se obtiene

fT (x|T > t) =
Funcin de
tasa de fallo
fT (x)
1 FT (x)
A partir de esta ltima expresin se define la funcin de tasa de fallo al evaluarla en

82
x = t.
r(t) = fT (t|T > t) =
R0 (t)
R(t)
y se interpreta como la probabilidad de que un componente que funciona falle en el

instante siguiente:
P{t < T t + dt|T > t} = fT (t|T > t)dt = r(t)dt
Si la tasa de fallos tiene un valor constante, integrando la funcin r(t) entre 0 y t y
despejando R(t) llegamos a:
R(t) = et = FT (t) = 1 et
con lo que acabamos de obtener que el tiempo de vida es una distribucin exponencial
y su valor esperado ser el MTTF=1/
III.2.3.
Distribucin de los fallos
La funcin de tasa de fallos en un equipo tiene la forma que se muestra en la figura:
Durante la zona de infancia la tasa de fallos es alta debido al montaje de componentes

defectuosos. Esta tasa de fallos se reduce con el tiempo hasta alcanzar una etapa de
madurez que se correspondera con la poca en que tenemos tasa de fallos constante.
Por ltimo el envejecimiento del equipo aumenta la tasa de fallos.
Todos los clculos se realizan pensando en la zona de madurez del equipo, trabajando
con r(t) = cte
Por otro lado tenemos tambin los fallos en programas que pueden dividirse en dos
tipos segn su tratamiento
83
1 Programas que no son reparados cuando se encuentra el fallo sino que es

necesario esperar a que se publique una nueva versin del mismo. Es la situacin
habitual en produccin y con programas cerrados.
El modelo de tasa de fallos constante es vlido durante el uso de una misma
versin. Al cambiarla es necesario recalcular todos los datos.
2 Programas cuyos defectos se corrigen conforme se encuentran. Suele tratarse
de programas de produccin propia o ciclos de pruebas en la produccin de
programas. El principal problema es que la solucin de un defecto puede y suele
introducir otros nuevos.
En este caso el modelo de tasa de fallos constante no es vlido ya que
tendremos una tasa de fallos que decrece con el tiempo (segn se van arreglando
los desperfectos). Su forma depende del modelo elegido para el ritmo de
descubrimiento de fallos.
III.2.4.
Mantenibilidad
Es la probabilidad de realizar una reparacin satisfactoria en un tiempo determinado.

Mide la rapidez y facilidad con que un sistema se vuelve a poner operativo tras un fallo.
M (t) = P{T 0 > t} con T el tiempo de reparacin
Este tiempo incluye el tiempo necesario para descubrir el fallo, encontrar la causa,
conseguir las piezas necesarias, la instalacin de las mismas, arrancar el sistema de
nuevo, etc. Es decir, incluye todo el tiempo gastado desde que se produce el fallo (an
si no se detecta) hasta que se resuelve el problema.
M T T R = E[T 0 ]
III.2.5.
Componentes en serie frente a Componentes en paralelo
Si tenemos un sistema compuesto por componentes en serie, un fallo en cualquiera de

ellos implica un fallo global. La conexin en serie puede no ser fsica pero si lgica, una
componente depende del resultado del trabajo de otra.
Suponiendo que el fallo en cada componente es independiente del resto, tenemos:
A=
n
Y
i=1
Ai ; R(t) =
n
Y
Ri (t); r(t) =
i=1
n
X
ri (t)1
i=1
Si tenemos un sistema compuesto por componentes en paralelo y estas componentes

son redundantes para su funcionamiento, un fallo en una de ellas no implicar un fallo
en el sistema.
1
No veo clara esta frmula
84
Suponiendo que el fallo en cada componente es independiente nos queda:

n
n
n
Y
Y
Y
2
A = 1 (1 Ai ) ; FT (t) =
FTi (t); R(t) = 1 (1 Ri (t))
i=1
III.3.
i=1
i=1
Mejoras de la disponibilidad
Recordemos la ecuacin inicial que dimos para la disponibilidad:

A=
MTTF
1
=
MTTF + MTTR
1 + M T T R/M T T F
simplemente viendo esta fraccin podemos ver que la disponibilidad de un sistema

puede mejorarse (aumentar) de dos formas:
Aumentando M T T F mejorando la calidad de los equipos, introduciendo
redundancias o eliminando Puntos Simples de Fallo
Reduciendo M T T R mediante la reduccin del tiempo empleado en cualquiera
de las siguientes fases:
Tiempo de latencia (desde que se da el fallo hasta que se descubre que algo
falla)
Tiempo para aislarla (desde que se descubre hasta que se encuentra el
motivo)
Tiempo para corregirla
Tiempo para verificar que todo funciona bien
2
Estar disponible cuando al menos una componente est disponible
85
III.3.1.
Single Point
Of Failure,
SPOF
Arquitecturas que incrementan la disponibilidad
La disponibilidad de una cadena de procesamiento es siempre menor que la menor

de las disponibilidades de sus componentes. Denominamos Single Point Of Failure,
SPOF a los puntos ms crticos del sistema, aquellos que al fallar implican la cada del
servicio.
Como es evidente, la forma en que ms podemos incrementar el M T T F de cada
componente es mediante la creacin de un cluster (elementos redundantes) en cada
parte de la cadena de procesamiento. Esta solucin, adems, elimina los SPOF al aadir
redundancias incluso a esos componentes ms crticos.
Conseguir que varios sistemas realicen en paralelo una misma funcin no es sencillo y
la solucin empleada depende de factores como el tipo de elemento al que se le quiere
dar redundancia y las necesidades de disponibilidad del sistema completo.
Fail-over
Fail-back
En cualquier caso, siempre es necesario considerar dos procesos a la hora de

implementar un sistema: el cmo actuar cuando se produce un fallo para poder
mantener el servicio, Fail-over, y cmo actuar para recuperar la situacin normal una
vez se resuelve el fallo Fail-back.
Existen diferentes tipos de redundancia:
1 Segn el estado de cada elemento del cluster
Pueden estar todos los elementos activos (AA), uno activo y el resto preparados
para activarse casi instantneamente (AS) o uno activo y el resto detenidos
pudiendo activarse en un cierto periodo de tiempo (AP)
2 Segn el reparto de carga entre los elementos del cluster
Puede ser dinmico (D), en cuyo caso no habr que preocuparse en caso de fallo
de un componente; o esttico (E), donde un fallo implica reconfigurar el reparto
de carga
3 Segn el tratamiento de las conexiones activas
Las sesiones activas pueden continuar (C) tras un fallo o ser interrumpidas (I).
III.4.
Redundancia en los sistemas de comunicaciones
Los sistemas de comunicaciones son uno de los puntos crticos de todo sistema
distribuido.
Vamos a distinguir la redundancia en las redes de rea local (LAN) y en redes de rea
extendida (WAN) considerando en ambos casos los estndares de facto actuales: redes
LAN basadas en Ethernet y TCP/IP como medio de transporte.
Las caractersticas de los equipos que actualmente se emplean para implementar una
LAN hacen que estas redes se puedan construir atendiendo a tres modelos distintos:
Nivel 2 compartido Mltiples servidores se conectan a un mismo segmento de
86
LAN implementado en un Hub. Es el menos utilizado por ser el menos eficiente y

flexible.
El hub es un dispositivo que tiene la funcin de interconectar las computadoras
de una red local. Su funcionamiento es ms simple comparado con el Switch y
el router: El hub recibe datos procedentes de una computadora, los transmite a
los dems. En el momento en que esto ocurre, ninguna otra conmutadora puede
enviar una seal. Su liberacin surge despus que la seal anterior haya sido
completamente distribuida.
Nivel 2 conmutado Cada enlace es un segmento de LAN. Todos los componentes
se interconectan mediante switches, que actan como puentes multipuerta.
Suele emplearse en el nivel de acceso, por ejemplo, en las conexiones de los
ordenadores de las granjas de servidores.
Nivel 3 Cada enlace es un segmento de red que une un elemento con un
router. El router se implementa tambin en los propios switches mediante mdulos
especiales.
Suele emplearse en el nivel de agregacin interconectando diversos niveles de
acceso, servidores especiales y redes externas.
Estos modelos suelen coexistir dentro de un Centro de Proceso de Datos (CPD)
La instalacin de redundancias en el nivel 3 implica el uso de un protocolo de

encadenamiento dinmico (OSPF, BGP), igual que en el caso de redes de rea extendida
(WAN).
A nivel 2, implica la aparicin de bucles en los posibles caminos entre dos nodos de
la red lo que lo hace incompatible con el protocolo Transparent Bridging empleado en
Ethernet. Este problema se resuelve con el Spanning Tree Protocol, que se mejor con el
Rapid Spanning Tree Protocol. Para optimizar el uso de VLANs se deben crear mltiples
spanning trees, solucin proporcionada por Multiple Spanning Tree.
87
En definitiva, si en la red de comunicacin tenemos redundancias en un determinado

nivel, es necesario emplear un protocolo que permita encontrar el mejor camino de un
elemento a otro an con las redundancias.
III.4.1.
Rapid Spanning Tree Protocol, RSTP
Al aplicar este protocolo tenemos cada switch asociado a un identificador que nos da su
prioridad. El de mayor prioridad (menor identificador, ID1) se denomina switch raz. El
siguiente en prioridad se le denomina switch raz alternativo (ID2).
Para cada puerto hay que determinar de que tipo es:
Raz. Da el mejor camino al switch raz
Designado. Proporciona a cada segmento de red conectado al switch el mejor
camino al switch raz. Es decir, que para algn nodo, su mejor camino hasta el
nodo raz implicar coger justo este enlace.
Alternativo. Otros.
Peridicamente, cada switch genera una Bridge Protocol Data Unit, BDPU y la enva a
todos los switches de la red.
Mirar el ejemplo de moodle subido por la profesora. Explica bastante bien el protocolo
III.4.2.
Deteccin de fallos en RSTP
Puede producirse un fallo en un enlace conectado a un RP o DP, que se detecta

directamente por los switches que forman el enlace; o puede darse un fallo en un switch.
Si hay tres turnos seguidos en los que no se recibe BDPU de un switch, se le da por
muerto.
Tras el fallo, todos los switches reconfiguran el spanning tree, mediante intercambios
locales de los switches afectados por el cambio y el resultado se propaga al resto de
la red.
Observacin: Hay otra versin de este mecanismo es el spanning tree normal, en el que
nicamente el root bridge transmite BPDU. Slo se detecta un problema tras 20 segundos
(vida mxima) y tras esto recalculamos el spanning tree completo.
III.4.3.
Redundancia en la conexin de servidores a nivel 2
La redundancia bsica en la conexin de un ordenador a una LAN se consigue

mediante el uso de dos o ms adaptadores de red.
Los puertos de estos adaptadores (un puerto por adaptador) tendrn la misma MAC,
pero slo uno de los adaptadores estar disponible. Si cae, el sistema activar otro. No
afecta a los protocolos de niveles superiores.
88
EtherChannels
Definicin III.12 EtherChannels. Consiste en la agrupacin de enlaces Ethernet donde todos

los puertos poseen la misma MAC como si fuesen slo 1 (y as lo ven desde arriba) y estn activos
simultneamente.
Da mayor rapidez en la resolucin de fallos y mejora el ancho de banda pero su implementacin
es costosa. Se requiere que ambos extremos de la conexin tengan soporte de EtherChannels.
Los componentes de un EtherChannel no se pueden disgregar para conectar varios dispositivos
distintos. A todos los efectos, es un nico enlace.
III.4.4.
Redundancia de las WAN
Las redes WAN permiten establecer la interconexin entre elementos distantes de

sistemas distribuidos. Se basan en el protocolo TCP/IP y se distinguen dos tipos de
componentes: enlaces y unidades de encadenamiento (routers).
La alta disponibilidad de las WAN se consigue teniendo muchos routers y enlaces para
que siempre haya caminos alternativos. La gestin del trfico a travs de las diferentes
rutas se lleva a cabo con los protocolos de encadenamiento dinmico que estudiamos
en Redes: OSPB y BGP.
OSPF
Definicin III.13 OSPF. Protocolo de encadenamiento dinmico eficaz y ampliamente utilizado

en redes IP. Se basa en el conocimiento de toda la red y el empleo de Dijkstra para localizar el
camino ms corto. Se organiza la red en reas dentro de las cuales los routers encaminan los
paquetes. Para cambiar de rea se emplean los Area Border Gateways (routers fronterizos)
El mensaje OSPF Hello se emplea para conocer la topologa de la red con lo que cada router
conoce a sus vecinos. Y con el mensaje Link State se informa del estado de los enlaces.
Se puede producir un fallo en OSPF por la cada de un enlace, que se detecta de forma
inmediata, por la cada de un router, que se detecta gracias al protocolo OSPF Hello,
que sirve de keep-alive. El mensaje Hello se intercambia cada 10 segundos. Si tras cuatro
rondas no se han recibido Hellos de un router, se le da por muerto.
Si en un caso concreto se requiere una configuracin esttica (estaciones de trabajo, por
ejemplo) el router por defecto que se asigna a estos dispositivos se convierte en un SPOF
(Single Point Of Failure). Para evitarlo se emplea un cluster de routers controlado con el
protocolo Virtual Router Redundancy Protocolo, VRRP
VRRP
Definicin III.14 VRRP. Protocolo de clustering para routers empleado para proporcionar
redundancia en routers en los casos en que representan un punto nico de fallo en rutas de la
red. El router se sustituye por un virtual router formado por un router activo y otro en stand-by.
El router de mayor prioridad ser el activo y asume como propias una direccin IP y una MAC
que habrn sido asignadas al router virtual. Si cae el router se activa otro.
El router activo enva mensajes Hello en multicast cada x segundos. Si transcurre un
tiempo predefinido sin recibir mensajes Hello, se da al router por muerto y se activa
el siguiente en prioridad. Este tiempo de espera predefinido es menor cuanto menor
sea la prioridad. As cuando est un router activo que no sea el inicial, tendr ms
89
probabilidades de que se le d por muerto, por lo que el router principal tendr ms

probabilidades de volver.
En el fail-back hay dos opciones:
Si la configuracin activa preempt, el router de mayor prioridad asume el trfico.
Supone una breve interrupcin del servicio mientras se produce el cambio.
Si la configuracin desactiva preempt, se deja el router actual como activo hasta
un posible fallo, quedando el reincorporado como router de backup.
Balanceador
de carga
Definicin III.15 Balanceador de carga. Un balanceador de carga es un dispositivo capaz de

distribuir peticiones entre un grupo de servidores para su proceso. Tiene como objeto aumentar
la capacidad de proceso y la disponibilidad del servicio.
Previamente se realizaba este proceso en redes IP a travs del DNS, resolviendo el mismo nombre
por distintas IP pero esto no garantizaba que el servidor estuviera activo y los cambios del DNS
son lentos al propagarse por la red.
Frente a un switch que slo maneja informacin de nivel 2 y un router que slo maneja
informacin a nivel 3, el Load Balancer, LB tambin utiliza informacin de los niveles de
transporte y aplicacin para realizar el encadenamiento. Como mnimo debe garantizar que en
TCP todos los paquetes de la misma conexin van al mismo servidor.
Para emplear un LB, se asigna una direccin IP virtual (VIP), puerto y protocolo para
el servicio a prestar; se asocian al LB los servidores que prestan el servicio y se definen
unos mecanismos de distribucin de carga y entrega de paquetes.
Cuando llega una peticin, el LB decide qu servidor debe atenderla y se la reenva. El
servidor procesar la peticin y devolver una respuesta que ser reenviada al cliente.
Este ltimo paso, segn la configuracin de entrega de paquetes, puede eliminarse
siendo el servidor quien directamente responde al cliente. (Direct Server Return vs
Destination NAT)
El mecanismo de distribucin de carga puede ser cualquiera: Round Robin, alterno,
menor nmero de conexiones, ponderado, mejor tiempo de respuesta, por origen de
la peticin, etc.
En cualquier caso es necesario considerar condiciones lmite para realizar la entrega:
Mximo nmero de conexiones permitido
Umbral de tiempo de respuesta
Gracefull Shutdown. No mandar ms mensajes a un servidor que quiere
desconectarse
Tiempo de gracia. Tiempo que se deja a un servidor desde que est activo hasta
que se le enva trfico, para permitir su estabilizacin adecuada.
Si todos los paquetes de respuestas pasaban por el LB, se puede detectar un fallo si un
servidor deja de responder, se puede monitorizar en handshake de TCP o los cdigos de
90
retorno de HTTP. Si no es as, se emplean pruebas de nivel 3 con ICMP echo/replay; a

nivel 4, con apertura/cierre de conexiones TCP; o pruebas de nivel 7, tratar de conectar
con la aplicacin. Estos acciones las realizara el LB para comprobar que el servidor est
activo.
El LB debe ser capaz de hacer que un cliente se conecte siempre a un mismo servidor
para que se mantenga la sesin, que no est implementada de modo estndar en
TCP/IP. Existen diferentes formas de hacerlo:
Aplicando un algoritmo de balanceo por origen. Tiene el problema de que si
varios clientes estn tras una NAT son indistinguibles en este sentido.
Por concurrencia de conexiones. Una nueva peticin de un cliente se enva al
mismo servidor que mantiene la actual
Cookies o identificadores SSL que guarden informacin de la sesin. Requiere
analizar el paquete e impide que el balanceo se haga por paquete. Es necesario
partir la conexin TCP en el LB
III.4.5.
Redundancia en los sistemas de almacenamiento de la informacin
La informacin es el punto ms crtico de todo sistema informtico puesto que perder

datos o no tenerlos disponibles adecuadamente puede ser fatal para cualquier tipo de
negocio.
La redundancia de este tipo de elementos es ms compleja pues es necesario mantener
la consistencia y garantizar que los elementos de procesamiento redundantes accedan
a la misma copia de la informacin.
Existen diferentes arquitecturas de almacenamiento. Veamos algunas:
Conexin directa (Direct Attached Storage, DAS). Consiste en conectar el
dispositivo de almacenamiento directamente al servidor o estacin de trabajo, es
decir, fsicamente conectado al dispositivo que hace uso de l. Normalmente se
usa directamente el protocolo SCSI en alguna de sus variantes.
Conexin a red (Network Attached Storage, NAS). Es el nombre dado a
una tecnologa de almacenamiento dedicada a compartir la capacidad de
almacenamiento de un computador (Servidor) con computadoras personales o
servidores clientes a travs de una red (normalmente TCP/IP), haciendo uso de
un Sistema Operativo optimizado para dar acceso con los protocolos CIFS, NFS,
FTP o TFTP.
Red de rea de almacenamiento (Storage Area Network, SAN). Red dedicada
al almacenamiento que est conectada a las redes de comunicacin de una
compaa. Adems de contar con interfaces de red tradicionales, los equipos con
acceso a la SAN tienen una interfaz de red especfica que se conecta a la SAN.
Utiliza fibra ptica como medio de transporte y el protocolo FibreChannel
Internet SCSI (iSCSI) Estndar que permite el uso del protocolo SCSI sobre redes
TCP/IP
91
FibreChannel Over IP (FCIP) Encapsula el protocolo FibreChannel sobre IP

estableciendo tneles FC sobre TCP.
Internet Fibre Channel Protocol (iFCP) Implementa FC sobre IP pero no en modo
tnel sino interpretando el protocolo FC.
Uno de los mtodos para mantener redundante la informacin en unos ciertos discos
es el uso de Redundan Array of Independen Disks, RAID, que ya hemos estudiado
en otras asignaturas.
Los servidores de disco proporcionan herramientas autnomas para garantizar la copia

de la informacin, y garantizar as su disponibilidad para los servidores que la utilizan,
liberando as a los servidores de aplicaciones de la tarea de realizacin de las copias.
Estas copias pueden ser locales o remotas. Estas ltimas podran ser sncronas o
asncronas.
Dentro de las copias locales existen dos tipos: clonacin de discos (se copia la
informacin de una Unidad Lgica3 a otra) y las copias instantneas (Snapshots o Flash
Copy).
Flash Copy
Definicin III.16 Flash Copy. Copia de una Unidad Lgica en el instante que se solicita,
copiando los punteros a los sectores que contienen la informacin.
En caso de que haya una actualizacin de un sector, se copia la informacin antigua y se actualiza
el puntero de la copia instantnea.
Se emplean para generar una copia consistente de la informacin en un momento preciso para
su uso posterior.
Observacin: Bsicamente guardas un puntero a la posicin guardada. Si no la modifican,
3
Viene a ser como las particiones lgicas pero que afectan a diferentes discos, no slo a 1
92
pues ya lo tienes. Si se modifica esa parte del disco, mueves la antigua informacin a otro sitio y
actualizas tu puntero.
Las copias remotas sncronas consisten en que la actualizacin de la informacin del
servidor primario se copia a los secundarios y el proceso no finaliza hasta que no se ha
actualizado la informacin en todos los servidores, lo que da lugar a una alta latencia de
escritura. Empleado para realizar copias locales que garanticen la alta disponibilidad
En las asncronas, una vez se actualiza el primario se guardan los cambios en un buffer
y se van aplicando en el resto de servidores mediante un proceso en paralelo. Requiere
un protocolo de sincronizacin. Empleado para realizar copias remotas que permitan
la recuperacin ante desastres Leer ms
Las posibles averas en discos fsicos individuales son resueltas por la arquitectura
RAID. Si se producen averas en una Unidad Lgica (LUN) completa o en un servidor
de disco se siguen los siguientes pasos:
1 Fail-Over. Se interrumpe la copia remota y la LUN secundaria pasa a principal.
Para ello se notifica al servidor de proceso que debe usar a LUN secundaria y se
comienza a registrar los cambios.
2 Fail-Back Se copia el secundario activo al primario una vez recuperado. Para ello
se detiene el trabajo del servidor de proceso, se restablece la copia y se notifica al
servidor de proceso que puede seguir utilizando el primario.
III.4.6.
Redundancia en los sistemas de proceso
Este tipo de redundancia se consigue mediante la asociacin de los elementos de

proceso (servidores) en grupos (clusters) que realizan una tarea comn.
Cada servidor ejecutar un determinado nmero de grupos de servicio compuesto
por una identidad de red (direcciones a las que el servicio responde), un conjunto de
informacin almacenada en discos fsicos o LUNs y un conjunto de procesos.
Si un servidor de un cluster falla, los grupos de servicio que soporta deben ser
trasladados a otro elemento del cluster.
Bsicamente un grupo de servicios es un conjunto de actividades que desempea un
servidor, es decir, procesos que ejecuta, direcciones a las que responde y memoria que
usa. Si el servidor cae y no puede desempear estas actividades, otro tiene que ocupar
su lugar.
Hay tres tipos de clusters segn su modo de funcionamiento y gestin.
1 Clusters Activo-Pasivo o asimtricos: Cada grupo de servicio se ejecuta en un
nodo. Existen nodos de reserva en stand-by para ejecutarlos en caso de fallo.
Heartbeat
Definicin III.17 Heartbeat. In computer clusters, heartbeat network is a private network which is shared only by the cluster nodes, and is not accessible from outside the
cluster. It is used by cluster nodes in order to monitor each nodes status and communi-
93
cate with each other. -- Wikipedia.4

Es uno de los puntos crticos de un cluster de alta disponibilidad. Si falla se producir la
activacin simultnea de ambos nodos, generando conflictos y cada del servicio.
Puede implementarse como una red de rea local o mediante la escritura en una seccin
reservada de disco compartido.
Para aumentar la fiabilidad del heartbeat se pueden tomar diversas medidas:
Eliminar SPOF en los mecanismos de transporte del heartbeat.
Emplear dos heartbeat (dos redes o red+disco). Actuar slo en caso de fallo
de ambos.
Emplear redes independientes lo ms simples posibles: cable cruzado para
dos nodos, o segmentos de LAN con switches independientes.
Vigilar el correcto funcionamiento de los procesos que generan y atienden
los hearbeats en cada nodo. Instalar un watchdog local que los rearranque
en caso de cada.
Existe una serie de problemas a la hora de rearrancar en el servidor secundario
en el caso de fallo de uno de los nodos.
Si el cambio en la direccin IP se realiza sobre un adaptador con otra direccin
MAC, la cach ARP de los clientes mantendr la antigua hasta que detecten la
nueva situacin. Por ello se asume tambin la antigua direccin MAC.
Cuando la parada es no planificada (se dio un fallo en el sistema) se perdern
datos de las aplicaciones, las cachs de disco y/o transacciones que se estuvieran
realizando. Es por ello que el arranque de servicios en el servidor de reserva se
hace siguiente los procedimientos de arranque tras un cierre anormal:
Revisin de la consistencia de los sistemas de archivos a nivel de sistema
operativo.
Revisin de la consistencia de los datos en disco a nivel de aplicacin (por
ejemplo, bases de datos).
Rollback de las transacciones activas en el momento del fallo.
En caso del fail-back este proceso ser planificado, realizndose un cierre
ordenado. En ambos casos se interrumpir el servicio.
2 Clusters Activo-Pasivo cruzados o simtricos: Cada grupo de servicio se ejecuta
en un nodo. Todos los nodos ejecutan grupos de servicio. En caso de fallo de un
nodo, el resto se hacen cargo de la ejecucin de sus grupos de servicio.
El modelo es similar al anterior, pero con grupos de servicios activos en ambos
nodos. Cada nodo tiene direcciones de servicio fijas y, en caso de fallo, el resto de
nodos deber hacerse cargo de todas las direcciones.
En este modelo nunca se parar el sistema y, si no hay fallo, hay menos capacidad
de proceso desaprovechada.
Por otro lado, este modelo tiende a sobrecargar los nodos y, debido a la carga de
trabajo de los supervivientes tras un fallo, es posible que les cueste absorber la
carga del nodo cado. Adems, es imposible asignar dos o ms direcciones MAC
en el adaptador de un nodo de modo que los clientes del nodo cado debern
realizar un nuevo ARP para conectar con otro nodo.
4
http://en.wikipedia.org/wiki/Heartbeat_network
94
3 Clusters Activo-Activo: Cada grupo de servicio se ejecuta en mltiples nodos. El

fallo de uno de los nodos no supone la cada del grupo de servicio.
En este modelo existe un mecanismo de balanceo de carga para asignar las
peticiones de los clientes a alguno de los nodos activos, que realiza el reparto
de la carga y la verificacin de la actividad.
Si falla uno nodo no cae el grupo de servicio e incluso, dependiendo del tipo de
aplicacin, las conexiones activas en el momento del fallo pueden mantenerse
tambin.
El cluster debe incluir soluciones para el acceso compartido a discos en lectura y
escritura, creacin de reas de memoria compartida entre los nodos del cluster,
consistencia de la informacin distribuida entre los distintos nodos, etc.
Ejemplo: Ya vimos en el tema 2 la arquitectura de un servidor de aplicaciones J2EE,
que es la que muestra la siguiente imagen:
Se trata de un cluster Activo-Activo.

El balanceo de carga entre servidores Web lo realiza el Edge Server y el balanceo de carga
entre Servlet Engines lo realiza el Web Plug In.
La alta disponibilidad en el acceso a los contenedores EJB y a los servicios de Back End es
proporcionada por IIOP (corba) y por mecanismos de clustering respectivamente.
La continuidad de la sesin entre distintas Servlet Engines se obtiene mediante el
mantenimiento comn de los datos de sesin. Este soporte comn se puede conseguirse
mediante una tabla de sesiones en una BD compartida, un gestor de rplica centralizado
(Redundado para evitar SPOF) o un gestor de rplica distribuido.
III.5.
Recuperacin ante desastres
Un desastre es cualquier circunstancia que puede producir un fallo en la operativa del

negocio de una empresa. Pueden ser naturales, humanos, accidentes ...
Aunque tengan poca probabilidad, el impacto puede ser muy alto (por ejemplo, si se
queman tus servidores de datos). Para garantizar la recuperacin ante un desastre no
95
basta con las tcnicas de alta disponibilidad vistas hasta ahora sino que son necesarias
nuevas tcnicas que se presentan en esta seccin.
Veamos algunas definiciones necesarias para entender los conceptos que analizaremos
en este apartado:
Recovery
Point
Objective
(RPO)
Definicin III.18 Recovery Point Objective (RPO). Instante de tiempo al que se es capaz de
recuperar la informacin existente en el sistema tras un fallo. Si no es 0, habr perdida de datos
Recovery Time Objective (RTO)
Definicin III.19 Recovery Time Objective (RTO). Tiempo que se tarda en recuperar los
sistemas tras producirse un fallo. Si no es 0, habr interrupciones de servicio.
Menores valores de RTO y RPO requieren mayor coste por lo que hay que analizar bien
las necesidades del servicio.
Hay unas reglas bsicas en el diseo de arquitecturas tolerantes a desastres:
a. Proteger datos y nodos de proceso mediante distribucin geogrfica.
Cuanto ms alejados se encuentren, mayor seguridad, pero mayor complejidad y
coste.
b. Proporcionar a los CPDs redundancia en el suministro de energa. Preferiblemente con acometidas independientes, a travs de rutas alternativas de distribucin y
proporcionadas por distintas entidades suministradoras.
c. Proporcionar a los CPDs redundancia en el acceso de telecomunicaciones. Con las
mismas consideraciones que en el caso anterior.
d. Generar copias consistentes de la informacin, garantizando la capacidad de
recuperar los datos desde ellas.
Copias off-line: backups en cinta. Proporcionan un RPO elevado.
Puesto que hay que hacerlos de forma consistente, debe detenerse las
aplicaciones mientras se realiza el backup o emplear tcnicas de copia
instantnea.
Adems debe probarse que la informacin se restaura correctamente.
Copias on-line: rplicas directas de disco a disco. Proporcionan un RPO
reducido.
Los mecanismos ms habituales, ordenados de menor a mayor fiabilidad
son:
a) Scripts de usuario. Automatizados por planificador.
b) Rplicas basadas en software en los sistemas de proceso, a distintos
niveles:
c) Rplicas basadas en nivel de driver: mirroring remoto.
d) Rplicas basadas en el hardware de los servidores de disco: sncronas y
asncronas, estudiadas previamente.
96
III.5.1.
Arquitecturas de CPDs orientadas a la recuperacin ante desastres
Clusters a nivel de campus

Los elementos del cluster se distribuyen entre dos edificios prximos.
Extensin de LAN y SAN entre ambos edificios, normalmente con cableado
propio.
Es posible la copia sncrona de informacin entre servidores de disco.
El funcionamiento lgico es como un cluster local: Proporciona alta disponibilidad.
Protege frente a desastres que ocurran en un nico edificio.
Clusters metropolitanos
Similar al anterior, pero con edificios en ubicaciones distantes que no excedan el
rango en el que es posible realizar copia sncrona de la informacin.
Extensin de LAN y SAN con enlaces alquilados de alta velocidad (fibra oscura,
WDM).
Protege frente a desastres locales.
Clusters continentales
Sin lmite de distancia entre centros.
Requieren conexin a travs de red WAN.
Protege frente a desastres en reas extensas (regin o estado), segn la distancia
entre centros.
97
Soluciones mixtas
Cluster local o metropolitano para garantizar alta disponibilidad, aadiendo un
cluster continental para garantizar recuperacin ante desastres.
III.5.2.
Resumen de tipos de clusters
En resumen, en este tema se han visto 4 tipos de clusters:

High performance cluster : III.7
Load balancer : III.15
Cluster orientado a la recuperacin ante desastres : III.5.1
Cluster tolerante a fallos : III.5
98
III.6.
Problemas
Ejercicio 3.1: Se dispone de un equipo con un MTTF de 500 horas, que se encuentra bajo
un contrato de mantenimiento que garantiza su reparacin en un tiempo medio de 10 horas.
a) El proveedor nos ofrece sustituirlo por un equipo de mayor calidad, con un MTTF de
1000 horas. Calcular la mejora de disponibilidad que supone este cambio.
b) Tras un tiempo trabajando con el nuevo equipo, el proveedor nos ofrece de nuevo un
nuevo equipo de mucha mayor calidad, con un MTTF de 2000 horas. Calcular la mejora de
disponibilidad que supondra el nuevo cambio respecto al segundo equipo.
A PARTADO A )
Calculemos la disponibilidad de cada equipo:
A1 =
500
50
=
0.98039
500 + 10
51
100
1000
=
0.990099
1000 + 10
101
Luego la mejora es inferior al 1 %.
A2 =
A PARTADO B )
2000
200
=
0.995
2000 + 10
201
Lo que supone una mejora inferior al 0.5 % respecto al segundo y un 1.5 % respecto al
original.
A3 =
Ejercicio 3.2:
por ao.
Se desea prestar un servicio con una indisponibilidad menor de 10 horas
a) Calcular la disponibilidad deseada del sistema.

b) Se dispone de un servicio de mantenimiento que es capaz de sustituir un equipo averiado
en 24 h. Calcular el MTTF que debe tener el equipo para poder satisfacer el requerimiento
de disponibilidad establecido.
c) Si slo se dispone de equipos con un MTTF de 2000 horas, calcular el nmero de equipos
que se deberan colocar en paralelo para garantizar el requisito.
A PARTADO A )
Calculemos la disponibilidad:
A>
365 24 10
= A > 0.99886
365 24
99
A PARTADO B )
Con un MTTR = 24h, podemos despejar el MTTF necesario utilizando la A calculada
en el apartado anterior:
MTTF
MTTF (1 0.99886) = 24 0.99886
MTTF + 24
24 0.99886
MTTF =
21028.6316 horas ( 2.5 aos)
1 0.99886
0.99886 =
A PARTADO C )
Calculemos la disponibilidad de un nico equipo
Ae =
2000
0.98814
2000 + 24
Ahora calculemos el nmero de equipos utilizando la frmula para componentes

redundantes:
0.99886 1 (1 0.98814)n
(1 0.98814)n 1 0.99886
n log(1 0.98814) log(1 0.99886)
n 1.52
Como buscamos el mnimo n tal que cumpla esa desigualdad y n N = n = 2.
Ejercicio 3.3: El servidor de envo de mensajes ("busca") descrito en el problema nmero

7 del Tema 2 (2.7) se compone de dos dispositivos: uno de recepcin de mensajes y otro de
difusin de los mismos.
El MTTF del dispositivo de recepcin de mensajes es de 1000 horas.
El MTTF del dispositivo de difusin es de 1500 horas.
Ambos los atiende el mismo servicio tcnico, que en ambos casos nos asegura un MTTR de
5 horas.
Se pide calcular la disponibilidad total del sistema.
Como son 2 elementos en serie, la disponibilidad total es el producto de las

1000
1500
disponibilidades. Como Areceptor = 1000+5
y Adifusor = 1500+5
, tenemos que
Atotal =
1500 1000
0.9917
1505 1005
100
Ejercicio 3.4: Los datos de disponibilidad de cada uno de los componentes de la red de la
entidad financiera descrita en el problema nmero 8 del Tema 2 (2.8) son los siguientes:
MTTF del multiplexor: 2000 h.
MTTF del servidor: 2000 h.
MTTF de cada terminal remoto: 1000 h.
MTTF de la lnea de comunicaciones del terminal remoto: 500 horas.
MTTR de todos los elementos: 5 horas.
Suponiendo la existencia de dos nicos terminales remotos, realizar el diagrama de bloques
de disponibilidad y calcular la disponibilidad global del sistema.
Aqu hay que interpretar un poco el problema5 , lo que yo entiendo es un esquema como
el de la figura III.1.
Figura III.1: Esquema.

Siguiendo este esquema, hay que calcular la disponibilidad de cada cliente en serie con
su canal, luego calcular la disponibilidad en paralelo de los clientes, y luego calcular la
disponibilidad de los clientes, el multiplexor y el servidor en serie. Vamos a ello:
De un par cliente-canal:
A1 =
1000
500
20000
=
0.9852
1000 + 5 500 + 5
20301
De los clientes:
AClientes = 1 (1 0.9852)2 0.9998
Del multiplexor y el servidor:6
AMUL =
2000
2000
=
0.9975
2000 + 5
2005
De la red:
Juntndolo todo obtenemos lo siguiente:
A = 0.9998 0.9975 0.9975 0.9948
5
6
se aceptan crticas.
que tienen el mismo MTTF.
101
Ejercicio 3.5: Un servidor de fecha y hora de una red se compone de dos elementos, que
deben estar operativos para atender el servicio: Un ordenador, que satisface las peticiones,
y un receptor de seales horarias externo, que permite obtener la hora exacta. Si ambos
equipos tienen un MTTF de 1500 horas, calcular el MTTR mnimo que debemos considerar,
supuesto igual en ambos, si se desea una disponibilidad total del servicio mayor del 99 %.
Como son componentes en serie, la disponibilidad es el producto:

A=
1500
1500
> 0.99
1500 + MTTR 1500 + MTTR
15002 > 0.99 (1500 + MTTR)2
15002
15002 102
=
> 15002 + 3000 MTTR + MTTR2
0.99
99

100
2
+ 3000 MTTR + MTTR2
0 > 1500 1
99
Primero resolvemos la ecuacin de segundo grado:

q
3000 30002 4 1 15002 (1
MTTR =
2
100
99 )
3000 3015.1134
2
Como el resultado de MTTR = 3007.5567 horas es absurdo, MTTR = 7.5567 horas es

el nico resultado que tiene sentido.
Como lo que queremos resolver es la inecuacin, el resultado es MTTR < 7.5567.
Ejercicio 3.6: Un servicio que debe tener una disponibilidad mnima de 0.99 se debe
proporcionar con un sistema cuyo tiempo medio hasta el fallo es de 2000 horas.
a) Calcular el tiempo medio para reparar el equipo que es necesario para satisfacer la
disponibilidad solicitada.
b) Al comenzar con la explotacin del servicio se descubre que el programa que lo
implementa tiene fallos que hacen que en ocasiones se bloquee, dejando de atender peticiones.
Para resolverlo es necesario detener el proceso y volverlo a arrancar. Se ha estimado que en
media se produce un fallo cada dos das. El fallo se tarda en descubrir un promedio de 5 min.
y la reiniciacin del proceso requiere, tambin en promedio, 7 min. Calcular la disponibilidad
del sistema considerando este efecto.
c) Suponiendo imposible modificar el programa o cambiar el equipo, proponer una
alternativa que permita, en las nuevas circunstancias, satisfacer el requerimiento inicial
de disponibilidad.
A PARTADO A )
102
A=
2000
2000
> 0.99
2000 > MTTR 20.20 > MTTR
2000 + MTTR
0.99
Luego tomando el MTTR ms grande posible, M T T R = 20.202 horas es suficiente.7

A PARTADO B )
Con estos datos, decimos que M T BFprograma = 48 horas (2880 min), M T T Rprograma =
5 + 7 = 12 min
2880 12
Aprograma =
0.99583
2880
Luego:
Atotal = 0.99 0.99583 0.98587
Y descubrimos, con estupor, que no cumplimos el contrato.
A PARTADO C )
Debido a que tenemos el deber de cumplirlo, nos embarcamos en la bsqueda de una
solucin. Primero, consideramos poner elementos en paralelo, pero como no podemos
cambiar el programa para solucionar sus fallos ni aadirle funcionalidad para que se
pueda repartir la carga entre varios, no podemos llevar a cabo esta solucin. En segundo lugar, se nos ocurre aumentar el tiempo medio hasta el fallo, pero el sysadmin nos
amenaza con cortarnos las gnadas si le tocamos su sistema, y la empresa que proporciona el programa tampoco es capaz de solucionarnos el problema resolviendo los bugs.
No desesperando en nuestro empeo, perseveramos, y observamos que, desembolsando algunos euros ms, podemos contratar un becario para mejorar la disponibilidad
reduciendo el MTTR. Albricias! -pensamos, pero, cunto debemos reducirlo?
Tras esta bonita historia, vamos a resolver el problema:
Observamos que hay dos MTTRs que podemos mejorar, pero el del programa ya es
bastante bajo en comparacin con el del sistema (12 min frente a 20.20 horas)8 , luego es
evidente que mejorando el del sistema podemos cumplir con el contrato:
0.99 = 0.99583
2000
0.99585 2000
MTTR =
2000 11.81 horas
2000 + MTTR
0.99
Y, tomando un MTTR = 11.818 horas para el sistema, comprobamos que la nueva

disponibilidad es:
A=
2000
0.99583 0.99... > 0.99
2000 + 11.818
Y nos vamos felices, sabiendo que hemos hecho un buen trabajo.
Ejercicio 3.7: Una peticin que se procesa en un servidor web tiene que pasar por cuatro
clases de elementos distintos para su resolucin completa. Estos elementos son:
7
8
Aadidle todos los 020s que queris detrs.

obsrvese que la disponibilidad no tiene unidades.
103
Un distribuidor de carga, que reparte las peticiones a los servidores web.

Un servidor web, que entrega al cliente pginas estticas e imgenes. Existen en
el sistema tres servidores web, de igual funcionalidad, pudiendo cualquiera de ellos
atender las peticiones.
Un servidor de aplicaciones, que ejecuta programas bajo peticin de los servidores
web. El sistema posee dos de estos servidores, de igual funcionalidad. Los servidores
web pueden enviar indistintamente sus peticiones a cualquiera de ellos.
Un servidor de base de datos, al cual acceden los programas que se ejecutan en los
servidores de aplicaciones para recuperar los datos que necesitan para realizar las
peticiones.
Es necesario, por tanto, que est disponible al menos un elemento de cada una de las clases
citadas anteriormente para que el sistema completo funcione.
a) Dibujar el diagrama de disponibilidad del sistema total definido.
b) Suponiendo que todos los ordenadores que implementan los servidores tienen la misma
disponibilidad, A, y que cada servidor se implementa en un ordenador distinto, calcular la
expresin de la disponibilidad total del sistema, AT en funcin de A.
c) Calcular el valor numrico de AT cuando el tiempo medio entre fallos es de 2000 horas y
el tiempo medio entre reparaciones, 100 horas.
Hecho por Edu. Se ruegan correcciones.

A PARTADO A )
El esquema es el mostrado en la figura III.2.
Figura III.2: Esquema de cadena de procesamiento.

A PARTADO B )
104
Aplicando la misma idea que en la transparencia 17:

AT = A (1 (1 A)3 ) (1 (1 A)2 ) A = A7 + 5 A6 9 A5 + 6 A4
sage
A PARTADO C )
Hecho por Carolina.
Sabemos que
el tiempo medio entre fallos (MTBF) es 2000 horas,
el MTTR es de 100 horas.
Como MTTF = MTBF - MTTR:
MTTF
2000 100
19
=
=
MTBF
2000
20
1152167961
0.9001
AT =
1280000000
A=
sage
105
Ejercicio 3.8:
Cada uno de los elementos que componen el servidor de transacciones
descrito en el problema nmero 15 del Tema 2 (2.15) se ejecuta en un ordenador
independiente que tiene un MTTF de 4000 horas. Calcular el MTTR necesario para
garantizar una disponibilidad del sistema total del 99.9 %.
Tenemos:
Aproceso = ADB =
4000
4000 + MTTR
Debido a que hay un bucle, hay que tener en cuenta cuntas vueltas se dan para calcular
la disponibilidad total media:
Si se da una vuelta: AT = A con probabilidad (1 q)
Si se dan dos vueltas: AT = A3 con probabilidad q(1 q)
Si se dan tres vueltas: AT = A5 con probabilidad q 2 (1 q)
etc.
Luego
E (AT ) =
A2n1 q n1 (1 q)
n=1
Utilicemos el truco de la suma geomtrica:

S = A(1 q) + A3 q(1 q) + A5 q 2 (1 q) + ...
A2 q S = A3 q(1 q) + A5 q 2 (1 q) + A4 q 7 (1 q) + ...
(1 A2 q)S = A(1 q)
Por lo tanto, la disponibilidad total promedio es
E (AT ) =
A(1 q)
1 A2 q
Como queremos que AT 0.999

A(1 q)
1 A2 q
0.999(1 A2 q) = A(1 q)
1000
A2 q + A(1 q)
1=0
999
0.999 =
106
Resolviendo con sage el polinomio de segundo grado obtenemos:9

p
500 q 500 250000 q 2 + 498001 q + 250000
A=
999 q
p
500 q 500 + 250000 q 2 + 498001 q + 250000
A=
999 q
2000000 q 4000 p
1996000
MTTR =
250000 q 2 + 498001 q + 250000

999
999
999
2000000 q 4000 p
1996000
MTTR =
250000 q 2 + 498001 q + 250000
+
999
999
999
Quedndonos con la solucin positiva, tenemos que 0 MTTR
de q.
4000
999
horas, en funcin
Ejercicio 3.9:
Comparar desde el punto de vista de disponibilidad las dos soluciones
propuestas en el problema nmero 18 del Tema 2 (2.18) para resolver un cuello de botella en
acceso a disco. Suponer que todos los discos empleados tienen los mismos MTTF y MTTR,
y justifique qu alternativa es ms fiable calculando y comparando las disponibilidades en
ambos casos.

Por recordar, tenemos las dos soluciones siguientes para resolver un cuello de botella
en el acceso a disco:
a. Comprar un disco con tiempo de acceso menor, pero ms caro. En este caso, se
encolan las peticiones cuando el disco se encuentre ocupado.
b. Poner dos discos en espejo (mirroring) que tendrn un tiempo de acceso mayor
que el anterior, pero ms baratos. En este caso, se accede indistintamente a
cualquiera de los dos discos cuando se produce una peticin, dependiendo de
cul est libre, encolndose todas las peticiones en una cola comn.
As visto, el ejercicio es bastante absurdo, por decirlo de alguna forma. Por un lado,
si los discos son distintos no deberan tener la misma fiabilidad, pero bueno. Por otro,
est claro que si ponemos dos discos en espejo (esto es, a efectos de disponibilidad, en
paralelo) tendrn ms disponibilidad. En cualquier caso, vamos a hacer los clculos.
Tenemos por un lado la disponibilidad de la solucin a, dada por
Aa =
MTTF
MTTR + MTTF
La disponibilidad de la solucin b se basa en usar dos discos con la misma

disponibilidad individual Aa , as que aplicamos la frmula de sistemas en paralelo para
saber la disponibilidad del conjunto:
Ab = 1 (1 Aa )2 = 1 1 A2a + 2Aa = Aa (2 Aa )
9
este monstruo
107
Como sabemos que Aa < 1, tenemos que 2Aa > 1 y por lo tanto Ab = Aa (2Aa ) > Aa ,
as que, tal y como habamos dicho al principio, la solucin con dos discos en paralelo
es mejor.
Ejercicio 3.10: Los servidores de directorios DSA1 y DSA2 descritos en el problema

nmero 20 del Tema 2 (2.20) se encuentran conectados por una lnea de comunicaciones
que tiene una disponibilidad de 0.99. La disponibilidad de DSA2 es de 0.98. Si el MTTF
de DSA1 es de 2000 horas, cul ser el MTTR que deberemos garantizar para l, para
conseguir que la disponibilidad del sistema total sea igual a 0.95? Cul sera, en este caso,
la disponibilidad de DSA considerado aislado del resto del sistema?

El problema en cuestin nos deca que tenemos un servidor de directorio DSA1, que en
el 25 % de los casos redirige las peticiones al servidor DSA2. Lo del 25 % es importante,
ya que tenemos una parte que slo se va a usar en una de cada cuatro peticiones, y
tendremos que tener eso en cuenta para calcular la disponibilidad.
Empezamos calculando la disponibilidad del sistema superior, que consta del DSA2
y de la lnea de comunicaciones. Son dos componentes en serie, luego As = 0.99 0.98 =
0.9702. Cmo afecta esto a la disponibilidad del sistema total? Haciendo un clculo de
probabilidades, nos debera quedar algo como esto:
A = 0.75 A1 + 0.25 A1 As
Es una media ponderada entre las dos disponibilidades posibles: en un 75 % de los
casos slo nos importa el DSA1, mientras que en el 25 % restante (cuando DSA1 pide
datos al servidor superior) nos importa que funcione DSA1 y adems la lnea de
comunicacin y DSA2.
Ahora hacemos la ecuacin para hallar la disponibilidad necesaria de DSA1
0.95 = A1 (0.75 + 0.25 0.9702) = A1 0.9571
y adems resolvemos para sacar el MTTR:
0.9571 =
2000
= MTTR = 89.579 horas
2000 + MTTR
Ejercicio 3.11: Se desea definir la arquitectura de un servidor de aplicaciones siguiendo

el modelo estndar visto en la asignatura, compuesto por cuatro elementos distintos en la
cadena de procesamiento:
Capa de distribucin: Balanceador de carga del trfico de usuarios. La alta
disponibilidad de estos elementos se garantizar mediante el protocolo VRRP.
Capa de presentacin: Servidores web. La capa anterior garantiza una alta
disponibilidad activo-activo en esta capa.
108
Capa de aplicacin: Servidores de aplicaciones. El web plug-in insertado en los

servidores web garantiza la alta disponibilidad activo-activo en esta capa.
Capa de datos: Servidores de bases de datos. Se elige que la alta disponibilidad de esta
capa la proporcione un cluster activo-pasivo.
Los ordenadores con los que se trabaja tienen un MTTF de 4000 horas, y su MTTR es de 48
horas.
a) Calcular la disponibilidad de la capa de presentacin si se colocan en ella dos servidores
web.
b) Adicionalmente a los posibles problemas de hardware reflejados en el MTTF genrico
de los servidores empleados, se han detectado fallos en el software de los servidores de
aplicaciones, que hacen que en promedio exista un fallo por semana que hace necesario
rearrancar el servidor. El tiempo de rearranque del servidor es de 30 min. Calcular la
disponibilidad de la capa de aplicacin si se colocan en ella dos servidores de aplicaciones.
c) En el caso de la base de datos, la recuperacin tras un fallo no se realiza a travs de
las reparaciones habituales, sino que se dispone de un cluster activo-pasivo. El tiempo de
conmutacin al servidor pasivo se compone de los siguientes tiempos:
Tiempo de deteccin del fallo en el servidor principal: 30s.
Tiempo de arranque del servidor pasivo: 30 min.
Tiempo de recuperacin de la base de datos tras un cierre anormal, en el caso peor: 2
horas.
Calcular la disponibilidad de la capa de datos en dicho caso peor.
d) En la capa de distribucin se conocen los siguientes datos:
Advertisement interval (tiempo entre la transmisin de paquetes hello por el
balanceador activo): 1s.
Master down interval (tiempo tras el cual si no se reciben paquetes hello se considera
el master cado): 3s.
Skew adicional para producir la conmutacin tras la expiracin del master down
interval: 0.
Calcular, en el caso peor, la disponibilidad del conjunto de dos balanceadores de carga
trabajando en esta configuracin.
e) Calcular la disponibilidad total de la instalacin.

A PARTADO A )
109
La disponibilidad de un equipo es
Ae =
MTTF
4000
=
0.9881
MTTF + MTTR
4048
, luego si ponemos dos equipos en paralelo para la capa de presentacin tenemos que
Apres = 1 (1 Ae )2 0.9998
A PARTADO B )
Seguro que los fallos son por usar Glassfish.
La disponibilidad del software del servidor de aplicaciones ser
Asof t =
24 7
0.9970
24 7 + 0.5
, luego la nueva disponibilidad total de cada servidor ser

Aeapp = Asof t Ae = 0.9851
Poniendo dos en paralelo, tendremos una disponibilidad para la capa de aplicacin de
Aapp = 1 (1 Aeapp )2 0.9997
A PARTADO C )
Aqu seguimos teniendo el MTTF de 4000 horas, aunque el MTTR cambia al usar un
cluster. El MTTR en este caso es la suma de todos los tiempos que nos dicen, luego
MTTR = 2.5083 horas. Por lo tanto, la disponibilidad ser
ADB =
4000
MTTF
=
0.9993
MTTF + MTTR
4002.5083
A PARTADO D )
De nuevo tenemos que recalcular el MTTR, sumando bsicamente. MTTR = 0.0011
horas. Por lo tanto, la disponibilidad ser
Adist =
MTTF
4000
=
0.9999
MTTF + MTTR
4000.0011
A PARTADO E )
Simplemente hacemos el producto de todo:
A = Adist Apres Aapp ADB 0.9999 0.9998 0.9997 0.9993 = 0.9987
110
ndice alfabtico
APIs directas, 4
Apollo RPC, 8
Balanceador de carga, 90
Clusters
de alta disponibilidad, 81
de alto rendimiento, 81
CO, 80
Coeficiente
cuadrtico de variacin, 46
Continuous
Operation, 80
CORBA, 18
DAP, 22
DCE, 20
DCOM, 18, 20
DDE, 20
Disponibilidad, 79
DSA, 22
DSP, 22
DUA, 22
Elasticidad, 80
EtherChannels, 89
Factor
de utilizacin, 45
Fail-back, 86
Fail-over, 86
Fiabilidad, 80
Flash Copy, 92
funcin de tasa de fallo, 82
HA, 79
Heartbeat, 93
High
Availability, 79
IBM Sphere MQ, 14
IDL, 19
Intensidad
de trfico, 45
LDAP, 23
Mantenibilidad, 80
Marshalling, 7
Microsoft COM, 19
Middleware, 3
MIDL, 20
MOM, 14
MSMQ, 20
MTS, 20
Nmero medio
de clientes en cola, 45
de clientes en el sistema, 45
namespaces, 21
NDR, 9
Network Operating System, 3
NIDL, 9
NTLMP, 20
NTP, 24
OASIS, 9
OLE, 20
OMA, 18
OMG, 18
operaciones de RPC idempotentes, 7
ORB, 18
OSPF, 89
PortMapper, 7
Recovery
Point Objective, 96
Time Objective, 96
Recuperacin
ante desastres, 81
Red
de colas abiertas, 47
Reliability, 80
Resiliencia, 80
Resiliency, 80
REST, 12
RM-ODP, 3
111
RPO, 96
RTO, 96
SAM, 20
SCM, 20
Serviceability, 80
Single Point Of Failure, SPOF, 86
Sistemas
tolerantes a fallos, 80
SOAP, 10
Stub, 6
Sun RPC, 8
Tasa
de llegadas, 45
de servicio, 45
Teorema
de Burke, 47
de Jackson, 47
de Little, 45
Tiempo medio
de reparacin/recuperacin, 81
entre fallos, 81
hasta el fallo, 81
timer ticks, 23
tolerancia mnima de reloj, 25
UDDI, 11
Unmarhsalling, 7
URI, 13
UTC, 23
VRRP, 89
WADL, 13
WSDL, 11
WSRL, 9
X.500, 22
XDR, 8
XDS, 22
112

Sistemas Informáticos 2

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sistemas Informáticos 2

Caricato da

Copyright:

Formati disponibili

Sistemas Informticos II

Pedro Valero, Vctor de Juan, Eduardo Miravalls

III Aspectos operacionales de los sistemas distribuidos: Disponibilidad

Documento compilado el 14 de junio de 2016 a las 13:23

III.4.4 Redundancia de las WAN . . . . . . . . . . . . . . . . . . . . . . .

Pedro Valero, Vctor de Juan, Eduardo Miravalls

Definicin I.1 Middleware. Conjunto de aplicaciones encargadas de enlazar los componentes

Network Operating System (NOS)

SSO: Single Sign On - Un nico usuario y contrasea para todo el sistema.

Son la leche porque proporcionan mucha transparencia: podemos comunicarnos entre

Aunque ya deberamos saberlo, incluimos un par de esquemas (sacados de las

Figura I.1: Comunicacin orientada a conexin.

Figura I.2: Comunicacin No Orientada a conexin.

Modelos de servicios distribuidos

RPC - Remote Procedure Calls

Este modelo se basa en realizar llamadas a funciones como si fueran locales, as el

Para el funcionamiento de RPCs necesitamos unos componentes intermedios llamados

Figura I.3: Funcionamiento de una llamada RPC.

Tras un Time Out No se sabe si la llamada se ha ejecutado o no. Para intentar

Ejecucin Al menos una vez.

Es necesaria una representacin de datos compartida por los stubs.

Figura I.4: Compilacin y generacin de cdigo para Sun RPC.

Algunas diferencias entre RPCs

Parmetros: Aunque en general soporten mltiples parmetros (Apollo RPC por

Comentamos que Apollo RPC tiene su propio lenguaje de representacin de datos,

Web Services (SOAP-WSDL-UDDI)

Es un modelo de uso de la Web. La idea es tener servidores que ofrecen servicios

Complementos de los Web Services OASIS (Organization for the Advancement of

WSRL - Web Services Resource Framework.

Figura I.5: Componentes de un WS para su funcionamiento.

Body (obligatoria): Contiene la informacin relativa a la llamada y la respuesta.

Estructura de una declaracin WSDL

Pginas blancas. Direccin, contacto y otros identificadores conocidos.

Definicin I.7 REST. Si bien el trmino REST se refera originalmente a un conjunto de

Al trabajar con REST se considera que el sistema se compone de recursos, es decir,

Figura I.6: API de OneDrive utilizando REST.

Comuncacin mediante colas de mensajes

Definicin I.8 MOM. Message Oriented Middleware.

Observacin: Permite balanceo automtico de carga en un sistema distribuido. Se

IBM Web Sphere MQ

Es el MOM ms extendido. Es multiplataforma y multiprotocolo.

IBM Sphere MQ est formado por

Figura I.7: Sistema de mensajera de colas.

Ejemplo: Una de las utilidades de MOM son los servicios de publicacin/suscripcin. A

Figura I.8: Sistema publicador/suscriptor.

Services Oriented Architecture SOA

ESB - Enterprise Services Bus

Extendiendo el modelo de publicador/suscriptor tenemos un ESB. El ESB acta

Figura I.9: Enterprise Service Bus.

RMI - Remote Method Invocation

Igual que en programacin estructurada podamos ejecutar funciones remotamente

Figura I.10: Esquema de funcionamiento de RMI.

El otro componente que merece mencin es el mdulo de la referencia remota. El objeto

Definicin I.9 OMA. Object Management Architecture.

Figura I.11: Esquema de funcionamiento del modelo de referencias de OMA.

Object Request Broker, ORB: Bus de comunicacin entre objetos.

Es un middleware avanzado que es la repera y permite :

Enlace directo de aplicaciones escritas en mltiples lenguajes de alto nivel (no

Definicin I.11 IDL. Interface description language.

Figura I.12: Esquema del desarrollo de CORBA.

Los stubs de servidor se llaman skeletons

Esta plataforma de objetos ha ido mejorandose y evolucionando a lo largo del

Definicin I.13 MTS. Microsoft Transaction Server

Definicin I.14 MSMQ. Microsoft Message Queueing