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