In de vorige twee delen (, ) keken we naar de principes waarop de nieuwe fabriek op maat was gebouwd, en spraken we over de migratie van alle banen. Nu is het tijd om over de serverfabriek te praten.
Voorheen hadden we geen aparte serverinfrastructuur: serverswitches waren op dezelfde kern aangesloten als de gebruikersdistributieswitches. Toegangscontrole werd uitgevoerd met behulp van virtuele netwerken (VLAN's), VLAN-routering werd op één punt uitgevoerd - op de kern (volgens het principe ).
Oude netwerkinfrastructuur
Gelijktijdig met het nieuwe kantorennetwerk hebben we besloten om er een nieuwe serverruimte en een aparte nieuwe fabriek voor te bouwen. Het bleek klein te zijn (drie serverkasten), maar in overeenstemming met alle canons: een aparte kern op CE8850-switches, een volledig meshed (spine-leaf) topologie, top of the rack (ToR) CE6870-switches, een apart paar aantal switches voor interface met de rest van het netwerk (borderbladeren). Kortom, compleet gehakt.
Netwerk van de nieuwe serverfabriek
We hebben besloten server-SCS te verlaten en servers rechtstreeks met ToR-switches te verbinden. Waarom? We hebben al twee serverruimtes die zijn gebouwd met server-SCS, en we realiseerden ons dat dit het volgende is:
- onhandig in gebruik (veel heraansluitingen, u moet het kabellogboek zorgvuldig bijwerken);
- duur in termen van ruimte die wordt ingenomen door patchpanelen;
- is een obstakel wanneer het nodig is om de serververbindingssnelheid te verhogen (bijvoorbeeld overstappen van 1 Gbit/s-verbindingen over koper naar 10 Gbit/s over optisch).
Toen we naar een nieuwe serverfabriek verhuisden, probeerden we af te stappen van het verbinden van servers met een snelheid van 1 Gbit/s en beperkten we ons tot 10 Gbit-interfaces. Bijna alle oude servers die dit niet konden, waren gevirtualiseerd en de rest was via gigabit-transceivers verbonden met 10 gigabit-poorten. We hebben het berekend en besloten dat het goedkoper zou zijn dan het installeren van afzonderlijke gigabit-switches ervoor.
ToR-schakelaars
Ook in onze nieuwe serverruimte hebben we aparte out-of-band management (OOM) switches geïnstalleerd met 24 poorten, één per rack. Dit idee bleek erg goed, maar er waren niet genoeg poorten, de volgende keer zullen we OOM-switches met 48 poorten installeren.
Interfaces voor het beheer op afstand van servers zoals iLO, of iBMC in Huawei-terminologie, koppelen wij aan het OOM-netwerk. Als de server de hoofdverbinding met het netwerk heeft verloren, is het mogelijk deze via deze interface te bereiken. Ook zijn besturingsinterfaces van ToR-schakelaars, temperatuursensoren, UPS-besturingsinterfaces en andere soortgelijke apparaten aangesloten op OOM-schakelaars. Het OOM-netwerk is toegankelijk via een aparte firewallinterface.
OOM-netwerkverbinding
Koppelen van server- en gebruikersnetwerken
In een fabriek op maat worden afzonderlijke VRF's voor verschillende doeleinden gebruikt - voor het verbinden van gebruikerswerkstations, videobewakingssystemen, multimediasystemen in vergaderruimtes, voor het organiseren van stands en demoruimtes, enz.
Er is nog een set VRF's gemaakt in de serverfabriek:
- Om reguliere servers te verbinden waarop bedrijfsdiensten worden ingezet.
- Een aparte VRF, waarbinnen servers met toegang vanaf internet worden ingezet.
- Een aparte VRF voor databaseservers die alleen toegankelijk zijn voor andere servers (bijvoorbeeld applicatieservers).
- Aparte VRF voor ons mailsysteem (MS Exchange + Skype for Business).
We hebben dus een set VRF's aan de kant van de gebruikersfabriek en een set VRF's aan de kant van de serverfabriek. Beide sets worden geïnstalleerd op bedrijfsfirewallclusters (FW). ME's zijn verbonden met grensschakelaars (border leaves) van zowel de serverinfrastructuur als de gebruikersinfrastructuur.
Fabrieken met elkaar verbinden via ME - natuurkunde
Fabrieken met elkaar verbinden via ME - logica
Hoe is de migratie verlopen?
Tijdens de migratie hebben we de nieuwe en oude serverfabrieken op datalinkniveau met elkaar verbonden via tijdelijke trunks. Om servers die zich in een specifiek VLAN bevinden te migreren, hebben we een apart bridgedomein gemaakt, dat het VLAN van de oude serverfabriek en het VXLAN van de nieuwe serverfabriek omvatte.
De configuratie ziet er ongeveer zo uit, waarbij de laatste twee regels cruciaal zijn:
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
Migratie van virtuele machines
Vervolgens zijn met behulp van VMware vMotion virtuele machines in dit VLAN gemigreerd van oude hypervisors (versie 5.5) naar nieuwe (versie 6.5). Tegelijkertijd werden hardwareservers gevirtualiseerd.
Wanneer u het opnieuw probeertConfigureer de MTU vooraf en controleer de doorgang van grote pakketten “end-to-end”.
In het oude servernetwerk gebruikten we de virtuele firewall VMware vShield. Omdat VMware deze tool niet langer ondersteunt, zijn we tegelijk met de migratie naar de nieuwe virtuele farm overgestapt van vShield naar hardwarefirewalls.
Nadat er op het oude netwerk geen servers meer waren in een bepaald VLAN, zijn we overgestapt op routing. Voorheen werd dit uitgevoerd op de oude core, gebouwd met Collapsed Backbone-technologie, en in de nieuwe serverfabriek gebruikten we Anycast Gateway-technologie.
Wisselroutering
Nadat de routering voor een specifiek VLAN was gewijzigd, werd deze losgekoppeld van het bridge-domein en uitgesloten van de trunk tussen het oude en nieuwe netwerk, dat wil zeggen dat het volledig naar de nieuwe serverfabriek werd verplaatst. Daarom hebben we ongeveer 20 VLAN's gemigreerd.
Daarom hebben we een nieuw netwerk, een nieuwe server en een nieuwe virtualisatieboerderij gecreëerd. In een van de volgende artikelen zullen we praten over wat we met wifi hebben gedaan.
Maxim Klochkov
Senior consultant van de groep netwerkaudit en complexe projecten
Netwerkoplossingencentrum
"Jet-infosystemen"
Bron: www.habr.com