Azure Cloud Services (klassisch): Definition des LoadBalancerProbe-Schemas
Wichtig
Cloud Services (klassisch) ist jetzt ab dem 1. September 2024 für alle Kunden veraltet. Alle vorhandenen ausgeführten Bereitstellungen werden beendet und von Microsoft heruntergefahren, und die Daten sind ab Oktober 2024 dauerhaft verloren. In neuen Bereitstellungen sollte das neue auf Azure Resource Manager basierende Bereitstellungsmodell für Azure Cloud Services (erweiterter Support) verwendet werden.
Der Lastenausgleichstest ist ein vom Kunden definierter Integritätstest von UDP-Endpunkten und Endpunkten in Rolleninstanzen. LoadBalancerProbe ist kein eigenständiges Element, sondern wird mit der Webrolle oder der Workerrolle in einer Dienstdefinitionsdatei kombiniert. Mehrere Rollen können LoadBalancerProbe verwenden.
Die Standarderweiterung für die Dienstdefinitionsdatei lautet „.csdef“.
Die Funktion eines Lastenausgleichstests
Der Azure Load Balancer ist für das Routing von eingehendem Datenverkehr zu Ihren Rolleninstanzen verantwortlich. Der Lastenausgleich bestimmt, welche Instanzen Datenverkehr empfangen können, indem sie in regelmäßigen Zeitabständen getestet werden, um die Integrität dieser Instanz zu ermitteln. Bei dem Lastenausgleich wird jede Instanz mehrmals pro Minute getestet. Der Zustand der Instanz kann auf zwei Weisen für den Lastenausgleich bereitgestellt werden: mit dem standardmäßigen Lastenausgleichstest oder mit einem benutzerdefinierten Lastenausgleichstest, der durch die Definition des LoadBalancerProbe in der CSDEF-Datei implementiert wird.
Beim Standard-Lastenausgleichstest wird der Gast-Agent auf dem virtuellen Computer genutzt. Dieser lauscht und antwortet nur dann mit einer HTTP 200-Antwort „OK“, wenn die Instanz den Zustand „Bereit“ aufweist, d. h. nicht in den Zuständen „Ausgelastet“, „Wiederverwendung“ oder „Wird angehalten“ etc. Wenn der Gast-Agent nicht mit HTTP 200 OK antwortet, kennzeichnet der Azure Load Balancer die Instanz als nicht reagierend und sendet keinen Datenverkehr mehr an diese Instanz. Der Azure Load Balancer pingt die Instanz weiterhin, und wenn der Gast-Agent mit einer HTTP 200-Antwort reagiert, sendet der Azure Load Balancer erneut Datenverkehr an diese Instanz. Bei Verwendung einer Webrolle wird Ihr Websitecode in der Regel in „w3wp.exe“ ausgeführt. Dieses Programm wird nicht von der Azure-Fabric und vom Gast-Agent überwacht. Fehler in „w3wp.exe“ (z. B. HTTP 500-Antworten) werden nicht an den Gast-Agent gemeldet, und der Lastenausgleich weiß nicht, dass er diese Instanz aus der Rotation entfernen muss.
Der benutzerdefinierte Lastenausgleichstest erhält Vorrang vor dem Standard-Gast-Agent-Test und ermöglicht es Ihnen, Ihre eigene benutzerdefinierte Logik zum Bestimmen der Integrität der Rolleninstanz zu erstellen. Der Load Balancer testet Ihren Endpunkt standardmäßig alle 15 Sekunden. Die Instanz wird als rotierend betrachtet, wenn sie innerhalb des Zeitlimits (standardmäßig 31 Sekunden) mit einem TCP-ACK oder HTTP-Code 200 reagiert. Dieser Prozess kann hilfreich sein, um Ihre eigene Logik zum Entfernen von Instanzen aus der Lastenausgleichsrotation zu entfernen (z. B. die Rückgabe eines anderen Statuscodes als 200, wenn die Instanz eine CPU-Auslastung von über 90 % aufweist). Für Webrollen, die „w3wp.exe“ verwenden, bedeutet dieses Setup auch, dass Ihre Website automatisch überwacht wird, da Fehler im Websitecode einen Nicht-200-Status an den Lastenausgleichstest zurückgibt. Wenn Sie in der CSDEF-Datei kein LoadBalancerProbe-Element definieren, wird das zuvor beschriebene Standardverhalten des Lastenausgleichs verwendet.
Wenn Sie einen benutzerdefinierten Lastenausgleichstest verwenden, müssen Sie sicherstellen, dass Ihre Logik die Methode RoleEnvironment.OnStop berücksichtigt. Bei Verwendung des Standard-Lastenausgleichstests wird die Instanz von der Rotation ausgenommen, bevor OnStop aufgerufen wird. Bei einem benutzerdefinierten Lastenausgleichstest kann während des OnStop-Ereignisses jedoch weiterhin eine 200-Antwort vom Typ „OK“ zurückgegeben werden. Bei Verwendung des OnStop-Ereignisses zum Bereinigen des Cache, zum Beenden des Diensts oder zum Durchführen anderer Änderungen, die Auswirkungen auf das Laufzeitverhalten Ihres Diensts haben können, müssen Sie sicherstellen, dass die Logik Ihres benutzerdefinierten Lastenausgleichstests die Instanz aus der Rotation entfernt.
Grundlegendes Dienstdefinitionsschema für einen Lastenausgleichstest
Das Standardformat einer Dienstdefinitionsdatei, die einen Lastenausgleichstest enthält, lautet wie folgt.
<ServiceDefinition …>
<LoadBalancerProbes>
<LoadBalancerProbe name="<load-balancer-probe-name>" protocol="[http|tcp]" path="<uri-for-checking-health-status-of-vm>" port="<port-number>" intervalInSeconds="<interval-in-seconds>" timeoutInSeconds="<timeout-in-seconds>"/>
</LoadBalancerProbes>
</ServiceDefinition>
Schema-Elemente
Das Element LoadBalancerProbes der Dienstdefinitionsdatei umfasst folgende Elemente:
LoadBalancerProbes-Element
Das Element LoadBalancerProbes beschreibt die Sammlung von Lastenausgleichstests. Dieses Element ist dem LoadBalancerProbe-Element übergeordnet.
LoadBalancerProbe-Element
Das Element LoadBalancerProbe definiert den Integritätstest für ein Modell. Sie können mehrere Lastenausgleichstests definieren.
In der folgenden Tabelle sind die Attribute des LoadBalancerProbe-Elements beschrieben:
| Attribut | type | BESCHREIBUNG |
|---|---|---|
name |
string |
Erforderlich. Der Name des Lastenausgleichstests. Der Name muss eindeutig sein. |
protocol |
string |
Erforderlich. Gibt das Protokoll des Endpunkts an. Mögliche Werte sind http oder tcp. Wenn tcp angegeben wird, ist der Empfang einer Bestätigung erforderlich, damit der Test erfolgreich ist. Wenn http angegeben wird, ist eine 200 OK-Antwort vom angegebenen URI erforderlich, damit der Test erfolgreich ist. |
path |
string |
Der URI, mit dem der Integritätsstatus über den virtuellen Computer angefordert wird. path ist erforderlich, wenn protocol auf http festgelegt ist. Andernfalls wird dies nicht erlaubt.Es gibt keinen Standardwert. |
port |
integer |
Optional. Der Port für die Übertragung des Tests. Dieses Attribut ist für jeden Endpunkt optional, da derselbe Port für den Test verwendet wird. Sie können einen anderen Port für die Ausführung des Tests konfigurieren. Mögliche Werte reichen von 1 bis einschließlich 65535. Der Standardwert wird vom Endpunkt festgelegt. |
intervalInSeconds |
integer |
Optional. Das Intervall in Sekunden, in dem der Endpunkt auf den Integritätsstatus getestet werden soll. In der Regel ist das Intervall etwas kleiner als die Hälfte des zugeordneten Zeitlimits (in Sekunden). Dies ermöglicht die Durchführung von zwei vollständigen Tests, bevor die Instanz von der Rotation ausgenommen wird. Der Standardwert lautet 15. Der Mindestwert ist 5. |
timeoutInSeconds |
integer |
Optional. Das Zeitlimit in Sekunden für den Test, bei dem keine Antwort dazu führt, dass die Übermittlung von weiterem Datenverkehr an den Endpunkt beendet wird. Mit diesem Wert können Endpunkte schneller oder langsamer als bei den typischen, in Azure verwendeten Zeiten (Standardwerte) von der Rotation ausgenommen werden. Der Standardwert ist 31. Der Mindestwert ist 11. |