"экспериментальный" статус JGroups Master/Slave для поиска в спящем режиме и бесконечности
Мы используем hibernate-search для полнотекстовой индексации наших объектов в wildfly 8.2 (используя библиотеки hibernate/hibernate-search и infinspan, включенные в wildfly 8.2). Запуск в качестве автономного узла или в домене с выделенным мастером поиска в спящем режиме и org.hibernate.search.store.impl.FSDirectoryProvider это работало нормально в течение нескольких лет (и версий jboss).
Теперь мы хотели бы развернуть эту систему в кластерной среде высокой доступности, где wildfly 8.2 работает за прокси-сервером балансировки нагрузки. Мы хотим иметь динамически масштабируемый кластер без точки отказа в смысле мастера домена или мастера поиска в спящем режиме, и мы настроили для этого автономные узлы без домена. Для выбора мастера HS мы используем серверную часть jgroups, а для репликации данных поиска в спящем режиме мы используем провайдера infinispan с file-store сохранить данные между перезапусками.
Я запустил его в работу, довольно быстро и был очень взволнован, поскольку это выглядит как надежный и масштабируемый сценарий, но я несколько сомневаюсь, чтобы запустить эту конфигурацию в производство, так как бэкэнд jgroups был назван "экспериментальным" (и на некоторых форумах). "чрезвычайно экспериментальный"). Каков текущий статус бэкэнда? Люди в настоящее время используют это в производстве? Что мы можем сделать, чтобы минимизировать риск, используя эту конфигурацию?
Кроме того, есть ли у кого-то опыт использования infinispan вместе с hibernate-search в этом созвездии? Большинство настроек касаются replicated-cache были просто повторно использованы из существующих примеров, если у кого-нибудь есть какие-либо советы или рекомендации относительно этих настроек, например, будет ли он масштабироваться с индексами ~50 ГБ? Я был бы очень благодарен за любые отзывы или опыт работы с подобными сценариями.
Конфигурация была в основном собрана с использованием справочного материала отсюда:
- http://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/
- https://forum.hibernate.org/viewtopic.php?f=9&t=1035437
Подробные шаги, которые мы предприняли, приведены ниже.
- За основу мы взяли и расширили
standalone-ha-full.xml - настроить jgroups для использования стека TCP
- запустить TCPPING вместо MPing (мы планируем запустить его в облачном контексте, где multicast/udp вызывает проблемы - мы можем перейти к JDBCPing, чтобы сделать его более гибким в некоторый момент).
- мы запускаем со следующими Системными свойствами для каждого узла (конечно, имя / порт изменяется для каждого узла)
Свойства системы:
<system-properties>
<property name="jboss.node.name" value="node2" />
<property name="jboss.socket.binding.port-offset" value="889" />
<!-- Automatic master election via JGroups, requires Infinispan directory provider -->
<property name="hibernate.search.default.worker.backend" value="jgroups"/>
<!-- Enable cluster-replicated index, but the default configuration does not enable any
form of permanent persistence for the index, we do this with cache-container/file-store below -->
<property name="hibernate.search.default.directory_provider" value="infinispan" />
<property name="hibernate.search.infinispan.chunk_size" value="300000000" />
<property name="hibernate.search.reader.strategy" value="shared" />
<property name="hibernate.search.worker.execution" value="sync" />
<property name="hibernate.search.default.optimizer.operation_limit.max" value="10000"/>
<property name="hibernate.search.default.optimizer.transaction_limit.max" value="1000"/>
<!-- Use CacheManager defined in WildFly configuration file, e.g., standalone.xml -->
<property name="hibernate.search.infinispan.cachemanager_jndiname" value="java:jboss/infinispan/container/hibernate-search"/>
</system-properties>
Мы определили следующее <cache-container> для бесконечности:
<!-- BEGIN HIBERNATE INFINISPAN CACHE -->
<cache-container name="hibernate-search" jndi-name="java:jboss/infinispan/container/hibernate-search" start="EAGER">
<transport lock-timeout="330000"/>
<replicated-cache name="LuceneIndexesMetadata" start="EAGER" mode="SYNC" remote-timeout="330000">
<locking striping="false" acquire-timeout="330000" concurrency-level="500"/>
<transaction mode="NONE"/>
<eviction strategy="NONE" max-entries="-1"/>
<expiration max-idle="-1"/>
<state-transfer enabled="true" timeout="480000"/>
<file-store preload="true" purge="false" passivation="false" relative-to="jboss.home.dir" path="..\namespaces\mc\infinispan-file-store">
<write-behind/>
</file-store>
<indexing index="NONE"/>
</replicated-cache>
<replicated-cache name="LuceneIndexesData" start="EAGER" mode="SYNC" remote-timeout="25000">
<locking striping="false" acquire-timeout="330000" concurrency-level="500"/>
<transaction mode="NONE"/>
<eviction strategy="NONE" max-entries="-1"/>
<expiration max-idle="-1"/>
<state-transfer enabled="true" timeout="480000"/>
<file-store preload="true" purge="false" passivation="false" relative-to="jboss.home.dir" path="..\namespaces\mc\infinispan-file-store">
<write-behind/>
</file-store>
<indexing index="NONE"/>
</replicated-cache>
<replicated-cache name="LuceneIndexesLocking" start="EAGER" mode="SYNC" remote-timeout="25000">
<locking striping="false" acquire-timeout="330000" concurrency-level="500"/>
<transaction mode="NONE"/>
<eviction strategy="NONE" max-entries="-1"/>
<expiration max-idle="-1"/>
<state-transfer enabled="true" timeout="480000"/>
<indexing index="NONE"/>
</replicated-cache>
</cache-container>
<!-- END HIBERNATE INFINISPAN CACHE -->
Насколько я понимаю (и, похоже, на практике работает с моими тестами), Infispan будет сериализовать свои данные в сконфигурированные <file-store> и данные затем сохраняются между перезапусками узла. Даже некоторые катастрофические тесты (например, kill -9 <jboss-pid>) показали, что восстановление индекса происходит корректно, когда узел возвращается. Во время автономного периода другой узел становится ведущим, и кластер работает бесперебойно.