XenClient – 2.0

Egy korábbi cikkben írtam arról az elvetemült igényemről, hogy egy biztonságos destop operációs rendszert szeretnék használni, ahol nem keverednek a céges adataim/alkalmazásaim a priváttal, és legfőképp nem a szórakozásra használtakkal…

A Citrix elsőként jelent meg a piacon egy  széles körben használható desktop virtualizációs megoldással, amely alapjául egy valódi Type1 típusú hypervisor szolgál: a Xen

A hivatalos marketing ömleny természetesen a Citrix oldalain olvasható, én ezt a részt ugranám, és rátérnék arra, hogy mit is kapunk valójában.

Verziók

Először is tisztázni kell, hogy pontosan melyik verzióról is van szó:

Ez a XenDesktop részeként használható, nagyvállalatoknak szánt megoldás.

Ez egy titokzatos, magas biztonsági szintet ígérő verzió – ám erről egyelőre kizárólag marketing anyag érhető el…

Ez lenne a nép számára is ingyenesen használható megoldás, ami vizsgálatunk további tárgyát is képezi :)

Telepítés

Hardver Követelmények

A hivatalosan támogatott hardverek listája megtalálható a termék weboldalán

Ezek között sajnos az én laptopom sem szerepel, de ettől függetlenül egy próbát megért, és kiderült hogy mik azok a bizonyos sarkalatos pontok:

  • VT-x

Ezen a fícsör megléte elengedhetetlen, nélküle egyáltalán nem telepíthető a rendszer (ahogy semmilyen más egyéb Type1 hypervisor sem)

  • VT-d

Ennek hiányát a telepítő jelzi, ám a gyakorlatban csak a VM-ek 3D támogatás hiányát okozza.

  • GPU

Ezzel kapcsolatban a telepítő nem nyilatkozik, a telepítés gyakorlatilag bármilyen GPU-val sikeres lesz, ám a rendszer támogatott GPU hiányában csak „Safe Grapics Mode”-ban hajlandó elindulni. Ez később a VM-ekre is kihatással van, ők is csak limitált felbontással (1024×768) és sebességgel (fbdev) fogynak működni…

  • HDD

Erről csak annyit, hogy a telepítés során a TELJES diszket birtokba veszi a rendszer, külön partícióra nem telepíthető. Erre amúgy a telepítés során fel is hívja a figyelmet.

Ha a fenti követelményeknek (többé-kevésbé) megfelel a hardverünk, akkor hipp-hopp fel is települ, és az első sikeres boot után a rendszer grafikus felülete fogad bennünket, ahol többek között virtuális gépeket hozhatunk létre – és végül is, ez volt a cél :)

A virtuális gépek létrehozására – egyelőre – két lehetőségünk van:

  • Local Disc

Azt hiszem ezt nem kell túlmagyarázni, lokális médiáról való telepítést jelent :) Tehát, ha van a közelünkben telepítő CD, (vagy image) akkor a guest oprendszer telepítése semmiben nem különbözik egy normális telepítéstől.

  • Synchronizer

Ezen megoldás segítségével, egy központi szerveren hozhatunk létre szabványos VM-eket, amiket aztán a kliensek letölthetnek és használhatnak, Olyan egyéb járulékos előnyökkel mint: ‘Dynamic VM Image Mode’  használata. Természetesen ennek előfeltétele, a Synchronizer szerver, és a róla elérhető VM-ek előkészítése…

Használat

Amint sikerült egy legalább egy VM-et létrehoznunk, máris használatba vehetjük. Fontos kiemelni, hogy – egyelőre – a VM-ek között, a (hálózaton kívül) semmiféle egyéb kapcsolat nincs, egyszerre mindig csak az egyik VM konzolját látjuk és használhatjuk. A közös beviteli és kimeneti eszközök (egér, billentyűzet, hangkártya, monitor!, stb) mindig az ‘aktív’ VM-hez vannak rendelve.

Fontos kiemelni, hogy a 3D támogatás – ami tulajdonképp csak marketing elnevezés – szükséges egyéb olyan fícsörök használatához is, aminek semmi köze a 3D-hez. Ilyen pl.: a külső monitor használata, ami egy laptop esetében mindennapos… Ezt azonban egyszerre csak egy VM birtokolhatja, a többieknek ilyenkor be kell érni a beépített kijelzővel.

Tehát, hiába van (akár több) külső monitorunk, több VM egyidejű megjelenítésére nincs lehetőségünk.

Közösködés

Ha már van némi fogalmunk egy hypervisor (esetünkben a Xen) működésével kapcsolatban, akkor tudjuk, hogy van egy bizonyos dom0 nevezetű izé, ami közvetlenül a hardverelemekkel tartja a kapcsolatot, így ő lesz a közös pontja a rendszernek. Aki hozzáfér ehhez, az ugyanis teljes joggal birtokolhatja és befolyásolhatja a gépünkön futó összes VM működését. Ez tehát, a rendszerünk gyenge pontja is egyben.

Amit láthatjuk, ezen megoldás esetében valóban minden eszközt a dom0 lát, kezel és birtokol:

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 03)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
08:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

Ebből az következik, hogy a hálózati interfészeket, és így a külső fizikai hálózattal való összeköttetést is a dom0-re bízták:

brbridged Link encap:Ethernet  HWaddr 00:16:D3:8D:DB:F9  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

brinterna Link encap:Ethernet  HWaddr 82:0C:37:96:E1:4E  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

brshared  Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          inet addr:172.16.25.1  Bcast:172.16.25.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

brwireles Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          inet addr:172.16.26.1  Bcast:172.16.26.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:16:D3:8D:DB:F9  
          UP BROADCAST PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:162 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:296 (296.0 B)  TX bytes:296 (296.0 B)

uivm      Link encap:Ethernet  HWaddr 8A:6C:C3:83:70:B6  
          inet addr:10.169.142.1  Bcast:10.169.142.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vif2.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vif2.1    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:1C:BF:34:C1:A0  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Ami így, egy valós támadási felületet ad a rendszerhez, és ezt a marketing ódák figyelmen kívül hagyják!

Ezek után magától érthetődő, hogy a virtuális és fizikai interfészek közötti hálózati forgalomról is a dom0-ban kell gondoskodni:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  brshared brbridged  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  brbridged brshared  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  brwireless wlan0   0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  wlan0  brwireless  0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  brshared *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  brwireless *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      brshared  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      brwireless  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Ha a fenti csomagszűrő szabályokat hálózati szakemberként nézzük, láthatjuk, hogy nincs túlbonyolítva a dolog ;)

