O410Manuel nubes

OPINION
O410Manuel Nubes
5400
Nubes federadas
Por Manuel Dávila Sguerra
[email protected]
Siguen apareciendo más preguntas e iniciativas en el tema de la computación
en la nube, pues, al fin y al cabo, es un paradigma en proceso de convertirse en
un estándar.
En esta ocasión me voy a referir a una investigación que se está desarrollando
entre universidades y empresas europeas que han publicado un artículo en la
revista Computer de la IEEE y daremos algunas inquietudes relacionadas con
nuestras experiencias en el Centro de Innovación Social de Uniminuto y, más
específicamente, en el Laboratorio de software libre que usa computación en la
nube privada y pública.
La pregunta nace del hecho de que cualquier infraestructura informática creada
bajo el concepto de computación en la nube tiene características finitas de
poder computacional, de redes y de complejidad tecnológica. No es concebible
que una plataforma pueda soportar todo el crecimiento que se dé en una
organización y además surge el peligro de colapsos en las plataformas. Siendo
así: ¿qué alternativas habría para dar continuidad al negocio, en caso de darse
dichas circunstancias?
Me voy a permitir hacer un poco de historia por la similitud de la computación
en la nube de hoy, con los sistemas centralizados de antes. En los años 70 en
Bogotá, existían grandes centro de cómputo y se tenía la preocupación de un
colapso que creara situaciones catastróficas. Algunos de los centros de
cómputo más notables usaban equipos IBM 360, que fueron sistemas pioneros
de mucha de la tecnología actual. Un grupo conformado por la IBM de
Colombia, la Universidad de los Andes, Colsistemas, la Universidad Nacional,
las empresas del Acueducto y Energía de Bogotá (Ceprodate) y el Dane,
conscientes del peligro de un colapso, conformamos, en esa época, un comité
para estudiar lo que a propósito del tema que estamos tratando, lo hubiéramos
podido llamar “Centros de cómputo federados”. Personalmente dirigía el centro
de cómputo del Acueducto y la Energía - Ceprodate. El propósito era crear
políticas y estándares de configuración de los sistemas operacionales que nos
permitieran ejecutar los procesos en cualquiera de centros de cómputo en caso
de un colapso.
A propósito de esa época, hace unos años organicé un encuentro en Acis
llamado “La tecnología de hace 30 años” en el que invitamos a los pioneros
para contar cómo eran esos centros de cómputo, video que se puede ver en
youtube (http://e-logicasoftware.com/tutoriales/conferencias/video-la-tecnologiade-hace-30-anios.html) y que tiene interés histórico y académico.
Hoy, los centro de cómputo se llaman centros de datos o Data Centers y su
tecnología se basa en las telecomunicaciones y el Internet. En ellos, el riesgo
de colapso o de saturación en su capacidad de procesos existen, como bien se
formularon en la pregunta de la investigación que menciona la revista de la
IEEE sobre “Nubes federadas”, la cual es una iniciativa Europea llamada
Reservoir (Resources and services virtualization without boundaries).
Este modelo separa las actividades funcionales del centro de datos en:
aplicaciones de software, por un lado, y de infraestructura informática, por el
otro. Plantean un ejemplo en el cual las aplicaciones se reparten así:
Centro de datos 1: aplicación 1 y la 2
Centro de datos 2: aplicación 2 y la 3
Centro de datos 3: aplicación 3
Las aplicaciones se instalan en los servidores bajo un contrato de SLA o service
level agreement (acuerdos de niveles de servicio) que estipulan los servicios
que se prestarán, las prioridades, las responsabilidades, las garantías, la
disponibilidad, el rendimiento, los costos, los sistemas operacionales, los
recursos de computación como memoria y almacenamiento, redes medidas en
mbps, redes desmilitarizadas y abiertas, IP disponibles, recursos de backup y
demás. El nivel de servicio permite especificar mínimos y máximos que deben
ser monitoreados si se quiere tener un control.
Todos estos elementos deben ser medidos en una nube federada (ver
http://host97-240-14962.serverdedicati.aruba.it/uploads/Publications/The%20RESERVOIR%20Model
%20and%20Architecture%20for%20Open%20Federated%20Cloud%20Computi
ng.pdf en donde se pueden leer los detalles técnicos de este trabajo), con
políticas técnicamente definidas para que a través del software, que debe ser
desarrollado, las plataformas puedan tomar decisiones automáticas
relacionadas con el uso más eficiente de los recursos.
En nuestro caso particular del Laboratorio de investigación en software libre
hemos tomado un proyecto relacionado con la generación automática de
sistemas orientados a la web, que incluye generación de programas,
generación de portales y aplicaciones de discos virtuales, correo electrónico,
control de spam, diseño de software seguro, incluido detección de intrusos
dentro de las aplicaciones por encima de la seguridad perimetral, y una
propuesta para la auto documentación automática del software que plantea un
modelo para que él mismo genere los diagramas de UML de aplicaciones y de
clases.
Esta plataforma está en dos servidores de Cloud: uno propio con KVM, el
mismo que usa el proyecto Reservoir y el otro con Vmware de Terremark, e
influenciados por los planteamientos de las Nubes Federadas estamos
estudiando la viabilidad de implementar modelos de aseguramiento de la
continuidad de las aplicaciones vista como “Software as a service – SAAS”.