xivpath - pre-release

Ahogy az előző postomban is említettem dolgoztam egy kicsit egy 'xivpath' nevű datapath/pcmpath szerű programon, hogy egy kicsit megkönnyítsem a saját életemet az XIV adminisztráció kapcsán.
Nos.. A fejlesztés elérkezett a "pre-release" fázisba. Ebben a fázisban az általam megtalált hibák/bugok már javítva lettek, és nem tudok további olyan bugról, ami ténylegesen problémát tudna okozni, így elérkezettnek láttam az időt, hogy publikáljam a kódot (tekintve, hogy semmi confidential dolgot nem tartalmaz).
Amennyiben van XIV-s rendszere bárkinek, azt megkérném, hogy tesztelje a kódot, és amennyiben hibát talál bárhol, úgy vegye fel velem a kapcsolatot, hogy javíthassam azt.

Jah igen.. felhívnám a figyelmet arra, hogy a script csak Fibre Channel adapterekre lett felkészítve, mivel nem áll rendelkezésemre iSCSI-t használó kliens. Továbbá -remélem feleslegesen- kiemelném, hogy ez a script az XIV-s kliensekre lett készítve, így ha pl DS8K-n akarná valaki használni, akkor ne csodálkozzon ha nem azt kapja amit várt :)
Illetve a szokásos játék itt is fennáll: Ezt a scriptet én a saját kis szabadidőmben csináltam, ergo hivatalos support nincs rá, illetve az esetlegesen keletkezett kárért se tudok felelősséget vállalni, így tessék tisztességesen egy teszt környezeten tesztelgetni első körben (azért arra felhívnám a figyelmet, hogy a scriptnek elvileg nem szabadna semmiféle kárt okoznia, de sose lehet tudni :))

Update: Kicsit hivatalos formába öntöttem a dolgot, és felraktam a csomagot az alábbi címre:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/glukacs/resource/xivpath.tar.zip

SDD,SDDPCM,XIV - Connection azonosítók..

Elkezdtem dolgozni az XIV-s scriptemen (amit még az előző postomnál megemlítettem) és úgy gondoltam, hogy milyen jó is lenne, ha kb úgy működne a script, mint az SDD/SDDPCM pcmpath/datapath parancsa (egy vezérlő parancs, amivel mindent administrative taskot szépen meg lehet csinálni).
Megyeget is szépen a fejlesztés (első körben még csak a query parancsok), és el is jutottam a 'query essmap' részhez, ahol is le lehet kérni a connection detaileket (az adott LUN melyik SAN Rack, melyik Module, melyik portján közlekedik felénk - hasznos kis információ hibakeresés esetén)..
Ez ugye pcmpath/datapath alatt valahogy így néz ki:

test_server@root:/ # datapath query essmap|head -3
Disk Path P Location adapter LUN SN Type Size LSS Vol Rank C/A S Connection port RaidMode
------- ----- - ----------- ------ ----------- ------------ ---- ---- --- ----- ---- - ----------- ---- --------
vpath0 hdisk6 6p-08-02[FC] fscsi3 xxxxxxx0400 IBM 2107-900 32.8GB 4 0 0004 29 Y R1-B3-H1-ZA 200 RAID5

Ami nekem ebből kellett az az 'R1-B3-H1-ZA'. Ugyan ezt akarom én is megvalósítani az XIV-s scriptem 'query essmap' részénél.. Na de nézzük hogyan...
Mint kiderült - ezt is ki lehet bányászni ODM-ből (CuPath alatt connection attributum utolsó 3 karaktere), de sajna ezt már nem lehet 1 az 1ben konvertálni ahogy néztem (vagy csak még nem jöttem rá pontosan hogyan).
Sebaj mondom, az XIV is nagyban épít az MPIO-ra, ahogy az SDDPCM is, annak meg van pcmpath parancsa, ami ezeket az infókat gyönyörűen kiadja, úgy hogy akkor induljak ki abból, nézzük össze az adatokat, és akkor az alapján dolgozzunk.

