Sondes d’intégrité Azure Load Balancer
Une sonde d’intégrité Azure Load Balancer est une fonctionnalité qui détecte l’état d’intégrité de vos instances d’application. Il envoie une demande aux instances pour vérifier s’ils sont disponibles et répondre aux demandes. La sonde d’intégrité peut être configurée pour utiliser différents protocoles tels que TCP, HTTP ou HTTPS. Il s’agit d’une fonctionnalité importante, car elle vous aide à détecter les défaillances des applications, à gérer la charge et à planifier les temps d’arrêt.
Les règles dans Azure Load Balancer nécessitent une sonde d’intégrité pour la détection de l’état du point de terminaison. La configuration de la sonde d’intégrité et les réponses de la sonde déterminent quelles instances de pool principal reçoivent de nouvelles connexions. Utilisez les sondes d’intégrité pour détecter la défaillance d’une application. Générez une réponse personnalisée pour une sonde d’intégrité. Utilisez la sonde d’intégrité pour contrôler le flux afin de gérer la charge ou les temps d’arrêt planifiés. Lors de l’échec d’une sonde d’intégrité, l’équilibreur de charge cesse d’envoyer de nouvelles connexions à l’instance non saine concernée. La connectivité sortante n’est pas affectée, seule la connectivité entrante l’est.
Protocoles Probe
Les sondes d’intégrité prennent en charge plusieurs protocoles. La disponibilité d’un type spécifique de sonde d’intégrité varie en fonction de la référence SKU de Load Balancer. De plus, le comportement du service varie en fonction de la référence SKU de Load Balancer tel qu’indiqué dans le tableau suivant :
| Référence (SKU) | Protocole de sondage | Comportement en cas de panne de sonde |
|---|---|---|
| Standard | TCP, HTTP, HTTPS | Toutes les sondes sont en panne, tous les flux TCP continuent. |
| De base | TCP, HTTP | Toutes les sondes sont en panne, tous les flux TCP arrivent à expiration. |
Propriétés de la sonde d’intégrité
Les sondes d’intégrité ont les propriétés suivantes :
| Nom de la propriété de la sonde d’intégrité | Détails |
|---|---|
| Nom | Nom de la sonde d’intégrité. Il s’agit d’un nom que vous pouvez définir pour votre sonde d’intégrité |
| Protocol | Protocole de sonde d’intégrité. Il s’agit du type de protocole dont vous souhaitez que la sonde d’intégrité utilise. Les options sont les suivantes : protocoles TCP, HTTP, HTTPS |
| Port | Port de la sonde d’intégrité. Port de destination que vous souhaitez que la sonde d’intégrité utilise lorsqu’elle se connecte à la machine virtuelle pour vérifier son état d’intégrité |
| Intervalle (secondes) | Intervalle de sonde d’intégrité. Le temps (en secondes) entre les deux tentatives consécutives de contrôle d’intégrité de la machine virtuelle |
| Utilisée par | Liste des règles d’équilibreur de charge utilisant cette sonde d’intégrité spécifique. Vous devez avoir au moins une règle utilisant la sonde d’intégrité pour qu’elle soit efficace |
Configuration de sonde
La configuration de la sonde d’intégrité se compose des éléments suivants :
| Configuration de la sonde d’intégrité | Détails |
|---|---|
| Protocole | Protocole de sonde d’intégrité. Il s’agit du type de protocole dont vous souhaitez que la sonde d’intégrité utilise. Les options disponibles sont les suivantes : TCP, HTTP, HTTPS |
| Port | Port de la sonde d’intégrité. Port de destination que vous souhaitez que la sonde d’intégrité utilise lorsqu’elle se connecte à la machine virtuelle pour case activée l’état d’intégrité de la machine virtuelle. Vous devez vous assurer que la machine virtuelle écoute également sur ce port (autrement dit, le port est ouvert). |
| Intervalle | Intervalle de sonde d’intégrité. Temps (en secondes) entre les tentatives consécutives de contrôle de santé de la machine virtuelle |
Protocole de sondage
Le protocole utilisé par la sonde d’intégrité peut être configuré sur l’une des options suivantes : TCP, HTTP, HTTPS.
| Scénario | Sonde TCP | Sonde HTTP/HTTPS |
|---|---|---|
| Vue d’ensemble | Les sondes TCP établissent une connexion en effectuant une connexion TCP ouverte en trois temps au port défini. Les sondes TCP mettent fin à une connexion avec une négociation TCP de fermeture dans quatre directions. | Les protocoles HTTP et HTTPS émettent un message HTTP GET avec le chemin d’accès spécifié. Les deux sondes prennent en charge les chemins d’accès relatifs pour le HTTP GET. Les sondes HTTPS sont identiques aux sondes HTTP avec un wrapper Transport Layer Security (TLS) supplémentaire. Les sondes HTTP / HTTPS peuvent être pratiques pour implémenter votre propre logique afin de supprimer des instances de l’équilibreur de charge si le port de la sonde est également l’écouteur pour le service. |
| Comportement en cas d'échec de la sonde d’intégrité | Une sonde TCP échoue quand : 1. L’écouteur TCP sur l’instance ne répond pas durant toute la durée de l’opération. La sonde est marquée comme hors service en fonction du nombre de demandes ayant expiré et qui ont été configurées pour rester sans réponse avant que la sonde ne soit marquée hors service. 2. La sonde reçoit une réinitialisation TCP depuis l’instance. |
Une sonde HTTP/HTTPS échoue quand : 1. Le point de terminaison de la sonde renvoie un code de réponse HTTP autre que 200 (par exemple, 403, 404 ou 500). 2. Le point de terminaison de la sonde ne répond pas du tout pendant le minimum de l’intervalle de sondage et de la période d’expiration de 30 secondes. Plusieurs demandes de sondage peuvent rester sans réponse avant que la sonde soit marquée comme inactive et jusqu’à ce que la somme de tous les intervalles de délai d’attente ait été atteinte. 3. Le point de terminaison de la sonde ferme la connexion via une réinitialisation TCP. |
| Comportement de sonde opérationnelle | Les sondes d’intégrité TCP sont considérées comme saines et annotent le point de terminaison back-end comme sain quand : 1. La sonde d’intégrité fonctionne correctement après le démarrage de la machine virtuelle. 2. Tout point de terminaison back-end dans un état sain est éligible pour la réception de nouveaux flux. |
La sonde d’intégrité est marquée comme étant en fonctionnement lorsque l’instance répond avec un statut HTTP de 200 dans la période d’expiration. Les sondes d’intégrité HTTP/HTTPS sont considérées comme saines et annotent le point de terminaison back-end quand : 1. La sonde d’intégrité fonctionne correctement après le démarrage de la machine virtuelle. 2. Tout point de terminaison back-end dans un état sain est éligible pour la réception de nouveaux flux. |
Remarque
La sonde HTTPS nécessite l’utilisation de certificats basés sur un hachage de signature minimal de SHA256 dans la chaîne entière.
Comportement en cas de panne de sonde
| Scénario | Connexions TCP | Datagrammes UDP |
|---|---|---|
| Les sonde d’une seule instance sont hors service | Les nouvelles connexions TCP avec les points de terminaison back-end sains restants réussissent. Les connexions TCP établies à ce point de terminaison back-end continuent. | Les flux UDP existants passent dans une autre instance saine dans le pool back-end. |
| Les sondes de toutes les instances sont hors service | Aucun nouveau flux n’est envoyé au pool back-end. Standard Load Balancer autorise les flux TCP établis à se poursuivre, car un pool back-end dispose de plusieurs points de terminaison back-end. L’équilibreur de charge de base arrête tous les flux TCP existants vers le pool principal. | Tous les flux UDP existants s’arrêtent. |
Délai d’expiration et intervalle de sonde
La valeur d’intervalle détermine la fréquence à laquelle la sonde d’intégrité doit s’assurer d’une réponse de vos instances de pool principal. En cas d’échec de la sonde d’intégrité, les instances de pool principal sont immédiatement signalées comme non saines. Si la sonde d’intégrité réussit sur la sonde saine suivante, Azure Load Balancer marque vos instances de pool back-end comme étant saines. La sonde d’intégrité tente de vérifier le port de sonde d’intégrité configuré toutes les 5 secondes par défaut sur le Portail Azure, mais cette durée peut être explicitement définie sur une autre valeur.
Pour garantir une réponse en temps opportun, les sondes d’intégrité HTTP/S ont des délais d’expiration intégrés. Voici les durées de délai d’expiration pour les sondes TCP et HTTP/S :
- Durée du délai d’expiration de la sonde TCP : N/A (les sondes échouent une fois que la durée d’intervalle configurée de la sonde est dépassée et que la sonde suivante est envoyée)
- Durée du délai d’expiration de la sonde HTTP/S : 30 secondes
Pour des sondes HTTP/S, si l’intervalle configuré est plus long que le délai d’expiration ci-dessus, la sonde d’intégrité expire et échoue si aucune réponse n’est reçue pendant la période d’expiration. Par exemple, si une sonde d’intégrité HTTP est configurée avec un intervalle de sonde de 120 secondes (toutes les 2 minutes) et qu’aucune réponse de sonde n’est reçue pendant les 30 premières secondes, la sonde atteint sa période d’expiration et échoue. Lorsque l’intervalle configuré est plus court que la période d’expiration ci-dessus, la sonde d’intégrité échoue si aucune réponse n’est reçue avant la fin de l’intervalle de durée configuré et la sonde suivante est envoyée immédiatement.
Guide de conception
Quand vous concevez le modèle d’intégrité pour votre application, sondez un port sur un point de terminaison back-end qui reflète l’intégrité de l’instance et du service d’application. Le port de l’application et le port de la sonde ne doivent pas nécessairement être identiques. Dans certains scénarios, il peut être souhaitable que le port de sonde soit différent du port utilisé par votre application, mais il est généralement recommandé que le port soit identique.
Il peut être utile pour votre application de générer une réponse à une sonde d’intégrité et de signaler à l’équilibreur de charge si votre instance doit recevoir de nouvelles connexions. Vous pouvez manipuler la réponse de la sonde pour limiter la remise de nouvelles connexions à une instance en faisant échouer la sonde d’intégrité. Vous pouvez préparer la maintenance de votre application et initier le drainage des connexions sur votre application. Lors de l’utilisation du Standard Load Balancer, un signal de sonde hors service permet toujours la continuation des flux TCP jusqu’au délai d’expiration pour inactivité ou jusqu’à la fermeture de la connexion.
Pour une application d’équilibrage de charge UDP, générez un signal de sonde d’intégrité personnalisé à partir du point de terminaison principal. Utilisez TCP, HTTP ou HTTPS pour la sonde d’intégrité qui correspond à l’écouteur correspondant.
Règles d’équilibrage de charge des ports HA avec Standard Load Balancer. Tous les ports sont équilibrés en charge et une seule réponse de sonde d’intégrité doit communiquer l’état de la totalité de l’instance.
Ne traduisez pas ou ne proxysez pas une sonde d’intégrité via l’instance qui reçoit la sonde d’intégrité sur une autre instance de votre réseau virtuel. Cette configuration peut entraîner des défaillances dans votre scénario. Par exemple : un ensemble d’appliances tierces est déployé dans le pool principal d’un équilibreur de charge pour fournir une mise à l’échelle et une redondance pour les appareils. La sonde d’intégrité est configurée pour sonder un port que l’appliance tierse proxyse ou convertit en d’autres machines virtuelles derrière l’appliance. Si vous sondez le même port que celui utilisé pour traduire ou mettre en proxy les demandes vers les autres machines virtuelles derrière l’appliance, toute réponse de la sonde provenant d’une même machine virtuelle marque l’appliance comme étant hors service. Cette configuration peut entraîner une défaillance en cascade de l’application. Le déclencheur peut être un échec de sondage intermittent qui amène l’équilibreur de charge à désactiver l’appliance. Cette action peut désactiver votre application. Sondez l’intégrité de l’appliance elle-même. La sélection de la sonde pour déterminer le signal d’intégrité est une considération importante pour les scénarios d’appliances virtuelles réseau. Pour les scénarios de ce type, contactez le fournisseur de votre application pour obtenir le signal d’intégrité approprié.
Si vous avez plusieurs interfaces configurées sur votre machine virtuelle, vous devez vous assurer que vous répondez à la sonde sur l’interface à partir de laquelle l’avez reçue. Il peut être nécessaire de traduire l’adresse réseau source de cette adresse dans la machine virtuelle pour chaque interface.
Une définition de sonde n’est ni obligatoire ni vérifiée en cas d’utilisation d’Azure PowerShell, d’Azure CLI, de modèles ou d’une API. Les tests de validation de la sonde ne sont effectués que si vous utilisez le portail Azure.
Si la sonde d’intégrité fluctue, l’équilibreur de charge attend plus longtemps avant de replacer le point de terminaison back-end dans un état sain. Ce délai d’attente supplémentaire protège l’utilisateur et l’infrastructure. Il s’agit d’une stratégie intentionnelle.
Vérifiez que vos instances de machine virtuelle sont en cours d’exécution. Pour chaque instance en cours d’exécution dans le pool principal, la sonde d’intégrité vérifie la disponibilité. Si une instance est arrêtée, elle ne sera pas sondée tant qu’elle n’aura pas été redémarrée.
Ne configurez pas votre réseau virtuel avec la plage d’adresses IP détenue par Microsoft qui contient 168.63.129.16. La configuration va entrer en conflit avec l’adresse IP de la sonde d’intégrité et risquent de faire échouer votre scénario.
Pour tester un échec de sonde d’intégrité ou marquer une instance individuelle, utilisez un groupe de sécurité réseau pour bloquer explicitement la sonde d’intégrité. Créez une règle NSG pour bloquer le port de destination ou l'adresse IP source afin de simuler la défaillance d’une sonde.
Contrairement aux règles d’équilibrage de charge, les règles NAT de trafic entrant n’ont pas besoin d’être accompagnées d’une sonde d’intégrité.
Il n’est pas recommandé de bloquer l’adresse IP ou le port de la sonde d’intégrité Azure Load Balancer avec des règles de groupe de sécurité réseau. Il s’agit d’un scénario non pris en charge et peut entraîner l’effet différé des règles de groupe de sécurité réseau, ce qui entraîne l’inexactitude des sondes d’intégrité pour représenter de manière inexacte la disponibilité de vos instances principales.
Surveillance
Standard Load Balancer expose l’état des sondes d’intégrité par point de terminaison et par point de terminaison back-end via Azure Monitor. Ces métriques peuvent être utilisées par d’autres services Azure ou par des applications partenaires. Les journaux Azure Monitor ne sont pas pris en charge pour Basic Load Balancer.
Adresse IP source de sonde
Pour que la sonde d’intégrité d’Azure Load Balancer marque votre instance positivement, vous devez autoriser l’adresse IP 168.63.129.16 dans tous les groupes de sécurité réseau Azure et dans les stratégies de pare-feu local. L’étiquette de service AzureLoadBalancer identifie cette adresse IP source dans vos groupes de sécurité réseau et autorise par défaut le trafic de la sonde d’intégrité. Vous pouvez en apprendre davantage sur cette adresse IP ici.
Si vous n’autorisez pas l’adresse IP source de la sonde dans vos stratégies de pare-feu, la sonde d’intégrité échoue, car il lui est impossible d’atteindre votre instance. Azure Load Balancer marque à son tour votre instance comme étant hors service en raison de l’échec de la sonde d’intégrité. Une configuration incorrecte peut entraîner l’échec du scénario de votre application avec équilibrage de charge. Toutes les sondes d’intégrité de l’équilibreur de charge IPv4 ont pour source l’adresse IP 168.63.129.16. Les sondes IPv6 se servent d’une adresse de lien local (fe80::1234:5678:9abc) comme source. Pour un équilibreur de charge Azure double pile, vous devez configurer un groupe de sécurité réseau pour que la sonde d’intégrité IPv6 fonctionne.
Limites
Les sondes HTTPS ne prennent pas en charge l’authentification mutuelle avec un certificat client.
Les sondes HTTP ne prennent pas en charge l’utilisation de noms d’hôte pour les back-ends de sondes.
L’activation des horodatages TCP peut entraîner des problèmes de limitation ou autres problèmes de performances, ce qui peut aboutir à l’expiration des sondes d’intégrité.
Une sonde d’intégrité de base de l'équilibreur de charge SKU n'est pas prise en charge avec un groupe de machines virtuelles identiques.
Les sondes HTTP ne peuvent pas prendre en charge la détection sur les ports suivants pour des raisons de sécurité : 19, 21, 25, 70, 110, 119, 143, 220, 993.