Architecture physique

Cette architecture a été évaluée en janvier 2026 sur la base des éléments suivants :

• Organisation de gestion parcellaire de taille moyenne
• Prise en charge des processus de gestion parcellaire, avec une charge de conception cible telle que celle décrite dans la section méthodes de test
• Géodatabase d’entreprise configurée avec SQL Server
• Infrastructure cloud Microsoft Azure

Le système a été conçu et testé par rapport aux processus spécifiés, avec un ajustement des types et tailles de machines en fonction des résultats des tests

Téléchargez un fichier Microsoft Visio de cette architecture. Apprenez-en davantage sur les ressources de création de diagrammes pour les systèmes ArcGIS.

Types et tailles de machines

Voici les tailles de machines choisies et validées pour le champ d’application et l’objectif de cette étude test. Cependant, il est fortement recommandé de suivre un processus de conception complet pour tenir compte de vos exigences métier et techniques.

Si vous avez besoin d’aide pour déterminer tous les facteurs liés à la conception physique de votre organisation, tels que la mise en réseau, le stockage, les environnements système et le dimensionnement, Esri propose des services de conception d’architecture système. La configuration système minimale requise pour chaque composant est répertoriée dans la documentation disponible en ligne du logiciel respectif.

Desktop (ArcGIS Pro et navigateur Web)

• 3 machines utilisées dans les tests
• Standard_NC8as_T4_v3
• 8 processeurs virtuels
• 56 Go de RAM
• Processeur graphique de 16 Go
• Disque de 128 Go

Portal for ArcGIS

• 2 machines
• Standard_D4s_v6
• 4 processeurs virtuels
• 16 Go de mémoire RAM
• Disque de 128 Go

Serveur SIG ArcGIS

• 2 machines
• Standard_D8s_v6
• 8 processeurs virtuels
• 32 Go de mémoire RAM
• Disque de 128 Go

ArcGIS Server (serveur d’hébergement)

• 2 machines
• Standard_D8s_v6
• 8 processeurs virtuels
• 32 Go de mémoire RAM
• Disque de 128 Go

ArcGIS Data Store (relationnel)

• 2 machines
• Standard_D4s_v6
• 4 processeurs virtuels
• 16 Go de mémoire RAM
• Disque de 128 Go

ArcGIS Web Adaptor

• 2 machines
• Standard_D2as_v6
• 2 vCPU
• 8 Go de mémoire RAM
• Disque de 128 Go

ArcGIS Monitor

• 1 machine
• Standard_D8s_v6
• 8 processeurs virtuels
• 32 Go de mémoire RAM
• Disque de 128 Go

Stockage de fichiers

• 1 instance
• NetApp Files
• Débit de 100 MiB/s
• Disque de 1 To

Base de données

• 1 machine
• Standard_D16s_v6
• 16 vCPU
• 64 Go de mémoire RAM
• Disque de 1 To

Services d’annuaire

• Services de domaine Microsoft Entra

Autres éléments à prendre en compte concernant l’architecture

Voici d’autres points à prendre en compte pour concevoir un système de gestion des informations réseau, ainsi qu’une explication de certains choix d’infrastructure faits pour cette étude test.

Pour en savoir plus sur la conception de systèmes ArcGIS avec des composants et services Azure, consultez Technologies Azure.

Équilibrage de charge et proxys inverses

Au moins un équilibreur de charge tiers est requis dans un déploiement ArcGIS Enterprise haute disponibilité : il gère le trafic client à destination du portail et des sites de serveur, ainsi que le trafic interne entre les composants logiciels. Bien qu’ArcGIS Web Adaptor soit considéré comme un équilibreur de charge, il ne suffit pas dans une configuration haute disponibilité. Ainsi, dans cette étude test, Azure Application Gateway a été utilisé.

Éléments à prendre en considération pour les bases de données

Pour le champ d’application et les objectifs de cette étude test, le choix a été fait de déployer SQL Server sur une machine virtuelle. Toutefois, selon vos besoins, vous pouvez envisager d’utiliser un service de plateforme de base de données comme Azure SQL Managed Instance dans un environnement Microsoft Azure.

Stockage partagé

Pour implémenter un déploiement ArcGIS Enterprise haute disponibilité, les magasins de configuration doivent être stockés dans un emplacement haute disponibilité partagé. Cela garantit que ces données restent accessibles même si un serveur tombe en panne et offre ainsi un service ininterrompu à l’utilisateur final. De plus, le stockage partagé simplifie la gestion des données dans un déploiement sur plusieurs machines et améliore l’évolutivité en centralisant le stockage des données et en permettant un développement en fonction des besoins. Dans cette étude test, Azure NetApp Files a été utilisé.

Composants système non inclus dans le diagramme

Notez que si les logiciels antivirus et les composants réseau Azure ne sont pas illustrés dans ce diagramme, ils étaient présents dans l’étude test.