Préparer la mise à niveau

En procédant à la mise à niveau vers une nouvelle version de ArcGIS Enterprise on Kubernetes, votre organisation bénéficie de nouvelles fonctionnalités et de fonctions améliorées. Avant de procéder à la mise à niveau, découvrez les nouvelles fonctionnalités et identifiez les changements susceptibles d’affecter les membres de votre organisation.

Vous devez mettre à niveau ArcGIS Enterprise on Kubernetes avant la mise à niveau de Kubernetes vers une version prise en charge.

Attention :

Effectuez une sauvegarde de votre organisation avant de réaliser une mise à niveau.

Conseil :

Vous pouvez définir ou modifier l’affinité des nœuds et les tolérances des pods qui sont utilisés pendant les mises à jour ou les mises à niveau. Une fois créée, la politique de placement s’applique à chaque fois qu’une tâche de mise à niveau est créée. Les valeurs que vous définissez sont conservées pour toutes les mises à jour et mises à niveau ultérieures jusqu’à ce qu’elles soient réinitialisées. Pour plus de détails, reportez-vous à la rubrique Mettre à jour (configuration des mises à niveau).

Exigences liées à la mise à niveau

Les conditions suivantes doivent être remplies avant une mise à niveau :

• Si une mise à jour requise est disponible, vous devez l’appliquer avant de migrer vers cette version. Consultez les notes de publication pour en savoir plus sur la dernière mise à jour requise.
• Vous devez disposer d’une licence ArcGIS Enterprise on Kubernetes unifiée pour cette version.
• Vous devez mettre à jour les valeurs de quota des ressources dans votre espace de noms selon la configuration requise de la version.
• Votre environnement doit répondre aux normes de sécurité de pod, telles que les normes d’admission de sécurité de pod avant la mise à niveau.
• Si votre environnement se trouve dans Red Hat OpenShift, il doit répondre aux contraintes de contexte de sécurité actuelles.
• Les tailles des volumes des data stores doivent correspondre aux exigences minimales requises pour la version que vous mettez à niveau. Si l’extension du volume n’est pas disponible pour le provisionneur utilisé par la classe de stockage, restaurez une sauvegarde pour configurer une nouvelle organisation avec des volumes supérieurs. Le non-respect des conditions de stockage minimales requises risque d’aboutir à des problèmes lors du chargement des éléments de votre organisation et du démarrage des services.
• Si vous avez provisionné les volumes persistants statiques, vous devez provisionner davantage de stockage pour respecter la configuration de mise à niveau requise. Pour en savoir plus, consultez la section ci-après.
• Si votre stockage provisionné dispose de volumes persistants dynamiques, le stockage disponible doit être suffisant pour accueillir le volume de paquetage d’éléments, le volume d’objet et le volume de file d’attente supplémentaires.
• Pour mettre à niveau le store relationnel, une sauvegarde est créée dans le même volume persistant que l’instance de data store relationnel. Cette sauvegarde requiert qu’au moins 50 % de la taille de la base de données soit disponible. Par exemple, si le store relationnel utilise actuellement 100 Go de stockage, au moins 50 Go doivent être disponibles sur le volume persistant associé avant la mise à niveau, pour atteindre la taille de volume totale requise de 150 Go ou plus. Pour des instructions sur l’augmentation de la taille du volume, reportez-vous à la rubrique Gérer le stockage requis.
• La valeur de limites de mémoire pour le service ReportingTools doit être définie sur 3 Gio, voire plus. Pour plus de détails sur la mise à jour de cette valeur, reportez-vous à la rubrique Gérer les déploiements système.
• Exécutez le script préalable à la mise à niveau. Ce script détecte et traite les exigences fonctionnelles pour se conformer à la configuration requise par la version logicielle actuelle.
• Si vous avez configuré un Web Adaptor avec votre organisation, consultez la configuration requise en matière d’installation et de mise à niveau.
• Lors du déploiement de ArcGIS Enterprise on Kubernetes, si vous avez utilisé le registre de conteneur de votre organisation ou si vous avez déployé dans un environnement non connecté , vous devez copier les images de conteneur requises à partir du référentiel Esri dans votre registre avant de procéder à la mise à jour ou à la mise à niveau.
• Si le déploiement utilise plusieurs zones de disponibilité, chacune doit disposer d’une capacité adéquate pour prendre en charge les réplicas supplémentaires des charges applicatives avec état. Ceci peut nécessiter la mise à l’échelle temporaire du groupe de nœuds au cours des mises à jour ou des mises à niveau.
• Si vous avez créé des tableaux de bord personnalisés à l’aide de l’application de visionneuse de métriques Grafana dans une version antérieure à la version 11.2, vous devez exporter ces tableaux de bord avant de procéder à une mise à niveau. Grafana ne figure plus dans ArcGIS Enterprise on Kubernetes, mais vous pouvez toujours l’utiliser ou utiliser d’autres applications tierces pour afficher des statistiques internes ou externes au cluster.

  En savoir plus sur la migration de tableaux de bord existants vers une instance externe

• Toutes les licences ArcGIS Pro hors connexion doivent être archivées par les membres de votre organisation. Vous pouvez afficher l’activité des licences pour déterminer les membres qui ont extrait leur licence ArcGIS Pro afin de l’utiliser hors connexion. Pour plus d’informations sur la manière d’archiver une licence hors connexion, reportez-vous à la rubrique Archiver une licence hors connexion.
• Si vous utilisez un cloud relational store, la version de base de données doit être prise en charge pour votre version actuelle de ArcGIS Enterprise on Kubernetes et pour la version vers laquelle vous mettez à niveau. Cela peut nécessiter la mise à niveau de l’instance de base de données du cloud relational store.

Ajuster les volumes persistants statiques pour la mise à niveau

Avant une mise à niveau, les éléments suivants doivent être configurés avec un volume persistant supplémentaire :

• Chaque pod présent dans le déploiement de l’API du portail de l’organisation doit être configuré avec un item-packages-volume supplémentaire.
• Chaque pod présent dans le stockage système en mémoire de l’organisation doit être configuré avec un in-memory-volume supplémentaire.
• Chaque pod présent dans le stockage système du queue store de l’organisation doit être configuré avec un queue-volume supplémentaire.

Voici quelques exemples :

• Si le déploiement de l’API du portail est configuré avec trois pods en cours d’exécution, vous devez provisionner trois item-packages-volumes supplémentaires.
• Si le in-memory-volume est configuré avec un pod en cours d’exécution, vous devez provisionner un in-memory-volume supplémentaire.
• Si le queue-volume est configuré avec un pod en cours d’exécution, vous devez provisionner un queue-volume supplémentaire.

Dans tous les cas, vous devez configurer les volumes persistants supplémentaires selon des spécifications équivalentes à celles qui ont été indiquées durant le déploiement.

Une fois la mise à niveau terminée, le déploiement de l’API du portail, le stockage en mémoire et le stockage en file d’attente utilisent les volumes persistants qui viennent d’être provisionnés ainsi que la réclamation de volume persistant (PVC). Le jeu de volumes d’origine peut alors être supprimé. Il est fortement recommandé de supprimer tout volume persistant associé au stockage en file d’attente, car les volumes persistants publiés lors des mises à niveau ou mises à jour précédentes ne doivent jamais être réutilisés.