Hola usuario de nuestra página web, encontramos la solución a lo que estabas buscando, continúa leyendo y la verás más abajo.
Solución:
Solución 1:
Simplemente pon..
HaProxy es el mejor equilibrador de carga de código abierto del mercado.
Barniz es el mejor caché de archivos estáticos de código abierto del mercado.
Nginx es el mejor servidor web de código abierto del mercado.
(por supuesto, esta es mi opinión y la de muchas otras personas)
Pero, en general, no todas las consultas pasan por toda la pila.
Todo pasa por haproxy y nginx / multiple nginx’s.
La única diferencia es que usted “atornilla” el barniz para solicitudes estáticas.
- cualquier solicitud está balanceada de carga para redundancia y rendimiento (bueno, eso es redundancia escalable)
- cualquier solicitud de archivos estáticos llega primero al caché de barniz (bueno, eso es rápido)
- cualquier solicitud dinámica va directamente al backend (genial, el barniz no se usa)
En general, este modelo se ajusta a una arquitectura escalable y en crecimiento (elimine haproxy si no tiene varios servidores)
Espero que esto ayude: D
Nota: De hecho, también presentaré Pound para consultas SSL: D
Puede tener un servidor dedicado a descifrar solicitudes SSL y enviar solicitudes estándar a la pila de backend: D (Hace que toda la pila se ejecute de forma más rápida y sencilla)
Solucion 2:
Prefacio
Actualización en 2016. Las cosas están evolucionando, todos los servidores están mejorando, todos son compatibles con SSL y la web es más sorprendente que nunca.
A menos que se indique, lo siguiente está dirigido a profesionales de empresas y empresas emergentes, que brindan soporte a miles o millones de usuarios.
Estas herramientas y arquitecturas requieren una gran cantidad de usuarios / hardware / dinero. Puede probar esto en un laboratorio en casa o para ejecutar un blog, pero eso no tiene mucho sentido.
Como regla general, recuerde que desea mantenlo simple. Cada middleware adjunto es otra pieza fundamental de middleware que se debe mantener. La perfección no se logra cuando no hay nada que agregar sino cuando no queda nada para eliminar.
Algunas implementaciones comunes e interesantes
HAProxy (equilibrio) + nginx (aplicación php + almacenamiento en caché)
El servidor web es nginx ejecutando php. Cuando nginx ya está allí, también podría manejar el almacenamiento en caché y las redirecciones.
HAProxy ---> nginx-php
A ---> nginx-php
P ---> nginx-php
r ---> nginx-php
o ---> nginx-php
x ---> nginx-php
y ---> nginx-php
HAProxy (equilibrio) + Varnish (almacenamiento en caché) + Tomcat (aplicación Java)
HAProxy puede redirigir a Varnish según el URI de la solicitud (* .jpg * .css * .js).
HAProxy ---> tomcat
A ---> tomcat
---> tomcat
P ---> tomcat <----+
r ---> tomcat <---+|
o ||
x ---> varnish <--+|
y ---> varnish <---+
HAProxy (equilibrio) + nginx (SSL para el host y almacenamiento en caché) + Webserver (aplicación)
Los servidores web no hablan SSL aunque TODOS DEBEN HABLAR SSL (especialmente este enlace HAProxy-WebServer con información privada del usuario que pasa por EC2). Agregar un nginx local permite llevar SSL al host. Una vez que nginx esté allí, también podría hacer algo de almacenamiento en caché y reescritura de URL.
Nota: La redirección de puertos 443: 8080 está sucediendo, pero no es parte de las funciones. No tiene sentido hacer una redirección de puertos. El equilibrador de carga podría hablar directamente con el servidor web: 8080.
(nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A ---> nginx:443 -> webserver:8080
P ---> nginx:443 -> webserver:8080
r ---> nginx:443 -> webserver:8080
o ---> nginx:443 -> webserver:8080
x ---> nginx:443 -> webserver:8080
y ---> nginx:443 -> webserver:8080
Middleware
HAProxy: EL equilibrador de carga
Principales características:
- Equilibrio de carga (TCP, HTTP, HTTPS)
- Múltiples algoritmos (round robin, ip de origen, encabezados)
- Persistencia de la sesión
- Terminación SSL
Alternativas similares: nginx (servidor web multipropósito configurable como equilibrador de carga)
Diferentes alternativas: Nube (Amazon ELB, balanceador de carga de Google), Hardware (F5, fortinet, citrix netscaler), Otro y en todo el mundo (DNS, anycast, CloudFlare)
¿Qué hace HAProxy y cuándo TIENE QUE usarlo?
Siempre que necesite equilibrio de carga. HAProxy es la solución ideal.
Excepto cuando quieres muy barato O rápido y sucio O no tienes las habilidades disponibles, entonces puedes usar un ELB: D
Excepto cuando esté en banca / gobierno / similar y requiera usar su propio centro de datos con requisitos estrictos (infraestructura dedicada, conmutación por error confiable, 2 capas de firewall, material de auditoría, SLA para pagar x% por minuto de tiempo de inactividad, todo en uno), entonces usted puede poner 2 F5 en la parte superior del bastidor que contiene sus 30 servidores de aplicaciones.
Excepto cuando desee pasar de 100k HTTP (S) [and multi-sites], entonces DEBES tener múltiplos HAProxy con una capa de [global] equilibrio de carga frente a ellos (cloudflare, DNS, anycast). En teoría, el equilibrador global podría hablar directamente con los servidores web, lo que permitiría deshacerse de HAProxy. Por lo general, sin embargo, DEBE mantener HAProxy (s) como el (los) punto (s) de entrada público a su centro de datos y ajustar las opciones avanzadas para equilibrar de manera justa los hosts y minimizar la variación.
Opinión personal: Un proyecto pequeño, contenido y de código abierto, totalmente dedicado a UN PROPÓSITO VERDADERO. Entre las configuraciones más fáciles (UN archivo), el software de código abierto más útil y confiable que he encontrado en mi vida.
Nginx: Apache que no apesta
Principales características:
- Servidor web HTTP o HTTPS
- Ejecute aplicaciones en CGI / PHP / algún otro
- Redirección / reescritura de URL
- Control de acceso
- Manipulación de encabezados HTTP
- Almacenamiento en caché
- Proxy inverso
Alternativas similares: Apache, Lighttpd, Tomcat, Gunicorn ...
Apache era el servidor web de facto, también conocido como un clusterfuck gigante de docenas de módulos y miles de líneas. httpd.conf sobre una arquitectura de procesamiento de solicitudes rota. nginx rehaga todo eso, con menos módulos, una configuración (ligeramente) más simple y una mejor arquitectura central.
¿Qué hace nginx y cuándo TIENE QUE usarlo?
Un servidor web está diseñado para ejecutar aplicaciones. Cuando su aplicación está desarrollada para ejecutarse en nginx, ya tiene nginx y también puede usar todas sus funciones.
Excepto cuando su aplicación no está destinada a ejecutarse en nginx y nginx no se encuentra en ninguna parte de su pila (¿alguien compra Java?), entonces no tiene mucho sentido nginx. Es probable que las funciones de los servidores web existan en su servidor web actual y las otras tareas se manejan mejor con la herramienta dedicada adecuada (HAProxy / Varnish / CDN).
Excepto cuando su servidor web / aplicación carece de funciones, es difícil de configurar y / o prefiere morir antes que mirarlo (¿alguien Gunicorn?), entonces puede poner un nginx al frente (es decir, localmente en cada nodo) para realizar la reescritura de URL , envíe redirecciones 301, aplique el control de acceso, proporcione cifrado SSL y edite los encabezados HTTP sobre la marcha. [These are the features expected from a webserver]
Barniz: EL servidor de almacenamiento en caché
Principales características:
- Almacenamiento en caché
- Almacenamiento en caché avanzado
- Almacenamiento en caché de grano fino
- Almacenamiento en caché
Alternativas similares: nginx (servidor web multipropósito configurable como servidor de almacenamiento en caché)
Diferentes alternativas: CDN (Akamai, Amazon CloudFront, CloudFlare), hardware (F5, Fortinet, Citrix Netscaler)
¿Qué hace Varnish y cuándo DEBE usarlo?
Hace almacenamiento en caché, solo almacenamiento en caché. Por lo general, no vale la pena el esfuerzo y es una pérdida de tiempo. Prueba CDN en su lugar. Tenga en cuenta que el almacenamiento en caché es lo último que debe preocuparle al ejecutar un sitio web.
Excepto cuando está ejecutando un sitio web exclusivamente sobre imágenes o videos, entonces debe investigar la CDN a fondo y pensar seriamente en el almacenamiento en caché.
Excepto cuando se ve obligado a usar su propio hardware en su propio centro de datos (CDN no es una opción) y sus servidores web son terribles para entregar archivos estáticos (agregar más servidores web no ayuda), entonces Varnish es el último recurso.
Excepto cuando tiene un sitio con contenido principalmente estático pero complejo generado dinámicamente (consulte los párrafos siguientes), Varnish puede ahorrar una gran cantidad de potencia de procesamiento en sus servidores web.
El almacenamiento en caché estático está sobrevalorado en 2016
El almacenamiento en caché es casi sin configuración, sin dinero y sin tiempo. Simplemente suscríbase a CloudFlare, CloudFront o Akamai o MaxCDN. El tiempo que me toma escribir esta línea es más largo que el tiempo que toma configurar el almacenamiento en caché Y la cerveza que tengo en la mano es más cara que la suscripción mediana de CloudFlare.
Todos estos servicios funcionan desde el primer momento para estático * .css * .js * .png y más. De hecho, sobre todo honran a los Cache-Control directiva en el encabezado HTTP. El primer paso del almacenamiento en caché es configurar sus servidores web para que envíen las directivas de caché adecuadas. No importa qué CDN, qué Varnish, qué navegador esté en el medio.
Consideraciones de rendimiento
Varnish se creó en un momento en que los servidores web promedio se ahogaban para publicar una imagen de gato en un blog. Hoy en día, una sola instancia del servidor web asincrónico de palabras de moda de múltiples subprocesos moderno promedio puede entregar gatitos de manera confiable a todo un país. Cortesía de sendfile().
Hice algunas pruebas de rendimiento rápidas para el último proyecto en el que trabajé. Una sola instancia de tomcat podría servir de 21 000 a 33 000 archivos estáticos por segundo a través de HTTP (archivos de prueba de 20B a 12kB con diferentes recuentos de conexiones HTTP / cliente). El tráfico saliente sostenido supera los 2,4 Gb / s. La producción solo tendrá interfaces de 1 Gb / s. No se puede hacer mejor que el hardware, no tiene sentido ni siquiera probar Varnish.
Almacenamiento en caché de contenido dinámico cambiante complejo
Los servidores CDN y de almacenamiento en caché generalmente ignoran la URL con parámetros como ?article=1843, ignoran cualquier solicitud con cookies de sesión o usuarios autenticados, e ignoran la mayoría de los tipos MIME, incluido el application/json de /api/article/1843/info. Hay opciones de configuración disponibles, pero generalmente no son detalladas, sino "todo o nada".
Varnish puede tener reglas complejas personalizadas (consulte VCL) para definir qué se puede almacenar en caché y qué no. Estas reglas pueden almacenar en caché contenido específico por URI, encabezados y cookie de sesión de usuario actual y tipo y contenido MIME, TODOS JUNTOS. Eso puede ahorrar mucha potencia de procesamiento en los servidores web para un patrón de carga muy específico. Ahí es cuando Varnish es útil e IMPRESIONANTE.
Conclusión
Me tomó un tiempo entender todas estas piezas, cuándo usarlas y cómo encajan. Espero que esto le pueda ayudar.
Eso resulta ser bastante largo (6 horas para escribir. ¡Dios mío!: O). Tal vez debería comenzar un blog o un libro sobre eso. Dato curioso: no parece haber un límite en la longitud de la respuesta.
Solución 3:
Es cierto que las 3 herramientas comparten características comunes. La mayoría de las configuraciones están bien con cualquier combinación de 2 entre 3. Depende de cuál sea su propósito principal. Es común aceptar sacrificar algo de almacenamiento en caché si sabe que su servidor de aplicaciones es rápido en estática (por ejemplo: nginx). Es común sacrificar algunas funciones de equilibrio de carga si va a instalar decenas o cientos de servidores y no le importa aprovecharlos al máximo ni solucionar problemas. Es común sacrificar algunas funciones del servidor web si tiene la intención de ejecutar una aplicación distribuida con muchos componentes en todas partes. Aún así, algunas personas construyen granjas interesantes con todos ellos.
Debes tener en cuenta que estás hablando de 3 productos sólidos. Por lo general, no necesitará equilibrar la carga. Si necesita SSL frontal, entonces nginx primero como proxy inverso está bien. Si no lo necesita, entonces el barniz en el frente está bien. Luego, puede poner haproxy para equilibrar la carga de sus aplicaciones. A veces, también le gustará cambiar a diferentes granjas de servidores en el propio haproxy, dependiendo de los tipos de archivos o rutas.
A veces tendrás que protegerte contra fuertes ataques DDoS, y el haproxy al frente será más adecuado que los otros.
En general, no debe preocuparse por qué compromiso hacer entre sus opciones. Debe elegir cómo ensamblarlos para obtener la mejor flexibilidad para sus necesidades ahora y en el futuro. Incluso si apila varios de ellos varias veces, a veces puede ser correcto según sus necesidades.
¡Espero que esto ayude!
Solución 4:
Todas las demás respuestas son anteriores a 2010, por lo que se agrega una comparación actualizada.
Nginx
- Un servidor web completo, también se pueden utilizar otras funciones. Por ejemplo: Compresión HTTP
- Soporte SSL
- Muy liviano ya que Nginx fue diseñado para ser liviano desde el principio.
- Rendimiento de almacenamiento en caché de Near Varnish
- Cerca del rendimiento de equilibrio de carga de HAProxy
Barniz
- mejor para escenarios complejos de almacenamiento en caché e incorporación con las aplicaciones.
- mejor caché de archivos estáticos
- Sin soporte SSL
- Devorador de memoria y CPU
Haproxy
- el mejor equilibrador de carga, para funciones de equilibrio de carga de vanguardia, comparable a los equilibradores de carga de hardware
- SSL es compatible desde 1.5.0
- Más simple, siendo solo un proxy tcp sin una implementación http, lo que lo hace más rápido y menos propenso a errores.
Entonces, el mejor método parece ser implementarlos todos en un orden apropiado.
Sin embargo, para propósito general, Nginx es mejor a medida que obtiene un rendimiento superior al promedio para todos: Almacenamiento en caché, proxy inverso, equilibrio de carga, con muy poca sobrecarga en la utilización de recursos. Y luego tiene SSL y funciones completas de servidor web.
Solución 5:
Varnish admite el equilibrio de carga: http://www.varnish-cache.org/trac/wiki/LoadBalancing
Nginx tiene soporte para balanceo de carga: http://wiki.nginx.org/NginxHttpUpstreamModule
Simplemente configuraría esto con barniz + stunnel. Si necesitara nginx por alguna otra razón, solo usaría nginx + barniz. Puede hacer que nginx acepte conexiones SSL y las envíe a barniz, luego haga que varnish hable con nginx a través de http.
Algunas personas pueden incluir nginx (o Apache) en la mezcla porque estas son herramientas de propósito algo más general que Varnish. Por ejemplo, si desea transformar contenido (por ejemplo, usando XDV, filtros apache, etc.) en la capa de proxy, necesitaría uno de estos, porque Varnish no puede hacerlo por sí mismo. Algunas personas pueden estar más familiarizadas con la configuración de estas herramientas, por lo que es más fácil usar Varnish como un simple caché y hacer el equilibrio de carga en otra capa porque ya están familiarizados con Apache / nginx / haproxy como equilibrador de carga.
Comentarios y calificaciones del artículo
Si estás de acuerdo, tienes la opción de dejar un artículo acerca de qué le añadirías a este artículo.