Инициализация клиента сеанса Hazelcast, когда сервер находится в автономном режиме

Question

Мы пытаемся реплицировать поведение WebSphere Traditional (5/6/7/8/9) о сохранении сеансов для сервлетов и http, но с помощью Hazelcast и Tomcat.Позвольте мне объяснить ... WebSphere, даже если он настроен как клиент для домена репликации, ведет локальный регистр данных сеанса.И этот локальный регистр работает нормально, даже если процессы сервера, которые должны хранить реплицированные данные, отключаются с самого первого момента.То есть вы запускаете клиент, и сессия сеанса работает в контейнере сервлета.Очевидно, что вы не можете ожидать восстановления сеанса в другом контейнере сервлета, если произойдет сбой первого, но ваши приложения все равно будут работать.

С другой стороны, клиент Hazelcast в контейнерах Tomcat ожидает сервер Hazelcast (хотя бы один участниккластера), чтобы быть запущенным для инициализацииЕсли элемент кластера недоступен, инициализация завершается неудачно, и ... веб-приложения в контейнере сервлетов Tomcat запускаются неправильно.Они не ответят ни на один запрос.

Кроме того, после сбоя инициализации единственным способом восстановления является отключение и повторный запуск веб-контейнеров Tomcat (когда член кластера hazelcast подключен).

Такое поведение немного грубовато для системных администраторов: никто не может гарантировать, что служба резервного копирования в виде постоянства распределенных сеансов постоянно подключена.Это означает, что запуск клиента Tomcat становится рискованной задачей с единственной точкой отказа по конструкции, что нежелательно.

Теперь, может быть, я что-то упустил, может, я что-то не так понял.Итак, удалось ли кому-нибудь запустить клиент Hazelcast без серверов и как?Для нас разница является решающей: если мы не можем запустить веб-контейнер с отключенным сервером Hazelcast, мы должны продолжать работу с WebSphere.

Мы пробовали его на CentOS 7.5 на Virtual Box 5.2.22, а наша версия Tomcat - 8.5.Клиент и сервер Hazelcast - 3.11.1 / 2.

<group>
    <name>Integracion</name>
    <password></password>
</group>

<network>
  <cluster-members>
    <address>hazelcastsrv1/address>
    <address>hazelcastsrv2</address>
  </cluster-members>
</network>

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

Answer 1

Порядок включения / выключения питания не имеет значения в Hazelcast, если вы предоставляете оставшиеся узлы во время отключения питания, достаточно времени, чтобы завершить перераспределение.Например, в кластере из 4 узлов, если вы берете 1 узел и оставляете остальные 3 комнаты для завершения перераспределения, данные не теряются.Если вы удалите 2 узла вместе, то в кластере не будет данных, резервная копия которых была сохранена на 1 из 2 узлов, которые вы вынули.

Для запуска последовательность запуска не имеет значения, поскольку каждый узел владеет определенным набором разделов, которые определяются на основе согласованного хеширования.И это владение продолжает меняться, даже если есть узлы, покидающие / присоединяющиеся к работающему кластеру.

Answer 2

Hazelcast не "a single point of failure by design".Конструкция состоит в том, чтобы избежать единой точки отказа.По умолчанию данные отражаются между узлами.

Это сетка данных, вы запускаете столько узлов, сколько требуется для емкости и устойчивости, и они объединяются в кластеры.

Если вам нужно 3 узла для работыдля успешных операций, а также ожидайте, что 1 может выйти из строя, тогда вам нужно запустить 4 всего.Если произойдет этот 1 сбой, у вас будет достаточно большой кластер.