{"id":33050,"date":"2019-10-31T21:50:27","date_gmt":"2019-10-31T18:50:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu\/"},"modified":"2019-10-31T21:50:27","modified_gmt":"2019-10-31T18:50:27","slug":"application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu","title":{"rendered":"Application Centric Infrastructure. Die Netzwerkarchitektur der Zukunft \u2013 von \u00dcberlegungen zur Tat","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In den letzten Jahren hat Cisco aktiv eine neue Architektur f\u00fcr den Aufbau von Datennetzen in Rechenzentren vorangetrieben - Application Centric Infrastructure (oder ACI)<\/b>. Einige sind bereits damit vertraut. Andere haben sie sogar in ihren Unternehmen implementiert, auch in Russland. F\u00fcr die meisten IT-Fachleute und IT-Leiter bleibt ACI jedoch entweder ein unverst\u00e4ndliches Akronym oder lediglich eine Diskussion \u00fcber die Zukunft.
\nIn diesem Artikel werden wir versuchen, die Zukunft n\u00e4her zu bringen. Dazu werden wir \u00fcber die wichtigsten architektonischen Komponenten von ACI sprechen und deren Anwendung in der Praxis veranschaulichen. Dar\u00fcber hinaus werden wir in naher Zukunft eine anschauliche Demonstration der Funktionsweise von ACI organisieren, f\u00fcr die sich jeder interessierte IT-Fachmann anmelden kann.
\n<\/a><\/noindex>
\nMehr \u00fcber die neue Architektur des Netzaufbaus erfahren Sie im Mai 2019 in Sankt Petersburg. Alle Details - unter dem Link<\/a><\/noindex>. Melden Sie sich an!<\/p>\n

Vorgeschichte<\/b>
\nDas traditionelle und beliebteste Netzwerkmodell ist das dreistufige hierarchische Modell: Kern -> Verteilung (Aggregation) -> Zugriff. Dieses Modell war \u00fcber viele Jahre das Ma\u00df aller Dinge, und die Hersteller brachten verschiedene Netzwerkger\u00e4te mit entsprechender Funktionalit\u00e4t auf den Markt.
\nFr\u00fcher, als IT eine Art notwendiges (und, um ehrlich zu sein, nicht immer gew\u00fcnschtes) Anh\u00e4ngsel des Gesch\u00e4fts war, war dieses Modell bequem, sehr statisch und zuverl\u00e4ssig. Doch heutzutage, wo IT einer der Treiber f\u00fcr die Gesch\u00e4ftsentwicklung ist und in vielen F\u00e4llen selbst das Gesch\u00e4ft darstellt, hat die Statischtheit dieses Modells gro\u00dfe Probleme verursacht.<\/p>\n

Moderne Unternehmen erzeugen eine Vielzahl komplexer Anforderungen an die Netzwerkstruktur. Der Erfolg des Unternehmens h\u00e4ngt direkt von der Umsetzung dieser Anforderungen ab. Verz\u00f6gerungen sind in solchen Situationen unzul\u00e4ssig, und das klassische Netzwerkmodell erm\u00f6glicht es oft nicht, alle Gesch\u00e4ftsanforderungen rechtzeitig zu erf\u00fcllen. <\/p>\n

Zum Beispiel erfordert das Auftreten einer neuen komplexen Gesch\u00e4fts-Anwendung von Netzwerkadministratoren die Durchf\u00fchrung einer Vielzahl \u00e4hnlicher Routineoperationen auf einer gro\u00dfen Anzahl verschiedener Netzger\u00e4te auf unterschiedlichen Ebenen. Neben dem Zeitaufwand erh\u00f6ht dies auch das Risiko, einen Fehler zu machen, der zu ernsthaften Ausfallzeiten im IT-Service f\u00fchren kann und somit zu finanziellen Sch\u00e4den.<\/p>\n

Der Kern des Problems sind nicht einmal die Fristen oder die Komplexit\u00e4t der Anforderungen. Das Problem liegt darin, dass diese Anforderungen von der Sprache der Gesch\u00e4fts-Anwendungen in die Sprache der Netzwerkinfrastruktur \"\u00fcbersetzt\" werden m\u00fcssen. Wie bekannt, ist jede \u00dcbersetzung immer mit einem teilweisen Verlust von Bedeutung verbunden. Wenn der Anwendungsinhaber \u00fcber die Logik seines Anwendungsprogramms spricht, versteht der Netzwerkadministrator ein Set von VLANs, Access-Listen auf Dutzenden von Ger\u00e4ten, die aktualisiert, gewartet und dokumentiert werden m\u00fcssen.<\/p>\n

Die gesammelte Erfahrung und der st\u00e4ndige Austausch mit den Kunden erm\u00f6glichten es Cisco, neue Prinzipien f\u00fcr den Aufbau des Datennetzwerks eines Rechenzentrums zu entwerfen und umzusetzen, die modernen Trends entsprechen und in erster Linie auf der Logik der Gesch\u00e4fts-Anwendungen basieren. Daher der Name \u2013 Application Centric Infrastructure.<\/p>\n

Die Architektur von ACI.<\/b>
\nDie Architektur von ACI sollte nicht von der physischen, sondern von der logischen Seite betrachtet werden. Sie basiert auf einem Modell automatisierter Richtlinien, dessen Objekte auf der obersten Ebene in die folgenden Komponenten unterteilt werden k\u00f6nnen:<\/p>\n

    \n
  1. Netzwerk auf der Basis von Nexus-Switches.<\/li>\n
  2. Cluster von APIC-Controllern;<\/li>\n
  3. Anwendungsprofile;<\/li>\n<\/ol>\n

    \n\"Application
    \nBetrachten wir jede Ebene genauer \u2013 dabei werden wir von einfach zu komplex \u00fcbergehen.<\/p>\n

    Netzwerk auf der Basis von Nexus-Switches<\/b>
    \nDas Netzwerk in der ACI-Fabrik \u00e4hnelt dem traditionellen hierarchischen Modell, wird jedoch viel einfacher aufgebaut. F\u00fcr die Organisation des Netzwerks wird das Leaf-Spine-Modell verwendet, das sich als allgemeiner Ansatz zur Implementierung neuer Netzwerke etabliert hat. Dieses Modell besteht aus zwei Ebenen: Spine und Leaf, entsprechend.
    \n \"Application
    \nDie Spine-Ebene ist ausschlie\u00dflich f\u00fcr die Leistung verantwortlich. Die Gesamtheit der Leistung der Spine-Switches entspricht der Leistung der gesamten Fabrik, weshalb auf dieser Ebene Switches mit 40G-Ports oder h\u00f6her verwendet werden sollten.
    \nSpine-Switches verbinden sich mit allen Switches der n\u00e4chsten Ebene: Leaf-Switches, an die Endger\u00e4te angeschlossen werden. Die Hauptrolle der Leaf-Switches besteht in der Portkapazit\u00e4t. <\/p>\n

    Auf diese Weise werden Skalierungsfragen einfach gel\u00f6st: Wenn wir die Durchsatzf\u00e4higkeit der Fabrik erh\u00f6hen m\u00fcssen, f\u00fcgen wir Spine-Switches hinzu, und wenn wir die Portkapazit\u00e4t erh\u00f6hen m\u00fcssen \u2013 Leaf.
    \nF\u00fcr beide Ebenen werden die Switches der Serie Cisco Nexus 9000 verwendet, die f\u00fcr Cisco das Hauptinstrument zum Aufbau von Rechenzentrumsnetzwerken unabh\u00e4ngig von deren Architektur sind. F\u00fcr die Spine-Ebene werden die Switches Nexus 9300 oder Nexus 9500 verwendet, und f\u00fcr Leaf nur Nexus 9300.
    \nDie Modellreihe der Switches Nexus, die in der ACI-Fabrik verwendet werden, ist im Bild unten dargestellt.
    \n \"Application<\/p>\n

    Cluster Controller APIC (Application Policy Infrastructure Controller) <\/b>
    \nAPIC-Controller bestehen aus spezialisierten physischen Servern, wobei f\u00fcr kleinere Implementierungen ein Cluster aus einem physischen APIC-Controller und zwei virtuellen erlaubt ist.
    \nDie APIC-Controller \u00fcbernehmen die Funktionen der Verwaltung und \u00dcberwachung. Es ist wichtig, dass die Controller niemals an der Daten\u00fcbertragung beteiligt sind, das hei\u00dft, selbst wenn alle Controller des Clusters ausfallen, hat dies absolut keinen Einfluss auf die Stabilit\u00e4t des Netzwerkbetriebs. Au\u00dferdem muss angemerkt werden, dass der Administrator mit Hilfe der APICs alle physischen und logischen Ressourcen der Fabrik verwaltet, und um \u00c4nderungen vorzunehmen, ist es nicht mehr erforderlich, eine Verbindung zu einem bestimmten Ger\u00e4t herzustellen, da in ACI ein einheitlicher Managementpunkt verwendet wird.
    \n \"Application<\/p>\n

    Nun kommen wir zu einem der Hauptkomponenten von ACI \u2013 den Anwendungsprofilen.<\/b>
    \nAnwendungsprofil (Application Network Profile)<\/b> ist die logische Grundlage von ACI. Gerade die Anwendungsprofile definieren die Richtlinien f\u00fcr die Interaktion zwischen allen Netzwerksegmenten und beschreiben direkt die jeweiligen Netzwerksegmente. ANP erm\u00f6glicht eine Abstraktion von der physikalischen Ebene und stellt im Wesentlichen dar, wie die Interaktion zwischen verschiedenen Netzwerksegmenten aus Sicht der Anwendung organisiert werden sollte. <\/p>\n

    Das Anwendungsprofil besteht aus Verbindungsgruppen (End-point groups \u2013 EPG). Eine Verbindungsgruppe ist eine logische Gruppe von Hosts (virtuellen Maschinen, physischen Servern, Containern usw.), die sich im selben Sicherheitssegment befinden (nicht im Netzwerk, sondern konkret in der Sicherheit). End-Hosts, die zu einer bestimmten EPG geh\u00f6ren, k\u00f6nnen nach einer Vielzahl von Kriterien definiert werden. \u00dcblicherweise werden folgende verwendet: <\/p>\n