Projekte in verschiedenen Rechenzentren kombinieren

In diesem Artikel werden wir untersuchen, warum der traditionelle Ansatz zur Kombination lokaler Netzwerke auf L2-Ebene bei einer signifikanten Erhöhung der Anzahl der Geräte unwirksam ist, und Ihnen erläutern, welche Probleme wir bei der Kombination von Projekten an verschiedenen Standorten lösen konnten.

Normale L2-Schaltung

Da die IT-Infrastruktur im Rechenzentrum wächst, müssen Kunden Server, Speicher und Firewalls in einem einzigen Netzwerk kombinieren. Zu diesem Zweck schlägt Selectel zunächst die Verwendung eines lokalen Netzwerks vor.

Das lokale Netzwerk ist als klassisches "Campus" -Netzwerk innerhalb desselben Rechenzentrums angeordnet. Nur Zugriffsschalter befinden sich direkt in den Racks mit den Servern. Zugriffsschalter werden weiter zu einem einzigen Aggregationsschichtschalter kombiniert. Jeder Kunde kann für jedes Gerät, das er mietet oder bei uns im Rechenzentrum platziert , eine Verbindung zum lokalen Netzwerk bestellen .

Zum Organisieren eines lokalen Netzwerks werden dedizierte Zugriffs- und Aggregationsschalter verwendet, sodass Probleme im Internetnetzwerk das lokale Netzwerk nicht beeinträchtigen.


Es spielt keine Rolle, in welchem ​​Rack sich der nächste Server befindet - Selectel kombiniert die Server in einem einzigen lokalen Netzwerk, und Sie müssen nicht über Switches oder den Serverstandort nachdenken. Sie können einen Server bestellen, wenn er benötigt wird, und er wird mit dem lokalen Netzwerk verbunden.

L2 funktioniert hervorragend, wenn das Rechenzentrum klein ist und nicht alle Racks voll sind. Mit zunehmender Anzahl von Racks, Servern in Racks, Switches und Clients wird die Wartung der Schaltung jedoch sehr viel schwieriger.


Server eines Clients können sich in mehreren Rechenzentren befinden , um Katastrophenschutz zu gewährleisten, oder wenn es nicht möglich ist, den Server in einem vorhandenen Rechenzentrum zu platzieren (z. B. sind alle Racks und alle Plätze belegt). Zwischen mehreren Rechenzentren ist auch eine Konnektivität erforderlich - zwischen Servern in einem lokalen Netzwerk.

Mit zunehmender Anzahl von Rechenzentren, Racks und Servern wird die Schaltung komplizierter. Die Konnektivität zwischen den Servern verschiedener Rechenzentren wurde zunächst einfach auf der Ebene der Aggregations-Switches mithilfe der VLAN-Technologie durchgeführt.


Der VLAN-Identifikationsraum ist jedoch sehr begrenzt (4095 VLAN-IDs). Daher müssen Sie für jedes Rechenzentrum einen eigenen Satz von VLANs verwenden, wodurch die Anzahl der möglichen Kennungen verringert wird, die zwischen Rechenzentren verwendet werden können.

L2 Probleme

Bei Verwendung eines Schemas auf L2-Ebene mit VLAN kann ein fehlerhafter Betrieb eines der Server im Rechenzentrum zu Unterbrechungen bei der Bereitstellung von Diensten auf anderen Servern führen. Die häufigsten Probleme sind:

• Probleme mit STP (Spanning-Tree Protocol)
• Probleme mit Broadcast Storms
• Probleme mit falscher Multicast-Verarbeitung
• Human Factor (Link Transfer, VLAN Transfer)
• Probleme bei der Organisation der Reservierung für L2
• Probleme mit unbekanntem Unicast-Verkehr
• Probleme mit der Anzahl der MAC-Adressen

