VMware NSX za najmlađe. Dio 5: Konfiguriranje balansera opterećenja

Prvi dio. uvodni
Drugi dio. Konfiguriranje zaštitnog zida i NAT pravila
Treći dio. Konfiguriranje DHCP-a
Četvrti dio. Routing setup

Prošli put smo govorili o mogućnostima NSX Edge-a u smislu statičkog i dinamičkog rutiranja, a danas ćemo se pozabaviti balansiranjem opterećenja.
Prije nego što počnemo s postavljanjem, želio bih vas ukratko podsjetiti na glavne vrste balansiranja.

Teorija

Sva današnja rješenja za balansiranje tereta najčešće se dijele u dvije kategorije: balansiranje na četvrtom (transport) i sedmom (aplikacioni) nivou modela ILI AKO. OSI model nije najbolja referentna tačka kada se opisuje metode balansiranja. Na primjer, ako L4 balanser također podržava TLS terminaciju, da li onda postaje L7 balanser? Ali to je ono što jeste.

• Balanser L4 najčešće je to srednji proxy koji stoji između klijenta i skupa dostupnih pozadina, koji prekida TCP veze (tj. nezavisno odgovara na SYN), bira backend i pokreće novu TCP sesiju u njegovom pravcu, nezavisno šaljući SYN. Ovaj tip je jedan od osnovnih, moguće su i druge opcije.
• Balanser L7 distribuira saobraćaj preko dostupnih backend-ova „sofisticiranije“ od L4 balansera. Može odlučiti koji backend odabrati na osnovu, na primjer, sadržaja HTTP poruke (URL, kolačić, itd.).

Bez obzira na tip, balanser može podržati sljedeće funkcije:

• Otkrivanje usluge je proces određivanja skupa dostupnih pozadina (Static, DNS, Consul, Etcd, itd.).
• Provjera funkcionalnosti otkrivenih backenda (aktivan „ping“ backend-a pomoću HTTP zahtjeva, pasivno otkrivanje problema u TCP konekcijama, prisustvo nekoliko 503 HTTP kodova u odgovorima itd.).
• Samo balansiranje (round robin, slučajni odabir, izvorni IP hash, URI).
• TLS prestanak i provjera certifikata.
• Sigurnosne opcije (autentifikacija, prevencija DoS napada, ograničenje brzine) i još mnogo toga.

NSX Edge nudi podršku za dva načina implementacije balansera opterećenja:

Proxy način rada ili jednoručni. U ovom režimu, NSX Edge koristi svoju IP adresu kao izvornu adresu kada šalje zahtev jednom od pozadinskih delova. Dakle, balanser istovremeno obavlja funkcije izvornog i odredišnog NAT-a. Backend vidi sav promet kao poslan iz balansera i odgovara direktno na njega. U takvoj šemi, balanser mora biti u istom segmentu mreže sa internim serverima.

Evo kako to ide:
1. Korisnik šalje zahtjev na VIP adresu (adresu balansera) koja je konfigurisana na Edge-u.
2. Edge bira jedan od backend-a i izvodi odredišni NAT, zamjenjujući VIP adresu adresom odabranog backenda.
3. Edge izvodi izvorni NAT, zamjenjujući adresu korisnika koji je poslao zahtjev svojom.
4. Paket se šalje odabranom backendu.
5. Backend ne odgovara direktno korisniku, već Edgeu, pošto je originalna adresa korisnika promijenjena u adresu balansera.
6. Edge prenosi odgovor servera korisniku.
Dijagram je ispod.


Transparentni ili inline način rada. U ovom scenariju, balanser ima sučelja na internoj i eksternoj mreži. Istovremeno, iz eksterne mreže nema direktnog pristupa internoj mreži. Ugrađeni balansator opterećenja djeluje kao NAT gateway za virtuelne mašine na internoj mreži.

Mehanizam je sljedeći:
1. Korisnik šalje zahtjev na VIP adresu (adresu balansera) koja je konfigurisana na Edge-u.
2. Edge bira jedan od backend-a i izvodi odredišni NAT, zamjenjujući VIP adresu adresom odabranog backenda.
3. Paket se šalje odabranom backendu.
4. Backend prima zahtjev s originalnom adresom korisnika (izvorni NAT nije obavljen) i odgovara direktno na njega.
5. Saobraćaj je ponovo prihvaćen od strane balansera opterećenja, pošto u inline šemi obično deluje kao podrazumevani gateway za farmu servera.
6. Edge izvodi izvorni NAT da pošalje promet korisniku, koristeći svoj VIP kao izvornu IP adresu.
Dijagram je ispod.

Praksa

