caso de estudio: sistema de distribución de …isis2203/dokuwiki/lib/... · caso de estudio:...

12
Caso de Estudio: Sistema de Distribución de Información Correo Electrónico Universidad de Los Andes PARTE I. Dimensionamiento y Definición de la Infraestructura Tecnológica Asistente Graduado: Víctor Guana ([email protected]).

Upload: dangnguyet

Post on 10-Oct-2018

218 views

Category:

Documents


0 download

TRANSCRIPT

Caso de Estudio:

Sistema de Distribución de Información Correo Electrónico Universidad de Los Andes

PARTE I.

Dimensionamiento y Definición de la Infraestructura Tecnológica

Asistente Graduado: Víctor Guana ([email protected]).

Universidad de Los Andes Departamento de Ingeniería de Sistemas y Computación Infraestructura Computacional ISIS 2203 (C1) Caso 1 Dimensionamiento y Definición de la Infraestructura Tecnológica Preparado por: Asistente Graduado Víctor Guana.

Objetivo:

Realizar la selección y diseño de la infraestructura tecnológica que soporta el sistema de

información de correo electrónico de la Universidad de los Andes. Descripción General: En las organizaciones actuales uno de los principales núcleos de soporte de procesos organizacionales es la comunicación en todo instante y en todo lugar; las tecnologías actuales de la computación “pervasiva” hacen que esto sea realidad y que podamos acceder a los portales de información en línea en todo momento. El correo electrónico forma parte de esta intrincada red de mecanismos de comunicación que día tras día soportan el negocio y las actividades organizacionales de las empresas, esta es tal vez la herramienta más poderosa de comunicación asíncrona con la que se cuenta en la actualidad. En este caso de estudio se analizan los requerimientos y necesidades infraestructurales de un sistema de correo de alta disponibilidad de una organización grande como lo es la Universidad de los Andes, este sistema de información es el encargado de manejar 1.000.000 de correos al día con más de 20.000 usuarios entre profesores, estudiantes y administrativos de las diferentes facultades que hacen uso intensivo de él, razón por la cual se configura como un sistema con requerimientos de infraestructura tecnológica críticos dadas sus responsabilidades organizacionales. Descripción Sistema de Correo Electrónico Universidad de Los Andes La Universidad de Los Andes es una organización con 15.000 estudiantes, cerca de 1147 funcionarios administrativos y 500 profesores que se comunican a diario de forma intensiva por medio del correo electrónico institucional, esta herramienta se ha convertido en el núcleo de muchos de los procesos organizacionales que soportan la operación de la entidad. La caracterización de la información que fluye dentro de la infraestructura que soporta el correo se da de la siguiente manera: a diario intentan ingresar a la infraestructura cerca de 1.000.000 de correos, 90% de los cuales vienen de internet y el 10% restante son emitidos internamente. De los 900.000 correos que vienen de internet, cerca de 870.000 constituyen spam y son filtrados por la infraestructura, los 30.000 restantes son útiles para el receptor.

Ítem Valor

Emails de entrada a la Infraestructura por día 1.000.000

Emails Salientes de la Infraestructura (Uniandes) 100.000

Emails Entrantes Filtrados 870.000

Emails Salientes Filtrados 1000

Emails con Destino Internet desde Uniandes 10%

Emails con Destino Dominio Uniandes desde Uniandes 90%

Tabla 1: Estadísticas sobre los correos que viajan por la infraestructura

Los datos anteriores corresponden a la carga normal de correo en un día cualquiera de la semana. Los fines de semana la carga se reduce en un 30 %.

Los correos con destino a la organización son almacenados en casillas independientes para cada usuario, estas casillas tienen un tamaño flexible cuyo rango aceptable está entre los 0 y 100 MB, luego de esta cantidad de información almacenada cada casilla se expande dinámicamente en forma indefinida hasta que los administradores lo permitan, lo anterior se da según la priorización y rango organizacional que tenga el dueño de la casilla. El peso promedio de un correo electrónico oscila entre los 80 KB y 300 KB, sin embargo los requerimientos organizacionales exigen que se puedan adjuntar archivos hasta de 14 MB, lo anterior se volvió una práctica frecuente en el segmento de estudiantes, ya que transportan sus documentos a través de este medio, al punto que se ha detectado que algunos (cerca del 20% de los estudiantes) usan el sistema como memoria portátil o “Llave de memoria USB”.

Todos los usuarios del servicio de correo tienen acceso a su información a través de dos mecanismos posibles, un cliente de correo “stand alone” o de escritorio (por ejemplo Outlook, Thunderbird, Eudora, entre otros) o un cliente web que en este caso lo provee el administrador del sistema como mecanismo de acceso genérico. El cliente web y los servicios requeridos para mantener este mismo en línea con una alta disponibilidad son unas de las cargas más grandes para toda la infraestructura que soporta la solución. Lo anterior dado que los comportamientos organizacionales revelan que este es el medio de acceso a la información más usado, en su gran mayoría por los estudiantes que representan la parte más significativa de la población. Las estadísticas de los medios de acceso a la información se resumen en la tabla 2.

Tipo de Usuario División de Mecanismos de Acceso

Profesores 90 % Clientes de Escritorio 10% Web Mail

Personal Administrativo 50% Clientes Escritorio 50% Web Mail

Estudiantes 10% Clientes Escritorio 90% Web Mail

Tabla 2: Estadísticas de Tipos de Usuario y Mecanismos de Acceso al Sistema de Correo Electrónico Cada uno de los flujos de información que se involucran en el sistema de correo electrónico y los posibles mecanismos de acceso al mismo se ejemplifican en la figura 2 (siguiente página). La figura 1 muestra cómo se realiza el acceso a la información dentro del sistema, en primera instancia

encontramos el flujo de correo externo desde internet, este flujo corresponde a los emails de entrada que

no corresponden al dominio de la universidad, los cuales se transmiten desde servidores de entidades como

gmail, yahoo, hotmail, otras universidades, centros de investigación, entre otros.

El siguiente flujo de entrada de correos corresponde a los emails que son generados y tienen como destino

el mismo dominio de la universidad (aquellos correos originados por @uniandes.edu.co para sí mismo). Los

dos flujos de información anteriores son atendidos por conjuntos de servicios y entidades infraestructurales

diferentes.

Desde el punto de vista de la interacción con los usuarios, el sistema expone servicios para interactuar desde

clientes web, y clientes de escritorio, estas plataformas de acceso constituyen el “frontend” con el que

tienen contacto los usuarios del sistema, particularmente es aquí donde se encuentra de forma gráfica el

contenido de las casillas de correo correspondientes a cada usuario (bandeja de entrada, envió de mensajes,

entre otros). Esta interacción se configura de dos formas, si el cliente es de escritorio este se comunica

directamente con el servidor de correo correspondiente (POP | IMAP para recibir correo o SMTP para

enviar correo) si el mismo es un cliente web este tendrá que acceder a la información del correo a través de

un servidor Web y una aplicación que le sirven de intermediarias para realizar el mismo proceso.

La información almacenada en el sistema es bastante sensible en algunos casos (correos con parciales, listas

de estudiantes, notas, investigaciones clasificadas, entre otros) de esta forma es necesario contar con todos

los mecanismos de autenticación y autorización de acceso a los datos. Para este propósito existe un

servidor de directorio de usuarios que ofrece la infraestructura para la autenticación y autorización de

permisos, el acceso a dicho directorio es realizado mediante el protocolo LDAP (el servidor de directorio ya

es ofrecido actualmente por la universidad). Por otro lado las transmisiones de información entre los

posibles clientes (web y de escritorio) y los servicios frontales de acceso a la información deben ser

adecuadamente protegidas. El detalle de estos mecanismos de seguridad será evaluado en la segunda parte

del caso.

Figura 1. Esquema General de Flujos y Servicios de Correo Electrónico Uniandes

Requerimientos de Respaldo “Backup”:

Es importante tener en cuenta que la información almacenada en este sistema tiene que estar disponible la

mayoría del tiempo del año, además de esto si algún correo fue enviado o recibido es necesario que este se

preserve por al menos 2 años, en los cuales toda la información del correo electrónico de la universidad

debe estar respaldada con copias de seguridad, dichas copias son de vital importancia para la organización,

ya que es con estas con las que se hacen investigaciones académicas y judiciales de hechos irregulares

presentados. Por obvias razones la generación de los datos de respaldo “backup” tiene que ser realizada en

caliente, lo anterior debido a que el sistema de correo electrónico sólo puede salir de línea por tan solo un

cuarto de día al año, con una disponibilidad que usted deberá determinar en su consultoría en términos de

% de tiempo.

Funcionamiento de un Servicio de Correo Electrónico Genérico:

El funcionamiento de un sistema de correo de una organización se da de la siguiente manera con 5 pasos

(figura 2). En este esquema Bob le envía un correo a Alice, quien pertenece a la organización “a”, mientras

Bob a la “b”.

1. Alice usando su cliente de correo (web o de escritorio) compone un correo para Bob y lo envía al

servidor de envío correo de su organización para que este sea procesado y entregado. Este envío

se realiza por medio del protocolo SMTP. Técnicamente el cliente de correo es llamado MUA (Mail

User Agent).

2. El servidor de envío de correo de la organización “a” extrae el dominio de destino de la

organización “b”, este corresponde a “b.org”, a partir de esta información solicita la información a

los enrutadores de internet para poder comunicarse con el servidor DNS que conoce dónde se

encuentra el servidor de intercambio de correo de la organización destino.

3. El servidor DNS de la organización “b” responde con la dirección calificada del servidor de

intercambio de correos respectivo, esta información se encuentra en los registros MX del servidor

DNS.

4. Con la información del servidor de intercambio de la organización “b”, el servidor de envío de

correo de la organización “a” procede a enviar el correo electrónico para que se almacene en la

casilla del usuario destino en la organización “b”, este envío se realiza por medio del protocolo

SMTP.

5. Bob a través de su MUA (cliente de correo) solicita los correos que han llegado a su casilla y extrae

el contenido del correo enviado por Alice. Esta interacción de recuperación de la información por

parte de los MUA se realiza por medio del servidor de recuperación de correo, usando el protocolo

POP3. La anterior recuperación también pudo haber sido realizado mediante el protocolo IMAP. La

descripción de los protocolos usados se encuentra en la siguiente sección.

Figura 2. Esquema General de Funcionamiento de Correo Electrónico en Internet 1

Modelo Específico de Protocolos en Esquema Planteado:

En la figura 1 planteada anteriormente se mostró el flujo de correos entrantes a la infraestructura, y algunas

de las entidades físicas y lógicas que interactúan con el mismo para su transmisión, operación, y

almacenamiento. A continuación en la figura 3 se presenta el mismo esquema teniendo en cuenta los

protocolos que interactúan con dichas entidades dentro del esquema plantado en la figura 1.

Figura 3. Esquema General de Flujos y Servicios de Correo Electrónico Uniandes con Protocolos de

Comunicación.

1 http://en.wikipedia.org/wiki/E-mail

Los protocolos de comunicación que se involucran en la infraestructura no son parte central del caso, sin

embargo conocer su definición básica puede ayudar a la conceptualización de las transacciones y entidades

del sistema, la siguiente sección hace una introducción a los mismos, y enuncia los RFC (Request for

Comments) que los especifica formalmente, para más información puede dirigirse a estos últimos.

Descripción de Protocolos:

SMTP: El Simple Mail Transfer Protocol es un protocolo de la capa de aplicación (sobre TCP/IP) estándar

para el intercambio y transporte de correos electrónicos establecido a través de los RFC 821, y 5321. Su

utilidad se da tanto en el transporte entre agentes del sistema de correo de forma local, como en el

transporte entre infraestructuras remotas, usualmente este último transporte es llamado intercambio. La

siguiente figura muestra los posibles usos de este protocolo en el transporte de correos electrónicos y los

agentes del sistema que intervienen en el mismo:

Figura 4: Flujos de Comunicación (flechas azules) SMTP 2

En la figura 4 se encuentra en primera instancia el Mail User Agent que envía al servidor de correo

electrónico el correo específico a transportar, este es recibido por el Mail Submission Agent el cual es el

servicio de entrada de correo proveniente desde los MUA, a continuación el mensaje es enviado al Mail

Transfer Agent quien es el encargado de negociar con servidores externos para el intercambio de correos.

Usualmente los dos anteriores agentes son encapsulados en uno solo que coloquialmente es llamado

servidor SMTP.

El transporte sobre internet es de igual forma realizado por medio de SMTP, el recibo del intercambio de

información es realizado por el Mail Exchanger, quien provee los servicios de borde para interconectar una

infraestructura de correo local con otras externas. En última instancia el servidor de intercambio entrega al

