Minulý týždeň sme hovorili o možnostiach NSX Edge z pohľadu statického a dynamického routingu, a dnes sa budeme zaoberať vyvažovačom záťaže.
Predtým, ako začneme s nastavením, chcel by som veľmi stručne pripomenúť hlavné typy vyvažovania.
Teória
Všetky dnešné riešenia vyvažovania záťaže sa zvyčajne delia do dvoch kategórií: vyvažovanie na štvrtom (transportnom) a siedmom (aplikovanom) stupni modelu . Model OSI nie je najlepšou referenčnou bodkou pri popisovaní metód vyvažovania. Napríklad, ak L4 vyvažovač podporuje aj termináciu TLS, stáva sa v tom prípade L7 vyvažovačom? Ale čo je, to je.
- Vyvažovač L4 sa zvyčajne nachádza medzi klientom a súborom dostupných backendov ako prostredný proxy, ktorý terminujúcu TCP pripojenia (to znamená, že odpovedá na SYN), vyberá backend a iniciuje voči nemu nové TCP reláciu, pričom posiela SYN. Tento typ je jedným z základných, existujú aj iné varianty.
- Vyvažovač L7 rozdelení prevádzku medzi dostupnými backendmi 'sofistikovanejšie', ako to robí L4 vyvažovač. Môže sa rozhodovať o výbere backendu na základe, napríklad, obsahu správy HTTP (URL adresa, cookie atď.).
Nezávisle od typu môže vyvažovač podporovať nasledujúce funkcie:
- Objavovanie služieb - proces určovania sady dostupných backendov (Static, DNS, Consul, Etcd atď.).
- Kontrola funkčnosti objavených backendov (aktívny 'ping' backendu pomocou HTTP požiadavky, pasívne zisťovanie problémov v TCP pripojeniach, prítomnosť viacerých po sebe idúcich 503 HTTP-kódov v odpovediach atď.).
- Samotné vyvažovanie (round robin, náhodný výber, hash IP adresy, URI).
- Terminácia TLS a overovanie certifikátov.
- Možnosti súvisiace s bezpečnostnými opatreniami (autentifikácia, prevencia DoS útokov, obmedzenie rýchlosti) a mnoho ďalšieho.
NSX Edge ponúka podporu dvoch režimov nasadenia vyvažovača:
Režim proxy, alebo one-armV tomto režime NSX Edge pri zasielaní požiadavky na jeden z backendov používa svoju IP adresu ako adresu zdroja. Takto vyvažovač súčasne vykonáva funkcie Source a Destination NAT. Backend vidí celý prenos ako zaslaný z vyvažovača a odpovedá mu priamo. V takej schéme musí byť vyvažovač v rovnakom sieťovom segmente s vnútornými servermi.
Takto to prebieha:
1. Používateľ zasiela požiadavku na VIP adresu (adresu vyvažovača), ktorá je nakonfigurovaná na Edge.
2. Edge si vyberá jeden z backendov a vykonáva destination NAT, pričom nahrádza VIP adresu adresou vybraného backendu.
3. Edge vykonáva source NAT, pričom nahrádza adresu zasielajúceho používateľa svojou vlastnou.
4. Pakety sú zasielané k vybranému backendu.
5. Backend neodpovedá priamo používateľovi, ale Edge, pretože pôvodná adresa používateľa bola zmenená na adresu vyvažovača.
6. Edge prenáša odpoveď servera používateľovi.
Schéma nižšie.
Priehľadný, alebo inline, režim. V tomto scenári má vyvažovač rozhrania vo vnútorných a vonkajších sieťach. Vnútorná sieť nie je priamo prístupná z vonkajšej strany. Vstavaný vyvažovač záťaže funguje ako NAT brána pre virtuálne stroje vo vnútorných sieťach.
Mechanizmus je nasledujúci:
1. Používateľ zasiela požiadavku na VIP adresu (adresu vyvažovača), ktorá je nakonfigurovaná na Edge.
2. Edge si vyberá jeden z backendov a vykonáva destination NAT, pričom nahrádza VIP adresu adresou vybraného backendu.
3. Pakety sú zasielané k vybranému backendu.
4. Backend prijíma požiadavku s pôvodnou adresou používateľa (source NAT nebol vykonaný) a odpovedá mu priamo.
5. Prenos je opäť prijímaný vyvažovačom záťaže, pretože v inline schéme zvyčajne vystupuje ako predvolená brána pre farmu serverov.
6. Edge vykonáva source NAT na zaslanie prenosu používateľovi, pričom používa svoju VIP ako source IP adresu.
Schéma nižšie.
Praktika
Na mojej testovacej platforme sú nakonfigurované 3 servery s Apache, ktoré sú nastavené na prácu cez HTTPS. Edge bude vykonávať vyvažovanie HTTPS požiadaviek metódou round robin, pričom každý nový požiadavok bude proxyovaný na nový server.
Poďme na to.
Generujeme SSL certifikát, ktorý bude používať NSX Edge.
Môžete importovať platný CA certifikát alebo použiť samopodpísaný. V tomto teste použijem samopodpísaný.
- V rozhraní vCloud Director prejdeme do nastavení služieb Edge.
- Prejdeme na kartu Certifikáty. Z ponuky akcií vyberieme pridanie nového CSR.
- Vyplňte potrebné polia a kliknite na Keep.
- Vyberte práve vytvorený CSR a zvoľte možnosť self-sign CSR.
- Vyberte dobu platnosti certifikátu a kliknite na Keep.
- Samosignovaný certifikát sa objavil v zozname dostupných certifikátov.
Nastavujeme Application Profile.
Application profily poskytujú úplnú kontrolu nad sieťovým prenosom a zjednodušujú oraz efektívne spravovanie. Pomocou nich môžete definovať správanie pre konkrétne typy prenosu.
- Prejdite na kartu Load Balancer a aktivujte vyvažovač. Možnosť Acceleration enabled umožňuje vyvažovaču používať rýchlejšie L4 vyvažovanie namiesto L7.
- Prejdite na kartu Application profile, aby ste nastavili profil aplikácie. Kliknite na +.
- Zadajte názov profilu a vyberte typ prenosu, pre ktorý bude profil použitý. Vysvetlím niektoré parametre.
Persistence – uchováva a sleduje údaje relácie, napríklad: ktorý konkrétny server z poolu obsluhuje požiadavku používateľa. To zabezpečuje, že požiadavky používateľa sú smerované k jednému a tomu istému členovi poolu počas celej doby relácie alebo nasledujúcich relácií.
Enable SSL passthrough – pri zvolení tejto možnosti NSX Edge prestáva terminovať SSL. Namiesto toho sa terminácia uskutočňuje priamo na serveroch, pre ktoré sa vykonáva vyvažovanie.
Insert X-Forwarded-For HTTP header – umožňuje určiť pôvodnú IP adresu klienta, ktorý sa pripája k webovému serveru cez vyvažovač.
Enable Pool Side SSL – umožňuje označiť, že vybraný pool pozostáva z HTTPS serverov.
- Keďže budem vyvažovať HTTPS prenos, je potrebné aktivovať Pool Side SSL a vybrať predtým vygenerovaný certifikát na karte Virtual Server Certificates —> Service Certificate.
- Podobne pre Pool Certificates —> Service Certificate.
Vytvárame pool serverov, ktorého prenos bude vyvažovaný.
- Prejdite na kartu Pools. Kliknite na +.
- Zadajte názov poolu, vyberte algoritmus (budem používať round robin) a typ monitorovania pre health check backendu. Možnosť Transparent určuje, či sú pôvodné source IP klientov viditeľné pre interné servery.
- Ak je možnosť vypnutá, prenos pre interné servery ide s source IP vyvažovača.
- Ak je možnosť zapnutá, interné servery vidia source IP klientov. V takej konfigurácii musí NSX Edge fungovať ako predvolená brána, aby zabezpečilo, že vracajúce pakety prechádzajú cez NSX Edge.
NSX podporuje nasledujúce algoritmy vyvažovania:
- IP_HASH – výber servera na základe výsledkov hash funkcie pre zdrojovú a cieľovú IP adresu každého paketu.
- LEASTCONN – vyvažovanie prichádzajúcich spojení podľa počtu už existujúcich na konkrétnom serveri. Nové spojenia budú smerované na server s najmenším počtom spojení.
- ROUND_ROBIN – nové spojenia sa odosielajú na každý server po poriadku, v súlade s predpísanou hmotnosťou.
- URI – ľavá časť URI (pred otáznikom) sa hash-uje a delí na celkovú hmotnosť serverov v poole. Výsledok určuje, ktorý server dostáva požiadavku, pričom zaručuje, že požiadavka sa vždy smeruje na ten istý server, pokiaľ všetky servery zostávajú dostupné.
- HTTPHEADER – vyvažovanie na základe určitého HTTP hlavičky, ktorú je možné uviesť ako parameter. Ak hlavička chýba alebo nemá hodnotu, aplikuje sa algoritmus ROUND_ROBIN.
- URL – v každej HTTP GET požiadavke sa hľadá podľa parametra URL, uvádzaného ako argument. Ak za parametrom nasleduje znak rovnosti a hodnota, táto hodnota sa hash-uje a delí na celkovú hmotnosť bežiacich serverov. Výsledok určuje, ktorý server dostáva požiadavku. Tento proces sa používa na sledovanie identifikátorov používateľov v požiadavkách a zabezpečuje, aby rovnaký user id vždy putoval na ten istý server, pokiaľ všetky servery zostávajú dostupné.
- V bloku Members klikneme na +, aby sme pridali servery do poolu.
Tu je potrebné uviesť:- názov servera;
- IP adresa servera;
- port, na ktorý server bude prijímať trafic;
- port pre health check (Monitor healthcheck);
- hmotnosť (Weight) – pomocou tohto parametra môžeme regulovať proporcionálne množstvo prijímaného trafficu pre konkrétneho člena poolu;
- Max Connections – maximálny počet spojení k serveru;
- Min Connections – minimálny počet spojení, ktorý musí server spracovať, skôr ako sa traffic presmeruje na nasledujúceho člena poolu.
Takto vyzerá konečný pool z troch serverov.
Pridávame virtuálny server
- Prejdeme na kartu Virtuálne servery. Klikneme na +.
- Aktivujeme virtuálny server pomocou Enable Virtual Server.
Zadáme mu meno, vyberieme predtým vytvorené aplikácie profily, pool a uvedieme IP adresu, na ktorú bude virtuálny server prijímať požiadavky zvonka. Uvedieme protokol HTTPS a port 443.
Voliteľné parametre tu sú:
Limit pripojení – maximálny počet súčasných pripojení, ktoré môže spracovať virtuálny server;
Limit rýchlosti pripojení (CPS) – maximálny počet nových prichádzajúcich požiadaviek za sekundu.
Týmto sa konfigurácia vyvažovača dokončila, môžeme skontrolovať jeho funkčnosť. Servery majú najjednoduchšiu konfiguráciu, ktorá umožňuje pochopiť, ktorým konkrétnym serverom z poolu bola požiadavka spracovaná. Počas nastavenia sme vybrali algoritmus vyvažovania Round Robin a parameter Weight pre každý server je rovný jednej, takže každá ďalšia požiadavka bude spracovaná nasledujúcim serverom z poolu.
Zadáme do prehliadača externú adresu vyvažovača a vidíme:
Po obnovení stránky bude požiadavka spracovaná nasledujúcim serverom:
A ešte raz – aby sme skontrolovali aj tretí server z poolu:
Pri kontrole môžeme vidieť, že certifikát, ktorý nám posiela Edge, je ten istý, ktorý sme generovali na začiatku.
Kontrola stavu vyvažovača z konzoly Edge gateway. Na to zadajte show service loadbalancer pool.
Nastavujeme servisný monitor na kontrolu stavu serverov v poole
S pomocou servisného monitora môžeme sledovať stav serverov v backend poole. Ak odpoveď na požiadavku nezodpovedá očakávanej, server môžeme vyňať z poolu, aby nedostával žiadne nové požiadavky.
Predvolene sú nakonfigurované tri metódy kontroly:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Vytvoríme nový.
- Prejdeme na kartu Service Monitoring, klikneme na +.
- Vyberieme:
- meno pre novú metódu;
- interval, s ktorým budú odosielané požiadavky,
- timeout na čakanie na odpoveď,
- typ monitorovania – HTTPS request s použitím metódy GET, očakávaný status code – 200(OK) a URL požiadavky.
- Týmto sa nastavenie nového servisného monitora skončilo, teraz ho môžeme použiť pri vytváraní poolu.
Nastavujeme aplikačné pravidlá
Aplikačné pravidlá – spôsob manipulácie s prenosom, založený na určitých spúšťačoch. Pomocou tohto nástroja môžeme vytvárať rozšírené pravidlá na vyvažovanie záťaže, ktorých nastavenie môže byť nemožné prostredníctvom aplikačných profilov alebo iných služieb dostupných na Edge Gateway.
- Prejdite na kartu Application Rules vyrovnávača za zaťaženie na vytvorenie pravidla.
- Vyberte názov, skript, ktorý bude pravidlo používať, a kliknite na Keep.
- Po vytvorení pravidla je potrebné upraviť už nastavený Virtual Server.
- Na karte Advanced pridáme vytvorené pravidlo.
V uvedenom príklade sme zapli podporu tlsv1.
Ešte pár príkladov:
Presmerovanie prevádzky do iného poolu.
S týmto skriptom môžeme presmerovať prevádzku do iného vyrovnávacieho poolu, ak hlavný pool nefunguje. Aby pravidlo fungovalo, na vyrovnávači zaťaženia musia byť nakonfigurované viaceré pooly a všetky členy hlavného poolu musia byť v stave down. Je potrebné uviesť presne názov poolu, nie jeho ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Presmerovanie prevádzky na externý zdroj.
Tu presmerovávame prevádzku na externú webovú stránku, ak sú všetci účastníci hlavného poolu v stave down.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Ešte viac príkladov .
Týmto ohľadom mám k vyrovnávaču všetko. Ak máte nejaké otázky, spýtajte sa, som pripravený odpovedať.
Zdroj: habr.com
