„Natürlich weiß ich, dass die Automatisierung die Netzwerke im Unternehmen zerstören kann. Diese Tatsache lässt sich nicht leugnen. In der Vergangenheit war es jedoch nie nötig, unsere Netzwerke durch Automatisierung zu zerstören – dafür haben wir schon selbst gesorgt. Wir waren recht geschickt darin, dumme Fehler zu machen. Wir haben Spanning-Tree-Schleifen oder schwarze Löcher im Routing konfiguriert, unbeabsichtigt Schnittstellen deaktiviert oder haben wichtige Netzwerkkomponenten zum Absturz gebracht.
Um unseren dummen Fehlern entgegenzuwirken, haben wir umfangreiche Prozesse entwickelt, die uns helfen sollen, Fehler zu erkennen, bevor sie das Netzwerk erreichen. Wir verwenden Peer-Reviews und Change-Review-Boards, um große Fehler zu vermeiden. Wir verwenden Konfigurations-/Backout-Verfahren, um einen Fehler rückgängig zu machen, wenn uns dieser trotz aller Vorsicht trotzdem unterläuft. Gewisse Zeitfenster in denen Änderungen durchgeführt werden, geben uns hoffentlich Zeit, die Änderung vorzunehmen, sie zu testen und zurückzunehmen, wenn sie nicht so funktioniert.
Netze sind komplexe Kombinationen von Protokollen und Technologien mit oft nicht offensichtlichen Wechselwirkungen, die es zu verstehen gilt. Doch die Geschwindigkeit des Geschäftslebens führt zu einem Zeitdruck, der es nicht erlaubt, alle Zusammenhänge vollkommen zu verstehen. Außerdem konzentrieren sich die Schulungen der Netzwerkanbieter traditionell auf die Protokolle und die Konfiguration einer einzelnen Box nach der anderen. In den Schulungslaboratorien sind in der Regel nur einige wenige Geräte vorhanden, und wir konzentrieren uns darauf, wie die Konfigurationsbefehle funktionieren. Diese recht kurzsichtige Sichtweise wenden wir dann auf ein viel größeres Netzwerk an, in dem die Dinge etwas komplizierter sind.
Wir stellen auch fest, dass sich Gerüchte früherer Probleme hartnäckig halten. Ein gutes Beispiel ist das Gerücht, dass man die Duplex-Einstellung der Ethernet-Schnittstelle konfigurieren muss. Das Problem stammte von einigen Geräten, die die Geschwindigkeits- und Duplex-Aushandlung nicht korrekt implementiert hatten. Diese Zeiten liegen bereits weit hinter uns (es sei denn, man betreibt 20 Jahre alte Geräte im Netzwerk), so dass es keinen Grund gibt, dieses Gerücht weiter zu verbreiten. Ein anderes Gerücht besagt, dass viel Bandbreite ein guter Ersatz für die Priorisierung von zeitkritischem Netzwerkverkehr mit QoS ist. Um auf dieses Gerücht zu reagieren, empfehle ich immer, sich eingehend über die Themen „Microbursts“ und „Bufferbloat“ zu informieren.
Warum sind wir bei der Automatisierung so zurückhaltend?
Wir haben das Netzwerk schon einmal mit einem einzigen Befehl zerstört. Es gibt nichts, was uns daran hindert, den Netzbetrieb nicht mit der Automatisierung zu zerstören. Wir tragen immer eine Menge alten Gepäcks – bestehend aus vergangenen Fehlern – in die Zukunft. Fakt ist jedoch, dass neue Tools das Erlernen neuer Methoden erfordern, um deren Nutzung zu optimieren. Ein gutes Werkzeug, das falsch eingesetzt wird, ist schlimmer als ein mittelmäßiges Werkzeug, das gut eingesetzt wird.
Als Netzwerker sind wir keine Softwareentwickler, und verfügen in der Regel über wenig Programmierkenntnisse. Es gibt eine Softwareentwicklungsmethode namens Pair-Programming, bei der zwei Personen zusammenarbeiten, um Software zu erstellen. Eine Abwandlung dieses Prozesses, bei der ein Netzwerkarchitekt mit einem Softwareentwickler zusammenarbeitet, ermöglicht es Netzwerkingenieuren, neue Fähigkeiten zu erlernen und gleichzeitig Softwareexperten beizubringen, wie Netzwerke funktionieren.
Wir müssen uns weiterbilden. Wir müssen lernen, wie wir unser Wissen über Geräte und Systeme nutzen können, um große Netze mit Hilfe von Automatisierung zu entwerfen, aufzubauen und zu betreiben.
Wir haben Design-Faustregeln entwickelt, mit denen wir stabile Netzwerke aufbauen können, ohne alle Details und Auswirkungen verstehen zu müssen. Die Anbieter stellen uns Designs zur Verfügung, die sich in realen Netzwerken bewährt haben, und wir müssen sie verwenden. Am besten verwendet man diese Bausteindesigns für verschiedene Teile des Netzes. Die Bandbreite ist so günstig, dass wir es uns leisten können, ein oder zwei Designs für alle entfernten Standorte zu verwenden. Das Gleiche gilt für die Switches in den Rechenzentren – diese sollten alle auf den gleichen Designkriterien basieren.
Natürlich kann ich schon wieder die ewigen Bewahrer hören: Das geht so nicht, denn unser Netzwerk ist einzigartig!
Wenn das Netzwerk wirklich einzigartig ist, sollte man mit einzigartigen Problemen rechnen. Aber ich garantiere, dass dieses Netzwerk vielen anderen Netzwerken in verschiedenen Branchen ähnlich ist. Einige Details sind anders, aber die Notwendigkeit, Dateien zu übertragen, Sprach- und Videoanrufe zu führen und mit Anwendungen zu interagieren, ist immer gleich.
Es gilt das Netzwerkdesign so zu vereinfachen, dass wiederholbare Automatisierungsprozesse einfach einzusetzen sind.
Warum Netzwerkautomatisierung?
Die Automatisierung bringt viele Vorteile mit sich:
- Weniger menschliche Fehler,
- Konsistenz der Konfiguration,
- höhere Effizienz,
- keine lästigen Funktionen mehr (Automatisierung) oder
- Zero-Touch-Bereitstellung.
Bei der Automatisierung vollzieht sich ein interessanter Paradigmenwechsel. Es ist der Wechsel von der Hardware-Infrastruktur zur Infrastruktur als Code. Wir verwenden Software, um Abstraktionen zu schaffen, die das, was wir tun wollen, von den Implementierungsdetails entkoppeln. Das macht uns effizienter und wir machen weniger Fehler. Aus diesem Grund müssen wir zur Netzwerkautomatisierung übergehen.
Fazit
Ja, es gibt eine Menge zu lernen. Das macht es ja gerade so spannend. Die Zeit, damit zu beginnen, ist jetzt.“
Von Mathias Hein, Consultant, Buchautor, Redakteur
