Cloud computing is increasingly penetrating our lives, and there is probably no one who hasn't used any cloud services at least once. However, what exactly is the cloud and how does it work? Most people are only familiar with the concept at a basic level. 5G is becoming a reality, and telecom infrastructure is starting to shift from traditional solutions to cloud-based ones, just as it once transitioned from entirely hardware solutions to virtualized 'poles'.
Today, we will discuss the internal world of cloud infrastructure, specifically examining the basics of the network component.
What is the cloud? Is it just virtualization viewed from another angle?
A very logical question. No, it is not virtualization, although it is involved. Let's consider two definitions:
Cloud computing (hereafter referred to as the Cloud) is a model for providing convenient user access to distributed computing resources that must be deployed and activated on demand with minimal possible delay and minimal costs from the service provider.
Virtualizácia is the ability to divide one physical entity (for example, a server) into several virtual ones, thus increasing resource utilization (for instance, if you had 3 servers loaded at 25-30 percent, after virtualization you end up with 1 server loaded at 80-90 percent). Naturally, virtualization consumes some resources—you need to support the hypervisor; however, as practice shows, it's worth it. An ideal example of virtualization is VMWare, which excellently prepares virtual machines, or KVM, which I personally prefer, but that's a matter of taste.
We use virtualization without even realizing it; even hardware routers already use virtualization— for example, in the latest versions of JunOS, the operating system is installed as a virtual machine on top of a real-time Linux distribution (Wind River 9). But virtualization is not the cloud; however, the cloud cannot exist without virtualization.
Virtualization is one of the building blocks on which the cloud is constructed.
Vytvoriť cloud jednoducho spojením niekoľkých hypervízorov do jedného L2 doménového priestoru, pridaním niekoľkých yaml skriptov na automatické nastavovanie VLAN cez nejaký Ansible a nasadiť na to niečo ako systém orchestrácie na automatické vytváranie virtuálnych strojov — nebude možné. Presnejšie povedané, bude to možné, ale získaný Frankenstein — nie je ten cloud, ktorý potrebujeme, hoci pre niekoho to môže byť sen. Okrem toho, ak vezmeme ten istý OpenStack — v podstate je to tiež ešte jeden Frankenstein, ale dobre, o tom zatiaľ nebudeme hovoriť.
Ale rozumiem, že z predstaveného vyššieho vyjadrenia nie je úplne jasné, čo vlastne môžeme nazvať cloudom.
Preto v dokumente od NIST (National Institute of Standards and Technology) uvádzajú 5 hlavných charakteristík, ktorými by mala disponovať cloudová infraštruktúra:
Poskytovanie služby na požiadanie. Používateľovi musí byť poskytnutý voľný prístup k prideleným počítačovým zdrojom (ako sú siete, virtuálne disky, pamäť, procesorové jadrá a pod.), pričom tieto zdroje by mali byť poskytované automaticky — teda bez zásahu zo strany poskytovateľa služieb.
Široká dostupnosť služby. Prístup k zdrojom by mal byť zabezpečený prostredníctvom štandardných mechanizmov, aby bolo možné používať ako štandardné PC, tak aj tenké klienty a mobilné zariadenia.
Zlúčenie zdrojov do púl. Púly zdrojov by mali zabezpečiť súčasné poskytovanie zdrojov viacerým klientom, pričom zabezpečia izoláciu klientov a absenciu vzájomného ovplyvňovania medzi nimi a konkurenciu o zdroje. Do púl sú zahrnuté aj siete, čo hovorí o možnosti použitia prekrývajúcej sa adresácie. Púly by mali podporovať škálovanie na požiadanie. Použitie púlov umožňuje zabezpečiť potrebnú úroveň odolnosti voči chybám a abstrahovanie fyzických a virtuálnych zdrojov — príjemca služby jednoducho získa požadovaný set zdrojov (kde sú tieto zdroje fyzicky umiestnené, na koľkých serveroch a prepínačoch — klientovi na tom nezáleží). Je však treba zohľadniť fakt, ž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 presúvanie, pridávanie alebo znižovanie na požiadanie zákazníka, pričom zákazník by mal mať pocit, že zdroje cloudu sú nekonečné. Na ilustráciu, napríklad nevidíte upozornenie, že vám v Apple iCloud chýba časť úložiska, pretože sa na serveri pokazil pevný disk, a disky sa predsa kazia. Navyše z vašej strany sú možnosti tohto servisu prakticky neobmedzené – potrebujete 2 TB – niet problém, zaplatíte a dostanete. Podobne môžeme uviesť príklad s Google.Drive alebo Yandex.Disk.
Možnosť merania poskytovanej služby. Cloudové systémy by mali automaticky sledovať a optimalizovať spotrebovávané zdroje, pričom tieto mechanizmy by mali byť transparentné pre používateľa i poskytovateľa služieb. Teda, vždy môžete skontrolovať, koľko zdrojov vy a vaši zákazníci spotrebovávate.
Je treba zohľadniť fakt, že tieto požiadavky sú väčšinou požiadavkami na verejný cloud, takže pre súkromný cloud (teda cloud spustený pre interné potreby spoločnosti) môžu byť tieto požiadavky niekoľko upravené. Avšak mali by byť stále splnené, inak nedosiahnueme všetky výhody cloudového výpočtu.
Prečo potrebujeme cloud?
Avšak akákoľvek nová alebo už existujúca technológia, akýkoľvek nový protokol sa vytvára za nejakým účelom (no okrem RIP-ng samozrejme). Protivín pre protokoly – nikomu nie je potrebný (no okrem RIP-ng samozrejme). Je logické, že Cloud sa vytvára, aby poskytol nejakú službu používateľovi/zákazníkovi. Všetci poznáme aspoň pár cloudových služieb, ako Dropbox alebo Google.Docs a predpokladám, že väčšina úspešne používa – napríklad tento článok bol napísaný s využitím cloudovej služby Google.Docs. No známe cloudové služby sú len časťou možností cloudu – presnejšie je to len služba typu SaaS. Poskytovať cloudovú službu môžeme tromi spôsobmi: ako SaaS, PaaS alebo IaaS. Akú službu potrebujete, závisí od vašich želaní a možností.
Pozrime sa na každý poriadku:
Software as a Service (SaaS) — je model poskytovania úplnej služby klientovi, napríklad e-mailová služba ako Yandex.Mail alebo Gmail. V tomto modeli poskytovania služby vy, ako klient, v podstate nerobíte nič iné, len využívate službu — to znamená, že sa nemusíte zaoberať nastavením služby, jej odolnosťou voči poruchám alebo zálohovaním. Hlavné je, aby ste nekompromitovali svoje heslo, všetko ostatné za vás zabezpečí poskytovateľ tejto služby. Z pohľadu poskytovateľa služby je on plne zodpovedný za celú službu — počnúc serverovým hardvérom a hosťovacími operačnými systémami, až po nastavenia databáz a softvéru.
Platform as a Service (PaaS) — pri použití tohto modelu dodávateľ služieb poskytuje klientovi základ pre službu, napríklad si vezmite webový server. Dodávateľ služieb poskytol klientovi virtuálny server (v podstate súbor zdrojov, ako RAM/CPU/Úložisko/Siete a pod.), a dokonca nainštaloval na tento server OS a potrebný softvér, avšak nastavenie všetkého tohto vykonáva sám klient a za funkčnosť služby už zodpovedá klient. Dodávateľ služieb, ako v predchádzajúcom prípade, zodpovedá za funkčnosť fyzického hardvéru, hypervízorov, samotnej virtuálnej mašiny, jej sieťovú dostupnosť a pod., avšak samotná služba už nie je v jeho kompetencii.
Infrastructure as a Service (IaaS) — tento prístup je už zaujímavejší, v podstate dodávateľ služieb poskytuje klientovi úplnú virtualizovanú infraštruktúru — to znamená nejaký súbor (pool) zdrojov, ako CPU jadra, RAM, siete a pod. Všetko ostatné je na klientovi — čo chce klient urobiť s týmito zdrojmi v rámci prideleného mu poolu (kvóty) — dodávateľovi veľmi nezáleží. Chce klient vytvoriť svoj vlastný vEPC alebo vôbec fungovať ako mini operátor a poskytovať telekomunikačné služby — nie je problém — robte. V takomto scenári dodávateľ služieb zodpovedá za poskytovanie zdrojov, ich odolnosť voči poruchám a dostupnosť, ako aj za OS, ktorá umožňuje zjednotiť tieto zdroje do poolov a poskytnúť 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 fázy si klient konfiguruje sám cez portál samoobsluhy a konzolu, vrátane a nastavenia sietí (okrem vonkajších sietí).
Čo je OpenStack?
Pre všetky tri možnosti potrebuje poskytovateľ služieb operačný systém, ktorý umožní vytvorenie cloudovej infraštruktúry. V skutočnosti však pri SaaS za celý technológie zodpovedá nie jedno oddelenie — existuje oddelenie, ktoré zodpovedá za infraštruktúru — to znamená, že poskytuje IaaS inému oddeleniu, toto oddelenie poskytuje klientovi SaaS. OpenStack je jedným z cloudových operačných systémov, ktorý umožňuje spojiť množstvo prepínačov, serverov a úložných systémov do jedného zdroja, rozdeliť tento spoločný zdroj na podzdroje (tenanty) a poskytovať tieto zdroje klientom cez sieť.
OpenStack — je cloudový operačný systém, ktorý umožňuje kontrolovať veľké pooly výpočtových zdrojov, úložných dát a sieťových zdrojov, pričom provisioning a správa sú vykonávané cez API s použitím štandardných autentifikačných mechanizmov.
Inými slovami, je to komplex projektov voľného softvéru, ktorý je určený na vytváranie cloudových služieb (ako verejných, tak aj súkromných) — teda súbor nástrojov, ktoré umožňujú zlúčiť serverové a prepínacie zariadenia do jedného poolu zdrojov, spravovať tieto zdroje s požadovanou úrovňou odolnosti voči poruchám.
V čase písania tohto materiálu vyzerá štruktúra OpenStack takto:
Obrázok prevzatý z
Každá z komponent, ktorá patrí do OpenStack, vykonáva určitú funkciu. Takáto distribuovaná architektúra umožňuje zahrnúť do riešenia ten súbor funkcionálnych komponentov, ktoré potrebujete. Avšak niektoré komponenty sú základné a ich odstránenie povedie k úplnej alebo čiastočnej nefunkčnosti riešenia ako celku. K takýmto komponentom sa spravidla ráta:
- Dashboard — webové GUI na správu služieb OpenStack
- Keystone — centralizovaná služba identifikácie, ktorá poskytuje funkcionalitu autentifikácie a autorizácie pre ostatné služby, ako aj spravuje prihlasovacie údaje užívateľov a ich role.
- Neutron — sieťová služba, ktorá zabezpečuje konektivitu medzi rozhraním rôznych služieb OpenStack (vrátane konektivity medzi VM a ich prístupom do vonkajšieho sveta)
- Cinder — poskytuje prístup k blokovému úložisku pre virtuálne stroje
- Nova — správa životného cyklu virtuálnych strojov
- Glance — repozitár obrazov virtuálnych strojov a snapshotov
- Swift — poskytuje prístup k objektovému úložisku
- Ceilometer — služba, ktorá umožňuje zber telemetrie a meranie existujúcich a spotrebovaných zdrojov
- Heat — orchestrácia založená na šablónach pre automatické vytváranie a provisioning zdrojov
Úplný zoznam všetkých projektov a ich účel si môžete pozrieť .
Každá z komponentov OpenStack je služba, ktorá zodpovedá za určitú funkciu a poskytuje API na správu tejto funkcie a interakciu tejto služby s inými službami cloudového operačného systému za účelom vytvorenia jednotnej infraštruktúry. Napríklad, Nova spravuje výpočtové zdroje a API na prístup k konfigurácii týchto zdrojov, Glance – správa obrazov a API na ich správu, Cinder – blokové úložisko a API na jeho správu atď. Všetky funkcie sú navzájom veľmi úzko prepojené.
Avšak ak sa zamyslíme, všetky služby spustené v OpenStack vlastne predstavujú nejaký virtuálny stroj (alebo kontajner), ktorý je pripojený k sieti. Otázka vzniká — prečo potrebujeme toľko prvkov?
Pozrime sa na algoritmus vytvárania virtuálneho stroja a jeho pripojenia k sieti a trvalému úložisku v OpenStacku.
- Keď vytvárate požiadavku na vytvorenie stroja, či už prostredníctvom Horizon (Dashboard) alebo cez CLI, prvá vec, ktorá sa stane — je autorizácia vašej požiadavky na Keystone — či môžete vytvoriť stroj, máte právo používať túto sieť, či má váš projekt dostatočné kvóty atď.
- Keystone autentifikuje vašu požiadavku a generuje v odpovedi auth-token, ktorý bude použitý ďalej. Po obdržaní odpovede od Keystone je požiadavka odoslaná do Nova (nova api).
- Nova-api overuje platnosť vašej požiadavky, obracajúc sa na Keystone s použitím predtým vygenerovaného auth-tokenu.
- Keystone autentifikuje a poskytuje na základe tohto auth-tokenu informácie o povoleniach a obmedzeniach.
- Nova-api vytvára v nova-database záznam o novom VM a odosiela požiadavku na vytvorenie stroja do nova-scheduler.
- Nova-scheduler vyberá hostiteľa (počítačovú uzol), na ktorom bude VM nasadená na základe zadaných parametrov, váh a zón. Záznam o tom a identifikátor VM sa zapisujú do nova-database.
- Následne nova-scheduler zasiela požiadavku na nasadenie inštancie do nova-compute. Nova-compute sa obracia na nova-conductor, aby získal informácie o parametroch stroja (nova-conductor je súčasťou nova, ktorá funguje ako proxy server medzi nova-database a nova-compute, čím obmedzuje množstvo požiadaviek smerom k nova-database, aby sa predišlo problémom s konzistenciou databázy a znížila záťaž).
- Nova-conductor získava požadované informácie z nova-database a posiela ich do nova-compute.
- Následne nova-compute kontaktuje glance pre získanie ID obrazu. Glance vykonáva validáciu požiadavky v Keystone a vracia požadované informácie.
- Nova-compute sa obracia na neutron, aby získal informácie o parametroch siete. Rovnako ako glance, neutron vykonáva validáciu požiadavky v Keystone, po čom vytvára záznam v databáze (identifikátor portu atď.), vytvára požiadavku na vytvorenie portu a vracia požadované informácie do nova-compute.
- Nova-compute sa obracia na cinder s požiadavkou na pridelenie volume virtuálnej maquina. Rovnako ako glance, cinder vykonáva validáciu požiadavky v Keystone, vytvára požiadavku na vytvorenie volume a vracia požadované informácie.
- Nova-compute odosiela požiadavku libvirt na nasadenie virtuálnej mašiny s danými parametrami.
Na prvý pohľad sa zdá, že jednoduchá operácia vytvorenia virtuálneho stroja sa mení na vír API volaní medzi prvkami cloudovej platformy. Ako vidíte, aj predtým označené služby sa skladajú z menších komponentov, medzi ktorými prebieha interakcia. Vytvorenie stroja je len malou časťou toho, čo cloudová platforma umožňuje — existuje služba zodpovedná za vyrovnávanie zaťaženia, služba pre blokové uloženie, služba pre DNS, služba na provisionovanie bare metal serverov a tak ďalej. Cloud vám umožňuje zaobchádzať s vašimi virtuálnymi strojmi ako so stádom oviec (na rozdiel od virtualizácie). Ak sa vo virtuálnom prostredí niečo stane so strojom — obnovíte ho z záloh a podobne, cloudové aplikácie sú postavené tak, aby virtuálny stroj nehral takú dôležitú úlohu — virtuálny stroj „zhynul“ — nevadí — jednoducho sa vytvorí nový stroj na základe šablóny a, ako sa hovorí, družstvo si nevšimlo stratu bojovníka. Samozrejme, to vyžaduje existenciu orchestracných mechanizmov — pomocou Heat šablón môžete bez problémov nasadiť komplexnú funkciu pozostávajúcu z desiatok sietí a virtuálnych strojov.
Vždy je potrebné mať na pamäti, že cloudová infraštruktúra neexistuje bez siete — každý prvok interaguje s inými prvkami prostredníctvom siete. Okrem toho cloud má úplne nestatickú sieť. Samozrejme, podkladová sieť je ešte viac-menej statická — nové uzly a prepínače sa nepridávajú každý deň, avšak overlay zložka sa môže a nevyhnutne bude neustále meniť — nové siete sa budú pridávať alebo odstraňovať, nové virtuálne stroje sa objavia a staré zaniknú. A ako si pamätáte z definície cloudu uvedenej na začiatku článku — zdroje by sa mali automaticky prideliť používateľovi s minimálnym (alebo lepšie, bez) zásahu zo strany poskytovateľa služieb. To znamená, že ten typ poskytovania sieťových zdrojov, ktorý existuje teraz vo forme frontendu vo vašej osobnej oblasti, dostupnej cez http/https a pohotovostného sieťového inžiniera Vasila ako backendu — to nie je cloud, ani ak Vasil má osem rúk.
Neutron, ako sieťová služba, poskytuje API na správu sieťovej časti cloudovej infraštruktúry. Služba zabezpečuje fungovanie a správu sieťovej časti OpenStack, čím poskytuje úroveň abstrakcie nazývanú Network-as-a-Service (NaaS). To znamená, že sieť je rovnakou virtuálnou merateľnou jednotkou ako napríklad virtuálne jadrá CPU alebo objem RAM.
Ale predtým, ako prejdeme na architektúru sieťovej časti OpenStack, zoberme si, ako funguje táto sieť v OpenStacku a prečo je sieť dôležitou a neoddeliteľnou súčasťou cloudu.
Máme teda dve virtuálne stroje klienta RED a dva virtuálne stroje klienta GREEN. Povedzme, že tieto stroje sú umiestnené na dvoch hypervízoroch nasledovne:
Momentálne ide len o virtualizáciu 4 serverov a nič viac, pretože doteraz sme len virtualizovali 4 servery umiestnené na dvoch fyzických serveroch. Zatiaľ ani nie sú pripojené k sieti.
Aby sme vytvorili cloud, musíme pridať niekoľko komponentov. Po prvé, virtualizujeme sieťovú časť — musíme tieto 4 stroje spojit po pároch, pričom klienti požadujú práve L2 pripojenie. Samozrejme, môžeme použiť prepínač a nastaviť v jeho smere trunk a všetko vyriešiť pomocou linux bridge, alebo pre pokročilejších používateľov openvswitch (k nemu sa ešte vrátime). Ale sietí môže byť veľmi veľa a neustále tlačiť L2 cez switch — nie je najlepšia myšlienka — tak rôzne oddelenia, servisný desk, mesiace čakania na vyhotovenie žiadosti, týždne troubleshooting — v modernom svete tento prístup už nefunguje. A čím skôr si to spoločnosť uvedomí, tým ľahšie sa jej bude napredovať. Preto medzi hypervízormi vyčleníme L3 sieť, cez ktorú budú komunikovať naše virtuálne stroje, a už nad touto L3 sieťou postavíme virtuálne prekryté L2 (overlay) siete, kde bude prebiehať prevádzka našich virtuálnych strojov. Ako enkapsuláciu môžeme použiť GRE, Geneve alebo VxLAN. Zatiaľ sa zastavíme na poslednom, aj keď to nie je zvlášť dôležité.
Musíme niekde umiestniť VTEP (dúfam, že sú všetci oboznámení s terminológiou VxLAN). Keďže zo serverov vychádza hneď L3 sieť, nič nám nebráni umiestniť VTEP na samotné servery, pričom OVS (OpenvSwitch) to skvele zvládne. Nakoniec sme získali takúto konštrukciu:
Keďže musí byť traffic medzi VM rozdelený, porty smerom k virtuálnym strojom budú mať rôzne čísla VLAN. Číslo tagu hrá rolu len v rámci jedného virtuálneho prepínača, pretože pri enkapsulácii v VxLAN ho môžeme bez problémov odstrániť, keďže budeme mať VNI.
Teraz môžeme bez problémov vytvárať naše stroje a virtuálne siete pre ne.
Ale čo ak má klient ďalší stroj, ktorý sa nachádza v inej sieti? Potrebujeme routing medzi sieťami. Rozoberieme jednoduchý variant, keď sa používa centralizovaný routing — to znamená, že traffic je smerovaný cez špeciálne vyhradené network uzly (bežne sú kombinované s control uzlami, takže u nás to bude to isté).
Na prvý pohľad to nie je nič zložité — vytvoríme bridge interface na kontrolnom uzle, nasmerujeme naň traffic a odtiaľ ho smerujeme kam potrebujeme. Ale problém je v tom, že klient RED chce používať sieť 10.0.0.0/24 a klient GREEN chce používať sieť 10.0.0.0/24. To znamená, že sa začína prekrývanie adresných priestorov. Okrem toho klienti nechcú, aby ostatní klienti mohli byť smerovaní do ich interných sietí, čo je logické. Aby sme oddelili siete a traffic dát klientov, vyčleníme pre každého z nich samostatný namespace. Namespace je v podstate kópia sieťového stacku Linux, to znamená, že klienti v namespace RED sú úplne izolovaní od klientov v namespace GREEN (alebo je routing medzi týmito sieťami klientov povolený cez default namespace alebo už na vyššie položenom transportnom vybavení).
Dostaneme teda takú schému:
L2 tunely sa zbiehajú zo všetkých výpočtových uzlov na kontrolný uzol, kde sa nachádza L3 interface pre tieto siete, každý v vyhradenom namespace pre izoláciu.
Avšak zabudli sme 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é sa k nemu dá dostať. To znamená, že musíme vystúpiť do vonkajšieho sveta. Existujú rôzne možnosti. Urobíme najjednoduchšiu variantu. Pridáme klientom jednu sieť, ktorá bude platná v sieti poskytovateľa a nebude sa prekrývať s inými sieťami. Sieťe môžu byť taktiež prekrývajúce sa a smerovať do rôznych VRF na strane poskytovateľskej siete. Tieto siete budú tiež žiť v mennom priestore každého z klientov. Napriek tomu však budú vystupovať do vonkajšieho sveta cez jedno fyzické (alebo bondované, čo je logickejšie) rozhranie. Aby sme oddelili prevádzku klientov, prevádzka vychádzajúca von bude označovaná VLAN tagom prideleným klientovi.
Nakoniec máme takúto schému:
Rozumná otázka — prečo neurobiť brány na samotných compute nodoch? Nie je s tým veľký problém, viac než to, pri zapnutí distribuovaného smerovača (DVR) to tak aj funguje. V tomto scenári sa zaoberáme najjednoduchšou variantou so centralizovanou bránou, ktorá sa v Openstacku používa predvolene. Pre vysoko zaťažené funkcie sa budú používať ako distribuovaný smerovač, tak aj technológie zrýchlenia ako SR-IOV a Passthrough, ale ako sa hovorí, to je už celkom iný príbeh. Najprv sa zamerajme na základný aspekt a potom prejdeme na detaily.
Naša schéma je už funkčná, avšak sú tu niektoré nuansy:
- Musíme nejakým spôsobom chrániť naše stroje, t.j. umiestniť na rozhranie switche smerom k klientovi filter.
- Umožniť automatické získanie IP adresy virtuálnym strojom, aby sme nemuseli zakaždým vstupovať do nich cez konzolu a zadávať adresu.
Začnime s ochranou strojov. Na to môžeme použiť banálne iptables, prečo nie.
To znamená, že naša topológia sa už trochu skomplexnila:
Pokračujme ďalej. Musíme pridať DHCP server. Najideálnejším miestom na umiestnenie DHCP serverov pre každého z klientov bude už spomínaná kontrolná nód, kde sa nachádzajú menné priestory:
Avšak existuje malý problém. Čo ak sa všetko reštartuje a všetky informácie o prenájme adries na DHCP zmiznú? logicky budú priradené nové adresy, čo nie je veľmi pohodlné. Riešenia sú dve — buď použiť doménové mená a pridať DNS server pre každého zákazníka, potom nám adresa nebude veľmi dôležitá (podobne ako v sieťovej časti v k8s) — ale tu nastáva problém s externými sieťami, pretože aj v nich môžu byť priradené adresy cez DHCP — je potrebná synchronizácia s DNS servermi na cloudovej platforme a externým DNS serverom, čo nie je veľmi flexibilné, hoci to môže byť celkom možné. Alebo druhá možnosť — použiť metadáta — teda uchovávať informácie o priradenej adrese stroja, aby DHCP server vedel, ktorú adresu priradiť stroju, ak už nejakú dostal. Druhá možnosť je jednoduchšia a flexibilnejšia, pretože umožňuje uchovať doplnkové informácie o stroji. Teraz do schémy pridáme metadata agenta:
Ešte jedna otázka, ktorú by sme mali osvetliť — je to možnosť používať jednu externú sieť pre všetkých klientov, pretože externé siete, ak majú byť platné v celej sieti, budú mať komplikáciu — je potrebné neustále prideľovať a kontrolovať prideľovanie týchto sietí. Možnosť použitia jedinej externé predkonfigurovanej siete pre všetkých klientov by bola veľmi vítaná pri vytváraní verejného cloudu. To by zjednodušilo nasadzovanie strojov, pretože sa nemusíme porovnávať s databázou adries a vyberať jedinečný adresný priestor pre externú sieť každého klienta. Navyše môžeme externú sieť napísať vopred a pri nasadzovaní budeme musieť len asociovať externé adresy s klientskými strojmi.
A tu nám pomáha NAT — jednoducho umožníme klientom vychádzať do vonkajšieho sveta cez default namespace pomocou NAT prekladu. Ale tu je malý problém. To je dobré, ak klientsky server funguje ako klient, nie ako server — teda iniciuje, nie prijíma pripojenia. Ale my to budeme mať naopak. V takom prípade musíme urobiť destination NAT, aby kontrolný uzol pri prijímaní prevádzky pochopil, že táto prevádzka je určená pre virtuálny stroj A klienta A, a preto je potrebné vykonať NAT preklad z vonkajšej adresy, napríklad 100.1.1.1 na vnútornú adresu 10.0.0.1. V takomto prípade, hoci všetci klienti používajú jednu a tú istú sieť, vnútorná izolácia je úplne zachovaná. To znamená, že na kontrolnom uzle musíme urobiť dNAT a sNAT. Použitie jednotnej siete s priradením plávajúcich adres alebo vonkajších sietí, alebo aj to aj ono naraz — závisí od toho, čo chcete do cloudu preniesť. Na schému nenanesieme ešte plávajúce adresy, ale necháme už predtým pridané vonkajšie siete — každý klient má svoju vonkajšiu sieť (na schéme označené ako VLAN 100 a 200 na vonkajšom rozhraní).
Nakoniec sme dostali zaujímavé, ale zároveň premyslené riešenie, ktoré má určitú flexibilitu, ale zatiaľ nemá mechanizmy odolnosti voči zlyhaniu.
Po prvé, máme iba jeden kontrolný uzol — jeho výpadok spôsobí zrútenie všetkých systémov. Na odstránenie tohto problému je potrebné vytvoriť aspoň kvorum z 3 uzlov. Pridáme to na schému:
Samozrejme, všetky uzly sa synchronizujú a pri výpadku aktívneho uzla prevezme jeho povinnosti iný uzol.
Nasledujúci problém sú disky virtuálnych strojov. V súčasnosti sa nachádzajú na samých hypervisoroch a v prípade problémov s hypervisorom stratíme všetky dáta — a existencia RAIDu tu nijako nepomôže, ak stratíme nie disk, ale celý server. Preto potrebujeme vybudovať službu, ktorá bude fungovať ako front-end pre akékoľvek úložisko. Aké to úložisko bude, nám nie je až tak dôležité, ale malo by chrániť naše dáta pred zlyhaním disku, uzla a možno aj celého kabinetu. Existuje niekoľko možností — samozrejme, sú tu SAN siete s Fiber Channel, ale povedzme si úprimne — FC je už prežitok minulosti — analóg E1 v doprave — áno, súhlasím, stále sa používa, ale len tam, kde bez neho jednoducho nemôžeme. Preto by som sa dobrovoľne neodvážil rozširovať FC sieť v roku 2020, keď viem o existencii iných zaujímavejších alternatív. Hoci každý má svoje a možno sa nájdu tí, kto si myslí, že FC so všetkými svojimi obmedzeniami je všetko, čo potrebujeme — nebudem sa hádať, každý má svoj názor. Ale najzaujímavejším riešením, domnievam sa, je použiť SDS, napríklad Ceph.
Ceph umožňuje vybudovať vysoko dostupné riešenie na ukladanie dát s množstvom možností zálohovania, počnúc kódmi s kontrolou paritou (analóg RAID 5 alebo 6) až po úplnú replikáciu dát na rôzne disky s ohľadom na umiestnenie diskov v serveroch, a serverov v skriniach atď.
Na zostavenie Ceph potrebujeme ďalšie 3 uzly. Interakcia s úložiskom sa taktiež bude vykonávať pomocou siete s využitím služieb blokového, objektového a súborového úložiska. Pridáme do schémy úložisko:
Poznámka: môžeme vytvárať aj hyperkonvergované výpočtové nody — ide o koncept zlúčenia viacerých funkcií na jednej node — napríklad úložisko + výpočty — nevyčleňovať špeciálne nody pre ceph úložisko. Získame tak rovnakú odolnú schému — pretože SDS rezervuje údaje s úrovňou rezervácie, ktorú určíme. Avšak hyperkonvergované nody sú vždy kompromis — pretože úložná node len tak nezahreje vzduch, ako sa na prvý pohľad zdá (pretože na nej nie sú virtuálne stroje) — spotrebúva zdroje CPU na údržbu SDS (v pozadí vykonáva všetky replikácie, obnovy po poruchách node, diskov atď.). Teda stratíte časť výkonu výpočtovej nody ak ju skombinujete s úložiskom.
S tým všetkým sa nejako musí narábať — potrebujeme niečo, čo nám umožní vytvoriť stroj, sieť, virtuálny smerovač atď. Na to pridáme na kontrolnú node službu, ktorá bude plniť úlohu dashboardu — klient sa bude môcť pripojiť k tomuto portálu cez http/https a urobiť všetko, čo potrebuje (no takmer).
Nakoniec máme vysoce odolný systém. Všetky prvky tejto infraštruktúry musia byť nejako ovládané. Predtým bolo opísané, že Openstack je súbor projektov, z ktorých každý zabezpečuje určitú funkciu. Ako vidíme, prvkov, ktoré je potrebné konfigurovať a kontrolovať, je viac než dosť. Dnes sa porozprávame o sieťovej časti.
Architektúra Neutron
V OpenStack je Neutron zodpovedný za pripojenie portov virtuálnych strojov k spoločnej L2 sieti, za zabezpečenie smerovania prevádzky medzi VM nachádzajúcimi sa v rôznych L2 sieťach, ako aj za smerovanie von, poskytovanie takých služieb ako NAT, Floating IP, DHCP atď.
Vysokoúrovňovo možno prácu sieťovej služby (základná časť) opísať takto.
Pri spustení VM sieťová služba:
- Vytvára port pre tento VM (alebo porty) a informuje o tom službu DHCP;
- Vytvára sa nové virtuálne sieťové zariadenie (cez libvirt);
- VM sa pripája k portu vytvorenému v kroku 1 (portom);
Nie je to tak prekvapujúce, ale v základe fungovania Neutronu sú štandardné mechanizmy známe všetkým, ktorí sa kedy zaoberali Linuxom — sú to namespaces, iptables, linux bridges, openvswitch, conntrack atď.
Treba hneď spresniť, že Neutron nie je SDN kontrolér.
Neutron sa skladá z niekoľkých vzájomne prepojených komponentov:
Openstack-neutron-server — je demon, ktorý pracuje s používateľskými požiadavkami prostredníctvom API. Tento demon sa nezaoberá definovaním akýchkoľvek sieťových súvislostí, ale poskytuje potrebné informácie svojim plug-inom, ktoré následne konfigurujú požadovaný sieťový prvok. Neutron-agenti na uzloch OpenStack sa registrujú na serveri Neutron.
Neutron-server je v podstate aplikácia napísaná v pythone, ktorá sa skladá z dvoch častí:
- REST služba
- Neutron Plugin (core/service)
REST služba je určená na prijímanie API volaní od ostatných komponentov (napríklad požiadavka na poskytnutie nejakých informácií atď.)
Plug-iny sú pripojiteľné programové komponenty/moduly, ktoré sa vyvolávajú pri API požiadavkách — teda pripojenie nejakého služby sa uskutočňuje prostredníctvom nich. Plug-iny sa delia do dvoch typov — služobný a koreňový. Zvyčajne koreňový plug-in zodpovedá hlavne za správu adresného priestoru a L2 pripojenia medzi VM, zatiaľ čo služobné plug-iny poskytujú ďalšie funkcie, ako napríklad VPN alebo FW.
Zoznam dostupných plug-inov je možné napríklad pozrieť
Služobných plug-inov môže byť niekoľko, avšak koreňový plug-in môže byť iba jeden.
Openstack-neutron-ml2 — je štandardný koreňový plug-in Openstack. Tento plug-in má modulárnu architektúru (na rozdiel od svojho predchodcu) a prostredníctvom pripojených ovládačov vykonáva konfiguráciu sieťovej služby. Samotný plug-in si podrobnejšie preberieme neskôr, pretože v skutočnosti poskytuje tú flexibilitu, ktorou disponuje OpenStack v oblasti siete. Koreňový plug-in môže byť nahradený (napríklad Contrail Networking robí takúto výmenu).
RPC služba (rabbitmq-server) — služba zabezpečujúca správu frontov a interakciu s inými službami OpenStack, ako aj interakciu medzi agentmi sieťovej služby.
Sieťoví agenti — agenti, ktorí sú umiestnení na každom uzle, prostredníctvom ktorých sa vykonáva konfigurácia sieťových služieb.
Agenti môžu mať niekoľko typov.
Hlavný agent — to je L2 agent. Tieto agenti sa spúšťajú na každom z hypervízorov, vrátane kontrolných uzlov (presnejšie povedané na všetkých uzloch, ktoré poskytujú akúkoľvek službu pre tenantov) a ich hlavnou funkciou je pripojenie virtuálnych strojov k spoločnej L2 sieti, ako aj generovanie upozornení pri vzniku akýchkoľvek udalostí (napríklad odpojenia/zapojenia portu).
Ďalším, rovnako dôležitým agentom je L3 agent. Podľa predvoleného nastavenia sa tento agent spúšťa výhradne na sieťovom uzle (často je sieťový uzol spojený s kontrolným uzlom) a zabezpečuje smerovanie medzi sieťami tenantov (ako medzi jeho sieťami a sieťami iných tenantov, tak aj prístupom do vonkajšieho sveta, poskytujúc NAT a DHCP službu). Avšak pri použití DVR (distribuovaný smerovač) sa potreba L3 pluginu objavuje aj na výpočtových uzloch.
L3 agent využíva Linux namespaces na poskytnutie každému tenantovi súboru vlastných izolovaných sietí a funkcie virtuálnych smerovačov, ktoré smerujú prevádzku a poskytujú služby brány pre Layer 2 siete.
Databáza — databáza identifikátorov sietí, podsietí, portov, poolov a pod.
V skutočnosti Neutron prijíma API požiadavky na vytvorenie akýchkoľvek sieťových entít, autentifikuje požiadavku a cez RPC (ak sa obracia na nejaký plugin alebo agenta) alebo REST API (ak komunikuje v SDN) posiela agentom (cez pluginy) pokyny potrebné na organizáciu požadovanej služby.
Teraz sa pozrieme na testovaciu inštaláciu (ako je nasadená a čo je v jej obsahu, pozrieme sa 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 ~]$ 
A toto je celá štruktúra Neutron. Teraz si zaslúži trochu času na plugin ML2.
Modular Layer 2
Ako už bolo uvedené, plugin je štandardným koreňovým pluginom OpenStack a má modulárnu architektúru.
Predchodca pluginu ML2 mal monolitnú štruktúru, čo neumožňovalo napríklad používať mix niekoľkých technológií v jednej inštalácii. Napríklad ste nemohli používať openvswitch a linuxbridge súčasne — buď jedno, alebo druhé. Z tohto dôvodu bol vytvorený plugin ML2 s jeho architektúrou.
ML2 má dve zložky — dva typy ovládačov: Type drivers a Mechanism drivers.
Type drivers určujú technológie, ktoré budú použité na organizáciu sieťových spojení, napríklad VxLAN, VLAN, GRE. Ovládač umožňuje používať rôzne technológie. Štandardnou technológiou je VxLAN enkapsulácia pre overlay siete a vlan vonkajších sietí.
K Type drivers patria nasledujúce typy sietí:
Flat — sieť bez tagovania
VLAN — tagovaná sieť
Local — špeciálny typ siete pre inštalácie typu all-in-one (takéto inštalácie sú potrebné buď pre vývojárov alebo na školenie)
GRE — overlay sieť využívajúca GRE tunely
VxLAN — overlay sieť využívajúca VxLAN tunely
Mechanism drivers určujú prostriedky, ktoré zabezpečujú organizáciu uvedených v type driver technologických — napríklad openvswitch, sr-iov, opendaylight, OVN atď.
V závislosti od implementácie daného ovládača budú použité buď agenti, ktoré spravuje Neutron, alebo sa využijú pripojenia s externým SDN kontrolórom, ktorý preberá všetky otázky týkajúce sa organizácie L2 sietí, smerovania atď.
Príklad, ak používame ML2 spolu s OVS, na každom výpočtovom uzle je nainštalovaný L2 agent, ktorý spravuje OVS. Avšak ak používame napríklad OVN alebo OpenDayLight, riadenie OVS prechádza pod ich jurisdikciu — Neutron prostredníctvom koreňového pluginu poskytuje príkazy kontrolórovi, a ten už robí to, čo mu bolo povedané.
Osrefreshme v pamäti Open vSwitch
V súčasnej dobe je jednou z kľúčových komponentov OpenStack Open vSwitch.
Pri inštalácii OpenStack bez akéhokoľvek dodatočného dodávateľského SDN ako Juniper Contrail alebo Nokia Nuage je OVS hlavným sieťovým komponentom cloudovej siete a v kombinácii s iptables, conntrack, namespaces umožňuje organizáciu plnohodnotných overlay sietí s multitenanciou. samozrejme, tento komponent môže byť nahradený, napríklad pri použití externých proprietárnych (dodávateľských) SDN riešení.
OVS je softvérový prepínač s otvoreným zdrojovým kódom, ktorý je určený na použitie vo virtualizovaných prostrediach ako virtuálny forwarder prevádzky.
V súčasnosti má OVS veľmi slušnú funkcionalitu, ktorá zahŕňa také technológie ako QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK atď.
Poznámka: pôvodne OVS nebol zamýšľaný ako softvérový prepínač pre vysoce zaťažené telekomunikačné funkcie a bol viac určený pre menej náročné na prenosové kapacity IT funkcie ako WEB server alebo poštový server. Avšak OVS sa neustále zdokonaľuje a súčasné implementácie OVS výrazne zlepšili jeho výkon a možnosti, čo umožňuje jeho použitie operátorom sietí pre vysoce zaťažené funkcie, napríklad existuje implementácia OVS s podporou DPDK urýchlenia.
Existujú tri dôležité komponenty OVS, o ktorých je potrebné vedieť:
- Kernel module — komponenta, umiestnená v kernel space, ktorá vykonáva spracovanie prevádzky na základe prijatých pravidiel od riadiaceho prvku;
- vSwitch Daemon (ovs-vswitchd) je proces spustený v používateľskom priestore, ktorý zodpovedá za programovanie kernel modulu — teda predstavuje priamo logiku fungovania prepínača.
- Server databáz — lokálna databáza umiestnená na každom hoste, na ktorom je spustený OVS, v ktorej sú uložené konfigurácie. Skrze tento modul môžu komunikovať SDN kontroléry cez protokol OVSDB.
K tomu všetkému sa pridáva súbor diagnostických a ovládacích nástrojov, ako sú ovs-vsctl, ovs-appctl, ovs-ofctl a pod.
V súčasnosti sa Openstack široko využíva telekomunikačnými operátormi na migráciu sieťových funkcií, ako sú EPC, SBC, HLR a pod. Niektoré funkcie môžu bez problémov fungovať s OVS v jeho súčasnej forme, ale napríklad EPC spracováva tok predplatiteľských dát — teda prechádza cez seba obrovské množstvá dát (v súčasnosti dosahujú objemy dát niekoľko stoviek gigabitov za sekundu). Samozrejme, púšťať takýto tok cez kernel space (keďže predvolene je forwarder umiestnený tam) nie je najlepšia idea. Preto často OVS nasadzujú výhradne v používateľskom priestore s využitím technológie DPDK na presmerovanie tokov z NIC do používateľského priestoru obchádzajúc kernel.
Poznámka: pre cloud, nasadený pre telekomunikačné funkcie, existuje možnosť presmerovania toku z compute uzla obchádzajúc OVS priamo do prepínacieho zariadenia. Na tento účel sa používajú mechanizmy SR-IOV a Passthrough.
Ako to funguje na reálnom makete?
A teraz prejdeme k praktickej časti a pozrieme sa, ako to všetko funguje v praxi.
Na začiatok rozbehneme jednoduchú inštaláciu Openstacku. Keďže nemám k dispozícii sadu serverov na experimenty, budeme skladať maketu na jednom fyzickom serveri z virtuálnych strojov. Áno, samozrejme na komerčné účely takéto riešenie nie je vhodné, ale aby sme sa na príklade pozreli, ako funguje sieť v Openstacku, táto inštalácia úplne postačuje. Navyše, takáto inštalácia je pre účely vzdelávania ešte zaujímavejšia — pretože je možné sledovať tok a pod.
Keďže potrebujeme vidieť len základnú časť, môžeme nevyužívať niekoľko sietí, ale všetko postaviť pomocou len dvoch sietí, pričom druhá sieť v tejto makete bude využívaná výhradne na prístup k undercloud a DNS serveru. Vonkajšie siete zatiaľ nebudeme riešiť — to je téma na samostatný veľký článok.
Tak, začneme po poriadku. Najprv trochu teórie. Budeme inštalovať OpenStack pomocou TripleO (OpenStack na OpenStack). Podstata TripleO spočíva v tom, že inštalujeme OpenStack all-in-one (to znamená na jednu uzol), nazývaný undercloud, a následne využívame možnosti nasadeného OpenStacku na inštaláciu OpenStacku určeného na prevádzku, nazývaného overcloud. Undercloud bude využívať zakomponovanú schopnosť spravovať fyzické servery (bare metal) — projekt Ironic — na provisionovanie hypervízorov, ktoré budú plniť úlohy compute, control, a storage uzlov. To znamená, že na nasadenie OpenStacku nepoužívame žiadne externé nástroje — nasadzujeme OpenStack pomocou OpenStacku. Počas inštalácie sa to stane oveľa jasnejším, preto sa na tom nezastavíme a ideme ďalej.
Poznámka: V tomto článku som na zjednodušenie nepoužil sieťovú izoláciu pre interné siete OpenStacku, a všetko je nasadené s použitím len jednej siete. Avšak prítomnosť alebo neprítomnosť izolácie sietí neovplyvňuje základnú funkčnosť riešenia — všetko bude fungovať presne tak, ako pri použití izolácie, avšak prevádzka bude prebiehať v jednej sieti. Pri komerčnej inštalácii je samozrejme potrebné používať izoláciu s rôznymi VLANmi a rozhraním. Napríklad správa prevádzky úložiska Ceph a prevádzka priamo dát (prístupy strojov k diskovým jednotkám a pod.) pri izolácii využívajú rôzne podsiete (Storage management a Storage), čo umožňuje spraviť riešenie odolnejším voči výpadkom, oddelením tejto prevádzky napríklad na rôznych portoch, alebo použitím rôznych QoS profilov pre rôznu prevádzku, aby prevádzka dát nepreťažila signálnu prevádzku. V našom prípade však pôjdu v jednej a tej istej sieti, a vo faktore nás to nijako neobmedzuje.
Poznámka: Keďže sa chystáme spustiť virtuálne stroje v virtuálnom prostredí, ktoré je založené na virtuálnych strojoch, je najprv potrebné povoliť nested virtualizáciu.
Skontrolovať, či je nested virtualizácia zapnutá alebo nie, môžete takto:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Ak vidíte písmeno N, zapnite podporu nested virtualizácie podľa akéhokoľvek návodu, ktorý nájdete na internete, napríklad .
Potrebujeme zostaviť takúto schému z virtuálnych strojov:
V mojom prípade, pre spojenie virtuálnych strojov, ktoré budú súčasťou budúcej inštalácie (mám ich sedem, ale môžete sa obísť aj s štyrmi, ak nemáte veľa zdrojov), som použil OpenvSwitch. Vytvoril som jeden ovs most a pripojil k nemu virtuálne stroje cez portové skupiny. Na to som vytvoril xml súbor nasledujúceho typu:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
ovs-network-1
7a2e7de7-fc16-4e00-b1ed-4d190133af67Tu sú vyhlásené tri portové skupiny — dve prístupové a jedna trunk (posledná bola potrebná pre DNS server, ale môžete sa obísť aj bez neho, alebo ho postaviť na hostiteľskom stroji — ako vám to vyhovuje). Potom pomocou tejto šablóny vyhlásime našu sieť cez 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áciu 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 scénári adresa na portu ovs-br1 nebude prístupná, pretože nemá VLAN tag. Aby sme to opravili, musíme zadať príkaz sudo ovs-vsctl set port ovs-br1 tag=100. Avšak po reštarte tento tag zmizne (ak niekto vie, ako ho udržať — budem veľmi vďačný). Ale to nie je veľmi dôležité, pretože táto adresa nám bude potrebná len počas inštalácie a nebude potrebná, keď bude OpenStack úplne nasadený.
Ďalej vytvoríme undercloud 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=ttyS0Pri inštalácii nastavte všetky potrebné parametre, ako je názov stroja, heslá, používateľov, NTP servery a podobne. Môžete si hneď nastaviť aj porty, ale pre mňa osobne je jednoduchšie po inštalácii vstúpiť do stroja cez konzolu a upraviť potrebné súbory. Ak už máte pripravený obraz, môžete ho využiť, alebo sa môžete správať ako ja — stiahnuť minimálny obraz CentOS 7 a využiť ho na inštaláciu VM.
Po úspešnej inštalácii by sa vám mala objaviť virtuálna mašina, na ktorú môžete nainštalovať Undercloud.
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningNajprv nainštalujte potrebné nástroje počas 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 Undercloud
Vytvorte používateľa stack, nastavte mu heslo, pridajte ho do sudoer a povoľte mu vykonávať root príkazy cez sudo bez nutnosti zadávať heslo:
useradd stack
passwd stack
echo "stack ALL=(root) NOPASSWD:ALL" > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackTeraz uveďte v súbore hosts celé meno undercloud:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Potom pridajte repozitáre a nainštalujte potrebný softvér:
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, potom príkazy súvisiace s ceph nemusíte zadávať. Použil som vydanie Queens, ale vy môžete použiť akékoľvek iné, ktoré sa vám páči.
Ďalej skopírujte konfiguračný súbor undercloud do domácej priečinky používateľa stack:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confTeraz je potrebné upraviť tento súbor, aby sa prispôsobil našej inštalácii.
Na začiatok súboru je potrebné pridať nasledujúce 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 = 10Takže sa pozrime na nastavenia:
undercloud_hostname — celé meno undercloud servera, malo by sa zhodovať s záznamom na DNS serveri
local_ip — lokálna adresa undercloud smerom k provizioningovej sieti
network_gateway — tá istá lokálna adresa, ktorá bude fungovať ako gateway pre prístup do vonkajšieho sveta počas inštalácie overcloud uzlov, tiež súhlasí s lokálnou IP
undercloud_public_host — adresa vonkajšieho API, priraďte akúkoľvek voľnú adresu z provizioningovej siete
undercloud_admin_host adresa vnútorného API, priraďte akúkoľvek voľnú adresu z provizioningovej siete
undercloud_nameservers — DNS server
generate_service_certificate — táto poloha je veľmi dôležitá v aktuálnom príklade, pretože ak ju nenastavíte na hodnotu false, dostanete chybu pri inštalácii, problém je popísaný v bugtrackeri Red Hat
local_interface rozhranie v provizioningovej sieti. Toto rozhranie bude prekonfigurované počas nasadenia undercloud, preto musí mať undercloud dve rozhrania — jedno na prístup a druhé na provizioning
local_mtu — MTU. Keďže máme testovaciu laboratóriu a MTU mám 1500 na portoch OVS switche, je potrebné nastaviť hodnotu na 1450, aby prešli paketmi zapuzdrenými vo VxLAN
network_cidr — provizioningová sieť
masquerade — použitie NAT pre prístup do vonkajšej siete
masquerade_network — sieť, ktorá bude NAT-ovaná
dhcp_start — počiatočná adresa z poolu adries, z ktorého budú priraďované adresy uzlom počas nasadenia overcloud
dhcp_end — koncová adresa z poolu adries, z ktorého budú priraďované adresy uzlom počas nasadenia overcloud
inspection_iprange — pool adries potrebných na introspekciu (nesmie sa prekryť s vyššie uvedeným poolom)
scheduler_max_attempts — maximálny počet pokusov o inštaláciu overcloud (musí byť väčší alebo rovný počtu uzlov)
Potom, čo je súbor opísaný, môžete zadať príkaz na nasadenie undercloud:
openstack undercloud install
Procedúra trvá od 10 do 30 minút v závislosti od vášho hardvéru. Nakoniec by ste mali vidieť takýto výstup:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Inštalácia undercloud dokončená.
Súbor obsahujúci heslá tejto inštalácie je na
/home/stack/undercloud-passwords.conf.
K dispozícii je aj súbor stackrc na /home/stack/stackrc.
Tieto súbory sú potrebné na interakciu so službami OpenStack a mali by byť
zabezpečené.
#############################################################################Tento výstup hovorí, že ste úspešne nainštalovali undercloud a teraz môžete skontrolovať stav undercloud a prejsť k inštalácii overcloud.
Ak sa pozriete na výstup ifconfig, uvidíte, že sa objavil nový bridge rozhranie
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163 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
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 0Tento rozhranie teraz bude použité na nasadenie overcloudu.
Z nasledujúceho výstupu je zrejmé, že všetky služby sú 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 sieťovej časti undercloud:
(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 ~]$Inštalácia overcloud
V súčasnosti máme len undercloud a chýbajú nám uzly, z ktorých sa bude vytvárať overcloud. Preto najprv nasadíme potrebné virtuálne stroje. Počas nasadzovania undercloud sám nainštaluje operačný systém a potrebný softvér na overcloud stroje — to znamená, že nám netreba úplne nasadiť stroj, ale len vytvoriť pre neho disk (alebo disky) a určiť jeho parametre — čo v skutočnosti znamená, že dostaneme holý server bez nainštalovaného operačného systému.
Prejdeme do priečinka s diskami našich virtuálnych strojov a vytvoríme 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 konáme ako root, musíme zmeniť vlastníka týchto diskov, aby sme sa vyhli problémom 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 inštalovať ceph na účely jeho štúdia, nevytvárajte príkazy pre minimálne 3 uzly s minimálne dvoma diskami, a v šablóne uveďte, že sa budú používať virtuálne disky vda, vdb atď.
Skvele, 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 sú príkazy --print-xml > /tmp/storage-1.xml, ktorý vytvára xml súbor s popisom každého stroja v priečinku /tmp/, ak ju nepridáte, nebudete schopní definovať virtuálne stroje.
Teraz musíme definovať všetky tieto stroje v 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 vypnuté
- compute-2 vypnuté
- control-1 vypnuté
- storage-1 vypnuté
- storage-2 vypnuté
[root@hp-gen9 ~]#Teraz malý detail — tripleO používa IPMI na správu serverov počas inštalácie a introspekcie.
Introspekcia je proces inšpekcie hardvéru na získanie jeho parametrov potrebných pre ďalšie provisioning nód. Introspekcia sa vykonáva pomocou ironic — služby určené na prácu s bare metal servermi.
Ale tu je problém — ak majú fyzické servery IPMI tohto samostatný port (alebo zdieľaný port, ale to nie je podstatné), tak virtuálne stroje nemajú takéto porty. Tu nám na pomoc prichádza obrat s názvom vbmc — nástroj, ktorý umožňuje emulovať port IPMI. Na túto nuansu by sa mali obzvlášť zamerať tí, ktorí by chceli nastaviť takéto laboratórium na hypervízore ESXI — samozrejme, neviem, či v ňom existuje ekvivalent vbmc, preto by som sa týmto problémom mal zaoberať predtým, ako všetko rozmiestniť.
Inštalujeme vbmc:
yum install python2-virtualbmcAk vaša OS nemôže nájsť balík, pridajte repozitár:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmTeraz nastavíme nástroj. Tu je všetko triviálne. Teraz je logické, že v zozname vbmc nie sú žiadne servery.
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Aby sa objavili, je potrebné ich ručne vyhlásiť 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 | vypnuté | :: | 7004 |
| compute-2 | vypnuté | :: | 7005 |
| control-1 | vypnuté | :: | 7001 |
| storage-1 | vypnuté | :: | 7002 |
| storage-2 | vypnuté | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Myslím, že syntax príkazu je jasný aj bez vysvetlení. Avšak zatiaľ sú všetky naše relácie v stave DOWN. Aby prešli do stavu UP, je potrebné ich zapnúť:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Spustená inštancia vBMC pre doménu control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Spustená inštancia vBMC pre doménu storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Spustená inštancia vBMC pre doménu storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Spustená inštancia vBMC pre doménu compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Spustená inštancia vBMC pre doménu compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Názov domény | Stav | Adresa | Port |
+-------------+---------+---------+------+
| compute-1 | beží | :: | 7004 |
| compute-2 | beží | :: | 7005 |
| control-1 | beží | :: | 7001 |
| storage-1 | beží | :: | 7002 |
| storage-2 | beží | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#A posledným krokom je úprava pravidiel firewallu (alebo jeho úplné vypnutie):
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 sa prihlásime do undercloud a skontrolujeme, že všetko funguje. Adresa hostiteľskej stroje 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
Napájanie šasi je vypnuté
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Ovládanie napájania šasi: Zapnúť
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Názov Stav
----------------------------------------------------
6 dns-server beží
64 undercloud beží
65 control-1 bežíAko vidíte, úspešne sme spustili control uzol cez vbmc. Teraz ho vypneme a prejdeme ďalej:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Ovládanie napájania šasi: Vypnúť
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Napájanie šasi je vypnuté
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Názov Stav
----------------------------------------------------
6 dns-server beží
64 undercloud beží
- compute-1 vypnuté
- compute-2 vypnuté
- control-1 vypnuté
- storage-1 vypnuté
- storage-2 vypnuté
[root@hp-gen9 ~]#Ďalším krokom je introspekcia uzlov, na ktoré bude inštalovaný overcloud. Na to potrebujeme pripraviť json súbor s popisom našich uzlov. Všimnite si, že na rozdiel od inštalácie na holé servery je v súbore uvedený port, na ktorom je spustený vbmc pre každé z strojov.
[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: na kontrolnom uzle sú dva rozhrania, ale v tomto prípade to nie je dôležité, v tejto inštalácii nám stačí aj jedno.
Teraz pripravíme súbor json. Musíme zadať MAC adresu portu, cez ktorý sa bude realizovať provisioning, parametre uzlov, určiť im mená a uviesť, ako sa pripojiť na 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ť obrazy pre Ironic. Na to ich stiahneme cez wget a nainštalujeme:
(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ávame obrazy do undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~\/images\/\nObrázok "overcloud-full-vmlinuz" bol nahraný.\n+--------------------------------------+------------------------+-------------+---------+--------+\n| ID | Názov | Diskový formát | Veľkosť | Status |\n+--------------------------------------+------------------------+-------------+---------+--------+\n| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | aktívny |\n+--------------------------------------+------------------------+-------------+---------+--------+\nObrázok "overcloud-full-initrd" bol nahraný.\n+--------------------------------------+-----------------------+-------------+----------+--------+\n| ID | Názov | Diskový formát | Veľkosť | Status |\n+--------------------------------------+-----------------------+-------------+----------+--------+\n| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | aktívny |\n+--------------------------------------+-----------------------+-------------+----------+--------+\nObrázok "overcloud-full" bol nahraný.\n+--------------------------------------+----------------+-------------+------------+--------+\n| ID | Názov | Diskový formát | Veľkosť | Status |\n+--------------------------------------+----------------+-------------+------------+--------+\n| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | aktívny |\n+--------------------------------------+----------------+-------------+------------+--------+\nObrázok "bm-deploy-kernel" bol nahraný.\n+--------------------------------------+------------------+-------------+---------+--------+\n| ID | Názov | Diskový formát | Veľkosť | Status |\n+--------------------------------------+------------------+-------------+---------+--------+\n| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | aktívny |\n+--------------------------------------+------------------+-------------+---------+--------+\nObrázok "bm-deploy-ramdisk" bol nahraný.\n+--------------------------------------+-------------------+-------------+-----------+--------+\n| ID | Názov | Diskový formát | Veľkosť | Status |\n+--------------------------------------+-------------------+-------------+-----------+--------+\n| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | aktívny |\n+--------------------------------------+-------------------+-------------+-----------+--------+\n(undercloud) [stack@undercloud ~]$Kontrolujeme, že všetky obrazy sa nahrali
(undercloud) [stack@undercloud ~]$ openstack image list\n+--------------------------------------+------------------------+--------+\n| ID | Názov | Status |\n+--------------------------------------+------------------------+--------+\n| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aktívny |\n| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | aktívny |\n| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | aktívny |\n| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | aktívny |\n| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aktívny |\n+--------------------------------------+------------------------+--------+\n(undercloud) [stack@undercloud ~]$Ďalším krokom je pridať DNS server:
(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 zadať príkaz na introspekciu:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Spustený Mistral Workflow tripleo.baremetal.v1.register_or_update. ID vykonávania: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Čakáme na správy v queue 'tripleo' bez časového limitu.
5 uzlov bolo úspešne presunutých do stavu "manageable".
Úspešne registrovaný uzol UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Úspešne registrovaný uzol UUID b89a72a3-6bb7-429a-93bc-48393d225838
Úspešne registrovaný uzol UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Úspešne registrovaný uzol UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Úspešne registrovaný uzol UUID 766ab623-464c-423d-a529-d9afb69d1167
Čakáme na dokončenie introspekcie...
Spustený Mistral Workflow tripleo.baremetal.v1.introspect. ID vykonávania: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Čakáme na správy v queue 'tripleo' bez časového limitu.
Introspekcia uzla b89a72a3-6bb7-429a-93bc-48393d225838 bola dokončená. Stav:SUCCESS. Chyby:Žiadne
Introspekcia uzla 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e bola dokončená. Stav:SUCCESS. Chyby:Žiadne
Introspekcia uzla bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 bola dokončená. Stav:SUCCESS. Chyby:Žiadne
Introspekcia uzla 766ab623-464c-423d-a529-d9afb69d1167 bola dokončená. Stav:SUCCESS. Chyby:Žiadne
Introspekcia uzla b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 bola dokončená. Stav:SUCCESS. Chyby:Žiadne
Úspešne introspektované 5 uzlov.
Spustený Mistral Workflow tripleo.baremetal.v1.provide. ID vykonávania: f5594736-edcf-4927-a8a0-2a7bf806a59a
Čakáme na správy v queue 'tripleo' bez časového limitu.
5 uzlov bolo úspešne presunutých do stavu "available".
(undercloud) [stack@undercloud ~]$Ako vidno z výstupu, všetko sa skončilo bez chýb. Skontrolujeme, či sú všetky uzly v stave available:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Názov | UUID inštancie | Stav napájania | Stav provisioning | Údržba |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | vypnutý | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | vypnutý | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | vypnutý | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | vypnutý | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | vypnutý | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Ak uzly budú v inom stave, zvyčajne manageable, niečo nefungovalo správne a treba sa pozrieť do logu, aby sme zistili, prečo to takto dopadlo. Majte na pamäti, že v tomto scenári používame virtualizáciu a môžu sa vyskytnúť chyby spojené s využívaním virtuálnych strojov alebo vbmc.
Ďalej musíme uviesť, akú funkciu bude každý uzol vykonávať — teda zadať profil, s ktorým bude uzol nasadený:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| UUID uzla | Názov uzla | Stav poskytovania | Aktuálny profil | Možné profily |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | k dispozícii | Žiadny | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | k dispozícii | Žiadny | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | k dispozícii | Žiadny | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | k dispozícii | Žiadny | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | k dispozícii | Žiadny | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Názov | RAM | Disk | Ephemeral | VCPUs | Je verejný |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | Áno |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | Áno |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | Áno |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | Áno |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | Áno |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | Áno |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Určujeme 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-d9afb69d1167Kontrolujeme, či sme všetko urobili 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, zadá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 qemuPri skutočnej inštalácii sa samozrejme použijú prispôsobené šablóny, v našom prípade to však veľmi skomplikuje proces, pretože bude potrebné vysvetliť každú úpravu v šablóne. Ako už bolo povedané, aj jednoduchá inštalácia nám bude stačiť na to, aby sme videli, ako to funguje.
Poznámka: premenná --libvirt-type qemu je v tomto prípade nevyhnutná, pretože budeme používať nested virtualizáciu. Inak sa vám nezobrazia virtuálne stroje.
Teraz máte asi hodinu, alebo aj dlhšie (záleží na možnostiach hardvéru) a môžete len dúfať, že po uplynutí tohto času uvidíte nasledujúci text:
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 sa môžete učiť, robiť experimenty atď.
Skontrolujeme, či všetko normálne funguje. V domácom adresári používateľa stack sú dva súbory - jeden stackrc (na správu undercloud) a druhý overcloudrc (na správu overcloud). Tieto súbory je potrebné zadať ako source, pretože obsahujú potrebné informácie na autentifikáciu.
(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 ~]$V mojej inštalácii ešte chýba jeden malý detail — pridať trasu na kontroléri, pretože stroj, z ktorého pracujem, sa nachádza v inej sieti. Na to sa prihlásime na control-1 s účtom heat-admin a zapíšeme trasu.
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Posledný prístup: Pi Aug 14 09:47:40 2020 z 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.254A teraz sa môžete prihlásiť do horizontu. Všetky informácie — adresy, prihlasovacie údaje a heslo — sú uložené v súbore /home/stack/overcloudrc. Konečná schéma vyzerá nasledovne:
Mimochodom, v našej inštalácii boli adresy strojov pridelené cez DHCP a, ako vidíte, sú pridelené „náhodne“. Môžete v šablóne pevne zadať, ktorú adresu má každý stroj priradiť počas nasadenia, ak je to potrebné.
Ako prechádza prevádzka medzi virtuálnymi strojmi?
V tomto článku preskúmame tri možnosti prenosu prevádzky
- Dve stroje na jednom hypervízore v jednej L2 sieti
- Dve stroje na rôznych hypervízoroch v jednej L2 sieti
- Dve stroje v rôznych sieťach (s meraním medzi sieťami)
Prípady s pripojením do vonkajšieho sveta cez externú sieť, s využitím plávajúcich adries, ako aj distribuovanú routingu, preskúmame nabudúce, zatiaľ sa zameriame na vnútornú prevádzku.
Na overenie zhromážďujeme nasledujúcu schému:
Vytvorili sme 4 virtuálne stroje — 3 v jednej L2 sieti — net-1 a jeden 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 | AKTÍVNY | - | Beží | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | AKTÍVNY | - | Beží | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | AKTÍVNY | - | Beží | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | AKTÍVNY | - | Beží | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Pozrime sa, na ktorých hypervízoroch sú umiestnené vytvorené stroje:
(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 ~]$
Virtuálne 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č na umožnenie smerovania medzi uvedený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é slúžia 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, ako sa správa prevádzka, poďme sa pozrieť, čo máme v súčasnosti na riadiacom uzle (ktorý je zároveň aj sieťovým uzlom) a na uzle compute. Začneme uzlom compute.
[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 v node existujú tri ovs bridže — br-int, br-tun, br-ex. Medzi nimi, ako vidíme, je súbor rozhraní. Na zjednodušenie vnímania znázorníme všetky tieto rozhrania na schéme a pozrieme sa, čo z toho vyjde.
Na adresách, na ktorých sú vytvorené VxLAN tunely, vidíme, že jeden tunel je vytvorený na compute-1 (192.168.255.26) a druhý na control-1 (192.168.255.15). Avšak najzaujímavejšie je, že br-ex nemá žiadne fyzické rozhrania, a ak sa pozrieme, aké toky sú nastavené, vidíme, že tento bridž v súčasnosti môže len odmietať prevádzku.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
d eth0: flags=4163 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
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 je vidno z výstupu, adresa je priradená priamo na fyzický port, a nie na virtuálny bridžový rozhraní.
[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 je potrebné všetko, čo prišlo z portu phy-br-ex, odmietnuť.
Vlastne do tohto bridža momentálne nemôže prichádzať prevádzka z iného miesta, okrem tohto rozhrania (prepojenia s br-int), a súdiac podľa odmietania, do bridža už prichádzala BUM prevádzka.
To znamená, že z tejto nody môže odísť prevádzka iba cez VxLAN tunel a nijak inak. Avšak ak aktivujete DVR, situácia sa zmení, ale to si vysvetlíme inokedy. Pri využívaní izolácie sietí, napríklad pomocou VLAN-ov, budete mať nie jeden L3 rozhranie vo VLAN 0, ale viacero rozhraní. Prevádzka VxLAN však bude vychádzať z nody presne takisto, ale ešte aj zabalená v nejakom vyhradenom VLAN-e.
S compute nodou sme sa vyrovnali, prechádzame na control nodu.
[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 ostáva rovnaké, avšak IP adresa už nie je na fyzickom rozhraní, ale na virtuálnom brídži. To sa robí preto, že tento port je portom, cez ktorý bude odchádzať prevádzka do vonkajšieho sveta.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163 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
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 pripojený k brídžu br-ex a keďže na ňom nie sú žiadne VLAN tagy, tento port je trunkový port, na ktorom sú povolené všetky VLAN-y, teraz prevádzka odchádza von bez tagu, čo naznačuje VLAN-id 0 vo vyššie uvedenom výstupe.
Všetko ostatné je v súčasnosti rovnaké ako na compute node — tie isté brídže, tie isté tunely, ktoré idú na dve compute nody.
O skladových uzloch sa v tomto článku nezmiňujeme, ale pre pochopenie je potrebné povedať, že sieťová časť týchto uzlov je mimoriadne jednoduchá. V našom prípade je tam iba jeden fyzický port (eth0) s priradenou IP adresou, a to je všetko. Nie sú tam žiadne VxLAN tunely, tunelové mosty atď. — proste tam nie je OVS, pretože to nemá zmysel. Pri použití izolácie sietí sa na tomto uzle objavia dva rozhrania (fyzické porty, VLANy, alebo jednoducho dva VLAN-y — na tom nezáleží — závisí od toho, čo chcete) — jedno na správu, druhé na prenos (zápis na disk VM, čítanie z disku atď.).
Rozobrali sme, čo máme na uzloch bez akýchkoľvek služieb. Teraz spustíme 4 virtuálne stroje a pozrieme sa, ako sa zmení vyššie opísaná schéma — mali by sme mať porty, virtuálne smerovače atď.
Naša sieť zatiaľ vyzerá takto:
Máme po dve virtuálne stroje na každom počítačovom uzle. Na príklade compute-0 sa pozrieme, ako je všetko pripojené.
[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á len 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 smeruje do linuxového mosta:
[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 je vidieť z výstupu, v moste sú iba dve rozhrania — tap95d96a75-a0 a qvb95d96a75-a0.
Tu sa krátko zastavíme pri typoch virtuálnych sieťových zariadení v OpenStack:
vtap — virtuálne rozhranie pripojené k inštancii (VM)
qbr — Linuxový most
qvb a qvo — vEth pár pripojený k Linuxovému mostu a Open vSwitch mostu
br-int, br-tun, br-vlan — Open vSwitch mosty
patch-, int-br-, phy-br- — Open vSwitch patchové rozhrania, ktoré spájajú mosty
qg, qr, ha, fg, sg — porty Open vSwitch, ktoré používajú virtuálne zariadenia na pripojenie k OVS
Ako chápete, ak máme v bridži port qvb95d96a75-a0, ktorý je parou vEth, potom niekde musí byť jeho zodpovedajúca strana, ktorá by logicky mala byť nazvaná 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, port sa nachádza v br-int. Br-int zohráva úlohu prepínača, ktorý terminujú porty virtuálnych strojov. Okrem qvo95d96a75-a0 je vo výstupe viditeľný port qvo5bd37136-47. Ide o port pre druhý virtuálny stroj. Nakoniec naša schéma teraz vyzerá takto:
Otázka, ktorá by mala okamžite zaujať pozorného čitateľa — prečo je medzi portom virtuálneho stroja a portom OVS linux bridge? Pretože na ochranu stroja sa používajú bezpečnostné skupiny, ktoré nie sú ničím iným ako iptables. OVS nefunguje s iptables, a preto bol vymyslený tento "kostrč". Avšak už je naozaj nevyhnutné, aby bol nahradený conntrack v nových verziach.
Takže v konečnom dôsledku schéma vyzerá takto:
Dve stroje na jednom hypervízore v jednej L2 sieti
Keďže dva virtuálne stroje sa nachádzajú v tej istej L2 sieti a na rovnakom hypervízore, bude logické, že prevádzka medzi nimi pôjde lokálne cez br-int, pretože obe stroje budú v rovnakom 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 ~]$ Dve stroje na rôznych hypervízoroch v jednej L2 sieti
Teraz sa pozrime, ako bude prebiehať prevádzka medzi dvoma strojmi v jednej L2 sieti, ale umiestnenými na rôznych hypervízoroch. Aby som bol úprimný, veľa sa nezmení, jednoducho prevádzka medzi hypervízormi pôjde cez vxlan tunel. Pozrime sa na príklade.
Adresa virtuálnych strojov, medzi ktorými budeme sledovať traffic:
[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 ~]$ Sledujeme forwarding tabuľku 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 ~]Traffic by mal ísť do portu 2 – pozrime sa, čo je to za port:
[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-tun. Pozrime sa, čo sa deje s paketom 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 ~]$ Packet je zabalený do VxLAN a poslaný do portu 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 vxlan tunel 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 ~]$Ideme na compute-1 a pozrieme sa, čo sa ďalej deje s paketom:
[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 forwarding tabuľke br-int na compute-1, a ako je vidieť z výstupu vyššie, je viditeľný cez port 2, ktorý je portom smerom na 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:46A pokračujeme ďalej a pozrieme sa, čo je v br-int na compute-1, kde je MAC adresy cieľa:
[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 pôjde do portu 3, za ktorým sa nachádza virtuálny stroj instance-00000003.
Celá krása nasadenia Openstack na štúdium vo virtuálnej infraštruktúre spočíva v tom, že môžeme bez problémov sledovať prenosy medzi hypervízormi a pozrieť sa, čo sa s nimi deje. To je presne to, čo teraz urobíme, spustíme tcpdump na vnet porte smerom k compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: počúvanie na vnet3, typ odkazu EN10MB (Ethernet), veľkosť zachytenia 262144 bajtov
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), dĺžka 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flagy [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), dĺžka 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, dĺžka 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), dĺžka 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flagy [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), dĺžka 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, dĺžka 64
*****************omitted*******************Prvý riadok ukazuje, že paket s adresou 10.0.1.85 ide na adresu 10.0.1.88 (ICMP prenos), pričom je zabalený v balíku VxLAN s vni 22 a paket ide z hosta 192.168.255.19 (compute-0) na hosta 192.168.255.26 (compute-1). Môžeme overiť, že VNI zodpovedá tomu, ktorý je uvedený v ovs.
Vrátime sa k tomuto riadku actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 — to je vni v hexadecimálnom systéme. Prevedieme toto číslo do desiatkovej sústavy:
16 = 6*16^0+1*16^1 = 6+16 = 22To znamená, že vni zodpovedá realite.
Druhý riadok ukazuje spätný prenos, ale nie je potrebné ho vysvetľovať, tam je všetko jasné.
Dve mašiny v rôznych sieťach (routing medzi sieťami)
Posledný prípad dnes — to je routing medzi sieťami v rámci jedného projektu s použitím virtuálneho smerovača. Zvažujeme prípad bez DVR (ten preskúmame v inom článku), preto routing prebieha na network node. V našom prípade network node nie je vyčleněná do samostatnej entity a nachádza sa na control node.
Na začiatok sa pozrime, či routing funguje:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 dátových bajtov
64 bajtov od 10.0.2.8: seq=0 ttl=63 čas=7.727 ms
64 bajtov od 10.0.2.8: seq=1 ttl=63 čas=3.832 ms
^C
--- štatistika ping 10.0.2.8 ---
2 pakety odoslané, 2 pakety prijaté, 0% strata paketov
round-trip min/avg/max = 3.832/5.779/7.727 msKeďže v tomto prípade by mal paket ísť na bránu a tam byť smerovaný, potrebujeme zistiť MAC adresu brány, preto sa pozrieme na ARP tabuľku 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 pozrieme, kam by mal byť smerovaný traffic na adresu (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 ~]$ Je to jasné, traffic odchádza do br-tun. Pozrime sa, do ktorého vxlan tunela 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í port je vxlan tunel:
[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ý smeruje na kontrolnú 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 ~]$ Traffic dorazil na kontrolnú uzol, preto musíme prejsť na ňu a pozrieť sa, ako bude prebiehať smerovanie.
Ako si pamätáte, kontrolná uzol vyzerala zvnútra rovnako ako compute uzol — tie isté tri mosty, len br-ex mal fyzický port, cez ktorý uzol mohla posielať traffic von. Vytvorenie inštancií zmenilo konfiguráciu na compute uzloch — pridali sa linux bridge, iptables a rozhrania na uzly. Vytvorenie sietí a virtuálneho smerovača tiež zanechalo svoj odtlačok na konfigurácii kontrolného uzla.
Takže je zrejmé, že MAC adresa gateway by mala byť v smerovacej tabuľke br-int na kontrolnej uzle. Overíme, či tam je a kam smeruje:
[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 späť k zoznamu virtuálnych portov v OpenStacku, tento typ portu sa používa na pripojenie k OVS rôznych virtuálnych zariadení. Ak chceme byť presnejší, qr je port smerom k virtuálnemu smerovaču, ktorý sa predstavuje ako namespace.
Pozrime sa, aké namespace 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 ~]$ Sú až tri inštancie. Ale podľa mien môžeme 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 namespace 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 ~]$ V tomto namespace sú dve interné, ktoré sme vytvorili predtým. Oba virtuálne porty sú pridané do br-int. Skontrolujme MAC adresu portu qr-0c52b15f-8f, pretože podľa MAC adresy cieľa išiel práve na tento 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 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
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 pravidiel štandardného smerovania. Keďže je premávka určená hostiteľovi 10.0.2.8, mala by ísť cez druhé rozhranie qr-92fa49b5-54 a odísť cez VXLAN tunel na compute uzol:
[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, odkiaľ je viditeľná MAC 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 patrí, premávka ide do br-tun, pozrime sa, do ktorého tunela pôjde ďalej:
[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 ~]$ Prevádzka ide do tunela k compute-1. A na compute-1 je to jednoduché — z br-tun balík prechádza do br-int a odtiaľ do rozhrania virtuálneho stroja:
[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 ~]$ Oververíme, že je to naozaj 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 ~]$ Prešli sme celú cestu balíka. Myslím, že ste si všimli, že prevádzka išla cez rôzne vxlan tunely a vychádzala s rôznymi VNI. Pozrime sa, aké to VNI sú, potom zhromaždíme dump na porte control node a uistíme sa, že prevádzka ide presne tak, ako je opísané vyššie.
Takže, tunel do compute-0 má nasledujúce actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Premeníme 0x16 na desiatkový systém:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunel do compute-1 má nasledujúci VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Premeníme 0x63 na desiatkový systém:
0x63 = 3*16^0+6*16^1 = 3+96 = 99A teraz sa pozrime na dump:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: počúvanie na vnet4, typ linky EN10MB (Ethernet), veľkosť zachytnutia 262144 bajtov
*****************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 požiadavka, 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 požiadavka, 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 odpoveď, 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 odpoveď, id 5378, seq 9, length 64
*****************omitted*******************Prvý paket je vxlan paket z hosta 192.168.255.19 (compute-0) na hosta 192.168.255.15 (control-1) s vni 22, v ktorom je zabalený ICMP paket z hosta 10.0.1.85 na hosta 10.0.2.8. Ako sme už počítali vyššie, vni zodpovedá tomu, čo sme videli vo výstupoch.
Druhý paket je vxlan paket z hosta 192.168.255.15 (control-1) na hosta 192.168.255.26 (compute-1) s vni 99, v ktorom je zabalený ICMP paket z hosta 10.0.1.85 na hosta 10.0.2.8. Ako sme už počítali vyššie, vni zodpovedá tomu, čo sme videli vo výstupoch.
Dva nasledujúce pakety sú spätný traffic z 10.0.2.8 na 10.0.1.85.
Teda nakoniec máme takúto schému kontrolnej uzly:
Zdá sa, že je všetko? Zabudli sme na dva namespace:
[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 ~]$ Ako sme už hovorili o architektúre cloudovej platformy – bolo by dobré, aby stroje dostávali adresy automaticky od DHCP servera. To sú dva DHCP servery pre naše dve siete 10.0.1.0/24 a 10.0.2.0/24.
Skontrolujeme, či je to tak. V tomto namespace je len jedna adresa – 10.0.1.1 – adresa samotného DHCP servera, a ten je taktiež zahrnutý v br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
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 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
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 existujú procesy s názvom qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 na kontrolnom 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í z vyššie uvedeného výstupu môžeme napríklad zistiť, čo máme momentálne v prenájme:
[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 ~]$Na konci dostaneme takýto súbor služieb na kontrolnom uzle:
Majte na pamäti, že ide len o 4 stroje, 2 vnútorné siete a jeden virtuálny smerovač... Momentálne tu nemáme žiadne vonkajšie siete, množstvo rôznych projektov, každý so svojimi (prekryvajúcimi sa) sieťami, a máme vypnutý distribuovaný smerovač. A na koniec koncov, v testovacom prostredí bola len jedna kontrolná uzol (na zaručenie odolnosti musí byť kvorum z troch uzlov). Je logické, že v komerčnej sfére je všetko „trochu“ zložitejšie, ale na tomto jednoduchom príklade chápeme, ako to má fungovať — či už máte 3 alebo 300 názvových priestorov, je to určite dôležité, ale z pohľadu fungovania celej konštrukcie sa toho veľa nezmení... pravda, pokiaľ tam nezapojíte nejaký dodávateľský SDN. Ale to je už úplne iný príbeh.
Dúfam, že to bolo zaujímavé. Ak máte pripomienky/doplnenia, alebo ak som niekde otvorene 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 rád povedal pár slov o porovnaní OpenStack (ako vanilkového, tak aj dodávateľských) s cloudovým riešením od spoločnosti VMWare — túto otázku mi kladli mnohí posledné dva roky a úprimne povedané, začínam byť unavený, ale predsa. Podľa môjho názoru je ťažké tieto dve riešenia porovnať, no dá sa jednoznačne povedať, že nevýhody sú v oboch riešeniach a pri výbere jedného z nich je potrebné zvážiť všetky klady a zápory.
Ak je OpenStack komunitne riadeným riešením, potom VMWare má právo robiť len to, čo chce (čítajte — čo je pre ňu výhodné) a to je logické — veď je to komerčná spoločnosť, ktorá je zvyknutá zarábať peniaze na svojich klientoch. Ale tu je jedno veľké a tučné ALE — môžete prejsť z OpenStack napríklad od Nokia a bez veľkých problémov prejsť na riešenie od napríklad Juniper (Contrail Cloud), ale prechod z VMWare by Vám asi nevyšiel. Pre mňa tieto dve riešenia vyzerajú takto — OpenStack (dodávateľský) je jednoduchá klietka, do ktorej vás zavrú, ale máte kľúč a môžete kedykoľvek odísť. VMWare — to je zlatá klietka, kľúč od klietky má majiteľ a bude vás to stáť veľa peňazí.
Nebránim ani jednomu produktu, ani druhému — vy si vyberete to, čo potrebujete. Ak by som však mal takú možnosť, zvolil by som obidve riešenia — VMWare pre IT cloud (malé zaťaženie, pohodlné ovládanie), OpenStack od niektorého dodávateľa (Nokia a Juniper ponúkajú veľmi solídne riešenia na kľúč) — pre telekomunikáčný cloud. Neodporúčal by som používať OpenStack pre čisté IT — to je ako strieľať z dela na vrabca, ale nevidím žiadne kontraindikácie pre jeho použitie, okrem nadbytočnosti. Ale používať VMWare v telekomunikáciách — to je ako prevážať kamenivo v Ford Raptor — vyzerá to dobre, ale vodič musí urobiť 10 jázd namiesto jednej.
Podľa môjho názoru je najväčším nedostatkom VMWare jej úplná uzavretosť — spoločnosť vám neposkytne žiadne informácie o tom, ako je napríklad vSAN alebo čo je vo vnútri hypervízora — nie je to pre ňu výhodné — to znamená, že sa nikdy nestanete expertom na VMWare — bez podpory dodávateľa ste odsúdení na neúspech (veľmi často stretávam expertov na VMWare, ktorí sú zúfalí z banálnych otázok). Pre mňa je VMWare ako nákup auta s uzamknutým kapotom — áno, možno máte odborníkov, ktorí dokážu vymeniť rozvodový remeň, ale kapotu otvorí len ten, kto vám to riešenie predal. Osobne nemám rád riešenia, do ktorých sa nemôžem ponoriť. Povedali by ste, že možno nebudete musieť ísť pod kapotou. Áno, to je možné, ale pozriem sa na vás, keď budete musieť zostaviť v cloude veľkú funkciu z 20-30 virtuálnych strojov, 40-50 sietí, polovica z nich chce ísť von, a druhá polovica žiada SR-IOV akceleráciu, inak budete musieť mať ešte pár desiatok takýchto strojov — inak nebude výkon dostatočný.
Existujú aj iné názory, preto je to len na vás, čo si vyberiete, a najdôležitejšie — vy budete za svoj výber neskôr zodpovedať. Toto je len môj názor — človeka, ktorý videl a dotýkal sa aspoň štyroch produktov — Nokia, Juniper, Red Hat a VMWare. To znamená, že mám s čím porovnávať.
Zdroj: habr.com
