Frage Wie kann ich einen skalierbaren, zuverlässigen Haproxy-Cluster auf Amazon EC2 bereitstellen?


Wir benötigen einige erweiterte Funktionen, die ELB bietet (hauptsächlich L7-Inspektionen), aber es ist nicht offensichtlich, wie man Dinge wie Herzschlag und hohe Verfügbarkeit mit etwas wie haproxy unter Verwendung von EC2 handhaben kann. Es ist sehr wahrscheinlich, dass wir 3 oder mehr Haproxy-Knoten im Cluster benötigen, daher wird ein einfacher Heartbeat zwischen zwei Knoten nicht funktionieren.

Es scheint so, als ob eine Heartbeat-Ebene vor den Haproxy-Knoten die richtige Wahl wäre, möglicherweise mit IPVS, aber die Konfigurationsänderungen beim Wechsel des EC2-Clusters (entweder durch absichtliche Änderungen, wie eine Erweiterung oder unbeabsichtigtes, wie das Verlieren eines EC2-Knoten) scheint nicht trivial zu sein.

Vorzugsweise würde die Lösung mindestens zwei Availability Zones umfassen.

In Antwort auf Qs: Nein, Sitzungen sind nicht klebrig. Und ja, wir werden SSL brauchen, aber das könnte theoretisch durch ein anderes Setup vollständig gehandhabt werden - wir können SSL-Datenverkehr an einen anderen Ort als Nicht-SSL-Datenverkehr leiten.


25
2017-12-03 22:50


Ursprung


Ich recherchiere, wie man canary mit einem langsam ansteigenden Prozentsatz des Verkehrs zur neuen Version der Software ausbringt, und ich bin super-neugierig darüber, wo Sie damit endete. Hast du am Ende irgendeinen von Jespers Vorschlägen versucht? - Iain


Antworten:


OK, ich habe noch nie eine AWS-Load-Balancing-Lösung mit Traffic auf den Ebenen von SmugMug selbst gebaut, aber wenn ich nur an die Theorie und die Services von AWS denke, fallen mir ein paar Ideen ein.

Der ursprünglichen Frage fehlen einige Dinge, die das Lastenausgleichsdesign beeinflussen:

  1. Klebrige Sitzungen oder nicht? Es ist sehr vorzuziehen, keine sticky-Sitzung zu verwenden, und alle Load Balancer (LBs) sollten Round Robin (RR) oder zufällige Backend-Auswahl verwenden. RR- oder Random-Backend-Auswahlen sind einfach, skalierbar und bieten unter allen Umständen eine gleichmäßige Lastverteilung.
  2. SSL oder nicht? Ob SSL verwendet wird oder nicht, und über welchen Prozentsatz von Anforderungen sich das Lastenausgleichsdesign im Allgemeinen auswirkt. Es ist oft vorzuziehen, SSL so früh wie möglich zu beenden, um die Zertifikatsbehandlung zu vereinfachen und die SSL-CPU-Last von Webanwendungsservern fernzuhalten.

Ich antworte aus der Perspektive, wie man das hält Lastausgleichsschicht selbst hoch verfügbar. Halten Sie die Anwendungsserver HA ist nur mit den Integritätsprüfungen in Ihren L7-Lastenausgleich integriert.

OK, ein paar Ideen, die funktionieren sollten:

1) "Der AWS-Weg":

  • Die erste Ebene ganz vorne verwendet ELB im L4-Modus (TCP / IP).
  • Zweite Ebene, verwenden Sie EC2-Instanzen mit Ihrem L7-Lastenausgleicher Ihrer Wahl (nginx, HAProxy, Apache usw.).

Vorteile / Idee: Die L7-Load-Balancer können recht einfache EC2-AMIs sein, die alle aus demselben AMI geklont wurden und die gleiche Konfiguration verwenden. Somit können die Werkzeuge von Amazon alle HA-Anforderungen erfüllen: ELB überwacht die L7-Lastverteiler. Wenn ein L7 LB stirbt oder nicht mehr reagiert, erstellen ELB & Cloudwatch zusammen eine neue Instanz automatisch und bringen sie in den ELB-Pool.

