Legutóbb az NSX Edge lehetőségeiről beszéltünk a statikus és dinamikus irányítási lehetőségek tükrében, ma pedig a terheléselosztóról fogunk beszélni.
Mielőtt nekilátnánk a beállításoknak, szeretném röviden áttekinteni az alapvető terheléselosztási típusokat.
Elmélet
A mai terheléselosztási megoldásokat leggyakrabban két kategóriába sorolják: a negyedik (szállítási) és a hetedik (alkalmazási) réteg szerint. Az OSI modell nem a legjobb referencia pont a terheléselosztási módszerek leírására. Például, ha egy L4-es terheléselosztó támogatja a TLS terminálást, akkor L7-es terheléselosztónak számít-e? De ami van, az van.
- Az L4-es terheléselosztó általában egy köztes proxy, amely a kliens és a rendelkezésre álló backendek között helyezkedik el, terminálja a TCP kapcsolatokat (tehát saját magának válaszol a SYN-re), kiválaszt egy backendet és új TCP szessiont indít el felé, saját magától küldve a SYN-t. Ez a típus az alapmodell egyike, más lehetőségek is léteznek.
- Az L7-es terheléselosztó például a HTTP üzenet tartalma (URL, süti stb.) alapján képes dönteni a backend kiválasztásáról, "finomabban" osztja el a forgalmat a rendelkezésre álló backendek között, mint az L4-es terheléselosztó.
Függetlenül a típustól, a terheléselosztó a következő funkciókat támogathatja:
- Szolgáltatás felfedezés – a rendelkezésre álló backendek készletének meghatározása (Static, DNS, Consul, Etcd stb.).
- Felfedezett backendek elérhetőségének ellenőrzése (aktív "ping" backend HTTP kérés segítségével, passzív hibafelismerés TCP kapcsolatokban, több egymást követő 503-as HTTP-kód válaszok megléte stb.).
- A terheléselosztás (round robin, véletlenszerű kiválasztás, forrás IP hash, URI).
- TLS terminálás és a tanúsítványok ellenőrzése.
- Biztonsággal kapcsolatos opciók (azonosítás, DoS támadások megakadályozása, sebességkorlátozás) és még sok más.
Az NSX Edge két terheléselosztó telepítési módot kínál:
Proxy üzemmód, vagy one-arm. Ebben a módban az NSX Edge a hátsó végpontok egyikére küldött kérésnél a saját IP-címét használja forráscímként. Így a terheléselosztó egyszerre látja el a Source és Destination NAT funkciókat. A hátsó végpont az összes forgalmat úgy észleli, mintha azt a terheléselosztótól küldték volna, és közvetlenül rá válaszol. Ezen rendszer szerint a terheléselosztónak egy hálózati szegmensen belül kell lennie a belső szerverekkel.
Így történik:
1. A felhasználó kérdést küld a VIP-címre (a terheléselosztó címe), amely az Edge-en van konfigurálva.
2. Az Edge választ egy hátsó végpontot és destination NAT-ot hajt végre, lecserélve a VIP-címet a választott hátsó végpont címére.
3. Az Edge source NAT-ot végez, lecserélve a kérdést küldő felhasználó címét a sajátjára.
4. A csomag a választott hátsó végpontra kerül elküldésre.
5. A hátsó végpont nem közvetlenül a felhasználónak válaszol, hanem az Edge-nek, mivel a felhasználó eredeti címe meg lett változtatva a terheléselosztó címére.
6. Az Edge átadja a szerver válaszát a felhasználónak.
Az alábbi séma.
Átlátszó, vagy inline mód. Ebben a forgatókönyvben a terheléselosztónak interfészei vannak a belső és külső hálózatban. A belső hálózathoz nincs közvetlen hozzáférés a külső felől. Az integrált terheléselosztó NAT-gatewayként működik a belső hálózat virtuális gépei számára.
A mechanizmus a következő:
1. A felhasználó kérdést küld a VIP-címre (a terheléselosztó címe), amely az Edge-en van konfigurálva.
2. Az Edge választ egy hátsó végpontot és destination NAT-ot hajt végre, lecserélve a VIP-címet a választott hátsó végpont címére.
3. A csomag a választott hátsó végpontra kerül elküldésre.
4. A hátsó végpont közvetlenül kapja a felhasználó eredeti címét (source NAT nem volt végrehajtva) és közvetlenül rá válaszol.
5. A forgalmat ismét a terheléselosztó fogadja, mivel inline rendszer esetén általában alapértelmezett gateway-ként működik a szerver farm számára.
6. Az Edge source NAT-ot hajt végre a forgalom felhasználónak való küldése érdekében, a saját VIP-jét forrás IP-címként használva.
Az alábbi séma.
Gyakorlat
A tesztkörnyezetemben 3 Apache-szerver van beállítva, amely HTTPS-en működik. Az Edge round robin módszerrel végzi az HTTPS-kérelmek terheléselosztását, minden új kérdést új szerverre proxizálva.
Kezdjük.
SSL-tanúsítványt generálunk, amelyet az NSX Edge használni fog.
Érvényes CA-tanúsítványt importálhat, vagy használhat önaláírt tanúsítványt. Ezen a teszten önaláírt tanúsítványt fogok használni.
- A vCloud Director felületén lépjünk a szolgáltatások Edge-beállításaiba.
- Lépjünk a Tanúsítványok fülecske alá. Az akciók listájából válasszuk az új CSR hozzáadását.
- Töltsük ki a szükséges mezőket, majd kattintsunk a Keep gombra.
- Jelöljük ki a nemrég létrehozott CSR-t, majd válasszuk a self-sign CSR opciót.
- Válasszuk ki a tanúsítvány érvényességi idejét, majd klikkeljünk a Keep gombra.
- Az önaláírt tanúsítvány megjelent a rendelkezésre álló tanúsítványok listájában.
Konfiguráljuk az Application Profile-t.
Az application profile-ok teljesebb ellenőrzést biztosítanak a hálózati forgalom felett, és egyszerűvé, hatékonnyá teszik annak kezelését. Ezek segítségével meghatározhatjuk a forgalom viselkedését konkrét típusok esetén.
- Lépjünk a Load Balancer fülre, és aktiváljuk a terheléselosztót. Az Acceleration enabled opció itt lehetővé teszi, hogy a terheléselosztó gyorsabb L4 terheléselosztást végezzen L7 helyett.
- Lépjünk az Application profile fülre, hogy beállítsuk az alkalmazás profilt. Kattintsunk a + gombra.
- Adjuk meg a profil nevét, és válasszuk ki a forgalom típusát, amire a profil vonatkozni fog. Ismertetem néhány paramétert.
Persistence – megőrzi és nyomon követi a sessió adatait, például: melyik konkrét szerver a poolból kiszolgálja a felhasználói kérést. Ez garantálja, hogy a felhasználói kérések egy adott pool tagnak kerülnek továbbításra a sessió vagy a következő sessió ideje alatt.
Enable SSL passthrough – ennek az opció kiválasztásával a NSX Edge leállítja az SSL terhelést. Ehelyett a terhelés közvetlenül a szervereken történik, amelyekre a terheléselosztás irányul.
Insert X-Forwarded-For HTTP header – lehetővé teszi a webkiszolgálóhoz csatlakozó kliens eredeti IP-címének meghatározását a terheléselosztón keresztül.
Enable Pool Side SSL – lehetővé teszi, hogy kijelöljük, hogy a kiválasztott pool HTTPS-szerverekből áll.
- Mivel HTTPS-forgalmat fogok balanszírozni, be kell kapcsolnom a Pool Side SSL-t, és ki kell választanom az előzőleg generált tanúsítványt a Virtual Server Certificates fül alatt –> Service Certificate.
- Hasonlóan a Pool Certificates –> Service Certificate opcióhoz.
Hozzunk létre egy szerver pool-t, amelynek forgalmát egyensúlyozni fogjuk Pools.
- Lépjünk a Pools fülre. Kattintsunk a + gombra.
- Adjuk meg a pool nevét, válasszuk ki az algoritmust (én round robin-t fogok használni) és a backend health check monitorozásának típusát. A Transparent opció azt jelzi, hogy az eredeti kliens source IP-k láthatók-e a belső szerverek számára.
- Ha az opció ki van kapcsolva, a belső szerverek számára a terheléselosztó source IP-jével érkezik a forgalom.
- Ha az opció be van kapcsolva, a belső szerverek látják a kliensek source IP-jét. Ilyen konfigurációban a NSX Edge-nek az alapértelmezett átjáróként kell működnie, hogy biztosítsa, hogy a visszaküldött csomagok a NSX Edge-en keresztül haladjanak.
Az NSX a következő terheléselosztási algoritmusokat támogatja:
- IP_HASH – a szerver kiválasztása a forrás és cél IP címek hash függvényének eredményei alapján minden csomaghoz.
- LEASTCONN – a bejövő kapcsolatok terheléselosztása a már egy adott szerveren lévő mennyiség alapján. Az új kapcsolatok a legkevesebb kapcsolattal rendelkező szerverhez lesznek irányítva.
- ROUND_ROBIN – az új kapcsolatok minden szerverhez váltakozva kerülnek küldésre az adott súlyuknak megfelelően.
- URI – az URI bal oldala (a kérdőjel előtt) hash-elésre kerül és elosztásra az összes szerver súlyával a poolban. Az eredmény megmutatja, hogy melyik szerver kapja a kérést, biztosítva, hogy a kérés mindig ugyanarra a szerverre érkezzen, amíg minden szerver elérhető marad.
- HTTPHEADER – a terheléselosztás egy adott HTTP fejléc alapján történik, amely megadható paraméterként. Ha a fejléc hiányzik vagy nincs értéke, a ROUND_ROBIN algoritmus alkalmazásra kerül.
- URL – minden HTTP GET kérésnél keresés történik az URL paraméterében, amelyet argumentumként adtunk meg. Ha a paraméter után egy egyenlőségjel és érték következik, akkor az érték hash-elésre kerül és elosztásra az összes elindított szerver súlyával. Az eredmény megmutatja, hogy melyik szerver kapja a kérést. Ez a folyamat a felhasználói azonosítók nyomon követésére szolgál a kérésekben, biztosítva, hogy a ugyanaz a felhasználói azonosító mindig ugyanarra a szerverre kerüljön, amíg minden szerver elérhető marad.
- A Members blokkban kattintsunk a + gombra, hogy szervereket adjunk a poolhoz.
1. Az Elasticsearch szerver címe (a telepítéskor megadott).- szerver neve;
- szerver IP-címe;
- a port, amelyen a szerver fogadja a forgalmat;
- port a health check-hez (Monitor healthcheck);
- súly (Weight) – ezzel a paraméterrel beállíthatjuk a forgalom arányos mennyiségét egy adott pool tag számára;
- Max Connections – a maximális kapcsolatok száma a szerverhez;
- Min Connections – a minimális kapcsolatok száma, amelyet a szervernek kezelnie kell, mielőtt a forgalmat a következő pool tagra irányítják.
Így néz ki a végső pool három szerverből.
Virtual Server hozzáadása
- Lépjünk a Virtual Servers fülre. Kattintsunk a + gombra.
- Aktiváljuk a virtuális szervert az Enable Virtual Server beállítással.
Adjuk neki nevet, válasszuk ki a korábban létrehozott Application Profile-t, Pool-t, és adjuk meg azt az IP-címet, amelyre a Virtual Server külső kéréseket fogad. A protokollt HTTPS-re és a portot 443-ra állítjuk.
Itt opcionális paraméterek találhatók:
Kapcsolódási limit – a virtuális szerver által feldolgozható egyidejű kapcsolatok maximális száma;
Kapcsolódási sebesség limit (CPS) – az új bejövő kérések maximális száma másodpercenként.
Ezzel a terheléselosztó konfigurációja befejeződött, ellenőrizhetjük a működését. A szerverek a legegyszerűbb konfigurációval rendelkeznek, amely lehetővé teszi, hogy megértsük, pontosan melyik szerver a pool-ból dolgozta fel a kérést. A beállítás során a Round Robin terheléselosztási algoritmust választottuk, és minden szerverhez tartozó Weight paraméter egyenlő egyel, így a következő kérés a pool következő szerverét fogja feldolgozni.
Beírjuk a böngészőbe a terheléselosztó külső címét, és látjuk:
Az oldal frissítése után a következő kérést a következő szerver dolgozza fel:
És még egyszer – hogy ellenőrizzük a pool harmadik szerverét is:
Ellenőrzés során láthatjuk, hogy az Edge által küldött tanúsítvány az, amelyet az elején generáltunk.
A terheléselosztó állapotának ellenőrzése az Edge gateway konzoljából. Ehhez írja be show service loadbalancer pool.
Szerviz-monitor beállítása a poolban lévő szerverek állapotának ellenőrzésére
A Service Monitor segítségével nyomon követhetjük a backend poolban lévő szerverek állapotát. Ha a kérés válaszai nem felelnek meg a vártnak, a szervert ki lehet vonni a poolból, hogy ne kapjon új kéréseket.
Alapértelmezés szerint három ellenőrzési módszer van beállítva:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Hozzunk létre egy újat.
- Átmegyünk a Szervizmonitorozás fülre, rákattintunk a + gombra.
- Kiválasztjuk:
- nevet az új módszerhez;
- az intervallumot, amellyel a kéréseket küldjük,
- a válasz várakozási idejét,
- a monitorozás típusát – HTTPS kérés GET módszerrel, elvárt státuszkód – 200(OK) és a kérés URL-jét.
- Ezzel a Service Monitor új beállítása befejeződött, most felhasználhatjuk azt a pool létrehozásakor.
Application Rules beállítása
Az Application Rules – a forgalom manipulálásának módja, amely bizonyos kiváltókra épít. Ezzel az eszközzel fejlett terheléselosztási szabályokat hozhatunk létre, amelyek konfigurálása lehetetlen lehet az Application profils vagy az Edge Gateway-en elérhető egyéb szolgáltatások segítségével.
- A szabály létrehozásához lépjünk az alkalmazási szabályok fülére a terheléselosztón.
- Válasszuk ki a nevet, a szkriptet, amely a szabályt használni fogja, és kattintsunk a Megtartás gombra.
- Miután a szabály létrejött, módosítanunk kell a már beállított virtuális szervert.
- Az Advanced fülön adjuk hozzá a létrehozott szabályunkat.
A fenti példa szerint engedélyeztük a tlsv1 támogatását.
Még néhány példa:
A forgalom átirányítása egy másik poolra.
Ezzel a szkripttel a forgalmat egy másik terheléselosztási poolra irányíthatjuk, ha a fő pool nem működik. Ahhoz, hogy a szabály érvényesüljön, a terheléselosztón konfigurálva kell lennie több poolnak, és a fő pool összes tagjának le kell állnia. Itt pontosan a pool nevét kell megadni, nem az ID-ját.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
A forgalom átirányítása egy külső forrásra.
Itt a forgalmat egy külső weboldalra irányítjuk, ha a fő pool összes résztvevője le van állítva.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Még több példa .
Ezzel a terheléselosztóval kapcsolatban mindent elmondtam. Ha kérdései vannak, kérdezzen, szívesen válaszolok.
Forrás: habr.com
