В мурунку маселе Мен тармакты автоматташтыруу негизин сүрөттөп бердим. Кээ бир адамдардын пикири боюнча, маселеге биринчи жолу мамиле кылуу да айрым суроолорду чечип койгон. Бул мени абдан кубандырат, анткени циклдеги биздин максат Python скрипттери менен Ansibleди жабуу эмес, системаны куруу.

Ошол эле алкак биз суроону чече турган тартипти белгилейт.
Жана бул маселе арналган тармак виртуалдаштыруу, биз автоматташтыруу талдоо ADSM темасына, өзгөчө туура келбейт.

Бирок, келгиле, башка жагынан карайлы.

Көптөгөн кызматтар бир эле тармакты көптөн бери колдонуп келишет. Байланыш оператору болсо, бул, мисалы, 2G, 3G, LTE, кең тилкелүү жана B2B. DC учурда: ар кандай кардарлар үчүн байланыш, Интернет, блокту сактоо, объект сактоо.

Жана бардык кызматтар бири-биринен обочолонууну талап кылат. Ушинтип кабатталган тармактар ​​пайда болгон.

Жана бардык кызматтар адамдын аларды кол менен конфигурациялоосун күткүсү келбейт. Оркестрлер жана SDN ушундайча пайда болгон.

Тармакты системалуу автоматташтырууга биринчи мамиле, тагыраак айтканда, анын бир бөлүгү көп жерлерде көптөн бери кабыл алынган жана ишке ашырылган: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Бул биз бүгүн чече турган нерсе.

ыраазы

• себептер
• терминология
• Underlay - физикалык тармак
• Overlay - виртуалдык тармак
  • ToR менен катмар
  • Хосттан кабатталган
  • Мисал катары вольфрам кездемесин колдонуу
    • Бир физикалык машинанын ичиндеги байланыш
    • Ар кандай физикалык машиналарда жайгашкан VMлердин ортосундагы байланыш
    • Тышкы дүйнөгө чыгуу

• FAQ
• жыйынтыктоо
• Пайдалуу шилтемелер

себептер

Жана биз бул жөнүндө сөз кылып жаткандыктан, тармакты виртуалдаштыруунун өбөлгөлөрү жөнүндө сөз кылуу керек. Чынында бул процесс кечээ башталган жок.

Тармак ар кандай системанын эң инерттүү бөлүгү болуп келгенин сиз бир нече жолу уккандырсыз. Жана бул бардык мааниде чындык. Тармак баары таянган негиз болуп саналат жана ага өзгөртүүлөрдү киргизүү абдан кыйын - тармак иштебей турганда кызматтар ага чыдабайт. Көбүнчө бир түйүндү колдонуудан чыгаруу тиркемелердин чоң бөлүгүн өчүрүп, көптөгөн кардарларга таасирин тийгизиши мүмкүн. Бул жарым-жартылай эмне үчүн тармак командасы кандайдыр бир өзгөрүүлөргө каршы тура алат - анткени азыр кандайдыр бир жол менен иштейт (биз кантип билбей калышыбыз мүмкүн), бирок бул жерде сиз жаңы нерсени конфигурациялашыңыз керек жана ал тармакка кандай таасир этээри белгисиз.

Тармакчылардын VLANдарды киргизүүсүн күтпөө жана ар бир тармак түйүнүндө эч кандай кызматтарды каттабоо үчүн, адамдар капталуучу тармактарды колдонуу идеясын ойлоп табышты, алардын ар кандай түрлөрү бар: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE ж.б.

Алардын кайрылуусу эки жөнөкөй нерседе жатат:

• Акыркы түйүндөр гана конфигурацияланган — транзиттик түйүндөргө тийүүнүн кереги жок. Бул процессти кыйла тездетет, ал эми кээде тармактык инфраструктура бөлүмүн жаңы кызматтарды киргизүү процессинен толугу менен чыгарып салууга мүмкүндүк берет.
• Жүктөм баштыктардын тереңинде катылган - транзиттик түйүндөр бул жөнүндө, хосттордогу даректер жөнүндө же капталган тармактын маршруттары жөнүндө эч нерсе билүүнүн кереги жок. Бул таблицаларда азыраак маалыматты сактоо керек дегенди билдирет, бул жөнөкөй/арзаныраак түзүлүштү колдонууну билдирет.

Бул толук эмес, толук кандуу маселеде мен мүмкүн болгон бардык технологияларды талдап чыгууну пландаган жокмун, тескерисинче, ДКдагы кабаттуу тармактардын иштешинин негизин сүрөттөп берем.

Бүткүл серия бир эле сервердик жабдуулар орнотулган окшош текчелердин катарларынан турган маалымат борборун сүрөттөйт.

Бул жабдуулар кызматтарды ишке ашырган виртуалдык машиналарды/контейнерлерди/серверсиз иштейт.

терминология

циклде сервер Мен кардар-сервер байланышынын сервердик тарабын ишке ашырган программаны атайм.

