Diseñando un Personal Cloud escalable. Cristian Cotes González

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Diseñando un Personal Cloud escalable. Cristian Cotes González"

Transcripción

1 Departamento de Ingeniería Informática y Matemáticas Grupo de investigación de Arquitecturas y Servicios Telemáticos Diseñando un Personal Cloud escalable por Cristian Cotes González Tutor: Dr. Pedro García López Proyecto final de carrera de: Ingeniería Informática 06 de septiembre de 2013

2

3

4

5 1 Resumen Desde el origen de los ordenadores ha existido la necesidad de utilizar soportes físicos para almacenar y compartir ficheros. Durante los últimos años, con la aparición del Cloud Computing y Cloud Storage, se están creando nuevas formas de dar servicios en Internet y el almacenamiento de datos no es una excepción. La facilidad de uso que han proporcionado los Personal Clouds para poder tener los datos sincronizados y almacenado en servidores de almacenamiento, ha producido que la demanda de estos servicios no pare de crecer durante estos años. Esto ha obligado a crear sistemas escalables que sean capaces de soportar grandes cantidades de usuarios para poder satisfacer la demanda. El objetivo del proyecto es estudiar los requisitos que tiene sistema de sincronización escalable para luego poner los conocimientos adquiridos en práctica proponiendo una arquitectura. Después de eso se procederá a implementar el sistema propuesto y se acabará con unas pruebas de rendimiento que verificarán si se han cumplido los objetivos marcado al inicio del proyecto. La arquitectura tendrá la parte de cliente y la de servidor. Pero para no tener que realizar todo el desarrollo desde cero, se utilizará StackSync como cliente de sincronización. Aunque la filosofía con la que se ha desarrollado StackSync hace que no sea escalable, se tendrán que realizar varias mejoras para poder adaptarlo a la nueva arquitectura. Resum Des dels origens dels ordinadors ha existit la necessitat d utilitzar suports físics per emmagatzemar i compartir fitxers. Durant els últims anys, amb l aparició del Cloud Computing i Cloud Storage, s estan creant noves formes de donar serveis a Internet, i l emmagatzematge de dades no es una exepció. La facilitat d ús que han proporcionat els Personal Clouds per a poder tenir les dades sincronitzades y emmagatzemades en servidors, ha produït que la demanda d aquests serveis no pari de creixer durant els últims anys. Això ha obligat a crear sistemes escalables que puguin soportar grans quantitats d usuaris per poder satisfer la demanda. L objectiu del projecte és estudiar els requisits que tenen els sistemes de sincronitizació escalables per després posar els coneixements adquirits en pràctica proposant una arquitectura. Després d això s implementarà el sistema i s acabarà amb unes probes de rendiment que verificaran si s han complert els objectius marcats a l inici del projecte. 5

6 1 Resumen L arquitectura tindrà la part de client i la de servidor. Però per no haver de realitzar tot el desenvolupament des de zero, s utilitzarà StackSync com a client de sincronització. Tot i que la filosofía amb la que es va desenvolupar StackSync fa que no sigui escalable y es tindrà que millorar per aconseguir adapta-ho a la nova arquitectura. Abstract Since the beginning of the computers age, there has been the necessity to use devices to store and share files. During the last years, with the emergence of Cloud Computing and Cloud Storage concepts appear new types of services in the Internet, and the storage is not an exception. Personal Clouds have created an easy way to sync and store files in servers, and this has produced a high demand during the last years. For this reason, the necessity of creating highly scalable system is a must. The aim of the project is to study the requirements that a scalable synchronization system has to accomplish. Once that I have acquired the knowledge, I will apply them to propose a new scalable architecture. After that, the proposed architecture will be developed and, finally, it will be tested to compare the results with the initial goals. The architecture will have two parts: the client and the server. In order to avoid developing everything from the root, I will use StackSync as a synchronization client. The problem is that StackSync is not as scalable as I would like, so I will have to improve it and adapt it to the new architecture. 6

7 Contents 1 Resumen 5 2 Introducción Antecedentes Objetivos del proyecto Especificaciones Servidor Cliente Tratamiento de ficheros Comunicación Servidor de datos Servidor de metadatos Resolución de conflictos Conflictos en la parte del servidor Conflictos en la parte del cliente Diseño Servidor OpenStack Swift: el servidor de datos SyncService: el servidor de metadatos StackSync: el cliente Mejoras del cliente Arquitectura Chunking dinámico De pull a push Base de datos Sincronización Servidor de actualizaciones API Rest Pseudocódigo Servidor de logs API Rest Base de datos

8 Contents 5 Implementación OpenStack Swift Elección de hardware Gestión de usuarios SyncService Estructura del código Parámetros Base de datos Integración con ObjectMQ StackSync Chunker Integración con ObjectMQ Instalador Servidor de actualizaciones Validación OpenStack Swift SyncService Base de datos Arquitectura Desarrollo de las pruebas StackSync comparado con owncloud Tiempo de sincronización Escalabilidad y balanceo de carga Conclusiones 59 8 Bibliografía 61 8

9 2 Introducción Desde la creación de los ordenadores, los métodos de almacenamiento de datos han ido evolucionando según las necesidades de los usuarios. Son muchos los soportes físicos que se han utilizado para guardar datos durante la historia: desde cintas magnéticas a principios de los años 60 a memorias flash en la actualidad, pasando por disquetes y CDs/DVDs. Sin embargo, durante los últimos años ha aparecido una nueva forma de almacenamiento: el Cloud storage. El Cloud Storage, o almacenamiento en la nube, ofrece a los usuarios una forma fácil y rápida de guardar datos y tenerlos accesibles desde cualquier dispositivo con acceso a Internet. De esta forma ya no se necesita un soporte físico para mover datos de un dispositivo a otro. Para satisfacer la necesidad y poder explotar esta funcionalidad son muchas las nuevas empresas que se han creado (Dropbox, Box, SugarSync) o que se han especializado en dar este servicio (Google con Google Drive o Microsoft con SkyDrive). Todas ellas ofrecen cuentas gratuitas con un espacio inicial limitado (desde los 2 GB hasta 50 GB), pero muchas veces suficiente para uso personal. Crearse una cuenta e instalarse la aplicación es suficiente para empezar a utilizar estos servicios. El cliente de escritorio creará una carpeta en la que cualquier documento o carpeta que se cree se sincronizará en tiempo real con todos los dispositivos que tengan instalado el cliente. Además, ofrecen un servicio de versiones, así si se está trabajando con un documento de texto que se ha modificado varias veces durante los últimos días, el usuario tendrá la posibilidad de restaurar una versión anterior. También permiten compartir carpetas con diferentes usuarios. De esta forma, si varias personas están trabajando en un mismo proyecto, podrían compartir una carpeta entre ellos y tener en todo momento los ficheros actualizados. Gracias a estas características y la facilidad de uso, la aceptación por parte de los usuarios ha sido muy buena, y las empresas que ofrecen el servicio se han visto obligadas a investigar en sistemas escalables, es decir, sistemas que sean capaces de soportar muchos usuarios sin que la calidad se vea afectada. No obstante, la mayoría de usuarios no son conscientes de algunos inconvenientes que tiene el almacenamiento en la nube. A diferencia que los soportes de almacenamiento físicos, con el almacenamiento en la nube ellos no tienen el control de los datos. Todos sus datos son guardados en servidores de terceras empresas. Así pues, el usuario no puede controlar qué se hace con esos datos, ni siquiera sabe si esos datos se están guardando 9

10 2 Introducción encriptados o no. Tal vez esta solución sea válida para uso personal, pero para una empresa que necesita almacenar datos privados utilizar estos servicios no cumple con todos los requisitos de privacidad. Este proyecto se ha desarrollado en el contexto del proyecto Europeo CP7 CloudSpaces. 2.1 Antecedentes En este apartado se van a describir conceptos que son necesarios para entender el proyecto. Primero se definirá el concepto de Cloud Computing o computación en la nube y luego se describirá qué es un Personal Cloud. Para acabar se explicará qué es y para que sirve una API rest. Cloud Computing o computación en la nube El Cloud Computing es un paradigma que permite ofrecer servicios de computación a través de Internet. En este tipo de computación todo lo que puede ofrecer un sistema informático se ofrece como servicio, de modo que los usuarios puedan acceder a los servicios disponibles en la nube de Internet sin conocimientos (o, al menos sin ser expertos) en la gestión de los recursos que usan. Se utilizan servidores desde Internet encargados de atender las peticiones en cualquier momento. Se puede tener acceso a su información o servicio, mediante una conexión a Internet desde cualquier dispositivo móvil o fijo ubicado en cualquier lugar. Hay tres capas diferentes en los servicios de Cloud: Infraestructura como servicio (Iaas): Proporciona almacenamiento básico y capacidades de cómputo como servicios. Es la capa de mas bajo nivel. Plataforma como servicio (Paas): Es la encapsulación de una abstracción de un ambiente de desarrollo y el empaquetamiento de una serie de módulos o complementos que proporcionan, normalmente, una funcionalidad horizontal (persistencia de datos, autenticación, mensajería, etc.). Software como servicio (Saas): Se encuentra en la capa más alta y caracteriza una aplicación completa ofrecida como un servicio. Igual que hay diferentes tipos de Cloud según los servicio que ofrece, también hay diferentes tipos de Cloud según la arquitectura interna: Cloud público: En este tipo de nubes tanto los datos como los procesos de varios clientes se mezclan en los servidores, sistemas de almacenamiento y otras infraestructuras de la nube. Los usuarios finales de la nube no conocen que trabajos de otros clientes pueden estar corriendo en el mismo servidor, red, sistemas de almacenamiento, etc. 10

11 2.1 Antecedentes Cloud privado: Son una buena opción para las compañías que necesitan alta protección de datos y ediciones a nivel de servicio. Las nubes privadas están en una infraestructura bajo demanda gestionada para un solo cliente que controla qué aplicaciones debe ejecutarse y dónde. Cloud híbrido: Combinan los modelos de nubes públicas y privadas. Personal Cloud Un Personal Cloud es un servicio de almacenamiento en la nube que ofrece tres servicios claves: almacenamiento, sincronización y compartición. Por un lado, tiene que ofrecer redundancia y seguridad para poder almacenar datos privados. Por otra lado, tiene que disponer de un servicio de sincronización en diferentes plataformas y dispositivos. Finalmente, tiene que ofrecer un sistema de compartición de información con otros usuarios o aplicaciones. Hay varias empresas que dan un claro ejemplo de lo que es un Personal Cloud, algunas de ellas son Dropbox, Google Drive o Box. Todos ellos ponen al alcance de cualquiera de forma sencilla y transparente poder utilizar un Personal Cloud con todas las características comentadas anteriormente. API REST REST (REpresentational State Transfer) es un tipo de arquitectura de desarrollo web que se apoya totalmente en el estándar HTTP. REST permite crear servicios y aplicaciones que pueden ser usadas por cualquier dispositivo o cliente que entienda HTTP, por lo que es increíblemente más simple y convencional que otras alternativas que se han usado en los últimos diez años como SOAP y XML-RPC. Una API REST es un conjunto de llamadas HTTP para poder acceder a un servicio web. Para manipular los recursos del servidor, se utilizan las diferentes peticiones HTTP (GET, PUT, POST...) para realizar un determinado tipo de acción. Por ejemplo, todos los servicios de Personal Cloud disponen de una API Rest para terceras aplicaciones, si se quiere guardar un fichero en el sistema se utilizará la petición PUT. Por otro lado, si se quiere recuperar el fichero se utilizará un GET. StackSync StackSync es un cliente de escritorio basado en Syncany, un cliente de sincronización con un sistema de módulos para poder almacenar datos en varios servidores de datos. Está pensado para trabajar con un modelo cliente-servidor en el que el servidor es sólamente un servicio para almacenar datos. Así pues toda la lógica de sincronización, y lo que ello conlleva, recae sobre el cliente. Para poder sincronizar los datos entre los clientes se utiliza un fichero de texto que se almacena en el servidor de datos y que todos los clientes van descargando periódicamente 11

12 2 Introducción para comprobar si hay cambios en los ficheros sincronizados. 2.2 Objetivos del proyecto Como se ha comentado en la introducción del proyecto, los Personal Clouds están teniendo gran aceptación por parte de los usuarios para poder tener sus datos almacenados en la nube y sincronizados con todos sus dispositivos. Debido a la gran demanda que hay en el mercado, no tiene sentido tener un sistema de sincronización que no sea capaz de soportar grandes cargas de usuarios. Como se ha explicado en los antecedentes, el cliente StackSync es una aplicación funcional capaz de sincronizar datos entre distintos dispositivos. Pero debido a la filosofía de querer sincronizar con muchos sistemas de almacenamiento, se ha olvidado el requisito más importante de los Personal Clouds, la escalabilidad. Aunque la arquitectura de StackSync está muy bien diseñada e implementa varios métodos para intentar optimizar la transferencia de ficheros, eso no evita que la sincronización se haga toda a través de un fichero de datos. Además, la política de descubrimiento de actualizaciones de otros dispositivos no hará más que sobrecargar el servidor cuando el número de usuarios crezca. En el caso de StackSync, los problemas de escalabilidad no vienen por la parte del servidor, ya que es el cliente el que se encarga de realizar todo el trabajo. Pero esto no significa que en determinadas ocasiones no pueda ser el servidor el eslabón débil que no permita escalar al sistema. En este proyecto, primero se van a estudiar las necesidades que tiene que cumplir un Personal Cloud para escalar. Una vez se tenga claro cuales son los requisitos para poder crear un sistema escalable, se va a proponer una arquitectura de sincronización escalable en la que se utilizará una versión mejorada de StackSync. 12

