Cloud computing is increasingly permeating our lives, and it is likely that there is not a single person who has not used some cloud services at least once. However, what exactly is the cloud and how does it work is something that most people know little about, even at an idea level. 5G is already becoming a reality, and telecommunications infrastructure is beginning to shift from traditional solutions to cloud solutions, just as it transitioned from pure hardware solutions to virtualized 'poles'.
Today we will talk about the internal world of cloud infrastructure, specifically, we will discuss the basics of the network part.
What is the cloud? Is it just virtualization — a profile view?
A perfectly logical question. No — it is not virtualization, although it is certainly part of it. Let's look at two definitions:
Cloud computing (hereafter referred to as the Cloud) — is a model that provides end-users with convenient access to distributed computing resources that must be deployed and launched on demand with minimal possible delay and minimal costs on the part of the service provider.
Virtualizace — is the ability to divide one physical entity (for example, a server) into several virtual ones, thereby increasing resource utilization (for example, if you had 3 servers loaded at 25-30 percent, after virtualization you get 1 server loaded at 80-90 percent). Naturally, virtualization consumes some resources — you need to maintain the hypervisor; however, as practice has shown, it is worth it. An ideal example of virtualization is VMWare, which effectively prepares virtual machines, or KVM, which I prefer, but that’s a matter of taste.
We use virtualization without even realizing it; even hardware routers already use virtualization — for example, in the latest versions of JunOS, the operating system is installed as a virtual machine on top of a real-time Linux distribution (Wind River 9). But virtualization is not the cloud; however, the cloud cannot exist without virtualization.
Virtualization is one of the building blocks on which the cloud is constructed.
Vytvořit cloud stažením několika hypervizorů do jednoho L2 domény, přidáním několika yaml playbooků pro automatické nastavení VLAN přes nějaké Ansible a na to všechno nasadit něco jako orchestraci pro automatické vytváření virtuálních strojů — nepůjde. Přesněji to půjde, ale vzniklý Frankenstein — není to cloud, který potřebujeme, i když pro někoho to může být sen. Navíc, pokud vezmeme například OpenStack — v podstatě je to také takový Frankenstein, ale prozatím se o tom nebudeme bavit.
Ale rozumím tomu, že z výše uvedené definice není úplně jasné, co vlastně můžeme označit jako cloud.
Proto v dokumentu NIST (National Institute of Standards and Technology) jsou uvedeny 5 hlavních charakteristik, kterými by měla disponovat cloudová infrastruktura:
Poskytování služby na požádání. Uživateli by měl být umožněn volný přístup k přiděleným počítačovým zdrojům (jako jsou sítě, virtuální disky, paměť, jádra procesorů atd.), přičemž tyto zdroje by měly být poskytovány automaticky — tedy bez zásahu poskytovatele služeb.
Široká dostupnost služby. Přístup ke zdrojům by měl být zajištěn standardními mechanismy pro možnost použití jak standardních PC, tak tenkých klientů a mobilních zařízení.
Sjednocení zdrojů do poolů. Pool zdrojů by měl umožnit současné poskytování zdrojů více klientům, zajistit izolaci klientů a nedocházet k vzájemnému ovlivňování a konkurenci o zdroje. Do poolů jsou zahrnuty i sítě, což naznačuje možnost použití překrývající se adresace. Pooly by měly podporovat škálování na požádání. Využití poolů zajišťuje potřebnou úroveň odolnosti zdrojů a abstrahaci fyzických a virtuálních zdrojů — uživateli služby je jednoduše poskytnut požadovaný soubor zdrojů (kde jsou tyto zdroje fyzicky umístěny, na kolika serverech a switchích — pro klienta není důležité). Avšak je třeba brát v potaz, že poskytovatel musí zajistit transparentní rezervaci těchto zdrojů.
Rychlá adaptace na různé podmínky. Služby musí být flexibilní — rychlé poskytování prostředků, jejich přeobjednání, dodání nebo zúžení prostředků na žádost zákazníka, přičemž zákazník by měl mít pocit, že zdroje cloudu jsou nekonečné. Pro jednodušší pochopení, například jste si nevšimli varování, že vám v Apple iCloud zmizelo část diskového prostoru kvůli tomu, že na serveru selhal pevný disk, a disky selhávají. Kromě toho jsou možnosti této služby z vaší strany prakticky neomezené — potřebujete 2 TB — není problém, zaplatili jste a dostali jste. Analogicky lze uvést příklad s Google.Drive nebo Yandex.Disk.
Možnost měření poskytované služby. Cloudové systémy by měly automaticky monitorovat a optimalizovat spotřebovávané zdroje, přičemž tyto mechanismy by měly být transparentní jak pro uživatele, tak pro poskytovatele služeb. To znamená, že vždy můžete zkontrolovat, kolik zdrojů vy a vaši klienti spotřebováváte.
Je třeba vzít v úvahu, že tato požadavky jsou většinou požadavky na veřejný cloud, a proto pro soukromý cloud (to znamená cloud spuštěný pro vnitřní potřeby společnosti) mohou být tyto požadavky mírně upraveny. Nicméně by měly být splněny, jinak nezískáme všechny výhody cloudového výpočtu.
Proč potřebujeme cloud?
Nicméně jakákoliv nová nebo již existující technologie, jakýkoliv nový protokol je vytvořen pro něco (nu, kromě RIP-ng, samozřejmě). Protokol pro protokol — není nikomu potřebný (nu, kromě RIP-ng, samozřejmě). Je logické, že cloud je vytvářen, aby poskytl nějakou službu uživateli/klientovi. Všichni jsme se seznámili alespoň s několika cloudovými službami, například Dropbox nebo Google.Docs a předpokládám, že většina z nich úspěšně používá — například tento článek byl napsán s využitím cloudové služby Google.Docs. Ale známé cloudové služby jsou pouze částí možností cloudu — přesněji to jsou pouze služby typu SaaS. Poskytnout cloudovou službu můžeme třemi způsoby: ve formě SaaS, PaaS nebo IaaS. Jaká služba je pro vás potřebná, závisí na vašich přáních a možnostech.
Prozkoumejme každý postupně:
Software jako služba (SaaS) — to je model poskytování plnohodnotné služby klientovi, například poštovního servisu typu Yandex.Mail nebo Gmail. V tomto modelu poskytování služby vlastně jako klient neděláte nic jiného, než že využíváte služby – to znamená, že se nemusíte starat o nastavení služby, její odolnost proti výpadkům nebo zálohování. Hlavní je nekompromitovat své heslo, vše ostatní za vás zajistí poskytovatel této služby. Z pohledu poskytovatele služby – nese plnou odpovědnost za celou službu – počínaje serverovým vybavením a hostitelskými operačními systémy, konče nastavením databází a softwaru.
Platforma jako služba (PaaS) — při využívání tohoto modelu poskytovatel služeb poskytuje klientovi šablonu pro službu, například vezmeme Web server. Poskytovatel služeb poskytl klientovi virtuální server (ve skutečnosti soubor zdrojů, jako je RAM/CPU/Úložiště/Sítě atd.), a dokonce na tento server nainstaloval OS a potřebný software, avšak nastavení celého tohoto zařízení provádí sám klient a za funkčnost služby už odpovídá klient. Poskytovatel služeb, stejně jako v předchozím případě, odpovídá za funkčnost fyzického vybavení, hypervizorů, samotné virtuální mašiny, její síťovou dostupnost atd., ale samotná služba už leží mimo jeho zodpovědnost.
Infrastruktura jako služba (IaaS) — tento přístup je již zajímavější, v podstatě poskytovatel služeb klientovi poskytuje úplnou virtualizovanou infrastrukturu — tedy jakýsi soubor (pool) zdrojů, jako jsou CPU jádra, RAM, Sítě atd. Všechno ostatní je věcí klienta — co chce klient udělat s těmito zdroji v rámci vyhrazeného mu poolu (kvóty) — poskytovateli až tak moc nezáleží. Chce klient vytvořit svůj vlastní vEPC nebo dokonce založit mini operátora a poskytovat telekomunikační služby — není problém — dělejte. V takovém scénáři poskytovatel služeb odpovídá za poskytování zdrojů, jejich odolnost proti výpadkům a dostupnost, a také za OS, která umožňuje spojit tyto zdroje do poolů a poskytnout je klientovi se schopností kdykoli provést zvýšení nebo snížení zdrojů na žádost klienta. Všechny virtuální stroje a další mřížky si klient nastavuje sám prostřednictvím portálu samoobsluhy a konzole, včetně nastavení sítí (kromě externích sítí).
Co je OpenStack?
Ve všech třech variantách potřebuje poskytovatel služeb operační systém, který umožňuje vytvoření cloudové infrastruktury. Ve skutečnosti však při SaaS za celý technologický stack neodpovídá jedno oddělení — existuje oddělení, které odpovídá za infrastrukturu — to znamená, že poskytuje IaaS jinému oddělení, které poskytuje zákazníkovi SaaS. OpenStack je jedním z cloudových operačních systémů, který umožňuje shromáždit řadu switchů, serverů a systémů ukládání do jedné zdrojové poolu, rozdělit tento společný pool na subpools (tenants) a poskytovat tyto zdroje zákazníkům prostřednictvím sítě.
OpenStack — je to cloudový operační systém, který umožňuje řídit velké pooly výpočetních zdrojů, datových úložišť a síťových zdrojů, jejich provision a správu, která se provádí prostřednictvím API za použití standardních autentizačních mechanismů.
Jinými slovy, je to soubor projektů svobodného software, který je určen pro vytváření cloudových služeb (jak veřejných, tak soukromých) — to znamená soubor nástrojů, které umožňují spojit serverové a komutační zařízení do jedné pooly zdrojů, spravovat tyto zdroje, zajišťující potřebnou úroveň odolnosti proti výpadkům.
V době psaní tohoto materiálu struktura OpenStack vypadá takto:
Obrázek převzat z
Každá z komponent, které tvoří OpenStack, plní určitou funkci. Taková distribuovaná architektura umožňuje zahrnout do řešení ten soubor funkčních komponent, které potřebujete. Nicméně některé komponenty jsou základní a jejich odstranění povede k plné nebo částečné nefunkčnosti řešení jako celku. K takovým komponentám se obvykle řadí:
- Dashboard — GUI na bázi webu pro správu OpenStack služeb
- Keystone — centralizovaná služba identifikace, která poskytuje funkčnost autentizace a autorizace pro ostatní služby, a také spravuje uživatelské údaje a jejich role.
- Neutron — síťová služba, která zajišťuje konektivitu mezi rozhraními různých služeb OpenStack (včetně konektivity mezi VM a jejich přístupem do vnějšího světa)
- Cinder — poskytuje přístup k blokovému úložišti pro virtuální stroje
- Nova — správa životního cyklu virtuálních strojů
- Glance — repozitář obrazů virtuálních strojů a snímků
- Swift — poskytuje přístup k objektovému úložišti
- Ceilometer — služba, která umožňuje sběr telemetrie a měření dostupných a spotřebovávaných zdrojů
- Heat — orchestraci na základě šablon pro automatické vytváření a provisionování zdrojů
Úplný seznam všech projektů a jejich účel je k dispozici .
Každá komponenta OpenStack je služba, která odpovídá za určitou funkci a poskytuje API pro správu této funkce a interakci této služby s ostatními službami cloudového operačního systému za účelem vytvoření jednotné infrastruktury. Například, Nova zajišťuje správu výpočetních zdrojů a API pro přístup k konfiguraci těchto zdrojů, Glance – správu obrazů a API pro jejich správu, Cinder – blokové úložiště a API pro jeho správu atd. Všechny funkce jsou vzájemně úzce propojeny.
Pokud se však zamyslíme, všechny služby běžící v OpenStack nakonec představují nějaký virtuální stroj (nebo kontejner) připojený k síti. Vzniká otázka – proč máme tolik prvků?
Pojďme se projít algoritmem vytváření virtuálního stroje a jeho připojení k síti a trvalému úložišti v OpenStacku.
- Když vytváříte žádost o vytvoření stroje, ať už je to žádost přes Horizon (Dashboard) nebo žádost přes CLI, první, co se stane – je autorizace vaší žádosti na Keystone – zda můžete vytvářet stroj, zda máte právo používat tuto síť, zda má váš projekt dostatek kvót atd.
- Keystone autentizuje vaši žádost a generuje v odpovědi auth-token, který bude posléze použit. Po získání odpovědi od Keystone je žádost odeslána směrem k Nově (nova api).
- Nova-api kontroluje platnost vaší žádosti tím, že se obrátí na Keystone a použije dříve vygenerovaný auth-token.
- Keystone provádí autentifikaci a na základě tohoto auth-tokenu poskytuje informace o oprávněních a omezeních.
- Nova-api vytváří v nova-database záznam o novém VM a předává žádost o vytvoření stroje do nova-scheduler.
- Nova-scheduler vybírá hostitele (počítačové uzly), na kterém bude VM nasazena, na základě zadaných parametrů, vah a zón. Záznam o tom a identifikátor VM jsou zapsány do nova-database.
- Dále nova-scheduler se obrací na nova-compute s žádostí o nasazení instance. Nova-compute se obrátil na nova-conductor pro získání informací o parametrech stroje (nova-conductor je prvek nova, který plní roli proxy serveru mezi nova-database a nova-compute, omezující počet požadavků směrem k nova-database, aby se předešlo problémům s konzistencí databáze a snížení zatížení).
- Nova-conductor získává požadované informace z nova-database a předává je nova-compute.
- Dále nova-compute se obrací na glance pro získání ID obrazu. Glance provádí validaci požadavku v Keystone a vrací požadované informace.
- Nova-compute se obrací na neutron pro získání informací o parametrech sítě. Podobně jako glance, neutron provádí validaci požadavku v Keystone, poté vytváří záznam v databázi (identifikátor portu atd.), vytváří žádost na vytvoření portu a vrací požadované informace do nova-compute.
- Nova-compute se obrací na cinder s žádostí o přidělení svazku virtuální stroji. Podobně jako glance, cinder provádí validaci požadavku v Keystone, vytváří žádost na vytvoření svazku a vrací požadované informace.
- Nova-compute se obrací na libvirt s žádostí o nasazení virtuálního stroje se zadanými parametry.
Na první pohled se zdá, že jednoduchá operace vytvoření jednoduché virtuální stroje se mění v takový vír API volání mezi prvky cloudové platformy. A jak vidíte, i dříve uvedené služby se skládají z menších komponent, mezi kterými probíhá interakce. Vytvoření stroje je pouze malou částí toho, co cloudová platforma umožňuje — existuje služba odpovědná za vyvažování provozu, služba odpovědná za blokové úložiště, služba odpovědná za DNS, služba odpovědná za provisionování bare metal serverů atd. Cloud vám umožňuje zacházet s vašimi virtuálními stroji jako se stádem ovcí (na rozdíl od virtualizace). Pokud se ve virtuálním prostředí něco stane se strojem — obnovíte ho z záloh atd., cloudové aplikace jsou však navrženy tak, aby virtuální stroje nehrály tak důležitou roli — virtuální stroj „zemřel“ — nevadí — jednoduše se vytvoří nový stroj na základě šablony a, jak se říká, ztráty si nikdo nevšiml. Samozřejmě to předpokládá existenci orchestrace — pomocí šablon Heat lze snadno nasadit složitou funkci, která se skládá z desítek sítí a virtuálních strojů.
Vždy je dobré mít na paměti, že bez sítě není cloudová infrastruktura — každý prvek nějakým způsobem interaguje s ostatními prvky přes síť. Kromě toho má cloud zcela nestatickou síť. Samozřejmě, že podkladová (underlay) síť je více či méně statická — nové uzly a přepínače se nepřidávají každý den, avšak overlay část se může a nevyhnutelně bude neustále měnit — nové sítě se budou přidávat nebo odstraňovat, nové virtuální stroje se objeví a staré zaniknou. A jak si pamatujete z definice cloudu na začátku článku — zdroje by měly být uživateli přidělovány automaticky a s minimálním (nebo lépe bez) zásahu ze strany poskytovatele služeb. To znamená, že typ poskytování síťových zdrojů, který existuje nyní ve formě frontendu vašeho osobního účtu dostupného přes http/https a s pohotovým síťovým inženýrem Vasilym jako backendem — to není cloud, i když má Vasily osm rukou.
Neutron, jako síťová služba, poskytuje API pro správu síťové části cloudové infrastruktury. Služba zajišťuje funkčnost a správu síťové části OpenStack a zajišťuje úroveň abstrakce nazývanou Network-as-a-Service (NaaS). To znamená, že síť je tak stejně virtuální měřitelnou jednotkou, jako například virtuální jádra CPU nebo objem RAM.
Ale než přejdeme k architektuře síťové části OpenStacku, podívejme se, jak v OpenStacku tato síť funguje a proč je síť důležitou a nedílnou součástí cloudu.
Máme tedy dva virtuální stroje klienta RED a dva virtuální stroje klienta GREEN. Předpokládejme, že tyto stroje jsou umístěny na dvou hypervizorech následujícím způsobem:
V tuto chvíli se jedná pouze o virtualizaci 4 serverů a nic víc, protože dosud jsme pouze virtualizovali 4 servery, které jsou umístěny na dvou fyzických serverech. A zatím nejsou ani připojeny k síti.
Abychom získali cloud, musíme přidat několik komponent. Za prvé virtualizujeme síťovou část — musíme tyto 4 stroje spojit po dvojicích, a přitom klienti požadují právě L2 spojení. Můžeme použít switch a nastavit trunk směrem k němu, a vyřešit vše pomocí linux bridge, nebo pro pokročilejší uživatele openvswitch (k tomu se ještě vrátíme). Ale sítí může být velmi mnoho, a neustále protahovat L2 přes switch — není nejlepším řešením — takové přístupy vedou k různým oddělením, servisu, měsícům čekání na splnění žádosti, týdny řešení problémů — v moderním světě už takový přístup nefunguje. Čím dříve si to společnost uvědomí, tím snadněji se jí bude posouvat vpřed. Proto mezi hypervizory vyčleníme L3 síť, přes kterou budou komunikovat naše virtuální stroje, a na této L3 síti postavíme virtuální překryté L2 (overlay) sítě, kde bude probíhat provoz našich virtuálních strojů. Jako enkapsulaci můžeme použít GRE, Geneve nebo VxLAN. Zatím se zastavíme u posledního, i když to není příliš důležité.
Musíme někde umístit VTEP (doufám, že všichni znají terminologii VxLAN). Jelikož z našich serverů vychází ihned L3 síť, nic nám nebrání umístit VTEP na samotné servery, přičemž OVS (OpenvSwitch) to skvěle umí. Nakonec jsme dostali takovou konstrukci:
Protože musí být provoz mezi VM oddělen, mají porty směrem k virtuálním strojům různé čísla VLAN. Číslo tagu hraje roli pouze v rámci jednoho virtuálního switche, protože při enkapsulaci do VxLAN ho můžeme bez problémů odstranit, protože budeme mít VNI.
Nyní můžeme rozmnožit naše stroje a virtuální sítě pro ně bez jakýchkoli problémů.
Ale co když bude klient mít další stroj, ale nachází se v jiné síti? Potřebujeme routování mezi sítěmi. Probereme jednoduchou variantu, kdy se používá centralizované routování — to znamená, že provoz se směruje přes speciální vyhrazené síťové uzly (tyto uzly jsou obvykle sloučeny s kontrolními uzly, takže budeme mít totéž).
Není to nic složitého — vytvoříme bridge interface na kontrolním uzlu, nasměrujeme na něj provoz a odtud ho směrujeme tam, kam potřebujeme. Ale problém je, že klient RED chce používat síť 10.0.0.0/24 a klient GREEN chce používat síť 10.0.0.0/24. Takže nám začíná překrývání adresových prostorů. Kromě toho klienti nechtějí, aby se ostatní klienti mohli směrovat do jejich vnitřních sítí, což je logické. Abychom rozdělili sítě a datový provoz těchto klientů, vyčleníme pro každého z nich samostatný namespace. Namespace je de facto kopie síťového stacku Linuxu, což znamená, že klienti v namespace RED jsou plně izolováni od klientů v namespace GREEN (buď je povoleno routování mezi těmito sítěmi klientů přes default namespace, nebo již na vyšším transportním zařízení).
Takže dostáváme takovou schéma:
L2 tunely se sbíhají ze všech výpočetních uzlů na kontrolní uzel, kde se nachází L3 interface pro tyto sítě, každý v vyhrazeném namespace pro izolaci.
Ale zapomněli jsme na to nejdůležitější. Virtuální stroj musí poskytovat službu klientovi, což znamená, že by měl mít alespoň jedno externí rozhraní, přes které k němu mohou přistupovat. Musíme se tedy dostat do vnějšího světa. Zde existují různé možnosti. Uděláme ten nejjednodušší variant. Přidáme klientům jednu síť, která bude platná v síti poskytovatele a nebude se překrývat s jinými sítěmi. Sítě mohou také mít překrývající se adresy a směřovat do různých VRF na straně poskytovateské sítě. Tyto sítě rovněž budou žít v namespace každého z klientů. Nicméně přístup do vnějšího světa budou mít stále přes jedno fyzické (nebo bondované, což je logičtější) rozhraní. Abychom oddělili provoz klientů, veškerý provoz vycházející ven bude označován tagem VLAN, který je přidělen klientovi.
Výsledkem je následující schéma:
Rozumná otázka — proč neudělat brány přímo na samotných compute nodách? V tom není žádný velký problém, navíc, při zapnutí distribuovaného směrovače (DVR) to tak bude fungovat. V tomto scénáři zvažujeme ten nejjednodušší variant s centralizovanou bránou, která se ve standardním Openstacku používá. Pro vysoce zatížené funkce budou použity jak distribuovaný směrovač, tak technologie urychlení jako SR-IOV a Passthrough, ale jak se říká, to už je úplně jiný příběh. Nejprve se zaměříme na základní část a poté se pustíme do detailů.
Vlastně naše schéma už je funkční, nicméně existují některé nuancy:
- Musíme nějak ochránit naše stroje, tedy nasadit na rozhraní switche směrem ke klientovi filtr.
- Umožnit automatické získávání IP adresy virtuálním strojem, aby se nemuselo pokaždé přihlašovat do něj přes konzolu a zadávat adresu.
Začněme s ochrannou strojů. K tomu lze použít obyčejné iptables, proč ne.
To znamená, že nyní naše topologie je již trochu složitější:
Pokračujme dál. Musíme přidat DHCP server. Nejideálnější místo pro umístění DHCP serverů pro každého z klientů bude již zmíněná kontrolní nody, kde se nacházejí namespace:
Existuje 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 strojům budou přiděleny nové adresy, což není příliš pohodlné. Existují 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 příliš důležitá (podobně jako v síťové části k8s) — ale zde je problém s externími sítěmi, protože i v nich mohou být adresy přiděleny pomocí DHCP — je potřeba synchronizace s DNS servery v cloudové platformě a externím DNS serverem, což dle mého názoru není příliš flexibilní, ale je to zcela možné. Nebo druhá varianta — použít metadata — tzn. uchovávat informace o přidělené adrese stroje, aby DHCP server věděl, kterou adresu stroji přiřadit, pokud stroj již adresu dostal. Druhá varianta je jednodušší a flexibilnější, protože umožňuje uchovávat doplňkové informace o stroji. Nyní na schéma přidáme metadata agenta:
Další otázkou, kterou je také potřeba osvětit, je možnost používat jednu externí síť všemi klienty, protože externí sítě, pokud mají být platné v celé síti, budou komplikované — je třeba neustále přidělovat a kontrolovat přidělení těchto sítí. Možnost použití jediné, pro všechny klienty externí předkonfigurované sítě by byla velmi vítaná při vytváření veřejného cloudu. To zjednoduší nasazení strojů, protože se nemusíme shodovat s databází adres a vybírat unikátní adresní prostor pro externí síť každého klienta. Navíc můžeme externí síť zapsat předem a v okamžiku nasazení nám bude stačit pouze asociovat externí adresy s klientskými stroji.
A zde nám pomáhá NAT — jednoduše umožníme klientům připojit se do externího světa prostřednictvím defaultního namespace pomocí NAT překladů. Je tu však malý problém. Je to dobré, pokud klientský server funguje jako klient a ne jako server — tedy iniciuje, nikoli nepřijímá spojení. Ale v našem případě bude všechno naopak. V takovém případě musíme provést destination NAT, aby kontrolní uzel rozuměl, že tento provoz je určen virtuálnímu stroji A klienta A, a tudíž je nutné provést NAT překlad z vnější adresy, například 100.1.1.1 na vnitřní adresu 10.0.0.1. V takovém případě, přestože všichni klienti používají stejnou síť, vnitřní izolace je plně zachována. To znamená, že na kontrolním uzlu musíme provést dNAT a sNAT. Použití jediné sítě s přidělením plovoucích adres nebo externích sítí, nebo obou, závisí na tom, co chcete do cloudu přitáhnout. Do schématu nebudeme přidávat další plovoucí adresy, ale ponecháme již dříve přidané externí sítě — každý klient má svou externí síť (na schématu označena jako VLAN 100 a 200 na externím rozhraní).
Výsledkem je zajímavé a zároveň promyšlené řešení, které má určitou flexibilitu, ale zatím postrádá mechanismy odolnosti proti výpadkům.
Za prvé, máme pouze jeden kontrolní uzel — jeho selhání povede k zhroucení všech systémů. Abychom tento problém vyřešili, je nutné mít alespoň kvórum ze 3 uzlů. Přidáme to do schématu:
Samozřejmě, všechny uzly se synchronizují a při selhání aktivního uzlu převezme jeho povinnosti jiný uzel.
Další problém se týká disků virtuálních strojů. V současnosti jsou uloženy přímo na hypervizorech a v případě problémů s hypervizorem ztrácíme všechna data — a to, že máme RAID, nám v ničem nepomůže, pokud ztratíme celý server, nikoli jen disk. Potřebujeme proto vytvořit službu, která bude fungovat jako front-end pro nějaké úložiště. Jaké to bude úložiště, není pro nás tak důležité, ale mělo by chránit naše data před selháním jak disku, tak uzlu, případně i celého racku. Možností je několik — existují samozřejmě SAN sítě s Fiber Channel, ale řekněme si upřímně — FC je již přežitkem minulosti — ekvivalent E1 v dopravě — ano, souhlasím, stále se používá, ale jen tam, kde se bez něj opravdu neobejdeme. Proto bych se v roce 2020 neodvážil rozjíždět síť FC, když vím o existenci zajímavějších alternativ. Ačkoli každý má své preference a možná se najdou lidé, kteří si myslí, že FC se všemi svými omezeními je to, co potřebujeme — nebudu polemizovat, každý má svůj názor. Nicméně, z mého pohledu je nejzajímavějším řešením využití SDS, například Ceph.
Ceph umožňuje vybudovat vysoce dostupné řešení pro ukládání dat s mnoha možnými variantami zálohování, počínaje kódy s kontrolou parit (podobné RAID 5 nebo 6) konče úplnou replikací dat na různých discích s ohledem na umístění disků v serverech, a serverů v racku atd.
Pro sestavení Ceph potřebujeme ještě 3 uzly. Interakce s úložištěm bude probíhat také přes síť s využitím služeb blokového, objektového a souborového úložiště. Přidáme do schématu úložiště:
Poznámka: lze vytvářet také hyperkonvergentní compute uzly – je to koncept spojení několika funkcí v jednom uzlu – například storage + compute – nevyčleňovat speciální uzly pro Ceph storage. Získáme tak stejně rezilientní schéma – protože SDS rezervuje data s námi určenou úrovní zálohování. Nicméně hyperkonvergentní uzly jsou vždy kompromis – protože storage uzel jen tak neohřívá vzduch, jak se na první pohled zdá (protože na něm nejsou virtuální stroje) – spotřebovává zdroje CPU na správu SDS (ve skutečnosti na pozadí provádí všechny replikace, obnovy po poruchách uzlů, disků atd.). Tedy ztratíte část výkonu compute uzlu, pokud jej zkombinujete se storage.
S tímto vším je třeba nějakým způsobem řídit – potřebujeme něco, přes co můžeme vytvořit stroj, síť, virtuální router atd. K tomu na kontrolní uzel přidáme službu, která bude fungovat jako dashboard – klient se bude moci připojit k tomuto portálu přes http/https a udělat vše, co potřebuje (no skoro).
Nakonec máme odolný systém. Všemi prvky této infrastruktury je potřeba nějakým způsobem řídit. Dříve bylo popsáno, že OpenStack je soubor projektů, z nichž každý poskytuje nějakou konkrétní funkci. Jak vidíme, prvků, které je potřeba konfigurovat a řídit, je více než dost. Dnes se podíváme na síťovou část.
Architektura Neutron
V OpenStack se Neutron stará o připojení portů virtuálních strojů k sdílené L2 síti, zajištění směrování provozu mezi VM umístěnými v různých L2 sítích a také směrování ven, poskytování takových služeb jako NAT, Floating IP, DHCP atd.
Vysokoúrovňová práce síťové služby (základní část) může být popsána takto.
Při spuštění VM síťová služba:
- Vytváří port pro daný VM (nebo porty) a informuje o tom DHCP službu;
- Vytváří se nový virtuální síťový zařízení (přes libvirt);
- VM se připojuje k portu vytvořenému v kroku 1 (portům);
Jak se zdá překvapivé, jádrem funkce Neutron jsou standardní mechanismy známé každému, kdo se kdy ponořil do Linuxu – to jsou namespaces, iptables, linux bridges, openvswitch, conntrack atd.
Je třeba hned upřesnit, že Neutron není SDN kontroler.
Neutron se skládá z několika vzájemně propojených komponentů:
Openstack-neutron-server — je demon, který prostřednictvím API pracuje s uživatelskými požadavky. Tento démon se nezabývá definováním jakýchkoliv síťových vazeb, ale poskytuje potřebné informace svým pluginům, které poté konfiguruji požadovaný prvek sítě. Neutron agenty na uzlech OpenStack se registrují na serveru Neutron.
Neutron-server je vlastně aplikace napsaná v Pythonu, skládající se ze dvou částí:
- REST služba
- Neutron Plugin (core/service)
REST služba slouží k přijímání API volání od ostatních komponent (například žádost o poskytnutí nějaké informace atd.)
Pluginy jsou volitelné programové komponenty/moduly, které se vyvolávají při API voláních — to znamená, že připojení nějaké služby se provádí přes ně. Pluginy se dělí na dva typy — servisní a kořenový. Obecně kořenový plugin odpovídá především za správu adresního prostoru a L2 spojení mezi VM, zatímco servisní pluginy zajišťují dodatečné funkce, například VPN nebo FW.
Seznam dostupných pluginů dnes lze například zobrazit
Servisních pluginů může být několik, avšak kořenový plugin může být pouze jeden.
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 prostřednictvím připojených ovladačů provádí konfiguraci síťové služby. Samotný plugin probereme později, protože prakticky poskytuje tu flexibilitu, kterou OpenStack v oblasti sítě má. Kořenový plugin může být nahrazen (např. Contrail Networking provádí tuto náhradu).
RPC služba (rabbitmq-server) — služba zajišťující správu front a interakci s ostatními službami OpenStack a také interakci mezi agenty síťové služby.
Síťoví agenti — agenti, kteří jsou umístěni v každé uzlu, prostřednictvím nichž se provádí konfigurace síťových služeb.
Agenti mohou být několika typů.
Hlavní agent — to je L2 agent. Tyto agenty jsou spuštěny na každém z hypervizorů, včetně kontrolních uzlů (přesněji řečeno na všech uzlech, které poskytují jakoukoli službu pro nájemce) a jejich hlavní funkcí je připojení virtuálních strojů ke společné L2 síti a také generování upozornění při výskytu jakýchkoli událostí (například vypnutí/zapnutí portu).
Dalším, neméně důležitým agentem je L3 agent. Ve výchozím nastavení je tento agent spuštěn výhradně na síťovém uzlu (často se síťový uzel slučuje s kontrolním uzlem) a zajišťuje směrování mezi sítěmi nájemců (jak mezi jeho sítěmi a sítěmi jiných nájemců, tak i přístup do vnějšího světa, zajišťující NAT a také DHCP službu). Při použití DVR (distribuovaný směrovač) se však potřeba po L3 pluginu objevuje i na compute uzlech.
L3 agent používá Linux namespaces pro poskytování sad vlastních izolovaných sítí každému nájemci a funkcionalitu virtuálních směrovačů, které směrují provoz a poskytují služby brány pro Layer 2 sítě.
Databáze — databáze identifikátorů sítí, podsítí, portů, poolů atd.
V podstatě Neutron přijímá API požadavky na vytvoření jakýchkoli síťových entit, autentizuje požadavek a prostřednictvím RPC (pokud se obrací na nějaký plugin nebo agenta) nebo REST API (pokud komunikuje v SDN) předává agentům (prostřednictvím pluginů) instrukce potřebné pro zajištění požadované služby.
Nyní se podíváme na testovací instalaci (jak je nasazena a co je jejím součástí, uvidíme později v praktické části) a podíváme se, kde se nachází která komponenta:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 
A to je celá struktura Neutron. Nyní stojí za to věnovat nějaký čas pluginu ML2.
Modulární vrstva 2
Jak již bylo uvedeno, plugin je standardním základním pluginem OpenStack a má modulární architekturu.
Předchůdce pluginu ML2 měl monolitickou strukturu, což neumožňovalo například používat mix několika technologií v jedné instalaci. Například jste nemohli použít jak openvswitch, tak linuxbridge současně — buď jedno, nebo druhé. Z tohoto důvodu byl vytvořen plugin ML2 s jeho architekturou.
ML2 má dvě složky — dva typy ovladačů: Type drivers a Mechanism drivers.
Type drivers určují technologie, které budou použity k organizaci síťových spojení, například VxLAN, VLAN, GRE. Tento ovladač umožňuje používat různé technologie. Standardní technologií je VxLAN encapsulation pro overlay sítě a vlan externích sítí.
K type drivers patří následující typy sítí:
Flat — síť bez tagování
VLAN — tagovaná síť
Místní — speciální typ sítě pro instalace typu all-in-one (takové instalace jsou potřebné buď pro vývojáře, nebo pro školení)
GRE — overlay síť využívající GRE tunely
VxLAN — overlay síť využívající VxLAN tunely
Mechanism drivers určují prostředky, které zajišťují organizaci uvedených technologií typu driver — například openvswitch, sr-iov, opendaylight, OVN atd.
V závislosti na implementaci tohoto ovladače budou použity buď agenty řízené Neutronem, nebo budou využívána spojení s externím SDN kontrolérem, který se stará o všechny otázky organizace L2 sítí, routování atd.
Pokud použijeme ML2 spolu s OVS, na každém výpočetním uzlu se nainstaluje L2 agent, který spravuje OVS. Avšak pokud použijeme například OVN nebo OpenDayLight, tak řízení OVS přechází pod jejich jurisdikci — Neutron prostřednictvím kořenového pluginu dává pokyny kontroléru, a ten provádí to, co mu bylo řečeno.
Osrefreshujeme v paměti Open vSwitch
V současné době je jedním z klíčových komponentů OpenStack Open vSwitch.
Při instalaci OpenStack bez jakéhokoli dalšího dodavatelského SDN typu Juniper Contrail nebo Nokia Nuage, je OVS hlavní síťovou komponentou cloudové sítě a v kombinaci s iptables, conntrack, namespaces umožňuje organizaci plnohodnotných overlayových sítí s multitenancy. Samozřejmě tato komponenta může být nahrazena, například při použití externích proprietárních (dodavatelských) SDN řešení.
OVS je softwarový přepínač s otevřeným zdrojovým kódem, určený pro použití ve virtualizovaných prostředích jako virtuální forwarder provozu.
V současné době má OVS velmi slušnou funkcionalitu, která zahrnuje takové technologie jako QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK atd.
Poznámka: původně nebyl OVS zamýšlen jako softwarový přepínač pro vysoce zatížené telekomunikační funkce a byl spíše určen pro méně náročné na průchodnost IT funkce typu WEB serveru nebo poštovního serveru. Nicméně OVS se vyvíjí a současné implementace OVS výrazně zlepšily jeho výkon a schopnosti, což umožňuje jeho použití operátorům s vysokými zatíženími, například existuje implementace OVS s podporou DPDK akcelerace.
Existují tři důležité komponenty OVS, které je třeba znát:
- Kernel module — komponenta umístěná v prostoru jádra, která provádí zpracování provozu na základě pravidel získaných od řídícího prvku;
- vSwitch daemon (ovs-vswitchd) je proces běžící v uživatelském prostoru, který zodpovídá za programování jádrového modulu – tedy představuje přímo logiku fungování přepínače.
- Databázový server je místní databáze umístěná na každém hostiteli, na kterém běží OVS, kde je uložena konfigurace. Skrze tento modul mohou komunikovat SDN kontroleři prostřednictvím protokolu OVSDB.
K tomu všemu ještě přichází soubor diagnostických a řídících nástrojů, jako jsou ovs-vsctl, ovs-appctl, ovs-ofctl atd.
V současné době je Openstack široce používán telekomunikačními operátory k migraci síťových funkcí, jako jsou EPC, SBC, HLR atd. Některé funkce mohou bez problémů fungovat s OVS v takové podobě, jaká je, ale například EPC zpracovává provoz odběratelů – tedy provozuje obrovské množství dat (v současnosti objemy dat dosahují několika stovek gigabitů za sekundu). Je jasné, že podávat tento provoz přes jádrový prostor (jelikož je defaultně forwarder umístěn tam) není nejlepší nápad. Proto se často OVS nasazuje zcela v uživatelském prostoru s využitím technologie zrychlení DPDK k přesměrování provozu z NIC do uživatelského prostoru, čímž se obchází jádro.
Poznámka: pro cloud nasazený pro telekomunikační funkce je možný variant výstupu provozu z compute uzlu přímo do přepínacího zařízení, a to bez OVS. K tomu se používají mechanismy SR-IOV a Passthrough.
Jak to funguje na reálném modelu?
A nyní se přesuňme k praktické části a podívejme se, jak to celé funguje v praxi.
Nejprve nasadíme jednoduchou instalaci Openstack. Protože nemám k dispozici sadu serverů pro experimenty, budeme vytvářet model na jednom fyzickém serveru z virtuálních strojů. Ano, samozřejmě pro komerční cíle toto řešení není vhodné, ale abychom se podívali na příkladu, jak funguje síť v Openstacku, taková instalace pro tento účel stačí. Taková instalace je pro vzdělávací účely dokonce zajímavější – protože můžeme zachytit provoz atd.
Jelikož potřebujeme vidět pouze základní část, můžeme nevytvářet několik sítí, ale vše nastavit s použitím pouze dvou sítí, přičemž druhá síť v tomto modelu bude používána výhradně pro přístup k undercloud a DNS serveru. Venkovní sítě prozatím nebudeme zmiňovat – to je téma pro samostatný velký článek.
Takže začneme postupně. Nejprve si představíme trochu teorie. Budeme instalovat OpenStack pomocí TripleO (OpenStack na OpenStack). Podstatou TripleO je, že nainstalujeme OpenStack all-in-one (tj. na jednu nodu), nazývaný undercloud, a dále využijeme vlastnosti nasazeného OpenStacku k instalaci OpenStacku určeného pro provoz, nazývaného overcloud. Undercloud bude používat vestavěnou možnost spravovat fyzické servery (bare metal) — projekt Ironic — pro provisionování hypervisorů, které budou plnit role compute, control a storage nod. To znamená, že nepoužíváme žádné externí prostředky pro nasazení OpenStacku — OpenStack nasazujeme vlastními silami. V průběhu instalace se to stane mnohem jasnějším, takže se nezastavíme a půjdeme dál.
Poznámka: V tomto článku pro zjednodušení jsem se rozhodl nepoužívat síťovou izolaci pro interní sítě OpenStack a vše bylo nasazeno s použitím pouze jedné sítě. Nicméně přítomnost nebo absence izolace sítí neovlivňuje základní funkčnost řešení — vše bude fungovat přesně tak, jako při použití izolace, ale provoz bude probíhat v jedné síti. Pro komerční instalaci je samozřejmě nutné použít izolaci pomocí různých VLANů a rozhraní. Například provoz správy úložiště Ceph a provoz dat (přístup strojů k diskům atd.) při izolaci používají různé podsítě (Storage management a Storage), což činí řešení odolnějším odchylkám, neboť tento provoz lze rozdělit například na různé porty, nebo použít různé QoS profily pro různý provoz, aby datový provoz nevytlačil signální provoz. V našem případě však budou probíhat v jedné a téže síti a vlastně nás to nijak neomezuje.
Poznámka: Pokud plánujeme spouštět virtuální stroje ve virtuálním prostředí založeném na virtuálních strojích, je nejprve třeba povolit nested virtualizaci.
Zkontrolovat, zda je nested virtualizace povolena, můžete takto:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Pokud vidíte písmeno N, povolte podporu nested virtualizace podle jakéhokoli návodu, který najdete na internetu, například .
Musíme sestavit tuto schéma z virtuálních strojů:
V mém případě pro propojení virtuálních strojů zapojených do budoucí instalace (mám jich celkem 7, ale vystačíte si i se 4, pokud nemáte mnoho prostředků) jsem použil OpenvSwitch. Vytvořil jsem jeden ovs most a připojil k němu virtuální stroje prostřednictvím portových skupin. K tomu jsem vytvořil xml soubor následujícího typu:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
ovs-network-1
7a2e7de7-fc16-4e00-b1ed-4d190133af67Zde jsou deklarovány tři portové skupiny — dvě access a jedna trunk (ta poslední byla nezbytná pro DNS server, ale můžete se bez ní obejít, nebo ji nainstalovat na hostitelské machines — podle toho, co vám vyhovuje). Poté s použitím této šablony deklarujeme naši existenci 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 dostupná, protože nemá VLAN tag. Abychom to opravili, je třeba zadat příkaz sudo ovs-vsctl set port ovs-br1 tag=100. Nicméně po restartu tento tag zmizí (pokud někdo ví, jak to udržet, budu velmi vděčný). Ale to není tak důležité, protože tuto adresu budeme potřebovat pouze během instalace a nebude nutná, když bude OpenStack zcela nasazen.
Dále vytvoříme stroj undercloud:
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=ttyS0Během instalace nastavíte všechny potřebné parametry, jako je název stroje, hesla, uživatelé, NTP servery atd. Můžete také rovnou nastavit porty, ale osobně mi přijde jednodušší po instalaci vstoupit do stroje přes konzoli a upravit potřebné soubory. Pokud již máte hotový obraz, můžete ho použít, nebo se můžete právě tak jako já — stáhnout minimální obraz CentOS 7 a použít ho k instalaci VM.
Po úspěšné instalaci by se měla objevit virtuální mašina, na kterou budete moci nainstalovat undercloud.
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningNejprve nainstalujeme potřebné nástroje během instalace:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Instalace Undercloud
Vytvoříme uživatele stack, nastavíme heslo, přidáme do sudoerů a povolíme mu provádět rootovské příkazy 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í uvedeme v souboru hosts celé jméno undercloud:
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 repozitáře a nainstalujeme potřebný software:
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, pak příkazy týkající se ceph zadávat nemusíte. Použil jsem verzi Queens, ale můžete použít jakoukoli jinou, která se vám líbí.
Dále zkopírujeme konfigurační soubor undercloud do domácího adresáře uživatele stack:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNyní je třeba upravit tento soubor a přizpůsobit ho naší instalaci.
Na začátek souboru je třeba 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 = 10Takže projdeme nastavení:
undercloud_hostname — celé jméno serveru undercloud, mělo by se shodovat se záznamem na DNS serveru
local_ip — místní adresa undercloud směrem k provisioning síti
network_gateway — tato stejná místní adresa, která bude sloužit jako gateway pro přístup do vnějšího světa během instalace overcloud uzlů, se také shoduje s místní IP
undercloud_public_host — adresa externího API, přiřazuje se jakákoli volná adresa z provisioning sítě
undercloud_admin_host adresa interního API, přiřazuje se jakákoli volná adresa z provisioning sítě
undercloud_nameservers — DNS server
generate_service_certificate — tento řetězec je v aktuálním příkladu velmi důležitý, protože pokud jej nenastavíte na hodnotu false, dostanete chybu při instalaci, problém je popsán na bugtrackeru Red Hat
local_interface interface v provisioning síti. Tento interface bude překonfigurován během nasazení undercloud, proto musí mít undercloud dva interface — jeden pro přístup k němu, druhý pro provisioning
local_mtu — MTU. Protože máme testovací laboratoř a MTU mám 1500 na portech OVS switche, je třeba nastavit hodnotu 1450, aby prošly zapečetěné v VxLAN pakety
network_cidr — provisioning síť
masquerade — použití NAT pro přístup do vnější sítě
masquerade_network — síť, která bude NAT-ována
dhcp_start — počáteční adresa poolu adres, ze kterého budou přidělovány adresy uzlům během nasazení overcloud
dhcp_end — koncová adresa poolu adres, ze kterého budou přidělovány adresy uzlům během nasazení overcloud
inspection_iprange — pool adres potřebných pro provádění introspekce (nesmí se překrývat s výše uvedeným poolu)
scheduler_max_attempts — maximální počet pokusů o instalaci overcloud (musí být větší nebo rovno počtu uzlů)
Jakmile je soubor popsán, můžete zahájit příkaz pro nasazení undercloud:
openstack undercloud install
Procedura trvá od 10 do 30 minut v závislosti na vašem hardwaru. Nakonec byste měli vidět následující výstup:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Instalace undercloud dokončena.
Soubor obsahující hesla této instalace je na
/home/stack/undercloud-passwords.conf.
Existuje také stackrc soubor na /home/stack/stackrc.
Tyto soubory jsou potřebné pro interakci se službami OpenStack a měly by být zabezpečeny.
#############################################################################Tento výstup potvrzuje, že jste úspěšně nainstalovali undercloud a nyní můžete zkontrolovat jeho stav a přejít k instalaci overcloud.
Pokud se podíváte na výstup ifconfig, uvidíte, že se objevil nový bridge interface.
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163 mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Tento rozhraní bude nyní použito pro nasazení overcloud.
Z následujícího výstupu je vidět, že všechny služby máme 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 uvedena konfigurace síťové části undercloud:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Instalace overcloud
V tuto chvíli máme pouze undercloud a chybí nám uzly, ze kterých bude overcloud sestaven. Proto jako první krok nasadíme potřebné virtuální stroje. Během nasazení undercloud automaticky nainstaluje operační systém a potřebný software na stroje overcloud – tedy nemusíme plně nasazovat stroj, stačí vytvořit disk (nebo disky) a určit jeho parametry – v podstatě dostaneme holý server bez nainstalovaného operačního systému.
Přejdeme do složky s disky našich virtuálních strojů a vytvoříme 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 160GJelikož pracujeme jako root, musíme změnit vlastníka těchto disků, abychom se vyhnuli problémům s oprávněním:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu \/var\lib\libvirt\images\*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# Poznámka: pokud neplánujete používat Ceph pro studijní účely, nevytvářejte minimálně 3 uzly se dvěma disky a v šabloně specifikujte, že budou použity virtuální disky vda, vdb atd.
Skvěle, nyní musíme všechny tyto stroje definovat:
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 jsou příkazy —print-xml > \/tmp\/storage-1.xml, které vytvářejí xml soubor s popisem každého stroje v adresáři \/tmp\, pokud jej nepřidáte, nebude možné definovat virtuální stroje.
Nyní musíme všechny tyto stroje definovat v programu 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 vypnuto
- compute-2 vypnuto
- control-1 vypnuto
- storage-1 vypnuto
- storage-2 vypnuto
[root@hp-gen9 ~]#Nyní malý detail — tripleO používá IPMI k řízení serverů během instalace a introspekce.
Introspekce je proces zkoumání hardwaru za účelem získání jeho parametrů potřebných pro následné provizionování uzlů. Introspekce se provádí pomocí ironic — služby určené pro práci s bare metal servery.
Ale tady je problém — pokud u fyzických serverů je IPMI oddělený port (nebo sdílený port, ale to není zásadní), u virtuálních strojů takové porty neexistují. Na pomoc přichází workaround s názvem vbmc — nástroj, který umožňuje emulovat IPMI port. Na tento detail by si měli dávat pozor zejména ti, kteří chtějí postavit takovou laboratoř na hypervizoru ESXI — pokud tedy vím, nevím, jestli v něm existuje ekvivalent vbmc, takže by se tímto problémem měli zabývat předtím, než vše nasadí.
Instalujeme vbmc:
yum install python2-virtualbmcPokud vaše OS nemůže najít balíček, přidejte repozitář:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNyní nastavíme nástroj. Tady je to zcela jednoduché. Je logické, že v seznamu vbmc nejsou žádné servery.
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Aby se objevily, je třeba je manuálně deklarovat následujícím způsobem:
[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 ~]#Domnívám se, že syntaxe příkazu je jasná i bez vysvětlení. Nicméně zatím jsou všechny naše relace ve stavu DOWN. Aby přešly do stavu UP, je třeba je zapnout:
[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í úprava — je třeba upravit pravidla firewallu (nebo ho úplně vypnout):
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
Teď se přihlásíme do undercloud a zkontrolujeme, že vše funguje. Adresa hostitelské mašiny je 192.168.255.200, na undercloud jsme přidali potřebný balíček ipmitool během přípravy na nasazení:
[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 vidíte, úspěšně jsme spustili kontrolní uzel přes vbmc. Teď ho 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é bude instalováno overcloud. K tomu musíme připravit json soubor s popisem našich uzlů. Všimněte si, že na rozdíl od instalace na holé servery je v souboru uveden port, na kterém je spuštěn vbmc pro každou z mašin.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Poznámka: Na kontrolním uzlu jsou dvě rozhraní, ale v tomto případě to není důležité, v této instalaci nám stačí jen jedno.
Nyní připravíme soubor JSON. Musíme uvést MAC adresu portu, přes který bude probíhat provisioning, parametry uzlů, pojmenovat je a uvést, jak se dostat na IPMI:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Nyní musíme připravit obrazy pro Ironic. K tomu je stáhneme přes wget a nainstalujeme:
(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áme obrazy do undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Obrázek "overcloud-full-vmlinuz" byl nahrán.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Název | Formát disku | Velikost | Stav |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | aktivní |
+--------------------------------------+------------------------+-------------+---------+--------+
Obrázek "overcloud-full-initrd" byl nahrán.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Název | Formát disku | Velikost | Stav |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | aktivní |
+--------------------------------------+-----------------------+-------------+----------+--------+
Obrázek "overcloud-full" byl nahrán.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Název | Formát disku | Velikost | Stav |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | aktivní |
+--------------------------------------+----------------+-------------+------------+--------+
Obrázek "bm-deploy-kernel" byl nahrán.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Název | Formát disku | Velikost | Stav |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | aktivní |
+--------------------------------------+------------------+-------------+---------+--------+
Obrázek "bm-deploy-ramdisk" byl nahrán.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Název | Formát disku | Velikost | Stav |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | aktivní |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Kontrolujeme, že se všechny obrazy úspěšně nahrály
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Název | Stav |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aktivní |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | aktivní |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | aktivní |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | aktivní |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aktivní |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Ještě jeden detail — je potřeba přidat DNS server:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Název | Síť | 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
+-------------------+-----------------------------------------------------------+
| Pole | Hodnota |
+-------------------+-----------------------------------------------------------+
| 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 je zastaralé a bude odstraněno v budoucnu. Místo toho použijte openstack CLI.
Aktualizováno subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Nyní můžeme zadat příkaz pro introspekci:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Zahájen Mistral Workflow tripleo.baremetal.v1.register_or_update. ID provedení: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Čekání na zprávy v frontě 'tripleo' bez časového omezení.
5 uzlů bylo úspěšně převedeno do stavu "manageable".
Uzly UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 úspěšně zaregistrovány
Uzly UUID b89a72a3-6bb7-429a-93bc-48393d225838 úspěšně zaregistrovány
Uzly UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e úspěšně zaregistrovány
Uzly UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 úspěšně zaregistrovány
Uzly UUID 766ab623-464c-423d-a529-d9afb69d1167 úspěšně zaregistrovány
Čekání na dokončení introspekce...
Zahájen Mistral Workflow tripleo.baremetal.v1.introspect. ID provedení: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Čekání na zprávy v frontě 'tripleo' bez časového omezení.
Introspekce uzlu b89a72a3-6bb7-429a-93bc-48393d225838 dokončena. Stav: SUCCESS. Chyby: žádné
Introspekce uzlu 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e dokončena. Stav: SUCCESS. Chyby: žádné
Introspekce uzlu bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 dokončena. Stav: SUCCESS. Chyby: žádné
Introspekce uzlu 766ab623-464c-423d-a529-d9afb69d1167 dokončena. Stav: SUCCESS. Chyby: žádné
Introspekce uzlu b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 dokončena. Stav: SUCCESS. Chyby: žádné
Úspěšně introspektovalo 5 uzlů.
Zahájen Mistral Workflow tripleo.baremetal.v1.provide. ID provedení: f5594736-edcf-4927-a8a0-2a7bf806a59a
Čekání na zprávy v frontě 'tripleo' bez časového omezení.
5 uzlů bylo úspěšně převedeno do stavu "available".
(undercloud) [stack@undercloud ~]$Jak je vidět z výstupu, vše proběhlo bez chyb. Zkontrolujeme, že všechny uzly jsou ve stavu available:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Název | UUID instance | Stav napájení | Stav nasazení | Údržba |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | vypnuto | available | Ne |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | vypnuto | available | Ne |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | vypnuto | available | Ne |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | vypnuto | available | Ne |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | vypnuto | available | Ne |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Pokud budou uzly v jiném stavu, obvykle manageable, pak něco nefungovalo, a je třeba se podívat do logu a zjistit, proč k tomu došlo. Mějte na paměti, že v tomto scénáři používáme virtualizaci a mohou se vyskytnout chyby spojené s použitím virtuálních strojů nebo vbmc.
Dále musíme určit, která uzel bude vykonávat jakou funkci — tedy specifikovat profil, s nímž bude uzel nasazen:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| UUID uzlu | Název uzlu | Stav zprovoznění | Aktuální profil | Možné profily |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | k dispozici | Žádný | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | k dispozici | Žádný | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | k dispozici | Žádný | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | k dispozici | Žádný | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | k dispozici | Žádný | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Název | RAM | Disk | Ephemeral | VCPUs | Je veřejný |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | Ano |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | Ano |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | Ano |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | Ano |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | Ano |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | Ano |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Určujeme 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-d9afb69d1167Kontrolujeme, že jsme udělali vše správně:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| UUID uzlu | Název uzlu | Stav provisioningu | Aktuální profil | Možné profily |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | dostupný | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | dostupný | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | dostupný | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | dostupný | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | dostupný | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Pokud je vše správně, zadáme příkaz pro 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 se samozřejmě budou používat přizpůsobené šablony, v našem případě to proces výrazně zkomplikuje, protože bude potřeba vysvětlit každou úpravu v šabloně. Jak bylo dříve zmíněno — pro tento účel bude stačit i jednoduchá instalace, abychom viděli, jak to funguje.
Poznámka: proměnná --libvirt-type qemu je v tomto případě nezbytná, protože budeme používat nested virtualizaci. Jinak se vám nebudou spouštět virtuální stroje.
Nyní máte přibližně hodinu, možná i více (záleží na výkonu hardwaru) a zůstává vám doufat, že po uplynutí této doby uvidíte následující zprávu:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Systém CREATE byl úspěšně dokončen
Systém overcloud CREATE_COMPLETE
Host 192.168.255.21 nebyl nalezen v /home/stack/.ssh/known_hosts
Zahájeno Mistral Workflow tripleo.deployment.v1.get_horizon_url. ID provedení: fcb996cd-6a19-482b-b755-2ca0c08069a9
Endpoint Overcloud: http://192.168.255.21:5000/
URL dashboardu Overcloud Horizon: http://192.168.255.21:80/dashboard
Soubor rc Overcloud: /home/stack/overcloudrc
Overcloud nasazen
(undercloud) [stack@undercloud ~]$Nyní máte téměř plnohodnotnou verzi OpenStacku, na které se můžete učit, provádět experimenty atd.
Zkontrolujeme, že vše funguje správně. V domovském adresáři uživatele stack jsou dvě soubory — jeden stackrc (pro správu undercloud) a druhý overcloudrc (pro správu overcloud). Tyto soubory je třeba zadat jako source, protože obsahují informace potřebné pro autentizaci.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$V mé instalaci je potřeba ještě jeden malý detail — přidat trasu na kontroléru, protože stroj, ze kterého pracuji, je v jiné síti. K tomu se přihlásíme na control-1 s účtem heat-admin a nastavíme trasu.
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Poslední přihlášení: Pá 14. srpna 09:47:40 2020 z 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254A nyní se můžete přihlásit do horizontu. Veškeré informace — adresy, přihlašovací jméno a heslo — se nacházejí v souboru /home/stack/overcloudrc. Konečná schéma vypadá následovně:
Mimochodem, v naší instalaci byly adresy strojů přidělovány přes DHCP a, jak vidíte, byly přidělovány "náhodně". Můžete v šabloně pevně určit, kterou adresu jakému stroji přiřadit během nasazení, pokud je to nutné.
Jak probíhá provoz mezi virtuálními stroji?
V tomto článku se podíváme na tři varianty průchodu provozu.
- Dvě stroje na jednom hypervizoru v jedné L2 síti.
- Dvě stroje na různých hypervizorech v jedné L2 síti.
- Dvě stroje v různých sítích (směrování mezi sítěmi).
Případy s výstupem do vnějšího světa přes externí síť, s využitím plovoucích adres a také distribuce směrování probereme příště, zatím se zaměříme na vnitřní provoz.
Pro ověření sestavíme takovou schéma:
Máme vytvořeno 4 virtuální stroje — 3 v jedné L2 síti — net-1, a další 1 v síti net-2.
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Název | ID nájemce | Stav | Stav úkolu | Stav napájení | Sítě |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | AKTIVNÍ| - | Běží | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | AKTIVNÍ| - | Běží | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | AKTIVNÍ| - | Běží | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | AKTIVNÍ| - | Běží | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Podíváme se, na jakých hypervizorech jsou umístěny vytvořené stroje:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 | (overcloud) [stack@undercloud ~]$
Stroje vm-1 a vm-3 se nacházejí na compute-0, stroje vm-2 a vm-4 se nacházejí na uzlu compute-1.
Dále byl vytvořen virtuální router pro možnost směrování mezi uvedený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é slouží 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 ~]$ Ale než se podíváme, jak se pohybuje provoz, pojďme si prohlédnout, co máme momentálně na kontrolním uzlu (který je také uzlem sítě) a na uzlu compute. Začneme uzlem compute.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Na nodě jsou v současnosti tři OVS mosty — br-int, br-tun, br-ex. Jak vidíme, mezi nimi existuje sada rozhraní. Pro snazší pochopení zakreslíme tato všechna rozhraní do schématu a podíváme se, co z toho vznikne.
Na adresách, kde jsou vztyčeny VxLAN tunely, je vidět, že jeden tunel je vztyčen na compute-1 (192.168.255.26), druhý tunel směřuje na control-1 (192.168.255.15). Zajímavé je, že br-ex nemá žádná fyzická rozhraní, a když se podíváme na nastavené toky, vidíme, že tento most nyní může pouze odhazovat provoz.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eht0: flags=4163 mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Jak je vidět z výstupu, adresa je připojena přímo na fyzický port, nikoli na virtuální mostové rozhraní.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ Podle první pravidla je třeba všechno, co přišlo z portu phy-br-ex, odmítnout.
V tomto mostu zatím nemůže být žádný jiný provoz kromě tohoto rozhraní (spojení s br-int), a podle odhozených paketů už do mostu dorazil BUM provoz.
Tedy, z této uzlu může provoz odejít pouze přes VxLAN tunel a jinak ne. Pokud však zapnete DVR, situace se změní, ale na to se podíváme příště. Při použití izolace sítí, například pomocí VLANů, budete mít více než jedno L3 rozhraní v 0. VLANu, ale VxLAN provoz bude vycházet z uzlu stejným způsobem, pouze je také zabaleno do nějakého vyhrazeného VLANu.
S compute uzlem jsme si poradili, přecházíme k control uzlu.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (interní)
eth0 1/2: (systém)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (interní)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (interní)
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 lze říci, že vše zůstává stejné, avšak IP adresa se již nenachází na fyzickém rozhraní, ale na virtuálním mostu. To bylo uděláno proto, že tento port je port, přes který bude provoz směrem do vnějšího světa.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163 mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Tento port je připojen k mostu br-ex a protože na něm nejsou žádné VLAN tagy, je tento port trunkovým portem, na kterém jsou povoleny všechny VLANy. V současnosti provoz odchází ven bez tagu, což dokazuje vlan-id 0 v předchozím výstupu.
Všechno ostatní v tuto chvíli odpovídá compute uzlu — stejné mosty, stejné tunely, které vedou k dvěma compute uzlům.
Sklady uzlů nebudeme v tomto článku probírat, ale pro pochopení je třeba říci, že síťová část těchto uzlů je až ukrutně jednoduchá. V našem případě je tam pouze jeden fyzický port (eth0) s přiřazenou IP adresou a to je vše. Neexistují žádné VxLAN tunely, tunelové mosty atd. — OVS tam vůbec není, protože to nemá smysl. Při použití izolace sítí — na tomto uzlu budou dva rozhraní (fyzické porty, body, nebo jednoduše dva VLANy — to není důležité — závisí to na tom, co chcete) — jedno pro správu, druhé pro provoz (zápis na disk VM, čtení z disku atd.).
Rozebrali jsme, co máme na uzlech v nepřítomnosti jakýchkoliv služeb. Nyní spustíme 4 virtuální stroje a podíváme se, jak se změní výše popsaná schéma — měly by se nám objevit porty, virtuální směrovače atd.
Naše síť zatím vypadá takto:
Máme po dvou virtuálních strojích na každém počítačovém uzlu. Na příkladu compute-0 se podívejme, jak je všechno připojeno.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Název Stav
----------------------------------------------------
1 instance-00000001 běží
3 instance-00000003 běží
[heat-admin@overcloud-novacompute-0 ~]$ Stroj má pouze jedno virtuální rozhraní — tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Rozhraní Typ Zdroj Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Toto rozhraní směřuje do linuxového mostu:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
název mostu id mostu STP povolen rozhraní
docker0 8000.0242904c92a8 ne
qbr5bd37136-47 8000.5e4e05841423 ne qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 ne qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Jak je z výstupu patrné, v mostě jsou pouze dvě rozhraní — tap95d96a75-a0 a qvb95d96a75-a0.
Zde bychom se měli na chvíli zastavit u typů virtuálních síťových zařízení v OpenStacku:
vtap — virtuální rozhraní připojené k instanci (VM)
qbr — Linux bridge
qvb a qvo — vEth pár připojený k Linux bridge a Open vSwitch bridge
br-int, br-tun, br-vlan — Open vSwitch mosty
patch-, int-br-, phy-br- — Open vSwitch patchová rozhraní spojující mosty
qg, qr, ha, fg, sg — porty Open vSwitch používané virtuálními zařízeními pro připojení k OVS
Jak chápete, pokud máme v mostě port qvb95d96a75-a0, který je vEth párem, tak někde je jeho protější strana, která by se logicky měla 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, port se nachází v br-int. Br-int funguje jako switch, který terminates porty virtuálních strojů. Kromě qvo95d96a75-a0 je v výstupu vidět port qvo5bd37136-47. To je port pro druhý virtuální stroj. Naše schéma nyní vypadá takto:
Otázka, která by měla ihned zaujmout pozorného čtenáře - proč je linux bridge mezi portem virtuálního stroje a portem OVS? Faktem je, že pro ochranu strojů se používají security groups, které nejsou nic jiného než iptables. OVS nepracuje s iptables, proto byl vymyšlen takový ‘fikus’. Nicméně už dávno se vyčerpává - přichází mu na pomoc conntrack v nových verzích.
To znamená, že v konečném důsledku schéma vypadá takto:
Dvě stroje na jednom hypervizoru v jedné L2 síti.
Protože dva dané VM se nachází v té samé L2 síti a na stejném hypervizoru, bude logické, že provoz mezi nimi půjde lokálně přes br-int, protože oba stroje budou ve 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-novocompute-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 ~]$ Dvě stroje na různých hypervizorech v jedné L2 síti.
Nyní se podívejme, jak bude probíhat provoz mezi dvěma stroji v jedné L2 síti, ale umístěnými na různých hypervizorech. Pokud mám být upřímný, nic se výrazně nezmění, prostě bude provoz mezi hypervizory probíhat prostřednictvím vxlan tunelu. Podívejme se na příkladu.
Adresa virtuálních strojů, mezi kterými budeme sledovat provoz:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Rozhraní Typ Zdroj 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
Rozhraní Typ Zdroj Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Sledujeme tabulku forwardingu 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, co to za port:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$To je patch-tun — tedy rozhraní v br-tun. Sledujeme, co se děje s paketem 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 ~]$ Paketu je zabaleno do VxLAN a odesláno 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 ~]$To je vxlan tunel na compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Jdeme na compute-1 a sledujeme, co se dále děje s paketem:
[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 forwardingu br-int na compute-1, a jak je vidět z výstupu výše, je viditelný přes port 2, který je portem 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 a dále sledujeme, že v br-int na compute-1 je MAC cíle:
[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 bude odeslán na port 3, za kterým již stojí virtuální stroj instance-00000003.
Všechny výhody nasazení Openstack pro studium na virtuální infrastruktuře spočívají v tom, že můžeme bez problémů zachytit provoz mezi hypervizory a podívat se, co se děje. To teď uděláme, spusťíme tcpdump na vnet portu směrem k compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: poslouchání na vnet3, typ odkazu EN10MB (Ethernet), velikost zachycení 262144 bajtů
*****************vynecháno*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), délka 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, vlajky [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), délka 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, délka 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), délka 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, vlajky [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), délka 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, délka 64
*****************vynecháno*******************První řádek ukazuje, že paket s adresou 10.0.1.85 jde na adresu 10.0.1.88 (ICMP provoz), přičemž je zabalen do VxLAN paketu s vni 22 a paket jde z hostitele 192.168.255.19 (compute-0) na hostitele 192.168.255.26 (compute-1). Můžeme ověřit, že VNI odpovídá tomu, který je uveden v ovs.
Vraťme se k tomuto řádku actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 — to je vni v šestnáctkové soustavě. Převodíme toto číslo na desítkovou soustavu:
16 = 6*16^0+1*16^1 = 6+16 = 22To znamená, že vni odpovídá realitě.
Druhý řádek ukazuje zpětný provoz, ale není potřeba ho vysvětlovat, tam je to jasné.
Dva stroje v různých sítích (směrování mezi sítěmi)
Poslední případ na dnešek — to je směrování mezi sítěmi uvnitř jednoho projektu s využitím virtuálního směrovače. Zvažujeme případ bez DVR (ten probereme v jiném článku), proto se směrování provádí na síťovém nodu. V našem případě síťový nod není vyčleněn jako samostatná entita a je umístěn na ovládacím nodu.
Nejdřív se podíváme, zda směrování funguje:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 datových bytů
64 bajty z 10.0.2.8: seq=0 ttl=63 doba=7.727 ms
64 bajty z 10.0.2.8: seq=1 ttl=63 doba=3.832 ms
^C
--- statistika pingu 10.0.2.8 ---
2 pakety odeslané, 2 pakety přijaté, 0% ztráty paketů
round-trip min/avg/max = 3.832/5.779/7.727 msProtože v tomto případě by paket měl odejít na bránu a tam být směrován, potřebujeme zjistit MAC adresu brány, proto se podíváme na ARP tabulku v instanci:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] na eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] na eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] na eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] na eth0Podívejme se, kam by měla být směrována doprava na adrese (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šechno dává smysl, doprava směřuje do br-tun. Podívejme se, do kterého vxlan tunelu bude zabalena:
[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ý směřuje k kontrolní uzlu:
[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 ~]$ Doprava dorazila do kontrolního uzlu, takže se na něj musíme přepnout a podívat se, jak bude probíhat směrování.
Jak si pamatujete, kontrolní uzel uvnitř vypadal přesně stejně jako compute uzel - stejné tři mosty, jen u br-ex byl fyzický port, přes který mohla uzel posílat dopravu ven. Vytvoření instancí změnilo konfiguraci na compute uzlech - přibyly linux bridge, iptables a rozhraní do uzlů. Vytvoření sítí a virtuálního směrovače také zanechalo svůj otisk na konfiguraci kontrolního uzlu.
Takže je zřejmé, že MAC adresa gateway by měla být v tabulce forwarding br-int na kontrolním uzlu. Zkontrolujme, že tam je a kam směřuje:
[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 zpět k seznamu virtuálních portů v Openstack, tento typ portu se používá pro připojení různých virtuálních zařízení k OVS. Přesněji qr je port směrem k virtuálnímu směrovači, který je reprezentován jako namespace.
Podívejme se, jaké namespace 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 ~]$ Celých tři instance. Ale podle názvů lze usoudit, k čemu každá z nich slouží. K instancím s ID 0 a 1 se vrátíme později, nyní nás zajímá namespace qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ V tomto namespace jsou dvě interní, které jsme vytvořili dříve. Oba virtuální porty byly přidány do br-int. Zkontrolujeme MAC adresu portu qr-0c52b15f-8f, protože traffic, podle cílové MAC adresy, směřoval právě do tohoto 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 mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ To znamená, že v tomto případě vše funguje podle pravidel standardního směrování. Protože traffic je určen hostiteli 10.0.2.8, měl by projít druhým rozhraním qr-92fa49b5-54 a odejít skrze VXLAN tunel na compute nodu.
[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šechno dává smysl, žádná překvapení. Podíváme se, odkud je vidět MAC adresa hostitele 10.0.2.8 v br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Jak se má, traffic jde do br-tun, podívejme se, do jakého tunelu traffic půjde dál:
[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 putuje tunelem do compute-1. A na compute-1 je to jednoduché — z br-tun packet jde 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 ~]$ Zkontrolujeme, že to je 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 ~]$ V podstatě jsme prošli celou cestu paketu. Myslím, že jste si všimli, že provoz šel různými vxlan tunely a vycházel s různými VNI. Pojďme se podívat, jaké to VNI jsou, poté uděláme dump na portu control node a ujistíme se, že provoz opravdu probíhá přesně tak, jak bylo popsáno výše.
Takže, tunel k compute-0 má následující actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Převodíme 0x16 na desítkový systém:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunel k compute-1 má následující VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Převodíme 0x63 na desítkový systém:
0x63 = 3*16^0+6*16^1 = 3+96 = 99A teď se podívejme na dump:
[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 vxlan paket z hostitele 192.168.255.19 (compute-0) na hostitele 192.168.255.15 (control-1) s vni 22, uvnitř kterého je zabalen ICMP paket z hostitele 10.0.1.85 na hostitele 10.0.2.8. Jak jsme spočítali výše, vni odpovídá tomu, co jsme viděli ve výstupech.
Druhý paket je vxlan paket z hostitele 192.168.255.15 (control-1) na hostitele 192.168.255.26 (compute-1) s vni 99, uvnitř kterého je zabalen ICMP paket z hostitele 10.0.1.85 na hostitele 10.0.2.8. Jak jsme spočítali výše, vni odpovídá tomu, co jsme viděli ve výstupech.
Dva následující pakety jsou zpětný provoz z 10.0.2.8 na 10.0.1.85.
To znamená, že jsme nakonec dostali takovou schéma control nodu:
Vypadá to, že máme všechno? Zapomněli jsme na dva namespace:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Jak jsme mluvili o architektuře cloudové platformy — bylo by dobré, aby stroje automaticky získávaly adresy od DHCP serveru. To jsou dva DHCP servery pro naše dvě sítě 10.0.1.0/24 a 10.0.2.0/24.
Ověříme, že je to tak. V tomto namespace je pouze jedna adresa — 10.0.1.1 — adresa samotného DHCP serveru, a také je zahrnuta v br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163 mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Podívejme se, zda existují procesy s názvem qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 na řídící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 ~]$ Existuje takový proces a na základě výše uvedených informací se můžeme například podívat, co máme momentálně v 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 ~]$Nakonec získáváme takový soubor služeb na řídícím uzlu:
Mějte na paměti — to jsou pouze — 4 stroje, 2 vnitřní sítě a jeden virtuální router… Nyní nemáme žádné externí sítě, spoustu různých projektů, z nichž každý má své vlastní (křížící se) sítě, a máme vypnutý distribuovaný router. Koneckonců na testovacím stánku byla pouze jedna řídící node (pro odolnost vůči poruchám by měly být tři nody). Je logické, že v komerční sféře je to „o něco“ složitější, ale na tomto jednoduchém příkladu rozumíme, jak to má fungovat — ať už máte 3 nebo 300 namespace, je to samozřejmě důležité, ale z pohledu fungování celé konstrukce se toho příliš nezmění… pokud samozřejmě nepřipojíte nějaký dodavatelský SDN. Ale to už je úplně jiný příběh.
Doufám, že to bylo zajímavé. Pokud máte připomínky/doplňky nebo pokud jsem někde otevřeně lhal (jsem člověk a můj názor bude vždy subjektivní) — napište, co je třeba opravit/přidat — všechno opravíme/přidáme.
Na závěr bych chtěl říct pár slov o srovnání OpenStacku (jak vanilkového, tak dodavatelského) s cloudovým řešením od společnosti VMWare — příliš často se mě na tuto otázku ptali za poslední dva roky a už jsem se k tomu upřímně unavil, ale přesto. Podle mě je velmi těžké tyto dvě řešení srovnat, ale jednoznačně lze říct, že nevýhody jsou u obou řešení a pokud vybíráte nějaké jedno řešení, musíte zvážit všechny pro a proti.
Pokud je OpenStack komunitně řízené řešení, pak VMWare má právo dělat pouze to, co chce (čtěte — co je pro ni výhodné), a to je logické — protože je to komerční společnost, která je zvyklá vydělávat peníze na svých zákaznících. Ale tady je jedno velké a tučné ALE — můžete přejít z OpenStacku například od Nokie a snadno se přestěhovat na řešení například od Juniperu (Contrail Cloud), ale přejít z VMWare se vám pravděpodobně nepodaří. Pro mě tato dvě řešení vypadají takto — OpenStack (dodavatelský) je jednoduchá klec, do které vás zavírají, ale máte klíč a můžete kdykoli odejít. VMWare — to je zlatá klec, klíč od klece je u majitele a bude vás stát velmi mnoho.
Nedoporučuji žádný z produktů, vyberte si to, co potřebujete. Kdybych měl takovou volbu, zvolil bych obě řešení — VMWare pro IT cloud (pro menší zátěže, snadná správa), OpenStack od nějakého dodavatele (Nokia a Juniper nabízejí velmi slušná řešení na klíč) — pro Telekom cloud. Nepoužil bych OpenStack čistě pro IT — to je jako střílet na vrabce z děla, ale kromě nadbytečnosti nevidím žádná další omezení. Nicméně použít VMWare v telekomunikacích — to je jako vozit štěrk v Fordu Raptor — vypadá to pěkně, ale řidič musí udělat 10 jízd místo jedné.
Podle mě je největším nedostatkem VMWare její úplná uzavřenost — společnost vám neposkytne žádné informace o tom, jak funguje například vSAN nebo co se skrývá v jádru hypervizoru — je to pro ni jednoduše výhodné — takže se nikdy nestanete odborníkem na VMWare — bez podpory dodavatele jste odsouzeni (často se setkávám s odborníky na VMWare, které zmate banální otázky). Pro mě je VMWare jako koupě auta se zamčeným kapotem — ano, možná máte specialisty, kteří dokážou vyměnit rozvodový řemen, ale kapotu může otevřít jen ten, kdo vám toto řešení prodal. Osobně nemám rád řešení, do kterých se nemohu dostat. Říkáte, že možná nebudete muset lézt pod kapotu. To je možné, ale podívám se na vás, když budete potřebovat v cloudu sestavit velkou funkci z 20-30 virtuálních strojů, 40-50 sítí, polovina z nich chce vyjít ven, a druhá polovina žádá o urychlení SR-IOV, jinak budete potřebovat ještě pár desítek takových strojů — jinak nebude výkon stačit.
Existují i jiné názory, takže je jen na vás, co si vyberete, a především — vy pak nesete odpovědnost za váš výběr. To je pouze můj názor — člověka, který viděl a dotýkal se minimálně 4 produktů — Nokia, Juniper, Red Hat a VMWare. To znamená, že mám s čím srovnávat.
Zdroj: habr.com
