Balanceamento de carga de DNS LVS na máquina com apenas 1 NIC

Question

Primeiro de tudo, deixe-me esclarecer que eu sou apenas um desenvolvedor de software e não um administrador, portanto, tenho algum conhecimento (digamos um entendimento básico dos conceitos) em relação à configuração de rede, bem como a esses tipos de configuração. Não, por favor, tenha paciência comigo se isso soa estúpido ou irracional.

Estou tentando configurar o keepalived no RH7 para balancear as solicitações do NDS entre dois servidores nos quais o bind foi configurado. Nos guias que li até agora, eles parecem estar usando 2 NICs , mas só tenho um disponível.

Referências:

• LVS-NAT-Keepalived-HOWTO
• Página man do Keepalived
• PDF de instruções do LVS mini
• Este artigo parece ser sugerindo configurar os IPs reais dos mestres de DNS como servidores virtuais e os IPs do balanceador como servidores reais, mas não acho que esteja certo ... ou talvez eu esteja entendendo mal ou lendo-o incorretamente ?!

HW:

Eu tenho 3 computadores na mesma rede configurados da seguinte forma:

• 1 máquina com 1 NIC atuando como balanceador de carga, IP real 192.168.0.1
• 1 máquina com 1 NIC atuando como um servidor de ligação principal, IP real 192.168.0.2
• 1 máquina com 1 NIC agindo como um servidor de ligação principal, IP real 192.168.0.3

O encaminhamento também foi ativado net.ipv4.ip_forward = 1

Configuração mantida em funcionamento:

! This is a comment
! Configuration File for keepalived

global_defs {
   ! this is who emails will go to on alerts
   notification_email {
        [email protected]
        [email protected]
    ! add a few more email addresses here if you would like
   }
   notification_email_from [email protected]

   ! I use the local machine to relay mail
   smtp_server 127.0.0.1
   smtp_connect_timeout 30

   ! each load balancer should have a different ID
   ! this will be used in SMTP alerts, so you should make
   ! each router easily identifiable
   lvs_id LVS_EXAMPLE_01
}

! vrrp_sync_groups make sure that several router instances
! stay together on a failure - a good example of this is
! that the external interface on one router fails and the backup server
! takes over, you want the internal interface on the failed server
! to failover as well, otherwise nothing will work.
! you can have as many vrrp_sync_group blocks as you want.
vrrp_sync_group VG1 {
   group {
      VI_1
      VI_GATEWAY
   }
}

! each interface needs at least one vrrp_instance
! each vrrp_instance is a group of VIPs that are logically grouped
! together
! you can have as many vrrp_instaces as you want

vrrp_instance VI_1 {
        state MASTER
        interface eth0

        lvs_sync_daemon_inteface eth0

    ! each virtual router id must be unique per instance name!
        virtual_router_id 51

    ! MASTER and BACKUP state are determined by the priority
    ! even if you specify MASTER as the state, the state will
    ! be voted on by priority (so if your state is MASTER but your
    ! priority is lower than the router with BACKUP, you will lose
    ! the MASTER state)
    ! I make it a habit to set priorities at least 50 points apart
    ! note that a lower number is lesser priority - lower gets less vote
        priority 150

    ! how often should we vote, in seconds?
        advert_int 1

    ! send an alert when this instance changes state from MASTER to BACKUP
        smtp_alert

    ! this authentication is for syncing between failover servers
    ! keepalived supports PASS, which is simple password
    ! authentication
    ! or AH, which is the IPSec authentication header.
    ! I don't use AH
    ! yet as many people have reported problems with it
        authentication {
                auth_type PASS
                auth_pass example
        }

    ! these are the IP addresses that keepalived will setup on this
    ! machine. Later in the config we will specify which real
        ! servers  are behind these IPs
    ! without this block, keepalived will not setup and takedown the
    ! any IP addresses

        virtual_ipaddress {
                192.168.0.10
        ! and more if you want them
        }
}

! now I setup the instance that the real servers will use as a default
! gateway
! most of the config is the same as above, but on a different interface

vrrp_instance VI_GATEWAY {
        state MASTER
        interface eth0
        lvs_sync_daemon_inteface eth0 
        virtual_router_id 52
        priority 150
        advert_int 1
        smtp_alert
        authentication {
                auth_type PASS
                auth_pass example
        }
        virtual_ipaddress {
                192.168.0.11
        }
}

! now we setup more information about are virtual server
! we are just setting up one for now, listening on port 53 for dns
! requests.

