Lorsque vous déployez ArcGIS Enterprise on Kubernetes, vous devez sélectionner un profil d’architecture adapté à votre organisation. Les profils d’architecture sont des profils de déploiement prédéfinis en corrélation avec différents niveaux de redondance sur les pods. Le profil que vous choisissez détermine les pods qui sont automatiquement répliqués lors de la configuration. Puisque certaines organisations requièrent des niveaux accrus de résilience et de disponibilité, les profils d’architecture offrent une certaine flexibilité sur plusieurs variables connues, comme la configuration matérielle requise, la redondance et l’utilisation au sein de l’organisation.
Les profils d’architecture prédéfinis sont décrits ci-dessous. Les deux premiers sont destinés à la haute disponibilité et le troisième s’applique à une utilisation dans un environnement de développement ou hors production.
| Profil d’architecture | Cas d’utilisation | Configuration matérielle | Redondance prédéfinie sur les pods |
|---|---|---|---|
Enhanced availability (Disponibilité optimisée) | Conçu pour une utilisation dans des environnements de production métier ou cruciaux. Ce profil est prévu pour le niveau de disponibilité le plus élevé, car il inclut une redondance accrue et développée sur des pods critiques. | Maximum | Maximum |
Standard availability (Disponibilité standard) | Conçu pour une utilisation dans des environnements de production et des environnements visant à réduire les temps d’arrêt non planifiés grâce à la redondance sur de nombreux pods. Il s’agit du profil par défaut. | Modéré | Modéré |
Development (Développement) | Conçu pour une utilisation dans des environnement hors production, y compris les environnements de test et d’évaluation. Ce profil n’est pas pris en charge pour les environnement de production. | Minimale | Minimale |
Si vous déployez ArcGIS Enterprise on Kubernetes dans des environnements hors production ou de test, utilisez l’option de développement. Ce profil requiert le niveau le moins élevé de matériel et de ressources. Lorsque vous effectuez un déploiement dans des environnements de production, les deux profils de haute disponibilité permettent une utilisation et une disponibilité continues en cas de panne ; toutefois, le profil amélioré requiert du matériel supplémentaire.
Pods répliqués par profil d’architecture
Comme décrit ci-dessus, chaque profil d’architecture fournit un ensemble prédéfini de pods répliqués pour la prise en charge de processus continus dans le cas d’une panne inattendue. Un exemple de processus pris en charge est fourni pour chaque profil.
- Enhanced availability (Disponibilité améliorée) : des pods répliqués sont fournis pour les outils de publication, le stockage, les API et les contrôleurs ingress avec une redondance accrue pour la prise en charge d’une utilisation ininterrompue en cas de panne ou de temps d’arrêt inattendu.
- Standard availability (Disponibilité standard) : des pods répliqués sont fournis pour les outils de publication et d’autres pods essentiels tels que le stockage, les API et les contrôleurs ingress pour la prise en charge d’une utilisation continue en cas de panne ou de temps d’arrêt inattendu.
- Development (Développement) : les outils de publication sont répliqués pour la prise en charge de plusieurs éditeurs dans une organisation.
Une description de chaque profil de pod par architecture est indiquée ci-dessous.
| Pods répliqués | Profil Enhanced availability (Disponibilité améliorée) | Profil Standard availability (Disponibilité standard) | Profil Development (Développement) |
|---|---|---|---|
Outils de publication | 4 | 3 | 3 |
Relational data store | 2 | 2 | 2 |
Contrôleur ingress privé | 3 | 2 | 2 |
Contrôleur ingress | 3 | 2 | |
API de l’administrateur | 2 | 2 | |
API du portail | 2 | 2 | |
API des services | 2 | 2 | |
Service d’automatisation des notebooks | 2 | ||
Stockage en file d’attente | 2 | 2 | |
Object store : mixte | 3 | ||
Object store : métadonnées | 3 | ||
Object store : serveur de données | 5 | ||
Store spatiotemporel et d’index : mixte | 3 | ||
Store spatiotemporel et d’index : coordinateur | 3 | ||
Store spatiotemporel et d’index : données | 2 | ||
Service d’entités partagé | 2 | 2 | |
Service d’imagerie partagé | 2 | 2 | |
Service de carte partagé | 2 | 2 | |
Service de tuiles partagé | 2 | 2 |
Taille de stockage recommandée par profil d’architecture
Pour garantir un stockage suffisant, la taille de stockage recommandée pour chaque volume StatefulSet dépend du profil d’architecture spécifié, comme indiqué dans la table ci-dessous. La taille provisionnée doit être au moins égale à la valeur minimale spécifiée dans le profil de développement. Vous pouve augmenter la taille du volume de l’object store, du relational store et du store spatiotemporel et d’index après la création si vous avez besoin de stockage supplémentaire.
| StatefulSet | Profil de disponibilité avancé (Go) | Profil de disponibilité standard (Go) | Profil de développement (Go) |
|---|---|---|---|
Store relationnel | 300 | 150 | 16 |
stockage d’objets | 300 | 150 | 64 |
Cache en mémoire | 16 | 16 | 16 |
Stockage en file d’attente | 16 | 16 | 16 |
Store spatiotemporel et d’index | 300 | 150 | 32 |
Paquetages d’éléments | 32 | 16 | 16 |
Prometheus | 120 | 60 | 30 |
Le stockage total recommandé pour chaque profil d’architecture indiqué dans la table suivante dépend de la taille de chaque volume et du nombre de réplicas :
| Profil d’architecture | Taille de stockage totale recommandée (Go) |
|---|---|
Profil Enhanced availability (Disponibilité améliorée) | 4732 |
Profil Standard availability (Disponibilité standard) | 1340 |
Profil Development (Développement) | 206 |
Vous avez un commentaire à formuler concernant cette rubrique ?