Profils de disponibilité
Un profil de disponibilité détermine le niveau de redondance entre 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 de disponibilité offrent une certaine flexibilité sur plusieurs variables connues, comme la configuration matérielle requise, la redondance et l’utilisation au sein de l’organisation.
Lors de la création de votre organisation, sélectionnez un profil de disponibilité adapté à vos besoins de redondance.
Les profils de disponibilité prédéfinis sont décrits ci-dessous.
|
Profil de disponibilité |
Cas d’utilisation |
Configuration matérielle |
Redondance prédéfinie sur les pods |
|---|---|---|---|
|
Haute 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 |
|
Haute 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é |
|
Environnements de développement et de test |
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, utilisez l’option des environnements de développement et de test. 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. Le profil de haute disponibilité améliorée offre une résilience supplémentaire par rapport au profil de haute disponibilité standard, mais nécessite des ressources système supplémentaires.
Pods répliqués par profil de disponibilité
Comme décrit ci-dessus, chaque profil de disponibilité 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 high availability (Haute 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 high availability (Haute 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 and test environments (Environnements de développement et de test) : 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 disponibilité est indiquée ci-dessous.
|
Pods répliqués |
Profil de haute disponibilité avancée |
Profil de haute disponibilité standard |
Profil d’environnements de développement et de test |
|---|---|---|---|
|
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 |
|
|
JavaScript API |
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 |
|
|
Portail d’entreprise |
2 |
||
|
Applications d’entreprise |
2 |
Taille de stockage recommandée par profil de disponibilité
Pour garantir un stockage suffisant, la taille de stockage recommandée pour chaque volume StatefulSet dépend du profil de disponibilité 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 d’environnements de développement et de test. Vous pouvez augmenter la taille du volume de l’Object Store, du Relational Data Store et du store spatiotemporel et d’index après la création si vous avez besoin de stockage supplémentaire.
|
StatefulSet |
Profil de haute disponibilité avancé (Go) |
Profil de haute disponibilité standard (Go) |
Profil d’environnements de développement et de test (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 de disponibilité indiqué dans la table suivante dépend de la taille de chaque volume et du nombre de réplicas :
|
Profil de disponibilité |
Taille de stockage totale recommandée (Go) |
|---|---|
|
Profil de haute disponibilité avancée |
4732 |
|
Profil de haute disponibilité standard |
1340 |
|
Profil d’environnements de développement et de test |
206 |