Természetesen egy Type2 hypervisorhoz képest ez semmivel sem rosszabb megoldás, ám a biztonságos szeparáció elnevezés ezesetben megtévesztő lehet. Várhatóan, a titokzatos XT verzióban a maximális biztonság érdekében ezen eszközök további szeparációjáról beszélnek…

Ilyen jellegű szeparáció nyomait fedezhetjük fel, ha megnézzük milyen VM-ek is vannak a gépünkön:

 ID  | Name               | UUID                                 | State     
-----+--------------------+--------------------------------------+--------
   1 | uivm               | 00000000-0000-0000-0000-000000000001 | running   
   2 | windows7           | d5f0e6ae-22ba-4386-8fd0-a78f15c2c6ed | running

Trmészetesen, a windows7 nevű az, amit én magam hoztam létre, a másik pedig egy gyári – a nevéből ítélve – a VM váltó felület, és a globális beállításokért, és a  Synchronizer-rel való kapcsolattartásért felelős virtuális gép lehet.

Összegzés

Ha az egyéb (biztonsággal és működéssel kapcsolatos) részletek nem különösebben érdekelnek, akkor tulajdonképpen a rendszer kész és működőképes, hiszen használhatunk egyszerre több operációs rendszert, váltogathatunk közöttük, és akár központilag előkészített céges VM-eket is letölthetünk/használhatunk. Mindezt ingyen.

Ha azonban valós biztonságot is remélünk, akkor tisztában kell lennünk ezen megoldás részleteivel is, nem bedőlve a marketing szövegeknek.

A biztonságon kívül, van ezért még egy-két kérdéses pontja a Citrix megoldásának: kezdve a VM-ek mentési lehetőségeitől, egyészen a VM-ek közötti adatcsere lehetőségéig.

Mivel azonban a terméknek egyelőre nincs életképes konkurenciája, így más lehetőség hiján ez az egyedüli valódi deskop virtualizációt biztosító megoldás. Ha tetszik használjuk, ha nem akkor várunk bizakodva az újabb vezriók és/vagy a konkurrencia megjelenésére ;)

 

vSphere 5.0 – Auto Deploy

Ezzel az új funkcióval már hivatalosan is készíthetünk diskless ESXi szervereket, megkönnyítve ezzel az új ESXi szerverek telepítését, éles üzembe állítását, és frissítését is.

A rendszer a következő ábra szerint épül fel:

Működés

  1. Az ESXi szerverek PXE boot segítségével, először is egy IP címet kell hogy kapjanak egy DHCP szervertől
  2. A DHCP szerver az IP-n kívül átadja azt a szükséges információt is, hogy hol keresse a számára előkészített boot image-et.
  3. A boot során az Auto Deploy szerver eldönti, hogy milyen komponenseket kell az adott szervernek betöltenie, és ezeket a rendelkezésére is bocsátja.
  4. A fentiek alapján, az adott szerver egy egyedi, neki szánt modulokat tartalmazó hypervisor-t kap, ami teljes egészében a memóriába töltődve el is indul, maintenance módban.
  5. A vCenter Server a sikeresen elindult ESXi node-ot felveszi a saját inventory-jába, és az image beállításaitól függően berakja a megfelelő Cluster-be.
  6. Rátölti a neki való host profile-t
  7. A maintenance mód megszüntetésével éles üzembe állítja az újonnan elindított ESXi szervert

Beállítások

A fenti működési vázlatból következik, hogy jó néhány szoftverkomponens szoros együttműködésére van szükség a megoldás kivitelezéséhez:

DHCP

Ahhoz, hogy a szerverek PXE boot során kapjanak IP-t, mindenképp szükség van egy DHCP szerverre, ami az IP-n kívül a szükséges információkat is megadja a leendő ESXi szerverünk számára. A vCenter Server Appliance tartalmaz egy dhcp szerver megoldást, ám nincs megfelelően konfigurálva, és értelem szerűen elindítva sem. Az alapvető működéshez a következőkre lesz szükségünk:

# vim /etc/dhcpd.conf

option domain-name "fexmee.com";

authoritative;

use-host-decl-names on;
one-lease-per-client on;

default-lease-time 14400;
max-lease-time 28800;

allow booting;
allow bootp;
deny duplicates;
ddns-update-style none;

# Defines various dhcp options related to gPXE.

option space gpxe;
option gpxe-encap-opts code 175 = encapsulate gpxe;
option gpxe.priority code 1 = signed integer 8;
option gpxe.keep-san code 8 = unsigned integer 8;
option gpxe.no-pxedhcp code 176 = unsigned integer 8;
option gpxe.bus-id code 177 = string;
option gpxe.bios-drive code 189 = unsigned integer 8;
option gpxe.username code 190 = string;
option gpxe.password code 191 = string;
option gpxe.reverse-username code 192 = string;
option gpxe.reverse-password code 193 = string;
option gpxe.version code 235 = string;

subnet 172.26.2.0 netmask 255.255.255.0 {
    range 172.26.2.1 172.26.2.14;
    next-server 172.26.2.31;

    # Tell gPXE to not try and send a second DHCPDISCOVER to get ProxyDHCP
    # information, which makes the boots faster.
    option gpxe.no-pxedhcp 1;

    filename "/tftpboot/undionly.kpxe.vmw-hardwired";

        server-identifier 172.26.2.254;
        option subnet-mask 255.255.255.0;
        option broadcast-address 172.26.2.255;
        option routers 172.26.2.254;

        option domain-name-servers 172.26.2.254;
        option domain-name "fixmee.com";
        option ntp-servers 172.26.2.254;
}

Hogy mindezt kis is szolgálja valahol, szerkesztenünk kell a /etc/sysconfig/dhcpd állományt is, hogy tartalmazzon valami ilyesmit:

DHCPD_INTERFACE="eth0"

Majd, indítsuk is el:

service dhcpd start

És gondoskodjunk arról is, hogy következő boot során automatikusan elindul a szolgáltatás:

chkconfig dhcpd on

 

TFTP

A szerverünknek az IP cím megszerzése után valahogyan el kell tudni érnie a boot image-t, ehhez egy tftp kiszolgálóra lesz szükségünk, amit a vCenter Server Appliance szintén tartalmaz (a megfelelő boot image-ekkel együtt) csak el kell indítani:

service atftpd start

És gondoskodni arról, hogy ez is automatikusan elinduljon boot során:

chkconfig atftpd on

Sok-sok szívástól ment meg bennünket, ha a tramp állományban kijavítjuk az URL-t IP címekre, vagy gondoskodunk a megfelelően beállított DNS név feloldásról.

