Xen - Xen

Xen

Xen z NetBSD i trzema dystrybucjami Linuksa
Pierwotny autor (autorzy)	Keir Fraser, William Perkins jr, Steven Hand, Ian Pratt , Laboratorium Komputerowe Uniwersytetu Cambridge
Deweloper(zy)	Intel Fundacja Linuksa
Pierwsze wydanie	2003 ( 2003 )
Wersja stabilna	4.15/08 kwietnia 2021 ; 6 miesięcy temu ( 2021-04-08 )
Magazyn
Napisane w	C
Rodzaj	Nadzorca
Licencja	GPLv2
Strona internetowa	xenproject .org

Xen (wymawiane / oo ɛ n / ) jest typu 1 hypervisor , świadczenie usług, które umożliwiają wielokrotne komputerowe systemy operacyjne , aby wykonać na tym samym sprzęcie komputerowym jednocześnie. Został pierwotnie opracowany przez University of Cambridge Computer Laboratory, a obecnie jest rozwijany przez Linux Foundation przy wsparciu firm Intel , Citrix , Arm Ltd , Huawei , AWS , Alibaba Cloud , AMD , Bitdefender i epam .

Społeczność Xen Project rozwija i utrzymuje Xen Project jako wolne i otwarte oprogramowanie , podlegające wymogom GNU General Public License (GPL), wersja 2. Xen Project jest obecnie dostępny dla IA-32 , x86-64 i ARM zestawy instrukcji .

Architektura oprogramowania

Xen Project działa w bardziej uprzywilejowanym stanie procesora niż jakiekolwiek inne oprogramowanie na komputerze.

Do zadań hypervisora ​​należy zarządzanie pamięcią i planowanie CPU wszystkich maszyn wirtualnych ("domen") oraz uruchamianie najbardziej uprzywilejowanej domeny ("dom0") - jedynej maszyny wirtualnej, która domyślnie ma bezpośredni dostęp do sprzętu. Z dom0 można zarządzać hiperwizorem i uruchamiać domeny nieuprzywilejowane („domU”).

Domena dom0 jest zazwyczaj wersją systemu Linux lub BSD . Domeny użytkownika mogą być albo tradycyjnymi systemami operacyjnymi, takimi jak Microsoft Windows, w których uprzywilejowane instrukcje są dostarczane przez instrukcje wirtualizacji sprzętowej (jeśli procesor hosta obsługuje wirtualizację x86 , np. Intel VT-x i AMD-V ), albo parawirtualizowanymi systemami operacyjnymi, w których system operacyjny ma świadomość, że działa wewnątrz maszyny wirtualnej, dlatego wykonuje hiperwywołania bezpośrednio, zamiast wydawać uprzywilejowane instrukcje.

Xen Project uruchamia się z programu ładującego, takiego jak GNU GRUB , a następnie zwykle ładuje parawirtualizowany system operacyjny hosta do domeny hosta (dom0).

Historia

Xen powstał jako projekt badawczy na Uniwersytecie Cambridge prowadzonym przez Iana Pratta , starszego wykładowcę w Laboratorium Komputerowym , i jego doktoranta Keira Frasera. Pierwsze publiczne wydanie Xen zostało wydane w 2003 roku, a wersja 1.0 pojawiła się w 2004 roku. Niedługo potem Pratt i Fraser wraz z innymi absolwentami Cambridge, w tym Simonem Crosbym i założycielem Nick Gault, stworzyli XenSource Inc., aby przekształcić Xen w konkurencyjny produkt korporacyjny .

Aby wspierać systemy wbudowane, takie jak smartfony/IoT, przy stosunkowo niewielkich zasobach sprzętowych, architektura Secure Xen ARM na procesorze ARM została zaprezentowana na Xen Summit w dniu 17 kwietnia 2007 r., który odbył się w IBM TJ Watson. Pierwsze publiczne wydanie kodu źródłowego Secure Xen ARM zostało wydane na Xen Summit 24 czerwca 2008 r. przez Sang-bum Suh , absolwenta Cambridge, w Samsung Electronics.

