freshidea - Fotolia

Netzwerkvereinfachung: Was steckt wirklich dahinter?

Netzwerkvereinfachung ist das neueste Schlagwort, das in der IT-Branche die Runde macht. Doch was bedeutet der Begriff Network Simplification genau?

Netzwerkvereinfachung oder Network Simplification ist das Meta-Modewort, das momentan im Networking-Bereich in aller Munde ist. Nehmen Sie zum Beispiel SD-WAN (Software-defined WAN). Diese Technik verspricht, die Komplexität von Wide Area Networks (WANs) zu reduzieren, indem sie MPLS und die Konnektivität über Mietleitungen durch Services ersetzt, die auf die üblichen Übertragungsverfahren im Internet setzen.

Oder denken Sie an die Integration in Form vorintegrierter Stacks von Computing-, Storage- und Networking-Komponenten in einem einzigen Rack. Diese Racks werden dann über eine einzige GUI gesteuert – eine Form von Hyper-Konvergenz. Nicht zuletzt gibt es noch Software-defined Networking (SDN), angepriesen als Mittel für die IT, um komplexe, verteilte Steuerungsschichten aus dem Netzwerk zu entfernen.

Das ist alles gut und schön. Aber es gibt zwei Fragen, die Netzwerktechniker als Reaktion auf das Meta-Modewort Netzwerkvereinfachung stellen sollten.

Einfacher zu nutzen, oder gibt es potenzielle Tücken?

Erste Frage: Ist es wirklich einfacher? Der Umstieg auf SD-WAN, zum Beispiel, reduziert sicherlich die Anzahl der beweglichen Komponenten, die an der Bereitstellung und dem Management eines WAN beteiligt sind. Verbindungen müssen nicht extra beschafft werden, und deren Verwaltung steht kaum etwas im Wege – etwa das Monitoring der Bandbreitennutzung, Anpassen von Quality of Service (QoS) und Interagieren mit dem Provider bezüglich verschiedener Routing-Optionen und -Einstellungen. Viele SD-WAN-Produkte ersetzen den lokalen Router an jedem Standort durch ein einfacheres, billigeres Gerät, das über weit weniger Konfigurationseinstellungen verfügt. Doch ist das Produkt tatsächlich einfacher, oder verbirgt sich die Komplexität einfach hinter einer Schicht aus hübsch gemachten GUIs und Automatisierungsskripten?

Zweite Frage: Ist das eine Rückkehr zu den geschlossenen Systemen aus den Anfangstagen der Netzwerktechnik? Bevor die Internet Engineering Task Force (IETF) und andere Gremien sich der Aufgabe annahmen, Standards zu entwickeln, die es den Nutzern ermöglichen sollten, Ausrüstungskomponenten von verschiedenen Anbietern problemlos miteinander zu kombinieren, konnte ein echtes Network Engineering innerhalb der engen Grenzen des Netzwerks kaum stattfinden. Die notwendigen Informationen, Fähigkeiten und Hilfsmittel standen dem durchschnittlichen Operator realistisch betrachtet einfach nicht zur Verfügung.

Sehr wenige SD-WAN-Produkte beispielsweise sind in irgendeiner Weise offen. Die meisten SDN-Produkte vermitteln auf den ersten Blick einen äußerst offenen Eindruck, aber Sie können sich schnell in Open-Source-Projekten des Typs könnte genauso gut proprietär sein verheddern. Das bedeutet, den überwiegenden Teil der Architekturarbeiten in die Hände von großen Providern oder der Community zu legen, deren Mitglieder mit äußerster Leidenschaft an verschiedenen Ansätzen arbeiten – und dafür Zeit erübrigen können.

Falscher Ansatz für das Komplexitätsproblem

Vielleicht gehen wir das Komplexitätsproblem auf die falsche Weise an. Im Fall von SDN besteht eine echte Gefahr, dass wir einfach ein System durch ein anderes ersetzen, in der Annahme, ein solcher Austausch würde effektiv die Komplexität eines Netzwerks auf sinnvolle Art verringern.

Im Fall der Hyper-Konvergenz und SD-WAN gehen wir – zumindest manchmal – davon aus, dass das System einfach ist, wenn es eine GUI oder ein automatisches Skript für die Netzwerkverwaltung gibt. Wir haben es uns irgendwie angewöhnt, neue Funktionen und Probleme auf die alten zu stapeln, anstatt uns die Zeit zu nehmen, darüber nachzudenken, welche Probleme wir tatsächlich zu lösen versuchen und wie sie sich am besten lösen lassen.

Infolgedessen hat sich das Network Engineering von einem schlanken System – in dem komplette Netzwerkbetriebssysteme nur einige Zehntausend Zeilen Code umfassten – zu einem komplexen System entwickelt, in dem mehrere Zehntausend Seiten an Dokumentation erforderlich sind, um all die Funktionen zu beschreiben, die in den meisten Netzwerkprodukten enthalten sind.

Ein Optimist sagt, das Glas ist halb voll. Ein Pessimist sagt, das Glas ist halb leer. Der Techniker sagt, das Glas ist zu komplex.

Wie weit wir bereits gekommen sind, zeigt das Beispiel von Ask Neighbors2, einer Funktion, die das Team Cymru genauer unter die Lupe genommen hat. Sie können die Entdeckung dieses interessanten DDoS-Angriffs (Distributed Denial of Service) auch im Blog von Team Cymru mitverfolgen.

Alte Funktion als Werkzeug für Hacker

Kurz gesagt, war Folgendes passiert: Eine viele Jahre zuvor für das Troubleshooting von Multicast-Steuerungsschichten hinzugefügte Funktion – die nie wirklich in der Breite zum Einsatz kam – entpuppt sich als äußerst effektiver Angriffsvektor für DDoS-Attacken. Das führt zu der Frage: Wie viele weitere solcher Funktionen lauern unbemerkt in den Abermillionen von Codezeilen, die wir über Millionen von Netzwerken verteilt haben? Wie viele dieser Millionen von Codezeilen werden tatsächlich genutzt? Wie viele davon sind eine tickende Zeitbombe? Wie viele Bugs gehen auf das Konto dieser ungenutzten Codezeilen?

Ich kann mich erinnern, dass ich eine Funktion in ein Betriebssystem implementierte, an dem ich arbeitete. Irgendwann rief mich ein Kunde nach einem Absturz an, den eine damit überhaupt nicht in Zusammenhang stehende – zumindest dachte ich das – Funktion verursacht hatte, von der niemand auch nur ahnte, dass sie noch immer genutzt wurde.

Beginnen Sie, wie Techniker zu denken

Netzwerktechniker müssen es sich zur Angewohnheit machen, nach weniger anstatt nach mehr Funktionen zu verlangen. Wir müssen aufhören, Funktionen wie einen Verbandskasten zu benutzen, mit denen wir jedes Wehwehchen im IT-Bereich kurieren können. Wir müssen lernen, wie Techniker zu denken, und versuchen, eine Netzwerkvereinfachung anzustreben.

Techniker wissen, wie sie Dinge schlanker gestalten und aufbauen können. Ein altes Sprichwort lautet: Ein Optimist sagt, das Glas ist halb voll. Ein Pessimist sagt, das Glas ist halb leer. Der Techniker sagt, das Glas ist zu komplex. Wir haben derzeit eine Menge wirklich voller, zu komplexer Gläser in Form von Produkten, die alles Erdenkliche erledigen.

Es ist an der Zeit, Network Engineering zum Zwecke der Netzwerkvereinfachung zu nutzen.

Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Management von Netzwerkfehlern in modernen komplexen Rechenzentren

So vermeiden Sie Komplexitätsfallen einer diversifizierten Cloud-Strategie

Deployment und Upgrades von OpenStack: So lässt sich die Komplexität reduzieren

Kostenloses E-Handbook: Ratgeber SD-WAN

Artikel wurde zuletzt im August 2017 aktualisiert

Erfahren Sie mehr über IP-Netzwerke

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close