VMware NSX za male. Dio 5. Postavljanje ravnoteže opterećenja

Prvi dio. Uvod
Drugi dio. Postavka pravila vatrozida i NAT-a
Treći dio. Postavka DHCP-a
Četvrti deo. Konfiguracija usmeravanja

Zadnji put smo govorili o mogućnostima NSX Edge u kontekstu statičke i dinamičke rutiranja, a danas ćemo se baviti balancerom.
Prije nego što započnemo s konfiguracijom, želio bih se ukratko podsjetiti na osnovne vrste balansiranja.

Teorija

Sva današnja rješenja za uravnoteženje opterećenja obično se dijele u dvije kategorije: uravnoteženje na četvrtom (transportnom) i sedmom (aplikacijskom) sloju modela OSI. OSI model nije najbolja referentna točka prilikom opisivanja metoda balansiranja. Na primjer, ako L4 balancer podržava TLS terminaciju, postaje li on tada L7 balancer? No, to je tako.

• L4 balancer najčešće predstavlja srednji proxy koji se nalazi između klijenta i skupa dostupnih backendova, koji terminira TCP veze (odnosno sam odgovara na SYN), bira backend i inicira novu TCP sesiju prema njemu, šaljući SYN samostalno. Ova vrsta je jedna od osnovnih, moguće su i druge varijante.
• L7 balancer distribuira promet među dostupnim backendovima na „složeniji“ način nego što to čini L4 balancer. Može donositi odluke o odabiru backend-a na temelju, na primjer, sadržaja HTTP poruke (URL adresa, kolačići itd.).

Neovisno o vrsti, balancer može podržavati sljedeće funkcije:

• Otkrivanje servisa – proces utvrđivanja skupa dostupnih backendova (Static, DNS, Consul, Etcd itd.).
• Provjera funkcionalnosti otkrivenih backendova (aktivno „pinganje“ backend-a putem HTTP zahtjeva, pasivno otkrivanje problema u TCP vezama, prisutnost više uzastopnih 503 HTTP koda u odgovorima itd.).
• Samo balansiranje (round robin, nasumični odabir, hash izvorne IP adrese, URI).
• Terminacija TLS-a i verifikacija certifikata.
• Opcije vezane uz sigurnost (autentifikacija, prevencija DoS napada, ograničenje brzine) i još mnogo toga.

NSX Edge nudi podršku za dva moda implementacije balancer-a:

Proxy način, ili one-arm. U ovom režimu, NSX Edge koristi svoju IP adresu kao adresu izvora kada šalje zahtjev jednom od backendova. Tako balancer istovremeno obavlja funkcije Source i Destination NAT. Backend vidi sav promet kao da je poslan s balancera i izravno mu odgovara. U toj shemi, balancer mora biti u istom mrežnom segmentu s internim serverima.

Evo kako to funkcionira:
1.       Korisnik šalje zahtjev na VIP adresu (adresu balancera) koja je konfigurirana na Edge.
2.       Edge bira jedan od backendova i izvršava destination NAT, zamjenjujući VIP adresu adresom odabranog backend.
3.       Edge izvršava source NAT, zamjenjujući adresu korisnika koji je poslao zahtjev svojom vlastitom.
4.       Paketa se šalje odabranom backendu.
5.       Backend ne odgovara izravno korisniku, već Edge-u, budući da je izvorna adresa korisnika promijenjena na adresu balancera.
6.       Edge prosljeđuje odgovor servera korisniku.
Shema ispod.


Transparentan ili inline režim. U ovom scenariju, balancer ima sučelja u unutarnjoj i vanjskoj mreži. Pristup unutarnjoj mreži nije izravan iz vanjske. Ugrađeni balansirnik opterećenja djeluje kao NAT gateway za virtualne mašine u unutrašnjoj mreži.

Mehanizam je sljedeći:
1.       Korisnik šalje zahtjev na VIP adresu (adresu balancera) koja je konfigurirana na Edge.
2.       Edge bira jedan od backendova i izvršava destination NAT, zamjenjujući VIP adresu adresom odabranog backend.
3.       Paketa se šalje odabranom backendu.
4.       Backend primi zahtjev s izvornoj adresom korisnika (source NAT nije izvršen) i odgovara mu izravno.
5.       Promet ponovo prihvaća balancer opterećenja, budući da u inline shemi obično djeluje kao zadani gateway za farmu servera.
6.       Edge izvršava source NAT za slanje prometa korisniku, koristeći svoj VIP kao source IP adresu.
Shema ispod.

Praksa

Na mom testnom okviru konfigurirana su 3 servera s Apache-om, koji je podešen za rad putem HTTPS-a. Edge će vršiti balansiranje HTTPS zahtjeva metodom round robin, proksirajući svaki novi zahtjev na novi server.
Krenimo.

Generiramo SSL certifikat koji će koristiti NSX Edge.
Možete uvesti valjani CA certifikat ili koristiti samopotpisani. U ovom testu koristit ću samopotpisani.

1. U sučelju vCloud Director odlazimo na postavke usluga Edge.
   
2. Odlazimo na karticu Certifikati. Iz padajućeg izbornika odabiremo dodavanje novog CSR-a.
   
3. Ispunjavamo potrebna polja i kliknemo na Keep.
   
4. Odabiremo upravo kreirani CSR i biramo opciju self-sign CSR.
   
5. Odabiremo trajanje valjanosti certifikata i kliknemo na Keep.
   
6. Samo potpisani certifikat pojavljuje se na popisu dostupnih.
   

Konfiguriramo Application Profile.
Application profili pružaju potpuniju kontrolu nad mrežnim prometom i olakšavaju upravljanje istim. Pomoću njih možemo odrediti ponašanje za određene tipove prometa.

1. Idemo na karticu Load Balancer i uključujemo ravnotežu opterećenja. Opcija Acceleration enabled ovdje omogućuje ravnoteži opterećenja da koristi bržu L4 ravnotežu umjesto L7.
   
2. Idemo na karticu Application profile kako bismo postavili profil aplikacije. Kliknite +.
   
3. Postavljamo naziv profila i biramo tip prometa kojem će se profil primijeniti. Objasnit ću neke parametre.
   Persistence – čuva i prati podatke sesije, na primjer: koji točno poslužitelj iz grupe obrađuje korisnički zahtjev. Ovo jamči da se korisnički zahtjevi šalju istoj članici grupe tijekom trajanja sesije ili sljedećih sesija.
   Enable SSL passthrough – odabirom ove opcije NSX Edge prestaje terminirati SSL. Umjesto toga, terminacija se događa izravno na poslužiteljima za koje se obavlja ravnoteža.
   Insert X-Forwarded-For HTTP header – omogućuje identifikaciju izvorne IP adrese klijenta koji se povezuje s web poslužiteljem putem ravnoteže opterećenja.
   Enable Pool Side SSL – označava da odabrana grupa sastoji se od HTTPS poslužitelja.
   
4. Budući da ću ravnotežiti HTTPS promet, potrebno je uključiti Pool Side SSL i odabrati prethodno generirani certifikat na kartici Virtual Server Certificates —> Service Certificate.
   
5. Slično za Pool Certificates —> Service Certificate.
   

Stvaramo grupu poslužitelja čiji će promet biti ravnotežen Pools.

1. Idemo na karticu Pools. Kliknemo +.
   
2. Postavljamo naziv grupe, biramo algoritam (ja ću koristiti round robin) i tip praćenja za health check pozadine. Opcija Transparent označava da li izvorni IP klijenata vidi interni poslužitelj.
   • Ako je opcija isključena, promet za interne poslužitelje dolazi s IP adrese ravnoteže.
   • Ako je opcija uključena, interni poslužitelji vide izvorni IP klijenata. U takvoj konfiguraciji NSX Edge mora biti zadani pristupnik kako bi se osiguralo da se vraćeni paketi šalju kroz NSX Edge.

   NSX podržava sljedeće algoritme balansiranja:

   • IP_HASH – odabir poslužitelja na temelju rezultata funkcije raspršenja za source i destination IP svakog paketa.
   • LEASTCONN – balansiranje ulaznih veza, ovisno o broju već postojećih na određenom poslužitelju. Nove veze će se usmjeriti na poslužitelj s najmanje veza.
   • ROUND_ROBIN – nove veze se šalju na svaki poslužitelj redoslijedom, prema unaprijed određenoj težini.
   • URI – lijeva strana URI (prije upitnika) se hashira i dijeli na ukupnu težinu poslužitelja u bazenu. Rezultat ukazuje koji poslužitelj prima zahtjev, osiguravajući da se zahtjev uvijek šalje na isti poslužitelj, sve dok svi poslužitelji ostaju dostupni.
   • HTTPHEADER – balansiranje na temelju određenog HTTP zaglavlja koje se može odrediti kao parametar. Ako zaglavlje nedostaje ili nema nikakvu vrijednost, primjenjuje se algoritam ROUND_ROBIN.
   • URL – u svakom HTTP GET zahtjevu pretražuje se po parametru URL, navedenom kao argument. Ako iza parametra slijedi znak jednakosti i vrijednost, onda se vrijednost hashira i dijeli na ukupnu težinu aktivnih poslužitelja. Rezultat ukazuje koji poslužitelj prima zahtjev. Ovaj proces se koristi za praćenje identifikatora korisnika u zahtjevima i osiguranje da se isti user id uvijek šalje na isti poslužitelj, sve dok svi poslužitelji ostaju dostupni.

   

3. U bloku Members kliknemo + za dodavanje poslužitelja u bazen.
   
   
   Ovdje treba navesti:
   • ime poslužitelja;
   • IP adresa poslužitelja;
   • port na koji će poslužitelj primati promet;
   • port za health check (Monitor healthcheck);
   • težina (Weight) – pomoću ovog parametra može se regulirati proporcionalna količina prometa za određenog člana bazena;
   • Max Connections – maksimalan broj veza na poslužitelj;
   • Min Connections – minimalan broj veza koje poslužitelj mora obraditi prije nego što se promet prebaci na sljedećeg člana bazena.

   
   
   Ovako izgleda konačni bazen od tri poslužitelja.
   

Dodajemo Virtual Server

1. Prelazimo na karticu Virtual Servers. Kliknemo +.
   
2. Aktiviramo virtualni poslužitelj pomoću Enable Virtual Server.
   Postavljamo mu ime, biramo prethodno stvoreni Application Profile, Pool i određujemo IP adresu na koju će Virtual Server primati zahtjeve izvana. Određujemo protokol HTTPS i port 443.
   Opcionalni parametri ovdje:
   Ograničenje veze – maksimalni broj istovremenih veza koje virtualni server može obraditi;
   Ograničenje brzine veze (CPS) – maksimalni broj novih ulaznih zahtjeva u sekundi.
   

Na ovoj konfiguraciji balansera je gotovo, možemo provjeriti njegovu funkcionalnost. Serveri imaju jednostavnu konfiguraciju koja omogućava razumijevanje kojim je točno serverom iz poola obrađen zahtjev. Tijekom konfiguracije odabrali smo algoritam uravnoteženja Round Robin, a parametar Weight za svaki server iznosi jedan, tako da će svaki sljedeći zahtjev biti obrađen sljedećim serverom iz poola.
Upisujemo vanjsku adresu balansirača u pregledniku i vidimo:


Nakon ponovnog učitavanja stranice, zahtjev će biti obrađen sljedećim serverom:


Još jednom – da provjerimo i treći server iz poola:


Tijekom provjere možemo vidjeti da je certifikat koji nam šalje Edge onaj koji smo generirali na samom početku.

Provjera statusa balansirača iz konzole Edge gateway. Za to unesite show service loadbalancer pool.


Konfiguriramo Service Monitor za provjeru stanja servera u poolu
Pomoću Service Monitora možemo pratiti stanje servera u backend poolu. Ako odgovor na zahtjev ne odgovara očekivanju, server se može izbaciti iz poola kako ne bi primao nove zahtjeve.
Po defaultu su konfigurirane tri metode provjere:

• TCP-monitor,
• HTTP-monitor,
• HTTPS-monitor.

Napravimo novi.

1. Prelazimo na karticu Service Monitoring, kliknemo +.
   
2. Biramo:
   • ime za novu metodu;
   • interval s kojim će se slati zahtjevi,
   • timeout za čekanje odgovora,
   • tip monitoringa – HTTPS zahtjev koristeći metodu GET, očekivani statusni kod – 200(OK) i URL zahtjeva.
3. S ovim je konfiguracija novog Service Monitora završena, sada ga možemo koristiti prilikom stvaranja poola.
   

Konfiguriramo Application Rules

Application Rules – način manipulacije prometom temeljen na određenim okidačima. Pomoću ovog alata možemo stvoriti napredna pravila uravnoteženja opterećenja, čija konfiguracija možda neće biti moguća putem Application profiles ili drugih usluga dostupnih na Edge Gateway.

1. Da bismo stvorili pravilo, idemo na karticu Application Rules balansatora.
   
2. Odabiremo ime, skript koji će koristiti pravilo i pritisnemo Keep.
   
3. Nakon što je pravilo stvoreno, trebamo urediti već postavljeni Virtual Server.
   
4. Na kartici Advanced dodajemo pravilo koje smo stvorili.
   

U gornjem primjeru omogućili smo podršku za tlsv1.

Još nekoliko primjera:

Preusmjeravanje prometa u drugi bazen.
Pomoću ovog skripta možemo preusmjeriti promet u drugi bazen ravnoteže, ako glavni bazen ne radi. Da bi pravilo radilo, na balansatoru mora biti konfigurirano više bazena, a svi članovi glavnog bazena trebaju biti u stanju down. Treba navesti ime bazena, a ne njegov ID.

acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME


Preusmjeravanje prometa na vanjski resurs.
Ovdje preusmjeravamo promet na vanjsku web stranicu, ako su svi sudionici glavnog bazena u stanju down.

acl pool_down nbsrv(NAME_OF_POOL) eq 0
preusmjeri lokaciju http://www.example.com ako je pool_down

Još više primjera ovdje.

To je sve o balansatoru. Ako imate pitanja, slobodno pitajte, spreman sam odgovoriti.

Izvor: habr.com