Skip To Content

Déploiement sur une seule machine haute disponibilité (actif-actif)

Cette configuration représente une variation du déploiement sur une seule machine haute disponibilité (actif-passif), dans le cadre duquel le système d'équilibrage de la charge est configuré pour répartir constamment la charge sur tous les sites. Il n'existe aucun site de secours dans cette configuration.

Cette architecture implique la configuration d'au moins deux sites derrière un système d'équilibre de la charge tiers afin d'augmenter la capacité de votre déploiement ArcGIS Server. Vous pouvez utiliser cette technique pour compenser les limites en termes de haute disponibilité décrites dans les scénarios de déploiement sur une seule machine et de déploiement sur une seule machine avec un serveur proxy inverse ou pour ajouter des machines.

Alors que vous pouvez augmenter votre capacité et bénéficier d'une haute disponibilité en utilisant des sites à plusieurs machines, les déploiements de type actif-actif présentent des avantages et des inconvénients que nous allons exposer ci-dessous.

Déploiement de type actif-actif avec deux sites
Déploiement de type actif-actif avec deux sites. Les administrateurs de connectent à chaque site séparément. Les deux sites possèdent un exemplaire identique des répertoires du serveur et de l'emplacement de configuration.

Le concept à l'origine d'une architecture de type actif-actif à une seule machine consiste à cloner le site à une seule machine et à en placer des instances indépendantes derrière un système d'équilibrage de la charge. Techniquement parlant, cette configuration ne peut pas être assimilée à un site à plusieurs machines, car les sites sont indépendants les uns des autres, composés d'une seule machine ArcGIS Server, et ils possèdent chacun leur emplacement de configuration et leurs répertoires du serveur en local.

Le déploiement d'un site ArcGIS Server sur plusieurs machines simplifie considérablement l'administration du serveur. Toutefois, l'architecture de type actif-actif peut être utilisée dans des scénarios où le nombre et les paramètres des services sont bien définis et restent statiques, ce qui représente un avantage considérable en termes de performances par rapport aux sites à plusieurs machines, et ceci particulièrement pour des services de cartes en cache.

Machines ArcGIS Server, répertoires du serveur et emplacement de configuration

Chaque machine ArcGIS Server doit posséder en local son propre emplacement de configuration et ses répertoires cache, de tâches et système. Les performances sont ainsi optimisées et les interdépendances minimisées. A l'inverse, le ou les répertoire(s) en sortie doivent être partagés entre chaque site. Pour plus de détails, consultez les autres remarques ci-dessous.

Données

Pour plus d'informations, reportez-vous à la rubrique Déploiement sur une seule machine haute disponibilité (actif-passif).

serveur proxy inverse

Dans cette configuration, un système d'équilibrage de la charge est requis. Ce composant servira au moins à répartir la charge sur tous les sites. Les systèmes d'équilibrage de la charge présentent des configurations diverses pour répartir la charge, telles que la rotation et le nombre de connexions le moins élevé. Le choix de la distribution appropriée de la charge dépend des services hébergés et de leurs modes d'utilisation. Les systèmes d'équilibrage de la charge utilisent habituellement plusieurs options de gestion des défaillances. Par exemple, vous pouvez définir des règles dans le système d'équilibrage de la charge pour l'empêcher de transférer des requêtes à une machine indisponible en raison d'une défaillance matérielle ou réseau ou à un service ArcGIS Server spécifique qui n'est pas disponible. Si vous utilisez des sites à une seule machine comme l'indique ce scénario, les requêtes envoyées à une machine spécifique seront systématiquement traitées par cette machine.

Habituellement, le système d'équilibrage de la charge assume également le rôle de serveur proxy inverse comme le décrit la rubrique Déploiement sur une seule machine avec un serveur proxy inverse. Dans certains scénarios, vous pourrez avoir configuré un serveur proxy inverse indépendamment du système d'équilibrage de la charge.

Si votre système d'équilibrage de la charge réseau prend en charge une fonction de contrôle de l'intégrité, vous pouvez utiliser l'extrémité de contrôle de l'intégrité d'ArcGIS Server pour déterminer si le site peut recevoir des requêtes. Ceci est utile pour déterminer rapidement si le site rencontre une défaillance logicielle ou matérielle. Pour plus d'informations, reportez-vous à Contrôle de l'intégrité dans l'API REST d'ArcGIS.

L'utilisation d'ArcGIS Web Adaptor est facultative et habituellement nécessaire uniquement pour ce scénario si vous souhaitez utiliser l'authentification au niveau du Web. Vous pouvez le configurer sur la même machine que votre ArcGIS Server ou sur une machine dédiée. Dans ce cas, si vous utilisez ArcGIS Web Adaptor, vous devez en configurer une instance distincte sur chaque site.

Autres remarques

Synchronisation des services de vos sites

Contrairement à un site à plusieurs machines authentique, cette configuration exige que tous les sites derrière le système d'équilibrage de la charge hébergent exactement le même contenu et adoptent le même modèle de sécurité. Vous devez vous assurer que tous les sites semblent identiques au système d'équilibrage de la charge.