22 października 2007 r. firma Citrix Systems zakończyła przejęcie XenSource, a projekt Xen został przeniesiony do domeny xen.org. Ten ruch rozpoczął się jakiś czas wcześniej i upublicznił istnienie Xen Project Advisory Board (Xen AB), w skład którego wchodzą członkowie Citrix , IBM , Intel , Hewlett-Packard , Novell , Red Hat , Sun Microsystems i Oracle . Xen Advisory Board doradza liderowi projektu Xen i odpowiada za znak towarowy Xen, na który Citrix bezpłatnie udzielił licencji wszystkim dostawcom i projektom wdrażającym hipernadzorcę Xen . Citrix wykorzystał również samą markę Xen do niektórych zastrzeżonych produktów niezwiązanych z Xen, w tym XenApp i XenDesktop .

15 kwietnia 2013 roku ogłoszono, że projekt Xen został przeniesiony pod auspicjami Linux Foundation jako projekt współpracy. Linux Foundation wprowadziła nowy znak towarowy dla „Xen Project”, aby odróżnić projekt od jakiegokolwiek komercyjnego wykorzystania starszego znaku towarowego „Xen”. W ramach przeniesienia uruchomiono nową witrynę społecznościową pod adresem xenproject.org. Członkowie projektu w momencie ogłoszenia obejmowały: Amazon, AMD, Bromium, CA Technologies, Calxeda, Cisco, Citrix, Google, Intel, Oracle, Samsung i Verizon. Sam projekt Xen jest samorządny.

Od wersji 3.0 jądra Linux obsługa Xen dla dom0 i domU istnieje w głównym jądrze.

Historia wydań

Zastosowania

Firmy świadczące usługi hostingu internetowego używają hipernadzorców do udostępniania wirtualnych serwerów prywatnych . Amazon EC2 (od sierpnia 2006), IBM SoftLayer , Liquid Web, Fujitsu Global Cloud Platform , Linode , OrionVM i Rackspace Cloud używają Xen jako głównego hipernadzorcy maszyn wirtualnych w swoich ofertach produktów.

Monitory maszyn wirtualnych (znane również jako hipernadzorcy) również często działają na komputerach mainframe i dużych serwerach z systemami IBM, HP i innymi. Wirtualizacja serwerów może zapewnić takie korzyści, jak:

• Konsolidacja prowadząca do zwiększonego wykorzystania
• Szybkie udostępnianie
• Dynamiczna odporność na awarie oprogramowania (poprzez szybkie uruchamianie lub ponowne uruchamianie)
• Odporność na uszkodzenia sprzętu (poprzez migrację maszyny wirtualnej na inny sprzęt)
• Bezpieczne separacje wirtualnych systemów operacyjnych
• Obsługa starszego oprogramowania oraz nowych instancji systemu operacyjnego na tym samym komputerze

Wsparcie Xen dla migracji na żywo maszyn wirtualnych z jednego hosta do drugiego pozwala na równoważenie obciążenia i uniknięcie przestojów.

Wirtualizacja przynosi również korzyści podczas pracy nad rozwojem (w tym rozwoju systemów operacyjnych): uruchamianie nowego systemu jako gość pozwala uniknąć konieczności ponownego uruchamiania fizycznego komputera w przypadku wystąpienia błędu. Systemy gości w trybie piaskownicy mogą również pomóc w badaniach nad bezpieczeństwem komputerów, umożliwiając badanie skutków działania niektórych wirusów lub robaków bez możliwości narażania systemu hosta.

Wreszcie, dostawcy urządzeń sprzętowych mogą zdecydować się na wysyłanie swoich urządzeń z kilkoma systemami gościa, aby móc wykonywać różne części oprogramowania, które wymagają różnych systemów operacyjnych.

Rodzaje wirtualizacji

Xen oferuje pięć podejść do uruchamiania systemu operacyjnego gościa:

• HVM (sprzętowa maszyna wirtualna)
• HVM ze sterownikami PV
• PVHVM (parawirtualizacja z pełną wirtualizacją sprzętową, czyli HVM ze sterownikami PVHVM)
• PVH (PV w kontenerze HVM)
• PV (parawirtualizacja).

Xen zapewnia formę wirtualizacji znaną jako parawirtualizacja, w której goście uruchamiają zmodyfikowany system operacyjny. Goście są modyfikowani tak, aby używali specjalnego hipercall ABI zamiast pewnych funkcji architektonicznych. Dzięki parawirtualizacji Xen może osiągnąć wysoką wydajność nawet na swojej architekturze hosta (x86), która ma reputację braku współpracy z tradycyjnymi technikami wirtualizacji. Xen może uruchamiać parawirtualizowanych gości ("goście PV" w terminologii Xen) nawet na procesorach bez wyraźnej obsługi wirtualizacji. Parawirtualizacja pozwala uniknąć konieczności emulowania pełnego zestawu usług sprzętowych i oprogramowania układowego, co ułatwia zarządzanie systemem fotowoltaicznym i zmniejsza powierzchnię ataku na potencjalnie złośliwych gości. Na 32-bitowej architekturze x86 kod jądra hosta Xen działa w pierścieniu 0 , podczas gdy hostowane domeny działają w pierścieniu 1 (jądro) i pierścieniu 3 (aplikacje).

Procesory obsługujące wirtualizację umożliwiają uruchamianie niezmodyfikowanych gości, w tym zastrzeżonych systemów operacyjnych (takich jak Microsoft Windows). Jest to znane jako wirtualizacja wspomagana sprzętowo , jednak w Xen jest to znane jako sprzętowa maszyna wirtualna (HVM). Rozszerzenia HVM zapewniają dodatkowe tryby wykonywania, z wyraźnym rozróżnieniem między najbardziej uprzywilejowanymi trybami używanymi przez hiperwizor z dostępem do rzeczywistego sprzętu (nazywanymi „trybem root” w x86) a mniej uprzywilejowanymi trybami używanymi przez jądra gościa i aplikacje z „ sprzęt” uzyskuje dostęp pod pełną kontrolą hipernadzorcy (w x86, znany jako „tryb non-root”; zarówno tryb root, jak i tryb non-root mają pierścienie 0–3). Zarówno Intel, jak i AMD wniosły modyfikacje do Xen, aby wykorzystać ich odpowiednie rozszerzenia architektury Intel VT-x i AMD-V. Korzystanie z rozszerzeń wirtualizacji ARM v7A i v8A pojawiło się wraz z Xen 4.3. Rozszerzenia HVM często oferują również nowe instrukcje umożliwiające bezpośrednie wywołania przez parawirtualizowanego gościa/sterownika do hipernadzorcy, zwykle używane do operacji we/wy lub innych operacji wymagających wysokiej wydajności. Dzięki temu goście HVM z odpowiednimi drobnymi modyfikacjami mogą uzyskać wiele korzyści związanych z wydajnością parawirtualizowanych we/wy. W obecnych wersjach Xen (do 4.2) tylko w pełni zwirtualizowani goście HVM mogą korzystać z udogodnień sprzętowych dla wielu niezależnych poziomów ochrony pamięci i stronicowania. W rezultacie w przypadku niektórych obciążeń goście HVM ze sterownikami fotowoltaicznymi (znani również jako PV-on-HVM lub PVH) zapewniają lepszą wydajność niż goście czysto PV. Xen HVM posiada emulację urządzenia opartą na projekcie QEMU , aby zapewnić wirtualizację I/O maszynom wirtualnym. System emuluje sprzęt za pośrednictwem załatanego demona „menedżera urządzeń” QEMU (qemu-dm) działającego jako backend w dom0. Oznacza to, że zwirtualizowane maszyny widzą emulowaną wersję dość podstawowego komputera. W środowisku krytycznym dla wydajności dyski PV-on-HVM i sterowniki sieciowe są używane podczas normalnej pracy gościa, więc emulowany sprzęt PC jest używany głównie do uruchamiania.

Cechy

Administratorzy mogą „migrować na żywo” maszyny wirtualne Xen między hostami fizycznymi w sieci LAN bez utraty dostępności. Podczas tej procedury sieć LAN iteracyjnie kopiuje pamięć maszyny wirtualnej do miejsca docelowego bez zatrzymywania jej wykonywania. Proces wymaga zatrzymania na około 60–300 ms, aby wykonać ostateczną synchronizację, zanim maszyna wirtualna zacznie działać w miejscu docelowym, zapewniając iluzję bezproblemowej migracji. Podobna technologia może służyć do zawieszania uruchomionych maszyn wirtualnych na dysku, „zamrażania” ich stanu działania w celu wznowienia w późniejszym terminie.

Xen można skalować do 4095 fizycznych procesorów, 256 VCPU na gościa HVM, 512 VCPU na gościa PV, 16 TB pamięci RAM na host i do 1 TB pamięci RAM na gościa HVM lub 512 GB pamięci RAM na gościa PV.

Dostępność

Hypervisor Xen został przeniesiony do kilku rodzin procesorów:

• Intel: IA-32, IA-64 (przed wersją 4.2), x86-64
• PowerPC: wcześniej obsługiwany w ramach projektu XenPPC, nie jest już aktywny po Xen 3.2
• ARM: wcześniej obsługiwane w ramach projektu XenARM dla starszych wersji ARM bez rozszerzeń wirtualizacji, takich jak Cortex-A9. Obecnie obsługiwane od Xen 4.3 dla nowszych wersji ARM z rozszerzeniami wirtualizacji, takimi jak Cortex-A15 .
• MIPS : port eksperymentalny XLP832

Zastępy niebieskie

Xen może być dostarczany na dedykowanej platformie wirtualizacyjnej, takiej jak Citrix Hypervisor (dawniej Citrix XenServer, a wcześniej XenEnterprise firmy XenSource).

Alternatywnie, Xen jest dystrybuowany jako opcjonalna konfiguracja wielu standardowych systemów operacyjnych. Xen jest dostępny i dystrybuowany z:

• Alpine Linux oferuje minimalny system dom0 ( Busybox , UClibc ), który można uruchomić z nośników wymiennych, takich jak pendrive'y USB.
• Arch Linux zapewnia niezbędne pakiety ze szczegółowymi instrukcjami konfiguracji na swojej Wiki.
• Debian Linux (od wersji 4.0 "etch") i wiele jego pochodnych;
• FreeBSD 11 zawiera eksperymentalne wsparcie hosta.
• Gentoo posiada niezbędne pakiety do obsługi Xen, wraz z instrukcjami na ich Wiki.
• Mageia (od wersji 4);
• NetBSD może działać jako domU i dom0.
• Dystrybucje oparte na OpenSolaris mogą działać jako dom0 i domU od wersji Nevada 75 i nowszych.
• openSUSE 10.x do 12.x: od 12.1 obsługiwane są tylko hosty 64-bitowe;
• Qubes OS używa Xen do izolowania aplikacji dla bezpieczniejszego pulpitu.
• SUSE Linux Enterprise Server (od wersji 10);
• Solaris (od 2013 z Oracle VM Server for x86 , wcześniej z Sun xVM );
• Ubuntu (od 12.04 "Precise Pangolin" ; także 8.04 "Hardy Heron" , ale bez jądra obsługującego dom0 w 8.10 "Intrepid Ibex" do 12.04.)

Goście

Systemy gości mogą działać w pełni zwirtualizowane (co wymaga obsługi sprzętu), parawirtualizowane (co wymaga zmodyfikowanego systemu operacyjnego gościa) lub w pełni zwirtualizowane ze sterownikami parawirtualizowanymi (PVHVM). Większość systemów operacyjnych, które mogą działać na komputerach PC, może działać jako gość Xen HVM. Następujące systemy mogą działać jako parawirtualizowane goście Xen:

• Linux
• FreeBSD w wersji 32-bitowej lub 64-bitowej przez PVHVM;
• OpenBSD poprzez PVHVM;
• NetBSD
• MINIX
• GNU Hurd (gnumach-1-oddział-Xen-oddział)
• Plan 9 z Bell Labs

Xen w wersji 3.0 wprowadził możliwość uruchamiania Microsoft Windows jako systemu operacyjnego gościa w niezmienionej formie, jeśli procesor hosta obsługuje wirtualizację sprzętu zapewnianą przez Intel VT-x (wcześniej o nazwie kodowej Vanderpool) lub AMD-V (wcześniej o nazwie kodowej Pacifica). Podczas opracowywania Xen 1.x, Microsoft Research wraz z grupą zajmującą się systemami operacyjnymi Uniwersytetu Cambridge opracowali port Windows XP na Xen — możliwy dzięki programowi Microsoft Academic Licensing Program. Warunki tej licencji nie pozwalają na publikację tego portu, chociaż dokumentacja doświadczenia pojawia się w oryginalnym dokumencie Xen SOSP . James Harper i społeczność open-source Xen zaczęli opracowywać sterowniki do parawirtualizacji wolnego oprogramowania dla systemu Windows. Zapewniają one sterowniki frontonu dla bloku Xen i urządzeń sieciowych oraz umożliwiają znacznie wyższą wydajność dysku i sieci w systemach Windows działających w trybie HVM. Bez tych sterowników cały ruch dyskowy i sieciowy musi być przetwarzany przez QEMU-DM. Następnie Citrix wydał na licencji BSD (i nadal utrzymuje) sterowniki PV dla systemu Windows.

Kierownictwo

Zewnętrzni deweloperzy zbudowali szereg narzędzi (znanych jako konsole zarządzania Xen), które ułatwiają wykonywanie typowych zadań związanych z administrowaniem hostem Xen, takich jak konfigurowanie, uruchamianie, monitorowanie i zatrzymywanie gości Xen. Przykłady obejmują:

• HyperVM oparty na sieci Web
• OpenNebula Management Toolkit chmura
• W openSUSE YaST i virt-man oferują graficzne zarządzanie VM
• OpenStack natywnie obsługuje Xen jako cel Hypervisora/Compute
• Apache CloudStack obsługuje również Xen jako hiperwizor
• PlateSpin Orchestrate firmy Novell zarządza również maszynami wirtualnymi Xen przeznaczonymi do dostarczania Xen w systemie SUSE Linux Enterprise Server.

Wersje komercyjne

• Citrix Hypervisor (dawniej XenServer, do 2019 r.)
• Huawei FusionSphere
• Oracle VM Server dla x86
• Cienka korporacja
• Virtual Iron (wycofany przez Oracle)
• Tygiel (hiperwizor) firmy Star Lab Corp.

Hypervisor Xen jest objęty Powszechną Licencją Publiczną GNU, więc wszystkie te wersje zawierają rdzeń wolnego oprogramowania z kodem źródłowym. Jednak wiele z nich zawiera autorskie dodatki.

Zobacz też

• CloudStack
• Maszyna wirtualna oparta na jądrze (KVM)
• OpenStack
• Obraz dysku wirtualnego
• tboot , oparty na TXT system integralności dla jądra Linux i hipernadzorcy Xen
• VMware ESX
• System operacyjny Qube

Bibliografia

Dalsza lektura

• Paul Venezia (13 kwietnia 2011) Strzelanina wirtualizacji: Citrix, Microsoft, Red Hat i VMware. Wiodący konkurenci w dziedzinie wirtualizacji serwerów mierzą się z największym wyzwaniem wirtualizacji InfoWorld , InfoWorld

Zewnętrzne linki

• Oficjalna strona internetowa