Vue d’ensemble des sondes d’intégrité Application Gateway
Azure Application Gateway analyse l’intégrité de tous les serveurs de son pool principal et arrête automatiquement d’envoyer du trafic à tout serveur qu’il considère non sain. Les sondes continuent à analyser un tel serveur défectueux et la passerelle recommence à acheminer le trafic vers celui-ci dès que les sondes le détectent comme sain.
La sonde par défaut utilise le numéro de port du paramètre principal associé et d’autres configurations prédéfinies. Vous pouvez utiliser Sondes personnalisées pour les configurer de votre façon.
Comportement des sondes
Une adresse IP source
L’adresse IP source des sondes dépend du type de serveur principal :
- Si l’adresse du serveur dans le pool principal est un point de terminaison public, l’adresse source est l’adresse IP publique front-end de la passerelle applicative.
- Si le serveur du pool principal est un point de terminaison privé, l’adresse IP source proviendra de l’espace d’adressage du sous-réseau de votre passerelle applicative.
Opérations des sondes
Une passerelle commence à déclencher des sondes immédiatement après avoir configuré une règle, en l’associant à un paramètre principal et à un pool principal (et à l’écouteur, bien sûr). L’illustration montre que la passerelle sonde indépendamment tous les serveurs du pool principal. Les requêtes entrantes qui commencent à arriver sont envoyées uniquement aux serveurs sains. Un serveur principal est marqué comme non sain par défaut jusqu’à ce qu’une réponse de sonde positive soit reçue.
Les sondes requises sont déterminées en fonction de la combinaison unique du serveur principal et du paramétrage backend. Par exemple, considérez une passerelle avec un pool principal unique avec deux serveurs et deux paramétrages back-end, chacun ayant des numéros de port différents. Lorsque ces paramétrages backend distincts sont associés au même pool principal à l’aide de leurs règles respectives, la passerelle crée des sondes pour chaque serveur et la combinaison du paramétrage backend. Vous pouvez le visualiser sur la page Intégrité du serveur principal.
De plus, toutes les instances de la passerelle applicative sondent les serveurs principaux indépendamment les uns des autres.
Intervalles d'analyse
La même configuration de sonde s’applique à chaque instance de votre Application Gateway. Par exemple, si une passerelle applicative a deux instances et que l’intervalle de sonde est défini sur 20 secondes, les deux instances envoient la sonde d’intégrité toutes les 20 secondes.
Une fois que la sonde détecte une réponse négative, le compteur pour « Seuil non sain » se déclenche et marque le serveur comme non sain si le nombre d’échecs consécutif correspond au seuil configuré. En conséquence, si vous définissez ce seuil non sain sur 2, la sonde suivante détectera d’abord cette défaillance. La passerelle applicative marque ensuite le serveur comme non sain après 2 sondes négatives consécutives [Première détection 20 sec + (2 sondes négatives consécutives * 20 sec)].
Remarque
Le rapport d’intégrité du serveur principal est mis à jour en fonction de l’intervalle d’actualisation de la sonde correspondante et ne dépend pas de la requête de l’utilisateur.
Sonde d’intégrité par défaut
Une passerelle d’application configure automatiquement une sonde d’intégrité par défaut lorsque vous ne définissez pas de configuration de sonde personnalisée. Le comportement de monitoring par défaut consiste à lancer une requête HTTP GET aux adresses IP qui sont configurées dans le pool de back-ends. En ce qui concerne les sondes par défaut, si les paramètres HTTP du serveur principal sont configurés pour HTTPS, la sonde utilise HTTPS pour tester l’intégrité des serveurs principaux.
Par exemple : vous configurez votre passerelle applicative pour utiliser les serveurs back-end A, B et C, qui recevront le trafic réseau HTTP sur le port 80. Les tests de monitoring de l’intégrité par défaut testent les trois serveurs toutes les 30 secondes pour obtenir une réponse HTTP intègre, avec un délai d’expiration de 30 secondes pour chaque requête. Le code d’état d’une réponse HTTP correcte est compris entre 200 et 399. Dans ce cas, la requête HTTP GET pour la sonde d’intégrité se présente comme suit : http://127.0.0.1/. Consultez également Codes de réponse HTTP dans Application Gateway.
Si la vérification de la sonde par défaut échoue pour le serveur A, la passerelle d’application arrête de transférer des requêtes vers ce serveur. La sonde par défaut continue de contrôler le serveur A toutes les 30 secondes. Lorsque le serveur A répond correctement à une requête de sonde d’intégrité par défaut, la passerelle d’application recommence à transférer les requêtes vers le serveur.
Paramètres de sonde d’intégrité par défaut
| Propriétés de la sonde | Valeur | Description |
|---|---|---|
| URL de sonde | <protocole>://127.0.0.1:<port>/ | Le protocole et le port sont hérités des paramètres HTTP principaux auxquels la sonde est associée |
| Intervalle | 30 | Durée de l’attente, en secondes, avant l’envoi de la sonde d’intégrité suivante. |
| Délai d’attente | 30 | Durée de l’attente, en secondes, de la passerelle d’application pour une réponse de la sonde avant que la sonde ne soit déclarée comme défectueuse. Si une sonde renvoie un état intègre, le serveur principal correspondant est immédiatement marqué comme étant intègre. |
| Seuil de défaillance sur le plan de l’intégrité | 3 | Détermine le nombre de sondes à envoyer en cas d’échec de la sonde d’intégrité standard. Dans la référence SKU v1, ces sondes d’intégrité supplémentaires sont envoyées de façon rapprochée pour déterminer rapidement l’intégrité du serveur principal et ne tiennent pas compte de l’intervalle d’analyse. Dans le cas du SKU v2, les sondes d’intégrité attendent l’intervalle. Le serveur back-end est marqué comme étant défectueux lorsque le nombre d’échecs consécutifs a atteint le seuil de défaillance. |
La sonde d’intégrité par défaut examine uniquement <protocole>://127.0.0.1:<port> pour déterminer l’état d’intégrité. Si vous devez configurer la sonde d’intégrité de sorte qu’elle accède à une URL personnalisée ou modifier d’autres paramètres, vous devez utiliser des sondes personnalisées. Pour plus d’informations sur les sondes HTTPS, consultez Présentation de la terminaison TLS et du TLS de bout en bout sur la passerelle Application Gateway.
Sonde d’intégrité personnalisée
Les sondes personnalisées vous permettent d’avoir un contrôle plus précis de l’analyse de l’intégrité. En utilisant des sondes personnalisées, vous pouvez notamment configurer un nom d’hôte personnalisé, un chemin d’URL, un intervalle de sondage et le nombre de réponses en échec autorisé avant que l’instance de pool de back-ends ne soit marquée comme non saine.
Paramètres de sonde d’intégrité personnalisée
Le tableau suivant fournit des définitions pour les propriétés d’une sonde d’intégrité personnalisée.
| Propriétés de la sonde | Description |
|---|---|
| Nom | Nom de la sonde. Ce nom est utilisé pour identifier et désigner la sonde dans les paramètres HTTP du serveur back-end. |
| Protocol | Protocole utilisé pour envoyer la sonde. Ceci doit correspondre au protocole défini dans les paramètres HTTP backend auquel il est associé. |
| Host | Nom d’hôte pour l’envoi de la sonde. Dans la référence SKU v1, cette valeur est uniquement utilisée pour l’en-tête d’hôte de la requête de sonde. Dans la référence SKU v2, elle est utilisée en tant qu’en-tête d’hôte et SNI. |
| Path | Chemin relatif de la sonde. Un chemin d’accès valide commence par « / » |
| Port | S’il est défini, il est utilisé en tant que port de destination. Sinon, il utilise le même port que les paramètres HTTP auxquels il est associé. Cette propriété est uniquement disponible dans la référence SKU v2 |
| Intervalle | Intervalle d’analyse en secondes. Cette valeur correspond à l’intervalle de temps qui s’écoule entre deux analyses consécutives. |
| Délai d’attente | Délai d’expiration de l’analyse en secondes. Si aucune réponse valide n’est reçue dans le délai imparti, la sonde est marquée comme étant en échec. |
| Seuil de défaillance sur le plan de l’intégrité | Nombre de tentatives d’analyse Le serveur back-end est marqué comme étant non sain lorsque le nombre d’échecs consécutifs a atteint le seuil de défaillance. |
Correspondance des sondes
Par défaut, une réponse HTTP(S) avec un code d’état compris entre 200 et 399 est considérée comme intègre. Les sondes d’intégrité personnalisées prennent également en charge deux critères de correspondance. Des critères de correspondance peuvent être utilisés pour éventuellement modifier l’interprétation par défaut de ce qui rend une réponse intègre.
Les éléments suivants sont des critères de correspondance :
- Correspondance de code d’état de la réponse HTTP : le critère de correspondance de la sonde pour l’acceptation du code de réponse http spécifié par l’utilisateur ou des plages de codes de réponse. Les codes d’état de réponse séparées par des virgules individuelles ou une plage de codes d’état sont pris en charge.
- Correspondance du corps de la réponse HTTP : critère de correspondance de la sonde qui examine le corps de la réponse HTTP et correspond à une chaîne spécifiée par l’utilisateur. La correspondance ne tient compte que de la présence d’une chaîne spécifiée par l’utilisateur dans le corps de la réponse et n’est pas une correspondance d’expression régulière complète. La correspondance spécifiée doit être de 4090 caractères ou moins.
Les critères de correspondance peuvent être spécifiés à l’aide de la cmdlet New-AzApplicationGatewayProbeHealthResponseMatch.
Par exemple :
$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"
Les critères de correspondance peuvent être attachés à la configuration de la sonde à l’aide d’un opérateur -Match dans PowerShell.
Certains cas d’usage des sondes personnalisées
- Si un serveur principal autorise l’accès aux utilisateurs authentifiés uniquement, les sondes de passerelle applicative reçoivent un code de réponse 403 au lieu de 200. Les clients (utilisateurs) étant limités à s’authentifier pour le trafic en direct, vous pouvez configurer le trafic de la sonde pour accepter 403 comme réponse attendue.
- Lorsqu’un serveur principal dispose d’un certificat générique (*.contoso.com) installé pour servir différents sous-domaines, vous pouvez utiliser une sonde personnalisée avec un nom d’hôte spécifique (requis pour SNI) qui soit accepté pour établir une sonde TLS positive et signaler que ce serveur est sain. Avec « remplacer le nom d’hôte » dans le paramétrage principal défini sur NO, les différents noms d’hôte entrants (sous-domaines) sont transmis comme tels au backend.
Considérations pour un groupe de sécurité réseau
Un contrôle précis du sous-réseau Application Gateway via des règles NSG est possible en préversion publique. Pour plus d’informations, cliquez ici.
Avec les fonctionnalités actuelles, il existe certaines restrictions :
Vous devez autoriser le trafic Internet entrant sur les ports TCP 65503-65534 pour la référence (SKU) Application Gateway v1, et sur les ports TCP 65200-65535 pour la référence (SKU) v2 avec le sous-réseau de destination en tant que Any et la source en tant que balise de service GatewayManager. Cette plage de ports est nécessaire pour la communication avec l’infrastructure Azure.
En outre, la connectivité Internet sortante ne peut pas être bloquée, et le trafic entrant provenant de la balise AzureLoadBalancer doit être autorisé.
Pour plus d’informations, consultez Présentation de la configuration d’Application Gateway.
Étapes suivantes
Après vous être familiarisé avec l’analyse d’intégrité Application Gateway, vous pouvez configurer une sonde d’intégrité personnalisée dans le portail Azure ou une sonde d’intégrité personnalisée à l’aide de PowerShell et du modèle de déploiement Azure Resource Manager.