Die Geschichte eines Wechsels

In unserer Aggregation des lokalen Netzwerks gab es sechs Paare von Arista DCS-7050CX3-32S-Switches und ein Paar Brocade VDX 6940-36Q-Switches. Es wäre nicht ganz richtig zu sagen, dass uns die Brocade-Switches in diesem Netzwerk stark gestört haben; sie funktionieren und erfüllen ihre Aufgaben, aber wir bereiteten eine vollständige Automatisierung bestimmter Vorgänge vor, wofür wir an diesen Switches keine Möglichkeiten hatten. Außerdem wollten wir von 40GE-Schnittstellen auf 100GE umsteigen, um für die nächsten 2-3 Jahre einen Puffer zu schaffen. Daher entschieden wir uns, Brocade durch Arista zu ersetzen.

Diese Switches sind die Aggregations-Switches für jedes Rechenzentrum. An sie sind direkt die Verteilungsswitches (zweite Aggregationsebene) angeschlossen, die bereits die Top-of-Rack-Switches im Serverrack sammeln.

Jeder Server ist mit einem oder zwei Zugriffsswitches verbunden. Die Zugriffsswitches sind mit einem Paar von Verteilungsswitches verbunden (zwei Verteilungsswitches und zwei physische Links vom Zugriffsswitch zu verschiedenen Verteilungsswitches werden für die Redundanz genutzt).

Jeder Server kann von seinem Kunden genutzt werden, weshalb dem Kunden ein separater VLAN zugewiesen wird. Derselbe VLAN wird dann auf einem anderen Server dieses Kunden in einem beliebigen Rack konfiguriert. Das Rechenzentrum besteht aus mehreren solchen Reihen (PODs), für jede Reihe von Racks gibt es eigene Verteilungsswitches. Diese Verteilungsswitches sind dann mit den Aggregations-Switches verbunden.

Die Kunden können einen Server in jeder Reihe bestellen; im Voraus vorherzusagen, dass der Server einem bestimmten Rack in einer bestimmten Reihe zugewiesen oder installiert wird, ist nicht möglich, weshalb in den Aggregations-Switches in jedem Rechenzentrum etwa 2500 VLANs vorhanden sind.

Die Ausrüstung für DCI (Data-Center Interconnect) wird an die Aggregations-Switches angeschlossen. Sie kann sowohl für L2-Konnektivität (ein Paar Switches, die einen VXLAN-Tunnel in ein anderes Rechenzentrum bilden) als auch für L3-Konnektivität (zwei MPLS-Router) vorgesehen sein.

Wie ich bereits erwähnt habe, war es notwendig, die zentralen Aggregationsswitches in einem Rechenzentrum auszutauschen, um die Prozesse der Konfigurationsautomatisierung zu vereinheitlichen. Wir haben neue Switches neben den bestehenden installiert, sie zu einem MLAG-Paar verbunden und uns auf die Arbeiten vorbereitet. Diese wurden sofort mit den bestehenden Aggregationsswitches verbunden, sodass sie ein gemeinsames L2-Domain über alle Kunden-VLANs haben.

Details des Schemas

Um es konkret zu machen, nennen wir die alten Aggregationsswitches A1 und A2, die neuen — N1 und N2. Angenommen, dass in POD 1 und POD 4 Server eines Kunden untergebracht sind C1, das Kunden-VLAN wird blau markiert. Dieser Kunde nutzt den Dienst der L2-Konnektivität mit einem anderen Rechenzentrum, daher wird sein VLAN auf ein Paar von VXLAN-Switches übertragen.

den Kunden zurückzuführen sind, nicht verfügbar ist. C2 unterbringt Server in POD 2 und POD 3, das Kunden-VLAN kennzeichnen wir dunkelgrün. Dieser Kunde nutzt ebenfalls den Dienst der Konnektivität mit einem anderen Rechenzentrum, jedoch L3, sodass sein VLAN auf ein Paar von L3VPN-Routern übertragen wird.

