Рачунарство у облаку продире све дубље у наше животе и вероватно не постоји особа која бар једном није користила било који цлоуд сервис. Међутим, шта је тачно облак и како функционише, мало ко зна, чак и на нивоу идеје. 5Г већ постаје стварност и телеком инфраструктура почиње да се креће од полних решења до решења у облаку, баш као што је то било када је прешла са потпуно хардверских решења на виртуелизоване „стубове“.
Данас ћемо говорити о унутрашњем свету инфраструктуре облака, посебно ћемо погледати основе мрежног дела.
Шта је облак? Иста виртуелизација - преглед профила?
Више него логично питање. Не – ово није виртуелизација, иако се без ње не би могло. Погледајмо две дефиниције:
Рачунарство у облаку (у даљем тексту Цлоуд) је модел за пружање приступа прилагођеног кориснику дистрибуираним рачунарским ресурсима који се морају применити и покренути на захтев са најнижим могућим кашњењем и минималним трошковима за добављача услуга.
Виртуелизација - ово је могућност да се један физички ентитет (на пример, сервер) подели на неколико виртуелних, чиме се повећава искоришћеност ресурса (на пример, имали сте 3 сервера учитана на 25-30 процената, након виртуелизације добијате 1 учитан сервер на 80-90 одсто). Наравно, виртуелизација поједе неке од ресурса - морате хранити хипервизор, међутим, као што је пракса показала, игра вреди свеће. Идеалан пример виртуелизације је ВМВаре, који савршено припрема виртуелне машине, или на пример КВМ, што ја преферирам, али ово је ствар укуса.
Ми користимо виртуелизацију а да тога нисмо свесни, а чак и гвоздени рутери већ користе виртуелизацију – на пример, у најновијој верзији ЈунОС-а, оперативни систем је инсталиран као виртуелна машина на врху Линук дистрибуције у реалном времену (Винд Ривер 9). Али виртуелизација није облак, али облак не може постојати без виртуелизације.
Виртуелизација је један од грађевинских блокова на којима је изграђен облак.
Прављење облака једноставним сакупљањем неколико хипервизора у један Л2 домен, додавањем неколико иамл плаибоок-а за аутоматску регистрацију влан-ова кроз неку врсту Ансибле-а и стављањем нечег попут система оркестрације на њега за аутоматско креирање виртуелних машина неће радити. Биће тачније, али добијени Франкенштајн није облак који нам је потребан, иако може бити крајњи сан за друге. Штавише, ако узмете исти Опенстацк, то је у суштини и даље Франкенштајн, али добро, хајде да за сада не причамо о томе.
Али разумем да из горе представљене дефиниције није сасвим јасно шта се заправо може назвати облаком.
Дакле, документ НИСТ-а (Националног института за стандарде и технологију) пружа 5 главних карактеристика које инфраструктура облака треба да има:
Пружање услуге на захтев. Кориснику се мора омогућити слободан приступ рачунарским ресурсима који су му додељени (као што су мреже, виртуелни дискови, меморија, процесорска језгра итд.), а ти ресурси морају бити обезбеђени аутоматски – односно без интервенције провајдера сервиса.
Широка доступност услуге. Приступ ресурсима мора бити обезбеђен стандардним механизмима који омогућавају коришћење и стандардних рачунара и танких клијената и мобилних уређаја.
Комбиновање ресурса у групе. Групе ресурса морају бити у стању да обезбеде ресурсе за више клијената у исто време, обезбеђујући да су клијенти изоловани и ослобођени међусобног утицаја и конкуренције за ресурсе. Мреже су такође укључене у скупове, што указује на могућност коришћења преклапајућег адресирања. Базени морају бити у могућности да се повећавају на захтев. Коришћење скупова омогућава да се обезбеди неопходан ниво отпорности ресурса на грешке и апстраховање физичких и виртуелних ресурса – примаоцу услуге једноставно се обезбеђује скуп ресурса који је затражио (где се ти ресурси физички налазе, колико сервери и свичеви – није битно за клијента). Међутим, морамо узети у обзир чињеницу да провајдер мора да обезбеди транспарентну резервацију ових ресурса.
Брзо прилагођавање различитим условима. Услуге морају бити флексибилне – брзо обезбеђивање ресурса, њихова прерасподела, додавање или смањење ресурса на захтев клијента, а са стране клијента треба да постоји осећај да су ресурси у облаку бескрајни. Ради лакшег разумевања, на пример, не видите упозорење да је део вашег простора на диску у Аппле иЦлоуд-у нестао јер се чврсти диск на серверу покварио, а дискови се покварили. Поред тога, са ваше стране, могућности ове услуге су скоро неограничене - потребно вам је 2 ТБ - нема проблема, платили сте и добили. Сличан пример се може дати са Гоогле.Дриве или Иандек.Диск.
Могућност мерења пружене услуге. Системи у облаку морају аутоматски да контролишу и оптимизују потрошене ресурсе, а ови механизми морају бити транспарентни и за корисника и за добављача услуга. То јест, увек можете да проверите колико ресурса трошите ви и ваши клијенти.
Вреди узети у обзир чињеницу да су ови захтеви углавном захтеви за јавни облак, тако да се за приватни облак (тј. облак покренут за интерне потребе компаније) ови захтеви могу мало прилагодити. Међутим, они и даље морају да се ураде, иначе нећемо добити све предности рачунарства у облаку.
Зашто нам је потребан облак?
Међутим, свака нова или постојећа технологија, сваки нови протокол је створен за нешто (па, осим за РИП-нг, наравно). Протокол никоме није потребан ради протокола (па, осим РИП-нга, наравно). Логично је да је Цлоуд креиран да пружи неку врсту услуге кориснику/клијенту. Свима нам је познато барем неколико сервиса у облаку, на пример Дропбок или Гоогле.Доцс, и верујем да их већина људи успешно користи – на пример, овај чланак је написан помоћу услуге облака Гоогле.Доцс. Али услуге у облаку које познајемо само су део могућности облака – тачније, оне су само услуга типа СааС. Услугу у облаку можемо да обезбедимо на три начина: у облику СааС, ПааС или ИааС. Која вам је услуга потребна зависи од ваших жеља и могућности.
Погледајмо сваки редом:
Софтвер као услуга (СааС) је модел за пружање пуноправне услуге клијенту, на пример, услуга е-поште као што је Иандек.Маил или Гмаил. У овом моделу пружања услуга, ви, као клијент, заправо не радите ништа осим што користите услуге – то јест, не морате размишљати о постављању услуге, њеној толеранцији грешака или редундантности. Главна ствар је да не угрозите своју лозинку, провајдер ове услуге ће учинити остало за вас. Са становишта провајдера сервиса, он је у потпуности одговоран за целокупну услугу – од серверског хардвера и хост оперативних система до подешавања базе података и софтвера.
Платформа као услуга (ПааС) — када се користи овај модел, провајдер услуга обезбеђује клијенту радни комад за услугу, на пример, узмимо веб сервер. Добављач услуга је клијенту обезбедио виртуелни сервер (у ствари, скуп ресурса, као што су РАМ/ЦПУ/Стораге/Нетс, итд.), па чак и инсталирао ОС и потребан софтвер на овом серверу, међутим, конфигурација све ове ствари ради сам клијент, а за обављање услуге клијент одговара. Провајдер услуга је, као иу претходном случају, одговоран за перформансе физичке опреме, хипервизора, саме виртуелне машине, њене доступности мреже итд., али сама услуга више није у његовој зони одговорности.
Инфраструктура као услуга (ИааС) - овај приступ је већ интересантнији, у ствари, провајдер услуга пружа клијенту комплетну виртуелизовану инфраструктуру - односно неки скуп (пул) ресурса, као што су ЦПУ језгра, РАМ, мреже, итд. Све остало зависи од клијент – шта клијент жели да уради са овим ресурсима у оквиру додељене групе (квоте) – за добављача није посебно важно. Било да клијент жели да креира сопствени вЕПЦ или чак да креира мини оператера и пружа комуникационе услуге - нема сумње - уради то. У таквом сценарију, провајдер услуга је одговоран за обезбеђивање ресурса, њихову толеранцију грешака и доступност, као и оперативни систем који им омогућава да обједине ове ресурсе и учини их доступним клијенту са могућношћу повећања или смањења ресурса у било ком тренутку на захтев наручиоца. Клијент сам конфигурише све виртуелне машине и друге шљокице преко самоуслужног портала и конзоле, укључујући и подешавање мрежа (осим спољних мрежа).
Шта је ОпенСтацк?
У све три опције, провајдеру је потребан ОС који ће омогућити креирање клауд инфраструктуре. У ствари, код СааС-а, више од једног одељења је одговорно за читав низ технологија – постоји одељење које је одговорно за инфраструктуру – то јест, пружа ИааС другом одељењу, ова дивизија обезбеђује СааС клијенту. ОпенСтацк је један од оперативних система у облаку који вам омогућава да сакупите гомилу прекидача, сервера и система за складиштење у један скуп ресурса, поделите овај заједнички скуп на подпуле (станаре) и обезбедите ове ресурсе клијентима преко мреже.
ОпенСтацк је оперативни систем у облаку који вам омогућава да контролишете велике групе рачунарских ресурса, складиштења података и мрежних ресурса, који се обезбеђују и којима се управља преко АПИ-ја користећи стандардне механизме аутентификације.
Другим речима, ово је скуп пројеката бесплатног софтвера који је дизајниран да креира услуге у облаку (и јавне и приватне) - то јест, скуп алата који вам омогућавају да комбинујете сервер и опрему за пребацивање у један скуп ресурса, управљате ове ресурсе, обезбеђујући неопходан ниво толеранције грешака.
У време писања овог материјала, ОпенСтацк структура изгледа овако:
Слика преузета са
Свака од компоненти укључених у ОпенСтацк обавља одређену функцију. Ова дистрибуирана архитектура вам омогућава да у решење укључите скуп функционалних компоненти које су вам потребне. Међутим, неке компоненте су коренске компоненте и њихово уклањање ће довести до потпуне или делимичне неоперабилности решења у целини. Ове компоненте се обично класификују као:
- Kontrolna tabla — ГУИ заснован на вебу за управљање ОпенСтацк услугама
- главни принцип је централизовани сервис идентитета који обезбеђује функционалност аутентификације и ауторизације за друге услуге, као и управљање корисничким акредитивима и њиховим улогама.
- Неутрон - мрежни сервис који обезбеђује повезаност између интерфејса различитих ОпенСтацк сервиса (укључујући повезивање између ВМ-а и њихов приступ спољашњем свету)
- Циндер — пружа приступ блок меморији за виртуелне машине
- Нова — управљање животним циклусом виртуелних машина
- Поглед — спремиште слика и снимака виртуелне машине
- Брз — омогућава приступ објекту складиштења
- Цеилометер — услуга која пружа могућност прикупљања телеметрије и мерења расположивих и утрошених ресурса
- Топлота — оркестрација заснована на шаблонима за аутоматско креирање и обезбеђивање ресурса
Можете погледати комплетну листу свих пројеката и њихову намену .
Свака ОпенСтацк компонента је услуга која обавља одређену функцију и обезбеђује АПИ за управљање том функцијом и интеракцију са другим услугама оперативног система у облаку како би се створила обједињена инфраструктура. На пример, Нова обезбеђује управљање рачунарским ресурсима и АПИ за приступ конфигурисању ових ресурса, Гланце обезбеђује управљање сликама и АПИ за управљање њима, Циндер обезбеђује блок складиштење и АПИ за управљање, итд. Све функције су међусобно повезане на веома близак начин.
Међутим, ако погледате, све услуге које раде у ОпенСтацк-у су на крају нека врста виртуелне машине (или контејнера) повезане на мрежу. Поставља се питање – зашто нам треба толико елемената?
Хајде да прођемо кроз алгоритам за креирање виртуелне машине и њено повезивање на мрежу и трајно складиште у Опенстацк-у.
- Када креирате захтев за креирање машине, било да се ради о захтеву преко Хоризон-а (Дасхбоард) или захтеву преко ЦЛИ-а, прва ствар која се дешава је ауторизација вашег захтева на Кеистоне-у – можете ли да креирате машину, да ли она има право на коришћење ове мреже, да ли ваша квота за нацрт итд.
- Кеистоне аутентификује ваш захтев и генерише токен аутентификације у поруци одговора, који ће се даље користити. Након што је Кеистоне добио одговор, захтев се шаље према Новој (нова апи).
- Нова-апи проверава валидност вашег захтева тако што ће контактирати Кеистоне користећи претходно генерисани токен
- Кеистоне врши аутентификацију и пружа информације о дозволама и ограничењима на основу овог токена аутентификације.
- Нова-апи креира унос за нови ВМ у нова-датабасе и прослеђује захтев за креирање машине нова-сцхедулер-у.
- Нова-сцхедулер бира хост (рачунарски чвор) на коме ће ВМ бити распоређен на основу наведених параметара, тежина и зона. Запис о томе и ВМ ИД се уписују у нова-датабасе.
- Затим нова-сцхедулер контактира нова-цомпуте са захтевом да примени инстанцу. Нова-цомпуте контактира нова-цондуцтор да добије информације о параметрима машине (нова-цондуцтор је нова елемент који делује као проки сервер између нова-базе података и нова-цомпуте, ограничавајући број захтева за нова-базом података да би се избегли проблеми са базом података конзистентност смањење оптерећења).
- Нова-цондуцтор прима тражену информацију из нова-базе података и прослеђује је нова-цомпуте-у.
- Затим нова-цомпуте позива поглед да би добио ИД слике. Глаце потврђује захтев у Кеистоне-у и враћа тражене информације.
- Нова-цомпуте контактира неутрон да би добио информације о параметрима мреже. Слично као на први поглед, неутрон валидира захтев у Кеистоне-у, након чега креира унос у бази података (идентификатор порта, итд.), креира захтев за креирање порта и враћа тражене информације у нова-цомпуте.
- Нова-цомпуте контактира са захтевом да додели волумен виртуелној машини. Слично као на први поглед, јабуковача потврђује захтев у Кеистоне-у, креира захтев за креирање волумена и враћа тражене информације.
- Нова-цомпуте контактира либвирт са захтевом за примену виртуелне машине са наведеним параметрима.
У ствари, наизглед једноставна операција креирања једноставне виртуелне машине претвара се у такав вртлог АПИ позива између елемената клауд платформе. Штавише, као што видите, чак и претходно одређене услуге се такође састоје од мањих компоненти између којих долази до интеракције. Креирање машине је само мали део онога што вам клауд платформа омогућава – постоји услуга одговорна за балансирање саобраћаја, услуга одговорна за складиштење блокова, услуга одговорна за ДНС, услуга одговорна за обезбеђивање голих металних сервера итд. Облак вам омогућава да третирате своје виртуелне машине као стадо оваца (за разлику од виртуелизације). Ако се нешто деси вашој машини у виртуелном окружењу - враћате је из резервних копија итд., али апликације у облаку су направљене тако да виртуелна машина не игра тако важну улогу - виртуелна машина је "умрла" - нема проблема - тек је направљено ново возило је базирано на шаблону и, како кажу, одред није приметио губитак борца. Наравно, ово обезбеђује присуство механизама оркестрације - користећи Хеат шаблоне, лако можете применити сложену функцију која се састоји од десетина мрежа и виртуелних машина.
Увек је вредно имати на уму да нема инфраструктуре облака без мреже – сваки елемент на овај или онај начин комуницира са другим елементима кроз мрежу. Поред тога, облак има апсолутно нестатичну мрежу. Наравно, мрежа испод је чак мање-више статична – нови чворови и прекидачи се не додају сваки дан, али компонента преклапања може и неизбежно ће се стално мењати – нове мреже ће се додавати или брисати, нове виртуелне машине ће се појавити и старе ће се умрети. И као што се сећате из дефиниције облака дате на самом почетку чланка, ресурсе треба доделити кориснику аутоматски и уз најмању (или још боље, без) интервенције провајдера услуге. Односно, врста пружања мрежних ресурса која сада постоји у виду фронт-енда у виду вашег личног налога доступног преко хттп/хттпс и дежурног мрежног инжењера Василија као бацкенда није облак, чак ни ако Василиј има осам руку.
Неутрон, као мрежни сервис, обезбеђује АПИ за управљање мрежним делом инфраструктуре облака. Услуга покреће и управља мрежним делом Опенстацк-а тако што обезбеђује слој апстракције који се зове Мрежа као услуга (НааС). То јест, мрежа је иста виртуелна мерљива јединица као, на пример, виртуелна ЦПУ језгра или количина РАМ-а.
Али пре него што пређемо на архитектуру мрежног дела ОпенСтацк-а, хајде да размотримо како ова мрежа функционише у ОпенСтацк-у и зашто је мрежа важан и саставни део облака.
Дакле, имамо две РЕД клијент ВМ и две ЗЕЛЕНЕ клијентске ВМ. Претпоставимо да се ове машине налазе на два хипервизора на овај начин:
Тренутно је ово само виртуелизација 4 сервера и ништа више, пошто смо до сада урадили само виртуелизацију 4 сервера, постављајући их на два физичка сервера. А до сада нису ни повезани на мрежу.
Да бисмо направили облак, морамо додати неколико компоненти. Прво, виртуелизујемо мрежни део – треба да повежемо ове 4 машине у пару, а клијенти желе Л2 везу. Можете користити прекидач и конфигурисати трунк у његовом правцу и све решити користећи линук бридге или, за напредније кориснике, опенвсвитцх (на ово ћемо се вратити касније). Али може бити много мрежа, а стално гурање Л2 кроз прекидач није најбоља идеја – постоје различита одељења, сервисни деск, месеци чекања да се апликација заврши, недеље решавања проблема – у савременом свету ово приступ више не функционише. И што пре компанија ово схвати, лакше јој је да иде напред. Стога ћемо између хипервизора изабрати Л3 мрежу преко које ће наше виртуелне машине комуницирати, а на врху ове Л3 мреже изградићемо виртуелне Л2 преклапајуће мреже где ће се одвијати саобраћај наших виртуелних машина. Можете користити ГРЕ, Геневе или ВкЛАН као енкапсулацију. Хајде да се за сада фокусирамо на ово друго, иако то није посебно важно.
Морамо негде да лоцирамо ВТЕП (надам се да су сви упознати са ВкЛАН терминологијом). Пошто имамо Л3 мрежу која долази директно са сервера, ништа нас не спречава да поставимо ВТЕП на саме сервере, а ОВС (ОпенвСвитцх) је одличан у томе. Као резултат, добили смо овај дизајн:
Пошто саобраћај између ВМ-ова мора бити подељен, портови ка виртуелним машинама ће имати различите бројеве влан-а. Број ознаке игра улогу само унутар једног виртуелног прекидача, пошто када је инкапсулиран у ВкЛАН можемо га лако уклонити, пошто ћемо имати ВНИ.
Сада можемо да креирамо наше машине и виртуелне мреже за њих без икаквих проблема.
Међутим, шта ако клијент има другу машину, али је на другој мрежи? Треба нам рутовање између мрежа. Погледаћемо једноставну опцију када се користи централизовано рутирање – то јест, саобраћај се усмерава кроз посебне наменске мрежне чворове (добро, по правилу се комбинују са контролним чворовима, тако да ћемо имати исту ствар).
Чини се да ништа није компликовано – правимо бридге интерфејс на контролном чвору, возимо саобраћај до њега и одатле га усмеравамо тамо где нам треба. Али проблем је у томе што РЕД клијент жели да користи мрежу 10.0.0.0/24, а ГРЕЕН клијент жели да користи мрежу 10.0.0.0/24. То јест, почињемо да пресецамо адресне просторе. Поред тога, клијенти не желе да други клијенти могу да рутирају у њихове интерне мреже, што има смисла. Да бисмо раздвојили мреже и клијентски саобраћај података, доделићемо посебан простор имена за сваку од њих. Именски простор је у ствари копија Линук мрежног стека, то јест, клијенти у именском простору РЕД су потпуно изоловани од клијената из именског простора ЗЕЛЕНИ (па, или је рутирање између ових клијентских мрежа дозвољено кроз подразумевани именски простор или на узводној транспортној опреми).
То јест, добијамо следећи дијаграм:
Л2 тунели конвергирају од свих рачунарских чворова до контролног чвора. чвор где се налази Л3 интерфејс за ове мреже, свака у наменском именском простору за изолацију.
Међутим, заборавили смо оно најважније. Виртуелна машина мора да пружи услугу клијенту, односно да има најмање један екстерни интерфејс преко којег се може доћи до ње. Односно, треба да изађемо у спољашњи свет. Овде постоје различите опције. Хајде да урадимо најједноставнију опцију. Сваком клијенту ћемо додати једну мрежу, која ће важити у мрежи провајдера и неће се преклапати са другим мрежама. Мреже се такође могу укрштати и гледати различите ВРФ-ове на страни мреже провајдера. Мрежни подаци ће такође живети у именском простору сваког клијента. Међутим, они ће и даље излазити у спољашњи свет преко једног физичког (или везе, што је логичније) интерфејса. Да би се раздвојио клијентски саобраћај, саобраћај који иде ван биће означен ВЛАН ознаком додељеном клијенту.
Као резултат, добили смо овај дијаграм:
Разумно питање је зашто не направити пролазе на самим рачунарским чворовима? Ово није велики проблем; штавише, ако укључите дистрибуирани рутер (ДВР), ово ће радити. У овом сценарију, разматрамо најједноставнију опцију са централизованим пролазом, који се подразумевано користи у Опенстацк-у. За функције високог оптерећења користиће и дистрибуирани рутер и технологије убрзања као што су СР-ИОВ и Пасстхроугх, али како кажу, то је сасвим друга прича. Прво, хајде да се позабавимо основним делом, а затим ћемо прећи на детаље.
Заправо, наша шема је већ изводљива, али постоји неколико нијанси:
- Морамо некако заштитити наше машине, односно поставити филтер на интерфејс прекидача према клијенту.
- Омогућите виртуелној машини да аутоматски добије ИП адресу, тако да не морате сваки пут да се пријављујете на њу преко конзоле и региструјете адресу.
Почнимо са заштитом машине. За ово можете користити баналне иптаблес, зашто не.
То јест, сада је наша топологија постала мало компликованија:
Идемо даље. Морамо да додамо ДХЦП сервер. Најидеалније место за лоцирање ДХЦП сервера за сваког клијента би био контролни чвор који је већ поменут изнад, где се налазе простори имена:
Међутим, постоји мали проблем. Шта ако се све поново покрене и све информације о изнајмљивању адреса на ДХЦП-у нестану. Логично је да ће машине добити нове адресе, што није баш згодно. Овде постоје два излаза - или користите имена домена и додајте ДНС сервер за сваког клијента, тада нам адреса неће бити посебно важна (слично мрежном делу у к8с) - али постоји проблем са спољним мрежама, јер адресе се у њима могу издати и преко ДХЦП-а - потребна вам је синхронизација са ДНС серверима у клауд платформи и екстерним ДНС сервером, што по мом мишљењу није много флексибилно, али је сасвим могуће. Или друга опција је да користите метаподатке – то јест, сачувате информације о адреси која је издата машини тако да ДХЦП сервер зна коју адресу да изда машини ако је машина већ примила адресу. Друга опција је једноставнија и флексибилнија, јер вам омогућава да сачувате додатне информације о аутомобилу. Сада додајмо метаподатке агента у дијаграм:
Још једно питање о коме такође вреди разговарати је могућност коришћења једне екстерне мреже од стране свих клијената, пошто ће екстерне мреже, ако морају да важе у целој мрежи, бити тешка – потребно је стално алоцирати и контролисати алокацију ових мрежа. Могућност коришћења једне екстерне унапред конфигурисане мреже за све клијенте биће веома корисна приликом креирања јавног облака. Ово ће олакшати примену машина јер не морамо да консултујемо базу података адреса и бирамо јединствени адресни простор за спољну мрежу сваког клијента. Поред тога, можемо унапред да региструјемо спољну мрежу иу тренутку постављања требаћемо само да повежемо спољне адресе са клијентским машинама.
И ту нам НАТ долази у помоћ – само ћемо омогућити клијентима да приступе спољашњем свету преко подразумеваног простора имена користећи НАТ превод. Па, ево малог проблема. Ово је добро ако клијент сервер делује као клијент, а не као сервер – то јест, покреће, а не прихвата везе. Али за нас ће бити обрнуто. У овом случају, потребно је да урадимо одредишни НАТ тако да приликом пријема саобраћаја контролни чвор разуме да је овај саобраћај намењен виртуелној машини А клијента А, што значи да треба да урадимо НАТ превод са спољне адресе, на пример 100.1.1.1 .10.0.0.1, на интерну адресу 100. У овом случају, иако ће сви клијенти користити исту мрежу, интерна изолација је потпуно очувана. То јест, треба да урадимо дНАТ и сНАТ на контролном чвору. Да ли ћете користити једну мрежу са плутајућим адресама или спољне мреже, или обоје одједном, зависи од тога шта желите да унесете у облак. Нећемо додавати плутајуће адресе дијаграму, али ћемо оставити екстерне мреже које су већ додате раније – сваки клијент има своју спољну мрежу (на дијаграму су означене као влан 200 и XNUMX на спољном интерфејсу).
Као резултат тога, добили смо занимљиво и истовремено добро осмишљено решење, које има одређену флексибилност, али још увек нема механизме толеранције грешака.
Прво, имамо само један контролни чвор - његов квар ће довести до колапса свих система. Да бисте решили овај проблем, потребно је да направите кворум од најмање 3 чвора. Додајмо ово дијаграму:
Наравно, сви чворови су синхронизовани и када активни чвор напусти, други чвор ће преузети његове одговорности.
Следећи проблем су дискови виртуелне машине. Тренутно се чувају на самим хипервизорима, а у случају проблема са хипервизором губимо све податке - а присуство рације овде неће помоћи ако изгубимо не диск, већ цео сервер. Да бисмо то урадили, морамо да направимо сервис који ће деловати као предњи крај за неку врсту складишта. Каква ће то бити складиште није нам посебно важно, али би требало да заштити наше податке од квара и диска и чвора, а можда и целог кабинета. Овде постоји неколико опција - постоје, наравно, САН мреже са Фибре Цханнел-ом, али будимо искрени - ФЦ је већ реликт прошлости - аналог Е1 у транспорту - да, слажем се, још увек се користи, али само тамо где је без тога апсолутно немогуће. Стога, не бих добровољно поставио ФЦ мрежу 2020. године, знајући да постоје друге интересантније алтернативе. Иако сваком своје, можда има оних који верују да је ФК са свим својим ограничењима све што нам треба - нећу се расправљати, свако има своје мишљење. Ипак, најзанимљивије рјешење по мом мишљењу је кориштење СДС-а, као што је Цепх.
Цепх вам омогућава да направите високо доступно решење за складиштење података са гомилом могућих резервних опција, почевши од кодова са провером паритета (аналогно раид 5 или 6) до потпуног репликације података на различите дискове, узимајући у обзир локацију дискова у сервери, и сервери у кабинетима итд.
Да бисте направили Цепх, потребна су вам још 3 чвора. Интеракција са складиштем ће се такође вршити преко мреже коришћењем сервиса за складиштење блокова, објеката и датотека. Хајде да додамо складиште у шему:
Напомена: такође можете направити хиперконвергиране рачунарске чворове – ово је концепт комбиновања неколико функција на једном чвору – на пример, складиштење+рачунање – без издвајања посебних чворова за цепх складиште. Добићемо исту шему отпорну на грешке - пошто ће СДС резервисати податке са нивоом резервације који одредимо. Међутим, хиперконвергентни чворови су увек компромис – пошто чвор за складиштење не загрева само ваздух како се чини на први поглед (пошто на њему нема виртуелних машина) – он троши ЦПУ ресурсе на сервисирање СДС-а (у ствари, он ради све репликација и опоравак након кварова чворова, дискова, итд.). То јест, изгубићете део снаге рачунарског чвора ако га комбинујете са складиштем.
Свим овим стварима треба некако управљати – потребно нам је нешто преко чега можемо да креирамо машину, мрежу, виртуелни рутер, итд. Да бисмо то урадили, контролном чвору ћемо додати сервис који ће деловати као контролна табла – клијент ће моћи да се повеже на овај портал преко хттп/ хттпс и уради све што му је потребно (па, скоро).
Као резултат тога, сада имамо систем отпоран на грешке. Свим елементима ове инфраструктуре се мора некако управљати. Раније је описано да је Опенстацк скуп пројеката, од којих сваки пружа одређену функцију. Као што видимо, има више него довољно елемената које треба конфигурисати и контролисати. Данас ћемо причати о мрежном делу.
Неутронска архитектура
У ОпенСтацк-у, Неутрон је тај који је одговоран за повезивање портова виртуелне машине са заједничком Л2 мрежом, обезбеђујући рутирање саобраћаја између ВМ-ова који се налазе на различитим Л2 мрежама, као и спољно рутирање, пружајући услуге као што су НАТ, Флоатинг ИП, ДХЦП, итд.
На високом нивоу, рад мрежног сервиса (основни део) може се описати на следећи начин.
Приликом покретања ВМ-а, мрежни сервис:
- Креира порт за дати ВМ (или портове) и обавештава ДХЦП сервис о томе;
- Креиран је нови виртуелни мрежни уређај (преко либвирт-а);
- ВМ се повезује на порт(ове) креиране у кораку 1;
Чудно је да је Неутронов рад заснован на стандардним механизмима познатим свима који су икада заронили у Линукс - простори имена, иптаблес, линук мостови, опенвсвитцх, цоннтрацк, итд.
Одмах треба разјаснити да Неутрон није СДН контролер.
Неутрон се састоји од неколико међусобно повезаних компоненти:
Опенстацк-неутрон-сервер је демон који ради са захтевима корисника преко АПИ-ја. Овај демон није укључен у регистровање било каквих мрежних веза, али пружа неопходне информације за то својим додацима, који затим конфигуришу жељени мрежни елемент. Неутронски агенти на ОпенСтацк чворовима се региструју на Неутрон серверу.
Неутрон-сервер је заправо апликација написана на питону, која се састоји од два дела:
- РЕСТ сервице
- Неутрон додатак (језгро/услуга)
РЕСТ услуга је дизајнирана да прима АПИ позиве од других компоненти (на пример, захтев за пружање неких информација, итд.)
Додаци су софтверске компоненте/модули додатака који се позивају током АПИ захтева – то јест, атрибуција услуге се дешава преко њих. Додаци су подељени у два типа - сервисни и роот. По правилу, коњски додатак је углавном одговоран за управљање адресним простором и Л2 везама између ВМ-а, а сервисни додаци већ пружају додатну функционалност као што су ВПН или ФВ.
Списак додатака доступних данас може се видети на пример
Може постојати неколико сервисних додатака, али може постојати само један коњски додатак.
опенстацк-неутрон-мл2 је стандардни Опенстацк роот додатак. Овај додатак има модуларну архитектуру (за разлику од свог претходника) и конфигурише мрежну услугу преко драјвера повезаних на њега. Погледаћемо сам додатак мало касније, пошто он у ствари даје флексибилност коју ОпенСтацк има у мрежном делу. Основни додатак се може заменити (на пример, Цонтраил Нетворкинг ради такву замену).
РПЦ услуга (раббитмк-сервер) — услуга која обезбеђује управљање редовима и интеракцију са другим ОпенСтацк сервисима, као и интеракцију између агената мрежних услуга.
Мрежни агенти — агенти који се налазе у сваком чвору, преко којих се конфигуришу мрежни сервиси.
Постоји неколико врста агената.
Главни агент је Л2 агент. Ови агенти се покрећу на сваком од хипервизора, укључујући контролне чворове (тачније, на свим чворовима који пружају било коју услугу за станаре) и њихова главна функција је да повежу виртуелне машине на заједничку Л2 мрежу, а такође генеришу упозорења када дође до било каквих догађаја ( на пример онемогућити/омогућити порт).
Следећи, ништа мање важан агент је Л3 агент. Подразумевано, овај агент ради искључиво на мрежном чвору (често је мрежни чвор комбинован са контролним чвором) и обезбеђује рутирање између мрежа закупаца (и између својих мрежа и мрежа других закупаца, и доступан је спољном свету, обезбеђујући НАТ, као и ДХЦП сервис). Међутим, када се користи ДВР (дистрибуирани рутер), потреба за Л3 додатком се појављује и на рачунарским чворовима.
Л3 агент користи Линук именске просторе да сваком закупцу обезбеди скуп сопствених изолованих мрежа и функционалност виртуелних рутера који усмеравају саобраћај и обезбеђују услуге пролаза за мреже слоја 2.
База података — база података идентификатора мрежа, подмрежа, портова, скупова итд.
У ствари, Неутрон прихвата АПИ захтеве од креирања било ког мрежног ентитета, аутентификује захтев и преко РПЦ (ако приступа неком додатку или агенту) или РЕСТ АПИ (ако комуницира у СДН) преноси агентима (преко додатака) упутства неопходна за организовање тражене услуге.
Сада се окренемо пробној инсталацији (како се поставља и шта је у њој укључено, видећемо касније у практичном делу) и видимо где се свака компонента налази:
(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 ~]$
У ствари, то је цела структура Неутрона. Сада је вредно потрошити неко време на додатак МЛ2.
Модуларни слој 2
Као што је горе поменуто, додатак је стандардни ОпенСтацк роот додатак и има модуларну архитектуру.
Претходник МЛ2 додатка имао је монолитну структуру, што није дозвољавало, на пример, коришћење мешавине неколико технологија у једној инсталацији. На пример, не можете истовремено да користите и опенвсвитцх и линукбридге - ни први ни други. Из тог разлога је креиран додатак МЛ2 са својом архитектуром.
МЛ2 има две компоненте - две врсте драјвера: драјвере типа и драјвере механизма.
Тип драјвери одредити технологије које ће се користити за организовање мрежних веза, на пример ВкЛАН, ВЛАН, ГРЕ. Истовремено, возач дозвољава употребу различитих технологија. Стандардна технологија је ВкЛАН инкапсулација за мреже са преклапањем и екстерне влан мреже.
Тип драјвера укључује следеће типове мреже:
Раван - мрежа без означавања
ВЛАН - означена мрежа
Lokalna — посебан тип мреже за све-у-једном инсталације (такве инсталације су потребне или за програмере или за обуку)
ГРЕ — преклапање мреже помоћу ГРЕ тунела
ВкЛАН — преклапање мреже користећи ВкЛАН тунеле
Возачи механизма дефинишу алате који обезбеђују организацију технологија наведених у драјверу типа – на пример, опенвсвитцх, ср-иов, опендаилигхт, ОВН итд.
У зависности од имплементације овог драјвера, користиће се или агенти које контролише Неутрон, или ће се користити везе са екстерним СДН контролером, који брине о свим питањима у вези са организовањем Л2 мрежа, рутирањем итд.
Пример: ако користимо МЛ2 заједно са ОВС-ом, онда је Л2 агент инсталиран на сваком рачунарском чвору који управља ОВС-ом. Међутим, ако користимо, на пример, ОВН или ОпенДаиЛигхт, онда контрола ОВС-а долази у њихову надлежност – Неутрон преко роот додатка даје команде контролеру, а он већ ради оно што му је речено.
Хајде да освежимо Опен вСвитцх
У овом тренутку, једна од кључних компоненти ОпенСтацк-а је Опен вСвитцх.
Када инсталирате ОпенСтацк без икаквог додатног добављача СДН-а као што је Јунипер Цонтраил или Нокиа Нуаге, ОВС је главна мрежна компонента клауд мреже и, заједно са иптаблес, цоннтрацк, именским просторима, омогућава вам да организујете пуноправне мреже са више закупаца. Наравно, ова компонента се може заменити, на пример, када се користе СДН решења треће стране (вендора).
ОВС је софтверски прекидач отвореног кода који је дизајниран за употребу у виртуелизованим окружењима као виртуелни прослеђивач саобраћаја.
У овом тренутку, ОВС има веома пристојну функционалност, која укључује технологије као што су КоС, ЛАЦП, ВЛАН, ВкЛАН, ГЕНЕВЕ, ОпенФлов, ДПДК итд.
Напомена: ОВС није првобитно замишљен као меки прекидач за високо оптерећене телеком функције и више је дизајниран за мање захтевне ИТ функције као што су ВЕБ сервер или сервер поште. Међутим, ОВС се даље развија и тренутне имплементације ОВС-а су у великој мери побољшале његове перформансе и могућности, што омогућава да га користе телеком оператери са високо оптерећеним функцијама, на пример, постоји имплементација ОВС-а са подршком за ДПДК убрзање.
Постоје три важне компоненте ОВС-а којих треба да будете свесни:
- Кернел модул — компонента која се налази у простору кернела која обрађује саобраћај на основу правила примљених од контролног елемента;
- вСвитцх даемон (овс-всвитцхд) је процес покренут у корисничком простору који је одговоран за програмирање модула кернела – односно директно представља логику рада прекидача
- Сервер базе података - локалну базу података која се налази на сваком хосту који ради ОВС, у којој се чува конфигурација. СДН контролери могу да комуницирају преко овог модула користећи ОВСДБ протокол.
Све ово је праћено скупом дијагностичких и управљачких услужних програма, као што су овс-всцтл, овс-аппцтл, овс-офцтл, итд.
Тренутно, Опенстацк широко користе телеком оператери за миграцију мрежних функција на њега, као што су ЕПЦ, СБЦ, ХЛР, итд. Неке функције могу да живе без проблема са ОВС-ом какав јесте, али на пример, ЕПЦ обрађује претплатнички саобраћај - онда пролази кроз огромна количина саобраћаја (сада обим саобраћаја достиже неколико стотина гигабита у секунди). Наравно, вожња таквог саобраћаја кроз простор кернела (пошто се прослеђивач подразумевано налази тамо) није најбоља идеја. Због тога се ОВС често поставља у потпуности у корисничком простору користећи ДПДК технологију убрзања за прослеђивање саобраћаја са НИЦ-а на кориснички простор заобилазећи језгро.
Напомена: за облак распоређен за телекомуникационе функције, могуће је емитовати саобраћај из рачунарског чвора заобилазећи ОВС директно на комутаторску опрему. У ту сврху се користе механизми СР-ИОВ и Пасстхроугх.
Како ово функционише на стварном распореду?
Е, сад да пређемо на практични део и да видимо како то све функционише у пракси.
Прво, хајде да применимо једноставну Опенстацк инсталацију. Пошто немам при руци сет сервера за експерименте, саставићемо прототип на једном физичком серверу са виртуелних машина. Да, наравно, такво решење није погодно за комерцијалне сврхе, али да видите пример како мрежа функционише у Опенстацк-у, таква инсталација је довољна за очи. Штавише, таква инсталација је још интересантнија за потребе обуке - пошто можете ухватити саобраћај итд.
Пошто треба да видимо само основни део, не можемо да користимо неколико мрежа већ да све подигнемо користећи само две мреже, а друга мрежа у овом распореду ће се користити искључиво за приступ ундерцлоуд-у и ДНС серверу. За сада се нећемо дотицати спољних мрежа - ово је тема за посебан велики чланак.
Дакле, почнимо редом. Прво, мало теорије. Инсталираћемо Опенстацк користећи ТриплеО (Опенстацк на Опенстацк-у). Суштина ТриплеО-а је да инсталирамо Опенстацк све-у-једном (то јест, на једном чвору), који се зове ундерцлоуд, а затим користимо могућности распоређеног Опенстацк-а за инсталирање Опенстацк-а намењеног за рад, који се зове оверцлоуд. Ундерцлоуд ће користити своју инхерентну способност управљања физичким серверима (голи метал) - пројекат Ирониц - да обезбеди хипервизоре који ће обављати улоге рачунарских, контролних и складишних чворова. То јест, ми не користимо никакве алате треће стране за примену Опенстацк-а - ми примењујемо Опенстацк користећи Опенстацк. Биће много јасније како инсталација буде напредовала, тако да се нећемо зауставити на томе и кренути напред.
Напомена: У овом чланку, ради једноставности, нисам користио мрежну изолацију за интерне Опенстацк мреже, већ се све поставља користећи само једну мрежу. Међутим, присуство или одсуство мрежне изолације не утиче на основну функционалност решења – све ће радити потпуно исто као и када се користи изолација, али ће саобраћај тећи на истој мрежи. За комерцијалну инсталацију, природно је неопходно користити изолацију користећи различите влан-ове и интерфејсе. На пример, цепх саобраћај за управљање складиштем и сам промет података (приступ машине дисковима, итд.) када су изоловани користе различите подмреже (управљање складиштем и складиштење) и то вам омогућава да решење учините отпорнијим на грешке тако што ћете поделити овај саобраћај, нпр. , преко различитих портова, или користећи различите КоС профиле за различит саобраћај тако да саобраћај података не истискује сигнални саобраћај. У нашем случају, они ће ићи на исту мрежу и то нас заправо ни на који начин не ограничава.
Напомена: Пошто ћемо покретати виртуелне машине у виртуелном окружењу заснованом на виртуелним машинама, прво треба да омогућимо угнежђену виртуелизацију.
Можете да проверите да ли је угнежђена виртуелизација омогућена или не овако:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Ако видите слово Н, онда омогућавамо подршку за угнежђену виртуелизацију према било ком водичу који нађете на мрежи, нпр. .
Морамо да саставимо следеће коло из виртуелних машина:
У мом случају, да бих повезао виртуелне машине које су део будуће инсталације (а добио сам их 7, али можете да прођете са 4 ако немате пуно ресурса), користио сам ОпенвСвитцх. Направио сам један овс мост и повезао виртуелне машине на њега преко порт-група. Да бих то урадио, направио сам кмл датотеку овако:
[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>Овде су декларисане три групе портова - два приступа и један транк (потоњи је био потребан за ДНС сервер, али можете и без њега, или га инсталирати на хост машину - шта вам више одговара). Затим, користећи овај шаблон, проглашавамо наш путем вирсх нет-дефине:
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 ~]# Напомена: у овом сценарију адреса на порту овс-бр1 неће бити доступна јер нема влан ознаку. Да бисте ово поправили, потребно је да издате команду судо овс-всцтл сет порт овс-бр1 таг=100. Међутим, након поновног покретања, ова ознака ће нестати (ако неко зна како да остане на месту, бићу веома захвалан). Али ово није толико важно, јер ће нам ова адреса бити потребна само током инсталације и неће нам требати када се Опенстацк у потпуности примени.
Затим креирамо машину у облаку:
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Током инсталације подесите све потребне параметре, као што су назив машине, лозинке, корисници, нтп сервери итд., можете одмах да конфигуришете портове, али мени лично је после инсталације лакше да се пријавите на машину преко конзолу и исправите потребне датотеке. Ако већ имате готову слику, можете је користити или урадити оно што сам ја урадио - преузмите минималну слику Центос 7 и користите је за инсталирање ВМ-а.
Након успешне инсталације, требало би да имате виртуелну машину на коју можете да инсталирате ундерцлоуд
[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
Ундерцлоуд инсталација
Креирамо корисника стека, постављамо лозинку, додајемо је судоер-у и дајемо му могућност да извршава роот команде преко судо без потребе за уносом лозинке:
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Напомена: ако не планирате да инсталирате цепх, онда не морате да уносите команде везане за цепх. Користио сам издање Куеенс, али можете користити било које друго које желите.
Затим копирајте конфигурациону датотеку ундерцлоуд у стек кућног директоријума корисника:
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Дакле, идемо кроз подешавања:
ундерцлоуд_хостнаме — пуно име сервера у облаку мора да одговара уносу на ДНС серверу
лоцал_ип — локална ундерцлоуд адреса у правцу обезбеђивања мреже
нетворк_гатеваи — иста локална адреса, која ће служити као капија за приступ спољашњем свету током инсталације оверцлоуд чворова, такође се поклапа са локалним ИП-ом
ундерцлоуд_публиц_хост — екстерна АПИ адреса, додељује се свака слободна адреса из мреже за обезбеђивање
ундерцлоуд_админ_хост интерна АПИ адреса, додељује се свака слободна адреса из мреже за обезбеђивање
ундерцлоуд_намесерверс - ДНС сервер
генерате_сервице_цертифицате - ова линија је веома важна у тренутном примеру, јер ако је не поставите на фалсе добићете грешку током инсталације, проблем је описан на Ред Хат праћењу грешака
локални_интерфејс интерфејс у мрежном обезбеђивању. Овај интерфејс ће бити поново конфигурисан током постављања у подклауду, тако да морате да имате два интерфејса на ундерцлоуд-у - један за приступ, други за обезбеђивање
лоцал_мту — МТУ. Пошто имамо лабораторију за тестирање и имам МТУ од 1500 на портовима ОВС свитцх-а, потребно је да га подесим на 1450 како би пакети инкапсулирани у ВкЛАН могли да пролазе
нетворк_цидр — мреже за обезбеђивање
маскуераде — коришћењем НАТ-а за приступ спољној мрежи
маскуераде_нетворк - мрежа која ће бити НАТ
дхцп_старт — почетна адреса скупа адреса са које ће адресе бити додељене чворовима током примене прекомерног облака
дхцп_енд — коначну адресу скупа адреса са које ће адресе бити додељене чворовима током примене прекомерног облака
инспецтион_ипранге — скуп адреса неопходних за интроспекцију (не би требало да се преклапа са горњим скупом)
сцхедулер_мак_аттемптс — максималан број покушаја инсталирања оверцлоуда (мора бити већи или једнак броју чворова)
Након што је датотека описана, можете дати команду за примену ундерцлоуд-а:
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.
#############################################################################Овај излаз каже да сте успешно инсталирали ундерцлоуд и да сада можете проверити статус ундерцлоуд-а и наставити са инсталирањем оверцлоуд-а.
Ако погледате ифцонфиг излаз, видећете да се појавио нови интерфејс за мост
[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]# Напомена: ако не планирате да инсталирате цепх да бисте га проучавали, онда команде не креирају најмање 3 чвора са најмање два диска, већ у шаблону означавају да ће се користити виртуелни дискови вда, вдб итд.
Одлично, сада морамо да дефинишемо све ове машине:
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 На крају се налази команда -принт-кмл > /тмп/стораге-1.кмл, која креира кмл датотеку са описом сваке машине у фасцикли /тмп/; ако је не додате, нећете бити у стању да идентификује виртуелне машине.
Сада морамо да дефинишемо све ове машине у вирсх-у:
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 ~]#Сада мала нијанса - триплеО користи ИПМИ за управљање серверима током инсталације и интроспекције.
Интроспекција је процес инспекције хардвера како би се добили његови параметри неопходни за даље обезбеђивање чворова. Интроспекција се спроводи помоћу ирониц, услуге дизајниране за рад са голим металним серверима.
Али ево проблема - док хардверски ИПМИ сервери имају посебан порт (или заједнички порт, али то није важно), виртуелне машине немају такве портове. Овде нам у помоћ долази штака под називом вбмц – услужни програм који вам омогућава да емулирате ИПМИ порт. На ову нијансу вреди обратити пажњу посебно за оне који желе да поставе такву лабораторију на ЕСКСИ хипервизору - да будем искрен, не знам да ли има аналог вбмц-а, тако да је вредно запитати се о овом питању пре него што све примените .
Инсталирај вбмц:
yum install yum install python2-virtualbmcАко ваш ОС не може да пронађе пакет, додајте спремиште:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmСада постављамо услужни програм. Овде је све банално до срамоте. Сада је логично да нема сервера на листи вбмц
[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, на ундерцлоуд-у смо додали неопходан ипмитоол пакет током припреме за имплементацију:
[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Као што видите, успешно смо покренули контролни чвор преко вбмц-а. Сада га искључимо и наставимо:
[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 ~]#Следећи корак је интроспекција чворова на којима ће оверцлоуд бити инсталиран. Да бисмо то урадили, потребно је да припремимо јсон датотеку са описом наших чворова. Имајте на уму да, за разлику од инсталације на голим серверима, датотека означава порт на којем вбмц ради за сваку машину.
[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Напомена: контролни чвор има два интерфејса, али у овом случају то није важно, у овој инсталацији ће нам један бити довољан.
Сада припремамо јсон датотеку. Морамо да наведемо мак адресу порта преко којег ће се вршити обезбеђивање, параметре чворова, да им дамо имена и назначимо како да дођемо до ипми-а:
{
"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"
}
]
}Сада треба да припремимо слике за иронију. Да бисте то урадили, преузмите их преко вгет-а и инсталирајте:
(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 ~]$Још једна ствар - потребно је да додате ДНС сервер:
(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 ~]$ Ако су чворови у другом стању, којим се обично може управљати, онда је нешто пошло наопако и морате погледати дневник и схватити зашто се то догодило. Имајте на уму да у овом сценарију користимо виртуелизацију и да може доћи до грешака повезаних са употребом виртуелних машина или вбмц-а.
Затим треба да назначимо који ће чвор обављати коју функцију - то јест, назначити профил са којим ће се чвор распоредити:
(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У правој инсталацији, природно ће се користити прилагођени шаблони, у нашем случају ће то увелико закомпликовати процес, јер ће свака измена у шаблону морати да буде објашњена. Као што је раније написано, чак и једноставна инсталација биће нам довољна да видимо како функционише.
Напомена: променљива --либвирт-типе кему је неопходна у овом случају, пошто ћемо користити угнежђену виртуелизацију. У супротном, нећете моћи да покрећете виртуелне машине.
Сада имате око сат времена, или можда више (у зависности од могућности хардвера) и можете само да се надате да ћете након овог времена видети следећу поруку:
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 ~]$Сада имате скоро пуну верзију опенстацк-а, на којој можете учити, експериментисати итд.
Хајде да проверимо да ли све ради како треба. У стеку кућног директоријума корисника налазе се две датотеке - једна стацкрц (за управљање ундерцлоуд) и друга оверцлоудрц (за управљање оверцлоуд). Ове датотеке морају бити наведене као извор, пошто садрже информације неопходне за аутентификацију.
(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 ~]$Моја инсталација и даље захтева један мали додир - додавање руте на контролеру, пошто је машина са којом радим на другој мрежи. Да бисте то урадили, идите на цонтрол-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Па, сада можете ићи на хоризонт. Све информације - адресе, логин и лозинка - налазе се у датотеци /хоме/стацк/оверцлоудрц. Коначни дијаграм изгледа овако:
Иначе, у нашој инсталацији, адресе машина су издате преко ДХЦП-а и, као што видите, издају се „насумично“. Можете стриктно дефинисати у шаблону која адреса треба да буде прикачена којој машини током примене, ако вам је потребна.
Како се саобраћај одвија између виртуелних машина?
У овом чланку ћемо погледати три опције за пропуштање саобраћаја
- Две машине на једном хипервизору на једној Л2 мрежи
- Две машине на различитим хипервизорима на истој Л2 мрежи
- Две машине на различитим мрежама (роот на више мрежа)
Случајеве са приступом спољашњем свету преко екстерне мреже, коришћењем плутајућих адреса, као и дистрибуираног рутирања, размотрићемо следећи пут, за сада ћемо се фокусирати на унутрашњи саобраћај.
Да бисмо проверили, саставимо следећи дијаграм:
Направили смо 4 виртуелне машине - 3 на једној Л2 мрежи - нет-1, и још 1 на нет-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 |
(оверцлоуд) [стацк@ундерцлоуд ~]$
Машине вм-1 и вм-3 се налазе на цомпуте-0, машине вм-2 и вм-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 ~]$У овом тренутку чвор има три овс моста - бр-инт, бр-тун, бр-ек. Између њих, као што видимо, постоји скуп интерфејса. Ради лакшег разумевања, хајде да нацртамо све ове интерфејсе на дијаграму и видимо шта се дешава.
Гледајући адресе до којих су подигнути ВкЛАН тунели, може се видети да је један тунел подигнут на цомпуте-1 (192.168.255.26), други тунел гледа на цонтрол-1 (192.168.255.15). Али најзанимљивије је то што бр-ек нема физичке интерфејсе, а ако погледате који су токови конфигурисани, можете видети да овај мост тренутно може само да смањи саобраћај.
[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 ~]$
Према првом правилу, све што је дошло из фи-бр-екс луке мора да се одбаци.
Заправо, тренутно више нема где да долази саобраћај на овај мост осим са овог интерфејса (интерфејса са бр-инт), а судећи по падовима, БУМ саобраћај је већ прелетео на мост.
То јест, саобраћај може напустити овај чвор само кроз ВкЛАН тунел и ништа више. Међутим, ако укључите ДВР, ситуација ће се променити, али ћемо се тиме позабавити неком другом приликом. Када користите мрежну изолацију, на пример користећи вланс, нећете имати један Л3 интерфејс у влану 0, већ неколико интерфејса. Међутим, ВкЛАН саобраћај ће напустити чвор на исти начин, али такође инкапсулиран у неку врсту наменског влан-а.
Средили смо рачунарски чвор, пређимо на контролни чвор.
[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 ~]$У ствари, можемо рећи да је све исто, али ИП адреса више није на физичком интерфејсу већ на виртуелном мосту. Ово се ради зато што је ова лука лука кроз коју ће саобраћај излазити у спољни свет.
[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 ~]$ Овај порт је везан за бр-ек мост и пошто на њему нема влан тагова, овај порт је трунк порт на коме су дозвољени сви влан-ови, сада саобраћај иде ван без ознаке, као што је назначено влан-ид 0 у излаз изнад.
Све остало је тренутно слично рачунарском чвору - исти мостови, исти тунели који иду до два рачунарска чвора.
У овом чланку нећемо разматрати чворове за складиштење, али за разумевање потребно је рећи да је мрежни део ових чворова баналан до срамоте. У нашем случају постоји само један физички порт (етх0) са ИП адресом која му је додељена и то је то. Нема ВкЛАН тунела, тунелских мостова итд - нема овс уопште, пошто нема смисла у томе. Када користите мрежну изолацију, овај чвор ће имати два интерфејса (физички портови, бодни или само два влан-а - није важно - зависи шта желите) - један за управљање, други за саобраћај (записивање на ВМ диск , читање са диска, итд.)
Схватили смо шта имамо на чворовима у одсуству било каквих услуга. Хајде сада да покренемо 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 ~]$ Машина има само један виртуелни интерфејс - тап95д96а75-а0:
[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 ~]$ 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 ~]$ Као што видите из излаза, у мосту постоје само два интерфејса - тап95д96а75-а0 и квб95д96а75-а0.
Овде се вреди мало задржати на типовима виртуелних мрежних уређаја у ОпенСтацк-у:
втап - виртуелни интерфејс повезан са инстанцом (ВМ)
кбр - Линук мост
квб и кво - вЕтх пар повезан са Линук мостом и Опен вСвитцх мостом
бр-инт, бр-тун, бр-влан — Отворите вСвитцх мостове
патцх-, инт-бр-, пхи-бр- - Отворени вСвитцх интерфејси закрпе који повезују мостове
кг, кр, ха, фг, сг - Отворите вСвитцх портове које користе виртуелни уређаји за повезивање са ОВС-ом
Као што разумете, ако имамо квб95д96а75-а0 порт у мосту, који је вЕтх пар, онда негде постоји његов пандан, који би логично требало да се зове кво95д96а75-а0. Да видимо који су портови на ОВС-у.
[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 ~]$ Као што видимо, порт је у бр-инт. Бр-инт делује као прекидач који завршава портове виртуелне машине. Поред кво95д96а75-а0, порт кво5бд37136-47 је видљив у излазу. Ово је порт за другу виртуелну машину. Као резултат, наш дијаграм сада изгледа овако:
Питање које би одмах требало да заинтересује пажљивог читаоца - шта је линукс мост између порта виртуелне машине и ОВС порта? Чињеница је да се за заштиту машине користе безбедносне групе, које нису ништа друго до иптаблес. ОВС не ради са иптаблесом, тако да је ова „штака“ измишљена. Међутим, он постаје застарео - замењује га цоннтрацк у новим издањима.
То јест, на крају шема изгледа овако:
Две машине на једном хипервизору на једној Л2 мрежи
Пошто се ова два ВМ-а налазе на истој Л2 мрежи и на истом хипервизору, саобраћај између њих ће логично тећи локално кроз бр-инт, пошто ће обе машине бити на истом ВЛАН-у:
[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 ~]$ Две машине на различитим хипервизорима на истој Л2 мрежи
Сада да видимо како ће се саобраћај одвијати између две машине на истој Л2 мрежи, али се налазе на различитим хипервизорима. Да будем искрен, ништа се неће много променити, само ће саобраћај између хипервизора ићи кроз вклан тунел. Погледајмо пример.
Адресе виртуелних машина између којих ћемо пратити саобраћај:
[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:
[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 ~]$Ово је патцх-тун - то јест, интерфејс у бр-тун. Да видимо шта се дешава са пакетом на бр-тун:
[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 ~]$ Пакет се пакује у ВкЛАН и шаље на порт 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:
[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 ~]$ Мац се налази у бр-инт табели прослеђивања на цомпуте-1, и као што се може видети из излаза изнад, видљив је кроз порт 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Па, онда видимо да у бр-инт на цомпуте-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.
Лепота примене Опенстацк-а за учење на виртуелној инфраструктури је у томе што лако можемо да ухватимо саобраћај између хипервизора и видимо шта се са њим дешава. Ево шта ћемо сада урадити, покрените тцпдумп на внет порту према цомпуте-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Први ред показује да Патек са адресе 10.0.1.85 иде на адресу 10.0.1.88 (ИЦМП саобраћај), и да је умотан у ВкЛАН пакет са вни 22 и пакет иде са хоста 192.168.255.19 (цомпуте-0) на хост 192.168.255.26 .1 (рачунај-XNUMX). Можемо проверити да ли се ВНИ подудара са оним наведеним у овс.
Вратимо се на ову линију ацтионс=лоад:0->НКСМ_ОФ_ВЛАН_ТЦИ[],лоад:0к16->НКСМ_НКС_ТУН_ИД[],оутпут:2. 0к16 је вни у хексадецималном бројевном систему. Претворимо овај број у 16. систем:
16 = 6*16^0+1*16^1 = 6+16 = 22То јест, вни одговара стварности.
Други ред показује повратни саобраћај, па, нема сврхе објашњавати, ту је све јасно.
Две машине на различитим мрежама (међумрежно рутирање)
Последњи случај за данас је рутирање између мрежа у оквиру једног пројекта помоћу виртуелног рутера. Разматрамо случај без ДВР-а (погледаћемо то у другом чланку), тако да се рутирање дешава на мрежном чвору. У нашем случају, мрежни чвор није смештен у посебан ентитет и налази се на контролном чвору.
Прво, да видимо да рутирање функционише:
$ 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
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) фа:16:3е:ц4: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 ~]$ Све је логично, саобраћај иде на бр-тун. Хајде да видимо у који вклан тунел ће бити умотан:
[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 ~]$ Трећи порт је вклан тунел:
[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 ~]$ Саобраћај је стигао до контролног чвора, тако да треба да одемо до њега и видимо како ће се рутирање одвијати.
Као што се сећате, контролни чвор изнутра је изгледао потпуно исто као и рачунарски чвор - иста три моста, само бр-ек је имао физички порт кроз који је чвор могао да шаље саобраћај напоље. Креирање инстанци је променило конфигурацију на рачунарским чворовима - линук бридге, иптаблес и интерфејси су додати чворовима. Креирање мрежа и виртуелног рутера такође је оставило трага на конфигурацији контролног чвора.
Дакле, очигледно је да МАЦ адреса мрежног пролаза мора бити у бр-инт табели прослеђивања на контролном чвору. Хајде да проверимо да ли је ту и где гледа:
[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 ~]$ Мац је видљив са порта кр-0ц52б15ф-8ф. Ако се вратимо на листу виртуелних портова у Опенстацк-у, овај тип порта се користи за повезивање различитих виртуелних уређаја на ОВС. Да будемо прецизнији, кр је порт за виртуелни рутер, који је представљен као именски простор.
Хајде да видимо који су именски простори на серверу:
[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, сада нас занима простор имена кроутер-0а4д2420-4б9ц-46бд-аец1-86а1еф299абе:
[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 ~]$ Овај именски простор садржи два интерна која смо креирали раније. Оба виртуелна порта су додата у бр-инт. Хајде да проверимо мац адресу порта кр-0ц52б15ф-8ф, пошто је саобраћај, судећи по одредишној мац адреси, ишао на овај интерфејс.
[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, он мора изаћи кроз други интерфејс кр-92фа49б5-54 и проћи кроз вклан тунел до рачунарског чвора:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ Све је логично, нема изненађења. Да видимо где је у бр-инту видљива мак адреса хоста 10.0.2.8:
[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 ~]$ Саобраћај, очекивано, иде ка бр-тун, да видимо у који тунел ће саобраћај даље:
[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. Па, на цомпуте-1 све је једноставно - од бр-тун пакет иде у бр-инт и одатле у интерфејс виртуелне машине:
[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 ~]$
У ствари, прошли смо до краја кроз пакет. Мислим да сте приметили да је саобраћај пролазио кроз различите вклан тунеле и излазио са различитим ВНИ-овима. Хајде да видимо каква су то ВНИ, након чега ћемо прикупити думп на контролном порту чвора и уверити се да саобраћај тече тачно како је горе описано.
Дакле, тунел за израчунавање-0 има следеће акције=учитавање:0->НКСМ_ОФ_ВЛАН_ТЦИ[],учитавање:0к16->НКСМ_НКС_ТУН_ИД[],излаз:3. Хајде да претворимо 0к16 у децимални бројни систем:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Тунел за цомпуте-1 има следеће ВНИ:ацтионс=лоад:0->НКСМ_ОФ_ВЛАН_ТЦИ[],лоад:0к63->НКСМ_НКС_ТУН_ИД[],оутпут:2. Хајде да претворимо 0к63 у децимални бројни систем:
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) до хоста 192.168.255.15 (цонтрол-1) са вни 22, унутар којег је ИЦМП пакет упакован од хоста 10.0.1.85 до хоста 10.0.2.8. Као што смо израчунали изнад, вни одговара ономе што смо видели у излазу.
Други пакет је вклан пакет од хоста 192.168.255.15 (цонтрол-1) до хоста 192.168.255.26 (цомпуте-1) са вни 99, унутар којег је ИЦМП пакет упакован од хоста 10.0.1.85 до хоста 10.0.2.8. Као што смо израчунали изнад, вни одговара ономе што смо видели у излазу.
Следећа два пакета су повратни саобраћај од 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 ~]$ Како смо причали о архитектури клауд платформе, било би добро када би машине примале адресе аутоматски са ДХЦП сервера. Ово су два ДХЦП сервера за наше две мреже 10.0.1.0/24 и 10.0.2.0/24.
Хајде да проверимо да ли је ово тачно. У овом именском простору постоји само једна адреса - 10.0.1.1 - адреса самог ДХЦП сервера, а такође је укључена у бр-инт:
[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Хајде да видимо да ли процеси који садрже кдхцп-67а3798ц-32ц0-4ц18-8502-2531247е3цц2 у свом имену на контролном чвору:
[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 именских простора је наравно важно, али са становишта рада целог структура, ништа се неће много променити... мада док не прикључите СДН неког добављача. Али то је сасвим друга прича.
Надам се да је било занимљиво. Ако имате било какве коментаре/допуне, или негде сам потпуно лагао (ја сам човек и моје мишљење ће увек бити субјективно) - напишите шта треба исправити/додати - све ћемо исправити/додати.
У закључку, желео бих да кажем неколико речи о поређењу Опенстацк-а (и ваниле и добављача) са ВМВаре решењем у облаку – ово питање су ми постављали пречесто у последњих неколико година и, искрено говорећи, ја сам већ уморан од тога, али ипак. По мом мишљењу, веома је тешко упоредити ова два решења, али са сигурношћу можемо рећи да постоје недостаци у оба решења и када бирате једно решење потребно је одмерити предности и недостатке.
Ако је ОпенСтацк решење које покреће заједница, онда ВМВаре има право да ради само оно што жели (читај – шта му је исплативо) и то је логично – јер је то комерцијална компанија која је навикла да зарађује од својих клијената. Али постоји једно велико и дебело АЛИ - можете да се ослободите ОпенСтацк-а, на пример од Нокије, и да уз мало трошкова пређете на решење са, на пример, Јунипер-а (Цонтраил Цлоуд), али је мало вероватно да ћете моћи да напустите ВМВаре . За мене ова два решења изгледају овако – Опенстацк (вендор) је једноставан кавез у који сте стављени, али имате кључ и можете отићи у било ком тренутку. ВМВаре је златни кавез, власник има кључ од кавеза и то ће вас много коштати.
Не промовишем ни први ни други производ - ви бирајте шта вам треба. Али да имам такав избор, изабрао бих оба решења – ВМВаре за ИТ облак (мало оптерећење, лако управљање), ОпенСтацк од неког добављача (Нокиа и Јунипер пружају веома добра решења „кључ у руке“) – за Телеком облак. Не бих користио Опенстацк за чист ИТ - то је као да гађате врапце из топа, али не видим никакве контраиндикације за његово коришћење осим редундантности. Међутим, коришћење ВМВаре-а у телекомуникацијама је као течење дробљеног камена у Форд Раптор-у - прелепо је споља, али возач мора да направи 10 путовања уместо једног.
По мом мишљењу, највећи недостатак ВМВаре-а је његова потпуна затвореност – компанија вам неће дати никакве информације о томе како ради, на пример, вСАН или шта је у кернелу хипервизора – то једноставно није исплативо за њега – то јест, ви ћете никада не постаните стручњак за ВМВаре – без подршке добављача, осуђени сте на пропаст (веома често срећем ВМВаре стручњаке који су збуњени тривијалним питањима). За мене ВМВаре купује аутомобил са закључаном хаубом - да, можда имате специјалисте који могу да промене зупчасти каиш, али само онај ко вам је продао ово решење може да отвори хаубу. Лично, не волим решења у која не могу да се уклопим. Рећи ћете да можда нећете морати да идете испод хаубе. Да, ово је могуће, али погледаћу вас када треба да саставите велику функцију у облаку од 20-30 виртуелних машина, 40-50 мрежа, од којих половина жели да изађе напоље, а друга половина тражи СР-ИОВ убрзање, иначе ће вам требати још неколико десетина ових аутомобила - иначе перформансе неће бити довољне.
Постоје и друге тачке гледишта, тако да само ви можете одлучити шта ћете изабрати и, што је најважније, тада ћете бити одговорни за свој избор. Ово је само моје мишљење - особа која је видела и додирнула најмање 4 производа - Нокиа, Јунипер, Ред Хат и ВМВаре. Односно, имам са чиме да упоредим.
Извор: ввв.хабр.цом