Oracle VM Server for SPARC (Logical Domains)

Volt már szó a SUN Solaris 10 óta megjelent egyik virtualizációs megoldásról a Zónákról. Az ugye egy Shared Kernel alapú chroot megoldás volt. Nézzük a Sun, illetve ORACLE igazi bare metal alapú virtualizációs megoldását. A következő dokumentáció nagyban Gyene András vázlatait dolgozza fel.

Hardver

Az Oracle VM Server for SPARC megoldás nem érhető el akármelyik hardwaren. Speciális Oracle gépre van szükség. Az úgynevezett T sorozat gépei, amelyek felruházhatóak ezzel a képességgel.

Íme a jelenlegi kínálat ami számításba jöhet:

UltraSPARC T1-based:

    Sun / Fujitsu SPARC Enterprise T1000 and T2000 servers
    Sun Fire T1000 and T2000 servers
    Netra T2000 Server
    Netra CP3060 Blade
    Sun Blade T6300 Server Module

UltraSPARC T2-based:

    Sun / Fujitsu SPARC Enterprise T5120 and T5220 servers
    Sun Blade T6320 Server Module
    Netra CP3260 Blade
    Netra T5220 Rackmount Server

UltraSPARC T2 Plus systems:

    Sun / Fujitsu SPARC Enterprise T5140 and T5240 servers (2 sockets)
    Sun Blade T6340 Server Module (2 sockets)
    Sun / Fujitsu SPARC Enterprise T5440 (4 sockets)

SPARC T3 systems:

    Sun / Fujitsu SPARC T3-1 servers (1 socket)
    Sun SPARC T3-1B Server Module (1 socket)
    Sun / Fujitsu SPARC T3-2 servers (2 sockets)
    Sun / Fujitsu SPARC T3-4 servers (4 sockets)

SPARC T4 systems:

    SPARC T4-1 Server (1 socket)
    SPARC T4-1B Server Module (blade)
    SPARC T4-2 Server (2 sockets)
    SPARC T4-4 Server (4 sockets)

Struktúra

Ha már megvan a megfelelő hardver (az én esetemben T5120), akkor értsük meg mit is fogunk csinálni. Alapvetően a gépünkben van elrejtve egy Hypervisor réteg, amellyel képesek vagyunk teljesen elkülönített Logical Domain-eket (LDOM)-et létrehozni. Kvázi Virtuális gépeket (VM), melyekbe azt és úgy installálunk amit szeretnénk. Természetesen olyan megkötéssel, hogy a telepíteni kívánt OS-nek támogatnia kell a SPARC architektúrát. Ilyen lehet a Solaris 10, OpenBSD, Ubuntu Linux.

A Hypervisor réteg, ami a virtualizációt fogja eredményezni nem egy telepítendő Software, mint a VMWare termékei, hanem a gépben vas szinten, számunkra megfoghatatlan állapotban létezik. Természetesen valahogy vezérelnünk kell. A vezérléshez pedig nem HMC-t fogunk használni mint PowerVM esetében. A vezérléshez egy Solaris-ra lesz szükségünk. Méghozzá egy olyan Solaris-ra, ami az adott fizikai gépre van telepítve.

Négy féle szerepkörrel lehet egy Logical Domain-t felruházni.

    Control Domain: Ez a szerepkör fogja betölteni a vezérlést. Ez a domai tudja majd elindítani, leállítani a többi domain-t illetve a virtual console funkcióért is ez lesz a felelős.

    Service Domain: Ez a szerepkör fogja ellátni a különböző virtuális eszközök mint disk, hálózat áthidalási funkcióját az I/O domain és az LDOM-ok között.

    I/O Domain: Ez a szerepkör ami ténylegesen kezeli az I/O eszközöket, PCI kártyákat. Tehát a tényleges adatáram ezen a szerepkörrel felruházott domain-en fog átáramlani.

    Guest Domain: Ez lesz az egyszerű kliens OS, amit virtualizáltan akarunk futtatni, minden féle többlettudás nélkül. Többnyire virtuális eszközöket fog látni mint CPU, mint MEMORY, mint DISK.

A Controll illetve a Service role általában egy LDOM-on belül szokott megvalósításra kerülni. Olcsóbb és kisebb helyeken még az I/O domain role is ugyan arra az egy LDOM-ra kerül, ami így egy személyben lesz a lelke az egész rendszernek.

Az egyszerűség kedvéért én is egyetlen LDOM-ba fogok minden nem GUEST jellegű role-t tömöríteni.

Előfeltételek

Amint megvan a gépünk, és kicsomagoltuk, összekábeleztük, és bekapcsoltuk, akkor első dolgunk ILOM-ra vezessen. Itt adjuk ki a következő parancsot:

-> show HOST

A rendszer firmware 6.4.2 vagy annál magasabb legyen.

Alapértelmezetten van egy domain a gépünkön, sőt az ORACLE egy előre telepített Solarissal szállítja. Elegendő ezt felbootolnunk (vagy erre az alapértelmezett domainra telepíteni egy tetszés szerinti Solaris-t)

Bár a Solaris 10 update 6-tól alapból fent vannak a szükséges patch-ek illetve csomagok, de azért ellenőrizzük. A következő két patch illetve csomag szükségeltetik:

124921-xx
125043-xx
SUNWldm
SUNWjass

# pkginfo SUNWldm
# pkginfo SUNWjass
# showrev -p|egrep „124921|125043”

Konfiguráljuk be a Controll / Service / I/O Domain-t

Ahogy említettem, én mindhárom role-t egy azon LDOM-ra fogom érvényesíteni.

Nézzük, meg, hogy a következő két service elérhető-e a gépünkön és ha nem hozzuk online-ba.

# svcs -a|egrep „ldmd|agents”

(Ha nem lennének ONLINE akkor:
# svcadm enable svc:/ldoms/ldmd:default
# svcadm enable svc:/ldoms/agents:default
)

Amint a 2 service online, a következő paranccsal tudjuk lekérni LDOM-jaink listáját:

# /opt/SUNWldm/bin/ldm list

Mivel jelenleg nincs egy darab konfigurált LDOM-unk sem, ezért a pre-installed OS birtokol minden erőforrást (CPU,MEMORY), és ezért kapja alapértelmezettként a „primary” nevet.

Ahhoz, hogy „guest” domain-eket tudjunk készíteni, a primary (control) domaint át kell konfigurálni, hogy ne használja az összes ram-ot és cpu-t, plussz létre kell hoznunk virtuális service-ket.

# ldm add-vdiskserver primary-vds0 primary
# ldm add-vconscon port-range=5000-5100 primary-vcc0 primary
# ldm add-vswitch net-dev=e1000g0 primary-vsw0 primary

Azaz, kreáltunk Virtual Disk server (VDS) , Virtual Console concentrator (VCC) és Virtual Switch server (VSW) service-eket:

VDS: diskek managelése
VCC: a domain console-ok eléréséhez szükséges
VSW: hálózati kapcsolatot biztosít

Akkor most Listázzuk ki az új service-ket:

# ldm list-services primary

Ezek után limitálhatjuk a Controll Domain erőforrásait. Adjunk neki 4 vCPU-t és 4GB MEMORY-t.

# ldm set-mau 0 primary
# ldm set-vcpu 4 primary
# ldm set-memory 4g primary

Ezeket az új beállításokat egy új konfigurációként el kell menteni.

# ldm add-spconfig xyz
# ldm list-spconfig

Miután elmentettünk mindent, enabled-be kell tennünk a virtual network kezeléséhez szükséges SMF service-t.

# svcadm enable svc:/ldoms/vntsd:default

Ezt az SMF service-t nem lehet enabled-be tenni, amíg nincs megcsinálva a virtuális network service.

Adunk egy reboot-ot a gépnek, hogy betöltődjön az új control domain beállítás , melyet xyz-nek neveztem el.

# init 6

Amint feljött a gép látható, hogy 4 vCPU és 4GB RAM van elérhető, azaz betöltődött az új config:

# psrinfo
# prtconf | grep -i mem
# ldm list primary

Ezzel egy időben elérhetővé vállt az új Virtuális Switch is:

# dladm show-dev

Plumboljuk fel az vsw0 –t ,és unplumb-oljuk az e1000g0-t (ezen fel van húzva egy IP : 192.168.74.28). Mostmár a vsw0 nevű virtuális switch fogja tartalmazni az IP-t , és az összes többi jövőben készülő guest domain ezen a virtuális device-on keresztül fogja kapni az IP-jét és kapcsolatát is a külvilággal.

Tehát, e1000g0-n lévő IP-t átkonfiguráljuk a vsw0-ra, és permanens config-ot gyártunk:

# ifconfig vsw0 plumb
# e1000g0 down unplumb
# ifconfig vsw0 192.168.74.28 netmask + broadcast + up
# mv /etc/hostname.e1000g1 /etc/hostname.vsw0

Ezek után létrehozhatunk új GUEST Logical Domain-eket.

Új Guest Logical Domain létrehozása

A Control Domain-en én a meglévő ZPOOL-omból létrehozok egy Datasetet.

# zfs create xxxpool/misi
# zfs list xxxpool/misi

Ezek után hozzunk létre olyan Block Volume-ket, amiket oda tudunk adni majd az LDOM-nak, mint virtuális disk.

# zfs create -V 10g xxxpool/misi/os_disk

Ezek után elkezdhetjük az LDOM konfigurációját:

Hozzuk létre a LDOM konfigurációt:
# ldm add-domain misi

Adjunk hozzá vCPU-t:
# ldm set-vcpu 4 misi

Adjunk hozzá Memóriát:
# ldm set-memory 2g misi

Adjunk hozzá hálózatot a Virtual Switch-ről:
# ldm add-vnet vnet1 primary-vsw0 misi

Hozzunk létre az Control Domain által elnevezett tárolási eszközt. Meg kell hivatkoznunk a device PATH-ját, majd az LDOM féle elnevezését.
# ldm add-vdsdev /dev/zvol/dsk/xxxpool/misi/os_disk misi_os_disk@primary-vds0

Most a létrehozott virtuális diszket rendeljük az LDOMunkhoz, egy vdisk0 néven.
# ldm add-vdisk vdisk0 misi_os_disk@primary-vds0 misi

Adjunk egy Virtuális Console portot, amin keresztül elérhető lesz.
# ldm set-vconsole port=5010 service=primary-vcc0 misi

Beállítjuk, hogy automatikusan ne induljon el:
# ldm set-variable autoboot\\?=false misi

Írjuk ki ezeket a beállításokkal:
# ldm bind-domain misi

Majd indítsuk el:
# ldm start-domain misi

Ha mindent jól csináltunk, akkor az LDOM-unk futni is fog. Listázzuk ki az elérhető Logical Domain-eket:

# ldm list-domain

Íme, már látszik is, hogy active az új domain, azaz fut, plussz nagyon fontos, hogy ebben a kimenetben látszik az a port is, amit definiáltunk neki a console eléréséhez (5010).

Teszteljük a CONSOLE elérést

Valahogy most hozzá kell férnünk a futó LDOM-hoz. Ismerjük a console portját, így be is tudunk lépni a CONTROL domain-ről:

# telnet localhost 5010

Nyomjunk egy enter-t és máris OK promptot kell kapnunk. Ez egyenértékű lesz egy fizikai gép OK promptjával. Kérjük le az elérhető devaliasokat.

{0} ok devalias

Ahogy látszik normális hardware path alatt látszanak a virtuális eszközök is. Persze a gépünk gyakorlatilag használhatatlan, hisz nincs telepítve semmi. Lehetőségünk van a CONTROL domain-en elérhető ISO image-t létrehozni mint Virtual Disk és hozzárendelni az LDOM-hoz.

Gyártsuk le a virtuális eszközt:
# ldm add-vdiskserverdevice /xxxpool/andriska/sol-10-u9-ga-sparc-dvd.iso telepito@primary-vds0

Majd adjuk hozzá:
# ldm add-vdisk telepito telepito@primary-vds0 misi

Ekkor kaphatunk egy hibaüzenetet:
Please perform the operation while the domain is bound or inactive.

