Vámdíjak virtualizálása
A felhasználók virtualizáció iránti érdeklődése a közelmúltban eltűnt. Egyfelől érthető asztali megoldások vannak minden tengely számára. Másrészt a VDS költségei nem olyan magasak, és a szerver mindenki számára elérhető, a fejlesztést bármely pontról bizonyítani tudja. De ha mindent többé-kevésbé világos a Linux, és a választás van, akkor a Windows hosting nem kínál mindent, a költségek magasak (körülbelül kétszer olyan drága), és figyelembe őket, amikor ilyen rendszerre van szükség ritkán nincs értelme. Itt ismerhetjük meg a KVM-et.
A KVM előnyei és hátrányai
A technológia teljes virtualizációt biztosít a hardver szintjén. Ezért, szemben a népszerű LXC és OpenVZ rendszerekkel, a KVM elvileg bármely operációs rendszert futtathat, nem csak Linuxot (Windows, FreeBSD ...) és Linuxot, amely eltér a fő rendszer konfigurációjától. Ha olyan virtuális gépre van szüksége, amely nem felel meg a fő gazda paramétereinek, akkor nincs külön választás. A magban való beilleszkedés nagy áttörés volt. A virtualizációs támogatás az operációs rendszerben nem feltétlenül szükséges egy hypervisor (például Xen) telepítéséhez, és bármilyen elosztásban, beleértve az asztali környezetet is, megvalósítható lenne. A dobozon kívül van a VNC, amely lehetővé teszi a virtuális kiszolgáló kezelését a letöltés pillanatától (vagyis amikor az SSH még nem működik), mintha a helyi konzolból származna. A projekt aktívan együttműködik egy másik hasonló QEMU megoldással. egyes segédprogramokat használnak, és a képfájl általános formátuma a Qcow2.
Természetesen vannak hátrányai is. Hol van nélkülük. A fő processzornak hardveres támogatást kell nyújtania az Intel VT-x vagy az AMD-V virtualizációjához. Kézzel vagy segédprogramokkal ellenőrizheti azok elérhetőségét:
Szintén a technológiai támogatásról azt mondják, hogy zászlók vannak a CPU-ban:
A processzorgyártótól függően a rendszermag modulja betöltődik (kvm-amd.ko vagy kvm-intel.ko).
A KVM támogatásának ellenőrzése
A fej fölött valamivel magasabb, mint az LXC és az OpenVZ használata esetén. Ennek két oka van.
A KVM konténer elindítja a rendszermag és környezetének másolatát, és ehhez memóriát igényel. Az LXC és az OpenVZ a kiszolgáló kernelét és rendszerhívásait is használja. Ezért ugyanolyan tulajdonságokkal rendelkeznek, mint a tárhely, teljesen más lehetőségek vannak. KVM konténer létrehozásakor minden erőforrás közvetlenül a beállítások szerint van fenntartva. Ezt egyértelműen a HOPOP látja. Érdemes hozzáadni a RAM-ot a KVM-hez, amint ez az érték megnöveli a felhasznált memória mennyiségét. A VM határainak kilépése nem lehetséges, keményen vannak telepítve. Ebben, még egy plusz, akkor azonnal kiszámíthatja a jövőbeli terhelést a szerveren, és senki sem fog kölcsönbe venni.
A VM-k viszonylag stabilak a teljesítmény szempontjából. Míg az OpenVZ virtualizációval, az erőforrásokat szükség szerint dinamikusan osztják fel, és minden virtuális kiszolgáló annyi erőforrást használ, amennyire szüksége van most. A nem tervezett erőforrások szabadon maradnak. Ezért népszerű a vendéglátók számára, mert mindig egy kicsit több VM-et tudsz megcsinálni, ezért a margóval létrehozott virtuális gépek gyorsabban vagy lassabban tudnak működni. Néha az OpenVZ-re vonatkozó VM optimalizálása valódi étkezés: nem világos, hogy a szerver miért kezdett másként működni - új beállítások vagy külső tényezők miatt.
Nehéz a KVM adminisztrációja, mivel nincs átlátható hozzáférés a fájlokhoz, folyamatokhoz, konzolokhoz és konténerek hálózathoz, saját maga kell konfigurálnia. A VM paraméterek ú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. Ugyanabban az OpenVZ-ben lehet repülni. Maga a projekt nem nyújt kényelmes grafikus eszközöket a virtuális gépek kezeléséhez, csak a virsh segédprogramot, amely végrehajtja az összes szükséges funkciót. De az interneten való keresés során több interfész található, bár egy vagy több VM egyéni használatához általában nincs értelme. Emellett sok nyílt forráskódú projekt is aktívan fejlődött a virtuális gépek nagy érdeklődésének köszönhetően, kereskedelmi forgalomba kerültek, bár egyesek még mindig kivágott szabad verziót kínálnak. A csomagtárban virt-manager található. Grafikus felületet kínál a KVM és a virlib támogatását támogató egyéb típusú VM-ek kezelésére, mind lokálisan telepítve, mind távolról SSH-n keresztül.
Web interfészként ajánlhat egy régi, de még mindig működő WebVirtMgr-t. szabad UVMM UCS Core Edition. openQRM Free Community Edition és mások. Ezenkívül vannak olyan speciális terjesztések is, mint a Proxmox VE. ahol a KVM és az LXC alapú VM-k létrehozására és kezelésére szolgáló összes eszköz már létezik (bár alkalmas a csupasz fémszerkezetekre és nem a távoli VDS-re).
A KVM telepítése
A KVM előnyei az, hogy működik a dobozból, és hogy a gazdaszervezetek processzorai egyedülállóan támogatják ezt a technológiát. Ezért a rendelkezésre álló erőforrások jelenlétében teljesen megvalósítható a VDS-ben egy másik virtuális gép (vagy több) betöltése. Természetesen a virtuális virtualizáció alatt nem fognak olyan gyorsan dolgozni, mint a hardveren, de ha egy nagy terhelést nem terveznek, elég legyen. Ezenkívül egyes hosting cégeknek megmentési eszközei vannak, amelyek lehetővé teszik egy másik fájlrendszer csatlakoztatását (a hetznerben a mentés / LARA), a meglévők cseréje és a saját operációs rendszer telepítése. Bizonyos készséggel a Windows teljesen jogszerűen használható a Linux tarifák szerint.
Ellenőrizzük a KVM támogatását.
Ha ilyen válasz érkezik, akkor minden rendben van. A támogatott operációs rendszerek listáját és a helyes nevüket a osinfo lekérdezéssel lehet elérni.
A libvirt konfigurációs fájlok az / etc / libvirt könyvtárban találhatók. A problémákra adott válaszokat a / var / log / libvirt könyvtárban találja meg. A / var / lib / libvirt könyvtárak több könyvtárat tartalmaznak: a rendszerindító rendszerben, ha nincs megadva elérési út, keresni fog egy képet a vendégrendszer telepítéséhez, és a merevlemezek helyére.
A virtuális gépek kezelése a konzolból a virsh segédprogrammal történik. Rengeteg paraméter létezik, mindegyiket a következőképpen írhatja be:
Kezdetben egyszerűen csak meg kell ismerkedned, hogy megértsd a lényeget. Az OS listája üres:
Ellenőrizzük, hogy a hálózat konfigurálva van-e. Alapértelmezés szerint az alapértelmezett értéket használja.
Ha azt válaszoljuk, hogy lehetetlen kapcsolódni, akkor ellenőrizzük a hozzáférési jogokat a foglalathoz és a fenti könyvtárakhoz (alapvetően ez a probléma).
És indítsa újra a modulokat:
Még egy dolog. A Win futtatásához olyan paravirtual virtio meghajtókra van szükség, amelyek végrehajtják a fő eszközök virtuális környezetben való működését. Nem feltétlenül szükségesek, de használatuk révén nagyobb termelékenységet és rugalmasságot érhet el a virtuális környezet munkájában. A vendégeket és a vendég operációs rendszert támogatni kell. A Linux kernelben az illesztőprogram 2.6.25-ből támogatott, de a modul alapértelmezés szerint nincs telepítve. Ha hívó / sbin / lsmod | grep virtio és macska "/ boot / config-uname -r" | grep -i virtio nem mutatott semmit, telepítse a qemu-guest-agent csomagot. A vendég OS esetében az ISO kép elérhető a fedoraproject.org-on.
Ezután két lehetőség van. Az operációs rendszert önállóan telepítheti, vagy készíthet egy már kész képet a telepített operációs rendszerrel. Az első lépés általában különbözik a lemez készítéséhez, a VM futtatásához és az operációs rendszer szabványos telepítéséhez. Hozzunk létre egy 25 GB-os lemezt.