|
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 werden, um auf die Anwendung mit Lastausgleich zuzugreifen.
|
|
Subnetz-Maske/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 des Realen Servers ü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.
|
|
Dienst-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
|
Das Feld Aktivität kann verwendet werden, um den Status des lastverteilten realen Servers anzuzeigen und zu ändern.
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, so dass die Persistenz geleert und der Server in einen Offline-Zustand versetzt werden kann, ohne dass die Benutzer davon betroffen sind.
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 im 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 den ADC bei der Installation, und die Spalte Primary/Mode zeigt den Modus an, in dem er 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
|
Die Rolle Manuell ermöglicht es, dass das ADC-Paar im Aktiv-Aktiv-Modus für verschiedene virtuelle IP-Adressen läuft. In solchen Fällen enthält die Spalte Primär ein Kästchen neben jeder einzelnen Virtuellen IP, das für Aktiv angekreuzt oder für 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, aber 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
|
|
Dienst-Typ
|
Port/Protokoll
|
Dienst-Schicht
|
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
|
|
DNS
|
!!!
|
|
|
|
HTTP
|
HTTP- oder HTTPS-Protokoll
|
Ebene 7
|
Der ADC kann den Datenstrom mit flightPATH interagieren, manipulieren und modifizieren.
|
|
FTP
|
Dateiübertragungsprotokoll Protokoll
|
Ebene 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 von Terminaldienste-Servern
|
|
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 Statischer 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 verbunden
|
|
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 Lastausgleichsrichtlinie, die auf der Registerkarte Basis eingestellt ist.
|
|
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 läuft. Sobald die bestehenden Verbindungen natürlich geschlossen sind, 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 vornehmen müssen; ein Beispiel dafür wären Lookup-Webserver. 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.
|
|
Layer 3 Session Affinity/Persistence - IP Bound
|
In diesem Modus bildet die IP-Adresse des Clients die Grundlage für die Auswahl des Real-Servers, der die Anfrage erhalten soll. 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 Last nicht gleichmäßig wäre. Bei HTTP wird die Header-Information (X-Forwarder-For) verwendet, wenn sie vorhanden ist, um mit Proxys 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 aufrechterhalten, aber dies kann mit einem jetPACK geändert werden.
|
|
Schicht 7 Session-Affinität/Persistenz - Session-Cookie
|
Dieser Modus ist die beliebteste 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 gleichen Back-End-Server gehen muss. Das Cookie läuft ab, sobald die Sitzung geschlossen wird.
|
|
Schicht 7 Sitzungsaffinität/Persistenz - Persistentes 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 gleichen 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 ausgewählt ist, behält das ADC die Sitzung 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 der kleinsten Verbindungen 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 Erkennung eines neuen ASP-Cookies wird ein Lastausgleich mit dem Algorithmus der kleinsten Verbindungen 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 Hilfe des Algorithmus der kleinsten Verbindungen 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 Sitzung auf demselben 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 Hilfe des Algorithmus der kleinsten Verbindungen 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 einer 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 Real-Servers 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 vom Realen Server (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 eintrifft und mit einer der Real-Server-IDs
übereinstimmt, dieser Server ausgewählt werden soll; andernfalls verwenden Sie die nächste Methode (delegieren.)
|
|
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 ältere 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 hergestellt und sofort wieder unterbrochen, 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, hält der ADC den Real Server für betriebsbereit. 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 hergestellt wurde, 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 betriebsbereit. 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 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 gehandhabt wird.
|
|
DICOM
|
Eine TCP-Verbindung zum Real-Server wird im DICOM-Modus initialisiert, und beim Verbindungsaufbau 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 Real-Server-Überwachung konfiguriert wurde, erscheint in der Liste.
|
|
Option
|
Beschreibung
|
|
Nach Host
|
Das Caching pro Host basiert auf der Anwendung pro Hostname. Für jede Domain/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 wird nur ein Cache für alle Domänen/Hostnamen existieren, die den virtuellen Dienst durchlaufen. Diese Option ist eine spezielle Einstellung für die Verwendung mit mehreren Klonen einer einzelnen Site.
|
|
Option
|
Beschreibung
|
|
Aus
|
Schalten Sie die Komprimierung für den virtuellen Dienst aus
|
|
Komprimierung
|
Wenn diese Option ausgewählt ist, schaltet sie die Komprimierung für den ausgewählten virtuellen Dienst ein. Das ADC komprimiert den Datenstrom zum Client auf Anfrage 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 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 keins erstellt oder importiert wurde.
|
|
AnyUseCert
|
Verwenden Sie ein auf dem ADC vorhandenes Zertifikat, das der Benutzer hochgeladen oder generiert hat
|
|
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 eine so genannte "SSL-Offload" zu ermöglichen.
|
|
Beliebig
|
Der ADC agiert als Client und akzeptiert jedes Zertifikat, das der Real-Server vorlegt. Der Datenverkehr vom ADC zum Real Server 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, 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 Datenverkehr vom ADC zum Real Server wird verschlüsselt, wenn dies ausgewählt ist. Verwenden Sie die Option "Beliebig", wenn ein Zertifikat auf der Seite des virtuellen Dienstes angegeben ist, wodurch eine so genannte "SSL-Überbrückung" oder "SSL-Neuverschlüsselung" bereitgestellt wird. Wählen Sie diese Option, um SNI auf der Server-Seite zu aktivieren.
|
|
AnyUseCert
|
Hier erscheinen alle Zertifikate, die Sie erzeugt oder 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 und 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-Lastausgleich geeignet. Daher sind Caching und Komprimierung bei dieser gewählten Option nicht verfügbar.
Der Layer-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 nur die Quell-IP-Persistenzunterstützung verfügbar ist. DSR erfordert auch Änderungen am Real Server. Bitte lesen Sie den Abschnitt Änderungen am Real-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 ADC-Virtual Machines 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 Persistenz gibt, außer IP-Listen-basiert. Diese Methode erfordert, dass der Real-Server sein Standard-Gateway auf die lokale Schnittstellenadresse (eth0, eth1, etc.) des ADCs setzt. Lesen Sie dazu den Abschnitt Real-Server-Änderungen.
Bitte beachten Sie, dass der Gateway-Modus keine Ausfallsicherung in einer Cluster-Umgebung unterstützt.
|
