Haute disponibilité pour vos applications

Ce document fournit des conseils techniques et des bonnes pratiques pour concevoir et déployer des charges de travail disponibilité élevée (HA) dans plusieurs zones d'un univers Google Distributed Cloud (GDC) sous air gap. Ce guide décrit les principaux modèles d'architecture, les configurations de service et les considérations opérationnelles permettant de minimiser les temps d'arrêt et d'assurer la continuité de l'activité.

Les stratégies décrites dans ce document sont destinées aux professionnels techniques suivants :

  • Architectes cloud qui conçoivent des infrastructures et des architectures d'application résilientes.

  • Ingénieurs DevOps et ingénieurs en fiabilité des sites qui mettent en œuvre des stratégies de déploiement, d'automatisation, de surveillance et de réponse aux incidents pour les charges de travail à haute disponibilité.

  • Développeurs d'applications qui créent des applications tolérantes aux pannes et qui s'intègrent aux modèles à haute disponibilité.

Pour en savoir plus, consultez la documentation sur les audiences pour GDC sous air gap.

Importance de la haute disponibilité

Dans les systèmes distribués modernes, il est essentiel de planifier la haute disponibilité. Les temps d'arrêt peuvent entraîner des perturbations importantes de l'activité, des pertes de revenus et une mauvaise expérience utilisateur.

Pour les charges de travail exécutées dans des centres de données privés à l'aide de GDC, la disponibilité est souvent directement corrélée à la réussite opérationnelle de base, en particulier pour les applications sensibles à la latence ou critiques. Il est essentiel de concevoir la haute disponibilité dès le départ pour créer des services résilients et fiables.

GDC offre des capacités hyperscale dans votre environnement sous air gap avec plusieurs centres de données déconnectés, ou zones. La haute disponibilité de vos applications multizones dépend de services multizones, tels que l'équilibrage de charge et le stockage asynchrone. Pour en savoir plus sur les services importants à utiliser pour la haute disponibilité, consultez les sections Évolutivité et équilibrage de charge et Déploiement d'applications à haute disponibilité dans plusieurs zones avec stockage asynchrone de ce document.

Capacités hyperscale, fournies localement

GDC étend l' Google Cloud infrastructure et les services à la périphérie du réseau et à vos centres de données. GDC fournit une solution matérielle et logicielle entièrement gérée, ce qui vous permet d'exécuter Google Kubernetes Engine (GKE) sur des clusters GDC et d'autres Google Cloud services plus près de l'endroit où vos données sont générées et utilisées.

Ce document se concentre sur les univers GDC configurés dans une topologie multizone. Dans cette configuration, un seul univers comprend plusieurs zones physiquement isolées zones au sein du même emplacement.

Ces zones disposent d'une alimentation, d'un refroidissement et d'une mise en réseau indépendants, ce qui offre une protection contre les défaillances localisées de l'infrastructure physique. La connectivité réseau à faible latence et à bande passante élevée entre les zones permet la réplication des données et le basculement rapide, ce qui constitue la base de la création d'applications à disponibilité élevée.

Évolutivité et équilibrage de charge

Au-delà de la redondance de base des composants, la gestion efficace du trafic et l'évolutivité transparente sont essentielles pour maintenir une haute disponibilité, en particulier en cas de conditions de charge variables. GDC fournit plusieurs mécanismes d'équilibrage de charge et de gestion sophistiquée du trafic.

Équilibreur de charge externe pour le trafic nord-sud

Pour exposer vos applications aux utilisateurs ou aux systèmes en dehors d'un cluster GKE sur GDC (trafic nord-sud), utilisez les fonctionnalités d'équilibrage de charge externe gérées de GDC. Le service d'équilibreur de charge externe (ELB) fournit ces fonctionnalités et s'intègre de manière transparente à Kubernetes.

Les principales caractéristiques du service ELB qui assurent la haute disponibilité et l'évolutivité sont les suivantes :

  • Service géré : s'exécute en tant que service spécifique à GDC, et est conçu pour la haute disponibilité et la résilience dans un environnement sous air gap.

  • Accès externe : provisionne des adresses IP externes stables à partir de pools gérés par GDC, ce qui fournit un point d'entrée cohérent pour les clients externes.

  • Intégration de l'équilibreur de charge à Kubernetes : provisionne et configure automatiquement l'équilibreur de charge lorsque vous créez un Service Kubernetes de type: LoadBalancer sans annotations internes spécifiques.

  • Connaissance des zones : distribue le trafic entrant entre les pods d'application sains s'exécutant dans toutes les zones disponibles de l'univers GDC. L'équilibreur de charge externe s'appuie sur des sondes d'aptitude des pods pour déterminer l'état du backend.

  • Évolutivité : gère la distribution du trafic externe à mesure que votre application évolue horizontalement entre les nœuds et les zones.

Pour assurer la haute disponibilité du trafic externe entrant afin que les requêtes client soient automatiquement redirigées en cas de défaillance des zones ou des instances, nous vous recommandons d'utiliser un équilibreur de charge externe.

Pour en savoir plus, consultez Configurer des équilibreurs de charge externes.

Équilibreur de charge interne pour le trafic est-ouest

Pour la communication entre les services s'exécutant dans le même cluster GKE sur GDC (trafic est-ouest), GDC fournit un équilibreur de charge interne (ILB). Un équilibreur de charge interne est essentiel pour dissocier les services internes et fournir des chemins de communication internes qui sont également disponibilité élevée et évolutifs.

Les principales caractéristiques du service ILB qui assurent la haute disponibilité et l'évolutivité sont les suivantes :

  • Accès interne : provisionne une adresse IP interne stable accessible uniquement depuis le réseau GDC, par exemple les nœuds de cluster ou d'autres services internes.

  • Intégration de l'équilibreur de charge à Kubernetes : provisionne l'équilibrage de charge en créant un Service Kubernetes de type: LoadBalancer avec une annotation spécifique pour indiquer qu'il doit être interne. Par exemple, networking.gke.io/load-balancer-type: "Internal".

  • Connaissance des zones : distribue le trafic entre les pods de backend sains, qui sont identifiés à l'aide de sondes d'aptitude, situés dans toutes les zones disponibles. Cette distribution empêche les échecs de communication interne si une zone rencontre des problèmes.

  • Découverte et dissociation des services : fournit une adresse IP interne stable et un nom DNS avec l'intégration de kube-dns et de CoreDNS. Les services peuvent se découvrir et communiquer entre eux, ce qui évite aux clients de connaître les adresses IP des pods individuels.

  • Évolutivité : facilite le scaling des services de backend internes en distribuant le trafic entre toutes les instances répliquées saines disponibles.

L'utilisation d'un équilibreur de charge interne pour la communication interne entre les services rend le flux de trafic interne résilient aux défaillances de zone et assure un scaling efficace, en complément de la haute disponibilité fournie par l'équilibreur de charge externe et la distribution de calcul sous-jacente. Cette stratégie est souvent utilisée pour les applications à plusieurs niveaux où les API frontend doivent communiquer avec les API ou les bases de données backend au sein du cluster Kubernetes.

Pour en savoir plus, consultez Configurer des équilibreurs de charge internes.

Déploiement d'applications à haute disponibilité dans plusieurs zones avec stockage asynchrone

GDC vous permet d'exécuter l'infrastructure et les applications plus près de vos sources de données. Pour déployer des applications à haute disponibilité avec une source de données résiliente, implémentez la réplication de stockage asynchrone pour la persistance des données et la reprise après sinistre.

Les zones représentent des domaines de défaillance distincts au sein d'un même univers. En distribuant les composants d'application et en répliquant les données entre les zones, vous améliorez considérablement la résilience aux défaillances matérielles localisées ou aux événements de maintenance.

Pour en savoir plus, consultez Protection des données avec le stockage multizone.

Étape suivante