Whitepaper
Prinzipien der Application Centric Infrastructure
Übersicht
Eine der wichtigsten Innovationen der Application Centric Infrastructure (ACI) ist die Einführung einer
hochabstrakten Schnittstelle für die Verbindung von Anwendungskomponenten sowie die entsprechenden
übergeordneten Richtlinien. Das Modell ist darauf ausgelegt, dass Anwendungsentwickler es problemlos umsetzen
können und gleichzeitig Automatisierungsgrad und Sicherheit erhöht werden.
Richtlinientheorie der ACI
Das Richtlinienmodell der ACI ist objektorientiert und basiert auf der „Promise Theory“. Die Promise Theory basiert
wiederum auf der skalierbaren Kontrolle intelligenter Objekte – im Gegensatz zu herkömmlichen Zwangsmodellen,
die als Top-Down-Managementsystem beschrieben werden können. In einem solchen System muss der Central
Manager sowohl die Konfigurationsbefehle der zugrunde liegenden Objekte als auch ihren jeweiligen aktuellen
Status kennen.
Bei der Promise Theory wird dagegen davon ausgegangen, dass die zugrunde liegenden Objekte vom
Kontrollsystem ausgehende Änderungen des Konfigurationsstatus als „gewünschte Statusänderungen“ behandeln.
Die Objekte geben dann Ausnahmen oder Fehler an das Kontrollsystem weiter. Dieser Ansatz entlastet und
vereinfacht das Kontrollsystem und ermöglicht eine größere Skalierung. Dieses System kann noch weiter skaliert
werden, indem die Methoden zugrunde liegender Objekte Statusänderungen voneinander und von
untergeordneten Objekten anfordern können (Abbildung 1).
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 1 von 8
Abbildung 1.
Promise Theory-Ansatz zur Kontrolle umfangreicher Systeme
In diesem theoretischen Modell stellt die ACI ein Objektmodell für die Bereitstellung von Anwendungen dar, wobei
die Anwendungen im Mittelpunkt stehen. Bisher wurden Anwendungen durch die Netzwerkfunktionen und durch
Maßnahmen zum Schutz vor Missbrauch der Richtlinienstrukturen eingeschränkt. Konzepte wie Adressierung,
VLAN und Sicherheit wurden miteinander verknüpft, wodurch Skalierung und Mobilität der Anwendungen begrenzt
wurden. Da immer mehr Anwendungen für Mobilität und Web optimiert werden, steht dieser bisherige Ansatz einer
schnellen und konsistenten Bereitstellung im Weg.
Das ACI-Richtlinienmodell enthält keine Vorgaben hinsichtlich der Struktur des zugrunde liegenden Netzwerks.
Gemäß Promise Theory ist jedoch für das Management der Verbindungen mit verschiedenen Geräten ein EdgeElement erforderlich, das als „iLeaf“ bezeichnet wird.
Objektmodell
Auf der obersten Ebene basiert das ACI-Objektmodell auf einer Gruppe von Tenants, die eine Trennung von
Administration der Netzwerkinfrastruktur und Datenflüssen ermöglicht. Je nach Geschäftsanforderungen können
die Tenants für Kunden, Geschäftsbereiche oder Gruppen verwendet werden. So kann in einem Unternehmen ein
Tenant für das gesamte Unternehmen verwendet werden. Die Kunden eines Cloud-Providers könnten dagegen
einen oder mehrere Tenants zur Darstellung ihrer jeweiligen Unternehmen verwenden.
Die Tenants lassen sich weiter in Kontexte unterteilen, die sich direkt auf VRF-Instanzen (Virtual Routing and
Forwarding) oder separate IP-Adressräume beziehen. Je nach Geschäftsanforderungen kann jeder Tenant einen
oder mehrere Kontexte enthalten. Mithilfe der Kontexte lassen sich die Unternehmens- und
Weiterleitungsanforderungen eines Tenants weiter aufteilen. Da Kontexte separate Weiterleitungsinstanzen
verwenden, kann die IP-Adressierung für Multi-Tenant-Umgebungen in separaten Kontexten dupliziert werden.
Innerhalb des Kontexts enthält das Modell eine Reihe von Objekten, die wiederum die Anwendung definieren. Bei
diesen Objekten handelt es sich um die Endpunkte (EP), Endpunktgruppen (EPG) und die Richtlinien, die deren
Beziehung definieren (Abbildung 2). In diesem Fall bestehen Richtlinien nicht nur aus verschiedenen
Zugriffskontrolllisten (ACLs), sondern enthalten auch Ein- und Ausgangsfilter, Einstellungen zur
Datenverkehrsqualität, Markierungsregeln und Umleitungsregeln.
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 2 von 8
Abbildung 2.
Logisches Objektmodell
Abbildung 2 zeigt einen Tenant mit zwei Kontexten und den Anwendungen, die diesen Kontext darstellen. Die
gezeigten EPGs sind Gruppen von Endpunkten, die eine Anwendungsebene oder eine andere logische
Anwendungsgruppierung darstellen. Beispielsweise könnte Anwendung B (in der Abbildung rechts erweitert
dargestellt) aus einer Webebene (blau), einer Anwendungsebene (rot) und einer Datenbankebene (orange)
bestehen. Die Kombination aus EPGs und den ihre Interaktion definierenden Richtlinien entspricht im ACI-Modell
einem anwendungsbezogenen Netzwerkprofil.
Endpunktgruppen
Eine EPG ist eine Zusammenstellung ähnlicher Endpunkte, die einer Anwendungsebene oder Servicegruppe
entsprechen. Diese stellen eine logische Gruppierung von Objekten mit ähnlichen Richtlinien dar. Eine EPG könnte
beispielsweise die Komponentengruppe darstellen, aus denen die Webebene einer Anwendung besteht.
Endpunkte werden über die Netzwerkkarte (NIC), virtuelle NIC (vNIC), IP-Adresse oder den DNS-Namen (Domain
Name System) definiert, wobei auch zukünftige Methoden zur Identifizierung der Anwendungskomponenten
unterstützt werden sollen.
EPGs können auch andere Einheiten darstellen, z. B. externe Netzwerke, Netzwerkservices, Sicherheitsgeräte
oder Netzwerkspeicher. Eine EPG ist eine Zusammenstellung von Endpunkten mit ähnlicher Funktion. Diese
stellen eine logische Gruppierung mit verschiedenen Anwendungsoptionen dar, die vom verwendeten
Bereitstellungsmodell abhängig sind (Abbildung 3).
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 3 von 8
Abbildung 3.
Beziehungen von Endpunktgruppen
EPGs sind auf Flexibilität ausgelegt, sodass ihre Anwendung an das vom Kunden ausgewählte
Bereitstellungsmodell angepasst werden kann. Mit ihrer Hilfe werden die Elemente definiert, auf die Richtlinien
angewendet werden sollen. Innerhalb der Netzwerkstruktur werden Richtlinien zwischen EPGs angewendet, um
deren Kommunikationsweise zu definieren. Dieser Ansatz ist dahingehend auf Erweiterbarkeit ausgelegt, dass
Richtlinien zukünftig auch innerhalb der EPGs angewendet werden können.
Anwendungsbeispiele für EPGs:
●
Durch herkömmliche Netzwerk-VLANs definierte EPG: alle mit einem bestimmten VLAN verbundenen
Endpunkte in einer EPG zusammengefasst
●
Durch VXLAN (Virtual Extensible LAN) definierte EPG: wie bei VLANs, aber unter Verwendung eines
VXLANs
●
Einer VMware-Portgruppe zugeordnete EPG
●
Durch IP-Adresse oder Subnetz definierte EPG: z. B. 172.168.10.10 oder 172.168.10
●
Durch DNS-Namen oder DNS-Bereiche definierte EPG: z. B. example.foo.com oder *.web.foo.com
Die Anwendung von EPGs ist flexibel und erweiterbar. Das Modell bietet entsprechende Tools zur Entwicklung
eines Modells für das Anwendungsnetzwerk, das zum Bereitstellungsmodell der tatsächlichen Umgebung passt.
Die Definition der Endpunkte ist ebenfalls erweiterbar und unterstützt zukünftige Produkterweiterungen und
Branchenanforderungen.
Das EPG-Modell bietet mehrere Managementvorteile. So bietet es ein Objekt mit einer einheitlichen Richtlinie für
Automatisierungs- und Orchestrierungstools auf höherer Ebene. Zum Ändern der Richtlinien müssen die einzelnen
Endpunkte nicht bearbeitet werden. Darüber hinaus kann die Konsistenz über alle Endpunkte hinweg unabhängig
von deren Position im Netzwerk sichergestellt werden.
Richtliniendurchsetzung
Die Beziehung zwischen EPGs und Richtlinien kann als Matrix veranschaulicht werden, in der eine Achse die
Quell-EPG (sEPG) und die andere die Ziel-EPG (dEPG) darstellt. Am Schnittpunkt der entsprechenden sEPG und
dEPG werden eine oder mehrere Richtlinien platziert. In den meisten Fällen enthält die Matrix nur wenige Einträge,
da viele EPGs nicht miteinander kommunizieren müssen (Abbildung 4).
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 4 von 8
Abbildung 4.
Matrix zur Richtliniendurchsetzung
Die Richtlinien werden durch Filter für Quality of Service (QoS), Zugriffskontrolle, Serviceeinbindung usw.
aufgeteilt. Bei diesen Filtern handelt es sich um bestimmte Regeln für eine Richtlinie zwischen zwei EPGs. Die
Filter bestehen aus Eingangs- und Ausgangsregeln: Zulassen, Verweigern, Umleiten, Protokollieren, Kopieren und
Markieren. In den Richtliniendefinitionen sind auch Wildcards (Platzhalter) zulässig (Abbildung 5). Bei der
Richtliniendurchsetzung gilt in der Regel der Grundsatz „genauester Treffer zuerst“.
Abbildung 5.
Regeln zur Durchsetzung von Wildcards
Anwendungsbezogene Netzwerkprofile
Ein anwendungsbezogenes Netzwerkprofil ist eine Zusammenstellung von EPGs, deren Verbindungen und den
dazugehörigen Richtlinien. Bei anwendungsbezogenen Netzwerkprofilen handelt es sich um die logische
Darstellung einer Anwendung und ihrer Abhängigkeiten in der Netzwerkstruktur.
Anwendungsbezogene Netzwerkprofile sind logisch aufgebaut und entsprechen dem Design und der Bereitstellung
der Anwendungen. Konfiguration und Durchsetzung von Richtlinien und Verbindungen werden vom System und
nicht manuell von einem Administrator vorgenommen. Abbildung 6 zeigt ein Beispiel für ein Zugriffsprofil.
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 5 von 8
Abbildung 6.
Anwendungsbezogene Netzwerkprofile
Zur Erstellung eines anwendungsbezogenen Netzwerkprofils sind die folgenden allgemeinen Schritte erforderlich:
1.
Erstellen von EPGs (wie weiter oben beschrieben).
2.
Erstellen von Richtlinien zur Definition der Verbindung mit folgenden Regeln:
3.
●
Zulassen
●
Ablehnen
●
Protokollieren
●
Markieren
●
Umleiten
●
Kopieren
Erstellen von Verbindungspunkten zwischen EPGs mittels Richtlinienstrukturen, die als „Contracts“ bezeichnet
werden.
Contracts
Contracts definieren neben Regeln für Zulassen, Verweigern und QoS-Regeln auch Richtlinien wie Umleiten. Je
nach Anforderungen der Umgebung ermöglichen Contracts einfache oder komplexe Definitionen der
Kommunikationsweise zwischen EPGs. Contracts werden zwar zwischen EPGs durchgesetzt, sind aber über eine
Provider-Verbraucher-Beziehung mit EPGs verbunden. Im Wesentlichen stellt eine EPG einen Contract bereit
(„provide“), den andere EPGs nutzen („verbrauchen“).
Das Provider-Verbraucher-Modell eignet sich für verschiedene Zwecke. Es bietet ein natürliches „Schutzschild“ für
Anwendungsebenen, das die Interaktionsweise der Ebene mit anderen Teilen der Anwendung vorgibt. So kann
etwa ein Webserver, der über HTTP oder HTTPS kommunizieren kann, in einen Contract eingebunden werden,
der nur diese beiden Protokolle zulässt. Darüber hinaus fördert das Provider-Verbraucher-Modell die Sicherheit,
indem einfache, konsistente Richtlinienupdates für einzelne Richtlinienobjekte statt für mehrere Verbindungen
eines Contracts möglich sind. Contracts tragen außerdem zur Vereinfachung bei, da Richtlinien nur einmal definiert
werden müssen und anschließend mehrmals verwendet werden können (Abbildung 7).
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 6 von 8
Abbildung 7.
Contracts
Abbildung 8 zeigt die durch EPG-Verbindung definierte Beziehung zwischen den drei Ebenen einer
Webanwendung und die Contracts, die ihre Kommunikationsweise bestimmen. Aus der Summe dieser Einzelteile
ergibt sich ein anwendungsspezifisches Netzwerkprofil. Contracts können mehrmals verwendet werden und
ermöglichen konsistente Richtlinien für Services, die in der Regel mit mehreren EPGs kommunizieren.
Abbildung 8.
Vollständiges anwendungsspezifisches Netzwerkprofil
Fazit
Dieses Dokument enthält lediglich eine Einführung in das ACI-Richtlinienmodell mit einer näheren Beschreibung
der ACI und der Anwendung des Richtlinienmodells. Dieses Modell enthält eine Reihe weiterer Strukturen und
Objekte, die aus Gründen der Einfachheit hier nicht behandelt werden.
Weitere Informationen
Weitere Informationen finden Sie unter http://www.cisco.com/go/aci.
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
Seite 7 von 8
Gedruckt in den USA
© 2013 Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco.
C11-729906-00
11/13
Seite 8 von 8