Prinzipien der Application Centric Infrastructure

Transkript

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

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

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

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

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

6 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: Zulassen Ablehnen Protokollieren Markieren Umleiten Kopieren 3. 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) Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco. Seite 6 von 8

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

8 Gedruckt in den USA C / Cisco und/oder Partnerunternehmen. Alle Rechte vorbehalten. Dieses Dokument enthält öffentliche Informationen von Cisco. Seite 8 von 8