Probleme mit STP hängen häufig mit den Einstellungen von Client-Servern oder Client-Geräten zusammen. Im Gegensatz zu gängigen Verkehrsaustauschpunkten können wir STP nicht vollständig nach Zugriffsports filtern und Ports löschen, wenn eine STP-PDU eintrifft. Bei STP implementieren eine Reihe von Herstellern von Netzwerkgeräten grundlegende Funktionen von Rechenzentrums-Switches wie das Erkennen von Schleifen im Netzwerk.

Wenn STP auf der Clientseite nicht ordnungsgemäß funktioniert, ist möglicherweise die gesamte STP-Domäne von mindestens einem Zugriffsschalter betroffen. Die Verwendung von STP-Erweiterungen wie MSTP ist ebenfalls keine Lösung, da die Anzahl der Ports, VLANs und Switches häufig die architektonische Skalierbarkeit des STP-Protokolls überschreitet.

Sendung

Das Netzwerk im Rechenzentrum kann auf Geräten verschiedener Hersteller aufgebaut werden. Manchmal reichen sogar die Unterschiede in der Switch-Softwareversion aus, damit die Switches STP unterschiedlich handhaben können. So gibt es beispielsweise im Rechenzentrum Dubrovka 3 280 Racks, was die maximal mögliche Anzahl von Switches in einer STP-Domäne überschreitet.

Mit der weit verbreiteten Verwendung von STP in einem solchen Netzwerk überschreitet die Reaktionszeit auf Änderungen, insbesondere durch einfaches Ein- oder Ausschalten des Ports, alle Warteschwellen. Sie möchten nicht, dass Ihre Netzwerkverbindung für einige Minuten verschwindet, wenn einer der Clients den Port einschaltet?

Probleme mit dem Broadcast-Verkehr treten häufig sowohl aufgrund falscher Aktionen auf dem Server (z. B. Erstellen einer Brücke zwischen mehreren Server-Ports) als auch aufgrund einer falschen Softwarekonfiguration auf den Servern auf. Wir versuchen, mögliche Probleme mit der Menge des Broadcast-Verkehrs, der in unser Netzwerk gelangt, auszugleichen. Wir können dies jedoch an einem Serververbindungsport tun. Wenn 5 Server in einem Switch enthalten sind, von denen jeder die festgelegten Schwellenwerte nicht überschreitet, können sie zusammen genügend Datenverkehr generieren, um die Steuerung des Aggregations-Switch auszulösen. Nach unserer eigenen Praxis können Probleme mit einem Broadcast-Sturm von der Serverseite durch einen bestimmten Ausfall der Netzwerkkarte des Servers verursacht werden.

Durch den Schutz des gesamten Netzwerks „setzt“ der Aggregationsschalter den Port, an dem die Netzwerkanomalie aufgetreten ist. Leider führt dies zur Inoperabilität der fünf Server, die diesen Vorfall verursacht haben, sowie zur Inoperabilität anderer Server (bis zu mehreren Racks im Rechenzentrum).

Multicast

Probleme mit der fehlerhaften Verarbeitung des Multicast-Verkehrs sind sehr spezifische Probleme, die im Komplex aufgrund des fehlerhaften Betriebs der Software auf dem Server und der Software auf dem Switch auftreten. Beispielsweise wird Corosync im Multicast-Modus zwischen mehreren Servern konfiguriert. Der Austausch von Hello-Paketen erfolgt regelmäßig in kleinen Mengen. In einigen Fällen können Server mit installiertem Corosync jedoch eine ganze Reihe von Paketen weiterleiten. Dieses Volume erfordert entweder eine spezielle Konfiguration der Switches oder die Verwendung der richtigen Verarbeitungsmechanismen (IGMP-Join und andere). Bei fehlerhafter Bedienung der Mechanismen oder beim Auslösen von Schwellenwerten kann es zu Betriebsunterbrechungen kommen, die andere Kunden betreffen. Je weniger Clients sich auf dem Switch befinden, desto unwahrscheinlicher ist es natürlich, dass Probleme von einem anderen Client auftreten.

Der Faktor Mensch ist ein eher unvorhergesehenes Problem, das bei der Arbeit mit Netzwerkgeräten auftreten kann. Wenn der Netzwerkadministrator alleine ist und seine Arbeit kompetent aufbaut, die Aktionen dokumentiert und über die Konsequenzen seiner Aktionen nachdenkt, ist die Wahrscheinlichkeit eines Fehlers recht gering. Wenn jedoch die Anzahl der Geräte, die im Rechenzentrum in Betrieb sind, zunimmt, wenn viele Mitarbeiter vorhanden sind, wenn viele Aufgaben vorhanden sind, ist ein völlig anderer Ansatz für die Arbeitsorganisation erforderlich.

Einige Arten typischer Aktionen werden automatisiert, um menschliches Versagen zu vermeiden, aber viele Arten von Aktionen können derzeit nicht automatisiert werden, oder der Preis für die Automatisierung solcher Aktionen ist unangemessen hoch. Zum Beispiel das physische Schalten von Patchkabeln auf einem Patchfeld, das Verbinden neuer Links und das Ersetzen vorhandener Links. Alles im Zusammenhang mit physischem Kontakt mit SCS. Ja, es gibt Patch-Panels, die einen Fernwechsel ermöglichen, aber sie sind sehr teuer, erfordern viel Vorarbeit und sind in ihren Funktionen sehr eingeschränkt.

Kein automatisches Patchfeld wird bei Bedarf ein neues Kabel verlegen. Sie können beim Konfigurieren eines Switches oder Routers einen Fehler machen. Geben Sie die falsche Portnummer (VLAN-Nummer) an, die bei der Eingabe eines numerischen Werts versiegelt werden soll. Berücksichtigen Sie bei der Angabe zusätzlicher Einstellungen nicht deren Einfluss auf die vorhandene Konfiguration. Mit zunehmender Komplexität des Schemas, die das Redundanzschema kompliziert (zum Beispiel weil das aktuelle Schema die Skalierungsgrenze erreicht), steigt die Wahrscheinlichkeit menschlicher Fehler. Jeder kann einen menschlichen Fehler haben, unabhängig davon, ob sich das Gerät in der Konfigurationsphase befindet, ein Server, ein Switch, ein Router oder eine Art Transitgerät.

Die Organisation der Redundanz über L2 scheint auf den ersten Blick eine einfache Aufgabe für kleine Netzwerke zu sein. Der Cisco ICND-Kurs behandelt die Grundlagen der Verwendung von STP als Protokoll, das ursprünglich für die Bereitstellung von L2-Redundanz entwickelt wurde. STP hat viele Einschränkungen, die in diesem Protokoll als "von Entwurf" bezeichnet werden. Wir dürfen nicht vergessen, dass jede STP-Domäne eine sehr begrenzte "Breite" hat, dh die Anzahl der Geräte in einer STP-Domäne ist im Vergleich zur Anzahl der Racks im Rechenzentrum recht gering. Das STP-Protokoll in seiner ursprünglichen Version unterteilt die Links in verwendete und Backups, wodurch Uplinks im normalen Betrieb nicht vollständig genutzt werden.

Die Verwendung anderer L2-Reservierungsprotokolle unterliegt Einschränkungen. Zum Beispiel ERPS (Ethernet Ring Protection Switching) - für die verwendete physische Topologie, für die Anzahl der Ringe auf einem Gerät und für die Nutzung aller Verbindungen. Die Verwendung anderer Protokolle beinhaltet in der Regel proprietäre Änderungen von verschiedenen Herstellern oder beschränkt den Netzwerkaufbau auf eine ausgewählte Technologie (z. B. TRILL / SPBm-Factory mit Avaya-Geräten).

Unbekannt-Unicast