Mail Delivery Agent (MDA) el correo entrante para que se almacene en las casillas respectivas y pueda ser

recuperado en futuras ocasiones a través de otros MUA.

POP3: El Post Office Protocol es un protocolo de la capa de aplicación (sobre TCP/IP) estandarizado

mediante el RFC 918 en su primera versión, RFC 937 en su segunda versión, y en su tercera (POP3) en los

RFC 2449 y 1734. Es usado para recuperar desde un servidor de correo, correos electrónicos de forma

remota hasta un MU. En la figura 4 su uso puede ser visto en el flujo de información desde el MDA hasta el

MUA de destino.

2 http://en.wikipedia.org/wiki/File:SMTP-transfer-model.svg

IMAP: El Internet Message Access Protocol es un protocolo de la capa de aplicación (sobre TCP/IP) usado

para la recuperación de correos desde servidores remotos estandarizado mediante el RFC 1064 y 3501. Al

igual que POP este protocolo es usado para recuperar desde los MUA los correos depositados en los

servidores de correo que corresponden a una cuenta o nombre específico. La diferencia con POP radica en

varios aspectos, el primero de ellos es que recupera los correos de forma eficiente y sin colisión, en este

orden de ideas cuando un MUA ha solicitado un correo con ID x, solicitará todos los correos a través de

IMAP con ID > X, en el caso de POP se solicitaría (de haber colisiones de IDs) la lista de correos a mostrar, lo

cual para bandejas de entrada de tamaño considerable requeriría grandes capacidades de procesamiento y

memoria. Desde otro punto de vista IMAP puede suportar modos de operación “always online” el cual

radica en un modo de conexión en donde la comunicación del MUA con el servidor no se da de forma

esporádica, sino que se realiza de forma permanente y continúa. IMAP también habilita la conexión de

múltiples clientes a la misma casilla de correo, entre muchos otros.

LDAP: El Lightweight Directory Access Protocol es un protocolo ubicado en la capa de aplicación (sobre

TCP/IP) formalizado a través del RFC 4510, tiene como último fin el poder consultar un directorio que tiene

atributos organizados de forma jerárquica de una organización en general. La operación más usada en

términos de seguridad es el “Bind” ante el servidor, esta permite la autenticación de un cliente ante un

servidor. El Bind simple realiza consultas en texto plano, donde viaja el campo DN del protocolo el cual

identifica al usuario, y su respectivo password. Como una extensión segura, LDAP puede soportar el acople

de TLS ( o SSL) para el viaje cifrado y seguro de esta información.

A Realizar:

Selección y diseño de la infraestructura:

Su tarea en este caso consiste en seleccionar y diseñar la infraestructura que la dirección de tecnologías de

información (DTI) de la Universidad debe implementar para la implementación de un sistema de correo que

sea capaz de soportar todos los requerimientos enunciados en el caso de estudio. La situación es la

siguiente:

En este primer caso la Universidad desea proveer a sus estudiantes, personal administrativo, y profesores,

de un sistema de correo electrónico con alta disponibilidad, altamente fiable, y seguro, con el fin de que este

sea el núcleo de las comunicaciones diarias en la organización. Se tiene planeado que en tan solo seis meses

la infraestructura pueda ser desplegada y los sistemas de información instalados para que estén a

disposición de la organización. Su trabajo consiste en jugar el rol de consultor en primera instancia para

diseñar la infraestructura computacional que es requerida para esta tarea. Hay que tener en cuenta que las

cifras de crecimiento de la población organizacional son de un 10% anual, por lo que es especialmente

necesario que el sistema escale a largo plazo.

Usted deberá seleccionar y diseñar la infraestructura para responder a las necesidades que se han

identificado y otras, que usted deberá deducir en su consultoría.

Tareas: A. Entendimiento del Problema: 1. Describa las transacciones que el sistema recibe y expone, caracterícelas de acuerdo con su: posible

duración, acceso a archivos persistentes, datos manejados, peso en coste de procesamiento y de operaciones de entrada/salida, e interconexión con otros sistemas internos y externos.

2. A partir de la información dada más arriba defina los requerimientos técnicos generales que puede inferir de la infraestructura en términos de: - Número y tipo de transacciones totales y en los períodos pico que deben ser procesadas. Tenga en

cuenta que la universidad está activa el 95% del año y que sus estudiantes pueden acceder al

sistema desde cualquier parte del mundo.

