Ihr Inventar ist eine Hypothese, bis das Netzwerk sie bestätigt

Jedes Rechenzentrumsinventar beginnt korrekt und driftet vom ersten Tag an. Ein Server wird umgezogen, ein Kabel in Eile ersetzt, eine Adresse wiederverwendet, und der Datensatz hört leise auf, die Wirklichkeit zu beschreiben. Die Lösung ist keine größere Tabelle. Es ist eine Gewohnheit: Behandeln Sie jeden Datensatz als Behauptung und prüfen Sie ihn gegen das Live-Netzwerk, wann immer Sie ihn schreiben oder sich auf ihn verlassen.

Das Live-Gerät gewinnt

Die erste Regel ist die, die jeden Streit entscheidet. Wenn Datensatz und Gerät nicht übereinstimmen, hat das Gerät recht, und der Datensatz wird korrigiert. Ein DCIM, das ständig mit dem laufenden Netzwerk abgeglichen wird, wird zum nützlichsten Werkzeug, das Sie um drei Uhr morgens haben.

Wir betreiben ein selbst gehostetes DCIM auf Basis von RackTables, erweitert um Module, die Live-Daten von den Geräten ziehen: ARP-Tabellen, Port-Status, Fibre-Channel-Zoning, Storage-Exporte und Switch-Konfigurationen. Die Abfragen existieren, damit der Datensatz gegen die Leitung geprüft werden kann, nicht damit man ihm für sich allein vertraut.

Beweisen Sie auf drei Arten, dass eine Adresse frei ist

Ein Datensatz, der «frei» sagt, ist die erste Prüfung, nicht die letzte. Bevor irgendeine Adresse vergeben wird, prüfen wir sie auf drei Arten:

1. Der Datensatz. Ist sie im DCIM irgendetwas zugewiesen?
2. Die ARP-Tabellen. Hat irgendein Router oder Switch in diesem Segment sie kürzlich gesehen? Auf Cisco-Geräten antwortet show ip arp <address> in einer Sekunde.
3. Die Leitung selbst. Von einem Host im selben Segment fragt die Duplicate Address Detection das ganze Segment, ob jemand die Adresse besitzt:

arping -D -I <interface> -c 3 <address>
echo $?    # 0 means nobody answered, 1 means the address is in use

Ping ist die schwächste der Prüfungen, weil ein Host hinter einer Firewall nicht antwortet, weshalb ARP im lokalen Segment mehr zählt. Wenn irgendeine Prüfung dem Datensatz widerspricht, gewinnt die Live-Antwort, und Sie untersuchen, bevor Sie irgendetwas vergeben. Auf jede Zuweisung folgen dann ihre Vorwärts- und Rückwärts-DNS-Einträge, damit jede Adresse im Netzwerk zu einem Namen auflöst, der sagt, was sie ist.

Bestätigen Sie die Hardware und ihre Links

Lesen Sie die MAC-Adressen von der Maschine

Von einem Aufkleber oder einem Angebot von Hand abgeschriebene MAC-Adressen sind oft genug falsch, dass es zählt. Bevor ein Server ins Rack kommt, kann sein Management-Controller Ihnen bereits die echte MAC jedes Netzwerkports nennen, und bei Blade-Systemen kann das Enclosure Ihnen jede MAC und jede Fibre-Channel-WWPN für jeden Einschub nennen. Lesen Sie sie dort ab und schreiben Sie sie in den Datensatz. Wenn der Server angeschlossen ist, sollte die MAC-Adresstabelle des Switches genau die Adressen zeigen, die Sie erfasst haben, genau an den Ports, die Sie geplant haben.

Bestätigen Sie die Verkabelung mit LLDP

Ein Kabelplan ist eine Absichtserklärung. LLDP sagt Ihnen, was tatsächlich angeschlossen wurde. Auf dem Switch:

show lldp neighbors detail

Auf einem Linux-Host mit lldpd:

lldpctl

Jede Seite meldet den Nachbarn, den sie sieht: Systemname und Port. Vergleichen Sie das mit den Links im Datensatz. Ein Server, der den richtigen Switch am falschen Port meldet, ist ein Verkabelungsfehler, der gefangen wird, bevor er Traffic trägt, statt eines Nachmittags voller Verwirrung später.

Lesen Sie jedes Feld zurück

