2010. november 29., hétfő

AIX - VG varyon failed.. - Avagy amikor Murphy nagyot mosolyog..

Na de vajon miért.. (költői kérdés).. avagy - ez az a helyzet, amibe nem szívesen kerülök, mint system admin (amúgy sikerült megoldani, csak gondoltam postolom ezt is :))
# > lspv |grep -w hdisk10
hdisk10 00c3f43e8eff2532 None
# > readvgda hdisk10 |grep pv_id
pv_id: 00c3f42e99549e58
pv_id: 00c3f42e99549fef
pv_id: 00c3f42e9954a259
pv_id: 00c3f42e9954a3ee
pv_id: 00c3f42e9954a587
pv_id: 00c3f42e9954a716
pv_id: 00c3f42e9954a982
pv_id: 00c3f42e9954ab07
pv_id: 00c3f42e9954ad78
pv_id: 00c3f42e9954aeff
pv_id: 00c3f42e9954b162
pv_id: 00c3f42e9954b2f1
pv_id: 00c3f42e9954b47c
A szitu az volt, hogy kb 150 diszk keringőzött a gépen, amiből mint fentebb látható 13 egy VG-hez tartozott.. Sajna a gépen -nem részeletezem miért - az összes diszk PVID-ja törölve lett (kiv a rootvg-hez tartozók), ergo a VG-ket a VGDA adatok alapján kellett helyrevágni.
A dolog pikantériáját az adta, hogy a readvgda/lqueryvg segítségével meg tudod nézni melyik diszk mely diszkkel volt közös VG-n belül (vgda-n belül a vg_id sokat tud ebben segíteni), viszont ez után még 2 problémával szembe kell nézz:
- Az 1ik az, hogy a PVID-kat attól még vissza kéne rakni (VGDA-ba nem írunk), különben a VG-t az istennek se lehet varyon-olni
- A másik az, hogy az embernek figyelnie kell arra is, hogy a megfelelő PVID-t a megfelelő diszkre írja vissza (az, hogy még mondjuk fél napja -hasraütök- a hdisk10es az XY PVID-t bírtokolta, az még nem jelenti azt, hogy az a hdisk10 ugyan az a hdisk10 amit most látsz, ergo nem lehet benne biztos, hogy az XY PVID-t erre a diszkre kell visszaírd..
Az első problémára a megoldás kicsit vicces... A PVID fizikailag tárolódik a diszken, így azt felül lehet vágni egy mókásan felparaméterezett dd-vel .. a módszer kb így néz ki:
#!/usr/bin/ksh
pvid=$1
disk=$2
set -A a `echo $pvid|\
awk ' {
for (f=1; f <= length($0); f=f+2) {
print "ibase=16\nobase=8\n"toupper(substr($0,f,2))
}
}'|\
bc 2>/dev/null`
/usr/bin/echo "\0"${a[0]}"\0"${a[1]}"\0"${a[2]}"\0"${a[3]}"\0"\
${a[4]}"\0"${a[5]}"\0"${a[6]}"\0"${a[7]}"\0\0\0\0\0\0\0\0\c"|\
dd bs=1 seek=128 of=/dev/$disk
A 2. probléma már gázosabb.. megvan, hogy mely 13 diszk van benne a VG-ben (sőt még a VG nevét is tudjuk valahonnan), de attól még nem tudjuk melyik diszk melyik PVID-t kéne birtokolja.. Nos.. ez az a pont, ahol a jól dokumentált rendszer csak a jó rendszer - előkaptam a régi doksikat, és a LUNID-k alapján (vagy lokál diszk esetén lokációs adat alapján) összerendezhető, hogy minden diszk az e akiről tudjuk.. Ha ez megvan, akkor a fentebb leírt módszerrel a megfelelő PVID-k visszavarázsolhatók a megfelelő diszkekre, és ismét lehet varyon-olni..

2010. november 23., kedd

AIX CSM cluster - szinkronizációs problémák

Tünetek:
- 'cfmupdatenode -v -n [nodename]' esetén az alábbi hibaüzenetet kapjuk:
"cfm_local: 2657-259 No hostname or ip address to which the files are being sent matched the local hostname or ip address"
- A node az 'lsnode -p' szerint alive állapotban van
- A CW és a node is jól (!) fel van véve a /etc/hosts-ban
- Név feloldás, és kommunikáció a node-CW között szépen megy
- Az összes szükséges subsystem fut, ahogy kell
- Latest (1.7.1.7) CSM client telepítve
- Node újradefiniálás nem segít.
- A CW-node szinkronizáció az istenért se akar menni ( a CSM beállítások a CW-n garantáltan jók )
Kis utánajárás után (illetve a /opt/csm/csmbin/cfm_local script analizálását követően) az alábbi hibaüzenet 2 eshetőség esetén jöhet elő:
- A generált /var/opt/csm/cfmlocal/.runclocal file-ban a file-ok/mappák végén nincs nodename megadva, csupán egy randa CFM_MODE_CFM=
- A feloldott hostname, vagy IP cím nem egyezik a file-ban talált hostname-el, vagy feloldott IP címmel.
Jelen esetben a hostname fel volt sorolva (ha valaki utána akarna nézni, akkor 'export CSM_CFM_DEBUG=1 cfmupdatenode -v -n [nodename]'), így visszanéztem hogy is nézi vissza a gyógyegér a hostnevet:
/usr/bin/lsrsrc-api -i -s IBM.ManagementServer::"ManagerType='CSM'"::LocalHostname
Jelen esetben ez volt a gázos - Az itt található hostname a HMC-hez kellett volna tartozzon.. Így hát persze hogy nem volt jó.. Na de akkor mi van a HMC-nél??
/usr/sbin/rsct/bin/lsrsrc IBM.ManagementServer
Hopp.. Semmi.. Csak CSM-hez volt bejegyezve.. Mit utólag kiderült ennek az az oka, hogy a node definiálásakkor még jó IP-t/nevet vesz fel, de ha a HMC-s classhoz nincs semmi definiálva, akkor azt a gép hajlamos felülvágni.. Na akkor hozzuk ezt helyre:
Konfoljuk újra az RSCT-s cuccokat from scratch:
/usr/sbin/rsct/install/bin/recfgct
Engedélyezzük újra a távoli RSCT konneckiókat:
/usr/sbin/rsct/bin/rmcctrl -p
# Most várunk 1-2 percet, míg az RSCT észre veszi magát, és a HMC-s kapcsolatot visszaépíti.. /usr/sbin/rsct/bin/lsrsrc IBM.ManagementServer-vel nézzük, hogy visszajött e már.. (Amíg nem jött vissza ne definiáljuk újra a node-ot, mert az updatenode meg fogja hülyíteni az egészet ismét )
Definiáljuk újra a node-unka:
rmnode, definenode, updatenode
És ne felejtsük el a CSM group-ba bevenni az újra definiált node-ot!
Hállelújja... 4,5 órányi nyomozás eredménye :)
Szerk: Egy kis finomítás a node újradefiniálás előtt
Szerk2: Ha valaki ne adj isten azt tapasztalná, hogy az újra definíció után rövid idővel a CSM-hez tartozó entry ismét a HMC IP-jét viseli (ergo a probléma ismét előállt), az frissítse fel a csm.client-et 1.7.1.7-re! (ahogy nézem az alap issue 1.7.1.6-nál jött elő)

2010. november 18., csütörtök

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..