Wie wir das neue Netzwerk auf Huawei im Moskauer Büro entworfen und implementiert haben, Teil 3: Server Factory



In den beiden vorhergehenden Teilen ( eins , zwei ) haben wir die Prinzipien untersucht, auf deren Grundlage eine neue Benutzerfabrik gebaut wurde, und über die Migration aller Jobs gesprochen. Jetzt ist es Zeit, über die Serverfabrik zu sprechen.

Bisher hatten wir keine separate Serverinfrastruktur: Server-Switches waren mit demselben Kern verbunden wie Benutzerverteilungs-Switches. Die Zugriffskontrolle wurde über virtuelle Netzwerke (VLAN) durchgeführt, das VLAN-Routing wurde an einem Punkt durchgeführt - auf dem Kern (gemäß dem Collapsed Backbone- Prinzip).


Alte Netzwerkinfrastruktur

Zusammen mit dem neuen Büronetzwerk haben wir beschlossen, einen neuen Serverraum und dafür eine separate neue Fabrik zu bauen. Es stellte sich als klein heraus (drei Serverschränke), folgte jedoch allen Kanonen: ein separater Kern der CE8850-Switches, eine vollständig verbundene (Spine-Leaf-) Topologie, ToR-Kommutatoren CE6870, ein separates Switch-Paar für die Verbindung mit dem Rest des Netzwerks (Rand) Blätter). Kurz gesagt, volle Füllung.


Netzwerk der neuen Serverfabrik

Wir haben beschlossen, den Server-SCS aufzugeben, um die Server direkt mit den ToR-Switches zu verbinden. Warum? Wir haben bereits zwei Serverräume, die mit serverbasiertem SCS erstellt wurden, und wir haben festgestellt, dass dies:

  • unpraktisch im Betrieb (viel Umschalten, Sie müssen das Kabelprotokoll sorgfältig aktualisieren);
  • kostspielig in Bezug auf den Platz, den Patch-Panels einnehmen;
  • Erhöhen Sie gegebenenfalls die Geschwindigkeit der Serververbindung (wechseln Sie beispielsweise von 1-Gbit / s-Kupferverbindungen zu einer 10-Gbit / s-Optik).

Beim Umzug in eine neue Serverfabrik haben wir versucht, die Verbindung von Servern mit einer Geschwindigkeit von 1 Gbit / s zu unterbinden, und uns auf 10-Gigabit-Schnittstellen beschränkt. Virtualisierte fast alle alten Server, die nicht wissen wie, und den Rest über Gigabit-Transceiver, die mit 10-Gigabit-Ports verbunden sind. Wir haben berechnet und entschieden, dass dies billiger ist als die Installation separater Gigabit-Switches.


ToR-Schalter

Ebenfalls in unserem neuen Serverraum haben wir separate OOM-Switches (Out-of-Band Management) an 24 Ports installiert, einen pro Rack. Diese Idee erwies sich als sehr gut, nur die Ports waren nicht genug, das nächste Mal werden wir OOM-Switches für 48 Ports installieren.

Im OOM-Netzwerk verbinden wir Remoteverwaltungsschnittstellen für Server wie iLO oder iBMC gemäß der Huawei-Terminologie. Wenn der Server die Hauptverbindung zum Netzwerk verloren hat, können Sie diese über diese Schnittstelle erreichen. Die OOM-Switches verbinden auch ToR-Switch-Verwaltungsschnittstellen, Temperatursensoren, USV-Steuerschnittstellen und andere ähnliche Geräte. Auf das OOM-Netzwerk kann über eine separate Firewall-Schnittstelle zugegriffen werden.


OOM-Netzwerkverbindung

Pairing von Server- und Benutzernetzwerken


In einer benutzerdefinierten Fabrik werden separate VRFs für verschiedene Zwecke verwendet - zum Verbinden von Benutzerarbeitsplätzen, Videoüberwachungssystemen, Multimedia-Systemen in Besprechungsräumen, zum Organisieren von Ständen und Demozonen usw.

In der Serverfactory wurde ein anderer Satz von VRFs erstellt:

  • Zum Verbinden herkömmlicher Server, auf denen Unternehmensdienste bereitgestellt werden.
  • Separate VRF, in der Server mit Zugriff aus dem Internet bereitgestellt werden.
  • Separate VRF für Datenbankserver, auf die nur andere Server zugreifen (z. B. Anwendungsserver).
  • Separate VRF für unser Mailsystem (MS Exchange + Skype for Business).

Daher haben wir einen VRF-Satz von der Benutzerfabrikseite und einen VRF-Satz von der Serverfabrikseite. Beide Sets sind auf Unternehmensfirewalls (MEs) gruppiert. MEs sind an Grenzschalter sowohl der Serverfabrik als auch der Benutzerfabrik angeschlossen.


Schnittstellenfabriken durch ME - Physik


Schnittstellen von Fabriken durch ME - Logik

Wie verlief die Migration?


Während der Migration haben wir die neuen und alten Serverfabriken auf Kanalebene über temporäre Amtsleitungen verbunden. Um Server in einem bestimmten VLAN zu migrieren, haben wir eine separate Bridge-Domäne erstellt, die das VLAN der alten Serverfactory und das VXLAN der neuen Serverfactory enthält.

Die Konfiguration sieht ungefähr so ​​aus, der Schlüssel sind die letzten beiden Zeilen:

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 der virtuellen Maschine

Anschließend wurden mithilfe von VMware vMotion die virtuellen Maschinen in diesem VLAN von alten Hypervisoren (Version 5.5) auf neue (Version 6.5) migriert. Unterwegs wurden Hardwareserver virtualisiert.

Wenn Sie versuchen zu wiederholen
Konfigurieren Sie die MTU im Voraus und suchen Sie nach großen End-to-End-Paketen.

Im alten Servernetzwerk haben wir das virtuelle ME von VMware vShield verwendet. 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 im alten Netzwerk keine Server in einem bestimmten VLAN mehr vorhanden waren, haben wir das Routing umgestellt. Zuvor wurde es auf dem alten Kern implementiert, der mit der Collapsed Backbone-Technologie erstellt wurde, und in der neuen Serverfabrik haben wir die Anycast Gateway-Technologie verwendet.


Routing-Schalter

Nach dem Umschalten des Routings für ein bestimmtes VLAN wurde die Verbindung zur Bridge-Domäne getrennt und vom Trunk zwischen dem alten und dem neuen Netzwerk ausgeschlossen, d. H. Es wurde vollständig an die neue Serverfactory übertragen. Also haben wir ungefähr 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 Klochkov
Senior Consultant, Netzwerkaudit und integrierte Projekte
Network Solution Center
Jet Infosystems

Source: https://habr.com/ru/post/de462903/


All Articles