ARTICULO ORIGINAL

Arquitectura de Referencia para el diseño y despliegue de Nubes Privadas

A Private Cloud's Reference Architecture Proposal

Ing. Lilia Rosa García Perellada, Dr.C. Alain Abel Garófalo Hernández

RESUMEN

El modelo de Infraestructura como Servicio, perteneciente al paradigma de Computación en la Nube, constituye para la mayoría de las organizaciones una solución costo-efectiva-segura para satisfacer ágilmente la demanda de infraestructura de computación, a través de centros de datos privados dinámicamente escalables. Las soluciones propuestas por los líderes en la rama constituyen arquitecturas genéricas basadas en costosas infraestructuras de hardware de alto nivel de cómputo, que pueden resultar inadecuadas de acuerdo a las metas que se persigan con las Tecnologías de la Información y las Comunicaciones, y las limitaciones económicas o de otro tipo que presente una institución. Lo anterior dificulta la adopción de este modelo en entidades con fuertes restricciones económicas, por lo que el presente trabajo propone una arquitectura de Nube Privada con soporte para Infraestructura como Servicio que permite el diseño de soluciones para el mencionado modelo sobre hardware heredado y herramientas de Software Libre y Código Abierto. Los resultados alcanzados fueron una Arquitectura de Referencia que permite el diseño de Nubes Privadas que respondan a los objetivos y restricciones de las entidades, y una solución de despliegue basada en hardware de propósito general y Software Libre y Código Abierto, impactando en la reducción de las inversiones en las organizaciones.

Palabras claves: computación en la nube, nube privada, infraestructura como servicio, arquitectura de referencia.

ABSTRACT

The Infrastructure as a Service model belonging to the Cloud Computing paradigm constitutes for most organizations a secure-cost-effective solution for rapidly achieving the computing infrastructure demand through dynamically scalable private data centers. The solutions proposed by leaders in the industry are generic architectures based on expensive hardware infrastructure of high-level computation, which may be inappropriate according to the real needs and constraints of the institution's Information and Communications Technologies. This hinders the adoption of this model in companies with strong economic constraints, so the goal of this investigation was to propose a Private Cloud Infrastructure supporting Infrastructure as a Service based on legacy hardware, or not, and Free and Open Source Software tools, with Quality of Service levels comparable to the commercial solutions levels. The results achieved were: a Reference Architecture that lets the design of Private Clouds that meet the objectives and constraints of the interested organizations; a deployment solution based on general purpose hardware and Free and Open Source Software. These results favorably impacts on the reduction of the organization's TIC´s investments.

Key words: cloud computing, private cloud, infrastructure as a service, reference architecture. ]]>

INTRODUCCIÓN

El modelo de Infraestructura como Servicio (IaaS, Infrastructure as a Service), perteneciente al paradigma de Computación en la Nube, ofrece una solución costo-efectiva-segura para brindar infraestructura de computación como servicio (procesamiento, almacenamiento, redes y otros recursos de computación). Este ayuda a satisfacer las constantes y variadas demandas del negocio minimizando inversiones capitales en recursos de cómputo físicos que necesitan de mantenimiento y actualización. El modelo se destaca por posibilitar un centro de datos con una infraestructura de computación dinámicamente escalable, junto a la optimización y simplificación de sus operaciones internas, objetivos que logra mediante la gestión centralizada de todos los servidores y servicios, con una explotación más eficiente de estos recursos. La IaaS logra de este modo responder ágilmente a la demanda de los recursos de las Tecnologías de la Información y las Comunicaciones (TIC), de una manera en que la infraestructura tradicional no se encuentra capacitada ¹.

Actualmente las soluciones comerciales de esta tecnología provienen de dos grandes grupos de desarrolladores: los proveedores de soluciones propietarias con productos de alta profesionalidad que requieren el pago de licencias, como VMware (vCloud), Microsoft (Windows Server 2008 R2 Hyper-V y Microsoft System Center) y el International Business Machines (IBM) (IBM Tivoli Service Manager (ISDM)); y los proyectos de Software Libre y Código Abierto (SLCA) con soluciones como OpenNebula, Elastic Utility Computing Architecture for Linking your Programs to Useful Systems (Eucalyptus) y CloudStack. Ambos grupos proponen arquitecturas genéricas (para aplicaciones y patrones de tráfico tradicionales) basadas sobre costosas infraestructuras de hardware de alto nivel de cómputo, que pueden resultar inadecuadas de acuerdo a las necesidades reales y restricciones (presupuesto, preferencias tecnológicas, políticas, regulaciones) de la institución con las TIC. Lo anterior obstaculiza la adopción de este nuevo modelo en entidades con fuertes restricciones económicas, que carezcan de centros de datos capaces de responder rápidamente a las crecientes necesidades TIC; y en donde el mantenimiento y desarrollo de la infraestructura de computación necesaria para el soporte de la misión de la entidad resultan presupuestariamente complejo ^{1 2}. Estas organizaciones se enfrentan al reto de cumplir los nuevos y necesarios requerimientos técnicos para brindar los servicios con la calidad demandada a partir de un presupuesto muy limitado. En ocasiones la solución solo es posible mediante la reutilización de la infraestructura existente, compuesta mayormente por hardware de propósito general.

Este trabajo presenta una propuesta para el despliegue de una Nube Privada con IaaS sobre hardware heredado y mediante el empleo de SLCA. De esta forma las organizaciones mencionadas arriba podrían migrar sus infraestructuras TIC al nuevo paradigma con impactos significativamente menores en las Inversiones de Capital (CAPEX, Capital Expenditures) que las propuestas de los líderes en el mercado. Para el desarrollo de la propuesta los autores definieron una Arquitectura de Referencia para Nubes Privadas que les permitió construir la propuesta de despliegue basada en gestores de Nube, hipervisores, sistemas de almacenamiento y demás aplicaciones, todas ellas SLCA.

DEFINICIÓN DE NUBE PRIVADA CON SOPORTE PARA IAAS

