Freigeben über


Erreichen von Hochverfügbarkeit und Skalierbarkeit - ARR und Hardware Load Balancer

von Won Yoo

Erreichen von Hochverfügbarkeit und Skalierbarkeit:
Microsoft Application Request Routing (ARR) für IIS 7.0 und höher und Hardwarelastenausgleich.

Microsoft Corporation F5
Autor: Won Yoo Autor: Ryan Korock
Veröffentlicht: 13. November 2008

Abstract

Dieses Dokument enthält präskriptive Anleitungen dazu, wie Routing von Anwendungsanforderungen (ARR) mit einem Hardwaregerät zum Lastenausgleich verwendet werden kann, um hohe Verfügbarkeit und Skalierbarkeit zu erzielen. F5 BIG-IP Load Balancer wird in diesem Dokument verwendet, um die Arbeitsbeziehung zwischen ARR und den Hardwarelastenausgleichsmodulen zu veranschaulichen.

Übersicht

Microsoft Routing von Anwendungsanforderungen (Application Request Routing, ARR) für IIS 7.0 ist ein proxybasiertes Routingmodul, das HTTP-Anforderungen auf Grundlage von HTTP-Headern, Servervariablen und Lastenausgleichsalgorithmen an Inhaltsserver weiterleitet. Eine typische ARR-Bereitstellung wird im folgenden Diagramm veranschaulicht:

Diagram of a typical A R R deployment. A R R provides high availability and scalability for the content servers.

ARR bietet zwar hohe Verfügbarkeit und Skalierbarkeit für die Inhaltsserver, die gesamte Bereitstellung ist jedoch nicht hochverfügbar oder skalierbar, da:

  • ARR ist der Single Point of Failure.
  • Die Skalierbarkeit der Inhaltsserver ist durch die maximale Kapazität eines ARR-Servers begrenzt.

Um diese Herausforderungen zu bewältigen, können Administratoren die Verwendung mehrerer ARR-Server mit Hardwarelastenausgleichsmodulen wie F5 BIG-IP in Betracht ziehen. ARR kann im aktiven/passiven Modus bereitgestellt werden, um nur hohe Verfügbarkeit oder im aktiven/aktiven Modus, um sowohl hohe Verfügbarkeit als auch Skalierbarkeit zu erzielen. In diesem Whitepaper wird beschrieben, wie ARR und F5 BIG-IP zusammen bereitgestellt werden können, um die wichtigsten ARR-Szenarien zu ermöglichen und gleichzeitig hohe Verfügbarkeit und Skalierbarkeit zu erzielen.

Verwendung von Routing von Anwendungsanforderungen und F5 BIG-IP

ARR wird als Modul über IIS erstellt und ist darauf ausgelegt, die Routingentscheidungen auf Schicht 7 (Anwendung) zu treffen. Genauer gesagt basiert ARR auf einem anderen IIS-Modul, URL Rewrite, um die eingehenden HTTP-Anforderungsheader und Servervariablen zu prüfen, um die Routingentscheidungen zu treffen. Aufgrund dieses Designs können Administratoren intelligente Routingregeln basierend auf den Informationen auf Anwendungsebene schreiben, z. B.:

  • Hostname (HTTP_HOST): Leiten Sie den Datenverkehr basierend auf dem Hostnamen an verschiedene Inhaltsserver weiter.
  • Angeforderte Ressource (URL): Ermitteln Sie basierend auf Dateierweiterungen, ob die angeforderten Ressourcen für statische Inhalte oder dynamische Inhalte sind, und leiten Sie die Anforderungen entsprechend weiter.
  • Clientinformationen (HTTP_USER_AGENT): Basierend auf dem Browsertyp und der Version leiten Sie die Anforderungen an die entsprechenden Inhaltsserver weiter.
  • Benutzerdefinierte Header (Als Cookie nach Anwendungen festlegen): Leiten Sie Datenverkehr basierend auf Cookieinformationen, die von Anwendungen festgelegt werden, z. B. Benutzereinstellung oder Benutzer-ID.

Oben sind nur einige Beispiele aufgeführt. Eine vollständige Liste der HTTP-Header und Servervariablen finden Sie in Anhang A.

F5 Big-IPs Schicht 3- und Schicht 4-Funktionalität ergänzt die Stärke von ARR bei der Entscheidungsfindung über Routingentscheidungen basierend auf Schicht 7, z. B. HTTP-Header und Servervariablen. Gleichzeitig stellt ARR keine fehlertoleranten Bereitstellungsfeatures für sich selbst bereit und muss sich auf andere ergänzende Technologien und Lösungen verlassen, um eine hohe Verfügbarkeit für die ARR-Ebene zu erreichen, wie unten dargestellt:

Diagram of F five Big dash I P layer three and four functionality. F five Big dash I P layer three and layer four compliment A R R strength in making routing decisions based on layer seven.

Szenario 1: HTTP-basiertes Routing und Lastenausgleich

Das HTTP-basierte Routing- und Lastenausgleichsszenario ermöglicht eine 3-stufige Bereitstellungsarchitektur, die Folgendes umfasst:

  • Stufe 1 (Web): Stellt duale Zwecke für die Verarbeitung statischer Inhalte und des Routings und des Lastenausgleichs der verbleibenden dynamischen Anforderungen an Server der Stufe 2 bereit.
  • Stufe 2 (Anwendung): Verarbeitet dynamische Inhalte, die auf Geschäftslogik basieren.
  • Stufe 3 (Daten): Speichert Daten.

Das folgende Diagramm veranschaulicht die 3-stufige Bereitstellung:

Diagram illustrating the three tier deployment. It shows a routing rule that differentiates the static content form the dynamic content.

Obwohl das obige Beispiel eine Routingregel zeigt, die den statischen Inhalt vom dynamischen Inhalt unterscheidet, besteht ein weiteres häufiges Szenario darin, Präsentationsanforderungen von Webdienstanforderungen zu unterscheiden.

Option 1: Aktiv/Passiv

Im aktiven/passiven Modus gibt es in der Regel zwei ARR-Server, in denen ein Server die Anforderungen verarbeitet, während der andere Server als Failoverserver steht. Wie oben erwähnt, erreicht diese Konfiguration zwar eine hohe Verfügbarkeit durch das Entfernen des Single Point of Failures, es ist jedoch keine Skalierungslösung, da die aggregierte Kapazität der Inhaltsserver durch die maximale Kapazität eines ARR-Servers begrenzt ist.

Da in diesem Setup zwei ARR-Server auf die gleiche Weise konfiguriert sind, wird eine freigegebene Konfiguration verwendet. Die F5 BIG-IP ist so konfiguriert, dass alle Anforderungen an den aktiven ARR-Server weitergeleitet und nur bei Bedarf an den passiven ARR-Server weitergeleitet werden.

Mit Ausnahme der Funktion zur Hostnamenaffinität in ARR gibt es keine Runtime-Statusinformationen, die zwischen den beiden ARR-Servern gemeinsam genutzt werden müssen. Daher ist für dieses Szenario keine spezielle Konfiguration auf den ARR-Servern oder der F5 BIG-IP erforderlich. Auch wenn Sie die Serveraffinitätsfunktion in ARR verwenden, werden die Affinitätsstatusinformationen dem passiven Server über ein Cookie im Anforderungsheader zur Verfügung gestellt, wenn F5 BIG-IP die Anforderungen an den früher passiven, aber jetzt aktiven Server weitergibt.

Dieses Szenario wird in der ARR Version 1 vollständig unterstützt.

ARR-Konfiguration

Schritt 1: Aktivieren der freigegebenen Konfiguration auf zwei ARR-Servern.

  • Führen Sie die Schritte in diesem Dokument aus, um die freigegebene Konfiguration in IIS einzurichten.

