Arquitectura de Nube Privada para un Centro de Cómputo · gestiona las aplicaciones y los...

Universidad Técnica Federico Santa María

Departamento de Informática

Magíster en Tecnologías de la Información

1

Arquitectura de Nube Privada para un Centro de Cómputo

Roberto Schiaffino Mascareño

Manuel Rodríguez N° 328, Limache, Región de Valparaíso.

[email protected]

Resumen: El presente trabajo propone una adaptación de la arquitectura del principal centro de cómputo de una Institución Pública, aplicando tecnologías de virtualización, mejorando de esta forma la eficiencia en la utilización de los recursos y orientando la oferta de servicios hacia IaaS y PaaS. El rediseño de la infraestructura de servicios hacia el concepto de nube privada permitirá reducir los costos inversión, operación y mantenimiento, además de facilitar el gobierno y entrega de servicios de TI, permitiendo cumplir con los niveles de disponibilidad que la organización establece para sus aplicaciones. Los resultados serán validados efectuando mediciones y comparaciones de rendimiento energético, costos operacionales y de infraestructura TI, desde la configuración tradicional a la propuesta de nube privada. Palabras Clave: Cluster, Datacenter, Energía, Nube privada, Virtualización.

1 Introducción

Ante la necesidad de optimizar los recursos y cumplir con los acuerdos de niveles de servicio (S.L.A.), las organizaciones están adoptando tecnologías de virtualización de infraestructura, buscando una operación más eficiente, ágil y resiliente. La concentración de alta capacidad de cómputo y almacenamiento en los servidores de última generación ha permitido la implementación de estas tecnologías y el desarrollo de soluciones de software que facilitan la gestión y escalabilidad de mencionadas plataformas, convirtiéndolas en clústeres que ejecutan grandes cantidades de aplicaciones basadas en servidores o microservicios virtuales. La rápida adopción de servicios en la nube por parte de algunas organizaciones, buscando externalizar la administración de su infraestructura y traspasar costos de inversión a costos de operación, ha llevado a otras a evaluar la conveniencia de aplicar estos paradigmas en busca de la optimización de recursos, cuando las restricciones de confidencialidad impiden externalizar los servicios de TI. Teniendo en cuenta la naturaleza de la información que maneja y la madurez alcanzada en la entrega de servicios TI a sus clientes internos, además de encontrarse ante un nuevo ciclo de renovación de la base de infraestructura que compone su principal centro de cómputo, se analizarán las implicancias de habilitar una nube privada en el Centro de Tecnologías de la Información (C.T.I.). En primer lugar, se presentarán la hipótesis y los objetivos en los que se basa esta investigación. A continuación, se explicará el fundamento teórico y el estado del arte de las tecnologías de nube, para luego exponer la situación actual del datacenter del C.T.I., en lo que respecta a su infraestructura tecnológica y los servicios que entrega. Luego de describir la situación actual, se propondrá el diseño de una nueva arquitectura del datacenter aplicando tecnologías de nube privada, buscando proveer servicios de plataforma e infraestructura en una implementación ad-hoc a las características de espacio, energía, conectividad, disponibilidad de recursos y realidad presupuestaria. Con los datos recopilados desde mediciones, registros y estimaciones de diversas fuentes, se procederá a validar la hipótesis planteada en esta Tesina, finalizando el documento de esta investigación con las conclusiones obtenidas y el trabajo futuro que puede generarse a partir de la implementación de la nube privada en el Centro de Tecnologías de la Información.




2

2 Hipótesis y Objetivos

2.1 Hipótesis

La aplicación de tecnologías de cloud computing en el datacenter permitirán reducir el consumo energético y los tiempos de despliegue de aplicaciones, además de la reducción de los recursos materiales (hardware y software) necesarios para la operación del mismo.

2.2 Objetivos Específicos

Los siguientes son los objetivos específicos considerados en el desarrollo del presente trabajo: ● Proponer una nueva configuración del centro de cómputo, orientando la organización de la infraestructura

de servidores y plataforma de servicios hacia un modelo de nube privada. ● Reducir el consumo energético del datacenter. ● Reducir los costos de inversión y de operación de las aplicaciones que se habiliten en el datacenter. ● Mejorar o asegurar el cumplimiento de los indicadores de acuerdos de niveles de servicio relacionados con

disponibilidad de la infraestructura, plataforma y aplicaciones críticas. ● Reducir el tiempo de despliegue de aplicaciones.

2.3 Metodología para validar la Hipótesis

Efectuando mediciones, estimaciones y simulaciones de rendimiento energético, estimaciones de costos por instancia de servidor virtual y tiempo de despliegue se determinarán los parámetros que permitirán la comparación con los indicadores actuales y probar la Hipótesis.

3 Marco Teórico

De acuerdo a lo establecido por el Instituto Nacional de Estándares y Tecnología del Departamento de Comercio de EE.UU. (NIST), “la computación en la nube es un modelo para permitir acceso vía red, conveniente y ubicuo a un conjunto de recursos de computación configurables (por ejemplo, redes, servidores, almacenamiento, aplicaciones y servicios) que pueden ser rápidamente provisionados y entregados con mínimo esfuerzo o interacción del proveedor de servicios”[1]. La computación en la nube tiene cinco características esenciales, a saber: autoservicio a demanda, intenso acceso a la red, agrupación de recursos de computación, elasticidad para permitir escalamiento de capacidades de acuerdo a la demanda y medición de los servicios entregados. La infraestructura en la cual se basa la computación en la nube puede ubicarse en lugares distantes sacando ventaja de las redes de alta velocidad o concentrarse en datacenters aprovechando la alta densidad de potencia de cómputo disponible. En esta infraestructura, los recursos se entregan virtualizadamente a los clientes, ajustando su asignación a requerimiento y de forma autónoma. Junto con lo anterior, dependiendo del tamaño de la infraestructura, la ubicación donde se despliega y quién gestiona las aplicaciones y los servicios, la computación en la nube define 4 modelos de despliegue: ● Nube privada: La infraestructura es operada sólo por una organización. Puede ser gestionada por la misma

organización o por terceros y puede existir dentro o fuera de las instalaciones de ésta. ● Nube pública: La infraestructura está disponible al público en general o a un segmento de una industria

específica. Es propiedad de una empresa cuyo negocio es vender servicios de nube.




3

● Nube híbrida: La infraestructura está compuesta por dos o más nubes que se mantienen como entidades únicas, pero operan en conjunto por medio de tecnologías que permiten portabilidad de datos y aplicaciones (por ejemplo, cloud bursting para balanceo de carga entre nubes).

● Nube comunitaria: La infraestructura es compartida entre varias organizaciones y soporta una comunidad específica que tiene preocupaciones compartidas (por ejemplo, misión, requerimientos de seguridad, políticas y consideraciones de cumplimiento). Puede ser gestionada por las mismas organizaciones o por terceras partes y puede existir dentro o fuera de las instalaciones [2].

Dependiendo de las capacidades de control sobre las distintas capas de servicios de computación que se otorgan a los usuarios o clientes, se definen tres modelos de entrega: ● Infraestructura como Servicio: Se entrega capacidad al cliente para gestionar el procesamiento,

almacenamiento, redes y otros recursos de computación. El usuario puede instalar y ejecutar software a su arbitrio, lo cual incluye sistemas operativos y aplicaciones. El cliente no gestiona la infraestructura subyacente, pero tiene control sobre el sistema operativo, almacenamiento, aplicaciones y sobre algunos componentes de redes.

● Plataforma como Servicio: Se entrega capacidad al cliente para instalar aplicaciones desarrolladas por sí mismo o terceros, utilizando sólo lenguajes de programación y herramientas soportadas por el proveedor de nube. El usuario no gestiona la infraestructura o software subyacente como la red, servidores, sistema operativo o almacenamiento. Sin embargo, tiene control sobre las aplicaciones instaladas por él y sobre las configuraciones del ambiente para soportar su ejecución.

● Software como Servicio: Se entrega capacidad al cliente para utilizar las aplicaciones del proveedor que están ejecutándose en la infraestructura de Nube. El usuario no gestiona ni controla la infraestructura subyacente, sólo se le permite realizar ciertos ajustes en la configuración de las aplicaciones que utiliza.

La figura 1 resume los modelos y características principales que definen la computación en la nube, descritas anteriormente.

Figura 1. Modelos de computación en la nube (Fuente [2])




4

La figura 2 muestra los tres modelos de servicios y las áreas de responsabilidad de gestión tanto del cliente como del proveedor, con respecto a las capas que componen la infraestructura en la que se basan y los componentes que conforman las aplicaciones. En este diagrama, se aprecia la existencia de una capa de virtualización que abstrae los elementos de hardware (servidores, almacenamiento y red) que permiten el despliegue de éstas y sus componentes de software (datos, runtime, middleware y sistema operativo).

Figura 2. Modelos de servicios de nube (Fuente: [3])

Así, es posible definir la existencia de una máquina virtual que se ejecuta en un ambiente de virtualización, habilitado sobre la infraestructura de hardware (Fabric). Esta máquina virtual concentra el entorno de ejecución, los datos y las aplicaciones en sí mismas. Cada uno de estos componentes integran tanto las secciones de interés para el usuario, así como también el entorno de ejecución, virtualización y fabric, permitiendo identificar su correspondencia al modelo de servicio de nube relacionado, dependiendo del nivel de abstracción: Infraestructura (Máquina Virtual), Plataforma (Entorno de ejecución) y Software (Aplicación y Datos), como se muestra en la figura 3.

Figura 3. Ambiente de ejecución de una máquina virtual (Fuente [4])




5

4 Estado del Arte

La implementación de nubes privadas involucra la utilización de software diseñado para concentrar recursos de computación, entiéndase servidores y almacenamiento, y emplearlos como plataforma única donde se habilitan máquinas virtuales y/o aplicaciones que se entregan a los usuarios, proporcionando agilidad y flexibilidad ante los diversos requerimientos, a la vez de elasticidad de recursos, respondiendo automáticamente a variaciones de carga de trabajo y otorgando alta disponibilidad de las aplicaciones por la tolerancia ante fallos que se logra. Existen diversos productos en el mercado, tanto de fuente abierta como si no, que permiten llevar a cabo estas implementaciones, permitiendo la convergencia y escalabilidad de computación y almacenamiento utilizando los mismos servidores físicos que se integran al conjunto para cumplir tales funciones. En cualquier caso, la tendencia es convertir el centro de cómputo en uno definido por software, existiendo las herramientas para implementar no sólo computación, sino que también almacenamiento y redes definidas por software, siendo necesario la adición de nodos servidores cuando los requerimientos de conectividad, escalabilidad o elasticidad así lo establezcan. En general, las tecnologías de virtualización y contenerización o microservicios han sido adoptadas en los datacenters modernos para aumentar la eficiencia en el uso de los recursos de hardware y energía, ahorrando además tiempo y espacio, reduciendo los costos de operación[5]. En el último tiempo, se aprecia la consolidación de diversas herramientas de virtualización de servidores en el mercado, abarcando un segmento importante de éste, las suites de productos de fabricantes tales como VMWare (vSphere), Microsoft (Hyper-V) y Red Hat (Red Hat Virtualization). Los primeros dos fueron clasificados por Gartner como líderes en su cuadrante mágico de agosto de 2016, mientras que Red Hat fue clasificado como visionario en el mismo cuadrante[6]. Si bien las herramientas de virtualización de servidores son utilizadas para proveer principalmente IaaS en las nubes privadas, los fabricantes han desarrollado herramientas de software para entregar almacenamiento, red, gestión y monitoreo de la arquitectura convergente, la que a la vez de heterogénea, requiere la utilización de API para centralizar la operación de la Nube o el Datacenter Definido por Software (SDDC). Así es como VMWare propone vCloud Suite para la gestión de la Nube Privada. En el caso de Microsoft, System Center es el nombre de la solución que permite la gestión del SDDC. En el ámbito del Opensource, Openstack ofrece también componentes para el monitoreo, aprovisionamiento de máquinas virtuales, gestión de configuración, networking y almacenamiento, entre otros[7]. Varios proveedores de servicios ofrecen su propia versión de arquitectura de Openstack, utilizando los componentes necesarios de la suite para construir una nube privada de grado empresarial, entre los cuales destacan Red Hat, Oracle y Rackspace. Para entregar PaaS, proveyendo a los desarrolladores un ambiente para crear, instalar y desplegar aplicaciones, los contenedores ofrecen la posibilidad de abstraer las capas sobre las que éstas se ejecutan y por tanto entregar el servicio de plataforma a demanda. Un contenedor es una pieza de software que incluye todo lo necesario para ejecutarse: código, runtime, herramientas y bibliotecas del sistema además de las distintas configuraciones. El software en un contenedor siempre se ejecutará de la misma forma, independiente del ambiente, debido a que el código del programa y sus dependencias se empaquetan en conjunto. Es posible ejecutar múltiples contenedores en la misma máquina y compartir el kernel del sistema operativo con otros contenedores, cada uno ejecutándose como un proceso aislado. Uno de los paquetes de software de contenedores más utilizado es Dockers, el cual puede emplearse tanto en sistemas operativos Windows como Linux. Por otra parte, un número importante de investigadores, académicos y profesionales de TI han presentado trabajos donde explican o proponen la aplicación de estas tecnologías. En particular, Cardelinni y Ianucci (2012) propusieron un diseño flexible y una arquitectura modular para una nube privada, que permite escalabilidad, fácil administración y adaptabilidad para proveer IaaS, agregando tolerancia ante fallos y alta disponibilidad[8]. Huo, Qu y Wo (2015) proponen la implementación de una plataforma de almacenamiento de nube privada utilizando OpenStack Swift, aprovechando sus capacidades de redundancia y tolerancia ante fallos para minimizar la pérdida de datos y entregar al centro de cómputo capacidad de almacenamiento escalable y de bajo costo[9]. Cáliz, Pérez y Pérez (2015) describen la arquitectura, diseño y las experiencias aprendidas en la implementación de una nube privada enfocándose en la adaptación de la infraestructura del Datacenter y las




6

decisiones para entregar servicios de computación de alto desempeño[10]. El trabajo propuesto buscará entregar infraestructura y servicios de TI con alta disponibilidad y desempeño, adaptando la arquitectura del data center para operar como una nube privada, de forma similar a lo propuesto por Cáliz, Pérez y Pérez [9], aprovechando además la experiencia de Huo, Qu y Wo [8] en la utilización de almacenamiento definido por software para entregar el soporte de storage que requieren las tecnologías de virtualización y sistema operativo de nube para proveer tolerancia ante fallas y alta disponibilidad para las instancias de las aplicaciones en ejecución.

5 Análisis de la Situación Actual

5.1 Contexto

El Centro de Tecnologías de la Información, C.T.I., es el órgano ejecutivo dependiente de la Dirección de Tecnología y Comunicaciones, responsable del desarrollo, mantención y explotación de los principales sistemas de información Institucionales, junto con la administración y mantenimiento del principal centro de cómputo de la organización. El C.T.I., entrega servicios de cómputo a más de 15.000 clientes distribuidos a lo largo de todo el país. Para tal fin, y por medio del datacenter que administra, provee hosting y/o housing a los sistemas informáticos relacionados con la administración logística, administración de personal, administración financiero-contable y datawarehouse, junto con servicios estándar como Intranet, correo electrónico, directorio institucional (LDAP), entre otros. Por otra parte, el C.T.I. efectúa el desarrollo de aplicaciones a medida, para cubrir las diversas necesidades administrativas en la Institución. La mayoría de estas aplicaciones deben ser desarrolladas, probadas e implementadas sobre la infraestructura del mismo datacenter que el C.T.I. administra. Para mantener en operación los sistemas bajo custodia y cumplir con los niveles de servicio fijados por la institución, el Centro de Tecnologías de la Información se organiza en tres departamentos; delegando las tareas de desarrollo de software, mantención y explotación de sistemas al departamento de Sistemas de Información; mientras que las tareas de administración y mantención del datacenter y servicios relacionados se entregan al departamento de Operaciones. El departamento de Administración y Finanzas se encarga de la gestión tanto del personal, como financiera y de abastecimiento, con el objeto de garantizar la disponibilidad de los recursos necesarios para la operación del Centro.