- Requerimientos de tolerancia a fallas de las transacciones.

- Para cada tipo grande de datos, volumen e índice de crecimiento, sensibilidad, requerimientos de

seguridad, requerimientos legales, requerimientos con respecto a los backups.

- Requerimientos de interoperabilidad.

- Requerimientos de la plataforma con respecto a crecimiento horizontal, facilidad de

administración, facilidad de actualización en caliente, disponibilidad, tolerancia a fallas,

conveniencia de implantación rápida.

- Otros aspectos que considere conveniente tener en cuenta.

B. Selección de la Infraestructura Nota: Antes de contestar la siguiente pregunta es recomendable que consulte sitios en donde se especifican configuraciones típicas de sistemas de correo como el portal de Gartner, los sitios de casos de estudio de IBM, Dell, Microsoft, HP, Cray entre otros. Esto le permitirá tener una idea de las configuraciones típicas de este tipo de sistemas. 3. Suponiendo que la arquitectura que usted identifica para implementar es el montaje de un centro de datos (“Data Center”) que deberá administrar la Dirección de Tecnologías de Información DTI la Universidad (de acuerdo con las transacciones especificadas los requerimientos especificados en el punto 1) : - Defina la arquitectura de la infraestructura requerida para satisfacer las necesidades definidas en el punto anterior. Para ello debe definir cuántos servidores se requieren, qué papel (recibir las solicitudes, filtrar el spam, manejar el correo, manejar de los datos,..) desempeña cada uno y cómo se interconectan entre sí. - Defina igualmente el nivel de disponibilidad y tolerancia a fallas que debe cumplir cada servidor y justifique se elección. - Defina cómo dentro de esta infraestructura se despliegan los sistemas de información que soportan a nivel de software el servicio de correo electrónico. - Defina la tecnología de almacenamiento que se requiere ( ATA, RAID, NAS, SAN,….) y justifique su decisión. Si dentro de las definiciones anteriores usted considera que es necesario contar con un cluster de servidores, especifique: qué tipo de cluster (activo o pasivo) se requiere y para qué propósitos (disponibilidad, tolerancia a fallas, alto desempeño, etc. ).

4) Con base en el análisis realizado en la sección 2 describa la configuración de las máquinas, realice un diagrama que especifique cómo se interconectan cada una de ellas, la responsabilidad de estas (para este fin use la notación UML 2.0 para diagramas de despliegue). Adicionalmente modele el flujo de transacciones sobre la topología planteada ¿por dónde entran las transacciones a la topología, por dónde salen? Omita la caracterización de redes y sistemas de interconexión (sin embargo modele los flujos de comunicación entre entidades infraestructurales). Justifique sus decisiones de diseño.

- De cada máquina investigue en el mercado existente y dimensione:

Ítem Sub Ítems.

Procesador: El cálculo de estos ítems tiene que ser apalancado por la disponibilidad de hardware existente por vendedores, y un análisis de mercado

- Rango de Núcleos (de 1 a 2, de 2 a 4, de 4 a 8, 8 a 16) - Velocidad

Memoria RAM: - Tamaño, Tipo y Velocidad.

Dispositivos de Almacenamiento (HDD): - Tipo de almacenamiento requerido ( ATA, Raid, NAS, SAN )

- Tamaño

- Velocidad

- Tenga en cuenta los requerimientos de “Backup”, especifique

los mecanismos y tipos.

Compatibilidad: - Con Hardware y Software Legado y Futuros.

- (Tecnologías de partes específicas de cada componente).

Recuerde que cada uno de los ítems mencionados debe ser acorde con las necesidades expresadas y la

contextualización del caso. Por ejemplo, el tipo de procesador debe ser acorde con el tipo de transacciones

de las cuales es responsable cada máquina (¿son largas, cortas, concurrentes, acceden al disco, a memoria?).

La idea no es diseñar la máquina más poderosa del mercado sino, por el contrario, escalar sus dimensiones

para que cumpla una relación costo/beneficio óptima.

Siempre especifique la razón de su decisión, una alternativa diferente a la que usted planteó, y un análisis

del por qué escogió la planteada y no la otra que identificó viable (modele casos extremos p.e. por qué

elegir un procesador de 1 núcleo en vez de uno de 8).

5. Haga un estimativo del costo de la infraestructura (sólo servidores) requerida basándose en una