Las definiciones de Nube Privada e IaaS, influyen directamente en el alcance y requerimientos técnicos (escalabilidad, seguridad, desempeño,…) a contemplar en los diseños lógico y físico de un centro de datos a implementar con este nuevo paradigma. «La Computación en la Nube es un modelo para habilitar convenientemente el acceso bajo demanda a través de la red a un conjunto compartido de recursos de cómputo configurables (ejemplos: redes, servidores, almacenamiento, aplicaciones y servicios) que pueden ser rápidamente aprovisionados y liberados con un mínimo esfuerzo de gestión o de interacción por parte del proveedor de servicios. Este modelo promueve disponibilidad y se encuentra compuesto por cinco características esenciales (auto servicio bajo demanda, acceso de red con banda ancha, concentración de recursos, elasticidad rápida y servicio contabilizado), tres modelos de servicios (IaaS, Plataforma como Servicio (PaaS, Platform as a Service) y Software como Servicio (SaaS, Software as a Service) y cuatro modelos de despliegue (Nube Pública, Nube Privada, Nube Comunitaria y Nube Híbrida)» ³. Dicha definición, brindada por el Instituto Nacional de Estándares y Tecnología (NIST, National Institute of Standards and Technology), es la que ha sido adoptada por la mayoría de los órganos de estandarización como la Unión Internacional de Telecomunicaciones (UIT) ⁴ y la Distributed Management Task Force (DMTF) ⁵.

El NIST, la UIT y la DMTF concuerdan en la siguiente definición del modelo de servicio de Nube IaaS ^{3 4 5}: la IaaS constituye la capacidad del proveedor de servicios de aprovisionar al consumidor procesamiento, almacenamiento, red y otros recursos de computación fundamentales de la infraestructura Nube, en donde el consumidor es capaz de desplegar y correr software arbitrario, lo que puede incluir Sistemas Operativos (SO) y aplicaciones. El consumidor no gestiona o controla la infraestructura Nube subyacente, pero tiene control sobre los SO, almacenamiento, aplicaciones desplegadas, y posiblemente control limitado sobre componentes de red seleccionados, ejemplo: corta-fuegos del nodo.

ARQUITECTURAS DE REFERENCIAS GENÉRICAS DE NUBE

Los autores del presente trabajo consideran que la concepción de una Arquitectura de Referencia para Nubes Privadas constituye una herramienta para describir y desarrollar un sistema o arquitectura específica partiendo de las necesidades de las TIC de una institución y sus restricciones ⁶. No obstante, actualmente las arquitecturas propuestas son genéricas para la Nube, no particularizando en las características propias de cada uno de los modelos de despliegue. En pos de definir entonces, una Arquitectura de Referencia para Nubes Privadas, se analizaron críticamente desde la perspectiva de dicho modelo, las Arquitecturas de Referencias emitidas por las organizaciones líderes en los procesos de estandarización de la Computación en la Nube ⁷: el NIST, la UIT y la DMTF, para determinar las semejanzas y particularidades de sus propuestas, y cómo estas se ajustan a una Nube Privada gestionada por la entidad en sus propias instalaciones con soporte para IaaS.

La Arquitectura de Referencia abarca su Ecosistema del Negocio y su Arquitectura de Referencia Funcional. El Ecosistema define los actores y sus roles. Se encuentra formado de manera general por el proveedor, el usuario y el contribuidor, los cuales poseen su ubicación y rol en la Nube Privada, destacando la DMTF por su detallada descripción de los actores ⁸, convirtiéndose en la base del Ecosistema de la Nube Privada en la que se centró el presente trabajo. La Figura 1 muestra las interacciones y categorías de actores definidas por la DMTF (consumidor-usuario, desarrollador-uno de los roles del contribuidor).

La Arquitectura Funcional especifica la estructuración de grupos de funciones que responden a actividades específicas dentro de la Operación-Administración-Mantenimiento y Aprovisionamiento (OAM&P, Operations, Aministration, Maintenance and Provisioning) y el Sistema de Soporte del Negocio/Sistema de Soporte de Operaciones (BSS/OSS, Business Support System/Operational Support System). La Arquitectura de Referencia Funcional que se consideró más integral fue la de la UIT ^{4 6 9} mostrada en la Figura 2, tomada como referencia para el desarrollo del trabajo, debido a que disgrega con mayor precisión las tareas y elementos necesarios para el soporte de los servicios Nube, partiendo desde la interfaz usuario/contribuidor->proveedor, hasta las acciones dentro de la Infraestructura Nube (capas: «Recursos y Red» y «Funciones Comunes a las Capas»), abarcando la mayoría de las funcionalidades que define el NIST en su arquitectura ³, aportando este las funcionalidades necesarias para el soporte a la gestión del negocio. La mayoría de los bloques funcionales y recomendaciones analizados se consideraron útiles para la conformación de la Nube Privada. No obstante, en el presente trabajo fueron abordadas solo las capas bases en el soporte de los servicios Nube, comprendidas en las capas de la infraestructura de la Nube, acotadas a las características de la Nube Privada. El resto de las capas no fueron incluidas porque son dependientes de los protocolos y tecnologías empleados en las capas antes mencionadas y muy particulares del caso de uso en cuestión. El bloque funcional de Seguridad y Privacidad, por razones de alcance del proyecto no fue abordado.

SOLUCIONES DISPONIBLES PARA EL DESPLIEGUE DE NUBES PRIVADAS CON SOPORTE PARA IAAS

La segunda tarea fundamental realizada para la obtención de una Arquitectura de Referencia Funcional para una Nube Privada con soporte para IaaS, fue analizar cómo los principales líderes en la rama despliegan las capas de la Arquitectura de Referencia Funcional de la UIT en sus soluciones de Nube Privada. Las soluciones propietarias examinadas fueron las de Microsoft, Vmware e IBM por sus experiencias desarrolladas en el diseño e implementación de Nubes Privadas ¹⁰, aunque el principal interés para cumplir los objetivos del proyecto lo constituyeron las soluciones de SLCA. Las soluciones de SLCA estudiadas fueron OpenNebula, Eucalyptus y CloudStack, seleccionadas por su empleo en entidades a nivel internacional, las referencias obtenidas en relación a las capacidades para efectuar la gestión de infraestructuras en la Nube y la bibliografía disponible ¹⁰. El estudio comparativo de dichas soluciones se basó en el nivel de cumplimiento respecto a la Arquitectura de Referencia Funcional de la UIT, las funcionalidades referentes a la gestión del negocio aportadas por el NIST y los parámetros comparativos tomados de un conjunto de publicaciones como ¹¹.

El análisis de las funcionalidades y los requerimientos por capas del Modelo de Referencia de la UIT en los gestores considerados, teniendo en cuenta además los parámetros comparativos en la bibliografía consultada, arrojó: a) que todos los gestores analizados, excepto la herramienta de gestión ISDM, abarcan las capas definidas por dicho modelo; b) las principales tendencias en el despliegue de cada una de las capas; y c) que las soluciones propietarias, a pesar de que demandan los mayores requerimientos de cómputo, deben ser tomadas como referencias ya que soportan un mayor número de funcionalidades, tecnologías avanzadas, recomendaciones y estándares, en relación a las soluciones SLCA. Estas últimas, aportan, entre otros aspectos, la posibilidad de personalización y optimización, el apoyo de desarrolladores de todo el mundo interesados en el auge del SLCA e independencia tecnológica ¹⁰.

