Einführung
Organisationen benötigen oft eine bestimmte Systemverfügbarkeit für ihre ArcGIS Enterprise-Bereitstellungen, beispielsweise 99 Prozent oder mehr. Für diese Organisationen ist die Implementierung einer Strategie zur Sicherstellung hoher Verfügbarkeit entscheidend.
Hohe Verfügbarkeit (HA), obwohl verwandt mit Disaster Recovery (DR), ist ein separates Konzept. Im Allgemeinen konzentriert sich HA darauf, Ausfallzeiten bei der Servicebereitstellung zu vermeiden, während DR darauf abzielt, die Daten und Ressourcen zu erhalten, die benötigt werden, um ein System nach einer Katastrophe in einen vorher akzeptablen Zustand wiederherzustellen.
Dieser Beitrag konzentriert sich auf bewährte Methoden zur Konfiguration eines lokalen Load Balancers (Local Traffic Manager, LTM) an einem einzigen Standort für hohe Verfügbarkeit und schließt keine Überlegungen zur Konfiguration des Global Traffic Managers (GTM) für automatisches Failover zwischen verschiedenen Standorten ein.
Um hohe Verfügbarkeit zu erreichen, müssen Sie Single Points of Failure durch Duplizierung und Lastverteilung reduzieren.
Load Balancer fungieren als Reverse Proxy und verteilen den Datenverkehr auf Backend-Server. Ein Drittanbieter Load Balancer ist in einer hochverfügbaren ArcGIS Enterprise-Bereitstellung erforderlich, um die Kapazität und Zuverlässigkeit der Software zu verbessern. Sie verwalten den Client-Datenverkehr zu Ihren Portal- und Server-Sites sowie den internen Datenverkehr zwischen den Softwarekomponenten.
ArcGIS Web Adaptor
Obwohl der ArcGIS Web Adaptor als Load Balancer betrachtet wird, ist er unzureichend, um als einziger Load Balancer in einer hochverfügbaren Bereitstellung zu dienen, da auch der ArcGIS Web Adaptor Redundanz benötigt, um hohe Verfügbarkeit zu erreichen.
Der ArcGIS Web Adaptor ist eine optionale Komponente, da Load Balancer Anfragen direkt an Ihre Portal- und Server-Sites weiterleiten können, dennoch ist er eine empfohlene Komponente. Die Vorteile der Verwendung von Web Adaptors sind:
- Er bietet eine einfache Möglichkeit, eine einzelne URL für das System zu konfigurieren
- Er ermöglicht die Auswahl von Kontextnamen für die verschiedenen Systemkomponenten, z.B. portal, server, mapping usw.
- Er ist nativ in andere ArcGIS Enterprise Softwarekomponenten integriert, die Portal- und Server-Sites, und übernimmt automatisch Health Checks und Konfigurationsaufgaben, z.B. das Hinzufügen neuer Maschinen zu einer Server-Site
Web Context URL
Die Web Context URL ist die öffentliche URL für das Portal. Da jedes Element im Portal eine URL hat – Datei, Layer, Karte und App – hilft die Eigenschaft WebContextURL des Portals dabei, die korrekten URLs für alle Ressourcen zu erstellen, die an den Endbenutzer gesendet werden.
Externer Zugriff und DNS
Das ArcGIS Enterprise Portal unterstützt nur einen DNS für die öffentliche Portal URL (die Web Context URL), und derzeit gibt es keine unterstützte Möglichkeit, die Web Context URL zu ändern, ohne administrative Aufgaben neu durchzuführen, z.B. das Föderieren von Server-Sites mit Ihrem Portal. Wenn Ihr ArcGIS Enterprise externen Zugriff benötigt, z.B. um mobilen Benutzern, Auftragnehmern, Partnern oder Behörden ohne VPN Zugang zu ermöglichen oder wenn Sie erwarten, dass Sie in Zukunft externen Zugriff erlauben müssen, müssen Sie einen extern auflösbaren DNS-Namen für die Web Context URL des Portals verwenden, z.B. https://gis.company.com/portal.
Um den externen Zugriff auf ArcGIS Enterprise abzusichern, ist es üblich, einen Load Balancer in einer DMZ zu hosten und ein Split Domain Name System (Split DNS) zu implementieren. Das heißt interner Zugriff auf den ArcGIS Enterprise DNS (z.B. gis.company.com) wird auf eine interne IP des Load Balancers aufgelöst, sodass interne Benutzer hinter der Firewall bleiben, und externer Zugriff auf den ArcGIS Enterprise DNS wird auf eine externe (DMZ) IP des Load Balancers aufgelöst.
URLs, die in der Föderation verwendet werden
In einer hochverfügbaren ArcGIS Enterprise-Bereitstellung werden mehrere verschiedene URLs verwendet.
Services URL
Dies ist die URL, die von Benutzern und Client-Anwendungen verwendet wird, um auf ArcGIS Server-Sites zuzugreifen. Es ist die URL des Load Balancers, der den ArcGIS Server-Datenverkehr verwaltet und Anfragen entweder an den Web Adaptor der Server-Site oder direkt an die Server-Maschinen weiterleitet.
Administrative URL
Diese URL wird von Administratoren und intern vom Portal verwendet, um auf eine ArcGIS Server-Site bei administrativen Vorgängen zuzugreifen. Diese URL wird auch zum Veröffentlichen von GIS-Diensten mit Bezug auf einen registrierten Datenspeicher verwendet, z.B. SQL Server Enterprise Geodatabase bei einer föderierten Server-Site. Diese muss auf einen Load Balancer zeigen; wenn die Administrative URL auf eine einzelne Maschine in der Server-Site zeigt und diese Maschine offline ist, funktioniert die Föderation nicht. Dies kann dieselbe URL wie die Services URL sein oder ein zweiter Load Balancer (VIP) für jede föderierte Server-Site Admin URL über Port 6443. Die Konfiguration eines dedizierten VIP für jede föderierte Server-Site Admin URL über Port 6443 erfordert das Öffnen dieses Ports für Administratoren und Publisher und Sie können den administrativen Zugriff über den Web Adaptor deaktivieren, wodurch zusätzliche Sicherheitskontrollen für die Organisation bereitgestellt werden.
Ich empfehle dieselbe URL wie die Services URL zu verwenden, da dies die Konfiguration vereinfacht. Der administrative Zugriff auf ArcGIS Server wird durch ArcGIS Enterprise Authentifizierung und Benutzerrollen gesteuert, ähnlich wie der administrative Zugriff auf das Portal z.B. ArcGIS Portal Directory (portaladmin) und Organisationseinstellungen. Um die Web Adaptor URL als Administrative URL zu verwenden, müssen Sie den administrativen Zugriff im Server Web Adaptor aktivieren.
Private portal URL
Dies ist eine interne URL, die von Ihren Server-Sites zur Kommunikation mit dem Portal verwendet wird. Diese muss ebenfalls auf einen Load Balancer zeigen und sollte vor der Föderation definiert werden. Wenn Sie Ihre Server-Sites föderieren bevor Sie privatePortalURL setzen, folgen Sie Schritt 8 und 9 im Thema Configure an existing deployment for hohe Verfügbarkeit, um die URL innerhalb Ihrer Bereitstellung zu aktualisieren. Ähnlich wie bei der administrativen URL kann dies dieselbe sein wie die öffentliche URL für das Portal (Webkontext-URL des Portals) oder es kann ein zweiter Load Balancer (VIP) über Port 7443 sein.
Zur Vereinfachung der Konfiguration empfehle ich, die öffentliche URL für das Portal als private Portal-URL zu verwenden. Wenn Sie sich entscheiden, einen dedizierten Load Balancer VIP über Port 7443 für die private Portal-URL zu verwenden, sollten Sie den Load Balancer so konfigurieren, dass er den Gesundheitszustand der Portalmaschinen überprüft.
Load Balancer-Konfiguration
Einstellungen zur Gesundheitsprüfung
Die wichtigste Funktion ist die Gesundheitsprüfung. Wie in der Dokumentation zur Gesundheitsprüfung des Portals beschrieben:
„Die Gesundheitsprüfung meldet, ob die antwortende Portal for ArcGIS-Maschine Anfragen empfangen und verarbeiten kann. Zum Beispiel meldet die URL der Gesundheitsprüfung vor der Erstellung des Portals, dass die Site nicht verfügbar ist, weil sie zu diesem Zeitpunkt keine Anfragen annehmen kann.“
ArcGIS Enterprise portal und server verfügen über Gesundheitsprüfungen.
Wenn Sie ArcGIS Web Adaptors verwenden, übernehmen diese die Durchführung der Gesundheitsprüfungen gegen das Portal und die Server. In diesem Fall können Sie den Load Balancer mit einer einfachen TCP/443-Gesundheitsprüfung oder einer statischen Seiten-Gesundheitsprüfung konfigurieren, mit Standard-Einstellungen für Timeout, Fehlerauslösung, Abfrageintervall und Schwellenwert für Gesundheit.
Wenn Sie den Load Balancer so konfigurieren, dass er direkt auf das Portal und/oder die Server zugreift, z. B. wenn Sie keine Web Adaptors in Ihrer Architektur einbinden oder wenn Sie eine dedizierte Load Balancer-URL für die private Portal-URL (Port 7443) oder die administrative URL des föderierten Servers (Port 6443) verwenden, sollten Sie den Load Balancer so einstellen, dass er den Gesundheitszustand der Portal- und Servermaschinen überprüft.
Es gibt einige wichtige Überlegungen zu den Einstellungen der Gesundheitsprüfung am Load Balancer. Die meisten Organisationen, die einen Load Balancer verwenden, nutzen eine statische Seite als ihre Gesundheitsprüfung (z. B. index.html), um festzustellen, ob der Webserver gesund ist. Dies ist eine statische Datei, die nur einen Festplattenzugriff erfordert. Außerdem neigen die meisten Webserver dazu, eher durch I/O als durch CPU begrenzt zu sein.
ArcGIS Server von Esri ist jedoch anders, da unsere Gesundheitsprüfung eine sehr geringe CPU-Leistung benötigt, weil unsere Prüfung mehr als nur ein Festplattenzugriff ist; die Software muss feststellen, ob bestimmte Prozesse funktionsfähig sind.
Bei Gesundheitsprüfungen gibt es einen Timeout-Wert für die Abfrage. Die meisten Load-Balancer-Administratoren setzen den Timeout-Wert sehr niedrig, da Festplattenzugriffe normalerweise sehr schnell sind (obwohl sie oft etwas Puffer für schlechte Netzwerklatenz lassen).
Bei Verwendung eines niedrigen Timeout-Werts mit ArcGIS Server und bei einer Multi-Maschinen-Konfiguration besteht die Möglichkeit, dass eine Maschine den niedrigen Timeout-Wert überschreitet und eine gesunde Maschine entfernt wird.
Esri empfiehlt einen höheren Timeout-Wert, idealerweise mindestens 5 Sekunden. Je nach System müssen Sie diesen Wert möglicherweise noch weiter erhöhen. Sie sollten Ihre Umgebung überwachen und diesen Wert entsprechend anpassen. Dies mag für Netzwerkadministratoren hoch erscheinen, da eine Gesundheitsprüfung auf einer einfachen Seite normalerweise weniger als 10 ms dauert (plus Netzwerklatenz).
Es ist jedoch entscheidend für die Load Balancer zu unterscheiden, wann eine Maschine nur langsam ist und wann sie wirklich ausgefallen und nicht mehr reagiert. Wenn das Portal oder der Server tatsächlich ausgefallen ist und überhaupt nicht auf einem Port hört, erkennen dies die meisten Load Balancer sogar schneller als in 5 Sekunden; dieser Timeout wirkt sich also nicht auf „normale“ Ausfälle aus, bei denen eine Maschine ausfällt.
Die zweite Überlegung ist der Fehlerauslöser – wie oft muss eine Abfrage fehlschlagen, bevor die Maschine aus dem Load Balancer entfernt wird.
Als Regel setzen Netzwerkadministratoren den Fehlerauslöser auf mehr als 1 Fehler, da sie nicht wollen, dass ein einzelner Netzwerkfehler das System lahmlegt. Wie oben erwähnt kann ein kleiner CPU-Spitzenwert (der bei ArcGIS Server-Systemen häufig vorkommt) einen Timeout verursachen; es ist nicht wünschenswert, eine Maschine wegen eines einzelnen CPU-Spitzenwerts auf einer einzelnen Maschine auszuschalten.
Esri hat umfangreiche interne Tests mit Load Balancern durchgeführt und festgestellt, dass eine Einstellung von 5 Fehlern die Anzahl falscher Positivmeldungen drastisch reduziert und gleichzeitig echte Ausfälle erkennt. Wir haben festgestellt, dass ein Wert von 3 immer noch anfällig für falsche Positivmeldungen war.
Die dritte Überlegung ist das Abfrageintervall. Esri hat herausgefunden, dass 30-Sekunden-Abfrageintervalle zusammen mit 5 Fehlern ein guter Kompromiss sind zwischen dem Erkennen echter Ausfälle und dem Ignorieren falscher Positivmeldungen.
Mit dieser Kombination beträgt der erwartete Wert (unter Verwendung eines statistischen Begriffs) oder mittlere Erkennungszeitpunkt 1 Minute und 15 Sekunden Ausfallzeit vor der Erkennung mit einem Worst Case von 2 Minuten und 30 Sekunden. Es ist möglich, eine niedrigere mittlere Erkennungszeit anzustreben, aber der Kompromiss besteht darin, falsche Positivmeldungen zu erhalten.
Wenn eine niedrigere mittlere Erkennungszeit bevorzugt wird, kann es erforderlich sein, die Kapazität zu erhöhen, sodass genügend Ressourcen vorhanden sind, um einen echten Ausfall auf einer Maschine sowie eine falsche Positivmeldung zu verkraften ohne die verbleibenden Maschinen zu überlasten.
Die letzte Einstellung bezüglich der Gesundheitsprüfungen ist der Schwellenwert für Gesundheit beim Load Balancer zum erneuten Senden von Anfragen. Esri hat keine Empfehlung dafür und wir haben keine großen Unterschiede bei diesem Wert beobachtet; typischerweise sehen wir 3 gesunde aufeinanderfolgende Abfragen vor dem Wiedereintritt.
Drosselung
Drosselungseinstellungen sind ebenfalls zu berücksichtigen. ArcGIS Server ist CPU-begrenzt, was bedeutet, dass die meiste Zeit einer Anfrage mit CPU-Nutzung verbracht wird statt mit Warten auf I/O.
Das bedeutet praktisch gesehen: Bei 8 Kernen kann ArcGIS Server etwas mehr als 8 gleichzeitige Anfragen verarbeiten. Wenn ArcGIS Server ausgelastet ist, beginnt er Anfragen in Warteschlangen zu stellen bis Hunderte von Anfragen in der Warteschlange stehen; nach dieser Schwelle lehnt er Verbindungen ab. Bei langer Rückstauung führt dies zu langen Wartezeiten; letztlich wird aber jede Anfrage bearbeitet.
ArcGIS Server verfügt über Einstellungen zur Steuerung dieses Verhaltens, sodass weniger dieser abgebrochenen Anfragen bearbeitet werden müssen; es ist jedoch auch Best Practice dies auf Load-Balancer-Ebene über dessen Drosselfähigkeit zu steuern.
Esri gibt keine numerische Empfehlung ab, da dies stark von der spezifischen Architektur und den eingehenden Anfragetypen abhängt; typischerweise wird jedoch bei einem deutlich niedrigeren Wert gedrosselt als Netzwerkadministratoren üblicherweise für Webserver tun würden.
Dies liegt außerhalb der Kontrolle des Netzwerkadministrators; Client-Anwendungen sollten so geschrieben sein, dass sie Drosselungsereignisse handhaben können und Wiederholungen in zunehmenden Zeitintervallen durchführen (z.B. beim ersten Mal sofort erneut versuchen, beim zweiten Mal eine Sekunde warten, beim dritten Versuch fünf Sekunden warten usw.).
Sticky Sessions
Esri empfiehlt Sticky Sessions nur in sehr seltenen Fällen. Sticky Sessions können theoretisch eine Maschine überlasten. Esri hat Lasttests mit Sticky Sessions durchgeführt um festzustellen ob unser GIS Server dadurch überlastet wird – dies war nicht der Fall. Wir haben auch keine Kundenbeschwerden erhalten. Da unsere Software zustandslos ist sehen wir jedoch keinen Nutzen in Sticky Sessions.
Layer 4 vs. Layer 7
Die letzte erwähnenswerte Einstellung betrifft die Frage ob der Load Balancer einen „Level 7“-Ansatz oder einen „Layer 4“-Ansatz verfolgt. Dies kann unter Netzwerkadministratoren diskutiert werden; unten finden Sie eine kurze Zusammenfassung mit Unterschieden und Vorteilen beider Ansätze.
Ein Layer-7-Load-Balancer versteht http und https; er entschlüsselt daher https-Inhalte und verschlüsselt sie anschließend wieder. Da er http und https versteht kann er Inhalte zwischenspeichern und so Anfragen an den Backend-Server reduzieren.
Ein Layer-4-Load-Balancer betrachtet den gesamten Verkehr als TCP-Pakete ohne deren Bedeutung zu kennen; sie könnten ftp-, https-, smtp-Pakete sein – das spielt für einen Layer-4-Load-Balancer keine Rolle. Daher muss er den http-Nutzlastinhalt nicht verstehen und kann schneller sein.
ArcGIS Server funktioniert mit beiden Ansätzen; es gibt keine Empfehlung für Netzwerkadministratoren bezüglich dieser Einstellung; aber einige Informationen sollte ein Administrator kennen.
ArcGIS Server-Nutzlasten können viel größer sein als HTML-Seiten sowie CSS- und JS-Inhalte (die tatsächliche Größe hängt oft von den vom Kunden verwendeten Daten ab). Das bedeutet mehr CPU-Belastung für einen Layer-7-Load-Balancer beim Entschlüsseln und Verschlüsseln pro Anfrage.
Zudem sind viele ArcGIS Server-Daten dynamisch und ändern sich häufig; standardmäßig verhindern Cache-Header das Caching beim Client und im Load Balancer. Wenn sich Daten kaum ändern und der Kunde einen Layer-7-Load-Balancer verwenden möchte kann er diese Cache-Einstellungen ändern und steuern.
Zusammenfassung der Empfehlungen
Gesundheitsprüfung
- Wenn Sie Ihre Load Balancer mit ArcGIS Web Adaptors konfigurieren können Sie den Load Balancer mit einer einfachen TCP/443-Gesundheitsprüfung oder einer statischen Seiten-Gesundheitsprüfung gegen die Webserver konfigurieren
- Wenn Sie den Load Balancer so konfigurieren möchten dass er direkt auf das Portal und/oder die Server zugreift (über Ports 6443 und 7443), verwenden Sie HTTPS-Gesundheitsprüfendpunkt:<\/SPAN>Portal:<\/SPAN>Anfrage: <\/SPAN>https:\/\/\/\/portaladmin\/healthCheck?f=json
ODER<\/SPAN>
<\/SPAN>https:\/\/:7443\/arcgis\/portaladmin\/healthCheck?f=json<\/A><\/SPAN><\/LI>Antwort: {"status":"success"}<\/SPAN><\/LI><\/UL><\/LI>Server:<\/SPAN>Anfrage: <\/SPAN>https:\/\/\/\/rest\/info\/healthCheck?f=json
ODER<\/SPAN>
<\/SPAN>https:\/\/:6443\/arcgis\/rest\/info\/healthCheck?f=json<\/A><\/SPAN><\/LI>Antwort: {"success":true}<\/SPAN><\/LI><\/UL><\/LI>Verwenden Sie einen höheren Timeout-Wert für die Gesundheitsprüfung, mindestens 5 Sekunden<\/SPAN><\/LI>Verwenden Sie einen Wert von 5 für den Fehlerauslöser<\/SPAN><\/LI>Verwenden Sie 30-Sekunden-Abfrageintervalle<\/SPAN><\/LI>Verwenden Sie 3 aufeinanderfolgende gesunde Abfragen, bevor Sie wieder beitreten<\/SPAN><\/LI><\/UL><\/LI><\/UL>Drosselung <\/SPAN><\/P>Verwenden Sie eine Drosselungseinstellung mit einem deutlich niedrigeren Wert als typische Webserver<\/SPAN><\/LI><\/UL>Sticky Sessions<\/SPAN><\/P>Verwenden Sie keine Sticky Sessions<\/SPAN><\/LI><\/UL>Zertifikate<\/SPAN><\/H1>ArcGIS Enterprise-Komponenten werden mit selbstsignierten Serverzertifikaten vorkonfiguriert geliefert, was es ermöglicht, die Software zunächst zu testen und Ihnen schnell zu bestätigen, dass Ihre Installation erfolgreich war. In fast allen Fällen sollte eine Organisation jedoch ein Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) anfordern und die Software so konfigurieren, dass sie dieses verwendet. Das Zertifikat kann von einer unternehmensinternen (internen) oder kommerziellen CA signiert sein. Kommerzielle CA (known-CA) müssen für extern auflösbare DNS verwendet werden, z.B. Load Balancer VIP DNS; interne Domänenzertifikate können für interne Server verwendet werden. <\/SPAN>
Für ArcGIS Enterprise-Systeme mit extern auflösbarem DNS, wenn die SSL-Methode des Load Balancers SSL-Passthrough ist (der Load Balancer entschlüsselt und verschlüsselt https-Inhalte nicht neu), ist kein Zertifikat erforderlich, und ein kommerzielles CA-Zertifikat muss auf den zugeordneten Servern installiert sein (z.B. Webserver, auf denen die Web Adaptor installiert sind). Wenn die SSL-Methode des Load Balancers SSL-Neuverschlüsselung ist, muss ein kommerzielles CA-Zertifikat auf dem Load Balancer installiert sein.<\/SPAN><\/SPAN><\/P>
.png)
