Einrichten eines Reverseproxyservers mit ArcGIS Notebook Server

Ein Reverseproxyserver ist ein Computer, der in einem Umkreisnetzwerk (auch demilitarisierte Zone [DMZ] oder überprüftes Subnetz genannt) bereitgestellt wird, das Anforderungen aus dem Internet bearbeitet und diese an die Computer im internen Netzwerk weiterleitet. Bei der Weiterleitung von Anforderungen maskiert der Reverseproxyserver die Computer hinter der Firewall der Organisation und schützt interne Computer vor direkten Angriffen durch Internetbenutzer. Um das interne Netzwerk vor externen Benutzern zu schützen, können zusätzliche Sicherheitsfunktionen in den Reverseproxyserver implementiert werden.

Sie können Ihre ArcGIS Notebook Server-Site so konfigurieren, dass der Reverseproxyserver Ihrer Organisation verwendet wird. Diese Angabe ist optional. Wenn Ihre Organisation keinen Reverseproxy verwendet oder Sie Ihre ArcGIS Notebook Server-Site nicht dafür konfigurieren möchten, dann können Sie mit dem Konfigurieren Ihrer Site mit einem Portal fortfahren.

Hinzufügen von ArcGIS Notebook Server zu einem Reverseproxyserver

Der Reverseproxyserver Ihrer Organisation muss für die Kommunikation mit ArcGIS Web Adaptor konfiguriert werden, indem den Proxy-Direktiven die entsprechenden URLs hinzugefügt werden.

Wenn Sie beispielsweise Apache als Reverseproxyserver verwenden, müssen Sie die ArcGIS Web Adaptor-URL zu den ProxyPass-Direktiven in der Apache-Webserver-Konfigurationsdatei httpd.conf hinzufügen:

ProxyPass /notebook https://notebookserver.domain.com/notebook
ProxyPassReverse /notebook https://notebookserver.domain.com/notebook

Die meisten Reverseproxyserver weisen ein konfigurierbares Zeitlimit für Clientverbindungen auf. Die von ArcGIS Notebook Server für die Kommunikation mit dem Python-Kernel verwendeten WebSocket-Verbindungen werden getrennt, wenn das Verbindungszeitlimit erreicht wird. Im Notebook wird dann eine Benachrichtigung angezeigt. Geschieht dies in einem regelmäßigen Intervall, beispielsweise alle 1, 3 oder 5 Minuten nach einer erneuten Verbindung mit dem Kernel, sollten die Verbindungszeitlimits für den Netzwerkpfad untersucht und entsprechend erhöht werden.

Festlegen der Eigenschaft WebContextURL

Wenn Sie einen Reverseproxyserver verwenden und die URL zu Ihrer Site nicht mit der Standardzeichenfolge /arcgis (alle in Kleinbuchstaben) endet, sollten Sie auch die WebContextURL-Eigenschaft von ArcGIS Notebook Server festlegen. Damit kann ArcGIS Notebook Server die richtigen URLs für die Ressourcen erstellen, die an den Endbenutzer gesendet werden.

Hinweis:

Verwenden Sie die Eigenschaft WebContextURL, um die ArcGIS Notebook Server-URL so festzulegen, dass sie der URL der zugehörigen Instanz von ArcGIS Web Adaptor (wie zum Beispiel /notebook) entspricht.

Führen Sie die folgenden Schritte aus, um die Eigenschaft WebContextURL zu ändern:

1. Melden Sie sich beim ArcGIS Notebook Server-Administratorverzeichnis unter https://notebookserver.domain.com:11443/arcgis/admin als Benutzer mit Administratorberechtigungen an.
2. Klicken Sie auf System > Eigenschaften > Update.
3. Geben Sie in das Textfeld Properties das folgende JSON an und ersetzen Sie dabei Ihre eigene ArcGIS Notebook Server-URL, die Benutzern außerhalb der Firewall der Organisation angezeigt wird:

   {
      "WebContextURL": "https://notebookserver.domain.com/notebook"
   }

4. Klicken Sie auf Aktualisieren.
5. Starten Sie ArcGIS Notebook Server erneut. Unter Windows starten Sie den ArcGIS Server-Windows-Service neu.

Reverseproxykopfzeilen und ArcGIS Notebook Server

Beim Integrieren des Reverseproxys in ArcGIS Web Adaptor muss die folgende Eigenschaft in der vom Reverseproxyserver gesendeten Kopfzeile festgelegt sein:

X-Forwarded-Host=<FQDN of reverse proxy server>

Wenn diese Eigenschaft in der Kopfzeile festgelegt ist, gibt ArcGIS Web Adaptor Anforderungen an den Reverseproxyserver zurück, die mit der URL des Reverseproxyservers übereinstimmen. Eine Anforderung an das ArcGIS Notebook Server-Services-Verzeichnis (https://reverseproxy.domain.com/arcgis/rest/services) wird beispielsweise als dieselbe URL an den Client zurückgegeben.

Wenn die Kopfzeileneigenschaft X-Forwarded-Host nicht festgelegt ist, gibt ArcGIS Web Adaptor möglicherweise die URL des internen Computers zurück, an den die Anforderung gerichtet war (z. B. https://notebookserver.domain.com/arcgis/rest/services statt https://reverseproxy.domain.com/arcgis/rest/services). Dies ist problematisch, da Clients nicht auf diese URL zugreifen können (im Allgemeinen als Browserfehler 404 angegeben). Zudem erhält der Client möglicherweise Informationen zu dem internen Computer.

Bei der Problembehandlung im Zusammenhang mit der Kommunikation zwischen Clients und ArcGIS Web Adaptor wird empfohlen, die Kopfzeileneigenschaft X-Forwarded-Host im Reverseproxyserver festzulegen, da dies häufig die Ursache von Kommunikationsfehlern darstellt. Das Verfahren zum Festlegen dieser Kopfzeile ist je nach Implementierung des Reverseproxyservers unterschiedlich.

Hilfe zum Weiterleiten der ursprünglichen Host-Kopfzeile finden Sie in der Produktdokumentation zu Ihrem Reverseproxyserver.

Konfigurieren des Reverseproxyservers für eine ArcGIS Notebook Server-Site mit hoher Verfügbarkeit

Wenn Sie einen Reverseproxyserver implementieren, der mehrere Backend-Ziele mit ArcGIS Web Adaptor aufweist, die bei einer einzigen ArcGIS Notebook Server-Site registriert sind, müssen weitere Überlegungen berücksichtigt werden.

ArcGIS Notebook Server nutzt WebSocket-Verbindungen für die Kommunikation mit dem Python-Kernel. Diese WebSocket-Verbindungen erstellen eine zustandsbehaftete Sitzung, die in der Reverseproxy-Konfiguration verwaltet werden muss. Dieses Verhalten wird auch als "Session Stickiness" bezeichnet, und es kann nur mit einem Load Balancer auf Layer 7 (Anwendung) erreicht werden.

Richtige Session Stickiness kann mit Apache wie folgt erreicht werden:

Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED

<Proxy balancer://web_adaptors_https>
    BalancerMember https://notebook1.domain.com:443 route=notebook1
    BalancerMember https://notebook2.domain.com:443 route=notebook2
    BalancerMember https://notebook3.domain.com:443 route=notebook3

    ProxySet lbmethod=byrequests
    ProxySet stickysession=ROUTEID
</Proxy>

Zudem ist es wichtig, dass die sicheren WebSocket-Verbindungen (WSS) per Proxy an die gleichen Backend-Ziele geleitet werden:

<Proxy balancer://web_adaptors_wss>
    BalancerMember wss://notebook1.domain.com:443 route=notebook1
    BalancerMember wss://notebook2.domain.com:443 route=notebook2
    BalancerMember wss://notebook3.domain.com:443 route=notebook3

    ProxySet lbmethod=byrequests
    ProxySet stickysession=ROUTEID
</Proxy>