Nodi JGroups su EC2 che non parlano anche se si vedono

Question

Sto provando a utilizzare Hibernate Search in modo che tutte le scritture sull'indice Lucene dai nodi jgroupsSlave vengano inviate al nodo jgroupsMaster e quindi l'indice Lucene viene condiviso nuovamente al schiavi con Infinispan. Tutto funziona localmente, ma mentre i nodi si scoprono a vicenda su EC2, non sembrano comunicare.

Entrambi si stanno scambiando messaggi "sei vivo".

# master output sample 
86522 [LockBreakingService,localCache,archlinux-37498] DEBUG org.infinispan.transaction.TransactionTable - About to cleanup completed transaction. Initial size is 0 
86523 [LockBreakingService,LuceneIndexesLocking,archlinux-37498] DEBUG org.infinispan.transaction.TransactionTable - About to cleanup completed transaction. Initial size is 0 
87449 [Timer-4,luceneCluster,archlinux-37498] DEBUG org.jgroups.protocols.FD - sending are-you-alive msg to archlinux-57950 (own address=archlinux-37498) 
87522 [LockBreakingService,localCache,archlinux-37498] DEBUG org.infinispan.transaction.TransactionTable - About to cleanup completed transaction. Initial size is 0 
87523 [LockBreakingService,LuceneIndexesLocking,archlinux-37498] DEBUG org.infinispan.transaction.TransactionTable - About to cleanup completed transaction. Initial size is 0 

# slave output sample 
85499 [LockBreakingService,localCache,archlinux-57950] DEBUG org.infinispan.transaction.TransactionTable - About to cleanup completed transaction. Initial size is 0 
85503 [LockBreakingService,LuceneIndexesLocking,archlinux-57950] DEBUG org.infinispan.transaction.TransactionTable - About to cleanup completed transaction. Initial size is 0 
86190 [Timer-3,luceneCluster,archlinux-57950] DEBUG org.jgroups.protocols.FD - sending are-you-alive msg to archlinux-37498 (own address=archlinux-57950) 
86499 [LockBreakingService,localCache,archlinux-57950] DEBUG org.infinispan.transaction.TransactionTable - About to cleanup completed transaction. Initial size is 0 
86503 [LockBreakingService,LuceneIndexesLocking,archlinux-57950] DEBUG org.infinispan.transaction.TransactionTable - About to cleanup completed transaction. Initial size is 0 

Gruppi di protezione

Ho due vasi, uno per il padrone, e uno per schiavo, che io sono in esecuzione sulle proprie istanze EC2. Posso eseguire il ping di ogni istanza, dall'altra, e sono entrambi nello stesso gruppo di sicurezza, che definisce le seguenti regole per la comunicazione tra le macchine nel mio gruppo.

tutte le porte per ICMP 0-65535 per TCP 0-65535 per UDP

Quindi non credo sia un problema di configurazione gruppo di protezione.

hibernate.properties

# there is also a corresponding jgroupsSlave 
hibernate.search.default.worker.backend=jgroupsMaster 
hibernate.search.default.directory_provider = infinispan 
hibernate.search.infinispan.configuration_resourcename=infinispan.xml 
hibernate.search.default.data_cachename=localCache 
hibernate.search.default.metadata_cachename=localCache 

infinispan.xml

<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:schemaLocation="urn:infinispan:config:5.1 http://www.infinispan.org/schemas/infinispan-config-5.1.xsd" 
      xmlns="urn:infinispan:config:5.1"> 
    <global> 
     <transport clusterName="luceneCluster" transportClass="org.infinispan.remoting.transport.jgroups.JGroupsTransport"> 
      <properties> 
       <property name="configurationFile" value="jgroups-ec2.xml" /> 
      </properties> 
     </transport> 
    </global> 

    <default> 
     <invocationBatching enabled="true" /> 
     <clustering mode="repl"> 

     </clustering> 
    </default> 

    <!-- this is just so that each machine doesn't have to store the index 
     in memory --> 
    <namedCache name="localCache"> 
     <loaders passivation="false" preload="true" shared="false"> 
      <loader class="org.infinispan.loaders.file.FileCacheStore" fetchPersistentState="true" ignoreModifications="false" purgeOnStartup="false"> 
       <properties> 
        <property name="location" value="/tmp/infinspan/master" /> 
        <!-- there is a corresponding /tmp/infinispan/slave in 
        the slave config --> 
       </properties> 
      </loader> 
     </loaders> 
    </namedCache> 
