Облачните изчисления навлизат все по-дълбоко в живота ни и вероятно няма човек, който поне веднъж да не е използвал облачни услуги. Но какво е облак и как работи в по-голямата си част малко хора знаят дори на ниво идея. 5G се превръща в реалност и телекомуникационната инфраструктура започва да се движи от полюсни решения към облачни решения, както стана, когато премина от изцяло хардуерни решения към виртуализирани „стълбове“.
Днес ще говорим за вътрешния свят на облачната инфраструктура, по-специално ще анализираме основите на мрежовата част.
Какво е облак? Същата виртуализация - изглед на профил?
Повече от логичен въпрос. Не - това не е виртуализация, въпреки че не би могло без нея. Помислете за две определения:
Облачни изчисления (наричани по-нататък Облак) е модел за осигуряване на удобен за потребителя достъп до разпределени изчислителни ресурси, които трябва да бъдат разгърнати и работещи при поискване с възможно най-ниско забавяне и минимални разходи за доставчика на услуги.
виртуализация - това е възможността да разделите един физически обект (например сървър) на няколко виртуални, като по този начин увеличите използването на ресурси (например, имахте 3 сървъра, натоварени с 25-30 процента, след виртуализация получавате 1 зареден сървър с 80-90 процента). Естествено, виртуализацията изяжда част от ресурсите - трябва да захранвате хипервайзора, но както показа практиката, играта си струва свещта. Идеален пример за виртуализация е VMWare, който отлично подготвя виртуални машини или например KVM, който аз предпочитам, но това вече е въпрос на вкус.
Ние самите използваме виртуализация, без да го осъзнаваме, и дори железните рутери вече използват виртуализация - например в най-новата версия на JunOS операционната система е инсталирана като виртуална машина върху дистрибуцията на Linux в реално време (Wind River 9). Но виртуализацията не е облакът, но облакът не може да съществува без виртуализация.
Виртуализацията е един от градивните елементи, върху които е изграден облакът.
Няма да работи да се направи облак просто чрез събиране на няколко хипервайзора в един L2 домейн, добавяне на няколко yaml playbooks за автоматично регистриране на vlan чрез някакъв вид ansible и напълване на нещо като система за оркестрация, за да създава автоматично виртуални машини. По-точно, ще се окаже, но полученият Франкенщайн не е облакът, от който се нуждаем, въпреки че е като за някой, може би за някой това е най-голямата мечта. Освен това, ако вземете същия Openstack, всъщност той все още е Франкенщайн, но о, добре, нека не говорим за това засега.
Но разбирам, че от дефиницията, представена по-горе, не е напълно ясно какво всъщност може да се нарече облак.
Следователно документът от NIST (Национален институт за стандарти и технологии) изброява 5 основни характеристики, които трябва да притежава облачната инфраструктура:
Предоставяне на услуга при поискване. На потребителя трябва да бъде осигурен свободен достъп до разпределените му компютърни ресурси (като мрежи, виртуални дискове, памет, процесорни ядра и др.), като тези ресурси трябва да се предоставят автоматично – тоест без намеса от страна на доставчика на услугата.
Широка наличност на услугата. Достъпът до ресурсите трябва да се осигурява по стандартни механизми, за да могат да се използват както стандартни компютри, така и тънки клиенти и мобилни устройства.
Комбиниране на ресурси в пулове. Пуловете от ресурси трябва да предоставят ресурси на множество клиенти едновременно, като гарантират, че клиентите са изолирани и не си пречат един на друг и не се конкурират за ресурси. Мрежите също са включени в пуловете, което показва възможността за използване на кръстосано адресиране. Пуловете трябва да поддържат мащабиране при поискване. Използването на пулове ви позволява да осигурите необходимото ниво на отказоустойчивост на ресурсите и абстракция на физически и виртуални ресурси - на получателя на услугата просто се предоставя наборът от ресурси, който е поискал (къде се намират тези ресурси физически, на колко сървъри и комутатори - клиента не го интересува). Трябва обаче да се вземе предвид фактът, че доставчикът трябва да осигури прозрачно резервиране на тези ресурси.
Бърза адаптация към различни условия. Услугите трябва да бъдат гъвкави - да предоставят ресурси бързо, да ги преразпределят, да добавят или намаляват ресурси по желание на клиента, а клиентът трябва да има усещането, че облачните ресурси са безкрайни. За по-лесно разбиране, например, не виждате предупреждение, че част от вашето дисково пространство е изчезнало в Apple iCloud поради факта, че твърдият диск на сървъра е счупен и дисковете се чупят. Освен това от ваша страна възможностите на тази услуга са почти неограничени - трябват ви 2 TB - няма проблем, платил си и получил. По същия начин можете да дадете пример с Google.Drive или Yandex.Disk.
Възможност за измерване на предоставената услуга. Облачните системи трябва автоматично да контролират и оптимизират консумираните ресурси, докато тези механизми трябва да бъдат прозрачни както за потребителя, така и за доставчика на услуги. Тоест винаги можете да проверите колко ресурси консумирате вие и вашите клиенти.
Струва си да се има предвид фактът, че тези изисквания са в по-голямата си част изисквания за публичен облак, така че за частен облак (т.е. облак, стартиран за вътрешните нужди на компанията), тези изисквания могат да бъдат леко коригирани. Те обаче все още трябва да бъдат изпълнени, в противен случай няма да получим всички предимства на облачните изчисления.
Защо се нуждаем от облак?
Въпреки това, всяка нова или съществуваща технология, всеки нов протокол е създаден за нещо (е, с изключение на RIP-ng, разбира се). Протокол в името на протокола не е необходим на никого (е, с изключение на RIP-ng, разбира се). Логично е облакът да е създаден, за да предоставя някаква услуга на потребителя/клиента. Всички сме запознати с поне няколко облачни услуги, като Dropbox или Google.Docs, и вярвам, че повечето от тях успешно ги използват - например тази статия е написана с помощта на облачната услуга Google.Docs. Но познатите ни облачни услуги са само част от възможностите на облака – по-точно той е само услуга от тип SaaS. Можем да предоставим облачна услуга по три начина: под формата на SaaS, PaaS или IaaS. От каква услуга се нуждаете зависи от вашите желания и възможности.
Нека разгледаме всеки по ред:
Софтуерът като услуга (SaaS) е модел за предоставяне на пълноценна услуга на клиент, например пощенска услуга като Yandex.Mail или Gmail. В този модел на предоставяне на услуги вие, като клиент, всъщност не правите нищо, освен да използвате услугите - тоест не е нужно да мислите за конфигуриране на услугата, нейната устойчивост на грешки или резервиране. Основното нещо е да не компрометирате паролата си, доставчикът на тази услуга ще свърши останалото вместо вас. От гледна точка на доставчика на услугата той носи пълната отговорност за цялата услуга – от сървърния хардуер и хост операционните системи до базата данни и настройките на софтуера.
Платформа като услуга (PaaS) - когато се използва този модел, доставчикът на услуги предоставя на клиента детайл за услугата, например, да вземем уеб сървър. Доставчикът на услуги предостави на клиента виртуален сървър (всъщност набор от ресурси, като RAM / CPU / Storage / Nets и т.н.) и дори инсталира операционната система и необходимия софтуер на този сървър, но клиентът сам конфигурира цялата тази доброта и за изпълнението на услугата отговаря клиента. Доставчикът на услугата, както и в предишния случай, е отговорен за работата на физическото оборудване, хипервайзорите, самата виртуална машина, нейната наличност в мрежата и т.н., но самата услуга вече е извън неговата зона на отговорност.
Инфраструктура като услуга (IaaS) - този подход вече е по-интересен, всъщност доставчикът на услуги предоставя на клиента пълна виртуализирана инфраструктура - тоест някакъв набор (пул) от ресурси, като CPU ядра, RAM, мрежи и т.н. Всичко останало е до клиента - какво иска да прави клиентът с тези ресурси в рамките на разпределения му пул (квота) - не е особено важно за доставчика. Ако клиентът иска да създаде свой собствен vEPC или дори да направи мини оператор и да предоставя комуникационни услуги - няма спор - направете го. При такъв сценарий доставчикът на услуги е отговорен за предоставянето на ресурси, тяхната устойчивост на грешки и наличност, както и за операционната система, която позволява обединяването на тези ресурси и предоставянето им на клиента с възможността да увеличава или намалява ресурсите по всяко време в искането на клиента. Клиентът конфигурира всички виртуални машини и други мишури чрез портала за самообслужване и конзолите, включително присвояването на мрежи (с изключение на външни мрежи).
Какво е OpenStack?
И в трите варианта доставчикът на услуги се нуждае от операционна система, която ще му позволи да създаде облачна инфраструктура. Всъщност при SaaS повече от един отдел отговаря за целия технологичен стек – има отдел, който отговаря за инфраструктурата – тоест той предоставя IaaS на друг отдел, този отдел предоставя SaaS на клиента. OpenStack е една от облачните операционни системи, която ви позволява да съберете куп комутатори, сървъри и системи за съхранение в един ресурсен пул, да разделите този общ пул на подпулове (наематели) и да предоставите тези ресурси на клиенти по мрежата.
OpenStack е облачна операционна система, която ви позволява да контролирате големи групи от изчислителни ресурси, съхранение на данни и мрежови ресурси, които се осигуряват и управляват чрез API, използвайки стандартни механизми за удостоверяване.
С други думи, това е набор от безплатни софтуерни проекти, предназначени да създават облачни услуги (както публични, така и частни) - тоест набор от инструменти, които ви позволяват да комбинирате сървърно и превключващо оборудване в един пул от ресурси, да управлявате тези ресурси, осигуряващи необходимото ниво на отказоустойчивост.
Към момента на писане структурата на OpenStack изглежда така:
Снимката е направена от
Всеки от компонентите, съставляващи OpenStack, изпълнява определена функция. Тази разпределена архитектура ви позволява да включите набора от функционални компоненти, от които се нуждаете, в решението. Въпреки това, някои от компонентите са основни компоненти и премахването им ще доведе до пълна или частична неработоспособност на решението като цяло. Тези компоненти обикновено се наричат:
- Табло - Уеб базиран GUI за управление на OpenStack услуги
- Крайъгълен камък - централизирана услуга за идентификация, която предоставя функционалност за удостоверяване и оторизация за други услуги, както и управление на потребителските идентификационни данни и техните роли.
- неутрон - мрежова услуга, която осигурява свързаност между интерфейсите на различни OpenStack услуги (включително свързаност между виртуални машини и техния достъп до външния свят)
- сгурия - осигурява достъп до блоково съхранение за виртуални машини
- Нов — управление на жизнения цикъл на виртуални машини
- бегъл поглед - хранилище на изображения и моментни снимки на виртуални машини
- Swift - осигурява достъп до обектно съхранение
- Целомер - услуга, която предоставя възможност за събиране на телеметрия и измерване на наличните и консумиращи ресурси
- Топлина — оркестрация въз основа на шаблони за автоматично създаване и предоставяне на ресурси
Можете да видите пълен списък на всички проекти и тяхното предназначение .
Всеки от компонентите на OpenStack е услуга, която отговаря за определена функция и предоставя API за управление на тази функция и взаимодействие с други услуги на облачната операционна система, за да се създаде единна инфраструктура. Например Nova осигурява управление на изчислителни ресурси и API за достъп до конфигурацията на ресурсните данни, Glance осигурява управление на изображения и API за управлението им, Cinder осигурява съхранение на блокове и API за управлението им и т.н. Всички функции са тясно свързани помежду си.
Въпреки това, ако преценим, тогава всички услуги, работещи в OpenStack, в крайна сметка са някаква виртуална машина (или контейнер), свързана към мрежата. Възниква въпросът - защо се нуждаем от толкова много елементи?
Нека преминем през алгоритъма за създаване на виртуална машина и свързването й към мрежата и постоянното хранилище в Openstack.
- Когато създавате заявка за създаване на кола, независимо дали е заявка през Horizon (табло за управление) или заявка през CLI, първото нещо, което се случва, е оторизацията на вашата заявка в Keystone - можете ли да създадете кола, има или правото да използвате тази мрежа, изпълнява ли вашия квотен проект и т.н.
- Keystone удостоверява вашата заявка и генерира маркер за удостоверяване в съобщението за отговор, който ще бъде използван по-късно. След получаване на отговор от Keystone, заявката се изпраща към Nova (nova api).
- Nova-api проверява валидността на вашата заявка, като се свързва с Keystone, използвайки предварително генерирания токен за удостоверяване
- Keystone извършва удостоверяване и предоставя информация за разрешенията и ограниченията въз основа на този токен за удостоверяване.
- Nova-api създава нов VM запис в nova-database и изпраща заявка за създаване на машина към nova-scheduler.
- Nova-scheduler избира хоста (компютър с възел), на който ще бъде разгърната VM въз основа на зададените параметри, тегла и зони. Запис за това и VM ID се записват в nova-database.
- След това nova-scheduler извиква nova-compute с искане за внедряване на екземпляра. Nova-compute извиква nova-conductor, за да получи информация за параметрите на машината (nova-conductor е nova елемент, който действа като прокси сървър между nova-database и nova-compute, ограничавайки броя на заявките към nova-database, за да се избегнат проблеми с намаляване на натоварването на последователността на базата данни).
- Nova-conductor извлича исканата информация от nova-database и я предава на nova-compute.
- След това nova-compute извиква glance, за да получи ID на изображението. Glace валидира заявката в Keystone и връща исканата информация.
- Nova-compute се обажда на neutron за информация относно мрежовите параметри. Подобно на glance, neutron валидира заявката в Keystone, след това създава запис в базата данни (идентификатор на порт и т.н.), създава заявка за създаване на порт и връща исканата информация на nova-compute.
- Nova-compute се обажда на cinder с искане за разпределяне на обем към виртуалната машина. Подобно на glance, cider валидира заявката в Keystone, създава заявка за създаване на обем и връща исканата информация.
- Nova-compute извиква libvirt със заявка за внедряване на виртуална машина с дадените параметри.
Всъщност една привидно проста операция за създаване на проста виртуална машина се превръща в такъв водовъртеж от api извиквания между елементи на облачната платформа. Освен това, както можете да видите, дори посочените по-рано услуги също се състоят от по-малки компоненти, между които се осъществява взаимодействие. Създаването на машина е само малка част от това, което облачната платформа ви позволява да правите - има услуга, която отговаря за балансирането на трафика, услуга, която отговаря за блоковото съхранение, услуга, която отговаря за DNS, услуга, която отговаря за предоставянето на голи сървъри и т.н. Облакът ви позволява да се отнасяте към вашите виртуални машини като към стадо овце (за разлика от виртуализацията). Ако нещо се случи с машината във вашата виртуална среда - възстановявате я от архиви и т.н., докато облачните приложения са изградени така, че виртуалната машина не играе толкова важна роля - виртуалната машина "умря" - тя няма значение - просто е създадена нова кола въз основа на шаблона и, както се казва, отрядът не е забелязал загубата на боец. Естествено, това осигурява наличието на механизми за оркестрация - използвайки Heat шаблони, можете да разгърнете сложна функция, състояща се от десетки мрежи и виртуални машини без никакви проблеми.
Винаги си струва да имате предвид, че няма облачна инфраструктура без мрежа - всеки елемент взаимодейства с други елементи чрез мрежата по един или друг начин. Освен това облакът има абсолютно нестатична мрежа. Естествено, основната мрежа е дори повече или по-малко статична - нови възли и превключватели не се добавят всеки ден, но компонентът на наслагването може и неизбежно ще се променя постоянно - ще се добавят или премахват нови мрежи, ще се появяват нови виртуални машини и стари умирам. И както си спомняте от дефиницията на облака, дадена в самото начало на статията, ресурсите трябва да се разпределят на потребителя автоматично и с най-малко (или по-добре без) намеса от страна на доставчика на услуги. Тоест, типът предоставяне на мрежови ресурси, който сега е под формата на интерфейс под формата на вашия личен акаунт, достъпен чрез http / https и Василий, дежурният мрежов инженер като бекенд, не е облак, дори ако Василий има осем ръце.
Neutron, като мрежова услуга, предоставя API за управление на мрежовата част от облачната инфраструктура. Услугата осигурява здравето и управлението на мрежовата част на Openstack чрез предоставяне на абстрактен слой, наречен Network-as-a-Service (NaaS). Тоест мрежата е същата виртуална измерима единица, като например виртуалните ядра на процесора или количеството RAM.
Но преди да преминем към архитектурата на мрежовата част на OpenStack, нека да разгледаме как работи тази мрежа в OpenStack и защо мрежата е важна и неразделна част от облака.
Така че имаме две ЧЕРВЕНИ клиентски виртуални машини и две ЗЕЛЕНИ клиентски виртуални машини. Да приемем, че тези машини са разположени на два хипервайзора по следния начин:
В момента това е само виртуализация на 4 сървъра и нищо повече, тъй като досега всичко, което направихме, е виртуализация на 4 сървъра, поставяйки ги на два физически сървъра. И въпреки това те дори не са свързани към мрежата.
За да получим облак, трябва да добавим няколко компонента. Първо виртуализираме мрежовата част - трябва да свържем тези 4 машини по двойки, а клиентите искат точно L2 връзка. Можете да използвате превключвателя и да настроите ствол в неговата посока и да разрешите всичко с помощта на linux bridge или за по-напреднали потребители на openvswitch (ще се върнем към него по-късно). Но може да има много мрежи и постоянното натискане на L2 през превключвател не е най-добрата идея - толкова различни отдели, бюро за обслужване, месеци чакане за завършване на приложение, седмици отстраняване на неизправности - в съвременния свят това подходът вече не работи. И колкото по-рано компанията разбере това, толкова по-лесно ще продължи напред. Следователно между хипервайзорите ще изберем L3 мрежа, през която нашите виртуални машини ще комуникират, и върху тази L3 мрежа ще изградим виртуални наслагвани L2 (overlay) мрежи, където ще се движи трафикът на нашите виртуални машини. Капсулирането може да бъде GRE, Geneve или VxLAN. Засега нека се спрем на последното, въпреки че това не е особено важно.
Трябва да намерим някъде VTEP (надявам се, че всички са запознати с терминологията на VxLAN). Тъй като мрежата L3 незабавно напуска нашите сървъри, нищо не ни пречи да поставим VTEP на самите сървъри и OVS (OpenvSwitch) е в състояние да направи това перфектно. В резултат на това получихме следната структура:
Тъй като трафикът между виртуалните машини трябва да бъде разделен, портовете към виртуалните машини ще имат различни vlan номера. Номерът на етикета играе роля само в рамките на един виртуален комутатор, тъй като при капсулиране във VxLAN можем лесно да го премахнем, тъй като ще имаме VNI.
Сега можем да създадем нашите машини и виртуални мрежи за тях без никакви проблеми.
Но какво ще стане, ако клиентът има друга машина, но е в друга мрежа? Имаме нужда от руутване между мрежите. Ще анализираме проста опция, когато се използва централизирано вкореняване - т.е. трафикът се насочва през специални специализирани мрежови възли (е, като правило те се комбинират с контролни възли, така че ще имаме същото).
Изглежда, че няма нищо сложно - правим мостов интерфейс на контролния възел, насочваме трафик към него и оттам го маршрутизираме до където ни трябва. Но проблемът е, че ЧЕРВЕНИЯТ клиент иска да използва мрежата 10.0.0.0/24, а ЗЕЛЕНИЯТ клиент иска да използва мрежата 10.0.0.0/24. Тоест започваме пресичането на адресните пространства. Освен това клиентите не желаят други клиенти да могат да маршрутизират към техните вътрешни мрежи, което е логично. За да разделим мрежите и трафика на тези клиенти, ще разпределим отделно пространство от имена за всеки от тях. Пространството от имена всъщност е копие на мрежовия стек на Linux, тоест клиентите в пространството от имена RED са напълно изолирани от клиентите от пространството от имена GREEN (е, маршрутизирането между тези клиентски мрежи е разрешено чрез пространство от имена по подразбиране или вече на по-високо транспортно оборудване).
Тоест получаваме следната схема:
Тунелите L2 се събират от всички изчислителни възли към контролния. възел, където се намира интерфейсът L3 за тези мрежи, всяка в специално пространство от имена за изолиране.
Забравихме обаче най-важното. Виртуалната машина трябва да предоставя услуга на клиента, тоест да има поне един външен интерфейс, през който да може да се достигне до нея. Тоест трябва да отидем във външния свят. Тук има различни варианти. Нека направим най-простия вариант. Нека добавим клиенти в една мрежа, която ще бъде валидна в мрежата на доставчика и няма да се припокрива с други мрежи. Мрежите също могат да се пресичат и да търсят различни VRF от страната на мрежата на доставчика. Мрежовите данни също ще живеят в пространството на имената на всеки от клиентите. Въпреки това, те все пак ще отидат във външния свят чрез един физически (или връзка, което е по-логично) интерфейс. За да се раздели клиентският трафик, трафикът, който излиза навън, ще бъде VLAN маркиран с етикета, присвоен на клиента.
В резултат на това получихме следната схема:
Разумен въпрос е защо не направите шлюзове на самите изчислителни възли? Това не е голям проблем, още повече, че когато включите разпределения рутер (DVR), той ще работи така. В този сценарий разглеждаме най-простата опция с централизиран шлюз, който се използва по подразбиране в Openstack. За функции с високо натоварване те ще използват както разпределен рутер, така и технологии за ускоряване като SR-IOV и Passthrough, но както казват, това е съвсем различна история. Първо, нека се справим с основната част, а след това ще навлезем в подробностите.
Всъщност нашата схема вече работи, но има няколко нюанса:
- Трябва по някакъв начин да защитим нашите машини, тоест да поставим филтър на интерфейса на комутатора към клиента.
- Направете възможно автоматично получаване на ip адрес от виртуална машина, така че да не се налага всеки път да го въвеждате през конзолата и да предписвате адреса.
Да започнем със защитата на автомобила. За да направите това, можете да използвате баналните iptables, защо не.
Тоест сега нашата топология стана малко по-сложна:
Да отидем по-нататък. Трябва да добавим DHCP сървър. Най-идеалното място за намиране на DHCP сървъри за всеки от клиентите би бил вече споменатият по-горе контролен възел, където се намират пространствата от имена:
Има обаче малък проблем. Какво ще стане, ако всичко се рестартира и цялата информация за наем на DHCP изчезне. Логично е машините да получат нови адреси, което не е много удобно. Има два изхода - или да използвате имена на домейни и да добавите DNS сървър за всеки клиент, тогава адресът няма да е много важен за нас (подобно на мрежовата част в k8s) - но има проблем с външните мрежи, тъй като адресите може да се издава и в тях през DHCP - трябва ви синхронизация с DNS сървъри в облачната платформа и външен DNS сървър, което според мен не е много гъвкаво, но е напълно възможно. Или вторият вариант е да използвате метаданни - тоест да съхранявате информация за адреса, издаден на машината, така че DHCP сървърът да знае кой адрес да издаде на машината, ако машината вече е получила адреса. Вторият вариант е по-прост и по-гъвкав, тъй като ви позволява да запазите допълнителна информация за автомобила. Сега нека добавим метаданните на агента към схемата:
Друг въпрос, който също си струва да се посвети, е възможността за използване на една външна мрежа от всички клиенти, тъй като външните мрежи, ако трябва да са валидни в цялата мрежа, ще бъде трудно - трябва постоянно да избирате и контролирате разпределението на тези мрежи. Възможността за използване на една външна предварително конфигурирана мрежа за всички клиенти ще бъде много полезна при създаване на публичен облак. Това ще опрости разгръщането на машини, тъй като не се налага да се консултираме с адресната база данни и да избираме уникално адресно пространство за външната мрежа на всеки клиент. Освен това можем да предпишем външна мрежа предварително и по време на разгръщането ще трябва само да асоциираме външни адреси с клиентски машини.
И тук NAT идва на помощ - ние просто ще направим възможно клиентите да имат достъп до външния свят през пространството от имена по подразбиране, използвайки NAT превод. Е, тук има малък проблем. Това е добре, ако клиентският сървър действа като клиент, а не като сървър - тоест инициира и не приема връзки. Но при нас ще е обратното. В този случай трябва да направим дестинация NAT, така че когато се получи трафик, контролният възел разбира, че този трафик е предназначен за виртуалната машина A на клиент А, което означава, че трябва да направим NAT транслация от външен адрес, например 100.1.1.1. 10.0.0.1 към вътрешен адрес 100. В този случай, въпреки че всички клиенти ще използват една и съща мрежа, вътрешната изолация е напълно запазена. Тоест трябва да направим dNAT и sNAT на контролния възел. Използвайте една мрежа с разпределение на плаващи адреси или външни мрежи, или и двете наведнъж - това се определя от факта, че искате да го затегнете в облака. Няма да поставяме и плаващи адреси на диаграмата, а ще оставим предварително добавените външни мрежи - всеки клиент има своя собствена външна мрежа (в диаграмата те са посочени като vlan 200 и XNUMX на външния интерфейс).
В резултат на това получихме интересно и в същото време добре обмислено решение, което има известна гъвкавост, но засега няма механизми за устойчивост на грешки.
Първо, имаме само един контролен възел - неговият отказ ще доведе до колапс на всички системи. За да разрешите този проблем, трябва да направите поне кворум от 3 възела. Нека добавим това към диаграмата:
Естествено, всички възли са синхронизирани и когато активният възел излезе, друг възел ще поеме неговите задължения.
Следващият проблем са дисковете на виртуалните машини. В момента те се съхраняват на самите хипервайзори и при проблеми с хипервайзора губим всички данни - и наличието на рейд няма да помогне тук, ако загубим не диска, а целия сървър. За да направим това, трябва да направим услуга, която ще действа като интерфейс за всяко хранилище. Какъв вид хранилище ще бъде, не е особено важно за нас, но трябва да предпази данните ни от повреда както на диска, така и на възела, а може би и на целия шкаф. Тук има няколко варианта - разбира се, има SAN мрежи с Fibre Channel, но нека бъдем честни - FC вече е реликва от миналото - аналог на E1 в транспорта - да, съгласен съм, все още се използва, но само където без него не може. Затова не бих разположил доброволно FC мрежата през 2020 г., знаейки, че има други по-интересни алтернативи. Въпреки, че всеки си мисли и може би има хора, които смятат, че FC с всичките му ограничения е всичко, от което се нуждаем - няма да споря, всеки има собствено мнение. Въпреки това, най-интересното решение според мен е използването на SDS, като Ceph.
Ceph ви позволява да изградите високо достъпно решение за съхранение с куп възможни опции за резервиране, от кодове за паритет (подобно на raid 5 или 6) до пълна репликация на данни на различни дискове, като се вземе предвид местоположението на дисковете в сървърите и сървърите в шкафове и др.
Имате нужда от още 3 възела, за да изградите Ceph. Взаимодействието с хранилището също ще се извършва през мрежата, като се използват услуги за съхранение на блокове, обекти и файлове. Нека добавим памет към схемата:
Забележка: можете също да направите хиперконвергирани изчислителни възли - това е концепцията за комбиниране на няколко функции на един възел - например съхранение + компютър - не разпределяйте специални възли за ceph съхранение. Ще получим същата отказоустойчива схема - тъй като SDS ще запази данните с нивото на резервиране, което сме посочили. Въпреки това, хиперконвергираните възли винаги са компромис - тъй като възелът за съхранение не просто загрява въздуха, както изглежда на пръв поглед (тъй като няма виртуални машини в него) - той изразходва ресурси на процесора за обслужване на SDS (всъщност той прави всичко репликации във фонов режим, възстановяване след повреда на възли, дискове и др.). Тоест ще загубите част от изчислителната мощност на възела, ако го комбинирате със съхранение.
Всички тези неща трябва да бъдат управлявани по някакъв начин - имаме нужда от нещо, чрез което можем да създадем машина, мрежа, виртуален рутер и т.н. За да направите това, добавете услуга към контролния възел, който ще действа като табло за управление - клиентът ще да може да се свързва с този портал чрез http/https и да прави каквото трябва (е, почти).
В резултат на това сега имаме система, устойчива на грешки. Всички елементи на тази инфраструктура трябва да се управляват по някакъв начин. По-рано беше описано, че Openstack е набор от проекти, всеки от които предоставя определена функция. Както виждаме, има повече от достатъчно елементи, които трябва да бъдат конфигурирани и контролирани. Днес ще говорим за мрежовата част.
Неутронна архитектура
В OpenStack Neutron отговаря за свързването на портове на виртуална машина към обща L2 мрежа, осигурявайки маршрутизиране на трафика между виртуални машини, разположени в различни L2 мрежи, както и изходящо маршрутизиране, предоставяйки услуги като NAT, плаващ IP, DHCP и др.
Работата на високо ниво на мрежовата услуга (основна част) може да бъде описана по следния начин.
При стартиране на VM мрежовата услуга:
- Създава порт за тази VM (или портове) и уведомява DHCP услугата за това;
- Създава се ново виртуално мрежово устройство (чрез libvirt);
- VM се свързва към порта(овете), създаден(и) в стъпка 1;
Колкото и да е странно, Neutron се основава на стандартни механизми, познати на всеки, който някога се е гмуркал в Linux - това са пространства от имена, iptables, linux bridges, openvswitch, conntrack и т.н.
Веднага трябва да се изясни, че Neutron не е SDN контролер.
Неутронът се състои от няколко взаимосвързани компонента:
openstack-neutron-сървър е демон, който работи с потребителски заявки чрез API. Този демон не записва никакви мрежови връзки, но предоставя необходимата информация за това на своите добавки, които след това конфигурират желания мрежов елемент. Агентите Neutron на възлите на OpenStack са регистрирани в сървъра Neutron.
Neutron-server всъщност е приложение, написано на python, състоящо се от две части:
- REST услуга
- Neutron Plugin (ядро/услуга)
Услугата REST е предназначена да получава API извиквания от други компоненти (например заявка за предоставяне на някаква информация и т.н.)
Добавките са софтуерни компоненти/модули за добавки, които се извикват при API заявки - тоест присвояването на някакъв вид услуга става чрез тях. Плъгините се делят на два вида - сервизни и root. Като правило root плъгинът е отговорен главно за управлението на адресното пространство и L2 връзките между VM, докато сервизните плъгини вече предоставят допълнителна функционалност, като VPN или FW.
Списъкът с наличните в момента плъгини може да се види например
Може да има няколко приставки за услуги, но може да има само една основна приставка.
openstack-neutron-ml2 е стандартният root плъгин на Openstack. Тази добавка има модулна архитектура (за разлика от предшественика си) и конфигурира мрежовата услуга чрез свързаните към нея драйвери. Ще разгледаме самия плъгин малко по-късно, тъй като всъщност той дава гъвкавостта, която има OpenStack в мрежовата част. Основният плъгин може да бъде заменен (например Contrail Networking прави такава замяна).
RPC услуга (rabbitmq-сървър) - услуга, която осигурява управление на опашка и взаимодействие с други OpenStack услуги, както и взаимодействие между агенти на мрежови услуги.
мрежови агенти - агенти, които се намират във всеки възел, чрез който се конфигурират мрежовите услуги.
Агентите са няколко вида.
Основният агент е L2 агент. Тези агенти работят на всеки от хипервайзорите, включително контролни възли (по-точно на всички възли, които предоставят някаква услуга за наематели) и основната им функция е да свързват виртуални машини към обща L2 мрежа, както и да генерират предупреждения при възникване на някакви събития (например деактивиране/разрешаване на порта).
Следващият не по-малко важен агент е L3 агент. По подразбиране този агент работи изключително на мрежов възел (често мрежовият възел се комбинира с контролен възел) и осигурява маршрутизиране между мрежите на наематели (както между своите мрежи, така и мрежите на други наематели и е достъпен за външния свят, осигурявайки NAT , както и DHCP услуга). Въпреки това, когато използвате DVR (разпределен рутер), необходимостта от L3 плъгин се появява и на изчислителните възли.
Агентът L3 използва пространства от имена на Linux, за да предостави на всеки клиент набор от свои собствени изолирани мрежи и функционалността на виртуални рутери, които насочват трафика и предоставят услуги за шлюз за мрежи от слой 2.
База данни - база данни с идентификатори за мрежи, подмрежи, портове, пулове и др.
Всъщност Neutron приема API заявки от създаването на всякакви мрежови обекти, удостоверява заявката и чрез RPC (ако се отнася до някакъв вид плъгин или агент) или REST API (ако комуникира в SDN) предава на агентите (чрез добавки) инструкциите, необходими за организиране на исканата услуга.
Сега нека се обърнем към тестовата инсталация (как се разполага и какво съдържа, ще видим по-късно в практическата част) и да видим къде кой компонент се намира:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$
Всъщност това е цялата структура на Neutron. Сега си струва да отделите малко време за приставката ML2.
Модулен слой 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 преминава под тяхна юрисдикция - Neutron дава команди на контролера чрез 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, които трябва да знаете:
- Модул на ядрото - компонент, разположен в пространството на ядрото, който обработва трафик въз основа на правилата, получени от контролния елемент;
- vSwitch daemon (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, но всичко е разгърнато с помощта само на една мрежа. Наличието или отсъствието на изолация на мрежата обаче не засяга основната функционалност на решението - всичко ще работи точно както при използване на изолация, но трафикът ще върви в същата мрежа. За комерсиална инсталация е естествено необходимо да се използва изолация с помощта на различни vlan и интерфейси. Например трафикът за управление на съхранение на ceph и директният трафик на данни (машинни достъпи до дискове и т.н.) използват различни подмрежи (управление на съхранение и съхранение) по време на изолация и това ви позволява да направите решението по-устойчиво на грешки, като разделите този трафик, за например в различни портове или използвайте различни QoS профили за различен трафик, така че трафикът на данни да не изтласква сигналния трафик. В нашия случай те ще ходят в една и съща мрежа и всъщност това не ни ограничава по никакъв начин.
Забележка: Тъй като ще стартираме виртуални машини в среда, базирана на виртуална машина, първо трябва да активираме вложена виртуализация.
Можете да проверите дали вложената виртуализация е активирана или не по този начин:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Ако видите буквата N, активирайте поддръжката за вложена виртуализация според всяко ръководство, което намерите в мрежата, например .
Трябва да сглобим следната схема от виртуални машини:
В моя случай, за свързаността на виртуалните машини, които са част от бъдещата инсталация (и имам 7 от тях, но можете да минете и с 4, ако нямате много ресурси), използвах OpenvSwitch. Създадох един ovs мост и свързах виртуални машини към него чрез групи портове. За да направя това, създадох xml файл със следната форма:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Тук са декларирани три групи портове - две за достъп и една trunk (последната беше необходима за DNS сървъра, но можете да го направите без него или да го повдигнете на хост машината - което ви е по-удобно). След това, използвайки този шаблон, ние декларираме нашите чрез virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Сега редактираме конфигурацията на портовете на хипервизора:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Забележка: в този сценарий адресът на порта ovs-br1 няма да бъде достъпен, тъй като няма 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Сега посочваме пълното име на undercloud във файла hosts:
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. Използвах изданието на Queen, но вие можете да използвате каквото искате.
След това копирайте конфигурационния файл на 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 сървъра, трябва да съответства на записа на DNS сървъра
локален_ip - локален подземен облак на адреси към осигуряване на мрежа
мрежов_шлюз - същият локален адрес, който ще действа като шлюз за достъп до външния свят по време на инсталирането на overcloud възли, също съответства на локалния ip
undercloud_public_host - външен API адрес, присвоява се всеки свободен адрес от мрежата за осигуряване
undercloud_admin_host адрес на вътрешния API, се присвоява всеки свободен адрес от мрежата за осигуряване
undercloud_name servers - DNS сървър
генериране_услуга_сертификат - този ред е много важен в настоящия пример, защото ако не го зададете на false, ще получите грешка при инсталиране, проблемът е описан в програмата за проследяване на грешки на Red Hat
локален_интерфейс интерфейс към мрежата за осигуряване. Този интерфейс ще бъде преконфигуриран по време на внедряването на Undercloud, така че трябва да имате два интерфейса на Undercloud - един за достъп до него, вторият за осигуряване
local_mtu — MTU. Тъй като имаме тестова лаборатория и имам MTU 1500 на OVS портовете на комутатора, е необходимо да го настроя на 1450, за да преминат пакетите, капсулирани във VxLAN
network_cidr — мрежа за осигуряване
бал с маски - използване на NAT за достъп до външна мрежа
маскарадна_мрежа - мрежа, която ще бъде NAT-Xia
dhcp_start - началния адрес на адресния пул, от който адресите ще бъдат присвоени на възлите по време на разгръщането на overcloud
dhcp_end - краен адрес на адресния пул, от който адресите ще бъдат присвоени на възли по време на внедряването на overcloud
инспекция_iprange - набор от адреси, необходими за интроспекция (не трябва да се припокрива с горния набор)
планиращ_максимални_опити - максималният брой опити за инсталиране на overcloud (трябва да бъде по-голям или равен на броя на възлите)
След като файлът е описан, можете да подадете команда за разгръщане на undercloud:
openstack undercloud install
Процедурата отнема от 10 до 30 минути в зависимост от вашето желязо. В крайна сметка трябва да видите резултат като този:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Този изход казва, че сте инсталирали успешно undercloud и сега можете да проверите състоянието на undercloud и да преминете към инсталиране на overcloud.
Ако погледнете изхода на ifconfig, ще видите, че се е появил нов мостов интерфейс
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Чрез този интерфейс сега ще се работи за внедряване на overcloud.
От резултата по-долу можете да видите, че имаме всички услуги на един и същи възел:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+По-долу е конфигурацията на подоблачната мрежова част:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$overcloud инсталация
В момента имаме само подоблак и нямаме достатъчно възли, от които да се изгради надоблакът. Следователно, първата стъпка е да разположим виртуалните машини, от които се нуждаем. По време на разгръщането самият undercloud ще инсталира операционната система и необходимия софтуер на overcloud на машината - тоест не е нужно да разгръщаме напълно машината, а само да създадем диск (или дискове) за нея и да определим нейните параметри - тоест всъщност получаваме гол сървър без инсталирана на него ОС.
Отидете в папката с дисковете на нашите виртуални машини и създайте дискове с необходимия размер:
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, за да управлява сървъри по време на инсталация и интроспекция.
Интроспекцията е процес на проверка на хардуера, за да се получат неговите параметри, необходими за по-нататъшно осигуряване на възел. Интроспекцията се извършва с помощта на ironic, услуга, предназначена да работи с голи метални сървъри.
Но тук е проблемът - ако IPMI iron сървърите имат отделен порт (или споделен порт, но това не е важно), тогава виртуалните машини нямат такива портове. Тук на помощ ни идва патерица, наречена 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, добавихме необходимия пакет ipmitool към подоблака по време на подготовката за внедряването:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningКакто можете да видите, ние успешно стартирахме контролния възел чрез vbmc. Сега го изключете и продължете напред:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Следващата стъпка е интроспекцията на възлите, върху които ще бъде поставен свръхоблакът. За да направим това, трябва да подготвим json файл с описание на нашите възли. Моля, обърнете внимание, че за разлика от инсталирането на голи сървъри, файлът указва порта, на който се изпълнява vbmc за всяка от машините.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Забележка: има два интерфейса на контролния възел, но в този случай това няма значение, в тази инсталация един е достатъчен за нас.
Сега подготвяме json файла. Трябва да посочим poppy адреса на порта, през който ще се извършва осигуряването, параметрите на възлите, да им дадем имена и да посочим как да стигнем до 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 ~]$Ако всичко е правилно, даваме командата за разгръщане на overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuПри реална инсталация те естествено ще използват персонализирани шаблони, в нашия случай това значително ще усложни процеса, тъй като ще е необходимо да се обяснява всяка редакция в шаблона. Както беше написано по-рано, дори една проста инсталация ще бъде достатъчна, за да видим как работи.
Забележка: Променливата 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 ~]$Сега имате почти пълноценна версия на отворения стек, върху която можете да учите, експериментирате и т.н.
Нека проверим дали всичко работи добре. Има два файла в стека на домашната директория на потребителя - един stackrc (за управление на подоблак) и вторият overcloudrc (за управление на облак). Тези файлове трябва да бъдат посочени като източник, защото съдържат информация, необходима за удостоверяване.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$Моята инсталация все още се нуждае от едно малко докосване - да добавя маршрут на контролера, тъй като машината, с която работя, е в друга мрежа. За да направите това, отидете на control-1 под акаунта на heat-admin и напишете маршрута
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Е, сега можете да отидете до хоризонта. Цялата информация - адреси, потребителско име и парола - се намират във файла /home/stack/overcloudrc. Крайната схема изглежда така:
Между другото, в нашата инсталация машинните адреси бяха издадени чрез DHCP и както можете да видите, те се издават „както и да е“. Можете да кодирате твърдо в шаблона кой адрес трябва да бъде прикачен към коя машина по време на внедряването, ако имате нужда от това.
Как протича трафикът между виртуалните машини?
В тази статия ще разгледаме три варианта за преминаване на трафик
- Две машини на един хипервайзор в една L2 мрежа
- Две машини на различни хипервайзори в една и съща L2 мрежа
- Две машини в различни мрежи (междумрежово руутване)
Случаите с достъп до външния свят през външна мрежа, използвайки плаващи адреси, както и разпределено маршрутизиране, ще бъдат разгледани следващия път, засега ще се съсредоточим върху вътрешния трафик.
За да тестваме, нека съставим следната схема:
Създадохме 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 |
(надоблак) [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 тунели, може да се види, че единият тунел е повдигнат на compute-1 (192.168.255.26), вторият тунел гледа към control-1 (192.168.255.15). Но най-интересното е, че br-ex няма физически интерфейси и ако погледнете кои потоци са конфигурирани, можете да видите, че този мост може да намали трафика само в момента.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Както се вижда от изхода, адресът се завинтва директно към физическия порт, а не към интерфейса на виртуалния мост.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$
Според първото правило всичко, което идва от phy-br-ex порта, трябва да се изхвърли.
Всъщност все още няма друго място за получаване на трафик към този мост, освен от този интерфейс (връзка с br-int) и съдейки по капките, BUM трафикът вече е пристигнал в моста.
Тоест трафикът от този възел може да тръгва само през VxLAN тунела и нищо друго. Ако обаче включите DVR, ситуацията ще се промени, но ще се занимаваме с това друг път. Когато използвате мрежова изолация, например, използвайки vlan, вие няма да имате един L3 интерфейс в 0th vlan, а няколко интерфейса. Обаче 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, тъй като няма смисъл. Когато използвате мрежова изолация - този възел ще има два интерфейса (физически портове, bodns или само два vlan-а - няма значение - зависи какво искате) - единият за контрол, вторият за трафик (запис на VM диска , четене от диск и др.).
Разбрахме какво имаме на възлите при липса на услуги. Сега нека стартираме 4 виртуални машини и да видим как се променя описаната по-горе схема - трябва да имаме портове, виртуални рутери и т.н.
Засега нашата мрежа изглежда така:
Имаме две виртуални машини на всеки компютърен възел. Използвайки compute-0 като пример, нека видим как всичко е включено.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Машината има само един виртуален интерфейс - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Този интерфейс изглежда в linux bridge:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Както можете да видите от изхода, има само два интерфейса в моста - tap95d96a75-a0 и qvb95d96a75-a0.
Тук си струва да се спрем малко на типовете виртуални мрежови устройства в OpenStack:
vtap е виртуален интерфейс, прикрепен към екземпляр (VM)
qbr - Линукс мост
qvb и qvo - двойка vEth, свързана към Linux мост и Open vSwitch мост
br-int, br-tun, br-vlan - Отваряне на vSwitch мостове
patch-, int-br-, phy-br- — Open vSwitch patch интерфейси, свързващи мостове
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 се вижда в изхода. Това е порт към втората виртуална машина. В резултат нашата схема сега изглежда така:
Въпросът, който веднага трябва да заинтересува внимателния читател, е какъв линукс мост е между порта на виртуалната машина и порта OVS? Факт е, че групите за сигурност се използват за защита на машината, които не са нищо повече от iptables. OVS не работи с iptables, така че е измислена такава „патерица“. Той обаче остарява - той е заменен от conntrack в новите версии.
Тоест в крайна сметка схемата изглежда така:
Две машини на един хипервайзор в една L2 мрежа
Тъй като тези две виртуални машини са в една и съща L2 мрежа и на един и същ хипервайзор, ще бъде логично трафикът между тях да преминава локално през br-int, тъй като и двете машини ще бъдат в една и съща VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Две машини на различни хипервайзори в една и съща L2 мрежа
Сега нека видим как ще върви трафикът между две машини в една и съща L2 мрежа, но разположени на различни хипервайзори. Честно казано, нищо няма да се промени много, просто трафикът между хипервайзорите ще минава през тунела vxlan. Нека разгледаме един пример.
Адреси на виртуални машини, между които ще наблюдаваме трафика:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Разглеждаме таблицата за пренасочване в br-int на compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Трафикът трябва да отива към порт 2 - вижте какъв порт е:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$Това е patch-tun - тоест интерфейсът в br-tun. Нека да видим какво се случва с пакета на br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Пакетът се пакетира във VxLAN и се изпраща до порт 2. Ние гледаме накъде води порт 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Това е тунелът vxlan на compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Отиваме на compute-1 и виждаме какво ще се случи след това с пакета:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Макът е в таблицата за пренасочване br-int на compute-1 и както можете да видите от изхода по-горе, той се вижда през порт 2, който е портовете към br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Е, тогава виждаме, че има целеви мак в br-int на compute-1:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ Тоест полученият пакет ще лети до порт 3, зад който вече има екземпляр на виртуална машина-00000003.
Красотата на внедряването на Openstack за изучаване на виртуална инфраструктура е, че можем лесно да уловим трафика между хипервайзорите и да видим какво ще се случи с него. Ето какво ще направим сега, стартираме tcpdump на порта vnet към compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Първият ред показва, че пакетът от адрес 10.0.1.85 отива на адрес 10.0.1.88 (ICMP трафик) и е обвит във VxLAN пакет с vni 22 и пакетът отива от хост 192.168.255.19 (compute-0) към хост 192.168.255.26 (изчисляване-1). Можем да проверим дали VNI съвпада с посочения в ovs.
Нека се върнем към този ред actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 е vni в шестнадесетична бройна система. Нека преобразуваме това число в 16-та система:
16 = 6*16^0+1*16^1 = 6+16 = 22Тоест vni е вярно.
Вторият ред показва обратен трафик, добре, няма смисъл да го обясняваме там и така всичко е ясно.
Две машини в различни мрежи (маршрутизиране между мрежи)
Последният случай за днес е маршрутизирането между мрежи в рамките на един и същ проект с помощта на виртуален рутер. Разглеждаме случая без DVR (ще го разгледаме в друга статия), така че маршрутизирането се извършва на мрежовия възел. В нашия случай мрежовият възел не е отделен обект и се намира на контролния възел.
Първо, нека видим дали маршрутизирането работи:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msТъй като в този случай пакетът трябва да отиде до шлюза и да бъде маршрутизиран там, трябва да намерим поп адреса на шлюза, за което ще разгледаме ARP таблицата в примера:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Сега нека видим къде трябва да бъде изпратен трафикът с дестинацията (10.0.1.254) fa:16:3e:c4:64:70:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Гледаме накъде води порт 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Всичко е логично, трафикът отива към br-tun. Да видим в кой vxlan тунел ще бъде увит:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ Третият порт е тунелът vxlan:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Което разглежда контролния възел:
[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 и интерфейси бяха добавени към възлите. Създаването на мрежи и виртуален рутер също остави своя отпечатък върху конфигурацията на контролния възел.
Така че очевидно адресът на шлюза трябва да бъде в таблицата за пренасочване 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. Нека проверим MAC адреса на порта qr-0c52b15f-8f, тъй като трафикът, съдейки по целевия MAC адрес, отиде към този интерфейс.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Тоест в този случай всичко работи според законите на стандартното маршрутизиране. Тъй като трафикът е предназначен за хост 10.0.2.8, той трябва да излезе през втория интерфейс qr-92fa49b5-54 и да премине през тунела vxlan към изчислителния възел:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ Всичко е логично, без изненади. Гледаме откъде се вижда мак адресът на хоста 10.0.2.8 в br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Както се очаква, трафикът отива към br-tun, нека видим към кой тунел ще отиде трафикът след това:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Трафикът отива в тунела за изчисляване-1. Е, на compute-1 всичко е просто - от br-tun пакетът стига до br-int и оттам до интерфейса на виртуалната машина:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ Нека проверим дали това наистина е правилният интерфейс:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$
Всъщност ние изминахме целия път на пакета. Мисля, че забелязахте, че трафикът преминава през различни vxlan тунели и излиза с различни VNI. Нека видим какво представляват VNI, след което ще съберем дъмп на контролния порт на възела и ще се уверим, че трафикът върви точно както е описано по-горе.
Така че тунелът за изчисляване-0 има следните действия=зареждане:0->NXM_OF_VLAN_TCI[],зареждане:0x16->NXM_NX_TUN_ID[],изход:3. Нека преведем 0x16 в десетичната бройна система:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Тунелът за compute-1 има следния VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Нека преведем 0x63 в десетичната бройна система:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Е, сега да видим дъмпа:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************Първият пакет е vxlan пакет от хост 192.168.255.19 (compute-0) до хост 192.168.255.15 (control-1) с vni 22, вътре в който е пакетиран ICMP пакет от хост 10.0.1.85 до хост 10.0.2.8. Както изчислихме по-горе, vni съвпада с това, което видяхме в изхода.
Вторият пакет е vxlan пакет от хост 192.168.255.15 (control-1) до хост 192.168.255.26 (compute-1) с vni 99, вътре в който е пакетиран ICMP пакет от хост 10.0.1.85 до хост 10.0.2.8. Както изчислихме по-горе, vni съвпада с това, което видяхме в изхода.
Следващите два пакета са обратен трафик от 10.0.2.8, а не от 10.0.1.85.
Това означава, че в крайна сметка получихме следната схема на контролния възел:
Изглежда, че това е? Забравихме за две пространства от имена:
[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 за ИТ облака (леки натоварвания, удобно управление), OpenStack от някой доставчик (Nokia и Juniper предоставят много добри решения до ключ) - за облака на Telecom. Не бих използвал 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