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ő)

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

Hátlapát...

.. annak a baromnak aki ezt a szerver design-t kitalálta (avagy architect epic fail)
Adott egy Power6os box (p570), amelyen a következő setup-ot alkották meg az "okosok":
- Mivel a gép bírja, így pakoltak bele egy csomó diszket meg 1-2 SAS RAID controllert, mert miért ne.. Fiber Channelt persze minek..
- A gépen létrehoztak 2 VIO szervert, ahogy az a nagy könyvben meg van írva.. Egyedül annyi a gáz, hogy valszeg a nagy könyv első 20 oldala lehet csak meg, mert se a network-ot, se a storage-ot, de még a VIO-kat se csinálták redundánsra!
- Na de akkor minek a VIO - Fogták a 2 VIO szervert, majd 1-1 RAID controllert hozzájuk rendeltek. A gépben lévő megannyi szép nagy vinyókat meg pdiskenként bebaxták egy 1-1 nagyobbacska RAID5 tömbbe
- Ebből következik, hogy mint redundancia olyan nincs, mert a RAID kártyákat nem lehet több LPAR-hoz is hozzárendelni, ergo innentől van 2 külön VIO-nk 2 külön RAID5 tömbbel.. Na de mire kell ez?
- A megoldás egyszerű: Fogták magunkat, létre hoztak egy nagy VG-t a RAID tömbben, majd a VG-n belül létrehozott LV-ket Virtual Diszkként kiosztották az LPAR-oknak, hogy azok boldogan magukévá tehessék az immáron új diszkeket.. A probléma persze csak az, hogy mivel a RAID tömbök VIO-nként egyediek, így véletlenül se tudjuk ugyan azt a kiosztást megcsinálni mind2 VIO-nál, ergo a Virtual diszkek csak az 1ik VIO-n keresztül érhetőek el => A 2 VIO csak külön-külön LPAR-okat tud kiszolgálni!
Problémák ezzel a felállással:
- Nehezen bővíthető: Ha elfogy a RAID5 alól a hely, akkor aztán így járás, mert egy idő után a diszkek is elfogynak
- Mivel RAID5ről beszélünk, így a teljes RAID tömbben csak egy VG van. Ennek annyi előnye van, hogy 1 LPAR gond nélkül el tudja vinni a teljes kapacitást a többi elől, ha ő úgy akarja (és mivel applikáció is fut rajta, így persze, hogy úgy akarja )
- Redundancia mint olyan sehol nincs, sőt nem is nagyon lehet úgy átépíteni a rendszert, hogy legyen (az alapoktól újra kéne építeni).
- A vicc kedvéért az LPAR-okhoz használható NIM szerver ugyan azon boxon belül található, mint az LPAR-ok, így aztán komolyabb HW failure esetén (lehal a box) esélye nincs bárkinek is restore-olni az LPAR-okat..
- MINEK MINDEHHEZ VIO????