Мы используем 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 (мы планируем запустить его в облачном контексте, где многоадресная рассылка/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> для infinispan:
<!-- 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 -->
Насколько я понимаю (и, похоже, это работает на практике с моими тестами), infinispan сериализует свои данные в настроенный <file-store>, а затем данные сохраняются между перезапусками узла. Даже некоторые катастрофические тесты (например, kill -9 <jboss-pid>) показали чистое восстановление индекса, когда узел возвращается. В течение автономного периода другой узел становится ведущим, и кластер работает бесперебойно.
