2011-12-29 9 views
7

Estamos considerando utilizar OSGi distribuido en nuestro entorno empresarial.
tendríamos la siguiente configuración:OSGi distribuido: ¿cuál es la forma correcta de administrar paquetes en todos los contenedores?

  • 10 a 100 contenedores OSGi en muchos anfitriones ofrecen diversos servicios.
  • Muchos de estos servicios son provistos por más de un contenedor.
  • Algunos de estos servicios pueden requerir ser consistentes en todos los contenedores (la misma versión implementada).

¿Cuál es la forma correcta de administrar el ciclo de vida de los paquetes (instalar, iniciar, actualizar, detener, desinstalar) en todos los contenedores?

Varios requisitos:

  • Dado que puede haber tantos contenedores, todos ellos deben ser manejados juntos; es decir, cuando estoy por actualizar un paquete, un solo comando debe actualizar todos los contenedores donde ese paquete ya está presente.
  • Los comandos deben poder repetirse: primero realice un comando en los sistemas de prueba y luego repita exactamente el mismo comando en el sistema de producción una vez que se completen las pruebas.

Agradezco cualquier sugerencia con respecto a la pregunta anterior.

Saludos, Marton

+0

¿Todos estos contenedores OSGi construyen un gran contenedor OSGi distribuido donde el servicio A en el host X puede usar el servicio B en el host Y tal como lo haría en el mismo host X? ¿o están separados el uno del otro y tienes solo 10-100 contenedores OSGi que deseas mantener? ¿y son todos iguales como 10-100 contenedores OSGi que tienen todos los mismos paquetes y quieres enviar un comando (como "instalar") a todos estos contenedores OSGi al mismo tiempo? ¿O son diferentes de que el host X tenga un contenedor OSGi con N paquetes y el contenedor OSGi en el host Y tenga un conjunto diferente de paquetes? – Progman

+0

Este es un gran entorno OSGi distribuido: el servicio A en el host X puede usar el servicio B en el host Y. Cada contenedor puede tener un conjunto diferente de paquetes. ¡Gracias! –

+0

Intentaré construir dicho sistema usando Apache Karaf (porque proporciona una manera fácil de automatizar comandos y una administración fácil de paquetes). Lo configuraré con una tienda de paquetes compartida, de modo que cada vez que actualice un paquete, todos los tiempos de ejecución lo recogerán. Karaf está diseñado para admitir la ejecución de comandos a partir de scripts, por lo que no debería ser difícil escribir los scripts necesarios, que administrarán el sistema. Sin embargo, no obtendrá transacciones distribuidas. En algún punto del tiempo, habría versiones incompatibles y no creo que haya una solución para esto actualmente. –

Respuesta

2

En términos de la gestión de un gran número de bultos, mirar las características Karaf - en gran manera simplificar el manejo en gran medida suites de paquetes.

Para el lado distribuido de las cosas, eche un vistazo al subproyecto Karaf Cellar, está agrupando Karaf usando HazelCast (y se instala en Karaf a través del mecanismo de características).

7

Es posible que desee echar un vistazo a soluciones más "administradas" hechas para ambientes tipo nube: Apache ACE o su hermano mayor Amdatu.

Apache ACE convierte contenedores de OSGi individuales en contenedores gestionados cuyo estado se puede controlar desde un solo punto de administración. Amdatu es un marco más completo que incluye ACE para aprovisionamiento pero agrega funcionalidad horizontal.

+0

Tenga en cuenta que Apache ACE acaba de graduarse como un Proyecto Apache de nivel superior, por lo que el enlace (aún en el espacio de la incubadora) puede no ser válido durante mucho tiempo. –

+1

El enlace seguirá siendo válido y simplemente redirigirá a la nueva ubicación. –

2

Si es serio acerca de la empresa lista -lo que significa "robusto" - tiempos de ejecución OSGi distribuidos- entonces eche un vistazo a Paremus Service Fabric. Hemos estado haciendo esto desde 2005 :)

La arquitectura de aprovisionamiento/gestión de Service Fabric es extremadamente escalable (>> 1,000 de contenedores), receptiva y estable. Varios años de desarrollo y experiencia de tiempo de ejecución comercial que apuntalan este producto. La arquitectura Service Fabric admite múltiples aplicaciones concurrentes distribuidas basadas en OSGi. La arquitectura de Service Fabric está centrada en OBR; nuestro ingeniero principal fue responsable de las recientes actividades de especificación de OSGi Alliance OBR.

El plano posterior del mensaje Service Fabric aprovecha el protocolo de mensajería DDS, que es el socio natural de OSGi distribuido.El Paremus RSA (implementación de servicios remotos) es una implementación de sala limpia del estándar, que es altamente robusto, liviano y permite la capacidad de conexión dinámica de los proveedores de protocolo y distribución. El proveedor de descubrimiento predeterminado: es nuevamente DDS.

Finalmente, y la tela de servicio funciona de la caja.

+0

Los siguientes enlaces pueden ser de interés: http://www.slideshare.net/mfrancis/the-dawn-of-composite-clouds-why-osgi-is-the-most-important-ingredient-in-the-next -generation-of-java-compute-cloud-richard-nicholson & http://www.slideshare.net/mfrancis/cloud-osgi-the-dawn-of-composite-clouds & y una ligera presentación más abstracta http://www.slideshare.net/mfrancis/complexity-components-clouds-paremus – Richard

1

En Gyrex usamos p2 para distribuir paquetes a través de diferentes nodos de un clúster. Es posible controlar qué paquetes se aprovisionarán a qué nodo utilizando las etiquetas de nodo y las expresiones de filtro LDAP (común en OSGi). Por ejemplo, es posible instalar (y activar) paquetes web solo en nodos web.

El soporte para servicios distribuidos es not available out-of-the box. ECF necesita integrarse manualmente.

+0

a partir de abril de 2016 parece que el trabajo va solo en el servidor http://git.eclipse.org/c/gyrex/ –

+0

Todo el código se ha fusionado en un único repositorio de Git para un mantenimiento más fácil. – Gunnar

Cuestiones relacionadas