Diese Konfiguration ist eine Variation der Bereitstellung eines einzelnen Computers mit hoher Verfügbarkeit (Aktiv/Passiv), in der die ständige Verteilung der Last auf alle Sites im Load-Balancer konfiguriert ist. In dieser Konfiguration gibt es keine Standby-Sites.
In dieser Architektur sind zwei oder mehr Sites hinter dem Load Balancer eines Drittanbieters konfiguriert, um die Kapazität der ArcGIS-Server-Bereitstellung zu erhöhen. Mit dieser Methode können Sie einige der Einschränkungen bezüglich der hohen Verfügbarkeit, die in den Bereitstellungsszenarios mit einem einzelnen Computer und einem einzelnen Computer mit Reverseproxyserver beschrieben werden, umgehen oder durch das Hinzufügen weiterer Computer hochskalieren.
Eine Skalierung und hohe Verfügbarkeit kann zwar durch die Verwendung von Sites mit mehreren Computern erreicht werden; es gibt jedoch einige Vorteile und Einschränkungen von Aktiv/Aktiv-Bereitstellungen, die nachstehend erörtert werden.
Generell besteht das Konzept der Aktiv/Aktiv-Architektur mit einem einzelnen Computer darin, eine Site mit einem einzelnen Computer zu klonen und unabhängige Instanzen davon hinter einen Load Balancer zu schalten. Technisch gesehen handelt es sich bei dieser Konfiguration nicht um eine Site mit mehreren Computern, da jede der Sites von den anderen unabhängig ist, aus einem einzelnen GIS-Server besteht und über einen eigenen lokalen Konfigurationsspeicher und eigene lokale Serververzeichnisse verfügt.
Bereitstellungen von ArcGIS-Server-Sites mit mehreren Computern erleichtern die Serveradministration in hohem Maße. Die Aktiv/Aktiv-Architektur kann jedoch in Szenarien verwendet werden, in denen die Anzahl und Einstellungen der Services genau definiert sind, statisch bleiben und bedeutende Performance-Vorteile gegenüber Sites mit mehreren Computern bieten können, besonders bei gecachten Kartenservices.
GIS-Server, Serververzeichnisse und Konfigurationsspeicher
Jeder GIS-Server muss über ein eigenes lokales Serververzeichnis sowie Cache-, Auftrags- und Systemverzeichnis verfügen. Dadurch wird eine bestmögliche Performance sichergestellt, und Interdependenzen werden auf ein Minimum reduziert. Umgekehrt muss/müssen das/die Ausgabeverzeichnis(se) für jede Site freigegeben werden. Weitere Informationen finden Sie nachfolgend unter Weitere Überlegungen.
Daten
In diesem Fall gelten dieselben Überlegungen, die bereits im Zusammenhang mit der Bereitstellung eines einzelnen Computers mit hoher Verfügbarkeit (Aktiv/Passiv) beschrieben wurden.
Reverseproxyserver
In dieser Konfiguration ist ein Load Balancer eines Drittanbieters erforderlich. Diese Komponente wird mindestens zur Verteilung der Last auf alle Sites eingesetzt. Load Balancer verfügen über verschiedene Konfigurationen zum Verteilen der Last, z. B. Roundrobin und Least Connection-Methode. Die Auswahl der richtigen Lastverteilung hängt von den gehosteten Services und deren Nutzungsmustern ab. Load Balancer bieten normalerweise auch Optionen zur Ausfallbehandlung. Beispielsweise können Sie im Load Balancer Regeln anwenden, die verhindern, dass Anforderungen an einen aufgrund eines Hardware- oder Netzwerkausfalls nicht verfügbaren Computer oder an einen bestimmten nicht verfügbaren ArcGIS-Server-Service weitergeleitet werden. Bei Verwendung von Sites mit einem einzigen Computer (wie hier beschrieben) werden Anforderungen, die an einen bestimmten Computer gesendet werden, auch tatsächlich von diesem Computer verarbeitet.
Normalerweise übernimmt der Load Balancer auch die Rolle des Reverseproxyservers, wie in der Bereitstellung auf einem einzelnen Computer mit Reverseproxyserver beschrieben. In einigen Szenarien wurde möglicherweise bereits unabhängig vom Load Balancer ein Reverseproxyserver konfiguriert.
Wenn Ihr Netzwerk-Load-Balancer eine Systemdiagnose unterstützt, können Sie den Endpunkt der Systemdiagnose von ArcGIS-Server verwenden, um zu ermitteln, ob die Site für den Empfang von Anforderungen verfügbar ist. Dies ist hilfreich, um schnell zu bestimmen, ob ein Software- oder Hardwarefehler in der Site vorliegt. Weitere Informationen finden Sie unter Systemdiagnose in der ArcGIS-REST-API.
Die Verwendung von ArcGIS Web Adaptor ist optional und bei diesem Szenario normalerweise nur erforderlich, wenn Sie die Vorteile der Authentifizierung auf Webebene nutzen möchten. Sie können ihn auf demselben Computer konfigurieren, auf dem sich auch der GIS-Server befindet, oder alternativ auf einem dedizierten Computer. In beiden Fällen müssen Sie bei der Verwendung von ArcGIS Web Adaptor einen separaten ArcGIS Web Adaptor für jede Site konfigurieren.
Weitere Überlegungen
Die Services in den Sites synchron halten
Im Gegensatz zu einer Site mit mehreren Computern muss bei dieser Konfiguration auf allen Sites hinter dem Load Balancer genau derselbe Inhalt gehostet werden, und alle Sites müssen dasselbe Sicherheitsmodell aufweisen. Sie müssen sicherstellen, dass alle Sites für den Load Balancer identisch aussehen.
Es gibt mehrere Möglichkeiten, mit denen Sie die ArcGIS-Server-Services auf den primären und Failover-Sites miteinander synchron halten können:
- Skripte: Der ArcGIS-Server umfasst eine administrative REST-API, mit der Sie Skripts für administrative Tasks erstellen können, z. B. zum Veröffentlichen von Services und Ändern der Sicherheitseinstellungen. Sie können eigene Skripte erstellen, um Änderungen durchgängig auf alle in der Bereitstellung enthaltenen GIS-Server anzuwenden. Skripte sind besonders hilfreich, wenn Sie kleinere Anpassungen vornehmen müssen, etwa zum Ändern oder Überschreiben der Sicherheit eines Service. Weitere Informationen finden Sie im Thema Skripterstellung für die ArcGIS-Server-Verwaltung.
- Virtualisierung: Wenn Sie in einer virtuellen Umgebung arbeiten, können Vorlagen virtueller Computer erstellt und zum Einrichten neuer Sites verwendet werden. Jede Vorlage enthält eine Kopie der erforderlichen Daten für GIS-Services (es sei denn, es wird eine Datenbank verwendet). Mit der Vorlage werden ebenfalls alle Services veröffentlicht und konfiguriert. Wenn Änderungen erforderlich sind (z. B. beim Hinzufügen oder Aktualisieren vorhandener Services), kann eine neue Vorlage erstellt werden, um später neue virtuelle Computer einzurichten, die den vom Load Balancer verwendeten vorhandenen Pool von GIS-Servercomputern ersetzen. Vorlagen für virtuelle Computer können auch verwendet werden, um schnell veraltete GIS-Server wiederherzustellen.
Für die Anwendung von Änderungen in Ihren Sites wird bei diesem Bereitstellungsmuster die folgende Vorgehensweise empfohlen:
- Administrative Änderungen werden zuerst für eine Site im Standby-Modus vorgenommen. Fügen Sie beispielsweise einen neuen Service hinzu oder ändern Sie die Sicherheit eines anderen Service in einer Site, die keine aktiven Anforderungen verarbeitet. Auf diese Weise wird sichergestellt, dass keinerlei Auswirkungen auf Anwendungen auftreten, die die primäre Site verwenden.
- Konfigurieren Sie den Load Balancer manuell, um alle Anforderungen an die Standby-Site weiterzuleiten, auf der die Änderungen vorgenommen wurden.
- Wenden Sie dieselben Änderungen auf die nicht aktive Site an.
- Kehren Sie den Vorgang auf dem Load Balancer wieder um, sodass Anforderungen wieder zur ursprünglichen primären Site weitergeleitet werden, und belassen Sie die Standby-Site im Standby-Modus.
In der vorstehenden Vorgehensweise beschriebene Änderungen an der Site können manuell durch ArcGIS Server Manager, Skripte oder virtuelle Images angewendet werden.
Ausgabeverzeichnis freigeben
Manche Service-Operationen von ArcGIS for Server referenzieren Ressourcen in einem oder mehreren Ausgabeverzeichnissen. Beispielsweise können Kartenservices Bilder in ein Ausgabeverzeichnis schreiben und diese über eine URL in der Anforderung/Antwort referenzieren. Damit das Bild beim jeweiligen Client auch wirklich ankommt, müssen alle Sites in Ihrer Aktiv/Aktiv-Konfiguration auf dasselbe Ausgabeverzeichnis verweisen. Dies lässt sich dadurch erreichen, dass die Ausgabeverzeichnisse auf einer Netzwerkressource gespeichert und für Ihre Sites freigegeben werden.
Nachfolgend sind Service-Operationen aufgelistet, die Ausgabeverzeichnisse verwenden:
- Erstellen eines Feature-Service-Replikats (Feature-Service)
- Herunterladen eines Raster-Images (Image-Service)
- Abrufen von Mobile-Service- und Mobile-Layer-Ressourcen (Mobile-Funktion in einem Kartenservice)
- Exportieren eines Kartenbildes (Kartenservice)
- Exportieren eines Schematic-Diagramms (Schematics-Funktion in einem Kartenservice)
- Exportieren einer Webkarte (Geoverarbeitungs-Service)
Asynchrone Ausführung von Geoverarbeitungsservices
ArcGIS for Server Geoverarbeitungsservices unterstützen zwei Ausführungsmodi: synchron und asynchron. Die synchrone Ausführung geht nach einem statusunabhängigen Anforderungs-/Antwort-Muster vor und wird in einer Aktiv/Aktiv-Konfiguration vollständig unterstützt. Bei der asynchronen Ausführung wird ein statusabhängiges Anforderungs-/Antwort-Muster befolgt, was der Standard ist. Wenn Sie die asynchrone Ausführung in einer Aktiv/Aktiv-Konfiguration nutzen möchten, sollten Sie Folgendes berücksichtigen:
- Beim Senden eines asynchronen Geoverarbeitungsauftrags wird eine Auftrags-ID zurückgegeben, die auf den gesendeten Auftrag und die zugehörigen Ausgaben verweist. Nur die ArcGIS-Server-Site, die die ursprüngliche Anforderung empfängt, kann diese ID erkennen. Aus diesem Grund müssen Sie in der Aktiv/Aktiv-Konfiguration die Affinität in Ihrem Load Balancer definieren (auch als "Sticky-Sitzungen" bezeichnet), wenn Sie die asynchrone Ausführung verwenden möchten. Auf diese Weise kann hohe Verfügbarkeit für asynchrone Geoverarbeitungs- und Kartenservice-Ausgaben bereitgestellt werden. Konsultieren Sie den Hersteller Ihres Load Balancers, um die Auswirkungen aktivierter "Sticky-Sitzungen" abzuklären.
- Sollte Ihr Geoverarbeitungsservice das Rendern von Ergebnissen durch Kartenservices nicht unterstützen und wurden keine Ergebnisse vom Typ "Datei" definiert, können Sie für Ihre Geoverarbeitungsservices die synchrone Ausführung wählen. Hierfür werden im Load Balancer keine "Sticky-Sitzungen" benötigt.
Verwenden der tokenbasierten Sicherheit
Bei Verwendung der tokenbasierten Authentifizierung – auch als Authentifizierung auf GIS-Ebene bezeichnet – ist wichtig, dass alle Sites in dieser Konfiguration genau denselben freigegebenen Tokenschlüssel verwenden. Andernfalls sind für einen Computer generierte Token ungültig, wenn sie für den anderen Computer verwendet werden. Informationen zum Duplizieren der freigegebenen Tokenschlüssel auf mehrere Sites finden Sie unter ArcGIS-Token und Bearbeiten von Token-Einstellungen in Manager.
Vorteile
- Einfaches Konzept. Aufgrund minimaler Interdependenzen zwischen GIS-Servern ist es einfach, veraltete oder fehlerhafte Computer zu ersetzen, Upgrades anzuwenden oder Computer nach Bedarf zum GIS-Serverpool hinzuzufügen oder daraus zu entfernen, ohne die Services zu unterbrechen oder Anforderungen abzubrechen.
- Wenn Kartenkacheln lokal auf den einzelnen Computern gespeichert werden, bietet diese Konfiguration bedeutende Performance-Vorteile im Vergleich zu Sites mit mehreren Computern. Tatsächlich ist diese Konfiguration ideal geeignet, wenn Sie die Kapazität gecachter Kartenservices erhöhen möchten.
Nachteile
- Sie müssen dafür sorgen, dass alle Sites miteinander synchronisiert sind. Dadurch entsteht administrativer Mehraufwand, der dieses Bereitstellungskonzept schnell unpraktisch werden lässt, wenn es viele Computer oder Services/Caches gibt, die sich regelmäßig ändern.
- Die Vorgehensweise im Hinblick Load Balancern von Drittanbietern muss verstanden werden.