Bulutli hisoblash hayotimizga tobora chuqurroq kirib bormoqda va hech bo'lmaganda bir marta bulut xizmatlaridan foydalanmagan odam yo'q. Biroq, bulut nima va u qanday ishlaydi, hatto g'oya darajasida ham kam odam biladi. 5G allaqachon haqiqatga aylanmoqda va telekommunikatsiya infratuzilmasi to'liq apparatli yechimlardan virtuallashtirilgan "ustunlar" ga o'tganda bo'lgani kabi, ustunli echimlardan bulutli echimlarga o'tishni boshladi.
Bugun biz bulutli infratuzilmaning ichki dunyosi haqida gapiramiz, xususan, tarmoq qismining asoslarini ko'rib chiqamiz.
Bulut nima? Xuddi shu virtualizatsiya - profil ko'rinishi?
Mantiqiy savoldan ko'ra ko'proq. Yo'q - bu virtualizatsiya emas, garchi usiz amalga oshirib bo'lmasdi. Keling, ikkita ta'rifni ko'rib chiqaylik:
Bulutli hisoblash (bundan buyon matnda bulut deb yuritiladi) xizmat ko'rsatuvchi provayder uchun eng past kechikish va minimal xarajatlar bilan talab bo'yicha joylashtirilishi va ishga tushirilishi kerak bo'lgan taqsimlangan hisoblash resurslariga foydalanuvchilarga qulay kirishni ta'minlash modelidir.
Virtualizatsiya - bu bitta jismoniy ob'ektni (masalan, serverni) bir nechta virtuallarga bo'lish va shu bilan resurslardan foydalanishni oshirish qobiliyatidir (masalan, sizda 3 ta server 25-30 foizga yuklangan edi, virtualizatsiyadan so'ng siz 1 ta server yuklangan bo'lasiz. 80-90 foiz). Tabiiyki, virtualizatsiya resurslarning bir qismini iste'mol qiladi - siz gipervisorni boqishingiz kerak, ammo amaliyot shuni ko'rsatadiki, o'yin shamga arziydi. Virtualizatsiyaning ideal namunasi - virtual mashinalarni mukammal tayyorlaydigan VMWare yoki men afzal ko'rgan KVM, ammo bu ta'mga bog'liq.
Biz virtualizatsiyadan o‘zimiz sezmagan holda foydalanamiz va hatto temir routerlar allaqachon virtualizatsiyadan foydalanmoqda – masalan, JunOS’ning so‘nggi versiyasida operatsion tizim real vaqtda Linux distribyutsiyasi (Wind River 9) ustiga virtual mashina sifatida o‘rnatilgan. Ammo virtualizatsiya bulut emas, lekin bulut virtualizatsiyasiz mavjud bo'lolmaydi.
Virtualizatsiya bulut qurilgan qurilish bloklaridan biridir.
Bitta L2 domeniga bir nechta gipervisorlarni yig'ish, vlanlarni avtomatik ravishda ro'yxatdan o'tkazish uchun bir nechta yaml o'yin kitoblarini qo'shish va virtual mashinalarni avtomatik yaratish uchun orkestratsiya tizimi kabi narsalarni tiqilib qolish orqali bulut yaratish ishlamaydi. Bu aniqroq bo'ladi, lekin natijada paydo bo'lgan Frankenshteyn bizga kerak bo'lgan bulut emas, garchi u boshqalar uchun eng yaxshi orzu bo'lishi mumkin. Bundan tashqari, agar siz xuddi shu Openstack-ni olsangiz, bu hali ham Frankenshteyn, ammo hozircha bu haqda gapirmaylik.
Ammo men tushunamanki, yuqorida keltirilgan ta'rifdan aslida bulutni nima deb atash mumkinligi to'liq aniq emas.
Shunday qilib, NIST (Milliy standartlar va texnologiyalar instituti) hujjati bulut infratuzilmasi ega bo'lishi kerak bo'lgan 5 ta asosiy xususiyatni taqdim etadi:
So'rov bo'yicha xizmat ko'rsatish. Foydalanuvchiga o'ziga ajratilgan kompyuter resurslaridan (tarmoqlar, virtual disklar, xotira, protsessor yadrolari va boshqalar) erkin foydalanish imkoniyati berilishi kerak va bu resurslar avtomatik ravishda - ya'ni xizmat ko'rsatuvchi provayderning aralashuvisiz taqdim etilishi kerak.
Xizmatning keng mavjudligi. Resurslarga kirish standart shaxsiy kompyuterlar va nozik mijozlar va mobil qurilmalardan foydalanishga ruxsat berish uchun standart mexanizmlar bilan ta'minlanishi kerak.
Resurslarni hovuzlarga birlashtirish. Resurs pullari bir vaqtning o'zida bir nechta mijozlarni resurslar bilan ta'minlashi kerak, bu mijozlar izolyatsiya qilinganligini va o'zaro ta'sir va resurslar uchun raqobatdan xoli bo'lishini ta'minlashi kerak. Tarmoqlar ham hovuzlarga kiritilgan, bu bir-birining ustiga chiqadigan manzillardan foydalanish imkoniyatini ko'rsatadi. Hovuzlar talabga ko'ra o'lchab turishi kerak. Hovuzlardan foydalanish resurslarning nosozliklarga chidamliligi va jismoniy va virtual resurslarning abstraktsiyasining zarur darajasini ta'minlashga imkon beradi - xizmatni oluvchiga u so'ragan resurslar to'plami taqdim etiladi (bu resurslar jismoniy jihatdan qayerda joylashganligi, qanchaligi haqida) serverlar va kalitlar - mijoz uchun bu muhim emas). Biroq, biz provayder ushbu resurslarning shaffof zaxirasini ta'minlashi kerakligini hisobga olishimiz kerak.
Turli sharoitlarga tez moslashish. Xizmatlar moslashuvchan bo'lishi kerak - resurslarni tezkor ta'minlash, ularni qayta taqsimlash, mijozning iltimosiga binoan resurslarni qo'shish yoki kamaytirish, mijoz tomonidan esa bulutli resurslar cheksiz ekanligi hissi paydo bo'lishi kerak. Tushunish uchun qulaylik uchun, masalan, Apple iCloud-da disk maydonining bir qismi yo'qolganligi haqida ogohlantirishni ko'rmaysiz, chunki serverdagi qattiq disk buzilgan va drayvlar buziladi. Bundan tashqari, siz tomondan ushbu xizmatning imkoniyatlari deyarli cheksizdir - sizga 2 TB kerak - muammo yo'q, siz uni to'ladingiz va qabul qildingiz. Shunga o'xshash misol Google.Drive yoki Yandex.Disk bilan berilishi mumkin.
Taqdim etilgan xizmatni o'lchash imkoniyati. Bulutli tizimlar iste'mol qilinadigan resurslarni avtomatik ravishda boshqarishi va optimallashtirishi kerak va bu mexanizmlar ham foydalanuvchi, ham xizmat ko'rsatuvchi provayder uchun shaffof bo'lishi kerak. Ya'ni, siz va mijozlaringiz qancha resurslarni iste'mol qilayotganini har doim tekshirishingiz mumkin.
Shuni hisobga olish kerakki, ushbu talablar asosan umumiy bulutga qo'yiladigan talablardir, shuning uchun shaxsiy bulut uchun (ya'ni kompaniyaning ichki ehtiyojlari uchun ishga tushirilgan bulut) bu talablar biroz sozlanishi mumkin. Biroq, ular hali ham bajarilishi kerak, aks holda biz bulutli hisoblashning barcha afzalliklarini olmaymiz.
Nega bizga bulut kerak?
Biroq, har qanday yangi yoki mavjud texnologiya, har qanday yangi protokol biror narsa uchun yaratiladi (yaxshi, RIP-ngdan tashqari, albatta). Protokol uchun protokol hech kimga kerak emas (yaxshi, albatta, RIP-ngdan tashqari). Bulutli foydalanuvchi/mijoz uchun qandaydir xizmatlarni taqdim etish uchun yaratilganligi mantiqan to'g'ri. Biz hammamiz kamida bir nechta bulut xizmatlarini yaxshi bilamiz, masalan, Dropbox yoki Google.Docs va ko'pchilik ulardan muvaffaqiyatli foydalanishiga ishonaman - masalan, ushbu maqola Google.Docs bulut xizmatidan foydalangan holda yozilgan. Ammo biz biladigan bulut xizmatlari bulut imkoniyatlarining faqat bir qismi, aniqrog'i, ular faqat SaaS tipidagi xizmatdir. Biz bulut xizmatini uchta usulda taqdim etishimiz mumkin: SaaS, PaaS yoki IaaS shaklida. Sizga qanday xizmat kerakligi sizning xohishingiz va imkoniyatlaringizga bog'liq.
Keling, har birini tartibda ko'rib chiqaylik:
Dasturiy ta'minot sifatida (SaaS) mijozga to'liq huquqli xizmatni taqdim etish modelidir, masalan, Yandex.Mail yoki Gmail kabi elektron pochta xizmati. Xizmatni taqdim etishning ushbu modelida siz mijoz sifatida xizmatlardan foydalanishdan boshqa hech narsa qilmaysiz, ya'ni xizmatni sozlash, uning nosozliklarga chidamliligi yoki ortiqchaligi haqida o'ylashingiz shart emas. Asosiysi, parolingizni buzmaslik, qolganini ushbu xizmat provayderi bajaradi. Xizmat ko'rsatuvchi provayder nuqtai nazaridan u butun xizmat uchun to'liq javobgardir - server apparati va xost operatsion tizimlaridan ma'lumotlar bazasi va dasturiy ta'minot sozlamalarigacha.
Xizmat sifatida platforma (PaaS) — ushbu modeldan foydalanganda xizmat ko'rsatuvchi provayder mijozga xizmat uchun ish qismini taqdim etadi, masalan, veb-serverni olaylik. Xizmat ko'rsatuvchi provayder mijozni virtual server bilan ta'minladi (aslida, RAM/CPU/Storage/Nets kabi resurslar to'plami va h.k.) va hatto ushbu serverga OS va kerakli dasturiy ta'minotni o'rnatdi, ammo konfiguratsiya Bularning barchasi mijozning o'zi tomonidan amalga oshiriladi va mijoz javob beradigan xizmatni bajarish uchun. Xizmat ko'rsatuvchi provayder, avvalgi holatda bo'lgani kabi, jismoniy uskunalar, gipervizorlar, virtual mashinaning o'zi, tarmoq mavjudligi va boshqalar uchun javobgardir, ammo xizmatning o'zi endi uning mas'uliyat sohasiga kirmaydi.
Xizmat sifatida infratuzilma (IaaS) - bu yondashuv allaqachon qiziqroq, aslida xizmat ko'rsatuvchi provayder mijozni to'liq virtuallashtirilgan infratuzilma bilan ta'minlaydi - ya'ni protsessor yadrolari, operativ xotira, tarmoqlar va boshqalar kabi resurslarning ba'zi to'plami (hovuzi). mijoz - mijoz ajratilgan hovuz (kvota) doirasida ushbu resurslar bilan nima qilishni xohlaydi - bu etkazib beruvchi uchun ayniqsa muhim emas. Mijoz o'zining vEPC-ni yaratmoqchimi yoki hatto mini operatorni yaratmoqchimi va aloqa xizmatlarini ko'rsatmoqchimi - shubhasiz - buni qiling. Bunday stsenariyda xizmat ko'rsatuvchi provayder resurslarni ta'minlash, ularning xatolarga chidamliligi va mavjudligi, shuningdek, ushbu resurslarni birlashtirish va ularni istalgan vaqtda resurslarni ko'paytirish yoki kamaytirish imkoniyati bilan mijozga taqdim etish imkonini beruvchi OS uchun javobgardir. mijozning iltimosiga binoan. Mijoz o'z-o'ziga xizmat ko'rsatish portali va konsoli orqali barcha virtual mashinalarni va boshqa tinsellarni o'zi sozlaydi, shu jumladan tarmoqlarni sozlash (tashqi tarmoqlardan tashqari).
OpenStack nima?
Barcha uchta variantda xizmat ko'rsatuvchi provayderga bulutli infratuzilmani yaratish imkonini beruvchi OT kerak. Haqiqatan ham, SaaS bilan bir nechta bo'linmalar butun texnologiyalar to'plami uchun javobgardir - infratuzilma uchun mas'ul bo'lgan bo'linma mavjud - ya'ni u boshqa bo'limga IaaS beradi, bu bo'lim mijozga SaaS ni taqdim etadi. OpenStack - bu bulutli operatsion tizimlardan biri bo'lib, u sizga bir nechta kalitlarni, serverlarni va saqlash tizimlarini yagona resurs puliga to'plash, ushbu umumiy hovuzni subpoollarga (ijaraga) bo'lish va ushbu resurslarni tarmoq orqali mijozlarga taqdim etish imkonini beradi.
OpenStack bulutli operatsion tizim boʻlib, standart autentifikatsiya mexanizmlari yordamida API orqali taʼminlangan va boshqariladigan katta hajmdagi hisoblash resurslari, maʼlumotlarni saqlash va tarmoq resurslarini boshqarish imkonini beradi.
Boshqacha qilib aytganda, bu bulutli xizmatlarni (ham davlat, ham xususiy) yaratish uchun mo'ljallangan bepul dasturiy ta'minot loyihalari to'plami - ya'ni server va kommutatsiya uskunalarini yagona resurslar puliga birlashtirish, boshqarish imkonini beruvchi vositalar to'plami. bu manbalar, nosozlikka chidamlilikning zarur darajasini ta'minlaydi.
Ushbu materialni yozish paytida OpenStack tuzilishi quyidagicha ko'rinadi:
dan olingan rasm
OpenStack-ga kiritilgan komponentlarning har biri ma'lum bir funktsiyani bajaradi. Ushbu taqsimlangan arxitektura sizga kerakli funktsional komponentlar to'plamini yechimga kiritish imkonini beradi. Biroq, ba'zi komponentlar ildiz komponentlari bo'lib, ularni olib tashlash umuman eritmaning to'liq yoki qisman ishlamasligiga olib keladi. Ushbu komponentlar odatda quyidagilarga bo'linadi:
- Dashboard — OpenStack xizmatlarini boshqarish uchun veb-ga asoslangan GUI
- Keystone boshqa xizmatlar uchun autentifikatsiya va avtorizatsiya funksiyalarini taʼminlovchi, shuningdek, foydalanuvchi hisob maʼlumotlari va ularning rollarini boshqaradigan markazlashtirilgan identifikatsiya xizmatidir.
- Neytron - turli OpenStack xizmatlarining interfeyslari o'rtasida ulanishni ta'minlaydigan tarmoq xizmati (shu jumladan VMlar o'rtasidagi ulanish va ularning tashqi dunyoga kirishi)
- Shlakli — virtual mashinalar uchun saqlash blokiga kirish imkonini beradi
- Novak — virtual mashinalarning hayot aylanishini boshqarish
- Qarang — virtual mashina tasvirlari va oniy tasvirlar ombori
- Swift — saqlash ob'ektiga kirishni ta'minlaydi
- Seilometr — telemetriyani yig'ish va mavjud va iste'mol qilingan resurslarni o'lchash imkoniyatini beruvchi xizmat
- issiqlik — resurslarni avtomatik yaratish va ta'minlash uchun shablonlarga asoslangan orkestratsiya
Barcha loyihalarning to'liq ro'yxati va ularning maqsadlarini ko'rish mumkin .
Har bir OpenStack komponenti muayyan funktsiyani bajaradigan va ushbu funktsiyani boshqarish va yagona infratuzilmani yaratish uchun boshqa bulutli operatsion tizim xizmatlari bilan o'zaro aloqada bo'lish uchun API taqdim etadigan xizmatdir. Masalan, Nova hisoblash resurslarini boshqarish va ushbu resurslarni sozlash uchun API-ni taqdim etadi, Glance tasvirlarni boshqarish va ularni boshqarish uchun API-ni taqdim etadi, Cinder bloklarni saqlash va uni boshqarish uchun API-ni taqdim etadi va hokazo. Barcha funktsiyalar bir-biriga juda yaqin bog'langan.
Biroq, agar siz unga qarasangiz, OpenStack-da ishlaydigan barcha xizmatlar oxir-oqibat tarmoqqa ulangan virtual mashina (yoki konteyner) turidir. Savol tug'iladi - nima uchun bizga juda ko'p elementlar kerak?
Keling, virtual mashinani yaratish va uni tarmoqqa ulash va Openstack-da doimiy saqlash algoritmini ko'rib chiqaylik.
- Mashina yaratish uchun so'rovni yaratganingizda, xoh Horizon (boshqarish paneli) orqali so'rov bo'lsin, xoh CLI orqali so'rov bo'lsin, birinchi bo'lib Keystone-da so'rovingizni avtorizatsiya qilish bo'ladi - siz mashinani yaratishingiz mumkinmi? ushbu tarmoqdan foydalanish huquqi, loyiha kvotasi va boshqalar.
- Keystone so'rovingizni autentifikatsiya qiladi va javob xabarida autentifikatsiya belgisini yaratadi, bundan keyin undan foydalaniladi. Keystonedan javob olgach, so'rov Nova (nova api) ga yuboriladi.
- Nova-api so'rovingiz to'g'riligini Keystone bilan bog'lanib, avval yaratilgan autentlik tokeni yordamida tekshiradi.
- Keystone autentifikatsiyani amalga oshiradi va ushbu autentifikatsiya belgisiga asoslangan ruxsatlar va cheklovlar haqida ma'lumot beradi.
- Nova-api nova-ma'lumotlar bazasida yangi VM uchun yozuv yaratadi va mashinani yaratish so'rovini nova-scheduler-ga uzatadi.
- Nova-scheduler belgilangan parametrlar, vaznlar va zonalar asosida VM joylashtiriladigan xostni (kompyuter tugunini) tanlaydi. Buning yozuvi va VM identifikatori nova-ma'lumotlar bazasiga yoziladi.
- Keyinchalik, nova-scheduler nova-compute bilan bog'lanib, namunani joylashtirish so'rovi bilan. Nova-compute mashina parametrlari haqida ma'lumot olish uchun nova-o'tkazgich bilan aloqa qiladi (nova-o'tkazgich - nova-ma'lumotlar bazasi va nova-compute o'rtasida proksi-server vazifasini bajaradigan nova elementi, ma'lumotlar bazasi bilan bog'liq muammolarni oldini olish uchun nova-ma'lumotlar bazasiga so'rovlar sonini cheklaydi. mustahkamlik yukini kamaytirish).
- Nova-conductor so'ralgan ma'lumotni nova-ma'lumotlar bazasidan oladi va uni nova-computerga uzatadi.
- Keyinchalik, nova-compute tasvir identifikatorini olish uchun qo'ng'iroq qiladi. Glace Keystone-da so'rovni tasdiqlaydi va so'ralgan ma'lumotni qaytaradi.
- Nova-comput tarmoq parametrlari haqida ma'lumot olish uchun neytron bilan aloqa qiladi. Bir qarashga o'xshab, neytron Keystone-da so'rovni tasdiqlaydi, shundan so'ng u ma'lumotlar bazasida (port identifikatori va boshqalar) yozuv yaratadi, port yaratish uchun so'rovni yaratadi va so'ralgan ma'lumotni nova-compute-ga qaytaradi.
- Nova-compute kontaktlari virtual mashinaga ovoz hajmini ajratish so'rovi bilan ajralib turadi. Bir qarashga o'xshab, sidr Keystone-da so'rovni tasdiqlaydi, hajm yaratish so'rovini yaratadi va so'ralgan ma'lumotni qaytaradi.
- Nova-compute ko'rsatilgan parametrlarga ega virtual mashinani joylashtirish so'rovi bilan libvirt bilan aloqa qiladi.
Aslida, oddiy virtual mashinani yaratishning oddiy ko'rinadigan operatsiyasi bulut platformasi elementlari o'rtasida API qo'ng'iroqlarining bunday girdobiga aylanadi. Bundan tashqari, ko'rib turganingizdek, hatto ilgari belgilangan xizmatlar ham o'zaro ta'sir sodir bo'ladigan kichikroq qismlardan iborat. Mashinani yaratish bulutli platforma sizga imkon beradigan narsaning faqat kichik bir qismidir - trafikni muvozanatlash uchun mas'ul bo'lgan xizmat, bloklarni saqlash uchun mas'ul xizmat, DNS uchun mas'ul xizmat, yalang'och metall serverlarni ta'minlash uchun mas'ul xizmat va hk. Bulut sizga virtual mashinalaringizga qo'ylar podasi kabi munosabatda bo'lishingizga imkon beradi (virtualizatsiyadan farqli o'laroq). Agar virtual muhitda mashinangizga biror narsa yuz bersa - siz uni zaxira nusxalaridan tiklaysiz va hokazo, lekin bulutli ilovalar virtual mashina unchalik muhim rol o'ynamaydigan tarzda qurilgan - virtual mashina "o'lgan" - muammo yo'q. - yangisi oddiygina yaratilgan transport vositasi shablonga asoslangan va ular aytganidek, otryad qiruvchining yo'qolganini sezmagan. Tabiiyki, bu orkestr mexanizmlarining mavjudligini ta'minlaydi - Issiqlik shablonlari yordamida siz o'nlab tarmoqlar va virtual mashinalardan iborat murakkab funktsiyani osongina joylashtirishingiz mumkin.
Shuni doimo yodda tutish kerakki, tarmoqsiz bulutli infratuzilma mavjud emas - har bir element u yoki bu tarzda tarmoq orqali boshqa elementlar bilan o'zaro ta'sir qiladi. Bundan tashqari, bulut mutlaqo statik bo'lmagan tarmoqqa ega. Tabiiyki, astarli tarmoq ko'proq yoki kamroq statikdir - har kuni yangi tugunlar va kalitlar qo'shilmaydi, lekin qoplama komponenti doimiy ravishda o'zgarishi mumkin va muqarrar ravishda o'zgaradi - yangi tarmoqlar qo'shiladi yoki o'chiriladi, yangi virtual mashinalar paydo bo'ladi va eskilari paydo bo'ladi. o'lish. Maqolaning boshida berilgan bulut ta'rifidan eslaganingizdek, resurslar foydalanuvchiga avtomatik ravishda va xizmat ko'rsatuvchi provayderning eng kam (yoki undan ham yaxshiroq) aralashuvisiz taqsimlanishi kerak. Ya'ni, hozirda http/https va navbatchi tarmoq muhandisi Vasiliy orqali kirish mumkin bo'lgan shaxsiy hisob ko'rinishidagi front-end shaklida mavjud bo'lgan tarmoq resurslarini taqdim etish turi bulut emas, hattoki. agar Vasiliyning sakkiz qo'li bo'lsa.
Neytron, tarmoq xizmati sifatida, bulutli infratuzilmaning tarmoq qismini boshqarish uchun API taqdim etadi. Xizmat Network-as-a-Service (NaaS) deb nomlangan abstraksiya qatlamini taqdim etish orqali Openstack-ning tarmoq qismini quvvatlaydi va boshqaradi. Ya'ni, tarmoq, masalan, virtual protsessor yadrolari yoki RAM miqdori bilan bir xil virtual o'lchov birligidir.
Ammo OpenStack-ning tarmoq qismi arxitekturasiga o'tishdan oldin, keling, ushbu tarmoq OpenStack-da qanday ishlashini va nima uchun tarmoq bulutning muhim va ajralmas qismi ekanligini ko'rib chiqaylik.
Shunday qilib, bizda ikkita RED mijoz VM va ikkita GREEN mijoz VM mavjud. Faraz qilaylik, bu mashinalar shu tarzda ikkita gipervizorda joylashgan:
Hozirgi vaqtda bu 4 ta serverni virtualizatsiya qilish va boshqa hech narsa emas, chunki biz hozirgacha 4 ta serverni virtualizatsiya qilib, ularni ikkita jismoniy serverga joylashtirdik. Va hozirgacha ular hatto tarmoqqa ulanmagan.
Bulut yaratish uchun biz bir nechta komponentlarni qo'shishimiz kerak. Birinchidan, biz tarmoq qismini virtualizatsiya qilamiz - biz ushbu 4 ta mashinani juftlikda ulashimiz kerak va mijozlar L2 ulanishini xohlashadi. Siz kalitdan foydalanishingiz va magistralni uning yo'nalishi bo'yicha sozlashingiz va hamma narsani Linux ko'prigi yoki yanada rivojlangan foydalanuvchilar uchun openvswitch yordamida hal qilishingiz mumkin (bu haqda keyinroq qaytamiz). Ammo juda ko'p tarmoqlar bo'lishi mumkin va doimiy ravishda L2 ni kommutator orqali bosish eng yaxshi g'oya emas - turli bo'limlar, xizmat ko'rsatish stoli, ariza tugashini kutish oylari, muammolarni bartaraf etish - zamonaviy dunyoda bu yondashuv endi ishlamaydi. Va kompaniya buni qanchalik tez tushunsa, uning oldinga siljishi shunchalik oson bo'ladi. Shuning uchun, gipervisorlar o'rtasida biz virtual mashinalarimiz aloqa qiladigan L3 tarmog'ini tanlaymiz va ushbu L3 tarmog'ining tepasida virtual mashinalarimiz trafigini ishlaydigan virtual L2 qoplamali tarmoqlarni quramiz. Inkapsulyatsiya sifatida GRE, Geneve yoki VxLAN dan foydalanishingiz mumkin. Hozircha ikkinchisiga e'tibor qarataylik, garchi bu unchalik muhim bo'lmasa ham.
Biz VTEPni biror joyda topishimiz kerak (umid qilamanki, hamma VxLAN terminologiyasi bilan yaxshi tanish). Bizda L3 tarmog'i to'g'ridan-to'g'ri serverlardan kelganligi sababli, VTEPni serverlarning o'ziga joylashtirishga hech narsa to'sqinlik qilmaydi va OVS (OpenvSwitch) buni amalga oshirishda juda yaxshi. Natijada biz ushbu dizaynni oldik:
VMlar orasidagi trafikni bo'lish kerakligi sababli, virtual mashinalar portlari turli xil vlan raqamlariga ega bo'ladi. Teg raqami faqat bitta virtual kalitda rol o'ynaydi, chunki VxLAN-ga kiritilganda biz uni osongina olib tashlashimiz mumkin, chunki bizda VNI bo'ladi.
Endi biz ular uchun hech qanday muammosiz mashinalarimiz va virtual tarmoqlarimizni yaratishimiz mumkin.
Biroq, mijozning boshqa mashinasi bo'lsa-yu, lekin boshqa tarmoqda bo'lsa-chi? Tarmoqlar o'rtasida ildiz otish kerak. Markazlashtirilgan marshrutlash qo'llanilganda oddiy variantni ko'rib chiqamiz - ya'ni trafik maxsus ajratilgan tarmoq tugunlari orqali yo'naltiriladi (yaxshi, qoida tariqasida, ular boshqaruv tugunlari bilan birlashtirilgan, shuning uchun bizda bir xil narsa bo'ladi).
Hech qanday murakkab narsa yo'qdek tuyuladi - biz boshqaruv tugunida ko'prik interfeysini yaratamiz, unga trafikni olib boramiz va u erdan biz uni kerakli joyga yo'naltiramiz. Ammo muammo shundaki, RED mijoz 10.0.0.0/24 tarmog'idan foydalanmoqchi, GREEN mijoz esa 10.0.0.0/24 tarmog'idan foydalanmoqchi. Ya'ni, biz manzil bo'shliqlarini kesishni boshlaymiz. Bundan tashqari, mijozlar boshqa mijozlar o'zlarining ichki tarmoqlariga kirishlarini xohlamaydilar, bu mantiqiy. Tarmoqlar va mijoz ma'lumotlar trafigini ajratish uchun biz ularning har biri uchun alohida nom maydoni ajratamiz. Ismlar maydoni aslida Linux tarmoq stekining nusxasidir, ya'ni RED nom maydonidagi mijozlar mijozlardan GREEN nom maydonidan butunlay ajratilgan (yaxshi, bu mijozlar tarmoqlari o'rtasida marshrutlash standart nomlar maydoni orqali yoki yuqori oqim transport uskunasida ruxsat etiladi).
Ya'ni, biz quyidagi diagrammani olamiz:
L2 tunnellari barcha hisoblash tugunlaridan boshqaruv tuguniga yaqinlashadi. ushbu tarmoqlar uchun L3 interfeysi joylashgan tugun, har biri izolyatsiya uchun ajratilgan nom maydonida.
Biroq, biz eng muhim narsani unutdik. Virtual mashina mijozga xizmat ko'rsatishi kerak, ya'ni unga kirish mumkin bo'lgan kamida bitta tashqi interfeysga ega bo'lishi kerak. Ya'ni, biz tashqi dunyoga chiqishimiz kerak. Bu erda turli xil variantlar mavjud. Keling, eng oddiy variantni qilaylik. Biz har bir mijozga bitta tarmoqni qo'shamiz, u provayder tarmog'ida amal qiladi va boshqa tarmoqlar bilan mos kelmaydi. Tarmoqlar, shuningdek, kesishishi va provayder tarmog'i tomonidagi turli VRF-larga qarashi mumkin. Tarmoq ma'lumotlari har bir mijozning nom maydonida ham yashaydi. Biroq, ular tashqi dunyoga bitta jismoniy (yoki bog'lanish, bu mantiqiyroq) interfeys orqali chiqadilar. Mijoz trafigini ajratish uchun tashqariga chiqadigan trafik mijozga ajratilgan VLAN tegi bilan belgilanadi.
Natijada biz quyidagi diagramma oldik:
O'rinli savol shundaki, nima uchun hisoblash tugunlarida shlyuzlarni o'zlari yaratmaslik kerak? Bu katta muammo emas, bundan tashqari, agar siz taqsimlangan routerni (DVR) yoqsangiz, bu ishlaydi. Ushbu stsenariyda biz Openstack-da sukut bo'yicha ishlatiladigan markazlashtirilgan shlyuz bilan eng oddiy variantni ko'rib chiqamiz. Yuqori yuklangan funktsiyalar uchun ular SR-IOV va Passthrough kabi taqsimlangan yo'riqnoma va tezlashtirish texnologiyalaridan foydalanadilar, ammo ular aytganidek, bu butunlay boshqacha hikoya. Birinchidan, asosiy qism bilan shug'ullanamiz, keyin esa tafsilotlarga o'tamiz.
Aslida, bizning sxemamiz allaqachon ishlaydi, ammo bir nechta nuanslar mavjud:
- Biz qandaydir tarzda mashinalarimizni himoya qilishimiz kerak, ya'ni mijozga qarab kalit interfeysiga filtr qo'yishimiz kerak.
- Virtual mashinaga avtomatik ravishda IP manzilini olish imkoniyatini yarating, shunda siz har safar konsol orqali unga kirishingiz va manzilni ro'yxatdan o'tkazishingiz shart emas.
Mashinalarni himoya qilishdan boshlaylik. Buning uchun siz banal iptables dan foydalanishingiz mumkin, nima uchun emas.
Ya'ni, endi bizning topologiyamiz biroz murakkablashdi:
Keling, davom etaylik. Biz DHCP serverini qo'shishimiz kerak. Har bir mijoz uchun DHCP serverlarini joylashtirish uchun eng ideal joy yuqorida aytib o'tilgan boshqaruv tugunidir, bu erda nomlar bo'shliqlari joylashgan:
Biroq, kichik muammo bor. Agar hamma narsa qayta ishga tushsa va DHCP-da manzillarni ijaraga olish haqidagi barcha ma'lumotlar yo'qolsa-chi. Mashinalarga yangi manzillar berilishi mantiqan to'g'ri, bu unchalik qulay emas. Bu erda ikkita yo'l bor - yoki domen nomlaridan foydalaning va har bir mijoz uchun DNS serverini qo'shing, keyin manzil biz uchun unchalik muhim bo'lmaydi (k8s-dagi tarmoq qismiga o'xshash) - lekin tashqi tarmoqlarda muammo bor, chunki manzillar ularda DHCP orqali ham chiqarilishi mumkin - sizga bulut platformasidagi DNS serverlari va tashqi DNS serveri bilan sinxronlashtirish kerak, menimcha, bu juda moslashuvchan emas, lekin juda mumkin. Yoki ikkinchi variant - metama'lumotlardan foydalanish - ya'ni mashinaga berilgan manzil haqidagi ma'lumotni saqlash, DHCP serveri, agar mashina allaqachon manzilni olgan bo'lsa, mashinaga qaysi manzilni berishni biladi. Ikkinchi variant oddiyroq va moslashuvchan, chunki u avtomobil haqida qo'shimcha ma'lumotni saqlashga imkon beradi. Endi diagrammaga agent metama'lumotlarini qo'shamiz:
Muhokama qilish kerak bo'lgan yana bir masala - bu barcha mijozlar tomonidan bitta tashqi tarmoqdan foydalanish qobiliyati, chunki tashqi tarmoqlar, agar ular butun tarmoq bo'ylab amal qilishlari kerak bo'lsa, qiyin bo'ladi - siz doimiy ravishda ushbu tarmoqlarni taqsimlash va nazorat qilish kerak. Barcha mijozlar uchun yagona tashqi oldindan tuzilgan tarmoqdan foydalanish imkoniyati ommaviy bulutni yaratishda juda foydali bo'ladi. Bu mashinalarni joylashtirishni osonlashtiradi, chunki biz manzillar ma'lumotlar bazasiga murojaat qilishimiz va har bir mijozning tashqi tarmog'i uchun noyob manzil maydonini tanlashimiz shart emas. Bundan tashqari, biz tashqi tarmoqni oldindan ro'yxatdan o'tkazishimiz mumkin va o'rnatish vaqtida biz faqat tashqi manzillarni mijoz mashinalari bilan bog'lashimiz kerak bo'ladi.
Va bu erda NAT bizning yordamimizga keladi - biz mijozlarga NAT tarjimasi yordamida standart nomlar maydoni orqali tashqi dunyoga kirish imkoniyatini yaratamiz. Xo'sh, bu erda kichik muammo bor. Mijoz serveri server sifatida emas, balki mijoz sifatida ishlasa, bu yaxshi bo'ladi - ya'ni ulanishlarni qabul qilishdan ko'ra boshlanadi. Ammo biz uchun bu aksincha bo'ladi. Bunday holda, biz NAT manzilini bajarishimiz kerak, shunda trafikni qabul qilishda boshqaruv tugunlari ushbu trafik A mijozining virtual mashinasi A uchun mo'ljallanganligini tushunadi, ya'ni biz tashqi manzildan NAT tarjimasini qilishimiz kerakligini anglatadi, masalan, 100.1.1.1. .10.0.0.1, ichki manzilga 100. Bunday holda, barcha mijozlar bir xil tarmoqdan foydalanishiga qaramay, ichki izolyatsiya butunlay saqlanib qoladi. Ya'ni, biz nazorat tugunida dNAT va sNAT qilishimiz kerak. Bir vaqtning o'zida suzuvchi manzillar yoki tashqi tarmoqlarga ega bo'lgan bitta tarmoqdan yoki ikkalasidan foydalanish bulutga nima kiritmoqchi ekanligingizga bog'liq. Biz diagrammaga suzuvchi manzillarni qo'shmaymiz, lekin ilgari qo'shilgan tashqi tarmoqlarni qoldiramiz - har bir mijozning o'z tashqi tarmog'i bor (diagrammada ular tashqi interfeysda vlan 200 va XNUMX sifatida ko'rsatilgan).
Natijada, biz qiziqarli va ayni paytda yaxshi o'ylangan yechimni oldik, u ma'lum bir moslashuvchanlikka ega, lekin hali nosozliklarga chidamlilik mexanizmlariga ega emas.
Birinchidan, bizda faqat bitta boshqaruv tugunlari bor - uning ishlamay qolishi barcha tizimlarning qulashiga olib keladi. Ushbu muammoni hal qilish uchun siz kamida 3 ta tugundan iborat kvorumni yaratishingiz kerak. Keling, buni diagrammaga qo'shamiz:
Tabiiyki, barcha tugunlar sinxronlashtiriladi va faol tugun chiqib ketganda, boshqa tugun uning mas'uliyatini o'z zimmasiga oladi.
Keyingi muammo virtual mashina disklari. Ayni paytda ular gipervisorlarning o'zida saqlanadi va gipervisor bilan bog'liq muammolar bo'lsa, biz barcha ma'lumotlarni yo'qotamiz - va agar biz diskni emas, balki butun serverni yo'qotsak, reydning mavjudligi bu erda yordam bermaydi. Buning uchun biz qandaydir saqlash uchun old qism vazifasini bajaradigan xizmatni yaratishimiz kerak. Bu qanday saqlash bo'lishi biz uchun unchalik muhim emas, lekin u bizning ma'lumotlarimizni disk va tugunning va, ehtimol, butun shkafning ishdan chiqishidan himoya qilishi kerak. Bu erda bir nechta variant bor - albatta, Fiber Channel bilan SAN tarmoqlari mavjud, lekin rostini aytaylik - FC allaqachon o'tmishning yodgorligi - transportda E1 analogi - ha, roziman, u hali ham ishlatiladi, lekin faqat usiz mutlaqo mumkin bo'lmagan joyda. Shuning uchun, men 2020 yilda boshqa qiziqarli alternativalar mavjudligini bilib, FC tarmog'ini ixtiyoriy ravishda joylashtirmayman. Garchi har birining o'ziga xos bo'lsa-da, FK o'zining barcha cheklovlari bilan bizga kerak, deb hisoblaydiganlar bo'lishi mumkin - men bahslashmayman, har kimning o'z fikri bor. Biroq, mening fikrimcha, eng qiziqarli yechim Ceph kabi SDS dan foydalanishdir.
Ceph sizga disklarning joylashishini hisobga olgan holda, paritet tekshiruvi kodlaridan (5 yoki 6-gachasi reydga o'xshash) turli xil disklarga to'liq ma'lumotlarni takrorlash bilan tugaydigan kodlardan boshlab, mumkin bo'lgan zaxira variantlari bilan yuqori darajada mavjud bo'lgan ma'lumotlarni saqlash echimini yaratishga imkon beradi. serverlar va kabinetlardagi serverlar va boshqalar.
Ceph qurish uchun sizga yana 3 ta tugun kerak bo'ladi. Saqlash bilan o'zaro aloqa, shuningdek, blok, ob'ekt va fayllarni saqlash xizmatlaridan foydalangan holda tarmoq orqali amalga oshiriladi. Sxemaga xotira qo'shamiz:
Eslatma: siz giperkonversiyalangan hisoblash tugunlarini ham yaratishingiz mumkin - bu bir nechta funktsiyalarni bitta tugunda birlashtirish tushunchasi - masalan, saqlash + hisoblash - seph saqlash uchun maxsus tugunlarni ajratmasdan. Biz bir xil nosozliklarga chidamli sxemani olamiz - chunki SDS biz belgilagan zahira darajasi bilan ma'lumotlarni zahiraga oladi. Biroq, giperkonversiyalangan tugunlar har doim murosaga keladi - chunki saqlash tugunlari bir qarashda ko'rinadigan darajada havoni isitmaydi (chunki u erda virtual mashinalar yo'q) - u CPU resurslarini SDSga xizmat ko'rsatishga sarflaydi (aslida bu hammasini qiladi). tugunlar, disklar va boshqalarning ishdan chiqishidan keyin takrorlash va tiklash). Ya'ni, agar siz uni saqlash bilan birlashtirsangiz, hisoblash tugunining kuchining bir qismini yo'qotasiz.
Bularning barchasini qandaydir tarzda boshqarish kerak - bizga mashina, tarmoq, virtual router va hokazolarni yaratishimiz mumkin bo'lgan narsa kerak. Buning uchun biz boshqaruv tuguniga asboblar paneli vazifasini bajaradigan xizmatni qo'shamiz - mijoz http/ https orqali ushbu portalga ulanishi va o'ziga kerak bo'lgan hamma narsani (yaxshi, deyarli) bajarishi mumkin.
Natijada, bizda endi xatolarga chidamli tizim mavjud. Ushbu infratuzilmaning barcha elementlari qandaydir tarzda boshqarilishi kerak. Ilgari Openstack har biri o'ziga xos funktsiyani ta'minlaydigan loyihalar to'plami ekanligi ta'riflangan edi. Ko'rib turganimizdek, sozlash va boshqarish kerak bo'lgan elementlar etarli. Bugun biz tarmoq qismi haqida gaplashamiz.
Neytron arxitekturasi
OpenStack-da virtual mashina portlarini umumiy L2 tarmog'iga ulash, turli L2 tarmoqlarida joylashgan VM-lar o'rtasida trafikni yo'naltirishni ta'minlash, shuningdek, NAT, Floating IP, DHCP va boshqalar kabi xizmatlarni taqdim etish uchun mas'ul bo'lgan Neytron.
Yuqori darajada tarmoq xizmatining (asosiy qismi) ishlashini quyidagicha ta'riflash mumkin.
VMni ishga tushirishda tarmoq xizmati:
- Berilgan VM (yoki portlar) uchun port yaratadi va bu haqda DHCP xizmatini xabardor qiladi;
- Yangi virtual tarmoq qurilmasi yaratildi (libvirt orqali);
- VM 1-bosqichda yaratilgan port(lar)ga ulanadi;
Ajablanarlisi shundaki, Neytronning ishi Linuxga sho'ng'igan har bir kishiga tanish bo'lgan standart mexanizmlarga asoslangan - nomlar maydoni, iptables, Linux ko'prigi, openvswitch, conntrack va boshqalar.
Neytron SDN boshqaruvchisi emasligini darhol aniqlash kerak.
Neytron bir-biriga bog'langan bir nechta tarkibiy qismlardan iborat:
Openstack-neytron-server API orqali foydalanuvchi so'rovlari bilan ishlaydigan daemon. Ushbu iblis hech qanday tarmoq ulanishlarini ro'yxatdan o'tkazishda ishtirok etmaydi, lekin buning uchun kerakli ma'lumotlarni o'zining plaginlariga taqdim etadi, so'ngra kerakli tarmoq elementini sozlaydi. OpenStack tugunlaridagi neytron agentlari Neytron serverida ro'yxatdan o'tadi.
Neytron-server aslida python-da yozilgan dastur bo'lib, ikki qismdan iborat:
- REST xizmati
- Neytron plagini (yadro/xizmat)
REST xizmati boshqa komponentlardan API qo'ng'iroqlarini qabul qilish uchun mo'ljallangan (masalan, ba'zi ma'lumotlarni taqdim etish so'rovi va boshqalar).
Plaginlar API so'rovlari paytida chaqiriladigan plagin dasturiy ta'minot komponentlari/modullaridir, ya'ni xizmatning atributi ular orqali amalga oshiriladi. Plaginlar ikki turga bo'linadi - xizmat ko'rsatish va ildiz. Qoida tariqasida, ot plagini asosan manzil maydonini va VMlar orasidagi L2 ulanishlarini boshqarish uchun javobgardir va xizmat plaginlari allaqachon VPN yoki FW kabi qo'shimcha funktsiyalarni taqdim etadi.
Masalan, bugungi kunda mavjud plaginlar ro'yxatini ko'rish mumkin
Bir nechta xizmat plaginlari bo'lishi mumkin, lekin faqat bitta ot plaginlari bo'lishi mumkin.
Openstack-neytron-ml2 standart Openstack root plaginidir. Ushbu plagin modulli arxitekturaga ega (oldingisidan farqli o'laroq) va tarmoq xizmatini unga ulangan drayverlar orqali sozlaydi. Biz plaginning o'zini biroz keyinroq ko'rib chiqamiz, chunki aslida u OpenStack-ning tarmoq qismida mavjud bo'lgan moslashuvchanlikni beradi. Ildiz plaginini almashtirish mumkin (masalan, Contrail Networking bunday almashtirishni amalga oshiradi).
RPC xizmati (rabbitmq-server) — navbatni boshqarish va boshqa OpenStack xizmatlari bilan o'zaro aloqani, shuningdek, tarmoq xizmati agentlari o'rtasidagi o'zaro aloqani ta'minlaydigan xizmat.
Tarmoq agentlari — har bir tugunda joylashgan agentlar, ular orqali tarmoq xizmatlari sozlanadi.
Bir necha turdagi agentlar mavjud.
Asosiy agent L2 agenti. Ushbu agentlar gipervisorlarning har birida, shu jumladan boshqaruv tugunlarida (aniqrog'i, ijarachilarga har qanday xizmat ko'rsatadigan barcha tugunlarda) ishlaydi va ularning asosiy vazifasi virtual mashinalarni umumiy L2 tarmog'iga ulash, shuningdek, har qanday voqea sodir bo'lganda ogohlantirishlarni yaratishdir ( masalan, portni o'chirish/yoqish).
Keyingi, muhim bo'lmagan agent L3 agenti. Odatiy bo'lib, ushbu agent faqat tarmoq tugunida ishlaydi (ko'pincha tarmoq tugunlari boshqaruv tugunlari bilan birlashtiriladi) va ijarachilarning tarmoqlari (uning tarmoqlari va boshqa ijarachilarning tarmoqlari o'rtasida) o'rtasida marshrutlashni ta'minlaydi va tashqi dunyo uchun ochiq, NAT, shuningdek DHCP xizmati). Biroq, DVR (tarqatilgan yo'riqnoma) dan foydalanilganda, L3 plaginiga bo'lgan ehtiyoj hisoblash tugunlarida ham paydo bo'ladi.
L3 agenti har bir ijarachiga o'zining izolyatsiyalangan tarmoqlari to'plamini va trafikni yo'naltiruvchi va Layer 2 tarmoqlari uchun shlyuz xizmatlarini taqdim etuvchi virtual routerlarning funksionalligini ta'minlash uchun Linux nom maydonlaridan foydalanadi.
ma'lumotlar bazasi — tarmoqlar, quyi tarmoqlar, portlar, hovuzlar va boshqalar identifikatorlarining maʼlumotlar bazasi.
Aslida, Neytron har qanday tarmoq ob'ektlarini yaratishda API so'rovlarini qabul qiladi, so'rovni autentifikatsiya qiladi va RPC orqali (agar u ba'zi plagin yoki agentga kirsa) yoki REST API (agar u SDN-da muloqot qilsa) agentlarga (plaginlar orqali) ma'lumotlarni uzatadi. so'ralgan xizmatni tashkil qilish uchun zarur bo'lgan ko'rsatmalar.
Endi sinovni o'rnatishga o'taylik (u qanday joylashtirilgan va unga nima kiritilgan, biz amaliy qismda keyinroq ko'rib chiqamiz) va har bir komponent qaerda joylashganligini ko'rib chiqamiz:
(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 ~]$
Aslida, bu Neytronning butun tuzilishi. Endi ML2 plaginiga biroz vaqt sarflashga arziydi.
Modulli qatlam 2
Yuqorida aytib o'tilganidek, plagin standart OpenStack ildiz plaginidir va modulli arxitekturaga ega.
ML2 plaginining salafi monolit tuzilishga ega edi, bu, masalan, bitta o'rnatishda bir nechta texnologiyalar aralashmasidan foydalanishga imkon bermadi. Misol uchun, siz ikkala openvswitch va linuxbridge-dan bir vaqtning o'zida foydalana olmaysiz - birinchi yoki ikkinchi. Shu sababli, arxitekturasi bilan ML2 plagini yaratildi.
ML2 ikkita komponentdan iborat - ikki turdagi drayverlar: Tip drayverlari va Mexanizm drayverlari.
Drayvlarni yozing VxLAN, VLAN, GRE kabi tarmoq ulanishlarini tashkil qilish uchun foydalaniladigan texnologiyalarni aniqlang. Shu bilan birga, haydovchi turli texnologiyalardan foydalanishga imkon beradi. Standart texnologiya overlay tarmoqlari va vlan tashqi tarmoqlari uchun VxLAN inkapsulyatsiyasidir.
Tip drayverlari quyidagi tarmoq turlarini o'z ichiga oladi:
Yassi - teglarsiz tarmoq
VLANlar - belgilangan tarmoq
mahalliy — yaxlit o'rnatish uchun tarmoqning maxsus turi (bunday o'rnatishlar ishlab chiquvchilar uchun ham, o'qitish uchun ham kerak)
GRE — GRE tunnellaridan foydalangan holda ustki tarmoq
VxLAN — VxLAN tunnellaridan foydalangan holda ustki tarmoq
Mexanizm haydovchilar turdagi drayverda ko'rsatilgan texnologiyalarni tashkil qilishni ta'minlaydigan vositalarni aniqlang - masalan, openvswitch, sr-iov, opendaylight, OVN va boshqalar.
Ushbu drayverni amalga oshirishga qarab, Neytron tomonidan boshqariladigan agentlar yoki L2 tarmoqlarini tashkil qilish, marshrutlash va h.k. bilan bog'liq barcha masalalarni hal qiladigan tashqi SDN kontrollerga ulanishlar qo'llaniladi.
Misol: agar biz ML2 dan OVS bilan birga foydalansak, u holda OVSni boshqaradigan har bir hisoblash tuguniga L2 agenti o'rnatiladi. Biroq, agar biz, masalan, OVN yoki OpenDayLight dan foydalansak, OVS boshqaruvi ularning yurisdiktsiyasiga kiradi - Neytron, ildiz plagini orqali boshqaruvchiga buyruqlar beradi va u allaqachon aytganini bajaradi.
Keling, Open vSwitch-ni ko'rib chiqaylik
Hozirgi vaqtda OpenStack-ning asosiy komponentlaridan biri Open vSwitch hisoblanadi.
OpenStack-ni Juniper Contrail yoki Nokia Nuage kabi qo'shimcha SDN sotuvchisisiz o'rnatishda OVS bulutli tarmoqning asosiy tarmoq komponenti bo'lib, iptables, conntrack, nomlar bo'shliqlari bilan birgalikda to'liq huquqli ko'p ijaraga olingan qatlamli tarmoqlarni tashkil qilish imkonini beradi. Tabiiyki, ushbu komponentni, masalan, uchinchi tomon mulkiy (sotuvchi) SDN yechimlaridan foydalanganda almashtirish mumkin.
OVS bu ochiq kodli dasturiy ta'minot kaliti bo'lib, u virtuallashtirilgan muhitda virtual trafik uzatuvchi sifatida foydalanish uchun mo'ljallangan.
Ayni paytda OVS juda yaxshi funksionallikka ega, ular orasida QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK va boshqalar kabi texnologiyalar mavjud.
Eslatma: OVS dastlab yuqori yuklangan telekommunikatsiya funktsiyalari uchun yumshoq kalit sifatida ishlab chiqilmagan va WEB-server yoki pochta serveri kabi kamroq tarmoqli kengligi talab qiladigan AT funktsiyalari uchun mo'ljallangan. Biroq, OVS yanada ishlab chiqilmoqda va OVS ning joriy tatbiqlari uning ishlashi va imkoniyatlarini sezilarli darajada yaxshilagan, bu esa undan yuqori yuklangan funktsiyalarga ega bo'lgan aloqa operatorlari tomonidan foydalanishga imkon beradi, masalan, DPDK tezlashuvini qo'llab-quvvatlaydigan OVS ilovasi mavjud.
Siz bilishingiz kerak bo'lgan OVSning uchta muhim komponenti mavjud:
- Yadro moduli — boshqaruv elementidan olingan qoidalar asosida trafikni qayta ishlovchi yadro maydonida joylashgan komponent;
- vSwitch daemon (ovs-vswitchd) - bu yadro modulini dasturlash uchun mas'ul bo'lgan foydalanuvchi maydonida ishga tushirilgan jarayon, ya'ni u to'g'ridan-to'g'ri kommutatorning ishlashi mantiqini ifodalaydi.
- Ma'lumotlar bazasi serveri - konfiguratsiya saqlanadigan OVS ishlaydigan har bir xostda joylashgan mahalliy ma'lumotlar bazasi. SDN kontrollerlari OVSDB protokoli yordamida ushbu modul orqali muloqot qilishlari mumkin.
Bularning barchasi ovs-vsctl, ovs-appctl, ovs-ofctl va boshqalar kabi diagnostika va boshqaruv yordamchi dasturlari bilan birga keladi.
Hozirda Openstack telekommunikatsiya operatorlari tomonidan EPC, SBC, HLR va boshqalar kabi tarmoq funksiyalarini koʻchirish uchun keng qoʻllaniladi. Baʼzi funksiyalar OVS bilan muammosiz yashashi mumkin, lekin masalan, EPC abonent trafigini qayta ishlaydi – keyin u orqali oʻtadi. katta miqdordagi trafik (hozirgi trafik hajmi soniyasiga bir necha yuz gigabitga etadi). Tabiiyki, bunday trafikni yadro maydoni orqali haydash (chunki ekspeditor sukut bo'yicha u erda joylashgan) eng yaxshi g'oya emas. Shuning uchun, OVS ko'pincha DPDK tezlashtirish texnologiyasidan foydalangan holda, yadroni chetlab o'tib, NIC dan foydalanuvchi maydoniga trafikni yo'naltirish uchun to'liq foydalanuvchi maydonida joylashtiriladi.
Eslatma: telekommunikatsiya funktsiyalari uchun o'rnatilgan bulut uchun OVSni chetlab o'tgan hisoblash tugunidan to'g'ridan-to'g'ri kommutatsiya uskunasiga trafikni chiqarish mumkin. Buning uchun SR-IOV va Passthrough mexanizmlari qo'llaniladi.
Bu haqiqiy maketda qanday ishlaydi?
Xo'sh, endi amaliy qismga o'tamiz va bularning barchasi amalda qanday ishlashini ko'rib chiqamiz.
Birinchidan, oddiy Openstack o'rnatilishini o'rnatamiz. Tajribalar uchun qo'limda serverlar to'plami yo'qligi sababli, biz prototipni virtual mashinalardan bitta jismoniy serverda yig'amiz. Ha, tabiiyki, bunday yechim tijoriy maqsadlar uchun mos emas, lekin Openstack-da tarmoq qanday ishlashining misolini ko'rish uchun bunday o'rnatish ko'zlar uchun etarli. Bundan tashqari, bunday o'rnatish o'quv maqsadlari uchun yanada qiziqarli - chunki siz trafikni ushlab turishingiz mumkin va hokazo.
Biz faqat asosiy qismni ko'rishimiz kerak bo'lganligi sababli, biz bir nechta tarmoqlardan foydalana olmaymiz, lekin faqat ikkita tarmoq yordamida hamma narsani ko'taramiz va ushbu tartibdagi ikkinchi tarmoq faqat bulutli va DNS serveriga kirish uchun ishlatiladi. Biz hozircha tashqi tarmoqlarga tegmaymiz - bu alohida katta maqola uchun mavzu.
Shunday qilib, keling, tartibda boshlaylik. Birinchidan, bir oz nazariya. Biz Openstackni TripleO (Openstack on Openstack) yordamida o'rnatamiz. TripleO-ning mohiyati shundaki, biz bulutli deb ataladigan Openstack all-in-one-ni (ya'ni bitta tugunga) o'rnatamiz va keyin o'rnatilgan Openstack-ning imkoniyatlaridan overcloud deb ataladigan ishlash uchun mo'ljallangan Openstack-ni o'rnatamiz. Undercloud o'zining jismoniy serverlarini (yalang'och metall) boshqarish qobiliyatidan foydalanadi - Ironic loyihasi - hisoblash, boshqarish, saqlash tugunlari rolini bajaradigan gipervizorlarni taqdim etish uchun. Ya'ni, biz Openstack-ni joylashtirish uchun hech qanday uchinchi tomon vositalaridan foydalanmaymiz - biz Openstack-ni Openstack-dan foydalanib joylashtiramiz. O'rnatish davom etar ekan, bu aniqroq bo'ladi, shuning uchun biz u erda to'xtab qolmaymiz va oldinga siljiymiz.
Eslatma: Ushbu maqolada, soddaligi uchun men ichki Openstack tarmoqlari uchun tarmoq izolyatsiyasidan foydalanmadim, lekin hamma narsa faqat bitta tarmoq yordamida joylashtirilgan. Biroq, tarmoq izolyatsiyasining mavjudligi yoki yo'qligi yechimning asosiy funksionalligiga ta'sir qilmaydi - hamma narsa izolyatsiyadan foydalanganda bo'lgani kabi ishlaydi, lekin trafik bir xil tarmoqda oqadi. Tijoriy o'rnatish uchun tabiiy ravishda turli xil vlan va interfeyslardan foydalangan holda izolyatsiyadan foydalanish kerak. Masalan, ceph xotirasini boshqarish trafigi va ma'lumotlar trafigining o'zi (disklarga mashina kirishi va h.k.) izolyatsiya qilingan holda turli pastki tarmoqlardan foydalanadi (Saqlash boshqaruvi va saqlash) va bu sizga ushbu trafikni bo'lish orqali yechimni xatoga chidamliroq qilish imkonini beradi, masalan. , turli portlar bo'ylab yoki turli trafik uchun turli QoS profillaridan foydalanish, shunda ma'lumotlar trafigini signalizatsiya trafigini siqib chiqarmaydi. Bizning holatlarimizda ular bir xil tarmoqqa kirishadi va aslida bu bizni hech qanday tarzda cheklamaydi.
Eslatma: Biz virtual mashinalarni virtual mashinalarga asoslangan virtual muhitda ishga tushirmoqchi bo'lganimiz uchun, avvalo, ichki virtualizatsiyani yoqishimiz kerak.
Ichki virtualizatsiya yoqilgan yoki yoqilmaganligini tekshirishingiz mumkin:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Agar siz N harfini ko'rsangiz, biz tarmoqda topadigan har qanday qo'llanmaga muvofiq ichki virtualizatsiyani qo'llab-quvvatlashni yoqamiz, masalan .
Biz virtual mashinalardan quyidagi sxemani yig'ishimiz kerak:
Mening holimda, kelajakdagi o'rnatishning bir qismi bo'lgan virtual mashinalarni ulash uchun (va men ulardan 7 tasini oldim, lekin sizda juda ko'p resurslar bo'lmasa, siz 4 tasini olishingiz mumkin), men OpenvSwitch-dan foydalandim. Men bitta ovs ko'prigi yaratdim va unga port-guruhlar orqali virtual mashinalarni uladim. Buning uchun men shunday xml faylini yaratdim:
[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>Bu erda uchta port guruhi e'lon qilingan - ikkita kirish va bitta magistral (ikkinchisi DNS-server uchun kerak edi, lekin siz usiz ham qilishingiz mumkin yoki uni xost-mashinaga o'rnatishingiz mumkin - qaysi biri sizga qulayroq bo'lsa). Keyinchalik, ushbu shablondan foydalanib, biz virsh net-define orqali o'zimiznikini e'lon qilamiz:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Endi biz gipervisor port konfiguratsiyasini tahrirlaymiz:
[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 ~]# Eslatma: bu stsenariyda ovs-br1 portidagi manzilga kirish imkoni bo‘lmaydi, chunki unda vlan tegi yo‘q. Buni tuzatish uchun siz sudo ovs-vsctl set port ovs-br1 tag=100 buyrug'ini berishingiz kerak. Biroq, qayta ishga tushirilgandan so'ng, bu teg yo'qoladi (agar kimdir uni joyida qoldirishni bilsa, men juda minnatdorman). Lekin bu unchalik muhim emas, chunki bizga bu manzil faqat o'rnatish vaqtida kerak bo'ladi va Openstack to'liq o'rnatilganda kerak bo'lmaydi.
Keyinchalik, biz bulutli mashinani yaratamiz:
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=ttyS0O'rnatish vaqtida siz barcha kerakli parametrlarni o'rnatasiz, masalan, mashina nomi, parollar, foydalanuvchilar, ntp serverlari va boshqalar, siz darhol portlarni sozlashingiz mumkin, lekin shaxsan men uchun, o'rnatishdan so'ng, mashinaga kirish osonroq bo'ladi. konsolni oching va kerakli fayllarni tuzating. Agar sizda allaqachon tayyor tasvir mavjud bo'lsa, siz undan foydalanishingiz yoki men qilgan ishni bajarishingiz mumkin - minimal Centos 7 tasvirini yuklab oling va undan VMni o'rnatish uchun foydalaning.
Muvaffaqiyatli o'rnatishdan so'ng, siz bulutli bulutni o'rnatishingiz mumkin bo'lgan virtual mashinaga ega bo'lishingiz kerak
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningBirinchidan, o'rnatish jarayoni uchun zarur bo'lgan asboblarni o'rnating:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Bulut ostida o'rnatish
Biz stack foydalanuvchisini yaratamiz, parol o'rnatamiz, uni sudoer-ga qo'shamiz va unga parol kiritmasdan sudo orqali root buyruqlarini bajarish imkoniyatini beramiz:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackEndi biz hostlar faylida to'liq bulut nomini belgilaymiz:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Keyinchalik, biz omborlarni qo'shamiz va kerakli dasturlarni o'rnatamiz:
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-ansibleEslatma: agar siz ceph-ni o'rnatishni rejalashtirmasangiz, unda siz ceph bilan bog'liq buyruqlarni kiritishingiz shart emas. Men Queens versiyasidan foydalandim, lekin siz o'zingizga yoqqan boshqasidan foydalanishingiz mumkin.
Keyin bulutli konfiguratsiya faylini foydalanuvchining uy kataloglari stekiga nusxalang:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confEndi biz ushbu faylni o'rnatishimizga moslashtirib, tuzatishimiz kerak.
Fayl boshiga quyidagi qatorlarni qo'shishingiz kerak:
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 = 10Shunday qilib, keling, sozlamalarni ko'rib chiqamiz:
undercloud_hostname — bulutli serverning toʻliq nomi, DNS serveridagi yozuvga mos kelishi kerak
local_ip - tarmoqni ta'minlashga qaratilgan mahalliy bulutli manzil
tarmoq_shlyuzi — bulutli tugunlarni o'rnatishda tashqi dunyoga kirish uchun shlyuz vazifasini bajaradigan xuddi shu mahalliy manzil mahalliy IP bilan ham mos keladi.
undercloud_public_host — tashqi API manzili, provayder tarmog‘idan istalgan bepul manzil tayinlangan
undercloud_admin_host ichki API manzili, provayder tarmog'idan istalgan bepul manzil tayinlanadi
undercloud_nameservers - DNS server
yaratish_xizmat_sertifikati - joriy misolda bu satr juda muhim, chunki agar siz uni noto'g'ri deb o'rnatmasangiz, o'rnatish vaqtida xatolik paydo bo'ladi, muammo Red Hat xato trekerida tasvirlangan.
mahalliy_interfeys tarmoqni ta'minlashda interfeys. Bu interfeys bulutli oʻrnatish vaqtida qayta konfiguratsiya qilinadi, shuning uchun siz bulutda ikkita interfeysga ega boʻlishingiz kerak – biri unga kirish uchun, ikkinchisi esa taʼminlash uchun.
local_mtu - MTU. Bizda sinov laboratoriyamiz bor va menda OVS kommutatorining portlarida 1500 MTU bor, shuning uchun VxLAN-ga o'rnatilgan paketlar o'tishi uchun uni 1450 ga o'rnatish kerak.
tarmoq_sidr - ta'minlash tarmog'i
maskarad — tashqi tarmoqqa kirish uchun NAT-dan foydalanish
maskarad_tarmoq - NATlangan tarmoq
dhcp_start — bulutli oʻrnatish vaqtida tugunlarga manzillar tayinlanadigan manzillar hovuzining boshlangʻich manzili
dhcp_end — bulutli joylashish vaqtida tugunlarga manzillar tayinlanadigan manzillar hovuzining yakuniy manzili
inspection_iprange - introspektsiya uchun zarur bo'lgan manzillar hovuzi (yuqoridagi hovuz bilan bir-biriga mos kelmasligi kerak)
rejalashtiruvchi_maks_urinishlar — haddan tashqari bulutni o'rnatishga urinishlarning maksimal soni (tugunlar sonidan ko'p yoki teng bo'lishi kerak)
Fayl tavsiflangandan so'ng, siz bulutli bulutni o'rnatish buyrug'ini berishingiz mumkin:
openstack undercloud install
Jarayon dazmolingizga qarab 10 dan 30 minutgacha davom etadi. Oxir-oqibat, siz shunday chiqishni ko'rishingiz kerak:
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.
#############################################################################Bu chiqishda aytilishicha, siz bulutli bulutni muvaffaqiyatli o'rnatdingiz va endi siz bulutli bulut holatini tekshirishingiz va bulutli bulutni o'rnatishni davom ettirishingiz mumkin.
Ifconfig chiqishiga qarasangiz, yangi ko'prik interfeysi paydo bo'lganini ko'rasiz
[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 0Haddan tashqari bulutli joylashtirish endi ushbu interfeys orqali amalga oshiriladi.
Quyidagi chiqishdan bizda bitta tugunda barcha xizmatlar mavjudligini ko'rishingiz mumkin:
(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 |
+--------------------------+-----------+----------+Quyida bulutli tarmoq qismining konfiguratsiyasi keltirilgan:
(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 ~]$Haddan tashqari bulutli o'rnatish
Ayni paytda bizda faqat bulutli bulut mavjud va bizda ortiqcha bulut yig'iladigan tugunlar etarli emas. Shuning uchun, birinchi navbatda, bizga kerak bo'lgan virtual mashinalarni joylashtiramiz. O'rnatish vaqtida bulutli bulutning o'zi OS va kerakli dasturiy ta'minotni bulutli mashinaga o'rnatadi - ya'ni biz mashinani to'liq joylashtirishimiz shart emas, faqat u uchun disk (yoki disklar) yaratish va uning parametrlarini aniqlash - ya'ni , aslida, biz OS o'rnatilmagan yalang'och serverni olamiz.
Keling, virtual mashinalarimiz disklari joylashgan papkaga o'tamiz va kerakli o'lchamdagi disklarni yaratamiz:
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 160GBiz root sifatida ishlayotganimiz sababli, huquqlar bilan bog'liq muammoga duch kelmaslik uchun ushbu disklarning egasini o'zgartirishimiz kerak:
[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]# Eslatma: agar siz uni o'rganish uchun cephni o'rnatishni rejalashtirmasangiz, unda buyruqlar kamida ikkita diskli kamida 3 ta tugun yaratmaydi, lekin shablonda vda, vdb va boshqalar virtual disklari ishlatilishini ko'rsatadi.
Ajoyib, endi biz ushbu mashinalarning barchasini aniqlashimiz kerak:
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 Oxirida -print-xml > /tmp/storage-1.xml buyrug'i mavjud bo'lib, u /tmp/ papkasida har bir mashinaning tavsifi bilan xml faylini yaratadi; agar siz uni qo'shmasangiz, siz qo'shilmaydi. virtual mashinalarni aniqlay oladi.
Endi biz ushbu mashinalarning barchasini virshda aniqlashimiz kerak:
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 ~]#Endi kichik nuance - tripleO o'rnatish va introspektsiya paytida serverlarni boshqarish uchun IPMI-dan foydalanadi.
Introspeksiya - bu tugunlarni keyingi ta'minlash uchun zarur bo'lgan parametrlarini olish uchun uskunani tekshirish jarayoni. Introspeksiya yalang'och metall serverlar bilan ishlash uchun mo'ljallangan ironic xizmati yordamida amalga oshiriladi.
Ammo bu erda muammo bor - apparat IPMI serverlarida alohida port (yoki umumiy port, lekin bu muhim emas), virtual mashinalarda bunday portlar yo'q. Bu erda vbmc deb nomlangan qo'ltiq tayoqchasi yordamga keladi - IPMI portiga taqlid qilish imkonini beruvchi yordamchi dastur. Ushbu nuance, ayniqsa, ESXI gipervisorida bunday laboratoriyani o'rnatmoqchi bo'lganlar uchun e'tibor berishga arziydi - rostini aytsam, uning vbmc analogi bor-yo'qligini bilmayman, shuning uchun hamma narsani joylashtirishdan oldin bu masala haqida o'ylash kerak. .
vbmc-ni o'rnating:
yum install yum install python2-virtualbmcAgar operatsion tizimingiz paketni topa olmasa, omborni qo'shing:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmEndi biz yordamchi dasturni o'rnatamiz. Bu erda hamma narsa sharmandalik darajasiga qadar banal. Endi vbmc ro'yxatida serverlar yo'qligi mantiqan to'g'ri
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Ular paydo bo'lishi uchun ular qo'lda shunday e'lon qilinishi kerak:
[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 ~]#Menimcha, buyruq sintaksisi tushuntirishsiz aniq. Biroq, hozircha barcha seanslarimiz DOWN holatida. Ular UP holatiga o'tishlari uchun ularni yoqishingiz kerak:
[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 ~]#Va oxirgi teginish - xavfsizlik devori qoidalarini tuzatishingiz kerak (yoki uni butunlay o'chirib qo'ying):
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
Endi bulut ostiga o'tamiz va hamma narsa ishlayotganini tekshiramiz. Xost mashinasining manzili - 192.168.255.200, biz o'rnatishga tayyorgarlik paytida kerakli ipmitool paketini qo'shdik:
[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 runningKo'rib turganingizdek, biz vbmc orqali boshqaruv tugunini muvaffaqiyatli ishga tushirdik. Endi uni o'chirib, davom etamiz:
[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 ~]#Keyingi qadam - bulutli bulut o'rnatiladigan tugunlarning introspektsiyasi. Buning uchun biz tugunlarimiz tavsifi bilan json faylini tayyorlashimiz kerak. Esda tutingki, yalang'och serverlarga o'rnatishdan farqli o'laroq, fayl har bir mashina uchun vbmc ishlayotgan portni ko'rsatadi.
[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:27Eslatma: boshqaruv tugunida ikkita interfeys mavjud, ammo bu holda bu muhim emas, bu o'rnatishda biz uchun bittasi etarli bo'ladi.
Endi json faylini tayyorlaymiz. Biz ta'minlash amalga oshiriladigan portning ko'knori manzilini, tugunlarning parametrlarini ko'rsatishimiz, ularga nom berishimiz va ipmi-ga qanday borishni ko'rsatishimiz kerak:
{
"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"
}
]
}Endi biz istehzo uchun tasvirlarni tayyorlashimiz kerak. Buning uchun ularni wget orqali yuklab oling va o'rnating:
(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 ~]$Tasvirlarni bulutli bulutga yuklash:
(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 ~]$Barcha tasvirlar yuklanganligini tekshirish
(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 ~]$Yana bir narsa - DNS serverini qo'shishingiz kerak:
(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 ~]$Endi biz introspektsiya uchun buyruq berishimiz mumkin:
(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 ~]$Chiqishdan ko'rinib turibdiki, hamma narsa xatosiz yakunlandi. Keling, barcha tugunlar mavjud holatda ekanligini tekshiramiz:
(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 ~]$ Agar tugunlar boshqa holatda bo'lsa, odatda boshqarilsa, unda biror narsa noto'g'ri ketdi va siz jurnalga qarashingiz va nima uchun bu sodir bo'lganini aniqlashingiz kerak. Shuni yodda tutingki, ushbu stsenariyda biz virtualizatsiyadan foydalanamiz va virtual mashinalar yoki vbmc-dan foydalanish bilan bog'liq xatolar bo'lishi mumkin.
Keyinchalik, qaysi tugun qaysi funktsiyani bajarishini ko'rsatishimiz kerak - ya'ni tugun o'rnatadigan profilni ko'rsating:
(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 ~]$Har bir tugun uchun profilni belgilang:
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-d9afb69d1167Keling, hamma narsani to'g'ri bajarganimizni tekshiramiz:
(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 ~]$Agar hamma narsa to'g'ri bo'lsa, biz bulutni o'rnatish buyrug'ini beramiz:
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 qemuHaqiqiy o'rnatishda moslashtirilgan shablonlardan tabiiy ravishda foydalaniladi, bizning holatlarimizda bu jarayonni ancha murakkablashtiradi, chunki shablondagi har bir tahrirni tushuntirish kerak bo'ladi. Yuqorida yozilganidek, uning qanday ishlashini ko'rish uchun oddiy o'rnatish ham etarli bo'ladi.
Eslatma: --libvirt tipidagi qemu o'zgaruvchisi bu holda kerak, chunki biz ichki virtualizatsiyadan foydalanamiz. Aks holda, virtual mashinalarni ishga tushira olmaysiz.
Endi sizda taxminan bir soat yoki undan ko'proq vaqt bor (apparatning imkoniyatlariga qarab) va faqat shu vaqtdan keyin siz quyidagi xabarni ko'rasiz deb umid qilishingiz mumkin:
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 ~]$Endi sizda ochiq stackning deyarli to'laqonli versiyasi mavjud, uni o'rganishingiz, tajriba qilishingiz va hokazo.
Keling, hamma narsa to'g'ri ishlayotganini tekshirib ko'raylik. Foydalanuvchining uy kataloglari stekida ikkita fayl mavjud - biri stackrc (osti bulutni boshqarish uchun) va ikkinchisi overcloudrc (ortiqcha bulutni boshqarish uchun). Ushbu fayllar manba sifatida ko'rsatilishi kerak, chunki ular autentifikatsiya uchun zarur bo'lgan ma'lumotlarni o'z ichiga oladi.
(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 ~]$Mening o'rnatishim hali ham bitta kichik teginishni talab qiladi - boshqaruvchiga marshrut qo'shish, chunki men ishlayotgan mashina boshqa tarmoqda. Buni amalga oshirish uchun issiqlik boshqaruvchisi hisobi ostidagi nazorat-1-ga o'ting va marshrutni ro'yxatdan o'tkazing
(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.254Xo'sh, endi siz ufqqa kirishingiz mumkin. Barcha ma'lumotlar - manzillar, login va parol - /home/stack/overcloudrc faylida. Yakuniy diagramma quyidagicha ko'rinadi:
Aytgancha, bizning o'rnatishimizda mashina manzillari DHCP orqali chiqarilgan va siz ko'rib turganingizdek, ular "tasodifiy" chiqarilgan. Agar kerak bo'lsa, o'rnatish vaqtida qaysi mashinaga qaysi manzil biriktirilishi kerakligini shablonda aniq belgilashingiz mumkin.
Virtual mashinalar orasidagi trafik qanday o'tadi?
Ushbu maqolada biz trafikni o'tkazishning uchta variantini ko'rib chiqamiz
- Bitta L2 tarmog'ida bitta gipervisorda ikkita mashina
- Xuddi shu L2 tarmog'idagi turli xil gipervizorlarda ikkita mashina
- Turli tarmoqlardagi ikkita mashina (tarmoqlararo ildiz otish)
Tashqi dunyoga tashqi tarmoq orqali kirish, suzuvchi manzillar, shuningdek, taqsimlangan marshrutlash holatlarini keyingi safar ko'rib chiqamiz, hozircha biz ichki trafikga e'tibor qaratamiz.
Tekshirish uchun quyidagi diagrammani tuzamiz:
Biz 4 ta virtual mashinani yaratdik - bitta L3 tarmog'ida 2 tasi - net-1 va yana 1 tasi net-2 tarmog'ida
(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 ~]$ Keling, yaratilgan mashinalar qaysi gipervisorlarda joylashganligini ko'rib chiqaylik:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(overcloud) [stack@undercloud ~]$
Vm-1 va vm-3 mashinalari hisoblash-0 da, vm-2 va vm-4 mashinalari hisoblash-1 tugunida joylashgan.
Bundan tashqari, ko'rsatilgan tarmoqlar o'rtasida marshrutlashni yoqish uchun virtual router yaratilgan:
(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 ~]$ Routerda ikkita virtual port mavjud bo'lib, ular tarmoqlar uchun shlyuz vazifasini bajaradi:
(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 ~]$ Biroq, trafik qanday oqishini ko'rib chiqishdan oldin, hozirda boshqaruv tugunida (bu ham tarmoq tugunidir) va hisoblash tugunida nima borligini ko'rib chiqaylik. Hisoblash tugunidan boshlaylik.
[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 ~]$Hozirgi vaqtda tugunda uchta ovs ko'prigi mavjud - br-int, br-tun, br-ex. Ularning o'rtasida, biz ko'rib turganimizdek, interfeyslar to'plami mavjud. Tushunish qulayligi uchun keling, ushbu interfeyslarning barchasini diagrammada chizamiz va nima sodir bo'lishini ko'rib chiqamiz.
VxLAN tunnellari ko'tarilgan manzillarga qarab, bitta tunnel hisoblash-1 (192.168.255.26), ikkinchi tunnel boshqaruv-1 (192.168.255.15) ga ko'tarilganligini ko'rish mumkin. Ammo eng qizig'i shundaki, br-ex-da jismoniy interfeyslar yo'q va agar siz qanday oqimlar sozlanganiga qarasangiz, bu ko'prik hozirda faqat trafikni kamaytirishi mumkinligini ko'rishingiz mumkin.
[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 ~]$ Chiqishdan ko'rinib turibdiki, manzil virtual ko'prik interfeysiga emas, balki to'g'ridan-to'g'ri jismoniy portga vidalanadi.
[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 ~]$
Birinchi qoidaga ko'ra, phy-br-ex portidan kelgan hamma narsa tashlanishi kerak.
Haqiqatan ham, hozirda ushbu interfeysdan (br-int bilan interfeys) tashqari trafik bu ko'prikga kirish uchun boshqa joy yo'q va pasayishlarga qaraganda, BUM trafig'i allaqachon ko'prik ichiga uchib ketgan.
Ya'ni, trafik bu tugunni faqat VxLAN tunnel orqali tark etishi mumkin va boshqa hech narsa yo'q. Biroq, agar siz DVR-ni yoqsangiz, vaziyat o'zgaradi, lekin biz buni boshqa safar hal qilamiz. Tarmoq izolyatsiyasidan foydalanganda, masalan, vlan-lardan foydalanganda, siz vlan 3-da bitta L0 interfeysiga emas, balki bir nechta interfeyslarga ega bo'lasiz. Biroq, VxLAN trafigi tugunni xuddi shu tarzda tark etadi, lekin u qandaydir bag'ishlangan vlanda inkapsullanadi.
Biz hisoblash tugunini saralab oldik, keling, boshqaruv tuguniga o'tamiz.
[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 ~]$Aslida, biz hamma narsani bir xil deb aytishimiz mumkin, lekin IP-manzil endi jismoniy interfeysda emas, balki virtual ko'prikda. Bu amalga oshiriladi, chunki bu port trafik tashqi dunyoga chiqadigan portdir.
[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 ~]$ Ushbu port br-ex ko'prigiga bog'langan va unda vlan teglari yo'qligi sababli, bu port magistral port bo'lib, unda barcha vlanlarga ruxsat beriladi, endi trafik yorliqsiz tashqariga chiqadi, bu esa vlan-id 0 da ko'rsatilgan. yuqoridagi chiqish.
Ayni paytda hamma narsa hisoblash tuguniga o'xshaydi - bir xil ko'priklar, ikkita hisoblash tuguniga o'tadigan bir xil tunnellar.
Biz ushbu maqolada saqlash tugunlarini ko'rib chiqmaymiz, ammo tushunish uchun shuni aytish kerakki, ushbu tugunlarning tarmoq qismi sharmandalik darajasiga qadar banaldir. Bizning holatda, IP-manzil tayinlangan faqat bitta jismoniy port (eth0) mavjud va bu ham. VxLAN tunnellari, tunnel ko'priklari va boshqalar yo'q - umuman ovs yo'q, chunki unda hech qanday ma'no yo'q. Tarmoq izolatsiyasidan foydalanganda, bu tugun ikkita interfeysga ega bo'ladi (jismoniy portlar, bodny yoki faqat ikkita vlan - bu muhim emas - bu sizning xohishingizga bog'liq) - biri boshqaruv uchun, ikkinchisi trafik uchun (VM diskiga yozish) , diskdan o'qish va boshqalar)
Hech qanday xizmatlar yo'qligida biz tugunlarda nima borligini aniqladik. Keling, 4 ta virtual mashinani ishga tushiramiz va yuqorida tavsiflangan sxema qanday o'zgarishini ko'rib chiqamiz - bizda portlar, virtual routerlar va boshqalar bo'lishi kerak.
Hozircha bizning tarmog'imiz quyidagicha ko'rinadi:
Har bir kompyuter tugunida ikkita virtual mashinamiz mavjud. Misol sifatida hisoblash-0 dan foydalanib, keling, hamma narsa qanday kiritilganligini ko'rib chiqaylik.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Mashinada faqat bitta virtual interfeys mavjud - 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 ~]$
Ushbu interfeys Linux ko'prigida ko'rinadi:
[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 ~]$ Chiqishdan ko'rinib turibdiki, ko'prikda faqat ikkita interfeys mavjud - tap95d96a75-a0 va qvb95d96a75-a0.
Bu erda OpenStack-da virtual tarmoq qurilmalari turlari haqida bir oz to'xtalib o'tishga arziydi:
vtap - nusxaga biriktirilgan virtual interfeys (VM)
qbr - Linux ko'prigi
qvb va qvo - vEth juftligi Linux ko'prigi va Open vSwitch ko'prigiga ulangan
br-int, br-tun, br-vlan — vSwitch koʻpriklarini oching
patch-, int-br-, phy-br- - ko'priklarni bog'laydigan vSwitch patch interfeyslarini oching
qg, qr, ha, fg, sg - OVSga ulanish uchun virtual qurilmalar tomonidan ishlatiladigan vSwitch portlarini ochish
Siz tushunganingizdek, agar bizda vEth juftligi bo'lgan ko'prikda qvb95d96a75-a0 porti bo'lsa, unda bir joyda uning hamkasbi bor, uni mantiqan qvo95d96a75-a0 deb atash kerak. Keling, OVSda qanday portlar borligini ko'rib chiqaylik.
[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 ~]$ Ko'rib turganimizdek, port br-intda. Br-int virtual mashina portlarini tugatuvchi kalit vazifasini bajaradi. Qvo95d96a75-a0 ga qo'shimcha ravishda qvo5bd37136-47 porti chiqishda ko'rinadi. Bu ikkinchi virtual mashinaning porti. Natijada, bizning diagrammamiz quyidagicha ko'rinadi:
Diqqatli o'quvchini darhol qiziqtiradigan savol - virtual mashina porti va OVS porti o'rtasidagi Linux ko'prigi nima? Haqiqat shundaki, mashinani himoya qilish uchun xavfsizlik guruhlari qo'llaniladi, ular iptablesdan boshqa narsa emas. OVS iptables bilan ishlamaydi, shuning uchun bu "tayoqcha" ixtiro qilingan. Biroq, u eskirib bormoqda - uning o'rnini yangi nashrlarda conntrack egallaydi.
Ya'ni, oxir-oqibat sxema quyidagicha ko'rinadi:
Bitta L2 tarmog'ida bitta gipervisorda ikkita mashina
Ushbu ikkita VM bir xil L2 tarmog'ida va bitta gipervisorda joylashganligi sababli, ular orasidagi trafik mantiqiy ravishda br-int orqali mahalliy ravishda oqadi, chunki ikkala mashina ham bir xil VLANda bo'ladi:
[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 ~]$ Xuddi shu L2 tarmog'idagi turli xil gipervizorlarda ikkita mashina
Keling, bir xil L2 tarmog'idagi, ammo turli xil gipervizorlarda joylashgan ikkita mashina o'rtasida trafik qanday ketishini ko'rib chiqaylik. Rostini aytsam, hech narsa o'zgarmaydi, faqat gipervisorlar orasidagi trafik vxlan tunnelidan o'tadi. Keling, bir misolni ko'rib chiqaylik.
Biz trafikni kuzatadigan virtual mashinalar manzillari:
[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 ~]$ Biz hisoblash-0 da br-int-dagi yo'naltirish jadvaliga qaraymiz:
[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 ~]Trafik 2-portga o'tishi kerak - keling, u qanday port ekanligini ko'rib chiqaylik:
[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 ~]$Bu patch-tun - ya'ni br-tundagi interfeys. Keling, br-tun-dagi paket bilan nima sodir bo'lishini ko'rib chiqaylik:
[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 ~]$ Paket VxLAN-ga qadoqlangan va 2-portga yuborilgan. Keling, 2-port qayerga olib borishini ko'rib chiqaylik:
[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 ~]$Bu 1-kompyuterdagi vxlan tunnel:
[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 ~]$Keling, hisoblash-1 ga o'tamiz va paket bilan keyin nima bo'lishini ko'ramiz:
[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-kompyuterda br-int yo'naltirish jadvalida joylashgan va yuqoridagi chiqishdan ko'rinib turibdiki, u br-tun porti bo'lgan 2-port orqali ko'rinadi:
[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:46Xo'sh, unda biz br-int-da 1-kompyuterda maqsadli ko'knori mavjudligini ko'ramiz:
[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 ~]$ Ya'ni, qabul qilingan paket 3-portga uchadi, uning orqasida allaqachon virtual mashina misoli-00000003 mavjud.
Virtual infratuzilmada o'rganish uchun Openstack-ni qo'llashning go'zalligi shundaki, biz gipervisorlar orasidagi trafikni osongina yozib olishimiz va u bilan nima sodir bo'layotganini ko'rishimiz mumkin. Endi biz shunday qilamiz, vnet portida tcpdump-ni hisoblash-0 tomon ishga tushiramiz:
[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*******************Birinchi qatorda Patek 10.0.1.85 manzilidan 10.0.1.88 (ICMP trafiki) manziliga o'tishi va u vni 22 bilan VxLAN paketiga o'ralganligini va paket 192.168.255.19 (hisoblash-0) xostidan 192.168.255.26 xostiga o'tishini ko'rsatadi. .1 (hisoblash-XNUMX). VNI ovlarda ko'rsatilganiga mos kelishini tekshirishimiz mumkin.
Keling, ushbu qatorga qaytaylik actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 - o'n oltilik sanoq sistemasidagi vni. Keling, bu raqamni 16-tizimga aylantiramiz:
16 = 6*16^0+1*16^1 = 6+16 = 22Ya'ni, vni haqiqatga mos keladi.
Ikkinchi qatorda qaytib keladigan trafik ko'rsatilgan, yaxshi, buni tushuntirishning ma'nosi yo'q, u erda hamma narsa aniq.
Turli tarmoqlardagi ikkita mashina (tarmoqlararo marshrutlash)
Bugungi kun uchun oxirgi holat virtual router yordamida bitta loyiha doirasidagi tarmoqlar o'rtasida marshrutlashdir. Biz DVRsiz ishni ko'rib chiqamiz (biz uni boshqa maqolada ko'rib chiqamiz), shuning uchun marshrutlash tarmoq tugunida sodir bo'ladi. Bizning holatda, tarmoq tuguni alohida ob'ektga joylashtirilmaydi va boshqaruv tugunida joylashgan.
Birinchidan, marshrutlash qanday ishlashini ko'rib chiqaylik:
$ 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 msBunday holda, paket shlyuzga borishi va u erga yo'naltirilishi kerakligi sababli, biz shlyuzning MAC manzilini aniqlashimiz kerak, buning uchun biz misolda ARP jadvalini ko'rib chiqamiz:
$ 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 eth0Endi maqsadli (10.0.1.254) fa:16:3e:c4:64:70 bilan trafik qaerga yuborilishi kerakligini ko'rib chiqamiz:
[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 ~]$ Keling, 2-port qayerga olib borishini ko'rib chiqaylik:
[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 ~]$ Har bir narsa mantiqiy, transport br-tunga ketadi. Keling, u qaysi vxlan tunneliga o'ralganligini ko'rib chiqaylik:
[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 ~]$ Uchinchi port vxlan tunnelidir:
[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 ~]$ Bu boshqaruv tuguniga qaraydi:
[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 ~]$ Trafik boshqaruv tuguniga yetib keldi, shuning uchun biz unga borib, marshrutlash qanday sodir bo'lishini ko'rishimiz kerak.
Esingizda bo'lsa, ichidagi boshqaruv tuguni hisoblash tuguniga o'xshab ko'rinardi - bir xil uchta ko'prik, faqat br-exda jismoniy port mavjud bo'lib, u orqali tugun tashqi trafikni jo'natishi mumkin edi. Misollarni yaratish hisoblash tugunlaridagi konfiguratsiyani o'zgartirdi - tugunlarga linux ko'prigi, iptables va interfeyslar qo'shildi. Tarmoqlar va virtual yo'riqnoma yaratilishi boshqaruv tugunining konfiguratsiyasida ham o'z izini qoldirdi.
Shunday qilib, shlyuz MAC manzili boshqaruv tugunidagi br-int uzatish jadvalida bo'lishi kerakligi aniq. Keling, u borligini va qayerga qaraganini tekshirib ko'raylik:
[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 portidan ko'rinadi. Agar Openstack-dagi virtual portlar ro'yxatiga qaytadigan bo'lsak, bu turdagi port turli virtual qurilmalarni OVS ga ulash uchun ishlatiladi. Aniqroq qilib aytadigan bo'lsak, qr virtual routerning porti bo'lib, u nom maydoni sifatida taqdim etiladi.
Keling, serverda qanday nomlar maydoni mavjudligini ko'rib chiqaylik:
[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 ~]$ Uch nusxagacha. Ammo ismlarga qarab, ularning har birining maqsadini taxmin qilishingiz mumkin. Biz 0 va 1 identifikatorli misollarga keyinroq qaytamiz, endi biz qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe nom maydoniga qiziqamiz:
[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 ~]$ Bu nomlar maydonida biz avval yaratgan ikkita ichki nom mavjud. Ikkala virtual port ham br-int ga qo'shildi. Qr-0c52b15f-8f portining Mac manzilini tekshirib ko'raylik, chunki maqsad mac manziliga ko'ra trafik ushbu interfeysga o'tgan.
[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 ~]$ Ya'ni, bu holda, hamma narsa standart marshrutlash qonunlariga muvofiq ishlaydi. Trafik 10.0.2.8 xost uchun mo'ljallanganligi sababli, u ikkinchi qr-92fa49b5-54 interfeysi orqali chiqishi va vxlan tunnel orqali hisoblash tuguniga o'tishi kerak:
[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 ~]$ Hammasi mantiqiy, kutilmagan hodisalar yo'q. Keling, br-int-da 10.0.2.8 xostining ko'knori manzili qayerda ko'rinishini ko'rib chiqaylik:
[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 ~]$ Kutilganidek, trafik br-tunga boradi, keling, transport keyingi qaysi tunnelga borishini ko'raylik:
[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 ~]$ Trafik 1-hisoblash uchun tunnelga kiradi. Xo'sh, compute-1 da hamma narsa oddiy - br-tun dan paket br-int-ga va u erdan virtual mashina interfeysiga o'tadi:
[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 ~]$ Keling, bu haqiqatan ham to'g'ri interfeys ekanligini tekshirib ko'raylik:
[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 ~]$
Haqiqatan ham, biz paketni to'liq bosib o'tdik. O'ylaymanki, siz trafik turli vxlan tunnellaridan o'tib, turli VNIlar bilan chiqqanini payqadingiz. Keling, bu qanday VNI ekanligini ko'rib chiqaylik, shundan so'ng biz tugunning boshqaruv portiga axlat yig'amiz va trafik yuqorida tavsiflanganidek harakatlanishiga ishonch hosil qilamiz.
Shunday qilib, hisoblash-0 uchun tunnel quyidagi amallarga ega=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. 0x16 ni o‘nlik sanoq sistemasiga aylantiramiz:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Hisoblash-1 uchun tunnel quyidagi VNIga ega: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],chiqish:2. 0x63 ni o‘nlik sanoq sistemasiga aylantiramiz:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Xo'sh, endi axlatxonaga qaraylik:
[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*******************Birinchi paket 192.168.255.19 xostidan (hisoblash-0) vni 192.168.255.15 bilan 1 (nazorat-22) xostiga vxlan paketi bo‘lib, uning ichida ICMP paketi 10.0.1.85 xostidan 10.0.2.8 xostiga qadoqlangan. Yuqorida hisoblaganimizdek, vni chiqishda ko'rgan narsamizga mos keladi.
Ikkinchi paket 192.168.255.15 (nazorat-1) xostidan vni 192.168.255.26 bilan 1 (hisoblash-99) xostiga vxlan paketi bo‘lib, uning ichida ICMP paketi 10.0.1.85 xostidan 10.0.2.8 xostiga qadoqlangan. Yuqorida hisoblaganimizdek, vni chiqishda ko'rgan narsamizga mos keladi.
Keyingi ikkita paket 10.0.2.8 emas, balki 10.0.1.85 dan qaytariladigan trafikdir.
Ya'ni, oxirida biz quyidagi boshqaruv tugun sxemasini oldik:
Qarang, shundaymi? Biz ikkita nom maydonini unutdik:
[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 ~]$ Bulutli platformaning arxitekturasi haqida gapirganimizda, agar mashinalar manzillarni avtomatik ravishda DHCP serveridan olsa yaxshi bo'lardi. Bu bizning ikkita 10.0.1.0/24 va 10.0.2.0/24 tarmoqlarimiz uchun ikkita DHCP serveri.
Keling, bu haqiqat ekanligini tekshirib ko'raylik. Ushbu nom maydonida faqat bitta manzil mavjud - 10.0.1.1 - DHCP serverining manzili va u br-int tarkibiga ham kiritilgan:
[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 0Boshqarish tugunida qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ni o'z ichiga olgan jarayonlarni ko'rib chiqaylik:
[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 ~]$ Bunday jarayon mavjud va yuqorida keltirilgan ma'lumotlarga asoslanib, biz, masalan, hozirda ijaraga olingan narsalarni ko'rishimiz mumkin:
[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 ~]$Natijada, biz boshqaruv tugunida quyidagi xizmatlar to'plamini olamiz:
Xo'sh, yodda tuting - bu atigi 4 ta mashina, 2 ta ichki tarmoq va bitta virtual router... Bizda hozir tashqi tarmoqlar yo'q, har birining o'z tarmoqlari (bir-biriga o'xshash) bo'lgan bir qancha turli loyihalar mavjud va bizda mavjud taqsimlangan marshrutizator o'chirildi va oxir-oqibat, sinov dastgohida faqat bitta nazorat tugunlari bor edi (nosozlikka chidamlilik uchun uchta tugunning kvorum bo'lishi kerak). Tijoratda hamma narsa "biroz" murakkabroq bo'lishi mantiqan to'g'ri, ammo bu oddiy misolda biz bu qanday ishlashi kerakligini tushunamiz - sizda 3 yoki 300 nom bo'shlig'i bormi, albatta muhim, ammo butun tizimning ishlashi nuqtai nazaridan. tuzilma, hech narsa ko'p o'zgarmaydi ... garchi siz ba'zi sotuvchi SDN-ni ulamaysiz. Ammo bu butunlay boshqacha hikoya.
Umid qilamanki, bu qiziqarli bo'ldi. Agar sizda biron bir izoh/qo'shimcha bo'lsa yoki men yolg'on gapirgan bo'lsam (men odamman va mening fikrim har doim sub'ektiv bo'ladi) - tuzatish/qo'shish kerak bo'lgan narsalarni yozing - biz hamma narsani tuzatamiz/qo'shamiz.
Xulosa qilib aytganda, Openstackni (ham vanil, ham sotuvchini) VMWare bulutli yechimi bilan solishtirish haqida bir necha so'z aytmoqchiman - so'nggi bir necha yil ichida menga bu savol juda tez-tez berilgan va ochig'ini aytganda, men allaqachon charchagan, lekin baribir. Menimcha, bu ikki yechimni solishtirish juda qiyin, lekin biz aniq aytishimiz mumkinki, ikkala yechimda ham kamchiliklar mavjud va bitta yechimni tanlashda ijobiy va salbiy tomonlarini tortish kerak.
Agar OpenStack hamjamiyat tomonidan boshqariladigan yechim bo'lsa, u holda VMWare faqat o'zi xohlagan narsani qilish huquqiga ega (o'qing - u uchun nima foydali) va bu mantiqiy - chunki u o'z mijozlaridan pul ishlashga odatlangan tijorat kompaniyasi. Ammo bitta katta va semiz LEKIN - siz OpenStack-dan, masalan, Nokia-dan chiqib ketishingiz mumkin va ozgina xarajat bilan masalan, Juniper (Contrail Cloud) yechimiga o'tishingiz mumkin, ammo siz VMWare-dan chiqa olmaysiz. . Men uchun bu ikki yechim shunday ko'rinadi - Openstack (sotuvchi) siz qo'yiladigan oddiy qafas, lekin sizda kalit bor va siz xohlagan vaqtda chiqib ketishingiz mumkin. VMWare - bu oltin qafas, egasi qafas kalitiga ega va bu sizga juda qimmatga tushadi.
Men birinchi yoki ikkinchi mahsulotni targ'ib qilmayman - o'zingizga kerakli narsani tanlaysiz. Ammo agar menda shunday tanlov bo'lsa, men ikkala yechimni tanlagan bo'lardim - IT buluti uchun VMWare (past yuk, oson boshqaruv), ba'zi sotuvchilardan OpenStack (Nokia va Juniper juda yaxshi kalit echimlarni taqdim etadi) - Telecom buluti uchun. Men Openstack-ni sof IT uchun ishlatmagan bo'lardim - bu to'p bilan chumchuqlarni otishga o'xshaydi, lekin men uni ishlatishda ortiqchalikdan boshqa hech qanday kontrendikatsiyani ko'rmayapman. Biroq, telekommunikatsiyada VMWare’dan foydalanish Ford Raptor’da maydalangan toshni tashishga o‘xshaydi – bu tashqi tomondan chiroyli, lekin haydovchi bitta emas, 10 marta sayohat qilishi kerak.
Menimcha, VMWare-ning eng katta kamchiligi uning to'liq yopiqligidir - kompaniya sizga uning qanday ishlashi haqida hech qanday ma'lumot bermaydi, masalan, vSAN yoki gipervizor yadrosida nima bor - bu shunchaki foyda keltirmaydi - ya'ni siz hech qachon VMWare-da mutaxassis bo'lmang - sotuvchining yordamisiz siz halokatga duchor bo'lasiz (ko'pincha men arzimas savollarga hayron bo'lgan VMWare mutaxassislarini uchrataman). Men uchun VMWare kapoti qulflangan mashina sotib olmoqda - ha, sizda vaqt kamarini o'zgartira oladigan mutaxassislar bo'lishi mumkin, ammo faqat sizga ushbu yechimni sotgan kishi kapotni ochishi mumkin. Shaxsan men o'zim sig'maydigan yechimlarni yoqtirmayman. Siz kaput ostiga kirishingiz shart emasligini aytasiz. Ha, bu mumkin, lekin siz bulutda 20-30 virtual mashinadan, 40-50 ta tarmoqdan, yarmi tashqariga chiqmoqchi bo'lgan, ikkinchi yarmi esa talab qiladigan katta funktsiyani yig'ishingiz kerak bo'lganda sizga qarayman. SR-IOV tezlashuvi, aks holda sizga bir nechta o'nlab mashinalar kerak bo'ladi - aks holda unumdorlik etarli bo'lmaydi.
Boshqa nuqtai nazarlar ham bor, shuning uchun faqat siz nimani tanlashni hal qilishingiz mumkin va eng muhimi, keyin siz o'zingizning tanlovingiz uchun javobgar bo'lasiz. Bu faqat mening fikrim - Nokia, Juniper, Red Hat va VMWare-ni kamida 4 ta mahsulotni ko'rgan va qo'llagan odam. Ya'ni, mening solishtiradigan narsam bor.
Manba: www.habr.com