Points à prendre en compte pour utiliser un Cloud relational store

Le stockage système est un prérequis fondamental de ArcGIS Enterprise pour prendre en charge les processus administratifs et d’autres processus dans l’organisation. Sont inclus dans cette exigence en matière de stockage deux stores relationnels qui prennent en charge les données d’entités hébergées et les éléments d’administration tels que les paramètres de personnalisation et de configuration.

Un administrateur peut configurer des volumes persistants pour prendre en charge les stores relationnels, ou configurer le store relationnel en dehors du cluster à l’aide d’un service de base de données Cloud pris en charge. Cette option peut être plus adaptée pour les administrateurs qui ont déjà géré des bases de données PostgreSQL, car elle peut offrir des avantages en matière de fiabilité, de mise à l’échelle et de performances lorsque vous utilisez des services Cloud à partir de Amazon Web Services (AWS), Microsoft Azure et Google Cloud.

Comme pour toutes les offres de service, les fournisseurs de services de base de données cloud peuvent modifier les paramètres et les fonctions de leurs offres, même dans les versions mineures. Il est possible que les modifications effectuées par le fournisseur aient des conséquences négatives sur l’accès à la base de données à partir d’ArcGIS. Pour limiter ces effets négatifs, nous vous recommandons de collaborer avec votre fournisseur cloud pour comprendre les modifications apportées au service et garder votre logiciel ArcGIS à jour pour avoir accès aux dernières mises à jour qui prennent en compte les modifications des services cloud. Effectuez régulièrement des sauvegardes de votre organisation ArcGIS Enterprise et testez votre processus de restauration de sauvegarde.

Les éléments à prendre en compte lors de l’utilisation d’un store relationnel avec ArcGIS Enterprise, y compris l’utilisation du logiciel, les types pris en charge, les exigences et les besoins de maintenance en continu, sont indiqués ci-dessous.

Services de base de données Cloud pris en charge

Les types de services de base de données Cloud suivants sont pris en charge pour une utilisation avec ArcGIS Enterprise on Kubernetes :

  • Amazon RDS for PostgreSQL
  • Amazon Aurora PostgreSQL
  • Azure Database for PostgreSQL - Serveur flexible
  • Google Cloud SQL for PostgreSQL
  • Google Cloud AlloyDB for PostgreSQL

Remarque :

Pour minimiser les problèmes en matière de latence et de connectivité, il est recommandé d’utiliser le même fournisseur Cloud et la même région qu’ArcGIS Enterprise pour tous les services de base de données Cloud.

Spécifications de bases de données

Un cloud relational store configuré avec ArcGIS Enterprise on Kubernetes doit répondre aux exigences suivantes :

  • La version de l’instance PostgreSQL doit être prise en charge pour cette version de ArcGIS Enterprise on Kubernetes
    • ArcGIS Enterprise 12.0 : PostgreSQL version 15.x ou 16.x
    • ArcGIS Enterprise 11.5 : PostgreSQL version 15.x ou 16.x
    • ArcGIS Enterprise 11.4 : PostgreSQL version 15.x
  • La base de données doit être accessible sur le réseau à partir du cluster Kubernetes. Certains groupes de sécurité et pare-feu peuvent bloquer l’accès direct à la base de données par défaut.
  • L’authentification de base de données à l’aide d’un nom d’utilisateur et d’un mot de passe doit être utilisée pour le compte administrateur.
  • Vous devez installer le plug-in PostGIS et activer le type spatial PostGIS. Il s’agit de la valeur par défaut pour AWS et Google Cloud mais elle doit être ajoutée aux extensions autorisées dans Azure. Actuellement, seules la version 3.5.2 et les versions antérieures à 3.5.2 de PostGIS sont prises en charge en raison du problème PostGIS 5978.

Connexions et dimensionnement des instances

Il est important de réfléchir au dimensionnement de votre instance de base de données afin de faire en sorte qu’il soit suffisant, car de nombreux services ne permettent pas le redimensionnement des instances. De plus, le redimensionnement d’une instance après son utilisation peut provoquer des interruptions de service et entraîner des problèmes inattendus.

Chaque connexion à une base de données consomme de la mémoire et du processeur sur les serveurs de base de données, impactant ainsi les besoins matériels.

Par exemple, un pod qui s’exécute pour un service d’entités hébergés peut utiliser jusqu’à 100 connexions à des bases de données en présence de 100 demandes simultanées. Dans la mesure où il est courant d’avoir deux pods en cours d’exécution pour les services d’entités hébergés, 200 connexions doivent être disponibles. Pour gérer d’autres demandes de service, 100 connexions supplémentaires sont recommandées, soit un total de 300 connexions.

Si possible, les pods de service d’entités hébergés utilisent le groupage pour réutiliser les connexions. Ainsi, 300 connexions peuvent être suffisantes pour gérer jusqu’à 1 000 demandes par seconde. Par défaut, la plupart des bases de données Cloud incluent moins de 300 connexions. Il est donc recommandé d’augmenter la limite du nombre de connexions à 300 ou plus.

Remarque :

L’utilisation de pgBouncer comme proxy pour les connexions aux bases de données de pool vers le cloud relational store n’est pas prise en charge.

Les bases de données utilisent la mémoire RAM pour améliorer les performances des données fréquemment utilisées. Les services d’entités hébergés sont généralement ceux qui comptent le plus de données. L’utilisation peut varier considérablement, dans la mesure où de nombreux services peuvent être utilisés occasionnellement, tandis que d’autres sont constamment utilisés. Si vous savez que vos utilisateurs accéderont régulièrement à certains services d’entités hébergés, dont vous pouvez estimer la taille, il peut être utile de prévoir de la mémoire RAM supplémentaire.

Recommandations matérielles

Pour des performances optimales avec une charge moyenne, il est recommandé d’utiliser des instances de base de données présentant les caractéristiques suivantes :

  • 4 processeurs virtuels
  • 16 Go de mémoire RAM

Pour les plus grands volumes de données fréquemment utilisés, il est recommandé d’ajouter davantage de mémoire RAM.

Stockage

Les besoins de votre organisation en matière de stockage varient en fonction des données que vous utilisez. Une recommandation de base est de disposer de 100 Go de stockage, ce qui est adapté à une centaine de services d’entités hébergés avec peu de pièces jointes. Les pièces jointes des entités, notamment les images haute résolution, peuvent consommer beaucoup d’espace. Si vous prévoyez d’avoir des pièces jointes volumineuses, il est essentiel que vous collaboriez avec votre département SIG pour estimer l’espace de stockage, car certaines organisations ont besoin de plus de 1 To de stockage pour répondre à leurs besoins.

Utilisation du logiciel

Lors de la configuration d’un stockage relationnel Cloud, pensez que la base de données qui en résulte doit être exclusivement utilisée pour ArcGIS Enterprise on Kubernetes. Il est recommandé qu’il n’existe aucune autre base de données ou données dans la base de données. De plus, le logiciel crée des bases de données, des structures et des utilisateurs dans la base de données, parmi lesquels :

  • Une géodatabase d’entreprise pour stocker les données des services d’entités hébergés
  • Une base de données pour stocker les informations sur le contenu et les éléments
  • Une base de données pour stocker les informations de webhook

L’utilisateur de base de données administrateur que vous indiquez à ArcGIS Enterprise est utilisé lors de la configuration initiale et des processus de sauvegarde et de restauration. Des utilisateurs spécifiques avec des privilèges moindres seront créés pour l’utilisation opérationnelle, pour garantir davantage de sécurité.

Maintenance continue

Lorsque vous utilisez un store relationnel Cloud, votre administrateur de base de données ou IT doit poursuivre la maintenance et la gestion continues du système. Voici quelques exemples :

  • Gérer le système de base de données en appliquant des correctifs et en suivant l’utilisation du matériel, en particulier le stockage.
  • Gérer les paramètres du système, par exemple le nombre de connexions.

Le logiciel ArcGIS Enterprise, en revanche, poursuit la maintenance logicielle continue. Voici quelques exemples :

  • Sauvegarder et restaurer la base de données lors des processus de routine de sauvegarde et de restauration de l’organisation.
  • Gérer les colonnes, les tables, les indices et les utilisateurs.

Les administrateurs peuvent créer leurs propres sauvegardes de la base de données, mais il est essentiel de vous rapprocher du support technique Esri avant de restaurer une sauvegarde de la base de données de manière isolée, car cela peut provoquer des problèmes de synchronisation avec d’autres exigences fondamentales, par exemple l’object store.

Mise à niveau d’un cloud relational store

Lorsque vous utilisez un cloud relational store, la mise à niveau de ArcGIS Enterprise on Kubernetes ne met pas automatiquement à niveau la version de l’instance de base de données. Reportez-vous à la documentation de votre service de base de données cloud pour obtenir des instructions sur la mise à niveau de l’instance de base de données, notamment des informations sur les prérequis, le temps d’arrêt prévu, les pratiques recommandées pour les sauvegardes et les tests, et les options de récupération des données en cas d’échec de la mise à niveau. Avant de mettre à niveau l’instance de base de données, assurez-vous que la nouvelle version de base de données est prise en charge pour votre version de ArcGIS Enterprise on Kubernetes.