Бұлтты есептеулер біздің өмірімізге барған сайын тереңдеп еніп келеді және кем дегенде бір рет бұлттық қызметтерді пайдаланбаған бірде-бір адам жоқ шығар. Дегенмен, бұлт дегеніміз не және оның қалай жұмыс істейтінін көбіне идея деңгейінде де аз адамдар біледі. 5G қазірдің өзінде шындыққа айналуда және телекоммуникациялық инфрақұрылым полюстік шешімдерден бұлтты шешімдерге ауыса бастады, ол толық аппараттық шешімдерден виртуалды «бағандарға» ауысқан кездегідей.
Бүгін біз бұлтты инфрақұрылымның ішкі әлемі туралы сөйлесетін боламыз, атап айтқанда, желі бөлігінің негіздерін қарастырамыз.
Бұлт дегеніміз не? Бірдей виртуализация - профиль көрінісі?
Логикалық сұрақ емес. Жоқ - бұл виртуализация емес, бірақ онсыз мүмкін емес. Екі анықтаманы қарастырайық:
Бұлтты есептеулер (бұдан әрі - бұлттық) ең аз кідіріспен және қызмет провайдеріне ең аз шығынмен сұраныс бойынша орналастырылуы және іске қосылуы қажет таратылған есептеу ресурстарына пайдаланушыға ыңғайлы қолжетімділікті қамтамасыз ету үлгісі болып табылады.
Виртуалдандыру - бұл бір физикалық нысанды (мысалы, серверді) бірнеше виртуалдыға бөлу мүмкіндігі, осылайша ресурстарды пайдалануды арттырады (мысалы, сізде 3-25 пайызға 30 сервер жүктелді, виртуализациядан кейін 1 сервер жүктеледі. 80-90 пайыз). Әрине, виртуалдандыру кейбір ресурстарды жейді - сіз гипервизорды тамақтандыруыңыз керек, бірақ тәжірибе көрсеткендей, ойын шамға тұрарлық. Виртуализацияның тамаша мысалы - виртуалды машиналарды тамаша дайындайтын VMWare немесе мысалы, мен ұнататын KVM, бірақ бұл талғам мәселесі.
Виртуализацияны біз байқамай қолданамыз, тіпті темір маршрутизаторлар виртуализацияны қолданады - мысалы, JunOS-тың соңғы нұсқасында операциялық жүйе нақты уақыттағы Linux дистрибутивінің (Wind River 9) үстіне виртуалды машина ретінде орнатылған. Бірақ виртуализация бұлт емес, бірақ бұлт виртуализациясыз өмір сүре алмайды.
Виртуализация - бұлт құрылатын құрылыс блоктарының бірі.
Бір L2 доменіне бірнеше гипервизорларды жинау арқылы бұлт жасау, вландарды автоматты түрде тіркеу үшін бірнеше yaml ойын кітаптарын қосу және виртуалды машиналарды автоматты түрде жасау үшін оған оркестрлік жүйе сияқты нәрсені кептелу жұмыс істемейді. Бұл дәлірек болады, бірақ нәтижесінде пайда болған Франкенштейн бізге қажет бұлт емес, бірақ ол басқалар үшін түпкі арман болуы мүмкін. Сонымен қатар, егер сіз бірдей Openstack-ті алсаңыз, бұл әлі де Франкенштейн, бірақ әзірше бұл туралы айтпай-ақ қояйық.
Бірақ мен түсінемін, жоғарыда келтірілген анықтамадан бұлт деп нені атауға болатыны анық емес.
Сондықтан, NIST (Ұлттық стандарттар және технологиялар институты) құжаты бұлттық инфрақұрылымға ие болуы керек 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) — осы үлгіні пайдаланған кезде қызмет провайдері клиентке қызметке арналған дайындаманы береді, мысалы, веб-серверді алайық. Қызмет провайдері клиентті виртуалды сервермен қамтамасыз етті (шын мәнінде, RAM/CPU/Storage/Nets және т. мұның барлығын клиенттің өзі жасайды және қызмет көрсету үшін клиент жауап береді. Қызмет провайдері, алдыңғы жағдайдағыдай, физикалық жабдықтың, гипервизорлардың, виртуалды машинаның өзіне, оның желіге қолжетімділігіне және т.б. жұмысына жауап береді, бірақ қызметтің өзі енді оның жауапкершілік аймағында емес.
Қызмет ретінде инфрақұрылым (IaaS) - бұл тәсіл қазірдің өзінде қызықтырақ, шын мәнінде, қызмет провайдері клиентті толық виртуалдандырылған инфрақұрылыммен қамтамасыз етеді - яғни CPU Cores, RAM, Networks және т.б. сияқты ресурстардың кейбір жиынтығы (пул). Қалғанының бәрі клиент – бөлінген пул (квота) шеңберінде клиент осы ресурстармен не істегісі келеді – бұл жеткізуші үшін аса маңызды емес. Клиент өзінің vEPC жасағысы келе ме, тіпті шағын операторды құрып, байланыс қызметтерін ұсынғысы келеді ме - сұрақ жоқ - мұны жасаңыз. Мұндай сценарийде қызмет провайдері ресурстарды, олардың ақауларға төзімділігі мен қолжетімділігін, сондай-ақ осы ресурстарды біріктіруге және оларды кез келген уақытта ресурстарды көбейту немесе азайту мүмкіндігімен клиентке қолжетімді етуге мүмкіндік беретін ОЖ үшін жауапты болады. клиенттің өтініші бойынша. Клиент өзіне-өзі қызмет көрсету порталы мен консоль арқылы барлық виртуалды машиналарды және басқа шиналарды өзі конфигурациялайды, соның ішінде желілерді орнату (сыртқы желілерді қоспағанда).
OpenStack дегеніміз не?
Үш нұсқада да қызмет провайдеріне бұлтты инфрақұрылымды жасауға мүмкіндік беретін ОЖ қажет. Шындығында, SaaS көмегімен бір емес, бірнеше бөлімше технологиялардың барлық стекке жауап береді - инфрақұрылымға жауапты бөлімше бар - яғни ол басқа бөлімшеге IaaS береді, бұл бөлім клиентке SaaS береді. OpenStack - қосқыштар, серверлер мен сақтау жүйелерін бір ресурс пулына жинауға, осы жалпы пулды қосалқы пулдарға (жалға алушыларға) бөлуге және осы ресурстарды желі арқылы клиенттерге ұсынуға мүмкіндік беретін бұлттық операциялық жүйелердің бірі.
OpenStack стандартты аутентификация механизмдерін пайдалана отырып API арқылы қамтамасыз етілген және басқарылатын есептеу ресурстарының, деректерді сақтаудың және желілік ресурстардың үлкен пулдарын басқаруға мүмкіндік беретін бұлттық операциялық жүйе.
Басқаша айтқанда, бұл бұлтты қызметтерді (жалпыға да, жеке де) жасауға арналған тегін бағдарламалық қамтамасыз ету жобаларының жиынтығы, яғни сервер мен коммутациялық жабдықты ресурстардың бір пулына біріктіруге, басқаруға мүмкіндік беретін құралдар жиынтығы. ақауларға төзімділіктің қажетті деңгейін қамтамасыз ететін бұл ресурстар.
Осы материалды жазу кезінде OpenStack құрылымы келесідей көрінеді:
Суреттен алынған
OpenStack құрамына кіретін құрамдастардың әрқайсысы белгілі бір функцияны орындайды. Бұл бөлінген архитектура шешімге қажетті функционалдық құрамдас бөліктерді қосуға мүмкіндік береді. Дегенмен, кейбір компоненттер түбірлік құрамдас бөліктер болып табылады және оларды жою тұтастай шешімнің толық немесе ішінара жұмыс істемеуіне әкеледі. Бұл компоненттер әдетте келесідей жіктеледі:
- Dashboard — OpenStack қызметтерін басқаруға арналған веб-негізделген GUI
- трапеция басқа қызметтер үшін аутентификация және авторизация функционалдығын қамтамасыз ететін, сондай-ақ пайдаланушының тіркелгі деректерін және олардың рөлдерін басқаратын орталықтандырылған сәйкестендіру қызметі болып табылады.
- нейтронды - әртүрлі OpenStack қызметтерінің интерфейстері арасындағы байланысты қамтамасыз ететін желілік қызмет (соның ішінде VM құрылғылары арасындағы байланыс және олардың сыртқы әлемге қол жеткізуі)
- Шлак — виртуалды машиналар үшін блоктық жадқа қол жеткізуді қамтамасыз етеді
- Nova — виртуалды машиналардың өмірлік циклін басқару
- Қарау — виртуалды машинаның суреттері мен суреттерінің репозиторийі
- Swift — сақтау объектісіне қол жеткізуді қамтамасыз етеді
- Цеилометр — телеметрияны жинау және қолжетімді және тұтынылатын ресурстарды өлшеу мүмкіндігін қамтамасыз ететін қызмет
- ыстық — ресурстарды автоматты түрде құру және қамтамасыз ету үшін шаблондар негізіндегі оркестрлеу
Барлық жобалардың толық тізімін және олардың мақсатын көруге болады .
Әрбір OpenStack компоненті белгілі бір функцияны орындайтын және сол функцияны басқару және бірыңғай инфрақұрылымды жасау үшін басқа бұлттық операциялық жүйе қызметтерімен өзара әрекеттесу үшін API ұсынатын қызмет болып табылады. Мысалы, Nova есептеу ресурстарын басқаруды және осы ресурстарды конфигурациялауға қол жеткізу үшін API ұсынады, Glance кескінді басқаруды және оларды басқаруға арналған API ұсынады, Cinder блокты сақтауды және оны басқаруға арналған API ұсынады, т.б. Барлық функциялар бір-бірімен өте тығыз байланысты.
Дегенмен, егер сіз оған қарасаңыз, OpenStack-те жұмыс істейтін барлық қызметтер, сайып келгенде, желіге қосылған виртуалды машинаның (немесе контейнердің) қандай да бір түрі болып табылады. Сұрақ туындайды - бізге көп элементтер не үшін қажет?
Виртуалды машинаны құру және оны желіге қосу және Openstack-те тұрақты сақтау алгоритмін қарастырайық.
- Құрылғыны жасауға сұраныс жасағанда, ол Horizon (бақылау тақтасы) арқылы сұрау болсын немесе CLI арқылы сұрау болсын, бірінші орын алатын нәрсе - Keystone жүйесінде сұрауыңызды авторизациялау - сіз машина жасай аласыз ба, оның осы желіні пайдалану құқығы, сіздің квотаның жобасын жасау және т.б.
- Keystone сұрауыңызды аутентификациялайды және жауап хабарында аутентификация белгісін жасайды, ол әрі қарай пайдаланылады. Keystone-дан жауап алғаннан кейін сұраныс Nova (nova api) бағытына жіберіледі.
- Nova-api бұрын жасалған аутентификация белгісін пайдаланып Keystone компаниясына хабарласу арқылы сұрауыңыздың жарамдылығын тексереді.
- Keystone аутентификацияны орындайды және осы аутентификация белгісіне негізделген рұқсаттар мен шектеулер туралы ақпаратты береді.
- Nova-api nova-деректер базасында жаңа VM үшін жазба жасайды және машинаны жасау сұрауын nova-scheduler-ге жібереді.
- Nova-жоспарлаушы көрсетілген параметрлер, салмақтар және аймақтар негізінде VM орналастырылатын хостты (компьютер түйінін) таңдайды. Бұл туралы жазба және VM идентификаторы nova-деректер базасына жазылады.
- Содан кейін nova-жоспарлаушы дананы орналастыру сұрауымен nova-compute байланысады. Nova-computer құрылғы параметрлері туралы ақпаратты алу үшін nova-conductor байланысады (nova-conductor — nova-деректер базасы мен nova-compute арасында прокси-сервер ретінде әрекет ететін nova элементі, дерекқормен проблемаларды болдырмау үшін nova-деректер базасына сұраулар санын шектейді. консистенциясы жүктемені азайту).
- Nova-conductor nova-деректер базасынан сұралған ақпаратты алады және оны nova-computer-ге береді.
- Содан кейін nova-compute сурет идентификаторын алу үшін шолу жасайды. Glace Keystone ішіндегі сұрауды тексереді және сұралған ақпаратты қайтарады.
- Nova-comput желі параметрлері туралы ақпаратты алу үшін нейтронмен байланысады. Қарау сияқты, нейтрон Keystone бағдарламасында сұранысты тексереді, содан кейін ол дерекқорға жазба жасайды (порт идентификаторы және т.б.), порт жасау үшін сұраныс жасайды және сұралған ақпаратты nova-compute жүйесіне қайтарады.
- Nova-compute контактілері виртуалды машинаға көлемді бөлуге сұраныс береді. Қарау сияқты, сидр Keystone ішіндегі сұрауды тексереді, көлемді құру сұрауын жасайды және сұралған ақпаратты қайтарады.
- Nova-compute libvirt контактілері көрсетілген параметрлері бар виртуалды машинаны орналастыру сұрауымен.
Шындығында, қарапайым виртуалды машинаны жасаудың қарапайым болып көрінетін операциясы бұлттық платформаның элементтері арасындағы API қоңырауларының осындай құйынына айналады. Оның үстіне, көріп отырғаныңыздай, тіпті бұрын тағайындалған қызметтер де өзара әрекеттесу орын алатын кішірек құрамдас бөліктерден тұрады. Машинаны жасау - бұлт платформасы сізге мүмкіндік беретін нәрсенің аз ғана бөлігі - трафикті теңестіруге жауапты қызмет, блокты сақтауға жауапты қызмет, DNS үшін жауапты қызмет, жалаң металл серверлерді қамтамасыз етуге жауапты қызмет және т.б. Бұлт виртуалды машиналарды қой отары сияқты (виртуализацияға қарағанда) қарауға мүмкіндік береді. Егер виртуалды ортада құрылғыңызға бірдеңе болса - сіз оны сақтық көшірмелерден қалпына келтіресіз және т.б., бірақ бұлттық қолданбалар виртуалды машина маңызды рөл атқармайтындай етіп салынған - виртуалды машина «қайтыс болды» - проблема жоқ. - Жаңадан жасалған көлік шаблонға негізделген және олар айтқандай, жасақ жауынгердің жоғалғанын байқамады. Әрине, бұл оркестрлік механизмдердің болуын қамтамасыз етеді - Жылу үлгілерін пайдаланып, ондаған желілер мен виртуалды машиналардан тұратын күрделі функцияны оңай орналастыруға болады.
Желісіз бұлтты инфрақұрылым жоқ екенін әрқашан есте ұстаған жөн - әрбір элемент бір жолмен желі арқылы басқа элементтермен өзара әрекеттеседі. Сонымен қатар, бұлтта мүлдем статикалық емес желі бар. Әрине, астарлы желі азды-көпті статикалық - жаңа түйіндер мен қосқыштар күн сайын қосылмайды, бірақ қабаттасушы компонент үнемі өзгеріп отырады және сөзсіз өзгереді - жаңа желілер қосылады немесе жойылады, жаңа виртуалды машиналар пайда болады және ескілері болады. өлу. Мақаланың басында берілген бұлт анықтамасынан есіңізде болса, ресурстар пайдаланушыға автоматты түрде және қызмет провайдерінің араласуынсыз (немесе жақсырақ) бөлінуі керек. Яғни, желілік ресурстарды қамтамасыз ету түрі қазір http/https арқылы қол жеткізуге болатын жеке шот түріндегі фронт түрінде және желілік инженер Василийдің сервері ретінде бұлт емес, тіпті. егер Василийдің сегіз қолы болса.
Нейтрон желілік қызмет ретінде бұлттық инфрақұрылымның желілік бөлігін басқаруға арналған API ұсынады. Қызмет Network-as-a-Service (NaaS) деп аталатын абстракциялық деңгейді қамтамасыз ету арқылы Openstack желілік бөлігін қуаттайды және басқарады. Яғни, желі виртуалды өлшенетін бірлік, мысалы, виртуалды процессор өзегі немесе жедел жады көлемі.
Бірақ OpenStack желілік бөлігінің архитектурасына көшпес бұрын, бұл желі OpenStack-те қалай жұмыс істейтінін және желі неліктен бұлттың маңызды және ажырамас бөлігі болып табылатынын қарастырайық.
Сонымен, бізде екі RED клиенттік VM және екі GREEN клиенттік VM бар. Бұл машиналар екі гипервизорда осылай орналасқан деп есептейік:
Қазіргі уақытта бұл жай ғана 4 серверді виртуалдандыру және басқа ештеңе жоқ, өйткені біз осы уақытқа дейін 4 серверді виртуализациялап, оларды екі физикалық серверге орналастырдық. Ал әзірге олар желіге қосылмаған.
Бұлтты жасау үшін бізге бірнеше компоненттерді қосу керек. Біріншіден, біз желі бөлігін виртуализациялаймыз - біз осы 4 машинаны жұппен қосуымыз керек, ал клиенттер L2 қосылымын қалайды. Сіз коммутаторды пайдалана аласыз және оның бағыты бойынша магистральді конфигурациялай аласыз және барлығын Linux көпірі немесе неғұрлым озық пайдаланушылар үшін openvswitch арқылы шеше аласыз (бұл туралы кейінірек ораламыз). Бірақ көптеген желілер болуы мүмкін және L2-ді коммутатор арқылы үнемі итермелеу жақсы идея емес - әртүрлі бөлімдер, қызмет көрсету үстелі, өтініштің аяқталуын бірнеше ай күту, ақауларды жою апталары - қазіргі әлемде бұл тәсіл енді жұмыс істемейді. Ал компания мұны неғұрлым тез түсінсе, соғұрлым алға жылжу оңай болады. Сондықтан, гипервизорлар арасында виртуалды машиналарымыз байланысатын L3 желісін таңдаймыз және осы L3 желісінің үстіне виртуалды машиналарымыздың трафигі жұмыс істейтін виртуалды L2 қабаттасатын желілерді саламыз. Инкапсуляция ретінде GRE, Geneve немесе VxLAN пайдалануға болады. Әсіресе маңызды болмаса да, қазір соңғысына тоқталайық.
Біз VTEP-ті бір жерден табуымыз керек (барлығы VxLAN терминологиясымен таныс деп үміттенемін). Бізде тікелей серверлерден келетін L3 желісі болғандықтан, бізге VTEP-ті серверлердің өзінде орналастыруға ештеңе кедергі келтірмейді және OVS (OpenvSwitch) мұны өте жақсы жасайды. Нәтижесінде біз бұл дизайнды алдық:
Виртуалды машиналар арасындағы трафикті бөлу керек болғандықтан, виртуалды машиналарға арналған порттарда әртүрлі vlan нөмірлері болады. Тег нөмірі бір виртуалды қосқышта ғана рөл атқарады, өйткені VxLAN-да инкапсуляцияланған кезде біз оны оңай алып тастай аламыз, өйткені бізде VNI болады.
Енді біз машиналар мен виртуалды желілерді еш қиындықсыз жасай аламыз.
Дегенмен, клиентте басқа құрылғы болса, бірақ басқа желіде болса ше? Бізге желілер арасында root керек. Орталықтандырылған маршруттау пайдаланылған кезде қарапайым опцияны қарастырамыз - яғни трафик арнайы бөлінген желі түйіндері арқылы бағытталады (жақсы, әдетте, олар басқару түйіндерімен біріктіріледі, сондықтан бізде бірдей нәрсе болады).
Күрделі ештеңе жоқ сияқты - біз басқару түйінінде көпір интерфейсін жасаймыз, оған трафикті жүргіземіз және сол жерден біз оны қажет жерге бағыттаймыз. Бірақ мәселе ҚЫЗЫЛ клиент 10.0.0.0/24 желісін пайдаланғысы келеді, ал ЖАСЫЛ клиент 10.0.0.0/24 желісін пайдаланғысы келеді. Яғни, біз адрестік кеңістіктерді қиылысуды бастаймыз. Сонымен қатар, клиенттер басқа клиенттердің ішкі желілеріне бағыттау мүмкіндігін қаламайды, бұл мағынасы бар. Желілер мен клиенттік деректер трафигін бөлу үшін біз олардың әрқайсысы үшін жеке аттар кеңістігін бөлеміз. Атау кеңістігі шын мәнінде Linux желі стекінің көшірмесі болып табылады, яғни RED аттар кеңістігіндегі клиенттер ЖАСЫЛ аттар кеңістігінен клиенттерден толығымен оқшауланған (жақсы, не осы клиенттік желілер арасында маршрутизация әдепкі аттар кеңістігі арқылы немесе жоғары ағынды көлік жабдығы арқылы рұқсат етілген).
Яғни, біз келесі диаграмманы аламыз:
L2 туннельдері барлық есептеу түйіндерінен басқару түйініне біріктіріледі. осы желілерге арналған L3 интерфейсі орналасқан түйін, әрқайсысы оқшаулау үшін арнайы аттар кеңістігінде.
Дегенмен, біз ең бастысын ұмытып кеттік. Виртуалды машина клиентке қызмет көрсетуі керек, яғни оған қол жеткізуге болатын кем дегенде бір сыртқы интерфейс болуы керек. Яғни, біз сыртқы әлемге шығуымыз керек. Мұнда әртүрлі нұсқалар бар. Ең қарапайым нұсқаны жасайық. Біз әрбір клиентке провайдердің желісінде жарамды және басқа желілермен қабаттаспайтын бір желіні қосамыз. Желілер провайдер желісінің жағындағы әртүрлі VRF-терді қиып, қарауы мүмкін. Желі деректері де әрбір клиенттің аттар кеңістігінде тұрады. Дегенмен, олар әлі де бір физикалық (немесе байланыс, бұл логикалық) интерфейс арқылы сыртқы әлемге шығады. Клиенттік трафикті бөлу үшін сыртқа шығатын трафик клиентке бөлінген VLAN тегімен белгіленеді.
Нәтижесінде біз мына диаграмманы алдық:
Ақылға қонымды сұрақ - неге есептеу түйіндерінде шлюздер жасамасқа? Бұл үлкен мәселе емес, сонымен қатар таратылған маршрутизаторды (DVR) қоссаңыз, бұл жұмыс істейді. Бұл сценарийде біз Openstack-те әдепкі бойынша пайдаланылатын орталықтандырылған шлюзі бар ең қарапайым опцияны қарастырамыз. Жоғары жүктеме функциялары үшін олар бөлінген маршрутизаторды да, SR-IOV және Passthrough сияқты жеделдету технологияларын да пайдаланады, бірақ олар айтқандай, бұл мүлдем басқа оқиға. Алдымен, негізгі бөлікпен айналысайық, содан кейін біз егжей-тегжейлі қарастырамыз.
Шын мәнінде, біздің схема қазірдің өзінде жұмыс істейді, бірақ бірнеше нюанстар бар:
- Біз машиналарымызды қандай да бір жолмен қорғауымыз керек, яғни коммутатор интерфейсіне клиентке сүзгі қою керек.
- Виртуалды машинаның IP мекенжайын автоматты түрде алуына мүмкіндік беріңіз, сонда сіз оған консоль арқылы әр уақытта кіріп, мекенжайды тіркемеуіңіз керек.
Машинаны қорғаудан бастайық. Бұл үшін сіз банальды iptables пайдалана аласыз, неге жоқ.
Яғни, қазір біздің топологиямыз біршама күрделене түсті:
Әрі қарай жүрейік. Біз DHCP серверін қосуымыз керек. Әрбір клиент үшін DHCP серверлерін орналастырудың ең тамаша орны жоғарыда аталған басқару түйіні болады, онда аттар кеңістігі орналасқан:
Дегенмен, шағын мәселе бар. Барлығы қайта жүктелсе және DHCP жүйесінде мекенжайларды жалға алу туралы барлық ақпарат жоғалса ше? Машиналарға жаңа мекенжайлар берілетіні қисынды, бұл өте ыңғайлы емес. Мұнда шығудың екі жолы бар – не домендік атауларды пайдаланыңыз және әр клиент үшін DNS серверін қосыңыз, сонда мекенжай біз үшін аса маңызды болмайды (k8s жүйесіндегі желі бөлігіне ұқсас) – бірақ сыртқы желілерде мәселе бар, өйткені мекенжайларды оларда DHCP арқылы да шығаруға болады - сізге бұлттық платформадағы DNS серверлерімен және сыртқы DNS серверімен синхрондау қажет, менің ойымша, бұл өте икемді емес, бірақ әбден мүмкін. Немесе екінші опция метадеректерді пайдалану болып табылады - яғни, құрылғы адресті алған болса, DHCP сервері құрылғыға қандай мекенжай беру керектігін білуі үшін құрылғыға берілген мекенжай туралы ақпаратты сақтау. Екінші нұсқа қарапайым және икемді, өйткені ол автомобиль туралы қосымша ақпаратты сақтауға мүмкіндік береді. Енді диаграммаға агент метадеректерін қосамыз:
Сондай-ақ талқылауға тұрарлық тағы бір мәселе - барлық клиенттердің бір сыртқы желіні пайдалану мүмкіндігі, өйткені сыртқы желілер, егер олар бүкіл желіде жарамды болуы керек болса, қиын болады - бұл желілерді үнемі бөлу және бақылау қажет. Барлық клиенттер үшін бір сыртқы алдын ала конфигурацияланған желіні пайдалану мүмкіндігі жалпы бұлтты құру кезінде өте пайдалы болады. Бұл машиналарды орналастыруды жеңілдетеді, себебі бізге мекенжай дерекқорымен кеңесудің және әрбір клиенттің сыртқы желісі үшін бірегей мекенжай кеңістігін таңдаудың қажеті жоқ. Бұған қоса, біз сыртқы желіні алдын ала тіркей аламыз және орналастыру кезінде бізге тек сыртқы мекенжайларды клиенттік машиналармен байланыстыру қажет болады.
Міне, NAT бізге көмекке келеді - біз клиенттерге NAT аудармасы арқылы әдепкі аттар кеңістігі арқылы сыртқы әлемге қол жеткізуге мүмкіндік береміз. Міне, кішкентай мәселе. Клиент сервері сервер ретінде емес, клиент ретінде әрекет етсе, бұл жақсы, яғни ол қосылымдарды қабылдамай, бастайды. Бірақ біз үшін бәрі керісінше болады. Бұл жағдайда трафикті қабылдау кезінде басқару түйіні бұл трафик А клиентінің виртуалды машинасына арналғанын түсінуі үшін NAT тағайындалған орнын орындауымыз керек, яғни сыртқы мекенжайдан NAT аудармасын жасау керек, мысалы 100.1.1.1. .10.0.0.1, ішкі мекенжайға 100. Бұл жағдайда барлық клиенттер бір желіні пайдаланса да, ішкі оқшаулау толығымен сақталады. Яғни, басқару түйінінде dNAT және sNAT жасауымыз керек. Қалқымалы мекенжайлары бар жалғыз желіні немесе сыртқы желілерді немесе екеуін бірден пайдалану керек пе, бұлтқа не әкелгіңіз келетініне байланысты. Біз диаграммаға өзгермелі мекенжайларды қоспаймыз, бірақ бұрын қосылған сыртқы желілерді қалдырамыз - әрбір клиенттің өзінің сыртқы желісі бар (диаграммада олар сыртқы интерфейсте vlan 200 және XNUMX ретінде көрсетілген).
Нәтижесінде біз белгілі бір икемділікке ие, бірақ ақауларға төзімділік тетіктері әлі жоқ қызықты және сонымен бірге жақсы ойластырылған шешім алдық.
Біріншіден, бізде бір ғана басқару түйіні бар - оның істен шығуы барлық жүйелердің күйреуіне әкеледі. Бұл мәселені шешу үшін кем дегенде 3 түйіннен тұратын кворум жасау керек. Мұны диаграммаға қосайық:
Әрине, барлық түйіндер синхрондалады және белсенді түйін кеткенде, басқа түйін оның жауапкершілігін алады.
Келесі мәселе - виртуалды машина дискілері. Қазіргі уақытта олар гипервизорлардың өзінде сақталады, ал гипервизормен проблемалар туындаған жағдайда біз барлық деректерді жоғалтамыз - және дискіні емес, бүкіл серверді жоғалтсақ, рейдтің болуы мұнда көмектеспейді. Бұл әрекетті орындау үшін бізге қандай да бір сақтаудың алдыңғы бөлігі ретінде әрекет ететін қызметті жасау керек. Оның қандай сақтау орны болатыны біз үшін аса маңызды емес, бірақ ол біздің деректерімізді дискінің де, түйіннің де, мүмкін, бүкіл шкафтың істен шығуынан қорғауы керек. Мұнда бірнеше нұсқалар бар - әрине, Fiber Channel бар SAN желілері бар, бірақ шынын айтайық - FC қазірдің өзінде өткеннің реликті - көліктегі E1 аналогы - иә, келісемін, ол әлі де қолданылады, бірақ онсыз мүлде мүмкін емес жерде ғана. Сондықтан, мен 2020 жылы FC желісін өз еркіммен орналастырмас едім, өйткені басқа да қызықты баламалар бар. Әрқайсысының жеке пікірі болса да, ФК барлық шектеулерімен бізге қажет деп санайтындар болуы мүмкін - мен дауласпаймын, әркімнің өз пікірі бар. Дегенмен, менің ойымша, ең қызықты шешім - Ceph сияқты SDS пайдалану.
Ceph дискілердің орналасуын ескере отырып, паритеттік тексеруі бар кодтардан (5 немесе 6-шы рейдтерге ұқсас) бастап, әртүрлі дискілерге деректерді толық репликациялаумен аяқталатын ықтимал сақтық көшірме опцияларымен жоғары қолжетімді деректерді сақтау шешімін құруға мүмкіндік береді. серверлер, және шкафтардағы серверлер және т.б.
Ceph құру үшін сізге тағы 3 түйін қажет. Жадпен өзара әрекеттесу блок, объект және файлдарды сақтау қызметтерін пайдалана отырып, желі арқылы да жүзеге асырылатын болады. Схемаға жад қосамыз:
Ескертпе: гиперконвергентті есептеу түйіндерін де жасауға болады - бұл бірнеше функцияларды бір түйінде біріктіру тұжырымдамасы - мысалы, сақтау+есептеу - ceph сақтау үшін арнайы түйіндерді арнамай. Біз бірдей ақауларға төзімді схеманы аламыз - өйткені SDS біз көрсеткен брондау деңгейімен деректерді сақтайды. Дегенмен, гиперконвергентті түйіндер әрқашан компромисс болып табылады - сақтау түйіні бір қарағанда көрінгендей ауаны қыздырып қана қоймайды (өйткені онда виртуалды машиналар жоқ) - ол CPU ресурстарын SDS қызмет көрсетуге жұмсайды (шын мәнінде бұл бәрін жасайды) түйіндердің, дискілердің және т.б. ақаулардан кейін репликация және қалпына келтіру). Яғни, егер сіз оны жадпен біріктірсеңіз, есептеу түйінінің кейбір қуатын жоғалтасыз.
Осы заттардың барлығын қандай да бір жолмен басқару керек - бізге машина, желі, виртуалды маршрутизатор және т.б. жасай алатын нәрсе керек. Бұл әрекетті орындау үшін басқару түйініне бақылау тақтасы ретінде әрекет ететін қызметті қосамыз - клиент осы порталға http/ https арқылы қосылып, өзіне қажет (жақсы, дерлік) барлығын жасай алады.
Нәтижесінде бізде қазір ақауларға төзімді жүйе бар. Бұл инфрақұрылымның барлық элементтері қандай да бір жолмен басқарылуы керек. Openstack - бұл әрқайсысы белгілі бір функцияны қамтамасыз ететін жобалар жиынтығы деп бұрын сипатталған болатын. Көріп отырғанымыздай, конфигурациялауды және басқаруды қажет ететін элементтер жеткілікті. Бүгін біз желілік бөлік туралы айтатын боламыз.
Нейтрондардың архитектурасы
OpenStack-те виртуалды машина порттарын жалпы L2 желісіне қосуға, әртүрлі L2 желілерінде орналасқан VM-лер арасындағы трафикті бағыттауды қамтамасыз етуге, сонымен қатар NAT, Floating IP, DHCP және т.
Жоғары деңгейде желі қызметінің жұмысын (негізгі бөлігі) келесідей сипаттауға болады.
VM іске қосқан кезде желі қызметі:
- Берілген VM (немесе порттар) үшін порт жасайды және ол туралы DHCP қызметіне хабарлайды;
- Жаңа виртуалды желі құрылғысы жасалды (libvirt арқылы);
- VM 1-қадамда жасалған порт(тарға) қосылады;
Бір қызығы, Нейтронның жұмысы Linux жүйесіне енгендердің барлығына таныс стандартты механизмдерге негізделген - аттар кеңістігі, iptables, linux bridges, openvswitch, conntrack және т.б.
Нейтронның SDN контроллері емес екенін бірден түсіндіру керек.
Нейтрон өзара байланысты бірнеше компоненттерден тұрады:
Openstack-нейтрон-сервер API арқылы пайдаланушы сұрауларымен жұмыс істейтін демон болып табылады. Бұл жын ешқандай желілік қосылымдарды тіркеуге қатыспайды, бірақ ол үшін қажетті ақпаратты өзінің плагиндеріне береді, содан кейін қажетті желі элементін конфигурациялайды. OpenStack түйіндеріндегі нейтрондық агенттер Нейтрон серверінде тіркеледі.
Нейтрон-сервер шын мәнінде екі бөліктен тұратын питон тілінде жазылған қолданба болып табылады:
- REST қызметі
- Нейтрондық плагин (негізгі/қызмет)
REST қызметі басқа компоненттерден API қоңырауларын қабылдауға арналған (мысалы, кейбір ақпаратты ұсыну туралы сұрау және т.б.)
Плагиндер API сұраулары кезінде шақырылатын қосылатын бағдарламалық құрал құрамдастары/модульдері болып табылады, яғни қызметтің атрибуты олар арқылы жүзеге асады. Плагиндер екі түрге бөлінеді - сервистік және түбірлік. Әдетте, жылқы плагині негізінен мекенжай кеңістігін және VM арасындағы L2 қосылымдарын басқаруға жауап береді, ал сервистік плагиндер VPN немесе FW сияқты қосымша функционалдылықты қамтамасыз етеді.
Мысалы, бүгінгі күні қолжетімді плагиндер тізімін көруге болады
Бірнеше қызмет плагиндері болуы мүмкін, бірақ тек бір жылқы плагині болуы мүмкін.
openstack-нейтрон-ml2 стандартты Openstack түбірлік плагині болып табылады. Бұл плагиннің модульдік архитектурасы бар (алдыңғыдан айырмашылығы) және желілік қызметті оған қосылған драйверлер арқылы конфигурациялайды. Плагиннің өзін сәл кейінірек қарастырамыз, өйткені шын мәнінде ол OpenStack-тің желілік бөлігіндегі икемділігін береді. Түбірлік плагинді ауыстыруға болады (мысалы, Contrail Networking мұндай ауыстыруды жасайды).
RPC қызметі (rabbitmq-сервер) — кезекті басқаруды және басқа OpenStack қызметтерімен өзара әрекеттесуді, сондай-ақ желілік қызмет агенттері арасындағы өзара әрекетті қамтамасыз ететін қызмет.
Желілік агенттер — желі қызметтері конфигурацияланатын әрбір түйінде орналасқан агенттер.
Агенттердің бірнеше түрі бар.
Негізгі агент болып табылады L2 агенті. Бұл агенттер гипервизорлардың әрқайсысында, соның ішінде басқару түйіндерінде (дәлірек айтқанда, жалға алушыларға кез келген қызметті ұсынатын барлық түйіндерде) жұмыс істейді және олардың негізгі функциясы виртуалды машиналарды жалпы L2 желісіне қосу, сондай-ақ кез келген оқиғалар болған кезде ескертулерді жасау ( мысалы, портты өшіру/қосу).
Келесі, кем емес маңызды агент L3 агенті. Әдепкі бойынша, бұл агент тек желі түйінінде жұмыс істейді (көбінесе желі түйіні басқару түйінімен біріктіріледі) және жалға алушы желілері арасында (оның желілері мен басқа жалға алушылардың желілері арасында) маршруттауды қамтамасыз етеді және сыртқы әлемге қол жетімді, NAT, сондай-ақ DHCP қызметі). Дегенмен, DVR (таратылған маршрутизатор) пайдаланған кезде L3 плагинінің қажеттілігі есептеу түйіндерінде де пайда болады.
L3 агенті әрбір жалға алушыға өзінің оқшауланған желілерінің жиынтығын және трафикті бағыттайтын және 2-деңгей желілері үшін шлюз қызметтерін ұсынатын виртуалды маршрутизаторлардың функционалдығын қамтамасыз ету үшін Linux аттар кеңістігін пайдаланады.
дерекқор — желілердің, ішкі желілердің, порттардың, пулдардың және т.б. идентификаторлардың мәліметтер базасы.
Іс жүзінде, 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 ~]$
Шын мәнінде, бұл нейтронның бүкіл құрылымы. Енді ML2 плагиніне біраз уақыт жұмсаған жөн.
Модульдік қабат 2
Жоғарыда айтылғандай, плагин стандартты OpenStack түбірлік плагин болып табылады және модульдік архитектурасына ие.
ML2 плагинінің предшесі монолитті құрылымға ие болды, ол, мысалы, бір қондырғыда бірнеше технологияларды араластыруға мүмкіндік бермеді. Мысалы, сіз бір уақытта openvswitch және linuxbridge екеуін де пайдалана алмайсыз - біріншісін де, екіншісін де. Осы себепті архитектурасы бар ML2 плагині жасалды.
ML2 екі компоненттен тұрады - драйверлердің екі түрі: типті драйверлер және механизм драйверлері.
Драйверлерді теріңіз VxLAN, VLAN, GRE сияқты желілік қосылымдарды ұйымдастыру үшін қолданылатын технологияларды анықтаңыз. Бұл ретте жүргізуші әртүрлі технологияларды пайдалануға мүмкіндік береді. Стандартты технология қабаттасқан желілер мен vlan сыртқы желілері үшін VxLAN инкапсуляциясы болып табылады.
Түр драйверлері келесі желі түрлерін қамтиды:
жазық - тегсіз желі
VLAN желілері - тегтелген желі
жергілікті — барлығы бір қондырғыға арналған желінің арнайы түрі (мұндай қондырғылар әзірлеушілер үшін де, оқыту үшін де қажет)
GRE — GRE туннельдерін қолданатын қабаттас желі
VxLAN — VxLAN туннельдерін қолданатын қабаттас желі
Механизм драйверлері типті драйверде көрсетілген технологияларды ұйымдастыруды қамтамасыз ететін құралдарды анықтау - мысалы, openvswitch, sr-iov, opendaylight, OVN және т.б.
Осы драйверді іске асыруға байланысты, не Neutron басқаратын агенттер пайдаланылады немесе L2 желілерін ұйымдастыруға, маршруттауға және т.б. байланысты барлық мәселелерді шешетін сыртқы SDN контроллеріне қосылымдар пайдаланылады.
Мысал: егер біз ML2-ді OVS-мен бірге қолдансақ, онда OVS-ті басқаратын әрбір есептеу түйініне L2 агенті орнатылады. Алайда, мысалы, OVN немесе OpenDayLight пайдаланатын болсақ, онда OVS басқаруы олардың юрисдикциясына түседі - Neutron, түбірлік плагин арқылы контроллерге командалар береді және ол айтқанын жасайды.
Open vSwitch қолданбасын жаңартып көрейік
Қазіргі уақытта OpenStack негізгі құрамдастарының бірі Open vSwitch болып табылады.
Juniper Contrail немесе Nokia Nuage сияқты қосымша жеткізуші SDN жоқ OpenStack орнатқанда, OVS бұлтты желінің негізгі желілік құрамдас бөлігі болып табылады және iptables, conntrack, аттар кеңістігімен бірге толыққанды көп жалға беру желілерін ұйымдастыруға мүмкіндік береді. Әрине, бұл компонентті, мысалы, үшінші тараптың меншікті (өндіруші) SDN шешімдерін пайдаланған кезде ауыстыруға болады.
OVS – виртуалды трафик экспедиторы ретінде виртуалдандырылған орталарда пайдалануға арналған ашық бастапқы бағдарламалық құрал қосқышы.
Қазіргі уақытта OVS өте лайықты функционалдылыққа ие, оның ішінде QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK және т.б.
Ескертпе: OVS бастапқыда жоғары жүктелген телекоммуникациялық функцияларға арналған жұмсақ қосқыш ретінде ойластырылмаған және WEB сервері немесе пошта сервері сияқты өткізу қабілеттілігі азырақ талап етілетін АТ функцияларына арналған. Дегенмен, OVS одан әрі дамытылуда және OVS-тің ағымдағы енгізулері оның өнімділігі мен мүмкіндіктерін айтарлықтай жақсартты, бұл оны жоғары жүктелген функциялары бар байланыс операторларына пайдалануға мүмкіндік береді, мысалы, DPDK жеделдету қолдауымен OVS іске асыру бар.
Сіз білуіңіз керек OVS үш маңызды құрамдас бөлігі бар:
- Ядро модулі — басқару элементінен алынған ережелер негізінде трафикті өңдейтін ядро кеңістігінде орналасқан компонент;
- vSwitch демон (ovs-vswitchd) — ядро модулін бағдарламалауға жауап беретін пайдаланушы кеңістігінде іске қосылған процесс, яғни ол коммутатор жұмысының логикасын тікелей көрсетеді.
- Мәліметтер базасының сервері - конфигурация сақталатын OVS жұмыс істейтін әрбір хостта орналасқан жергілікті дерекқор. SDN контроллері осы модуль арқылы OVSDB протоколы арқылы байланыса алады.
Мұның бәрі диагностикалық және басқару утилиталарының жиынтығымен бірге жүреді, мысалы, ovs-vsctl, ovs-appctl, ovs-ofctl және т.б.
Қазіргі уақытта Openstack-ті байланыс операторлары оған EPC, SBC, HLR және т.б. сияқты желілік функцияларды көшіру үшін кеңінен қолданылады. Кейбір функциялар OVS-мен бұрынғыдай проблемаларсыз жұмыс істей алады, бірақ, мысалы, EPC абоненттік трафикті өңдейді - содан кейін ол арқылы өтеді. трафиктің үлкен көлемі (қазір трафик көлемі секундына бірнеше жүз гигабитке жетеді). Әрине, мұндай трафикті ядро кеңістігі арқылы жүргізу (өйткені экспедитор әдепкі бойынша сонда орналасқан) жақсы идея емес. Сондықтан OVS көбінесе ядроны айналып өтіп, трафикті NIC-тен пайдаланушы кеңістігіне бағыттау үшін DPDK жеделдету технологиясын пайдаланып толығымен пайдаланушы кеңістігінде орналастырылады.
Ескертпе: телекоммуникациялық функциялар үшін орналастырылған бұлт үшін OVS-ті айналып өтетін есептеу түйінінен трафикті коммутациялық жабдыққа шығаруға болады. Ол үшін SR-IOV және Passthrough механизмдері қолданылады.
Бұл нақты орналасуда қалай жұмыс істейді?
Ал, енді практикалық бөлікке өтіп, оның барлығы іс жүзінде қалай жұмыс істейтінін көрейік.
Алдымен қарапайым Openstack орнатуын қолданайық. Менде эксперименттер үшін серверлер жинағы болмағандықтан, біз прототипті виртуалды машиналардан бір физикалық серверге жинаймыз. Иә, әрине, мұндай шешім коммерциялық мақсаттарға жарамайды, бірақ Openstack-те желінің қалай жұмыс істейтінінің мысалын көру үшін мұндай орнату көзге жеткілікті. Сонымен қатар, мұндай қондырғы оқу мақсаттары үшін одан да қызықты - өйткені сіз трафикті ұстай аласыз және т.б.
Бізге тек негізгі бөлікті көру керек болғандықтан, біз бірнеше желіні пайдалана алмаймыз, бірақ барлығын тек екі желі арқылы көтереміз, ал осы орналасудағы екінші желі тек асты бұлт пен DNS серверіне кіру үшін пайдаланылады. Біз әзірге сыртқы желілерді қозғамаймыз - бұл бөлек үлкен мақаланың тақырыбы.
Сонымен, ретімен бастайық. Біріншіден, кішкене теория. Біз TripleO (Openstack on Openstack) көмегімен Openstack орнатамыз. TripleO мәні мынада: біз undercloud деп аталатын Openstack all-in-one бағдарламасын (яғни бір түйінге) орнатамыз, содан кейін overcloud деп аталатын операцияға арналған Openstack орнату үшін орналастырылған Openstack мүмкіндіктерін пайдаланамыз. Undercloud өзінің физикалық серверлерді (жалаңаш металл) басқару қабілетін - Ironic жобасын - есептеу, басқару, сақтау түйіндерінің рөлдерін орындайтын гипервизорларды қамтамасыз ету үшін пайдаланады. Яғни, біз Openstack-ті орналастыру үшін ешқандай үшінші тарап құралдарын пайдаланбаймыз - Openstack көмегімен Openstack-ті орналастырамыз. Орнату жүріп жатқанда бұл әлдеқайда анық болады, сондықтан біз мұнымен тоқтамай, алға жылжымаймыз.
Ескерту: Бұл мақалада қарапайымдылық үшін мен ішкі Openstack желілері үшін желілік оқшаулауды пайдаланған жоқпын, бірақ бәрі тек бір желі арқылы орналастырылған. Дегенмен, желілік оқшаулаудың болуы немесе болмауы шешімнің негізгі функционалдылығына әсер етпейді - бәрі оқшаулауды пайдаланған кездегідей жұмыс істейді, бірақ трафик бір желіде өтеді. Коммерциялық орнату үшін, әрине, әртүрлі вландар мен интерфейстерді пайдаланып оқшаулауды пайдалану қажет. Мысалы, ceph жадын басқару трафигі және деректер трафикінің өзі (дискілерге машиналық қатынас және т.б.) оқшауланған кезде әртүрлі ішкі желілерді (Сақтауды басқару және сақтау) пайдаланады және бұл, мысалы, осы трафикті бөлу арқылы шешімді ақауларға төзімді етуге мүмкіндік береді. , әртүрлі порттар арқылы немесе әртүрлі трафик үшін әртүрлі QoS профильдерін пайдалану, осылайша деректер трафигі сигналдық трафикті қыспауы үшін. Біздің жағдайда олар бір желіде жүреді және іс жүзінде бұл бізді ешқандай жолмен шектемейді.
Ескертпе: Виртуалды машиналарды виртуалды машиналарға негізделген виртуалды ортада іске қосатындықтан, алдымен кірістірілген виртуалдандыруды қосу керек.
Кірістірілген виртуализацияның қосылғанын немесе қосылмағанын келесідей тексеруге болады:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Егер сіз N әрпін көрсеңіз, біз желіде тапқан кез келген нұсқаулыққа сәйкес кірістірілген виртуализацияны қолдауды қосамыз, мысалы .
Виртуалды машиналардан келесі схеманы құрастыру керек:
Менің жағдайда, болашақ орнатудың бөлігі болып табылатын виртуалды машиналарды қосу үшін (және менде олардың 7-і бар, бірақ сізде көп ресурстар болмаса, 4-ке жетуге болады) мен OpenvSwitch-ті қолдандым. Мен бір ovs көпірін жасап, оған порт-топтар арқылы виртуалды машиналарды қостым. Мұны істеу үшін мен келесідей 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>Мұнда үш порт тобы жарияланған - екі кіру және бір магистральдық (соңғысы 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 портындағы мекенжай қолжетімді болмайды, себебі оның vlan тегі жоқ. Мұны түзету үшін sudo ovs-vsctl set port ovs-br1 тег=100 пәрменін беру керек. Дегенмен, қайта жүктегеннен кейін бұл тег жоғалады (егер біреу оны орнында қалдыруды білсе, мен өте ризамын). Бірақ бұл соншалықты маңызды емес, өйткені бізге бұл мекенжай орнату кезінде ғана қажет болады және Openstack толығымен орналастырылған кезде қажет болмайды.
Әрі қарай, біз бұлтты машинаны жасаймыз:
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 орнату үшін пайдаланыңыз.
Сәтті орнатудан кейін сізде астыртын бұлтты орнатуға болатын виртуалды машина болуы керек
[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
Бұлтты орнату
Біз стек пайдаланушысын жасаймыз, құпия сөз орнатамыз, оны sudoer-ге қосамыз және оған құпия сөзді енгізбей-ақ sudo арқылы түбірлік пәрмендерді орындау мүмкіндігін береміз:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackЕнді біз хосттар файлында бұлттың толық атауын көрсетеміз:
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 шығарылымын қолдандым, бірақ сіз өзіңізге ұнайтын кез келген басқа нұсқасын пайдалана аласыз.
Содан кейін бұлтты конфигурация файлын пайдаланушының үй каталогының стекіне көшіріңіз:
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 — бұлтты сервердің толық атауы, DNS серверіндегі жазбаға сәйкес келуі керек
local_ip — желіні қамтамасыз ету үшін жергілікті астыртын мекенжай
желілік_шлюз — бұлтты түйіндерді орнату кезінде сыртқы әлемге кіру шлюзі ретінде әрекет ететін бірдей жергілікті мекенжай жергілікті IP-мен сәйкес келеді.
undercloud_public_host — сыртқы API мекенжайы, қамтамасыз ету желісінен кез келген бос мекенжай тағайындалады
undercloud_admin_host ішкі API мекенжайы, қамтамасыз ету желісінен кез келген бос мекенжай тағайындалады
undercloud_nameservers - DNS сервері
жасау_қызметі_сертификат - бұл жол ағымдағы мысалда өте маңызды, өйткені егер сіз оны жалған деп орнатпасаңыз, орнату кезінде қате пайда болады, мәселе Red Hat қате бақылаушысында сипатталған.
жергілікті_интерфейс желіні қамтамасыз етудегі интерфейс. Бұл интерфейс асты бұлтты орналастыру кезінде қайта конфигурацияланады, сондықтан сізде астыртын бұлтта екі интерфейс болуы керек - біреуі оған қол жеткізу үшін, екіншісі қамтамасыз ету үшін
local_mtu - МТУ. Бізде сынақ зертханасы болғандықтан және менде OVS коммутатор порттарында 1500 MTU бар, сондықтан VxLAN-да инкапсуляцияланған пакеттер өтуі үшін оны 1450-ге орнату керек.
network_cidr — қамтамасыз ету желісі
маскарад — сыртқы желіге кіру үшін NAT пайдалану
маскарад_желі - NAT болатын желі
dhcp_start — бұлтты орналастыру кезінде түйіндерге мекенжайлар тағайындалатын мекенжай пулының бастапқы мекенжайы
dhcp_end — бұлтты орналастыру кезінде түйіндерге мекенжайлар тағайындалатын мекенжай пулының соңғы мекенжайы
inspection_iprange — интроспекцияға қажетті адрестер пулы (жоғарыда көрсетілген пулмен сәйкес келмеуі керек)
жоспарлаушы_макс_әрекеттері — бұлтты орнату әрекеттерінің максималды саны (түйіндер санынан көп немесе оған тең болуы керек)
Файл сипатталғаннан кейін астыртын бұлтты орналастыру пәрменін бере аласыз:
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.
#############################################################################Бұл шығыс астыртын бұлтты сәтті орнатқаныңызды айтады және енді астыртын бұлт күйін тексеріп, қосымша бұлтты орнатуды жалғастыра аласыз.
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Бұлтты орналастыру енді осы интерфейс арқылы жүзеге асырылады.
Төмендегі нәтижеден бізде барлық қызметтер бір түйінде бар екенін көруге болады:
(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) [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 ~]$Бұлтты орнату
Қазіргі уақытта бізде тек астыңғы бұлттылық бар, ал бізде бұлтты жинайтын түйіндер жеткіліксіз. Сондықтан, ең алдымен, бізге қажет виртуалды машиналарды орналастырайық. Орналастыру кезінде астыртын бұлттың өзі бұлтты компьютерге ОЖ-ны және қажетті бағдарламалық жасақтаманы орнатады - яғни біз машинаны толығымен орналастырудың қажеті жоқ, тек ол үшін дискіні (немесе дискілерді) жасап, оның параметрлерін анықтаймыз - яғни , шын мәнінде, бізде ОЖ орнатылмаған жалаң сервер аламыз.
Виртуалды машиналарымыздың дискілері бар қалтаға өтіп, қажетті өлшемдегі дискілерді жасайық:
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 пәрмені бар, ол /tmp/ қалтасындағы әрбір машинаның сипаттамасы бар xml файлын жасайды; егер сіз оны қоспасаңыз, сіз қосылмайсыз. виртуалды машиналарды анықтай алады.
Енді біз барлық осы машиналарды 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 қызметі арқылы жүзеге асырылады.
Бірақ мәселе мынада: аппараттық IPMI серверлерінде бөлек порт (немесе ортақ порт, бірақ бұл маңызды емес) болса, виртуалды машиналарда мұндай порттар болмайды. Мұнда 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 ~]#Менің ойымша, команда синтаксисі түсініктемесіз анық. Дегенмен, әзірге біздің барлық сеанстарымыз ТӨМЕН күйде. Олардың ЖОҒАРЫ күйіне өтуі үшін оларды қосу керек:
[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
Енді астыртын бұлтқа өтіп, бәрі жұмыс істеп тұрғанын тексерейік. Хост машинасының мекенжайы - 192.168.255.200, біз орналастыруға дайындық кезінде қажетті 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Көріп отырғаныңыздай, 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 ~]#Келесі қадам - бұлт орнатылатын түйіндердің интроспекциясы. Ол үшін түйіндеріміздің сипаттамасы бар 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"
}
]
}Енді біз ирониялық суреттерді дайындауымыз керек. Мұны істеу үшін оларды 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) [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 ~]$Шығарудан көріп отырғаныңыздай, барлығы қатесіз аяқталды. Барлық түйіндердің қолжетімді күйде екенін тексерейік:
(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 ~]$ Егер түйіндер басқа күйде болса, әдетте басқарылатын болса, онда бірдеңе дұрыс болмады және журналға қарап, бұл неліктен болғанын анықтау керек. Бұл сценарийде біз виртуализацияны қолданып жатқанымызды және виртуалды машиналарды немесе 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 ~]$Егер бәрі дұрыс болса, біз бұлтты орналастыру пәрменін береміз:
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 айнымалысы бұл жағдайда қажет, өйткені біз кірістірілген виртуализацияны қолданамыз. Әйтпесе, виртуалды машиналарды іске қоса алмайсыз.
Енді сізде шамамен бір сағат немесе одан да көп уақыт бар (аппараттық құралдардың мүмкіндіктеріне байланысты) және сіз осы уақыттан кейін келесі хабарламаны көресіз деп үміттенуге болады:
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 ~]$Енді сізде ашық стектің толыққанды нұсқасы бар, оны зерттеуге, тәжірибе жасауға және т.б.
Барлығы дұрыс жұмыс істеп тұрғанын тексерейік. Пайдаланушының үй каталогының стегінде екі файл бар - бір stackrc (асқынды бұлтты басқару үшін) және екінші overcloudrc (толық бұлтты басқару үшін). Бұл файлдар бастапқы ретінде көрсетілуі керек, өйткені оларда аутентификацияға қажетті ақпарат бар.
(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 ~]$Менің орнатуым әлі де бір кішкене түртуді қажет етеді - контроллерге маршрут қосу, өйткені мен жұмыс істейтін құрылғы басқа желіде. Ол үшін heat-admin тіркелгісі астындағы басқару-1 бөліміне өтіп, маршрутты тіркеңіз
(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 желісіндегі әртүрлі гипервизорлардағы екі машина
- Әр түрлі желілердегі екі машина (желіаралық түбірлеу)
Сыртқы әлемге сыртқы желі арқылы қол жеткізу, өзгермелі мекенжайларды пайдалану, сондай-ақ бөлінген маршруттау жағдайларын біз келесі жолы қарастырамыз, әзірге біз ішкі трафикке назар аударамыз.
Тексеру үшін келесі диаграмманы құрастырайық:
Біз 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) [стек@undercloud ~]$
vm-1 және vm-3 машиналары есептеу-0, vm-2 және vm-4 машиналары есептеу-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 ~]$ Бірақ трафиктің қалай жүретінін қарастырмас бұрын, басқару түйінінде (ол да желі түйіні болып табылады) және есептеу түйінінде қазіргі уақытта не бар екенін қарастырайық. Есептеу түйінінен бастайық.
[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 ~]$Қазіргі уақытта түйінде үш овс көпірі бар - br-int, br-tun, br-ex. Олардың арасында, біз көріп отырғанымыздай, интерфейстер жиынтығы бар. Түсінікті болу үшін осы интерфейстердің барлығын диаграммаға салып, не болатынын көрейік.
VxLAN туннельдері көтерілетін мекенжайларға қарап, бір туннель есептеу-1 (192.168.255.26), екінші туннель басқару-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 қоссаңыз, жағдай өзгереді, бірақ біз оны басқа жолы шешеміз. Желіні оқшаулауды пайдаланған кезде, мысалы, vlans пайдаланғанда, vlan 3 жүйесінде бір L0 интерфейсі емес, бірнеше интерфейстер болады. Дегенмен, VxLAN трафигі түйіннен дәл осылай шығады, бірақ сонымен бірге қандай да бір арнайы vlan түрінде инкапсуляцияланады.
Есептеу түйінін сұрыптадық, басқару түйініне көшейік.
[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 тегтері болмағандықтан, бұл порт барлық вландарға рұқсат етілген магистральдық порт болып табылады, енді трафик тегсіз сыртқа шығады, бұл влан-идентификатор 0 файлында көрсетілген. жоғарыдағы шығыс.
Қалғанының бәрі қазіргі уақытта есептеу түйініне ұқсас - бірдей көпірлер, екі есептеу түйініне баратын бірдей туннельдер.
Біз осы мақалада сақтау түйіндерін қарастырмаймыз, бірақ түсіну үшін бұл түйіндердің желілік бөлігі масқараға дейін банальды екенін айту керек. Біздің жағдайда IP мекенжайы тағайындалған бір ғана физикалық порт (eth0) бар және бұл. VxLAN туннельдері, туннель көпірлері және т.б. жоқ - овс мүлде жоқ, өйткені оның мағынасы жоқ. Желіні оқшаулауды пайдаланған кезде, бұл түйінде екі интерфейс болады (физикалық порттар, денелік немесе екі ғана влан - бұл маңызды емес - бұл сіздің қалауыңызға байланысты) - біреуі басқару үшін, екіншісі трафик үшін (VM дискісіне жазу) , дискіден оқу және т.б.)
Біз ешқандай қызметтер болмаған кезде түйіндерде не бар екенін анықтадық. Енді 4 виртуалды машинаны іске қосып, жоғарыда сипатталған схеманың қалай өзгеретінін көрейік - бізде порттар, виртуалды маршрутизаторлар және т.б. болуы керек.
Әзірге біздің желі келесідей көрінеді:
Бізде әрбір компьютер түйінінде екі виртуалды машина бар. Мысал ретінде есептеу-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 көпірінде көрінеді:
[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 - данаға тіркелген виртуалды интерфейс (VM)
qbr - Linux көпірі
qvb және qvo - Linux көпіріне және Open vSwitch көпіріне қосылған vEth жұбы
br-int, br-tun, br-vlan — vSwitch көпірлерін ашыңыз
patch-, int-br-, phy-br- - көпірлерді қосатын vSwitch патч интерфейстерін ашыңыз
qg, qr, ha, fg, sg - OVS жүйесіне қосылу үшін виртуалды құрылғылар пайдаланатын ашық vSwitch порттары
Түсінгеніңіздей, егер бізде vEth жұбы болып табылатын көпірде qvb95d96a75-a0 порты болса, онда бір жерде оның аналогы бар, оны логикалық түрде 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 порты шығыста көрінеді. Бұл екінші виртуалды машинаның порты. Нәтижесінде біздің диаграмма енді келесідей болады:
Мұқият оқырманды бірден қызықтыратын сұрақ – виртуалды машина порты мен OVS порты арасындағы Linux көпірі дегеніміз не? Мәселе мынада, машинаны қорғау үшін қауіпсіздік топтары пайдаланылады, олар 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 ~]$ Біз есептеу-0 жүйесінде br-int ішіндегі бағыттау кестесін қарастырамыз:
[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 ~]$Бұл 1-компьютердегі vxlan туннелі:
[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 ~]$Есептеу-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 ~]$ Mac компьютері 1-компьютердегі br-int бағыттау кестесінде және жоғарыдағы шығыстан көрініп тұрғандай, ол br-tun порты болып табылатын 2-порт арқылы көрінеді:
[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-те 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-портқа ұшады, оның артында виртуалды машина данасы-00000003 бар.
Виртуалды инфрақұрылымда оқуға арналған Openstack қолданудың әдемілігі мынада: біз гипервизорлар арасындағы трафикті оңай түсіріп, онымен не болып жатқанын көре аламыз. Міне, біз қазір істейміз, tcpdump бағдарламасын vnet портында есептеу-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 мекенжайынан Patek 10.0.1.88 (ICMP трафигі) мекенжайына баратынын және ол vni 22 бар VxLAN пакетіне оралғанын және пакет 192.168.255.19 (есептеу-0) хостынан 192.168.255.26 хостына өтетінін көрсетеді. .1 (есептеу-XNUMX). Біз VNI ovs ішінде көрсетілгенге сәйкес келетінін тексере аламыз.
Осы жолға оралайық actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 - он алтылық санау жүйесіндегі vni. Бұл санды 16-шы жүйеге ауыстырайық:
16 = 6*16^0+1*16^1 = 6+16 = 22Яғни vni шындыққа сәйкес келеді.
Екінші жолда кері трафик көрсетілген, жақсы, оны түсіндірудің қажеті жоқ, онда бәрі түсінікті.
Әр түрлі желілердегі екі машина (желіаралық маршруттау)
Бүгінгі күннің соңғы жағдайы - виртуалды маршрутизаторды пайдаланып бір жобадағы желілер арасында маршруттау. Біз DVR жоқ істі қарастырамыз (біз оны басқа мақалада қарастырамыз), сондықтан маршруттау желі түйінінде орын алады. Біздің жағдайда желі түйіні бөлек нысанға орналастырылмайды және басқару түйінінде орналасады.
Алдымен, маршруттау жұмыс істейтінін көрейік:
$ 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) fa:16:3e:c4:64:70 бар трафик қайда жіберілетінін көрейік:
[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 ~]$ Барлығы қисынды, трафик бр-тунға кетеді. Оның қай 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 ~]$ Басқару түйініне қарайтын:
[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 ~]$ Трафик басқару түйініне жетті, сондықтан біз оған барып, маршруттау қалай болатынын көруіміз керек.
Естеріңізде болса, ішіндегі басқару түйіні есептеу түйінімен бірдей көрінді - бірдей үш көпір, тек br-ex-те түйін сыртқы трафикті жібере алатын физикалық порты болды. Даналарды құру есептеу түйіндеріндегі конфигурацияны өзгертті - linux bridge, iptables және интерфейстер түйіндерге қосылды. Желілер мен виртуалды маршрутизаторды құру басқару түйінінің конфигурациясында да өз ізін қалдырды.
Сонымен, шлюз MAC мекенжайы басқару түйініндегі br-int бағыттау кестесінде болуы керек екені анық. Оның бар екенін және қайда қарап тұрғанын тексерейік:
[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 ~]$ Mac qr-0c52b15f-8f портынан көрінеді. Егер Openstack-тегі виртуалды порттар тізіміне оралсақ, бұл порт түрі әртүрлі виртуалды құрылғыларды OVS-ке қосу үшін қолданылады. Дәлірек айтсақ, qr виртуалды маршрутизатордың порты болып табылады, ол аттар кеңістігі ретінде ұсынылған.
Серверде қандай аттар кеңістігі бар екенін көрейік:
[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 ~]$ Үш данаға дейін. Бірақ атауларға қарап, олардың әрқайсысының мақсатын болжай аласыз. Біз 0 және 1 идентификаторы бар даналарға кейінірек ораламыз, енді бізді 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 ~]$ Бұл аттар кеңістігінде біз бұрын жасаған екі ішкі кеңістік бар. Екі виртуалды порт br-int-ке қосылды. qr-0c52b15f-8f портының Mac мекенжайын тексерейік, өйткені тағайындалған Mac мекенжайы бойынша трафик осы интерфейске өтті.
[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 туннелі арқылы есептеу түйініне өтуі керек:
[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 ~]$ Барлығы қисынды, тосынсыйлар жоқ. br-int ішінде 10.0.2.8 хостының көкнәр мекенжайы қай жерде көрінетінін көрейік:
[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 ~]$ Қозғалыс туннельге түседі-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 екенін көрейік, содан кейін біз түйіннің басқару портында қоқыс жинаймыз және трафиктің жоғарыда сипатталғандай өтуіне көз жеткіземіз.
Сонымен, есептеу-0 туннельінде келесі әрекеттер бар=жүктеу:0->NXM_OF_VLAN_TCI[],жүктеме:0x16->NXM_NX_TUN_ID[],шығару:3. 0x16 санын ондық санау жүйесіне ауыстырайық:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Есептеу-1 туннельінде келесі VNI бар: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],шығыс: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*******************Бірінші пакет - 192.168.255.19 хостынан (есептеу-0) vni 192.168.255.15 бар 1 (басқару-22) хостына арналған vxlan пакеті, оның ішінде ICMP пакеті 10.0.1.85 хостынан 10.0.2.8 хостына оралған. Жоғарыда есептегеніміздей, vni шығыста көргенімізге сәйкес келеді.
Екінші пакет - 192.168.255.15 (басқару-1) хостынан 192.168.255.26 (есептеу-1) үшін vni 99, оның ішінде ICMP пакеті 10.0.1.85 хостынан 10.0.2.8 хостына оралған vxlan пакеті. Жоғарыда есептегеніміздей, vni шығыста көргенімізге сәйкес келеді.
Келесі екі пакет 10.0.2.8 емес 10.0.1.85-тен қайтарылатын трафик.
Яғни, соңында біз келесі басқару түйінінің схемасын алдық:
Міне, солай ма? Біз екі атау кеңістігі туралы ұмытып кеттік:
[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 серверінен автоматты түрде алса жақсы болар еді. Бұл 10.0.1.0/24 және 10.0.2.0/24 екі желіге арналған екі DHCP сервері.
Мұның рас екенін тексерейік. Бұл аттар кеңістігінде бір ғана адрес бар - 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 бар процестер бар-жоғын көрейік:
[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 ~]$Нәтижесінде біз басқару түйінінде келесі қызметтер жинағын аламыз:
Есіңізде болсын - бұл бар болғаны 4 машина, 2 ішкі желі және бір виртуалды маршрутизатор... Бізде қазір сыртқы желілер жоқ, әрқайсысының өз желілері бар (қабаттасатын) әртүрлі жобалар тобы, және бізде бар. бөлінген маршрутизатор өшіп қалды, ақыр соңында сынақ стендінде бір ғана басқару түйіні болды (ақауларға төзімділік үшін үш түйіннен тұратын кворум болуы керек). Коммерцияда бәрі «кішкене» күрделірек екендігі қисынды, бірақ бұл қарапайым мысалда біз оның қалай жұмыс істеу керектігін түсінеміз - сізде 3 немесе 300 атау кеңістігі бар ма, әрине маңызды, бірақ бүкіл жүйенің жұмысы тұрғысынан құрылым, ештеңе өзгермейді... дегенмен сіз кейбір жеткізушінің SDN-ін қоспайсыз. Бірақ бұл мүлдем басқа әңгіме.
Қызықты болды деп үміттенемін. Егер сізде қандай да бір ескертулер/толықтырулар болса немесе мен өтірік айтқан жерім болса (мен адаммын және менің пікірім әрқашан субъективті болады) - түзету/қосу қажет нәрсені жазыңыз - біз бәрін түзетеміз/қосамыз.
Қорытындылай келе, мен Openstack-ті (ванильді де, сатушыны да) VMWare бұлттық шешімімен салыстыру туралы бірнеше сөз айтқым келеді - соңғы екі жылда маған бұл сұрақ жиі қойылды және шынымды айтсам, мен шаршадым, бірақ бәрібір. Менің ойымша, бұл екі шешімді салыстыру өте қиын, бірақ біз екі шешімнің де кемшіліктері бар және бір шешімді таңдаған кезде оң және теріс жақтарын таразылау керек деп нақты айта аламыз.
Егер OpenStack қоғамдастық басқаратын шешім болса, онда VMWare тек өз қалағанын жасауға құқылы (оқыңыз - ол үшін не тиімді) және бұл қисынды - өйткені бұл өз клиенттерінен ақша табуға дағдыланған коммерциялық компания. Бірақ бір үлкен және майлы БІРАҚ бар - сіз OpenStack-тен, мысалы, Nokia-дан шыға аласыз және аз шығынмен шешімге ауыса аласыз, мысалы, Juniper (Contrail Cloud), бірақ сіз VMWare-дан шыға алмайсыз. . Мен үшін бұл екі шешім келесідей көрінеді - Openstack (сатушы) - бұл қарапайым тор, онда сіз салынады, бірақ сізде кілт бар және сіз кез келген уақытта кете аласыз. VMWare - бұл алтын тор, иесінде тордың кілті бар және ол сізге қымбатқа түседі.
Мен бірінші өнімді де, екіншісін де жарнамалап жатқан жоқпын - өзіңізге қажет нәрсені өзіңіз таңдайсыз. Бірақ егер менде мұндай таңдау болса, мен екі шешімді де таңдар едім - IT бұлтына арналған VMWare (төмен жүктеме, оңай басқару), кейбір сатушыдан OpenStack (Nokia және Juniper өте жақсы кілтті шешімдерді ұсынады) - Telecom бұлты үшін. Мен таза IT үшін Openstack қолданбас едім - бұл торғайларды зеңбірекпен ату сияқты, бірақ мен оны пайдаланудың артықшылығынан басқа ешқандай қарсы көрсетілімдерін көрмеймін. Дегенмен, телекоммуникацияда VMWare пайдалану Ford Raptor көлігінде қиыршық тасты тасымалдаумен бірдей - бұл сыртынан әдемі, бірақ жүргізуші бір сапардың орнына 10 сапар жасауы керек.
Менің ойымша, VMWare-тің ең үлкен кемшілігі оның толық жабықтығы болып табылады - компания сізге оның қалай жұмыс істейтіні туралы ешқандай ақпарат бермейді, мысалы, vSAN немесе гипервизордың ядросында не бар - бұл жай ғана ол үшін тиімді емес - яғни сіз ешқашан VMWare-де сарапшы болмаңыз - жеткізушінің қолдауынсыз сіз жойылып кетесіз (мен VMWare сарапшыларымен жиі кездесетін болмашы сұрақтарға жауап беремін). Мен үшін VMWare капоты құлыпталған көлік сатып алуда - иә, сізде уақыт белдеуін ауыстыра алатын мамандар болуы мүмкін, бірақ капотты сізге осы шешімді сатқан адам ғана аша алады. Жеке өзіме сәйкес келмейтін шешімдерді ұнатпаймын. Сіз капоттың астына түсуге тура келмейтінін айтасыз. Иә, бұл мүмкін, бірақ мен сізге бұлтта 20-30 виртуалды машинадан, 40-50 желіден үлкен функцияны жинау керек болғанда қараймын, олардың жартысы сыртқа шыққысы келеді, ал екінші жартысы сұрайды. SR-IOV жеделдету, әйтпесе сізге бірнеше ондаған көлік қажет болады - әйтпесе өнімділік жеткіліксіз болады.
Басқа да көзқарастар бар, сондықтан сіз не таңдау керектігін шеше аласыз және ең бастысы, таңдауыңыз үшін жауапты боласыз. Бұл жай ғана менің пікірім - Nokia, Juniper, Red Hat және VMWare кем дегенде 4 өнімді көрген және қолмен ұстаған адам. Яғни, менің салыстыратын нәрсем бар.
Ақпарат көзі: www.habr.com