Programmierbarkeit von Netzwerken mit Cisco Application Centric Infrastructure

Transkript

1 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 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco. Seite 1 von 8

2 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

3 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 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco. Seite 3 von 8

4 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

5 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

6 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 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco. Seite 6 von 8

7 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 Python- Programmierumgebung. 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 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco. Seite 7 von 8