In die vorige twee dele (, ) ons het gekyk na die beginsels waarop die nuwe pasgemaakte fabriek gebou is, en oor die migrasie van alle werksgeleenthede gepraat. Nou is dit tyd om oor die bedienerfabriek te praat.
Voorheen het ons nie enige afsonderlike bedienerinfrastruktuur gehad nie: bedienerskakelaars was aan dieselfde kern gekoppel as gebruikersverspreidingskakelaars. Toegangsbeheer is uitgevoer met behulp van virtuele netwerke (VLAN's), VLAN-roetering is op een punt uitgevoer - op die kern (volgens die beginsel ).
Ou netwerkinfrastruktuur
Gelyktydig met die nuwe kantoornetwerk het ons besluit om 'n nuwe bedienerkamer te bou, en daarvoor 'n aparte nuwe fabriek. Dit blyk klein te wees (drie bedienerkaste), maar in ooreenstemming met al die kanonne: 'n aparte kern op die CE8850-skakelaars, 'n volmaas (ruggraat-blaar) topologie, bo-op die rek (ToR) CE6870-skakelaars, 'n aparte paar skakelaars vir verbinding met die res van die netwerk (grensblare). Kortom, 'n volledige gemors.
Nuwe bediener fabriek netwerk
Ons het besluit om die bediener SCS te laat vaar ten gunste daarvan om bedieners direk aan die ToR-skakelaars te koppel. Hoekom? Ons het reeds twee bedienerkamers wat gebou is met behulp van 'n bediener SCS, en ons het besef dat hulle:
- ongerieflik om te gebruik (baie skakeling, jy moet die kabelmagasyn noukeurig opdateer);
- duur in terme van ruimte wat deur pleisterpanele ingeneem word;
- is 'n struikelblok as jy die spoed van koppelbedieners moet verhoog (skakel byvoorbeeld van 1 Gb/s-verbindings oor koper na 10 Gb/s oor optika).
Toe ons na 'n nuwe bedienerfabriek verhuis het, het ons probeer wegkom daarvan om bedieners teen 'n spoed van 1 Gb / s te koppel en ons tot 10 Gb-koppelvlakke beperk. Gevirtualiseerde byna al die ou bedieners wat nie weet hoe nie, en die res deur gigabit-ontvangers wat aan 10-gigabit-poorte gekoppel is. Ons het bereken en besluit dat dit goedkoper sou wees as om aparte gigabit-skakelaars vir hulle te installeer.
ToR skakelaars
Ons het ook aparte 24-poort buite-band bestuur (OOM) skakelaars in ons nuwe bedienerkamer geïnstalleer, een per rek. Hierdie idee blyk baie goed te wees, net daar was nie genoeg poorte nie, volgende keer sal ons OOM-skakelaars vir 48 poorte installeer.
Ons koppel koppelvlakke vir afstandbestuur van bedieners soos iLO, of iBMC in Huawei-terminologie, aan die OOM-netwerk. As die bediener sy hoofverbinding met die netwerk verloor het, sal dit moontlik wees om dit deur hierdie koppelvlak te bereik. Beheerkoppelvlakke van ToR-skakelaars, temperatuursensors, UPS-beheerkoppelvlakke en ander soortgelyke toestelle word ook aan OOM-skakelaars gekoppel. Die OOM-netwerk is toeganklik deur 'n aparte firewall-koppelvlak.
Koppel die OOM-netwerk
Interkonneksie van bediener- en gebruikersnetwerke
In die gebruikersfabriek word aparte VRF's vir verskeie doeleindes gebruik - om gebruikerswerkplekke, videobewakingstelsels, multimediastelsels in vergaderlokale te verbind, om erwe en demonstrasiesones te organiseer, ens.
Nog 'n stel VRF's word in die bedienerfabriek geskep:
- Om gereelde bedieners te koppel wat korporatiewe dienste aanbied.
- 'n Aparte VRF waarbinne bedieners ontplooi word met toegang vanaf die internet.
- Aparte VRF vir databasisbedieners wat slegs deur ander bedieners (soos toepassingbedieners) verkry kan word.
- Aparte VRF vir ons posstelsel (MS Exchange + Skype for Business).
Ons het dus 'n VRF-stel van die gebruiker se fabriekskant en 'n VRF-stel van die bedienerfabriekskant af. Albei stelle is gekoppel aan groepe korporatiewe brandmure (ME). ME's is gekoppel aan grensskakelaars (grensblare) van beide die bedienerfabriek en die gebruikersfabriek.
Vervoeging van fabrieke deur ME - fisika
Koppel fabrieke deur ME - logika
Hoe was die migrasie
Tydens die migrasie het ons die nuwe en ou bedienerfabrieke op die dataskakelvlak deur middel van tydelike trunks verbind. Om bedieners wat in 'n spesifieke VLAN geleë is, te migreer, het ons 'n aparte brugdomein geskep, wat die VLAN van die ou bedienerfabriek en die VXLAN van die nuwe bedienerfabriek ingesluit het.
Die konfigurasie lyk iets soos hierdie, die laaste twee reëls is die sleutel:
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
Migreer virtuele masjiene
Toe, met behulp van VMware vMotion, het ons die virtuele masjiene in hierdie VLAN van die ou hipervisors (weergawe 5.5) na die nuwes (weergawe 6.5) gemigreer. Langs die pad, gevirtualiseerde hardeware-bedieners.
Wanneer jy probeer om te herhaalStel die MTU vooraf en kontroleer die deurgang van groot "end-tot-end"-pakkies.
In die ou bedienernetwerk het ons die VMware vShield virtuele firewall gebruik. Aangesien VMware nie meer hierdie nutsding ondersteun nie, het ons tegelykertyd met die migreer na 'n nuwe virtuele plaas oorgeskakel van vShield na hardeware firewalls.
Nadat daar nie 'n enkele bediener in 'n spesifieke VLAN in die ou netwerk oorgebly het nie, het ons roetering verander. Voorheen is dit op die ou kern uitgevoer, gebou met behulp van die Collapsed Backbone-tegnologie, en in die nuwe bedienerfabriek het ons die Anycast Gateway-tegnologie gebruik.
Skakel roetering
Nadat roetering vir 'n spesifieke VLAN omgeskakel is, is dit van die brugdomein ontkoppel en uit die stam tussen die ou en nuwe netwerke uitgesluit, dit wil sê, dit is heeltemal na die nuwe bedienerfabriek oorgeplaas. Ons het dus ongeveer 20 VLAN's gemigreer.
Ons het dus 'n nuwe netwerk, 'n nuwe bediener en 'n nuwe virtualisasieplaas geskep. In een van die volgende artikels sal ons praat oor wat ons met Wi-Fi gedoen het.
Maxim Klochkov
Senior konsultant, netwerkoudit en komplekse projektegroep
Netwerkoplossingsentrum
"Jet Infosystems"
Bron: will.com