Freigeben über


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.

Die Load-Balancer-Prüfung ist eine vom Kunden definierte Überprüfung 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 einer Lastenausgleichsprobe

Der Azure Load Balancer ist für das Routing von eingehendem Datenverkehr zu Ihren Rolleninstanzen verantwortlich. Der Lastverteiler bestimmt, welche Instanzen Datenverkehr empfangen können, indem er regelmäßig den Zustand jeder Instanz prüft. Der Load Balancer überwacht jede Instanz mehrmals pro Minute. 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 Load-Balancer-Test erhält Vorrang vor dem Standard-Gast-Agent-Test und ermöglicht es Ihnen, eine eigene benutzerdefinierte Logik zur Bestimmung des Zustands 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 implementieren (z. B. die Rückgabe eines nicht-200-Statuscodes, 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 eine benutzerdefinierte Load-Balancer-Überprüfungsabfrage verwenden, müssen Sie sicherstellen, dass Ihre Logik die Methode RoleEnvironment.OnStop berücksichtigt. Bei Verwendung der Standard-Lastenausgleichs-Probe wird die Instanz aus der Rotation entfernt, bevor OnStop aufgerufen wird. Eine benutzerdefinierte Lastenausgleichs-Probe kann jedoch während des OnStop-Ereignisses weiterhin einen 200-OK-Status zurückgeben. 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 eine Load Balancer Abfrage

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 die Gesundheitsüberprüfung für ein Modell. Sie können mehrere Lastverteilungsüberwachungstests definieren.

In der folgenden Tabelle sind die Attribute des LoadBalancerProbe-Elements beschrieben:

Attribut Typ BESCHREIBUNG
name string Erforderlich. Der Name der Load-Balancer-Probe. 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, muss eine empfangene Bestätigung vorliegen, 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, der zum Anfordern des Gesundheitsstatus von der VM verwendet wird. path ist erforderlich, wenn protocol auf http festgelegt ist. Andernfalls wird dies nicht erlaubt.

Es gibt keinen Standardwert.
port integer Wahlfrei. Der Port für die Kommunikation des Sondes. Dieses Attribut ist für jeden Endpunkt optional, da derselbe Port für den Test verwendet wird. Sie können auch einen anderen Port für ihre Prüfung konfigurieren. Mögliche Werte reichen von 1 bis einschließlich 65535.

Der Standardwert wird vom Endpunkt festgelegt.
intervalInSeconds integer Wahlfrei. Das Intervall in Sekunden für die Häufigkeit, mit der der Endpunkt auf den Gesundheitsstatus überprüft werden soll. In der Regel ist das Intervall etwas kleiner als die Hälfte des zugeordneten Timeout-Zeitraums (in Sekunden), was zwei vollständige Überprüfungen ermöglicht, bevor die Instanz aus dem Umlauf genommen wird.

Der Standardwert ist 15. Der Mindestwert ist 5.
timeoutInSeconds integer Wahlfrei. Der Timeout-Zeitraum in Sekunden, der auf die Abfrage angewendet wird, wobei das Ausbleiben einer Antwort dazu führt, dass kein weiterer Datenverkehr an den Endpunkt geliefert 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.

Siehe auch

Clouddienst-Definitionsschema (klassisch)