{"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":"Anwendungszentrierte Infrastruktur. Die Netzwerkarchitektur der Zukunft \u2013 vom Nachdenken zum Handeln","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In den letzten Jahren hat Cisco aktiv eine neue Architektur zur Erstellung von Netzwerken in Rechenzentren vorangetrieben \u2013 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 Mehrheit der IT-Professionals und IT-Leiter bleibt ACI jedoch entweder eine unverst\u00e4ndliche Abk\u00fcrzung oder einfach eine Diskussion \u00fcber die Zukunft.
\nIn diesem Artikel werden wir versuchen, diese Zukunft n\u00e4herzubringen. Dazu erl\u00e4utern wir die grundlegenden architektonischen Komponenten von ACI und veranschaulichen deren praktische Anwendung. Au\u00dferdem werden wir in naher Zukunft eine anschauliche Demonstration von ACI organisieren, an der sich jeder interessierte IT-Fachmann teilnehmen kann.
\n<\/a><\/noindex>
\nMehr \u00fcber die neue Netzwerkarchitektur erfahren Sie in St. Petersburg im Mai 2019. Alle Details finden Sie unter \u00fcber diesen Link verf\u00fcgbar<\/a><\/noindex>. Melden Sie sich an!<\/p>\n

Hintergrund<\/b>
\nDas traditionelle und am weitesten verbreitete Netzwerkmodell ist das dreistufige hierarchische Modell: Kern -> Verteilung (Aggregation) -> Zugriff. Viele Jahre lang stellte dieses Modell den Standard dar, und Hersteller entwickelten verschiedene Netzwerkger\u00e4te, die diesen Anforderungen gerecht wurden.
\nFr\u00fcher, als Informationstechnologie eine Art notwendiges (und, ehrlich gesagt, nicht immer gew\u00fcnschtes) Anh\u00e4ngsel an das Gesch\u00e4ft war, war dieses Modell praktisch, ziemlich statisch und zuverl\u00e4ssig. Doch heute, wo IT einer der Antriebskr\u00e4fte f\u00fcr das Wachstum von Unternehmen ist und in vielen F\u00e4llen selbst das Gesch\u00e4ft darstellt, hat die Statischer dieses Modells zu erheblichen Problemen gef\u00fchrt.<\/p>\n

Moderne Unternehmen generieren eine Vielzahl komplexer Anforderungen an die Netzwerk Infrastruktur. Die rechtzeitige Umsetzung dieser Anforderungen ist entscheidend f\u00fcr den Gesch\u00e4ftserfolg. In solchen Situationen ist jede Verz\u00f6gerung inakzeptabel, und das klassische Netzwerkmodell erm\u00f6glicht es oft nicht, den gesch\u00e4ftlichen Bed\u00fcrfnissen zeitgerecht gerecht zu werden. <\/p>\n

Ein neues, komplexes Gesch\u00e4ftsanwendungsprogramm bedeutet, dass Netzwerkadministratoren viele \u00e4hnliche Routineoperationen an einer Vielzahl von unterschiedlichen Netzwerkger\u00e4ten auf verschiedenen Ebenen durchf\u00fchren m\u00fcssen. Das kostet nicht nur viel Zeit, sondern erh\u00f6ht auch das Risiko von Fehlern, die zu ernsthaften Ausfallzeiten der IT-Dienste und damit zu finanziellen Sch\u00e4den f\u00fchren k\u00f6nnen.<\/p>\n

Das eigentliche Problem sind nicht einmal die Fristen oder die Komplexit\u00e4t der Anforderungen. Vielmehr m\u00fcssen diese Anforderungen von der Sprache der Gesch\u00e4ftsanwendungen in die Sprache der Netzwerk-Infrastruktur \u201e\u00fcbersetzt\u201c werden. Wie bekannt ist, geht bei jeder \u00dcbersetzung ein Teil des Sinns verloren. Wenn der Anwendungsinhaber \u00fcber die Logik seiner Anwendung spricht, versteht der Netzwerkadministrator eine Reihe von VLANs und Access-Listen auf Dutzenden von Ger\u00e4ten, die unterst\u00fctzt, aktualisiert und dokumentiert werden m\u00fcssen.<\/p>\n

Die gesammelte Erfahrung und der st\u00e4ndige Austausch mit unseren Kunden haben es Cisco erm\u00f6glicht, neue Prinzipien f\u00fcr den Aufbau von Netzwerken in Rechenzentren zu entwerfen und umzusetzen, die den modernen Trends entsprechen und in erster Linie auf der Logik von Gesch\u00e4ftsapplikationen basieren. Daher der Name \u2014 Application Centric Infrastructure.<\/p>\n

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

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

    \n\"Anwendungszentrierte
    \nLassen Sie uns jede Ebene im Detail betrachten \u2013 dabei werden wir vom Einfachen zum Komplexen \u00fcbergehen.<\/p>\n

    Netzwerk auf Basis von Nexus-Switches<\/b>
    \nDas Netzwerk in einer ACI-Fabrik \u00e4hnelt dem traditionellen hierarchischen Modell, wird jedoch erheblich einfacher aufgebaut. F\u00fcr die Organisation des Netzwerks wird das Leaf-Spine-Modell verwendet, das sich als allgemeiner Ansatz f\u00fcr die Implementierung von Netzwerken der n\u00e4chsten Generation etabliert hat. Dieses Modell besteht aus zwei Ebenen: Spine und Leaf.
    \n \"Anwendungszentrierte
    \nDie Spine-Ebene ist ausschlie\u00dflich f\u00fcr die Leistung verantwortlich. Die Gesamtleistung 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 die Endger\u00e4te angeschlossen sind. Die Hauptfunktion der Leaf-Switches besteht in der Portkapazit\u00e4t. <\/p>\n

    Damit werden Skalierungsfragen einfach gel\u00f6st: Wenn wir die Bandbreite der Fabrik erh\u00f6hen m\u00f6chten, f\u00fcgen wir Spine-Switches hinzu, und wenn wir die Portkapazit\u00e4t erh\u00f6hen m\u00f6chten, Leaf.
    \nF\u00fcr beide Ebenen kommen die Switches der Cisco Nexus 9000-Serie zum Einsatz, die f\u00fcr Cisco das Hauptwerkzeug zum Aufbau von Rechenzentrumsnetzwerken unabh\u00e4ngig von deren Architektur darstellen. F\u00fcr die Spine-Ebene werden die Switches Nexus 9300 oder Nexus 9500 verwendet, und f\u00fcr Leaf nur Nexus 9300.
    \nDie Modellreihe der Nexus-Switches, die in der ACI-Fabrik verwendet werden, ist in der Abbildung unten dargestellt.
    \n \"Anwendungszentrierte<\/p>\n

    Cluster von APIC-Controllern (Application Policy Infrastructure Controller) <\/b>
    \nAPIC-Controller sind spezialisierte physische Server. F\u00fcr kleinere Implementierungen kann ein Cluster aus einem physischen APIC-Controller und zwei virtuellen Controllern verwendet werden.
    \nDie APIC-Controller \u00fcbernehmen Funktionen f\u00fcr die Verwaltung und \u00dcberwachung. Es ist wichtig zu beachten, dass die Controller niemals an der Daten\u00fcbertragung beteiligt sind. Selbst wenn alle Controller eines Clusters ausfallen, hat das keine Auswirkungen auf die Stabilit\u00e4t des Netzwerks. Au\u00dferdem verwaltet der Administrator mit Hilfe von APICs alle physischen und logischen Ressourcen des Systems. Um \u00c4nderungen vorzunehmen, ist es nicht erforderlich, sich mit einem bestimmten Ger\u00e4t zu verbinden, da ACI eine zentrale Verwaltungsstelle nutzt.
    \n \"Anwendungszentrierte<\/p>\n

    Kommen wir nun zu einem der Hauptbestandteile von ACI \u2013 den Anwendungsprofilen.<\/b>
    \nAnwendungsprofil (Application Network Profile)<\/b> \u2013 ist die logische Grundlage von ACI. Anhand von Anwendungsprofilen werden die Interaktionsrichtlinien zwischen allen Netzsegmenten definiert und die Netzsegmente selbst beschrieben. ANP erm\u00f6glicht es, sich von der physikalischen Ebene zu abstrahieren und im Grunde darzustellen, wie die Interaktion zwischen verschiedenen Netzsegmenten aus der Sicht der Anwendung organisiert werden sollte. <\/p>\n

    Ein Anwendungsprofil besteht aus Gruppen von Verbindungen (End-Point Groups \u2013 EPG). Eine Verbindungsgruppe ist eine logische Gruppe von Hosts (virtuellen Maschinen, physischen Servern, Containern usw.), die sich in einem Sicherheitssegment befinden (nicht im Netzwerk, sondern speziell in der Sicherheit). Die End-Hosts, die zu einer bestimmten EPG geh\u00f6ren, k\u00f6nnen anhand einer Vielzahl von Kriterien definiert werden. \u00dcblicherweise werden folgende verwendet: <\/p>\n