Questo articolo appare anche sul blog di NGINX. Leggi su NGINX>
Tradizionalmente, lo sviluppo web e l'hosting venivano eseguiti principalmente utilizzando lo stack LAMP - LAMP è l'abbreviazione di L inux (sistema operativo), A pache (server web), M ySQL (database) e P HP (linguaggio di programmazione), i componenti principali che sono stati poi utilizzati per eseguire i siti aziendali.
Man mano che gli stack Web e i bilanciatori di carico diventano più agili e poiché le esigenze aziendali impongono prestazioni e stabilità migliori, sta diventando sempre più comune sostituire Apache HTTP Server con un'alternativa leggera e altamente scalabile, NGINX. Con NGINX, lo stack diventa noto come LEMP – L inux, (e )NGINX, M ySQL, P HP.
Atlantic.Net offre una gamma di soluzioni che include storage, hosting e servizi gestiti. La nostra piattaforma di hosting VPS ha un'opzione LEMP con un clic che consente al tuo stack di essere attivo e funzionante in meno di 30 secondi. Per coloro che preferiscono eseguire NGINX da Docker, abbiamo sia Linux che Windows Cloud Server con Docker. Forniamo anche servizi gestiti per coloro che desiderano o necessitano di assistenza per la configurazione di NGINX.
Facciamo un uso frequente e robusto di NGINX non solo come server web, ma anche come proxy inverso e bilanciamento del carico. Abbiamo deciso di utilizzare NGINX dopo aver ricercato soluzioni di bilanciamento del carico per il nostro cluster di registrazione centralizzato. Utilizzando NGINX in varie capacità, otteniamo un'elevata disponibilità sia per i nostri server front-end che per quelli back-end, pur mantenendo un footprint estremamente ridotto, tutto grazie all'efficienza di NGINX nell'utilizzo di RAM e CPU.
In termini di quali funzioni specifiche di NGINX sono più utili, alcune che troviamo particolarmente potenti sono il proxy TCP/UDP e il bilanciamento del carico, il controllo degli accessi e gli handshake SSL a tre vie. In questo post del blog, descriverò come utilizziamo ciascuna di queste capacità.
Bilanciamento del carico La nostra registrazione centralizzata con NGINX Streams
Poiché la necessità di fornire la registrazione per il controllo e la sicurezza è diventata un obiettivo sempre più importante, noi di Atlantic.Net stavamo cercando la giusta soluzione proxy e di bilanciamento del carico, non solo per il traffico HTTP, ma anche per syslog. Syslog viene comunemente inviato in formato UDP (User Datagram Protocol), quindi avevamo bisogno di qualcosa che gestisse UDP e HTTP.
Qui è dove NGINX stream i moduli sono entrati in gioco, poiché consentono il bilanciamento del carico del traffico UDP. Il bilanciamento del carico utilizza una serie di server back-end per una distribuzione efficiente del traffico di rete. Come suggerisce il termine, lo scopo è distribuire il carico di lavoro in modo uniforme.
Nel frammento di codice seguente, inviamo messaggi syslog dall'infrastruttura di rete esterna al nostro back-end di registrazione:
...
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;
}
}
... Gli stream funzionano bene anche per SSL su TCP, come mostrato nell'esempio seguente che invia i log Filebeat in modo sicuro:
...
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;
}
... Come puoi vedere, NGINX è in grado di eseguire il proxy e il bilanciamento del carico del traffico UDP e TCP (Transmission Control Protocol).
L'uso dei proxy inversi e del bilanciamento del carico è utile quando si dispone di un servizio, database o programma che comunica tramite UDP o TCP. A livello di base, questi metodi sono rilevanti quando hai lo stesso servizio, database o istanza del programma in esecuzione su più server upstream, come gestiti da NGINX. In Atlantic.Net, sfruttiamo anche il proxy inverso di NGINX, perché fornisce un ulteriore livello di offuscamento ai nostri servizi di back-end critici, con un sovraccarico minimo.
Controllo accessi
Un altro passo importante per proteggere la nostra registrazione centralizzata è stato impedire la cancellazione di tutti i dati. Inoltre, gli elenchi di controllo di accesso (ACL) sono molto utili per limitare il traffico in base all'indirizzo IP. Per i nostri scopi, abbiamo voluto consentire l'accesso ai dati di registro solo dalla nostra rete di gestione interna.
NGINX ci offre un modo per delineare in modo molto preciso quali tipi di azioni HTTP possono essere eseguite e da dove, come si può vedere qui:
...
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 supporta anche una funzione IP trasparente che ci consente di vedere l'indirizzo IP di origine dopo che la richiesta è passata attraverso il proxy. Questa funzionalità aiuta a tenere traccia dell'origine dei registri. NGINX rende questo compito molto semplice:
...
server {
listen 5915 udp;
proxy_timeout 0s;
proxy_bind $remote_addr transparent;
proxy_pass vmware_udp;
}
... Handshake SSL a tre vie
NGINX gestisce in modo pulito entrambi i lati degli handoff SSL per la nostra registrazione centralizzata. Questa implementazione è molto importante, poiché significa che sia i server interni che quelli dei clienti possono comunicare in modo sicuro con NGINX. Ciascun server registrato dispone del proprio certificato per la comunicazione SSL a due vie, riducendo ulteriormente le vulnerabilità. NGINX trasmette quindi i dati in modo sicuro attraverso la nostra rete interna, tramite SSL, ai server di registrazione. In totale, sono coinvolti tre certificati SSL per ogni comunicazione end-to-end che supporta la trasmissione sicura. (Vedi il secondo snippet di configurazione in Load Balancing Our Centralized Logging with NGINX Streams per la nostra configurazione SSL a tre vie preferita).
Prospettive e test di NGINX
Diverse persone e organizzazioni hanno elogiato NGINX nel corso degli anni e da NGINX abbiamo riscontrato gli stessi vantaggi aggiuntivi di cui hanno parlato.
L'ingegnere del software Chris Lea di NodeSource confronta Apache con Microsoft Word, osservando che entrambe le applicazioni hanno un numero assurdamente elevato di funzionalità, ma che in genere ne sono necessarie solo alcune. Lea preferisce NGINX perché ha le funzionalità di cui hai bisogno, senza ingombro e prestazioni di gran lunga migliori.
Secondo Thomas Gieselman della società di venture capital BV Capital, alcune delle organizzazioni che hanno finanziato hanno risolto problemi relativi al ridimensionamento cambiando il proprio server in NGINX. Gieselman vede NGINX come una crescita rapida più semplice e accessibile a più organizzazioni.
Linux Journal ha condotto un test semplice, utilizzando il software di benchmark Apache, ab , per confrontare Apache con NGINX (rispettivamente versioni 2.2.8 e 0.5.22). I programmi top e vmstat sono stati utilizzati per verificare le prestazioni del sistema mentre i due server funzionavano contemporaneamente.
Il test ha mostrato che NGINX era più veloce di Apache come server di contenuti statici. Ciascuno dei due server funzionava in modo ottimale, con la simultaneità impostata a 100. Per soddisfare 6500 richieste al secondo, Apache ha utilizzato 17 MB di memoria, il 30% CPU e 4 processi di lavoro (in modalità thread). Per servire a una clip molto più veloce di 11.500 richieste al secondo, NGINX aveva bisogno di solo 1 MB di memoria, 15% CPU e 1 lavoratore.
Bob Ippolito ha fondato la piattaforma di gioco Mochi Media, che aveva 140 milioni di utenti unici al mese al suo apice , quindi comprende bene la richiesta di prestazioni elevate. Ippolito ha dichiarato nel 2006 di aver eseguito un test in cui ha utilizzato NGINX come proxy inverso per decine di milioni di richieste HTTP al giorno (ovvero poche centinaia al secondo) su un server.
Quando il server NGINX era al massimo della capacità, consumava circa il 10% CPU e 15 MB di memoria nella sua configurazione, che era FreeBSD (un sistema operativo open source basato su UNIX). Utilizzando gli stessi parametri, Apache ha generato 1000 processi e ha inghiottito un'enorme quantità di RAM. Pound ha creato thread eccessivi e ha utilizzato più di 400 MB per i vari stack di thread. Aveva leggermente bisogno di più CPU e perdeva oltre 20 MB all'ora.
Prova Atlantic.Net con NGINX
In Atlantic.Net, abbiamo riscontrato guadagni di prestazioni simili con NGINX come descritto da queste varie parti. Abbiamo anche beneficiato delle caratteristiche specifiche sopra descritte. Se stai attualmente utilizzando Apache o un altro server web, potresti provare NGINX per vedere se ottieni miglioramenti simili che possono aiutarti a gestire meglio la scalabilità e il bisogno sempre crescente di velocità. Prova NGINX con un Cloud Server oggi stesso.