Wenn ein Aufbau oder eine Verkabelungsarbeit fertig ist, lesen Sie jedes Feld, das Sie geschrieben haben, aus der Datenbank zurück und vergleichen Sie es mit dem Plan: Höheneinheiten, Ports, MAC-Adressen, Links an beiden Enden, Cable-IDs, Adresszuweisungen mit dem Interface, auf dem sie liegen, Management-Controller, und bei Blades ihr Platz im Enclosure. Ein halb gefülltes Objekt ist unfertige Arbeit, kein Entwurf zum späteren Vervollständigen. «Später» ist die Art, wie Datensätze driften.

Eine weitere Absicherung ist billig und fängt erstaunlich viel: Lassen Sie regelmäßig einen Duplikatbericht laufen, denn zwei Datensätze für eine Maschine sind so irreführend wie keiner.

Gleichen Sie auch die Storage-Fabric ab

In einer Fibre-Channel-Fabric sollte der Datensatz die WWPN jedes Host-Ports enthalten, den Switch-Port, auf dem er landet, und die Zonen, zu denen er gehört. Die Fabric selbst kann alle drei bestätigen. Auf Brocade-Switches listet switchshow, was an jedem Port eingeloggt ist, nsshow listet die im Name Server der Fabric registrierten WWPNs, und zoneshow gibt das aktive Zoning aus. Vergleichen Sie das mit dem Datensatz auf beiden Fabrics. Ein Host, der nur in einer Fabric eingeloggt erscheint, ist ein Host, der einen Switch-Ausfall davon entfernt ist, seine Platten zu verlieren, und der Vergleich findet ihn, bevor das passiert. Wir ziehen das Zoning genau deshalb von den Switches in unser DCIM, damit der Datensatz einer Zone die Zone ist, wie die Fabric sie durchsetzt.

Verwenden Sie eine Cable-ID nie wieder

Jedes Kabel, das wir installieren, trägt an beiden Enden ein laminiertes Etikett mit einer eindeutigen numerischen Cable-ID sowie Rack, Gerät, Port und Länge des fernen Endes, und dieselbe Nummer wird am Link im DCIM erfasst. Die Regel, die das funktionieren lässt, ist die, die man am ehesten zu brechen versucht ist: Eine Cable-ID wird nie wiederverwendet, nicht einmal die Nummer eines inzwischen entfernten Kabels. Unsere kommen aus einem eigenen Allocator, werden reserviert, bevor die Etiketten gedruckt werden, und auf Duplikate überwacht. Warum die vertraute Methode «höchste Nummer plus eins» scheitert und wie man die Vergabe richtig betreibt, ist das Thema von Kabel nummerieren. Warum «höchste plus eins» die falsche Regel ist.

Bauen Sie zuerst auf dem Papier

All das läuft in einer Gewohnheit zusammen: Neue Hardware ist vollständig im Datensatz, bevor sie ankommt. Höheneinheiten, Management-Controller, jeder Port mit seiner MAC-Adresse, Port-Channels, die Switch-Ports am anderen Ende und eine reservierte Cable-ID für jeden Link. Der Etikettensatz wird im Voraus gedruckt, und die Hardware wird nach einem Plan ins Rack gebaut und verkabelt, der bereits der Datensatz ist. Die Verifikation am Ende ist dann ein Vergleich, keine Rekonstruktion.

Prüfen Sie Ihre eigenen Datensätze

• Wählen Sie eine als frei markierte Adresse und führen Sie alle drei Prüfungen durch. Stimmen sie überein?
• Wählen Sie einen Server und vergleichen Sie seine erfassten MACs mit der MAC-Tabelle des Switches.
• Lassen Sie LLDP in einem Rack laufen und vergleichen Sie jeden Link mit dem Datensatz.
• Vergleichen Sie die WWPNs jedes Hosts im Datensatz mit nsshow auf beiden Fabrics.
• Suchen Sie nach jeder Kabelnummer, die auf zwei Links erscheint.

Wenn Sie eine Migration planen und sie auf einem Datensatz aufbauen wollen, dem Sie vertrauen können, helfen wir gern. Mit einem Ingenieur sprechen

Related (rows[1])

Verwandte Themen: DCIM: jedes Objekt, jeder Port, jedes Kabel und jede Adresse erfasst · Rack-Aufbau, Blade-Onboarding, Management-Controller · Strom-Monitoring und Kapazität