</infinispan> 

JGroups-ec2.xml

<config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.2.xsd"> 
    <TCP 
      bind_addr="${jgroups.tcp.address:127.0.0.1}" 
      bind_port="${jgroups.tcp.port:7800}" 
      loopback="true" 
      port_range="30" 
      recv_buf_size="20000000" 
      send_buf_size="640000" 
      max_bundle_size="64000" 
      max_bundle_timeout="30" 
      enable_bundling="true" 
      use_send_queues="true" 
      sock_conn_timeout="300" 
      enable_diagnostics="false" 

      bundler_type="old" 

      thread_pool.enabled="true" 
      thread_pool.min_threads="2" 
      thread_pool.max_threads="30" 
      thread_pool.keep_alive_time="60000" 
      thread_pool.queue_enabled="false" 
      thread_pool.queue_max_size="100" 
      thread_pool.rejection_policy="Discard" 

      oob_thread_pool.enabled="true" 
      oob_thread_pool.min_threads="2" 
      oob_thread_pool.max_threads="30" 
      oob_thread_pool.keep_alive_time="60000" 
      oob_thread_pool.queue_enabled="false" 
      oob_thread_pool.queue_max_size="100" 
      oob_thread_pool.rejection_policy="Discard" 
      /> 
    <S3_PING secret_access_key="removed_for_stackoverflow" access_key="removed_for_stackoverflow" location="jgroups_ping" /> 

    <MERGE2 max_interval="30000" 
      min_interval="10000"/> 
    <FD_SOCK/> 
    <FD timeout="3000" max_tries="3"/> 
    <VERIFY_SUSPECT timeout="1500"/> 
    <pbcast.NAKACK2 
      use_mcast_xmit="false" 
      xmit_interval="1000" 
      xmit_table_num_rows="100" 
      xmit_table_msgs_per_row="10000" 
      xmit_table_max_compaction_time="10000" 
      max_msg_batch_size="100" 
      become_server_queue_size="0"/> 
    <UNICAST2 
      max_bytes="20M" 
      xmit_table_num_rows="20" 
      xmit_table_msgs_per_row="10000" 
      xmit_table_max_compaction_time="10000" 
      max_msg_batch_size="100"/> 
    <RSVP /> 
    <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" 
        max_bytes="400000"/> 
    <pbcast.GMS print_local_addr="false" join_timeout="7000" view_bundling="true"/> 
    <UFC max_credits="2000000" min_threshold="0.10"/> 
    <MFC max_credits="2000000" min_threshold="0.10"/> 
    <FRAG2 frag_size="60000"/> 
</config> 

L'ho copiato direttamente dalla più recente distribuzione infinispan-core (5.2.0.Beta3, ma ho anche provato il 5.1.4 che penso fosse). L'unica cosa che ho cambiato è stata la loro s3_ping rimpiazzata con la mia, ma di nuovo vedo i nodi scrivere su s3, e si trovano l'un l'altro quindi non penso che sia questo il problema. Sto anche iniziando master/slave con i loro vars di ambiente per jgroups.tcp.address impostato sul loro indirizzo IP privato. Ho anche provato alcune configurazioni che sono state notevolmente semplificate senza alcun successo.

Qualche idea su quale potrebbe essere il problema? Ho passato qualche giorno a giocarci, e mi sta facendo impazzire. Penso che debba essere qualcosa con la configurazione di jgroups poiché funziona localmente e non è in grado di parlare su EC2.

Qualsiasi altra informazione voi ragazzi volete aiutare a capirlo?

Answer 1

Sono in esecuzione due canali JGroup, quindi due configurazioni di JGroup da specificare: una per Infinispan e una per la comunicazione di backend worker.

Sia Infinispan e la jgroupsMaster stanno per usare le loro impostazioni di configurazione di default se non si specifica uno, ma i valori di default utilizzano multicast che non funziona su EC2.

Sembra che si disponga di una configurazione di configurazione corretta per l'indice Infinispan, ma è necessario riconfigurare l'operatore jgroupsMaster per utilizzare anche S3_PING o JDBC_PING; probabilmente sta funzionando per te in quanto la configurazione predefinita è in grado di individuare automaticamente i peer utilizzando il multicast.

Questa duplicazione verrà risolta da HSEARCH-882, non vedo l'ora di semplificare notevolmente la configurazione.