Cisco Network Registrar ユーザー ガイド 7.0
DHCP フェールオーバーの構成
DHCP フェールオーバーの構成
発行日;2012/01/16 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 9MB) | フィードバック

目次

DHCP フェールオーバーの構成

フェールオーバーのシナリオ

基本フェールオーバー

バック オフィス フェールオーバー

対称フェールオーバー

フェールオーバーのチェックリスト

フェールオーバー サーバ ペアの作成と同期化

フェールオーバー ペアの追加

フェールオーバー ペアの同期化

フェールオーバー サーバの再起動

フェールオーバーの確認

統合時の状態の移行

詳細フェールオーバー アトリビュートの設定

バックアップ パーセンテージの設定

サーバとスコープのバックアップ パーセンテージ

BOOTP バックアップ パーセンテージ

バックアップ割り振り境界の設定

最大クライアント リード タイムの設定

フェールオーバー安全期間を使用したサーバの PARTNER-DOWN 状態への移行

DHCP 要求と応答パケット バッファの設定

ポーリング アトリビュートの変更

ネットワーク ディスカバリ アトリビュートの設定

ロード バランシングの設定

Network Registrar の以前のバージョンとのロード バランシングの互換性

ロード バランシングの設定

フェールオーバー サーバ ロールの変更

非フェールオーバー サーバをフェールオーバー メインとして設定

記憶域に障害があるサーバの交換

バックアップ サーバの削除とフェールオーバー操作の中止

既存のバックアップ サーバへのメイン サーバの追加

複数インターフェイスを持つホストでのフェールオーバーの構成

フェールオーバーでの BOOTP クライアントのサポート

スタティック BOOTP

ダイナミック BOOTP

BOOTP リレーの設定

DHCPLEASEQUERY およびフェールオーバー

フェールオーバーのトラブルシューティング

フェールオーバー操作の監視

ネットワーク障害の検出と処理

DHCP フェールオーバーの構成

DHCP フェールオーバーは、何らかの理由でメイン サーバが動作しない場合に、バックアップ DHCP サーバがメイン サーバを引き継ぐためのプロトコルです。

フェールオーバーのシナリオ

基本的なフェールオーバーのシナリオには、次の 3 つがあります。

基本フェールオーバー(推奨) :1 つのサーバがメイン、もう 1 つのサーバがバックアップとして動作します(「基本フェールオーバー」を参照)。

バック オフィス フェールオーバー :2 つのメイン サーバが、同一のバックアップ サーバを使用します(「バック オフィス フェールオーバー」を参照)。

対称フェールオーバー :2 つのサーバがメインであると同時に、互いのバックアップとして動作します(「対称フェールオーバー」を参照)。

基本フェールオーバー

基本フェールオーバーでは、1 つのメイン サーバと 1 つのバックアップ サーバから構成されるペアを使用します(図27-1を参照)。例では、サーバ A に 3 つのスコープがあり、バックアップ サーバ B にもまったく同様にスコープが構成されています。

図27-1 基本フェールオーバーの例

 

基本フェールオーバーが他のシナリオより優れているのは、次の点です。

ネットワークが変更されたときに最も管理しやすい。Web UI によって十分にサポートされているので、メイン サーバの構成への変更が、バックアップ サーバに自動的に伝搬されます。

パフォーマンスが最もよい。

追加のロード バランシング機能を有効にすると、バック オフィスまたは対称の各シナリオが不要になる(「ロード バランシングの設定」を参照)。

バック オフィス フェールオーバー

バック オフィス フェールオーバーでは、2 つ以上のメイン サーバが同じバックアップ サーバを共有します(図27-2を参照)。例では、メイン サーバ A および B にそれぞれ異なるスコープがあり、バックアップ サーバ C はこれらすべてのスコープを含む必要があります。このシナリオは、同じ LAN セグメント上のスコープであって、同一のメイン サーバとバックアップ サーバが必要であるが、別の LAN セグメントにもスコープがある場合に適切です。

図27-2 バック オフィス フェールオーバーの例

 

バック オフィス フェールオーバーが他のシナリオより優れている点は、管理が必要なサーバ数が少なくて済むことです。ただし、バック オフィス フェールオーバーには次の制約があるので、基本フェールオーバーを使用することをお勧めします。

バックアップ サーバには構成すべてを管理できるサイズが必要である。

メイン サーバに対して行った変更は、すべてバックアップ サーバに複製する必要がある。

より複雑になると、実際のアベイラビリティが著しく低下することがある。

対称フェールオーバー

対称フェールオーバーでは、2 つのサーバがメインであると同時に、互いのバックアップとして動作します(図27-3を参照)。サーバ間でスコープのアトリビュート値を同一にする必要があり、不一致があるとサーバ関係が正しく機能しないので、これは非常に扱いにくいシナリオです。

対称フェールオーバーは従来、サーバのロード バランシングの方法でしたが、現在は基本フェールオーバー シナリオでロード バランシング機能を使用して、より効率的に実行されます(「ロード バランシングの設定」を参照)。

残念ながら、対称フェールオーバーには、基本シナリオまたはバック オフィス シナリオを上回るパフォーマンス上の利点がほとんどありません。バックアップ サーバは、メイン サーバの 40% で動作してリース データベースの同期を維持します。サーバが互いをバックアップする場合、サーバの処理キャパシティの一部がこのタスクに使用されるので、クライアント要求の処理に利用できるキャパシティが小さくなります。さらに、対称フェールオーバーでは各スコープを個別に構成する必要があるので、構成エラーが起こりやすくなります。

図27-3 対称フェールオーバーの例

 

フェールオーバーのチェックリスト

このチェックリストを使用して、フェールオーバー構成を準備してください。

基本フェールオーバー シナリオ用にフェールオーバー サーバ ペアを構成することにより、パートナー サーバの、スコープ、ポリシー、DHCP オプション、およびアドレス設定を複製します。バックオフィス フェールオーバーまたは対称フェールオーバーのシナリオの場合には、サーバ ペア構成に対するネットワーク照合リストを変更して、ネットワーク アドレス、または正しいスコープを識別するアドレスをリストに含める必要があります。

メイン サーバがダウンした場合にその間バックアップ サーバがリースを提供できるよう、両方のパートナーに十分な広さのアドレス範囲を設定します。

次のオブジェクトは、両方のサーバ上で同じ構成にする必要があります。

スコープ

スコープ選択タグ

ポリシー

IP アドレス

予約

クライアント

クライアントクラス

ダイナミック DNS アップデート

ダイナミック BOOTP

バーチャル プライベート ネットワーク(VPN)

DHCP 拡張

LDAP を使用する場合、パートナー サーバから同一の LDAP サーバに転送します。

BOOTP リレー(IP ヘルパー)を使用する場合は、すべての BOOTP リレー エージェントが両方のパートナーをポイントするように設定します。Network Registrar は、この自動検出を行いません。ライブ テストを実行することによって、定期的にメイン サーバの稼働を停止して、DHCP クライアントに対してバックアップ サーバを使用できることを確認しますが、これを実行することによって検出できるのは BOOTP 設定エラーだけです。

フェールオーバー サーバ ペアの作成と同期化

フェールオーバー ペアは、メインとバックアップの DHCP サーバで構成されます。フェールオーバー ペアは、ローカル クラスタおよびリージョナル クラスタの Web UI で作成できます。メイン サーバとバックアップ サーバを同期化する必要があります。

フェールオーバー ペアの追加

最初に、クラスタのメイン サーバとバックアップ サーバに基づいて DHCP フェールオーバー ペアを作成します。次に、スコープ、ポリシー、クライアント、拡張、およびその他の DHCP プロパティがサーバ間で一致するようにフェールオーバー ペアを同期化します。

Web UI


ステップ 1 DHCP をクリックしてから Failover をクリックし、List DHCP Failover Pairs ページを開きます。

ステップ 2 Add DHCP Failover Pair をクリックします。

ステップ 3 Add DHCP Failover Pair ページで、フェールオーバー ペアの名前を追加します。名前は区別できればどのようなものでもよく、必須です。

ステップ 4 次の操作を実行します。

