Równoważenie obciążenia Apache z ograniczonym budżetem?

13

Staram się skupić na koncepcji równoważenia obciążenia, aby zapewnić dostępność i nadmiarowość, aby zadowolić użytkowników, gdy coś pójdzie nie tak, zamiast równoważenia obciążenia w celu zapewnienia ogromnej prędkości milionom użytkowników.

Mamy ograniczony budżet i staramy się trzymać rzeczy, w których dostępna jest duża wiedza, więc uruchamianie Apache na Ubuntu VPS wydaje się strategią, dopóki nie zdobędzie nas znana wyszukiwarka ( uwaga na ironię w sobotę ).

Przynajmniej dla mnie to kompletna dżungla różnych dostępnych rozwiązań. Podejścia własne mod_proxy i HAproxy to dwa, które znaleźliśmy dzięki szybkiemu wyszukiwaniu w Google, ale mając zerowe doświadczenie w równoważeniu obciążenia, nie mam pojęcia, co byłoby odpowiednie w naszej sytuacji, ani czego moglibyśmy się zająć, wybierając rozwiązanie rozwiązania naszego problemu obawy dotyczące dostępności.

Jaka jest dla nas najlepsza opcja? Co powinniśmy zrobić, aby zwiększyć dostępność, pozostając w ramach naszych budżetów?

Przemysłowy
źródło
2
Przy okazji, nie implementuj „redundancji” za pomocą dwóch maszyn wirtualnych działających na tym samym serwerze. To po prostu głupie. (Nie mówię, że to był twój plan)
Earlz
być może użycie 3 lub 4 dedykowanych adresów IP i serwerów (VPS) do serwera w twoim bilansie obciążenia, spowoduje ideę prędkości, ale tak naprawdę nie jest. Równowaga obciążenia wybierze łącze, do którego dostęp ma uzyskać dostęp, jeśli jeden z nich jest wyłączony (ponieważ wielu użytkowników uzyskuje dostęp).
@Ellz - Nie, to nie był plan. Chciałem rozłożyć maszyny wirtualne tak daleko (geograficznie), jak to możliwe, aby nie były nawet w tym samym centrum danych
Industrial
@Fernando Costa Hi! Nie jestem pewien, co naprawdę masz na myśli, czy masz coś przeciwko napisaniu odpowiedzi i wyjaśnieniu swojej koncepcji?
Przemysłowe
Bounty jest włączone! Czekamy na więcej przemyśleń na ten temat
Industrial

Odpowiedzi:

6

Rozwiązanie, którego używam i które można łatwo wdrożyć za pomocą VPS, jest następujące:

  • DNS jest okradziony (sp?) Na 6 różnych prawidłowych adresów IP.
  • Mam 3 moduły równoważące obciążenie o identycznej konfiguracji i używające corosync / pacemaker do równomiernej dystrybucji 6 adresów IP (więc każda maszyna otrzymuje 2 adresy).
  • Każdy z modułów równoważenia obciążenia ma konfigurację nginx + lakier . Nginx zajmuje się odbieraniem połączeń, przepisywaniem i niektórymi statycznymi podaniami, a także przekazywaniem go do Varnish, który wykonuje równoważenie obciążenia i buforowanie.

Ten łuk ma następujące zalety, według mojej stronniczej opinii:

  1. corosync / pacemaker rozdzieli adresy IP na wypadek awarii jednego z LB.
  2. Nginx może być używany do obsługi SSL, niektórych typów plików bezpośrednio z systemu plików lub NFS bez użycia pamięci podręcznej (duże filmy, audio lub duże pliki).
  3. Lakier jest bardzo dobrym narzędziem równoważącym obciążenie, wspierającym wagę, sprawdzanie kondycji zaplecza, i wykonuje znakomitą pracę jako odwrotne proxy.
  4. W przypadku potrzeby większej liczby LB do obsługi ruchu, po prostu dodaj więcej maszyn do klastra, a adresy IP zostaną ponownie zrównoważone między wszystkimi maszynami. Możesz to zrobić nawet automatycznie (dodawanie i usuwanie modułów równoważenia obciążenia). Dlatego używam 6 ips dla 3 komputerów, aby dać trochę miejsca na rozwój.

W twoim przypadku posiadanie fizycznie oddzielonych VPS jest dobrym pomysłem, ale utrudnia udostępnianie IP. Celem jest posiadanie odpornego na awarie, nadmiarowego systemu, a niektóre konfiguracje równoważenia obciążenia / końca HA powodują bałagan, dodając jeden punkt awarii (jak jeden moduł równoważenia obciążenia, który odbiera cały ruch).

Wiem też, że pytałeś o apache, ale w dzisiejszych czasach mamy specjalne narzędzia, które lepiej pasują do zadania (takie jak Nginx i lakier). Pozostaw apache, aby uruchomić aplikacje na backendie i podawać go za pomocą innych narzędzi (nie to, że apache nie potrafi dobrze wyrównywać obciążenia lub odwracać proxy, to tylko kwestia przeniesienia różnych części zadania do większej liczby usług, aby każda część mogła dobrze sobie poradzić to udostępnij).

rdzeń rdzeniowy
źródło
Cześć znowu Coredump. Ile maszyn byłoby potrzebnych co najmniej do osiągnięcia tego w scenariuszu w świecie rzeczywistym?
Przemysłowy
Potrzebujesz co najmniej 2 VPS, aby działało na minimum. Oba VPS mogą bez problemu uruchamiać lakier nginx +. Dwa VPS MUSZĄ znajdować się na różnych hostach, jeśli to możliwe, z różnymi zasilaczami i siecią przychodzącą z różnych przełączników, więc jeśli jedna strona zawiedzie, nadal będziesz mieć drugą.
coredump
Witaj ponownie. Dziękuję za odpowiedź. Postaram się przeczytać instrukcje i przewodniki, jak to skonfigurować i wypróbować w środowisku wirtualnym w mojej sieci LAN i zobaczyć, jak obsługiwane jest przełączanie awaryjne. W tej chwili wydaje się zdecydowanie, że to rozwiązanie jest najlepsze na dłuższą metę, nawet jeśli da mi trochę siwych włosów, zanim zacznie działać zgodnie z przeznaczeniem ...
Przemysłowe
@industrial To najlepszy sposób na naukę :) Zacznij od złożenia modułu równoważenia obciążenia za pomocą nginx + lakieru, a potem martwisz się częścią klastra.
rdzeń rdzeniowy
6

HAproxy to dobre rozwiązanie. Konfiguracja jest dość prosta.

Potrzebujesz innej instancji VPS, aby usiąść przed co najmniej 2 innymi VPS. Więc do równoważenia obciążenia / przełączania awaryjnego potrzebujesz co najmniej 3 VPS

Kilka rzeczy do przemyślenia to także:

  1. Zakończenie SSL. Jeśli używasz HTTPS: // to połączenie powinno zostać zakończone w module równoważenia obciążenia, za modułem równoważenia obciążenia powinien przekazywać cały ruch przez niezaszyfrowane połączenie.

  2. Nośnik danych. Jeśli użytkownik prześle obraz, dokąd to idzie? Czy to po prostu siedzi na jednej maszynie? Potrzebujesz sposobu na natychmiastowe udostępnianie plików między komputerami - możesz użyć usługi Amazon S3 do przechowywania wszystkich plików statycznych lub możesz mieć inny VPS, który działałby jak serwer plików, ale polecam S3, ponieważ jest nadmiarowy i niesamowicie tani.

  3. informacje o sesji. każda maszyna w konfiguracji modułu równoważenia obciążenia musi mieć dostęp do informacji o sesji użytkownika, ponieważ nigdy nie wiadomo, na którą maszynę trafią.

  4. db - czy masz osobny serwer db? jeśli masz teraz tylko jeden komputer, w jaki sposób upewnisz się, że twój nowy komputer będzie miał dostęp do serwera db - a jeśli jest to oddzielny serwer db VPS, to w jakim stopniu jest to nadmiarowe. Posiadanie interfejsów WWW wysokiej dostępności i pojedynczego punktu awarii na jednym serwerze db nie musi mieć sensu, teraz należy również rozważyć replikację db i promocję slave.

Więc byłem w twoich butach, to jest problem ze stroną internetową, która wykonuje kilkaset odsłon dziennie w prawdziwej operacji. Szybko się komplikuje. Mam nadzieję, że dało ci to do myślenia :)

bonez
źródło
2
jeśli po prostu umieścisz jeden VPS równoważący obciążenie z przodu, nadal będziesz miał jeden punkt awarii!
JamesRyan,
@JamesRyan - Tak, myślałem o tym, pojedyncze punkty awarii są trochę śmierdzące. Czy masz jakieś zalecenia, co zamiast tego zrobić?
Przemysłowe
+1 HAProxy jest niesamowicie łatwy w użyciu.
Antoine Benkemoun
3

Głosuję na Linux Virtual Server jako moduł równoważenia obciążenia. Czyni to dyrektora LVS zarówno pojedynczym punktem awarii, jak i wąskim gardłem, ale

  1. Wąskie gardło nie jest, z mojego doświadczenia, problemem; etap przekierowania LVS odbywa się w warstwie 3 i jest niezwykle (obliczeniowo) tani.
  2. Pojedynczy punkt awarii powinien być rozwiązany poprzez posiadanie drugiego dyrektora, z dwoma kontrolowanymi przez Linux HA .

Koszt można obniżyć, utrzymując, że pierwszy dyrektor znajduje się na tej samej maszynie co pierwszy węzeł LVS, a drugi dyrektor na tej samej maszynie co drugi węzeł LVS. Trzeci i kolejne węzły są węzłami czystymi, bez implikacji LVS i HA.

Dzięki temu możesz dowolnie uruchamiać dowolne oprogramowanie serwera WWW, ponieważ przekierowanie odbywa się poniżej warstwy aplikacji.

Szalony Kapelusznik
źródło
Cześć MadHatter. To rozwiązanie, o którym nigdy wcześniej nie słyszałem. Przeczytaj o tym!
Przemysłowy
Działa dla mnie dobrze, zachęcamy do powrotu z pytaniami!
MadHatter,
W moim miejscu pracy intensywnie używamy lvs do równoważenia obciążenia i po skonfigurowaniu nigdy nie widziałem, żeby reżyser miał kiedykolwiek problemy. Jak mówi szalony kapelusznik, samo równoważenie obciążenia nie wymaga dużych zasobów. Używamy lvs w połączeniu z pulsem i piranią, aby zapewnić mechanizm przełączania awaryjnego i interfejs sieciowy do edycji konfiguracji. To zdecydowanie warte obejrzenia.
Czy
1

Co powiesz na ten łańcuch?

round robin dns> haproxy na obu komputerach> nginx, aby oddzielić pliki statyczne> apache

Ewentualnie użyj również ucarp lub bicia serca, aby haproxy zawsze odpowiadał. Stunnel usiadłby przed haproxy, gdybyś także potrzebował SSL

JamesRyan
źródło
1

Możesz rozważyć użycie odpowiedniego oprogramowania do klastrowania. Pakiet klastrów RedHat (lub CentOS) lub ClusterWare firmy Oracle . Można ich użyć do skonfigurowania klastrów aktywno-pasywnych, a także do ponownego uruchomienia usług i awarii między węzłami, gdy występują poważne problemy. Właśnie tego szukasz.

Wszystkie te rozwiązania klastrowe są zawarte w odpowiednich licencjach na system operacyjny, więc zapewne nie masz nic przeciwko kosztom. Wymagają one pewnego rodzaju pamięci współdzielonej - albo montowania NFS, albo fizycznego dysku, do którego dostęp mają oba węzły z klastrowym systemem plików. Przykładem tego ostatniego mogą być dyski SAN z dostępem do wielu hostów, sformatowane przy pomocy OCFS2 lub GFS . Wierzę, że możesz do tego użyć dysków współdzielonych VMWare .

Oprogramowanie klastra służy do definiowania „usług”, które działają przez cały czas w węzłach lub tylko wtedy, gdy ten węzeł jest „aktywny”. Węzły komunikują się za pomocą uderzeń serca, a także monitorują te usługi. Mogą je ponownie uruchomić, jeśli zauważą awarie, i uruchomią się ponownie, jeśli nie można ich naprawić.

