Sun Cluster 3.2

A Sun a saját operációs rendszeréhez természetesen ajánlj saját megoldást a magas rendelkezésre állás (High Availability) biztosítására. Ez a termék a Sun Cluster. A Sun Cluster mondhatni harmadik generációját éli. A 3.0-s verzió talán még nagyon kezdeti próbálkozásnak számított. Ezek után a 3.1 viszont egy teljesen kiforrott és eszközrendszerében az üzleti igényekhez megfelelő szolgáltatást nyújtott. Ez terjedt el rengeteg helyen, és a bár már nem számít újnak, mégis sok helyen találkozni vele. Majd jött az újragondolt 3.2-es verzió. Meghagyták a 3.1 tudását, viszont felvértezték az újdonsült igényekkel, és a parancs konvencióját igazították az új Solaris 10-ben megszokott élményhez. A következőben a Sun Cluster 3.2 struktúrájába, előnyeibe és használatába kívánom elkalauzolni a kedves olvasót.

A cluster maga egy csoportot azonosít. A Clusternek van egy neve, és definiálva vannak a tagjai. A tagokat általánosságban NODE-nak szokás hívni. Így szokás egy szempont szerint definiálni azt, hogy hány node-s clusterről beszélünk. A 2 node-s cluster esetén két különálló rendszer alkotja a clustert.

Bár funkció szempontjából nincs értelme egy node-s cluster-ről beszélni, mégis előfordulnak. Az egy node-s cluster esetén inkább beszélhetünk arról, hogy a rendszer már fel van készítve a lehetőségre, hogy másik node-al bővítsük leállás nélkül. Ugyanis ha egy (sima) single system számára nem előkészített rendszerből akarunk cluster tagot varázsolni, ott leállással, és szolgáltatáskieséssel kell számolnunk. Míg ha már kezdet kezdetén clusterként indult a gép, gond nélkül, online tehetünk új node-t. Így előre látó és fejlődő rendszerek esetében már egy node esetén is cluster kerül kialakításra.

Cluster Topológiák

Tehát egy cluster szolgáltatással bíró rendszerben kettő vagy több node-ból álló rendszert kell építenünk. Ezt több féle képen is megtehetjük:

• Clustered pairs
• Pair+N
• N+1 (star)
• N*N (scalable)

Részletes bemutatás olvasható ezekről itt.

A legtöbb üzleti rendszerben a teljes redundancia miatt a következő cluster topológia használatos, és a továbbiakban én is ezt fogom hivatkozni.

A Sun cluster filozófiája azt az elvet követi, hogy minden, tényleg minden eszközből kettő legyen, illetve teljesen megkerülhető legyen azon a szinten egy meghibásodás. Ezért a Sun Cluster topológiája megköveteli a dupla tükrözött storage meglétét, illetve ezt kiválthatjuk azzal, ha egy storage-t használunk, viszont azt multipathing-al (több független vonalon keresztül is kommunkálnak az adott elemek) látjuk el. Ezen túl legalább két független hálózati csatlakozásnak kell lenni node-k között. Ezen kapcsolatok fognak heartbeat-ként funkcionálni. A node-k ezen keresztül fognak egymás között kommunikálni, a másik státuszát ellenőrizni, és cluster számára belső információként szolgáló adatokat cserélgetni. Ez a vonal amennyiben nem dedikált, úgy lehetőség van titkosításra is, ezen interconnect vonalak esetében.

Ezen túl szükséges még, hogy a clusterek a külső hálózat fele is nyitottak legyenek. Ez bár nem megkövetelt feltétlenül, de erősen ajánlott, hogy külső kapcsolatból node-nként párba legyenek szervezve a külső vonalakat biztosító hálózati interface-k. Ezeket úgynevezet IPMP groupoknak nevezzük, de erre majd még később vissza fogunk térni.

Rendszerkövetelmény és telepítés

Először is nézzük milyen rendszerekre telepíthetjük a cikk írásakor legfrissebben elérhető Sun Cluster 3.2-es cluster software-t:

