Apache de equilibrio de carga en un presupuesto?

Estoy tratando de entender el concepto de equilibrio de carga para garantizar la disponibilidad y la redundancia para mantener a los usuarios contentos cuando las cosas van mal, en lugar de equilibrar la carga en aras de ofrecer una velocidad vertiginosa a millones de usuarios.

Tenemos un presupuesto limitado y tratamos de mantenernos en lo que hay mucho conocimiento disponible, por lo que ejecutar Apache en Ubuntu VPS parece ser la estrategia hasta que algún motor de búsqueda famoso nos adquiera ( incluye la ironía del sábado, tenga en cuenta ).

Al menos para mí, es una jungla completa de diferentes soluciones disponibles. Los propios mod_proxy y HAproxy de Apaches son dos que encontramos mediante una búsqueda rápida en Google, pero al no tener experiencia en el equilibrio de carga, no tengo idea de lo que sería apropiado para nuestra situación, o qué buscaríamos al elegir una solución para resolver nuestro problema. preocupaciones de disponibilidad.

¿Cuál es la mejor opción para nosotros? ¿Qué debemos hacer para obtener una alta disponibilidad mientras nos mantenemos dentro de nuestros presupuestos?

La solución que uso y que se puede implementar fácilmente con VPS es la siguiente:

• DNS se redondea (sp?) A 6 direcciones IP válidas diferentes.
• Tengo 3 equilibradores de carga con una configuración idéntica y uso de corosync / marcapasos para distribuir las 6 direcciones IP de manera uniforme (por lo que cada máquina tiene 2 direcciones).
• Cada uno de los equilibradores de carga tiene una configuración nginx + barniz . Nginx se encarga de recibir las conexiones y hacer reescrituras y algunos servicios estáticos, y pasarlos de nuevo a Varnish que realiza el equilibrio de carga y el almacenamiento en caché.

Este arco tiene las siguientes ventajas, en mi opinión sesgada:

1. corosync / pacemaker redistribuirá las direcciones IP en caso de que falle uno de los LB.
2. nginx se puede usar para servir SSL, ciertos tipos de archivos directamente desde el sistema de archivos o NFS sin usar el caché (videos grandes, audio o archivos grandes).
3. El barniz es un muy buen equilibrador de carga que soporta el peso, la comprobación del estado del backend y hace un trabajo excepcional como proxy inverso.
4. En caso de que se necesiten más LB para manejar el tráfico, simplemente agregue más máquinas al clúster y las direcciones IP se reequilibrarán entre todas las máquinas. Incluso puede hacerlo automáticamente (agregando y eliminando equilibradores de carga). Es por eso que uso 6 ips para 3 máquinas, para dejar espacio para el crecimiento.

En su caso, tener VPS físicamente separados es una buena idea, pero hace que compartir ip sea más difícil. El objetivo es tener un sistema redundante y resistente a fallas, y algunas configuraciones para el equilibrio de carga / HA terminan estropeándolo agregando un solo punto de falla (como un solo equilibrador de carga para recibir todo el tráfico).

También sé que preguntaste sobre apache, pero esos días tenemos herramientas específicas más adecuadas para el trabajo (como nginx y barniz). Deje apache para ejecutar las aplicaciones en el back-end y sirva utilizando otras herramientas (no es que apache no pueda hacer un buen equilibrio de carga o proxy inverso, es solo una cuestión de descargar diferentes partes del trabajo a más servicios para que cada parte pueda funcionar bien) es compartir).

HAproxy es una buena solución. La configuración es bastante sencilla.

Necesitará otra instancia de VPS para sentarse frente a al menos otros 2 VPS. Por lo tanto, para el equilibrio de carga / conmutación por error, necesita un mínimo de 3 VPS

Algunas cosas en las que pensar también es:

1. Terminación SSL. Si usa HTTPS: // esa conexión debería terminar en el equilibrador de carga, detrás del equilibrador de carga debería pasar todo el tráfico a través de una conexión sin cifrar.

2. Almacenamiento de archivos. Si un usuario sube una imagen, ¿a dónde va? ¿Simplemente se sienta en una máquina? Necesita alguna manera de compartir archivos instantáneamente entre máquinas: podría usar el servicio S3 de Amazon para almacenar todos sus archivos estáticos, o podría tener otro VPS que actuaría como un servidor de archivos, pero recomendaría S3 porque es redundante e increíblemente barato.

3. información de la sesión cada máquina en su configuración de equilibrador de carga debe poder acceder a la información de la sesión del usuario, porque nunca se sabe a qué máquina golpearán.

