HAProxy és terheléselosztási koncepciók: az alapok

Bevezetés

High Availability Proxy (HAProxy), egy népszerű nyílt forráskódú proxy- és TCP/HTTP-terheléselosztó megoldás, amely futtatható Solaris, FreeBSD, és Linux rendszereken. Leggyakrabban a szerverkörnyezet megbízhatóságának és teljesítményének növelésére használják, a munkaterhelés kiegyensúlyozott elosztásával több szerver között. Ezt az eszköztípust számos kiemelt környezetben használják, mint például az Instagram, a GitHub, a Twitter és az Imgur.

Ez az útmutató bemutatja a HAProxy-t, megismerteti Önt a terheléselosztási terminológiával, és példákat mutat be arra, hogyan használható fel a szerverkörnyezetek teljesítményének és megbízhatóságának növelésére.

Alapvető HAProxy kifejezések

Mielőtt rátérnénk a terheléselosztás és a proxyzás részleteire, érdemes megismerkedni néhány fontos kifejezéssel és fogalommal. Kezdjük ezen fogalmak áttekintésével a következő szakaszokban.

ACL (Access Control List)

Ha terheléselosztásról van szó, az ACL-ek egy adott feltétel tesztelésére és az eredmény alapján egy művelet végrehajtására szolgálnak. Ez lehetővé teszi a forgalom optimális továbbítását olyan tényezők alapján, mint a háttérkapcsolatok (backend), a mintaillesztés és számos egyéb szempont. Íme egy példa az ACL használatára:

Ebben az esetben az ACL akkor egyezik, ha a felhasználó által kért útvonal a /blog karakterlánccal kezdődik. Ez az egyező kérés például a következőre mutatna: http://yourdomain.com/blog/blog-entry-1. A HAProxy konfigurációs kézikönyv részletes útmutatót tartalmaz az ACL használatáról.

The Backend

A továbbított kéréseket egy szervercsoport fogadja, amelyet backendnek nevezünk. A kérések a HAProxy konfiguráció backend szekciójában vannak meghatározva. A legegyszerűbb megfogalmazásban a backendet a használandó terheléselosztási algoritmusok, valamint a portok és szerverek listája határozza meg. Egy backend állhat egyetlen szerverből vagy több szerverből is. Ahogy egyre több szervert adunk a backendhez, a potenciális terhelhetőség növekszik, a feldolgozás pedig megoszlik a több szerver között. Ha a backend szerverek közül néhány leáll, a többiek tartalékként szolgálnak a kérések feldolgozásához.

Nézzünk meg egy példát két backend konfigurációjára. Ebben az esetben ezek egy blog-backend és egy web-backend. Mindegyik két webszerverrel rendelkezik, amelyek a 80-as porton hallgatóznak:

A balance roundrobin sor a terheléselosztási algoritmus meghatározására szolgál. A részletek a következő, Terheléselosztási algoritmusok című szakaszban találhatók, míg a mode http a 7. rétegbeli (layer 7) proxy használatát állítja be. Ezt a Terheléselosztási típusok szakaszban fogjuk elmagyarázni. Emellett a szerverek definíciója után álló check opció azt jelzi, hogy az adott backend szervereken állapotellenőrzések (health check) fognak futni.

The Frontend

Azt a definíciót, amely meghatározza, hogyan továbbítódnak a kérések a backendhez, frontendnek nevezünk. A kérések a HAProxy konfiguráció frontend szekciójában vannak meghatározva. Ezek ACL-ekből, egy portból, IP-címekből és egy úgynevezett use_backend szabályból állnak, amely meghatározza, hogy melyik backendet kell használni attól függően, hogy melyik ACL-feltétel teljesült. Emellett létezik egy default_backend szabály is minden egyéb eset kezelésére. A következő szakasz bemutatja, hogyan konfigurálható a frontend a különböző hálózati forgalomtípusokhoz.

Terheléselosztási típusok

A terheléselosztáshoz használt alapvető összetevők tisztázása után most áttérhetünk a terheléselosztás alapvető típusaira.

Nincs terheléselosztás

A legkezdetlegesebb formájában a terheléselosztás hiánya a következőképpen ábrázolható:

Ebben a forgatókönyvben a felhasználó közvetlenül a webkiszolgálóhoz csatlakozik a yourdomain.com címen. Nincs terheléselosztás. Mivel csak egy adatbázis-szerver van, ha az offline állapotba kerül, a rajta lévő információkhoz való hozzáférés teljesen megszakad. Ha sok felhasználó próbál egyszerre csatlakozni egyetlen webkiszolgálóhoz, és az nem képes kezelni az ebből adódó terhelést, az összes kapcsolat lelassul, vagy teljesen meghiúsul.

Terheléselosztás (4. réteg)

A hálózati forgalom több szerver közötti elosztásának egyik legegyszerűbb, legpraktikusabb módja a szállítási réteg vagy a 4. rétegbeli elosztási módszerek használata. A terheléselosztásnak ez a módja minden csatlakozó felhasználót az IP-címük IP-tartománya és a port alapján irányít át. Más szóval, ha a http://yourdomain.com/anything címről érkezik a kérés, akkor a kérések kezelésére meghatározott backend fogja azt végső soron feldolgozni. Továbbítani fogja ezeket a kéréseket a yourdomain.com felé a 80-as porton.

A 4. rétegbeli terheléselosztás alapvető felépítése így néz ki:

Amikor a felhasználó hozzáférést kap a terheléselosztóhoz, a kérései a web-backend szervercsoporthoz továbbítódnak. A konfigurált backend szerver közvetlenül válaszol a felhasználó kérésére. Annak elkerülése érdekében, hogy a felhasználó inkonzisztens adatokkal találkozzon, az összes web-backend szervernek azonos tartalmat kell kiszolgálnia. A fenti ábra szerint mindkét webszerver végső soron ugyanahhoz az adatbázis-szerverhez kapcsolódik.

Terheléselosztás (7. réteg)

Létezik egy másik, összetettebb módszer is a hálózati forgalom terheléselosztására. Ez a 7. szintű, vagyis alkalmazási rétegbeli terheléselosztás. Ez a megközelítés lehetővé teszi, hogy a felhasználói kérések a kérések tartalmától függően különböző backend szerverekre továbbítódjanak. Ez a módszer lehetővé teszi a terheléselosztást több webalkalmazás-szerver között ugyanazon a porton és tartományon keresztül. A réteggel kapcsolatos további részletekért tekintse meg a The Nitty Gritty of Networking: Learn about Terminology, Interfaces, and Protocols útmutatónk HTTP alfejezetét.

A következő ábra a 7. rétegbeli terheléselosztást szemlélteti:

Ebben az esetben a felhasználó a yourdomain.com/blog címet kéri, és a kérése a blog backendhez továbbítódik. Ez egy kifejezetten a blog alkalmazás futtatására kijelölt backend szerverkészlet. Eközben a többi kérés a web-backendhez továbbítódik. Mindkét backend azonban ugyanahhoz az adatbázis-szerverhez fér hozzá.

A 7. rétegbeli terheléselosztás frontend konfigurációjának egy kis darabjára példaként a következő parancsok szolgálnak. Úgy konfigurálják a http frontendet, hogy a bejövő forgalmat a 80-as porton keresztül kezelje:

Ha a felhasználó kérésének útvonala a /blog-gal kezdődik, az acl url_blog path_beg /blog egyezni fog a kéréssel.

use_backend blog backend if url_blog az ACL használatával a blog-backendhez irányítja a forgalmat.

defaut_backen web_backend minden más forgalmat a web-backendhez irányít.

A terheléselosztás algoritmusai

Terheléselosztás végrehajtásakor a terheléselosztási algoritmus határozza meg, hogy melyik backend szerver kerül kiválasztásra erre a célra. A HAProxy számos algoritmus-lehetőséget kínál. Ezenkívül lehetőség van egy súlyparaméter hozzárendelésére is a szerverekhez, amellyel befolyásolható, hogy egy szerver milyen gyakran kerüljön kiválasztásra a többiekhez képest. Egyszerűen túl sok algoritmus áll rendelkezésre ahhoz, hogy mindegyiket ismertessük. Ezért ez az útmutató csak a leggyakoribbakra összpontosít. Hivatkozhat a HAProxy Documentation Converter dokumentumra a teljes lista megtekintéséhez. A leggyakrabban használtak a következők:

• roundrobin: Az alapértelmezett algoritmus, amely sorban választja ki a szervereket.
• leastconn: A rendszer automatikusan a legkevesebb kapcsolattal rendelkező szervert választja ki. Azonban az ugyanazon a backend-en belüli szervereket round-robin módszerrel kell váltogatni.
• source: Az algoritmus a felhasználói kérést indító IP-cím alapján választja ki a szervert. Ez egy olyan módszer, amellyel biztosítható, hogy a felhasználó mindig ugyanahhoz a szerverhez kapcsolódjon.

Sticky Sessions

Egyes alkalmazások esetében követelmény, hogy a kapcsolódó felhasználók mindig ugyanahhoz a szerverhez kapcsolódjanak. A „sticky sessions” (ragaszkodó munkamenetek) révén és a(z) appsession paraméter használatával az ezt igénylő backendben ez a perzisztencia elérhető.

Health Check-ek feldolgozása

A HAProxy-nak szüksége van egy módszerre, amellyel meghatározhatja a backend szerver kérések feldolgozására való képességét. Ez kiváltja a szerver eltávolítását a backendből, ha az offline állapotba kerül. Létezik egy alapértelmezett „health check” (egészségügyi ellenőrzés) futtatás, amely megpróbál TCP-kapcsolatot létesíteni. Ezt a beállított IP-címen és porton való figyeléssel teszi meg.

Ha a szerver health check-je sikertelen, a szerver nem képes feldolgozni a küldött kéréseket. Ekkor a szerver automatikusan letiltásra kerül a backendben, és a forgalom nem lesz továbbítva felé, amíg újra működőképes (egészséges) nem lesz. Bizonyos esetekben azonban a szerver állapotának meghatározása az alapértelmezett health check segítségével elégtelennek bizonyul.

Alternatív megoldások

Előfordulhat, hogy a HAProxy túl kifinomultnak bizonyul az Ön egyedi igényeihez képest. Ebben az esetben van néhány jó alternatíva, amelyek hatékonyabbnak bizonyulhatnak:

• Nginx: Ez egy megbízható és gyors webszerver, amely terheléselosztási és proxy célokra is használható. Valójában az Nginx-et gyakran használják a HAProxy-val együtt, amely kihasználja annak tömörítési és gyorsítótárazási képességeit.
• Linux Virtual Servers (LVS): Ez egy egyszerű, 4. rétegbeli (layer 4) terheléselosztó, amely számos Linux rendszerben megtalálható.

Magas rendelkezésre állás

Eddig a 4. és 7. rétegbeli terheléselosztásról beszéltünk. Mindkettő terheléselosztót használ annak meghatározására, hogy a számos backend szerver közül melyik kapja feladatul a felhasználó kérésének megválaszolását. Fontos azonban észben tartani a terheléselosztó korlátait. Nevezetesen azt, hogy ez egy egypontos hibaforrás (single point of failure). Ez azt jelenti, hogy ha leállna, vagy túlterheltté válna a felhasználói kérésekkel, az leállást vagy a kérések feldolgozásának késleltetését eredményezné. Egy HA (magas rendelkezésre állású) felépítés azonban olyan infrastruktúrát biztosít, amelyből hiányzik az egypontos hibaforrás. Ez megakadályozza a szerverhibák miatti leállásokat azáltal, hogy a rendszer architektúrájának minden szintjén redundanciát vezet be. Bár a terheléselosztó segít elősegíteni a backend redundanciáját, maguknak a terheléselosztóknak is redundánsnak kell lenniük.

A következő diagram egy magas rendelkezésre állású rendszer alapvető formáját mutatja be:

Ez az infrastruktúra több terheléselosztóval rendelkezik (egy aktív, a többi passzív), amelyek egy statikus IP-címhez vannak kötve. Ez az IP-cím szükség esetén átirányítható egy másik szerverre. A felhasználói kérés a külső IP-címen keresztül jut el a jelenleg aktív terheléselosztóhoz. Ha a terheléselosztó éppen offline állapotban van, a hibatűrő (failsafe) mechanizmus észleli annak állapotát, és hozzárendeli az IP-címet a passzív szerver(ek)hez.

Összegzés

A terheléselosztás alapvető megértése és azon módok ismerete, ahogyan a HAProxy képes kielégíteni a rendszere terheléselosztási igényeit, szilárd alapot nyújt a jelenlegi szerverkörnyezetei megbízhatóságának és teljesítményének optimalizálásához. Megtekintheti továbbá az alábbi útmutatónkat is: Nginx HTTP proxyzás, terheléselosztás, pufferelés és gyorsítótárazás: áttekintés, hogy többet tudjon meg az Nginx terheléselosztási tulajdonságairól.

Kellemes számítástechnikát!