De los gestores SLCA analizados OpenNebula se consideró el más integral al destacarse por los elementos siguientes ¹⁰:

- Su facilidad de expansión e integración con terceras herramientas.

- Incluir los cuatro modelos de despliegue y permitir la interacción inter-Nube a través de un gran número de interfaces estandarizadas.

- Soportar la mayor variedad de hipervisores, mecanismos de virtualización y el Formato Abierto de Virtualización (OVF, Open Virtualization Format).

- Implementar la migración estática, dinámica y transparente de máquinas virtuales (MV).

- Poseer un planificador por defecto que permite agregar nuevos parámetros a considerar en los nodos y definir nuevas políticas para la distribución de las MV, considerándose el mejor entre los empleados por los gestores SLCA si solo se requiere de planificación inmediata. Además el planificador en OpenNebula es una entidad independiente por lo que puede ser fácilmente sustituido por una tercera solución.

- Integrar el mayor número de sistemas de almacenamiento y de sistemas de ficheros en red, siendo la única solución con soporte para la Interfaz de Gestión de Datos de la Nube (CDMI, Cloud Data Management Interface), estándar de la DMTF.

- Garantizar un mecanismo de detección y recuperación de fallos mediante hooks, que permite personalizar el control de fallos del sistema.

- Su flexibilidad en la monitorización y contabilidad de los recursos.

Teniendo en cuenta el importante grupo de ventajas enumeradas anteriormente, OpenNebula fue seleccionado como gestor de Nube Privada en la propuesta de despliegue del presente trabajo.

La Arquitectura de Referencia propuesta por los autores se encuentra basada en los resultados del estudio del estado del arte expuestos en la sección «Arquitecturas de Referencias Genéricas de Nube», en las recomendaciones emitidas por las organizaciones de estandarización consultadas y en las tecnologías empleadas para el despliegue de Nubes Privadas por los líderes en la rama.

El Ecosistema propuesto destaca por contextualizar en una entidad el departamento y/o el personal, que asume los diferentes roles de cada uno de los actores de una Nube Privada, bajo posibles escenarios. En función del contexto existirán o no, determinados roles de actores. El Ecosistema define tres categorías de actores: el proveedor, el cliente y el contribuidor, los que se describen en los próximos párrafos. La Figura 3 muestra las categorías de actores y sus interacciones.

El proveedor: entidad que despliegue la Nube Privada, motivada por las tres fuentes primarias de valor para el negocio brindadas por este paradigma, eficiencia, agilidad e innovación, explotando una o más de ellas, de acuerdo a sus necesidades y su misión. La entidad en pos de lograr los objetivos del negocio actuará como proveedor al desplegar y administrar una Arquitectura Nube capaz de brindar IaaS a través de la red, a niveles de servicios y costos acordados, a los usuarios que determine pertinente. La entidad actuará como Administrador de las Operaciones del Servicio, Administrador del Servicio del Negocio y Administrador de la Transición del Servicio, actores definidos por la DMTF ⁸ y que abarcan lo expuesto por la UIT y el NIST ^{3 4}.

El usuario: la entidad (personal autorizado) se comporta como consumidora al explotar los recursos de la Nube Privada desplegada, a través de los servicios brindados, en correspondencia con los objetivos del negocio perseguidos. Además, puede comportarse incluso como consumidora de servicios de otra Nube en una interacción entre Nubes. Pueden coexistir los tres actores definidos por la DMTF ⁸ dentro de esta categoría, los que abarcan lo definido por el NIST y la UIT ^{3 4}, bajo diferentes contextos, que además pueden coincidir como muestra la Figura 3:

- La delegación de la administración del conjunto de recursos de cómputo aprovisionados a una sub-entidad o individuo constituye una solución eficiente y flexible para la administración de los recursos TIC asignados. En este contexto el Administrador del Servicio del Consumidor ⁸ (sub-entidad o individuo) es esencial para la administración de los recursos, servicios y gestión de los usuarios. En el caso de que los servicios brindados sean tarificados el Director del Negocio del Consumidor ⁸ es quien arregla los pagos por los servicios y junto con el Administrador del Servicio del Consumidor ⁸ selecciona los servicios apropiados.

- Los usuarios pueden existir de manera individual, sin que medie alguna sub-entidad para que estos accedan a la IaaS. En este caso la infraestructura solicitada no es administrada por un administrador de una sub-entidad o él mismo, es decir, no se tienen responsabilidades de administración. En caso de que los servicios sean tarificados actuarán como Director del Negocio del Consumidor.

El contribuidor: en este actor, a diferencia de los Ecosistemas analizados, se engloban todos aquellos que contribuyan al soporte de la construcción de la oferta del servicio del proveedor, en la entidad o fuera de esta. Contiene los roles planteados por la UIT ⁴, coincidentes con los planteados por la DMTF ⁸ y el NIST ³.

La Arquitectura Funcional, además de definir cada uno de los bloques funcionales necesarios para el despliegue de una Nube Privada con soporte para IaaS, se diferencia con las Arquitecturas del estado del arte estudiadas, por indicar, en donde es pertinente, técnicas para dimensionar y/u optimizar la infraestructura a implementar, así como los estándares necesarios para lograr interoperabilidad y portabilidad. Las funcionalidades y características agregadas a la Arquitectura tributan al cumplimiento de diferentes requerimientos no funcionales planteados a un diseño como: desempeño, escalabilidad, usabilidad, adaptabilidad, capacidad de gestión y factibilidad económica. Resalta a su vez por contar con una capa de «Gestión de la Arquitectura y los Servicios» que permite administrar tanto la infraestructura como los servicios brindados. De las cinco capas que conforman el sistema, cuatro contienen aportes de los autores, como muestra la Figura 4 (en líneas discontinúas rojas). En los próximos párrafos se describe la propuesta.

La Capa de Usuario coincide con la de la UIT ^{4 9}, exponiendo las funciones que permiten la interacción del cliente/contribuidor con el proveedor (solicitud, recepción, acceso, administración de servicios Nube). La DMTF la define como «Interfaz del Proveedor» ⁸. Los autores proponen que las interfaces sean abiertas, con el objetivo de lograr la interoperabilidad de servicio y la portabilidad de datos y de sistemas; y que se le brinde al usuario el auto-aprovisionamiento bajo demanda, para que este solicite los recursos en función de sus necesidades reales, en el menor tiempo posible.

Las capas de Servicios y de Recursos y Red se encuentran conformadas a partir de la arquitectura de la UIT ^{4 6 9} porque esta engloba las funcionalidades planteadas por el NIST en las tres capas del componente de Orquestación del Servicio ³, salvo los recursos facilitadores contenidos en la capa de Recursos Físicos del NIST ³, que fueron incluidos en la propuesta en la agrupación funcional de Recursos Físicos. Los recursos facilitadores son claves para la climatización del centro de datos.

Los autores proponen que en la capa de Servicios la Función de Orquestación soporte el despliegue automático y elástico de clústeres virtuales para el soporte de servicios PaaS y SaaS, y la técnica para mejorar la eficiencia de explotación de los recursos de almacenamiento thin provisioning, todo lo cual permite mejorar la QoS y la escalabilidad del sistema.

En la capa de Recursos y Red, los autores proponen que en el bloque funcional de Orquestación de Recursos, el planificador soporte: a) diferentes formas de gestión de contratos para arrendar MV como la reserva avanzada, la de mejor esfuerzo, la inmediata, entre otras, para mejorar la QoS del usuario; b) el despliegue automático y manual de MV, en el manual se deben indicar los nodos mejores candidatos, mientras que el automático debe basarse en políticas como la de eficiencia energética, la de optimización del rendimiento de las MV y la de balance de carga que debe permitir seleccionar los niveles de prioridad de los recursos de los nodos, almacenamiento y red a ser tomados en cuenta para distribuir las MV; y c) la notificación y migración automática de MV en función de las condiciones del clúster sin afectar la disponibilidad y QoS.

Los incisos b) y c) contribuyen a aumentar el desempeño, disponibilidad y escalabilidad del centro de datos. En el bloque funcional de Concentración y Virtualización los autores consideran deben ser soportados los estándares para la Gestión de la Virtualización (VMAN, Virtualization Management) de la DMTF ¹² y cumplir con las recomendaciones para este bloque de la UIT ⁶, ya que contribuyen a simplificar las operaciones de gestión, y a la interoperabilidad y portabilidad de datos y servicios.

En el bloque funcional de Recursos Físicos la relación entre los recursos de cómputo de los nodos y sus homólogos en las MV asegura los niveles óptimos de desempeño; por ello se recomienda que el uso de los recursos virtuales debe estar entre el 60 y 80% de los físicos, para evitar tanto su infrautilización, como su explotación excesiva ¹³. En el bloque funcional de «Recursos de Cómputo» los autores proponen las Fórmulas 1 y 2, tomadas de los resultados investigativos de Chris Wolf y Erick M. Halter ¹⁴, para dimensionar los nodos de procesamiento (Unidades Centrales de Procesamiento (CPU, Central Processing Unit), Memoria de Acceso Aleatorio (RAM, Random Access Memory)) en función del número de MV a soportar y sus características.

Fórmula 1: # de núcleos para las MV = (# de procesadores del nodo) * (# de núcleos lógicos de cada procesador) - 1

Fórmula 2: Capacidad de RAM disponible para las MV = Capacidad de RAM del nodo Capacidad de RAM necesitada por el SO del nodo Capacidades de RAM necesitadas por los SO invitados 1 GB

La Fórmula 1 permite determinar la cantidad de núcleos que los nodos pueden brindar a las MV que van a hospedar, teniendo en cuenta que se debe reservar un núcleo de procesamiento para el uso exclusivo del nodo. Se usa el término de «núcleos lógicos» por la posibilidad de que existan tecnologías, como el hyper-threading. Con la cantidad de núcleos que la computadora hospedera puede brindar a las MV, se determina la cantidad de MV que puede ser hospedada, en dependencia del número de núcleos que se les requiera asignar. Se propone como criterio práctico para evitar la ralentización excesiva del procesamiento, que cada núcleo disponible no atienda a más de cuatro núcleos virtuales ¹⁵. La Fórmula 2 indica la capacidad de RAM que el nodo puede poner a disposición de las MV, para lo cual se debe considerar que se dedica 1 GB para uso exclusivo del nodo en aras de evitar la sobreexplotación de la memoria por parte de las MV. El desempeño del nodo y de las MV puede ser mejorado mediante la activación de las tecnologías dual-channel o tri-channel.

En el bloque funcional de Almacenamiento, con el objetivo de aprovechar las ventajas que proporciona la utilización de los sistemas de Almacenamiento Conectado a la Red (NAS, Network Attached Storage) y de Redes de Área de Almacenamiento (SAN, Storage Area Network), y la tendencia de los principales proveedores de emplear sistemas de almacenamiento unificados, los autores proponen un sistema de tipo «híbrido» como solución. El NAS debe almacenar datos temporales de usuarios y en general datos no críticos para la entidad, mientras la SAN se destinará a los servicios y aplicaciones de mayor importancia. En la sub-capa de gestión y monitoreo centralizado los autores proponen que se gestione de manera unificada el sistema de almacenamiento híbrido, se soporten las funciones declaradas en esta sub-capa por la UIT ⁶ y las técnicas de optimización de capacidades como la de-duplicación, la automatización de niveles de almacenamiento y de la gestión de volúmenes, para aumentar el uso eficiente de los recursos y la escalabilidad.

Fórmula 3: Capacidad de la MV = Capacidad básica requerida por el SO + Capacidad requerida para el almacenamiento de los ficheros log (bitácoras) + Capacidad requerida para la funcionalidad de suspensión y reinicio + Capacidad adicional de seguridad

El diseño de la red intra-Nube debe soportar los requerimientos planteados por la UIT ⁶. Los autores proponen una infraestructura de red convergente con una topología jerárquica parcialmente mallada como se muestra en la Figura 5. En la capa de agregación si el tráfico de broadcast fuese excesivo los dominios pueden ser segmentados mediante Redes de Área Local Virtuales (VLAN, Virtual Local Area Network), o pueden emplearse los protocolos en proceso de estandarización: Interconexión Transparente de Muchos Enlaces (TRILL, Transparent Interconnection of Lots of Links) o Shortest Path Bridging (SPB)/802.1aq. Estos protocolos permiten lograr un uso más efectivo del ancho de banda, mayores niveles de estabilidad, escalabilidad y desempeño, e incluso soportar los nuevos requerimientos de movilidad de la carga de trabajo, aunque encarecen la solución ^{6 10}.

Para alcanzar un buen nivel de disponibilidad y evitar la competencia entre los distintos tipos de tráfico, se propone para centros de datos de gama alta el empleo de tres Tarjetas de Interfaces de Red (NIC, Network Interface Card) en los nodos, de dos puertos cada una, con la siguiente distribución: NIC 1 - un puerto para el tráfico de gestión y el otro para el tráfico de las MV; NIC 2 - un puerto para el tráfico de las MV y el otro para el tráfico de almacenamiento; y NIC 3 - un puerto para el tráfico de almacenamiento y el otro para el tráfico de gestión. En caso de que no exista la posibilidad de dedicar NIC físicas se pueden emplear VLAN capaces de aislar los tipos de tráfico, requiriendo menos NIC, pero con soporte de enlaces a mayores velocidades, de modo que no se vea afectado el usuario final.

En el caso de centros de datos de gama baja y media se propone que se empleen en los nodos dos NIC de un puerto y emplear VLAN para el aislamiento de los tráficos. El tráfico de gestión demanda mucho menos ancho de banda que el de almacenamiento y el generado por las MV, razón por lo cual puede dedicarse una NIC al de mayor requerimiento de ancho de banda, y la otra encargarse de los dos tráficos restantes, aislándolos mediante VLAN. En el caso de errores en una NIC, su tráfico deberá ser asumido por la segunda tarjeta. Se puede observar que el fallo individual de cualquiera de las NIC, tanto para los centro de datos de gama alta, media o baja, no provoca afectación a la disponibilidad del sistema debido a que no existen puntos únicos de fallo. Los dispositivos de interconexión deben ser gestionables y soportar políticas de seguridad, QoS, VLAN y tramas jumbo. Las velocidades de sus interfaces se encuentran en función de la cantidad de usuarios de la empresa y la carga ofrecida a la red por cada uno.

La capa paralela «Gestión de la Arquitectura y los Servicios» resulta un híbrido de la capa de Funciones Comunes a las Capas de la UIT ^{4 9} y el componente de Gestión del Servicio Nube del NIST ³, debido a que la primera se centra en las funcionalidades necesarias para la gestión total de la Arquitectura Nube, mientras que el segundo aporta elementos para la gestión y operación de los servicios Nube ofertados. Como se muestra en la Figura 4 consta de cuatro bloques funcionales:

- Soporte del Negocio: tomada de la Arquitectura de Referencia del NIST ³, con la adición de la funcionalidad de modelos de costos, en donde se recoge la función de precios de la NIST.

En la gestión de usuarios los autores proponen permitir crear y eliminar cuentas de usuarios, autenticar por medio de contraseñas modificables, mostrar las cuentas de usuario y definir cuotas para usuarios y grupos de usuarios. En la definición de cuotas se propone incluir los parámetros que limita CloudStack ¹⁰ y los parámetros de cantidad de CPU y RAM definidos por OpenNebula ¹⁰. En la gestión de roles de usuario se propone permitir que los administradores creen subgrupos dentro de una misma organización y asignen administradores delegados a tales subgrupos. En la gestión de inventario los autores proponen que las interfaces de usuario tengan disponibles plantillas por defecto, las que pueden ser modificadas e incluso crear nuevas que podrán ser compartidas si se autoriza. Estas deberán permitir definir el hardware de las MV, SO, softwares necesarios, alta disponibilidad y los requerimientos a tener en cuenta a la hora del despliegue de las mismas. Se deberá admitir la capacidad de crear MV a partir de instantáneas (snapshots).

En la gestión de reportes los autores proponen que: a) los usuarios y los administradores puedan solicitar y recibir reportes de contabilidad, eventos del sistema, uso de los recursos de los nodos, usuarios y grupos; b) brindar la posibilidad de configurar la forma en que se generan los reportes: por usuario o por grupos de usuarios, la frecuencia de generación y la fecha de vencimiento; y que c) los reportes sean exportados en diferentes formatos como el Formato de Documento Portátil (PDF, Portable Document Format) y el Word.

En la gestión de los modelos de costos los autores proponen que en la facturación los usuarios/grupos de usuarios puedan personalizar los modelos de costos para adaptarse a las necesidades variables de la organización; y que puedan revisar sus consumos y facturas a través de los reportes de contabilidad.

En este bloque los autores proponen implementar mecanismos para la recuperación ante fallos en las MV, los nodos y el propio gestor de la Nube. Se propone hacer salvas de manera programada a los archivos de configuración de las MV, a los archivos de sistema de los servidores, nodos y bases de datos. Además se deben hacer instantáneas de los volúmenes de discos del sistema o discos de datos e implementar la Alta Disponibilidad en las MV. Además los nodos, las aplicaciones y el gestor deben ser actualizados, automática y manualmente, a través de una gestión centralizada. El mantenimiento debe ser realizado sin afectar el rendimiento y disponibilidad de los servicios brindados, para ello se propone el inicio de los nodos en modo mantenimiento y el cálculo del número de nodos a actualizar simultáneamente.

- Desempeño: definida por ambas organizaciones ^{4 9} (el NIST la define como monitoreo y reportes) para el monitoreo y control de la Arquitectura Nube. Debe indicar el nivel de desempeño del sistema, el grado de explotación, las fallas, las alertas, entre otras funciones. Contiene la función de auditoría, definida por la UIT ⁴, para colectar los eventos del sistema como accesos e información de reportes por usuario y servicios.

Los autores proponen que los elementos a ser monitoreados sean los nodos, MV, tráfico de red, almacenamiento y aplicaciones a través de métricas que permitan identificar los niveles de explotación, desempeño y disponibilidad del sistema. La información de monitoreo debe ser mostrada en forma gráfica de varios tipos y resúmenes porcentuales para una mayor comprensión por parte de los usuarios y los administradores. Las gráficas y resúmenes deben ser personalizables, actualizando la información a intervalos de tiempo configurables. Los eventos y la información sobre estos deben permitir al usuario verificar los cargos hechos a su cuenta, mostrando las fuentes de datos.

- Seguridad y Privacidad: definida por ambas organizaciones ^{3 4}. Los autores proponen que abarque las funciones (controles) necesarias para cumplir con los requerimientos (privacidad, integridad, disponibilidad, confidencialidad, regulaciones) que se impongan y abarcar las nuevas perspectivas de seguridad particulares de la Computación en la Nube. Se debe prestar atención a los hipervisores para lograr el aislamiento necesario entre las MV, al despliegue o no de controles en la frontera de la Nube Privada y a la correcta determinación de las responsabilidades del proveedor y de los usuarios.

SOLUCIÓN PARA EL DESPLIEGUE DE UNA INFRAESTRUCTURA DE NUBE PRIVADA BASADA EN HERRAMIENTAS DE SLCA

La solución para el despliegue de la infraestructura de la Nube Privada se condicionó al empleo del gestor de Nube OpenNebula dados los resultados comparativos de las soluciones SLCA mostrados en la sección «Soluciones disponibles para el despliegue de Nubes Privadas con soporte para IaaS», tomándose en cuenta además las recomendaciones emitidas por las organizaciones de estandarización consultadas y las soluciones de Nubes Privadas de los principales proveedores analizadas.

En la capa de Usuario los clientes acceden a la Nube Privada a través de diferentes interfaces, como la Interfaz de Auto-Servicio de OpenNebula y la Interfaz Abierta de Computación en la Nube (OCCI, Open Cloud Computing Interface). En su capa de Servicios OpenNebula no soporta intrínsecamente el despliegue automático y elástico de clústeres
virtuales, por lo que se le deben integrar herramientas concebidas para este fin como Claudia, Carina y el Administrador de Servicios OpenNebula.

De las tecnologías de virtualización SLCA que soporta OpenNebula, OpenVZ y la para-virtualización con Xen son los que mejores niveles de desempeño y escalabilidad presentan, siendo el primero el que más destaca en pruebas realizadas ¹⁷. Por tanto, en el bloque funcional de Concentración y Virtualización se recomiendan en primera opción el empleo de OpenVZ y Xen con para-virtualización. Estas dos soluciones poseen como restricción el empleo de SO Linux y/o UNIX. OpenVZ soporta en sus contenedores las diferentes distribuciones del SO Linux del núcleo del nodo. Xen con la para-virtualización requiere de SO modificados para las MV de los Dominios U, existiendo hoy de las familias UNIX y Linux. Si los requerimientos devienen en barreras para el cliente, y sin embargo el empleo de procesadores con soporte para la Virtualización Asistida por Hardware (HVM, Hardware-assited Virtual Machine) no, se recomienda el empleo de Xen con HVM o de KVM. En el escenario de nodos heterogéneos (algunos con soporte para HVM y otros no) se aconseja el empleo de Xen. En entornos que requieran la virtualización de SO heterogéneos (Windows sobre nodos Linux y viceversa), y no se disponga de hardware con soporte para HVM, se recomienda el empleo de VirtualBox. Este hipervisor no tiene los niveles de desempeño de los anteriores, no soporta la migración en caliente con OpenNebula, pero posee la ventaja de poder soportar en sus MV a cualquier SO sin modificación alguna y soporta el estándar OVF de la DMTF.

Se propone el empleo de una SAN de Sistema para Pequeñas Computadoras de Internet (iSCSI, Internet Small Computers System Interface) (SAN iSCSI) debido a que: a) presenta menores costos que las SAN de Canal de Fibra sobre Ethernet (FCoE, Fibre Channel over Ethernet) (SAN FCoE) y las SAN Multi-Protocolo que requieren de dispositivos de red que las soporten, b) los recursos de almacenamiento de las SAN de ATA sobre Ethernet (AoE, ATA over Ethernet) (SAN AoE) actualmente son solo proveídos por Coraid, c) puede alcanzar valores de desempeño comparables a los de las SAN FC, y d) permite desplegar una red convergente en el centro de datos ¹⁰.

Se propone el empleo de una fabric SAN jerárquica parcialmente mallada con dos conmutadores de enlace de núcleo, conectados a más de un conmutador de enlace de acceso. En caso de aumentar la escalabilidad los conmutadores de núcleo deben ser de la capa de red. Los enlaces para la SAN iSCSI y el front-end deben ser de velocidad Gigabit Ethernet, aunque si se requieren mayores índices de desempeño deben ser de 10 Gigabit Ethernet.

Se propone el empleo de más de una NIC Ethernet con soporte para tramas jumbo para los servidores y dispositivos terminales de almacenamiento, por ser la alternativa con mejor relación costo-beneficio y responder a los objetivos principales de este trabajo. Las NIC que implementan Motor de Descarga de Protocolo de Control de Transporte (TCP, Transport Control Protocol)/Protocolo de Internet (IP, Internet Protocol) (NIC-TOE, NIC supporting TCP Offload Engine) y los Buses para Terminales (HBA, Host Bus Adapter) iSCSI (iSCSI HBA), presentan un costo muy superior a las NIC comunes y las diferencias de desempeño pueden suplirse en gran medida utilizando NIC de mayor velocidad y bajas demoras de procesamiento. Se propone emplear servidores con más de un procesador multi-núcleo con una frecuencia superior a los 2 GHz, en aras de mejorar el desempeño y disminuir las demoras que pudiera ocasionar la sobrecarga de procesamiento, debida a la utilización por iSCSI de las capas superiores del modelo TCP/IP.

OpenNebula almacena las imágenes de las MV en un repositorio de imágenes (sistema de almacenamiento) el cual puede ser compartido o no por los nodos. Se propone la primera configuración en donde la capacidad requerida en el almacenamiento local en los nodos será baja pues los ficheros necesarios para el despliegue de las MV serán tomados directamente del sistema de almacenamiento.

OpenNebula logra la integración de las redes física y virtual a través de Open Virtual Switch (OVS, Open Virtualization Switching)-NetFlow-Generic Routing Encapsulation (GRE) y otras funcionalidades, requiriendo un mayor consumo de los recursos en los nodos. La explotación de los recursos de los nodos puede ser reducida, logrando mayores índices de desempeño si se emplean conmutadores IBM con tecnología VMready, con soporte para 802.1Qbg, ya que la plataforma de virtualización de OpenNebula no soporta las nuevas tendencias de integración de las redes física y virtual (802.1Qbg y 802.1BR).

En la capa de Gestión de la Nube Privada y Servicios de la Nube se propone la integración de las herramientas Ganglia para mejorar el número de métricas de desempeño a ser monitorizadas en la infraestructura y de la herramienta Cluster Energy Saving (CLUES) para la gestión eficiente de la energía del centro de datos.

VALIDACIÓN PARCIAL DE LA SOLUCIÓN PROPUESTA

La validación de la propuesta se realiza de manera parcial y sobre diferentes escenarios de pruebas dada la escasez de los recursos necesarios para llevar a cabo una validación integral, que permita comparar los resultados obtenidos con los de soluciones comerciales. Los escenarios recreados son semejantes a la solución propuesta, siendo los recursos de hardware y software empleados de propósito general y SLCA respectivamente.

A través de pruebas de configuración se evidenció:

- La posibilidad de un usuario de tener acceso a los servicios mediante el portal de auto-servicio de OpenNebula para crear y explotar MV según los permisos y cuotas asignados en el Soporte del Negocio. Esta prueba fue realizada sobre una plataforma de virtualización con el hipervisor VMware ESXi en el escenario mostrado en la Figura 8. La Figura 9 muestra evidencia de cómo el usuario recibe notificaciones de error cuando sobrepasa los límites de las cuotas que le fueron asignadas. La Figura 10 muestra cómo un usuario puede tener acceso a los servicios mediante el portal de auto-servicio según los permisos asignados y sus necesidades reales.

A través de una prueba de desempeño (tipo benchmark) y otra de escalabilidad, se comprobó la no sobre explotación de los recursos de CPU y RAM de los nodos de procesamiento, si los recursos virtuales son dimensionados con las Fórmulas 1 y 2. Los criterios de aceptación tomados en cuenta en las pruebas realizadas fueron que los niveles de utilización del CPU y la RAM de los nodos se mantuviesen dentro de los umbrales recomendados por ¹⁹ y adoptados por la comunidad científica: del 75% al 80% para el uso de las capacidades de RAM, y del 85% al 90% del poder de cómputo del CPU. La Figura 11 muestra el escenario de prueba. La aplicación SPEC CPU2006, empleada por la DMTF y el Instituto de Ingeniería Eléctrica y Electrónica (IEEE, Institute of Electrical and Electronics Engineers) en evaluaciones al desempeño de disímiles hipervisores ²⁰, se utilizó para añadir carga a las MV. Las MV fueron estresadas llevando el uso de sus recursos virtuales hasta un: 96,9%-MV1, 95,1%-MV2 y 95,7%-MV3 en el caso de la RAM, y un 100% del uso del CPU en las tres. La Tabla 1 muestra la no sobre explotación de los recursos en los nodos después del estrés.

En la prueba de escalabilidad realizada en el escenario anterior se observó que al superar el número máximo calculado de MV (tres) a desplegar en el nodo, el desempeño de las mismas comenzó a declinar al medirse las métricas de throughput, tiempo de respuesta y porcentaje de utilización de la CPU y la RAM del nodo, como muestran las Figuras 12, 13 y 14. El throughput fue medido con el software NetPerf 2.5, herramienta empleada por la IEEE en pruebas para medir el desempeño de distintos tipos de redes, y el tiempo de respuesta con la herramienta Ntop 4.1, proyecto de SLCA multiplataforma que cuenta con una sencilla interfaz web, la cual dispone de una gran variedad de informes.

A través de las pruebas anteriores se pudo comprobar: a) la facilidad del uso del auto-aprovisionamiento bajo demanda, requerimiento en la capa de «Usuario» en la Arquitectura propuesta y soportado por las soluciones comerciales; b) el soporte de múltiples hipervisores, con diferentes tipos de virtualización, por parte de OpenNebula, al igual que las soluciones comerciales, lo que permite ajustarse a los recursos y necesidades reales del cliente; c) la no sobre explotación de los recursos de CPU y RAM de los nodos de procesamiento, si los recursos virtuales son calculados con las Fórmulas 1 y 2 del bloque de «Recursos de Cómputo» de la Arquitectura propuesta; d) el empleo de hardware de propósito general como recursos de cómputo si se dimensionan correctamente, disminuyendo los costos de la solución de Nube Privada, junto al empleo de herramientas SLCA como el gestor de Nube y el hipervisor; y e) la capacidad de desplegar y monitorizar MV a través de OpenNebula, así como el correcto funcionamiento de la definición de cuotas por usuario, funcionalidad contenida en el bloque de «Gestión de Usuario» de la Arquitectura propuesta y en todas las soluciones comerciales.

CONCLUSIONES

El modelo de servicio de Nube Privada constituye una posible solución económica, efectiva y segura para las infraestructuras TIC de las instituciones, dotándolas de una infraestructura dinámica con un nivel de escalabilidad capaz de responder rápidamente a la demanda de los servicios TIC. La investigación desarrollada hace aportes en el diseño de Nubes Privadas con soporte para IaaS a partir de hardware heredado y herramientas de SLCA para entidades con fuertes restricciones económicas, concretamente:

- La propuesta de una Arquitectura de Referencia que define el Ecosistema y Arquitectura Funcional para conformar una arquitectura de Nube Privada localizada dentro de la entidad y gestionada por la misma, basada en las Arquitecturas de Referencia genéricas de una Nube del NIST, la UIT y la DMTF; y las recomendaciones, herramientas, tecnologías y criterios de dimensionamiento empleados hoy por los principales proveedores de soluciones Nube.

- Una solución para el despliegue de Nubes Privadas basada en hardware de propósito general y SLCA que responde a la Arquitectura de Referencia propuesta. Se propone a OpenNebula como gestor, al considerarse por los autores el más integral entre los gestores SLCA analizados, y herramientas que complementan determinadas insuficiencias del mismo.

La solución destaca por soportar una multi-plataforma de virtualización que permite adaptarse a los requerimientos y restricciones del cliente, recomendándose por los valores de desempeño demostrados a OpenVZ y Xen; y un sistema de almacenamiento compartido, con adecuados niveles de desempeño, escalabilidad y disponibilidad que permite el despliegue de una red convergente basado en una SAN iSCSI, tecnología con mejor relación beneficio/costo para una entidad a consideración de los autores.

La validación de la propuesta se realizó de manera parcial y en diferentes escenarios de pruebas, semejantes al de la solución, en donde se realizaron pruebas de configuración, desempeño y escalabilidad, que permitieron comprobar funcionalidades, criterios de selección de tecnologías de hardware y software, y fórmulas para el dimensionamiento de los recursos de cómputo en función de la demanda del cliente.

REFERENCIAS

1. GARCÍA PERELLADA LR, GARÓFALO HERNÁNDEZ AA, GONZÁLEZ POL, ET AL.: «Propuesta de arquitectura para una nube privada con soporte para infraestructura como servicio». En: Informática 2013, VI Simposio de Telecomunicaciones. Palacio de las Convenciones, La Habana, Cuba; 2013. p. 11. ISBN: 978-959-7213-02-4.

2. LIU Y, LIU W, LIU L, ET AL.: «An Infrastructure Framework for Deploying Enterprise Private Cloud». Proceedings of the 2013 IEEE International Conference on Services Computing [en línea]. Washington, DC, USA: IEEE Computer Society; 2013 [cited 2014 Sep 11]. p. 50210. Disponible en: http://dx.doi.org/10.1109/SCC.2013.99.

3. LIU F, TONG J, MAO J, ET AL.: «NIST: Cloud Computing Reference Architecture» [en línea]. NIST Special Publication 500-292. [Gaithersburg, Estados Unidos de América]: National Institute of Standards and Technology, September 2011.

4. UIT-T: «Part 1: Introduction to the cloud ecosystem: definitions, taxonomies, use cases and high-level requirements». Geneva: ITU-T; 2012 Feb p. 69. Report No.: Part 1.

5. DMTF: «Interoperable Clouds» [en línea]. DSP-IS0101. Distributed Management Task Force, Inc. (DMTF), 2009-11-11, [cited 2012 Jul 10]. Disponible en: http://dmtf.org/sites/default/files/standards/documents/DSP -IS0101_1.0.0.pdf.

6. UIT-T: «Part 3: Requirements and framework architecture of cloud infrastructure». FG Cloud Technical Report Part 3. [Geneva]: ITU-T, 2012 Feb.

7. UIT-T: «Part 6: Overview of SDOs involved in cloud computing». FG Cloud Technical Report Part 6. [Geneva]: ITU-T, 2012 Feb.

8. DMTF: «Use Cases and Interactions for Managing Clouds» [en línea]. DSP-IS0103. Distributed Management Task Force, Inc. (DMTF), 2010-06-18, [cited 2012 Jul 10]. Disponible en: http://dmtf.org/sites/default/files/standards /documents/DSP-IS0103_1.0.0.pdf.

9. UIT-T: «Part 2: Functional requirements and reference architecture». FG Cloud Technical Report Part 2. [Geneva]: ITU-T, 2012 Feb.

10. GARCÍA PERELLADA LR.: «Propuesta de arquitectura para una Nube Privada con soporte para Infraestructura como Servicio». Director: Alain Abel Garófalo Hernández. Tesis de Maestría. Instituto Superior Politécnico José Antonio Echeverría (ISPJAE), Departamento de Telecomunicaciones y Telemática, 2014.

11. AMRANI CE, FILALI KB, AHMED KB, ET AL.: «A Compartive Study of Cloud Computing Middleware». En: 2012 12th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid). 2012. p. 6903.

12. DMTF: CLOUD | DMTF [en línea]. DMTF, 2012, [cited 2012 Jul 10]. Disponible en: http://dmtf.org/standards/cloud .

13. MICROSOFT.: «Hyper-V Cloud Fast Track Program, Reference Architecture Technical White Paper». Microsoft Corporation, 2011.

14. WOLF C, HALTER EM.: «Virtualization: From the Desktop to the Enterprise». Apress, 2005. 600 p.

15. MICROSOFT.: «Hyper-v cloud deployment guides module 1: architecture and sizing. Microsoft Corporation», 2010.

16. LASZEWSKI T, NAUDURI P.: «Migrating to the Cloud». 1a ed. 225 Wyman Street, Waltham, MA 02451, USA: Elsevier Inc., 2012.

17. MAHJOUB M, MDHAFFAR A, HALIMA RB, ET AL.: «A Comparative Study of the Current Cloud Computing Technologies and Offers». En: 2011 First International Symposium on Network Cloud Computing and Applications (NCCA). 2011. p. 1314.

18. CASMARTIÑO BONDARENKO FC, LARA BRITO A, GARCÍA PERELLADA LR.: «Comparación de Sistemas de Ficheros Distribuidos». En: 17 Convención Científica de Ingeniería y Arquitectura. Palacio de las Convenciones, La Habana, Cuba; 2014.

19. MEYLER K, FULLER C, JOYNER J, ET AL.: «System Center Operations Manager 2007 R2 Unleashed». United States of America: Pearson Education, Inc., 2010. 527 p.

20. CHE J, YU Y, SHI C, ET AL.: «A Synthetical Performance Evaluation of OpenVZ, Xen and KVM». En: Services Computing Conference (APSCC). Asia-Pacific: IEEE, 2010. p. 58794.

Recibido: Diciembre 2014 ]]> Aprobado: Febrero 2015