Wildfly 9 - mod_cluster su TCP

Question

Attualmente stiamo testando il passaggio da Wildfly 8.2.0 a Wildfly 9.0.0.CR1 (o CR2 creato da snapshot). Il sistema è un cluster che utilizza mod_cluster ed è in esecuzione su VPS, cosa che di fatto impedisce di utilizzare il multicast.

Su 8.2.0 Abbiamo utilizzato la seguente configurazione del modcluster che funziona bene:

 <mod-cluster-config proxy-list="1.2.3.4:10001,1.2.3.5:10001" advertise="false" connector="ajp"> 
      <dynamic-load-provider> 
       <load-metric type="cpu"/> 
      </dynamic-load-provider> 
     </mod-cluster-config> 

Purtroppo, il 9.0.0 proxy-list è stato deprecato e l'inizio del server si concluderà con una errore. C'è una terribile mancanza di documentazione, tuttavia dopo un paio di tentativi ho scoperto che l'elenco di proxy è stato sostituito con proxy che sono un elenco di binding in uscita. Quindi, la configurazione è simile alla seguente:

 <mod-cluster-config proxies="mc-prox1 mc-prox2" advertise="false" connector="ajp"> 
      <dynamic-load-provider> 
       <load-metric type="cpu"/> 
      </dynamic-load-provider> 
     </mod-cluster-config> 

e la seguente deve essere aggiunto nella appropriata presa-binding-gruppo (full-ha nel mio caso):

<outbound-socket-binding name="mc-prox1"> 
     <remote-destination host="1.2.3.4" port="10001"/> 
    </outbound-socket-binding> 
    <outbound-socket-binding name="mc-prox2"> 
     <remote-destination host="1.2.3.5" port="10001"/> 
    </outbound-socket-binding> 

Fin qui tutto bene . Dopo questo, il cluster httpd inizia a registrare i nodi. Tuttavia sto ricevendo errori dal servizio di bilanciamento del carico. Quando guardo nei/mod_cluster-manager, vedo un paio di nodo rimosso linee e ci sono anche molti molti errori come:

ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending STATUS command to node1/1.2.3.4:10001, configuration will be reset: MEM: Can't read node 

Nel registro di mod_cluster ci sono gli avvertimenti equivalenti:

manager_handler STATUS error: MEM: Can't read node

Per quanto ho capito, il problema è che sebbene wildfly/modcluster sia in grado di connettersi a httpd/mod_cluster, non funziona nell'altro modo. Sfortunatamente, anche dopo un lungo sforzo, sono bloccato.

Qualcuno potrebbe aiutare con l'impostazione mod_cluster per Wildfly 9.0.0 senza pubblicità? Molte grazie.

Answer 1

Dopo un paio di settimane sono tornato al problema e ho trovato la soluzione. Il problema era - ovviamente - nella configurazione e non aveva nulla in comune con la versione specifica di Wildfly. In modo specifico:

Nel dominio c'erano tre nodi e tre server in ciascun nodo. Tutti i nodi sono stati avviati con la seguente proprietà:

-Djboss.node.name=nodeX 

... dove nodeX è il nome di un nodo particolare. Tuttavia, ciò significa che tutti e tre i server nel nodo ottengono lo stesso nome, che è esattamente ciò che ha confuso il load balancer. Non appena ho rimosso questa proprietà, tutto ha iniziato a funzionare.

Answer 2

Non è necessario alcuno sforzo o disagio non necessario sulla configurazione proxy statica. Ogni distribuzione WildFly viene fornita con fogli xsd che descrivono la configurazione del sottosistema xml. Ad esempio, con wildfly 9x, è:

WILDFLY_DIRECTORY/docs/schema/jboss-as-mod-cluster_2_0.xsd 

Dice:

<xs:attribute name="proxies" use="optional"> 
    <xs:annotation> 
    <xs:documentation>List of proxies for mod_cluster to register with defined by outbound-socket-binding in socket-binding-group.</xs:documentation> 
    </xs:annotation> 
    <xs:simpleType> 
    <xs:list itemType="xs:string"/> 
    </xs:simpleType> 
</xs:attribute> 

La configurazione che segue funziona su scatola

1. Scarica wildfly-9.0.0.CR1.zip o costruire con ./build.sh from sources
2. Supponiamo hai 2 scatole, Apache HTTP Server con mod_cluster che funge da proxy di bilanciamento del carico e il tuo server WildFly che agisce da lavoratore. Assicurarsi che i server botch possano accedere l'uno all'altro sia sull'indirizzo e sulla porta di VirtualHost abilitati MCMP (lato Apache HTTP Server) che su lato WildJly AJP e HTTP. L'errore comune è quello di effettuare il bind di WildFLy su localhost; riporta quindi il suo addess come localhost al Server HTTP Apache che risiede su una casella dofferent, il che rende impossibile per lui contattare il server WildFly. La comunicazione è bidirezionale.
3. Questa è la mia differenza rispetto al valore predefinito wildfly-9.0.0.CR1.zip.

328c328
< <mod-cluster-config advertise-socket="modcluster" connector="ajp" advertise="false" proxies="my-proxy-one">
---
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
384c384
< <subsystem xmlns="urn:jboss:domain:undertow:2.0" instance-id="worker-1">
---
> <subsystem xmlns="urn:jboss:domain:undertow:2.0">
435c435
< <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:102}">
---
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
452,454d451
< <outbound-socket-binding name="my-proxy-one">
< <remote-destination host="10.10.2.4" port="6666"/>
< </outbound-socket-binding>
456c453
< </server>
---
> </server>

Modifiche spiegazione

• proxies="my-proxy-one", presa in uscita nome vincolante; potrebbe essere più di loro qui.
• instance-id="worker-1", il nome del lavoratore, a.k.a. JVMRoute.
offset
• - si potrebbe ignorare, è solo per la mia configurazione di prova. Offset non si applica ai binding di socket in uscita.
• <outbound-socket-binding name="my-proxy-one"> - IP e porta dello VirtualHost in Apache HTTP Server contenente la direttiva EnableMCPMReceive.

Conclusione

Generalmente, questi MEM lettura/nodo messaggi di errore sono riportate problemi di rete, ad esempio WildFly può contattare Apache, ma Apache non può contattare WildFly. Ultimo ma non meno importante, potrebbe accadere che la configurazione del Server HTTP Apache utilizzi la direttiva PersistSlots e che si siano verificati alcuni sostanziali cambiamenti di ambiente, ad es. passare da mpm_prefork a mpm_worker. In questo caso, i messaggi di errore MEM Read non vengono realizzati su WildFly, ma sui file slotmem memorizzati nella cache in HTTPD/cache/mod_custer che devono essere eliminati. Sono certo che sia la rete nel tuo caso però.

Answer 3

Mi sono imbattuto nel problema Rimosso nodo su. sono riuscito a risolverlo utilizzando il seguente come instance-id

<subsystem xmlns="urn:jboss:domain:undertow:2.0" instance-id="${jboss.server.name}"> 

Spero che questo vi aiuterà qualcun altro a;)