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