Verwenden Sie beim Erstellen oder Bearbeiten Ihrer vRealize Automation-Cloud-Vorlagen die für Ihre Zwecke am besten geeigneten Lastausgleichsdienstressourcen.

Sie können NSX- und Cloud-unabhängige Lastausgleichsdienstressourcen in einer Cloud-Vorlage verwenden, um den Lastausgleich in einer Bereitstellung zu steuern.

Der Cloud-unabhängige Lastausgleichsdienst kann über mehrere Clouds hinweg bereitgestellt werden. Ein Cloud-spezifischer Lastausgleichsdienst kann erweiterte Einstellungen und Funktionen angeben, die nur für eine bestimmte Cloud/Topologie verfügbar sind. Cloud-spezifische Eigenschaften stehen im Ressourcentyp „NSX-Lastausgleichsdienst“ (Cloud.NSX.LoadBalancer) zur Verfügung. Wenn Sie diese Eigenschaften auf einem Cloud-unabhängigen Lastausgleichsdienst (Cloud.LoadBalancer) hinzufügen, werden sie bei Bereitstellung eines Amazon Web Services- oder Microsoft Azure-Lastausgleichsdiensts ignoriert. Die Eigenschaften werden aber berücksichtigt, wenn ein NSX-Lastausgleichsdienst bereitgestellt wird. Wählen Sie basierend auf den Bedingungen in Ihrer vRealize Automation-Cloud-Vorlage verfügbare Ressourcentypen des Lastausgleichsdiensts aus.

Sie können eine Lastausgleichsdienstressource nicht direkt mit einer Sicherheitsgruppenressource auf der Design-Arbeitsfläche verbinden.

Cloud-unabhängige Lastausgleichsdienstressource

Verwenden Sie einen Cloud-unabhängigen Lastausgleichsdienst, wenn Sie Netzwerkeigenschaften für alle Typen von Zielmaschinen angeben möchten.

Sie fügen einen Cloud-unabhängigen Lastausgleichsdienst mithilfe der Ressource Cloud-unabhängig > Lastausgleichsdienst auf der Seite „Design“ der Cloud-Vorlage hinzu. Die Ressource wird im Code der Cloud-Vorlage als Cloud.LoadBalancer-Ressourcentyp angezeigt. Die Standardressource wird wie folgt angezeigt: 
Cloud_LoadBalancer_1:
    type: Cloud.LoadBalancer
    properties:
      routes: []
      network: ''
      instances: []
      internetFacing: false

NSX-Lastausgleichsdienstressource

Verwenden Sie einen NSX-Lastausgleichsdienst, wenn die Cloud-Vorlage Eigenschaften enthält, die für NSX spezifisch sind (entweder die Richtlinien-API- oder die Manager-API-Methode). Sie können mindestens einen Lastausgleichsdienst an ein NSX-Netzwerk oder an Maschinen anhängen, die mit einem NSX-Netzwerk verknüpft sind.

Zum Hinzufügen eines NSX-Lastausgleichsdiensts verwenden Sie die Ressource NSX > Lastausgleichsdienst. Die Ressource wird im Code der Cloud-Vorlage als Cloud.NSX.LoadBalancer-Ressourcentyp angezeigt. Die Standardressource wird wie folgt angezeigt: 
Cloud_NSX_LoadBalancer_1:
    type: Cloud.NSX.LoadBalancer
    properties:
      routes: []
      network: ''
      instances: []

Optionen des Lastausgleichsdiensts im Code der Cloud-Vorlage

Durch Hinzufügen mindestens einer Lastausgleichsdienstressource zu Ihrer Cloud-Vorlage können Sie die folgenden Einstellungen angeben. Sie finden einige Beispiele hierzu unter Netzwerke, Sicherheitsressourcen und Lastausgleichsdienste in vRealize Automation.

Das HTTP-Protokoll wird für alle bedarfsgesteuerten Lastausgleichsdienste unterstützt.

Das HTTPS-Protokoll wird nur für bedarfsgesteuerte Lastausgleichsdienste unterstützt, die einem NSX-Cloud-Konto zugeordnet sind, dessen NSX-Modus auf Richtlinie festgelegt ist. NSX-Cloud-Konten, deren NSX-Modus auf Manager festgelegt ist, können das HTTPS-Protokoll nicht verwenden.

  • Maschinenspezifikation

    Sie können benannte Maschinenressourcen angeben, die an einem Lastausgleichspool teilnehmen sollen. Alternativ können Sie angeben, dass eine Netzwerkkarte (NIC) einer bestimmten Maschine am Lastausgleichspool teilnimmt.

    Diese Option ist nur für die NSX-Lastausgleichsdienstressource (Cloud.NSX.LoadBalancer) verfügbar.

    • resource.Cloud_Machine_1.id

      Gibt an, dass der Lastausgleichsdienst die im Code der Cloud-Vorlage als Cloud_Machine_1 angegebene Maschine berücksichtigt.

    • resource.Cloud_Machine_2.networks[2].id

      Gibt an, dass der Lastausgleichsdienst die im Code der Cloud-Vorlage als Cloud_Machine_2 festgelegte Maschine nur dann einbezieht, wenn sie für die Maschinen-Netzwerkkarte Cloud_Machine_2.networks[2] bereitgestellt wird.

  • Protokollierungsebene

    Mit dem Wert der Protokollierungsebene wird ein Schweregrad für das Fehlerprotokoll angegeben. Die Optionen lauten KEIN, NOTFALL, ALARM, KRITISCH, FEHLER, WARNUNG, INFO, DEBUGGEN und HINWEIS. Der Wert für die Protokollierungsebene gilt für alle Lastausgleichsdienste in der Cloud-Vorlage. Diese Option ist spezifisch für NSX. Für Lastausgleichsdienste mit einem übergeordneten Element überschreibt die Einstellung der übergeordneten Protokollierungsebene alle Einstellungen der Protokollierungsebene in den untergeordneten Elementen.

    Weitere Informationen hierzu finden Sie in Themen wie etwa Hinzufügen von Load Balancers in der NSX-Produktdokumentation.

  • Typ

    Verwenden Sie einen Lastausgleichsdiensttyp, um eine Skalierungsgröße anzugeben. Die Standardeinstellung ist „Klein“. Diese Option ist spezifisch für NSX. Für Lastausgleichsdienste mit einem übergeordneten Element überschreibt die Einstellung des übergeordneten Typs alle Einstellungen des Typs in den untergeordneten Elementen.

    • Klein

      Korreliert mit „Kompakt“ in NSX-V und „Klein“ in NSX-T.

    • Mittel

      Korreliert mit „Groß“ in NSX-V und „Mittel“ in NSX-T.

    • Groß

      Korreliert mit „Quad Large“ in NSX-V und „Groß“ in NSX-T.

    • Besonders groß

      Korreliert mit „Sehr groß“ in NSX-V und „Groß“ in NSX-T.

      Weitere Informationen hierzu finden Sie in Themen wie etwa Skalieren von Load Balancer-Ressourcen in der Produktdokumentation zu NSX.

    Diese Option ist nur für die NSX-Lastausgleichsdienstressource (Cloud.NSX.LoadBalancer) verfügbar.

  • Algorithmus (Serverpool)
    Verwenden Sie eine algorithmische Ausgleichsmethode, um die Verteilung eingehender Verbindungen unter den Serverpoolmitgliedern zu steuern. Der Algorithmus kann auf einem Serverpool oder direkt auf einem Server verwendet werden. Alle Lastausgleichsalgorithmen überspringen Server, die eine der folgenden Bedingungen erfüllen:
    • Der Admin-Zustand ist auf DISABLED festgelegt.
    • Der Admin-Zustand ist auf GRACEFUL_DISABLED festgelegt, und ein übereinstimmender Persistenzeintrag ist nicht vorhanden.
    • Der Zustand der aktiven oder passiven Integritätsprüfung lautet DOWN.
    • Der Verbindungsgrenzwert für die maximale Anzahl gleichzeitiger Verbindungen des Serverpools ist erreicht.

    Diese Option ist spezifisch für NSX.

    • IP_HASH

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

      Korreliert mit IP-HASH in NSX.

    • LEAST_CONNECTION

      Verteilt Clientanforderungen basierend auf der Anzahl der bereits auf dem Server vorhandenen Verbindungen auf mehrere Server. Neue Verbindungen werden an den Server mit den wenigsten Verbindungen gesendet. Ignoriert die Gewichtungen der Serverpoolmitglieder, auch wenn diese konfiguriert sind.

      Korreliert mit LEASTCONN in NSX-V und LEAST_CONNECTION in NSX-T.

    • ROUND_ROBIN

      Eingehende Clientanforderungen werden durch eine Liste verfügbarer Server geleitet, die die Anforderung verarbeiten können. Ignoriert die Gewichtungen der Serverpoolmitglieder, auch wenn sie konfiguriert sind. Standard.

      Korreliert mit ROUND_ROBIN in NSX.

    • WEIGHTED_LEAST_CONNECTION

      Jedem Server wird ein Gewichtungswert zugewiesen, der die Leistung dieses Servers verglichen mit anderen Servern im Pool angibt. Mit diesem Wert wird die Anzahl der Clientanforderungen angegeben, die im Vergleich zu anderen Servern im Pool an einen Server gesendet werden. Dieser Lastausgleichsalgorithmus konzentriert sich darauf, die Last gleichmäßig auf die verfügbaren Serverressourcen zu verteilen. Standardmäßig beträgt der Wert für die Gewichtung 1, wenn der Wert nicht konfiguriert ist und langsamer Start aktiviert ist.

      Korreliert mit WEIGHTED_LEAST_CONNECTION in NSX-T. In NSX-V ist keine Korrelation vorhanden.

    • WEIGHTED_ROUND_ROBIN

      Jedem Server wird ein Gewichtungswert zugewiesen, der die Leistung dieses Servers verglichen mit anderen Servern im Pool angibt. Mit diesem Wert wird die Anzahl der Clientanforderungen angegeben, die im Vergleich zu anderen Servern im Pool an einen Server gesendet werden. Dieser Lastausgleichsalgorithmus konzentriert sich darauf, die Last gleichmäßig auf die verfügbaren Serverressourcen zu verteilen.

      Korreliert mit WEIGHTED_ROUND_ROBIN in NSX-T. In NSX-V ist keine Korrelation vorhanden.

    • URI

      Der linke Teil des URI ist mit einem Hashwert versehen und wird durch das Gesamtgewicht der ausgeführten Server dividiert. Das Ergebnis bestimmt, welcher Server die Anforderung erhält. Der URI ist immer an denselben Server gerichtet, solange kein Server aktiviert oder deaktiviert wird. Der URI-Algorithmusparameter verfügt über zwei Optionen: uriLength=<len> und uriDepth=<dep>. Der Bereich für den Längenparameter muss 1<=len<256 lauten. Der Bereich für den Tiefenparameter muss 1<=dep<10 lauten. Auf die Parameter 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 Tiefenparameter legt die maximale Verzeichnistiefe zur Berechnung des Hash fest. Jeder Schrägstrich in der Anforderung wird als eine Ebene behandelt. Bei Angabe beider Parameter wird die Evaluierung beendet, wenn der Wert eines der beiden Parameter erreicht ist.

      Korreliert mit URI in NSX-V. In NSX-T ist keine Korrelation vorhanden.

    • HTTPHEADER

      Der Name des HTTP-Headers wird in jeder HTTP-Anforderung gesucht. Bei dem Header-Namen in Klammern wird die Groß- und Kleinschreibung nicht beachtet. Wenn der Header nicht vorhanden ist oder keinen Wert enthält, wird der Round-Robin-Algorithmus angewendet. Der HTTPHEADER-Algorithmusparameter verfügt über eine Option: headerName=<name>.

      Korreliert mit HTTPHEADER in NSX-V. In NSX-T ist keine Korrelation vorhanden.

    • URL

      Der im Argument angegebene URL-Parameter wird in der Abfragezeichenfolge jeder HTTP GET-Anforderung gesucht. 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 dividiert. Das Ergebnis bestimmt, 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. Der URL-Algorithmusparameter verfügt über eine Option: urlParam=<url>.

      Korreliert mit URL in NSX-V. In NSX-T ist keine Korrelation vorhanden.

    Weitere Informationen hierzu finden Sie in Themen wie etwa Hinzufügen eines Serverpools für das Load Balancing in der NSX-Produktdokumentation.

  • Integritätsüberwachungen

    Verwenden Sie die Optionen der Integritätsüberwachung, um zu testen, ob ein Server verfügbar ist. Die aktive Integritätsüberwachung für HTTP-, ICMP-, TCP- und UDP-Protokolle wird unterstützt. Die passive Integritätsüberwachung steht nur für NSX-T zur Verfügung.

    Diese Option ist spezifisch für NSX.

    • httpMethod

      HTTP-Methode, die zum Erkennen des Serverstatus für die Integritätsprüfungsanforderung verwendet wird. Die Methoden sind GET, HOST, OPTIONS, HEAD oder PUT.

    • requestBody

      Inhalt des Textkörpers der Integritätsprüfungsanforderung. Wird von den Protokollen HTTP, TCP und UDP verwendet und benötigt.

    • responseBody

      Erwarteter Inhalt des Textkörpers der Integritätsprüfungsantwort. Wenn die empfangene Zeichenfolge mit diesem Antworttext übereinstimmt, wird der Server als fehlerfrei betrachtet. Wird von den Protokollen HTTP, TCP und UDP verwendet und benötigt.

    Hinweis: Wenn Sie das UDP-Überwachungsprotokoll verwenden, sind die Parameter UDP Data Sent und UDP Data Expected erforderlich. Die Eigenschaften requestBody und responseBody werden diesen Parametern zugeordnet.

    Diese Option ist nur für die NSX-Lastausgleichsdienstressource (Cloud.NSX.LoadBalancer) verfügbar.

    Weitere Informationen hierzu finden Sie in Themen wie etwa Konfigurieren einer aktiven Systemzustandsüberwachung in der NSX-Produktdokumentation.

  • Integritätsprüfung

    Verwenden Sie die Optionen für die Integritätsprüfung, um festzulegen, wie der Lastausgleichsdienst Integritätsprüfungen durchführt.

    Diese Option ist nur für die NSX-Lastausgleichsdienstressource (Cloud.NSX.LoadBalancer) verfügbar.

    Unter Netzwerke, Sicherheitsressourcen und Lastausgleichsdienste in vRealize Automation finden Sie ein Beispiel für die verfügbaren Einstellungen der Integritätsprüfung.

NSX-Netzwerktypen und Optionen des Lastausgleichsdiensts

Die Optionen des Lastausgleichsdiensts hängen von dem Netzwerk ab, mit dem die Lastausgleichsdienstressource in der Cloud-Vorlage verknüpft ist. Sie können einen Lastausgleichsdienst relativ zum Netzwerktyp und den Netzwerkbedingungen konfigurieren.

  • Bedarfsgesteuertes Netzwerk

    Wenn die Berechnungen des Lastausgleichsdiensts mit einem bedarfsgesteuerten Netzwerk verbunden sind, wird ein neuer Tier-1-Router erstellt und mit dem im Netzwerkprofil angegebenen Tier-0-Router verbunden. Der Lastausgleichsdienst wird dann an den Tier-1-Router angehängt. Die VIP-Ankündigung des Tier-1-Routers ist aktiviert, wenn sich die VIP in einem vorhandenen Netzwerk befindet. Wenn ein bedarfsgesteuertes Netzwerk für DHCP konfiguriert wird, verwenden das bedarfsgesteuerte Netzwerk und der Lastausgleichsdienst den Tier-1-Router gemeinsam.

  • Vorhandenes Netzwerk

    Wenn der Lastausgleichsdienst mit einem vorhandenen Netzwerk verbunden ist, wird der Lastausgleichsdienst mit dem Tier-1-Router des vorhandenen Netzwerks erstellt. Ein neuer Lastausgleichsdienst wird erstellt, wenn kein Lastausgleichsdienst mit dem Tier-1-Router verbunden ist. Wenn der Lastausgleichsdienst bereits vorhanden ist, wird er mit neuen virtuellen Servern verbunden. Wenn das vorhandene Netzwerk nicht mit einem Tier-1-Router verbunden ist, wird ein neuer Tier-1-Router erstellt und an einen Tier-0-Router angehängt, der im Netzwerkprofil definiert ist. Die VIP-Ankündigung des Tier-1-Routers ist nicht aktiviert.

    vRealize Automation unterstützt keinen zweiarmigen NSX-T-Lastausgleichsdienst (Inline-Lastausgleichsdienst) auf zwei verschiedenen vorhandenen Netzwerken. Beachten Sie, dass sich der VIP-Uplink bei einem Szenario mit zweiarmigem Lastausgleichsdienst in einem vorhandenen Netzwerk befindet, während die Poolmitgliedsmaschinen mit einem bedarfsgesteuerten Netzwerk verbunden sind. Um den Lastausgleich bei Verwendung eines vorhandenen Netzwerks anzugeben, müssen Sie einen einarmigen Lastausgleichsdienst konfigurieren, bei dem dasselbe vorhandene Netzwerk für die Lastausgleichsdienst-VIP und die Poolmitgliedsmaschinen verwendet wird. Bei Verwendung eines im Netzwerkprofil ausgewählten Lastausgleichsdiensts hingegen können Sie den Lastausgleich zwischen Maschinen in zwei verschiedenen vorhandenen Netzwerken ermöglichen, wenn die beiden vorhandenen Netzwerke miteinander verbunden sind.

  • Im Netzwerkprofil definierte Netzwerkisolierung

    Für die Netzwerktypen outbound oder private können Sie Einstellungen für die Netzwerkisolierung in einem Netzwerkprofil angeben, um eine neue Sicherheitsgruppe zu emulieren. Da Maschinen mit einem vorhandenen Netzwerk verbunden sind und die Isolierungseinstellungen im Profil festgelegt sind, ähnelt diese Option einem Lastausgleichsdienst, der in einem vorhandenen Netzwerk erstellt wurde. Der Unterschied besteht darin, dass zum Aktivieren des Datenpfads die IP des Tier-1-Uplink-Ports zur Sicherheitsgruppe der Isolierung hinzugefügt wird.

Sie können Einstellungen des Lastausgleichsdiensts für mit NSX verknüpfte Netzwerke unter Verwendung einer NSX-Lastausgleichsdienstressource im Design der Cloud-Vorlage angeben.

Weitere Informationen finden Sie im VMware-Blogbeitrag vRA Cloud Assembly-Lastausgleichsdienst mit NSX-T Deep Dive.

Persistenz des NSX-T Load Balancer-Profils

Cloud-Vorlagen und Bereitstellungen für vRealize Automation unterstützen NSX-T Load Balancer-Persistenzprofiloptionen für SOURCE_IP- und COOKIE-Einstellungen. Informationen zum Konfigurieren dieser Einstellungen in NSX-T, sodass sie von Cloud-Vorlagen und Bereitstellungen für vRealize Automation verwendet werden können, finden Sie unter Hinzufügen eines Persistenzprofils in der NSX-T-Dokumentation.

Neukonfigurieren der Einstellungen für die Protokollierungsebene oder den Typ, wenn mehrere Lastausgleichsdienste einen Tier-1-Router in NSX-T oder einen Edge-Router in NSX-V gemeinsam nutzen

Wenn Sie eine Cloud-Vorlage mit mehreren Lastausgleichsdiensten verwenden, die einen Tier-1-Router im NSX-T-Endpoint oder einen Edge-Router im NSX-V-Endpoint gemeinsam nutzen, werden bei einer Neukonfiguration der Einstellungen für die Protokollierungsebene oder den Typ in einem der Lastausgleichsdienstressourcen die Einstellungen für die anderen Lastausgleichsdienste nicht aktualisiert. Nicht übereinstimmende Einstellungen verursachen Inkonsistenzen in NSX. Um Inkonsistenzen bei der Neukonfiguration dieser Einstellungen für die Protokollierungsebene und/oder den Typ zu vermeiden, verwenden Sie dieselben Neukonfigurationswerte für alle Lastausgleichsdienstressourcen in der Cloud-Vorlage, die in ihrem zugeordneten NSX-Endpoint einen Tier-1- oder Edge-Router gemeinsam nutzen.

Verfügbare Tag-2-Vorgänge

Wenn Sie eine Bereitstellung mit einem Lastausgleichsdienst horizontal herunter- oder hochskalieren, wird der Lastausgleichsdienst so konfiguriert, dass neu hinzugefügte Maschinen aufgenommen bzw. Lastausgleichsmaschinen, die entfernt werden sollen, angehalten werden.

Eine Liste allgemeiner Tag-2-Vorgänge, die für Cloud-Vorlagen und Bereitstellungen verfügbar sind, finden Sie unter Welche Aktionen kann ich auf Cloud Assembly-Bereitstellungen ausführen?.

Weitere Informationen

Informationen zum Definieren der Einstellungen für den Lastausgleichsdienst in einem Netzwerkprofil finden Sie unter Weitere Informationen zu Netzwerkprofilen in vRealize Automation.

Beispiele für Cloud-Vorlagen-Designs, die Lastausgleichsdienste enthalten, finden Sie unter Netzwerke, Sicherheitsressourcen und Lastausgleichsdienste in vRealize Automation.