#!gpxe
set filename https://172.26.2.31:6502/vmw/rbd/tramp
chain https://172.26.2.31:6502/vmw/rbd/tramp

Auto Deploy

Az Auto Deploy szerver valójában egy webszerver kiegésztve egy szabályfeldolgozó motorral (Rules Engine), ami eldönti, hogy melyik szervernek melyik modulokat adja oda. Ez a komponens egyaránt megtalálható a windows alapú és a vCenter Server Appliance megoldás esetében is, így ezzel túl sok teendőnk nincs, mint elindítani…

Image builder

Ahhoz hogy saját, testre szabott ESXi image-eket készíthessünk – vagy a VMware által szállítottakat használhassuk – szükségünk van valamire ami az Auto Deploy szerverre feltölti ezeket, és megfelelő szabályokat hoz létre. Ez lenne az Image Builder, ami valamilyen számomra érthetetlen okból kizárólag PowerCLI segítségével használható. Nem hiszem, hogy a perl API-val nehezebb lett volna megvalósítani a dolgot… ebből is az látszik inkább, hogy ez valójában még nincs kész :(

Tehát, vegyünk egy windows-os gépet, és telepítsük fel a PowerCLI-t, majd töltsük le a VMware által előre csomagolt depot állományt: „ESXi 5.0 Offline Bundle

Majd, készítsünk egy ESXi image-et, a következők szerint:

PowerCLI C:\> Connect-VIServer -server 172.26.2.31

Name                           Port  User
----                           ----  ----
172.26.2.31                    443   root

PowerCLI C:\> Add-EsxSoftwareDepot VMware-ESXi-5.0.0-469512-depot.zip

Depot Url
---------
zip:VMware-ESXi-5.0.0-469512-depot.zip?index.xml

PowerCLI C:\> Get-EsxImageProfile

Name                           Vendor          Last Modified   Acceptance Level
----                           ------          -------------   ----------------
ESXi-5.0.0-469512-no-tools     VMware, Inc.    19/08/2011 1... PartnerSupported
ESXi-5.0.0-469512-standard     VMware, Inc.    19/08/2011 1... PartnerSupported

PowerCLI C:\> New-DeployRule -Name "Initial ESXi5" -Item "ESXi-5.0.0-469512-standard" -AllHosts
. . . 
PowerCLI C:\> Add-DeployRule -DeployRule "Initial ESXi5"

Name        : Initial ESXi5
PatternList :
ItemList    : {ESXi-5.0.0-469512-standard} 

Ezzel, elkészítettünk egy ‘gyári’ ESXi csomagot, amit minden szerver megkaphat. – Ez természetesen csak teszt céljára való, éles körülmények között kicsit szofisztikáltabb szabályokat és csomagokat érdemes létrehozni: erről szól egy másik cikkem: vSphere 5.0 – Image Builder

Ha mindezzel készen vagyunk, akkor máris boot-olhatunk egy új ESX-et:

vCenter Server

Természetesen, mindehez egy vCenter Server is szükséges. A fenti példákban az appliance megoldást vettem alapul. Windows alapú megoldás esetén, a szükségletek hasonlóak, ám ott magunknak kell összevadászni a hiányzó szoftvereket…

Járulékos előnyök

Ez a megoldás, az appliance egyik hiányosságát automatikusan kiküszöböli, ugyanis Update Manager használatára ezentúl nem lesz szükség. Hiszen, a frissítés tulajdonképpen egy új image-re bootolást jelent….

Így, ha egyéb pluginek/kiegészítő szoftverekre nincs szükségünk, ténylegesen megvalósítható egy windows nélküli virtuális környezet – legalábbis szerver oldalon ;)

Biztonság

Soha nem szabad figyelmen kívül hagyni a biztonsági szempontokat, főleg amikor egy virtuális környezetet építünk, ami akár cégünk TELJES szolgáltatási palettájának biztosít virtuális környezetet.

Egyéb esetekben is erősen javasolt a management hálózatot fizikailag is elszeparálni, és tűzfallal védeni az egyéb hálózatoktól, ez esetben viszont kötelező! Hiszen, ezen megoldás alkalmazása esetén nagyon könnyű a boot folyamatba beavatkozni, és ezzel akár egy gonosz módon preparált hypervisort létrehozni, ami éles környezetben katasztrofális következményekkel járhat!

vSphere 5.0 – vCenter Server Appliance

Régóta ígérgetett megoldást publikált a VMware. A vSpher 5.0 verzióba belekerült egy ‘új’ Appliance alapú vCenter Server megoldás. A lényeges része, hogy ez az Appliance Linux alapú! Így tehát megszűnt az az eddigi kényszer, hogy mindenképpen Microsoft termékeket is kell vásárolnunk, a virtuális környezetünk megvalósításához. – Vagy mégsem?

Telepítés

A vCenter Server telepítése sosem volt bonyolult, főleg ha a vele csomagolt adatbázissal telepítjük –  később persze kiderül, hogy ennek nagy ára van. Ha lehet, az Appliance telepítése még egyszerűbb, hiszen ez tulajdonképpen egy előre elkészített virtuális gép .ofv formátumból való importálását jelenti.

Itt egyből elő is kerülnek az első problémák:

  • Szükségünk van egyből egy vSpeher kliensre, ami még mindig CSAK windows-on képes futni,
  • Ha az előző problémát leküzdöttük, kiderül, hogy .ovf formátumból importálni direktbe egy ESX-re csatlakozva NEM lehet. – Így kell egy már meglévő vCenter Server.
  • 5.0 Update1 óta már nem szükséges vCenter ehhez a művelethez, simán az ESX-hez csatlakozva lehet .ovf-ből importálni  – hurrá :)

Ezek után máris szertefoszlott az a halvány remény, hogy windows nélkül is lehet vSphere környezetet kialakítani és üzemeltetni.

Ha ennél a pontnál még adtuk fel, akkor az első feladat a telepítőkészlet letöltése, ami 3 állományból áll:

  • OVF File          ~ 8.1 Kb
  • System Disk    ~ 4.0 Gb
  • Data Disk         ~ 40 Mb

Ezeket egy könyvtárba kell pakolni, mert az importáláskor csak így találja meg őket.

A telepítés folyamata egyszerű, mintha csak egy új virtuális gépet készítenénk. Hasznos dolog, hogy előre megmondja mekkora helyre lesz szükség az általunk választott diszkformátum függvényében:

screenshot-deployovftemplate

Beállítások

A a telepítés végeztével, egy virtuális gépet kapunk:

screenshot-vcenter-5-0-appliance-00

Ezt elindítva, a gép konzolján a következő képernyő fogad:

screenshot-vcenter-5-0-appliance-01

Amit első körben mindenképp be kell állítani az a virtuális gépünk IP címe – hacsak nem kapott egyet a DHCP szervertől már  a boot során.

screenshot-vcenter-5-0-appliance-02

Ha ezzel megvagyunk, máris elérhetjük – a sokkal barátságosabb – webes adminisztrációs felületét, ahol a telepítés után a root/vmware felhasználónév/jelszó párossal be is tudunk lépni:

screenshot-vcenterserverappliance-login

vCenter Server

Belépés után el kell végezni néhány kötelező beállítást, az első és legfontosabb az adatbázis elérés:

screenshot-vcenterserverappliance-database

Ennek aktiválása az ’embedded’ adatbázis használata esetén eltart egy darabig, hiszen ekkor hozza létre a működéséhez szükséges adatbázist (ami egyébként egy DB2 express) Természetesen külső adatbázis használatát is támogatja, ez azonban ennél a verziónál kizárólag Oracle lehet. – Hiszen ki is szeretne MS SQL-t használni, ha épp az MS termékektől készülünk fájó szívvel megválni ;)

Ha elkészült az adatbázis inicializálása, akkor a ‘Status’ fülön elindíthatjuk a vCenter szolgáltatást:

screenshot-vcenterserverappliance-status

Ezek után, máris használatba vehetnénk – a default beállításokkal – amiken ezért javasolt változtatni. Legfontosabb az ‘administrator’ (root) jelszavát lecserélni, és igény szerint ki/be kapcsolni az appliance SSH-n keresztüli elérési lehetőségét:

screenshot-vcenterserverappliance-admin

Ha nem szimpatikusan a szolgáltatások default portjai, azokon is változtathatunk:

screenshot-vcenterserverappliance-settings

Ha külső diszkre (NFS) szeretnénk menteni a logokat, azt is itt állíthatjuk be:

screenshot-vcenterserverappliance-storage

Authentication

Ahogy az eddigi vCenter verzióknál már megszokhattuk, AD integráció lehetősége adott, így nem kell helyi felhasználókkal és csoportokkal bajlódnunk, hanem beleilleszkedhet a cég központi felhasználó és csoport kezelésébe:

screenshot-vcenterserverappliance-auth

Ez megint furcsa lehet, annak fényében hogy mi adott esetben nem szeretnénk MS termékeket használni… Azonban, a Domain Controller kiváltásával több projekt is régóta próbálkozik több-kevesebb sikerrel. Amit erre a célra bátran javasolni tudok az a Zentyal.

Új dolog a NIS használatának lehetősége – én ugyan egyetlen céget sem ismerek aki ilyet használna, de a lehetőség adott ;)

Network

A hálózat fülön találjuk a részletes hálózati beállításokat, Az itt található beállítási lehetőségeket is mindenképp érdemes átnézni/véglegesíteni éles használat előtt:

screenshot-vcenterserverappliance-network

System

Az appliance-ról kapunk némi információt (aktuális verzió) és leállítási lehetőséget a következő felületen:

screenshot-vcenterserverappliance-system

Services

Ezen fülön találhatóak azok a kiegészítő szolgáltatások és beállítási lehetőségeik, amik a virtuális környezetünket teszik/tehetik könnyebben üzemeltethetővé:

screenshot-vcenterserverappliance-services

Syslog

Az appliance kapott egy saját központi log gyűjtő szervert, ami történetesen egy syslog-ng és egy stunnel párosból alkottak. A felületről csak annyit lehet állítani rajta, hogy mely portokon fogadja a logokat. – amiket az ESXi szerverek már SSL csatornán is kápsek küldeni. Ez a log gyűjtő szerver megoldás rengeteg lehetőséggel bír, amennyiben ezt igényeinknek megfelelően szeretnénk beállítani, megtehetjük a parancsoros felületen…

NetDump

Szintén új lehetőség a diskless ESXi megoldások számára, hogy core dumpot hálózaton keresztül képes küldeni – ha van aki fogadja ezeket. Az appliance kapott egy szervert erre a célra is.

AutoDeploy

Ez is egy új lehetőség, segítségével diskless ESXi megoldásokat lehet létrehozni. Természetesen az ehhez szükséges kiszolgáló szoftverek is helyet kaptak az appliance csomagban.

Update

Egy appliance megoldástól alapvető követelmény, a szoftverelemek frissítésének lehetősége:

screenshot-vcenterserverappliance-update-01

screenshot-vcenterserverappliance-update-02

Használat

Ha a fenti beállításokon átrágtuk magunkat, és mindent megfelelően beállítottunk, akkor máris használatba vehetjük az új vCenter megoldást.

Ahogy már a legelején konstatáltam, windows nélkül erre esély sincs. Ugyanis, az egyetlen teljes értékű kliens, még mindig a ‘vSphere Clinet’, ami egy windows-os alkalmazás. Ez esetben, még az a mentőöv is elúszott, amit egyébként alkalmazni szoktunk, hogy a vCenter Server-re telepítünk egy klienst is, és ide csak rdsektoppal belépve, gyakorlatilag bármilyen oprendszer alól tudjuk adminisztrálni a rendszert.

vSphere Client

A – hibáival együtt – megszokott windows-os vSphere Client. Használata esetén az ég világon semmi különbség nincs a windows-os és a Linux-os appliance megoldás között, sőt ki sem lehet deríteni melyik változaton dolgozunk éppen.

vSphere Web Client

Ha a beállításoknál elindítottuk ezt a szolgáltatást, akkor virtuális környezetünket elérhetjük webes felületen is.(Ez a szolgáltatás a windows-os vCenter Server esetében is rendelkezésünkre áll)

screenshot-vspherewebclient-login

Ám, ezen a felületen egyelőre eléggé limitált lehetőségeink vannak. Látszólag ugyanis (majdnem) minden fület/felületet megtalálunk valahol, amit a windows-os kliens használata közben megszoktunk, ám itt legtöbbet csak nézegetni lehet, állítgatni nem.

screenshot-vspherewebclient-cluster

Ha mindezt nagyon optimistán, naivan, vagy esetleg marketinges szemüvegben nézzük akkor tulajdonképpen ez ‘fícsör’ hiszen az átlag felhasználónak – vagy éppen a főnöknek, aki mindent szeretne látni – tökéletesen elegendő szolgáltatást nyújt. És jogosultság kezeléstől függetlenül vannak limitálva a jogaink – a felület hiányosságai révén ;)

Ha viszont objektív véleményt szeretnénk hallani: Ez bizony még nincs kész, ennyit sikerült összehozni a már amúgy is halogatott vSphere 5.0 beharangozásáig.

