En la antaŭaj du partoj (, ) ni rigardis la principojn sur kiuj la nova kutima fabriko estis konstruita, kaj parolis pri la migrado de ĉiuj laborpostenoj. Nun estas tempo paroli pri la servila fabriko.
Antaŭe, ni ne havis apartan servilan infrastrukturon: servilŝaltiloj estis konektitaj al la sama kerno kiel la uzantdistribuoŝaltiloj. Kontrolo de aliro estis farita per virtualaj retoj (VLANoj), VLAN-vojigo estis efektivigita ĉe unu punkto - sur la kerno (laŭ la principo ).
Malnova reto infrastrukturo
Samtempe kun la nova oficeja reto, ni decidis konstrui novan servilan ĉambron kaj apartan novan fabrikon por ĝi. Ĝi rezultis esti malgranda (tri servilaj kabinetoj), sed konforme al ĉiuj kanonoj: aparta kerno sur CE8850-ŝaltiloj, plene maŝita (dorno-folia) topologio, supro de la rako (ToR) CE6870-ŝaltiloj, aparta paro. de ŝaltiloj por interfacado kun la resto de la reto (limaj folioj). Mallonge, kompleta hakaĵo.
Reto de la nova servila fabriko
Ni decidis forlasi servilon SCS favore al konekti servilojn rekte al ToR-ŝaltiloj. Kial? Ni jam havas du servilĉambrojn, kiuj estas konstruitaj per servilo SCS, kaj ni rimarkis, ke ĉi tio estas:
- maloportuna uzi (multaj rekonektoj, vi devas zorge ĝisdatigi la kablan protokolon);
- multekosta laŭ spaco okupita de flikpaneloj;
- estas malhelpo kiam necesas pliigi la konekton de serviloj (ekzemple, ŝanĝi de 1 Gbit/s konektoj super kupro al 10 Gbit/s super optika).
Moviĝante al nova servila fabriko, ni provis malproksimigi de konekti servilojn kun rapido de 1 Gbit/s kaj limigis nin al 10 Gbit-interfacoj. Preskaŭ ĉiuj malnovaj serviloj, kiuj ne povas fari tion, estis virtualigitaj, kaj la ceteraj estis konektitaj per gigabitaj transceptoroj al 10 gigabitaj havenoj. Ni faris la matematikon kaj decidis, ke ĝi estus pli malmultekosta ol instali apartajn gigabit-ŝaltilojn por ili.
ToR-ŝaltiloj
Ankaŭ en nia nova servila ĉambro, ni instalis apartajn ekster-bandan administradon (OOM) ŝaltilojn kun 24 havenoj, unu por rako. Ĉi tiu ideo montriĝis tre bona, sed ne estis sufiĉe da havenoj, venontfoje ni instalos OOM-ŝaltilojn kun 48 havenoj.
Ni konektas interfacojn por fora administrado de serviloj kiel iLO, aŭ iBMC laŭ Huawei-terminologio, al la OOM-reto. Se la servilo perdis sian ĉefan konekton al la reto, tiam eblos atingi ĝin per ĉi tiu interfaco. Ankaŭ, kontrolinterfacoj de ToR-ŝaltiloj, temperatursensiloj, UPS-kontrolinterfacoj kaj aliaj similaj aparatoj estas konektitaj al OOM-ŝaltiloj. La OOM-reto estas alirebla per aparta fajromurinterfaco.
OOM Reta Konekto
Parigo de servilo kaj uzantretoj
En kutima fabriko, apartaj VRF-oj estas uzataj por malsamaj celoj - por konekti uzantajn laborstaciojn, videogvatajn sistemojn, plurmediajn sistemojn en kunvenejoj, por organizi standojn kaj demo-areojn ktp.
Alia aro de VRF-oj estis kreita en la servilfabriko:
- Konekti regulajn servilojn sur kiuj kompaniaj servoj estas deplojitaj.
- Aparta VRF, ene de kiu serviloj kun aliro de la Interreto estas deplojitaj.
- Aparta VRF por datumbazaj serviloj, kiuj estas nur alireblaj de aliaj serviloj (ekzemple, aplikaĵoserviloj).
- Aparta VRF por nia poŝta sistemo (MS Exchange + Skype por Komerco).
Do ni havas aron da VRF-oj ĉe la uzantfabrika flanko kaj aro da VRF-oj ĉe la servila fabrikflanko. Ambaŭ aroj estas instalitaj sur kompaniaj fajroŝirmiloj (FW) aretoj. MEoj estas ligitaj al limŝaltiloj (limaj folioj) de kaj la servilŝtofo kaj la uzantŝtofo.
Interfaco de fabrikoj per ME - fiziko
Interfacado de fabrikoj per ME - logiko
Kiel iris la migrado?
Dum la migrado, ni konektis la novajn kaj malnovajn servilfabrikojn ĉe la datumliga nivelo, per provizoraj trunkoj. Por migri servilojn situantajn en specifa VLAN, ni kreis apartan pontan domajnon, kiu inkludis la VLAN de la malnova servila fabriko kaj la VXLAN de la nova servila fabriko.
La agordo aspektas kiel ĉi tio, la lastaj du linioj estas ŝlosilaj:
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
Migrado de virtualaj maŝinoj
Tiam, uzante VMware vMotion, virtualaj maŝinoj en ĉi tiu VLAN estis migritaj de malnovaj hiperviziiloj (versio 5.5) al novaj (versio 6.5). En la sama tempo, hardvarserviloj estis virtualigitaj.
Kiam vi provas ripetiAgordu la MTU anticipe kaj kontrolu la trairejon de grandaj pakaĵoj "fin al fino".
En la malnova servila reto, ni uzis la virtualan fajroŝirmilon VMware vShield. Ĉar VMware ne plu subtenas ĉi tiun ilon, ni ŝanĝis de vShield al aparataj fajroŝirmiloj samtempe ni migris al la nova virtuala bieno.
Post kiam ne restis serviloj en aparta VLAN en la malnova reto, ni ŝanĝis enrutadon. Antaŭe, ĝi estis efektivigita sur la malnova kerno, konstruita per Collapsed Backbone-teknologio, kaj en la nova servila fabriko ni uzis Anycast Gateway-teknologion.
Ŝanĝante envojigon
Post ŝanĝado de vojigo por specifa VLAN, ĝi estis malkonektita de la ponta domajno kaj ekskludita de la trunko inter la malnovaj kaj novaj retoj, t.e., ĝi tute translokiĝis al la nova servila fabriko. Tiel, ni migris ĉirkaŭ 20 VLANojn.
Do ni kreis novan reton, novan servilon kaj novan virtualigbienon. En unu el la sekvaj artikoloj ni parolos pri tio, kion ni faris per Wi-Fi.
Maksim Kloĉkov
Ĉefkonsultisto de la reto-revizio kaj kompleksaj projektogrupo
Centro de Retaj Solvoj
"Jetaj Infosistemoj"
fonto: www.habr.com