Load Balancer/ADC ALB-X Testfahrt Tutorial

(ADC Application Delivery Controller)

Holen Sie sich hier Ihre Probefahrt

Wir wünschen Ihnen viel Spaß mit dem ALB-X Load Balancer und würden uns freuen, wenn Sie eine realistische Konfiguration zum Spielen hätten.

Im Rahmen dieser Testphase haben wir einige Beispieldienste vorkonfiguriert, damit Sie sofort loslegen können.
Wir hosten dieses Setup auf Azure, aber keine Sorge, Sie müssen kein Azure-Konto haben und es ist auch KOSTENLOS.
Sie können die Appliance gerne neu konfigurieren, um sie auf Ihren eigenen Servern auszuprobieren.

Im Folgenden finden Sie einige Hinweise, die Ihnen helfen sollen, sich auf der Benutzeroberfläche zurechtzufinden und das Beste aus Ihrer Testfahrt herauszuholen, also schnallen Sie sich an....

Sobald Sie sich für Ihren ALB-X-Testlauf angemeldet haben, erhalten Sie Ihre eigene URL, mit der Sie über Ihren Webbrowser auf die ALB-X-GUI zugreifen können. Wenn möglich, empfehlen wir die Verwendung des Browsers Google Chrome.

Für die Live-Bereitstellung können Sie Ihr eigenes Zertifikat hochladen, um die Authentizität der Verwaltungsverbindung zu bestätigen.

Geben Sie bei der Aufforderung Ihren eindeutigen Benutzernamen und Ihr Passwort für diese Testlaufsitzung ein (Sie haben diese in der E-Mail erhalten).

Azure Test Drive Setup

Die auf der Load Balancer-Appliance automatisch konfigurierte IP-Adresse verwendet eine private Azure-IP-Adresse.
Sie können Azure natürlich so konfigurieren, dass es weitere Ports für zusätzliche Dienste öffnet und NAT durchführt.
Für diese Demo wurden nur die Ports 80, 443 und 27376 (für die GUI) geöffnet.

ALB-X Test Drive Vorgefertigte Dienste

Da es sich um einen benutzerdefinierten Testlauf handelt, haben wir die IP-Dienste mit einigen Diensten vorbelegt, die Sie sofort ausprobieren können. Für den Testlauf haben wir echte Serverinhalte auf 2 öffentlich zugänglichen Webservern zur Verfügung gestellt:

Wir haben 4 Demodienste für Sie eingerichtet:

Name	Hafen	Zugänglichkeit
Lastausgleich für die wenigsten HTTP-Verbindungen	80	http://yoururl
HTTPS-Offload	443	https://yoururl
Cookie-basierte Persistenz	601	http://yoururl/601/
Körperprüfung neu schreiben	602	http://yoururl/?602

Dienst auf Port 80 - Lastausgleich für HTTP-Mindestverbindungen

Der erste Dienst ist ein einfacher Webserver-Load-Balancer für Port 80, der unsere Lastausgleichsrichtlinie "geringste Verbindungen" für 2 "echte Server" verwendet.

Dienst an Anschluss 443 - SSL-Offloading

Der zweite Dienst läuft über Port 443. In diesem Fall übernimmt der Load Balancer die Verschlüsselung, die auch als SSL-Offload" bezeichnet wird.

Sie können gerne Ihr eigenes SSL-Zertifikat hochladen und auf den Dienst anwenden, siehe Anleitung weiter unten. Sobald Sie die Sicherheitsausnahme überwunden haben, wird derselbe Inhalt in Ihrem Browser angezeigt.

Umleitung von HTTP zu HTTPS

Die erste Sache, die wir uns ansehen können und die flightPATH verwendet, ist die Umleitung von HTTP zu HTTPS.

Diese Funktion wird häufig verwendet, um sicherzustellen, dass der Internetverkehr über eine sichere Verbindung läuft.

				
					/?secure

Wenn flightPATH diese "Bedingung" erkennt, reagiert es auf den Datenverkehr und sendet eine 302-Weiterleitung an den Browser, um ihm mitzuteilen, dass er eine weitere GET-Anfrage an HTTPS://your.original.request.location stellen soll, die in diesem Fall dieselbe öffentliche IP-Adresse des Dienstes ist, jedoch über den Kanal 443.

