Les considérations suivantes sont organisées autour des piliers d’architecture de l’ArcGIS Well-Architected Framework. L’application appropriée des bonnes pratiques et des approches architecturales dans chacun de ces domaines techniques contribue de manière significative à la réussite de la conception et de l’implémentation de systèmes à l’architecture bien conçue.
Vous pouvez également vous reporter à ces considérations en matière de conception physique pour obtenir des recommandations supplémentaires.
Nous avons opté pour une séparation des charges de travail afin d’optimiser la distribution des ressources de calcul dans le système. Dans l’étude test, le traitement des demandes de modification ayant généralement pris plus de temps que celui des demandes de carte standard, nous avons isolé les charges de travail de mise à jour avec des ressources de calcul dédiées sous la forme d’un site de serveur SIG ArcGIS distinct.
De plus, l’isolation des composants système eux-mêmes sur différentes machines permet de s’assurer qu’ils ne se disputent pas les ressources système et permet d’adapter les types et les tailles de machines aux exigences système de chaque composant.
Il est essentiel de choisir le processeur graphique (GPU, Graphics Processing Unit) approprié pour garantir les performances d’ArcGIS Pro dans un environnement virtualisé. Les tests ont montré que l’ajout d’un GPU dédié aux machines virtuelles ArcGIS Pro améliorait considérablement la productivité de l’utilisateur final et générait une réduction nette des coûts lorsque les dépenses opérationnelles (coûts de main-d’œuvre) étaient prises en compte.
Il est important de comprendre le ratio entre le processeur virtuel (vCPU) et le processeur physique lors des choix de conception afin que les ressources appropriées soient attribuées aux composants système. Le ratio vCPU:CPU est de 2:1 pour la plupart des instances figurant dans le diagramme, à l’exception de nos instances de bureau, qui ont un ratio de 1:1.
Il est à noter que les ratios peuvent varier en fonction des options de virtualisation. Outre les éventuels impacts sur les performances, cela peut aussi avoir des conséquences sur les licences Esri. Pour obtenir des exemples de ratios dans le cas des clouds publics, consultez les ressources suivantes.
La configuration appropriée des services SIG est essentielle pour les performances système et l’expérience utilisateur. Une mauvaise configuration des instances de service SIG peut entraîner des problèmes ou des défis de fiabilité dans un système. Par exemple, si le nombre d’instances d’un service de carte ou d’entités est trop faible, cela peut entraîner des temps d’attente rallongés pour les clients et des erreurs de délai d’expiration. Toutefois, si les instances configurées sont trop nombreuses, l’utilisation de ressources machine peut être excessive, ce qui limite le nombre de services pouvant être déployés sur une configuration matérielle fixe.
Lorsque le nombre maximum d’instances est supérieur au nombre minimum, le système peut automatiquement ajouter de nouvelles instances en réponse à la demande. Cependant, cela peut aussi dégrader les performances perçues, car les requêtes entrantes doivent attendre que l’instance démarre. Pour tout système, il est important de comprendre l’utilisation du service afin de pouvoir ajuster les nombres d’instances et les ressources du serveur pour offrir des performances optimales.
Pour les besoins de nos tests, le ratio entre les instances de service et les vCPU (processeurs virtuels) a été fixé à 1:1 pour chaque service, avec un nombre minimal et maximal d’instances identiques. Ainsi, comme nos sites de serveur SIG et de serveur d’hébergement disposaient chacun de deux instances à 8 vCPU, nous avions 16 instances par site de serveur. L’utilisation des instances a été surveillée pour déterminer comment le système gérait la charge. Si, à un moment donné, toutes les instances d’un serveur SIG étaient occupées, des temps d’attente élevés seraient à prévoir pour ce service.
Il s’agissait de la configuration d’instances de service optimale pour notre système de test, mais la configuration de votre organisation peut être différente. La surveillance et la collecte de données de télémétrie sont nécessaires pour configurer de façon avisée vos propres paramètres d’instances de service. Consultez le document The art and science of ArcSOC optimization pour obtenir des recommandations.
Dans cette étude test, les services de mise à jour d’atelier parcellaire ont été configurés comme suit :
Les serveurs d’hébergement (processus en lecture seule) ont été configurés comme suit :
Les délais d’expiration de service spécifiés ont été configurés comme suit :
Notre configuration du délai d’expiration a été ajustée de manière itérative pour résoudre les problèmes de délai d’expiration rencontrés pendant le test. Étant donné que ces paramètres peuvent varier en fonction d’exigences spécifiques, il est recommandé d’effectuer vos propres tests pour identifier la configuration optimale.
Les sauvegardes sont essentielles pour les systèmes de gestion des parcelles, comme pour la plupart des systèmes axés sur la mise à jour et la gestion des données. Bien que la conception testée ne corresponde pas à un système de production, nous avons capturé des instantanés de machine et des sauvegardes de base de données à chaque exécution de test et avant d’apporter des modifications au système. Des instantanés de machine virtuelle ont été pris avant et après toute modification dans l’environnement, comme le redimensionnement d’une machine, l’installation d’un correctif ou la mise à jour de Windows. Les instantanés ont ensuite été catalogués pour :
Notez que les instantanés peuvent ne pas suffire à récupérer votre environnement. Consultez Sauvegardes et récupération d’urgence pour obtenir une vue d’ensemble du processus de sauvegarde dans ArcGIS Enterprise.
Pour plus d’informations, consultez Architecture de référence du système de gestion des parcelles.
Le choix de concevoir ce système avec une configuration haute disponibilité des composants ArcGIS Enterprise a été fait en fonction des exigences commerciales et techniques du système, ainsi que d’autres objectifs organisationnels tels que la réalisation d’opérations ininterrompues et la réduction des temps d’arrêt. Cette configuration est illustrée dans la conception au moyen de composants système redondants et d’un stockage de fichiers natif Cloud et haute disponibilité. Cette étude test n’a pas configuré de base de données haute disponibilité à des fins de test, bien que les fournisseurs de bases de données relationnelles disposent de diverses méthodes pour approcher la haute disponibilité, y compris les services Cloud natifs.
Gardez à l’esprit que les configurations de haute disponibilité peuvent accroître sensiblement les coûts d’infrastructure et d’exploitation du système et qu’elles nécessitent des compétences spécialisées pour être mise en œuvre avec succès. Apprenez-en davantage sur les choix et considérations en matière de conception eu égard à la haute disponibilité d’un système de gestion des parcelles.
Pour réussir la validation du système et fournir des résultats significatifs, la surveillance du système et la capture de la télémétrie ont été des aspects clés de l’étude test.
ArcGIS Monitor et des outils de surveillance informatique d’entreprise tels que le moniteur de performance de Windows ont été utilisés pour surveiller les performances système et capturer la télémétrie sur son comportement dans certaines conditions. Des journaux ont été collectés dans différents composants du système, notamment :
Des mesures, telles que l’utilisation du processeur, la consommation de la mémoire RAM, l’activité du disque et l’activité du réseau, ont été capturées sur toutes les machines de l’environnement. Consultez les résultats de test pour plus d’informations.
De plus, des enregistrements d’écran des processus exécutés ont été capturés afin d’observer et d’évaluer l’expérience et la productivité de l’utilisateur final.
Étant donné que le champ d’application de l’étude test était principalement centré sur les tests de charge, la plupart des types d’automatisation recommandés pour un système de production, comme la rédaction de scripts pour les tâches administratives, n’ont pas été utilisés. Toutefois, dans votre environnement, les scripts d’administration peuvent avoir une valeur significative pour les processus et les opérations. Tout script d’automatisation doit être testé dans un environnement inférieur avant d’être déployé en production.
Dans cette étude test, l’utilisation principale de l’automatisation a été de simuler des demandes lors de tests de charge. Plusieurs processus ont été exécutés avec des utilisateurs virtuels à grande échelle avec la possibilité de s’appliquer à différentes tailles de charge, comme illustré dans les résultats des tests.
Nous avons utilisé des scripts Python pour analyser les temps d’attente des services, l’utilisation des instances de service, les temps de réponse et les requêtes en échec, et pour en dégager des tendances, afin d’orienter les ajustements nécessaires du système. Des scripts Python, PowerShell et SQL ont également été utilisés pour restaurer la base de données à son état d’origine après avoir terminé un test de charge.
La sécurité est un aspect essentiel de tout système informatique d’entreprise : authentification et autorisation, filtrage, chiffrement, audit et sécurisation. Les logiciels ArcGIS ont été pensés pour fonctionner avec efficacité au sein de réseaux sécurisés, y compris ceux qui sont totalement déconnectés d’Internet. Il est essentiel de prendre en considération les exigences de sécurité dès le début du processus de conception pour tout système de production.
Bien que la sécurité n’était pas l’idée centrale de cette étude test, nous avons intégré un fournisseur d’identité afin d’assurer une authentification et une autorisation des utilisateurs appropriées, comme l’illustre le diagramme d’architecture physique. La segmentation des sous-réseaux est une autre pratique de sécurité fondamentale appliquée dans cette étude test, reposant sur les principes du moindre privilège et de l’isolation réseau.
Ressources associées :
Bien que l’intégration était hors du champ d’application de l’étude test, un système de gestion des parcelles nécessite souvent une intégration avec d’autres systèmes d’entreprise, tels que des systèmes CAMA (évaluation de masse assistée par ordinateur). Apprenez-en davantage sur les considérations d’intégration avec ArcGIS.