Las nubes privadas… ¿existen?
Email
| 
¿Desea imprimir?
Regístrese ahora
Algunos creen que se trata de la misma estrategia empleada en los data centers, sólo que con un nombre más bonito. No hay que hacerles caso.Las compañías que desean aprovechar los servicios del cómputo en nube (o cloud computing) sin los riesgos que ello acarrea, buscan crear ambientes tipo nube en sus propios centros de datos. Para ello tienen que añadir una capa de nuevas tecnologías a los sistemas de data centers y procesos existentes: gestión de la virtualización, API para la nube, portales de autoservicio, sistemas de retrocarga y más.
Todo aquel que pretenda hablar de esta nueva forma de hacer las cosas debe aprestarse a enfrentar debates. De por sí, el término “nube privada” pone los pelos de punta a algunos veteranos del ramo de la computación, quienes argumentan que, por definición, el cloud computing es algo que ocurre fuera del propio centro de datos, o que las tecnologías que entran en las nubes privadas no representan nada nuevo bajo el Sol.
Si bien no hay una sola pieza de la arquitectura interna de la nube que dé la impresión de ser un avance tecnológico, las nubes privadas representan una convergencia de tendencias tecnológicas de gran promesa para el cómputo empresarial. Las nubes privadas son una combinación más poderosa de hardware modular que se puede rebanar en pequeñas piezas, y donde las redes y el almacenamiento se distribuyen dinámicamente mediante políticas preestablecidas.
Una capa de gestión de la virtualización trata todo el conjunto de tecnologías como un recurso combinado, mientras que los servicios Web y de redes por Internet permiten interactuar con la nube desde cualquier ubicación. Además, es posible crear nuevos servicios a partir de los existentes hospedados en la nube, y correr cargas de usuarios con sólo un clic.
MÁS NUBES PARA SACAR VENTAJA. Algunos trazan una firme línea divisoria entre las nubes públicas operadas por Amazon Web Services (AWS), Google y Microsoft, y los data centers corporativos de uso mixto. Dicha línea solía existir ya entre las redes empresariales propietarias e Internet.
Con todo, las intranets internas gradualmente desplazaron algunas de las funciones de las redes empresariales porque estaban moldeadas sobre TCP/IP y, por lo mismo, eran compatibles con el Web que las rodeaba. A la postre, los TCP/IP estándar sustituyeron las redes corporativas propietarias e Internet comenzó a funcionar como una extensión de ellas.
Un fenómeno parecido podría tener lugar con el cloud computing. Si las eficientes nubes externas –como la Elastic Compute Cloud, de AWS– se basan en unos cuantos estándares, ¿por qué no van a poder los centros de datos comenzar a ser construidos como nubes internas que más estrechamente se les parecen? Y una vez que ambas redes comiencen a emparejarse en arquitectura, ¿qué impedirá que la carga de trabajo en una se exporte a la otra?
A este concepto se le conoce como “nube híbrida”, por tener parte del servicio de nube pública y parte nube interna. Bob Muglia, presidente de la división de servidores y herramientas de Microsoft, espera que muchas organizaciones se muevan en esa dirección.
“Todos los clientes tendrán servidores Windows en sus instalaciones y, con el tiempo, les añadirán el uso de servicios de nube”, dice Muglia. Pero también estima que será muy difícil arrancar las nubes híbridas cuando impliquen aplicaciones que requieran una auténtica integración transnubes y no se trate simplemente de mover una aplicación virtualizada de una nube privada a una nube pública: “La parte difícil es mover todos los servicios adheridos a esta carga de trabajo”.
El grupo de Muglia espera resolver el problema incorporando tecnologías desarrolladas por el sistema operativo para nube Windows Azure al Windows Server, de modo que ambos ambientes no sólo se parezcan el uno al otro, sino que también trabajen juntos. Por lo que se refiere a la compañía de Redmond, todo éste es camino que tiene por andar.
Stephen Brobst, CIO del proveedor de tecnología de datos Teradata, prevé otro tipo de complicaciones: mientras que es técnicamente factible correr data warehouses en las redes públicas, hay preocupaciones de privacidad y aprovisionamiento que vuelven prácticamente inconcebible hacerlo con datos personales.
MÁS VALE IRLA CONSIDERANDO. Leyes como la Health Insurance Portability and Accountability Act (HIPAA), la Sarbanes-Oxley y el estándar PCI del ramo de las tarjetas de crédito imponen estrictos controles en lo referente a datos personales. Pero un data warehouse en una red interna deja a salvo tales inconvenientes. eBay, cliente de Teradata, corre internamente un data warehouse de 5 petabytes (PB), añadiendo 40 teras por día en una red (grid computing) de servidores x86.
Las redes internas pueden ayudar a las compañías de diferentes maneras; la ‘elasticidad’ de la computación es una de las principales. Si ocurre un pico en la demanda de sistemas IT –por ejemplo, el lanzamiento de una nueva línea de productos que abarque los canales de manufactura, marketing y distribución– se puede escalar para satisfacer la demanda. Y si un negocio espera picos en su sistema de e-commerce durante una promoción, un gerente de mercadotecnia o el enlace IT-marketing podría establecer una nube interna para el manejo de picos, manteniendo los demás trabajos en suspenso temporal, y facturar el costo al área de promociones.
Ello lleva al reino de los portales de autoservicio, las mediciones y los sistemas de retrocarga que se requieren para hacer posible la entrega de recursos IT sobre demanda, medir el consumo y adjudicar los gastos cada vez con mayor detalle. El mejor modo de establecer un sistema así es con los productos de administración de laboratorios virtuales que los desarrolladores de software usan para aprovisionar servidores, dice el analista de Forrester Research, James Staten. El vCenter Lab Manager (VMware) y el Lab Manager (Citrix Systems), entre otros, vienen con portales de autoservicio.
Incluso si no se está pensando en implementar una red interna en este momento, sería bueno considerar un proyecto piloto. “Las empresas deben comenzar a entrenarse ahora y así llevar una ventaja en cloud computing para de aquí a dos años”, considera Staten.
EL ROL DE LOS PROVEEDORES IT. Para pensar, pues, en alguna arquitectura de nube interna, lo primero que se requiere son servidores commodity x86, y cuanto más semejantes sean en su configuración tanto más fácil será manejarlos en un clúster o grid. (No hay más que mirar a Amazon, Google y Microsoft para comprobar que servidores x86 que parecen todos iguales son la base de las arquitecturas de sus redes.).
En la mayoría de los casos, los diseñadores de redes privadas requieren implementar también una capa de administración de la virtualización que va más allá de lo que ya se tiene instalado. Y es que en la mayoría de los casos es difícil obtener las eficiencias requeridas y manejar la escala involucrada sin una gestión de la virtualización completa.
En este terreno, el líder al que muchos están copiando los pasos para dirigirse hacia nubes privadas e híbridas es VMware. Este año, la firma liberó lo que llama su Virtual Data Center Operating System (VDC-OS), que ilustra con un diagrama tanto la nube interna como la externa. El fin de VMware es que los clientes usen VDC-OS para gestionar servidores x86 y el almacenamiento correlacionado como recursos combinados, y mover cargas de trabajo virtualizadas entre las nubes internas y externas.
El poder aprovisionar, monitorear y mover servidores virtuales son ya capacidades inherentes a VDC-OS, pero siguen faltando otras herramientas propias de redes privadas. Una es vCloud (que VMware describe más como una iniciativa que como un producto), cuyo propósito es que los usuarios de redes privadas obtengan servicios de redes externas.
Por ese motivo, la compañía está aliándose a proveedores de servicio como Melbourne IT, Savvis, SunGard y Terremark. Lo hacen vía la vCloud API. Si VMware logra obtener más amplia aceptación para sus API resultará mucho más fácil enviar una carga de trabajo a un nube externa o que una carga de trabajo en una nube externa aproveche servicios que son parte de la infraestructura empresarial. En este momento, la vCloud API está en entrega limitada.
A más largo plazo, el CEO Paul Maritz señala que VMware buscará dar a los clientes una única interfaz de administración con la que corran máquinas virtuales en redes privadas o públicas. Para saber si la empresa cumplirá tales expectativas habrá que esperar, más o menos, entre año y medio y dos años.
Recientemente, Sun Microsystems también introdujo una plataforma para nubes privadas (Sun Open Cloud Platform), así como servicios de nube pública (Sun Cloud) que se basan en un conjunto de API abiertas. Pero dado que la firma pasará a formar parte de Oracle, habrá que ver cuáles son los planes de ésta con respecto al tema.
Los usuarios de la nube Amazon EC2, por su parte, podrían optar por monitorear el proyecto de fuente abierta Eucalyptus, que consiste en crear un conjunto de API abiertas que pudieran usarse para construir nubes privadas que funcionarían de una manera similar a como lo hace EC2. Las API de Eucalyptus se podrían emplear para activar el equivalente de la base de datos Simple DB de EC2 o servicios de almacenamiento S3. Una aplicación construida usando tales interfaces se podría adaptar fácilmente para su exportación a la nube de AWS.
Ahora bien, otro problema que se debe solucionar en las redes privadas es la necesidad de un sistema subyacente de archivos de almacenamiento compartidos, pues sin él un conjunto de máquinas virtuales no se puede tratar como un recurso elástico. Esto es, cuando la máquina virtual se mueva a un nuevo servidor físico, no sólo dejará atrás los CPU y la memoria a favor de una nueva máquina, sino que también se migrará alejándose del almacenamiento que se le había señalado y no podrá extraer los datos previos a la migración.
La solución de VMware: migrar a VMotion de máquinas virtuales imponiendo su propio sistema de archivos de almacenamiento sobre una porción de arreglos de discos del cliente.
TRABAJAR PARA SIMPLIFICAR. Las redes internas no son sólo una manera más eficiente de mantener las prácticas de los viejos centros de datos. “Hay que repensar los procesos que se hacían antes”, dice Jerry McLeod, vicepresidente de gestión de producto en el configurador de cargas de trabajo de nube FastScale Technology. En lugar de tener un administrador de sistemas que configure cada servidor, la configuración de máquinas virtuales se hace basándose en unas cuantas imágenes de referencia que se usarán plenamente en la empresa.
En el data center tradicional, un administrador de redes mapea la añadidura de un nuevo servidor a la red, asignándole recursos de switch y ruteador; entonces un administrador de seguridad y cumplimiento de normas checa las configuraciones e instala un protección adicional requerida para el nuevo servidor. Con una nube interna, esas tres tareas pueden concentrarse en una: la creación de una máquina virtual que satisfaga las tres acciones. Los departamentos IT deben trabajar en el proceso de construir máquinas virtuales de modo que lo logren automatizadamente, sin interrumpir las operaciones del área IT, crear riesgos a la seguridad o desproteger la privacidad de los datos, añade McLeod.
Una vez que algunas aplicaciones establecidas corren en una red interna, los gerentes deberán pensar cómo “arquitecturar” las futuras aplicaciones para la red. En el caso de las redes externas, las opciones quedan limitadas a lo que cada uno pueda correr. Por ejemplo, el Google App Engine ahora corre aplicaciones que deben escribirse en Python 2.5. Si se recurre a un proveedor externo, como Salesforce.com, se podrán usar los datos internos y customizar la aplicación, pero hay que trabajar en lenguaje Visual Force (propietario de Salesforce) o en el otro único lenguaje soportado, Apex (de Adobe).
Microsoft busca ampliar la selección a sus populares tecnologías Visual Studio y .Net en su futura nube Azure, pero los desarrolladores de nube quedarán restringidos a los productos y servicios de la firma, que pueden o no funcionar al tratar de coordinarlos con redes internas.
En cuanto a las nubes internas está la perspectiva de que los desarrolladores internos sigan usando su ambiente de desarrollo favorito y su sistema de gestión de códigos para producir aplicaciones de nube. También tendrán acceso a código customizado y a los servicios internos de la empresa, con tal que hayan sido diseñados para ser consumidos como servicios. Las nubes internas tienen el propósito de accesar y utilizar servicios, y en ese sentido son un ambiente específico de ejecución para sistemas de arquitectura orientados a servicios (SOA, por sus siglas en inglés).
De igual manera, en lugar de ajustarse al formato de archivos virtuales de AWS, llamado Amazon Machine Image (AMI), los administradores de nubes privadas pueden trabajar con los archivos virtualizados con los que se sientan más cómodos en sus propios centros de datos. Se están construyendo herramientas para convertir tales archivos en el formato usado por la nube externa. La herramienta en línea rBuider, de rPath, por ejemplo, empaca las aplicaciones virtuales de AMI para enviarlas a la nube de Amazon.
Además, al construir en la organización una nube interna, probablemente el nuevo usuario final encontrará formas de combinar servicios y generar aplicaciones que IT no haya considerado.
Sí, una corriente de usuarios finales multiplicará las máquinas virtuales y aumentará la complejidad del data center. Pero si también incrementa los ingresos, por el hecho de que las unidades de negocio ejecutan más rápidamente las nuevas oportunidades, las redes privadas podrían convertirse, en tiempo récord, en un modelo de entrega IT muy buscado.
La perspectiva de que la creatividad interna un día se juntará con servicios de nube externos bien diseñados es tan atractiva que quienes se muestran escépticos en lo referente a nubes privadas no prevalecerán mucho tiempo.
3 RAZONES PARA CONSTRUIR NUBES PRIVADAS
Menor capacidad requerida
Conjuntar los recursos permitirá a las compañías reducir su capacidad de cómputo al otorgar mayor potencial a tareas de prioridad más alta durante los picos
Reducción de gastos fijos
Los servidores x86 y los recursos afines contenidos en un centro de datos virtual se pueden manejar como una unidad
Preparación para lo que viene
Una nube privada contribuirá a que los equipos IT estén listos para la existencia de nubes híbridas (privado-públicas) en el futuro data center
LA INFLUENZA, BIEN VIGILADA
Éste es un caso de éxito que se adelantó incluso a la propuesta actual de proveedores IT
En Estados Unidos, el Departamento de Asuntos de los Veteranos (VAD, por sus siglas en inglés) ha desplegado una pequeña nube interna. Deseaba un sistema de aviso temprano que pudiera analizar datos de su centenar y pico de clínicas y hospitales, y localizar así cualquier brote de enfermedades infecciosas, pero no disponía de un presupuesto considerable. El proyecto, bautizado Sistema de Vigilancia de Infecciones y de Influenza, se construyó sobre seis servidores blade estándar con redes y almacenamiento de entrada y salida (I/O) convergidos. Los CPU se pueden manejar individualmente o como un todo virtualizado, con cambio de cargas de trabajo y de capacidad según se requiera.
Los seis sistemas blade corren software de gestión de nubes de Egenera, un manejador encargado de las I/O, redes y almacenamiento para los servidores; todo como un conjunto lógico que puede ejecutar varias aplicaciones, mientras tenga los suficientes caballos de fuerza para hacer su trabajo.
Los blades y el almacenamiento (de Dell) se pueden virtualizar como un recurso conjunto, de forma que todo el potencial de procesamiento se dedica rápidamente a la nube del VAD, que es su tarea de más alta prioridad.
Por muchos aspectos, el nuevo sistema se ha adelantado a la plataforma de cómputo unificado recientemente introducida por Cisco: chasis de servidores multiblade virtualizados con I/O convergidos, del que Cisco alardea como lo más apropiado para el cloud computing.
