AWS ELB als Backend für Varnish Accelerator

Ich arbeite an einer umfangreichen Bereitstellung in AWS, die den ganzen Tag über hohe Verfügbarkeitsanforderungen und variable Lasten aufweist. Offensichtlich ist dies der perfekte Anwendungsfall für ELB (Elastic Load Balancer) und Autoscaling.

Wir verlassen uns jedoch auch auf Lack zum Zwischenspeichern von API-Aufrufen. Mein anfänglicher Instinkt war es, den Stapel so zu strukturieren, dass der Lack ELB als Backend verwendet, das wiederum eine AppGroup trifft.

Varnish -> ELB -> AppServers

Doch nach ein paar Quellen , die nicht möglich sind , wie ELB ständig die IP - Adresse der DNS - Hostnamen ändern, die Lack - Caches auf Start, Änderungen an dem IP - Sinne nicht von Lack abgeholt werden.

Beim Lesen sieht es jedoch so aus, als würden die Leute dies tun, also frage ich mich, welche Problemumgehungen es gibt. Vielleicht ein Skript, um die vcl regelmäßig neu zu laden?

Für den Fall, dass dies wirklich keine gute Idee ist, eine Idee für andere Lösungen?

Lack kann tatsächlich als Load Balancer arbeiten. Du solltest es versuchen Varnish -> AppServers.

Definieren Sie einfach jeden App-Server als Backend in einem Director in der Varnish-Konfiguration.

Sie können sogar Tests hinzufügen, um die Verfügbarkeit des Backends zu überprüfen, erneut zu versuchen, zu einem anderen Server zu wechseln, wenn einer während eines Anforderungsprozesses ausfällt usw.

Wo wird Ihre Lackinstanz gehostet? ASW auch? Sie können Varnish Hash Director ausprobieren und Varnish auf denselben Servern wie Apps hosten. Jede Instanz verarbeitet Anforderungen, die sie verarbeiten soll, und leitet andere an das rechte Backend weiter. Jede eindeutige URL wird nur auf einem (verfügbaren) Server zwischengespeichert, und Ihr Cache-Speicher wird mit der Anzahl der Lackinstanzen multipliziert, während Cache-Fehler begrenzt sind.

Dies ist absolut möglich, aber es dauert ein paar Schritte, bis es gut funktioniert! Die Art und Weise, wie wir es hier tun, wenn wir diese Art von Konfiguration benötigen, ist:

• Erstellen Sie eine VPC. Sie müssen dies in VPC tun, da Sie darin Subnetze erstellen müssen.

• Erstellen Sie in jeder Verfügbarkeitszone ein Subnetz, in dem Instanzen bei der ELB registriert sind. Sie sollten ein Subnetz einrichten, damit Sie in jedem Subnetz eine kleine Anzahl von IP-Adressen haben, da jede IP-Adresse zu einem Overhead wird. (Wir verwenden derzeit Subnetze, die a / 26 sind)

• Beginnen Sie mit der Erstellung eines DNS Director-Backends in Ihrer Lack-VCL. Fügen Sie die 3 oben erstellten Subnetze hinzu. ( https://www.varnish-cache.org/docs/3.0/reference/vcl.html#the-dns-director )

• Stellen Sie die Hosteinstellung im DNS Director-Backend auf den Hostnamen ein, den der Lack erwarten sollte. (Wenn Ihr Front-End-Service beispielsweise front-end-service.subdomain.example.com heißt, geben Sie front-end-service.example.com als Host-Einstellung in die VCL ein.)

• Stellen Sie die Suffixeinstellung im DNS Director auf etwas ein, das Sie auflösen können. Wenn Sie das obige Beispiel fortsetzen, können Sie leicht '-varnish.example.com' für Ihr Suffix verwenden. Wenn eine Anforderung auf "Lack" trifft, überprüft der Lack den HTTP-Host-Header. Wenn der Name mit dem im DNS Director Backend der VCL für die Einstellung "Host-Header" angegebenen Lack übereinstimmt, hängt der Lack das Suffix an und führt eine DNS-Suche für den Hostnamen durch das Ergebnis der Verkettung des Inhalts des Host-Headers mit dem Suffix. Daher wird in diesem Beispiel eine DNS-Suche durch Lack für den Host mit dem Namen "front-end-service.subdomain.example.com-varnish.example.com" durchgeführt.

• Erstellen Sie Ihr Loadbalancer-Backend und hängen Sie es an jedes von Ihnen erstellte Subnetz an.

• Legen Sie einen DNS-Eintrag für das Ergebnis der Verkettung als CNAME für den DNS-Namen fest, den amazon für Ihren Loadbalancer bereitstellt.

• Starten Sie den Lack. Sehen Sie sich optional den Lackstat an, um die Anzahl der Backends zu überprüfen.

• Testen Sie Ihr Setup, indem Sie a ausgeben

  curl -H "Host: front-end-service.subdomain.example.com" http://varnish-server-hostname.example.com/whatever-path

• Beobachten Sie, wie die Anfrage mit varnishlog eingeht, um zu überprüfen, ob alles funktioniert.

Es kann nützlich sein zu beachten, dass AWS empfiehlt, ein Subnetz mit mindestens 20 nicht verwendeten IP-Adressen zu haben, wenn Sie einen Loadbalancer in diesem Subnetz platzieren möchten. (Siehe http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/UserScenariosForVPC.html )

Wir haben dies für ein kürzlich durchgeführtes Projekt getan, bei dem ELBs für eine Anforderungsspezifikation benötigt wurden. Wir sind jedoch besorgt darüber, wie sich dies in Bezug auf die einfache Verwaltung skalieren lässt, und untersuchen auf Service Discovery basierende Ansätze sowie ein automatisiertes VCL-Update und eine automatisierte VCL Bereitstellung über etwas wie Varnish Agent ( https://github.com/varnish/vagent2 )

Wenn es Ihnen jedoch nichts ausmacht, Ihre VPC-Subnetze zu verwalten, funktioniert die obige Beschreibung sehr gut.

Prost!

Ein Teil des Zwecks von ELB besteht darin, Ausfälle von Wirten zu überleben. Selbst mit automatischer Skalierung und CloudWatch, wenn eine tote Instanz ersetzt werden muss, sehen Sie möglicherweise mehrere Minuten Ausfallzeit.

Ich empfehle:

[Front End ELB] -> [Varnish] -> [Back End ELB] -> [AppServers]

Ich weiß, dass Sie das Caching so weit wie möglich nutzen möchten, aber Sie sollten die Last wirklich auf alle Verfügbarkeitszonen verteilen. Dies bedeutet, dass in Zone A, B und C für die Region (en), in der sich Ihr Stapel befindet, die gleiche Anzahl von Instanzen vorhanden ist (also 3x Lack). Dies kostet natürlich mehr, bietet Ihnen jedoch die Möglichkeit, ganze AZ-Ausfälle * zu überstehen. Wenn Sie diese Kosten senken, müssen Sie wahrscheinlich irgendwann Ausfallzeiten einstecken. Das ist Ihre Entscheidung, aber zumindest können Sie eine fundierte Entscheidung treffen.

Haben Sie zwei Sicherheitsgruppen, eine für Lack und eine für AppServer. Konfigurieren Sie jede so, dass nur die zugeordnete ELB über den entsprechenden Port darauf zugreifen kann.

Stellen Sie für die Lackkonfiguration den DNS-Director auf eine niedrige TTL ein. Stellen Sie den Wert (oder die Hälfte) der TTL des CNAME ein, den Amazon für die Back-End-ELB bereitstellt. Das sollte ausreichen, damit Varnish auf dem neuesten Stand bleibt.

* Und wenn Sie die ultimative Verfügbarkeit anstreben möchten. Verwenden Sie Route53 mit Multi-Region- und Multi-Az-Redundanz.