À propos de l'état composite pour le basculement interrégional automatique

L'état de fonctionnement composite permet aux producteurs de services de définir des critères qui déterminent les états de fonctionnement des services publiés au niveau régional. Ces états de santé permettent le basculement interrégional automatique pour les consommateurs de services qui utilisent des backends Private Service Connect. Les états de santé sont basés sur l'état de santé agrégé des backends du producteur de services (VM ou points de terminaison réseau). Ils fournissent aux consommateurs un signal de basculement plus précis que la détection des valeurs aberrantes, qui déduit l'état de santé à partir des échecs de réponse.

Pour activer le basculement interrégional, le producteur et le consommateur de services doivent utiliser un déploiement multirégional. Lorsque vous configurez l'état de santé composite, l'état de santé de chaque service régional publié est automatiquement propagé à l'équilibreur de charge du consommateur. Si un service publié dans une région n'est plus opérationnel, l'équilibreur de charge du consommateur cesse d'acheminer le trafic vers ce service et l'achemine plutôt vers une instance opérationnelle du service publié qui se trouve dans une autre région.

Exigences de déploiement

Cette section explique comment les producteurs et les consommateurs de services peuvent configurer leurs ressources pour un déploiement multirégional compatible avec le basculement automatique entre régions avec Composite Health.

Pour en savoir plus sur les exigences concernant les types d'équilibreurs de charge et de backends, consultez Spécifications.

Configuration du producteur :

Configuration du consommateur :

Le diagramme suivant illustre un déploiement multirégional :

Un déploiement multirégional se compose d'un équilibreur de charge client qui se connecte aux services publiés dans plusieurs régions à l'aide de Private Service Connect.

Cet exemple montre un équilibreur de charge d'application externe mondial consommateur qui se connecte à un service publié dans plusieurs régions. L'accès à un service multirégional avec un équilibreur de charge global ou multirégional compatible permet au consommateur de services de profiter de l'état de santé composite pour le basculement automatique entre régions (cliquez pour agrandir).

Composants de l'état composite

L'état de santé composite utilise les composants suivants pour prendre en charge le basculement automatique entre régions.

Plusieurs sources d'état, chacune avec une règle d'agrégation des données d'état, sont combinées dans une vérification de l'état composite, qui met à jour la destination d'état.

Le schéma ci-dessus montre les principaux composants de l'état composite. Les règles d'agrégation des données d'état définissent les conditions à remplir pour que les sources d'état soient considérées comme opérationnelles. Les états de santé des sources de données d'état individuelles sont combinés en un seul état par une vérification de l'état'état composite, et le résultat est transmis à une destination d'état.

Règle d'agrégation des données d'état

Une règle d'agrégation des états est une ressource que vous créez pour définir les conditions qu'un service de backend doit remplir pour être considéré comme opérationnel. Une règle agrège les états de santé des backends d'un service de backend (VM dans un groupe d'instances ou points de terminaison réseau dans un NEG), tels que déterminés par des vérifications de l'état régulières.

Un service de backend est considéré comme opérationnel si deux conditions configurables sont remplies :

  • Pourcentage de points de terminaison opérationnels : pourcentage minimal de backends qui doivent être opérationnels. La valeur par défaut est de 60%.

  • Nombre minimal de points de terminaison opérationnels : nombre minimal de backends qui doivent être opérationnels. La valeur par défaut est de 1.

Par exemple, vous pouvez créer une règle qui spécifie qu'un service de backend doit avoir au moins 75% de ses backends opérationnels et au moins trois backends opérationnels. Si le nombre de backends opérationnels tombe en dessous de l'un de ces seuils, le service de backend est considéré comme non opérationnel.

Source des données d'état

Une source d'état est une ressource qui rend l'état d'un seul service de backend disponible pour l'agrégation lors d'une vérification de l'état'état composite. Lorsque vous créez une source de données de santé, vous spécifiez les éléments suivants :

  • Un service de backend à surveiller
  • Règle d'agrégation des états qui détermine l'état du service de backend

La source de données d'état utilise les conditions définies dans la règle d'agrégation des données d'état pour déterminer l'état de fonctionnement du service de backend associé.

Vérification de l'état composite

