Tartalomjegyzék

Előkészületek

Ha több WildFly példányt szeretnénk használni, hogy minimalizáljuk a kieséseket, akkor célszerű domain módban  módban indítani az alkalmazásszervert, mert a standalone mód helyett ez ad lehetőségeket  mód mellett ez a mód lehetőségeket ad a könnyű adminisztrációra, illetve a beállítások és a telepítések megfelelő terítésére. A WildFly domain módja  módja esetén két (viszonylag) sovány igényű java folyamat  folyamat indul el a gépeken (a process controller és a host controllera Process Controller és a Host Controller), amelyeknek felügyelik az a tényleges alkalmazásszerver funkciókat, de erre kicsit később még visszatérünk.

A szükséges kialakítandó topológia az alábbi ábra szerint alakul majd (egy master és két slavekell egy master és két slave gép), mind a három kiszolgálóra kerül alkalmazásszerver példány, illetve httpd kiszolgáló  kiszolgáló is, amely a mod-cluster terheléselosztót  terheléselosztót fogja kezelni, így bármelyik kiszolgáló esik ki, a szolgáltatás nem fog szünetelni, csak esetleg lassulni, ha egyébként kellően terheltek voltak. Felmerülhet a kérdés, hogy mi történik a master kiesése esetén: a felhasználó szemszögéből semmi, a többi alkalmazásszerver példány dolgozik tovább, a terhelés elosztása automatikusan átszerveződik, csak a rendszergazdai szolgáltatások csökkennek, amíg helyre nem áll a master funkcionalitása (akár mentésből visszaállítva). Ez egyfajta SPOF a rendszerben, de vállalható a kockázat.

.. ábra ..

Telepítés

Hozzunk létre a szervereken egy 'wildfly' nevű felhasználót, majd töltsük le és tömörítsük ki a WildFly 8 alkalmazásszervert:

# adduser -g users -m wildfly
# su - wildfly
$ wget http://download.jboss.org/wildfly/8.0.0.Final/wildfly-8.0.0.Final.tar.gz
$ tar xzvf wildfly-8.0.0.Final.tar.gz
...
$

Próbaképp elindíthatjuk domain módban, hogy minden szükséges függőség rendelkezésre áll-e:

$ wildfly-8.0.0.Final/bin/domain.sh
...
[Server:server-two] 14:40:23,007 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874:
  WildFly 8.0.0.Final "WildFly" started in 30443ms - Started 207 of 255 services (86 services are lazy, passive or on-demand)

Állítsuk le létrehozott példányt és olvassunk egy kis dokumentációt a https://docs.jboss.org/author/display/WFLY8/ oldalról indulva. 

Hogy lesz ebből cluster?

A telepítés során volt három – egymástól függetlenül futó – példányunk, amelyek nem igazán tudtak egymás létezéséről. Ennek két oka volt:

• 127.0.0.1 (avagy localhost) címen futottak
• a legtöbb VPS vagy Cloud szolgáltatónál nincs UDP multicast a virtualizált gépek között

Mind a két "problémára" van megoldás, de ezek előtt alakítsuk ki a két slave és egy master topológiát, amelyhez kétféle módon kell indítanunk a WildFly szervereket:

$ bin/domain.sh --host-config=host-master.xml -Djboss.bind.address.management=10.129.214.116 -Djboss.bind.address=10.129.214.116

$ bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=10.129.214.116 -Djboss.bind.address.management=10.129.216.43 -Djboss.bind.address=10.129.216.43

Vegyük észre (a különböző IP címeken kívül) a két alapvető különbséget:

• a config-host paraméternél megadott XML állomány nevét,
• illetve a slave esetén a master IP címét definiáló jboss.domain.master.address paramétert.

Indításkor tapasztalni fogjuk, hogy a master példány elindul rendesen, a slave viszont hibát fog jelezni és el se indul:

...