2) "Das DNS Round Robin mit Überwachung Weg:"

  • Verwenden Sie das grundlegende DNS-Round-Robin, um eine grobkörnige Lastenverteilung über einige IP-Adressen hinweg zu erhalten. Nehmen wir an, Sie veröffentlichen 3 IP-Adressen für Ihre Website.
  • Jede dieser drei IP-Adressen ist eine AWS Elastic IP-Adresse (EIA), die an eine EC2-Instanz gebunden ist, mit einem L7-Lastenausgleichsmodul Ihrer Wahl.
  • Wenn ein EC2 L7 LB stirbt, ein kompatibler Benutzeragent (Browser) sollte benutze einfach eine der anderen IPs stattdessen.
  • Richten Sie einen externen Überwachungsserver ein. Überwachen Sie jedes der drei EIPs. Wenn einer nicht mehr reagiert, verwenden Sie die Befehlszeilentools und einige Skripts von AWS, um den EIP zu einer anderen EC2-Instanz zu verschieben.

Vorteile / Idee: Konforme Benutzeragenten sollten automatisch auf eine andere IP-Adresse umschalten, wenn eine nicht mehr reagiert. Daher sollte im Falle eines Fehlers nur 1/3 Ihrer Benutzer betroffen sein, und die meisten von ihnen sollten nichts bemerken, da ihre UA stillschweigend zu einer anderen IP übergeht. Und Ihre externe Überwachungsbox wird bemerken, dass eine EIP nicht reagiert, und die Situation innerhalb weniger Minuten beheben.

3) DNS-RR für Paare von HA-Servern:

Im Grunde genommen ist dies Dons eigener Vorschlag eines einfachen Heartbeats zwischen einem Serverpaar, aber vereinfacht für mehrere IP-Adressen.

  • Verwenden Sie DNS RR, um eine Reihe von IP-Adressen für den Dienst zu veröffentlichen. Folgen Sie dem obigen Beispiel, lassen Sie uns nur sagen, dass Sie 3 IPs veröffentlichen.
  • Jedes dieser IP geht an a Paar von EC2-Servern, also insgesamt 6 EC2-Instanzen.
  • Jedes dieser Paare verwendet Heartbeat oder eine andere HA-Lösung zusammen mit AWS-Tools, um 1 IP-Adresse in einer aktiven / passiven Konfiguration live zu halten.
  • In jeder EC2-Instanz ist Ihr L7-Lastenausgleich der Wahl installiert.

Vorteile / Idee: In der vollständig virtualisierten Umgebung von AWS ist es nicht so einfach, über L4-Dienste und Failover-Modi nachzudenken. Durch die Vereinfachung auf ein Paar identischer Server, die nur 1 IP-Adresse am Leben erhalten, wird es einfacher, darüber nachzudenken und zu testen.

Fazit: Auch das habe ich in der Produktion noch nicht probiert. Nur aus meinem Bauchgefühl, Option eins mit ELB im L4-Modus, und selbstverwaltete EC2-Instanzen als L7 LBs scheint am meisten mit dem Geist der AWS-Plattform ausgerichtet, und wo Amazon am ehesten investieren und später erweitern wird. Das wäre wahrscheinlich meine erste Wahl.


14
2017-12-05 14:41



Also liebe ich Approach # 1, das ist die Richtung, in die ich gelehnt habe, aber es gibt immer noch einige interessante Probleme - nicht zuletzt, dass ELB nicht mit einer ganzen AZ zurechtkommt, die sehr schlecht läuft (etwas, das wir bereits hatten) ). Die einfache, aber eklige "Lösung" ist es, die Haproxies hinter ELB so konfiguriert zu haben, dass sie AZs kreuzen (vielleicht mit einem Backup-Cluster in einem anderen AZ). Wenn also mindestens ein Haproxy in jedem AZ ist, sollten wir in Ordnung sein. Aber das mimimisiert nur, beseitigt das Problem nicht. Irgendwelche Ideen zu diesem Problem? - Don MacAskill
@Don MacAskill: Ich weiß, dass AWS ein paar großflächige Service-Ausfallzeiten hatte, aber es ist schwierig, die Azu-Zuverlässigkeit auf AWS zu verbessern. Der Wechsel zum Multi-AZ-Betrieb des Frontends könnte leicht der erste Schritt in Richtung Multi-AZ-Betrieb des gesamten Stacks sein, und das ist ein ganzer Schlangenkessel ... - Jesper Mortensen
@Don MacAskill: Eine Option wäre eine geo-bewusste DNS-Auflösung wie DynDNS Dynect -> ELB + L7 LBs in einem AZ, mit einem anderen ELB + L7 auf Hot-Standby in einem anderen AZ. (Abgesehen von der Tatsache, dass Geo-aware, hat Dynect auch einige Gesundheitschecks.) DynDNS hat eine große Erfolgsbilanz für die Betriebszeit, aber trotzdem ist das Hinzufügen von Geo-Aware-DNS ein weiterer SPOF. Ob Dynect + Load Balancing in 2 AZs eine bessere Langzeitverfügbarkeit als nur ein AWS AZ hat, ist mir nicht klar. Hier finden Sie einen Überblick über das, was ich meine, ohne die Multi-AZ-Datenbanken: dev.bizo.com/2010/05/improving-global-application.html - Jesper Mortensen
@Don MacAskill: Nur eine letzte Sache - bedenken Sie, dass eine einzelne ELB-Instanz mehrere AZs umfassen kann. Es kann nicht über EC2 laufen Regionen. Aber wenn nur ELB zu L7 LBs in zwei AZs innerhalb der gleichen Region akzeptabel ist, wäre dies bei weitem die einfachste ... Sie schrieb: "ELB behandelt nicht eine ganze AZ sehr gut", vielleicht wissen Sie bereits mehr als Ich mache. - Jesper Mortensen
Ja, wenn ein ELB mehrere AZs überspannt und eine Art von Fehler hat, wo es nicht hinkommt irgendein der Backend-Knoten in einem AZ (sie sind überlastet, down, 503s zurück, was auch immer), Endbenutzer sehen diese Fehler - es wird nicht auf die anderen AZ (s) umgeleitet. Ich hoffe, das ist geplant, aber es hat uns schon einmal gebissen. - Don MacAskill


