| Xen | |
|---|---|
| Xen se systémem NetBSD a třemi distribucemi Linuxu | |
| Typ | Virtualizační server |
| Vývojář | Projekt Xen, XenSource, Inc. |
| Zapsáno v | C [1] |
| Operační systém | Linux , OpenSolaris , BSD |
| První vydání | 2003 |
| Nejnovější verze | |
| Licence | GNU GPL 2 [3] |
| webová stránka | xenproject.org |
| Mediální soubory na Wikimedia Commons | |
Xen (pron. / ˈzɛn / ) je multiplatformní hypervizor vyvinutý na University of Cambridge Computer Lab a licencovaný pod licencí GPL . Hlavní vlastnosti: podpora režimu paravirtualizace vedle hardwarové virtualizace, minimální kód samotného hypervizoru díky odstranění maximálního počtu komponent mimo hypervisor.
Xen začal jako výzkumný projekt na University of Cambridge pod vedením Iana Pratta , který se později stal zakladatelem XenSource. Společnost podporovala vývoj open source verze (xen) a současně prodávala komerční verze softwaru s názvem XenServer a XenEnterprise.
První veřejné vydání Xenu bylo v roce 2003. V říjnu 2007 koupil Citrix XenSource a přejmenoval produkty:
Později byly přejmenovány na XenServer (Free), Essentials for XenServer Enterprise a Essentials for XenServer Platinum.
22. října 2007 Citrix dokončil převzetí XenSource [4] a bezplatný projekt se přesunul na xen.org.
21. října 2009 Citrix oznámil, že komerční verze XenServeru budou zcela zdarma [5] . Simon Crosby , hlavní inženýr divize virtualizace společnosti Citrix, uvedl: „XenServer je 100% zdarma a brzy bude plně open source. Zisk [z toho] vůbec neplánujeme“ [6] ). Přestože existuje bezplatná verze Citrix XenServer, XenCenter (software pro centralizovanou správu) není zdrojově kódován, i když je k dispozici ke stažení zdarma.
15. dubna 2013 Xen přešel pod křídla Linux Foundation [1] Archivováno 19. dubna 2013 na Wayback Machine
| Verze | Datum vydání | Poznámky |
|---|---|---|
| 1,0 | 2003.10.02 [7] [8] | |
| 2,0 | 5. 11. 2004 [9] | Živá migrace pro paravirtuální hostující stroje |
| 3.0 | 05.12.2005 [10] [11] |
Verze 3.0.4 také přidala: |
| 3.1 | 18.05.2007 [15] | Živá migrace pro hosty HVM, podpora XenAPI |
| 3.2 | 17.01.2008 [16] | "Přesměrování" PCI, "spánkový" režim ACPI S3. |
| 3.3 | 24.08.2008 [17] | Vylepšení předávání PCI a správy napájení. |
| 3.4 | 18.05.2009 [18] | Obsahuje první verzi „Xen Client Initiative“ (XCI). |
| 4,0 | 07.04.2010 [19] | Umožňuje linuxová jádra používat jako dom0 pomocí nového mechanismu PVOps. [dvacet] |
| 4.1 | 25.03.2011 [21] | Podpora více než 255 procesorů, vylepšená stabilita.( [22] ). |
| 4.2 | 17.09.2012 [23] | Podpora pro 4095 fyzických (a až 512 virtuálních) procesorů, podpora více segmentů PCI, vylepšené zabezpečení a dokumentace.( [24] ). |
| 4.3 | 09.07.2013 [25] | Experimentální podpora pro ARM. Zohlednění funkcí architektury NUMA v plánovači. Otevřete podporu vSwitch . |
| 4.4 | 10.03.2014 [26] | Podpora ARM je nyní stabilní. Podpora pro libxl knihovnou libvirt. Nové škálovatelné rozhraní pro kanály událostí. Podpora pro vytváření vnořených virtuálních prostředí na hardwaru Intel. Odebrána podpora pro x86 32-bit a ia64 (itanium) hypervizory. |
| 4.5 | 15.01.2015 [27] | Toolstack je nyní přepsán v C a nazývá se xl nebo libxl, čímž zcela nahrazuje starý toolstack xend, který byl napsán v pythonu. |
| 4.6 | 13.10.2015 [28] | |
| 4.7 | 24.06.2016 [29] | Vylepšení: zabezpečení, živé migrace, výkon a pracovní zátěž. Hardwarová podpora (ARM a Intel Xeon). [třicet] |
| 4.8.1 | 12.04.2017 [31] | |
| 4.9 | 28.07.2017 [32] | Poznámky k vydání Xen Project 4.9 |
| 4.10 | 12. 12. 2017 [33] | Poznámky k vydání Xen Project 4.10 |
| 4.11 | 10.07.2018 [34] | Poznámky k vydání Xen Project 4.11 |
| 4.12 | 2019.04.02 [35] | Poznámky k vydání Xen Project 4.12 |
Technologie virtuálních strojů umožňuje rozšířit funkčnost zařízení následujícími způsoby:
Základním konceptem hypervizoru je doména . Běžící kopie virtuálního stroje se nazývá doména. Pokud je virtuální počítač restartován, jeho doména je ukončena (v době restartu) a objeví se nová doména. Navíc i během migrace je obsah zkopírován z jedné domény do jiné domény. Téměř všechny virtuální stroje se tak během svého života postupně ocitnou v různých doménách. Xen operuje pouze s konceptem domény a koncept „virtuálního stroje“ se objevuje na úrovni administrace (aplikační programy, které řídí hypervizor).
Domény jsou několika typů. Nejznámější jsou dom0 a domU . dom0 je první spuštěná doména Xen, obvykle se automaticky vytvoří a načte ihned po načtení a inicializaci hypervizoru. Tato doména má speciální práva k ovládání hypervizoru a ve výchozím nastavení je veškerý počítačový hardware přístupný z dom0. Dom0 je ve skutečnosti místo, kde žije software, který spravuje Xen. dom0 je vždy sám.
domU je členská doména (zkratka pro User domain), která obsahuje doménu běžících virtuálních strojů. Obvykle nemá přístup ke skutečnému hardwaru a je „užitnou zátěží“ virtualizačního systému. Na rozdíl od dom0 může být domU mnoho (obvykle několik desítek).
stub-domain - doména, která provozuje velmi specializovaný OS, který poskytuje práci s jakýmkoliv hardwarem nebo ovladačem back-end. Jde o evoluci bezpečnostního modelu Xen.
domain builder (doménový konstruktor) - program, který vytvoří domU (nahraje do něj potřebný kód a řekne hypervizoru, aby se spustil). Kromě konstrukce domény se obvykle zabývá připojováním a konfigurací virtuálních zařízení dostupných pro virtuální stroj. Je také zodpovědná za proces migrace virtuálního stroje z hostitele na hostitele.
Paravirtualizace je přizpůsobení jádra spustitelného OS pro práci ve spojení s Xen, obvykle zkráceno na PV. Umožňuje dosáhnout velmi vysokého výkonu díky chybějící emulaci „skutečného hardwaru“, jednoduchosti rozhraní a zohlednění existence hypervizoru při provádění systémových volání v kódu jádra. Provádění privilegovaných operací je zakázáno, místo nich se provádějí hypercalls ( angl. hypercalls ) - požadavky z jádra hostujícího OS na hypervizor s požadavkem na provedení určitých operací. Ve většině případů změny při portování OS na Xen ovlivní pouze jádro OS, i když mohou zahrnovat drobné změny v systémových knihovnách (např. libc). Proces adaptace na Xen je velmi podobný portování pro novou platformu, ale je mnohem jednodušší díky snadné implementaci „hostující“ části ovladače (ovladače v Xenu se skládají ze dvou částí – jedna se spouští mimo Část ovladače v hostujícím systému je extrémně primitivní a slouží pouze jako překladač dotazů do druhé části (toto bylo provedeno záměrně pro usnadnění portování OS na Xen). Režim PV nepodporuje „vnořené“ režimy procesoru, jako je reálný-86, virtuální-86, přepínání mezi 32bitovým a 64bitovým režimem, podpora emulace hardwarové virtualizace atd. V tomto ohledu existuje režim PV- žádný počáteční fragment bootování počítače (s imitací kódu BIOS, bootloaderu atd.) a hostující jádro systému se okamžitě spustí v požadovaném režimu, stejně jako se spouštějí běžné programy. V tomto ohledu konkrétně Xen sám o sobě nemůže běžet v režimu PV (to znamená, že v režimu PV nelze spustit „vnořený“ hypervizor).
V režimu hardwarové virtualizace (HVM) hostující OS „neví“ o existenci hypervizoru. Xen pomocí modulů z QEMU emuluje skutečný hardware a umožňuje zavádění operačního systému. Na jeho konci by pro normální výkon měly být spuštěny ovladače PV, které implementují rychlé rozhraní s virtuálními zařízeními, podobně jako to funguje v režimu PV. Protože většina privilegovaných operací je emulována, je možné spustit Xen v režimu HVM z prostředí Xen. V tomto případě může vnořený hypervizor fungovat pouze v režimu PV.
Hypervizor Xen (pro verzi 3.4) implementuje minimální sadu operací pro správu hlavní paměti, stavu procesoru, časovačů procesoru v reálném čase a hodinových čítačů (TSC), přerušení a řízení DMA. Všechny ostatní funkce, jako je implementace diskových a blokových zařízení, vytváření a odstraňování virtuálních strojů, jejich migrace mezi servery atd., jsou implementovány v doméně kontroly. Vzhledem k tomu je velikost hypervizoru velmi malá (u verze 3.4 je velikost binárního kódu celého hypervizoru necelých 600 KB), stejně jako velikost jeho zdrojového kódu. Dle záměru autorů se tím zvyšuje stabilita virtualizačního systému, protože chyba v komponentách mimo hypervizor nevede ke kompromitaci/poškození samotného hypervizoru a omezuje poškození pouze na vadné komponentě, aniž by zasahovala do zbytku.
Z hypervisoru jsou přesunuty všechny funkce související s provozem sítě, blokových (diskových) zařízení, emulace video adaptérů a dalších zařízení. Většina těchto zařízení se skládá ze dvou částí: ovladačů v domU a programů v dom0. Ovladač (nejčastěji zabudovaný v jádře OS nebo načtený jako modul) implementuje minimální množství práce, ve skutečnosti překládá požadavky z OS do programu v dom0. Většinu práce udělá program v dom0. V tomto případě program nejčastěji běží jako samostatný proces pro každé obsluhované zařízení. Porucha v takovém programu vede k poruše pouze jednoho zařízení (blok, síť) a nemá vliv na chod dalších kopií programu (tedy neovlivňuje síťová/bloková zařízení jiných domén, popř. jiná zařízení stejné domény).
Tradičně se používá následující terminologie: frontend je část modulu umístěná v domU, backend je část umístěná v dom0. U některých typů zařízení může být zadní část odlišná, přičemž je zachována stejná přední část. Ovladač blokového zařízení může mít například backend ve formě imageru VHD, ovladače blokového zařízení, iniciátoru iscsi a tak dále.
Xen poskytuje tři komunikační mechanismy pro domény: jeden s hypervizorem (hypercalls) a dva mezi doménami. Nejčastěji dochází k interakci mezi dom0 a domU, i když model umožňuje interakci mezi dvěma domU.
Interakce mezi doménami se dělí na dva typy: události (události) a sdílená paměť (přístup ke sdílené paměti). Třetí možnost, přenos stránky paměti, je speciální případ přístupu ke sdílené paměti.
Události slouží zhruba ke stejnému účelu jako přerušení v architektuře x86 nebo signály v Unixu – rychlý synchronní nebo asynchronní přenos signálu o výskytu nějaké události. Přístup ke sdílené paměti poskytuje možnost přenášet značné množství informací a události poskytují přenosovou rychlost.
Události lze maskovat nebo odmaskovat. Odmaskované události způsobují zpětné volání (volání funkce, jejíž adresa byla předána dříve) a umožňují zpracovat událost ihned po jejím výskytu. Maskované události pouze nastavují příznak, že událost nastala, a obsluha pravidelně hledá, zda se událost (jedna nebo více) vyskytla. Druhá metoda umožňuje nevolat zpětné volání pro každou událost a v případě častých událostí výrazně zkracuje dobu zpracování. Naopak první možnost (se zpětným voláním) umožňuje zvýšit rychlost zpracování události, která se nemusí vyskytovat příliš často, ale vyžaduje okamžitou reakci.
Xen (prostřednictvím zásobníku pro správu) podporuje migraci hostovaných virtuálních strojů přes síť. Migrace paravirtuálních strojů je podporována od verze Xen 2 a HVM - od verze 3. Migrace může probíhat s vypnutým hostujícím systémem nebo přímo v průběhu tzv. "živé" migrace ( anglicky live migrace ) bez ztráty dostupnost.
Je vyžadováno, aby oba fyzické servery Xen viděly stejné úložiště, kde jsou uložena data virtuálního stroje. To je nutné, protože při migraci virtuálního počítače se nezkopíruje jeho souborový systém, protože by to zabralo příliš mnoho času i v případě rychlé sítě. Sdílené úložiště může být založeno na různých technologiích SAN nebo NAS , jako je Fibre Channel , iSCSI nebo DRBD .
Vzhledem k tomu, že samotný hypervizor (cca 500-600 KB) implementuje pouze „jádro“ systému, všechny ostatní funkcionality jsou přesunuty do aplikační vrstvy běžící v dom0. Sada programů, které implementují funkce mimo Xen, se nazývá angličtina. toolstack (neexistuje žádný ustálený překlad, někdy se používá termín „management stack“).
Existují dvě verze sady nástrojů pro Xen: založená na xendu (zahrnutá ve většině distribucí Xen) a založená na xapi (zahrnutá v Citrix XenServer a Xen Cloud Platform). Xend byl vyvíjen ve stejné době jako Xen, napsaný v Pythonu a od samého začátku byl pod licencí open source. Xapi byl proprietární pro Xensource (dále jen Citrix), ale byl uvolněn pod GPL v roce 2009. Xapi je napsán v OCaml , v době psaní měl menší sadu funkcí, ale byl stabilnější.
Ve verzi 4.5 byl xend napsaný v pythonu nahrazen xl/libxl napsaným v C.
Obě verze sady nástrojů obsahují následující nástroje:
Toolstack zajišťuje správu virtuálních strojů (vytváření/mazání, start/stop, migrace, připojení zdrojů atd.). Sada nástrojů navíc poskytuje správu prostředků pro rozsáhlé systémy: vytváří a udržuje úložiště pro ukládání obrazů disků virtuálních strojů (SR - storage repository), podporuje serverové fondy pro migraci virtuálních strojů a dokáže spravovat složité konfigurace místní sítě, včetně s podporou VLAN . Kromě toho je podporováno rozhraní dálkového ovládání XenApi založené na XML-RPC [36] .
Xen podporuje každý den více a více platforem.
Jako hybridní hypervizor typu 1 běží Xen přímo na hardwarové platformě, ale ke spuštění vyžaduje hostitelský operační systém v dom0. Xen podporuje procesory počínaje Pentium II , existují verze pro architektury x86-64 , PowerPC , Itanium (až do verze 4.4) a ARM (stabilní od verze 4.4). Načítání Xenu se provádí zavaděčem jako je GRUB nebo podobným. Ihned po načtení Xen spustí operační systém v dom0.
Většina instalací používá Linux jako operační systém pro doménu dom0 control. Po dlouhou dobu nebyla podpora Xen součástí oficiálního linuxového jádra a existovala jako sada záplat pro jádro v2.6.18. Od verze 2.6.37 se v linuxovém jádře objevil mechanismus pv_ops pro interakci s hypervizory [37] . Tento mechanismus umožňuje jádru pracovat jak v paravirtuálním režimu, tak přímo na hardwaru. Počínaje Xen 4.0 podporuje mechanismus pv_ops pro linuxové jádro v dom0 [38] . Linuxová jádra vyšší než 3.0 také plně podporují Xen pro dom0 i domU [39] .
Také následující operační systémy mohou fungovat jako dom0:
Většinu operačních systémů lze provozovat v režimu hardwarové virtualizace HVM, k dosažení vysoké rychlosti provádění se však používá technologie paravirtualizace. Následující hostované operační systémy lze v domU provozovat v paravirtuálním režimu:
Porty dalších operačních systémů, jako je Plan 9 , jsou také v práci. Očekává se, že oficiální porty pro Xen budou uvolněny pro všechny tyto operační systémy (jako se stalo pro NetBSD).
Operační systémy rodiny Microsoft Windows mohou běžet v režimu plné virtualizace HVM počínaje Xen 3 na procesorech, které podporují hardwarovou virtualizaci. V tomto případě jsou virtuální zařízení (disk, síť) emulována pomocí speciální verze QEMU . Pro zrychlení Windows lze použít tzv. paravirtuální ovladače . Na rozdíl od Linuxu v paravirtuálním režimu je jádro Windows nemodifikované a běží v režimu virtualizace hardwaru, ale ovladače zařízení přistupují k Xenu přímo (prostřednictvím HyperCalls), čímž obcházejí emulační vrstvu QEMU. Dochází k vývoji paravirtualizačních ovladačů pod licencí GPL pro Windows a produkty Citrix XenServer a Oracle VM obsahují podepsané paravirtualizační ovladače pro Windows.
Xen je široce používán jako virtualizační komponenta v cloud computingu a vyhrazených soukromých serverových službách . Hostingové společnosti jako Amazon Elastic Compute Cloud , Liquid Web , Fujitsu Global Cloud Platform , [46] Linode , SparkNode [47] a Rackspace Cloud používají Xen jako hypervizor virtuálního stroje.
V současné době[ upřesnit ] Komunita Xen vyvíjí Xen Cloud Platform (XCP), systém virtualizace serverů. XCP pochází z bezplatné verze Citrix XenServer a je plně uvolněn pod GNU GPL .
Existuje několik komerčních produktů pro konsolidaci serverů založených na Xenu. Jedná se zejména o produkty jako: