dlaczego nie ma przykładów skalowalnych w poziomie oprogramowania równoważących obciążenie równoważących ssl?

Mam mnóstwo pytań dotyczących ssl, sesji lokalnych i równoważenia obciążenia, które wydają się być ze sobą powiązane, dlatego z góry przepraszam za długość tego pytania.

Mam stronę internetową, która wykorzystuje sesje oparte na plikach. Charakter strony jest taki, że większość z nich to http, ale niektóre sekcje to ssl. Obecnie, ze względu na sesje oparte na plikach, wszelkie żądania ssl muszą trafić na ten sam serwer, co poprzednie żądania HTTP.

Z powodu ograniczeń czasowych chcę zrobić najłatwiejszą możliwą rzecz w celu zrównoważenia obciążenia zwiększonym ruchem http i ssl.

Wydaje się, że istnieją 2 opcje dla lepkich algorytmów równoważenia obciążenia:

• oparte na ip
• na podstawie plików cookie

Rozwiązanie oparte na IP prawdopodobnie będzie działać, ale algorytm mieszający potencjalnie zmieni serwer, do którego przechodzi użytkownik, gdy serwer ulegnie awarii lub zostanie dodany, co jest niepożądane przy obecnej konfiguracji sesji opartej na plikach. Przypuszczam również, że technicznie jest możliwe, aby użytkownik mógł legalnie zmienić IP podczas przeglądania strony internetowej.

Algorytm oparty na plikach cookie wydaje się lepszy, ale niemożność sprawdzenia pliku cookie po zaszyfrowaniu przez ssl pozornie stwarza własne problemy.

Poszukiwałem przykładów, jak ładować balans obciążenia ssl, i nie mogę znaleźć żadnych wyraźnych przykładów konfiguracji, które mogą wykonywać równoważenie obciążenia oparte na plikach cookie ORAZ, które mogą poradzić sobie ze zwiększonym obciążeniem ssl przez dodanie innego dekodera ssl.

Większość jawnych przykładów, które widziałem, zawiera dekoder ssl (zwykle sprzętowy, apache_mod_ssl lub nginx) siedzący między klientem przeglądarki a modułem równoważenia obciążenia. Przykłady zwykle wydają się mieć coś takiego (zmodyfikowane z http://haproxy.1wt.eu/download/1.3/doc/architecture.txt ):

      192.168.1.1 192.168.1.11-192.168.1.14
 ------- + ----------- + ----- + ----- + ----- +
        | | | | |       
     + - + - + + - + - + + - + - + + - + - + + - + - +    
     | LB1 | | A | | B | | C | | D |    
     + ----- + + --- + + --- + + --- + + --- +    
     apache 4 tanie serwery sieciowe
     mod_ssl
     haproksy 

Część dekodująca ssl w powyższym przykładzie wydaje się być potencjalnym wąskim gardłem, które nie jest skalowalne w poziomie.

Patrzyłem na haproxy i wydaje się, że ma opcję „mode tcp”, która pozwala na coś takiego, co pozwala na posiadanie wielu dekoderów ssl:

              haproksy
                 |
            -------------
            | |
ssl-decoder-1 ssl-decoder2
            | |
        -------------------
        | | |  
      web1 web2 web3

Jednak w takiej konfiguracji wygląda na to, że utraciłbyś adres IP klienta, ponieważ haproxy nie dekoduje ssl: https://cloud-support.engineyard.com/discussions/problems/335-haproxy-not-passing-x-forwarded -dla

Spojrzałem również na nginx i nie widzę żadnych wyraźnych przykładów skalowalnych poziomo dekoderów ssl. Wydaje się, że istnieje wiele przykładów osób, które mają nginx jako potencjalne wąskie gardło. Przynajmniej ten link wydaje się sugerować, że nginx nie ma nawet opcji konfiguracji podobnej do haproxy, w której można stracić ip, mówiąc, że nginx „nie obsługuje przezroczystego przekazywania połączeń TCP do backendu” Jak przekazać Apache Ruch SSL przez serwer proxy Nginx? .

Pytania:

• Dlaczego wydaje się, że nie ma więcej przykładów konfiguracji dodających więcej dekoderów ssl, aby poradzić sobie ze zwiększonym ruchem?
• Czy to dlatego, że krok dekodowania ssl jest tylko teoretycznym wąskim gardłem, a praktycznie mówiąc, jeden dekoder zasadniczo wystarczy, z wyjątkiem witryn z absurdalnym ruchem?
• Innym możliwym rozwiązaniem, które przychodzi mi na myśl, być może każdy, kto ma tak zwiększone potrzeby ssl, ma również scentralizowany magazyn sesji, więc nie ma znaczenia, który serwer WWW trafi klient na kolejne żądania. Następnie możesz włączyć mod_ssl lub równoważny na każdym serwerze internetowym.
• Wspomniane powyżej rozwiązanie haproxy wydaje się działać (oprócz problemu z adresem IP klienta), ale ktoś napotkał rozwiązanie równoważące obciążenie oparte na plikach cookie, które działałoby, zwiększając liczbę dekoderów przy jednoczesnym zachowaniu adresu IP klienta, czy może technicznie nie możliwe (ponieważ musisz zdekodować żądanie uzyskania adresu IP klienta, w takim przypadku mamy wąskie gardło dekodera).

Zakładając, że wszystko, co powiedziałem, jest prawdą, wydają się to moje opcje:

• używaj haszowania IP (złe dla użytkowników, którzy potencjalnie mogą legalnie zmienić IP, oraz dla scenariuszy dodawania i upuszczania serwerów)
• użyj nginx lub mod_ssl jako pierwszego programu dotykającego żądania ssl, będzie to potencjalne wąskie gardło dekodowania ssl
• użyj haproxy jako pierwszego programu dotykającego żądania ssl, uzyskując poziomą skalowalność ssl, ale żyje bez ips zalogowanych na poziomie serwera dla żądań ssl (prawdopodobnie tymczasowo OK)
• w dłuższej perspektywie przejdź do mobilnego lub scentralizowanego sklepu z sesjami, dzięki czemu niepotrzebne sesje nie będą konieczne

„Najprostszą rzeczą”, z całą powagą, jest przejście do scentralizowanego sklepu z sesjami. Musisz skonfigurować całą tę instalację wodno-kanalizacyjną z modułami równoważenia obciążenia, haproxy, SSL i resztą, gdy każdy kawałek kodu do obsługi sesji, jaki kiedykolwiek widziałem, sprawia, że ​​podłączenie różnych silników pamięci staje się niemal trywialne, więc odrobina kodu i bardzo, bardzo mała dodatkowa złożoność rozwiązuje wszystkie problemy.

womble ma rację co do wspólnego sklepu z sesjami, dzięki czemu wszystko jest znacznie łatwiejsze. Oprócz jego odpowiedzi mogę nieco rozwinąć części pytania dotyczące równoważenia obciążenia:

Dlaczego wydaje się, że nie ma więcej przykładów konfiguracji dodających więcej dekoderów ssl, aby poradzić sobie ze zwiększonym ruchem?

Nowoczesne wielordzeniowe komputery PC mogą wykonywać kilka tysięcy transakcji SSL na sekundę. A jeśli stanie się to wąskim gardłem, wówczas dedykowane urządzenie od F5 , Citrix, Cisco itp. Może być jeszcze szybsze. Dlatego większość witryn nigdy nie przerasta dobrego rozwiązania SSL i równoważenia obciążenia na jednym urządzeniu.

Zakładając, że wszystko, co powiedziałem, jest prawdą, wydają się to moje opcje:

Istnieją opcje skalowania deszyfrowania SSL w poziomie, jeśli zajdzie taka potrzeba.

Powszechnym podejściem jest używanie DNS Round Robin do wysoce dostępnych par akceleratorów SSL, tj. Publikowanie wielu adresów IP dla domeny, każdy adres IP wskazuje parę akceleratorów SSL.

W takim przypadku możesz martwić się przekroczeniem limitu czasu TTL usługi DNS w trakcie sesji użytkownika, powodując, że użytkownik wpadnie na inny serwer aplikacji. To nie powinno być częstym zjawiskiem, ale może się zdarzyć. Współużytkowany magazyn sesji jest powszechnym rozwiązaniem, ale można go obsługiwać na inne sposoby.

Jako jeden przykład możesz oddzielić odszyfrowanie SSL od równoważenia serwera aplikacji. Obsługa protokołu SSL wymaga większego obciążenia procesora niż podstawowe równoważenie obciążenia, dlatego jeden moduł równoważenia obciążenia powinien być w stanie nasycić kilka akceleratorów SSL. Lubię to:

Internet --> DNS round robin to multiple SSL accelerators --> plain HTTP to a single HTTP load balancer --> plain HTTP to multiple application servers

Jak wspomniano na początku, wspólny magazyn sesji upraszcza wiele rzeczy i jest prawie na pewno lepszym długoterminowym rozwiązaniem niż nakładanie dużej złożoności na warstwę SSL / równoważenia obciążenia.

Fajnie jest odpowiadać na takie dwuletnie pytania, gdy ewoluowały produkty. Obecnie haproxy obsługuje protokół PROXY, który pozwala mu przesłać adres IP klienta do następnego przeskoku nawet w trybie czystego TCP. Obsługuje także natywny SSL, a także lepkość SSL, jeśli chcesz go używać jako pierwszej warstwy przed farmą SSL (prawdopodobnie wykonaną z serwerów haproxy). Wygląda więc na to, że twoja prośba była nieco wcześniejsza niż wcześniej i że implementacje nadrobiły zaległości :-)

