DHCP für Rechenzentrum


7

Kann jemand Vor- und Nachteile für DHCP in einem Rechenzentrum bieten?

Ich weiß, dass dies normalerweise ein Tabu ist, aber vielleicht gab es Entwicklungen, die die genannten Probleme lindern?

Vielen Dank.

Antworten:


16

Ich stimme nein. Gestatten Sie mir, meine Gründe aufzuzählen.

1: Zuverlässigkeit.
Wenn jeder Server auf DHCP angewiesen ist, damit sein Netzwerkstapel korrekt angezeigt wird, wird ein weiterer potenzieller Fehler hinzugefügt. In einer Serverumgebung, in der Sie so viel wie möglich versuchen, maximale Verfügbarkeit zu erreichen, ist das Hinzufügen eines weiteren beweglichen Teils keine gute Idee

2: Sicherheits-
DHCP übergibt im Wesentlichen jedem, der an den Switch angeschlossen ist, eine gültige Lease. Ja, Sie können angeben, dass nur bekannte MACs Leases erhalten und alle anderen abgelehnt werden. Ein besserer Ort dafür sind jedoch dynamische VLANs.

3: Dokumentation
Ein zentraler DHCP-Pool, der Adressen wohl oder übel zuweist, ist für einen Serverblock verrückt. Das Zuweisen einer bestimmten IP-Adresse zu einem Server über DHCP ist weniger verrückt, da 3 imaginäre rosa Elefanten, die Sie verfolgen, weniger verrückt sind als 5.

4: Verwaltung
Sie müssen nicht nur auf dem DHCP-Server angeben, wem jeder Computer zugewiesen ist, sondern auch eine Dokumentation darüber führen. Und Sie müssen die gesamte Dokumentation aktualisieren, wenn sich etwas ändert. Neue Netzwerkkarte? Aktualisieren Sie die Dokumentation und den DHCP-Server sowie DNS usw.

Einfach ist besser.


1
+1 Pink Elephans hat mich lol
Zypher

Vielen Dank für die ausführliche Begründung. Nur eine Frage - bieten die DHCP-Reservierungen einen Wert? Oder ist es im Wesentlichen dasselbe wie eine statische IP-Zuweisung mit der zusätzlichen Belastung durch die Verwaltung von MAC-Adressen?
SyRenity

Wenn Ihr DHCP-Server ordnungsgemäß konfiguriert ist UND funktioniert, entspricht er praktisch statischen IP-Adressen. Warum sollte jedoch eine weitere Dienstabhängigkeit hinzugefügt werden? Hochverfügbarkeit DHCP hört man nicht oft ...
Matt Simmons

2
Ich denke, es ist erwähnenswert, dass Ihre Gründe, DHCP nicht zu verwenden, nicht immer so stark sind, wie sie erscheinen. 1) In Bezug auf die Zuverlässigkeit ist DHCP eine der zuverlässigsten Protokoll- / Serverimplementierungen. Probleme mit DHCP sind in der Regel Netzwerkprobleme, bei denen Server ohnehin offline geschaltet werden. 2) Sie können DHCP so konfigurieren, dass es absolut sicher ist. Dies ist ein Strohmann. 3) Die DHCP-Konfiguration ist eine hervorragende Dokumentation. 4) Das gleiche, die Konfiguration ist die Dokumentation.
Travis Bradshaw

Auch in Bezug auf (4) Management. Sie können "DHCP-Server" durch "lokal auf jedem Server" ersetzen, ohne die Bedeutung zu ändern.
Travis Bradshaw

14

Im Allgemeinen ist DHCP mit Vorbehalten das "Best of Breed" für die IP-Verwaltung im Rechenzentrum, abhängig von den besonderen Anforderungen Ihres Rechenzentrums.

