Múltkor az NSX Edge statikus és dinamikus útválasztási képességeiről beszéltünk, ma pedig a terheléselosztóval fogunk foglalkozni.
Mielőtt elkezdené a beállítást, szeretném röviden emlékeztetni a kiegyenlítés főbb típusaira.
elmélet
Az összes mai hasznos teherkiegyenlítési megoldást leggyakrabban két kategóriába sorolják: a modell negyedik (szállítási) és hetedik (alkalmazási) szintjén történő kiegyensúlyozás. . Az OSI modell nem a legjobb referenciapont a kiegyenlítési módszerek leírásánál. Például, ha egy L4-es kiegyenlítő is támogatja a TLS-lezárást, akkor L7-es kiegyenlítővé válik? De ez az, ami.
- Balancer L4 leggyakrabban egy középső proxy, amely a kliens és az elérhető háttérrendszerek halmaza között áll, amely megszakítja a TCP-kapcsolatokat (azaz önállóan válaszol a SYN-re), kiválaszt egy háttérrendszert és új TCP-munkamenetet kezdeményez annak irányában, függetlenül SYN-t küldve. Ez a típus az egyik alapvető típus, más lehetőségek is lehetségesek.
- Balancer L7 „kifinomultabban” osztja el a forgalmat az elérhető háttérrendszerek között, mint az L4-es kiegyenlítő. Például a HTTP-üzenet tartalma (URL, cookie stb.) alapján el tudja dönteni, hogy melyik háttérrendszert válassza.
A kiegyensúlyozó típustól függetlenül a következő funkciókat tudja támogatni:
- A szolgáltatásfelderítés az elérhető háttérrendszerek (statikus, DNS, konsul, stb.) meghatározásának folyamata.
- Az észlelt háttérprogramok működőképességének ellenőrzése (a backend aktív „ping”-je HTTP-kéréssel, a TCP-kapcsolatok problémáinak passzív észlelése, több 503-as HTTP-kód jelenléte a válaszokban stb.).
- Maga a kiegyenlítés (körmérkőzés, véletlenszerű kiválasztás, forrás IP hash, URI).
- TLS felmondás és tanúsítvány ellenőrzése.
- Biztonsággal kapcsolatos lehetőségek (hitelesítés, DoS támadásmegelőzés, sebességkorlátozás) és még sok más.
Az NSX Edge két terheléselosztó üzembe helyezési módot kínál:
Proxy mód, vagy egykaros. Ebben a módban az NSX Edge az IP-címét használja forráscímként, amikor kérést küld az egyik háttérprogramnak. Így a kiegyenlítő egyszerre látja el a Source és Destination NAT funkcióit. A háttérrendszer a kiegyenlítőtől küldött összes forgalmat látja, és közvetlenül válaszol rá. Egy ilyen sémában a kiegyenlítőnek ugyanabban a hálózati szegmensben kell lennie a belső szerverekkel.
Így megy ez:
1. A felhasználó kérést küld az Edge-n konfigurált VIP címre (balancer címre).
2. Az Edge kiválasztja az egyik háttérprogramot, és végrehajtja a cél NAT-ot, lecserélve a VIP-címet a kiválasztott háttérprogram címére.
3. Az Edge végrehajtja a forrás NAT-ot, lecserélve a kérést küldő felhasználó címét a sajátjára.
4. A csomag elküldésre kerül a kiválasztott háttérrendszerre.
5. A háttérrendszer nem közvetlenül a felhasználónak válaszol, hanem az Edge-nek, mivel a felhasználó eredeti címe a balancer címére módosult.
6. Az Edge továbbítja a szerver válaszát a felhasználónak.
A diagram lent látható.
Átlátszó vagy beépített mód. Ebben a forgatókönyvben a kiegyenlítő interfésszel rendelkezik a belső és külső hálózatokon. Ugyanakkor a külső hálózatról nincs közvetlen hozzáférés a belső hálózathoz. A beépített terheléselosztó NAT-átjáróként működik a belső hálózaton lévő virtuális gépek számára.
A mechanizmus a következő:
1. A felhasználó kérést küld az Edge-n konfigurált VIP címre (balancer címre).
2. Az Edge kiválasztja az egyik háttérprogramot, és végrehajtja a cél NAT-ot, lecserélve a VIP-címet a kiválasztott háttérprogram címére.
3. A csomag elküldésre kerül a kiválasztott háttérrendszerre.
4. A háttérprogram kérést kap a felhasználó eredeti címével (a forrás NAT nem került végrehajtásra), és közvetlenül válaszol rá.
5. A forgalmat ismét elfogadja a terheléselosztó, mivel egy beépített sémában általában a szerverfarm alapértelmezett átjárójaként működik.
6. Az Edge forrás-NAT-ot hajt végre, hogy forgalmat küldjön a felhasználónak, és a VIP-t használja forrás IP-címként.
A diagram lent látható.
Gyakorlat
A tesztpadomban 3 Apache kiszolgáló fut, amely HTTPS-en keresztül működik. Az Edge elvégzi a HTTPS-kérelmek körkörös kiegyensúlyozását, és minden új kérést egy új szerverre küld.
Kezdjük el.
Az NSX Edge által használt SSL-tanúsítvány létrehozása
Importálhat érvényes CA-tanúsítványt, vagy használhat önaláírt tanúsítványt. Ehhez a teszthez saját aláírást használok.
- A vCloud Director felületen lépjen az Edge szolgáltatások beállításaihoz.
- Lépjen a Tanúsítványok lapra. A műveletek listájából válassza ki az új CSR hozzáadását.
- Töltse ki a kötelező mezőket, majd kattintson a Megtartás gombra.
- Válassza ki az újonnan létrehozott CSR-t, és válassza az önaláíró CSR lehetőséget.
- Válassza ki a tanúsítvány érvényességi idejét, majd kattintson a Megtartás gombra
- Az önaláírt tanúsítvány megjelenik az elérhető tanúsítványok listájában.
Alkalmazásprofil beállítása
Az alkalmazásprofilok teljesebb ellenőrzést biztosítanak a hálózati forgalom felett, és egyszerűvé és hatékonysá teszik a kezelését. Használhatók bizonyos típusú forgalom viselkedésének meghatározására.
- Lépjen a Load Balancer fülre, és engedélyezze a kiegyenlítőt. A Gyorsítás engedélyezve opció lehetővé teszi, hogy a kiegyenlítő gyorsabb L4-es kiegyensúlyozást használjon az L7 helyett.
- Az alkalmazásprofil beállításához lépjen az Alkalmazásprofil fülre. Kattintson a + gombra.
- Állítsa be a profil nevét, és válassza ki a forgalom típusát, amelyre a profilt alkalmazni kívánja. Hadd magyarázzam el néhány paramétert.
Kitartás – tárolja és nyomon követi a munkamenet adatait, például: a készlet melyik szervere szolgálja ki a felhasználói kérést. Ez biztosítja, hogy a felhasználói kérések ugyanahhoz a készlettaghoz legyenek irányítva a munkamenet vagy az azt követő munkamenetek élettartama alatt.
SSL áthárítás engedélyezése – Ha ezt a lehetőséget választja, az NSX Edge leállítja az SSL leállítását. Ehelyett a felmondás közvetlenül a kiegyensúlyozott szervereken történik.
Helyezze be az X-Forwarded-For HTTP fejlécet – lehetővé teszi a terheléselosztón keresztül a webszerverhez csatlakozó kliens forrás IP-címének meghatározását.
Engedélyezze a medence oldali SSL-t – lehetővé teszi annak megadását, hogy a kiválasztott készlet HTTPS-kiszolgálókat tartalmazzon.
- Mivel a HTTPS forgalmat kiegyensúlyozom, engedélyeznem kell a Pool Side SSL-t, és ki kell választanom a korábban generált tanúsítványt a Virtuális szerver tanúsítványai -> Szolgáltatási tanúsítvány lapon.
- Hasonlóan a Pool tanúsítványokhoz -> Szolgáltatási tanúsítványhoz.
Létrehozunk egy szerverkészletet, amelyhez a forgalom kiegyensúlyozott pool lesz
- Lépjen a Medencék lapra. Kattintson a + gombra.
- Beállítjuk a készlet nevét, kiválasztjuk az algoritmust (a körvizsgálatot fogom használni) és a monitorozás típusát az állapotellenőrző háttérrendszerhez.Az Átlátszó opció jelzi, hogy a kliensek kezdeti forrás IP-címe látható-e a belső szerverek számára.
- Ha az opció le van tiltva, a belső szerverek forgalma a kiegyenlítő forrás IP-jéről származik.
- Ha az opció engedélyezve van, a belső szerverek látják az ügyfelek forrás IP-címét. Ebben a konfigurációban az NSX Edge-nek alapértelmezett átjáróként kell működnie annak biztosítására, hogy a visszaküldött csomagok áthaladjanak az NSX Edge-n.
Az NSX a következő kiegyensúlyozó algoritmusokat támogatja:
- IP_HASH – a szerver kiválasztása egy hash függvény eredményei alapján az egyes csomagok forrás- és cél IP-címéhez.
- LEASTCONN – a bejövő kapcsolatok kiegyensúlyozása az adott szerveren már elérhető számtól függően. Az új kapcsolatok a legkevesebb kapcsolattal rendelkező szerverre lesznek irányítva.
- ROUND_ROBIN – az új kapcsolatok sorra kerülnek minden szerverre, a hozzárendelt súlynak megfelelően.
- URI – az URI bal oldali részét (a kérdőjel előtt) kivonatolja, és elosztja a készletben lévő szerverek össztömegével. Az eredmény azt jelzi, hogy melyik szerver kapja meg a kérést, biztosítva, hogy a kérés mindig ugyanahhoz a szerverhez kerüljön átirányításra, mindaddig, amíg az összes kiszolgáló elérhető marad.
- HTTPHEADER – egy adott HTTP fejléc alapján történő kiegyenlítés, amely paraméterként adható meg. Ha a fejléc hiányzik vagy nincs értéke, akkor a ROUND_ROBIN algoritmus kerül alkalmazásra.
- URL – Minden HTTP GET kérés az argumentumként megadott URL paramétert keresi. Ha a paramétert egyenlőségjel és érték követi, akkor az értéket kivonatolja, és elosztja a futó szerverek össztömegével. Az eredmény azt jelzi, hogy melyik szerver fogadja 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, és biztosítja, hogy mindig ugyanaz a felhasználói azonosító kerüljön elküldésre ugyanahhoz a szerverhez, mindaddig, amíg az összes kiszolgáló elérhető marad.
- A Tagok blokkban kattintson a + gombra, ha szervereket szeretne hozzáadni a készlethez.
Itt kell jelezni:- szerver név;
- Szerver IP cím;
- a port, amelyen a szerver forgalmat fogad;
- port az állapotfelméréshez (Monitor healthcheck);
- súly – ezzel a paraméterrel beállíthatja a forgalom arányos mennyiségét egy adott pooltag esetében;
- Max Connections – a szerverhez fűződő kapcsolatok maximális száma;
- Minimális kapcsolatok – a kapcsolatok minimális száma, amelyet a szervernek fel kell dolgoznia, mielőtt a forgalmat továbbítaná a következő készlettagnak.
Így néz ki a három szerverből álló végső készlet.
Virtuális szerver hozzáadása
- Lépjen a Virtuális szerverek lapra. Kattintson a + gombra.
- A virtuális szervert az Enable Virtual Server segítségével aktiváljuk.
Adunk neki egy nevet, kiválasztjuk a korábban létrehozott Alkalmazásprofilt, Poolt és megadjuk azt az IP címet, amelyre a Virtuális Szerver kívülről kapja a kéréseket. Megadjuk a HTTPS protokollt és a 443-as portot.
Opcionális paraméterek itt:
Csatlakozási korlát – a virtuális szerver által feldolgozható egyidejű kapcsolatok maximális száma;
Csatlakozási sebességkorlát (CPS) – az új bejövő kérések maximális száma másodpercenként.
Ezzel befejeződik a kiegyenlítő konfigurálása, ellenőrizheti a működését. A szerverek egyszerű konfigurációval rendelkeznek, amely lehetővé teszi annak megértését, hogy a készlet melyik kiszolgálója dolgozta fel a kérést. A beállítás során a Round Robin kiegyenlítő algoritmust választottuk, és a Weight paraméter minden szerverhez egyenlő eggyel, így minden további kérést a készlet következő szervere dolgoz fel.
Beírjuk a kiegyenlítő külső címét a böngészőbe, és látjuk:
Az oldal frissítése után a kérést a következő szerver dolgozza fel:
És ismét - a harmadik szerver ellenőrzéséhez a medencéből:
Az ellenőrzés során láthatja, hogy az Edge által nekünk küldött tanúsítvány ugyanaz, mint amit a legelején generáltunk.
A kiegyenlítő állapotának ellenőrzése az Edge átjárókonzolról. Ehhez írja be show service loadbalancer pool.
A Service Monitor konfigurálása a készletben lévő kiszolgálók állapotának ellenőrzésére
A Service Monitor segítségével nyomon követhetjük a háttérkészletben lévő szerverek állapotát. Ha a kérésre adott válasz nem a vártnak felel meg, a szervert ki lehet venni a készletből, így nem kap új kéréseket.
Alapértelmezés szerint három ellenőrzési módszer van konfigurálva:
- TCP monitor,
- HTTP monitor,
- HTTPS-monitor.
Hozzunk létre egy újat.
- Lépjen a Szolgáltatásfigyelés lapra, és kattintson a + gombra.
- Választ:
- az új módszer neve;
- a kérések elküldésének időköze,
- időtúllépés válaszra várva,
- figyelési típus – HTTPS kérés GET metódussal, várható állapotkód – 200(OK) és kérés URL.
- Ezzel befejeződött az új Service Monitor telepítése, amelyet most már használhatunk készlet létrehozásához.
Pályázati szabályok beállítása
Az alkalmazási szabályok a forgalom manipulálásának módjai bizonyos triggerek alapján. Ezzel az eszközzel olyan fejlett terheléselosztási szabályokat hozhatunk létre, amelyek nem biztos, hogy lehetségesek az alkalmazásprofilokon vagy az Edge Gateway-en elérhető egyéb szolgáltatásokon keresztül.
- Szabály létrehozásához lépjen a kiegyenlítő Alkalmazási szabályok lapjára.
- Válasszon egy nevet és egy parancsfájlt, amely a szabályt használja, majd kattintson a Megtartás gombra.
- A szabály létrehozása után szerkesztenünk kell a már konfigurált Virtual Servert.
- A Speciális lapon adja hozzá az általunk létrehozott szabályt.
A fenti példában engedélyeztük a tlsv1 támogatást.
Még egy-két példa:
A forgalom átirányítása egy másik készletbe.
Ezzel a szkripttel átirányíthatjuk a forgalmat egy másik kiegyenlítő készletbe, ha a fő készlet nem működik. A szabály működéséhez több készletet kell konfigurálni a kiegyenlítőn, és a fő készlet minden tagjának lefelé mutató állapotban kell lennie. A készlet nevét kell megadnia, nem az azonosító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 külső erőforrásra.
Itt átirányítjuk a forgalmat a külső webhelyre, ha a főkészlet összes tagja nem működik.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Még több példa .
Nekem ennyi a kiegyensúlyozóról. Ha kérdésed van, tedd fel, készséggel válaszolok.
Forrás: will.com