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:
Beállítások
A a telepítés végeztével, egy virtuális gépet kapunk:
Ezt elindítva, a gép konzolján a következő képernyő fogad:
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.
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:
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:
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:
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:
Ha nem szimpatikusan a szolgáltatások default portjai, azokon is változtathatunk:
Ha külső diszkre (NFS) szeretnénk menteni a logokat, azt is itt állíthatjuk be:
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:
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:
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:
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é:
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:
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)
Á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.
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:
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…