Minimization des pertes de données et des temps d’arrêt

Avec ArcGIS Enterprise, votre organisation peut créer et partager des informations géographiques, des cartes et des applications, et effectuer des analyses géographiques dans un environnement collaboratif. Le contenu et les outils d’un déploiement ArcGIS Enterprise sont nécessaires aux fonctions de votre organisation. Aussi, assurez-vous que le déploiement reste accessible autant que possible aux utilisateurs, avec une perte minimale des données en cas d’incident. Pour y parvenir, faites appel à une stratégie de récupération d’urgence ou de basculement.

Les fonctionnalités intégrées à ArcGIS Enterprise permettent d’effectuer les opérations suivantes :

• Sélectionnez un profil d’architecture qui répond aux critères de votre organisation en termes de redondance et de disponibilité.
• Conservez les sauvegardes de votre déploiement ArcGIS Enterprise afin de pouvoir le restaurer en cas d’incident.

Au moment de choisir une option appropriée, tenez compte des besoins de votre organisation, ainsi que de votre connaissance de la méthode envisagée. Posez-vous les questions suivantes :

• Quel est le temps d’arrêt acceptable (le cas échéant) ?
• Quelles sont les pertes de données acceptables (le cas échéant) ?
• Combien de ressources (matériel, licences et personnel) votre organisation consacre-t-elle à la prévention contre la perte de données et les temps d'arrêt ?

Haute disponibilité dans ArcGIS Enterprise on Kubernetes

ArcGIS Enterprise on Kubernetes offre une résilience et une haute disponibilité intégrée à l’aide du comportement natif de l’agrégat Kubernetes. Le fait que Kubernetes organise et gère les pods et les cycles de vie des conteneurs permet de s’assurer que les pods qui activent le déploiement peuvent être récupérés rapidement en cas d’échec.

Tous les conteneurs dans chaque pod sont configurés avec des probes liveness et readiness pour s’assurer que le cycle de vie et la surveillance des pods sont gérés par l’agrégat. En fonction des paramètres de la règle anti-affinity, ArcGIS Enterprise on Kubernetes respecte les principes de base de la haute disponibilité, notamment : aucun point de défaillance, détection et récupération automatiques des composants ayant échoué.

Reprise après incident

Lorsque ArcGIS Enterprise on Kubernetes est déployé avec un profil d’architecture hautement disponible, le niveau de redondance dans les pods est augmenté et le risque de temps d’arrêt imprévus est réduit. Tous les pods essentiels et critiques sont déployés dans des ensembles avec état ou de réplicas. Ce comportement permet à l’agrégat Kubernetes de replanifier automatiquement tous les pods ayant échoué sur des nœuds identiques ou différents de l’agrégat sans que l’administrateur n’intervienne.

L’échec d’un pod dans un ensemble avec état ou un ensemble de réplicas contenant deux réplicas ou plus n’a généralement aucun impact sur l’accès de l’utilisateur au déploiement. Bien que les pods en bonne santé continuent de fonctionner, l’agrégat Kubernetes replanifie automatiquement les pods ayant échoué. Les deux situations suivantes peuvent toutefois impacter les opérations commerciales :

• La détection d’un échec du data store relationnel principal et sa récupération ultérieure, ou la promotion d’un data store relationnel secondaire peuvent prendre quelques minutes. Pendant cette période, il est possible que les utilisateurs n’aient pas accès au déploiement.
• Si le profil d’architecture de disponibilité standard est sélectionné, l’échec d’un des pods de stockage d’objets ou de la moitié ou plus des volumes persistants associés au stockage d’objets a pour effet de rendre le déploiement en lecture seule. Lorsque le déploiement est en lecture seule, les utilisateurs peuvent accéder au contenu existant, mais il ne peuvent pas créer ou modifier le contenu.