Phanor Coll menu

5 maneras de configurar un Servidor Web

Al decidir qué arquitectura en el servidor se debe utilizar para su entorno, hay muchos factores a considerar, tales como el rendimiento, la escalabilidad, disponibilidad, confiabilidad, costo y facilidad de gestión.

Aquí está una lista de instalaciones de servidor de uso general, con una breve descripción de cada uno, incluyendo los pros y los contras. Tenga en cuenta que todos los conceptos tratados aquí se pueden utilizar en varias combinaciones entre sí, y que cada entorno tiene diferentes requisitos, por lo que no existe una configuración única, correcta.

1. Todo en un mismo servidor

Todo el ambiente se encuentra en un solo servidor. Para una aplicacion web tipica, esto puede incluir el servidor web, servidor de aplicaciones y el servidor de base de datos. Una variacion comun de esta configuracion es LAMP que significa (Linux, Apache, Mysql y PHP) en un solo servidor.

Caso de Uso: Es bueno para configurar una aplicacion de manera rapida y sencilla, pero ofrece poco en la manera en que se puede escalar y en el aislamiento de componentes.

PROS

  • Simple

CONS

  • La aplicacion y la base de datos luchan por los mismos recursos del servidor (CPU, Memoria, I/O, etc.) lo cual, a parte de dar un mal rendimiento, se hace dificil determinar la fuete de este mal rendimiento (aplicacion o base de datos).

  • No es escalable.

2. Servidor de base de datos separado

El sistema de administracion de base de datos (DBMS) puede estar separado del resto del ambiente de la aplicacion para eliminar el tener que compartir los recursos del servidor entre la aplicacion y la base de datos, y para incrementar la seguraidad al remover la base de datos de la DMZ o internet publica.

* Caso de Uso:* Es bueno para configurar una aplicacion de manera rapida y sencilla, pero evita que la aplicacion y la base de datos luchen por los mismos recursos del servidor.

PROS

  • Los niveles de la aplicacion y la base de datos no luchan por los mismos recursos del servidor (CPU, Memoria, I/O, etc.)

  • Se puede escalar verticalmente cada nivel agregando mas recursos a cualquiera de los servidores que lo necesite.

  • Dependiento de la configuracion, se puede incrementar la seguridad removiendo la base de datos de la DMZ

CONS

  • Un poco mas compleja de configurar que un solo servidor.

  • Pueden surgir problemas de rendimiento si aparecen problemas de conexion entre los dos servidores. (ej. los servidores estan geograficamente distantes uno del otro), o si el ancho de banda es muy bajo para la cantidad de data que se transfiere.

3. Balanceo de Carga (Proxy Inverso)

El balaceo de carga se puede agregar a un ambiente de servidores para mejorar el rendimiento y confiabilidad, distribuyendo la carga de trabajo a traves de multiples servidores. Si uno de los servidores encargados del balanceo de carga falla, otro servidor se ocupa del trafico entrante hasta que el servidor caido vuelva a funcionar. Tambien puede ser usado para servir multiples aplicaciones a traves del mismo dominio y puerto, usando el proxy inverso de la capa 7, capa de la aplicacion (layer 7 - application layer reverse proxy) .

Algunos ejemplos de software capaz de proveer balaceo de carga mediante proxy inverso: HAProxy, Nginx, and Varnish.

* Caso de Uso:* Util en ambientes que requieren escalabilidad agregando mas servidores, tambien llamado escalabilidad horizontal.

PROS

  • Permite la escalabilidad horizontal (e.j capacidad del ambientes puede ser escalado agregando mas servidores)

  • Puede protejer el ambientes de ataques DDOS, limitando la conexion de clientes a una cantidad y frecuencia moderada.

CONS

  • El balanceo de carga puede crear un cuello de botella en el rendimiento si no cuenta con los recursos necesarios, o si esta configurado de mala manera.

4. Acelerador HTTP (Caching Proxy Inverso)

Un acelerador HTTP, o caching HTTP mediante proxy inverso, puede ser usado para reducir el tiempo que tarda para servir contenido al usuario a traves de una variedad de tecnicas. La tecnica principal es haciendo cache de las respuestas de un servidor web o servidor de aplicaciones en memoria, para que las futuras solicitudes del mismo contenido puedan ser cargadas rapidamente, con menos interaccion con el servidor web o de aplicaciones.

Algunos ejemplos de software capaz de aceleracion HTTP: Varnish, Squid, Nginx.

Caso de Uso: Util en un ambiente con alto contenido dinamico o con gran cantidad de archivos con acceso.

PROS

  • Incrementa el rendimiento reduciendo la carga del CPU en el servidor web, a traves del caching y compresion, aumentando de este modo la capacidad de usuarios.

  • Puede ser usado para el balaceo de carga con proxy inverso.

  • Algunos servidores pueden proteger de ataques DDOS.

5. Replicacion de base de datos Maestro-Esclavo

Una manera de mejorar el rendimiento de un sistema de base de datos que ejecuta mas lecturas que escrituras, como un CMS, es de usar replicacion de base de datos maestro-esclavo. Esto requiere un nodo maestro y uno o mas nodos esclavos. En esta configuracion, todas las acciones de escribir-actualizar-eliminar se envian al nodo maestro, mientras que las acciones de lectura se pueden distribuir a traves de todos los nodos.

Caso de Uso: Util para incrementar el rendimiento de lectura para la base de datos de una aplicacion.

Aqui un ejemplo de la configuracion de maestro-esclavo, con un solo nodo esclavo:

PROS

  • Mejora el rendimiento de lectura de la base de datos, enviando las lecturas a traves de todos los nodos esclavos.

  • Puede mejorar el rendimiento de escritura usando solo el nodo maestro para las actualizaciones (no gasta tiempo en servir solicitudes en lectura)

CONS

  • La aplicacion que accede a la base de datos debe contener algun tipo de mecanismo que determine a cual nodo debe enviar las solicitudes de lectura y escritura.

  • Las actualizaciones a los nodos esclavos son asyncronas, asi que puede haber un chance de que sus contenidos esten desactualizados.

  • Si el nodo maestro falla, no se podra realizar actualizaciones a la base de datos hasta que se arregle el error.

  • No tiene conmutación por error en caso de que el nodo maestro falle.

==========

Aqui les dejo un ejemplo combinando los conceptos mencionados.

Es posible hacer balanceo de carga al servidor de cacheo, adicionalmente al servidor de aplicaciones, y usar la replicacion de la base de datos en un ambiente individual.
El proposito de combinar estas tecnicas es de obtener los beneficios de cada una sin introducir mayor complejidad.

Este es un diagrama de como el ambiente de servidores deberia ser:

Vamos asumir que el encargado de hacer balanceo de carga esta configurado para reconocer solicitudes estaticas (como imagenes, css, javascript, etc) y envia estas solicitudes directamente a los servidores de cacheo, y envia otras solicitudes a los servidores de aplicaciones.

Aqui una descripcion de lo que podria suceder cuando un usuario solicita contenido dinamico:

  • El usuario solicitia contenido dinamico de http://ejemplo.com (hace del balanceo de carga).

  • El balanceo de carga envia la solicitud al backend de la aplicacion.

  • El backend lee desde la base de datos y regresa el contenido solicitado al balacin de carga.

  • El balacin de carga regresa la data solicitada al usuario.

Ete ambiente todavia posee dos puntos de fallo (el balancin de carga el servidor de base de datos maestro), pero proveer la confiabilidad y rendimiento de los beneficios descritos en las secciones anteriores.

This environment still has two single points of failure (load balancer and master database server), but it provides the all of the other reliability and performance benefits that were described in each section above.

Conclusion

Ahora que esta familiarizado con lo basico en configuracion de servidores, podra tener una buena idea de que tipo de configuracion necesita para sus propios desarrollos. Si esta trabajando en mejorar su ambiente de servidores, hay que recordar que un proceso interactivo puede evitar la introduccion de configuraciones complejar.