Lastausgleich Apache auf ein Budget?

Ich versuche, mich mit dem Konzept des Lastausgleichs vertraut zu machen, um Verfügbarkeit und Redundanz zu gewährleisten und die Benutzer bei Problemen zufrieden zu stellen, anstatt den Lastausgleich zu betreiben, um Millionen von Benutzern eine rasante Geschwindigkeit zu bieten.

Wir haben ein begrenztes Budget und versuchen, uns an die Dinge zu halten, bei denen es genügend Wissen gibt. Daher scheint es die Strategie zu sein, Apache unter Ubuntu VPS zu betreiben, bis uns eine berühmte Suchmaschine dazu bringt ( inklusive Samstags-Ironie, bitte beachten Sie ).

Zumindest für mich ist es ein kompletter Dschungel von verschiedenen verfügbaren Lösungen. Apaches own mod_proxy & HAproxy sind zwei, die wir durch eine schnelle Google-Suche gefunden haben. Da ich jedoch keine Erfahrung mit dem Lastenausgleich habe, habe ich keine Ahnung, was für unsere Situation angemessen wäre oder worauf wir bei der Auswahl einer Lösung für unsere Probleme achten würden Bedenken hinsichtlich der Verfügbarkeit.

Was ist die beste Option für uns? Was sollten wir tun, um die Verfügbarkeit hoch zu halten, während wir innerhalb unseres Budgets bleiben?

Die Lösung, die ich verwende und die mit VPS einfach zu implementieren ist, ist folgende:

• DNS wird auf 6 verschiedene gültige IP-Adressen umgeleitet.
• Ich habe 3 Load Balancer mit identischer Konfiguration und verwende Corosync / Schrittmacher , um die 6 IP-Adressen gleichmäßig zu verteilen (so erhält jeder Rechner 2 Adressen).
• Jeder der Load Balancer verfügt über eine Nginx + Lack- Konfiguration. Nginx kümmert sich darum, die Verbindungen zu erhalten, Änderungen vorzunehmen und statische Daten zu liefern und diese an Varnish weiterzuleiten, der für den Lastenausgleich und das Caching zuständig ist.

Dieser Bogen hat meiner voreingenommenen Meinung nach die folgenden Vorteile:

1. corosync / pacemaker verteilt die IP-Adressen neu, falls einer der LB ausfällt.
2. nginx kann verwendet werden, um SSL, bestimmte Dateitypen direkt aus dem Dateisystem oder NFS bereitzustellen, ohne den Cache zu verwenden (große Videos, Audiodateien oder große Dateien).
3. Lack ist ein sehr guter Load Balancer, der das Gewicht und die Integritätsprüfung im Backend unterstützt und hervorragende Arbeit als Reverse Proxy leistet.
4. Wenn mehr LBs für die Verarbeitung des Datenverkehrs benötigt werden, fügen Sie dem Cluster einfach weitere Computer hinzu, und die IP-Adressen werden zwischen allen Computern neu verteilt. Sie können dies sogar automatisch tun (Hinzufügen und Entfernen von Load Balancern). Deshalb verwende ich 6 ips für 3 Maschinen, um etwas Platz für Wachstum zu lassen.

In Ihrem Fall ist es eine gute Idee, physikalisch getrennte VPSs zu haben, aber die gemeinsame Nutzung von IP-Adressen wird schwieriger. Das Ziel besteht darin, ein fehlerresistentes, redundantes System und einige Konfigurationen für Load Balancing / HA zu haben und einen einzigen Fehlerpunkt hinzuzufügen (wie einen einzelnen Load Balancer, um den gesamten Datenverkehr zu empfangen).

Ich weiß auch, dass Sie nach Apache gefragt haben, aber heutzutage haben wir spezielle Tools, die besser für den Job geeignet sind (wie Nginx und Lack). Überlassen Sie es apache, die Anwendungen auf dem Backend auszuführen und sie mit anderen Tools zu bedienen (nicht, dass apache keinen guten Lastenausgleich oder Reverse-Proxying durchführen kann, es geht nur darum, verschiedene Teile des Jobs auf mehr Dienste zu verlagern, damit jeder Teil eine gute Leistung erbringen kann es ist Anteil).

