HAProxy parece estar balanceando a carga em vez de seguir as regras da ACL

2

Estou vendo um comportamento muito estranho com o HAProxy. Eu tenho a seguinte configuração abaixo projetada para permitir que example.com/wiki vá para um servidor e example.com/ vá para outro. O problema é que parece que o / wiki só funciona metade do tempo e o / webserver funciona apenas metade do tempo também. Após um exame mais detalhado, parece que ele está alternando entre os dois backends; possivelmente balanceamento de carga, em vez de ir a um back-end específico com base nas regras da ACL!

Outra coisa estranha é que ambos services-staging.example.com/greenoven e staging.example.com iriam para o kumquat, mesmo que as regras digam especificamente que somente o host de preparação de serviços deve ir para esse backend.

Há algo errado com minha configuração do HAProxy? Estou usando acls ou backends incorretamente?

global
        log 127.0.0.1   local1 debug
        maxconn 200000
        chroot /var/lib/haproxy
        user haproxy
        group haproxy
        daemon
        #debug
        #quiet

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        retries 3
        option redispatch
        maxconn 200000
        contimeout      5000
        clitimeout      50000
        srvtimeout      50000

        stats uri /monitor
        stats auth admin:GS01
        stats refresh 5s
        stats enable


frontend http-in
        bind *:80

        option forwardfor

        #Staging Hosts

        acl host_staging hdr(host) -i staging.example.com
        acl host_staging_services hdr(host) -i staging-services.example.com

        #Production Hosts

        acl host_prod hdr(host) -i example.com www.example.com
        acl host_prod_services hdr(host) -i services.urbanatla.com

        #URL Paths

        acl url_wiki url_beg /wiki
        acl url_go   url_beg /greenoven
        acl url_arcgis url_beg /ArcGIS

        #Staging Backends

        use_backend pluto if host_staging_services url_arcgis
        use_backend kumquat if host_staging_services url_go
        use_backend kumquat if host_staging url_wiki
        use_backend cumberland if host_staging

        #Production Backends

        use_backend saturn if host_prod_services url_arcgis
        use_backend willow if host_prod_services url_go
        use_backend willow if host_prod url_wiki
        use_backend ganges if host_prod


backend kumquat
        server kumquat kumquat.example.com:8080 maxconn 5000

backend cumberland
        server cumberland cumberland.example.com:80 maxconn 5000

backend ganges
        server ganges ganges.example.com:80 maxconn 5000

backend articdata
        server articdata  articdata.example.com:80 maxconn  5000

backend saturn
        server saturn saturn.example.com:80 maxconn 5000

backend willow
        server willow willow.example.com:8080 maxconn 5000

backend pluto
        server pluto pluto.example.com:80 maxconn 5000        
    
por djsumdog 12.09.2011 / 04:33

2 respostas

3

Parece que estava reutilizando conexões, o que você não deve fazer quando estiver realizando a troca de contexto. Eu adicionei o seguinte:

option httpclose

por este post: Por que estou recebendo erros na minha configuração de switching de conteúdo HAProxy? .

Todos os URLs e domínios funcionam corretamente agora.

    
por 12.09.2011 / 16:43
1

Se você ler na documentação do haproxy, você encontrará este parágrafo:

hdr(name)   The HTTP header <name> will be looked up in each HTTP request.
            Just as with the equivalent ACL 'hdr()' function, the header
            name in parenthesis is not case sensitive. If the header is
            absent or if it does not contain any value, the roundrobin
            algorithm is applied instead.

Isso pode explicar por que o haproxy está fazendo o balanceamento de carga entre os servidores que não seguem as ACLs. Para ter certeza, você precisa verificar se realmente está recebendo a solicitação com host header.

Acho que você pode usar o IP, nome ou URL de destino em vez de verificar o cabeçalho host .

    
por 12.09.2011 / 09:05