Úvod
Nginx je vysoko výkonný webový server, ktorý sa používa aj ako reverzný proxy server, poštový proxy server, nástroj na vyrovnávanie záťaže a HTTP vyrovnávacia pamäť. Nginx je bezplatný a open-source, čo umožňuje komukoľvek stiahnuť si ho a používať ho vo svojom serverovom prostredí.
Možno ste už Nginx použili na hosťovanie webových stránok. V tomto návode budeme diskutovať o ďalších schopnostiach Nginx. HTTP proxyovanie schopnosť Nginx mu umožňuje odovzdávať požiadavky backendovým HTTP serverom na spracovanie. Pomocou tejto funkcie môžete nastaviť viacero backendových serverov. Umožňuje vám to škálovať vašu infraštruktúru podľa potreby, aby ste zvládli nárasty klientskych požiadaviek.
Ako budeme postupovať v návode, dozviete sa o škálovaní vašej infraštruktúry pomocou vlastností Nginx pre vyrovnávanie záťaže, buffering, a caching odpovedí na zlepšenie výkonu vášho servera, ako aj na zabezpečenie lepšej skúsenosti pre klientov. Začnime!
V prvom rade, ak chcete začať s Nginx, pozrite sa na náš návod, ako nainštalovať Nginx na váš server Ubuntu.
Všeobecné informácie o proxyovaní
Ak sú vaše znalosti o webových serveroch len o spracovávaní požiadaviek na webové stránky a poskytovaní webových stránok, možno sa pýtate, prečo potrebujeme proxyovať požiadavky. Nižšie vysvetlíme dôvody, ktoré za tým stoja.
Jedným z dôvodov na proxyovanie požiadaviek na iné servery z Nginx je podpora škálovateľnosti vašej infraštruktúry. Nginx predvolene spracováva mnoho pripojení súčasne. Vďaka tomu je ideálny ako prvý bod kontaktu pre klientov. A potom môže odovzdávať požiadavky rôznym backendovým serverom, aby zvládli samotné spracovanie klientskych požiadaviek. To je to, čo rozkladá záťaž. Tým sa zabezpečí, že môžete svoju infraštruktúru škálovať čo najviac. Umožňuje vám to tiež odstaviť iné servery kvôli údržbe, zatiaľ čo ostatné naďalej obsluhujú požiadavky.
Druhým dôvodom, prečo by ste mohli chcieť proxyovať požiadavky na iné servery, je, keď používate aplikačné servery, ktoré nie sú vhodné na priame spracovanie požiadaviek od klientov v produkčnom prostredí. Viaceré frameworky vrátane webových serverov nie sú vhodné pre vysoký výkon ako Nginx. Ak necháte Nginx ako vstupný bod a budete proxyovať požiadavky na tieto servery s nižším výkonom, môžete zabezpečiť, aby mali vaši používatelia lepšiu skúsenosť. Okrem toho to môže zaručiť zvýšenú bezpečnosť pre vašu aplikáciu.
Proces proxyovania požiadaviek v Nginx zahŕňa úpravu požiadavky z Nginx servera a jej odovzdanie iným backendovým serverom na samotné spracovanie. Keď ostatné backendové servery požiadavku spracujú, odovzdajú výsledok späť Nginx. Ten potom pošle výsledok ako odpoveď klientovi. Klientom je v tomto prípade webový prehliadač alebo dokonca mobilná webová aplikácia. Ostatné backendové servery môžu byť lokálne servery, ktoré nie sú verejne prístupné na internete, vzdialené servery alebo dokonca iné virtuálne servery v rámci konfigurácií serverových blokov Nginx. Tieto ostatné servery, na ktoré Nginx proxyuje požiadavky, sa označujú ako upstream servery.
Nginx dokáže proxyovať požiadavky na servery, ktoré komunikujú pomocou niekoľkých protokolov vrátane HTTP(S), Memcached, SCGI, FastCGI, a uWSGI. Pre každý typ protokolu existujú sady direktív. Naším zameraním v tomto návode je protokol HTTP. Nginx analyzuje požiadavky a komponenty správ do formátu, ktorý dokáže upstream server interpretovať a spracovať.
Analýza základného HTTP Proxy Pass
Najjednoduchší typ proxy zahŕňa odovzdanie požiadavky jednému serveru, ktorý komunikuje cez HTTP. Tento typ proxy sa vo všeobecnosti označuje ako „proxy pass“ a spracováva ho výstižne pomenovaná direktíva proxy_pass v konfiguračných súboroch Nginx.
Direktíva proxy_pass sa objavuje v blokoch location. Nachádza sa tiež v blokoch kontextu location a v kontextoch limit_except. Keď sa požiadavka zhoduje s umiestnením s direktívou proxy_pass vo vnútri, požiadavka smeruje na URL, ktorú direktíva špecifikuje. Nižšie je príklad konfiguračného úryvku:
|
1 2 3 4 |
listen 80; location / { proxy_pass http://127.0.0.1:3000; } |
Vo vyššie uvedenom príklade by požiadavky na port 80 smerovali na localhost:3000:
Vyššie uvedená snímka obrazovky zobrazuje predvolenú stránku Nginx, keď sa pokúsite pripojiť k localhost. Po reštartovaní servera Nginx s účinnou direktívou proxy pass budú všetky požiadavky smerovať na port 3000. Na porte 3000 beží ukážková aplikácia, ktorú môžete vidieť na obrázku nižšie a ku ktorej sa môžete dostať priamo z localhost bez zadania portu:
V nasledujúcom príklade nebolo na konci servera v definícii proxy_pass špecifikované žiadne URI. Pri definíciách zodpovedajúcich tomuto vzoru sa URI, ktoré klient požaduje, odovzdá upstream serveru v takej podobe, v akej je.
|
1 2 3 |
location /zhoda/url/tu { proxy_pass http://example.com; } |
Napríklad, keď tento blok spracováva požiadavku na /match/url/here, URI požiadavky prejde na server example.com ako http://example.com/match/url/here.
Nižšie je uvedený príklad alternatívneho úryvku konfigurácie:
|
1 2 3 |
location /zhoda/url/tu { proxy_pass http://example.com/new/url/prefix; } |
Ako môžete vidieť vo vyššie uvedenom úryvku, na konci proxy servera sme definovali segment URI ako new/url/prefix. Keď definujete URI v definícii proxy_pass, časť požiadavky, ktorá zodpovedá definícii location, sa pri prechode na upstream server na spracovanie nahradí týmto URI.
Napríklad požiadavka na /match/url/here na serveri Nginx prechádza na upstream server ako http://example.com/new/url/here. Časť /match/url sa nahradí za /new/url. Majte tento bod na pamäti.
V niektorých prípadoch nie je odovzdanie URI ako vyššie možné. V takýchto prípadoch Nginx ignoruje URI na konci definície proxy_pass. V konečnom dôsledku sa upstream serveru odovzdá buď pôvodné URI od klienta, alebo URI, ktoré upravia iné direktívy.
Príkladom je, keď regulárne výrazy zodpovedajú umiestneniu (location). Nginx nemusí byť schopný určiť, ktorá časť URI zodpovedá výrazu. Preto odošle pôvodné URI požiadavky klienta. To spôsobí prepísanie a spracovanie URI klienta v rovnakom bloku. V takom prípade sa odovzdá prepísané URI.
Ako Nginx spracováva hlavičky?
Hlavičky sú kľúčové pre to, ako server spracováva požiadavku. Niektoré hlavičky môžu obsahovať autentifikačné informácie. Preto musíme pochopiť, ako bude proxy server Nginx spracovávať hlavičky. Proxy požiadavka z Nginx na upstream server bude vyzerať inak ako tá, ktorá prišla priamo od klienta. Niektoré z rozdielov sú dôsledkom hlavičiek, ktoré sprevádzajú proxy požiadavku.
Počas proxyovania požiadavky vykoná Nginx úpravy hlavičiek požiadaviek, ktoré prijme od klienta. Niektoré z týchto úprav zahŕňajú:
-
Odstránenie všetkých prázdnych hlavičiek. Prázdne hlavičky požiadavku len zbytočne zväčšujú, takže nemá zmysel ich odovzdávať upstream serveru.
-
Všetky hlavičky obsahujúce podčiarkovníky sa predvolene považujú za neplatné, a preto sa z požiadavky odstránia. Ak by ste chceli toto správanie zmeniť a povoliť Nginx interpretovať hlavičky s podčiarkovníkmi ako platné, môžete nastaviť direktívu underscores_in_headers na „on“. Ak tak neurobíte, takéto hlavičky od klienta sa k upstream serveru nikdy nedostanú.
-
Hlavička „Host“ sa prepíše na hodnotu špecifikovanú premennou $proxy_host. Ide o IP adresu alebo názov a číslo portu upstream servera, ako je špecifikované direktívou proxy_pass.
-
Hodnota hlavičky „Connection“ sa zmení na „close“. Hlavička spojenia obsahuje informácie o konkrétnom spojení nadviazanom medzi dvoma stranami. Keď Nginx nastaví jej hodnotu na close, signalizuje upstream serveru, že spojenie sa po odpovedaní na pôvodnú požiadavku uzavrie, takže by nemal očakávať, že pôjde o trvalé spojenie.
Tu je niekoľko bodov, ktoré si môžeme všimnúť z úprav hlavičiek proxy požiadaviek popísaných vyššie:
-
Ak nechcete, aby sa hlavička odosielala na upstream server, jej nastavenie na prázdny reťazec ju z požiadavky úplne odstráni.
-
Ak bude aplikácia vo vašom upstream serveri spracovávať neštandardné hlavičky, uistite sa, že hlavičky neobsahujú podčiarkovník. Voliteľne môžete vo svojej konfigurácii nastaviť direktívu underscores_in_headers na „on“ (platné buď v kontexte predvolenej deklarácie servera pre kombináciu IP adresy/portu, alebo v kontexte HTTP). Tým sa zabezpečí, že hlavičky nebudú označené ako neplatné, a preto sa skutočne odovzdajú na upstream server.
-
Hlavička „Host“ je vo väčšine situácií s proxy serverom pomerne dôležitá. Predvolene je nastavená na hodnotu $proxy_host, čo je premenná obsahujúca názov domény alebo IP adresu a port získaný zo špecifikácie proxy_pass. Táto adresa sa vyberá predvolene a preberá sa priamo z informácií o pripojení. Je to jediná adresa, pri ktorej má Nginx záruku, že na ňu upstream server odpovie.
Nižšie sú uvedené najbežnejšie hodnoty pre hlavičku „Host“:
-
$host – premenná sa nastavuje v poradí preferencií podľa názvu hostiteľa zo samotného riadku požiadavky, hlavičky „Host“ z požiadavky klienta alebo názvu servera, ktorý zodpovedá požiadavke.
-
$http_host – premenná, ktorá nastavuje hlavičku „Host“ na hlavičku „Host“ z požiadavky klienta. Hlavičky v požiadavke klienta sú pre Nginx vždy dostupné ako premenné. Tieto premenné začínajú predponou $http_ a potom nasleduje názov hlavičky malými písmenami. Hoci premenná $http_host bude väčšinou fungovať dobre, ak v požiadavke klienta chýba platná hlavička „Host“, môže to viesť k zlyhaniu prenosu.
-
$proxy_host – premenná, ktorá nastavuje hlavičku „Host“ na kombináciu názvu domény alebo IP adresy a portu získanú zo špecifikácie proxy_pass. Z pohľadu Nginx je to predvolené správanie, a preto sa považuje za bezpečné. Nemusí to však byť to, čo server potrebuje na správne spracovanie požiadavky.
Väčšina konfigurácií bude zahŕňať nastavenie hlavičky „Host“ na premennú $host. Je to vysoko flexibilné a poskytne to upstream serveru presne vyplnené hlavičky.
Nastavenie a úprava hlavičiek
Direktíva proxy_set_header nám umožňuje nastaviť alebo upraviť hlavičky pre proxy pripojenia. V skôr spomínanej hlavičke „Host“ môžeme urobiť nasledovné na úpravu a pridanie ďalších hlavičiek bežných pri proxy požiadavkách:
|
1 2 3 4 5 6 7 8 |
location /match/here { proxy_set_header HOST $host; proxy_set_header X-Forwarded-Proto $schema; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://example.com/new/prefix; } |
Vo vyššie uvedenom fragmente konfigurácie nastavujeme hlavičku „Host“ na premennú $host, ktorá obsahuje informácie o pôvodnom požadovanom hostiteľovi. Hlavičku X-Forwarded-Proto nastavujeme s informáciami o schéme pôvodnej požiadavky od klienta (môže ísť o požiadavku HTTP alebo HTTPS).
Skutočnú IP adresu klienta odovzdávame do X-Real-IP. To umožňuje upstream serveru vhodne sa rozhodovať alebo ukladať protokoly na základe pôvodu IP adresy klienta. Hlavička X-Forwarded-For obsahuje zoznam všetkých IP adries patriacich serverom, cez ktoré bol klient smerovaný (proxy) pred dosiahnutím tohto bodu. Vo vyššie uvedenom fragmente kódu sme ju nastavili na premennú $proxy_add_x_forwarded_for. Táto premenná prevezme hodnotu pôvodnej hlavičky X-Forwarded-For získanej od klienta a na koniec pridá IP adresu proxy servera Nginx.
Ak si želáte, aby sa na direktívy proxy_set_header odkazovalo na viac ako jednom mieste (location), môžete ich presunúť do kontextu server alebo http. Zvážte fragment konfigurácie nižšie:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
proxy_set_header HOST $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; location /match/here { proxy_pass http://example.com/new/prefix; } location /different/match { proxy_pass http://example.com; } |
Definovanie kontextu upstream na vyvažovanie záťaže proxy pripojení
Do tohto momentu už rozumiete tomu, ako vytvoriť jednoduché http proxy na jeden backendový upstream server. Našťastie s Nginx môžete takúto konfiguráciu škálovať definovaním skupín (poolov) backendových serverov, na ktoré sa budú požiadavky odovzdávať na spracovanie.
Nginx poskytuje direktívu s názvom upstream, ktorá sa používa na definovanie skupiny serverov. V rámci konfigurácie tejto direktívy musíte špecifikovať iba servery, ktoré sú schopné spracovať požiadavku klienta. Nginx ako proxy server umožňuje škálovanie infraštruktúry s minimálnym úsilím. Direktíva upstream musí byť špecifikovaná v rámci kontextu http vašej konfigurácie Nginx.
Tu je príklad znázorňujúci direktívu upstream:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
upstream several_backend_hosts { server host1.example.com; server host2.example.com; server host3.example.com; } server { listen 80; server_name example.com; location /proxy-me { proxy_pass http://several_backend_hosts; } } |
Vo vyššie uvedenom fragmente konfiguračného kódu sme definovali kontext upstream s názvom several_backend_hosts. Definovaný názov kontextu je teraz k dispozícii v rámci proxy_pass. Môže sa použiť, akoby to bola bežná doména, ako je znázornené v príklade. V rámci bloku server odovzdávame všetky požiadavky smerované na example.com/proxy-me/… do skupiny, ktorú sme definovali pomocou direktívy upstream, v tomto prípade several_backend_hosts. Hostiteľ v rámci skupiny sa vyberá na spracovanie prichádzajúcich požiadaviek pomocou konfigurovateľného algoritmu. V predvolenom nastavení výber prebieha podľa round-robin (kruhového) procesu – každá požiadavka je postupne smerovaná na iného hostiteľa.
Ako zmeniť algoritmus vyvažovania upstreamu
Ako bolo zdôraznené vyššie, proces výberu prebieha metódou round-robin. V tejto časti si ukážeme, ako môžeme upraviť algoritmus vyvažovania používaný skupinou upstream. Ak chcete upraviť algoritmus, zahrniete do kontextu upstream ďalšie direktívy alebo príznaky, ako je definované nižšie:
-
(round-robin) – ak nie je špecifikovaná žiadna iná direktíva na vyvažovanie upstreamu, potom sa predvolene každému serveru definovanému v kontexte upstream odovzdávajú požiadavky postupne za sebou.
-
least_conn – táto direktíva inštruuje upstream, aby vybral backendový server s najmenším počtom aktívnych pripojení. To je použiteľné v situáciách, keď pripojenia k jednému backendovému serveru môžu pretrvávať dlhší čas.
-
hash – táto direktíva je bežná pre proxying memcached. Pripojenia sa odovzdávajú backendovým serverom na základe hodnoty náhodne poskytnutého hashovacieho kľúča. Hodnotou hashovacieho kľúča môžu byť premenné, text alebo kombinácia oboch. hash je jedinou metódou vyvažovania, ktorá vyžaduje vstup od používateľov, ktorý slúži ako kľúč pre hashovanie.
-
ip_hash – táto direktíva inštruuje upstream, aby distribuoval požiadavky na rôzne servery na základe IP adresy klienta. Prvé tri oktety IP adresy sú kľúčom na určenie, ktorý server má požiadavku spracovať. Výhodou tejto direktívy je, že klienti majú tendenciu zakaždým dostávať rovnaký server, čo zaisťuje konzistentnosť relácie.
Tu je príklad toho, ako môžeme pridať direktívu algoritmu vyvažovania do kontextu upstream:
|
1 2 3 4 5 6 7 8 |
upstream several_backend_hosts { least_conn; server host1.example.com; server host2.example.com; server host3.example.com; } |
Vo vyššie uvedenom fragmente kódu Nginx vyberie na spracovanie prichádzajúcej požiadavky ten zo serverov, ktorý má najmenej pripojení. Direktíva ip_hash má rovnakú syntax. Pre direktívu hash musíte zadať kľúč podľa vlastného výberu, voči ktorému sa bude hashovať, tu je príklad:
|
1 2 3 4 5 6 7 8 |
upstream several_backend_hosts { hash $remote_addr$remote_port consistent; server host1.example.com; server host2.example.com; server host3.example.com; } |
Tu použitý hash bude výsledkom IP adresy a portu klienta. Voliteľný parameter consistent implementuje algoritmus konzistentného hashovania ketama. To zaisťuje minimálny vplyv na vašu vyrovnávaciu pamäť (cache), ak by ste zmenili svoje upstream servery.
Ako určiť váhu servera pre vyvažovanie
V predvolenom nastavení majú pri deklarovaní backend serverov všetky servery rovnakú váhu. Predpokladá sa, že každý server má zdroje a schopnosti zvládnuť rovnaké množstvo záťaže, samozrejme, s ohľadom na to, aký algoritmus vyvažovania určíte v kontexte upstream. Ak chcete toto predvolené správanie zmeniť, môžete počas deklarácie nastaviť alternatívnu váhu pre každý server. Pozrime sa na príklad:
|
1 2 3 4 5 |
upstream backend_hosts { server host1.example.com weight=2; server host2.example.com; server host3.example.com; } |
V tomto príklade host1.example.com prijme dvakrát viac prevádzky ako ostatné dva servery. Váha pre každý server je predvolene jedna.
Uvoľnenie backend serverov pomocou vyrovnávacích pamätí
Pri konfigurácii proxy v konfigurácii vášho servera sa môžete obávať vplyvu pridania ďalších serverov do procesu na výkon. Našťastie Nginx prichádza s funkciami ukladania do vyrovnávacej pamäte (buffering a caching), ktoré môžu pomôčiť zmierniť tieto problémy s výkonom.
Rýchlosť dvoch rôznych pripojení určite ovplyvní používateľskú skúsenosť klienta pri proxyovaní na iný server:
-
Prvé pripojenie je od klienta k proxy serveru Nginx.
-
Druhé pripojenie je z proxy servera Nginx k backendovému upstream serveru.
Nginx môže upraviť svoje správanie tak, aby pomohol optimalizovať ktorékoľvek z pripojení podľa potreby.
Ak odstránime vyrovnávacie pamäte (buffery), prenos dát z upstream backendu ku klientovi začne okamžite na proxy serveri Nginx. Ak viete, že vaši klienti sú rýchli, môžete ukladanie do vyrovnávacej pamäte (buffering) úplne vypnúť, aby sa dáta dostali ku klientovi dostatočne rýchlo. Keď máte vyrovnávacie pamäte zapnuté, proxy server Nginx dočasne ukladá dáta odpovede prijaté z backendového upstream servera. Potom posiela dáta klientovi v závislosti od jeho rýchlosti. Akonáhle má Nginx odpoveď vo svojich vyrovnávacích pamätiach, môže ukončiť pripojenie k backend serveru. Potom bude distribuovať dáta klientovi rýchlosťou, ktorú klient podporuje. Zároveň tým umožňuje backend serveru pokračovať v spracovávaní ďalších prichádzajúcich požiadaviek.
V predvolenom nastavení bude mať Nginx ukladanie do vyrovnávacej pamäte (buffering) zapnuté. Je to preto, že nemôžeme poznať rýchlosti pripojenia klientov. Klienti zvyknú mať rôzne pripojenia, ktoré môžu byť pomalšie. Nižšie definujeme rôzne direktívy, ktoré môžeme špecifikovať na úpravu správania ukladania do vyrovnávacej pamäte v Nginx. Direktívy môžu byť definované v kontextoch http, server alebo location, mali by ste však vziať na vedomie, že direktívy určujúce veľkosť sa konfigurujú na požiadavku. Preto ich zvýšenie nad rámec toho, čo je absolútne nevyhnutné, môže ovplyvniť výkon vášho servera, keď prichádza príliš veľa požiadaviek od klientov. Tu sú tieto direktívy:
-
proxy_buffering – direktíva, ktorá riadi, či je ukladanie do vyrovnávacej pamäte (buffering) aktívne pre konkrétny kontext a dcérske kontexty. Predvolená konfigurácia pre proxy_buffering je „on“.
-
proxy_buffer_size – direktíva, ktorá určuje veľkosť vyrovnávacej pamäte na ukladanie hlavičiek nájdených v odpovedi od backendového servera. Hlavičky tvoria prvú časť odpovede z backendového servera. Ukladanie týchto hlavičiek do vyrovnávacej pamäte je oddelené od zvyšku odpovede. Predvolene je nastavená veľkosť tejto vyrovnávacej pamäte rovnaká ako pri proxy_buffers. Ak sú však informácie v hlavičke malé, môžete nastaviť veľkosť na nižšiu hodnotu.
-
proxy_buffers – direktíva riadiaca počet (prvý argument) a veľkosť (druhý argument) vyrovnávacích pamätí pre proxy odpovede. Predvolená konfigurácia špecifikuje 8 vyrovnávacích pamätí s veľkosťou rovnajúcou sa jednej pamäťovej stránke (buď 4k alebo 8k). Ukladanie väčšieho množstva informácií do vyrovnávacej pamäte môžete povoliť zvýšením počtu vyrovnávacích pamätí.
-
proxy_max_temp_file_size – direktíva určujúca maximálnu veľkosť dočasného súboru na disku na jednu požiadavku. Dočasné súbory sa vytvárajú vtedy, keď je odpoveď zo servera upstream príliš veľká na to, aby sa zmestila do vyrovnávacej pamäte.
-
proxy_busy_buffers_size – direktíva určujúca maximálnu veľkosť vyrovnávacích pamätí, ktoré môžu prejsť ako „pripravené pre klienta“ a teda zaneprázdnené. Klient môže čítať dáta naraz iba z jednej vyrovnávacej pamäte. Vyrovnávacie pamäte sú však v rade na odoslanie klientovi v dávkach. Úpravou tejto direktívy môžete určiť veľkosť priestoru vyrovnávacej pamäte, ktorý môže byť v tomto stave.
-
proxy_temp_file_write_size – direktíva určujúca množstvo dát, ktoré Nginx zapíše do dočasného súboru naraz, keď je odpoveď z backendového upstream servera príliš veľká na to, aby sa zmestila do nakonfigurovaných vyrovnávacích pamätí.
-
proxy_temp_path – direktíva určujúca cestu k umiestneniu na disku, kde má Nginx ukladať dočasné súbory, keď je odpoveď z upstream backendového servera príliš veľká na to, aby sa zmestila do nakonfigurovaných vyrovnávacích pamätí.
Nginx je vysoko prispôsobiteľný a poskytuje vám niekoľko direktív na doladenie správania ukladania do vyrovnávacej pamäte. Vo väčšine prípadov budú predvolené hodnoty fungovať úplne v poriadku. Zároveň je dobré vedieť, že niektoré z týchto hodnôt môžete upraviť pre svoju vlastnú implementáciu. Najčastejšie budete chcieť upraviť direktívy proxy_buffers a proxy_buffer_size.
Nižšie je uvedený príklad, ktorý zvyšuje počet dostupných proxy vyrovnávacích pamätí pre každú požiadavku upstream. Robí to pri súčasnom znížení veľkosti vyrovnávacej pamäte, ktorá ukladá hlavičky:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
server { proxy_buffering on; proxy_buffer_size 1k; proxy_buffers 24 4k; proxy_busy_buffers_size 8k; proxy_max_temp_file_size 2048m; proxy_temp_file_write_size 32k; location / { proxy_pass http://example.com; } } |
Pozrime sa, ako môžete rýchlejšie poskytovať dáta rýchlym klientom úplným vypnutím ukladania do vyrovnávacej pamäte. Ak sa stane, že váš klient nie je dostatočne rýchly, Nginx automaticky použije vyrovnávacie pamäte. Najprv však odošle dáta klientovi namiesto čakania na fondy vyrovnávacích pamätí. Táto konfigurácia má nevýhodu. Spôsobuje totiž, že pripojenie k upstream serveru zostane pre pomalých klientov otvorené, kým klient neprijme všetky dáta odpovede. Ak je ukladanie do vyrovnávacej pamäte nastavené na „off“, použije sa iba vyrovnávacia pamäť definovaná direktívou proxy_buffer_size. Tu je úryvok kódu, ktorý ukazuje, ako by ste špecifikovali vypnutie ukladania do vyrovnávacej pamäte:
|
1 2 3 4 5 6 7 8 9 |
server { proxy_buffering off; proxy_buffer_size 4k; location / { proxy_pass http://example.com; } } |
-
Konfigurácia vysoko dostupnej (HA) infraštruktúry (voliteľné nastavenie)
Do konfigurácie proxy servera Nginx môžete pridať redundantnú sadu nástrojov na vyrovnávanie záťaže (load balancerov), čím zabezpečíte, že bude robustnejšia, a teda vysoko dostupná. Nastavenie vysokej dostupnosti (HA) je infraštruktúra bez jediného bodu zlyhania. Nástroje na vyrovnávanie záťaže sú súčasťou tejto konfigurácie. S viac ako jedným nástrojom na vyrovnávanie záťaže môžete zabrániť potenciálnym prestojom, ak jeden z nich zlyhá alebo prejde do režimu offline kvôli údržbe.
Ako implementovať ukladanie do vyrovnávacej pamäte (caching) proxy servera Nginx na zníženie času odozvy
V predchádzajúcej časti sme diskutovali o tom, ako použiť ukladanie do vyrovnávacej pamäte (buffering) na uvoľnenie backendových serverov, aby mohli spracovať viac požiadaviek. Nginx prichádza s ďalšou funkciou, ktorá nám umožňuje ukladať údaje odozvy z backendu do vyrovnávacej pamäte (cache). Úplne tak odpadá potreba pripájať sa k upstreamu pri všetkých prichádzajúcich požiadavkách.
Implementácia vyrovnávacej pamäte proxy (Proxy Cache)
Direktíva proxy_cache_path nám umožňuje nastaviť vyrovnávaciu pamäť špecifikovaním oblasti na disku, ktorá sa použije na ukladanie sprostredkovaného obsahu. Direktíva proxy_cache_path sa definuje v kontexte http.
Nižšie uvedený úryvok konfiguračného kódu je príkladom toho, ako môžete implementovať systém ukladania do vyrovnávacej pamäte:
|
1 2 3 4 5 6 |
http { proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=backendcache:8m max_size=50m; proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args"; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; } |
V tomto úryvku kódu sme použili direktívu proxy_cache_path na definovanie adresára v súborovom systéme, ktorý bude obsahovať našu vyrovnávaciu pamäť. V tomto prípade sme nastavili adresár /var/lib/nginx/cache. Môžete si slobodne definovať cestu k adresáru podľa vlastného výberu. Na vytvorenie vybraných adresárov so správnymi povoleniami a vlastníctvom použite nasledujúce príkazy:
|
1 2 3 |
sudo mkdir -p /var/lib/nginx/cache sudo chown www-data /var/lib/nginx/cache sudo chmod 700 /var/lib/nginx/cache |
V úryvku kódu parameter levels= špecifikuje organizáciu vyrovnávacej pamäte. Nginx vytvorí kľúč vyrovnávacej pamäte hašovaním hodnoty kľúča (špecifikovaného pomocou direktívy proxy_cache_key). Úrovne, ktoré sme špecifikovali (1:2), naznačujú, že sa vytvorí jednorozmerný adresár s jedným znakom (t. j. posledný znak hašovanej hodnoty) s dvojznakovým podadresárom (prevzatým z nasledujúcich dvoch znakov od konca hašovanej hodnoty). Vo väčšine prípadov sa vás to nebude týkať. Je však dobré vedieť, ako to pomáha Nginx rýchlo nájsť príslušné hodnoty.
Parameter keys_zone= definuje názov zóny vyrovnávacej pamäte, v našom prípade sme ju nazvali backendcache. Tu tiež definujeme, koľko metadát chceme uložiť. V tomto príklade ukladáme 8 MB kľúčov. Nginx dokáže uložiť približne 8000 záznamov na každý megabajt. Parameter max_size špecifikuje maximálnu veľkosť skutočných uložených údajov, v našom príklade 50 MB.
Mali by ste si tiež všimnúť použitú direktívu proxy_cache_key. Táto direktíva špecifikuje kľúč, ktorý použijeme na ukladanie hodnôt do vyrovnávacej pamäte. Rovnaký kľúč použijeme na kontrolu, či požiadavka existuje vo vyrovnávacej pamäti. Tento kľúč sme definovali ako kombináciu schémy (http alebo https), metódy požiadavky HTTP a požadovaného hostiteľa a URI.
Okrem toho sme použili direktívu proxy_cache_valid. Túto direktívu je možné špecifikovať viackrát pre rôzne stavové kódy. Umožňuje nám určiť, ako dlho sa majú hodnoty uchovávať v závislosti od stavového kódu. V úryvku kódu sme špecifikovali 10 minút pre úspešné kódy a 1 minútu pre odpovede 404.
Keďže sme nakonfigurovali zónu vyrovnávacej pamäte, ďalším krokom je uviesť konfiguráciu do platnosti tým, že povieme Nginx, kedy má vyrovnávaciu pamäť použiť. Nižšie je uvedený úryvok konfigurácie, ktorý ukazuje, ako môžeme implementovať použitie tejto vyrovnávacej pamäte:
|
1 2 3 4 5 6 7 8 9 |
server { location /proxy-me { proxy_cache backendcache; proxy_cache_bypass $http_cache_control; add_header X-Proxy-Cache $upstream_cache_status; proxy_pass http://backend; } } |
V direktíve proxy_cache sme špecifikovali, že pre tento kontext by sa mala použiť zóna vyrovnávacej pamäte backendcache. Ak ste v konfigurácii vyrovnávacej pamäte vybrali iný názov, tu ho nahradíte. Pri každom platnom zázname Nginx pred odovzdaním požiadavky na backendový upstream server skontroluje vyrovnávaciu pamäť.
Definujeme direktívu proxy_cache_bypass na použitie premennej $http_cache_control. Táto premenná hovorí serveru, či má odpovedať odpoveďou z vyrovnávacej pamäte alebo čerstvou, neuloženou verziou zdroja. Správne nastavenie tejto direktívy umožňuje Nginx správne spracovať rôzne typy prichádzajúcich požiadaviek od klientov.
Špecifikovaná je aj dodatočná hlavička s názvom X-Proxy-Cache. Táto hlavička má hodnotu premennej $upstream_cache_status. Poskytuje nám informácie o tom, či požiadavka viedla k zásahu vyrovnávacej pamäte (cache hit), minutiu vyrovnávacej pamäte (cache miss), alebo či bola vyrovnávacia pamäť explicitne obídená. Takéto informácie môžu byť užitočné pre klienta a kľúčové počas ladenia aplikácií.
Dôležité body týkajúce sa ukladania výsledkov do vyrovnávacej pamäte
Hoci ukladanie do vyrovnávacej pamäte výrazne zlepší výkon vášho proxy servera, pri implementácii cachovania by ste mali vziať do úvahy nasledujúce skutočnosti:
Žiadne údaje súvisiace s osobnými informáciami používateľa by sa nemali ukladať do vyrovnávacej pamäte, aby sa predišlo scenárom, kedy sú údaje jedného používateľa viditeľné pre iného používateľa.
Vaše backendové servery by mali zohľadňovať všetky dynamické prvky vašej webovej lokality. V našej odpovedi môžeme špecifikovať niekoľko hlavičiek Cache-Control na rôzne účely. Poďme si ich prediskutovať:
-
no-cache – špecifikuje, že proxy musí pred odoslaním odpovede skontrolovať, či sa údaje na backende nezmenili. To platí pre dynamické a dôležité údaje. Pri každej požiadavke sa kontroluje hlavička s hašovanými metadátami ETag, a ak backend vráti rovnakú hodnotu hašu, použije sa predchádzajúca hodnota.
-
no-store – špecifikuje zákaz ukladania akýchkoľvek prijatých údajov do vyrovnávacej pamäte, preto každá požiadavka pôjde na server pre čerstvé údaje. Toto je najbezpečnejšie pre citlivé údaje.
-
private – špecifikuje, že žiadny zdieľaný priestor vyrovnávacej pamäte by nemal ukladať tieto údaje. Túto hlavičku môžete použiť na špecifikovanie ukladania do vyrovnávacej pamäte v prehliadači používateľa, ale zároveň informovať proxy server, aby považoval údaje za neplatné pre následné požiadavky.
-
public – špecifikuje verejnú odpoveď a umožňuje ukladanie do vyrovnávacej pamäte v ktoromkoľvek bode pripojenia.
Pomocou hlavičky max-age môžete určiť, ako dlho má vyrovnávacia pamäť vydržať v sekundách. Rôzne vyššie definované hlavičky vám môžu pomôcť implementovať ukladanie do vyrovnávacej pamäte a zároveň zachovať citlivé údaje v bezpečí, dynamické údaje čerstvé a čo je najdôležitejšie, zlepšiť výkon vášho servera.
Ak na vašich backendových serveroch bežia servery Nginx, môžete v blokoch server špecifikovať, ako dlho má byť vyrovnávacia pamäť platná. Môžete to urobiť pridaním direktívy expires do konfigurácie, ako je znázornené nižšie:
|
1 2 3 4 5 6 7 |
location / { expires 59m; } location /check-me { expires -1; } |
Prvý blok umožňuje ukladanie obsahu do vyrovnávacej pamäte na 59 minút, zatiaľ čo druhý blok indikuje žiadne ukladanie. Tieto nastavenia sa vzťahujú na možnosti hlavičiek Cache-Control, napríklad „no-cache“ pre druhý blok.
Na nastavenie ďalších hodnôt môžete použiť direktívu add-header:
|
1 2 3 4 |
location /private { expires -1; add_header Cache-Control "no-store"; } |
Záver
V tomto návode sme sa dozvedeli o výkonných funkciách Nginx. Nginx je webový server a čo je najdôležitejšie, reverzný proxy server. Vďaka svojej architektúre dokáže Nginx spracovať tisíce súčasných pripojení. Vďaka tomu je ideálny na vyvažovanie záťaže (load balancing). Vzhľadom na jeho návrh je smerovanie požiadaviek na iné backendové servery na spracovanie pomerne jednoduché.
S vedomosťami z tohto návodu by ste mali byť schopní implementovať komplexné proxy servery a nástroje na vyrovnávanie záťaže vďaka flexibilite Nginx.
Tu je niekoľko zdrojov, ktoré nájdete na našom blogu ktoré vás môžu bližšie oboznámiť s Nginx:
Príjemnú prácu!
Komentáre
Zatiaľ žiadne komentáre. Buďte prvý.