Zgadzam się z Womble i Jesperem tutaj. Najłatwiejszą / najlepszą drogą jest naprawa kodu. Oczywiście jako administratorzy często nie mamy takiej opcji, ale nawet w takim przypadku istnieje wystarczająca liczba sztuczek, które można wyciągnąć, aby uzyskać stosunkowo tani nowoczesny sprzęt, który można skalować wystarczająco daleko, nawet jeśli nie jest on naprawdę poziomy.

Chciałem tylko napisać komentarz, w którym obawiasz się utraty IP klienta. W dowolnym z głównych rozwiązań L7 / proxy możesz wstawić do żądania nagłówek X-Forwarded-For (lub cokolwiek chcesz). Następnie na serwerze WWW zaplecza odbierającym żądanie można zmienić format pliku dziennika, aby zarejestrować tę wartość w tym samym miejscu w pliku, którego użył do zarejestrowania adresu IP klienta warstwy3. W ten sposób żadne oprogramowanie do analizy dzienników nie widzi różnicy (podobnie jak Ty podczas tailowania).

Wszystko jest kompromisowe i nie słyszeliśmy wystarczająco dużo o twojej konfiguracji, aby wiedzieć, ale mając do czynienia z trio ha-proxy, nginx i lakierów, prawdopodobnie dobrym pomysłem jest przesunięcie równoważenia obciążenia do narzędzia warstwy pośredniej. To rozwiąże problem ssl, a także zapewni wiele nowych opcji, takich jak buforowanie, przełączanie treści i manipulowanie nagłówkami.

Kilka przypadkowych myśli;)

Najpierw zastrzel osobę, która zdecydowała się użyć danych sesji opartych na plikach. Nie ma możliwości, aby odczyt / zapis danych z systemu plików był szybszy niż powrót do źródła w celu pobrania potrzebnych danych. To jest o NAJGORSZY sposób na to.

Osobiście nigdy nie widziałem sytuacji, w której przechowywanie danych w sesji byłoby lepsze niż pobieranie ich bezpośrednio z bazy danych w razie potrzeby. To powiedziawszy, widziałem, gdzie użycie memcache lub podobnych strategii buforowania może pomóc w skalowaniu witryny do milionów użytkowników, ale nie jest to nawet takie samo jak w przypadku sesji.

Po drugie, właśnie znalazłeś najważniejszy powód, aby w ogóle nie używać sesji: równoważenie obciążenia. FYI - Przyklejony nie oznacza Utknąć. Nawet przy włączonych sesjach Sticky istnieje bardzo realna możliwość przeniesienia użytkownika na inny serwer w trakcie korzystania z aplikacji. Stanie się to w najbardziej nieodpowiednich momentach. Lepkie oznacza po prostu, że moduł równoważenia obciążenia spróbuje odepchnąć użytkownika z powrotem do serwera, na którym uruchomiono, ale nie jest to w żadnym wypadku gwarancją.

Ten punkt zwykle prowadzi ludzi do zapisywania sesji z powrotem w bazie danych ... Co, moim zdaniem, jest całkowitym niepowodzeniem . Aby sesja działała, należy ją ładować i zapisywać na każdym żądaniu strony. Gdy jest przechowywany w bazie danych (niezbędny dla serwerów z równoważeniem obciążenia), wymaga to dwóch zapytań do serwera: pierwszy, aby uzyskać dane, drugi, aby zapisać wszelkie aktualizacje.

Częścią niepowodzenia jest to, że ludzie zwykle używają sesji, więc nie muszą wracać do bazy danych, aby pobrać takie rzeczy, jak nazwa użytkownika ... Ale jeśli strona musi wysłać zapytanie do bazy danych, aby załadować sesję, to ... cóż, powinieneś zobaczyć tutaj problem z logiką.

Jest tylko gorzej z sesjami ... ponieważ procesor stron musi zapisać dane sesji z powrotem do bazy danych na końcu cyklu życia strony ... na wypadek, gdyby coś się zmieniło. Co oznacza, że ​​zamiast jednego zapytania, aby wyciągnąć nazwę użytkownika, otrzymujesz dwa. Dla każdego załadowania pojedynczej strony. Ponadto oznacza to serializację i deserializację danych, co ma wpływ na ich wydajność.

Chodzi mi o to, że sesja jest zła i zwykle bez niej lepiej. Witryny o niskim natężeniu ruchu, które działają tylko na jednym serwerze internetowym, nie wymagają zwiększenia wydajności, które może wystąpić; a witryny o dużym natężeniu ruchu działające w farmie internetowej są z tego powodu ograniczone.

Zamiast używać Haproxy na froncie, możesz użyć okrągłego robin DNS, aby zgrubnie zrównoważyć wiele dekoderów SSL, a następnie przekazać go do haproxy dla właściwego równoważenia obciążenia.