Kuidas kujundasime ja juurutasime Moskva kontoris Huawei uue võrgu, osa 3: serveritehas

Kahes eelmises osas (aeg, два) vaatasime, millistel põhimõtetel uus eritellimustehas ehitati, ja rääkisime kõikide töökohtade migratsioonist. Nüüd on aeg rääkida serveritehasest.

Varem meil eraldi serveritaristut ei olnud: serveri lülitid olid ühendatud samasse tuuma, mis kasutajate jaotuslülitid. Juurdepääsu kontroll viidi läbi virtuaalsete võrkude (VLAN) abil, VLAN-i marsruutimine viidi läbi ühes punktis - tuumas (vastavalt põhimõttele Kokkuvarisenud selgroog).

Vana võrguinfrastruktuur

Samaaegselt uue kontorivõrguga otsustasime ehitada uue serveriruumi ja selle jaoks eraldi uue tehase. See osutus väikeseks (kolm serverikappi), kuid järgis kõiki kaanoneid: eraldi tuum CE8850 lülititel, täielikult võrgustatud (selg-leht) topoloogia, racki ülaosa (ToR) CE6870 lülitid, eraldi paar. lülititest ülejäänud võrguga liidestamiseks (äärised). Ühesõnaga täielik hakkliha.

Uue serveritehase võrk

Otsustasime serveri SCS-ist loobuda, et ühendada serverid otse ToR-lülititega. Miks? Meil on juba kaks serveriruumi, mis on ehitatud serveri SCS-i abil ja saime aru, et see on:

• ebamugav kasutada (palju taasühendamisi, peate kaablilogi hoolikalt värskendama);
• kallis, kui arvestada plaatpaneelide poolt hõivatud ruumi;
• on takistuseks, kui on vaja tõsta serverite ühenduse kiirust (näiteks lülituda 1 Gbit/s ühendustelt üle vase 10 Gbit/s üle optilise).

Uude serveritehasesse kolides püüdsime eemalduda serverite ühendamisest kiirusega 1 Gbit/s ja piirdusime 10 Gbit liidestega. Peaaegu kõik vanad serverid, mis seda teha ei suuda, virtualiseeriti ja ülejäänud olid ühendatud gigabitise transiiveri kaudu 10 gigabitise porti. Arvutasime ja otsustasime, et see on odavam, kui paigaldada neile eraldi gigabitised lülitid.

ToR lülitid

Ka meie uude serveriruumi paigaldasime eraldi 24 pordiga ribavälise halduse (OOM) lülitid, üks iga riiuli kohta. See idee osutus väga heaks, kuid porte ei olnud piisavalt, järgmine kord paigaldame 48 pordiga OOM switchid.

Ühendame OOM-võrguga liidesed serverite kaughalduseks nagu iLO või Huawei terminoloogias iBMC. Kui server on kaotanud põhiühenduse võrguga, siis on selle liidese kaudu võimalik selleni jõuda. Samuti on OOM-lülititega ühendatud ToR-lülitite, temperatuuriandurite, UPS-i juhtliideste ja muude sarnaste seadmete juhtliidesed. OOM-võrku pääseb juurde eraldi tulemüüriliidese kaudu.

OOM võrguühendus

Serveri ja kasutajavõrkude sidumine

Eritellimusel tehases kasutatakse eraldi VRF-e erinevatel eesmärkidel - kasutajate tööjaamade ühendamiseks, videovalvesüsteemideks, multimeediasüsteemideks koosolekuruumides, stendide ja demoalade korraldamiseks jne.

Serveritehases on loodud veel üks VRF-ide komplekt:

• Tavaliste serverite ühendamiseks, kus ettevõtte teenused on juurutatud.
• Eraldi VRF, mille sees on juurutatud Internetist juurdepääsuga serverid.
• Eraldi VRF andmebaasiserverite jaoks, millele pääsevad juurde ainult teised serverid (näiteks rakendusserverid).
• Eraldi VRF meie meilisüsteemi jaoks (MS Exchange + Skype for Business).

Seega on meil VRF-ide komplekt kasutaja tehase poolel ja VRF-ide komplekt serveritehase poolel. Mõlemad komplektid on installitud ettevõtte tulemüüri (FW) klastritesse. ME-d on ühendatud nii serverikoe kui ka kasutajakanga piirilülititega (piirdelehtedega).

Tehaste liidestamine ME kaudu – füüsika

Tehaste liidestamine ME kaudu – loogika

Kuidas migratsioon läks?

Migratsiooni käigus ühendasime uue ja vana serveritehase andmesidetasandil, ajutiste magistraalide kaudu. Konkreetses VLAN-is asuvate serverite migreerimiseks lõime eraldi silddomeeni, mis hõlmas vana serveritehase VLAN-i ja uue serveritehase VXLAN-i.

Konfiguratsioon näeb välja umbes selline, kaks viimast rida on võtmetähtsusega:

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

Virtuaalsete masinate migratsioon

Seejärel migreeriti VMware vMotioni abil selle VLAN-i virtuaalmasinad vanadelt hüperviisoridelt (versioon 5.5) uutele (versioon 6.5). Samal ajal virtualiseeriti riistvaraservereid.

Kui proovite uuestiSeadistage MTU eelnevalt ja kontrollige suurte pakettide läbimist otsast lõpuni.

Vanas serverivõrgus kasutasime virtuaalset tulemüüri VMware vShield. Kuna VMware seda tööriista enam ei toeta, läksime vShieldilt riistvaratulemüüridele üle samal ajal, kui uude virtuaalfarmi migreerusime.

Pärast seda, kui vanas võrgus ei olnud kindlas VLAN-is ühtegi serverit, vahetasime marsruutimist. Varem tehti seda Collapsed Backbone tehnoloogia abil ehitatud vanal tuumal ja uues serveritehases Anycast Gateway tehnoloogiat.

Marsruutimise vahetamine

Pärast konkreetse VLAN-i marsruutimise vahetamist eraldati see silddomeenist ja jäeti vana ja uue võrgu vahelisest magistraalvõrgust välja, st see kolis täielikult uude serveritehasesse. Seega migreerisime umbes 20 VLAN-i.

Nii lõime uue võrgu, uue serveri ja uue virtualiseerimisfarmi. Ühes järgmistest artiklitest räägime sellest, mida me WiFi-ga tegime.

Maksim Klochkov
Võrguauditi ja kompleksprojektide grupi vanemkonsultant
Võrgulahenduste keskus
"Jet Infosüsteemid"

Allikas: www.habr.com