Ha kifejezetten kritikus szemmel nézzük, akkor belenézünk először az oldal forráskódjába kicsit:

   <!--
   Smart developers always View Source.

   This application was built using Adobe Flex, an open source framework
   for building rich Internet applications that get delivered via the
   Flash Player or to desktops via Adobe AIR.

   Learn more about Flex at http://flex.org
   // -->

És sírva fakadunk. Flash. 2011-ben, egy piacvezető virtuális környezet kezelőfelületeként. – no comment.

Persze, lehetne ez akár jó is, de biztonsági szakemberként nézve a flash egy böngészőbe ágyazott, reklámok, filmek zenék, és biztonsági rések rendkívül gyors terjesztésére alkalmas izé. Ráadásul, ha a platform függetlenséget nézzük, mint megcélzott előnyt: a flash az egyik legtöbbet szidott cucc ami létezik, hiszen mai naping nincs hivatalos 64 bites plugin Linux-ra… És hogy mindez egy böngészőbe van paszírozva, az csak tovább ront a helyzeten.

A VM-ek konzol eléréséhez ezen (Flash plugin) felül még külön plugin is kell, amit ráadásul érthetetlen módon root jogokat igényel, és egy egézs szoftverhalmazt telepít fel a gépünkre – a legnygobb örömünkre.

Majd, ezek után szimplán nem működik:

screenshot-webclient-console-error-01

Névfeloldás egy konzol eléréséhez?? – és könyörgöm, minek a nevét nem tudja??

Teljesen privát véleményem, és eddigi tapasztalataim szerint ez a valami produktív használatra nem alkalmas. Csak a tesztelés során többször dobott hibát, majd megpróbálta újratölteni az ‘oldalt’, aminek az eredménye minden esetben az összes böngészőablakom lefagyása lett.

Azonban, a VMware szerint ez lesz a fejlesztési irány. Ahogy az ESX-et is lassan, de biztosan leváltotta az ESXi, így a jelenlegi – egyetlen teljes értékű – vSphere kliens is ki fog halni, és ennek a webes felületnek a továbbfejlesztett verziója fogja átvenni a helyét. – majd egyszer.

A felület további bemutatása screenshot-okkal kb lehetetlen, és a fentiek tükrében értelmetlen is. Akit érdekel úgyis kipróbálja, akit nem – az meg sokkal jobban jár ;)

VMware Workstation

Újabb fejletsztési irány, hogy a workstation képes kliensként egy vCenterhez, vagy ESXi szerverhez csatlakozni. Egyelőre limitált képességekkel bír, pl ha nem Administrator jogosultségú felhasználóval lépünk be, kb semmire nem használható :P – szóval van még hová fejlődnie ;)

Remote CLI

A szokásos, eddig is meglővő parancssoros ‘kezelőfelületek’, melyből több verzió is létezik:

  • PowerCLI

Windows-os rendszergazdák szerethetik – használható parancssr Windowsra ;)

  • Perl SDK

Linux, és egyép Perl-t futtatni képes Operációs rendszerek számára nyújt kényelmesen használható management parancsokat.

  • vSphere Management Assistant (vMA)

Egy újabb Appliance, ami valójában egy Linux + a Perl SDK, így nem kell mindenkinek a gépre ezeket felpakolni, hanem egy központi management gépet hozhatunk létre segítségével :)

Üzemeltetés

Az eddigiek során kiderült, hogy kliens oldalon továbbra is mindenképp kell windows a virtuális környezet üzemeltetéséhez, nézzük most a szerver oldalt, mit nyerünk azzal hogy Linuxon fut?

Itt máris leszögezném, hogy egy windows rendszergazda szemszögéből semmit, sőt neki valószínűleg egyáltalán nem való ez, még akkor sem ha az ‘appliance’ csomagolás miatt mindez könnyen kezelhetőnek tűnik.

Tehát, a továbbiak kifejezetten Lunux rendszergazdáknak szól, és persze azoknak akik számára eddig problémát jelentett a sok járulékos Microsoft licenc…

„Under the hood” – azaz, mit is kaptunk valójában?

SSH belépés után érdemes kicsit körülnézni, ugyanis sok ismerős dolgot fogunk találni:

vcenter5:~ # cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 1

Tehát, egy SUSE az alapja mindennek…

vcenter5:~ # uname -a
Linux vcenter5.iw-service.andrews 2.6.32.29-0.3-default #1 SMP 2011-02-25 13:36:59 +0100 x86_64 x86_64 x86_64 GNU/Linux

 

vcenter5:~ # df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             9.8G  3.9G  5.4G  43% /
devtmpfs              4.0G  104K  4.0G   1% /dev
tmpfs                 4.0G  4.0K  4.0G   1% /dev/shm
/dev/sda1             130M   18M  105M  15% /boot
/dev/sdb1              20G  173M   19G   1% /storage/core
/dev/sdb2              20G  624M   19G   4% /storage/log
/dev/sdb3              20G 1001M   18G   6% /storage/db

Ahogy láthatjuk, nincs túlfényezve a partícionálás, arre figyelni is kell, amint élesben üzemeltetjük, ugyanis a logok mennyisége egyelőre ismeretlen, de nagy számú ESX esetén mégis gyorsan betelhet…

Nézzük, mit kínál a hálózaton:

vcenter5:~ # netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
tcp        0      0 127.0.0.1:389           0.0.0.0:*               LISTEN      9195/slapd          
tcp        0      0 0.0.0.0:135             0.0.0.0:*               LISTEN      11265/dcerpcd       
tcp        0      0 127.0.0.1:32200         0.0.0.0:*               LISTEN      9833/java           
tcp        0      0 127.0.0.1:32300         0.0.0.0:*               LISTEN      10105/java          
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      6885/portmap        
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      9234/vpxd           
tcp        0      0 127.0.0.1:8085          0.0.0.0:*               LISTEN      9234/vpxd           
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      5690/sshd           
tcp        0      0 0.0.0.0:47543           0.0.0.0:*               LISTEN      11312/eventlogd     
tcp        0      0 127.0.0.1:8089          0.0.0.0:*               LISTEN      9234/vpxd           
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      7094/sendmail: acce
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      9234/vpxd           
tcp        0      0 127.0.0.1:8005          :::*                    LISTEN      9482/java           
tcp        0      0 ::1:389                 :::*                    LISTEN      9195/slapd          
tcp        0      0 :::21000                :::*                    LISTEN      10105/java          
tcp        0      0 :::5480                 :::*                    LISTEN      5332/vami-lighttpd  
tcp        0      0 :::8009                 :::*                    LISTEN      9482/java           
tcp        0      0 :::1514                 :::*                    LISTEN      6973/stunnel        
tcp        0      0 :::10443                :::*                    LISTEN      9833/java           
tcp        0      0 :::523                  :::*                    LISTEN      5835/db2dasrrm      
tcp        0      0 :::21100                :::*                    LISTEN      10105/java          
tcp        0      0 127.0.0.1:8080          :::*                    LISTEN      9482/java           
tcp        0      0 :::80                   :::*                    LISTEN      9234/vpxd           
tcp        0      0 :::50000                :::*                    LISTEN      5768/db2sysc        
tcp        0      0 :::5488                 :::*                    LISTEN      5357/vami-sfcbd     
tcp        0      0 :::9009                 :::*                    LISTEN      7015/java           
tcp        0      0 :::5489                 :::*                    LISTEN      5356/vami-sfcbd     
tcp        0      0 :::9875                 :::*                    LISTEN      7015/java           
tcp        0      0 ::1:8085                :::*                    LISTEN      9234/vpxd           
tcp        0      0 :::22                   :::*                    LISTEN      5690/sshd           
tcp        0      0 ::1:8089                :::*                    LISTEN      9234/vpxd           
tcp        0      0 :::8443                 :::*                    LISTEN      9482/java           
tcp        0      0 :::443                  :::*                    LISTEN      9234/vpxd           
tcp        0      0 :::38619                :::*                    LISTEN      7015/java           
tcp        0      0 :::10109                :::*                    LISTEN      9833/java           
tcp        0      0 :::10080                :::*                    LISTEN      9833/java           
tcp        0      0 :::46305                :::*                    LISTEN      7015/java           
tcp        0      0 :::9090                 :::*                    LISTEN      7015/java           
tcp        0      0 :::514                  :::*                    LISTEN      6965/syslog-ng      
tcp        0      0 :::9443                 :::*                    LISTEN      7015/java

vcenter5:~ # netstat -ulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
udp        0      0 0.0.0.0:111             0.0.0.0:*                           6885/portmap        
udp        0      0 0.0.0.0:902             0.0.0.0:*                           9234/vpxd           
udp        0      0 0.0.0.0:135             0.0.0.0:*                           11265/dcerpcd       
udp        0      0 0.0.0.0:523             0.0.0.0:*                           5835/db2dasrrm      
udp        0      0 0.0.0.0:6500            0.0.0.0:*                           6995/vmware-netdump
udp        0      0 :::514                  :::*                                6965/syslog-ng      
udp        0      0 :::902                  :::*                                9234/vpxd

Karácsonfa. De mit is vártunk? VMware-ék egyelőre nem kápráztattak el bennünket Linux-os tudássukkal :P

Ebből mindenesetre az a tanulság, hogy erre a gépre nagyon kell ‘vigyázni’. Helyi tűzfal szabályokkal kitiltani a publikálni nem kívánt portokat, és mindenképp külön szeparált management hálózatba rakni (az ESX-ekkel együt)

Az is látszik, hogy bár elvileg ipv6 nem támogatott – gondolom alkalmazás oldalról – ám mivel a linux és az alkalmazást kiszolgáló szoftverek már régóta fel vannak készítve errre, ha nem tiltjuk külön le, akkor bizony ipv6-on is fog figyelni minden – ami határozottan nem jó nekünk

Nézzük mit tettek meg ennek védelmében ‘a gyárban’:

vcenter5:~ # iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Ahogy látjuk, Ők nem foglalkoznak ilyesmivel – egyelőre.

Íme egy process lista ,amiből minden egyéb részlet is kiderül, és egy ottfelejett log, amiből pedig azt tudhatjuk meg hogy készült az appliance ;)

Az üzemeltetés szempontjából fontosabb elemek:

  • Linux kernel

Ezzel túl sok teendőnk nem akad, ám az ipv6 támogatás kikapcsolás javasolt.

  • csomagszűrű tűzfal

Amint a fentiekből kiderül, lenne mit korlátozni, ám a gyári beállítások nem tartalmaznak semmilyen tűzfalszabályt, ami éles környezetben könnyen védtelen áldozattá teheti az egész rendszerünket.

  • ssh

Jelszavak helyett kulcs alapú bejelentkezés javasolt, ennek megfelelően a password auth tiltása is.

  • Sendmail

Ha szükségünk van a levelezés állítgatására, akor megtehetjük – ha értünk a sendmailhez ;)

  • Syslog-ng

A loggyűjtő szerver, egy nagyon egyszerű konfiggal szállítva. Ha konolyan vesszük a loggyűjtést/elemzést, akkor ezen mindenképp kell állítgatni…

  • stunnel

A syslog-hoz van egy alap konfigja, de ha valóban biztonságos loggyűjtést szeretnénk, akkor ezen is állítgatni kell…

  • tomcat

Aki ért hozzá, annak javasolt átnézni, és optimalizálni a beállításait.

  • DB2 Express

Szintén hozzáértők állíthatják a saját igényeiknek megfelelőre…

  • vmware specifikus processek

Ezzel valójában nem nagyon tudunk mit kezdeni – de ha baj van velük, lehet kill-elni legalább ;)

És végül, a fekete leves:

A fentiekből levonhatjuk a következtetéseket, hogy mindez jó-e/kell-e nekünk vagy sem… Ám, egy komolyabb virtuális környezethez ezeken kívül is kell még egy csomó minden, ami az Appliance használata esetén jelenleg még nincs megoldva:

  • Update Manager
  • vCenter Converter
  • Orchestrator
  • egyéb ‘külős’ pluginek és kiegészítők

Ezek ugyanis vagy külön windows alapú gépet/gépeket igényelnek, vagy egész egyszerűen nem működnek az appliance használata esetén.

Szóval, összességében ez egy kezdeti állapota valaminek, amit még nagyon nem sikerült befejezni, de talán majd egyszer. Addig is használhatjuk a ‘régi’ windows-os megoldást, vagy ha a jelenlegi állapot megfelel, kísérletet tehetünk egy windows nélküli virtuális környezet megteremtésére, ám ezesetben sok-sok dolgot nekünk kell a helyére kalapálni

vSphere 5.0 – Hypervisor

Elérkezett a pillanat, innentől nincs többféle – különböző tulajdonságokkal és üzemeltetési különbségekkel rendelkező – hypervisor. A vSphere 5.0-ben már csak az ESXi az egyetlen változat.

Ez azonban jó dolog, és már nagyon régóta ebbe az irányba tolják a vmware hypervisor szekerét. Remélhetőleg, az eddigi sok félreértés is tisztázódok az ingyenes és a fizetős ESX verziók körül.

