In den beiden vorherigen Teilen (
Bisher hatten wir keine separate Serverinfrastruktur: Server-Switches waren mit demselben Kern verbunden wie die Benutzerverteilungs-Switches. Die Zugangskontrolle erfolgte über virtuelle Netzwerke (VLANs), das VLAN-Routing erfolgte an einer Stelle – am Kern (nach dem Prinzip).
Alte Netzwerkinfrastruktur
Gleichzeitig mit dem neuen Büronetzwerk beschlossen wir, dafür einen neuen Serverraum und eine separate neue Fabrik zu bauen. Es stellte sich heraus, dass es klein war (drei Serverschränke), aber in Übereinstimmung mit allen Regeln: ein separater Kern auf CE8850-Switches, eine vollständig vermaschte Topologie (Spine-Leaf), Top-of-the-Rack-Switches (ToR) CE6870, ein separates Paar von Switches zur Anbindung an den Rest des Netzwerks (Grenzblätter). Kurz gesagt, komplettes Hackfleisch.
Netzwerk der neuen Serverfabrik
Wir haben uns entschieden, Server-SCS aufzugeben und stattdessen Server direkt mit ToR-Switches zu verbinden. Warum? Wir haben bereits zwei Serverräume, die mit Server-SCS erstellt wurden, und wir haben festgestellt, dass dies der Fall ist:
- unpraktisch in der Verwendung (viele Neuverbindungen, Sie müssen das Kabelprotokoll sorgfältig aktualisieren);
- teuer im Hinblick auf den Platzbedarf der Patchpanels;
- ist ein Hindernis, wenn die Verbindungsgeschwindigkeit von Servern erhöht werden muss (z. B. Umstellung von 1-Gbit/s-Verbindungen über Kupfer auf 10 Gbit/s über optische Verbindungen).
Beim Umzug in eine neue Serverfabrik haben wir versucht, von der Anbindung von Servern mit einer Geschwindigkeit von 1 Gbit/s Abstand zu nehmen und uns auf 10-Gbit-Schnittstellen zu beschränken. Fast alle alten Server, die das nicht können, wurden virtualisiert, der Rest wurde über Gigabit-Transceiver an 10-Gigabit-Ports angebunden. Wir haben nachgerechnet und sind zu dem Schluss gekommen, dass es günstiger wäre, als separate Gigabit-Switches für sie zu installieren.
ToR-Schalter
Außerdem haben wir in unserem neuen Serverraum separate Out-of-Band-Management-Switches (OOM) mit 24 Ports installiert, einen pro Rack. Diese Idee erwies sich als sehr gut, aber es waren nicht genügend Ports vorhanden, das nächste Mal werden wir OOM-Switches mit 48 Ports installieren.
Wir verbinden Schnittstellen zur Fernverwaltung von Servern wie iLO, oder iBMC in der Huawei-Terminologie, mit dem OOM-Netzwerk. Sollte der Server seine Hauptverbindung zum Netzwerk verloren haben, ist er über diese Schnittstelle erreichbar. Außerdem werden Steuerschnittstellen von ToR-Switches, Temperatursensoren, USV-Steuerschnittstellen und anderen ähnlichen Geräten an OOM-Switches angeschlossen. Der Zugriff auf das OOM-Netzwerk erfolgt über eine separate Firewall-Schnittstelle.
OOM-Netzwerkverbindung
Koppeln von Server- und Benutzernetzwerken
In einer maßgeschneiderten Fabrik werden separate VRFs für unterschiedliche Zwecke verwendet – zum Anschluss von Benutzerarbeitsplätzen, Videoüberwachungssystemen, Multimediasystemen in Besprechungsräumen, zur Organisation von Ständen und Demobereichen usw.
In der Serverfabrik wurde ein weiterer Satz VRFs erstellt:
- Zum Verbinden regulärer Server, auf denen Unternehmensdienste bereitgestellt werden.
- Ein separates VRF, in dem Server mit Zugriff aus dem Internet bereitgestellt werden.
- Ein separates VRF für Datenbankserver, auf die nur andere Server zugreifen (z. B. Anwendungsserver).
- Separates VRF für unser Mailsystem (MS Exchange + Skype for Business).
Wir haben also eine Reihe von VRFs auf der Seite der Benutzerfabrik und eine Reihe von VRFs auf der Seite der Serverfabrik. Beide Sets werden auf Unternehmens-Firewall-Clustern (FW) installiert. MEs sind mit Grenzschaltern (Grenzblättern) sowohl der Server-Fabric als auch der Benutzer-Fabric verbunden.
Anbindung von Fabriken durch ME – Physik
Anbindung von Fabriken durch ME – Logik
Wie verlief die Migration?
Während der Migration haben wir die neuen und alten Serverfabriken auf Datenverbindungsebene über temporäre Trunks verbunden. Um Server in einem bestimmten VLAN zu migrieren, haben wir eine separate Bridge-Domäne erstellt, die das VLAN der alten Serverfabrik und das VXLAN der neuen Serverfabrik umfasste.
Die Konfiguration sieht in etwa so aus, wobei die letzten beiden Zeilen entscheidend sind:
bridge-domain 22
vxlan vni 600022
evpn
route-distinguisher 10.xxx.xxx.xxx:60022
vpn-target 6xxxx:60022 export-extcommunity
vpn-target 6xxxx:60022 import-extcommunity
interface Eth-Trunk1
mode lacp-static
dfs-group 1 m-lag 1
interface Eth-Trunk1.1022 mode l2
encapsulation dot1q vid 22
bridge-domain 22
Migration virtueller Maschinen
Anschließend wurden mithilfe von VMware vMotion virtuelle Maschinen in diesem VLAN von alten Hypervisoren (Version 5.5) auf neue (Version 6.5) migriert. Gleichzeitig wurden Hardware-Server virtualisiert.
Wenn Sie versuchen zu wiederholenKonfigurieren Sie die MTU im Voraus und überprüfen Sie den Durchgang großer Pakete „Ende zu Ende“.
Im alten Servernetzwerk verwendeten wir die virtuelle Firewall VMware vShield. Da VMware dieses Tool nicht mehr unterstützt, haben wir gleichzeitig mit der Migration auf die neue virtuelle Farm von vShield auf Hardware-Firewalls umgestellt.
Nachdem in einem bestimmten VLAN im alten Netzwerk keine Server mehr vorhanden waren, haben wir das Routing geändert. Zuvor wurde es auf dem alten Kern ausgeführt, der mit der Collapsed-Backbone-Technologie aufgebaut war, und in der neuen Serverfabrik verwendeten wir die Anycast-Gateway-Technologie.
Routing wechseln
Nachdem das Routing für ein bestimmtes VLAN umgestellt wurde, wurde es von der Bridge-Domäne getrennt und vom Trunk zwischen dem alten und dem neuen Netzwerk ausgeschlossen, d. h. es wurde vollständig in die neue Serverfabrik verschoben. Somit haben wir etwa 20 VLANs migriert.
Also haben wir ein neues Netzwerk, einen neuen Server und eine neue Virtualisierungsfarm erstellt. In einem der folgenden Artikel werden wir darüber sprechen, was wir mit Wi-Fi gemacht haben.
Maxim Klotschkow
Leitender Berater der Gruppe Netzwerkprüfung und komplexe Projekte
Netzwerklösungszentrum
„Jet-Infosysteme“
Source: habr.com