Zasadniczo skonfigurowałbyś pojedynczy „wspólny” adres IP, na który kierowany byłby ruch. Następnie można zdefiniować apache i inne niezbędne usługi, które będą działać tylko na aktywnym serwerze. Współużytkowany dysk byłby używany do wszystkich treści internetowych, wszelkich przesyłanych plików i katalogów konfiguracji apache. (z httpd.conf itp.)

Z mojego doświadczenia wynika, że ​​działa to niesamowicie dobrze.

  • Nie ma potrzeby korzystania z okrągłego robota DNS ani żadnego innego modułu równoważenia obciążenia z pojedynczym punktem awarii - wszystko uderza w jeden adres IP / FQDN.
  • Pliki przesłane przez użytkownika trafiają do tej współużytkowanej pamięci, a tym samym nie przejmują się tym, czy komputer ulegnie awarii.
  • Programiści przesyłają treści do tego pojedynczego adresu IP / FQDN z zerowym dodatkowym szkoleniem i zawsze jest aktualne, jeśli nastąpi awaria.
  • Administrator może zabrać komputer w trybie offline, usunąć go, zrestartować itp. Następnie nie można przełączyć aktywnego węzła. Dokonanie aktualizacji wymaga minimalnego czasu przestoju.
  • Ten nieaktualny węzeł może być przez pewien czas niepakowany, dzięki czemu powrót po awarii jest równie łatwym procesem. (Szybsze niż migawki VMWare)
  • Zmiany w konfiguracji Apache są współdzielone, dzięki czemu podczas przełączania awaryjnego nic dziwnego się nie dzieje, ponieważ administrator zapomniał wprowadzić zmiany w polu offline.


- Krzysztof Karel

Christopher Karel
źródło
1

Optymalne równoważenie obciążenia może być bardzo kosztowne i skomplikowane. Podstawowe równoważenie obciążenia powinno po prostu zapewnić, że każdy serwer obsługuje w przybliżeniu taką samą liczbę trafień w dowolnym momencie.

Najprostszą metodą równoważenia obciążenia jest zapewnienie wielu rekordów A w DNS. Domyślnie adres IP zostanie skonfigurowany przy użyciu metody round robin. Spowoduje to, że użytkownicy będą stosunkowo równomiernie rozmieszczeni na serwerach. Działa to dobrze w przypadku witryn bezstanowych. W przypadku witryny z funkcją stanową wymagana jest nieco bardziej złożona metoda.

Aby obsłużyć stanowe wymagania, możesz użyć przekierowań. Nadaj każdemu serwerowi alternatywny adres, taki jak www1, www2, www3 itd. Przekieruj początkowe połączenie www na alternatywny adres hosta. W ten sposób mogą pojawić się problemy z zakładkami, ale powinny być one równomiernie rozłożone na serwerach.

Alternatywnie, użycie innej ścieżki do wskazania, który serwer obsługuje sesję stanową, pozwoliłoby na sesje proxy, które przełączyły hosta na oryginalny serwer. Może to stanowić problem, gdy sesja dla uszkodzonego serwera dotrze do serwera, który przejęł z uszkodzonego serwera. Jednak z wyjątkiem oprogramowania do klastrowania państwo i tak będzie go brakowało. Ze względu na buforowanie przeglądarki może nie wystąpić wiele sesji zmieniających serwery.

Tryb failover można obsłużyć, konfigurując serwer tak, aby przejmował adres IP serwera, który uległ awarii. Pozwoli to zminimalizować przestoje w przypadku awarii serwera. Bez oprogramowania do klastrowania sesje stanowe zostaną utracone, jeśli serwer ulegnie awarii.

Bez przełączania awaryjnego użytkownicy doświadczą opóźnienia, dopóki ich przeglądarka nie przełączy się na następny adres IP.

Korzystanie z usług Restful zamiast sesji stanowych powinno wyeliminować problemy związane z klastrowaniem w interfejsie. Nadal obowiązywałyby problemy związane z klastrowaniem po stronie magazynu.

Nawet z modułami równoważenia obciążenia przed serwerami, prawdopodobnie będziesz mieć przed nimi DNS typu round-robin. Zapewni to wykorzystanie wszystkich modułów równoważenia obciążenia. Dodadzą kolejną warstwę do twojego projektu, z dodatkową złożonością i innym punktem awarii. Mogą jednak zapewnić pewne funkcje bezpieczeństwa.