Maga a hypervisor látszólag nem sokat változott, kisebb-nagyobb újítások azonban kerültek bele. Minderről bővebben a vmware hivatalos oldalán olvashatunk, én csak az újításokat részletezném a 4.1 verzióhoz képest:

  • Admin/config CLIs

Ez tulajdonképp a régi, jól bevált BusyBox-ra épülő parancssoros felület, amit többféleképpen is elérhetünk: közvetlenül a konzolon beléve,  ssh-n keresztül, vagy remote CLI-n keresztül (Powershell/perl)

Az itt található parancsok szakértő kezekben nagyon hasznosak lehetnek, ám hozzá nemértéssel egycsapásra lerombolhatjuk az egész ESX szervert és a rajta futó virtuális gépeket egyaránt!

Aki ezek után is parancssorban szeretne bűvészkedni, azok számára kötelező olvasmány az ide vonatkozó hivatalos dokumentáció!

  • Rapid deployment (Auto Deploy)

Ezzel a témával külön is fogok foglalkozni, azonban mivel ennek a gyakorlatban csak nagy számú ESX telepítéseknél van értelme, erről külön bejegyzés is született…

  • Secure syslog

Ez egy remek lehetőség, ám a használatához kell egy szerver is, ami fogadja a logokat. Az újdonság ebben, hogy már nem csak UDP-n képest logokat küldeni, hanem TCP-n, sőt SSL csatornába csomagolva is, így a logok titkosítva közlekedhetnek a hálózaton. Ezen felül a vCenter Server mellé csomagoltak egy syslog szervert is így ezt nem kell külön keresgélni ;)

Beállítása azonban nem triviális, parancssorból lehet csak bekapcsolni, vagy a vSphere Client segítségével az ‘Advanced Settings’ részben kitölteni a megfelelő mezőket. Hogy pontosan mit, és hogyan kell állítani megtalálható itt.

Még ez sem elég, ugyanis egyelőre a szép új tűzfal nem fogja kiengedni ezt a forgalmat, tehát ott is ki kell engedni, hogy a remote logging működjön…

  • Management interface firewall

Ezt a ‘fícsört’ valamiért kissé túl lihegik a marketingesek. Szerintem, eddig is teljesen rendben volt az Iptables alapú megoldás. Most sem kapunk sokkal többet, ugyan úgy a felületről kapcsolgathatjuk mit lehet elérni, és mit nem. Az ‘újdonság’, hogy forrás/cél IP-re is szűrhetünk, és a kimenő kapcsolatok engedélyezésének/tiltásának lehetősége, ami véleményem szerint több mint felesleges.

Ha biztonságban szeretnénk tudni az ESX-ek management interface-eit, akkor az egyetlen a gyakorlatban is működő megoldás a hálózati szeparáció. Külön hálózati szegmensbe kell tenni ezeket, és ide csak azokat a portokat beengedni, amik az üzemeltetésükhöz szükségesek. (Persze ez külön téma, tartottam is már előadást a 2010-es v-day rendezvényem, és a VMUG-on is erről. Az előadás anyaga elérhető innen is: vSphere-Hardening)

  • Telepítés, management

A ‘hagyományos’ ESXi telepítés esetén szinte semmi nem változott. A telepítő enél a verziónál a licenc feltételek elfogadása után csak azt várja tőlünk, hogy jelöljük ki melyik eszközre szeretnénk telepíteni a hypervisort, és hogy már a telepítés során adjunk a ‘root’ felhasználónak egy jelszót.

Ezek után, a megszokott sárga/fekete képernyős kozol köszönt minket, ahol szokás szerint a managemet interface konfigurálását kell mindenképp elvégeznünk, hogy utána a vSphere Clinet-en keresztül elérhető legyen a frissen telepített  ESXi szerverünk.

Biztonságos desktop OS?

Sajnos kevesen vannak egyáltalán tisztában azzal, hogy miféle veszélyeknek van kitéve egy átlagos felhasználó számítógépe, és a rajta tárolt bizalmas/értékes adatai. Ha pedig nem átlagos, hanem pl: magas beosztású vezetőről, vagy bizalmas adatokkal dolgozó szakemberekről, vagy éppen egy IT biztonsági szakemberről van szó, akkor a veszély még komolyabb!

A hordozható számítógépek, okostelefonok, és egyéb kütyük elterjedésével a helyzet csak egyre romlik, hiszen ezekkel az eszközökkel céges hálózatokat, leveleket, és egyéb bizalmas adatokat is elérhetünk.

A leggyengébb láncszem persze legtöbbször maga a felhasználó. Köszönhető ez a informatika világának rohamos – sokak számára követhetetlen – fejlődésének, és a marketing gépezetnek, ami pedig elhiteti velünk, hogy a fészbúk elérése a legfontosabb dolog a világon ;)

Aki képes ezen átlátni, és egy kicsit is érdekli, hogyan tudhatja biztonságban a laptopján tárolt adatait, az lapozza végig ezt a rövid prezentációt, ami valójában már egy konkrét megoldásra is fókuszál, azonban termékektől függetlenül is a probléma forrására igyekszik felhívni a figyelmet…

A megoldás: szeparáció

Előfeltételek

A fenti ábrán látható architektúra megvalósításának elengedhetetlen feltételei a következők:

Hardver

Ez alapvető fontosságú processzor feature. Ennek megléte (bekapcsolt állapota) nélkül egyáltalán nem használható egyetlen HVM Hypervisor sem. Bővebben…

A Xen azonban nem csak HVM domaineket (virtuális gépekt) képes létrehozni, sőt a Qubes 1.0 VT-x nélkül is működőképes, mivel nem HVM virtualizációt használ.

Ez a fícsört szinte minden mai processzor támogatja, ám sok laptop BIOS-ból hiányzik a ki/be kapcsolás lehetősége. Az én laptopom (Esprimo V5505) is ebbe a kategóriába tartozik, így kicsit hackelni kellet a BIOS-t hogy bekapcsolható legyen.

Ez a chipset feature ahhoz szükséges, hogy a különböző I/O eszközöket is biztonságosan hozzárendelhessünk különböző VM-ekhez. Ennek megléte nélkül technikailag működőképes megoldást hozhatunk létre, viszont biztonsági szempontból nem leszünk sokkal előrébb. Bővebben...

Megléte opcionális, ezzel még tovább növelhetjük rendszerünk megbízhatóságát.

Az Intel legújabb technológiája, ami a fent említett ‘alap’ dolgokon felül, a még teljesebb hardver virtualizáció megvalósítását tűzte ki célul. Bővebben…

