Globale Einstellungen #

Das HTTP-Profil übernimmt die Inhaltsumschaltung auf der Anwendungsebene des OSI-Modells für HTTP- und HTTPS-Protokolle. Dieses Profil ist darauf ausgelegt, eingehenden Webdatenverkehr intelligent auf mehrere Backend-Ressourcen zu verteilen, indem es den Inhalt eingehender Anfragen analysiert und Routing-Entscheidungen auf der Grundlage von Parametern wie URL, Cookies, Headern und Sitzungsinformationen trifft. Anhand dieser Informationen wird der Datenverkehr an die entsprechenden Serverpools weitergeleitet.

Im oberen rechten Bereich haben wir zwei Indikatoren. Aktion Tasten und die Status.
Quatratische Kiste: Wenn Sie darauf klicken, wird die LSLB-Farm gestoppt.
Aktualisieren Sie die Schaltfläche: Wenn Sie darauf klicken, wird die Farm neu gestartet.
Play-Taste: Wenn die Farm ausgeschaltet oder inaktiv ist, wird sie beim Klicken gestartet.

Jede der unten beschriebenen Farben repräsentiert die Status eines gegebenen Farm:
Grün: Bedeutet, dass die Farm UP und alle Backends laufen. Es könnte auch bedeuten, dass eine Umleitung konfiguriert ist.
Rot: Bedeutet, dass die Farm AB oder es ist nicht funktionsfähig.
Schwarz: Zeigt eine KRITISCH Schaden. Tritt normalerweise auf, wenn eine Farm aktiv ist, aber kein Backend verfügbar ist oder sie sich im Wartungsmodus befindet.
Blau: Wird angezeigt, wenn ein AUFGABENSTELLUNG. Die Farm könnte ausgeführt werden, aber mindestens ein Backend ist ausgefallen.
Orange: Repräsentiert WARTUNG. Wird angezeigt, wenn die Farm ausgeführt wird, sich aber mindestens ein Backend im Wartungsmodus befindet.

Diese Farbcodes sind in der gesamten grafischen Benutzeroberfläche einheitlich. Eine kurze Erklärung finden Sie im LSLB-Farmabschnitt.

Im HTTP(S)-Farmprofil der HTTP-Header X-Forwarded-For- wird automatisch mit der Client-IP-Adresse gefüllt.

Als Reverse-Proxy verwaltet jede HTTP(S)-Farm (oder jeder virtuelle Dienst) mehrere Dienste. Das bedeutet, dass ein virtuelles HTTP-IP- und Port-Paar mehr als einen lastenausgeglichenen Webdienst verarbeiten kann. Daher gibt es innerhalb der HTTP-Farm eine Abschnitt, der virtuelle Hostflexibilität bietet und die Erstellung von Backend-Listen für jeden Dienst ermöglicht.

Jeder HTTP(S)-Dienst verwendet reguläre Ausdrücke verwenden (für virtuelle Hosts und URL-Muster) in PCRE, um bestimmte Muster in den HTTP-Headern eingehender Verbindungen zu identifizieren. Wenn ein Muster sowohl in den virtueller Host und URL-Muster Felder, die Backends für diesen bestimmten Dienst verarbeiten diese eingehenden Verbindungen.

Grundlegende Konfiguration #

Im Folgenden sind die grundlegenden Parameter für das HTTP/S-Farmprofil aufgeführt.

Name. Dies ist ein Name, der eine Farm leicht identifiziert. Um den Namen einer bestimmten Farm zu ändern, müssen Sie sie zuerst stoppen. Stellen Sie sicher, dass der neue Name nicht bereits verwendet wird.

Virtuelle IP und Port. Dies sind die virtuellen IP-Adressen und Portpaare, von denen die Farm auf eingehende Verbindungen wartet. Die neue Kombination aus IP-Adresse und Port muss vor der Konfiguration unbenutzt und verfügbar sein.

Hörer. Dieses Feld gibt das Layer-7-Protokoll für die Inhaltsumschaltung an.

