Évolution des services

Lorsque vous avez publié des services SIG, il est recommandé de les surveiller, par exemple, en examinant les statistiques d’utilisation des services, pour comprendre les modèles d’utilisation et avoir une idée de l’ajustement des ressources à appliquer, en fonction du trafic observé. Vous pouvez traiter l’évolution des modèles de trafic et de la demande utilisateur pour vos services de différentes manières. Pour satisfaire les attentes en matière de demandes et de performances, considérez les méthodes suivantes pour optimiser les ressources des services :

• Ajustez le mode de service pour optimiser les ressources dédiées à un service.
• Mettez manuellement à l’échelle les services en spécifiant le nombre de pods à allouer à un service.
• Activez la mise à l’échelle automatique en fixant un seuil en fonction duquel les pods sont automatiquement alloués à un service.

Pour déterminer l’option qui convient, examinez les scénarios ci-après.

Types d’évolution

Vous pouvez faire évoluer les services manuellement ou utilisez la fonction de mise à l’échelle automatique. Dans les deux cas, la méthode par laquelle les services sont redimensionnés se caractérise par une mise à l’échelle horizontale (ajout ou suppression des ressources) ou verticale (augmentation ou diminution de la taille des ressources). Les services peuvent être redimensionnés quel que soit le mode de configuration, qu’ils soient partagés ou dédiés.

• Mise à l’échelle horizontale - Ajoute plusieurs pods à un déploiement de service. Elle permet, par exemple, de passer d’un pod à plusieurs. Option prise en charge pour la mise à l’échelle manuelle et la mise à l’échelle automatique.
• Mise à l’échelle verticale - Ajoute des ressources de processeur ou de mémoire au jeu actuel de pods d’un déploiement. Option prise en charge pour la mise à l’échelle manuelle.

Lorsque vous augmentez le nombre de pods disponibles pour un service, le cluster Kubernetes génère des réplicas supplémentaires pods existants du déploiement de service, notamment leurs instances de service et de configuration du service au sein des pods.

Ce redimensionnement augmente également la disponibilité et le rendement total des instances du service, mais également la consommation de mémoire et de processeur du service. Comme vous faites évoluer votre infrastructure Kubernetes, cette option tolère les pannes. Les pods qui ne fonctionnent plus sont automatiquement restaurés sans que cela n’affecte les autres pods. Cette opération autorise également une évolution indépendante et isolée sans affecter les autres services ou composants de votre système.

Remarque :

Le cluster Kubernetes sur lequel votre organisation est déployée comporte un nombre fini de nœuds informatiques. En faisant évoluer de nombreux services SIG manuellement ou automatiquement, votre organisation peut atteindre la limite des ressources informatiques allouées à ArcGIS Enterprise on Kubernetes. Dans ce cas, contactez votre administrateur informatique pour lui demander d’ajouter des nœuds supplémentaires au cluster Kubernetes. Envisagez d’utiliser la mise à l’échelle automatique du cluster comme solution dans votre environnement.

Mise à l’échelle horizontale

La mise à l’échelle horizontale ajoute plusieurs pods à un déploiement de service. Elle permet, par exemple, de passer d’un pod à plusieurs. Elle est prise en charge pour la mise à l’échelle manuelle comme la mise à l’échelle automatique.

L’exemple ci-dessus illustre la mise à l’échelle horizontale pour un service de géotraitement qui s’exécute en mode dédié. Comme des pods supplémentaires sont nécessaires, le déploiement de service est ajusté en conséquence, que ce soit manuellement ou automatiquement. Dans cet exemple, un réplica de pod supplémentaire est ajouté au déploiement de service.

Dans l’exemple suivant, un déploiement de service d’entités partagé est ajusté horizontalement par ajout de réplicas de pods au déploiement. Dans l’ensemble initial des ressources partagées, il existe trois services d’entités hébergés par quatre pods. Comme la demande régulière a augmenté, les pods du déploiement de service sont passés à huit.

Mise à l’échelle verticale

La mise à l’échelle verticale ajoute un processeur ou de la mémoire au jeu actuel de pods dans un déploiement ; cette option est prise en charge dans le cadre de la mise à l’échelle manuelle.

L’exemple ci-dessus illustre la mise à l’échelle vertical pour un service d’imagerie qui s’exécute en mode dédié. Comme une capacité supplémentaire est nécessaire, les pods dédiés peuvent être ajustés en conséquence, que ce soit manuellement ou automatiquement. Dans ce cas, les ressources augmentées (CPU, mémoire ou les deux), sont allouées au pod.

Dans un autre exemple, lorsqu’un service de carte en mode dédié n’a plus besoin de ressources supplémentaires, ses ressources ont diminué verticalement.

Dans l’exemple suivant, la mise à l’échelle verticale est utilisé pour un déploiement de service de carte partagé. Comme un CPU ou de la mémoire sont nécessaires, les pods dédiés peuvent être ajustés en conséquence. Dans ce cas particulier, les ressources de CPU ou de mémoire augmentées sont allouées aux trois pods impliqués.

Scénarios

Afin de répondre aux exigences de performances tout en assurant l’utilisation des ressources par votre organisation , il est important de comprendre quand et comment adapter les ressources disponibles pour vos services. Les exemples suivants sont des scénarios hypothétiques dans lesquels des administrateurs d’organisation doivent envisager quand il convient d’adapter leurs ressources :

