|
Feld
|
Beschreibung
|
|
IP-Adresse
|
Geben Sie eine neue virtuelle IP-Adresse ein, die als Zieleinstiegspunkt für den Zugriff auf den Real-Server dienen soll. Diese IP ist der Punkt, auf den Benutzer oder Anwendungen zeigen, um auf die Anwendung mit Lastausgleich zuzugreifen.
|
|
Subnetzmaske/Präfix
|
Dieses Feld ist für die Subnetzmaske, die für das Netzwerk relevant ist, in dem sich der ADC befindet
|
|
Hafen
|
Der Eingangsport, der beim Zugriff auf das VIP verwendet wird. Dieser Wert muss nicht unbedingt mit dem Real-Server übereinstimmen, wenn Sie Reverse-Proxy verwenden.
|
|
Dienst Name
|
Der Dienstname ist eine textuelle Darstellung des Zwecks des VIPs. Er ist optional, aber wir empfehlen Ihnen, ihn aus Gründen der Übersichtlichkeit anzugeben.
|
|
Service Typ
|
Es gibt viele verschiedene Diensttypen, die Sie auswählen können. Layer-4-Diensttypen können die flightPATH-Technologie nicht verwenden.
|
|
Feld
|
Beschreibung
|
|
Aktivität
|
Über das Feld Aktivität kann der Status des lastverteilten realen Servers angezeigt und geändert werden.
Online - Zeigt an, dass der Server aktiv ist und Lastausgleichsanfragen empfängt
Offline - Der Server ist offline und empfängt keine Anfragen
Drain - Der Server wurde in den Drain-Modus versetzt, damit die Persistenz geleert und der Server in einen Offline-Zustand versetzt werden kann, ohne dass die Benutzer beeinträchtigt werden.
Standby - Der Server wurde in einen Standby-Zustand versetzt
|
|
IP-Adresse
|
Dieser Wert ist die IP-Adresse des Real-Servers. Sie muss genau sein und sollte keine DHCP-Adresse sein.
|
|
Hafen
|
Der Ziel-Port des Zugriffs auf dem Real-Server. Bei Verwendung eines Reverse-Proxys kann dieser von dem auf dem VIP angegebenen Eingangs-Port abweichen.
|
|
Gewichtung
|
Diese Einstellung wird normalerweise automatisch vom ADC konfiguriert. Sie können dies ändern, wenn Sie die Prioritätsgewichtung ändern möchten.
|
|
Option
|
Beschreibung
|
|
Cluster
|
Cluster ist die Standardrolle für das ADC bei der Installation, und die Spalte Primary/Mode zeigt den Modus an, in dem es gerade läuft. Wenn Sie ein HA-Paar von ADC-Appliances in Ihrem Rechenzentrum haben, wird eine von ihnen als aktiv und die andere als passiv angezeigt
|
|
Handbuch
|
Mit der Rolle "Manuell" kann das ADC-Paar im Aktiv-Aktiv-Modus für verschiedene virtuelle IP-Adressen betrieben werden. In solchen Fällen enthält die Spalte "Primary" (Primär) ein Kästchen neben jeder eindeutigen virtuellen IP, das für "Active" (aktiv) angekreuzt oder für "Passive" (passiv) nicht angekreuzt werden kann.
|
|
Stand-Alone
|
Der ADC agiert als eigenständiges Gerät und befindet sich nicht im Hochverfügbarkeitsmodus. In der Spalte "Primär" wird daher "Stand-alone" angezeigt.
|
|
LED
|
Bedeutung
|
|
l
|
Online
|
|
l
|
Failover-Standby. Dieser virtuelle Dienst ist hot-standby
|
|
l
|
Zeigt an, dass ein "Sekundär" auf einen "Primär" wartet.
|
|
l
|
Dienst benötigt Aufmerksamkeit. Diese Anzeige kann daraus resultieren, dass ein Real Server eine Zustandsüberprüfung nicht bestanden hat oder manuell auf Offline geändert wurde. Der Datenverkehr fließt weiter, jedoch mit reduzierter Real-Server-Kapazität
|
|
l
|
Offline. Inhaltsserver sind nicht erreichbar, oder keine Inhaltsserver aktiviert
|
|
l
|
Status finden
|
|
l
|
Nicht lizenziert oder lizenzierte virtuelle IPs überschritten
|
|
Service Typ
|
Anschluss/Protokoll
|
Dienstschicht
|
Kommentar
|
|
Schicht 4 TCP
|
Beliebiger TCP-Port
|
Schicht 4
|
Der ADC verändert keine Informationen im Datenstrom und führt einen Standard-Lastausgleich des Datenverkehrs gemäß der Lastausgleichsrichtlinie durch
|
|
Schicht 4 UDP
|
Beliebiger UDP-Port
|
Schicht 4
|
Wie bei Layer 4 TCP verändert der ADC keine Informationen im Datenstrom und führt einen Standard-Lastausgleich des Datenverkehrs gemäß der Lastausgleichsrichtlinie durch
|
|
Schicht 4 TCP/UDP
|
Beliebiger TCP- oder UDP-Port
|
Schicht 4
|
Es ist ideal, wenn Ihr Dienst ein primäres Protokoll wie UDP hat, aber auf TCP zurückgreifen wird. Der ADC ändert keine Informationen im Datenstrom und führt den Standard-Lastausgleich des Datenverkehrs gemäß der Lastausgleichsrichtlinie durch
|
|
HTTP
|
HTTP- oder HTTPS-Protokoll
|
Schicht 7
|
Der ADC kann mit flightPATH interagieren, den Datenstrom manipulieren und modifizieren.
|
|
FTP
|
Dateiübertragungsprotokoll Protokoll
|
Schicht 7
|
Verwendung getrennter Steuer- und Datenverbindungen zwischen Client und Server
|
|
SMTP
|
Simple Mail Transfer Protocol
|
Schicht 4
|
Verwendung beim Lastausgleich von Mailservern
|
|
POP3
|
Postamt-Protokoll
|
Schicht 4
|
Verwendung beim Lastausgleich von Mailservern
|
|
IMAP
|
Internet Message Access Protocol
|
Schicht 4
|
Verwendung beim Lastausgleich von Mailservern
|
|
RDP
|
Remote-Desktop-Protokoll
|
Schicht 4
|
Verwendung beim Lastausgleich für Terminaldienste-Server
|
|
RPC
|
Remote Procedure Call
|
Schicht 4
|
Verwendung beim Lastausgleich von Systemen mit RPC-Aufrufen
|
|
RPC/ADS
|
Exchange 2010 Statischer RPC für Adressbuchdienst
|
Schicht 4
|
Verwendung beim Lastausgleich von Exchange-Servern
|
|
RPC/CA/PF
|
Exchange 2010 Static RPC für Client-Zugriff & Öffentliche Ordner
|
Schicht 4
|
Verwendung beim Lastausgleich von Exchange-Servern
|
|
DICOM
|
Digitale Bildgebung und Kommunikation in der Medizin
|
Schicht 4
|
Verwendung beim Lastausgleich von Servern mit DICOM-Protokollen
|
|
LED
|
Bedeutung
|
|
l
|
Verbunden
|
|
£
|
Nicht überwacht
|
|
l
|
Entleeren
|
|
l
|
Offline
|
|
l
|
Standby
|
|
l
|
Nicht angeschlossen
|
|
l
|
Status der Suche
|
|
l
|
Nicht lizenzierte oder lizenzierte Real-Server überschritten
|
|
Option
|
Beschreibung
|
|
Online
|
Alle Real-Server, die online zugewiesen sind, erhalten den Datenverkehr gemäß der auf der Registerkarte "Basic" eingestellten Lastausgleichsrichtlinie.
|
|
Ablassen
|
Alle Real-Server, die als Drain zugewiesen sind, bedienen weiterhin bestehende Verbindungen, nehmen aber keine neuen Verbindungen an. Die Statusanzeige blinkt grün/blau, während die Entleerung durchgeführt wird. Sobald die bestehenden Verbindungen auf natürliche Weise geschlossen wurden, gehen die Real-Server offline, und die Statusanzeige leuchtet durchgehend blau. Sie können diese Verbindungen auch anzeigen, indem Sie zum Bereich "Navigation > Monitor > Status" navigieren.
|
|
Offline
|
Alle Real-Server, die als Offline eingestellt sind, werden sofort offline genommen und erhalten keinen Datenverkehr.
|
|
Standby
|
Alle Real-Server, die als Standby eingestellt sind, bleiben offline, bis ALLE Server der Online-Gruppe ihre Server Health Monitor-Prüfungen nicht bestehen. Der Verkehr wird von der Standby-Gruppe gemäß der Lastausgleichsrichtlinie empfangen, wenn dies geschieht. 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
|
|
Schnellste
|
Die Richtlinie Schnellster Lastausgleich berechnet automatisch die Antwortzeit für alle Anfragen pro Server geglättet über die Zeit. Die Spalte Berechnetes Gewicht enthält den automatisch berechneten Wert. Eine manuelle Eingabe ist nur bei Verwendung dieser Lastausgleichsrichtlinie möglich.
|
|
Runde Robin
|
Round Robin wird häufig in Firewalls und einfachen Lastverteilern verwendet und ist die einfachste Methode. Jeder Real Server erhält nacheinander eine neue Anfrage. Diese Methode ist nur dann geeignet, wenn Sie einen gleichmäßigen Lastausgleich zwischen den Servern herstellen müssen, z. B. bei der Suche nach Webservern. Wenn Sie jedoch einen Lastausgleich basierend auf der Anwendungslast oder der Serverlast benötigen oder sogar sicherstellen müssen, dass Sie denselben Server für die Sitzung verwenden, ist die Round Robin-Methode ungeeignet.
|
|
Geringste Verbindungen
|
Der Load Balancer behält die Anzahl der aktuellen Verbindungen zu jedem Real Server im Auge. Der Real Server mit der geringsten Anzahl von Verbindungen erhält die nachfolgende neue Anfrage.
|
|
Schicht 3 Sitzungsaffinität/Persistenz - IP Bound
|
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, und somit wäre die Last nicht gleichmäßig. Bei HTTP wird die Header-Information (X-Forwarder-For) verwendet, wenn sie vorhanden ist, um mit Proxies fertig zu werden.
|
|
Layer 3 Sitzungsaffinität/Persistenz - IP-Listenbasiert
|
Die Verbindung zum Real-Server wird mit "Least connections" initiiert, dann wird eine Sitzungsaffinität basierend auf der IP-Adresse des Clients erreicht. Standardmäßig wird eine Liste für 2 Stunden geführt, dies kann jedoch mit einem jetPACK geändert werden.
|
|
Schicht 7 Session Affinität/Persistenz - ALB Session Cookie
|
Dieser Modus ist die am häufigsten verwendete Persistenzmethode für den HTTP-Lastausgleich. In diesem Modus verwendet der ADC den IP-Listen-basierten Lastausgleich für jede erste Anfrage. Er fügt ein Cookie in die Header der ersten HTTP-Antwort ein. Danach verwendet der 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 ab, sobald die Sitzung geschlossen wird.
|
|
Schicht 7 Session Affinität/Persistenz - ALB Persistent Cookie
|
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.
|
|
Session-Cookie - Klassisches ASP-Session-Cookie
|
Active Server Pages (ASP) ist eine serverseitige Technologie von Microsoft. Wenn diese Option aktiviert ist, behält das ADC die Sitzungspersistenz auf demselben Server bei, wenn ein ASP-Cookie erkannt und in seiner Liste der bekannten Cookies gefunden wird. Bei der Erkennung eines neuen ASP-Cookies wird ein Lastausgleich mit dem Algorithmus "Least Connections" durchgeführt.
|
|
Sitzungs-Cookie - ASP.NET-Sitzungs-Cookie
|
Dieser Modus gilt für ASP.net. Wenn dieser Modus ausgewählt ist, behält das ADC die Sitzungspersistenz zum selben Server bei, wenn ein ASP.NET-Cookie erkannt und in seiner Liste der bekannten Cookies gefunden wird. Bei der Erkennung eines neuen ASP-Cookies wird ein Lastausgleich mit dem Algorithmus "Least Connections" durchgeführt.
|
|
Session-Cookie - JSP-Session-Cookie
|
Java Server Pages (JSP) ist eine serverseitige Technologie von Oracle. Wenn dieser Modus ausgewählt ist, behält das ADC die Sitzungspersistenz auf demselben Server bei, wenn ein JSP-Cookie erkannt und in seiner Liste der bekannten Cookies gefunden wird. Bei der Erkennung eines neuen JSP-Cookies wird ein Lastausgleich mit dem Algorithmus "Least Connections" durchgeführt.
|
|
Sitzungs-Cookie - JAX-WS Sitzungs-Cookie
|
Java Web Services (JAX-WS) ist eine serverseitige Technologie von Oracle. Wenn dieser Modus ausgewählt ist, behält das ADC die Sitzungspersistenz zum selben Server bei, wenn ein JAX-WS-Cookie erkannt und in seiner Liste der bekannten Cookies gefunden wird. Bei Erkennung eines neuen JAX-WS-Cookies wird ein Lastausgleich mit dem Least Connections-Algorithmus durchgeführt.
|
|
Session-Cookie - PHP-Session-Cookie
|
Personal Home Page (PHP) ist eine serverseitige Open-Source-Technologie. Wenn dieser Modus ausgewählt ist, behält das ADC die Sitzungspersistenz auf demselben Server bei, wenn ein PHP-Cookie erkannt wird.
|
|
Sitzungs-Cookie - RDP-Cookie-Persistenz
|
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 ist, dass die Aufrechterhaltung der Verbindung zu einem Server auch dann möglich ist, 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 eingestellt ist, als Cookie-Wert zur Identifizierung des Servers. Es handelt sich also um eine ähnliche Methode wie CookieListBased, verwendet aber einen anderen Cookie-Namen und speichert einen eindeutigen Cookie-Wert, nicht die verschlüsselte IP, sondern die ID des Realen Servers (die zur Ladezeit eingelesen wird).
Der Standardwert ist CookieIDName="h"; wenn es jedoch einen Überschreibungswert in der Konfiguration der erweiterten Einstellungen des virtuellen Servers gibt, verwenden Sie stattdessen diesen. HINWEIS: Wenn dieser Wert gesetzt ist, überschreiben wir den obigen Cookie-Ausdruck, um h= durch den neuen Wert zu ersetzen.
Der letzte Punkt ist, dass, wenn ein unbekannter Cookie-Wert ankommt und mit einer der Realserver-IDs
übereinstimmt, dieser Server ausgewählt werden soll; andernfalls wird die nächste Methode (delegieren.) verwendet.
|
|
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. Es ist ein Weg, um unzuverlässige oder Legacy-Systeme zu hosten, die nicht primär für den H/A-Betrieb sind. Verwenden Sie diese Überwachungsmethode mit jedem Diensttyp.
|
|
Ping/ICMP-Echo
|
In diesem Modus sendet der ADC eine ICMP-Echo-Anfrage an die IP des Content-Servers. Wenn eine gültige Echo-Antwort empfangen wird, betrachtet der 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 ist mit jedem Diensttyp verwendbar.
|
|
TCP-Verbindung
|
In diesem Modus wird eine TCP-Verbindung zum Real-Server aufgebaut und sofort wieder abgebaut, ohne Daten zu senden. Wenn die Verbindung erfolgreich ist, hält die ADC den Real Server für betriebsbereit. Diese Überwachungsmethode ist mit jedem Diensttyp verwendbar. Nur UDP-Dienste sind derzeit nicht für die TCP-Verbindungsüberwachung geeignet.
|
|
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 initialisiert, wie in der Methode ICMP Unreachable beschrieben. Nachdem die Verbindung initialisiert wurde, wird eine Layer-7-RDP-Verbindung angefordert. Wenn die Verbindung bestätigt wird, stuft das ADC den Real Server als betriebsbereit ein. Diese Überwachungsmethode ist mit jedem Microsoft-Terminalserver verwendbar.
|
|
200 OK
|
Bei dieser Methode wird eine TCP-Verbindung zum Real-Server initialisiert. Nachdem die Verbindung erfolgreich war, sendet der ADC eine HTTP-Anfrage an den Real-Server. Es wird auf eine HTTP-Antwort gewartet und auf den Antwortcode "200 OK" geprüft. Wenn der Antwortcode "200 OK" empfangen wird, betrachtet die ADC den Real Server als funktionsfähig. Wenn die ADC aus irgendeinem Grund keinen "200 OK"-Antwortcode empfängt, einschließlich Timeouts, Verbindungsfehler 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 ein Layer 4-Diensttyp für einen HTTP-Server verwendet wird, ist er verwendbar, wenn SSL auf dem Real-Server nicht verwendet wird oder durch die "Content SSL"-Funktion entsprechend behandelt wird.
|
|
DICOM
|
Eine TCP-Verbindung wird zum Real-Server im DICOM-Modus initialisiert, und bei der Verbindung wird eine Echoscu-"Associate Request" 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 aus irgendeinem Grund nicht erfolgreich abgeschlossen werden kann, wird der Real-Server als ausgefallen betrachtet.
|
|
Benutzerdefiniert
|
Jeder Monitor, der im Abschnitt Realserver-Überwachung konfiguriert wurde, wird in der Liste angezeigt.
|
|
Option
|
Beschreibung
|
|
Nach Host
|
Das Caching pro Host basiert auf der Anwendung pro Hostname. Für jede Domäne/jeden Hostnamen existiert ein eigener Cache. Dieser Modus ist ideal für Webserver, die je nach Domain mehrere Websites bedienen können.
|
|
Durch virtuellen Service
|
Caching pro virtuellem Dienst ist verfügbar, wenn Sie diese Option wählen. Es gibt nur einen Cache für alle Domänen/Hostnamen, die den virtuellen Dienst durchlaufen. Diese Option ist eine spezielle Einstellung für die Verwendung mit mehreren Klonen einer einzelnen Site.
|
|
Option
|
Beschreibung
|
|
Aus
|
Komprimierung für den virtuellen Dienst ausschalten
|
|
Komprimierung
|
Wenn diese Option aktiviert ist, schaltet sie die Komprimierung für den ausgewählten virtuellen Dienst ein. Das ADC komprimiert den Datenstrom zum Client auf Anforderung dynamisch. Dieser Vorgang gilt nur für Objekte, die den Header content-encoding: gzip enthalten. Beispielinhalte sind HTML, CSS oder Javascript. Sie können auch bestimmte Inhaltstypen über den Abschnitt "Globale Ausschlüsse" ausschließen.
|
|
Option
|
Beschreibung
|
|
Kein SSL
|
Der Verkehr von der Quelle zum ADC wird nicht verschlüsselt.
|
|
Standard
|
Diese Option führt dazu, dass ein lokal erstelltes Zertifikat mit dem Namen "Standard" auf die Browserseite des Kanals angewendet wird. Verwenden Sie diese Option, um SSL zu testen, wenn noch keines erstellt oder importiert wurde.
|
|
Vom Benutzer importierte SSL-Zertifikate
|
Alle Zertifikate, die Sie in den ADC importiert haben, werden hier angezeigt.
|
|
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" clientseitig gewählt werden kann, um einen so genannten "SSL Offload" zu ermöglichen.
|
|
Beliebig
|
Der ADC fungiert als Client und akzeptiert jedes Zertifikat, das der Real Server vorlegt. Der Verkehr vom ADC zum Real Server wird verschlüsselt, wenn diese Option ausgewählt ist. Verwenden Sie die Option "Any", wenn auf der Seite des virtuellen Dienstes ein Zertifikat angegeben ist, wodurch eine sogenannte "SSL-Überbrückung" oder "SSL-Wiederverschlüsselung" bereitgestellt wird.
|
|
SNI
|
Der ADC agiert als Client und akzeptiert jedes Zertifikat, das der Real Server vorlegt. Der Verkehr vom ADC zum Real Server wird verschlüsselt, wenn diese Option ausgewählt ist. Verwenden Sie die Option "Any", wenn auf der Seite des virtuellen Dienstes ein Zertifikat angegeben ist, das eine so genannte "SSL-Überbrückung" oder "SSL-Neuverschlüsselung" bietet. Wählen Sie diese Option, um SNI auf der Serverseite zu aktivieren.
|
|
Vom Benutzer importierte SSL-Zertifikate
|
Hier erscheinen alle Zertifikate, die Sie in den ADC importiert haben.
|
|
Option
|
Beschreibung
|
|
Umgekehrter Proxy
|
Reverse Proxy ist der Standardwert und arbeitet auf Layer7 mit Komprimierung und Caching. Und auf Layer4 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 Server-Rückgabe
|
Direct Server Return oder DSR, wie es weithin bekannt ist (DR - Direct Routing in einigen Kreisen), ermöglicht es dem Server hinter dem Load Balancer, direkt auf den Client zu antworten, indem er den ADC bei der Antwort umgeht. DSR ist nur für den Einsatz mit Layer 4-Lastverteilung geeignet. Daher sind Caching und Komprimierung bei dieser Option nicht verfügbar.
Der Schicht-7-Lastausgleich funktioniert nicht mit diesem DSR. Außerdem gibt es keine andere Persistenzunterstützung als IP-Listen-basiert. Der SSL/TLS-Lastausgleich mit dieser Methode ist nicht ideal, da die Unterstützung der Quell-IP-Persistenz der einzige verfügbare Typ ist. DSR erfordert auch Änderungen am Realserver, die durchgeführt werden müssen. Bitte lesen Sie den Abschnitt Änderungen am realen Server.
|
|
Gateway
|
Im Gateway-Modus können Sie den gesamten Datenverkehr über den ADC leiten, so dass der Datenverkehr von den Real Servern über den ADC zu anderen Netzwerken über die virtuellen ADC-Maschinen oder Hardware-Schnittstellen geleitet werden kann. Die Verwendung des Geräts als Gateway-Gerät für Real Server ist ideal, wenn es im Multi-Interface-Modus betrieben wird.
Der Layer-7-Lastausgleich mit dieser Methode funktioniert nicht, da es keine Unterstützung für die Persistenz gibt, die nicht auf IP-Listen basiert. Diese Methode erfordert, dass der Real Server sein Standardgateway auf die lokale Schnittstellenadresse (eth0, eth1 usw.) des ADCs setzt. Lesen Sie dazu den Abschnitt Real Server Changes.
|
