ACI-Automatisierung

Einer der Vorteile von ACI ist das Verwenden eines objektbasierten Modells, das die vollständige Konfiguration von Netzwerkkomponenten über ein offenes Representational State Transfer Application Programming Interface (REST-API) erlaubt. Der programmierbare Charakter von ACI ermöglicht die Flexibilität des Netzes. Manuelle und wiederholbare Aufgaben können mit Skripten automatisiert werden, um Zeit zu sparen und eine Standardisierung der Konfiguration durchzusetzen.

Das Gehirn der ACI-Umgebung

Im Gegensatz zu traditionellen Netzen, die ein imperatives Modell verwenden, nutzt ACI ein deklaratives zentrales Steuersystem. Dadurch sind individuelle Aufrufe auf einzelne Netzwerkkomponenten nicht mehr notwendig, da die gesamte Verwaltung und Konfiguration über einen zentralen Verwaltungspunkt ablaufen. Bei diesem zentralen Verwaltungspunkt handelt es sich um den sogenannten Application Policy Infrastructure Controller (APIC). Aus der Verwaltungsperspektive verwaltet und konfiguriert der APIC die Richtlinie auf jedem Switch in der gesamten ACI-Fabric. Der APIC stellt demanch so etwas wie das Gehirn der ACI-Fabric dar. Dieser speichert alle Richtlinien, Protokolle und statistische Daten in einer Datenbank. Beim APIC handelt es sich um einen Software-Controller, welcher auf einem UCS-Server (Cisco Unified Computing System) läuft. In der Praxis werden oft drei APIC-Hardware-Appliances eingesetzt, die ein Cluster bilden. Der APIC liegt im Gegensatz zu anderen SDN-Lösungen nicht auf dem Datenpfad. Demzufolge wird die Datenweiterleitung weiterhin durch die Fabric-Komponenten ausgeführt, selbst wenn die Kommunikation mit dem APIC unterbrochen werden sollte.

ACI-Objekt- und Richtlinienmodell

Eine ACI-Fabric besteht nicht nur aus physischen, sondern auch aus logischen Komponenten. Die Komponenten können in einer Objekthierarchie dargestellt werden, die als Management Information Model (MIM) bezeichnet wird. Das MIM wird auf dem APIC verwaltet und gespeichert.

Die hierarchische Darstellung des MIMs ist in Abbildung 1 zu sehen und wird als Management Information Tree (MIT) bezeichnet. Jeder Knoten im MIT stellt ein verwaltetes Objekt (MO) oder eine Gruppe von Objekten dar. Bei den MOs handelt es sich um eine Abstraktion der Fabric-Ressourcen. Ein verwaltetes Objekt kann ein konkretes Objekt, wie z.B. ein Switch, oder auch ein logisches Objekt, wie z. B. eine Richtlinie, oder ein Anwendungsprofil sein.

Die logische hierarchische Struktur fängt mit dem Policy Universe bzw. Richtlinienmodell (polUni) an und enthält untergeordnete Objekte. Jedes weitere Objekt kann weitere untergeordnete Objekte enthalten. Jedes MO in dieser hierarchischen Baumstruktur besitzt eine Klasse, einen global relativen Namen (RN) und einen sogenannten eindeutigen Namen (DN). Mithilfe der Namen kann die Position im Baum beschrieben werden.

RN ist ein Präfix, wodurch ein MO relativ zu dem übergeordneten Objekt identifiziert wird. Ein relativer Name ist in seinem Namensraum eindeutig, was bedeutet, dass es innerhalb des lokalen Geltungsbereichs eines MOs immer nur ein RN mit diesem Namen geben kann. Um dieses eindeutige verwaltete Objekt in der Baumstruktur zu finden, verwendet das Richtlinienmodell einen DN, der den gesamten Pfad in der Baumstruktur verfolgt.

Mit der Klasse lassen sich die Konfigurationsmöglichkeiten und die Struktur des jeweiligen MOs beschreiben. Mit Ausnahme der Baumwurzel (topRoot) haben alle Klassen ein einziges übergeordnetes Objekt und können dementsprechend mehrere untergeordnete Objekte enthalten.

Zur einfacheren Navigation innerhalb des Baumes lassen sich logische Gruppen von Klassen bilden, die ähnliche konfigurierbare Attribute besitzen. Dabei setzen sich die Klassennamen aus dem Paketnamen und der eigentlichen Klasse zusammen. Am Beispiel der Klasse topRoot wäre der Paketname top und der Name der eigentlichen Klasse Root. Ein weiteres Beispiel wäre die Klasse für die Bridge-Domäne fvBD. Der Name setzt sich hierbei aus dem Paketnamen fv und der Klasse BD zusammen.

