Selon la méthode d’authentification que vous utilisez avec votre organisation et selon que vous autorisez ou non l’accès à partir de l’autre côté de votre pare-feu, la manière dont vous implémentez un déploiement ArcGIS Enterprise haute disponibilité varie.
Les conditions suivantes sont vraies pour tous les scénarios décrits dans cette rubrique :
- Les machines du portail (Portal1 et Portal2) stockent du contenu dans le même répertoire, qui a été placé sur un serveur de fichiers haute disponibilité.
- Les machines GIS Server (HostingServer1 et HostingServer2) sur le site de serveur d’hébergement partagent des répertoires de serveur et un magasin de configuration, qui ont été placés sur un serveur de fichiers haute disponibilité.
- Un data store relationnel haute disponibilité est composé d’une machine principale (DataStore1) et d’une machine de secours (DataStore2) qui sont inscrites auprès du site de serveur d’hébergement. ArcGIS Data Store comporte un mécanisme de reprise après incident intégré par lequel le data store relationnel de secours devient la machine de data store principale en cas d’échec de la machine principale. Comme le data store vérifie la condition des machines ArcGIS Server pour le site auprès duquel il est inscrit, vous pouvez configurer le data store via l’URL de n’importe laquelle des machines ArcGIS Server.
- Les protocoles HTTPS et HTTP sont activés pour Portal for ArcGIS comme pour ArcGIS Server. Si HTTP est désactivé pour tous les composants, les ports HTTP (80, 6080 et 7080) peuvent être supprimés des exemples. Les URL d’administration exigent des communications HTTPS.
- Pour les architectures qui impliquent des équilibreurs de charge, des contrôles d’intégrité ont été configurés afin de déterminer la disponibilité des cibles en arrière-plan et répartir le trafic à l’aide d’un algorithme en rotation. Dans cet exemple, les hôtes loadbalancer.example.com et internalloadbalancer.example.com sont utilisés dans les diagrammes, mais ils peuvent être remplacés par un alias DNS attribué à l’un ou l’autre des composants via un serveur DNS interne ou externe.
Les différences entre les protocoles d’authentification et de communication client-portail sont décrites dans les sections suivantes. Vous trouverez plus d’informations sur les URL utilisées dans un déploiement haute disponibilité dans Haute disponibilité dans la rubrique ArcGIS Enterprise.
Les utilisateurs intégrés et les clients ont accès au portail via les ports 80 et 443
Dans ce scénario, l'authentification du portail utilise les utilisateurs intégrés et toutes les communications entre les clients (en haut du diagramme) et le portail ont lieu à l'intérieur du pare-feu.
Dans l’exemple, les clients accèdent à l’organisation par l’équilibreur de charge via l’URL de l’organisation (dans ce cas, https://loadbalancer.example.com/portal/home/) et le répertoire REST du site ArcGIS Server est accessible via https://loadbalancer.example.com/server/rest/services. Le portail haute disponibilité (deux machines Portal for ArcGIS, Portal1 et Portal2) communique avec son site de serveur d’hébergement haute disponibilité via l’URL d’administration (https://loadbalancer.example.com/server/admin) définie durant la fédération. Les machines dans le site de serveur d’hébergement (HostingServer1 et HostingServer2) communiquent avec le portail par la même extrémité que les clients (https://loadbalancer.example.com/portal) grâce à l’URL de portail privée définie dans les propriétés système du portail. L’URL du répertoire d’administration ArcGIS Server et l’URL de portail privée passent toutes les deux par l’équilibreur de charge (LoadBalancer) pour tenir compte de la redondance. Si une machine Portal for ArcGIS tombe en panne ou est inaccessible, le serveur d’hébergement peut toujours communiquer avec la machine restante, car l’équilibreur de charge dirige le trafic vers cette machine. De même, si l’une des machines du serveur d’hébergement tombe en panne ou est inaccessible, l’équilibreur de charge continue de diriger le trafic des machines Portal for ArcGIS vers la machine ArcGIS Server restante.
Utilisateurs intégrés avec accès public au portail
Dans ce scénario, l’authentification du portail fait appel aux utilisateurs intégrés ; certains clients, au moins, ont accès au portail depuis l’autre côté du pare-feu. L’accès administratif de l’extérieur du pare-feu doit être désactivé.
Les clients accèdent à l’organisation et à l’extrémité REST ArcGIS Server par l’équilibreur de charge situé à l’extérieur du pare-feu (LoadBalancer), en général par le biais d’un alias DNS attribué à loadbalancer.example.com. Le portail communique avec le site de serveur d’hébergement par un deuxième équilibreur de charge (InternalLoadBalancer) à l’intérieur du pare-feu (https://internalloadbalancer.example.com:6443/arcgis, les lignes vertes dans le diagramme). Le serveur d’hébergement communique avec le portail via l’URL de portail privée, qui passe aussi par InternalLoadBalancer (https://internalloadbalancer.example.com:7443/arcgis, les lignes orange dans le diagramme) pour que la communication n’ait pas à passer par le pare-feu. Si une machine du portail tombe en panne, le serveur d’hébergement peut toujours communiquer avec la machine de portail restante, car l’équilibreur de charge interne envoie des requêtes à cette dernière. De même, si l’une des machines GIS Server tombe en panne, l’équilibreur de charge interne continue de diriger le trafic du portail vers la machine GIS Server restante.
L’accès direct des clients situés à l’extérieur du pare-feu au site GIS Server passe également par l’équilibreur de charge (LoadBalancer) à l’extérieur du pare-feu (ligne rouge dans le diagramme).
L’accès administrateur au répertoire administrateur ArcGIS Server et à ArcGIS Server Manager est bloqué en définissant des règles sur l’équilibreur de charge (LoadBalancer) à l’extérieur du pare-feu (ligne rouge dans le diagramme).
Authentification IWA ou LDAP avec accès interne des clients
Dans ce scénario, les utilisateurs du portail s’authentifient selon l’authentification Windows intégrée (IWA) ou l’authentification LDAP (Lightweight Access Directory Protocol) et tous les clients qui accèdent au portail se trouvent à l’intérieur du pare-feu.
Lorsque l’accès public au portail n’est pas requis, mais que les clients vont s’authentifier auprès du portail selon l’authentification IWA ou LDAP, chaque machine du portail haute disponibilité requiert un Web Adaptor (WebAdaptor1 et WebAdaptor2). L’équilibreur de charge (LoadBalancer) envoie le trafic aux instances Web Adaptor, qui répartissent ensuite les requêtes entre les deux machines du portail (Portal1 et Portal2). Toute communication des machines ArcGIS Server vers les machines Portal for ArcGIS doivent passer outre le défi de l’authentification au niveau du Web à l’aide du Web Adaptor. Par conséquent, l’équilibreur de charge est configuré de façon à écouter les ports 7080 et 7443 et à ce que le trafic soit envoyé directement au portail sur les ports 7080 ou 7443 via l’URL de portail privée.
Comme l’accès public au portail n’est pas requis, l’équilibreur de charge est utilisé pour l’URL des services et de l’administration pour le site d’hébergement. L’URL de portail privée est https://internalloadbalancer.example.com:7443/arcgis. Les machines du site d’hébergement communiquent avec les machines du portail par cette URL (les lignes orange dans le diagramme). L’URL de l’organisation est https://loadbalancer.example.com/portal, et l’URL des services et de l’administration pour le site d’hébergement correspondent toutes deux à https://loadbalancer.example.com/server.
Authentification SAML ou ADFS avec accès public au portail
Dans ce scénario, les utilisateurs s’authentifient à l’aide de l’authentification SAML (Security Assertion Markup Language) ou ADFS (Active Directory Federation Services), mais certains clients qui accèdent à l’organisation se situent à l’extérieur du pare-feu. Dans ce cas, vous devez désactiver l’accès administratif aux machines ArcGIS Server du site de serveur d’hébergement à des fins de sécurité. La section ci-après décrit les deux configurations qui permettent cela.
Remarque :
L’utilisation de l’authentification SAML ou ADFS pour votre portail rend inutile la configuration d’adaptateurs web avec le portail. Vous pouvez utiliser ArcGIS Web Adaptor avec votre portail dans les deux scénarios suivants, mais cela n’apporte aucun avantage fonctionnel à la configuration.
Sécuriser un portail d’accès public à l’aide des règles définies dans le système d’équilibrage de la charge
Dans ce scénario, les clients se connectent via l’équilibreur de charge (LoadBalancer) à l’extérieur du pare-feu (ligne rouge dans le diagramme), qui envoie le trafic directement aux deux machines du portail (Portal1 et Portal2) sur les ports 7443 et 7080 et aux deux machines GIS Server (HostingServer1 et HostingServer2) sur les ports 6443 et 6080. Les règles de l’équilibreur de charge bloquent l’accès à l’URL du répertoire administrateur ArcGIS Server et de ArcGIS Server Manager.
Le système d’équilibrage de la charge en dehors du pare-feu ne peut pas communiquer via les ports 6080, 6443, 7080 ou 7443. Un autre équilibreur de charge (InternalLoadBalancer) est configuré à l’intérieur du pare-feu afin d’activer les communications entre le portail et le serveur d’hébergement. Le portail communiquera avec le serveur d’hébergement par l’URL définie comme URL d’administration lors de la fédération (lignes vertes dans le diagramme) et le serveur d’hébergement communiquera avec le portail par l’URL de portail privée (lignes orange dans le diagramme) de sorte que la communication n’ait pas à passer par le pare-feu. L’équilibreur de charge interne garantit la redondance en cas de défaillance de l’une des machines GIS Server ou de l’une des machines du portail.
Dans ce scénario, l’URL https://internalloadbalancer.example.com:7443/arcgis est l’URL du portail privé. L’URL https://internalloadbalancer.example.com:6443/arcgis est l’URL d’administration du site de serveur ArcGIS Server utilisée pendant l’opération de fédération.
Sécuriser un portail d’accès public à l’aide des Web Adaptors sur le site GIS Server
Dans ce scénario, les clients se connectent via l’équilibreur de charge (LoadBalancer) à l’extérieur du pare-feu (ligne rouge dans le diagramme), qui envoie le trafic directement aux deux machines du portail (Portal1 et Portal2) sur les ports 7443 et 7080 et aux deux Web Adaptors (WebAdaptor1 et Webadaptor2) configurés avec les machines ArcGIS Server (HostingServer1 et HostingServer2). Un autre équilibreur de charge (InternalLoadBalancer) gère le trafic entre les machines du portail et celles du site de serveur d’hébergement et assure la redondance si l’une des machines GIS Server ou des machines du portail présente une défaillance.
Les clients accèdent au portail via l’équilibreur de charge (LoadBalancer) https://loadbalancer.example.com/portal/home/, qui envoie le trafic au deux machines du portail via les ports 7080 et 7443. Puisque le portail est configuré avec l’authentification SAML ou ADFS, le fournisseur SAML ou ADFS authentifie les utilisateurs lorsqu’ils accèdent au portail.
Les clients peuvent accéder au site de serveur d’hébergement via l’équilibreur de charge (LoadBalancer) à l’extérieur du pare-feu, qui envoie le trafic aux Web Adaptors GIS Server (WebAdaptor1 et WebAdaptor2). Les Web Adaptors transmettent le trafic aux machines GIS Server par les ports 6080 et 6443.
Les machines ArcGIS Server communiquent avec le portail par l’URL de portail privée (https://internalloadbalancer.example.com:7443/arcgis, les lignes orange dans le diagramme) pour que la communication n’ait pas à passer par le pare-feu. Le site de serveur d’hébergement est fédéré sur le portail avec https://loadbalancer.example.com/server comme URL des services. Ce trafic passe par les Web Adaptors (WebAdaptor1 et WebAdaptor2), qui sont configurés pour bloquer l’accès de l’administrateur à ArcGIS Server Manager et au répertoire administrateur ArcGIS Server. Un deuxième équilibreur de charge (InternalLoadBalancer) est utilisé pour accéder à l’URL d’administration (https://internalloadbalancer.example.com:6443/arcgis, les lignes vertes dans le diagramme) définie durant la fédération afin d’assurer la redondance.
Vous avez un commentaire à formuler concernant cette rubrique ?