Minule jsme si povídali o schopnostech NSX Edge z hlediska statického a dynamického směrování a dnes se budeme zabývat load balancerem.
Než se pustíme do nastavování, rád bych vám krátce připomněl hlavní typy vyvažování.
Teorie
Všechna dnešní řešení vyvažování užitečného zatížení se nejčastěji dělí do dvou kategorií: vyvažování na čtvrté (přepravní) a sedmé (aplikační) úrovni modelu . Model OSI není nejlepším referenčním bodem při popisu metod vyvažování. Pokud například balancer L4 podporuje také ukončení TLS, stane se pak balancerem L7? Ale je to, co to je.
- Balancer L4 nejčastěji se jedná o prostřední proxy stojící mezi klientem a sadou dostupných backendů, která ukončí TCP spojení (tedy samostatně reaguje na SYN), vybere backend a zahájí novou TCP relaci v jeho směru, nezávisle na odeslání SYN. Tento typ je jedním ze základních, jsou možné i další možnosti.
- Balancer L7 distribuuje provoz mezi dostupné backendy „sofistikovanější“ než balancér L4. Může se rozhodnout, který backend zvolit, například na základě obsahu HTTP zprávy (URL, cookie atd.).
Bez ohledu na typ může balancer podporovat následující funkce:
- Zjišťování služby je proces určování sady dostupných backendů (Static, DNS, Consul, Etcd atd.).
- Kontrola funkčnosti detekovaných backendů (aktivní „ping“ backendu pomocí HTTP požadavku, pasivní detekce problémů v TCP spojení, přítomnost několika 503 HTTP kódů v odpovědích atd.).
- Samotné vyvažování (round robin, náhodný výběr, zdrojová IP hash, URI).
- Ukončení TLS a ověření certifikátu.
- Možnosti související se zabezpečením (autentizace, prevence DoS útoků, omezení rychlosti) a mnoho dalšího.
NSX Edge nabízí podporu pro dva režimy nasazení nástroje pro vyrovnávání zatížení:
Proxy režim, nebo jednoručka. V tomto režimu používá NSX Edge svou IP adresu jako zdrojovou adresu při odesílání požadavku na jeden z backendů. Balancér tedy současně vykonává funkce Source a Destination NAT. Backend vidí veškerý provoz jako odeslaný z balanceru a přímo na něj reaguje. V takovém schématu musí být balancer ve stejném segmentu sítě jako interní servery.
Funguje to takto:
1. Uživatel odešle požadavek na VIP adresu (adresu balancera), která je nakonfigurována na Edge.
2. Edge vybere jeden z backendů a provede cílové NAT, přičemž nahradí VIP adresu adresou zvoleného backendu.
3. Edge provede zdrojový NAT a nahradí adresu uživatele, který požadavek odeslal, svou vlastní.
4. Balíček je odeslán na vybraný backend.
5. Backend neodpovídá přímo uživateli, ale Edge, protože původní adresa uživatele byla změněna na adresu balanceru.
6. Edge odešle odpověď serveru uživateli.
Schéma je níže.
Transparentní neboli inline režim. V tomto scénáři má balancer rozhraní na interní a externí síti. Zároveň neexistuje přímý přístup do vnitřní sítě z externí. Vestavěný nástroj pro vyrovnávání zatížení funguje jako brána NAT pro virtuální stroje v interní síti.
Mechanismus je následující:
1. Uživatel odešle požadavek na VIP adresu (adresu balancera), která je nakonfigurována na Edge.
2. Edge vybere jeden z backendů a provede cílové NAT, přičemž nahradí VIP adresu adresou zvoleného backendu.
3. Balíček je odeslán na vybraný backend.
4. Backend obdrží požadavek s původní adresou uživatele (zdrojový NAT nebyl proveden) a přímo na něj odpoví.
5. Provoz je opět přijímán nástrojem pro vyrovnávání zatížení, protože v inline schématu obvykle funguje jako výchozí brána pro serverovou farmu.
6. Edge provádí zdrojový NAT pro odesílání provozu k uživateli pomocí jeho VIP jako zdrojové IP adresy.
Schéma je níže.
Praxe
Moje testovací stolice má 3 servery se systémem Apache, který je nakonfigurován pro práci přes HTTPS. Edge bude provádět cyklické vyvažování požadavků HTTPS, přičemž každý nový požadavek přidělí novému serveru.
Pojďme začít.
Generování certifikátu SSL, který bude používat NSX Edge
Můžete importovat platný certifikát CA nebo použít certifikát s vlastním podpisem. Pro tento test použiji self-signed.
- V rozhraní vCloud Director přejděte do nastavení služeb Edge.
- Přejděte na kartu Certifikáty. Ze seznamu akcí vyberte přidání nového CSR.
- Vyplňte požadovaná pole a klikněte na Ponechat.
- Vyberte nově vytvořenou CSR a vyberte možnost CSR s vlastním podpisem.
- Vyberte dobu platnosti certifikátu a klikněte na Ponechat
- Certifikát s vlastním podpisem se zobrazí v seznamu dostupných certifikátů.
Nastavení profilu aplikace
Profily aplikací vám poskytují úplnější kontrolu nad síťovým provozem a zjednodušují a zefektivňují jeho správu. Lze je použít k definování chování pro konkrétní typy provozu.
- Přejděte na kartu Load Balancer a povolte balancer. Volba Acceleration enabled zde umožňuje balanceru používat rychlejší vyvažování L4 místo L7.
- Přejděte na kartu Profil aplikace a nastavte profil aplikace. Klikněte na +.
- Nastavte název profilu a vyberte typ provozu, pro který bude profil použit. Dovolte mi vysvětlit některé parametry.
Perzistence – ukládá a sleduje data relace, například: který konkrétní server ve fondu obsluhuje požadavek uživatele. To zajišťuje, že požadavky uživatelů jsou směrovány do stejného člena fondu po celou dobu trvání relace nebo následujících relací.
Povolit průchod SSL – Když je vybrána tato možnost, NSX Edge přestane ukončovat SSL. Místo toho dojde k ukončení přímo na serverech, které jsou vyrovnávány.
Vložte X-Forwarded-For HTTP hlavičku – umožňuje určit zdrojovou IP adresu klienta připojujícího se k webovému serveru prostřednictvím nástroje pro vyrovnávání zatížení.
Povolit protokol SSL na straně fondu – umožňuje určit, že vybraný fond se skládá ze serverů HTTPS.
- Vzhledem k tomu, že budu vyvažovat HTTPS provoz, musím povolit Pool Side SSL a vybrat dříve vygenerovaný certifikát v záložce Certifikáty virtuálního serveru -> Servisní certifikát.
- Podobně pro Pool Certificates -> Service Certificate.
Vytváříme pool serverů, provoz na kterých bude vyvážený pooly
- Přejděte na kartu Bazény. Klikněte na +.
- Nastavíme název poolu, vybereme algoritmus (použiji round robin) a typ monitoringu pro backend kontroly stavu Volba Transparent udává, zda jsou počáteční zdrojové IP klientů viditelné pro interní servery.
- Pokud je tato možnost zakázána, provoz pro interní servery pochází ze zdrojové IP balanceru.
- Pokud je tato možnost povolena, interní servery uvidí zdrojovou IP adresu klientů. V této konfiguraci musí NSX Edge fungovat jako výchozí brána, aby bylo zajištěno, že vrácené pakety projdou přes NSX Edge.
NSX podporuje následující vyvažovací algoritmy:
- IP_HASH – výběr serveru na základě výsledků hashovací funkce pro zdrojovou a cílovou IP každého paketu.
- LEASTCONN – vyrovnávání příchozích spojení v závislosti na počtu již dostupných na konkrétním serveru. Nová připojení budou přesměrována na server s nejmenším počtem připojení.
- ROUND_ROBIN – nová spojení jsou postupně odesílána na každý server podle váhy, která je mu přidělena.
- URI – levá část URI (před otazníkem) je hašována a vydělena celkovou hmotností serverů ve fondu. Výsledek ukazuje, který server obdrží požadavek, což zajišťuje, že požadavek je vždy směrován na stejný server, pokud všechny servery zůstanou dostupné.
- HTTPHEADER – balancování na základě specifické HTTP hlavičky, kterou lze zadat jako parametr. Pokud záhlaví chybí nebo nemá žádnou hodnotu, použije se algoritmus ROUND_ROBIN.
- URL – Každý požadavek HTTP GET hledá parametr URL zadaný jako argument. Pokud za parametrem následuje rovnítko a hodnota, je hodnota hašována a vydělena celkovou váhou běžících serverů. Výsledek ukazuje, který server obdrží požadavek. Tento proces se používá ke sledování ID uživatelů v požadavcích a zajištění toho, že stejné ID uživatele bude vždy odesláno na stejný server, pokud všechny servery zůstanou dostupné.
- V bloku Členové klikněte na + a přidejte servery do fondu.
Zde je třeba uvést:- název serveru;
- IP adresa serveru;
- port, na kterém bude server přijímat provoz;
- port pro kontrolu stavu (Monitor healthcheck);
- váha – pomocí tohoto parametru můžete upravit poměrné množství přijatého provozu pro konkrétního člena fondu;
- Max připojení – maximální počet připojení k serveru;
- Minimální počet připojení – minimální počet připojení, která musí server zpracovat, než je provoz předán dalšímu členovi fondu.
Takto vypadá konečný fond tří serverů.
Přidání virtuálního serveru
- Přejděte na kartu Virtuální servery. Klikněte na +.
- Virtuální server aktivujeme pomocí Enable Virtual Server.
Dáme mu název, vybereme dříve vytvořený profil aplikace, fond a označíme IP adresu, na kterou bude virtuální server přijímat požadavky zvenčí. Uvádíme protokol HTTPS a port 443.
Volitelné parametry zde:
Limit připojení – maximální počet současných připojení, které může virtuální server zpracovat;
Limit rychlosti připojení (CPS) – maximální počet nových příchozích požadavků za sekundu.
Tím je konfigurace balanceru dokončena a můžete zkontrolovat jeho funkčnost. Servery mají jednoduchou konfiguraci, která vám umožní pochopit, který server z fondu zpracoval požadavek. Při nastavování jsme zvolili vyrovnávací algoritmus Round Robin a parametr Weight pro každý server je roven jedné, takže každý následující požadavek bude zpracován dalším serverem z fondu.
Zadáme externí adresu balanceru do prohlížeče a uvidíme:
Po obnovení stránky bude požadavek zpracován následujícím serverem:
A znovu - pro kontrolu třetího serveru z fondu:
Při kontrole vidíte, že certifikát, který nám Edge posílá, je stejný, který jsme vygenerovali na samém začátku.
Kontrola stavu balanceru z konzoly brány Edge. Chcete-li to provést, zadejte zobrazit službu loadbalancer pool.
Konfigurace Service Monitor pro kontrolu stavu serverů ve fondu
Pomocí Service Monitor můžeme sledovat stav serverů v backend fondu. Pokud odpověď na požadavek neodpovídá očekávání, může být server vyjmut z fondu, takže nebude přijímat žádné nové požadavky.
Ve výchozím nastavení jsou nakonfigurovány tři způsoby ověření:
- TCP-monitor,
- HTTP monitor,
- HTTPS-monitor.
Pojďme vytvořit nový.
- Přejděte na kartu Sledování služeb a klikněte na +.
- Vybrat:
- název nové metody;
- interval, ve kterém budou žádosti odesílány,
- časový limit čekání na odpověď,
- typ monitorování – požadavek HTTPS metodou GET, očekávaný stavový kód – 200(OK) a URL požadavku.
- Tím je nastavení nového Service Monitoru dokončeno; nyní jej můžeme použít při vytváření fondu.
Nastavení pravidel aplikace
Pravidla aplikací představují způsob, jak manipulovat s provozem na základě určitých spouštěčů. Pomocí tohoto nástroje můžeme vytvořit pokročilá pravidla pro vyrovnávání zátěže, která nemusí být možná prostřednictvím aplikačních profilů nebo jiných služeb dostupných na Edge Gateway.
- Chcete-li vytvořit pravidlo, přejděte na záložku Pravidla aplikace v balanceru.
- Vyberte název, skript, který bude pravidlo používat, a klikněte na Ponechat.
- Po vytvoření pravidla musíme upravit již nakonfigurovaný virtuální server.
- Na kartě Upřesnit přidejte pravidlo, které jsme vytvořili.
Ve výše uvedeném příkladu jsme povolili podporu tlsv1.
Ještě pár příkladů:
Přesměrujte provoz do jiného fondu.
Pomocí tohoto skriptu můžeme přesměrovat provoz do jiného vyrovnávacího fondu, pokud je hlavní fond mimo provoz. Aby pravidlo fungovalo, musí být na balanceru nakonfigurováno více fondů a všichni členové hlavního fondu musí být v neaktivním stavu. Musíte zadat název fondu, nikoli jeho ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Přesměrujte provoz na externí zdroj.
Zde přesměrujeme provoz na externí web, pokud jsou všichni členové hlavního fondu mimo provoz.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Ještě více příkladů .
To je pro mě o balanceru vše. Pokud máte nějaké dotazy, ptejte se, jsem připraven odpovědět.
Zdroj: www.habr.com