Mit der Workflow Manager-Lizenz verfügbar.
Ein Reverseproxyserver ist ein Computer, der in der Regel in einem Umkreisnetzwerk (auch demilitarisierte Zone [DMZ] oder überwachtes 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.
Sie können ArcGIS Workflow Manager Server optional so konfigurieren, dass der Reverseproxyserver Ihrer Organisation verwendet wird. Wenn Ihre Organisation keinen Reverseproxyserver verwendet oder Sie Workflow Manager nicht für die Verwendung eines solchen konfigurieren möchten, konfigurieren Sie Workflow Manager mit einem ArcGIS Enterprise-Portal.
Hinzufügen von Workflow Manager zu einem Reverseproxyserver
Workflow Manager erfordert ein pfadbasiertes Routing von Anforderungen zwischen den folgenden beiden Back-End-Ports: 6443 für ArcGIS Server-Verbindungen und 13443 für Workflow Manager-Verbindungen.
In ArcGIS Web Adaptor erfolgt das Routing im Rahmen der Standardkonfiguration, d. h. dass ein Reverseproxy auf Schicht 3/4 oder 7 im Netzwerkpfad dem ArcGIS Web Adaptor vorgeschaltet werden kann, um einen Client-Zugriff zu ermöglichen. Wenn Sie sich gegen die Verwendung von ArcGIS Web Adaptor im Netzwerkpfad entscheiden, ist für das Routing von Anforderungen zwischen Clients und Workflow Manager ein Reverseproxy auf Schicht 7 erforderlich.
Weitere Informationen über Typen von Load Balancern
Reverseproxy auf Schicht 3/4
Reverseproxys auf Schicht 3/4 lassen den Datenverkehr über das Websocket-Protokoll standardmäßig ohne zusätzliche Konfiguration durch. Reverseproxys auf Schicht 3/4 Layer erfordern eine ArcGIS Web Adaptor, damit der Datenverkehr ordnungsgemäß an die Back-End-Ziele gleitet werden kann.
Reverseproxy auf Schicht 7
In den folgenden Beispielen werden https://example.domain.com/server als Services-URL undFQDN1 und FQDN2 als Hostnamen für die Back-End-Ziele verwendet. Bei Verwendung eines einzelnen Workflow Manager-Computers gibt es nur einen Host in der Zielgruppe.
Konfiguration mit ArcGIS Web Adaptor im Netzwerkpfad
In diesem Beispiel wird auf den Back-End-Hosts FQDN1 und FQDN2 ein ArcGIS Web Adaptor namens server gehostet. Workflow Manager erfordert, dass der Websocket-Datenverkehr von verbindenden Clients aus den Reverseproxy passiert. Der Datenverkehr kann mittels eines Roundrobin-Algorithmus ausgeglichen werden, wobei an den Back-End-Zielen Systemdiagnosen konfiguriert werden müssen, um ein ordnungsgemäßes Passieren des Datenverkehrs durch den Webserver zu gewährleisten.
Nachstehend sehen Sie eine Konfigurationsvorlage für die Aktivierung des Websocket-Protokolls in einer Apache- httpd-Konfiguration:
RewriteEngine On
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteRule ^/server/workflow/(.*)? "balancer://wss_webadaptor_endpoint/$1" [P,L]
<Proxy balancer://wss_webadaptor_endpoint>
BalancerMember wss://FQDN1/server
BalancerMember wss://FQDN2/server
</Proxy>Im Folgenden wird https://example.domain.com/server als Services-URL und FQDN als Hostname des Computers für das Routing des Datenverkehrs an die Webadaptor-Hosts verwendet:
ProxyPass /server balancer://webadaptor_endpoint/server
ProxyPassReverse /server balancer://webadaptor_endpoint/server
<Proxy balancer://webadaptor_endpoint>
BalancerMember https://FQDN1/server
BalancerMember https://FQDN2/server
</Proxy>Konfiguration ohne ArcGIS Web Adaptor im Netzwerkpfad
Wenn Sie sich gegen die Verwendung von ArcGIS Web Adaptor im Netzwerkpfad entscheiden, ist für das Routing von Anforderungen zwischen Clients und Workflow Manager ein Reverseproxy auf Schicht 7 erforderlich. Der Header X-Forwarded-Host muss in den per Proxy übermittelten Anforderungen auf die Werte des Host-Headers des ursprünglichen Clients festgelegt werden.
Nachstehend sehen Sie eine Konfigurationsvorlage für die Aktivierung des Websocket-Protokolls in einer Apache- httpd-Konfiguration:
RewriteEngine On
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteRule ^/server/workflow/(.*)? "balancer://workflow_endpoint_wss/$1" [P,L]
<Proxy balancer://workflow_endpoint_wss>
BalancerMember wss://FQDN1:13443
BalancerMember wss://FQDN2:13443
</Proxy>Beim Einrichten der Back-End-Ziele müssen im Load Balancer pfadbasierte Regeln implementiert werden, damit der Datenverkehr an den ArcGIS Server- und Workflow Manager-Webserver gesendet werden kann.
Im Folgenden wird https://example.domain.com/server als Services-URL und FQDN als Hostname in der Beispielvorlage für pfadbasierte Routingregeln verwendet: Clientanforderungen an https://example.domain.com/server/workflow/* müssen an https://FQDN:13443/workflow umgeleitet werden, während Anforderungen an die oberste Ebene und sonstige untergeordneten Pfade von https://example.domain.com/server/* an https://FQDN:6443/arcgis geleitet werden müssen:
Nachstehend sehen Sie eine Konfigurationsvorlage zum Hinzufügen von pfadbasierten Routingregeln zur Weiterleitung von Clientanforderungen:
ProxyPass /server/workflow balancer://workflow_manager_endpoint/workflow
ProxyPassReverse /server/workflow balancer://workflow_manager_endpoint/workflow
ProxyPass /server balancer://server_endpoint/arcgis
ProxyPassReverse /server balancer://server_endpoint/arcgis
<Proxy balancer://server_endpoint>
BalancerMember https://FQDN1:6443
BalancerMember https://FQDN2:6443
</Proxy>
<Proxy balancer://workflow_manager_endpoint>
BalancerMember https://FQDN1:13443
BalancerMember https://FQDN2:13443
</Proxy>