Стеллаждардагы физикалык машиналар серверлер деп аталат жок биз жасайбыз.

Физикалык машина — стойкага орнотулган x86 компьютери. Эң көп колдонулган термин кожоюн. Биз муну ушундай деп атайбыз "машина"же кожоюн.

Гипервизор - Виртуалдык машиналар иштеген физикалык ресурстарды эмуляциялоочу физикалык машинада иштеген тиркеме. Кээде адабиятта жана Интернетте "гипервизор" сөзү "хосттун" синоними катары колдонулат.

Виртуалдык машина - гипервизордун үстүндө физикалык машинада иштеген операциялык система. Бул циклде биз үчүн бул чындыгында виртуалдык машинабы же жөн эле контейнерби, бул маанилүү эмес. аны атайлы"М«

Ижарачы бул макалада мен өзүнчө кызмат же өзүнчө кардар катары аныктай турган кеңири түшүнүк.

Көп кабаттуу же көп ижаралык - бир эле тиркемени ар кандай кардарлар/кызматтар тарабынан колдонуу. Ошол эле учурда, кардарларды бири-биринен обочолонтуу өзүнчө иштеп жаткан инстанциялар аркылуу эмес, колдонмо архитектурасынын аркасында ишке ашат.

ToR — Рактын үстү - бардык физикалык машиналар туташтырылган стойкага орнотулган өчүргүч.

ToR топологиясынан тышкары, ар кандай провайдерлер катардын аягы (EoR) же катардын ортосун колдонушат (бирок акыркысы сейрек кездешүүчү жана MoR аббревиатурасын көргөн жокмун).

Негизги тармак же негизги тармак же астыңкы катмар физикалык тармак инфраструктурасы: өчүргүчтөр, роутерлор, кабелдер.

Overlay тармак же үстүнкү тармак же катмар - физикалык туннелдердин үстүндө иштеген виртуалдык тармак.

L3 кездеме же IP кездеме - STP кайталоодон качууга жана интервью үчүн TRILL үйрөнүүгө мүмкүндүк берген адамзаттын укмуштуудай ойлоп табуусу. Концепция, анда кирүү деңгээлине чейин бүт тармак VLANсыз жана ошого жараша чоң кеңейтилген уктуруу домендери жок гана L3. Кийинки бөлүмдө "фабрика" деген сөз кайдан келгенин карап чыгабыз.

SDN - Программалык камсыздоо менен аныкталган тармак. Кириш сөздүн кереги жок. Тармакты башкарууга болгон мамиле, тармакка өзгөртүүлөр адам тарабынан эмес, программа тарабынан жасалат. Адатта Control Plane акыркы тармак түзүлүштөрүнөн тышкары контроллерге жылдырууну билдирет.

NFV — Тармактык функцияларды виртуалдаштыруу — тармактык түзүлүштөрдү виртуалдаштыруу, жаңы кызматтарды ишке ашырууну тездетүү, Кызматтын чынжырын уюштуруу жана горизонталдык масштабдуулуктун жөнөкөйлөштүрүлүшү үчүн кээ бир тармак функцияларын виртуалдык машиналар же контейнерлер түрүндө иштетүүнү сунуштайт.

VNF - Виртуалдык тармак функциясы. Өзгөчө виртуалдык түзүлүш: роутер, коммутатор, брандмауэр, NAT, IPS/IDS ж.б.

Мен азыр окурманды ашыкча чаташтырбоо үчүн сыпаттаманы белгилүү бир ишке ашыруу үчүн жөнөкөйлөтүп жатам. Көбүрөөк ойлонуу үчүн, мен аны бөлүмгө кайрылам шилтемелер. Кошумчалай кетсек, бул макаланы так эместиги үчүн сындаган Рома Горге сервердик жана тармактык виртуалдаштыруу технологиялары жөнүндө өзүнчө маселени тереңирээк жана майда-чүйдөсүнө чейин жазууну убада кылат.

Бүгүнкү күндө көпчүлүк тармактарды эки бөлүккө бөлүүгө болот:

Астында — туруктуу конфигурациялуу физикалык тармак.
Каптама — Ижарачыларды обочолонтуу үчүн астындагы абстракция.

Бул DC (биз бул макалада талдайбыз) үчүн да, ISP үчүн да (аны талдабайбыз, анткени ал буга чейин эле SDSM). Ишкана тармактары менен, албетте, абал бир аз башкача.

Тармакка багытталган сүрөт:

Астында

Underlay физикалык тармак: аппараттык өчүргүчтөр жана кабелдер. Жер астындагы аппараттар физикалык машиналарга кантип жетүүнү билишет.

Ал стандарттык протоколдорго жана технологияларга таянат. Аппараттык түзүлүштөр ушул күнгө чейин микросхеманы программалоого же өзүнүн протоколдорун ишке ашырууга мүмкүндүк бербеген менчик программалык камсыздоодо иштешет, демек, башка сатуучулар менен шайкештик жана стандартташтыруу зарыл.

