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

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?

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).

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 :)

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.

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

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

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.

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.

• http://www.openbsd.org - Strona główna
• http://www.openbsd.org/faq/pf/carp.html - Dokumentacja karpia
• https://calomel.org/relayd.html - Przyzwoity zestaw informacji o howto na RelayD

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

}

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.