a. メイン DHCP サーバのクラスタを選択します。ローカルホストまたはユーザ定義のその他のクラスタを選択できます。ここで選択したものが、フェールオーバー ペアを追加したときの main-server アトリビュートの IP アドレス値になります。


) ローカル ホスト マシンの IP アドレスを変更する場合は、(Edit Cluster ページで)ローカルホスト クラスタを修正して、IP Address フィールドのアドレスを変更する必要があります。値を 127.0.0.1 に設定しないでください。


b. バックアップ DHCP サーバのクラスタを選択します。メイン サーバ クラスタと同じにできませんが、メイン クラスタがローカルホストでない場合はローカルホストにする必要があります。ここで選択したものが、フェールオーバー ペアを追加したときの backup-server アトリビュートの IP アドレス値になります。

c. フェールオーバー構成に含めるアドレス ブロックごとにそのブロックの IP アドレスとマスクを入力し、 Add Address Block をクリックします(「アドレス ブロックの追加」を参照)。

d. マルチホーム ホストがある場合を除いて、 main-server アトリビュートと backup-server アトリビュートの IP アドレス値を変更してはいけません。

e. さらに複雑なフェールオーバー シナリオが存在する場合には、設定が必要なプライマリ スコープ(またはプライマリ サブネットを持つセカンダリ スコープ)のサブネットを識別するネットワーク照合リストに、IP アドレスのリストを追加します。IP アドレスを追加してから、 Add Network Match をクリックします。

f. 最大クライアント リード タイム( mclt )やバックアップ パーセンテージ( backup-pct )など、追加のアトリビュートを設定できます。ほとんどのデフォルト値は、最適化されています。ペアのためにフェールオーバーを一時的にディセーブルにする場合以外は、 failover アトリビュートをデフォルトのイネーブルのままにしておきます。

ステップ 5 Add Failover Pair をクリックします。フェールオーバー ペアのプロパティを編集できます。


 

CLI コマンド

failover-pair name create main-server-address backup-server-address を使用します。サーバどうしを同期化する場合は、 main アトリビュートと backup アトリビュートを設定し、メイン クラスタとバックアップ クラスタも指定する必要があります。次に例を示します。

nrcmd> failover-pair example-fo-pair create 192.168.50.1 192.168.60.1 main=Example-cluster backup=Boston-cluster
 

failover-pair name addMatch [ vpn ] / ipaddr / mask を使用して、さらに複雑なフェールオーバーを設定します。追加するスコープを識別するサブネットの IP アドレスを指定します。一致するものごとに、このコマンドを使用します。 failover-pair name removeMatch [ vpn ] / ipaddr / mask コマンドを使用すると一致を削除でき、 failover-pair name listMatches コマンドを使用すると一致を一覧表示できます。また、フェールオーバー ペアの作成時に、照合リストを指定できます。次に例を示します。

nrcmd> failover-pair example-fo-pair create 192.168.50.1 192.168.60.1 main=Example-cluster backup=Boston-cluster addMatch 192.168.70.0/24
 

フェールオーバー ペアの同期化

フェールオーバー ペアを作成したら、次にサーバを同期化する必要があります。


ヒント Expert モードでは、List DHCP Failover Pairs ページに Resync CCM Failover Pairs ボタンがあります。


Web UI


ステップ 1 List DHCP Failover Pairs ページで Report アイコン( )をクリックして、Report Synchronize Failover Pair ページを開きます。

ステップ 2 メイン サーバのプロパティ値でどの程度バックアップ サーバのプロパティ値を置き換えるかによって、同期化操作を選択します。基本的な操作は次の 3 つです。

Update :これはデフォルトであると同時に、最も安全な操作です。バックアップ サーバの一意のプロパティに対する影響が最も少ないので、同期化のアップデートに適切です。

Complete :この操作は、すべての初期同期化の際に適切です。この操作では Update 操作よりも十分で、バック オフィス フェールオーバー構成に必要なプロパティなど、バックアップ サーバの一意のプロパティの多くが維持されます。

Exact :この操作は、基本フェールオーバーおよび対称フェールオーバーの初期の構成時に適していますが、バック オフィス構成には適していません。この操作では、2 つのサーバをできる限り互いのミラー イメージになるようにしますが、一意の DHCP サーバ、LDAP リモート サーバ、およびバックアップ サーバ上の拡張ポイントはそのまま維持されます。初期フェールオーバー構成では、Exact または Complete 操作を使用します。

それぞれの操作では、 表27-1 で説明するように、フェールオーバー プロパティに対してさまざまな機能の組み合せが実行されます。次の 4 つの機能があります。これらのプロパティと名前の値のペアに基づいて説明します。

メイン サーバ上 バックアップ サーバ上
Name1=A Name2=B
Name2=C Name3=D

no change :バックアップ サーバ上のプロパティや値のリストが変更されません。たとえば、結果は Name2=B、Name3=D となります。

ensure :バックアップ サーバ上に存在するメイン サーバ プロパティのコピーは保証されますが、値は置き換えられません。たとえば、結果は Name1=A、Name2=B、Name3=D となります。

replace :2 つのサーバが共通して持っているプロパティ値が、メイン サーバのプロパティ値と置き換えられます。たとえば、結果は Name1=A、Name2=C、Name3=D となります。

exact :メイン サーバのプロパティと値のリストの正確なコピーが、バックアップ サーバに保存され、一意のプロパティや値は削除されます。たとえば、結果は Name1=A、Name2=C となります。

 

表27-1 フェールオーバー ペアの同期化機能

データの説明
Update
Complete
Exact

DHCP サーバ(サーバ レベルのフェールオーバー ペア):

クライアントクラス プロパティ
クライアント ホスト名プロパティ
DNS アップデート プロパティ
フェールオーバー調整プロパティ
(フェールオーバーの同期化によって影響を受けるフェールオーバー ペア アトリビュートのリストについては、 表27-2 を参照)

replace

replace

replace

他のすべてのプロパティ

no change

replace

replace

LDAP リモート サーバ

ensure

replace

exact

ポリシー:

オプション リスト プロパティ
パケット ブート ファイル プロパティ
その他すべてのプロパティ

クライアント

replace

replace

exact

クライアントクラス

replace

replace

exact

スコープ(フェールオーバー ペアに関連付けられている)

exact

exact

exact

DNS アップデート設定

replace

replace

exact

トラップ設定

ensure

replace

exact

VPN

replace

replace

exact

キー

replace

replace

exact

拡張機能
(拡張ファイルをコピーする必要がある)

ensure

replace

exact

拡張ポイント

replace

replace

replace

オプション情報:

カスタム オプション リスト
ベンダー オプション リスト

ensure

replace

exact

 

表27-2 フェールオーバー同期化の影響を受けるフェールオーバー ペア アトリビュート

影響を受けるフェールオーバー ペアのアトリビュート

failover-bulking
failover-poll-interval
failover-poll-timeout
recover

ステップ 3 Run Synchronize Failover ページ上の Run 、または Report Synchronize Failover ページ上の Report をクリックします。

Run をクリックして接続が受け入れられた場合、View DHCP Failover Pair Sync Report ページに、どの変更エントリが同期化によって追加されたかが表示されます。

Report をクリックすると、同期化を実行した場合に、同期化によってどの変更エントリが追加されるかが、View DHCP Failover Pair Sync Report ページに表示されます。 Run Update Run Complete 、または Run Exact ボタンに、実行する同期化の種類が表示されます。適切なボタンをクリックして、同期化を実行します。

ステップ 4 List DHCP Failover Pairs ページで、Manage Servers カラム内の View アイコン( )をクリックし、Manage DHCP Failover Servers ページを開きます。

ステップ 5 バックアップ サーバの横の Reload アイコン( )をクリックしてバックアップ サーバをリロードします。

ステップ 6 リースの取得を試みます。

ステップ 7 Manage DHCP Failover Servers ページで、サーバの安定度を確認します( で表示されます)。また、Logs アイコン( )をクリックして、Log for Server ページにログ エントリを表示し、サーバが NORMAL フェールオーバー モードであることを確認します。ログ ファイルには、次のような項目があります。

06/19/2003 9:41:19 name/dhcp/1 Info Configuration 0 04092 Failover is enabled server-wide. Main server name: '192.168.0.1', backup server name: '192.168.0.110', mclt = 3600, backup-pct = 10, dynamic-bootp-backup-pct = 0, use-safe-period: disabled, safe-period = 0.
 


 

CLI コマンド

failover-pair name sync { update | complete | exact } を使用します。

nrcmd> failover-pair example-fo-pair sync exact
 

フェールオーバー サーバの再起動

フェールオーバー同期をすべて有効にするには、メインとバックアップの両方のフェールオーバー サーバに接続し、それらを再起動する必要があります。


ステップ 1 List Failover Pairs ページで、Main DHCP Server カラム内の Go Local アイコン( )をクリックします。

ステップ 2 メイン サーバの local Manage DHCP Server ページで、ページの右側にある Reload アイコン( )をクリックします。

ステップ 3 ページの右上にある Go Regional アイコン( )をクリックします。

ステップ 4 regional List Failover Pairs ページで、Backup DHCP Server カラム内の Go Local アイコン( )をクリックします。

ステップ 5 バックアップ サーバの local Manage DHCP Server ページで、ページの右側にある Reload アイコン( )をクリックします。

ステップ 6 ページの右上にある Go Regional アイコン( )をクリックします。


 

フェールオーバーの確認


ステップ 1 一方のサーバから他方のサーバに対して ping を実行して、TCP/IP 接続を確認します。クライアントを両方のサーバに転送するようにルータが設定されていることを確認します。

ステップ 2 サーバが NORMAL モードになっていることを確認します。これを行うには、DHCP Server ページまたは List DHCP Failover Pairs ページで Related Servers アイコン( )をクリックし、CLI では dhcp getRelatedServers を使用します。

ステップ 3 起動後、クライアントのリースの取得を試みます。

ステップ 4 メイン サーバ上で、少なくとも failover-detail が含まれるようにログ設定を行います。

ステップ 5 メイン サーバ上の name_dhcp_1_log ログ ファイル( install-path /logs)に、各サーバからの DHCPBNDACK または DHCPBNDUPD メッセージがあることを確認します。

ステップ 6 バックアップ サーバ上の name_dhcp_1_log ログ ファイルに、フェールオーバーが NORMAL 状態であるためバックアップ サーバが要求をドロップしていることを示すメッセージがあることを確認します。

ステップ 7 ステップ 2 を繰り返します。


 

統合時の状態の移行

通常の動作では、フェールオーバー パートナーは 1 つの状態から別の状態に移行します。それらのサーバは、すべてのアクションの状態遷移が完了するか、通信障害の場合は、次の状態が満たされるまで現在の状態を維持します。サーバがさまざまな状態になった場合に何が発生するか、および一定の状況下で、サーバどうしで互いに最初の統合とその後の再統合がどのように行われるかを、 表27-3 に示します。

 

表27-3 フェールオーバーの状態の移行と統合プロセス

統合
結果

NORMAL 状態に移行、最初にバックアップ サーバがメイン サーバと連絡したとき

1. 新しく構成されたバックアップ サーバがメイン サーバと連絡し、それによって PARTNER-DOWN 状態になります。

2. バックアップ サーバは新しいパートナーであるため、RECOVER 状態になり、Binding Request メッセージがメイン サーバに送信されます。

3. メイン サーバが Binding Update メッセージを応答します。このメッセージでは、リース状態データベースにリースがあります。

4. バックアップ サーバがこれらのメッセージを確認応答したら、メイン サーバが Binding Complete メッセージを応答します。

5. バックアップ サーバが RECOVER-DONE 状態になります。

6. 両方のサーバが NORMAL 状態になります。

7. バックアップ サーバが Pool Request メッセージを送信します。

8. メイン サーバはそれに対して、構成された backup-pct に基づき、リースをバックアップ サーバに割り振ります。

COMMUNICATIONS-
INTERRUPTED 状態の後

1. この状態でサーバがバックアップになりパートナーと接続されると、応答するサーバは同じ状態に移行した後すぐに NORMAL 状態に移行します。

2. パートナーも、NORMAL 状態に移行します。

PARTNER-DOWN 状態の後

この状態でサーバがバックアップになりパートナーと接続されると、サーバはそれ自体がダウンした時刻とパートナーがこの状態になった時刻を比較します。

サーバがダウンし、その後でパートナーがこの状態になったことをサーバが検出した場合:

a. 応答するサーバが RECOVER 状態に移行し、Update Request メッセージをパートナーに送信します。

b. パートナーは、以前送信できなかったすべてのバインディング データを返し、次いで Update Done メッセージを送信します。

c. 応答するサーバが RECOVER-DONE 状態に移行します。

d. 両方のサーバが NORMAL 状態に移行します。

パートナーが PARTNER-DOWN 状態になったときに、応答するサーバがまだ動作していたことを応答するサーバが検出した場合:

a. サーバが POTENTIAL-CONFLICT 状態に移行し、これによってパートナーもこの状態に移行します。

b. メイン サーバが、バックアップ サーバにアップデート要求を送信します。

c. バックアップ サーバが応答として、応答がないすべてのアップデートをメイン サーバに送信し、最後に Update Done メッセージを送信します。

d. メイン サーバが、NORMAL 状態に移行します。

e. バックアップ サーバが、応答のないすべてのアップデートを要求する Update Request メッセージをメイン サーバに送信します。

f. メイン サーバは、これらのアップデートを送信し、最後に Update Done メッセージを送信します。

g. バックアップ サーバが NORMAL 状態に移行します。

サーバがリース状態
データベースを失った後

応答するサーバは、通常、そのリース状態データベースを維持します。ただし、致命的な障害や意図的な削除によってそれが失われることがあります。

1. リース データベースを失ったサーバがパートナーとともに応答したときに、パートナーが PARTNER-DOWN または COMMUNICATIONS-INTERRUPTED の状態であると、サーバは、パートナーがこれまでサーバに通信したことがあるかどうかを判別します。通信したことがない場合は、データベースが失われたと判断して RECOVER 状態に移行し、Update Request All メッセージをパートナーに送信します。

2. パートナーは、そのデータベースにあるすべてのリースについてのバインディング データを返信し、続いて Update Done メッセージを送信します。

3. 応答するサーバは、最大クライアント リードタイム(MCLT)の間(通常 1 時間)待ち、RECOVER-DONE 状態に移行します。MCLT の詳細については、「最大クライアント リード タイムの設定」を参照してください。

4. 次に、両方のサーバが NORMAL 状態に移行します。

リース状態データベースのバックアップ復元後

応答するサーバがバックアップからそのリース状態データベースを復元し、追加のデータなしにそのパートナーと再接続する場合、そのサーバが要求するのは未知のリース バインディング データだけです。このデータは、予期したものと異なる場合があります。

1. この場合、応答するサーバの failover-recover アトリビュートを、バックアップが発生した時刻に設定します。

2. サーバは RECOVER 状態に移行するとともに、パートナーのすべてのデータを要求します。サーバは、バックアップが行われて RECOVER-DONE 状態に移行してから MCLT の時間(通常 1 時間)待ちます。MCLT の詳細については、「最大クライアント リード タイムの設定」を参照してください。

3. いったんサーバが NORMAL 状態に戻ったら、 failover-recover アトリビュートを設定解除するか、または 0 に設定する必要があります。

nrcmd> dhcp set failover-recover=0

動作中のサーバのフェールオーバーをディセーブルにした後

動作中のサーバのフェールオーバーを、イネーブル、ディセーブルの後、再度イネーブルにした場合は、新しく構成されたバックアップ サーバを動作させるときに特に注意が必要です。バックアップ サーバにはリース状態データは不要です。また
failover-recover
アトリビュートが、現在の時刻から MCLT 間隔(通常 1 時間)を引いた値に設定されている必要があります。MCLT の詳細については、「最大クライアント リード タイムの設定」を参照してください。