13 3 Especificaciones El sistema está formado por dor partes bien diferenciadas: servidor y cliente. 3.1 Servidor La parte de servidor se encarga de almacenar los ficheros que los usuarios quieren sincronizar con sus cuentas. Los ficheros necesariamente llevan asociados metadatos. Estos metadatos son campos de texto que añaden información adicional, como la fecha de creación y modificación, tamaño, creador o número de versión. Los metadatos a menudo son críticos y plantean riesgos de seguridad, ya que contienen información sensible como nombres de usuarios o rutas del sistema de ficheros. El sistema de sincronización necesitará todos estos metadatos para poder gestionar los eventos que reciba de los clientes de escritorio, así que estos datos tienen que ser almacenados en una parte segura del sistema. Para garantizar la seguridad de estos, se ha decidido separar lo que es el tráfico de datos con el trafico de metadatos, de esta forma ambos procesos pueden ejecutarse en diferentes máquinas. En el entorno de una gran empresa, se podría utilizar como servidor de matadatos un servidor interno, que no tenga acceso a Internet, y para el servidor de datos podría contratar a algún proveedor de almacenamiento en la nube. Con esto se consigue que los datos críticos y sensibles (metadatos) no salgan de la empresa y se guarden en la nube los datos encriptados. A continuación se explica un poco más en detalle las especificaciones de cada uno de estos servicios. Servidor de datos El servidor de datos almacenará los ficheros. Este servidor tiene que cumplir con los requisitos fundamentales del almacenamiento en la nube: Escalabilidad: El sistema tiene que ser capaz de soportar un gran número de usuarios manteniendo la calidad del servicio. Replicación: El mismo servidor se encarga de crear las réplicas del contenido para garantizar que los datos no se pierdan. Disponibilidad: Los datos tienen que estar disponibles en cualquier momento. 13

14 3 Especificaciones Accesibilidad: Cualquier dispositivo con acceso a Internet podrá acceder a los datos. Flexibilidad: Adaptación a las necesidades de la aplicación. Empresas como Dropbox o Box contratan a terceras empresas para que les ofrezcan estos servicios. Algunas de las empresas más conocidas son Amazon S3 y Rackspace. Debido a esto, las empresas que ofrecen servicios de Personal Clouds, hacen de intermediarios entre los usuarios y los servidores de almacenamiento. Otra solución para no tener que contratar ningún servicio de almacenamiento, es utilizar una plataforma Cloud open source. Hay varios proyectos conocidos que están avanzando muy rápidamente gracias a la colaboración de la comunidad y que permiten desplegar desde cero un Cloud escalable y tolerante a fallos listo para ponerlo en producción. Por contra, se necesitará una infraestructura que aloje todo los servidores. Cada cliente se conectará directamente a una cuenta de usuario para subir o descargar ficheros. Esto hace que un requisito fundamental es que el servidor de datos permita gestionar cuentas de usuarios (crear o eliminar) a un administrador del sistema. También tiene que tener un control de acceso para evitar que alguien pueda acceder a datos de otros usuarios. Servidor de metadatos El servidor de metadatos se encarga de gestionar y guardar los metadatos necesarios para poder realizar la sincronización de los datos. Los clientes de escritorio se comunicarán con el servidor de metadatos para: Pedir las actualizaciones que han ocurrido mientras el cliente ha estado desconectado. Notificar una nueva versión de un fichero. Cuando un cliente se conecta al sistema, lo primero que hace es pedir al servidor de metadatos los cambios que se han realizado en los fichero mientras ha estado desconectado. Este caso es muy común en usuarios que trabajan con dos ordenadores diferentes, por ejemplo, el de casa y el del trabajo. Mientras el usuario está en el trabajo y modifica ficheros sincronizados, si el ordenador de casa está apagado no recibirá ninguna notificación, así que una vez llegue a casa y encienda el ordenador, este tendrá que actualizarse para aplicar los cambios realizados en el trabajo. Cuando el servidor recibe una actualización de un fichero, tiene que comprobar que los metadatos sean coherentes. Si los metadatos son correctos, se procederá a guardarlos en una base de datos para poder consultarlos en un futuro. Finalmente, se enviará una notificación a todos los dispositivos de ese usuario informando sobre la actualización del fichero. Con esto se consigue que prácticamente en tiempo real todos los dispositivos puedan recibir notificaciones de cambios y estar siempre sincronizados. En cambio, si 14

15 3.2 Cliente los metadatos son incorrectos, se enviará el fallo al cliente para que solucione el error y vuelva a subirlos sin errores. 3.2 Cliente El cliente será la aplicación que se instalarán los usuarios. Su función es procesar los ficheros a sincronizar y comunicarse con el servidor para almacenarlos en la nube. Como requisitos genéricos, el cliente tiene que cumplir lo siguiente: Detectar cambios en el sistema de fichero: Cada vez que haya un cambio en la carpeta sincronizada, tendrá que procesar el evento para sincronizarlo con el sistema. Instalación: El cliente tiene que poder instalarse como cualquier aplicación de ordenador. Durante la instalación el usuario tendrá que elegir que carpeta querrá sincronizar. Una vez instalado, tiene que integrarse con el sistema de la forma más transparente posible para el usuario. Actualizaciónes: La aplicación también dispondrá de un sistema de actualizaciones automático. Periódicamente el programa comprobará si existe una actualización, en tal caso se descargará y se instalará. Notificación de errores: Cualquier error que pueda lanzar el cliente será enviado a un servidor de logs el cual las almacenará para poder analizar y arreglar los errores que puedan ir apareciendo con el uso de la aplicación. Información visual: Para poder mostrar información del estado de los ficheros, se integrará con el Explorador de Windows un sistema de iconos, llamados overlays, que, dependiendo del estado de los ficheros, mostrará un tipo de icono u otro. Inicialmente habrá tres overlays diferentes para tres posibles estados: SYNCED(sincronizado), SYNCIN (sincronizándose) y UNSYNC (no sincronizado). En la figura 3.1 se pueden ver las imágenes para cada estado. Figure 3.1: Overlays Tratamiento de ficheros El cliente tiene que integrarse con el sistema de tal forma que, cuando haya algún cambio en la carpeta de sincronización, la aplicación reciba una notificación para a procesar el evento. Una vez que se haya detectado qué fichero es el modificado o creado, este pasará a ser tratado para almacenarlo en la nube. 15

16 3 Especificaciones Primero se extraerán los metadatos necesarios de dicho fichero: nombre, tamaño, fecha de modificación, hash... Seguidamente se guardarán en una base de datos que se utilizará para tener la información de las diferentes versiones que se hayan creando de los ficheros. A continuación se partirá el fichero en diferentes trozos, llamdos chunks. Internamente, los Personal Clouds no utilizan el concepto de fichero, sino que trabajan en un nivel inferior dividiendo los ficheros en chunks. Cada chunk es tratado de forma independiente y es identificado por su valor de hash. Para reconstruir el fichero se necesitas que todos los chunks sean unidos en el orden correcto. Los principales motivos por los que aplicar un algoritmo de chunkig es aconsejable son: 1. Optimizar la transferencia de datos con el servidor: Cuando se modifica un fichero, se aplica de nuevo todo el proceso, incluyendo el chunking. Si la modificación se ha realizado en la parte final del fichero, las primeras partes no habrán variado, así que los chunks iniciales serán los mismos que los de la versión anterior. El cliente será consciente de eso y no hará falta que se vuelvan a subir esos datos porque ya están en el servidor. 2. Optimizar el espacio de almacenamiento utlizado: Como se ha comentado en el punto anterior, al modificar un fichero sólo se subirán los chunks modificados. Si no se aplicara una estrategia de chunking, aunque sólo se modificara un byte del fichero, se volvería a subir todo entero, ocupando mucho más espacio que si se sube sólo la parte modificada. 3. Facilitar la transferencia de fichero grandes: Si un usuario quiere sincronizar un fichero de 3 GB, sería muy costoso, tanto para el cliente como para el servidor, mantener la conexión establecida hasta que el total de los datos ha sido transferido. Como los chunks normalmente ocupan poco espacio (entre 32 KB y 1 MB), la transferencia de estos es mucho más rápida. Así que si se pierde la conexión al servidor en mitad de la sincronización, se podrá seguir en el punto en el que se paró, sin tener que volver a subir todos los chunks. Cuando el proceso de chunking ha finalizado, el programa procederá a subir los chunks al servidor de datos. Se conectará directamente a la cuenta del usuario para guardar los datos en su espacio privado. Una vez que el fichero ya se ha subido por completo al servidor de datos, se establecerá una comunicación con el servidor de metadatos para notificar la nueva versión del fichero. Es en ese momento cuando el servidor de metadatos procesará los metadatos y enviará a todos los dispositivos del usuario una notificación con los datos necesarios para que se puedan actualizar. En el instante en el que cualquier cliente que esté ejecutándose en otra máquina recibe el evento, aplicará el algoritmo de sincronización. Si no hay ningún conflicto con la nueva versión del fichero, se procederá a descargar todos los chunks del fichero 16

17 3.3 Comunicación y a ensamblarlos en orden. Cuando el fichero ya esté completamente descargado, se mostrará en la carpeta de sincronización con un icono indicando que está listo para ser usado por el usuario. 3.3 Comunicación Como ya se ha comentado en las dos secciones anteriores, el cliente está en constante comunicación con los servidores. Como el propósito de ambos es totalmente distinto, a continuación se detallará qué datos se tienen que enviar y cuales son las posibles respuestas que espera recibir el cliente Servidor de datos El servidor de datos es uno de los componentes de la arquitectura que no se desarrollarán desde cero debido a su complejidad. Tanto si se contrata el servicio a una empresa, como si se despliega un Cloud con algunas de las soluciones de código libre, en ambos casos el protocolo de comunicación está predeterminado. Así que una de las características a tener en cuenta a la hora de elegir una solución, son las formas de comunicación con la misma. Algunos de los requisitos que tiene que cumplir el servidor de datos en cuanto a comunicación son: Control de acceso: El sistema tiene que disponer de un control de acceso para permitir que los usuarios sólo puedan acceder a sus datos. Subir o bajar ficheros: Tiene que permitir almacenar y recuperar ficheros. Borrar ficheros: Además tiene que dar la opción de borrar ficheros que ya no estén en uso para poder liberar espacio. Metadatos del almacenamiento: Aunque no es estríctamente necesario, estaría bien que el servidor de datos ofreciera metadatos sobre el mismo almacenamiento como, por ejemplo, el espacio total ocupado o el número de objectos que hay subidos. La mayoria de veces, para acceder a estos servicios y sus funcionalidades se utiliza una API Rest Servidor de metadatos La comunicación entre el servidor de metadatos y los clientes es bidireccional. Los clientes pueden notificar en cualquier momento una actualización de un fichero al servidor y prácticamente al instante, recibir todos los dispositivos de ese usuario la notificación con el nuevo cambio. 17

18 3 Especificaciones Para que los clientes puedan estar sincronizados en todo momento, necesitan saber todos los cambios que se realicen en la cuenta del usuario. Esto se puede conseguir de dos formas: haciendo que el cliente pregunte periódicamente al servidor de metadatos si ha ocurrido algún cambio (pull) o que el servidor de metadatos notifique directamente los eventos a los clientes (push). Los modelos de comunicación pull y push han sido comparados en numerosos artículos de investigación. A continuación se ofrece una breve descripción de ambos conceptos con sus ventajas e inconvenientes. Pull: En esta estrategia, la información está disponible en el servidor y son los clientes los que preguntan periódicamente si ha habido algún cambio. Si hay muchos clientes conectados simultáneamente, el servidor podría llegar a colapsarse al recibir muchas peticiones. Además crearía muchas comunicaciones que la mayoría de veces serían innecesarias. Así que si se quiere crear un sistema escalable, en el que un gran número de usuarios utilicen el servicio, esta estrategia no es la adecuada. Push: Es el caso contrario la anterior. En vez de preguntar los clientes, estos se mantienen a la espera de que el servidor les notifique cambios. Al contrario que en el modelo pull, aquí se ahorra mucha comunicación con el servidor, pero tiene el inconveniente de que los clientes tienen que mantener una conexión contínua abierta para recibir las notificaciones. A priori, la decisión de utilizar un modelo de comunicación push en vez de pull es clara. Menos carga del servidor y menos comunicación para sincronizarse. Los clientes pueden realizar dos tipos de llamadas al servidor: síncronas y asincronas. Llamadas síncronas Hay peticiones que los clientes hacen al servidor de metadatos que son necesarias para que puedan iniciarse. Este tipo de llamadas será bloqueante, es decir, cuando el cliente haga la petición, quedará bloqueado hasta que el servidor le haya respondido. Cada vez que el cliente se pone en marcha, es necesario que aplique todos los cambios que se han efectuado mientras no ha estado ejectuandose. Como las notificaciones siguen una estrategia push, si estas no son procesadas en el momento que el servidor hace el broadcast, se pierden. Por eso el cliente tendrá que pedir al servidor el estado actual de los ficheros para que él mismo compruebe cuales son los cambios que han habido. El hecho de que esta llamada sea bloqueante hace que el tiempo que tiene el servidor para procesarla sea crítico, ya que si no se responde en un periodo de tiempo adecuado, podrían empezar a acomularse peticiones en horas puntas del día. Llamadas asíncronas Por otro lado, hay peticiones que requieren bastante tiempo de procesamiento para asegurar la consistencia de los datos. Desacoplar el envío del mensaje de su proce- 18