! notice we do not setup a virtual_server block for the 192.168.0.10
! address in the VI_GATEWAY instance. That's because we are doing NAT
! on that IP, and nothing else.

virtual_server 192.168.0.10 53 {
    delay_loop 6

    ! use round-robin as a load balancing algorithm
    lb_algo rr

    ! we are doing NAT
    lb_kind NAT
    nat_mask 255.255.255.0

    protocol TCP

    ! there can be as many real_server blocks as you need

    real_server 192.168.0.2 53 {

    ! if we used weighted round-robin or a similar lb algo,
    ! we include the weight of this server

        weight 1

    ! here is a health checker for this server.
    ! we could use a custom script here (see the keepalived docs)
    ! but we will just make sure we can do a vanilla tcp connect()
    ! on port 53
    ! if it fails, we will pull this realserver out of the pool
    ! and send email about the removal
        TCP_CHECK {
            connect_timeout 3
            connect_port 53
        }
    }

    real_server 192.168.0.3 53 {

    ! if we used weighted round-robin or a similar lb algo,
    ! we include the weight of this server

        weight 1

    ! here is a health checker for this server.
    ! we could use a custom script here (see the keepalived docs)
    ! but we will just make sure we can do a vanilla tcp connect()
    ! on port 53
    ! if it fails, we will pull this realserver out of the pool
    ! and send email about the removal
        TCP_CHECK {
            connect_timeout 3
            connect_port 53
        }
    }
}

Conclusão:

O firewall está desabilitado e a conectividade funciona bem entre as máquinas, podendo o keepalived validar uma conexão TCP simples para os mestres de DNS. Eu também sou capaz de executar dig myhost @192.168.0.2/3 do balanceador de carga e estou obtendo os resultados corretos.

No entanto, ao executar dig myhost @192.168.0.10 , recebo um ;; connection timed out; no servers could be reached . Eu ficaria grato por quaisquer sugestões ou sugestões que me ajudariam a superar este problema, se for possível com 1 NIC e, por favor, deixe-me saber se detalhes adicionais são necessários.

    

Answer 1

Após mais algumas pesquisas, ocorreu-me que talvez o UDP também seja necessário, além do TCP, e que parece ser o caso de fato (note para si mesmo: provavelmente teria ajudado se eu tivesse usado um tcpdump / tshark ...):

Protocol transport

DNS primarily uses the User Datagram Protocol (UDP) on port number 53 to serve requests. DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server. The Transmission Control Protocol (TCP) is used when the response data size exceeds 512 bytes, or for tasks such as zone transfers. Some resolver implementations use TCP for all queries.

O mesmo também é sugerido por este artigo antigo sobre DNS de balanceamento de carga com keepalived escrito em 2006.

Em consequência, adicionei a seguinte configuração do UDP ao que já estava presente:

virtual_server 192.168.0.10 53 {
    delay_loop 6

    ! use round-robin as a load balancing algorithm
    lb_algo rr

    ! we are doing NAT
    lb_kind NAT
    nat_mask 255.255.255.0

    protocol UDP

    ! there can be as many real_server blocks as you need

    real_server 192.168.0.2 53 {
        ! if we used weighted round-robin or a similar lb algo,
        ! we include the weight of this server
        weight 1
    }

    real_server 192.168.0.3 53 {
        ! if we used weighted round-robin or a similar lb algo,
        ! we include the weight of this server
        weight 1
    }
}

Nota: No PDF de instruções do LVS mini , havia um < em> pegadinha :

2.2. Gotchas: you need an outside client (the director and realservers can’t access the virtual service)

Como o PDF também parece antigo (2006), não é mais o caso. Agora sou capaz de cavar a partir do próprio balanceador de carga; no entanto, ao usar uma máquina cliente diferente da mesma rede, recebo um ;; reply from unexpected source: 192.168.0.2#53, expected 192.168.0.10#53 . Eu tentei a sugestão abaixo de esta pergunta , mas até agora não funciona:

sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv4.vs.conntrack=1
iptables -t nat -A POSTROUTING -j MASQUERADE

Pelo que eu aprendi até agora, isso pode ter algo a ver com a topologia de rede e configuração de NAT, mas ainda tenho que descobrir isso.

Parece que ainda tenho navegação, mas pelo menos tenho algo com que trabalhar e agora sei que 1 NIC é suficiente para balancear a carga dos 2 servidores DNS (pelo menos para os testes que estou fazendo agora).