Widziałem, że ludzie zalecają łączenie ich wszystkich w jednym procesie, ale wydaje się, że mają wiele nakładających się funkcji, więc chciałbym się dowiedzieć, dlaczego warto przejść przez 3 różne programy przed uderzeniem w twój serwer WWW.

nginx:

• ssl: tak
• kompres: tak
• pamięć podręczna: tak
• pula zaplecza: tak

lakier:

• ssl: no (stunnel?)
• Kompresja: ?
• pamięć podręczna: tak (podstawowa funkcja)
• pula zaplecza: tak

haproksy:

• ssl: no (stunnel)
• Kompresja: ?
• pamięć podręczna: nie
• pula zaplecza: tak (podstawowa funkcja)

Czy zamiar łączenia ich wszystkich przed głównymi serwerami WWW ma na celu uzyskanie niektórych z ich głównych zalet?

Wydaje się dość niestabilne, gdy tak wiele demonów przesyła razem, tworząc podobne rzeczy.

Jakie są Twoje preferencje dotyczące wdrażania i zamawiania i dlaczego?

Po prostu…

HaProxy to najlepszy na rynku moduł równoważenia obciążenia typu open source.
Varnish to najlepszy dostępny na rynku bufor plików statycznych typu open source.
Nginx to najlepszy serwer sieciowy typu open source na rynku.

(oczywiście to moja opinia i wiele innych osób)

Ale generalnie nie wszystkie zapytania przechodzą przez cały stos.

Wszystko przechodzi przez haproxy i nginx / multiple nginx.
Jedyną różnicą jest to, że „przykręcasz” lakier do żądań statycznych.

• każde żądanie jest równoważone pod względem obciążenia w celu zapewnienia nadmiarowości i przepustowości (dobrze, to skalowalna nadmiarowość)
• każde żądanie plików statycznych najpierw uderza w pamięć podręczną lakieru (dobrze, to szybko)
• każde żądanie dynamiczne kierowane jest bezpośrednio do backendu (świetnie, lakier się nie używa)

Ogólnie rzecz biorąc, ten model pasuje do skalowalnej i rozwijającej się architektury (zabierz haproxy, jeśli nie masz wielu serwerów)

Mam nadzieję, że to pomoże: D

Uwaga: Wprowadzę również Pound dla zapytań SSL: D
Możesz mieć serwer dedykowany do odszyfrowywania żądań SSL i przekazywania standardowych żądań do stosu zaplecza: D (Sprawia, że ​​cały stos działa szybciej i prościej)

Przedmowa

Aktualizacja w 2016 roku. Wszystko ewoluuje, wszystkie serwery stają się coraz lepsze, wszystkie obsługują SSL, a sieć jest jeszcze bardziej niesamowita.

O ile nie zaznaczono inaczej, poniższe informacje są skierowane do profesjonalistów w biznesie i przedsiębiorstwach typu start-up, obsługujących tysiące do milionów użytkowników.

Te narzędzia i architektury wymagają dużej liczby użytkowników / sprzętu / pieniędzy. Możesz spróbować w laboratorium domowym lub na blogu, ale to nie ma większego sensu.

Zasadniczo pamiętaj, że chcesz zachować prostotę . Każde dołączone oprogramowanie pośrednie to kolejny kluczowy element oprogramowania pośredniego do utrzymania. Doskonałości nie osiąga się, gdy nie ma nic do dodania, ale gdy nie ma już nic do usunięcia.

Niektóre typowe i interesujące wdrożenia

HAProxy (równoważenie) + nginx (aplikacja php + buforowanie)

Serwer to nginx z uruchomionym php. Gdy nginx już tam jest, równie dobrze może obsługiwać buforowanie i przekierowania.

HAProxy ---> nginx-php
A       ---> nginx-php
P       ---> nginx-php
r       ---> nginx-php
o       ---> nginx-php
x       ---> nginx-php
y       ---> nginx-php

