データセンターのDHCP
誰かがデータセンターにDHCPを導入することの短所と長所を提供できますか？
これは通常タブーであることを私は知っていますが、おそらく上記の問題を軽減する開発があったのでしょうか？
ありがとう。
私は反対票を投じます。私の理由を列挙させてください。
1：信頼性。
ネットワークスタックを正しく起動するために各サーバーマシンをdhcpに依存させると、別の潜在的な障害が追加されます。最大の可用性を実現するために可能な限り努力しているサーバー環境では、別の可動部分を追加することはお勧めできません。
2：セキュリティ
DHCPは基本的に、スイッチに接続しているすべての人に有効なリースを渡します。はい、既知のMACのみがリースを取得し、他のすべてのMACが拒否されるように指定できますが、これには動的VLANが適しています。
3：ドキュメント
アドレスをwilly-nillyに割り当てる中央DHCPプールを持つことは、サーバーブロックにとって非常識です。 DHCPを介してサーバーに特定のIPを割り当てることは、3頭の想像上のピンクの象があなたを追いかけているという意味で、5頭よりも狂気ではありません。
4：管理
DHCPサーバーで各マシンの割り当て先を指定する必要があるだけでなく、そのドキュメントを保持する必要があります。また、何かが変更されるたびに、すべてのドキュメントを更新する必要があります。新しいネットワークカード？ドキュメントとDHCPサーバーおよびDNSなどを更新します。
シンプルな方がいいです。
一般的に言って、予約付きのDHCPは、データセンターの特定のニーズに応じて（もちろん）、データセンターでのIP管理に「最適」です。
長所：
- 予約付きのDHCPを使用すると、アドレス空間を一元管理できます。管理者が名前空間（DNS）を参照しなくても、アドレス空間を参照および編集できる単一の場所。これは、管理者がネットワーク層での職務を自然に「分割」する場合に特に便利です。
- DHCPは、アドレス空間で正しいIPを使用してリソースを動的に割り当てる機能を提供できます。再インストールされたサーバーは、相談なしですぐに正しいIPを思い付きます。
- 動的割り当ては、自動化がシステムインストールの大部分を処理する迅速なサーバー展開に特に適しています。
短所：
- DHCPプロバイダーは、ネットワークアクセスを妨げる可能性のある障害点です。 （dhcpクライアントのタイムアウトを下げるのを忘れると特に厄介です。）
- ネットワーク設計では、DHCPブロードキャストトラフィックを考慮する必要があります。これにより、ルーティングが複雑になり、ネットワークアクセスに別のレベルの潜在的な障害が発生する可能性があります。
- DNSとDHCPを別々に管理することは、一部の人にとっては煩わしいと考えられています。
- DHCPの割り当てに失敗すると、169ネットワークが作成される可能性があるため、ファイアウォールとルーターを適切に準備する必要があります。
いくつかのブレンドが適切ですが、予約なしでデータセンターでDHCPを実行することが賢明なことはめったにありません。多くの設定では、予約付きのDHCPの「短所」は問題になりません（ルーターがDHCPを取得できる場合は、サーバーにアクセスできないなど）。また、一般的にサイズに関する決定でもあります。頻繁に展開および再インストールされる数百または数千のサーバーを備えたデータセンターは、テスト/展開専用であっても、確かにDHCPを使用します。サーバーが数台あるデータセンターは、すべてが静的に割り当てられていれば問題ないでしょう。
データセンターでDHCPを実行しない場合のonly例外は次のとおりです。
[〜＃〜]専用[〜＃〜]ビルドVLAN）でのDHCPにより、新しいサーバーをラックに入れてイメージを作成した後、PXEブートできます。
他のすべての人がすでによく指摘しているように、データセンターでDHCPを実行する正当な理由は他にありません。
個人的には、共有アドレス空間を使用している場合、データセンターではDHCPで問題ないと思います。 DHCPは、実際には動的アドレスである必要があるという意味ではありません。それらは修正できます。
DHCPが常に利用可能であるように冗長DHCPサーバー（DHCPフェイルオーバー）を提供する限り、問題はないはずです。
人々は、スイッチポートを自動選択速度とデュプレックスのままにするのは悪い考えだと思っていましたが、今では、そのようなスイッチの構成に時間を費やしている人は誰も知りません。
なぜ人々はデータセンターのDHCPについてそれほど心配しているのですか？
- DHCPにより管理が容易になります
- 少なくともMSの世界では、DHCPは非常に信頼性があります
- 心配な場合は、DHCPサーバー上の唯一のワークロードであることを確認してください
- リースがどのように機能するかを理解します。 DHCPサーバーがダウンしていることは災害ではなく、クライアント（サーバーを含む）は引き続き機能します
- MS DHCPを高可用性にする方法はいくつかあり、MSによって文書化され、サポートされています。
- 予約を使用し、一般的にサーバーのワークロードに動的に割り当てられたアドレスを持たせたくないことに同意します
- DHCP、DDNS、およびActiveDirectoryはすべてうまく結合します
- これらのトピックは、主にここの他の投稿でカバーされています
- ここや他のフォーラムでのこの議論には多くの感情があるようです。どうして？ 「正しい」または「間違っている」のどちらでもなく、ハイブリッドソリューションでも使用できます。インフラストラクチャのサイズ、変更の量、組織の運用の成熟度、リスクに対する欲求または嫌悪感、サービスレベル、スタッフのレベルなどはすべて、これらの要素に影響します。
免責事項-私はデータセンターにDHCPを実装しており、インフラストラクチャマネージャーのときは問題はありませんでしたが、現在は多くの顧客のコンサルタントとしてそれを行いません。それはすべて依存します..。
以下はMSからコピーされたものです。これをよく考えて、データセンターのDHCPについてそれほど心配する理由を考えてください。
クライアントがDHCPサーバーからアドレス割り当てを受信する場合、DHCPサーバーのダウンタイムによってクライアントがどのように影響を受けるかを予測できることが重要です。一般に、リース期間が長いほど、DHCPのダウンタイムが短いままの場合の影響は少なくなります。たとえば、クライアントのリース期間がデフォルトの8日に設定されている場合、クライアントはこの期間の50％（4日）が経過するまでリースの更新を試みません。この時点で元のDHCPサーバーが使用できない場合、クライアントはリース期間（7日）の87.5％までこのリースされたアドレスを使用し続け、その後DHCPサーバーで更新を試みます。クライアントが4日後に更新を試みると、DHCPサーバーが2日間使用できなくなったとしても、クライアントは87.5％の再バインド状態に到達しません。したがって、通常、リース期間の25％以内の停止について心配する必要はありません。同様に、リース時間が短いほど、DHCPサーバーの回復に使用できる時間が短くなります。
えーと...データセンターの隣のオフィスにいるクライアントPCに適しています...
...必要に応じてプリンタも...
...しかし、いいえ、それでもサーバー、少なくとも本番サーバーにとっては悪い考えです-おそらく私が推測する開発/テスト環境で、または他に選択肢がない場合はVPSにとって。