Intent-basierte Netzwerksysteme sind mehr als nur ein weiteres neues Schlagwort, aber es gibt viele Hürden zu überwinden, bevor diese Art der Vernetzung in den Unternehmen zur Wirklichkeit wird.
Traditionelle IT-Systeme wurden von intelligenten Einzelpersonen (oder Teams) aufgebaut. Diese verstehen, was das eigene Unternehmen an „Connectivity“ benötigt und versuchen diese Anforderungen so optimal wie möglich umzusetzen. Das Ergebnis sind spezifische Konfigurationen für Netzwerkkomponenten, Server, Speicher und die Sicherheitsfunktionen. Der Schlüssel zum Verständnis dieser Netzwerke liegt in den Details der jeweiligen Umsetzung verborgen.
Sehen wir uns beispielsweise die QoS-Definition an. Ich könnte eine Definition für eine Express-Forwarding- (EF-)Warteschlange mit einer Zuweisung von 1 MBit/s festlegen, die auf einer Gigabit-Ethernet-Schnittstelle angewendet wird. Meine Absicht könnte wie folgt definiert werden: 1 Prozent der maximalen Verbindungsgeschwindigkeit wird der EF-Warteschlange zugewiesen. Die Absicht könnte jedoch auch die folgende Definition unterstützen: Zehn G.711-VoIP-Anrufe (inklusive VLAN-Tagging) sollen über eine MPLS-Verbindung übermittelt werden. Für jeden Anruf stehen eine Bandbreite von ca. 100 KBit/s zur Verfügung. Ohne genaue Kenntnis der jeweiligen Anforderung zu kennen, ist die korrekte Konfiguration fast nicht umzusetzbar.
Intent-basierte Systeme vermeiden diese Verwirrung, indem die gewünschte Absicht (Was) konkret benannt wird. Dies erlaubt die direkte Umsetzung der Absichten in die notwendigen Konfigurationen. Die Richtlinie, die 1 Prozent der Bandbreite den Datenströmen der EF-Warteschlange zuweist, ist für das gesamte Netzwerk gültig. Die Richtlinie, die sich um die Anzahl der Anrufe kümmert, muss die zu erwartete Anzahl der Anrufe einer bestimmten Strecke automatisch erkennen.
Definieren der Richtlinien
Die Definition der Richtlinien muss gelernt werden. Die Richtlinien und die damit verbundenen Absichten hängen unter Umständen von der jeweiligen Datenquelle ab. Betrachten wir unser QoS-Beispiel näher, können wir eine dritte Definition festlegen, die auf dem tatsächlichen Anrufvolumen statt auf statischen Werten basiert. Diese Definition könnte wie folgt aussehen:
Es soll für die EF-Warteschlange genügend Bandbreite vergeben werden, damit das maximale Anrufvolumen in jeder der vergangenen vier Wochen abgedeckt wird. Beispielsweise MAX (Woche1, Woche2, Woche3, Woche4).
Die definierte Politik kann auch Warnungen erzeugen, wenn die Ergebnisse einer Richtlinie einen bestimmten Schwellenwert überschreitet: Ein Beispiels hierfür wäre eine Bandbreitenzuweisung, die mehr als 50 Prozent der Bandbreite eines Links beträgt. Eine andere Regel kann auf Alarmschwellen angewendet werden. Diese sorgt dafür, dass das System beim erreichen bzw. beim überschreiten eines festgelegten Werts selbständig Hilfe anfordert.
Eine andere Definition könnte beispielsweise QoS-Merkmale festlegen: Die EF-Warteschlange darf ihre Kapazitäten überschreiten, wenn genügend überschüssige Bandbreite zur Verfügung steht. Tritt ein solcher Fall ein, dann sollte das System eine Warnung an den Administrator übermitteln, dass dieser die Bandbreitenzuteilung anpassen kann. Noch besser wäre es, die Warnung erst nach einer gewissen Anzahl von Vorkommnissen (beispielsweise 10 Mal pro Monat) auszulösen. Diese Richtlinien können in der Praxis ziemlich komplex werden und in der Praxis sollten die Regeln so einfach wie möglich gestaltet werden.
Wie werden Konflikte gelöst?
Was passiert, wenn bei der Vielzahl der unterschiedlichen Regeln gewisse Konflikte auftreten? In unserem QoS-Beispiel können beispielsweise die Bandbreitenanforderungen für andere Warteschlangen gleichzeitig mit den EF-Verkehrsanforderungen wachsen. Dies kann passieren, wenn die Anzahl der Mitarbeiter an einem bestimmten Standort ansteigt und folglich zu einem Anstieg der Daten in allen QoS-Warteschlangen führt. Die optimale Antwort auf diese Situation würde bedeuten, dass dem System mehr Bandbreite bereitgestellt wird. Dieser Prozess ist jedoch zeitaufwändig. Aus diesem Grund muss ein absichtsbezogenes System die richtige Zuordnung der vorhandenen Bandbreite auf allen Warteschlangen vornehmen. Vorübergehende Konflikte erfordern daher eine automatische Handhabung.
Ein weiteres Beispiel für den Einsatz von Intent-basierten Netzwerksystemen ist der Bereich der Netzwerksicherheit. Wir können Richtlinien festlegen, die den Zugriff auf eine Anwendung ermöglicht und eine andere Richtlinie, die den Zugriff aufgrund eines Sicherheitsproblems beschränkt. Die beiden Richtlinien können zu einer Konfiguration führen, bei der die beiden Sicherheitsregeln miteinander in Konflikt stehen. Auch kann der Konflikt davon abhängen, wo die Regeln angewendet werden. Das Zusammenführen der unterschiedlichen Regeln ist ein schwieriger Prozess. Aus diesem Grund sollten die eigentlichen Regeln einfach gehalten werden.
Neue Abstraktionen
Der größte Vorteil von Intent-basierten Netzwerksystemen ist die Möglichkeit, ein Regelwerk für den Einsatz auf großen Teilen des Netzwerks zu schaffen. Dies führt zu einer Vereinfachung der Konfigurationen. Eine QoS-Richtlinie, die für ein gesamtes Unternehmensnetzwerk gültig ist, muss auch die Unterschiede der WAN- und LAN-Strukturen berücksichtigen. Das System sollte den Administrator warnen, wenn bei der Umsetzung einer Richtlinie in der Praxis ein Problem (beispielsweise eine Bandbreitenregel für einen Link der aktuell zu wenig Bandbreite zur Umsetzung der Regel aufweist) entsteht.
Bei Intent-basierten Netzwerksystemen können auch White-List-Verbindungsregeln auf Gruppen von Endpunkten angewendet werden. Anstatt einzelne Firewall-Regeln zu definieren, können Intent-basierte Netzwerkregeln festgelegt werden, die auf Zugriffsregeln für Anwendungen bzw. Anwendungsprofilen bestehen. Die für die Regeln erforderlichen Details (Protokolle, Portnummern und Paketgrößen) sollten aus einer Anwendungsdatenbank bereitgestellt werden, so muss sich der Administrator nicht mehr um die spezifischen Details kümmern. Der Vorteil dieses Abstraktionsprozesses besteht darin, dass das System von sich aus (autonom) die jeweiligen Firewall-Regeln ändern oder löschen kann.
Eine der großen Hürden die die Administratoren bei der Einführung von Intent-basierten Netzwerkregeln überwinden müssen, besteht darin, die jeweiligen Regeln in reale Netzwerkkonfigurationen umzuwandeln. Die Übersetzung der Regeln in reale Konfigurationen erfolgt derzeit durch intelligente Netzwerk-Ingenieure auf einem manuellen Prozess. Diese relativ banale, aber fehleranfällige Aufgabe muss jedes Mal ausgeführt werden, wenn eine Gerätekonfiguration geändert werden soll. Da hierbei in der Regel viele unterschiedliche (und oftmals von einander abhängende) Parameter verändert werden müssen, sind Konfigurationsänderung die Ursache vieler Netzausfälle.
Fazit
Seit mehr als 20 Jahren diskutieren wir regelbasierte Netze. Mit Intent-basierten Netzwerkregeln kommt die Netzwerkindustrie endlich einen Schritt weiter. Die Netze lassen sich dadurch in der gleichen Geschwindigkeit wie die Server- und Speichersysteme konfigurieren und dieser Vorgang dauert nicht mehr Tage oder Wochen, sondern ist in Sekunden oder Minuten abgeschlossen. Mit Intent-basierten Netzwerkregeln wird das seit den 1980er Jahren gültige manuelle Konfigurieren der Netzsysteme auf eine höhere Abstraktionsstufe gehoben und vereinfacht die Arbeitsprozesse.