5.2 Definición del Problema

La configuración de los centros de cómputo de diversas instituciones públicas se ha obtenido de forma incremental, no ajustándose en su totalidad a los estándares o buenas prácticas de la industria, involucrando un bajo nivel de eficiencia respecto de los recursos que los componen. En general, el modelo de operación de estos centros obedece a una oferta de servicios de tipo “housing”, facilitando los espacios físicos, conectividad y energía para la habilitación de aplicaciones. Los requerimientos crecientes de despliegue ágil de aplicaciones, disponibilidad y escalabilidad de las mismas no es posible satisfacerlos con arquitecturas de infraestructura estáticas, altamente dependientes de las condiciones físicas del centro de cómputo, a la vez que las exigencias respecto de los niveles de servicio por parte de los usuarios, tanto internos como externos, aumentan. Por otra parte, las restricciones presupuestarias requieren de un uso eficiente y racional de los recursos y en contraposición, el modelo actual de servicios del datacenter, basados en housing, lleva generalmente a seleccionar hardware y software sobredimensionado a los requerimientos de las aplicaciones.




7

Adicionalmente, el tipo y clasificación de la información que se almacena en estos centros de cómputo impide, en la mayoría de los casos, externalizar los servicios de infraestructura y plataforma, obligando a mantener en operación estos servicios en modalidad “on site”. Se ha comprobado que las tecnologías de virtualización y convergencia permiten mejorar los niveles de eficiencia en los datacenters, maximizando el uso de la infraestructura de servidores[5]. Organizaciones de todo tipo están adoptando estas tecnologías para lograr agilidad en el despliegue de sus aplicaciones y mejorar la disponibilidad y escalabilidad de éstas. El desarrollo de herramientas que agregan niveles de abstracción a la infraestructura, independizándola de la arquitectura física, permite hoy en día entregar servicios TI mejor ajustados a los requerimientos de los clientes, que se habilitan, adaptan y escalan de acuerdo a las necesidades del momento. Se propone modificar la modalidad en la que se entregan los servicios del centro de cómputo del C.T.I. efectuando cambios a la arquitectura actual, estableciendo un modelo de nube privada para ofrecer a los usuarios ya sea Plataforma o Infraestructura como servicio (PaaS e IaaS respectivamente). La aplicación de esta nueva arquitectura involucrará una mejora en los tiempos de despliegue de aplicaciones, utilización de recursos y efectividad del consumo energético, a la vez del cumplimiento de exigencias institucionales y de gobierno, respecto de la continuidad operacional.

5.3 Servicios e Infraestructura que Provee el Datacenter

5.3.1 Servicios que entrega el datacenter

El datacenter del C.T.I. permite habilitar aplicaciones en dos modalidades: Housing y Hosting. La primera, involucra entregar espacio de rack, energía y conectividad al equipamiento necesario para la operación de la aplicación (servidores, unidades de almacenamiento y ciertos dispositivos de red son provistos por el cliente). Bajo la modalidad de hosting, el C.T.I. provee la infraestructura y servicios de computación para habilitar las aplicaciones. Sin embargo, éstas deben ser compatibles y estar soportadas por la infraestructura y configuración de los servicios con los que cuenta el datacenter, en lo que respecta particularmente al ambiente de ejecución (runtime, middleware y sistema operativo soportado).

5.3.2 Características físicas y eléctricas

● El Datacenter se emplaza en una superficie de 60 metros cuadrados. ● Los servidores, unidades de almacenamiento y dispositivos de red instalados se distribuyen en 11 racks de

42U cada uno. ● La capacidad IT o carga eléctrica útil medida es de 15,84 KW. ● El sistema de aire acondicionado tiene una capacidad de 83000 BTU, en funcionamiento normal, presenta

un consumo estimado de 10,67 KW. ● El diesel generador posee una capacidad de 32 KW. ● La UPS posee una capacidad de 32 KW.

5.3.3. Sistemas de información e infraestructura de servidores relacionados

Los sistemas de información y servicios de computación que entrega el datacenter se listan a continuación: ● Sistema de Gestión Logística ● Sistema de Gestión Financiera ● Sistema de Gestión de Operaciones ● Plataforma de Inteligencia de Negocios (BI) ● Sistema de Gestión Documental




8

● Intranet (Hosting de aplicaciones para Intranet) ● Servicios: ○ Actualizaciones ○ Antivirus ○ Email ○ Directorio ○ DNS ○ Proxy

● Storage: Red de área de almacenamiento (SAN) ● Dispositivos de seguridad perimetral y de redes En resumen, se tiene las siguientes cantidades totales, que se muestran en la tabla 1, en lo que respecta a infraestructura dedicada a cómputo, sin considerar equipamiento dedicado a Networking, Seguridad y Storage:

Tabla 1. Resumen de la infraestructura existente en el datacenter

Componente Cantidad Servidores físicos 37 Servidores virtuales 36 CPU Físicas 62 CPU Cores 422 Memoria RAM 2155 GB Storage en HDD 37080 GB

Durante el levantamiento de la situación actual, se evidenció una cantidad similar de servidores tanto físicos como virtuales, ejecutándose en grupos de hypervisores independientes. Estos clústeres trabajan en su mayoría en modalidad activo-pasivo, basados en pares de servidores físicos, para proveer tolerancia ante fallas. Sin embargo, esa configuración obliga a mantener el hypervisor secundario encendido permanentemente, consumiendo energía y enfriamiento. Adicionalmente, existen hypervisores fuera de un cluster, ejecutando máquinas virtuales de forma independiente, las que no pueden ser migradas automáticamente en caso de falla del host de virtualización. La gestión de los clústeres se realiza también individualmente, no existiendo un gestor centralizado para la orquestación de todos los servidores virtuales. Por otra parte, los hypervisores están dedicados al sostenimiento de un sistema en particular, no permitiéndose la habilitación de una aplicación de un sistema distinto en un hypervisor asignado. En segundo lugar, existen servidores de bases de datos, los cuales para ser virtualizados, presentan restricciones de licenciamiento del motor de base de datos utilizado. Las licencias que posee la Institución son mayoritariamente por CPU, con limitaciones también en la cantidad máxima de Cores de CPU que debe poseer el servidor donde ésta se instala. El modelo de licenciamiento sólo permite particionamiento de hardware (hard partitioning) en plataformas de virtualización certificadas por el fabricante y los hypervisores que ejecuten los servidores de bases de datos deben operar en modo standalone (no en un cluster). Por todo lo anterior, y mientras no se modifique la modalidad de licenciamiento respecto de la operación en infraestructura convergente, no es posible virtualizar la totalidad de los servidores dedicados a la función de motor de bases de datos.

6 Propuesta de Solución

Para entregar IaaS y PaaS existen diversas soluciones de virtualización tanto Opensource como comerciales, las que en general permiten establecer distintos niveles de abstracción del hardware y del sistema operativo base. Tecnologías desarrolladas por VMWare, Microsoft, Oracle, Red Hat, Nutanix, Rackspace, Google y muchos otros, ofrecen la posibilidad de otorgar Infraestructura y Plataforma como servicio en el Datacenter corporativo.

Básicamente, para entregar infraestructura a demanda es necesario contar con software que permita generar para el cliente máquinas virtuales con una configuración de hardware y sistema operativo adecuada a los




9

requerimientos de éste. Por otra parte, para entregar plataforma o el ambiente requerido para que las aplicaciones se ejecuten, la solución debe entregar los componentes necesarios como bibliotecas, paquetes de software y servicios relacionados, los que pueden ser incluidos en un contenedor que permita abstraer la aplicación y los componentes requeridos del sistema operativo donde se ejecuta.

La implementación de la nube privada en el C.T.I. permitirá ofrecer IaaS y PaaS por medio del soporte del software que permitirá gestionar la infraestructura de servidores y facilitar los procesos de habilitación de aplicaciones.

Uno de los proyectos que mayor solidez y despliegue ha alcanzado en ambientes productivos de nubes privadas es Openstack. Openstack se define a sí mismo como software open source para crear tanto nubes privadas como públicas. Posee los componentes necesarios para controlar los recursos de cómputo, almacenamiento y red del datacenter y es compatible con tecnologías comerciales o de fuente abierta, adaptándose fácilmente en infraestructuras heterogéneas. Por medio de Openstack, los administradores cuentan con un dashboard para el control de la infraestructura y los usuarios pueden provisionar recursos utilizando una interfaz web. Existen diversos fabricantes que ofrecen soporte comercial para esta suite, proveyendo además productos con valor agregado basados en Openstack, tales como arquitecturas de referencia, distribuciones de sistema operativo adaptadas o unidades de hardware y software preconfiguradas (appliances). La figura 4 muestra los componentes que son gestionados y/o provistos por Openstack, identificándose servidores físicos, máquinas virtuales y contenedores que utilizan los distintos servicios de almacenamiento y la red común. Todos estos componentes son administrados y controlados utilizando las API que provee la suite o las herramientas de monitoreo y gestión nativas. Sobre esta infraestructura se habilitan las aplicaciones de los usuarios.

Figura 4. Componentes de Openstack (Fuente: [11])

Openstack agrupa 46 proyectos que permiten automatizar cómputo, respaldo, almacenamiento y restauración, redes, análisis de datos, gestión de identidad, herramientas de gestión y de despliegue, servicios de aplicaciones y monitoreo. Con relación a éstos, los proyectos con mayor popularidad y presencia en las implementaciones de distintos proveedores se listan en la tabla 2.

Tabla 2. Descripción de proyectos componentes de Openstack[12]

Nombre Servicio Descripción Neutron Networking Provee conectividad entre las interfaces de los servicios de Openstack. Cinder Almacenamiento

de Bloques Gestiona los volúmenes de almacenamiento persistente en bloques para las máquinas virtuales. Usualmente se utiliza una conexión a almacenamiento externo, particularmente del tipo definido por software como Ceph.

Nova Cómputo Gestiona y provisiona las máquinas virtuales que se ejecutan en los nodos hypervisores.




10

Glance Imagen Servicio de registro que se usa para almacenar recursos como imágenes de máquinas virtuales e instantáneas de volumen.

Swift Almacenamiento de objetos

Permite a los usuarios almacenar y recuperar archivos de distintos formatos, incluyendo imágenes de máquinas virtuales.

Ceilometer Telemetría Entrega mediciones de los recursos de la nube. Heat Orquestación Motor de orquestación que soporta la creación automática de pilas de

recursos. Horizon Dashboard Dashboard que funciona como aplicación web, utilizada para gestionar

los servicios de Openstack. En el caso de PaaS, este servicio se propone habilitar utilizando una solución de orquestación de contenedores, la cual consumirá los servicios de la plataforma IaaS, habilitada sobre Openstack. En este aspecto, se propone utilizar la plataforma opensource Openshift, la cual se compone del paquete Dockers para la creación de los contenedores y Kubernetes para la gestión de los clústeres o grupos de éstos en múltiples hosts.

Openshift permite desarrollar, desplegar y gestionar las aplicaciones basadas en contenedor en la infraestructura física, virtual o en la nube (privada o pública), permitiendo acelerar los procesos de desarrollo, entregar nuevos servicios y modernizar las aplicaciones existentes en un modelo de autoservicio, el cual ofrece workflows automatizados que incorporan herramientas de integración contínua (CI) y entrega contínua (CD). Kubernetes en particular, permite la orquestación del conjunto de contenedores utilizando políticas de control, balanceo de carga y escalamiento automatizado, junto con agregar niveles de seguridad para aislar las aplicaciones entre uno y otro contenedor[13]. La arquitectura de Openshift está basada en capas, como se muestra en la figura 5, donde la capa de Enrutamiento (Routing) permite exponer los contenedores a los usuarios, la capa de servicios entrega el soporte físico donde los Nodos que alojan los contenedores se ejecutan. Por medio del servidor Master tanto los desarrolladores como los administradores interactúan con el cluster, en los procesos de desarrollo, integración y entrega de aplicaciones, así como en la gestión de los contenedores Linux.

Figura 5. Componentes de Openshift (Fuente: [13])




11

Los componentes de la arquitectura de Openshift se describen a continuación en la tabla 3:

Tabla 3. Descripción de componentes de Openshift[13]

Nombre Descripción Master Host que contiene los componentes principales como el servidor de API y el controlador.

Gestiona los nodos que están en el cluster Kubernetes y planifica la ejecución de los Pods en los Nodos.

Kubernetes Gestiona las aplicaciones contenerizadas y provee mecanismos para desplegarlas, mantenerlas y escalarlas. Un cluster Kubernetes se compone en uno o más maestros y un conjunto de nodos.

Docker Instancia y ejecuta las aplicaciones que se encuentran contenerizadas. Nodo Provee el ambiente de ejecución a los contenedores. Cada nodo en un cluster Kubernetes es

gestionado por el Master. Los nodos poseen los servicios necesarios para ejecutar los contenedores o pods, tales como el Docker, Kubelet y el proxy de servicio.

Contenedor Mecanismo para aislar procesos de manera de limitar su interacción sólo con los recursos asignados. Muchas instancias de contenedor pueden ejecutarse en un host sin que los otros procesos, archivos o la red tengan visibilidad de éstos. Típicamente cada contenedor entrega un único servicio llamado microservicio, como un servidor web o una base de datos.

Pod Es uno o más contenedores existentes en un host y la unidad de cómputo más pequeña que puede ser definida, desplegada y manejada. Son el equivalente de una máquina (física o virtual) a un contenedor. Cada Pod posee su propia dirección IP y puertos. Los contenedores de un mismo Pod pueden compartir el almacenamiento y la red.

Router Los routers son desplegados por el administrador de OpenShift para permitir que las rutas creadas por los desarrolladores sean utilizadas por los clientes, facilitando así que el tráfico de red llegue al cluster. Uno de los plugin más utilizados es HAProxy.

Para asegurar el respaldo técnico y la estabilidad de la plataforma, se propone utilizar la versión de Openstack que ofrece Red Hat, quien contribuye al desarrollo de estos conjuntos de programas opensource, pero además entrega el soporte a las versiones más estables, las que pueden así ser utilizadas en el ámbito empresarial con altos niveles de confiabilidad. Adicionalmente, la plataforma Openstack de Red Hat (RHOSP) utiliza el sistema de Almacenamiento Definido por Software (SDS) Ceph para entregar almacenamiento de bloque a los nodos de cómputo vía el paquete Cinder de Openstack. En lo que respecta a Openshift y considerando que inicialmente se migrarán los servidores físicos y virtuales sólo a Instancias Openstack y que el grado de adopción de contenedores será mínimo en principio, se propone habilitar la versión Openshift Origins hasta determinar que es necesario el soporte empresarial para la herramienta. RHOSP se divide en dos partes principales: Undercloud y Overcloud. Undercloud se compone principalmente de Openstack Director, servidor utilizado para desplegar, gestionar y actualizar los servidores que pertenecen a Overcloud, los cuales corresponden a los nodos controladores, de cómputo y de almacenamiento, como se muestra en la figura 6.




12

Figura 6. Undercloud y Overcloud en Openstack (Fuente: [7])

La nueva arquitectura considera la creación de la nube, la habilitación de las instancias para la implementación de aplicaciones y el soporte de cómputo y almacenamiento para su operación; a la vez de mantener los servidores de bases de datos que requieren operar en infraestructura física, debido a restricciones del licenciamiento para la habilitación en clústeres con gran cantidad de cores. El equipamiento de la Red de Área de Almacenamiento (SAN) mantendrá su operación para la provisión de storage con alta velocidad de acceso y confiabilidad, requerido por las bases de datos principalmente. De esta manera y como se muestra en la figura 7, el cluster Openstack, el cluster de almacenamiento, el grupo de hosts de virtualización, el grupo de servidores de bases de datos y la SAN se interconectarán entre sí otorgando los servicios de cómputo y storage a las aplicaciones y servicios que lo requieran, configurando de esta manera la nube privada y otorgando flexibilidad para habilitar máquinas tanto físicas como virtuales en caso de ser necesario.

Figura 7. Componentes de la nube privada propuesta (Fuente: Elaboración propia)




13

Como se menciona anteriormente, para la entrega de servicios PaaS se propone utilizar la suite Openshift y para proveer IaaS, se utilizará Openstack. Secundariamente y observando que se requieren servicios permanentes para la administración de la plataforma de nube y eventualmente sea necesario habilitar máquinas virtuales con características particulares de hardware y operación, la plataforma de virtualización Red Hat Virtualization participará también de la entrega de servicios IaaS. Es posible así, definir la arquitectura en un modelo de capas, basado en las aplicaciones, la plataforma PaaS, la plataforma IaaS, la plataforma de almacenamiento y la infraestructura. La figura 8 muestra las componentes de la arquitectura, donde las aplicaciones actuales serán implementadas principalmente sobre instancias virtuales de Openstack las que se ejecutarán sobre nodos de cómputo, que recibirán los servicios para la operación continua y de abstracción por parte de los controladores quienes ejecutan los servicios que permiten operaciones de cómputo, almacenamiento, redes, análisis de datos, despliegue y monitoreo. Openstack utilizará los servicios de almacenamiento de bloques provistos por Ceph, para los requerimientos de las instancias y contar con una ubicación común para el soporte de alta disponibilidad de éstas, permitiendo la migración a distintos nodos de cómputo. Los servicios de ejecución de nodos para los contenedores y administración de la nube serán habilitados como máquinas virtuales que se ubicarán en los hosts de virtualización. Esta plataforma estará conectada a la SAN para obtener almacenamiento compartido y otorgar alta disponibilidad a las aplicaciones de gestión.

Figura 8. Modelo de Capas en el que se basa la arquitectura propuesta (Fuente: Elaboración propia)

Para entregar la conectividad necesaria, se habilitarán ocho VLANs las que interconectarán los diversos servicios de la nube privada y los clientes externos[12]. La función de cada una de estas redes y su organización se describe a continuación y se muestra en la figura 9: ● Red de administración: Se utilizarán las interfaces que cada servidor posee para realizar operaciones IPMI

(Intelligent Platform Management Interface) con la intención de proveer capacidades de monitoreo y gestión independiente de la infraestructura de la nube.

● Red de almacenamiento: Red exclusiva para el tráfico de storage, utilizada por todos los nodos de cómputo para comunicarse con el cluster Ceph Storage y por los servicios que realizan operaciones de configuración y aprovisionamiento en el mismo cluster.

● Red interna para instancias: Conectividad entre el servicio de cómputo Nova y las instancias en los nodos de cómputo.

● Red de aprovisionamiento: Interconexión de todos los nodos para la configuración y aprovisionamiento de los servidores de la nube privada.




14

● Red del cluster de almacenamiento: Utilizada sólo por los nodos de storage para replicación y verificación de datos.

● Red externa para instancias: Red que soporta las direcciones flotantes y enrutamiento para las instancias hacia el exterior de la infraestructura.

● Red privada de API: Utilizada para la comunicación del cluster Openstack entre los nodos controladores, los nodos controladores y el nodo Director (este último se ejecuta en los hosts de virtualización).

● Red pública de API: Utilizada para la comunicación con las API de gestión de Openstack, el Gateway RADOS (comunicación externa con Ceph) y la GUI de Horizon (Dashboard de Openstack).

La velocidad de la red en el cluster será de 10 Gbps, considerando la implementación de agregación de enlaces, logrando conexiones de hasta 20 Gbps en los nodos de cómputo, almacenamiento y virtualización a las diferentes VLAN que se implementarán.

Figura 9 Diagrama de red. VLANs a implementar para la operación de la plataforma (Fuente: [12])




15

Para establecer la cantidad de nodos de cómputo y de almacenamiento que se requieren para migrar las aplicaciones existentes en el datacenter a la nube privada, se calculó la cantidad de CPU, RAM y Disco duro requeridos en base a las aplicaciones seleccionadas para la migración, basándose en la factibilidad de ser virtualizadas. Las referencias documentales relacionadas con el dimensionamiento de la arquitectura de Openstack sugieren la definición de tipos de instancias a utilizar (flavors), en base a los parámetros básicos de hardware de cada una, teniendo en cuenta las características originales de los servidores que serán habilitados en la nube privada. Así, se definirán cuatro tipos de instancias: ● S (Pequeña): 01 vCPU / 02 GB RAM / 50 GB HDD ● M (Mediana): 02 vCPU / 04 GB RAM / 100 GB HDD ● L (Grande): 02 vCPU / 08 GB RAM / 200 GB HDD ● XL (Extra Grande): 04 vCPU / 16 GB RAM / 400 GB HDD Para determinar el tamaño de los nodos de cómputo se establecen criterios de sobre dimensionamiento (over-commit) de RAM y CPU, los cuales se basan en el rendimiento medido de los componentes de hardware utilizados en virtualización. Las reglas básicas establecen que no debe considerarse over-commit para el tamaño de la RAM y para el caso de las CPU, permitir un over-commit máximo de 10 veces la cantidad de sus núcleos de procesamiento[14] Después de analizar las características de los servidores tanto físicos como virtuales, existentes en el datacenter, y determinar la moda estadística en la cantidad de CPU, RAM y Disco duro en ese conjunto, se establece que los parámetros comunes corresponden a 02 CPU, 02 GB RAM y 292 GB de disco duro. Sin embargo, el tamaño de disco duro se ajusta a 100 GB, considerando que ese último valor regularmente se sobredimensiona. Siendo éstos los parámetros comunes, se construye la siguiente tabla en base a un total de 57 instancias y a la asignación de los 4 tipos de éstas, incluyendo los cálculos totales, teniendo en cuenta un 20% de incremento por la sobrecarga de procesamiento en los nodos de cómputo.

Tabla 4. Requerimientos de hardware por tipo de instancia para los nodos de cómputo

Tipo Instancia Cantidad vCPU RAM (GB) HDD (GB) S 9 9 18 450 M 24 48 96 2400 L 19 38 152 3800

XL 5 20 80 2000 Subtotal 57 115 346 8650

Total 57 138 415,2 10380 Para la cantidad total de vCPU, se considerará un overcommit de 8, obteniéndose 17,25 núcleos físicos. No se aplicará overcommit para RAM y HDD, manteniéndose 415,2 GB y 10380 GB respectivamente.

Lo anterior, permite establecer que en un nodo de cómputo, con 02 CPU de 12 cores cada una y 512 GB de RAM, es posible soportar la cantidad establecida de instancias y sus diversos tipos. Un sistema de almacenamiento de 10 TB soportaría los requerimientos de disco duro.

La cantidad recomendada de nodos de cómputo para asegurar disponibilidad de la plataforma es de tres, lo anterior para asegurar escalabilidad y confiabilidad a la arquitectura. En el caso del almacenamiento, se recomiendan tres nodos Ceph para permitir la redundancia necesaria. La versión de Red Hat Openstack permite contar con hasta 64 TB en un máximo de tres nodos sin incorporar costos de suscripción para Ceph. Esos 64 TB se convierten en 20 TB disponibles para asignar, el doble de lo requerido para soportar la cantidad de instancias que se habilitarán en la plataforma. En definitiva, y después de aplicar las recomendaciones para el dimensionamiento de la infraestructura y tomando en cuenta las arquitecturas de referencia publicadas por los fabricantes, en conjunto con las necesidades del datacenter del C.T.I.; es posible proponer que la nube privada para soportar las aplicaciones en




16

uso constará de dos racks de 42U en los que 12 servidores se dedicarán a la implementación de la plataforma de soporte de PaaS e IaaS y se mantendrán 8 servidores de base de datos, 8 appliances de seguridad y los 4 nodos pertenecientes a la SAN actual del datacenter. La figura 10 muestra la configuración física propuesta.

Figura 10. Configuración física de los racks para la nueva arquitectura del datacenter. (Fuente: Elaboración propia)

7 Validación de la Propuesta

7.1 Reducción del consumo energético Para determinar la reducción del consumo eléctrico del datacenter al implementar la nube privada se realizaron mediciones de corriente de entrada al centro de cómputo, se recopilaron datos de consumo eléctrico mensual y se estimaron las cargas de TI y del sistema de aire acondicionado.

La tabla 5 muestra los valores obtenidos y calculados en base a la medición de corriente efectuada en los puntos de conexión a la red del proveedor de energía eléctrica del datacenter, con el sistema de aire acondicionado (AC) desconectado y conectado. De esta medición, es posible determinar cuál es el porcentaje de la carga TI y del total dedicado a enfriamiento en el momento de la medición. Para el cálculo de potencia se utiliza un factor de potencia igual a 1.




17

Tabla 5. Mediciones de corriente de entrada al datacenter y cálculos de potencia

AC Desconectado AC Conectado Potencia consumida por el AC

Fase Amps Watts Amps Watts Amps Watts Porcentaje de carga TI

Porcentaje del Total

A 23,3 5126 39,5 8.690 16,2 3564 70% 41% B 24,2 5324 40,3 8.866 16,1 3542 67% 40% C 24,5 5390 40,7 8.954 16,2 3564 66% 40%

Totales 72 15840 120,5 26.510 48,5 10.670 67% 40% La tabla 6 muestra el detalle del consumo eléctrico del datacenter en el período Julio 2016 a Julio 2017, expresado en energía consumida y la potencia promedio y máxima entregada a la carga eléctrica del centro de cómputo. Es importante tener en cuenta que de acuerdo a estudios realizados por la empresa American Power Conversion (APC) el consumo de la carga TI en un datacenter típicamente representa el 47% del total y la energía invertida en el enfriamiento y la climatización del mismo representa el 41%[15], como se aprecia en la figura 11. Este último valor es similar al obtenido en la medición de potencia explicada en la tabla 5.

Figura 11. Porcentajes de consumo de energía en un datacenter típico por tipo de carga. (Fuente: [15])

El registro de la tabla 6 permite determinar los valores promedio de consumo mensual, factor de potencia y potencia demandada. A su vez, se evidencia que la potencia requerida por el datacenter alcanza niveles cercanos a la capacidad máxima del generador existente.

Tabla 6. Registro de consumo eléctrico en el último año para el datacenter del C.T.I.

Período Energía Activa (KWHr)

Energía Reactiva (KWHr)

Factor Potencia

Potencia Leída (KW)

Potencia Máxima (KW)

JUL 2016 18.675 5602 0,96 27,20 29,50 AGO 2016 16.535 5229 0,95 28,40 29,20 SEP 2016 15.929 4989 0,95 27,70 28,60 OCT 2016 19.343 5190 0,97 29,70 29,70 NOV 2016 16.551 4827 0,96 29,90 29,90 DIC 2016 19.962 5720 0,96 32,00 32,00 ENE 2017 14.337 3304 0,97 29,20 29,20 FEB 2017 16.681 4417 0,97 28,00 28,60 MAR 2017 15.742 4430 0,96 27,40 28,60 ABR 2017 18.063 5032 0,96 27,90 28,40 MAY 2017 14.239 3784 0,97 27,20 28,20 JUN 2017 16.553 4396 0,97 28,20 28,30 JUL 2017 15.456 3788 0,97 27,10 28,30 Promedio 16.774,31 4.669,85 0,96 28,45 29,12




18

Los gráficos de las figuras 12 y 13 muestran la relación de la energía consumida y potencia requerida por el datacenter en el período observado, apreciándose los meses de mayor consumo, los peaks de potencia requerida y la tendencia a la baja en el consumo a lo largo del ciclo presentado.

Figura 12. Relación de energía activa y reactiva consumida por el datacenter en el último año. (Fuente: Elaboración propia)

Figura 13. Relación de la potencia leída y máxima medida por el proveedor de electricidad en el período del último año. (Fuente: Elaboración propia)

A partir de los requerimientos de potencia de los servidores que formarán parte de la nueva configuración del datacenter, es posible estimar la demanda eléctrica estimada total de la nube privada.

Tabla 7. Potencia total requerida por los servidores de la nube privada por Rack

Rack Potencia [W] Rack 1 4.080,6 Rack 2 5.797,2 Total Estimado 9.877,8

A partir de la información descrita en las tablas 5 y 6, teniendo además en cuenta un consumo estimado del equipamiento TI entre el 47% a 59% del total entregado por la compañía eléctrica, podemos estimar una carga TI actual del datacenter en un rango de 13,37 KW a 16,79 KW. Considerando la potencia total estimada para la nube privada, descrita en la tabla 7 y el rango de carga TI actual, se esperaría una reducción de consumo en un rango de 3,49 KW a 6,91 KW.




19

La reducción de consumo establecida en el párrafo anterior, involucrará también la reducción de carga térmica para el sistema de enfriamiento. Si el consumo del sistema de climatización alcanza un porcentaje cercano al 41% del total del datacenter[15] [16]y el que presenta la carga TI es de 47%[15], entonces la disminución por este ítem se encontraría en un rango similar al indicado en el párrafo anterior, estimándose en un rango entre 3 KW y 6 KW.

En resumen y en el peor de los casos, se lograría un ahorro de energía anual de 56.852 KWHr, es decir una reducción de costo de USD 7.391 al año, por concepto de energía, al implementar la nube.

7.2 Reducción del tiempo de despliegue de aplicaciones

Para estimar la reducción del tiempo que tomaría desplegar aplicaciones en la nube privada es necesario determinar los plazos actuales de ejecución que se experimentan en el proceso que involucra desde la solicitud de housing hasta la puesta en producción.

Desde el momento en que se asignan los recursos para habilitar una nueva aplicación, en un servidor físico en el datacenter, se desarrollan las actividades descritas a continuación en la tabla 8, con los plazos estimados de ejecución y recursos involucrados que se indican.

Tabla 8. Plazos y costos estimados para habilitar aplicaciones en el datacenter actualmente

Actividad Plazo de Ejecución Recursos Involucrados

Asignación de rack, punto de conexión a la red, direccionamiento y permisos de firewall.

2 días Ingeniero de Datacenter: 01 HH Ingeniero de Enlaces: 01 HH Ingeniero de Seguridad: 01 HH Costo mínimo estimado: USD 30

Adquisición de equipamiento y software.

5 a 30 días Encargado de adquisiciones: 03 HH Servidor: 01 NR Costo mínimo estimado: USD 5.030

Habilitación de los servidores (Carga de Sistema Operativo y paquetes requeridos para la operación de la aplicación)

