Cisco bereitet allgemeine Verfügbarkeit von ACI vor: Überblick

Transkript

1 Cloud-fähige Zweigstellennetzwerke Cisco bereitet allgemeine Verfügbarkeit von ACI vor: Überblick Von Nicholas John Lippis III President, Lippis Consulting August 2014

2 Einer der wichtigsten Termine im Netzwerkbereich ist diesen August die allgemeine Verfügbarkeit der Cisco ACI (Application Centric Infrastructure). Seit November 2013 liefert Cisco den Nexus-Switch der Serie 9000 im sogenannten Standalone-Modus aus, einen extrem schnellen Ethernet-Switch für Rechenzentren. Die Bestellungen für Nexus 9000 hatten sich von 180 im 3. auf 580 am Ende des 4. Geschäftsquartals von Cisco verdreifacht. Bei der Einführung des Nexus 9000 hatte Cisco angekündigt, dass sich diese Switches im sogenannten ACI- Fabric-Modus bereitstellen lassen. Dieser Modus verspricht reduzierte Betriebskosten, höhere Flexibilität und eine revolutionierte Anbindung von Anwendungen an die Netzwerkinfrastruktur. Dieser Fabric-Modus nimmt mit der jetzt allgemein verfügbaren ACI Gestalt an. In dieser Lippis Report Studie soll untersucht werden, welche Vorteile die ACI Rechenzentrumsarchitekten heute bieten kann. Die ACI besteht aus drei Grundbausteinen: 1) einem Richtlinienmodell als organisatorisches Prinzip zur Gruppierung von Geräten in containerartige Strukturen und zur Beschreibung ihrer Verbindung, 2) dem APIC (Application Policy Infrastructure Controller) als zentrale Verwaltungsstelle und Repository für alle beschriebenen Richtlinien, und 3) der ACI-Fabric als Abstraktion aller physischen und virtuellen Netzwerkgeräte. Im Folgenden wird eine kurze Übersicht über die drei ACI-Komponenten gegeben. Datenbankebene benötigt möglicherweise auch eine Verbindung nach außen. Die Richtlinie zur Beschreibung der Anbindungsanforderungen dieser Anwendung kann mithilfe gruppenbasierter Richtlinien direkt in der ACI definiert werden; das Modell kann jedoch ebenso sehr allgemein gehalten werden. Über die Richtlinie können auch sicherheitsorientierte Richtlinien definiert werden, wobei z. B. eine externe Gruppe (externer Standort und Internet- Datenverkehr) mit der DMZ-Gruppe und diese mit der internen Gruppe verbunden wird. Alternativ können über eine GBP die meisten heute bestehenden Netzwerke modelliert werden, bei denen VLANs und/oder Subnetze verschiedenen Gruppen zugeteilt werden. Cisco verfolgt das Ziel, dieses Konzept der gruppenbasierten Richtlinien verschiedenen Interessengruppen näherzubringen, sodass für die Anbindung kein Cisco Certified Internetwork Expert (CCIE) oder Netzwerkexperte benötigt wird. Ein Administrator muss diese Komponentengruppe lediglich mit einer anderen Komponentengruppe verbinden. Cisco bezeichnet diese beliebigen Komponentengruppen als Endgerätegruppen (End Point Group, EPG), d. h. Sammlungen physischer oder virtueller Endgeräte. Eine EPG könnte also physische Services, Bare Metal-Server, virtuelle Systeme auf verschiedenen Hypervisoren usw. enthalten. Dabei können Komponenten relativ flexibel Gruppen zugeteilt werden, unabhängig von ihrer Position innerhalb der ACI- Fabric. Richtlinienmodell: Das Richtlinienmodell der ACI ist eine neue Methode zur Beschreibung der Anbindung anhand eines Konzepts, das Cisco als Gruppenbasierte Richtlinie (Group-Based Policy, GBP) bezeichnet. Das Richtlinienmodell von Cisco bietet eine allgemeine Methode zur Beschreibung der Verbindungen zwischen Komponenten. Beispiel: Eine typische, in einem Rechenzentrum bereitgestellte dreistufige Anwendung mit Front-End- Webebene, Middleware-Anwendungsebene und Back-End- Ein weiteres zentrales Konzept des ACI-Richtlinienmodells besteht in der Möglichkeit, die Beziehung zwischen EPGs zu definieren. Diese Beziehung wird als Contract bezeichnet und beschreibt die zulässigen Verbindungsmethoden zwischen EPGs. Ein Contract kann etwa ein bestimmtes Protokoll oder eine Gruppe von Protokollen enthalten, die zwischen Gruppen genutzt werden können, oder den Einsatz eines Layer-4-7-Servicediagramms für Netzwerkservices wie Firewalls, Load Balancern usw. zwischen Gruppen vorsehen. 1

3 Hinsichtlich Sicherheit wird beim ACI-Richtlinienmodell im Wesentlichen ein Whitelist-Modell angewendet, das sich erheblich von der herkömmlichen Implementierung von ACLs unterscheidet. Beim Netzwerkbetrieb wird heute davon ausgegangen, dass nahezu alle Komponenten kommunizieren können und nur diejenigen, die dazu nicht in der Lage sind, durch ACLs beschränkt werden sollten (Blacklist-Sicherheitsmodell). Die gesamte ACI-Fabric kann aus betrieblicher Sicht als eine verteilte kontextbasierte Firewall beschrieben werden, die Richtlinien ganzheitlich im gesamten Rechenzentrum durchsetzt. Cisco fasst diese Definitionen von EPGs, Contracts und externen Netzwerken in sogenannten anwendungsbezogenen Netzwerkprofilen (Application Network Profile, ANP) zusammen. Diese ANPs sind vollständig von der zugrunde liegenden physischen/virtuellen Infrastruktur losgelöst und können daher auch in andere ACI- Fabrics kopiert und erneut instanziiert werden. Dies erleichtert ganz erheblich die globale Definition der Anwendungsanbindung für mehrere PODs oder Standorte, ohne dass der Anwendungsadministrator die genaue Architektur einer bestimmten Fabric kennen muss. APIC: Die ACI-Richtlinien werden im APIC (Application Policy Infrastructure Controller) beschrieben. Der APIC ist ein Cluster von x86-rack-servern der UCS C-Serie (je 1 HE) und fungiert als zentrale Verwaltungsstelle und als Repository für alle beschriebenen Richtlinien sowie alle weiteren Richtlinien, die zur Bereitstellung, Administration, Überwachung und Fehlerbehebung der Fabric erforderlich sind. Cisco fasst sozusagen alles in Richtlinien zusammen. Der APIC erfüllt jedoch keine Weiterleitungs- oder Suchfunktionen. Nach der Richtliniendefinition könnte der APIC theoretisch vollständig entfernt werden, ohne dass die Funktion beeinträchtigt würde. Hier soll jedoch betont werden, dass der APIC nicht für Weiterleitungsvorgänge benötigt wird. Cisco empfiehlt allerdings nicht, das APIC-Cluster vollständig zu entfernen, da Administratoren die Richtlinien dann nicht mehr verändern könnten, solange kein APIC verbunden ist. Das APIC-Cluster ist vollständig redundant und dient gleichzeitig dem Load Balancing, wobei ein Dauerbetrieb von drei APIC-Appliances für das Cluster empfohlen wird. Das gesamte ACI-System ist als Objektmodell konzipiert, wobei die Objekte im sogenannten verteilten Managementinformationsbaum (distributed Management Information Tree, dmit) strukturiert werden und Eigenschaften (Sicherheitsberechtigungen oder Attribute usw.) von übergeordneten Objekten übernehmen. Diese Objekte sind über den APIC anhand von Methoden wie REST-APIs (XML/JSON), grafischen Benutzeroberflächen (GUIs) oder eine Kommandozeilen-Shell (einer Linux BASH- Umgebung ähnlich) northbound zugänglich. Alternativ bietet Cisco auch Software Development Kits (SDKs) an, mit denen Anwendungen zur direkten Interaktion mit dem ACI- Richtlinienmodell entwickelt werden können. Mit der allgemeinen Verfügbarkeit liefert und unterstützt Cisco auch ein Python-SDK, das sich auch als Ruby- und C#-Variante bereits in der Entwicklung befindet. ACI-Fabric: Die ACI-Fabric ist im Wesentlichen eine Sammlung physischer und virtueller Geräte (Netzwerk- Fabric), in der alle Datenebenenfunktionen wie Suche, Weiterleitung, Durchsetzung von Richtlinien usw. verarbeitet werden. Diese Geräte können auch Weiterleitungsservices (z. B. Switches und Router) und/oder L4-7-Netzwerkservices (z. B. Firewalls, Load Balancer usw.) bereitstellen. Kernstück der ACI-Fabric sind die neuen High-End-Switches der Serie Nexus 9000 von Cisco, die in einer Spine-Leaf- Topologie konfiguriert werden und eine skalierbare Anbindung, Leistung, Ausfallsicherheit und Flexibilität bieten. Mit der allgemeinen Verfügbarkeit bietet Cisco zwei Varianten von Leaf-Switches an: Nexus 9396PX: 48 SFP+-Ports für 1/10G sowie weitere 12 QSFP-Uplink-Ports für 40G Nexus 93128TX: 96 Ports für 1/10G Base-T sowie weitere 8 QSFP-Uplink-Ports für 40G Außerdem bietet Cisco die folgenden zwei Varianten von Spine-Switches an: Nexus 9336PQ: 36 QSFP-Ports für 40G mit Links zu den Leaf-Switches Nexus 9508: bis zu 288 QSFP-Ports für 40G mit Links zu den Leaf-Switches 2

4 Cisco plant außerdem in Kürze weitere Formfaktoren von Spine- und Leaf-Switches, darunter 1-HE-Leaf-Switches und sowohl kleinere (Nexus 9504 mit 4 Steckplätzen) als auch größere (Nexus 9516 mit 16 Steckplätzen) Spine-Switches. Aus Sicht des Netzwerkdesigns werden alle Geräte mit den Leaf-Switches verbunden. Mit den Spine-Switches werden lediglich die anderen Leaf-Switches verbunden. Cisco setzt IPv4-Routing in der Fabric als Underlay -Protokoll und ein hardwarebasiertes Virtual extensible LAN (VXLAN) als Overlay -Kapselung ein, um Bridging und Routing zwischen beliebigen Layer-2- und Layer-3-Geräten in der gesamten ACI-Fabric zu ermöglichen. Ein wichtiger Punkt ist, dass die ACI-Fabric auch beliebige virtuelle Switches (vswitches) auf verschiedenen integrierten Hypervisoren steuern kann, z. B. VMware über vcenter, Microsoft über SCVMM (System Center Virtual Machine Manager) mit Windows Server 2012 R2 oder OVS über OpenStack (mit Ubuntu oder Red Hat-Varianten). Darüber hinaus kann die ACI-Fabric über als Gerätepakete bezeichnete Plug-ins Netzwerkservices steuern, wobei der APIC Orchestrierung, Automatisierung und Verkettung von L4-7-Services erleichtert. Sämtliche Richtlinien werden auch auf diese Netzwerkservices angewendet, sodass Administratoren diese Geräte nicht separat verwalten müssen. Die ACI-Fabric kann also über die Nexus Plattformen von Cisco hinaus erweitert werden, deckt aber auch alle anderen Services ab, mit denen sie integriert werden kann. Implementierung der ACI: Integritätsbewertung Ein zentraler Punkt des ACI-Ansatzes von Cisco ist, dass mit der allgemeinen Einführung auch verschiedene Tools angeboten werden, die Administratoren von Rechenzentren bei der Implementierung einer Cisco ACI-Bereitstellung unterstützen. Eines dieser Tools ist die Integritätsbewertung. Neben einer optimierten Möglichkeit zur Bereitstellung der ACI-Fabric verfolgte Cisco das Ziel, die alltäglichen Management- und Betriebsvorgänge zu optimieren. Nach der Konfiguration und Einrichtung der ACI müssen Administratoren die Fabric überwachen können, um zu beurteilen, inwiefern sie die Erwartungen erfüllen kann. Die Integritätsbewertung bietet verschiedenen Administratoren eine elegante Möglichkeit, problematische Bereiche sehr spezifisch und detailliert zu überwachen. Da alle Geräte innerhalb der ACI-Fabric wie oben erwähnt als Objekte behandelt werden, kann die ACI für die meisten Objekte im Objektbaum eine Integritätsbewertung vornehmen. Diese Integritätsbewertungen können auch über den Baum aggregiert werden, d. h. eine Bewertung kann etwa für bestimmte Tenants oder für die gesamte Fabric ermittelt werden. Bei diesem fraktalen Modell wird eine übergeordnete Bewertung erstellt, und der Administrator kann die Details für einzelne Geräte und Komponenten oder Gerätefunktionen einsehen, z. B. Ports oder sogar bestimmte Protokolle. Beispiel: Die Integritätsbewertung der gesamten ACI-Fabric beträgt sehr gute 99 %, ändert sich jedoch, sobald bei einem Bestandteil der Fabric eine Verschlechterung eintritt. Dabei könnte es sich z. B. um einen fehlerhaften oder ausgefallenen Port oder ein virtuelles System auf einem ESX-Host mit einer sehr hohen CPU-Zyklusauslastung handeln. Wenn Fehler auftreten, lösen diese bestimmte Ereignisse aus. Die dadurch verursachte Verschlechterung der Integritätsbewertung bestimmter Objekte gibt Administratoren eine sichtbare Warnung. Diese Bewertungen werden über den Baum aggregiert, bis schließlich die Bewertung der gesamten Fabric durch die zugrunde liegenden Objektbewertungen negativ beeinflusst wird. Wer mit dem Betrieb und der Administration von Netzwerken in Rechenzentren vertraut ist, kennt die Schwierigkeiten bei der Ermittlung einer Problemursache ohne aussagekräftigen Kontext. Die Integritätsbewertungen bieten außer Kontext auch ein Bewertungssystem, wobei 100 % der besten Wertung entspricht. 3

5 bezeichnet) oder zwischen bestimmten Eingangs-/Ausgangs- Uplink-Ports (von Cisco als Trail bezeichnet) Pakete verworfen wurden. Anhand dieser Informationen können Administratoren den Paketfluss innerhalb der gesamten Fabric nachverfolgen und den Umfang dieser Paketflüsse zwischen Quellen und Zielen ermitteln. NetOps-Mitarbeiter könnten nun argumentieren, dass sich durch Ausführen von Skripten zur Automatisierung der Erfassung und Verarbeitung regelmäßiger Netzwerkstatistiken ein ähnliches System schaffen ließe so einfach ist es jedoch nicht. Zwar lässt sich mit Skripten ein Großteil der Komplexität vorhandener Netzwerke verbergen, aber die Entwicklung von Skripten für jede einzelne betriebliche Netzwerkkomponente wäre extrem aufwändig. Dazu wären nicht nur sehr umfassende DevOps-Kenntnisse erforderlich; auch eine Skalierung auf große Umgebungen wäre kaum möglich. Beim Konzipieren der ACI entwickelte Cisco noch vor der Hardware und Software des Systems das objektorientierte Datenmodell zur Unterstützung dieser Funktionen. Dieses Modell unterstützt nicht nur das Bereitstellen und Löschen, wenn Administratoren Objekte erstellen und entfernen, sondern liefert auch fortlaufende Informationen zu den Attributen einzelner Objekte, anhand derer Administratoren den Objektstatus überwachen können. Dadurch ist dieses Modell skalierbarer und leistet außerdem einen wesentlichen Beitrag zur Senkung der Betriebskosten, während zudem die Zeit zur Behebung von Problemen verkürzt wird. Transparenz und Fehlerbehebung: Atomare Zähler Eine weitere wichtige Betriebsfunktion ist ein Fehlerbehebungs- und Analysetool, das Cisco als atomare Zähler bezeichnet. Atomare Zähler äußern sich auf verschiedene Weise, wurden von Cisco aber als spezifische Funktion in die Hardware integriert, um bei Aktivierung Leistungseinbußen zu verhindern. Cisco plant zudem die Implementierung atomarer Zähler in seinen Software-Switch, den Cisco Application Virtual Switch (AVS), sowie möglicherweise auch in weitere offene Software-Switches. Wie funktionieren atomare Zähler? Ihre Funktionsweise ist im Prinzip sehr einfach, dafür aber umso wertvoller. Atomare Zähler zählen alle ein- und ausgehenden Pakete in der Fabric, ermitteln aber gleichzeitig auch den Paketkontext. Bisher war es sehr schwierig, den Datenverkehr innerhalb von Netzwerken transparent zu machen. Bei der ACI-Fabric soll dies grundsätzlich anders werden, indem die atomaren Zähler den ein- und ausgehenden Datenverkehr in der Fabric und innerhalb der oben erwähnten Richtliniengruppen nachverfolgen. Eingehende Pakete werden am ersten Eingangspunkt in der ACI-Fabric getaggt; am Ausgangspunkt werden diese Tags wieder entfernt. Diese getaggten Pakete dienen als Quelle für die Nachverfolgung und Zählung durch die atomaren Zähler. Mithilfe der atomaren Zähler können Administratoren sehr schnell ermitteln, ob für ein bestimmtes Eingangs-/Ausgangs-Leaf-Paar (von Cisco als Pfad Cisco hat eine nützliche Grafik zur Darstellung der von den atomaren Zählern erfassten Daten in Form einer Heatmap entwickelt, in der die prozentuale Auslastung der Paketflüsse zwischen verschiedenen Pfaden und Trails gezeigt wird. Die Auslastung wird farbcodiert dargestellt, sodass Bereiche mit hoher/mittlerer/niedriger Auslastung schnell erkennbar sind. Diese Informationen sind nützlich, um Paketverluste in der Fabric zu erkennen und um die Platzierung zusätzlicher Workloads in der Fabric zu planen. Eine der größten Herausforderungen bei der Diagnose von Netzwerkproblemen besteht in der Korrelation von Informationen zu verschiedenen Geräten und Managementsystemen. Häufig interagiert das NetOps- Personal über eine Reihe von CLI-Befehlen wie show ip arp, show mac-address usw. mit verschiedenen Geräten. Diese Informationen müssen anschließend (meist auf Papier) nachverfolgt werden, um den Netzwerkpfad ermitteln zu können. Die Detailfunktion der atomaren Zähler macht diesen lästigen und zeitraubenden Prozess überflüssig und zeigt direkt die Ursache des Problems auf. In diesen Szenarien erleichtern die atomaren Zähler die Fehlerbehebung im gesamten System. Administratoren können nach bestimmten Tenants, EPGs, Endgeräten usw. filtern und nur die Pakete zählen lassen, die bestimmten Kriterien entsprechen. Verknüpfen von Anwendungen mit Netzwerkservices Besonders interessant für Infrastrukturadministratoren ist die Frage, wie anwendungsbezogene Netzwerkprofile (Application Network Profiles, ANPs) mit Netzwerkservices verknüpft werden können, wobei L4-7-Netzwerkservices als physische Appliances, virtualisierte Formfaktoren oder beides instanziiert werden können. Die ACI bietet mehrere Möglichkeiten zur Behebung dieses Designproblems und verringert die Anzahl der Verwaltungsstellen auf genau eine. Um einen L4-7-Netzwerkservice mit einem ANP zu verknüpfen, muss der Administrator nicht mit verschiedenen Geräteschnittstellen oder Managementsystemen interagieren. Im Rahmen der Modellierung der ACI-Fabric hat Cisco diese L4-7-Services als Teil des oben beschriebenen gruppenbasierten Richtlinienmodells ausgelegt. Ein weiterer enormer Vorteil des ACI-Fabric-Modells zur Verknüpfung von L4-7-Services mit ANPs besteht in der Ortsunabhängigkeit 4

6 der L4-7-Services, d. h. diese können überall in der Fabric eingesetzt werden, sodass nach dem Verknüpfen der Servicefunktion mit dem ANP die Fabric automatisch die Position des Services ermittelt und alle Kapselungen für die Serviceknoten bereitstellt, um die Datenpfadweiterleitung zu automatisieren. Cisco stellt diese L4-7-Servicefunktionen als Servicediagramm dar, das eine oder mehrere Servicefunktionen (Firewall, Load Balancer usw.) enthalten kann. Diese Servicediagramme können in die Definition des ANP integriert werden, um ein bestimmtes ANP-Verhalten zu erzielen. Durch Integration von L4-7-Servicediagrammen in das ANP kann der Administrator oder Sicherheitsauditor beispielsweise auf oberster Ebene erkennen, dass sämtlicher HTTP/S-Datenverkehr an die Web-EPG in der ACI-Fabric zunächst ein bestimmtes Firewall-Servicediagramm durchlaufen muss. Oder vor dem Eintritt in die EPG der Back-End-Datenbank muss ein Datenfluss ein Load Balancing-Servicediagramm durchlaufen. Der Cisco ACI- Ansatz der ANP-Verknüpfung mit Netzwerkservices beseitigt einen Großteil des Zeitaufwands bei der Bereitstellung von IT-Services: Zwar dauerte die Einrichtung eines virtuellen Systems nur Minuten, die Konfiguration des Netzwerks und der L4-7-Netzwerkservices dagegen Wochen oder Monate. Derzeit ermöglicht die Cisco ACI die Integration mit den Firewalls Cisco ASA und ASAv sowie mit Load Balancern von Citrix und F5. Die Gerätepakete für die entsprechenden Serviceknoten stehen auf den Websites der jeweiligen Anbieter zur Verfügung. Cisco plant die Entwicklung weiterer Gerätepakete zusammen mit mehr als einem Dutzend L4-7- Serviceanbietern. Eine aktuelle Liste der ACI- Netzwerkpartner ist auf der Cisco ACI-Seite unter zu finden. Serviceverkettung und Replikation Für die Integration von L4-7-Services gibt es zwei grundlegende Ansätze: die logische Unterteilung physischer Netzwerkservices in mehrere Kontexte für jeden Tenant oder die Dedizierung einzelner virtueller Services für jeden Tenant. Die ACI unterstützt beide Ansätze, da die meisten IT- Abteilungen und Cloud Provider beide benötigen. So muss in den meisten Unternehmen etwa der Datenverkehr vor Eintritt in die Definition einer Unternehmensanwendung eine Perimeter-Firewall durchlaufen. Diese Firewall-Funktion wird in der Regel streng kontrolliert und gesichert, fast wie eine Luftschleuse bei Raumschiffen oder U-Booten. In den letzten Jahren stellte sich jedoch heraus, dass statt einer solchen Luftschleuse vielmehr ein physisches Gerät als Kontrollpunkt für die Richtlinien benötigt wurde. In diesem Szenario ermöglicht die ACI die Integration der Firewall- Plattformen von Cisco und anderen Anbietern in die ACI- Fabric. Unternehmen mit strengeren Sicherheitsrichtlinien bevorzugen dieses Architekturmodell, da sie virtualisierten Firewalls als Schutz vor Bedrohungen in der DMZ weniger Vertrauen entgegenbringen. Stattdessen vertrauen sie auf ihre Cisco ASA, Juniper SRX oder ihre Firewall von Check Point oder Palo Alto Networks. Der APIC schützt die Investition dieser IT-Abteilungen in ihre bestehende physische Firewall, indem er diese direkt in die ACI-Fabric einbindet und somit ihre Funktion übernimmt sowie die Bereitstellung ihrer Richtlinien ermöglicht. Es besteht ein wachsendes Interesse an einer Beschränkung oder Segmentierung der Kommunikation zwischen verschiedenen Anwendungsebenen, und hier kann das ACI- Richtlinienmodell hinsichtlich Skalierbarkeit und Leistung besonders punkten. Da Richtlinien im ANP definiert werden, gelten sie für die gesamte Infrastruktur und werden am ersten Eingangspunkt in der ACI-Fabric durchgesetzt, sodass für alle ANPs die Funktion einer verteilten Firewall bereitgestellt wird. Dedizierte virtuelle Services für jeden Tenant werden in der ACI ebenso unterstützt wie Appliances mit physischen Formfaktoren. Anbieter von Cloud-Services haben ein besonderes Interesse an der Einrichtung und Dedizierung einer Instanz virtueller Firewalls, Load Balancer usw. für jeden gehosteten Tenant, sodass diese von jedem Tenant gesteuert und individuell verwaltet werden kann. Viele IT- Abteilungen wenden das Konzept der Tenants etwa auf einzelne Geschäftsbereiche an. Bei virtuellen Netzwerkservices ist jedoch ein weiterer Schritt zur Bereitstellung virtueller Firewalls oder Load Balancer erforderlich, nämlich die Durchführung einer geeigneten Versionskontrolle und die Installation der richtigen Lizenzen. Dies wird allgemein als Lebenszyklusmanagement für virtuelle Services bezeichnet. Cisco integriert diese Funktion in Zusammenarbeit mit Embrane in seine ACI-Lösung. Ein großer Schritt für Auditoren von IT-Systemen Ein Hauptvorteil der expliziten Definition von EPGs und Verträgen besteht in der Möglichkeit für Administratoren und IT-Auditoren zur einfachen Überwachung der instanziierten Richtlinien im Vergleich zur ursprünglichen Absicht des Anwendungseigentümers. Es ist kein großes Geheimnis, dass die Dokumentation der Systemrichtlinien in den meisten IT-Abteilungen keine hohe Priorität genießt, da die Pflege dieser Dokumente einen erheblichen Verwaltungsaufwand für IT-Administratoren bedeutet. Wenn zudem möglicherweise der ursprüngliche Eigentümer der Anwendung oder Plattform in eine andere Position wechselt oder das Unternehmen verlässt, entsteht eine enorme Wissenslücke. Wer schon einmal die Absicht des Eigentümers einer Anwendung oder Plattform aus den Konfigurationen von Switch, Router, Firewall, Load Balancer usw. ableiten musste, kennt den Zeit- und Kostenaufwand sowie die Mühsamkeit eines solchen Prozesses. 5

7 In diesem großen Bereich spielt die ACI eine wichtige Rolle. Da die ACI-Richtlinien auf höherer Ebene abstrahiert werden, können IT-Auditoren die Absicht des Anwendungseigentümers durch einen Blick auf das ANP schnell erkennen. Der Auditor muss keine detaillierten Konfigurationsdateien für Netzwerk und Services suchen und korrelieren, um die überspannenden Anwendungsrichtlinien zu ermitteln. Für eine umfassende Nachverfolgbarkeit hat Cisco zudem ein sehr detailliertes Auditprotokoll für geänderte Objekte mit Zeitstempel, Benutzer, Objekt und Beschreibung der Änderung implementiert. Tunneling und Interoperabilität bei mehreren Hypervisoren ACI bietet vor allem Anbindungsmöglichkeiten, aber die Verbindungsmethoden unterscheiden sich bei Anwendungen in sowohl physischen als auch virtuellen Umgebungen. Obwohl die Migration von physischen zu virtuellen Workloads stetig zugenommen hat, müssen virtuelle Workloads nach wie vor in jedem Fall mit Workloads auf Bare Metal-Hosts kommunizieren können. Zudem ist im letzten Jahr das Interesse an containerbasierten Workloads zur weiteren Leistungsoptimierung und Reduzierung des Verarbeitungsaufwands enorm gestiegen. Das Netzwerk war schon immer der Normalisierungspunkt für IT-Ressourcen und Computing-Modelle, da alle Workloads zur Anbindung auf das Netzwerk angewiesen sind. Die ACI soll zur neuen Grundlage für die Normalisierung von Workloads sowohl hinsichtlich Anbindung als auch Richtlinien werden. Der größte Normalisierungsbedarf besteht heute in virtuellen Netzwerken, da verschiedene Hypervisoren beim Management virtueller Netzwerke verschiedene Methoden nutzen und verschiedene Datenebenenkapselungen (VLAN, VXLAN, NVGRE usw.) unterstützen. In immer mehr Umgebungen sollen mehrere Hypervisoren bereitgestellt werden, und angesichts dieses Trends benötigen Unternehmen eine ganzheitliche Methode für das Management dieser unterschiedlichen Umgebungen und ihrer jeweiligen Kapselungen. Cisco ACI ermöglicht die direkte Integration in VMware vcenter und OpenStack Icehouse (mit Ubuntu-KVM bei allgemeiner Verfügbarkeit der Software). In Kürze plant Cisco auch die Unterstützung von Microsoft SCVMM, Microsoft AzurePack und Red Hat KVM mit OpenStack. Durch die Integration mehrerer Hypervisoren in die ACI wird der APIC zur zentralen Verwaltungsstelle für physische und virtuelle Netzwerkrichtlinien, und die ACI-Fabric wird zum verteilten Normalisierungspunkt für mehrere Kapselungstypen (VLAN, VXLAN, NVGRE), sodass Administratoren verschiedene Kapselungen untereinander flexibel terminieren, interpretieren und neu zuordnen können. Diese Kapselungen werden durch den APIC orchestriert, sodass der Netzwerkoder VM-Administrator keine Tag-Bindings koordinieren muss. Wenn Pakete in die ACI-Fabric eintreten, werden diese eindeutigen Kapselungs-Tags entfernt und entweder beim Austritt wieder angehängt oder in das Kapselungsschema des Zielhypervisors übersetzt, um die Anbindung mehrerer Hypervisoren zu ermöglichen. Durch die Integration in diese Virtual Machine Manager (VMMs) kann der Administrator physische und virtuelle Workloads mithilfe des ACI-Richtlinienmodells identisch behandeln. Wenn Administratoren Anwendungsebenen, Sicherheitsbereiche oder andere an eine EPG gebundene Elemente erstellen, werden diese Gruppen auf die zugrunde liegenden physischen und virtuellen Geräte übertragen. In VMware vcenter überträgt der APIC die EPGs als VMware- Portgruppen. In Microsoft SCVMM überträgt der APIC die EPGs als VM-Netzwerke und bei OpenStack als einfache Netzwerke. Ein VMware ESX-Hypervisor mit VXLAN taggt beispielsweise alle Pakete per VXLAN, muss aber mit zwei anderen ESX- Hypervisoren kommunizieren, die VLAN-Kapselung verwenden. Die ACI-Fabric führt die VLAN-Übersetzung oder das Bridging und Routing zwischen VXLAN und VLAN durch, sodass diese Pakete über die Subnetze übertragen werden können. Die ACI bietet also sämtliche VLAN- und VXLAN- Funktionen für Terminierung, Normalisierung und Routing mit Hardwareleistung. Host- oder Netzwerkansatz zur Normalisierung virtueller Tunneling-Schemas Die ACI nutzt einen anderen Architekturansatz als reine Hypervisornetzwerke. Bei einem reinen Hypervisoransatz sind die Netzwerkfunktionen im Hypervisor implementiert. Dies gilt etwa für die Mechanismen für Tagging und Durchsetzung von Richtlinien, die eine End-to-End- Transparenz des Netzwerks auf Hypervisorebene ermöglichen. Bei diesem Modell muss jeder Host, der als Tunnel-Endpunkt fungiert, demselben vertikalen Stack angehören, z. B. VMware, Microsoft oder einem anderen eingesetzten virtuellen Tunneling-Schema. Die virtuellen Tunneling-Schemas müssen zwischen allen Hypervisor- Hosts in der Anbindungsdomäne koordiniert werden. Im Wesentlichen müssen also die Workloads virtualisiert und jeweils mit genau demselben Hypervisor gepaart werden. Die verschiedenen Hypervisor-Managementsysteme bieten jedoch kaum Interoperabilität, die eine gleichzeitige Nutzung verschiedener Kapselungen und Richtlinien ermöglichen würde. Für die Anbindung an einen nicht virtualisierten Bare Metal-Server etwa muss ein physischer Switch im Netzwerk zudem dieselben virtuellen Tunneling-Schemas nutzen und umfassend in die Hypervisor-Managementsysteme integriert werden können, damit sich die Kapselungen und Richtlinien koordinieren lassen. Eine weitere Herausforderung für Produktionsbereitstellungen besteht darin, dass Administratoren von Rechenzentren nicht nur die physische zugrunde liegende Fabric ( Underlay ) testen und validieren müssen, sondern auch weitere Tools zur Validierung der 6

8 virtuellen Netzwerke ( Overlay ) benötigen würden, wodurch sich die insgesamt erforderliche Qualifikationszeit zur Überführung der Netzwerkinfrastruktur in eine einsatzbereite Implementierung verdoppeln würde. Anstelle der Koordinierung auf Hostebene nutzt die ACI das Netzwerk zur Koordinierung der virtuellen Tunneling- Schemas und ermöglicht so die Normalisierung an jedem Leaf-Knoten. Da die Netzwerkknoten bei der ACI die Normalisierungspunkte sind, bietet die Lösung umfassende Anbindungsmöglichkeiten und Richtlinien für alle Geräte, ob physisch, virtuell oder an das Netzwerk angebundene Container. Um die ACI-Fabric in eine einsatzbereite Implementierung zu überführen, muss der Administrator des Rechenzentrums lediglich die ACI-Fabric testen und validieren, da diese sowohl Underlay als auch Overlay auf einer Ebene vereint. Dadurch lässt sich sehr viel Zeit bei der Qualifikation der End-to-End-Lösung einsparen. Die meisten Architekten stehen also vor folgender Wahl: 1) Nutzung des Netzwerks als Normalisierungspunkt für Anbindung und Richtlinien und gemeinsame Qualifikation des physischen und virtuellen Netzwerks, 2) vollständige Virtualisierung und Vorgabe, dass jeder Host im gesamten Rechenzentrum genau denselben Hypervisor ausführen muss (dadurch Verdoppelung der Qualifikationszeit), und/oder 3) Betrieb mehrerer Overlay-Netzwerke ohne Interoperabilität zwischen Hypervisoren und/oder Bare Metal- Servern (dadurch zusätzliche Qualifikationszyklen). Beim ACI-Modell können Anwendungen Microsoft Hyper-V, VMware ESX und Ubuntu/Red Hat-KVM sowie Bare Metal- Server umfassen. Bei diesem Modell kann etwa eine Web- Anwendung jeweils zu Teilen auf ESX mit VXLAN und auf Hyper-V und die Datenbank auf KVM und Bare Metal (mit Anbindung) gehostet werden. Die Richtlinien können über eine zentrale Verwaltungsstelle global durchgesetzt werden. Wenn in einer Rechenzentrumsinfrastruktur eine echte Auswahl und Flexibilität benötigt wird, ist die ACI die optimale Lösung. Zusammenfassung Cisco hat die Probleme von IT-Führungskräften beim Management moderner Rechenzentrumsinfrastrukturen analysiert und einen neuen Ansatz mit dem Ziel entwickelt, Betriebskosten zu senken, die IT-Bereitstellung zu beschleunigen, physische und virtuelle IT-Ressourcen zu vereinen sowie die Unterstützung und Interoperabilität mehrerer Hypervisoren zu ermöglichen. Dabei hat Cisco das wichtigste Designprinzip bei Netzwerken beachtet, nämlich alle Anwendungen und Workloads zu unterstützen und eine Infrastruktur für allgemeine Zwecke zu liefern, die hinsichtlich der Anbindung über Richtlinien, Automatisierung und Programmierbarkeit angepasst werden kann. Diesen neuen Ansatz hat Cisco mit der Application Centric Infrastructure realisiert, einer der größten Innovationen in der Netzwerkbranche der letzten 25 Jahre. Auch wenn eine umfassende Einführung der ACI in der Branche wohl noch einige Zeit dauern wird, steht schon jetzt fest, dass Cisco ein neues Netzwerkmodell mit wertvollen technologischen Innovationen liefert, das sich sehr viel einfacher kontrollieren und verwalten lässt als die bisherigen geräteorientierten Netzwerke. Das Ergebnis dürften kurzfristig sinkende Betriebskosten sowie langfristig eine Architektur für Rechenzentrumsinfrastrukturen der nächsten Generation sein, mit denen Unternehmen weltweit auch in den nächsten 25 Jahren erfolgreich sein werden. 7

9 Informationen zu Nicholas J. Lippis Nicholas J. Lippis III ist ein weltweit geschätzter Experte auf dem Gebiet der IP-Netzwerke und IP-Kommunikation und deren geschäftlichem Nutzen für Unternehmen. Er ist Herausgeber des Lippis Report, einer Publikation, die von über IT-Entscheidungsträgern abonniert wird. Die Lippis Report-Podcasts wurden bereits über Mal heruntergeladen. Laut Angaben von itunes laden dieselben Kunden auch Money Matters aus dem Wall Street Journal, Climbing the Ladder von Business Week sowie weitere Podcasts von The Economist und den IdeaCast von The Harvard Business Review herunter. Lippis ist darüber hinaus Mitbegründer und Konferenzleiter der Open Networking User Group, die zweimal jährlich ein Zusammentreffen von mehr als 200 IT-Entscheidungsträgern aus führenden Unternehmen organisiert. Aktuell entwickelt Lippis in Zusammenarbeit mit Kunden eine Private- und Public- Cloud-Netzwerkarchitektur mit offenen Netzwerktechnologien für virtualisierte Rechenzentren, mit der maximaler geschäftlicher Nutzen und Erfolg gewährleistet werden soll. Er berät zahlreiche der Global 2000-Unternehmen zu den Themen Netzwerkarchitektur, Design, Implementierung, Anbieterauswahl und Budgetierung, darunter Barclays Bank, Eastman Kodak Company, Federal Deposit Insurance Corporation (FDIC), Hughes Aerospace, Liberty Mutual, Schering-Plough, Camp Dresser McKee, der Bundesstaat Alaska, Microsoft, Kaiser Permanente, Sprint, Worldcom, Cisco Systems, Hewlett Packard, IBM, Avaya und viele andere. Er arbeitet ausschließlich mit CIOs und deren direkt unterstellten Mitarbeitern zusammen. Mit seiner langjährigen Erfahrung sowohl auf der Anbieter- als auch der Nachfrageseite ist Lippis bestens mit den neuesten Trends in der Netzwerkbranche und den Faktoren vertraut, die die Kräfte auf dem Markt beeinflussen. Lippis wurde mit dem renommierten Alumni Award des Boston University College of Engineering für seine besonderen Verdienste in dieser Branche ausgezeichnet. Von Network World wurde er als einer der 40 einflussreichsten Persönlichkeiten in der Netzwerkbranche bezeichnet. TechTarget, ein branchenspezifisches Online-Magazin, hat ihn zum Netzwerkdesign-Guru gekürt. Das Network Computing Magazine lobt ihn als Star-IT-Guru. Nicholas J. Lippis ist Gründer von Strategic Networks Consulting, Inc., einem renommierten und einflussreichen Beratungsunternehmen der Netzwerkbranche wurde das Unternehmen von Softbank/Ziff-Davis übernommen. Er tritt häufig als Gastredner bei Branchenveranstaltungen auf und wird oft und gern in der unternehmens- und branchenrelevanten Presse zitiert. Darüber hinaus arbeitet er für den Dean of Boston University s College of Engineering Board of Advisors und ist Mitglied von Beratungsgremien zahlreicher Start-up-Unternehmen hielt er die Rede bei der Abschlussfeier der Absolventen des College of Engineering der Boston University. Er erwarb einen Bachelor of Science in Elektrotechnik sowie einen Master of Science in Systemtechnik an der Boston University. Für seine Masterarbeit belegte er ausgewählte technische Lehrgänge und zog Mitarbeiter des Massachusetts Institute of Technology (MIT) zu den Themen optische Kommunikation und Computing zurate.