Este artículo también aparece en el blog de NGINX. Leer en NGINX>
Tradicionalmente, el desarrollo web y el alojamiento se realizaban principalmente con la pila LAMP ; LAMP es la abreviatura de L inux (sistema operativo), A pache (servidor web), M ySQL (base de datos) y P HP (lenguaje de programación), los componentes principales que luego se usaron para ejecutar sitios empresariales.
A medida que las pilas web y los balanceadores de carga se vuelven más ágiles, y las necesidades comerciales exigen un mejor rendimiento y estabilidad, se vuelve cada vez más común reemplazar Apache HTTP Server con una alternativa liviana y altamente escalable, NGINX. Con NGINX, la pila se conoce como LEMP - L entrada, (e )NGINX, M ySQL, P HP.
Atlantic.Net ofrece una gama de soluciones que incluye almacenamiento, alojamiento y servicios administrados. Nuestra plataforma de alojamiento VPS tiene una opción LEMP de un clic que tiene su pila lista y funcionando en menos de 30 segundos. Para aquellos que prefieren ejecutar NGINX desde Docker, tenemos servidores en la nube Linux y Windows con Docker. También proporcionamos servicios administrados para aquellos que desean o necesitan ayuda para configurar NGINX.
Hacemos un uso frecuente y sólido de NGINX no solo como servidor web, sino también como proxy inverso y equilibrador de carga. Decidimos usar NGINX después de investigar soluciones de equilibrio de carga para nuestro clúster de registro centralizado. Mediante el uso de NGINX en varias capacidades, logramos una alta disponibilidad para nuestros servidores front-end y back-end, mientras mantenemos un espacio extremadamente pequeño, todo gracias a las eficiencias de NGINX en el uso de RAM y CPU.
En términos de qué funciones específicas de NGINX son más útiles, algunas que consideramos particularmente poderosas son el equilibrio de carga y proxy TCP/UDP, el control de acceso y los protocolos de enlace SSL de tres vías. En esta publicación de blog, describiré cómo usamos cada una de estas capacidades.
Equilibrio de carga de nuestro registro centralizado con transmisiones NGINX
Dado que la necesidad de proporcionar registros para la auditoría y la seguridad se ha convertido en un enfoque más importante, en Atlantic.Net buscábamos la solución adecuada de equilibrio de carga y proxy, no solo para el tráfico HTTP, sino también para syslog. Syslog se envía comúnmente en formato de Protocolo de datagramas de usuario (UDP), por lo que necesitábamos algo que manejara tanto UDP como HTTP.
Aquí es donde NGINX stream Los módulos entraron en juego, ya que permiten el equilibrio de carga del tráfico UDP. El equilibrio de carga utiliza una serie de servidores back-end para una distribución eficiente del tráfico de red. Como sugiere el término, el propósito es distribuir la carga de trabajo de manera uniforme.
En el siguiente fragmento, enviamos mensajes de syslog desde nuestra infraestructura de red a nuestro backend de registro:
...
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;
}
}
... Las transmisiones también funcionan bien para SSL sobre TCP, como se muestra en el siguiente ejemplo que envía registros de Filebeat de forma segura:
...
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;
}
... Como puede ver, NGINX es capaz de utilizar proxy y equilibrar la carga del tráfico UDP y del Protocolo de control de transmisión (TCP).
El uso de proxies inversos y equilibrio de carga es útil cuando tiene un servicio, una base de datos o un programa que se comunica a través de UDP o TCP. En un nivel básico, estos métodos son relevantes cuando tiene el mismo servicio, base de datos o instancia de programa ejecutándose en varios servidores ascendentes, administrados por NGINX. En Atlantic.Net, también aprovechamos el proxy inverso de NGINX, porque proporciona una capa adicional de ofuscación a nuestros servicios de back-end críticos, con muy poca sobrecarga.
Control de acceso
Otro paso importante para asegurar nuestro registro centralizado fue evitar la eliminación de cualquier dato. Además, las listas de control de acceso (ACL) son muy útiles para limitar el tráfico según la dirección IP. Para nuestros propósitos, queríamos permitir el acceso a los datos de registro solo desde nuestra red de administración interna.
NGINX nos brinda una forma de delinear con mucha precisión qué tipos de acciones HTTP se pueden realizar y desde dónde, como se puede ver aquí:
...
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 también es compatible con una función de IP transparente que nos permite ver la dirección IP de origen después de que la solicitud pasa por el proxy. Esta capacidad ayuda con el seguimiento de dónde se originan los registros. NGINX hace que esta tarea sea muy fácil:
...
server {
listen 5915 udp;
proxy_timeout 0s;
proxy_bind $remote_addr transparent;
proxy_pass vmware_udp;
}
... Apretones de manos SSL de tres vías
NGINX maneja limpiamente ambos lados de las transferencias de SSL para nuestro registro centralizado. Esta implementación es muy importante, ya que significa que tanto los servidores internos como los de los clientes pueden comunicarse de forma segura con NGINX. Cada servidor que se registra tiene su propio certificado para la comunicación SSL bidireccional, lo que reduce aún más las vulnerabilidades. Luego, NGINX transmite los datos de forma segura a través de nuestra red interna, a través de SSL, a los servidores de registro. En total, hay tres certificados SSL involucrados para cada comunicación de extremo a extremo que admita una transmisión segura. (Consulte el segundo fragmento de configuración en Equilibrio de carga de nuestro registro centralizado con transmisiones NGINX para conocer nuestra configuración SSL de tres vías preferida).
Perspectivas y pruebas de NGINX
Varias personas y organizaciones han elogiado a NGINX a lo largo de los años, y hemos experimentado los mismos beneficios adicionales de NGINX que ellos mencionan.
El ingeniero de software Chris Lea de NodeSource compara Apache con Microsoft Word y señala que ambas aplicaciones tienen una cantidad absurdamente grande de funciones, pero que, por lo general, solo se necesitan unas pocas. Lea prefiere NGINX porque tiene las funciones que necesita, sin el volumen y con un rendimiento mucho mejor.
Según Thomas Gieselman, de la firma de capital de riesgo BV Capital, algunas de las organizaciones que financiaron solucionaron problemas relacionados con la escalabilidad al cambiar su servidor a NGINX. Gieselman considera que NGINX hace que el crecimiento rápido sea más simple y accesible para más organizaciones.
Linux Journal realizó una prueba sencilla, utilizando el software de referencia de Apache, ab , para comparar Apache con NGINX (versiones 2.2.8 y 0.5.22, respectivamente). Los programas top y vmstat se utilizaron para comprobar el rendimiento del sistema mientras los dos servidores se ejecutaban simultáneamente.
La prueba mostró que NGINX era más rápido que Apache como servidor de contenido estático. Cada uno de los dos servidores funcionó de manera óptima, con una simultaneidad establecida en 100. Para atender 6500 solicitudes por segundo, Apache usó 17 MB de memoria, 30 % de CPU y 4 procesos de trabajo (en modo subproceso). Para atender a un ritmo mucho más rápido de 11 500 solicitudes por segundo, NGINX solo necesitaba 1 MB de memoria, 15 % de CPU y 1 trabajador.
Bob Ippolito fundó la plataforma de juegos Mochi Media, que tenía 140 millones de usuarios únicos por mes en su punto máximo, por lo que comprende bien la demanda de alto rendimiento. Ippolito dijo en 2006 que realizó una prueba en la que usó NGINX como proxy inverso para decenas de millones de solicitudes HTTP por día (es decir, unos cientos por segundo) en un servidor.
Cuando el servidor NGINX estaba al máximo de su capacidad, consumía aproximadamente un 10 % de CPU y 15 MB de memoria en su configuración, que era FreeBSD (un sistema operativo de código abierto basado en UNIX). Usando los mismos parámetros, Apache generó 1000 procesos y engulló una gran cantidad de RAM. Pound creó hilos excesivos y usó más de 400 MB para las distintas pilas de hilos. Necesitaba ligeramente más CPU y se filtraban más de 20 MB por hora.
Pruebe Atlantic.Net con NGINX
En Atlantic.Net, hemos encontrado ganancias de rendimiento similares con NGINX según lo descrito por estas diversas partes. También nos hemos beneficiado de las características específicas descritas anteriormente. Si actualmente está utilizando Apache u otro servidor web, es posible que desee probar NGINX para ver si obtiene mejoras similares que pueden ayudarlo a manejar mejor la escalabilidad y la necesidad cada vez mayor de velocidad. Pruebe NGINX con un servidor en la nube hoy.