1のみのマシンでのLVSDNS負荷分散NIC

Question

まず、私は管理者ではなくソフトウェア開発者にすぎないことを明確にしておきます。したがって、ネットワーク構成とこれらのタイプのセットアップに関する知識（概念の基本的な理解など）はありますが、私はエースではありません。ですから、これがばかげている、または不合理に聞こえる場合は、私にご容赦ください。

バインドが設定されている2台のサーバー間でNDS要求のバランスをとるようにRH7でkeepalivedを構成しようとしています。これまで読んだガイドでは、2つのNICを使用しているようですが、私は1つしか持っていません利用可能。

参照：

• LVS-NAT-キープアライブ-HOWTO
• Keepalivedのマニュアルページ
• LVSミニハウツーPDF
• この記事 DNSマスターの実際のIPを仮想サーバーとして構成し、バランサーのIPを実際のサーバーとして構成することを提案しているようですが、それは正しくないと思います...またはおそらく私はそうです誤解や誤読？！

HW：

同じネットワーク上に3台のマシンが次のように構成されています。

• 1台のマシンと1 NICロードバランサーとして機能、実際のIP 192.168.0.1
• 1台のマシンと1 NICメインバインドサーバーとして機能、実際のIP 192.168.0.2
• 1台のマシンと1 NICメインバインドサーバーとして機能、実際のIP 192.168.0.3

また、転送が有効になっていますnet.ipv4.ip_forward = 1

Keepalived構成：

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

結論：

ファイアウォールが無効になり、マシン間の接続が正常に機能し、キープアライブで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で可能であれば、この問題を解決するのに役立つヒントや提案をいただければ幸いです。さらに詳細が必要な場合はお知らせください。

Answer 1

もう少し調べてみると、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ハウツーPDF に落とし穴がありました：：

2.2。落とし穴：外部クライアントが必要です（ディレクターと実サーバーは仮想サービスにアクセスできません）

PDFも古いようです（2006）ので、もうそうではありません。今では、Digを実行できるようになりました。ロードバランサー自体ですが、同じネットワークから別のクライアントマシンを使用すると、;; 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サーバーの負荷を分散するのに十分であることがわかりました（少なくともテストでは私は今やっています）。