Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Computación de Altas Prestaciones - Módulo 4 - Introducción A La Computación Distribuida
Computación de Altas Prestaciones - Módulo 4 - Introducción A La Computación Distribuida
la computación
distribuida
Ivan Rodero Castro
Francesc Guim Bernat
PID_00191921
CC-BY-NC-ND • PID_00191921 Introducción a la computación distribuida
Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de
Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 España de Creative Commons. Podéis copiarlos, distribuirlos
y transmitirlos públicamente siempre que citéis el autor y la fuente (FUOC. Fundación para la Universitat Oberta de Catalunya),
no hagáis de ellos un uso comercial y ni obra derivada. La licencia completa se puede consultar en http://creativecommons.org/
licenses/by-nc-nd/3.0/es/legalcode.es
CC-BY-NC-ND • PID_00191921 Introducción a la computación distribuida
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 6
2. Computación en parrilla................................................................. 28
2.1. Introducción a la computación en parrilla ................................. 28
2.2. Concepto de organización virtual .............................................. 30
2.3. El middleware................................................................................. 31
2.3.1. Gestión de la ejecución ................................................. 34
2.3.2. Gestión de los datos ...................................................... 34
2.3.3. Servicios de información ............................................... 34
2.3.4. Seguridad ........................................................................ 34
2.4. Meta-scheduling.............................................................................. 35
2.5. Estandarización ........................................................................... 39
2.6. Computación en parrilla frente a supercomputación ................. 40
3. Computación en nube....................................................................... 42
3.1. Introducción a la computación en nube .................................... 42
3.2. Características de la computación en nube ................................ 46
3.3. Tipos de nubes ............................................................................ 49
3.3.1. Nubes públicas ............................................................... 49
3.3.2. Nubes privadas ............................................................... 50
3.3.3. Nubes de comunidad ..................................................... 51
3.3.4. Nubes híbridas ............................................................... 52
CC-BY-NC-ND • PID_00191921 Introducción a la computación distribuida
Bibliografía................................................................................................. 69
CC-BY-NC-ND • PID_00191921 5 Introducción a la computación distribuida
Introducción
Una vez estudiadas las tecnologías básicas para sistemas distribuidos, nos cen-
traremos en la computación en parrilla (grid computing), que se desarrolla a
partir de tecnologías de sistemas distribuidos como las vistas en el primer mó-
dulo. En concreto, estudiaremos las características de los sistemas de compu-
tación en parrilla y posteriormente utilizaremos un ejemplo de middleware y
otro de metaplanificación (meta-scheduling) para ilustrar las funcionalidades
más significativas de estos entornos.
Objetivos
Los principales objetivos que alcanzaréis con el estudio de este módulo son
los siguientes:
(1)
Lo más habitual es que el sistema operativo integre los servicios de red que En inglés, distributed shared me-
mory.
ofrecen protocolos abiertos de comunicación, como TCP y UDP. Sobre estos se
disponen los soportes adicionales para la comunicación distribuida, como es
el caso de RPC, RMI o DSM1, y los servicios específicos que proporcionan las
propiedades del sistema distribuido (servicios de middleware), como es el caso
de la gestión de tiempo, eventos y estado global, sobre los que se fundamentan
las aplicaciones.
Actividad
Buscad información sobre DSM y pensad las similitudes y las limitaciones respecto a otros
modelos de memoria distribuida.
• Compartición de recursos.
• Apertura.
• Concurrencia.
• Escalabilidad.
• Tolerancia a fallos.
• Transparencia.
CC-BY-NC-ND • PID_00191921 9 Introducción a la computación distribuida
1.1.2. Apertura
1.1.3. Concurrencia
Cuando hay varios procesos en una única máquina decimos que se están
ejecutando� concurrentemente. Si el computador está equipado con
un único procesador central, la concurrencia tiene lugar entrelazando
la ejecución de los diferentes procesos. Si el computador tiene N pro-
cesadores, entonces se pueden estar ejecutando estrictamente a la vez
hasta N procesos.
En los sistemas distribuidos hay muchas máquinas, cada una con uno o más
procesadores centrales. Es decir, si hay M ordenadores en un sistema distribui-
do con un procesador central cada una, entonces hasta M procesos pueden
estar ejecutándose en paralelo.
CC-BY-NC-ND • PID_00191921 11 Introducción a la computación distribuida
1.1.4. Escalabilidad
Esto significa que si la demanda de un recurso crece, debería ser posible ex-
tender el sistema para dar servicio. Por ejemplo, la frecuencia con la que se
accede a los ficheros aumenta cuando se incrementa el número de usuarios
y estaciones de trabajo en un sistema distribuido. Entonces, ha de ser posible
añadir servidores para evitar el cuello de botella que se produciría si un solo
servidor de ficheros tuviera que gestionar todas las peticiones de acceso a los
ficheros. En este caso, el sistema debe estar diseñado de manera que permita
trabajar con ficheros replicados en diferentes servidores, con las consideracio-
nes de consistencias que esto supone.
1.1.6. Transparencia
interfaz de red local, etc. Estos recursos clave son gestionados separadamente
por un sistema operativo en cada computador; solo podrían ser compartidos
entre procesos localizados en el mismo computador.
1.2.1. Middleware
El middleware define la interfaz que usan los clientes para pedir un servicio a
un servidor, la transmisión física de la petición mediante la red y la devolución
de resultados desde el servidor al cliente. Algunos ejemplos de middleware es-
tándar para dominios específicos son: ODBC para bases de datos, HTTP y SSL
para Internet, y CORBA y RMI para objetos distribuidos.
(2)
El mecanismo de llamada a procedimiento remoto (RPC)2 trata de eliminar Del inglés remote procedure call.
(3)
De este modo, el procedimiento especificado se ejecuta en otro proceso de otra Del inglés interface description
language.
máquina (servidor). El objetivo de RPC es mantener la semántica de la llama-
da a procedimientos normales en un entorno de implementación totalmente
diferente. La ventaja está en que el desarrollador solo debe preocuparse de las
interfaces que soporta el servidor. Para especificar estas interfaces se dispone
de un lenguaje de definición de interfaces (IDL)3.
(4)
1) Procesamiento relacionado con las interfaces: integrar RPC en el entorno En inglés, marshalling.
4 5
de programación, empaquetamiento /desempaquetamiento y atender las pe-
(5)
ticiones al procedimiento adecuado. En inglés, unmarshalling.
(6)
En inglés, binding.
2) Gestionar las comunicaciones.
(7)
Una implementación bastante habitual de RPC es la de SUN. Esta incorpora Del inglés external data represen-
tatio.
un conjunto de primitivas para trabajar con RPC en lenguaje C. Dispone de
una representación neutral de los datos (XDR)7 para su empaquetamiento.
1) A partir del nombre del servicio remoto, el cliente localiza el servidor que
soporta el servicio.
CC-BY-NC-ND • PID_00191921 18 Introducción a la computación distribuida
(8)
2) Se empaquetan los argumentos en un formato estándar (por ejemplo, En inglés, marshaling.
8
XDR20) para formar el cuerpo de un mensaje, es decir, se serializan .
11) El sistema operativo del nodo del cliente desbloquea a este en la recepción
del resultado.
(9)
La invocación de métodos remotos (RMI)9 corresponde al modelo de progra- Del inglés remote method invoca-
tion.
mación orientada a objetos, al contrario de las RPC, que pertenecen al modelo
de programación procedimental. Primero veremos los conceptos relacionados
con la invocación de métodos del modelo de objetos, centrándonos después
en el modelo de objetos distribuidos.
Algunos objetos solo pueden recibir invocaciones locales, mientras que otros,
los objetos remotos, pueden recibir tanto invocaciones locales como remotas.
Para invocar un método de un objeto remoto, un objeto debe tener acceso a
la referencia de objeto remoto del receptor, que es un identificador único en
el sistema distribuido
Cada objeto remoto tiene una interfaz remota que especifica cuáles de sus mé-
todos se pueden invocar remotamente. Estos métodos estarán implementados
por la clase del objeto remoto. En Java RMI, las interfaces remotas se definen
como toda interfaz de Java, sin más que ampliar la interfaz “Remote”. CORBA
proporciona un lenguaje de definición de interfaces (CORBA IDL), que permi-
te que las clases de los objetos remotos y los programas clientes estén progra-
CC-BY-NC-ND • PID_00191921 20 Introducción a la computación distribuida
Java RMI amplía el modelo de objetos de Java para soportar objetos distribui-
dos de un modo integrado en el lenguaje, haciendo la invocación de métodos
remotos transparente, excepto por el hecho de que el cliente deba tratar las
excepciones remotas y el servidor definir como “Remote” la interfaz del objeto
remoto.
En una aplicación distribuida en Java RMI, hay que definir las interfaces re-
motas e implementar los objetos remotos y los clientes. Una vez compilados
los ficheros fuente, la aplicación se organiza de la siguiente manera:
Primero se define la interfaz que declara el método remoto, que tiene dos números como
argumentos y devuelve la suma.
import java.rmi.*;
import java.rmi.*;
import java.rmi.server.*;
El siguiente código se encarga de hacer que los objetos estén disponibles para nodos
remotos, es decir, que actualiza el registro RMI (mediante “rebind”).
import java.net.*;
import java.rmi.*;
Finalmente, hay que implementar un programa cliente que será el encargado de utilizar
la interfaz remota y acabar llamando al método del objeto remoto. Este cliente tiene tres
argumentos: la dirección IP, o el nombre del servidor remoto, y los dos números que se
han de sumar.
import java.rmi.*;
public class AddClient {
public static void main(String args[]) {
try {
String addServerURL = "rmi://" + args[0] + "/AddServer";
AddServerIntf addServerIntf =
(AddServerIntf)Naming.lookup(addServerURL);
System.out.println("The first number is: " + args[1]);
double d1 = Double.valueOf(args[1]).doubleValue();
System.out.println("The second number is: " + args[2]);
double d2 = Double.valueOf(args[2]).doubleValue();
System.out.println("The sum is: " + addServerIntf.add(d1, d2));
}
catch(Exception e) {
System.out.println("Exception: " + e);
}
}
}
(10)
El concepto de servicio web10 ha evolucionado desde su definición inicial. Los En inglés, web service.
inicios de los servicios web los podemos encontrar en los sistemas distribuidos,
(11)
con CORBA y DCOM, pero ninguno de los dos sistemas acabó generalizándo- Del inglés simple access protocol.
(13)
Entre las distintas organizaciones que se encargan de velar por los estándares De World Wide Web Consor-
13 14 tium.
y arquitectura web destacan el WWWC (W3C ) y OASIS .
(14)
De The Organization for the
El W3C define los servicios web del siguiente modo: Advancement of Structured Infor-
mation Standards.
“Un servicio web es un sistema de software diseñado para dar soporte a la interacción
interoperable de máquina a máquina en una red. Tiene una interfaz descrita en un for-
mato procesable por máquina, específicamente WSDL. Otros sistemas interactúan con el
servicio web de una manera prescrita por su descripción, usando mensajes SOAP, típica-
mente transmitido a través de HTTP con una serialización XML en conjunción con otras
normas relacionadas con la web”.
En un intento de estandarización global, el W3C propone su visión de los Web services protocol stack
servicios web, especificando la web services protocol stack (figura 3), que es un
Es un conjunto de protocolos
conjunto de protocolos para servicios web. A pesar del peso y la importancia y estándares para redes (Inter-
del W3C como organismo de estandarización en los servicios web, entre otras net, intranet, etc.) utilizados
para definir, localizar, imple-
tecnologías, es cierto que muchos fabricantes proponen pequeños cambios a mentar y hacer que un servicio
web interactúe con otros.
esta especificación.
CC-BY-NC-ND • PID_00191921 23 Introducción a la computación distribuida
(15)
La mensajeríaXML consiste en un lenguaje de marcas ampliable. Es un están- En inglés, parsed.
dar para describir datos y crear etiquetas. Las características especiales son la
(16)
independencia de datos y la separación de los contenidos de su representa- En inglés, unparsed.
(17)
El WSDL17 es un lenguaje de descripción de servicios web. Es una especifica- Del inglés web service descrip-
tion language.
ción XML para la construcción del documento de descripción del servicio web.
Cuando decimos que es una especificación XML significa que el documento
WSDL está escrito en XML.
El fichero WSDL identifica los métodos, las funciones y los parámetros nece-
sarios para invocar un determinado servicio y describe información crítica que
el cliente del servicio web necesita conocer, como:
(18)
• El nombre del servicio, incluyendo su URN18. Del inglés uniform resource na-
me.
• La localización del servidor, normalmente una dirección URL19 por HTTP. (19)
Del inglés uniform resource loca-
tion.
<definitions name="HelloService"
targetNamespace="http://www.examples.com/wsdl/HelloService.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<message name="SayHelloRequest">
<part name="firstName" type="xsd:string"/>
</message>
<message name="SayHelloResponse">
<part name="greeting" type="xsd:string"/>
</message>
<portType name="Hello_PortType">
CC-BY-NC-ND • PID_00191921 25 Introducción a la computación distribuida
<operation name="sayHello">
<input message="tns:SayHelloRequest"/>
<output message="tns:SayHelloResponse"/>
</operation>
</portType>
<service name="Hello_Service">
<documentation>WSDL File for HelloService</documentation>
<port binding="tns:Hello_Binding" name="Hello_Port">
<soap:address
location="http://www.examples.com/SayHello/">
</port>
</service>
</definitions>
(20)
UDDI20 es un elemento fundamental en el que se apoyan los servicios web. Del inglés universal description
discovery and integration.
Este estándar ofrece la posibilidad de que los proveedores/clientes de servicios
puedan publicar y encontrar otros servicios web de terceros. UDDI tiene un
mecanismo para que los proveedores de servicios se describan a sí mismos y
los diferentes servicios que proporcionan, permitiendo que se puedan registrar
y publicar en un registro UDDI. Estos servicios publicados pueden ser busca-
dos, consultados o descubiertos por otros usando mensajes SOAP. La figura 5
muestra el funcionamiento de UDDI.
CC-BY-NC-ND • PID_00191921 26 Introducción a la computación distribuida
Ejemplo
En los documentos XML siguientes se muestran una petición y una respuesta SOAP, res-
pectivamente.
Petición�SOAP
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
Respuesta�SOAP
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>
</soap:Envelope>
CC-BY-NC-ND • PID_00191921 28 Introducción a la computación distribuida
2. Computación en parrilla
(21)
En este apartado se introducen los conceptos más fundamentales de la compu- En inglés, grid computing.
21
tación en parrilla . Utilizaremos algunas soluciones concretas para ejempli-
ficar las características de las funcionalidades de la computación en parrilla.
Por último, discutiremos los aspectos fundamentales que diferencian los sis-
temas clásicos de altas prestaciones de la computación en parrilla. Se espera
que complementéis los contenidos de este apartado con investigación propia
a partir de información y lecturas que se os proporcionarán durante el curso.
(22)
De este modo, la idea esencial de la computación en parrilla es la de compartir En inglés, power grid.
recursos entre diferentes grupos de investigación y, en general, entre diferen-
(23)
tes instituciones u organizaciones. En la computación en parrilla, los recursos En inglés, utility computing.
A pesar de las distancias físicas a las que se pueden encontrar las diferentes
máquinas que componen la parrilla, el poder de unificación y el modo de re-
lación dinámica de estas máquinas consiguen responder a todas las demandas
de los diferentes usuarios de la red. Dicho esto, se puede ver que las peticiones
de los usuarios se distribuyen en diferentes tareas para diferentes equipos que
forman la parrilla, de modo que el usuario simplemente ve los datos finales
como un solo cómputo.
(24)
Hay que tener en cuenta que el origen de la computación en parrilla está ínti- Del inglés large hadron collider.
mamente ligado a la compartición de recursos entre la comunidad científica,
que requiere altas prestaciones para resolver problemas complejos. Un ejem-
plo claro de ello es el desarrollo de la computación en parrilla durante la últi-
ma década para poder dar soporte al LHC24 en el CERN de Ginebra. Parte del
reto técnico-científico es poder almacenar y procesar los datos generados en
un tiempo razonable y lograr realizar descubrimientos científicos de dominios
concretos, como la física de partículas.
Los recursos de la parrilla no son dedicados, dado que son recursos ya existen-
tes en la institución y posiblemente se usen para uso personal o institucional
(por ejemplo, un grupo de investigación de la universidad) a la hora de formar
parte de la parrilla. Así pues, la cantidad de recursos que están disponibles para
la parrilla varía en función de la utilización local. Esto hace imprescindible
incorporar una monitorización constante a los recursos y políticas de repla-
nificación con capacidad para variar el conjunto de recursos asignados a una
tarea en tiempo de ejecución.
CC-BY-NC-ND • PID_00191921 30 Introducción a la computación distribuida
Lectura complementaria
Foster (2001) introdujo el concepto de organización�virtual (VO). De-
fine la organización virtual como “una colección dinámica de múltiples I.�Foster;�C.�Kesselman;
S.�Tuecke (2001). “The
organizaciones, que proporcionan flexibilidad y el intercambio seguro Anatomy of the Grid,
Enabling Scalable Virtual Or-
y coordinado de recursos”.
ganizations”. International
Journal of High Performance
Computing Applications (vol.
15, núm. 3).
La figura 6 muestra tres organizaciones reales con recursos tanto computacio-
nales como de datos para compartir a través de las fronteras organizacionales.
Por otro lado, la figura forma dos organizaciones virtuales, A y B, y cada una
de ellas puede tener acceso a un subconjunto de los recursos en cada una de
las organizaciones. La virtualización es un mecanismo que mejora la utilidad
de los sistemas de computación en parrilla, proporcionando a los usuarios la
posibilidad de configurar su entorno.
Hay que tener en cuenta que para poder implementar múltiples organizacio-
nes virtuales por encima de organizaciones físicas, hay que utilizar mecanis-
mos de seguridad y gestión de usuarios, tal y como veremos más adelante. Aun
así, el concepto de organización virtual coincide claramente con el espíritu
colaborativo con el que se inició el desarrollo de la computación en parrilla.
CC-BY-NC-ND • PID_00191921 31 Introducción a la computación distribuida
2.3. El middleware
El middleware de los recursos de una parrilla también tiene por objetivo realizar
otras tareas, como la replicación de los datos y los metadatos, que requerirán
que los nodos ejecuten una cierta tarea por cuestiones de eficiencia o toleran-
cia a fallos. Para simplificar este tipo de tareas se definieron una serie de pro-
tocolos especializados en redes en parrilla, como el GridFTP, que veremos con
detalle más adelante.
CC-BY-NC-ND • PID_00191921 32 Introducción a la computación distribuida
Actividad
(25)
La Globus Alliance es el nombre de un esfuerzo internacional entre diferentes En inglés, loosely coupled.
instituciones e individuos cuyos objetivos son la investigación y el desarrollo
de tecnologías y estándares para la computación en parrilla. Una de sus tareas
principales es la construcción del Globus Toolkit, un conjunto de soluciones
para problemas típicos de la computación en parrilla, como mantener la segu-
ridad en entornos distribuidos y heterogéneos, gestión de recursos, monitori-
zación, solución de fallos y gestión de datos, entre otros, que permiten cons-
truir middleware para cubrir las necesidades de gestión de la parrilla. El desa-
rrollo del Globus Toolkit ha tenido desde el principio un enfoque de software
libre y construcción descentralizada, así como una clara preferencia para la
adopción de estándares. También hay que destacar el uso de servicios web a
nivel de interfaz entre módulos, basada en mecanismos XML, consiguiendo
un sistema distribuido poco acoplado25.
(26)
El principal servicio ofrecido por el Globus Toolkit en materia de gestión de la Del inglés grid resource alloca-
26 tion and management.
ejecución es el servicio de gestión y reparto de recursos de la parrilla (GRAM) ,
que proporciona una interfaz para enviar, monitorizar y cancelar tareas. De es-
Lectura complementaria
te modo, terceras partes pueden basarse en estas implementaciones, por ejem-
plo para construir planificadores de tareas. Podéis encontrar mucha más
información sobre la arqui-
tectura interna de este módu-
2.3.2. Gestión de los datos lo en el documento “Globus
Toolkit 4.0 WS GRAM Ap-
proach”.
Dentro del mundo de la computación en parrilla, la transferencia de datos es
un problema fundamental, pues nos encontramos con conjuntos de nodos
computacionales repartidos por localizaciones geográficas muy dispersas. Ade-
más, ciertos tipos de aplicaciones necesitan un uso intensivo de datos, como
es el caso del LHC construido en el CERN.
(27)
El Globus Toolkit ofrece distintas piezas de software que dan solución a algu- En inglés, replica location servi-
ce.
nos de los problemas relacionados con la transferencia y el acceso a grandes
cantidades de datos. Por un lado, la implementación de la especificación Grid- (28)
En inglés, reliable file transfer.
FTP proporciona herramientas para hacer transferencias seguras y de alto ren-
dimiento de memoria a memoria o disco a disco, y además tiene compatibili-
dad con clientes y servidores FTP tradicionales. El servicio de replicación de
ubicaciones27 proporciona un servicio descentralizado para mantener infor-
mación sobre la ubicación de conjuntos de datos y ficheros repartidos por la
red. Otra solución, como el servicio de transferencia fiable de ficheros28, pro-
porciona una nueva capa sobre el GridFTP que permite hacer transferencias
múltiples y fiables de ficheros a gran escala.
2.3.4. Seguridad
2.4. Meta-scheduling
Actividad
Actividad
2) La política waiting-time policy tiene por objetivo evitar que las tareas con una
menor prioridad nunca pasen a ejecutarse para que otras de mayor prioridad
monopolicen los recursos continuamente (problema de asignación de recursos
compartidos conocido en el mundo de la computación como inanición). Lo
que hace es incrementar linealmente la prioridad de las tareas a medida que
pasa el tiempo mientras espera a ser ejecutada.
CC-BY-NC-ND • PID_00191921 39 Introducción a la computación distribuida
(29)
3) Los límites temporales de ejecución29 se pueden marcar gracias a la política En inglés, deadlines.
Actividad
2.5. Estandarización
Las principales normas que han sido producidas por la OGF son, entre muchas
otras:
• Single API for Grid Applications (SAGA): es una especificación de alto nivel
para aplicaciones en red que describe una interfaz de programación de
aplicaciones en parrilla.
Por otro lado, los nodos de un clúster se encuentran altamente acoplados, si-
tuados en el mismo dominio de red y habitualmente conectados con interfa-
ces de red de altas prestaciones. Además, los nodos son dedicados y, por lo
tanto, ejecutan únicamente las aplicaciones del clúster. En estas condiciones
(conexiones rápidas, nodos dedicados, alto acoplamiento) lo más habitual es
utilizar MPI para programar aplicaciones. De este modo, los clústeres son idea-
les para ejecutar aplicaciones subdivididas en muchos problemas pequeños y
con gran cantidad de comunicación entre procesos, las aplicaciones paralelas
de grano fino.
CC-BY-NC-ND • PID_00191921 41 Introducción a la computación distribuida
3. Computación en nube
(30)
La computación en nube30 se presenta como la materialización más cercana a En inglés, cloud computing.
Este modelo en nube está compuesto por cinco características esenciales, tres
modelos de servicio y cuatro modelos de despliegue.
La definición del NIST también incluye tres modelos de servicio (SaaS, PaaS,
IaaS) y cuatro modelos de despliegue o tipo de nubes (privado, de comunidad,
público, híbrido), que veremos más adelante.
Desde el punto de vista del hardware existen tres aspectos nuevos en la compu-
tación en nube:
CC-BY-NC-ND • PID_00191921 44 Introducción a la computación distribuida
La elasticidad de los recursos es una de las claves, dado que permite que los
usuarios puedan adaptar los recursos utilizados (y por los que pagan) bajo de-
manda, ya sea porque la utilización de los servicios tiene fluctuaciones perió-
dicas (por ejemplo, más clientes durante el día que durante la noche), ya sea a
causa de caídas inesperadas de la demanda por acontecimientos externos (por
ejemplo, los casos de noticias), tal y como ilustra la figura 11.
Debemos tener en cuenta que adquirir nuevos equipos puede requerir sema-
nas y el único modo de soportar estos picos en la demanda es el suministro
anticipado. Esto provoca que, si no se dispone de los recursos para soportar
los picos de demanda, se pierda capacidad, tal como muestra la figura 12a.
También puede suceder que se infravalore el pico de demanda (figura 12b) y
no se disponga de suficientes recursos para dar servicio a los clientes. Mien-
tras que los efectos monetarios de exceso de aprovisionamiento son fáciles de
medir, los de falta de aprovisionamiento son más difíciles de medir pero po-
tencialmente igual de graves: no solo se rechazan usuarios, por lo que no se
generará ningún ingreso, sino que muchos usuarios se perderán para siempre
a causa de un mal servicio. La figura 12c tiene como objetivo captar este com-
portamiento: los usuarios abandonan un servicio que está saturado hasta que
la carga pico es igual a la capacidad de uso del centro de datos, en el que los
usuarios reciben de nuevo un punto de servicio aceptable, pero con un menor
número de usuarios potenciales.
• Coste: el modelo de pago por uso permite a las compañías reducir los cos-
tes fijos y las inversiones en tecnologías de la información, además de
aprovechar al máximo su dinero, ya que pueden pagar exactamente por
lo que necesitan. El precio de este tipo de servicios es competitivo gracias
a la explotación de las economías de escala.
• Las actualizaciones del software no hay que hacerlas en las máquinas físi-
cas, sino que se hacen automáticamente en la nube. De este modo no se
pierde tiempo en actualizaciones.
• Los datos sensibles no son locales, lo que podría infringir parte de la ley
de protección de datos, dado que exponen los datos a la posibilidad de
robo de información.
• La fiabilidad del servicio recae sobre la tecnología que utilizan los provee-
dores. Muchas veces el cliente no sabe qué sistemas son los que dan servi-
cio y no sabe si podrían ser mejores por el mismo precio.
Existen diferentes tipos de nubes (o modelos de despliegue) que hay que deta-
llar porque cada uno tiene unas características diferentes, lo que provoca que
unos se ajusten mejor que otros según el tipo de cliente o empresa.
Estas nubes siguen siendo entidades únicas pero interconectadas entre sí, lo
que permite disfrutar de las ventajas de los diferentes tipos de nubes:
Normalmente las nubes híbridas suelen intentar explotar primero los recursos
propios (para evitar pagar por uso) y solo cuando el usuario no tiene suficiente
capacidad con los recursos locales, utiliza la nube pública (por ejemplo, como
extensión o forma de aceleración). Este tipo de técnica se suele denominar
cloud bursting.
(32)
Del inglés infrastructure as a ser-
32
En el modelo o capa de infraestructura como servicio (IaaS) , el provee- vice.
(33)
Del inglés platform as a service.
33
En el modelo o capa de plataforma como servicio (PaaS) , el servicio va
un paso más allá del de infraestructura como servicio y, en este modelo,
el cliente recibe la plataforma entera (sistema operativo, base de datos,
servidor de aplicaciones, lenguaje de programación, entre otras) como
servicio.
En este tipo de servicio el cliente solo se debe preocupar de gestionar las apli-
caciones que quiere emplear en la plataforma y no es necesario que gestione
conceptos relacionados con la gestión ni el mantenimiento de la plataforma
o de la infraestructura.
CC-BY-NC-ND • PID_00191921 54 Introducción a la computación distribuida
(34)
Del inglés software as a service.
34
El modelo o capa de software como servicio (SaaS) es el modelo prefe-
riblemente recomendado para un cliente final y consiste en la adquisi-
ción del servicio a más alto nivel, que corresponde al nivel de aplicación.
Tal y como se muestra en la figura 16, cada uno de los modelos o capas necesita
a su predecesor para poder ofrecer este servicio. Así pues, si un proveedor quie-
re ofrecer un software como servicio (SaaS), debe disponer de una plataforma
como servicio (PaaS), o en otro caso debe contratar este servicio a un tercero.
Lo mismo con la capa de infraestructura como servicio, que es el modelo de
menor nivel. Este hecho provoca que las vulnerabilidades y los agujeros de
seguridad de los modelos de computación en nube deban dividirse según su
modelo y se gestionen según este, ya sean el proveedor o el cliente los encar-
gados de hacerlo. En este sentido, como clientes la ventaja de disponer de un
servicio de más alto nivel (SaaS) ofrece la desventaja de no poder controlar la
gestión de la seguridad de este y a la inversa. Por ejemplo, si disponemos de un
software como servicio (SaaS), perdemos el control de la gestión del sistema
operativo, actualizaciones, requisitos de acceso a los datos y privacidad, entre
otros. Mientras que si disponemos de un servicio de infraestructura, seremos
nosotros mismos quienes deberemos gestionar toda la seguridad tanto a nivel
de sistema operativo como de aplicaciones y software.
(35)
• Red como servicio (NaaS)35. Del inglés network as a service.
(36)
• Del inglés storage as a service.
Almacenamiento como servicio (STaaS)36.
(37)
• Datos como servicio (DaaS)37. Del inglés data as a service.
(38)
• Del inglés test environment as a
Entorno de pruebas como servicio (TeaaS)38. service.
También existen otros más especializados, como los relacionados con la segu-
ridad, la monitorización de múltiples aspectos, etc.
CC-BY-NC-ND • PID_00191921 55 Introducción a la computación distribuida
Actividad
(39)
1)�Adaptarse�a�las�variaciones�estacionales�de�carga: Las empresas, depen- En inglés, outsorcing.
diendo de su sector o sistema de funcionamiento, como el caso de empresas
que solo trabajan durante ciertos periodos del año o tienen picos importantes
de trabajo, necesitan tecnologías de la información muy variadas y difíciles
de planificar. Este caso de uso es muy importante, dado que utilizar una nube
pública permite redimensionar la capacidad de los sistemas de tecnologías de
la información para adaptarse a las variaciones de carga o a la necesidad de
nuevos servicios. La capacidad de la nube para este caso de uso viene dada
39
gracias a la virtualización y a la subcontratación . La virtualización permite
aumentar o disminuir los recursos de hardware o servicios contratados por
cada compañía de manera ágil, gracias a que esta proporciona independencia
del hardware real.
2)� Cambio� en� el� sistema� de� financiación: Otro caso de uso popular de la
computación en nube es aprovecharlo para pasar de un sistema de financia-
ción consistente en comprar activos fijos para conseguir realizar las tareas de
tecnologías de la información necesarias, a pagar por servicios. De este modo
se obtienen varios beneficios:
3)�Externalización�de�las�tecnologías�de�la�información: La externalización
de los servicios de tecnologías de la información ofrece una gran cantidad de
ventajas a pesar de que no está exenta de algunos inconvenientes, por eso al-
gunas empresas optan por soluciones de nube privada o híbrida. Las principa-
les ventajas de la externalización son:
12)�Sistema�de�tecnologías�de�la�información�compartido�con�empresas
con�intereses�similares: Las nubes compartidas presentadas en el subapartado
anterior también suponen un motivo importante para decantarse por la nube,
dado que conjuntos de empresas con intereses comunes pueden compartir la
nube. Esto permite crear una nube más específica que una pública, dado que se
puede invertir en crear una que se ajuste lo máximo posible a las necesidades
del conjunto. Al compartir la nube, también facilita la compartición de datos
y una mayor capacidad de cooperación.
CC-BY-NC-ND • PID_00191921 58 Introducción a la computación distribuida
3.6. Virtualización
(40)
Observad que en este subapartado haremos especial énfasis en la virtualiza- Del inglés virtual machine moni-
tor.
ción x86. La figura 17 muestra la estructura básica de un sistema virtualizado.
La capa de virtualización de base es el software que organiza y gestiona dife- (41)
En inglés, guest operating sys-
rentes máquinas virtuales en los monitores de máquinas virtuales (VMM)40. tem.
El hipervisor es el componente encargado de la interacción directamente con
el hardware. Su funcionalidad es diferente para diferentes arquitecturas e im-
plementaciones. Cada VMM se ejecuta en el hipervisor y tiene su propia abs-
tracción de máquina virtual encargada de ejecutar un sistema operativo invi-
tado41. Sus funciones principales son la partición y compartición de los dife-
rentes recursos, como los dispositivos de CPU, memoria, disco y entrada/sa-
lida, de manera que todo el sistema es compartido por multiplexación entre
diferentes máquinas virtuales.
CC-BY-NC-ND • PID_00191921 59 Introducción a la computación distribuida
• Virtualización CPU.
• Virtualización de memoria y dispositivo.
• Virtualización de entrada/salida.
Figura 18
• Menor�consumo�de�energía�e�infraestructura�de�refrigeración. La utili-
zación eficiente de recursos se traduce en un uso óptimo de la energía y
la reducción de sus costes. Disponer de una infraestructura más reducida
nos permite una eficaz refrigeración de los centros de datos con menos
sistemas de aire acondicionado, lo que reduce los costes energéticos.
Para llevar a cabo estas funciones, el VMM ocupa una posición privilegiada
en el sistema a partir de arquitectura basada en capas discutida anteriormente,
cuando se hablaba de paravirtualización.
mente algunas herramientas de Xen que tienen una gran cantidad de funcio-
nalidades dirigidas a controlar/monitorizar el comportamiento de estas má-
quinas virtuales invitadas y del VMM en general.
Sin embargo, también es importante mirar más allá de los beneficios de la ex-
ternalización y comprender las posibles maneras de formular las aplicaciones
y de utilizar los recursos en un entorno híbrido en el que se pueden combinar
sistemas de altas prestaciones tradicionales, sistemas de computación en pa-
rrilla y sitemas de computación en nube.
Hay que tener en cuenta que nos centramos en las nubes de computación pero
la misma discusión también se puede aplicar a las nubes de datos; la idea es
poder soportar datos científicos y de ingeniería y proporcionar el análisis de
datos como servicio.
Entre los posibles modelos que combinan la computación en nube con los
conceptos más tradicionales de la computación de otras prestaciones, pode-
mos encontrar:
CC-BY-NC-ND • PID_00191921 67 Introducción a la computación distribuida
Bibliografía
Armbrust, M.; Fox, A.; Griffith, R.; Joseph, A. D.; Katz, R.; Konwinski, A.; Lee, G.;
Patterson, D.; Rabkin, A.; Stoica, I.; Zaharia, M. (2010). “A view of cloud computing”.
Commun. ACM (núm. 53, vol. 4, pág. 50-58).
Foster, I.; Kesselman, C. (1999). The Grid: Blueprint for a New Computing Infrastructure.
Burlington, Massachusetts: Morgan Kaufmann.
Foster, I.; Kesselman, C.; Tuecke, S. (2001). “The Anatomy of the Grid, Enabling Scalable
Virtual Organizations”. International Journal of High Performance Computing Applications (vol.
15, núm. 3).
Foster, I.; Yong Zhao; Raicu, I.; Lu, S. (2008). “Cloud Computing and Grid Computing
360-Degree Compared. Grid Computing Environments Workshop, 2008”. GCE ‘08 (pág. 1-10
y 12-16).
Fox, G. (2011). “Data Intensive Applications on Clouds”. Keynote at The Second International
Workshop on Data Intensive Computing in the Clouds (DataCloud-SC11) at SC11 November 14.
Fox, G.; Gannon, D. (2012). “Cloud Programming Paradigms for Technical Computing
Applications” (Informe técnico).
Hwang, K,; Dongarra, J.; Fox, G. (2011). Distributed and Cloud Computing. Burlington,
Massachusetts: Morgan Kaufmann.
IBM (2009). “IBM Research Doubles Its Productivity with Cloud Computing”. Case Study
QuickView.
Iosup, A.; Ostermann, S.; Yigitbasi, N.; Prodan, R.; Fahringer, T.; Epema, D. (2011).
“Performance analysis of Cloud computing services for many-tasks scientific computing”.
IEEE TPDS. Los Alamitos, CA.
Iverson, W. (2004). Real World Web Services. Sebastopol, CA: O’Reilly (recurso electrónico).
Mell, P.; Grance, T. (2011). The NIST Definition of Cloud Computing. Recommendations of the
National Institute of Standards and Technology. U.S. Department of Commerce.
Raicu, I.; Zhang, Z.; Wilde, M.; Foster, I.; Beckman, P.; Iskra, K.; Clifford, B. (2008).
“Towards Loosely-Coupled Programming on Petascale Systems”. IEEE/ACM Supercomputing.
Yelick, K. y otros (2011). The Magellan Report on Cloud Computing for Science. U.S. Department
of Energy Office of Advanced Scientific Computing Research (ASCR).