Schauen Sie sich nun an, wie die flightPATH-Regel konfiguriert ist.

Dazu klicken Sie auf die Registerkarte Bibliothek auf der linken Seite und wählen flightPATH.

Klicken Sie auf den Eintrag "HTTPS erzwingen - wenn der Abfrage-String sicher ist" und Sie können die

Persistenz von Cookies und Verwendung eines pfadbasierten Servers

Wie Sie gesehen haben, wurden die Verbindungen bisher auf beide realen Server verteilt – deshalb sehen Sie Bilder, die sowohl von Server 1 als auch von Server 2 zurückgegeben werden. Das liegt daran, dass die Standardrichtlinie für den Lastausgleich „geringste Verbindungen“ lautet. Damit wird versucht, eine gerade Anzahl von Verbindungen zu allen für einen Dienst konfigurierten Servern aufrechtzuerhalten.

Bei HTTP-Diensten kann dies durch die Anwendung eines speziellen Sitzungs-Cookies erreicht werden, das der Browser bei allen nachfolgenden Anfragen an diesen Dienst vorlegt, normalerweise für die Dauer der "Sitzung".

Die flightPATH-Regel prüft den angeforderten Pfad, und wenn dieser /601/ lautet, wird der Datenverkehr an den Dienst gesendet, der an Port 601 läuft. Hier sind die Einzelheiten dieser flightPATH-Regel.

Diese flightPATH-Regel zeigt, wie der Datenverkehr auf der Grundlage des Pfades an einen anderen Dienst gesendet werden kann; dies ist ein leistungsfähiges Instrument zur Manipulation des Datenverkehrs oder zur Steuerung von Inhalten.

Wir können die Konfiguration des VIP auf Port 601 sehen:

				
					http://myurl/601/

Sie sehen hier, dass der gesamte Inhalt von Server 1 geliefert wird - Sie können in den Entwicklertools Ihres Browsers nachsehen, dass ein Cookie namens jnAccel= gesetzt wurde.

Path Rewrite und RegEx-Auswertung

Da der echte Server keinen Inhalt unter dem Pfad /601/ hat, mussten wir ihn aus der Anfrage entfernen, da wir sonst einen 404-Fehler erhalten würden (den wir auch mit flightPATH ausblenden können).

Hier suchen wir wieder nach 601 im Pfad als Bedingung, um diese Regel auszulösen.

Wir erstellen also den NewPath, indem wir einfach die Daten nach dem führenden Pfadpräfix /601/ extrahieren.

Die "Aktion" besteht darin, den Pfad unter Verwendung von $NewPath1$ und $querystring$ neu zu schreiben, falls dieser vorhanden war.

HTML-Text ersetzen

Im anderen Servicebeispiel mit Port :602 zeigen wir, wie Sie auch den HTML-Inhalt und nicht nur den HTTP-Header manipulieren können.

				
					http://myurl/?602

Wenn Sie die öffentliche IP-Adresse Ihres Testlaufwerks ALB-X in Ihren Browser eingeben und /?602 anhängen, sollten Sie das folgende Ergebnis zurückerhalten.

Sie können eine zusätzliche Textzeile in Orange sehen, die besagt, dass -

Dies wird mit Hilfe von 2 flightPATH-Regeln erreicht.

Die folgende Regel, die auf Port:80 angewendet wird, sucht nach einem Query-String-Wert von 602 und sendet alle übereinstimmenden Anfragen an den Dienst, der auf Port 602 läuft.

Auf den Dienst, der auf Port :602 läuft, wird eine flightPATH-Regel angewendet, die eine 'Body Replace Last'-Funktion ausführt und nach dem abschließenden Body-Tag sucht

				
					</body>

und ersetzt sie durch

				
					<font face=’Arial’ size=’6′ color=’orange’><center>This text has been added by flightPATH</center></font></body>

In diesem Fall ist keine Bedingung oder Bewertung erforderlich, so dass die Funktion für den gesamten Verkehr gilt, der den Dienst durchläuft.

Sie sehen hoffentlich, wie diese Möglichkeiten kombiniert werden können, um den HTTP-Verkehr geschickt zu manipulieren, und dies ist nur die Spitze des Eisbergs dessen, was flightPATH tun kann.

