Comprendre les profils d’architecture
Lorsque vous créez une organisation ArcGIS Enterprise, vous sélectionnez des profils d’architecture pour définir le niveau initial de disponibilité et de performance d’ArcGIS Enterprise on Kubernetes. Les profils que vous choisissez déterminent la quantité de CPU, de mémoire et d’espace disque dont vous aurez besoin pour le déploiement initial, et comment ces besoins évoluent à mesure que vous faites évoluer votre déploiement. Il existe deux types de profils d’architecture :
Un profil de disponibilité définit le nombre initial de réplicas de pods pour chaque charge de travail dans ArcGIS Enterprise. Avoir plus de réplicas offre une plus grande redondance et améliore la disponibilité.
Un profil de performance définit la quantité initiale de CPU et de mémoire requise par chaque pod. Les pods de service avec plus de CPU et de mémoire ont généralement un meilleur débit et des temps de réponse plus courts.
Ressources système requises
La quantité totale de CPU et de mémoire nécessaires pour déployer ArcGIS Enterprise dépend à la fois du nombre de réplicas de pods et des ressources système utilisées par chaque pod. La configuration système requise répertorie les ressources minimales requises pour chaque combinaison de profil de disponibilité et de performance.
Il est important de noter que publier des services dédiés, augmenter la taille des réplicas de pods ou ajouter des fonctionnalités telles que l’analyse raster augmentera les ressources nécessaires.
Scénarios
Choisir les bons profils d’architecture implique des compromis. Le meilleur choix équilibrera votre besoin de redondance et de performance avec les coûts de déploiement de l’infrastructure nécessaire. Utilisez les scénarios ci-dessous pour vous aider à choisir les meilleurs profils d’architecture pour votre organisation.
Scénario : environnement de démonstration
Une organisation souhaite faire une démonstration des fonctionnalités d’ArcGIS Enterprise on Kubernetes. Cet environnement hors production ne sera en service que quelques heures. Il n’est donc pas nécessaire d’assurer une haute disponibilité. Le système devrait offrir d’excellentes performances pour mettre en avant ses fonctionnalités.
Profil de disponibilité : environnements de développement et de test
Profil de performance : performances améliorées
Scénario : déploiement de l’équipe interne
Un service d’urbanisme municipal a une mission centrée sur l’intérieur et ne dispose pas d’un accord de niveau de service (SLA) strict. Communiquer les coupures planifiées ou imprévues est simple et il existe une grande flexibilité pour les interruptions planifiées. Le service a besoin de l’environnement de production le moins coûteux possible, adapté à des charges prévisibles et stables.
Profil de disponibilité : haute disponibilité standard
Profil de performance : performances standard
Scénario : déploiement à l’échelle de l’organisation
Une grande entreprise utilise ArcGIS Enterprise pour répondre aux besoins de nombreux utilisateurs au sein de toute l’organisation. Il est acceptable de planifier des temps d’arrêt pour la maintenance en dehors des heures d’ouverture normales, mais les utilisateurs s’attendent à une communication en amont pour tout temps d’arrêt. Des réponses lentes pendant de courtes périodes peuvent être acceptables aux heures de pointe, tant qu’elles ne se produisent que quelques fois par mois.
Profil architectural : haute disponibilité standard
Profil de performance : performances standard
Scénario : déploiement public
Le gouvernement d’un État utilise ArcGIS Enterprise pour fournir des informations à diverses agences. Les agences sont des parties prenantes officielles qui attendent une disponibilité continue. Le système doit s’adapter à des heures d’exploitation continues, mais une fenêtre de maintenance planifiée est acceptable si elle est communiquée par les canaux officiels suffisamment longtemps à l’avance. Aucun accord de niveau de service en matière de performances n’est défini, mais les parties prenantes attendent une bonne performance en permanence et ne font preuve d’aucune tolérance, même pour des réponses de service occasionnellement lentes.
Profil architectural : haute disponibilité standard
Profil de performance : performances améliorées
Scénario : système opérationnel
Une grande entreprise utilise ArcGIS Enterprise pour traiter les données entrantes, effectuer des analyses planifiées et générer des rapports à partir de ces analyses. Il est important que ce système reste disponible en continu, et il existe un accord de niveau de service imposant un niveau spécifique de disponibilité opérationnelle. Des fluctuations des performances sont cependant tolérables, car les utilisateurs n’attendent pas activement des réponses.
Profil architectural : haute disponibilité accrue
Profil de performance : performances standard
Scénario : déploiement public potentiellement viral
Un centre national d’intervention d’urgence utilise ArcGIS Enterprise pour fournir des informations vitales sur la sécurité publique lors de catastrophes naturelles. Lors de ces événements, le système est utilisé par des millions de personnes qui s’attendent à des performances rapides. Cependant, pendant certaines périodes de l’année, aucun changement autre que l’entretien de routine ne peut être effectué. Il existe des accords de niveau de service formels en matière de disponibilité et de temps de réponse du service.
Profil architectural : haute disponibilité accrue
Profil de performance : performances améliorées