4. db: ¿tiene un servidor db separado? si solo tiene una máquina en este momento, ¿cómo se asegurará de que su nueva máquina tenga acceso al servidor db? Y si es un servidor VPS db separado, qué redundante es eso. No tiene necesariamente sentido tener front-end web de alta disponibilidad y un solo punto de falla con un servidor db, ahora también debe considerar la replicación db y la promoción de esclavos.

Así que he estado en tu lugar, ese es el problema con un sitio web que hace unos cientos de visitas al día a una operación real. Se vuelve complejo rápido. Espero que te haya dado algo de reflexión :)

Mi voto es para Linux Virtual Server como equilibrador de carga. Esto hace que el director de LVS sea un punto único de falla, así como un cuello de botella, pero

1. El cuello de botella no es, en mi experiencia, un problema; El paso de redireccionamiento de LVS es la capa 3, y extremadamente (computacionalmente) barato.
2. El único punto de falla debe abordarse teniendo un segundo director, con los dos controlados por Linux HA .

El costo puede mantenerse bajo haciendo que el primer director esté en la misma máquina que el primer nodo LVS, y el segundo director en la misma máquina que el segundo nodo LVS. Los nodos terceros y posteriores son nodos puros, sin implicaciones de LVS o HA.

Esto también le permite ejecutar cualquier software de servidor web que desee, ya que la redirección se realiza debajo de la capa de aplicación.

¿Qué tal esta cadena?

round robin dns> haproxy en ambas máquinas> nginx para separar archivos estáticos> apache

Posiblemente también use ucarp o heartbeat para garantizar que el haproxy siempre responda. Stunnel se sentaría frente a haproxy si necesita SSL también

Es posible que desee considerar el uso de un software de agrupación adecuado. Cluster Suite de RedHat (o CentOS) , o ClusterWare de Oracle . Estos pueden usarse para configurar clústeres activo-pasivos, y pueden usarse para reiniciar servicios, y fallar entre nodos cuando hay problemas serios. Esto es esencialmente lo que estás buscando.

Todas estas soluciones de clúster están incluidas en las respectivas licencias del sistema operativo, por lo que probablemente tenga un costo excelente. Requieren algún tipo de almacenamiento compartido, ya sea un montaje NFS o un disco físico al que acceden ambos nodos con un sistema de archivos en clúster. Un ejemplo de esto último serían los discos SAN con acceso de host múltiple permitido, formateados con OCFS2 o GFS . Creo que puede usar discos compartidos VMWare para esto.

El software de clúster se utiliza para definir 'servicios' que se ejecutan en nodos todo el tiempo, o solo cuando ese nodo está 'activo'. Los nodos se comunican a través de los latidos del corazón y también supervisan esos servicios. Pueden reiniciarlos si notan fallas y reiniciar si no pueden repararse.

Básicamente, configuraría una única dirección IP 'compartida' a la que se dirigiría el tráfico. Luego, apache y cualquier otro servicio necesario también se pueden definir y ejecutar solo en el servidor activo. El disco compartido se usaría para todo su contenido web, cualquier archivo cargado y sus directorios de configuración de apache. (con httpd.conf, etc.)

En mi experiencia, esto funciona increíblemente bien.

• No hay necesidad de DNS round robin, ni ningún otro equilibrador de carga de punto único de falla: todo golpea una IP / FQDN.
• Los archivos cargados por el usuario van a ese almacenamiento compartido y, por lo tanto, no le importa si su máquina falla.
• Los desarrolladores cargan contenido a esa única IP / FQDN con cero capacitación adicional, y siempre está actualizado si falla.
• El administrador puede quitar la máquina fuera de línea, parchearla, reiniciarla, etc. Luego fallar el nodo activo. Hacer una actualización requiere un tiempo de inactividad mínimo.
• Ese nodo ahora desactualizado se puede mantener sin parchear durante un tiempo, lo que hace que la recuperación de fallos sea un proceso igualmente fácil. (Más rápido que las instantáneas de VMWare)
• Los cambios en la configuración de Apache se comparten, por lo que no ocurre nada extraño durante una conmutación por error, porque un administrador olvidó hacer cambios en el cuadro sin conexión.

--Christopher Karel

El equilibrio de carga óptimo puede ser muy costoso y complicado. El equilibrio de carga básico solo debe garantizar que cada servidor atienda aproximadamente el mismo número de visitas en cualquier momento.

El método más simple de equilibrio de carga es proporcionar múltiples registros A en DNS. Por defecto, la dirección IP se configurará en un método round robin. Esto dará como resultado que los usuarios se distribuyan de manera relativamente uniforme entre los servidores. Esto funciona bien para sitios apátridas. Se requiere un método un poco más complejo cuando tiene un sitio con estado.