Бирок Google сыяктуу бирөө өз которгучтарын иштеп чыгып, жалпы кабыл алынган протоколдордон баш тарта алат. Бирок LAN_DC Google эмес.

Underlay салыштырмалуу сейрек өзгөрөт, анткени анын милдети физикалык машиналар ортосундагы негизги IP байланышы. Underlay анын үстүндө иштеген кызматтар, кардарлар же ижарачылар жөнүндө эч нерсе билбейт - ал пакетти бир машинадан экинчисине жеткирүү үчүн гана керек.
Төмөнкү төмөнкүдөй болушу мүмкүн:

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+TRILL
• L2+STP

Underlay тармагы классикалык түрдө конфигурацияланган: CLI/GUI/NETCONF.

Кол менен, скрипттер, проприетардык утилиталар.

Сериядагы кийинки макала кененирээк астыңкы катмарга арналат.

Каптама

Overlay - бул Underlay үстүнө созулган туннелдердин виртуалдык тармагы, ал бир кардардын VM'лерине башка кардарлардан обочолонууну камсыз кылуу менен бирге бири-бири менен байланышууга мүмкүндүк берет.

Кардардын маалыматтары коомдук тармак аркылуу өткөрүү үчүн кээ бир туннелдик аталыштарда камтылган.

Ошентип, бир кардардын (бир кызматтын) VM'лери пакеттин иш жүзүндө кандай жолду басып өткөнүн билбей туруп, бири-бири менен Overlay аркылуу байланыша алышат.

Мисалы, мен жогоруда айткандай, капталышы мүмкүн:

• GRE туннели
• VXLAN
• EVPN
• L3VPN
• ЖЕНЕВ

Кабаттуу тармак адатта борбордук контроллер аркылуу конфигурацияланат жана сакталат. Андан конфигурация, Control Plane жана Data Plane кардар трафигин багыттаган жана инкапсуляциялаган түзмөктөргө жеткирилет. Бир аз төмөндө Муну мисалдар менен карап көрөлү.

Ооба, бул эң таза түрүндө SDN.

Overlay тармагын уюштуруунун эки түп-тамырынан айырмаланган мамилеси бар:

1. ToR менен катмар
2. Хосттан кабатталган

ToR менен катмар

Кабаттоо, мисалы, VXLAN кездемесинде болгондой, стеллажда турган кирүү которгучунан (ToR) башталышы мүмкүн.

Бул ISP тармактарында убакыт сынагынан өткөн механизм жана бардык тармак жабдууларын сатуучулар аны колдошот.

Бирок, бул учурда ToR которуштуруусу ар кандай кызматтарды ажырата алышы керек жана тармак администратору белгилүү бир деңгээлде виртуалдык машинанын администраторлору менен кызматташып, түзмөктөрдүн конфигурациясына өзгөртүүлөрдү (автоматтык түрдө болсо да) киргизиши керек. .

Бул жерде мен окурманды макалага кайрылам Habré боюнча VxLAN биздин эски досубуз @bormoglotx.
бул ENOG менен презентациялар EVPN VXLAN ткани менен DC тармагын курууга болгон мамилелер деталдуу сүрөттөлгөн.

Ал эми чындыкка толук чөмүлүү үчүн, сиз Цисканын китебин окуй аласыз Заманбап, ачык жана масштабдуу кездеме: VXLAN EVPN.

Мен VXLAN бул бир гана инкапсуляция ыкмасы экенин белгилеймин жана туннелдердин токтотулушу ToRде эмес, мисалы, OpenStack окуясында болгондой, хостто болушу мүмкүн.

Бирок, VXLAN ткани, анда үстүнкү катмар ToRден башталат, белгиленген катмарлуу тармак дизайндарынын бири.

Хосттан кабатталган

Дагы бир ыкма - акыркы хосттордогу туннелдерди баштоо жана токтотуу.
Бул учурда, тармак (Underlay) мүмкүн болушунча жөнөкөй жана статикалык бойдон калууда.
Ал эми хост өзү бардык керектүү инкапсуляцияны жасайт.

Бул, албетте, хосттордо атайын тиркемени иштетүүнү талап кылат, бирок бул татыктуу.

Биринчиден, кардарды Linux машинасында иштетүү жеңилирээк же айталы, ал тургай мүмкүн, которгучта сиз көп сатуучу идеясын жок кылган жеке SDN чечимдерине кайрылышыңыз керек болот.

Экинчиден, бул учурда ToR которуштурууну башкаруу планы жана маалымат планы жагынан мүмкүн болушунча жөнөкөй калтырса болот. Чынында эле, анда SDN контроллери менен байланышуунун кереги жок, ошондой эле бардык туташкан кардарлардын тармактарын/ARPтерин сактоонун кереги жок - физикалык машинанын IP дарегин билүү жетиштүү, бул которуштурууну// маршруттук таблицалар.

ADSM сериясында мен хосттон кабатталган ыкманы тандайм - анда биз бул жөнүндө гана сүйлөшөбүз жана VXLAN фабрикасына кайтып келбейбиз.

