У папярэдніх дзвюх частках (, ) мы разгледзелі прынцыпы, на аснове якіх пабудавана новая карыстацкая фабрыка, і распавялі пра міграцыю ўсіх працоўных месцаў. Цяпер прыйшла пара пагаварыць аб сервернай фабрыцы.
Раней ніякай асобнай сервернай інфраструктуры ў нас не было: серверныя камутатары былі падлучаныя да таго ж ядру, што і карыстацкія камутатары размеркавання. Размежаванне доступу ажыццяўлялася з дапамогай віртуальных сетак (VLAN), маршрутызацыя VLAN праводзілася ў адной кропцы – на ядры (па прынцыпе ).
Старая сеткавая інфраструктура
Адначасова з новай сеткай офіса мы вырашылі пабудаваць новую серверную, і для яе - асобную новую фабрыку. Яна атрымалася невялікая (тры серверных шафы), але з захаваннем усіх канонаў: асобнае ядро на камутатарах CE8850, полносвязная (spine-leaf) тапалогія, top of the rack (ToR)-камутатары CE6870, асобная пара камутатараў для спалучэння з астатняй сеткай ( leaves). Карацей, поўны фарш.
Сетка новай сервернай фабрыкі
Мы вырашылі адмовіцца ад сервернай СКС у карысць падлучэння сервераў непасрэдна ў ToR-камутатары. Чаму? У нас ужо ёсць дзве серверныя, якія пабудаваны з ужываннем сервернай СКС, і мы зразумелі, што гэта:
- няёмка ў эксплуатацыі (шмат перакамутацый, трэба акуратна абнаўляць кабельны часопіс);
- накладна з пункту гледжання месца, займанага камутацыйнымі панэлямі;
- з'яўляецца перашкодай пры неабходнасці павялічыць хуткасць падлучэння сервераў (напрыклад, перайсці з падлучэнняў 1 Гбіт/з па медзі на 10 Гбіт/з па оптыцы).
Пры пераходзе на новую серверную фабрыку мы пастараліся сысці ад падлучэння сервераў на хуткасці 1 Гбіт/з і абмежаваліся 10-гігабітнымі інтэрфейсамі. Віртуалізавалі амаль усе старыя серверы, якія так не ўмеюць, а астатнія праз гігабітныя трансіверы падлучылі ў 10-гігабітныя парты. Мы палічылі і вырашылі, што гэта будзе танней, чым ставіць для іх асобныя гігабітныя камутатары.
Камутатары ToR
Таксама ў нашай новай сервернай мы ўсталявалі асобныя камутатары out-of-band management (OOM) на 24 порта, па адным на стойку. Гэта ідэя апынулася вельмі добрай, вось толькі партоў аказалася замала, у наступны раз усталюем камутатары OOM на 48 партоў.
У сетку OOM у нас падлучаюцца інтэрфейсы выдаленага кіравання серверамі тыпу iLO, ці iBMC па тэрміналогіі Huawei. Калі сервер страціў асноўнае злучэнне з сеткай, тое дастукацца да яго можна будзе па такім інтэрфейсе. Таксама ў камутатары OOM падлучаюцца кіраўнікі інтэрфейсы камутатараў ToR, датчыкі тэмпературы, кіраўнікі інтэрфейсы КБС і іншыя падобныя прылады. Сетка OOM даступная праз асобны інтэрфейс міжсеткавых экранаў.
Падключэнне сеткі OOM
Спалучэнне сервернай і карыстацкай сетак
У карыстацкай фабрыцы для розных мэт выкарыстоўваюцца асобныя VRF - для падлучэння працоўных месцаў карыстачоў, сістэм відэаназірання, мультымедыйных сістэм у перамоўных, для арганізацыі стэндаў і дэмазон, і т. п.
У сервернай фабрыцы створаны іншы набор VRF:
- Для падлучэння звычайных сервераў, на якіх разгорнутыя карпаратыўныя сэрвісы.
- Асобны VRF, у рамках якога разгортваюцца серверы з доступам з інтэрнэту.
- Асобны VRF для сервераў баз дадзеных, да якіх звяртацца толькі іншыя серверы (напрыклад, серверы дадаткаў).
- Асобны VRF пад нашу паштовую сістэму (MS Exchange + Skype for Business).
Такім чынам, у нас ёсць набор VRF з боку карыстацкай фабрыкі і набор VRF з боку сервернай фабрыкі. Абодва набору заведзены на кластары карпаратыўных міжсеткавых экранаў (МЭ). МЭ падлучаныя да памежных камутатараў (border leaves) як сервернай фабрыкі, так і карыстацкай фабрыкі.
Спалучэнне фабрык праз МЭ - фізіка
Спалучэнне фабрык праз МЭ - логіка
Як праходзіла міграцыя
У ходзе міграцыі мы злучылі новую і старую серверныя фабрыкі на канальным узроўні, праз часовыя транкі. Для міграцыі сервераў, размешчаных у вызначаным VLAN, мы стваралі асобны bridge-дамен, у які ўключалі VLAN старой сервернай фабрыкі і VXLAN новай сервернай фабрыкі.
Канфігурацыя выглядае прыкладна так, ключавымі з'яўляюцца два апошнія радкі:
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
Міграцыя віртуальных машын
Затым з дапамогай VMware vMotion мігравалі віртуальныя машыны ў гэтым VLAN са старых гіпервізораў (версіі 5.5) на новыя (версіі 6.5). Адначасна віртуалізавалі апаратныя серверы.
Калі паспрабуеце паўтарыцьЗагадзя наладзьце MTU і праверце праходжанне вялікіх пакетаў "end to end".
У старой сервернай сетцы мы карысталіся віртуальным МЭ VMware vShield. Паколькі кампанія VMware больш не падтрымлівае гэты інструмент, то адначасова з міграцыяй на новую віртуальную ферму мы перайшлі з vShield на апаратныя міжсеткавыя экраны.
Пасля таго, як у пэўным VLAN у старой сетцы не заставалася ніводнага сервера, мы перамыкалі маршрутызацыю. Раней яна ажыццяўлялася на старым ядры, пабудаваным па тэхналогіі Collapsed Backbone, а ў новай сервернай фабрыцы мы выкарыстоўвалі тэхналогію Anycast Gateway.
Пераключэнне маршрутызацыі
Пасля пераключэння маршрутызацыі для вызначанага VLAN ён адключаўся ад bridge-дамена і выключаўся з транка паміж старой і новай сеткай, т. е. цалкам пераходзіў у новую серверную фабрыку. Такім чынам мы мігравалі каля 20 VLAN.
Так мы стварылі новую сетку, новую серверную і новую ферму віртуалізацыі. У адной з наступных артыкулаў мы раскажам аб тым, што зрабілі з Wi-Fi.
Максім Клачкоў
Старэйшы кансультант групы сеткавага аўдыту і комплексных праектаў
Цэнтра сеткавых рашэнняў
«Інфасістэмы Джэт»
Крыніца: habr.com