Haute disponibilité pour vos applications

Ce guide stratégique fournit des conseils techniques et des bonnes pratiques pour concevoir et déployer des charges de travail à disponibilité élevée (HA) dans un univers Google Distributed Cloud (GDC) isolé et configuré avec plusieurs zones, ou multizones. Ce guide décrit les principaux modèles d'architecture, les configurations de service et les considérations opérationnelles nécessaires pour minimiser les temps d'arrêt et assurer la continuité des activités pour les applications exécutées sur GDC.

Les stratégies de haute disponibilité sont destinées aux professionnels techniques impliqués dans la conception, le déploiement et la gestion d'applications sur GDC, y compris les suivants :

  • Architectes cloud du groupe des administrateurs de plate-forme : concevoir des architectures d'infrastructure et d'application résilientes sur GDC.

  • Ingénieurs DevOps et ingénieurs en fiabilité des sites (SRE) du groupe des opérateurs d'applications : implémentation de stratégies de déploiement, d'automatisation, de surveillance et de réponse aux incidents pour les charges de travail HA.

  • Développeurs d'applications du groupe des opérateurs d'applications : ils créent des applications tolérantes aux pannes et qui s'intègrent parfaitement aux modèles d'infrastructure HA.

Pour en savoir plus, consultez la documentation sur les audiences pour GDC en mode air-gapped.

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, qu'ils soient planifiés ou non, peuvent entraîner des perturbations importantes pour l'activité, une perte de revenus, une atteinte à la réputation et une mauvaise expérience utilisateur. Pour les charges de travail exécutées en périphérie ou dans des centres de données privés à l'aide de GDC, la disponibilité est souvent directement corrélée au succès opérationnel de base, en particulier pour les applications sensibles à la latence ou critiques. Il est essentiel de concevoir des services à haute disponibilité dès le départ pour créer des services résilients et fiables.

Des capacités hyperscale, fournies localement

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

Ce guide se concentre spécifiquement sur les univers GDC configurés dans une topologie multizone. Avec la multizone, un seul univers GDC comprend plusieurs zones physiquement isolées au sein d'un même emplacement, comme un campus de centres de données ou une zone métropolitaine. Ces zones disposent d'une infrastructure indépendante pour l'alimentation, le refroidissement et la mise en réseau, ce qui permet de se protéger contre les défaillances localisées de l'infrastructure physique. La connectivité réseau à faible latence et à bande passante élevée entre les zones d'un univers GDC permet la réplication synchrone 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 des composants de base, la gestion efficace du trafic et l'évolutivité fluide sont essentielles pour maintenir une haute disponibilité, en particulier avec des conditions de charge variables. GDC fournit plusieurs mécanismes pour l'équilibrage de charge et la gestion sophistiquée du trafic.

Équilibreur de charge externe pour le trafic nord-sud

Pour exposer vos applications à des utilisateurs ou des systèmes en dehors d'un cluster GKE sur GDC (trafic nord-sud), vous 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 parfaitement à Kubernetes.

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

  • Service géré : ELB est géré par GDC et conçu pour la haute disponibilité et la résilience.

  • 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 opérationnels s'exécutant dans toutes les zones disponibles de l'univers GDC. L'ELB s'appuie sur les vérifications d'aptitude des pods pour déterminer l'état du backend.

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

L'utilisation d'un équilibreur de charge externe est la méthode standard et recommandée pour obtenir une haute disponibilité pour l'entrée de trafic externe. Les requêtes des clients sont ainsi automatiquement redirigées vers des zones ou instances non défaillantes.

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). C'est essentiel pour dissocier les services internes et fournir des chemins de communication internes qui sont également disponibilité élevée et évolutifs.

Voici les principales caractéristiques du service ILB qui offre une haute disponibilité et une évolutivité :

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

  • Intégration de l'équilibreur de charge à Kubernetes : généralement provisionné 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 opérationnels, identifiés à l'aide de sondes de préparation, situés dans toutes les zones disponibles. Cette distribution permet d'éviter les échecs de communication interne si une zone rencontre des problèmes.

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

  • Scalabilité : facilite la mise à l'échelle des services de backend internes en répartissant le trafic sur toutes les répliques saines disponibles.

L'utilisation d'un équilibreur de charge interne pour la communication interne entre services permet au flux de trafic interne de résister aux défaillances de zone et offre 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 méthode est souvent utilisée pour les applications à plusieurs niveaux où les frontaux doivent communiquer avec les API ou les bases de données de backend au sein du cluster Kubernetes.

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

Déploiement d'applications à haute disponibilité entre 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 ou de vos utilisateurs finaux. Il est essentiel d'atteindre la haute disponibilité dans votre univers GDC pour les charges de travail critiques. Vous pouvez déployer des applications à haute disponibilité dans plusieurs zones de votre univers GDC, en implémentant la réplication asynchrone du stockage 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 de l'application et en répliquant les données dans les zones, vous pouvez améliorer considérablement la résilience face aux défaillances matérielles localisées ou aux événements de maintenance.

Étapes suivantes