Artificial Intelligence Defined Networking – Ein cleveres Netzwerk
Artificial Intelligence, Machine Learning und Deep Learning sind immer wieder Schlagworte, die in den letzten Monaten sich zu einem großen Hype entwickelt haben. Nach einem Hype folgt ja meist das Tal der Tränen und anschließend wird erst klar, was man tatsächlich aus diesen Themen in der Produktion umsetzen kann und welche Mehrwerte daraus gerneriert werden können.
In meinen vorherigen Posts bin ich bereits mehrfach auf die Grundlagen von Application Centric Infrastructure (ACI) eingegangen und einhergehend damit die Vorteile einer automatisierten Nutzung.
Unabhängig von Zukunftsthemen über die Regulatoriken von automatisierten Systemen wie beispielsweise das automatisierte Fahren und den dazu anzupassenden Verkehrsrichtlinien und Versicherungsstrukturen möchte ich heute rein von der Technologie das Thema Artificial Intelligence Defined Networking beleuchten.
In Summe klingt es recht abstrakt und wenn man länger darüber nachdenkt, kommen einem recht schnell zwei Begriffe in den Kopf. Der eine ist SkyNet. Jeder, der Terminator gesehen hat, weiß um die Bedrohung von künstlichen Intelligenzen, die irgendwann komplett eigenständig agieren.
Source: Giphy, Terminator skynet
Des Weiteren denkt man natürlich an iRobot. Ähnliche Idee und die Filmindustrie hat damit mal wieder bewiesen, dass diese Themen nicht ganz unumstritten sind.
Natürlich sind das absolut krasse Beispiele aber selbst in einem stabilen Netzwerk stellt man sich immer wieder die Fragen:
Wie viel Eigendynamik und Lernfähigkeit darf mein Netzwerk haben? Habe ich noch die Kontrolle, sobald mein Netzwerk eigene Entscheidungen trifft?
Um diese Fragen zu beantworten, müssen wir uns mit den technologischen Gegebenheiten vertraut machen und uns fragen:
Warum wollen wir überhaupt Intelligenz im Netzwerk haben?
Diese Frage ist leicht zu beantworten. Intelligenz im Netzwerk bringt mir zwei erhebliche Vorteile. Automatisierte Vorgänge können mit anderen Vorgängen anhand von Logiken kombiniert werden und sind so leichter im Netzwerk auszurollen. Des Weiteren minimiere ich die manuellen Eingriffe eines Administrators, der dafür die Zeit bekommt, sich mit neuen Konzepten und Strukturen in Netzwerken auseinanderzusetzen.
Ein ganz triviales Beispiel: In meinem Netzwerk sind etwa 100 Applikationen deployed. Anhand von Portfreigaben, Trafficflows und anderen Metriken wird erkannt, dass von diesen 100 Applikationen etwa 10 Applikationen sehr identisch sind und das Netzwerk geht sogar noch einen Schritt weiter und identifiziert diese Applikationen als Sharepoint-Umgebungen. Sobald das Netzwerk gelernt hat, was dort existiert, macht es zwei Schritte. Der erste Schritt beschränkt die Regelwerke noch weiter auf die tatsächlich benötigten Freigaben und erhöht im Netzwerk somit die Sicherheit. Der zweite Schritt baut daraus ein generisches Template für Sharepoint-Umgebungen in meinem Netzwerk und passt dieses bei Zeiten an.
Sobald ich nun anfange eine Sharepoint-Umgebung auszurollen auf einem Cluster oder in einer Hybrid-Cloud erkennt das Netzwerk automatisch was passieren soll und erstellt anhand des Templates die entsprechenden VLANs (EPG) und die Regelwerke (Contracts), damit die Applikation einwandfrei kommunizieren kann.
Jetzt sind wir wieder am Anfang! Wollen wir diesen Schritt oder wollen wir ihn nicht? Das sind Grundsatzdiskussionen, die man sich in einer Organisationsstruktur stellen muss . Wenn man diesen Schritt geht, ist die nächste Frage vorprogrammiert:
Nutze ich diese Mechanismen für alle Applikationen oder nur für agile Applikationen, welche meine Entwickler tagtäglich ausrollen?
Sobald ich mir darüber im Klaren bin was ich erreichen möchte und wieviel ich erlaube will, kommen wir zum Punkt, wie man es umsetzt.
In meinen vorherigen Posts bin ich immer wieder auf die Themen Automatisierung und Application Centric Infrastructure eingegangen. Diese bieten das Fundament. Ich brauche ein dynamisches Netzwerk, um dieses auch dynamisch verändern zu können oder automatisch verändern zu lassen.
Sobald im Netzwerk eine Veränderung erkannt wird, möchte ich eine Änderung vornehmen lassen. Im Klartext: Wenn im Trafficflow eines Mongo DB Clusters irgendeine Anomalie entsteht, dann soll diese Anomalie isoliert werden. Zur Erkennung der Anomalien wird durch Hardware- und Software-Sensoren Cisco Tetration eingesetzt, diese über forensische Analysen erkennt, sobald eine Applikation nicht den Traffic verwendet, den diese üblicherweise nutzt. Ich kann also in einem closed-loop direkt wieder Änderungen im ACI einspielen und somit entsprechende Hosts isolieren und mögliche Angreifer abwenden.
Damit ich in Summe überhaupt prüfen kann, ob die Fabric auch das macht was ich von ihr erwarte, kann ich über den Weg der Cisco Network Assurance Engine einen sogenannten Intend prüfen lassen und gegebenenfalls diesen korrigieren. Die CNAE arbeitet hierbei immer wieder als prüfende Instanz, damit Applikationen stabiler laufen und Troubleshooting vereinfacht wird.
Abschließend ist festzustellen, dass wir noch weit entfernt von einem SkyNet sind und dass die komplette Ausbaustufe einer künstlichen Intelligenz fern liegt. Wir befinden uns aber gerade an dem Punkt an dem Prozesse, Routinen und automatisierte Logiken Einzug ins Netzwerk erhalten und diese immer weiter ausgebaut werden, um effizienter und sicherer Netzwerke gestalten zu können.
Tags:- ACI
- AI
- Application Centric Infrastructure
- Apps
- Artificial Intelligence
- automation
- Cisco network assurance engine
- cloud
- CNAE
- Network
- Network as a Service
- network assurance engine
- Tetration