Мисалдарды карап көрүү эң оңой. Ал эми сыноо предмети катары биз OpenSource SDN платформасын алабыз OpenContrail, азыр деп аталат Вольфрам кездеме.

Макаланын аягында мен OpenFlow жана OpenvSwitch менен окшоштуктар боюнча бир нече ойлорду берем.

Мисал катары вольфрам кездемесин колдонуу

Ар бир физикалык машина бар vRouter - ага туташкан тармактар ​​жана алар кайсы кардарларга таандык экенин билген виртуалдык роутер - негизинен PE роутер. Ар бир кардар үчүн ал обочолонгон маршруттук таблицаны жүргүзөт (VRF окуу). Жана vRouter чындыгында Overlay туннелдерин жасайт.

vRouter жөнүндө бир аз көбүрөөк маалымат макаланын аягында.

Гипервизордо жайгашкан ар бир VM бул машинанын vRouter менен туташтырылган TAP интерфейси.

TAP - Терминал кирүү чекити - тармактын өз ара аракеттенүүсүн камсыз кылган Linux ядросундагы виртуалдык интерфейс.

Эгерде vRouterдин артында бир нече тармактар ​​бар болсо, анда алардын ар бири үчүн виртуалдык интерфейс түзүлөт, ага IP дареги дайындалат - бул демейки шлюз дареги болот.
Бир кардардын бардык тармактары бирге жайгаштырылат VRF (бир стол), ар кандай - ар кандай.
Мен бул жерде бардыгы жөнөкөй эмес экенин билдирем жана мен макаланын аягына кызыккан окурманды жөнөтөм.

VRouters бири-бири менен байланыша алышы үчүн, демек, алардын артында жайгашкан VMлер, алар аркылуу маршруттук маалымат алмашышат. SDN контроллери.

Сырткы дүйнөгө чыгуу үчүн матрицадан чыгуу чекити бар - виртуалдык тармак шлюзи VNGW - Virtual Network GateWay (менин мөөнөтүм).

Эми байланыштын мисалдарын карап көрөлү - ошондо айкындык болот.

Бир физикалык машинанын ичиндеги байланыш

VM0 VM2ге пакет жөнөткүсү келет. Азырынча бул жалгыз кардар VM деп ойлойлу.

Data Plane

1. VM-0 өзүнүн eth0 интерфейсине демейки маршрутка ээ. Пакет ошол жакка жөнөтүлөт.
   Бул интерфейс eth0 чындыгында виртуалдык роутер vRouterге TAP интерфейси tap0 аркылуу туташтырылган.
2. vRouter пакеттин кайсы интерфейске келгенин, башкача айтканда, ал кайсы кардарга (VRF) таандык экенин талдап, алуучунун дарегин бул кардардын маршруттук таблицасы менен текшерет.
3. Ошол эле машинадагы алуучу башка портто экенин байкаган vRouter ага пакетти жөн гана кошумча аталыштарсыз жөнөтөт - бул учурда, vRouter мурунтан эле ARP жазуусу бар.

Бул учурда пакет физикалык тармакка кирбейт - ал vRouter ичинде багытталат.

Башкаруучу учак

Виртуалдык машина ишке киргенде, гипервизор ага мындай дейт:

• Анын өзүнүн IP дареги.
• Демейки маршрут бул тармактагы vRouterдин IP дареги аркылуу.

Гипервизор vRouterге атайын API аркылуу отчет берет:

• Виртуалдык интерфейсти түзүү үчүн эмне керек.
• Ал (VM) кандай виртуалдык тармакты түзүшү керек?
• Кайсы VRF (VN) менен байланыштыруу керек.
• Бул VM үчүн статикалык ARP жазуусу - анын IP дарегинин артында кайсы интерфейс турат жана ал кайсы MAC дареги менен байланышкан.

Кайрадан, иш жүзүндөгү өз ара аракеттенүү процедурасы түшүнүктү түшүнүү үчүн жөнөкөйлөтүлгөн.

Ошентип, vRouter берилген машинадагы бир кардардын бардык VM'лерин түздөн-түз туташкан тармактар ​​катары көрөт жана алардын ортосунда өзү багыт бере алат.

Бирок VM0 жана VM1 ар кандай кардарларга таандык жана, демек, ар кандай vRouter таблицаларында.

Алар бири-бири менен түз байланыша алабы же жокпу, бул vRouter орнотууларына жана тармактын дизайнына жараша болот.
Мисалы, эгерде эки кардар тең VM жалпы даректерди колдонсо же NAT vRouterдин өзүндө пайда болсо, анда vRouterге түз багыттоо жүргүзүлүшү мүмкүн.

Тескерисинче, дарек мейкиндиктерин кесип өтүүгө болот - жалпыга ачык даректи алуу үчүн NAT серверинен өтүш керек - бул төмөндө талкууланган тышкы тармактарга кирүүгө окшош.

Ар кандай физикалык машиналарда жайгашкан VMлердин ортосундагы байланыш