Sajnos le kell állítanunk az LDOM-ot ehhez:

# ldm unbind-domain misi
# ldm add-vdisk telepito telepito@primary-vds0 misi
# ldm start-domain misi

Ezek után a Virtual Console-ra belépve már látnunk kell az új TELEPITO disket:

Akkor most bootoljuk meg:

{0} ok boot telepito – install

Ezek után ez már csak a szokott módon telepíteni kell az LDOM-ot.

Ahogy a fenti képen látszik a telepítés a végére ért. Beléptem a misi nevű LDOM-ba.

Online Bővítések

Mivel az LDOM-unk, most egy virtuális gép, ezért hasonlóképpen, mint VMware esetben, erőforrásokat tudunk kellene online módosítani rajta. Először is kérjük le a jelenlegi beállításait az LDOMunknak a Control Domin-ből:

# ldm list-bindings misi

Felül zölddel kereteztem be azt a részt, ami egy összesítő képet kíván nyújtani az LDOM-ról. Most pedig nézzük a többi részt, illetve, hogy tudjuk módosítani.

CPU

Sárgával jelöltem a CPU beállításait az LDOM-nak a fenti képen. Ahogy látszik négy darab vCPU van a géphez rendelve. Láthatjuk azt is innen, mennyire vannak terhelve.

Akkor most próbáljunk meg hozzáadni, mondván, hogy az LDOM teljesítménye megköveteli:

# ldm add-vcpu 1 misi

Ahogy látszik automatikusan, minden reboot nélkül megjelent a Solaris-ban is az új CPU.

Persze jogos az igény, hogy amennyiben pedig sok van feleslegesen odaadva, akkor vegyük el tőle:

# ldm remove-vcpu 3 misi

Ez is természetesen minden fajta reboot nélkül ONLINE végrehajtódik a futó rendszeren:

Memory

Hasonlóképp adjunk többlet memóriát az LDOM-nak:

# ldm add-memory 2G misi

Vagy próbáljunk elvenni tőle:

# ldm remove-memory 1G misi

Amennyiben futó rendszernél próbáltuk meg, mindkét esetben a következő hibaüzenetet fogjuk kapni:

Please perform the operation while the domain is bound or inactive

Ahogy látszik is, memóriát növelni és csökkenteni is csupán lekapcsolt állapotú LDOM esetében tudunk.

Network

A fenti képen pirossal jelöltem a hálózatra vonatkozó részeket. Ahogy látszik is, egyetlen VNET1 eszköz van a gépünkhöz rendelve. Természetesen az LDOM olyan Virtual Switch-re van kötve, amin más gépek is lógnak már. Ezért látunk alatta még más PEER információkat is.

Adjunk most hozzá egy új virtuális hálózati interface-t az LDOMunkhoz.

# ldm add-vnet vnet2 primary-vsw0 misi

Ez is reboot nélkül mehet, és természetesen amennyiben másik Virtual Switch-hez rendeljük az Virtual Interface-t, akkor ez másik hálózatot is fog jelenteni.

Az network interface elvétele kicsit zűrösebb. Bemutatom miért. Az LDOM-ban adok egy IP címet az egyik interface-nek és megpróbálom eltávolítani a Control Domain-ből:

LDOM# ifconfig vnet1

CONTROL_DOMAIN# ldm remove-vnet vnet2 misi

Ez azt jelenti, hogy csak unplumb-olt interface-ket távolíthatunk el:

LDOM# ifconfig vnet1 unplumb
CONTROL_DOMAIN# ldm remove-vnet vnet2 misi

DISK

A fenti ábrán narancssárgával jelöltem a disk-ekre vonatkozó részt.
Próbáljunk készíteni egy új virtual disk-et és adjuk hozzá a gépünkhöz:

# zfs create -V 1g xxxpool/misi/data1_disk
# ldm add-vdsdev /dev/zvol/dsk/xxxpool/misi/data1_disk data1_disk@primary-vds0
# ldm add-vdisk vdisk2 data1_disk@primary-vds0 misi

Ez is természetesen ONLINE művelete. Nézzük ezek után a LDOM-ot:

Most hozzunk rá gyorsan egy ZPOOL-t, majd próbáljuk meg úgy eltávolítani:

LDOM# zpool create data_pool c0d2
LDOM# zpool status data_pool

Mos probáljuk meg elvenni az LDOM-ból:

# ldm remove-vdisk vdisk2 misi

Miútán eltávolítjuk a filesystemet, volume manager birtoklását erről a disk-ről azonnal altávolítható lesz:

CONTROL_DOMAIN#ldm remove-vdisk vdisk2 misi

I/O Slot

Igazából nem a virtualizációhoz tartozik, de tényleges fizikai PCI slotokat, és ezáltal azok kártyáit és ezek funkcióit is natívan LDOM-okhoz köthetjük. Sajnos az én teszt gépemben nincs elegendő ilyen eszköz, így ezt nem tudom saját példán bemutatni. Viszont vegyünk egy interneten talált példát:

Alapból minden I/O PCI slot a primary, Control Domain-hez van rendelve:

CONTROL_DOMAIN# /opt/SUNWldm/bin/ldm list-bindings primary

IO: pci@780 (bus_a)
pci@7c0 (bus_b)

Ellenőrizzük, hogy melyik PCI slotok azok, amik aktívan használva vannak a CONTROL DOMAIN által:

CONTROL_DOMAI# df /
/ (/dev/dsk/c1t0d0s0 ): 1309384 blocks 457028 files

CONTROL_DOMAI# ls -l /dev/dsk/c1t0d0s0
lrwxrwxrwx 1 root root 65 Feb 2 17:19 /dev/dsk/c1t0d0s0 -> ../../devices/pci@7c0/pci@0/pci@1/pci@0,2/LSILogic,sas@2/sd@0,0:a

Ahogy látszik a PCI@7C0 (bus_a) van használatban, így a másikat oda tudjuk adni egy LDOM-nak. Vegyük el a CONTROL_DOMAIN-tól:

CONTROL_DOMAIN# ldm remove-io pci@780 primary
Initiating delayed reconfigure operation on LDom primary. All configuration changes for other LDoms are disabled until the LDom reboots, at which time the new configuration for LDom ldg1 will also take effect.

Ezek után újra kell indítani a CONTROL_DOMAIN-t.

CONTROL_DOMAIN# shutdown -i6 -g0 -y

Amikor újraindult, már hozzá tudjuk a felszabadult PCI slotot rendelni egy LDOM-hoz:

CONTROL_DOMAI# /opt/SUNWldm/bin/ldm add-io pci@780 misi
Initiating delayed reconfigure operation on LDom misi. All configuration changes for other LDoms are disabled until the LDom reboots, at which time the new configuration for LDom ldg1 will also take effect.

Sajnos az LDOM esetében sem megy a PCI slot hozzáadása vagy elvétele újraindítás nélkül:

misi# shutdown -i6 -g0 -y

Összefoglalás

Számomra az LDOM egy könnyen kezelhető és dinamikus virtualizációs megoldás SPARC rendszerekre. Látszik, hogy a SUN/ORACLE az IBM LPAR rendszere ellen indított technológiája. Viszont memória és I/O slotok managelése esetén sajnos nem lehet ONLINE mód managelni az LDOM-ot. Ennek ellenére akinek hasonló célra kell több kisebb telljesítményű gépet, modernebb, költséghatékonyabb módon konszolidálnia, annak kivíálló megoldást nyújt az Oracle VM Server for SPARC (Logical Domains). Gyakorlatilag csak a megfelelő hardware-be kell beruháznunk, minden más ingyen jár hozzá. A végére még egyetlen megjegyzés. Az LPAR-ok esetén két külön gép esetén lehetett Live Migration-t használni, azaz menet közben egy működő LPAR-t áttenni egy másik fizika gépre. Ez SPARC és LDOM esetében jelenleg nem elérhető technológia. OS cluster-t ajánl az ORACLE a magas rendelkezésreállás biztosítására.

Oracle VM Server for SPARC (Logical Domains)” bejegyzéshez 2 hozzászólás

Vélemény, hozzászólás?

Az e-mail címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük