Les organisations qui ont les exigences les plus élevées en termes de temps de disponibilité doivent être en mesure de résister à des pannes plus importantes, telles que la perte d’une zone de disponibilité entière. Bien que la mise en service d’un cluster Kubernetes qui s’étend sur plusieurs zones de disponibilité soit simple dans des fournisseurs de Cloud géré, vous devez tenir compte d’exigences d’administration supplémentaires lors des phases de déploiement, de configuration et d’exécution du logiciel ArcGIS Enterprise on Kubernetes.
Les sections suivantes décrivent les éléments et les exigences à prendre en compte avant la configuration de l’organisation, les effets anticipés de la perte de fonctionnalité dans une zone de disponibilité, et la manière dont un administrateur peut vérifier l’intégrité du système sous-jacent après la récupération de la fonctionnalité dans cette zone de disponibilité.
Au minimum, le cluster Kubernetes dans lequel l’application est déployée doit répondre aux exigences suivantes :
- Les groupes de noœuds worker doivent s’étendre sur au moins trois zones de disponibilité.
- La capacité des nœuds worker doit être en mesure de rééquilibrer toutes les charges de travail sur deux zones de disponibilité lors d’une panne.
Déploiement et configuration
Lors du déploiement de ArcGIS Enterprise on Kubernetes dans un cluster sur plusieurs zones de disponibilité, la présence de charges de travail avec état signifie que lorsque vous utilisez des périphériques de stockage par bloc, ces disques associés dépendant de la zone de disponibilité.
Pour vous assurer que les réplicas associés de chaque ensemble avec état sont répartis sur la topologie adéquate, vous pouvez utiliser le nouveau fichier des propriétés de déploiement, K8S_TOPOLOGY_AVAILABILITY_KEY, qui doit être mis à jour avant l’exécution du script de déploiement. La modification de cette propriété avec une valeur autre que kubernetes.io/hostname introduit une spécification topologySpreadConstraint dans les ensembles avec état, ce qui garantit l’absence de déséquilibre ou de réplicas dans chaque zone de disponibilité.
Pendant la configuration de l’organisation, configurez l’organisation avec le profil d’architecture de disponibilité améliorée pour garantir la disponibilité la plus élevée. Il s’agit du seul profil qui garantit la couverture adéquate pour toutes les charges de travail avec état en cas de défaillance d’une zone de disponibilité.
Même lorsque vous utilisez le profil d’architecture de disponibilité améliorée, plusieurs déploiements ne présentent qu’une seule réplique car ils varient considérablement en fonction des exigences spécifiques de l’organisation. Vous devez envisager de faire évoluer les déploiements suivants avec plus d’un réplica afin de réduire davantage les temps d’arrêt :
- arcgis-enterprise-apps
- arcgis-enterprise-manager
- arcgis-enterprise-portal
- arcgis-enterprise-web-style-app
- arcgis-help
- arcgis-javascript-api
- arcgis-service-api
- arcgis-service-lifecycle-manager
- arcgis-featureserver-webhook-processor
- arcgis-gpserver-webhook-processor
Chacun des déploiements répertoriés ci-dessus, à l’exception de arcgis-enterprise-web-style-app, met un peu moins de temps à redémarrer après une perte de zone de disponibilité que le traitement de reprise après incident d’un data store relationnel. L’ajout d’un réplica supplémentaire de tous les déploiements indiqués entraîne l’ajout d’environ 1 UC supplémentaire et de 0,5 Gio de RAM au nombre total de requêtes d’espace de noms, ainsi que de 5 UC supplémentaires et de 2,5 Gio de RAM aux limites totales de l’espace de noms.
Lors de la publication des services, tous les services dédiés doivent être définis pour exécuter un minimum de deux pods pour éviter toute interruption lors de la replanification. Les déploiements à instance partagée doivent également être dimensionnés sur au moins deux réplicas dans le même objectif.
Effets d’une perte de zone de disponibilité
La signification et l’impact de la zone de disponibilité varient en fonction des services Cloud affectés. La perte d’un service spécifique, comme un ordinateur ou un stockage, peut avoir un impact considérable sur les charges de travail en cours d’exécution tandis que d’autres pannes basées sur le réseau, telles que la résolution DNS ou de fortes augmentations de la latence, peuvent affecter la façon dont les microservices sont capables de communiquer entre eux.
Lors du basculement du store relationnel, certaines fonctions, telles que la connexion, la modification des services d’entités hébergés et le chargement de couches hébergées, peuvent être dégradées pendant un court laps de temps. Une fois l’instance de secours promue en instance principale, toutes les fonctionnalités de l’organisation doivent être dans un état stable.
Vérification de l’intégrité de l’organisation
Les administrateurs peuvent utiliser les rapports intégrés de contrôle d’intégrité pour évaluer l’intégrité de leur site. Ils peuvent également examiner les charges de travail de l’espace de noms pour détecter les problèmes de démarrage de pods et d’autres incidents susceptible de se produire.
Pendant une panne de zone de disponibilité
Si une zone de disponibilité est perdue lors de l’utilisation du stockage par bloc pour les volumes persistants, les pods des ensembles avec état ne peuvent pas être reprogrammés dans d’autres zones de disponibilité en raison des exigences d’affinité de volume.
Pour les data stores qui le nécessitent, un quorum est maintenu afin que les services associés puissent fonctionner dans un état dégradé. Étant donné que le store relationnel est un composant central dont dépendent plusieurs autres services, il est possible de réinitialiser l’instance de secours par l’intermédiaire de l’API d’administration. Cette opération supprime l’ensemble avec état ainsi que la réclamation de volume persistant associée, et crée un nouvel ensemble avec état. Cela permet à l’instance de secours de se resynchroniser avec l’instance principale après la génération dans l’une des zones de disponibilité restantes.
Après une panne de zone de disponibilité
Si les services sont restaurés dans la zone de disponibilité touchée par une panne, les charges de travail associées qui étaient bloquées dans un état en attente doivent être démarrées, ce qui peut être confirmé par l’intermédiaire de l’API Kubernetes.
Si les services ne peuvent pas être restaurés dans la zone de disponibilité existante, assurez-vous que le cluster possède au moins trois zones de disponibilité restantes et, si ce n’est pas le cas, étendez le cluster sur une zone de disponibilité supplémentaire. Une fois cette opération terminée, créez une sauvegarde, annulez le déploiement et effectuez un nouveau déploiement, puis procédez à la restauration à partir de la sauvegarde.
Vous avez un commentaire à formuler concernant cette rubrique ?