Durch Auswahl der Option Anpassen auf der Registerkarte Allgemein können Sie Informationen zu den Poolmitgliedern angeben, wie z. B. den Port, an dem die Mitglieder Datenverkehr erhalten, den Protokolltyp, den der NSX-Lastausgleichsdienst für den Zugriff auf diesen Port verwenden kann, den Algorithmus, der für den Lastausgleichsdienst verwendet wird, oder Persistenzeinstellungen.

Warum und wann dieser Vorgang ausgeführt wird

Ein Pool stellt einen Cluster aus Maschinen mit Lastausgleich dar. Ein Poolmitglied steht für eine Maschine in diesem Cluster.

Das Standardmitgliedsprotokoll und die Mitgliedsporteinstellungen stimmen mit den Protokoll- und Porteinstellungen auf der Seite Allgemein überein.

Der Pool der Mitgliedsmaschinen wird im Optionswert Mitglied auf der Benutzeroberfläche der Blueprint-Komponente für den Lastausgleichsdienst angezeigt. Der Eintrag Mitglied ist auf den Pool oder Cluster von Maschinen festgelegt.

Prozedur

  1. (Optional) : Die Einstellung Mitgliedsprotokoll entspricht dem Protokoll, das Sie auf der Registerkarte Allgemein angegeben haben. Diese Einstellung definiert, wie das Poolmitglied Netzwerkdatenverkehr empfängt.
  2. (Optional) : Geben Sie eine Portnummer in das Textfeld Mitgliedsport ein, um den Port anzugeben, auf dem das Poolmitglied Netzwerkdatenverkehr empfangen soll.

    Wenn die eingehende Anforderung für die virtuelle IP-Adresse (VIP) des Lastausgleichsdiensts an Port 80 ankommt, möchten Sie die Anforderung möglicherweise an einen anderen Port innerhalb der Poolmitglieder weiterleiten, zum Beispiel an Port 8080.

  3. (Optional) : Wählen Sie die algorithmische Ausgleichsmethode für diesen Pool aus.

    Die Algorithmusoptionen und die Algorithmusparameter für die Optionen, die diese benötigen, werden in der folgenden Tabelle beschrieben.

    Option

    Beschreibung und Algorithmusparameter

    ROUND_ROBIN

    Dabei wird die jedem Server zugeordnete Gewichtung berücksichtigt.

    Wenn der Lastausgleichsdienst in vRealize Automation erstellt wurde, ist die Gewichtung für alle Mitglieder identisch.

    Dies ist der geeignetste Algorithmus bei gleichmäßig verteilter Prozessorzeit auf dem Server.

    Algorithmusparameter sind für diese Option deaktiviert.

    IP-HASH

    Wählt einen Server auf der Basis eines Hash der Quell-IP-Adresse und der gesamten Gewichtung aller ausgeführten Server aus.

    Algorithmusparameter sind für diese Option deaktiviert.

    LEASTCONN

    Verteilt basierend auf der Anzahl der bereits auf den Servern aktiven Verbindungen die Client-Anforderungen an mehrere Server.

    Neue Verbindungen werden an den Server mit den wenigsten Verbindungen gesendet.

    Algorithmusparameter sind für diese Option deaktiviert.

    URI

    Der linke Teil des URI (vor dem Fragezeichen) wird zerlegt und durch die Gesamtgewichtung der ausgeführten Server geteilt.

    Aus dem Ergebnis wird ersichtlich, welcher Server die Anforderung erhält. Dies gewährleistet, dass ein URI immer auf denselben Server gerichtet ist, solange kein Server heruntergefahren oder gestartet wird.

    Der URI-Algorithmusparameter verfügt über zwei Optionen: uriLength=<len> und uriDepth=<dep>. Geben Sie die Parameter für Länge und Tiefe in separate Zeilen in das Textfeld Algorithmus-Parameter ein.

    Den Parametern für Länge und Tiefe folgt eine positive Ganzzahl. Mit diesen Optionen können Server nur auf der Basis des Anfangs des URI ausgeglichen werden.

    Der Längenparameter gibt an, dass der Algorithmus nur die definierten Zeichen am Anfang des URI zur Berechnung des Hash verwenden soll. Der Bereich für den Längenparameter lautet 1<=len<256.

    Der Tiefenparameter legt die maximale Verzeichnistiefe zur Berechnung des Hash fest. Jeder Schrägstrich in der Anforderung wird als ein Level behandelt. Der Bereich für den Tiefenparameter lautet 1<=dep<10.

    Bei Angabe beider Parameter wird die Evaluierung beendet, wenn der Wert eines der beiden Parameter erreicht ist.

    HTTPHEADER

    Der Name des HTTP-Headers, der in jeder HTTP-Anforderung gesucht wird.

    Für den Header-Namen in Klammern wird wie bei der Funktion ACL 'hdr()' nicht zwischen Groß- und Kleinschreibung unterschieden.

    Der HTTPHEADER-Algorithmusparameter verfügt über eine Option: headerName=<name>. Beispielsweise können Sie als HTTPHEADER-Algorithmusparameter host verwenden.

    Wenn der Header nicht vorhanden ist oder keinen Wert enthält, wird der Round-Robin-Algorithmus angewendet.

    URL

    Der im Argument angegebene URL-Parameter wird in der Abfragezeichenfolge jeder HTTP GET-Anforderung gesucht.

    Der URL-Algorithmusparameter verfügt über eine Option: urlParam=<url>.

    Stehen nach dem Parameter ein Gleichheitszeichen (=) und ein Wert, erhält der Wert einen Hash und wird durch die gesamte Gewichtung der ausgeführten Server geteilt. Aus dem Ergebnis wird ersichtlich, welcher Server die Anforderung erhält. Mit diesem Vorgang werden Benutzerbezeichner in Anforderungen ermittelt und es wird damit sichergestellt, dass eine bestimmte Benutzer-ID immer zum selben Server gesendet wird, solange kein Server aktiviert oder deaktiviert wird.

    Wenn kein Wert oder kein Parameter gefunden wurde, wird ein Round-Robin-Algorithmus angewendet.

  4. (Optional) : Wählen Sie die Persistenzmethode für diesen Pool aus.

    Die Persistenz verfolgt und speichert Sitzungsdaten wie das spezifische Poolmitglied, das eine Client-Anforderung verarbeitet hat. Mit Persistenz werden die Client-Anforderungen in einer gesamten Sitzung oder während nachfolgender Sitzungen demselben Poolmitglied zugeordnet.

    Protokoll

    Unterstützte Persistenzmethode

    HTTP

    Keine, Cookie, Quell-IP

    HTTPS

    Keine, Quell-IP und SSI-Sitzungs-ID

    TCP

    Keine, Quell-IP, MSRDP

    UDP

    Keine, Quell-IP

    • Wählen Sie Cookie aus, um ein eindeutiges Cookie zur Identifizierung der Sitzung beim ersten Zugriff eines Clients auf die Site einzufügen. Auf das Cookie wird in den folgenden Anforderungen zur Aufrechterhaltung der Verbindung mit dem jeweiligen Server Bezug genommen.

    • Wählen Sie Quell-IP aus, um Sitzungen auf der Basis der Quell-IP-Adresse nachzuverfolgen. Wenn ein Client eine Verbindung zu einem virtuellen Server anfordert, der die Affinitätspersistenz der Quelladresse unterstützt, überprüft der Lastausgleichsdienst, ob der Client sich zuvor verbunden hat, und wenn dies der Fall ist, gibt er den Client an dasselbe Poolmitglied zurück.

    • Wählen Sie SSL-Sitzungs-ID aus und wählen Sie das HTTPS-Datenverkehrsmuster für SSL-Passthrough aus.

      • SSL-Passthrough – Client -> HTTPS-> LB (mit SSL-Passthrough) -> HTTPS -> Server

      • Client -> HTTP-> LB -> HTTP -> Server

      Anmerkung:

      vRealize Automation unterstützt derzeit nur SSL-Passthrough. Die Methode SSL-Passthrough wird unabhängig davon, welche Option Sie ausgewählt haben, verwendet.

    • Wählen Sie MSRDP aus, um dauerhafte Sitzungen zwischen Windows-Clients und -Servern beizubehalten, auf denen der Remotedesktopprotokoll-Dienst von Microsoft (RDP) ausgeführt wird. Das empfohlene Szenario für die Aktivierung der MSRDP-Persistenz ist das Erstellen eines Lastausgleichspools, der aus Mitgliedern besteht, die die unterstützte Windows Server-Version ausführen, wobei alle Mitglieder zu einem Windows-Cluster gehören und an einem Windows-Sitzungsverzeichnis teilnehmen.

    • Wählen Sie Keine aus, um anzugeben, dass die Sitzungsaktionen nicht für nachfolgende Rückrufe gespeichert werden.

  5. Wenn Sie eine Cookiepersistenzeinstellung verwenden, geben Sie den Cookienamen ein.
  6. (Optional) : Wählen Sie den Modus aus, in dem das Cookie über das Dropdown-Menü Modus eingefügt wird.

    Option

    Beschreibung

    Einfügen

    NSX Edge sendet ein Cookie.

    Sendet der Server eines oder mehrere Cookies, dann erhält der Client ein zusätzliches Cookie (Server-Cookie(s) + NSX Edge-Cookie). Sendet der Server keine Cookies, dann erhält der Client nur das NSX Edge-Cookie.

    Präfix

    Der Server sendet ein Cookie. Verwenden Sie diese Option, wenn Ihr Client nur ein Cookie unterstützt.

    Wenn Sie über eine proprietäre Anwendung verfügen, die einen proprietären Client verwendet, der nur ein Cookie unterstützt, sendet der Webserver ein Cookie, aber der NSX Edge fügt seine Cookieinformationen im Servercookiewert (als Präfix) ein.

    App-Sitzung

    Der Server sendet kein Cookie. Stattdessen sendet er die Informationen zur Benutzersitzung als URL.

    Beispiel: http://mysite.com/admin/UpdateUserServlet;jsessionid=X000X0XXX0XXXX, wobei jsessionid die Informationen zur Benutzersitzung darstellen und für die Persistenz verwendet werden.

  7. (Optional) : Geben Sie das Persistenz-Ablaufdatum für das Cookie in Sekunden ein.

    Beispiel: Der Persistenzeintrag für den L7-Lastausgleich mit einer TCP-Quell-IP läuft ab, wenn keine neuen TCP-Verbindungen für das angegebene Ablaufdatum hergestellt werden, auch wenn die vorhandenen Verbindungen immer noch aktiv sind.

  8. (Optional) : Klicken Sie auf die Registerkarte Integritätsprüfung und fahren Sie mit dem Thema Definieren der Einstellungen für Integritätsprüfungen im virtuellen Server fort, um das Definieren des virtuellen Servers für denNSX-Lastausgleichsdienst fortzusetzen.