In unserem lokalen Netzwerkverbund hatten wir sechs Paar Arista DCS-7050CX3-32S-Switches und ein Paar Brocade VDX 6940-36Q-Switches. Es ist nicht so, dass wir durch die Brocade-Switches in diesem Netzwerk übermäßig belastet wurden, sie funktionieren und führen ihre Funktionen aus, aber wir bereiteten die vollständige Automatisierung einiger Aktionen vor und verfügten bei diesen Switches nicht über diese Fähigkeiten. Ich wollte auch von 40GE-Schnittstellen auf die Möglichkeit der Nutzung von 100GE umsteigen, um eine Reserve für die nächsten 2-3 Jahre zu schaffen. Deshalb haben wir beschlossen, Brocade durch Arista zu ersetzen.
Bei diesen Switches handelt es sich um LAN-Aggregations-Switches für jedes Rechenzentrum. An sie sind direkt Verteilungs-Switches (zweite Aggregationsebene) angeschlossen, die bereits lokale Top-of-Rack-Netzwerk-Switches in Racks mit Servern zusammenbauen.
Jeder Server ist mit einem oder zwei Zugriffsschaltern verbunden. Zugangs-Switches sind mit einem Paar Verteilungs-Switches verbunden (zwei Verteilungs-Switches und zwei physische Verbindungen vom Zugangs-Switch zu verschiedenen Verteilungs-Switches werden zur Redundanz verwendet).
Jeder Server kann von einem eigenen Client genutzt werden, daher wird dem Client ein separates VLAN zugewiesen. Das gleiche VLAN wird dann auf einem anderen Server dieses Clients in einem beliebigen Rack registriert. Das Rechenzentrum besteht aus mehreren solcher Reihen (PODs), jede Rackreihe verfügt über eigene Verteilerschalter. Anschließend werden diese Distributions-Switches mit Aggregation-Switches verbunden.
Kunden können einen Server in einer beliebigen Reihe bestellen; es ist unmöglich, im Voraus vorherzusagen, ob der Server in einer bestimmten Reihe in einem bestimmten Rack zugewiesen oder installiert wird, weshalb es in jedem Rechenzentrum etwa 2500 VLANs auf Aggregation-Switches gibt.
Geräte für DCI (Data-Center Interconnect) sind mit Aggregations-Switches verbunden. Es kann für L2-Konnektivität (ein Paar Switches, die einen VXLAN-Tunnel zu einem anderen Rechenzentrum bilden) oder für L3-Konnektivität (zwei MPLS-Router) vorgesehen sein.
Wie ich bereits geschrieben habe, war es zur Vereinheitlichung der Prozesse zur Automatisierung der Konfiguration von Diensten auf Geräten in einem Rechenzentrum erforderlich, die zentralen Aggregations-Switches zu ersetzen. Wir installierten neue Schalter neben den vorhandenen, kombinierten sie zu einem MLAG-Paar und begannen mit den Vorbereitungen für die Arbeit. Sie wurden sofort mit vorhandenen Aggregations-Switches verbunden, sodass sie über eine gemeinsame L2-Domäne in allen Client-VLANs verfügten.
Einzelheiten zur Schaltung
Benennen wir für genauere Angaben die alten Aggregationsschalter A1 и A2, neu - N1 и N2. Stellen wir uns das mal vor Pod 1 и Pod 4 Server eines Clients werden gehostet С1,Das Client-VLAN wird blau angezeigt. Dieser Client nutzt den L2-Konnektivitätsdienst mit einem anderen Rechenzentrum, sodass sein VLAN einem Paar VXLAN-Switches zugeführt wird.
Auftraggeber С2 hostet Server in Pod 2 и Pod 3,Das Client-VLAN ist dunkelgrün gekennzeichnet. Dieser Client nutzt auch einen Konnektivitätsdienst mit einem anderen Rechenzentrum, jedoch L3, sodass sein VLAN an ein Paar L3VPN-Router weitergeleitet wird.
Wir benötigen Client-VLANs, um zu verstehen, in welchen Phasen der Austauscharbeiten was passiert, wo die Kommunikationsunterbrechung auftritt und wie lange sie dauern kann. Das STP-Protokoll wird in diesem Schema nicht verwendet, da die Breite des Baums dafür in diesem Fall groß ist und die Konvergenz des Protokolls exponentiell mit der Anzahl der Geräte und Verbindungen zwischen ihnen zunimmt.
Alle über Doppelverbindungen verbundenen Geräte bilden einen Stack, ein MLAG-Paar oder eine VCS-Ethernet-Fabric. Für ein Paar L3VPN-Router werden solche Technologien nicht verwendet, da keine L2-Redundanz erforderlich ist; es reicht aus, dass sie über Aggregations-Switches über L2-Konnektivität untereinander verfügen.
Umsetzungsmöglichkeiten
Bei der Analyse der Optionen für weitere Veranstaltungen haben wir festgestellt, dass es mehrere Möglichkeiten gibt, diese Arbeit durchzuführen. Von einer globalen Unterbrechung im gesamten lokalen Netzwerk bis hin zu kleinen Unterbrechungen von buchstäblich 1–2 Sekunden in Teilen des Netzwerks.
Netzwerk, hör auf! Schalter, tauschen Sie sie aus!
Am einfachsten ist es natürlich, eine globale Kommunikationspause auf allen PODs und allen DCI-Diensten auszurufen und alle Verbindungen über die Switches umzuschalten А zu Schaltern N.
Abgesehen von der Unterbrechung, deren Zeitpunkt wir nicht zuverlässig vorhersagen können (ja, wir kennen die Anzahl der Verbindungen, aber wir wissen nicht, wie oft etwas schief gehen wird – von einem kaputten Patchkabel oder einem beschädigten Stecker bis hin zu einem fehlerhaften Port oder Transceiver). ) können wir immer noch nicht im Voraus vorhersagen, ob die Länge der an die alten Schalter A angeschlossenen Patchkabel DAC, AOC ausreicht, um sie zu den neuen Schaltern N zu erreichen, obwohl sie daneben stehen, aber immer noch ein wenig zu Seite und ob die gleichen Transceiver funktionieren /DAC/AOC von Brocade-Switches zu Arista-Switches.
Und das alles unter Bedingungen starken Drucks seitens der Kunden und des technischen Supports („Natasha, steh auf! Natasha, da funktioniert nicht alles! Natasha, wir haben schon mal an den technischen Support geschrieben, ganz ehrlich! Natasha, die haben schon alles fallen lassen ! Natasha, wie viele haben wir noch, wird es funktionieren? Natasha, wann wird es funktionieren?!"). Auch trotz der angekündigten Pause und Benachrichtigung der Kunden ist ein Zustrom von Anfragen zu diesem Zeitpunkt garantiert.
Stopp, 1-2-3-4!
Was wäre, wenn wir keine globale Unterbrechung, sondern eine Reihe kleinerer Kommunikationsunterbrechungen für POD- und DCI-Dienste ankündigen würden? Wechseln Sie in der ersten Pause zu Schaltern N nur Pod 1, im zweiten - in ein paar Tagen - Pod 2, dann noch ein paar Tage Pod 3Weiter POD 4…[N], dann VXLAN-Switches und dann L3VPN-Router.
Mit dieser Organisation der Schaltarbeit reduzieren wir die Komplexität einmaliger Arbeiten und erhöhen unsere Zeit zur Problemlösung, wenn plötzlich etwas schief geht. POD 1 bleibt nach dem Umschalten mit anderen PODs und DCIs verbunden. Aber die Arbeit selbst zieht sich lange hin; während dieser Arbeit im Rechenzentrum ist ein Techniker erforderlich, der die Umschaltung physisch durchführt, und während der Arbeiten (und solche Arbeiten werden in der Regel nachts von 2 bis 5 Uhr morgens) ist die Anwesenheit eines Online-Netzwerktechnikers mit relativ hohem Qualifikationsniveau erforderlich. Aber dann kommt es zu kurzen Kommunikationsunterbrechungen; in der Regel kann im Abstand von einer halben Stunde mit einer Pause von bis zu 2 Minuten gearbeitet werden (in der Praxis oft 20-30 Sekunden bei erwartetem Verhalten der Geräte).
Im Beispiel-Client С1 oder Kunde С2 Sie müssen mindestens dreimal vor Arbeiten mit Kommunikationsunterbrechung warnen – das erste Mal, um Arbeiten an einem POD durchzuführen, in dem sich einer seiner Server befindet, das zweite Mal – beim zweiten und das dritte Mal – wann Vermittlungsausrüstung für DCI-Dienste.
Wechsel aggregierter Kommunikationskanäle
Warum sprechen wir über das erwartete Verhalten von Geräten und wie aggregierte Kanäle umgeschaltet und gleichzeitig Kommunikationsunterbrechungen minimiert werden können? Stellen wir uns das folgende Bild vor:
Auf einer Seite der Verbindung befinden sich POD-Verteilungsschalter – D1 и D2, sie bilden miteinander ein MLAG-Paar (Stack, VCS-Factory, vPC-Paar), andererseits gibt es zwei Links - Link 1 и Link 2 – im MLAG-Paar alter Aggregations-Switches enthalten А. Auf der Schalterseite D eine aggregierte Schnittstelle mit dem Namen Port-Kanal A, auf der Seite der Aggregationsschalter А - Aggregierte Schnittstelle mit dem Namen Port-Kanal D.
Aggregierte Schnittstellen verwenden LACP in ihrem Betrieb, d. h. Switches auf beiden Seiten tauschen regelmäßig LACPDU-Pakete auf beiden Links aus, um sicherzustellen, dass die Links:
- Arbeiter
- in einem Gerätepaar auf der Remote-Seite enthalten.
Beim Austausch von Paketen trägt das Paket den Wert System-ID, Angabe des Geräts, auf dem diese Links enthalten sind. Für ein MLAG-Paar (Stack, Factory usw.) ist der System-ID-Wert für die Geräte, die die aggregierte Schnittstelle bilden, derselbe. Schalten D1 sendet an Link 1 Wert System-ID D, und wechseln D2 sendet an Link 2 Wert System-ID D.
Schalter A1 и A2 Analysieren Sie LACPDU-Pakete, die über eine Po-D-Schnittstelle empfangen werden, und prüfen Sie, ob die darin enthaltene System-ID übereinstimmt. Wenn sich die über einen Link empfangene System-ID plötzlich unterscheidet vom aktuellen Betriebswert, dann wird dieser Link von der aggregierten Schnittstelle entfernt, bis die Situation behoben ist. Jetzt auf unserer Switch-Seite D aktueller System-ID-Wert vom LACP-Partner - A, und auf der Schalterseite А — aktueller System-ID-Wert vom LACP-Partner — D.
Wenn wir die aggregierte Schnittstelle wechseln müssen, können wir dies auf zwei verschiedene Arten tun:
Methode 1 – einfach
Deaktivieren Sie beide Verbindungen über Schalter A. In diesem Fall funktioniert der aggregierte Kanal nicht.
Verbinden Sie beide Links nacheinander mit den Switches N, dann werden die LACP-Betriebsparameter erneut ausgehandelt und die Schnittstelle gebildet PoD an Schaltern N und Übertragung von Werten auf Links System-ID N.
Methode 2 – Unterbrechungen minimieren
Trennen Sie Link 2 vom Schalter A2. Gleichzeitig ist der Verkehr dazwischen А и D werden weiterhin einfach über einen der Links übertragen, der Teil der aggregierten Schnittstelle bleibt.
Verbinden Sie Link 2 mit Switch N2. Am Schalter N Die aggregierte Schnittstelle ist bereits konfiguriert Po DN, und wechseln N2 beginnt mit der Übertragung an LACPDU System-ID N. Zu diesem Zeitpunkt können wir bereits überprüfen, ob der Schalter funktioniert N2 Funktioniert ordnungsgemäß mit dem verwendeten Transceiver Link 2, dass der Verbindungsport in den Status eingetreten ist Upund dass bei der Übertragung von LACPDUs keine Fehler auf dem Verbindungsport auftreten.
Aber die Tatsache, dass der Schalter D2 für aggregierte Schnittstelle Po A durch Link 2 empfängt einen System-ID-N-Wert, der sich vom aktuellen Betriebssystem-ID-A-Wert unterscheidet, erlaubt keine Schalter D vorstellen Link 2 Teil der aggregierten Schnittstelle Po A. Schalten N kann nicht eintreten Link 2 in Betrieb genommen werden, da er vom LACP-Partner des Switches keine Bestätigung der Funktionsfähigkeit erhält D2. Der resultierende Verkehr ist Link 2 nicht durchkommen.
Und jetzt schalten wir Link 1 über Schalter A1 aus, wodurch die Schalter entzogen werden А и D funktionierende Aggregatschnittstelle. Also auf der Schalterseite D Der aktuell funktionierende System-ID-Wert für die Schnittstelle verschwindet Po A.
Dies ermöglicht Schalter D и N Stimmen Sie dem Austausch der System-ID zu EIN auf Schnittstellen Po A и Po DN, sodass der Datenverkehr entlang der Verbindung übertragen wird Link 2. Die Pause beträgt in diesem Fall in der Praxis bis zu 2 Sekunden.
Und jetzt können wir Link 1 ganz einfach auf Switch N1 umstellen, wodurch die Kapazität und der Grad der Schnittstellenredundanz wiederhergestellt werden Po A и Po DN. Da sich bei der Verbindung dieser Verbindung der aktuelle System-ID-Wert auf beiden Seiten nicht ändert, kommt es zu keiner Unterbrechung.
Zusätzliche Links
Der Wechsel kann jedoch ohne die Anwesenheit eines Technikers zum Zeitpunkt des Wechsels durchgeführt werden. Dazu müssen wir im Vorfeld zusätzliche Verbindungen zwischen Verteilerschaltern verlegen D und neue Aggregationsschalter N.
Wir legen neue Verbindungen zwischen Aggregationsschaltern her N und Verteilerschalter für alle PODs. Dies erfordert die Bestellung und Verlegung zusätzlicher Patchkabel sowie die Installation zusätzlicher Transceiver wie in Nund in D. Wir können dies tun, weil in unseren Schaltern D Jeder POD verfügt über freie Ports (oder wir geben sie vorab frei). Dadurch ist jeder POD physisch über zwei Verbindungen mit den alten Switches A und den neuen Switches N verbunden.
Am Schalter D Es wurden zwei aggregierte Schnittstellen gebildet - Po A mit Links Link 1 и Link 2Und Po N - mit Links Link N1 и Link N2. In dieser Phase überprüfen wir die korrekte Verbindung von Schnittstellen und Verbindungen, die Pegel der optischen Signale an beiden Enden der Verbindungen (über DDM-Informationen von den Switches), wir können sogar die Leistung der Verbindung unter Last überprüfen oder deren Zustände überwachen optische Signale und Transceiver-Temperaturen für ein paar Tage.
Der Datenverkehr wird weiterhin über die Schnittstelle gesendet Po A, und die Schnittstelle Po N kostet keinen Verkehr. Die Einstellungen an den Schnittstellen sind etwa so:
Interface Port-channel A
Switchport mode trunk
Switchport allowed vlan C1, C2
Interface Port-channel N
Switchport mode trunk
Switchport allowed vlan noneD-Switches unterstützen in der Regel sitzungsbasierte Konfigurationsänderungen; es werden Switch-Modelle verwendet, die über diese Funktionalität verfügen. So können wir die Einstellungen der Po A- und Po N-Schnittstellen in einem Schritt ändern:
Configure session
Interface Port-channel A
Switchport allowed vlan none
Interface Port-channel N
Switchport allowed vlan C1, C2
CommitDann erfolgt die Konfigurationsänderung schnell genug und die Pause beträgt in der Praxis nicht mehr als 5 Sekunden.
Diese Methode ermöglicht es uns, alle vorbereitenden Arbeiten im Voraus abzuschließen, alle notwendigen Kontrollen durchzuführen, die Arbeit mit den Prozessbeteiligten zu koordinieren, die Aktionen für die Arbeitsproduktion im Detail vorherzusagen, ohne Kreativitätsflüge, wenn „alles schief gelaufen ist.“ ” und halten Sie einen Plan für die Rückkehr zur vorherigen Konfiguration bereit. Die Arbeiten nach diesem Plan werden von einem Netzwerktechniker durchgeführt, ohne dass ein Rechenzentrumstechniker vor Ort sein muss, der die Umschaltung physisch durchführt.
Wichtig bei dieser Art der Umstellung ist auch, dass alle neuen Links bereits im Vorfeld überwacht werden. Fehler, Aufnahme von Links in die Einheit, Laden von Links – alle notwendigen Informationen sind bereits im Monitoringsystem vorhanden und werden auch bereits auf den Karten eingezeichnet.
D-Day
POD
Wir haben mit zusätzlichen Links den für Kunden am wenigsten schmerzhaften Umstellungspfad gewählt und am wenigsten anfällig für „etwas ist schief gelaufen“-Szenarien. Also haben wir innerhalb weniger Nächte alle PODs auf neue Aggregations-Switches umgestellt.
Es bleibt jedoch nur noch, die Geräte auszutauschen, die DCI-Dienste bereitstellen.
L2
Bei Geräten mit L2-Konnektivität konnten wir ähnliche Arbeiten mit zusätzlichen Verbindungen nicht durchführen. Dafür gibt es mindestens zwei Gründe:
- Mangel an freien Ports mit der erforderlichen Geschwindigkeit auf VXLAN-Switches.
- Fehlende Funktionalität zum Ändern der Sitzungskonfiguration auf VXLAN-Switches.
Wir haben die Links nicht „einen nach dem anderen“ mit einer Unterbrechung gewechselt, nur während wir uns auf ein neues System-ID-Paar geeinigt haben, da wir nicht hundertprozentig sicher waren, dass der Vorgang korrekt ablaufen würde, und ein Test im Labor zeigte, dass dies der Fall war Wenn „etwas schief geht“, kommt es immer noch zu einer Verbindungsunterbrechung, und das Schlimmste ist nicht nur für Clients, die über L100-Konnektivität mit anderen Rechenzentren verfügen, sondern im Allgemeinen für alle Clients dieses Rechenzentrums.
Wir haben den Übergang von L2-Kanälen im Vorfeld propagiert, sodass die Zahl der von Arbeiten an VXLAN-Switches betroffenen Clients bereits um ein Vielfaches geringer war als vor einem Jahr. Aus diesem Grund haben wir uns entschieden, die Kommunikation über den L2-Verbindungsdienst zu unterbrechen, sofern wir den normalen Betrieb der lokalen Netzwerkdienste in einem Rechenzentrum aufrechterhalten. Darüber hinaus sieht das SLA für diesen Service die Möglichkeit vor, geplante Arbeiten mit Unterbrechungen durchzuführen.
L3
Warum haben wir jedem empfohlen, bei der Organisation von DCI-Diensten auf L3VPN umzusteigen? Einer der Gründe ist die Möglichkeit, Arbeiten an einem der Router durchzuführen, die diesen Dienst bereitstellen, indem einfach die Redundanzstufe auf N+0 reduziert wird, ohne die Kommunikation zu unterbrechen.
Werfen wir einen genaueren Blick auf das Servicebereitstellungsschema. Bei diesem Dienst reicht das L2-Segment nur von Client-Servern zu L3VPN Selectel-Routern. Das Client-Netzwerk wird auf Routern terminiert.
Jeder Client-Server, z.B. S2 и S3 im obigen Diagramm haben ihre eigenen privaten IP-Adressen - 10.0.0.2/24 auf Server S2 и 10.0.0.3/24 auf Server S3. Adressen 10.0.0.252/24 и 10.0.0.253/24 wird von Selectel den Routern zugewiesen L3VPN-1 и L3VPN-2, jeweils. IP Adresse 10.0.0.254/24 ist eine VRRP-VIP-Adresse auf Selectel-Routern.
Erfahren Sie mehr über den L3VPN-Dienst in unserem Blog.
Vor der Umstellung sah alles ungefähr so aus wie im Diagramm:
Zwei Router L3VPN-1 и L3VPN-2 waren mit dem alten Aggregation-Switch verbunden А. Der Master für die VRRP-VIP-Adresse 10.0.0.254 ist der Router L3VPN-1. Er hat für diese Adresse eine höhere Priorität 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 S2-Server verwendet Gateway 10.0.0.254, um mit Servern an anderen Standorten zu kommunizieren. Daher hat das Trennen des L3VPN-2-Routers vom Netzwerk (natürlich, wenn er zuerst von der MPLS-Domäne getrennt wird) keinen Einfluss auf die Konnektivität der Server des Clients. An diesem Punkt wird der Redundanzgrad der Schaltung einfach reduziert.
Danach können wir den Router sicher wieder verbinden L3VPN-2 an ein Schalterpaar N. Verbindungen verlegen, Transceiver wechseln. Die logischen Schnittstellen des Routers, von denen der Betrieb der Client-Dienste abhängt, werden deaktiviert, bis bestätigt wird, dass alles ordnungsgemäß funktioniert.
Nach Überprüfung der Links, Transceiver, Signalpegel und Fehlerpegel an den Schnittstellen wird der Router in Betrieb genommen, jedoch bereits mit einem neuen Switch-Paar verbunden.
Als nächstes senken wir die VRRP-Priorität des L3VPN-1-Routers und die VIP-Adresse 10.0.0.254 wird auf den L3VPN-2-Router verschoben. Auch diese Arbeiten werden ohne Kommunikationsunterbrechung durchgeführt.
Übertragen der VIP-Adresse 10.0.0.254 an den Router L3VPN-2 ermöglicht Ihnen, den Router zu deaktivieren L3VPN-1 ohne Unterbrechung der Kommunikation für den Client und verbinden Sie ihn mit einem neuen Paar von Aggregations-Switches N.
Ob VRRP VIP an den L3VPN-1-Router zurückgegeben werden soll oder nicht, ist eine andere Frage, und selbst wenn es zurückgegeben wird, erfolgt dies ohne Unterbrechung der Verbindung.
Insgesamt
Nach all diesen Schritten haben wir tatsächlich die Aggregations-Switches in einem unserer Rechenzentren ersetzt und gleichzeitig die Unterbrechungen für unsere Kunden minimiert.
Bleibt nur noch die Demontage. Demontage alter Switches, Demontage alter Verbindungen zwischen Switch A und D, Demontage von Transceivern aus diesen Verbindungen, Korrektur des Monitorings, Korrektur von Netzwerkplänen in Dokumentation und Monitoring.
Wir können Schalter, Transceiver, Patchkabel, AOC, DAC, die nach dem Umschalten in anderen Projekten oder für andere ähnliche Umschaltungen übrig bleiben, verwenden.
„Natasha, wir haben alles vertauscht!“
Source: habr.com