web-dev-qa-db-ja.com

ISCDHCPがピア間のリースの同期に失敗する

両方のサーバーのDebianGNU/LinuxでISCDHCPバージョン4.1.1を使用しています。さまざまなバージョンのISCDHCPを使用して次の問題を解決しようとしましたが、同じままでした。

異なるサブネット上の2つのサーバー間のフェイルオーバーの構成は次のとおりです。

#-----------------------------------------------
# Primary Server
#-----------------------------------------------

authoritative;
default-lease-time 900;
max-lease-time 1800;         
option domain-name "foo.com";
option domain-name-servers 10.12.0.254;

failover peer "foo" {
    primary;
    address 10.12.0.254;
    port 647;
    peer address 10.10.10.12;
    peer port 647;
    max-response-delay 30;
    max-unacked-updates 10;
    load balance max seconds 3;
    mclt 1800;  
    split 128;
}

subnet 10.12.0.0 netmask 255.255.0.0 {
    pool {
        failover peer "foo";
        range 10.12.10.0 10.12.112.0;
        range 10.12.112.12 10.12.255.254;
        deny dynamic bootp clients;
    }
    option routers 10.12.0.254;
    option subnet-mask 255.255.0.0;
    option broadcast-address 10.12.255.255;
}

#-----------------------------------------------
# Secondary Server
#-----------------------------------------------

authoritative;
default-lease-time 900;
max-lease-time 1800;
option domain-name "foo.com";
option domain-name-servers 10.12.0.254;

failover peer "foo" {
        secondary;
        address 10.10.10.12;
        port 647;
        peer address 10.12.0.254;
        peer port 647;
        max-response-delay 30;
        max-unacked-updates 10;
        load balance max seconds 3;
}

subnet 10.12.0.0 netmask 255.255.0.0 {
        pool {
                failover peer "foo";
                range 10.12.10.0 10.12.112.0;
                range 10.12.112.12 10.12.255.254;
        deny dynamic bootp clients;
        }
    option routers 10.12.0.254;
    option subnet-mask 255.255.0.0;
    option broadcast-address 10.12.255.255;
}

subnet 10.10.10.0 netmask 255.255.255.240 {
}

IPヘルパー（別名UDPヘルパー）とDHCPリレーは、プライマリサーバーのネットワークとセカンダリサーバーのネットワークを接続するルーターで有効になっています。あるサーバーから別のサーバーにpingおよびsshを実行できます。

両方のサーバーでdhcpdサービスを開始すると、リースのバランスが取れません。

両方のサーバーのログのサンプルを貼り付けます

プライマリサーバー

Sep 19 10:31:11 primary dhcpd: failover peer foo: I move from recover to startup
Sep 19 10:31:11 primary dhcpd: failover peer foo: I move from startup to recover
Sep 19 10:31:11 primary dhcpd: Sent update request all message to foo
Sep 19 10:31:20 primary dhcpd: peer foo: disconnected
Sep 19 10:31:22 primary dhcpd: failover peer foo: peer moves from recover-done to recover-done
Sep 19 10:31:22 primary dhcpd: failover peer foo: peer moves from recover-done to recover-done
Sep 19 10:31:45 primary dhcpd: DHCPINFORM from 10.12.181.177 via eth1
Sep 19 10:31:45 primary dhcpd: DHCPACK to 10.12.181.177 (00:17:42:c0:e3:ce) via eth1
Sep 19 10:32:45 primary dhcpd: DHCPDISCOVER from 00:16:d3:e5:3a:3c (PC1) via eth1: not responding (recovering)
Sep 19 10:32:46 primary dhcpd: DHCPINFORM from 10.12.181.177 via eth1
Sep 19 10:32:46 primary dhcpd: DHCPACK to 10.12.181.177 (00:17:42:c0:e3:ce) via eth1
Sep 19 10:32:49 primary dhcpd: DHCPDISCOVER from 00:16:d3:e5:3a:3c (PC1) via eth1: not responding (recovering)
Sep 19 10:32:57 primary dhcpd: DHCPDISCOVER from 00:16:d3:e5:3a:3c (PC1) via eth1: not responding (recovering)
Sep 19 10:33:13 primary dhcpd: DHCPDISCOVER from 00:19:99:95:41:99 (PC2) via eth1: not responding (recovering)
Sep 19 10:33:13 primary dhcpd: DHCPDISCOVER from 00:16:d3:e5:3a:3c (PC1) via eth1: not responding (recovering)
Sep 19 10:33:17 primary dhcpd: DHCPDISCOVER from 00:19:99:95:41:99 (PC2) via eth1: not responding (recovering)
Sep 19 10:33:25 primary dhcpd: DHCPDISCOVER from 00:19:99:95:41:99 (PC2) via eth1: not responding (recovering)
Sep 19 10:33:41 primary dhcpd: DHCPDISCOVER from 00:19:99:95:41:99 (PC2) via eth1: not responding (recovering)

セカンダリサーバー

