Ich habe an den Optionen gebleicht, die azure bietet, um die Last zwischen mehreren Webrollen auszugleichen.
Ich habe drei mögliche Wege gefunden, dies zu tun.
Das erste wäre, überhaupt nichts zu tun und die Standard-Implementierung (Round-Robin) die Aufgabe übernehmen zu lassen.
Die zweite Möglichkeit wäre, eine benutzerdefinierte LoadBalancerProbe in der ServiceDefinitionFile zu definieren, die ich ausprobiert habe und die ich nicht ausführen konnte: Nach meinem Verständnis wird die benutzerdefinierte aspx-Seite jedes Mal aufgerufen, wenn eine Statusprüfung für die Rolle durchgeführt wird. Abhängig vom HTTP-Antwortcode ändert die Rolle ihren Status in "Besetzt". - Aber das passiert nie. Außerdem konnte ich wirklich keine Beispiele finden, um eine benutzerdefinierte LoadBalancingProbe zu definieren.
Also habe ich nach einem alternativen Weg gesucht, dies zu tun.
Jetzt abonniere ich das RoleEnvironment.StatusCheck-Ereignis, das es mir ermöglicht, eine Logik zu implementieren und abhängig von den Ergebnissen den Rollenstatus auf beschäftigt und verfügbar zu setzen.
Meine Fragen: 1) Angenommen, die benutzerdefinierte LoadBalancerProbe funktioniert wie im MSDN beschrieben, was ist der Unterschied zwischen dem Abonnieren des StatusCheckEvent und der Verwendung eines benutzerdefinierten Tests?
2) Warum funktioniert mein benutzerdefinierter Load Balancer-Probe nicht? - Ich habe gerade erst mit dem Azure-Emulator getestet und bin mir bewusst, dass der Traffic immer noch an die WebRole-Instanzen weitergeleitet wird, obwohl sie im Emulator auf "Beschäftigt" eingestellt sind. Aber mein Custom Probe ändert den Status der webroleinstances überhaupt nicht.
Hier ist der sehr rudimentäre Code, der meines Wissens den Status von webrole instance_n_0 auf busy setzen sollte.
%Vor%Ich habe auch meine Dienstdefinitionsdatei konferiert und eine Route zum Weiterleiten an diese Steuerung / Aktion festgelegt, wenn ich die im benutzerdefinierten Prüfpunkt definierte Option "healthcheck.aspx" aufruft.
%Vor%Die Route:
%Vor%Nicht sicher, warum das benutzerdefinierte Prüfprogramm nicht funktioniert, sondern für die Unterschiede: Mit dem Ereignis "health-check" können Sie ankündigen, ob eine Instanz verfügbar ist, aber Sie haben keine Flexibilität hinsichtlich der Häufigkeit, mit der diese aufgerufen wird. Außerdem können Sie keinen separaten Dienst starten, der einen benutzerdefinierten Port (oder Porttyp) überwacht.
Sie haben viel mehr Flexibilität mit benutzerdefinierten Tests, da Sie jeden Typ von Port-Listener erstellen können, um die Integrität zu bestimmen, sogar eine separate exe.
Bei virtuellen Maschinen ist dies die einzige Methode für Health Probes, da auf virtuellen Maschinen der Gastagent nicht ausgeführt wird und das Health-Check-Ereignis nicht bereitgestellt wird.
Tags und Links azure load-balancing