19 3.4 Resolución de conflictos samiento en estos escenarios es vital para asegurar la escalabilidad del sistema. Un ejemplo de llamada asíncrona es cuando el cliente quiere subir los metadatos de una nueva versión. En el momento en que el cliente ha subido un fichero al servidor de datos, envía una petición de commit al servidor de metadatos con todos los datos necesarios. El servidor, después de analizar que los datos sean coherentes y no haya ningún conflicto, envía un evento a todos los dispositivos del usuario. Durante el espacio de tiempo que pasa desde que se envía el mensaje, hasta que se recibe la notificación, el cliente puede ir haciendo otras tareas. 3.4 Resolución de conflictos Como en cualquier sistema Personal Clouds, los conflictos de sincronización pueden suceder. Como es imposible evitar estos errores, es necesario implementar una estrategia para tratarlos y resolverlos. Básicamente, estos errores ocurren en entornos en los que más de un usuario modifica el mismo fichero al mismo tiempo. Puede haber dos tipos de conflictos, los que son detectados por el servidor de metadatos y los que son detectados por el cliente Conflictos en la parte del servidor El escenario más común para estos conflictos es cuando dos usuarios intentan subir el mismo número de versión al servidor con diferentes metadatos. Para entender mejor el problema, se explica con un ejemplo: Supongamos que hay un fichero compartido que está en la versión número cuatro y que dos usuarios lo están modificando a la vez. Cuando guarden el fichero, cada cliente intentará subir la versión número cinco, pero solo una será procesada. La política de resolución de conflictos en la parte del servidor es que el primero que llega, es el ganador. En este ejemplo, cuando llega la segunda versión, el servidor se daría cuenta de que se está intentando subir una versión que ya existe y los metadatos (chunks, hashes, tamaño...) son diferentes. Así, el primer cliente recibirá que su versión ha sido procesada correctamente, mientras que el segundo recibirá un error explicando el motivo que lo ha producido. En la figura 3.2 se puede ver una imágen para clarificar el ejemplo. Como se puede observar en este caso, es el servidor el que decide qué versión es la ganadora y cual es la que no se acepta como buena. A partir de aquí será el cliente el que tenga que solucionar el problema. Cuando el cliente recibe que su versión no se ha podido procesar porque ya existe esa versión del fichero, lo que tiene que hacer es descargar la version número cinco real (la que el servidor ha aceptado) y crear un fichero nuevo en la carpeta del usuario nombrándolo Copia conflictiva. De esta se evita que se pierdan los datos que el usuario ha hecho en su versión número cinco ficticia. 19

20 3 Especificaciones Figure 3.2: Conflicto de un fichero Conflictos en la parte del cliente Puede ser, que mientras se trabaje con un fichero, se pierda la conexión a Internet. El cliente tiene que estar preparado para saber manejar estas situaciones. Durante el tiempo que el cliente no tenga conxión a Internet, será imposible notificar cualquier actualización a los servidores, de forma que el cliente guardará en la base de datos internas todos los cambios que no se hayan subido. En una situación como en la anterior, el usuario, al ver que no hay conexión y que no se está sincronizando nada, puede que decida ir al ordenador del trabajo para seguir con la tarea que estaba haciendo. Modificará los ficheros que había modificado en el otro cliente que no se habían subido. Al volver a arrancar el cliente que tenía pendiente subir algunas versiones, pedirá las actualizaciones que han habido mientras que ha estado desconectado. En el momento en que empiece a procesarlas una a una, detectará que hay una versión conflictiva entre las actualizaciones que ha recibido del servidor y las que tenía en su base de datos local. Es aquí cuando el cliente tendrá que decidir qué versión es la válida. Como los metadatos del servidor no se pueden modificar, no se podrá hacer otra cosa que renombrar el fichero que tiene en local el cliente con el nombre de Copia conflictiva y tratar los metadatos que le llegan desde el servidor como los válidos. 20

21 4 Diseño En este apartado se comentarán las decisiones de diseño previas a la implementación de las diferentes partes del proyecto. Además, se hará un estudio de las tecnologías que se pueden usar en cada parte de la arquitectura y después se elegirá la más adecuada. Como ya se ha explicado anteriormente, la arquitectura propuesta consta de dos partes bien diferenciadas: parte de servidor y de cliente. La parte de servidor se divide en dos partes independiente entre ellas: el servidor de datos y el de metadatos. En la figura 4.1 se muestra una imagen general del sistema con la comunicación que habrá entre sus componentes. Metadata DB Sync service Storage backend FTP/SFTP WebDAV Push ObjectMQ Desktop client Indexer Chunker Storage plugin Figure 4.1: Arquitectura del Personal Cloud. Ahora que se tiene una visión global de la arquitectura, se entrará más en detalle en cada una de las partes para comentar su diseño interno. 21

22 4 Diseño 4.1 Servidor OpenStack Swift: el servidor de datos Como se comentará en el apartado del cliente, este tiene la opción de conectarse a múltiples sistemas de almacenamiento como, por ejemplo, una FTP, Amazon S3, un servidor WebDAV o Rackspace. Para el proyecto solo es necesario elegir un sistema de almacenamiento que cumpla los requisitos comentados en el apartado de especificaciones. Así que después de estudiar las diferentes soluciones se ha decidido utilizar OpenStack Swift. La definición de OpenStack Swift según la documentación inicial es: Swift is a highly available, distributed, eventually consistent object/blob store. Organizations can use Swift to store lots of data efficiently, safely, and cheaply. Algunos de los motivos por lo que se ha tomado la decisión de utilizar OpenStack Swift como almacenamiento en la nube son: Es una plataforma de Cloud open source que en los últimos años ha crecido de forma muy rápida y con gran aceptación por parte de la comunidad Cloud. Cumple todos los requisitos de un almacenamiento en la nube: escalabilidad, accesibilidad, replicación... Cada seis meses hay una versión nuevo con más funcionalidades y mejoras en el rendimiento y la estabilidad. Además, el hecho de que Swift tenga una gran comunidad open source hace que cualquier bug encontrado se resuelva con relativa rapideza. Arquitectura La arquitectura de Swift está forma por: Proxy Node: Es el punto de entrada al Cloud. peticiones y de comunicarse con los Storage Nodes. Se encarga de procesar las Storage Node: Se encarga de almacenar los datos que le encarga el Proxy. Además, tiene algunos servicios de replicación y de consistencia de datos ejecutándose continuamente. Auth Node: En las arquitecturas más pequeñas se integra en el mismo Proxy. Su función es la de autenticar y validar las peticiones de usuarios. En la figura 4.2 se puede ver un ejemplo de arquitectura de Swift. Una vez se tiene instalada toda la arquitectura, añadir nuevos nodos para soportar más carga es una tarea simple. Cuando un nodo se introduce en la arquitectura, se inicia un proceso para balancear los datos que hay entre todos los nodos. 22

23 4.1 Servidor Figure 4.2: Ejemplo de arquitectura de OpenStack Swift. Cuando se quiere almacenar un ficheor en Swift, en ralidad se guardan tres copias del mismo en tres Storage Nodes diferentes. De esta forma, si algún nodo cae, los datos que contenía se reparten entre los nodos restantes de forma equilibrada. Así que el sistema siempre tiene tres copias de un mismo fichero. Gestión de usuarios Para poder utilizar los servicios de Swift es necesario tener una cuenta de usuario. Para acceder al sistema es necesario autenticarse mediante la API Rest que ofrece. Cuando el usuario se valida, Swift devuelve información necesaria para poder interactuar con el almacenamiento: Auth-token: Es un token que tiene una validez de 24 horas, después de ese tiempo se caduca. En todas las peticiones que realize el cliente tiene que llevar el token en una cabecera. Esto se utilizara para autenticar y autorizar al usuario. Storage-URL: Cada usuario tiene una URL única que es a la que tiene que realizar las peticiones. La Storage-URL no cambia nunca y no puede haber dos iguales. Cuando el usuario tiene el token autenticador y la storage-url, puede empezar a utilizar el servicio. Para subir ficheros antes tiene que crear un container. El container es un espacio en el que se pueden guardar objetos y se pueden crear tantos como se necesiten, pero nunca se pueden crear containers dentro de containers. Además, hay tres servicios corriendo en Swift que pueden ofrecer información al usuario: Servicio de account: Contiene datos de las cuentas de usuarios e información relacionada con estas como, por ejemplo, el número de containers o objetos o el espacio 23

24 4 Diseño total ocupado. Servicio de container: Contiene datos específicos de containers como los objetos que hay dentro de los containers, las fechas de actualización... Servicio de objetos: Muestra información de los objetos como las fechas de creación o el tamaño que ocupan SyncService: el servidor de metadatos El servidor de metadatos, llamado SyncService, es la parte más importante y crítica de toda la arquitectura de sincronización. Se encarga de notificar eventos a los clientes, gestionar las actualizaciones y de la persistencia de metadatos. A diferencia de los servicios de almacenamiento, en este caso no hay ningún Personal Cloud open source, así que se tendrá que desarrollar desde cero. Para explicar todas las decisiones de diseño de forma ordenada se crearán tres subsecciones: 1. Persistencia de metadatos 2. Procesamiento de metadatos 3. Comunicación Persistencia de metadatos Los metadatos se almacenarán en una base de datos. extraido de los requisitos son: Las entidades que se han User: Se corresponde con un usuario del sistema. Tendrá como atributos el nombre, un y un identificador, entre otros. Device: Es un dispositivo físico. Un usuario puede tener más de un dispositivo (ordenador de casa y del trabajo, por ejemplo). Workspace: Por defecto cada usuario tiene su propio workspace. Cuando se comparte una carpeta se crea otro workspace, de ese modo todas las modificaciones que se hagan en los ficheros de la carpeta compartida irán a parar al workspace compartido y no al principal. Object: Es un fichero o carpeta. Los workspaces contienen objetos. Algunos de los atributos que tiene son un identificador único en el sistema, un nombre, un path... Version: Un objeto estará formado por versiones. Una versión contiene los datos que más pueden variar al modificarse el fichero. Algunos ejemplos son: checksum, hora de modificación, tamaño, estado, el dispositivo que ha realizado el cambio... 24

25 4.1 Servidor Chunk: Un chunk es una porción de una versión específica de un objeto. De forma que una versión tendrá uno o varios chunks si es un fichero o ninguno si es una carpeta. Con estos datos se ha creado el diseño de la base de datos. En la figura 4.3 se puede ver el diagrama. Figure 4.3: Diagrama base de datos del SyncService. Con el esquema de la base de datos claro, se ha estudiado qué base de datos era la mejor para el sistema: MySQL o PostgreSQL. Comparando ambas soluciones, se ha decidido utilizar PostgreSQL en vez de MySQL por los siguientes motivos: PostgreSQL tiene mejor rendimiento que MySQL cuando la base de datos contiene muchas entradas. PostgreSQL cuenta con funciones recursivas que dan un rendimiento muy superior 25

26 4 Diseño a MySQL si se saben utilizar correctamente. La comunidad open source de MySQL está migrando a MariaDB, así que cada vez hay menos soporte por parte de los usuarios. Para poder acceder o modificar los valores de la base de datos desde el código se tendrá que implementar el patrón de diseño DAO (Data Access Object). Con este patrón se cre crea una interfaz común entre la aplciación y la base de datos. Además, se creará también una factoría en la que se le especificiará que tipo de base de datos se quiere utilizar. Así se consigue crear un sistema de persistencia modular, en el que si se quiere añadir una base de datos diferentes solo hay que implementar las interfaces del DAO y no se tiene que modificar nada del código. El diagrama de clases del DAO se puede ver en la figura 4.4. com.stacksync.syncservice.db DAOFactory +getdatabasedao(type:string): DatabaseDAO <<interface>> DatabaseDAO +getobject(id:long): Object +getdevice(id:long): Device +getchunk(id:long): Chunk com.stacksync.syncservice.db.postgresql PostgresqlDatabaseDAO +getobject(id:long): Object +getdevice(id:long): Device +getchunk(id:long): Chunk Figure 4.4: Diagrama de clases del patrón DAO aplicado al SyncService. Procesamiento de metadatos Cuando el SyncService reciba un commit, tiene que haber un procesamiento de metadatos para comprobar si la versión es correcta y no hay ningún conflicto. El psuedocódigo se puede ver en 1. Para poder procesar correctamente los metadatades, se harán varias consultas a la base de datos. Si todo ha ido bien, se guardará la nueva versión. Toda la comunicación 26

27 4.1 Servidor Algorithm 1 Pseudocode of the commitrequest function in the SyncService 1: function commitrequest(workspace, List < ObjectM etadata > objects changed) 2: commit event new instance of CommitEvent 3: for new object in objects changed do 4: server object metadata backend.get current version(new object.id) 5: if not exists server object then To commit the first version of the new object 6: metadata backend.store new object(new object) 7: commit event.add(new object, confirmed = T rue) 8: else if server object.version precedes new object.version then 9: No conflict, committing the new version 10: metadata backend.store new version(new object) 11: commit event.add(new object, confirmed = T rue) 12: else 13: Conflict detected, the current object metadata is returned 14: commit event.add(new object, confirmed = F alse, server object) 15: end if 16: end for 17: trigger event(workspace, commit event) 18: end function con la base de datos se hace a través del patrón DAO que se ha explicado en el apartado anterior. Comunicación Para un sistema de sincronización, la comunicación es vital. Tiene que ser segura, rápida y, sobretodo, escalable, ya que el servidor tiene que soportar muchas peticiones. Por ese motivo se ha decidido utilizar ObjectMQ, que es un middleware orientado a objectos implementado sobre un modelo MOM (message-oriented middleware). Gracias a esto consigue mezclar las ventajas de ambos tipos de middleware. Así pues consigue ser un middleware muy escalable y fiable. Este middleware se caracteriza por su facilidad de uso en distintos tipos de invocaciones remotas. Permite hacer invocaciones síncronas, asíncronas y llamadas a múltiples objetos remotos mediante simples anotaciones Esta es una llamada remota síncrona bloqueante. Se puede configurar un timeout y el número de veces que se tiene que reintentar la llamada antes de lanzar la Esta es una llamada asíncrona. El cliente no espera recibir Cuando esta anotación se utiliza junto con las otras dos, las invocaciones irán a todos los servidores que están a la escucha. Para la comunicación entre el cliente y el SyncService se tendrán que implementar tres llamadas: 27

28 4 Diseño GetWorkspaces: Esta llamada la realizará el cliente en la inicialización. Servirá pera que reciba a qué workspaces tiene acceso. Esta llamada es síncrona, ya que es necesaria para la inicialización. GetChanges: Después de haber recibido los workspaces disponibles, por cada uno de ellos realizará una llamada GetChanges. Esta llamada retorna los metadatos de la última versión de los ficheros sincronizados. Así es como el cliente puede saber qué ficheros han cambiado mientras estaba desconectado. Esta llamada es síncrona, ya que es necesaria para la inicialización. Commit: Esta llamada será la que realice el cliente cada vez que el usuario haya modificado un fichero. Esta llamada será asíncrona. 4.2 StackSync: el cliente StackSync se darrolló para poder sincronizar ficheros con cualquier almacenamiento en la nube. Esto limita mucho las funcionalidades y el potencial del cliente. Querer abarcar la sincronización sin importar el servicio de almacenamiento afecta directamente a la escalabilidad del sistema. Por ese motivo se van a tener que realizar varias mejoras en el cliente para adaptarlo a la arquitectura presentada en el proyecto Mejoras del cliente Los puntos que se intentarán potenciar o mejorar del cliente para poder introducirlo en el sistema escalable son los siguientes: Sincronización: Como StackSync esta pensado para trabajar sin un servidor de metadatos, todos los metadatos necesarios los guarda en un fichero de texto plano llamado update. Este fichero se guarda en el servidor de datos y cada dispositivo tiene el suyo. Cuando algún dispositivo realiza un cambio, modifica su fichero update con las nuevas versiones. Para que el resto de dispositivos puedan aplicar el cambio, se tienen que descargar de forma periódica el fichero update y comprobar si ha habido cambios. Este modelo de ir descargando cada poco tiempo los fichero updates es el equivalente al una estrategia pull, así que es necesario cambiar este comportamiento. Chunking: El cliente crea chunks estáticos de 512 KB de los ficheros. Así que si se modifica el principio del fichero añadiendo un solo byte, todos los chunks se desplazan un byte y cambia el hash que los identifica. Si esto ocurre se tiene que volver a subir de nuevo todos los chunks, cuando en realidad los datos ya están subidos. Algoritmo de sincronización: El algoritmo de sincronización esta preparado para trabajar con el fichero update. Al ser este fichero un cuello de botella para el sistema, el SyncService será el encargado de hacer sus funciones pero de forma correcta, óptima y escalable. Finalmente se va a crear un algoritmo de sincronización 28

29 4.2 StackSync: el cliente más sencillo y que se adaptará mejor con la arquitectura propuesta. A parte de estos puntos que se han comentado, el cliente StackSync tampoco conta con un instalador, con un servidor de logs remoto ni con un servidor de actualizaciones, así que todas estas características se tendrán que implementar desde cero Arquitectura En la figura 4.5 se muestra la nueva arquitectura interna de StackSync que se va a implementar. Es muy parecida a la que ya tenía, pero se ha añadido el SyncService, que será el servidor de metadatos y el EventListener que será el proceso que estará a la espera de notificaciones del SyncService. Swift TransferManager SyncService Uploader EventListener Indexer ChangeManager Watcher Figure 4.5: Arquitectura de StackSync. Watcher: Recibe eventos de modificaciones en los ficheros de la carpeta sincronizada. Cualquier acción (crear, modificar, borrar...) se notifica al Indexer. Indexer: Cuando recibe un evento del Wathcer tiene que procesarlo. Actualiza la base de datos de StackSync y crea los chunks del fichero modificado o creado. Uploader: Se encarga de comunciarse con Swift y el SyncService. Primero sube los chunks a Swift utilizando la interfaz TransferManager. Después notifica al SyncService el commit del fichero. EventListener: Está a la espera de recibir eventos del SyncService. Cuando los recibe los encola para que puedan ser tratados por el ChangeManager 29

30 4 Diseño ChangeManager: Procesa todos los eventos que vienen del SyncService. Contiene el algoritmo de sincronización Chunking dinámico El chunking estático que utilizaba la versión inicial de StackSync funciona bien para un sistema con poco usuarios, pero si se quiere crear un sistema realmente escalable se tiene que utilizar un chunking dinámico. Un chunking dinámico basado en contenido puede reducir notablemente la cantidad de espacio utilizado por los usuarios en el servidor de datos. Al contrario que con el chunking estático, cuando el usuario modifique un fichero el mismo algoritmo de chunking detectará las partes del fichero que no se hayan modificado y no será necesario volverlas a subir. Por otro lado, el coste computacional será mucho más intensivo cuando los clientes realicen la partición del fichero, pero estamos hablando del orden de segundos para poder obtener un ahorro en el almacenamiento de hasta el 30 El chunking basado en contenidos que se implementará será el TTTD (Two Thersholds Two Divisors). Es un algoritmo el que hay que especificar los tamaños mínimos y máximos del chunk (dos límites). Emepzando desde el pimer byte del fichero, se va leyendo byte a byte hasta que se llega al tamaño mínimo del chunk. En ese momento se calcula el hash del chunk y este se calcula el módulo del hash por un valor principal y otro secundario (dos divisores). Si el resultado es igual al divisor-1, significa que el el chunk se tiene que partir por ahí. En la figura 4.6 se puede ver el peor escenario para un chunking estático. Añadir un byte al principio del fichero hará que todos los chunks sean diferentes al de la versión anterior porque se han desplazado todos los bytes. En cambio con el chunking dinámico el único chunk que se vería afectado sería el primero, una vez se encuentre el punto de corte con los divisores, todos los demás chunks serán los mismos y no será necesario subirlos al Cloud. Chunk 1 Chunk 2 Chunk 3 Chunk 4 Chunk 5 Figure 4.6: Chunking estático. En el algoritmo 2 se muestra el pseudocódigo del algoritmo del TTTD. 30

31 4.2 StackSync: el cliente De pull a push En la versión inicial de StackSync se utilizaba una estrategia pull con un fichero update. Para cambiar a un modelo push habrá que realizar bastante cambios a nivel conceptual y de código en el cliente. Primero se eliminarán todos los procesos del cliente encargados de descargar el fichero update y los que se encargan de procesarlo. Para poder convertir el cliente al modelo push se tendrá que tener en cuenta los métodos que se implementarán en el SyncService para realizar la comunicación. Como hay llamadas asíncronas, será necesario crear un thread que esté esperando notificaciones. Cuando se reciba una notificación, esta tendrá que ser procesada para aplicar la actualización Base de datos El cliente tiene que mantener una base de datos interna para poder llevar un control de los ficheros que tiene y de las versiones de las que dispone. En la figura 4.7 se muestra el diagrama de la base de datos. Figure 4.7: Diagrama base de datos de StackSync Para realizar la persistencia de datos en el cliente se utilizará JPA (Java Persistence 31

32 4 Diseño API). De modo que las clases del código se podrán mapear directamente en la base de datos. Clonechunk: En esta tabla se guardan los chunks, el path indica la localización y el checksum es sobre el chunk. CloneFile: Esta tabla contiene la información de cada fichero que está sincronizado, aparece el path de su ubicación, el checksum del fichero, el identificador de la carpeta sincronizada, tamaño, un indicador si es carpeta, fechas de actualización, estados de sincronización... CloneFile clonechunk: Por cada fichero se guarda que chunks que forman parte del y el orden para posteriormente poder recuperar el fichero. Workspace: Contiene la informacin de los workspaces a los que tiene acceso el cliente Sincronización El ChangeManager es la clase que se encargada de aplicar el algoritmo de sincronización y resolución de conflictos. Cuando recibe un evento del SyncService aplica el pseudocódigo 3. Como se puede ver en el pseudocódigo, primero se comprobará si el identificador del fichero que se está sincronizando ya existe en la base de datos. Si efectivamente existe, se comprobará si los metadatos son correctos y según esto aplicar una actualización de un fichero o resolver el conflicto. Por otro lado, si el identificador no existe en la base de datos se comprobará si ya existe un fichero como ese en la carpeta sincronizada comparando el path del fichero y el nombre. Si el fichero no existe, se aplicará la cración del fichero, sino se solucionará el conflicto. 4.3 Servidor de actualizaciones Uno de los requisitos del cliente era que se pudiera actualizar remotamente. Para esto se va a implementar un servidor de actualizaciones que se podría ejecutar en el mismo SyncService. El servidor de actualziaciones tendrá una API Rest a la que se le podrá pedir qué número de version es el actual. Cuando StackSync obtenga estos datos lo comparará con la versión que tiene. Si la versión del srevidor es mayor pasará a descargarse la actualización del servidor. Cuando la actualización esté lista para instalarse, se detendrá el cliente, se instalará el nuevo cliente y se volverá a lanzar. Lo ideal es que todo este proceso sea lo más transparente posible al usuario. 32

33 4.4 Servidor de logs API Rest La API Rest de comunicación con el servidor de actualizaciones tendrá las siguientes llamadas: Versión Descripción: Devuelve la información de la version más actualizada del cliente StackSync. Estructura URL: https://domain.ext/stacksync/version Método: GET Cabecera: Ninguno Parametros: Ninguno Retona: Un diccionario JSON con clave version y valor el número de versión. Descargar actualización Descripción: Devuelve un fichero comprimido con la última versión del cliente. Estructura URL: https://domain.ext/stacksync/file Método: GET Cabecera: Ninguno Parametros: Ninguno Retona: En el cuerpo de la respuesta estará el contenido de la actualización en binario listo para ser guardado en un fichero Pseudocódigo El proceso que se encarga de actualizar StackSync no estará integrado en el cliente, sino que será un proceso a parte. Esto se hace para poder parar y relanzar el cliente antes y después de la actualización. En el pseudocódigo 4 se muestra qué hace este programa. 4.4 Servidor de logs Para poder recibir los errores que pueda lanzar el cliente, se va a implementar un servidor de logs. Este servidor tiene como objetivo recibir logs del cliente y guardarlos en una base de datos para que puedan ser revisados en un futuro. El formato de logs sera el siguiente: 33

34 4 Diseño [fecha] prioridad thread package.clase:linea - mensaje Los logs solo se envían cuando hay un error. En ese caso se comprimirá el fichero de logs, se enviará al servidor y finalmente se vaciará para empezar de nuevo API Rest Igual que en el caso del servidor de actulizaciones, aquí también se utiliza una API Rest para poder enviar los logs. Enviar logs Descripción: Envía y guarda los logs en el servidor. Estructura URL: https://domain.ext/stacksync/logs Método: PUT Cabecera: Será necesario una cabecera que indique el nombre de la máquina desde la que se envía. Parametros: Tendrá el parámetro type que indicará si el fichero está comprimido o esta en texto plano. Retona: 201 en caso correcto, código de error en cualquier otro caso Base de datos Para almacenar los logs se utilizará PostgreSQL. El diagrama de la base de datos se muestra en la figura 4.8 Computer: Representa el ordenador que ha reportado el error. Report: Representa un conjuto de logs con un error. Logs: Son los logs del cliente parseades. Un conjunto de logs forman parte de un mismo report. 34

35 4.4 Servidor de logs Figure 4.8: Diagrama de la base de datos de logs. 35

36 4 Diseño Algorithm 2 Pseudocódigo del algoritmo TTTD 1: function TTTD(input) 2: p = 0 3: l = 0 4: backupbreak = 0 5: while not EOF (input) do 6: c = getn extbyte(input) 7: hash = updatehash(c) 8: 9: if p 1 < T min then 10: //Not at minimum size yet 11: continue 12: end if 13: 14: if (hash%ddash) == (Ddash 1) then 15: //Possible backup break 16: backupbreak = p 17: end if 18: 19: if (hash%d) == (D 1) then 20: //Found a breakpoint 21: //before the maximum threshold 22: addbreakpoint(p) 23: backupbreak = 0 24: l = p 25: continue 26: end if 27: if (p 1) < T max then 28: //Fail to find a breakpoint, 29: //but we are not at the maximum yet 30: continue 31: end if 32: 33: //When we reach here, we have not found a breakpoint with 34: //the main divisor, and we are at the threshold. If there 35: //is a backup breakpoint use it. Otherwise impose a hard threshold. 36: if backupbreak! = 0 then 37: addbreakpoint(backupbreak) 38: l = backupbreak 39: backupbreak = 0 40: else 41: addbreakpoint(p) 42: l = p 43: backupbreak = 0 44: end if 45: p = p : end while 47: end function 36

37 4.4 Servidor de logs Algorithm 3 Pseudocódigo del algoritmo de sincronización 1: function ProcessEvent(event) 2: f ile metadata = event.get f ile metadata 3: if file ID in DB(file metadata) then 4: if correct version then 5: apply update 6: else 7: apply conf lict 8: end if 9: else 10: if exist file locally then 11: apply conf lict 12: else 13: apply new 14: end if 15: end if 16: end function Algorithm 4 Pseudocódigo del proceso de actualización de StackSync 1: function updatestacksync 2: launch stacksync 3: new version = get server version 4: curren version = get client version 5: if new version available then Need to update the client 6: download update 7: stop stacksync 8: replace f iles 9: relaunch stacksync 10: end if 11: end function 37

38

39 5 Implementación En este apartado se explicarán aspectos de la implementación de las diferentes partes de la arquitectura. También se comentarán problemas que han ido saliendo sobre el desarrollo y como se han solucionado. 5.1 OpenStack Swift Para tener una plataforma de pruebas que permita desarrollar y realizar pruebas realistas con algunos usuarios se ha instalado Swift en un Rack Elección de hardware Un hardware adecuado para OpenStack Swift tiene que cumplir los siguientes requisitos: Tener mucho espacio de almacenamiento, ya que este es el objetivo principal de Swift. Los Storage Nodes no requieren mucha potencia de cálculo, a diferencia del Proxy Node, que tiene que procesar todas las peticiones de los usuarios. Tener una buena refrigeración para no tener problemas de temperaturas. Disponer de mecanismos de alimentación redundantes y seguros para evitar apagones inesperados. A partir de estos requisitos se generaron algunos presupuestos con varias configuraciones. Finalmente se decidió adquirir seis servidores: dos Proxy Nodes y cuatro Storage Nodes. Las características se especifican a continuación: Proxy node: Ubuntu LTS(64 bits); Intel(R) Xeon(R) CPU 2.20GHz 4 cores/8 threads ; Memory: 12 GB. Storage nodes: Ubuntu LTS(64 bits); Intel(R) Xeon(R) CPU 1.80GHz 4 cores/4threads; Memory: 8GB. Además también se ha adquirido un rack pensado para posibles futuras expansiones de la plataforma y un switch para crear la red interna de los nodos. 39

40 5 Implementación Todo el rack se ha alojado en el CPD de la Universitat Rovira i Virgili para asegurar una buena refrigeración de los coponentes y que no haya caidas de tensión que dejen el sistema inaccesible Gestión de usuarios Facilitar la gestión de usuarios es necesario en un Personal Cloud, así que se ha desarrolado un script que se encarga de crear usuarios en Swift e inicializarlos en el SyncService. 5.2 SyncService El leguaje de programación para desarrollar el SyncService ha sido Java. Se ha utilizado Eclipse y el plugin de Maven para su desarrollo. Maven es una herramienta de software para la gestión y construcción de proyectos Java. Igual que Apache Ant necesita el fichero build.xml para especificar la configuración de construcción del proyecto, Maven utiliza el fichero POM.xml. La decisión de utilizar Maven fue la facilidad que da a la hora de importar librerias. Se añaden las dependencias en el fichero POM.xml y Maven de forma automática las descarga. De esta forma no hace falta subir las librerías al servidor de Subversion que se utiliza como repositorio de código Estructura del código La estructura del código sigue las especificaciones de Maven. El código se ha estructurado en los siguientes paquetes: com.stacksync.syncservice: Contiene la clase principal del proyecto. punto de inicio de la ejecución. Es el com.stacksync.syncservice.db: Contiene las clases de la base de datos genéricas, es decir, las factorias del DAO y las interfaces. com.stacksync.syncservice.db.postgresql: Contiene la implementación despecífica de PostgreSQL del DAO. com.stacksync.syncservice.handler: contien com.stacksync.syncservice.exceptions: que se han creado para el SyncService. Contien las excepciones específicas com.stacksync.syncservice.model: Contiene los modelos utilizados para agrupar los datos en objetos. com.stacksync.syncservice.omq: Contiene las clases de comunicación con ObjectMQ. 40

41 5.2 SyncService com.stacksync.syncservice.util: Contiene clases que ofrecen métodos genéricos y utilizados en varias clases Parámetros Para lanzar el servicio se necesitan mucho parámetros, los quales pueden variar para modificar el comportamiento del servidor. Algunos de estos parámetros son: Datos de la base de datos (puerto, servidor, base de datos...) Datos de ObjectMQ. Número de threads del SyncService para atender peticiones de los clientes. Inicialmente estos parámetros se especificaban en una clase del paquete utils, pero se tenía el problema de que el modificar una variable requería recompilar el código para aplicar los cambios. Para resolver este problema se ha implementado un mecanismo para cargar parámetros desde un fichero de texto. Cuando se ejecuta el servidor se puede elegir la opción de que cree un fichero base con los parámetros configurables y sus valores por defecto. Si no se encuentra un parámetro en el fichero, se utilizará su valor por defecto. Todos estos parámetros son guardados en una clase Properties de Java Base de datos Como ya se ha comentado anteriormente, la base de datos es uno de los puntos débiles de la arquitectura. Utilizar consultas ineficientes o hacer un mal diseño de tablas puede hacer que el rendimiento de todo el sistema decaiga. DAO En la fase de especificaciones del proyecto se creó el diagrama de clases del DAO. La clase DatabaseDAO.java era la interfaz que tenía las funciones para acceder a la base de datos. Cuando se empezó con el desarrollo, esta clase creció mucho debido a la cantidad de consultas diferentes que se tenían que hacer a la base de datos. Al refactorizar el código se decidió modificar ligeramente el DAO para hacer más fácil el desarrollo de nuevos conectores y, sobretodo, dar claridad al código. Como la clase DatabaseDAO.java contenía funciones que accedían a todas las tablas de la base de datos del SyncService, se cambió el paradigma y se creó una clase por cada tabla. En la figura 5.1 se puede ver el nuevo diseño del DAO. Con esta solución, la clase DeviceDAO.java contiene los métodos que se muestran en la figura 5.2. Como se puede observar, esta es una forma más sencilla e intuitiva de comunicarse con la base de datos. 41

42 5 Implementación com.stacksync.syncservice.db DAOFactory +getuserdao(type:string): UserDAO +getdevicedao(type:string): DeviceDAO +getworkspacedao(type:string): WorkspaceDAO +getobjectdao(type:string): ObjectDAO +getobjectversiondao(type:string): ObjectVersionDAO com.stacksync.syncservice.db.postgresql <<interface>> UserDAO +add(user:user) +update(user:user) +remove(id:long) PGUserDAO +add(user:user) +update(user:user) +remove(id:long) <<interface>> DeviceDAO +add(device:device) +update(device:device) +remove(id:long) PGDeviceDAO +add(device:device) +update(device:device) +remove(id:long) <<interface>> WorkspaceDAO +add(workspace:workspace) +update(workspace:workspace) +remove(id:long) PGWorkspaceDAO +add(workspace:workspace) +update(workspace:workspace) +remove(id:long) <<interface>> ObjectDAO +add(object:object) +update(object:object) +remove(id:long) PGObjectDAO +add(object:object) +update(object:object) +remove(id:long) <<interface>> ObjectVersionDAO +add(objectversion:objectversion) +update(objectversion:objectversion) +remove(id:long) PGObjectVersionDAO +add(objectversion:objectversion) +update(objectversion:objectversion) +remove(id:long) Figure 5.1: Nuevo diagrama de clases del DAO. public interface DeviceDAO { public Device findbyprimarykey(long id) throws DAOException; public Device findbyname(string name) throws DAOException; public Collection<Device> findall() throws DAOException; public void add(device device) throws DAOException; public void update(device device) throws DAOException; public void delete(long id) throws DAOException; } Figure 5.2: Interfaz DeviceDAO.java Consultas y funciones Cada una de las funciones de la figura 5.2 tiene que ser implementada con las consultas a PostgreSQL. 42

43 5.2 SyncService Continuando con el ejemplo del DeviceDAO, se puede ver la implementación del método findbyprimarykey en la figura public Device findbyprimarykey(long deviceid) throws DAOException { ResultSet resultset = null; Device device = null; String query = SELECT FROM device WHERE id =? ; try { resultset = executequery(query, new Object[] { deviceid }); if (resultset.next()) { device = mapdevice(resultset); } } catch (SQLException e) { throw new DAOException(e); } } return device; Figure 5.3: Método findbyprimarykey de la clase DeviceDAO. La forma de estos métodos es siempre el mismo: se define la consulta, se ejecuta, se mapea el resultado en un modelo y se retorna. Hay consultas más complejas como la que se encarga de devolver los metadatos de la última versión de todos los ficheros de un workspace. En la figura 5.4 se puede ver la consulta utilizada para este propósito. Lo que se está haciendo es un INNER JOIN (unión) de tres tablas (worpsace, object, object version). Primero se unen la tabla object con workspace para obtener los objetos que pertenencen a un workspace específico y ese resultado se une con la tabla object version con la condición de que la última versión del objeto sea igual al número de versión del object version. SELECT o., ov., get chunks ( ov. id ) AS chunks FROM workspace w INNER JOIN o b j e c t o ON w. id = o. workspace id INNER JOIN o b j e c t v e r s i o n ov ON o. id = ov. o b j e c t i d AND o. l a t e s t v e r s i o n = ov. v e r s i o n WHERE w. client workspace name =? GROUP BY o. id, ov. id Figure 5.4: Consulta SQL que retorna la última versión de un workspace. Además de consultas a la base de datos, también se han creado funciones para poder facilitar algunas consultas. En la figura 5.4 se puede ver la función get chunks a la que se le pasa como parámetro el identificador del object version. Esta función lo que haces es obtener todos los chunks de una versión y los devuelve en una lista ordenada. De esta forma el cliente los recibe ya ordenados. En la figura

44 5 Implementación se puede ver la implementación de esta función. CREATE OR REPLACE FUNCTION get chunks ( b i g i n t, OUT r e s u l t t e x t [ ] ) RETURNS t e x t [ ] AS $BODY$ BEGIN SELECT INTO r e s u l t a r r a y c a t (ARRAY [ ] : : character varying [ ], array agg ( client chunk name ) ) AS chunks FROM ( SELECT ovc. client chunk name FROM o b j e c t v e r s i o n c h u n k ovc WHERE ovc. o b j e c t v e r s i o n i d = $1 ORDER BY ovc. chunk order ASC ) AS foo ; END; $BODY$ Figure 5.5: Función get chunks Integración con ObjectMQ Para hacer que la comunicación se realize sobre ObjectMQ se tiene que crear la interfaz que procesará los eventos del cliente. Esta interfaz se importará en el SyncService y en StackSync, pero sólo el SyncService tendrá que hacer la implementación de la misma. En la figura 5.6 se puede ver los métodos a implementar. Hay otra interfaz (figura 5.7)que es la encargada de notificar los eventos a los clientes. Así que después de procesar un commit, el SyncService tendrá que llamar a la función notifycommit para propagar el evento a los clientes del workspace. 5.3 StackSync Chunker Para seguir con la filosofía modular de StackSync, se ha desarrollado una factoría para que se pueda elegir qué tipo de chunking se quiere aplicar. Al contrario que en el SyncService, aquí no se da la opción de poder cambirlo sin tener que recompilar el código porque los dos métodos no son compatibles entre ellos. 44

45 5.3 public interface ISyncService extends Remote { / Returns a list containing all metadata objects in a workspace for a given user The ID of the requestid Used for the client to identify the workspace The ID of the A list of ObjectMetadata} = 3, timeout = 5000) public List<ObjectMetadata> getchanges(string user, String requestid, WorkspaceInfo workspace); / Returns a list containing all workspaces for a given user The ID of the requestid Used for the client to identify the A list of WorkspaceInfo} = 3, timeout = 5000) public List<WorkspaceInfo> getworkspaces(string user, String requestid); } / Function used to commit new versions of user The ID of the requestid Used for the client to identify the workspace The ID of the device The ID of the commitobjects List of ObjectMetadata} with the newly modified objects public void commit(string user, String requestid, WorkspaceInfo workspace, String device, List<ObjectMetadata> commitobjects); Figure 5.6: Interfaz de comunicación con el public interface RemoteWorkspace extends Remote void notifycommit(commitresult commitresult); Figure 5.7: Interfaz de comunicación con el SyncService. El diagrama de clases que se ha desarrollado se puede ver en la figura 5.8. La clase Chunker es la que se instanciará desde el Indexer, al llamar al método createchunks se devolverá un objeto que extienda de la clase ChunkEnumeration. Después están las clases StaticChunker y TTTDChunker que son las encargadas de hacer los chunks estáticos y dinámicos respectivamente. Ambas heredan de la clase ChunkEnumeration, la qual implementa la interfaz de Enumeration de Java. 45

46 5 Implementación com.stacksync.client.chunker Chunker +createfilechecksum(file:file): String +createchunks(file:file,type:string): ChunkEnumeration FileChunk +checksum: String +contentes: byte[] +number: long +filechecksum: long +size: long +closestream() ChunkEnumeration<FileChunk> +closestream() Enumeration<E> +hasmoreelements() +nextelement() com.stacksync.client.chunker.static com.stacksync.client.chunker.tttd StaticChunking +hasmoreelements() +nextelement() TTTDChunking +Tmin: int +Tmax: int +D: int +Ddash: int +hasmoreelements() +nextelement() RollingChecksum +calculatechecksum(bt:byte): logn +reset() +getvalue(): long +trim() Figure 5.8: Diagrama de clases de los paquetes de chunking Integración con ObjectMQ Para integrar ObjectMQ con StackSync se tiene que importar el mismo jar que se ha importado en el SyncService. Como se puede ver en la arquitectura mostrada en el diseño, es la clase Uploader la que se encarga de notificar las actualizaciones al servidor. Así que simplemente tiene que utilizar las funciones de la interfaz que se explica en la implementación del SyncService. En cambio, el cliente tiene que implementar la interfaz del RemoteWorkspace, más concretamente la función notifycommit. De esto se encarga la clase EventListener, que es la encargada de recibir las notificaciones y tratarlas. En una misma notificación puede haber más de una actualización, así que se va objeto por objeto leyendo los metadatos y encolándolos a la cola de proceso de la clase ChangeManager, la cual se encarga de procesar la actualización Instalador Para crear el instalador se ha utilizado NSIS (Null Scriptable Install System), una aplicación open source diseñada para ser simple pero efectiva. El objetivo del instalador es hacerlo lo más sencillo posible, cuanto menos cosas tenga 46

47 5.3 StackSync que cambiar el usuario mejor. Igual que el instalador de Dropbox, el que se desarrolle tampoco permitirá al usuario cambiar la el directorio de instalación, el cual estará bajo la carpeta AppData/Roaming del usuario. Durante la instalación se configurará que el cliente se ejecute al iniciar Windows, se creará un acceso directo en el inicio y otro en el explorador de ficheros. También se preparará un desinstalador de la aplicación. ; Create s h o r t c u t s C r e a t e D i r e c t o r y $SMPROGRAMS\ StackSync CreateShortCut $SMPROGRAMS\ StackSync \ U n i n s t a l l. lnk $INSTDIR\ U n i n s t a l l. exe CreateShortCut $SMPROGRAMS\ Stacksync \ StackSync. lnk $INSTDIR\ StackSync. j a r $INSTDIR\ r e s \ l o go48. i c o 0 CreateShortCut $DESKTOP\ StackSync. lnk $INSTDIR\ StackSync. j a r $INSTDIR\ r e s \ l o go48. i c o 0 CreateShortCut $SMSTARTUP\ StackSync. lnk $INSTDIR\ StackSync. j a r $INSTDIR\ r e s \ l o go48. i c o 0 Figure 5.9: Código del instalador para crear los accesos directos. Como el cliente requiere de Java 1.6 o superior, el instalador tiene que comprobar si está instalado en el sistema. Para eso se tendrá que acceder al registro de Windows. En caso de que no esté instalado, se notificará al usuario el problema para que pueda solucionarlo. En la figura 5.10 se puede per como se comprueba el registro y en caso de que no se encuntre ninguna versión de Java se muestra el mensaje de error al usuario. Function DetectJRE! d e f i n e JAVAEXE javaw. exe ReadRegStr $R0 HKLM SOFTWARE\ JavaSoft \ Java Runtime Environment CurrentVersion StrCmp $R0 DetectTry2 0 ReadRegStr $R1 HKLM SOFTWARE\ JavaSoft \ Java Runtime Environment \$R0 JavaHome StrCpy $R1 $R1\ bin \ ${JAVAEXE} goto JavaFound DetectTry2 : ReadRegStr $R0 HKLM SOFTWARE\ JavaSoft \ Java Development Kit CurrentVersion StrCmp $R0 NotDetected ReadRegStr $R1 HKLM SOFTWARE\ JavaSoft \ Java Development Kit \$R0 JavaHome StrCpy $R1 $R1\ bin \ ${JAVAEXE} goto JavaFound NotDetected : Messagebox MB OK MB ICONSTOP Java not found. Please, i n s t a l l i t. Quit JavaFound : FunctionEnd Figure 5.10: Código del instalador para detectar Java en el sistema. En las siguientes capturas se puede ver la interficie gráfica del instalador. 47

48 5 Implementación Figure 5.11: Capturas del instalador 5.4 Servidor de actualizaciones Para implementar la API REST en el lado del servidor se ha utilizado Tonic, una aplicación web desarrollada en PHP que se ha diseñado para facilitar la craeción de APIs. Para hacer funcionar esta aplicación, se tiene que tener instalado un servidor Apache2, tener instalado PHP5 y activar el módulo rewrite de Apache. Cuando se cumplan todos estos requisitos se tendrá que crear un fichero PHP con una clase en la que se especificará qué llamadas se soportarán y a qué recursos se tendrá acceso. En la figura 5.12 se puede ver el código de que procesa la petición que se hace para obtener la última versión del cliente. /version/([0 9] [. 0 9] ) / class Version extends Resource @return Tonic\Response / public function getversion() { $version = $this >getcurrentversion(); } return new Response(200, array( version => $version )); Figure 5.12: Código de la API REST implementada para el sistema de actualizaciones. 48

STACKSYNC UNA SOLUCIÓN DE CLOUD STORAGE A MEDIDA Y SEGURO

STACKSYNC UNA SOLUCIÓN DE CLOUD STORAGE A MEDIDA Y SEGURO STACKSYNC UNA SOLUCIÓN DE CLOUD STORAGE A MEDIDA Y SEGURO JORNADAS TÉCNICAS REDIRIS 2013 IVAN.UTGE@URV.CAT 2 Índice 1. Origen de la idea: Cloudspaces 2. Introducción a StackSync 3. Arquitectura 4. Comparativa

Más detalles

CURSOS DE VERANO 2014

CURSOS DE VERANO 2014 CURSOS DE VERANO 2014 CLOUD COMPUTING: LA INFORMÁTICA COMO SERVICIO EN INTERNET LA PLATAFORMA GOOGLE CLOUD PLATFORM. GOOGLE APP ENGINE Pedro A. Castillo Valdivieso Universidad de Granada http://bit.ly/unia2014

Más detalles

Plantilla para las VIII Jornadas de SIG libre.

Plantilla para las VIII Jornadas de SIG libre. VIII JORNADAS DE SIG LIBRE Plantilla para las VIII Jornadas de SIG libre. M. Arias de Reyna Domínguez (1) (1) Ingeniera Informática, GeoCat bv, Bennekom, Países Bajos, maria.arias@geocat.net RESUMEN GeoCat

Más detalles

Cloud Computing. Rodrigo Moreno Rosales DN-11

Cloud Computing. Rodrigo Moreno Rosales DN-11 Cloud Computing Rodrigo Moreno Rosales DN-11 Cloud Computing La computación en la nube,conocido también como servicios en la nube, informática en la nube, nube de cómputo o nube de conceptos, es un paradigma

Más detalles

CL_50466 Windows Azure Solutions with Microsoft Visual Studio 2010

CL_50466 Windows Azure Solutions with Microsoft Visual Studio 2010 Windows Azure Solutions with Microsoft Visual Studio 2010 www.ked.com.mx Av. Revolución No. 374 Col. San Pedro de los Pinos, C.P. 03800, México, D.F. Tel/Fax: 52785560 Introducción Este curso es una introducción

Más detalles

UNIDAD 3: SEGURIDAD PASIVA: ALMACENAMIENTO

UNIDAD 3: SEGURIDAD PASIVA: ALMACENAMIENTO UNIDAD 3: SEGURIDAD PASIVA: ALMACENAMIENTO 1. Estrategias de almacenamiento Para una empresa, la parte más importante de la informática son los datos: sus datos. Porque: El hardware es caro. Si una máquina

Más detalles

PROTOCOLO DE TRANSFERENCIA DE ARCHIVOS. (FTP)

PROTOCOLO DE TRANSFERENCIA DE ARCHIVOS. (FTP) PROTOCOLO DE TRANSFERENCIA DE ARCHIVOS. (FTP) AUTORÍA ÁNGEL LUIS COBO YERA TEMÁTICA SERVICIOS DE INTERNET ETAPA BACHILLERTATO, CICLOS FORMATIVOS. Resumen En este artículo, se explican los conceptos necesarios

Más detalles

Servicios Cloud Almacenamiento en la Nube

Servicios Cloud Almacenamiento en la Nube ECBTI Curso Herramientas Teleinformáticas-221120 Servicios Cloud Almacenamiento en la Nube Red tutores del curso Agenda Almacenamiento en la Nube Ventajas y Desventajas Herramientas Cloud de Almacenamiento

Más detalles

IVista: es la interfaz con la que el Presentador se comunica con la vista.

IVista: es la interfaz con la que el Presentador se comunica con la vista. Capítulo 3 MODELO DE DISEÑO 3.1 Arquitectura Modelo-Vista-Presentador La arquitectura Modelo-Vista-Presentador (MVP) [11] separa el modelo, la presentación y las acciones basadas en la interacción con

Más detalles

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com Modelos de los sistemas distribuidos Jorge Iván Meza Martínez jimezam@gmail.com Especialización en Gestión de Redes de Datos Universidad Nacional de Colombia Sede Manizales 1/36 Contenidos Modelo arquitectónico

Más detalles

CONSIDERACIONES A TENER EN CUENTA PARA LA GESTION DE COPIAS DE SEGURIDAD

CONSIDERACIONES A TENER EN CUENTA PARA LA GESTION DE COPIAS DE SEGURIDAD CONSIDERACIONES A TENER EN CUENTA PARA LA GESTION DE COPIAS DE SEGURIDAD El proceso de copias a través de Internet es relativamente lento, tenga en cuenta que va a utilizar la velocidad de subida.más información

Más detalles

Acoplamiento e interoperabilidad

Acoplamiento e interoperabilidad Máster Universitario en Ingeniería Informá3ca Acoplamiento e interoperabilidad Sistemas de Información Orientados a Servicios RODRIGO SANTAMARÍA 2 Acoplamiento débil Tipos de acoplamiento Cabalgando el

Más detalles

Cloud computing: El servicio de almacenamiento en la nube

Cloud computing: El servicio de almacenamiento en la nube Cloud computing: El servicio de almacenamiento en la nube www.sevensheaven.nl Alicia Rey, Info-doc, Gestión de la información INDICE 1.Qué es el Cloud computing: 1.1 Consideraciones previas 1.2 El concepto

Más detalles

ÍNDICE 1. INTRODUCCIÓN... 4 1.1 MODOS DE ACCESO AL SISTEMA... 4 1.2 PERFILES DE USUARIO... 4 2. APLICACIÓN CLIENTE... 5

ÍNDICE 1. INTRODUCCIÓN... 4 1.1 MODOS DE ACCESO AL SISTEMA... 4 1.2 PERFILES DE USUARIO... 4 2. APLICACIÓN CLIENTE... 5 MANUAL DE USUARIO ÍNDICE 1. INTRODUCCIÓN... 4 1.1 MODOS DE ACCESO AL SISTEMA... 4 1.2 PERFILES DE USUARIO... 4 2. APLICACIÓN CLIENTE... 5 2.1 REQUISITOS MÍNIMOS DE USO DEL SERVICIO... 5 2.1.1 REQUISITOS

Más detalles

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 1: Tareas Iniciales. Virtualización

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 1: Tareas Iniciales. Virtualización Ministerio de Educación, Cultura y Deporte Aulas en Red. Windows Módulo 1: Tareas Iniciales. Virtualización Aulas en red. Aplicaciones y servicios. Windows Virtualización En numerosas ocasiones necesitamos

Más detalles

Alojamiento web gratuito

Alojamiento web gratuito Alojamiento web gratuito 3. Alojamiento web gratuito Sin dejar de tener en cuenta que un alojamiento web gratuito no será el más adecuado para mantener un sitio web de calidad, sí podemos disponer de alguno

Más detalles

CURSOS DE VERANO 2014

CURSOS DE VERANO 2014 CURSOS DE VERANO 2014 CLOUD COMPUTING: LA INFORMÁTICA COMO SERVICIO EN INTERNET La plataforma Google Cloud Platform. Google App Engine Pedro A. Castillo Valdivieso Universidad de Granada La plataforma

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Seminario. Cloud Computing. Granada, 20 al 22 de febrero de 2013

Seminario. Cloud Computing. Granada, 20 al 22 de febrero de 2013 Seminario Cloud Computing Granada, 20 al 22 de febrero de 2013 1 Plataformas Open Source para Cloud Computing Sergio Alonso (zerjioi@ugr.es) Universidad de Granada Seminario Cloud Computing Contenidos

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Planos de ejecución en Velneo V7

Planos de ejecución en Velneo V7 Planos de ejecución en Velneo V7 Por Jesús Arboleya Introducción 3 Arquitectura Cliente/Servidor 4 1. Objetos que siempre se ejecutan en el servidor 5 2. Objetos que siempre se ejecutan en el cliente 6

Más detalles

Programación en Capas.

Programación en Capas. Programación en Capas. Ricardo J. Vargas Del Valle Universidad de Costa Rica, Ciencias de Computación e Informática, San José, Costa Rica, 506 ricvargas@gmail.com Juan P. Maltés Granados Universidad de

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

CENTRO DE DATOS Y POP

CENTRO DE DATOS Y POP Virtual y física. Pública y privada. Por horas o por meses. Nuestra plataforma unificada proporciona infraestructuras en la nube a nivel de Internet. Todo lo que quiera, desplegado bajo demanda y en tiempo

Más detalles

Ministerio de Educación, Cultura y Deporte. HTML5 en la educación. Módulo 8: Publicación.

Ministerio de Educación, Cultura y Deporte. HTML5 en la educación. Módulo 8: Publicación. Ministerio de Educación, Cultura y Deporte. HTML5 en la educación Módulo 8: Publicación. Instituto Nacional de Tecnologías Educativas y de Formación del Profesorado 2012 Publicación de un proyecto web

Más detalles

Escritorios Remotos 1. RDP

Escritorios Remotos 1. RDP Escritorios Remotos 1. RDP RDP (Remote Desktop Protocol = Protocolo de Acceso a un Escritorio Remoto) es un protocolo desarrollado por Microsoft que permite manipular, de manera remota, el escritorio de

Más detalles

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 6: Servicio Copias de seguridad

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 6: Servicio Copias de seguridad Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows Módulo 6: Servicio Copias de seguridad Aulas en red. Aplicaciones y servicios. Windows Servicio Copias de Seguridad En este instante ya

Más detalles

Introducción a OpenStack

Introducción a OpenStack Introducción a OpenStack Proyecto de Innovación. Implantación y puesta a punto de la infraestructura de un cloud computing privado para el despliegue de servicios en la nube IES Gonzalo Nazareno Dos Hermanas

Más detalles

Indice 1. Introducción a la computación en nube (cloud computing)

Indice 1. Introducción a la computación en nube (cloud computing) Tema 9. Centros de datos: computación en nube y organización física Indice 1. Introducción a la computación en nube (cloud computing) 2. Virtualización de recursos: consolidación de servidores 3. Arquitectura

Más detalles

Cloudbuilder Next. Ventajas y características. Descubre todas sus funcionalidades. Índice

Cloudbuilder Next. Ventajas y características. Descubre todas sus funcionalidades. Índice Cloudbuilder Next Ventajas y características Descubre todas sus funcionalidades Índice 1. La solución más sólida del mercado 2. Qué es Cloudbuilder Next? 3. Qué ventajas aporta Cloudbuilder Next? 4. Qué

Más detalles

Sistemas de Información para la Gestión

Sistemas de Información para la Gestión Sistemas de Información para la Gestión UNIDAD 2: RECURSOS DE TI Bases de Datos UNIDAD 2: RECURSOS DE TECNOLOGÍA DE INFORMACIÓN Información 1. La Información: Propiedades de la Información. Sistemas de

Más detalles

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 5: Servicio Microsoft Exchange

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 5: Servicio Microsoft Exchange Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows Módulo 5: Servicio Microsoft Exchange Aulas en red. Aplicaciones y servicios. Windows Servicio Correo Electrónico En este apartado procederemos

Más detalles

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 1: Tareas Iniciales. Instalación Servidor

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 1: Tareas Iniciales. Instalación Servidor Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows Módulo 1: Tareas Iniciales. Instalación Servidor Aulas en red. Aplicaciones y servicios. Windows Windows Server 2008 En este apartado de

Más detalles

9243059 Edición 1 ES. Nokia y Nokia Connecting People son marcas comerciales registradas de Nokia Corporation

9243059 Edición 1 ES. Nokia y Nokia Connecting People son marcas comerciales registradas de Nokia Corporation 9243059 Edición 1 ES Nokia y Nokia Connecting People son marcas comerciales registradas de Nokia Corporation Cliente de VPN Guía de usuario 9243059 Edición 1 Copyright 2005 Nokia. Reservados todos los

Más detalles

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 4: Servicios de Internet. FTP

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 4: Servicios de Internet. FTP Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows Módulo 4: Servicios de Internet. FTP Aulas en red. Aplicaciones y servicios. Windows Servicio FTP Con anterioridad, en este mismo módulo

Más detalles

Respaldo Cloud. Preguntas Frecuentes. Versión 1.0

Respaldo Cloud. Preguntas Frecuentes. Versión 1.0 Respaldo Cloud Preguntas Frecuentes Versión 1.0 1. Contenidos Manual de usuario para Respaldo Cloud 1 GENERAL... 4 1.1 Qué es Respaldo Cloud?... 4 1.2 Qué necesito para usar Respaldo Cloud?... 4 1.3 Cuáles

Más detalles

PROYECTO REALIZADO POR: ENTIDAD GESTORA: COFINANCIADO POR:

PROYECTO REALIZADO POR: ENTIDAD GESTORA: COFINANCIADO POR: CLOUD COMPUTING PROYECTO REALIZADO POR: ENTIDAD GESTORA: COFINANCIADO POR: 1. Introducción 1. Qué es el Cloud Computing? La computación en nube es un sistema informático basado en Internet y centros de

Más detalles

TFM Comunicación, Redes y Gestión de Contenidos

TFM Comunicación, Redes y Gestión de Contenidos TFM Comunicación, Redes y Gestión de Contenidos Aplicación móvil hibrida para control de asistencia y servicio técnico a domicilio y gestión de partes de trabajo Autor: Patricia Paguay Lara Tutorizado

Más detalles

aspectos y no estaríamos donde estamos hoy, si hubiéramos utilizado otra herramienta.

aspectos y no estaríamos donde estamos hoy, si hubiéramos utilizado otra herramienta. 4D es una plataforma de aplicación Web, flexible, potente y muy escalable. Este documento examina los requerimientos comunes para servidores de aplicación Web, y discute las ventajas ofrecidas por la línea

Más detalles

APLICATECA. Guía para la contratación y gestión de. Servidor Cloud

APLICATECA. Guía para la contratación y gestión de. Servidor Cloud APLICATECA Guía para la contratación y gestión de Servidor Cloud INDICE 1 QUÉ ES SERVIDOR CLOUD?... 1 1.1 PARA QUÉ SIRVE?... 1 1.2 CARACTERÍSTICAS DE SERVIDOR CLOUD... 2 2 CONTRATACIÓN DE SERVIDOR CLOUD...

Más detalles

OPC Server PS/PSS MANUAL DE INSTRUCCIONES

OPC Server PS/PSS MANUAL DE INSTRUCCIONES SERVIDOR DE COMUNICACIONES OPC Server PS/PSS Versión 1.4 MANUAL DE INSTRUCCIONES (M98222901-03-13A) CIRCUTOR S.A. OPC Server PS/ PSS -1- ÍNDICE 1.- INSTALACIÓN DEL SERVIDOR OPC POWERSTUDIO / SCADA... 3

Más detalles

SISTEMAS OPERATIVOS EN RED. UT. 05 Utilidades de administración. ÍNDICE

SISTEMAS OPERATIVOS EN RED. UT. 05 Utilidades de administración. ÍNDICE ÍNDICE 1. Perfiles de usuarios. 2.1. Perfiles móviles variables. 2.2. Perfiles obligatorios. 2. Administración de discos. 2.1. Configuraciones de disco. 2.1.1. Discos Básicos. 2.1.2. Discos Dinámicos 2.2.

Más detalles

Tema 4. Diseño arquitectónico.

Tema 4. Diseño arquitectónico. Tema 4. Diseño arquitectónico. Introducción, Objetivos del Diseño. Ingeniería del Software II 2011 Para la transformación del modelo de análisis en un modelo de diseño del sistema, se definen los objetivos

Más detalles

Versión 4.0 BOLETÍN (ABRIL 2010) a2 Herramienta Administrativa Configurable (Arquitectura Cliente Servidor) a2 softway C. A.

Versión 4.0 BOLETÍN (ABRIL 2010) a2 Herramienta Administrativa Configurable (Arquitectura Cliente Servidor) a2 softway C. A. Versión 4.0 BOLETÍN (ABRIL 2010) a2 Herramienta Administrativa Configurable (Arquitectura Cliente Servidor) a2 softway C. A. VERSIÓN 4.0 a2 Herramienta Administrativa Configurable e-mail a2softway@cantv.net

Más detalles

1. Introducción a LMD (LTSP Management for non-developers)

1. Introducción a LMD (LTSP Management for non-developers) 1. Introducción a LMD (LTSP Management for non-developers) 1.1. Qué es LMD (o LliureX LMD 2.0)? LliureX LMD es la adaptación del proyecto LTSP (Linux Terminal Server Project) para el soporte de clientes

Más detalles

Ficha Técnica del curso Online de Cloud Computing con Amazon Web Services (AWS)

Ficha Técnica del curso Online de Cloud Computing con Amazon Web Services (AWS) Ficha Técnica del curso Online de Cloud Computing con Amazon Web Services (AWS) Nombre del Curso: Curso Online de Cloud Computing con Amazon Web Services (AWS) Breve descripción del Curso: Este curso online

Más detalles

COUNTSTAR: ADMINISTRACIÓN Y GESTIÓN DE EMPRESA

COUNTSTAR: ADMINISTRACIÓN Y GESTIÓN DE EMPRESA Trabajo fin de carrera INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS Facultad de Matemáticas Universidad de Barcelona COUNTSTAR: ADMINISTRACIÓN Y GESTIÓN DE EMPRESA Óscar Llorente Lucía Director/a: Dra.

Más detalles

INSTALACIÓN DE ABIES 2 WEB PARA REALIZAR CONSULTAS SÓLO DESDE ORDENADORES DEL CENTRO ESCOLAR...5

INSTALACIÓN DE ABIES 2 WEB PARA REALIZAR CONSULTAS SÓLO DESDE ORDENADORES DEL CENTRO ESCOLAR...5 DE EDUCACIÓN SECRETARÍA DE ESTADO DE EDUCACIÓN Y FORMACIÓN DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONA INSTITUTO DE TECNOLOGÍAS EDUCATIVAS MANUAL DE ABIES 2 WEB CREDITOS: Versión 2.0 Fecha 13/10/2009 Autor/es

Más detalles

Guía de uso del Cloud Datacenter de acens

Guía de uso del Cloud Datacenter de acens guíasdeuso Guía de uso del Cloud Datacenter de Calle San Rafael, 14 28108 Alcobendas (Madrid) 902 90 10 20 www..com Introducción Un Data Center o centro de datos físico es un espacio utilizado para alojar

Más detalles

Universidad de Almería. Máster en Administración, Comunicaciones y Seguridad Informática CLOUD STORAGE. Autores: José Asta Alarcón

Universidad de Almería. Máster en Administración, Comunicaciones y Seguridad Informática CLOUD STORAGE. Autores: José Asta Alarcón Universidad de Almería Máster en Administración, Comunicaciones y Seguridad Informática CLOUD STORAGE Autores: José Asta Alarcón CLOUD STORAGE José Asta Alarcón Ingeniero Técnico Informático de Sistemas

Más detalles

REDES DE ÁREA LOCAL. APLICACIONES Y SERVICIOS EN WINDOWS

REDES DE ÁREA LOCAL. APLICACIONES Y SERVICIOS EN WINDOWS REDES DE ÁREA LOCAL. APLICACIONES Y SERVICIOS EN WINDOWS Escritorio remoto - 1 - Escritorio Remoto...- 3 - Definición de Escritorio Remoto... - 3 - Habilitar Escritorio Remoto... - 4 - Instalación del

Más detalles

BitTorrent Sync. Informe de Redes de Computadores ELO-322. Eduardo González 2921001-2. Marco Benzi 2803054-1 2803026-6

BitTorrent Sync. Informe de Redes de Computadores ELO-322. Eduardo González 2921001-2. Marco Benzi 2803054-1 2803026-6 BitTorrent Sync Informe de Redes de Computadores ELO-322 Marco Benzi 2803054-1 Eduardo González 2921001-2 Matías Müller 2803026-6 2 de septiembre de 2013 ÍNDICE Índice 1. Resumen 2 2. Introducción 2 2.1.

Más detalles

13º Unidad Didáctica. RAID (Redundant Array of Independent Disks) Eduard Lara

13º Unidad Didáctica. RAID (Redundant Array of Independent Disks) Eduard Lara 13º Unidad Didáctica RAID (Redundant Array of Independent Disks) Eduard Lara 1 RAID: INTRODUCCIÓN Sistema de almacenamiento que usa múltiples discos duros entre los que distribuye o replica los datos.

Más detalles

Redes de área local: Aplicaciones y servicios WINDOWS

Redes de área local: Aplicaciones y servicios WINDOWS Redes de área local: Aplicaciones y servicios WINDOWS 7. Escritorio remoto 1 Índice Definición de Escritorio Remoto... 3 Habilitar Escritorio Remoto... 4 Instalación del cliente de Escritorio Remoto...

Más detalles

CAPÍTULO NOVENO PUPPET

CAPÍTULO NOVENO PUPPET CAPÍTULO NOVENO PUPPET En el capítulo anterior se han mostrado las 4 herramientas de software libre más representativas para la gestión de configuraciones. Al finalizarlo se optó por elegir a Puppet como

Más detalles

serra Access y SQL Server Qué es mejor en cada caso? Valentín Playá, Serra GTS 22 de enero de 2009 Bases de datos 1

serra Access y SQL Server Qué es mejor en cada caso? Valentín Playá, Serra GTS 22 de enero de 2009 Bases de datos 1 Access y SQL Server Qué es mejor en cada caso? Valentín Playá, Serra GTS 22 de enero de 2009 Bases de datos 1 Bases de datos en una organización Distintas necesidades según el tipo de solución Ninguna

Más detalles

INSTALACION VIRTUALIZADA DE UBUNTU SERVER CON SERVICIOS LAMP Y OPENSSH SOBRE VIRTUAL BOX. Nicolás Botero Botero Juan Manuel Velásquez Isaza

INSTALACION VIRTUALIZADA DE UBUNTU SERVER CON SERVICIOS LAMP Y OPENSSH SOBRE VIRTUAL BOX. Nicolás Botero Botero Juan Manuel Velásquez Isaza INSTALACION VIRTUALIZADA DE UBUNTU SERVER CON SERVICIOS LAMP Y OPENSSH SOBRE VIRTUAL BOX Nicolás Botero Botero Juan Manuel Velásquez Isaza Universidad Tecnológica de Pereira Facultad de Ingenierías Ingeniería

Más detalles

III. INTRODUCCIÓN AL CLOUD COMPUTING

III. INTRODUCCIÓN AL CLOUD COMPUTING III. INTRODUCCIÓN AL CLOUD COMPUTING Definición (I) Qué es el cloud computing? Nuevo paradigma de computación distribuida Provee un servicio de acceso a recursos computacionales: servidores, almacenamiento,

Más detalles

UNIVERSIDAD DON BOSCO FACULTAD DE ESTUDIOS TECNOLÓGICOS ESCUELA DE COMPUTACIÓN

UNIVERSIDAD DON BOSCO FACULTAD DE ESTUDIOS TECNOLÓGICOS ESCUELA DE COMPUTACIÓN ues CICLO: 02/2013 UNIVERSIDAD DON BOSCO FACULTAD DE ESTUDIOS TECNOLÓGICOS ESCUELA DE COMPUTACIÓN GUIA DE LABORATORIO #2 Nombre de la Práctica: Instalación y configuración de Joomla Lugar de Ejecución:

Más detalles

MANUAL. J. Enrique Durán Colaborador TIC Huesca

MANUAL. J. Enrique Durán Colaborador TIC Huesca MANUAL ÍNDICE 1.- QUÉ ES DROPBOX. 2.- DESCARGA DE DROPBOX 3.- INTRODUCCIÓN 4.- ARCHIVOS 4.1.- INVITAR A CARPETA 4.2.- COMPARTIR VÍNCULO 4.3.- DESCARGAR 4.4.- ELIMINAR 4.5.- CAMBIAR NOMBRE 4.6.- MOVER 4.7.-

Más detalles

MANUAL DE USUARIO Guía de Gestión de la Configuración con Subversion

MANUAL DE USUARIO Guía de Gestión de la Configuración con Subversion MANUAL DE USUARIO Guía de Gestión de la Configuración con Subversion Versión 1.8 Área de Integración y Arquitectura de Aplicaciones Hoja de Control Título Documento de Referencia Responsable Guía de Gestión

Más detalles

Administración de Ficheros de Bases de Datos

Administración de Ficheros de Bases de Datos Administración de Ficheros de Bases de Datos Contenido Introducción 1 Introducción a las estructuras de datos 2 Creación de bases de datos 7 Administración de bases de datos 13 Colocación de archivos y

Más detalles

Instituto Tecnológico de Las América. Materia Sistemas operativos III. Temas. Facilitador José Doñe. Sustentante Robín Bienvenido Disla Ramirez

Instituto Tecnológico de Las América. Materia Sistemas operativos III. Temas. Facilitador José Doñe. Sustentante Robín Bienvenido Disla Ramirez Instituto Tecnológico de Las América Materia Sistemas operativos III Temas Servidor FTP Facilitador José Doñe Sustentante Robín Bienvenido Disla Ramirez Matricula 2011-2505 Grupo 1 Servidor FTP FTP (File

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización

Más detalles

CENTRO DE RESGUARDO ARQUITECTURA AVANZADA PROF.: JUAN JOSÉ MUÑOZ BUSSI AUTOR: MARIANA FERRETTO

CENTRO DE RESGUARDO ARQUITECTURA AVANZADA PROF.: JUAN JOSÉ MUÑOZ BUSSI AUTOR: MARIANA FERRETTO CENTRO DE RESGUARDO ARQUITECTURA AVANZADA PROF.: JUAN JOSÉ MUÑOZ BUSSI AUTOR: MARIANA FERRETTO CENTRO DE RESGUARDO Centro de Cómputos de Resguardo Sitio para reubicarse luego de un desastre Sitio manejado

Más detalles

Bonsai: consulta web del catálogo de la biblioteca

Bonsai: consulta web del catálogo de la biblioteca Bonsai: consulta web del catálogo de la biblioteca Manual de instalación, configuración y uso Versión 5.0 Julio 2009 Fernando Posada fernandoposada@gmail.com Índice 1. Qué es Bonsai?... 3 2. Requisitos

Más detalles

Cloud Computing: Cloud híbrida y la solución de AWS

Cloud Computing: Cloud híbrida y la solución de AWS Whitepaper Cloud Computing: Cloud híbrida y la solución de AWS BEE PART OF THE CHANGE hablemos@beeva.com www.beeva.com AÑADE EL VALOR DEL CLOUD A TUS PROYECTOS QUÉ ES CLOUD? Entendemos por Cloud todos

Más detalles

WHITE PAPER. Proteger sus servidores virtuales con Acronis True Image

WHITE PAPER. Proteger sus servidores virtuales con Acronis True Image Proteger sus servidores virtuales con Acronis True Image Copyright Acronis, Inc., 2000 2008 Las organizaciones dedicadas a la TI han descubierto que la tecnología de virtualización puede simplificar la

Más detalles

Almacenamiento en la nube: SkyDrive, Google Drive, Dropbox. Cuál elegir?

Almacenamiento en la nube: SkyDrive, Google Drive, Dropbox. Cuál elegir? Almacenamiento en la nube: SkyDrive, Google Drive, Dropbox. Cuál elegir? Ya no caben dudas, hay que mudarse a la nube. Este es un buen momento para comparar los tres servicios más populares para almacenar

Más detalles

EL MODELO DE PROGRAMACIÓN DE WINDOWS AZURE

EL MODELO DE PROGRAMACIÓN DE WINDOWS AZURE EL MODELO DE PROGRAMACIÓN DE WINDOWS AZURE DAVID CHAPPELL OCTUBRE DE 2010 PATROCINADO POR MICROSOFT CORPORATION CONTENIDOS Por qué crear un nuevo modelo de programación?... 3 Las tres reglas del modelo

Más detalles

Reproductor Multimedia Streaming v0.1

Reproductor Multimedia Streaming v0.1 Reproductor Multimedia Streaming v0.1 Joaquín Gutiérrez Gil Universidad Pablo de Olavide Ingeniería Técnica en Informática de Gestión Asignatura Proyecto Introducción El presente documento trata sobre

Más detalles

Proyecto Fin de Carrera OpenNebula y Hadoop: Cloud Computing con herramientas Open Source

Proyecto Fin de Carrera OpenNebula y Hadoop: Cloud Computing con herramientas Open Source Proyecto Fin de Carrera OpenNebula y Hadoop: Cloud Computing con herramientas Open Source Francisco Magaz Villaverde Consultor: Víctor Carceler Hontoria Junio 2012 Contenido Introducción Qué es Cloud Compu5ng?

Más detalles

2.1 Compuertas para Bases de Datos

2.1 Compuertas para Bases de Datos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Uno de los aspectos mas importantes en un sistema multibase de datos es la forma en como llevar a cabo la comunicación

Más detalles

Cree un entorno cluster virtual

Cree un entorno cluster virtual Cree un entorno cluster virtual Cómo tener un cluster de dos nodos en su portátil u ordenador de sobremesa Las soluciones empresariales de Microsoft para entornos cluster han mejorado con el tiempo, haciéndose

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: EL PROCESO DE DISEÑO DE SISTEMAS DISTRIBUIDOS MANEJANDO LOS DATOS EN LOS SISTEMAS DISTRIBUIDOS DISEÑANDO SISTEMAS PARA REDES DE ÁREA LOCAL DISEÑANDO SISTEMAS PARA ARQUITECTURAS CLIENTE/SERVIDOR

Más detalles

Juan de Dios Murillo Morera e-mail: jmurillo@una.ac.cr Santiago Caamaño Polini e-mail: scaamano@costarricense.cr INTRODUCCIÓN

Juan de Dios Murillo Morera e-mail: jmurillo@una.ac.cr Santiago Caamaño Polini e-mail: scaamano@costarricense.cr INTRODUCCIÓN UNICIENCIA 24 pp. 83-89 2010 IMPLEMENTACIÓN DE UN SERVIDOR FTP UTILIZANDO EL MODELO CLIENTE/SERVIDOR MEDIANTE EL USO DE SOCKETS EN LENGUAJE C UNIX CON EL FIN DE MEJORAR LOS TIEMPOS DE RESPUESTA EN LA RED

Más detalles

Ileana del Socorro vázquez Carrillo migración de negocios a la nube digital Las así denominadas TI han representado una nueva manera de

Ileana del Socorro vázquez Carrillo migración de negocios a la nube digital Las así denominadas TI han representado una nueva manera de InFORmÁTICA PymE Ileana del Socorro vázquez Carrillo migración de negocios a la nube digital Las así denominadas TI han representado una nueva manera de hacer negocios, ya que las funciones más importantes

Más detalles

1. INTRODUCCIÓN 2 2. EVERDRIVE LITE 3 3. SINCRONIZADOR DE EVERDRIVE 4 4. VISTA GENERAL DE LAS OPCIONES DE LA APLICACIÓN 5

1. INTRODUCCIÓN 2 2. EVERDRIVE LITE 3 3. SINCRONIZADOR DE EVERDRIVE 4 4. VISTA GENERAL DE LAS OPCIONES DE LA APLICACIÓN 5 Aplicación everdrive: Usuario Resumen Funcionalidades disponibles en la aplicación Registro de Modificaciones Versión Descripción [o descripción de cambios] Autor Fecha creación Aprobado por Fecha aprobación

Más detalles

BROWSERSQL VERSIÓN 3.1 TUTORIAL

BROWSERSQL VERSIÓN 3.1 TUTORIAL TUTORIAL LAURA NOUSSAN LETTRY (MENDOZA, ARGENTINA 2011) ÍNDICE CONTENIDOS PÁGINA Introducción 2 Características Funcionales 2 Área de Conexión 3 Área de Ejecución de Sentencias 4 En qué se basa su funcionamiento

Más detalles

WHITE PAPER MIGRACIÓN DE UNA APLICACIÓN ON-PREMISE A WINDOWS AZURE. OSSESoluciones - Cartera de Soluciones en Tecnologías de Información

WHITE PAPER MIGRACIÓN DE UNA APLICACIÓN ON-PREMISE A WINDOWS AZURE. OSSESoluciones - Cartera de Soluciones en Tecnologías de Información WHITE PAPER MIGRACIÓN DE UNA APLICACIÓN ON-PREMISE A WINDOWS AZURE OSSESoluciones - Cartera de Soluciones en Tecnologías de Información Sep2014 Contenido Resumen... 3 Acerca de Windows Azure... 4 Caso

Más detalles

ALMACENAMIENTO Manual de uso de owncloud

ALMACENAMIENTO Manual de uso de owncloud ALMACENAMIENTO Manual de uso de owncloud El proyecto CloudPYME (id: 0682_CLOUDPYME2_1_E) está cofinanciado por la Comisión Europea a través del Fondo Europeo de Desarrollo Regional (FEDER) dentro de la

Más detalles

Ministerio de Educación,Cultura y Deporte. Aulas en Red.Aplicaciones y servicios Windows. Módulo 3: Gestión de equipos.

Ministerio de Educación,Cultura y Deporte. Aulas en Red.Aplicaciones y servicios Windows. Módulo 3: Gestión de equipos. Ministerio de Educación,Cultura y Deporte. Aulas en Red.Aplicaciones y servicios Windows Módulo 3: Gestión de equipos. Escritorio Remoto Aulas en red. Aplicaciones y servicios. Windows Escritorio Remoto

Más detalles

DESARROLLO WEB EN ENTORNO SERVIDOR

DESARROLLO WEB EN ENTORNO SERVIDOR DESARROLLO WEB EN ENTORNO SERVIDOR CAPÍTULO 7: Programación de servicios Web Marcos López Sanz Juan Manuel Vara Mesa Jenifer Verde Marín Diana Marcela Sánchez Fúquene Jesús Javier Jiménez Hernández Valeria

Más detalles

UNIVERSIDAD PONTIFICIA DE SALAMANCA. Faculta de Informática

UNIVERSIDAD PONTIFICIA DE SALAMANCA. Faculta de Informática UNIVERSIDAD PONTIFICIA DE SALAMANCA Faculta de Informática Sistemas de Información y Auditoría de Sistemas de Información Modelos de servicio en Cloud Computing (SaaS, PaaS, IaaS) Alumno:!!! Alberto Balado

Más detalles

GESTOR DE DESCARGAS. Índice de contenido

GESTOR DE DESCARGAS. Índice de contenido GESTOR DE DESCARGAS Índice de contenido 1. Qué es DocumentosOnLine.net?...2 2. Qué es el Gestor de Descargas?...3 3.Instalación / Configuración...5 4.Descarga de Documentos...9 5.Búsqueda / Consulta de

Más detalles

Documentación Instalación NOD32 Server y Clientes

Documentación Instalación NOD32 Server y Clientes Documentación Instalación NOD32 Server y Clientes En esta documentación se indicará detalladamente la manera de instalar el antivirus NOD32 de forma distribuida desde un servidor de dominio a todos los

Más detalles

Software de Comunicaciones. Práctica 4 - DHCP & Dynamic DNS

Software de Comunicaciones. Práctica 4 - DHCP & Dynamic DNS Software de Comunicaciones Práctica 4 - DHCP & Dynamic DNS Juan Díez-Yanguas Barber Software de Comunicaciones Ingeniería Informática - 5º Curso Jdyb - Marzo 2013 Juan Díez- Yanguas Barber Práctica 4 Índice

Más detalles

Software de la impresora

Software de la impresora Software de la impresora Acerca del software de la impresora El software Epson contiene el software del driver de la impresora y EPSON Status Monitor 3. El driver de la impresora es un programa que permite

Más detalles

Computación en Red. Máster en Ingeniería de Telecomunicación. 2 º Curso. Curso Académico 2014/15

Computación en Red. Máster en Ingeniería de Telecomunicación. 2 º Curso. Curso Académico 2014/15 Computación en Red Máster en Ingeniería de Telecomunicación Curso Académico 2014/15 2 º Curso GUÍA DOCENTE Nombre de la asignatura: Computación en Red Código: 201816 Titulación en la que se imparte: Carácter:

Más detalles

COMPUTACIÓN EN LA NUBE YULIANA SAAVEDRA HECTOR JAIME USMA MONTAÑO CARLOS ANDRES FLOREZ VILLARRAGA PROFESORA LINA MARIA QUINTERO MARTÍNEZ

COMPUTACIÓN EN LA NUBE YULIANA SAAVEDRA HECTOR JAIME USMA MONTAÑO CARLOS ANDRES FLOREZ VILLARRAGA PROFESORA LINA MARIA QUINTERO MARTÍNEZ COMPUTACIÓN EN LA NUBE YULIANA SAAVEDRA HECTOR JAIME USMA MONTAÑO CARLOS ANDRES FLOREZ VILLARRAGA PROFESORA LINA MARIA QUINTERO MARTÍNEZ ESPACIO ACADÉMICO HERRAMIENTAS WEB 2.0 PARA EL DESARROLLO PROFESIONAL

Más detalles

Tema 1: Introducción a la gestión y planificación de redes

Tema 1: Introducción a la gestión y planificación de redes Tema 1: Introducción a la gestión y planificación de redes 1. Introducción general 2. Objetivos de la gestión de redes 3. Objetivos de la planificación de redes 4. Sistemas de gestión de red Gestión de

Más detalles

RAID. Los detalles de las características segunda y tercera, cambian según los distintos niveles RAID. RAID 0 no soporta la tercera característica.

RAID. Los detalles de las características segunda y tercera, cambian según los distintos niveles RAID. RAID 0 no soporta la tercera característica. RAID Como se dijo anteriormente, el ritmo de mejora de prestaciones en memoria secundaria ha sido considerablemente menor que en procesadores y en memoria principal. Esta desigualdad ha hecho, quizás,

Más detalles

Redes de área local en centros educativos. Windows

Redes de área local en centros educativos. Windows Ministerio de Educación Redes de área local en centros educativos. Windows Módulo 6: W7-Gestión de imágenes Instituto de Tecnologías Educativas 2011 En este apartado nos centraremos en la gestión de la

Más detalles

Windows, Linux, AIX, IBM i, Solaris y UNIX

Windows, Linux, AIX, IBM i, Solaris y UNIX SECURE FTP SERVER Windows, Linux, AIX, IBM i, Solaris y UNIX El servidor de archivos seguro permite a sus socios de negocio conectarse a su sistema e intercambiar archivos en un entorno auditado y centralizado

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

Monitor de Estadísticas de IDECanarias

Monitor de Estadísticas de IDECanarias Monitor de Estadísticas de IDECanarias Deepak P. Daswani 1, J. J. Rodrigo 1 y J. Rosales 2 1 Depto. de Ingeniería GRAFCAN. Cartográfica de Canarias, S.A C/ Panamá 34, Naves 8 y 9 Santa Cruz de Tenerife

Más detalles

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Página 1 de 11 1. Introducción Tom Baeyens es el fundador y arquitecto del proyecto de JBoss jbpm, la máquina de workflow

Más detalles