Repositorio Institucional de Documentos

Estudio y diseño de infraestructura virtualizada distribuida para el soporte de una arquitectura basada en Cloud Computing Óscar Salcedo Robles Ingeniería de Telecomunicación Director: Íñigo Sola Zuñiga Ponente: José Ruiz Mas i ESTUDIO Y DISEÑO DE INFRAESTRUCTURA VIRTUALIZADA DISTRIBUIDA PARA EL SOPORTE DE UNA ARQUITECTURA BASADA EN CLOUD COMPUTING Resumen El presente documento titulado “Estudio y diseño de infraestructura virtualizada distribuida para el soporte de una arquitectura basada en Cloud Computing” recoge el trabajo realizado por el autor como Proyecto Final de Carrera en el periodo comprendido entre julio de 2009 y agosto de 2010 en el programa de becas de la empresa Consultoría y Comunicaciones. En dicho periodo se contempla también el tiempo empleado en el estudio previo y que igualmente se recoge aquí. Se mostrará la manera en que ha sido entendido el paradigma Cloud Computing y cómo se ha acomodado éste a una situación concreta: la modernización de la infraestructura que soporta la labor empresarial de CyC. Se introducirán conceptos como virtualización, hipervisor o red de almacenamiento relacionados con infraestructuras de comunicaciones que serán debidamente explicados en el texto principal y ampliados y desarrollados en los diferentes anexos. Se validará todo lo expuesto con la realización de un piloto que cubra los principales campos de la solución dada y se intentará, en la medida de lo posible, dar nociones de otros aspectos que, si bien se encuentran enmarcados dentro del despliegue de una infraestructura genérica, van más allá de los objetivos de este estudio. El funcionamiento interno, el análisis pormenorizado de la infraestructura, así como otros aspectos confidenciales a juicio de CyC no podrán ser incluidos en este documento, sin que ello resulte impedimento para la comprensión de los objetivos, desarrollo y resultados del proyecto al que se refiere esta memoria. ii iii Agradecimientos Ningún trabajo debería ser considerado importante si no se encuentra razón para agradecer a nadie, pues hay pocas cosas de provecho que uno alcance realizándolas solo. En mi caso ocurre lo contrario: hay tantas personas a las que debo agradecer algo que quiero comenzar disculpándome con aquellos que se sientan olvidados en estas líneas. Si un barco llega a buen puerto, es porque posee una buena cadena de mando. Gracias a mi director, Íñigo Sola, por haberme brindado la oportunidad y los medios de hacer este proyecto con tanta libertad. Gracias también a José Ruiz, que a pesar de haberse embarcado ‘en marcha’ me ha ayudado con sus consejos, aportando su punto de vista y confiando en mí. Sin Julio Villalba y Diego Forcén no habría podido navegar por los entresijos de la infraestructura de CyC. Vuestras explicaciones me han acercado a la realidad empresarial que no se encuentra en los libros. Pero si este proyecto es un barco, entonces no hay nada más importante que tener un hogar al que regresar al final del viaje. Si he llegado hasta aquí, es gracias a mi familia, en especial mis padres y mis hermanas, que han soportado mis nervios, mi desesperación y también disfrutado mis triunfos durante todos estos años. Marta, tu apoyo me ha mantenido a flote y es el responsable de que estemos hoy al final de este camino mirando hacia atrás con satisfacción. Por las largas horas de trabajo, por la tensión, porque ha sido tu mano la que encontraba cuando necesitaba levantarme, este proyecto te lo dedico a ti. Y por último pero no menos importantes, gracias a mis amigos, que son la alegría y los buenos momentos que quedarán en el recuerdo cuando vuelva la vista hacia estos días. A los de siempre, que siguen ahí y que merecen tanto: Adrián, Amparo, Asun, Blanca, Carlos, Gloria, Javi, Jose, Marcos y María, y a los que he conocido en este viaje y que ya nunca me abandonarán: Bea, Cristina, Desi, Edgar, Enrique, Fer, Fran, Isabel, Javi, José Antonio, José Manuel, Laura, Mario, Paula, Silvia y Tomás. iv v Índice General Resumen ...................................................................................................................................... i Agradecimientos ...................................................................................................................... iii Índice General ........................................................................................................................... v Índice de figuras y tablas ....................................................................................................... vii Glosario de términos ................................................................................................................ xi Glosario de siglas .................................................................................................................. xiii Índice de capítulos 1. INTRODUCCIÓN ..................................................................................................................... 1 1.1. Contexto ............................................................................................................................... 1 1.2. Motivación ........................................................................................................................... 2 1.3. Objetivo y alcance ............................................................................................................... 3 1.4. Métodos y técnicas .............................................................................................................. 3 1.5. Breve descripción del contenido de la memoria .................................................................. 4 2. ESCENARIO DE TRABAJO ................................................................................................... 6 2.1. Trabajo previo ...................................................................................................................... 6 2.2. Cloud Computing ................................................................................................................. 8 2.3. Estructura de CyC .............................................................................................................. 12 2.3.1. Método de trabajo .................................................................................................... 12 2.3.2. Infraestructura del CPD ........................................................................................... 13 2.4. Cloud para CyC ................................................................................................................. 14 3. DISEÑO DE LA INFRAESTRUCTURA ............................................................................. 17 3.1. Propuesta de infraestructura .............................................................................................. 17 3.1.1. Virtualización .......................................................................................................... 18 3.1.2. Hipervisor ESX ........................................................................................................ 18 3.1.3. Almacenamiento distribuido .................................................................................... 22 3.1.4. Infraestructura física ideal ....................................................................................... 23 3.1.5. Infraestructuras físicas propuestas ........................................................................... 24 vi 3.1.6. Infraestructura lógica ............................................................................................... 29 3.2. Provisión de servicio .......................................................................................................... 32 3.2.1. Modelo de servicio para Cloud Computing ............................................................. 32 3.2.2. Lab Manager ............................................................................................................ 34 4. INFRAESTRUCTURA PILOTO .......................................................................................... 36 4.1. Entorno .............................................................................................................................. 36 4.2. Pruebas realizadas .............................................................................................................. 38 5. CONCLUSIONES ................................................................................................................... 43 5.1. Conclusiones finales .......................................................................................................... 43 5.2. Diagrama de Gantt ............................................................................................................. 44 5.3. Líneas futuras ..................................................................................................................... 46 Bibliografía ................................................................................................................................... 47 vii Índice de figuras y tablas Figuras Figura 1.1. Edificio Technocenter……………………………………………………1 Figura 2.1. Esquema Web x.0………………………………………………………..7 Figura 2.2. Diagrama de oportunidad………………………………………………...8 Figura 2.3. Tipos de nube según el ámbito………………………………………….10 Figura 2.4. Taxonomía de la nube propuesta en CyC……………………………....12 Figura 2.5. Infraestructura inicial de CyC…………………………………………..13 Figura 2.6. Estructura del nuevo CPD……………………………………………....15 Figura 2.7. Estructura del servicio………………………………………………..…16 Figura 3.1. Anillo de privilegios…………………………………………………….19 Figura 3.2 (a) Pantalla ESX………………………………………………………...20 (b) vSphere Client………………………………………………………21 Figura 3.3. Aspecto de vCenter………………………………………………….….21 Figura 3.4 (a) DAS…………………………………………………………………22 (b) NAS………………………………………………………………....22 (c) SAN………………………………………………………………....22 Figura 3.5. Infraestructura ideal vSphere……………………………..…….............23 Figura 3.6. Arquitectura propuesta en Opción 1…….……………………………...25 Figura 3.7. Arquitectura propuesta en Opción 2…………………………………....26 Figura 3.8. Arquitectura propuesta en Opción 3………………………………...….27 Figura 3.9. Elementos de la red virtual dentro de un ESX……………………….…30 Figura 3.10. Redundancia total de red haciendo uso de NIC teaming……………….31 Figura 3.11. Jerarquía de servicio en la nube de CyC………………………………..33 xiv OS Operating System PaaS Platform as a Service PFC Proyecto Fin de Carrera PLA-ZA PLAtaforma logística de ZAragoza RAID Redundant Array of Independent Disk S3 Simple Storage Service SaaS Software as a Service SAN Storage Area Network SCSI Small Computers System Interface SDK Software Development Kit SLA Service Level Agreement SOA Service Oriented Architecture URL Uniform Resource Locator VMFS Virtual Machine File System VMM Virtual Machine Manager VPN Virtual Private Network WWW World Wide Web Capítulo 1. Introducción 1 Capítulo 1 INTRODUCCIÓN En este primer capítulo se sitúa el proyecto en su contexto, presentando la empresa en la que se ha desarrollado, las motivaciones que lo han hecho posible y los objetivos marcados al inicio del mismo. Al final, se ofrece una breve referencia de cada una de las secciones que componen la memoria. 1.1. Contexto El presente proyecto se ha llevado a cabo en las oficinas de la empresa Consultoría y Comunicaciones (CyC), localizadas en el edificio Technocenter (Figura 1.1) del polígono empresarial PLA-ZA, en Zaragoza. Figura 1.1. Edificio Technocenter Capítulo 1. Introducción 2 CyC es una consultora tecnológica dedicada al desarrollo de productos informáticos integrales para empresas. Estos productos se materializan en los ámbitos de plataformas de productividad, gestión del conocimiento o Business Intelligence entre otros. La orientación a proyecto de la empresa y su estudio personalizado del cliente, para proveerlo de soluciones verticales que se ajusten a sus necesidades a partir de herramientas estándar, implica que una importante parte del esfuerzo profesional de CyC se dedique a investigar mejoras y novedades que se puedan aplicar tanto al desarrollo del software como de los sistemas que lo sustentan. Por esta razón, el proyecto ha estado ligado a varias áreas de la organización. Si bien, por su naturaleza, ha supuesto una estrecha colaboración con el departamento de Sistemas, en la fase de definición se han aplicado metodologías de Innovación, y todo su desarrollo se ha apoyado en I+D. 1.2. Motivación El principal valor de una consultora consiste en prestar atención al mercado para anticipar las necesidades de sus clientes, antes incluso de que ellos mismos se aperciban de que las tienen. Para alcanzar este fin, son necesarios una labor continua de documentación en los medios de divulgación tecnológica y un esfuerzo de investigación en aquellas ramas relacionadas con los productos ofrecidos, lo que nos permitirá discriminar las actividades que resulte más adecuado desarrollar en cada momento. La apuesta de CyC, tras su propio proceso de escucha al mercado es el Cloud Computing. Un hype del sector que mal entendido puede llevar a una implementación estéril de la tecnología que desarrolla. Por ello, conviene realizar una comprensión e interiorización del concepto en las que es preferible alejarse de la definición estricta a favor de un desarrollo eficiente. Se explicará, a lo largo del documento y los anexos correspondientes, una acepción particular de lo que es Cloud Computing (o computación en la nube), delimitando conceptos como las nubes privadas y, en ese contexto, la provisión de servicios de infraestructura (IaaS, Infraestructure as a Service), plataforma (PaaS, Platform as a Service) y software (SaaS, Software as a Service). Gracias a la experiencia de la empresa en arquitectura SOA (Service Oriented Architecture), se ha podido vivir el proceso como una migración de la metodología utilizada hasta el momento al campo del hardware. La infraestructura de tecnologías de la información (en adelante IT, por Information Technologies) dentro de las empresas es un ingrediente esencial al margen de la actividad que éstas desarrollen. Su funcionamiento tiene repercusión directa en el proceso de negocio, por lo que no se pueden obviar ni su implantación ni su mantenimiento. En un tiempo en el que la relación potencia-coste ya no supone un escollo, es el modelo organizativo, entendido como la manera de explotar dicha infraestructura, el que marca su rendimiento y la velocidad con la que retorna a nosotros la necesaria inversión en material tecnológico. Para hacer frente a las mejoras, se deben atender factores como el espacio, el consumo eléctrico, el porcentaje de utilización… y entre las alternativas existentes, una Capítulo 1. Introducción 3 que nos permite alcanzar nuevas metas con antiguos métodos es la virtualización. La virtualización nace hace más de cuatro décadas, pero gracias a la potencia de los equipos actuales y el esfuerzo por incrementar los bajos ratios de uso de CPU de las arquitecturas x86, hoy se ha convertido en una de las tecnologías más aplicadas en el ámbito de los servidores empresariales y las intranets corporativas. 1.3. Objetivo y alcance A través de este Proyecto Fin de Carrera (en adelante PFC), se pretende estudiar la mejor manera de aplicar tecnologías de virtualización, junto a conceptos de Cloud Computing, en la modernización y optimización de uso de una infraestructura distribuida entre tres sedes geográficamente dispersas. Éstas poseen una topología de interconexión preexistente que inicialmente será respetada. Se impone para el diseño mantener la metodología utilizada hasta el momento por los trabajadores para el desarrollo de la actividad de la empresa. La nueva implementación deberá modificar lo menos posible las tareas y costumbres ya establecidas al abordar proyectos de cliente. Las actuaciones se centrarán en la arquitectura del sistema, sin perder de vista la distribución territorial que la empresa posee por constitución. Para ello se perseguirán los siguientes hitos: - Justificar cuál ha sido el proceso por el cual se ha decidido apostar por el Cloud Computing entre las tecnologías consideradas de interés. - Analizar el concepto de Cloud Computing, adaptándolo al ideario de la empresa de modo que se obtenga un paradigma de arquitectura realizable en términos de los proyectos que CyC desarrolla. - Examinar la actual estructura de CPD dentro de CyC, delimitando qué elementos y servicios son susceptibles de ser mejorados por dicho paradigma. - Aplicar la virtualización como la palanca de cambio dentro del CPD que facilite la creación de servicios de Cloud Computing. - Diseñar el flujo de trabajo que permita la interacción de los roles proveedorusuario para la explotación de la infraestructura resultante. - Establecer las diferencias en el uso de la red y las comunicaciones que supone trabajar sobre un entorno virtualizado en lugar de uno físico. - Esbozar las mejores prácticas a seguir en la migración desde el sistema actual al propuesto. El alcance del estudio contempla la propuesta de una solución plausible y su validación mediante un prototipo que demuestre su viabilidad. La concepción y despliegue del mismo son igualmente objeto del proyecto. 1.4. Métodos y técnicas La actualidad de la temática elegida y el despliegue de internet constituyen el motivo de que este proyecto haya sido documentado mayoritariamente a través de la Capítulo 1. Introducción 4 web. En la búsqueda y definición de un concepto para el que, por el momento, no existen estándares, han resultado fundamentales las aportaciones de grandes proveedores de IT a través de whitepapers y portales web. Toda la bibliografía está puntualmente referenciada, pero el lector encontrará interesante ampliar su visión a través de las páginas de Amazon [i], SalesForce.com [ii], VMware [iii], Microsoft [iv] y Sun Microsystems [v] entre otros. También las de organismos reguladores como el NIST [vi], IEEE [vii] o CSA [viii]. De especial importancia ha sido la suscripción a grupos a través de la red profesional LinkedIn [ix], así como la numerosa información presente en la blogosfera tanto hispana como angloparlante. Merece una mención singular “El Blog de la Virtualización en español” [x] debido a su extensa documentación en castellano sobre casos prácticos con ESX, Hyper-V y Xen. Conviene resaltar que la adopción del Cloud Computing es una interpretación propia, por parte de la empresa, acomodada a la metodología y enfocada a optimizar un recurso concreto: la infraestructura interna. No debe ser tomada como una definición unívoca; es más, el autor, como otras numerosas fuentes, considera que el buen momento mediático del Cloud Computing se debe precisamente a su potencial como base para realizar diversidad de proyectos de distinta naturaleza. Nótese que el término nace de la tendencia histórica de representar la parte desconocida de cualquier sistema utilizando una nube. 1.5. Breve descripción del contenido de la memoria Este documento está estructurado en cinco capítulos. El primero, y presente, indica al lector el estado del arte en el momento de acometer el proyecto y establece las referencias que permitirán comprender la manera de abordar el trabajo por parte del autor. El segundo capítulo establece el marco inicial, el estado de la empresa antes de abordar el proyecto y la percepción de la tecnología que se pretende adoptar. También muestra el estudio previo realizado hasta llegar al Cloud Computing como materia de interés. Con él, se delimita el campo de acción y se sientan las bases para diseñar una solución. El tercer capítulo explica todo el diseño realizado, presenta y desarrolla las herramientas utilizadas, justifica las decisiones tomadas y expone la solución del autor. El cuarto capítulo presenta el prototipo que valida las decisiones expuestas en el epígrafe anterior. Pretende ser una muestra de la posible solución, además de un ejemplo de implementación de la tecnología comentada. El último capítulo sirve para comprender el esfuerzo aplicado a cada tarea, las dificultades más significativas y muestra una conclusión meditada de lo que ha supuesto realizar el proyecto. Los diferentes anexos, a los que el lector será invitado a acudir en el momento en que más apoyen la comprensión del texto, recogen y amplían la información Capítulo 1. Introducción 5 recabada. Si bien no son necesarios para el correcto seguimiento del trabajo realizado, posibilitan una visión más completa de lo que suponen el Cloud Computing, las tecnologías de virtualización y otros aspectos que se presentan en el texto principal. Capítulo 2. Escenario de trabajo 6 Capítulo 2 ESCENARIO DE TRABAJO Este segundo capítulo arranca con la exposición del estudio previo que nos ha llevado a elegir el Cloud Computing como herramienta para diferenciarnos como empresa en el manejo de nuestra infraestructura. Una vez discriminada esta tecnología entre las muchas estudiadas, se presenta conceptualmente el modelo al que pretendemos llegar y se justifica por qué se centra la atención sobre la infraestructura a partir de entonces. Por otro lado, se introduce el punto de partida, que es la empresa; para lo cual se describen, por un lado, las líneas generales de la metodología utilizada en la misma para acometer proyectos de cliente, y por otro, el centro de datos existente, con lo que el lector comprenderá más fácilmente las motivaciones y limitaciones de la solución que se pretende alcanzar. 2.1. Trabajo previo El principal impulso para la acometida de este proyecto basado en virtualización y Cloud Computing, es un estudio realizado previamente por el autor en el ámbito de la empresa, destinado a identificar la temática más interesante entre las principales tecnologías web que componen la oferta actual. Durante aproximadamente cuatro meses, se llevó a cabo una investigación que partía de las etiquetas “Web 2.0”, “Web semántica” o “Web de nueva generación” [xi] y trataba de delimitar qué elementos componían el germen de dichas expresiones, si existían atributos comunes a todas ellas y qué fundamentos arquitectónicos, tecnológicamente hablando, las hacían posibles. Capítulo 2. Escenario de trabajo 7 El estudio en su totalidad puede ser consultado en el Anexo A. Como síntesis del mismo, se confeccionó el esquema que puede verse en la Figura 2.1. Figura 2.1. Esquema Web x.0 Para ser consecuente con la terminología se acuñó el término “Web x.0” que engloba todas aquellas técnicas y arquitecturas objeto de estudio. Se identificaron un total de 9 técnicas o elementos (Blog, Mundos Virtuales, Wiki, Media Sharing, Buscadores, Marcadores Sociales, Redes Sociales, Sindicación de Contenidos y Sistemas de Recomendación) y 8 fundamentos arquitectónicos (Comunicaciones Unificadas, Objetos en Red, Georreferenciación, Cloud Computing, Web Semántica, Movilidad, Personalización y Web 3D), aunque las fronteras no siempre son tan nítidas como para establecerlas categóricamente (por ejemplo, los términos Mundos Virtuales y Web 3D son utilizados para referirse a las dos manifestaciones, como técnica y como arquitectura, de un mismo concepto). A su vez, para alinearlas con la metodología empleada en CyC, se agruparon en 3 áreas: gestión del conocimiento, extensión de proyectos web y plataformas de nueva generación, clasificación que igualmente dista de ser estricta. La información desmenuzada de todas las tecnologías permitió realizar un análisis que las situara dentro de una gráfica Retorno previsto/tiempo atendiendo a los siguientes factores: - La comprensión alcanzada del concepto. - Las relaciones entre ellas y la relevancia de los ejemplos existentes. Capítulo 2. Escenario de trabajo 8 - Posibles ampliaciones relacionadas con la especialización. - La tecnología que las sustenta, la experiencia en la misma y la posibilidad de dedicar recursos a su desarrollo. - El valor añadido que aportan en el contexto empresa/administración. - La valoración de personas involucradas hasta ahora en proyectos similares. - El alcance potencial de una solución basada en dicha tecnología. Estos factores fueron colocando cada tecnología en un área de la gráfica (Figura 2.2) 1 . En la mitad inferior quedaron aquellos elementos cuyo desarrollo resultaba actualmente tan avanzado que un pequeño incremento de innovación supondría un elevado aporte de recursos. Se decidió dejar estas tecnologías como herramientas a tener en cuenta a través de los proveedores que ya estaban en el mercado. En la mitad superior se localizaron las tecnologías más interesantes a tener en cuenta. Las más cercanas en el tiempo coincidían en temática con propuestas ya consideradas por la empresa, y a partir de un punto en el eje temporal, se trataba de propuestas tempranas para ser acometidas. En la zona óptima (centro-arriba) quedó situado el Cloud Computing. Figura 2.2. Diagrama de oportunidad Se decidió comenzar una línea de investigación que documentara la tecnología y que reuniera los requisitos necesarios para convertirse en PFC, de modo que el aprovechamiento del trabajo realizado resultara mutuo para el autor y la empresa. 2.2. Cloud Computing Cloud Computing es, a día de hoy, un paradigma en evolución. Por ello, sus definiciones, casos de uso, trasfondo, tecnologías, implementaciones, beneficios y riesgos continúan en debate en los sectores público y privado [xii]. La que se presenta aquí, y en el correspondiente anexo (Anexo B), es una interpretación libre de la 1 Se puede consultar la figura a mayor resolución en el Anexo A. Capítulo 2. Escenario de trabajo 9 bibliografía existente y, sobre todo, acomodada al modelo de trabajo de la organización en la que se desarrolla el proyecto. Las conclusiones obtenidas deben por tanto tomarse como una implementación específica y muy particular del concepto Cloud. Definido en una línea, Cloud Computing es “todo recurso de IT ofrecido como servicio”. Esta definición, tan concreta y ambigua a la vez, se irá perfilando a medida que avancemos, pero ya puede dar una idea de qué elementos se van a manejar (recursos tecnológicos) y qué se pretende hacer con ellos (ofrecer servicio). Prácticamente toda la literatura está de acuerdo en dividir el tipo de servicio que se ofrece “en la nube” en tres categorías según la naturaleza de sus contenidos: IaaS, PaaS y SaaS [xiii]. Se habla de IaaS cuando el servicio entregado supone capacidad de procesamiento (ciclos de procesador y memoria RAM), capacidad de almacenamiento, dispositivos de red o, por extensión, cualquier otro recurso fundamental (hardware), si bien los cuatro nombrados son los habituales. La particularidad es que, al ser un servicio, no se entregan físicamente, sino que se posibilita el acceso a su utilización independizándola de la ubicación del usuario. Tómese como ejemplo los servicios EC2 (potencia de CPU y RAM) o S3 (almacenamiento) ofrecidos públicamente a través de internet por Amazon. La expresión PaaS recoge aquellos casos en los que se entrega una arquitectura preconfigurada provista de herramientas capaces de desarrollar aplicaciones, programar procesos, flujos de trabajo… En general toda implementación que no supone un producto final o acabado, pero que reúne una infraestructura base más el software que la configura. Un ejemplo de esto sería la plataforma Force.com, utilizada para desarrollar el producto final de SalesForce, pero que se ofrece independientemente de éste para crear herramientas personalizadas diferentes de la original. Por último, SaaS hace referencia a aplicaciones completas que resuelven un problema concreto. Son soluciones específicas y especializadas, y son las más cercanas al concepto de servicio que generalmente manejamos. Sus ejemplos son los más extensos: correo web como GMail o Hotmail, herramientas ofimáticas online como Google Docs, herramientas CRM como SalesForce… Todas estas soluciones comparten la característica común de no necesitar el uso de recursos locales al usuario. La manera más extendida de entrega es a través de una interfaz web, y los requerimientos de esta son los únicos recursos que el consumidor debe aportar. Esta identificación con el modelo de servicio web ofrece a CyC la oportunidad de acercarse al Cloud Computing a través de otra definición que ya está instaurada en la empresa: la arquitectura orientada a servicio (SOA, Service Oriented Architecture). A partir de SharePoint, un producto de plataforma de colaboración de Microsoft, CyC lleva años ofreciendo soluciones basadas en arquitectura de servicios web; aplicado al actual proyecto, supone que tanto los servicios de SaaS como los de PaaS que interesa implementar en la empresa, o la manera de acceder al uso del Cloud podrán apoyarse en Capítulo 2. Escenario de trabajo 16 Figura 2.7. Estructura del servicio En la Figura 2.7 aparece la pila de componentes que intervendrán en un proceso de petición. Ésta no siempre se recorrerá en su totalidad, pues nuestro interés puede ser un servicio IaaS, un servicio PaaS o un servicio SaaS. A continuación se explica qué supone un servicio de cada capa: - Servicio IaaS: El producto a entregar es una máquina virtual en la que se ha especificado la potencia de CPU, la cantidad de RAM, el espacio de disco y el número y naturaleza de tarjetas de red. También contempla la instalación de un sistema operativo de base. - Servicio PaaS: Se compone de un conjunto de máquinas orquestadas (generalmente servidor de aplicaciones, base de datos y software de plataforma) lista para desarrollar soluciones sobre ella. - Servicio SaaS: Se entrega un servicio completo: acceso a la aplicación de Partes de Trabajo, un espacio de reuniones, un foro… Veamos un ejemplo: un empleado necesita recursos para desarrollar una aplicación. Realiza una petición que llega al responsable de plataforma. Éste conoce los elementos que necesita para crear la aplicación, pero no tiene acceso a la gestión de la infraestructura, por lo que pedirá a su vez un conjunto de máquinas preconfiguradas con cierta potencia y cierto software base. El administrador de la infraestructura recibirá la petición, tomará los recursos y los entregará. Capítulo 3. Diseño de la infraestructura 17 Capítulo 3 DISEÑO DE LA INFRAESTRUCTURA El tercer capítulo supone el grueso del presente documento. Se explican en él todas las decisiones de diseño que conducen a la creación de una infraestructura Cloud. Para que ésta tenga lugar, el primer paso es crear una base adecuada que, como se ha nombrado, la aportan las tecnologías de virtualización. Con ellas instaladas posibilitando el acceso a una piscina de recursos, la segunda fase recoge todas las aportaciones y herramientas que hacen que la infraestructura funcione como una nube de servicios de IT. 3.1. Propuesta de infraestructura Para llegar a nuestra solución, debemos convertir la suma de máquinas físicas en un único conjunto de recursos disponibles para ser tomados en fragmentos a medida de los requerimientos de cada momento. Esto, impensable hace unos años, es hoy día posible gracias a técnicas que abstraen el hardware de la lógica que hace uso de ellos, permitiéndonos montar y desmontar arquitecturas completas desde la terminal de un ordenador sin necesidad de conectar o desconectar los dispositivos. La virtualización y las redes de almacenamiento convierten el CPD en un recurso dinámico que amplía las posibilidades de configuración y de gestión respecto a los modelos precedentes. Capítulo 3. Diseño de la infraestructura 18 3.1.1. Virtualización La virtualización no es la única manera de hacer Cloud Computing, pero por sus características, puede ser la palanca perfecta para aproximarse a ella. Provee cuatro de las cinco características principales que Garthner, y de manera similar otras fuentes, asocian al Cloud: elasticidad y escalabilidad, piscina de recursos, cuantificación de su uso y orientación a servicio [xv]. La quinta característica, el acceso distribuido o web, se alcanza, como se demostrará más adelante, a través de las herramientas de gestión que los fabricantes de software proveen. Para poder llevar a cabo esta distribución de los recursos básicos de computación (procesador, memoria almacenamiento y red), debemos ser capaces de fragmentarlos a partir de los componentes físicos que los conforman. Esto no había sido posible hasta hace unos años, cuando se dio un nuevo impulso a una tecnología ya existente: la virtualización. Utilizada por IBM en la década de los 60 para gestionar los grandes mainframes, su uso se había limitado a este tipo de configuraciones, con un sistema de particiones lógicas, muy evolucionado actualmente, llamadas LPARs [xvi] hasta que se logró implementarla sobre arquitecturas x86 mediante la llamada traducción binaria. Así se multiplicaron las posibilidades de este tipo de servidores, que por su barato coste ya proliferaban en los CPDs de empresas de todos los tamaños, pero que, sin embargo, resultaban tremendamente infrautilizados, pues la técnica utilizada hasta entonces y aún en la actualidad, consistente en un único sistema operativo corriendo sobre cada máquina física supone un tiempo ocioso de procesador del 85% [xvii]. La virtualización permite un incremento del rendimiento a cotas mucho más altas, al admitir varias máquinas lógicas, o sea, varios sistemas operativos sobre el mismo hardware, en cada servidor físico. Esto facilita diversas aplicaciones, como la consolidación de servidores, pero, sobre todo, permite disponer con total libertad de los recursos de cada máquina para distribuirlos en la medida que nos interese. 3.1.2. Hipervisor ESX Para poder llevar a cabo la virtualización es necesario crear una capa de abstracción entre el hardware y el sistema operativo que hace uso de él, que gracias a esta nueva capa, no será uno solo sino varios. Esto modifica el anillo de privilegios de la arquitectura del computador 2 (Figura 3.1), lo que impone la presencia de un autómata que “traduzca” el anterior esquema, que los sistemas esperan encontrar, a la nueva configuración que permite la separación hardware-software. A la capa de abstracción se la denomina VMM (Virtual Machine Manager o Gestor de Máquina Virtual) y el autómata que se comunica con ella y actúa en cada servidor como sistema operativo anfitrión (host OS) se le conoce como hipervisor. 2 Para una explicación más amplia, acudir al Anexo C. Capítulo 3. Diseño de la infraestructura 19 Figura 3.1. Anillo de privilegios Existe un extenso número de hipervisores en el mercado implementando las diferentes generaciones de virtualización desarrolladas hasta la fecha y que pueden ser consultadas en el Anexo C. Aquí se van a considerar los tres que han logrado mayor trascendencia por sus características: ESX de VMware, Hyper-V de Microsoft y Xen de Citrix. Para decantar la decisión por uno u otro se van a considerar: - Las características técnicas, aquellas cosas que son capaces de hacer y sus competidores no, el peso en espacio de disco, etc. - El numero de “complementos” que se deben añadir al hipervisor base para constituir una solución completa Cloud. - El coste de implantación, los precios de las licencias y la posibilidad de reutilizar hardware existente para su implantación. - La facilidad para obtener conocimientos sobre su administración, manuales, tutoriales, formación por parte del fabricante y similares. El estudio completo puede consultarse en el Anexo D. La elección final se decantó hacia ESX y las ventajas evaluadas para utilizar este hipervisor sobre sus competidores son las siguientes: - Pertenecer a la desarrolladora original de las tecnologías de virtualización, VMware, lo que supone una garantía, por su largo camino trabajando en ellas. - Poseer el mayor repertorio de sistemas operativos huéspedes soportados del mercado. - Disponer en la empresa de experiencia en el uso de otras soluciones de la misma marca: VMware Server y VMware Workstation. - Obtener ventajas estratégicas y económicas de partnership que se traducen en formación, soporte y ahorro de licencias. - Existir un acuerdo de colaboración entre VMware y las principales distribuidoras de hardware de red (Cisco) y almacenamiento (Net App). Gracias a este acuerdo existe numerosa bibliografía que facilita la Capítulo 3. Diseño de la infraestructura 20 documentación en mejores prácticas al construir un CPD como el que nos ocupa. El principal inconveniente de la solución tomada es la reducida lista de hardware compatible y los altos requerimientos. No obstante, esta no deja de ser una característica común a todas las soluciones. Además, durante el proceso de elección, a la vista de las bondades que esta solución concreta proveía, principalmente unas técnicas de alta disponibilidad y recuperación ante desastres que liberaban mucho la carga del departamento de IT, se consideró la posibilidad de que en la futura fase de puesta en producción de la solución se renovara el parque de máquinas físicas existentes. Actualmente ESX puede ser adquirido en su versión 4 dentro de una suite, llamada vSphere, en la que lo acompañan las herramientas de gestión que a continuación se presentarán. ESX se deberá instalar como sistema operativo base (corre sobre un Linux 2.6.x integrado en el programa de instalación) en todos los servidores cuyos recursos se pretendan utilizar en la infraestructura virtualizada. Una vez instalado, su aspecto es el mostrado en la Figura 3.2a. Existen dos alternativas de instalación: ESX y ESXi. Si se dispone de la versión ESX se podrá acceder a una consola de servicio, con el aspecto de una línea de comandos Linux, desde la que se puede administrar localmente el equipo. Si se ha optado por la versión ESXi, la consola no estará disponible, no pudiéndose salir de la pantalla inicial. Ésta es la única diferencia entre las dos versiones del hipervisor, la ESX y la ESXi, y es así porque la principal vía de administración de este hipervisor es a través de cliente web, llamado vSphere Client, instalable en Windows (Figura 3.2b). Este cliente está limitado a un solo hipervisor por sesión, por eso, como lo que se pretende es hacer uso de una infraestructura formada por varios hipervisores, se hará uso de un servidor de gestión, el vCenter. Figura 3.2a. Pantalla ESX Capítulo 3. Diseño de la infraestructura 21 Figura 3.2b. vSphere Client vCenter es la herramienta que acompaña a ESX en la suite vSphere. Su aspecto (Figura 3.3) es similar al vSphere Client (se accede con el mismo interfaz lanzador) solo que presenta más funcionalidades, relacionadas con la gestión de varios hipervisores: conexiones de red, almacenamiento compartido y opciones avanzadas de gestión como la creación de clusters para alta disponibilidad. Para que dos ESX puedan ser configurados entre ellos con estas características deben pertenecer al mismo vCenter y cada ESX sólo puede pertenecer a un vCenter simultáneamente. Las repercusiones de estas condiciones se evalúan en el apartado 3.1.5. Figura 3.3. Aspecto de vCenter Capítulo 3. Diseño de la infraestructura 22 3.1.3. Almacenamiento distribuido Para poder sacar provecho de las ventajas de la virtualización, necesitamos un sistema de almacenamiento independiente de los servidores que aportan la potencia de computación. De nada sirve tener la capacidad de migrar una aplicación cuando una máquina cae si el archivo imagen de dicha aplicación se encontraba dentro de la máquina caída. Esto quiere decir que el sistema de almacenamiento DAS utilizado hasta ahora, en el que los discos dependen de la fuente de alimentación del servidor al que van conectados, es insuficiente, por ejemplo, para poder definir clusters de alta disponibilidad. Además, la capacidad global de almacenamiento se diluye entre decenas de dispositivos que no pueden compartir sus recursos con el resto de la infraestructura. Se deben utilizar técnicas en las que los discos estén disponibles en red, como discos conectados a la red (NAS) o redes dedicadas expresamente para el almacenamiento (SAN) [xviii] (ver Figura 3.4). Una explicación más extensa sobre los tipos de almacenamiento puede consultarse en el Anexo E. Figura 3.4a. DAS Figura 3.4b. NAS Figura 3.4c. SAN Lo más accesible sería configurar una red SAN, pues se independiza el tráfico inyectado a la red por los accesos a disco del resto del tráfico, que en un entorno de a partir de 4-5 servidores comienza a ser considerable [xix]. En la sede de Zaragoza, dado el reducido tamaño del CPD, podía bastar inicialmente con un disco conectado a la red existente. No obstante, la problemática de la red de almacenamiento se ve incrementada por el hecho de tratarse de sedes distribuidas, y es abordada con más detalle en el apartado 3.1.5. En cuanto al sistema de acceso, descartamos rápidamente una solución Fibre Channel por su elevado coste. La alternativa iSCSI se ha convertido en los últimos años, gracias a la aparición de NICs Gigabit Ethernet, en una opción más económica y capaz de resultar eficiente en entornos casi tan exigentes como aquellos en los que se suele utilizar fibra. Aunque su ancho de banda siempre será menor que el que se pueda alcanzar con ésta, su rendimiento es suficiente para una red con un número reducido de máquinas. Siempre que se pueda, la opción de iSCSI hardware es deseable a la software, para aliviar la carga del procesador de la máquina cliente. Esto se alcanza utilizando tarjetas HBA iSCSI tanto en el lado cliente como en el servidor. En caso de trabajar con iSCSI software, los requisitos de potencia de las máquinas serán mayores, y deberá ser tenido en cuenta en su dimensionado. Capítulo 3. Diseño de la infraestructura 23 3.1.4. Infraestructura física ideal El modelo de virtualización llevado a cabo por vSphere se apoya en una arquitectura compuesta por los elementos que aparecen en la Figura 3.5: servidores ESX, servidor vCenter, equipos cliente y discos de la SAN, generalmente cabinas de disco, y que han sido presentados en los epígrafes anteriores: Figura 3.5. Infraestructura ideal vSphere Como se puede ver, los elementos descritos están interconectados por dos redes aisladas una de otra, la de acceso y la de almacenamiento. A la red de acceso concurren los servidores dotados de hipervisor ESX, el servidor de gestión vCenter y los equipos cliente que quieran hacer uso de la infraestructura, tanto para gestionarla, a través de vCenter, como para solicitar servicios haciendo uso de las diferentes interfaces que se habiliten para ello. En el apartado 3.2.2 se explica la solución adoptada para acceder a estos recursos de infraestructura. La conexión se realiza a través de una tarjeta de red Ethernet, preferentemente Gigabit, aunque Fast Ethernet es soportada con una calidad de servicio aceptable [xx]. A la red de almacenamiento tienen acceso los servidores de ESX y las cabinas de disco que constituyen la SAN. El acceso, como ya se ha comentado, se realizará preferentemente a través de tarjetas HBA iSCSI. Si esto no es posible, bastará con tarjetas Gigabit Ethernet (en este caso una velocidad menor no es aceptable) y se deberá contar con un software específico en las máquinas, tanto en los ESX, que disponen de Capítulo 3. Diseño de la infraestructura 24 un adaptador iSCSI software, como en las cabinas, en las que suele presentarse integrado en el firmware. La topología de almacenamiento presentada, donde todos los ESX tienen acceso a todas las cabinas de disco, es difícil de implementar en la infraestructura de CyC sin modificar las comunicaciones existentes. Para comunicar eficientemente el almacenamiento entre sedes, sería necesario contratar una línea de alta velocidad y alta capacidad que asegurase el sincronismo y el tráfico de datos que requieren algunas configuraciones del vCenter. Por ello, se explicarán a continuación tres alternativas a la topología de red presentada aquí. 3.1.5. Infraestructuras físicas propuestas Dada la distribución geográfica de los CPDs que constituirán nuestra infraestructura, una SAN única y común a las tres sedes no va a ser posible con las comunicaciones existentes entre ellas. Esto requeriría el uso de una red de mayor capacidad; aparte de un estudio en el que evaluar si las ventajas obtenidas son equiparables al esfuerzo económico realizado. Las siguientes opciones muestran posibles soluciones que minimicen el impacto de no disponer de dicha red. En las tres configuraciones, la red de acceso está constituida por las LAN de las sedes interconectadas mediante el VPN existente, de modo que, a todos los efectos funcionará como una LAN lógica única. Capítulo 3. Diseño de la infraestructura 25 Opción 1: Figura 3.6. Arquitectura propuesta en Opción 1 La primera opción (Figura 3.6) consiste en considerar un sistema de almacenamiento local aislado en cada emplazamiento. La infraestructura tendrá entonces las siguientes características: - Un solo vCenter gestionando los tres CPD. - Todos los ESX se ‘ven’ entre ellos, pero vCenter solo permitirá crear clusters entre los que compartan el mismo almacenamiento, lo que se traduce en que sólo lo harán ESX de la misma sede. - El software basado en vCenter, como Lab Manager que se explica en el apartado 3.2.2, ve toda la infraestructura. Existirán repercusiones sobre los usuarios respecto al caso ideal. Las más destacables son: - Un técnico de la infraestructura puede crear, modificar y destruir entornos y máquinas virtuales desde cualquier sede de la organización, o desde cualquier lugar mediante túnel VPN, siempre que no caigan las comunicaciones. Para una configuración concreta, los recursos se tomarán de una única sede. - Un usuario puede solicitar y hacer uso de la infraestructura desde cualquier sede de la organización, o desde cualquier lugar mediante túnel VPN, siempre que no caigan las comunicaciones. - En caso de fallo de las comunicaciones inter-sede, un técnico o un usuario que no pertenezca a la sede en la que se encuentra físicamente el vCenter, no puede Capítulo 3. Diseño de la infraestructura 32 3.2. Provisión de servicio En el momento en que se dispone de una infraestructura virtualizada, las maneras de hacer uso de ella son muy diversas. Siguiendo la motivación del presente estudio, se tratará de alcanzar un modelo siguiendo el paradigma proveedor/consumidor al que, como se ha introducido en los capítulos iniciales, se llegará tomando como modelo el Cloud Computing. 3.2.1. Modelo de servicio para Cloud Computing Para poder ofrecer un servicio, lo primero que se debe establecer es qué términos lo definen. Esto determinará el uso que se puede hacer de la infraestructura, para qué debe estar preparada ésta o las personas que se encargan de administrarla y proporciona un referente al que acudir en caso de conflicto. Como punto de partida se han estudiado los modelos de oferta de servicio de Google App Engine, SalesForce, Microsoft (Azure y Online Services) y Amazon Web Services entre otros. Se han consultado sus acuerdos de servicio (SLAs), explorado sus interfaces y documentado las herramientas que utilizan para llegar hasta el consumidor. A partir de las ideas extraídas, se ha modelado un SLA para CyC que refleje las particularidades que se deben considerar en el uso de su infraestructura interna. Los campos que debe definir el acuerdo son: - Una descripción de la(s) máquina(s) que entra(n) en servicio. - Cuánto tiempo estará disponible la máquina o entorno solicitado dentro de la infraestructura o, lo que es lo mismo, cuándo se liberarán los recursos que consume. - Que disponibilidad temporal debe ofrecer el entorno mientras esté funcionando. - Qué tipo de recuperación ante desastres se debe implementar o qué interrupción de servicio es tolerable. - Si se deben utilizar puntos de recuperación (snapshots) y cuanto tiempo se conservará la copia. - Si se contempla un aumento dinámico de los recursos o la configuración inicial será inamovible. - Cuánto tiempo se mantendrá una copia del sistema una vez retirado del servicio. - Si se avisará del cese del servicio antes de cumplirse el plazo. - El tipo de permisos que tendrán los usuarios que accedan a la máquina o entorno. Estos términos serán seleccionados a través de un formulario de petición disponible en la plataforma interna de CyC, que inicia el flujo de trabajo que desemboca en la concesión de uso de la infraestructura interna, y que se describe completo a continuación: - Un usuario de CyC realiza una petición a través del formulario. Capítulo 3. Diseño de la infraestructura 33 - El formulario llega al proveedor del servicio y queda almacenado. - El proveedor puede: a) Disponer de credenciales suficientes para programar la infraestructura que sustenta el servicio. Si es el caso, realiza la configuración del entorno utilizando conjuntamente Lab Manager y vCenter. Para ello, dispondrá de plantillas, entornos preconfigurados o, en alguna ocasión, deberá crearlos desde cero. b) No tener a su alcance todos los elementos para entregar el servicio. Entonces, realiza a su vez una nueva petición que será atendida por un proveedor de la capa inferior. - El proveedor comunica al usuario la manera de acceder a los recursos solicitados. - Días antes de la fecha de fin de servicio, el sistema avisa al administrador, el cual podrá comunicarse con el usuario para negociar una prórroga a través de un nuevo SLA o cesar el servicio en la fecha acordada. La jerarquía para las peticiones la determinan los tipos de servicio que se definieron en el capítulo 2 y que se ilustran en la Figura 3.11. Figura 3.11. Jerarquía de servicio en la nube de CyC Debe existir algún tipo de software que empaquete la solución para que ésta pueda ser entregada. Dada la especialización que supone la virtualización, existen escasas opciones de gestión de una nube más allá de las que ofrecen los fabricantes. Una que merece la pena nombrar aquí, aunque no será explorada en profundidad es Open Nébula [xxii]. Este software de código abierto es capaz de gestionar soluciones tan diversas como Xen o VMware en el entorno privado, o Amazon en el ámbito público y Capítulo 3. Diseño de la infraestructura 34 orquestar un conjunto de tareas que permita ver la suma de aportaciones de estas plataformas como una única nube híbrida. Entre las opciones dentro de vSphere, encontraremos herramientas completas como Lab Manager, SDKs (Software Development Kits) que VMware pone al alcance de los desarrolladores y frameworks como Orchestrator, que se trata del propio motor de vCenter ofrecido a través de una interfaz que permite programar flujos de trabajo. Aquí se explotarán las posibilidades de Lab Manager, con el que se construirá la jerarquía expuesta que permite dar servicio Cloud. Los usos y posibilidades de los SDKs y Orchestrator se proponen como líneas futuras de especialización con vistas a ampliar la interacción con la infraestructura creada. 3.2.2. Lab Manager Para poder entregar la infraestructura a los usuarios finales se deben implementar interfaces y flujos de trabajo que les hagan llegar los productos solicitados. En este caso se utilizará Lab Manager, un componente de la suite vSphere que nos permite configurar entornos de desarrollo y pruebas. También puede implementar entornos de producción, pero su versatilidad no lo persigue como opción principal. A través de él, se harán efectivas las peticiones realizadas por formulario. La estructura de Lab Manager se puede observar en la Figura 3.12, donde también se refleja cómo se adapta a la jerarquía establecida para la concesión de servicios de la Cloud y cómo se corresponden estos con los roles presentes en un proyecto genérico de CyC. - La jerarquía creada protege la integridad tanto de los recursos cómo de los entornos, dado que solamente el administrador de sistema (azul) puede añadir/eliminar elementos reales. - El creador de plantillas (amarillo) pensado cómo un apoyo del administrador de sistema, puede moldear los recursos que este ofrece para aportar al entorno máquinas preconfiguradas que aceleren el despliegue. - A partir de ahí, cada organización, o lo que es lo mismo, proyecto, es gestionada por un administrador (rojo), que dispondrá de los recursos entregados para asignar las distintas cargas de trabajo, así como tendrá potestad para crear roles dentro del proyecto con diferentes limitaciones en el uso de los recursos. - En un mismo proyecto podremos encontrar dos espacios de trabajo, uno más libre en el que hacer las pruebas y otro limitado en su configuración para reflejar las necesidades del cliente. Las reconfiguraciones de los mismos estarán a cargo del propietario de aplicaciones (verde). - Por último, el usuario (morado) podrá probar diferentes configuraciones pero nunca modificar las máquinas existentes y sus relaciones. - Con permisos de solo lectura, a fin de poder acceder a los desarrollos como mero observador, se habilitará un rol específico (negro). Capítulo 3. Diseño de la infraestructura 35 Figura 3.12. Estructura de Lab Manager y su correspondencia con la jerarquía Cloud de CyC Para la asignación de permisos, necesitamos tener conexión a un directorio de autenticación como pueda ser Active Directory. La configuración actual de CyC será suficiente con sólo redirigir a dichos servidores en el momento de la instalación. Cuando un usuario o equipo lance una petición por el sistema expuesto en el apartado 3.2.1, recibirá un rol de los arriba descritos y una URL de acceso al entorno que solicita (Lab Manager permite asignar URLs únicas a cada entorno). Así, sea una petición enmarcada dentro de los proyectos que ya tienen cabida en la infraestructura, y por tanto en Lab Manager, o sea un nuevo entorno configurado desde cero, siempre se respetará la jerarquía que permite que nuestra Cloud sea un entorno controlado por un conjunto de administradores (proveedores) y disfrutada por el total de los integrantes de la organización (usuarios). Capítulo 4. Infraestructura piloto 36 Capítulo 4 INFRAESTRUCTURA PILOTO En este capítulo se explica la configuración elegida para ilustrar la viabilidad de las soluciones propuestas y se describirán las diferentes tareas a las que ésta ha sido sometida. 4.1. Entorno Para validar los principales elementos descritos en el capítulo de diseño se va a crear un piloto sobre el que se orquestará un flujo de trabajo donde la infraestructura sea gestionada como una nube. Para ello, el modelo a implementar es el mostrado en la Figura 4.1. Figura 4.1. Diagrama de la infraestructura piloto Capítulo 4. Infraestructura piloto 37 Una primera configuración básica será desplegada en ámbito local. Se instalarán todas las máquinas conectadas en red al mismo concentrador (hub) y con ellas se probará el hipervisor elegido y su centro de gestión, el sistema de almacenamiento y las configuraciones que pueden ser llevadas a cabo con el conjunto. La configuración extendida supone disponer de una red IP que simule la distribución geográfica, y con la que se validará la conexión Linked Mode entre los vCenter, y un despliegue donde la potencia de procesado (ESX) se encuentre en una sede y la de almacenamiento (dispositivo iSCSI) en otra. Como extensión también se demostrará que la sincronización entre dos dispositivos de almacenamiento de la red SAN a través de internet no es viable sobre las comunicaciones existentes. La versatilidad que proporciona la virtualización se hace patente en las numerosas implementaciones con las que alcanzar el esquema propuesto. Por ejemplo, con una máquina física lo suficientemente potente, se podría llegar a montar todo el modelo únicamente en el interior de la misma [xxiii]. Esta configuración es apropiada cuando se pretenden probar las características del software de virtualización sin realizar un esfuerzo de despliegue de red. En nuestro caso, resulta más interesante hacer uso de varias máquinas físicas y comprobar la influencia que la red tiene sobre la implementación. Se ha realizado la maqueta en un entorno compuesto por cuatro máquinas físicas: dos de ellas para soportar sendos ESX y otras dos para actuar de cabinas de disco. Se utiliza en estas últimas acceso iSCSI software mediante la plataforma libre OpenFiler. OpenFiler es una aplicación de almacenamiento software que permite convertir una máquina x86 en una cabina de disco. De las dos máquinas que sustentan los hipervisores, en la primera se ha realizado una instalación directamente sobre el hardware y en el segundo se ha optado por instalarlo sobre una máquina virtual haciendo uso del software VMware Workstation. Esto permitirá reflejar las diferencias de rendimiento entre la virtualización de última generación, o asistida por hardware, y un tipo de virtualización de escritorio basada en traducción binaria, que es el método del que hace uso Workstation. Se ha optado por instalar el gestor de la infraestructura, o sea el vCenter, virtualizado sobre uno de los hipervisores arriba descritos. Esta opción está soportada por VMware, y es una alternativa a tener en cuenta, pues permite aprovechar las ventajas de la virtualización en el despliegue de la virtualización misma. En nuestro caso, facilitará además las pruebas que impliquen la caída de un vCenter, por ejemplo en la validación del Linked Mode. El acceso de usuario se realiza mediante conexión web desde una quinta máquina en la que se ha instalado el vSphere Client. Recuérdese del apartado 3.1.2 que éste nos permite conectarnos tanto al vCenter como a la consola de administración Capítulo 4. Infraestructura piloto 38 individual de cada ESX, conexión que se hace necesaria aquí para acceder al servidor ESX que contiene el vCenter y poder poner éste en servicio. 4.2. Pruebas realizadas Lo primero que se debe hace es preparar las máquinas físicas, extendiendo cables de red para todas las tarjetas instaladas (Figura 4.2). Las opciones de redundancia ya han sido detalladas en el apartado 3.1.6. Aquí, utilizaremos un interfaz de red por ESX e igualmente uno para los iSCSI. ESX Cabina iSCSI ESX Cabina iSCSI 150.10.30.226 150.10.30.111 150.10.30.225 150.10.30.238 HUB Figura 4.2. Infraestructura piloto física Con el cableado extendido se instalan primero los OpenFiler. Éstos siguen un sistema cliente-servidor en el que el servidor, llamado target iSCSI serán los equipos en los que se aloja OpenFiler y el cliente, conocido como iniciador iSCSI serán los ESX que contienen su propio software de iniciador. La arquitectura se expone en la Figura 4.3. Figura 4.3. Arquitectura iSCSI Capítulo 4. Infraestructura piloto 39 El programa corre sobre una distribución Linux llamada rPath. Durante la instalación, se puede seleccionar el tamaño de las particiones, que conviene sean el mínimo tamaño posible para que quede la mayor cantidad de disco utilizada como almacenamiento. Este espacio posteriormente será formateado con el sistema de archivo VMFS (Virtual Machine File System) de VMware, que permite accesos concurrentes en lectura y en escritura, con lo que los discos pueden ser accedidos por más de una máquina a la vez. En caso contrario, sería como tener un disco físico conectado a varios equipos simultáneamente, y el sistema no resultaría útil. Una vez instalado, OpenFiler se gestiona mediante cliente web (Figura 4.4). Los pasos, que consisten en particionar el disco en distintas LUN (Logical UNits) y activar el controlador iSCSI para cada uno de ellos, pueden ser consultados en los numerosos tutoriales disponibles por internet [xxiv]. Figura 4.4. Cliente web OpenFiler Por otro lado, incluso simultáneamente a la instalación de OpenFiler, se lanza el instalador de ESX para el que lo único que hay que tener claro es la configuración de red: IP y la puerta de enlace. Sobre uno de los ESX se instala Windows Server 2003, que alojará vCenter Server. Éste se inicia como un servicio más de Windows Server y a partir de ahí, se puede acceder a él con vSphere Client. Ahora toda la gestión la realizaremos desde el vCenter al que se conectarán los ESX. La idea es lograr que cada ESX ‘vea’ el iSCSI, activando el iniciador y a continuación configurando un puerto en cada ESX del tipo VMkernel que conduzca el tráfico iSCSI (Figura 4.6a). Luego se rastrea en busca de dispositivo de almacenamiento y si todo es correcto, las unidades iSCSI deben ser detectadas (Figura 4.6b). Desde este momento ya se puede comenzar a alojar máquinas en ellas. Capítulo 4. Infraestructura piloto 40 Figura 4.6a. vSwitch configurado para iSCSI Figura 4.6b Iniciador iSCSI y cabina de disco visible desde ESX Una vez los ESX comparten almacenamiento y red de acceso, se pueden definir dentro de un mismo cluster (Figura 4.7), lo que permitirá tareas como activar la alta disponibilidad. Si se activa DRS, que es el sistema de balanceo de carga de VMware, se nos permitirá también definir piscinas de recursos. Una piscina de recursos es una cantidad, acotada o ilimitada, de los recursos de las máquinas en un cluster, solo que es vCenter quien la administra de manera dinámica, utilizando en cada momento los recursos que sean más accesibles dentro del cluster. Cuando nosotros tomamos recursos de una piscina, por ejemplo, instalando una máquina virtual en ella, no sabemos de qué servidores del cluster está tomando vCenter los recursos y, de hecho, no tienen por qué ser los mismos cada vez que la ejecutamos. Este elemento es de especial interés en Lab Manager. Capítulo 4. Infraestructura piloto 41 Figura 4.7. Detalle de cluster en vCenter Creando una nueva máquina virtual con Windows Server 2003, se dispondrá de recursos para instalar Lab Manager (Figura 4.8). La configuración de Lab Manager incluye una IP para el acceso y recursos provenientes del vCenter incluidas piscinas de IPs si queremos desentendernos de posteriores asignaciones. 48 [xvii] Sun Microsystems. Take your business to a higher level. Sun Microsystems; 2009. http://www.ania.it/opencms/openmcs/export/sites/default/documenti/55d9 15d2-93d9-11de-a3d1-f3c446ddba06___cloud_computing_primer.pdf [xviii] Anónimo. A storage architecture guide.Auspex Systems; 2001. http://www.storagesearch.com/auspexart.html [xix] VMware. iSCSI SAN configuration guide. Palo Alto, California; 2009. [xx] http://www.vmware.com/products/vcenter-server/ [xxi] VMware; CISCo Systems. VMware infrastructure 3 in a Cisco network environment. Americas Headquarters; 2008. http://www.cisco.com/application/pdf/en/us/guest/netsol/ns304/c649/ccm igration_09186a00807a15d0.pdf [xxii] http://www.opennebula.org [xxiii] http://www.hypervizor.com [xxiv] http://www.techhead.co.uk/how-to-configure-openfiler-v23-iscsi-storage- for-use-with-vmware-esx