Ich möchte insbesondere den Subtyp von Problemen mit unbekanntem Unicast-Verkehr hervorheben. Was ist das? Datenverkehr, der für eine bestimmte IP-Adresse über L3 bestimmt ist, aber über L2 im Netzwerk gesendet wird, dh an alle zu diesem VLAN gehörenden Ports übertragen wird. Diese Situation kann aus einer Reihe von Gründen auftreten, beispielsweise beim Empfang von DDoS an eine nicht belegte IP-Adresse. Oder wenn während eines Tippfehlers in der Serverkonfiguration eine Adresse, die im Netzwerk nicht vorhanden ist, als Sicherung angegeben wurde und auf dem Server in der Vergangenheit ein statischer ARP-Datensatz unter dieser Adresse vorhanden ist. Unknown-Unicast wird angezeigt, wenn alle Einträge in den ARP-Tabellen vorhanden sind, jedoch keine MAC-Adresse des Empfängers in den Switching-Tabellen der Transit-Switches vorhanden ist.

Beispielsweise wechselt der Port, hinter dem sich der Netzwerkhost mit der angegebenen Adresse befindet, sehr oft in den Aus-Zustand. Diese Art von Verkehr wird durch Transit-Switches begrenzt und häufig auf die gleiche Weise wie Broadcast oder Multicast bedient. Im Gegensatz zu ihnen kann unbekannter Unicast-Verkehr jedoch „über das Internet“ und nicht nur über das Client-Netzwerk initiiert werden. Das Risiko von unbekanntem Unicast-Verkehr ist besonders hoch, wenn Filterregeln auf Grenzroutern das Spoofing von IP-Adressen von außen ermöglichen.

Sogar die schiere Anzahl von MAC-Adressen kann manchmal ein Problem sein. Bei einer Rechenzentrumsgröße von 200 Racks und 40 Servern pro Rack ist es unwahrscheinlich, dass die Anzahl der MAC-Adressen die Anzahl der Server im Rechenzentrum erheblich überschreitet. Dies ist jedoch keine wahre Aussage mehr, da eines der Virtualisierungssysteme auf den Servern gestartet werden kann und jede virtuelle Maschine durch ihre MAC-Adresse oder sogar mehrere dargestellt werden kann (beispielsweise beim Emulieren mehrerer Netzwerkkarten in einer virtuellen Maschine). Insgesamt können wir mehr als mehrere tausend legitime MAC-Adressen von einem Rack in 40 Servern erhalten.

Eine solche Anzahl von MAC-Adressen kann bei einigen Switch-Modellen die Fülle der Switching-Tabelle beeinträchtigen. Darüber hinaus wird bei bestimmten Switch-Modellen beim Ausfüllen der Switching-Tabelle Hashing verwendet, und einige MAC-Adressen können Hash-Kollisionen verursachen, die zum Auftreten von unbekanntem Unicast-Verkehr führen. Eine zufällige Suche nach MAC-Adressen auf einem gemieteten Server mit einer Geschwindigkeit von beispielsweise 4.000 Adressen pro Sekunde kann dazu führen, dass die Switching-Tabelle auf dem Access Switch überläuft. Natürlich beschränken die Switches die Anzahl der MAC-Adressen, die an den Switch-Ports gelernt werden können. Abhängig von der spezifischen Implementierung dieses Mechanismus können die Daten jedoch unterschiedlich interpretiert werden.

Das Senden von Datenverkehr an die durch diesen Mechanismus gefilterte MAC-Adresse führt wiederum zum Auftreten von Datenverkehr mit unbekanntem Unicast. Das Unangenehmste in dieser Situation ist, dass die Schalter vom Hersteller selten auf Selbstheilung nach Fällen mit Überlauf des Schalttisches getestet werden. Ein einzelner Überlauf der Tabelle, der beispielsweise durch einen Fehler eines Clients in den HPING-Parametern oder durch das Schreiben eines Skripts zur Überwachung seiner Infrastruktur verursacht wird, kann zu einem Neustart des Switches und einer Unterbrechung der Kommunikation für alle Server im Rack führen. Wenn ein solcher Überlauf auf dem Switch auf Aggregationsebene auftritt, kann ein Neustart des Switch zu einer 15-minütigen Ausfallzeit des lokalen Netzwerks des gesamten Rechenzentrums führen.

