Domov › Služby › Co je virtualizace kvm. Typy virtualizace: OVZ a KVM. Instalace a konfigurace virtuálního serveru

Co je virtualizace kvm. Typy virtualizace: OVZ a KVM. Instalace a konfigurace virtuálního serveru

Hypervizory, virtualizace a cloud

Analýza hypervizoru KVM

Obsahová řada:

O této sérii článků

Tento cyklus začíná s obecné informace o typech hypervizorů a virtualizaci systému a poté se podívá na funkce pěti hypervizorů, jejich instalační procesy a problémy se správou, které mohou nastat.

Tuto sérii článků můžete použít jako výchozí bod k pochopení role hypervizoru v cloudové virtualizaci nebo k prozkoumání jednotlivých článků, které vám pomohou určit, který hypervizor tím nejlepším možným způsobem vhodné pro konkrétní úkoly, řešený v cloudu.

Co potřebujete vědět, abyste mohli začít

Na bázi jádra Virtuální stroj(KVM) je kompletní řešení virtualizace závislá na platformě pro Linux na procesorech x86 s virtualizačními rozšířeními (Intel VT nebo AMD-V). Pro hosty je k dispozici také omezená podpora paravirtualizace pro Linux a Windows ve formě paravirtuálního síťového ovladače.

V současné době KVM komunikuje s jádrem prostřednictvím zaváděcího modulu jádra. Jsou podporovány různé hostované operační systémy, jako je Linux, BSD, Solaris, Windows, Haiku, ReactOS a AROS Research Operační systém. Upravená verze KVM (qemu) může běžet na Mac OS X.

Poznámka: KVM neprovádí žádnou samoemulaci; místo toho program běžící v uživatelském prostoru používá rozhraní /dev/kvm ke konfiguraci adresního prostoru hosta virtuální server, vezme své simulované I/O zdroje a namapuje svůj obraz na obraz hostitele.

Architektura KVM je znázorněna na obrázku 1.

Obrázek 1. Architektura KVM

Paravirtualizace

Paravirtualizace je metoda virtualizace, která poskytuje virtuální stroje softwarové rozhraní, podobný, ale ne identický se základním hardwarem. Účelem tohoto upraveného rozhraní je zkrátit čas strávený hostujícím operačním systémem prováděním operací, které jsou ve virtuálním prostředí mnohem obtížnější než v prostředí nevirtualizovaném.

Existují speciální „háky“, které umožňují hostujícím a hostitelským systémům požadovat a potvrzovat řešení těchto složitých úkolů, které by bylo možné provádět ve virtuálním prostředí, ale mnohem pomaleji.

V architektuře KVM běží virtuální stroj jako normální proces Linuxu naplánovaný standardním plánovačem Linuxu. Ve skutečnosti se každý virtuální procesor jeví jako běžný linuxový proces. To umožňuje KVM využít všech funkcí Linuxová jádra.

Ovládací prvky emulace zařízení upravená verze qemu, který zajišťuje emulaci BIOSu, sběrnice PCI, sběrnice USB a také standardní sada zařízení jako např řadiče disků IDE a SCSI, síťové karty atd.

Funkčnost

Hlavní funkce KVM jsou uvedeny níže.

Bezpečnost

Vzhledem k tomu, že virtuální stroj je implementován jako proces Linux, používá standardní model Linux zabezpečení pro izolaci a správu zdrojů. S SELinux (Security-Enhanced Linux) linuxové jádro přidává povinné řízení přístupu, vrstvené a vícevrstvé zabezpečení a spravuje bezpečnostní politiku. SELinux poskytuje přísnou izolaci zdrojů a omezuje mobilitu procesů běžících v linuxovém jádře.

Projekt SVirt je snahou komunity integrovat bezpečnostní funkce a virtualizaci povinného přístupu (MAC). Na bázi Linuxu(KVM) – staví na SELinux a poskytuje infrastrukturu, která umožňuje správci definovat zásady izolace virtuálních strojů. SVirt je navržen tak, aby zajistil, že prostředky virtuálních strojů nebudou přístupné žádným jiným procesům (nebo virtuálním strojům); správce může tuto zásadu rozšířit definováním podrobných oprávnění; například, aby skupina virtuálních strojů sdílela stejné prostředky.

Správa paměti

KVM zdědí výkonné funkce správy paměti z Linuxu. Paměť virtuálního stroje je uložena stejně jako paměť jakéhokoli jiného linuxového procesu a lze ji zaměnit, zkopírovat do velkých stránek pro zlepšení výkonu, sdílet nebo uložit do souboru na disk. Podpora technologie NUMA (Non-Uniform Memory Access, architektura paměti pro víceprocesorové systémy) umožňuje virtuálním strojům efektivní přístup k velkému množství paměti.

KVM podporuje nejnovější funkce virtualizace paměti od výrobců procesorů, jako je Intel Extended Page Table (EPT) a AMD Rapid Virtualization Indexing (RVI), pro minimalizaci zatížení procesoru a dosažení vysoké propustnosti.

Sdílení stránek paměti je podporováno pomocí funkce jádra Kernel Same-page Merging (KSM). KSM skenuje paměť každého virtuálního stroje, a pokud jsou některé paměťové stránky virtuálních strojů identické, spojí je do jedné stránky, která se stane pro tyto virtuální stroje společnou a je uložena v jediné kopii. Li hostující systém snaží se to změnit obecná stránka, dostává vlastní kopii.

Ukládání dat

KVM může k ukládání obrazů virtuálních strojů použít jakákoli média podporovaná Linuxem, včetně lokální disky S IDE rozhraní, SCSI a SATA, Network Attached Storage (NAS), včetně NFS a SAMBA/CIFS, nebo SAN s podporou iSCSI a Fibre Channel. Vícevláknové I/O lze použít ke zlepšení propustnosti úložiště a redundance.

Opět, protože KVM je součástí linuxového jádra, lze použít osvědčenou a spolehlivou infrastrukturu úložiště s podporou všech předních výrobců; Jeho řada úložných funkcí byla ověřena v mnoha výrobních instalacích.

KVM podporuje obrazy virtuálních strojů na distribuovaných souborových systémech, jako je Global File System (GFS2), takže je lze sdílet mezi více hostiteli nebo sdílet pomocí logických svazků. Podpora jemné doladění (tenké zajišťování) diskových obrazů umožňuje optimalizovat využití zdrojů datových úložišť a nepřiděluje je všechny najednou předem, ale pouze tehdy, když to virtuální stroj vyžaduje. Proprietární diskový formát KVM, QCOW2, podporuje snímky a poskytuje několik úrovní snímků, komprese a šifrování.

Živá migrace

KVM podporuje živou migraci a umožňuje běžícím virtuálním strojům pohybovat se mezi fyzickými hostiteli bez přerušení služby. Živá migrace je pro uživatele transparentní: virtuální počítač zůstává zapnutý, síťová připojení- aktivní a uživatelské aplikace pokračují v běhu, zatímco se virtuální stroj přesune na nový fyzický server.

Kromě živé migrace podporuje KVM ukládání kopie aktuálního stavu virtuálního stroje na disk, což vám umožňuje jej uložit a později obnovit.

Ovladače zařízení

KVM podporuje hybridní virtualizaci, když jsou v hostujícím operačním systému nainstalovány paravirtualizované ovladače, což umožňuje virtuálním strojům používat optimalizované I/O rozhraní místo emulovaných zařízení. vysoký výkon I/O pro síťová a bloková zařízení.

Hypervizor KVM používá standard VirtIO vyvinutý společností IBM a Červený klobouk ve spolupráci s linuxovou komunitou pro paravirtualizované ovladače; Jedná se o rozhraní nezávislé na hypervizoru pro vytváření ovladačů zařízení, které umožňuje více hypervizorům sdílet stejnou sadu ovladačů zařízení a zlepšuje interoperabilitu mezi hosty.

Ovladače VirtIO jsou součástí moderní verze Linuxová jádra (nejnovější 2.6.25) jsou součástí Red Hat Enterprise Linux 4.8+ a 5.3+ a jsou také dostupná pro Red Hat Enterprise Linux 3. Red Hat vyvinul ovladače VirtIO pro hostující operační systémy Microsoft Windows optimalizace sítě a diskové operace I/O; tyto ovladače jsou certifikovány v rámci certifikačního programu společnosti Microsoft Hardware Windows Quality Labs (WHQL).

Výkon a škálovatelnost

KVM zdědí výkon a škálovatelnost Linuxu, podporuje virtuální stroje s 16 virtuálními procesory a 256 GB BERAN, stejně jako hostitelské systémy s 256 jádry a více než 1 TB RAM. Může poskytnout:

95-135% výkon ve srovnání s holým kovem ve skutečných podnikových aplikacích, jako jsou SAP, Oracle, LAMP a Microsoft Exchange;
více než milion zpráv za sekundu a latence menší než 200 mikrosekund ve virtuálních strojích běžících na standardním serveru;
maximální úrovně konsolidace od více než 600 virtuální stroje provozování podnikových aplikací na jediném serveru.

To znamená, že KVM dokáže virtualizovat nejnáročnější pracovní zátěže.

Nasazení virtualizace

Nasazení KVM je poměrně složitý proces, kompletní speciální požadavky do konfigurace, takže další informace naleznete v části.

Správa virtuálních strojů

Existuje několik správců virtuálních strojů. Mezi nimi:

Univention virtuální manažer;
qemu/KVM: spouští se přímo z příkazového řádku v počítači KVM;
Virsh: minimální shell pro správu virtuálních strojů;
Virtual Machine Manager: jinak - virt-manager, uživatelské rozhraní pro správu virtuálních strojů.

Výběr KVM

Pro:

navzdory skutečnosti, že KVM je relativně mladý hypervizor, to kompaktní modul, který v kombinaci s linuxovým jádrem poskytuje snadnou implementaci při zachování podpory pro linuxové těžké váhy;
KVM je flexibilní; Vzhledem k tomu, že hostované operační systémy komunikují s hypervizorem integrovaným do linuxového jádra, mohou ve všech případech přistupovat přímo k hardwaru bez nutnosti upravovat virtualizovaný operační systém. To dělá KVM více rychlé řešení pro virtuální stroje;
KVM patche jsou kompatibilní s linuxovým jádrem. KVM je implementováno v samotném linuxovém jádře, což usnadňuje správu virtualizačních procesů.

nevýhody:

výkonné nástroje pro správu serverů a virtuálních serverů KVM stroje neexistuje;
Podpora KVM potřebuje zlepšení virtuální sítě A virtuální systémyúložiště dat, vylepšené zabezpečení, vylepšená spolehlivost a odolnost, správa napájení, podpora HPC/reálný čas, škálovatelnost vCPU, kompatibilita mezi výrobci, přenositelnost virtuálních počítačů a vytvoření ekosystému cloudových služeb.

V Ubuntu se doporučuje používat jako nástroje pro správu KVM hypervisor (virtual machine manager) a knihovnu libvirt. Libvirt obsahuje sadu softwarových rozhraní API a uživatelských aplikací pro správu virtuálních strojů (VM), virt-manager (grafické rozhraní, GUI) nebo virsh ( příkazový řádek,CLI). Jak alternativní manažeři můžete použít convirt (GUI) nebo convirt2 (WEB rozhraní).

V současné době je na Ubuntu oficiálně podporován pouze hypervizor KVM. Tento hypervizor je součástí kódu operačního jádra Linuxové systémy. Na rozdíl od Xen KVM nepodporuje paravirtualizaci, což znamená, že pro její použití musí váš CPU podporovat technologie VT. Zda váš procesor podporuje tuto technologii, můžete zkontrolovat spuštěním příkazu v terminálu:

Pokud se jako výsledek zobrazí následující zpráva:

INFO: /dev/kvm existuje Lze použít akceleraci KVM

To znamená, že KVM bude fungovat bez problémů.

Pokud jste na výstupu obdrželi následující zprávu:

Váš procesor nepodporuje rozšíření KVM Akceleraci KVM NELZE použít

pak můžete stále používat virtuální stroj, ale bude mnohem pomalejší.

Nainstalujte 64bitové systémy jako hosté

Hostujícím systémům přidělte více než 2 GB paměti RAM

Instalace

Sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

Jedná se o instalaci na server bez X, tedy bez grafického rozhraní. Můžete jej nainstalovat pomocí příkazu

Sudo apt-get install virt-manager

Poté se v nabídce objeví položka „Správce virtuálních strojů“ a s vysokou mírou pravděpodobnosti bude vše fungovat. Pokud nějaké problémy přetrvávají, budete si muset přečíst pokyny na anglické wiki.

Vytvoření hostujícího systému

Postup pro vytvoření hostujícího systému pomocí GUI je poměrně jednoduchý.

Ale textový režim se dá popsat.

qcow2

Při vytváření systému pomocí GUI as pevný disk navrhuje se buď vybrat existující obrazový soubor nebo blokovat zařízení, nebo vytvořit nový soubor s nezpracovanými (RAW) daty. To však není zdaleka jediné dostupný formát soubory. Ze všech typů disků uvedených v man qemu-img je nejflexibilnější a nejmodernější qcow2. Podporuje snímky, šifrování a kompresi. Musí být vytvořen před vytvořením nového hosta.

Qemu-img create -o preallocation=metadata -f qcow2 qcow2.img 20G

Podle stejného muže qemu-img předběžné přidělení metadat (-o preallocation=metadata) způsobí, že disk bude zpočátku trochu větší, ale poskytuje lepší výkon v těch chvílích, kdy obraz potřebuje růst. Ve skutečnosti v v tomto případě Tato možnost vám umožní vyhnout se nepříjemné chybě. Vytvořený obrázek zpočátku zabírá méně než megabajt místa a podle potřeby roste do zadané velikosti. Hostující systém by měl toto finále okamžitě vidět specifikovaná velikost, nicméně během fáze instalace může vidět skutečnou velikost souboru. Přirozeně nainstalujte pevný disk 200 kB o velikosti odmítne. Chyba není specifická pro Ubuntu, objevuje se alespoň v RHEL.

Kromě typu obrazu si následně můžete zvolit způsob jeho připojení – IDE, SCSI nebo Virtio Disk. Výkon diskového subsystému bude záviset na této volbě. Neexistuje žádná definitivní správná odpověď, kterou musíte vybrat na základě úkolu, který bude přidělen hostujícímu systému. Pokud je hostující systém vytvořen „k prohlížení“, pak bude stačit jakákoli metoda. Obecně je to obvykle I/O, co je úzkým hrdlem virtuálního stroje, takže při vytváření vysoce zatíženého systému je třeba k tomuto problému přistupovat co nejzodpovědněji.

V tomto úvodním článku budu krátce mluvit o všem software, používané v procesu vývoje služby. Podrobněji se jim budeme věnovat v následujících článcích.

proč? Tento operační systém je mi blízká a srozumitelná, takže při výběru distribuce nedocházelo k žádnému trápení, trápení a přehazování. Nemá žádné zvláštní výhody oproti Red Hat Enterprise Linux, ale bylo rozhodnuto pracovat se známým systémem.

Pokud plánujete nasadit vlastní infrastrukturu pomocí podobných technologií, doporučil bych zvolit RHEL: díky dobré dokumentaci a dobře napsané aplikační programy to bude, ne-li řádově, tak určitě dvakrát jednodušší, a díky vyvinutému certifikačnímu systému bude možné bez větších problémů najít řadu specialistů, kteří se v tomto OS vyznají na patřičné úrovni.

Opět jsme se rozhodli použít Debian Squeeze se sadou balíčků od Sid/Experimentální a některé balíčky backportované a kompilované s našimi patchi.
Plánuje se zveřejnění úložiště s balíčky.

Při výběru virtualizační technologie byly zvažovány dvě možnosti – Xen a KVM.

Počítalo se také s tím, že existovalo obrovské množství vývojářů, hostitelů a komerčních řešení založených na Xenu – o to zajímavější bylo implementovat řešení založené na KVM.

Hlavním důvodem, proč jsme se rozhodli použít KVM, je potřeba provozovat virtuální stroje s FreeBSD a v budoucnu i s MS Windows.

Ke správě virtuálních strojů se ukázalo jako mimořádně výhodné používat produkty, které využívají jeho API: virsh, virt-manažerka, virt-install, pr.

Jedná se o systém, který ukládá nastavení virtuálních strojů, spravuje je, vede o nich statistiky, zajišťuje, že se rozhraní virtuálního stroje zvedne při spuštění, připojuje zařízení k počítači - obecně dělá spoustu věcí užitečná práce a ještě něco navíc.

Řešení samozřejmě není dokonalé. Mezi nevýhody patří:

Naprosto šílené chybové hlášky.
Nemožnost měnit část konfigurace virtuálního stroje za běhu, ačkoli QMP (QEMU Monitor Protocol) to umožňuje.
Někdy se z nějakého neznámého důvodu nelze připojit k libvirtd - přestane reagovat na vnější události.

Hlavním problémem při implementaci služby na samém počátku bylo omezení zdrojů pro virtuální stroje. V Xenu byl tento problém vyřešen pomocí interního plánovače, který rozděluje zdroje mezi virtuální stroje – a nejlepší je, že byla implementována i možnost omezit operace s diskem.

Nic takového v KVM nebylo až do příchodu mechanismu alokace zdrojů jádra. Jak už to v Linuxu bývá, přístup k těmto funkcím byl realizován prostřednictvím speciálu souborový systém cgroup, ve kterém lze pomocí normálních systémových volání write() přidat proces do skupiny, přiřadit mu váhu papouška, určit jádro, na kterém poběží, určit šířku pásma disku, kterou může proces používat, nebo znovu , přiřaďte mu váhu.

Výhodou je, že to vše je implementováno uvnitř jádra a lze to použít nejen pro server, ale také pro desktop (který byl použit ve slavném „~200 Line Linux Kernel Patch That Does Wonders“). A podle mého názoru je to jedna z nejvýraznějších změn ve větvi 2.6, nepočítám-li můj oblíbený #12309, a ne podání jiného souborového systému. Tedy snad kromě POHMELFS (ale čistě kvůli názvu).

Můj postoj k této knihovně nástrojů je velmi nejednoznačný.

Na jednu stranu to vypadá asi takto:

A tuhle věc je také zatraceně těžké sestavit ze zdroje, natož pak do balíčku: někdy se mi zdá, že Linux From Scratch je o něco snazší sestavit od začátku.

Na druhou stranu je to velmi výkonná věc, která umožňuje vytvářet obrazy pro virtuální stroje, upravovat je, komprimovat, instalovat grub, upravovat tabulku oddílů, spravovat konfigurační soubory, přenést "železné" stroje do virtuální prostředí, přenášet virtuální stroje z jednoho obrázku do druhého, přenášet virtuální stroje z obrázku na hardware a upřímně řečeno, zde mě má představivost trochu zklamala. Ach, ano: můžete také spustit démona uvnitř virtuálu Linuxové stroje a přistupovat k datům virtuálních strojů živě, a to vše v prostředí shell, python, perl, java, ocaml. To je krátké a daleko od toho úplný seznam s čím se dá dělat.

Zajímalo by mě co většina Kód v je generován v době montáže, stejně jako dokumentace k projektu. Ocaml a perl jsou široce používány. Samotný kód je napsán v C, který je následně zabalen do OCaml a opakované části kódu jsou generovány samy. Práce s obrazy se provádí spuštěním speciálního servisního obrazu (supermin zařízení), do kterého jsou kanálem odesílány příkazy. Tento záchranný obraz obsahuje určitou sadu nástrojů, jako je parted, mkfs a další užitečné pro správce systému.

Nedávno jsem to dokonce začal používat doma, když jsem z obrázku nandroidu vytáhl potřebná data. Ale to vyžaduje jádro s podporou yaffs.

Ostatní

Níže je několik dalších zajímavé odkazy popis použitého softwaru - v případě zájmu si jej přečtěte a prostudujte sami. Například,

Řekněme, že jste mladý, ale stále chudý student, což znamená, že ze všech možných platforem máte pouze PC na Windows a PS4. Jednoho krásného dne se rozhodnete přijít k rozumu a stát se programátorem, ale moudří lidé na internetu vám řekli, že bez Linuxu se nemůžete stát normálním inženýrem. Nemůžete nainstalovat Fedoru jako svůj hlavní a jediný systém, protože Windows je stále potřeba pro hry a VKontakte a strach nebo nedostatek zkušeností vám brání nainstalovat Linux jako druhý systém na váš pevný disk.

Nebo, řekněme, už jste vyrostli a nyní jste šéfem serverů v velká společnost a jednoho krásného dne si všimnete, že většina serverů není vytížena ani z poloviny. Zveřejnit více aplikací a z bezpečnostních důvodů nemůžete ukládat data na servery a náklady na podporu a údržbu rostoucí serverové farmy rychle rostou.

Nebo řekněme, že už máš vousy a brýle, ty technický ředitel a nejste spokojeni s tím, co vývojáři dostanou k nasazení nové aplikace nový server musíte počkat dva měsíce. Jak se v takových podmínkách rychle posunout vpřed?

Nebo jste možná architekt, který navrhl nový komplexní systém pro zpracování podnikových analýz. Váš systém obsahuje věci jako ElasticSearch, Kafka, Spark a mnoho dalšího a každá součást musí žít samostatně, být inteligentně nakonfigurována a komunikovat s ostatními součástmi. Jako správný inženýr chápete, že nestačí jednoduše nainstalovat celou tuto zoo přímo do vašeho systému. Musíte se pokusit nasadit prostředí co nejblíže budoucímu produkčnímu prostředí, a pokud možno tak, aby váš vývoj potom bez problémů fungoval na produkčních serverech.

A co dělat ve všech těchto těžkých situacích? Správně: použijte virtualizaci.

Virtualizace umožňuje nainstalovat mnoho operačních systémů, které jsou od sebe zcela izolované a běží vedle sebe na stejném hardwaru.

Trocha historie. První virtualizační technologie se objevily již v 60. letech, ale jejich skutečná potřeba se objevila až v 90. letech, kdy počet serverů stále více rostl. Tehdy nastal problém s efektivní recyklací veškerého hardwaru a také s optimalizací procesů aktualizace, nasazování aplikací, zajištění bezpečnosti a obnovy systémů v případě havárie.

Nechme v zákulisí dlouhou a bolestnou historii vývoje různých technologií a metod virtualizace – pro zvídavé čtenáře na konci článku bude doplňkové materiály na toto téma. Důležité je, k čemu to všechno nakonec došlo: tři hlavní přístupy k virtualizaci.

Přístupy k virtualizaci

Bez ohledu na přístup a technologii je při použití virtualizace vždy hostitelský stroj a na něm nainstalován hypervizor, který řídí hostující stroje.

V závislosti na použité technologii může být hypervizor buď samostatný software nainstalovaný přímo na hardwaru, nebo součást operačního systému.

Pozorný čtenář, který má rád buzzwords, začne během pár odstavců mumlat, že jeho oblíbené kontejnery Docker jsou také považovány za virtualizaci. O kontejnerových technologiích si povíme jindy, ale ano, máte pravdu, pozorný čtenáři, kontejnery jsou také určitým druhem virtualizace, pouze na úrovni prostředků stejného operačního systému.

Existují tři způsoby interakce virtuálních strojů s hardwarem:

Dynamické vysílání

V tomto případě virtuální stroje netuší, že jsou virtuální. Hypervizor zachycuje všechny příkazy z virtuálního stroje za chodu a zpracovává je, nahrazuje je bezpečnými a poté je vrací zpět do virtuálního stroje. Tento přístup samozřejmě trpí určitými problémy s výkonem, ale umožňuje virtualizovat jakýkoli OS, protože hostující OS není třeba upravovat. Dynamický překlad se používá v produktech VMWare, lídra v komerčním virtualizačním softwaru.

Paravirtualizace

V případě paravirtualizace zdrojový kód hostující OS je speciálně upraven tak, aby všechny instrukce byly prováděny co nejefektivněji a bezpečně. Virtuální žena si přitom vždy uvědomuje, že je virtuální ženou. Jednou z výhod je lepší výkon. Nevýhodou je, že takto nemůžete virtualizovat např. MacOS nebo Windows, ani žádný jiný OS, ke kterému nemáte přístup ke zdrojovému kódu. Paravirtualizace v té či oné formě se používá například v Xen a KVM.

Hardwarová virtualizace

Vývojáři procesorů si včas uvědomili, že architektura x86 není vhodná pro virtualizaci, protože byla původně navržena pro jeden OS najednou. Proto poté, co se objevil dynamický překlad z VMWare a paravirtualizace z Xen, začaly Intel a AMD vydávat procesory s hardwarovou podporou virtualizace.

