Хмарныя вылічэнні ўсё глыбей і глыбей пранікаюць у наша жыццё і ўжо напэўна няма ніводнага чалавека, які хоць бы раз не карыстаўся якімі або хмарнымі сэрвісамі. Аднак што ж такое воблака і як яно працуе ў большасці сваёй мала хто ведае нават на ўзроўні ідэі. 5G становіцца ўжо рэальнасцю і целікам інфраструктура пачынае пераходзіць ад слупковых рашэнняў да хмарных рашэннямі, як калі пераходзіла ад цалкам жалезных рашэнняў да віртуалізаваных «слупоў».
Сёння пагаворым аб унутраным свеце хмарнай інфраструктуры, у прыватнасці разбяром асновы сеткавай часткі.
Што такое воблака? Тая ж віртуалізацыя - выгляд у профіль?
Больш за лагічнае пытанне. Не - гэта не віртуалізацыя, хоць без яе не абышлося. Разгледзім два азначэнні:
Воблачнае вылічэнні (далей Воблака) - Гэта мадэль прадастаўлення зручнага для карыстальніка доступу да размеркаваных вылічальных рэсурсаў, якія павінны быць разгорнуты і запушчаны па запыце з мінімальна магчымай затрымкай і мінімальнымі выдаткамі з боку сэрвіс правайдэра.
віртуалізацыя - Гэта магчымасць падзяліць адну фізічную сутнасць (напрыклад сервер) на некалькі віртуальных, тым самым павысіўшы ўтылізацыю рэсурсаў (напрыклад у вас было 3 сервера, загружаных на 25-30 працэнтаў, пасля віртуалізацыі вы атрымліваеце 1 сервер, загружаны на 80-90 працэнтаў). Натуральна віртуалізацыя ад'ядае частка рэсурсаў - вам трэба пракарміць гіпервізор, аднак, як паказала практыка, гульня варта свеч. Ідэальны прыклад віртуалізацыі - гэта VMWare, якая выдатна рыхтуе віртуальныя машыны, ці напрыклад KVM, які мне больш па душы, але гэта ўжо справа густу.
Мы выкарыстоўваем віртуалізацыю самі гэтага не разумеючы, ды нават жалезныя маршрутызатары ўжо выкарыстоўваюць віртуалізацыю – напрыклад у апошніх версія JunOS аперацыйная сістэма ставіцца як віртуальная машына па-над real-time linux дыстрыбутыва (Wind River 9). Але віртуалізацыя - гэта не воблака, аднак воблака не можа існаваць без віртуалізацыі.
Віртуалізацыя - гэта адзін з цаглінак, на якім воблака будуецца.
Зрабіць воблака, проста сабраўшы некалькі гіпервізораў у адзін L2 дамен, дадаўшы пару yaml плэйбукаў для аўтаматычнага прапісвання ўланаў праз які небудзь ansible і насунуць на гэта ўсё штосьці тыпу сістэмы аркестрацыі для аўтаматычнага стварэння віртуальных машын - не атрымаецца. Дакладней атрымаецца, але атрыманы Франкенштэйн - не тое воблака якое нам трэба, хоць каму як, можа быць для каго то гэта мяжа летуценняў. Да таго ж калі ўзяць той жа Openstack па сутнасці яшчэ той яшчэ Франкенштэйн, але ды добра не будзем пакуль пра гэта.
Але я разумею што з прадстаўленага вышэй вызначэння не зусім зразумела, што ж насамрэч можна назваць воблакам.
Таму ў дакуменце ад NIST (National Institute of Standards and Technology) прыведзены 5 асноўных характарыстык, якімі павінна валодаць хмарная інфраструктура:
Прадастаўленне сэрвісу па запыце. Карыстальніку павінен быць прадстаўлены вольны доступ да вылучаных яму кампутарных рэсурсаў (такім як сеткі, віртуальныя кружэлкі, памяць, ядры працэсараў і т д) прычым гэтыя рэсурсы павінны падавацца аўтаматычна - гэта значыць без умяшання са боку сэрвіс правайдэра.
Шырокая даступнасць сэрвісу. Доступ да рэсурсаў павінен забяспечвацца стандартнымі механізмамі для магчымасці выкарыстання як стандартных ПК, так і тонкіх кліентаў і мабільных прылад.
Аб'яднанне рэсурсаў у пулы. Пулы рэсурсаў павінны забяспечваць адначасовае прадастаўленне рэсурсаў некалькім кліентам, забяспечваючы ізаляцыю кліентаў і адсутнасць узаемнага ўплыву паміж імі і канкурэнцыі за рэсурсы. У пулы ўключаюцца і сеткі, што кажа аб магчымасці выкарыстання перасякальнага адрасавання. Пулы павінны падтрымліваць маштабаванне па запыце. Выкарыстанне пулаў дазваляе забяспечыць неабходны ўзровень адмоваўстойлівасці рэсурсаў і абстрагаванне фізічных і віртуальных рэсурсаў - атрымальніку сэрвісу проста прадастаўляецца запытаны ім набор рэсурсаў (дзе гэтыя рэсурсы размешчаны фізічна, на колькіх серверах і камутатарах - кліенту не важна). Аднак трэба ўлічваць той факт, што правайдэр павінен забяспечыць празрыстае рэзерваванне гэтых рэсурсаў.
Хуткая адаптацыя да розных умоў. Сэрвісы павінны быць гнуткімі - хуткае прадастаўленне рэсурсаў, іх пераразмеркаванне, даданне або скарачэнне рэсурсаў па запыце кліента, прычым з боку кліента павінна складацца адчуванне, што рэсурсы аблокі бясконцыя. Для прастаты разумення, напрыклад, вы ж не бачыце папярэджанне аб тым, што ў вас у Apple iCloud знікла частка дыскавай прасторы з-за таго, што на серверы зламалася цвёрдая кружэлка, а кружэлкі то ламаюцца. Да таго ж з вашага боку магчымасці гэтага сэрвісу практычна бязмежныя - трэба вам 2 Тб - не праблема, заплацілі і атрымалі. Аналагічна можна прывесці прыклад з Google.Drive ці Yandex.Disk.
Магчымасць вымярэння прадастаўляемага сэрвісу. Воблачнае сістэмы павінны аўтаматычна кантраляваць і аптымізаваць спажываныя рэсурсы, пры гэтым гэтыя механізмы павінны быць празрыстыя як для карыстальніка так і для правайдэра паслуг. Гэта значыць, вы заўсёды можаце праверыць, колькі рэсурсаў вы і вашыя кліенты спажываюць.
Варта ўлічыць той факт, што дадзеныя патрабаванні ў большасці сваёй з'яўляюцца патрабаваннямі да публічнага воблака, таму для прыватнага аблокі (гэта значыць аблокі, запушчанага для ўнутраных патрэб кампаніі) гэтыя патрабаванні могуць быць некалькі скарэкціраваны. Аднак яны ўсё ж павінны выконвацца, інакш мы не атрымаем усіх плюсаў хмарных вылічэнняў.
Навошта нам воблака?
Аднак любая новая ці ўжо існуючая тэхналогія, любы новы пратакол ствараецца для чагосьці (ну акрамя RIP-ng натуральна). Пратакол дзеля пратакола – нікому не патрэбен (ну акрамя RIP-ng натуральна). Лагічна, што Воблака ствараецца каб даць нейкі сэрвіс карыстачу/кліенту. Мы ўсе знаёмыя хаця б з парай хмарных сэрвісаў, напрыклад Dropbox або Google.Docs і я так мяркую большасць паспяхова імі карыстаецца - напрыклад дадзены артыкул напісана з выкарыстаннем хмарнага сэрвісу Google.Docs. Але вядомыя нам хмарныя сэрвісы гэта толькі частка магчымасцяў аблокі - дакладней гэта толькі сэрвіс тыпу SaaS. Даць хмарны сэрвіс мы можам трыма шляхамі: у выглядзе SaaS, PaaS або IaaS. Які сэрвіс патрэбен менавіта вам залежыць ад вашых жаданняў і магчымасцяў.
Разгледзім кожны па парадку:
Праграмнае забеспячэнне як паслуга (SaaS) - гэта мадэль прадастаўлення паўнавартаснага сэрвісу кліенту, напрыклад паштовы сэрвіс тыпу Yandex.Mail або Gmail. У такой мадэлі прадастаўлення сэрвісу вы, як кліент па факце не робіце нічога, акрамя як карыстаецеся сэрвісаў - гэта значыць вам не трэба думаць аб наладзе сэрвісу, яго адмоваўстойлівасці або рэзерваванні. Галоўнае не скампраметаваць свой пароль, усё астатняе за вас зробіць правайдэр дадзенага сэрвісу. З пункту гледжання правайдэра сэрвісу – ён адказвае цалкам за ўвесь сэрвіс – пачынаючы з сервернага абсталявання і хаставых аперацыйных сістэм, заканчваючы наладамі баз дадзеных і праграмнага забеспячэння.
Платформа як паслуга (PaaS) - пры выкарыстанні дадзенай мадэлі пастаўшчык паслуг падае кліенту нарыхтоўку пад сэрвіс, напрыклад возьмем Web сервер. Пастаўшчык паслуг падаў кліенту віртуальны сервер (па факце набор рэсурсаў, такіх як RAM/CPU/Storage/Nets і т д), і нават усталяваў на дадзены сервер АС і неабходнае ПЗ, аднак наладу ўсяго гэтага дабра вырабляе сам кліент і за працаздольнасць сэрвісу ўжо адказвае кліент. Пастаўшчык паслуг, як і ў мінулым выпадку адказвае за працаздольнасць фізічнага абсталявання, гіпервізораў, самай віртуальнай машыны, яе сеткавую даступнасць і т д, але сам сэрвіс ужо па-за яго зонай адказнасці.
Інфраструктура як паслуга (IaaS) - дадзены падыход ужо цікавей, па факце пастаўшчык паслуг прадастаўляе кліенту поўную віртуалізаваную інфраструктуру - гэта значыць нейкі набор (пул) рэсурсаў, такіх як CPU Cores, RAM, Networks і т д. Усё астатняе - справа кліента - што кліент хоча зрабіць з гэтымі рэсурсамі ў рамках выдзеленага яму пула (квоты) - пастаўшчыку не асабліва важна. Хоча кліент стварыць свой уласны vEPC або наогул зрабіць міні аператара і прадастаўляць паслугі сувязі - не пытанне - рабі. У такім сцэнары пастаўшчык паслуг адказвае за прадастаўленне рэсурсаў, іх адмоваўстойлівасць і даступнасць, а таксама за АС, якая дазваляе аб'яднаць дадзеныя рэсурсы ў пулы і даць іх кліенту з магчымасць у любы момант правесці павелічэнне або памяншэнне рэсурсаў па запыце кліента. Усе віртуальныя машыны і іншую мішуру кліент настройвае сам праз партал самаабслугоўвання і кансолі, у тым ліку і прапісанне сетак (акрамя вонкавых сетак).
Што такое OpenStack?
Ва ўсіх трох варыянтах пастаўшчыку паслуг патрэбна АС, якая дазволіць стварыць хмарную інфраструктуру. Фактычна ж пры SaaS за ўвесь стэк дадзены стэк тэхналогій адказвае не адно падраздзяленне – ёсць падраздзяленне, якое адказвае за інфраструктуру – гэта значыць падае IaaS іншаму падраздзяленню, гэта падраздзяленне падае кліенту SaaS. OpenStack з'яўляецца адной з хмарных АС, якая дазваляе сабраць кучу камутатараў, сервераў і сістэм захоўвання ў адзіны рэсурсны пул, разбіваць гэты агульны пул на падпулы (тэнанты) і падаваць гэтыя рэсурсы кліентам праз сетку.
OpenStack - Гэта хмарная аперацыйная сістэма якая дазваляе кантраляваць вялікія пулы вылічальных рэсурсаў, сховішчаў дадзеных і сеткавых рэсурсаў, провижининг і кіраванне якімі вырабляецца праз API з выкарыстаннем стандартных механізмаў аўтэнтыфікацыі.
Іншымі словамі, гэта комплекс праектаў вольнага праграмнага забеспячэння які прызначаны для стварэння хмарных сэрвісаў, (як публічных, так і дзеляў) — гэта значыць набор прылад, якія дазваляюць аб'яднаць сервернае і камутацыйнае абсталяванне ў адзіны пул рэсурсаў, кіраваць гэтымі рэсурсамі, забяспечваючы неабходны ўзровень адмоваўстойлівасці .
На момант напісання дадзенага матэрыялу структура OpenStack выглядае так:
Малюнак узятая з
Кожная з кампанентаў, якія ўваходзяць у склад OpenStack якіх выконвае якую-небудзь пэўную функцыю. Такая размеркаваная архітэктура дазваляе ўключаць у склад рашэння той набор функцыянальных кампанентаў, якія вам неабходны. Аднак частка кампанентаў з'яўляюцца каранёвымі кампанентамі і іх выдаленне прывядзе да поўнай ці частковай непрацаздольнасці рашэння ў цэлым. Да такіх кампанентаў прынята адносіць:
- прыборная панэль - GUI на базе web для кіравання OpenStack сэрвісамі
- Краевугольны камень - цэнтралізаваны сэрвіс ідэнтыфікацыі, які дае функцыянальнасць аўтэнтыфікацыі і аўтарызацыі для іншых сэрвісаў, а таксама кіраваць уліковымі дадзенымі карыстальнікаў і іх ролямі.
- нейтрон - сеткавая служба, якая забяспечвае складнасць паміж інтэрфейсамі розных службаў OpenStack (уключаючы і складнасць паміж VM і доступ іх у навакольны свет)
- акаліна - дае доступ да блокавага сховішча для віртуальных машын.
- Новая зорка - кіраванне жыццёвым цыклам віртуальных машын
- Позірк - рэпазітар вобразаў віртуальных машын і снапшотаў
- хутка - дае доступ да аб'екта сховішча
- Облакомер — служба, якая дае магчымасць збору тэлеметрыі і замеру наяўных і пажыўных рэсурсаў.
- Цяпло - аркестрацыя на базе тэмплейтаў для аўтаматычнага стварэння і правіжынінгу рэсурсаў
Поўны спіс усіх праектаў і іх прызначэнне можна паглядзець .
Кожная з кампанентаў OpenStack - гэта служба, якая адказвае за пэўную функцыю і забяспечвае API для кіравання гэтай функцыяй і ўзаемадзеяння гэтай службы з іншымі службамі хмарнай аперацыйнай сістэмы ў мэтах стварэння адзінай інфраструктуры. Напрыклад, Nova забяспечвае кіравання вылічальнымі рэсурсамі і API для доступу да канфігуравання дадзеных рэсурсаў, Glance - кіравання выявамі і API для кіравання імі, Cinder - блокавае сховішча і API для кіравання ім і тд. Усе функцыі ўзаемаўвязаны паміж сабой вельмі цесным чынам.
Аднак калі пасудзіць, то ўсе сэрвісы, запушчаныя ў OpenStack уяўляе з сябе ў канчатковым рахунку якую або віртуальную машыну (або кантэйнер), падлучаную да сеткі. Паўстае пытанне - а навошта нам столькі элементаў?
Давайце прабяжымся па алгарытме стварэння віртуальнай машыны і падлучэнні яе да сеткі і сталаму сховішча ў Openstack.
- Калі вы ствараеце запыт на стварэнне машыны, няхай гэта будзе запыт праз Horizon (Dashboard) ці ж запыт праз CLI, першае што адбываецца – гэта аўтарызацыя вашага запыту на Keystone – ці можаце вы ствараць машыну, мае ці права выкарыстоўваць дадзеную сетку, ці хапае ў вашага праекта квоты і т д.
- Keystone вырабляе аўтэнтыфікацыю вашага запыту і генеруе ў паведамленні ў адказ auth-токен, які будзе выкарыстаны далей. Атрымаўшы адказ ад Keystone запыт адпраўляецца ў бок Nova (nova api).
- Nova-api правярае валіднасць вашага запыту, звяртаючыся ў Keystone, выкарыстоўваючы раней згенераваны auth-токен
- Keystone вырабляе аўтэнтыфікацыю і падае на падставе дадзенага auth-токена інфармацыю па дазволах і абмежаванням.
- Nova-api стварае ў nova-database запіс аб новай VM і перадае запыт на стварэнне машыны ў nova-scheduler.
- Nova-scheduler вырабляе выбар хаста (компьют ноды), на якой VM будзе разгорнутая на падставе зададзеных параметраў, шаляў і зон. Запіс аб гэтым і ідэнтыфікатар VM запісваюцца ў nova-database.
- Далей nova-scheduler звяртаецца да nova-compute з запытам аб разгортванні інстансу. Nova-compute звяртаецца ў nova-conductor для атрымання інфармацыі аб параметрах машыны (nova-conductor з'яўляецца элементам nova, які выконвае ролю проксі сервера паміж nova-database і nova-compute, абмяжоўваючы колькасць запытаў у бок nova-database у пазбяганні праблем з кансістэнтнасцю базы дадзеных скарачэння загрузкі).
- Nova-conductor атрымлівае з nova-database запытаную інфармацыю і перадае яе nova-compute.
- Далей nova-compute звяртаецца да glance для атрымання ID выявы. Glace праводзіць валідацыю запыту ў Keystone і вяртае патрэбную інфармацыю.
- Nova-compute звяртаецца да neutron для атрымання інфармацыі аб параметрах сеткі. Аналагічна glance, neutron праводзіць валідацыю запыту ў Keystone, пасля чаго стварае запіс у database (ідэнтыфікатар порта і т д), стварае запыт на стварэнне порта і вяртае запытаную інфармацыю ў nova-compute.
- Nova-compute звяртаецца да cinder з запытам вылучэння віртуальнай машыне volume. Аналагічна glance, cider праводзіць валідацыю запыту ў Keystone, стварае запыт на стварэнне volume і вяртае патрэбную інфармацыю.
- Nova-compute звяртаецца да libvirt з запытам разгортвання віртуальнай машыны з зададзенымі параметрамі.
Па факце быццам бы простая аперацыя па стварэнні простай віртуальнай машыны ператвараецца ў такі вір api колаў паміж элементамі хмарнай платформы. Прычым, як вы бачыце, нават раней пазначаныя службы - таксама складаюцца з драбнейшых кампанент, паміж якімі адбываецца ўзаемадзеянне. Стварэнне машыны - гэта толькі малая частка таго, што дае зрабіць хмарная платформа - ёсць служба, якая адказвае за балансаванне трафіку, служба, якая адказвае за блокавае сховішча, служба, якая адказвае за DNS, служба, якая адказвае за провижининг bare metal сервераў і т д. Воблака дазваляе вам ставіцца да вашых віртуальных машын як да статка бараноў (у адрозненні ад віртуалізацыі). Калі ў віртуальным асяроддзі ў вас што тое адбылося з машынай - вы яе аднаўляеце з бекапаў і т д, хмарныя ж прыкладанні пабудаваны такім чынам, што б віртуальная машыны не гуляла такую важную ролю - віртуальная машына "памерла" - не бяда - проста ствараецца новая машына на падставе темплейта і, як гаворыцца, атрад не заўважыў страты байца. Натуральна гэта прадугледжвае наяўнасць механізмаў аркестрацыі – выкарыстоўваючы Heat темплейты вы без асаблівых праблем можаце разгарнуць складаную фунцыю, якая складаецца з дзясяткаў сетак і віртуальных машын.
Варта заўсёды трымаць у розуме тое, што хмарнай інфраструктуры без сеткі не бывае - кожны элемент так ці інакш ўзаемадзейнічае з іншымі элементамі праз сетку. Акрамя таго воблака мае абсалютна не статычную сетку. Натуральна underlay сетка яшчэ больш-менш статычная не кожны дзень дадаюцца новыя ноды і камутатары, аднак overlay складнік можа і непазбежна будзе ўвесь час змяняць будуць дадавацца ці выдаляцца новыя сеткі, з'яўляцца новыя віртуальныя машыны і паміраць старыя. І як вы падушыце з азначэння аблокі, дадзенага ў самым пачатку артыкула — рэсурсы павінны вылучаць карыстачу аўтаматычна і з найменшым (а лепш без) умяшаннем са боку сэрвіс правайдэра. Гэта значыць той тып прадастаўлення рэсурсаў сеткі, які ёсць цяпер у выглядзе фронтэнда ў выглядзе вашага асабістага кабінета даступнага па http / https і дзяжурнага сеткавага інжынера Васіля ў якасці бэкэнда - гэта не воблака, нават пры наяўнасці ў Васіля васьмі рук.
Neutron, з'яўляючыся сеткавай службай, забяспечвае API для кіравання сеткавай часткай хмарнай інфраструктуры. Служба забяспечвае працаздольнасць і кіраванне сеткавай часткі Openstack забяспечваючы ўзровень абстракцыі, званы Network-as-a-Service (NaaS). Гэта значыць сетка з'яўляецца такой жа віртуальнай вымерна адзінкай, як напрыклад віртуальныя ядры CPU або аб'ём RAM.
Але перад тым як пераходзіць да архітэктуры сеткавай часткі OpenStack, разгледзім як у OpenStack гэтая сетка працуе і чаму сетка з'яўляецца важнай і неад'емнай часткай аблокі.
Такім чынам, у нас ёсць дзве віртуальныя машыны кліента RED і дзве віртуальныя машыны кліента GREEN. Выкажам здагадку, што гэтыя машыны размешчаныя на двух гіпервізорах такім чынам:
У дадзены момант гэта проста віртуалізацыя 4-х сервераў і не больш за тое, бо пакуль што ўсё што мы зрабілі – віртуалізавалі 4 сервера, размясціўшы іх на двух фізічных серверах. Прычым пакуль што яны нават не падключаны да сеткі.
Каб атрымалася воблака нам трэба дадаць некалькі кампанентаў. У першых віртуалізуем сеткавую частку нам трэба гэтыя 4 машыны парамі злучыць, прычым кліенты жадаюць менавіта L2 злучэнне. Можна выкарыстоўваць скончана камутатар і наладзіць у яго бок транк і разруліць усё з дапамогай linux bridge ну ці для больш прасунутых карыстачоў openvswitch (да яго мы яшчэ вернемся). Але сетак можа быць вельмі шмат, ды і ўвесь час прапіхваць L2 праз свіч – не самая лепшая ідэя – так розныя падраздзяленні, сэрвіс-дэск, месяцы чакання выканання заяўкі, тыдні траблшутинга – у сучаснасці свеце такі падыход ужо не працуе. І чым раней кампанія гэта разумее - тым лягчэй ёй рухацца наперад. Таму паміж гіпервізорамі вылучым L3 сетку праз якую будуць мець зносіны нашы віртуальныя машыны, а ўжо па-над дадзенай L3 сеткі пабудуем віртуальныя накладзеныя L2 (overlay) сеткі, дзе будзе бегаць трафік нашых віртуальных машын. Як інкапсуляцыю можна выкарыстоўваць GRE, Geneve ці VxLAN. Пакуль спынімся на апошнім, хоць гэта не асоба важна.
Нам трэба дзе тое размясціць VTEP (спадзяюся ўсе знаёмыя з тэрміналогіяй VxLAN). Бо з сервераў у нас выходзіць адразу L3 сетка, то нам нічога не мяшае размясціць VTEP на саміх серверах, прычым OVS (OpenvSwitch) гэта выдатна ўмее рабіць. У выніку мы атрымалі вось такую канструкцыю:
Так як трафік паміж VM павінен быць падзелены, то порты ў бок віртуальных машын будуць мець розныя нумары ўланаў. Нумар тэга гуляе ролю толькі ў межах аднаго віртуальнага камутатара, бо пры інкапсуляванні ў VxLAN мы яго можам беспраблемна зняць, бо ў нас будзе VNI.
Цяпер мы можам пладзіць нашы машыны і віртуальныя сеткі для іх без якіх-небудзь праблем.
Аднак што калі ў кліента будзе яшчэ адна машына, але знаходзіцца ў іншай сетцы? Нам патрэбен рутынг паміж сеткамі. Мы разбярэм просты варыянт, калі выкарыстоўваецца цэнтралізаваны рутынг - гэта значыць трафік маршрутызуецца праз спецыяльныя выдзеленыя network ноды (ну як правіла яны сумешчаны з control нодамі, таму ў нас будзе тое ж самае).
Нібыта нічога складанага — які робіцца брыдж інтэрфейс на кантрольнай нодзе, гонім на яе трафік і адтуль маршрутызуем яго куды нам трэба. Але праблема ў тым, што кліент RED жадае выкарыстаць сетку 10.0.0.0/24, і кліент GREEN жадае выкарыстаць сетку 10.0.0.0/24. Гэта значыць, у нас пачынаецца скрыжаванне адрасных прастор. Акрамя таго кліенты не хочуць, каб іншыя кліенты маглі маршрутызаваць у іх унутраныя сеткі, што лагічна. Каб падзяліць сеткі і трафік дадзеных кліентаў, мы для кожнага з іх вылучым асобны namespace. Namespace - гэта па факце копія сеткавага стэка Linux, гэта значыць кліенты ў namespace RED цалкам ізаляваныя ад кліентаў з namespace GREEN (ну альбо маршрутызацыя паміж дадзенымі сеткамі кліентаў дазволеная праз default namespace альбо ўжо на вышэйстаячым транспартным абсталяванні).
Гэта значыць атрымліваем такую схему:
L2 тунэлі сыходзяцца з усіх вылічальных нод на кантрольную. ноду, дзе размешчаны L3 інтэрфейс для дадзеных сетак, кожны ў выдзеленым namespace для ізаляцыі.
Аднак мы забыліся самае галоўнае. Віртуальная машына павінна падаваць сэрвіс кліенту, гэта значыць яна павінна мець хаця б адзін вонкавы інтэрфейс, праз які да яе можна дастукацца. Гэта значыць, нам трэба выйсці ў знешні свет. Тут ёсць розныя варыянты. Зробім самы проста варыянт. Дадамо кліентам па адной сетцы, якія будуць валідныя ў сетцы правайдэра і не будуць перасякацца з іншымі сеткамі. Сеткі магу быць таксама якія перасякаюцца і глядзець у розныя VRF на боку правайдэрскай сеткі. Дадзеныя сеткі таксама будуць жыць у namespace кожнага з кліентаў. Аднак выходзіць у знешні свет яны ўсё роўна будуць праз адзін фізічны (ці бонд, што больш лагічна) інтэрфейс. Каб падзяліць трафік кліентаў трафік, які выходзіць вонкі будзе праводзіцца тэгаванне VLAN тэгам, выдзеленым кліенту.
У выніку мы атрымалі вось такую схему:
Слушнае пытанне - чаму не зрабіць шлюзы на саміх compute нодах? Вялікай праблемы ў гэтым няма, больш за тое, пры ўключэнні размеркаванага маршрутызатара (DVR) гэта так і будзе працаваць. У дадзеным сцэнары мы разглядаем самы просты варыянт з цэнтралізаваным gateway, які ў Openstack выкарыстоўваецца па змаўчанні. Для высоканагружаных функцый будуць выкарыстоўваць як размеркаваны маршрутызатар, так і тэхналогіі паскарэння тыпу SR-IOV і Passthrough, але як гаворыцца, гэта ўжо зусім іншая гісторыя. Для пачатку разбяромся з базавай часткай, а потым сыдзем у дэталі.
Уласна наша схема ўжо працаздольная, аднак ёсць пара нюансаў:
- Нам трэба як то абараніць нашы машыны, гэта значыць павесіць на інтэрфейс свіча ў бок кліента фільтр.
- Зрабіць магчымасць аўтаматычнага атрымання ip адраса віртуальнай машынай, каб не прыйшлося кожны раз заходзіць у яе праз кансоль і прапісваць адрас.
Пачнём з абароны машын. Для гэтага можна выкарыстоўваць банальныя iptables, чаму б і не.
Гэта значыць, цяпер наша тапалогія ўжо крыху ўскладнілася:
Пойдзем далей. Нам трэба дадаць DHCP сервер. Самым ідэальным месцам для размяшчэння DHCP сервераў для кожнага з кліентаў будзе ўжо згаданая вышэй кантрольная нода, дзе размешчаны namespaces:
Аднак, ёсць невялікая праблема. Што калі ўсё перазагрузіцца і ўся інфармацыя па арэндзе адрасоў на DHCP знікне. Лагічна, што машынам будуць выдадзены новыя адрасы, што не вельмі зручна. Выйсця тут два – альбо выкарыстоўваць даменныя імёны і дадаць DNS сервер для кожнага кліента, тады нам адрас будзе не асоба важны (па аналогіі з сеткавай частка ў k8s) – але тут ёсць праблема з вонкавымі сеткамі, бо ў іх адрасы таксама магу быць выдадзены па DHCP – патрэбна сінхранізацыя з DNS сервераў у хмарнай платформе і вонкавым DNS серверам, што на мой погляд не вельмі гнутка, аднак суцэль магчыма. Або другі варыянт - выкарыстоўваць метададзеныя - гэта значыць захоўваць інфармацыю аб выдадзенай машыне адрасе каб DHCP сервер ведаў, які адрас машыне выдаць, калі машына ўжо атрымлівала адрас. Другі варыянт прасцей і гнутчэй, бо дазваляе захаваць дадатковую інфармацыю аб машыне. Зараз на схему дадамо metadata агента:
Яшчэ адно пытанне які таксама варта асвяціць - гэта магчымасць выкарыстоўваць адну знешнюю сетку ўсімі кліентамі, бо знешнія сеткі, калі яны павінны быць валідныя ва ўсёй сетцы, то будзе складанасць - трэба пастаянна вылучаць і кантраляваць выдзяленне гэтых сетак. Магчымасць выкарыстання адзінай для ўсіх кліентаў знешняй перадканфігураванай сеткі будзе вельмі дарэчы пры стварэнні публічнага аблокі. Гэта спросціць разгортванне машын, бо нам не трэба спраўджвацца з базай дадзеных адрасоў і выбіраць унікальную адрасную прастору для знешняй сеткі кожнага кліента. Да таго ж мы можам прапісаць знешнюю сетку загадзя і ў момант разгортвання нам трэба будзе ўсяго толькі асацыяваць вонкавыя адрасы з кліенцкімі машынамі.
І тут на дапамогу нам прыходзіць NAT - проста зробім магчымасць кліентаў выходзіць у знешні свет праз default namespace з выкарыстаннем NAT трансляцыі. Ну і тут невялікая праблема. Гэта добра, калі кліенцкі сервер працуе як кліент, а не як сервер - гэта значыць ініцыюе а не прымае падлучэння. Але ў нас тое будзе наадварот. У такім разе нам трэба зрабіць destination NAT, каб пры атрыманні трафіку кантрольная нода разумела, што дадзены трафік прызначаны віртуальнай машыне А кліента А, а значыць трэба зрабіць NAT трансляцыю з вонкавага адрасу, напрыклад 100.1.1.1 ва ўнутраны адрас 10.0.0.1. У такім выпадку, хаця ўсе кліенты будуць выкарыстоўваць адну і тую ж сетку, унутраная ізаляцыя цалкам захоўваецца. Гэта значыць, нам трэба на кантрольнай нодзе зрабіць dNAT і sNAT. Выкарыстоўваць адзіную сетку з вылучэннем плаваюць адрасоў або знешнія сеткі ці ж і тое і тое адразу - абумоўліваецца тым, што вы хочаце ў воблака зацягнуць. Мы не будзем наносіць на схему яшчэ і плывучыя адрасы, а пакінем ужо дададзеныя раней вонкавыя сеткі - у кожнага кліента ёсць свая вонкавая сетка (на схеме пазначаныя як влан 100 і 200 на вонкавым інтэрфейсе).
У выніку мы атрымалі цікавае і ў той жа час прадуманае рашэнне, якое валодае пэўнай гнуткасцю, але пакуль што не валодае механізмамі адмоваўстойлівасці.
У першых у нас усяго адна кантрольная нода - выйсце яе з ладу прывядзе да краху ўсе сістэмы. Для ўхілення дадзенай праблемы неабходна зрабіць прынамсі кворум з 3-х нод. Дадамо гэта на схему:
Вядома ўсе ноды сінхранізуюцца і пры выхадзе актыўнай ноды яе абавязкі на сябе возьме іншая нода.
Наступная праблема - дыскі віртуальных машын. У дадзены момант яны захоўваюцца на саміх гіпервізорах і ў выпадку праблем з гіпервізарам мы губляем усе дадзеныя - і наяўнасць рэйду тут ніяк не дапаможа калі мы страцім не дыск, а ўвесь сервер цалкам. Для гэтага нам трэба зрабіць службу, якая будзе выступаць фронтэндам для якога-небудзь сховішча. Якое гэта будзе сховішча нам асоба не важна, але яно павінна абараніць нашы дадзеныя ад выйсця са строю і дыска і ноды, а магчыма і цэлай шафы. Варыянтаў тут некалькі – ёсць вядома SAN сеткі з Fiber Channel, але скажам шчыра – FC гэта ўжо перажытак мінулага – аналаг E1 у транспарце – ды згодзен, ён яшчэ выкарыстоўваецца, але толькі там, дзе без яго ну ніяк нельга. Таму добраахвотна разгортваць FC сетку ў 2020 году я бы не стаў, ведаючы аб наяўнасці іншых цікавейшых альтэрнатыў. Хоць кожнаму сваё і магчыма знойдуцца тыя, хто лічыць, што FC са ўсімі яго абмежаваннямі усё што нам трэба не буду спрачацца, у кожнага сваё меркаванне. Аднак найболей цікавым рашэннем на мой погляд з'яўляецца выкарыстанне SDS, напрыклад Ceph.
Ceph дазваляе пабудаваць выскадаступнае рашэнне для захоўвання дадзеных з кучай магчымых варыянтаў рэзервавання, пачынальна з кодаў з праверкай цотнасці (аналаг рэйд 5 ці 6) сканчаючы поўнай рэплікацыяй дадзеных на розныя дыскі з улікам размяшчэння дыскаў у серверах, і сервераў у шафах і т д.
Для зборкі Ceph трэба яшчэ 3 ноды. Узаемадзеянне са сховішчам будзе рабіцца таксама праз сетку з выкарыстаннем службаў блокавага, аб'ектнага і файлавага сховішчаў. Дадамо ў схему сховішча:
Заўвага: можна рабіць і гиперконвергентные compute ноды - гэта канцэпцыя аб'яднання некалькіх функцый на адной нодзе - напрыклад storage + compute - не вылучаць спецыяльныя ноды пад ceph storage. Мы атрымаем такую ж адмоваўстойлівасць схему - так як SDS зарэзервуе дадзеныя з названым намі узроўнем рэзервавання. Аднак гиперконвергентные ноды - гэта заўсёды кампраміс - бо storage нода не проста грэе паветра як здаецца на першы погляд (бо на ёй няма віртуальных машын) - яна марнуе рэсурсы CPU на абслугоўванне SDS (па факце яна ў фоне робіць усё рэплікацыі, аднаўлення пасля збояў нод, дыскаў і т д). Гэта значыць, вы страціце частку мошнасці compute ноды калі сумясціце яе з storage.
Усім гэтым дабром трэба як тое кіраваць - трэба што тое, праз што мы можам стварыць машыну, сетку, віртуальны маршрутызатар і т д. Для гэтага на кантрольную ноду дадамо службу, якая будзе выконваць ролю dashboard - кліент зможа падлучыцца да дадзенага партала праз http/ https і зрабіць усё, што яму трэба (ну амаль што).
У выніку зараз мы маем адмоваўстойлівую сістэму. Усімі элементамі дадзенай інфраструктуры трэба неяк кіраваць. Раней было апісана, што Openstack – гэта набор праектаў, кожны з якіх забяспечвае нейкую пэўную функцыю. Як мы бачым элементаў, якія трэба канфігураваць і кантраляваць больш за досыць. Сёння мы пагаворым аб сеткавай частцы.
Архітэктура Neutron
У OpenStack менавіта Neutron адказвае за падлучэнне партоў віртуальных машын да агульнай L2 сеткі, забеспячэнне маршрутызацыі трафіку паміж VM, змешчанымі ў розных L2 сетках а таксама маршрутызацыю вонкі, падаванне такіх сэрвісаў як NAT, Floating IP, DHCP і т д.
Высокаўзроўневую працу сеткавай службы (базавая частка) можна апісаць так.
Пры запуску VM сеткавая служба:
- Стварае порт для дадзенай VM (ці парты) і апавяшчае пра гэта DHCP сэрвіс;
- Ствараецца новы віртуальны сеткавы девайс (праз libvirt);
- VM падлучаецца да створанага на 1 кроку порце (партам);
Як ні дзіўна, але ў аснове працы Neutron ляжаць стандартныя механізмы, знаёмыя ўсім, што калі-небудзь апускаўся ў Linux – гэта namespaces, iptables, linux bridges, openvswitch, conntrack і т д.
Варта адразу ўдакладніць, што Neutron не з`яўляецца SDN кантролерам.
Neutron складаецца з некалькіх узаемаўвязаных паміж сабой кампанент:
Openstack-neutron-server - Гэта дэман, які праз API працуе з карыстацкімі запытамі. Дадзены дэман не займаецца прапісваннем якіх-небудзь сеткавых сувязнасцяў, а дае неабходную для гэтага інфармацыю сваім убудовам, якія далей наладжваюць патрэбны элемент сеткі. Neutron-агенты на вузлах OpenStack рэгіструюцца на серверы Neutron.
Neutron-server гэта фактычна дадатак, напісанае на python, якое складаецца з дзвюх частак:
- REST service
- Neutron Plugin (core/service)
REST сэрвіс прызначаны для прыёму API выклікаў ад астатніх кампанент (напрыклад запыт на прадастаўленне якой-небудзь інфармацыі і г.д.)
Убудовы гэта падлучальныя праграмныя кампаненты/модулі якія выклікаюцца пры API запытах — гэта значыць прыпісванне нейкага сэрвісу адбываецца праз іх. Убудовы дзеляцца на два выгляду - сэрвісны і каранёвай. Як правіла коневая плягін адказвае ў асноўным за кіраванне адраснай прасторай і L2 злучэння паміж VM, а сэрвісныя плагіны ўжо забяспечваюць дадатковы функцыянал напрыклад VPN або FW.
Спіс даступных на сёння плагінаў можна паглядзець напрыклад
Сэрвісных убудоваў можа быць некалькі, аднак коневая ўбудова можа быць толькі адзін.
Openstack-neutron-ml2 — гэта стандартная каранёвая плягін Openstack. Дадзеная ўбудова мае модульную архітэктуру (у адрозненні ад свайго папярэдніка) і праз якія падключаюцца да яго драйверы вырабляе канфігураванне сеткавага сэрвісу. Сам убудова разгледзім крыху пазней, бо фактычна ён дае тую гнуткасць, якой валодае OpenStack у сеткавай частцы. Каранёвы плягін можа быць заменены (напрыклад Contrail Networking робіць такую замену).
RPC service (rabbitmq-server) - сэрвіс, які забяспечвае кіраваннем чэргамі і ўзаемадзеянне з іншымі службамі OpenStack а таксама ўзаемадзеянне паміж агентамі сеткавай службы.
Network agents - Агенты, якія размешчаны ў кожнай нодзе, праз якія і вырабляецца канфігураванне сеткавых сэрвісаў.
Агенты бываюць некалькіх відаў.
Асноўны агент - гэта L2 agent. Гэтыя агенты запускаюцца на кожным з гіпервізораў уключаючы і кантрольныя ноды (дакладней сказаць на ўсіх вузлах, якія падаюць які-небудзь сэрвіс для тэнантаў) і іх асноўная функцыя - падлучэнне віртуальных машын да агульнай L2 сеткі, а таксама генераваць абвесткі пры ўзнікненні якіх-небудзь падзей (напрыклад адключэння/уключэнні порта).
Наступным, не менш важным агентам з'яўляецца L3 agent. Па змаўчанні гэты агент запускаецца выключна на network нодзе (часта network node сумяшчаецца з control node) і забяспечвае маршрутызацыю паміж сеткамі тэнантаў (як паміж яго сеткамі і сеткамі іншых тэнатаў, так і даступны ў навакольны свет, забяспечваючы NAT, а таксама DHCP сэрвіс). Аднак пры выкарыстанні DVR (размеркаваны маршрутызатар) неабходнасць у L3 убудове з'яўляецца і на compute нодах.
L3 агент выкарыстоўвае Linux namespaces для прадастаўлення кожнаму тэнанта набору ўласных ізаляваных сетак і функцыянал віртуальных маршрутызатараў, якія маршрутызуюць трафік і падаюць паслугі шлюза для Layer 2 сетак.
База дадзеных - база дадзеных ідэнтыфікатараў сетак, падсетак, партоў, пулаў і т д.
Фактычна Neutron прымае API запыты ад на стварэнне якіх-небудзь сеткавых сутнасцяў аўтэнтыфікуе запыт, і праз RPC (калі звяртаецца да нейкага убудовы або агенту) або REST API (калі мае зносіны ў SDN) перадае агентам (праз убудовы) інструкцыі, неабходныя для арганізацыі запытанага сэрвісу .
Зараз звернемся да тэставай усталёўкі (як яна разгорнута і што ў яе складзе паглядзім пазней у практычнай частцы) і паглядзім дзе якая кампанента размешчана:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$
Вось і ўся структура Neutron. Цяпер варта надаць некаторы час ML2 убудову.
Modular Layer 2
Як ужо сказана вышэй убудова з'яўляецца стандартным каранёвым убудовай OpenStack і мае модульную архітэктуру.
Папярэднік ML2 плагіна меў маналітную структуру што не дазваляла напрыклад выкарыстоўваць мікс з некалькіх тэхналогій у адной усталёўцы. Напрыклад вы не маглі выкарыстоўваць і openvswitch і linuxbridge адначасова - альбо першае, альбо другое. Па гэтай прычыне быў створаны ML2 убудова з яго архітэктурай.
ML2 мае дзве складнікі - два тыпу драйвераў: Type drivers і Mechanism drivers.
Type drivers вызначаюць тэхналогіі, якія будуць скарыстаны для арганізацыі сеткавых сувязнасцяў, напрыклад VxLAN, VLAN, GRE. Пры гэтым драйвер дазваляе выкарыстоўваць розныя тэхналогіі. Стандартнай тэхналогіяй з'яўляецца VxLAN інкапсуляцыя для overlay сетак і vlan знешніх сетак.
Да Type drivers з'яўляюцца наступныя тыпы сетак:
Плоскі - сетка без тэгавання
VLAN - Тэгіраваная сетка
Мясцовы - спецыяльны тып сеткі для інсталяцый тыпу all-in-one (такія інсталяцыі патрэбныя або для распрацоўшчыкаў або для навучання)
GRE — overlay сетка, якая выкарыстоўвае GRE тунэлі
VxLAN - overlay сетка, якая выкарыстоўвае VxLAN тунэлі
Mechanism drivers вызначаюць сродкі, якія забяспечваюць арганізацыю паказаных у type driver тэхналогій - напрыклад, openvswitch, sr-iov, opendaylight, OVN і т д.
У залежнасці ад рэалізацыі дадзенага драйвера будзе скарыстаны альбо агенты, якія кіруюцца Neutron, альбо выкарыстоўвацца злучэнні з вонкавым SDN кантролерам, які бярэ на сябе ўсе пытанні па арганізацыі L2 сетак, маршрутызацыі і т д.
Прыклад калі мы выкарыстоўваем ML2 разам з OVS, то на кожнай вылічальнай нодзе усталёўваецца L2 агент, які кіруе OVS. Аднак калі мы выкарыстоўваем напрыклад OVN або OpenDayLight, то кіраванне OVS пераходзіць пад іх юрысдыкцыю – Neutron праз каранёвую ўбудову дае каманды кантролеру, а ён ужо робіць тое, што яму сказалі.
Асвяжам у памяці Open vSwitch
На дадзены момант адным з ключавых кампанентаў OpenStack з'яўляецца Open vSwitch.
Пры ўсталёўцы OpenStack без якога або дадатковага вендарскага SDN тыпу Juniper Contrail або Nokia Nuage, OVS з'яўляецца асноўнай сеткавай кампанентам хмарнай сеткі і ў сукупнасці з iptables, conntrack, namespaces дазваляе арганізоўваць паўнавартасны оверлейные сеткі з мультытэнансы. Натуральна дадзеная кампанента можа быць заменена, напрыклад пры выкарыстанні іншых прапрыетарных (вендарскіх) SDN рашэнняў.
OVS гэта праграмны камутатар з адкрытым зыходным кодам, які прызначаны для выкарыстання ў віртуалізаваных асяроддзях як віртуальны форвардэр трафіку.
На дадзены момант OVS мае вельмі прыстойны функцыянал, у які ўваходзяць такія тэхналогіі, як QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK і т.д.
Нататка: першапачаткова OVS не задумляўся як праграмны камутатар для высоканагружаных целікам функцый і быў больш разлічаны пад меней патрабавальныя да прапускной здольнасці ІТ функцыі тыпу WEB сервера ці паштовага сервера. Аднак OVS дапрацоўваецца і бягучыя рэалізацыі OVS моцна палепшылі яго прадукцыйнасць і магчымасці, што дазваляе яго выкарыстоўваць аператарам сувязі з высоканагружанымі функцыямі, напрыклад ёсць рэалізацыя OVS з падтрымкай DPDK паскарэння.
Існуе тры важныя кампаненты OVS, аб якіх неабходна ведаць:
- Модуль ядра - кампанента, размешчаная ў kernel space, якая выконвае апрацоўку трафік на аснове атрыманых ад кіраўніка элемента правіл;
- vSwitch daemon (ovs-vswitchd) - гэта працэс, запушчаны ў user space, які адказвае за праграмаванне kernel модуля - гэта значыць уяўляе непасрэдна логіку працы камутатара
- Сервер базы дадзеных - лакальная база дадзеных, размешчаная на кожным хасце, на якім запушчаны OVS, у якой захоўваецца канфігурацыя. Праз гэты модуль па пратаколе OVSDB могуць мець зносіны SDN кантролеры.
Да гэтага ўсяго яшчэ прыкладаецца набор дыягнастычных і кіраўнікоў утыліт, такіх як ovs-vsctl, ovs-appctl, ovs-ofctl і т д.
У сапраўдны момант Openstack шырока выкарыстоўваецца тэлекам аператарамі для міграцыі ў яго сеткавых функцый, такіх як EPC, SBC, HLR і т д. Частка функцый можа без праблем жыць з OVS у тым выглядзе ў якім ён ёсць, але напрыклад EPC апрацоўвае трафік абанентаў – то ёсць прапускае праз сябе велізарная колькасць трафіку (цяпер аб'ёмы трафіку дасягаюць некалькіх сотняў гігабіт у секунду). Натуральна гнаць такі трафік праз kernel space (бо па змаўчанні форвардэр размешчаны менавіта там) - не самая лепшая ідэя. Таму часцяком OVS разгортваюць цалкам у user space з выкарыстаннем тэхналогіі паскарэння DPDK для пракіду трафіку з NIC у user space абыходзячы kernel.
Заўвага: для аблокі, разгорнутага для тэлевізараў функцый магчымы варыянт вываду трафіку з compute ноды абыходзячы OVS напрамую ў камутацыйнае абсталяванне. Для гэтай мэты выкарыстоўваюцца механізмы SR-IOV і Passthrough.
Як гэта працуе на рэальным макеце?
Ну і зараз пяройдзем да практычнай часткі і паглядзім як гэта ўсё працуе на практыцы.
Для пачатку разгорнем прасценькую Openstack усталёўку. Бо ў мяне пад рукой пад эксперыменты няма набору сервераў, тое збіраць макет будзем на адным фізічным серверы з віртуальных машын. Так, натуральна пад камерцыйныя мэты такое рашэнне не падыходзіць, але каб паглядзець на прыкладзе як працуе сетку ў Openstack такой усталёўкі хопіць за вочы. Прычым такая інсталяцыя для мэт навучання нават цікавей - бо можна адлавіць трафік і т д.
Бо нам трэба ўбачыць толькі базавую частку, то мы можам не выкарыстоўваць некалькі сетак а ўсё падняць з выкарыстаннем усяго двух сетак, прычым другая сетка ў дадзеным макеце будзе выкарыстоўвацца выключна для доступу да undercloud і dns серверу. Вонкавыя сеткі мы пакуль закранаць не будзем - гэта тэма для асобнага вялікага артыкула.
Такім чынам, пачнем па парадку. Спачатку крыху тэорыі. Ставіць мы будзем Openstack з дапамогай TripleO (Openstack on Openstack). Сутнасць TripleO складаецца ў тым, што мы ўсталёўваны Openstack all-in-one (гэта значыць на адну ноду), званы undercloud, і далей выкарыстоўваем магчымасці разгорнутага Openstack каб усталяваць Openstack, прызначаны для эксплуатацыі, званы overcloud. Undercloud будзе выкарыстоўваць закладзеную ў яго магчымасць кіраваць фізічнымі серверамі (bare metal) – праект Ironic – для провижининга гіпервізораў, якія будуць выконваць ролі compute, control, storage нод. Гэта значыць, мы не выкарыстоўваем ніякіх іншых сродкаў для разгортвання Openstack - мы разгортваем Openstack сіламі Openstack. Далей па ходзе ўстаноўкі стане нашмат больш зразумела, таму не будзем спыняць на гэтым і пойдзем наперад.
Нататка: У дадзеным артыкуле ў мэтах спрашчэння я не стаў выкарыстоўваць сеткавую ізаляцыю для ўнутраных сетак Openstack, а ўсё разгорнута з выкарыстаннем толькі адной сеткі. Аднак наяўнасць ці адсутнасць ізаляцыі сетак не ўплывае на базавую функцыянальнасць рашэння – усё будзе працаваць сапраўды гэтак жа, як і пры выкарыстанні ізаляцыі, але трафік будзе хадзіць у адной сетцы. Для камерцыйнай усталёўкі натуральна неабходна выкарыстоўваць ізаляцыю з выкарыстаннем розных уланаў і інтэрфейсаў. Напрыклад трафік кіравання ceph сховішчам і трафік непасрэдна дадзеных (звароты машын да дыскаў і т д) пры ізаляцыі выкарыстоўваюць розныя падсеткі (Storage management і Storage) і гэта дазваляе зрабіць рашэнне больш адмоваўстойлівым, падзяліўшы дадзены трафік напрыклад па розных партах, альбо выкарыстоўваць розныя QoS профілі для рознага трафіку, каб трафік даных не выціснуў сігнальны трафік. У нашым жа выпадку яны будуць ісці ў адной і той жа сетцы і па факце гэта нас ніяк не лімітуе.
Нататка: Бо мы збіраемся запускаць віртуальныя машыны ў віртуальным асяроддзі, якая базуецца на віртуальных машынах, то для пачатку трэба ўлучыць nested віртуалізацыю.
Праверыць, ці ўключаная nested віртуалізацыя ці не можна так:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Калі вы бачыце літару N, то ўключаем падтрымку nested віртуалізацыі па любым гайду, які знойдзеце ў сетцы, напрыклад .
Нам трэба сабраць вось такую схему з віртуальных машын:
У маім выпадку для складнасці віртуальных машын, якія ўваходзяць у склад будучай усталёўкі (а іх у мяне атрымалася 7 штук, але можна абыйсціся 4, калі ў вас не шмат рэсурсаў) я выкарыстаў OpenvSwitch. Я стварыў адзін ovs брыдж і падключыў да яго віртуальныя машыны празе port-groups. Для гэтага стварыў xml файл наступнага выгляду:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Тут абвешчаныя тры порт групы – дзве access і адна trunk (апошняя патрэбна была для DNS сервера, але можна абыйсціся і без яго, альбо падняць яго на хаставой машыне – гэта як вам зручней). Далей з дапамогай дадзенага шаблону аб'яўляем нашу есць праз virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Цяпер правім канфігурацыі партоў гіпервізара:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Нататка: у дадзеным сцэнары адрас на порце ovs-br1 не будзе даступны, бо ён не мае влан тэга. Каб гэта паправіць, трэба даць каманду sudo ovs-vsctl set port ovs-br1 tag=100. Аднак пасля перазагрузкі дадзены тэг знікне (калі хто ведае як прымусіць яго застацца на месцы - буду вельмі ўдзячны). Але гэта не гэтак важна, бо дадзены адрас нам спатрэбіцца толькі на час усталёўкі і будзе не патрэбен, калі Openstack будзе цалкам разгорнуты.
Далей ствараем undercloud машыну:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Падчас усталёўкі выстаўляеце ўсе патрэбныя параметры, такія як імя машыны, паролі, карыстачы, ntp серверы і т д, можна адразу наладзіць і парты, але мне асабіста прасцей пасля ўсталёўкі зайсці ў машыну праз кансоль і падправіць патрэбныя файлы. Калі ў вас ужо ёсць гатовая выява, то можаце выкарыстоўваць яго, альбо паступіць як я — запампаваць мінімальную выяву Centos 7 і выкарыстаць яго для ўсталёўкі VM.
Пасля паспяховай усталёўкі ў вас павінна з'явіцца віртуальная машына на якую можна будзе ставіць undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningСпачатку ставім неабходныя падчас усталёўкі прылады:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Ўстаноўка Undercloud
Ствараем юзэра stack, задаём пароль, дадаем у sudoer і даем яму магчымасць выконваць root каманды праз sudo без неабходнасці ўводу пароля:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackЦяпер паказваем у файле hosts поўнае імя undercloud:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Далей дадаем рэпазітары і ставім патрэбны нам софт:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleНататка: калі вы не плануеце ставіць ceph, то каманды, якія адносяцца да ceph уводзіць не трэба. Я выкарыстоўваў рэліз Queens, але вы можаце выкарыстоўваць любы іншы, які вам спадабаецца.
Далей які капіюецца файл канфігурацыі undercloud у хатнюю дырэкторыю карыстача stack:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confЗараз неабходна паправіць дадзены файл, падбудаваўшы яго пад нашу інсталяцыю.
У пачатак файла трэба дадаць дадзеныя радкі:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10Такім чынам, пройдзем па наладах:
undercloud_hostname - поўнае імя undercloud сервера, павінна супадаць з запісам на DNS серверы
лакальны_іп - лакальны адрас undercloud у бок правіжэнінг сеткі
network_gateway - гэты ж лакальны адрас, які будзе выступаць у якасці gateway для доступу ў знешні свет падчас усталёўкі overcloud нод, таксама супадае з local ip
undercloud_public_host - адрас вонкавага API, прызначаецца любы вольны адрас з провижининг сеткі
undercloud_admin_host адрас унутранага API, прызначаецца любы вольны адрас з провижининг сеткі
undercloud_nameservers - DNS сервер
generate_service_certificate - дадзены радок вельмі важная ў бягучым прыкладзе, бо калі яе не ўсталяваць у значэнне false вы атрымаеце памылку пры ўсталёўцы, праблема апісана на багтрэкер Red Hat
local_interface інтэрфейс у провижининг сеткі. Дадзены інтэрфейс будзе пераканфігураваны падчас разгортвання undercloud, таму на undercloud неабходна мець два інтэрфейсы - адзін для доступу да яго, другі для провижининга
local_mtu - MTU. Бо ў нас тэставая лабараторыя і MTU у мяне 1500 на партах OVS свіча, тое неабходна выставіць у значэнне 1450, што бы мінулі інкапсуляваныя ў VxLAN пакеты.
network_cidr - правіжынінг сетка
маскарад - выкарыстанне NAT для доступу ў знешнюю сетку
masquerade_network - сетка, якая будзе NAT-ся
dhcp_start - пачатковы адрас пула адрасоў, з якога будуць прызначацца адрасы нодам падчас дэплою overcloud
dhcp_end - канчатковы адрас пула адрасоў, з якога будуць прызначацца адрасы нодам падчас дэплою overcloud
inspection_iprange - Пул адрасоў, неабходных для правядзення інтраспекцыі (не павінен перасякацца з вышэйпазначаным пулам)
scheduler_max_attempts - максімальная колькасць спроб усталёўкі overcloud (павінна быць больш ці роўна колькасці нод)
Пасля таго, як файл апісаны, можна даць каманду на дэплой undercloud:
openstack undercloud install
Працэдура займае ад 10 да 30 хвілін у залежнасці ад вашага жалеза. У канчатковым рахунку вы павінны ўбачыць такую выснову:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Дадзеная выснова кажа, што вы паспяхова ўсталявалі undercloud і зараз можна праверыць стан undercloud і пераходзіць да ўсталёўкі overcloud.
Калі паглядзець выснову ifconfig, тыя вы ўбачыце, што з'явіўся новы брыдж інтэрфейс
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Праз дадзены інтэрфейс зараз будзе праводзіцца праца па разгортванні overcloud.
З высновы ніжэй бачна, што ўсе сэрвісы ў нас на адной нодзе:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+Ніжэй паказана канфігурацыя сеткавай часткі undercloud:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Ўстаноўка overcloud
На дадзены момант у нас есць толькі undercloud, і нам не хапае нод, з якіх будзе збірацца overcloud. Таму перш за ўсё разгорнем патрэбныя нам віртуальныя машыны. Падчас дэплою undercloud сам паставіць АС і патрэбны софт на overcloud машыны - гэта значыць нам не трэба цалкам разгортваць машыну, а толькі стварыць для яе дыск (ці дыскі) і вызначыць яе параметры - гэта значыць па факце атрымліваем голы сервер без усталяванай на яго АС .
Пераходзім у тэчку з дыскамі нашых віртуальных машын і створым кружэлкі патрэбнага аб'ёму:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160GБо дзейнічаем мы ад рута, то нам трэба змяніць уладальніка гэтых кружэлак каб не атрымаць праблему з правамі:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# Нататка: калі вы не плануеце ставіць ceph у мэтах яго вывучэння, то каманды не стварайце прынамсі 3 ноды з мінімум двума кружэлкамі, а ў темплейте пакажыце, што будуць выкарыстоўвацца віртуальныя кружэлкі vda, vdb і т д.
Выдатна, зараз нам трэба ўсе гэтыя машыны вызначыць:
virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml
virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml
virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml
virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml
virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml У канцы ёсць каманды -print-xml > /tmp/storage-1.xml, якая стварае xml файл з апісаннем кожнай машыне ў тэчцы /tmp/, калі яе не дадаць, то не зможаце вызначыць віртуальныя машыны.
Цяпер нам трэба ўсе гэтыя машыны вызначыць у virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Зараз невялікі нюанс – tripleO выкарыстоўвае IPMI для таго, каб кіраваць серверамі падчас усталёўкі і интроспекции.
Інтраспекцыя - гэта працэс інспекцыі аппратной часткі ў мэтах атрымання яе параметраў, неабходных для далейшага провижининга нод. Інтраспекцыя вырабляецца з дапамогай ironic – службы, прызначанай для працы з bare metal серверамі.
Але вось тут праблема - калі ў жалезных сервераў IPMI гэта асобны порт (або shared порт, але гэта не прынцыпова), то ў віртуальных машын такіх партоў няма. Тут нам на дапамогу прыходзіць мыліца пад назовам vbmc - утыліта, якая дазваляе эмуляваць IPMI порт. На гэты нюанс варта звярнуць увагу асабліва тым, хто захоча падняць такую лабараторыю на ESXI гіпервізоры - калі вядома, не ведаю ці ёсць у ім аналаг vbmc, таму варта збянтэжыцца гэтым пытаннем перад тым як усё разгортваць.
Усталёўваны vbmc:
yum install yum install python2-virtualbmcКалі ваша АС не можа знайсці пакет, то дадайце рэпазітар:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmЦяпер наладжваем утыліту. Тут усё банальна да бязладдзя. Цяпер лагічна, што ў спісе vbmc няма ніякіх сервераў
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Каб яны з'явіліся іх неабходна ўручную аб'явіць такім чынам:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Думаю сінтаксіс каманды зразумелы і без тлумачэнняў. Аднак пакуль што ўсе нашыя сэсіі ў статусе DOWN. Каб яны перайшлі ў статут UP, неабходна іх уключыць:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#І апошняя рыска – трэба паправіць правілы фаервала (ну або адключыць яго зусім):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
Цяпер зойдзем у undercloud і праверым што ўсё працуе. Адрас хаставой машыны - 192.168.255.200, на undercloud мы дадалі патрэбны пакет ipmitool падчас падрыхтоўкі да дэплою:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningЯк бачыце, мы паспяхова запусцілі control ноду праз vbmc. Цяпер выключым яе і пойдзем далей:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Наступны крок - гэта інтраспекцыя нод, на якія будзе ставіцца overcloud. Для гэтага нам трэба падрыхтаваць json файл з апісаннем нашых нод. Звярніце ўвагу, што ў адрозненні ад усталёўкі на голыя серверы ў файле паказаны порт, на якім запушчаны vbmc для кожнай з машын.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Нататка: на кантрольнай нодзе два інтэрфейсу, але ў дадзеным выпадку гэта не важна, у дадзенай усталёўцы нам хопіць і аднаго.
Цяпер рыхтуем json файл. Нам трэба ўказаць мак адрас порта, праз які будзе рабіцца правіжынінг, параметры нод, задаць ім імёны і паказаць як патрапіць на ipmi:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Цяпер нам трэба падрыхтаваць вобразы для ironic. Для гэтага спампоўваем іх праз wget і ўсталёўваны:
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$Загружаем выявы ў undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Правяраем, што ўсе выявы загрузіліся
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Яшчэ адзін рыска - трэба дадаць dns сервер:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Цяпер мы можам даць каманду на інтраспекцыю:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Як бачна з высновы ўсё завяршылася без памылак. Праверым, што ўсе ноды ў стане available:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Калі ноды будуць у іншым стане, як правіла manageable, тое што тое пайшло не так і трэба глядзець лог, разбірацца, чаму так атрымалася. Майце на ўвазе, што ў дадзеным сцэнары мы выкарыстоўваем віртуалізацыю і могуць быць багі звязаныя з выкарыстаннем віртуальных машын або vbmc.
Далей нам трэба паказаць якая нода якую функцыю будзе выконваць - гэта значыць паказаць профіль, з якім нода будзе дэплаіравацца:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Указваем профіль для кожнай ноды:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167Правяраем, што мы зрабілі ўсё карэктна:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Калі ўсё дакладна, даем каманду на дэплой overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuУ рэальнай усталёўцы натуральна будуць выкарыстоўваць кастамізаваныя темплейты, у нашым выпадку гэта вельмі моцна ўскладніць працэс, бо трэба будзе растлумачыць кожную праўку ў шаблоне. Як было напісана раней – нават простай усталёўкі нам будзе дастаткова, каб паглядзець, як гэта працуе.
Заўвага: зменная -libvirt-type qemu у дадзеным выпадку неабходна, бо мы будзем выкарыстоўваць nested віртуалізацыі. У адваротным выпадку ў вас не будуць запускаць віртуальныя машыны.
Зараз у вас ёсць каля гадзіны, а можа і больш (залежыць ад магчымасцяў жалеза) і вам застаецца спадзявацца, што па заканчэнні гэтага часу вы ўбачыце такі надпіс:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Цяпер у вас ёсць амаль паўнавартасная версія апенстак, на якой вы можаце вучыцца, ставіць доследы і г д.
Праверым што ўсё нармальна працуе. У хатняй дырэкторыі карыстача stack ёсць два файла – адзін stackrc (для кіравання undercloud) і другі overcloudrc (для кіравання overcloud). Гэтыя файлы неабходна паказаць як source, бо ў іх утрымоўваецца неабходная для аўтэнтыфікацыі інфармацыя.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$У маёй усталёўцы яшчэ патрабуецца адзін невялікі рыска - дадаць маршрут на кантролеры, бо машына, з якой я працую знаходзіцца ў іншай сетцы. Для гэтага зойдзем на control-1 пад улікам heat-admin і прапішам маршрут
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Ну і зараз вы можаце зайсці ў гарызонт. Уся інфармацыя - адрасы, лагін і пароль - ляжаць у файле /home/stack/overcloudrc. Выніковая схема выглядае наступным чынам:
Дарэчы кажучы, у нашай усталёўцы адрасы машын выдаваліся праз DHCP і як бачыце, яны выдаюцца "як патрапіла". Вы можаце ў тэмплейце цвёрда задаць, які адрас якой машыне трэба прымацаваць падчас дэплою, калі вам гэта неабходна.
Як жа ходзіць трафік паміж віртуальнымі машынамі?
У дадзеным артыкуле мы разгледзім тры варыянты праходжання трафік
- Дзве машыны на адным гіпервізоры ў адной L2 сеткі
- Дзве машыны на розных гіпервізарах у адной L2 сеткі
- Дзве машыны ў розных сетках (рутынг паміж сеткамі)
Кейсы з выхадам у знешні свет праз external сетку, з выкарыстаннем якія плаваюць адрасоў, а таксама размеркаваную маршрутызацыю разгледзім у наступны раз, пакуль што спынімся на ўнутраным трафіку.
Для праверкі збяром такую схему:
У нас створана 4 віртуальныя машыны - 3 у адной L2 сеткі - net-1, і яшчэ 1 у сетцы net-2
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Паглядзім, на якіх гіпервізорах размешчаны створаныя машыны:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(overcloud) [stack@undercloud ~]$
Машыны vm-1 і vm-3 размешчаны на compute-0, машыны vm-2 і vm-4 размешчаны на нодзе compute-1.
Акрамя таго створаны віртуальны маршрутызатар для магчымасці маршрутызацыі паміж пазначанымі сеткамі:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ У маршрутызатара два віртуальныя порты, які выконваюць ролю шлюзаў для сетак:
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ Але перад тым як глядзець, як ходзіць трафік, давайце разгледзім, што мы маем на дадзены момант на кантрольнай надзе (якая па сумяшчальніцтве і network нода) і на compute ноду. Пачнём з compute ноды.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$У дадзены момант на нодзе тры ovs брыджы - br-int, br-tun, br-ex. Паміж імі, як мы бачым ёсць набор інтэрфейсаў. Для прастаты ўспрымання вырабім усе дадзеныя інтэрфейсы на схему і паглядзім, што атрымаецца.
Па адрасах, на якія паднятыя VxLAN тунэлі відаць, што адзін тунэль падняты на compute-1 (192.168.255.26), другі тунэль глядзіць на control-1 (192.168.255.15). Але найболей цікава тое, што br-ex няма фізічных інтэрфейсаў, а калі паглядзець, якія флоу наладжаныя, тое відаць, што дадзены брыдж у дадзены момант можа толькі драпаць трафік.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Як відаць з высновы адрас прыкручаны наўпрост на фізічны порт, а не на віртуальны брыдж інтэрфейс.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$
Згодна з першым правілам, усё што прыйшло з порта phy-br-ex неабходна адкінуць.
Уласна ў дадзены брыдж пакуль што больш няма адкуль узяцца трафіку, акрамя як з дадзенага інтэрфейсу (стык з br-int), і мяркуючы па дропам у брыдж ужо прылятаў BUM трафік.
Гэта значыць з дадзенай ноды трафік можа сысці толькі праз VxLAN тунэль і ніяк больш. Аднак калі ўключыць DVR сітуацыя зменіцца, але з гэтым разбяромся ў іншы раз. Пры выкарыстанні ізаляцыі сетак напрыклад з дапамогай уланаў, у вас будзе не адзін L3 інтэрфейс у 0-вом ўлане, а некалькі інтэрфейсаў. Аднак VxLAN трафік будзе выходзіць з ноды сапраўды гэтак жа, але інкапсуляванага яшчэ і ў нейкі то выдзелены влан.
З compute нодай разабраліся, пераходзім да control нодзе.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$Па факце можна сказаць, што ўсё тое ж самае, аднак ip адрас ужо знаходзіцца не на фізічным інтэрфейсе а на віртуальным брыджы. Гэта зроблена з-за таго, што дадзены порт з'яўляецца портам, праз які будзе выходзіць трафік у навакольны свет.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Дадзены порт прывязаны да брыджу br-ex і бо на ім няма ніякіх влан тэгаў, то дадзены порт з'яўляецца транкавым портам на якім дазволеныя ўсе ўланы, цяпер трафік выходзіць вонкі без тэга, пра што кажа vlan-id 0 у выснове вышэй.
Усё астатняе ў дадзены момант аналагічна compute нодзе - тыя ж брыджы, тыя ж тунэлі, якія ідуць на дзве compute ноды.
Storage ноды мы разглядаць у дадзеным артыкуле не будзем, але для разумення неабходна сказаць, што сеткавая частка дадзеных нод банальная да бязладдзя. У нашым выпадку тамака ўсяго адзін фізічны порт (eth0) з навешаным на яго ip адрасам і ўсё. Там няма ніякіх VxLAN тунэляў, тунэльных брыджаў і т д - там няма ovs наогул, бо няма ад яго сэнсу. Пры выкарыстанні ізаляцыі сетак - на дадзенай нодзе будзе два інтэрфейсу (фізічных порта, бадны, ці проста два ўлана - гэта не важна - залежыць ад таго, што вы хочаце) - адзін пад кіраванне, другі пад трафік (запіс на дыск VM, чытанне з дыска і т д).
Разабраліся што ў нас ёсць на нодах без якіх-небудзь сэрвісаў. Цяпер запусцім 4 віртуальныя машыны і паглядзім, як зменіцца апісаная вышэй схема - у нас павінны з'явіцца парты, віртуальныя роўтэры і г.д.
Пакуль што наша сетка выглядае вось так:
У нас па дзве віртуальныя машыны на кожнай камп'ют надзе. На прыкладзе compute-0 паглядзім, як усё ўключана.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ У машыны ўсяго адзін віртуальны інтэрфейс – tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Дадзены інтэрфейс глядзіць у linux bridge:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Як відаць з высновы ў брыджы ўсяго два інтэрфейсу – tap95d96a75-a0 і qvb95d96a75-a0.
Тут варта крыху спыніцца на тыпах віртуальных сеткавых прылады ў OpenStack:
vtap - віртуальны інтэрфейс, далучаны да інстансу (ВМ)
qbr - Linux bridge
qvb і qvo - vEth пара, падлучаная да Linux bridge і Open vSwitch bridge
br-int, br-tun, br-vlan – Open vSwitch bridges
patch-, int-br-, phy-br- - Open vSwitch patch-інтэрфейсы, якія злучаюць bridges
qg, qr, ha, fg, sg – парты Open vSwitch, якія выкарыстоўваюцца віртуальнымі прыладамі для падлучэння да OVS
Як вы разумееце, калі ў нас у брыджы ёсць qvb95d96a75-a0 порт, які з'яўляецца vEth парай, то дзе гэта значыць яго зваротны бок, якая лагічна павінна называцца qvo95d96a75-a0. Глядзім, якія парты ёсць на OVS.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Як мы бачым порт знаходзіцца ў br-int. Br-int выконвае ролю камутатара, які тэрмінуе парты віртуальных машын. Апроч qvo95d96a75-a0 у выснове бачны порт qvo5bd37136-47. Гэта порт у другую віртуальную машыну. У выніку наша схема зараз выглядае так:
Пытанне, які павінен адразу зацікавіць ўважлівага чытача – на які linux bridge паміж портам віртуальнай машыны і портам OVS? Справа ў тым, што для абароны машыны выкарыстоўваюцца security groups, якія есць не што іншае як iptables. OVS не працуе з iptables, таму быў прыдуманы такі "мыліца". Аднак ён аджывае сваё яму на змену прыходзіць conntrack у новых рэлізах.
Гэта значыць, у канчатковым рахунку схема выглядае так:
Дзве машыны на адным гіпервізоры ў адной L2 сеткі
Бо дзве дадзеныя VM знаходзяцца ў адной і той жа L2 сеткі і на адным і тым жа гіпервізоры, то трафік паміж імі будзе лагічна хадзіць лакальна праз br-int, бо абедзве машыны будуць у адным і тым жа VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Дзве машыны на розных гіпервізарах у адной L2 сеткі
Цяпер паглядзім, як пойдзе трафік паміж дзвюма машынамі ў адной L2 сеткі, але размешчанымі на розных гіпервізорах. Калі быць сумленным, то асабліва моцна нічога не памяняецца, проста трафік паміж гіпервізарамі пойдзе праз vxlan тунэль. Паглядзім на прыкладзе.
Адрасы віртуальных машын, паміж якімі будзем глядзець трафік:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Глядзім табліцу форвардынгу ў br-int на compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Трафік павінен сысці ў порт 2 - глядзім што гэта за порт:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$Гэта patch-tun - гэта значыць інтэрфейс у br-tun. Глядзім, што адбываецца з пакетам на br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Пакет пакуецца ў VxLAN і адпраўляецца ў порт 2. Глядзім, куды вядзе порт 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Гэта vxlan тунэль на compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Ідзем на compute-1 і глядзім, што далей адбываецца з пакетам:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Мак ёсць у табліцы форвардынгу br-int на compute-1, і як відаць з высновы вышэй бачны ён праз порт 2, які з'яўляецца портаў у бок br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Ну і далей глядзім, што ў br-int на compute-1 ёсць мак прызначэнні:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ Гэта значыць атрыманы пакет паляціць у порт 3, за якім ужо знаходзіцца віртуальная машына instance-00000003.
Усё хараство разгортвання Openstack для вывучэння на віртуальнай інфраструктуры ў тым, што мы можам без праблем адлавіць трафік паміж гіпервізарамі і паглядзець, што адбываецца з ім. Гэта мы зараз і зробім, запусцім tcpdump на vnet порце ў бок compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Першы радок паказвае, што патэк з адрас 10.0.1.85 ідзе на адрас 10.0.1.88 (ICMP трафік), прычым ён загорнуты ў VxLAN пакет з vni 22 і пакет ідзе з хаста 192.168.255.19 (compute-0) на хост192.168.255.26. compute-1). Можам праверыць, што VNI адпавядае таму, які пазначаны ў ovs.
Вернемся да гэтага радка actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0х16 - гэта vni у 16-рычнай сістэме злічэння. Перавядзем гэты лік у 10-ю сістэму:
16 = 6*16^0+1*16^1 = 6+16 = 22Гэта значыць vni адпавядае рэчаіснасці.
Другі радок паказвае зваротны трафік, ну яго тлумачыць няма сэнсу тамака і так усё ясна.
Дзве машыны ў розных сетках (маршрутызацыя паміж сеткамі)
Апошні кейс на сёння - гэта маршрутызацыя паміж сеткамі ўнутры аднаго праекта з выкарыстаннем віртуальнага маршрутызатара. Мы разглядаем выпадак без DVR (яго разгледзім у іншым артыкуле), таму маршрутызацыя адбываецца на network нодзе. У нашым выпадку network нода не вынесена ў асобную сутнасць і размешчана на control нодзе.
Для пачатку паглядзім, што маршрутызацыя працуе:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msТак як у дадзеным выпадку пакет павінен сысці на шлюз і там змашрутызаваны, нам трэба пазнаць мак адрас шлюза, для чаго паглядзім ARP табліцу ў інстансе:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Цяпер паглядзім, куды павінен быць адпраўлены трафік з прызначэннем (10.0.1.254).
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Глядзім куды вядзе порт 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Усё лагічна, трафік сыходзіць у br-tun. Паглядзім, у які vxlan тунэль ён будзе загорнуты:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ Трэці порт - гэта vxlan тунэль:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Які глядзіць на control ноду:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Трафік даляцеў да control ноды, таму нам трэба перайсці на яе і паглядзець, як будзе адбывацца маршрутызацыя.
Як вы падушыце, кантрольная нода ўсярэдзіне выглядала сапраўды таксама як і compute нода — тыя ж тры брыджы, толькі ў br-ex быў фізічны порт, праз які нода магла слаць трафік вонкі. Стварэнне інстансаў змяніла канфігурацыю на compute нодах – дадаліся linux bridge, iptables і інтэрфейсы ў ноды. Стварэнне сетак і віртуальнага маршрутызатара таксама пакінула свой адбітак на канфігурацыі control ноды.
Такім чынам, відавочна, што мак адрас gateway павінен быць у табліцы форвардынгу br-int на control нодзе. Праверым, што ён там ёсць і куды ён глядзіць:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Мак бачны з порта qr-0c52b15f-8f. Калі вярнуцца назад да спісу віртуальных партоў у Openstack, то гэты тып порта выкарыстоўваецца для падлучэння да OVS розных віртуальных прылад. Калі быць дакладней qr - гэта порт у бок віртуальнага маршрутызатара, які прадстаўлена ў выглядзе namespace.
Паглядзім, якія namespace ёсць на серверы:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Цэлыя тры экзэмпляры. Але мяркуючы па імёнах можна здагадацца аб прызначэнні кожнага з іх. Да інстансаў з ID 0 і 1 мы вернемся пазней, зараз нам цікавы namespace qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ У дадзеным namespace дзве ўнутраныя, якія былі намі створаны раней. Абодва віртуальных порта дададзены ў br-int. Праверым мас адрас порта qr-0c52b15f-8f, бо трафік, судзячы па мак адрасу прызначэння ішоў менавіта ў гэты інтэрфейс.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Гэта значыць, у дадзеным выпадку ўсё працуе па законах стандартнай маршрутызацыі. Так як трафік прызначаны хасту 10.0.2.8, то ён павінен выйсці праз другі інтэрфейс qr-92fa49b5-54 і сысці праз vxlan тунэль на compute ноду:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ Усё лагічна, ніякіх сюрпрызаў. Глядзім адкуль бачны мак адрас хаста 10.0.2.8 у br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Як належыць, трафік ідзе ў br-tun, паглядзім, у які тунэль трафік пойдзе далей:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Трафік сыходзіць у тунэль да compute-1. Ну і на compute-1 усё проста - з br-tun пакет пападае ў br-int і адтуль у інтэрфейс віртуальнай машыны:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ Праверым, што гэта сапраўды дакладны інтэрфейс:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$
Уласна мы прайшлі ўвесь шлях пакета. Думаю вы заўважылі, што трафік ішоў праз розныя vxlan тунэлі і выходзіў з рознымі VNI. Давайце паглядзім, якія гэта VNI, пасля чаго збяром дамп на порце control ноды і пераканаемся, што трафік ходзіць менавіта так, як апісана вышэй.
Такім чынам, тунэль да compute-0 мае наступны actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Перавядзем 0x16 у дзесятковую сістэму злічэння:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Тунэль да compute-1 мае наступны VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Перавядзем 0x63 у дзесятковую сістэму злічэння:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Ну і зараз паглядзім дамп:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************Першы пакет - гэта vxlan пакет з хаста 192.168.255.19 (compute-0) на хост 192.168.255.15 (control-1) з vni 22, усярэдзіне якога спакаваны ICMP пакет з хаста 10.0.1.85 на хост 10.0.2.8. Як мы палічылі вышэй, vni адпавядае таму, што мы бачылі ў высновах.
Другі пакет - гэта vxlan пакет з хаста 192.168.255.15 (control-1) на хост 192.168.255.26 (compute-1) з vni 99, усярэдзіне якога спакаваны ICMP пакет з хаста 10.0.1.85 на хост 10.0.2.8. Як мы палічылі вышэй, vni адпавядае таму, што мы бачылі ў высновах.
Два наступныя пакеты - гэта зваротны трафік з 10.0.2.8 не 10.0.1.85.
Гэта значыць, у выніку ў нас атрымалася такая схема control ноды:
Накшталт усё? Мы забыліся пра два namespace:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Як мы казалі пра архітэктура хмарнай платформы – было б добра, каб машыны атрымлівалі адрасы аўтаматам ад DHCP сервера. Гэта і ёсць два DHCP серверы на нашы дзве сеткі 10.0.1.0/24 і 10.0.2.0/24.
Праверым, што гэта так. У дадзеным namespace толькі адзін адрас - 10.0.1.1 - адрас самога DHCP сервера, і ён гэтак жа ўключаны ў br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Паглядзім, калі працэсы змяшчаюць у сваёй назве qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 на control нодзе:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ Ёсць такі працэс і зыходзячы з інфармацыі, прадстаўленай у выснове вышэй мы можам напрыклад паглядзець, што ў нас у арэндзе ў сапраўдны момант:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$У выніку мы атрымліваем вось такі набор сэрвісаў на control нодзе:
Ну і майце на ўвазе — гэта ўсяго толькі — 4 машыны, 2 унутраныя сеткі і адзін віртуальны маршрутызатар… У нас тут няма зараз вонкавых сетак, кучы розных праектаў, кожны са сваімі сеткамі (якія перасякаюцца), і ў нас выключаны размеркаваны маршрутызатар, ды ў канцы канцоў у тэставым стэндзе была ўсяго адна control нода (для адмоваўстойлівасці павінен быць кворум з трох нод). Лагічна, што ў камерцыі ўсё "трохі" складаней, але на дадзеным простым прыкладзе мы разумеем, як гэта павінна працаваць – будзе ў вас 3 ці 300 namespace вядома важна, але з пункту гледжання працы ўсёй канструкцыі – асабліва нічога не памяняецца… праўда пакуль вы не ўторкнеце які небудзь вендорскі SDN. Але гэта ўжо зусім іншая гісторыя.
Спадзяюся, было цікава. Калі ёсць заўвагі/дадаткі ну ці дзе то я адкрыта схлусіў (я чалавек і маё меркаванне заўсёды будзе суб'ектыўна) - пішыце што трэба паправіць/дадаць - усё паправім/дадамо.
У зняволенні хацелася б сказаць пару слоў аб параўнанні Openstack (як ванільнага, так і вендорскіх) з хмарным рашэннем ад кампаніі VMWare – занадта частка мне задавалі гэтае пытанне апошнія пару гадоў і я ўжо шчыра кажучы ад яго стаміўся, але ўсё ж. На мой погляд гэтыя два рашэнні параўнаць вельмі складана, але можна адназначна сказаць што мінусы ёсць у абодвух рашэннях і выбіраючы нейкае адно рашэнне трэба ўзважыць усе за і супраць.
Калі OpenStack з'яўляецца community-driven рашэннем, то VMWare мае права рабіць толькі тое, што яна хоча (чытайце - тое што ёй выгадна) і гэта лагічна - бо гэта камерцыйная кампанія, якая прывыкла зарабляць грошы на сваіх кліентах. Але тут ёсць адно вялікае і тоўстае НС – вы можаце злезці з OpenStack напрыклад ад Nokia і малой крывёй перайсці на рашэнне ад напрыклад Juniper (Contrail Cloud), але злезці з VMWare у вас наўрад ці атрымаецца. Для мяне гэтыя два рашэнні выглядаюць так — Openstack (вендорскі) гэта простая клетка, у якую вас саджаюць, але ў вас ёсць ключ і вы можаце выйсці ў любы момант. VMWare - гэта залатая клетка, ключ ад клеткі ў гаспадара і абыйдзецца ён вам вельмі дорага.
Я не агітую ні за першы прадукт ні за другі - вы выбіраеце тое, што вам трэба. Але калі б мне меўся быць такі выбар то я б абраў абодва рашэнні – VMWare для IT аблокі (малыя нагрузкі, зручнае кіраванне), OpenStack ад якога небудзь вендара (Nokia і Juniper падаюць вельмі нядрэнныя рашэнні пад ключ) – для Тэлекам аблокі. Я б не стаў выкарыстоўваць Openstack для чыстага IT – гэта як страляць з гарматы па вераб'ях, але супрацьпаказанняў выкарыстоўваць яго, акрамя як надмернасць – я не бачу. Аднак выкарыстоўваць VMWare у телекоме - як вазіць друз на Ford Raptor- хораша са боку, але кіроўцу прыходзіцца рабіць 10 рэйсаў замест аднаго.
На мой погляд самым вялікім недахопам VMWare з'яўляецца яе поўная закрытасць – кампанія вам не выдасць ніякай інфармацыі аб тым, як у яе ўладкованы напрыклад vSAN ці што там у ядры гіпервізара – ёй гэта проста не выгадна – гэта значыць вы ніколі не станеце экспертам у VMWare – без падтрымкі вендара вы асуджаныя (вельмі частка сустракаю экспертаў па VMWare якіх ставяць у тупік банальныя пытанні). Для мяне VMWare - гэта купля машыны з зачыненым на замак капотам - так, магчыма ў вас ёсць адмыслоўцы, якія могуць памяняць рамень ГРМ, але адкрыць капот зможа толькі той, хто прадаў вам гэтае рашэнне. Асабіста я не люблю рашэнні, у якія не магу ўлезці. Вы скажаце, што вам магчыма не давядзецца лезці пад капот. Ды такое магчыма, але я пагляджу на вас калі вам трэба будзе сабраць у воблаку вялікую функцыю з 20-30 віртуальных машын, 40-50 сетак, палова з якіх жадае выйсці вонкі, а другая палова просіць SR-IOV паскарэнні інакш вам трэба будзе яшчэ пару дзясятак такіх машын інакш перфомансу не годзе.
Існуюць і іншыя пункты гледжання, таму толькі вам вырашаць што выбіраць і самае галоўнае - вам жа за ваш выбар потым адказваць. Гэта ўсяго толькі маё меркаванне - чалавека які бачыў і чапаў рукамі як мінімум 4 прадукта - Nokia, Juniper, Red Hat і VMWare. Гэта значыць, мне ёсць з чым параўнаць.
Крыніца: habr.com