Die Kunden-VLANs sind wichtig, um zu verstehen, was in den verschiedenen Phasen der Austauscharbeiten geschieht, wo es eine Unterbrechung der Verbindung gibt und wie lange diese dauern könnte. Das STP-Protokoll wird in diesem Schema nicht verwendet, da die Baumweite in diesem Fall groß wird und die Konvergenz des Protokolls geometrisch ansteigt, abhängig von der Anzahl der Geräte und der Links zwischen ihnen.

Alle Geräte, die über doppelte Links verbunden sind, bilden einen Stack, ein MLAG-Paar oder eine VCS-Ethernet-Fabrik. Für ein Paar von L3VPN-Routern werden solche Technologien nicht genutzt, da kein Bedarf an der Reservierung von L2 besteht, es genügt, dass sie über die Aggregationsswitches L2-Konnektivität zueinander haben.

Implementierungsvarianten

Bei der Analyse der Optionen für die weiteren Ereignisse haben wir festgestellt, dass es mehrere Möglichkeiten gibt, diese Arbeiten durchzuführen. Von einer globalen Unterbrechung des gesamten lokalen Netzwerks bis hin zu kleinen, buchstäblich 1-2 Sekunden dauernden Unterbrechungen in Teilen des Netzwerks.

Netzwerk, stillstehen! Switches, wechselt euch aus!

Der einfachste Weg wäre natürlich, eine globale Unterbrechung der Verbindung für alle PODs und alle DCI-Dienste bekannt zu geben und alle Links von den Switches A zu den Switches umzuschalten. N.

Neben der nicht zuverlässig vorhersehbaren Ausfallzeit (ja, wir kennen die Anzahl der Links, aber wir wissen nicht, wie oft etwas schiefgeht – von defekten Patchkabeln oder beschädigten Steckern bis hin zu fehlerhaften Ports oder Transceivern) können wir auch nicht im Voraus vorhersagen, ob die Länge der Patchkabel, DAC, AOC, die an alten Switches A angeschlossen sind, ausreicht, um sie zu den neuen Switches N zu ziehen, die zwar in der Nähe stehen, aber dennoch ein wenig abseits sind, und ob dieselben Transceiver/DAC/AOC von Brocade in den Switches von Arista funktionieren werden.

Und das alles unter dem Druck von Kunden und dem technischen Support („Natascha, steh auf! Natascha, es funktioniert alles nicht! Natascha, wir haben schon den technischen Support kontaktiert, ehrlich, ehrlich! Natascha, alles ist schon gefallen! Natascha, wie lange funktioniert es nicht mehr? Natascha, wann wird es wieder funktionieren?!”). Selbst bei vorher angekündigter Ausfallzeit und den Mitteilungen an die Kunden ist ein Anstieg der Anfragen in dieser Zeit garantiert.

Halt, 1-2-3-4!

Und wenn wir keinen globalen Ausfall ankündigen, sondern eine Reihe von kleinen Verbindungsausfällen nach POD und DCI angeben. Im ersten Ausfall die Switches umschalten N nur POD 1, im zweiten – nach ein paar Tagen – POD 2, dann nach ein paar weiteren Tagen POD 3, dann POD 4…[N], dann VXLAN-Switches und schließlich L3VPN-Router.

Bei dieser Vorgehensweise zum Umschalten reduzieren wir die Komplexität der gleichzeitigen Arbeiten und gewinnen Zeit, um Probleme zu lösen, falls etwas nicht wie geplant funktioniert. Die Verbindung von POD 1 nach dem Umschalten mit anderen PODs und DCI bleibt intakt. Aber die Arbeiten selbst ziehen sich lange hin, während dieser Arbeiten im Rechenzentrum wird ein Ingenieur für die physische Durchführung der Umschaltungen benötigt, und während der Arbeiten (die in der Regel nachts von 2 bis 5 Uhr durchgeführt werden) ist ein Online-Netzwerkingenieur mit recht hoher Qualifikation erforderlich. Aber dafür erhalten wir kurze Verbindungsausfälle, in der Regel können die Arbeiten im Zeitraum von einer halben Stunde mit Unterbrechungen von bis zu 2 Minuten durchgeführt werden (in der Praxis häufig 20-30 Sekunden bei erwartetem Verhalten der Geräte).

Im genannten Beispiel des Kunden C1 oder des Kunden C2 Es ist notwendig, über die Arbeiten mit Verbindungsunterbrechungen mindestens dreimal zu informieren – das erste Mal für die Durchführung von Arbeiten an einem POD, in dem sich ein Server befindet, das zweite Mal für den zweiten und das dritte Mal beim Umschalten der Geräte für DCI-Dienste.

Umschalten aggregierter Verbindungen

Warum sprechen wir über das erwartete Verhalten der Geräte und wie aggregierte Verbindungen mit minimaler Verbindungsunterbrechung umgeschaltet werden können. Stellen wir uns folgendes Szenario vor:

Auf der einen Seite der Verbindung – die Verteilungsschalter des POD – D1 und D2, sie bilden ein MLAG-Paar (Stack, VCS-Fabrik, vPC-Paar), auf der anderen Seite zwei Verbindungen – Link 1 und Link 2 – sind in das MLAG-Paar der alten Aggregierungsschalter integriert. AAuf der Seite der Schalter D wurde eine aggregierte Schnittstelle mit dem Namen Port-channel A, auf der Seite der Aggregierungsschalter A – aggregierte Schnittstelle mit dem Namen Port-channel D.

Aggregierte Schnittstellen verwenden für ihre Funktion LACP, d.h. die Switches auf beiden Seiten tauschen regelmäßig LACPDU-Pakete über beide Links aus, um sicherzustellen, dass die Links:

• funktionieren;
• in einem Paar von Geräten auf der entfernten Seite eingebunden sind.

Beim Austausch von Paketen wird der Wert system-idübertragen, der das Gerät bezeichnet, in das diese Links eingebunden sind. Für das MLAG-Paar (Stack, Fabrik usw.) ist der Wert der system-id für die Geräte, die die aggregierte Schnittstelle bilden, identisch. Der Switch D1 sendet den Wert Link 1 system-id D , und der Switchanalysiert die über eine Schnittstelle Po D empfangenen LACPDU-Pakete und überprüft die Übereinstimmung der system-id darin. Wenn die auf einem Link empfangene system-id plötzlich von dem aktuellen Wert abweicht, D2 sendet den Wert Link 2 system-id D , und der Switch.

Switches A1 und A2 wird dieser Link aus der aggregierten Schnittstelle entfernt, bis die Situation behoben ist. Derzeit haben wir auf der Seite der Switches den aktuellen Wert der system-id vom LACP-Partner –, und auf der Seite der Switches D – den aktuellen Wert der system-id vom LACP-Partner – AIm Falle einer Notwendigkeit zum Umschalten der aggregierten Schnittstelle können wir auf zwei verschiedene Arten vorgehen: A Methode 1 – Einfach D.

Deaktivieren Sie beide Links bei den Switches A.

In diesem Fall funktioniert der aggregierte Kanal nicht.
Aktivieren Sie die beiden Links nacheinander bei den Switches, dann wird eine erneute Aushandlung der LACP-Betriebsparameter stattfinden, die Bildung der Schnittstelle

Po D Nauf den Switches und die Übertragung des Wertes auf den Links system-id N N und die Übertragung von Werten über Links System-ID N.

Methode 2 — Minimierung der Unterbrechung
Link 2 vom Switch A2 trennen. Der Datenverkehr zwischen A und D wird weiterhin über einen der Links übertragen, der Teil der aggregierten Schnittstelle bleibt.

Link 2 am Switch N2 anschließen. Am Switch N wurde bereits eine aggregierte Schnittstelle eingerichtet Po DNanalysiert die über eine Schnittstelle Po D empfangenen LACPDU-Pakete und überprüft die Übereinstimmung der system-id darin. Wenn die auf einem Link empfangene system-id plötzlich von dem aktuellen Wert abweicht, N2 beginnt, in LACPDU zu übertragen System-ID N. An diesem Punkt können wir bereits überprüfen, dass der Switch N2 korrekt mit dem Transceiver arbeitet, der für Link 2, dass der Verbindungsport in den Zustand Up, und dass bei der Übertragung von LACPDU keine Fehler am Verbindungsport auftreten.

Aber die Tatsache, dass der Switch D2 für die aggregierte Schnittstelle Po A von der Seite Link 2 den Wert system-id N erhält, der sich von dem aktuellen Arbeitswert system-id A unterscheidet, hindert die Switches daran, D in die aggregierte Schnittstelle Link 2 aufzunehmen. Der Switch Po Akann nicht in Betrieb genommen werden, da er keine Bestätigung der Funktionalität vom LACP-Partner des Switches erhält N . Der Datenverkehr wird letztendlich über Link 2 nicht übertragen. D2Jetzt trennen wir Link 1 vom Switch A1 Link 2 , wodurch die Switches

der aktiven aggregierten Schnittstelle beraubt werden. Dadurch entfällt auf der Seite des Switchesder aktuelle Arbeitswert der system-id für die Schnittstelle. A und D Dies ermöglicht es den Switches, D sich auf den Austausch von system-id Po A.

A-N D und N an den Schnittstellen , sodass der Datenverkehr über den Link übertragen werden kann. Die Unterbrechung beträgt in diesem Fall praktisch bis zu 2 Sekunden. Po A und Po DNJetzt schalten wir Link 1 wieder am Switch N1 ein Link 2, wodurch die Kapazität und das Niveau der Redundanz der Schnittstellen wiederhergestellt werden.

Da sich bei der Verbindung dieses Links der aktuelle Wert der system-id auf keiner Seite ändert, tritt keine Unterbrechung auf.Zusätzliche Links Po A und Po DNAber der Wechsel kann ohne Anwesenheit eines Ingenieurs zum Zeitpunkt des Wechsels durchgeführt werden. Dazu müssen wir im Voraus zusätzliche Links zwischen den Verteilungsswitches

und den neuen Aggregationsswitches

verlegen. Wir verlegen neue Links zwischen den Aggregationsswitches D und den Verteilungsswitches aller PODs. Dies erfordert die Bestellung und Verlegung zusätzlicher Patchkabel und die Installation zusätzlicher Transceiver sowohl in N.

. Das können wir tun, da in den Switches N jeder PODs freie Ports vorhanden sind (oder wir sie im Voraus freimachen). N, als auch in Djedes POD über freie Ports verfügen (oder diese zuvor freigeben). D jedes POD hat freie Ports (oder wir machen sie vorher frei). Insgesamt ist jeder POD physisch über zwei Verbindungen mit den alten Switches A und den neuen Switches N verbunden.

Am Switch D sind zwei aggregierte Schnittstellen gebildet — Po A mit den Verbindungen Link 1 und Link 2, und Über N — mit den Verbindungen Link N1 und Link N2. In dieser Phase überprüfen wir die Richtigkeit der Verbindung der Schnittstellen und Verbindungen, die optischen Signalpegel an beiden Enden der Verbindungen (mittels DDM-Informationen von den Switches), wir können sogar die Funktionsfähigkeit der Verbindung unter Last überprüfen oder die Zustände der optischen Signale und die Temperaturen der Transceiver über ein paar Tage überwachen.

Der Datenverkehr wird nach wie vor über die Schnittstelle Po A, während die Schnittstelle Über N verkehrslos bleibt. Die Einstellungen der Schnittstellen sind ungefähr wie folgt:

Schnittstelle Port-channel A
Switchport Mode Trunk
Switchport Erlaubte VLAN C1, C2

Schnittstelle Port-channel N
Switchport Mode Trunk
Switchport Erlaubte VLAN keine

Switches D unterstützen in der Regel die Sitzungsänderung der Konfiguration, es werden solche Switch-Modelle verwendet, die diese Funktionalität haben. So können wir die Einstellungen für die Schnittstellen Po A und Po N in einem Durchgang ändern:

Konfigurationssitzung
Schnittstelle Port-channel A
Switchport erlaubte VLAN keine
Schnittstelle Port-channel N
Switchport erlaubte VLAN C1, C2
Übernehmen

Dann findet die Konfigurationsänderung ziemlich schnell statt, und die Unterbrechung beträgt in der Praxis nicht mehr als 5 Sekunden.

Dieses Verfahren ermöglicht es uns, alle Vorbereitungsarbeiten im Voraus durchzuführen, alle erforderlichen Prüfungen zu erledigen, die Arbeiten mit den Beteiligten abzustimmen, die Aktionen zur Durchführung der Arbeiten detailliert vorherzusagen, ohne kreative Ausbrüche, wenn "alles nicht wie geplant lief", und einen Plan für die Rückkehr zur vorherigen Konfiguration zur Hand zu haben. Die Arbeiten nach diesem Plan werden von einem Netzwerkingenieur ohne Anwesenheit eines Rechenzentrumsingenieurs durchgeführt, der physisch die Umschaltungen vornimmt.

Was bei solchen Umschaltungen ebenfalls wichtig ist — alle neuen Links wurden bereits im Voraus überwacht. Fehler, die Aktivierung der Links im Aggregat, die Auslastung der Links — alle erforderlichen Informationen sind bereits im Überwachungssystem, und das ist bereits auf Karten eingezeichnet.

D-Day

POD

Wir haben den für die Kunden am wenigsten schmerzhaften und am wenigsten anfälligen Weg für "etwas ist schiefgelaufen" bei Umschaltungen mit zusätzlichen Links gewählt. So haben wir in ein paar Nächten alle POD auf die neuen Aggregation-Switches umgeschaltet.

Es bleibt jedoch, die Geräte umzuschalten, die die DCI-Dienste bereitstellen.

L2

Im Fall von Geräten, die L2-Konnektivität gewährleisten, konnten wir vergleichbare Arbeiten an zusätzlichen Links nicht durchführen. Dafür gibt es mindestens zwei Gründe:

• Fehlende freie Ports mit der erforderlichen Geschwindigkeit an den VXLAN-Switches.
• Fehlende Funktionalität zur Änderung der Konfiguration in einer Sitzung an den VXLAN-Switches.

Wir wollten die Links „eins nach dem anderen“ schalten, nur mit einer Unterbrechung während der Abstimmung einer neuen System-ID, haben es aber nicht gemacht, da wir uns nicht 100%ig sicher waren, dass das Verfahren korrekt ablaufen würde. Ein Test im Labor zeigte, dass wir, wenn "etwas schiefgeht", trotzdem eine Verbindungstrennung haben, und das Schlimmste dabei ist, nicht nur für Kunden, die L2-Konnektivität zu anderen Rechenzentren haben, sondern für alle Kunden dieses Rechenzentrums.

Wir haben frühzeitig Information darüber bereitgestellt, dass wir von L2-Kanälen wechseln möchten. Daher war die Anzahl der Kunden, die von den Arbeiten an den VXLAN-Switches betroffen waren, bereits mehrere Male geringer als vor einem Jahr. Letztendlich haben wir uns entschieden, die Verbindung bei der L2-Konnektivität zu unterbrechen, unter der Bedingung, dass wir die normale Funktion der lokalen Netzwerkdienste in einem Rechenzentrum aufrecht erhalten. Zudem sieht das SLA für diesen Dienst die Möglichkeit vor, planmäßige Arbeiten mit Unterbrechungen durchzuführen.

L3

Warum haben wir allen empfohlen, auf L3VPN für die DCI-Dienste umzusteigen? Einer der Gründe ist die Möglichkeit, Arbeiten an einem der Router, die diesen Dienst bereitstellen, einfach durch Senkung des Redundanzniveaus auf N+0, ohne Verbindungsunterbrechung, durchzuführen.

Betrachten wir das Bereitstellungsschema des Dienstes genauer. In diesem Dienst erstreckt sich das L2-Segment nur von den Kundenservern bis zu den Selectel L3VPN-Routern. An den Routern wird das Kundennetzwerk terminiert.

