ローカルクラスタの DHCP の考慮事項
-
1 台のサーバにいくつのリースを設定できますか。
-
サーバに n 個のリースを配置する場合、どのようなサーバを購入する必要がありますか、または仮想マシンを設定する必要がありますか。
単一サーバで許可されるリースの数
サーバのキャパシティについて説明する場合、サーバがサポートできる 1 秒あたりの DHCP 操作の数が最も重要な問題です。サーバがサポートする必要がある 1 秒あたりの操作に影響する 2 つの条件があります。
-
安定状態:リースを更新する既存の DHCP クライアントと、以前はサーバで認識されていなかった DHCP クライアントの到着で構成されます。
-
アバランシェ:多数の(場合によっては膨大な)既存の DHCP クライアントで構成され、すべて DHCP サーバでアドレスを取得するために競合します。この状況は、障害後の電源復旧や、多くのお客様のデバイスの一括リセットで発生する可能性があります。これは多くの場合、DHCP サーバから同時に IP アドレスを取得しようとする何万もの DHCP クライアントで構成されます。IP アドレスを取得しようとする何十万もの DHCP クライアントが存在することもあります。
安定状態では、DHCP クライアントの数とクライアントに付与されるリースのリース時間が負荷の大半を占めます。
DHCP クライアント群に必要な 1 秒あたりの操作は、その群に付与されるリース時間(有効期限と更新時間の両方)に加えて、そのクライアント群のサイズによって大きく左右されます。これらの値はすべて設定可能であるため、実際の要件は大幅に異なる場合があります。
次の表に、さまざまなクライアント群と異なるリース時間に必要な 1 秒あたりの操作数を表すこれらのデータポイントの範囲を示します。
1 秒あたりの操作 | ||||||
---|---|---|---|---|---|---|
クライアントのリース時間 | ||||||
アクティブなリース |
30 分 |
1 時間 |
1 日 |
1 週間 |
2 週間 |
30日間 |
1,000 |
1 |
1 |
- |
- |
- |
- |
10,000 |
11 |
6 |
- |
- |
- |
- |
100,000 |
111 |
72 |
2 |
- |
- |
- |
500, 000 |
556 |
278 |
12 |
2 |
1 |
- |
1,000,000 |
1,111 |
556 |
23 |
4 |
2 |
1 |
1,500,000 |
1,667 |
833 |
35 |
5 |
2 |
1 |
2,000,000 |
2,222 |
1,111 |
46 |
7 |
3 |
2 |
4,000,000 |
4,444 |
2,222 |
93 |
13 |
7 |
3 |
6,000,000 |
6,667 |
3,333 |
139 |
20 |
10 |
5 |
クライアントに付与されるリース時間は、DHCP サーバで必要な 1 秒あたりの安定状態操作に大きな影響を与えます。既存のリースを持たないクライアントのリース時間はフェールオーバーの最大クライアントリードタイム(MCLT)によって制限され、他の操作(「不良」クライアントやリースクエリ要求など)がある場合もあるため、サーバの操作にはリース時間が混在する可能性があります。
DHCP サーバは、クライアントに負荷がかかるどのような状態でも崩壊しませんが、数万または数十万のクライアントを処理するのに数秒から数分かかることがあります。このため、安定状態でサーバがサポートする必要がある 1 秒あたりの操作に関する推奨事項は、サーバが最終的なアバランシェを処理するための十分な余裕を持てるように、低い数値になる傾向があります。
1 秒あたりの DHCP 操作
DHCP サーバのパフォーマンスのこの側面には多くの要因が関係しているため、DHCP サーバが DHCP クライアントに提供できる 1 秒あたりの操作に関する具体的な推奨事項を提示することは困難です。
シスコがラボで DHCP サーバのパフォーマンスを測定したところ、1 秒あたりの操作は 20,000 回をはるかに超えています。ただし、これは最大のパフォーマンス(フェールオーバーなし、ロギングなし、リース履歴なし、拡張なし、LDAP なし)のために特別に設定された DHCP サーバでした。DHCP サーバで設定するほとんどすべての機能は、ある程度のパフォーマンスの低下を生じさせます。多くの場合は、以前のパフォーマンスよりも 10% 程度減少します。たとえば、LDAP ルックアップやプライム ケーブル プロビジョニング(PCP)製品での実行などの一部の機能は、パフォーマンスに大きく影響する可能性があります。 LDAP ルックアップまたは DPE との PCP インタラクションには、着信 DHCP 要求を処理する前に、別のサーバとのインターロックとそれに伴うラウンドトリップ遅延を必要とするためです。フェールオーバーには少なくとも 10% のコストがかかります。基本的なロギングには、パフォーマンスの 10% 以上のコストがかかることもあります。拡張には、単に拡張機能を呼び出すための一定のオーバーヘッドに加えて、予測不能なコストがかかります。拡張に費やされる時間も、すべての DHCP 要求の処理にかかる時間に同期して加算されます。
これらすべての結果として、特定のソフトウェア構成で特定のハードウェア構成を実行している場合に、特定の負荷に対して DHCP サーバが提供できる 1 秒あたりの操作を合理的に予測する方法がなくなります。
また、DHCP クライアントからの DHCP RENEW 要求を処理するための一定の要件(「安定状態」)によって、DHCP サーバにかかる 1 秒あたりの操作の負荷は、数千から数万までの DHCP クライアントが短時間で DHCP サーバからサービスを取得しようとする、大規模な「アバランシェ」負荷を処理するための要件によって影がうすくなることがよくあります。これらのイベントは、DHCP クライアント間での停電またはネットワーク要素のリセットによって生成され、何千もの DHCP クライアントが IP アドレスの再検出や再送信要求を行うように誘導します。DHCP サーバは、これらの負荷を処理できる必要があります。通常は、安定状態の RENEWAL トラフィックによって生成される負荷を軽減します。
異常な状況で DHCP サーバに提供されるアバランシェ負荷を処理するためのヘッドルームを確保するためにも、シスコは DHCP サーバの安定状態の負荷を 1 秒あたり数百の操作に制限することを推奨します。高性能のハードウェアと優れた監視体制を備え、1 秒あたり数百の操作、場合によっては一定の負荷でそれ以上の操作を実行するお客様もいます。これらは、各サーバのアクティブリースの数を制限することで、アバランシェ負荷のサイズが大きくなりすぎないように注意していることもあり、正常に実行されています。
DHCP サーバには、サーバの負荷を軽減し、特にアバランシェ状態の場合に、可能な限り迅速に要求に対応できるようにするいくつかの機能があります。
-
リース延長の延期
デフォルトでは、クライアントが予想される更新時期よりも前にクライアントが「更新」した場合、サーバはクライアントへのリースの延長を保留します。これは、多数のクライアントがディスク書き込み(およびフェールオーバー更新)の必要性を回避するため、通常、それがトリガーされた停止が短かった(リース時間の 1/2 未満)場合に、アバランシェで役立ちます。
-
過負荷時のロギングの削減
デフォルトでは、使用中の要求バッファが設定されたバッファの 67% を超えると、サーバはロギングを削減します。ロギングは高コストになる可能性があるため、非常にビジーな場合にサーバが追加のキャパシティを処理できるようにします。この機能は無効にできます。サーバが負荷を軽減できる唯一の方法であり、クライアントが要求を再送信するため、アバランシェ状態でサーバが要求をドロップすることが予期されることに注意してください。安定している状態でサーバが頻繁に要求をドロップする場合は、負荷を処理できないことを示していると考えられます。
-
おしゃべりクライアントフィルタ
すべてのサービス プロバイダー ネットワークで、この提供された拡張機能を使用することを強く推奨します。この拡張機能は、クライアントのアクティビティを監視し、「おしゃべり」と見なされるクライアントをブロックします。一旦ブロックされたクライアントが沈静化すると、ブロックが解除されます。多くのサービス プロバイダー ネットワークでは、おしゃべりクライアントフィルタによってサーバへの要求を約 50% 削減できます。ただし、おしゃべりクライアントフィルタは慎重に調整する必要があり、トラフィックパターンが変更されていないことを確認するために定期的に調整を見直す必要があります。詳細については、『Cisco Prime Network Registrar 11.0 DHCP ユーザーガイド』の「拡張機能を使用したおしゃべりクライアントの防止(Preventing Chatty Clients by Using an Extension)」の項を参照してください。
-
識別レートリミッタ
識別レートリミッタは、すべての RENEW 要求を受け入れながら、DISCOVER 要求と SOLICIT 要求のレートを制限することで、サービスネットワークの停止後のダウンタイムを短縮します。基本的な概念は、リースを提供されたクライアントがそのリースの取得を完了できることを保証することです。詳細については、『Cisco Prime Network Registrar 11.0 DHCP ユーザーガイド』の「DHCP サーバの詳細属性の設定(Setting Advanced DHCP Server Attributes)」の項を参照してください。
サーバで必要なリースの数
負荷が 1 秒あたりの安定状態の操作だけである場合は、上記の表を見て、1 週間のリース時間で、1,200 万または 2,400 万のリースで問題が発生しないことを想像できます。ただし、他にも次のような要因があります。
-
アバランシェ負荷:サーバのリースの合計数に応じて増減する場合があります。
-
リロード時間:サーバは、リロードされるたびにインメモリキャッシュを更新する必要があります。リロード時間は、サーバ内のアクティブリースの数に比例します。
-
サービス中断の影響:最初に数百万のリースがある場合は、DHCP クライアントと何らかの顧客との間に関係がある可能性があります。DHCP フェールオーバーペア全体のサービスが数時間停止すると、ビジネスに許容できないリスクが生じる可能性があるため、通常は DHCP サーバに多数のリースが存在しないようにする必要があります。DHCP フェールオーバーはほとんどすべてのサービスの中断を防ぎ、シングルポイント障害がない可能性がありますが、同時に 2 つの障害が発生することもあります。DHCP フェールオーバーペアの両方のサーバでしばらくの間、障害が発生する可能性があります。万が一、これが発生した場合は、1 台のサーバに 200 万台の DHCP クライアントが存在するか、1 台のサーバに 1,000 万台の DHCP クライアントが存在するかの違いが非常に重要になる可能性があります。適度な DHCP リース時間では、フェールオーバーペアがサービスを停止する時間ごとにリースが使用不可になるのは、DHCP クライアントのごくわずかな割合です。
推奨事項
単一の DHCP サーバ(またはサーバフェールオーバーペア)のアクティブリースの合計数を 600 万に制限することを強く推奨します。さらに、アバランシェやその他の例外的な状態を処理するのに十分な帯域幅を確保するために、安定状態における 1 秒あたりの操作の要件を 1 秒あたり 500 操作に制限することを強く推奨します。
ある時点を超えて、スケールアップではなくスケールアウトします。
1 つの DHCP サーバまたはフェールオーバーペアに膨大な数のリースをロードする代わりに、リース数を適度な数(たとえば、300 万から 500 万)に抑えることを検討してください。シスコのリソース制限により、警告レベルは 600 万リースに設定されており、将来の増加に対応するために、サーバあたり 400 万リース以上のように設定することをお勧めします。複数のフェールオーバーペアを管理することは、1 つのフェールオーバーペアを管理するよりも手間がかかりますが、300 万リースから 400 万リースが適度にロードされたサーバの管理が容易なことは、長期的な利益をもたらします。サーバペア全体に数時間障害が発生するという万が一の事態には、当然ながらビジネスに影響を及ぼします。
要求遅延
DHCP サーバの設計は、多数の要求に迅速に応答するように最適化されており、各要求の遅延が最小になるように最適化されているわけではないことに注意してください。これは、いくつかの同時要求によるサーバのパフォーマンスが実際の処理能力を示していない可能性があるため、スケールのテストを複雑にすることがよくあります。
サーバに関する考慮事項
多くの操作を必要とせず、サーバのリース数も少ない場合、どのようなサーバ構成でも可能です。この説明では、可能な限り最大のパフォーマンスを得ることを想定しています。
-
ディスク書き込みのパフォーマンスは、主な考慮事項です。SAN ストレージまたは SSD ディスクが推奨されます。DHCP サーバは、クライアントに応答する前に、リースの変更(主に新しいクライアントへのリースの割り当てとリース時間の延長)をディスクにコミットする必要があるため、ディスク書き込みパフォーマンスが制限されます。フェールオーバー、リース履歴、DNS 更新などの構成オプションも、追加の書き込み操作を必要とするため、サーバのディスク書き込み負荷が増加します。サーバ上のリースに対して、リースを許可、延長(更新と再バインド)、リリース、または期限切れにする書き込みが最大 4 回あり、さらに次のようにフェールオーバーパートナーで 1 回の書き込みがあります。 -
リース自体(クライアントに応答する前)。一般に、フェールオーバーが使用されている場合は、フェールオーバーバインドも更新されます。
-
履歴レコード(リース履歴が有効で、リースされていたが、もはやリースが終了した場合にのみ発生)。
-
フェールオーバーバインド更新を受信すると、パートナーはリースを書き込みます(フェールオーバーが使用されている場合)。
-
フェールオーバーバインド更新の確認応答の受信後のリース(フェールオーバーが使用されている場合)。
-
DNS 更新が完了した後のリース(リース用に設定および開始された場合)。
サーバは、リースのフェールオーバー状態の移行、フェールオーバープールのバランシング時、およびユーザアクションによる影響(たとえば、リースを強制的に使用可能にする場合)など、リースの別の時点で書き込みを開始することもあります。DHCP サーバのリース状態データベースのディスク容量要件は、一般に次のとおりです。
-
設定済みリースまたはアクティブリースごとに 1 KB。
-
リース履歴が有効な場合、履歴レコードごとに 1 KB。
リースレコードの圧縮が有効になっている場合、これらの数値は約 30% 削減できます(DHCP サーバの server-flags 属性を参照)。
(注)
シャドウバックアップに対応するには、これらの数値に 3 を掛ける必要があります。これらの数値は、リース状態データベースを反映するだけで、その他のシステム要件はありません。
-
-
メモリ(RAM)はセカンダリであり、64 ビットをサポートしているため、システムに十分なメモリがあれば、メモリ制限は一般には問題になりません。ディスクの読み取りの必要性を回避するためには、DHCP リース状態データベース全体をメモリに保持できるように、ファイルシステムには十分な「空き」メモリを確保することが重要です。大まかな経験則では、次のように仮定します。 -
DHCP サーバのメモリ使用量に対して、設定済みリースまたはアクティブリースごとに 1 KB。DNS アップデート、ホスト名とドメイン名の長さ、オプション 82(DHCPv4)またはリレー転送メッセージ(DHCPv6)データの量などの構成オプションは、この経験則に影響を与える可能性があります。
-
各リース(設定済みまたはアクティブ)のファイルシステムキャッシュ用に 1 KB の「空き」メモリ。
-
リース履歴が有効になっている場合は、各履歴レコードのファイルシステムキャッシュ用に 1 KB の「空き」メモリ(リースの期限切れまたはリリースの頻度に応じて判断が困難になります)。
-
-
要求を処理するために必要な処理が全般に低下するため、CPU パフォーマンスへの影響は最も低くなります。一方、アバランシェ処理は、主に CPU サイクルと最小限のディスク書き込みで処理されます。そのため、大規模なアバランシェの可能性がある場合は、優れた CPU 能力と高速なネットワークインターフェイスを備えたシステムに投資してください。最新のマルチプロセッサシステムのほとんどは、中程度のアバランシェ負荷に対して十分です。キャパシティとパフォーマンスの高いアプリケーションでは、CPU 速度と有効なプロセッサの数の両方を高くする必要があります。DHCP サーバは高度にマルチスレッド化されているため、追加の CPU コアによって DHCP サーバのパフォーマンスがある程度向上します。DHCP サーバ内のロックの最小限の要件により、最大 12 個の CPU コアを追加するとパフォーマンスが向上します。CPU コアが 12 個を超えると、同期の要件によるパフォーマンスの向上はほとんどありません。