Probieren Sie es selbst aus, und wir würden uns freuen, von Ihren spezifischen Anforderungen zu hören.

Echte Server-Gesundheitschecks

Als Nächstes werden wir uns mit der Überprüfung des Serverzustands befassen. Es ist von entscheidender Bedeutung, dass die richtige Art von Gesundheitsprüfung auf einen Dienst angewendet wird, um eine zuverlässige Erkennung des Zustands der Backend-Server zu ermöglichen und sicherzustellen, dass der Client-Datenverkehr nur an Server gesendet wird, die betriebsbereit sind.

Bei der Erstellung eines neuen Dienstes müssen wir eine Reihe von Standardparametern festlegen. Für die Serverüberwachung verwenden wir den TCP Connection Health Check. Die Option Serverüberwachung befindet sich auf der Registerkarte Basis für den zu konfigurierenden Dienst.

Dies ist zwar ein vernünftiger Ausgangspunkt, aber es wird dringend empfohlen, eine zuverlässigere Zustandsprüfung zu konfigurieren und auf einen Dienst anzuwenden. Wir haben die Erstellung benutzerdefinierter HTTP-Zustandsprüfungen sehr einfach gemacht.

Im Test Drive haben wir einen dritten Real Server Monitor hinzugefügt, um ein Beispiel für einen HTTP Response Health Check zu zeigen.

HTTP 200 OK Überwachungsmethode

Der 200OK verwendet eine HTTP-GET-Anfrage an die für die Prüfung konfigurierte Seite und stellt sicher, dass eine 200OK-Statusantwort zurückgegeben wird.

Er sucht nicht nach bestimmten Inhalten, sondern prüft nur, ob ein Webserver an diesem Anschluss läuft und die angeforderte Seite bereitstellen kann.

Wir haben diesen Monitor, wie Sie oben sehen können, auf den Dienst angewendet, der auf Port:601 läuft.

HTTP-Antwort-Überwachungsmethode

Der im Testlauf konfigurierte NLS-Monitor verwendet die HTTP-Antwortprüfung.

Hierfür definieren Sie die spezifische Seitenposition (dies kann die vollständige URL sein, wenn Host-Header erforderlich sind) und Sie definieren den Inhalt (eine Textzeichenkette), der in den vom Server/der Anwendung zurückgegebenen Daten enthalten sein soll.

Dies ist ein weitaus besserer Test, da die Seite vorhanden sein muss und der spezifische Inhalt verfügbar sein muss.

Wie Sie sehen, haben wir diesen Monitor auf den Dienst angewendet, der auf Port:602 läuft.

Sie können den Text im Feld "Erforderlicher Inhalt" für diese Gesundheitsprüfung ändern, und die Server werden rot angezeigt, um anzuzeigen, dass sie die Gesundheitsprüfung nicht bestanden haben. Stellen Sie den erforderlichen Inhalt wieder auf den korrekten Wert zurück, und die Server werden wieder grün angezeigt.

Überwachungsintervall

Auf der Registerkarte "Erweitert" können Sie die Häufigkeit und das Zeitlimit usw. für die Gesundheitsprüfung des betreffenden Dienstes einstellen.

Für die Testfahrt haben wir das Überwachungsintervall auf 3 Sekunden mit einem Timeout von 2 Sekunden eingestellt.

Der Monitoring Out Count ist auf 3 gesetzt, so dass der Server erst dann als unerreichbar markiert wird, wenn er 3 aufeinander folgende Antworten erhält.

HTTPS und SSL-Zertifikate

Immer mehr Websites verwenden HTTPS, und Anfang 2017 hatte sich der Prozentsatz zugunsten von HTTPS verschoben.

Die meisten Unternehmensanwendungen erfordern einen Schutz durch Verschlüsselung, so dass Sie mit ziemlicher Sicherheit Zertifikate auf dem ALB-X verwenden müssen. Die Bereitstellung eines Load Balancers mit HTTPS ist eine schnelle und einfache Möglichkeit, den Zugriff auf nicht verschlüsselte Anwendungen zu sichern.

Der Dienst ist für SSL-Offload konfiguriert und die Real Server Seite ist daher für No SSL konfiguriert.

