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.
Le choix de conception pour une séparation de la charge de travail a été fait pour optimiser la distribution des ressources de calcul dans le système. Dans l’étude test, le traitement des demandes de modification a généralement été plus long que celui des demandes de carte standard, de sorte que le choix a été fait d’isoler les charges de travail de mise à jour avec des ressources de calcul dédiées sous la forme d’un site ArcGIS GIS Server 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 révélé 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. Pour en savoir plus sur la sélection du matériel GPU et la virtualisation d’ArcGIS Pro, consultez le centre d’architecture ArcGIS.
Il est important de comprendre le ratio entre le processeur virtuel (vCPU) et le processeur physique lors du 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 toutes les machines du diagramme, mais certaines options de virtualisation peuvent présenter des ratios différents, par exemple 1:1. Ces choix peuvent également avoir des implications sur les licences Esri . Les ratios Cloud publics sont par exemple AWS, Azure et GCP.
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 le nombre d’instances est trop élevé, les ressources machine utilisées peuvent être excessives, ce qui limite le nombre de services pouvant être déployés sur une configuration matérielle fixe. Lorsque le nombre maximal d’instances est supérieur au nombre minimal, le système peut ajouter automatiquement de nouvelles instances en réponse à la demande, mais cela peut également être problématique car les demandes entrantes doivent attendre le démarrage de l’instance. 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.
Dans cette étude test, le ratio entre les instances de service et les cœurs de processeurs physiques a été défini sur 2:1 pour chaque service concerné, les nombres minimal et maximal d’instances étant définis sur la même valeur. L’utilisation de l’instance a été surveillée pour déterminer quand le système était surchargé. Par exemple, à une charge de conception x8, les instances d’un service sur le serveur d’hébergement ont été observées comme actives pendant 99 % de la période de test, ce qui a entraîné des délais d’attente élevés pour les services en lecture seule. Les services de ce test ont été configurés pour des instances dédiées. En savoir plus sur la configuration des paramètres des instances de service.
Dans cette étude test, les services du réseau de distribution ont été configurés comme suit :
Le nombre total d’instances disponibles était de 16 car le site comprenait deux serveurs SIG ArcGIS.
Les serveurs d’hébergement ont été configurés comme suit :
Le nombre total d’instances disponibles était de 12 car le site comprenait deux serveurs SIG ArcGIS.
Les délais d’expiration de service spécifiés ont été configurés comme suit :
Notre configuration de 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 processus de 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 informations réseau. Reportez-vous à l’architecture de référence pour plus d’informations. Bien que la conception testée ne corresponde pas à un système de production, des instantanés machine et des sauvegardes de base de données ont été capturés pour l’exécution de chaque 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 de 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 :
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 haute disponibilité augmentent considérablement les coûts d’infrastructure et d’exploitation du système et nécessitent des compétences pointues pour réussir. En savoir plus sur les choix et considérations en matière de conception relatives à la haute disponibilité d’un système de gestion des informations réseau.
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 axée 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.
Des scripts Python ont été utilisés pour analyser et identifier des modèles dans les temps d’attente de service, l’utilisation d’ArcSOC, les délais de réponse et les demandes ayant échoué afin d’indiquer les modifications nécessaires au 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.
Bien que la sécurité n’ait pas été au centre de l’étude test, il est essentiel de prendre en compte les exigences de sécurité dès le début du processus de conception de tout système de production. Le logiciel ArcGIS a été conçu pour fonctionner efficacement au sein de réseaux sécurisés, y compris ceux qui sont entièrement déconnectés d’Internet. La conception de l’étude test comprend l’utilisation d’un fournisseur d’identités pour fournir une authentification et une autorisation appropriées.
Ressources associées :
Bien que les intégrations ne fassent pas partie du champ d’application de l’étude test, un système de gestion des informations réseau nécessite souvent une intégration avec d’autres systèmes d’entreprise tels que les systèmes de gestion des ressources d’entreprise (EAM), de gestion de la relation client (CRM) et de gestion avancée de la distribution (ADMS). Outre les considérations d’intégration standard avec ArcGIS, la fonctionnalité ArcGIS Utility Network présente des exigences supplémentaires à prendre en compte. En fonction des exigences d’intégration, différentes API et/ou différents SDK peuvent être pris en charge. Consultez l’article de blog Migration vers Utility Network : vue d’ensemble des stratégies d’intégration pour plus d’informations.