Mākoņdatošana arvien dziļāk iekļūst mūsu dzīvē, un, iespējams, nav neviena cilvēka, kurš kaut reizi nebūtu izmantojis mākoņpakalpojumus. Taču, kas īsti ir mākonis un kā tas darbojas, pat idejas līmenī zina retais. 5G jau kļūst par realitāti, un telekomunikāciju infrastruktūra sāk pāriet no polu risinājumiem uz mākoņa risinājumiem, tāpat kā tad, kad tā no pilnībā aparatūras risinājumiem pārcēlās uz virtualizētiem "pīlāriem".
Šodien mēs runāsim par mākoņa infrastruktūras iekšējo pasauli, jo īpaši mēs apskatīsim tīkla daļas pamatus.
Kas ir mākonis? Tā pati virtualizācija - profila skats?
Vairāk nekā loģisks jautājums. Nē – tā nav virtualizācija, lai gan bez tās nevarētu iztikt. Apskatīsim divas definīcijas:
Mākoņdatošana (turpmāk tekstā – mākonis) ir modelis lietotājam draudzīgas piekļuves nodrošināšanai izkliedētajiem skaitļošanas resursiem, kas pēc pieprasījuma ir jāizvieto un jāpalaiž ar iespējami zemāko latentumu un minimālām izmaksām pakalpojumu sniedzējam.
Virtualizācija - tā ir iespēja sadalīt vienu fizisko entītiju (piemēram, serveri) vairākās virtuālajās, tādējādi palielinot resursu izmantošanu (piemēram, jums bija 3 serveri noslogoti ar 25-30 procentiem, pēc virtualizācijas jūs saņemat 1 servera ielādi par 80-90 procentiem). Protams, virtualizācija patērē daļu resursu - jums ir jāpabaro hipervizors, tomēr, kā rāda prakse, spēle ir sveces vērta. Ideāls virtualizācijas piemērs ir VMWare, kas lieliski sagatavo virtuālās mašīnas vai piemēram KVM, kam es dodu priekšroku, bet tā ir gaumes lieta.
Mēs izmantojam virtualizāciju, to neapzinoties, un pat dzelzs maršrutētāji jau izmanto virtualizāciju - piemēram, jaunākajā JunOS versijā operētājsistēma ir instalēta kā virtuāla mašīna virs reāllaika Linux izplatīšanas (Wind River 9). Bet virtualizācija nav mākonis, bet mākonis nevar pastāvēt bez virtualizācijas.
Virtualizācija ir viens no elementiem, uz kura tiek veidots mākonis.
Mākoņa izveide, vienkārši savācot vairākus hipervizorus vienā L2 domēnā, pievienojot pāris yaml rokasgrāmatas, lai automātiski reģistrētu vlans, izmantojot kaut kādu ansible, un tam visam iesprūdot kaut ko, piemēram, orķestrēšanas sistēmu, lai automātiski izveidotu virtuālās mašīnas. Tas būs precīzāk, taču iegūtais Frankenšteins nav mums vajadzīgais mākonis, lai gan tas var būt galvenais sapnis citiem. Turklāt, ja ņemat to pašu Openstack, tas būtībā joprojām ir Frankenšteins, bet, labi, par to pagaidām nerunāsim.
Bet es saprotu, ka no iepriekš sniegtās definīcijas nav pilnīgi skaidrs, ko patiesībā var saukt par mākoni.
Tāpēc NIST (Nacionālais standartu un tehnoloģiju institūts) dokumentā ir sniegti 5 galvenie raksturlielumi, kādiem jābūt mākoņa infrastruktūrai:
Pakalpojumu sniegšana pēc pieprasījuma. Lietotājam ir jānodrošina brīva pieeja viņam piešķirtajiem datora resursiem (piemēram, tīkliem, virtuālajiem diskiem, atmiņai, procesora kodoliem utt.), un šie resursi ir jānodrošina automātiski – tas ir, bez pakalpojumu sniedzēja iejaukšanās.
Plaša pakalpojuma pieejamība. Piekļuve resursiem jānodrošina ar standarta mehānismiem, kas ļautu izmantot gan standarta personālos datorus, gan plānos klientus un mobilās ierīces.
Resursu apvienošana baseinos. Resursu kopumiem jāspēj vienlaikus nodrošināt resursus vairākiem klientiem, nodrošinot, ka klienti ir izolēti un brīvi no savstarpējas ietekmes un konkurences par resursiem. Pūlos ir iekļauti arī tīkli, kas norāda uz iespēju izmantot pārklājošu adresāciju. Baseinus jāspēj pielāgot pēc pieprasījuma. Pūlu izmantošana ļauj nodrošināt nepieciešamo resursu kļūdu tolerances līmeni un fizisko un virtuālo resursu abstrakciju - pakalpojuma saņēmējam vienkārši tiek nodrošināts viņa pieprasītais resursu kopums (kur šie resursi fiziski atrodas, cik daudz serveri un slēdži - klientam tas nav svarīgi). Taču jāņem vērā fakts, ka pakalpojumu sniedzējam ir jānodrošina pārskatāma šo resursu rezervēšana.
Ātra pielāgošanās dažādiem apstākļiem. Pakalpojumiem ir jābūt elastīgiem - ātra resursu nodrošināšana, to pārdale, resursu pievienošana vai samazināšana pēc klienta pieprasījuma, un no klienta puses ir jābūt sajūtai, ka mākoņa resursi ir bezgalīgi. Lai atvieglotu izpratni, piemēram, jūs neredzat brīdinājumu, ka daļa no jūsu diska vietas pakalpojumā Apple iCloud ir pazudusi, jo servera cietais disks ir sabojājies un diskdziņi sabojājas. Turklāt no jūsu puses šī servisa iespējas ir gandrīz neierobežotas - vajag 2 TB - nekādu problēmu, samaksājāt un saņēmāt. Līdzīgu piemēru var sniegt ar Google.Drive vai Yandex.Disk.
Iespēja izmērīt sniegto pakalpojumu. Mākoņsistēmām ir automātiski jākontrolē un jāoptimizē patērētie resursi, un šiem mehānismiem ir jābūt pārskatāmiem gan lietotājam, gan pakalpojuma sniedzējam. Tas nozīmē, ka jūs vienmēr varat pārbaudīt, cik daudz resursu jūs un jūsu klienti patērē.
Ir vērts ņemt vērā faktu, ka šīs prasības pārsvarā ir prasības publiskajam mākonim, tāpēc privātajam mākonim (tas ir, uzņēmuma iekšējām vajadzībām palaistajam mākonim) šīs prasības var nedaudz koriģēt. Tomēr tie joprojām ir jādara, pretējā gadījumā mēs neiegūsim visas mākoņdatošanas priekšrocības.
Kāpēc mums ir vajadzīgs mākonis?
Tomēr jebkura jauna vai esoša tehnoloģija, jebkurš jauns protokols tiek radīts kaut kam (nu, protams, izņemot RIP-ng). Protokols nevienam nav vajadzīgs protokola dēļ (nu, protams, izņemot RIP-ng). Loģiski, ka mākonis ir izveidots, lai sniegtu lietotājam/klientam kādu pakalpojumu. Mēs visi esam pazīstami ar vismaz pāris mākoņpakalpojumiem, piemēram, Dropbox vai Google.Docs, un es uzskatu, ka lielākā daļa cilvēku tos izmanto veiksmīgi – piemēram, šis raksts tika uzrakstīts, izmantojot Google.Docs mākoņpakalpojumu. Taču mums zināmie mākoņpakalpojumi ir tikai daļa no mākoņa iespējām — precīzāk, tie ir tikai SaaS tipa pakalpojumi. Mēs varam nodrošināt mākoņpakalpojumu trīs veidos: SaaS, PaaS vai IaaS veidā. Tas, kāds pakalpojums jums ir nepieciešams, ir atkarīgs no jūsu vēlmēm un iespējām.
Apskatīsim katru secībā:
Programmatūra kā pakalpojums (SaaS) ir modelis pilnvērtīga pakalpojuma sniegšanai klientam, piemēram, e-pasta pakalpojums, piemēram, Yandex.Mail vai Gmail. Šajā pakalpojuma sniegšanas modelī jūs kā klients faktiski neko nedara, izņemot pakalpojumu izmantošanu – tas ir, jums nav jādomā par pakalpojuma iestatīšanu, tā kļūdu toleranci vai dublēšanu. Galvenais ir neapdraudēt savu paroli; pārējo jūsu vietā paveiks šī pakalpojuma sniedzējs. No pakalpojumu sniedzēja viedokļa viņš ir pilnībā atbildīgs par visu pakalpojumu - no servera aparatūras un resursdatora operētājsistēmām līdz datu bāzes un programmatūras iestatījumiem.
Platforma kā pakalpojums (PaaS) — izmantojot šo modeli, pakalpojumu sniedzējs nodrošina klientam pakalpojuma sagatavi, piemēram, ņemsim Web serveri. Pakalpojuma sniedzējs nodrošināja klientam virtuālo serveri (patiesībā resursu kopumu, piemēram, RAM/CPU/Storage/Nets u.c.) un pat instalēja šajā serverī OS un nepieciešamo programmatūru, tomēr visu šo lietu dara pats klients un par pakalpojuma izpildi klients atbild. Pakalpojuma sniedzējs, tāpat kā iepriekšējā gadījumā, ir atbildīgs par fiziskā aprīkojuma, hipervizoru, pašas virtuālās mašīnas darbību, tās tīkla pieejamību utt., bet pats pakalpojums vairs nav tā atbildības jomā.
Infrastruktūra kā pakalpojums (IaaS) - šī pieeja jau ir interesantāka, faktiski pakalpojumu sniedzējs nodrošina klientam pilnīgu virtualizētu infrastruktūru - tas ir, kādu resursu kopumu (kopu), piemēram, CPU kodoli, RAM, tīkli utt. Viss pārējais ir atkarīgs no klients - ko klients vēlas darīt ar šiem resursiem piešķirtā pūla (kvotas) ietvaros - piegādātājam tas nav īpaši svarīgi. Neatkarīgi no tā, vai klients vēlas izveidot savu vEPC vai pat izveidot mini operatoru un sniegt sakaru pakalpojumus - bez šaubām - dariet to. Šādā gadījumā pakalpojumu sniedzējs ir atbildīgs par resursu nodrošināšanu, to kļūdu toleranci un pieejamību, kā arī OS, kas ļauj apvienot šos resursus un padarīt tos pieejamus klientam ar iespēju jebkurā laikā palielināt vai samazināt resursus. pēc klienta pieprasījuma. Klients pats konfigurē visas virtuālās mašīnas un citus sīkumus, izmantojot pašapkalpošanās portālu un konsoli, ieskaitot tīklu iestatīšanu (izņemot ārējos tīklus).
Kas ir OpenStack?
Visās trīs opcijās pakalpojuma sniedzējam ir nepieciešama OS, kas ļaus izveidot mākoņa infrastruktūru. Faktiski ar SaaS vairāk nekā viena nodaļa ir atbildīga par visu tehnoloģiju kaudzi - ir nodaļa, kas ir atbildīga par infrastruktūru - tas ir, tā nodrošina IaaS citai nodaļai, šī nodaļa nodrošina SaaS klientam. OpenStack ir viena no mākoņa operētājsistēmām, kas ļauj apkopot virkni slēdžu, serveru un uzglabāšanas sistēmu vienā resursu baseinā, sadalīt šo kopējo kopu apakšpulkos (īrniekiem) un nodrošināt šos resursus klientiem tīklā.
OpenStack ir mākoņa operētājsistēma, kas ļauj kontrolēt lielus skaitļošanas resursu, datu krātuves un tīkla resursu kopumus, kas nodrošināti un pārvaldīti, izmantojot API, izmantojot standarta autentifikācijas mehānismus.
Citiem vārdiem sakot, šis ir bezmaksas programmatūras projektu kopums, kas paredzēts mākoņpakalpojumu (gan publisko, gan privāto) izveidošanai - tas ir, rīku komplekts, kas ļauj apvienot serveri un komutācijas iekārtas vienā resursu kopumā, pārvaldīt. šos resursus, nodrošinot nepieciešamo kļūdu tolerances līmeni.
Šī materiāla rakstīšanas laikā OpenStack struktūra izskatās šādi:
Bilde uzņemta no
Katrs no OpenStack komponentiem veic noteiktu funkciju. Šī izplatītā arhitektūra ļauj risinājumā iekļaut nepieciešamo funkcionālo komponentu komplektu. Tomēr daži komponenti ir saknes komponenti, un to noņemšana novedīs pie risinājuma kā veseluma pilnīgas vai daļējas nedarbošanās. Šīs sastāvdaļas parasti klasificē šādi:
- Mans Profils — Tīmekļa GUI OpenStack pakalpojumu pārvaldībai
- Pamatprincips ir centralizēts identitātes pakalpojums, kas nodrošina autentifikācijas un autorizācijas funkcionalitāti citiem pakalpojumiem, kā arī lietotāju akreditācijas datu un viņu lomu pārvaldību.
- neitronu - tīkla pakalpojums, kas nodrošina savienojamību starp dažādu OpenStack pakalpojumu saskarnēm (tostarp savienojamību starp virtuālajām mašīnām un to piekļuvi ārpasaulei)
- Plēnes — nodrošina piekļuvi virtuālo mašīnu bloku krātuvei
- jaunums — virtuālo mašīnu dzīves cikla pārvaldība
- Skatiens — virtuālās mašīnas attēlu un momentuzņēmumu krātuve
- Swift kods — nodrošina piekļuvi krātuves objektam
- Celometrs — pakalpojums, kas nodrošina iespēju apkopot telemetriju un izmērīt pieejamos un patērētos resursus
- Siltums — uz veidnēm balstīta orķestrēšana resursu automātiskai izveidei un nodrošināšanai
Pilns visu projektu saraksts un to mērķis ir apskatāms .
Katrs OpenStack komponents ir pakalpojums, kas veic noteiktu funkciju un nodrošina API, lai pārvaldītu šo funkciju un mijiedarbotos ar citiem mākoņa operētājsistēmas pakalpojumiem, lai izveidotu vienotu infrastruktūru. Piemēram, Nova nodrošina skaitļošanas resursu pārvaldību un API, lai piekļūtu šo resursu konfigurēšanai, Glance nodrošina attēlu pārvaldību un API to pārvaldībai, Cinder nodrošina bloku krātuvi un API to pārvaldībai utt. Visas funkcijas ir savstarpēji ļoti cieši saistītas.
Tomēr, ja paskatās uz to, visi pakalpojumi, kas darbojas OpenStack, galu galā ir sava veida virtuālā mašīna (vai konteiners), kas savienots ar tīklu. Rodas jautājums – kāpēc mums vajag tik daudz elementu?
Apskatīsim algoritmu, lai izveidotu virtuālo mašīnu un savienotu to ar tīklu un pastāvīgo krātuvi programmā Openstack.
- Kad veidojat pieprasījumu izveidot mašīnu, neatkarīgi no tā, vai tas ir pieprasījums, izmantojot Horizon (informācijas paneli) vai pieprasījums, izmantojot CLI, pirmā lieta, kas notiek, ir jūsu pieprasījuma autorizācija Keystone — vai varat izveidot mašīnu, vai tai ir tiesības izmantot šo tīklu, vai jūsu kvotas projekts utt.
- Keystone autentificē jūsu pieprasījumu un atbildes ziņojumā ģenerē autentifikācijas pilnvaru, kas tiks izmantota turpmāk. Saņemot atbildi no Keystone, pieprasījums tiek nosūtīts uz Nova (nova api).
- Nova-api pārbauda jūsu pieprasījuma derīgumu, sazinoties ar Keystone, izmantojot iepriekš ģenerētu autentifikācijas pilnvaru
- Keystone veic autentifikāciju un sniedz informāciju par atļaujām un ierobežojumiem, pamatojoties uz šo autentifikācijas pilnvaru.
- Nova-api izveido jaunās virtuālās mašīnas ierakstu nova-database un nosūta pieprasījumu izveidot mašīnu nova-scheduler.
- Nova-scheduler atlasa resursdatoru (datora mezglu), uz kura tiks izvietota virtuālā mašīna, pamatojoties uz norādītajiem parametriem, svariem un zonām. Ieraksts par šo un virtuālās mašīnas ID tiek ierakstīts nova-database.
- Pēc tam nova-scheduler sazinās ar nova-compute ar pieprasījumu izvietot gadījumu. Nova-compute sazinās ar nova-conductor, lai iegūtu informāciju par mašīnas parametriem (nova-conductor ir nova elements, kas darbojas kā starpniekserveris starp nova-database un nova-compute, ierobežojot pieprasījumu skaitu nova-database, lai izvairītos no problēmām ar datu bāzi konsistences slodzes samazināšana).
- Nova-conductor saņem pieprasīto informāciju no nova-database un nodod to nova-compute.
- Pēc tam nova-compute zvani, lai iegūtu attēla ID. Glace apstiprina pieprasījumu Keystone un atgriež pieprasīto informāciju.
- Nova-compute sazinās ar neitronu, lai iegūtu informāciju par tīkla parametriem. Līdzīgi kā skatiens, neitrons apstiprina pieprasījumu Keystone, pēc tam izveido ierakstu datu bāzē (porta identifikatoru utt.), izveido pieprasījumu izveidot portu un atgriež pieprasīto informāciju nova-compute.
- Nova-compute sazinās ar lūgumu piešķirt sējumu virtuālajai mašīnai. Līdzīgi kā skatiens, sidrs apstiprina pieprasījumu Keystone, izveido sējuma izveides pieprasījumu un atgriež pieprasīto informāciju.
- Nova-compute sazinās ar libvirt ar pieprasījumu izvietot virtuālo mašīnu ar norādītajiem parametriem.
Patiesībā šķietami vienkārša vienkāršas virtuālās mašīnas izveides darbība pārvēršas par šādu API zvanu virpuli starp mākoņa platformas elementiem. Turklāt, kā redzat, pat iepriekš noteiktie pakalpojumi sastāv no mazākiem komponentiem, starp kuriem notiek mijiedarbība. Mašīnas izveide ir tikai neliela daļa no tā, ko mākoņa platforma ļauj darīt – ir pakalpojums, kas atbild par trafika līdzsvarošanu, pakalpojums, kas atbild par bloku krātuvi, pakalpojums, kas atbild par DNS, pakalpojums, kas atbild par tukša metāla serveru nodrošināšanu utt. Mākonis ļauj jums izturēties pret virtuālajām mašīnām kā pret aitu ganāmpulku (pretstatā virtualizācijai). Ja kaut kas notiek ar jūsu mašīnu virtuālajā vidē - jūs to atjaunojat no dublējumkopijām utt., bet mākoņa aplikācijas ir uzbūvētas tā, ka virtuālā mašīna nespēlē tik svarīgu lomu - virtuālā mašīna "nomira" - nav problēmu - vienkārši tiek izveidots jauns, transportlīdzeklis ir balstīts uz veidni, un, kā saka, komanda nepamanīja cīnītāja zaudējumu. Protams, tas nodrošina orķestrēšanas mehānismu klātbūtni - izmantojot Heat veidnes, jūs varat viegli izvietot sarežģītu funkciju, kas sastāv no desmitiem tīklu un virtuālo mašīnu.
Vienmēr ir vērts paturēt prātā, ka nav mākoņa infrastruktūras bez tīkla – katrs elements tādā vai citādā veidā mijiedarbojas ar citiem elementiem caur tīklu. Turklāt mākonim ir absolūti nestatisks tīkls. Dabiski, ka apakštīkls ir pat vairāk vai mazāk statisks - jauni mezgli un slēdži netiek pievienoti katru dienu, bet pārklājuma komponents var un neizbēgami mainīsies pastāvīgi - tiks pievienoti vai dzēsti jauni tīkli, parādīsies jaunas virtuālās mašīnas un vecās. mirt. Un, kā jūs atceraties no mākoņa definīcijas, kas sniegta pašā raksta sākumā, resursi lietotājam ir jāpiešķir automātiski un ar vismazāko (vai vēl labāk, bez) pakalpojumu sniedzēja iejaukšanās. Tas nozīmē, ka tīkla resursu nodrošināšanas veids, kas tagad pastāv priekšgala veidā jūsu personīgā konta veidā, kuram var piekļūt, izmantojot http/https, un dežurējošais tīkla inženieris Vasilijs kā aizmugursistēma nav mākonis, pat ja Vasilijam ir astoņas rokas.
Neutron kā tīkla pakalpojums nodrošina API mākoņa infrastruktūras tīkla daļas pārvaldīšanai. Pakalpojums nodrošina un pārvalda Openstack tīkla daļu, nodrošinot abstrakcijas slāni ar nosaukumu Network-as-a-Service (NaaS). Tas nozīmē, ka tīkls ir tāda pati virtuālā izmērāmā vienība kā, piemēram, virtuālie CPU kodoli vai RAM apjoms.
Bet pirms pāriet uz OpenStack tīkla daļas arhitektūru, apskatīsim, kā šis tīkls darbojas OpenStack un kāpēc tīkls ir svarīga un neatņemama mākoņa sastāvdaļa.
Tātad mums ir divas RED klientu virtuālās mašīnas un divas GREEN klienta virtuālās mašīnas. Pieņemsim, ka šīs mašīnas atrodas uz diviem hipervizoriem šādā veidā:
Šobrīd tā ir tikai 4 serveru virtualizācija un nekas vairāk, jo līdz šim viss, ko esam paveikuši, ir virtualizējuši 4 serverus, novietojot tos uz diviem fiziskajiem serveriem. Un līdz šim tie pat nav savienoti ar tīklu.
Lai izveidotu mākoni, mums jāpievieno vairāki komponenti. Pirmkārt, mēs virtualizējam tīkla daļu - mums ir jāsavieno šīs 4 mašīnas pa pāriem, un klienti vēlas L2 savienojumu. Varat izmantot slēdzi un konfigurēt maģistrāli tā virzienā un atrisināt visu, izmantojot linux tiltu vai, pieredzējušākiem lietotājiem, openvswitch (pie tā atgriezīsimies vēlāk). Taču tīklu var būt daudz, un nepārtraukta L2 stumšana caur slēdzi nav tā labākā ideja – ir dažādas nodaļas, apkalpošanas galds, mēnešiem ilgi jāgaida, līdz tiks pabeigta lietojumprogramma, nedēļām ilga problēmu novēršana – mūsdienu pasaulē tas ir pieeja vairs nedarbojas. Un jo ātrāk uzņēmums to saprot, jo vieglāk tam ir virzīties uz priekšu. Tāpēc starp hipervizoriem mēs izvēlēsimies L3 tīklu, caur kuru sazināsies mūsu virtuālās mašīnas, un papildus šim L3 tīklam mēs izveidosim virtuālos L2 pārklājuma tīklus, kuros darbosies mūsu virtuālo mašīnu trafiks. Kā iekapsulēšanu varat izmantot GRE, Geneve vai VxLAN. Pagaidām pievērsīsimies pēdējam, lai gan tas nav īpaši svarīgi.
Mums kaut kur jāatrod VTEP (es ceru, ka visi ir pazīstami ar VxLAN terminoloģiju). Tā kā mums ir L3 tīkls, kas nāk tieši no serveriem, nekas neliedz mums izvietot VTEP pašos serveros, un OVS (OpenvSwitch) lieliski to dara. Rezultātā mēs ieguvām šādu dizainu:
Tā kā satiksme starp virtuālajām mašīnām ir jāsadala, portiem, kas vērsti uz virtuālajām mašīnām, būs atšķirīgi VLAN numuri. Taga numuram ir nozīme tikai vienā virtuālajā slēdžā, jo, kad tas ir iekapsulēts VxLAN, mēs to varam viegli noņemt, jo mums būs VNI.
Tagad mēs varam bez problēmām izveidot viņiem savas mašīnas un virtuālos tīklus.
Tomēr ko darīt, ja klientam ir cita iekārta, bet tas atrodas citā tīklā? Mums ir nepieciešama sakņu izveide starp tīkliem. Mēs apskatīsim vienkāršu iespēju, ja tiek izmantota centralizēta maršrutēšana - tas ir, trafika tiek maršrutēta caur īpašiem īpašiem tīkla mezgliem (kā likums, tie ir apvienoti ar vadības mezgliem, tāpēc mums būs tas pats).
Šķiet pietiekami vienkārši: vadības mezglā mēs izveidojam tilta saskarni, pārsūtām trafiku uz to un no turienes maršrutējam to uz jebkuru vietu, kur mums tas nepieciešams. Taču problēma ir tā, ka RED klients vēlas izmantot 10.0.0.0/24 tīklu, bet GREEN klients vēlas izmantot 10.0.0.0/24 tīklu. Tas nozīmē, ka mūsu adrešu telpas pārklājas. Turklāt klienti nevēlas, lai citi klienti varētu maršrutēt uz viņu iekšējiem tīkliem, kas ir loģiski. Lai atdalītu šo klientu tīklus un trafiku, mēs katram piešķirsim atsevišķu vārdtelpu. Nosaukumtelpa būtībā ir tīkla steka kopija. Linux, tas ir, klienti SARKANĀ vārdtelpā ir pilnībā izolēti no klientiem ZAĻĀ vārdtelpā (vai arī maršrutēšana starp šiem klientu tīkliem ir atļauta, izmantojot noklusējuma vārdtelpu vai augšupējās plūsmas transporta iekārtas).
Tas ir, mēs iegūstam šādu diagrammu:
L2 tuneļi saplūst no visiem skaitļošanas mezgliem uz vadības mezglu. mezgls, kurā atrodas šo tīklu L3 interfeiss, katrs atsevišķā nosaukumvietā izolācijai.
Tomēr mēs aizmirsām vissvarīgāko. Virtuālajai mašīnai ir jānodrošina pakalpojums klientam, tas ir, tai ir jābūt vismaz vienam ārējam interfeisam, caur kuru to var sasniegt. Tas ir, mums ir jāiziet ārpasaulē. Šeit ir dažādas iespējas. Izdarīsim vienkāršāko variantu. Katram klientam pievienosim vienu tīklu, kas būs derīgs pakalpojumu sniedzēja tīklā un nepārklāsies ar citiem tīkliem. Tīkli var arī krustoties un apskatīt dažādus VRF pakalpojumu sniedzēja tīkla pusē. Tīkla dati arī dzīvos katra klienta nosaukumu telpā. Tomēr viņi joprojām izies uz ārpasauli, izmantojot vienu fizisku (vai saiti, kas ir loģiskāk) saskarni. Lai atdalītu klienta trafiku, datplūsma, kas iziet ārpusē, tiks marķēta ar klientam piešķirto VLAN tagu.
Rezultātā mēs saņēmām šādu diagrammu:
Saprātīgs jautājums ir, kāpēc gan neizveidot vārtejas pašos skaitļošanas mezglos? Tā nav liela problēma; turklāt, ja ieslēdzat sadalīto maršrutētāju (DVR), tas darbosies. Šajā scenārijā mēs apsveram vienkāršāko iespēju ar centralizētu vārteju, kas tiek izmantota pēc noklusējuma Openstack. Lielas slodzes funkcijām tie izmantos gan sadalīto maršrutētāju, gan paātrināšanas tehnoloģijas, piemēram, SR-IOV un Passthrough, taču, kā viņi saka, tas ir pavisam cits stāsts. Vispirms apskatīsim pamata daļu, un tad iedziļināsimies detaļās.
Patiesībā mūsu shēma jau darbojas, taču ir dažas nianses:
- Mums ir kaut kā jāaizsargā mūsu mašīnas, tas ir, slēdža saskarnē jāievieto filtrs pret klientu.
- Dodiet iespēju virtuālajai mašīnai automātiski iegūt IP adresi, lai jums nebūtu katru reizi tajā jāpiesakās caur konsoli un jāreģistrē adrese.
Sāksim ar mašīnu aizsardzību. Šim nolūkam varat izmantot banālus iptables, kāpēc gan ne.
Tas ir, tagad mūsu topoloģija ir kļuvusi nedaudz sarežģītāka:
Ejam tālāk. Mums jāpievieno DHCP serveris. Ideālākā vieta DHCP serveru atrašanai katram klientam būtu jau iepriekš minētais vadības mezgls, kurā atrodas nosaukumu telpas:
Tomēr ir neliela problēma. Ko darīt, ja viss tiek restartēts un visa informācija par adrešu nomu DHCP tīklā pazūd. Loģiski, ka automātiem tiks piešķirtas jaunas adreses, kas nav īpaši ērti. Šeit ir divas izejas - vai nu izmantojiet domēna nosaukumus un pievienojiet DNS serveri katram klientam, tad adrese mums nebūs īpaši svarīga (līdzīgi kā tīkla daļai k8s) - taču ir problēma ar ārējiem tīkliem, jo adreses tajās var izsniegt arī caur DHCP - nepieciešama sinhronizācija ar DNS serveriem mākoņplatformā un ārējais DNS serveris, kas manuprāt nav īpaši elastīgs, bet ir pilnīgi iespējams. Vai arī otrā iespēja ir izmantot metadatus - tas ir, saglabāt informāciju par mašīnai izsniegto adresi, lai DHCP serveris zinātu, kuru adresi iekārtai izsniegt, ja iekārta jau ir saņēmusi adresi. Otrā iespēja ir vienkāršāka un elastīgāka, jo ļauj saglabāt papildu informāciju par automašīnu. Tagad pievienosim diagrammai aģenta metadatus:
Vēl viens jautājums, kas arī ir vērts apspriest, ir iespēja visiem klientiem izmantot vienu ārējo tīklu, jo ārējie tīkli, ja tiem ir jābūt derīgiem visā tīklā, būs sarežģīti - jums ir pastāvīgi jāpiešķir un jākontrolē šo tīklu piešķiršana. Iespēja izmantot vienu ārēju iepriekš konfigurētu tīklu visiem klientiem būs ļoti noderīga, veidojot publisko mākoni. Tas atvieglos mašīnu izvietošanu, jo mums nav jāmeklē adrešu datubāze un jāizvēlas unikāla adrešu telpa katra klienta ārējam tīklam. Turklāt mēs varam iepriekš reģistrēt ārējo tīklu, un izvietošanas laikā mums būs jāsaista tikai ārējās adreses ar klientu iekārtām.
Un šeit mums palīdz NAT — mēs tikai nodrošināsim klientiem piekļuvi ārpasaulei, izmantojot noklusējuma nosaukumvietu, izmantojot NAT tulkojumu. Nu, lūk, neliela problēma. Tas ir labi, ja klienta serveris darbojas kā klients, nevis kā serveris - tas ir, tas iniciē, nevis pieņem savienojumus. Bet mums būs otrādi. Šajā gadījumā mums ir jāveic galamērķa NAT, lai, saņemot trafiku, vadības mezgls saprastu, ka šī trafika ir paredzēta klienta A virtuālajai mašīnai A, kas nozīmē, ka mums ir jāveic NAT tulkojums no ārējās adreses, piemēram, 100.1.1.1. .10.0.0.1, uz iekšējo adresi 100. Šajā gadījumā, lai gan visi klienti izmantos vienu un to pašu tīklu, iekšējā izolācija ir pilnībā saglabāta. Tas ir, mums ir jāveic dNAT un sNAT vadības mezglā. Tas, vai izmantot vienu tīklu ar peldošām adresēm vai ārējiem tīkliem, vai abus vienlaikus, ir atkarīgs no tā, ko vēlaties ievietot mākonī. Mēs diagrammai nepievienosim peldošās adreses, bet atstāsim jau iepriekš pievienotos ārējos tīklus - katram klientam ir savs ārējais tīkls (shēmā tie ir norādīti kā vlan 200 un XNUMX ārējā saskarnē).
Rezultātā saņēmām interesantu un tajā pašā laikā pārdomātu risinājumu, kuram ir zināma elastība, bet vēl nav kļūdu tolerances mehānismu.
Pirmkārt, mums ir tikai viens vadības mezgls - tā kļūme novedīs pie visu sistēmu sabrukuma. Lai novērstu šo problēmu, jums ir nepieciešams vismaz 3 mezglu kvorums. Pievienosim diagrammai šo:
Protams, visi mezgli tiek sinhronizēti un, kad aktīvs mezgls aiziet, cits mezgls pārņems savus pienākumus.
Nākamā problēma ir virtuālās mašīnas diski. Šobrīd tie tiek glabāti pašos hipervizoros, un, ja rodas problēmas ar hipervizoru, mēs zaudējam visus datus - un reida klātbūtne šeit nepalīdzēs, ja mēs zaudēsim nevis disku, bet visu serveri. Lai to izdarītu, mums ir jāizveido pakalpojums, kas darbosies kā kāda veida krātuves priekšgals. Mums nav īpaši svarīgi, kāda veida krātuve tā būs, taču tai vajadzētu aizsargāt mūsu datus no diska un mezgla un, iespējams, visa korpusa kļūmēm. Šeit ir vairākas iespējas - ir, protams, SAN tīkli ar Fibre Channel, bet būsim godīgi - FC jau ir pagātnes relikts - E1 analogs transportā - jā, piekrītu, joprojām tiek izmantots, bet tikai tur, kur bez tā nav iespējams. Tāpēc es 2020. gadā brīvprātīgi neizvietotu FC tīklu, zinot, ka ir arī citas interesantākas alternatīvas. Lai gan katram savs, iespējams, ir tādi, kas uzskata, ka FC ar visiem tās ierobežojumiem ir viss, kas mums vajadzīgs - nestrīdēšos, katram savs viedoklis. Tomēr visinteresantākais risinājums, manuprāt, ir izmantot SDS, piemēram, Ceph.
Ceph ļauj izveidot ļoti pieejamu datu glabāšanas risinājumu ar daudzām iespējamām rezerves iespējām, sākot ar kodiem ar paritātes pārbaudi (analogs 5. vai 6. reidam) un beidzot ar pilnu datu replikāciju dažādos diskos, ņemot vērā disku atrašanās vietu serveri un serveri kabinetos utt.
Lai izveidotu Ceph, jums ir nepieciešami vēl 3 mezgli. Mijiedarbība ar krātuvi tiks veikta arī caur tīklu, izmantojot bloku, objektu un failu uzglabāšanas pakalpojumus. Pievienosim shēmai krātuvi:
Piezīme: varat izveidot arī hiperkonverģētus skaitļošanas mezglus — tā ir vairāku funkciju apvienošanas koncepcija vienā mezglā, piemēram, krātuve+aprēķināšana, neatvēlot īpašus mezglus ceph glabāšanai. Mēs iegūsim to pašu kļūdu izturīgo shēmu - tā kā SDS rezervēs datus ar mūsu norādīto rezervācijas līmeni. Tomēr hiperkonverģētie mezgli vienmēr ir kompromiss — tā kā uzglabāšanas mezgls ne tikai silda gaisu, kā šķiet pirmajā mirklī (jo tajā nav virtuālo mašīnu), — tas tērē CPU resursus SDS apkalpošanai (patiesībā tas dara visu replikācija un atkopšana pēc mezglu, disku uc kļūmēm). Tas nozīmē, ka, apvienojot to ar krātuvi, jūs zaudēsit daļu no aprēķina mezgla jaudas.
Visas šīs lietas ir kaut kā jāpārvalda — mums ir nepieciešams kaut kas, ar kura palīdzību mēs varam izveidot mašīnu, tīklu, virtuālo maršrutētāju utt. Lai to izdarītu, vadības mezglam pievienosim pakalpojumu, kas darbosies kā informācijas panelis — klients varēs pieslēgties šim portālam caur http/ https un darīt visu nepieciešamo (nu, gandrīz).
Tā rezultātā mums tagad ir kļūmju izturīga sistēma. Visi šīs infrastruktūras elementi ir kaut kā jāpārvalda. Iepriekš tika aprakstīts, ka Openstack ir projektu kopums, no kuriem katrs nodrošina noteiktu funkciju. Kā redzam, elementu, kas jākonfigurē un jākontrolē, ir vairāk nekā pietiekami. Šodien mēs runāsim par tīkla daļu.
Neitronu arhitektūra
OpenStack tieši Neutron ir atbildīgs par virtuālās mašīnas pieslēgvietu pievienošanu kopējam L2 tīklam, trafika maršrutēšanas nodrošināšanu starp virtuālajām mašīnām, kas atrodas dažādos L2 tīklos, kā arī izbraukšanu, nodrošinot tādus pakalpojumus kā NAT, Floating IP, DHCP u.c.
Augstā līmenī tīkla pakalpojuma (pamata daļas) darbību var raksturot šādi.
Startējot virtuālo mašīnu, tīkla pakalpojums:
- Izveido portu dotajai VM (vai portiem) un paziņo par to DHCP servisam;
- Tiek izveidota jauna virtuālā tīkla ierīce (izmantojot libvirt);
- Virtuālā mašīna izveido savienojumu ar 1. darbībā izveidoto(-iem) portu(-iem);
Savādi, bet Neutron darbība balstās uz standarta mehānismiem, kas pazīstami ikvienam, kurš jebkad ir iedziļinājies tajā. Linux - tās ir namespaces, iptables, linux tilti, openvswitch, conntrack utt.
Nekavējoties jāprecizē, ka Neutron nav SDN kontrolieris.
Neitrons sastāv no vairākiem savstarpēji saistītiem komponentiem:
Openstack-neutron-serveris ir dēmons, kas darbojas ar lietotāju pieprasījumiem, izmantojot API. Šis dēmons nav iesaistīts tīkla savienojumu reģistrēšanā, bet sniedz šim nolūkam nepieciešamo informāciju saviem spraudņiem, kas pēc tam konfigurē vēlamo tīkla elementu. Neitronu aģenti OpenStack mezglos reģistrējas Neutron serverī.
Neitron-serveris faktiski ir lietojumprogramma, kas rakstīta python un sastāv no divām daļām:
- REST serviss
- Neitron spraudnis (pamats/pakalpojums)
Pakalpojums REST ir paredzēts API zvanu saņemšanai no citiem komponentiem (piemēram, pieprasījumu sniegt kādu informāciju utt.)
Spraudņi ir spraudņu programmatūras komponenti/moduļi, kas tiek izsaukti API pieprasījumu laikā — tas ir, pakalpojuma attiecināšana notiek caur tiem. Spraudņi ir sadalīti divos veidos - serviss un saknes. Parasti zirga spraudnis galvenokārt ir atbildīgs par adrešu telpas un L2 savienojumu pārvaldību starp virtuālajām mašīnām, un pakalpojumu spraudņi jau nodrošina papildu funkcionalitāti, piemēram, VPN vai FW.
Piemēram, var apskatīt šodien pieejamo spraudņu sarakstu
Var būt vairāki pakalpojumu spraudņi, bet var būt tikai viens zirgu spraudnis.
openstack-neutron-ml2 ir standarta Openstack saknes spraudnis. Šim spraudnim ir modulāra arhitektūra (atšķirībā no tā priekšgājēja), un tas konfigurē tīkla pakalpojumu, izmantojot tam pievienotos draiverus. Pašu spraudni apskatīsim nedaudz vēlāk, jo patiesībā tas nodrošina OpenStack tīkla daļas elastību. Saknes spraudni var aizstāt (piemēram, Contrail Networking veic šādu nomaiņu).
RPC pakalpojums (rabbitmq-server) — pakalpojums, kas nodrošina rindu pārvaldību un mijiedarbību ar citiem OpenStack pakalpojumiem, kā arī mijiedarbību starp tīkla pakalpojumu aģentiem.
Tīkla aģenti — aģenti, kas atrodas katrā mezglā, caur kuriem tiek konfigurēti tīkla pakalpojumi.
Ir vairāki aģentu veidi.
Galvenais aģents ir L2 aģents. Šie aģenti darbojas katrā no hipervizoriem, tostarp vadības mezgliem (precīzāk, visos mezglos, kas sniedz jebkādus pakalpojumus nomniekiem), un to galvenā funkcija ir savienot virtuālās mašīnas ar kopēju L2 tīklu, kā arī ģenerēt brīdinājumus, kad notiek kādi notikumi ( piemēram, atspējot/iespējot portu).
Nākamais, ne mazāk svarīgais aģents ir L3 aģents. Pēc noklusējuma šis aģents darbojas tikai tīkla mezglā (bieži tīkla mezgls tiek apvienots ar vadības mezglu) un nodrošina maršrutēšanu starp nomnieku tīkliem (gan starp saviem tīkliem, gan citu nomnieku tīkliem, kā arī ir pieejams ārpasaulei, nodrošinot NAT, kā arī DHCP pakalpojumu). Tomēr, izmantojot DVR (distributed router), nepieciešamība pēc L3 spraudņa parādās arī skaitļošanas mezglos.
3. līmeņa aģentu lietojumi Linux nosaukumtelpas, lai katram nomniekam nodrošinātu savu izolētu tīklu kopu un virtuālā maršrutētāja funkcionalitāti, kas maršrutē datplūsmu un nodrošina vārtejas pakalpojumus 2. slāņa tīkliem.
Datubāze — tīklu, apakštīklu, portu, kopu utt. identifikatoru datu bāze.
Faktiski Neutron pieņem API pieprasījumus no jebkura tīkla entītiju izveides, autentificē pieprasījumu un caur RPC (ja tas piekļūst kādam spraudnim vai aģentam) vai REST API (ja tas sazinās SDN) pārsūta aģentiem (izmantojot spraudņus) norādījumi, kas nepieciešami pieprasītā pakalpojuma organizēšanai.
Tagad pievērsīsimies testa instalācijai (kā tā tiek izvietota un kas tajā ir iekļauta, redzēsim vēlāk praktiskajā daļā) un redzēsim, kur atrodas katra sastāvdaļa:
(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 ~]$ 
Faktiski tā ir visa neitrona struktūra. Tagad ir vērts kādu laiku veltīt spraudnim ML2.
2. moduļu slānis
Kā minēts iepriekš, spraudnis ir standarta OpenStack saknes spraudnis, un tam ir modulāra arhitektūra.
ML2 spraudņa priekšgājējam bija monolīta struktūra, kas neļāva, piemēram, vienā instalācijā izmantot vairāku tehnoloģiju sajaukumu. Piemēram, jūs nevarējāt vienlaikus izmantot gan openvswitch, gan linuxbridge - ne pirmo, ne otro. Šī iemesla dēļ tika izveidots spraudnis ML2 ar tā arhitektūru.
ML2 ir divas sastāvdaļas - divu veidu draiveri: tipa draiveri un mehānisma draiveri.
Ierakstiet draiverus noteikt tehnoloģijas, kas tiks izmantotas tīkla savienojumu organizēšanai, piemēram, VxLAN, VLAN, GRE. Tajā pašā laikā vadītājs ļauj izmantot dažādas tehnoloģijas. Standarta tehnoloģija ir VxLAN iekapsulēšana pārklājuma tīkliem un VLAN ārējiem tīkliem.
Tipu draiveri ietver šādus tīklu veidus:
Dzīvoklis - tīkls bez marķēšanas
VLAN - atzīmēts tīkls
Uz vietas — īpaša veida tīkls instalācijām viss vienā (šādas iekārtas ir vajadzīgas izstrādātājiem vai apmācībai)
GRE — pārklājuma tīkls, izmantojot GRE tuneļus
VxLAN — pārklājuma tīkls, izmantojot VxLAN tuneļus
Mehānismu draiveri definēt rīkus, kas nodrošina tipa draiverī norādīto tehnoloģiju organizēšanu - piemēram, openvswitch, sr-iov, opendaylight, OVN u.c.
Atkarībā no šī draivera ieviešanas tiks izmantoti vai nu Neutron kontrolēti aģenti, vai arī savienojumi ar ārēju SDN kontrolieri, kas rūpējas par visiem jautājumiem, kas saistīti ar L2 tīklu organizēšanu, maršrutēšanu utt.
Piemērs: ja mēs izmantojam ML2 kopā ar OVS, tad L2 aģents tiek instalēts katrā skaitļošanas mezglā, kas pārvalda OVS. Taču, ja lietojam, piemēram, OVN vai OpenDayLight, tad OVS vadība nonāk viņu jurisdikcijā - Neutron caur root spraudni dod komandas kontrolierim, un tas jau dara to, ko lika.
Atjaunināsim informāciju par Open vSwitch
Šobrīd viens no OpenStack galvenajiem komponentiem ir Open vSwitch.
Instalējot OpenStack bez papildu pārdevēja SDN, piemēram, Juniper Contrail vai Nokia Nuage, OVS ir galvenā mākoņa tīkla tīkla sastāvdaļa un kopā ar iptables, conntrack, namespaces ļauj organizēt pilnvērtīgus vairāku nomas pārklājumu tīklus. Protams, šo komponentu var aizstāt, piemēram, izmantojot trešās puses patentētus (pārdevēja) SDN risinājumus.
OVS ir atvērtā pirmkoda programmatūras slēdzis, kas paredzēts lietošanai virtualizētā vidē kā virtuālā trafika pārsūtītājs.
Šobrīd OVS ir ļoti pieklājīga funkcionalitāte, kas ietver tādas tehnoloģijas kā QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK u.c.
Piezīme: OVS sākotnēji netika iecerēts kā mīksts slēdzis ļoti noslogotām telekomunikāciju funkcijām, un tas bija vairāk paredzēts IT funkcijām, kurām ir mazāks joslas platums, piemēram, WEB serverim vai pasta serverim. Taču OVS tiek tālāk attīstīts un pašreizējās OVS implementācijas ir krietni uzlabojušas tā veiktspēju un iespējas, kas ļauj to izmantot telekomunikāciju operatoriem ar ļoti noslogotām funkcijām, piemēram, ir OVS implementācija ar atbalstu DPDK paātrinājumam.
Ir trīs svarīgi OVS komponenti, kas jums jāzina:
- Kodola modulis — komponents, kas atrodas kodola telpā, kas apstrādā trafiku, pamatojoties uz noteikumiem, kas saņemti no vadības elementa;
- vSlēdzis dēmons (ovs-vswitchd) ir lietotāja telpā palaists process, kas ir atbildīgs par kodola moduļa programmēšanu - tas ir, tas tieši atspoguļo slēdža darbības loģiku
- Datu bāzes serveris - lokālā datu bāze, kas atrodas katrā resursdatorā, kurā darbojas OVS, un kurā tiek saglabāta konfigurācija. SDN kontrolleri var sazināties, izmantojot šo moduli, izmantojot OVSDB protokolu.
Tam visam ir pievienots diagnostikas un pārvaldības utilītu komplekts, piemēram, ovs-vsctl, ovs-appctl, ovs-ofctl utt.
Pašlaik Openstack plaši izmanto telekomunikāciju operatori, lai uz to migrētu tīkla funkcijas, piemēram, EPC, SBC, HLR u.c. Dažas funkcijas var darboties bez problēmām ar tādu OVS, kāds tas ir, bet, piemēram, EPC apstrādā abonentu trafiku - tad tas iet cauri. milzīgs satiksmes apjoms (tagad trafika apjoms sasniedz vairākus simtus gigabitu sekundē). Protams, šādas trafika vadīšana caur kodola vietu (jo ekspeditors pēc noklusējuma atrodas tur) nav labākā ideja. Tāpēc OVS bieži tiek pilnībā izvietots lietotāju telpā, izmantojot DPDK paātrinājuma tehnoloģiju, lai pārsūtītu trafiku no NIC uz lietotāja vietu, apejot kodolu.
Piezīme: mākonim, kas izvietots telekomunikāciju funkcijām, ir iespējams izvadīt trafiku no skaitļošanas mezgla, apejot OVS, tieši uz komutācijas aprīkojumu. Šim nolūkam tiek izmantoti SR-IOV un Passthrough mehānismi.
Kā tas darbojas reālā izkārtojumā?
Nu, tagad pāriesim uz praktisko daļu un redzēsim, kā tas viss darbojas praksē.
Vispirms izvietosim vienkāršu Openstack instalāciju. Tā kā man nav pie rokas serveru komplekta eksperimentiem, mēs saliksim prototipu vienā fiziskajā serverī no virtuālajām mašīnām. Jā, dabiski, ka šāds risinājums nav piemērots komerciāliem nolūkiem, taču, lai redzētu piemēru, kā Openstack darbojas tīkls, ar šādu instalāciju acīm pietiek. Turklāt šāda instalācija ir vēl interesantāka apmācības nolūkos - jo jūs varat noķert satiksmi utt.
Tā kā mums ir jāredz tikai pamata daļa, mēs nevaram izmantot vairākus tīklus, bet visu pacelt, izmantojot tikai divus tīklus, un otrs tīkls šajā izkārtojumā tiks izmantots tikai piekļuvei undercloud un DNS serverim. Pagaidām mēs nepieskaramies ārējiem tīkliem - šī ir atsevišķa liela raksta tēma.
Tātad, sāksim secībā. Pirmkārt, neliela teorija. Mēs instalēsim Openstack, izmantojot TripleO (Openstack uz Openstack). TripleO būtība ir tāda, ka mēs instalējam Openstack all-in-one (tas ir, vienā mezglā), ko sauc par undercloud, un pēc tam izmantojam izvietotā Openstack iespējas, lai instalētu darbībai paredzēto Openstack, ko sauc par overcloud. Undercloud izmantos tai piemītošo spēju pārvaldīt fiziskos serverus (bezmetāla) — Ironic projektu —, lai nodrošinātu hipervizorus, kas pildīs skaitļošanas, vadības un uzglabāšanas mezglu funkcijas. Tas nozīmē, ka mēs neizmantojam nekādus trešo pušu rīkus, lai izvietotu Openstack — mēs izvietojam Openstack, izmantojot Openstack. Instalēšanas gaitā tas kļūs daudz skaidrāks, tāpēc mēs neapstāsimies un virzīsimies uz priekšu.
Piezīme. Šajā rakstā vienkāršības labad es neizmantoju tīkla izolāciju iekšējiem Openstack tīkliem, bet viss tiek izvietots, izmantojot tikai vienu tīklu. Taču tīkla izolācijas esamība vai neesamība neietekmē risinājuma pamata funkcionalitāti – viss darbosies tieši tāpat, kā lietojot izolāciju, taču trafika plūdīs tajā pašā tīklā. Komerciālai instalācijai, protams, ir jāizmanto izolācija, izmantojot dažādus vlanus un saskarnes. Piemēram, ceph krātuves pārvaldības trafiks un pati datu trafika (mašīnas piekļuve diskiem utt.), kad tā ir izolēta, izmanto dažādus apakštīklus (Storage management un Storage), un tas ļauj risinājumu padarīt izturīgāku pret kļūmēm, piemēram, sadalot šo trafiku. , izmantojot dažādus portus vai izmantojot dažādus QoS profilus dažādai trafikai, lai datu trafiks neizspiestu signalizācijas trafiku. Mūsu gadījumā tie darbosies vienā tīklā, un patiesībā tas mūs nekādi neierobežo.
Piezīme. Tā kā virtuālās mašīnas darbināsim virtuālajā vidē, kuras pamatā ir virtuālās mašīnas, vispirms ir jāiespējo ligzdotā virtualizācija.
Varat pārbaudīt, vai ligzdotā virtualizācija ir iespējota vai nav, šādi:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Ja redzat burtu N, mēs iespējojam atbalstu ligzdotai virtualizācijai saskaņā ar jebkuru ceļvedi, ko atrodat tīklā, piemēram, .
Mums ir jāsamontē šāda ķēde no virtuālajām mašīnām:
Manā gadījumā, lai savienotu virtuālās mašīnas, kas ir daļa no turpmākās instalācijas (un man ir 7 no tām, bet jūs varat iztikt ar 4, ja jums nav daudz resursu), es izmantoju OpenvSwitch. Es izveidoju vienu ovs tiltu un pievienoju tam virtuālās mašīnas, izmantojot portu grupas. Lai to izdarītu, es izveidoju šādu xml failu:
[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>Šeit ir deklarētas trīs portu grupas - divas piekļuves un viena maģistrāle (pēdējā bija nepieciešama DNS serverim, bet jūs varat iztikt bez tā vai instalēt to resursdatorā - kā jums ērtāk). Pēc tam, izmantojot šo veidni, mēs deklarējam savu, izmantojot virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Tagad mēs rediģējam hipervizora porta konfigurācijas:
[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 ~]# Piezīme: šajā gadījumā adrese portā ovs-br1 nebūs pieejama, jo tai nav vlan taga. Lai to novērstu, jums ir jāizdod komanda sudo ovs-vsctl set port ovs-br1 tag=100. Tomēr pēc pārstartēšanas šis tags pazudīs (ja kāds zina, kā likt tam palikt vietā, būšu ļoti pateicīgs). Bet tas nav tik svarīgi, jo šī adrese mums būs nepieciešama tikai instalēšanas laikā un nebūs vajadzīga, kad Openstack būs pilnībā izvietots.
Tālāk mēs izveidojam mākoņdatošanas mašīnu:
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=ttyS0Instalēšanas laikā jūs iestatāt visus nepieciešamos parametrus, piemēram, datora nosaukumu, paroles, lietotājus, NTP serverus utt. Varat arī uzreiz konfigurēt portus, taču man personīgi ir vieglāk pēc instalēšanas pieteikties datorā, izmantojot konsoli, un rediģēt nepieciešamos failus. Ja jums jau ir iepriekš izveidots attēls, varat to izmantot vai darīt tāpat kā es un lejupielādēt minimālu attēlu. Centos 7 un izmantojiet to, lai instalētu VM.
Pēc veiksmīgas instalēšanas jums vajadzētu būt virtuālai mašīnai, kurā varat instalēt zem mākoņa
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningVispirms instalējiet instalēšanas procesam nepieciešamos rīkus:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud uzstādīšana
Mēs izveidojam steka lietotāju, iestatām paroli, pievienojam to sudoer un dodam viņam iespēju izpildīt root komandas, izmantojot sudo, neievadot paroli:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackTagad saimniekdatora failā mēs norādām pilnu mākoņa nosaukumu:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Tālāk mēs pievienojam krātuves un instalējam nepieciešamo programmatūru:
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-ansiblePiezīme: ja neplānojat instalēt ceph, jums nav jāievada ar ceph saistītas komandas. Es izmantoju Queens izlaidumu, bet jūs varat izmantot jebkuru citu, kas jums patīk.
Pēc tam nokopējiet mākoņdatošanas konfigurācijas failu lietotāja mājas direktoriju kaudzē:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confTagad mums ir jālabo šis fails, pielāgojot to mūsu instalācijai.
Faila sākumā jāpievieno šīs rindas:
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 = 10Tātad, iesim cauri iestatījumiem:
undercloud_hostname — pilnam mākoņa servera nosaukumam jāsakrīt ar DNS servera ierakstu
vietējais_ip — lokālā mākoņdatošanas adrese tīkla nodrošināšanai
network_gateway — tā pati vietējā adrese, kas darbosies kā vārteja piekļuvei ārpasaulei mākoņu mezglu uzstādīšanas laikā, sakrīt arī ar vietējo IP
undercloud_public_host — ārējā API adrese, tiek piešķirta jebkura brīva adrese no nodrošināšanas tīkla
undercloud_admin_host iekšējā API adrese, tiek piešķirta jebkura bezmaksas adrese no nodrošināšanas tīkla
undercloud_nameservers — DNS serveris
Gene_service_certificate - šī rinda ir ļoti svarīga pašreizējā piemērā, jo, ja jūs to neiestatīsit uz false, instalēšanas laikā tiks parādīta kļūda, problēma ir aprakstīta Red Hat kļūdu izsekotājā
vietējais_interfeiss saskarne tīkla nodrošināšanā. Šis interfeiss tiks pārkonfigurēts undercloud izvietošanas laikā, tāpēc jums ir jābūt diviem interfeisiem undercloud — vienai, lai piekļūtu tai, otrai — nodrošināšanai.
local_mtu — MTU. Tā kā mums ir testēšanas laboratorija un man ir MTU 1500 uz OVS slēdža portiem, ir jāiestata uz 1450, lai VxLAN iekapsulētās paketes varētu iziet cauri.
tīkls_cidr — nodrošināšanas tīkls
maskarāde — izmantojot NAT, lai piekļūtu ārējam tīklam
masquerade_network - tīkls, kas tiks savienots ar NAT
dhcp_start — adrešu kopas sākuma adrese, no kuras adreses tiks piešķirtas mezgliem mākoņa izvietošanas laikā
dhcp_end — adrešu kopas galīgā adrese, no kuras adreses tiks piešķirtas mezgliem mākoņa izvietošanas laikā
inspekcijas_izlaide — adrešu kopums, kas nepieciešams pašpārbaudei (nedrīkst pārklāties ar iepriekš minēto kopu)
scheduler_max_attempts — maksimālais mākoņu uzstādīšanas mēģinājumu skaits (jābūt lielākam vai vienādam ar mezglu skaitu)
Kad fails ir aprakstīts, varat dot komandu izvietot undercloud:
openstack undercloud install
Procedūra ilgst no 10 līdz 30 minūtēm atkarībā no jūsu gludekļa. Galu galā jums vajadzētu redzēt šādu izvadi:
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.
#############################################################################Šī izvade norāda, ka esat veiksmīgi instalējis undercloud, un tagad varat pārbaudīt undercloud statusu un turpināt instalēt overcloud.
Ja paskatās uz ifconfig izvadi, jūs redzēsit, ka ir parādījies jauns tilta interfeiss
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Overcloud izvietošana tagad tiks veikta, izmantojot šo saskarni.
No tālāk redzamās produkcijas varat redzēt, ka mums visi pakalpojumi ir vienā mezglā:
(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 |
+--------------------------+-----------+----------+Zemāk ir mākoņa tīkla daļas konfigurācija:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Overcloud uzstādīšana
Šobrīd mums ir tikai mākonis, un mums nav pietiekami daudz mezglu, no kuriem tiks montēti mākoņi. Tāpēc, pirmkārt, izvietosim mums nepieciešamās virtuālās mašīnas. Izvietošanas laikā Undercloud pats instalēs OS un nepieciešamo programmatūru overcloud mašīnā - tas ir, mums nav pilnībā jāizvieto mašīna, bet tikai jāizveido tai disks (vai diski) un jānosaka tā parametri - tas ir. , patiesībā mēs iegūstam tukšu serveri, kurā nav instalēta OS.
Dosimies uz mapi ar mūsu virtuālo mašīnu diskiem un izveidosim vajadzīgā izmēra diskus:
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 160GTā kā mēs darbojamies kā root, mums ir jāmaina šo disku īpašnieks, lai nerastos problēmas ar tiesībām:
[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]# Piezīme: ja neplānojat instalēt ceph, lai to izpētītu, tad komandas neveido vismaz 3 mezglus ar vismaz diviem diskiem, bet veidnē norāda, ka tiks izmantoti virtuālie diski vda, vdb utt.
Lieliski, tagad mums ir jādefinē visas šīs mašīnas:
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 Beigās ir komanda -print-xml > /tmp/storage-1.xml, kas izveido xml failu ar katras mašīnas aprakstu mapē /tmp/; ja jūs to nepievienosit, jūs vairs nebūsiet. spēj identificēt virtuālās mašīnas.
Tagad mums ir jādefinē visas šīs mašīnas virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Tagad neliela nianse – tripleO izmanto IPMI, lai pārvaldītu serverus instalēšanas un pašpārbaudes laikā.
Introspekcija ir aparatūras pārbaudes process, lai iegūtu tās parametrus, kas nepieciešami tālākai mezglu nodrošināšanai. Introspekcija tiek veikta, izmantojot ironiju, pakalpojumu, kas paredzēts darbam ar tukša metāla serveriem.
Bet šeit ir problēma - lai gan aparatūras IPMI serveriem ir atsevišķs ports (vai koplietots ports, bet tas nav svarīgi), virtuālajām mašīnām šādu portu nav. Šeit mums palīdz kruķis ar nosaukumu vbmc - utilīta, kas ļauj emulēt IPMI portu. Šai niansei ir vērts pievērst uzmanību īpaši tiem, kas vēlas izveidot šādu laboratoriju uz ESXI hipervizora - godīgi sakot, es nezinu, vai tam ir vbmc analogs, tāpēc ir vērts padomāt par šo problēmu pirms visa izvietošanas. .
Instalējiet vbmc:
yum install yum install python2-virtualbmcJa jūsu operētājsistēma nevar atrast pakotni, pievienojiet repozitoriju:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmTagad mēs iestatām utilītu. Šeit viss ir banāli līdz apkaunojumam. Tagad loģiski, ka vbmc sarakstā nav neviena servera
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Lai tie tiktu parādīti, tie ir manuāli jādeklarē šādi:
[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 ~]#Es domāju, ka komandu sintakse ir skaidra bez paskaidrojumiem. Tomēr pagaidām visas mūsu sesijas ir DOWN statusā. Lai tie pārietu uz UP statusu, tie ir jāiespējo:
[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 ~]#Un pēdējais pieskāriens - jums ir jālabo ugunsmūra noteikumi (vai pilnībā jāatspējo):
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
Tagad pāriesim uz mākoņiem un pārbaudīsim, vai viss darbojas. Resursmašīnas adrese ir 192.168.255.200, mākoņdatnē mēs pievienojām nepieciešamo ipmitool pakotni, gatavojoties izvietošanai:
[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 runningKā redzat, mēs esam veiksmīgi palaiduši vadības mezglu, izmantojot vbmc. Tagad izslēgsim to un turpināsim:
[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 ~]#Nākamais solis ir to mezglu introspekcija, uz kuriem tiks uzstādīts mākonis. Lai to izdarītu, mums ir jāsagatavo json fails ar mūsu mezglu aprakstu. Lūdzu, ņemiet vērā, ka atšķirībā no instalēšanas uz tukšiem serveriem fails norāda portu, kurā darbojas vbmc katrai mašīnai.
[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:27Piezīme: vadības mezglam ir divas saskarnes, taču šajā gadījumā tas nav svarīgi, šajā instalācijā mums pietiks ar vienu.
Tagad mēs sagatavojam json failu. Mums jānorāda porta magoņu adrese, caur kuru tiks veikta nodrošināšana, mezglu parametri, jāpiešķir tiem nosaukumi un jānorāda, kā nokļūt ipmi:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Tagad mums ir jāsagatavo attēli ironijai. Lai to izdarītu, lejupielādējiet tos, izmantojot wget, un instalējiet:
(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 ~]$Attēlu augšupielāde mākoņos:
(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 ~]$Pārbauda, vai visi attēli ir ielādēti
(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 ~]$Vēl viena lieta - jums jāpievieno DNS serveris:
(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 ~]$Tagad mēs varam dot komandu pašpārbaudei:
(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 ~]$Kā redzat no izvades, viss tika pabeigts bez kļūdām. Pārbaudīsim, vai visi mezgli ir pieejamajā stāvoklī:
(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 ~]$ Ja mezgli ir citā stāvoklī, parasti pārvaldāmi, tad kaut kas nogāja greizi, un jums ir jāaplūko žurnāls un jānoskaidro, kāpēc tas notika. Ņemiet vērā, ka šajā scenārijā mēs izmantojam virtualizāciju un var būt kļūdas, kas saistītas ar virtuālo mašīnu vai vbmc izmantošanu.
Tālāk mums jānorāda, kurš mezgls kādu funkciju pildīs, tas ir, jānorāda profils, ar kuru mezgls izvietos:
(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 ~]$Norādiet katra mezgla profilu:
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-d9afb69d1167Pārbaudīsim, vai mēs visu izdarījām pareizi:
(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 ~]$Ja viss ir pareizi, mēs dodam komandu izvietot overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuReālā instalācijā, protams, tiks izmantotas pielāgotas veidnes, mūsu gadījumā tas ievērojami sarežģīs procesu, jo katrs veidnes labojums būs jāpaskaidro. Kā jau tika rakstīts iepriekš, pat ar vienkāršu instalāciju mums pietiks, lai redzētu, kā tā darbojas.
Piezīme: šajā gadījumā ir nepieciešams mainīgais --libvirt tipa qemu, jo mēs izmantosim ligzdotu virtualizāciju. Pretējā gadījumā jūs nevarēsit palaist virtuālās mašīnas.
Tagad jums ir aptuveni stunda vai varbūt vairāk (atkarībā no aparatūras iespējām), un jūs varat tikai cerēt, ka pēc šī laika jūs redzēsit šādu ziņojumu:
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 ~]$Tagad jums ir gandrīz pilnvērtīga openstack versija, kurā varat mācīties, eksperimentēt utt.
Pārbaudīsim, vai viss darbojas pareizi. Lietotāja mājas direktoriju stekā ir divi faili – viens stackrc (undercloud pārvaldībai) un otrs overcloudrc (overcloud pārvaldīšanai). Šie faili ir jānorāda kā avots, jo tie satur autentifikācijai nepieciešamo informāciju.
(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 ~]$Manai instalēšanai joprojām ir nepieciešams neliels pieskāriens - maršruta pievienošana kontrollerī, jo iekārta, ar kuru es strādāju, atrodas citā tīklā. Lai to izdarītu, siltuma administratora kontā dodieties uz kontroli-1 un reģistrējiet maršrutu
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
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.254Nu, tagad jūs varat doties uz horizontu. Visa informācija - adreses, pieteikšanās vārds un parole - atrodas failā /home/stack/overcloudrc. Galīgā diagramma izskatās šādi:
Starp citu, mūsu instalācijā mašīnu adreses tika izsniegtas, izmantojot DHCP, un, kā redzat, tās tiek izsniegtas “nejauši”. Veidnē varat stingri noteikt, kura adrese ir jāpievieno kurai mašīnai izvietošanas laikā, ja jums tā ir nepieciešama.
Kā notiek trafika plūsma starp virtuālajām mašīnām?
Šajā rakstā mēs apskatīsim trīs iespējas garāmbraucošai satiksmei
- Divas mašīnas vienā hipervizorā vienā L2 tīklā
- Divas mašīnas dažādos hipervizoros vienā L2 tīklā
- Divas mašīnas dažādos tīklos (starptīklu sakņošana)
Gadījumus ar piekļuvi ārējai pasaulei, izmantojot ārējo tīklu, izmantojot peldošās adreses, kā arī izkliedētu maršrutēšanu, mēs izskatīsim nākamreiz, pagaidām koncentrēsimies uz iekšējo trafiku.
Lai pārbaudītu, izveidosim šādu diagrammu:
Mēs esam izveidojuši 4 virtuālās mašīnas - 3 vienā L2 tīklā - net-1 un vēl 1 tīklā net-2
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Apskatīsim, kādos hipervizoros atrodas izveidotās mašīnas:
(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) [steck@undercloud ~]$
Mašīnas vm-1 un vm-3 atrodas uz compute-0, mašīnas vm-2 un vm-4 atrodas mezglā compute-1.
Turklāt ir izveidots virtuālais maršrutētājs, lai nodrošinātu maršrutēšanu starp norādītajiem tīkliem:
(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 ~]$ Maršrutētājam ir divi virtuālie porti, kas darbojas kā vārtejas tīkliem:
(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 ~]$ Bet pirms mēs aplūkojam trafika plūsmu, apskatīsim, kas mums pašlaik ir vadības mezglā (kas arī ir tīkla mezgls) un skaitļošanas mezglā. Sāksim ar skaitļošanas mezglu.
[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 ~]$Šobrīd mezglā ir trīs ovs tilti - br-int, br-tun, br-ex. Starp tiem, kā mēs redzam, ir saskarņu kopums. Lai atvieglotu izpratni, uzzīmēsim visas šīs saskarnes diagrammā un redzēsim, kas notiek.
Aplūkojot adreses, uz kurām tiek pacelti VxLAN tuneļi, redzams, ka viens tunelis ir paaugstināts uz compute-1 (192.168.255.26), otrs tunelis izskatās uz control-1 (192.168.255.15). Bet pats interesantākais ir tas, ka br-ex nav fizisku saskarņu, un, ja paskatās, kādas plūsmas ir konfigurētas, var redzēt, ka šis tilts šobrīd var tikai atmest satiksmi.
[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 ~]$ Kā redzat no izejas, adrese tiek pieskrūvēta tieši fiziskajam portam, nevis virtuālā tilta saskarnei.
[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 ~]$ Saskaņā ar pirmo noteikumu viss, kas nāca no phy-br-ex porta, ir jāizmet.
Patiesībā šobrīd nav kur citur satiksmei iekļūt šajā tiltā, izņemot no šīs saskarnes (saskarne ar br-int), un, spriežot pēc kritumiem, BUM satiksme jau ir ieplūdusi tiltā.
Tas nozīmē, ka satiksme var atstāt šo mezglu tikai caur VxLAN tuneli un neko citu. Taču, ja ieslēdzat DVR, situācija mainīsies, bet ar to tiksim galā citreiz. Izmantojot tīkla izolāciju, piemēram, izmantojot vlans, jums būs nevis viens L3 interfeiss vlan 0, bet gan vairākas saskarnes. Tomēr VxLAN trafiks iziet no mezgla tādā pašā veidā, bet arī iekapsulēts kaut kādā īpašā VLAN.
Mēs esam sakārtojuši aprēķina mezglu, pāriesim uz vadības mezglu.
[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 ~]$Patiesībā mēs varam teikt, ka viss ir vienāds, bet IP adrese vairs nav fiziskajā saskarnē, bet gan virtuālajā tiltā. Tas tiek darīts, jo šī osta ir osta, caur kuru satiksme izies uz ārpasauli.
[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 ~]$ Šis ports ir piesaistīts br-ex tiltam un, tā kā uz tā nav vlan tagu, šis ports ir maģistrālais ports, kurā ir atļauti visi vlani, tagad satiksme iet ārpusē bez atzīmes, kā to norāda vlan-id 0 izvade iepriekš.
Viss pārējais šobrīd ir līdzīgs skaitļošanas mezglam - tie paši tilti, tie paši tuneļi, kas iet uz diviem skaitļošanas mezgliem.
Šajā rakstā mēs neapskatīsim krātuves mezglus, taču, lai saprastu, jāsaka, ka šo mezglu tīkla daļa ir banāla līdz apkaunojuma vietai. Mūsu gadījumā ir tikai viens fiziskais ports (eth0) ar tam piešķirtu IP adresi, un tas arī viss. Nav VxLAN tuneļu, tuneļu tiltu u.c. - ovs vispār nav, jo nav jēgas. Izmantojot tīkla izolāciju, šim mezglam būs divas saskarnes (fiziskie porti, bodny vai tikai divi VLAN — tas nav svarīgi — tas ir atkarīgs no tā, ko vēlaties) - viens pārvaldībai, otrs trafikam (rakstīšanai VM diskā , lasīšana no diska utt.)
Mēs noskaidrojām, kas mums ir uz mezgliem, ja nebija pakalpojumu. Tagad palaidīsim 4 virtuālās mašīnas un redzēsim, kā mainās iepriekš aprakstītā shēma - mums vajadzētu būt portiem, virtuālajiem maršrutētājiem utt.
Līdz šim mūsu tīkls izskatās šādi:
Mums ir divas virtuālās mašīnas katrā datora mezglā. Izmantojot compute-0 kā piemēru, redzēsim, kā viss ir iekļauts.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Iekārtai ir tikai viens virtuālais interfeiss - 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 ~]$
Šis interfeiss izskatās Linux tiltā:
[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 ~]$ Kā redzat no izejas, tiltā ir tikai divas saskarnes - tap95d96a75-a0 un qvb95d96a75-a0.
Šeit ir vērts nedaudz pakavēties pie OpenStack virtuālā tīkla ierīču veidiem:
vtap — virtuālais interfeiss, kas pievienots instancei (VM)
qbr — Linux tilts
qvb un qvo ir vEth pāris, kas savienots ar Linux tilts un Open vSwitch tilts
br-int, br-tun, br-vlan — atveriet vSwitch tiltus
patch-, int-br-, phy-br- — atvērt vSwitch ielāpu saskarnes, kas savieno tiltus
qg, qr, ha, fg, sg — atver vSwitch portus, ko izmanto virtuālās ierīces, lai izveidotu savienojumu ar OVS
Kā jūs saprotat, ja mums tiltā ir qvb95d96a75-a0 ports, kas ir vEth pāris, tad kaut kur ir tā līdzinieks, kuru loģiski vajadzētu saukt par qvo95d96a75-a0. Apskatīsim, kādi porti ir uz OVS.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Kā redzam, osta atrodas br-int. Br-int darbojas kā slēdzis, kas pārtrauc virtuālās mašīnas portus. Papildus qvo95d96a75-a0 izvadā ir redzams ports qvo5bd37136-47. Šis ir ports uz otro virtuālo mašīnu. Rezultātā mūsu diagramma tagad izskatās šādi:
Jautājums, kuram uzreiz vajadzētu interesēt vērīgo lasītāju - kāds ir linux tilts starp virtuālās mašīnas portu un OVS portu? Fakts ir tāds, ka mašīnas aizsardzībai tiek izmantotas drošības grupas, kas ir nekas vairāk kā iptables. OVS nedarbojas ar iptables, tāpēc tika izgudrots šis “kruķis”. Tomēr tas kļūst novecojis - tas tiek aizstāts ar conntrack jaunajos izlaidumos.
Tas ir, galu galā shēma izskatās šādi:
Divas mašīnas vienā hipervizorā vienā L2 tīklā
Tā kā šīs divas virtuālās mašīnas atrodas tajā pašā L2 tīklā un tajā pašā hipervizorā, satiksme starp tām loģiski plūst lokāli caur br-int, jo abas mašīnas būs vienā VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Divas mašīnas dažādos hipervizoros vienā L2 tīklā
Tagad redzēsim, kā trafiks notiks starp divām mašīnām tajā pašā L2 tīklā, bet kas atrodas dažādos hipervizoros. Ja godīgi, nekas īpaši nemainīsies, tikai satiksme starp hipervizoriem ies caur vxlan tuneli. Apskatīsim piemēru.
To virtuālo mašīnu adreses, starp kurām mēs vērosim trafiku:
[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 ~]$ Mēs aplūkojam pārsūtīšanas tabulu br-int skaitļošanā-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Satiksmei vajadzētu virzīties uz 2. portu — paskatīsimies, kāda veida osta tas ir:
[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 ~]$Tas ir patch-tun - tas ir, interfeiss br-tun. Apskatīsim, kas notiek ar br-tun paku:
[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 ~]$ Pakete tiek iesaiņota VxLAN un nosūtīta uz 2. portu. Apskatīsim, kur ved 2. ports:
[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 ~]$Šis ir vxlan tunelis uz compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Dosimies uz compute-1 un redzēsim, kas notiks tālāk ar paketi:
[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 ir br-int pārsūtīšanas tabulā compute-1, un, kā redzams no iepriekš esošās izvades, tas ir redzams caur portu 2, kas ir ports virzienā uz br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Nu, tad mēs redzam, ka br-int uz compute-1 ir galamērķa magone:
[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 ~]$ Tas ir, saņemtā pakete lidos uz portu 3, aiz kura jau atrodas virtuālās mašīnas instance-00000003.
Openstack izvietošana mācībām virtuālajā infrastruktūrā ir tāda, ka mēs varam viegli uztvert trafiku starp hipervizoriem un redzēt, kas ar to notiek. Tas ir tas, ko mēs tagad darīsim, palaidīsim tcpdump vnet portā virzienā uz compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Pirmajā rindā redzams, ka Patek no adreses 10.0.1.85 dodas uz adresi 10.0.1.88 (ICMP trafiks), un tas ir iesaiņots VxLAN paketē ar vni 22, un pakete pāriet no resursdatora 192.168.255.19 (compute-0) uz resursdatoru 192.168.255.26. .1 ( aprēķina-XNUMX). Varam pārbaudīt, vai VNĪ atbilst ovs norādītajam.
Atgriezīsimies pie šīs rindas action=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],izeja:2. 0x16 ir vni heksadecimālajā skaitļu sistēmā. Pārveidosim šo skaitli 16. sistēmā:
16 = 6*16^0+1*16^1 = 6+16 = 22Tas ir, vni atbilst realitātei.
Otrajā rindā redzama atgriešanās satiksme, nu, nav jēgas to skaidrot, tur viss skaidrs.
Divas mašīnas dažādos tīklos (starptīklu maršrutēšana)
Pēdējais gadījums šodien ir maršrutēšana starp tīkliem viena projekta ietvaros, izmantojot virtuālo maršrutētāju. Mēs apsveram gadījumu bez DVR (mēs to aplūkosim citā rakstā), tāpēc maršrutēšana notiek tīkla mezglā. Mūsu gadījumā tīkla mezgls nav ievietots atsevišķā entītijā un atrodas vadības mezglā.
Vispirms apskatīsim, vai maršrutēšana darbojas:
$ 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 msTā kā šajā gadījumā paketei ir jāiet uz vārteju un jānovirza tur, mums ir jānoskaidro vārtejas magones adrese, kuras gadījumā mēs skatāmies uz ARP tabulu:
$ 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 eth0Tagad paskatīsimies, kur jānosūta satiksme ar galamērķi (10.0.1.254) fa:16:3e:c4:64:70:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Apskatīsim, kurp ved 2. ports:
[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 ~]$ Viss loģiski, satiksme iet uz br-tun. Apskatīsim, kurā vxlan tunelī tas tiks ietīts:
[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 ~]$ Trešais ports ir vxlan tunelis:
[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 ~]$ Kas aplūko vadības mezglu:
[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 ~]$ Satiksme ir sasniegusi vadības mezglu, tāpēc mums jādodas uz to un jāskatās, kā notiks maršrutēšana.
Kā atceraties, vadības mezgls iekšā izskatījās tieši tāpat kā skaitļošanas mezgls - tie paši trīs tilti, tikai br-ex bija fiziska pieslēgvieta, caur kuru mezgls varēja nosūtīt trafiku ārpusē. Instanču izveide mainīja konfigurāciju skaitļošanas mezglos - mezgliem tika pievienots linux tilts, iptables un saskarnes. Tīklu un virtuālā maršrutētāja izveide arī atstāja savas pēdas vadības mezgla konfigurācijā.
Tātad ir skaidrs, ka vārtejas MAC adresei jābūt vadības mezgla br-int pārsūtīšanas tabulā. Pārbaudīsim, vai tas tur ir un kur tas meklē:
[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 ir redzams no porta qr-0c52b15f-8f. Ja mēs atgriežamies pie Openstack virtuālo portu saraksta, šāda veida porti tiek izmantoti dažādu virtuālo ierīču savienošanai ar OVS. Precīzāk sakot, qr ir ports uz virtuālo maršrutētāju, kas tiek attēlots kā nosaukumvieta.
Apskatīsim, kādas nosaukumvietas atrodas serverī:
[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 ~]$ Pat trīs eksemplāri. Bet, spriežot pēc nosaukumiem, jūs varat uzminēt katra no tiem mērķi. Mēs vēlāk atgriezīsimies pie gadījumiem ar ID 0 un 1, tagad mūs interesē nosaukumvieta qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ Šajā nosaukumvietā ir divas iekšējās, kuras mēs izveidojām iepriekš. Abi virtuālie porti ir pievienoti br-int. Pārbaudīsim porta qr-0c52b15f-8f mac adresi, jo trafiks, spriežot pēc galamērķa mac adreses, nonāca šajā saskarnē.
[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 ~]$ Tas ir, šajā gadījumā viss darbojas saskaņā ar standarta maršrutēšanas likumiem. Tā kā trafiks ir paredzēts resursdatoram 10.0.2.8, tai ir jāiziet caur otro saskarni qr-92fa49b5-54 un jāiet cauri vxlan tuneli uz skaitļošanas mezglu:
[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 ~]$ Viss ir loģiski, bez pārsteigumiem. Apskatīsim, kur br-int ir redzama resursdatora 10.0.2.8 magones adrese:
[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 ~]$ Kā paredzēts, satiksme virzās uz br-tun, paskatīsimies, uz kuru tuneli satiksme virzīsies tālāk:
[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 ~]$ Satiksme ieiet tunelī, lai aprēķinātu-1. Nu, compute-1 viss ir vienkārši - no br-tun pakotne nonāk br-int un no turienes uz virtuālās mašīnas saskarni:
[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 ~]$ Pārbaudīsim, vai šī patiešām ir pareizā saskarne:
[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 ~]$ Patiesībā mēs izgājām cauri paku. Es domāju, ka pamanījāt, ka satiksme gāja pa dažādiem vxlan tuneļiem un izbrauca ar dažādiem VNI. Apskatīsim, kas tie ir par VNI, pēc tam savāksim izgāztuvi mezgla vadības portā un pārliecināsimies, ka satiksme notiek tieši tā, kā aprakstīts iepriekš.
Tātad tunelim, lai aprēķinātu-0, ir šādas darbības=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],izeja:3. Pārveidosim 0x16 par decimālo skaitļu sistēmu:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunelim, lai aprēķinātu-1, ir šāds VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],izeja:2. Pārveidosim 0x63 par decimālo skaitļu sistēmu:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Nu, tagad apskatīsim izgāztuvi:
[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*******************Pirmā pakete ir vxlan pakete no resursdatora 192.168.255.19 (compute-0) uz resursdatoru 192.168.255.15 (control-1) ar vni 22, kurā ir iesaiņota ICMP pakete no resursdatora 10.0.1.85 uz resursdatoru 10.0.2.8. Kā mēs aprēķinājām iepriekš, vni atbilst tam, ko mēs redzējām izvadē.
Otrā pakete ir vxlan pakete no resursdatora 192.168.255.15 (control-1) uz resursdatoru 192.168.255.26 (compute-1) ar vni 99, kurā ICMP pakete ir iepakota no resursdatora 10.0.1.85 uz resursdatoru 10.0.2.8. Kā mēs aprēķinājām iepriekš, vni atbilst tam, ko mēs redzējām izvadē.
Nākamās divas paketes ir atgriezeniskā trafika no 10.0.2.8, nevis 10.0.1.85.
Tas ir, galu galā mēs saņēmām šādu vadības mezgla shēmu:
Izskatās, ka tas tā ir? Mēs aizmirsām par divām nosaukumvietām:
[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 ~]$ Tā kā mēs runājām par mākoņa platformas arhitektūru, būtu labi, ja mašīnas automātiski saņemtu adreses no DHCP servera. Šie ir divi DHCP serveri mūsu diviem tīkliem 10.0.1.0/24 un 10.0.2.0/24.
Pārbaudīsim, vai tā ir patiesība. Šajā nosaukumvietā ir tikai viena adrese - 10.0.1.1 - paša DHCP servera adrese, un tā ir iekļauta arī br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Apskatīsim, vai procesi, kuru nosaukumā vadības mezglā ir ietverti qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ Šāds process pastāv, un, pamatojoties uz iepriekš iznākumā sniegto informāciju, mēs, piemēram, varam redzēt, kas mums šobrīd ir īrējams:
[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 ~]$Rezultātā vadības mezglā mēs iegūstam šādu pakalpojumu kopu:
Nu, paturiet prātā - šīs ir tikai 4 mašīnas, 2 iekšējie tīkli un viens virtuālais maršrutētājs... Mums šeit nav ārējo tīklu, ir daudz dažādu projektu, katram ir savi tīkli (pārklājas), un mums ir sadalīts maršrutētājs izslēdzās, un galu galā testa stendā bija tikai viens kontroles mezgls (lai nodrošinātu kļūdu toleranci, ir jābūt trīs mezglu kvorumam). Loģiski, ka tirdzniecībā viss ir “nedaudz” sarežģītāk, taču šajā vienkāršajā piemērā mēs saprotam, kā tam vajadzētu darboties – protams, ir svarīgi, vai tev ir 3 vai 300 nosaukumvietas, bet no visas nosaukumvietas darbības viedokļa. struktūra, nekas daudz nemainīsies... lai gan, kamēr jūs nepievienosiet kāda pārdevēja SDN. Bet tas ir pavisam cits stāsts.
Ceru, ka bija interesanti. Ja jums ir kādi komentāri/papildinājumi vai kaut kur es tieši meloju (esmu cilvēks un mans viedoklis vienmēr būs subjektīvs) - rakstiet, kas jālabo/pievieno - visu labosim/pievienosim.
Nobeigumā es vēlos teikt dažus vārdus par Openstack (gan vaniļas, gan pārdevēja) salīdzināšanu ar mākoņrisinājumu no VMWare — man šis jautājums pēdējo pāris gadu laikā ir uzdots pārāk bieži, un, atklāti sakot, es esmu jau apnicis, bet tomēr. Manuprāt, ir ļoti grūti salīdzināt šos divus risinājumus, taču noteikti varam teikt, ka abiem risinājumiem ir trūkumi un izvēloties vienu risinājumu ir jāizsver plusi un mīnusi.
Ja OpenStack ir kopienas virzīts risinājums, tad VMWare ir tiesības darīt tikai to, ko vēlas (lasi - kas tam ir izdevīgi) un tas ir loģiski - jo tā ir komercsabiedrība, kas ir pieradusi pelnīt naudu no saviem klientiem. Bet ir viens liels un trekns BET - jūs varat izkāpt no OpenStack, piemēram, no Nokia un ar nelieliem izdevumiem pāriet uz risinājumu, piemēram, no Juniper (Contrail Cloud), bet diez vai jūs varēsit izkāpt no VMWare . Man šie divi risinājumi izskatās šādi - Openstack (vendor) ir vienkāršs būris, kurā tevi ieliek, bet tev ir atslēga un tu vari iziet jebkurā brīdī. VMWare ir zelta būris, saimniekam ir būra atslēga un tas tev izmaksās dārgi.
Es nereklamēju ne pirmo, ne otro produktu - jūs izvēlaties to, kas jums nepieciešams. Bet, ja man būtu tāda izvēle, es izvēlētos abus risinājumus - VMWare IT mākonim (zemas slodzes, vienkārša pārvaldība), OpenStack no kāda pārdevēja (Nokia un Juniper nodrošina ļoti labus pabeigtus risinājumus) - Telecom mākonim. Es neizmantotu Openstack tikai IT vajadzībām - tas ir kā šaut uz zvirbuļiem ar lielgabalu, bet es neredzu nekādas kontrindikācijas tā lietošanai, izņemot atlaišanu. Tomēr VMWare izmantošana telekomunikācijās ir kā šķembu vilkšana ar Ford Raptor — tas ir skaisti no ārpuses, bet vadītājam ir jāveic 10 braucieni, nevis viens.
Manuprāt lielākais VMWare mīnuss ir tā pilnīga noslēgtība - uzņēmums nedos nekādu informāciju par to kā tas darbojas, piemēram, vSAN vai kas atrodas hipervizora kodolā - tas viņam vienkārši nav izdevīgi - proti, jūs nekad nekļūsti par VMWare ekspertu – bez pārdevēja atbalsta tu esi lemts (ļoti bieži es sastopu VMWare ekspertus, kuri ir neizpratnē par triviāliem jautājumiem). Man VMWare pērk auto ar aizslēgtu motora pārsegu - jā, jums var būt speciālisti, kas var nomainīt zobsiksnu, bet pārsegu var atvērt tikai tas, kurš jums pārdeva šo risinājumu. Personīgi man nepatīk risinājumi, kuros es nevaru iekļauties. Teiksiet, ka var nebūt zem pārsega iet. Jā, tas ir iespējams, bet es paskatīšos uz jums, kad jums būs jāsamontē liela funkcija mākonī no 20-30 virtuālajām mašīnām, 40-50 tīkliem, no kuriem puse vēlas iet ārā, bet otrā puse prasa SR-IOV paātrinājums, pretējā gadījumā jums būs nepieciešami vēl pāris desmiti šo automašīnu - pretējā gadījumā ar veiktspēju nepietiks.
Ir arī citi viedokļi, tāpēc tikai jūs varat izlemt, ko izvēlēties, un, pats galvenais, jūs pēc tam būsiet atbildīgs par savu izvēli. Tas ir tikai mans viedoklis - cilvēks, kurš ir redzējis un aptaustījis vismaz 4 produktus - Nokia, Juniper, Red Hat un VMWare. Tas ir, man ir ar ko salīdzināt.
Avots: www.habr.com