Vorteile:

  • DHCP mit Reservierungen ermöglicht die zentrale Verwaltung Ihres Adressraums. Ein einziger Ort, an dem Administratoren auf Ihren Adressraum verweisen und ihn bearbeiten können, ohne unbedingt auf den Namespace (DNS) verweisen zu müssen. Dies ist besonders dann von Vorteil, wenn Ihre Administratoren die Aufgaben auf Netzwerkebene auf natürliche Weise "aufteilen".
  • DHCP bietet die Möglichkeit, Ressourcen mit der richtigen IP im Adressraum dynamisch zuzuweisen. Ein neu installierter Server liefert sofort ohne Rücksprache die richtige IP.
  • Die dynamische Zuweisung eignet sich besonders für die schnelle Serverbereitstellung, bei der die Automatisierung den Großteil der Systeminstallation übernimmt.

Nachteile:

  • DHCP-Anbieter weisen einen Fehlerpunkt auf, der den Netzwerkzugriff verhindern kann. (Es ist besonders unangenehm, wenn man vergisst, die Zeit für den DHCP-Client zu verkürzen.)
  • Das Netzwerkdesign muss den DHCP-Broadcast-Verkehr berücksichtigen. Dies kann das Routing erschweren und eine weitere potenzielle Fehlerstufe für den Netzwerkzugriff darstellen.
  • Die getrennte Verwaltung von DNS und DHCP wird von einigen als lästig angesehen.
  • Eine fehlgeschlagene DHCP-Zuweisung kann dazu führen, dass das Netzwerk erstellt wird. Firewalls und Router sollten entsprechend vorbereitet sein.

Sehr selten ist es ratsam, DHCP in einem Rechenzentrum ohne Vorbehalte auszuführen, obwohl eine Mischung angemessen ist. In vielen Einstellungen sind die "Nachteile" für DHCP mit Reservierungen kein Problem (wenn der Router DHCP entfernen kann, sind die Server sowieso nicht zugänglich usw.). Es ist auch häufig eine Entscheidung bezüglich der Größe. Ein Rechenzentrum mit Hunderten oder Tausenden von Servern mit häufigen Bereitstellungen und Neuinstallationen wird sicherlich etwas DHCP verwenden, selbst wenn es nur zum Testen / Bereitstellen dient. Ein Rechenzentrum mit einigen Servern kann wahrscheinlich alles statisch zuweisen.


Was ist mit der Verwaltung von MAC-Adressen, führt dies nicht zu einer weiteren Belastung?
SyRenity

Nun, es hängt davon ab, was Sie als Belastung betrachten. Bei vielen Bereitstellungen müssen MAC-Adressen und IP-Adressen ohnehin dokumentiert werden. Eine gut gestaltete DHCP-Konfigurationsdatei ist eine großartige Dokumentation für beide. Jede Schicht des Netzwerkstapels ist wichtig für das Design des Rechenzentrums, daher ist das "Ignorieren" von MAC-Adressen ohnehin keine Option. Die meisten Administratoren, die ich kenne, ziehen es vor, auf die DHCP-Konfigurationsdatei zu verweisen, anstatt die Router- / Switch-Konfiguration zu durchlaufen (oder auf einen Netzwerkadministrator zu warten, um Zeit für eine Antwort zu haben).
Travis Bradshaw

Hallo Travis. Vielen Dank für die hervorragenden Punkte. Ich habe mir wirklich überlegt, welcher Weg für mich der beste ist, und derzeit denke ich immer noch, dass eine Umgebung ohne DHCP attraktiver ist, solange ich es schaffe, die IP-Adressen der Maschinen mit einem Remote-Konfigurationssystem auszuführen.
SyRenity

Kein Problem. Froh, dass ich helfen konnte. Viel Glück. :)
Travis Bradshaw

2

Die einzige Ausnahme, um DHCP nicht im Rechenzentrum auszuführen, ist folgende:

DHCP in einem DEDICATED- Build-VLAN, damit Sie neue Server per PXE starten können, nachdem Sie sie gestapelt haben, um sie abzubilden.

Es gibt keinen anderen guten Grund, DHCP in einem Rechenzentrum auszuführen, wie bereits von allen anderen so gut hervorgehoben wurde.


1

Ich persönlich glaube, dass DHCP in einem Rechenzentrum in Ordnung ist, wenn ein gemeinsamer Adressraum verwendet wird. DHCP bedeutet nicht wirklich, dass es sich um dynamische Adressen handeln muss. Sie können behoben werden.