1. これにより、バックアップ サーバは、メイン サーバからすべてのリース状態データを要求できるようになります。この表の「サーバがリース状態データベースを失った後」の説明とは異なり、バックアップ サーバはこのデータを自動的に要求できません。これはメイン サーバとこれまでに通信をした記録が、バックアップ サーバに存在しないからです。

2. 再接続の後、バックアップ サーバは RECOVER 状態になり、メイン サーバのすべてのリース データを要求し、RECOVER-DONE 状態に移行します。

3. 両方のサーバが NORMAL 状態になります。この時点で、バックアップ サーバの failover-recover アトリビュートを設定解除するか、または 0 に設定する必要があります。

nrcmd> dhcp set failover-recover=0

詳細フェールオーバー アトリビュートの設定

設定が必要な詳細フェールオーバー プロパティは次のとおりです。

バックアップ パーセンテージ(「バックアップ パーセンテージの設定」を参照)

バックアップ割り振り境界(「バックアップ割り振り境界の設定」を参照)

最大クライアント リード タイム(MCLT)(「最大クライアント リード タイムの設定」を参照)

安全期間(「フェールオーバー安全期間を使用したサーバの PARTNER-DOWN 状態への移行」を参照)

要求パケットと応答パケットのバッファ(「DHCP 要求と応答パケット バッファの設定」を参照)

ポーリング アトリビュート(「ポーリング アトリビュートの変更」を参照)

ネットワーク ディスカバリ(「ネットワーク ディスカバリ アトリビュートの設定」を参照)

ロード バランシング(「ロード バランシングの設定」を参照)

バックアップ パーセンテージの設定

ネットワーク パーティション(両方のサーバがクライアントとは通信できても、互いに通信することができない)の場合でもフェールオーバー パートナー サーバの動作を維持するには、1 つのサーバで必要とする数より多いアドレスを割り振ります。各スコープ内の現在使用可能なアドレスのパーセンテージをバックアップ サーバに割り振るように、メイン サーバを構成する必要があります。その結果、これらのアドレスは、メイン サーバでは使用できなくなります。バックアップ サーバは、メイン サーバと連絡できず、それがダウンしているかどうかわからない場合に、これらのアドレスを使用します。


) Network Registrar フェールオーバー サーバが、6.0 より前の Network Registrar を実行する Network Registrar DHCP サーバからアップデートを受け取る場合、使用不可のリースはタイムアウト値を持ちません。この場合、Network Registrar 6.2 以降のサーバは、スコープ ポリシーまたは
system_default_policy
ポリシーに設定されている unavailable-timeout 値を使用不可のリースのタイムアウトとして使用します。リースがタイムアウトになると、そのポリシーにより、両方のフェールオーバー パートナーでそのリースが使用可能な状態に移行されます。


フェールオーバー ペアまたはスコープの backup-pct アトリビュートを設定することで(CLI では、 failover-pair name set backup-pct または scope name set backup-pct を使用)、現在使用可能なアドレスのパーセンテージを設定できます。フェールオーバー ペア レベルのバックアップ パーセンテージを設定すると、そのアトリビュートで設定されないすべてのスコープの値が設定されます。ただし、スコープ レベルで設定すると、バックアップ パーセンテージがフェールオーバー ペア レベルの設定を上書きします。フェールオーバー ペアの load-balancing アトリビュートがイネーブルの場合(CLI では、 failover-pair name enable load-balancing の場合)、バックアップ パーセンテージは 50% に固定され、(フェールオーバー ペアまたはスコープの)すべてのバックアップ パーセンテージ アトリビュートが無視されます(「Network Registrar の以前のバージョンとのロード バランシングの互換性」を参照)。

バックアップ パーセンテージは、メイン サーバで障害が発生した場合に、バックアップ サーバが新しいクライアントに対応できる大きさに設定する必要があります。バックアップ パーセンテージは、使用可能なアドレスをもとに計算されます。デフォルトのバックアップ パーセンテージは 10% です(ロード バランシングが有効でない場合に限り 50%)。ただし、停止時間が長いと予測される場合は、通常のリース活動でメイン サーバの使用可能なアドレス プールが事前定義のパーセンテージを下回った場合、メイン サーバが定期的(通常 1 時間ごと)にアドレスを解放するので、この値を十分大きな値に設定した方が安全です。たとえば、デフォルトの 10% のバックアップ パーセンテージでは、メイン サーバのアドレス プールが 90% を下回った場合にアドレスが解放されます。

パーセンテージは、新しいクライアントの到着率や、ネットワーク オペレータの反応時間によって異なります。バックアップ サーバでは、メイン サーバがダウンしているかどうかがわからない時間に到着する新しいクライアントすべての要求を満たすために、個々のスコープからの十分なアドレスが必要となります。バックアップ サーバは、PARTNER-DOWN 状態にある場合でも、リースを再割り振りする前に、最大クライアント リード タイム(MCLT)が経過し、リース時間が期限切れになるのを待ちます。「最大クライアント リード タイムの設定」を参照してください。これらの期間が終了すると、バックアップ サーバは次を実行します。

プライベート プールからリースを提供する。

メイン サーバのプールからリースを提供する。

期限が終了したリースを新しいクライアントに提供する。

日中であれば、メイン サーバが動作している場合、オペレータが 2 時間以内に COMMUNICATIONS-INTERRUPTED 状態に対応します。このときバックアップ サーバには、その 2 時間のうちに到着する新しいクライアントの適度な上限をサポートするのに十分なアドレスが必要です。

稼働時間外には、未知のクライアントの到着率が低くなることがあります。同じ状況に対して、オペレータは通常、12 時間以内に応答できます。このときバックアップ サーバには、その 12 時間のうちに到着するクライアントの適度な上限をサポートするのに十分なアドレスが必要です。

バックアップ サーバが単独で制御するために必要なアドレス数は、これら 2 つの数より大きくなります。この数は、各スコープで現在使用可能な(割り当てられていない)アドレスのパーセンテージとして表されます。クライアントクラスを使用する場合、一部のスコープしか使用できないクライアントもあることに注意してください。


) フェールオーバー時には、クライアントが取得するリースの期限が、設定より短いことがあります。これは、サーバ パートナーの同期を維持するためには正常です。通常、これは最初のリース期間または COMMUNICATIONS-INTERRUPTED 状態の場合にだけ発生します。


サーバとスコープのバックアップ パーセンテージ

フェールオーバーをイネーブルにしたすべてのサーバまたはスコープについて、 backup-pct アトリビュートを設定する必要があります。これは、現在使用可能な(予約解除されている)リースの値であり、メイン サーバのダウン時に、バックアップ サーバが新しい DHCP クライアントへの割り振りに使用できます。プリセット値(10%)を使用できます。または、他の値も指定できます。


) フェールオーバー ロード バランシングが有効な場合、メイン サーバとバックアップ サーバは、使用可能なリースを両者の間でアクティブに移動して、使用可能なリースのバックアップ パーセンテージを維持します。「ロード バランシングの設定」を参照してください。


BOOTP バックアップ パーセンテージ

ダイナミック BOOTP をイネーブルにしたスコープについては、 dynamic-bootp-backup-pct アトリビュートを使用し、フェールオーバー ペアの backup-pct アトリビュートは使用しません。 dynamic-bootp-backup-pct は、BOOTP クライアントとともに使用するために、メイン サーバがバックアップ サーバに送信する必要がある使用可能アドレスのパーセンテージです。

スコープ上で BOOTP をイネーブルにすると、サーバはたとえ PARTNER-DOWN 状態であっても、他のサーバによる利用が可能なアドレスのリースを許可しないので、 dynamic-bootp-backup-pct backup-pct アトリビュートとは区別する必要があります。Network Registrar がリースを割り当てないのは、パートナーがダイナミック BOOTP を使用してリースする可能性があるので、それらが再度使用可能になると安全に想定できないからです。


) ダイナミック BOOTP バックアップ パーセンテージは、メイン サーバ上で定義する必要があります。バックアップ サーバ上で定義すると、Network Registrar はそれを無視します(スクリプトによる構成の複製をイネーブルにするため)。これを定義しなければ、Network Registrar はデフォルトの backup-pct をフェールオーバー ペアまたはスコープに使用します。


フェールオーバー プロトコルを使用しながら、ダイナミック BOOTP を正しくサポートするには、BOOTP をサポートする必要があるすべての LAN セグメントで次の操作を行います。

ダイナミック BOOTP 用にスコープを 1 つ作成します。

BOOTP とダイナミック BOOTP をイネーブルにします。

そのスコープで DHCP をディセーブルにします。

バックアップ割り振り境界の設定

failover-backup-allocation-boundary アトリビュートをスコープに対して使用すると、バックアップ サーバに割り振るアドレスをより具体的に指定できます。この値として設定される IP アドレスは、バックアップ サーバに割り振られるアドレスの上限の境界となります。バックアップに割り振られるのは、この境界より下のアドレスだけです。この境界より下に使用可能なアドレスが存在せず、それより上にアドレスが存在する場合は、それより上のアドレスがバックアップに割り振られます。実際の割り振りはこのアドレスより下側で機能し、DHCP クライアントの通常の割り振りはスコープの最も下のアドレスよりも上側で機能します。

スコープに対して failover-backup-allocation-boundary を設定する場合は、 allocate-first-available アトリビュートもイネーブルにする必要があります。 failover-backup-allocation-boundary が設定されていないか、0 に設定されている場合、使用される境界は、スコープ範囲の最初と最後のアドレスの中間になります。この境界より下に使用可能なアドレスが存在しない場合は、使用可能な最初のアドレスが使用されます。

最大クライアント リード タイムの設定

フェールオーバーのプロパティ、最大クライアント リード タイム(MCLT)を設定すると、リース期間を調整できます。MCLT は、サーバ間の不確実な接続の潜在的な期間についての調整を行います。これは、サーバが、最初にパートナーと長い時間を交渉しなくてもクライアントにリースを割り当てられる(または延長できる)最大時間です。この時間は、次の意味を持ちます。

MCLT の長さのリースだけをクライアントが最初に(または、パートナーが通信していない場合に)受け取る可能性があります。これは、クライアントが、フェールオーバーを使用しない場合の更新よりも早期にリースを更新する必要があることを意味します。この更新時に、クライアントは(パートナーが通信していない場合を除いて)全リース時間を取得する必要があります。

サーバが PARTNER-DOWN 状態になると、サーバがすべてのリースを取得するには、ダウン時間の後、MCLT だけ待つ必要があります。

フェールオーバー復元が発生し、一方のパートナーが何をしたか(リース データベースをいつ失ったかなど)が不明な場合、通常のフェールオーバー操作を再開するには、両方のパートナーは同期の後、MCLT 期間だけリース アクティビティを制限する必要があります。

デフォルトの MCLT は 1 時間で、ほとんどの構成ではこの値が最適です。フェールオーバー プロトコルによって定義されているように、クライアントに与えられるリース期間は、フェールオーバー パートナーから最後に受け取った潜在的な期限の時刻または現在の時刻のどちらか遅い方に MCLT を加えた期限を超えることはできません。初期リース期間が 1 時間だけであったり、予期した更新時より 1 時間長かったりするのはこのためです。実際のリース時間は、メイン サーバが復帰した時点で再計算されます。

フェールオーバーでは緩やかな更新を使用するので、MCLT が必要になります。緩やかな更新では、サーバはそのパートナーをアップデートする前にリースをクライアントに発行したり、クライアントのリースを更新したりでき、その後バッチでアップデートできます。サーバがダウンしてリース情報をパートナーに通信できない場合、パートナーが期限について最後に認識した期限に基づいて、別のクライアントにリースを提供し直すことを試みる場合があります。MCLT によって、クライアントが更新する機会のウィンドウが追加されることが保証されます。MCLT とともに動作してリースを提供し更新する方法は、次のとおりです。

1. クライアントはサーバに DHCPDISCOVER を送信し、必要なリース期間(たとえば 3 日間)を要求します。サーバは応答として DHCPOFFER と MCLT(デフォルトでは 1 時間のみ)の初期リース期間を返します。次にクライアントは、MCLT リース期間を要求し、サーバがこれに対して確認応答をします。

2. サーバがそのパートナーに対し、クライアントのリース期限として現在の時刻に MCLT を加算した期限が入ったバインド アップデートを送信します。またアップデートには、潜在的な期限の時刻として、現在の時刻とクライアントが要求した期間に MCLT を加えた期限(3 日と 1 時間)もあります。パートナーがこの潜在的な期限に確認応答することによって、トランザクションが保証されます。

3. リースの半分(30 分)が経過したところでクライアントが更新要求を送信すると、サーバはクライアントの要求するリース期間(3 日間)に対して確認応答を返します。さらにサーバはそのパートナーに対し、リース期限を現在の時刻に要求されたリース期間(3 日間)を加えた期限に、潜在的な期限を現在の時刻に要求された期間および現在の期間の残りの半分を加えた期限(3 + 1.5 = 4.5 日間)にアップデートします。パートナーが、この 4.5 日という潜在的な期限に対して確認応答を返します。この方法により、メイン サーバは、そのパートナーがクライアントのリース期間について常にクライアントよりも先に認識し、クライアントに常に提供できるように試みます。

MCLT には 1 つの正しい値というものはありません。さまざまな要因の間で明確なトレードオフがあり、その中から 1 つの値を選択することになります。ほとんどはプリセット値の 1 時間が効果的に使用されており、ほとんどすべての環境でこの値が適切に機能します。MCLT を短く設定した場合と長く設定した場合のトレードオフについて、いくつか紹介します。

短い MCLT :MCLT 値を短く設定すると、PARTNER-DOWN 状態に移行してから、サーバがパートナーの IP アドレスを DHCP クライアントに割り振り始める時間が短くなります。さらに、リースの期限が満了してから、サーバがそのアドレスを他の DHCP クライアントに再割り振りするまでの時間が短くなります。ただし、欠点として、短い MCLT 時間の半分が経過したところで DHCP クライアントが最初の更新を送信する必要があるので、すべての新しい DHCP クライアントに提供される初期リース間隔が短くなるとトラフィックが増加します。また、サーバが COMMUNICATIONS-INTERRUPTED 状態になってから要求されたクライアント リース期間の間に、COMMUNICATIONS-INTERRUPTED 状態のサーバが与えられるリース拡張は MCLT だけです。サーバが長時間その状態である場合は、サーバが提供するリースが短いために、そのサーバへの負荷が増大し、問題が発生することがあります。

長い MCLT :MCLT の値を長くすると、初期リース期間が長くなり、
COMMUNICATIONS-INTERRUPTED 状態のサーバが(要求されるクライアント リース期間の間その状態でいた後)リースを延長できるまでの時間が長くなります。ただし、PARTNER-DOWN 状態に移行するサーバが、そのパートナーのアドレスを新しい DHCP クライアントに割り振れるようになるまでの MCLT 時間も長くなります。したがって、この時間に対応するために、追加のアドレスが必要になることがあります。また、PARTNER-DOWN 状態のサーバは、リースの期限が満了してから、アドレスを別の DHCP クライアントに割り振れるようになるまでの MCLT も長くなります。

フェールオーバー安全期間を使用したサーバの PARTNER-DOWN 状態への移行

一方または両方のフェールオーバー パートナーを COMMUNICATIONS-INTERRUPTED 状態に移行することもできます。都合のいいことに、サーバはこの状態で重複するアドレスを発行することはできません。ただし、この状態ではサーバができる動作に制限があるので、サーバを長期間この状態にしておくことは好ましくありません。メイン サーバは期限満了のリースを再割り振りできないので、バックアップ サーバがそのプールのアドレスを使い切ってしまう可能性があります。COMMUNICATIONS-INTERRUPTED 状態は、数分から数日の間、サーバが一時的な通信障害に容易に耐えられるようにするための状態です。サーバは短時間であれば、クライアントの発着率によっては、この状態で十分に機能することがあります。その後は、サーバが再度同期化するまでの間、リース機能を完全に引き継げるように、サーバを PARTNER-DOWN 状態に移行してください。

サーバを PARTNER-DOWN 状態に移行するには、次の 2 つの方法があります。

ユーザ操作 :管理者が、現状を正確に評価した上で、サーバを PARTNER-DOWN 状態に設定します。フェールオーバー プロトコルがこれを正しく処理します。両方のパートナーを PARTNER-DOWN モードに設定しないでください。

フェールオーバー安全期間の期限満了 :サーバを長期間無人で実行する場合、サーバが自動的に PARTNER-DOWN 状態に移行するための方法が必要です。

サーバがダウンしたり通信不能になったりしたときに、ネットワーク オペレータがそれに気付かない可能性もあります。したがって、フェールオーバー安全期間を設定することによって、サーバが COMMUNICATIONS-INTERRUPTED 状態に移行する際に、ネットワーク オペレータに対応する時間の余裕ができます。安全期間中は、唯一の要件は、両方のサーバがなお動作中であるとオペレータが判別することです。動作中であれば、ネットワーク通信障害を修正するか、安全期間が終わる前にいずれかのサーバを停止します。

安全期間中は、既存のクライアントからの更新を既存のいずれかのサーバが受け付けますが、これは重複したアドレスが発行されるという大きなリスクがあります。これは、一方のサーバが突然 PARTNER-DOWN 状態になっても、他方がそのまま動作し続けることがあるからです。このようなリスクがあるので、フェールオーバー安全期間は、デフォルトではディセーブルです。このため、サーバ障害時に、重複するアドレスを受け取るリスクよりもアドレスの取得が重要な場合にだけ、安全期間をイネーブルにするのが最も適切です。

安全期間の長さはインストールに固有であり、プール内に割り振られていないアドレスの数や、アドレスを要求する、予期される未知のクライアントの到着率に依存します。安全期間は通常、24 時間ですが、多くの環境では数日間の期間をサポートできます。

安全期間に必要となる追加のアドレス数は、サーバに到着すると予期される新しいクライアントの数と同じです。この数は、未処理のリースの合計ではなく、新しいクライアントの到着率に依存します。アドレス不足または新しいクライアントの到着率が高いために、短い安全期間だけが設定できる場合でも、1 時間で修正可能な小さな問題に DHCP が耐えられるようにすることにより、大きな利点が得られます。重複したアドレスが割り振られる可能性は最小に抑えられ、障害解決後の再統合は自動なのでオペレータの介入は必要ありません。

PARTNER-DOWN 状態への移行のために手動介入を使用するか、安全期間を使用するかを決定するためのガイドラインを次に示します。

手動介入は極力避けるという企業ポリシーがある場合は、安全期間を設定します。安全期間をイネーブルにするには、フェールオーバー ペア アトリビュート use-safe-period をイネーブルにします。次に、DHCP アトリビュート safe-period を設定して期限(デフォルトは 86400 秒、つまり 24 時間)を設定します。この期限は、オペレータが通信障害の原因を探り、パートナーが本当にダウンしていることを確信できる十分な長さに設定します。最低 12 時間を推奨します。

どのような状況下でも競合を避けるという企業ポリシーがある場合は、明示的なコマンドによる場合を除き、バックアップ サーバが PARTNER-DOWN 状態にならないようにします。管理者がカバーしないときに期間中の新しいクライアントの到着に対応できるよう、バックアップ サーバに十分な数のアドレスを割り振ります。リージョナル クラスタ Web UI の View Failover Related Server ページで PARTNER-DOWN を設定でき、パートナーが Communications-interrupted フェールオーバー状態になっている場合は、 Set Partner Down をクリックして入力フィールドを使用し、PARTNER-DOWN の日付を設定できます。この設定は、 start-of-communications-
interrupted
アトリビュートの値に初期化されます(Normal Web UI モードでは、この日付を初期化された日付より前の値に設定することはできません。Expert Web UI モードでは、任意の日付を設定できます)。 Set Partner Down をクリックした後、List Related Servers for DHCP Server ページに戻り、PARTNER-DOWN アクションの結果を表示します。両方のパートナーを PARTNER-DOWN モードに設定しないでください。

CLI で dhcp setPartnerDown を使用して、パートナー サーバの名前を指定します。この操作により、パートナーとのフェールオーバーを実行するすべてのスコープが、即座に PARTNER-DOWN 状態に移行します。この日付と時刻は、パートナーの動作が最後に確認された日付と時刻です。

日付の指定には、次の 2 つの表記法があります。

- num unit :(過去の時間)。 num は 10 進数で、 unit s m h d 、または w で、それぞれ秒、分、時間、日、または週を示します。たとえば、3 日の場合は「-3d」と指定します。

月(月名または最初の 3 文字)、日、時刻(24 時間制)、年(4 桁表示または最後の 2 桁のみ表示)。次の例では、バックアップ サーバに対し、そのメイン サーバが 2002 年 10 月 31 日の深夜の 12 時にダウンしたことを通知します。

nrcmd> server dhcp setPartnerDown dhcp2.example.com. -3d
nrcmd> server dhcp setPartnerDown dhcp2.example.com. Oct 31 00:00:00 2001
nrcmd> dhcp reload
 

) CLI で日付と時刻を指定するときは、必ず nrcmd プロセスにローカルな時刻を入力する必要があります。サーバがこのプロセスと異なる時間帯で動作している場合、サーバが動作している場所の時間帯は無視して、このプロセスの現地時間を使用します。


DHCP 要求と応答パケット バッファの設定

要求バッファの数( max-dhcp-requests DHCP アトリビュートで設定)により、サーバが受け取ることのできる同時要求の最大数が設定されます。デフォルト値は 500 で、これはほとんどの展開に適していますが、サーバのキャパシティに合せることができます。このキャパシティは、リース トランザクションのリース レートと平均レイテンシに関係しています。たとえば、クライアントが 250 ミリ秒ごとに新しいリースを受け取る場合、サーバが 1 秒間に 2000 のクライアントに応答するには、500 の要求バッファ値で十分です(このレートでクライアントを処理するための十分な処理キャパシティがある場合)。値を小さくすると、サーバのパフォーマンスがこのキャパシティ以下に制限されます。値を大きくすると、再試行なしに多くのクライアントを負荷のバースト期間中に処理できますが、クライアントごとの平均レイテンシが大きくなります。平均レイテンシが 2 秒以下であれば、クライアントを適切に処理するために十分です。

max-dhcp-responses DHCP アトリビュートを使用して設定する)応答バッファの数により、サーバがクライアント応答を発行することで完了できる同時要求の最大数が設定されます。ネットワークが安定した状態で動作している場合、応答は受け取った要求の数と一致すると予想されます。同じ応答バッファ プールがリースとフェールオーバーの両方のアクティビティに使用されるので、フェールオーバーがイネーブルの場合、サーバは応答バッファの値を調整して、少なくとも要求バッファの 4 倍にします。この設定により、保留中のすべてのクライアントとフェールオーバーのアクティビティを同時に処理するために十分なリソースが確保されます。

ポーリング アトリビュートの変更

たとえば、メイン サーバがバックアップ サーバに送信する必要があるリースの数や MCLT など、いくつかのシステム デフォルトが変更できます。「最大クライアント リード タイムの設定」を参照してください。ただし、変更は両方のサーバで行う必要があります。

各サーバで次の操作を行います。

ポーリング間隔(DHCP アトリビュート failover-poll-interval) を変更します。これは、パートナーが互いに連絡を取り合って、ネットワーク接続を確認する間隔です。プリセット値は 10 秒です。

ポーリング タイムアウト(DHCP アトリビュート failover-poll-timeout) を変更します。フェールオーバー パートナーは、このタイムアウト期間中に通信が成立しない場合、ネットワーク接続が失われたという結論を出して、適切な動作状態に変更します。プリセット値は 60 秒です。

一般に、 failover-poll-timeout は変更する必要がありません。この数値は failover-poll-interval と密接にリンクされており、実社会での経験に基づいて設定されています。フェールオーバー ロード バランシングのため、バックアップ サーバは、メイン サーバがダウンしたことを検出するまで( failover-poll-timeout 期間後)、メイン サーバに対するクライアントからの要求を受け取っても、すべて破棄します。


) フェールオーバー ペアのサブネット使用状況履歴を収集するには、基本フェールオーバーを設定している場合は、メインとバックアップの各 DHCP サーバの個々のポーリングをディセーブルにし、フェールオーバー ペア アトリビュート poll-subnet-util-interval を設定することで、フェールオーバー ペアのポーリングをイネーブルにして、両方のサーバから 1 セットのデータを収集できるようにします。


ネットワーク ディスカバリ アトリビュートの設定

UNIX システムでフェールオーバーをイネーブルにする場合、 sms-network-discovery アトリビュートを設定すると、リースされたアドレスについてクライアントの os-type の計算をイネーブルにできます。これは、Windows のパートナー サーバを持ち、そのサーバ上の CLI で dhcp updateSms を使用する必要がある場合に役立ちます。

ロード バランシングの設定

通常のフェールオーバー モードでは、フェールオーバー パートナーが通常の通信モードのときに、メイン DHCP サーバがクライアント処理のほとんどの負荷を受け持ちます。メイン サーバは、新しいすべてのクライアント要求を処理するだけでなく、バックアップ パートナーからの更新要求、再バインド要求、および期限満了リースも処理する必要があります。基本フェールオーバー構成シナリオにおいて 2 つのサーバ間で負荷をより均等に分散できるよう、Network Registrar では(RFC 3074 に基づく)ロード バランシング機能が導入されました。

フェールオーバー ロード バランシングにより、両方のサーバが、クライアントをアクティブに処理したり、同じクライアントを両方で処理する危険性なしに、各サーバがどの固有のクライアントを処理するかを決定することができます。フェールオーバー ロード バランシングは、サーバが NORMAL 状態になっている場合だけ適用されます。他の状態では、両方のサーバがクライアントに応答できます。RFC 3074 に準じて、サーバは、クライアントの識別子オプション値またはハードウェア アドレスに基づき、サーバが受信する各要求のハッシュ値を計算し、要求は、ハッシュ値がそのサーバに割り当てられている場合に処理されます。フェールオーバー ロード バランシングがイネーブルになっている場合、両サーバはクライアントの負荷を均等に分割します(メイン サーバがハッシュ値の 50% を処理し、バックアップ サーバが残りの 50% を処理します)。

ロード バランシングを使用すると、NORMAL 通信状態でない場合、各パートナーはすべてのクライアントに応答します。この通信状態のときは、割り当てられたハッシュ値内にあるクライアントからのブロードキャスト DHCPDISCOVER メッセージにだけ応答します。ブロードキャスト DHCPDISCOVER に対して、そのサーバが(サーバ識別子オプションに基づく)ターゲット サーバである場合だけ、サーバは応答します。したがって、ターゲット サーバがメイン サーバで、ダウンしている場合、バックアップ サーバは、クライアントにサービスを行いません(リースを解放していない場合)。ブロードキャスト BOOTP および DHCPINFORM 要求にも、ロード バランシングが適用されます。

Network Registrar の以前のバージョンとのロード バランシングの互換性

フェールオーバー ロード バランシングは、Network Registrar の以前のリリースとの互換性を保証するため、デフォルトではディセーブルになっています。使用されるのは、両方のサーバがロード バランシングをサポートする場合だけです。したがって、フェールオーバー ペアのロード バランシングは未設定で、明示的にイネーブルにするまでデフォルト値のディセーブルが適用されます。ロード バランシングをイネーブルにした場合、各サーバがクライアントを約 50% ずつ処理し、バックアップに与えられるフリー リースは、設定したパーセンテージに関係なく 50% になります(「バックアップ パーセンテージの設定」を参照)。

ロード バランシングの設定

Web UI では、ペアのフェールオーバー プロパティを設定するときに(「フェールオーバー サーバ ペアの作成と同期化」を参照)、フェールオーバー設定アトリビュートの load-balancing アトリビュートを必要に応じてイネーブルまたはディセーブルにすることで、フェールオーバー ロード バランシングをイネーブルまたはディセーブルにします。CLI では、 failover-pair name set load-balancing を使用します。

フェールオーバー サーバ ロールの変更


注意 フェールオーバー サーバのロールを変更するときには注意してください。スコープを構成から除いてリロードすると、サーバから、スコープ内のアドレス状態がすべて失われます。

非フェールオーバー サーバをフェールオーバー メインとして設定

既存のインストールをアップデートし、提供される DHCP サービスのアベイラビリティを高めます。次の手順は、元のサーバがフェールオーバーに参加していない場合にだけ使用できます。


ステップ 1 元のサーバに Network Registrar をインストールし、インストール後、正しく動作することを確認します。

ステップ 2 バックアップ サーバとなるマシンに、Network Registrar をインストールします。マシンの DNS 名を書きとめておきます。

ステップ 3 元のサーバでフェールオーバーをイネーブルにします。最後にインストールしたバックアップ サーバの DNS 名を使用します。「基本フェールオーバー」を参照してください。

ステップ 4 メイン サーバをリロードします。メイン サーバが PARTNER-DOWN 状態になります。メイン サーバはまだ構成されていないので、バックアップ サーバを検索できません。この時点では、メイン サーバの操作に変更はありません。

ステップ 5 バックアップ サーバ上のメイン サーバの構成、つまり、スコープ(セカンダリを含む)、ポリシー、クライアントクラスなどを複製します。クライアントクラスを使用している場合、クライアントが各クラスタに入れられることや、各サーバがクライアント データを使用して LDAP データベースにアクセスできることを確認します。

ステップ 6 バックアップ サーバで、フェールオーバーをイネーブルにします。必ずメイン サーバを定義してください。

ステップ 7 ブロードキャスト パケットが、メイン サーバとバックアップ サーバに転送されるように、動作している BOOTP リレーをすべて再構成します。

ステップ 8 バックアップ サーバをリロードします。


 

これらのステップを完了すると、次の動作が行われます。

1. バックアップ サーバがメイン サーバを検出し、RECOVER 状態に移行します。

2. バックアップ サーバは、メイン サーバのリース データが入った安定した記憶域をリフレッシュし、完了すると RECOVER-DONE 状態に移行します。

3. メイン サーバが、NORMAL 状態に移行します。

4. バックアップ サーバが NORMAL 状態に移行します。

5. バックアップ サーバは、プール要求を使用して、通信が中断した場合に割り振るアドレスをメイン サーバに求めます。

6. メイン サーバは、これらのアドレスを割り振った後、このデータをバックアップ サーバに送信します。

記憶域に障害があるサーバの交換

フェールオーバー サーバが安定した記憶域(ハードディスク)を失った場合、サーバを交換し、交換したサーバにパートナーから提供される状態情報を回復します。


ステップ 1 どのサーバが安定した記憶域を失っているのかを判別します。

ステップ 2 CLI で dhcp setPartnerDown を使用し、パートナーがダウンしたことを相手方のサーバに通知します。時刻を指定しない場合は、現在の時刻が使用されます。

ステップ 3 サーバが再び稼働したら、Network Registrar を再インストールします。

ステップ 4 サーバの設定をパートナーから複製します。ただし、リース データベースは、以前のバックアップまたはパートナーのシステムから復元しないでください。

ステップ 5 交換したサーバをリロードします。


 

これらのステップを完了すると、次の動作が行われます。

1. 回復したサーバが RECOVER 状態に移行します。

2. パートナーがすべてのデータを回復したサーバに送信します。

3. サーバは、最大クライアント リード タイム(および failover-recover に設定した時刻)に達すると、RECOVER-DONE 状態に移行します。

4. パートナーが、NORMAL 状態に移行します。

5. 回復したサーバが NORMAL 状態に移行します。回復したサーバはアドレスを要求できますが、以前に割り振られたアドレスはすべてパートナーによってすでに送信されているため、新しいアドレスが割り振られることはほとんどありません。

バックアップ サーバの削除とフェールオーバー操作の中止

バックアップ サーバを削除し、すべてのフェールオーバー操作を中止することが必要になる場合があります。


ステップ 1 バックアップ サーバで、メイン サーバのバックアップとして指定されたすべてのスコープを削除します。

ステップ 2 メイン サーバで、バックアップ サーバのメインであったスコープからフェールオーバー機能を削除します。または、サーバ全体で構成されていた場合は、サーバ全体でフェールオーバーをディセーブルにします。

ステップ 3 両方のサーバをリロードします。


 

既存のバックアップ サーバへのメイン サーバの追加

既存のバックアップ サーバをメイン サーバ用に使用できます。


ステップ 1 メイン サーバのスコープ、ポリシー、およびその他の設定をバックアップ サーバに複製します。

ステップ 2 メイン サーバでフェールオーバーをイネーブルにし、バックアップ サーバをポイントします。

ステップ 3 新しいメイン サーバをポイントする新しいスコープに対してフェールオーバーをイネーブルにするよう、バックアップ サーバを構成します。

ステップ 4 両方のサーバをリロードします。Network Registrar が、「非フェールオーバー サーバをフェールオーバー メインとして設定」で説明されている手順を実行します。


 

複数インターフェイスを持つホストでのフェールオーバーの構成

複数のインターフェイスを持つサーバ ホストでフェールオーバーを使用する予定がある場合は、ローカル サーバの名前またはアドレスを明示的に構成する必要があります。これには、追加のコマンドが必要です。たとえば、serverA と serverB の 2 つのインターフェイスを持つ 1 つのホストがあり、serverA をメインのフェールオーバー サーバにする場合、バックアップ サーバのサーバ名(external serverB)を設定する前に、serverA を failover-main-server として定義する必要があります。このようにしないと、フェールオーバーが正しく初期化されない可能性があり、フェールオーバーで間違ったインターフェイスの使用が試みられます。

DHCP サーバのプロパティを failover-main-server failover-backup-server に設定します。

1 つのホスト上に複数のインターフェイスがある場合、1 つのアドレスまたは A レコードだけをポイントするホスト名を指定する必要があります。サーバにラウンドロビンのサポートを設定することはできません。

フェールオーバーでの BOOTP クライアントのサポート

BOOTP クライアントは、スタティックとダイナミックの 2 つのタイプがサポートできます。

スタティック BOOTP

スタティック BOOTP クライアントは、DHCP 予約を使用してサポートできます。フェールオーバーをイネーブルにする場合は、メインとバックアップの両方のサーバに、同じ予約を設定する必要があります。

ダイナミック BOOTP

ダイナミック BOOTP クライアントをイネーブルにするには、スコープ上で dynamic-bootp アトリビュートをイネーブルにします。ただし、フェールオーバーを使用すると、BOOTP クライアントが、期限の切れない永久アドレスや永久リースを取得するので、そのスコープでのアドレス使用についてさらに制約が加わります。

dynamic-bootp オプションがイネーブルでないスコープを持つサーバは、PARTNER-DOWN 状態に移行すると、そのスコープからの使用可能な(割り当てられていない)アドレスを、それが当初パートナーが使用できたかどうかにかかわらず割り振ることができます。ただし、 dynamic-bootp オプションが設定されている場合は、各パートナーはそれ自体のアドレスしか割り振ることができません。したがって、 dynamic-bootp オプションをイネーブルにすると、フェールオーバーをサポートするためにより多くのアドレスが必要になります。

ダイナミック BOOTP を使用する場合は、次の設定を行います。

ダイナミック BOOTP クライアントを 1 つのスコープに分離します。そのスコープで dhcp アトリビュートをディセーブルにして、DHCP クライアントがそのスコープを使用できないようにします。

このスコープで、バックアップ サーバに割り振るアドレスのパーセンテージが通常のバックアップ パーセンテージより 50% 高くなるように、 dynamic-bootp-backup-pct フェールオーバー ペア アトリビュートを設定します。

BOOTP リレーの設定

Network Registrar フェールオーバー プロトコルは、BOOTP リレー(IP ヘルパーとも呼ばれます)という、サーバにローカルに接続されていない DHCP クライアントをサポートするルータ機能と連携して動作します。

BOOTP リレーを使用する場合は、メインとバックアップの両方のサーバをポイントするように実装されているかを確認します。そうでない場合は、メイン サーバがダウンすると、バックアップ サーバが必要なパケットを認識できないので、クライアントが処理されません。BOOTP リレーがブロードキャスト パケットを 2 つの異なるサーバに転送するように設定できない場合は、ルータを設定して、メインとバックアップの両方のサーバを含めることのできる LAN セグメントのサブネットローカル ブロードキャスト アドレスにパケットを転送します。次に、メインとバックアップの両方のサーバが同じ LAN セグメントにあることを確認します。

DHCPLEASEQUERY およびフェールオーバー

マスター サーバがダウンしたときに、DHCPLEASEQUERY メッセージが DHCP フェールオーバー バックアップ サーバに送信されるように対応するには、マスター サーバが relay-agent-info (82) オプション値をパートナー サーバに通信する必要があります。これを実現するために、マスター サーバは、DHCP フェールオーバー アップデート メッセージを使用します。

フェールオーバーのトラブルシューティング

この項ではフェールオーバー構成の誤りを回避する方法や、フェールオーバー操作の監視方法、およびネットワークの問題を検出、処理する方法について説明します。

フェールオーバー操作の監視

両方のパートナー サーバで DHCP サーバのログ ファイルを調べて、フェールオーバー構成を確認します。

フェールオーバーのトラブルシューティングを行うための、ログとデバッグの重要な設定がいくつかあります。DHCP ログ設定を failover-detail に設定します。これは、記録されるフェールオーバー メッセージの数と詳細です。前のメッセージが上書きされないようにするには、 failover-detail アトリビュートをリストの最後に追加します。サーバのフェールオーバー競合を記録しない場合は no-failover-conflict アトリビュートを、正常なサーバ フェールオーバー アクティビティを記録しない場合は no-failover-activity アトリビュートを使用します。次に、サーバをリロードします。

設定の誤りをより簡単に特定することもできます。これを行うには、Manage DHCP Server ページまたは List DHCP Failover Pairs ページで Related Servers アイコン( )をクリックします。CLI の場合は、 dhcp getRelatedServers を使用します。

ネットワーク障害の検出と処理

表27-4 に、フェールオーバーの問題について、症状、原因、および解決策を説明します。

 

表27-4 障害の検出と処理

症状
原因
解決策

新しいクライアントがアドレスを取得できない。

バックアップ サーバが COMMUNICATIONS-INTERRUPTED 状態になっているために、アドレスが不足しています。

メイン サーバのバックアップ パーセンテージを大きくします。

スコープが不一致だというエラーメッセージが表示される。

パートナー間で、スコープ構成の不一致があります。

サーバを再構成します。

パートナーと通信できないというログ メッセージが表示される。

サーバが、もう一方のサーバと通信できません。

サーバのステータスをチェックします。

メイン サーバで障害が発生する。一部のクライアントで、リースの更新や再バインドができない。バックアップ サーバが動作していてクライアント要求を一部処理できる場合に、リースが期限満了になる。

一部の BOOTP リレー(IP ヘルパー)が、両方のサーバをポイントするように設定されていません。「BOOTP リレーの設定」を参照してください。

メインとバックアップの両方のサーバをポイントするよう、BOOTP リレーを再構成します。

ファイア ドリル テストを実行します。メイン サーバを 1 日程度停止して、ユーザ コミュニティがリースを取得および更新できるかを確認します。

SNMP トラップ:他のサーバが応答しない。

サーバが、もう一方のサーバと通信できません。

サーバのステータスをチェックします。

SNMP トラップ:dhcp フェールオーバー構成が不一致。

パートナー間でスコープ構成が不一致です。

サーバを再構成します。

思ったとおりにサービスやシステムが使えないとユーザから苦情が来る。

パートナー間でポリシーやクライアントクラスが不一致です。

パートナー関係にあるサーバのポリシーが同じになるように再構成します。また現在クライアントをパートナーに直接登録している場合は、できるだけクライアント登録用の LDAP を使用します。