Erreur "Service indisponible" du service 503 d'appairage de VPC avec TARGET_CONNECT_TIMEOUT

Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Il n'existe pas de documentation Apigee Edge équivalente pour ce sujet.

Symptôme

Ce problème apparaît sous la forme d'erreurs "503 - Service indisponible" dans la Surveillance des API et dans Débogage ou dans d'autres outils. Le motif "TARGET_CONNECT_TIMEOUT" indique un délai d'expiration de connexion entre l'instance Apigee et la cible lors de l'utilisation de l'appairage VPC.

L'erreur ne doit pas être confondue avec d'autres erreurs d'expiration de délai, telles que "504 - Expiration du délai de passerelle".

Message d'erreur

Il s'agit de l'erreur type dans la session de débogage ou de la charge utile de réponse. Veuillez noter la raison : TARGET_CONNECT_TIMEOUT.

{"fault":{"faultstring":"The Service is temporarily unavailable",
"detail":{"errorcode":"messaging.adaptors.http.flow.ServiceUnavailable",
"reason":"TARGET_CONNECT_TIMEOUT"}}}

Causes possibles :

Notez que ces causes sont spécifiques à Apigee configuré avec l'appairage de VPC. Consultez la page Options de mise en réseau Apigee. Si la cible est PSC (rattachement du point de terminaison), consultez plutôt le guide PSC.

Cause	Description
Erreur de configuration des routes	Les routes cibles ne sont pas exportées dans l'appairage avec l'instance Apigee.
Problème de connectivité à la cible	La cible n'est pas toujours en mesure d'accepter une connexion TCP.
Liste d'autorisation d'adresses IP au niveau de la cible avec une partie ou la totalité des adresses IP NAT Apigee non ajoutées	Toutes les adresses IP NAT Apigee ne sont pas incluses dans la liste d'autorisation au niveau de la cible.
Épuisement des ports IP NAT	Le nombre de ports NAT hébergés est insuffisant pour le trafic.
La valeur connect.timeout.millis est trop faible	Le paramètre de délai avant expiration de la connexion est trop faible côté Apigee.

Étapes de diagnostic courantes

Debug est un outil essentiel pour capturer et évaluer les informations suivantes sur le problème :

Durée totale de la requête. Généralement, il faut trois secondes (valeur par défaut de connect.timeout.millis) avant que le délai d'expiration de connexion ne se produise. Si vous remarquez une durée inférieure, vérifiez la configuration du point de terminaison cible.
Nom d'hôte cible et adresse IP. La mauvaise adresse IP affichée peut indiquer un problème lié au DNS. Vous remarquerez peut-être également une corrélation entre différentes adresses IP cibles et le problème en question.
Fréquence. Différentes approches sont nécessaires selon que le problème est intermittent ou persistant.

Cause : erreur de configuration de route

Diagnostic

Si le problème est persistant, même s'il a démarré récemment, il peut être dû à une mauvaise configuration de route.

Cela peut affecter les cibles internes (routées au sein d'un VPC appairé) et externes (Internet).

Commencez par identifier l'adresse IP de la cible résolue à partir de l'instance Apigee. L'une des méthodes consiste à utiliser une session Debug. Dans Debug, accédez à AnalyticsPublisher (ou AX dans le débogage classique) :

Recherchez la valeur target.ip à droite de l'écran.

Dans cet exemple, l'adresse IP est 10.2.0.1. Étant donné que cette plage est privée, certaines mesures de routage doivent être mises en place pour qu'Apigee puisse atteindre la cible.

Veuillez noter que si la cible se trouve sur Internet, vous devez suivre cette étape si VPC Service Controls est activé pour Apigee, car cet outil empêche la connectivité Internet.
Notez la région dans laquelle l'instance Apigee concernée est déployée. Sur la page https://console.cloud.google.com/apigee, cliquez sur Instances. Dans le champ Emplacement, vous pouvez trouver la région exacte de l'instance.
Dans le projet appairé à Apigee, accédez à la section Réseau VPC -> Appairage de réseaux VPC dans l'interface utilisateur. Veuillez noter que si vous utilisez un VPC partagé, ces étapes doivent être effectuées dans le projet hôte plutôt que dans le projet Apigee.
Cliquez sur servicenetworking-googleapis-com, sélectionnez l'onglet ROUTES EXPORTÉES, puis filtrez les résultats en fonction de la région obtenue à l'étape 2.

Cet exemple montre la route 10.2.0.0/24 telle qu'elle a été exportée et inclut l'exemple d'adresse IP de cible 10.2.0.1. Si vous ne voyez aucune route correspondant à votre cible, il s'agit de la cause du problème.
Remarque : Si la cible est externe, les routes ne sont généralement pas présentes dans les Routes exportées et les requêtes Apigee sont directement acheminées vers Internet. Comme ce n'est pas toujours le cas, veillez à clarifier la topologie de réseau souhaitée. Par exemple, si VPC Service Controls est activé, vous devez également exporter les routes par défaut ou autres afin d'atteindre des cibles externes.

Solution

Examinez votre architecture réseau et assurez-vous que les routes sont exportées dans l'appairage de VPC avec Apigee. La route manquante est très probablement statique ou dynamique. L'absence de routes dynamiques nécessaires indique un problème avec la fonctionnalité correspondante, par exemple Cloud Interconnect.

Notez que l'appairage transitif n'est pas pris en charge. En d'autres termes, si le réseau VPC N1 est appairé à N2 et N3, mais si N2 et N3 ne sont pas directement connectés, le réseau VPC N2 ne peut pas communiquer avec le réseau VPC N3 via l'appairage de réseaux VPC.

Pour plus d'informations, consultez la page Modèles de mise en réseau Southbound.

Cause : problème de connectivité au niveau de la cible

Diagnostic

Il est possible que la cible ne soit pas accessible à partir du VPC ou qu'elle ne puisse pas accepter une connexion. Deux options s'offrent à vous pour diagnostiquer le problème.

Test de connectivité (adresses IP cibles privées)

Si la cible se trouve dans un réseau privé, vous pouvez utiliser la fonctionnalité Tests de connectivité pour diagnostiquer les causes courantes.

Identifiez l'adresse IP de la cible résolue à partir de l'instance Apigee. L'une des méthodes consiste à utiliser une session Debug.

Dans Debuug, accédez à AnalyticsPublisher (ou AX dans la version classique de Debug). Recherchez la valeur target.ip à droite de l'écran.

Dans cet exemple, l'adresse IP est 10.2.0.1. Il s'agit d'une adresse IP privée, ce qui signifie que nous pouvons utiliser les tests de connectivité.
Notez l'adresse IP de l'instance Apigee qui ne parvient pas à se connecter à la cible. Dans la page Instances, dans la console Apigee, recherchez l'adresse IP de l'instance Apigee dans le champ Adresse IP.
Accédez à Tests de connectivité, puis cliquez sur Créer un test de connectivité. Fournissez les informations suivantes :
1. Adresse IP source : utilisez l'adresse IP de l'instance Apigee obtenue à l'étape 2 ci-dessus. Veuillez noter qu'il ne s'agit pas de l'adresse IP source exacte utilisée par Apigee pour envoyer une requête à la cible. Elle est cependant suffisante pour le test, car elle se trouve dans le même sous-réseau.
2. Il s'agit d'une adresse IP utilisée dans Google Cloud : ne cochez pas la case, sauf si l'adresse se trouve dans l'un de vos projets Google Cloud. Si vous cochez cette valeur, indiquez également le projet et le réseau.
3. Indiquez l'adresse cible (étape 1) et le port dans les champs Adresse IP de destination et Port de destination.
Cliquez sur Créer et attendez la fin de la première exécution du test.
Dans la liste des tests de connectivité, cliquez sur Afficher pour afficher les résultats de l'exécution.
Si le résultat est "Inaccessible", cela signifie que votre configuration présente un problème. L'outil devrait vous rediriger vers la documentation sur les états des tests de connectivité pour continuer. Si l'état est "Joignable", de nombreux problèmes de configuration sont effectivement exclus. Toutefois, cela ne garantit pas que la cible est accessible. Il n'y a pas eu de tentative réelle d'établissement d'une connexion TCP avec la cible. Seul le diagnostic suivant ci-dessous vous permettra de le vérifier.

Test de connectivité de VM (toutes les cibles)

Dans le même VPC appairé avec Apigee, créez une instance de VM sous Linux.
Effectuez des tests de connectivité à partir de la VM, de préférence au moment où le problème est reproductible à partir d'Apigee. Vous pouvez utiliser telnet, curl et d'autres utilitaires pour établir une connexion. Cet exemple curl s'exécute dans une boucle avec un délai d'expiration de trois secondes. Si curl ne parvient pas à établir une connexion TCP en trois secondes, l'exemple échoue.
```
for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done
```
Vérifiez le résultat complet et recherchez l'erreur ci-dessous :
```
* Closing connection 0
 curl: (28) Connection timed out after 3005 milliseconds
```
La présence de cette erreur confirme que le problème est reproductible en dehors d'Apigee.

Veuillez noter que si vous rencontrez d'autres erreurs, telles que des erreurs liées au protocole TLS, des codes d'état incorrects, etc… ils ne confirment pas l'expiration de la connexion et ne sont pas liés à ce problème.
Si la cible nécessite de créer une liste d'autorisation d'adresses IP, vous ne pourrez peut-être pas la tester à partir d'une VM, sauf si vous ajoutez également l'adresse IP source de l'instance de VM à la liste d'autorisation.

Solution

Si vous avez identifié un problème grâce aux tests de connectivité, suivez les étapes de résolution documentées.

Si le délai avant expiration est reproduit à partir d'une VM, il n'existe aucune instruction précise sur la manière de résoudre le problème côté cible. Une fois que le délai avant expiration de la connexion est reproductible en dehors d'Apigee, poursuivez le diagnostic du problème en vous écartant du réseau VPC. Essayez de tester la connectivité aussi près que possible de la cible.

Si la cible se trouve derrière une connexion VPN, vous pouvez également la tester à partir du réseau local.

Si la cible se trouve sur Internet, vous pouvez essayer de reproduire le problème en dehors de la console Google Cloud.

Si le problème se produit pendant les heures de pointe, la cible peut être surchargée de connexions.

Si vous devez envoyer une demande d'assistance Google Cloud à ce stade, vous n'avez plus besoin de sélectionner le composant Apigee, car le problème est désormais reproductible directement à partir du VPC.

Cause : Liste d'autorisation d'adresses IP au niveau de la cible avec tout ou partie des adresses IP NAT Apigee non ajoutées.

Diagnostic

Cela concerne les cibles externes (Internet) pour lesquelles la liste d'autorisation d'adresses IP est activée. Assurez-vous que toutes les adresses IP NAT Apigee sont ajoutées du côté cible concerné. En l'absence de liste d'autorisation sur la cible, vous pouvez ignorer cette section.

Le problème est plus facile à identifier si les erreurs sont intermittentes, car vous pouvez alors trouver une corrélation entre des adresses IP NAT spécifiques et les erreurs.

Si le problème est persistant (tous les appels échouent), assurez-vous que les adresses IP NAT sont activées sur Apigee et récupérez-les en procédant comme suit :

Répertoriez les adresses IP NAT pour une instance :

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"

Exemple de réponse :

{
  "natAddresses": [
    {
      "name": "nat-1",
      "ipAddress": "35.203.160.18",
      "state": "ACTIVE"
    },
    {
      "name": "nat-2",
      "ipAddress": "35.230.14.174",
      "state": "RESERVED"
    }
  ]
}

Si vous ne recevez aucune adresse dans la sortie, les adresses IP NAT ne sont pas ajoutées côté Apigee. Si vous obtenez des adresses, mais qu'aucune d'entre elles n'est ACTIVE, aucune des adresses utilisées ne permet d'accéder à Internet, ce qui pose également un problème.

Si vous disposez d'au moins une adresse ACTIVE, elle peut être ajoutée à la liste d'autorisation sur la cible, auquel cas il n'y a pas d'erreur de configuration côté Apigee. Dans ce cas, l'adresse peut ne pas figurer dans la liste d'autorisation à la cible.

Si le problème est intermittent, cela peut indiquer que seul un sous-ensemble d'adresses IP NAT a été ajouté à la liste d'autorisation sur la cible. Pour l'identifier, procédez comme suit :

Créez un proxy inverse dans lequel la cible concernée est spécifiée dans le TargetEndpoint. Vous pouvez également réutiliser le proxy existant et passer à l'étape suivante :
Ajout d'une règle ServiceCallout au PreFlow de requête. La règle ServiceCallout doit appeler "https://icanhazip.com", "https://mocktarget.apigee.net/ip" ou tout autre point de terminaison public qui renvoie l'adresse IP de l'appelant dans la réponse. Stockez la réponse dans la variable "response" afin que le contenu soit visible dans Debug. Voici un exemple de configuration de règle ServiceCallout :
```
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout continueOnError="false" enabled="true" name="Service-Callout-1">
    <DisplayName>Service Callout-1</DisplayName>
    <Properties/>
    <Request clearPayload="true" variable="myRequest">
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    </Request>
    <Response>response</Response>
    <HTTPTargetConnection>
        <Properties/>
        <URL>https://icanhazip.com</URL>
    </HTTPTargetConnection>
</ServiceCallout>
```
Vous pouvez également stocker la réponse dans une variable personnalisée, mais vous devez lire le ".content" de cette variable avec la règle AssignMessage pour l'afficher dans l'outil Debug.

Assurez-vous que la cible est configurée exactement de la même manière que dans le proxy concerné.

Remarque : Les requêtes ServiceCallout et Target doivent toutes deux se produire au cours d'une même transaction. Cela permet de garantir que le même serveur traite une requête, de sorte que l'adresse IP NAT de la requête concernée corresponde à l'adresse IP NAT obtenue à partir de l'appel de service.
Exécutez une session Debug et cliquez sur l'étape ServiceCallout :
Dans le coin inférieur droit, vous devriez voir une section Contenu de la réponse contenant l'adresse IP NAT (dans le corps de réponse) de l'instance Apigee à l'origine de la requête. Si vous stockez la réponse de ServiceCallout dans un autre emplacement, vous devriez également la voir à cet emplacement.

Notez que plus tard dans le flux, le proxy appellera la cible et que le contenu de la réponse sera remplacé par l'erreur ou par une réponse de la cible.
Essayez de mettre en corrélation les adresses IP NAT avec le problème. Si vous constatez que seules des adresses IP spécifiques échouent à cette vérification, cela signifie que certaines adresses IP, mais pas toutes, sont ajoutées à la liste d'autorisation sur la cible.
Si vous ne constatez aucune corrélation entre les adresses IP NAT et les erreurs, par exemple si la même adresse IP échoue dans une requête mais pas dans une autre, il ne s'agit probablement pas d'un problème de liste d'autorisation. Il peut s'agir d'un épuisement de NAT. Consultez la section Cause : épuisement des ports IP NAT.

Solution

Assurez-vous que des adresses IP NAT sont provisionnées et activées, et assurez-vous qu'elles sont bien toutes ajoutées du côté cible.

Cause : épuisement des ports IP NAT

Diagnostic

Si le problème ne peut être reproduit qu'à partir d'Apigee et que des adresses IP NAT sont provisionnées pour votre organisation, et que vous constatez que le problème se manifeste simultanément pour plusieurs cibles différentes, vous avez peut-être épuisé vos ports NAT source :

Notez la période concernée par le problème. Par exemple : tous les jours entre 17h58 et 18h08.
Vérifiez si une autre cible est concernée par le problème au même moment. Cette autre cible doit être accessible via Internet et ne doit pas être hébergée au même emplacement que la cible concernée initiale.
Déterminez si les erreurs ne se produisent qu'au-dessus d'un certain volume de trafic dans TPS. Pour ce faire, notez la période du problème et accédez au tableau de bord Performances des proxys.
Essayez de corréler la fenêtre temporelle d'erreur avec l'augmentation du nombre moyen de transactions par seconde (TPS).

Dans cet exemple, les TPS atteignent 1000 à 17h58. En partant du principe que dans cet exemple, 17h58 correspond exactement au moment où le problème se produit et qu'il affecte au moins deux cibles non liées, cela indique un problème d'épuisement NAT.

Solution

Recalculez vos besoins en adresses IP NAT en suivant les instructions de la section Calculer les besoins en adresses IP NAT statiques.

Vous pouvez également ajouter des adresses IP NAT et voir si cela résout le problème. Notez que l'ajout d'autres adresses IP peut nécessiter de d'abord les ajouter à la liste d'autorisation pour toutes les cibles.

Cause : La valeur connect.timeout.millis est trop faible

Diagnostic

Il se peut que la valeur du délai d'expiration soit mal configurée dans le proxy.

Pour vérifier, accédez au proxy concerné et inspectez le TargetEndpoint en question. Notez la propriété "connect.timeout.millis" et sa valeur. Dans cet exemple, la valeur est de 50, soit 50 millisecondes, et elle est généralement trop faible pour garantir l'établissement d'une connexion TCP. Si une valeur inférieure à 1000 s'affiche, il s'agit probablement de la cause du problème. Si vous ne voyez pas la propriété "connect.timeout.millis", la valeur par défaut est définie et la cause n'est pas confirmée.

Proxy avec délai d'expiration

Solution

Corrigez la valeur connect.timeout.millis, en gardant bien à l'esprit que les unités de temps sont exprimées en millisecondes. La valeur par défaut est 3000, soit 3000 millisecondes. Pour en savoir plus, consultez la documentation de référence sur les propriétés des points de terminaison.

Contacter le service d'assistance pour obtenir de l'aide

Si le problème persiste après avoir suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes pour l'assistance Google Cloud :

ID du projet et nom de l'organisation Apigee
Noms du ou des proxys et de l'environnement
Période concernée par le problème
Fréquence du problème
Nom d'hôte de la cible
Session Debug incluant le problème
Résultat des vérifications effectuées pour les causes possibles ci-dessus. Par exemple, le résultat de la commande curl à partir d'une VM