Spanish (pdf)
Article in xml format
Article references
Automatic translation
Send this article by e-mail
Cited by SciELO 
Cited by Google 
Similars in
SciELO 
Similars in Google 
Permalink
1. INTRODUCCIÓN
Los centros de datos (CD), ya sean tradicionales o bajo el paradigma de la computación en la nube (CN), deben ser diseñados siguiendo un enfoque top-down, en busca de una solución eficiente que realmente satisfaga los objetivos del negocio, las restricciones y requerimientos técnicos de las entidades que los necesitan1), (2. Actualmente, sin embargo, la tendencia es dimensionar para garantizar la calidad de servicio (Quality of Service, QoS)3, y adoptar las soluciones comerciales de pago de grandes proveedores, o simplemente aquellas que mayor presencia estén teniendo en el mundo de los CD o de la CN, sin tener presentes en primer lugar las necesidades y demandas del cliente. Una de las principales causas de este fenómeno es que no se cuenta con una consultoría o método que indique cómo planear CD desde la perspectiva del negocio4), (5.
Con base en el reporte bianual del Standish Group desde el 1994 al 20166), (7), (8, los proyectos relacionados con las tecnologías de la información (TI) exitosos como promedio fueron de un 29%. La mayoría de los proyectos, un 52%, presentó serios problemas relacionados con sobrepaso del presupuesto asignado, entrega fuera de tiempo o deficiencias e insuficiencias en las características y funcionalidades requeridas; mientras que un 19% resultaron fracasados por cancelación antes de su finalización o culminados, pero nunca explotados. Como parte del estudio, y en concordancia con otras consultoras como Gartner y la academia9), (1 se identificaron un conjunto de factores que llevaron al traste los proyectos como: fallo en la identificación de los objetivos del negocio y los requerimientos, cálculo inexacto de los recursos, no gestión de riesgos, deficiente comunicación entre los clientes, los desarrolladores y usuarios, y empleo de tecnologías no adecuadas.
En este escenario el presente trabajo muestra un estudio del estado del arte acerca de los métodos de diseño para nubes privadas (NP) o CD dedicados preferiblemente a pequeñas y medianas empresas (PyME). En el análisis se evidenció: la relación insuficiente entre las estrategias y métodos de diseño y los objetivos del negocio, restricciones y requerimientos técnicos de las entidades que los necesitan; y los altos requerimientos de cómputo que como mínimo imponen las soluciones comerciales con mayor presencia en el mercado en relación con los bajos requerimientos de recursos de cómputo que presentan las PyME para el soporte de los servicios de las TI y las comunicaciones (TIC) que requieren para cumplir con su misión y hacer realidad su visión. Lo anterior puede originar impactos económicamente negativos para este tipo de organizaciones, obstaculizando la adopción del paradigma.
El artículo se estructura de la siguiente forma: “Procesos para adoptar el paradigma de la computación en la nube”, expone las fortalezas y debilidades de los métodos propuestos por el Consejo de Estándares de la Nube para Clientes (Cloud Standards Customer Council, CSCC) y por los investigadores Caesar Wu y el Dr. Rajkumar Buyya; “Procesos, métodos o buenas prácticas para diseñar nubes privadas”, muestra los procedimientos, consideraciones, criterios y referencias de diseño enfocados a NP que fueron identificados en la academia y en la industria; y finalmente, las “Conclusiones”, que presenta los principales resultados de la investigación realizada.
2. PROCESOS PARA ADOPTAR EL PARADIGMA DE LA COMPUTACIÓN EN LA NUBE
En la revisión de la literatura realizada resaltaron los procesos propuestos para adoptar el paradigma de la CN con el objetivo de resolver problemas del negocio por: el CSCC en su “Guía práctica hacia la computación en la nube, versión 3.0”10, p. 0) y por los autores Caesar Wu y Rajkumar Buyya en su libro Centros de datos nube y modelación de costos. Guía completa para planificar, diseñar y construir un centro de datos nube1. Ambos procesos, mostrados en las Figs. 1 y 2, respectivamente, defienden el enfoque de diseño desde la perspectiva del negocio, así como lo hacen los autores de la presente investigación. Las propuestas concuerdan en que: 1) durante el proceso de diseño deben participar todos los involucrados en el flujo productivo del negocio que serán afectados con la adopción del paradigma, enfatizando en la necesaria participación permanente del líder de la entidad, el cliente, así como las funciones del analista del negocio; 2) en primera instancia deben ser identificados los problemas por resolver del negocio con el proyecto de Nube, para esto proponen: conocer las variables del negocio, y caracterizar tanto los servicios TIC como la infraestructura de cómputo y de red que los sustentan; 3) posteriormente, y en función de la fase anterior, deben ser identificados las metas, objetivos y requerimientos para cumplir por el proyecto de Nube; y 4) la propuesta obtenida debe ser validada y optimizada con base en las metas, objetivos y requerimientos acordados en las fases iniciales del proyecto. El CSCC resalta la necesidad de que el proceso de evaluación debe ser sustentado en métricas y pruebas personalizadas al caso de uso en cuestión.
En el proceso de resolución de problemas de negocios Extremo-Extremo (End two End, E2E), en la Fig. 2, se observan cinco fases que abarcan desde la identificación de los problemas hasta la entrega y puesta en marcha del proyecto concebido. Estas fases engloban bloques funcionales que indican acciones por realizar, pero no aportan instrumentos, procedimientos o buenas prácticas para diseñar la infraestructura de un CD bajo el paradigma de la CN tomando en cuenta los objetivos, requerimientos y restricciones del cliente ya identificados. Los autores de la presente investigación consideran lo anterior como insuficiencias, presentes también en la propuesta del CSCC, que muestran cómo aún no se imbrican los objetivos del negocio con el proceso de diseño en la práctica, a pesar de que se resalte su obligatoriedad, lo cual provoca soluciones ineficientes o insatisfactorias1), (2, así como que la mayoría de las PyME dependan de consultoras externas o de los proveedores líderes de la rama para poder adoptar el paradigma11), (4), (12.
3. PROCESOS, MÉTODOS O BUENAS PRÁCTICAS PARA DISEÑAR NUBES PRIVADAS
En post de identificar buenas prácticas, consideraciones, criterios y referencias de diseño enfocados a NP, fue realizado un estudio del estado del arte que abarcó la documentación publicada relativa al tema en revistas y eventos nacionales e internacionales, así como guías de diseño y despliegue de destacados proveedores de la rama. Pocas fueron las publicaciones académicas encontradas, mientras que en la industria las guías y manuales giran en los productos propios de los proveedores, considerándose por los autores de la presente investigación insuficiente la información disponible para poder afrontar el desarrollo de un proyecto de diseño de esta índole, en especial por parte de las comunidades de las Plataformas de Gestión de Nubes (Cloud Management Platform, CMP) que son de software libre y código abierto (SLCA).
3.1 Evaluación de ciclos de vida de diseño y gestión de centros de datos
En el estudio del estado del arte fueron identificados cuatro ciclos de vida de diseño y gestión de CD propuestos por: Kapil Bakshi13, Montri Wiboonrat11, la compañía de Petróleo Nacional de China14, el Centro de Computación de Alto Desempeño (CECAD) de la Universidad Distrital Francisco José de Caldas de Bogotá, Colombia15, y el flujo de procesos de diseño de CD de los Laboratorios de Hewlett-Packard (HP)16. Las cuatro propuestas mostradas en la Fig. 3 y el flujo de procesos de diseño de HP presentan: 1) Un desarrollo del diseño bajo la perspectiva del negocio. Todos los ciclos parten de una primera fase donde deben ser identificados los objetivos del negocio, las restricciones y los requerimientos técnicos por cumplir. Destaca en esta etapa la propuesta de HP, en que incluye entre sus tareas la identificación de los servicios a soportar y sus requerimientos, incluyendo la obtención de sus perfiles de carga y posibles variaciones en el tiempo, para en base a estos datos dimensionar la infraestructura del CD. 2) Una estructuración de los ciclos de vida de diseño y gestión en cuatro fases fundamentales: la identificación de los objetivos del negocio, restricciones y requerimientos técnicos por cumplir; el diseño de los bloques funcionales que componen la NP; la evaluación y optimización de la propuesta; y la Operación, administración y mantenimiento (OAM) y renovación de la NP implementada.
Los autores de la presente investigación consideran pertinentes las características de los procesos de diseño antes especificadas, ya que se evidencia la intencionalidad de estructurar procedimientos de diseño que garanticen que la solución obtenida responda a los objetivos y necesidades reales que presente un negocio. No obstante, 1) No se realizan distinciones ante posibles particularidades de diseño cuando se tributa a PyME o grandes empresas. Los autores consideran esto como una debilidad, ya que de realizarse se simplificaría el proceso de diseño. 2) No se brindan instrumentos que permitan desarrollar la fase de identificación de los objetivos del negocio y sus restricciones. 3) No se aborda cómo afrontar el diseño de los diferentes bloques funcionales de la NP, ni se especifica un orden lógico de diseño de estos, ni su relación de precedencia. Tampoco se proponen criterios o directrices de diseño, así como soluciones o tecnologías por considerar. Solo en 15 fue descrito que el diseño de la infraestructura partió de la selección del CMP, y que el resto de los bloques fueron concebidos bajo las consideraciones de diseño brindadas por la comunidad de este y los requerimientos de la entidad; así como brindó los criterios de selección seguidos. 4) No se proponen pruebas para evaluar la propuesta de diseño.
Estas insuficiencias evidencian el reclamo de la comunidad científica y los especialistas de TI de las PyME referente a la carencia de métodos que permitan afrontar el diseño de NP bajo las perspectivas del negocio4), (17), (2. Se plantea que la mayoría de las guías y procedimientos existentes pertenecen a los proveedores de soluciones propietarias, que describen cómo proyectar y desplegar CD, pero restringido a sus tecnologías y a la de sus socios4.
3.2 Guías de diseño de nubes privadas propuestas por los proveedores líderes
En el estudio fueron incluidos procedimientos o guías de diseño y despliegue de CD y NP empresariales de los proveedores: Microsoft18, Cisco19) y (20, Juniper21, VMware22, Huawei23 y Lenovo24) y (25; así como de la comunidad SLCA: OpenStack26. Su selección estuvo basada en que fuesen proveedores/comunidades líderes a nivel internacional en el mundo de las TI, y que tuviesen disponibles documentos que abordasen el tema tratado.
La mayoría de los documentos consultados definen una arquitectura de referencia (AR) para el diseño y despliegue de NP. Estas AR siempre se encuentran enmarcadas a la solución del (los) proveedor(es) que emite(n) la documentación. La tendencia actual por parte de los proveedores es a simplificar el proceso de diseño y optimización de NP a las PyME, razón por la cual las empresas de software, como Microsoft y VMware han publicado AR de NP cuyos recursos físicos son implementados con el hardware de sus denominados Original Equipment Manufacturers (OEM), y viceversa. El resultado obtenido es la propuesta de un conjunto de soluciones de NP preconcebidas, que pueden ser rápidamente adoptadas por las diferentes entidades, pero que no necesariamente ofrecen un costo/beneficio aceptable para todas las PyME. Ejemplos son las propuestas en: 23), (24), (25) y (21. La mayoría de las AR analizadas no describen un conjunto de fases o tareas concretas que indiquen cómo afrontar el diseño de una NP partiendo del análisis de las necesidades y requerimientos de la entidad. Estas se enfocan en la descripción de las tecnologías que permiten desplegar los diferentes bloques funcionales que conforman la NP, aportando en cada subsistema cuando se considera pertinente, criterios de selección y buenas prácticas de diseño y configuración, para lograr requerimientos no funcionales (RNF) como desempeño, escalabilidad, disponibilidad y seguridad.
De manera general, se plantea en todos los documentos que los diseños deben ajustarse a los objetivos del negocio y a los requerimientos de las entidades, pero se considera por los autores de la presente investigación que no se articulan los mecanismos adecuados para garantizarlo, así como para poder evaluar su cumplimiento. De los documentos consultados solo: 1) 24), (25) y (26 comienzan sus pautas de diseño con acápites dedicados a la identificación de los valores del negocio, los requerimientos funcionales (RF) y RNF que se persiguen con el proyecto de la NP. En 26 advierte que en caso de existir un CD inicial este debe ser caracterizado, en función de esclarecer el punto de partida y los problemas por resolver, así como para identificar los elementos que pueden ser reutilizados.
La Fig. 4 muestra que el diseño de los bloques funcionales que conforman la infraestructura de las NP no presenta un patrón de diseño en relación con un orden lógico establecido. Ningún proveedor se pronuncia por una relación de precedencia entre los diferentes subsistemas. Sin embargo, Cisco y Microsoft 20), (18 en sus guías de despliegue especifican que los diseños de los recursos de cómputo, red y Sistema de Almacenamiento (SA) se encuentran estrechamente relacionados, y que las decisiones en uno tienen efecto en el otro. Los autores de la presente investigación consideran que debe definirse en el proceso de diseño las restricciones que impone un bloque sobre el otro, para evitar posibles iteraciones innecesarias y complejidad.
De manera general los proveedores y comunidades SLCA plantean que el dimensionamiento debe partir de la identificación y caracterización de los perfiles de carga e índices de utilización de los servicios para soportar, en función del número de usuarios presente y futuro. No obstante, no se brinda un instrumento que implemente la afirmación anterior. Los recursos virtuales son obtenidos empleando fórmulas que parten de las características de los nodos físicos, tanto de cómputo como de almacenamiento, empleando por tanto una filosofía bottom-up, y no top-down, que, a juicio de los autores, es la que tributa con mayor efectividad a un diseño ajustado a las necesidades reales del cliente. En función de los resultados obtenidos se estima el número y tipos de máquinas virtuales (MV) que pueden ser desplegadas en la NP. En el caso de la red, solo se plantea su capacidad para cada nivel de las topologías propuestas. Por tanto, la relación costo/eficiencia, y por consiguiente costo/beneficio, puede que no sea la adecuada para las entidades, dado que el cálculo de la capacidad del CD no se realiza a partir de la carga esperada real.
En función de los requerimientos mínimos de hardware que imponen Microsoft y OpenStack para desplegar una NP, así como las soluciones preconcebidas que ofrecen Microsoft-Huawei23, VMware-Lenovo y Red Hat Enterprise Linux OpenStack-Lenovo24), (25, los autores de la presente investigación consideran que para empresas con pocos requerimientos de recursos de cómputo para el soporte de los servicios de usuario y del flujo productivo de la entidad, las soluciones antes mencionadas pueden resultar inadecuadas debido a: 1) Los SA que proponen los proveedores Microsoft y VMware son soluciones propietarias con altos costos en el mercado. 2) Microsoft y VMware proponen soluciones de software que requieren pago de licencias. 3) Se dedican de dos a siete nodos con altos requerimientos de cómputo para desplegar los servicios de soporte y de gestión de la infraestructura. Para PyME este podría ser el número de nodos necesarios para el soporte de los servicios de la entidad, de hecho, el número de nodos para el soporte de la carga útil es como promedio de tres a cuatro nodos.
Los autores de la presente investigación, tomando como referencia los datos expuestos consideran que existe una relación insuficiente entre las estrategias y métodos de diseño CD, en especial aquellos bajo el paradigma de la NP, y los objetivos del negocio, restricciones y requerimientos técnicos de las PyME que los necesitan.
4. CONCLUSIONES
El modelo de servicio de NP constituye una posible solución económica, efectiva y segura para las infraestructuras TIC de las PyME con pocos requerimientos de recursos de cómputo para el soporte de los servicios de usuario y del flujo productivo de la entidad. No obstante, se identificó que su adopción se encuentra obstaculizada por la relación insuficiente entre las estrategias y métodos de diseño de CD, en especial aquellos bajo el paradigma de la NP, y los objetivos del negocio, restricciones y requerimientos técnicos de las PyME que los necesitan, problema por resolver, lo cual puede originar soluciones ineficientes con impactos económicamente negativos. La razón principal se debe a la carencia de métodos que permitan afrontar el diseño de NP bajo las perspectivas del negocio, en especial por parte de las comunidades de las CMP SLCA; mientras que la mayoría de las guías y procedimientos existentes pertenecen a los proveedores de soluciones propietarias, que describen cómo proyectar y desplegar CD, pero restringido a sus tecnologías y a la de sus socios, originando que la mayoría de las PyME dependan de consultoras externas o de los proveedores líderes de la rama para poder migrar al nuevo paradigma. Asimismo, la adopción de mercado puede resultar inadecuada para las PyME, en especial aquellas con restricciones económicas, dado los requerimientos de cómputo que como mínimo imponen estas soluciones o el pago de licencias.
Se necesita entonces la concepción de un método de diseño de NP desde la perspectiva del negocio, para lograr en el proceso de diseño la vinculación estrecha entre los objetivos del negocio, las restricciones y requerimientos técnicos que precisa la entidad cliente; y las estrategias de diseño de la NP como un todo. Esta última abarca el diseño de los diferentes subsistemas independientes e interoperables entre sí, que conforman a la NP, los cuales deben heredar las exigencias impuestas al sistema en general.