Solange Sie redundante DHCP-Server bereitstellen (DHCP-Failover), damit DHCP immer verfügbar ist, sollte alles in Ordnung sein.

Früher dachten die Leute, es sei eine schlechte Idee, Switch-Ports der automatischen Auswahl von Geschwindigkeiten und Duplex zu überlassen, und jetzt kenne ich niemanden, der die Zeit damit verbringt, einen Switch wie diesen zu konfigurieren.


1

Warum sind die Leute im Rechenzentrum so besorgt über DHCP?

  • DHCP erleichtert die Verwaltung
  • Zumindest in der MS-Welt ist DHCP sehr zuverlässig
  • Stellen Sie bei Bedenken sicher, dass dies die einzige Arbeitslast auf dem DHCP-Server ist
  • Verstehen Sie, wie Leasingverträge funktionieren. Ein ausgefallener DHCP-Server ist keine Katastrophe. Clients (einschließlich Server) funktionieren weiterhin
  • Es gibt verschiedene Möglichkeiten, MS DHCP hoch verfügbar zu machen, die von MS dokumentiert und unterstützt werden
  • Verwenden Sie Reservierungen und stimmen Sie zu, dass Server-Workloads im Allgemeinen keine dynamisch zugewiesenen Adressen haben sollen
  • DHCP, DDNS und Active Directory passen gut zusammen
  • Diese Themen werden hauptsächlich in anderen Beiträgen hier behandelt
  • Diese Debatte hier und in anderen Foren scheint sehr emotional zu sein. Warum? Weder ist "richtig" noch "falsch" und es kann sogar eine Hybridlösung verwendet werden. Die Größe Ihrer Infrastruktur, das Ausmaß der Änderungen, die betriebliche Reife Ihres Unternehmens, Ihr Appetit oder Ihre Risikoaversion, Ihr Servicelevel, Ihr Personalbestand usw. usw. berücksichtigen diese Faktoren

Haftungsausschluss - Ich habe DHCP im Rechenzentrum implementiert und hatte als Infrastrukturmanager keine Probleme, aber jetzt als Berater für viele Kunden würde ich das nicht tun. Es hängt alles ab ....

Das Folgende wird von MS kopiert. Denken Sie darüber nach und überlegen Sie, warum Sie sich im Rechenzentrum so viele Sorgen um DHCP machen:

Wenn Clients Adresszuweisungen von einem DHCP-Server erhalten, ist es wichtig, vorhersagen zu können, wie sie von Ausfallzeiten des DHCP-Servers betroffen sind. Je länger die Mietdauer ist, desto geringer sind im Allgemeinen die Auswirkungen, wenn die DHCP-Ausfallzeit kurz bleibt. Wenn beispielsweise die Leasingdauer für Kunden auf den Standardwert von 8 Tagen festgelegt ist, versuchen Kunden nicht, die Leasingdauer zu verlängern, bis 50 Prozent dieser Frist (4 Tage) abgelaufen sind. Wenn der ursprüngliche DHCP-Server zu diesem Zeitpunkt nicht verfügbar ist, setzt der Client diese geleaste Adresse bis zu 87,5 Prozent der Lease-Laufzeit (7 Tage) fort und versucht dann, sie mit einem beliebigen DHCP-Server zu verlängern. Bei Clients, die nach 4 Tagen versuchen, eine Verlängerung durchzuführen, würden Clients den Rückbindungsstatus von 87,5 Prozent nicht erreichen, selbst wenn der DHCP-Server 2 Tage lang nicht verfügbar wäre. Deshalb, Normalerweise müssen Sie sich keine Sorgen über Ausfälle machen, die innerhalb von 25 Prozent der Mietdauer liegen. In ähnlicher Weise ist die zur Wiederherstellung des DHCP-Servers verfügbare Zeit umso kürzer, je kürzer die Lease-Zeiten sind.


0

Ähm ... es ist gut für Client-PCs im Büro neben einem Rechenzentrum ...

... auch Drucker, wenn Sie müssen ...

... aber nein, immer noch eine schlechte Idee für Server, zumindest für Produktionsserver - vielleicht in einer Entwicklungs- / Testumgebung, denke ich, oder für VPSs, wenn Sie keine andere Wahl hatten.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.