. Az egyszerű áttekinthetőség miatt nem húztam vonalakat az Apache Httpd kiszolgálók és a WildFly JavaEE példányok közé, mert ott kilenc vonalat kellene húzni, ugyanis mindegyik kapcsolatban vagy mindegyikkel. 

Majdnem minden komponens legalább duplikálva van, kivéve a master: felmerülhet a kérdés, hogy mi történik a master kiesése esetén:

• a felhasználó szemszögéből semmi, a többi alkalmazásszerver példány dolgozik tovább, a terhelés elosztása automatikusan átszerveződik,
• a rendszergazdai eszköztár viszont jelentősen csökken, amíg helyre nem áll a master funkcionalitása (akár mentésből visszaállítva): ez egyfajta SPOF a rendszerben, de vállalható a kockázat.

A három Apache Httpd kiszolgáló tetejére érdemes tenni egy hálózati szintű terheléselosztót, amelyik csak az három Apache Httpd 80-as és 443-as portjait figyeli, és hiba esetén nem oszt oda kérést. Ez a terheléselosztó lehet egy megfelelő redundanciával ellátott hálózati elem, de lehet akár egy földrajzilag elosztott DNS szolgáltatás is, de lehetőség van arra is, hogy csak a master gépen lévő Apache Httpd kapja a kéréseket és a master kiesése esetén irányítjuk át a forgalmat másik kiszolgáló felé. A lényeg az, hogy előre készre vannak konfigurálva, nem kell időt vesztegetni ebben a rétegben való átkonfigurálással vagy programindítgatásokkal.

Telepítés

Hozzuk létre a szervereken egy 'wildfly' nevű felhasználót, majd töltsük le és tömörítsük ki a WildFly 8.1 alkalmazásszervert:

# adduser -g users -m wildfly
# su - wildfly
$ wget http://download.jboss.org/wildfly/8.2.0.Final/wildfly-8.2.0.Final.zip
$ unzip wildfly-8.2.0.Final.zip
...
$

Próbaképp elindíthatjuk domain módban, hogy minden szükséges függőség rendelkezésre áll-e. (Ha nem indul megfelelően, akkor pótoljuk a hiányosságokat):

$ wildfly-8.1.0.Final/bin/domain.sh
...
[Server:server-two] 11:50:37,496 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.1.0.Final "Kenny" started in 27020ms - Started 210 of 258 services (89 services are lazy, passive or on-demand)

Állítsuk le a létrehozott példányokat, főzzünk egy jó kávét, közben olvassunk egy kis dokumentációt a https://docs.jboss.org/author/display/WFLY8/ oldalról indulva... 

Hogy lesz ebből cluster?

A telepítés és a futtatási teszt során volt három – egymástól függetlenül futó – példányunk, amelyek nem igazán tudtak egymás létezéséről. Ennek két oka volt:

• 127.0.0.1 (avagy localhost) címen futottak
• a legtöbb VPS és/vagy Cloud szolgáltatónál nincs multicast a virtualizált gépek között, a WildFly példányok viszont multicast protokollon beszélnék meg a topológiát.

Mind a két "problémára" van megoldás, de ezek előtt alakítsuk ki a két slave és egy master topológiát, amelyhez kétféle módon kell indítanunk a WildFly szervereket:

$ bin/domain.sh --host-config=host-master.xml -Djboss.bind.address.management=10.129.214.116 -Djboss.bind.address=10.129.214.116

$ bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=10.129.214.116 -Djboss.bind.address.management=10.129.216.43 -Djboss.bind.address=10.129.216.43

Vegyük észre (a különböző privát IP címeken kívül) a két alapvető különbséget:

• a config-host paraméternél megadott XML állomány nevét,
• illetve a slave esetén a master IP címét definiáló jboss.domain.master.address paramétert.

Indításkor tapasztalni fogjuk, hogy a master példány elindul rendesen, a slave viszont hibát fog jelezni és el se indul:

[Host Controller] 03:52:36,530517 ERROR [org.jboss.asremoting.hostremote.controllerconnection] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS016519: Tried all domain controller discovery option(s) but unable to connectRemoting "gacivs-test01.javaforum.hu:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: the server presented no authentication mechanisms
[Host Controller] 03:52:36,583528 INFOWARN  [org.jboss.as.host.controller] (MSCController service thread 1-1Boot Thread) JBAS015950JBAS016535: WildFly 8.0.0.Final "WildFly" stopped in 35ms
[Host Controller] 
03:52:36,914 INFO  [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99
 Could not connect to master. No domain controller discovery options left. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure.
[Host Controller] 03:52:36,917530 INFOERROR  [org.jboss.as.processhost.controller] (Controller Boot Thread-8) JBAS012016JBAS010901: ShuttingCould down process controller
not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS016519: Tried all domain controller discovery option(s) but unable to connect
[Host Controller] 03:52:36,918583 INFO  [org.jboss.as.process] (Thread-8MSC service thread 1-1) JBAS012015JBAS015950: All processes finished; exiting

A "Could not connect to master" hiba oka teljesen logikus: a master nem engedi, hogy bármilyen jött-ment slave csatlakozhasson, a csatlakozáshoz a master oldalán létre kell hozni egy technikai felhasználót, a slave oldalán pedig meg kell adni a hozzá tartozó jelszót. A technikai felhasználó nevét több módon megadhatjuk:

• a host-slave.xml fájlban a host nevénél
• a host-slave.xml fájlban a domain-controller szekcióban a remote paramétereként
• ezek hiányában az adott szerver teljes neve lesz.

Célszerű az utolsó opciót választani, ez jár a legkevesebb munkával, ezért adjunk hozzá kettő új (gacivs-test01.javaforum.hu és gacivs-test02.javaforum.hu) a master "adatbázisához":

$ bin/add-user.sh 
What type of user do you wish to add? 
 a) Management User (mgmt-users.properties) 
 b) Application User (application-users.properties)
(a): a
Enter the details of the new user to add.
Using realm 'ManagementRealm' as discovered from the existing property files.
Username : gacivs-test01.javaforum.hu
Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
 - The password should not be one of the following restricted values {root, admin, administrator}
 - The password should contain at least 8 characters, 1 alphanumeric character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
 - The password should be different from the username
Password : 
Re-enter Password : 
What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[  ]: 
About to add user 'gacivs-test01.javaforum.hu' for realm 'ManagementRealm'
Is this correct yes/no? y
Added user 'gacivs-test01.javaforum.hu' to file '/home/wildfly/wildfly-8.0.0.Final/standalone/configuration/mgmt-users.properties'
Added user 'gacivs-test01.javaforum.hu' to file '/home/wildfly/wildfly-8.0.0.Final/domain/configuration/mgmt-users.properties'
Added user 'gacivs-test01.javaforum.hu' with groups  to file '/home/wildfly/wildfly-8.0.0.Final/standalone/configuration/mgmt-groups.properties'
Added user 'gacivs-test01.javaforum.hu' with groups  to file '/home/wildfly/wildfly-8.0.0.Final/domain/configuration/mgmt-groups.properties'
Is this new user going to be used for one AS process to connect to another AS process? 
e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
yes/no? y
To represent the user add the following to the server-identities definition <secret value="R2FDSVZTMzc5Iw==" />

...

WildFly 8.0.0.Final "WildFly" stopped in 35ms
[Host Controller] 
03:52:36,914 INFO  [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99
03:52:36,917 INFO  [org.jboss.as.process] (Thread-8) JBAS012016: Shutting down process controller
03:52:36,918 INFO  [org.jboss.as.process] (Thread-8) JBAS012015: All processes finished; exiting

A "Could not connect to master" hiba oka teljesen logikus: a master nem engedi, hogy bármilyen jött-ment slave csak úgy csatlakozhasson, a csatlakozáshoz a master oldalán létre kell hozni egy technikai felhasználót, a slave oldalán pedig meg kell adni a hozzá tartozó jelszót. A technikai felhasználó nevét több módon megadhatjuk:

• a host-slave.xml fájlban a host nevénél
• a host-slave.xml fájlban a domain-controller szekcióban a remote paramétereként
• ezek hiányában az adott szerver teljes neve lesz.

Célszerű az utolsó opciót választani, ez jár a legkevesebb munkával, ezért adjunk hozzá kettő új (gacivs-test01.javaforum.hu és gacivs-test02.javaforum.hu) a master "adatbázisához":

$ bin/add-user.sh 
What type of user do you wish to add? 
 a) Management User (mgmt-users.properties) 
 b) Application User (application-users.properties)
