Проблемы с подключаемым модулем Openfire Cluster Hazelcast

Windows Server 2003R2 / 2008R2 / 2012, Openfire 3.8.1, Hazelcast 1.0.4, MySQL 5.5.30 -ndb-7.2.12-кластер-gpl-журнал

Мы настроили 5 серверов в Openfire Cluster. Каждая из них находится в разных подсетях, подсети расположены в разных городах и связаны друг с другом через маршрутизаторы VPN (2-8 Мбит / с):

192.168.0.1 - node0
192.168.1.1 - node1
192.168.2.1 - node2
192.168.3.1 - node3
192.168.4.1 - node4

Openfire настроен на использование базы данных MySQL, которая успешно реплицируется с главного узла0 на все подчиненные узлы (каждый узел использует это собственный локальный сервер базы данных, работающий как подчиненный).

В Openfire Web Admin> Server Manager> Clustering мы можем просмотреть все узлы кластера.

Пользовательские настройки Openfire для Hazelcast:

hazelcast.max.execution.seconds - 30
hazelcast.startup.delay.seconds - 3
hazelcast.startup.retry.count - 3
hazelcast.startup.retry.seconds - 10

Конфигурация Hazelcast для node0 (аналогична другим узлам, за исключением раздела интерфейса) (% PROGRAMFILES% \ Openfire \ plugins \ hazelcast \ classes \ hazelcast-cache-config.xml):

<join>
  <multicast enabled="false" /> 
  <tcp-ip enabled="true">
    <hostname>192.168.0.1:5701</hostname> 
    <hostname>192.168.1.1:5701</hostname> 
    <hostname>192.168.2.1:5701</hostname> 
    <hostname>192.168.3.1:5701</hostname> 
    <hostname>192.168.4.1:5701</hostname>
  </tcp-ip>
  <aws enabled="false" /> 
</join>
<interfaces enabled="true">
  <interface>192.168.0.1</interface> 
</interfaces>

Это единственные настройки, отличные от настроек по умолчанию.

Проблема в том, что клиенты XMPP авторизуются слишком долго, примерно 3-4 минуты, после авторизации другие пользователи в реестре неактивны в течение 5-7 минут, за это время авторизовались. Пользователь в Openfire Web Admin> Сеансы отмечен как Не в сети. Даже после того, как пользователь видит, что другие пользователи вошли в систему как активные, сообщения не доставляются или доставляются через 5-10 минут или после нескольких перезапусков Openfire ...

