Archivos de la categoría ‘Grid Computing’

h1

Grid Computing y GMPLS

Septiembre 25, 2006

Ando unos días buscando información sobre el tema. El otro día me entró el gusanillo mientras pensábamos en nuevos recursos que añadir a nuestro catálogo de "plugins" para el middleware. Y es que, como ya sabéis (Y si no lo sabéis ahora es el momento), soy Ingeniero de Telecomunicaciones y de entre los temas que más me atrajo en mi dorada época estudiantil, las redes ópticas y las nuevas arquitecturas definidas sobre ellas.

Las redes ópticas actuales constan de un elevado número de capas que otorgan la capacidad de manejar perfiles determinados de información, lo que estaba tendiendo a redes demasiado específicas y difíciles de gestionar. Pero a algunos  iluminados se les encendió la bombilla y  pensaron que las redes debían simplicarse, evitando funcionalidades redundantes entre capas. Esto derivo hasta llegar a tener solo dos.  Esto ha permitido desarrollar un plano de control común, y entre algunos protocolos de gestión, se encuentra GMPLS.

GMPLS es el resultado del trabajo entre Optical Internetworking Forum, Optical Domain Service Interconnect consortium y la Internet Engineering Task Force que pretende estandarizar un protocolo que pueda servir para todo tipo de tráfico. La clave se encuentra (y aquí os empezará a sonar a Grid) en la capacidad que tiene la capa de control de extender la topología de la red y la gestión del ancho de banda a lo largo de todas las capas para lograr un sistema eficiente que integre servicios y transporte.

Siguiendo con la filosofía Grid, GMPLS necesita tres componentes básicos para su correcto uso:

  1. Exploración de recursos: se obtiene información acerca de los recursos de red tales como conectividad o capacidad de los enlaces. Los mecanismos utilizados para diseminar esta información de estado se basan en una extensión del Internet Gateway Protocol (IGP).
  2. Selección de ruta: se utiliza para seleccionar una ruta apropiada a través de la red óptica inteligente en base a unas ciertas restricciones impuestas por el entorno y las limitaciones de la capa física.
  3. Gestión de ruta: incluye distribución de etiquetas, así como establecimiento, mantenimiento y terminación de ruta. Estas funciones se realizan por medio de un protocolo de señalización extendido como Resource Reservation Protocol for Traffic Engineering (RSVP-TE) o Constraint-routed Label Distribution Protocol (CR-LDP).

Estos tres componentes deben estar diseñados para su correcta utilización independiente entre si, permitiendo a las operadoras diseñar sus redes en consonancia con su modelo de negocio.

Aquí entra ThinkInGrid y nuestros componentes desarrollados. Queremos llegar a desarrollar un plugin capaz de virtualizar los datos provenientes de una red óptica. Esto debería permitir a empresas mucho más especializadas desarrollar productos o proyectos a medida para gestión de redes troncales:

  • Uso de información descentralizada y distribuida por la red.
  • Uso del plano de inteligencia artificial para optimizar y automatizar procesos de control y balanceo de carga.
  • Monitorización de red añadiendo un plano de decisiones automatizadas.
  • Desarrollo rápido y estandarizado de aplicaciones mediante el Framework.
  • Creación de mecanismos de colaboración entre operadoras o empresas complementarias.
  • Generación de nuevos modelos de negocio. Lo que permite una clara diversificación de servicios.

Bueno, creo que la cosa está clara. ¿Algún directivo de Telefónica, Wanadoo, JazztelOno, etc en la sala y que quiera desarrollar la idea con nosotros? Las líneas de teléfono y de mail quedan abiertas :).

h1

El concepto Grid sobre redes Ad hoc

Septiembre 8, 2006

Entre línea y línea de código son comunes los brainstorming entre el grupo de trabajo con el humilde propósito de descargar nuestras apretadas mentes y porqué no, encontrar esa idea que nos expulse del anonimato.

