In der griechischen Mythologie wurde der Titan Prometheus an einen Felsen gekettet. Jeden Tag flog ein Adler hinunter und aß einen Teil seiner Leber. Das Organ regenerierte sich während der Nacht und füllte die Nahrungsquelle auf. Die Leber ist eines der wenigen Organe im menschlichen Körper, die sich spontan regenerieren können. Noch beeindruckender ist die Tatsache, dass die Leber, während sie sich regeneriert und repariert, immer noch funktionsfähig ist. Die alten Griechen wussten von dieser Fähigkeit und haben sie vor fast 3000 Jahren in ihre Mythologie aufgenommen.

Kontinuierliche Funktionalität

Wenn wir Netzwerke entwerfen, wollen wir, dass sie funktionsfähig sind, auch wenn das System unterbrochen wird. Hardwarefehler, Glasfaserausfälle, Softwarefehler und sogar Eichhörnchen, die durch Kabel kauen, passieren. Wir sind besorgt darüber, wie die Anwendungsbereitstellung und die Netzwerkinfrastruktur auf diese Probleme reagieren. Wir integrieren Technologien in unsere IT-Infrastruktur, um die Auswirkungen des Schadens zu minimieren.

Wie unsere Leber muss das Netzwerk funktionieren, auch wenn es den verursachten Schaden heilt. Anwendungen müssen bereitgestellt werden, und Unternehmen haben noch viel zu tun. Schon früh entwickelten wir dynamische Netzwerkprotokolle wie das Spanning Tree Protocol (STP) für Layer-2-Topologien und das Routing Information Protocol (RIP) für Layer-3-Topologien. Im Laufe der Zeit haben wir diese Protokolle weiterentwickelt, um das Layer 2-basierte Rapid Spanning Tree Protocol (RSTP) und Layer 3-Routing-Protokolle wie OSPF, ISIS und BGP einzubeziehen.

Weiter auf dem OSI-Stack

Wir müssen noch Mechanismen für die Anwendungsverfügbarkeit und die Bereitstellung der Anwendungen über die Netzwerkinfrastruktur bereitstellen. Hier haben wir Server Load Balancing (SLB) und dynamische DNS-Manipulation durch Global Server Load Balancing (GSLB) eingeführt. Sie bieten die Mechanismen zum Erkennen von Anwendungsserverfehlern und zum Abschließen von Rechenzentrumsfehlern.

Mein ideales Netzwerk (Art)

Wenn ich heute ein Netzwerk auf hohem Niveau entwerfen würde, würde es dem obigen Diagramm sehr ähnlich sehen. Redundanz ist in jeden Aspekt der Architektur integriert. Es gibt mehrere Server, geografisch unterschiedliche Standorte und mehrere Netzwerkpfade zu den verschiedenen Komponenten. Es gibt keinen Single Point of Failure. Wenn ein Aspekt fehlschlägt, konvergieren die dynamischen Technologien automatisch neu, um einen neuen besten Pfad zwischen Client und Anwendungsserver zu ermitteln.

Es gibt eine Menge feiner Details, die ich in diesem Artikel nicht behandle. Das tatsächliche Design des Layer 2/3-Netzwerks und der Gerätekonnektivität hängt davon ab, ob die unterschiedlichen Anforderungen an die Anwendungsbereitstellung erfüllt werden, um die Application Service Level Assurance (SLA) für alle Anwendungen sicherzustellen. Da wir nicht wissen, um welche Anträge es sich handelt, können wir diese Entscheidung nicht treffen. Der andere Grund ist, dass ich ein Buch schreiben müsste, um alle Aspekte zu diskutieren, die notwendig sind, um dieses Netzwerk aufzubauen.

Die wichtigsten Punkte, an die Sie sich erinnern sollten, wenn Sie Ihre eigene selbstheilende, regenerierende IT-Infrastruktur entwerfen, sind:

• Redundanz in die Architektur einbauen
• Dynamische Technologien nutzen, die sich automatisch an sich ändernde Bedingungen anpassen
• Denken Sie daran, dass das entscheidende Endziel darin besteht, die Anwendungs-SLA sicherzustellen

Als nächstes werden wir dieses Netzwerk nehmen und verschiedene Komponenten zerlegen, um zu sehen, wie sie sich auf die Bereitstellung der Anwendung auswirken und was der Endbenutzer wahrnimmt.

Lesen Sie „Halten Sie es einfach; Machen Sie es skalierbar: 6 Merkmale des zukunftssicheren Load Balancers“ erfahren Sie mehr.

Jetzt herunterladen