|
|||||||
|
|||||||
|
|
Feld
|
Beschreibung
|
|
IP-Adresse
|
Geben Sie eine neue virtuelle IP-Adresse ein, die als Zieleinstiegspunkt für den Zugriff auf den Realserver dienen soll. Diese IP-Adresse ist der Punkt, an dem Benutzer oder Anwendungen auf die Anwendung mit Lastausgleich zugreifen.
|
|
Teilnetzmaske/Präfix
|
Dieses Feld dient der Angabe der Subnetzmaske für das Netz, in dem sich die ADC befindet.
|
|
Hafen
|
Der Eingangsport, der beim Zugriff auf das VIP verwendet wird. Dieser Wert muss nicht notwendigerweise mit dem des Realen Servers übereinstimmen, wenn Sie Reverse Proxy verwenden.
|
|
Dienst Name
|
Der Name des Dienstes ist eine textliche Darstellung des Zwecks des VIPs. Er ist optional, wir empfehlen jedoch, ihn aus Gründen der Klarheit anzugeben.
|
|
Art der Dienstleistung
|
Es gibt viele verschiedene Diensttypen, die Sie auswählen können. Layer-4-Diensttypen können die flightPATH-Technologie nicht nutzen.
|
|
Feld
|
Beschreibung
|
|
Tätigkeit
|
Über das Feld Aktivität kann der Status des realen Servers mit Lastausgleich 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 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 dies ein anderer als der im VIP angegebene Eingangs-Port sein.
|
|
Gewichtung
|
Diese Einstellung wird normalerweise automatisch von der OEZA 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 Primär/Modus 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 manuelle Rolle ermöglicht es dem ADC-Paar, im Aktiv-Aktiv-Modus für verschiedene virtuelle IP-Adressen zu arbeiten. 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.
|
|
Eigenständig
|
Der ADC arbeitet 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 darauf zurückzuführen sein, dass ein Real Server eine Zustandsüberprüfung nicht bestanden hat oder manuell auf Offline gesetzt wurde. Der Datenverkehr fließt weiter, allerdings mit reduzierter Real Server Kapazität.
|
|
l
|
Offline. Inhaltsserver sind unerreichbar oder keine Inhaltsserver aktiviert
|
|
l
|
Status der Suche
|
|
l
|
Nicht lizenziert oder lizenzierte virtuelle IPs überschritten
|
|
Art der Dienstleistung
|
Anschluss/Protokoll
|
Dienst-Ebene
|
Kommentar
|
|
Schicht 4 TCP
|
Jeder TCP-Anschluss
|
Schicht 4
|
Die ADC ä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 ändert die ADC keine Informationen im Datenstrom und führt einen Standard-Lastausgleich des Datenverkehrs gemäß der Lastausgleichsrichtlinie durch.
|
|
Schicht 4 TCP/UDP
|
Jeder TCP- oder UDP-Port
|
Schicht 4
|
Es ist ideal, wenn Ihr Dienst ein primäres Protokoll wie UDP hat, aber auf TCP zurückgreift. Die ADC ändert keine Informationen im Datenstrom und führt einen Standard-Lastausgleich des Datenverkehrs gemäß der Lastausgleichsrichtlinie durch
|
|
DNS
|
TCP/UDP
|
Schicht 4
|
Wird zum Lastausgleich von DNS-Servern verwendet.
|
|
HTTP
|
HTTP- oder HTTPS-Protokoll
|
Schicht 7
|
Die ADC kann den Datenstrom mit flightPATH interagieren, manipulieren und verändern.
|
|
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 und ö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
|
Bereitschaft
|
|
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 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 die Entleerung läuft. Sobald die bestehenden Verbindungen auf natürliche Weise beendet sind, gehen die Real-Server offline, und die Statusanzeige leuchtet durchgehend blau. Sie können diese Verbindungen auch anzeigen, indem Sie zum Abschnitt Navigation > Monitor > Status navigieren.
|
|
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 Datenverkehr 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
|
|
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.
|
|
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-Web-Servern. 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.
|
|
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.
|
|
IP-Grenze
Schicht 3 Sitzungsaffinität/Persistenz
|
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, bei 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
Schicht 3 Sitzungsaffinität/Persistenz
|
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.
|
|
Sitzungs-Cookie
Schicht 7 Sitzungsaffinität/Persistenz
|
Dieser Modus ist die beliebteste Persistenzmethode für den HTTP-Lastausgleich. In diesem Modus verwendet die ADC den IP-Listen-basierten Lastausgleich für jede erste Anfrage. Sie 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 weiterzuleiten. Dieses Cookie wird für die Persistenz verwendet, wenn der Client jedes Mal zum selben Back-End-Server gehen muss. Das Cookie verfällt, sobald die Sitzung geschlossen 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.
|
|
Sitzungs-Cookie - 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.
|
|
Sitzungs-Cookie - 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.
|
|
Sitzungs-Cookie - 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.
|
|
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 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.
|
|
Sitzungs-Cookie - 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.
|
|
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 besteht darin, dass die Verbindung zu einem Server aufrechterhalten werden kann, auch 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, 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.
|
|
Gemeinsame IP-Liste basierend
|
Dieser Diensttyp ist nur verfügbar, wenn der Konnektivitätsmodus auf Gateway oder Direct Server Return eingestellt ist. Er wurde hauptsächlich zur Unterstützung des VMware-Lastausgleichs hinzugefügt.
|
|
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 Daten zu senden. Wenn die Verbindung erfolgreich ist, betrachtet die ADC den Real Server als betriebsbereit. Diese Überwachungsmethode kann mit jedem 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.
|
|
AnyUseCert
|
Jedes auf dem ADC vorhandene Zertifikat verwenden, das der Benutzer hochgeladen oder generiert hat
|
|
Option
|
Beschreibung
|
|
Kein SSL
|
Der Datenverkehr 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
|
Der ADC fungiert als Client und akzeptiert jedes vom Real Server vorgelegte Zertifikat. Der Datenverkehr vom ADC zum Realen Server wird verschlüsselt, wenn diese Option ausgewählt ist. Verwenden Sie die Option "Any", wenn ein Zertifikat auf der Seite des Virtuellen Dienstes angegeben ist, und bieten Sie damit das so genannte "SSL Bridging" oder "SSL Re-Encryption". Wählen Sie diese Option, um SNI auf der Serverseite zu aktivieren.
|
|
AnyUseCert
|
Hier erscheinen alle Zertifikate, die Sie erstellt oder in die ADC importiert haben.
|
|
Option
|
Beschreibung
|
|
Umgekehrter Proxy
|
Reverse Proxy ist der Standardwert und funktioniert auf Layer7 mit Komprimierung und Caching. Und auf Layer4 ohne Caching oder Kompression. 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, wie es weithin bekannt ist (DR - Direct Routing in einigen Kreisen), ermöglicht es dem Server hinter dem Load Balancer, direkt an 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 Option nicht verfügbar.
Dieser Modus kann nur mit den Diensttypen TCP, UDP und TCP/UDP verwendet werden.
Der Schicht-7-Lastausgleich funktioniert nicht mit diesem DSR. Außerdem gibt es keine andere Unterstützung für Persistenz 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 vorgenommen werden müssen. Bitte lesen Sie den Abschnitt Änderungen am Realserver.
|
|
Gateway
|
Im Gateway-Modus können Sie den gesamten Datenverkehr über den ADC leiten, so dass die Real Server über den ADC zu anderen Netzwerken über die virtuellen ADC-Maschinen oder Hardware-Schnittstellen geleitet 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.
Der Schicht-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 des ADC (eth0, eth1, etc.) setzt. Bitte lesen Sie den Abschnitt Real Server Änderungen.
Bitte beachten Sie, dass der Gateway-Modus keine Ausfallsicherung in einer Cluster-Umgebung unterstützt.
|
