Openness@Microsoft

Openness@Microsoft es el medio para mantener una comunicación sana y continua entre la comunidad de código abierto, donde se permite hablar abierta y honestamente acerca de los diferentes temas de interoperabilidad, como son UNIX, Linux, Windows, entre ot

nginx como proxy balanceador de carga de otros servidores Web - Jose M Parella

nginx como proxy balanceador de carga de otros servidores Web - Jose M Parella

  • Comments 1
  • Likes

Tomado de Jose M Parella @BUREADO

Hace 4 años y medio que escribí por primera vez sobre nginx, un servidor Web orientado a eventos, muy robusto y elegante. En ese momento, Aníbal Rojas, uno de los programadores, profesionales y personas más creativas que conozco, me habló de nginx y de como se estaba haciendo popular en el underground de Ruby. Decidí dar un paso y empaquetarlo para Debian, era la versión 0.4.2

Mi primera experiencia con nginx en un proyecto grande fue utilizando sus capacidades de proxy IMAP para escribir un módulo de autenticación (en Perl) que consultaba en OpenLDAP el destino de una conexión entrante. Esto se convirtió en el IMAP de entrada de lo que es ahora la CORPOELEC.

Luego, me pregunté si podía usar nginx como proxy para Puppet, en vez del terrible servidor Web integrado (WEBrick) que traía en su momento.

Y desde hace algunos años, lo uso para hacer caché junto a memcached, escenario que publicaré en los próximos días. Pero nunca lo había puesto como un proxy balanceador de carga ante otros servidores Web, así que aquí explico como, y en realidad es bastante sencillo. Para hacerlo más interesante usé IIS en Windows Server 2003R2, tratando de emular lo que una organización con aplicaciones en .NET quisiera hacer para ahorrar costos de appliances de balanceo de carga usando software libre. Como nginx.

En mi escenario, nginx 0.7.67 corre en Debian, dirección IP 192.168.56.104, y IIS corre en dos máquinas Windows Server 2003, direcciones IP 192.168.56.101 y 192.168.56.102. En ambas he instalado Acquia Drupal, tal y como se instala con Web Platform Installer, y he nombrado a los sitios WS1 y WS2. He comprobado que puedo ver el sitio por las direcciones IP de los servidores.

En nginx, la configuración en el site (por ejemplo, en /etc/nginx/sites-available/default en Debian y derivados) se remite a:

upstream mycluster { # en el contexto http, que es el default de este archivo
  server 192.168.56.101;
  server 192.168.56.102;
}
...
server {
  ...
  location / {
    proxy_pass http://mycluster;
  }
}

Puedo hacer algunas variaciones, por ejemplo, dentro de upstream puedo definir un puerto para cada server, puedo usar IPv6, o puedo definir un peso (weight) para hacer un balanceo con preferencias, por ejemplo si uno de los servidores con Windows tiene más recursos de cómputo.

Un service nginx restart es suficiente para que la nueva configuración está funcionando y pueda llamar directamente a la IP (o host name) de nginx y utilizar los recursos del cluster. En Firefox, con http://192.168.56.104/acquia-drupal y recargando puedo ver como cambia el título WS1 y WS2 con cada request.

Si pongo un weight=2 en el primer server, cada 3 requests veré 2 con WS1 y 1 con WS2, y así sucesivamente.

¿Por qué es útil? Nuevamente, si tengo una granja de servidores de aplicación, potencialmente propietarios (como los de IBM o Microsoft) y administrados por una unidad dedicada que no necesariamente conoce de infraestructura, y quiero una solución rápida a un problema común (balanceo de carga) entonces puedo ahorrarme el overhead de tener appliances y hacer una solución en software con nginx sobre Linux. Y con nginx en el borde puedo hacer aplicaciones interesantes como el proxy IMAP del que les hablé o incluso colocar memcache antes de los servidores Web de backend.

Ver original …

Comments
  • bien

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment