Whitepaper
Programmierbarkeit von Netzwerken mit Cisco
Application Centric Infrastructure
Übersicht
In diesem Dokument wird die Unterstützung der Programmierbarkeit durch die Cisco® Application Centric
Infrastructure (ACI) näher erläutert. Das Programmierungsmodell der Cisco ACI ermöglicht einen umfassenden
programmgesteuerten Zugriff auf die Application Centric Infrastructure. Die Cisco ACI bietet über REST-APIs
(Representational State Transfer) Lese- und Schreibzugriff auf das zugrunde liegende Objektmodell. Dieses ist
eine Darstellung sämtlicher physischer und logischer Attribute des gesamten Systems. Mithilfe dieses Zugriffs
können Kunden die Netzwerkbereitstellung in Management- und Überwachungstools integrieren und neue
Workloads programmgesteuert bereitstellen.
Herausforderungen bei bisherigen Ansätzen zur Netzwerkprogrammierbarkeit
Die meisten heute betriebenen Netzwerke basieren auf Hardware mit eng integrierter Software, die auf
Management und Administration über die Kommandozeile (CLI) ausgelegt sind. In Umgebungen mit statischen
Konfigurationen, statischen Workloads und berechenbaren Geschwindigkeiten bei der Anwendungsskalierung
arbeiten solche Systeme erfolgreich. In virtualisierten und Cloud-basierten Rechenzentren mit flexiblen IT-Modellen
funktioniert dieses Modell jedoch nicht mehr.
Aus diesem Grund arbeiten die Hersteller an der Integration der Programmierbarkeit in bestehende Geräte und
Betriebssysteme. Dieser Ansatz bietet zwar einen größeren Funktionsumfang, ist aber zur Integration von
Programmierbarkeit nicht ideal geeignet. Durch die Einführung einer völlig neuen Management-Stelle (in der Regel
ein Netzwerk-Controller) sollen Anwendungs- und Benutzerrichtlinien in unflexible Netzwerkstrukturen integriert
werden – so steigt am Ende die Komplexität. Darüber hinaus sind diese Netzwerk-Controller und ihre Modelle auf
Netzwerkfunktionen beschränkt und unterstützen die übrige Infrastruktur nicht. Aus diesem Grund muss die
Programmierbarkeit schon Teil der Basis sein, anstatt erst nachträglich angewendet zu werden. Die
Infrastrukturkomponenten und ihre zugrunde liegenden Strukturen müssen bereits unter Berücksichtigung der
Programmierbarkeit konzipiert werden. Das dabei angewendete Modell müssen Programmierer leicht umsetzen
können.
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 1 von 8
Programmierbarkeit bei der Cisco ACI mit objektorientiertem Datenmodell und REST-APIs
Cisco hat bei der Entwicklung einer programmierbaren Netzwerkinfrastruktur mit der Cisco ACI-Lösung einen
grundsätzlichen Ansatz gewählt. Diese Infrastruktur arbeitet auf der Fabric-Ebene als Einzelsystem, das durch den
zentralisierten Cisco Application Policy Infrastructure Controller (APIC) kontrolliert wird. Auf diese Weise wird das
Rechenzentrumsnetzwerk als Ganzes zusammengefasst und fungiert als intelligentes Transportsystem für
geschäftskritische Anwendungen. Der Kern des Betriebssystems auf den Netzwerkgeräten in der Fabric unterstützt
diese Systemsicht und stellt eine Architektur bereit, die auf Programmierbarkeit basiert.
Statt wie bei früheren SDN-Lösungen (Software Defined Networking) einen Teil der Netzwerkfunktionen über
Programmierschnittstellen zu realisieren, ermöglicht die gesamte Infrastruktur einen programmgesteuerten Zugriff.
Dies ist durch den Zugriff auf das Objektmodell der Cisco ACI möglich, das die gesamte Konfiguration und den
Laufzeitstatus sämtlicher Software- und Hardwarekomponenten in der gesamten Infrastruktur darstellt. Außerdem
wird dieses Objektmodell über REST-Standardschnittstellen bereitgestellt, wodurch das Modell selbst und somit
auch die Konfiguration und der Laufzeitstatus des Systems einfacher zu verwalten sind.
Auf der obersten Ebene basiert das Objektmodell der Cisco ACI auf der Promise Theory, einer skalierbaren
Kontrollarchitektur, in der autonome Objekte die vom Controller-Cluster angeforderten Statusänderungen
umsetzen. Dieses Konzept ist skalierbarer als herkömmliche hierarchische Managementsysteme, die umfassende
Kenntnisse der untergeordneten Konfigurationen und des aktuellen Status erfordern. Bei der Promise Theory
werden Statusänderungen angefordert und von den Objekten umgesetzt, wobei ggf. Fehler zurückgegeben
werden.
Dieses Konzept ist dem Kern der Programmierbarkeit bei der Cisco ACI übergeordnet: dem Objektmodell. Das
Modell kann in einen logischen und einen physischen Teil unterteilt werden. Modellbasierte Strukturen eignen sich
sehr gut zur Darstellung von Daten. Das Cisco ACI-Modell bietet umfassenden Zugriff auf das zugrunde liegende
Informationsmodell mit Richtlinienabstrahierung, physischen Modellen sowie Debugging- und
Implementierungsdaten. In Abbildung 1 ist die Struktur des Cisco ACI-Modells dargestellt. Der Zugriff auf das
Modell ist über REST-APIs möglich, sodass das System programmierbar wird.
Abbildung 1.
Objektorientiertes Datenmodell und REST-APIs bei der Cisco ACI
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 2 von 8
Wie in Abbildung 1 gezeigt, bildet das logische Modell die Schnittstelle mit dem System. Administratoren oder
Cloud-Managementsysteme auf höherer Ebene interagieren über die API, CLI oder GUI mit dem logischen Modell.
Änderungen am logischen Modell werden anschließend an das physische Modell übergeben, das die Grundlage
für die Hardwarekonfiguration bildet.
Das logische Modell selbst besteht aus den veränderbaren Objekten (Konfiguration, Richtlinien und Laufzeitstatus)
und deren Attributen. Im Cisco ACI-Framework wird dieses Modell als Management Information Tree (MIT)
bezeichnet. Jeder Knoten im MIT stellt ein verwaltetes Objekt oder eine Objektgruppe dar. Diese Objekte sind
hierarchisch in logische Objektcontainer strukturiert. Abbildung 2 zeigt die logische Hierarchie des MIT-Objektmodells.
Abbildung 2.
Management Information Tree (MIT)
Objekte im MIT
Bei der Cisco ACI kommt eine informationsmodellbasierte Architektur zum Einsatz, in der das Modell alle durch
einen Managementprozess kontrollierbare Informationen beschreibt. Objektinstanzen werden als verwaltete
Objekte (MOs) bezeichnet. Jedes verwaltete Objekt im System kann durch einen eindeutigen Distinguished Name
(DN) identifiziert werden. Auf diese Weise kann ein Objekt global referenziert werden.
Neben dem eindeutigen Namen kann ein Objekt auch anhand seines relativen Namens (RN) referenziert werden.
Der RN identifiziert ein Objekt im Verhältnis zu seinem übergeordneten Objekt. Der DN eines Objekts wird
gebildet, indem dessen RN an den DN des übergeordneten Objekts angehängt wird. DNs werden direkt URLs
zugeordnet. Der Zugriff auf ein Objekt ist je nach aktueller Position im MIT entweder anhand des RNs oder anhand
des DNs möglich. Die Beziehung zwischen verwalteten Objekten, relativen Namen und eindeutigen Namen ist in
Abbildung 3 dargestellt.
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 3 von 8
Abbildung 3.
Verwaltete Objekte, relative Namen und eindeutige Namen
Abbildung 3 zeigt den eindeutigen Namen, der eine Instanz eines verwalteten Objekts eindeutig repräsentiert, und
den relativen Namen, der das Objekt lokal unter seinem übergeordneten verwalteten Objekt repräsentiert. Alle
Objekte in der Baumstruktur sind dem Root-Objekt untergeordnet.
Da die Baumstruktur und das Attributsystem zur Identifizierung der Objektklassen hierarchisch aufgebaut sind,
können Informationen zu verwalteten Objekten auf verschiedene Weise abgefragt werden. Abfragen sind für ein
Objekt selbst anhand von dessen eindeutigen Namen, für eine Objektklasse wie Switch-Chassis oder für eine
Ebene der Baumstruktur möglich, wodurch alle Elemente eines Objekts ermittelt werden können. In Abbildung 4
sind zwei Abfragen auf Baumstrukturebene dargestellt.
Abbildung 4.
Abfragen auf Baumstrukturebene
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 4 von 8
In Abbildung 4 sind zwei Abfragen für Chassis auf Baumstrukturebene dargestellt. Beide Abfragen geben das
referenzierte Objekt und dessen untergeordnete Objekte zurück. Diese Methode eignet sich besonders zur
Ermittlung der Komponenten eines größeren Systems.
Anhand des Beispiels in Abbildung 4 werden die Karten und Ports eines bestimmten Switch-Chassis ermittelt.
Abbildung 5 zeigt einen weiteren Abfragetyp: die Abfrage auf Klassenebene.
Abbildung 5.
Abfragen auf Klassenebene
Wie in Abbildung 5 gezeigt, geben Abfragen auf Klassenebene alle Objekte einer bestimmten Klasse zurück. Diese
Methode eignet sich zur Ermittlung aller im MIT enthaltenen Objekte eines bestimmten Typs. In diesem Beispiel
wird die Klasse „Karten“ verwendet, sodass alle Objekte des Typs „Karten“ zurückgegeben werden.
Beim dritten Abfragetyp handelt es sich um die Abfrage auf Objektebene. Bei einer Abfrage auf Objektebene wird
ein bestimmtes Objekt anhand seines DNs zurückgegeben. Abbildung 6 zeigt zwei Abfragen auf Objektebene: eine
Abfrage von Knoten 1 in Chassis 2 und eine Abfrage von Knoten 1 in Chassis 1 in Karte 1 in Port 2.
Abbildung 6.
Abfragen auf Klassenebene
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 5 von 8
Bei allen MIT-Abfragen kann optional auch die gesamte Teilbaumstruktur oder wiederum ein Teil davon
zurückgegeben werden. Darüber hinaus gibt die rollenbasierte Zugriffskontrolle (RBAC) vor, welche Objekte
zurückgegeben werden: Nur diejenigen Objekte werden zurückgegeben, für die der Benutzer entsprechende
Rechte hat.
Eigenschaften verwalteter Objekte
Verwaltete Objekte in der Cisco ACI enthalten Eigenschaften, durch die sie definiert werden. Die Eigenschaften
verwalteter Objekte werden in Chunks unterteilt, die durch bestimmte Prozesse im Betriebssystem verwaltet
werden. Auf jedes Objekt können mehrere Prozesse zugreifen. Alle Eigenschaften zusammen werden zur Laufzeit
kompiliert und sind für den Benutzer als Einzelobjekt sichtbar. Abbildung 7 zeigt ein Beispiel für diese Beziehung.
Abbildung 7.
Eigenschaften verwalteter Objekte
In Abbildung 7 sind drei Prozesse vorhanden, die in Chunks der Eigenschaften des Beispielobjekts schreiben. Die
Datenmanagement-Engine (DME), die als Schnittstelle zwischen Cisco APIC (Benutzer) und Objekt fungiert, der
Portmanager, der die Portkonfiguration verwaltet, und das Spanning Tree Protocol (STP) interagieren mit den
Chunks dieses Objekts. Das Objekt selbst wird für den Benutzer über die API als Einzeleinheit dargestellt, die zur
Laufzeit kompiliert wird.
Zugriff auf die Objektdaten über REST-Schnittstellen
REST ist eine Softwarearchitektur für verteilte Systeme wie das World Wide Web. In den vergangenen Jahren hat
sich REST zum vorrangigen Designmodell für Webservices entwickelt. Andere Designmodelle, etwa Simple Object
Access Protocol (SOAP) und Web Services Description Language (WSDL), wurden aufgrund des einfacheren
Aufbaus von REST verdrängt. Der Cisco APIC unterstützt REST-Schnittstellen für den programmgesteuerten
Zugriff auf die gesamte Cisco ACI-Lösung.
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 6 von 8
Das objektbasierte Informationsmodell von Cisco ACI ist für REST-Schnittstellen sehr gut geeignet: URLs und
URIs werden den DNs zur Identifizierung von Objekten in der Baumstruktur direkt zugeordnet, und alle Daten im
MIT können als eigenständige Textdokumente mit Baumstruktur und XML- oder JSON-Verschlüsselung
(JavaScript Object Notation) beschrieben werden. Die Beziehungen aus über- und untergeordneten Objekten
werden anhand der DNs und Eigenschaften identifiziert, die durch entsprechende CRUD-Vorgänge (Create, Read,
Update, Delete bzw. Erstellen, Lesen, Aktualisieren, Löschen) gelesen und verändert werden.
Der Zugriff auf die Objekte ist anhand ihrer definierten Adressen (REST-URLs) über HTTP-Standardbefehle zum
Abrufen und Verändern der Cisco APIC-Objektdaten möglich. Dabei wird das folgende URL-Format verwendet:
<system>/api/[mo|class]/[dn|class][:method].[xml|json]?{options}
Diese URL besteht aus den folgenden Bausteinen:
●
System: System-ID, eine IP-Adresse oder ein im DNS auflösbarer Hostname
●
mo | class: Angabe, ob es sich um eine Abfrage auf Objekt- (MO), Baumstruktur- (MIT) oder Klassenebene
handelt
●
class: Klasse der abgefragten verwalteten Objekte (wie im Informationsmodell angegeben); Darstellung
des Klassennamens als <pkgName><ManagedObjectClassName>
●
dn: Distinguished Name (eindeutiger hierarchischer Name des Objekts in der MIT-Baumstruktur) des
abgefragten Objekts
●
method: Optionale Angabe der aufgerufenen Methode des Objekts (gilt nur für HTTP-POST-Anforderungen)
●
xml | json: Verschlüsselungsformat
●
options: Abfrageoptionen, Filter und Argumente
Durch die Möglichkeit zur Adressierung bestimmter Objekte oder Objektklassen anhand der REST-URL ist ein
vollständiger programmgesteuerter Zugriff auf die gesamte Objektbaumstruktur und somit auf das gesamte System
möglich.
Software Development Kits für Programmierumgebungen
Die REST-APIs für Cisco ACI lassen sich unabhängig von der verwendeten Sprache und Entwicklungsmethode
problemlos in jede Programmierumgebung integrieren. Um die Entwicklung in häufig verwendeten
Programmierumgebungen weiter zu beschleunigen, werden Software Development Kits (SDKs) für Cisco ACI zur
Verfügung gestellt. Cisco ACI-pysdk, ein Python-basiertes SDK, ist ein SDK für eine PythonProgrammierumgebung. Die Python-Bibliotheken und APIs im SDK abstrahieren entsprechende Aufrufe der
REST-API und ermöglichen so die schnelle und einfache Integration in Python-basierte Software-Suites.
Fazit
Das objektorientierte Datenmodell der Cisco ACI ist grundlegend auf Netzwerkprogrammierbarkeit ausgelegt. Das
Betriebssystem auf Geräteebene wurde als vollständig objektbasiertes Switch-Betriebssystem für die Cisco ACI
überarbeitet. Die Komponenten der Cisco ACI werden vom Cisco APIC verwaltet, der REST-APIs mit vollem
Funktionsumfang bietet. Diese API ist durch eine CLI und eine GUI für die tägliche Administration umgesetzt.
Das Objektmodell ermöglicht eine reibungslose Programmierbarkeit und umfassenden Zugriff auf die zugrunde
liegenden Komponenten der Infrastruktur über REST-APIs. Die Objekte sind logisch in einem hierarchischen
Modell aufgebaut und werden im MIT gespeichert. Durch dieses Konzept entsteht ein offenes Framework für die
Kontrolle und Programmierbarkeit des Netzwerks, das andere Systeme nicht liefern können.
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 7 von 8
Weitere Informationen
http://www.cisco.com/go/aci.
Gedruckt in den USA
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
C11-729999-00
11/13
Seite 8 von 8