Introducción

Al decidir qué arquitectura de servidor usar para tu entorno, hay muchos factores a considerar, como el rendimiento, la escalabilidad, la disponibilidad, la confiabilidad, el costo y la facilidad de administración.

Aquí hay una lista de las configuraciones de servidor más utilizadas, con una breve descripción de cada una, que incluye las ventajas y desventajas. Ten en cuenta que todos los conceptos que aquí se mencionan pueden usarse en varias combinaciones entre sí, y que cada entorno tiene diferentes requisitos, por lo que no hay una configuración única y correcta.

1. Todo en un servidor

Todo el entorno reside en un único servidor. Para una aplicación web típica, eso incluiría el servidor web, el servidor de aplicaciones y el servidor de base de datos. Una variación común de esta configuración es un conjunto LAMP, que significa Linux, Apache, MySQL y PHP, en un solo servidor.

Caso de uso: ideal para configurar una aplicación rápidamente, ya que es la configuración más simple posible, pero ofrece poca escalabilidad y aislamiento de componentes.

Ventajas:

  • Sencilla

Desventajas:

  • La aplicación y la base de datos compiten por los mismos recursos del servidor (CPU, memoria, E/S, etc.) que, aparte de un posible rendimiento deficiente, pueden dificultar la determinación del origen (aplicación o base de datos) del rendimiento deficiente
  • No fácilmente escalable horizontalmente

Tutoriales relacionados:

2. Servidor de base de datos independiente

El sistema de administración de bases de datos (DBMS) se puede separar del resto del entorno para eliminar la contención de recursos entre la aplicación y la base de datos, y para aumentar la seguridad al eliminar la base de datos de la zona desmilitariza (DMZ) o Internet público.

Caso de uso: ideal para configurar una aplicación rápidamente, y evita que la aplicación y la base de datos compitan por los mismos recursos del sistema.

Ventajas:

  • Los niveles de aplicaciones y bases de datos no compiten por los mismos recursos del servidor (CPU, memoria, E/S, etc.)
  • Puedes escalar verticalmente cada nivel por separado, agregando más recursos a cualquier servidor que necesite mayor capacidad
  • Dependiendo de tu configuración, puedes aumentar la seguridad al eliminar tu base de datos de la DMZ

Desventajas:

  • Configuración un poco más compleja que un solo servidor
  • Pueden surgir problemas de rendimiento si la conexión de red entre los dos servidores es de alta latencia (es decir, los servidores están geográficamente distantes entre sí) o si el ancho de banda es demasiado bajo para la cantidad de datos que se transfieren.

3. Balanceo de carga (Proxy inverso)

Los balanceadores de carga se pueden agregar a un entorno de servidor para mejorar el rendimiento y la confiabilidad mediante la distribución de la carga de trabajo entre varios servidores. Si uno de los servidores que tiene carga balanceada falla, los otros servidores manejarán el tráfico entrante hasta que el servidor con fallas vuelva a funcionar correctamente. También se puede utilizar para mostrar múltiples aplicaciones a través del mismo dominio y puerto, utilizando un proxy inverso de capa 7 (capa de aplicación).

Ejemplos de software capaces de actuar como proxy inverso en el balanceo de carga: HAProxy, Nginx y Varnish.

Caso de uso: muy útil en un entorno que requiere escalar agregando más servidores, también conocido como escalado horizontal.

Ventajas:

  • Permite escalar horizontalmente, es decir, la capacidad del entorno se puede escalar agregándole más servidores
  • Puedes protegerte contra ataques DDOS al limitar las conexiones de los clientes a una cantidad y frecuencia razonables

Desventajas:

  • El balanceador de carga puede convertirse en un cuello de botella de rendimiento si no tiene suficientes recursos o si está mal configurado
  • Puede introducir complejidades que requieren una consideración adicional, como dónde realizar la terminación SSL y cómo manejar aplicaciones que requieren sesiones adhesivas
  • El balanceador de carga es un único punto de falla; Si se cae, todo tu servicio puede caer. Una configuración de alta disponibilidad (HA) es una infraestructura sin un solo punto de falla.

4. Acelerador HTTP (caché de proxy inverso)

Se puede usar un acelerador de HTTP, o el almacenamiento en caché de proxy inverso, para reducir el tiempo que se tarda en mostrar contenido a un usuario a través de una variedad de técnicas. La técnica principal empleada con un acelerador HTTP es el almacenamiento en caché de las respuestas de un servidor web o de aplicaciones en la memoria, por lo que las futuras solicitudes del mismo contenido se pueden atender rápidamente, con una interacción menos innecesaria con los servidores web o de aplicaciones.

Ejemplos de software capaces de acelerar HTTP: Varnish, Squid, Nginx.

Caso de uso: muy útil en un entorno con contenido de aplicaciones web dinámicas, o con muchos archivos de acceso común.

Ventajas:

  • Aumenta el rendimiento del sitio al reducir la carga de CPU en el servidor web, a través del almacenamiento en caché y la compresión, lo que aumenta la capacidad del usuario
  • Se puede utilizar como un balanceador de carga de proxy inverso
  • Algunos softwares de almacenamiento en caché pueden proteger contra ataques DDOS

Desventajas:

  • Requiere ajuste para obtener el mejor rendimiento de este.
  • Si la tasa de aciertos de caché es baja, podría reducir el rendimiento.

5. Replicación de base de datos réplica primaria

Una forma de mejorar el rendimiento de un sistema de base de datos que realiza muchas lecturas en comparación con las escrituras, como un CMS, es usar la replicación de la base de datos de réplica primaria. La replicación requiere un nodo primario y uno o más nodos de réplica. En esta configuración, todas las actualizaciones se envían al nodo primario y las lecturas se pueden distribuir entre todos los nodos.

Caso de uso: ideal para aumentar el rendimiento de lectura para el nivel de base de datos de una aplicación.

Este es un ejemplo de una configuración de replicación de réplica primaria, con un solo nodo de réplica:

Ventajas:

  • Mejora el rendimiento de lectura de la base de datos al distribuir las lecturas en las réplicas
  • Puede mejorar el rendimiento de escritura utilizando el primario exclusivamente para actualizaciones (no pasa tiempo sirviendo solicitudes de lectura)

Desventajas:

  • La aplicación que accede a la base de datos debe tener un mecanismo para determinar a qué nodos de base de datos debe enviar las solicitudes de actualización y lectura.
  • Las actualizaciones de las réplicas son asíncronas, por lo que existe la posibilidad de que sus contenidos estén desactualizados.
  • Si el primario falla, no se pueden realizar actualizaciones en la base de datos hasta que se corrija el problema
  • No tiene conmutación por error integrada en caso de falla del nodo primario

Ejemplo: combinando los conceptos

Es posible balancear la carga de los servidores de almacenamiento en caché, además de los servidores de aplicaciones, y usar la replicación de la base de datos en un solo entorno. El propósito de combinar estas técnicas es obtener los beneficios de cada una sin introducir demasiados problemas o complejidad. Aquí hay un diagrama de ejemplo de cómo podría verse un entorno de servidor:

Supongamos que el balanceador de carga está configurado para reconocer solicitudes estáticas (como imágenes, css, javascript, etc.) y enviarlas directamente a los servidores de almacenamiento en caché, y enviar otras solicitudes a los servidores de aplicaciones.

Aquí hay una descripción de lo que sucedería cuando un usuario envía un contenido dinámico de solicitudes:

  1. El usuario solicita contenido dinámico desde http://example.com/ (balanceador de carga)
  2. El Balanceador de carga envía una solicitud a la aplicación backend
  3. La aplicación backend lee desde la base de datos y devuelve el contenido solicitado al balanceador de carga
  4. El balanceador de carga devuelve los datos solicitados al usuario.

Si el usuario solicita contenido estático:

  1. El equilibrador de carga comprueba el back-end de caché para ver si el contenido solicitado está en caché (caché hit) o no (caché miss)
  2. Si es un caché hit: devuelve el contenido solicitado al balanceador de carga y salta al Paso 7. Si es un caché-miss: el servidor de caché reenvía la solicitud al servidor de aplicaciones, a través del balanceador de carga
  3. El balanceador de carga reenvía la solicitud a la aplicación backend
  4. La aplicación backend lee desde la base de datos y luego devuelve el contenido solicitado al balanceador de carga
  5. El balanceador de carga reenvía la respuesta al caché-backend
  6. El caché-backend almacena en caché el contenido y luego lo devuelve al balanceador de carga
  7. El balanceador de carga devuelve los datos solicitados al usuario.

Este entorno aún tiene dos puntos únicos de falla (balanceador de carga y servidor de base de datos principal), pero proporciona todos los otros beneficios de confiabilidad y rendimiento que se describieron en cada sección anterior.

Conclusión

Ahora que estás familiarizado con algunas configuraciones básicas del servidor, debes tener una buena idea de qué tipo de configuración usarías para tus propias aplicaciones. Si estás trabajando para mejorar tu propio entorno, recuerda que un proceso iterativo es el mejor para evitar introducir demasiadas complejidades demasiado rápido.

Te puede interesar