102.6 Lecke 1
Tanúsítvány: |
LPIC-1 |
---|---|
Verzió: |
5.0 |
Témakör: |
102 A Linux telepítése és a csomagkezelés |
Fejezet: |
102.6 A Linux, mint virtualization guest (virtualizációs vendég) |
Lecke: |
1/1 |
Bevezetés
A Linux egyik nagy erőssége a sokoldalúsága. Ennek a sokoldalúságnak az egyik aspektusa az a képesség, hogy a Linuxot más operációs rendszerek vagy egyedi alkalmazások teljesen elszigetelt és biztonságos környezetben történő elhelyezésére használhatjuk. Ez a lecke a virtualizáció és a konténertechnológiák (container technologies) fogalmaira összpontosít, valamint néhány technikai részletre, amelyeket figyelembe kell venni, amikor virtuális gépet telepítünk egy felhőplatformon.
A virtualizáció áttekintése
A virtualizáció egy olyan technológia, amely lehetővé teszi, hogy egy hypervisor-nak nevezett szoftverplatformon olyan folyamatokat futtassunk, amelyek egy teljesen emulált számítógépes rendszert tartalmaznak. A hypervisor felelős az egyes virtuális gépek által használható fizikai hardver erőforrásainak kezeléséért. Ezeket a virtuális gépeket a hypervisor vendégeinek (guests) nevezzük. Egy virtuális gép a fizikai számítógép számos aspektusát emulálja szoftveresen, például a rendszer BIOS-át és a merevlemez vezérlőit. A virtuális gépek gyakran használnak egyedi fájlként tárolt merevlemez image-ket, és a hypervisor szoftveren keresztül hozzáférnek a gazdagép (host machine) RAM-jához és CPU-jához. A hypervisor szétválasztja a vendégeknek a gazdarendszer hardveres erőforrásaihoz való hozzáférését, így lehetővé teszi, hogy egyetlen gazdarendszeren több operációs rendszer is fusson.
A Linuxhoz általában használt hypervisorok a következők:
- Xen
-
A Xen egy nyílt forráskódú, Type-1 hypervisor, ami azt jelenti, hogy működéséhez nem támaszkodik egy alapul szolgáló operációs rendszerre. Az ilyen típusú hypervisort bare-metal hypervisornak nevezik, mivel a számítógép közvetlenül a hypervisorba tud bootolni.
- KVM
-
A Kernel Virtual Machine egy Linux kernelmodul a virtualizációhoz. A KVM mind a Type-1, mind a Type-2 hypervisorok közé tartozik, mert bár működéséhez egy általános Linux operációs rendszerre van szüksége, egy futó Linux telepítésbe integrálódva tökéletesen képes hypervisorként működni. A KVM-mel telepített virtuális gépek létrehozásához és kezeléséhez a
libvirt
daemont és a kapcsolódó szoftveres segédprogramokat használják. - VirtualBox
-
Egy népszerű asztali alkalmazás, amely megkönnyíti a virtuális gépek létrehozását és kezelését. Az Oracle VM VirtualBox átível a platformokon, mert Linuxon, macOS-en és Microsoft Windowson is működik. Mivel a VirtualBox futtatásához egy mögöttes operációs rendszerre van szükség, ezért ez egy Type-2 hypervisor.
Egyes hypervisorok lehetővé teszik a virtuális gépek dinamikus áthelyezését. A virtuális gép egyik hypervisor telepítésből a másikba történő áthelyezésének folyamatát migrációnak nevezzük, és az ezzel kapcsolatos technikák a hypervisor-megvalósításokban különböznek. Egyes áttelepítések csak akkor végezhetők el, amikor a vendégrendszer teljesen leállt, míg más áttelepítések a vendég futása közben is elvégezhetők (ezt nevezzük live migrációnak). Ezek a technikák hasznosak lehetnek a hypervisorok karbantartási időszakai alatt, vagy a rendszer rugalmassága érdekében, amikor egy hypervisor működésképtelenné válik, és a vendéget át lehet helyezni egy működő hypervisorra.
A virtuális gépek típusai
A virtuális gépeknek három fő típusa van: a teljesen virtualizált (fully virtualized) vendég, a paravirtualizált (paravirtualized) vendég és a hibrid (hybrid) vendég.
- Teljesen virtualizált
-
Minden olyan utasításnak, amelyet a vendég operációs rendszer várhatóan végrehajt, képesnek kell lennie a teljes mértékben virtualizált operációs rendszer telepítésén belül is futni. Ennek oka az, hogy a vendégen belül nem települnek további szoftverillesztőprogramok, amelyek az utasításokat lefordítanák akár a szimulált, akár a valós hardverre. A teljesen virtualizált vendég olyan vendég, ahol a vendég (vagy HardwareVM) nem tudja, hogy az egy futó virtuális gép példánya. Ahhoz, hogy ez a fajta virtualizáció x86-alapú hardveren megvalósulhasson, az Intel VT-x vagy AMD-V CPU-bővítményeket engedélyezni kell a hypervisort telepítő rendszeren. Ezt a BIOS vagy az UEFI firmware konfigurációs menüjéből lehet megtenni.
- Paravirtualizált
-
A paravirtualizált vendég (vagy PVM) olyan vendég, ahol a vendég operációs rendszer tisztában van azzal, hogy ő egy futó virtuális gép példánya. Az ilyen típusú vendégek egy módosított kernelt és speciális illesztőprogramokat (úgynevezett vendégillesztőprogramokat (guest drivers)) használnak, amelyek segítenek a vendég operációs rendszernek a hypervisor szoftver- és hardvererőforrásainak használatában. A paravirtualizált vendég teljesítménye gyakran jobb, mint a teljesen virtualizált vendégé, az ilyen szoftverillesztők által biztosított előnynek köszönhetően.
- Hibrid
-
A paravirtualizálás és a teljes virtualizáció kombinálható, így a nem módosított operációs rendszerek közel natív I/O teljesítményt kaphatnak, ha paravirtualizált illesztőprogramokat használnak a teljesen virtualizált operációs rendszereken. A paravirtualizált illesztőprogramok tároló- és hálózati eszközillesztőket tartalmaznak, amelyek fokozott lemez- és hálózati I/O-teljesítményt nyújtanak.
A virtualizációs platformok gyakran kínálnak csomagolt vendégillesztőket (packaged guest drivers) a virtualizált operációs rendszerekhez. A KVM a Virtio projektből származó illesztőprogramokat használja, míg az Oracle VM VirtualBox a letölthető ISO CD-ROM image fájlból elérhető Guest Extensions-t használja.
Példa a libvirt
virtuális gépre
Egy olyan virtuális gépet fogunk megvizsgálni, amelyet a libvirt
kezel, és a KVM hypervisort használja. Egy virtuális gép gyakran egy fájlcsoportból áll, elsősorban egy XML-fájlból, amely meghatározza a virtuális gépet (például a hardverkonfigurációt, a hálózati csatlakoztathatóságot, a megjelenítési képességeket és egyebeket), valamint egy kapcsolódó merevlemez image fájlból, amely az operációs rendszer és a szoftver telepítését tartalmazza.
Először is kezdjük el megvizsgálni egy virtuális gép és a hozzá tartozó hálózati környezet XML konfigurációs fájljának példáját:
$ ls /etc/libvirt/qemu total 24 drwxr-xr-x 3 root root 4096 Oct 29 17:48 networks -rw------- 1 root root 5667 Jun 29 17:17 rhel8.0.xml
Note
|
A mappa elérési útvonalának |
Vegyük észre, hogy van egy networks
nevű mappa. Ez a mappa olyan (szintén XML-t használó) definíciós fájlokat tartalmaz, amelyek olyan hálózati konfigurációkat hoznak létre, amelyeket a virtuális gépek használhatnak. Ez a hypervisor csak egy hálózatot használ, ezért csak egy definíciós fájlja van, amely egy virtuális hálózati szegmens konfigurációját tartalmazza, amelyet ezek a rendszerek használni fognak.
$ ls -l /etc/libvirt/qemu/networks/ total 8 drwxr-xr-x 2 root root 4096 Jun 29 17:15 autostart -rw------- 1 root root 576 Jun 28 16:39 default.xml $ sudo cat /etc/libvirt/qemu/networks/default.xml <!-- WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: virsh net-edit default or other application using the libvirt API. --> <network> <name>default</name> <uuid>55ab064f-62f8-49d3-8d25-8ef36a524344</uuid> <forward mode='nat'/> <bridge name='virbr0' stp='on' delay='0'/> <mac address='52:54:00:b8:e0:15'/> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254'/> </dhcp> </ip> </network>
Ez a definíció tartalmaz egy Class C magánhálózatot és egy emulált hardvereszközt, amely a hálózat routereként működik. A hypervisor számára egy DHCP-kiszolgáló implementációval használható IP-címek tartománya is rendelkezésre áll, amelyeket az ezt a hálózatot használó virtuális gépekhez lehet hozzárendelni. Ez a hálózati konfiguráció a hálózati címfordítást (Network Address Translation, NAT) is használja a csomagok más hálózatokra, például a hypervisor LAN-jára történő továbbítására.
Most egy Red Hat Enterprise Linux 8 virtuális gép definíciós fájljára fordítjuk figyelmünket. (A külön figyelmet érdemlő részek félkövér szöveggel vannak szedve):
$ sudo cat /etc/libvirt/qemu/rhel8.0.xml <!-- WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: virsh edit rhel8.0 or other application using the libvirt API. --> <domain type='kvm'> <name>rhel8.0</name> <uuid>fadd8c5d-c5e1-410e-b425-30da7598d0f6</uuid> <metadata> <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> <libosinfo:os id="http://redhat.com/rhel/8.0"/> </libosinfo:libosinfo> </metadata> <memory unit='KiB'>4194304</memory> <currentMemory unit='KiB'>4194304</currentMemory> <vcpu placement='static'>2</vcpu> <os> <type arch='x86_64' machine='pc-q35-3.1'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <vmport state='off'/> </features> <cpu mode='host-model' check='partial'> <model fallback='allow'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <pm> <suspend-to-mem enabled='no'/> <suspend-to-disk enabled='no'/> </pm> <devices> <emulator>/usr/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/rhel8'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </disk> <controller type='usb' index='0' model='qemu-xhci' ports='15'> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x10'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x11'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> </controller> <controller type='pci' index='3' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='3' port='0x12'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> </controller> <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='4' port='0x13'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> </controller> <controller type='pci' index='5' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='5' port='0x14'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> </controller> <controller type='pci' index='6' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='6' port='0x15'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/> </controller> <controller type='pci' index='7' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='7' port='0x16'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </controller> <interface type='network'> <mac address='52:54:00:50:a7:18'/> <source network='default'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <channel type='spicevmc'> <target type='virtio' name='com.redhat.spice.0'/> <address type='virtio-serial' controller='0' bus='0' port='2'/> </channel> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='spice' autoport='yes'> <listen type='address'/> <image compression='off'/> </graphics> <sound model='ich9'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> </sound> <video> <model type='virtio' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> <redirdev bus='usb' type='spicevmc'> <address type='usb' bus='0' port='2'/> </redirdev> <redirdev bus='usb' type='spicevmc'> <address type='usb' bus='0' port='3'/> </redirdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </memballoon> <rng model='virtio'> <backend model='random'>/dev/urandom</backend> <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </rng> </devices> </domain>
Ez a fájl számos olyan hardverbeállítást határoz meg, amelyet ez a vendég használ, például a hozzárendelt RAM mennyiségét, a hypervisor CPU-magjainak számát, amelyekhez a vendég hozzáférhet, a vendéghez tartozó merevlemez image fájlt (a disk
stanza alatt), a megjelenítési képességeit (a SPICE protokollon keresztül), a vendég hozzáférését az USB-eszközökhöz, valamint az emulált billentyűzet- és egérbevitelt.
Példa virtuális gép lemeztárhelyére
A virtuális gép merevlemezének image-e a /var/lib/libvirt/images/rhel8
címen található. Itt van maga a lemez image ezen a hypervisoron:
$ sudo ls -lh /var/lib/libvirt/images/rhel8 -rw------- 1 root root 5.5G Oct 25 15:57 /var/lib/libvirt/images/rhel8
A lemez image jelenlegi mérete mindössze 5,5 GB helyet foglal el a hypervisoron. A vendég operációs rendszere azonban 23,3 GB méretű lemezt lát, amint azt a következő parancs kimenete is mutatja a futó virtuális gépen belül:
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:0 0 23.3G 0 disk ├─vda1 252:1 0 1G 0 part /boot └─vda2 252:2 0 22.3G 0 part ├─rhel-root 253:0 0 20G 0 lvm / └─rhel-swap 253:1 0 2.3G 0 lvm [SWAP]
Ez a vendéghez használt lemezszolgáltatás típusának köszönhető. A virtuális gépek többféle lemez imaget használhatnak, de a két elsődleges típus a következő:
- COW
-
Az írás közbeni másolás (copy-on-write, más néven thin-provisioning vagy sparse images) egy olyan módszer, amelynek során egy lemezfájl előre meghatározott felső mérethatárral jön létre. A lemez image mérete csak akkor növekszik, amikor új adatok kerülnek a lemezre. Az előző példához hasonlóan a vendég operációs rendszer látja az előre meghatározott 23,3 GB-os lemezkorlátot, de csak 5,5 GB adatot írt a lemezfájlba. A példa virtuális gépéhez használt lemezkép formátum a
qcow2
, ami egy QEMU COW fájlformátum. - RAW
-
A raw vagy full lemeztípus egy olyan fájl, amelynek minden hely előre ki van osztva (pre-allocated). Például egy 10 GB-os nyers lemezképfájl 10 GB tényleges lemezterületet foglal el a hypervisoron. Ez a lemezstílus teljesítménybeli előnyökkel jár, mivel az összes szükséges lemezterület már rendelkezésre áll, így az alapul szolgáló hypervisor csak adatokat írhat a lemezre anélkül, hogy a teljesítményt megterhelné a lemez image ellenőrzése, hogy az még nem érte-e el a korlátot, és a fájl méretének növelése, ha új adatok íródnak rá.
Vannak más virtualizációs kezelőplatformok, például a Red Hat Enterprise Virtualization és az oVirt, amelyek képesek fizikai lemezeket használni a virtuális gépek operációs rendszerének háttértárolójaként. Ezek a rendszerek tárolóhálózati (Storage Area Network, SAN) vagy hálózatra csatolt tárolóeszközöket (Network Attached Storage, NAS) használhatnak az adatok írásához, és a hypervisor nyomon követi, hogy melyik tárolóhely melyik virtuális géphez tartozik. Ezek a tárolórendszerek olyan technológiákat használhatnak, mint a logikai kötetkezelés (Logical Volume Management, LVM), hogy szükség szerint növeljék vagy csökkentsék a virtuális gépek lemezes tárolóhelyeinek méretét, és hogy segítsék a tárhely pillanatfelvételeinek (snapshot) létrehozását és kezelését.
Virtális gépek templatejei
Mivel a virtuális gépek jellemzően csak fájlok, amelyek egy hypervisoron futnak, könnyen létrehozhatók templatek (sablonok), amelyek testreszabhatók az adott telepítési forgatókönyvekhez. Gyakran előfordul, hogy egy virtuális gépen egy alapvető operációs rendszer és néhány előre meghatározott hitelesítési konfigurációs beállítás van a későbbi rendszerindítások megkönnyítése érdekében. Ez csökkenti az új rendszer létrehozásához szükséges időt azáltal, hogy csökkenti a gyakran ismétlődő munkák mennyiségét, például az alapcsomagok telepítését és a helyi beállításokat.
Ez a virtuális gép-sablon később átmásolható egy új vendégrendszerbe. Ebben az esetben az új vendéget átneveznénk, új MAC-címet generálnánk a hálózati interfészéhez, és egyéb módosításokat végeznénk a tervezett felhasználástól függően.
A D-Bus Machine ID
Sok Linux-telepítés a telepítéskor generált gépazonosító számot, az úgynevezett D-Bus machine ID-t (gépazonosítót) használja. Ha azonban egy virtuális gépet klónozunk, hogy más virtuális gépek telepítéséhez sablonként használjuk, akkor új D-Bus machine ID-t kell létrehozni annak biztosítására, hogy a hypervisor rendszererőforrásai a megfelelő vendégrendszerhez kerüljenek.
A következő paranccsal ellenőrizhetjük, hogy létezik-e D-Bus machine ID a futó rendszerhez:
$ dbus-uuidgen --ensure
Ha nem jelenik meg hibaüzenet, akkor a rendszer rendelkezik azonosítóval. Az aktuális D-Bus machine ID megtekintéséhez futtassuk a következőt:
$ dbus-uuidgen --get 17f2e0698e844e31b12ccd3f9aa4d94a
A megjelenő szöveges karakterlánc az aktuális azonosítószám. Egy hypervisoron futó két Linux rendszer nem rendelkezhet ugyanazzal a D-Bus machine ID-vel.
A D-Bus machine ID a /var/lib/dbus/machine-id
mappában található, és szimbolikusan linkelve van az /etc/machine-id
mappához. Ennek az azonosítószámnak a megváltoztatása egy futó rendszeren nem javasolt, mivel a rendszer instabilitása és összeomlása valószínűsíthető. Ha két virtuális gépnek ugyanaz a D-Bus machine ID-je van, az alábbi eljárást követve hozhatunk létre egy újat:
$ sudo rm -f /etc/machine-id $ sudo dbus-uuidgen --ensure=/etc/machine-id
Abban az esetben, ha a /var/lib/dbus/machine-id
nem egy szimbolikus link a /etc/machine-id
-re, akkor a /var/lib/dbus/machine-id
-t el kell távolítani.
Virtuális gépek telepítése a felhőbe
Számos IaaS (Infrastructure as a Service, szolgáltatott infrastruktúra) szolgáltató áll rendelkezésre, amelyek hypervisor rendszereket futtatnak, és virtuális vendég-image-ket tudnak telepíteni egy szervezet számára. Gyakorlatilag ezek a szolgáltatók mindegyike rendelkezik olyan eszközökkel, amelyek lehetővé teszik a rendszergazdák számára, hogy különböző Linux-disztribúciókon alapuló egyéni virtuális gépeket készítsenek, telepítsenek és konfiguráljanak. E vállalatok közül sokan rendelkeznek olyan rendszerekkel is, amelyek lehetővé teszik az ügyfél szervezetén belül létrehozott virtuális gépek telepítését és migrációját.
Egy Linux-rendszer IaaS-környezetben történő telepítésének értékelésekor a rendszergazdának tisztában kell lennie néhány kulcsfontosságú elemmel:
- Computing Instances
-
“Computing instances” (számítási példányok) alapján számolja fel a használati díjakat, vagyis hogy mennyi CPU-időt használ a felhőalapú infrastruktúra. Annak gondos megtervezése, hogy az alkalmazásoknak mennyi feldolgozási időre lesz ténylegesen szükségük, segít abban, hogy a felhőmegoldás költségei kezelhetőek maradjanak.
A számítási példányok gyakran a felhőkörnyezetben rendelkezésre bocsátott virtuális gépek számára is utalnak. Az egyszerre futó rendszerek minél több példánya szintén befolyásolja, hogy mennyi CPU-időért kell fizetnie a szervezetnek.
- Block Storage
-
A felhőszolgáltatók különböző szintű blokk-tárolókkal is rendelkeznek, amelyeket egy szervezet használhat. Egyes ajánlatok egyszerűen a fájlok webalapú hálózati tárolására szolgálnak, más ajánlatok pedig a felhőből biztosított virtuális gépek számára a fájlok tárolására szolgáló külső tárolókra vonatkoznak.
Az ilyen ajánlatok költségei a felhasznált tárhely mennyiségétől és a szolgáltató adatközpontjaiban lévő tárhely sebességétől függően változnak. A gyorsabb tárhely-hozzáférés általában többe kerül, és ezzel szemben a "nyugvó" adatok (mint az archív tárolás) gyakran nagyon olcsók.
- Networking
-
A felhőmegoldások szolgáltatójával való együttműködés egyik fő eleme a virtuális hálózat konfigurálása. Sok IaaS-szolgáltató rendelkezik valamilyen webalapú segédprogrammal, amelyet a különböző hálózati útvonalak, alhálózatok és tűzfal-konfigurációk megtervezéséhez és végrehajtásához lehet használni. Egyesek még DNS-megoldásokat is biztosítanak, hogy az internetre néző rendszerekhez nyilvánosan elérhető FQDN (teljesen minősített tartománynevek (fully qualified domain names)) rendelhetők legyenek. Olyan “hibrid” megoldások is rendelkezésre állnak, amelyek VPN (virtuális magánhálózat (Virtual Private Network)) segítségével összekapcsolják a meglévő, helyben lévő hálózati infrastruktúrát a felhőalapú infrastruktúrával, így összekapcsolva a kettőt.
Vendégek biztonságos elérése a felhőben
A legelterjedtebb módszer egy távoli virtuális vendég elérésére egy felhőplatformon az OpenSSH szoftver használata. A felhőben található Linux rendszerben az OpenSSH kiszolgáló futna, míg a rendszergazda egy előre megosztott kulcsokkal rendelkező OpenSSH klienst használna a távoli eléréshez.
Egy adminisztrátor a következő parancsot futtatná
$ ssh-keygen
és követi a promptokat egy nyilvános és egy privát SSH-kulcspár létrehozásához. A privát kulcs a rendszergazda helyi rendszerén marad (a ~/.ssh/
fájlban tárolva), a nyilvános kulcs pedig átmásolódik a távoli felhőrendszerbe, pontosan ugyanezt a módszert használjuk, amikor egy vállalati LAN-on lévő hálózati gépekkel dolgozunk.
Az adminisztrátor a következő parancsot futtatná:
$ ssh-copy-id -i <public_key> user@cloud_server
Ez a most generált kulcspár nyilvános SSH-kulcsát másolja át a távoli felhőkiszolgálóra. A nyilvános kulcsot a felhőkiszolgáló ~/.ssh/authorized_keys
fájljába rögzíti, és beállítja a megfelelő jogosultságokat a fájlhoz.
Note
|
Ha csak egy nyilvános kulcsfájl van a |
Egyes felhőszolgáltatók automatikusan generálnak egy kulcspárt, amikor egy új Linux-rendszert biztosítanak. A rendszergazdának ezután le kell töltenie a felhőszolgáltatótól az új rendszerhez tartozó privát kulcsot, és azt a helyi rendszerén kell tárolnia. Ne feledjük, hogy az SSH kulcsok engedélyei a magánkulcsok esetében a 0600
, a nyilvános kulcsok esetében pedig a 0644
kell, hogy legyenek.
Felhőrendszerek előzetes konfigurálása
Egy hasznos eszköz, amely leegyszerűsíti a felhőalapú virtuális gépek telepítését, a cloud-init
segédprogram. Ez a parancs, a hozzá tartozó konfigurációs fájlokkal és az előre definiált virtuális gépek image-ivel együtt egy gyártófüggetlen módszer egy Linux guest telepítésére az IaaS szolgáltatók sokaságában. A YAML (YAML Ain’t Markup Language) egyszerű szöveges fájlok segítségével a rendszergazda előre konfigurálhatja a hálózati beállításokat, a szoftvercsomagok kiválasztását, az SSH-kulcsok konfigurálását, a felhasználói fiókok létrehozását, a helyi beállításokat, valamint számtalan más opciót az új rendszerek gyors kiépítéséhez.
Egy új rendszer első indítása során a cloud-init
beolvassa a beállításokat a YAML konfigurációs fájlokból és alkalmazza azokat. Ezt a folyamatot csak a rendszer kezdeti beállításakor kell alkalmazni, és megkönnyíti az új rendszerek sokaságának telepítését egy felhőszolgáltató platformjára.
A cloud-init
segítségével használt YAML fájl szintaxisát cloud-config-nak hívják. Íme egy cloud-config
példafájl:
#cloud-config timezone: Africa/Dar_es_Salaam hostname: test-system # Update the system when it first boots up apt_update: true apt_upgrade: true # Install the Nginx web server packages: - nginx
Figyeljük meg, hogy a felső sorban nincs szóköz a hash szimbólum (#
) és a cloud-config
kifejezés között!
Note
|
A |
Konténerek
A konténertechnológia bizonyos szempontból hasonlít a virtuális gépekhez, ahol egy izolált környezetet kapunk egy alkalmazás egyszerű telepítéséhez. Míg a virtuális gép esetében egy teljes számítógépet emulálnak, a konténer csak annyi szoftvert használ, amennyi az alkalmazás futtatásához szükséges. Ily módon sokkal kevesebb az overhead.
A konténerek nagyobb rugalmasságot tesznek lehetővé, mint a virtuális gépek. Egy alkalmazáskonténer ugyanúgy átvihető egyik állomásról a másikra, mint ahogy egy virtuális gép is átvihető egyik hypervisorról a másikra. Néha azonban egy virtuális gépet ki kell kapcsolni, mielőtt migrálni lehetne, míg egy konténer esetében az alkalmazás mindig fut, amíg migrálódik. A konténerek megkönnyítik az alkalmazások új verzióinak a meglévő verzióval párhuzamos telepítését is. Ahogy a felhasználók lezárják a munkameneteiket a futó konténerekkel, a konténereket a konténer-összehangoló szoftver automatikusan eltávolíthatja a rendszerből, és az új verzióval helyettesítheti őket, így csökkentve az állásidőt.
Note
|
Számos konténertechnológia áll rendelkezésre Linuxhoz, például a Docker, Kubernetes, LXD/LXC, systemd-nspawn, OpenShift és még sok más. Egy konténer-szoftvercsomag pontos implementálása meghaladja az LPIC-1 vizsga kereteit. |
A konténerek a Linux kernel kontrollcsoportok (control groups, ismertebb nevén cgroups) mechanizmusát használják. A cgroup az egyik lehetőség arra, hogy a rendszer erőforrásait, például a memóriát, a processzoridőt, valamint a lemez- és hálózati sávszélességet egy-egy alkalmazás számára felosszuk. A rendszergazda közvetlenül használhatja a cgroupokat arra, hogy a rendszer erőforrás-korlátjait beállítsa egy alkalmazás vagy alkalmazáscsoportok számára, amelyek egyetlen cgroupon belül létezhetnek. Lényegében ezt teszi a renszergazda számára a konténerszoftver, valamint olyan eszközöket biztosít, amelyek megkönnyítik a cgroups kezelését és telepítését.
Note
|
Jelenleg a cgroups ismerete nem szükséges az LPIC-1 vizsga teljesítéséhez. A cgroup fogalmát azért említjük itt, hogy a jelölt legalább némi háttérismerettel rendelkezzen arról, hogyan különül el egy alkalmazás a rendszer erőforrásainak kihasználása érdekében. |
Gyakorló feladatok
-
Milyen CPU-bővítésekre van szükség egy x86 alapú hardverplatformon, amely teljesen virtualizált vendégeket futtat?
-
Egy kritikus fontosságú kiszolgáló telepítése, amely a leggyorsabb teljesítményt igényli, valószínűleg milyen típusú virtualizációt használ?
-
Két, ugyanabból a sablonból klónozott és D-Bus-t használó virtuális gép teljesítménye hibásan működik. Mindkettőnek különálló hosztneve és hálózati konfigurációs beállításai vannak. Milyen paranccsal lehetne meghatározni, hogy az egyes virtuális gépek különböző D-Bus machine ID-kkal rendelkeznek-e?
Gondolkodtató feladatok
-
Futtassuk a következő parancsot, hogy ellenőrizzük, hogy a rendszeren már engedélyezve vannak-e a CPU-bővítések egy virtuális gép futtatásához (az eredmények a CPU-tól függően változhatnak):
grep --color -E "vmx|svm" /proc/cpuinfo
A kimenettől függően a
vmx
(Intel VT-x engedélyezett CPU-k esetén) vagy azsvm
(AMD SVM engedélyezett CPU-k esetén) van kiemelve. Ha nem kapunk eredményt, nézzük meg a BIOS vagy az UEFI firmware utasításait a virtualizáció engedélyezéséről a processzor számára. -
Ha processzor támogatja a virtualizációt, keressük meg a disztribúció dokumentációját a KVM hypervisor futtatásához!
-
Telepítsük a KVM hypervisor futtatásához szükséges csomagokat!
-
Ha grafikus asztali környezetet használunk, ajánlott telepíteni a
virt-manager
alkalmazást is, ami egy grafikus front-end, amely egy KVM telepítésekor használható. Ez segíti a virtuális gépek telepítését és kezelését! -
Töltsük le az általunk választott Linux disztribúció ISO image-ét és a disztribúció dokumentációját követve hozzunk létre egy új virtuális gépet az ISO segítségével!
-
Összefoglalás
Ebben a leckében a virtuális gépek és a konténerek koncepcionális alapjait ismertettük, valamint azt, hogy ezek a technológiák hogyan használhatók Linux alatt.
Röviden ismertettük az alábbi parancsokat:
dbus-uuidgen
-
A rendszer DBus ID-jának ellenőrzésére és megtekintésére szolgál.
ssh-keygen
-
Nyilvános és privát SSH kulcspár generálására szolgál távoli, felhőalapú rendszerek eléréséhez.
ssh-copy-id
-
Egy rendszer nyilvános SSH-kulcsának távoli rendszerre való másolásához használatos, a távoli hitelesítés megkönnyítése érdekében.
cloud-init
-
Virtuális gépek és konténerek felhőkörnyezetbe történő konfigurálásának és telepítésének segítésére szolgál.
Válaszok a gyakorló feladatokra
-
Milyen CPU-bővítésekre van szükség egy x86 alapú hardverplatformon, amely teljesen virtualizált vendégeket futtat?
Intel CPU-k esetén VT-x, AMD CPU-k esetén pedig AMD-V
-
Egy kritikus fontosságú kiszolgáló telepítése, amely a leggyorsabb teljesítményt igényli, valószínűleg milyen típusú virtualizációt használ?
A paravirtualizációt - például a Xen-t - vendég operációs rendszerként használó operációs rendszer jobban kihasználhatja a rendelkezésére álló hardveres erőforrásokat a hypervisorral való együttműködésre tervezett szoftverillesztőprogramok használatával.
-
Két, ugyanabból a sablonból klónozott és D-Bus-t használó virtuális gép teljesítménye hibásan működik. Mindkettőnek különálló hosztneve és hálózati konfigurációs beállításai vannak. Milyen paranccsal lehetne meghatározni, hogy az egyes virtuális gépek különböző D-Bus gépazonosítókkal rendelkeznek-e?
dbus-uuidgen --get
Válaszok a gondolkodtató feladatokra
-
Futtassuk a következő parancsot, hogy ellenőrizzük, hogy a rendszeren már engedélyezve vannak-e a CPU-bővítések egy virtuális gép futtatásához (az eredmények a CPU-tól függően változhatnak):
grep --color -E "vmx|svm" /proc/cpuinfo
. A kimenettől függően avmx
(Intel VT-x engedélyezett CPU-k esetén) vagy azsvm
(AMD SVM engedélyezett CPU-k esetén) van kiemelve. Ha nem kapunk eredményt, nézzük meg a BIOS vagy az UEFI firmware utasításait a virtualizáció engedélyezéséről a processzor számára.Az eredmények az általunk használt CPU-tól függően változnak. Itt egy példa egy Intel CPU-val rendelkező számítógép kimeneti eredményére, amelynek virtualizációs kiterjesztései engedélyezve vannak az UEFI firmware-ben:
$ grep --color -E "vmx|svm" /proc/cpuinfo flags : 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 lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
-
Ha processzor támogatja a virtualizációt, keressük meg a disztribúció dokumentációját a KVM hipervizor futtatásához!
-
Telepítsük a KVM hipervizor futtatásához szükséges csomagokat!
Ez a disztribúciótól függően változik, de itt található néhány kiindulási pont:
Arch Linux — https://wiki.archlinux.org/index.php/KVM
-
Ha grafikus asztali környezetet használunk, ajánlott telepíteni a
virt-manager
alkalmazást is, ami egy grafikus front-end, amely egy KVM telepítésekor használható. Ez segíti a virtuális gépek telepítését és kezelését!Ez is a disztribúciótól függ. Ubuntu esetén így fog kinézni:
$ sudo apt install virt-manager
-
Töltsük le az általunk választott Linux disztribúció ISO image-ét és a disztribúció dokumentációját követve hozzunk létre egy új virtuális gépet az ISO segítségével!
Ezt a feladatot a
virt-manager
csomag könnyedén megoldja. A virtuális gép azonban a parancssorból is létrehozható avirt-install
paranccsal. Próbáljuk ki mindkét módszert, hogy megértsük a virtuális gépek telepítésének módját.
-