Ich möchte vermitteln, dass die Verwendung von L2 nur für begrenzte Fälle gerechtfertigt ist und viele Einschränkungen auferlegt. Die Größe des Segments, die Anzahl der L2-Segmente - dies sind alle Parameter, die jedes Mal ausgewertet werden müssen, wenn Sie ein neues VLAN mit L2-Konnektivität hinzufügen. Und je kleiner die L2-Segmente sind, desto einfacher und damit zuverlässiger ist das Netzwerk in Betrieb.

Typische L2-Anwendungsfälle

Wie bereits erwähnt, wird bei der schrittweisen Entwicklung der Infrastruktur in einem Rechenzentrum ein lokales L2-Netzwerk verwendet. Leider ist diese Verwendung auch bei der Entwicklung von Projekten in einem anderen Rechenzentrum oder in einer anderen Technologie (z. B. virtuellen Maschinen in der Cloud) impliziert.

Verknüpfen Sie Front- und Back-End, Backup

In der Regel beginnt die Verwendung eines lokalen Netzwerks mit der Trennung der Funktionalität der Front- und Back-End-Dienste, wobei das DBMS einem separaten Server zugewiesen wird (um die Leistung zu verbessern und den Betriebssystemtyp auf dem Anwendungsserver und dem DBMS zu trennen). Die Verwendung von L2 für diese Zwecke erscheint zunächst gerechtfertigt, in dem Segment gibt es nur wenige Server, oft befinden sie sich sogar im selben Rack.


Server sind in einem VLAN, in einem oder mehreren Switches enthalten. Mit zunehmender Anzahl von Geräten werden immer mehr neue Server in die Switches neuer Racks im Rechenzentrum aufgenommen, von denen aus die L2-Domäne an Breite zunimmt.


Es werden neue Server angezeigt, einschließlich Sicherungsdatenbankservern, Sicherungsservern und dergleichen. Solange sich das Projekt in einem Rechenzentrum befindet, treten in der Regel keine Skalierungsprobleme auf. Anwendungsentwickler gewöhnen sich nur daran, dass sich auf dem nächsten Server im lokalen Netzwerk die IP-Adresse erst im letzten Oktett ändert und Sie keine separaten Routing-Regeln schreiben müssen.

Entwickler werden gebeten, ein ähnliches Schema anzuwenden, wenn das Projekt wächst, wenn die folgenden Server bereits in einem anderen Rechenzentrum gemietet sind oder wenn ein Teil des Projekts auf die virtuellen Maschinen in der Cloud verschoben wird . Auf dem Bild sieht alles sehr einfach und schön aus:


Es scheint, dass Sie nur zwei Aggregations-Switches in DC1 und DC2 mit einem VLAN verbinden müssen. Aber was steckt hinter dieser einfachen Aktion?

Ressourcenreservierung

Zunächst erhöhen wir die Breite der L2-Domäne, sodass alle potenziellen Probleme des lokalen Netzwerks von DC1 in DC2 auftreten können. Wem wird es gefallen, dass sich seine Server in DC2 befinden und der Vorfall im Zusammenhang mit der Unzugänglichkeit des lokalen Netzwerks aufgrund falscher Aktionen in DC1 auftritt?

Zweitens müssen Sie sich um die Sicherung dieses VLAN kümmern. Der Aggregationsschalter in jedem Rechenzentrum ist der Fehlerpunkt. Das Kabel zwischen Rechenzentren ist ein weiterer Fehlerpunkt. Jeder Fehlerpunkt sollte reserviert werden. Zwei Aggregationsschalter, zwei Kabel von Aggregationsschaltern zu Zugriffsschaltern, zwei Kabel zwischen Rechenzentren ... Jedes Mal, wenn die Anzahl der Komponenten zunimmt, wird die Schaltung komplizierter.