Solaris OS verzió (minden node-nak ugyan azzal a verzióval kell, hogy rendelkezzen):

• Solaris 9 OS 8/05 Update 8 (SPARC)
• Solaris 10 OS 11/06 (update 3) vagy későbbi (SPARC és x86)

Veritas Volume Manager verzió:

• Veritas Volume Manager 4.1 (Sparc és x86)
• Veritas Volume Manager 5.0 (Sparc)

Solaris Volume Manager verzió:

• Az alap Solaris 9 vagy 10 rendszer részét képező bármelyik SVM

Mag a Cluster software külön érhető el, és külön telepítendő. Attól viszont, hogy külön programként van jelen, telepítés után nagyon is kernel szinten fog beépülni a rendszerünkbe. Ahonnan azután már nem nagyon lehet külön eltávolítani.

Maga az installáció elég interaktív, egyértelmű kérdésekre kell a megfelelő válaszokat kiválasztani egy menüben. Lehetőségünk van már az elején több node-s cluster-t installálni egyszerre, illetve először csak egy node-sat telepíteni, és utána a többi node-t hozzáadni később. Mivel ezt a technikai leírások megfelelőképp bemutatják, én bele se mennék, csak hosszadalmas lenne.

Did device, Global Filesystem

Már az installáció közben is fel fog merülni néhány új kifejezés, amit a Cluster működése maga vezet be. Mivel több különálló rendszer saját elnevezéseket használ, így a cluster-nek ezt valahogy egységesítenie kell. Főleg a storage device nevek esetében fontos ez. Ez a központosított név rendszer a Did Device. Egy Did Device egy clusterben egyértelműen azonosít egy node-n lévő disk-et. Amennyiben ugyan az a disk (közös storage) több gépről is elérhető, és értelem szerűen lokálisan más más nevük van, nehezen lehetne ezt a cluster-rel lekezelni, illetve ez a kesze-kusza feladat is az adminisztrátorra várna. Mivel viszont van DID device szolgáltatásunk ez a sok lokális disk neve helyett egy-egy DID device fogja ezen elemeket képviselni a cluster-ban, és elég azt hivatkoznunk, a cluster majd tudni fogja hogy jusson el hozzá. Fontos megjegyezni hogy DID device név minden, tehát lokális diskek-hez is létre fog jönni.

Amennyiben már a Did Device-ok révén tudunk azonosítani cluster-ben disk-eket, már csak filerendszereket kell tudnunk kezelni cluster-ben. Ennek a problémának a megoldására született meg a global filesystem. Ez gyakorlatilag azt jelenti, hogy egy bizonyos filerendszer a cluster minden egyes tagjára felmountolódik, egy azon időben. Természetesen nem arra kell gondolni, hogy minden node saját maga direkt mód fér hozzá a diskhez, és maga mountolja fel a filesystem-et. Ezt érzékeljük, de a cluster csal nekünk. Minden egyes esetben egy kitüntet tagja a cluster-nek férhet hozzá direkt mód a diskekhez és a filerendszerhez. Minden más node ezt a kitüntetett node-t fogja használni egy proxy-ként, átjátszóként. Tehát a többi node-on úgy fog tűnni, mintha a global filerendszert ő közvetlenül érné el, persze az igazság az, hogy a kitüntet node szolgálja ki az I/O műveleteket.

IPMP group

Már volt szó a network multipathingról. Ez gyakorlatilag nem szól másról, mint hogy egy virtuális csoportba (IP MultiPathing Groupba) teszünk bele fizikai eszközöket. Így amennyiben az egyik vonallal, vagy interface-el valami hiba történik a másik még mindig tud szolgáltatni, kiszolgálni a definiált IP-t. A következő példák azt fogják bemutatni, hogy milyen lehetőség van IPMP group-okat szervezni:

Active-Active
Két Interface

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up

/etc/hostname.ce1
group ipmp0 up

# ifconfig -a
ce0: flags=1000843 mtu 1500 index 4
     inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
     groupname ipmp0
     ether 0:3:ba:93:90:fc