Das hierarchische Richtlinienmodell eignet sich zur Nutzung der REST-API-Schnittstelle. Wenn die API aufgerufen wird, liest die API von Objekten im MIT oder schreibt in diese. Die URLs des Browsers lassen sich direkt auf eindeutige Namen abbilden, die die Position der verwalteten Objekte im MIT kennzeichnen. Es ist auch möglich, eine Abfrage auf Baumebene durchzuführen, um alle Elemente eines Objektes zu ermitteln. Dabei werden die Daten in der MIT in XML oder JSON kodiert.

Zugriffsmöglichkeiten

Die APIC-Architektur basiert auf REST, wodurch eine programmierbare Schnittstelle zur Verfügung steht und über XML und JSON festgelegt ist. Um auf den APIC zugreifen zu können, existieren unterschiedliche Möglichkeiten, wie in Abbildung 2 dargestellt.

Für die programmiergesteuerte Verwaltung, Konfiguration und Datenerfassung kann ein Administrator die REST-API verwenden. Sobald eine REST-API-Verbindung mit einem APIC über HTTP oder HTTPs hergestellt wurde, können über XML- und JSON-Dateien API-Methoden oder Objekte aufgerufen werden.

Wenn kein unmittelbarer Bedarf an Automatisierung oder Programmierbarkeit der Fabric besteht, bietet sich die integrierte grafische Benutzeroberfläche an. Neben Verwaltung und Konfiguration kann über die GUI zu jedem Zeitpunkt der Fabric-Zustand beobachtet werden.

Eine weitere manuelle Zugriffsmöglichkeit bietet die Kommandozeile (CLI). Über diese Methode können auch tiefer gehende Fehlersuchen durchgeführt werden.

Unabhängig davon, welche der drei Methoden Anwendung findet, werden alle drei schließlich in der API aufgelöst. Sowohl die GUI als auch die CLI sind im Grunde genommen Schnittstellen zur API.

REST-API

Die REST-API ist eine Client- /Server-Kommunikationsmethode, die ein TCP-basiertes HTTP- oder HTTPS-Protokoll verwendet, bei dem der Client eine Ressourcenanfrage an einen Server stellt und der Server als Antwort einen Status der angeforderten Ressource an den Client übermittelt. Die Anfrage besteht in der Regel aus den folgenden Elementen:

• HTTP / HTTPS-Methode: Legt fest, welche Art von Operation durchgeführt werden soll
  • GET-Methode: Ruft eine bestimmte Ressource oder eine Sammlung von Ressourcen ab
  • POST-Methode: Erzeugt oder aktualisiert eine Ressource
  • DELETE-Methode: Entfernt eine bestimmte Ressource
  • PUT-Methode: Wird in ACI nicht unterstützt
• Header: Ermöglicht dem Client, die Anfrage zu übermitteln
• Pfad: Identifiziert den Ort einer Ressource
• Nachrichtentextkörper (Body): Enthält Daten, die in XML oder JSON kodiert sind

Die POST- und DELETE-Methoden sind idempotent. Somit gibt es keine zusätzlichen Auswirkungen, wenn sie mehrfach mit denselben Eingabeparametern aufgerufen werden. Die GET-Methode hingegen ist nullipotent. Unabhängig von den Eingabeparametern und wie oft sie ausgeführt wird, gibt es keine Änderung des MIT-Objektmodells. Das bedeutet, es werden nur Lese-Operationen durchgeführt.

Um den Umfang einer Abfrage im URL einzugrenzen, können die von der REST-API zur Verfügung gestellten Filterfunktionen verwendet werden. Die Filter in der URL können mit einem Fragezeichen beginnen. Um mehrere Filter in einer URL nutzen zu können, gibt es die Möglichkeit, diese miteinander zu verketten, indem ein UND-Symbol (&) eingefügt wird.

Zur Authentifizierung der HTTP(S)-Anfrage werden im Nachrichtentextkörper der Benutzername und das Passwort eingegeben. Bei Erfolg wird ein Authentifizierungstoken zurückgegeben. Das Token wird in den darauffolgenden REST-API-Aufrufen als Cookie oder HTTP-Header verwendet. Hierbei muss jedoch beachtet werden, dass der Authentifizierungstoken bei jeder einzelnen REST-Anfrage übergeben werden muss. In einigen Sprachen werden die Cookies für den Nutzer verwaltet. Wenn beispielsweise eine HTTP-Anfrage gestellt wird und der Server ein Cookie zurückgibt, wird dieses Cookie automatisch in den darauffolgenden Anfragen auf denselben Server gesetzt. Es gibt jedoch auch Sprachen, die das Cookie nicht automatisch setzen. In solch einem Fall muss der Nutzer den Authentifizierungstoken aus der Antwort des Servers extrahieren und es dann als HTTP-Header in jede einzelne REST-Anfrage einfügen.

Die API-Hilfstools

Mit dem API-Inspektor kann jedes Paket, das durch die Leitung fließt, erfasst werden. Wenn beispielsweise ein Task auf dem APIC ausgeführt wird, dann ruft die GUI im Hintergrund die REST-API auf. Mit dem integrierten API-Inspektor können die API-Aufrufe angezeigt werden. So hat man die Möglichkeit, die API-Aufrufe zu replizieren, um bestimmte Tasks zu automatisieren.

Weiterhin gibt es den Objektmodell-Browser namens Visore. Das Tool hilft dabei herauszufinden, welche Werte für eine bestimmte Variable möglich sind und welche Werte für jedes Objekt existieren oder wie die Beziehung zwischen den Objekten verschiedener Klassen aussieht.

Um Visore aufzurufen, ist folgender URL in die Browser-Suchzeile einzugeben: https://APIC-IP-Adresse/visore.html.

Visore ist auch in einer Kommandozeilen-Version verfügbar. Hierbei handelt es sich um das Tool Moquery (Managed Object Query). Um Moquery aufzurufen, wird eine Verbindung zum APIC-CLI benötigt. Von dort aus kann mit dem Kommando moquery das Tool aufgerufen werden.

Python-SDK für ACI

Neben der Verwendung nativer REST-API-Aufrufe mit rohen XML- und JSON-Formaten besteht auch die Möglichkeit, eine Programmiersprache wie Python zu verwenden. Cisco bietet hierzu das Python Software Development Kit (Python-SDK) an, auch bekannt als Cobra, um API-Aufrufe zu tätigen, ohne XML- und JSON-Formate posten zu müssen.

Ein Aspekt des SDKs ist das Vorhandensein des Tools APIC REST Python Adapter (Arya), welches zur dynamischen Codegenerierung dient. Hierdurch kann auch ohne Python-Kenntnisse das SDK verwendet werden. Mit Arya ist es nämlich möglich, rohe XML- oder JSON- Formate in Python-Code umzuwandeln.

Ansible

Ein weiteres Tool, welches zur Automatisierung bestimmter Aufgaben genutzt werden kann, ist Ansible. Im Gegensatz zu anderen Tools wie z. B. Chef oder Puppet ist Ansible ein agentenloses Tool, das in einem Push-Modell mit in Python entwickelten Modulen läuft. Es läuft auf einem System, das als Kontrollknoten bezeichnet wird, der diese Automatisierungsskripte über eine SSH-Verbindung an sogenannte Managed Hosts weiterleitet. Diese sind in einer Inventardatei enthalten. Das Automatisierungsskript an sich besteht dabei aus einer Reihe von Anweisungen in einem sogenannten Playbook. Der Kontrollknoten kann dabei auf einem Betriebssystem laufen, und ein Managed Host kann ein physischer oder virtueller Server, ein Netzwerkgerät oder auch ein L4-L7-Gerät sein.

Der Ablauf sieht so aus, dass sich das Playbook die Informationen über die Managed Hosts aus dem Inventarfile holt und alle darin beschriebenen Geräte mit den Befehlen aus dem Playbook automatisiert konfiguriert.

Die für ACI entwickelten Ansible-Module laufen jedoch weder auf den Fabric-Switches noch auf dem Fabric-Controller (dem APIC). Vielmehr kommunizieren sie direkt mit der REST-API des APIC. Daher laufen die Ansible-Module für ACI entweder lokal auf dem Ansible-Kontrollknoten oder werden an andere Systeme übertragen, die über sichere Verbindungen verfügen.

Zusammenfassung

Aufgrund des objektbasierten Aufbaus von ACI und des auf REST basierten Software-Controllers APIC gibt es bei ACI die Möglichkeit, viele der manuellen und langwierigen Abläufe sowie Routineaufgaben zu automatisieren. So können Prozesse viel effizienter gestaltet werden. Zudem werden Gefahren wie z. B. menschliches Versagen oder unterschiedliche Konfigurationen auf ein Minimum reduziert.

Verweis

[1] Cisco ACI Policy Model Guide, 18. Februar 2018