| Createlydiagram | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Tartalomjegyzék
| Table of Contents |
|---|
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 a Process Controller és a é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 lassulni -- feltéve, ha egyébként is kellően terheltek voltak.
Felmerülhet a kérdés, hogy mi történik a master kiesése esetén:
...
esetleg lassulni. 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.
| Createlydiagram | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
| Info |
|---|
Az ábrán szerepel egy Cassandra cluster is, amely a Cassandra kezdő lépések cikkben leírtak szerint telepítendő és használni is fogjuk a későbbiekben, mint lineárisan skálázható adatbázist. A cél ugyanis az, hogy egy olyan JavaEE környezetet alakítsunk ki, amelyikben a slave példányok száma (tervezett módon) tetszőlegesen változtatható a terhelés függvényében, illetve a kialakított architektúra biztosítja a (akár a hardver vagy az egész adatközpont) meghibásodásából következő kiesések automatikus minimalizálását. |
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:
| Code Block |
|---|
# adduser -g users -m wildfly # su - wildfly $ wget http://download.jboss.org/wildfly/8.02.0.Final/wildfly-8.02.0.Final.tar.gzzip $ tar xzvfunzip wildfly-8.02.0.Final.tar.gzzip ... $ |
Próbaképp elindíthatjuk domain módban, hogy minden szükséges függőség rendelkezésre áll-eáll-e. (Ha nem indul megfelelően, akkor pótoljuk a hiányosságokat):
| Code Block |
|---|
$ wildfly-8.01.0.Final/bin/domain.sh ... [Server:server-two] 1411:4050:2337,007496 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.01.0.Final "WildFlyKenny" started in 30443ms27020ms - Started 207210 of 255258 services (8689 services are lazy, passive or on-demand) |
...
Vegyük észre (a különböző privát IP címeken kívül) a két alapvető különbséget:
...
| Info |
|---|
Ha ugyanazt a jelszót használjuk a slave példányokhoz tartozó technikai felhasználóknál, akkor könnyedén tudjuk klónozni a slave példányt, így a változó terhelés függvényében könnyen tudunk új tagot hozzátenni a meglévő kiszolgálókhoz és minimális lesz a hibázási lehetőség! Érdemes úgy kialakítani a kiszolgálóinkat, hogy a terhelés növekedésére ne vertikálisan (kevés számú erősebb gép), hanem horizontálisan (sok gyengébb gép) legyen skálázható, ez sokkal célravezetőbb Cloud környezetben, ahol az egyes futó példányokért akár perc alapokon fizetünk, sokkal könnyebb egy meglévő példányt klónozni és elindítani, majd leállítani és törölni, mint a memória, CPU és tárhely hármast hozzáigazítani a terhelési profilhoz. |
Ezek 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:
...
- 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 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).
...
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:
...
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:
| Code Block |
|---|
|
.
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:
...
A felhasználó oldaláról a HTTP kiszolgálás folyamatossága és folytonossága a szempont, így konfiguráljunk be egy Apache Httpd szervert, ehhez a WildFly (régebben ugye JBoss) mellé kiadott mod_cluster modult tudjuk használni.
...
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:
| Code Block |
|---|
[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"
}
}}}
}}}
} |
...
Telepítsünk egy httpd csomagot, töltsük le a legfrissebb mod_cluster kiadást a megfelelő (jelen esetben 64 bites CentOS) rendszerhez:
| Code Block |
|---|
# 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 ... # |
...