HAProxy (równoważenie) + lakier (buforowanie) + Tomcat (aplikacja Java)

HAProxy może przekierowywać do Varnish na podstawie identyfikatora URI żądania (* .jpg * .css * .js).

HAProxy ---> tomcat
A       ---> tomcat
        ---> tomcat
P       ---> tomcat <----+
r       ---> tomcat <---+|
o                       ||
x       ---> varnish <--+|
y       ---> varnish <---+

HAProxy (równoważenie) + nginx (SSL do hosta i buforowanie) + serwer WWW (aplikacja)

Serwery nie mówią SSL, chociaż KAŻDY MUSI MÓWIĆ SSL ( szczególnie ten link HAProxy-WebServer z prywatnymi informacjami użytkownika przechodzącymi przez EC2 ). Dodanie lokalnego nginx pozwala ustawić SSL na hoście. Gdy nginx już tam jest, równie dobrze może buforować i przepisywać adresy URL.

Uwaga : Przekierowanie portu 443: 8080 ma miejsce, ale nie jest częścią funkcji. Przekierowywanie portów nie ma sensu. Moduł równoważenia obciążenia może komunikować się bezpośrednio z serwerem WWW: 8080.

          (nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A       ---> nginx:443 -> webserver:8080
P       ---> nginx:443 -> webserver:8080
r       ---> nginx:443 -> webserver:8080
o       ---> nginx:443 -> webserver:8080
x       ---> nginx:443 -> webserver:8080
y       ---> nginx:443 -> webserver:8080

Middleware

HAProxy: moduł równoważenia obciążenia

Główne cechy :

• Równoważenie obciążenia (TCP, HTTP, HTTPS)
• Wiele algorytmów (round robin, source ip, headers)
• Trwałość sesji
• Zakończenie SSL

Podobne alternatywy : nginx (wielofunkcyjny serwer sieciowy konfigurowany jako moduł równoważenia obciążenia)
Różne alternatywy : chmura (Amazon ELB, moduł równoważenia obciążenia Google), sprzęt (F5, fortinet, netscaler crix), inne i na całym świecie (DNS, anycast, CloudFlare)

Co robi HAProxy i kiedy należy go używać?
Ilekroć potrzebujesz równoważenia obciążenia. HAProxy to rozwiązanie.

Z wyjątkiem sytuacji, gdy chcesz bardzo tanie LUB szybkie i brudne LUB nie masz dostępnych umiejętności, możesz użyć ELB: D

Z wyjątkiem sytuacji, gdy pracujesz w bankowości / administracji publicznej lub podobnej firmie i wymagasz korzystania z własnego centrum danych o wysokich wymaganiach (dedykowana infrastruktura, niezawodne przełączanie awaryjne, 2 warstwy zapory ogniowej, audyty, SLA, aby zapłacić x% za minutę przestoju, wszystko w jednym) możesz umieścić 2 F5 na szafie zawierającej 30 serwerów aplikacji.

Z wyjątkiem sytuacji, gdy chcesz przejść przez 100k HTTP (S) [i wiele witryn], MUSISZ mieć wiele HAProxy z warstwą [globalnego] równoważenia obciążenia przed nimi (cloudflare, DNS, anycast). Teoretycznie globalny moduł równoważący może rozmawiać bezpośrednio z serwerami sieciowymi, umożliwiając porzucenie HAProxy. Zwykle POWINNYŚCIE utrzymywać HAProxy jako publiczne punkty wejścia do centrum danych i dostroić zaawansowane opcje, aby zachować równowagę między hostami i zminimalizować wariancję.

Osobista opinia : mały, zamknięty projekt open source, w całości poświęcony JEDNEJ PRAWDZIWEMU CELU. Wśród najłatwiejszej konfiguracji (plik JEDEN), najbardziej przydatne i najbardziej niezawodne oprogramowanie open source, z jakim się spotkałem.

Nginx: Apache, który nie jest do bani

Główne cechy :

• WebServer HTTP lub HTTPS
• Uruchamiaj aplikacje w CGI / PHP / jakiś inny
• Przekierowanie / przepisanie adresu URL
• Kontrola dostępu
• Manipulowanie nagłówkami HTTP
• Buforowanie
• Odwrotny serwer proxy

Podobne alternatywy : Apache, Lighttpd, Tomcat, Gunicorn ...

Apache był de facto serwerem internetowym, znanym również jako gigantyczny ruch w klastrze składający się z dziesiątek modułów i tysięcy linii httpd.confna wierzchu uszkodzonej architektury przetwarzania żądań. nginx ponownie to wszystko, z mniejszą liczbą modułów, (nieco) prostszą konfiguracją i lepszą architekturą rdzenia.

Co robi nginx i kiedy musisz go używać?
Serwer WWW jest przeznaczony do uruchamiania aplikacji. Gdy twoja aplikacja jest rozwijana do działania na nginx, masz już nginx i równie dobrze możesz korzystać ze wszystkich jego funkcji.

Z wyjątkiem sytuacji, gdy twoja aplikacja nie jest przeznaczona do uruchamiania na nginx, a nginx nie ma nigdzie na twoim stosie (ktoś robi zakupy w Java?), To nie ma sensu w nginx. Funkcje obecnego serwera prawdopodobnie będą istnieć na twoim obecnym serwerze, a inne zadania są lepiej obsługiwane przez odpowiednie dedykowane narzędzie (HAProxy / Varnish / CDN).

Z wyjątkiem sytuacji, gdy twój serwer / aplikacja nie ma funkcji, jest trudna do skonfigurowania i / lub wolisz umrzeć niż patrzeć na nią (Gunicorn czy ktoś?), Możesz umieścić nginx z przodu (tj. Lokalnie na każdym węźle), aby wykonać adres URL przepisywanie, wysyłanie przekierowań 301, wymuszanie kontroli dostępu, szyfrowanie SSL i edytowanie nagłówków HTTP w locie. [Są to funkcje oczekiwane od serwera]

Lakier: serwer buforowania

Główne cechy :

• Buforowanie
• Zaawansowane buforowanie
• Buforowanie drobnoziarniste
• Buforowanie

Podobne alternatywy : nginx (wielofunkcyjny serwer WWW konfigurowalny jako serwer buforujący)
Różne alternatywy : CDN (Akamai, Amazon CloudFront, CloudFlare), Sprzęt (F5, Fortinet, Citrix Netscaler)

Co robi Varnish i kiedy należy go używać?
Robi buforowanie, tylko buforowanie. Zwykle nie jest to warte wysiłku i jest stratą czasu. Zamiast tego wypróbuj CDN. Pamiętaj, że buforowanie jest ostatnią rzeczą, na którą powinieneś zwrócić uwagę podczas prowadzenia strony internetowej.

Z wyjątkiem sytuacji, gdy prowadzisz witrynę internetową poświęconą wyłącznie zdjęciom lub filmom, powinieneś dokładnie przyjrzeć się CDN i poważnie pomyśleć o buforowaniu.

Z wyjątkiem sytuacji, gdy jesteś zmuszony używać własnego sprzętu we własnym centrum danych (CDN nie jest opcją), a twoje serwery WWW są straszne w dostarczaniu plików statycznych (dodanie większej liczby serwerów nie pomaga), wtedy Varnish jest ostatecznością.

Z wyjątkiem sytuacji, gdy masz witrynę z przeważnie statyczną, ale złożoną, dynamicznie generowaną treścią (zobacz poniższe akapity), Varnish może zaoszczędzić dużo mocy obliczeniowej na twoich serwerach.

Buforowanie statyczne jest przereklamowane w 2016 r

Buforowanie jest prawie bez konfiguracji, bez pieniędzy i czasu. Po prostu subskrybuj CloudFlare, CloudFront lub Akamai lub MaxCDN. Czas, który zajmuje mi napisanie tego wiersza, jest dłuższy niż czas potrzebny na ustawienie buforowania ORAZ piwo, które trzymam w dłoni, jest droższe niż mediana subskrypcji CloudFlare.

Wszystkie te usługi działają od razu dla statycznych * .css * .js * .png i innych. W rzeczywistości w większości honorują Cache-Controldyrektywę w nagłówku HTTP. Pierwszym krokiem buforowania jest skonfigurowanie serwerów WWW do wysyłania odpowiednich dyrektyw pamięci podręcznej. Nie ma znaczenia, co CDN, jaki lakier, jaka przeglądarka jest w środku.

Uwagi dotyczące wydajności

Lakier powstał w czasie, gdy przeciętne serwery internetowe dusiły się, aby udostępnić zdjęcie kota na blogu. Obecnie jeden przykład przeciętnego nowoczesnego, wielowątkowego serwera asynchronicznego opartego na modnym haśle może niezawodnie dostarczać kocięta do całego kraju. Dzięki uprzejmości sendfile().

Przeprowadziłem szybkie testy wydajności dla ostatniego projektu, nad którym pracowałem. Pojedyncze wystąpienia tomcat mogłyby obsłużyć od 21 000 do 33 000 plików statycznych na sekundę przez HTTP (testowanie plików od 20B do 12kB przy różnej liczbie połączeń HTTP / klient). Stały ruch wychodzący przekracza 2,4 Gb / s. Produkcja będzie miała tylko interfejsy 1 Gb / s. Nie może być lepszy niż sprzęt, nie ma sensu nawet próbować lakieru.

Kompleks buforowania zmieniający zawartość dynamiczną

CDN i serwery buforujące zwykle ignorują adres URL za pomocą parametrów takich jak: ?article=1843ignorują każde żądanie z sesyjnymi plikami cookie lub uwierzytelnionymi użytkownikami i ignorują większość typów MIME, w tym application/jsonpochodzące z /api/article/1843/info. Dostępne są opcje konfiguracji, ale zazwyczaj nie są drobnoziarniste, a raczej „wszystko albo nic”.

Lakier może mieć niestandardowe złożone reguły (patrz VCL), aby zdefiniować, co można buforować, a co nie. Reguły te mogą buforować określoną zawartość według identyfikatora URI, nagłówków i bieżącego pliku cookie sesji użytkownika oraz typu MIME i zawartości WSZYSTKO RAZEM. To może zaoszczędzić dużo mocy obliczeniowej na serwerach WWW dla niektórych bardzo specyficznych wzorców obciążenia. Właśnie wtedy Lakier jest przydatny i NIESAMOWITY.

Wniosek

Zajęło mi trochę czasu, aby zrozumieć wszystkie te elementy, kiedy ich używać i jak pasują do siebie. Mam nadzieję, że to może ci pomóc.

To okazuje się dość długie (6 godzin na napisanie. OMG!: O). Może powinienem założyć blog lub książkę na ten temat. Ciekawostka: Wydaje się, że nie ma ograniczenia długości odpowiedzi.

To prawda, że ​​3 narzędzia mają wspólne cechy. Większość ustawień jest w porządku z dowolną kombinacją 2 spośród 3. Zależy to od ich głównego celu. Powszechnie jest akceptować poświęcanie pamięci podręcznej, jeśli wiesz, że twój serwer aplikacji jest szybki w statystyce (np. Nginx). Często trzeba poświęcić niektóre funkcje równoważenia obciążenia, jeśli zamierzasz zainstalować dziesiątki lub setki serwerów i nie zależy ci na tym, aby w pełni je wykorzystać, ani na rozwiązywaniu problemów. Często rezygnuje się z niektórych funkcji serwera WWW, jeśli zamierzasz uruchomić rozproszoną aplikację z wieloma komponentami na całym świecie. Mimo to niektórzy ludzie budują z nimi wszystkie interesujące farmy.

Pamiętaj, że mówisz o 3 stałych produktach. Zasadniczo nie trzeba ich równoważyć. Jeśli potrzebujesz frontowego protokołu SSL, najpierw nginx jako odwrotny serwer proxy jest w porządku. Jeśli nie potrzebujesz tego, lakier z przodu jest w porządku. Następnie możesz ustawić haproxy, aby zrównoważyć obciążenia aplikacji. Czasami lubisz przełączać się na różne farmy serwerów na samym haproxy, w zależności od typów plików lub ścieżek.

Czasami będziesz musiał chronić się przed ciężkimi atakami DDoS, a haproxy z przodu będzie bardziej odpowiedni niż inne.

Ogólnie rzecz biorąc, nie powinieneś się martwić, jaki kompromis należy zrobić między wyborami. Powinieneś wybrać sposób ich montażu, aby uzyskać najlepszą elastyczność dla swoich potrzeb teraz i w przyszłości. Nawet jeśli ułożysz kilka z nich wiele razy, może to czasem być właściwe w zależności od twoich potrzeb.

Mam nadzieję, że to pomoże!

Wszystkie pozostałe odpowiedzi pochodzą z 2010 r., Dlatego dodano zaktualizowane porównanie.

Nginx

• Pełny serwer WWW, można również użyć innych funkcji. Np .: Kompresja HTTP
• Obsługa SSL
• Bardzo lekka, ponieważ Nginx od samego początku był lekki.
• Wydajność buforowania w pobliżu lakieru
• Blisko równoważenia obciążenia HAProxy

Lakier

• najlepszy do złożonych scenariuszy buforowania i dołączania do aplikacji.
• najlepszy bufor plików statycznych
• Brak obsługi SSL
• Pożeracz pamięci i procesora

Haproksy

• najlepszy moduł równoważenia obciążenia, zapewniający najnowocześniejsze funkcje równoważenia obciążenia, porównywalny do równoważenia obciążenia sprzętowego
• SSL jest obsługiwany od wersji 1.5.0
• Prostsze, ponieważ jest to tylko serwer proxy tcp bez implementacji HTTP, co czyni go szybszym i mniej podatnym na błędy.

Tak więc najlepszą metodą wydaje się wdrażanie ich wszystkich w odpowiedniej kolejności.

Jednak do ogólnego zastosowania Nginx jest najlepszy, ponieważ uzyskuje się ponadprzeciętną wydajność dla wszystkich: buforowanie, odwrotne proxy, równoważenie obciążenia , przy bardzo niewielkim obciążeniu zasobów. A potem masz SSL i pełne funkcje serwera WWW.

Varnish obsługuje równoważenie obciążenia: http://www.varnish-cache.org/trac/wiki/LoadBalancing

Nginx obsługuje równoważenie obciążenia: http://wiki.nginx.org/NginxHttpUpstreamModule

Po prostu skonfigurowałbym to za pomocą lakieru + stunnela. Gdybym potrzebował nginx z jakiegoś innego powodu, po prostu użyłbym lakieru nginx +. Możesz poprosić nginx o akceptację połączeń SSL i powielić je do lakierowania, a następnie porozmawiać z nginx za pośrednictwem http.

Niektóre osoby mogą wrzucać do miksu nginx (lub Apache), ponieważ są to narzędzia bardziej ogólne niż Lakier. Na przykład, jeśli chcesz przekształcić zawartość (np. Za pomocą XDV, filtrów apache itp.) W warstwie proxy, potrzebujesz jednego z nich, ponieważ Varnish nie może tego zrobić samodzielnie. Niektóre osoby mogą być bardziej zaznajomione z konfiguracją tych narzędzi, więc łatwiej jest używać Lakieru jako prostej pamięci podręcznej i wykonywać równoważenie obciążenia na innej warstwie, ponieważ znają już Apache / nginx / haproxy jako moduł równoważenia obciążenia.