Plusieurs techniques permettent de synchroniser les services ArcGIS Server sur les sites principaux et de reprise :

  • Génération de scripts : ArcGIS Server intègre une API d'administration RESTful qui permet de rédiger des tâches administratives, telles que la publication de services et la modification de leurs paramètres de sécurité. Vous pouvez créer vos scripts pour appliquer des modifications cohérentes à toutes les machines ArcGIS Server de votre déploiement. Les scripts sont très utiles lorsque vous devez procéder à des ajustements mineurs, tels que la modification des paramètres de sécurité d'un service ou le remplacement de ce dernier. Pour plus d'informations, reportez-vous à la rubrique Ecriture de scripts ArcGIS Server d'administration.
  • Virtualisation : si votre environnement est virtuel, vous pouvez créer des modèles de machines virtuelles et les utiliser pour lancer de nouveaux sites. Chaque modèle disposera d'un exemplaire des données requises par les services SIG (à moins qu'une base de données ne soit utilisée). Le modèle permettra également de publier et de configurer tous les services. Si vous devez procéder à des modifications, telles que l'ajout ou la mise à jour de services, vous pouvez créer un nouveau modèle pour lancer ultérieurement de nouvelles machines virtuelles qui remplaceront le groupe de machines ArcGIS Server utilisé par le système d'équilibrage de la charge. Les modèles de machines virtuelles permettent également de récupérer rapidement des machines ArcGIS Server obsolètes.

Voici la procédure recommandée pour appliquer des modifications à vos sites dans le cadre de ce scénario de déploiement :

  1. Les modifications administratives sont tout d'abord apportées à un site en mode de secours. Par exemple, vous pourrez ajouter un nouveau service et modifier la sécurité d'un autre service sur un site qui ne traite pas les requêtes. Ainsi, les applications utilisant votre site principal ne seront pas affectées.
  2. Configurez manuellement votre système d'équilibrage de la charge pour transférer toutes les requêtes au site de secours sur lequel les modifications ont été apportées.
  3. Appliquez les mêmes modifications au site inactif.
  4. Rétablissez le système d'équilibrage de la charge pour que les requêtes soient redirigées vers le site principal d'origine et quittent le site de secours en mode de secours.

Vous pouvez apporter manuellement les modifications susmentionnées à votre site via le gestionnaire ArcGIS Server, des scripts ou des images virtuelles.

Partage de répertoire en sortie

Certaines opérations de service d'ArcGIS Server référencent des ressources dans un ou plusieurs répertoires en sortie. Par exemple, les services de carte peuvent écrire des images dans un répertoire en sortie et référencer ces images via une URL dans la réponse à la requête. Afin que les clients reçoivent correctement l'image, tous les sites de votre configuration active-active doivent référencer le même répertoire en sortie. Cela peut être réalisé en plaçant les répertoires en sortie sur une ressource du réseau et en les partageant avec vos sites.

Voici une liste d'opérations de service qui utilisent les répertoires en sortie :

Exécution asynchrones de services de géotraitement

Les services de géotraitement ArcGIS Server prennent en charge deux modes d'exécution : synchrones et asynchrones. L'exécution synchrone suit un modèle requête-réponse passif et est entièrement prise en charge dans une configuration active-active. L'exécution asynchrone suit un modèle requête-réponse dynamique et est le mode par défaut. Afin d'utiliser l'exécution asynchrone dans une configuration active-active, vous devez prendre en compte les points suivants :

  • Lorsque vous soumettez une tâche de géotraitement asynchrone, l'ID de tâche qui vous est renvoyé correspond à la tâche soumise et à ses sorties. Seul le site ArcGIS Server qui reçoit la requête d'origine pourra reconnaître cet ID. C'est la raison pour laquelle la configuration active-active exige que vous définissiez l'affinité dans votre équilibrage de charge (appelées également sessions rémanentes) si vous souhaitez utiliser l'exécution asynchrone. Cela vous permet de garantir une disponibilité élevée pour les traitements asynchrones et les sorties de services de carte. Reportez-vous à votre fournisseur d'équilibrage de charge pour comprendre les implications de l'activation des sessions rémanentes.
  • Si votre service de géotraitement n'utilise pas de services de carte pour rendre les sorties et les sans sortie du type "Fichier" définies, vous pouvez sélectionner l'exécution synchrone pour vos services de géotraitement. Aucune session rémanente dans votre équilibrage de charge n'est requise.

Utilisation de la sécurité à base de jetons

Si vous utilisez l'authentification à base de jetons, également appelée authentification au niveau du serveur SIG, tous les sites de cette configuration doivent utiliser exactement la même clé de jeton partagée. Sinon, les jetons générés pour une machine ne seront pas valides s'ils sont utilisés pour l'autre machine. Pour savoir comment dupliquer les clés de jetons partagées sur plusieurs sites, reportez-vous aux rubriques A propos des jetons ArcGIS et Modification des paramètres de jeton dans le gestionnaire.

Avantages

  • Conception simple. Puisque les interdépendances sont minimes entre les machines ArcGIS Server, il est facile de remplacer des machines obsolètes ou défectueuses, d'appliquer des mises à niveau ou d'ajouter et de supprimer des machines du groupe ArcGIS Server sans interrompre les services ou abandonner les requêtes.
  • Si des tuiles de carte sont stockées en local sur chaque machine, cette configuration présente des avantages considérables en termes de performances par rapport aux sites à plusieurs machines. En fait, cette configuration est idéale si vous souhaitez augmenter la capacité des services de carte en cache.

Inconvénients

  • Vous êtes chargé de synchroniser tous les sites. Cette tâche administrative supplémentaire rend ce modèle de déploiement peu pratique en présence de nombreuses machines ou services/caches qui changent souvent.
  • Connaissance requise des systèmes tiers d'équilibrage de la charge.