Une vérification de l'état composite est une ressource qui agrège les états d'une ou de plusieurs sources d'état pour produire un seul état composite pour un service publié au niveau régional. Le service publié est considéré comme opérationnel si chacune des sources d'état associées est opérationnelle. Si l'une des sources d'état n'est pas opérationnelle, le service est considéré comme non opérationnel.

Destination des données d'état

Une destination d'état reçoit l'état de fonctionnement composite final d'une vérification de l'état'état composite. Pour un service publié, la destination de l'état de santé est la règle de transfert de l'équilibreur de charge du producteur. L'état de fonctionnement est automatiquement propagé aux équilibreurs de charge du consommateur qui se connectent à cette règle de transfert.

Spécifications

La vérification d'état composite présente les spécifications suivantes.

  • Comportement :

    • L'état des backends individuels d'un service de backend est déterminé par des vérifications d'état standards.
    • Une règle d'agrégation des états configurable détermine l'état de fonctionnement global d'un service de backend en fonction de l'état de fonctionnement de ses backends individuels.
    • Une vérification de l'état composite agrège les états d'un ou de plusieurs services de backend configurés comme sources d'état, créant ainsi un état composite.
    • L'état de santé composite est fourni à une destination d'état, qui doit être la règle de transfert d'un service publié.
    • L'état de santé composite est automatiquement propagé aux équilibreurs de charge client connectés, où les états non sains déclenchent un basculement interrégional automatique.
    • Par défaut, les transitions d'état sont enregistrées par Cloud Logging. Les producteurs peuvent afficher les journaux des sources de données de santé et des vérifications d'état composites. Les consommateurs peuvent afficher les journaux des NEG Private Service Connect qui se connectent aux services publiés utilisant l'état de santé composite. Pour en savoir plus, consultez Surveiller l'état composite.

  • Configuration :

États

L'état de fonctionnement composite utilise les états suivants pour représenter l'état de fonctionnement des services publiés et des services de backend.

État de fonctionnement Ressource surveillée Description
HEALTHY Source des données d'état Le service de backend associé est opérationnel, comme défini par sa règle d'agrégation des données d'état.
Vérification de l'état composite Le service publié est opérationnel, car chacune de ses sources d'état associées est opérationnelle.
NEG Private Service Connect Le service publié associé est opérationnel, tel que défini par la vérification d'état composite du producteur.
UNHEALTHY Source des données d'état Le service de backend ne répond pas aux critères définis par sa règle d'agrégation des états.
Vérification de l'état composite Le service publié n'est pas en bon état, car une ou plusieurs sources d'état associées ne le sont pas.
NEG Private Service Connect Le service publié associé n'est pas opérationnel, tel que défini par la vérification d'état composite du producteur. Cet état peut déclencher un basculement interrégional.
UNKNOWN Source des données d'état L'état de fonctionnement n'est pas encore disponible. Il s'agit d'un état transitoire qui se produit lorsque des ressources sont nouvellement créées ou configurées.
Vérification de l'état composite Aucune source d'état associée n'est en mauvais état, mais une ou plusieurs sources d'état sont inconnues.
NEG Private Service Connect L'état de santé du service publié associé n'est pas encore disponible.

Limites

La santé composite présente les limites suivantes :

  • L'état de santé composite n'est compatible qu'avec les ressources créées après le 20 octobre 2025, y compris les règles de transfert de producteur, les rattachements de service et les NEG Private Service Connect. Si vous configurez l'état de santé composite pour les ressources créées avant cette date, il est possible que l'état de santé composite ne soit pas correctement reconnu. Si vous avez besoin de l'état de santé composite pour les ressources créées avant le 20 octobre 2025, vous devez recréer les ressources.
  • Toutes les ressources d'état de santé composite, y compris les services de backend et les règles de transfert auxquels elles font référence, doivent exister dans le même projet.
  • Vous ne pouvez pas utiliser l'état de santé composite d'un service comme source de données d'état pour un autre service.
  • Il n'existe aucun mode permettant de tester une configuration de vérification de l'état de l'état qui n'affecte pas les consommateurs connectés. Toute vérification d'état composite configurée peut déclencher immédiatement un basculement.
  • Composite Health n'est compatible qu'avec les backends Private Service Connect qui accèdent aux services publiés.

Tarifs

Pour en savoir plus sur les tarifs, consultez la page Tarifs du VPC.

Étapes suivantes