Schritt 2: Konfigurieren der 3-stufigen Bereitstellungsarchitektur mithilfe von ARR.

  • Führen Sie die Schritte in diesem Dokument aus, um ARR in der 3-stufigen Bereitstellungsarchitektur zu konfigurieren.

  • Auf hoher Ebene beschreibt das obige Dokument Folgendes:

    • Bereitstellung statischer Inhalte auf dem ARR-Server.
    • Schreiben von URL-Umschreibungsregeln für statische Inhalte, sodass sie direkt vom ARR-Server bereitgestellt werden.
    • Schreiben von URL-Umschreibungsregeln für dynamische Inhalte, sodass sie an die Anwendungsserver weitergeleitet werden.

F5 BIG-IP-Konfiguration

In diesem Szenario erstellen Sie einen virtuellen Server, der einen Lastenausgleich auf einen Pool von zwei (oder mehr) ARR-Servern herstellt. Die ausgewählte Lastenausgleichsmethode sollte den gesamten Datenverkehr an den primären ARR-Server senden, bis er nicht verfügbar ist. Zu diesem Zeitpunkt sollte der BIG-IP LTM den gesamten Datenverkehr an den sekundären ARR-Server senden.

Schritt 1: Konfigurieren des Pools von ARR-Servern.

  • Klicken Sie im Abschnitt Lokaler Datenverkehr auf Pools. Klicken Sie dann auf die Schaltfläche Erstellen, um einen Pool zu erstellen.
  • Jeder eindeutige Name funktioniert für den Pool; im Beispiel wird ARR_Pool verwendet.
  • Für die Systemüberwachung können Sie einen benutzerdefinierten HTTP-Monitor oder den Standard-HTTP-Monitor verwenden.
  • Sie können die Lastenausgleichsmethode auf Round Robin festlegen. In diesem Szenario wird kein Lastenausgleich verwendet, da nur ein aktiver und passiver ARR-Server vorhanden ist.
  • Achten Sie darauf, die Aktivierung der Prioritätsgruppe zuzulassen. Dadurch wird die BIG-IP so konfiguriert, dass Datenverkehr an die Server mit dem höchsten Prioritätswert gesendet wird. Wenn diese Server nicht verfügbar sind, sendet BIG-IP Datenverkehr an den ARR-Server mit dem nächsthöchsten Prioritätswert.
  • In diesem Szenario weist der ARR-Server mit 10.0.0.1 den Prioritätswert 1 auf, und 10.0.0.2 hat den Prioritätswert 2. Der gesamte Datenverkehr wird an 10.0.0.2 gesendet, bis er heruntergeht, und dann wird der Datenverkehr an 10.0.0.1 gesendet.

Screenshot of the Big dash I P web page. In the Health Monitors box under Active, h t t p is highlighted. In the New Members box, the A R R server priority value is ten dot zero dot zero dot one.

Schritt 2: Konfigurieren des Pools von ARR-Servern.

  • Klicken Sie im Abschnitt Lokaler Datenverkehr auf Virtuelle Server. Klicken Sie dann auf die Schaltfläche Erstellen, um einen virtuellen Server zu erstellen.
  • Jeder eindeutige Name funktioniert für den virtuellen Server; im Beispiel wird ARR_VS verwendet.
  • Für das Ziel können Sie die IP-Adresse verwenden, auf die Benutzer ihre Browser verweisen. In diesem spezifischen Beispiel verwenden wir 65.197.145.23. Für den Dienstport verwenden wir "80".
  • Für den Abschnitt Virtual Server Type haben Sie mehrere Optionen. Da Sie von ARR abhängig sind, können Sie Performance HTTP auswählen, das für die beste Leistung ausgelegt ist.
  • Wählen Sie für den Standardpool den Pool aus, den Sie in Schritt 1 erstellt haben.

Screenshot of the F five Big I P page. In the Name box A R R underscore V S is written.

  • Zu diesem Zeitpunkt sollten Sie in der Lage sein, eine Verbindung mit diesem virtuellen Server herzustellen, der an den entsprechenden ARR-Server gesendet wird.

Option 2: Aktiv/Aktiv

Im Aktiv/Aktiv-Modus können Sie über zwei oder mehr ARR-Server verfügen. Diese Konfiguration erreicht sowohl hohe Verfügbarkeit als auch Skalierbarkeit, im Gegensatz zum Active/Pass-Modus, der nur hohe Verfügbarkeit erreicht. Wie bereits erwähnt, wird eine gemeinsam genutzte Konfiguration verwendet, da mehrere ARR-Server auf die gleiche Weise konfiguriert sind. Die F5 BIG-IP ist so konfiguriert, dass eingehende Anforderungen auf alle verfügbaren und fehlerfreien ARR-Servern geladen werden, die wiederum Anforderungen an die Inhaltsserver weiterleitet. Unabhängig davon, ob die Serveraffinitätsfunktion auf der F5 BIG-IP verwendet wird oder nicht, ist keine spezielle Konfiguration auf den ARR-Servern erforderlich. Zum einen verwenden die ARR-Server eine freigegebene Konfiguration, sodass sie auf die gleiche Weise konfiguriert sind. Da ARR ein Clientcookie verwendet, um die Serveraffinitätsinformationen für die eigene Verwendung zu speichern, sind diese Informationen pro Anforderung verfügbar und daher auf den ARR-Servern verfügbar. Dieses Szenario wird in der ARR Version 1 vollständig unterstützt.

ARR-Konfiguration

Die ARR-Konfiguration für Aktiv/Aktiv ist identisch mit der von Aktiv/Passiv. Der Hauptunterschied besteht darin, wie F5 konfiguriert ist.

Schritt 1: Aktivieren der freigegebenen Konfiguration auf zwei ARR-Servern.

  • Führen Sie die Schritte in diesem Dokument aus, um die freigegebene Konfiguration in IIS einzurichten.

Schritt 2: Konfigurieren der 3-stufigen Bereitstellungsarchitektur mithilfe von ARR.

  • Führen Sie die Schritte in diesem Dokument aus, um ARR in der 3-stufigen Bereitstellungsarchitektur zu konfigurieren.

  • Auf hoher Ebene beschreibt das obige Dokument Folgendes:

    • Bereitstellung statischer Inhalte auf dem ARR-Server.
    • Schreiben von URL-Umschreibungsregeln für statische Inhalte, sodass sie direkt vom ARR-Server bereitgestellt werden.
    • Schreiben von URL-Umschreibungsregeln für dynamische Inhalte, sodass sie an die Anwendungsserver weitergeleitet werden.

F5 BIG-IP-Konfiguration

In diesem Szenario gelten alle verfügbaren ARR-Server als aktiv und Kandidaten für Datenverkehr mit Lastenausgleich. Verwenden Sie BIG-IP LTM, um die Integrität und Leistung der ARR-Front-Ends zu ermitteln und den Datenverkehr auf die leistungsstärksten Zugänge zu lenken.

Schritt 1: Konfigurieren des Pools von ARR-Servern.

  • Klicken Sie im Abschnitt Lokaler Datenverkehr auf Pools. Klicken Sie dann auf die Schaltfläche Erstellen, um einen Pool zu erstellen.
  • Jeder eindeutige Name funktioniert für den Pool; in den Beispielen wird ARR_Pool verwendet. - Für die Systemüberwachung können Sie einen benutzerdefinierten HTTP-Monitor oder den Standard-HTTP-Monitor verwenden. - Da Sie über mehrere ARR-Server verfügen, an die Datenverkehr verteilt werden soll, sollten Sie eine Lastenausgleichsmethode auswählen, die Ihren Anforderungen am besten entspricht. Wenn alle ARR-Server ähnliche Hardwaremerkmale aufweisen, erhalten Sie eine dynamische Lastenausgleichsmethode, z. B. schnellste, beobachtete oder prädiktive, leistungsbasierte Verteilung.