Némi kis keresgélés után kiderült, hogy SDDPCM alatt ugyan úgy a CuPath alatt kell keresni az adatokat, csak ott nem a végén, hanem kicsit máshol, de ugyan úgy megvan. Így aztán elkezdtem írni egy kis scriptet ami ezeket összegyűjti nekem, és amiből aztán majd egy kedves kis mátrixot csinálhatok, hogy mi és merre..
Aztán ahogy gyűltek az adatok észrevettem, hogy ugyan ezen kiosztás érvényes az SDD esetében is és ott meg a datapath alatt ugyan úgy elérhetőek ezek a Connection infók, szóval kicsit kibővítettem a scriptem, hogy lekezelje az SDD-os ODM bejegyzéseket is (ez kivételesen már a CuAt alatt van) és összeszedtem amit tudtam.

Az eredmény: Egy egész kellemes kis script:

#!usr/bin/ksh
SDDPCM=0
SDD=0
export ODMDIR=/etc/objrepos
if [ `lslpp -l |grep -wc devices.sddpcm` -gt 0 ]
then
SDDPCM=1
MAIN_COMMAND="pcmpath"
fi

if [ `lslpp -l |grep -wc devices.sdd` -gt 0 ]
then
SDD=1
MAIN_COMMAND="datapath"
fi

$MAIN_COMMAND query essmap > /tmp/$MAIN_COMMAND.query.essmap
for i in $(awk '{print $14}' /tmp/$MAIN_COMMAND.query.essmap |sort|uniq |grep ^R);do grep -w $i /tmp/$MAIN_COMMAND.query.essmap |head -1;done |awk '{ sub("path", ""); print $1,$2,$14}' > /tmp/connection.check

while read LINE
do
if [ $SDDPCM -eq 1 ]
then
set -A array $LINE
DISK=$(print ${array[0]})
CONN_PATH=$(print ${array[1]})
CONNECTION=$(print ${array[2]})
# In case of SDDPCM 11-13 contain the right identifiers in CuPath
CONN_IDENTIFIER=$(odmget -q "name=$DISK and path_id=$CONN_PATH" CuPath|awk -F "\"" '/connection/ {print $2}'|cut -c 11-13)
elif [ $SDD -eq 1 ]
then
set -A array $LINE
DISK=$(print ${array[1]})
CONNECTION=$(print ${array[2]})
# In case of SDD
CONN_IDENTIFIER=$(odmget -q "name=$DISK and attribute=ww_name" CuAt|awk -F "\"" '/value/ {print $2}' |cut -c 13-15)
fi

echo "$CONN_IDENTIFIER - $CONNECTION"
done < /tmp/connection.check

Illetve egy kellemes kis mátrix, amit használni tudok:

000 - R1-B1-H1-ZA
004 - R1-B1-H1-ZB
008 - R1-B1-H1-ZC
030 - R1-B1-H3-ZA
034 - R1-B1-H3-ZB
038 - R1-B1-H3-ZC
080 - R1-B2-H1-ZA
084 - R1-B2-H1-ZB
088 - R1-B2-H1-ZC
0b0 - R1-B2-H3-ZA
0b4 - R1-B2-H3-ZB
0b8 - R1-B2-H3-ZC
100 - R1-B3-H1-ZA
104 - R1-B3-H1-ZB
108 - R1-B3-H1-ZC
130 - R1-B3-H3-ZA
134 - R1-B3-H3-ZC
138 - R1-B3-H3-ZC
180 - R1-B4-H1-ZA
184 - R1-B4-H1-ZB
188 - R1-B4-H1-ZC
1b0 - R1-B4-H3-ZA
1b4 - R1-B4-H3-ZB
1b8 - R1-B4-H3-ZC
200 - R1-B5-H1-ZA
204 - R1-B5-H1-ZB
208 - R1-B5-H1-ZC
230 - R1-B5-H3-ZA
234 - R1-B5-H3-ZB
238 - R1-B5-H3-ZC
280 - R1-B6-H1-ZA
284 - R1-B6-H1-ZB
288 - R1-B6-H1-ZC
2b0 - R1-B6-H3-ZA
2b4 - R1-B6-H3-ZB
2b8 - R1-B6-H3-ZC
300 - R1-B7-H1-ZA
304 - R1-B7-H1-ZB
308 - R1-B7-H1-ZC
330 - R1-B7-H3-ZA
334 - R1-B7-H3-ZB
338 - R1-B7-H3-ZC
380 - R1-B8-H1-ZA
384 - R1-B8-H1-ZB
388 - R1-B8-H1-ZC
3b0 - R1-B8-H3-ZA
3b4 - R1-B8-H3-ZB
3b8 - R1-B8-H3-ZC

