Misi bloggazda barátom kiváló cikket írt az LDOM-ok Veritas clusterbe való integrációjáról. A dolgok úgy alakultak, hogy munkám során hasonló környezetet kellett megtervezni és kialakítani. Az egyedüli különbség a magas rendelkezésre állást biztosító cluster alkalmazásban állt. Az igény ugyanis az volt, hogy ezt Oracle Cluster (régebben Sun Cluster) alkalmazással valósuljon meg.
LDOM Oracle (SUN) Cluster integráció
Az Oracle cluster-megoldását a Veritas-sal összevetve elmondhatjuk, hogy minden szermpontot figyelembe véve egyik sem több vagy jobb a másiknál, egyszerűen csak mások illetve előnye és htránya mindkettőnek van. A legnagyobb különbség talán a kettő közt, hogy míg a Veritas Cluster egy userland alkalmazás, addig az Oracle Clustere igencsak „mélyvénás” , kernel-szinten integrálódik rendszerünkbe telepítés után.
Vizsgáljuk meg, hogyan tudjuk egy megosztott storagen telepített LDOM-ot magas rendelkezésre állásúvá tenni – Oracle Cluster segítségével.
A cluster alkalmazás a két control domain szerveren van installálva természetesen, és leegyszerűsítve az lesz a feladata, hogy a két control domain között tudja kapcsolgatni a konfigurált és telepített LDOM-unkat. Az LDOM ill. a SUN Cluster telepítésre itt nem térnék ki: a bloggazda korábbi cikkei kellő mélységben taglalják ezeket: itt és itt.
Nézzük meg, hogy mi is fog történni!
Az elv:
- control domainek SAN-tól kapják a szükséges storage-kapacitást
- ezen ZFS volume-t hozunk létre
- az létrehozott ZFS volumet, mint root-disket adjuk oda az LDOM-nak
- a cluster a ZFS kötet ill. az LDOM „kapcsolgatását” végzi a control domain szerverek között
Itt megjegyezhetjük, hogy az LDOM-ok migrációja control domainek között az Oracle Cluster által teljes körűen támogatott: mind a HOT, mint a COLD migrationt támogatja; természetesen ennek mindenképpen feltétele a használni kívánt storage ill. annak választott fájlrendszerének helyes megválasztása, konfigurálása. Ennek fényében, mivel a mi esetünkben a használt fájlrendszer ZFS, ami NEM konkurrens módon használható (global) fájlrendszer, itt a COLD migráció kerül bemutatásra, mely az LDOM leállítása, migrálása, és céleszközön való elindítása lépéseket foglalja magában.
Lássuk, gyakorlatban hogyan is történik ez!
1., Az LDOM létrehozása
# ldm create testldom # ldm set-vcpu 2 # ldm set-memory 4g
2., A szükséges zpool és volume megkreálása, melyet majd az LDOM-ba telepített OS fog használni:
# zpool create rpool_testldom c9t60060E8016501E000001501E000001F9d0 # zfs create -V 20g rpool_testldom/testldom-rootdisk
3., Hozzáadjuk a létrehozott kötetet a virtual disk servicehez, majd hozzárdendeljük ezt az LDOM-hoz:
# ldm add-vdsdev /dev/zvol/dsk/testldom_rootpool/testldom-rootdisk testldom-rootdisk@primary-vds0 # ldm add-vdsdev /dev/zvol/dsk/testldom_datapool/testldom-datadisk testldom-datadisk@primary-vds0 # ldm add-vdisk testldom-rootdisk testldom-rootdisk@primary-vds0 testldom # ldm add-vdisk testldom-datadisk testldom-datadisk@primary-vds0 testldom
4., Létrehozzuk az LDOM hálózati interfészeit:
# ldm add-vnet testldom-adm adm-ABN-vsw testldom # ldm add-vnet testldom-sto sto-ABN-vsw testldom # ldm add-vnet testldom-cus cus-ABN-vsw testldom
5., Illetve a virtual consoleját:
# ldm set-vconsole port=5001 service=primary-vcc0 testldom
6., És végül néhány fontosabb változó beállítása:
# ldm set-variable local-mac-address?=true testldom # ldm set-variable autoboot\?=false testldom (mivel indítani a cluster fogja)
Itt meg kell állnunk egy fontos dolgot hangsúlyozni. Az adott LDOM-nak van egy fontos paramétere, amit „hostid„-nak hívunk. Ez egy egyedi azonosító, mely a control domainen ücsörgő LDOM-ot azonosítja és ugyancsak fontos tény, hogy az LDOM MAC-addresséből generálódik. A ZFS azonban, ha már importálva lett LDOM-on belül, ragaszkodni fog ehhez a hostid-hez. Ennek okán, amennyiben az LDOM-ot másik control domain-re migráltuk, nyilvánvalóan másik MAC-addressel fog ott megjelenni, ez eltérő hostid-t fog eredményezni, ennek pedig a legszomorúbb következménye, hogy az LDOM-on belül a zpool (itt a mi esetünkben a datapool-ból kreált fájlrendszer vagy volume) NEM fog importálódni, viszont kapunk egy, az alábbihoz hasonló hibaüzenetet.
Ez nekünk nem jó. Ám van rá megoldás is, ehhez azonban egy kis elméletre van szükség. Az Oracle, bölcsen, úgy döntött, hogy egy saját MAC-address tartomány foglal le és használ az LDOM-ok rugalmas konfigurálhatósága miatt. Ezek a következők:
00:14:4F:F8:00:00 ~ 00:14:4F:FF:FF:FF
Az alsó 256 ezer cím az ajánlás szerint az LDOM-ok AUTOMATIKUS MAC-cím allokációjára használatosak, ezeket manuális kiosztáshoz NE használjuk:
00:14:4F:F8:00:00 – 00:14:4F:FB:FF:FF
Az ezen felüli MAC-címek viszont kifejezetten a MANUÁLIS kiosztáshoz használatosak, ezekből sosem fog automatikusan osztani a control domain, tehát ezekből kézzel bátran oszthatunk, ügyelve természetesen arra, hogy ütközés ne történjen.
00:14:4F:FC:00:00 – 00:14:4F:FF:FF:FF
A megoldás tehát az, hogy az adott LDOM MAC-addressét kézzel konfiguráljuk, így biztosan lehetünk abban, hogy migráció esetén a másik control domainen is ezzel fog megjelenni.
# ldm set-domain mac-addr=00:14:4F:FE:00:01 testldom
Rendben is van. Van egy jól konfigurált LDOM-unk (tételezzük fel, hogy sikeresen teszteltük az LDOM migrációját a két control domain szerver között), mostmár szeretnék, ha magas rendelkezésre állású lenne, építsük tehát be a már feltelepített Oracle clusterünkbe.
Ehhez három resource-típust fogunk használni:
- SUNW.HAStoragePlus (HA Storage Plus)
- SUNW.ldom (HA for xVM Server SPARC Guest Domains)
- SUNW.gds (Generic Data Service, ezt a SUNW.ldom hívja majd meg)
Először is hozzunk létre egy resource-group-ot, mely a szükséges resource-okat fogja majd tartalmazni.
# clrg create -n ctrl-dom1,ctrl-dom2 testldom-rg
(Itt a ctrl-dom1 ill. ctrl-dom2 a control-domain szerverek hostnevei, a testldom-rg pedig a resource group neve).
A zpool-jainkat is kapcsolni kell, mivel egy adott zpool egyidőben csak egy helyen lehet importált állapotban, tehát szükség lesz két HAStoragePlus típusú resource-ra is.
# clrs create -g testldom-rg -t HAStoragePlus -p Zpools=rpool_testldom testldom-rootfs-rs # clrs create -g testldom-rg -t HAStoragePlus -p Zpools=datapool_testldom testldom-datafs-rs
(Itt a testldom-rootfs-rs ill. a testldom-datafs-rs a resource-nevek lesznek).
Végül pedig, hozzuk létre a resourcet, mely magának az LDOM-nak a control domainek közötti switchelését fogja lekezelni:
# clrs create -d -g testldom-rg -t SUNW.ldom -p Domain_name=testldom -p password_file=/root/pfile -p Resource_dependencies=testldom-rootfs-rs,testldom-datafs-rs -p Migration_type=NORMAL testldom-ldom-rs
Ez talán egy kis magyarázatra szorul. A password_file= /root/pfile nevű paramétere -az Oracle cluster ilyen irányú „butasága” miatt – tartalmazza azt a jelszót, ami a cél node-on a root user jelszava. Ez nem egy elegáns megoldás, de enélkül nem megy a dolog. A Veritas clusterhez képest viszont itt megmutatkozik egy előny is: NEM KELL az LDOM kidumpolt .xml fájlját konfigurálnunk, az Oracle Cluster ugyanis ezt intelligensen megteszi helyettünk és a /var/cluster/run/ könyvtárba menti, majd a továbbiakban ezt használja. A Migration_type=NORMAL felel meg a COLD típusú migrációnak, a Domain_name= paramétere pedig maga az LDOM neve, amit switchelni szeretnénk. Fontos paraméter még az Resource_dependencies=testldom-rootfs-rs,testldom-datafs-rs, ez azt fogja megmondani a resource-nak, hogy az LDOM-ot addig ne akarja migrálni, míg a szükséges tárterületet sikerrel át nem vitte a másik node-ra.
Egy nagyon fontos info, melyet csak azért írok le, mert nálam a megoldás másfél napot tolódott emiatt, míg rájöttem: az Oracle Cluster 3.3 és az LDOM 3.0 csomagok sajnos nem működnek együtt. Az LDOM 3.0 az LDOM 2.1-hez képest más visszatérési értéket prezentál, melyet az Oracle 3.3-as Clustere még -vagy csak simán –nem tud értelmezni, ezért hibával leáll migrációkor.
Ezek után a clusterünk képes az LDOM-ok magas rendelkezésre állását biztosítani.
Összegzés:
Az Oracle Cluster LDOM integrációja a Veritas-éhoz képest kevesebb is, több is. Az, hogy automatikus generálja az .xml-t, mely alapján az LDOM migrációja a cluster által vezérelt, illetőleg az, hogy a HOT migration-t is támogatja, mindenképpen nagy pozitívum. A jelszó fájl kényszerű megadása, melyet a másik control-domain node eléréséhez használ, viszont számomra eléggé fapados és kissé primitív módszert mutat. Mindezekkel együtt azonban egy stabil és jól működő magas rendelkezésre állású LDOM megoldás valósítható meg.
Update: tesztek alapján a COLD típusú migráció NEM igényli a superuser password-ot tartalmazú password file meglétét, így ezt a cluster SUNW.ldom resourceban sem kell kötelezően megadni.
