În cele două părți anterioare (, ) ne-am uitat la principiile pe care a fost construită noua fabrică la comandă și am vorbit despre migrarea tuturor locurilor de muncă. Acum este timpul să vorbim despre fabrica de servere.
Anterior, nu aveam nicio infrastructură de server separată: comutatoarele de server erau conectate la același nucleu ca și comutatoarele de distribuție a utilizatorilor. Controlul accesului a fost efectuat folosind rețele virtuale (VLAN-uri), rutarea VLAN a fost efectuată la un moment dat - pe nucleu (conform principiului ).
Veche infrastructură de rețea
Concomitent cu noua rețea de birouri, am decis să construim o nouă cameră de server și o nouă fabrică separată pentru aceasta. S-a dovedit a fi mic (trei dulapuri de server), dar în conformitate cu toate canoanele: un nucleu separat pe comutatoarele CE8850, o topologie complet mesh (coală-coală), switch-uri CE6870 în partea de sus a rack-ului (ToR), o pereche separată de comutatoare pentru interfaţarea cu restul reţelei (frunze de frontieră). Pe scurt, carne tocată completă.
Rețeaua noii fabrici de servere
Am decis să abandonăm serverul SCS în favoarea conectării serverelor direct la comutatoarele ToR. De ce? Avem deja două camere de server care sunt construite folosind serverul SCS și am realizat că acesta este:
- incomod de utilizat (multe reconectari, trebuie să actualizați cu atenție jurnalul de cablu);
- scump din punct de vedere al spațiului ocupat de panouri de corecție;
- este un obstacol atunci când este necesară creșterea vitezei de conectare a serverelor (de exemplu, treceți de la conexiuni de 1 Gbit/s pe cupru la 10 Gbit/s pe optice).
Când ne-am mutat la o nouă fabrică de servere, am încercat să ne îndepărtăm de conectarea serverelor la o viteză de 1 Gbit/s și ne-am limitat la interfețe de 10 Gbit. Aproape toate serverele vechi care nu pot face acest lucru au fost virtualizate, iar restul au fost conectate prin transceiver gigabit la porturi de 10 gigabit. Am făcut calculele și am decis că ar fi mai ieftin decât să le instalăm switch-uri gigabit separate.
Comutatoare ToR
De asemenea, în noua noastră cameră de servere, am instalat comutatoare separate de management out-of-band (OOM) cu 24 de porturi, unul pe rack. Această idee s-a dovedit a fi foarte bună, dar nu au fost suficiente porturi, data viitoare vom instala switch-uri OOM cu 48 de porturi.
Conectăm interfețe pentru gestionarea de la distanță a serverelor precum iLO, sau iBMC în terminologia Huawei, la rețeaua OOM. Dacă serverul și-a pierdut conexiunea principală la rețea, atunci va fi posibil să ajungeți la el prin această interfață. De asemenea, interfețele de control ale comutatoarelor ToR, senzorii de temperatură, interfețele de control UPS și alte dispozitive similare sunt conectate la comutatoarele OOM. Rețeaua OOM este accesibilă printr-o interfață firewall separată.
Conexiune la rețea OOM
Împerecherea rețelelor de server și utilizatori
Într-o fabrică personalizată, VRF-uri separate sunt utilizate în diferite scopuri - pentru conectarea stațiilor de lucru ale utilizatorilor, sistemelor de supraveghere video, sistemelor multimedia în sălile de ședințe, pentru organizarea de standuri și zone demonstrative etc.
Un alt set de VRF-uri a fost creat în fabrica de servere:
- Pentru a conecta servere obișnuite pe care sunt implementate servicii corporative.
- Un VRF separat, în cadrul căruia sunt implementate servere cu acces de pe Internet.
- Un VRF separat pentru serverele de baze de date care sunt accesate numai de alte servere (de exemplu, servere de aplicații).
- VRF separat pentru sistemul nostru de e-mail (MS Exchange + Skype for Business).
Deci avem un set de VRF-uri pe partea fabricii utilizatorului și un set de VRF-uri pe partea fabricii de server. Ambele seturi sunt instalate pe clustere de firewall corporative (FW). ME-urile sunt conectate la comutatoare de frontieră (frunze de graniță) atât ale fabricii de server, cât și ale fabricii de utilizator.
Interfațarea fabricilor prin ME - fizică
Interfațarea fabricilor prin ME - logica
Cum a decurs migrația?
În timpul migrării, am conectat fabricile de servere noi și vechi la nivel de legătură de date, prin trunk-uri temporare. Pentru a migra serverele situate într-un anumit VLAN, am creat un domeniu bridge separat, care includea VLAN-ul vechii fabrici de servere și VXLAN-ul noii fabrici de servere.
Configurația arată cam așa, ultimele două rânduri fiind cheie:
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
Migrarea mașinilor virtuale
Apoi, folosind VMware vMotion, mașinile virtuale din acest VLAN au fost migrate de la vechile hypervizoare (versiunea 5.5) la altele noi (versiunea 6.5). În același timp, serverele hardware au fost virtualizate.
Când încerci din nouConfigurați MTU-ul în avans și verificați trecerea pachetelor mari „de la capăt la capăt”.
În vechea rețea de servere, am folosit firewall-ul virtual VMware vShield. Deoarece VMware nu mai acceptă acest instrument, am trecut de la vShield la firewall-uri hardware în același timp cu migrarea la noua fermă virtuală.
După ce nu au mai rămas servere într-un anumit VLAN pe vechea rețea, am schimbat rutarea. Anterior, a fost realizat pe vechiul nucleu, construit folosind tehnologia Collapsed Backbone, iar în noua fabrică de servere am folosit tehnologia Anycast Gateway.
Comutare rutare
După comutarea de rutare pentru un anumit VLAN, acesta a fost deconectat de la domeniul bridge și exclus din trunchiul dintre rețelele vechi și noi, adică s-a mutat complet în noua fabrică de servere. Astfel, am migrat aproximativ 20 de VLAN-uri.
Așa că am creat o nouă rețea, un nou server și o nouă fermă de virtualizare. Într-unul din articolele următoare vom vorbi despre ce am făcut cu Wi-Fi.
Maxim Klochkov
Consultant senior al grupului de audit de rețea și proiecte complexe
Centrul de soluții de rețea
„Jet Infosystems”
Sursa: www.habr.com