• HTTP. Der virtuelle Dienst empfängt nur einfachen HTTP-Inhalt.
• HTTPS. Der virtuelle Dienst empfängt sichere HTTP-Inhalte, verwaltet SSL-Handshakes, verarbeitet sichere Verschlüsselungskonfigurationen, SSL-Zertifikate (Wildcard oder SNI) usw., um SSL-Offloading durchzuführen. Dadurch werden die realen Anwendungsserver von diesen schweren Aufgaben entlastet.

HTTPS-Parameter #

HTTPS-Parameter Nachfolgend finden.

SSLv2 deaktivieren, SSLv3 deaktivieren, TLSv1 deaktivieren, TLSv1.1 deaktivieren, TLSv1.2 deaktivieren. Jeder dieser Umschaltflächen aktiviert oder deaktiviert die zugehörige SSL- oder TLS-Version. Das Deaktivieren eines der Protokolle wird nicht empfohlen, da die zugehörigen Chiffren ebenfalls deaktiviert werden. TLSv1.3 ist standardmäßig aktiviert.

Ziffern. In diesem Abschnitt erstellen wir Listen mit Chiffren, die wir zur Stärkung einer SSL-Verbindung verwenden. Bevor ein Client und ein Server beginnen, durch das TLS-Protokoll geschützte Informationen auszutauschen, müssen sie einen Verschlüsselungsschlüssel und eine Chiffre, die beim Verschlüsseln von Daten verwendet werden soll, sicher austauschen oder sich darauf einigen.

Um eine zu verwendende Verschlüsselung zu konfigurieren, wählen Sie eine der folgenden Optionen aus.

• Alle. Wenn dieser Befehl ausgewählt ist, verwaltet die lauschende HTTP(S)-Farm alle verfügbaren Cipher Suites. Dies ist die Standardeinstellung.
• Hohe SicherheitDieser Befehl aktiviert die folgenden Chiffren:

kEECDH+ECDSA+AES128:kEECDH+ECDSA+AES256:kEECDH+AES128:kEECDH+AES256:kEDH+AES128:kEDH+AES256:DES-CBC3-SHA:+SHA:!aNULL:!eNULL:!LOW:!kECDH:!DSS:!MD5:!EXP:!PSK:!SRP:!CAMELLIA:!SEED

Das Aktivieren dieser Option bietet Sicherheit, die stark genug ist, um mit einem A+ Note in SSL Labs .

• Kundenspezifische SicherheitMit diesem Befehl können Sie Ihre eigenen Chiffren anpassen, indem Sie Benutzerdefinierte Chiffren Feld.
• Benutzerdefinierte ChiffrenMit diesem Befehl können Sie bestimmte Chiffren anpassen, die beim Herstellen einer SSL-Verbindung zugelassen oder verboten werden sollen. Es muss sich um eine Zeichenfolge im gleichen Format wie in OpenSSL-Chiffren Dieser Befehl wird angezeigt, wenn Kundenspezifische Sicherheit wird gesetzt.
• AES SSL HW-Offloading. Diese Option ermöglicht das Auslagern der AES-Chiffren über die Hardware, wenn der Prozessor dies zulässt. Aes Flag. Dadurch kann die Leistung der SSL-Verschlüsselungs-/Entschlüsselungsaufgabe optimiert werden. Testen Sie, ob diese Option mit Ihrer aktuellen CPU kompatibel ist, indem Sie den folgenden Befehl ausführen. Wenn die CPU-Flags angezeigt werden, kann sie verwendet werden.

root@noid-ee-02:~# grep "flags.* aes" /proc/cpuinfo

Verfügbare Zertifikate: Dies sind die auf dem Gerät installierten SSL-Zertifikate. Um ein Zertifikat zu aktivieren, wählen Sie es aus und klicken Sie auf die Pfeilschaltfläche oder ziehen Sie es per Drag & Drop aus dem Feld „Verfügbar“ in das Feld „Aktiviert“. Sie können auch mehrere oder alle Zertifikate aktivieren/deaktivieren.

Aktivierte Zertifikate: In dieser Liste werden die Zertifikate angezeigt, die derzeit von der Farm verwendet werden. Sie können sie mit den doppelten Auf-/Ab-Pfeilen nach oben oder unten verschieben oder alle deaktivieren. Beachten Sie die Reihenfolge der Zertifikate. Wenn ein Platzhalterzertifikat vor einem Hostzertifikat platziert wird, wird der Platzhalter zuerst verwendet.

Erweiterte Einstellungen #

Standortheader neu schreiben. Wenn aktiviert, muss die Farm die Header „Location“ und „Content-location“ als Antwort auf die Clients ändern. Wenn sie den Wert des Backends selbst oder des VIP haben, aber mit einem anderen Protokoll, wird die Antwort geändert, um den virtuellen Host in der Anfrage anzuzeigen. Wenn der Umschaltknopf „Aktiviert“ und „Backends vergleichen“ aktiviert ist, wird nur die Backend-IP-Adresse verglichen. Dies ist wichtig, um eine Anfrage an einen HTTPS-Listener auf demselben Server wie den HTTP-Listener umzuleiten. Wenn dieses Feld im Serviceabschnitt konfiguriert ist, wird diese Anweisung für diesen Service ignoriert.

Akzeptierte HTTP-Verben: Dieses Feld gibt die HTTP-Methoden an, die zum Validieren von HTTP-Clientanforderungen verwendet werden. Wenn die Anforderung eines Clients eine nicht unterstützte Methode verwendet, wird eine Fehlermeldung angezeigt. Jedes Verb umfasst auch zusätzliche Methoden auf niedrigerer Ebene.

• Standard-HTTP-Anforderung. Standard-HTTP-Anfragen (GET, POST, HEAD).
• + erweiterte HTTP-Anfrage. erweiterte HTTP-Anfragen (PUT, DELETE).
• + Optionen HTTP-Verb. erweiterte HTTP-Anfragen (PUT, DELETE).
• + Standard-WebDAV-Verben. Standard-WebDAV-Verben (LOCK, UNLOCK, PROPFIND, PROPPATCH, SEARCH, MKCOL, MOVE, COPY, OPTIONS, TRACE, MKACTIVITY, CHECKOUT, MERGE, REPORT).
• + MS-Erweiterungen WebDAV-Verben. MS-Erweiterungen WebDAV-Verben (SUBSCRIBE, UNSUBSCRIBE, NOTIFY, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
• + MS RPC-Erweiterungsverben. MS RPC-Erweiterungsverben (RPC_IN_DATA, RPC_OUT_DATA).

Ignorieren 100 Weiter: Wenn aktiviert, 100 Weiter Funktion wird deaktiviert. Gemäß dem HTTP 1.1-Protokoll signalisiert dieser Header, dass die Formulardaten nicht mit der ersten Anfrage gesendet werden sollen. Stattdessen sendet er den Header an das Backend des Webservers, das mit 100 (Continue) antwortet. Dies zeigt an, dass der Server die Anfrage-Header erhalten hat und der Client mit dem Senden des Anfragetexts fortfahren soll (z. B. in einer POST-Anfrage). Diese Funktion soll eine ineffiziente Datenübertragung verhindern, indem sichergestellt wird, dass der Server prüft, ob die Anfrage allein anhand der Header akzeptiert werden kann. Clients müssen senden Erwartet: 100-weiter als Header und warten Sie auf einen 100-Continue-Statuscode, bevor Sie fortfahren, oder auf einen 417-Expectation Failed, wenn die Anforderung abgelehnt wird.

Logs: Aktivieren oder deaktivieren Sie Farmverkehrsprotokolle, um den Datenverkehr, der durch den Load Balancer läuft, zu debuggen und zu analysieren.

Timeout der Backend-Verbindung: Dieser Wert legt die Zeit in Sekunden fest, die die Farm auf eine Verbindung zum Backend wartet. Normalerweise ist dies die Wartezeit zum Öffnen des Sockets. Der Standardwert beträgt 20 Sekunden.

Häufigkeit der Überprüfung wiederauferstandener Backends: Diese Einstellung bestimmt, wie oft der Load Balancer prüft, ob ein zuvor auf die schwarze Liste gesetztes Backend erreichbar ist, und es von der schwarzen Liste entfernt, wenn es aktiv ist. Die Farm prüft das Backend regelmäßig, sobald es als inaktiv markiert ist, unabhängig von neuen Clientverbindungen. Der Standardwert beträgt 10 Sekunden.

Backend-Antwort-Timeout: Dieser Wert legt die Zeit in Sekunden fest, die die Farm auf eine Antwort von den Backends wartet. Der Standardwert beträgt 45 Sekunden.

Clientanforderungs-Timeout: Dieser Wert legt die Zeit fest, die die Farm auf eine Client-Anforderung wartet. Wenn innerhalb dieser Zeitspanne keine Daten empfangen werden, wird die Verbindung beendet. Der Standardwert beträgt 30 Sekunden.

HTTP-Fehlermeldungen #

Der Farmdienst zeigt benutzerdefinierte Nachrichten auf Ihrer Site an, wenn bestimmte Webcodefehler von den realen Servern erkannt werden. Für die Fehlercodes 414, 500, 501, 503 und WAF 403 werden personalisierte HTML-Seiten angezeigt.

• 414: Anforderungs-URI zu lang. Dieser Fehler tritt auf, wenn die URI die maximal zulässige Länge überschreitet. Wenn Sie diesen Fehler erhalten, kürzen Sie die Länge der URL.
• 500: Interner Serverfehler. Dieser Fehler zeigt an, dass das Backend auf einen unerwarteten Befehl gestoßen ist.
• 501: Nicht implementiert. Dieser Fehler tritt auf, wenn das Anforderungsverb vom Proxy oder Backend nicht erkannt oder verwaltet wird.
• 503 Dienst nicht verfügbar. Dieser Fehler zeigt an, dass der Proxy kein verfügbares Backend für die Anfrage finden konnte. Dies kann passieren, wenn alle Backends ausgefallen sind oder wenn der reguläre Ausdruck der Anfrage keinem konfigurierten Dienst entspricht.
• WAF 403: VerbotenDieser Fehler tritt auf, wenn die Web Application Firewall (WAF) aktiviert ist und die WAF-Engine die Anforderung ablehnt.

Headers #

In diesem Abschnitt können Sie Anforderungs- und Antwortheader global hinzufügen oder löschen und diese Aktionen auf alle konfigurierten Dienste anwenden. Wenn im Dienstabschnitt ein Header konfiguriert ist, wird diese spezifische Konfiguration überschrieben.

Zu den in diesem Abschnitt zu verwendenden Aktionen gehören:

Regel erstellen. Eine globale Header-Regel wird erstellt.
LöschenEine globale Header-Regel wird gelöscht.

In diesem Abschnitt können Sie hinzufügen oder erstellen Kopfzeile Anfragen und Antworten, wie in der Abbildung unten dargestellt.

Typ.

• Anforderung: Header entfernen. Entfernt das angegebene Header-Muster aus den HTTP-Anfragen des Clients.
• Anfrage: Header hinzufügen. Fügt den angegebenen Header zu den HTTP-Anfragen des Clients hinzu.
• Antwort: Header entfernen. Entfernt das angegebene Header-Muster aus den Backend-HTTP-Antworten.
• Antwort: Header hinzufügen. Fügt den angegebenen Header zu den HTTP-Antworten des Backends hinzu.

Kopfzeile. Geben Sie die Kopfzeile an, die hinzugefügt oder entfernt werden soll.
Wert. Geben Sie bei Bedarf den Wert des angegebenen Headers an.

Diensteinstellungen #

Die Dienste innerhalb einer LSLB-Farm, die ein HTTP-Profil verwenden, ermöglichen Content-Switching für virtuelle Webdienste und konsolidieren mehrere Webanwendungen unter dem gleiche virtuelle IP und PORT. Dieses Setup erleichtert Zentralisierte Verwaltung von Webanwendungen, virtuelle Hostkonfigurationen, URL-Verwaltung, Umleitungs-Setups und Persistenz und Backend-Konfigurationen pro Dienst. Jeder Dienst in einer LSLB-Farm enthält Eigenschaften für Integritätsprüfungen, Persistenz, Header-Verwaltung und eine Backend-Liste. Reguläre Ausdrücke können angewendet werden, um Bedingungen zu erfüllen, die bestimmen, welcher Dienst jede Anfrage verarbeitet.

Das HTTP-Farmprofil wertet Service-Übereinstimmungsbedingungen im Prioritätsmodus aus (nach Bedarf änderbar). Wenn kein Service übereinstimmt, gibt die Farm einen HTTP-Fehler 503 zurück. Daher wird das Definieren mehrerer Services mit bestimmten Bedingungen unterstützt. Anfragen stimmen mit Services basierend auf virtuellen Host- und/oder URL-Mustern überein.

Es ist wichtig, zuerst mindestens einen Backend-Server zu erstellen und zu einem Dienst hinzuzufügen. Nach dem Anwenden des neuen Dienstes werden HTTP-Dienste in der Listenreihenfolge nacheinander von oben nach unten ausgewertet. Der erste Dienst, der in den Feldern Host und/oder URL übereinstimmt, verarbeitet die eingehende Anfrage basierend auf konfigurierten URL- oder Host-Mustern.

Die Bedingungen, die erfüllt sein müssen, sind:

Virtueller Host. Mit dieser Funktion können Sie eine Bedingung basierend auf dem Domänennamen definieren, der dieselbe virtuelle IP und denselben Port innerhalb einer HTTP-Farm verwendet. Wenn Sie diese Bedingung entfernen möchten, können Sie das Feld leer lassen. Reguläre Ausdrücke in PCRE Format werden in diesem Feld unterstützt.

URL-Muster. Der Zweck dieses Feldes besteht darin, einen Webdienst anhand des vom Client angeforderten URL-Pfads zu identifizieren. Die URL wird anhand eines festgelegten Musters ausgewertet, um sicherzustellen, dass ihre Syntax korrekt ist. Wenn Sie diese Bedingung ignorieren möchten, können Sie das Feld leer lassen. Reguläre Ausdrücke in PCRE In diesem Feld werden Formate unterstützt, die eine erweiterte Musterübereinstimmung ermöglichen.

Die Virtueller Host und URL-Muster Werte sind reguläre Ausdrücke. Wenn sie leer gelassen werden, stimmt jeder Wert überein. Beide Felder müssen übereinstimmen, sonst wird zum nächsten Dienst übergegangen. Es wird empfohlen, mindestens eines zu verwenden, das als Standard dient, wenn unten keine Übereinstimmung erkannt wird.

Lastenausgleichsplaner. Dieses Feld gibt den Algorithmus an, der zum Verteilen der Last auf die Backend-Server verwendet wird. Der standardmäßig ausgewählte Algorithmus ist gewichtsbasiert.

• Gewicht: Verbindung linearer Versand nach Gewicht. Verteilt Verbindungen basierend auf zugewiesenen Gewichten an jedes Backend. Anfragen werden wahrscheinlichkeitsbasiert entsprechend den definierten Gewichten übermittelt.
• Geringste Antwort: dynamisches Gewicht entsprechend der Backend-Antwort. Passt Backend-Gewichte dynamisch basierend auf ihren Antwortzeiten an. Schnellere Antworten erhöhen die Wahrscheinlichkeit, dass Verbindungen an diese Server weitergeleitet werden.

Umleiten #

Wenn für den Dienst die Umleitungsoption aktiviert ist, werden möglicherweise keine Backend-Server verwendet, da alle Anforderungen an die angegebene URL gesendet werden.

UmleitungstypEs gibt zwei Arten von Weiterleitungen:

• Standard: Nimmt die URL als absoluten Host und Pfad für die Weiterleitung.
• Anhängen: Fügt den ursprünglichen Anforderungspfad an den angegebenen Host und Pfad an.

URL umleiten. Gibt an, wohin der Client nach dem Empfang einer Antwort umgeleitet werden soll. Wenn ein Umleitungswert konfiguriert ist, können Sie für diesen Dienst keine Backends konfigurieren. Wenn sowohl der virtuelle Host als auch das URL-Muster übereinstimmen, sendet das Gerät eine HTTP-Standortheader Antwort, um den Client zur konfigurierten URL umzuleiten.

Umleitungscode. Gibt den HTTP-Statuscode für die Umleitung an:

• 301 (dauerhaft verschoben)
• 302 (vorübergehend verschoben)
• 307 (Temporäre Weiterleitung)

Beharrlichkeit #

Dieser Parameter definiert, wie der HTTP-Dienst Clientsitzungen verwaltet und steuert, welche HTTP-Verbindungen aufrechterhalten werden, um stabile Clientsitzungen sicherzustellen. Sobald ein Typ von Persistenzsitzung ausgewählt ist, wird seine Time To Live (TTL) in Sekunden angezeigt.

Keine Beharrlichkeit. Mit dieser Option können HTTP- oder HTTPS-Anfragen an echte Server übermittelt werden, ohne dass Client-Sitzungen verwaltet werden müssen.
IP: Client-Adresse. Diese Option verwendet die IP-Adresse des Clients, um offene Clientsitzungen über reale Server hinweg aufrechtzuerhalten.
BASIC: Basisauthentifizierung. Diese Option verwendet den HTTP-Header für die Basisauthentifizierung, um Clientsitzungen zu steuern. Wenn eine Webseite beispielsweise eine Basisauthentifizierung vom Client erfordert, enthält ein HTTP-Header eine Zeichenfolge wie die folgende:

		HTTP/1.1 401 Autorisierung erforderlich Server: HTTPd/1.0 Datum: Samstag, 27. November 2011, 10:18:15 GMT
		WWW-Authentifizierung: Basic realm="Sicherer Bereich"
		Inhaltstyp: Text/HTML Inhaltslänge: 31

Dann antwortet der Client mit dem Header:

                GET /private/index.html HTTP/1.1 Host: localhost
		Autorisierung: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Diese grundlegende Authentifizierungszeichenfolge wird als Sitzungs-ID verwendet, um die Clientsitzung zu identifizieren.
PARM: Ein URI-ParameterEine andere Möglichkeit, eine Client-Sitzung zu identifizieren, ist ein URI-Parameter, der durch ein Semikolon getrennt ist und als Benutzersitzungskennung verwendet wird. Im Beispiel http://www.example.com/private.php;EFD4Y7 Der Parameter wird als Sitzungskennung verwendet.
URL: Ein Anforderungsparameter. Wenn die Sitzungs-ID über einen GET-Parameter mit der URL gesendet wird, gibt dieser Parameter an, dass der mit der Client-Sitzungs-ID verknüpfte Name möglich ist. Beispielsweise eine Client-Anforderung wie http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 sollte mit dem Parameter konfiguriert werden Persistenzsitzungskennung (Sid-Wert in diesem Beispiel) und die Lebensdauer der Persistenzsitzung (TTL)
PLÄTZCHEN: . Sie können eine HTTP-Cookie-Variable auswählen, die aus den HTTP-Headern gelesen wird, und diese verwenden, um Clientsitzungen für eine bestimmte Zeit aufrechtzuerhalten. Der konfigurierte Cookiename im Persistenzsitzungskennung Das Feld wird von einem Programmierer erstellt und in eine Webseite eingebettet, um die Client-Sitzung zu identifizieren, zum Beispiel:

                GET /spec.html HTTP/1.1 Host: www.example.org
                Cookie: sessionidexample=75HRSd4356SDBfrte

Zusätzlich sollte die Persistence Session Time To Life (TTL) konfiguriert werden. Dieser Wert verwaltet die Zeit, die der Load Balancer speichert, wenn der Client und das Backend inaktiv sind.
HEADER: ein Anforderungsheader. Ein benutzerdefiniertes HTTP-Headerfeld kann zur Identifizierung der Clientsitzung verwendet werden. Die Lebensdauer der Persistenzsitzung und die Persistenzsitzungskennung müssen konfiguriert werden. Beispiel:

               GET /index.html HTTP/1.1 Host: www.example.org
               X-Sitzung: 75HRSd4356SDBfrte

Cookie-Einsatz #

Wenn konfiguriert, generiert der Load Balancer eine Plätzchen in jeder Antwort mit dem entsprechenden Backend-Schlüssel. Dadurch wird sichergestellt, dass auch dann das richtige Backend ausgewählt wird, wenn die Sitzungstabelle gelöscht oder Sitzungen deaktiviert werden. Mit dieser Funktion ist es nicht mehr erforderlich, den eigentlichen Servercode zu ändern, um ein Sitzungscookie zu erstellen.

Die Cookie Name gibt den Namen des Cookies an, der erstellt und in die Client-Anforderung oder Backend-Antwort eingefügt wird. Der Cookie-Pfad definiert die URI oder den relativen Pfad, in dem das neue Cookie erstellt wird. Um das Cookie auf die gesamte Domäne anzuwenden, legen Sie dieses Feld entsprechend fest. Das Cookie Domain gibt die Domäne an, in der das Cookie gesetzt wird. Schließlich ist die Gültigkeitsbereich des Cookies gibt die Anzahl der Sekunden an, die das Cookie zwischen Client und Backend aktiv bleibt. Dieser Wert muss 0 überschreiten und bezieht sich auf die Dauer ohne Aktivität. Sobald die angegebene Zeit ohne Aktivität verstreicht, läuft die mit dem Cookie verknüpfte Persistenzsitzung ab.

Bauernwächter #

HTTP-Farmen stellen eine grundlegende und native Backend-Integritätsprüfung bereit, allerdings wird die Farmguardian-Konfiguration für intelligentere heuristische Backend-Integritätsprüfungen empfohlen, um sicherzustellen, dass die Anwendung fehlerfrei ist.

Aus den bereits erstellten Farmguardian-Prüfungen können diesem Dienst einige integrierte oder angepasste erweiterte Integritätsprüfungen zugewiesen werden.

Weitere Informationen zu Farmguardian finden Sie unter Überwachung > Farmguardian .

Beachten Sie, dass der Farmguardian nach der Auswahl automatisch auf die Farm angewendet wird.

HTTPS-Backends. Dieses Kontrollkästchen zeigt der Farm an, dass die im aktuellen Dienst definierten Backend-Server das HTTPS-Protokoll verwenden, sodass die Daten vor dem Senden verschlüsselt werden.

Backends #

Bezüglich der Backends, das HTTP-Farmprofil ermöglicht die Konfiguration der folgenden Eigenschaften: Alle Backends müssen IPv4 oder IPv6 sein und dieselbe IP-Version wie die Farm-VIP haben.

Backend hinzufügen #

Durch die Aktion Menüschaltfläche stehen folgende Aktionen für ein oder mehrere ausgewählte Backends zur Verfügung:
Backend hinzufügen. Dieser Befehl öffnet das Backend-Erstellungsformular.
Die oben genannten Aktionen: Wartung aktivieren (Abtropfen und Schneiden Modus), Wartung deaktivieren und Löschen.

Backend-Liste #

AktionVerwenden Sie die folgenden Aktionen, um die Backends zu verwalten:

• Wartung aktivieren. Verwenden Sie diese Aktion, wenn das Backend zuvor deaktiviert wurde. Wenn Sie einen realen Server in den Wartungsmodus versetzen, werden keine neuen Verbindungen zu ihm umgeleitet. Es gibt zwei Methoden, um den Wartungsmodus zu aktivieren:
  • Entleeren Sie Modus. Behält bestehende Verbindungen und Persistenz bei, falls aktiviert, lässt aber keine neuen Verbindungen zu.
  • Schnittmodus. Beendet alle aktiven Verbindungen zum Backend
• Wartung deaktivieren. Verwenden Sie diese Aktion, wenn sich das Backend im Wartungsmodus befindet. Aktivieren Sie nach dem Deaktivieren des Wartungsmodus wieder neue Verbindungen zum realen Server.
• Löschen. Entfernt Konfigurationen eines ausgewählten virtuellen Dienstes. Der Alias ​​(falls vorhanden) wird nicht gelöscht.

Alias. Backend-Alias, sofern ein Alias ​​ausgewählt wurde.
IP. Die IP-Adresse eines bestimmten Backends.
Hafen. Die Portnummer des aktuellen realen Servers.
Timeout. Die Zeit, die ein Backend zum Antworten benötigt. Dieser Wert überschreibt den Parameter des globalen Backend-Verbindungstimeouts, ist aber auf diese ausgewählte Farm beschränkt.
Gewicht. Der Gewichtungswert für den aktuellen realen Server. Mehr Gewichtung bedeutet, dass mehr Verbindungen zum aktuellen Backend hergestellt werden. Standardmäßig wird ein Gewichtungswert von 1 festgelegt. Der verfügbare Wertebereich reicht von 1 bis 9.
Status. Die möglichen Werte sind:

• Up. Die Farm läuft und das Backend ist bereit, Verbindungen zu empfangen.
• Nach unten. Die Farm läuft und der Dienst hat festgestellt, dass das Backend nicht funktioniert
• Wartung. Das Backend wird vom Administrator als nicht bereit zum Empfangen von Verbindungen markiert. Diese Option ist für Wartungsaufgaben des Backends nützlich.
• Undefiniert. Der Backend-Status wurde nicht geprüft.

Priorität. Der Prioritätswert für den aktuellen realen Server. Niedrigere Werte haben eine höhere Priorität. Der Standardwert für die Dienstpriorität ist 1. Wenn ein Backend ausfällt, wird die Dienstpriorität um 1 erhöht. Wenn das Backend wieder aktiv ist, wird der Dienstprioritätswert um 1 verringert. Aktive Backends enthalten Prioritätswerte, die kleiner oder gleich der Dienstpriorität sind.

IPDS-Regeln für HTTP-Farmen #

In diesem Abschnitt können Sie IPDS-Regeln aktivieren. Die Liste zeigt verschiedene Schutzarten mit einem Auswahlfeld zum Aktivieren an. Weitere Informationen finden Sie in der spezifischen Dokumentation für IPDS > Blacklist-Regeln, IPDS > DoS-Regeln, IPDS > RBL-Regeln or IPDS > WAF-Regeln.

Für jeden der vier IPDS-Regeltypen (Blacklist, DoS, WAF und RBL) gibt es zwei Listen: Verfügbar und Nutzer der Smart‑Spaces‑App mit Google Wallet erhalten berührungslosen Mobile‑Zutritt an jedem NFC‑fähigen HID® Signo™‑Leser.. Ein Kettensymbol ist ebenfalls vorhanden. Im Verfügbar finden Sie Regeln desselben Typs, die auf eine bestimmte Farm angewendet werden können. In der Nutzer der Smart‑Spaces‑App mit Google Wallet erhalten berührungslosen Mobile‑Zutritt an jedem NFC‑fähigen HID® Signo™‑Leser. In der Liste werden die Regeln angezeigt, die derzeit auf die ausgewählte Farm angewendet werden und durch ihr Statussymbol gekennzeichnet sind: rot markiert für gestoppt und grün zum Laufen.

Jede Regel kann durch Klicken auf das Bearbeitungssymbol bearbeitet werden. Dadurch können Sie Regelparameter ändern oder die Regel starten/stoppen. Beachten Sie, dass in dieser Farmansicht keine neuen Regeln erstellt werden können und über das IPDS .

Um eine Regel hinzuzufügen, klicken Sie auf die gewünschte Regel und dann auf den rechten Einzelpfeil. Sie können auch mehrere Regeln auswählen, indem Sie die Umschalttaste gedrückt halten und die gewünschten Regeln auswählen, bevor Sie auf den rechten Einzelpfeil klicken. Um alle verfügbaren Blacklists hinzuzufügen, klicken Sie auf den rechten Doppelpfeil.

Um eine oder mehrere Regeln zu löschen, wählen Sie sie aus und klicken Sie auf den linken Pfeil oder klicken Sie auf den Doppelpfeil, um alle zu entfernen.