Najlepsze rozwiązanie będzie zależeć od odpowiednich wymagań.

Wdrożenie serwerów obrazów do obsługi treści takich jak obrazy, pliki CSS i inne treści statyczne może zmniejszyć obciążenie serwerów aplikacji.

BillThor
źródło
1

Ogólnie używam pary identycznych maszyn OpenBSD:

  • Użyj RelayD do równoważenia obciążenia, monitorowania serwera WWW i obsługi uszkodzonego serwera WWW
  • Użyj CARP dla wysokiej dostępności samych równoważników obciążenia.

OpenBSD jest lekki, stabilny i dość bezpieczny - idealny do usług sieciowych.

Na początek polecam instalację warstwy3. Pozwala uniknąć komplikacji zapory ogniowej (PF). Oto przykładowy plik /etc/relayd.conf, który pokazuje konfigurację prostego modułu równoważenia obciążenia przekaźnika z monitorowaniem serwerów WWW zaplecza:

# $OpenBSD: relayd.conf,v 1.13 2008/03/03 16:58:41 reyk Exp $
#
# Macros
#

# The production internal load balanced address
intralbaddr="1.1.1.100"

# The interface on this load balancer with the alias for the intralbaddr address
intralbint="carp0"

# The list of web/app servers serving weblbaddress
intra1="1.1.1.90"
intra2="1.1.1.91"

# Global Options
#
# interval 10
timeout 1000
# prefork 5

log updates

# The "relaylb" interface group is assigned to the intralbint carp interface
# The following forces a demotion in carp if relayd stops
demote relaylb

#
# Each table will be mapped to a pf table.
#
table <intrahosts> { $intra1 $intra2 }

# Assumes local webserver that can provide a sorry page
table <fallback> { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration
#
http protocol httprelay {
        return error
        header append "$REMOTE_ADDR" to "X-Forwarded-For"
        header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        # header change "Connection" to "close"

        # Various TCP performance options
        tcp { nodelay, sack, socket buffer 65536, backlog 128 }

#       ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
#       ssl session cache disable
}

relay intra-httprelay {
        listen on $intralbaddr port 80
        protocol httprelay

        # Forward to hosts in the intrahosts table using a src/dst hash
        # The example shows use of a page with dynamic content to provide
        # application aware site checking.  This page should return a 200 on success,
        # including database or appserver connection, and a 500 or other on failure
        forward to <intrahosts> port http mode loadbalance \
                check http "/nlbcheck.asp" code 200

}
Paul Doom
źródło
Cześć Paul, dziękuję za Twój praktyczny przykład! Czy byłeś zadowolony z niezawodności swojego rozwiązania?
Przemysłowy
Bardzo szczęśliwy. Używam OpenBSD do wszelkiego rodzaju zadań sieciowych (zapory ogniowe, serwery DNS, serwery WWW, usługi równoważenia obciążenia itp.) Od około 12 lat i niezmienna jakość każdej wersji jest niesamowita. Po skonfigurowaniu po prostu działa. Kropka.
Paul Doom
0

Czy dałeś ec2 z cloudfoundry, a może Elastic Beanstalk lub zwykłym starym AWS automatycznie skalującym myśl. Używam tego i skaluje się całkiem dobrze, a elastyczność jest skalowalna w górę / w dół bez jakiejkolwiek interwencji człowieka.

Biorąc pod uwagę, że mówisz, że nie masz doświadczenia w równoważeniu obciążenia, zasugerowałbym te opcje, ponieważ wymagają minimalnego „smażenia” mózgu, aby się uruchomić.

To może być lepsze wykorzystanie twojego czasu.

Ankur Chauhan
źródło
Rodzina witryn StackOverflow używana pounddo niedawna, kiedy, jak sądzę, zaimplementowała nginx. Zauważ, że nginx może zostać zaimplementowany w celu zastąpienia Apache lub po prostu jako nakładka na Apache.
Michael Dillon,
Cześć Ankur. Dzięki za odpowiedź. Amazon z pewnością jest opcją, którą rozważaliśmy, jednak wydaje się, że jest tyle samo pozytywnych, co negatywnych opinii na temat EC2, jeśli chodzi o budowanie na nich krytycznych aplikacji biznesowych ...
Przemysłowe