Wenn Sie keine sticky-Sitzungen durchführen oder Tomcat- / Apache-Stil verwenden (Knoten-ID an Sitzungs-ID anhängen, anstatt den Status im LB zu speichern), würde ich ELB vor einer Gruppe von Haproxies verwenden. In ELB ist ein Healthcheck eingebaut, damit Sie die Haproxies überwachen und aus dem Pool entfernen können. Viel weniger einzurichten als Heartbeat Failover.

Was Veränderungen anbelangt, habe ich keine großartige Antwort. Puppet eignet sich hervorragend für die Erstkonfiguration und das Implementieren von Änderungen. Zum Hinzufügen / Entfernen von Knoten möchten Sie jedoch eine schnellere Antwort als das 30-minütige Abfrageintervall wünschen.


2
2017-12-04 03:53



Das ist eine gute Lösung (und eine gute Frage!) Sie können mit Amazon SNS Konfigurationsänderungen auf Push-Weise weitergeben. Sie benötigen ein Benachrichtigungssystem zum Hinzufügen / Entfernen von Knoten aus der Haproxy-Konfiguration. - Rafiq Maniar
Eine weitere Option für die Verwaltung von Backend-Servern (denen haproxy weiterleitet) besteht darin, dass jeder Backend-Server entweder alle haproxies oder einen Konfigurationsserver eine periodische Registrierung (30 Sekunden oder so) sendet. Wenn einer stirbt, wird er schnell wieder unregistriert (und haproxy sollte es trotzdem bemerken); Wenn ein neues kommt, wird es automatisch in Rotation versetzt. Dies ist anscheinend das, was Netflix tut. - Ben Jencks


Ich habe es selbst nicht benutzt, aber ich habe viele Leute erwähnt, die Marionetten benutzen, um diese Art von Problemen auf EC2 zu lösen


1
2017-12-04 00:46



Ja, Puppet auf EC2 macht das Verwalten eines Clusters ziemlich einfach. Erstelle einfach eine Mikroinstanz und verwende sie als deinen Puppenspieler. - Tom O'Connor
Wir verwenden Marionette in unseren Datencentern, haben aber noch keine EC2 ausprobiert. Ist Puppet EC2-aware irgendwie so, dass es Knoten mit ec2-describe-instances oder sowas finden kann, und automatisch konfigurieren / rekonfigurieren basierend auf dieser Ausgabe? Und wie würdest du damit umgehen, dass der Puppenspieler plötzlich weggeht? - Don MacAskill
Warum würde es plötzlich verschwinden? - Tom O'Connor
Es ist nicht EC2-fähig, aber Sie können es einrichten, so dass neue Knoten beim Starten als Signierung markiert werden und ein Skript für externe Knoten verwenden, um sie zu beschreiben. Ich schrieb einige Python, um dies mit SimpleDB (externe Knoten) und SQS (Warteschlange der Signieranfragen für neue Knoten) zu tun; Ein Ubuntu-Entwickler schrieb Skripte mit S3: ubuntumathiaz.wordpress.com/2010/04/07/ ... - Ben Jencks
Wenn der Puppenspieler plötzlich verschwindet, wird das Manifest nicht ausgeführt, d. H. Es verlässt die Knoten in dem Zustand, in dem sie sich befinden. - Ben Jencks