ce1: flags=1000843 mtu 1500 index 5
     inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
     groupname ipmp0
     ether 0:3:ba:93:91:35

Két Interface + alias

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up \
addif 192.168.10.11 netmask + broadcast + up

/etc/hostname.ce1
group ipmp0 up

# ifconfig -a
ce0: flags=1000843 mtu 1500 index 4
     inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
     groupname ipmp0
     ether 0:3:ba:93:90:fc
ce0:1: flags=1000843 mtu 1500 index 4
     inet 192.168.10.11 netmask ffffff00 broadcast 192.168.10.255
ce1: flags=1000843 mtu 1500 index 5
     inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
     groupname ipmp0
     ether 0:3:ba:93:91:35

Három Interface

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up

/etc/hostname.ce1
group ipmp0 up

/etc/hostname.bge1
group ipmp0 up

# ifconfig -a
bge1: flags=1000843 mtu 1500 index 3
     inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
     groupname ipmp0
     ether 0:9:3d:11:91:1b
ce0: flags=1000843 mtu 1500 index 4
     inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
     groupname ipmp0
     ether 0:3:ba:93:90:fc
ce1: flags=1000843 mtu 1500 index 5
     inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
     groupname ipmp0
     ether 0:3:ba:93:91:35

Active-Standby
Két interface

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up

/etc/hostname.ce1
group ipmp0 standby up

# ifconfig -a
ce0: flags=1000843 mtu 1500 index 4
     inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
     groupname ipmp0
     ether 0:3:ba:93:90:fc
ce0:1: flags=1000843 mtu 1500 index 4
     inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
ce1: flags=69000842 mtu 0 index 5
     inet 0.0.0.0 netmask 0
     groupname ipmp0
     ether 0:3:ba:93:91:35

Két Interface + alias

/etc/hostname.ce0
192.168.10.10 netmask + broadcast + group ipmp0 up \
addif 192.168.10.11 netmask + broadcast + up

/etc/hostname.ce1
group ipmp0 standby up

# ifconfig -a
ce0: flags=1000843 mtu 1500 index 4
     inet 192.168.10.10 netmask ffffff00 broadcast 192.168.10.255
     groupname ipmp0
     ether 0:3:ba:93:90:fc
ce0:1: flags=1000843 mtu 1500 index 4
     inet 192.168.10.11 netmask ffffff00 broadcast 192.168.10.255
ce0:2: flags=1000843 mtu 1500 index 4
     inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
ce1: flags=69000842 mtu 0 index 5
     inet 0.0.0.0 netmask 0
     groupname ipmp0
     ether 0:3:ba:93:91:35

Mi az a quorum és mi a szerepe?

Már tudjuk biztosítani a szükséges topológiát a cluster-hez. Viszont meg kell ismerkednünk egy új fogalommal a quorummal. Alap esetben ugye a node-k, az interconnect hálózati kapcsolatukon szereznek egymás állapotáról tudomást. Amennyiben ez a kapcsolat megszakad, és az egyik node nem szerez tudomást a másik node állapotáról, akkor el kell gondolkodnia az elsőnek, most vajon mi történhetett, és mit kellene neki tennie.

• Első lehetőségként a cluster másik tagja, aki működteti a szükséges szolgáltatást, az meghalt. Nem elérhető, lefagyott, stb. Ez esetben át kellene venni a feladatkörét, és minél hamarabb szolgáltatni kellene a megfelelő alkalmazást.
• Második lehetőségként pedig csak hiba történt a két node közötti kapcsolatban, viszont ez nem érintette az szolgáltató node működését, így ha a másik is megpróbálná a szolgáltatást aktivizálni, abban az esetben csak a meglévő működést veszélyeztetné.

