Jakie są wady lepkich sesji z modułami równoważenia obciążenia?

Mamy farmę internetową maszyn IIS7, które działają świetnie. Przed nimi znajduje się sprzętowy moduł równoważenia obciążenia F5 Big-IP , który również działa dobrze :)

_{(źródło: www.f5.com )}

Obecnie używamy ASP.NET State Servicedo obsługi naszego stanu OutProc . Jest to wymagane, gdy masz farmę internetową, aby zachować dowolny rodzaj informacji o sesji.

Zastanawiałem się, czy moglibyśmy mieć lepkie sesje na F5 Big-IP i dlatego zmienić z OutProc z powrotem na InProc? Jeśli tak, jakie są tego wady? Znam wady InProc vs. OutProc, więc nie martw się o wyjaśnienie tego. Bardziej interesują mnie zalety / wady lepkich sesji bez F5 Big-IP .

Czy ktoś może rzucić trochę światła i / lub doświadczyć?

Istnieją dwie główne wady:

1. Twoje obciążenie nie jest równomiernie rozłożone. Przyklejone sesje będą się trzymać, stąd nazwa. Chociaż początkowe żądania będą rozłożone równomiernie, może się okazać, że znaczna liczba użytkowników spędza więcej czasu niż inni. Jeśli wszystkie z nich są początkowo ustawione na jeden serwer, serwer ten będzie miał znacznie większe obciążenie. Zazwyczaj nie ma to większego wpływu i można je złagodzić, mając więcej serwerów w klastrze.

2. Serwery proxy zlepiają użytkowników w pojedyncze adresy IP, z których wszystkie zostaną przesłane na jeden serwer. Chociaż zwykle nie wyrządza to szkody, ponownie oprócz zwiększenia obciążenia poszczególnych serwerów, serwery proxy mogą również działać w klastrze. Żądanie wysłane do twojego F5 z takiego systemu niekoniecznie zostanie odesłane z powrotem do tego samego serwera, jeśli żądanie pochodzi z innego serwera proxy w ich klastrze proxy.

AOL w pewnym momencie korzystał z klastrów proxy i naprawdę miał problemy z równoważeniem obciążenia i lepkimi sesjami. Większość modułów równoważących obciążenie będzie teraz oferować sesje lepkie oparte na zakresach sieci klasy C lub, w przypadku F5, sesje trwałe oparte na plikach cookie, które przechowują węzeł końcowy w pliku cookie żądania internetowego.

Chociaż sesje oparte na plikach cookie powinny działać, miałem z nimi pewne problemy i zwykle wybieram sesje oparte na adresie IP. DUŻY JEDNAK: Pracuję głównie nad aplikacjami wewnętrznymi - przebieg DMZ może się różnić.

Biorąc to wszystko pod uwagę, odnieśliśmy duży sukces w witrynach obsługujących F5 z lepkimi sesjami i sesjami In-Proc.

Możesz także rzucić okiem na jeden z rozproszonych w pamięci systemów buforowania, takich jak Memcached lub Velocity, na alternatywę dla sesji przechowywanej w SQL lub usługi pamięci poza proc. Zbliżasz się do prędkości pamięci wewnętrznej z możliwością uruchomienia jej na kilku serwerach.

Niedawno przeczytałem świetny artykuł w TechNet dotyczący „Zapewnienia skalowalności dla aplikacji ASP.NET”. Przeszedł do zalet i wad każdego możliwego rozwiązania. Przeczytaj:

TechNet Czerwiec 2009 - Zapewnienie skalowalności aplikacji ASP.NET

Oprócz doskonałej odpowiedzi od Christophera, lepkie sesje oznaczają, że straciłeś kilka ogromnych zalet nadmiarowych serwerów - możliwość obniżenia jednego lub więcej w celu konserwacji oraz przejrzystość w przypadku awarii systemu.

Uważam, że lepkie sesje są silnym wskaźnikiem słabej architektury aplikacji i / lub słabego programowania. Moje motto brzmi „unikaj za wszelką cenę”.