• Une carte Web dans une organisation publique reçoit subitement un volume de trafic élevé et les utilisateurs rencontrent des problèmes de performances. L’administrateur de l’organisation consulte les journaux système et identifie qu’un service de carte utilisé par la carte Web est surchargé. Il commence par modifier le mode de service en utilisant des instances dédiées au lieu d’instances partagées. Il augmente ensuite les réplicas de pods dans le déploiement de service. En fournissant des ressources dédiées au service de carte, l’administrateur s’assure que le trafic élevé du service est géré sans problème de performances.
• Une société d’arpentage a accumulé des centaines de services d’entités dans son organisation. Puisque ils utilisent tous le mode partagé, un seul déploiement de service les prend en charge. Aucun service ne reçoit un trafic élevé, mais l’utilisation globale du contenu SIG de l’organisation a pour effet de surcharger le déploiement de service. L’administrateur de l’organisation choisit de faire évoluer manuellement le service en augmentant le nombre de réplicas de pods dans le déploiement de service. Avec l’exécution d’un plus grand nombre d’instances partagées, le trafic vers les nombreux services d’entités de l’organisation est mieux géré.
• Au cours d’un projet de migration de contenu, l’organisation SIG d’une municipalité republie de nombreuses cartes Web et couches Web sur son organisation. Pressée par les délais, la municipalité veut effectuer cette publication rapidement. Comme la publication des services sous-jacents aux cartes Web et aux couches Web est effectuée par le service utilitaire PublishingTools, les ressources machine disponibles pour ce service utilitaire déterminent la vitesse potentielle de la publication. L’administrateur de l’organisation augmente temporairement les réplicas de pods dans le déploiement de service PublishingTools en vue d’optimiser la publication au cours du projet. Une fois le projet terminé, il réduit les réplicas de pods dans le déploiement de service pour préserver les ressources machine.

• En examinant les deux premiers scénarios ci-dessus illustrant un service de carte surchargé ou l’utilisation simultanée d’un grand nombre de services d’entités entraînant la saturation du système, la mise à l’échelle manuelle d’un service de carte dédié ou le déploiement de service d’entités partagé ne semblent pas être pas la méthode la plus appropriée. La mise à l’échelle manuelle implique une surveillance constante de la charge et une bonne compréhension des types de charge afin de déterminer le nombre de pods à utiliser. Si une charge est intermittente et imprévisible, ajouter manuellement un grand nombre de pods entraînera un gaspillage des ressources dès lors que la charge pesant sur le système est réduite. Inversement, vous voulez que le système soit en mesure d’évoluer si davantage de pods sont nécessaires face à de lourdes charges.

  ll s’agit d’un cas de figure où un administrateur tire parti de la mise à l’échelle automatique. La mise à l’échelle automatique permet de maintenir un nombre minimal de pods et de fixer le nombre maximal de pods que le système peut atteindre selon les seuils de processeurs que vous avez définis. Cette méthode assure une détection automatique du moment où il est nécessaire d’augmenter ou de diminuer le nombre de pods en fonction de l’évolution de la charge. Cela évite de devoir surveiller en permanence un système et assure la bonne gestion des ressources de celui-ci.

Ajuster le mode de service

Si un service d’entités ou de carte qui utilise des ressources partagées reçoit un trafic constant, vous pouvez changer le mode de service pour utiliser des ressources dédiées. Cela permet d’ouvrir un nouveau pool de ressources de service dédié à ce service.

Mise à l’échelle manuelle

Lorsque la demande des services est prévisible ou constante, vous pouvez faire évoluer un déploiement de service en spécifiant le nombre de pods alloués à un service ou en augmentant les ressources (processeur/mémoire) disponibles pour le service. Cette option est utile lorsque le nombre de ressources dédiées au service semble inadapté et que les utilisateurs rencontrent des problèmes de performances.

Si après avoir surveillé le service, vous constatez que cette demande a augmenté ou si des problèmes de performances du service ont été signalés, vous pouvez augmenter le nombre de pods comme il convient. Lorsque la demande commence à baisser, vous pouvez diminuer le nombre de pods.

Mise à l'échelle automatique

Lorsque la demande des services est imprévisible ou intermittente, vous pouvez activer la mise à l’échelle automatique pour optimiser l’efficacité des ressources système.

Quand vous activez la mise à l’échelle automatique sur un service, les réplicas de pods dans un déploiement de service augmentent ou diminuent automatiquement conformément à la demande. Le déploiement de service utilise vos critères prédéfinis en termes de CPU ou de mémoire pour calculer le nombre de pods à la hausse ou à la baisse et les ajuste en conséquence.

Remarque :

Pour bénéficier de la mise à l’échelle automatique horizontale de pod dans ArcGIS Enterprise on Kubernetes, le serveur de métriques est nécessaire afin de retirer des métriques de consommation de ressources de pod du processus kubelet sur chaque nœud en cours d’exécution. Pour plus d’informations, reportez-vous à la rubrique Serveur de métriques Kubernetes.

Rôle des instances de service

Les déploiements de service qui ne sont pas hébergés (comme les services de carte, d’imagerie ou de géotraitement) contiennent des instances de service qui s’exécutent dans chaque pod du déploiement de service. Ils représentent la capacité de chaque pod et sont les processus sous-jacents utilisés pour traiter les requêtes envoyées à n’importe lesquels de ces services. L’ajustement et la mise à l’échelle automatiques de ces processus sont pris en charge. Toutefois il est recommandé d’ajuster et de mettre à l’échelle au niveau des pods pour tirer parti des avantages offerts par Kubernetes (tolérance à la panne, isolement, résilience, évolution automatique, etc.).