Die Komplexität des Schemas wird durch die Notwendigkeit verursacht, jedes Element im System zu reservieren. Für eine vollständige Sicherung von Geräten und Links müssen Sie fast jedes Element duplizieren. In einem so großen Netzwerk ist es nicht mehr möglich, STP zum Organisieren von Redundanz zu verwenden. Es wäre möglich, alle Netzwerkelemente, insbesondere Zugriffsschalter, als Komponenten der MPLS-Cloud darzustellen, dann würde aufgrund der Funktionalität des MPLS-Protokolls Redundanz erhalten.

MPLS-Geräte sind jedoch in der Regel doppelt so teuer wie Nicht-MPLS-Geräte. Und es sollte beachtet werden, dass der MPU-Switch in 1U, der einen guten Grad an Skalierbarkeit aufweist, die Implementierung der vollen MPLS-Funktionalität in der Steuerebene in der Praxis bis vor kurzem nicht existierte. Infolgedessen möchte ich die Auswirkungen von L2-Problemen auf das vorhandene Netzwerk beseitigen oder minimieren, aber gleichzeitig die Möglichkeit behalten, Ressourcen zu reservieren.

Übergang zu L3

Wenn jede Verbindung im Netzwerk als separates IP-Segment und jedes Gerät als separater Router dargestellt wird, benötigen wir keine Redundanz auf L2-Ebene. Die Redundanz von Verbindung und Router wird durch dynamische Routing-Protokolle und Routing-Redundanz im Netzwerk sichergestellt.

Innerhalb des Rechenzentrums können wir die vorhandenen Server-Interaktionsschemata über L2 miteinander speichern, und der Zugriff auf die Server in einem anderen Rechenzentrum erfolgt über L3.


Somit sind Rechenzentren durch L3-Konnektivität miteinander verbunden. Das heißt, es wird emuliert, dass ein Router zwischen den Rechenzentren installiert ist (tatsächlich mehrere zur Sicherung). Auf diese Weise können Sie L2-Domänen zwischen Rechenzentren aufteilen, in jedem Rechenzentrum ein eigenes VLAN verwenden und zwischen diesen kommunizieren. Für jeden Client können Sie sich wiederholende Bereiche von IP-Adressen verwenden, die Netzwerke sind vollständig voneinander isoliert und Sie können nicht vom Netzwerk eines Clients in das Netzwerk eines anderen Clients gelangen (es sei denn, beide Clients stimmen einer solchen Verbindung zu).

Wir empfehlen die Verwendung von IP-Segmenten ab 10.0.0.0/8 für lokale Netzwerke. Für das erste Rechenzentrum ist das Netzwerk beispielsweise 10.0.1.0/24, für das zweite 10.0.2.0/24. Selectel auf dem Router schreibt die IP-Adresse dieses Subnetzes vor. In der Regel sind .250-.254-Adressen für Selectel-Netzwerkgeräte reserviert, und eine .254-Adresse dient als Gateway zu anderen LANs. Die Route wird allen Geräten in allen Rechenzentren zugewiesen:

route add 10.0.0.0 mask 255.0.0.0 gw 10.0.x.254

Wobei x die Nummer des Rechenzentrums ist. Aufgrund dieser Route „sehen“ sich die Server in den Rechenzentren durch Routing.


Das Vorhandensein einer solchen Route vereinfacht die Skalierung des Schemas im Fall beispielsweise des Auftretens eines dritten Rechenzentrums. Für Server im dritten Rechenzentrum werden dann IP-Adressen aus dem nächsten Bereich, 10.0.3.0/24, auf dem Router registriert - der Adresse 10.0.3.254.


