Cloud computing preniká čoraz hlbšie do našich životov a snáď neexistuje jediný človek, ktorý by aspoň raz nevyužil žiadnu cloudovú službu. Čo to však vlastne cloud je a ako funguje, vie len málokto aj na úrovni nápadu. 5G sa už stáva realitou a telekomunikačná infraštruktúra sa začína presúvať od pólových riešení ku cloudovým riešeniam, rovnako ako keď sa presúvala z plne hardvérových riešení na virtualizované „piliere“.
Dnes si povieme niečo o vnútornom svete cloudovej infraštruktúry, konkrétne sa pozrieme na základy sieťovej časti.
čo je cloud? Rovnaká virtualizácia - zobrazenie profilu?
Viac ako logická otázka. Nie – nejde o virtualizáciu, aj keď bez nej by to nešlo. Pozrime sa na dve definície:
Cloud computing (ďalej len cloud) je model pre poskytovanie užívateľsky prívetivého prístupu k distribuovaným výpočtovým zdrojom, ktoré musia byť nasadené a spustené na požiadanie s čo najnižšou latenciou a minimálnymi nákladmi pre poskytovateľa služieb.
Virtualizácia - ide o možnosť rozdeliť jednu fyzickú entitu (napríklad server) na niekoľko virtuálnych, čím sa zvýši využitie zdrojov (napríklad 3 servery ste mali zaťažené na 25-30 percent, po virtualizácii sa vám načíta 1 server na 80-90 percent). Prirodzene, virtualizácia spotrebováva časť zdrojov - musíte nakŕmiť hypervízor, ale ako ukázala prax, hra stojí za sviečku. Ideálnym príkladom virtualizácie je VMWare, ktorý dokonale pripraví virtuálne stroje, alebo napríklad KVM, ktorý preferujem, ale to je vec vkusu.
Virtualizáciu používame bez toho, aby sme si to uvedomovali, a dokonca aj železné smerovače už virtualizáciu využívajú – napríklad v najnovšej verzii JunOS je operačný systém nainštalovaný ako virtuálny stroj nad distribúciou Linuxu v reálnom čase (Wind River 9). Ale virtualizácia nie je cloud, ale cloud nemôže existovať bez virtualizácie.
Virtualizácia je jedným zo stavebných kameňov, na ktorých je cloud postavený.
Vytvorenie cloudu jednoduchým zhromaždením niekoľkých hypervízorov do jednej domény L2, pridaním niekoľkých yaml playbookov na automatickú registráciu vlan cez nejaký ansible a zaseknutie niečoho ako orchestračný systém do toho všetkého na automatické vytváranie virtuálnych strojov nebude fungovať. Bude to presnejšie, ale výsledný Frankenstein nie je cloud, ktorý by sme potrebovali, aj keď pre ostatných môže byť konečným snom. Navyše, ak si vezmete rovnaký Openstack, je to v podstate stále Frankenstein, ale dobre, teraz o tom nehovorme.
Ale chápem, že z vyššie uvedenej definície nie je úplne jasné, čo vlastne možno nazvať cloudom.
Preto dokument od NIST (Národný inštitút pre štandardy a technológie) poskytuje 5 hlavných charakteristík, ktoré by mala mať cloudová infraštruktúra:
Poskytovanie servisu na požiadanie. Používateľovi musí byť poskytnutý voľný prístup k jemu prideleným zdrojom počítača (ako sú siete, virtuálne disky, pamäť, jadrá procesorov atď.), pričom tieto prostriedky musia byť poskytnuté automaticky – teda bez zásahu poskytovateľa služby.
Široká dostupnosť služby. Prístup k zdrojom musí byť zabezpečený štandardnými mechanizmami, ktoré umožnia používanie štandardných počítačov, tenkých klientov a mobilných zariadení.
Kombinovanie zdrojov do skupín. Fondy zdrojov musia byť schopné poskytnúť zdroje viacerým klientom súčasne, čím sa zabezpečí, že klienti budú izolovaní a bez vzájomného ovplyvňovania a súťaženia o zdroje. Do poolov sú zahrnuté aj siete, čo naznačuje možnosť použitia prekrývajúceho sa adresovania. Bazény sa musia dať škálovať na požiadanie. Použitie poolov umožňuje poskytnúť potrebnú úroveň odolnosti proti chybám zdrojov a abstrakciu fyzických a virtuálnych zdrojov – príjemcovi služby je jednoducho poskytnutá množina zdrojov, ktorú požadoval (kde sa tieto zdroje fyzicky nachádzajú, na koľkých servery a prepínače – na klientovi nezáleží). Musíme však brať do úvahy skutočnosť, že poskytovateľ musí zabezpečiť transparentnú rezerváciu týchto zdrojov.
Rýchla adaptácia na rôzne podmienky. Služby musia byť flexibilné – rýchle poskytovanie zdrojov, ich prerozdeľovanie, pridávanie alebo znižovanie zdrojov na žiadosť klienta a zo strany klienta by mal byť pocit, že cloudových zdrojov je neúrekom. Pre ľahšie pochopenie sa vám napríklad nezobrazuje upozornenie, že časť vášho diskového priestoru v Apple iCloud zmizla, pretože sa pokazil pevný disk na serveri a disky sa pokazili. Navyše z vašej strany sú možnosti tejto služby takmer neobmedzené - potrebujete 2 TB - žiadny problém, zaplatili ste a dostali. Podobný príklad možno uviesť s Google.Drive alebo Yandex.Disk.
Možnosť merania poskytovanej služby. Cloudové systémy musia automaticky riadiť a optimalizovať spotrebované zdroje a tieto mechanizmy musia byť transparentné pre používateľa aj poskytovateľa služieb. To znamená, že vždy môžete skontrolovať, koľko zdrojov vy a vaši klienti spotrebúvate.
Za zváženie stojí fakt, že tieto požiadavky sú väčšinou požiadavky na verejný cloud, takže pre privátny cloud (teda cloud spustený pre interné potreby firmy) je možné tieto požiadavky mierne upraviť. Stále ich však treba urobiť, inak nezískame všetky výhody cloud computingu.
Prečo potrebujeme cloud?
Každá nová alebo existujúca technológia, každý nový protokol je však vytvorený pre niečo (samozrejme okrem RIP-ng). Nikto nepotrebuje protokol kvôli protokolu (okrem RIP-ng, samozrejme). Je logické, že Cloud je vytvorený za účelom poskytovania nejakého druhu služby používateľovi/klientovi. Všetci poznáme aspoň pár cloudových služieb, napríklad Dropbox alebo Google.Docs, a verím, že väčšina ľudí ich úspešne používa – napríklad tento článok bol napísaný pomocou cloudovej služby Google.Docs. Ale cloudové služby, ktoré poznáme, sú len časťou možností cloudu – presnejšie povedané, sú to len služby typu SaaS. Cloudovú službu vieme poskytnúť tromi spôsobmi: formou SaaS, PaaS alebo IaaS. Akú službu potrebujete, závisí od vašich túžob a schopností.
Pozrime sa na každú v poradí:
Softvér ako služba (SaaS) je model poskytovania plnohodnotnej služby klientovi, napríklad e-mailovej služby ako Yandex.Mail alebo Gmail. V tomto modeli poskytovania služieb vy ako klient vlastne nerobíte nič okrem využívania služieb – to znamená, že nemusíte myslieť na nastavenie služby, jej chybovosť či redundanciu. Hlavnou vecou nie je prelomiť heslo, zvyšok za vás urobí poskytovateľ tejto služby. Z pohľadu poskytovateľa služby je plne zodpovedný za celú službu – od serverového hardvéru a hostiteľských operačných systémov až po nastavenia databázy a softvéru.
Platforma ako služba (PaaS) — pri použití tohto modelu poskytovateľ služby poskytuje klientovi obrobok pre službu, napríklad webový server. Poskytovateľ služby poskytol klientovi virtuálny server (v skutočnosti súbor zdrojov, ako sú RAM/CPU/Storage/Nets, atď.), a dokonca na tento server nainštaloval OS a potrebný softvér, avšak konfigurácia všetky tieto veci si robí klient sám a za výkon služby sa klient odpovedá. Poskytovateľ služby, rovnako ako v predchádzajúcom prípade, je zodpovedný za výkon fyzického zariadenia, hypervízorov, samotného virtuálneho stroja, jeho sieťovej dostupnosti atď., ale samotná služba už nie je v jeho oblasti zodpovednosti.
Infraštruktúra ako služba (IaaS) - tento prístup je už zaujímavejší, v skutočnosti poskytovateľ služby poskytuje klientovi kompletnú virtualizovanú infraštruktúru - teda nejakú sadu (pool) zdrojov, ako sú CPU jadrá, RAM, siete atď. klient - čo chce klient s týmito zdrojmi robiť v rámci prideleného fondu (kvóty) - to nie je pre dodávateľa zvlášť dôležité. Či už si chce klient vytvoriť svoj vlastný vEPC alebo dokonca vytvoriť mini operátora a poskytovať komunikačné služby - niet pochýb - urobte to. V takomto scenári je poskytovateľ služieb zodpovedný za poskytovanie prostriedkov, ich odolnosť voči chybám a dostupnosť, ako aj za operačný systém, ktorý mu umožňuje združovať tieto prostriedky a sprístupňovať ich klientovi s možnosťou kedykoľvek zvýšiť alebo znížiť zdroje. na žiadosť klienta. Všetky virtuálne stroje a ďalšie pozlátka si klient nakonfiguruje sám cez samoobslužný portál a konzolu vrátane nastavenia sietí (okrem externých sietí).
Čo je OpenStack?
Vo všetkých troch možnostiach poskytovateľ služieb potrebuje OS, ktorý umožní vytvorenie cloudovej infraštruktúry. V skutočnosti je pri SaaS viac ako jedna divízia zodpovedná za celý zásobník technológií - existuje divízia, ktorá je zodpovedná za infraštruktúru - to znamená, že poskytuje IaaS inej divízii, táto divízia poskytuje SaaS klientovi. OpenStack je jeden z cloudových operačných systémov, ktorý vám umožňuje zhromaždiť množstvo prepínačov, serverov a úložných systémov do jedného fondu zdrojov, rozdeliť tento spoločný fond na podfondy (nájomníkov) a poskytnúť tieto prostriedky klientom cez sieť.
OpenStack je cloudový operačný systém, ktorý vám umožňuje ovládať veľké skupiny výpočtových zdrojov, dátových úložísk a sieťových zdrojov, poskytovaných a spravovaných prostredníctvom API pomocou štandardných autentifikačných mechanizmov.
Inými slovami, ide o súbor projektov slobodného softvéru, ktorý je určený na vytváranie cloudových služieb (verejných aj súkromných) – to znamená súbor nástrojov, ktoré vám umožňujú kombinovať server a prepínacie zariadenia do jedného fondu zdrojov, spravovať tieto zdroje poskytujú potrebnú úroveň odolnosti voči chybám.
V čase písania tohto materiálu vyzerá štruktúra OpenStack takto:
Obrázok prevzatý z
Každý z komponentov zahrnutých v OpenStack vykonáva špecifickú funkciu. Táto distribuovaná architektúra vám umožňuje zahrnúť do riešenia sadu funkčných komponentov, ktoré potrebujete. Niektoré komponenty sú však koreňové komponenty a ich odstránenie povedie k úplnej alebo čiastočnej nefunkčnosti riešenia ako celku. Tieto komponenty sú zvyčajne klasifikované ako:
- Informačný panel — Webové grafické rozhranie na správu služieb OpenStack
- Keystone je centralizovaná služba identity, ktorá poskytuje funkcie overovania a autorizácie pre iné služby, ako aj správu poverení používateľov a ich rolí.
- Neutrón - sieťová služba, ktorá poskytuje konektivitu medzi rozhraniami rôznych služieb OpenStack (vrátane konektivity medzi VM a ich prístupu k vonkajšiemu svetu)
- škvára — poskytuje prístup k ukladaniu blokov pre virtuálne stroje
- Nova — riadenie životného cyklu virtuálnych strojov
- pohľad — úložisko obrazov virtuálnych strojov a snímok
- Rýchly — poskytuje prístup k objektu úložiska
- Ceilometer — služba, ktorá poskytuje možnosť zhromažďovať telemetriu a merať dostupné a spotrebované zdroje
- teplo — orchestrácia založená na šablónach na automatické vytváranie a poskytovanie zdrojov
Kompletný zoznam všetkých projektov a ich účel si môžete pozrieť .
Každý komponent OpenStack je služba, ktorá vykonáva špecifickú funkciu a poskytuje API na správu tejto funkcie a interakciu s inými cloudovými službami operačného systému na vytvorenie jednotnej infraštruktúry. Napríklad Nova poskytuje správu výpočtových zdrojov a API na prístup ku konfigurácii týchto zdrojov, Glance poskytuje správu obrázkov a API na ich správu, Cinder poskytuje blokové úložisko a API na ich správu atď. Všetky funkcie sú navzájom veľmi úzko prepojené.
Ak sa však na to pozriete, všetky služby bežiace v OpenStack sú v konečnom dôsledku nejakým druhom virtuálneho stroja (alebo kontajnera) pripojeného k sieti. Vynára sa otázka – prečo potrebujeme toľko prvkov?
Poďme si prejsť algoritmus na vytvorenie virtuálneho počítača a jeho pripojenie k sieti a trvalému úložisku v Openstacku.
- Keď vytvoríte požiadavku na vytvorenie stroja, či už ide o požiadavku cez Horizon (Dashboard) alebo požiadavku cez CLI, prvá vec, ktorá sa stane, je autorizácia vašej požiadavky na Keystone – môžete vytvoriť stroj, má právo používať túto sieť, váš návrh kvóty atď.
- Keystone overí vašu požiadavku a v odpovedi vygeneruje auth token, ktorý sa bude ďalej používať. Po prijatí odpovede od Keystone sa požiadavka odošle do Nova (nova api).
- Nova-api skontroluje platnosť vašej požiadavky kontaktovaním Keystone pomocou predtým vygenerovaného autorizačného tokenu
- Keystone vykonáva autentifikáciu a poskytuje informácie o povoleniach a obmedzeniach na základe tohto autorizačného tokenu.
- Nova-api vytvorí záznam pre nový VM v nova-database a odošle požiadavku na vytvorenie počítača nova-scheduler.
- Nova-scheduler vyberie hostiteľa (počítačový uzol), na ktorom bude VM nasadený na základe špecifikovaných parametrov, váh a zón. Záznam o tom a VM ID sa zapíšu do databázy nova.
- Ďalej nova-scheduler kontaktuje nova-compute s požiadavkou na nasadenie inštancie. Nova-compute kontaktuje nova-conductor, aby získal informácie o parametroch stroja (nova-conductor je prvok nova, ktorý funguje ako proxy server medzi nova-databázou a nova-compute, čím obmedzuje počet požiadaviek na nova-databázu, aby sa predišlo problémom s databázou zníženie konzistentného zaťaženia).
- Nova-conductor dostane požadované informácie z nova-databázy a odovzdá ich nova-compute.
- Potom sa nova-compute pozrie, aby získal ID obrázka. Glace overí požiadavku v Keystone a vráti požadované informácie.
- Nova-compute kontaktuje neutrón, aby získal informácie o parametroch siete. Podobne ako pri pohľade, neutrón overí požiadavku v Keystone, potom vytvorí záznam v databáze (identifikátor portu atď.), vytvorí požiadavku na vytvorenie portu a vráti požadované informácie do nova-compute.
- Kontakty Nova-compute sú popálené žiadosťou o pridelenie zväzku virtuálnemu stroju. Podobne ako pri pohľade, cider overí požiadavku v Keystone, vytvorí požiadavku na vytvorenie zväzku a vráti požadované informácie.
- Nova-compute kontaktuje libvirt so žiadosťou o nasadenie virtuálneho stroja so zadanými parametrami.
V skutočnosti sa zdanlivo jednoduchá operácia vytvorenia jednoduchého virtuálneho stroja zmení na taký kolotoč API volaní medzi prvkami cloudovej platformy. Navyše, ako vidíte, aj predtým určené služby pozostávajú z menších komponentov, medzi ktorými dochádza k interakcii. Vytvorenie stroja je len malá časť toho, čo vám cloudová platforma umožňuje – existuje služba zodpovedná za vyváženie prevádzky, služba zodpovedná za ukladanie blokov, služba zodpovedná za DNS, služba zodpovedná za poskytovanie serverov na holé kovové účely atď. Cloud vám umožňuje zaobchádzať so svojimi virtuálnymi strojmi ako so stádom oviec (na rozdiel od virtualizácie). Ak sa vášmu stroju niečo stane vo virtuálnom prostredí – obnovíte ho zo záloh a pod., no cloudové aplikácie sú postavené tak, že virtuálny stroj nehrá takú dôležitú úlohu – virtuálny stroj „zomrel“ – žiadny problém - jednoducho sa vytvorí nové vozidlo vychádza zo šablóny a ako sa hovorí, čata si nevšimla stratu stíhačky. Prirodzene to zabezpečuje prítomnosť mechanizmov orchestrácie – pomocou šablón Heat môžete jednoducho nasadiť komplexnú funkciu pozostávajúcu z desiatok sietí a virtuálnych strojov.
Vždy stojí za to mať na pamäti, že neexistuje žiadna cloudová infraštruktúra bez siete – každý prvok tak či onak interaguje s inými prvkami prostredníctvom siete. Okrem toho má cloud absolútne nestatickú sieť. Podkladová sieť je, samozrejme, ešte viac-menej statická – nové uzly a prepínače sa nepridávajú každý deň, ale prekryvný komponent sa môže a nevyhnutne bude neustále meniť – budú pridané alebo vymazané nové siete, objavia sa nové virtuálne stroje a staré budú zomrieť. A ako si pamätáte z definície cloudu uvedenej na samom začiatku článku, zdroje by mali byť používateľovi prideľované automaticky a s čo najmenším (alebo ešte lepšie, bez) zásahu poskytovateľa služby. To znamená, že typ poskytovania sieťových zdrojov, ktorý teraz existuje vo forme front-endu vo forme vášho osobného účtu prístupného cez http/https a službukonajúceho sieťového inžiniera Vasilija ako backend, nie je cloud, dokonca ani ak má Vasilij osem rúk.
Neutron ako sieťová služba poskytuje API na správu sieťovej časti cloudovej infraštruktúry. Služba poháňa a spravuje sieťovú časť Openstacku poskytovaním abstrakcie s názvom Network-as-a-Service (NaaS). To znamená, že sieť je rovnaká virtuálna merateľná jednotka ako napríklad virtuálne jadrá CPU alebo množstvo RAM.
Predtým, ako prejdeme k architektúre sieťovej časti OpenStacku, sa však zamyslime nad tým, ako táto sieť funguje v OpenStacku a prečo je sieť dôležitou a integrálnou súčasťou cloudu.
Máme teda dva ČERVENÉ klientske VM a dva ZELENÉ klientske VM. Predpokladajme, že tieto stroje sú umiestnené na dvoch hypervízoroch týmto spôsobom:
Momentálne je to len virtualizácia 4 serverov a nič viac, keďže zatiaľ sme urobili iba virtualizáciu 4 serverov, ktoré sme umiestnili na dva fyzické servery. A doteraz nie sú ani pripojené k sieti.
Aby sme vytvorili cloud, musíme pridať niekoľko komponentov. Najprv virtualizujeme sieťovú časť – potrebujeme spojiť tieto 4 stroje do párov a klienti chcú L2 pripojenie. Môžete použiť switch a nakonfigurovať trunk v jeho smere a všetko vyriešiť pomocou linux bridge alebo pre pokročilejších openvswitch (k tomu sa ešte vrátime). Ale môže existovať veľa sietí a neustále pretláčanie L2 cez prepínač nie je najlepší nápad - existujú rôzne oddelenia, servis, mesiace čakania na dokončenie aplikácie, týždne riešenia problémov - v modernom svete to prístup už nefunguje. A čím skôr to firma pochopí, tým ľahšie sa posunie vpred. Preto medzi hypervízormi vyberieme L3 sieť, cez ktorú budú naše virtuálne stroje komunikovať a nad touto L3 sieťou vybudujeme virtuálne L2 prekryvné siete, kde bude prebiehať prevádzka našich virtuálnych strojov. Ako zapuzdrenie môžete použiť GRE, Geneve alebo VxLAN. Sústreďme sa zatiaľ na to druhé, hoci to nie je zvlášť dôležité.
Musíme niekde nájsť VTEP (dúfam, že každý pozná terminológiu VxLAN). Keďže máme sieť L3 prichádzajúcu priamo zo serverov, nič nám nebráni umiestniť VTEP na samotné servery a OVS (OpenvSwitch) je v tom vynikajúci. V dôsledku toho sme dostali tento dizajn:
Keďže prevádzka medzi VM musí byť rozdelená, porty smerom k virtuálnym počítačom budú mať rôzne čísla vlan. Číslo tagu hrá rolu len v rámci jedného virtuálneho prepínača, keďže po zapuzdrení do VxLAN ho môžeme ľahko odstrániť, keďže budeme mať VNI.
Teraz pre ne môžeme bez problémov vytvárať naše stroje a virtuálne siete.
Čo však v prípade, ak má klient iný počítač, ale nachádza sa v inej sieti? Potrebujeme rootovanie medzi sieťami. Pozrime sa na jednoduchú možnosť, keď sa používa centralizované smerovanie - to znamená, že prevádzka je smerovaná cez špeciálne vyhradené uzly siete (spravidla sú kombinované s riadiacimi uzlami, takže budeme mať to isté).
Zdá sa, že to nie je nič zložité – na riadiacom uzle urobíme mostové rozhranie, nasmerujeme doň dopravu a odtiaľ ju nasmerujeme tam, kam potrebujeme. Problém je ale v tom, že ČERVENÝ klient chce používať sieť 10.0.0.0/24 a ZELENÝ klient chce používať sieť 10.0.0.0/24. To znamená, že začíname pretínať adresné priestory. Okrem toho klienti nechcú, aby ostatní klienti mohli smerovať do ich interných sietí, čo dáva zmysel. Aby sme oddelili siete a dátovú prevádzku klienta, pridelíme každej z nich samostatný menný priestor. Menný priestor je v skutočnosti kópiou linuxového sieťového zásobníka, to znamená, že klienti v mennom priestore ČERVENÝ sú úplne izolovaní od klientov od ZELEného menného priestoru (dobre, smerovanie medzi týmito klientskymi sieťami je povolené cez predvolený menný priestor alebo na nadradených transportných zariadeniach).
To znamená, že dostaneme nasledujúci diagram:
Tunely L2 sa zbiehajú zo všetkých výpočtových uzlov do riadiaceho uzla. uzol, kde sa nachádza rozhranie L3 pre tieto siete, každý vo vyhradenom mennom priestore na izoláciu.
Zabudli sme však na to najdôležitejšie. Virtuálny stroj musí poskytovať službu klientovi, to znamená, že musí mať aspoň jedno externé rozhranie, cez ktoré je dostupný. To znamená, že musíme ísť von do vonkajšieho sveta. Tu sú rôzne možnosti. Urobme najjednoduchšiu možnosť. Každému klientovi pridáme jednu sieť, ktorá bude platná v sieti poskytovateľa a nebude sa prekrývať s inými sieťami. Siete sa môžu tiež pretínať a pozerať sa na rôzne VRF na strane siete poskytovateľa. Sieťové údaje budú tiež žiť v mennom priestore každého klienta. Stále však budú vychádzať von do vonkajšieho sveta cez jedno fyzické (alebo puto, čo je logickejšie) rozhranie. Aby sa oddelila návštevnosť klienta, premávka smerujúca von bude označená značkou VLAN pridelenou klientovi.
V dôsledku toho sme dostali tento diagram:
Rozumnou otázkou je, prečo nevytvoriť brány na samotných výpočtových uzloch? Nie je to veľký problém, navyše, ak zapnete distribuovaný smerovač (DVR), bude to fungovať. V tomto scenári zvažujeme najjednoduchšiu možnosť s centralizovanou bránou, ktorá sa štandardne používa v Openstacku. Pre funkcie s vysokou záťažou využijú distribuovaný smerovač aj akceleračné technológie ako SR-IOV a Passthrough, ale ako sa hovorí, to je úplne iný príbeh. Najprv sa poďme venovať základnej časti a potom prejdeme k detailom.
V skutočnosti je naša schéma už funkčná, ale existuje niekoľko nuancií:
- Musíme nejako chrániť naše stroje, to znamená dať filter na rozhranie prepínača smerom ku klientovi.
- Umožnite virtuálnemu stroju automaticky získať IP adresu, aby ste sa doň nemuseli zakaždým prihlasovať cez konzolu a registrovať adresu.
Začnime ochranou stroja. Na to môžete použiť banálne iptables, prečo nie.
To znamená, že teraz sa naša topológia trochu skomplikovala:
Poďme ďalej. Potrebujeme pridať server DHCP. Najideálnejším miestom na lokalizáciu serverov DHCP pre každého klienta by bol už spomenutý riadiaci uzol, kde sa nachádzajú priestory názvov:
Je tu však malý problém. Čo ak sa všetko reštartuje a všetky informácie o prenajímaní adries na DHCP zmiznú. Je logické, že stroje dostanú nové adresy, čo nie je príliš pohodlné. Tu sú dva spôsoby - buď použiť názvy domén a pridať DNS server pre každého klienta, potom pre nás adresa nebude obzvlášť dôležitá (podobne ako sieťová časť v k8s) - ale je tu problém s externými sieťami, pretože adresy sa v nich dajú vydávať aj cez DHCP - potrebujete synchronizáciu s DNS servermi v cloudovej platforme a externý DNS server, čo podľa mňa nie je príliš flexibilné, ale je celkom možné. Alebo druhá možnosť je použiť metadáta – teda uložiť informácie o adrese pridelenej stroju, aby server DHCP vedel, ktorú adresu má stroju vydať, ak stroj už adresu dostal. Druhá možnosť je jednoduchšia a flexibilnejšia, pretože umožňuje uložiť ďalšie informácie o aute. Teraz do diagramu pridáme metadáta agenta:
Ďalšou otázkou, ktorá tiež stojí za diskusiu, je možnosť používať jednu externú sieť všetkými klientmi, pretože externé siete, ak musia byť platné v celej sieti, budú ťažké - musíte neustále prideľovať a kontrolovať prideľovanie týchto sietí. Možnosť použiť jednu externú predkonfigurovanú sieť pre všetkých klientov bude veľmi užitočná pri vytváraní verejného cloudu. To uľahčí nasadenie strojov, pretože nemusíme konzultovať databázu adries a vyberať jedinečný adresný priestor pre externú sieť každého klienta. Okrem toho si môžeme vopred zaregistrovať externú sieť a v čase nasadenia nám bude stačiť priradiť externé adresy ku klientskym strojom.
A tu nám prichádza na pomoc NAT – my len umožníme klientom prístup do vonkajšieho sveta cez predvolený menný priestor pomocou prekladu NAT. No, tu je malý problém. To je dobré, ak klientsky server funguje ako klient a nie ako server – to znamená, že skôr iniciuje ako prijíma pripojenia. Ale u nás to bude naopak. V tomto prípade musíme urobiť cieľový NAT, aby riadiaci uzol pri prijímaní prevádzky pochopil, že táto prevádzka je určená pre virtuálny stroj A klienta A, čo znamená, že musíme urobiť preklad NAT z externej adresy, napríklad 100.1.1.1 .10.0.0.1, na internú adresu 100. V tomto prípade, hoci všetci klienti budú používať rovnakú sieť, vnútorná izolácia je úplne zachovaná. To znamená, že musíme urobiť dNAT a sNAT na riadiacom uzle. Či použiť jednu sieť s pohyblivými adresami alebo externé siete, alebo obe naraz, závisí od toho, čo chcete do cloudu priniesť. Do diagramu nepridáme plávajúce adresy, ale ponecháme externé siete už pridané skôr - každý klient má svoju vlastnú externú sieť (v diagrame sú na externom rozhraní označené ako vlan 200 a XNUMX).
Vďaka tomu sme dostali zaujímavé a zároveň premyslené riešenie, ktoré má istú flexibilitu, no zatiaľ nedisponuje mechanizmami odolnosti voči chybám.
Po prvé, máme len jeden riadiaci uzol - jeho zlyhanie povedie ku kolapsu všetkých systémov. Ak chcete vyriešiť tento problém, musíte vytvoriť kvórum aspoň 3 uzlov. Pridajme to do diagramu:
Prirodzene, všetky uzly sú synchronizované a keď aktívny uzol odíde, iný uzol prevezme jeho povinnosti.
Ďalším problémom sú disky virtuálnych strojov. Momentálne sú uložené na samotných hypervízoroch a v prípade problémov s hypervízorom prídeme o všetky dáta - a prítomnosť raidu tu nepomôže, ak stratíme nie disk, ale celý server. Aby sme to dosiahli, musíme vytvoriť službu, ktorá bude fungovať ako frontend pre nejaký druh úložiska. Aké úložisko to bude, nie je pre nás zvlášť dôležité, no malo by chrániť naše dáta pred zlyhaním ako disku, tak aj uzla, prípadne celej skrinky. Existuje niekoľko možností - samozrejme existujú siete SAN s Fibre Channel, ale povedzme si úprimne - FC je už relikt minulosti - analóg E1 v doprave - áno, súhlasím, stále sa používa, ale len tam, kde to bez nej absolútne nejde. Preto by som v roku 2020 dobrovoľne nenasadil sieť FC s vedomím, že existujú aj iné zaujímavejšie alternatívy. Hoci každý má svoje vlastné, môžu sa nájsť takí, ktorí veria, že FC so všetkými jeho obmedzeniami je všetko, čo potrebujeme - nebudem sa hádať, každý má svoj vlastný názor. Najzaujímavejším riešením je však podľa mňa použiť KBÚ, napríklad Ceph.
Ceph vám umožňuje vybudovať vysoko dostupné riešenie na ukladanie dát s množstvom možných možností zálohovania, počnúc kódmi s kontrolou parity (analogicky ako raid 5 alebo 6) končiac úplnou replikáciou dát na rôzne disky, berúc do úvahy umiestnenie diskov v servery a servery v skriniach atď.
Na zostavenie Ceph potrebujete 3 ďalšie uzly. Interakcia s úložiskom bude prebiehať aj cez sieť pomocou služieb blokového, objektového a súborového úložiska. Pridajme úložisko do schémy:
Poznámka: Môžete tiež vytvoriť hyperkonvergované výpočtové uzly - to je koncept kombinovania niekoľkých funkcií na jednom uzle - napríklad storage+compute - bez vyhradenia špeciálnych uzlov pre ukladanie ceph. Získame rovnakú schému odolnosti voči chybám – keďže SDS bude rezervovať údaje s úrovňou rezervácie, ktorú určíme. Hyperkonvergované uzly sú však vždy kompromisom – keďže storage node neohrieva len vzduch, ako sa na prvý pohľad zdá (keďže na ňom nie sú žiadne virtuálne stroje) – míňa prostriedky CPU na obsluhu SDS (v skutočnosti robí všetko replikácia a obnova po zlyhaniach uzlov, diskov atď.). To znamená, že stratíte časť výkonu výpočtového uzla, ak ho skombinujete s úložiskom.
Všetky tieto veci je potrebné nejako riadiť - potrebujeme niečo, pomocou čoho vytvoríme počítač, sieť, virtuálny router atď. Na tento účel pridáme do riadiaceho uzla službu, ktorá bude fungovať ako dashboard - klient sa bude môcť pripojiť k tomuto portálu cez http/ https a robiť všetko, čo potrebuje (no, skoro).
Výsledkom je, že teraz máme systém odolný voči chybám. Všetky prvky tejto infraštruktúry sa musia nejako riadiť. Už skôr bolo popísané, že Openstack je súbor projektov, z ktorých každý poskytuje špecifickú funkciu. Ako vidíme, prvkov, ktoré je potrebné konfigurovať a ovládať, je viac než dosť. Dnes si povieme niečo o sieťovej časti.
Neutrónová architektúra
V OpenStack je to Neutron, kto je zodpovedný za pripojenie portov virtuálnych strojov do spoločnej siete L2, zabezpečenie smerovania prevádzky medzi VM umiestnenými v rôznych sieťach L2, ako aj smerovanie smerom von, poskytovanie služieb ako NAT, Floating IP, DHCP atď.
Na vysokej úrovni možno prevádzku sieťovej služby (základnej časti) opísať nasledovne.
Pri spustení VM sieťová služba:
- Vytvorí port pre daný VM (alebo porty) a upozorní na to službu DHCP;
- Vytvorí sa nové virtuálne sieťové zariadenie (cez libvirt);
- VM sa pripojí k portu (portom) vytvoreným v kroku 1;
Napodiv, práca Neutronu je založená na štandardných mechanizmoch, ktoré pozná každý, kto sa niekedy ponoril do Linuxu – menné priestory, iptables, linuxové mosty, openvswitch, conntrack atď.
Malo by byť okamžite objasnené, že Neutron nie je SDN kontrolér.
Neutrón pozostáva z niekoľkých vzájomne prepojených komponentov:
Openstack-neutrónový server je démon, ktorý pracuje s požiadavkami používateľov prostredníctvom API. Tento démon nie je zapojený do registrácie žiadnych sieťových pripojení, ale poskytuje potrebné informácie svojim pluginom, ktoré potom nakonfigurujú požadovaný sieťový prvok. Neutrónoví agenti na uzloch OpenStack sa registrujú na serveri Neutron.
Neutron-server je vlastne aplikácia napísaná v pythone, ktorá pozostáva z dvoch častí:
- Služba REST
- Neutron Plugin (jadro/služba)
Služba REST je navrhnutá tak, aby prijímala volania API z iných komponentov (napríklad žiadosť o poskytnutie niektorých informácií atď.)
Pluginy sú zásuvné softvérové komponenty/moduly, ktoré sa volajú počas požiadaviek API – to znamená, že prostredníctvom nich dochádza k priradeniu služby. Pluginy sú rozdelené do dvoch typov - servisné a koreňové. Zásuvný modul koňa je spravidla zodpovedný hlavne za správu adresného priestoru a L2 spojení medzi virtuálnymi počítačmi a zásuvné moduly služieb už poskytujú ďalšie funkcie, ako napríklad VPN alebo FW.
Zoznam dnes dostupných pluginov si môžete pozrieť napr
Môže existovať niekoľko zásuvných modulov služieb, ale môže existovať iba jeden zásuvný modul pre kone.
openstack-neutron-ml2 je štandardný koreňový doplnok Openstack. Tento plugin má modulárnu architektúru (na rozdiel od svojho predchodcu) a konfiguruje sieťovú službu pomocou ovládačov, ktoré sú k nemu pripojené. Na samotný plugin sa pozrieme o niečo neskôr, pretože v skutočnosti poskytuje flexibilitu, ktorú má OpenStack v sieťovej časti. Koreňový plugin je možné nahradiť (napríklad Contrail Networking robí takúto výmenu).
RPC služba (rabbitmq-server) — služba, ktorá poskytuje správu frontov a interakciu s inými službami OpenStack, ako aj interakciu medzi agentmi sieťových služieb.
Sieťoví agenti — agenti, ktorí sa nachádzajú v každom uzle, prostredníctvom ktorých sa konfigurujú sieťové služby.
Existuje niekoľko typov agentov.
Hlavným agentom je L2 agent. Títo agenti bežia na každom z hypervízorov vrátane riadiacich uzlov (presnejšie na všetkých uzloch, ktoré poskytujú akúkoľvek službu pre nájomníkov) a ich hlavnou funkciou je pripojiť virtuálne stroje k spoločnej sieti L2 a tiež generovať upozornenia, keď nastanú nejaké udalosti ( napríklad zakázať/povoliť port).
Ďalším, nemenej dôležitým agentom je L3 agent. Štandardne tento agent beží výlučne na sieťovom uzle (často je sieťový uzol kombinovaný s riadiacim uzlom) a poskytuje smerovanie medzi sieťami nájomníkov (medzi svojimi sieťami aj sieťami iných nájomníkov a je prístupný vonkajšiemu svetu, pričom poskytuje NAT, ako aj služba DHCP). Pri použití DVR (distribuovaného smerovača) sa však na výpočtových uzloch objavuje aj potreba L3 pluginu.
Agent L3 používa linuxové menné priestory na to, aby každému nájomcovi poskytol množinu vlastných izolovaných sietí a funkčnosť virtuálnych smerovačov, ktoré smerujú prevádzku a poskytujú služby brány pre siete vrstvy 2.
databázy — databázu identifikátorov sietí, podsietí, portov, fondov atď.
Neutron v skutočnosti prijíma požiadavky API od vytvorenia akýchkoľvek sieťových entít, autentifikuje požiadavku a prostredníctvom RPC (ak pristupuje k nejakému doplnku alebo agentovi) alebo REST API (ak komunikuje v SDN) odošle agentom (cez pluginy). pokyny potrebné na organizáciu požadovanej služby.
Teraz prejdime na testovaciu inštaláciu (ako je nasadená a čo je v nej zahrnuté, uvidíme neskôr v praktickej časti) a uvidíme, kde sa nachádzajú jednotlivé komponenty:
(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 ~]$
V skutočnosti je to celá štruktúra Neutrónu. Teraz sa oplatí venovať nejaký čas doplnku ML2.
Modulárna vrstva 2
Ako je uvedené vyššie, plugin je štandardný koreňový plugin OpenStack a má modulárnu architektúru.
Predchodca pluginu ML2 mal monolitickú štruktúru, ktorá neumožňovala napríklad použiť mix viacerých technológií v jednej inštalácii. Nemohli ste napríklad používať súčasne openvswitch aj linuxbridge – či už prvý alebo druhý. Z tohto dôvodu vznikol plugin ML2 s jeho architektúrou.
ML2 má dve zložky – dva typy ovládačov: ovládače typu a ovládače mechanizmu.
Typ ovládačov určiť technológie, ktoré sa použijú na organizáciu sieťových pripojení, napríklad VxLAN, VLAN, GRE. Vodič zároveň umožňuje použitie rôznych technológií. Štandardnou technológiou je zapuzdrenie VxLAN pre prekryvné siete a externé siete vlan.
Ovládače typov zahŕňajú nasledujúce typy sietí:
Byt - sieť bez označovania
VLAN - označená sieť
Miestne — špeciálny typ siete pre inštalácie typu všetko v jednom (takéto inštalácie sú potrebné buď pre vývojárov alebo na školenie)
GRE — prekryvná sieť využívajúca GRE tunely
VxLAN — prekryvná sieť využívajúca tunely VxLAN
Ovládače mechanizmov definovať nástroje, ktoré zabezpečujú organizáciu technológií uvedených v typovom ovládači - napríklad openvswitch, sr-iov, opendaylight, OVN atď.
V závislosti od implementácie tohto ovládača sa použijú buď agenti riadení Neutronom, alebo sa použijú pripojenia na externý SDN radič, ktorý sa stará o všetky záležitosti súvisiace s organizáciou L2 sietí, smerovaním atď.
Príklad: ak používame ML2 spolu s OVS, potom je na každom výpočtovom uzle, ktorý spravuje OVS, nainštalovaný agent L2. Ak však použijeme napríklad OVN alebo OpenDayLight, tak kontrola OVS patrí do ich kompetencie - Neutron cez root plugin dáva príkazy kontrolórovi a ten už robí, čo mu bolo povedané.
Oprášme Open vSwitch
V súčasnosti je jedným z kľúčových komponentov OpenStack Open vSwitch.
Pri inštalácii OpenStack bez akéhokoľvek dodatočného dodávateľa SDN, ako je Juniper Contrail alebo Nokia Nuage, je OVS hlavným sieťovým komponentom cloudovej siete a spolu s iptables, conntrack, mennými priestormi vám umožňuje organizovať plnohodnotné prekrývacie siete s viacerými nájomcami. Prirodzene, tento komponent je možné nahradiť napríklad pri použití SDN riešení tretích strán (dodávateľov).
OVS je open source softvérový prepínač, ktorý je navrhnutý na použitie vo virtualizovaných prostrediach ako virtuálny smerovač prevádzky.
Momentálne má OVS veľmi slušnú funkcionalitu, ktorá zahŕňa technológie ako QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK atď.
Poznámka: OVS nebol pôvodne koncipovaný ako mäkký prepínač pre vysoko zaťažené telekomunikačné funkcie a bol skôr navrhnutý pre IT funkcie, ktoré sú menej náročné na šírku pásma, ako je WEB server alebo poštový server. OVS sa však ďalej rozvíja a súčasné implementácie OVS výrazne zlepšili jeho výkon a možnosti, čo umožňuje jeho využitie aj telekomunikačným operátorom s vysoko zaťaženými funkciami, napríklad existuje implementácia OVS s podporou akcelerácie DPDK.
Existujú tri dôležité zložky OVS, o ktorých musíte vedieť:
- Modul jadra — komponent umiestnený v priestore jadra, ktorý spracováva prevádzku na základe pravidiel prijatých z riadiaceho prvku;
- vSwitch démon (ovs-vswitchd) je proces spustený v užívateľskom priestore, ktorý je zodpovedný za programovanie modulu jadra – to znamená, že priamo reprezentuje logiku činnosti prepínača
- Databázový server - lokálna databáza umiestnená na každom hostiteľovi s OVS, v ktorej je uložená konfigurácia. Prostredníctvom tohto modulu môžu SDN radiče komunikovať pomocou protokolu OVSDB.
To všetko sprevádza súbor diagnostických a riadiacich nástrojov, ako sú ovs-vsctl, ovs-appctl, ovs-ofctl atď.
Openstack je v súčasnosti široko používaný telekomunikačnými operátormi na migráciu sieťových funkcií naň ako EPC, SBC, HLR a pod. Niektoré funkcie môžu bez problémov žiť s OVS tak, ako je, ale napríklad EPC spracováva účastnícku prevádzku - potom prechádza cez obrovské množstvo prevádzky (v súčasnosti objemy prevádzky dosahujú niekoľko stoviek gigabitov za sekundu). Prirodzene, riadiť takú premávku cez priestor jadra (keďže tam sa preposielateľ štandardne nachádza) nie je najlepší nápad. Preto je OVS často nasadzovaný výhradne v užívateľskom priestore pomocou akceleračnej technológie DPDK na presmerovanie prevádzky z NIC do užívateľského priestoru, pričom sa obchádza jadro.
Poznámka: pre cloud nasadený pre telekomunikačné funkcie je možné odosielať prevádzku z výpočtového uzla obchádzajúcu OVS priamo do spínacieho zariadenia. Na tento účel sa používajú mechanizmy SR-IOV a Passthrough.
Ako to funguje na skutočnom rozložení?
No a teraz prejdime k praktickej časti a pozrime sa, ako to celé funguje v praxi.
Najprv nasadíme jednoduchú inštaláciu Openstacku. Keďže nemám po ruke sadu serverov na experimenty, prototyp zostavíme na jeden fyzický server z virtuálnych strojov. Áno, prirodzene, takéto riešenie nie je vhodné na komerčné účely, ale na ukážku fungovania siete v Openstacku stačí takáto inštalácia pre oči. Okrem toho je takáto inštalácia ešte zaujímavejšia na tréningové účely - pretože môžete zachytiť premávku atď.
Keďže potrebujeme vidieť iba základnú časť, nemôžeme použiť niekoľko sietí, ale všetko zdvihnúť iba pomocou dvoch sietí a druhá sieť v tomto rozložení bude slúžiť výlučne na prístup k undercloud a DNS serveru. Zatiaľ sa nebudeme dotýkať externých sietí - to je téma na samostatný veľký článok.
Začnime teda pekne po poriadku. Najprv trocha teórie. Openstack nainštalujeme pomocou TripleO (Openstack na Openstacku). Podstatou TripleO je, že Openstack nainštalujeme all-in-one (teda na jeden uzol), nazývaný undercloud a následne využijeme možnosti nasadeného Openstacku na inštaláciu Openstacku určeného na prevádzku, nazývaného overcloud. Undercloud využije svoju prirodzenú schopnosť spravovať fyzické servery (holé kovové) – projekt Ironic – na poskytovanie hypervízorov, ktoré budú vykonávať úlohy výpočtových, riadiacich a úložných uzlov. To znamená, že na nasadenie Openstacku nepoužívame žiadne nástroje tretích strán – Openstack nasadzujeme pomocou Openstacku. Postupom inštalácie to bude oveľa jasnejšie, takže sa tam nezastavíme a pohneme sa ďalej.
Poznámka: V tomto článku som pre jednoduchosť nepoužil izoláciu siete pre interné siete Openstack, ale všetko je nasadené iba pomocou jednej siete. Prítomnosť alebo absencia sieťovej izolácie však neovplyvňuje základnú funkcionalitu riešenia – všetko bude fungovať úplne rovnako ako pri použití izolácie, ale prevádzka bude prúdiť na rovnakej sieti. Pre komerčnú inštaláciu je prirodzene potrebné použiť izoláciu pomocou rôznych vlan a rozhraní. Napríklad prevádzka správy ceph storage a samotná dátová prevádzka (počítačový prístup k diskom atď.), keď sú izolované, používajú rôzne podsiete (Storage management a Storage) a to vám umožňuje urobiť riešenie odolnejšie voči chybám rozdelením tejto prevádzky, napr. , cez rôzne porty alebo pomocou rôznych profilov QoS pre rôznu prevádzku, aby dátová prevádzka nevytláčala signalizačnú prevádzku. V našom prípade pôjdu na rovnakú sieť a v podstate nás to nijako neobmedzuje.
Poznámka: Keďže virtuálne stroje budeme spúšťať vo virtuálnom prostredí založenom na virtuálnych strojoch, najprv musíme povoliť vnorenú virtualizáciu.
Či je vnorená virtualizácia povolená alebo nie, môžete skontrolovať takto:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Ak vidíte písmeno N, povoľujeme podporu pre vnorenú virtualizáciu podľa ľubovoľného návodu, ktorý nájdete v sieti, napr. .
Potrebujeme zostaviť nasledujúci okruh z virtuálnych strojov:
V mojom prípade som na pripojenie virtuálnych strojov, ktoré sú súčasťou budúcej inštalácie (a ja som ich dostal 7, ale vystačíte si so 4, ak nemáte veľa prostriedkov), použil OpenvSwitch. Vytvoril som jeden most ovs a pripojil som k nemu virtuálne stroje cez skupiny portov. Aby som to urobil, vytvoril som súbor xml, ako je tento:
[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>Sú tu deklarované tri skupiny portov - dve prístupové a jeden kmeň (druhý bol potrebný pre server DNS, ale môžete to urobiť aj bez neho alebo ho nainštalovať na hostiteľský počítač - podľa toho, čo je pre vás pohodlnejšie). Ďalej pomocou tejto šablóny deklarujeme naše prostredníctvom virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Teraz upravíme konfigurácie portov hypervízora:
[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 ~]# Poznámka: V tomto scenári adresa na porte ovs-br1 nebude prístupná, pretože nemá značku vlan. Ak to chcete opraviť, musíte zadať príkaz sudo ovs-vsctl set port ovs-br1 tag=100. Po reštarte však tento štítok zmizne (ak niekto vie, ako to urobiť, aby zostal na mieste, budem veľmi vďačný). To ale nie je až také dôležité, pretože túto adresu budeme potrebovať iba pri inštalácii a pri plnom nasadení Openstacku ju potrebovať nebudeme.
Ďalej vytvoríme podoblakový stroj:
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=ttyS0Počas inštalácie nastavíte všetky potrebné parametre, ako je názov stroja, heslá, používatelia, ntp servery atď., môžete okamžite nakonfigurovať porty, ale pre mňa osobne je po inštalácii jednoduchšie prihlásiť sa do stroja cez konzolu a opravte potrebné súbory. Ak už máte hotový obraz, môžete ho použiť, alebo urobte to, čo som urobil ja – stiahnite si minimálny obraz Centos 7 a použite ho na inštaláciu VM.
Po úspešnej inštalácii by ste mali mať virtuálny stroj, na ktorý si môžete undercloud nainštalovať
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningNajprv nainštalujte nástroje potrebné pre proces inštalácie:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Inštalácia pod mrakom
Vytvoríme používateľa zásobníka, nastavíme heslo, pridáme ho do sudoeru a dáme mu možnosť vykonávať príkazy root cez sudo bez toho, aby musel zadávať heslo:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackTeraz zadáme úplný názov podcloudu v súbore hosts:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Ďalej pridáme úložiská a nainštalujeme softvér, ktorý potrebujeme:
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-ansiblePoznámka: Ak neplánujete inštalovať ceph, nemusíte zadávať príkazy súvisiace s ceph. Použil som vydanie Queens, ale môžete použiť akékoľvek iné, ktoré sa vám páči.
Ďalej skopírujte konfiguračný súbor undercloud do zásobníka domovského adresára používateľa:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confTeraz musíme tento súbor opraviť a prispôsobiť ho našej inštalácii.
Na začiatok súboru musíte pridať tieto riadky:
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 = 10Poďme teda cez nastavenia:
undercloud_hostname — úplný názov servera pod cloudom sa musí zhodovať so záznamom na serveri DNS
local_ip — lokálna podcloudová adresa smerom k poskytovaniu siete
sieťová_brána — rovnaká lokálna adresa, ktorá bude fungovať ako brána pre prístup do vonkajšieho sveta počas inštalácie overcloud uzlov, sa tiež zhoduje s lokálnou IP
undercloud_public_host — externá adresa API, je priradená akákoľvek voľná adresa z poskytovania siete
undercloud_admin_host interná adresa API, je priradená akákoľvek voľná adresa z provizórnej siete
undercloud_nameservers — DNS server
vygenerovať_servisný_certifikát - tento riadok je v aktuálnom príklade veľmi dôležitý, pretože ak ho nenastavíte na hodnotu false, počas inštalácie sa zobrazí chyba, problém je popísaný v nástroji na sledovanie chýb Red Hat
lokálne_rozhranie rozhranie pri poskytovaní siete. Toto rozhranie sa prekonfiguruje počas nasadzovania v rámci cloudu, takže musíte mať v cloude dve rozhrania – jedno na prístup k nemu a druhé na poskytovanie
local_mtu - MTU. Keďže máme testovacie laboratórium a na portoch prepínača OVS mám MTU 1500, je potrebné nastaviť to na 1450, aby mohli prejsť pakety zapuzdrené vo VxLAN
network_cidr — zabezpečovacia sieť
maškaráda — pomocou NAT na prístup k externej sieti
masquerade_network - sieť, ktorá bude NATovaná
dhcp_start — začiatočná adresa oblasti adries, z ktorej budú adresy prideľované uzlom počas nasadenia overcloud
dhcp_end — konečná adresa oblasti adries, z ktorej budú adresy prideľované uzlom počas nasadenia overcloud
inšpekcia_iprange — súbor adries potrebných na introspekciu (nemal by sa prekrývať s vyššie uvedeným súborom)
scheduler_max_attempts — maximálny počet pokusov o inštaláciu overcloud (musí byť väčší alebo rovný počtu uzlov)
Po opísaní súboru môžete zadať príkaz na nasadenie podcloudu:
openstack undercloud install
Procedúra trvá od 10 do 30 minút v závislosti od vašej žehličky. Nakoniec by ste mali vidieť výstup takto:
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.
#############################################################################Tento výstup hovorí, že ste úspešne nainštalovali undercloud a teraz môžete skontrolovať stav undercloud a pokračovať v inštalácii overcloud.
Ak sa pozriete na výstup ifconfig, uvidíte, že sa objavilo nové rozhranie mosta
[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 0Nasadenie overcloud sa teraz bude vykonávať cez toto rozhranie.
Z výstupu nižšie môžete vidieť, že máme všetky služby na jednom uzle:
(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 |
+--------------------------+-----------+----------+Nižšie je uvedená konfigurácia časti siete pod cloudom:
(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 inštalácia
Momentálne máme iba undercloud a nemáme dostatok uzlov, z ktorých sa bude overcloud zostavovať. Preto najprv nasaďte virtuálne stroje, ktoré potrebujeme. Počas nasadenia si sám undercloud nainštaluje OS a potrebný softvér na overcloud stroj - to znamená, že stroj nemusíme kompletne nasadiť, ale len mu vytvoríme disk (alebo disky) a určíme jeho parametre - tzn. v skutočnosti získame holý server bez nainštalovaného operačného systému.
Poďme do priečinka s diskami našich virtuálnych strojov a vytvorte disky požadovanej veľkosti:
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 160GKeďže pracujeme ako root, musíme zmeniť vlastníka týchto diskov, aby sme nenastali problém s právami:
[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]# Poznámka: ak neplánujete nainštalovať ceph, aby ste ho mohli študovať, potom príkazy nevytvoria aspoň 3 uzly s aspoň dvoma diskami, ale v šablóne naznačujú, že sa použijú virtuálne disky vda, vdb atď.
Skvelé, teraz musíme definovať všetky tieto stroje:
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 Na konci je príkaz -print-xml > /tmp/storage-1.xml, ktorý vytvorí xml súbor s popisom každého stroja v priečinku /tmp/, ak ho nepridáte, nebudete schopný identifikovať virtuálne stroje.
Teraz musíme definovať všetky tieto stroje vo 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 ~]#Teraz malá nuansa - tripleO používa IPMI na správu serverov počas inštalácie a introspekcie.
Introspekcia je proces kontroly hardvéru s cieľom získať jeho parametre potrebné pre ďalšie poskytovanie uzlov. Introspekcia sa vykonáva pomocou ironickej, služby určenej na prácu s holými kovovými servermi.
Ale tu je problém - zatiaľ čo hardvérové servery IPMI majú samostatný port (alebo zdieľaný port, ale to nie je dôležité), virtuálne stroje takéto porty nemajú. Tu nám prichádza na pomoc barlička s názvom vbmc – nástroj, ktorý vám umožňuje emulovať port IPMI. Táto nuansa stojí za to venovať pozornosť najmä tým, ktorí chcú nastaviť takéto laboratórium na hypervízore ESXI - aby som bol úprimný, neviem, či má analóg vbmc, takže pred nasadením všetkého stojí za to sa nad týmto problémom zamyslieť. .
Nainštalujte vbmc:
yum install yum install python2-virtualbmcAk váš operačný systém nemôže nájsť balík, pridajte úložisko:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmTeraz nastavíme utilitu. Všetko je tu banálne až hanba. Teraz je logické, že v zozname vbmc nie sú žiadne servery
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Aby sa zobrazili, musia byť manuálne deklarované takto:
[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 ~]#Myslím, že syntax príkazu je jasná bez vysvetlenia. Zatiaľ sú však všetky naše relácie v stave DOWN. Aby mohli prejsť do stavu UP, musíte ich povoliť:
[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 ~]#A posledný dotyk - musíte opraviť pravidlá brány firewall (alebo ich úplne zakázať):
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
Teraz poďme do podmraku a skontrolujte, či všetko funguje. Adresa hostiteľského počítača je 192.168.255.200, na undercloud sme pridali potrebný balík ipmitool počas prípravy na nasadenie:
[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 runningAko vidíte, úspešne sme spustili riadiaci uzol cez vbmc. Teraz to vypneme a ideme ďalej:
[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 ~]#Ďalším krokom je introspekcia uzlov, na ktorých bude nainštalovaný overcloud. Aby sme to urobili, musíme pripraviť súbor json s popisom našich uzlov. Upozorňujeme, že na rozdiel od inštalácie na holé servery súbor označuje port, na ktorom beží vbmc pre každý počítač.
[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:27Poznámka: riadiaci uzol má dve rozhrania, ale v tomto prípade to nie je dôležité, v tejto inštalácii nám bude stačiť jedno.
Teraz pripravíme súbor json. Musíme uviesť makovú adresu portu, cez ktorý sa bude vykonávať poskytovanie, parametre uzlov, dať im mená a uviesť, ako sa dostať do 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"
}
]
}Teraz musíme pripraviť obrázky na iróniu. Ak to chcete urobiť, stiahnite si ich cez wget a nainštalujte:
(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 ~]$Nahrávanie obrázkov do cloudu:
(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 ~]$Kontrola, či sa načítali všetky obrázky
(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 ~]$Ešte jedna vec - musíte pridať server DNS:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Teraz môžeme dať príkaz na introspekciu:
(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 ~]$Ako môžete vidieť z výstupu, všetko prebehlo bez chýb. Skontrolujeme, či sú všetky uzly v dostupnom stave:
(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 ~]$ Ak sú uzly v inom, zvyčajne zvládnuteľnom stave, potom sa niečo pokazilo a musíte sa pozrieť na protokol a zistiť, prečo sa to stalo. Majte na pamäti, že v tomto scenári používame virtualizáciu a môžu sa vyskytnúť chyby spojené s používaním virtuálnych strojov alebo vbmc.
Ďalej musíme uviesť, ktorý uzol bude vykonávať ktorú funkciu - to znamená, uviesť profil, s ktorým sa uzol nasadí:
(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 ~]$Zadajte profil pre každý uzol:
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-d9afb69d1167Skontrolujte, či sme urobili všetko správne:
(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 ~]$Ak je všetko správne, dáme príkaz na nasadenie 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 qemuV reálnej inštalácii sa prirodzene použijú prispôsobené šablóny, v našom prípade to značne skomplikuje proces, pretože každú úpravu v šablóne bude potrebné vysvetliť. Ako už bolo napísané, aj jednoduchá inštalácia nám postačí, aby sme videli, ako to funguje.
Poznámka: premenná qemu typu --libvirt je v tomto prípade potrebná, pretože budeme používať vnorenú virtualizáciu. V opačnom prípade nebudete môcť spúšťať virtuálne stroje.
Teraz máte asi hodinu alebo možno viac (v závislosti od možností hardvéru) a môžete len dúfať, že po tomto čase uvidíte nasledujúcu správu:
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 ~]$Teraz máte takmer plnohodnotnú verziu openstacku, na ktorej môžete študovať, experimentovať atď.
Skontrolujeme, či všetko funguje správne. V zásobníku domovského adresára používateľa sa nachádzajú dva súbory – jeden stackrc (na správu podcloudu) a druhý overcloudrc (na spravovanie zakrytia). Tieto súbory musia byť špecifikované ako zdroj, pretože obsahujú informácie potrebné na overenie.
(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 ~]$Moja inštalácia stále vyžaduje jeden malý dotyk - pridanie trasy na ovládači, pretože stroj, s ktorým pracujem, je v inej sieti. Ak to chcete urobiť, prejdite na control-1 pod účtom heat-admin a zaregistrujte trasu
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Teraz môžete ísť do horizontu. Všetky informácie - adresy, prihlasovacie meno a heslo - sú v súbore /home/stack/overcloudrc. Konečný diagram vyzerá takto:
Mimochodom, v našej inštalácii boli adresy strojov vydávané cez DHCP a ako vidíte, sú vydávané „náhodne“. V šablóne môžete presne definovať, ktorá adresa má byť pri nasadzovaní pripojená ku ktorému stroju, ak to potrebujete.
Ako prebieha prevádzka medzi virtuálnymi strojmi?
V tomto článku sa pozrieme na tri možnosti prejazdu
- Dva stroje na jednom hypervízore na jednej L2 sieti
- Dva stroje na rôznych hypervízoroch v rovnakej sieti L2
- Dva počítače v rôznych sieťach (rootovanie medzi sieťami)
Prípady s prístupom do vonkajšieho sveta cez externú sieť, pomocou plávajúcich adries, ako aj distribuovaného smerovania zvážime nabudúce, zatiaľ sa zameriame na internú komunikáciu.
Pre kontrolu zostavme nasledujúci diagram:
Vytvorili sme 4 virtuálne stroje - 3 v jednej L2 sieti - net-1 a 1 ďalší v sieti 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 ~]$ Pozrime sa, na akých hypervízoroch sú vytvorené stroje umiestnené:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(overcloud) [stack@undercloud ~]$
Stroje vm-1 a vm-3 sú umiestnené na compute-0, stroje vm-2 a vm-4 sú umiestnené na uzle compute-1.
Okrem toho bol vytvorený virtuálny smerovač, ktorý umožňuje smerovanie medzi špecifikovanými sieťami:
(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 ~]$ Smerovač má dva virtuálne porty, ktoré fungujú ako brány pre siete:
(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 ~]$ Ale predtým, než sa pozrieme na to, ako tok dopravy, pozrime sa, čo aktuálne máme na riadiacom uzle (ktorý je zároveň sieťovým uzlom) a na výpočtovom uzle. Začnime s výpočtovým uzlom.
[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 ~]$Momentálne má uzol tri ovs mosty - br-int, br-tun, br-ex. Ako vidíme, medzi nimi je súbor rozhraní. Pre uľahčenie pochopenia nakreslíme všetky tieto rozhrania do diagramu a uvidíme, čo sa stane.
Pri pohľade na adresy, na ktoré sa vytvoria tunely VxLAN, je možné vidieť, že jeden tunel je povýšený na compute-1 (192.168.255.26), druhý tunel vyzerá na kontrolu-1 (192.168.255.15). Najzaujímavejšie však je, že br-ex nemá fyzické rozhrania a ak sa pozriete na to, aké toky sú nakonfigurované, môžete vidieť, že tento most môže v súčasnosti iba znížiť návštevnosť.
[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 ~]$ Ako môžete vidieť z výstupu, adresa je priskrutkovaná priamo na fyzický port a nie na rozhranie virtuálneho mosta.
[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 ~]$
Podľa prvého pravidla treba zlikvidovať všetko, čo prišlo z phy-br-ex portu.
V skutočnosti momentálne nie je nikde inde, aby na tento most prichádzala premávka okrem tohto rozhrania (rozhranie s br-int) a súdiac podľa poklesov, premávka BUM už do mosta vletela.
To znamená, že prevádzka môže opustiť tento uzol iba cez tunel VxLAN a nič iné. Ak však DVR zapnete, situácia sa zmení, ale tomu sa budeme venovať inokedy. Pri použití izolácie siete, napríklad pomocou vlan, nebudete mať vo vlan 3 jedno rozhranie L0, ale niekoľko rozhraní. Prevádzka VxLAN však bude opúšťať uzol rovnakým spôsobom, ale tiež zapuzdrená v akejsi vyhradenej vlan.
Vytriedili sme výpočtový uzol, prejdime k riadiacemu uzlu.
[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 ~]$V skutočnosti môžeme povedať, že všetko je rovnaké, ale IP adresa už nie je na fyzickom rozhraní, ale na virtuálnom moste. Je to spôsobené tým, že tento port je portom, cez ktorý bude prevádzka vychádzať do vonkajšieho sveta.
[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 ~]$ Tento port je prepojený s mostom br-ex a keďže na ňom nie sú žiadne značky vlan, tento port je kmeňovým portom, na ktorom sú povolené všetky siete vlan, teraz prevádzka ide von bez značky, ako naznačuje vlan-id 0 v výstup vyššie.
Všetko ostatné je v súčasnosti podobné ako pri výpočtovom uzle – rovnaké mosty, rovnaké tunely vedúce do dvoch výpočtových uzlov.
V tomto článku nebudeme uvažovať o úložných uzloch, ale pre pochopenie je potrebné povedať, že sieťová časť týchto uzlov je banálna až hanba. V našom prípade existuje iba jeden fyzický port (eth0) s priradenou IP adresou a to je všetko. Neexistujú žiadne tunely VxLAN, tunelové mosty atď. - neexistujú vôbec žiadne OV, pretože to nemá zmysel. Pri použití sieťovej izolácie bude mať tento uzol dve rozhrania (fyzické porty, bodny, alebo len dva vlany - to je jedno - záleží na tom, čo chcete) - jedno pre správu, druhé pre prevádzku (zápis na disk VM , čítanie z disku atď.)
Zistili sme, čo máme na uzloch pri absencii akýchkoľvek služieb. Teraz spustíme 4 virtuálne stroje a uvidíme, ako sa zmení schéma opísaná vyššie - mali by sme mať porty, virtuálne smerovače atď.
Naša sieť zatiaľ vyzerá takto:
Na každom uzle počítača máme dva virtuálne stroje. Pomocou compute-0 ako príkladu sa pozrime, ako je všetko zahrnuté.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Stroj má iba jedno virtuálne rozhranie - 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 ~]$
Toto rozhranie vyzerá v linuxovom moste:
[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 ~]$ Ako môžete vidieť z výstupu, v moste sú iba dve rozhrania - tap95d96a75-a0 a qvb95d96a75-a0.
Tu stojí za to sa trochu pozastaviť nad typmi virtuálnych sieťových zariadení v OpenStack:
vtap - virtuálne rozhranie pripojené k inštancii (VM)
qbr - Linuxový most
qvb a qvo - pár vEth pripojený k mostu Linux a mostu Open vSwitch
br-int, br-tun, br-vlan — Otvorte mosty vSwitch
patch-, int-br-, phy-br- - Otvorené vSwitch patch rozhrania spájajúce mosty
qg, qr, ha, fg, sg – Otvorené porty vSwitch používané virtuálnymi zariadeniami na pripojenie k OVS
Ako ste pochopili, ak máme v moste port qvb95d96a75-a0, čo je pár vEth, potom niekde existuje jeho náprotivok, ktorý by sa mal logicky volať qvo95d96a75-a0. Pozrime sa, aké porty sú na 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 ~]$ Ako vidíme, prístav je v br-int. Br-int funguje ako prepínač, ktorý ukončuje porty virtuálnych strojov. Okrem qvo95d96a75-a0 je vo výstupe viditeľný port qvo5bd37136-47. Toto je port na druhý virtuálny stroj. Výsledkom je, že náš diagram teraz vyzerá takto:
Otázka, ktorá by mala okamžite zaujať pozorného čitateľa – aký je linuxový most medzi portom virtuálneho stroja a portom OVS? Faktom je, že na ochranu stroja sa používajú bezpečnostné skupiny, ktoré nie sú ničím iným ako iptables. OVS nepracuje s iptables, preto bola vynájdená táto „barla“. Stáva sa však zastaraným – v nových vydaniach ho nahrádza conntrack.
To znamená, že schéma nakoniec vyzerá takto:
Dva stroje na jednom hypervízore na jednej L2 sieti
Keďže tieto dva VM sú umiestnené v rovnakej sieti L2 a na rovnakom hypervízore, prevádzka medzi nimi bude logicky prúdiť lokálne cez br-int, keďže oba stroje budú na rovnakej 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 ~]$ Dva stroje na rôznych hypervízoroch v rovnakej sieti L2
Teraz sa pozrime, ako bude prebiehať prevádzka medzi dvoma strojmi v rovnakej sieti L2, ale umiestnených na rôznych hypervízoroch. Úprimne povedané, nič sa veľmi nezmení, akurát premávka medzi hypervízormi pôjde cez tunel vxlan. Pozrime sa na príklad.
Adresy virtuálnych strojov, medzi ktorými budeme sledovať prevádzku:
[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 ~]$ Pozeráme sa na tabuľku presmerovania v br-int na compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Prevádzka by mala smerovať na port 2 – pozrime sa, o aký druh portu ide:
[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 ~]$Toto je patch-tun - teda rozhranie v br-tune. Pozrime sa, čo sa stane s balíkom na br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Paket je zabalený vo VxLAN a odoslaný na port 2. Pozrime sa, kam vedie port 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Toto je tunel vxlan na 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 ~]$Poďme na compute-1 a uvidíme, čo sa stane ďalej s balíkom:
[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 je v tabuľke presmerovania br-int na compute-1 a ako je vidieť z vyššie uvedeného výstupu, je viditeľný cez port 2, čo je port smerom k 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:46Potom vidíme, že v br-int na compute-1 je cieľový mak:
[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 ~]$ To znamená, že prijatý paket poletí na port 3, za ktorým sa už nachádza inštancia virtuálneho počítača-00000003.
Krása nasadenia Openstacku na učenie sa vo virtuálnej infraštruktúre je v tom, že môžeme jednoducho zachytiť prevádzku medzi hypervízormi a zistiť, čo sa s ňou deje. To je to, čo teraz urobíme, spustíme tcpdump na porte vnet smerom k 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*******************Prvý riadok ukazuje, že Patek z adresy 10.0.1.85 ide na adresu 10.0.1.88 (ICMP prenos) a je zabalený do paketu VxLAN s vni 22 a paket ide z hostiteľa 192.168.255.19 (výpočet-0) na hostiteľa 192.168.255.26 .1 (výpočet-XNUMX). Môžeme skontrolovať, či sa VNI zhoduje s údajom uvedeným v ovs.
Vráťme sa na tento riadok actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 je vni v hexadecimálnej číselnej sústave. Preveďme toto číslo na desiatu sústavu:
16 = 6*16^0+1*16^1 = 6+16 = 22To znamená, že vni zodpovedá realite.
Druhý riadok ukazuje spiatočnú dopravu, no, nemá zmysel to vysvetľovať, tam je všetko jasné.
Dva stroje v rôznych sieťach (smerovanie medzi sieťami)
Posledným prípadom pre dnešok je smerovanie medzi sieťami v rámci jedného projektu pomocou virtuálneho smerovača. Uvažujeme o prípade bez DVR (pozrieme sa na to v inom článku), takže smerovanie nastáva na uzle siete. V našom prípade sieťový uzol nie je umiestnený v samostatnej entite a nachádza sa na riadiacom uzle.
Najprv sa pozrime, že smerovanie funguje:
$ 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 msKeďže v tomto prípade musí paket smerovať na bránu a tam byť smerovaný, musíme zistiť MAC adresu brány, pre ktorú sa pozrieme do tabuľky ARP v inštancii:
$ 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 eth0Teraz sa pozrime, kam by mala byť odoslaná prevádzka s cieľom (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 ~]$ Pozrime sa, kam vedie port 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Všetko je logické, premávka ide na br-tun. Pozrime sa, do ktorého tunela vxlan bude zabalený:
[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 ~]$ Tretím portom je tunel vxlan:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Ktorý sa pozerá na riadiaci uzol:
[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 ~]$ Premávka sa dostala do riadiaceho uzla, takže k nemu musíme ísť a zistiť, ako dôjde k smerovaniu.
Ako si pamätáte, riadiaci uzol vo vnútri vyzeral úplne rovnako ako výpočtový uzol – rovnaké tri mosty, len br-ex mal fyzický port, cez ktorý mohol uzol posielať prevádzku von. Vytvorením inštancií sa zmenila konfigurácia na výpočtových uzloch - do uzlov pribudol linuxový most, iptables a rozhrania. Na konfigurácii riadiaceho uzla sa podpísalo aj vytvorenie sietí a virtuálneho smerovača.
Je teda zrejmé, že MAC adresa brány musí byť v tabuľke presmerovania br-int na riadiacom uzle. Skontrolujme, či tam je a kde sa pozerá:
[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 je viditeľný z portu qr-0c52b15f-8f. Ak sa vrátime k zoznamu virtuálnych portov v Openstacku, tento typ portu slúži na pripojenie rôznych virtuálnych zariadení k OVS. Presnejšie povedané, qr je port k virtuálnemu smerovaču, ktorý je reprezentovaný ako menný priestor.
Pozrime sa, aké menné priestory sú na serveri:
[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 ~]$ Až tri kópie. Ale podľa názvov môžete uhádnuť účel každého z nich. K inštanciám s ID 0 a 1 sa vrátime neskôr, teraz nás zaujíma menný priestor 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 ~]$ Tento priestor názvov obsahuje dva interné, ktoré sme vytvorili skôr. Oba virtuálne porty boli pridané do br-int. Pozrime sa na mac adresu portu qr-0c52b15f-8f, pretože prevádzka, súdiac podľa cieľovej mac adresy, smerovala na toto rozhranie.
[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 ~]$ To znamená, že v tomto prípade všetko funguje podľa zákonov štandardného smerovania. Keďže prevádzka je určená pre hostiteľa 10.0.2.8, musí opustiť druhé rozhranie qr-92fa49b5-54 a prejsť tunelom vxlan do výpočtového uzla:
[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 ~]$ Všetko je logické, žiadne prekvapenia. Pozrime sa, kde je viditeľná maková adresa hostiteľa 10.0.2.8 v br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Ako sa očakávalo, premávka smeruje do br-tun, pozrime sa, do ktorého tunela smeruje doprava:
[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 ~]$ Premávka ide do tunela na výpočet-1. No, na compute-1 je všetko jednoduché - z br-tun balík ide do br-int a odtiaľ do rozhrania virtuálneho počítača:
[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 ~]$ Skontrolujte, či je toto skutočne správne rozhranie:
[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 ~]$
Vlastne sme prešli celý balík. Myslím, že ste si všimli, že premávka prechádzala rôznymi tunelmi vxlan a vystupovala s rôznymi VNI. Pozrime sa, aké sú to VNI, po ktorých zhromaždíme výpis na riadiacom porte uzla a uistíme sa, že prevádzka tečie presne tak, ako je opísané vyššie.
Tunel na výpočet-0 má teda nasledujúce akcie=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],výstup:3. Prevedieme 0x16 na desiatkovú číselnú sústavu:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunel na výpočet-1 má nasledovné VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Prevedieme 0x63 na desiatkovú číselnú sústavu:
0x63 = 3*16^0+6*16^1 = 3+96 = 99No a teraz sa pozrime na skládku:
[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*******************Prvý paket je paket vxlan z hostiteľa 192.168.255.19 (výpočet-0) do hostiteľa 192.168.255.15 (kontrola-1) s vni 22, v ktorom je paket ICMP zabalený z hostiteľa 10.0.1.85 do hostiteľa 10.0.2.8. Ako sme vypočítali vyššie, vni zodpovedá tomu, čo sme videli vo výstupe.
Druhý paket je paket vxlan z hostiteľa 192.168.255.15 (riadiaci prvok-1) do hostiteľa 192.168.255.26 (výpočet-1) s vni 99, vo vnútri ktorého je paket ICMP zabalený z hostiteľa 10.0.1.85 do hostiteľa 10.0.2.8. Ako sme vypočítali vyššie, vni zodpovedá tomu, čo sme videli vo výstupe.
Nasledujúce dva pakety sú spätnou prevádzkou z 10.0.2.8, nie z 10.0.1.85.
To znamená, že nakoniec sme dostali nasledujúcu schému riadiaceho uzla:
Vyzerá to tak? Zabudli sme na dva menné priestory:
[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 ~]$ Keď sme hovorili o architektúre cloudovej platformy, bolo by dobré, keby stroje dostávali adresy automaticky z DHCP servera. Toto sú dva servery DHCP pre naše dve siete 10.0.1.0/24 a 10.0.2.0/24.
Overme si, či je to pravda. V tomto priestore názvov je iba jedna adresa - 10.0.1.1 - adresa samotného servera DHCP a je tiež zahrnutá v 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 0Pozrime sa, či procesy obsahujúce qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 vo svojom názve na riadiacom uzle:
[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 ~]$ Existuje taký proces a na základe informácií uvedených vo výstupe vyššie môžeme napríklad vidieť, čo máme momentálne na prenájom:
[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 ~]$Výsledkom je, že v riadiacom uzle získame nasledujúcu množinu služieb:
No, majte na pamäti - toto sú len 4 stroje, 2 interné siete a jeden virtuálny router... Teraz tu nemáme externé siete, kopu rôznych projektov, každý s vlastnými sieťami (prekrývajúce sa) a máme distribuovaný smerovač sa vypol a nakoniec V testovacej stolici bol predsa len jeden riadiaci uzol (pre odolnosť proti chybám musí byť kvórum troch uzlov). Je logické, že v komercii je všetko „trochu“ zložitejšie, ale na tomto jednoduchom príklade chápeme, ako by to malo fungovať – či máte 3 alebo 300 menných priestorov je samozrejme dôležité, no z hľadiska fungovania celú štruktúru, nič sa veľmi nezmení... aj keď nepripojíte niektoré SDN dodávateľa. Ale to je úplne iný príbeh.
Dúfam, že to bolo zaujímavé. Ak máte nejaké pripomienky/doplnenia, alebo som niekde priamo klamal (som človek a môj názor bude vždy subjektívny) - napíšte, čo treba opraviť/doplniť - všetko opravíme/doplníme.
Na záver by som chcel povedať pár slov o porovnaní Openstacku (vanilky aj predajcu) s cloudovým riešením od VMWare – túto otázku som dostával príliš často za posledných pár rokov a úprimne povedané, už je z toho unavený, ale predsa. Podľa môjho názoru je veľmi ťažké porovnávať tieto dve riešenia, ale určite môžeme povedať, že obe riešenia majú svoje nevýhody a pri výbere jedného riešenia je potrebné zvážiť pre a proti.
Ak je OpenStack komunitou riadené riešenie, tak má VMWare právo robiť si len to, čo chce (čítaj - čo je pre neho ziskové) a je to logické - pretože ide o komerčnú spoločnosť, ktorá je zvyknutá zarábať na svojich klientoch. Je tu však jedno veľké a tučné ALE - môžete vystúpiť z OpenStacku, napríklad od Nokie, a s malými nákladmi prejsť na riešenie napríklad od Juniper (Contrail Cloud), ale je nepravdepodobné, že by ste mohli vystúpiť z VMWare. . U mna tieto dve riesenia vyzeraju takto - Openstack (vendor) je jednoducha klietka, do ktorej vas nasadia, ale mate kluc a mozete kedykolvek odist. VMWare je zlatá klietka, kľúč od klietky má majiteľ a bude vás to stáť veľa.
Nepropagujem ani prvý produkt, ani druhý - vy si vyberiete, čo potrebujete. Ale ak by som mal takú možnosť, vybral by som si obe riešenia - VMWare pre IT cloud (nízka záťaž, jednoduchá správa), OpenStack od nejakého dodávateľa (Nokia a Juniper poskytujú veľmi dobré riešenia na kľúč) - pre Telecom cloud. Openstack by som nepoužil na čisté IT – je to ako strieľať vrabce kanónom, ale nevidím žiadne kontraindikácie jeho používania okrem redundancie. Používanie VMWare v telekomunikáciách je však ako ťahanie drveného kameňa vo Forde Raptor – je to krásne zvonku, ale vodič musí namiesto jednej urobiť 10 jázd.
Najväčšou nevýhodou VMWare je podľa mňa úplná uzavretosť – firma vám nedá žiadne informácie o tom, ako funguje napríklad vSAN alebo čo je v jadre hypervízora – jednoducho to pre ňu nie je rentabilné – teda budete nikdy sa nestaňte odborníkom na VMWare – bez podpory predajcu ste odsúdení na zánik (veľmi často sa stretávam s odborníkmi na VMWare, ktorí sú zmätení triviálnymi otázkami). Pre mňa VMWare kupuje auto so zamknutou kapotou - áno, možno máte špecialistov, ktorí vedia vymeniť rozvodový remeň, ale kapotu vie otvoriť len ten, kto vám toto riešenie predal. Osobne nemám rád riešenia, do ktorých sa neviem zmestiť. Poviete si, že pod kapotu už snáď nemusíte. Áno, je to možné, ale pozriem sa na vás, keď budete potrebovať poskladať veľkú funkciu v cloude z 20-30 virtuálnych strojov, 40-50 sietí, z ktorých polovica chce ísť von a druhá polovica žiada Zrýchlenie SR-IOV, inak budete potrebovať ďalších pár desiatok týchto áut – inak vám výkon nebude stačiť.
Existujú aj iné uhly pohľadu, takže len vy sa môžete rozhodnúť, čo si vybrať a hlavne potom budete za svoj výber zodpovedať. Toto je len môj názor - človeka, ktorý videl a ohmatal aspoň 4 produkty - Nokia, Juniper, Red Hat a VMWare. Teda mám s čím porovnávať.
Zdroj: hab.com