こんにちは、habrozhiteli。
私の愛する古い「サーバー」で電源が切れて正午にダウンタイムになった後、フェールオーバーDHCPについてもう一度考えました。
もちろん、今では多くの人がクラスターが支配していると言うでしょう。 クラスターの組織化が今や簡単になったという事実にさえ同意します。 SANや外部ハードドライブを購入する必要はありません。たとえば、構成済みのiSCSIコネクタを備えたFreeNAS上に構築された通常の米国は非常に適しています...しかし、
1.米国向けのプラットフォームがありません（その必要性もあります）。
2.クラスターをDHCPで排他的に上げることは望みませんが、他のニーズについてはまだクラスターは必要ありません。
MSDN（それがない場合）を見て、フォールトトレラントな構成を整理するためのソフトな方法によって提案された2番目の方法は、80/20の原則、つまり 最初のサーバーはワークスペースの80％を提供し、2番目のサーバーは残りの20％を提供します。 それは魅力的ですが、（すべてをポイントでリストするのが好きです）：
1.そのような組織は、DHCP機能の完全な使用を許可しません（たとえば、IPによるプロキシサーバーへのアクセスの制限）。
2. 2台のサーバーのメンテナンスが必要です。これには、より多くの工数が必要です。
3.帯域幅の使用率が高いネットワークでは、残りの20％がすべての顧客のニーズを満たすには不十分な場合があります。
さて、そして、結局のところ、「指で作られていない」のです。
だから私は自分自身に考え、「素晴らしい」考えを生み出しました。 しかし、DFSリソースを作成した場合、2つのサーバーをそのリソースに接続し、その上にDHCP構成ストレージを配置するとどうなりますか。 すぐに言ってやった。
仮想プラットフォーム上の2台のサーバーが発生し、ドメインが構成され、レプリケーションが構成され、リソースが作成され、2つのリンクサーバー間のリングレプリケーションが開始されました。 DHCPが発生し、適切なリソースに再構築されます。 Hooray、最初のサーバーは動作しています。 テストの時間です。
最初のサーバーを停止し、リソース間でデータが即座に複製され、2番目のサーバーに移動して、サービスを開始し、最初の熱狂を経験します。
仕事の半分が完了しました。 バックアップを停止し、最初のバックアップを開始し、新しい予約を作成して、メインサーバーを残酷にオフにします。 私たちは2番目に進み、サービスを開始し、最初の幸福感は「強い」と言わない限り、驚きに置き換えられます...
はい、DHCPは起動せず、オフになり、ログファイルとデータベースであらゆる可能な方法で誓います（MSDNを注意深く読む必要がありました。この問題はクラスターのセクションで説明されています）。
その結果 、バックアップ「サーバー」が作成され、その近くで起動するには半日実行する必要があります。 さらに、サービスが停止した後に発生した変更は完全になくなります。
しかし、怠idleな心はそこで止まりません。
ご存じのとおり、サーバーはタイムアウトによりデータベース全体のバックアップを作成します（デフォルトでは60分ごと）。したがって、バックアップフォルダーをDFSに移動できるのは「私は幸せです」だけです。
再構成には10分かかりました。 テスト-半日追加。
結果は再び嘆かわしい。 バックアップが行われ、DFSは利用可能なファイルを正直にバックアップサーバーに転送しますが、システムはそれらを構成ファイルに保持し続けます。
その結果 、DHCPはウィザードのクラッシュ後に起動できますが、すべての変更が反映されるわけではありません。 つまり 0をわずかに上回るパフォーマンス。
もちろん、解決策が見つかりました。 いつものように、バナル。
1時間ごとに、スクリプトはDHCPダンプをテキストファイルにエクスポートします。
netsh dhcp server 192.168.0.1 dump > C:\Dhcp\Dhcpcfg.dmp
ファイルはDFSボール上にあり（それがなくても、一緒に経験したすべての後に何らかの形で既に関連付けられていました）、両方のサーバー間で正常に複製されます。
時間Hで 、2番目のサーバーにダンプが単にインポートされます。
netsh exec dhcpcfg.dmp
サーバーの準備が整いました。
唯一のマイナスは、異なる言語のシステム上の異なるクラス名です。 ただし、ファイル内の通常の置換によって「硬化」されます。 さらに、私は同じ言語のシステムを持っているので、問題は通り過ぎました。
なんでこんなに...
はい、誰かがテストせずに自分のためにすべてを読んですぐに決定したように。
誰かが以前は理解していなかったいくつかのことを理解しました。
誰かがMSDNをより注意深く読み直しました。
そして、私たちは皆、否定的な結果も結果であると決めました。 貴重な経験が含まれています。
実際、MSDN。