Proxy Apache équilibrage de la charge serveur d'arrière-plan de détection de défaillance

Voici mon scénario (conçu par mon prédécesseur):

Deux serveurs Apache servir de proxy inverse l'obligation pour un certain nombre de mixte backend serveurs web (Apache, IIS, Tomcat, etc.). Il y a quelques sites pour lesquels nous avons plusieurs backend serveurs web, et dans ces cas, nous faisons quelque chose comme:

<Proxy balancer://www.example.com>
    BalancerMember http://192.168.1.40:80
    BalancerMember http://192.168.1.41:80
</Proxy>
<VirtualHost *:80>
    ServerName www.example.com:80
    CustomLog /var/log/apache2/www.example.com.log combined
    <Location />
        Order allow,deny
        Allow from all
        ProxyPass balancer://www.example.com/
        ProxyPassReverse balancer://www.example.com/
    </Location>
</VirtualHost>

Donc dans cet exemple, j'ai un site (www.example.com) dans les serveurs proxy' configs, et que ce site est acheminé vers l'un ou l'autre des deux serveurs backend, 192.168.1.40 et .41.

Je suis l'évaluation de ce pour s'assurer que nous sommes à tolérance de pannes sur l'ensemble de nos services web (j'ai déjà mis les deux serveurs proxy inverses dans un IP partagé de cluster pour cette raison), et je veux m'assurer que la charge est équilibrée backend serveurs à tolérance de pannes. Mais je vais avoir du mal à déterminer si backend de détection de défaillance (et de la logique pour éviter l'échec du serveur d'arrière-plan) est intégré dans le mod_proxy_balancer module...

Donc si 192.168.202.40 descend, va Apache détecter ce (je comprendrai si il prend l'échec d'une première demande) et d'acheminer automatiquement toutes les demandes pour les autres backend, 192.168.202.41? Ou continueront-ils de l'équilibre entre l'échec de l'backend et le backend?

J'ai trouvé quelques indices dans la documentation d'Apache pour mod_proxy et mod_proxy_balancer qui semblent indiquer que le défaut peut être détecté ("maxattempts = nombre Maximum d'échecs avant d'abandonner.", "failonstatus = Un seul ou une liste séparée par des virgules des codes d'état HTTP. Si la valeur de cette force de l'ouvrier en état d'erreur lorsque le backend retourne tous les codes de statut dans la liste."), mais après quelques jours de recherche, je n'ai rien trouvé de concluant dire pour sûr qu'il sera (ou au moins "devrait") détecter backend de défaillance et de récupération.

Je dirai que la plupart des résultats de recherche de référence en utilisant le protocole AJP pour passer le trafic vers le serveur d'arrière-plan, et ce qui, apparemment, prend en charge la détection de défaillance-- mais mon backends sont un mélange de Apache, IIS, Tomcat et les autres, et je suis assez sûr que beaucoup d'entre eux ne supportent pas l'AJP. Ils sont également un mélange de Windows 2k3/2k8 et Linux (surtout Ubuntu Lucid) cases de l'exécution de diverses applications différentes avec différentes exigences, de sorte que des modules supplémentaires comme le Revers et LVS ne sont pas une option pour moi.

J'ai aussi essayé de tester empiriquement cette fonctionnalité, par la création d'un nouveau site de test comme ceci:

<Proxy balancer://test.example.com>
    BalancerMember http://192.168.1.40:80
    BalancerMember http://192.168.1.200:80
</Proxy>
<VirtualHost *:80>
    ServerName test.example.com:80
    CustomLog /var/log/apache2/test.example.com.log combined
    LogLevel debug
    <Location />
        Order allow,deny
        Allow from all
        ProxyPass balancer://test.example.com/
        ProxyPassReverse balancer://test.example.com/
    </Location>
</VirtualHost>

Où 192.168.1.200 est une fausse adresse qui n'est pas en cours d'exécution à tout serveur web, afin de simuler un backend échec. Le site de test a été servi sans problème pour un tas de différentes machines clientes, mais même avec le niveau de Journalisation set debug, je n'ai rien vu connecté pour indiquer qu'il a détecté qu'un des serveurs back-end a été vers le bas... Et j'aimerais le faire à 100% sûr que je peux prendre à notre charge équilibrée backends vers le bas pour l'entretien (un à la fois, bien sûr) sans affecter les sites de production.

OriginalL'auteur Jon Heese | 2012-08-08