Hoy le ha tocado el turno a las arquitecturas ad hoc. Para quien no sea entendido en el tema, os comentaré que estas infraestructuras pretenden inhibir el concepto de nodo central para tender a un entorno en el que todos los recursos estén en igualdad de condiciones, o lo que es lo mismo, los elementos en una red, comparten las funcionalidades de cliente/servidor por igual.

Actualmente, uno de los máximos exponentes que se ha popularizado gracias a la implantación en un sinfín de "gadgets" es el sistema Bluetooth, que ha facilitado la interconexión entre dispositivos sin necesidad de pasar por entornos centrales, lo que ha facilitado saturaciones, colapsos, mal humor, etc.

Pues si señores, en ThinkInGrid hemos, estamos y vamos a seguir pensando en el concepto mientras desarrollamos nuestro entorno MIDDLEWARE - FRAMEWORK con el objetivo de descentralizar al máximo las "Funciones Grid" y de esta forma aprovechar las ventajas que proporciona las redes Ad hoc tanto en protección contra errores, transmisión de información, etc.

Nuestro Middleware basándose en estos conceptos proporciona una arquitectura muy ligera a cualquier estructura de recursos heterogéneos (Ordenadores, SCADAs, PDAs, camiones, dispositivos domóticos, etc.), sobre cualquier tipo de comunicación: Wireless, bluetooth, satélite, Powerline Communications, etc.; y mostrándose dentro de la misma estructura de información para nuestro FRAMEWORK, lo que permitirá a nuestros clientes afrontar infinidad de problemas (proyectos) de origen variante en un entorno homogéneo de análisis y desarrollo.

Por otro lado el FRAMEWORK, entre otros, proporciona los protocolos de protección de errores, descubrimiento de recursos, seguridad y gestión de colas que todo sistema Ad Hoc necesita. Todo embalado en un elegante sistema orientado a servicios (SOA) y que ha de facilitar el desarrollo estructurado de cualquier entorno empresarial.

En resumen, veamos las ventajas que proporciona durante la fase de desarrollo de un proyecto:

  • Reducción de tiempos de análisis. –> El desarrollo se define siempre para un mismo entorno.
  • Generalización de problemas –> Para un programador, la forma de utilizar un recurso CPU será igual que para utilizar un recurso EMBOBINADORA .
  • Fácil adaptabilidad de los equipos de desarrollo –> El desarrollo siempre se realiza sobre una misma plataforma
  • Disminución de impactos –> Si el entorno es conocido, los riesgos son fácilmente cuantificables.
  • Minimización de desviaciones. –> Si el entorno es conocido, las desviaciones son medibles.

En resumen, REDUCIMOS COSTES en los proyectos de desarrollo. Y aún nos falta por contabilizar el beneficio económico derivado de la propia aplicación o las ventajas técnicas que adquirirá el proyecto por el uso de nuestros entornos.

Nunca el pensar en entornos ad hoc fue tan fácil, con ThinkInGrid ese día ha llegado.

h1

Colaboro, ergo, me comprometo

Agosto 15, 2006

Estos días de meteorología variable en Barcelona desde el equipo de desarrollo de ThinkInGrid andamos ultimando la primera fase de nuestro entorno Grid. Como primer paso, a partir de ahora, eludiremos la palabra computing, en clara alusión a nuestra orientación a cliente y no a tecnología, tal y como se empieza a insinuar en los post de Albert y Diego.

Nuestro siguiente paso, utilizar dicho entorno para adaptar una aplicación ya existente a este nuevo modelo. Con esto, la búsqueda de varios objetivos:

  • Testear la arquitectura desarrollada.
  • Testeo integrado y funcional del entorno.
  • Testeo de los primeros servicios desarrollados y desarrollo de nuevos servicios básicos no contemplados en fase de análisis.
  • Empezar a realizar valoraciones prácticas de las mejoras que aporta el desarrollo realizado. Que mejor forma que acercarnos al cliente con números reales y no solo con propósitos
  • Primera aplicación grideada con nuestro Framework y que corre sobre nuestro Middleware.
  • Medir la convergencia con otras arquitecturas Grid pero que cumplen con los estándares.

Para dicho acometido, se está valorando la utilización de alguna herramienta colaborativa. Lo primero que se nos viene a la cabeza es el uso que se le está dando a dichas herramientas, que hasta el momento no está mal, pero estoy seguro que aún es insuficiente. Según la RAE COLABORAR: "Trabajar con otra u otras personas en la realización de una obra.".  Puntualizo con un sinónimo que nos aporta: CONTRIBUIR, lo siento, pero me encanta. Ahora yo modifico la definición para nuestro propósito: "Trabajar con otro/a u otros/as departamentos u organizaciones para la realización de una obra".

Si se empieza a pensar en la definición lo primero que se te pasa por la cabeza es: compartir ficheros, foros, interlocución on-line vía chat, etc. que no está mal, pero vamos, que me sabe a poco. ¿Se os ha encendido la lucecita? A nosotros si.  Y con nuestro entorno estamos pensando en:

  • Compartición de potencia de cálculo en una organización virtual. (1 problema contra 100 cpu’s = solución rápida y fiable).
  • Compartición de recursos (Yo invierto en una herramienta de análisis biomédico y vosotros aportáis a la herramienta vuestras BBDD –> Todos le sacamos la máxima rentabilidad).
  • Compartición de servicios (Yo se mucho de análisis de genoma, pero no puedo dedicar más personas a tu proyecto, te cedo el uso de mis servicios específicos para que explotes la información).
  • Toma de decisiones en tiempo-real (colaboración entre 10 empresas, no nos podemos reunir cada semana para decidir que hacer en tareas del día a día. Porque no automatizamos decisiones con inteligencia artificial en función de parámetros económicos, estratégicos, humanos, etc.).
  • Monitorización de la contribución (¿Como repartimos el pastel después de la colaboración? ¿Quien se ha mojado más el culo por esta idea? ¿Como saber con quien volver a trabajar?).
  • Y podríamos seguir…

Sin duda esta reflexión me ha llevado a creer y darme más argumentos para defender que nuestras herramientas llevan un buen camino si son lo suficientemente generalistas para poderse adaptar rápidamente a cualquier sector y son lo suficientemente concretas para aportar mejoras reales en entornos determinados. Porque por mucho que alguien se encabezone, la colaboración entre empresas de biomedicina nunca requerirá de las mismas necesidades que una colaboración entre entidades financieras.

h1

Una de proyecto

Julio 2, 2006

El viernes 30 de junio tuve la oportunidad de ir a presenciar el proyecto final de carrera de Lluís Ribes, uno de los miembros activos de Grid Cat, el grupo de investigación de donde han salido parte de los socios de Think In Grid .

El proyecto se basa en el estudio para la implementación de un mercado de recursos Grid, donde el precio de los mismos es oscilante dependiendo de varios parámetros de uso (rendimiento, tipología del recurso, popularidad del recurso, etc.) y la regulación de los mismos es realizada por una entidad central.

Personalmente, fue una grata sorpresa, ver como Lluís no solo fue capaz de realizar un estudio teórico, sino que mostró un interesante prototipo de herramienta de gestión (con los problemas que Murphy suele dar en estos casos), donde se pudo observar como el precio de los recursos variaba en función de la demanda que tenían y la calidad de los mismos, lo que hizo la presentación más atractiva de cara a los diferentes oyentes.

Es bueno ver como de vez en cuando se realizan proyectos totalmente enfocados a un entorno empresarial, huyendo, por así decirlo, de una perspectiva más universitaria.

Desde ThinkInGrid solo nos falta felicitar a Lluís Ribes, y esperar que ahora que ha acabado su aventura universitaria no deje abandonado todo su trabajo realizado con Grid Computing.