Cloud computing proniká stále hlouběji do našich životů a snad neexistuje jediný člověk, který by alespoň jednou nevyužil žádnou cloudovou službu. Co to však cloud přesně je a jak funguje, ví málokdo, a to i na úrovni nápadu. 5G se již stává realitou a telekomunikační infrastruktura se začíná přesouvat od pólových řešení ke cloudovým řešením, stejně jako tomu bylo, když přecházela od plně hardwarových řešení k virtualizovaným „pilířům“.
Dnes si povíme něco o vnitřním světě cloudové infrastruktury, konkrétně se podíváme na základy síťové části.
co je to cloud? Stejná virtualizace - zobrazení profilu?
Více než logická otázka. Ne – nejde o virtualizaci, i když bez ní by to nešlo. Podívejme se na dvě definice:
Cloud computing (dále jen cloud) je model pro poskytování uživatelsky přívětivého přístupu k distribuovaným výpočetním zdrojům, které je nutné nasadit a spustit na vyžádání s co nejnižší latencí a minimálními náklady pro poskytovatele služeb.
Virtualizace - jedná se o možnost rozdělit jednu fyzickou entitu (například server) na několik virtuálních, čímž se zvýší využití zdrojů (například jste měli 3 servery zatížené na 25-30 procent, po virtualizaci získáte načtený 1 server na 80-90 procentech). Virtualizace přirozeně spotřebovává některé zdroje - musíte nakrmit hypervizor, ale jak ukázala praxe, hra stojí za svíčku. Ideálním příkladem virtualizace je VMWare, který skvěle připraví virtuální stroje, nebo třeba KVM, které preferuji, ale to je věc vkusu.
Používáme virtualizaci, aniž bychom si to uvědomovali, a dokonce i železné routery již virtualizaci používají – například v nejnovější verzi JunOS je operační systém nainstalován jako virtuální stroj nad real-time distribucí Linuxu (Wind River 9). Ale virtualizace není cloud, ale cloud nemůže existovat bez virtualizace.
Virtualizace je jedním ze stavebních kamenů, na kterých je cloud postaven.
Vytvoření cloudu jednoduchým shromažďováním několika hypervizorů do jedné domény L2, přidáním několika yaml playbooků pro automatickou registraci vlan prostřednictvím nějakého druhu ansible a umístěním něčeho jako orchestračního systému pro automatické vytváření virtuálních strojů nebude fungovat. Bude to přesnější, ale výsledný Frankenstein není cloud, který bychom potřebovali, i když pro ostatní to může být konečný sen. Navíc, pokud si vezmete stejný Openstack, je to v podstatě stále Frankenstein, ale dobře, o tom teď nemluvme.
Ale chápu, že z výše uvedené definice není úplně jasné, co vlastně lze nazvat cloudem.
Proto dokument od NIST (Národní institut pro standardy a technologie) poskytuje 5 hlavních charakteristik, které by cloudová infrastruktura měla mít:
Poskytování servisu na vyžádání. Uživateli musí být umožněn volný přístup ke zdrojům počítače, které jsou mu přiděleny (jako jsou sítě, virtuální disky, paměť, procesorová jádra atd.), a tyto prostředky musí být poskytovány automaticky – tedy bez zásahu poskytovatele služby.
Široká dostupnost služby. Přístup ke zdrojům musí být zajištěn standardními mechanismy, aby bylo možné používat jak standardní počítače, tak tenké klienty a mobilní zařízení.
Kombinování zdrojů do skupin. Fondy zdrojů musí být schopny poskytovat zdroje více klientům současně a zajistit, aby klienti byli izolovaní a bez vzájemného vlivu a soupeření o zdroje. Do poolů jsou zahrnuty i sítě, což naznačuje možnost použití překrývajícího se adresování. Bazény musí být možné škálovat na požádání. Použití poolů umožňuje poskytnout potřebnou úroveň odolnosti proti chybám zdrojů a abstrakci fyzických a virtuálních zdrojů - příjemci služby je jednoduše poskytnuta sada zdrojů, které požadoval (kde se tyto zdroje fyzicky nacházejí, na kolik servery a přepínače - na klientovi nezáleží). Musíme však počítat s tím, že poskytovatel musí zajistit transparentní rezervaci těchto zdrojů.
Rychlé přizpůsobení různým podmínkám. Služby musí být flexibilní – rychlé poskytování zdrojů, jejich přerozdělování, přidávání či snižování zdrojů na přání klienta a ze strany klienta by měl být pocit, že cloudových zdrojů je neúrekom. Pro snazší pochopení například nevidíte varování, že část vašeho místa na disku v Apple iCloud zmizela, protože se porouchal pevný disk na serveru a disky se porouchají. Navíc z vaší strany jsou možnosti této služby téměř neomezené - potřebujete 2 TB - žádný problém, zaplatili jste a dostali. Podobný příklad lze uvést s Google.Drive nebo Yandex.Disk.
Možnost měření poskytované služby. Cloudové systémy musí automaticky řídit a optimalizovat spotřebovávané zdroje a tyto mechanismy musí být transparentní pro uživatele i poskytovatele služeb. To znamená, že vždy můžete zkontrolovat, kolik zdrojů vy a vaši klienti spotřebováváte.
Za zvážení stojí fakt, že tyto požadavky jsou většinou požadavky na veřejný cloud, takže u privátního cloudu (tedy cloudu spuštěného pro interní potřeby firmy) lze tyto požadavky mírně upravit. Musí se však ještě provést, jinak nezískáme všechny výhody cloud computingu.
Proč potřebujeme cloud?
Nicméně každá nová nebo existující technologie, jakýkoli nový protokol je vytvořen pro něco (no, samozřejmě kromě RIP-ng). Nikdo nepotřebuje protokol kvůli protokolu (samozřejmě kromě RIP-ng). Je logické, že Cloud je vytvořen za účelem poskytování nějaké služby uživateli/klientovi. Všichni známe alespoň pár cloudových služeb, například Dropbox nebo Google.Docs, a věřím, že většina lidí je úspěšně používá – například tento článek byl napsán pomocí cloudové služby Google.Docs. Ale cloudové služby, které známe, jsou jen částí schopností cloudu – přesněji řečeno, jsou to pouze služby typu SaaS. Cloudovou službu můžeme poskytovat třemi způsoby: formou SaaS, PaaS nebo IaaS. Jakou službu potřebujete, závisí na vašich přáních a schopnostech.
Podívejme se na každý v pořadí:
Software jako služba (SaaS) je modelem pro poskytování plnohodnotné služby klientovi, například e-mailové služby jako Yandex.Mail nebo Gmail. V tomto modelu poskytování služeb vy jako klient vlastně neděláte nic jiného než služby využíváte – to znamená, že nemusíte přemýšlet o nastavení služby, její chybovosti či redundanci. Hlavní je neprolomit heslo, zbytek za vás udělá poskytovatel této služby. Z pohledu poskytovatele služby je plně zodpovědný za celou službu - od serverového hardwaru a hostitelských operačních systémů až po nastavení databáze a softwaru.
Platforma jako služba (PaaS) — při použití tohoto modelu poskytuje poskytovatel služby klientovi obrobek pro službu, vezměme například webový server. Poskytovatel služby poskytl klientovi virtuální server (ve skutečnosti sadu zdrojů, jako je RAM/CPU/Storage/Nets atd.), a dokonce na tento server nainstaloval OS a potřebný software, nicméně konfigurace všechny tyto věci si provádí klient sám a za výkon služby odpovídá klient. Poskytovatel služby je stejně jako v předchozím případě zodpovědný za výkon fyzického zařízení, hypervizorů, samotného virtuálního stroje, jeho síťové dostupnosti atd., ale samotná služba již není v jeho oblasti odpovědnosti.
Infrastruktura jako služba (IaaS) - tento přístup je již zajímavější, ve skutečnosti poskytovatel služby poskytuje klientovi kompletní virtualizovanou infrastrukturu - tedy nějakou sadu (pool) zdrojů, jako jsou CPU Cores, RAM, Networks atd. Vše ostatní je na klient - co chce klient s těmito zdroji dělat v rámci přiděleného poolu (kvóty) - to není pro dodavatele zvlášť důležité. Ať už si klient chce vytvořit vlastní vEPC nebo dokonce vytvořit mini operátora a poskytovat komunikační služby - bez pochyb - udělejte to. V takovém scénáři je poskytovatel služeb odpovědný za poskytování prostředků, jejich odolnost proti chybám a dostupnost, stejně jako za operační systém, který mu umožňuje sdružovat tyto prostředky a zpřístupňovat je klientovi s možností zdroje kdykoli zvýšit nebo snížit. na žádost klienta. Všechny virtuální stroje a další pozlátka si klient konfiguruje sám přes samoobslužný portál a konzoli, včetně nastavování sítí (kromě externích sítí).
Co je OpenStack?
Ve všech třech možnostech poskytovatel služeb potřebuje OS, který umožní vytvoření cloudové infrastruktury. Ve skutečnosti je u SaaS více než jedna divize zodpovědná za celý zásobník technologií - existuje divize, která je zodpovědná za infrastrukturu - to znamená, že poskytuje IaaS jiné divizi, tato divize poskytuje SaaS klientovi. OpenStack je jeden z cloudových operačních systémů, který vám umožňuje shromáždit spoustu přepínačů, serverů a úložných systémů do jednoho fondu zdrojů, rozdělit tento společný fond do podfondů (tenantů) a poskytovat tyto prostředky klientům přes síť.
OpenStack je cloudový operační systém, který vám umožňuje ovládat velké fondy výpočetních zdrojů, datových úložišť a síťových zdrojů, zajišťovaných a spravovaných prostřednictvím API pomocí standardních ověřovacích mechanismů.
Jinými slovy, toto je sada projektů svobodného softwaru, která je navržena tak, aby vytvářela cloudové služby (veřejné i soukromé) – tedy sadu nástrojů, které vám umožňují kombinovat server a přepínací zařízení do jednoho fondu zdrojů, spravovat tyto prostředky poskytují nezbytnou úroveň odolnosti proti chybám.
V době psaní tohoto materiálu vypadá struktura OpenStack takto:
Obrázek převzat z
Každá z komponent obsažených v OpenStack plní specifickou funkci. Tato distribuovaná architektura umožňuje zahrnout do řešení sadu funkčních komponent, které potřebujete. Některé komponenty jsou však kořenovými komponentami a jejich odstranění povede k úplné nebo částečné nefunkčnosti řešení jako celku. Tyto komponenty jsou obvykle klasifikovány jako:
- Hlavní obrazovka — Webové grafické uživatelské rozhraní pro správu služeb OpenStack
- Keystone je centralizovaná služba identity, která poskytuje autentizační a autorizační funkce pro další služby a také správu uživatelských pověření a jejich rolí.
- Neutron - síťová služba, která poskytuje konektivitu mezi rozhraními různých služeb OpenStack (včetně konektivity mezi VM a jejich přístupu k vnějšímu světu)
- Škvára — poskytuje přístup k blokovému úložišti pro virtuální stroje
- Nova — správa životního cyklu virtuálních strojů
- Pohled — úložiště obrazů virtuálních strojů a snímků
- Rychlý — poskytuje přístup k objektu úložiště
- Ceilometr — služba, která poskytuje možnost shromažďovat telemetrii a měřit dostupné a spotřebované zdroje
- teplo — orchestrace založená na šablonách pro automatické vytváření a poskytování zdrojů
Kompletní seznam všech projektů a jejich účel si můžete prohlédnout .
Každá komponenta OpenStack je služba, která plní specifickou funkci a poskytuje API pro správu této funkce a interakci s dalšími cloudovými službami operačního systému za účelem vytvoření jednotné infrastruktury. Například Nova poskytuje správu výpočetních zdrojů a API pro přístup ke konfiguraci těchto zdrojů, Glance poskytuje správu obrázků a API pro jejich správu, Cinder poskytuje blokové úložiště a API pro jeho správu atd. Všechny funkce jsou velmi úzce propojeny.
Nicméně, když se na to podíváte, všechny služby běžící v OpenStacku jsou nakonec nějaký druh virtuálního stroje (nebo kontejneru) připojeného k síti. Nabízí se otázka – proč potřebujeme tolik prvků?
Pojďme si projít algoritmus pro vytvoření virtuálního stroje a jeho připojení k síti a trvalému úložišti v Openstacku.
- Když vytvoříte požadavek na vytvoření stroje, ať už je to požadavek přes Horizon (Dashboard) nebo požadavek přes CLI, první věc, která se stane, je autorizace vašeho požadavku na Keystone – můžete vytvořit stroj, má právo používat tuto síť, dělá váš koncept kvóty atd.
- Keystone ověří váš požadavek a ve zprávě s odpovědí vygeneruje ověřovací token, který bude dále používán. Po obdržení odpovědi od Keystone je požadavek odeslán do Novy (nova api).
- Nova-api zkontroluje platnost vašeho požadavku kontaktováním Keystone pomocí dříve vygenerovaného auth tokenu
- Keystone provádí ověřování a poskytuje informace o oprávněních a omezeních na základě tohoto ověřovacího tokenu.
- Nova-api vytvoří záznam pro nový VM v nova-database a předá požadavek na vytvoření počítače nova-scheduler.
- Nova-scheduler vybere hostitele (počítačový uzel), na kterém bude virtuální počítač nasazen na základě zadaných parametrů, vah a zón. Záznam o tom a VM ID jsou zapsány do nova-database.
- Dále nova-scheduler kontaktuje nova-compute s požadavkem na nasazení instance. Nova-compute kontaktuje nova-conductor, aby získal informace o parametrech stroje (nova-conductor je prvek nova, který funguje jako proxy server mezi nova-database a nova-compute, omezuje počet požadavků do nova-database, aby se předešlo problémům s databází snížení zatížení konzistence).
- Nova-conductor obdrží požadované informace z nova-database a předá je nova-compute.
- Dále nova-compute volá pohled, aby získal ID obrázku. Glace ověří požadavek v Keystone a vrátí požadované informace.
- Nova-compute kontaktuje neutron, aby získal informace o parametrech sítě. Podobně jako pohled neutron ověří požadavek v Keystone, poté vytvoří záznam v databázi (identifikátor portu atd.), vytvoří požadavek na vytvoření portu a vrátí požadované informace do nova-compute.
- Kontakty Nova-compute se rozesmějí s požadavkem na přidělení svazku virtuálnímu počítači. Podobně jako pohled, cider ověří požadavek v Keystone, vytvoří požadavek na vytvoření svazku a vrátí požadované informace.
- Nova-compute kontaktuje libvirt s požadavkem na nasazení virtuálního stroje se zadanými parametry.
Ve skutečnosti se zdánlivě jednoduchá operace vytvoření jednoduchého virtuálního stroje promění v takový kolotoč volání API mezi prvky cloudové platformy. Navíc, jak vidíte, i dříve určené služby se skládají z menších komponent, mezi kterými dochází k interakci. Vytvoření stroje je jen malá část toho, co vám cloudová platforma umožňuje – existuje služba zodpovědná za vyrovnávání provozu, služba zodpovědná za ukládání bloků, služba zodpovědná za DNS, služba zodpovědná za poskytování serverů s holýma rukama atd. Cloud umožňuje, abyste se svými virtuálními stroji zacházeli jako se stádem ovcí (na rozdíl od virtualizace). Pokud se vašemu stroji něco stane ve virtuálním prostředí – obnovíte jej ze záloh apod., ale cloudové aplikace jsou postaveny tak, že virtuální stroj nehraje tak důležitou roli – virtuální stroj „zemřel“ – žádný problém - prostě se vytvoří nové vozidlo je založeno na šabloně a jak se říká, četa nezaznamenala ztrátu stíhačky. To přirozeně zajišťuje přítomnost orchestračních mechanismů – pomocí šablon Heat můžete snadno nasadit komplexní funkci skládající se z desítek sítí a virtuálních strojů.
Vždy stojí za to mít na paměti, že neexistuje žádná cloudová infrastruktura bez sítě – každý prvek tak či onak interaguje s jinými prvky prostřednictvím sítě. Cloud má navíc absolutně nestatickou síť. Podkladová síť je přirozeně ještě víceméně statická – nové uzly a přepínače se nepřidávají každý den, ale překryvná komponenta se může a nevyhnutelně bude neustále měnit – nové sítě budou přidány nebo odstraněny, budou se objevovat nové virtuální stroje a staré budou zemřít. A jak si pamatujete z definice cloudu uvedené na samém začátku článku, zdroje by měly být uživateli přidělovány automaticky a s co nejmenším (nebo ještě lépe bez) zásahů poskytovatele služby. To znamená, že typ poskytování síťových zdrojů, který nyní existuje ve formě front-endu ve formě vašeho osobního účtu přístupného přes http/https a služebního síťového inženýra Vasilije jako backend, není cloud, dokonce ani má-li Vasilij osm rukou.
Neutron jako síťová služba poskytuje API pro správu síťové části cloudové infrastruktury. Služba pohání a spravuje síťovou část Openstacku poskytováním abstrakční vrstvy nazvané Network-as-a-Service (NaaS). To znamená, že síť je stejná virtuální měřitelná jednotka jako například virtuální jádra CPU nebo množství RAM.
Než ale přejdeme k architektuře síťové části OpenStacku, zamysleme se nad tím, jak tato síť funguje v OpenStacku a proč je síť důležitou a nedílnou součástí cloudu.
Máme tedy dva RED klientské VM a dva ZELENÉ klientské VM. Předpokládejme, že tyto stroje jsou umístěny na dvou hypervizorech tímto způsobem:
V tuto chvíli je to jen virtualizace 4 serverů a nic víc, protože zatím jsme udělali pouze virtualizaci 4 serverů a jejich umístění na dva fyzické servery. A zatím nejsou ani připojeny k síti.
Abychom vytvořili cloud, musíme přidat několik komponent. Nejprve virtualizujeme síťovou část – potřebujeme tyto 4 stroje propojit do párů a klienti chtějí L2 připojení. Můžete použít switch a nakonfigurovat trunk v jeho směru a vše vyřešit pomocí linux bridge nebo pro pokročilejšího openvswitche (k tomu se ještě vrátíme). Ale sítí může být spousta a neustálé protlačování L2 přes switch není nejlepší nápad – existují různá oddělení, service desk, měsíce čekání na dokončení aplikace, týdny řešení problémů – v moderním světě to přístup už nefunguje. A čím dříve to firma pochopí, tím snadněji se posune vpřed. Proto mezi hypervizory vybereme L3 síť, přes kterou budou naše virtuální stroje komunikovat, a nad tuto L3 síť postavíme virtuální L2 překryvné sítě, kde bude probíhat provoz našich virtuálních strojů. Jako zapouzdření můžete použít GRE, Geneve nebo VxLAN. Zaměřme se zatím na to druhé, i když to není nijak zvlášť důležité.
Potřebujeme někde najít VTEP (doufám, že každý zná terminologii VxLAN). Vzhledem k tomu, že máme síť L3 přicházející přímo ze serverů, nic nám nebrání umístit VTEP na samotné servery a OVS (OpenvSwitch) je v tom vynikající. V důsledku toho jsme dostali tento design:
Protože provoz mezi virtuálními počítači musí být rozdělen, porty směrem k virtuálním počítačům budou mít různá čísla vlan. Číslo tagu hraje roli pouze v rámci jednoho virtuálního přepínače, protože když je zapouzdřen ve VxLAN, můžeme jej snadno odstranit, protože budeme mít VNI.
Nyní pro ně můžeme bez problémů vytvářet naše stroje a virtuální sítě.
Co když má klient jiný počítač, ale je v jiné síti? Potřebujeme rootování mezi sítěmi. Podíváme se na jednoduchou možnost při použití centralizovaného směrování - to znamená, že provoz je směrován přes speciální vyhrazené síťové uzly (dobře, zpravidla jsou kombinovány s řídicími uzly, takže budeme mít totéž).
Zdá se, že to není nic složitého – na řídicím uzlu uděláme mostní rozhraní, nasměrujeme do něj provoz a odtud ho směrujeme tam, kam potřebujeme. Problém je ale v tom, že ČERVENÝ klient chce používat síť 10.0.0.0/24 a ZELENÝ klient chce používat síť 10.0.0.0/24. To znamená, že začneme protínat adresní prostory. Klienti navíc nechtějí, aby ostatní klienti mohli směrovat do jejich vnitřních sítí, což dává smysl. Abychom oddělili sítě a klientský datový provoz, přidělíme pro každou z nich samostatný jmenný prostor. Jmenný prostor je ve skutečnosti kopií linuxového síťového zásobníku, to znamená, že klienti v jmenném prostoru ČERVENÉ jsou zcela izolováni od klientů od ZELEného jmenného prostoru (dobře, směrování mezi těmito klientskými sítěmi je povoleno přes výchozí jmenný prostor nebo na přenosovém zařízení).
To znamená, že dostaneme následující diagram:
Tunely L2 se sbíhají ze všech výpočetních uzlů do řídicího uzlu. uzel, kde se nachází rozhraní L3 pro tyto sítě, každý ve vyhrazeném jmenném prostoru pro izolaci.
Na to nejdůležitější jsme však zapomněli. Virtuální stroj musí poskytovat službu klientovi, to znamená, že musí mít alespoň jedno externí rozhraní, přes které je dostupný. To znamená, že musíme jít ven do vnějšího světa. Zde jsou různé možnosti. Udělejme nejjednodušší možnost. Každému klientovi přidáme jednu síť, která bude platná v síti poskytovatele a nebude se překrývat s jinými sítěmi. Sítě se také mohou protínat a dívat se na různé VRF na straně sítě poskytovatele. Síťová data budou také žít ve jmenném prostoru každého klienta. Stále však půjdou ven do vnějšího světa přes jedno fyzické (neboli pouto, což je logičtější) rozhraní. Pro oddělení klientského provozu bude provoz směřující ven označen tagem VLAN přiděleným klientovi.
V důsledku toho jsme dostali tento diagram:
Rozumnou otázkou je, proč neudělat brány na samotných výpočetních uzlech? To není velký problém, navíc pokud zapnete distribuovaný router (DVR), bude to fungovat. V tomto scénáři zvažujeme nejjednodušší možnost s centralizovanou bránou, která se standardně používá v Openstacku. Pro funkce s vysokou zátěží využijí jak distribuovaný router, tak akcelerační technologie jako SR-IOV a Passthrough, ale jak říkají, to je úplně jiný příběh. Nejprve se vypořádáme se základní částí a pak půjdeme do detailů.
Ve skutečnosti je naše schéma již funkční, ale existuje několik nuancí:
- Musíme nějak chránit naše stroje, to znamená dát filtr na rozhraní přepínače směrem ke klientovi.
- Umožněte virtuálnímu počítači automaticky získat IP adresu, abyste se k němu nemuseli pokaždé přihlašovat přes konzoli a registrovat adresu.
Začněme ochranou stroje. K tomu můžete použít banální iptables, proč ne.
To znamená, že nyní se naše topologie trochu zkomplikovala:
Pokračujme. Potřebujeme přidat DHCP server. Nejideálnějším místem pro umístění serverů DHCP pro každého klienta by byl již výše zmíněný řídicí uzel, kde jsou umístěny jmenné prostory:
Je tu však malý problém. Co když se vše restartuje a všechny informace o pronájmu adres na DHCP zmizí. Je logické, že stroje dostanou nové adresy, což není příliš pohodlné. Zde jsou dvě možnosti - buď použít doménová jména a přidat DNS server pro každého klienta, pak pro nás adresa nebude nijak zvlášť důležitá (podobně jako síťová část v k8s) - ale je zde problém s externími sítěmi, protože adresy se v nich dají vydávat i přes DHCP - potřebujete synchronizaci s DNS servery v cloudové platformě a externí DNS server, což podle mého názoru není příliš flexibilní, ale je docela možné. Nebo druhou možností je použít metadata – tedy uložit informace o adrese přidělené stroji, aby DHCP server věděl, jakou adresu má stroji vydat, pokud stroj již adresu obdržel. Druhá možnost je jednodušší a flexibilnější, protože umožňuje uložit další informace o voze. Nyní do diagramu přidáme metadata agenta:
Dalším problémem, který také stojí za diskusi, je možnost používat jednu externí síť všemi klienty, protože externí sítě, pokud musí být platné v celé síti, budou obtížné - musíte neustále přidělovat a kontrolovat alokaci těchto sítí. Možnost používat jedinou externí předkonfigurovanou síť pro všechny klienty bude velmi užitečná při vytváření veřejného cloudu. To usnadní nasazení strojů, protože nemusíme prohlížet databázi adres a vybírat jedinečný adresní prostor pro externí síť každého klienta. Navíc si můžeme předem zaregistrovat externí síť a v době nasazení nám bude stačit přidružit externí adresy ke klientským strojům.
A zde nám NAT přichází na pomoc – pouze umožníme klientům přístup k vnějšímu světu prostřednictvím výchozího jmenného prostoru pomocí překladu NAT. No, tady je malý problém. To je dobré, pokud klientský server jedná jako klient a ne jako server – to znamená, že připojení spíše iniciuje, než přijímá. Ale u nás to bude naopak. V tomto případě musíme provést cílový NAT, aby při příjmu provozu řídící uzel pochopil, že tento provoz je určen pro virtuální stroj A klienta A, což znamená, že musíme provést překlad NAT z externí adresy, například 100.1.1.1 .10.0.0.1 na interní adresu 100. V tomto případě, přestože všichni klienti budou používat stejnou síť, je vnitřní izolace zcela zachována. To znamená, že musíme provést dNAT a sNAT na řídicím uzlu. Zda použít jednu síť s plovoucími adresami nebo externí sítě, nebo obě najednou, záleží na tom, co chcete do cloudu přenést. Do diagramu nebudeme přidávat plovoucí adresy, ale ponecháme externí sítě již přidané dříve - každý klient má svou vlastní externí síť (v diagramu jsou na externím rozhraní označeny jako vlan 200 a XNUMX).
Ve výsledku jsme dostali zajímavé a zároveň promyšlené řešení, které má určitou flexibilitu, ale zatím nemá mechanismy odolnosti proti chybám.
Za prvé, máme pouze jeden řídicí uzel – jeho selhání povede ke kolapsu všech systémů. Chcete-li tento problém vyřešit, musíte vytvořit kvorum alespoň 3 uzlů. Přidejme do diagramu toto:
Přirozeně jsou všechny uzly synchronizovány a když aktivní uzel odejde, další uzel převezme jeho povinnosti.
Dalším problémem jsou disky virtuálních strojů. V tuto chvíli jsou uloženy na samotných hypervisorech a v případě problémů s hypervisorem přicházíme o všechna data - a přítomnost raidu zde nepomůže, pokud neztratíme disk, ale celý server. K tomu musíme vytvořit službu, která bude fungovat jako frontend pro nějaký druh úložiště. O jaké úložiště se bude jednat, není pro nás nijak zvlášť důležité, ale mělo by nám chránit data před výpadkem jak disku, tak uzlu, případně celé skříně. Zde je několik možností - existují samozřejmě sítě SAN s Fibre Channel, ale buďme upřímní - FC je již relikt minulosti - analog E1 v dopravě - ano, souhlasím, stále se používá, ale jen tam, kde to bez něj absolutně nejde. Síť FC bych proto v roce 2020 dobrovolně nenasazoval s vědomím, že existují i jiné zajímavější alternativy. I když každému jeho vlastní, mohou se najít tací, kteří věří, že FC se všemi jeho omezeními je vše, co potřebujeme - nebudu se hádat, každý má svůj vlastní názor. Nejzajímavějším řešením je však podle mého názoru použití SDS, jako je Ceph.
Ceph vám umožňuje vybudovat vysoce dostupné řešení pro ukládání dat se spoustou možných možností zálohování, počínaje kódy s kontrolou parity (analogicky jako raid 5 nebo 6) a konče plnou replikací dat na různé disky, s přihlédnutím k umístění disků v servery a servery ve skříních atd.
K sestavení Ceph potřebujete 3 další uzly. Interakce s úložištěm bude také probíhat prostřednictvím sítě pomocí služeb blokového, objektového a souborového úložiště. Přidáme úložiště do diagramu:
Poznámka: Můžete také vytvořit hyperkonvergované výpočetní uzly - to je koncept kombinace několika funkcí na jednom uzlu - například storage+compute - bez vyhrazení speciálních uzlů pro ukládání ceph. Získáme stejné schéma odolnosti proti chybám – protože SDS bude rezervovat data s úrovní rezervace, kterou určíme. Hyperkonvergované uzly jsou však vždy kompromisem – protože storage node neohřívá pouze vzduch, jak se na první pohled zdá (protože na něm nejsou žádné virtuální stroje) – utrácí prostředky CPU na obsluhu SDS (ve skutečnosti dělá vše replikace a obnova po selhání uzlů, disků atd.). To znamená, že ztratíte část výkonu výpočetního uzlu, pokud jej zkombinujete s úložištěm.
Všechny tyto věci je potřeba nějak řídit – potřebujeme něco, přes co vytvoříme stroj, síť, virtuální router atd. K tomu přidáme do řídicího uzlu službu, která bude fungovat jako dashboard – klient se bude moci připojit k tomuto portálu přes http/ https a dělat vše, co potřebuje (no, skoro).
Výsledkem je, že nyní máme systém odolný proti chybám. Všechny prvky této infrastruktury se musí nějak řídit. Již dříve bylo popsáno, že Openstack je sada projektů, z nichž každý poskytuje specifickou funkci. Jak vidíme, prvků, které je třeba konfigurovat a ovládat, je více než dost. Dnes si povíme něco o síťové části.
Neutronová architektura
V OpenStacku je to Neutron, kdo je zodpovědný za připojení portů virtuálních strojů do společné sítě L2, zajištění směrování provozu mezi VM umístěnými v různých sítích L2 a také směrování ven, poskytování služeb jako NAT, Floating IP, DHCP atd.
Na vysoké úrovni lze provoz síťové služby (základní část) popsat následovně.
Při spouštění virtuálního počítače síťová služba:
- Vytvoří port pro daný virtuální počítač (nebo porty) a upozorní na to službu DHCP;
- Vytvoří se nové virtuální síťové zařízení (prostřednictvím libvirt);
- Virtuální počítač se připojí k portu (portům) vytvořeným v kroku 1;
Kupodivu je práce Neutronu založena na standardních mechanismech známých každému, kdo se kdy ponořil do Linuxu – jmenné prostory, iptables, linuxové mosty, openvswitch, conntrack atd.
Je třeba okamžitě objasnit, že Neutron není řadič SDN.
Neutron se skládá z několika vzájemně propojených složek:
Openstack-neutron-server je démon, který pracuje s požadavky uživatelů prostřednictvím API. Tento démon se nepodílí na registraci žádných síťových připojení, ale poskytuje k tomu potřebné informace svým pluginům, které pak konfigurují požadovaný síťový prvek. Neutronoví agenti na uzlech OpenStack se registrují na serveru Neutron.
Neutron-server je ve skutečnosti aplikace napsaná v pythonu, která se skládá ze dvou částí:
- Služba REST
- Neutron Plugin (jádro/služba)
Služba REST je navržena tak, aby přijímala volání API z jiných komponent (například požadavek na poskytnutí některých informací atd.)
Pluginy jsou zásuvné softwarové komponenty/moduly, které jsou volány během požadavků API – to znamená, že prostřednictvím nich dochází k přiřazení služby. Pluginy se dělí na dva typy – servisní a kořenové. Zásuvný modul koně je zpravidla zodpovědný za správu adresního prostoru a připojení L2 mezi virtuálními počítači a zásuvné moduly služeb již poskytují další funkce, jako je VPN nebo FW.
Seznam dnes dostupných pluginů si můžete prohlédnout např
Může existovat několik pluginů služeb, ale může existovat pouze jeden plugin pro koně.
openstack-neutron-ml2 je standardní kořenový plugin Openstack. Tento plugin má modulární architekturu (na rozdíl od svého předchůdce) a konfiguruje síťovou službu pomocí ovladačů, které jsou k němu připojeny. Na samotný plugin se podíváme o něco později, protože ve skutečnosti poskytuje flexibilitu, kterou OpenStack má v síťové části. Kořenový plugin lze nahradit (například Contrail Networking takovou výměnu provádí).
Služba RPC (rabbitmq-server) — služba, která poskytuje správu fronty a interakci s ostatními službami OpenStack, stejně jako interakci mezi agenty síťových služeb.
Síťoví agenti — agenti, kteří jsou umístěni v každém uzlu, prostřednictvím kterých se konfigurují síťové služby.
Existuje několik typů agentů.
Hlavním agentem je L2 agent. Tito agenti běží na každém z hypervizorů, včetně řídicích uzlů (přesněji na všech uzlech, které poskytují jakoukoli službu pro tenanty) a jejich hlavní funkcí je připojovat virtuální stroje ke společné L2 síti a také generovat upozornění, když nastanou nějaké události ( například zakázat/povolit port).
Dalším, neméně důležitým činitelem je L3 agent. Ve výchozím nastavení tento agent běží výhradně na síťovém uzlu (často je síťový uzel kombinován s řídícím uzlem) a poskytuje směrování mezi sítěmi tenantů (jak mezi svými sítěmi, tak sítěmi ostatních tenantů, a je přístupný vnějšímu světu a poskytuje NAT, stejně jako služba DHCP). Při použití DVR (distribuovaného routeru) se ale potřeba L3 pluginu objevuje i na výpočetních uzlech.
Agent L3 používá jmenné prostory Linuxu k tomu, aby každému tenantovi poskytl sadu vlastních izolovaných sítí a funkčnost virtuálních směrovačů, které směrují provoz a poskytují služby brány pro sítě vrstvy 2.
Databáze — databáze identifikátorů sítí, podsítí, portů, fondů atd.
Neutron ve skutečnosti přijímá požadavky API z vytvoření jakýchkoli síťových entit, ověřuje požadavek a prostřednictvím RPC (pokud přistupuje k nějakému pluginu nebo agentovi) nebo REST API (pokud komunikuje v SDN) přenáší agentům (přes pluginy) pokyny nezbytné pro organizaci požadované služby.
Nyní se podívejme na testovací instalaci (jak se nasazuje a co je v ní obsaženo, uvidíme později v praktické části) a podívejme se, kde se jednotlivé komponenty nacházejí:
(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 ~]$
Ve skutečnosti je to celá struktura Neutronu. Nyní stojí za to věnovat nějaký čas pluginu ML2.
Modulární vrstva 2
Jak bylo uvedeno výše, plugin je standardní kořenový plugin OpenStack a má modulární architekturu.
Předchůdce pluginu ML2 měl monolitickou strukturu, která neumožňovala například použití mixu více technologií v jedné instalaci. Nemohli jste například používat současně openvswitch i linuxbridge – buď první, ani druhý. Z tohoto důvodu vznikl plugin ML2 se svou architekturou.
ML2 má dvě součásti – dva typy ovladačů: ovladače typu a ovladače mechanismu.
Typ ovladače určit technologie, které budou použity k organizaci síťových připojení, například VxLAN, VLAN, GRE. Ovladač zároveň umožňuje použití různých technologií. Standardní technologií je zapouzdření VxLAN pro překryvné sítě a externí sítě vlan.
Typové ovladače zahrnují následující typy sítí:
Byt - síť bez označování
VLAN - označená síť
Místní — speciální typ sítě pro all-in-one instalace (takové instalace jsou potřebné buď pro vývojáře, nebo pro školení)
GRE — překryvná síť pomocí GRE tunelů
VxLAN — překryvná síť využívající tunely VxLAN
Ovladače mechanismů definovat nástroje, které zajišťují organizaci technologií uvedených v typovém ovladači - například openvswitch, sr-iov, opendaylight, OVN atd.
V závislosti na implementaci tohoto ovladače budou využiti buď agenti ovládaní Neutronem, nebo připojení k externímu SDN řadiči, který se stará o veškeré záležitosti spojené s organizací L2 sítí, směrováním atp.
Příklad: pokud používáme ML2 společně s OVS, pak je na každém výpočetním uzlu, který spravuje OVS, nainstalován L2 agent. Pokud ale použijeme např. OVN nebo OpenDayLight, tak kontrola OVS spadá do jejich pravomoci - Neutron přes root plugin dává příkazy ovladači a ten už dělá, co mu bylo řečeno.
Pojďme si oprášit Open vSwitch
V současné době je jednou z klíčových součástí OpenStack Open vSwitch.
Při instalaci OpenStack bez jakéhokoli dalšího dodavatele SDN, jako je Juniper Contrail nebo Nokia Nuage, je OVS hlavní síťovou součástí cloudové sítě a spolu s iptables, conntrack, jmennými prostory vám umožňuje organizovat plnohodnotné překryvné sítě s více nájemci. Přirozeně lze tuto komponentu nahradit například při použití řešení SDN třetích stran (proprietárního dodavatele).
OVS je softwarový přepínač s otevřeným zdrojovým kódem, který je navržen pro použití ve virtualizovaných prostředích jako virtuální směrovač provozu.
V tuto chvíli má OVS velmi slušnou funkcionalitu, která zahrnuje technologie jako QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK atd.
Poznámka: OVS nebyl původně koncipován jako měkký přepínač pro vysoce zatížené telekomunikační funkce a byl navržen spíše pro IT funkce, které jsou méně náročné na šířku pásma, jako je WEB server nebo poštovní server. OVS se však dále rozvíjí a současné implementace OVS výrazně zlepšily jeho výkon a možnosti, což umožňuje jeho využití i telekomunikačními operátory s vysoce zatíženými funkcemi, např. existuje implementace OVS s podporou akcelerace DPDK.
Existují tři důležité součásti OVS, o kterých musíte vědět:
- Modul jádra — komponenta umístěná v prostoru jádra, která zpracovává provoz na základě pravidel přijatých z řídicího prvku;
- vSwitch démon (ovs-vswitchd) je proces spuštěný v uživatelském prostoru, který je zodpovědný za programování modulu jádra – to znamená, že přímo reprezentuje logiku činnosti přepínače
- Databázový server - lokální databáze umístěná na každém hostiteli, na kterém běží OVS, ve které je uložena konfigurace. SDN kontroléry mohou komunikovat přes tento modul pomocí protokolu OVSDB.
To vše je doprovázeno sadou diagnostických a manažerských nástrojů, jako je ovs-vsctl, ovs-appctl, ovs-ofctl atd.
Openstack je v současné době hojně využíván telekomunikačními operátory k migraci síťových funkcí na něj, jako je EPC, SBC, HLR atd. Některé funkce mohou žít bez problémů s OVS tak, jak jsou, ale např. EPC zpracovává účastnický provoz - pak prochází přes obrovské množství provozu (nyní objemy provozu dosahují několika stovek gigabitů za sekundu). Přirozeně, že řídit takový provoz prostorem jádra (protože tam je přeposílání umístěn ve výchozím nastavení) není nejlepší nápad. Proto je OVS často nasazován výhradně v uživatelském prostoru pomocí akcelerační technologie DPDK k předávání provozu z NIC do uživatelského prostoru obcházením jádra.
Poznámka: u cloudu nasazeného pro telekomunikační funkce je možné provozovat provoz z výpočetního uzlu, který obchází OVS, přímo do přepínacího zařízení. K tomuto účelu slouží mechanismy SR-IOV a Passthrough.
Jak to funguje na skutečném rozložení?
No a teď přejděme k praktické části a podívejme se, jak to celé funguje v praxi.
Nejprve nasadíme jednoduchou instalaci Openstacku. Protože nemám po ruce sadu serverů pro experimenty, sestavíme prototyp na jeden fyzický server z virtuálních strojů. Ano, přirozeně, takové řešení není vhodné pro komerční účely, ale na ukázku fungování sítě v Openstacku taková instalace pro oči stačí. Navíc je taková instalace ještě zajímavější pro účely školení - protože můžete zachytit provoz atd.
Vzhledem k tomu, že potřebujeme vidět pouze základní část, nemůžeme použít několik sítí, ale vše zvedat pouze pomocí dvou sítí a druhá síť v tomto rozložení bude sloužit výhradně pro přístup k undercloud a DNS serveru. Externích sítí se prozatím nedotkneme – to je téma na samostatný velký článek.
Začněme tedy popořadě. Nejprve trocha teorie. Openstack nainstalujeme pomocí TripleO (Openstack na Openstacku). Podstatou TripleO je, že Openstack nainstalujeme all-in-one (tedy na jeden uzel), nazvaný undercloud, a následně využijeme možností nasazeného Openstacku k instalaci Openstacku určeného k provozu, kterému se říká overcloud. Undercloud využije svou vlastní schopnost spravovat fyzické servery (holý kov) – projekt Ironic – k poskytování hypervizorů, které budou plnit role výpočetních, řídicích a úložných uzlů. To znamená, že k nasazení Openstacku nepoužíváme žádné nástroje třetích stran – Openstack nasazujeme pomocí Openstacku. Postupem instalace to bude mnohem jasnější, takže se tam nezastavíme a půjdeme dál.
Poznámka: V tomto článku jsem pro jednoduchost nepoužil izolaci sítě pro interní sítě Openstack, ale vše je nasazeno pouze pomocí jedné sítě. Přítomnost či absence síťové izolace však nemá vliv na základní funkcionalitu řešení – vše bude fungovat úplně stejně jako při použití izolace, ale provoz bude proudit na stejné síti. Pro komerční instalaci je přirozeně nutné použít izolaci pomocí různých vlan a rozhraní. Například provoz správy úložiště ceph a samotný datový provoz (strojový přístup k diskům atd.), když jsou izolované, používají různé podsítě (Správa úložiště a úložiště) a to vám umožňuje učinit řešení odolnější proti chybám rozdělením tohoto provozu, například , přes různé porty nebo pomocí různých profilů QoS pro různý provoz, aby datový provoz nevytlačoval signalizační provoz. V našem případě pojedou na stejné síti a vlastně nás to nijak neomezuje.
Poznámka: Protože budeme virtuální stroje provozovat ve virtuálním prostředí založeném na virtuálních strojích, musíme nejprve povolit vnořenou virtualizaci.
Zda je vnořená virtualizace povolena nebo ne, můžete zkontrolovat takto:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Pokud vidíte písmeno N, povolujeme podporu pro vnořenou virtualizaci podle libovolného průvodce, který najdete v síti, např. .
Potřebujeme sestavit následující okruh z virtuálních strojů:
V mém případě jsem pro připojení virtuálních strojů, které jsou součástí budoucí instalace (a dostal jsem jich 7, ale vystačíte si se 4, pokud nemáte mnoho zdrojů), použil OpenvSwitch. Vytvořil jsem jeden ovs bridge a připojil k němu virtuální stroje přes port-groups. Za tímto účelem jsem vytvořil soubor xml takto:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Jsou zde deklarovány tři skupiny portů - dvě přístupové a jeden trunk (ten byl potřebný pro DNS server, ale můžete se obejít bez něj, nebo jej nainstalovat na hostitelský počítač - podle toho, co je pro vás výhodnější). Dále pomocí této šablony deklarujeme naše prostřednictvím virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Nyní upravíme konfigurace portů hypervizoru:
[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áři nebude adresa na portu ovs-br1 přístupná, protože nemá značku vlan. Chcete-li to opravit, musíte zadat příkaz sudo ovs-vsctl set port ovs-br1 tag=100. Po restartu však tato značka zmizí (pokud někdo ví, jak ji zajistit, aby zůstala na místě, budu velmi vděčný). To ale není tak důležité, protože tuto adresu budeme potřebovat pouze při instalaci a při plném nasazení Openstacku ji potřebovat nebudeme.
Dále vytvoříme podcloudový 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=ttyS0Při instalaci nastavíte všechny potřebné parametry, jako je název stroje, hesla, uživatelé, ntp servery atd., můžete ihned konfigurovat porty, ale pro mě osobně je po instalaci jednodušší se do stroje přihlásit přes konzole a opravte potřebné soubory. Pokud již máte hotový obraz, můžete jej použít, nebo udělejte to, co jsem udělal já – stáhněte si minimální obraz Centos 7 a použijte jej k instalaci VM.
Po úspěšné instalaci byste měli mít virtuální stroj, na který si můžete undercloud nainstalovat
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningNejprve nainstalujte nástroje potřebné pro proces instalace:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Instalace pod cloudem
Vytvoříme uživatele zásobníku, nastavíme heslo, přidáme ho do sudoeru a dáme mu možnost spouštět příkazy root přes sudo bez nutnosti zadávat heslo:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNyní zadáme celý název podcloudu v souboru hosts:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Dále přidáme úložiště a nainstalujeme software, který potřebujeme:
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: Pokud neplánujete instalovat ceph, nemusíte zadávat příkazy související s ceph. Použil jsem vydání Queens, ale můžete použít jakýkoli jiný, který chcete.
Dále zkopírujte konfigurační soubor undercloud do zásobníku domovského adresáře uživatele:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNyní musíme tento soubor opravit a přizpůsobit jej naší instalaci.
Na začátek souboru musíte přidat tyto řádky:
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 = 10Pojďme si tedy projít nastavení:
undercloud_hostname — úplný název serveru pod cloudem se musí shodovat se záznamem na serveru DNS
local_ip — adresa místního podcloudu směrem k poskytování sítě
síťová_brána — stejná místní adresa, která bude fungovat jako brána pro přístup do vnějšího světa během instalace overcloud uzlů, se také shoduje s místní ip
undercloud_public_host — externí adresa API, je přiřazena jakákoli volná adresa z prováděcí sítě
undercloud_admin_host interní adresa API, je přiřazena jakákoli volná adresa z prováděcí sítě
undercloud_nameservers - DNS server
vygenerovat_servisní_certifikát - tento řádek je v aktuálním příkladu velmi důležitý, protože pokud jej nenastavíte na false, během instalace se zobrazí chyba, problém je popsán na bug trackeru Red Hat
místní_rozhraní rozhraní při zajišťování sítě. Toto rozhraní bude překonfigurováno během nasazení pod cloudem, takže musíte mít na undercloudu dvě rozhraní – jedno pro přístup k němu, druhé pro zřizování
local_mtu — MTU. Jelikož máme zkušebnu a na portech přepínače OVS mám MTU 1500, je potřeba nastavit 1450, aby pakety zapouzdřené ve VxLAN mohly projít
network_cidr — zajišťovací síť
Maškaráda — pomocí NAT pro přístup k externí síti
maškarní_síť - síť, která bude NATed
dhcp_start — počáteční adresa fondu adres, ze kterého budou adresy přidělovány uzlům během nasazování overcloud
dhcp_end — konečná adresa fondu adres, ze kterého budou adresy přidělovány uzlům během nasazení overcloud
inspekce_iprange — soubor adres nezbytný pro introspekci (neměl by se překrývat s výše uvedeným fondem)
scheduler_max_attempts — maximální počet pokusů o instalaci overcloud (musí být větší nebo roven počtu uzlů)
Po popisu souboru můžete zadat příkaz k nasazení undercloud:
openstack undercloud install
Procedura trvá 10 až 30 minut v závislosti na vaší žehličce. Nakonec byste měli vidět výstup takto:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Tento výstup říká, že jste úspěšně nainstalovali podcloud a nyní můžete zkontrolovat stav podcloudu a pokračovat v instalaci overcloudu.
Pokud se podíváte na výstup ifconfig, uvidíte, že se objevilo nové rozhraní mostu
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Nasazení overcloudu bude nyní probíhat přes toto rozhraní.
Z výstupu níže můžete vidět, že máme všechny služby na jednom uzlu:
(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 |
+--------------------------+-----------+----------+Níže je konfigurace části sítě pod cloudem:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Overcloud instalace
V tuto chvíli máme pouze undercloud a nemáme dostatek uzlů, ze kterých by se overcloud sestavil. Nejprve tedy nasadíme virtuální stroje, které potřebujeme. Při nasazení si sám undercloud nainstaluje OS a potřebný software na overcloud stroj - to znamená, že nepotřebujeme stroj kompletně nasadit, ale pouze pro něj vytvořit disk (nebo disky) a určit jeho parametry - tzn. ve skutečnosti získáme holý server bez nainstalovaného OS.
Pojďme do složky s disky našich virtuálních strojů a vytvořte disky požadované velikosti:
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 160GProtože pracujeme jako root, musíme změnit vlastníka těchto disků, abychom neměli problém s právy:
[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: pokud neplánujete instalovat ceph za účelem jeho studia, pak příkazy nevytvoří alespoň 3 uzly s alespoň dvěma disky, ale v šabloně indikují, že budou použity virtuální disky vda, vdb atd.
Skvělé, nyní musíme definovat všechny tyto stroje:
virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml
virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml
virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml
virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml
virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml Na konci je příkaz -print-xml > /tmp/storage-1.xml, který ve složce /tmp/ vytvoří xml soubor s popisem každého stroje, pokud jej nepřidáte, nebudete dokáže identifikovat virtuální stroje.
Nyní musíme definovat všechny tyto stroje ve virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Nyní malá nuance – tripleO používá IPMI ke správě serverů během instalace a introspekce.
Introspekce je proces kontroly hardwaru za účelem získání jeho parametrů nezbytných pro další poskytování uzlů. Introspekce se provádí pomocí ironie, služby navržené pro práci s holými kovovými servery.
Ale tady je problém - zatímco hardwarové IPMI servery mají samostatný port (nebo sdílený port, ale to není důležité), virtuální stroje takové porty nemají. Zde nám přichází na pomoc berlička zvaná vbmc – nástroj, který vám umožňuje emulovat port IPMI. Tato nuance stojí za pozornost zejména pro ty, kteří chtějí takovou laboratoř zřídit na ESXI hypervisoru - abych byl upřímný, nevím, jestli má analog vbmc, takže stojí za to se nad tímto problémem zamyslet před nasazením všeho .
Nainstalujte vbmc:
yum install yum install python2-virtualbmcPokud váš operační systém nemůže balíček najít, přidejte úložiště:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNyní nastavíme utilitu. Všechno je tu banální až k ostudě. Nyní je logické, že v seznamu vbmc nejsou žádné servery
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Aby se objevily, musí být ručně deklarovány takto:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Myslím, že syntaxe příkazu je jasná bez vysvětlení. Prozatím jsou však všechny naše relace ve stavu DOWN. Aby mohly přejít do stavu UP, musíte je povolit:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#A poslední dotek - musíte opravit pravidla brány firewall (nebo je úplně zakázat):
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
Nyní přejdeme do podcloudu a zkontrolujeme, zda vše funguje. Adresa hostitelského počítače je 192.168.255.200, na undercloud jsme během přípravy na nasazení přidali potřebný balíček ipmitool:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningJak můžete vidět, úspěšně jsme spustili řídicí uzel přes vbmc. Nyní to vypneme a pokračujeme:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Dalším krokem je introspekce uzlů, na kterých bude nainstalován overcloud. K tomu musíme připravit json soubor s popisem našich uzlů. Vezměte prosím na vědomí, že na rozdíl od instalace na holé servery soubor označuje port, na kterém běží vbmc pro každý počítač.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Poznámka: ovládací uzel má dvě rozhraní, ale v tomto případě to není důležité, v této instalaci nám bude stačit jedno.
Nyní připravíme soubor json. Musíme uvést makovou adresu portu, přes který bude zajišťování prováděno, parametry uzlů, dát jim jména a uvést, jak se dostat do ipmi:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Nyní musíme připravit obrázky pro ironii. Chcete-li to provést, stáhněte si je přes wget a nainstalujte:
(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ávání obrázků do cloudu:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Kontrola, zda se načetly všechny obrázky
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Ještě jedna věc - musíte přidat server DNS:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Nyní můžeme dát příkaz k introspekci:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Jak je vidět z výstupu, vše proběhlo bez chyb. Zkontrolujeme, zda jsou všechny uzly v dostupném stavu:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Pokud jsou uzly v jiném stavu, obvykle zvládnutelném, pak se něco pokazilo a musíte se podívat do protokolu a zjistit, proč se to stalo. Mějte na paměti, že v tomto scénáři používáme virtualizaci a s používáním virtuálních strojů nebo vbmc mohou být spojeny chyby.
Dále musíme uvést, který uzel bude vykonávat jakou funkci – to znamená uvést profil, se kterým se uzel nasadí:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Zadejte profil pro každý uzel:
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-d9afb69d1167Zkontrolujeme, že jsme vše udělali správně:
(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 ~]$Pokud je vše v pořádku, dáme příkaz k nasazení overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuV reálné instalaci budou samozřejmě použity přizpůsobené šablony, v našem případě to značně zkomplikuje proces, protože každou úpravu v šabloně bude nutné vysvětlit. Jak již bylo napsáno dříve, i jednoduchá instalace nám postačí, abychom viděli, jak to funguje.
Poznámka: proměnná qemu typu --libvirt je v tomto případě nezbytná, protože budeme používat vnořenou virtualizaci. V opačném případě nebudete moci spouštět virtuální stroje.
Nyní máte asi hodinu, nebo možná více (v závislosti na možnostech hardwaru) a můžete jen doufat, že po této době uvidíte následující zprávu:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Nyní máte téměř plnohodnotnou verzi openstacku, na které můžete studovat, experimentovat atp.
Zkontrolujeme, zda vše funguje správně. V zásobníku domovského adresáře uživatele jsou dva soubory – jeden stackrc (pro správu undercloud) a druhý overcloudrc (pro správu overcloud). Tyto soubory musí být specifikovány jako zdroj, protože obsahují informace nezbytné pro ověření.
(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 ~]$Moje instalace stále vyžaduje jeden malý dotyk - přidání trasy na ovladači, protože stroj, se kterým pracuji, je v jiné síti. Chcete-li to provést, přejděte na control-1 pod účtem správce tepla a zaregistrujte trasu
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254No, teď můžete jít do horizontu. Veškeré informace – adresy, přihlašovací jméno a heslo – jsou v souboru /home/stack/overcloudrc. Konečný diagram vypadá takto:
Mimochodem, v naší instalaci byly adresy strojů vydávány přes DHCP a jak vidíte, jsou vydávány „náhodně“. V šabloně můžete přesně definovat, která adresa má být připojena ke kterému počítači během nasazení, pokud ji potřebujete.
Jak probíhá provoz mezi virtuálními stroji?
V tomto článku se podíváme na tři možnosti projíždění dopravy
- Dva stroje na jednom hypervisoru na jedné L2 síti
- Dva stroje na různých hypervizorech ve stejné síti L2
- Dva počítače v různých sítích (rootování napříč sítěmi)
Případy s přístupem do vnějšího světa přes externí síť, pomocí plovoucích adres, ale i distribuovaného směrování, zvážíme příště, zatím se zaměříme na interní provoz.
Pro kontrolu sestavme následující schéma:
Vytvořili jsme 4 virtuální stroje - 3 v jedné síti L2 - net-1 a 1 další v síti net-2
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Podívejme se, na jakých hypervizorech jsou vytvořené stroje umístěny:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(overcloud) [stack@undercloud ~]$
Stroje vm-1 a vm-3 jsou umístěny na compute-0, stroje vm-2 a vm-4 jsou umístěny na uzlu compute-1.
Kromě toho byl vytvořen virtuální směrovač, který umožňuje směrování mezi určenými sítěmi:
(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 ~]$ Router má dva virtuální porty, které fungují jako brány pro sítě:
(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 ~]$ Než se ale podíváme na to, jak provoz proudí, podívejme se, co aktuálně máme na řídicím uzlu (což je také síťový uzel) a na výpočetním uzlu. Začněme výpočetním uzlem.
[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 ~]$V tuto chvíli má uzel tři ovs mosty - br-int, br-tun, br-ex. Mezi nimi, jak vidíme, je sada rozhraní. Pro snazší pochopení si všechna tato rozhraní zakreslete do diagramu a uvidíme, co se stane.
Při pohledu na adresy, na které jsou tunely VxLAN zvýšeny, je vidět, že jeden tunel je zvýšen na výpočet-1 (192.168.255.26), druhý tunel vypadá na ovládání-1 (192.168.255.15). Ale nejzajímavější je, že br-ex nemá fyzická rozhraní, a když se podíváte na to, jaké toky jsou nakonfigurovány, můžete vidět, že tento most může v tuto chvíli pouze snížit provoz.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Jak můžete vidět z výstupu, adresa je přišroubována přímo k fyzickému portu, nikoli k rozhraní virtuálního mostu.
[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 ~]$
Podle prvního pravidla musí být zlikvidováno vše, co přišlo z phy-br-ex portu.
Ve skutečnosti není v současné době nikde jinde, než by do tohoto mostu mohl přicházet provoz kromě tohoto rozhraní (rozhraní s br-int), a soudě podle poklesů provoz BUM již do mostu vletěl.
To znamená, že provoz může opustit tento uzel pouze tunelem VxLAN a ničím jiným. Pokud však DVR zapnete, situace se změní, ale tím se budeme zabývat jindy. Při použití síťové izolace, například pomocí vlan, nebudete mít ve vlan 3 jedno rozhraní L0, ale několik rozhraní. Provoz VxLAN však opustí uzel stejným způsobem, ale také zapouzdřený v nějaké vyhrazené vlan.
Vyřešili jsme výpočetní uzel, přejděme k řídicímu uzlu.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$Ve skutečnosti můžeme říci, že je vše při starém, ale IP adresa již není na fyzickém rozhraní, ale na virtuálním mostě. To se děje proto, že tento port je portem, přes který bude provoz vycházet do vnějšího světa.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Tento port je svázán s mostem br-ex a protože na něm nejsou žádné značky vlan, je tento port kmenovým portem, na kterém jsou povoleny všechny sítě vlan, nyní provoz jde ven bez značky, jak je označeno vlan-id 0 v výstup výše.
Vše ostatní je v tuto chvíli podobné jako u výpočetního uzlu – stejné mosty, stejné tunely vedoucí do dvou výpočetních uzlů.
V tomto článku se nebudeme zabývat storage nody, ale pro pochopení je nutné říci, že síťová část těchto uzlů je banální až ostuda. V našem případě existuje pouze jeden fyzický port (eth0) s přidělenou IP adresou a to je vše. Neexistují žádné tunely VxLAN, tunelové mosty atd. - neexistují vůbec žádné ov, protože to nemá smysl. Při použití síťové izolace bude mít tento uzel dvě rozhraní (fyzické porty, bodny, nebo jen dva vlany - to je jedno - záleží na tom, co chcete) - jedno pro správu, druhé pro provoz (zápis na disk VM , čtení z disku atd.)
Přišli jsme na to, co máme na uzlech při absenci jakýchkoli služeb. Nyní spustíme 4 virtuální stroje a uvidíme, jak se výše popsané schéma změní – měli bychom mít porty, virtuální routery atd.
Naše síť zatím vypadá takto:
Na každém počítačovém uzlu máme dva virtuální stroje. Pomocí compute-0 jako příkladu se podívejme, jak je vše zahrnuto.
[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á pouze jedno virtuální rozhraní - 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 rozhraní vypadá v linuxovém mostě:
[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 ~]$ Jak můžete vidět z výstupu, v můstku jsou pouze dvě rozhraní - tap95d96a75-a0 a qvb95d96a75-a0.
Zde stojí za to se trochu zastavit u typů virtuálních síťových zařízení v OpenStack:
vtap - virtuální rozhraní připojené k instanci (VM)
qbr - Linuxový most
qvb a qvo - pár vEth připojený k mostu Linux a mostu Open vSwitch
br-int, br-tun, br-vlan — Otevřete mosty vSwitch
patch-, int-br-, phy-br- - Otevřená vSwitch patch rozhraní spojující mosty
qg, qr, ha, fg, sg - Otevření portů vSwitch používaných virtuálními zařízeními pro připojení k OVS
Jak jste pochopili, pokud máme v můstku port qvb95d96a75-a0, což je pár vEth, pak někde je jeho protějšek, který by se měl logicky jmenovat qvo95d96a75-a0. Podívejme se, jaké porty jsou 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 ~]$ Jak vidíme, přístav je v br-int. Br-int funguje jako přepínač, který ukončuje porty virtuálních strojů. Kromě qvo95d96a75-a0 je ve výstupu viditelný port qvo5bd37136-47. Toto je port na druhý virtuální počítač. Výsledkem je, že náš diagram nyní vypadá takto:
Otázka, která by měla okamžitě zaujmout pozorného čtenáře - jaký je linuxový most mezi portem virtuálního stroje a portem OVS? Faktem je, že k ochraně stroje se používají bezpečnostní skupiny, které nejsou ničím jiným než iptables. OVS nepracuje s iptables, proto byla vynalezena tato „berlička“. Stává se však zastaralým – v nových vydáních je nahrazován conntrackem.
To znamená, že schéma nakonec vypadá takto:
Dva stroje na jednom hypervisoru na jedné L2 síti
Protože jsou tyto dva virtuální počítače umístěny ve stejné síti L2 a na stejném hypervisoru, provoz mezi nimi bude logicky proudit lokálně přes br-int, protože oba stroje budou na stejné VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Dva stroje na různých hypervizorech ve stejné síti L2
Nyní se podívejme, jak bude probíhat provoz mezi dvěma stroji ve stejné síti L2, ale umístěnými na různých hypervizorech. Abych byl upřímný, nic se moc nezmění, akorát provoz mezi hypervizory půjde tunelem vxlan. Podívejme se na příklad.
Adresy virtuálních strojů, mezi kterými budeme sledovat provoz:
[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 ~]$ Podíváme se na tabulku přesměrování 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 ~]Provoz by měl jít na port 2 – podívejme se, o jaký druh portu se jedná:
[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 - tedy rozhraní v br-tunu. Podívejme se, co se stane s balíčkem na br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Paket je zabalen do VxLAN a odeslán na port 2. Podívejme se, kam vede port 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Toto je tunel vxlan na compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Pojďme na compute-1 a uvidíme, co se s balíčkem stane dál:
[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 tabulce předávání br-int na compute-1 a jak je vidět z výše uvedeného výstupu, je vidět přes port 2, což je port směrem k br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46No, pak vidíme, že v br-int na compute-1 je cílový mák:
[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 přijatý paket poletí na port 3, za kterým se již nachází instance virtuálního stroje-00000003.
Krása nasazení Openstacku pro výuku na virtuální infrastruktuře spočívá v tom, že můžeme snadno zachytit provoz mezi hypervizory a zjistit, co se s ním děje. To je to, co nyní uděláme, spustíme tcpdump na portu vnet směrem k compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************První řádek ukazuje, že Patek z adresy 10.0.1.85 jde na adresu 10.0.1.88 (provoz ICMP) a je zabalen do paketu VxLAN s vni 22 a paket jde z hostitele 192.168.255.19 (výpočet-0) na hostitele 192.168.255.26 .1 (výpočet-XNUMX). Můžeme zkontrolovat, zda VNI odpovídá tomu, který je uveden v ovs.
Vraťme se na tento řádek actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 je vni v hexadecimální číselné soustavě. Převedeme toto číslo na 16. systém:
16 = 6*16^0+1*16^1 = 6+16 = 22Čili vni odpovídá skutečnosti.
Druhý řádek ukazuje zpáteční provoz, no, nemá cenu to vysvětlovat, tam je vše jasné.
Dva stroje v různých sítích (směrování mezi sítěmi)
Posledním případem pro dnešek je směrování mezi sítěmi v rámci jednoho projektu pomocí virtuálního routeru. Uvažujeme o případu bez DVR (podíváme se na to v jiném článku), takže směrování nastává na síťovém uzlu. V našem případě není síťový uzel umístěn v samostatné entitě a je umístěn na řídicím uzlu.
Nejprve se podívejme, že směrování funguje:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msProtože v tomto případě musí paket jít na bránu a tam být směrován, musíme zjistit MAC adresu brány, pro kterou se podíváme do tabulky ARP v instanci:
$ 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 eth0Nyní se podívejme, kam by měl být odeslán provoz s cílem (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 ~]$ Podívejme se, kam vede port 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Vše je logické, provoz jde na br-tun. Podívejme se, do kterého tunelu vxlan to bude zabaleno:
[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 ~]$ Třetí 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 ~]$ Který se podívá na řídicí uzel:
[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 ~]$ Provoz dosáhl řídicího uzlu, takže k němu musíme jít a podívat se, jak bude směrování probíhat.
Jak si vzpomínáte, řídicí uzel uvnitř vypadal úplně stejně jako výpočetní uzel – stejné tři mosty, pouze br-ex měl fyzický port, přes který mohl uzel posílat provoz ven. Vytváření instancí změnilo konfiguraci na výpočetních uzlech - do uzlů byl přidán linuxový most, iptables a rozhraní. Na konfiguraci řídicího uzlu se podepsalo i vytvoření sítí a virtuálního routeru.
Je tedy zřejmé, že MAC adresa brány musí být v tabulce předávání br-int na řídicím uzlu. Zkontrolujeme, zda tam je a kam se dívá:
[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 viditelný z portu qr-0c52b15f-8f. Pokud se vrátíme k seznamu virtuálních portů v Openstacku, tento typ portu slouží k připojení různých virtuálních zařízení k OVS. Přesněji řečeno, qr je port k virtuálnímu routeru, který je reprezentován jako jmenný prostor.
Podívejme se, jaké jmenné prostory jsou na serveru:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Až tři kopie. Ale soudě podle názvů můžete hádat účel každého z nich. K instancím s ID 0 a 1 se vrátíme později, nyní nás zajímá jmenný prostor qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ Tento jmenný prostor obsahuje dva interní, které jsme vytvořili dříve. Oba virtuální porty byly přidány do br-int. Pojďme zkontrolovat mac adresu portu qr-0c52b15f-8f, protože provoz, soudě podle cílové mac adresy, šel na toto rozhraní.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ To znamená, že v tomto případě vše funguje podle zákonů standardního směrování. Protože provoz je určen pro hostitele 10.0.2.8, musí opustit druhé rozhraní qr-92fa49b5-54 a projít tunelem vxlan do výpočetního uzlu:
[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še je logické, žádné překvapení. Podívejme se, kde je v br-int viditelná maková adresa hostitele 10.0.2.8:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Jak se očekávalo, provoz směřuje do br-tun, podívejme se, do kterého tunelu provoz směřuje příště:
[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 ~]$ Provoz jde do tunelu na výpočet-1. No, na compute-1 je vše jednoduché - z br-tun jde balíček do br-int a odtud do rozhraní virtuálního stroje:
[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 ~]$ Pojďme zkontrolovat, zda je toto skutečně správné rozhraní:
[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 ~]$
Vlastně jsme prošli celou cestu balíkem. Myslím, že jste si všimli, že provoz procházel různými tunely vxlan a vyjížděl s různými VNI. Podívejme se, co to je za VNI, načež shromáždíme výpis na řídicím portu uzlu a ujistíme se, že provoz probíhá přesně tak, jak je popsáno výše.
Tunel k výpočtu-0 má tedy následující akce=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],výstup:3. Převedeme 0x16 na desítkovou číselnou soustavu:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunel do compute-1 má následující VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Převedeme 0x63 na desítkovou číselnou soustavu:
0x63 = 3*16^0+6*16^1 = 3+96 = 99No a teď se podívejme na skládku:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************První paket je paket vxlan z hostitele 192.168.255.19 (výpočet-0) do hostitele 192.168.255.15 (řízení-1) s vni 22, uvnitř kterého je paket ICMP zabalen z hostitele 10.0.1.85 do hostitele 10.0.2.8. Jak jsme vypočítali výše, vni odpovídá tomu, co jsme viděli ve výstupu.
Druhý paket je paket vxlan z hostitele 192.168.255.15 (řízení-1) do hostitele 192.168.255.26 (výpočet-1) s vni 99, uvnitř kterého je paket ICMP zabalen z hostitele 10.0.1.85 do hostitele 10.0.2.8. Jak jsme vypočítali výše, vni odpovídá tomu, co jsme viděli ve výstupu.
Další dva pakety jsou zpětný provoz z 10.0.2.8, nikoli 10.0.1.85.
To znamená, že jsme nakonec dostali následující schéma řídicího uzlu:
Vypadá to, že to je ono? Zapomněli jsme na dva jmenné prostory:
[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 ~]$ Jak jsme mluvili o architektuře cloudové platformy, bylo by dobré, kdyby stroje dostávaly adresy automaticky z DHCP serveru. Jedná se o dva servery DHCP pro naše dvě sítě 10.0.1.0/24 a 10.0.2.0/24.
Ověřte, zda je to pravda. V tomto jmenném prostoru je pouze jedna adresa - 10.0.1.1 - adresa samotného serveru DHCP a je také zahrnuta v br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Podívejme se, zda procesy obsahující qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ve svém názvu v řídicím uzlu:
[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 ~]$ Takový proces existuje a na základě informací uvedených ve výstupu výše můžeme například vidět, co máme aktuálně k pronájmu:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$Výsledkem je, že na řídicím uzlu získáme následující sadu služeb:
No, mějte na paměti - tohle jsou jen 4 stroje, 2 interní sítě a jeden virtuální router... Nemáme tu teď externí sítě, spoustu různých projektů, každý se svými vlastními sítěmi (překrývající se), a máme distribuovaný router se vypnul a nakonec Koneckonců v testovací stolici byl pouze jeden řídicí uzel (pro odolnost proti chybám musí být kvorum tří uzlů). Je logické, že v komerci je vše „trochu“ složitější, ale na tomto jednoduchém příkladu chápeme, jak by to mělo fungovat – zda máte 3 nebo 300 jmenných prostorů je samozřejmě důležité, ale z hlediska fungování celého struktura se nic moc nezmění... i když dokud nepřipojíte nějaké SDN dodavatele. Ale to je úplně jiný příběh.
Doufám, že to bylo zajímavé. Pokud máte nějaké připomínky/doplnění, nebo jsem někde přímo lhal (jsem člověk a můj názor bude vždy subjektivní) - napište, co je potřeba opravit/doplnit - vše opravíme/doplníme.
Na závěr bych rád řekl pár slov o srovnání Openstacku (vanilla i dodavatele) s cloudovým řešením od VMWare – tuto otázku jsem během posledních pár let dostával příliš často a upřímně řečeno, už je z toho unavený, ale stejně. Podle mého názoru je velmi obtížné tato dvě řešení porovnávat, ale rozhodně můžeme říci, že obě řešení mají své nevýhody a při výběru jednoho řešení je třeba zvážit pro a proti.
Pokud je OpenStack komunitní řešení, pak má VMWare právo dělat si jen to, co chce (čti - co je pro něj ziskové) a je to logické - jde totiž o komerční společnost, která je zvyklá na svých klientech vydělávat. Je tu ale jedno velké a tlusté ALE - můžete vystoupit z OpenStacku například od Nokie a s malými náklady přejít na řešení například od Juniper (Contrail Cloud), ale je nepravděpodobné, že budete moci vystoupit z VMWare . Pro mě tato dvě řešení vypadají takto - Openstack (vendor) je jednoduchá klec, do které vás strčí, ale máte klíč a můžete kdykoliv odejít. VMWare je zlatá klec, klíč od klece má majitel a bude vás to stát hodně.
Nepropaguji ani první produkt, ani druhý - vyberte si, co potřebujete. Pokud bych ale měl takovou možnost, zvolil bych obě řešení - VMWare pro IT cloud (nízká zátěž, snadná správa), OpenStack od nějakého dodavatele (Nokia a Juniper poskytují velmi dobrá řešení na klíč) - pro Telecom cloud. Openstack bych nepoužil pro čisté IT - je to jako střílet vrabce z děla, ale nevidím žádné kontraindikace jeho použití kromě redundance. Používání VMWare v telekomunikacích je však jako tahání drceného kamene ve Fordu Raptor – je to krásné zvenčí, ale řidič musí místo jedné cesty udělat 10.
Podle mě je největší nevýhodou VMWare jeho naprostá uzavřenost - firma vám nedá žádné informace o tom, jak to funguje např. vSAN nebo co je v jádře hypervisoru - prostě to pro ni není rentabilní - tedy budete nikdy se nestaňte expertem na VMWare – bez podpory dodavatele jste odsouzeni k záhubě (velmi často se setkávám s odborníky na VMWare, kteří jsou zmateni triviálními otázkami). Pro mě VMWare kupuje auto se zamčenou kapotou - ano, možná máte specialisty, kteří umí vyměnit rozvodový řemen, ale kapotu může otevřít pouze ten, kdo vám toto řešení prodal. Osobně nemám rád řešení, do kterých se nevejdu. Řeknete si, že pod kapotu snad nemusíte. Ano, je to možné, ale podívám se na vás, až budete potřebovat sestavit velkou funkci v cloudu z 20-30 virtuálních strojů, 40-50 sítí, z nichž polovina chce jít ven a druhá polovina požaduje Zrychlení SR-IOV, jinak budete potřebovat dalších pár desítek těchto vozů - jinak nebude výkon stačit.
Jsou i jiné úhly pohledu, takže jen vy se můžete rozhodnout, co si vybrat a hlavně pak budete za svůj výběr zodpovědní. Je to jen můj názor - člověka, který viděl a osahal minimálně 4 produkty - Nokia, Juniper, Red Hat a VMWare. To znamená, že mám s čím porovnávat.
Zdroj: www.habr.com