Introduction
Les organisations exigent souvent un certain niveau de disponibilité système pour leurs déploiements ArcGIS Enterprise, comme 99 pour cent du temps ou plus. Pour ces organisations, mettre en œuvre une stratégie pour assurer une haute disponibilité est crucial.
La Haute Disponibilité (HA), bien que liée à la Reprise après Sinistre (DR), est un concept distinct. En général, la HA se concentre sur l'évitement des interruptions de service, tandis que la DR vise à conserver les données et ressources nécessaires pour restaurer un système à un état acceptable antérieur après un sinistre.
Ce billet se concentrera sur les meilleures pratiques pour configurer un load balancer local (Local Traffic Manager, LTM) en un seul emplacement pour une haute disponibilité, et n'inclura pas les considérations pour configurer Global Traffic Manager (GTM) pour un basculement automatique entre différents emplacements.
Pour atteindre une haute disponibilité, vous devez réduire les points de défaillance uniques par duplication et équilibrage de charge.
Les load balancers agissent comme un proxy inverse et distribuent le trafic vers les serveurs back-end. Un load balancer tiers est requis dans un déploiement ArcGIS Enterprise hautement disponible pour améliorer la capacité et la fiabilité du logiciel. Ils gèrent le trafic client vers vos portails et sites serveur, ainsi que le trafic interne entre les composants logiciels.
ArcGIS Web Adaptor
Bien que ArcGIS Web Adaptor soit considéré comme un load balancer, il est insuffisant pour servir de seul load balancer dans un déploiement hautement disponible, car ArcGIS Web Adaptor nécessite également une redondance pour atteindre la haute disponibilité.
ArcGIS Web Adaptor est un composant optionnel, car les load balancers peuvent transmettre les requêtes directement à vos portails et sites serveur, mais c'est un composant recommandé. Les avantages d'utiliser des web adaptors sont :
- Il fournit un moyen simple de configurer une URL unique pour le système
- Il vous permet de choisir des noms de contexte pour les différents composants du système, par exemple portal, server, mapping, etc.
- Il est intégré nativement avec d'autres composants logiciels ArcGIS Enterprise, les portails et sites serveur, et gère automatiquement les vérifications de santé et les tâches de configuration, par exemple l'ajout d'une nouvelle machine à un site serveur
URL de contexte Web
L'URL de contexte web est l'URL publique du portail. Puisque tout élément dans le portail a une URL - fichier, couche, carte et application - la propriété WebContextURL du portail l'aide à construire les URLs correctes sur toutes les ressources qu'il envoie à l'utilisateur final.
Accès externe et DNS
Le portail ArcGIS Enterprise supporte uniquement un DNS pour l'URL publique du portail (l'URL de contexte web), et actuellement il n'existe aucun moyen supporté pour changer l'URL de contexte web sans refaire des tâches administratives, par exemple fédérer des sites serveur avec votre portail. Si votre ArcGIS Enterprise nécessite un accès externe, par exemple pour permettre l'accès aux utilisateurs mobiles, contractuels, partenaires ou agences sans VPN, ou si vous prévoyez devoir permettre l'accès externe à l'avenir, vous devez utiliser un nom DNS résolvable externement pour l'URL de contexte web du portail, par exemple https://gis.company.com/portal.
Pour sécuriser l'accès externe à ArcGIS Enterprise, il est courant d'héberger un load balancer dans une DMZ, et d'implémenter un système DNS fractionné (Split DNS), c'est-à-dire que l'accès interne au DNS ArcGIS Enterprise (par exemple gis.company.com) sera résolu vers une IP interne du load balancer, ainsi les utilisateurs internes resteront derrière le pare-feu, et l'accès externe au DNS ArcGIS Enterprise sera résolu vers une IP externe (DMZ) du load balancer.
URLs utilisées dans la fédération
Plusieurs URLs différentes sont utilisées dans un déploiement ArcGIS Enterprise hautement disponible.
URL des services
C'est l'URL utilisée par les utilisateurs et applications clientes pour accéder aux sites ArcGIS Server. C'est l'URL du load balancer qui gère le trafic ArcGIS Server et transmet les requêtes soit à l'ArcGIS Web Adaptor du site serveur soit directement aux machines serveur.
URL administrative
Cette URL est utilisée par les administrateurs, et en interne par le portail, pour accéder à un site ArcGIS Server lors d'opérations administratives. Cette URL est aussi utilisée pour publier des services SIG avec référence à une source de données enregistrée, par exemple une géodatabase entreprise SQL Server, vers un site serveur fédéré. Elle doit pointer vers un load balancer ; si l'URL administrative pointe vers une seule machine dans le site serveur et que cette machine est hors ligne, la fédération ne fonctionnera pas. Cela peut être la même URL que celle des services ou peut être un second load balancer (VIP) pour chaque URL admin du site serveur fédéré via le port 6443. Configurer un VIP dédié pour chaque URL admin du site serveur fédéré via le port 6443 nécessitera d'ouvrir ce port aux administrateurs et éditeurs, et vous pouvez désactiver l'accès administratif via le web adaptor, fournissant ainsi des contrôles supplémentaires de sécurité pour l'organisation.
Je recommande d'utiliser la même URL que celle des services car cela simplifie la configuration. L'accès administratif à ArcGIS Server sera contrôlé par l'authentification ArcGIS Enterprise et les rôles utilisateurs, similaire à l'accès administratif au portail, par exemple ArcGIS Portal Directory (portaladmin) et Paramètres de l'organisation. Pour utiliser l'URL du web adaptor comme URL administrative, vous devez activer l'accès administratif dans le web adaptor serveur.
URL privée du portail
C'est une URL interne utilisée par vos sites serveur pour communiquer avec le portail. Elle doit également pointer vers un load balancer et devrait être définie avant la fédération. Si vous fédérez vos sites serveur avant de définir privatePortalURL, suivez les étapes 8 et 9 dans le sujet Configurer un déploiement existant pour haute disponibilité pour mettre à jour l'URL dans votre déploiement. Similaire à l'URL administrative, cela peut être la même que l'URL publique pour le portail (l'URL du contexte web du portail), ou cela peut être un second équilibreur de charge (VIP) via le port 7443.<\/P>
Pour simplifier la configuration, je recommanderais d'utiliser l'URL publique pour le portail comme URL privée du portail. Si vous choisissez d'utiliser un VIP d'équilibreur de charge dédié via le port 7443 pour l'URL privée du portail, vous devriez configurer l'équilibreur de charge pour vérifier la santé des machines du portail.<\/P>
Configuration de l'équilibreur de charge<\/H1>Paramètres de vérification de santé <\/H2>La capacité la plus importante à utiliser est une Vérification de Santé. Comme décrit dans la documentation de vérification de santé du portail :<\/P> <\/P>« La vérification de santé indique si la machine Portal for ArcGIS répondante est capable de recevoir et traiter les requêtes. Par exemple, avant la création du portail, l'URL de vérification de santé indique que le site est indisponible car il ne peut pas prendre de requêtes à ce moment-là. »<\/EM><\/BLOCKQUOTE> <\/P>Le portail ArcGIS Enterprise et le serveur disposent de vérifications de santé.<\/P>Lorsque vous utilisez les ArcGIS Web Adaptors, ceux-ci s'occupent d'effectuer les vérifications de santé contre le portail et les serveurs. Dans ce cas, vous pouvez configurer l'équilibreur de charge avec une vérification de santé TCP\/443 basique ou une vérification de page statique, avec des paramètres standards pour le délai d'attente, le déclencheur d'échec, l'intervalle de sondage et le seuil sain.<\/STRONG><\/P>Si vous configurez l'équilibreur de charge pour accéder directement au portail et/ou aux serveurs, par exemple si vous n'incluez pas les web adaptors dans votre architecture, ou si vous utilisez une URL dédiée d'équilibreur de charge pour l'URL privée du portail (port 7443) ou l'URL administrative du serveur fédéré (port 6443), vous devez configurer l'équilibreur de charge pour vérifier la santé des machines du portail et du serveur.<\/P>Il y a quelques considérations importantes concernant les paramètres de vérification de santé sur l'équilibreur de charge. La plupart des organisations utilisant un équilibreur de charge utilisent une page statique comme leur vérification de santé (par exemple index.html) pour déterminer si le serveur web est sain. Il s'agit d'un fichier statique qui nécessite seulement une lecture disque. De plus, la plupart des serveurs web ont tendance à être limités par les E/S plutôt que par le CPU. <\/P>Cependant, ArcGIS Server d'Esri est différent en ce que notre vérification de santé nécessite une très faible quantité de CPU car notre contrôle est plus qu'une simple lecture disque, le logiciel doit déterminer si certains processus sont fonctionnels.<\/P>Avec les vérifications de santé, il y a une valeur de délai d'attente sur la sonde. La plupart des administrateurs d'équilibreurs définissent cette valeur très basse car les lectures disque sont généralement très rapides (bien qu'ils laissent souvent une marge pour une latence réseau élevée).<\/P>Lorsqu'on utilise une valeur basse avec ArcGIS Server et dans une configuration multi-machines, il y a un risque qu'une machine dépasse cette valeur basse et qu'une machine saine soit retirée.<\/P>Esri recommande une valeur plus élevée pour le délai d'attente, idéalement au moins 5 secondes. Selon le système, il pourrait être nécessaire d'augmenter encore cette valeur. Vous devriez surveiller votre environnement et ajuster cette valeur en conséquence. Cela peut sembler élevé aux administrateurs réseau puisque la vérification sur une page simple prend habituellement moins de 10 ms normalement (plus la latence réseau).<\/P>Cependant, il est crucial que les équilibreurs distinguent quand une machine est simplement lente et quand elle est vraiment morte et non réactive. Si le portail ou serveur est vraiment hors service et n'écoute pas du tout sur un port, la plupart des équilibreurs détecteront cela même avant 5 secondes, donc ce délai n'affecte pas les pannes "normales" où une machine disparaît.<\/P>La deuxième considération est le déclencheur d'échec - combien de fois la sonde doit échouer avant que la machine soit retirée de l'équilibreur. <\/P>En règle générale, les administrateurs réseau définissent ce déclencheur à plus d'un échec car ils ne veulent pas qu'un simple problème réseau fasse tomber le système. Comme mentionné ci-dessus, un pic temporaire d'utilisation CPU (commun sur les systèmes ArcGIS Server) peut causer un délai dépassé, et il n'est pas souhaitable d'arrêter une machine à cause d'un seul pic CPU sur une seule machine. <\/P>Esri a réalisé des tests internes approfondis avec des équilibreurs et a constaté qu'un réglage à 5 échecs réduisait considérablement les faux positifs tout en détectant les vraies pannes. Nous avons constaté qu'une valeur à 3 était encore très sujette aux faux positifs.<\/P>La troisième considération est l'intervalle entre sondages. Esri a trouvé que des intervalles de 30 secondes couplés à 5 échecs étaient un bon compromis entre détection réelle des pannes et ignorance des faux positifs. <\/P>Avec cette combinaison, la valeur attendue (en termes statistiques) ou temps moyen avant détection est d'environ 1 minute 15 secondes d'indisponibilité avant détection, avec un pire cas à 2 minutes 30 secondes. Il est possible d'avoir un temps moyen plus court mais au prix d'un nombre accru de faux positifs.<\/P>Si un temps moyen plus court est préféré, il peut être nécessaire d'augmenter la capacité afin qu'il y ait suffisamment de ressources pour supporter une vraie panne sur une machine ainsi qu'un faux positif sans surcharger les autres machines.<\/P>Le dernier paramètre concernant les vérifications est le seuil sain pour que l'équilibreur recommence à envoyer des requêtes. Esri n'a pas de recommandation spécifique pour cela et nous n'avons pas observé beaucoup de différences selon cette valeur, mais nous voyons typiquement 3 sondages consécutifs sains avant réintégration.<\/P>Limitation <\/H2>Les paramètres de limitation méritent considération. ArcGIS Server est lié au CPU ce qui signifie que la majeure partie du temps des requêtes est utilisée par le CPU plutôt que par attente E/S. <\/P>Cela signifie que s'il y a 8 cœurs, ArcGIS Server peut gérer un peu plus que 8 requêtes simultanées en pratique. Si ArcGIS Server est occupé, il commence à mettre en file d'attente les requêtes jusqu'à ce qu'il y ait des centaines en attente, après quoi il refuse les connexions. Lorsqu'il y a un long retard dans la file d'attente cela entraîne un long temps d'attente mais finalement la requête est traitée.<\/P>ArcGIS Server dispose de paramètres pour contrôler ce comportement afin qu'il y ait moins de requêtes abandonnées en cours mais c'est aussi une bonne pratique de contrôler cela au niveau de l'équilibreur via sa capacité à limiter. <\/P>Esri n'a pas de recommandation numérique car cela dépend beaucoup de l'architecture spécifique et des types de requêtes entrantes mais il est typique que la limitation soit fixée bien en dessous des valeurs habituelles utilisées par les administrateurs réseau pour un serveur web.<\/P>Cela dépasse le contrôle des administrateurs réseau mais les applications clientes doivent être conçues pour gérer un événement de limitation et effectuer des nouvelles tentatives avec des intervalles croissants (par exemple première fois réessayer immédiatement, deuxième fois attendre une seconde, troisième fois attendre 5 secondes etc.).<\/P>Sessions persistantes <\/H2>Esri ne recommande pas les sessions persistantes sauf dans des circonstances très rares. Les sessions persistantes peuvent théoriquement surcharger une machine. Esri a réalisé des tests sous charge utilisant ces sessions persistantes pour voir si cela surchargeait notre GIS Server et cela ne s'est pas produit. Nous n'avons également reçu aucune plainte client. Cela dit, puisque notre logiciel est sans état nous ne voyons pas l'intérêt d'utiliser ces sessions persistantes. <\/P>Couche 4 vs Couche 7 <\/H2>Le dernier paramètre à mentionner est si l'équilibreur utilise une approche "niveau 7" ou "couche 4". C'est souvent sujet à débat parmi les administrateurs réseau mais voici un résumé concis décrivant différences et avantages respectifs.<\/P>Un équilibreur couche 7 comprend http et https ; il déchiffre donc le contenu https puis le rechiffre. Parce qu'il comprend http et https il peut mettre en cache du contenu et économiser des requêtes vers le serveur backend.<\/P>Un équilibreur couche 4 voit tout le trafic comme paquets TCP sans savoir ce qu'ils signifient ; ils peuvent être ftp, https, smtp mais cela importe peu à un équilibreur couche 4. En conséquence il n'a pas besoin de comprendre la charge utile http et peut être plus rapide.<\/P>ArcGIS Server peut fonctionner avec ces deux approches sans recommandation spécifique aux admins réseau mais certains éléments doivent être connus par ces derniers. <\/P>Les charges utiles ArcGIS Server peuvent être bien plus volumineuses que pages HTML, CSS et JS (la quantité exacte dépend souvent des données utilisées par le client). Cela signifie plus charge CPU sur un équilibreur couche 7 qui doit déchiffrer puis rechiffrer chaque requête. <\/P>Aussi comme beaucoup des données ArcGIS Server sont dynamiques et changent fréquemment, par défaut les entêtes cache interdisent la mise en cache côté client et équilibreur. Si les données changent peu et que le client veut utiliser un équilibreur couche 7 ils peuvent modifier ces paramètres cache. <\/P>Résumé des recommandations<\/H2>Vérification Santé<\/SPAN><\/P>Si vous configurez vos équilibreurs avec ArcGIS Web Adaptors vous pouvez configurer l'équilibreur avec une vérification TCP/443 basique ou une vérification page statique contre les serveurs web<\/SPAN><\/LI>Si vous configurez l'équilibreur pour accéder directement au portail et/ou aux serveurs (via ports 6443 et 7443), utilisez Point de terminaison de vérification de santé HTTPS :<\/SPAN>Portal :<\/SPAN>Requête : <\/SPAN>https:\/\/\/\/portaladmin\/healthCheck?f=json
OU<\/SPAN>
<\/SPAN>https:\/\/:7443\/arcgis\/portaladmin\/healthCheck?f=json<\/A><\/SPAN><\/LI>Réponse : {"status":"success"}<\/SPAN><\/LI><\/UL><\/LI>Server :<\/SPAN>Requête : <\/SPAN>https:\/\/\/\/rest\/info\/healthCheck?f=json
OU<\/SPAN>
<\/SPAN>https:\/\/:6443\/arcgis\/rest\/info\/healthCheck?f=json<\/A><\/SPAN><\/LI>Réponse : {"success":true}<\/SPAN><\/LI><\/UL><\/LI>Utilisez une valeur de délai d'attente pour la vérification de santé plus élevée, au moins 5 secondes<\/SPAN><\/LI>Utilisez une valeur de 5 pour le déclencheur d'échec<\/SPAN><\/LI>Utilisez des intervalles de sondage de 30 secondes<\/SPAN><\/LI>Utilisez 3 sondages consécutifs sains avant de rejoindre à nouveau<\/SPAN><\/LI><\/UL><\/LI><\/UL>Limitation du débit <\/SPAN><\/P>Utilisez un réglage de limitation du débit à une valeur significativement inférieure à celle des serveurs web typiques<\/SPAN><\/LI><\/UL>Sessions persistantes<\/SPAN><\/P>N'utilisez pas les sessions persistantes<\/SPAN><\/LI><\/UL>
Certificats<\/SPAN><\/H1>Les composants ArcGIS Enterprise sont préconfigurés avec des certificats serveur auto-signés, ce qui permet de tester initialement le logiciel et de vous aider à vérifier rapidement que votre installation a réussi. Cependant, dans presque tous les cas, une organisation doit demander un certificat auprès d'une autorité de certification (CA) fiable et configurer le logiciel pour l'utiliser. Le certificat peut être signé par une CA d'entreprise (interne) ou commerciale. Une CA commerciale (known-CA) doit être utilisée pour un DNS résolvable en externe, par exemple le DNS VIP du load balancer ; des certificats de domaine interne peuvent être utilisés pour les serveurs internes. <\/SPAN>
Pour un système ArcGIS Enterprise avec un DNS résolvable en externe, si la méthode SSL du load balancer est SSL-passthrough (le load balancer ne déchiffre pas et ne rechiffre pas le contenu https), il ne nécessite pas de certificat, et un certificat CA commercial doit être installé sur les serveurs mappés (par exemple les serveurs web où les web adaptors sont installés). Si la méthode SSL du load balancer est la ré-encryption SSL, un certificat CA commercial doit être installé sur le load balancer.<\/SPAN><\/SPAN><\/P>
.png)
