Comprendre F5 · NGINX

NGINX : upstreams, répartition et pannes de serveurs

Choisir une méthode de répartition NGINX Open Source et comprendre les échecs passifs, retries, connexions keepalive et retrait d’un serveur.

Thomas SAUTIER · Publié le · Révisions de certification

  • Référence de F5CAN2 consultée le · Objectifs abordés : F5CAN2 1.1.
  • Référence de F5CAN3 consultée le · Objectifs abordés : F5CAN3 1.1.
  • Référence de F5CANR consultée le · Objectifs abordés : F5CANR 2.1, F5CANR 3.1.

Ce guide concerne NGINX Open Source. Vérifiez la version, les modules compilés ou chargés et les particularités de votre paquet.

Relier la méthode au comportement recherché

Un upstream décrit les serveurs susceptibles de traiter une requête. Round robin pondéré, least_conn et les méthodes fondées sur un hash répondent à des besoins différents. La répartition ne garantit pas que le nombre de requêtes observé sera égal à chaque instant : poids, connexions et affinité interviennent.

least_conn choisit selon les connexions actives, en tenant compte des poids. ip_hash cherche une affinité liée à l’adresse cliente ; derrière un NAT, plusieurs utilisateurs peuvent partager cette valeur. Un choix de méthode doit être confronté aux sessions et à la variabilité du coût des requêtes.

Repère visuelupstreams, répartition et pannes de serveurs
upstreams, répartition et pannes de serveurs L’upstream choisit un serveur selon la méthode et son état. Les échecs réellement observés alimentent la décision de retrait et les conditions de nouvelle tentative. 01 Requête méthode et affinité 02 Upstream état partagé 03 Serveur A connexions actives 04 Serveur B connexions actives 05 Échec observation passive 06 Décision retrait ou tentative
L’upstream choisit un serveur selon la méthode et son état. Les échecs réellement observés alimentent la décision de retrait et les conditions de nouvelle tentative.

Sources : NGINX / F5, Module ngx_http_upstream_module ; NGINX / F5, Using nginx as HTTP load balancer.

Comprendre ce qui détecte une panne

Les mécanismes passifs apprennent des échecs observés pendant les requêtes. max_fails et fail_timeout déterminent la prise en compte d’un serveur indisponible dans les conditions documentées. Les contrôles actifs intégrés d’état de santé relèvent des fonctionnalités commerciales ; ne les attribuez pas au seul fragment OSS.

Le groupe ci-dessous est un exemple à placer dans http. Il suppose deux serveurs locaux de laboratoire. Une zone upstream partage l’état entre workers. Les paramètres de panne ont des exceptions, notamment pour un groupe à un seul serveur ; lisez la référence avant d’interpréter un résultat.

Groupe de serveurs locaux pédagogiquesConfiguration NGINX · contexte http
upstream revision_app {
    zone revision_app 64k;
    least_conn;
    server 127.0.0.1:9001 max_fails=2 fail_timeout=10s;
    server 127.0.0.1:9002 max_fails=2 fail_timeout=10s;
    keepalive 16;
}

Sources : NGINX / F5, Module ngx_http_upstream_module ; NGINX / F5, Using nginx as HTTP load balancer.

Réutilisation et retrait d’un serveur

Le keepalive upstream conserve des connexions inactives pour les réutiliser. Sa taille ne constitue pas une limite globale du nombre de connexions aux serveurs. Le protocole et les en-têtes de connexion doivent être cohérents ; vérifiez les valeurs par défaut de votre version au lieu de supposer celles d’un ancien exemple.

Pour retirer un serveur, préparez la modification, validez puis rechargez. Les échanges déjà pris en charge et les nouveaux échanges doivent être considérés séparément. Les retries ne sont pas gratuits : une requête dont l’effet métier a commencé ne doit pas être rejouée sans examiner l’idempotence et les conditions de proxy_next_upstream.

Sources : NGINX / F5, Module ngx_http_upstream_module ; NGINX / F5, Module ngx_http_proxy_module ; NGINX / F5, Controlling nginx.

Exercice : répartition inégale et panne

Votre laboratoire montre davantage de requêtes sur un serveur. Comparez la méthode, les poids, l’affinité, l’état passif et les connexions actives. Un simple décompte de réponses n’établit pas à lui seul un défaut de répartition. Relevez aussi les tentatives upstream dans les journaux.

Préparez ensuite un scénario où un serveur devient indisponible. Précisez le type d’échec, la méthode de retrait, le comportement attendu pour une requête sûre et celui pour une opération métier. La recette doit démontrer le comportement observé, sans promettre une absence universelle d’erreurs pendant la panne.

Sources : NGINX / F5, Module ngx_http_upstream_module ; NGINX / F5, Module ngx_http_proxy_module ; NGINX / F5, Module ngx_http_log_module.

Sources et portée

Références consultées le . Les exemples utilisent des noms et adresses de documentation à remplacer. Les commandes de lecture affichent l’existant ; les captures et requêtes de diagnostic sont à limiter au périmètre autorisé.

Retrouver le parcours de lecture F5 NGINX

Continuer la série F5

Explorer tous les guides du parcours F5 NGINX

Découvrir l’expertise F5 de Samhan

Échange

Besoin d’éclaircir votre architecture F5 ?

Échangeons sur vos flux, vos contraintes de disponibilité et votre services applicatifs.