Tento článek se také objevuje na blogu NGINX. Přečtěte si na NGINX>
Vývoj webu a hostování se tradičně prováděly primárně pomocí zásobníku LAMP – LAMP je zkratka pro L inux (operační systém), A pache (webový server), M ySQL (databáze) a P HP (programovací jazyk), základní komponenty, které byly poté použity k provozování podnikových webů.
S tím, jak se webové zásobníky a nástroje pro vyrovnávání zatížení stávají agilnějšími a jak obchodní potřeby vyžadují lepší výkon a stabilitu, je stále běžnější nahrazovat Apache HTTP Server odlehčenou a vysoce škálovatelnou alternativou, NGINX. S NGINX se zásobník nazývá LEMP – L inux, (e )NGINX, M ySQL, P HP.
Atlantic.Net nabízí řadu řešení, která zahrnují úložiště, hosting a spravované služby. Naše platforma VPS Hosting má možnost LEMP na jedno kliknutí, která zajistí, že váš zásobník bude připraven a spuštěn za méně než 30 sekund. Pro ty, kteří dávají přednost spouštění NGINX z Dockeru, máme s Dockerem cloudové servery pro Linux i Windows. Poskytujeme také spravované služby pro ty, kteří chtějí nebo potřebují pomoc s nastavením NGINX.
NGINX využíváme často a robustně nejen jako webový server, ale také jako reverzní proxy a nástroj pro vyrovnávání zatížení. Rozhodli jsme se použít NGINX poté, co jsme prozkoumali řešení pro vyrovnávání zátěže pro náš centralizovaný logovací cluster. Používáním NGINX v různých kapacitách dosahujeme vysoké dostupnosti pro naše frontendové i backendové servery při zachování extrémně malých rozměrů – to vše díky efektivitě NGINX ve využití RAM a CPU.
Pokud jde o to, které konkrétní funkce NGINX jsou nejužitečnější, mezi některé, které považujeme za zvláště výkonné, patří TCP/UDP proxy a vyvažování zátěže, řízení přístupu a třícestné navázání spojení SSL. V tomto příspěvku na blogu popíšu, jak používáme každou z těchto funkcí.
Vyrovnávání zátěže Naše centralizované protokolování pomocí streamů NGINX
Vzhledem k tomu, že potřeba poskytovat protokolování pro audit a zabezpečení se stala stále důležitější, hledali jsme v Atlantic.Net správné řešení proxy a vyvažování zátěže – nejen pro provoz HTTP, ale také pro syslog. Syslog je běžně zasílán ve formátu User Datagram Protocol (UDP), takže jsme potřebovali něco, co zvládne UDP i HTTP.
Zde se NGINX stream do hry vstoupily moduly, které umožňují vyvažování zátěže UDP provozu. Load balancing využívá řadu backendových serverů pro efektivní distribuci síťového provozu. Jak termín napovídá, účelem je rovnoměrně rozložit pracovní zátěž.
V následujícím úryvku posíláme zprávy syslog z naší síťové infrastruktury do našeho logovacího backendu:
...
stream {
upstream networking_udp {
least_conn;
server 198.51.100.100:5910;
server 198.51.100.101:5910;
server 198.51.100.102:5910;
}
server {
listen 5910 udp;
proxy_timeout 0s;
proxy_bind $remote_addr transparent;
proxy_pass networking_udp;
}
}
... Streamy také fungují dobře pro SSL přes TCP, jak ukazuje následující příklad, který bezpečně odesílá protokoly Filebeat:
...
upstream filebeat_tcp {
least_conn;
server 198.51.100.100:5910;
server 198.51.100.101:5910;
server 198.51.100.102:5910;
}
server {
listen 5910 ssl;
ssl_certificate /etc/nginx/ssl/certs/cert.pem;
ssl_certificate_key /etc/nginx/ssl/private/priv-key.pem;
ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 4h;
ssl_handshake_timeout 30s;
proxy_pass filebeat_tcp;
proxy_ssl on;
proxy_ssl_certificate /etc/nginx/ssl/certs/cert.pem;
proxy_ssl_certificate_key /etc/nginx/ssl/private/priv-key.pem;
proxy_ssl_protocols TLSv1.2;
proxy_ssl_session_reuse on;
proxy_ssl_ciphers HIGH:!aNULL:!MD5;
proxy_ssl_trusted_certificate /etc/nginx/ssl/certs/ca.pem;
}
... Jak můžete vidět, NGINX je schopen proxy a vyvažování zátěže UDP a provozu protokolu TCP (Transmission Control Protocol).
Použití reverzních proxy a vyvažování zátěže je užitečné, když máte službu, databázi nebo program, který komunikuje přes UDP nebo TCP. Na základní úrovni jsou tyto metody relevantní, když máte stejnou službu, databázi nebo instanci programu spuštěnou na několika upstream serverech, jak jsou spravovány NGINX. V Atlantic.Net využíváme také reverzní proxy od NGINX, protože poskytuje další vrstvu zmatku našim kritickým backendovým službám s velmi malou režií.
Řízení přístupu
Dalším důležitým krokem k zabezpečení našeho centralizovaného protokolování bylo zabránit smazání jakýchkoli dat. Kromě toho jsou seznamy řízení přístupu (ACL) velmi užitečné pro omezení provozu na základě IP adresy. Pro naše účely jsme chtěli povolit přístup k logovacím datům pouze z naší interní sítě pro správu.
NGINX nám poskytuje způsob, jak velmi přesně vymezit, jaké druhy akcí HTTP lze provádět a odkud, jak je vidět zde:
...
server {
listen 9200;
client_max_body_size 20M;
location / {
limit_except GET POST PUT OPTIONS {
deny all;
}
allow 198.51.100.0/24;
deny all;
proxy_pass http://elasticsearch_backend;
}
location ~* ^(/_cluster|/_nodes|/_shutdown) {
allow 198.51.100.0/24;
deny all;
proxy_pass http://elasticsearch_backend;
}
}
... NGINX také podporuje funkci transparentní IP, která nám umožňuje vidět původní IP adresu poté, co požadavek projde přes proxy. Tato funkce pomáhá se sledováním, odkud protokoly pocházejí. NGINX tento úkol velmi usnadňuje:
...
server {
listen 5915 udp;
proxy_timeout 0s;
proxy_bind $remote_addr transparent;
proxy_pass vmware_udp;
}
... Three-Way SSL Handshake
NGINX čistě zpracovává obě strany předávání SSL pro naše centralizované protokolování. Tato implementace je velmi důležitá, protože znamená, že interní i zákaznické servery mohou bezpečně komunikovat s NGINX. Každý protokolovaný server má svůj vlastní certifikát pro obousměrnou komunikaci SSL, což dále snižuje zranitelnosti. NGINX pak data bezpečně přenáší přes naši interní síť prostřednictvím SSL na protokolovací servery. Celkem jsou pro každou komunikaci typu end-to-end, která podporuje bezpečný přenos, zapojeny tři certifikáty SSL. (Naše preferované třícestné nastavení SSL naleznete ve druhém úryvku konfigurace v naše centralizované protokolování zátěže pomocí streamů NGINX.)
Perspektivy a testy NGINX
Různí jednotlivci a organizace v průběhu let NGINX chválili a my jsme od NGINX zažili stejné další výhody, které zmiňují.
Softwarový inženýr Chris Lea z NodeSource srovnává Apache s Microsoft Word a poznamenává, že obě aplikace mají absurdně velké množství funkcí, ale obvykle jich je potřeba jen několik. Lea preferuje NGINX, protože má funkce, které potřebujete, bez velkého objemu a mnohem lepšího výkonu.
Podle Thomase Gieselmana z firmy rizikového kapitálu BV Capital několik organizací, které financovaly, opravilo problémy související se škálováním změnou svého serveru na NGINX. Gieselman vidí, že NGINX usnadňuje rychlý růst a zpřístupňuje jej více organizacím.
Linux Journal provedl přímý test pomocí srovnávacího softwaru Apache, ab pro porovnání Apache s NGINX (verze 2.2.8 a 0.5.22). Programy top a vmstat byly použity ke kontrole výkonu systému, zatímco oba servery běžely současně.
Test ukázal, že NGINX byl rychlejší než Apache jako server se statickým obsahem. Každý ze dvou serverů běžel optimálně, souběžnost byla nastavena na 100. Aby Apache obsluhoval 6 500 požadavků za sekundu, spotřeboval 17 MB paměti, 30 % CPU a 4 pracovní procesy (v režimu vláken). K poskytování mnohem rychlejšího klipu 11 500 požadavků za sekundu potřeboval NGINX jen 1 MB paměti, 15 % CPU a 1 pracovníka.
Bob Ippolito založil herní platformu Mochi Media, která měla na vrcholu 140 milionů unikátních uživatelů měsíčně – takže poptávce po vysokém výkonu dobře rozumí. Ippolito v roce 2006 řekl, že provedl test, ve kterém použil NGINX jako reverzní proxy pro desítky milionů požadavků HTTP za den (tj. několik stovek za sekundu) na jednom serveru.
Když měl server NGINX maximální kapacitu, spotřeboval přibližně 10 % CPU a 15 MB paměti v jeho nastavení, což bylo FreeBSD (open source OS založený na UNIXu). Pomocí stejných parametrů vygeneroval Apache 1000 procesů a spolykal obrovské množství paměti RAM. Pound vytvořil nadměrné množství vláken a pro různé zásobníky vláken spotřeboval více než 400 MB. Lehce potřeboval více CPU a uniklo přes 20 MB za hodinu.
Vyzkoušejte Atlantic.Net s NGINX
Na Atlantic.Net jsme zjistili podobné zvýšení výkonu s NGINX, jak je popsáno těmito různými stranami. Také jsme těžili ze specifických funkcí popsaných výše. Pokud aktuálně používáte Apache nebo jiný webový server, možná budete chtít vyzkoušet NGINX, abyste zjistili, zda získáte podobná vylepšení, která vám pomohou lépe zvládnout škálovatelnost a stále rostoucí potřebu rychlosti. Otestujte NGINX s cloudovým serverem ještě dnes.