investigación del mercado de proveedores actual, para lo anterior acuda a los portales, centros de servicio

en línea y telefónicos de fabricantes y vendedores de infraestructura computacional (p.e. Sun, IBM, Dell, HP,

Cray, entre muchos otros).

De igual forma investigue y caracterice el software de la máquina en términos de:

Manejador de Base de datos (MySQL, PostgreSQL, Oracle, DB2 y Microsoft SQL Server.)

Sistema Operativo (caracterización y configuración general del mismo).

Sistema de Correo Electrónico (Sun Microsystems Mail, Lotus, Microsoft Exchange, entre otros)

Aplicaciones de apoyo requeridas (antivirus, flitro de spam, etc.)

No olvide (además de las características del software) tener en cuenta: costos de licenciamiento,

representación de la marca o casa de software, si tiene o no soporte cada sistema por la casa fabricante,

dificultades de administración, etc.

Especifique en un diagrama de despliegue detalladamente las máquinas y las topologías de forma

detallada (para este fin use la notación UML 2.0 para diagramas de despliegue y componentes).

C. Evaluación de Otras Posibilidades: 6. Tradicionalmente se ha analizado la selección y diseño de la infraestructura para soportar una solución suponiendo que es la compañía la que va a administrar y comprar su propio centro de datos, sin embargo existe la posibilidad de utilizar la Computación en la Nube o CN (“Cloud Computing”). 6.1 ¿A qué nivel de CN llevaría la implementación (nivel de infraestructura IAAS, nivel de plataforma PAAS, nivel de aplicación o SAAS)? Justifique.

6.2 Caracterice el tipo de CN que convendría usar (privado, público ó hibrido) según las necesidades del caso. Justifique su respuesta. 6.3. Analice las ventajas e inconvenientes de usar el tipo de CN seleccionado en este caso con respecto a la de tener una infraestructura propia. Tenga en cuenta aspectos como:

- Seguridad - Escalabilidad - Desempeño - Facilidad de administración - Necesidad de integración con otros sistemas - Legislación - Técnicos (flexibilidad de crecimiento, facilidad de manejo de la obsolescencia, etc.) - Capacidad de la empresa para administrar sistemas, necesidad de genta capacitada, etc. - Otros que considere conveniente

6.4 Haga un análisis económico que muestre qué solución es más conveniente desde este punto de vista (CN o tener un centro de datos propio). Examine los posibles proveedores de servicios CN en el mercado actual y calcule los costos de la contratación de sus servicios para la solución planteada, así como los costos que implicaría tener un centro de datos propio.

6.5 Con base en los análisis anteriores formule una recomendación formal en este caso con respecto al uso de la CN.

Referencias:

Using SANs and NAS, W. Curtis Preston, Capítulos 1, 4, 7, Apéndice B, Publisher: O'Reilly Media,

Inc., February 5, 2002 (Disponible en la Biblioteca).

Schmidt, Claus. High Availability and Disaster Recovery: Concepts, Design, Implementation, capítulo 2, Springer. 2006 (Disponible en la Biblioteca).

Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide, David S.

Linthicum, capítulos 1, 2, 3, 4 (Disponible en la Biblioteca).

Should Your Email Live In The Cloud? A Comparative Cost Analysis, Ted Schadler, Forrester, 2009.

(disponible en la web)

Snevely, Rob. Enterprise Data Center Design and Methodology. Prentice Hall PTR (February 7, 2002).

Arregoses, Mauricio. Data Center Fundamentals . Cisco Press (December 14, 2003).

John W. Rittinghouse. Implementation, Management, and Security. CRC Press, 2010.

- Capitulo 1: Cloud Computing Definiciones Básicas. - Capitulo 2: Communication as a Service, Infrastructure as a Service, Monitoring as a Service,

Platform as a Service, y Software as a Service. - Capitulo 3: Service Oriented Architecture aplicada al diseño de Data Centers. - Capitulo 4: Nociones Básicas Virtualización

Sun Microsystems, Introduction to Cloud Computing (White Paper 1st

Edition), Junio 2009.

¿What is Cloud Computing?: http://www.youtube.com/watch?v=ae_DKNwK_ms&feature=related

Cloud Computing Explained: http://www.youtube.com/watch?v=QJncFirhjPg

Data Center Knowledge: Community http://www.datacenterknowledge.com/