HAProxy, vérification de l'intégrité de plusieurs serveurs avec des noms d'hôtes différents

11

Je dois équilibrer la charge entre plusieurs serveurs en cours d'exécution avec des noms d'hôtes différents. Je ne peux pas configurer le même hôte virtuel sur chacun d'eux.

Est-il possible d'avoir une seule configuration d'écoute avec plusieurs serveurs et de faire appliquer la http-send-name-header Hostdirective aux contrôles d' intégrité? J'utilise HAProxy 1.5.

J'ai trouvé ce haproxy.cfg fonctionnel, comme vous pouvez le voir, j'ai dû définir un nom d'hôte différent pour chaque contrôle de santé car le contrôle de santé ignore le http-send-name-header Host. J'aurais préféré utiliser des variables ou d'autres méthodes et garder les choses plus concises.

global
    log 127.0.0.1 local0 notice
    maxconn 2000
    user haproxy
    group haproxy

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    retries 3
    option redispatch
    timeout connect  5000
    timeout client  10000
    timeout server  10000
    stats enable
    stats uri /haproxy?stats
    stats refresh 5s
    balance roundrobin
    option httpclose

listen inbound :80    
    option httpchk HEAD / HTTP/1.1\r\n
    server instance1 127.0.0.101 check inter 3000 fall 1 rise 1
    server instance2 127.0.0.102 check inter 3000 fall 1 rise 1

listen instance1 127.0.0.101:80
    option forwardfor
    http-send-name-header Host
    option httpchk HEAD / HTTP/1.1\r\nHost:\ www.example.com
    server www.example.com www.example.com:80 check inter 5000 fall 3 rise 2

listen instance2 127.0.0.102:80
    option forwardfor
    http-send-name-header Host
    option httpchk HEAD / HTTP/1.1\r\nHost:\ www.bing.com
    server www.bing.com www.bing.com:80 check inter 5000 fall 3 rise 2
Marco Bettiolo
la source

Réponses:

2
defaults
log global
retries 2
timeout connect 3000
timeout server 5000
timeout client 5000

listen any-name-1
bind IP-Address:port
mode tcp or http
option user-check user haproxy_check
balance roundrobin
server hostname IpAddress:port check
server hostname  IpAddress:port check
listen any-name-2
bind IP-Address:port
mode tcp or http
option user-check user haproxy_check
balance roundrobin
server hostname IpAddress:port check
server hostanme  IpAddress:port check

listen any-name-3
bind IP-Address:port
mode tcp or http
option user-check user haproxy_check
balance roundrobin
server hostname IpAddress:port check
server hostname  IpAddress:port check

listen any-name-4
bind IP-Address:port
mode tcp or http
option user-check user haproxy_check
balance roundrobin
server hostname IpAddress:port check
server hostname  IpAddress:port check

listen any-name-5
bind IP-Address:port
mode tcp or http
option user-check user haproxy_check
balance roundrobin
server hostname IpAddress:port check
server hostname  IpAddress:port check

listen haproxyadmin
bind HAproxyServerIP:HaproxyPort
mode http
stats enable
stats uri /haproxy
stats realm Strictly\ Private
stats auth username:password
mohit singh
la source
1

Mise à jour : dans le cas que vous avez décrit, vous avez besoin de vérifications HTTP / 1.1 qui nécessitent le nom d'hôte codé en dur. Compte tenu de la documentation de la version 1.5, il ne semble pas y avoir de moyen d'éviter cela à moins que vous ne puissiez vous permettre de supprimer les vérifications http (ce qui bien sûr n'est généralement pas recommandé).

Réponse originale : Bien que je ne sois pas familier avec les changements de 1.5 de haproxy, ce que je ferais en 1.4 (et je suis assez sûr qu'il s'applique toujours en 1.5) est le suivant. Notez que la séparation frontend / backend est juste une commodité personnelle et vous pouvez simplement utiliser écouter.

defaults
    mode http
    option  httplog
    timeout connect  5000
    timeout client  10000
    timeout server  10000

frontend inbound
    bind 127.0.0.1:8000
    default_backend webservers

backend webservers
    option forwardfor
    option httpchk HEAD / HTTP/1.0
    http-send-name-header Host
    server google www.google.com:80 check inter 5000 fall 3 rise 2
    server bing www.bing.com:80 check inter 5000 fall 3 rise 2

Et le résultat:

$ curl -i localhost:8000
HTTP/1.1 301 Moved Permanently
Cache-Control: no-cache
Content-Length: 0
Location: http://www.bing.com/
Server: Microsoft-IIS/8.0
P3P: CP="NON UNI COM NAV STA LOC CURa DEVa PSAa PSDa OUR IND"
Set-Cookie: _HOP=I=1&TS=1399981378; path=/
Edge-control: no-store
X-MSEdge-Ref: Ref A: 26CEE14531BF45EFAC91FAC3D1945EDF Ref B: 42CE8D142D427C30F7851B56F38837A6 Ref C: Tue May 13 04:42:58 2014 PST
Date: Tue, 13 May 2014 11:42:57 GMT

$ curl -i localhost:8000
HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/
Content-Type: text/html; charset=UTF-8
X-Content-Type-Options: nosniff
Date: Tue, 13 May 2014 11:43:00 GMT
Expires: Thu, 12 Jun 2014 11:43:00 GMT
Cache-Control: public, max-age=2592000
Server: sffe
Content-Length: 219
X-XSS-Protection: 1; mode=block
Alternate-Protocol: 80:quic

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
$
user76776
la source
Je pense que votre méthode ne fonctionnerait pas car elle ne définit pas l'en-tête Host. Sans en-tête d'hôte, la demande n'atteindra jamais le serveur Web prévu. Vous pouvez tester cela avecexample.heroku.com
Marco Bettiolo
Vous avez raison, le httpchk nécessite l'en-tête Host dans l'exemple heroku, et il n'y a pas de solution pour cela. La suppression de la directive de vérification laisserait le proxy fonctionner comme prévu, mais vous ne seriez pas en mesure de détecter à l'avance une défaillance.
user76776
c'est exactement mon problème, en assurant un contrôle d'intégrité aux instances cloud qui nécessitent les en-têtes d'hôte corrects.
Marco Bettiolo
Je ne peux pas supprimer les contrôles HTTP / 1.1. Je vais m'en tenir à ma mise en œuvre pour l'instant.
Marco Bettiolo