ESXi – Telepítés USB-ről
Az ESXi egyik leggyakrabban használt telepítési média a pendrive, ennek előkészítését a VMware mégsem teszi egyszerű feladattá.
Az ESXi egyik leggyakrabban használt telepítési média a pendrive, ennek előkészítését a VMware mégsem teszi egyszerű feladattá.
Már jó ideje megjelent a vSphere termékcsalád 5.1-es verziója, ami nem kevés új szolgáltatást is ígér az 5.0-hoz képest. A legtöbb változás azonban mindenképp a vCenter Server egyes szolgáltatásaiban és működésében található.
Miután átfutottuk a szemkápzáztató és remek új fícsörökről szóló hivatalos kiadványt, felocsúdásképp nem árt tüzetesen végigolvasni a koránt sem annyira bíztató, és lényegesen hosszabb ismert hibák listáját is!
Ahogy az látható, a legtöbb dolog a vCenter Server újdonságairól szól – azonban az ezzel kapcsolatos hibák ismert problémák sokasága több mint szánalmas. Első olvasás után azt hittem, hogy véletlenül a béta programba tévedtem… de nem, ez bizony a hivatalos ‘stabil’ kiadás… ráadásul a verziószám alapján is csak kisebb változásokra számítottam.
Ettől függetlenül, igen nagy bizalommal álltam neki a tesztelésnek, ugyanis olyan változtatásokat eszközöltek, amik jelentősen növelték a vSphere 5.0 verziójában megjelent vCenter Server Appliance megoldás életképességét.
Megfigyelhető, hogy a ‘normál’ windows alapú vCenter Serverről egyáltalán nem írok. Ennek az az oka, hogy valójában ugyan az a java alkalmazáshalmaz mindkét megoldás, csak MS Windows és MS SQL szerver kell alá. Mivel számunkra mindkettő csak felesleges kínokat jelent, így örömmel szabadultunk meg tőlük véglegesen.
Lássuk tehát a vCenter Server Appliance újdonságait:
Gyorsan rájöttek hogy a DB2 ezen termék esetében zsákutca, és végre belátták hogy egy nyílt forrású termékre kell cserélni, így az appliance saját belső adatbázisa az 5.0.1 verziótól már PostgreSQL alapú. Hurrá! :)
A komponens neve – köszönhetően az erős marketing nyomásnak – sajnos eléggé megtévesztő. Valójában ez egy authentikációs szerver, ami a következő forrásokból képes authentikálni a felhasználókat:
Tehát az őt kiszolgáló operációs rendszerben létező felhasználók és csoportok alapján. Ez a funkció már eddig is létezett, ám ennek használata éles üzemben biztonsági okok miatt nem javasolt.
Ha minden egyéb rendszertől függetleníteni szeretnénk a vCenter felhasználók kezelését, akkor ez nagyon hasznos lehetőség. Fontos továbbá, hogy csak ebben az esetben van lehetőség a felhasználóknak a saját jelszavuk megváltoztatására a vSphere Web Client-en keresztül.
A felhasználókat és a csoportokat tudja standard LDAP adatbázisból is venni, azonban arról nem szól egyetlen (általam ismert) dokumentáció sem, hogy milyen objektumokat kellene ebben létrehoznunk, hogy ez sikerüljön is :(
Ez a leggyakrabban használt megoldás, ugyanis legtöbb helyen már létezik AD, amiben a felhasználókat nyilvántartják, így alapvető igény hogy a vCenter is része lehessen ennek jónak. A megvalósítása kétféleképpen lehetséges:
Az AD-t, csak LDAP forrásként használja
Az AD ugyanis valójában – bármennyire is szeretik ezt elmisztifikálni – egy egyszerű LDAP adatbázisra épül. Ez esetben a vCenter (vagy annak bármilyen komponense) nincs beléptetve a domain-ba, ‘csak’ egy ‘service account’-ra van szüksége, hogy le tudja kérdezni a felhasználók adatait. (ez a gyakorlatban sajnos domain adminisztrátori jogokat jelent)
Belép az AD által nyújtott domain-be
Ilyenkor az SSO szerver belép a domain-be, mint egy normál munkaállomás. KIZÁRÓLAG ilyenkor beszélhetünk SSO-ról, ugyanis ez esetben a domain-be beléptetett kliensek kerberos ticketek segítségével authentikálna a vCenter szolgáltatásokhoz, így nincs szükség a felhasználónév/jelszó páros ismételt bevitelére.
Persze ha elvonatkoztatunk a hagyományos felhasználóktól, akkor valóban beszélhetünk SSO-ról, hiszen az egyéb ‘service accountok’ is az SSO szerverbe authentikálnak, és ennek segítségével érik el az összes egyéb vSphere alkalmazást..
Szóval összességében ez előrelépés, hiszen egy nagyon fontos dolgot – az auhtentikációt – egy külön szolgáltatásként oldották meg, levéve ezt a feladatot az amúgy is kaotikus alkalmazáshalmazról, amit eddig együttesen vCenter Servernek neveztek. Persze, a ‘vCenter Server’ mint olyan, továbbra is alkalmazások összességét jelenti, a különbség csak annyi, hogy az egyes feladatok jobban elkülöníthetőek egymástól mint eddig.
A gyakorlatban viszont még(?) egy csomó probléma van vele, ami nem is meglepő hiszen valami teljesen új dologról van szó, amit egyszer csak ‘upgrade’ néven belecsaptak a vCenter Server szolgáltatáskupacba. Éppen ezért, éles üzembe csak úgy érdemes állítani, ha minden használni kívánt esetet előtte kipróbáltál, vagy fel vagy készülve az esetleges üzem közbeni meglepetésekre!
Ahhoz képest, hogy az 5.0-ban megjelent webes kliens nem lett az igazi, az 5.1-ben elkerülhetetlen a használata, mert sok új dolog – köztük az SSO szerver – CSAK ezen a felületeten keresztül konfigurálható.
Ehhez mérten sokat javult, már-már használható is lett, de azért kicsit túlzás hogy van amit csak ebből lehet megoldani. Amik hiányoznak és/vagy problémásak:
Úgy tűnik, nem vicceltek, totálisan komolyan gondolják hogy egy böngészőben futó flash izén keresztül kattintgassuk az egész cégünk – vagy sok esetben több cég TELJES virtuális környezetét. Mivel ezen változtatni nem nagyon tudunk, így bele kell törődni, hogy ez van.
Amit tehetünk, hogy kizárólag egy megbízható kliens gépről (ami semmi egyebet nem tud elérni) engedjük csak adminisztrálni a rendszert, és/vagy az adminisztrátorok kliens gépein igyekszünk csökkenteni az ebből adódó igen súlyos biztonsági problémákat: Qubes-OS.
Ez az egyébként igen hasznos fícsör úgy néz ki hiányzik a webes kliensről :(
Az eddig megszokott java-s cucc sem volt tökéletes, de már megszoktuk. A webes kliens esetében egy újabb (magát böngésző plugin-nek nevező) izére van szükségünk. Ám ennek a valaminek valójában semmi köze a böngészőhöz, ami egy csomó probléma forrása: nem küld tanúsítványt, nem oda kapcsolódik ahová a böngésző (emiatt NAT mögé tenni lehetetlen), rendszergazda jogokkal lehet csak telepíteni, és mind emellé még lassú is.
De legalább Linux-on is fut, tehát tulajdonképpen innentől nincs szükség többé windows operációs rendszerrel rendelkező adminisztrátor gépre!
Ugyan biztonság szempontjából eddig sem volt a csúcson, most hogy böngészőn keresztül érhető el, csak még tovább romlott a helyzet. Tehát, még mindig az a javasolt üzemeltetési megoldás, hogy a vCenter (és az ESX-ek) bármilyen felületét csak és kizárólag az arra feljogosítottak érhessék el…
A webes kliens teljes dokumentációja megtalálható a VMware hivatalos dokumentációi között.
Már a 5.0 esetében is probléma volt vele, miszerint csak bizonyos verziószámú böngészőkből hajlandó működni. Ezt sajnálatos módon az 5.1-es verzióban sem javították, de cserébe született róla egy KB bejegyzés.
Összességében tehát rengeteg új és hasznos változtatás került az 5.1 verzióba, csak én ezt még nem merném stabil – és éles környezetben bátran használható – kiadásnak nevezni.
Természetesen mivel mi már kitapasztaltuk az újdonságok miatt keletkezett legtöbb buktatót, így már meglévő – és leendő ügyfeleinknek ezen problémákkal már nem kell egyedül megküzdeniük.
Kevesen tudják, hogy a VMware létrehozott egy repository-t a különböző operációs rendszerekhez előre csomagolt hivatalos VMware Tools csomagok számára. Ez a megoldás alternatív telepítési lehetőséget nyújt, az eddig használt vSphere Client-ből kezdeményezett telepítés mellett.
Tehát, nem kell többé forrásból, vagy – az operációs rendszerünk csomagkezelőjébe nem illő – bináris telepítőkészlettel bajlódni, használhatjuk az operációs rendszer által biztosított szabványos csomagkezelőt a vmware-tools csomagok telepítésére is.
Azaz, a vmware-tools csomagok telepítése ezesetben pont olyan egyszerűvé válik, mint egy normál szoftvercsomag telepítése. Mindemellett, a csomagok közül lehetőség van csak a számunkra szükségeseket feltelepíteni, és ezekből is kiválaszthatjuk a számunkra legmegfelelőbb verziót.
Vagyis, az adott VMware környezettől függetlenül frissíthető, azaz a vmwate-tools csomagok telepítése nem függ többé az ESXi verzióktól. Ezt a megoldást használva, az adott operációs rendszer csomagkezelőjére bízhatjuk a frissítéseket – ahogyan a többi egyszerű szoftvercsomag esetében is tesszük.
A VMware hivatalos támogatást nyújt hozzá, ami produktív környezetben fontos követelmény lehet…
Ahhoz hogy a csomagkezelőnk ellenőrizni tudja a csomagok hitelességét először is telepíteni kell a VMware aláíró kulcsát:
rpm --import http://packages.vmware.com/tools/VMWARE-PACKAGING-GPG-KEY.pub
Ezek után, fel kell vennünk magát a repository-t, amihez hozzunk létre /etc/yum.repos.d/vmware-tools.repo néven egy állományt, a következő tartalommal:
[vmware-tools] name=VMware Tools baseurl=http://packages.vmware.com/tools/esx/<esx-version>/<dist>/<arch> enabled=1 gpgcheck=1
Amiben a következő mezőket kell értelem szerűen lecserélni:
A fentiek elvégzése után, a szokott módon telepíthetjük is a vmware-tool csomagokat:
yum install vmware-tools ... Dependencies Resolved ============================================================================================================================================= Package Arch Version Repository Size ============================================================================================================================================= Installing: vmware-tools x86_64 8.3.12-559003.el6 vmware-tools 2.7 k Installing for dependencies: vmware-open-vm-tools x86_64 8.3.12-559003.el6 vmware-tools 2.8 k vmware-open-vm-tools-common x86_64 8.3.12-559003.el6 vmware-tools 5.0 M vmware-open-vm-tools-kmod x86_64 8.3.12-559003.el6 vmware-tools 93 k vmware-open-vm-tools-nox x86_64 8.3.12-559003.el6 vmware-tools 2.6 k vmware-open-vm-tools-xorg-drv-display x86_64 11.0.1.0-0.559003.el6 vmware-tools 33 k vmware-open-vm-tools-xorg-drv-mouse x86_64 12.6.7.0-0.559003.el6 vmware-tools 18 k vmware-open-vm-tools-xorg-utilities x86_64 8.3.12-559003.el6 vmware-tools 7.5 M vmware-tools-common x86_64 8.3.12-559003.el6 vmware-tools 39 k vmware-tools-nox x86_64 8.3.12-559003.el6 vmware-tools 2.6 k Transaction Summary ============================================================================================================================================= Install 10 Package(s) Upgrade 0 Package(s)
Ahhoz hogy a csomagkezelőnk ellenőrizni tudja a csomagok hitelességét először is telepíteni kell a VMware aláíró kulcsát:
wget http://packages.vmware.com/tools/VMWARE-PACKAGING-GPG-KEY.pub apt-key add VMWARE-PACKAGING-GPG-KEY.pub
Ezek után, fel kell vennünk magát a repository-t, amihez hozzunk létre /etc/apt/sources.list.d/vmware-tools.list néven egy állományt, a következő tartalommal:
deb http://packages.vmware.com/tools/esx/<esx-version>/ubuntu <dist> main restricted
Amiben a következő mezőket kell értelem szerűen lecserélni:
A fentiek elvégzése után, a szokott módon telepíthetjük is a vmware-tool csomagokat:
apt-get install vmware-open-vm-tools-kmod-`uname -r |cut -d - -f3` apt-get instal vmware-tools
Előző cikkeimben bemutatásra került a VMware új, Linux alapú vCenter Server Appliance megoldása, és a vele együtt debütáló egyik új lehetőség: az Auto Deploy. Ezekben a cikkekben megismerkedhettünk az új termékekkel és hozzájuk kapcsolódó szolgáltatásokkal, majd telepítésükkel és alapvető beállításaikkal. Ám mindez csak arra elég, hogy egy teszt rendszeren bemutatható legyen a dolog, valós üzemeltetési tapasztalatot csak éles környezetben lehet szerezni, így mi – vélhetően elsőként – éles üzembe állítottuk az új appliance megoldást.
A következőkben, az élesbe állítás lépeseit fogom bemutatni – a hozzá szükséges egyéb kiegészítésekkel és beállításokkal együtt. Majd – hozzászólások formájában – a használata és üzemeltetése közben szerzett tapasztalataimat fogom megosztani itt.
Mielőtt nekiesnénk az új vCenter Server telepítésünknek, néhány fontos dolgot tisztázni kell:
Az itt leírtak megértéséhez és alkalmazásához a VCP szintű VMware ismeretek mellett a SUSE Linux rendszergazda szintű ismerete is elengedhetetlen.
Ami persze relatív, de mindenképp említésre érdemes különbségek a ‘megszokott’ windows alapú vCenterhez képest:
Ha használjuk az AutoDeploy-t, nem is lesz rá szükségünk többé!
Nem tudom ezt ki használta, és mire…. de szerintem a gyakorlatban használhatatlan. Semmi olyat nem nyújt számunkra, amire valóban szükségünk lenne. Amit elvártunk volna tőle, azt meg nem tudja…
Ezt nem tudom ki találta ki, és főleg minek? HA windows-on? Köszönjük, nem kértük eddig sem.
Ez szintén a vSphere 5.0-ban jelent meg, senki nem használta még élesben, nekünk nem is hiányzik, van rendes storage-ünk :)
A Windows-tól és az MS termékektől igyekszünk szabadulni, így ez annyira nem fáj. – De véleményem szerint egy MySQL is bőven elegendő lenne a feladatra. Kis és közepes (magyarországon csak ilyen van) környezetek esetében pedig megfelelő lehet a beépített DB2 is.
Ez azonban már kicsit fájhat, hiszen újra kell telepíteni a teljes virtuális infrastruktúrát. Emiatt sokkal körültekintőbben kell eljárni, és előre megtervezni az átállás folyamatát. Teljesen új projekt esetén persze ez megint nem hátrány…
Hacsak nem egy szigetet tervezünk építeni a semmi közepére, akkor szükségünk van a meglévő hálózatok konkrét topológiájának teljes ismeretére – Ennek hiányában akár a meglévő hálózat teljes összeomlását is okozhatjuk – amiért nem fognak megdícsérni.
Egy virtuális környezet megfelelően biztonságos tervezése külön feladat, erre nem is térnék ki most, addig is, javaslom az egyik korábbi VMUG-on tartott előadásom anyagát: vSphere-Hardening
A részletes és előzetes tervezés elengedhetetlen egy sikeres projekthez! Ha nem áll rendelkezésünkre saját, megfelelő hozzáértéssel (vmware, hálózat, security) rendelkező csapat, kérje külsős szakemberek segítségét, megéri! Egy ilyen átállás/migráció könnyen kudarcba fulladhat, ha az előzetes tervezést elhanyagoljuk. A tipikus tervezési hiányosságok pedig általában csak később bukkannak elő, amikor már valóban élesben üzemel a virtuális környezetünk. Legtöbb ilyen esetben az utólagos tervezés, és az ennek megfelelő átalakítások sokkal több pénzbe, időbe, és az éles környezet leállásába kerülnek!
Kelleni fog egy IP az új vCenter számára, amit az eddig megszokott elérhetőségeken felül a :22 és a :5480 portokon kell majd az adminisztrátoroknak elérni.
Hasznos dolog előre előkészíteni az új gép DNS bejegyzését is, főleg ha ez nem a mi hatáskörünkbe tartozik…
Az Auto Deploy működéséhez szükség lesz arra, hogy az ESX-ek dhcp segítségével kapjanak IP-t, és néhány speciális beállítást. Külső dhcp szerver használata esetén, azt külön fel kell erre készíteni, az appliance saját dhcp szerverének használata esetén ügyelni arra, hogy ez ne okozzon problémát a hálózat többi gépe számára.
A telepítés során minden SSL-es kapcsolat egy self-signed tanúsítványt kapott, ami miatt a hozzáféréskor ‘SSL warning’-ot kapunk. Ezt sajnálatos módon legtöbben csak ‘ignorálják’, vagy jobb esetben felveszik elfogadott tanúsítványok közé. Az igazi megoldás azonban ezek cseréje, hivatalos – de legalábbis számunkra elfogadott – kiadótól származó tanúsítványokra.
Az appliance telepítése egyszerű, annak alapvető lépései megtalálhatóak itt: vCenter Server Appliance így azt ott leírtakat már nem ismétlem…
Az következőkben azokat a beállításokat, és extra teendőket részletezem, amik éles üzemhez szerintem elengedhetetlenek.
Jelen esetben a beépített DB2 adatbázist használjuk, amit a management felületen aktiválhatunk.
A jelenlegi legfrissebb verzió még tartalmaz egy hibát, ennek javítását már most tegyük meg, még mielőtt probléma lenne belőle.
Lássuk, milyen aktív felhasználóik léteznek a rendszeren:
vcenter:~ # for user in `grep -v "\:\(*\|\!\)\:" /etc/shadow |cut -d: -f1`; do grep $user /etc/passwd ; done root:x:0:0:root:/root:/bin/bash dasusr1:x:1001:108::/opt/db2/home//dasusr1:/bin/false db2inst1:x:1002:109::/opt/db2/home//db2inst1:/bin/bash db2fenc1:x:1003:110::/opt/db2/home//db2fenc1:/bin/false vc:x:1004:100::/opt/db2/home//vc:/bin/false
Az eredményben látható felhasználóknak – számunkra legalábbis – ismeretlen a jelszava, ezek közül is kivastagítottam azokat, akiknek shell-jük is van. A root ugye mi vagyunk, ennek a jelszavát kapásból cseréljük is le!
Az imént fény derült rá, hogy vannak felhasználók akik nem a mi kezelésünk alatt állnak, így vegyük elejét a default jelszavak kihasználási lehetőségeinek, és tiltsuk le a jelszavas bejelentkezés lehetőségét! Ehhez először vegyük fel az ssh kulcsunkat a következő – még nem létező – állományba:
vcenter:~ # vim .ssh/authorized_keys
Majd, kapcsoljuk ki a jelszavas bejelentkezés lehetőségét, amit a : /etc/ssh/sshd_config állományban a következő sorral tehetünk meg:
PasswordAuthentication no
És indítsuk újra az érintett szolgáltatást:
vcenter:~ # service sshd restart
Ezek után nagyon hasznos, ha egy új belépéssel teszteljük is a beállítás sikerességét, még mielőtt kilépünk a jelenlegi session-ből…
A VMware hivatalosan nem támogatja az ipv6-ot, ám az appliance alapjául szolgáló linux igen, így ha nem teszünk ellene, akkor minden szolgáltatás figyelni fog ipv6-on is, és akár tudtunk és beleegyezésünk nélkül még IP címet is felvehet a gépünk – éljen az ipv6!
Ezt, és az ebből következő esetleges problémákat megelőzendő, kikapcsoltam az ipv6 támogatást, ám ez esetben egy csomó szolgáltatás el sem indult – így ez nem jó megoldás, marad a szigorú csomagszűrő.
Alapból nincs csomagszűrő a gépen, ami netstat kimenetét nézve eléggé merész dolog, éles üzembe állítani csomagszűrő nélkül elég nagy hiba lenne – főleg, ha az ajánlásaink ellenére nincs külön fizikailag szeparált management zóna kialakítva a vCenter és az ESX-ek management portjai számára.
Hogy ki milyen módszerrel varázsol csomagszűrőt, az mellékes, de valami ilyesmit kellene elérni:
vcenter:~ # ip6tables -L -n -v Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all lo * ::/0 ::/0 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 4 prefix `D:INPUT ' Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 LOG all * * ::/0 ::/0 LOG flags 0 level 4 prefix `D:FORWARD ' Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
vcenter:~ # iptables -L -n Chain INPUT (policy DROP) target prot opt source destination REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 reject-with icmp-port-unreachable ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:5480 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:514 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:514 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:902 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:6500 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:6502 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `D:LOdmz ' DROP all -- 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy DROP) target prot opt source destination LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `D:FORWARD ' DROP all -- 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT) target prot opt source destination
Az alap telepítés esetén ki van kapcsolva az ntp szerviz, és a management felületről sem lehet ntp szervert felvenni, illetve a szolgáltatást elindítani, így használjuk a yast2 konfig szerkesztő izét – amit személy szerint nagyon utálok, de mivel az összes konfig ezzel készült, így mégis ezt használom, nehogy a következő rendszerfrissítésnél probléma legyen belőle.
Na, itt van a legnagyobb káosz. Számomra teljesen érthetetlen módon, totálisan bénán van konfigurálva a log forgatás, aminek következtében egy éles rendszeren rengeteg log állomány keletkezik, össze vissza forgatva. Véleményem szerint, az összes logot a következők szerint érdemes forgatni:
daily rotate 365 create dateext compress delaycompress
A fentieket beállítottam a /etc/logrotate.conf-ban, majd a /etc/logrotate.d/ könyvtár alatt az összes állományból kigyomláltam azokat a sorokat amik a fentieknek ellentmondó volt…
Így, remélhetőleg egységes, és áttekinthető logokat kapunk…
Egy éles gépet felügyelni kell, hogy az adminisztrátorok időben értesüljenek az esetleges hibákról vagy rendellenességekről. Mi erre Munin-t és Nagios-t használunk, saját kibővített szenzorokkal…
Mindezektől függetlenül, mindenképp hasznos dolog a root felhasználó postaládáját egy létező, és általunk olvasott postafiókra továbbítani. Ezt legegyszerűbben az /etc/aliases állományban tehetjük meg.
Éles üzemben érdemes hivatalos tanúsítványokat használni, amit beszerezhetünk publikus tanúsítvány kiadóktól vagy, ha cégünk rendelkezik belső PKI rendszerrel, akkor egy céges tanúsítvány is megfelel. Mindössze egyetlen tanúsítványra lesz szükségünk arra a névre kiállítva, amivel majd a böngészőkből és vSphere kliensből el szeretnénk érni…
Lássuk, pontosan milyen szolgáltatásokhoz is kell SSL tanúsítvány:
Ez a standard https port, azonban a vcenter esetében nem csak egy egyszerű webszerver figyel itt, hiszen tulajdonképpen ide csatlakozunk a vSphere klienssel is. Az appliance esetén a következő állományokban találhatóak a tanúsítványok:
/etc/vmware-vpx/ssl/rui.crt /etc/vmware-vpx/ssl/rui.key /etc/vmware-vpx/ssl/rui.pfx
Ezek közül, a .crt, és a .key nem szorul különösebb magyarázatra, azonban a .pfx igen, ugyanis ezt a következő paranccsal kell létrehoznunk:
openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx
Igen, a jelszónak is PONTOSAN így kell kinézni – gondolom, valahol jól bele van drótozva az alkalmazásba…
Hogy használja is a rendszer az új tanúsítványokat, ezeket be is kell tölteni. A hivatalos dokumentáció szerint, nem is mindegy hogy hogyan!
Persze, ez a windows-os verzióról beszél, értelem szerűen kisebb módosításokkal, de követni kell a leírást, majd a végén újraindítani az érintett szolgáltatásokat:
service vmware-vpxd restart
Ezen a porton érhető el az adminisztrációs felület. Ezt egy igen egyszerű webszerver szolgálja ki, a lighthttpd. Ez alatt a tanúsítványt a következő paranccsal cserélhetjük ki:
cat rui.key rui.crt >/opt/vmware/etc/lighttpd/server.pem
Majd indítsuk újra az érintett szolgáltatást:
service vami-lighttp restart
Természetesen, jogos igény lenne, hogy tovább szigorítsuk a szolgáltatáshoz való hozzáférést, hogy csak a megfelelő kliens tanúsítvánnyal rendelkezőket engedjük kapcsolódni… Ennek beállításához a következőkre lenne szükség:
#### SSL engine ssl.engine = "enable" ssl.pemfile = "/opt/vmware/etc/lighttpd/server.pem" ssl.ca-file = "/opt/vmware/etc/lighttpd/CA.pem" ssl.verifyclient.activate = "enable" ssl.verifyclient.enforce = "enable"
Ám ez a verzió – amit várhatóan a VMware saját maga fordított – ezt valamiért mégsem támogatja :(
vcenter:~ # service vami-lighttp restart Shutting down vami-lighttpd: done. Starting vami-lighttpd: done. 2011-12-01 12:17:03: (/build/mts/release/bora-471789/vadk/src/vami/apps/lighttpd/1.5.0-2349/src/server.c.1485) WARNING: unknown config-key: ssl.verifyclient.activate (ignored) 2011-12-01 12:17:03: (/build/mts/release/bora-471789/vadk/src/vami/apps/lighttpd/1.5.0-2349/src/server.c.1485) WARNING: unknown config-key: ssl.verifyclient.enforce (ignored)
Itt lenne elérhető a web client – ám ezt éles környezetben használni igen nagy bátorság. Az előző cikkből kiderülhetett hogy ez egy flash izé, az ígéretekhez képest nagyon kevés implementált fícsörrel. Most még jobban megvizsgálva, az egész egy nagy java-s katyvasz, gyanúsan féligkész megoldások halmazával, amiknél a tanúsítvány cserét sem sikerült végeznem egyelőre… Legjobb, ha csomagszűrőből tiltjuk ehhez a porthoz való hozzáférést!
Mivel ez egy virtuális gép, így mentését megoldhatjuk ugyan úgy, ahogy a többi VM-et is mentjük :)
Persze, sokkal szofisztikáltabb módszereket is alkalmazhatunk, aminek lényege hogy egy default install után a mentéstben szereplő állományokat visszatöltve ismét megkapjuk a jelenlegi, működő allapotot.
Ehhez menteni kell a következőket:
Ez egylőre fekete bárány, mivel eddig nem üzemeltettünk DB2 adatbázist, így menteni sem nagyon tudom hogyan kellene – a cél hogy az adatbázis visszaállítható legyebn :)
Ezeknél egyszerűbb a dolgunk, hiszen csak azokat az állományokat kell menteni, amiken változtattunk…
Maga a migráció – egy éles környezet estén – a legkritikusabb fázis, ugyanis általában a cél az, hogy a lehető legkisebb leállása vigyük át a virtuális gépeket az új környezetbe. Sokszor az új környezet tulajdonképpen a meglővő vCenter és ESX-ek cseréjét jelenti, így visszaállásra nnics – vagy csak rengeteg munka árán van – lehetőség. Így ehhez a műveletethez mindenképp javasolt hozzáértő szakemberek segítségét kérni.
A feladat összetettsége – és a lehetséges kiinduló állapotok sokfélesége miatt – ehhez konkrét leírást adni nem lehet. Irányadónak a hivatalos dokomentációt javaslom.
Ez egyelőre kényes – és ráadásul ismeretlen terület, mert jelenleg nincs elérhető frissítés. Ám, amint lesz, különösen oda kell arra figyelni, hogy mi lesz a sorsa az általunk kézzel módosított állományoknak!
Ahogy az elején is felhívtam erre a figyelmet, az itt leírtak megvalósításához komoly szakértelem kell. Könnyen előfordulhat, hogy valami mégsem úgy működik ahogy leírtam, így csak akkor áljon neki bárki ilyen szintű módosításoknak, ha probléma esetén egyedül is elboldogul. Hivatalos supportot ilyen szintű módosítások után kizárt hogy bárki is nyújtson egy ilyen rendszerre.
Tehát, bármilyen módosítást mindeki csak SAJÁT FELELŐSSÉGRE végezzen!
Egyik előző cikkemben, a vSphere 5.0-ban megjelent Auto Deploy lehetőségeit, és alapvető beállításait mutattam be, és csak utaltam arra, hogy az Image Builder segítségével a gyakorlatban nagyon hatékonyan hozhatunk létre saját ESX profilokat.
Éppen ezért, folytatásként az Image Builder-ben rejlő hatalmas lehetőségeket fogom részletesen bemutatni.
Igen nagyon fájó pont, hogy az egész Image Builder-t egyelőre kizárólag Windows alól lehet birizgálni, ami eléggé kiábrándító egy Linux alapú appliance megoldás esetén…
Szóval, kerítsünk egy PowerCLI-vel felvértezett windows-t, és csatlakozzunk az vCenter Server-hez:
PowerCLI C:\> Connect-VIServer -server 192.168.201.50
Majd, nézzük meg milyen Profile-ok állnak a rendelkezésünkre:
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
Ha az előző cikkben leírtak alapján jártunk el, akkor a fenti kimenetet kapjuk.
Lássuk, melyik oszlop mit is jelent számunkra:
Ez ugye nem kíván túl sok magyarázatot. Fontos azonban, hogy egyedi nevet adjunk a leendő saját profiloknak, és praktikus ha benne van a kiinduló ESX csomag pontos verziója, és a patch level is.
Cégünk nevét írhatjuk ide, nem árt ha tudják a későbbi felhasználói kiket kell szidni, ha valami nem okés vele kapcsolatban ;)
Magáért beszél…
Ez egy igen fontos paraméter, ugyanis ezzel határozhatjuk meg, hogy kitől származó csomagokat (VIB’s) pakolhatunk bele. A lehetséges értékei megbízhatósági sorrendben: VMwareCertified, VMwareAccepted, PartnerSupported, and CommunitySupported
A fentiek ismeretében, hozzunk létre egy másolatot az egyik meglévő profile-ból, amit később majd jól testre szabunk az igényeinknek megfelelően:
PowerCLI C:\> New-EsxImageProfile -CloneProfile ESXi-5.0.0-469512-standard -Name "ESXi-5.0.0-469512-v" -Vendor "Andrews Kft." -Description "Image Profile optimized for virtual ESX servers"
És Íme az eredmény:
PowerCLI C:\> Get-EsxImageProfile Name Vendor Last Modified Acceptance Level ---- ------ ------------- ---------------- ESXi-5.0.0-469512-no-tools VMware, Inc. 2011.08.19. ... PartnerSupported ESXi-5.0.0-469512-standard VMware, Inc. 2011.08.19. ... PartnerSupported ESXi-5.0.0-469512-v Andrews Kft. 2011.08.19. ... PartnerSupported
Innentől, neki is állhatunk „testre szabni”. Ezzel azonban csak óvatosan, ugyanis igen könnyen elérhetjük, hogy az adott profile használhatatlan legyen. Éles környezetben használt profile-et SOHA ne piszkáljunk!
De mit is értünk a ‘testreszabás’ alatt? Egy-egy ilyen profile, különböző csomagok együttese, aminek a végeredménye – jó esetben – egy bootolható ESX image.
Lássuk, milyen csomagokból áll a gyári profile:
PowerCLI C:\> Get-EsxSoftwarePackage Name Version Vendor Release Date ---- ------- ------ ------------ net-ixgbe 2.0.84.8.2-10vmw.500.0.0.46... VMware 2011.08.19. 1... ata-pata-hpt3x2n 0.3.4-3vmw.500.0.0.469512 VMware 2011.08.19. 1... ehci-ehci-hcd 1.0-3vmw.500.0.0.469512 VMware 2011.08.19. 1... ata-pata-atiixp 0.4.6-3vmw.500.0.0.469512 VMware 2011.08.19. 1... scsi-megaraid2 2.00.4-9vmw.500.0.0.469512 VMware 2011.08.19. 1... scsi-aic79xx 3.1-5vmw.500.0.0.469512 VMware 2011.08.19. 1... net-r8168 8.013.00-3vmw.500.0.0.469512 VMware 2011.08.19. 1... ohci-usb-ohci 1.0-3vmw.500.0.0.469512 VMware 2011.08.19. 1... scsi-qla4xxx 5.01.03.2-3vmw.500.0.0.469512 VMware 2011.08.19. 1... ata-pata-sil680 0.4.8-3vmw.500.0.0.469512 VMware 2011.08.19. 1... scsi-megaraid-sas 4.32-1vmw.500.0.0.469512 VMware 2011.08.19. 1... uhci-usb-uhci 1.0-3vmw.500.0.0.469512 VMware 2011.08.19. 1... ata-pata-amd 0.3.10-3vmw.500.0.0.469512 VMware 2011.08.19. 1... net-bnx2 2.0.15g.v50.11-5vmw.500.0.0... VMware 2011.08.19. 1...
A fenti lista (ami persze nem teljes) az összes rendelkezésre álló depot-ban található, összes csomagot (VIB) tartalmazza! – Számomra érthetetlen okokból egy konkrét profile-ban található csomagokat egyelőre nem lehet kilistázni :o
Összehasonlíani viszont lehet:
PowerCLI C:\> Compare-EsxImageProfile -ReferenceProfile ESXi-5.0.0-469512-standard -ComparisonProfile ESXi-5.0.0-469512-no-tools Equal : False PackagesEqual : False RefAcceptanceLevel : PartnerSupported CompAcceptanceLevel : PartnerSupported OnlyInRef : {VMware_locker_tools-light_5.0.0-0.0.469512} OnlyInComp : {} UpgradeFromRef : {} DowngradeFromRef : {}
Aki a Linux/Unix parancssorhoz szokott szokott – mint én – az kicsit meglepődik a kimenet gagyiságán ;) De persze mit vártam? Az egész PowerCLI egy vicc, néha már-már sírva fakadtam használata közben :O
Ám, ha ezen valahogy túltesszük magunkat, akkor megtalálhatjuk hogy a két profile egyetlen csomagban (VMware_locker_tools-light_5.0.0-0.0.469512) tér el egymástól – ahogy az várható is volt…
Persze, a csomag neve is zanzásítva van, a listában ezt így találjuk meg: ‘tools-light‘ – Ezúton is csókoltatom a kedves fejlesztőket :P
Innentől viszont, már szinte minden egyértelmű, szabjuk hát saját igényeinkhez az újonnan létrehozott profile-unkat!
Ehhez persze csomag is kell, amiket általában a hardvergyártók bocsájtanak rendelkezésünkre, és tartalmuk ennek megfelelően driver vagy kiegészítő szoftver a saját hardvereikhez. Tehát, amit tőlük kapunk az egy kupac szoftver (depot) amit először hozzá kell adnunk az Image Builderhez, csak úgy mint a VMware által adott alap csomagot:
PowerCLI C:\> Add-EsxSoftwareDepot <csomagnév>.zip
Majd, a benne lévő VIB-ek közül, adjuk hozzá a nekünk szükségeset a profilunkhoz:
PowerCLI C:\> Add-EsxSoftwarePackage –ImageProfile ESXi-5.0.0-469512-v -SoftwarePackage <csomagnév>
Na, ilyenkor hiányzik igazán az a parancs, amiből megtudhatnánk, hogy mit is tartalmaz a profil tulajdonképp – de ha valahogy kitaláltuk, akkor törölhetünk közűlük ;)
PowerCLI C:\> Remove-EsxSoftwarePackage -ImageProfile ESXi-5.0.0-469512-v -SoftwarePackage <csomagnév>
Ha jól megnézzük, egy adott hardver használata esetén rengeteg számunkra teljesen felesleges csomag törölhető! Így, sokkal kisebb lesz a végső image mérete, aminek következtében kevesebb memóriát pazarol, gyorsabban bootol, és kevesebbszer kell frissíteni – hiszen, biztosan nem lesz minden frissítésnél érintett az a maradék pár csomag, ami az adott hardverhez kell…
Az így elkészült, saját igényeinkhez igazított telepítőkészlet többféle formában használható fel
Vagyis a profilt Auto Deploy profilként használjuk, ehhez persze előbb hozzá kell rendelni az Auto Deploy szerverben – különböző szabályok alapján – az ESX szervereink egy részéhez. Lásd később…
Figyelem! – A profile ezen formája csak az aktuális PowerCLI session-ben létezik. Tehát, ha kilépünk, többé már nem használhatjuk, hacsak nem exportáljuk .zip formába!
Ha saját profilt készítettünk, és később is szeretnénk még használni, mindenképp exportáljuk .zip formába! Persze, az is lehet cél, hogy ezt a remek új csomagot terjeszthetővé tegyük – például ügyfeleink számára. Ehhez nincs más teendőnk, mint kiexportálni .zip formátumba a következő parancs segítségével:
PowerCLI C:\> Export-EsxImageProfile –ImageProfile ESXi-5.0.0-469512-v –FilePath D:\VMware\depots\Andrews-ESXi-5.0.0-469512-v.zip –ExportToBundle
Hasznos lehet néha, ha telepítőmédiát (CD/DVD) is tudunk készíteni a profilunkból:
PowerCLI C:\> Export-EsxImageProfile –ImageProfile ESXi-5.0.0-469512-v –FilePath D:\VMware\depots\Andrews-ESXi-5.0.0-469512-v.iso –ExportToIso
Az elkészült ESX profilakat ezek után, különbözős szabályoka alapján rendelhetjük a megfelelő ESX csoporthoz. A legegyszerűbb szabály, ami minden ESX-re érvényes:
PowerCLI C:\> New-DeployRule -Name "Initial ESXi5" -Item "ESXi-5.0.0-469512-standard" -AllHosts
Ezt azonban lehet tovább finomítani, hiszen nem biztos, hogy minden ESX-re ugyan azt az image-et szeretnénk bootolni: Ezesetben, az ‘-AllHosts‘ paramétert a ‘-Pattern’ -re kell cserélni, és megadni az ESX-ek azonosításához szüksége paramétereket…
Igen ám, de mik is lehetnek ezek a paraméterek?
Ez sajnos egyelőre nincs túldokumentálva, a legbiztosabb, ha direkt olyan rule-t hozunk létre (vagy egyátalán nem hozunk létre) ami nem illeszkedik az érintett ESX-re, és akkor a boot során hibaüzenetet kapunk, ahol az adott hardverre érvényes összes paramétert felsorolja:
Ezek valahol a logokban is meg kellene hogy jelenjenek, ám én sehol sem találtam ezeket…
Hasznos dolog még, hogy vCenter szabályokat is lehet megadni a ‘-Item‘ kapcsolóval. Ennek hatására a frissen bootolt gép, automatikusan bekerülhet a megadott vCenter objektumba, amik a következők lehetnek:
Ezeket a szabályokat aztán, hozzá is kell adni az aktív szabályokhoz:
PowerCLI C:\> Add-DeployRule -DeployRule "Initial ESXi5"
Mivel egy ESX-re akár több szabály is illeszkedhet, fontos hogy egyféle objektum típus hozzárendelésből csak egy lesz érvényes! – Tehát, ha ugyan azt a host-ot két különböző clusterhez is hozzáadná két rá illeszkedő szabály, csak a magasabb prioritású lesz érvényes, több különböző típusú objektumba helyezés esetén viszont mindegyik érvényesül!
A szabályok prioritását az -At <prioritás> kapcsolóval szabályozhatjuk, ahol a kisebb érték jelenti a magasabb prioritást. – Szintén kezdeti hiányosság, hogy a listázásnál ezt egyáltalán nem mutatja :o
A fenti parancsok teljes dokumentációja természetesen megtalálható a VMware oldalain. Ennek tanulmányozását ajánlom mindekinek.
Ezekkel a lehetőségekkel rendkívül rugalmas, és könnyen kezelhető virtuális környezetet hozhatunk létre. Természetesen, ezen megoldások nagy része még igencsak gyerekcipőben jár – még akkor is ha a marketingesek az érintett termékek eladásakor nem így nyilatkoztak – ezt, többek között a hiányos parancsok, a PowerCLI-hez való értelmetlen ragaszkodás, és az appliance szervizeinek debug szintű logolása is bizonyítja
Azonban, mindez agyon ígéretes, érdemes vele foglalkozni! Főleg, nagy számú ESX-et tartalmazó virtuális környezetek esetében :)
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?
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:
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:
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:
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:
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:
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 ;)
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:
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:
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é:
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…
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.
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.
Egy appliance megoldástól alapvető követelmény, a szoftverelemek frissítésének lehetősége:
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.
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.
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 ;)
Ú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 ;)
A szokásos, eddig is meglővő parancssoros ‘kezelőfelületek’, melyből több verzió is létezik:
Windows-os rendszergazdák szerethetik – használható parancssr Windowsra ;)
Linux, és egyép Perl-t futtatni képes Operációs rendszerek számára nyújt kényelmesen használható management parancsokat.
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 :)
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…
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:
Ezzel túl sok teendőnk nem akad, ám az ipv6 támogatás kikapcsolás javasolt.
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.
Jelszavak helyett kulcs alapú bejelentkezés javasolt, ennek megfelelően a password auth tiltása is.
Ha szükségünk van a levelezés állítgatására, akor megtehetjük – ha értünk a sendmailhez ;)
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…
A syslog-hoz van egy alap konfigja, de ha valóban biztonságos loggyűjtést szeretnénk, akkor ezen is állítgatni kell…
Aki ért hozzá, annak javasolt átnézni, és optimalizálni a beállításait.
Szintén hozzáértők állíthatják a saját igényeiknek megfelelőre…
Ezzel valójában nem nagyon tudunk mit kezdeni – de ha baj van velük, lehet kill-elni legalább ;)
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:
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…
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:
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ó!
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…
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…
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)
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.
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.
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.
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…
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 elemek, többek között:
Újabb guest operációs rendszer támogatás: OS X Server 10.6 (Snow Leopard)
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…
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.
Újabb verziójú VMFS filerendszer…
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.
Ú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.
Új, virtuális gépenkénti sávszélesség szabályzás lehetősége, a további finomhangolás érdekében.
Ú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
Új HA architektúra, az egyszerűbb konfiguráció és a jobb skálázhatóság érdekében. – meglátjuk.
Már nagyobb késleltetésű hálózatokon is stabilan működő VMotion.
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.
Akár 4x nagyobb teljesítményű virtuális gépek használata is lehetséges, maximum:
A gyakorlatban eddig soha nem ütköztem ilyen korlátba, ezzel biztosították hogy a jövöben sem fogunk – egy darabig ;)
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…
Linux alapú vCenter Appiance megoldás – végre :)
A témáról külön post is született…