Moja testna klupa ima 3 servera koji koriste Apache, koji je konfigurisan da radi preko HTTPS-a. Edge će izvršiti kružno balansiranje HTTPS zahtjeva, proxy svaki novi zahtjev na novi server.
Počnimo.

Generisanje SSL sertifikata koji će koristiti NSX Edge
Možete uvesti važeći CA certifikat ili koristiti samopotpisani. Za ovaj test ću koristiti self-signed.

1. U interfejsu vCloud Director idite na postavke Edge usluga.
   
2. Idite na karticu Certifikati. Sa liste radnji izaberite dodavanje novog CSR-a.
   
3. Popunite potrebna polja i kliknite Zadrži.
   
4. Odaberite novokreirani CSR i odaberite opciju samopotpisa.
   
5. Odaberite period važenja certifikata i kliknite Zadrži
   
6. Samopotpisani certifikat se pojavljuje na listi dostupnih.
   

Postavljanje profila aplikacije
Profili aplikacija vam daju potpuniju kontrolu nad mrežnim prometom i čine upravljanje jednostavnim i efikasnim. Mogu se koristiti za definiranje ponašanja za određene vrste prometa.

1. Idite na karticu Load Balancer i omogućite balansiranje. Opcija omogućena za ubrzanje ovdje omogućava balanseru da koristi brže balansiranje L4 umjesto L7.
   
2. Idite na karticu Profil aplikacije da postavite profil aplikacije. Kliknite na +.
   
3. Postavite naziv profila i odaberite vrstu saobraćaja za koji će se profil primijeniti. Dozvolite mi da objasnim neke parametre.
   upornost – pohranjuje i prati podatke o sesiji, na primjer: koji specifični poslužitelj u bazenu servisira korisnički zahtjev. Ovo osigurava da se zahtjevi korisnika usmjeravaju na istog člana spremišta za vrijeme trajanja sesije ili sljedećih sesija.
   Omogući SSL prolaz – Kada je ova opcija odabrana, NSX Edge prestaje da prekida SSL. Umjesto toga, prekid se događa direktno na serverima koji se balansiraju.
   Umetnite X-Forwarded-For HTTP zaglavlje – omogućava vam da odredite izvornu IP adresu klijenta koji se povezuje na web server preko balansera opterećenja.
   Omogući SSL na strani bazena – omogućava vam da navedete da se odabrani skup sastoji od HTTPS servera.
   
4. Budući da ću balansirati HTTPS promet, moram omogućiti SSL na strani bazena i odabrati prethodno generirani certifikat na kartici Virtual Server Certificates -> Service Certificate.
   
5. Slično za Pool Certificate -> Service Certificate.
   

Kreiramo skup servera čiji će promet biti balansirani Pulovi

1. Idite na karticu Pools. Kliknite na +.
   
2. Postavljamo ime bazena, biramo algoritam (koristit ću round robin) i tip nadzora za pozadinu provjere zdravlja. Opcija Transparentna pokazuje da li su početni izvorni IP-ovi klijenata vidljivi internim serverima.
   • Ako je opcija onemogućena, promet za interne servere dolazi sa izvorne IP adrese balansera.
   • Ako je opcija omogućena, interni serveri vide izvornu IP adresu klijenata. U ovoj konfiguraciji, NSX Edge mora djelovati kao default gateway kako bi se osiguralo da vraćeni paketi prolaze kroz NSX Edge.

   NSX podržava sljedeće algoritme balansiranja:

   • IP_HASH – odabir servera na osnovu rezultata hash funkcije za izvornu i odredišnu IP adresu svakog paketa.
   • LEASTCONN – balansiranje dolaznih veza u zavisnosti od broja koji je već dostupan na određenom serveru. Nove veze će biti usmjerene na server s najmanje konekcija.
   • ROUND_ROBIN – nove veze se šalju svakom serveru redom, u skladu sa težinom koja mu je dodeljena.
   • URI – lijevi dio URI-ja (prije upitnika) se hešira i dijeli sa ukupnom težinom servera u grupi. Rezultat pokazuje koji server prima zahtjev, osiguravajući da se zahtjev uvijek usmjerava na isti server, sve dok svi serveri ostaju dostupni.
   • HTTPHEADER – balansiranje zasnovano na specifičnom HTTP zaglavlju, koje se može specificirati kao parametar. Ako zaglavlje nedostaje ili nema nikakvu vrijednost, primjenjuje se algoritam ROUND_ROBIN.
   • URL – Svaki HTTP GET zahtjev traži URL parametar naveden kao argument. Ako parametar prati znak jednakosti i vrijednost, tada se vrijednost raspršuje i dijeli s ukupnom težinom pokrenutih servera. Rezultat pokazuje koji server prima zahtjev. Ovaj proces se koristi za praćenje korisničkih ID-ova u zahtjevima i osiguravanje da se isti korisnički ID uvijek šalje na isti server, sve dok su svi serveri dostupni.

   

3. U bloku Članovi kliknite + da dodate servere u skup.
   
   
   Ovdje trebate navesti:
   • ime servera;
   • IP adresa servera;
   • port na kojem će server primati promet;
   • port za provjeru zdravlja (Monitor healthcheck);
   • težina – pomoću ovog parametra možete podesiti proporcionalnu količinu primljenog prometa za određenog člana grupe;
   • Max Connections – maksimalni broj konekcija na server;
   • Min. Connections – minimalni broj veza koje server mora obraditi prije nego što se promet prosljeđuje sljedećem članu spremišta.

   
   
   Ovako izgleda konačni skup od tri servera.
   

Dodavanje virtuelnog servera

1. Idite na karticu Virtuelni serveri. Kliknite na +.
   
2. Aktiviramo virtuelni server koristeći Enable Virtual Server.
   Dajemo mu ime, biramo prethodno kreirani Profil aplikacije, Pool i označavamo IP adresu na koju će Virtuelni server primati zahtjeve izvana. Navodimo HTTPS protokol i port 443.
   Opcioni parametri ovdje:
   Ograničenje veze – maksimalan broj istovremenih veza koje virtuelni server može obraditi;
   Ograničenje brzine veze (CPS) – maksimalan broj novih dolaznih zahtjeva u sekundi.
   

Ovo završava konfiguraciju balansera; možete provjeriti njegovu funkcionalnost. Serveri imaju jednostavnu konfiguraciju koja vam omogućava da shvatite koji je server iz skupa obradio zahtjev. Prilikom podešavanja odabrali smo Round Robin algoritam balansiranja, a parametar Weight za svaki server je jednak jedan, tako da će svaki sljedeći zahtjev obraditi sljedeći server iz pula.
U pretraživač unosimo eksternu adresu balansera i vidimo:


Nakon osvježavanja stranice, zahtjev će obraditi sljedeći server:


I opet - da provjerite treći server iz bazena:


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

Provjera statusa balansera iz Edge gateway konzole. Da biste to učinili, unesite show service loadbalancer pool.


Konfiguriranje Service Monitora za provjeru statusa servera u spremištu
Koristeći Service Monitor možemo pratiti status servera u backend bazenu. Ako odgovor na zahtjev nije kako se očekivalo, server se može ukloniti iz spremišta tako da ne prima nove zahtjeve.
Podrazumevano su konfigurisana tri načina provjere:

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

Kreirajmo novu.

1. Idite na karticu Nadgledanje usluge, kliknite na +.
   
2. Odaberite:
   • naziv za novu metodu;
   • interval u kojem će se zahtjevi slati,
   • vremensko ograničenje čekanja na odgovor,
   • tip praćenja – HTTPS zahtjev koristeći GET metodu, očekivani statusni kod – 200(OK) i URL zahtjeva.
3. Ovim je završeno postavljanje novog servisnog monitora; sada ga možemo koristiti prilikom kreiranja bazena.
   

Postavljanje pravila aplikacije

Pravila aplikacije su način da se manipuliše saobraćajem na osnovu određenih pokretača. Pomoću ovog alata možemo kreirati napredna pravila za balansiranje opterećenja koja možda neće biti moguća kroz profile aplikacije ili druge usluge dostupne na Edge Gateway-u.

1. Da kreirate pravilo, idite na karticu Pravila aplikacije u balanseru.
   
2. Odaberite ime, skriptu koja će koristiti pravilo i kliknite Zadrži.
   
3. Nakon kreiranja pravila, potrebno je da uredimo već konfigurisani virtuelni server.
   
4. Na kartici Napredno dodajte pravilo koje smo kreirali.
   

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

Još par primjera:

Preusmjerite promet na drugi bazen.
Pomoću ove skripte možemo preusmjeriti promet na drugi balansirajući bazen ako je glavni skup nestao. Da bi pravilo funkcioniralo, višestruki skupovi moraju biti konfigurirani na balanseru i svi članovi glavnog spremišta moraju biti u neaktivnom stanju. Morate 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


Preusmjerite promet na vanjski resurs.
Ovdje preusmjeravamo promet na vanjsku web stranicu ako svi članovi glavnog skupa ne rade.

acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down

Još više primjera ovdje.

To je sve za mene u vezi balansera. Ako imate pitanja, pitajte, spreman sam odgovoriti.

izvor: www.habr.com