I de två föregående delarna (, ) vi tittade på principerna som den nya anpassade fabriken byggdes på och pratade om migreringen av alla jobb. Nu är det dags att prata om serverfabriken.
Tidigare hade vi ingen separat serverinfrastruktur: serverswitchar var anslutna till samma kärna som användardistributionsväxlarna. Åtkomstkontroll utfördes med hjälp av virtuella nätverk (VLAN), VLAN-routing utfördes vid ett tillfälle - på kärnan (enligt principen ).
Gammal nätverksinfrastruktur
Samtidigt med det nya kontorsnätverket beslutade vi att bygga ett nytt serverrum och en separat ny fabrik för det. Det visade sig vara litet (tre serverskåp), men i överensstämmelse med alla kanoner: en separat kärna på CE8850-omkopplare, en helt maskad (ryggrads-) topologi, toppen av racket (ToR) CE6870-omkopplare, ett separat par av switchar för gränssnitt med resten av nätverket (kantblad). Kort sagt komplett köttfärs.
Nätverk för den nya serverfabriken
Vi bestämde oss för att överge server SCS till förmån för att ansluta servrar direkt till ToR-switchar. Varför? Vi har redan två serverrum som är byggda med server SCS, och vi insåg att detta är:
- obekvämt att använda (många återanslutningar, du måste noggrant uppdatera kabelloggen);
- dyrt i termer av utrymme upptaget av patchpaneler;
- är ett hinder när det är nödvändigt att öka anslutningshastigheten för servrar (byta till exempel från 1 Gbit/s anslutningar över koppar till 10 Gbit/s över optiska).
När vi flyttade till en ny serverfabrik försökte vi gå bort från att ansluta servrar med en hastighet av 1 Gbit/s och begränsade oss till 10 Gbit-gränssnitt. Nästan alla gamla servrar som inte kan göra detta var virtualiserade, och resten var anslutna via gigabit-sändtagare till 10 gigabit-portar. Vi gjorde uträkningen och bestämde oss för att det skulle vara billigare än att installera separata gigabit-switchar för dem.
ToR-omkopplare
Också i vårt nya serverrum installerade vi separata out-of-band management (OOM) switchar med 24 portar, en per rack. Denna idé visade sig vara mycket bra, men det fanns inte tillräckligt med portar, nästa gång kommer vi att installera OOM-switchar med 48 portar.
Vi kopplar gränssnitt för fjärrhantering av servrar som iLO, eller iBMC i Huawei-terminologi, till OOM-nätverket. Om servern har förlorat sin huvudsakliga anslutning till nätverket, kommer det att vara möjligt att nå den via detta gränssnitt. Styrgränssnitt för ToR-omkopplare, temperatursensorer, UPS-kontrollgränssnitt och andra liknande enheter är också anslutna till OOM-omkopplare. OOM-nätverket är tillgängligt via ett separat brandväggsgränssnitt.
OOM nätverksanslutning
Para ihop server- och användarnätverk
I en skräddarsydd fabrik används separata VRF:er för olika ändamål - för att koppla ihop användararbetsstationer, videoövervakningssystem, multimediasystem i mötesrum, för att organisera montrar och demoområden, etc.
Ytterligare en uppsättning VRF:er har skapats i serverfabriken:
- För att ansluta vanliga servrar på vilka företagstjänster är utplacerade.
- En separat VRF, inom vilken servrar med åtkomst från Internet är utplacerade.
- En separat VRF för databasservrar som endast nås av andra servrar (till exempel applikationsservrar).
- Separat VRF för vårt mailsystem (MS Exchange + Skype for Business).
Så vi har en uppsättning VRF:er på användarens fabrikssida och en uppsättning VRF:er på serverfabrikssidan. Båda uppsättningarna är installerade på företagsbrandväggskluster (FW). ME:er är anslutna till border switchar (border leaves) för både serverstrukturen och användarstrukturen.
Gränssnitt fabriker genom ME - fysik
Gränssnitt fabriker genom ME - logik
Hur gick migrationen?
Under migreringen kopplade vi upp de nya och gamla serverfabrikerna på datalänknivå, genom tillfälliga trunkar. För att migrera servrar placerade i ett specifikt VLAN skapade vi en separat bryggdomän, som inkluderade VLAN för den gamla serverfabriken och VXLAN för den nya serverfabriken.
Konfigurationen ser ut ungefär så här, de två sista raderna är nyckeln:
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
Migrering av virtuella maskiner
Sedan, med hjälp av VMware vMotion, migrerades virtuella maskiner i detta VLAN från gamla hypervisorer (version 5.5) till nya (version 6.5). Samtidigt virtualiserades hårdvaruservrar.
När du försöker igenKonfigurera MTU i förväg och kontrollera passagen av stora paket "ände till slut".
I det gamla servernätverket använde vi den virtuella brandväggen VMware vShield. Eftersom VMware inte längre stöder detta verktyg, bytte vi från vShield till hårdvarubrandväggar samtidigt som vi migrerade till den nya virtuella farmen.
Efter att det inte fanns några servrar kvar i ett visst VLAN på det gamla nätverket bytte vi routing. Tidigare utfördes det på den gamla kärnan, byggd med Collapsed Backbone-teknik, och i den nya serverfabriken använde vi Anycast Gateway-teknik.
Växla routing
Efter att ha bytt routing för ett specifikt VLAN kopplades det bort från bryggdomänen och uteslöts från trunk mellan det gamla och det nya nätverket, det vill säga att det helt flyttades till den nya serverfabriken. Således migrerade vi cirka 20 VLAN.
Så vi skapade ett nytt nätverk, en ny server och en ny virtualiseringsfarm. I en av följande artiklar kommer vi att prata om vad vi gjorde med Wi-Fi.
Maxim Klochkov
Seniorkonsult i gruppen för nätverksrevision och komplexa projekt
Nätverkslösningscenter
"Jet Infosystems"
Källa: will.com