Az előző két részben (, ) megvizsgáltuk, hogy milyen elvek alapján épült az új egyedi gyár, és beszéltünk az összes munkahely migrációjáról. Itt az ideje, hogy beszéljünk a szervergyárról.
Korábban nem volt külön szerverinfrastruktúránk: a szerverkapcsolók ugyanahhoz a maghoz csatlakoztak, mint a felhasználói disztribúciós kapcsolók. A hozzáférés-szabályozás virtuális hálózatok (VLAN) segítségével történt, a VLAN-útválasztás egy ponton - a magon (az elvnek megfelelően) ).
Régi hálózati infrastruktúra
Az új irodahálózattal egyidőben elhatároztuk, hogy új szerverszobát és külön új gyárat építünk hozzá. Kicsinek bizonyult (három szerverszekrény), de minden kánonnak megfelel: külön mag a CE8850 kapcsolókon, teljesen hálós (gerinc-levél) topológia, rack tetején (ToR) CE6870 kapcsolók, külön pár kapcsolók száma a hálózat többi részével való interfészhez (határok). Egyszóval komplett darált hús.
Az új szervergyár hálózata
Úgy döntöttünk, hogy elhagyjuk a szerver SCS-t, és a szervereket közvetlenül a ToR-kapcsolókhoz kapcsoljuk. Miért? Már van két szerverszobánk, amelyek szerver SCS használatával épülnek fel, és rájöttünk, hogy ez:
- kényelmetlen a használata (sok újracsatlakozás, gondosan frissítenie kell a kábelnaplót);
- drága a patch panelek által elfoglalt hely szempontjából;
- akadályt jelent, ha növelni kell a szerverek kapcsolati sebességét (például 1 Gbit/s-os rézkapcsolatról 10 Gbit/s-os optikai kapcsolatra váltani).
Amikor új szervergyárba költöztünk, igyekeztünk eltávolodni az 1 Gbit/s sebességű szerverek összekapcsolásától, és 10 Gbites interfészekre korlátozódtunk. Szinte az összes régi szervert, amely ezt nem tudta megtenni, virtualizáltuk, a többit gigabites adó-vevőn keresztül 10 gigabites portra kötötték. Kiszámoltuk, és úgy döntöttünk, hogy olcsóbb lenne, mintha külön gigabites switcheket telepítenénk nekik.
ToR kapcsolók
Szintén új szervertermünkben külön sávon kívüli felügyeleti (OOM) switcheket telepítettünk 24 porttal, rackenként egyet. Ez az ötlet nagyon jónak bizonyult, de nem volt elég port, legközelebb 48 portos OOM switcheket telepítünk.
A szerverek távoli felügyeletére szolgáló interfészeket, például az iLO-t vagy a Huawei terminológiájával iBMC-t csatlakoztatunk az OOM hálózathoz. Ha a szerver elvesztette fő kapcsolatát a hálózattal, akkor ezen az interfészen keresztül elérhető lesz. Ezenkívül a ToR kapcsolók, hőmérséklet-érzékelők, UPS vezérlő interfészek és más hasonló eszközök vezérlő interfészei az OOM kapcsolókhoz csatlakoznak. Az OOM hálózat különálló tűzfal interfészen keresztül érhető el.
OOM hálózati kapcsolat
Szerver és felhasználói hálózatok párosítása
Egy egyedi gyárban különálló VRF-eket használnak különböző célokra - felhasználói munkaállomások csatlakoztatására, videó megfigyelő rendszerekre, tárgyalótermekben lévő multimédiás rendszerekre, standok és bemutató területek rendezésére stb.
Egy másik VRF-készletet hoztak létre a szervergyárban:
- Normál szerverek csatlakoztatása, amelyeken vállalati szolgáltatások vannak telepítve.
- Különálló VRF, amelyen belül az internetről hozzáféréssel rendelkező szerverek kerülnek telepítésre.
- Külön VRF azokhoz az adatbázis-kiszolgálókhoz, amelyekhez csak más kiszolgálók (például alkalmazáskiszolgálók) férnek hozzá.
- Külön VRF a levelezőrendszerünkhöz (MS Exchange + Skype for Business).
Tehát van egy VRF-készletünk a felhasználói gyári oldalon, és egy VRF-készletünk a szervergyári oldalon. Mindkét készlet vállalati tűzfal (FW) fürtökre van telepítve. Az ME-k mind a kiszolgáló-, mind a felhasználói szövet határkapcsolóihoz (határlevelekhez) csatlakoznak.
A gyárak összekapcsolása az ME-n keresztül - fizika
A gyárak összekapcsolása ME-n keresztül - logika
Hogyan zajlott a migráció?
A migráció során az új és a régi szervergyárakat adatkapcsolati szinten, ideiglenes trönköken keresztül kapcsoltuk össze. Az adott VLAN-ban található szerverek migrálásához külön hídtartományt hoztunk létre, amely a régi szervergyár VLAN-ját és az új szervergyár VXLAN-ját tartalmazza.
A konfiguráció valahogy így néz ki, az utolsó két sor kulcsfontosságú:
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
Virtuális gépek migrációja
Ezután a VMware vMotion segítségével a VLAN virtuális gépeit a régi hipervizorokról (5.5-ös verzió) újakra (6.5-ös verzió) költöztették át. Ezzel egy időben a hardver szervereket is virtualizálták.
Amikor újra megpróbáljaÁllítsa be előre az MTU-t, és ellenőrizze a nagy csomagok áthaladását „végtől a végéig”.
A régi szerverhálózatban a VMware vShield virtuális tűzfalat használtuk. Mivel a VMware már nem támogatja ezt az eszközt, a vShieldről a hardveres tűzfalakra váltottunk, miközben áttértünk az új virtuális farmra.
Miután egy adott VLAN-ban nem maradt szerver a régi hálózaton, átváltottuk az útválasztást. Korábban a régi, Collapsed Backbone technológiával épített magon, az új szervergyárban pedig Anycast Gateway technológiát alkalmaztunk.
Útválasztás váltása
Miután egy adott VLAN-ra váltott útválasztást, leválasztották a hídtartományról, és kizárták a régi és új hálózatok közötti törzsből, azaz teljesen átkerült az új szervergyárba. Így körülbelül 20 VLAN-t migráltunk.
Így létrehoztunk egy új hálózatot, egy új szervert és egy új virtualizációs farmot. A következő cikkek egyikében arról fogunk beszélni, hogy mit csináltunk a Wi-Fi-vel.
Maxim Klochkov
A hálózati audit és komplex projektek csoport vezető tanácsadója
Hálózati megoldások központja
"Jet Inforendszerek"
Forrás: will.com