Az egyik a területen nem harcos, hogyan hozzunk létre egy átállási klasztert

előző ◈ a következő

Az egyik nem harcos a téren: hogyan hozzunk létre egy átállási klasztert

Gyakran előfordul, hogy az ambiciózus internetes projekt és sikeres PR-jének bevezetése után a cég nagy látogatókat vár. Sajnos, a világ nem tökéletes, és úgy történik, hogy a helyszínen nem tud megbirkózni a látogatók mozgására, az úgynevezett a „habraeffektom” körök, és kezd lassulni. Ennek megfelelően a vállalat mind pénzeket, mind hírnevet veszít. Ilyen esetekben a programozók általában hibáztatják az adminisztrátorokat, és a programozók adminisztrátorait. Kiderül egy ördögi kör.

A


Átállási fürt létrehozásához két n1 és n2 gépre van szükség az GlassFish szerverekhez (az egyikhez DAS és két GF szerver lesz); lb1 gép a terheléskiegyenlítéshez; DB1 gép db1. Győződjön meg arról, hogy minden gép "lát" egymást (ping).

Klaszterkonfiguráció


A klaszter konfigurációját elsősorban a parancssorból végezzük, a GlassFish asadmin szállítása útján

  1. Töltse le a GlassFish elosztást
    wget download.java.net/glassfish/3.1.1/release/glassfish-3.1.1.zip
    és csomagolja ki.
  2. Kezdeményezünk egy adminisztrátori domain (domain1) példányát:
    ./ asadmin start-domain domain1
    A GlassFish alapértelmezés szerint letiltja a távoli kapcsolatokat az adminisztrátori domainhez. És a klaszter összes csomópontja (Csomópont-ügynökök), azon a csomóponton kívül, amelyen a DAS áll, nem tud kapcsolódni vele.
    Egy tipikus hiba:
    Nem sikerült rendezni a DAS-t az n1: 4848-ban. Ellenőrizze, hogy működik-e a kiszolgáló, hogy a kiszolgáló megfelelően van-e konfigurálva, és hogy ez a kiszolgáló úgy van beállítva, hogy lehetővé tegye a távoli hozzáférést.
    Ennek érdekében:
    ./ asadmin enable-secure-admin
    és indítsa újra az adminisztratív tartományt.
    Hozzon létre fürtöt:
    ./ asadmin create-cluster c1.
    Készítsen két példányt az alkalmazáskiszolgálón, amely ugyanazon a fizikai gépen található:
    ./ asadmin create-local-instance-cluster c1 i1
    ./ asadmin create-local-instance-cluster c1 i2
  3. Indítsa el a fürtöt:
    ./ asadmin kezdő klaszter c1
  4. Új példányok hozzáadása a gépen n2 (a parancsok fizikailag végrehajtva n2-ben):
    . / asadmin -host n1 -port 4848 create-local-instance-cluster c1 i3
    ./ asadmin -host n1 -port 4848 create-local-instance-cluster c1 i4
  5. A konzol adminisztrátorában megtaláljuk az újonnan létrehozott példányt, megváltoztatjuk típusát SSH-ra, megváltoztatjuk a csomópont-gazdálkodó mező értékét n2-re. Ebben az esetben meg kell adnunk az SSH hozzáféréshez használt felhasználónevet és jelszót a gépen n2. Indítsa el a fürtöt. Látjuk, hogy minden másolat működik.
Terheléselosztás és HA


Valójában minden készen áll arra, hogy megszilárdítsa az alkalmazást a klaszterbe, de nekünk ez nem elég, mert A terheléskiegyenlítés és a HA nem biztosított.
Telepítenie és konfigurálni kell a terheléselosztót, hogy megkönnyítsük a felhasználók számára az alkalmazással való együttműködést:

  • Csak egy url szólt;
  • kéréseiket egyenletesen osztották el a klaszter-kiszolgálók összes példányán;
  • egyes példányok meghibásodása esetén a felhasználók normál üzemmódban továbbra is dolgozhattak az alkalmazással;
  • és nem is tudott a klaszter belső "konyhájáról".


Általában az GlassFish "tartalmaz" egy kiegyensúlyozó plug-inet a "népszerű" HTTP szerverek számára. A "tartalmaz" és a "népszerű" szavak nem hiábavalóak idézőjelben, tk. ez a plug-in nem szerepel a GF nyílt forráskódú verziójában, az Oracle iPlanet webszerver, az Oracle HTTP kiszolgáló, az Apache HTTP kiszolgáló, a Microsoft IIS támogatja. Mindannyian tudjuk, hogy az Apache egyszer jó volt, de most hatékonyabb megoldások vannak.
A jelöltek közül: NGINX, HAProxy, lighthttpd.
Támogatjuk a hazai gyártót és választjuk a NGINX-et. amely mindemellett egyre inkább elfoglalja a piacot.

  1. NGINX telepítése:
    #yum install nginx
    #nano /etc/nginx/nginx.conf
  2. Konfigurálása nginx a kiegyenlítő kérelmek kerek robbin 4 szerverek megegyező súlyú c támogatja a rögzített (a ragacsos) ülések (a következő része a config, és a szerver elindul).
    upstream backend ip_hash;
    szerver 192.168.0.1:28080 max_fails = 5 fail_timeout = 15s;
    kiszolgáló 192.168.0.1:28081 max_fails = 5 fail_timeout = 5s;
    kiszolgáló 192.168.0.2:28082 max_fails = 5 fail_timeout = 5s;
    szerver 192.168.0.2:28083 max_fails = 5 fail_timeout = 5s;
    >
    Meg kell jegyeznünk, hogy ez a legegyszerűbb konfiguráció, amely az ip_hash módszer használatával javítja az adott kiszolgáló felhasználói munkamenetét
  3. Annak érdekében, hogy a HA működjön, szükséges, hogy az n1 és n2 hostok közös szülő-tartományban legyenek. Például a cluster.com. Ehhez módosítani kell a / etc / hosts fájlokat mindkét gépen az alábbiak szerint:
    n1:
    127.0.0.1 localhost
    127.0.1.1 n1.cluster.com
    127.0.0.1 n1.cluster.com
    192.168.0.2 n2.cluster.com
    N2:
    127.0.0.1 localhost
    127.0.1.1 n2.cluster.com
    127.0.0.1 n2.cluster.com
    192.168.0.1 n1.cluster.com
  4. A fürt minden egyes fizikai gépén a multicast működésének ellenőrzéséhez hajtsa végre a következőket:
    ./ asadmin validate-multicast
  5. A DAS GlassFish adminisztrációs konzolban meg kell változtatnod az n2 említését a n2.cluster.com webhelyre
  6. Annak érdekében, hogy a GlassFish reprodukálja a Http-munkameneteket a fürt példányai között, szükséges, hogy az alkalmazás webes leírója tartalmazza a megfelelő utasítást (címke ), és az alkalmazás telepítésekor állítsa be az Avalaibility zászlót.
Az adatbázis telepítése és konfigurálása


Ebben a példában a PostgreSQL-t használjuk.
Telepítjük a DBMS-t, és létrehozunk egy új felhasználót és adatbázist.
# yum install postgresql-8.4
# service postgresql initdb
# service postgresql start
A PostgreSQL rendszerben csak helyi kapcsolatok engedélyezettek. Ennek kijavításához meg kell kijavítani konfigurációs fájl /var/lib/pgsql/data/pg_hba.conf, amelyben meg kell adnia hagyjuk alhálózatok: fogadó mind mind 192.168.0.0/24 md5

Nos, ez minden! Most végre kijavíthatjuk az alkalmazást (például a jforumot használjuk).

Számomra, hogy elmondjam az igazat, miután ezek a kiigazítások "az agy" szinte "felforrt". Jó "verejték" voltunk, hogy automatizáljuk a fent leírt eljárást Jelasticben, és néhány egérkattintássá alakítjuk.

