Cloud computing навлегува се подлабоко и подлабоко во нашите животи и веројатно нема ниту еден човек кој барем еднаш не користел ниту една облак услуга. Меѓутоа, што точно е облак и како функционира, малку луѓе знаат, дури и на ниво на идеја. 5G веќе станува реалност и телекомуникациската инфраструктура почнува да се движи од решенија на пол кон решенија за облак, исто како што се пресели од целосно хардверски решенија на виртуелизирани „столбови“.
Денес ќе зборуваме за внатрешниот свет на облак инфраструктурата, особено ќе ги разгледаме основите на мрежниот дел.
Што е облак? Истата виртуелизација - поглед на профилот?
Повеќе од логично прашање. Не - ова не е виртуелизација, иако не можеше да се направи без него. Ајде да погледнеме две дефиниции:
Cloud computing (во понатамошниот текст Облак) е модел за обезбедување лесен пристап до дистрибуирани компјутерски ресурси кои мора да се распоредат и стартуваат на барање со најниска можна латентност и минимални трошоци за давателот на услугата.
Виртуелизација - ова е способност да се подели еден физички ентитет (на пример, сервер) на неколку виртуелни, со што се зголемува искористеноста на ресурсите (на пример, имавте 3 сервери вчитани на 25-30 проценти, по виртуелизацијата добивате вчитан 1 сервер на 80-90 проценти). Секако, виртуелизацијата јаде дел од ресурсите - треба да го нахраните хипервизорот, сепак, како што покажа практиката, играта вреди за свеќата. Идеален пример за виртуелизација е VMWare кој одлично подготвува виртуелни машини или на пример KVM кој јас го преферирам, но ова е прашање на вкус.
Ние користиме виртуелизација без да го сфатиме тоа, па дури и железните рутери веќе користат виртуелизација - на пример, во најновата верзија на JunOS, оперативниот систем е инсталиран како виртуелна машина на врвот на дистрибуција на Linux во реално време (Wind River 9). Но, виртуелизацијата не е облак, но облакот не може да постои без виртуелизација.
Виртуелизацијата е еден од градежните блокови на кои е изграден облакот.
Создавањето облак со едноставно собирање на неколку хипервизори во еден L2 домен, додавање на неколку yaml плејбук за автоматско регистрирање vlan преку некој вид ансибил и заглавување нешто како систем за оркестрација на сето тоа за автоматско создавање виртуелни машини нема да работи. Ќе биде попрецизно, но добиениот Франкенштајн не е облакот што ни треба, иако можеби е крајниот сон за другите. Згора на тоа, ако го земете истиот Openstack, тоа во суштина е сепак Франкенштајн, но о, добро, да не зборуваме за тоа сега за сега.
Но, јас разбирам дека од дефиницијата претставена погоре не е сосема јасно што всушност може да се нарече облак.
Затоа, документ од NIST (Национален институт за стандарди и технологија) дава 5 главни карактеристики што треба да ги има облак инфраструктурата:
Обезбедување услуга по барање. На корисникот мора да му се даде бесплатен пристап до компјутерските ресурси кои му се доделени (како што се мрежи, виртуелни дискови, меморија, процесорски јадра итн.), а овие ресурси мора да се обезбедат автоматски - односно без интервенција од давателот на услугата.
Широка достапност на услугата. Пристапот до ресурсите мора да биде овозможен со стандардни механизми за да се овозможи користење и на стандардни компјутери и на тенки клиенти и на мобилни уреди.
Комбинирање ресурси во базени. Ресурсните базени мора да бидат способни да обезбедуваат ресурси на повеќе клиенти во исто време, осигурувајќи дека клиентите се изолирани и ослободени од меѓусебно влијание и конкуренција за ресурси. Во базените се вклучени и мрежи, што укажува на можноста за користење на преклопување на адреси. Базените мора да бидат способни да се зголемуваат по потреба. Употребата на базени овозможува да се обезбеди потребното ниво на толеранција на грешки во ресурсите и апстракција на физички и виртуелни ресурси - на примателот на услугата едноставно му се обезбедува множеството ресурси што ги побарал (каде овие ресурси се физички лоцирани, на колку сервери и прекинувачи - тоа не е важно за клиентот). Сепак, мора да го земеме предвид фактот дека давателот мора да обезбеди транспарентно резервирање на овие ресурси.
Брзо прилагодување на различни услови. Услугите мора да бидат флексибилни - брзо обезбедување ресурси, нивна прераспределба, додавање или намалување на ресурсите по барање на клиентот, а од страна на клиентот треба да има чувство дека ресурсите во облакот се бескрајни. За полесно разбирање, на пример, не гледате предупредување дека дел од просторот на вашиот диск во Apple iCloud исчезнал затоа што хард дискот на серверот е расипан, а дисковите навистина се расипуваат. Дополнително, од ваша страна, можностите на оваа услуга се речиси неограничени - ви требаат 2 ТБ - нема проблем, сте ја платиле и сте ја добиле. Сличен пример може да се даде со Google.Drive или Yandex.Disk.
Можност за мерење на дадената услуга. Облак системите мора автоматски да ги контролираат и оптимизираат потрошените ресурси, а овие механизми мора да бидат транспарентни и за корисникот и за давателот на услуги. Односно, секогаш можете да проверите колку ресурси трошите вие и вашите клиенти.
Вреди да се земе предвид фактот дека овие барања се претежно барања за јавен облак, така што за приватен облак (односно облак лансиран за внатрешни потреби на компанијата), овие барања може малку да се прилагодат. Сепак, тие сè уште треба да се направат, инаку нема да ги добиеме сите придобивки од cloud computing.
Зошто ни треба облак?
Сепак, секоја нова или постоечка технологија, секој нов протокол се креира за нешто (добро, освен за RIP-ng, се разбира). Никој не треба протокол заради протокол (добро, освен RIP-ng, се разбира). Логично е дека Облакот е создаден за да обезбеди некаква услуга на корисникот/клиентот. Сите сме запознаени со барем неколку облак услуги, на пример Dropbox или Google.Docs, и верувам дека повеќето луѓе успешно ги користат - на пример, овој напис е напишан со помош на услугата облак Google.Docs. Но, облак услугите што ги знаеме се само дел од можностите на облакот - поточно, тие се само услуга од типот SaaS. Можеме да обезбедиме облак услуга на три начини: во форма на SaaS, PaaS или IaaS. Која услуга ви треба зависи од вашите желби и можности.
Ајде да го разгледаме секој по редослед:
Софтвер како сервис (SaaS) е модел за обезбедување на полноправна услуга на клиентот, на пример, услуга за е-пошта како Yandex.Mail или Gmail. Во овој модел на испорака на услуги, вие, како клиент, всушност не правите ништо освен користење на услугите - односно, не треба да размислувате за поставување на услугата, нејзината толеранција на грешки или вишок. Главната работа не е да ја загрозите вашата лозинка; давателот на оваа услуга ќе го направи останатото за вас. Од гледна точка на давателот на услугата, тој е целосно одговорен за целата услуга - од хардверот на серверот и оперативните системи на домаќинот до поставките за базата на податоци и софтверот.
Платформа како услуга (PaaS) — при користење на овој модел, давателот на услуги му обезбедува на клиентот работно парче за услугата, на пример, да земеме веб-сервер. Давателот на услугата му обезбеди на клиентот виртуелен сервер (всушност, збир на ресурси, како што се RAM/CPU/Storage/Nets, итн.), па дури и го инсталираше оперативниот систем и потребниот софтвер на овој сервер, меѓутоа, конфигурацијата на сите овие работи ги прави самиот клиент и за извршување на услугата клиентот одговара. Давателот на услугата, како и во претходниот случај, е одговорен за изведбата на физичката опрема, хипервизорите, самата виртуелна машина, нејзината мрежна достапност итн., но самата услуга повеќе не е во нејзината област на одговорност.
Инфраструктура како услуга (IaaS) - овој пристап е веќе поинтересен, всушност, давателот на услугата му обезбедува на клиентот целосна виртуелизирана инфраструктура - односно одреден сет (базен) ресурси, како што се јадра на процесорот, RAM меморија, мрежи итн. Се друго е до клиентот - што сака клиентот да прави со овие ресурси во рамките на доделениот базен (квота) - тоа не е особено важно за добавувачот. Без разлика дали клиентот сака да создаде свој vEPC или дури и да создаде мини оператор и да обезбеди комуникациски услуги - без сомнение - направете го тоа. Во такво сценарио, давателот на услугата е одговорен за обезбедување ресурси, нивната толеранција и достапност на грешки, како и ОС што им овозможува да ги здружат овие ресурси и да ги направат достапни на клиентот со можност за зголемување или намалување на ресурсите во секое време. на барање на клиентот. Клиентот сам ги конфигурира сите виртуелни машини и други лажички преку порталот и конзолата за самопослужување, вклучително и поставување мрежи (освен за надворешни мрежи).
Што е OpenStack?
Во сите три опции, на давателот на услугата му е потребен ОС кој ќе овозможи креирање на облак инфраструктура. Всушност, со SaaS, повеќе од една поделба е одговорна за целиот куп технологии - постои поделба која е одговорна за инфраструктурата - односно, обезбедува IaaS на друга поделба, оваа поделба обезбедува SaaS на клиентот. OpenStack е еден од облак оперативните системи кој ви овозможува да соберете еден куп прекинувачи, сервери и системи за складирање во еден базен на ресурси, да го поделите овој заеднички базен на подгрупи (закупци) и да ги обезбедите овие ресурси на клиентите преку мрежата.
OpenStack е облак оперативен систем кој ви овозможува да контролирате големи групи на компјутерски ресурси, складирање податоци и мрежни ресурси, обезбедени и управувани преку API користејќи стандардни механизми за автентикација.
Со други зборови, ова е збир на проекти за слободен софтвер кој е дизајниран да создаде облак услуги (и јавни и приватни) - односно збир на алатки кои ви дозволуваат да комбинирате сервер и опрема за префрлување во единствен базен на ресурси, да управувате овие ресурси, обезбедувајќи го потребното ниво на толеранција на грешки.
Во моментот на пишување на овој материјал, структурата на OpenStack изгледа вака:
Сликата е преземена од
Секоја од компонентите вклучени во OpenStack врши одредена функција. Оваа дистрибуирана архитектура ви овозможува да го вклучите во решението множеството функционални компоненти што ви се потребни. Сепак, некои компоненти се коренски компоненти и нивното отстранување ќе доведе до целосна или делумна нефункционалност на растворот како целина. Овие компоненти обично се класифицираат како:
- Профил — Веб-базиран GUI за управување со услугите на OpenStack
- клуч е централизирана услуга за идентитет која обезбедува функционалност за автентикација и авторизација за други услуги, како и управување со корисничките акредитиви и нивните улоги.
- Неутрон - мрежна услуга која обезбедува поврзување помеѓу интерфејсите на различни услуги на OpenStack (вклучувајќи поврзување помеѓу VM и нивниот пристап до надворешниот свет)
- Пепел — обезбедува пристап до блокирање складирање за виртуелни машини
- Нова — управување со животниот циклус на виртуелните машини
- Поглед — складиште на слики и снимки од виртуелната машина
- Свифт — обезбедува пристап до објектот за складирање
- Цилометар — услуга која обезбедува можност за собирање телеметрија и мерење на расположливите и потрошените ресурси
- Топлина — оркестрација врз основа на шаблони за автоматско креирање и обезбедување ресурси
Може да се погледне комплетната листа на сите проекти и нивната цел .
Секоја OpenStack компонента е услуга која извршува одредена функција и обезбедува API за управување со таа функција и интеракција со други услуги на оперативниот систем во облак за да се создаде унифицирана инфраструктура. На пример, Nova обезбедува управување со компјутерски ресурси и API за пристап до конфигурирање на овие ресурси, Glance обезбедува управување со слики и API за управување со нив, Cinder обезбедува складирање на блокови и API за управување со него, итн. Сите функции се меѓусебно поврзани на многу близок начин.
Меѓутоа, ако го погледнете, сите услуги што работат во OpenStack на крајот се некаква виртуелна машина (или контејнер) поврзана на мрежата. Се поставува прашањето - зошто ни се потребни толку многу елементи?
Ајде да поминеме низ алгоритмот за создавање виртуелна машина и нејзино поврзување со мрежата и постојано складирање во Openstack.
- Кога креирате барање за создавање машина, било да е тоа барање преку Хоризонт (табла) или барање преку CLI, првото нешто што се случува е овластување на вашето барање на Keystone - дали може да креирате машина, дали има право на користење на оваа мрежа, дали вашата нацрт-квота, итн.
- Keystone го автентицира вашето барање и генерира токен за автентичност во пораката за одговор, што ќе се користи понатаму. Откако доби одговор од Keystone, барањето се испраќа до Нова (nova api).
- Nova-api ја проверува валидноста на вашето барање со контактирање со Keystone користејќи го претходно генерираниот токен за автентичност
- Keystone врши автентикација и обезбедува информации за дозволите и ограничувањата врз основа на овој токен за автентикација.
- Nova-api создава запис за новиот VM во nova-database и го пренесува барањето за креирање на машината до nova-распоредувач.
- Nova-scheduler го избира домаќинот (компјутерски јазол) на кој ќе се распореди VM врз основа на наведените параметри, тежини и зони. Записот за ова и VM ID се запишани во базата на податоци на Нова.
- Следно, nova-распоредувачот контактира со nova-compute со барање за распоредување на примерок. Nova-compute контактира со nova-conductor за да добие информации за параметрите на машината (nova-conductor е нов елемент кој делува како прокси-сервер помеѓу nova-database и nova-compute, ограничувајќи го бројот на барања до nova-database за да избегне проблеми со базата на податоци намалување на оптоварувањето на конзистентноста).
- Нова-диригент ја добива бараната информација од нова-база на податоци и ја пренесува на нова-компјутер.
- Следно, Nova-compute повиците погледнете за да го добиете ID на сликата. Glace го потврдува барањето во Keystone и ги враќа бараните информации.
- Nova-компјутер го контактира неутронот за да добие информации за мрежните параметри. Слично на погледот, неутронот го потврдува барањето во Keystone, по што создава запис во базата на податоци (идентификатор на портата, итн.), креира барање за креирање порта и ги враќа бараните информации на nova-compute.
- Nova-compute контактите се заситуваат со барање да се додели волумен на виртуелната машина. Слично на погледот, сидерот го потврдува барањето во Keystone, создава барање за создавање волумен и ги враќа бараните информации.
- Nova-compute контактите libvirt со барање да се распореди виртуелна машина со наведените параметри.
Всушност, навидум едноставна операција за создавање на едноставна виртуелна машина се претвора во таков вител на повици API помеѓу елементите на облак платформата. Покрај тоа, како што можете да видите, дури и претходно назначените услуги се состојат од помали компоненти меѓу кои се јавува интеракција. Создавањето машина е само мал дел од она што ви овозможува да го правите платформата за облак - постои услуга одговорна за балансирање на сообраќајот, услуга одговорна за складирање блок, услуга одговорна за DNS, услуга одговорна за обезбедување на голи метални сервери итн. Облакот ви дозволува да ги третирате вашите виртуелни машини како стадо овци (наспроти виртуелизацијата). Ако нешто се случи со вашата машина во виртуелна средина - ја враќате од резервни копии, итн., Но апликациите во облак се изградени на таков начин што виртуелната машина не игра толку важна улога - виртуелната машина „умре“ - нема проблем - штотуку е создадено ново возилото е базирано на шаблонот и, како што велат, одредот не забележал загуба на борецот. Секако, ова предвидува присуство на механизми за оркестрација - користејќи шаблони за топлина, можете лесно да распоредите сложена функција која се состои од десетици мрежи и виртуелни машини.
Секогаш вреди да се има на ум дека не постои облак инфраструктура без мрежа - секој елемент на еден или друг начин комуницира со други елементи преку мрежата. Покрај тоа, облакот има апсолутно нестатична мрежа. Секако, подлогата мрежа е уште повеќе или помалку статична - нови јазли и прекинувачи не се додаваат секој ден, но компонентата на преклоп може и неизбежно ќе се менува постојано - нови мрежи ќе се додаваат или бришат, ќе се појават нови виртуелни машини и стари ќе умре. И како што се сеќавате од дефиницијата за облакот дадена на самиот почеток на статијата, ресурсите треба да се распределат на корисникот автоматски и со најмала (или уште подобро, без) интервенција од давателот на услугата. Односно, типот на обезбедување на мрежни ресурси што сега постои во форма на преден дел во форма на вашата лична сметка достапна преку http/https и дежурниот мрежен инженер Василиј како заднина не е облак, дури и ако Василиј има осум раце.
Неутрон, како мрежна услуга, обезбедува API за управување со мрежниот дел од инфраструктурата на облакот. Услугата го напојува и управува со мрежниот дел на Openstack преку обезбедување на слој за апстракција наречена Network-as-a-Service (NaaS). Односно, мрежата е истата виртуелна мерлива единица како, на пример, виртуелните јадра на процесорот или количината на RAM меморија.
Но, пред да преминеме на архитектурата на мрежниот дел на OpenStack, да размислиме како оваа мрежа работи во OpenStack и зошто мрежата е важен и составен дел од облакот.
Значи, имаме два RED клиентски VM и две GREEN клиент VM. Да претпоставиме дека овие машини се наоѓаат на два хипервизори на овој начин:
Во моментов, ова е само виртуелизација на 4 сервери и ништо повеќе, бидејќи досега сè што направивме е виртуелизирање на 4 сервери, ставајќи ги на два физички сервери. И досега не се ни поврзани на мрежата.
За да направиме облак, треба да додадеме неколку компоненти. Прво, го виртуелизираме мрежниот дел - треба да ги поврземе овие 4 машини во парови, а клиентите сакаат L2 врска. Можете да користите прекинувач и да конфигурирате багажникот во негова насока и да решите сè со помош на линукс мост или, за понапредните корисници, openvswitch (на ова ќе се вратиме подоцна). Но, може да има многу мрежи, а постојаното туркање на L2 преку прекинувач не е најдобрата идеја - има различни оддели, сервис, месеци чекање да се пополни апликацијата, недели смена на проблеми - во современиот свет ова пристапот повеќе не функционира. И колку побрзо компанијата го разбере ова, толку полесно и е да оди напред. Затоа, помеѓу хипервизорите ќе избереме мрежа L3 преку која ќе комуницираат нашите виртуелни машини, а на врвот на оваа L3 мрежа ќе изградиме виртуелни L2 преклопни мрежи каде ќе се одвива сообраќајот на нашите виртуелни машини. Можете да користите GRE, Geneve или VxLAN како инкапсулација. Засега да се фокусираме на второто, иако не е особено важно.
Треба да го лоцираме VTEP некаде (се надевам дека сите се запознаени со терминологијата VxLAN). Бидејќи имаме мрежа L3 која доаѓа директно од серверите, ништо не не спречува да поставиме VTEP на самите сервери, а OVS (OpenvSwitch) е одличен во тоа. Како резултат, го добивме овој дизајн:
Бидејќи сообраќајот помеѓу VM мора да биде поделен, портите кон виртуелните машини ќе имаат различни vlan броеви. Бројот на ознаката игра улога само во еден виртуелен прекинувач, бидејќи кога е инкапсулиран во VxLAN можеме лесно да го отстраниме, бидејќи ќе имаме VNI.
Сега можеме да ги креираме нашите машини и виртуелни мрежи за нив без никакви проблеми.
Меѓутоа, што ако клиентот има друга машина, но е на друга мрежа? Ни треба искоренување помеѓу мрежите. Ќе разгледаме едноставна опција кога се користи централизирано рутирање - односно сообраќајот се насочува преку специјални посветени мрежни јазли (добро, по правило, тие се комбинираат со контролни јазли, така што ќе го имаме истото).
Се чини дека нема ништо комплицирано - правиме интерфејс за мост на контролниот јазол, го возиме сообраќајот до него и оттаму го насочуваме каде што ни треба. Но, проблемот е што клиентот RED сака да ја користи мрежата 10.0.0.0/24, а клиентот GREEN сака да ја користи мрежата 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, но да бидеме искрени - FC е веќе остаток од минатото - аналог на Е1 во транспортот - да, се согласувам, сè уште се користи, но само таму каде што е апсолутно невозможно без него. Затоа, не би доброволно да распоредам мрежа на ФК во 2020 година, знаејќи дека има други поинтересни алтернативи. Иако за секој свој, може да има и такви кои веруваат дека ФК со сите негови ограничувања е сè што ни треба - нема да се расправам, секој има свое мислење. Сепак, најинтересно решение според мене е користење на СДС, како што е Ceph.
Ceph ви овозможува да изградите високо достапно решение за складирање податоци со куп можни опции за резервна копија, почнувајќи со кодови со проверка на паритет (аналогно на рацијата 5 или 6) завршувајќи со целосна репликација на податоци на различни дискови, земајќи ја предвид локацијата на дисковите во сервери и сервери во кабинети итн.
За да изградите Ceph ви требаат уште 3 јазли. Интеракцијата со складиштето ќе се врши и преку мрежата користејќи услуги за складирање блок, објекти и датотеки. Ајде да додадеме складирање на шемата:
Забелешка: можете да направите и хиперконвергирани пресметковни јазли - ова е концептот на комбинирање на неколку функции на еден јазол - на пример складирање+пресметување - без да се посветат специјални јазли за складирање на цеф. Ќе ја добиеме истата шема за толеранција на грешки - бидејќи СДС ќе резервира податоци со нивото на резервација што го специфицираме. Сепак, хиперконвергираните јазли се секогаш компромис - бидејќи јазолот за складирање не само што го загрева воздухот како што изгледа на прв поглед (бидејќи на него нема виртуелни машини) - тој ги троши ресурсите на процесорот за сервисирање на SDS (всушност, тој прави сè репликација и обновување по дефекти на јазли, дискови, итн.). Односно, ќе изгубите дел од моќта на компјутерскиот јазол ако го комбинирате со складирање.
Сите овие работи треба некако да се управуваат - ни треба нешто преку кое можеме да создадеме машина, мрежа, виртуелен рутер итн. За да го направите ова, ќе додадеме услуга на контролниот јазол што ќе дејствува како контролна табла - клиентот ќе може да се поврзе со овој портал преку http/ https и да прави се што му треба (добро, скоро).
Како резултат на тоа, сега имаме систем толерантен за грешки. Сите елементи на оваа инфраструктура мора некако да се управуваат. Претходно беше опишано дека Openstack е збир на проекти, од кои секој обезбедува одредена функција. Како што гледаме, има повеќе од доволно елементи што треба да се конфигурираат и контролираат. Денес ќе зборуваме за мрежниот дел.
Неутронска архитектура
Во OpenStack, Neutron е тој кој е одговорен за поврзување на портите на виртуелната машина со заедничка L2 мрежа, обезбедувајќи рутирање на сообраќајот помеѓу VMs лоцирани на различни L2 мрежи, како и кон надвор рутирање, обезбедување услуги како NAT, Floating IP, DHCP итн.
На високо ниво, работата на мрежната услуга (основниот дел) може да се опише на следниов начин.
При стартување на VM, мрежната услуга:
- Креира порта за даден VM (или порти) и ја известува услугата DHCP за тоа;
- Се креира нов виртуелен мрежен уред (преку libvirt);
- VM се поврзува со портот(ите) создадени во чекор 1;
Доволно чудно, работата на Неутрон се заснова на стандардни механизми познати на сите што некогаш се нурнале во Linux - именски простори, iptables, Linux мостови, openvswitch, conntrack итн.
Веднаш треба да се разјасни дека Неутрон не е SDN контролер.
Неутронот се состои од неколку меѓусебно поврзани компоненти:
Опенстак-неутронски-сервер е демон кој работи со кориснички барања преку API. Овој демон не е вклучен во регистрирањето на какви било мрежни врски, но ги обезбедува потребните информации за тоа на неговите приклучоци, кои потоа го конфигурираат саканиот мрежен елемент. Неутронските агенси на јазлите на OpenStack се регистрираат со Неутронскиот сервер.
Неутронскиот сервер е всушност апликација напишана во питон, која се состои од два дела:
- Услуга REST
- Неутронски приклучок (јадро/услуга)
Услугата REST е дизајнирана да прима повици од API од други компоненти (на пример, барање да се обезбедат некои информации, итн.)
Приклучоците се софтверски компоненти/модули за приклучок кои се повикуваат за време на барањата за API - односно, припишувањето на услугата се случува преку нив. Приклучоците се поделени на два вида - сервис и root. Како по правило, додатокот за коњ е главно одговорен за управување со адресниот простор и L2 врските помеѓу VMs, а приклучоците за услуги веќе обезбедуваат дополнителна функционалност како VPN или FW.
Списокот на приклучоци достапни денес може да се види на пример
Може да има неколку додатоци за услуги, но може да има само еден додаток за коњи.
openstack-neutron-ml2 е стандарден приклучок за root Openstack. Овој приклучок има модуларна архитектура (за разлика од неговиот претходник) и ја конфигурира мрежната услуга преку драјвери поврзани со неа. Ќе го разгледаме самиот додаток малку подоцна, бидејќи всушност тој ја дава флексибилноста што ја има OpenStack во мрежниот дел. Приклучокот за root може да се замени (на пример, Contrail Networking прави таква замена).
RPC услуга (rabbitmq-сервер) — услуга која обезбедува управување со редици и интеракција со други услуги на OpenStack, како и интеракција помеѓу мрежни сервисни агенти.
Мрежни агенти — агенти кои се наоѓаат во секој јазол, преку кои се конфигурираат мрежните услуги.
Постојат неколку видови на агенти.
Главниот агент е L2 агент. Овие агенти работат на секој од хипервизорите, вклучувајќи ги и контролните јазли (поточно, на сите јазли кои обезбедуваат каква било услуга за станарите) и нивната главна функција е да ги поврзат виртуелните машини со заедничка мрежа L2, а исто така да генерираат предупредувања кога ќе се случат какви било настани ( на пример оневозможи/овозможи ја портата).
Следниот, не помалку важен агент е L3 агент. Стандардно, овој агент работи исклучиво на мрежен јазол (често мрежниот јазол е комбиниран со контролен јазол) и обезбедува рутирање помеѓу мрежите на станарите (и помеѓу неговите мрежи и мрежите на другите станари и е достапен за надворешниот свет, обезбедувајќи NAT, како и DHCP услуга). Меѓутоа, кога користите DVR (дистрибуиран рутер), потребата за приклучок L3 се појавува и на пресметковните јазли.
Агентот L3 користи именски простори на Линукс за да му обезбеди на секој закупец сет од свои изолирани мрежи и функционалноста на виртуелните рутери кои го насочуваат сообраќајот и обезбедуваат услуги на портал за мрежите на слојот 2.
База на податоци — база на податоци со идентификатори на мрежи, подмрежи, порти, базени итн.
Всушност, Neutron ги прифаќа барањата за API од создавањето на какви било мрежни ентитети, го автентицира барањето и преку RPC (ако пристапи до некој додаток или агент) или REST API (ако комуницира во SDN) им пренесува на агентите (преку приклучоци) инструкции неопходни за организирање на бараната услуга .
Сега да се свртиме кон тест-инсталацијата (како е распоредена и што е вклучено во неа, ќе видиме подоцна во практичниот дел) и да видиме каде се наоѓа секоја компонента:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$
Всушност, тоа е целата структура на неутронот. Сега вреди да потрошите малку време на приклучокот ML2.
Модуларен слој 2
Како што споменавме погоре, приклучокот е стандарден приклучок за root OpenStack и има модуларна архитектура.
Претходникот на приклучокот ML2 имаше монолитна структура, што не дозволуваше, на пример, користење на мешавина од неколку технологии во една инсталација. На пример, не можете истовремено да ги користите и openvswitch и linuxbridge - или првиот или вториот. Поради оваа причина, приклучокот ML2 со својата архитектура е создаден.
ML2 има две компоненти - два типа на двигатели: двигатели на типот и двигатели на механизмот.
Тип драјвери одреди ги технологиите што ќе се користат за организирање на мрежните врски, на пример VxLAN, VLAN, GRE. Во исто време, возачот дозволува користење на различни технологии. Стандардната технологија е VxLAN инкапсулација за преклопени мрежи и vlan надворешни мрежи.
Возачите за типови ги вклучуваат следните типови на мрежа:
Рамни - мрежа без означување
VLAN - означена мрежа
Локалните — посебен тип на мрежа за се-во-едно инсталации (таквите инсталации се потребни или за програмери или за обука)
GRE — преклопена мрежа со користење на GRE тунели
VxLAN — преклопување на мрежа користејќи VxLAN тунели
Возачи на механизмите дефинирајте алатки кои обезбедуваат организација на технологиите наведени во двигателот на типот - на пример, openvswitch, sr-iov, opendaylight, OVN итн.
Во зависност од имплементацијата на овој драјвер, ќе се користат или агенти контролирани од Neutron, или ќе се користат врски со надворешен SDN контролер, кој се грижи за сите прашања поврзани со организирање на L2 мрежи, рутирање итн.
Пример: ако користиме ML2 заедно со OVS, тогаш L2 агент е инсталиран на секој компјутерски јазол што управува со OVS. Меѓутоа, ако користиме, на пример, OVN или OpenDayLight, тогаш контролата на OVS доаѓа под нивна јурисдикција - Неутрон, преку приклучокот за root, му дава команди на контролерот, а тој веќе го прави она што му е кажано.
Ајде да започнеме со Open vSwitch
Во моментов, една од клучните компоненти на OpenStack е Open vSwitch.
Кога инсталирате OpenStack без дополнителен SDN на продавачот, како што се Juniper Contrail или Nokia Nuage, OVS е главната мрежна компонента на мрежата на облак и, заедно со iptables, conntrack, именски простори, ви овозможува да организирате полноправни мрежи за преклопување со повеќе наемни. Секако, оваа компонента може да се замени, на пример, кога се користат решенија за SDN сопственички (продавачи) од трети страни.
OVS е софтверски прекинувач со отворен код кој е дизајниран за употреба во виртуелизирани околини како виртуелен транспортер на сообраќај.
Во моментов, OVS има многу пристојна функционалност, која вклучува технологии како QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK итн.
Забелешка: OVS првично не беше замислен како мек прекинувач за високо оптоварени телекомуникациски функции и беше повеќе дизајниран за ИТ функции кои бараат помалку пропусен опсег, како што се WEB сервер или сервер за пошта. Сепак, OVS дополнително се развива и сегашните имплементации на OVS значително ги подобрија неговите перформанси и способности, што овозможува да се користи од телекомуникациски оператори со високо оптоварени функции, на пример, постои имплементација на OVS со поддршка за забрзување на DPDK.
Постојат три важни компоненти на OVS за кои треба да знаете:
- Модул на јадрото — компонента лоцирана во просторот на јадрото што го обработува сообраќајот врз основа на правилата добиени од контролниот елемент;
- vПрефрли демон (ovs-vswitchd) е процес лансиран во корисничкиот простор кој е одговорен за програмирање на модулот на јадрото - односно директно ја претставува логиката на работата на прекинувачот
- Сервер за бази на податоци - локална база на податоци лоцирана на секој домаќин што работи OVS, во кој е зачувана конфигурацијата. SDN контролерите можат да комуницираат преку овој модул користејќи го протоколот OVSDB.
Сето ова е придружено со збир на алатки за дијагностика и управување, како што се ovs-vsctl, ovs-appctl, ovs-ofctl, итн.
Во моментов, Openstack е широко користен од телекомуникациските оператори за мигрирање на мрежните функции на него, како што се EPC, SBC, HLR, итн. Некои функции можат да живеат без проблеми со OVS како што е, но на пример, EPC го обработува сообраќајот на претплатниците - потоа поминува низ огромна количина сообраќај (сега обемот на сообраќај достигнува неколку стотици гигабити во секунда). Секако, возењето на таков сообраќај низ просторот на јадрото (бидејќи шпедитерот стандардно се наоѓа таму) не е најдобрата идеја. Затоа, OVS често се распоредува целосно во корисничкиот простор користејќи технологија за забрзување DPDK за да го проследи сообраќајот од NIC до корисничкиот простор заобиколувајќи го кернелот.
Забелешка: за облак распореден за телекомуникациски функции, можно е да се емитува сообраќај од компјутерски јазол заобиколувајќи го OVS директно до опремата за префрлување. За таа цел се користат механизми SR-IOV и Passthrough.
Како функционира ова на вистински распоред?
Па, сега да преминеме на практичниот дел и да видиме како сето тоа функционира во пракса.
Прво, ајде да распоредиме едноставна инсталација на Openstack. Бидејќи немам при рака збир на сервери за експерименти, ќе го составиме прототипот на еден физички сервер од виртуелни машини. Да, нормално, ваквото решение не е погодно за комерцијални цели, но за да видите пример како функционира мрежата во Openstack, таква инсталација е доволна за очи. Покрај тоа, таквата инсталација е уште поинтересна за цели на обука - бидејќи можете да фатите сообраќај, итн.
Бидејќи треба да го видиме само основниот дел, не можеме да користиме неколку мрежи, туку да подигнеме сè користејќи само две мрежи, а втората мрежа во овој распоред ќе се користи исклучиво за пристап до подоблакот и DNS серверот. Засега нема да допираме надворешни мрежи - ова е тема за посебна голема статија.
Значи, да почнеме по ред. Прво, малку теорија. Ќе инсталираме Openstack користејќи TripleO (Openstack на Openstack). Суштината на TripleO е што инсталираме Openstack сè-во-едно (т.е. на еден јазол), наречен undercloud, а потоа ги користиме можностите на распоредениот Openstack за да го инсталираме Openstack наменет за работа, наречен overcloud. 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 bridge и поврзав виртуелни машини со него преку порт-групи. За да го направите ова, создадов 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.
По успешна инсталација, треба да имате виртуелна машина на која можете да инсталирате undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningПрво, инсталирајте ги алатките потребни за процесот на инсталација:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Инсталација под облак
Ние создаваме корисник на стек, поставуваме лозинка, ја додаваме во sudoer и му даваме можност да извршува root команди преку 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. Го користев изданието на Квинс, но можете да користите кое било друго што сакате.
Следно, копирајте ја конфигурациската датотека 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 — целото име на подоблак серверот, мора да одговара на записот на серверот DNS
local_ip — локална подоблак адреса кон обезбедување на мрежа
мрежа_порта — истата локална адреса, која ќе делува како порта за пристап до надворешниот свет при инсталирање на јазли преку облак, исто така се совпаѓа со локалната IP
undercloud_public_host — надворешна API адреса, се доделува која било бесплатна адреса од мрежата за обезбедување
undercloud_admin_host внатрешна API адреса, секоја слободна адреса од мрежата за обезбедување е доделена
undercloud_name сервери - DNS сервер
генерира_сервис_сертификат - оваа линија е многу важна во тековниот пример, бидејќи ако не ја поставите на неточно, ќе добиете грешка при инсталацијата, проблемот е опишан на следењето на грешки на Red Hat
локален_интерфејс интерфејс во мрежно обезбедување. Овој интерфејс ќе се реконфигурира за време на распоредувањето на подоблакот, така што треба да имате два интерфејси на undercloud - еден за пристап до него, вториот за обезбедување
local_mtu - МТУ. Бидејќи имаме лабораторија за тестирање и имам MTU од 1500 на портите на прекинувачот OVS, потребно е да го поставите на 1450 за да можат да поминат пакетите инкапсулирани во VxLAN.
мрежа_цидр — мрежа за обезбедување
маскарада — користење NAT за пристап до надворешна мрежа
маскарада_мрежа - мрежа која ќе биде NATed
dhcp_start — почетната адреса на базенот со адреси од кој адресите ќе бидат доделени на јазлите за време на распоредувањето преку облак
dhcp_end — конечната адреса на базенот со адреси од кој адресите ќе бидат доделени на јазлите за време на распоредувањето преку облак
инспекција_iprange — збир на адреси неопходни за интроспекција (не треба да се преклопуваат со горенаведениот базен)
scheduler_max_attempts — максимален број обиди за инсталирање 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.
#############################################################################Овој излез вели дека успешно сте го инсталирале undercloud и сега можете да го проверите статусот на undercloud и да продолжите да инсталирате overcloud.
Ако го погледнете излезот ifconfig, ќе видите дека се појави нов интерфејс за мост
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Распоредувањето преку облак сега ќе се врши преку овој интерфејс.
Од излезот подолу можете да видите дека ги имаме сите услуги на еден јазол:
(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 ќе го инсталира оперативниот систем и потребниот софтвер на машината преку облак - односно не треба целосно да ја распоредиме машината, туку само да создадеме диск (или дискови) за неа и да ги одредиме неговите параметри - т.е. , всушност, добиваме гол сервер без инсталиран ОС на него.
Ајде да одиме во папката со дисковите на нашите виртуелни машини и да создадеме дискови со потребната големина:
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, која создава xml датотека со опис на секоја машина во папката /tmp/; ако не ја додадете, нема да бидете способни да идентификуваат виртуелни машини.
Сега треба да ги дефинираме сите овие машини во virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Сега мала нијанса - tripleO користи IPMI за управување со серверите за време на инсталацијата и интроспекцијата.
Интроспекцијата е процес на проверка на хардверот со цел да се добијат неговите параметри неопходни за понатамошно обезбедување на јазли. Интроспекцијата се врши со помош на иронична, услуга дизајнирана да работи со голи метални сервери.
Но, тука е проблемот - додека хардверските IPMI сервери имаат посебна порта (или заедничка порта, но ова не е важно), тогаш виртуелните машини немаат такви порти. Овде ни доаѓа на помош патерица наречена vbmc - алатка која ви овозможува да имитирате IPMI порта. На оваа нијанса вреди да се обрне внимание особено за оние кои сакаат да постават таква лабораторија на ESXI хипервизор - да бидам искрен, не знам дали има аналог на vbmc, па вреди да се запрашате за ова прашање пред да распоредите сè .
Инсталирајте vbmc:
yum install yum install python2-virtualbmcАко вашиот ОС не може да го најде пакетот, тогаш додајте го складиштето:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmСега ја поставивме алатката. Овде се е банално до срамота. Сега е логично да нема сервери во списокот vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# За да се појават, мора рачно да се декларираат вака:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Мислам дека синтаксата на командата е јасна без објаснување. Сепак, засега сите наши сесии се во статус ДОЛУ. За да се префрлат на статусот UP, треба да ги овозможите:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#И последниот допир - треба да ги поправите правилата за заштитен ѕид (или целосно да го оневозможите):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
Сега да одиме на undercloud и да провериме дали сè работи. Адресата на машината домаќин е 192.168.255.200, на undercloud го додадовме потребниот пакет ipmitool за време на подготовката за распоредување:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningКако што можете да видите, успешно го лансиравме контролниот јазол преку vbmc. Сега да го исклучиме и да продолжиме понатаму:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Следниот чекор е интроспекција на јазлите на кои ќе се инсталира overcloud. За да го направите ова, треба да подготвиме датотека json со опис на нашите јазли. Забележете дека, за разлика од инсталацијата на голи сервери, датотеката ја означува портата на која работи vbmc за секоја машина.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Забелешка: контролниот јазол има два интерфејси, но во овој случај тоа не е важно, во оваа инсталација еден ќе ни биде доволен.
Сега ја подготвуваме датотеката json. Треба да ја наведеме афион адресата на пристаништето преку кое ќе се врши обезбедување, параметрите на јазлите, да им дадеме имиња и да укажеме како да стигнете до ipmi:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Сега треба да подготвиме слики за иронично. За да го направите ова, преземете ги преку wget и инсталирајте:
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$Поставување слики на undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Проверка дали се вчитани сите слики
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Уште една работа - треба да додадете DNS сервер:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Сега можеме да ја дадеме командата за интроспекција:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Како што можете да видите од излезот, сè е завршено без грешки. Ајде да провериме дали сите јазли се во достапна состојба:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Ако јазлите се во поинаква состојба, обично податливи, тогаш нешто тргна наопаку и треба да го погледнете дневникот и да откриете зошто се случило тоа. Имајте на ум дека во ова сценарио користиме виртуелизација и може да има грешки поврзани со употребата на виртуелни машини или vbmc.
Следно, треба да означиме кој јазол која функција ќе ја извршува - односно да го означиме профилот со кој ќе се распореди јазолот:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Наведете го профилот за секој јазол:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167Ајде да провериме дали направивме сè правилно:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Ако сè е точно, ја даваме командата за распоредување преку облак:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuВо вистинска инсталација, природно ќе се користат приспособени шаблони, во нашиот случај тоа во голема мера ќе го комплицира процесот, бидејќи секое уредување во шаблонот ќе треба да се објасни. Како што беше напишано претходно, дури и едноставна инсталација ќе биде доволна за да видиме како функционира.
Забелешка: променливата qemu од типот --libvirt е неопходна во овој случај, бидејќи ќе користиме вгнездена виртуелизација. Во спротивно, нема да можете да стартувате виртуелни машини.
Сега имате околу еден час, или можеби повеќе (во зависност од можностите на хардверот) и можете само да се надевате дека по овој пат ќе ја видите следнава порака:
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 ~]$Сега имате речиси полноправна верзија на openstack, на која можете да учите, експериментирате итн.
Ајде да провериме дали сè работи како што треба. Во магацинот на домашниот директориум на корисникот има две датотеки - едната stackrc (за управување со undercloud) и втората overcloudrc (за управување со overcloud). Овие датотеки мора да бидат наведени како извор, бидејќи содржат информации неопходни за автентикација.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$Мојата инсталација сè уште бара еден мал допир - додавање рута на контролорот, бидејќи машината со која работам е на друга мрежа. За да го направите ова, одете на control-1 под сметката за администратор на топлина и регистрирајте ја маршрутата
(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 ~]$
Машините vm-1 и vm-3 се наоѓаат на compute-0, машините vm-2 и vm-4 се наоѓаат на јазолот compute-1.
Дополнително, создаден е виртуелен рутер за да овозможи рутирање помеѓу наведените мрежи:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ Рутерот има две виртуелни порти, кои делуваат како порти за мрежи:
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ Но, пред да погледнеме како тече сообраќајот, да погледнеме што моментално имаме на контролниот јазол (кој исто така е мрежен јазол) и на пресметковниот јазол. Да почнеме со пресметковниот јазол.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Во моментот, јазолот има три ovs мостови - br-int, br-tun, br-ex. Помеѓу нив, како што гледаме, има збир на интерфејси. За полесно разбирање, ајде да ги нацртаме сите овие интерфејси на дијаграмот и да видиме што ќе се случи.
Гледајќи ги адресите на кои се подигнати VxLAN тунелите, може да се види дека еден тунел е подигнат на пресметување-1 (192.168.255.26), вториот тунел изгледа како контрол-1 (192.168.255.15). Но, најинтересно е што br-ex нема физички интерфејси и ако погледнете какви текови се конфигурирани, можете да видите дека овој мост може само да го намали сообраќајот во моментот.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Како што можете да видите од излезот, адресата се навртува директно на физичката порта, а не на интерфејсот на виртуелниот мост.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$
Според првото правило, сè што доаѓа од пристаништето phy-br-ex мора да се отфрли.
Всушност, моментално нема никаде на друго место сообраќајот да доаѓа во овој мост освен од овој интерфејс (интерфејсот со br-int), и судејќи според падовите, сообраќајот BUM веќе лета во мостот.
Односно, сообраќајот може да го напушти овој јазол само преку тунелот VxLAN и ништо друго. Меѓутоа, ако го вклучите DVR, ситуацијата ќе се промени, но ние ќе се справиме со тоа друг пат. Кога користите мрежна изолација, на пример користејќи vlans, нема да имате еден L3 интерфејс во vlan 0, туку неколку интерфејси. Сепак, 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, сега сообраќајот оди надвор без ознака, како што е означено со vlan-id 0 во излез погоре.
Сè друго во моментот е слично на пресметковниот јазол - истите мостови, истите тунели одат до два компјутерски јазли.
Ние нема да ги разгледаме јазлите за складирање во оваа статија, но за разбирање, неопходно е да се каже дека мрежниот дел од овие јазли е банален до степен на срам. Во нашиот случај, има само една физичка порта (eth0) со IP адреса доделена на неа и тоа е тоа. Нема VxLAN тунели, тунелни мостови итн. - нема ovs воопшто, бидејќи нема поента во тоа. Кога се користи мрежна изолација, овој јазол ќе има два интерфејси (физички порти, телесни, или само две vlans - не е важно - зависи од тоа што сакате) - еден за управување, вториот за сообраќај (пишување на VM-дискот , читање од диск, итн.)
Сфативме што имаме на јазлите во отсуство на какви било услуги. Сега да стартуваме 4 виртуелни машини и да видиме како се менува шемата опишана погоре - треба да имаме порти, виртуелни рутери итн.
Досега нашата мрежа изгледа вака:
Имаме две виртуелни машини на секој компјутерски јазол. Користејќи го compute-0 како пример, ајде да видиме како сè е вклучено.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Машината има само еден виртуелен интерфејс - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Овој интерфејс изгледа во мостот на Linux:
[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 - Линукс мост
qvb и qvo - vEth пар поврзан со Linux bridge и Open vSwitch bridge
br-int, br-tun, br-vlan — Отворете ги vSwitch мостовите
patch-, int-br-, phy-br- - Отвори vSwitch закрпи интерфејси што поврзуваат мостови
qg, qr, ha, fg, sg - Отворете ги портите vSwitch што ги користат виртуелните уреди за поврзување со OVS
Како што разбирате, ако имаме порта qvb95d96a75-a0 во мостот, што е vEth пар, тогаш некаде таму е неговиот пандан, кој логично треба да се нарече qvo95d96a75-a0. Ајде да видиме кои порти се на OVS.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Како што можеме да видиме, пристаништето е во br-int. Br-int делува како прекинувач што ги завршува портите на виртуелната машина. Покрај qvo95d96a75-a0, портата qvo5bd37136-47 е видлива на излезот. Ова е пристаништето до втората виртуелна машина. Како резултат на тоа, нашиот дијаграм сега изгледа вака:
Прашање што веднаш треба да го интересира внимателниот читател - кој е мостот на Linux помеѓу пристаништето за виртуелна машина и портата OVS? Факт е дека за заштита на машината се користат безбедносни групи, кои не се ништо повеќе од iptables. OVS не работи со iptables, па затоа е измислена оваа „патерица“. Сепак, тој станува застарен - се заменува со conntrack во новите изданија.
Тоа е, на крајот шемата изгледа вака:
Две машини на еден хипервизор на една L2 мрежа
Бидејќи овие два VM се наоѓаат на иста L2 мрежа и на истиот хипервизор, сообраќајот меѓу нив логично ќе тече локално преку br-int, бидејќи и двете машини ќе бидат на истиот VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Две машини на различни хипервизори на иста мрежа L2
Сега да видиме како ќе оди сообраќајот помеѓу две машини на иста мрежа L2, но лоцирани на различни хипервизори. Да бидам искрен, ништо нема да се промени многу, само сообраќајот помеѓу хипервизорите ќе оди преку тунелот vxlan. Ајде да погледнеме на пример.
Адреси на виртуелни машини меѓу кои ќе го следиме сообраќајот:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Ја гледаме табелата за препраќање во br-int на compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Сообраќајот треба да оди до порта 2 - ајде да видиме за каков вид на пристаниште станува збор:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$Ова е patch-tun - тоа е интерфејсот во br-tun. Ајде да видиме што ќе се случи со пакетот на br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Пакетот е спакуван во VxLAN и испратен до портата 2. Ајде да видиме каде води портата 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Ова е vxlan тунел на compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Ајде да одиме на пресметување-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 е во табелата за препраќање br-int на compute-1, и како што може да се види од излезот погоре, тој е видлив преку портата 2, која е порта кон br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Па, тогаш гледаме дека во br-int на compute-1 има дестинација афион:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ Односно, примениот пакет ќе лета до портата 3, зад која веќе има пример за виртуелна машина-00000003.
Убавината на имплементирањето на Openstack за учење на виртуелната инфраструктура е што можеме лесно да го снимиме сообраќајот помеѓу хипервизорите и да видиме што се случува со него. Ова е она што ќе го направиме сега, стартувајте го tcpdump на портата vnet кон compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Првата линија покажува дека Patek од адресата 10.0.1.85 оди на адресата 10.0.1.88 (ICMP сообраќај), и е завиткана во VxLAN пакет со vni 22 и пакетот оди од домаќинот 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[],излез:2. 0x16 е vni во хексадецимален броен систем. Ајде да го претвориме овој број во 16-тиот систем:
16 = 6*16^0+1*16^1 = 6+16 = 22Односно, вни одговара на реалноста.
Втората линија покажува повратен сообраќај, добро, нема смисла да се објаснува, се е јасно таму.
Две машини на различни мрежи (меѓумрежно рутирање)
Последниот случај за денес е рутирање помеѓу мрежи во рамките на еден проект со помош на виртуелен рутер. Разгледуваме случај без DVR (ќе го разгледаме во друга статија), така што рутирањето се јавува на мрежниот јазол. Во нашиот случај, мрежниот јазол не е поставен во посебен ентитет и се наоѓа на контролниот јазол.
Прво, да видиме дека рутирањето функционира:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msБидејќи во овој случај пакетот мора да оди до портата и да биде насочен таму, треба да ја дознаеме адресата на афион на портата, за што ја гледаме табелата ARP во примерот:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Сега да видиме каде треба да се испрати сообраќајот со дестинација (10.0.1.254) fa:16:3e:c4:64:70:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Ајде да погледнеме каде води портата 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Се е логично, сообраќајот оди до бр-тун. Ајде да видиме во кој vxlan тунел ќе биде завиткан:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ Третата порта е vxlan тунел:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Кој гледа во контролниот јазол:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Сообраќајот стигна до контролниот јазол, па треба да одиме до него и да видиме како ќе се случи рутирањето.
Како што се сеќавате, контролниот јазол внатре изгледаше сосема исто како и компјутерскиот јазол - истите три моста, само br-ex имаше физичка порта преку која јазолот можеше да испраќа сообраќај надвор. Создавањето инстанци ја промени конфигурацијата на пресметковните јазли - linux bridge, iptables и интерфејси беа додадени на јазлите. Создавањето мрежи и виртуелен рутер, исто така, остави свој белег на конфигурацијата на контролниот јазол.
Значи, очигледно е дека MAC адресата на портата мора да биде во табелата за препраќање br-int на контролниот јазол. Ајде да провериме дали е таму и каде гледа:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Mac е видлив од портата qr-0c52b15f-8f. Ако се вратиме на листата на виртуелни порти во Openstack, овој тип на порта се користи за поврзување на различни виртуелни уреди со OVS. Да бидам попрецизен, qr е порта на виртуелниот рутер, кој е претставен како именски простор.
Ајде да видиме кои имиња се наоѓаат на серверот:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Дури три примероци. Но, судејќи според имињата, можете да ја погодите целта на секое од нив. Подоцна ќе се вратиме на примероците со 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, бидејќи сообраќајот, судејќи според дестинациската мак-адреса, отиде на овој интерфејс.
[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 ~]$ Сè е логично, без изненадувања. Ајде да видиме каде е видлива адресата poppy на домаќинот 10.0.2.8 во br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Очекувано сообраќајот оди до бр-тун, да видиме до кој тунел оди сообраќајот понатаму:
[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[],load:0x16->NXM_NX_TUN_ID[],излез:3. Да го претвориме 0x16 во декаден броен систем:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Тунелот за пресметување-1 го има следниот VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],излез:2. Да го претвориме 0x63 во декаден броен систем:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Па, сега да го погледнеме депонијата:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************Првиот пакет е vxlan пакет од домаќинот 192.168.255.19 (пресметај-0) до хостот 192.168.255.15 (контрола-1) со vni 22, во кој ICMP пакет е спакуван од домаќин 10.0.1.85 до домаќин 10.0.2.8. Како што пресметавме погоре, vni одговара на она што го видовме на излезот.
Вториот пакет е vxlan пакет од домаќинот 192.168.255.15 (контрола-1) до хостот 192.168.255.26 (пресметај-1) со vni 99, во кој 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. Ова се два DHCP сервери за нашите две мрежи 10.0.1.0/24 и 10.0.2.0/24.
Ајде да провериме дали ова е вистина. Има само една адреса во овој именски простор - 10.0.1.1 - адресата на самиот DHCP сервер, а исто така е вклучена во br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Ајде да видиме дали процесите што содржат qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 во нивното име на контролниот јазол:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ Постои таков процес и врз основа на информациите презентирани во излезот погоре, можеме, на пример, да видиме што моментално имаме за изнајмување:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$Како резултат на тоа, го добиваме следниот сет на услуги на контролниот јазол:
Па, имајте на ум - ова се само 4 машини, 2 внатрешни мрежи и еден виртуелен рутер... Овде сега немаме надворешни мрежи, еден куп различни проекти, секој со свои мрежи (се преклопуваат), а имаме дистрибуираниот рутер се исклучи, и на крајот, на крајот на краиштата, имаше само еден контролен јазол во тест-клупата (за толеранција на грешки мора да има кворум од три јазли). Логично е дека во трговијата сè е „малку“ покомплицирано, но во овој едноставен пример разбираме како тоа треба да функционира - дали имате 3 или 300 именски простори е секако важно, но од гледна точка на функционирањето на целата структура, ништо нема да се промени многу... иако нема да приклучите некој SDN од продавачот. Но, тоа е сосема друга приказна.
Се надевам дека беше интересно. Ако имате какви било коментари/дополнувања или некаде целосно излажав (јас сум човек и моето мислење секогаш ќе биде субјективно) - напишете што треба да се поправи/додаде - ќе исправиме/додадеме сè.
Како заклучок, би сакал да кажам неколку зборови за споредба на Openstack (и ванила и продавач) со решението за облак од VMWare - ова прашање ми го поставуваа премногу често во изминатите неколку години и, искрено кажано, јас сум веќе уморен од тоа, но сепак. Според мене, многу е тешко да се споредат овие две решенија, но дефинитивно можеме да кажеме дека има недостатоци и во двете решенија и при изборот на едно решение треба да ги одмерите добрите и лошите страни.
Ако OpenStack е решение управувано од заедницата, тогаш VMWare има право да го прави само она што го сака (читај - што е профитабилно за него) и тоа е логично - бидејќи тоа е комерцијална компанија која е навикната да заработува пари од своите клиенти. Но, има едно големо и дебело НО - можете да се симне од OpenStack, на пример од Nokia, и со малку трошоци да се префрлите на решение од, на пример, Juniper (Contrail Cloud), но веројатно нема да можете да се симнете од VMWare. . За мене овие две решенија изгледаат вака - Openstack (продавач) е едноставен кафез во кој сте ставени, но имате клуч и можете да заминете во секое време. VMWare е златен кафез, сопственикот го има клучот од кафезот и ќе ве чини многу.
Не го промовирам ниту првиот производ, ниту вториот - вие изберете што ви треба. Но, кога би имал таков избор, би ги избрал двете решенија - VMWare за IT облакот (мали оптоварувања, лесно управување), OpenStack од некој продавач (Nokia и Juniper обезбедуваат многу добри решенија со клуч на рака) - за Телеком облакот. Јас не би користел Openstack за чиста ИТ - тоа е како да пукаш врапчиња со топ, но не гледам никакви контраиндикации за негово користење освен вишок. Сепак, користењето на VMWare во телеком е како влечење кршен камен во Ford Raptor - убаво е однадвор, но возачот треба да направи 10 патувања наместо едно.
Според мое мислење, најголемиот недостаток на VMWare е неговата целосна затвореност - компанијата нема да ви даде никакви информации за тоа како работи, на пример, vSAN или што има во кернелот на хипервизорот - едноставно не е профитабилно за него - т.е. никогаш не станете експерт за VMWare - без поддршка од продавачот, вие сте осудени на пропаст (многу често среќавам експерти на VMWare кои се збунети од тривијални прашања). За мене, VMWare е купување на автомобил со заклучена хауба - да, можеби имате специјалисти кои можат да го сменат ременот за мерење на тајмингот, но само тој што ви го продаде ова решение може да ја отвори хаубата. Лично, не ми се допаѓаат решенија во кои не можам да се вклопам. Ќе речете дека можеби нема да мора да одите под хауба. Да, ова е можно, но ќе ве погледнам кога ќе треба да соберете голема функција во облакот од 20-30 виртуелни машини, 40-50 мрежи, од кои половината сакаат да излезат надвор, а втората половина бара SR-IOV забрзување, инаку ќе ви требаат уште неколку десетици од овие автомобили - инаку перформансите нема да бидат доволни.
Има и други гледишта, па само вие можете да одлучите што да изберете и што е најважно, тогаш ќе бидете одговорни за вашиот избор. Ова е само мое мислење - човек кој видел и допрел најмалку 4 производи - Nokia, Juniper, Red Hat и VMWare. Односно имам со што да споредувам.
Извор: www.habr.com