Load Balancing Azure Service-Dienste Fabric hören auf URI-Präfix

Question

Szenario 1 (in Betrieb): Hier das Szenario, das gut funktioniert: Ich habe 2 öffentlich zugängliche staatenlos Dienste Foo und Bar

• Foo: 2 Fällen hören auf Port 8081
• Bar: 1 Instanz, auf Port 8082

Anfragen Senden entweder http://clusteruri:8081 oder http://clusteruri:8082 funktioniert ein d Ich sehe, dass für Foo die Anfragen schön zwischen den beiden Knoten verteilt sind, auf denen die beiden Instanzen gehostet werden.

Szenario 2 (Arbeiten nicht): Hier ist das Szenario würde ich damit gerne: wieder 2 staatenlos Dienste Foo und Bar

• Foo: 2 Instanzen, auf URI-Präfix hören http://+:8080/foo
• Bar: 1 Instanz, hört auf URI-Präfix http://+:8080/bar

Bitte beachten Sie, dass beiden Dienste auf dem gleich Port hören, aber unterschiedliche Wege (erreicht durch Verwendung eines Hosts, der auf http.sys basiert, wie WebListener).

Hier fängt es an, seltsam zu werden: Es scheint ASF/Load Balancer nicht wirklich zu verstehen und denke, dass alle 3 Knoten nur auf Port 8080 hören, was zu einigen Anfragen an Foo führt, die auf dem Knoten landen, der Bar und den anderen hostet andersherum.

Es scheint, dass ASF/Load Balancer automatisch Szenarien behandeln kann, in denen Dienste auf dedizierten Ports abhören, unterstützt aber nicht wirklich Dienste, die auf demselben Port (aber anderem Pfad) horchen.

Meine Fragen

• Gibt es eine Möglichkeit Szenario zu erhalten 2 arbeiten "out of the box", wie es für Szenario funktioniert 1 (das heißt ohne eine benutzerdefinierte App-Gateway-Service zu implementieren, die das Routing der Fall ist)?
• Kann jemand bitte etwas Licht darauf werfen, wie ASF konfiguriert/kommuniziert, um Szenario 1 zum Laufen zu bringen? I.e. Wo kann ich "sehen", dass ASF den Load Balancer konfiguriert hat, dass Anfragen an Foo entweder an Node0 oder Node1 gehen sollen und Anfragen an Bar an Node2 gehen sollen, abhängig davon, an welchen Port die Anfrage gesendet wird?

Answer 1

Das Service Fabric verfügt nicht über einen Netzwerklastenausgleich. Service Fabric ist nur die Clustering-/Orchestrierungs-/Anwendungsplattform, die auf einer Reihe von VMs ausgeführt wird. Wenn Sie einen Cluster in Azure über ARM (oder das Azure-Portal) erstellen, ist eine der Ressourcen, die Sie in den Standard-ARM-Vorlagen erhalten, der Azure Load Balancer. Er ist jedoch völlig unabhängig von den VMs, die Sie bereitstellen , nicht die Dienste, die auf ihnen laufen. Die Konfiguration des Lastenausgleichs erfolgt in Ihrer ARM-Vorlage (oder erneut über das Azure-Portal). Service Fabric kennt den Load Balancer nicht. Es ist die gleiche Topologie, die Sie erwarten würden, wenn Sie einen Cluster auf Ihrer eigenen Hardware einrichten würden.

Der Grund, warum 1 funktioniert und 2 nicht in Azure ist, weil der Azure Load Balancer ein Layer-4-Lastenausgleich ist: Er versteht offene Ports, versteht jedoch keine Anwendungsprotokolle wie HTTP und URLs und nicht Verstehen Sie, dass Sie verschiedene Anwendungen auf Ihren Knoten haben - alles, was es sieht, sind offene Ports. Mit dem ALB können Sie jedoch HTTP probes festlegen, die dem ALB mitteilen, an welche Knoten Daten gesendet werden sollen.

Hier ist ein wenig mehr Hintergrundinformationen, die nützlich sein könnten: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-connect-and-communicate-with-services/