(a): a
Enter the details of the new user to add.
Using realm 'ManagementRealm' as discovered from the existing property files.
Username : gacivs-test01.javaforum.hu
Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
 - The password should not be one of the following restricted values {root, admin, administrator}
 - The password should contain at least 8 characters, 1 alphanumeric character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
 - The password should be different from the username
Password : 
Re-enter Password : 
What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[  ]: 
About to add user 'gacivs-test01.javaforum.hu' for realm 'ManagementRealm'
Is this correct yes/no? y
Added user 'gacivs-test01.javaforum.hu' to file '/home/wildfly/wildfly-8.0.0.Final/standalone/configuration/mgmt-users.properties'
Added user 'gacivs-test01.javaforum.hu' to file '/home/wildfly/wildfly-8.0.0.Final/domain/configuration/mgmt-users.properties'
Added user 'gacivs-test01.javaforum.hu' with groups  to file '/home/wildfly/wildfly-8.0.0.Final/standalone/configuration/mgmt-groups.properties'
Added user 'gacivs-test01.javaforum.hu' with groups  to file '/home/wildfly/wildfly-8.0.0.Final/domain/configuration/mgmt-groups.properties'
Is this new user going to be used for one AS process to connect to another AS process? 
e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
yes/no? y
To represent the user add the following to the server-identities definition <secret value="R2FDSVZTMzc5Iw==" />

A fentiek beállítása után a slave példányok már tudnak csatlakozni, ha a secret XML elemet kicseréljük az add-user.sh szkript által kiírt értékre a host-slave.xml állomány megfelelő helyén:

...

Ha leállítjuk a master példányt, akkor a két slave mindenképpen megpróbál majd visszatalálni, s ha IP címek helyett a továbbiakban DNS neveket adunk meg, akkor könnyedén át tudunk állni akár egy mentésből visszaállított más IP című master példányra, ha valami baj történne az eredetivel:

...

• CLI (Command Line Interface) felületen át (ez a preferált módszer, mert a későbbiekben könnyen reprodukálható egy környezet a CLI futtatással ledokumentált és frissen tartott CLI gyűtemény futtatásával)
• vagy Web felületről (amelynél jelentős kézimunka egy új környezet kialakítása). 

Mind a két módszerhez szükséges egy admin felhasználó, amelyet a master példánynál kell létrehoznunk a más ismert add-user.sh futtatásával:

...

CLI csatlakozás

A WildFly tartalmaz egy jboss-cli.sh állományt, amellyel csatlakozni tudunk bármelyik példányhoz, de leginkább a master az érdekes:

$ bin/jboss-cli.sh 
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect gacivs-test-master
[domain@gacivs-test-master:9990 /] /host=gacivs-test01.javaforum.hu/server=server-one/interface=public:read-attribute(name=resolved-address)
{
    "outcome" => "success",
    "result" => "10.129.216.43"
}

 Vegyük észre, hogy ha arról a gépről csatlakozunk, ahol a WildFly master is fut, akkor nem kér jelszót! Egyéb helyről kapcsolódva viszont kérni fogja a felhasználónevet és a jelszót.

Web felület

A WildFly az általunk megadott IP címen fog a 9990 porton indítani egy management- console alkalmazást, amely lehetővé teszi a webes felületen való adminisztrációt, itt láthatjuk a kialakított topológiát és a két szervert, amelyeket az alapértelmezett konfiguráció szerint elindít a WildFly:

Multicast helyett TCP!

Mint említettem volt, a legtöbb VPS és Cloud szolgáltató nem igazán engedi az UDP (multicast) kommunikációta multicast kommunikációt, még akkor se, amikor adnak egy 10.x.x.x tartományt, mint privát hálózatprivát IP tartományt egy második hálózati interfészen. A WildFly viszont alapból multicast csatornán áll össze egy csoportba, ezért rá kell beszélnünk, hogy ezt TCP csatornán művelje, illetve a betérő vagy kieső tagokat TCP csatornán tartsa nyilván. Ehhez az alábbi parancsot kell kiadnunk, hogy a "mindenügyi" JGroups TCP-n kapcsolódjon össze:

...

[Server:server-two] 07:18:21,671 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,shared=tcpping) ISPN000094: Received new cluster view: [gacivs-test01.javaforum.hu:server-two/web|1] (2) [gacivs-test01.javaforum.hu:server-two/web, gacivs-test02.javaforum.hu:server-two/web]

HTTP cluster

A felhasználói oldalról felhasználó oldaláról a HTTP kiszolgálás folyamatossága és folytonossága a szempont, így konfiguráljunk be egy Apache HTTPD Httpd szervert, ehhez a WildFly (és régebben ugye JBoss) mellé csomagolt kiadott mod_cluster modult tudjuk használni.

Elsőképp szerezzük meg a cluster-test alkalmazást a WildFly dokumentumok között említett helyről (git clone git://github.com/liweinan/cluster-demo.git), majd telepítsük:

[domain@localhost:9990 /] deploy cluster-demo.war --server-groups=other-server-group

UDP helyett TCP!

Mivel TCP alapokon fogunk kommunikálni az Apache alá telepített mod_cluster modullal, ezért CLI használatával kapcsoljuk ki a hirdetést és konfiguráljuk be a HTTP proxy példányok IP címét és port számát:

...

fordítsuk le, majd telepítsük a CLI használatával:

[domain@gacivs-test-master:9990 /] deploy cluster-demo.war --server-groups=other-server-group

Multicast helyett TCP!

Mivel TCP alapokon fogunk kommunikálni az Apache alá telepített mod_cluster modullal, ezért CLI használatával kapcsoljuk ki a multicast hirdetést és konfiguráljuk be a proxy példányok IP címét és port számát, majd kapcsoljuk ki a Sticky Session szolgáltatást is:

[domain@gacivs-test-master:9990 /] /profile=full-ha/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=advertise,value=false)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"other-server-group" => {"host" => {
        "gacivs-test01.javaforum.hu" => {"server-two" => {"response" => {
            "outcome" => "success",
            "result" => undefined,
            "response-headers" => {
                "operation-requires-restart" => true,
                "process-state" => "restart-required"
            }
        }}},
        "gacivs-test02.javaforum.hu" => {"server-two" => {"response" => {
            "outcome" => "success",
            "result" => undefined,
            "response-headers" => {
                "operation-requires-restart" => true,
                "process-state" => "restart-required"
            }
        }}}
    }}}
}

Láthatjuk, hogy a master végrehajtotta a slave példányokon a kért módosítást (ellenőrizni is tudjuk ezt a webes felületen), de kiírta, hogy szükséges lesz az alkalmazásszerver példányok újraindítása. Még mielőtt ezt megtennénk, állítsuk be a proxy címeket is:

[domain@gacivs-test-master:9990 /] /profile=full-ha/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=proxy-list,value="10.129.214.116:10001,10.129.216.43:10001,10.129.215.37:10001")
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"other-server-group" => {"host" => {
        "gacivs-test01.javaforum.hu" => {"server-two" => {"response" => {
            "outcome" => "success",
            "result" => undefined,
            "response-headers" => {
                "operation-requires-restart" => true,
                "process-state" => "restart-required"
            }
        }}},
        "gacivs-test02.javaforum.hu" => {"server-two" => {"response" => {
            "outcome" => "success",
            "result" => undefined,
            "response-headers" => {
                "operation-requires-restart" => true,
                "process-state" => "restart-required"
            }
        }}}
    }}}
}