HAproxy ist eine gute Lösung. Die Konfiguration ist ziemlich einfach.

Sie benötigen eine weitere VPS-Instanz, um vor mindestens zwei anderen VPS zu sitzen. Zum Lastenausgleich / Failover benötigen Sie also mindestens 3 VPS

Ein paar Dinge, über die man nachdenken sollte, sind:

1. SSL-Kündigung. Wenn Sie HTTPS: // verwenden, sollte diese Verbindung am Load Balancer beendet werden. Hinter dem Load Balancer sollte der gesamte Datenverkehr über eine unverschlüsselte Verbindung geleitet werden.

2. Dateispeicher. Wenn ein Benutzer ein Bild hochlädt, wohin geht es? Sitzt es nur auf einer Maschine? Sie benötigen eine Möglichkeit, um Dateien sofort zwischen Computern auszutauschen - Sie könnten den S3-Dienst von Amazon verwenden, um alle statischen Dateien zu speichern, oder Sie könnten einen anderen VPS verwenden, der als Dateiserver fungieren würde, aber ich würde S3 empfehlen, weil es redundant und unglaublich billig ist.

3. Sitzungsinfo. Jeder Computer in Ihrer Load Balancer-Konfiguration muss auf die Sitzungsinformationen des Benutzers zugreifen können, da Sie nie wissen, auf welchen Computer er zugreifen wird.

4. db - hast du einen separaten db server? Wenn Sie gerade nur einen Computer haben, wie stellen Sie sicher, dass Ihr neuer Computer Zugriff auf den Datenbankserver hat? Wenn es sich um einen separaten VPS-Datenbankserver handelt, wie redundant ist das? Es ist nicht unbedingt sinnvoll, ein Hochverfügbarkeits-Web-Front-End und einen einzigen Ausfallpunkt mit einem Datenbankserver zu haben. Jetzt müssen Sie auch die Datenbankreplikation und die Slave-Promotion berücksichtigen.

Also, ich bin in Ihren Schuhen, das ist das Problem mit einer Website, die ein paar hundert Zugriffe pro Tag auf eine echte Operation macht. Es wird schnell komplex. Ich hoffe, das hat dir zu denken gegeben :)

Ich stimme für Linux Virtual Server als Load Balancer. Dies macht den LVS-Direktor zu einer einzigen Fehlerquelle und zu einem Engpass

1. Der Engpass ist nach meiner Erfahrung kein Problem; Der LVS-Umleitungsschritt ist Schicht-3 und extrem (rechnerisch) billig.
2. Der einzelne Fehlerpunkt sollte durch einen zweiten Director behoben werden, wobei die beiden von Linux HA gesteuert werden .

Die Kosten können niedrig gehalten werden, indem sich der erste Director auf demselben Computer wie der erste LVS-Knoten und der zweite Director auf demselben Computer wie der zweite LVS-Knoten befindet. Dritte und nachfolgende Knoten sind reine Knoten ohne LVS- oder HA-Implikationen.

Dadurch können Sie auch beliebige Webserver-Software ausführen, da die Umleitung unterhalb der Anwendungsebene erfolgt.

Wie wäre es mit dieser Kette?

Round-Robin-DNS> Haproxy auf beiden Maschinen> Nginx, um statische Dateien zu trennen> Apache

Verwenden Sie möglicherweise auch Ucarp oder Heartbeat, um sicherzustellen, dass Haproxy immer antwortet. Stunnel würde vor haproxy sitzen, wenn Sie auch SSL benötigen

