Ma nehéz elképzelni egy világot számítógépes eszközök nélkül. Körülbelül 20 évvel ezelőtt szinte minden háztartási gép elektromechanikus volt, a használatról szólt számítógépes áramkörök mindenhol egy szó sem volt. A legelső számítógépek jelentős mennyiségű helyet foglaltak el, és viszonylag keveset tudtak csinálni. A számítógépes rendszerek az elmúlt években sokat fejlődtek. Bár a számítógépek alapvetően nem változtak, a számítási teljesítmény gyorsan nőtt. A számítógép egy egyszerű családban már nem valami különleges.
BAN BEN Ebben a pillanatban, gyakran nagyszámú a helyiségben lévő számítógépes berendezések jelentős kényelmetlenséget okozhatnak. Emiatt kezdtek megjelenni a központosított rendszerek. De a központosított rendszerek gyakran nem tudják megoldani azokat a problémákat, amelyeket a számítógépek hálózata old meg. Emiatt javasolták a virtualizáció koncepcióját, amikor egy központi számítógép számítógépek hálózataként működik.
Lényegében az egész operációs rendszer általában egyfajta virtuális környezet, amelyet a szoftverfejlesztő számára biztosítanak a végső feladatok végrehajtásának eszközeként. Már régen eltelt az idő, amikor a programokat kifejezetten számítógépes hardverhez írtak hardverkódok és lekérdezések segítségével. Ma minden alkalmazás mindenekelőtt valamilyen API-ra írt alkalmazás, amelyet az operációs rendszer vezérel. Az operációs rendszer feladata, hogy ezeknek az API-knak közvetlen hozzáférést biztosítson a hardver erőforrásokhoz.
Valójában többféle virtualizáció létezik:
A virtualizáció viszont megtörténik teljesÉs részleges.
Szoftvervirtualizáció– egyfajta virtualizáció, amely különféle operációs rendszer-könyvtárakat használ, és a virtuális gépek hívásait operációs rendszer hívásokká alakítja. (DOSBox, Virtualbox, VirtualPC)
Hardveres virtualizáció- speciális hardverutasításokat, különösen processzorutasításokat biztosító típus. Lehetővé teszi a lekérdezések végrehajtását a vendég operációs rendszert megkerülve, és közvetlenül a hardveren. ( KVM virtualizáció,virtualizáció XEN, Parallels, VMware, Virtualbox)
Operációs rendszer szintű virtualizáció– a platform csak egy részének virtualizálása, a hardver teljes virtualizálása nélkül. Az operációs rendszer környezet több példányának működését jelenti. (Docker, LXC)
Ez a cikk megvizsgálja Hardveres virtualizáció,és konkrétan a KVM virtualizáció.
1. séma – A virtuális gép komponenseinek interakciója a hardverrel
A közvetlen hardverkérések végrehajtásához az operációs rendszernek rendelkeznie kell egy olyan könyvtárral, amely közvetlenül küldi ezeket a kéréseket a hardvernek. A platformokon Linux alapok hosszú ideje egyszerűen nem volt beépített virtualizációs rendszer (beépített hypervisor). Minden virtualizációs szoftvergyártó, amely támogatta a hardvervirtualizációs technológiát, kénytelen volt saját modulokat létrehozni a Linux kernelhez (vboxdrv a Virtualboxban, vmware-service a VMWare-ben stb.). Ez természetesen nem tarthatott örökké, és a Qumranet, Inc. majd kivásárolta Radhat létrehozta az Open Virtualization Alliance-t, amely a Linux kernel alapszintű hypervisor hiányának megoldására gondolt. Így jött létre hipervizor KVM vagy Kernel alapú virtuális gép.
A KVM hypervisor egy betölthető Linux kernelmodul, amelyet arra terveztek, hogy virtualizációt biztosítson a Linux x86 platformon. Maga a modul tartalmazza magát a virtualizációs komponenst (kvm.ko), valamint a processzorspecifikus betölthető kvm-amd.ko vagy kvm-intel.ko modult.
A KVM használatának előfeltétele a virtualizációs utasítások támogatása - Intel VT vagy AMD, valamint a kernel Linux verziók 2.6.20 és magasabb. Van egy KVM port is a Free-BSD számára. A QEMU-t hagyományosan a KVM meghívására használják, de vannak erőfeszítések a KVM támogatás hozzáadására is a Virtualboxhoz.
A KVM maga nem végez emulációt. Ehelyett a felhasználói területen futó program a /dev/kvm interfészt használja a virtuális gép vendég címterének konfigurálásához, és ezen keresztül emulálja az I/O eszközöket és a videoadaptert.
A KVM lehetővé teszi a virtuális gépek számára a QEMU, VMware és más operációs rendszereket tartalmazó lemezképek módosítás nélküli használatát. Minden virtuális gépnek megvan a maga virtuális Hardver: hálózati kártyák, lemez, videokártya és egyéb eszközök.
Számos megvalósítás létezik ennek a hipervizornak a használatára. Némelyik egész speciális könyvtár, mások egyszerű grafikus alkalmazások formájában jelennek meg.
Az egyértelműség kedvéért a KVM-virtualizációt tekintjük a könyvtáron alapulónak virt-menedzser.
Ez a könyvtár lehetővé teszi a különféle hipervizorok hívásának egyszerűsítését, kényelmes felületet biztosítva a virtualizációs folyamat automatizálásához. Ezenkívül a könyvtár képes együttműködni a hálózati infrastruktúrával, ami néha fontos kliens-szerver munkaállomások építésénél.
2. séma – Libvirt komponensek kölcsönhatása
QEMU lehetővé teszi egy keret létrehozását a hypervisor meghívásához az ügyfélrendszeren. Ez a program hívási argumentumokkal konfigurálva parancs sor, elég könnyű és egyszerű.
Számos grafikus héj is létezik, mint pl Gnome-Boxok.
A virtualizáció a modern világ szerves része vállalati rendszerek, óriási pénzügyi és energiaforrások megtakarítását teszi lehetővé. A virtualizációs technológiák fejlesztése számos szervezet számára kiemelt feladat. Olyan technológiákat fejlesztenek ki, mint a VGAPassthrough (technológia a gazdagép videokártyájának virtuális gépbe történő „továbbítására”) és a PCIPassthrough (PCI-eszköz „továbbítása”).
A hypervisor támogatás ellenőrzése
Ellenőrizzük, hogy a szerver támogatja-e a virtualizációs technológiákat:
cat /proc/cpuinfo | egrep "(vmx|svm)"
Valami ilyesmit kellene kapnod válaszul:
zászlók: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp cgo konstans nonbfodts stop_tsc aperfm perf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm epb tpr_shadow vnmi flexpriority ept vpid dtherm ida arat
Ellenkező esetben lépjen a BIOS-ba, keresse meg a virtualizációs technológia engedélyezésének lehetőségét (különböző nevei vannak, például Intel Virtualization Technology vagy Virtualization), és engedélyezze - állítsa be az értéket Engedélyezze.
A kompatibilitást a következő paranccsal is ellenőrizheti:
* ha a parancs hibát ad vissza "kvm-ok parancs nem található", telepítse a megfelelő csomagot: apt-get install cpu-checker.
Ha látjuk:
INFORMÁCIÓ: /dev/kvm létezik
KVM gyorsítás használható
Ez azt jelenti, hogy van hardveres támogatás.
Kényelmünk érdekében létrehozunk egy könyvtárat, amelyben a KVM adatait tároljuk:
mkdir -p /kvm/(vhdd,iso)
* két könyvtár jön létre: /kvm/vhdd(virtuálishoz merevlemezek) És /kvm/iso(iso képekhez).
Állítsuk be az időt:
\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime
* ezt a parancsot beállítja a zónát a moszkvai idő szerint.
ntpdate ru.pool.ntp.org
* Szinkronizálunk az időszerverrel.
Telepítjük a KVM-et és a szükséges felügyeleti segédprogramokat.
a) Ubuntu 18.10-es verzióig
apt-get install qemu-kvm libvirt-bin virtinst libosinfo-bin
b) Ubuntu 18.10 után:
apt-get install qemu-kvm libvirt-daemon-system libvirt-bin virtinst libosinfo-bin
* Ahol qemu-kvm- hipervizor; libvirt-bin— hipervizor vezérlőkönyvtár; virtinst- menedzsment segédprogram virtuális gépek; libosinfo-bin— segédprogram az opciók listájának megtekintéséhez operációs rendszer, mely vendégként is használható.
Állítsuk be a szolgáltatást úgy, hogy automatikusan elinduljon:
systemctl enable libvirtd
Indítsuk el a libvirtd-t:
systemctl start libvirtd
A virtuális gépek működhetnek a NAT (amely egy KVM-kiszolgáló) mögött, vagy kaphatnak IP-címeket helyi hálózat— ehhez hálózati hidat kell beállítani. Ez utóbbit konfiguráljuk.
Használata távoli kapcsolat, gondosan ellenőrizze a beállításokat. Ha hiba történik, a kapcsolat megszakad.
Híd segédprogramok telepítése:
apt-get install bridge-utils
a) a hálózat beállítása a régiben Ubuntu verziók(/etc/network/interfaces).
Nyissa meg a konfigurációs fájlt a hálózati interfészek konfigurálásához:
vi /etc/network/interfaces
És tegyük ebbe a formába:
#iface eth0 inet statikus
# cím 192.168.1.24
# hálózati maszk 255.255.255.0
#átjáró 192.168.1.1
# dns-névszerverek 192.168.1.1 192.168.1.2
Auto br0
iface br0 inet statikus
cím: 192.168.1.24
hálózati maszk 255.255.255.0
átjáró 192.168.1.1
dns-névszerverek 192.168.1.1 192.168.1.2
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off
* ahol minden, ami ki van írva, a hálózatom régi beállításai; br0— a létrehozott híd interfészének neve; eth0— egy meglévő hálózati interfész, amelyen keresztül a híd működik.
Indítsa újra a hálózati szolgáltatást:
systemctl indítsa újra a hálózatot
b) hálózat felállítása az Ubuntu új verzióiban (netplan).
vi /etc/netplan/01-netcfg.yaml
*rendszerverziótól függően, konfigurációs fájl yaml más neve is lehet.
Hozzuk formába:
hálózat:
verzió: 2
renderer: networkd
Ethernetek:
eth0:
dhcp4: false
dhcp6: false
wakeonlan: igaz
Hidak:
br0:
macaddress: 2c:6d:45:c3:55:a7
interfészek:
-eth0
címek:
- 192.168.1.24/24
4. átjáró: 192.168.1.1
MTU: 1500
névszerverek:
címek:
- 192.168.1.1
- 192.168.1.2
paraméterek:
stp: igaz
előre-késleltetés: 4
dhcp4: false
dhcp6: false
* V ebben a példában létrehozunk egy virtuális hídfelületet br0; mint fizikai interfész használjuk eth0.
Hálózati beállítások alkalmazása:
Ragaszkodunk a hálózati forgalom átirányításához (hogy virtuális gépek NAT hálózati interfésszel elérheti az Internetet):
vi /etc/sysctl.d/99-sysctl.conf
Add hozzá a sort:
net.ipv4.ip_forward=1
Alkalmazza a beállításokat:
sysctl -p /etc/sysctl.d/99-sysctl.conf
Az első virtuális gép létrehozásához írja be a következő parancsot:
virt-install -n VM1\
--Automatikus indítás\
--noautoconsole\
--network=bridge:br0 \
--ram 2048 --arch=x86_64 \
--vcpus=2 --cpu host --check-cpu \
--lemez elérési útja=/kvm/vhdd/VM1-disk1.img,size=16 \
--cdrom /kvm/iso/ubuntu-18.04.3-server-amd64.iso \
--graphics vnc,listen=0.0.0.0,password=vnc_password \
--os-type linux --os-variant=ubuntu18.04 --boot cdrom,hd,menu=on
Azon a számítógépen, amelyről virtuális gépekkel tervezünk dolgozni, töltsön le egy VNC-klienst, például a TightVNC-t, és telepítse.
A szerveren beírjuk:
virsh vncdisplay VM1
a parancs megmutatja, hogy a VNC melyik porton fut a VM1 gépen. Nekem volt:
A * :1 azt jelenti, hogy 1-et kell hozzáadnia az 5900-hoz - 5900 + 1 = 5901.
Indítsa el a TightVNC Viewer programot, amelyet telepítettünk, és adja meg a csatlakozási adatokat:
Kattintson Csatlakozás. Amikor a rendszer jelszót kér, adja meg a virtuális gép létrehozásakor megadott jelszót ( vnc_password). Egy távoli konzol segítségével csatlakozunk a virtuális géphez.
Ha nem emlékszünk a jelszóra, a virtuális gép beállításait a következő paranccsal nyitjuk meg:
És megtaláljuk a sort:
* Ebben a példában jelszót használunk a virtuális gép eléréséhez 12345678 .
Példák azokra a parancsokra, amelyek hasznosak lehetnek virtuális gépekkel végzett munka során.
1. Szerezze meg a létrehozott gépek listáját:
virsh lista --all
2. Engedélyezze a virtuális gépet:
virsh start VMname
* Ahol VMname— a létrehozott gép neve.
3. Állítsa le a virtuális gépet:
Az ubuntu-vm-builder a Canonical által kifejlesztett csomag, amely megkönnyíti az új virtuális gépek létrehozását.
A telepítéshez írja be:
apt-get install ubuntu-vm-builder
A rendszeradminisztrátor életében eljön az az időszak, amikor a nulláról kell felépítenie egy vállalati infrastruktúrát, vagy át kell alakítania egy meglévőt, amely már örökölt. Ebben a cikkben arról fogok beszélni, hogyan kell megfelelően telepíteni a hipervizort Linux alapú KVM és libvirt LVM (logikai csoportok) támogatásával.
Végignézzük a hypervisor-kezelés minden bonyolultságát, beleértve a konzol- és grafikus felhasználói felület segédprogramjait, az erőforrás-bővítést és a virtuális gépek másik hipervizorra való áttelepítését.
Először is, értsük meg, mi az a virtualizáció. A hivatalos definíció a következő: „A virtualizáció a hardveres megvalósítástól elvonatkoztatott számítási erőforrások halmazának vagy logikai kombinációjának biztosítása, miközben az ugyanazon a fizikai erőforráson futó számítási folyamatok egymástól logikai elkülönítését biztosítja.” Vagyis emberi értelemben egy nagy teljesítményű szerverrel több közepes méretű szervert alakíthatunk ki, amelyek mindegyike elvégzi az infrastruktúrában rábízott feladatát anélkül, hogy másokat zavarna.
A vállalati virtualizációval szorosan együttműködő rendszergazdák, szakmájuk mesterei és virtuózai két táborra oszlanak. Néhányan a csúcstechnológiás, de őrülten drága VMware for Windows hívei. Mások amatőrök nyílt forráskódés ingyenes megoldások Linux virtuális gépen. Még hosszan sorolhatnánk a VMware előnyeit, de itt a Linux VM-en alapuló virtualizációra térünk ki.
Jelenleg két népszerű virtualizációs technológia létezik: az Intel VT és az AMD-V. Az Intel VT (az Intel Virtualization Technology cégtől) valós címzési módú virtualizációt valósít meg; a megfelelő hardveres I/O virtualizációt VT-d-nek nevezik. Ezt a technológiát gyakran a VMX (Virtual Machine eXtension) rövidítéssel emlegetik. Az AMD létrehozta saját virtualizációs bővítményeit, és kezdetben AMD Secure Virtual Machine-nek (SVM) hívta őket. Amikor a technológia piacra került, AMD Virtualization (rövidítve AMD-V) néven vált ismertté.
A hardver üzembe helyezése előtt győződjön meg arról, hogy a berendezés támogatja e két technológia valamelyikét (a specifikációkat megtekintheti a gyártó honlapján). Ha elérhető a virtualizációs támogatás, azt engedélyezni kell a BIOS-ban a hypervisor üzembe helyezése előtt.
A hypervisorokkal szemben támasztott egyéb követelmények közé tartozik a hardveres RAID támogatása (1, 5, 10), amely növeli a hypervisor hibatűrését a merevlemezek meghibásodása esetén. Ha a hardveres RAID nem támogatott, akkor végső megoldásként használhat szoftvert. De a RAID kötelező!
Az ebben a cikkben ismertetett megoldás három virtuális gépet tartalmaz, és sikeresen fut rajta minimális követelményeket: Core 2 Quad Q6600 / 8 GB DDR2 PC6400 / 2 × 250 GB HDD SATA (hardveres RAID 1).
Egy példa segítségével megmutatom, hogyan konfigurálhat hipervizort Debian Linux 9.6.0 - X64-86. Bármelyik Linux disztribúciót használhatja.
Amikor a hardver kiválasztása mellett dönt, és azt végül leszállítják, eljön az ideje a hypervisor telepítésének. Az operációs rendszer telepítésekor mindent a szokásos módon csinálunk, kivéve a lemezparticionálást. A tapasztalatlan rendszergazdák gyakran az „Összes automatikus felosztása” lehetőséget választják. lemez terület LVM használata nélkül." Ekkor minden adat egy kötetbe lesz írva, ami több okból sem jó. Először is, ha HDD Ha meghiúsul, elveszíti az összes adatát. Másodszor, a fájlrendszer megváltoztatása sok problémát okoz.
Általánosságban elmondható, hogy a felesleges lépések és az időveszteség elkerülése érdekében azt javaslom, hogy LVM-mel használja a lemezparticionálást.
A Logical Volume Manager (LVM) egy Linuxon és OS/2-n elérhető alrendszer, amely az Eszközleképezőre épül. Feladata a különböző területek egyben bemutatása merevlemez vagy területek több merevlemezről egyetlen logikai kötetként. Az LVM létrehoz egy logikai kötetcsoportot (VG - Volumes Group) a fizikai kötetekből (PV - Physical Volumes). Ez viszont logikai kötetekből áll (LV - Logical Volume).
Mostantól minden 2.6-os vagy újabb rendszermaggal rendelkező Linux disztribúció támogatja az LVM2-t. Az LVM2 használatához 2.4-es kernellel rendelkező operációs rendszeren telepítenie kell egy javítást.
Miután a rendszer merevlemezeket észlelt, elindul a merevlemez-partíciókezelő. Válassza az Irányított – a teljes használata lehetőséget lemez ésállítsa be az LVM-et.
Most kiválasztjuk azt a lemezt, amelyre a kötetcsoportunk telepítve lesz.
A rendszer lehetőséget kínál a média elrendezésére. Válassza az „Összes fájl írása egy partícióra” lehetőséget, és lépjen tovább.
A változtatások mentése után egy logikai csoportot és két kötetet kapunk benne. Az első a root partíció, a második pedig a swap fájl. Itt sokan felteszik a kérdést: miért nem választja ki manuálisan a jelölést, és maga hozza létre az LVM-et?
A válaszom egyszerű: VG logikai csoport létrehozásakor rendszerindító partíció A boot nem VG-re van írva, hanem külön partícióként jön létre az ext2 fájlrendszerrel. Ha ezt nem vesszük figyelembe, a rendszerindító kötet egy logikai csoportba kerül. Ez kínra és szenvedésre ítéli a rendszerindítási hangerő visszaállítása során. Ez az oka annak, hogy a rendszerindító partíció nem LVM-kötetre kerül.
Térjünk át a hypervisor logikai csoportjának konfigurációjára. Válassza ki a „Logical Volume Manager Configuration” elemet.
A rendszer értesíti, hogy minden változtatás lemezre kerül. Egyetértünk.
Alkossunk új csoport- nevezzük például vg_sata-nak.
A szerverek SATA, SSD, SAS, SCSI, NVMe adathordozókat használnak. Logikai csoport létrehozásakor célszerű nem a gazdagép nevét, hanem a csoportban használt adathordozó típusát megadni. Azt tanácsolom, hogy nevezze el a logikai csoportot így: vg_sata, vg_ssd, vg_nvme és így tovább. Ez segít megérteni, hogy a logikai csoport milyen médiából épül fel.
Készítsük el az első logikai kötetünket. Ez lesz az operációs rendszer gyökérpartíciójának kötete. Válassza a „Logikai kötet létrehozása” elemet.
Válasszon egy csoportot az új logikai kötethez. Nekünk csak egy van.
A logikai kötetnek nevet adunk. Név hozzárendelésekor a leghelyesebb az előtag használata egy logikai csoport neve formájában - például vg_sata_root, vg_ssd_root és így tovább.
Adja meg az új logikai kötet kötetét. Azt tanácsolom, hogy 10 GB-ot jelöljön ki a gyökér számára, de kevesebb is lehetséges, mivel a logikai kötet mindig bővíthető.
A fenti példával analóg módon a következő logikai köteteket hozzuk létre:
Az összes kötet elkészítése után befejezzük a menedzser munkáját.
Most több kötet áll rendelkezésünkre az operációs rendszer partícióinak létrehozásához. Nem nehéz kitalálni, hogy minden partíciónak megvan a maga logikai kötete.
Minden logikai kötethez létrehozunk egy azonos nevű partíciót.
Mentse el és rögzítse a végrehajtott változtatásokat.
A lemezelrendezési módosítások mentése után megkezdődik az alapvető rendszerkomponensek telepítése, majd a rendszer további rendszerösszetevők kiválasztására és telepítésére kéri. Az összes összetevő közül szükségünk lesz az ssh-serverre és a szabványos rendszer-segédprogramokra.
A telepítés után generálódik és lemezre íródik GRUB rendszertöltő. Telepítjük arra a fizikai lemezre, ahol a rendszerindító partíció mentve van, vagyis a /dev/sda-ra.
Most megvárjuk, amíg a rendszertöltő befejezi a lemezre írást, és az értesítés után újraindítjuk a hypervisort.
A rendszer újraindítása után SSH-n keresztül jelentkezzen be a hypervisorba. Először is, a root alatt telepítse a munkához szükséges segédprogramokat.
$ sudo apt-get install -y sudo htop képernyő net-tools dnsutils bind9utils sysstat telnet traceroute tcpdump wget curl gcc rsync
Konfigurálja az SSH-t ízlése szerint. Azt tanácsolom, hogy haladéktalanul hajtsa végre az engedélyezést a kulcsokkal. Indítsa újra és ellenőrizze a szolgáltatás működését.
$ sudo nano /etc/ssh/sshd_config $ sudo systemctl az sshd újraindítása; sudo systemctl állapot sshd
A virtualizációs szoftver telepítése előtt ellenőriznie kell a fizikai köteteket és a logikai csoport állapotát.
$sudo pvscan $sudo lvs
Virtualizációs összetevőket és segédprogramokat telepítünk, hogy hálózati hidat hozzunk létre a hypervisor felületen.
$ sudo apt-get update; apt-get upgrade -y $ sudo apt install qemu-kvm libvirt-bin libvirt-dev libvirt-daemon-system libvirt-clients virtinst bridge-utils
A telepítés után konfiguráljuk a hálózati hidat a hypervisoron. Megjegyzés a hálózati interfész beállításaihoz, és állítson be újakat:
$ sudo nano /etc/network/interfaces
A tartalom valami ilyesmi lesz:
Auto br0 iface br0 inet statikus cím 192.168.1.61 hálózati maszk 255.255.255.192 átjáró 192.168.1.1 broadcast 192.168.0.61 dns-nameserver 127.0 0 bridge_fd 0
Hozzáadjuk a felhasználónkat, aki alatt a hypervisorral fogunk dolgozni, a libvirt és kvm csoportokhoz (RHEL esetében a csoport neve qemu).
$ sudo gpasswd -a iryzhevtsev kvm $ sudo gpasswd -a iryzhevtsev libvirt
Most inicializálnunk kell a logikai csoportunkat, hogy működjön együtt a hypervisorral, indítsuk el, és a rendszer indulásakor hozzá kell adnunk az indításhoz.
$ sudo virsh pool-list $ sudo virsh pool-define-as vg_sata logikai --target /dev/vg_sata $ sudo virsh pool-start vg_sata; sudo virsh pool-autostart vg_sata $ sudo virsh pool-list
Ahhoz, hogy egy LVM csoport megfelelően működjön a QEMU-KVM-mel, először aktiválnia kell a logikai csoportot a virsh konzolon keresztül.
Most töltse le a disztribúciót a vendégrendszerekre való telepítéshez, és helyezze el a kívánt mappába.
$ sudo wget https://mirror.yandex.ru/debian-cd/9.5.0/amd64/iso-cd/debian-9.5.0-amd64-netinst.iso $ sudo mv debian-9.5.0-amd64-netinst .iso /var/lib/libvirt/images/; ls -al /var/lib/libvirt/images/
Ha virtuális gépekhez VNC-n keresztül szeretne csatlakozni, szerkessze az /etc/libvirt/libvirtd.conf fájlt:
$ sudo grep "listen_addr = " /etc/libvirt/libvirtd.conf
Töröljük a megjegyzéseket, és változtassuk meg a listen_addr = "0.0.0.0" sort. Mentjük a fájlt, újraindítjuk a hypervisort, és ellenőrizzük, hogy minden szolgáltatás elindult és működik-e.
A meghatározott időszakon belüli közösségi tagság hozzáférést biztosít az ÖSSZES Hacker anyaghoz, növeli a személyes kumulatív kedvezményt, és lehetővé teszi, hogy professzionális Xakep Score értékelést gyűjtsön!
A Cloud4Y-nál a VmWare termékeket tekintjük a vezető virtualizációs megoldásnak. Érdekelnek azonban minket más megoldások is, köztük a Xen és a KVM. És itt van az, amit észrevettünk: nem sok információ áll rendelkezésre ezeknek a hipervizoroknak az összehasonlításához: a legutóbbi jó kutatás, amit az interneten találtunk, 2012-ből származik, és természetesen már nem tekinthető aktuálisnak. Ma nem a legújabb, de véleményünk szerint igen hasznos kutatásokat mutatjuk be a KVM és Xen hipervizorok teljesítményéről.
Bocsássanak meg nekünk a virtualizációs guruk, de először emlékeztetjük az olvasókat, hogy mi is az a hypervisor, és mire van szükség. Különböző értelmű feladatok elvégzésére (fejlesztés szoftver, hosting stb.) a legegyszerűbb módja a virtuális gépek használata: ezek lehetővé teszik, hogy több különböző operációs rendszerrel rendelkezzen a megfelelő szoftverkörnyezet. A virtuális gépekkel való munka megkönnyítése érdekében hipervizorokat használnak - szoftver, amely lehetővé teszi a virtuális gépek gyors üzembe helyezését, leállítását és elindítását. A KVM az egyik legszélesebb körben használt hipervizor.
A KVM olyan szoftver, amely lehetővé teszi a virtualizáció megszervezését Linuxot és hasonló operációs rendszereket futtató számítógépeken. Az utóbbi időben a KVM a Linux kernel összetevőjének számít, és ezzel párhuzamosan fejlesztik. Ez a hipervizor csak olyan rendszereken használható, ahol a virtualizáció hardveresen támogatott – Intel és AMD processzorok használatával.
Kezdetben a cambridge-i hallgatók elindítottak egy projektet, amely végül a Xen kereskedelmi verziója lett. Az első kiadás 2003-as keltezésű, 2007-ben pedig a forráskódot megvásárolta a Citrix. A Xen egy többplatformos hipervizor, amely nagyszerű funkcionalitással és hatalmas képességekkel rendelkezik, amely lehetővé teszi a vállalati szférában való használatát. A Xen támogatja a paravirtualizációt, az operációs rendszer kernelének egy speciális módját, amikor a kernel úgy van beállítva, hogy egyidejűleg működjön a hypervisorral.
Csak a szükséges funkciókat adták hozzá a Xen kódhoz: virtuális memória és processzor órajel kezelése, DMA-val való munkavégzés, valós idejű időzítő és megszakítások. A többi funkcionalitás átkerül a tartományokba, vagyis az akkor futó virtuális gépekre. Így a Xen a legkönnyebb hypervisor.
Tesztelés két SuperMicro szerveren alapul, mindegyik négymagos processzorral Intel Xeon E3-1220 3,10 Hz órajellel, 24 GB Kingston DDR3 RAM-mal és négy Western Digital RE-3 160 GB-os meghajtóval (RAID 10). BIOS verziók azonos.
Tárhelyhez és virtuális gépekhez Fedora 20-at használtunk (SELinuxszal). Íme az általunk készített szoftververziók:
Néhányan felháborodhatnak – azt mondják, hogy a Fedora 20 tulajdonosa, a Red Hat jelentős erőfeszítéseket tesz a KVM támogatására. Hogy egyértelmű legyen, a Red Hat évek óta nem tett jelentős előrelépést a Xen terén.
A vizsgálatot Intel processzorokon végezték, így az eredmények eltérhetnek az AMD és az ARM között.
A virtuális gépek tesztelésének alapjául a közvetlenül hardverre, azaz operációs rendszer nélkül telepített virtuális gépek tesztjei szolgáltak (a továbbiakban: hardver). A teljesítmény-eltérés két virtualizáció nélküli szerver között 0,51% vagy kevesebb volt.
A PostMark tesztben a Xen 14,41%-kal lassabb volt, mint a hardver. Újraindításkor a teszteredmények 2%-kal tértek el az eredetitől. A legjobb teszt a KVM esetében a MAFFT volt a második legrosszabbul teljesítő Xen esetében.
Íme egy rövid összefoglaló a tesztelésről:
| Legjobb ár-érték | Tiszta fém | KVM | Xen | |
|---|---|---|---|---|
| Időzített MAFFT igazítás | Alsó | 7.78 | 7.795 | 8.42 |
| Smallpt | Alsó | 160 | 162 | 167.5 |
| POV-Ray | Alsó | 230.02 | 232.44 | 235.89 |
| Postabélyegző | magasabb | 3667 | 3824 | 3205 |
| OpenSSL | magasabb | 397.68 | 393.95 | 388.25 |
| Hasfelmetsző János (MD5) | magasabb | 49548 | 48899.5 | 46653.5 |
| Hasfelmetsző János (DES) | magasabb | 7374833.5 | 7271833.5 | 6911167 |
| Hasfelmetsző János (Blowfish) | magasabb | 3026 | 2991.5 | 2856 |
| CLOMP | magasabb | 3.3 | 3.285 | 3.125 |
| C-Ray | Alsó | 35.35 | 35.66 | 36.13 |
| 7-Zip | magasabb | 12467.5 | 12129.5 | 11879 |
Ha szeretné látni a teljes eredményeket, kövesse a linket.
Tesztelésünk során a KVM szinte mindig 2%-kal lassabb volt, mint a hardver. A Xen tízből három tesztben 2,5%-kal lassabb volt, a többiben pedig még rosszabb: 5-7%. Bár a KVM jól teljesített a PostMark tesztben, meg kell jegyezni, hogy csak egy I/O tesztet futottunk le, és érdemes lenne még néhányat futtatni a pontosabb kép érdekében.
Ahogy mister_fog helyesen megjegyezte, a Citrix 2007-ben nem a Xen forráskódot vásárolta meg, hanem a Xen fejlesztők által alapított XenSource céget, amely ennek kereskedelmi fejlesztésével foglalkozott. nyitott projekt. .
A hipervizorok (virtualizációs technológiák) több mint 30 éve léteznek, és ez idő alatt sikerült a felhő-ökoszisztéma egyik fő „fogaskerekévé” válniuk. Sok virtualizációs megoldásokat választó vállalat két népszerű hipervizort választ – a VMware-t és a KVM-et. Javasoljuk, hogy találja ki, melyik a jobb. De először egy kis elmélet.
A hypervisor egy olyan program, amely elválasztja az operációs rendszert a hardvertől. A hipervizorok virtualizálják a szerver erőforrásokat (processzor, memória, lemez, hálózati interfészek stb.), lehetővé téve azok sajátként való használatát, és több különálló virtuális gépet hoznak létre egy szerveren. Minden létrehozott virtuális gép el van szigetelve a szomszédaitól, hogy ne befolyásolja mások munkáját. A hypervisor működéséhez virtualizációs támogatás szükséges: Intel processzoroknál bekapcsolva Intel processzor VT, és for AMD processzorok az AMD-V-n.
A hipervizorok két típusra oszthatók: az elsők közvetlenül a szerverrel működnek, és a felhasználó operációs rendszere a hipervizor tetején fut. Ezek a hipervizorok kiszolgálókezelési funkciókat biztosíthatnak egyes felhasználók számára, és a legtöbb vállalat ezeket a hipervizorokat használja.
A második típusú hypervisor, más néven Hosted Hypervisor, a kiszolgálóra telepített operációs rendszerrel működik. Az új felhasználók operációs rendszerei pedig a hypervisor tetején jönnek létre.
Asztali hipervizorok, mint az Oracle VirtualBox vagy VMware munkaállomás, a második típusú hipervizorok, a VMware és a KVM pedig az első. A VMware és a KVM közvetlenül a szerverre települ, és nem igényel operációs rendszer telepítését.
A VMware vSphere megvásárlása előtt próbálkozzon vele próbaverzió(60 nap), amely után licencet kell vásárolnia, vagy el kell viselnie a korlátozásokat ingyenes verzió.
A VMware Free vSphere Hypervisor nevű ingyenes verzióban nincsenek processzor- és memóriakorlátozások a gazdagép számára, de számos más korlátozás is létezik:
A VMware terméke abban különbözik analógjaitól, hogy számos operációs rendszert támogat - Windows, Linux, Solaris, FreeBSD, Netware, MacOS és mások.
A VMware disztribúció telepítése a szerverre nagyon egyszerű: csak CD-ről, flash meghajtóról vagy PXE-n keresztül indítsa el. Ezenkívül a szkriptek támogatottak a szoftvertelepítési folyamat, a hálózati konfiguráció és a vCenter Serverhez való kapcsolódás automatizálása érdekében.
Fontos továbbá egy speciális konverter VMware vCenter Converter, amely lehetővé teszi az MS Virtual Server, a Virtual PC, a Hyper-V képek használatát az ESXi-ben, valamint a fizikai szerverek és a lemezpartíciós lemezképek használatát, amelyeket olyan programok hoztak létre, mint például az Acronis True Image, Norton Ghost és mások.
A VMware vSphere beépített integrációval rendelkezik a Microsoft Active Directory-val, vagyis a felhasználó hitelesítés privát vagy hibrid felhőben tartomány használatával is elvégezhető Microsoft szolgáltatások. A rugalmas erőforrás-elosztás lehetővé teszi a CPU, a RAM és a merevlemez gyors hozzáadását (beleértve az aktuális merevlemez átméretezését újraindítás nélkül).
A VMware Fault Tolerate egy VMware technológia, amelyet a virtuális gépek védelmére terveztek folyamatos rendelkezésre állási fürtök használatával. Ha a virtuális gép elsődleges munkapéldányával rendelkező gazdagép (ESXi-kiszolgáló) meghibásodik, a védett virtuális gép azonnal átvált egy másik ESXi-kiszolgálón futó „másodlagos” vagy „árnyék” másolatra. A VMware hibatűréssel védett gépeknél a teljes memóriaállapot és a processzor utasításai folyamatosan (valós időben) átmásolódnak a fő másolatról az „árnyék” másolatra. Ha az elsődleges ESXi gazdagép meghibásodik, a felhasználók észre sem veszik a feladatátvételi folyamatot a második csomóponthoz. Itt különbözik a hibatűrés a magas rendelkezésre állástól. Magas rendelkezésre állás esetén, ha egy fizikai szerver meghibásodik, a virtuális gépek újraindulnak más csomópontokon, és amíg az operációs rendszer újraindul, a felhasználók nem férhetnek hozzá a virtuális szerverekhez.
A VMware Foult Tolerate mellett a VMware vCloud Suite Enterprise licenc magas rendelkezésre állást, hibatűrést és katasztrófa-helyreállítást biztosít a vSphere HA, vMotion, Storage vMotion és vCenter Site Recovery Manager szolgáltatásaival.
A kiszolgálók vagy tárolórendszerek karbantartása során tervezett leállások csökkentése érdekében a vMotion és a Storage vMotion funkciók online migrálják a virtuális gépeket és lemezeiket az alkalmazások és a felhasználók leállítása nélkül. vSphere Replication támogatja különböző változatok vCenter Site Recovery Manager (SRM) replikáció a nagyobb katasztrófák elleni védelem érdekében. Az SRM központosított katasztrófa-helyreállítási tervezést, automatikus feladatátvételt és visszaállítást biztosít egy biztonsági mentési helyről vagy vCloudról, valamint zavarmentes vész-helyreállítási tesztelést.
Ennek a hypervisornak a jellemzői közé tartozik a hardverszelektivitás – a telepítés előtt gondosan ellenőrizni kell a meglévő berendezés kompatibilitását a szükséges verziót ESXi. A VMware webhelyén van erre egy speciális.
A VMware termékek licencének megvannak a maga sajátosságai. További zavart okoz a VMware licencszabályzatának időszakos módosítása (a vSphere verzióról verzióra). A VMware vSpere licencek vásárlása előtt számos szempontot figyelembe kell venni:
Több gazdagép kezelése ESXi hipervizorokkal, tárolórendszerekkel és hálózati berendezések használhat egy másik VMware terméket - a Vcenter Servert. A VMware partnerek által biztosított vSphere Client beépülő modulok lehetővé teszik az informatikai rendszergazdák számára, hogy közvetlenül erről a konzolról kezeljék az adatközpontban lévő harmadik féltől származó elemeket. Ezért a vCenter felhasználók végre tudnak hajtani biztonsági mentés, adatok védelme, szerverek, hálózatok és biztonság kezelése közvetlenül a vCenter felületről. Ugyanabban a konzolban beállíthat triggereket, amelyek értesítik Önt a felmerült problémákról, és adatokat kaphat a teljes infrastruktúra működéséről grafikonok vagy táblázatok formájában.
A KVM egy könnyen használható, könnyű, alacsony erőforrás-igényű és meglehetősen funkcionális hipervizor. Lehetővé teszi a virtualizációs platform lehető legrövidebb időn belüli üzembe helyezését és a Linux operációs rendszert futtató virtualizáció megszervezését. Működés közben a KMV egy speciális modulon (KVM-Intel vagy KVM-AMD) keresztül éri el az operációs rendszer kernelt. Kezdetben a KVM csak x86-os processzorokat támogatott, de a KVM modern verziói a processzorok és a vendég operációs rendszerek széles skáláját támogatják, beleértve a Linuxot, a BSD-t, a Solarist, a Windowst stb. Mellesleg az összes Wiki-forrás (MediaWiki, Wikimedia Foundation, Wikipedia, Wikivoyage, Wikidata, Wikiversity) használja ezt a speciális hipervizort.
Mivel a vendég operációs rendszerek kölcsönhatásba lépnek a hypervisorral, amely integrálva van Linux kernel, A vendég operációs rendszerek képesek közvetlenül hozzáférni a hardverhez anélkül, hogy módosítani kellene a vendég operációs rendszert. Emiatt szinte nincs lassulás a vendég operációs rendszer teljesítményében.
A KVM lehetővé teszi a virtuális gépek számára a QEMU, a VMware és más operációs rendszereket tartalmazó lemezképek nem módosított lemezképeinek használatát. Minden virtuális gépnek megvan a maga virtuális hardvere: hálózati kártyák, lemez, videokártya és egyéb hardver.
A módosítatlan VMware-képek támogatásával, fizikai szerver könnyedén virtualizálhatja ugyanazt a VMware vServer Converter segédprogramot, majd az eredményül kapott fájlt átviheti a hypervisorba.
KVM telepítése a műtőbe Linux rendszer A KVM csomag és a Libvirt virtualizációs könyvtár telepítéséből, valamint a virtualizációs környezet gondos beállításából áll. A gazdagépen használt operációs rendszertől függően be kell állítani egy hidat vagy egy kapcsolatot egy VNC-konzollal, amelyen keresztül a virtuális gépek interakcióba lépnek a gazdagéppel.
A KVM-et nehezebb adminisztrálni, mivel nincs átlátható hozzáférés a fájlokhoz, folyamatokhoz, konzolokhoz és hálózati interfészekhez, ezt Önnek kell konfigurálnia. A virtuális gép paramétereinek újraépítése a KVM-ben (CPU, RAM, HDD) nem túl kényelmes, és további műveleteket igényel, beleértve az operációs rendszer újraindítását.
Maga a projekt nem kínál kényelmes grafikus eszközök virtuális gépek kezeléséhez csak a Virsh segédprogramot, amely az összes szükséges funkciót megvalósítja. Mert kényelmes vezérlés A virtuális gépek emellett telepíthetik a Virt-Manager csomagot.
A KVM nem rendelkezik olyan beépített eszközökkel, mint a Fault Tolerate for VMware, így a magas rendelkezésre állású fürt létrehozásának egyetlen módja a hálózati replikáció DRDB használatával. Egy DRBD-fürt csak két csomópontot támogat, és a csomópontok titkosítás nélkül szinkronizálódnak. Vagyis a biztonságosabb kommunikációhoz VPN-kapcsolatot kell használnia.
Ezenkívül a magas rendelkezésre állású fürt felépítéséhez szüksége lesz a Heartbeat programra, amely lehetővé teszi a fürt csomópontjainak, hogy szolgáltatási üzeneteket cseréljenek állapotukról, valamint a Pacemakerre, a fürt erőforrás-kezelőjére.
A KVM hypervisor nyílt forráskódú termékként kerül terjesztésre. forráskód, a vállalati felhasználók számára pedig létezik egy kereskedelmi megoldás, a Red Hat Virtualization (RHEL), amely KVM-en és az oVirt virtuális infrastruktúra-kezelő platformon alapul.
Ennek a hypervisornak az a kétségtelen előnye, hogy bármilyen szerveren futhat. A hypervisor erőforrásait tekintve meglehetősen szerény, így könnyen használható tesztelési feladatokhoz.
Felhívjuk figyelmét, hogy a KVM nem rendelkezik támogatási szolgáltatással. Ha valami nem sikerül, számíthat fórumokra és közösségi segítségre. Vagy váltson RHEL-re.
Mindkét hipervizor kiforrott, megbízható, nagy teljesítményű virtualizációs rendszer, és mindegyiknek megvannak a saját jellemzői, amelyeket figyelembe kell venni a választás során.
A KVM általában jobban méretezhető, mint a VMware, elsősorban azért, mert a vSphere bizonyos korlátozásokkal rendelkezik a kezelhető kiszolgálókra vonatkozóan. Ezenkívül a VMware számos tárolóhálózatot (SAN) adott hozzá több gyártó támogatásához. Ez a funkció azt jelenti, hogy a VMware több tárolási lehetőséggel rendelkezik, mint a KVM, de ez is megnehezíti a VMware tárolásának támogatását a bővítés során.
A KVM jellemzően a legnépszerűbb hipervizor a bevezetési költségek csökkentésére törekvő vállalatok számára, és kevésbé érdeklődnek a vállalati szintű szolgáltatások iránt.
A kutatások kimutatták, hogy a KVM teljes birtoklási költsége jellemzően 39 százalékkal alacsonyabb, mint a VMware-é, bár a tulajdonlás tényleges összköltsége olyan konkrét tényezőktől függ, mint például a működési paraméterek és a helyszíni munkaterhelés.
A gazdagép operációs rendszerrel való szoros integráció az egyik leggyakoribb ok, amiért a fejlesztők a KVM-et választják. Főleg azok, akik Linuxot használnak. A KVM engedélyezése sok esetben Linux disztribúciók a fejlesztők számára is kényelmes választássá teszi.
Az IaaS szolgáltatásokat ügyfeleiknek kínáló felhőszolgáltatók általában a VMware termékekre épülő infrastruktúrát választják. A VMware Sphere alapú megoldások minden lényeges vállalati funkciót tartalmaznak a magas és folyamatos rendelkezésre állás biztosításához, támogatást nyújtanak több vendég operációs rendszereket, és képesek lesznek összekapcsolni az ügyfél infrastruktúráját a felhőszolgáltatásokkal.