Мы ценим любую помощь. Мы потратили около 5 дней, пытаясь настроить этого монстра, и у нас нет никаких идей ... :(

Заранее большое спасибо!

UPD 1: установлен Openfire 3.8.2 alpha с Hazelcast 2.5.1 Build 20130427 с той же проблемой.

UPD 2: Попытка запустить кластер на двух серверах, находящихся в одном городе, разделенных, вероятно, 1-2 переходами при пинге 1-5 мс. Все работает отлично! Затем мы остановили один из этих серверов и запустили один в другом городе (3-4 прыжка при 80-100 мс пинг) проблема снова возникла ... Медленная авторизация, отключенные пользователи в реестре, сообщения не доставляются вовремя и т. Д.

UPD 3: установлен Openfire 3.8.2 без JRE и Java SDK 1.70_25.

Вот скриншоты JMX:

узел 0: node0

узел 1: node1

Красная линия - первое клиентское соединение (после перезапуска Openfire). Проверено на двух пользователях. То же самое ... Первый пользователь (node0) подключился мгновенно, второй пользователь (node1) потратил 5 секунд на подключение. Ростеры показывали офлайн-пользователей с обеих сторон по 20-30 секунд, затем в них начали появляться онлайн-пользователи. Первый пользователь отправляет сообщение второму пользователю. Второй пользователь ждет 20 секунд, затем получает первое сообщение. Ответ и все другие сообщения передаются мгновенно.

UPD 4:

Во время раскопок на вкладке «Потоки» JConsole мы обнаружили следующие состояния:

Например, hz.openfire.cached.thread-3:

WAITING on java.util.concurrent.SynchronousQueue$TransferStack@8a5325
Total blocked: 0  Total waited: 449

Может, это поможет ... Мы вообще не знаем, где искать.

Спасибо!


person Community    schedule 21.05.2013    source источник


Ответы (1)


[ОБНОВЛЕНИЕ] Примечание к документации Hazelcast - поддерживается репликация WAN только в их корпоративной версии, а не в версии для сообщества, поставляемой с Openfire. Вы должны получить корпоративный лицензионный ключ от Hazelcast, если хотите использовать эту функцию.

Вы можете настроить несколько кластеров Openfire на базе локальной сети, а затем объединить их с помощью интеграции S2S в отдельные домены XMPP. Это предпочтительный подход для расширения Openfire для очень большой пользовательской базы.

[Исходное сообщение следует]

Я предполагаю, что более длительная сетевая задержка в конфигурации вашего удаленного кластера может связывать потоки исполнителя Hazelcast (для запросов и событий). Некоторые из этих событий и запросов вызываются синхронно в кластере Openfire. Попробуйте настроить следующие свойства:

hazelcast.executor.query.thread.count (default: 8)
hazelcast.executor.event.thread.count (default: 16)

Я бы начал с установки этих значений на 40/80 (5x) соответственно, чтобы увидеть, есть ли какое-либо улучшение в общей отзывчивости приложения и, возможно, даже выше, в зависимости от ожидаемой нагрузки. Дополнительные настройки Hazelcast (включая другие пулы потоков), а также инструкции по добавлению этих свойств в конфигурационный XML можно найти здесь:

Свойства конфигурации Hazelcast

Надеюсь, что это поможет ... и удачи!

person Tom Evans    schedule 22.05.2013
comment
Просто попытался добавить эти строки в hazelcast-cache-config.xml на двух серверах в разных городах (сценарий описан в UPD 2). Файлы конфигурации: node0 и node4 - person ; 22.05.2013
comment
Имейте в виду, что вы захотите использовать одну и ту же конфигурацию для всех участников кластера. Задачи синхронного кластера (используемые Openfire) должны будут выполняться на всех членах, прежде чем исходный член сможет продолжить работу. - person Tom Evans; 22.05.2013
comment
Мы используем одну и ту же конфигурацию для всех участников, разница только в <interface>192.168.4.1</interface> строке. Не совсем понимал, что такое синхронные кластерные задачи, что вы имеете в виду? Какие действия мы должны предпринять, чтобы проверить эти задачи. Кстати, может, стоит предоставить логи? - person ; 23.05.2013
comment
Есть ли другие предложения? - person ; 27.05.2013
comment
Если вы загрузите последнюю версию (3.8.2), вы сможете воспользоваться преимуществами новых возможностей JMX для устранения неполадок. После установки новой сборки включите коннектор JMX через консоль администратора. Затем вы можете использовать инструмент JConsole, который поставляется с JDK, для подключения к Openfire (например, по адресу 192.168.0.1:1099). Обратите внимание, что по умолчанию вам нужно будет аутентифицировать соединение JConsole, используя учетные данные администратора Openfire. Оттуда вы можете отслеживать использование потоков и памяти, а также другие внутренние компоненты JVM, чтобы лучше понять, что происходит. - person Tom Evans; 29.05.2013
comment
Пожалуйста, взгляните на рассматриваемый UPD3. - person ; 22.07.2013
comment
Вместо того, чтобы настраивать один кластер, охватывающий несколько удаленных серверов, лучшим подходом может быть создание отдельных доменов Openfire, по одному в каждом месте. Каждый домен может состоять из небольшого кластера (2 или 3 члена) и может удаленно маршрутизировать пакеты через домены с помощью коннектора S2S. Затем вы можете предоставить своих пользователей в этих нескольких доменах. Это позволит создать хорошо масштабируемую модель федерации, которая по-прежнему должна работать достаточно хорошо. - person Tom Evans; 30.07.2013
comment
да. У нас была эта модель, проблема заключалась в совместном использовании реестра, и пользователи из другого реестра отображались как krylov @ inetserver вместо Ивана Крылова. - person ; 31.07.2013