Zpočátku to příliš nezvýšilo výkon, protože hlavním cílem prvních verzí bylo zlepšení architektury procesoru. Nicméně nyní, více než 10 let poté vznik Intelu VT-x a AMD-V není hardwarová virtualizace v žádném případě horší a dokonce v některých ohledech lepší než jiná řešení.

Hardwarová virtualizace využívá a vyžaduje KVM (Kernel-based Virtual Machine), který budeme používat i v budoucnu.

Virtuální stroj založený na jádru

KVM je virtualizační řešení zabudované přímo do linuxového jádra, které je stejně funkční jako ostatní řešení a má vynikající použitelnost. Navíc KVM je open source technologie, která přesto jde plnou rychlostí kupředu (jak z hlediska kódování, tak z hlediska marketingu) a do svých produktů ji implementuje společnost Red Hat.

To je mimochodem jeden z mnoha důvodů, proč trváme na distribucích Red Hat.

Tvůrci KVM se zpočátku soustředili na podporu hardwarové virtualizace a mnoho věcí znovu nevynalezli. Hypervizor je v podstatě malý operační systém, který musí být schopen pracovat s pamětí, sítí atd. Linux již tohle všechno umí perfektně, takže použití linuxového jádra jako hypervizoru je logické a krásné technické řešení. Každý virtuální KVM stroj- je to prostě oddělené Linuxový proces, zabezpečení je zajištěno pomocí SELinux/sVirt, zdroje jsou spravovány pomocí CGroups.

O SELinuxu a CGroups si povíme více v jiném článku, nelekejte se, pokud tato slova neznáte.

KVM nefunguje jen jako součást linuxového jádra: od verze jádra 2.6.20 je KVM základní součástí Linuxu. Jinými slovy, pokud máte Linux, pak již máte KVM. Pohodlné, že?

Za zmínku stojí, že na poli veřejných cloudových platforem Xen dominuje o něco více než zcela. Například AWS EC2 a Rackspace používají Xen. Je to dáno tím, že se Xen objevil dříve než všichni ostatní a jako první dosáhl dostatečné úrovně výkonu. Je tu ale dobrá zpráva: v listopadu 2017 postupně nahradí Xen u největšího cloudového poskytovatele.

Přestože KVM používá hardwarovou virtualizaci, pro některé ovladače I/O zařízení může KVM použít paravirtualizaci, která v určitých případech použití poskytuje zvýšení výkonu.

libvirt

Téměř jsme se dostali k praktické části článku, zbývá jen zvážit další open source nástroj: libvirt.

libvirt je sada nástrojů, které poskytují jediné API pro mnoho různých virtualizačních technologií. Při použití libvirt v zásadě nezáleží na tom, co je „backend“: Xen, KVM, VirtualBox nebo něco jiného. Kromě toho můžete použít libvirt v programech Ruby (a také Python, C++ a mnoho dalších). K virtuálním strojům se můžete také připojit vzdáleně prostřednictvím zabezpečených kanálů.

Mimochodem, libvirt vyvíjí Red Hat. Nainstalovali jste již Fedora Workstation jako svůj hlavní systém?

Pojďme vytvořit virtuální stroj

libvirt je pouze API, ale je na uživateli, jak s ním bude pracovat. Možností je spousta. Použijeme několik standardní inženýrské sítě. Připomínáme: trváme na používání distribucí Red Hat (CentOS, Fedora, RHEL) a níže uvedené příkazy byly testovány na jednom z těchto systémů. Pro ostatní Linuxové distribuce mohou nastat drobné rozdíly.

Nejprve se podívejme, zda je podporována hardwarová virtualizace. Ve skutečnosti bude fungovat bez jeho podpory, jen mnohem pomaleji.

egrep --color = auto "vmx|svm|0xc0f" /proc/cpuinfo # pokud se nic nezobrazuje, tak neexistuje podpora :(

Protože KVM je modul jádra Linuxu, musíte zkontrolovat, zda je již načten, a pokud ne, načtěte jej.

lsmod | grep kvm # kvm, kvm_intel, kvm_amd. Pokud se nic nezobrazí, musíte stáhnout požadované moduly # Pokud modul není načten modprobe kvm modprobe kvm_intel # nebo modprobe kvm_amd

Je možné, že virtualizace hardwaru je v systému BIOS zakázána. Pokud tedy nejsou načteny moduly kvm_intel/kvm_amd, zkontrolujte nastavení BIOSu.

Nyní pojďme nainstalovat požadované balíčky. Nejjednodušší způsob, jak toho dosáhnout, je nainstalovat skupinu balíčků najednou:

seznam yum skupiny "Virtuální*"

Seznam skupin závisí na použitém OS. Moje skupina byla volána Virtualizace. Chcete-li spravovat virtuální stroje z příkazového řádku, použijte obslužný program virsh. Zkontrolujte, zda máte alespoň jeden virtuální počítač pomocí příkazu virsh list. S největší pravděpodobností ne.

Pokud se vám nelíbí příkazový řádek, existuje také virt-manager - velmi pohodlné GUI pro virtuální stroje.

virsh může vytvářet virtuální stroje pouze z XML soubor s, jehož formát lze prostudovat v dokumentaci libvirt. Naštěstí existuje i virt-manager a příkaz virt-install. GUI můžete zjistit sami, ale zde je příklad použití virt-install:

sudo virt-install --name mkdev-vm-0 \ --location ~/Downloads/CentOS-7-x86_64-Minimal-1511.iso \ --memory = 1024 --vcpus = 1 \ --velikost disku = 8

Místo zadávání velikosti disku jej můžete vytvořit předem pomocí virt-manager nebo pomocí virsh a souboru XML. Použil jsem výše uvedený obrázek z Centos 7 minimal, který lze snadno najít na webu Centos.

Nyní zbývá jedna důležitá otázka: jak se připojit k vytvořenému stroji? Nejjednodušší způsob, jak to udělat, je přes virt-manager - stačí dvakrát kliknout na vytvořený stroj a otevře se okno s připojením SPICE. Čeká na vás obrazovka instalace OS.

Mimochodem, KVM může vnořit virtualizaci: virtuální stroje uvnitř virtuálního stroje. Musíme jít hlouběji!

Po ruční instalaci OS vás okamžitě napadne, jak lze tento proces automatizovat. K tomu potřebujeme nástroj nazvaný Kickstart, navržený tak, aby automaticky počáteční nastavení OS. Jedná se o jednoduchý textový soubor, ve kterém můžete zadat konfiguraci OS, až různé skripty, provedené po instalaci.

Ale kde mohu získat takový soubor? Proč to nenapsat od začátku? Samozřejmě ne: protože jsme již nainstalovali Centos 7 do našeho virtuálního stroje, stačí se k němu připojit a najít soubor /root/anaconda-ks.cfg - toto je konfigurace Kickstart, abychom vytvořili kopii již vytvořený OS. Stačí jej zkopírovat a upravit obsah.

Pouhé kopírování souboru je ale nuda, tak k tomu přidáme něco jiného. Faktem je, že ve výchozím nastavení se nebudeme moci připojit ke konzoli vytvořeného virtuálního stroje z příkazového řádku hostitelského stroje. Chcete-li to provést, musíte upravit konfiguraci zavaděč GRUB. Proto na úplný konec souboru Kickstart přidáme následující sekci:

%post --log = /root/grubby.log /sbin/grubby --update-kernel = ALL --args = "console=ttyS0" %end

%post , jak asi tušíte, bude spuštěn po instalaci OS. Příkaz grubby aktualizuje konfiguraci GRUB a přidá možnost připojení ke konzole.

Mimochodem, možnost připojení přes konzoli můžete určit i přímo při vytváření virtuálního stroje. Chcete-li to provést, musíte příkazu virt-install předat ještě jeden argument: --extra-args="console=ttyS0" . Poté můžete nainstalovat samotný OS do interaktivního textový režim z terminálu vašeho hostitelského počítače, připojení k virtuálnímu stroji přes virsh konzoli ihned po jeho vytvoření. To je zvláště výhodné, když vytváříte virtuální stroje na vzdáleném hardwarovém serveru.

Nyní můžete použít vytvořenou konfiguraci! virt-install vám umožňuje předat další argumenty při vytváření virtuálního počítače, včetně cesty k souboru Kickstart.

sudo virt-install --name mkdev-vm-1 \ --location ~/Downloads/CentOS-7-x86_64-Minimal-1511.iso \ --initrd-inject /cesta/k/ks.cfg \ --extra- args ks = soubor:/ks.cfg \ --paměť = 1024 --vcpus = 1 --velikost disku = 8

Po vytvoření druhého virtuálního stroje (zcela automaticky) se k němu můžete připojit z příkazového řádku pomocí příkazu virsh console vm_id. vm_id To zjistíte ze seznamu všech virtuálních strojů pomocí příkazu virsh list.

Jednou z výhod používání KVM/libvirt je úžasná dokumentace, včetně té, kterou vytvořil Red Hat. Milý čtenář je vyzván, aby si jej prostudoval s náležitou zvědavostí.

Vytvářet takovéto virtuální stroje ručně v konzoli a pak je nastavovat pouze pomocí Kickstartu samozřejmě není nejpohodlnější proces. V budoucích článcích se podíváme na mnoho skvělých nástrojů, které usnadňují konfiguraci systému a zcela automatizují.

co bude dál?

Není možné vměstnat vše, co stojí za to vědět o virtualizaci, do jednoho článku. Podívali jsme se na několik možností využití virtualizace a jejích výhod, ponořili se trochu hlouběji do detailů jejího fungování a seznámili se s nejlepším, podle nás, řešením těchto úloh (KVM), a dokonce jsme vytvořili a nakonfigurovali virtuální stroj.

Je důležité pochopit, že virtuální stroje jsou stavebními kameny moderních cloudových architektur. Umožňují aplikacím automaticky růst do neomezené velikosti a maximalizovat rychlým způsobem a s maximálním využitím všech zdrojů.

Bez ohledu na to, jak výkonný a bohatý na služby je AWS, jeho základem jsou virtuální stroje nad Xenem. Pokaždé, když vytvoříte nový droplet na DigitalOcean, vytvoříte virtuální stroj. Téměř všechny weby, které používáte, jsou hostovány na virtuálních počítačích. Jednoduchost a flexibilita virtuálních strojů umožňuje nejen budovat produkční systémy, ale také desetkrát usnadňuje místní vývoj a testování, zvláště když systém zahrnuje mnoho komponent.

Naučili jsme se, jak vytvořit jeden jediný stroj - není to špatné pro testování jedné aplikace. Ale co když potřebujeme několik virtuálních strojů najednou? Jak spolu budou komunikovat? Jak se najdou? K tomu budeme muset porozumět tomu, jak sítě obecně fungují, jak fungují v kontextu virtualizace a které komponenty se na této práci podílejí a je třeba je nakonfigurovat – v dalším článku ze série.

V tomto úvodním článku stručně představím všechny softwarové nástroje používané v procesu vývoje služby. Podrobněji se jim budeme věnovat v následujících článcích.

proč? Tento operační systém je mi blízký a srozumitelný, takže při výběru distribuce nedocházelo k žádnému trápení, trápení či zmítání. Nemá žádné zvláštní výhody oproti Red Hat Enterprise Linux, ale bylo rozhodnuto pracovat se známým systémem.

Pokud plánujete samostatné nasazení infrastruktury využívající podobné technologie, doporučil bych vám vzít si RHEL: díky dobré dokumentaci a dobře napsaným aplikačním programům to bude, když ne o řád, tak určitě dvakrát jednodušší, a díky vyvinutému certifikačnímu systému můžete snadno najít řadu specialistů, kteří jsou obeznámeni s tímto OS na správné úrovni.

Při výběru virtualizační technologie byly zvažovány dvě možnosti – Xen a KVM.

Hlavním důvodem, proč jsme se rozhodli použít KVM, je potřeba provozovat virtuální stroje s FreeBSD a v budoucnu i s MS Windows.

Ke správě virtuálních strojů se ukázalo jako mimořádně výhodné používat produkty, které využívají jeho API: virsh, virt-manažerka, virt-install, pr.

Jedná se o systém, který ukládá nastavení virtuálních strojů, spravuje je, vede o nich statistiky, zajišťuje, že se při startu zvedne rozhraní virtuálního stroje, připojuje zařízení k počítači - obecně odvádí spoustu užitečné práce a trochu víc než to.

Řešení samozřejmě není dokonalé. Mezi nevýhody patří:

Naprosto šílené chybové hlášky.
Nemožnost měnit část konfigurace virtuálního stroje za běhu, ačkoli QMP (QEMU Monitor Protocol) to umožňuje.
Někdy se z nějakého neznámého důvodu nelze připojit k libvirtd - přestane reagovat na vnější události.

Nic takového v KVM nebylo až do příchodu mechanismu alokace zdrojů jádra. Jak je v Linuxu obvyklé, přístup k těmto funkcím byl realizován prostřednictvím speciálního souborového systému cgroup, ve kterém lze pomocí normálních systémových volání write() přidat proces do skupiny, přiřadit mu váhu papouška, určit jádro, na kterém poběží, určit šířku pásma disku, kterou může proces používat, nebo znovu , přiřaďte mu váhu.

Můj postoj k této knihovně nástrojů je velmi nejednoznačný.

Na jednu stranu to vypadá asi takto:

A tuhle věc je také zatraceně těžké sestavit ze zdroje, natož pak do balíčku: někdy se mi zdá, že Linux From Scratch je o něco snazší sestavit od začátku.

Na druhou stranu je to velmi výkonná věc, která umožňuje vytvářet obrazy pro virtuální stroje, upravovat je, komprimovat, instalovat grub, upravovat tabulku oddílů, spravovat konfigurační soubory, přenášet hardwarové stroje do virtuálního prostředí, přenášet virtuální stroje z jednoho obrázku do druhého, přenést virtuální stroje z obrázku na hardware a abych byl upřímný, tady mě má představivost trochu zklamala. Ach, ano: můžete také spustit démona uvnitř virtuálního stroje Linux a přistupovat k datům virtuálního stroje živě, a to vše v prostředí shell, python, perl, java, ocaml. Toto je krátký a v žádném případě vyčerpávající seznam toho, s čím můžete dělat.

Zajímavé je, že většina kódu je generována v době montáže, stejně jako dokumentace k projektu. Ocaml a perl jsou široce používány. Samotný kód je napsán v C, který je následně zabalen do OCaml a opakované části kódu jsou generovány samy. Práce s obrazy se provádí spuštěním speciálního servisního obrazu (supermin zařízení), do kterého jsou kanálem odesílány příkazy. Tento záchranný obraz obsahuje určitou sadu nástrojů, jako je parted, mkfs a další užitečné pro správce systému.

Nedávno jsem to dokonce začal používat doma, když jsem z obrázku nandroidu vytáhl potřebná data. Ale to vyžaduje jádro s podporou yaffs.