Zertifikat hochladen/importieren

Sie können Ihre eigenen signierten Zertifikate auf den ALB-X hochladen, indem Sie das Menü SSL-Zertifikate im Abschnitt Bibliothek

Wie in den Texteingabefeldern hervorgehoben, muss das Zertifikat im PKCS#12-Format vorliegen, um in ALB-X importiert werden zu können.

Der Name (der keine Leerzeichen enthalten darf), den Sie dem Zertifikat beim Importieren geben, wird in den Dropdown-Listen für die Zertifikatsauswahl auf der Registerkarte IP Service Basic angezeigt.

Real Server Re-Encryption

Wenn die realen Server eine SSL/TLS-Neuverschlüsselung benötigen, ist es am sinnvollsten, die Option "Beliebig" aus der Dropdown-Liste "SSL-Zertifikat für reale Server" auszuwählen.

SNI (Server Name Indication)

Angesichts der Knappheit an öffentlichen IP-Adressen und der Tatsache, dass in Azure nur ein VIP konfiguriert werden kann, ist es sinnvoll, mehrere sichere Domains/Host-URLs über einen virtuellen Dienst zu unterstützen, was auf ALB-X möglich ist, da wir SNI unterstützen.

Auf der Real Server Seite, wenn die Dienste neu verschlüsselt und auf gemeinsamen Servern gehostet werden, benötigen sie SNI für die korrekte Dienstidentifizierung und -aushandlung, daher sollte SNI als Option in der Dropdown-Liste Real Server SSL-Zertifikat ausgewählt werden.

Apps

ALB-X unterstützt die Bereitstellung zusätzlicher Features und Funktionen durch den Kauf und das Herunterladen von Apps aus unserem App Store für die Bereitstellung innerhalb der ALB-X-Containerumgebung.

Wir haben 2 getrennte Testläufe in Azure eingerichtet, in denen Sie diese Funktionalität in Betrieb sehen können, wenn Sie daran interessiert sind.

Authentifizierung

ALB-X unterstützt Pre-Authentication in Verbindung mit einem MS AD (Microsoft Active Directory ) / LDAP-Server.

Diese Funktionalität ist ein beliebter Ersatz für das eingestellte Microsoft-Produkt TMG.

Überwachung von Gerätenutzung und Verbindungen

Der Abschnitt "Ansicht" des Menüs bietet Ihnen die Möglichkeit, den Verbindungsstatus und den tatsächlichen Zustand des Servers entweder in Echtzeit (Status) oder als Trend über die Zeit (Verlauf) zu sehen.

System

Hier finden Sie Konfigurationsoptionen, die sich auf die Systemfunktionen beziehen, wie z. B. die Einstellung von Uhrzeit und Datum, die Aktivierung von E-Mail-Benachrichtigungen, die Lizenzierung des Produkts, die Auswahl, wie die Protokollierung durchgeführt wird und wohin die Protokolle gesendet werden, der Neustart und die Wiederinbetriebnahme der Appliance, die Konfiguration von SNMP und das Hinzufügen anderer Verwaltungsbenutzer usw.

Fortgeschrittene

Im erweiterten Menü können Sie die Konfiguration sichern und wiederherstellen und auch jetPACK-Vorlagenkonfigurationen hochladen.

Schließlich gibt es einen Abschnitt zur Fehlerbehebung, in dem wir es Ihnen leicht gemacht haben, ein gebündeltes Unterstützungsdateipaket herunterzuladen, einen Netzwerk-PING durchzuführen und verschiedene Systemabfragen und Netzwerkpaketaufzeichnungen vorzunehmen.

Ich danke Ihnen.

Wir würden uns freuen, wenn Sie Fragen an pre-sales@edgenexus.io richten würden.

Kontakt

0808 1645876

(866) 376-0175

pre-sales@edgenexus.io

Nehmen Sie uns nicht beim Wort - machen Sie einen kostenlosen Test

Hardware, Software oder sogar Ihr eigenes Online-Image mit einer vollständigen Testumgebung.
Lassen Sie uns einfach wissen, was Sie brauchen hier

ANWENDUNGEN

RESSOURCEN

PARTNER

APP STORE