Az ilyen vitás helyzetek eldöntésére van a Quorum. A Quorum tradicionálisan egy (vagy több) disket jelent. Olyan közös storage disk-eket, amiket minden node lát direkt mód. Ezen diskekre a cluster node-k képesek egy SCSI reservation kulcsot ráírni. Tehát ezt a disk kapcsolatot, és speciális SCSI technológia által nyújtott lehetőséget használja fel a Sun Cluster annak jelzésére, hogy ő van és működik. A fent bemutatott helyzet esetében, amikor minden interconnect kapcsolat megszakad, a node ilyenkor a quorum-hoz tud fordulni, és meg nézni, hogy rajta vajon milyen kulcsok érhetőek el. Amennyiben csak a saját kulcsát találja, abban az esetben biztos lehet benne, hogy a másik gép nem működik, és elindíthatja a szolgáltatást nyugodt szívvel.

Quorum Server

A technológia fejlődésével, és a nagy távolságok (GeoCluster) megjelenésével a SCSI reservation használata elavulttá vállt. Így a Quorum szolgáltatást is egy külön dedikált hálózati szervizként módosították. Ezáltal egy központi server (vagy serverek, mert több Quorum is használható) hálózati alapon adva hírt, egy független forrásból. Természetesen a Sun Cluster 3.2-ben mind a SCSI reservation mind a Quorum Server alapú quorum támogatott. Akár egyszerre használhatunk belőle többet is.

Cluster Amnézia

Nézzük a következő helyzetet. Van két clusteres node. Mind a kettő működik, és leállítjuk az egyiket, normálisan, ahogy kell. Majd leállítjuk a másodikat. Így egyik cluster node se működik. Semmi gond, elindítjuk az elsőt. Mit fogunk tapasztalni? Azt, hogy ez az első node, ez csak áll és vár a másikra. Miért?

A vázolt szimptóma a Cluster Amnézia. Ugyanis, az először leállított node van annyira okos, hogy feltételezi azt, hogy a leállítása után a fenmaradó node cluster beállításai, adatai, akármi változott. Ergó ez az első node nem friss adatokat tartalmaz. Ezért nem indul el, amíg le nem tudja megát szinkronizálni azzal a node-al, amit ő uptodate-nek tart. Ez pedig a másik node. Tehát magas rendelkezésre állás ide, vagy oda, lehet nekünk egy clusterünk, ami szerencsétlen mód áll és vár a másikra.

Disk Group

Az egész Cluster működés szíve a központi adattárolás, ami függetleníthető a node-któl. Ezt a közös storage használatot természetesen logikai, volume szinten is le kell tudnunk kezelni.

A Sun Cluster számára egy tárolási csoport egységet, ami az egyik illetve a másik node-hoz tartozhat a Disk Group jelenti. Sun Cluster által két támogatott mód van egy Disk Group létrehozására:

– SVM Metaset készítés
– VxVM Disk Group készítés

Mindkét technikáról már külön külön írtam, így nem térek ki újra rá.

Resource Group, Resource, Resource type

Ha van már működő topológiánk, Sun Clusterrel, és létezik rajta egy Disk Group is akkor minden feltétel rendelkezésre áll, hogy végre a lényegre térjünk, arra hogy hogyan is fogunk mi a cluster által szolgáltatni. Ezen szolgáltatásokat, legyen az egy apache, nfs server, egy-egy resource group fogja reprezentálni a cluster számára. A resource group, ahogy a neve is elárulja resource csoport. A resource group testesíti meg magát a működő szolgáltatást, míg a benne lévő resource-k, a szolgáltatáshoz szükséges építő elemeket.

Vegyünk egy egyszerű példát. NFS server-t akarunk a clusterünkkel üzemeltetni. Tehát kell nekünk egy nfs-rg nevű resource group. Viszont mi is kell pontosan, ahhoz, hogy mi nfs server szolgáltatást nyújtsunk?

– egy IP, amin a szolgáltatás elérhető lesz
– egy filesystem amin egyrészt tároljuk az NFS server configurációs álományát, másrészt az NFS server által megosztott állományokat
– maga az a process ami az NFS szolgáltatásért lesz felelős

Ez a három feladat fog nekünk kelleni, tehát három resource-ra van szükségünk. Egy, ami az IP címünket intézi a cluster számára; egy, ami a megfelelő filesystemet teszi az adatokkal elérhetővé számunkra és egy ami, elindítja az nfs server processt, tehát a konkrét alkalmazást.

A számunkra szükséges resource-kat származtatnuk kell, úgynevezett resource type-okból.
A legáltalánosabb két resource type:

• SUNW.HaStoragePlus – a tárterületekért felelős resource type
• SUNW.LogicalHost – a megfelelő IP cím biztosításáért felelős resource type

Természetesen ezen túl rengeteg egyedi és más alkalmazás specifikus resource type van. A példánkhoz ugye még szükséges egy nfs resource type is. Amennyiben még nem ismeri a rendszerünk a használni kívánt resource type-okat regisztrálnunk kell.

# clresourcetype list -v
Resource Type         Node List
-------------         ---------
SUNW.LogicalHostname  all
SUNW.SharedAddress    all
SUNW.apache           phys-schost-1,phys-schost-2,phys-schost-3
# clresourcetype register nfs:3.1
# clresourcetype list
SUNW.LogicalHostname
SUNW.SharedAddress
SUNW.nfs
SUNW.apache

Ahhoz, hogy a mi általunk kitalált feladatra specifikált nfs resource-kat hozhassuk létre, a következő lépésekkel kell a resource type-okból tényleges resource-t létrehoznunk.

Először is a resource group-ot magát kell létrehoznunk, hisz a resource-kat már ehhez kell definiálnunk.

# clrdg create -p Pathprefix=/global/nfs/admin nfs-rg

A pathprefixnél azt adtuk meg, hogy a resource group hol keresse az adminisztrációs állományait

Most hogy van már resource group-unk, már jöhetnek bele a resource-k. Kezdjük a LogicalHost-al:

# clrslh create -g nfs-rg nfs-ipje

Az NFS-IPJE helyére azt a hostnevet kell megadnunk, amit a /etc/hosts file-ban a használni kívánt IP cím mellé megadtunk.
Most jöhet a HaStoragePlus resource:

# clrs create -t HAStoragePlus -g nfs-rg -p AffinityOn=true -p FilesystemMountPoints=/global/nfs nfs-stor

Most létrehoztunk egy nfs-stor nevű resource-t, ami a megadott mountpointért lesz felelős. Jöhet maga az nfs resource:

# clrs create -t nfs -g nfs-rg -p Resource_dependencies=nfs-stor nfs-res

Tehát az nfs resource type-ból származtatunk egy nfs-res nevű resource-t, ami viszont függeni fog az nfs-stor resource-től. Magyarán ha az nem indult el, ez meg se fog próbálni. Ha nincs tárhely szolgáltatni, ne is akarjunk szolgáltatni.
Mostmár csak egy dolgunk van az egész resource group elindításával az összes resource-t aktivizálni.

# clrg online -M nfs-rg

Resource Group vezérlése

Tehát létrehoztunk egy resource groupot, ami egy szolgáltatásért felel és resourcekből áll, ami a szolgáltatáshoz szükséges tényleges funkciókat jelenti. Nézzük tehát milyen állapotban lehet egy resource group és resource.

A fenti ábra jól mutatja azokat a parancsokat és állapotokat amiket elő lehet idézni. Nagyon fontos, hogy ugyan úgy mint az SMF service-k esetén a a resource-k esetén is van állapot ellenőrzés. Minden resource-hoz egy self test rész is tartozik, ami figyeli a resource állapotát. Amennyiben meghibásodás történik, abban az esetben a definíció szerint jár el.

Resource Group típusok

Failover Resource Group
A Failover ahogy a nevéből is következtethető a resource group-ot egy node-n futtatja egy időben. Amennyiben bármilyen hiba hatására ezen a node-n meghibásodás történik, a resource group megpróbál elindulni egy másik szabad node-n. A definiált resource típusok közül mind tud failover típusként működni.

Scalable Resource Group
A Failover-től eltérően a Scalable Resource groupok, egyszerre több node-n futnak. Mindegyik párhuzamosan nyújta a szolgáltatást. Természetesen skálázható esetben is kell lennie egy kitüntett node-nak, ami fogadja a szolgáltatás felé irányuló kéréseket, viszont a válasz már egy másik node fogja küldeni. Scalable resource group-ok esetében csak speciális resource typok használhatóak. Olyanok amik fel lettek készítve, illetve az alkalmazás jellege miatt egyáltalán lehetséges ez a fajta, „valaki kapja a kérést, de valaki más szolgálja ki” paradigma.