Para manejar requisitos con estado, puede usar redireccionamientos. Proporcione a cada servidor web una dirección alternativa como www1, www2, www3, etc. Redireccione la conexión www inicial a la dirección alternativa del host. Puede terminar con problemas de marcadores de esta manera, pero deberían estar distribuidos de manera uniforme en los servidores.

Alternativamente, el uso de una ruta diferente para indicar qué servidor está manejando la sesión con estado permitiría sesiones proxy que hayan cambiado el host al servidor original. Esto puede ser un problema cuando la sesión para un servidor fallido llega al servidor que se ha hecho cargo del servidor fallido. Sin embargo, salvo el software de agrupación, el estado se perderá de todos modos. Debido al almacenamiento en caché del navegador, es posible que no experimente muchas sesiones cambiando servidores.

La conmutación por error se puede manejar configurando el servidor para que se haga cargo de la dirección IP de un servidor fallido. Esto minimizará el tiempo de inactividad si falla un servidor. Sin el software de agrupamiento, las sesiones con estado se perderán si falla un servidor.

Sin la conmutación por error, los usuarios experimentarán un retraso hasta que su navegador falle a la siguiente dirección IP.

El uso de servicios Restful en lugar de sesiones con estado debería eliminar los problemas de agrupación en el front-end. Los problemas de agrupación en el lado del almacenamiento aún se aplicarían.

Incluso con equilibradores de carga frente a los servidores, es probable que tenga DNS round-robin frente a ellos. Esto asegurará que todos sus equilibradores de carga se utilicen. Agregarán otra capa a su diseño, con complejidad adicional y otro punto de falla. Sin embargo, pueden proporcionar algunas características de seguridad.

La mejor solución dependerá de los requisitos relevantes.

La implementación de servidores de imágenes para servir contenido como imágenes, archivos CSS y otro contenido estático puede facilitar la carga en los servidores de aplicaciones.

Generalmente uso un par de máquinas OpenBSD idénticas:

• Utilice RelayD para el equilibrio de carga, la supervisión del servidor web y el manejo de un servidor web fallido
• Use CARP para obtener una alta disponibilidad de los equilibradores de carga.

OpenBSD es ligero, estable y bastante seguro: perfecto para servicios de red.

• http://www.openbsd.org - Sitio principal
• http://www.openbsd.org/faq/pf/carp.html - Documentación de la carpa
• https://calomel.org/relayd.html - Un conjunto decente de información de procedimientos sobre RelayD

Para comenzar, recomiendo una configuración de layer3. Evita complicaciones en la configuración del firewall (PF). Aquí hay un ejemplo de archivo /etc/relayd.conf que muestra la configuración de un simple balanceador de carga de relé con monitoreo de los servidores web de fondo:

# $OpenBSD: relayd.conf,v 1.13 2008/03/03 16:58:41 reyk Exp $
#
# Macros
#

# The production internal load balanced address
intralbaddr="1.1.1.100"

# The interface on this load balancer with the alias for the intralbaddr address
intralbint="carp0"

# The list of web/app servers serving weblbaddress
intra1="1.1.1.90"
intra2="1.1.1.91"

# Global Options
#
# interval 10
timeout 1000
# prefork 5

log updates

# The "relaylb" interface group is assigned to the intralbint carp interface
# The following forces a demotion in carp if relayd stops
demote relaylb

#
# Each table will be mapped to a pf table.
#
table <intrahosts> { $intra1 $intra2 }

# Assumes local webserver that can provide a sorry page
table <fallback> { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration
#
http protocol httprelay {
        return error
        header append "$REMOTE_ADDR" to "X-Forwarded-For"
        header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        # header change "Connection" to "close"

        # Various TCP performance options
        tcp { nodelay, sack, socket buffer 65536, backlog 128 }

#       ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
#       ssl session cache disable
}

relay intra-httprelay {
        listen on $intralbaddr port 80
        protocol httprelay

        # Forward to hosts in the intrahosts table using a src/dst hash
        # The example shows use of a page with dynamic content to provide
        # application aware site checking.  This page should return a 200 on success,
        # including database or appserver connection, and a 500 or other on failure
        forward to <intrahosts> port http mode loadbalance \
                check http "/nlbcheck.asp" code 200

}

¿Le ha dado ec2 con cloudfoundry o tal vez Elastic beanstalk o simplemente un viejo escalado automático de AWS? un pensamiento? He estado usando eso y se escala bastante bien y ser elástico puede aumentar / disminuir sin ninguna intervención humana.

Dado que usted dice que no tiene experiencia con el equilibrio de carga, sugeriría estas opciones, ya que requieren un mínimo de "freír" el cerebro para comenzar a funcionar.

Podría ser un mejor uso de tu tiempo.