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