Ejecutamos una aplicación web que sirve API web para un número creciente de clientes. Para comenzar, los clientes eran generalmente redes domésticas, de oficina u otras redes inalámbricas que enviaban cargas http fragmentadas a nuestra API. Ahora nos hemos diversificado para manejar más clientes móviles. Los archivos van desde unos pocos k hasta varios conciertos, desglosados en trozos más pequeños y reensamblados en nuestra API.
Nuestro equilibrio de carga actual se realiza en dos capas, primero utilizamos DNS round robin para anunciar múltiples registros A para nuestra dirección api.company.com. En cada IP, alojamos un LVS de Linux: http://www.linuxvirtualserver.org/ , equilibrador de carga que analiza la dirección IP de origen de una solicitud para determinar a qué servidor API debe transferir la conexión. Estas cajas LVS están configuradas con heartbeatd para hacerse cargo de los VIP externos y las IP de las puertas de enlace internas entre sí.
Últimamente, hemos visto dos nuevas condiciones de error.
El primer error es cuando los clientes están oscilando o migrando de un LVS a otro, a mitad de carga. Esto a su vez hace que nuestros equilibradores de carga pierdan el rastro de la conexión persistente y envíen el tráfico a un nuevo servidor API, rompiendo así la carga fragmentada en dos o más servidores. Nuestra intención era que el valor Round TTL DNS TTL para nuestra api.company.com (que hemos establecido en 1 hora) sea honrado por los servidores de nombres de almacenamiento en caché posteriores, las capas de almacenamiento en caché del sistema operativo y las capas de aplicación del cliente. Este error ocurre para aproximadamente el 15% de nuestras cargas.
El segundo error que hemos visto con mucha menos frecuencia. Un cliente iniciará el tráfico a un cuadro LVS y se enrutará al servidor real A detrás de él. A partir de entonces, el cliente ingresará a través de una nueva dirección IP de origen, que el cuadro LVS no reconoce, por lo que enruta el tráfico en curso al servidor real B también detrás de ese LVS.
Dada nuestra arquitectura como se describe en la parte anterior, me gustaría saber cuáles son las experiencias de las personas con un mejor enfoque que nos permitirá manejar cada uno de los casos de error anteriores con más gracia.
Edición 3/5/2010:
Esto se parece a lo que necesitamos. Hashing de GSLB ponderado en la dirección IP de origen.