Распределенная OSGi - как правильно управлять пакетами во всех контейнерах?

Question

Мы рассматриваем возможность использования распределенной OSGi в нашей корпоративной среде.У нас будет следующая настройка:

• От 10 до 100 Контейнеры OSGi на многих хостах предлагают различные услуги.
• Многие из этих услуг предоставляются более чем одним контейнером.
• Для некоторых из этих служб может потребоваться согласованность во всех контейнерах (развернутая версия).

Как правильно управлять жизненным циклом комплектов (установка, запуск, обновление, остановка, удаление, удаление)все контейнеры?

Несколько требований:

• Поскольку может быть так много контейнеров, все они должны обрабатываться вместе;т.е. когда я собираюсь обновить пакет, одна команда должна обновить все контейнеры, в которых этот пакет уже присутствует.
• Команды должны быть повторяемыми: сначала выполнить команду в тестовых системах, а затем повторить ту же самую команду наПроизводственная система после завершения тестирования.

Я ценю любые предложения по вышеуказанному вопросу.

С уважением, Мартон

Answer 1

Возможно, вы захотите взглянуть на более «управляемые» решения, созданные для облачных сред: Apache ACE или его старший брат Amdatu .

Apache ACE превращает отдельные контейнеры OSGi в управляемые контейнеры, состояние которых можно контролировать из одной точки администрирования. Amdatu - это более полная структура, которая включает в себя ACE для предоставления, но добавляет горизонтальную функциональность.

Answer 2

С точки зрения управления большим количеством пакетов, обратите внимание на функции Karaf - они значительно упрощают обработку в значительной степени пакетов.

Что касается распределенной стороны, взгляните на подпроект Karaf Cellar , он кластеризирует Karaf с помощью HazelCast (и он устанавливается в Karaf с помощью механизма функций).

Answer 3

Если вы серьезно относитесь к корпоративной готовности - имеется в виду «надежные» - распределенные среды выполнения OSGi - взгляните на Paremus Service Fabric. Мы занимаемся этим с 2005 года:)

Архитектура обеспечения / управления Service Fabric чрезвычайно масштабируема (>> 1000 контейнеров), отзывчива и стабильна! Несколько лет разработки и коммерческого опыта поддержки этого продукта. Архитектура Service Fabric поддерживает несколько параллельных распределенных приложений на основе OSGi. Архитектура Service Fabric ориентирована на OBR; наш ведущий инженер отвечал за последние спецификации OSGi Alliance OBR.

Объединительная панель сообщений Service Fabric использует протокол обмена сообщениями DDS - IMO является естественным партнером для распределенной OSGi. Paremus RSA (реализация удаленного сервиса) - это реализация стандарта для чистых помещений, которая отличается высокой надежностью, легким весом и позволяет динамически подключаться поставщикам протоколов и распространения. Поставщик обнаружения по умолчанию - снова DDS.

Наконец - и Service Fabric работает из коробки.

Answer 4

В Gyrex мы используем p2 для распределения пакетов по различным узлам кластера.С помощью тегов узла и выражений фильтра LDAP (обычно в OSGi) можно контролировать, какие пакеты должны быть предоставлены для какого узла.Например, можно устанавливать (и активировать) веб-пакеты только на веб-узлах.

Поддержка распределенных служб недоступна "из коробки" .ECF необходимо интегрировать вручную.