«Экспериментальный» статус JGroups Master / Slave для поиска в спящем режиме и бесконечности

Мы используем hibernate-search для полнотекстовой индексации наших объектов в wildfly 8.2 (используя библиотеки hibernate / hibernate-search и infinspan, включенные в wildfly 8.2). Запуск в качестве автономного узла или в домене с выделенным мастером поиска Hibernate и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>) показали, что восстановление индекса происходит корректно, когда узел возвращается. Во время автономного периода другой узел становится ведущим, и кластер работает бесперебойно.