Na mondom éljen.. Megvan minden szépen ahogy kell.. Nézzük ezt össze az XIV-s kapcsolatokkal.. És kopp - XIV alatt jóvolta több kapcsolat van, mint amiket én kigyűjtöttem, ami azt jelenti, hogy ez a mátrix max részben használható jelenleg..
Most bújom a DS8000 és az XIV Architecture guide-jait, hogy megnézzem milyen durva különbségek vannak még amiről tudnom kéne :)))

Stay tooned :)

Szerk:
na végül erre is fény derült :))
- > DS8000 series alatt a Bay1-8 az a DS hátán elhelyezett I/O enclosure-öknek felelnek meg (SG246452 PDF 44. oldal), míg XIV esetében ez kicsit másként néz ki: Igaz, hogy jóvolta több kapcsolódási lehetősége van, viszont Fibre kapcsolatra csupán 6 I/O module-ja van (SG247659 PDF 81. oldal) amelyek számozása Module 4-9ig tart (ergo Bay1-4 variáció itt totál kiesik). Minden module rendelkezik 4-4 portal kapásból, amiket aztán rá lehet kötni a közeli Fibre switchre.
Ez után viszont akkor ez azt jelenti, hogy az SDD/SDDPCM-nél megszokott konnekciós ábrázolás bukott, helyette valami ilyesmi használható XIV esetén:

test_server@root:/ # odmget -q name=hdisk3 CuPath |awk -F "\"" '/connection/ {print $2}' |cut -c 14-16 |sort|uniq |head -1
140

Ergo jelen esetben akkor ez a kapcsolat a Rack 1, Module 4 1. portjáról jön ( az ODM-ben a számozás 0-3ig van, az XIV-n meg 1-4ig, ergo ott azt 1el kell növelni), tehát a nevezéktan valami ilyesmi lehetne:
R1-M3-C1
(Az SDD/SDDPCM query essmap outputja végén lévő ZA/ZB/ZC/ZD(?) elvileg a Fabric-et jelöli. Annak még megpróbálok utánajárni, hogy kinyerhető e valahogy :)

XIV_ID-k és XIV_LUNID-k

Te hogy kérdezed le egy XiV-ról kapott LUN ID-ját, illetve, hogy melyik XiV-ról is jön az adott LUN?
Nos.. Az alapvető válasz egyszerű: A HAK csomagon belül elérhető az xiv_devlist parancs, amit megfelelően felparaméterezve ('xiv_devlist -o all', vagy 'xiv_devlist -v') kidobja nekünk az összes XIV-hez csatolt LUN információját, abból meg kedvünk szerint szűrhetünk grep-el, awk-al, akármivel.. Nincs is ezzel baj.. Na jó... egy kicsi még is - ez a módszer iszonyat de lassú (de legalább színes),főleg ha scripteléshez is szeretnénk valamely adatot használni, arról ne is beszéljünk mi van akkor, ha sok diszkünk van az XiV-hez csatolva (lassú == csiga)
Úgy hogy kicsit elkezdtem turni, hogy hogy is lehetne ezt sokkal gyorsabban megvalósítani.. Nos.. VAN MEGOLDÁS.. Bár jól eldugták..
Az utat ahogy eddig eljutottam nem írom le (legyen elég annyi, hogy szívatós, főleg ha rászámolom, hogy a nyomozás egyik szakaszában a teljes rootvg-t végiggreppeltem az adott string után kutatva :)), úgy is inkább az eredmény érdekli az embereket..
Akkor lássuk hát:
Alapjáraton megszoktam, hogy mind SDD,SDDPCM,MPIO drivereknél az adott LUN ID-ja kinyerhető az ODM-ből.. Erre szolgál ugyan is az unique_id attributum (odmget-el, vagy lsattr-al lekérhető). XiV-s diszknél (hiába támaszkodik félig meddig az MPIO-ra) ez mintha mégse lenne így meg (az elején legalább is nagyon nem így tünt). De nézzük meg közelebbről ezt a stringet..

# odmget -q "name=hdisk10 and attribute=unique_id" CuAt |awk -F "=" '/value/{print $2}'
"261120017380005660F32072810XIV03IBMfcp"