Jeder Kundenserver, zum Beispiel, S2 und S3 in dem angegebenen Schema hat seine privaten IP-Adressen — 10.0.0.2/24 beim Server S2 und 10.0.0.3/24 beim Server S3. Die Adressen 10.0.0.252/24 und 10.0.0.253/24 sind von Selectel an die Router zugewiesen worden, L3VPN-1 und L3VPN-2, entsprechend. Die IP-Adresse 10.0.0.254/24 ist die VRRP VIP-Adresse an den Selectel-Routern.

Mehr über den L3VPN-Dienst kann man lesen in unserem Blog.

Bis zum Zeitpunkt der Umschaltung sah alles ungefähr so aus wie im Diagramm:

Zwei Router L3VPN-1 und L3VPN-2 waren mit dem alten Aggregationsswitch verbunden. ADer Master für die VRRP VIP-Adresse 10.0.0.254 ist der Router. L3VPN-1Er hat für diese Adresse eine höhere Priorität als der Router. L3VPN-2.

einheit 1006 {
    beschreibung C2;
    vlan-id 1006;
    familie inet {       
        adresse 10.0.0.252/24 {
            vrrp-gruppe 1 {
                priorität 200;
                virtuelle-adresse 10.100.0.254;
                preemption {
                    haltedauer 120;
                }
                daten-annehmen;
            }
        }
    }
}

Der Server S2 verwendet als Gateway zu den Servern an anderen Standorten die IP-Adresse 10.0.0.254. Dadurch hat die Trennung vom L3VPN-2-Router (natürlich nach dessen vorheriger Trennung vom MPLS-Domain) keine Auswirkungen auf die Konnektivität der Kundenserver. In diesem Moment wird einfach das Niveau der Redundanz des Schemas verringert.

Nach dieser Maßnahme können wir den Router problemlos wieder anschließen L3VPN-2 an ein Paar von Switches N. Kabel verlegen, Transceiver wechseln. Die logischen Schnittstellen des Routers, von denen die Kundenservices abhängen, sind bis zur Bestätigung, dass alles einwandfrei funktioniert, stillgelegt.

Nach Überprüfungen der Links, Transceiver, Signalpegel und Fehlerpegel an den Schnittstellen wird der Router in Betrieb genommen, aber bereits mit dem neuen Paar von Switches verbunden.

Anschließend senken wir die VRRP-Priorität des Routers L3VPN-1, und die VIP-Adresse 10.0.0.254 wird auf den Router L3VPN-2 übertragen. Diese Arbeiten werden ebenfalls ohne Unterbrechung der Verbindung durchgeführt.

Die Übertragung der VIP-Adresse 10.0.0.254 auf den Router L3VPN-2 ermöglicht es, den Router L3VPN-1 ohne Unterbrechung der Verbindung für den Kunden abzuschalten und ihn bereits mit dem neuen Paar von Aggregation Switches zu verbinden. N.

Ob die VRRP VIP zurück auf den Router L3VPN-1 übertragen wird oder nicht – das ist eine andere Frage, und wenn es zurückgegeben wird, geschieht das ebenfalls ohne Unterbrechung der Verbindung.

Insgesamt

Nach all diesen Maßnahmen haben wir tatsächlich die Aggregationsswitches in einem unserer Rechenzentren ersetzt, wobei wir gleichzeitig die Unterbrechungen für unsere Kunden minimiert haben.

Nun bleibt nur noch die Demontage. Die Demontage der alten Switches, die Demontage der alten Links zwischen den Switches A und D, die Demontage der Transceiver von diesen Links, die Anpassung der Überwachung, die Korrektur der Netzwerkanordnung in der Dokumentation und Überwachung.

Switches, Transceiver, Patchkabel, AOC, DAC, die nach den Umschaltungen übrig bleiben, können wir in anderen Projekten oder bei ähnlichen Umschaltungen verwenden.

„Natascha, wir haben alles umgeschaltet!“

Quelle: habr.com