1 día Ingeniero a cargo: 08 HH Costo mínimo estimado: USD 80

Totales mínimos 8 días USD 5.140 La habilitación de una instancia en Openstack involucra los siguientes pasos:

● Definir nombre y tipo de imagen virtual que utilizará la instancia. ● Seleccionar el tipo de instancia (flavor) de acuerdo a los requerimientos de hardware de la misma. ● Cantidad de instancias a crear. ● Seleccionar la red en la que se conectará la instancia.

Lo anterior, puede realizarse desde el portal Horizon o desde la línea de comandos en uno de los nodos de cómputo Openstack, indicando el tipo de imagen virtual a utilizar, el tipo de instancia (flavor) y su nombre, como se ejemplifica a continuación:

openstack server create --image ImagenWeb --flavor=2 --key-name LlaveStandard InstanciaWeb1

En consecuencia, considerando las herramientas de gestión que provee Openstack tales como el motor de orquestación Heat, el portal de autogestión Horizon o el sistema de red Neutron, al implementar la nube privada y automatizar las actividades relacionadas con la habilitación de infraestructura para las aplicaciones, el tiempo que involucra su despliegue se reducirá desde varios días a tan sólo minutos.




20

7.3 Reducción de recursos respecto de los costos de inversión y operación de aplicaciones Para comprobar la reducción de costos de inversión y operación, se estimará el costo de operación anual de un servidor en lo que respecta a consumo energético y luego se comparará el costo de inversión y operación de habilitar una aplicación genérica en este servidor con el costo de inversión y operación de una instancia Openstack en la plataforma propuesta.

Tabla 9. Estimación de costo de operación anual por consumo energético de un servidor

Características servidor[17] Dell Poweredge R630 02 CPU E52690 v3 2,6 Ghz, 128 GB RAM, 03 HDD 600 GB

RAID 5. Carga de trabajo Transaccional, 100% carga CPU. Valor KWhr Tarifa BT3 Valparaíso (en USD)[18] 0,13 Horas de operación anuales 8.760 Potencia estimada servidor 0,3 KW Potencia estimada AC[15] 0,3 KW Costo estimado de energía por operación anual (en USD) 683

Considerando los costos de inversión y operación de la nueva plataforma de nube privada, definiendo un horizonte de explotación de seis años, se determina un monto de USD 374.900 como costo total del proyecto. La tabla 10 muestra el detalle de los costos de inversión y operación para implementar la propuesta.

Tabla 10. Valorización de costo por instancia virtual

Producto Cant. Modelo Caracterísicas Base Costo (USD)

Nodos de Cómputo

3 R640 02 CPU Xeon Gold 5118 2.3Ghz / 512 GB RAM / 8 x 600 GB / 8 x 10 Gbps SFP

58.500

Nodos de Almacenamiento

3 R740 02 CPU Xeon Gold 5118 2.3Ghz / 128 GB RAM / 2 x 300 - 3 x 400 - 12 x 1800 / 8 x 10 Gbps SFP

67.500

Nodos Controladores

3 R640 02 CPU Xeon Gold 5118 2.3Ghz / 128 GB RAM / 8 x 600 GB HDD / 8 x 10 Gbps SFP

31.500

Switches 10 Gbps 3 S4048-ON 48 puertos 10 Gbps SFP 36.000 Suscripción RHOSP Cómputo

3 Premium Support

Servidores con 2 sockets - 6 años 81.000

Consultoría y Capacitación

1 N/A Servicios profesionales y Capacitación a administradores plataforma.

50.000

Suscripción RHOSP Controlador

3 Premium Support

Servidores con 2 sockets - 6 años 50.400

Total 374.900

De acuerdo a lo que se determina en la tabla 11, el costo por instancia virtual es de USD 7.265 al inicio de la puesta en producción, habilitando las 57 instancias virtuales en Openstack, considerando los costos de inversión y operación con un plazo de 6 años. Comparativamente, el costo de inversión y operación a 6 años para una aplicación habilitada en servidor físico es de USD 9.238. Por último, el costo de inversión y operación a 6 años para el máximo de instancias virtuales al cual se dimensionó la plataforma, 114, se calcula en USD 3.633.




21

Tabla 11. Comparaciones de costo de instancia virtual y servidor físico

Plataforma (USD)

Instancia Virtual

(57) (USD)

Servidor Físico (USD)

Instancia Virtual (114) (USD)

Inversión Infraestructura, consultoría y capacitación

243.500 4.272 5.140 2.136

Suscripción Soporte 6 años 131.400 2.305 1.153 Costos energía 6 años 39.220 688 4.098 344 Costo de instancia / servidor 7.265 9.238 3.633

En el modelo de gestión actual, los encargados de las aplicaciones deben contar con autorización de acceso al datacenter, para realizar actividades de mantenimiento en la infraestructura propia alojada en el C.T.I., cuando ello es necesario. En la actualidad, más de 50 personas cuenta con esa autorización, involucrando riesgos de seguridad que podrían afectar la confidencialidad y disponibilidad de la información. Al independizar la infraestructura y/o plataforma que las aplicaciones utilizan del equipamiento físico, los distintos encargados podrán continuar realizando sus actividades de administración de forma independiente sin requerir acceso al centro de cómputo ya que la gestión de las instancias en la nube privada será realizada remotamente, utilizando las herramientas de software provistas por la plataforma.

8 Conclusiones y Trabajo Futuro

Las validaciones realizadas permiten concluir que el cambio de modelo de operación, basado en housing principalmente, al de una nube privada, permitirá efectivamente una reducción del consumo energético y los costos de operación e inversión, los cuales irán incrementándose proporcionalmente con el grado de utilización de la plataforma. Ello también reducirá el riesgo de sobrecarga en el sistema de operación continua, considerando las capacidades máximas de Generador y UPS en el C.T.I.

Los costos de implementación de la nube privada, si bien se muestran altos, representan un monto inferior al presupuesto de renovación del hardware base del datacenter, el cual se encuentra al término de su vida útil. Por lo anterior, esta renovación no depende de las ventajas que presenta una arquitectura sobre la otra, sino más bien una inversión obligatoria en el corto plazo.

La disponibilidad de las aplicaciones se incrementará al contar con herramientas para asegurar su operación continua y elástica, basándose en la capacidad de migración en vivo de las instancias y la adaptación de los parámetros de hardware con respecto a la demanda. Las herramientas que incluye la plataforma Openstack facilitarán además el monitoreo, verificación de rendimiento y la liberación de tareas de administración por parte del equipo de ingenieros del datacenter, delegando actividades de gestión a los encargados y desarrolladores de aplicaciones.

La configuración de los clústeres de cómputo y almacenamiento permitirán escalamiento horizontal en la medida que sea necesario y los límites para ello sólo se suscriben a las capacidades físicas y eléctricas del datacenter. Es importante investigar las alternativas de licenciamiento y configuración de los motores de base de datos que permitan una completa integración en la plataforma de nube privada, buscando privilegiar la existencia de instancias virtuales o contenedores por sobre los servidores físicos para lograr una mayor reducción de los costos operacionales y otorgar holgura en la escalabilidad horizontal. En lo que respecta a la SAN del datacenter, considerando la evolución de las soluciones de almacenamiento definidas por software, como Ceph, y las mejoras continuas al rendimiento de estas plataformas, se estima conveniente estudiar la factibilidad de su reemplazo definitivo en los próximos años. La misma situación se aprecia para los appliances de seguridad, muchos de los cuales ya cuentan con alternativas basadas en máquinas virtuales, las que sacando provecho de los componentes de networking definido por software como Neutron, podrán ser migradas a la nube privada.




22