Annyit tudtam alapjáraton is, hogy a LUN-om a 6001382-ös XiV-ről jön, illetve hogy a LUN ID-ja 3890:

# xiv_devlist |grep -w hdisk10
/dev/hdisk10 34.4GB 18/18 Vol1 3890 6001382 test_server

Az adott ODM attributumban persze semmi hasonló nincs.. Egészen addig amíg az ember el nem kezdi boncolgatni.. Mint kiderült: Ott van az.. Csak nézzük kicsit másként azt a stringet:
261120017380005660F32072810XIV03IBMfcp
Na akkor mit is bányászhatunk ki:
0566 - Ez az XiV boxunk azonosítójának utolsó 4 jegye (jelen esetben) hexában tárolva -> 1382
0F32 - Ez pedig a LUNID-nk szintén hexában tárolva -> 3890
/* Azt majd még meg kéne nézni, hogy a 0-ák a string elején mennyire konstansak, de jelen esetben nálam erre nem volt szükség */
Ergo akkor némi kis scripteléssek ki lehet szedni az aktuális azonosítókat, immár kifejezetten gyorsabban:

#!/usr/bin/ksh
DISK=hdisk10
UNIQUE_ID=$(odmget -q "name=$DISK and attribute=unique_id" CuAt |awk -F "=" '/value/{print $2}')
XIV_ID=$(echo "600$(echo "ibase=16; $(echo $UNIQUE_ID|cut -c 15-18)"|bc)")
XIV_LUNID=$(echo "ibase=16; $(echo $UNIQUE_ID|cut -c 19-22)"|bc)

#Edit:
Az ODM entry-ben lévő '2810XIV' utal arra, hogy XiV-s LUN-ról van szó. Ugyan ez DS8k box esetében is megtalálható, csak akkor a '2107900'-es stringre kell figyeljünk

XIV client / lsxiv command issue.

Nézegettem google-n, de 0 találat volt erre az issue-ra, szóval gondoltam leblogolom a megoldást :)
Na szóval. Ha valaki abban a "szerencsében" részesült, hogy XiV-s Storage-ot kell használnia, és ne addj isten az alábbi hibaüzenetet kapja a kliens oldalon:

# lsxiv -v
XIV Non-MPIO ODM device entries are inconsistent for hdisk0. Please contact your IBM service representative to reinstall the XIV support packages.

reinstall a jó anyját, helyette nézzük meg hogy az adott disk alatt a scsi_id nem e duplikálódott:

# lsattr -El hdisk0 |grep -c scsi_id
2

Tehát de... Ez viszont azt jelenti, hogy az ODM-ünk valószínű nem épp normális, úgy hogy kicsit nyomozzunk a PdAt körül, mivel ez felel a listázandó attributumokért..

# odmget -q "uniquetype = 'disk/fcp/mpioosdisk' and attribute=scsi_id" PdAt |grep -c scsi_id
2

Első lépés: backup, mert ha valamit mégis elbaxnánk, akkor azért legyen visszalépési lehetőség :)

# tar -cvf /tmp/odm.tar /etc/objrepos /usr/lib/objrepos /usr/share/lib/objrepos

Második: Kérjük ki a jelenlegi beállításokat, és mentsük egy temporális file-ba

# odmget -q "uniquetype = 'disk/fcp/mpioosdisk' and attribute=scsi_id" PdAt > /tmp/PdAt.new

Szerkesszük meg kedvenc text editorunkal (vi) az újonnan létrehozott file-t, és szedjük ki a duplikált entry-ket, majd indítsuk a dózert:

# odmdelete -q "uniquetype = 'disk/fcp/mpioosdisk' and attribute=scsi_id" -o PdAt
0518-307 odmdelete: 2 objects deleted.

Ha a gyalu megvolt, akkor az immár jó adatokat töltsük vissza a helyére, majd ellenőrizzük le ismételten a dolgot

# odmadd /tmp/PdAt.new
# odmget -q "uniquetype = 'disk/fcp/mpioosdisk' and attribute=scsi_id" PdAt |grep -c scsi_id
1

Nagyszerű.. Akkor most futassuk ismét az lsxiv-t :)
# Megjegyzés: amennyiben az unique_id lenne duplikáltan, akkor "XIV ODM device entries are inconsistent ..." hibaüzit kapjuk btw..