...

...ezért most indítsuk újra, majd ellenőrizzük, hogy rendben elindultak-e a kiszolgálók:

[domain@gacivs-test-master:9990 /] /server-group=other-server-group:stop-servers
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}
[domain@gacivs-test-master:9990 /] /server-group=other-server-group:start-servers
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}
[domain@gacivs-test-master:9990 /] ls /host=gacivs-test01.javaforum.hu/server-config=server-two
interface                       path                            auto-start=true                 group=other-server-group        priority=undefined              socket-binding-port-offset=150  
jvm                             system-property                 cpu-affinity=undefined          name=server-two                 socket-binding-group=undefined  status=STARTED                  
[domain@gacivs-test-master:9990 /] ls /host=gacivs-test02.javaforum.hu/server-config=server-two
interface                       path                            auto-start=true                 group=other-server-group        priority=undefined              socket-binding-port-offset=150  
jvm                             system-property                 cpu-affinity=undefined          name=server-two                 socket-binding-group=undefined  status=STARTED

...ami után persze panaszkodni fognak az egyes példányok, hogy nem tudnak csatlakozni a megadott címre, mert ott még nincs Apache HTTPD Httpd szerver:

[Server:server-two] 05:01:58,840 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000043: Failed to send INFO to gacivs-test02/10.129.215.37:10001: java.net.ConnectException: Connection refused

Az Apache

...

Httpd és a mod_cluster beállítása

Telepítsünk egy httpd csomagot, töltsük le a legfrissebb mod_cluster kiadást a megfelelő Linux (jelen esetben 64 bites CentOS) rendszerhez:

# yum install httpd
...
# wget http://downloads.jboss.org/mod_cluster//1.2.6.Final/linux-x86_64/mod_cluster-1.2.6.Final-linux2-x64-so.tar.gz
...
# cd /etc/httpd/modules/
# tar xzvf /root/mod_cluster-1.2.6.Final-linux2-x64-so.tar.gz
...
#

Ezek után kicsit konfigurálnunk kell a /etc/httpd/conf/httpd.conf fájl szerkesztésével (figyelem: diff kimenet!):

192c192
< LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
---
> #LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
202a203,207
> LoadModule slotmem_module modules/mod_slotmem.so
> LoadModule manager_module modules/mod_manager.so
> LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
> LoadModule advertise_module modules/mod_advertise.so
> 
1009a1015,1040
> 
> Listen 0.0.0.0:10001
> MemManagerFile /var/cache/httpd
> 
> <VirtualHost 0.0.0.0:10001>
>   <Directory />
>     Order deny,allow
>     Deny from all
>     Allow from all
>   </Directory>
> 
>   <Location /mod_cluster-manager>
>    SetHandler mod_cluster-manager
>    Order deny,allow
>    Deny from all
>    Allow from all
>   </Location>
> 
>   KeepAliveTimeout 60
>   MaxKeepAliveRequests 0
> 
>   ManagerBalancerName other-server-group
>   AdvertiseFrequency 5 
>   ServerAdvertise off
>   EnableMCPMReceive
> </VirtualHost>

A httpd szolgáltatás elindítása után már láthatjuk bármelyik publikus IP címen a három közül a mod_cluster státusz és menedzsment felületét (figyelem! nincs korlátozva a mod_cluster-manager elérése, éles üzembe így nem való!):

Illetve

bármelyik IP címen az adott alkalmazástA mod_cluster ténykedése okán nem kell azzal törődnünk, hogy felsoroljuk a Context Path konfigurációt, az élő alkalmazásaink automatikusan megjelennek az Apache Httpd kiszolgáló publikus IP címein és mindig az az alkalmazásszerver kapja a kérést, amelyik ki tudja szolgálni és pillanatnyilag a legkevesebb kérést kapta: