|
LED
|
Bedeutung
|
|
?
|
Verbunden
|
|
?
|
Nicht überwacht
|
|
?
|
Entleeren
|
|
?
|
Offline
|
|
?
|
Bereitschaft
|
|
?
|
Nicht verbunden
|
|
?
|
Status der Suche
|
|
?
|
Nicht lizenzierte oder lizenzierte Real Server überschritten
|
|
Option
|
Beschreibung
|
|
Online
|
Alle Real Server, die online zugewiesen sind, erhalten den Datenverkehr gemäß der Lastausgleichsrichtlinie, die auf der Registerkarte Basic eingestellt ist.
|
|
Abfluss
|
Alle Real Server, die als Drain zugewiesen sind, bedienen weiterhin bestehende Verbindungen, nehmen aber keine neuen Verbindungen an. Die Statusanzeige blinkt grün/blau, solange der Abfluss läuft. Sobald die bestehenden Verbindungen auf natürliche Weise geschlossen wurden, gehen die Real Server offline und die Statusanzeige leuchtet dauerhaft blau. Sie können diese Verbindungen auch anzeigen, indem Sie zum Abschnitt Navigation > Monitor > Status navigieren.
Das Entleerungsverhalten kann auf der Registerkarte "Erweiterte Einstellungen" geändert werden.
|
|
Offline
|
Alle Real Server, die auf Offline gesetzt sind, werden sofort offline genommen und erhalten keinen Datenverkehr.
|
|
Bereitschaft
|
Alle Real-Server, die als Standby-Server eingestellt sind, bleiben offline, bis ALLE Server der Online-Gruppe ihre Server Health Monitor-Prüfungen nicht mehr bestehen. In diesem Fall wird der Verkehr gemäß der Lastausgleichsrichtlinie von der Standby-Gruppe empfangen. Wenn ein Server in der Online-Gruppe die Server Health Monitor-Prüfung besteht, erhält dieser Online-Server den gesamten Datenverkehr, und die Standby-Gruppe erhält keinen Datenverkehr mehr.
|
|
Option
|
Beschreibung
|
|
Geringste Verbindungen
|
Der Load Balancer verfolgt die Anzahl der aktuellen Verbindungen zu jedem Real Server. Der Real Server mit der geringsten Anzahl von Verbindungen erhält die nächste neue Anfrage.
|
|
Schnellste
|
Die Richtlinie für den schnellsten Lastausgleich berechnet automatisch die über die Zeit geglättete Antwortzeit für alle Anfragen pro Server. Die Spalte Berechnetes Gewicht enthält den automatisch berechneten Wert. Eine manuelle Eingabe ist nur möglich, wenn diese Lastausgleichsrichtlinie verwendet wird.
|
|
Dauerhafter Cookie
|
Schicht 7 Sitzungsaffinität/Persistenz
Der IP-Listen-basierte Lastausgleichsmodus wird für jede erste Anfrage verwendet. Die ADC fügt ein Cookie in die Header der ersten HTTP-Antwort ein. Danach verwendet die ADC das Client-Cookie, um den Datenverkehr an denselben Back-End-Server zu leiten. Dieses Cookie wird für die Persistenz verwendet, wenn der Client jedes Mal zum selben Back-End-Server gehen muss. Das Cookie läuft nach 2 Stunden ab, und die Verbindung wird nach einem IP-Listen-basierten Algorithmus ausgeglichen. Diese Verfallszeit ist mit einem jetPACK konfigurierbar.
|
|
Runde Robin
|
Round Robin wird häufig in Firewalls und einfachen Lastverteilern verwendet und ist die einfachste Methode. Jeder Realserver erhält nacheinander eine neue Anfrage. Diese Methode ist nur dann geeignet, wenn Sie die Last gleichmäßig auf die Server verteilen müssen, z. B. bei Look-up-Webservern. Wenn Sie jedoch einen Lastausgleich auf der Grundlage der Anwendungslast oder der Serverlast vornehmen oder sogar sicherstellen müssen, dass Sie denselben Server für die Sitzung verwenden, ist die Round-Robin-Methode ungeeignet.
|
|
IP-Grenze
|
Layer 3 Session Affinity/Persistence Cookie.
In diesem Modus bildet die IP-Adresse des Clients die Grundlage für die Auswahl des Real-Servers, der die Anfrage erhält. Diese Aktion bietet Persistenz. HTTP und Layer-4-Protokolle können diesen Modus verwenden. Diese Methode ist hilfreich für interne Netzwerke, in denen die Netzwerktopologie bekannt ist und Sie sicher sein können, dass keine "Super-Proxys" vorgeschaltet sind. Bei Layer 4 und Proxies können alle Anfragen so aussehen, als kämen sie von einem einzigen Client, so dass die Belastung nicht gleichmäßig wäre. Bei HTTP wird die Header-Information (X-Forwarder-For) verwendet, wenn sie vorhanden ist, um mit Proxies fertig zu werden.
|
|
IP-Liste basiert
|
Die Verbindung zum Real Server wird über "Least connections" initiiert, wobei die Sitzungsaffinität auf der Grundlage der IP-Adresse des Clients erreicht wird. Standardmäßig wird eine Liste für 2 Stunden geführt, dies kann jedoch mit einem jetPACK geändert werden.
|
|
Gemeinsame IP-Liste basierend
|
Dieser Diensttyp ist nur verfügbar, wenn der Konnektivitätsmodus auf Direkte Serverrückkehr eingestellt ist. Er wurde in erster Linie zur Unterstützung des VMware-Lastausgleichs hinzugefügt.
|
|
Dauerhafter Cookie
|
Schicht 7 Sitzungsaffinität/Persistenz
Der IP-Listen-basierte Lastausgleichsmodus wird für jede erste Anfrage verwendet. Die ADC fügt ein Cookie in die Header der ersten HTTP-Antwort ein. Danach verwendet die ADC das Client-Cookie, um den Datenverkehr an denselben Back-End-Server zu leiten. Dieses Cookie wird für die Persistenz verwendet, wenn der Client jedes Mal zum selben Back-End-Server gehen muss. Das Cookie läuft nach 2 Stunden ab, und die Verbindung wird nach einem IP-Listen-basierten Algorithmus ausgeglichen. Diese Verfallszeit ist mit einem jetPACK konfigurierbar.
|
|
Klassisches ASP-Sitzungs-Cookie
|
Active Server Pages (ASP) ist eine serverseitige Technologie von Microsoft. Wenn diese Option aktiviert ist, behält die ADC die Sitzung auf demselben Server bei, wenn ein ASP-Cookie erkannt und in der Liste der bekannten Cookies gefunden wird. Wenn ein neues ASP-Cookie erkannt wird, erfolgt ein Lastausgleich nach dem Least-Connections-Algorithmus.
|
|
ASP.NET-Sitzungs-Cookie
|
Dieser Modus gilt für ASP.net. Wenn dieser Modus ausgewählt ist, behält die ADC die Sitzungspersistenz auf demselben Server bei, wenn ein ASP.NET-Cookie erkannt und in der Liste der bekannten Cookies gefunden wird. Wenn ein neues ASP-Cookie erkannt wird, erfolgt ein Lastausgleich nach dem Algorithmus der kleinsten Verbindungen.
|
|
JSP-Sitzungs-Cookie
|
Java Server Pages (JSP) ist eine serverseitige Technologie von Oracle. Wenn dieser Modus ausgewählt ist, behält die ADC die Sitzungspersistenz auf demselben Server bei, wenn ein JSP-Cookie erkannt und in seiner Liste der bekannten Cookies gefunden wird. Wenn ein neues JSP-Cookie erkannt wird, erfolgt ein Lastausgleich nach dem Least-Connections-Algorithmus.
|
|
JAX-WS Sitzungs-Cookie
|
Java Web Services (JAX-WS) ist eine serverseitige Technologie von Oracle. Wenn dieser Modus ausgewählt ist, behält die ADC die Sitzung auf demselben Server bei, wenn ein JAX-WS-Cookie erkannt und in der Liste der bekannten Cookies gefunden wird. Bei Erkennung eines neuen JAX-WS-Cookies erfolgt ein Lastausgleich nach dem Least-Connections-Algorithmus.
|
|
PHP-Sitzungs-Cookie
|
Personal Home Page (PHP) ist eine serverseitige Open-Source-Technologie. Wenn dieser Modus ausgewählt ist, hält die ADC die Sitzung auf demselben Server aufrecht, wenn ein PHP-Cookie erkannt wird.
|
|
Persistenz von RDP-Cookies
|
Diese Lastausgleichsmethode verwendet das von Microsoft erstellte RDP-Cookie, das auf Benutzername/Domäne basiert, um die Verbindung zu einem Server aufrechtzuerhalten. Der Vorteil dieser Methode besteht darin, dass die Verbindung zu einem Server aufrechterhalten werden kann, selbst wenn sich die IP-Adresse des Clients ändert.
|
|
Cookie-ID-basiert
|
Eine neue Methode, die "PhpCookieBased" und anderen Lastausgleichsmethoden sehr ähnlich ist, aber CookieIDBased und Cookie RegEx h=[^;]+ verwendet.
Diese Methode verwendet den Wert, der im Notizfeld "ID=X;" des Realservers festgelegt ist, als Cookie-Wert zur Identifizierung des Servers. Es handelt sich also um eine ähnliche Methode wie CookieListBased, die jedoch einen anderen Cookie-Namen verwendet und einen eindeutigen Cookie-Wert speichert, nämlich nicht die verschlüsselte IP, sondern die ID des Realservers (die beim Laden eingelesen wird).
Der Standardwert ist CookieIDName="h"; wenn es jedoch in den erweiterten Einstellungen des virtuellen Servers einen Überschreibungswert gibt, verwenden Sie stattdessen diesen. HINWEIS: Wir überschreiben den obigen Cookie-Ausdruck, um h= durch den neuen Wert zu ersetzen, wenn dieser Wert gesetzt ist.
Der letzte Punkt ist, dass, wenn ein unbekannter Cookie-Wert eintrifft und mit einer der Realserver-IDs übereinstimmt, dieser Server ausgewählt werden sollte; andernfalls ist die nächste Methode (delegieren) zu verwenden.
|
|
Option
|
Beschreibung
|
|
Keine
|
In diesem Modus wird der Real Server nicht überwacht und läuft immer korrekt. Die Einstellung Keine ist hilfreich für Situationen, in denen die Überwachung einen Server stört, und für Dienste, die nicht an der Failover-Aktion des ADC teilnehmen sollen. Dies ist ein Weg, um unzuverlässige oder veraltete Systeme zu hosten, die für den H/A-Betrieb nicht primär sind. Verwenden Sie diese Überwachungsmethode für jeden Diensttyp.
|
|
Ping/ICMP-Echo
|
In diesem Modus sendet der ADC eine ICMP-Echo-Anfrage an die IP-Adresse des Inhaltsservers. Wenn eine gültige Echo-Antwort empfangen wird, betrachtet die ADC den Real Server als betriebsbereit und der Verkehrsdurchsatz zum Server wird fortgesetzt. Außerdem wird der Dienst auf einem H/A-Paar verfügbar gehalten. Diese Überwachungsmethode kann für jeden Diensttyp verwendet werden.
|
|
TCP-Verbindung
|
In diesem Modus wird eine TCP-Verbindung zum Realserver hergestellt und sofort unterbrochen, ohne dass Daten gesendet werden. Wenn die Verbindung erfolgreich ist, betrachtet die ADC den Real Server als betriebsbereit. Diese Überwachungsmethode kann für jeden Diensttyp verwendet werden, wobei UDP-Dienste derzeit nicht für die Überwachung von TCP-Verbindungen geeignet sind.
|
|
ICMP unerreichbar
|
Der ADC sendet eine UDP-Zustandsprüfung an den Server und markiert den Real Server als nicht verfügbar, wenn er eine ICMP-Port-Unreachable-Meldung erhält. Diese Methode kann hilfreich sein, wenn Sie prüfen müssen, ob ein UDP-Dienstport auf einem Server verfügbar ist, wie z. B. DNS-Port 53.
|
|
RDP
|
In diesem Modus wird eine TCP-Verbindung wie in der Methode ICMP Unreachable beschrieben initialisiert. Nachdem die Verbindung initialisiert wurde, wird eine Layer-7-RDP-Verbindung angefordert. Wenn die Verbindung bestätigt wird, geht die ADC davon aus, dass der Real Server betriebsbereit ist. Diese Überwachungsmethode kann mit jedem Microsoft-Terminalserver verwendet werden.
|
|
200 OK
|
Bei dieser Methode wird eine TCP-Verbindung zum Real Server initialisiert. Nach erfolgreichem Verbindungsaufbau sendet die OEZA eine HTTP-Anfrage an den Realserver. Es wird auf eine HTTP-Antwort gewartet und auf den Antwortcode "200 OK" geprüft. Die OEZA betrachtet den Realserver als betriebsbereit, wenn der Antwortcode "200 OK" empfangen wird. Wenn die ADC aus irgendeinem Grund keinen "200 OK"-Antwortcode erhält, einschließlich Timeouts, Verbindungsabbrüche und andere Gründe, markiert die ADC den Real Server als nicht verfügbar. Diese Überwachungsmethode ist nur für die Verwendung mit HTTP- und beschleunigten HTTP-Diensttypen gültig. Wenn für einen HTTP-Server ein Layer-4-Diensttyp verwendet wird, kann er verwendet werden, wenn SSL auf dem Real Server nicht verwendet wird oder durch die "Content SSL"-Funktion entsprechend behandelt wird.
|
|
DICOM
|
Eine TCP-Verbindung zum Real-Server wird im DICOM-Modus initialisiert, und beim Verbindungsaufbau wird eine "Associate Request" von Echoscu an den Real-Server gesendet. Eine Konversation, die ein "Associate Accept" vom Content Server, eine Übertragung einer kleinen Datenmenge, gefolgt von einem "Release Request" und einer "Release Response" umfasst, schließt den Monitor erfolgreich ab. Wenn der Monitor nicht erfolgreich abgeschlossen wird, gilt der Real Server aus irgendeinem Grund als ausgefallen.
|
|
Benutzerdefiniert
|
Jeder Monitor, der im Abschnitt Real Server Monitoring konfiguriert wurde, erscheint in der Liste.
|
|
Option
|
Beschreibung
|
|
Vom Gastgeber
|
Das Caching pro Host basiert auf der Anwendung pro Hostname. Für jede Domäne/jeden Hostnamen gibt es einen eigenen Cache. Dieser Modus ist ideal für Webserver, die je nach Domäne mehrere Websites bedienen können.
|
|
Durch virtuellen Dienst
|
Wenn Sie diese Option wählen, ist Caching pro virtuellem Dienst möglich. Es gibt nur einen Cache für alle Domänen/Hostnamen, die den virtuellen Service durchlaufen. Diese Option ist eine spezielle Einstellung für die Verwendung mit mehreren Klonen einer einzelnen Site.
|
|
Option
|
Beschreibung
|
|
Aus
|
Deaktivieren Sie die Komprimierung für den virtuellen Dienst
|
|
Komprimierung
|
Wenn diese Option ausgewählt ist, wird die Komprimierung für den ausgewählten virtuellen Dienst aktiviert. Die ADC komprimiert den Datenstrom zum Client auf Anfrage dynamisch. Dieser Vorgang gilt nur für Objekte, die den Header content-encoding: gzip enthalten. Zu den Beispielinhalten gehören HTML, CSS oder JavaScript. Sie können auch bestimmte Inhaltstypen ausschließen, indem Sie den Abschnitt Globale Ausschlüsse verwenden.
|
|
Option
|
Beschreibung
|
|
Kein SSL
|
Der Verkehr von der Quelle zum ADC wird nicht verschlüsselt.
|
|
Alle
|
Lädt alle verfügbaren Zertifikate zur Verwendung
|
|
Standard
|
Diese Option führt dazu, dass ein lokal erstelltes Zertifikat namens "Standard" auf die Browserseite des Kanals angewendet wird. Verwenden Sie diese Option, um SSL zu testen, wenn noch kein Zertifikat erstellt oder importiert wurde.
|
|
Option
|
Beschreibung
|
|
Kein SSL
|
Der Verkehr vom ADC zum Real Server wird nicht verschlüsselt. Die Auswahl eines Zertifikats auf der Browserseite bedeutet, dass "No SSL" auf der Client-Seite gewählt werden kann, um eine so genannte "SSL-Offload" zu ermöglichen.
|
|
Jede
|
Der ADC fungiert als Client und akzeptiert jedes vom Real Server vorgelegte Zertifikat. Der Datenverkehr vom ADC zum Realserver wird verschlüsselt, wenn diese Option ausgewählt ist. Verwenden Sie die Option "Beliebig", wenn auf der Seite des virtuellen Dienstes ein Zertifikat angegeben ist, um die so genannte "SSL-Überbrückung" oder "SSL-Wiederverschlüsselung" zu ermöglichen.
|
|
SNI
|
SNI (Server Name Indication) ist eine Erweiterung des TLS-Netzwerkprotokolls, mit der der Client zu Beginn des Handshaking-Prozesses angibt, mit welchem Hostnamen er sich zu verbinden versucht. Mit dieser Einstellung kann die ADC mehrere Zertifikate für dieselbe virtuelle IP-Adresse und denselben TCP-Port bereitstellen.
|
|
Standard
|
Alle selbstsignierten Zertifikate, die Sie erstellt haben, erscheinen hier.
|
|
Option
|
Beschreibung
|
|
Umgekehrter Proxy
|
Reverse Proxy ist der Standardwert und verwendet Komprimierung und Zwischenspeicherung, wenn er mit Layer 7 verwendet wird. Auf Layer 4 arbeitet Reverse Proxy ohne Caching oder Komprimierung. In diesem Modus fungiert Ihr ADC als Reverse-Proxy und wird zur Quelladresse, die von den Real-Servern gesehen wird.
|
|
Direkte Serverrückgabe
|
Direct Server Return oder DSR, auch bekannt als DR - Direct Routing, ermöglicht es dem Server hinter dem Load Balancer, direkt an den Client zu antworten und dabei den ADC zu umgehen. DSR eignet sich nur für den Einsatz mit Layer 4-Lastausgleich. Daher sind Caching und Komprimierung bei dieser Option nicht verfügbar.
Dieser Modus kann nur mit den Diensttypen TCP, UDP und TCP/UDP verwendet werden.
Die Lastausgleichspersistenzrichtlinien sind außerdem auf Least Connections, Shared IP List Based, Round Robin und IP List Based beschränkt.
 Die Verwendung von DSR erfordert auch Änderungen am Realserver, die vorgenommen werden müssen. Bitte lesen Sie den Abschnitt Änderungen am Realserver.
|
|
NAT
|
Standardmäßig verwendet der ADC die IP-Adresse des ADC als Quell-IP-Adresse, und die Real-Server senden dann die Antwort an den ADC zurück, um sie an den Client zu senden. Dies ist unter fast allen Umständen in Ordnung, aber es gibt Szenarien, in denen der Real Server die Quell-IP-Adresse des Clients und nicht des ADC sehen muss.
Wenn der NAT-Modus angewendet wird, empfängt der ADC die eingehende Anfrage und sendet sie an den Realen Server, nachdem er die Quell-IP-Adresse wieder in die des Virtuellen Dienstes (VIP-Adresse) geändert hat.
Dieser Modus kann nur mit den folgenden Load Balancing Policies verwendet werden:
 |
|
Gateway
|
Im Gateway-Modus können Sie den gesamten Datenverkehr über den ADC leiten, so dass die Real Server über den ADC an andere Netzwerke über die virtuellen ADC-Dienste oder Hardware-Schnittstellen weitergeleitet werden können. Die Verwendung des Geräts als Gateway-Gerät für Real Server ist ideal für den Betrieb im Multi-Interface-Modus.
Die Lastausgleichspersistenzrichtlinien sind außerdem auf Least Connections, Shared IP List Based, Round Robin und IP List Based beschränkt.
Diese Methode erfordert, dass der Real Server sein Standardgateway auf die lokale Schnittstellenadresse des ADC (eth0, eth1 usw.) einstellt. Bitte lesen Sie den Abschnitt Real Server Änderungen.
Bitte beachten Sie, dass der Gateway-Modus keine Ausfallsicherung in einer Cluster-Umgebung unterstützt.
|
|
Option
|
Beschreibung
|
|
Keine
|
Wenn kein Proxy-Header vorhanden ist oder dieser im aktuellen Diensttyp nicht unterstützt wird
|
|
entfernen
|
Entfernt den Proxy-Header aus dem TCP-Paket
|
|
Weiterleiten
|
Leitet den Proxy-Header an den Server weiter
|
|
Option
|
Beschreibung
|
|
Version 1
|
Textbasiertes Format, einfach zu implementieren und zu debuggen.
Liefert grundlegende Informationen über die Verbindung des Clients, einschließlich Quell-IP, Ziel-IP, Quell- und Ziel-Port.
Die Protokollzeile wird an den Anfang der TCP-Verbindung angehängt, wodurch sie für den Menschen lesbar wird, aber im Vergleich zu binären Formaten etwas weniger leistungsfähig ist.
|
|
Version 2
|
Binäres Format, das für mehr Leistung und Effizienz ausgelegt ist.
Erweitert die Informationen, die über die Verbindung weitergegeben werden können, und unterstützt zusätzliche Daten wie Adressfamilie und protokollspezifische Informationen.
Bessere Kompatibilität mit modernen Netzwerkprotokollen und -funktionen, einschließlich Unterstützung für IPv6 und Transportprotokolle über TCP hinaus.
|
|
Option
|
Beschreibung
|
|
Basis-IP (Standard)
|
Verwendet die eth0- oder Basis-IP-Adresse des ADC als Quell-IP der Anfrage.
|
|
Virtuelle IP
|
Verwendet die virtuelle IP des Dienstes.
|
|
<IP-Adresse>
|
Ermöglicht es Ihnen, eine IP-Adresse anzugeben, die Teil des ADC ist. Dies kann eine andere Netzwerkschnittstelle oder ein anderes VIP sein.
|
|
Option
|
Beschreibung
|
|
Persistenzgesteuert
|
Dies ist die Standardauswahl.
Immer wenn der Benutzer die Persistenzsitzung besucht, wird sie verlängert.
Bei einer 24-stündigen Nutzung ist es möglich, dass der Abfluss nie erfolgt.
Wenn die Anzahl der Verbindungen zum realen Server jedoch 0 erreicht, wird der Abfluss beendet, die Persistenzsitzungen werden gelöscht, und alle Besucher werden bei der nächsten Verbindung neu abgeglichen.
|
|
Besucher migrieren
|
Persistente Sitzung wird bei erneutem Verbindungsaufbau ignoriert - (altes Verhalten vor 2022)
Neue TCP-Verbindungen (unabhängig davon, ob sie Teil einer bestehenden Sitzung sind oder nicht) werden immer zu einem realen Online-Server hergestellt.
Wenn die Persistenzsitzung zu einem ablaufenden realen Server gehörte, wird sie überschrieben.
Der virtuelle Dienst ignoriert die Persistenz neuer Verbindungen, und die Lastverteilung erfolgt auf einen neuen Server.
|
|
Sitzungen im Ruhestand
|
Dauerhafte Sitzungen werden nicht verlängert.
Eingehende Benutzerverbindungen werden dem gewünschten Server zugewiesen, aber ihre Persistenzsitzung wird nicht verlängert. Wenn also die Zeit der Persistenzsitzung überschritten ist, werden sie als neue Verbindung behandelt und auf einen anderen Server verschoben.
|