Sun Cluster 3.1 és 3.2 vezérlő utasítások

CLUSTER GROUP Parancsok

Sun Cluster 3.1	Sun Cluster 3.2	Description
scconf -p	cluster show	Get cluster configuration
scdidadm -L	cldev list -v	Get did device list from the cluster all nodes
	didadm -L
scsetup	clsetup	Cluster configuration menu
scstat -q	clq status	Get quorum information
scinstall -pv	clnode show-rev -v	Get cluster packages version on one node.
	clq show	Get quorum details
scshutdown	cluster shutdown	Shut down the whole cluster to OK prompt.
scconf -r -h node=[nodename]	clnode remove	Remove a Node From the Cluster (From the node to be removed, which is in noncluster mode and has access.)
scconf –c –q maintenance,node=[node_name]	clq disable [node_name]	Set maintenance mode on the node.
scswitch –z –D [diskgroup] –h [other_node]	cldg switch –n [node_name] [disk_group]	Switch a disk group to another node.
scstat -i	clnode status -m	Get the cluster IPMP group information.

DEVICE GROUP Parancsok

Sun Cluster 3.1	Sun Cluster 3.2	Description
scdpm -p all:all	cldev status	Get the did devices status
scconf -r -D …	cldevicegroup delete [device group]	Remove a Device Group
scswitch -z -h [node] -D …	cldevicegroup switch -n [nodename] [device group]	Switch a Device Group to a New Node
scswitch -F -D …	cldevicegroup offline [device group]	Bring Offline a Device Group
scgdevs scdidadm -r	cldevice refresh [diskname]	Update Device IDs for the Cluster

RESOURCE Parancsok

Sun Cluster 3.1	Sun Cluster 3.2	Description
scrgadm –p(vv)	clrt show	Get resource type details
scrgadm –a –t [resorce_type]	clrt register [resource_type]	Register a resource type
scrgadm -a -g [RG] -t [RT] -j [RES] -y [St_prop] -x [Ext_prop]	clrs create –g [resource group] –t [resource type]	Create a Resource
scrgadm -r -j [RES]	clrs delete [resource]	Remove a Resource
scrgadm –a –g [resource_group] –L –l [host_resource]	clrslh create –g [resource_group] [host_resource]	Create a LogicalHost resource
scrgadm –a –g [resource_group]-j [store_resource] –x AffinityOn=true	clrs create –t HAStoragePlus –g [resource_group] –p FileSystemPoints=[path]	Create a HAStoragePlus resource
scswitch –n –j [resource]	clrs disable [resource]	Set a resource state to disable
scswitch –e –j [resource]	clrs enable [resource]	Set a resource state to enable
switch –c –h [node_name] –j [resource_group] –f STOP_FAILED	clresource clear -f STOP_FAILED resource	Clear the STOP_FAILED Error Flag on a Resource

RESOURCE GROUP Parancsok

Sun Cluster 3.1	Sun Cluster 3.2	Description
scstat -g	clrg status	Get resource group information
scrgadm -pv	clrg show	Get resource group details
scrgadm -a -g [RG] -y [St_prop] -x [Ext_prop]	clrg create [resource_group]	Create a Failover Resource Group
	clrg create -S [resource_group]	Create a Scalable Resource Group
	clrg online +	Bring Online All Resource Groups
scswitch –Z –g [resource_group]	clrg online –M [resource_group]	Set resource group to online
scswitch –F –g [resource_group]	clrg offline –M [resource_group]	Set resource group to offline
scswitch –z –g [resource_group]–h [node]	clrg switch –n [node] [resource group]	Switch a resource group to another node.
scrgadm -r -g [RG]	clrg delete [resource_group]	Delete a Resource Group
	clrg delete -F [resource_group]	Delete a Resource Group and All of Its Resources