Aunque no se ha considerado el impacto en los procesos del centro de cómputo, los cuales se estima mejorarán en su eficiencia, éstos deberán ser adaptados considerando la existencia de la nueva arquitectura y requerirán la adopción de metodología DevOps, en la que se integran los procesos de desarrollo y operaciones, además de la utilización de métodos ágiles para el desarrollo de software con el objeto de alcanzar mayor rendimiento de la plataforma PaaS. En ese sentido, la existencia de la infraestructura estandarizada y actualizada facilitaría también un trabajo en el gobierno de los servicios TI, aplicando frameworks como ITIL o COBIT a la gestión del C.T.I. La nube privada a definir, si bien en un principio estará circunscrita a un único datacenter, podrá escalar en el futuro a los otros centros de cómputo Institucionales, ubicados a lo largo del país, permitiendo la gestión y provisión de infraestructura de servidores y plataforma de manera centralizada, aprovechando las capacidades de cómputo distribuido. Con ello también se facilitaría la implementación de sitios de contingencia en distintas ubicaciones geográficas, permitiendo una mejor preparación ante interrupciones generadas por agentes externos. Referencias [1] P. Mell and T. Grance, “The NIST Definition of Cloud Computing Recommendations of the National

Institute of Standards and Technology,” Nist Spec. Publ., vol. 145, p. 7, 2011. [2] D. C. Marinescu, Cloud Computing: Theory and Practice, First. Elsevier, 2012. [3] K. Remde, “SaaS, PaaS, and IaaS.. Oh my! (‘Cloudy April’ ),” 2011. [Online]. Available:

https://blogs.technet.microsoft.com/kevinremde/2011/04/03/saas-paas-and-iaas-oh-my-cloudy-april-part-3/.

[4] Y. Chou, “What, Why and How IaaS and PaaS,” 2015. [Online]. Available: http://dw.connect.sys-con.com/session/2747/Yung_Chou_Final.pdf.

[5] S. Niles and P. Donovan, “Virtualization and Cloud Computing: Optimized Power, Cooling, and Management Maximizes Benefits,” White Pap., p. 14, 2011.

[6] Gartner, “Magic Quadrant for x86 Server Virtualization Infrastructure,” 2016. [Online]. Available: https://www.gartner.com/doc/reprints?ct=160707&id=1-3B9FAM0&st=sb.

[7] Red Hat, “Red Hat OpenStack Platform 11 Architecture Guide,” p. 80, 2017. [8] V. Cardellini and S. Iannucci, “Designing a Flexible and Modular Architecture for a Private Cloud: a Case

Study.” [9] J. Huo, H. Qu, and L. Wu, “Design and implementation of private cloud storage platform based on

OpenStack,” IEEE Int. Conf. Smart City/SocialCom/SustainCom together with DataCom, 2015. [10] R. Cáliz, F. Pérez, and N. Pérez, “Lessons learned in the design and implementation of a private cloud for

high-performance computing using OpenStack in existing university infrastructure,” … (10CCC), 2015 10th, pp. 558–567, 2015.

[11] Openstack, “Openstack software,” 2017. [Online]. Available: https://www.openstack.org/software/. [12] Dell-EMC, “Dell EMC Ready Bundle for Red Hat OpenStack.” [13] Openshift, “Openshift Overview,” 2017. [Online]. Available:

https://docs.openshift.org/latest/architecture/index.html. [14] B. Silverman and M. Solberg, OpenStack for Architects, First. Packt Publishing, 2017. [15] P. N. Rasmussen, “Medición de la eficiencia eléctrica para centros de datos,” p. 5, 2012. [16] Z. Song, X. Zhang, and C. Eriksson, “Data Center Energy and Cost Saving Evaluation,” in Energy

Procedia, 2015. [17] EnergyStar, “Energy Start Certified Enterprise Servers.” [Online]. Available:

https://www.energystar.gov/productfinder/product/certified-enterprise-servers/details/2217328. [18] Chilquinta, “Tarifas de Suministro Eléctrico.” [Online]. Available:

https://www.chilquinta.cl/uploads/2012/09/20120902231358-suministro20170701.pdf. [19] Dell, “Enterprise Infrastructure Planning Tool.” 2017.




23

Anexos Anexo A: Características y Demanda de Potencia de los Servidores de la Nube Privada Las tablas 12 y 13 muestran el detalle de las características y requerimientos de potencia de cada servidor y appliance que será incorporado a la nube privada.

Tabla 12. Características y Potencia estimada requerida por el equipamiento de la nube privada en el Rack 1

Rack 1 [19] Función Modelo CPU Cores RA (GB) HDD (GB) Watts

Controlador 1 Openstack R640 2 12 128 8 x 600 109 Controlador 2 Openstack R640 2 12 128 8 x 600 109 Controlador 3 Openstack R640 2 12 128 8 x 600 109 Cómputo 1 Openstack R640 2 12 512 8 x 600 110 Cómputo 2 Openstack R640 2 12 512 8 x 600 110 Cómputo 3 Openstack R640 2 12 512 8 x 600 110 Virtualización 1 RHV R630 2 10 256 2 x 300 309 Virtualización 2 RHV R630 2 10 256 2 x 300 309 Virtualización 3 RHV R630 2 10 256 2 x 300 309 Almacenamiento 1 Ceph R740 2 12 128 2 x 300 | 3 x 400 | 12 x

1.800 504

Almacenamiento 2 Ceph R740 2 12 128 2 x 300 | 3 x 400 | 12 x 1.800

504

Almacenamiento 3 Ceph R740 2 12 128 2 x 300 | 3 x 400 | 12 x 1.800

504

Switch 10 Gbps 1 S4048-ON N/A N/A N/A N/A 423,9 Switch 10 Gbps 2 S4048-ON N/A N/A N/A N/A 423,9 Switch 10 Gbps 3 S3048-ON N/A N/A N/A N/A 136,8

Potencia requerida Rack 1: 4.080,6

Tabla 13. Potencia estimada requerida por el equipamiento de la nube privada en el Rack 2

Rack 2 (Fuente: mediciones directas - referencia técnica fabricante) Función Modelo CPU Cores RAM (GB) HDD (GB) Watts

Base de Datos 1 X3650 M3 1 8 32 292 243 Base de Datos 2 X3650 M3 1 8 32 292 243 Base de Datos 3 X3650 M3 1 8 32 292 243 Base de Datos 4 DL360 1 12 32 600 325 Base de Datos 5 X3690 X5 1 8 64 292 243 Base de Datos 6 X3690 X5 1 8 64 292 250 Base de Datos 7 X3690 X5 1 8 64 292 250 Base de Datos 8 DL360 1 12 64 1500 355 Appliance Seguridad 1 N/A N/A N/A N/A N/A 450 Appliance Seguridad 2 N/A N/A N/A N/A N/A 215 Appliance Seguridad 3 N/A N/A N/A N/A N/A 215 Appliance Seguridad 4 N/A N/A N/A N/A N/A 215 Appliance Seguridad 5 N/A N/A N/A N/A N/A 215 Appliance Seguridad 6 N/A N/A N/A N/A N/A 215 Appliance Seguridad 7 N/A N/A N/A N/A N/A 215 Appliance Seguridad 8 N/A N/A N/A N/A N/A 215 Controlador 1 SAN SC8000 N/A N/A 64 N/A 443,1 Controlador 2 SAN SC8000 N/A N/A 64 N/A 443,1 Set Discos 1 SAN SC220 N/A N/A N/A 5 x 200 | 19 x 600 351 Set Discos 2 SAN SC220 N/A N/A N/A 16 x 1000 | 2 x 600 312 Switch SAN 1 B300 N/A N/A N/A N/A 48 Switch SAN 2 B300 N/A N/A N/A N/A 48 Switch LAN 1 C2950 45

Potencia estimada requerida Rack 2: 5.797,2

Arquitectura de Nube Privada para un Centro de Cómputo · gestiona las aplicaciones y los...

Documents

Transcript of Arquitectura de Nube Privada para un Centro de Cómputo · gestiona las aplicaciones y los...