Szoftver

Ha a hardveres alapfeltételek adottak, akkor már csak a megfelelő szoftver kell a megvalósításhoz. Technikailag bármelyik Hypervisor alkalmas lenne erre, a gyakorlatban mégis egyelőre csak Xen alapú megoldások léteznek:

A projekt egyelőre ‘beta’ állapotban van, azonban technikailag a legjobbat szeretnék kihozni belőle, így a biztonság az első és legfontosabb szempont. Ennek ellenére egyedülálló integrációs kiegészítő szoftvereken dolgoznak, ami a különböző VM-ek közötti állománycserét, és interakciót igyekeznek biztosítani ‘felhasználóbarát’ módon.

Egyetlen hátrányos tulajdonsága, hogy egyelőre csak Linux alapú VM-eket lehet benne használni, egészen konkrétan: Fedora Mivel sokaknak nem ez a szimpatikus disztribúció, így az ismeretlen felület és beállítási lehetőségek a tesztelés során némi kényelmetlenséget okozhatnak.

Nagyobb baj az, hogy akinek elengedhetetlen a windows-os VM, az nem sokra megy ezzel egyelőre :(

A projektről azóta több cikk is született:

  1. Qubes – Beta3
  2. Qubes 1.0 – RC1

Ez a szoftver a Citrixtől, ugyan ezt ígéri, ám esetükben a windows az alapértelmezett VM, a Linux egyelőre ‘experimental’ jelzéssel van ellátva.

A termékről azóta külön cikk is született…

 

vSphere 5.0 – az ígéret földje …izé, felhője

A VMware nemrég hivatalosan is bejelentette a virtualizációs platformjának legújabb verzióját: VMware vSphere 5.0 Ez azért nagyon jó hír, mert a „Beta Program” keretein belül már jó ideje elérhetőek az új termékek, ám a hivatalos bejelentés előtt – a licencszerződés értelmében – még beszélni sem lehetett róla.

Így a bejelentés után, de még a megjelenés előtt, még mindig meg van kötve a kezünk, ugyanis egyelőre csak a marketing anyagokat oszthatjuk meg az érdeklődőkkel, de a háttérben már gőzerővel folyik a tesztelés is…

Amint lehet, a gyakorlati tapasztalatokról is beszámolok – főleg az újdonságokra koncentrálva.

 

A marketing ígéretek – vagyis az újdonságok

Your Cloud

Ez az új szlogen.

Sajnos manapság mindenki azt ért alatta, amit akar. Így nem csoda, ha egy átlagember – még ha történetesen IT területen dolgozik is – félinformációkból próbál elképzelni valami nagyon misztikus dolgot, amit a marketingesek  privát/publikus felhőnek neveznek, és mindenképp meg akarják győzni, hogy neki bizony erre szüksége van.

Hypervisor

vSphere ESXi – az új irány

Már régóta az a trend, hogy a ‘régi’ ESX helyett az ESXi verzió használatát javasolják. – Ettől függetlenül, még mindig létezik mindkét verzió… Sajnos, nagyon sokan (a „szakemberek” között is!) nincsenek tisztában a verziók közötti különbségekkel, ezért erről is írok majd külön, addig is a vmware oldalai nyújthatnak segítséget ebben.

A témáról külön post is született…

vSphere Auto Deploy

Ezzel a lehetőséggel egy új ESX telepítési és frissítési megoldást ígérnek, a még kényelmesebb és gyorsabb cluster bővítés érdekében.

A témáról külön post is született…

Új virtuális hardver verzió (Version 8)

Új virtuális hardver elemek, többek között:

  • 3D grafika Windows Aero támogatással,
  • USB 3.0 eszközök támogatása

Apple OS X támogatás

Újabb guest operációs rendszer támogatás: OS X Server 10.6 (Snow Leopard)

Storage

vSphere Storage DRS

A virtuális gépek különböző teljesítményű storage tárhelyek közötti dinamikus elosztását biztosítja számunkra. Ha több, különböző teljesítményű/rendelkezésre állású/tárterületű tárhely áll a virtuális gépek rendelkezésére, ezzel a szolgáltatással igény szerint tudjuk elosztani rajtuk a virtuális gépeket. – Ezt eddig ‘kézzel’, statikusan kellett előre eldönteni…

 

Storage Profile

Ezzel a szolgáltatással a virtuális gépek számára automatikusan különböző SLA-kat biztosító tárhelyeket rendelhetünk, ezzel biztosítva, hogy a virtuális gépeink minden esetben a megfelelő storage területre kerüljenek.

vSphere File System

Újabb verziójú VMFS filerendszer…

vSphere Storage I/O Control

NFS datastore-ok használata esetén korlátozhatjuk/garantálhatjuk egy-egy virtuális gép I/O hozzáférését az adott storage területekhez.

vSphere Storage API Program

Új, kiegészítő lehetőségeket biztosít a storage rendszerrel való együttműködésben, támogatva a Storage DRS-t, és a Storage Profile-okat is.

Hálózat

vSphere Network I/O Control

Új, virtuális gépenkénti sávszélesség szabályzás lehetősége, a további finomhangolás érdekében.

vSphere Distributed Switch

Új lehetőségek a virtuális gépek forgalmának monitorozására Switched Port Analyzer (SPAN)
és Link Layer Discovery Protocol (LLDP) támogatással

Szolgáltatások

vSphere High Availability

Új HA architektúra, az egyszerűbb konfiguráció és a jobb skálázhatóság érdekében. – meglátjuk.

vSphere Vmotion

Már nagyobb késleltetésű hálózatokon is stabilan működő VMotion.

ESXi Firewall

Szolgáltatás központú, állapottartó csomagszűrő megoldás, ami ‘third-party’ modulok használata esetében válhat igazán hasznossá. – Állítólag.

Nagyobb teljesítmény

Akár 4x nagyobb teljesítményű virtuális gépek használata is lehetséges, maximum:

  • 32 vCPU
  • 1 TB RAM

A gyakorlatban eddig soha nem ütköztem ilyen korlátba, ezzel biztosították hogy a jövöben sem fogunk – egy darabig ;)

Management

vSphere Web Client

Webes felületről is elérhető szolgáltatások – Hasonló, de sikertelen próbálkozások korábban is voltak, kíváncsi vagyok most mit sikerült összehozni.

A témáról külön post is született…

VMware vCenter Appliance

Linux alapú  vCenter Appiance megoldás – végre :)

A témáról külön post is született…

 

Az eredeti marketinganyag elérhető itt, a vmware oldaláról.