Data Plane

1. Башталышы дал ушундай: VM-0 демейки боюнча көздөгөн VM-7 (172.17.3.2) менен пакетти жөнөтөт.
2. vRouter аны кабыл алат жана бул жолу көздөгөн жер башка машинада экенин жана Tunnel0 аркылуу жеткиликтүү экенин көрөт.
3. Биринчиден, ал алыскы интерфейсти аныктоочу MPLS энбелгисин илип коёт, андыктан арткы жагында vRouter бул пакетти кошумча издөөсүз эле кайда жайгаштырууну аныктай алат.

   

4. Tunnel0 10.0.0.2 булагы бар, көздөгөн жери: 10.0.1.2.
   vRouter баштапкы пакетке GRE (же UDP) аталыштарын жана жаңы IP кошот.
5. vRouter багыттоо жадыбалында ToR1 дареги 10.0.0.1 аркылуу демейки маршрут бар. Ошол жакка жөнөтөт.

   
   

6. ToR1, Underlay тармагынын мүчөсү катары, 10.0.1.2ге кантип жетүүнү билет (мисалы, OSPF аркылуу) жана пакетти маршрут боюнча жөнөтөт. Бул жерде ECMP иштетилгенин эске алыңыз. Иллюстрацияда эки кийинки бөлүм бар жана ар кандай жиптер аларга хэш боюнча иргелет. Чыныгы заводдун шартында 4 кийинки цех болушу мумкун.

   Ошол эле учурда, ал тышкы IP аталышынын астында эмне бар экенин билиши керек эмес. Башкача айтканда, чындыгында, IP астында Ethernet аркылуу MPLS аркылуу IPv6 сэндвичи болушу мүмкүн.

7. Демек, кабыл алуучу тарапта vRouter GREди алып салат жана MPLS тегин колдонуп, бул пакет кайсы интерфейске жөнөтүлүшү керектигин түшүнүп, аны ажыратып, аны баштапкы түрүндө алуучуга жөнөтөт.

Башкаруучу учак

Сиз машинени от алдырганда, жогоруда айтылгандай эле нерсе болот.

Жана плюс төмөнкүлөр:

• Ар бир кардар үчүн vRouter MPLS тегин бөлүп берет. Бул L3VPN кызмат белгиси, анын жардамы менен кардарлар бир эле физикалык машинанын ичинде бөлүнөт.
  

  Чынында, MPLS теги vRouter тарабынан ар дайым шартсыз бөлүштүрүлөт - баары бир, машина бир эле vRouterдин артында турган башка машиналар менен гана иштеше тургандыгы алдын ала белгилүү эмес жана бул чындыкка дал келбейт.

• vRouter BGP протоколун колдонуу менен SDN контроллери менен байланышты орнотот (же ага окшош - TF учурда, бул XMPP 0_o).
• Бул сессия аркылуу vRouter SDN контроллерине туташкан тармактарга каттамдарды билдирет:
  • Тармак дареги
  • Инкапсуляция ыкмасы (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS кардар теги
  • Nexthop катары сиздин IP дареги

• SDN контроллери бардык туташкан vRouterдерден мындай маршруттарды алат жана аларды башкаларга чагылдырат. Башкача айтканда, ал Маршруттук Рефлектордун милдетин аткарат.

Ошол эле нерсе карама-каршы багытта болот.

Кабаттоо жок дегенде ар бир мүнөт сайын өзгөрүшү мүмкүн. Бул болжол менен коомдук булуттарда болот, анда кардарлар виртуалдык машиналарын үзгүлтүксүз баштап, өчүрүшөт.

Борбордук контроллер конфигурацияны сактоонун жана vRouterдеги которуштуруу/маршруттук таблицаларга мониторинг жүргүзүүнүн бардык татаалдыктарына кам көрөт.

Болжол менен айтканда, контроллер бардык vRouters менен BGP (же ушуга окшош протокол) аркылуу байланышат жана жөн гана маршруттук маалыматты өткөрүп берет. Мисалы, BGP инкапсуляция ыкмасын жеткирүү үчүн дарек-үй-бүлөгө ээ MPLS-in-GRE же MPLS-in-UDP.

Ошол эле учурда, Underlay тармагынын конфигурациясы эч кандай өзгөрбөйт, демек, аны автоматташтыруу алда канча кыйын жана ыңгайсыз кыймыл менен бузуу оңой.

Тышкы дүйнөгө чыгуу

Бир жерде симуляция бүтүшү керек жана сиз виртуалдык дүйнөдөн чыныгы дүйнөгө чыгышыңыз керек. Жана сизге таксофондук шлюз керек.

Эки ыкма колдонулат:

1. Аппараттык роутер орнотулган.
2. Маршрутизатордун функцияларын ишке ашырган прибор ишке киргизилди (ооба, SDNден кийин биз VNF менен да жолуктук). Аны виртуалдык шлюз деп атайлы.

Экинчи ыкманын артыкчылыгы - арзан горизонталдык масштабда болуу - жетиштүү кубаттуулук жок - биз шлюз менен башка виртуалдык машинаны ишке киргиздик. Каалаган физикалык машинада, бекер стойкаларды, агрегаттарды, кубаттуулукту издебестен, аппараттын өзүн сатып алып, аны ташып, орнотуп, которуштурууга, конфигурациялоого, андан кийин андагы бузулган компоненттерди өзгөртүүгө болот.

Виртуалдык шлюздун кемчиликтери физикалык роутердин бирдиги дагы эле көп ядролуу виртуалдык машинага караганда күчтүүрөөк жана анын өзүнүн аппараттык базасына ылайыкташтырылган программалык камсыздоосу бир топ туруктуураак иштейт (жок). Аппараттык-программалык комплекс жөн гана конфигурациялоону талап кылган, ал эми виртуалдык шлюзду ишке киргизүү жана тейлөө күчтүү инженерлердин милдети экендигин тануу кыйын.

Бир буту менен шлюз кадимки Виртуалдык машина сыяктуу Overlay виртуалдык тармагын карайт жана башка бардык VMлер менен иштеше алат. Ошол эле учурда, ал бардык кардарлардын түйүндөрүн токтотуп, ошого жараша алардын ортосунда маршрутизацияны жүргүзө алат.

Башка буту менен шлюз магистралдык тармакка карайт жана Интернетке кантип кирүүнү билет.

Data Plane

Башкача айтканда, процесс мындай көрүнөт:

1. VM-0, ошол эле vRouterге демейки болуп, eth185.147.83.177 интерфейсине тышкы дүйнөдө көздөгөн (0) пакетти жөнөтөт.
2. vRouter бул пакетти алат жана багыттоо таблицасында көздөгөн даректи издейт - Туннел 1 аркылуу VNGW1 шлюзи аркылуу демейки маршрутту табат.
   Ал ошондой эле бул SIP 10.0.0.2 жана DIP 10.0.255.2 менен GRE туннели экенин көрөт, ошондой эле алгач VNGW1 күткөн бул кардардын MPLS энбелгисин тиркөө керек.
3. vRouter баштапкы пакетти MPLS, GRE жана жаңы IP аталыштары менен топтойт жана демейки боюнча ToR1 10.0.0.1ге жөнөтөт.
4. Негизги тармак пакетти VNGW1 шлюзуна жеткирет.
5. VNGW1 шлюзи GRE жана MPLS туннелдөө баштарын алып салат, көздөгөн даректи көрөт, анын маршруттук таблицасына кайрылат жана анын Интернетке багытталганын түшүнөт, башкача айтканда, Толук Көрүү же Демейки аркылуу. Зарыл болсо, NAT котормосун аткарат.
6. VNGWден чек арага чейин кадимки IP тармагы болушу мүмкүн, бул күмөн.
   Классикалык MPLS тармагы (IGP+LDP/RSVP TE) болушу мүмкүн, BGP LU менен арткы кездеме же VNGWден IP тармагы аркылуу чек арага чейин GRE туннели болушу мүмкүн.
   Кандай болбосун, VNGW1 керектүү инкапсуляцияларды аткарып, баштапкы пакетти чек арага жөнөтөт.

Карама-каршы багыттагы кыймыл тескери тартипте бирдей кадамдардан өтөт.

1. Чек пакетти VNGW1ге түшүрөт
2. Ал аны чечинтип, алуучунун дарегин карап, ага Tunnel1 туннели (MPLSoGRE же MPLSoUDP) аркылуу кирүүгө болорун көрөт.
3. Демек, ал MPLS энбелгисин, GRE/UDP башын жана жаңы IPди тиркеп, аны ToR3 10.0.255.1ге жөнөтөт.
   Туннелдин дареги максаттуу VM жайгашкан vRouterдин IP дареги - 10.0.0.2.
4. Негизги тармак пакетти керектүү vRouterге жеткирет.
5. Максаттуу vRouter GRE/UDP окуйт, MPLS энбелгисин колдонуп интерфейсти аныктайт жана VMнин eth0 менен байланышкан TAP интерфейсине жылаңач IP пакетин жөнөтөт.

Башкаруучу учак

VNGW1 SDN контроллери менен BGP кварталын түзөт, андан кардарлар жөнүндө бардык маршруттук маалыматты алат: кайсы IP дареги (vRouter) кайсы кардар артында турат жана ал кайсы MPLS энбелгиси менен аныкталат.

Ошо сыяктуу эле, ал өзү SDN контроллерине демейки маршрутту ушул кардардын энбелгиси менен билдирет, өзүн nexthop катары көрсөтөт. Анан бул демейки vRoutersке келет.

VNGWде адатта маршрутту бириктирүү же NAT котормосу пайда болот.

Ал эми башка багытта, ал чек аралары же Маршруттук Рефлекторлор менен сессияга дал ушул топтолгон маршрутту жөнөтөт. Жана алардан ал демейки маршрутту же Full-View же башка нерсени алат.

Инкапсуляция жана трафик алмашуу жагынан VNGW vRouterден эч айырмаланбайт.
Эгерде сиз масштабды бир аз кеңейтсеңиз, анда VNGWs жана vRouters үчүн башка тармак түзмөктөрүн кошо аласыз, мисалы, брандмауэрлер, трафикти тазалоо же байытуу чарбалары, IPS ж.б.

Ал эми VRFдерди ырааттуу түзүүнүн жана маршруттарды туура жарыялоонун жардамы менен сиз трафикти сиз каалагандай айланууга мажбурлай аласыз, бул Service Chaining деп аталат.

Башкача айтканда, бул жерде да SDN контроллери VNGW, vRouters жана башка тармактык түзүлүштөрдүн ортосунда Маршрут-Рефлектордун ролун аткарат.

Бирок, чындыгында, контроллер ошондой эле ACL жана PBR (Саясатка негизделген Маршруттоо) жөнүндө маалыматты чыгарат, бул жеке трафик агымдарынын маршрутка караганда башкача кетишине алып келет.

FAQ

Эмне үчүн сиз дайыма GRE/UDP эскертүүсүн жасайсыз?

Жалпысынан алганда, бул вольфрам кездемеге тиешелүү деп айтууга болот - аны такыр эске алуунун кереги жок.

Бирок, эгер биз аны алсак, OpenContrail дагы эле TF өзү эки инкапсуляцияны колдогон: GREдеги MPLS жана UDPдеги MPLS.

UDP жакшы, анткени Source Portто анын башындагы баштапкы IP+Proto+Portтун хэш-функциясын коддоо оңой, бул сизге балансташтырууга мүмкүндүк берет.

GRE учурда, тилекке каршы, тышкы IP жана GRE аталыштары гана бар, алар бардык инкапсуляцияланган трафик үчүн бирдей жана тең салмактуулук жөнүндө сөз жок - пакеттин ичин ушунчалык терең карай турган адамдар аз.

Бир нече убакытка чейин, роутерлор динамикалык туннелдерди кантип колдонууну билсе, MPLSoGREде гана жасашкан жана жакында эле MPLSoUDP колдонууну үйрөнүшкөн. Ошондуктан, биз ар дайым эки башка инкапсуляциянын мүмкүндүгү жөнүндө белгилешибиз керек.

Адилеттүүлүк үчүн, TF VXLAN аркылуу L2 байланышын толугу менен колдой турганын белгилей кетүү керек.

Сиз OpenFlow менен параллелдерди түзүүгө убада бергенсиз.
Алар чындап эле сурап жатышат. Ошол эле OpenStack ичиндеги vSwitch VXLAN аркылуу абдан окшош нерселерди жасайт, демек, анын UDP баш аты да бар.

Берилиштер тегиздигинде алар болжол менен бирдей иштешет; Башкаруу планы бир кыйла айырмаланат. Tungsten Fabric vRouterге маршруттук маалымат жеткирүү үчүн XMPP колдонот, ал эми OpenStack Openflow иштетет.

vRouter жөнүндө бир аз көбүрөөк айтып бере аласызбы?
Ал эки бөлүккө бөлүнөт: vRouter Agent жана vRouter Forwarder.

Биринчиси хост ОСтин Колдонуучу мейкиндигинде иштейт жана SDN контроллери менен байланышып, маршруттар, VRF жана ACL жөнүндө маалымат алмашат.

Экинчиси Data Planeди ишке ашырат - адатта ядро ​​мейкиндигинде, бирок SmartNIC-терде да иштей алат - CPU жана өзүнчө программалануучу коммутациялык чип бар тармак карталары, ал хост машинанын CPUсынан жүктү алып салууга жана тармакты тезирээк жана көбүрөөк кылууга мүмкүндүк берет. алдын ала айтууга болот.

Дагы бир мүмкүн болгон сценарий vRouter Колдонуучу мейкиндигинде DPDK тиркемеси болуп саналат.

vRouter Agent орнотууларды vRouter Forwarderге жөнөтөт.

Виртуалдык тармак деген эмне?
Мен VRF жөнүндө макаланын башында ар бир ижарачы өзүнүн VRF менен байланганын айттым. Ал эми бул кабаттуу тармактын иштешин үстүртөн түшүнүү үчүн жетиштүү болсо, анда кийинки итерацияда тактоолорду киргизүү керек.

Адатта, виртуалдаштыруу механизмдеринде Виртуалдык тармак объектиси (сиз муну туура атооч деп эсептесеңиз болот) кардарлардан/ижарачылардан/виртуалдык машиналардан өзүнчө киргизилет - бул толугу менен көз карандысыз нерсе. Жана бул виртуалдык тармак мурунтан эле интерфейстер аркылуу бир ижарачыга, экинчисине, экиге же каалаган жерден туташтырылышы мүмкүн. Ошентип, мисалы, Кызмат чынжырчасы трафикти керектүү ырааттуулукта белгилүү түйүндөр аркылуу өткөрүү керек болгондо, Виртуалдык тармактарды туура ырааттуулукта түзүү жана туташтыруу аркылуу ишке ашырылат.

Демек, Виртуалдык тармак менен ижарачынын ортосунда түз кат алышуулар жок.

жыйынтыктоо

Бул хост жана SDN контроллери менен виртуалдык тармактын иштешинин өтө үстүртөн сүрөттөлүшү. Бирок сиз бүгүн кайсы виртуалдаштыруу платформасын тандабаңыз, ал VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric же Juniper Contrail болобу, окшош жол менен иштейт. Алар инкапсуляциялардын жана аталыштардын түрлөрү, акыркы тармак түзүлүштөрүнө маалыматты жеткирүү протоколдору боюнча айырмаланат, бирок салыштырмалуу жөнөкөй жана статикалык астынкы тармактын үстүндө иштеген программалык конфигурациялануучу кабаттуу тармактын принциби өзгөрүүсүз калат.
Бүгүнкү күндө бир кабаттуу тармакка негизделген SDN жеке булут түзүү тармагын утуп алды деп айта алабыз. Бирок, бул Openflow заманбап дүйнөдө орун жок дегенди билдирбейт - ал OpenStacke жана ошол эле VMWare NSXте колдонулат, менин билишимче, Google аны жер астындагы тармакты орнотуу үчүн колдонот.

Эгер сиз маселени тереңирээк изилдегиңиз келсе, төмөндө мен кененирээк материалдарга шилтеме бердим.

Ал эми биздин Underlay жөнүндө эмне айтууга болот?

Бирок, жалпысынан, эч нерсе. Ал толугу менен өзгөргөн жок. Хосттан кабатталган учурда ал маршруттарды жана ARPлерди жаңыртуу керек, анткени vRouter/VNGW пайда болуп, жок болуп, алардын ортосунда пакеттерди алып жүрүшөт.

Келгиле, Underlay тармагына талаптардын тизмесин түзөлү.

1. Маршруттук протоколдун кандайдыр бир түрүн колдоно билүү, биздин кырдаалда - BGP.
2. Ашыкча жүктөөдөн улам пакеттер жоголуп кетпеши үчүн, ашыкча жазылуусуз, кеңири өткөрүү жөндөмдүүлүгүнө ээ болуңуз.
3. ECMP колдоо кездеменин ажырагыс бөлүгү болуп саналат.
4. ECN сыяктуу татаал нерселерди, анын ичинде QoS камсыз кыла алат.
5. NETCONF колдоо келечек үчүн негиз болуп саналат.

Мен бул жерде Underlay тармагынын ишине өтө аз убакыт бөлдүм. Себеби, кийинчерээк серияда мен ага басым жасайм жана биз өтүүдө бир гана Overlayге токтолобуз.

Албетте, мен Cloz фабрикасында таза IP багыттоосу жана хосттун катмары менен курулган DC тармагын мисал катары колдонуп, баарыбызды катуу чектеп жатам.

Бирок дизайны бар ар бир тармакты формалдуу түрдө сүрөттөп, автоматташтырууга болот деп ишенем. Бул жерде менин максатым – автоматташтырууга болгон мамилени түшүнүү жана маселени жалпы формада чечүү менен баарын чаташтырбоо.

ADSM алкагында Роман Горж экөөбүз эсептөө күчүн виртуалдаштыруу жана анын тармактык виртуалдаштыруу менен өз ара аракеттешүүсү жөнүндө өзүнчө чыгарууну пландаштырып жатабыз. Байланышта болуңуз.

Пайдалуу шилтемелер

• Вольфрам кездемесинин архитектурасы.
• жөнүндө: булут. TF боюнча виртуалдык тармакты да камтыган Yandex.Cloud жөнүндө 6 саат.
• Open vSwitch деген эмне?
• VxLANга киришүү.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): 2-кабат тармактары аркылуу Виртуалдашкан 3-катмар тармактарын каптатуу үчүн негиз.
  
• VXLAN EVPN Fabric үчүн Scaleway ыкмасы. Анда бүтүндөй DC тармагы, анын ичинде Underlay, Overlay, мульти-гоминг жана башкаруу ыкмалары жөнүндө сөз болот.

Рахмат

• Роман Горга - linkmeup подкастынын мурунку алып баруучусу жана азыр булут платформалары тармагындагы эксперт. Пикирлер жана түзөтүүлөр үчүн. Жакынкы арада анын виртуалдаштыруу боюнча тереңирээк макаласын күтөбүз.
• Александр Шалимов - менин кесиптешим жана виртуалдык тармакты өнүктүрүү жаатындагы эксперт. Пикирлер жана түзөтүүлөр үчүн.
• Валентин Синицын - менин кесиптешим жана вольфрам кездеме тармагындагы эксперт. Пикирлер жана түзөтүүлөр үчүн.
• Артём Чернобай — иллюстратор шилтемеси. KDPV үчүн.
• Александр Лимонов. "Автомат" мем үчүн.

Source: www.habr.com