Screenshot of the F five Big I P web page. In the Load Balancing Method box, Fastest Application is chosen.

Schritt 2: Konfigurieren des virtuellen Servers.

  • Klicken Sie im Abschnitt Lokaler Datenverkehr auf Virtuelle Server. Klicken Sie dann auf die Schaltfläche Erstellen, um einen virtuellen Server zu erstellen.
  • Jeder eindeutige Name funktioniert für den virtuellen Server; im Beispiel wird ARR_VS verwendet. - Für das Ziel können Sie die IP-Adresse verwenden, auf die Benutzer ihre Browser verweisen. In diesem spezifischen Beispiel verwenden wir 65.197.145.23. Für den Dienstport verwenden wir "80". - Für den Abschnitt Virtual Server Type haben Sie mehrere Optionen. Da Sie von ARR abhängig sind, können Sie Performance HTTP auswählen, das für die beste Leistung ausgelegt ist. – Wählen Sie für den Standardpool den Pool aus, den Sie in Schritt 1 erstellt haben.

Screenshot of the F five Big I P web page. In the Default Pool box, the pool created in Step one, the A R R pool, is selected.

Szenario 2: Gemeinsames Hosting mithilfe der Hostnamenaffinität

In diesem Szenario wird das Affinitätsfeature für Hostnamen in ARR verwendet, um eine gemeinsame Hostingbereitstellung für Folgendes zu ermöglichen:

  • Verringern Sie die manuelle Verwaltung und Wartung, die mit der herkömmlichen Bereitstellung gemeinsam genutzter Hostings verbunden ist.
  • Maximieren Sie die vorhandenen Serverressourcen, und stellen Sie sicher, dass alle Serverressourcen gleichmäßig genutzt werden.
  • Skalieren Sie die Umgebung auf einfache Weise.
  • Schaffen Sie Geschäftsmöglichkeiten, um zusätzliche Kapazitäten zu verkaufen.

Weitere Informationen zu gemeinsamem Hosting und ARR finden Sie in diesem Dokument.

Das folgende Diagramm veranschaulicht die freigegebene Hostingumgebung mithilfe von ARR: Diagram of the shared hosting environment using A R R.

Option 1: Aktiv/Passiv

Wie bereits erwähnt, gibt es im Aktiven/Passiven Modus in der Regel zwei ARR-Server, in denen ein Server die Anforderungen verarbeitet, während der andere Server als Failoverserver steht. Während diese Konfiguration hohe Verfügbarkeit durch Entfernen des einzelnen Fehlerpunkts erreicht, ist es keine Skalierungslösung, da die aggregierte Kapazität der Inhaltsserver durch die maximale Kapazität eines ARR-Servers begrenzt ist.

Da in diesem Setup zwei ARR-Server auf die gleiche Weise konfiguriert sind, wird eine freigegebene Konfiguration verwendet. Die F5 BIG-IP ist so konfiguriert, dass alle Anforderungen an den aktiven ARR-Server weitergeleitet und nur bei Bedarf an den passiven ARR-Server weitergeleitet werden.

Das Feature Hostnamenaffinität in ARR affinitisiert die Anforderungen auf einen bestimmten Server (oder eine Gruppe von Servern in RC) basierend auf dem Hostnamen. Die Laufzeitstatusinformationen der Affinitätszuordnung zwischen den Hostnamen und den Inhaltsservern werden innerhalb einer Instanz eines ARR-Servers im Arbeitsspeicher gespeichert. In der ARR Version 1-Version nutzt ARR den externen Microsoft Cache für IIS, um diesen Laufzeitstatus zwischen mehreren ARR-Servern freizugeben und aufrechtzuerhalten. Weitere Informationen zu diesem Szenario finden Sie in diesem Dokument.

Dieses Szenario wird in der ARR Version 1 vollständig unterstützt.

ARR-Konfiguration

Schritt 1: Aktivieren der freigegebenen Konfiguration auf zwei ARR-Servern.

  • Führen Sie die Schritte in diesem Dokument aus, um die freigegebene Konfiguration in IIS einzurichten.

Schritt 2: Konfigurieren der 3-stufigen Bereitstellungsarchitektur mithilfe von ARR.

  • Führen Sie die Schritte in diesem Dokument aus, um ARR in der 3-stufigen Bereitstellungsarchitektur zu konfigurieren.

  • Auf hoher Ebene beschreibt das obige Dokument Folgendes:

    • Bereitstellung statischer Inhalte auf dem ARR-Server.
    • Schreiben von URL-Umschreibungsregeln für statische Inhalte, sodass sie direkt vom ARR-Server bereitgestellt werden.
    • Schreiben von URL-Umschreibungsregeln für dynamische Inhalte, sodass sie an die Anwendungsserver weitergeleitet werden.

Schritt 3: Aktivieren und Konfigurieren des externen Caches.

  • Führen Sie die Schritte in diesem Dokument aus, um den externen Cache für die Verwendung mit ARR zu aktivieren und zu konfigurieren.

F5 BIG-IP-Konfiguration

In diesem Szenario erstellen Sie einen virtuellen Server, der einen Lastenausgleich auf einen Pool von zwei (oder mehr) ARR-Servern herstellt. Die ausgewählte Lastenausgleichsmethode sollte den gesamten Datenverkehr an den primären ARR-Server senden, bis er nicht verfügbar ist. Zu diesem Zeitpunkt sollte der BIG-IP LTM den gesamten Datenverkehr an den sekundären ARR-Server senden.

Schritt 1: Konfigurieren des Pools von ARR-Servern.

  • Klicken Sie im Abschnitt Lokaler Datenverkehr auf Pools. Klicken Sie dann auf die Schaltfläche Erstellen, um einen Pool zu erstellen.
  • Jeder eindeutige Name funktioniert für den Pool; im Beispiel wird ARR_Pool verwendet. - Für die Systemüberwachung können Sie einen benutzerdefinierten HTTP-Monitor oder den Standard-HTTP-Monitor verwenden. - Sie können die Load Balancing-Methode auf Round Robin festlegen. In diesem Szenario wird kein Lastenausgleich verwendet, da nur ein aktiver und passiver ARR-Server vorhanden ist. - Achten Sie darauf, die Aktivierung der Prioritätsgruppe zuzulassen. Dadurch wird die BIG-IP so konfiguriert, dass Datenverkehr an die Server mit dem höchsten Prioritätswert gesendet wird. Wenn diese Server nicht verfügbar sind, sendet BIG-IP Datenverkehr an den ARR-Server mit dem nächsthöchsten Prioritätswert. - In diesem Szenario hat der ARR-Server mit 10.0.0.1 den Prioritätswert 1, und 10.0.0.2 hat den Prioritätswert 2. Der gesamte Datenverkehr wird an 10.0.0.2 gesendet, bis er heruntergeht, und dann wird der Datenverkehr an 10.0.0.1 gesendet.

Screenshot of the Big I P web site. In the name box is A R R underscore pool. In the Local Traffic pane, Pools is selected.

Schritt 2: Konfigurieren des virtuellen Servers.

  • Klicken Sie im Abschnitt Lokaler Datenverkehr auf Virtuelle Server. Klicken Sie dann auf die Schaltfläche Erstellen, um einen virtuellen Server zu erstellen.
  • Jeder eindeutige Name funktioniert für den virtuellen Server; im Beispiel wird ARR_VS verwendet. - Für das Ziel können Sie die IP-Adresse verwenden, auf die Benutzer ihre Browser verweisen. In diesem Fall verwenden wir . Für den Dienstport verwenden wir "80". - Für den Abschnitt Virtual Server Type haben Sie mehrere Optionen. Da Sie von ARR abhängig sind, können Sie Performance HTTP auswählen, das für die beste Leistung ausgelegt ist. – Wählen Sie für den Standardpool den Pool aus, den Sie in Schritt 1 erstellt haben.

Screenshot of the F five web page. In the Default Pool box, A R R pool is selected. In the Local Traffic pane, Virtual Servers is selected.

  • Zu diesem Zeitpunkt sollten Sie in der Lage sein, eine Verbindung mit diesem virtuellen Server herzustellen, der an den entsprechenden ARR-Server gesendet wird.

Option 2: Aktiv/Aktiv in ARR

Im Aktiv/Aktiv-Modus können Sie über zwei oder mehr ARR-Server verfügen. Diese Konfiguration erreicht sowohl hohe Verfügbarkeit als auch Skalierbarkeit, im Gegensatz zum Active/Pass-Modus, der nur hohe Verfügbarkeit erreicht. Da mehrere ARR-Server auf die gleiche Weise konfiguriert sind, wird eine freigegebene Konfiguration verwendet. Die F5 BIG-IP ist so konfiguriert, dass eingehende Anforderungen auf alle verfügbaren und fehlerfreien ARR-Servern geladen werden, die wiederum Anforderungen an die Inhaltsserver weiterleitet.

Wie bereits erwähnt, werden die Laufzeitstatusinformationen der Affinitätszuordnung zwischen den Hostnamen und den Inhaltsservern in einem Speicher innerhalb einer Instanz eines ARR-Servers gespeichert. Um diese Informationen auf mehreren ARR-Servern freizugeben, wird der externe Microsoft-Cache für IIS verwendet. Weitere Informationen zum externen Cache finden Sie in diesem Dokument.

ARR-Konfiguration

Die ARR-Konfiguration für Aktiv/Aktiv ist identisch mit der von Aktiv/Passiv. Der Hauptunterschied besteht darin, wie F5 konfiguriert ist.

Schritt 1: Aktivieren der freigegebenen Konfiguration auf zwei ARR-Servern.

  • Führen Sie die Schritte in diesem Dokument aus, um die freigegebene Konfiguration in IIS einzurichten.

Schritt 2: Konfigurieren der 3-stufigen Bereitstellungsarchitektur mithilfe von ARR.

  • Führen Sie die Schritte in diesem Dokument aus, um ARR in der 3-stufigen Bereitstellungsarchitektur zu konfigurieren.

  • Auf hoher Ebene beschreibt das obige Dokument Folgendes:

    • Bereitstellung statischer Inhalte auf dem ARR-Server.
    • Schreiben von URL-Umschreibungsregeln für statische Inhalte, sodass sie direkt vom ARR-Server bereitgestellt werden.
    • Schreiben von URL-Umschreibungsregeln für dynamische Inhalte, sodass sie an die Anwendungsserver weitergeleitet werden.

Schritt 3: Aktivieren und Konfigurieren des externen Caches.

  • Führen Sie die Schritte in diesem Dokument aus, um den externen Cache für die Verwendung mit ARR zu aktivieren und zu konfigurieren.

F5 BIG-IP-Konfiguration

In diesem Szenario gelten alle verfügbaren ARR-Server als aktiv und Kandidaten für Datenverkehr mit Lastenausgleich. Verwenden Sie BIG-IP LTM, um die Integrität und Leistung der ARR-Front-Ends zu ermitteln und den Datenverkehr auf die leistungsstärksten Zugänge zu lenken.

Schritt 1: Konfigurieren des Pools von ARR-Servern.

  • Klicken Sie im Abschnitt Lokaler Datenverkehr auf Pools. Klicken Sie dann auf die Schaltfläche Erstellen, um einen Pool zu erstellen.
  • Jeder eindeutige Name funktioniert für den Pool; im Beispiel wird ARR_Pool verwendet. - Für die Systemüberwachung können Sie einen benutzerdefinierten HTTP-Monitor oder den Standard-HTTP-Monitor verwenden. - Da Sie über mehrere ARR-Server verfügen, an die Datenverkehr verteilt werden soll, sollten Sie eine Lastenausgleichsmethode auswählen, die Ihren Anforderungen am besten entspricht. Wenn alle ARR-Server ähnliche Hardwaremerkmale aufweisen, erhalten Sie eine dynamische Lastenausgleichsmethode, z. B. schnellste, beobachtete oder prädiktive, leistungsbasierte Verteilung.

Screenshot of the F five web page. In the Local Traffic box, Pools is selected. In the Load Balancing Method box, Fastest application is selected.

Schritt 2: Konfigurieren des virtuellen Servers.

  • Klicken Sie im Abschnitt Lokaler Datenverkehr auf Virtuelle Server. Klicken Sie dann auf die Schaltfläche Erstellen, um einen virtuellen Server zu erstellen.
  • Jeder eindeutige Name funktioniert für den virtuellen Server; im Beispiel wird ARR_VS verwendet. - Für das Ziel können Sie die IP-Adresse verwenden, auf die Benutzer ihre Browser verweisen. In diesem Fall verwenden wir . Für den Dienstport verwenden wir "80". - Für den Abschnitt Virtual Server Type haben Sie mehrere Optionen. Da Sie von ARR abhängig sind, können Sie Performance HTTP auswählen, das für die beste Leistung ausgelegt ist. – Wählen Sie für den Standardpool den Pool aus, den Sie in Schritt 1 erstellt haben.

Screenshot of the F five web page. In the Local Traffic box, Virtual Servers is selected. In the Default Pool box, A R R Pool is selected.

Zusammenfassung

In diesem Whitepaper wurden zwei Standard-ARR-Szenarien überprüft, um hohe Verfügbarkeit und Skalierbarkeit zu erzielen, indem mehrere ARR-Server bereitgestellt und F5 BIG-IP verwendet werden.

Anhang

Anhang A: Alle verfügbaren HTTP-Header und Servervariablen zum Schreiben von Routingentscheidungsregeln.

ALL_HTTP ALL_RAW APPL_MD_PATH
APPL_PHYSICAL_PATH CERT_COOKIE CERT_FLAGS
CERT_ISSUER CERT_KEYSIZE CERT_SECRETKEYSIZE
CERT_SERIALNUMBER CERT_SERVER_ISSUER CERT_SERVER_SUBJECT
CERT_SUBJECT CONTENT_LENGTH CONTENT_TYPE
DOCUMENT_ROOT GATEWAY_INTERFACE HTTP_ACCEPT
HTTP_ACCEPT_ENCODING HTTP_ACCEPT_LANGUAGE HTTP_CONNECTION
HTTP_CONTENT_LENGTH HTTP_HOST HTTP_IF_MODIFIED_SINCE
HTTP_IF_NONE_MATCH HTTP_REFERER HTTP_UA_CPU
HTTP_USER_AGENT HTTPS HTTPS_KEYSIZE
HTTPS_SECRETKEYSIZE HTTPS_SERVER_ISSUER HTTPS_SERVER_SUBJECT
INSTANCE_ID INSTANCE_META_PATH LOCAL_ADDR
PATH_INFO PATH_TRANSLATED QUERY_STRING
REMOTE_ADDR REMOTE_HOST REMOTE_PORT
REMOTE_USER REQUEST_FILENAME REQUEST_METHOD
REQUEST_URI SCRIPT_FILENAME SCRIPT_NAME
SERVER_ADDR SERVER_NAME SERVER_PORT
SERVER_PORT_SECURE SERVER_PROTOCOL SERVER_SOFTWARE
URL