Eine Besonderheit bei der Implementierung eines solchen Schemas besteht darin, dass im Falle eines Ausfalls des Rechenzentrums oder externer Kommunikationskanäle keine zusätzliche Reservierung erforderlich ist. Wenn beispielsweise das Rechenzentrum 1 ausfällt, bleibt die Verbindung zwischen dem Rechenzentrum 2 und dem Rechenzentrum 3 vollständig erhalten, und wenn das Schema mit dem L2-Feed zwischen den Rechenzentren über eines von ihnen implementiert wird, wie in der Abbildung dargestellt:


Die Verbindung zwischen dem Rechenzentrum 2 und dem Rechenzentrum 3 hängt von der Effizienz des Rechenzentrums 1 ab. Oder die Organisation zusätzlicher Verbindungen und die Verwendung komplexer L2-Reservierungsschemata sind erforderlich. Und während das L2-Schema gespeichert wird, reagiert das gesamte Netzwerk immer noch sehr empfindlich auf fehlerhaftes Schalten, die Bildung von Vermittlungsschleifen, verschiedene Verkehrsstürme und andere Probleme.

L3-Segmente innerhalb von Projekten

Neben der Verwendung unterschiedlicher L3-Segmente in verschiedenen Rechenzentren ist es sinnvoll, ein separates L3-Netzwerk für Server in verschiedenen Projekten zuzuweisen, die häufig mit unterschiedlichen Technologien erstellt werden. Beispielsweise Hardwareserver im Rechenzentrum in einem IP-Subnetz, virtuelle Server im selben Rechenzentrum, aber in der VMware-Cloud in einem anderen IP-Subnetz einige Staging-bezogene Server im dritten IP-Subnetz . Dann führen zufällige Fehler in einem der Segmente nicht zu einem vollständigen Ausfall aller im lokalen Netzwerk enthaltenen Server.

Router-Reservierung

Das ist alles beeindruckend, aber es gibt einen einzigen Fehlerpunkt zwischen Projekten - dies ist der Router. Was ist in diesem Fall zu tun? In der Tat ist der Router nicht allein. Für jedes Rechenzentrum werden zwei Router zugewiesen, und für jeden Kunden bilden sie mithilfe des VRRP-Protokolls die virtuelle IP .254.

Die Verwendung von VRRP zwischen zwei benachbarten Geräten mit einem gemeinsamen L2-Segment ist gerechtfertigt. Für Rechenzentren, die geografisch verteilt sind, werden verschiedene Router verwendet, zwischen denen MPLS organisiert ist. Somit ist jeder Client, der auf diese Weise eine Verbindung zum lokalen Netzwerk herstellt, mit einem separaten L3VPN verbunden, der auf diesen MPLS-Routern dafür vorgesehen ist. Und das Schema sieht in Annäherung an die Realität so aus:


Die Gateway-Adresse für jedes .254-Segment wird von VRRP zwischen den beiden Routern reserviert.

Fazit

Zusammenfassend lässt sich sagen, dass wir durch die Änderung des lokalen Netzwerktyps von L2 auf L3 die Skalierbarkeit beibehalten, die Zuverlässigkeit und Fehlertoleranz erhöhen und zusätzliche Redundanzschemata implementieren konnten. Darüber hinaus wurden die bestehenden Beschränkungen und „Fallstricke“ von L2 umgangen.

Mit dem Wachstum von Projekten und Rechenzentren stoßen vorhandene Standardlösungen an ihre Grenzen der Skalierbarkeit. Dies bedeutet, dass sie nicht mehr zur effektiven Problemlösung geeignet sind. Die Anforderungen an Zuverlässigkeit und Stabilität des Gesamtsystems steigen ständig, was sich wiederum auf den Planungsprozess auswirkt. Es ist wichtig zu berücksichtigen, dass optimistische Wachstumsprognosen berücksichtigt werden sollten, damit es in Zukunft kein System gibt, das nicht skaliert werden kann.

Sagen Sie uns - verwenden Sie bereits L3VPN? Wir sehen uns in den Kommentaren.