Redhat

僅具有 1 個 NIC 的機器上的 LVS DNS 負載平衡

  • March 11, 2016

首先讓我澄清一下,我只是一個軟體開發人員而不是管理員,因此我對網路配置以及這些類型的設置有一些知識(比如說對概念的基本理解),但我不是王牌,因此,如果這聽起來很愚蠢或不合理,請多多包涵。

我正在嘗試在 RH7 上配置 keepalived 以平衡已設置綁定的 2 台伺服器之間的 NDS 請求。在我目前閱讀的指南中,他們似乎使用了 2 個 NIC,但我只有一個可用。

參考:

硬體:

我在同一網路上有 3 台機器,配置如下:

  • 1台機器1個網卡作為負載均衡器,真實IP 192.168.0.1
  • 1台機器1個網卡作為主綁定伺服器,真實IP 192.168.0.2
  • 1台機器1個網卡作為主綁定伺服器,真實IP 192.168.0.3

還啟用了轉發net.ipv4.ip_forward = 1

保活配置:

! This is a comment
! Configuration File for keepalived

global_defs {
  ! this is who emails will go to on alerts
  notification_email {
       admins@example.com
       fakepager@example.com
   ! add a few more email addresses here if you would like
  }
  notification_email_from admins@example.com

  ! 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
       }
   }
}

結論:

防火牆被禁用,機器之間的連接工作正常,keepalived 能夠驗證到 DNS 主機的簡單 TCP 連接。我也可以dig myhost @192.168.0.2/3從負載均衡器執行,並且得到正確的結果。

但是,在執行時dig myhost @192.168.0.10我得到一個;; connection timed out; no servers could be reached. 如果有任何提示或建議可以幫助我克服這個問題,我將不勝感激,如果它甚至可以使用 1 個 NIC,如果需要更多詳細資訊,請告訴我。

在Google搜尋之後,我突然想到除了 TCP 之外可能還需要 UDP,而且似乎確實如此(自我注意:如果我使用 tcpdump/tshark 可能會有所幫助…… ):

協議傳輸

DNS 主要使用埠號 53 上的使用者數據報協議 (UDP) 來處理請求。DNS 查詢由來自客戶端的單個 UDP 請求和來自伺服器的單個 UDP 回复組成。傳輸控制協議 (TCP) 在響應數據大小超過 512 字節時使用,或用於區域傳輸等任務。一些解析器實現對所有查詢都使用 TCP。

在 2006 年寫的關於使用 keepalived 進行負載平衡 DNS的這篇較早的文章也提出了同樣的建議。

因此,我在已經存在的內容中添加了以下 UDP 配置:

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
   }
}

注意:LVS mini how-to PDF中有一個問題

2.2. 陷阱:您需要一個外部客戶端(director 和 realservers 無法訪問虛擬服務)

由於 PDF 似乎也很舊(2006 年),因此不再是這種情況。我現在能夠從負載均衡器本身進行探勘,但是當使用來自同一網路的不同客戶端機器時,我會得到一個;; reply from unexpected source: 192.168.0.2#53, expected 192.168.0.10#53. 我從這個問題嘗試了以下建議,但到目前為止它沒有奏效:

sysctl -w net.ipv4.ip_forward=1

sysctl -w net.ipv4.vs.conntrack=1

iptables -t nat -A POSTROUTING -j MASQUERADE

從我目前收集到的資訊來看,這可能與網路拓撲和 NAT 設置有關,但我還需要弄清楚這一點。

看起來我還有一些衝浪要做,但至少我有一些工作要做,我現在知道 1 個 NIC 足以負載平衡 2 個 DNS 伺服器(至少對於我現在正在做的測試)。

引用自:https://serverfault.com/questions/763195