Megpróbálhatja, hogy mi jött belőlük, a jelastic.com-on

Lássuk, hogy a kiszolgálók több erőforrást használnak a hibatűrő fürtkonfigurációban (a munkamenet-replikációval) a Jelasticben jelenleg elérhető szerverek példáihoz.


Kezdjük GlassFish-szel. Ez a szerver számos előnnyel rendelkezik: teljes körű támogatás az ipari klaszterezéshez, számos funkciók, sok modul, nagy megbízhatóság, adminisztrációs panel stb. Ha megnézzük a következő táblázatot, úgy tűnhet, hogy az GlassFish elég "torkosan", de ezt teljes mértékben igazolja a funkcionalitás.

Az egyik a területen nem harcos, hogyan hozzunk létre egy átállási klasztert

Megjegyzés: minden táblázatban nem csak a MB memóriafogyasztást, hanem az elfogyasztott claudlet számát is megadjuk. A Cloudlets a számlázott erőforrások számolásának módja. Egy tároló 128 MB RAM és kb. 200 Mhz CPU mag.



A Tomcat 6 a fejlesztők körében a legkedveltebb szerver az egyszerűség és stabilitás miatt. Optimális választás a legtöbb webes alkalmazáshoz. Hány erőforrást "eszik" az összes lehetséges konfigurációs opcióval, az alábbi táblázatban láthatja:

A Tomcat 7-nek is van valami büszkélkednie: még hatékonyabb és hatékonyabb, mint elődje. Ennek megfelelően valamivel magasabb költségeket igényel:



Mint Jetty. akkor ez az alkalmazáskiszolgáló egyre népszerűbb a fejlesztők körében (ahogy a statisztikák azt mutatják). Ez is a leginkább "könnyű", nézd meg magad:

Mint már tudjuk, az GlassFish egy rendkívül megbízható Java EE alkalmazáskiszolgáló, amely teljes mértékben támogatja az ipari fürtözést és számos funkciót.
A legutóbbi időkig a Glassfish-ot a Jelastic Java PaaS-ban egy külön szerverként használtuk, most támogatjuk a szerver összes funkcióját, beleértve a magas rendelkezésre állást (HA).

Mentettük a "natív" cluster architektúrát, az GlassFish-t, amely egy adminisztrációs tartomány koncepcióján alapul. Az adminisztrátori domainek klaszterekből és példányokból állnak, amelyeket a DAS (Domain Administration Server) felügyel.

A központi adattárat a felügyeleti konzol segítségével kezelheti. Ez egy egyszerűen kezelhető grafikus felület, amely támogatja az összes funkciót az Glassfish-ban. A DAS kezeli a Java tartományi példányokat, és a GMS (Group Management Service) felelős a fürtről és annak példányairól.

Replikációs munkamenetek a GlassFish-ben



A klaszterekben lévő példák párokra oszthatók. Ha egy példány sikertelen, akkor azok a felhasználók, akiknek feldolgozása folyamatban van, automatikusan átkerülnek a fürt másik példányára. Az "instance-partner" már a leomlott összes munkamenetét tartalmazza, így a végfelhasználó soha nem fog észrevenni semmilyen változást. Ha mindkét esetben sikertelen, a felhasználói kérelmek átkerülnek egy másik fürtbe. A kérések átirányítására a Jelastic az NGINX kiegyenlítőt használja (mint más alkalmazáskiszolgálók esetében).

skálázás


Természetesen nem felejtettük el a méretezést. Vízszintes és függőleges skálázást biztosít a kiszolgáló terhelésének növelése vagy csökkentése esetén. Ez azt jelenti, hogy mind a méret, mind a klaszterek száma változhat. Jelastic az első PaaS, amely ilyen tökéletes skálázási rendszert biztosít.

Az GlassFish Jelastic klaszterarchitektúrája nagyon közel áll a szabványhoz, így minden funkcióját és még egy kicsit többet is használhat.

Kapcsolódó cikkek

előző ◈ a következő