In unserer lokalen Netzwerkaggregation hatten wir sechs Paare von Arista DCS-7050CX3-32S-Switches und ein Paar von Brocade VDX 6940-36Q-Switches. Es war nicht so, dass uns die Brocade-Switches in diesem Netzwerk stark gestresst hätten; sie funktionieren und erfüllen ihre Aufgaben. Allerdings bereiteten wir die vollständige Automatisierung bestimmter Prozesse vor, und diese Möglichkeiten hatten wir mit diesen Switches nicht. Außerdem wollten wir von 40GE- auf 100GE-Interfaces umsteigen, um für die nächsten 2-3 Jahre vorzusorgen. Daher haben wir uns entschieden, Brocade gegen Arista auszutauschen.
Diese Switches sind die Aggregations-Switches für jedes Rechenzentrum. Sie sind direkt mit den Verteilungsswitches (zweite Aggregationsstufe) verbunden, die bereits die Top-of-Rack-Switches im Rack mit Servern sammeln.
Jeder Server ist an einen oder zwei Zugangsswitches angeschlossen. Die Zugangsswitches sind mit einem Paar von Verteilungsswitches verbunden (zwei Verteilungsswitches und zwei physische Links vom Zugangsswitch zu verschiedenen Verteilungsswitches werden zur Redundanz verwendet).
Jeder Server kann von seinem Kunden genutzt werden, sodass dem Kunden ein separater VLAN zugewiesen wird. Dieser VLAN wird dann auf einem anderen Server dieses Kunden in jedem Rack konfiguriert. Das Rechenzentrum besteht aus mehreren solchen Reihen (PODs), für jede Reihe von Racks gibt es eigene Verteilungsswitches. Diese Verteilungsswitches werden dann an Aggregationsswitches angeschlossen.
Kunden können Server in beliebigen Reihen bestellen, eine vorausschauende Zuweisung, dass der Server in eine bestimmte Reihe oder in ein konkretes Rack installiert wird, ist nicht möglich, daher gibt es an den Aggregationsswitches in jedem Rechenzentrum etwa 2500 VLANs.
Die Ausrüstung für DCI (Data-Center Interconnect) wird an die Aggregationsswitches angeschlossen. Sie kann sowohl für L2-Konnektivität (ein Paar Switches, das einen VXLAN-Tunnel in ein anderes Rechenzentrum bildet) als auch für L3-Konnektivität (zwei MPLS-Router) vorgesehen sein.
Wie ich bereits erwähnt habe, war es erforderlich, die zentralen Aggregationsswitches auszutauschen, um die Prozesse zur Automatisierung der Dienstkonfiguration in einem Rechenzentrum 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 einen gemeinsamen L2-Domänen für alle Kunden-VLANs erhielten.
Details des Schemas
Um es konkret zu machen, nennen wir die alten Aggregationsswitches A1 und A2, die neuen — N1 und N2. Stellen wir uns vor, dass im POD 1 und POD 4 Server eines Kunden untergebracht sind C1, das VLAN des Kunden ist in Blau dargestellt. Dieser Kunde nutzt die L2-Konnektivitätsdienstleistung zu einem anderen Rechenzentrum, daher wird sein VLAN auf ein Paar VXLAN-Switches weitergeleitet.
Kunde C2 unterbringt Server in POD 2 und POD 3, das VLAN des Kunden wird dunkelgrün dargestellt. Dieser Kunde nutzt ebenfalls einen Konnektivitätsdienst zu einem anderen Rechenzentrum, jedoch L3, sodass sein VLAN auf ein Paar L3VPN-Router weitergeleitet wird.
Kunden-VLANs sind für uns wichtig, um zu verstehen, in welchen Phasen der Umbaumaßnahmen was geschieht, wo Verbindungsunterbrechungen auftreten können und wie lange diese dauern könnten. Das STP-Protokoll wird in diesem Schema nicht verwendet, da es aufgrund der Breite des Baums in diesem Fall groß wird und die Konvergenz des Protokolls geometrisch ansteigt, abhängig von der Anzahl der Geräte und Links zwischen ihnen.
Alle Geräte, die durch 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 eingesetzt, da es keine Notwendigkeit für eine L2-Redundanz gibt; es reicht aus, dass sie eine L2-Verbindung zueinander über die Aggregationsswitches haben.
Implementierungsoptionen
Bei der Analyse der möglichen weiteren Ereignisse erkannten wir, dass es mehrere Möglichkeiten gibt, diese Arbeiten durchzuführen. Von einem globalen Ausfall im gesamten lokalen Netzwerk bis hin zu kurzen Unterbrechungen von nur 1-2 Sekunden in Teilen des Netzwerks.
Netzwerk, stehenbleiben! Switches, ersetzen Sie sich!
Der einfachste Weg ist natürlich, einen globalen Verbindungsabbruch für alle PODs und für alle DCI-Dienste anzukündigen und alle Links von den Switches umzuschalten. A in die Switches N.
Neben dem unvorhersehbaren Ausfall, dessen Dauer wir nicht garantieren können (ja, wir wissen, wie viele Links es gibt, aber wir wissen nicht, wie oft etwas schiefgeht – von einem beschädigten Patchkabel oder einem defekten Stecker bis hin zu einem fehlerhaften Port oder Transceiver), können wir außerdem nicht im Voraus einschätzen, ob die Länge der Patchkabel, DAC, AOC, die an die alten Switches A angeschlossen sind, ausreicht, um sie zu den neuen Switches N zu verlängern, die zwar in der Nähe stehen, aber dennoch etwas abseits sind, und ob die gleichen Transceiver/DAC/AOC von den Brocade-Switches in den Arista-Switches funktionieren werden.
Und das alles unter dem Druck von Kunden und dem technischen Support („Natascha, komm! Natascha, da funktioniert alles nicht! Natascha, wir haben bereits den technischen Support kontaktiert, ehrlich! Natascha, da ist alles schon abgestürzt! Natascha, wie lange wird es noch nicht funktionieren? Natascha, wann wird es wieder funktionieren?!“). Selbst bei einem im Voraus angekündigten Ausfall und der Benachrichtigung an die Kunden ist ein Ansturm an Anfragen in solchen Zeiten garantiert.
Halt, 1-2-3-4!
Und wenn man keinen globalen Ausfall anmeldet, sondern eine Reihe kleiner Kommunikationsausfälle nach POD und DCI-Diensten ankündigt? Beim ersten Ausfall auf die Switches umschalten. N nur POD 1, im zweiten — in ein paar Tagen — POD 2, dann wieder ein paar Tage später POD 3, danach POD 4…[N], dann VXLAN-Switches und schließlich L3VPN-Router.
Durch diese Organisation der Umschaltarbeiten reduzieren wir die Komplexität der gleichzeitigen Arbeiten und gewinnen Zeit für die Problemlösung, falls etwas unerwartet schiefgeht. Die Verbindung von POD 1 nach dem Umschalten mit anderen PODs und DCI bleibt erhalten. Allerdings ziehen sich die Arbeiten lange hin; während dieser Zeit ist es erforderlich, einen Ingenieur für die physische Durchführung der Umschaltungen im Rechenzentrum bereitzustellen, und während der Arbeiten (die in der Regel nachts von 2 bis 5 Uhr durchgeführt werden) muss ein Online-Netzingenieur mit hoher Qualifikation verfügbar sein. Aber dafür erhalten wir kurze Verbindungsunterbrechungen; in der Regel können die Arbeiten innerhalb von einer halben Stunde mit Unterbrechungen von bis zu 2 Minuten durchgeführt werden (in der Praxis sind es oft 20-30 Sekunden beim erwarteten Verhalten der Geräte).
Im gezeigten Beispiel des Kunden C1 oder des Kunden C2 Es wird nötig sein, mindestens dreimal über die Arbeiten mit Unterbrechung der Verbindung zu informieren — das erste Mal für die Arbeiten an einem POD, in dem sich ein Server befindet, das zweite Mal für den zweiten, und das dritte Mal bei der Umschaltung der Geräte für DCI-Dienste.
Umschaltung der aggregierten Verbindungen
Warum wir über das erwartete Verhalten der Geräte sprechen und wie aggregierte Verbindungen mit minimalen Unterbrechungen umgeschaltet werden können. Stellen wir uns folgende Situation vor:
Auf der einen Seite der Verbindung — die Verteilungsschalter des POD — D1 und D2, die eine MLAG-Paarung (Stack, VCS-Fabrik, vPC-Paar) bilden, auf der anderen Seite zwei Verbindungen — Link 1 und Link 2 — die in die MLAG-Paarung der alten Aggregationsschalter eingebunden sind. AAuf der Seite der Schalter OS-Angriffen wurde ein aggregiertes Interface mit dem Namen Port-channel Agebildet; auf der Seite der Aggregationsschalter A ist das aggregierte Interface mit dem Namen Port-channel D.
Aggregierte Interfaces verwenden LACP für ihre Funktion, das heißt, die Switches auf beiden Seiten tauschen regelmäßig LACPDU-Pakete über beide Verbindungen aus, um sicherzustellen, dass die Verbindungen:
- betriebsbereit sind;
- in ein Paar Geräte auf der gegenüberliegenden Seite eingebunden sind.
Bei der Paketübertragung wird der Wert übergeben system-id, der das Gerät bezeichnet, in das diese Links integriert sind. Für ein MLAG-Paar (Stack, Fabrik usw.) ist der system-id-Wert für die Geräte, die die aggregierte Schnittstelle bilden, identisch. Der Switch D1 sendet an Link 1 den Wert system-id D, und der Switch D2 sendet an Link 2 den Wert system-id D.
Switches A1 und A2 analysieren die LACPDU-Pakete, die über eine Po D-Schnittstelle empfangen werden, und überprüfen die Übereinstimmung der system-id darin. Wenn die empfangene system-id über einen Link plötzlich von dem aktuellen Betriebswert abweicht, wird dieser Link aus der aggregierten Schnittstelle entfernt, bis die Situation behoben ist. Derzeit haben wir auf der Seite der Switches OS-Angriffen den aktuellen Wert der system-id vom LACP-Partner — A, und auf der Seite der Switches A — den aktuellen Wert der system-id vom LACP-Partner — OS-Angriffen.
Bei Bedarf an einen Wechsel der aggregierten Schnittstelle können wir auf zwei verschiedene Weise vorgehen:
Methode 1 — Einfach
Trennen Sie beide Links von den Switches A. Dabei funktioniert der aggregierte Kanal nicht.
Aktivieren Sie beide Links nacheinander in den Switches N, dann findet erneut eine Aushandlung der LACP-Betriebsparameter statt, und es wird eine Schnittstelle Po D auf den Switches gebildet. N und die Übertragung über die Links Wert system-id N.
Methode 2 — Minimierung der Unterbrechung
Von Switch A2 Link 2 trennen. Dabei wird der Verkehr zwischen A und OS-Angriffen weiterhin einfach über einen der Links übertragen, der Teil des aggregierten Interfaces bleibt.
Link 2 mit Switch N2 verbinden. Am Switch N ist bereits ein aggregiertes Interface eingerichtet Po DN, und der Switch N2 beginnt, in LACPDU zu übertragen system-id N. An dieser Stelle können wir bereits überprüfen, dass der Switch N2 korrekt mit dem Transceiver funktioniert, der für Link 2, dass der Anschlussport in den Zustand Up, und dass beim Übertragen von LACPDU keine Fehler am Anschlussport auftreten.
Aber die Tatsache, dass der Switch D2 für das aggregierte Interface Po A von Link 2 den Wert system-id N erhält, der sich von dem aktuellen Betriebswert system-id A unterscheidet, lässt die Switches OS-Angriffen nicht in das aggregierte Interface Link 2 . Der Switch Po Akann nicht in Betrieb genommen werden, da er keine Bestätigung über die Funktionsfähigkeit vom LACP-Partner des Switches erhält N kann nicht eingeben Link 2 . Der Verkehr wird letztendlich nicht über D2übertragen. Link 2 Nun trennen wir Link 1 vom Switch A1
, wodurch die Switches ausgeschlossen werden., wodurch Switches deaktiviert werden A und OS-Angriffen funktionierender aggregierter Schnittstelle. So wird auf der Seite des Switches OS-Angriffen der aktuelle Arbeitswert des system-id für die Schnittstelle fällt weg Po A.
Dies ermöglicht es den Switches OS-Angriffen und N eine Vereinbarung über den Austausch des system-id zu treffen A-N an den Schnittstellen Po A und Po DN, sodass der Verkehr über die Verbindung zu übertragen beginnt Link 2. Die Unterbrechung beträgt in diesem Fall praktisch bis zu 2 Sekunden.
Jetzt schalten wir Link 1 in den Switch N1, wodurch die Kapazität und die Redundanz der Schnittstellen wiederhergestellt werden Po A und Po DN. Da sich bei der Verbindung dieses Links der aktuelle Wert des system-id auf keiner Seite ändert, tritt keine Unterbrechung auf.
Zusätzliche Links
Aber der Wechsel kann ohne das Vorhandensein eines Ingenieurs zum Zeitpunkt des Wechsels durchgeführt werden. Dazu müssen wir im Voraus zusätzliche Links zwischen den Verteilungsswitchen OS-Angriffen und den neuen Aggregationsswitches verlegen N.
Wir verlegen neue Links zwischen den Aggregationsswitches N und den Verteilungsswitchen aller PODs. Dies erfordert die Bestellung und das Verlegen zusätzlicher Patchkabel sowie die Installation zusätzlicher Transceiver in Nals auch in OS-Angriffen. Wir können das tun, da wir in unseren Switches OS-Angriffen Jeder POD hat freie Ports (oder wir machen sie vorher frei). So ist jeder POD physisch mit zwei Verbindungen an die alten Switches A und an die neuen Switches N angeschlossen.
Am Switch OS-Angriffen wurden zwei aggregierte Schnittstellen gebildet — Po A mit Verbindungen Link 1 und Link 2, und Po N — mit Verbindungen Link N1 und Link N2. An diesem Punkt überprüfen wir die Richtigkeit der Verbindung der Schnittstellen und Links, die optischen Signalpegel an beiden Enden der Links (mittels DDM-Informationen von den Switches), wir können sogar die Funktionsfähigkeit des Links unter Last testen oder die Zustände der optischen Signale und Temperaturen der Transceiver über ein paar Tage hinweg überwachen.
Der Traffic wird weiterhin über die Schnittstelle Po A, während die Schnittstelle Po N ohne Traffic ist. Die Einstellungen der Schnittstellen sind etwa folgende:
Interface Port-channel A
Switchport mode trunk
Switchport allowed vlan C1, C2
Interface Port-channel N
Switchport mode trunk
Switchport allowed vlan noneSwitches D unterstützen in der Regel eine sitzungsbasierte Änderung der Konfiguration; es werden Modelle von Switches verwendet, die diese Funktion haben. So können wir die Einstellungen der Schnittstellen Po A und Po N in einem Schritt ändern:
Konfigurieren Sie die Sitzung
Schnittstelle Port-Kanal A
Switchport zulässige VLAN keine
Schnittstelle Port-Kanal N
Switchport zulässige VLAN C1, C2
BestätigenDann erfolgt die Änderungs-Konfiguration ausreichend schnell, und die Unterbrechung beträgt in der Praxis nicht mehr als 5 Sekunden.
Diese Methode ermöglicht es uns, alle Vorbereitungsarbeiten im Voraus durchzuführen, alle notwendigen Überprüfungen vorzunehmen, die Arbeiten mit den Beteiligten abzustimmen und die Maßnahmen zur Durchführung der Arbeiten detailliert zu prognostizieren, ohne kreative Flüge, wenn „alles schiefgeht“, und einen Plan zur Rückkehr zur vorherigen Konfiguration zur Hand zu haben. Die Arbeiten nach diesem Plan werden von einem Netzwerkingenieur durchgeführt, ohne dass ein Ingenieur des Rechenzentrums physisch anwesend ist, der die Umschaltungen vornimmt.
Was bei dieser Methode der Umschaltungen ebenfalls wichtig ist — alle neuen Links sind bereits im Voraus überwacht. Fehler, die Aktivierung der Links in der Aggregation, die Auslastung der Links — alle notwendigen Informationen befinden sich bereits im Überwachungssystem, und dies ist bereits auf den Karten visualisiert.
D-Day
PODs
Wir haben den für die Kunden am wenigsten schmerzhaften und am wenigsten fehleranfälligen Weg gewählt, um von zusätzlichen Links zu wechseln. So haben wir über ein paar Nächte alle PODs auf neue Aggregationsswitches umgeschaltet.
Es bleibt jedoch, die Geräte umzuschalten, die die DCI-Dienste bereitstellen.
L2
Im Fall der Geräte, die die L2-Konnektivität gewährleisten, konnten wir keine ähnlichen Arbeiten mit zusätzlichen Links durchführen. Dafür gibt es mindestens zwei Gründe:
- Mangel an freien Ports mit der benötigten Geschwindigkeit auf den VXLAN-Switches.
- Fehlende Funktionalität für die session-basierte Konfigurationsänderung auf den VXLAN-Switches.
Wir haben es nicht gewagt, die Links "nacheinander" mit einer Unterbrechung nur für die Abstimmung eines neuen Paar system-id umzuschalten, da wir keine 100%ige Sicherheit hatten, dass das Verfahren korrekt abläuft, und ein Test im Labor zeigte, dass, wenn "etwas schiefgeht", wir trotzdem eine Unterbrechung der Verbindung erhalten, und das Schlimmste ist — nicht nur für die Kunden, die L2-Konnektivität mit anderen Rechenzentren haben, sondern für alle Kunden dieses Rechenzentrums.
Wir haben im Voraus Öffentlichkeitsarbeit für den Übergang von L2-Kanälen geleistet, sodass die Anzahl der von den Arbeiten an den VXLAN-Switches betroffenen Kunden bereits mehrere Male geringer war als vor einem Jahr. Daher haben wir uns entschieden, die Verbindung für den L2-Konnektivitätsdienst zu unterbrechen, vorausgesetzt, dass die Dienste des lokalen Netzwerks in einem Rechenzentrum weiterhin normal funktionieren. Zudem sieht das SLA für diesen Dienst geplante Arbeiten mit Unterbrechungen vor.
L3
Warum haben wir allen empfohlen, auf die Verwendung von L3VPN für die DCI-Dienste umzusteigen? Ein Grund dafür ist die Möglichkeit, Arbeiten an einem der Router, die diesen Dienst anbieten, einfach mit einer Reduktion des Redundanzniveaus auf N+0 durchzuführen, ohne die Verbindung zu unterbrechen.
Lassen Sie uns das Schema der Bereitstellung des Dienstes näher betrachten. In diesem Dienst reicht das L2-Segment nur von den Client-Servern bis zu den L3VPN-Routern von Selectel. An den Routern endet das Kundennetzwerk.
Jeder Client-Server, zum Beispiel, S2 und S3 in dem dargestellten Schema hat seine privaten IP-Adressen — 10.0.0.2/24 für den Server S2 und 10.0.0.3/24 für den Server S3. Die Adressen 10.0.0.252/24 und 10.0.0.253/24 sind von Selectel den Routern zugewiesen L3VPN-1 und L3VPN-2, entsprechend. Die IP-Adresse 10.0.0.254/24 ist die VRRP VIP-Adresse auf den Selectel-Routern.
Mehr Informationen zum L3VPN-Dienst finden Sie in unserem Blog.
Vor dem Umschalten sah alles ungefähr wie im Schema aus:
Zwei Router L3VPN-1 und L3VPN-2 waren mit dem alten Aggregationsswitch verbunden A. Der Master für die VRRP VIP-Adresse 10.0.0.254 ist der Router L3VPN-1. Er hat eine höhere Priorität für diese Adresse als der Router L3VPN-2.
unit 1006 {
description C2;
vlan-id 1006;
family inet {
address 10.0.0.252/24 {
vrrp-group 1 {
priority 200;
virtual-address 10.100.0.254;
preempt {
hold-time 120;
}
accept-data;
}
}
}
}Der Server S2 verwendet das Gateway 10.0.0.254 für die Kommunikation mit Servern an anderen Standorten. Somit hat das Trennen des Routers L3VPN-2 (natürlich nach dessen vorhergehender Abtrennung aus dem MPLS-Domain) keine Auswirkungen auf die Erreichbarkeit der Server des Kunden. In diesem Moment wird lediglich das Redundanzniveau des Schemas verringert.
Danach können wir den Router problemlos wieder anschließen L3VPN-2 an ein Paar Switches N. Links legen, Transceiver wechseln. Logische Schnittstellen des Routers, von denen die Funktionsfähigkeit der Kundenservices abhängt, sind bis zur Bestätigung, dass alles korrekt funktioniert, deaktiviert.
Nach der Überprüfung von Links, Transceivern, Signalstärken und Fehlern der Schnittstellen wird der Router wieder in Betrieb genommen, jedoch bereits an ein neues Paar von Switches angeschlossen.
Dann senken wir die VRRP-Priorität des Routers L3VPN-1, und die VIP-Adresse 10.0.0.254 wird auf den Router L3VPN-2 verschoben. Diese Arbeiten erfolgen ebenfalls ohne Unterbrechung der Verbindung.
Die Verschiebung 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 an das neue Paar von Aggregations-Switches anzuschließen. N.
Ob wir die VRRP VIP auf den Router L3VPN-1 zurückgeben oder nicht, ist eine andere Frage; und selbst wenn wir es zurückgeben, geschieht dies ohne Unterbrechung der Verbindung.
Gesamt
Nach all diesen Maßnahmen haben wir tatsächlich die Aggregations-Switches in einem unserer Rechenzentren ersetzt und dabei die Unterbrechungen für unsere Kunden minimiert.
Danach bleibt nur noch der Abbau. Abbau der alten Switches, Abbau der alten Verbindungen zwischen den Switches A und D, Abbau der Transceiver von diesen Verbindungen, Anpassung der Überwachung, Korrektur der Netzpläne in der Dokumentation und Überwachung.
Die Switches, Transceiver, Patchkabel, AOC und DAC, die nach den Umschaltungen übrig bleiben, können wir in anderen Projekten oder bei ähnlichen Umschaltungen verwenden.
„Natasha, wir haben alles umgeschaltet!“
Quelle: habr.com
