Hay dos desventajas principales:
Su carga no está distribuida uniformemente. Las sesiones adhesivas se mantendrán, de ahí el nombre. Si bien las solicitudes iniciales se distribuirán de manera uniforme, es posible que un número significativo de usuarios pasen más tiempo que otros. Si todos estos se configuran inicialmente en un solo servidor, ese servidor tendrá mucha más carga. Por lo general, esto realmente no tendrá un gran impacto y puede mitigarse al tener más servidores en su clúster.
Los proxies conglomeran a los usuarios en una sola IP, todo lo cual se enviaría a un solo servidor. Si bien eso generalmente no hace daño, nuevamente, aparte de aumentar las cargas de servidores individuales, los servidores proxy también pueden operar en un clúster. Una solicitud a su F5 desde dicho sistema no se enviaría necesariamente al mismo servidor si la solicitud sale de un servidor proxy diferente en su clúster proxy.
AOL estaba en un punto usando clústeres proxy, y realmente se atornilló con equilibradores de carga y sesiones pegajosas. La mayoría de los equilibradores de carga ahora ofrecerán sesiones fijas basadas en rangos netos de clase C, o con el caso de F5, sesiones fijas basadas en cookies que almacenan el nodo final en una cookie de solicitud web.
Si bien las sesiones basadas en cookies deberían funcionar, he tenido algunos problemas con ellas, y generalmente elijo sesiones basadas en IP. GRANDE SIN EMBARGO: Estoy trabajando principalmente en aplicaciones internas: el milagro de DMZ puede variar.
Dicho todo esto, hemos tenido un gran éxito con sitios que ejecutan detrás de F5 con sesiones fijas y sesiones In-Proc.
También es posible que desee echar un vistazo a uno de los sistemas de almacenamiento en caché distribuido en memoria como Memcached o Velocity para una alternativa a la sesión que se almacena en SQL o el servicio de memoria fuera de proceso. Te acercas a la velocidad de la memoria en proceso con la capacidad de ejecutarla en varios servidores.