Sep 19 10:31:11 secondary dhcpd: Update request all from foo: sending update
Sep 19 10:31:23 secondary dhcpd: Wrote 22 leases to leases file.
Sep 19 10:31:23 secondary dhcpd: failover peer foo: I move from recover-done to startup
Sep 19 10:31:23 secondary dhcpd: failover peer foo: I move from startup to recover-done
Sep 19 10:31:45 secondary dhcpd: DHCPINFORM from 10.12.181.177 via 10.12.0.1
Sep 19 10:31:45 secondary dhcpd: DHCPACK to 10.12.181.177 (00:17:42:c0:e3:ce) via eth0
Sep 19 10:32:45 secondary dhcpd: DHCPDISCOVER from 00:16:d3:e5:3a:3c via 10.12.0.1: not responding (recover done)
Sep 19 10:32:46 secondary dhcpd: DHCPINFORM from 10.12.181.177 via 10.12.0.1
Sep 19 10:32:46 secondary dhcpd: DHCPACK to 10.12.181.177 (00:17:42:c0:e3:ce) via eth0
Sep 19 10:32:49 secondary dhcpd: DHCPDISCOVER from 00:16:d3:e5:3a:3c via 10.12.0.1: not responding (recover done)
Sep 19 10:32:57 secondary dhcpd: DHCPDISCOVER from 00:16:d3:e5:3a:3c via 10.12.0.1: not responding (recover done)
Sep 19 10:33:13 secondary dhcpd: DHCPDISCOVER from 00:19:99:95:41:99 via 10.12.0.1: not responding (recover done)
Sep 19 10:33:13 secondary dhcpd: DHCPDISCOVER from 00:16:d3:e5:3a:3c via 10.12.0.1: not responding (recover done)
Sep 19 10:33:17 secondary dhcpd: DHCPDISCOVER from 00:19:99:95:41:99 via 10.12.0.1: not responding (recover done)
Sep 19 10:33:25 secondary dhcpd: DHCPDISCOVER from 00:19:99:95:41:99 via 10.12.0.1: not responding (recover done)
Sep 19 10:33:41 secondary dhcpd: DHCPDISCOVER from 00:19:99:95:41:99 via 10.12.0.1: not responding (recover done)
Sep 19 10:34:46 secondary dhcpd: DHCPDISCOVER from 00:1a:4b:45:3a:2f via 10.12.0.1: peer holds all free leases
Sep 19 10:34:51 secondary dhcpd: DHCPDISCOVER from 00:1a:4b:45:3a:2f via 10.12.0.1: peer holds all free leases
Sep 19 10:34:59 secondary dhcpd: DHCPDISCOVER from 00:1a:4b:45:3a:2f via 10.12.0.1: peer holds all free leases
Sep 19 10:35:16 secondary dhcpd: DHCPDISCOVER from 00:1a:4b:45:3a:2f via 10.12.0.1: peer holds all free leases
Sep 19 10:38:28 secondary dhcpd: DHCPDISCOVER from 00:16:d3:e5:3a:3c via 10.12.0.1: not responding (recover done)
Sep 19 10:38:32 secondary dhcpd: DHCPDISCOVER from 00:16:d3:e5:3a:3c via 10.12.0.1: not responding (recover done)

負荷分散ログ行がないようですので、リースバランシングが行われているとは思いません...

Sent update request all message to foo
Update request all from foo: sending update

バランシングプロセスは上記の2行で立ち往生しているようです

1つのサーバーでDHCPDデーモンをシャットダウンすると、他のピアがダウンしていることを検出しても、ピアが引き継ぐようには見えません。

この問題を解決するにはどうすればよいですか？

よろしくお願いします（そして私の悪い英語をお詫びします）:-)

linuxload-balancingdhcpfailover
1
PsyStyle

メッセージnot responding (recovering)は、サーバーがフェイルオーバー（または初期起動）から回復しているために応答していないことを示します。そして、おそらくまだプールからのすべての無料リースをリースデータベースに入力しています。これは、大きなプールがある場合は時間がかかる可能性があります。

小さいプールで試して、フェイルオーバーが正しく機能していることを確認してから、再調整してください。あなたの範囲は非常に大きく、おそらくそれが更新でハングしているように見える理由の原因です。

2
Steve Buzonas

私は以前にこの問題に遭遇しました。私にとっては、両方のサーバーのポート647/tcpをブロックするファイアウォールでした。各サーバーで以下を実行したところ、問題は解決しました。

firewall-cmd --add-port=647/tcp --permanent
firewall-cmd --reload

その後、dhcpdサービスを再起動します。

1
Zeke Uveges

エラーメッセージ_peer holds all free leases_は、リクエストが間違ったネットワークインターフェースで受信されたことを意味する場合もあります。コンピューターが_eth0_でIPを取得するように構成されているが、DHCP要求が_eth1_で受信された場合。 _deny dynamic bootp clients_は、このような設定では一般的です。私の場合、1つのインターフェイスはワークステーションネットワーク用で、もう1つはプリンタ専用で、誰かがワークステーションをプリンタネットワークに接続しました。

Debianでも エラーメッセージが表示され、明らかな理由が見つからなかったときのブログ投稿 を参照してください。

当時、メッセージnot responding (recovering)を見たのを覚えていませんが、両方のDHCPサーバーに_peer holds all free leases_もありました。

0
Axel Beckert