A blogban leírtak a szerzők saját véleménye, és nem a munkáltatójuké.
|
Egy nyomozás története következik.
Mint azt jónéhányan már látták (és sajnos néhányan önhibájukon kívül jól meg is járták 🙁 ) az IE224 labor teljesen új Ubuntu alapú rendszert kapott. Erről majd ha nagyon ráérek (famous last words…) írok egy részletesebb leírást is. Ez a rendszer most egy kellemes kis rejtvényfeladványt csinált nekem. Lássuk röviden a szereplőket:
- Labpc17. Róla annyit kell tudni, hogy rossz helyen volt rossz időben, rajta volt egy virtuális gép, amit szét kellett volna dobni az összes többi laborgépre.
- Shelob. Gonosz fekete pók, ami majdnem megette Frodót és most behálózta az összes laborgépet. Gyakorlatilag minden hálózati szolgáltatás a laborban erről jön. A mostani eset szempontjából annyi érdekes, hogy innen lehet lokálisan tárolt fájlokat szétmásolni a gépekre. CentOS fut rajta.
- Aragorn. A hibatűrő kutatócsoport “mindentvívő” gépe. Tényleg minden lényeges virtuális gépet ez visz a hátán, ez ugyanis egy ESX server. A Shelobot is hátán viszi… mert ugyanis az virtuális. (Ezt így szó szerint vizualizálni csak horror rajongóknak javaslom 🙂 )
- Idril. Ez adja iSCSI-n a tárhelyet az Aragorn (és még egy rakás másik) gép alá, az éles virtuális gépeink minden tárhelye fizikailag itt helyezkedik el. Egy raid-5 tömb van LVM-mel kötetekre bontva, ezt szolgálja ki az iscsi enterprise target. Mindez CentOS felett.
Egy szép komplikált rendszer kezd körvonalazódni. Igazából egy nagy IT infrastruktúra is jellemzően pont ennyi rétegből, hasonló struktúrával épül fel, csak minden elemből sokkal több darab van. Meg persze az egyes elemek kicsit nagyobbak és többe is kerülnek.
De bevezetőből ennyi elég is most. Nem akartam semmi különösen bonyolultat ettől a rendszertől, egyszerűen egy pár fájlt scp-vel felmásolni a labpc17-ről a Shelobra. Gigabites a hálózat végig, erős a gép a kapcsolat mindkét végen, 30-40 MB/s-et szokott tudni scp-vel másolva. Na ebből most nekem lett 200-300 kB/s. Ennél még az ADSL is gyorsabb. Mivel nem akartam az ítéletnapig tartó másolás közben unatkozni (jó pár óra lett volna ezzel a tempóval), ezért inkább azzal töltöttem az időt, hogy megpróbáltam rájönni, hogy mégis miért csinálja ezt és hogy lehet megjavítani.
laboradmin@labpc17:/media/vmware-images/oktatas$ scp -r TestImage/ xmi@shelob:/srv/nfs/imagestore/oktatas/
xmi@shelob's password:
Windows XP Professional SP3-cl1-000001-cl1.vmdk 100% 766 0.8KB/s 00:00
Windows XP Professional SP3-cl1-000001-cl1-000002-s003.vmdk 100% 320KB 320.0KB/s 00:00
vmware.log 100% 76KB 75.5KB/s 00:00
LaborXP.vmx 100% 1554 1.5KB/s 00:00
Windows XP Professional SP3-cl1-000001-cl1-000002.vmdk 100% 644 0.6KB/s 00:00
LaborXP-Snapshot5.vmsn 100% 26KB 26.4KB/s 00:00
vmware-1.log 100% 58KB 58.1KB/s 00:00
Windows XP Professional SP3-cl1-000001-cl1-s001.vmdk 70% 1338MB 307.9KB/s 31:34 ETA
Azt hiszem elég egyértelmű, nem kell ehhez sok magyarázat. Elsőre mit próbál ki a tanácstalan ember? Nézzük meg top-pal a gépeket. A kliens labpc kimenetét külön nem másoltam be ide, de azt hiszen nem nehéz elhinni, hogy ott semmi terhelés nem látszott. 300kB/s-el scp-zni egy 486-osnak is megy, nem hogy egy Core2 E6400-nak. Nézzük inkább a másik végét, a Shelobot, kizárásos alapon ott kell lennie a bajnak:
top - 16:20:58 up 12 days, 21:09, 2 users, load average: 1.57, 1.08, 0.52
Tasks: 150 total, 2 running, 148 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.8%us, 0.7%sy, 0.0%ni, 96.2%id, 1.8%wa, 0.1%hi, 0.3%si, 0.0%st
Mem: 3115860k total, 2616856k used, 499004k free, 418524k buffers
Swap: 0k total, 0k used, 0k free, 2011980k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20097 xmi 25 0 6496 1436 1124 R 6.0 0.0 4:35.69 scp
20096 xmi 15 0 14180 5944 1108 S 1.0 0.2 0:49.87 sshd
354 root 17 -5 0 0 0 S 0.1 0.0 5:58.81 kjournald
1 root 15 0 2064 624 536 S 0.0 0.0 0:02.27 init
2 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/0
Kiemeltem a lényeget, így máris rögtön látható, hogy… nem látható semmi. Gyakorlatilag üresjáratban van a gép. Némi gyanakvással töltött el azért a magas load average. Mégis mitől? Ha egyszer még az iowait is csak 1,8%. Pedig a diszk I/O-ra gyanakodtam. Biztos, ami biztos lássunk egy iostat kimenetet, ha többféle mérési eredmény van az sosem árt:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 6.67 0.00 26.67 0.00 8.00 0.01 2.00 2.00 1.33
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 200.00 0.00 800.00 8.00 0.22 1.11 0.06 1.11
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
[...]
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 40046.15 0.00 461.54 0.00 162030.77 702.13 1.12 2.42 0.48 22.31
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Szép sorminta, felülről lefelé minden sor egy 2 másodpercenkénti mintavétel. Annyit még elárulok, hogy kicsit csaltam, hogy ilyen szép legyen a kiírás, a következő parancsot adtam ki:
iostat -d -x -k 2 | grep 'sdb'
Az sdb az a diszk, amire másolok scp-vel, tehát itt sok írás műveletet kellene látni. Ehhez képest elég ritkásan történik bármi is. Persze jogos, hiszen a lassan csordogáló adat a write bufferben állomásozik, míg össze nem gyűlik elég (vagy le nem telik a beállított maximális idő) ahhoz, hogy érdemes legyen kiírni. Miket mutat az iostat:
- rrqm/s, wrqm/s – összevont olvasás és írás műveletek száma (átlagolva a legutóbbi 2 sec-es intervallumban)
- r/s, w/s – nyers olvasás és írás műveletek száma átlagolva
- rkB/s, wkB/s – na vajon mi lehet… adat áteresztő képesség olvasás és írás esetén
- avgrq-sz – egy művelet során átlagosan megmozgatott adatmennyiség
- avgqu-sz – a várakozási sor átlagos hossza
- await – átlagos várakozási ideje egy műveletnek, beleértve a sorban állási időt is
- svctm – a kérések kiszolgálási ideje az eszközben, sorban állási időt nem számítva
- %util – az idő mekkora részében végzett az eszköz valami feladatot.
Az %util értékek alacsonyak, tehát bőven van üresjárati ideje. Viszont akkor miért nem csinálja gyorsabban? Mi az amire várni kell? És ha már itt tartunk az a 162MB/s-es írás 2 másodpercre vett átlagként teljesen hihetetlen. Az is érezhető, hogy a gép lassan válaszol, mintha erősen terhelve lenne, annak ellenére, hogy látszólag minden szempontból üresjáratban van.
Mivel itt nem igazán jutottam közelebb a probléma természetének megértéshez, csak annyit sikerült megállapítani, hogy – finoman szólva – inkonzisztensek az eredmények, ezért most egy kicsit lejjebb kell ásni. Mit mond az ESX szerver a virtuális gépről, kívülről nézve? Ezt a service console-on az esxtop segítségével nézhetjük meg. Az esxtop csak root felhasználóval működik. Nézzük rögtön a ‘d’ lenyomásával a diszk statisztikát:
4:24:16pm up 67 days 5:43, 109 worlds; CPU load average: 0.35, 0.35, 0.35
ADAPTR CID TID LID WID NCHNS NTGTS NLUNS NVMS AQLEN LQLEN WQLEN ACTV QUED %USD LOAD CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s
vmhba0 - - - - 1 3 3 23 512 0 0 - - - - 1.91 0.00 1.91 0.00 0.01
vmhba1 - - - - 1 0 0 0 512 0 0 - - - - 0.00 0.00 0.00 0.00 0.00
vmhba32 - - - - 1 2 2 50 4096 0 0 - - - - 90.71 82.65 8.05 0.32 0.06
Na itt most nem fogok teljes jelmagyarázatot adni, akit érdekel itt elolvashatja a teljes leírást az esxtop által mért értékekről. A lényeg, hogy a vmhba32 a mi eszközünk, ez a szoftveres iscsi initiatior. A sor végére figyelve láthatjuk, hogy kiadott parancsok túlnyomó többsége olvasás. Persze nem egyedül terheli a Shelob a gépet, fut még egy rakás másik virtuális gép is. A tisztánlátás végett tekintsük meg a virtuális gépre lebontott diszk IO-t a ‘v’ billentyű lenyomásával:
ID GID NAME DEVICE NWD NDV DQLEN WQLEN ACTV QUED %USD LOAD CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s
2 2 system - 3 - 0 0 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00
6 6 helper - 5 - 0 0 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00
9 9 console - 1 - 0 0 0 0 0 0.00 1.72 0.00 1.72 0.00 0.01
15 15 vmware-vmkauthd - 1 - 0 0 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00
20 20 Alnitak - 3 - 0 0 0 0 0 0.00 0.19 0.00 0.19 0.00 0.00
37 37 Gorbag - 3 - 0 0 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00
50 50 Shelob - 4 - 0 0 0 0 0 0.00 68.66 65.99 2.67 0.26 0.04
59 59 Uglug - 4 - 0 0 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00
67 67 TaddmImage - 3 - 0 0 0 0 0 0.00 1.14 0.00 1.14 0.00 0.02
78 78 PseudoSalvador - 3 - 0 0 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00
[...]
De bizony a Shelob csinálja az olvasást. A többi gép viszonylag nyugiban van, nem lehet rájuk fogni, hogy elzabrálnák az erőforrásokat. Ez roppant érdekes, mert a Shelobon belülről nézve a nem látszottak kiadott olvasás műveletek, ebben az elkapott mintavételben pedig kb. 30-szor annyi olvasás művelet látható, mint írás, de az adatmennyiségben is legalább hatszoros eltérés van. Nem a mintavételezés csal, ezek sajnos az átlagot teljesen jól reprezentáló értékek. Honnan jönnek azok olvasás kérések? A Shelob itt valójában nem egy atomi bejegyzés, hanem egy aggregált folyamat csoport a hypervisor felett, ami kibontható az ‘e’ billentyűvel és a megfelelő GID megadásával. Kibontva ezt látjuk:
ID GID NAME DEVICE NWD NDV DQLEN WQLEN ACTV QUED %USD LOAD CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s
1325 50 vmware-vmx - 4 1 0 32 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00
1326 50 vmm0:Shelob - 4 1 0 32 1 0 3 0.03 66.76 65.04 1.72 0.25 0.01
1328 50 mks:Shelob - 4 1 0 32 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00
1329 50 vcpu-0:Shelob - 4 1 0 32 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00
A vmm csinálja. Szerettem volna azt hinni, hogy közelebb kerültem a megoldáshoz, de más virtuális gépeket megnézve azt tapasztaltam, hogy minden diszk művelet csak és kizárólag a vmm alatt jelenik meg. Érdemes még megfigyelni WQLEN és ACTV értékeket, az előbbi a várakozási sor maximális hossza, az utóbbi a kihasznált hossza. A sorban nem várakoznak műveletek, mindig csak egy van benne. Hasonlóan, ahogy az iostat-nál láttuk, itt is van egy számított kihasználtsági százalékos érték: %USD. Itt is meglepően alacsony az érték, nem magyarázza meg, hogy miért nem gyorsabb a szerencsétlen guest gép.
A fentebbi diszk statisztika is kibontható folyamatokig, ekkor egy ilyen szép táblázat lesz az eredmény:
ADAPTR CID TID LID WID NCHNS NTGTS NLUNS NVMS CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s DAVG/cmd KAVG/cmd GAVG/cmd QAVG/cmd DAVG/rd KAVG/rd GAVG/rd QAVG/rd DAVG/wr KAVG/wr GAVG/wr QAVG/wr
vmhba0 - - - - 1 3 3 23 1.91 0.00 1.91 0.00 0.01 4.56 0.01 4.56 0.00 0.00 0.00 0.00 0.00 4.56 0.01 4.56 0.00
vmhba1 - - - - 1 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1024 0 0 0 1 0.76 0.00 0.76 0.00 0.00 0.18 0.01 0.20 0.00 0.00 0.00 0.00 0.00 0.18 0.01 0.20 0.00
vmhba32 0 0 0 1032 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1033 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1035 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1036 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1037 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1069 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1078 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1079 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1080 0 0 0 1 0.38 0.00 0.38 0.00 0.03 7.15 0.00 7.16 0.00 0.00 0.00 0.00 0.00 7.15 0.01 7.16 0.00
vmhba32 0 0 0 1083 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1116 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1228 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1229 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1232 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1303 0 0 0 1 0.19 0.00 0.19 0.00 0.00 0.93 0.02 0.94 0.01 0.00 0.00 0.00 0.00 0.93 0.02 0.94 0.01
vmhba32 0 0 0 1305 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1314 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1315 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1318 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1325 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1326 0 0 0 1 106.24 76.48 29.75 0.30 7.72 9.09 0.01 9.10 0.00 11.06 0.01 11.07 0.00 4.04 0.00 4.05 0.00
vmhba32 0 0 0 1328 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1329 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1390 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1391 0 0 0 1 0.57 0.00 0.57 0.00 0.00 0.30 0.01 0.32 0.00 0.00 0.00 0.00 0.00 0.30 0.01 0.32 0.00
vmhba32 0 0 0 1392 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1395 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1446 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1447 0 0 0 1 4.39 0.00 4.39 0.00 0.02 3.68 0.00 3.68 0.00 0.00 0.00 0.00 0.00 3.68 0.00 3.68 0.00
vmhba32 0 0 0 1450 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1451 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1452 0 0 0 1 0.76 0.38 0.38 0.00 0.02 20.46 0.01 20.47 0.00 10.62 0.01 10.63 0.00 30.30 0.01 30.31 0.01
vmhba32 0 0 0 1455 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1498 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1499 0 0 0 1 0.76 0.00 0.76 0.00 0.01 11.32 0.01 11.34 0.01 0.00 0.00 0.00 0.00 11.32 0.01 11.34 0.01
vmhba32 0 0 0 1502 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1513 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1514 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 0 0 1517 0 0 0 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
vmhba32 0 1 - - 1 1 1 10 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Gyönyörű, a teljes vizuális élmény érdekében nem szedtem ki a történet szempontjából lényegtelen sorokat. 🙂 Most más oszlopokat kapcsoltam be (‘f’ billentyű), a kiszolgálási időket akartam szemügyre venni. A lényeges sort a World ID alapján találhatjuk meg (ez a process ID megfelelője a VMware terminológiájában), az előző táblázatból lenézhető, hogy az 1326-os a számunkra érdekes. A fizikai eszköz olvasási kiszolgálási idejére az átlag érték 11ms, ami teljesen normális, az írás ennél is rövidebb. Ez sem ad magyarázatot.
Nincs más hátra be kell nézni az iSCSI szerverre is, indításnak mondjuk egy iostat-tal. Ez most nem idősor, hanem csak egy mintavétel az idősorból az összes eszköz felsorolásával:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 47.50 0.00 36.00 0.00 334.00 0.00 18.56 0.43 11.85 8.54 30.75
sdd 18.00 0.00 31.50 0.00 198.00 0.00 12.57 0.37 11.62 9.70 30.55
sde 8.50 0.00 19.00 0.00 110.00 0.00 11.58 0.19 9.97 9.74 18.50
sdf 15.50 0.00 30.00 0.00 182.00 0.00 12.13 0.27 8.90 8.53 25.60
md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md2 0.00 0.00 206.00 0.00 824.00 0.00 8.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-4 0.00 0.00 206.00 0.00 824.00 0.00 8.00 2.04 9.90 4.60 94.85
dm-5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Az sdc, sdd, sde, sdf fizikai merevlemezek adják az md2 raid tömböt, azt hiszem ez talán ki is található az eredményekből. A dm-4 az egyik logikai kötet, történetesen az, amin a Shelob virtuális diszkje is helyet kapott. Na itt már látni csúnya dolgokat. A jobb szélen a táblázatban a %util 94,8%, tehát gyakorlatilag telítésben van. Ehhez tartozik egy 824 kB/s-os olvasási áteresztőképesség, ami nagyon alacsony. Ez bizony trashel, nem is kicsit. Mindezt 2048-as readahead és bekapcsolt read és writeback cache mellett, deadline IO ütemezővel. Ezen már nem sok tuningolási lehetőség van… Itt egyértelműen az ESX szerver ad ki olyan kéréseket, amik kicsik, avqrq-sz mindössze 8.00 kB, tehát a readahead nem segít. Emellett rossz a lokalitásuk, tehát a cache nem segít. Ráadásul egyesével jönnek a kérések, mint ahogy azt már feljebb is láthattuk, itt is csak 2 körüli a várakozási sor hossza (avgqu-sz), tehát az IO ütemező teljesen tehetetlen, nem tud optimalizálni semmit. Másképpen nézve ugyanez toppal:
top - 17:47:03 up 67 days, 6:09, 1 user, load average: 0.89, 1.00, 0.99
Tasks: 156 total, 1 running, 155 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0%us, 0.3%sy, 0.0%ni, 6.6%id, 93.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.0%us, 0.7%sy, 0.0%ni, 93.4%id, 5.3%wa, 0.0%hi, 0.7%si, 0.0%st
Mem: 2059236k total, 2048616k used, 10620k free, 1812760k buffers
Swap: 2097144k total, 144k used, 2097000k free, 97592k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1820 root 10 -5 0 0 0 S 0.3 0.0 102:36.12 md2_raid5
8063 root 10 -5 0 0 0 S 0.3 0.0 0:16.82 istd4
17288 root 15 0 12736 1116 816 R 0.3 0.1 0:00.13 top
1 root 15 0 10344 648 552 S 0.0 0.0 0:01.47 init
Az iscsi target daemon szálaiból csak egy aktív, pedig akár 8 szál is mehetne. Ez egybevág az 1-es sorhosszal kapcsolatos eddigi megfigyelésekkel. Borzasztó látvány a 93%-os IOWait CPU idő is. Próbálkoztam a több IO ütezővel, különösen az anticipatory schedulertől vártam javulást, amit pont ilyen esetekre találtak, hiszen megpróbálja előre becsülni a még be nem érkezett kéréseket is. Semmit nem javított, ami tovább erősítette a gyanút, hogy teljesen véletlenszerű helyekre érkeznek a kérések. Talán valami swappol? A Shelob belül nem swappolt, ez biztosan látszott volna. Ezen kívül a VI client VMware Tools: OK jelzést mutat, ami azt jelenti, hogy a memory ballooning meghajtó működik, memória kifogyásnál ennek elsőbbsége van a swappeléssel szemben.
Vissza az aragornra az esxtop-pal, ezúttal az memória statisztikára ‘m’ billentyűvel, majd ‘f’ és a SWAP oszlopcsoport beválasztásával:
4:37:31pm up 67 days 5:57, 109 worlds; MEM overcommit avg: 0.16, 0.16, 0.17
PMEM /MB: 20479 total: 272 cos, 299 vmk, 13469 other, 6438 free
VMKMEM/MB: 19929 managed: 1195 minfree, 2467 rsvd, 17316 ursvd, high state
COSMEM/MB: 9 free: 541 swap_t, 491 swap_f: 0.00 r/s, 0.00 w/s
PSHARE/MB: 4154 shared, 714 common: 3440 saving
SWAP /MB: 2156 curr, 8 target: 0.34 r/s, 0.00 w/s
MEMCTL/MB: 168 curr, 168 target, 7955 max
GID NAME MEMSZ SZTGT TCHD %ACTV %ACTVS %ACTVF %ACTVN SWCUR SWTGT SWR/s SWW/s
15 vmware-vmkauthd 5.58 5.58 1.93 0 0 0 0 0.00 0.00 0.00 0.00
16 Balrog 2048.00 1907.09 266.24 7 5 6 2 0.00 0.00 0.00 0.00
20 Alnitak 1536.00 1128.40 150.42 9 6 8 4 1.96 0.68 0.00 0.00
37 Gorbag 512.00 464.40 15.36 0 0 0 0 284.49 0.00 0.00 0.00
50 Shelob 3072.00 3006.20 1044.48 31 8 24 19 1116.38 0.00 0.34 0.00
59 Uglug 2048.00 1876.85 102.40 3 2 3 2 420.87 0.00 0.00 0.00
67 TaddmImage 3072.00 3020.48 829.44 25 23 24 9 0.00 0.00 0.00 0.00
68 ProjectWiki 512.00 509.26 10.24 2 1 2 2 223.01 7.84 0.00 0.00
78 PseudoSalvador 4096.00 2803.11 40.96 0 0 0 0 109.05 0.00 0.00 0.00
[...]
“Van különbség elmélet és gyakorlat között? Elméletileg nincs, de gyakorlatilag nagyon is van.” – tartja a bölcs mondás, a HUP-on egy ember aláírásából. Hát itt az élő példa rá. Az SWCUR bizony azt mutatja, hogy most éppen 1,1GB memória van swapra írva. A SWTGT, vagyis a megcélzott kilapozandó memória mérete viszont 0, vagyis korábban volt valami oka, de most már elmúlt. Az SWR/s, nos ez swap read-in rate, ez a rejtélyes folyamatos olvasás forrása. Nagyon lassacskán, kb 600kB/s-el csorog visszafelé swapról a memória tartalma. A szerencsétlen mit sem sejtő Shelob az scp-vel másolt adatokat a memóriban akarja cache-elni, ezáltal hozzáér a kilapozott memórialapokhoz. Ezeket egyesével szedi be az vmm, addig pedig felfüggeszti a guest gép futtatását, amíg nem tudja alárakni a hiányzó memórialapot. Mindezt meglepően szép egyenletes ütemben. Látható ugyanez másik ábrán is, a VI Clientből nézve:
 Azt hiszem innentől kezdve ez lesz az demonstrációs példa előadáson a memory ballooning hasznosságának magyarázatához. Már csak egy a kérdés: miért csinálja ezt? Erre is fény derült, hamarabb, mint gondoltam:
[xmi@shelob:~ ] sudo service vmware-tools status
Password:
vmware-guestd is running
Aha, tényleg?!
[xmi@shelob:~ ] sudo service vmware-tools restart
Stopping VMware Tools services in the virtual machine:
Guest operating system daemon: [ OK ]
Virtual Printing daemon: [ OK ]
Guest memory manager: [ OK ]
VM communication interface socket family: [ OK ]
VM communication interface: [ OK ]
VMware Tools is installed, but it has not been
(correctly) configured for the running kernel.
To (re-)configure it, invoke the following command:
/usr/bin/vmware-config-tools.pl.
Végülis nem hazudik, a guestd tényleg fut, de kb ez az egyetlen része, ami működik. Én viszont hazudtam, amikor azt írtam, hogy a VMware Tools: OK bármit is jelent a ballooning meghajtó működőképsségét illetően, ha nem is szándékosan, ez ugyanis engem is megvezetett. A kernel moduloknak bizony nagy híja van, nyilván a legutóbbi kernel update után elmaradt a vmware-config-tools.pl újbóli futtatása. Azért jó tudni, hogy erről a problémáról semmi, de semmi értesítésre nem számíthatok. Azt hiszem kell erre egy saját ágenst írnom, mert nem ez lesz az egyetlen virtuális gép, aminél ilyen előfordul.
Szintén tanulságos volt látni, hogy a valós IO terhelési értékek mennyire nem látszódnak át egy iSCSI kapcsolaton keresztül, és hasonlóképpen a külső swappolás következményei is teljesen mérhetetlenek a guest gépen belülről nézve.
A Virtualizációs technológiák és alkalmazásaik választható tárgyunkban most volt nemrég az ESXi-s gyakorlat, amire meg kellett oldani, hogy minden hallgatónak legyen egy saját ESXi homokozója. Bár a napokban megjelent új VMware Workstation 7-ben már támogatott az ESX 4.0 futtatása, nekünk még csak 6-os volt a laborban, így Dani megoldotta egyik este, hogy PXE boot segítségével hálózatról lehessen ESXi-t bootolni [amit majd szépen le is dokumentál itt, igaz?;-]. Minden hallgató 2 gépet kapott, az egyiken elindította az ESXi 4-et, a másikon pedig kapott két virtuális gépet: egy linuxos iSCSI target-et, ami a tárhelyet fogja szolgáltatni, és egy windowsos virtuális gépet benne a vSphere Client menedzsment eszközzel. Írtunk még egy rövid segédletet, hogy ebben a környezetben mit kell beállítani, hogy üzemképes legyen az ESXi. A tapasztalat viszont az volt, hogy mivel a hallgatók nagy része most látott először iSCSI-t és szerver oldali virtualizációs rendszert, ezért ez kb. egy óráig tartott, és gyakorlat végén jutottunk el oda, hogy akkor most lehetne virtuális gépet létrehozni:-). A következő alkalomra automatizálni kellett az előkészítő lépéseket. Ehhez a következők kellenek:
- VMKernel interfész létrehozása,
- Szoftveres iSCSI engedélyezése,
- iSCSI target csatlakoztatása,
- Kiajánlott lemezek felderítése,
- A csatlakoztatott lemezen VMFS-es datastore létrehozása.
A VMware több féle automatizálási megoldást nyújt, van távoli parancssor, Perl-es, PowerShell-es, Web Service-s API is. A VMware PowerShell cmdlet-eit úgyis ki akartam próbálni, ez tehát pont jó alkalomnak tűnt:-) A következőt kell tenni:
- PowerShell feltelepítése a windowsos virtuális gépre (Windows 7 előtti Windowsokon),
- PowerCLI letöltése és telepítése,
- PowerCLI elindít, a Get-VICommand segítségével ismerkedni a parancssokkal.
Akkor lássuk, miből élünk:) A VMKernel létrehozását elég gyorsan megoldottam, erre a New-VMHostNetworkAdapter cmdlet való. Az iSCSI már kicsit bonyolultabbnak nézett ki, de szerencsére a New-Datastore man oldalán van pont egy ilyen példa. Ezek alapján könnyű volt összerakni a szkriptet:
# Name: Prepare-ESXi.ps1
# Author: Micskei Zoltán
# Scripts based on the example in man New-Datastrore
# Date: 2009. 10. 27.
# Desc: Configures iSCSI initiator and adds a datastore to a PXE-booted ESXi host in IE224 lab
# Param: 1 - IP of the ESX host
# 2 - IP of the iSCSI target to connect
param(
[string] $esxIP = $(throw "Supply the IP address of the ESX host"),
[string] $iscsiServer = $(throw "Supply the IP address of the iSCSI target")
)
# Constants
$ISCSI_HBA = "vmhba34"
$ISCSI_PORT = 3260
Write-Output "Setting up $esxIP.."
# connect to the ESX host
connect-viserver $esxIP
# get the default virtual switch (assumes there is only one)
$vSwitch = Get-VirtualSwitch
# modify this according to your environment
$vmKernel_IP = $esxIP.Replace(".100.", ".120.")
# create a nem VMKernel
New-VMHostNetworkAdapter -VMHost $esxIP -PortGroup "VMKernel Port" -VirtualSwitch $vSwitch -IP $vmKernel_IP -SubnetMask 255.255.0.0
# get the necessary views
$h = Get-VMHost
$hostView = Get-View -VIObject $h
$storageSystem = Get-View $hostView.configManager.storageSystem
#Enable the software iSCSI controller.
$storageSystem.UpdateSoftwareInternetScsiEnabled($true)
#Add an iSCSI server for a dynamic discovery.
$target = New-Object VMware.Vim.HostInternetScsiHBASendTarget
$target.address = $iscsiServer
$target.port = $ISCSI_PORT
$storageSystem.AddInternetScsiSendTargets($ISCSI_HBA, $target)
#Scan for iSCSI devices.
$storageSystem.RescanHba($ISCSI_HBA)
# Get lunPath and create a new storage.
# Select the lun where the vendor is IET (iSCSI Enterprise Target, the Linux-based iSCSI target used currently)
$lunList = Get-ScsiLun -VMHost $h
#HACK: the proper name is 'IET ' (yes, with the spaces:( )
$lun = ($lunList | ? { $_.Vendor -like "IET*" })
# create new datastore
New-Datastore -Vmfs -VMHost $h -Path $lun.CanonicalName -Name iScsi
Write-Host "Datastrore created" |
# Name: Prepare-ESXi.ps1
# Author: Micskei Zoltán
# Scripts based on the example in man New-Datastrore
# Date: 2009. 10. 27.
# Desc: Configures iSCSI initiator and adds a datastore to a PXE-booted ESXi host in IE224 lab
# Param: 1 - IP of the ESX host
# 2 - IP of the iSCSI target to connect
param(
[string] $esxIP = $(throw "Supply the IP address of the ESX host"),
[string] $iscsiServer = $(throw "Supply the IP address of the iSCSI target")
)
# Constants
$ISCSI_HBA = "vmhba34"
$ISCSI_PORT = 3260
Write-Output "Setting up $esxIP.."
# connect to the ESX host
connect-viserver $esxIP
# get the default virtual switch (assumes there is only one)
$vSwitch = Get-VirtualSwitch
# modify this according to your environment
$vmKernel_IP = $esxIP.Replace(".100.", ".120.")
# create a nem VMKernel
New-VMHostNetworkAdapter -VMHost $esxIP -PortGroup "VMKernel Port" -VirtualSwitch $vSwitch -IP $vmKernel_IP -SubnetMask 255.255.0.0
# get the necessary views
$h = Get-VMHost
$hostView = Get-View -VIObject $h
$storageSystem = Get-View $hostView.configManager.storageSystem
#Enable the software iSCSI controller.
$storageSystem.UpdateSoftwareInternetScsiEnabled($true)
#Add an iSCSI server for a dynamic discovery.
$target = New-Object VMware.Vim.HostInternetScsiHBASendTarget
$target.address = $iscsiServer
$target.port = $ISCSI_PORT
$storageSystem.AddInternetScsiSendTargets($ISCSI_HBA, $target)
#Scan for iSCSI devices.
$storageSystem.RescanHba($ISCSI_HBA)
# Get lunPath and create a new storage.
# Select the lun where the vendor is IET (iSCSI Enterprise Target, the Linux-based iSCSI target used currently)
$lunList = Get-ScsiLun -VMHost $h
#HACK: the proper name is 'IET ' (yes, with the spaces:( )
$lun = ($lunList | ? { $_.Vendor -like "IET*" })
# create new datastore
New-Datastore -Vmfs -VMHost $h -Path $lun.CanonicalName -Name iScsi
Write-Host "Datastrore created" A szkript természetesen a mi környezetünkre (hálózat, iSCSI beállításai) illeszkedik, de szerintem könnyen lehet máshova is adaptálni. Pár dolog, amire érdemes figyelni:
- Jelenlegi formájában a csatlakozáshoz szükséges felhasználónevet és jelszót interaktívan kéri be,
- A New-Datastore leírásában a példában van pár elírás (pl. CannonicalName -> CanonicalName, ( előtti felesleges szóközök), lásd itt,
- A LUN kiválasztásánál sehogy se sikerült az IET sztringre szűrni, persze, mert a pontos név IET és utána még 5 szóköz, ezért használok -like operátort a kiválasztásban:)
- FIGYELEM: az ingyenes ESXi esetén csak olvasási műveleteket lehet végrehajtani távolról, tehát ott az alábbi szkript nem működik.
Alapvetően meglepően gyorsan ment a szkript elkészítése, és a segítéségével tényleg percek alatt össze lehet hozni egy működő teszt ESXi rendszert. Érdemes még nézegetni a PowerCLI csapat blogját, jó kis példák vannak ott is.
Micskei Zoltán
Július környékén kicsit írtam egy alkalmazást, ami JNI-n keresztül ért el natív C-s könyvtárakat. A kísérletből származó tapasztalataimat most megosztom veletek.
Continue reading Java Native Interface tanulságok
Most, hogy átálltunk Vistára az egyik laborban, természetesen jelentkeztek alkalmazás kompatibilitási problémák. De mondanom se kell, hogy ezek inkább a fejlesztők hibái voltak, mintsem az operációs rendszeré. Van nekünk egy ImageDistributer nevű .NET-es alkalmazásunk, ami az UFTP nevű kis multicast másoló programot használja a háttérben a nagy méretű virtuális gépek terítésére. Ennek az első változatát én írtam, aztán egy szakdolgozat tervező hallgatóm folytatta és működőképes állapotba hozta, most pedig a hibajavítás megint visszaszállt rám:) Egész szépen meg lett tervezve és írva, valamint a funkcionalitás nagy része le is lett tesztelve. De azért a tesztelés korántsem volt teljes körű, ami egy ilyen átállásnál (új OS, 32->64 bit, új gépek) elő is jön.
- Any platform volt beállítva a projektnek architektúrára, így a 64 bites OS-en a .NET-es alkalmazásunk 64 bites folyamatként futott. Igen ám, de így a 32 bites-es C-ben írt uftp DLL-t nem tudta betölteni. Gyors javításként lehet segíteni a corflags segédprogrammal ezen, de a szép megoldás ugye ha újrafordítjuk az alkalmazást, és bejelöljük szépen a célplatformot.
- Tanulság: gondolni kell a 64 bites környeztre is, és tesztelni azon is.
- Az új laptopoknak 1920×1200-as képernyőfelbontása, de ez csak úgy olvasható, ha a betűméretet megnöveljük (High DPI). Igen ám, de az alkalmazás GUI-jában voltak fixen beállított, pixelre megadott magasságú vezérlők, ott nyilvánvalóan a szöveg egy része kilógott.
- Tanulság: High DPI beállítással is kell tesztelni az alkalmazást.
- A fenti kettő problémát viszonylag gyorsan meg lehetett oldani, az utolsó trükkösebb volt. A Wake-on-LAN funkció nem működött az alkalmazásban. WireSharkkal ránézve látszott, hogy nem is küldi ki a mágikus csomagot (magic packet:) a hálózatra. Tűzfal rendben, hálózati beállítások rendben, a kódon nem változtattunk semmit, ez XP-n még ment. Rákeresve mások is találkoztak már ezzel, hogy bizonyos WOL-on programok nem működtek. Kerestem végül egy működő kódot, és sorról-sorra megnéztem, hogy hol tér el a mi kódunktól. A megoldás az volt, hogy a mi kódunk a 255.255.255.255 címre próbált meg küldeni UDP csomagot, és nem a subnet broadcast címre. A helyes broadcast címre küldve már ment minden simán.
- Tanulság: érdemes megnézni pontosan a technológiát, amit használunk, és nem pongyolán implementálni:)
Ezeket átírva az új verzió már gond nélkül megy Vista alatt is. Ez csak megerősítette azt a gyanúmat, hogy az alkalmazás inkompatibilitás csak egy jó kifogás a lusta fejlesztőknek:-)
Micskei Zoltán
A héten egy viszonylag nagy táblázatot kellett összeállítnom az AIS middleware robosztusság tesztek eredményeiből. A viszonylag nagy azt jelenti, hogy volt kb 145000 sorom, amiknek nagy részében képlettel kellett kiszámolni dolgokat, szóval nem mindegy a sebesség.
1. Keresés
Értékek keresésére viszonylag sok függvény áll rendelkezésünkre. Ezek közül az FKERES (VLOOKUP) a legadvancedabb. És az esetek többségében elég is, de lineárisan keres. Emiatt nagy tábláknál használhatatlan.
A KERES (LOOKUP) függvény ezzel szember binárisan keres. A keresett érték tömbnek növekvő sorrendben rendezettnek kell lennie emiatt.
VLOOKUP(lookup_value,table_array,col_index_num,range_lookup)
LOOKUP(lookup_value,lookup_vector,result_vector)
Még így is egy 1100000 (hivatkozások) * 43000-s (kulcsok) update eltart egy pár másodpercig. FKERES-sel viszont kivárhatatlan.
2. Automatikus kitöltés
Nagyon hasznos funkció, hogy a jobb alsó sarokban levő kis négyzettel automatikusan kitölthetünk cellákat. Többtízezer cella esetén azonban még ez sem elég segítség.Mivel API-ból is elérhető ez a funkció, írtam egy kis makrót, amivel bármennyi cellát automatikusan kitölthetünk lefelé:
Sub filldown()
maxindex = Cells(2, 1).End(xlDown).Row
copyFormula = ActiveCell.Formula
Set destinationRange = ActiveSheet.Range(ActiveCell, Cells(maxindex, ActiveCell.Column))
ActiveCell.AutoFill destinationRange
End Sub
A maxindex képletét megváltoztatva igazítani kell az igényeidhez, de másra nincs szükség. Az éppen aktuális cellában levő formulát sokszorozza lefelé a megfelelő számú cellába.
Most ennyi jutott eszembe. Még ráadásként itt egy listát az angol függvények magyar megfelelőivel, meg még egy csomó más nyelvvel.
Continue reading Excel optimalizáció
Az őszi tanévkezdés előtt esedékes mindig a tanszéki laborgépek újratelepítése. Most a fő motivációt az adta, hogy az eddigi 32 bites kliens Windowsok nem látták a gépekben lévő 4 GB memória egészét, így mindenképpen egy teljes cserét kellett elvégezni. Az eddig fent lévő Windows XP egyébként is kicsit elöregedett már, a kérdés csak az volt, hogy mire váltsunk. A Windows 7 ugyan megjelent már, MSDNAA-ban az egyéni felhasználóknak már el is érhető, azonban az intézményi Tisztaszoftverbe még nem került be (és az eddigi tapasztalatok alapján még egy jó félévig nem is fog, még a Vista SP2 telepítőig se jutottak el:). Így marad a Vista vagy a Linuxra átállás. Végül abban egyeztünk meg, hogy az egyik laborban Linux lesz (ez is természetesen központosított menedzsmenttel, testreszabva, hálózati boottal, stb. – erről majd talán egyszer később), a másikban pedig Vista az eddigi Active Directory tartománnyal. Így az adminisztrációs igény kétszer annyi, de később az oktatásban jól jön majd, hogy mindkét világ üzemeltetéséből lesz első kézből tapasztalatunk, és tényleg be tudunk mutatni egy heterogén rendszert.
Az első kérdés így eldőlt, 64 bites Vista kerül fel a gépekre. A második kérdés se volt egy egyszerűbb: hogyan menjen a telepítés. Eddig a referencia gép elkészítése teljesen kézzel + sysprep + ghost-os lemezkép készítése majd szétosztása módszer ment. Viszont ha már nekikezdtünk az átállásnak, akkor jó lenne az aktuálisan javasolt microsoftos klienstelepítési módszert is megismerni, nevezetesen a Microsoft Deployment Toolkitet és az összes hozzá kapcsolódó technológiát. Ez első körben a következőkből áll:
- Windows Automated Installation Kit (AIK): alapvető, alacsony szintű eszközök az automatizált szoftvertelepítéshez. A főbb eszközök a Windows Imaging Format (WIM), egy fájl alapú lemezkép formátum, ami több partíció képét képes tárolni egy fájlban, úgy, hogy az azonos fájlokat csak egyszer tárolja el (single image storage). Az ilyen lemezképek készítésére, módosítására és visszaírására való az ImageX program, a benne tárolt Windows példányt pedig a Windows 7-es AIK-ban bevezetett Deployment Image Servicing and Management (DISM) eszközzel lehet testreszabni (csomagok telepítése, frissítés, beállítások változtatása, stb.). A telepítendő gépek előkészítésére való a Windows PE, ami egy lecsupaszított Windows, a legújabb AIK-ban lévő Windows PE 3.0 a Windows 7-es kerneljén alapszik. A Windows System Image Manager (Windows SIM) segítségével lehet úgynevezett válasz fájlokat (answer file, unattend.xml) létrehozni, amik a telepítés során automatikusan megadnak egy csomó beállítást. Végül, mielőtt le szeretnénk klónozni egy windowsos gépet, ki kell irtani belőle a gépspecifikus beállításokat (pl. gép SID-je), erre való a Sysprep eszköz. Ezek segítségével már össze lehet állítani egy teljes folyamatot, lásd pl. itt: Windows Vista Deployment Step-by-Step Guide.
- Windows Deployment Services (WDS): a Windows Server egy szerepe, amelynek a segítségével WIM lemezképeket lehet telepíteni sok kliensgépre. Az AIK szolgáltatását kiegészíti hálózati bootolással, meghajtókat lehet felrakatni telepítés közben, és képes multicast másolásra is.
- Microsoft Deployment Toolkit (MDT): a telepítési folyamatot összefogó Solution Accelerator: egy közös GUI felület, leírások és sok-sok előre elkészített script. Az új verzió, ami a Windows 7-hez is jó már, most van Release Candidate állapotban, a Connectről letölthető. Két fajta módszert támogat. Lite Touch Installation (LTI) esetén lehet, hogy néhány lépést kézzel kell megtenni. Zero Touch Installation (ZTI) esetén a folyamat teljesen automatikus, de ehhez System Center Configuration Manager kell.
Van egy pár rövidítés, és ez még csak a jéghegy csúcsa:) Elég komplex rendszer, hisz rengeteg igényt ki kell szolgálnia: OEM-ek egyedi felhasználók számára készítenek elő testreszabott gépeket, vállalati rendszergazdák egységesített telepítéseket csinálnak, meglévő gépek migrálása és új telepítések, stb. stb. Dokumentáció és segédanyag is van hozzá rendesen, a gond inkább az, hogy győzze az ember megnézni őket. Néhány a teljesség igénye nélkül:
Új gépek esetén a két fő út, amit láttam:
- Alap operációs rendszert telepítünk, és az MDT-ben a telepítés során hozzáadjuk a frissítéseket, meghajtókat, alkalmazásokat és beállításokat.
- Feltelepítünk egy referenciagépet, erre felrakunk mindent, amit akarunk, majd készítünk egy saját WIM lemezképet erről, és ezt szórjuk szét a kliensekre.
Az első előnye szerintem, hogy nincs kézi játék a dologban, minden kiegészítő telepítése, minden beállítás látszik a konfig fájlokból. Könnyű egy-egy komponenst lecserélni, megváltoztatni. A másik megoldás előnye, hogy gyorsabb: csak egyszer kell SP2-t, Office-t, stb. telepíteni, a kliensgépeken már csak másolni kell. Továbbá nem minden alkalmazás esetén olyan triviális az automatizált telepítés. Én végül egy harmadik, hibrid megoldást választottam:), kicsit ebből is és abból is. Referencia gép készült, de csak az operációs rendszer frissítése és néhány alap alkalmazás került fel, ami minden gépre kell (Office, VMware, putty, winscp…). A gépspecifikus programok (pl. Levono System Update) és meghajtók MDT-vel kerülnek fel, a beállítások válasz fájlból vagy csoportházirendből jönnek.
Úgyhogy telepítettem egy Windows Server 2008 R2-t, felraktam rá a legfrissebb AIK-ot, MDT 2010 RC-t, bekapcsoltam a WDS szerepet, és nekikezdtem a próbálgatásnak. A telepítést részletesen nem írom le, az a fenti linkeken megtalálható, inkább csak a főbb problémákat sorolom fel, amibe belefutottam. Ezekből se volt kevés, kb. 4-5 nap volt, mire a technológia megismerésével, kipróbálásával, csiszolgatásával eljutottam odáig, hogy most péntekre megy minden gép az új rendszerrel.
Problémák (és megoldásaik)
Hibakeresés
- Előbb-utóbb ki kell próbálni, hogy mit alkottunk az MDT-ben a rengeteg beállítással és telepítendő komponenssel. Erre jobb módszert nem találtam, mint hogy egy virtuális géppel végigjátszatom a telepítést. Ez ugye viszont hosszú folyamat, környezettől függően fél-egy óra. Általában a végén szokott kiderülni, hogy valamit elírtunk egy konfig fájlban:-)
- A Windows telepítő hibaüzenetei nagyon félrevezetőek! Legtöbbször arra panaszkodik, hogy nem találja a WIM fájlt, közben teljesen más a gondja alsóbb szinteken. Ez különösen aljas volt az alábbi szituációban, itt a kiírás során levágta a fájlnév végét, és azt hittem, hogy a túl hosszú név a gondja (közben természetesen nem ez volt).
- A pontos hibaüzenetek a gépen lévő log fájlokban vannak. Ezek kicsit szét vannak szórva, tipikus helyek: X:\MININT, C:\MININT\SMSOSD\OSDLOGS, C:\Windows\Temp, C:\Windows\SMSOSD, C:\Windows\sysprep\panther (lásd pl. itt: Deployment logs). A leggyorsabban a setuperr.log-ból lehet kideríteni, ha a telepítés során volt hiba.
- A log fájlok magukban elég olvashatatlanok, érdemes letölteni az SMS2003 Toolkit2-ben lévő SMS Trace programot.
- Ezen kívül az MDT-ben kapcsoljuk be, hogy futás közben vagy után másolja már fel a log fájlokat a szerverre. Ha hiba van, nyomjunk a kliensen OK-ot, egész addig, amíg be nem jön a Windows PE command prompt, és ilyenkor már fel is kerültek a részletes logok a szerver megadott megosztásába. Ehhez az MDT Deployment Workbench-ében a CustomSettings.ini-ben kell megadni az SLShare változó. Ha még megadjuk az SLShareDynamicLogging változót is, akkor a fő log fájl, a BDD.log, minden egyes változása futás közben már felkerül, így követhető valós időben távolról, hogy hol tart a telepítő (lásd: MDT 2010 New Feature #1: Logging directly to the network)
vLite
- Az alap Vista telepítés elég nagy, és nem lehet kiszedni belőle a telepítés előtt komponenseket hivatalosan (Windows 7-ben a DISM már el tud távolítani néhányat, de közel se mindent). Erre a vLite nagyon jó volt, korábban többször használtam már. Most azonban nem igazán megy már.
- A vLite fejlesztését abbahagyták. AIK 2.0-val sikerült végül elindítanom, de futás közben elszállt. A fő gond viszont az, hogy nem lehet Vista SP2-t telepíteni vLite-tal kezelt gépre.
- Végül nem használtam vLite-ot, ennek az lett az eredménye, hogy 10 GB helyet használt alapból a rendszer.
Vista SP2
- A Campusba nem sikerült még felrakni egy Vista SP2-es telepítőt.
- SP2-t nem lehet MDT-vel a telepítés offline fázisában felrakatni, ezt csak online állapotban lehet (értsd, amikor az adott WIM image már fut egy gépen).
- Nem lehet SP2-vel összefűzött telepítőt könnyen készíteni, lásd pl. Slipstream Vista SP2? Csak olyan módszert találtam, hogy feltelepítjük a Vistát a gépre, SP1 telepítés (ha még nem volt), SP2 telepítés, majd ImageX segítségével készítünk egy új lemezképet. Ez jó nagy méretű lesz, de legalább megspóroljuk az SP2 telepítésének idejét a klienseken. Részletes leírás pl. itt: Use Reverse Integration to slipstream Windows Vista SP1 and SP2
- Ne felejtsük el az SP2 telepítés után lefuttatni a compcln programot, ami eltávolítja az elmentett régi fájlokat.
- A WIM fájlból ISO készíthető:
oscdimg.exe -n -h -m -o -bc:\temp\ISO\boot\etfsboot.com -lVISTASP2 c:\temp\ISO c:\temp\vista_sp2.iso
Arra kell csak figyelni, hogy ha a WIM fájl nagyobb, mint 4 GB, akkor UDF-es ISO-t kell készíteni (-u2 kapcsoló). Ha az egész nagyobb, mint 4,5GB, akkor még egy bootorder.txt-t is kell csinálni, lásd az oscdimg-t a súgóban.
WDS
- A WDS-ben ha készítünk egy Capture Image-t (egy olyan Windows PE, amiben van egy GUI, ami egy sysprep-elt partícióból WIM-et készít, és felmásolja a WDS szerverre), akkor az a WIM készítése során maximális tömörítést használ (ezt nem találtam leírva sehol, de a tapasztalat ezt mutatta).
- A Capture Image segítségével készített WIM-et viszont nem lehet egyből használni az MDT-ben, ugyanis a következő hibát kapjuk: “Error Message: Windows cannot access the required file d:\sources\install.wim when replacing install.wim with custom install.wim”. Ez természetesen megint nem a hiba valódi oka, az a logokban van: “SetWindowsImageInfoOnBB:Failed while updating EditionID for volume PID”. A gond az, hogy a WIM metaadataiban nincsen beállítva a FLAGS rész, ami tartalmazza, hogy melyik változatot kell telepíteni. Ezt könnyen bele lehet rakni az ImageX /info paranccsal.
- Alapértelmezés szerint, ha a WDS gép tartományi tag, akkor ha WDS-ről telepítünk egy WIM-et, akkor a telepítés végén belépteti a klienst a tartományba. Ezt a szerver tulajdonságai között ki lehet kapcsolni. (Ez nem vonatkozik arra az esetre, ha MDT-ből indítjuk a telepítést, mert ott a tartományba léptetést az MDT vezérli.)
- Az MDT-ben lehet WDS-en lévő WIM-eket importálni úgy, hogy a fájlokat otthagyja a WDS-en, és az MDT könyvtárában csak metaadatokat tárol, azonban ilyenkor nem lehet majd az MDT-ből az unattend.xml-t szerkeszteni. Úgyhogy ezt a módszert nem alkalmaztam.
- A multicast nálunk nagyon lassú volt (60KB/s 100Mbit/s-es hálón). Néhány tanács, ami multicastnál segíthet: Slow Multicasting speed using Windows Deployment Services. Végül nem találtam meg a probléma okát. Ami gyanús, hogy a WDS-ben a szerver tulajdonságainál a Network / Network Profile szürke, semmilyen sebességet nem lehet kiválasztani.
MDT
- Az MDT-t két szinten lehet testreszabni.
- Az egész deployment share szintjén lehet a CustomSettings.ini beállításaival szabályozni (ennek megadása a Deployment Workbench / adott deployment share / Tulajdonságok / Rules fül). Ez a fájl helyileg a deploymentshare\Control könyvtárban van. A megadható beállításokat az MDT súgójában a Microsoft Deployment Toolkit Reference / Properties rész alatt találjuk. Itt a Providing Properties for Skipped Windows Deployment Wizard Pages részt érdemes megnézni még, ez foglalja össze, hogy minimum mit kell megadni ahhoz, hogy az MDT-ben lévő Windows Deployment Wizard ne kérdezzen semmit. A CustomSettings.ini mellett van még egy fájl, a Bootstrap.ini. A CustomSettings.ini-t a kliens a deployment share-hez való csatlakozás után a szerverről szedi le, így a csatlakozás előtti beállításokat nem tudjuk megadni. Erre való a Bootsrap.ini, ami bekerül az LTI Windows PE image-be, és így jut le a klienshez.
- Létre kell hozni egy Task Sequence-t, amiben megmondjuk, hogy mit csináljon az MDT. Telepítéshez érdemes az alap Standard Client Task Sequence-t használni, mert kellően bonyolult ahhoz az MDT, hogy magunktól egy ilyet nem fogunk tudni összerakni:) Ebben pedig később le lehet tiltani azokat a lépéseket, amik nem kellenek nekünk.
- A LTI folyamat elején elinduló Windows PE-ben ha be akarjuk állítani a billentyűzetkiosztást, akkor ehhez a keyboardlayoutPE tulajdonságot kell megadni a CustomSettings.ini-ben és a Bootstrap.ini-ben. A trükk csak annyi, hogy nem a szokásos hu-HU értéket kell megadni, hanem a hexa kódját: 040e:0000040e
- A deployment share tulajdonságainál a PXE boot fülön meg lehetne adni saját hátteret, viszont ezt nekem valamiért kiszedte a WinPE fájlból. Helyette az a trükk, hogy megadunk egy ExtraFiles könyvtárat ugyanott, és abba belerakjuk a képet Windows\system32\winpe.bmp néven.
- A Standard Client Task Sequence sablon törli a teljes HDD-t, és egy maximális partíciót hoz létre rajta, ezt érdemes felülvizsgálni (Preinstall\New Computer only\Format and Partition disk task). A gépeken volt egy Lenovo Service Partition, amit meg kellett őrizni. Ezért én azt csináltam, hogy ezt a feladatot kitöröltem, helyette hozzáadtam egy Run Command Line-t, és meghívtam a diskpart.exe-t (lásd: How Do I Use MDT 2008 to Partition a hard Drive). Nálam ez így nézett ki (szerintem nem jó a beépített Scripts könyvtárba rakni a saját fájlokat, tisztább egy külön könyvtárat csinálni):
diskpart.exe /s %DEPLOYROOT%\ExtraScripts\itec-diskpart.txt
A diskpart.txt tartalma:
select disk 0
select partition 1
format fs=ntfs label="Preload" quick
exit
- Volt olyan, hogy meg akartam nézni, hogy egy lépés jól sikerült-e. Ilyenkor jó lett volna megállni, de a LTISuspend.wsf szkriptet csak feltelepült Windowsból lehet hívni. Helyette maradt a Restart Computer lépés, és újraindulás után nem az LTI image-t indítottam, hanem egy saját WinPE-t.
- Alkalmazások esetén nem egyszerű kitalálni, hogy pontosan milyen kapcsolók kellenek a teljesen automatikus telepítéshez. Ebben segíthet: Unattended/Silent Installation Switches for Windows Apps. Nekem pl. a Lenovo System Update-t kellett telepíteni, ennél ez így néz ki: setup.exe -s -a /s /v” /qn” /L1033. Szerencsére ez benne volt a leírásában🙂 Ráadásul pozitívan csalódtam a Lenovo-ban, van külön adminisztrátoroknak szóló oldal, ahol pl. még csoportházirend fájlok is vannak.
- Ha készítünk egy saját WIM-et, és azt importáljuk az MDT-be, akkor megkérdezi, hogy mellémásolja-e egy telepítő DVD-ről a teljes Setup-ot is (kb. 300 MB). Erre csak akkor van szükség, ha nincs még olyan WIM a deployment share-en, ami ugyanilyen verziójú és mellette ott van a Setup, egyébként tudja azt használni. Ha mégse talál ilyet, akkor a kliens telepítés közben leáll “ERROR – Unable to find SETUP, needed to install the image …” hibával. No igen, csak a trükk az, hogy pontosan mit is jelent az, hogy ugyanolyan verzió?:) A leírásokban ezt nem találtam meg, végül a megfelelő scripteket kicsit átírva állapítottam meg (az LTIAppyl.wsf tartalmazza, az ApplySetup() metódusban, MDT2010 RC1-ben a 371. sortól kezdve):
- Platform (X64, X86..), Build (a teljes build number, pl. 6.0.6002.18005 és a Flags metaadat (ebben van az, hogy melyik edition).
- A másik trükk csak az, hogy ezt nem a WIM fájlokból, hanem a deploymentshare\Control\OperatingSystems.xml-ből olvassa ki.
- Tartományba lépés: valahogy tárolni kell a tartományba lépéshez szükséges adatokat.
- Az unattend.xml-ben meg lehet adni az UnattendedJoin résznél, azonban itt a tartományi rendszergazda jelszavát nyílt szövegként tárolja. Ugye ez a fájl fent van a megosztáson végig, plusz lekerül a kliensre, és a végén meg is marad rajta (a helyi admin jelszavát titkosítva tárolja az unattend.xml-ben, sőt, az MDT a végén ki is törli még a titkosított részt is). Ez másnak is fájt: Domain Join Password Encryption and Unattended.xml (a válasz itt nem túl jó, hisz csak a legvégén törli le, mint ahogy azt az utolsó bejegyzésben fel is vetik).
- Lehet még azt, hogy az MDT Recover from Domain feladatával oldjuk meg, de ilyenkor meg a CustomSettings.ini-ben van benne a jelszó, ami megint nem túl jó.
- Van Offline domain join, de ez csak Windows 7-tel működik: Offline Domain Join (Djoin.exe) Step-by-Step Guide
- Végül azt csináltam, hogy a telepítés során nem léptettem be a tartományba a gépeket, hanem utána a netdom join parancsot távolról is végre lehet hajtatni. Így egy PowerShell szkript oldotta meg a feladatot. Nem a legjobb, de mást nem találtam.
Unattend.xml
- MDT-ben a Task Sequence tulajdonságainál az OS Info fülről lehet szerkeszteni.
- A súgóban a Settings to Use for an Unattended Installation résznél van megadva, hogy minimum mit kell beállítani ahhoz, hogy a telepítő ne kérdezzen semmit. Ennek nagy részét megadja az MDT alap sablonja is, de azért ellenőrizzük.
- A telepítés után a Windowsok most már az úgynevezett Welcome Screen-nel indulnak (ez az OOBE, out-of-box-experience). Ez az a rész, ahol felhasználót hozunk létre, időzónát állítunk stb. Ha ezen a részen Ctrl+Shift+F3 billentyűkombinációt nyomunk, akkor a gép újraindul úgynevezett audit módban (lásd a sysprep leírásában). Ilyenkor belép a helyi adminnal, és lehet még telepíteni, testreszabni. De mindig elindul a sysprep indulással, ezzel is jelezve, hogy ha végeztünk, akkor utána álljunk vissza az OOBE módba. A Settings to Use for Automating Windows Welcome rész mondja meg, hogy melyik beállításokat kell megadni az unattend.xml-ben, hogy átlépjük a Welcome Screent automatikusan.
- Az unattend.xml-ben a Package részen lehet elvileg eltávolítani komponenseket (pl. Sidebar), de nekem ez nem jött össze elsőre, tovább nem próbálkoztam ezzel.
Windows PE
Konfigurációs fájlok
Végül a CustomSettings.ini fájl, amit én használtam. Két lépés nem automatikus: az elején meg kell adni egy tartományi jelszót, amivel csatlakozunk a deployment share-hez, hogy bárki ne indíthassa el a telepítést. Utána pedig ki kell választani a Task Sequence-t, de ezután már csak akkor kell hozzányúlni, amikor bezárjuk a Deployment complete ablakot, és újraindítjuk az alkalmazásokkal ellátott, frissen Windows Update-et futtatott új operációs rendszert:-)
[Settings]
Priority=Default, MACAddress
Properties=MyCustomProperty
[Default]
OSInstall=Y
SkipAppsOnUpgrade=YES
SkipCapture=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipUserData=YES
SkipDomainMembership=YES
SkipTimeZone=YES
SkipBDDWelcome=YES
SkipApplications=YES
SkipSummary=YES
SkipBitLocker=YES
SkipLocaleSelection=YES
SkipComputerName=YES
KeyboardLocale=hu-HU
KeyboardLocalePE=040e:0000040e
UserLocale=hu-HU
UserID=mdtdeploy
UserDomain=ftslab
SLShare=\\deploy.ftslab.local\DeploymentShare$\Logs
SLShareDynamicLogging=\\deploy.ftslab.local\DeploymentShare$\Logs\%OSDComputerName%
[00:1C:25:BE:A4:19]
OSDComputerName=ITEC1
[00:1C:25:BE:33:B1]
OSDComputerName=ITEC2
A végén látszik, hogy a gépnevet is automatikusan a konfig fájlból veszi, MAC cím alapján (ha sok gépünk van, akkor érdemes ezt a részt adatbázisba kirakni, de nekem egyelőre elfért itt is).
Zárszó
Ebből a bejegyzésből is látszik, hogy azért nem egyszerű technológia és eszköztár ez. Ha rá tudjuk szánni a betanuláshoz szükséges időt, akkor viszont megéri. Így most sikerült elérni, hogy 3 adat megadásával az elején, nagyjából 45 perc alatt újra lehet húzni egy gépet.
Adott egy linuxos szerver, ami a benne lévő sok merevlemez tartalmát iSCSI-n keresztül ajánlja ki a többi szervernek, valamint egy Windows Server 2003 szerver, akinél a kiajánlott tárhely kezdett vészesen kevésnek bizonyulni. Nosza, gondoltuk, mivel volt még egy kis tartalék az iscsi-s gépben, megnöveljük az adott kötetet. Ám ez azért nem ment olyan simán, leizzadtunk közben párszor, volt néhány buktató:)
iSCSI kötet leválasztása
Először le akartam választani az iSCSI kötetet a windowsos gépen, hogy nyugodtan meg lehessen növelni. Azonban az iSCSI Initiator a következő hibaüzenetet adta:
The session cannot be logged out since a device on that session is currently being used.
Ki foghatja a kötetet? Process Explorer segítségével a Find handle.. parancssal könnyen meg lehetett találni a kötet betűjelére rákeresve. Bezárva azokat a programokat azonban még mindig nem lehetett kijelentkezni az adott iSCSI célról a kezdeményező programban. Az eseménynaplóban ennyi segítség volt:
Event Type: Information
Event Source: PlugPlayManager
Event Category: None
Event ID: 271
Date: 2009. 07. 21.
Time: 10:47:26
User: N/A
Description:
The Plug and Play operation cannot be completed because a device driver is preventing the device from stopping. The name of the device driver is listed as
the vetoing service name below.
Vetoed device: SCSI\DISK&VEN_IET_____&PROD_VIRTUAL-DISK____&REV_0___\1&2AFD7D61&0&000000
Vetoing device: STORAGE\Volume\1&30a96598&0&Signature89894C80Offset7E00Length3DCFC9AA00
Vetoing service name: FileSystem\Ntfs
Veto type 6: PNP_VetoDevice
When Windows attempts to install, upgrade, remove, or reconfigure a device, it queries the driver responsible for that device to confirm that the operation
can be performed. If any of these drivers denies permission (query-removal veto), then the computer must be restarted in order to complete the operation.
User Action
Restart your computer.
Túl sok opciót nem hagyott az újraindításon kívül:) Végül az összes távoli kapcsolatot lezárva és a konzolon belépve sikerült újraindítás nélkül is kijelentkeznem a célról.
Kötet megnövelése
Ezután Linux alatt az lvm-ben Dani gyorsan meg is növelte a logikai kötetet. Visszacsatlakoztattuk a windowsos szerveren az iSCSI kötetet, és akkor jött a második probléma: ez még csak Windows Server 2003 volt, és ott a Disk Managementben a grafikus felületen még nincsen Extend opció, nem lehet partíciót megnövelni. Azt sajnos elfelejtettem, hogy a diskpart.exe-t kell ilyenkor megnézni:
How to extend a data volume in Windows Server 2003, in Windows XP, in Windows 2000, and in Windows Server 2008
Úgyhogy helyette vissza a Linuxra, és ott a jó öreg fdisk elvégezte a partíció megnövelését. Igen, csak most volt egy 320 GB-os logikai kötetünk, rajta egy 320 GB-os elsődleges partíció, és azon egy 250 GB-os NTFS fájlrendszer:-) Az ntfsresize nevű program a segítőnk ilyenkor, azonban az nem látta a logikai köteten lévő fájlrendszert. Persze, hiszen a logikai köteten nem közvetlenül egy fájlrendszer, hanem még egy hagyományos partíciós tábla is van. Hogy lehetne rávenni a Linuxot, hogy a logikai kötetbe eldugott partíciókat külön blokkos eszközként kezelje? Dani és Zee elkezdett hevesen valami megoldás után kutatni (loopback device beállítása losetuppal és az offset kézi megadása), azonban amikor a következő mondat elhangzott – “… igen ilyesmivel a mútkor elég sok időm elment mire rájöttem, ez a script megcsinálta végül, csak előtte a teljes fájlrendszert tönkretette” – gyorsan elkezdtünk valami failback terven gondolkodni:-). Szerencsére sikerült megtalálni az alábbi KB cikket:
The partition size is extended, but the file system remains the original size when you extend an NTFS volume
A diskpart.exe-nek van egy extend filesystem opciója, amit nem ír ki a helpben, de működik rendesen. Visszacsatoltuk a kötetet a windowsos szerverre, az meglepő módon teljesen jól lekezelte, hogy a partíció 320GB-os, a fájlrendszer viszont csak 250 GB, majd utána a diskpart megoldotta a gondot azonnal. Innentől kezdve a fájlrendszer is 320GB-os volt. Most délután már el is kezdtük feltölteni a frissen allokált tárhelyet, érkezett 60 GB-nyi virtuális gép:-)
(Ez is az IRF házi kapcsán jött elő, az egyik hallgató kérdezte, hogy már megint miért van az, hogy a Microsoftnak sikerült egy általános szabványt Windows specifikusan implementálnia. Utánanézve aztán kiderült, hogy a helyzet nem is olyan egyszerű…)
A probléma a következő. A WinRM segítségével információkat kérdezhetünk le távoli gépekről a WS-Management szabványban definiált protokollt használva. Például ha a távoli gép általános adataira vagyunk kíváncsiak:
C:\>winrm enum wmicimv2/CIM_ComputerSystem -r:winxp-vm -u:administrator -p:password
Win32_ComputerSystem
BootupState = Normal boot
Caption = WINXP-VM
CreationClassName = Win32_ComputerSystem
Domain = WORKGROUP
...
Az enum (enumerate) kilistázza az adott ResourceURI-hoz tartozó osztály összes példányát a -r kapcsolóval megadott gépen. A ResourceURI-ban szépen a platform független osztálynevet (CIM_ComputerSystem) használtuk a Windows specifikus helyett (Win32_ComputerSystem), azonban az URI eleje még nem jó, a wmicimv2 alias Windows specifikus:
C:\>winrm help alias
Windows Remote Management Command Line Tool
Aliasing allows shortcuts to be used in place of full Resource URIs.
Available aliases and the Resource URIs they substitute for are:
wmi = http://schemas.microsoft.com/wbem/wsman/1/wmi
wmicimv2 = http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2
cimv2 = http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2
winrm = http://schemas.microsoft.com/wbem/wsman/1
wsman = http://schemas.microsoft.com/wbem/wsman/1
shell = http://schemas.microsoft.com/wbem/wsman/1/windows/shell
Ott van a cimv2, az látszik a szabványosnak, használjuk azt! No, itt kezdődnek a gondok:
C:\>winrm enum cimv2/CIM_ComputerSystem -r:winxp-vm -u:administrator -p:password
WSManFault
Message
ProviderFault
WSManFault
Message = The WS-Management service cannot process the request.
The service cannot find the resource identified by the resource URI and selectors.
Error number: -2144108544 0x80338000
The WS-Management service cannot process the request. The service cannot find th
e resource identified by the resource URI and selectors.
Az előbb még megvolt a CIM_ComputerSystem, most pedig nincs sehol. Ezzel az MS látszólag kilőtte annak a lehetőségét, hogy platform független scriptet írjak, hisz ha egy windowsos gépet akarok távolról lekérdezni, akkor a microsoftos prefixet kéne használni, és nem a dmtf-eset. Ez nem lenne szép dolog:) Elkezdtem utánanézni, hogy miért nem találja meg a CIM_ComputerSystem-et. A következő kapcsolódó leírások állnak rendelkezésre:
- DSP0226, Web Services for Management (WS Management): DMTF specifikáció a WS-Management protokollról. Csak a protokoll elemkészletét adja meg, a CIM osztályok lekérdezésével nem foglalkozik.
- DSP0227, WS-Management CIM Binding Specification: DMTF specifikáció, ez ad ajánlásokat, hogy hogyan kell kinéznie a ResourceURI-nak, ha egy CIM osztályt szeretnénk lekérdezni.
- MS-WSMV, Web Services Management Protocol Extensions for Windows Vista: a Microsoft specifikációja, hogy ők hogyan implementálták a WS-Management protokollt, mit változtattak esetleg rajta, mit implementáltak az opcionális részekből.
A MS-WSMV-t megfelelő részét nézegetve, vagy pl. ezt a blog bejegyzést olvasva (Accessing WMI data via WinRM) szemet szúrhat, hogy mi a gond:
All operations using the DMTF URI’s are defaulted by WinRM to the WMI namespace: root/hardware.
Így már érthető, a root/hardware alatt a különböző HW menedzsment szabványok (pl. IPMI) által kiajánlott adatok találhatóak, ilyen névtér Windows XP-n nincs is (WMI Explorerben ellenőrizhető), úgyhogy jogos a ResourceURI nem található hiba. A WinRM a Windows Hardware Management részeként jelent meg a WS2003-ban ha jól emlékszem, és gondolom ezért lett a root/hardware az alapértelmezett névtér. A többi WS-Management implementáció (pl. az openwsman) viszont a root/cimv2-t használja alapértelmezésként. Sajnos mindkettő megfelel a DMTF szabványnak, ugyanis a DSP0227 “5.3 Accounting for Different CIM Namespaces” része ennyit mond:
“The absence of this Selector in a message indicates the intended resource(s) is in the default CIM
namespace for that service. This specification does not define what the default CIM namespace should be.”
Tehát bárki azt használ alapértelmezettnek, amit akar:( Ugyanez a rész felhívja a figyelmet arra, hogy lehet névteret váltani egy ResourceURI-ban a __cimnamespace választó (selector) segítségével, de előtte még ki akartam próbálni, hogy mi van akkor, ha létezik a root/hardware névtér.
Ehhez egy Windows Server 2008 virtuális gépet kérdeztem le, amire a legfrissebb WinRM 2.0 CTP 3 volt telepítve:
c:>winrm enum cimv2/CIM_ComputerSystem -r:sicily
The result is:
WSManFault
Message
ProviderFault
WSManFault
Message = HRESULT = 0x80041001
Error number: -2147023537 0x8007054F
An internal error occurred.
Itt már megtalálta a root/hardware névteret, csak mivel ez egy virtuális gép volt, amiben nincsen értelemszerűen IPMI, nem tudta lekérdezni az ott lévő osztályok példányait. Azért ez az internal error nem túl beszédes:) Ezek a CIM osztályok vannak egyébként a root/hardware névtérben:
PS C:\> Get-WmiObject -list -namespace root/hardware | ? { $_.name -like "CIM*" } | select name | sort -property name
Name
----
CIM_Account
CIM_AdminDomain
CIM_AuthorizedPrivilege
CIM_Collection
CIM_ComputerSystem
CIM_ConcreteCollection
CIM_EnabledLogicalElement
CIM_Group
CIM_Log
CIM_LogicalDevice
CIM_LogicalElement
CIM_LogRecord
CIM_ManagedElement
CIM_ManagedSystemElement
CIM_NumericSensor
CIM_Privilege
CIM_RecordLog
CIM_RegisteredProfile
CIM_Sensor
CIM_System
CIM_SystemSpecificCollection
Vissza akkor az eredeti témához, próbáljuk névtér váltással lekérdezni a root/cimv2-ben lévő CIM_ComputerSystem-et szabványos URI-n:
C:\>winrm e http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ComputerSystem?__cimnamespace=root/cimv2 -r:192.168.255.128 -u:administrator -p:password
WSManFault
Message
ProviderFault
WSManFault
Message = The WS-Management service cannot process the request.
A DMTF resource URI was used to access a non-DMTF class. Try again using a non-D
MTF resource URI.
Error number: -2144108231 0x80338139
The WS-Management service cannot process the request. A DMTF resource URI was us
ed to access a non-DMTF class. Try again using a non-DMTF resource URI.
Na, ez volt a kedvenc hibaüzenetem:) Mi az, hogy nem DMTF osztályt akarok elérni, mind a prefix, mind az osztálynév DMTF specifikus! A CIM_ComputerSystem az egyik legalapvetőbb CIM osztály, és benne van az összes CIM specifikációban. Hosszas keresgélés után ez az apró félmondat segített (MS-WSMV, 3.3.5.1 ResourceURI for CIM classes):
Web Services Management Protocol Extensions for Windows Vista service and clients MUST use the http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/ namespace prefix followed by the class name when accessing DMTF classes. The classes in WMI are considered DMTF classes if they have a version qualifier with major number equal to 2.
Aha, tehát attól lesz a WinRM szerint egy WMI osztály DMTF osztály, ha 2-es a major verziószáma.
Gyors ellenőrzés wbemtest.exe-vel. A root/hardware-ben lévőknek van Version minősítője (qualifier), a root/cimv2-ben lévőknek nincs. Ha hozzáadjuk kézzel a Version minősítőt, akkor már megy rendesen a cimv2/CIM_ComputerSystem ResourceURI segítségével is a lekérdezés.
Tehát a következő két dolgot kell tenni, ha a DMTF-es prefixet akarjuk használni WinRM-ben:
- __cimnamespace segítségével átváltani a root/cimv2 névtérbe,
- a lekérdezendő osztályhoz a célgépen hozzáadni a Version minősítőt.
A problémát jelentettem a Connecten, az eredmény annyi lett, hogy bug-ot lezárták Resolved (External) eredménnyel egy napon belül, de még mindig privát, és semmit se írtak rá 2 hónapja:(
Zárásként térjünk vissza a nyitó kérdésre, hogy vajon az MS megint nem követi-e a szabványokat. A szomorú az, hogy a WinRM implementáció jelen esetben teljesen szabványos (a DMTF specifikáció nem ír elő alapértelmezett névteret), és a dokumentációnak megfelelően működik (megmondták, hogy akinek van 2-es Version minősítője, azt tekintik DMTF osztálynak), azonban a szabvány lazasága miatt mégis úgy tűnik elsőre, hogy nem követi a specifikációkat.
Az ntdebugging blogon volt most egy érdekes bejegyzés egy WMI hibakeresésről:
WMI: “REFERENCES OF” query failure during Provider startup could be disastrous
A cikk végigvezet azon, hogy hogyan épül fel a WMI, és hogy indulnak el a szolgáltatók (provider). A probléma oka is vicces, de nem lövöm le a poént:)
A keddi hivatalos magyarországi bejelentő után mától elérhető mindenki számára a VMware vSphere 4. Egy 60 napos próbaverziót lehet letölteni innen: VMware vSphere trial (meg is lepődtem, mert kedden még azt mondták, hogy most csak rendelést lehet rá leadni, és trial meg csak pár hét múlva lesz).
Egész gyorsan le is jött, többek között a következő fájlokat lehet leszedni:
- vSphere ESX 4: esx-DVD-4.0.0-164009.iso, 797 MB
- vSphere ESXi 4: VMware-VMvisor-Installer-4.0.0-164009.x86_64.iso, 340 MB
- vCenter Server: VMware-VIMSetup-all-4.0.0-162902.iso, 1,75 GB
Az induláshoz érdemes megnézni a vSphere Eval Guide leírást. Akinek ez nem elég, rengeteg dokumentáció van már kint a vSphere 4.0 documentation részen.
Fontos: csak 64 bites verzió van az új ESX-ekből.
Ha már itt voltak az ISO fájlok, gondoltam gyorsan meg is nézem, hogy eszik vagy iszák:-) Még végig kell gondolni, hogy melyik teszt szerverünket állítjuk majd át, de addig is kipróbáltam, hogy felmegy-e Workstationben. Csont nélkül felment, kb. 5 perc alatt már az ESXi sárga képernyője fogadott:
Én a következő beállításokat használtam:
- VMware Workstation, 6.5.2, other 64 bit, 2 CPU, 2048 RAM, LSI Logics, SCSI
- Telepítés után a Customize System résznél a root jelszót állítsuk be.
- (ha elszürkül a kép, akkor nem hiba van, hanem csak meg kell nyomni pl. a space-t)
- Kicsit lassan indul el a webes és a menedzsment felület, az ESXi elindulása után vagy 3-5 percet kell várni. F2-vel a helyi menübe be lehet lépni, az megy is rendesen, de a webes felület tök üres HTML oldalt adott vissza még vagy 5 percig.
Itt van néhány link, hogy hogyan lehet Workstationbe vagy akár ESX 4 alá telepíteni:
Miután elindult a webes felület, le lehet tölteni a vSphere Clientet. Ez feltelepülve lecseréli a régi VMware Infrastructure Clientet, a jó hír viszont az, hogy az új klienssel lehet csatlakozni a régi VirtualCenterhez.
Sok helyen lehetett már látni, de azért itt van még egy kép az új kliensről:
Még annyit próbáltam, hogy elindítok egy virtuális gépet (a jól bevált Nostalgia lett volna a kísérleti nyúl). Ez alapból nem támogatott (“You may not power on a virtual machine in a virtual machine” hibaüzenet), a fenti linkeken található meg, hogy a vmx fájlhoz hozzá kell adni a következő sort:
monitor_control.restrict_backdoor = "true"
Nekem viszont így se működött még, ezzel nem is indult el az ESXi. A fentiek az RC verzióra vonatkoztak, lehet, hogy a véglegesben mást is be kell még majd állítani.
Egyelőre ennyi, kell rendes tesztkörnyezetet találni majd hozzá, aztán ki lehet próbálni az új dolgokat. A következő félévben már remélhetőleg lehet majd ezt mutogatni a hallgatóknak:-)
UPDATE: a hibát nem sikerült reprpdukálnom utólag, és Daninak sikerült pusztán ennek az egy sornak a hozzáadásával otthon virtuális gépet is futtatnia, úgyhogy elvileg nem kell más az RTM verzióban sem.
|
