V první části tohoto blogu jsme nastavili HAProxy na uzlu Virtual Load Balancer na E2E Cloud. Nakonfigurovali jsme také HAProxy tak, aby směrovalo požadavky na back-endové webové servery pomocí zásad kruhového provozu.
V této druhé a závěrečné části tohoto blogu si projdeme několik pokročilých konfiguračních nastavení, která většina webů vyžaduje:přilnavost relace a zabezpečený přístup k webu pomocí SSL. Než tak učiníme, ukážeme si, jak se naše jediná instance HAProxy může starat o velký web s mnoha webovými aplikacemi na základě ACL. Během toho představíme několik dalších konfiguračních možností, jako je vážená kruhová politika, a na závěr uvedeme odkazy na další důležité úvahy pro produkční nasazení.
Nastavení vyvažování zátěže pro více webových aplikací
Mnoho velkých webových stránek se skládá z několika shluků webových serverů, z nichž každý hostí jinou webovou aplikaci. Například může existovat webová stránka s hlavním obsahem spolu s webovou stránkou pro zábavu a zábavu. HAProxy je schopen směrovat požadavky do správného clusteru na základě vzorů adres URL a Seznamů řízení přístupu (ACL).
Pro ilustraci této schopnosti nejprve vytvoříme dva nové uzly webového serveru v cloudu E2E, pojmenované „webserver3“ a „webserver4“. Jako obvykle nainstalujeme webový server Apache a balíčky PHP na dva nové uzly. Poté nasadíme druhou PHP aplikaci na URL ‚/fun/films.php‘ na pouze tyto dva nově přidané uzly . (Druhá aplikace používá persistenci relace a její funkce budou vysvětleny v další části.)
Na našem řídicím panelu jsou tedy viditelné následující uzly (4 webové servery a nástroj pro vyrovnávání zatížení):
Obrázek 1:Webové servery pro více webových aplikací
HAProxy tedy musí směrovat požadavky klientů na adresu URL ‚/fun/films.php‘ pouze do jednoho z uzlů ‚webserver3‘ a ‚webserver4‘, jinak požadavek nebude možné obsloužit vůbec. Abychom tento požadavek splnili, upravili jsme konfiguraci HAProxy (/etc/haproxy/haproxy.cfg) a vytvořili další backend (pojmenovaný „filmy“), který se skládá pouze ze dvou nových uzlů webového serveru. Toto je doplněk k existujícímu backendu s názvem „site“.
Obrázek 2:Konfigurace backendu pro novou aplikaci
Poté ve stávající konfiguraci frontendu zavedeme ACL, jak je uvedeno níže. To znamená, že jakákoli cesta URL, která začíná na '/fun', bude směrována do backendu s názvem 'films', zatímco ve výchozím nastavení všechny ostatní požadavky přistanou na (již existující) backend s názvem 'site' (sestávající z uzlů pouze 'websrv1' a 'websrv2').
Obrázek 3:Konfigurace frontendu s ACL
Obrázek 4:HAProxy Load-balancing s ACL
Pokročilá nastavení konfigurace
Zásady váženého Round Robin :Při provádění úprav pro ACL jsme zavedli váhu na každý server. Ve výrobě mohou mít různé servery různý výpočetní výkon, takže použití vah umožňuje HAProxy směrovat více požadavků na výkonnější servery. (V našem případě jsou všechny uzly webového serveru podobné a všechny váhy jsou stejné, ale můžeme to použít jako šablonu a vyladit ji v jiném scénáři.)
Maximální počet připojení na server :Za druhé jsme také použili parametr ‚maxconn‘ na úrovni backendového serveru , takže každý server může omezit počet připojení na to, co je přiměřené pro jeho výpočetní výkon. Globální „maxconn“ by mělo být větší než součet hodnot tohoto parametru na úrovni serveru (ponechává určitý prostor pro přidání dalších uzlů webového serveru pro škálovatelnost).
Přilnavost relace
Nová aplikace PHP náhodou používá relace PHP. Pokaždé, když klient přistoupí k této aplikaci, poskytne název oblíbeného filmu (prostřednictvím parametru HTTP GET s názvem ‚fav‘), který se přidá do relace PHP. Server odpoví seznamem oblíbených filmů (jedinečných pro každého klienta), které byly dosud shromážděny.
- session_start();
- $fav =$_GET[‘oblíbený’];
- if ( isset( $_SESSION[‘oblíbené’] ) ) {
- $_SESSION[‘oblíbené’] .=‘ , ‘;
- $_SESSION[‘oblíbené’] .=$fav;
- } jinak {
- $_SESSION[‘oblíbené’] =$fav;
- }
- $msg ='Moje oblíbené filmy:'. $_SESSION[‘oblíbené’];
- ?>
-
Moje oblíbené filmy - echo $msg;
- ?>
Relace PHP mohou být lokální pro instanci webového serveru (pokud není povolena persistence relace nebo replikace). Pokud je tedy stejný klient náhodně nasměrován do různých instancí backendového webového serveru v různých časech, když provede sérii požadavků, data jeho relace se mohou stát nepředvídatelnými. Klient však může být nucen ‚držet se ‘ na jednu instanci webového serveru během trvání relace.
Jedním ze způsobů, jak to nastavit v HAProxy, je zavést parametr ‘appsession’ do příslušné konfigurace backendu (v našem případě ‘filmy’). Různé typy aplikací používají různé HTTP Cookies pro správu relací. V případě aplikací PHP se tento soubor cookie jmenuje „PHPSESSID“. Nastavením „appsession“ spojuje HAProxy s každým jeden webový server „PHPSESSID“ (ta, kde byla tato relace vytvořena) a směruje opakované požadavky klientů obsahující stejné ID relace na stejný webový server, pokud je v provozu nebo pokud vypršel časový limit relace .
- appsession PHPSESSID len 32 timeout 1h
Samozřejmě, pokud se tento webový server z nějakého důvodu stane nedostupným, HAProxy by mělo mít možnost směrovat požadavky se stejným ID relace na jinou aktivní instanci serveru. To lze zajistit přidáním volby ‚redispatch‘ do sekce ‚default‘ konfiguračního souboru HAProxy.
- opětovné odeslání možnosti
Testování
Nyní můžeme testovat jak seznamy ACL, tak stálost relace. Můžeme sledovat HAProxy protokoly na uzlu load-balanceru:
- tail -f /var/log/haproxy.log
Také sledujeme protokoly přístupu k webovému serveru na každém z uzlů „webserver3“ a „webserver4“.
1. tail -f /var/log/apache2/access.log
Ze dvou různých klientských počítačů odesíláme požadavky z prohlížeče na následující adresu URL:http://
V každém požadavku můžeme nastavit jinou hodnotu parametru dotazu s názvem ‚fav‘.
Od prvního klienta zasíláme následující po sobě jdoucí požadavky:
- http://
/fun/films.php?fav=avengers - http://
/fun/films.php?fav=jurassicworld
Okno prohlížeče prvního klienta zobrazí:
Obrázek 5:Jedna klientská relace
Od druhého klienta posíláme následující po sobě jdoucí požadavky:
- http://
/fun/films.php?fav=race3 - http://
/fun/films.php?fav=gold
Okno prohlížeče druhého klienta zobrazí:
Obrázek 6:Další relace klienta
Z odpovědi zobrazené v každém klientském prohlížeči je jasné, že relace jsou v každém případě udržovány správně. Ve Firefoxu z webové konzole můžeme také zkontrolovat hodnoty PHPSESSID.
Z protokolů HAProxy a webového serveru můžeme učinit následující dvě pozorování:
- Tyto požadavky se vzorem adresy URL „/fun“ jsou směrovány do backendu s názvem „pouze filmy“ (zásady ACL)
- Požadavek ze stejné IP adresy klienta přistane na stejném uzlu webového serveru (pevnost relace)
Obrázek 7:Protokoly HAProxy s pevnými relacemi
Obrázek 8:Protokoly přístupu na uzlu webserver3 s pevnými relacemi
Obrázek 9:Protokoly přístupu na uzlu webserver4 s pevnými relacemi
Zabezpečení:Ukončení SSL
Jedna poslední, ale zásadní konfigurace, kterou bychom rádi přijali, se týká zabezpečení. Webové servery Apache lze nakonfigurovat tak, aby podporovaly HTTPS, ale když máme na frontendu nainstalované HAProxy, požadavky klientů přijdou nejprve na nástroj pro vyrovnávání zatížení.
Doporučujeme tedy nakonfigurovat HAProxy na podporu HTTPS. Toto je čtyřstupňový proces:
- Získejte certifikát SSL pro naše webové stránky. Pro experimentální účely jsme vytvořili certifikát s vlastním podpisem s názvem haproxy.pem pomocí openssl
- Připojte rozhraní k portu HTTPS (ve výchozím nastavení 443) a přiřaďte tomuto rozhraní certifikát SSL
- Povolte HAProxy přesměrovat požadavky klientů odeslané přes HTTP na port HTTPS
- Přidejte nebo nastavte požadovaná záhlaví k požadavku HTTP u každého z nakonfigurovaných backendů
První tři výše uvedené kroky jsou implementovány na úrovni frontendu. (Naše rozhraní jsme přejmenovali na ‚alltraffic‘ namísto ‚httptraffic‘.)
Obrázek 10:Konfigurace frontendu pro SSL
Čtvrtý krok výše je implementován u každého backend:
Obrázek 11:Konfigurace backendu pro SSL
Obvykle hlavičky X-Forward-Port a X-Forward-Proto pomáhají aplikaci správně vytvořit adresu URL, když jsou možné požadavky HTTP i HTTPS.
Ukončení SSL v uzlu vyrovnávání zátěže vytváří v tomto uzlu určitou režii zpracování (ve srovnání s předáváním šifrovaného požadavku do backendů). Existuje parametr související s použitým základním šifrovacím algoritmem. Vyšší hodnota zvyšuje režii zpracování na uzlu HAProxy. Lze jej nastavit v sekci ‚global‘ konfigurace HAProxy:
- tune.ssl.default-dh-param 2048
Požadavky šifrované SSL tedy končí na nástroji pro vyrovnávání zatížení, který směruje nešifrované požadavky HTTP na backendové webové servery.
Obrázek 12:Ukončení SSL
Nastavení brány firewall
Potřebujeme otevřít port 443 na uzlu virtuálního nástroje pro vyrovnávání zatížení (běžícím na CentOS) spuštěním příkazu:
- iptables -A INPUT -i eth0 -p tcp –dport 443 -m stav –stav NEW,ESTABLISHED -j ACCEPT
- systemctl restart iptables
Testování
Nyní se pokoušíme přistupovat k naší aplikaci PHP Greeter prostřednictvím prohlížeče (Firefox) tak, že odkazujeme na nezabezpečený HTTP URL:
http://
I poté nás Firefox vyzve k přidání bezpečnostní výjimky, což znamená, že klient je přesměrován na zabezpečenou HTTPS URL . To je také uvedeno v adresním řádku v samotném prohlížeči.
Obrázek 13:Přístup k webové aplikaci přes SSL
Vytváření obrazů strojů a monitorování
Tip :Hodně úsilí bylo vynaloženo na konfiguraci instance virtuálního nástroje pro vyrovnávání zatížení. Obraz stroje tohoto uzlu lze uložit, aby bylo možné v budoucnu vytvářet podobné instance nástroje pro vyrovnávání zátěže pomocí tohoto uzlu jako šablony. Na E2E Cloud toho lze dosáhnout tak, že nejprve vypnete uzel HAProxy a poté uložíte obrázek tohoto uzlu z Dashboardu.
Obrázek 14:Uložení obrazu počítače HAProxy
Obrázek 15:Vytvoření obrazu stroje z uzlu HAProxy
Volitelně lze uložit i strojový obraz instancí webového serveru.
Monitorování pomocí Zabbix :Uzel HAProxy, stejně jako jakýkoli jiný virtuální uzel v cloudu E2E, lze monitorovat pomocí Zabbix. Měli bychom využít této schopnosti.
Obrázek 16:Monitorování stavu nástroje Load Balancer
Závěr a další kroky
E2E Cloud nabízí uzly Virtual Load Balancer pro nastavení vyvažování zátěže pomocí HAProxy. V těchto dvou blozích jsme se zabývali tím, jak lze instalaci HAProxy na E2E Cloud nakonfigurovat tak, aby podporovala vyrovnávání zátěže mezi jednotlivými uživateli pro jednoduché a velké webové stránky s více aplikacemi s lepivostí relace a bezpečným přístupem přes HTTPS.
Tento blog zakončíme tím, že vezmeme na vědomí několik dalších úvah o produkčním nasazení:
- Nejprve by měl být uzel Virtual Load Balancer (a volitelně uzly webového serveru) svázán s doménou pomocí příslušných nastavení DNS
- V souladu s tím by měl být certifikát SSL pro bezpečný přístup k instanci HAProxy vázán na stejnou doménu
- Konečně by se nástroj pro vyrovnávání zatížení neměl stát jediným bodem selhání. Lze tedy doporučit aktivní a pasivní nasazení HAProxy.