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
- Az ESXi szerverek PXE boot segítségével, először is egy IP címet kell hogy kapjanak egy DHCP szervertől
- 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.
- 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.
- 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.
- 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.
- Rátölti a neki való host profile-t
- 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!