Möglicherweise möchten Sie die Verwendung einer geeigneten Cluster-Software in Betracht ziehen. RedHats (oder CentOS) Cluster Suite oder Oracle ClusterWare . Diese können zum Einrichten von Aktiv-Passiv-Clustern und zum Neustarten von Diensten verwendet werden. Bei schwerwiegenden Problemen können Fehler zwischen Knoten auftreten. Dies ist im Wesentlichen das, wonach Sie suchen.

Alle diese Cluster-Lösungen sind in den jeweiligen Betriebssystem-Lizenzen enthalten. Sie erfordern eine Art von gemeinsam genutztem Speicher - entweder ein NFS-Mount oder eine physische Festplatte, auf die beide Knoten mit einem Cluster-Dateisystem zugreifen. Ein Beispiel für Letzteres wären SAN-Festplatten mit mehreren zulässigen Hostzugriffen , die mit OCFS2 oder GFS formatiert sind . Ich glaube, Sie können dafür freigegebene VMWare- Festplatten verwenden .

Die Clustersoftware wird verwendet, um "Dienste" zu definieren, die ständig auf Knoten ausgeführt werden, oder nur, wenn dieser Knoten "aktiv" ist. Die Knoten kommunizieren über Heartbeats und überwachen diese Dienste. Sie können sie neu starten, wenn sie Fehler bemerken, und neu starten, wenn sie nicht behoben werden können.

Sie würden im Grunde eine einzelne "gemeinsame" IP-Adresse konfigurieren, an die der Datenverkehr geleitet wird. Dann können auch Apache und alle anderen erforderlichen Dienste definiert und nur auf dem aktiven Server ausgeführt werden. Die freigegebene Festplatte wird für Ihren gesamten Webinhalt, alle hochgeladenen Dateien und Ihre Apache-Konfigurationsverzeichnisse verwendet. (mit httpd.conf, etc)

Nach meiner Erfahrung funktioniert das unglaublich gut.

• Es ist kein DNS-Round-Robin oder ein anderer Single-Point-of-Failure-Load-Balancer erforderlich - alles trifft auf einen IP / FQDN.
• Vom Benutzer hochgeladene Dateien werden in diesen freigegebenen Speicher verschoben, und es ist daher unerheblich, ob für Ihren Computer ein Failover ausgeführt wird.
• Entwickler laden Inhalte ohne zusätzliches Training auf diesen einzelnen IP / FQDN hoch und es ist immer auf dem neuesten Stand, wenn ein Failover durchgeführt wird.
• Der Administrator kann den Offline-Computer entfernen, das Problem beheben, einen Neustart durchführen usw. Anschließend kann der aktive Knoten ausgefallen sein. Für ein Upgrade sind nur minimale Ausfallzeiten erforderlich.
• Dieser veraltete Knoten kann eine Zeit lang nicht gepatcht werden, sodass ein Failback ebenso einfach ist. (Schneller als VMWare-Snapshots)
• Änderungen an der Apache-Konfiguration werden freigegeben, sodass während eines Failovers nichts Ungewöhnliches passiert, da ein Administrator vergessen hat, Änderungen an der Offline-Box vorzunehmen.

--Christopher Karel

Ein optimaler Lastausgleich kann sehr teuer und kompliziert sein. Der grundlegende Lastenausgleich sollte lediglich sicherstellen, dass jeder Server zu jeder Zeit ungefähr die gleiche Anzahl von Treffern verarbeitet.

Die einfachste Methode zum Lastenausgleich besteht darin, mehrere A-Einträge in DNS bereitzustellen. Standardmäßig wird die IP-Adresse in einer Round-Robin-Methode konfiguriert. Dies führt dazu, dass die Benutzer relativ gleichmäßig auf die Server verteilt sind. Dies funktioniert gut für zustandslose Sites. Eine etwas komplexere Methode ist erforderlich, wenn Sie eine Stateful-Site haben.

Um Statusanforderungen zu verarbeiten, können Sie Weiterleitungen verwenden. Weisen Sie jedem Webserver eine alternative Adresse zu, z. B. www1, www2, www3 usw. Leiten Sie die ursprüngliche www-Verbindung zur alternativen Adresse des Hosts um. Auf diese Weise können Lesezeichenprobleme auftreten, die jedoch gleichmäßig auf die Server verteilt sein sollten.

Wenn Sie alternativ einen anderen Pfad verwenden, um anzugeben, welcher Server die zustandsbehaftete Sitzung abwickelt, können Sie Sitzungen, bei denen der Host auf den ursprünglichen Server umgeschaltet wurde, auch per Proxy weiterleiten. Dies kann ein Problem sein, wenn die Sitzung für einen ausgefallenen Server auf einem Server eintrifft, der vom ausgefallenen Server übernommen wurde. Wenn Sie die Cluster-Software nicht aktivieren, fehlt der Status jedoch. Aufgrund von Browser-Caching treten möglicherweise nicht viele Sitzungen auf, in denen die Server gewechselt werden.

Failover kann durch Konfigurieren des Servers zur Übernahme der IP-Adresse eines ausgefallenen Servers durchgeführt werden. Dies minimiert die Ausfallzeit, wenn ein Server ausfällt. Ohne Clustering-Software gehen zustandsbehaftete Sitzungen verloren, wenn ein Server ausfällt.

Ohne Failover kommt es zu einer Verzögerung, bis der Browser auf die nächste IP-Adresse umschaltet.

Durch die Verwendung von Restful-Diensten anstelle von Stateful-Sitzungen sollten Clusterprobleme im Front-End behoben werden. Clustering-Probleme auf der Speicherseite würden weiterhin auftreten.

Selbst wenn sich Load Balancer vor den Servern befinden, haben Sie wahrscheinlich Round-Robin-DNS vor sich. Dadurch wird sichergestellt, dass alle Ihre Load Balancer verwendet werden. Sie fügen Ihrem Entwurf eine weitere Ebene hinzu, die komplexer und fehleranfälliger ist. Sie können jedoch einige Sicherheitsfunktionen bereitstellen.

Die beste Lösung hängt von den jeweiligen Anforderungen ab.

Das Implementieren von Image-Servern zur Bereitstellung von Inhalten wie Bildern, CSS-Dateien und anderen statischen Inhalten kann die Belastung der Anwendungsserver verringern.

Ich benutze im Allgemeinen ein Paar identischer OpenBSD-Maschinen:

• Verwenden Sie RelayD für den Lastenausgleich, die Webserverüberwachung und die Behandlung eines ausgefallenen Webservers
• Verwenden Sie CARP für eine hohe Verfügbarkeit der Load Balancer.

OpenBSD ist leicht, stabil und ziemlich sicher - Perfekt für Netzwerkdienste.

• http://www.openbsd.org - Hauptseite
• http://www.openbsd.org/faq/pf/carp.html - Karpfendokumentation
• https://calomel.org/relayd.html - Eine gute Anleitung zu RelayD

Zu Beginn empfehle ich ein Layer3-Setup. Dies vermeidet Komplikationen bei der Einrichtung einer Firewall (PF). Hier ist ein Beispiel für die Datei /etc/relayd.conf, die die Einrichtung eines einfachen Relay-Load-Balancers mit Überwachung der Backend-Webserver zeigt:

# $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

}

Haben Sie ec2 mit Cloudfoundry oder vielleicht Elastic Beanstalk oder nur einem einfachen alten AWS Autoscaling einen Gedanken gegeben. Ich habe das benutzt und es skaliert ziemlich gut und elastisch zu sein kann ohne menschliches Eingreifen skaliert werden.

Angesichts der Tatsache, dass Sie sagen, dass Sie keine Erfahrung mit dem Lastenausgleich haben, würde ich diese Optionen vorschlagen, da sie nur minimales "Braten" des Gehirns erfordern, um in Betrieb zu gehen.

Es könnte eine bessere Nutzung Ihrer Zeit sein.