HACMP és PowerHA az AIX Cluster

AIX, Informatika 1 Minutes

A magas rendelkezésre állás kulcsa a legtöbb esetben valamilyen Cluster technológia. Ez az AIX operációs rendszernél sincs másként. A következő cikk Varga Tamás írása, mely próbálja az elejétől fogva bemutatni, hogy AIX-en, hogyan lehet telepíteni a cluster software-t, illetve bekonfigurálni egy HA szolgáltatást alá.

Mi is az a HACMP?

A HACMP az IBM AIX-re fejlesztett saját cluster technológiája, a High Availability Cluster Multi-Processing rövidítése. Az újabb verziókat >= 5.5 , már inkább PowerHA néven emlegetik. Az 5.4-es verzió óta Linux platformon is elérhető. Megtalálhatóak benne egy enterprise volumenű clustertől elvárható funkciók, úgymint például a storagek datacenterek közötti tükrözése, stb. Kényelmessé (vagy inkább kényelmesebbé) teszi vezérlését az AIX saját menüs felülete, melyben áttekinthetően tudjuk a cluster funckióit, vezérlését lekezelni. Szeretném leszögezni, hogy a HACMP-nek tonnányi irodalma, dokumentációja, cheat-sheetje, tutoriálja, howto-ja, example-ja és még ki tudja, mi mindene van, aki el akar mélyedni benne, megtalálja a weben, ezért én most csak egy konkrét példa konkrét megvalósítását igyekszem leírni, amit nekem nulláról indulva sikerült összehozni.

HACMP/PowerHA verziók és támogatások

A következő táblázatok összefoglalják, hogy milyen cluster software milyen rednszert támogat. Miről mire tudunk upgradelni.

HACMP Version
Supported?
AIX Level(s)
MISC
1.2
NO
3.2.5
2.1
NO
3.2.5
3.1.0
NO
3.2.5
3.1.1
NO
3.2.5
4.1.0
NO
4.1.X
4.1.1
NO
4.1.X
4.2
NO
4.1.4, 4.2.X
4.2.1
NO
4.1.5, 4.2.X
4.2.2
NO
4.1.5, 4.2.1, 4.3.X
4.3
NO
4.3.2, 4.3.3
4.3.1
NO
4.3.2, 4.3.3
4.4
NO
4.3.3
4.4.1
NO
4.3.3, 5.1
4.5
NO
5.1, 5.2
5.1
NO
5.1, 5.2,5.3
5.2
NO
5.1, 5.2,5.3
NO
5.2(ML4), 5.3(ML2) or higher
6.1
 AIX 5.2 RSCT 2.3.6 or higher
AIX 5.3 RSCT 2.4.2 or higher
5.4.0
and
5.4.1
NO
5.2 (TL8) or higher
5.3(TL4) or higher
AIX 5.2 RSCT 2.3.9 or higher
AIX 5.3 RSCT 2.4.5. or higher
NO –9/30/2011
5.3 TL7
6.1 TL2,SP1
AIX 7.1
 AIX 5.3 RSCT 2.4.10.0 or higher
AIX 6.1 RSCT 2.5.2.0 or higher
release_notes
Yes
AIX 5.3 TL 9
AIX 6.1 TL2 SP1
AIX 7.1
AIX 5.3 RSCT 2.4.12.0 or higher
AIX 6.1 RSCT 2.5.4.0 or higher
release_notes
Yes
AIX 6.1 TL6+
AIX 7.1
 AIX 6.1 RSCT 3.1.0.0 or higher
AIX 7.1 RSCT 3.1.0.0
release_notes
Yes
AIX 6.1 TL7 SP2
AIX 7.1 TL1 SP2
 RSCT 3.1.2.0 or higher for both AIX versions
release_notes

Upgrade path options

5.3
5.4
5.4.1
5.5
6.1
7.1.x
5.2
R/S/O
R/S/O
R/S/O
R/S/O
*
*
5.3
NA
R/S/O
R/S/O
R/S/O
R*/S/O*
*
5.4
NA
NA
R/S/O/N
R/S/O/N*
R*/S/O*/**
*
5.4.1
NA
NA
NA
R/S/O/N
R/S/O/N
R/S/O
5.5
NA
NA
NA
NA
R/S/O/N
R/S/O
6.1
NA
NA
NA
NA
NA
R/S/O

R=Rolling Upgrade
S=Snapshot Upgrade
O=Offline Upgrade
N=Non-disruptive Upgrade

*= Must upgrade to 5.4.1 or above first, making it a two step upgrade.
**=NDU not officially supported beyond two version

AIX 4.3.3
AIX 5.1
AIX 5.1(64-bit)
AIX 5.2
AIX 5.3
AIX 6.1
AIX 7.1
HACMP 4.5
No
Yes
No
Yes
No
No
No
HACMP/ES 4.5
No
Yes
Yes
Yes
No
No
No
HACMP/ES 5.1
No
Yes
Yes
Yes
Yes
No
No
HACMP/ES 5.2
No
Yes
Yes
Yes
Yes
No
No
HACMP/ES 5.3
No
No
No
Yes
Yes
No
HACMP/ES 5.4.0
No
No
No
TL8+
TL4+
No
No
No
No
No
TL8+
TL4+
No
No
No
No
TL9+
TL2,SP1+
No
No
No
No
TL9+
TL2,SP1+
No
No
No
No
No
TL6+
No
No
No
No
No
TL7+
Yes

HACMP/PowerHA install

Első lépésként fel kell telepítenünk a cluster alkalmazást magát. Tételezzük fel, hogy van már egy installált AIX (a mi esetünkben 7.1 verziójú) rendszerünk, amely rendelkezik egy alapszíntű konfigurációval, elérhető valamilyen remote console megoldással, stb.

A telepítést legegyszerűbben a smitty felületen keresztül végezhetjük el. Adjuk ki a ’smitty install_latest’ parancsot root userként. Itt a következőt fogjuk látni.

Adjuk meg a HACMP fileset elérési útvonalát, majd ’Do’, azaz Enter.

A ’SOFTWARE to install’-ra állva nyomjunk egy F4-et, és máris kiválaszthatóvá válnak a fileset collectionben található csomagok. Legalább a következőket kell hozzá kiválasztanunk: cluster.adt.es, cluster.es.cfs, cluster.es.client, cluster.es.cspoc, cluster.es.server, cluster.license (de lehet akár full install is). Továbbá ahhoz, hogy tudjunk disket concurrent módban használni, az AIX saját install médiájáról a bos.clvm.enh fileset szükséges (ez egyébként függőség is). Az ’ACCEPT new license agreements?’-et állítsuk ’Yes’-re, így nem fog minden filesetnél rákérdezni, hogy szeretnénk-e elfogadni. Ha nem vagyunk biztosak abban, hogy feltelepülnek a csomagjaink, megtehetjük, hogy a ’PREVIEW only’ opciót ’Yes’-re állítjuk, így a telepítést emulálni fogja csak, valós install nem fog történni.

Válasszuk ki a fileseteket F7-tel. Majd ’Do’.


Upsz, azt látjuk, hogy van egy hiányzó függőségünk: bos.adt.syscalls. Az AIX install mediáról tehető fel ez is.

Ezek után az installunk sikeres lesz, amit a bal felső sarokban levő ’running’ felirat ’OK’-ra változása fog tudatni velünk. Minden más esetben ’failed’ lesz az üzenet, ezekben az esetekben az alatta levő sorokban megkereshetjük a hiba okát, és korrigálhatjuk.

Ha a fenti lépéseken túl vagyunk, akkor a magunkénak tudhatunk egy AIX 7.1-es rendszert, rajta installált (de még nem konfigurált) cluster alkalmazással. Mivel clusterről legalább kettő node esetén érdemes beszélni, ezt természetesen a tervezett clusterünk mindkét nodeján meg kell tennünk. Az általános szempontokra (nodeok hardveres- és szoftveres azonosságára pl. )itt nem térnék ki, ez a leírás specifikusan a HACMP megoldásról szól.

Előkészületek

Ahhoz, hogy clusterünk konfigurációja minél zökkenőmentesebb legyen, érdemes a clusterünket megtervezni. Mi a szemléltetés kedvéért, a következő, nagyon egyszerű topológiát fogjuk követni.

Láthatjuk, hogy ez egy kettő nodeos cluster, melynek a storage-a a mi esetünkben egy EMC Clariion SAN. A nodeok rendelkeznek 2-2 db hálózati interface-szel, melyek egyike a nodeok közötti kommunikációt fogja szolgálni, a másikon pedig maga a szolgáltatás lesz elérhető. Ezeket célszerű, de erősen ajánlott is külön logikai, de akár fizikai hálózatba is rendezni.

A nodeok neve az egyszerűség kedvéért legyen:

test01 (IP címe: 192.168.132.58/25)
test02 (IP címe: 192.168.132.61/25)

ill. adjunk a heartbeat hálózat node-interfaceinak is külön címeket. Ezeket lehet egy nagyon szűk subnetbe (mondjuk egy 4 eleműbe) is rendezni, ha takarékoskodni szeretnénk az IP címekkel. Ezek neve ill. IP-je lehet mondjuk a mi esetünkben:

test01conn (IP: 10.0.0.1)
test02conn (IP: 10.0.0.2)

Ezenkívűl „kötelező kellék” még legalább egy darab IP cím, amin a magas rendelkezésre állású szolgáltatásunk lesz elérhető, ezt mi a tesztkörnyezetünkben nevezzük pl. serviceip-nek. Ez az IP fog „vándorolni” a nodeok között failover esetén (floating IP).

serviceip (IP: 192.168.132.70/25)

A fentebb felsorolt IP-hostnév hozzárendeléseknek KÖTELEZŐEN szerepelnie kell mindkét nodeunk /etc/hosts filejában, ellenkező esetben a clusterünk NEM fog működni vagy mindenféle rejtélyes hibákba futunk bele.

A cluster nodeok egymást közötti szinkronjához az alkalmazás az rsh-t ill. rshexec-t használ, szükség lesz tehát arra is, hogy probléma nélkül tudjanak egymáshoz hozzáférni. Ehhez a két node hostneveit célszerű az ’rhosts’ fileba, ill. a cluster saját rhosts filejaiba beírni. Ezek a következők:

/.rhosts
/usr/es/sbin/cluster/etc/rhosts

Ill. csak a nodeneveket a /usr/es/sbin/cluster/etc/clhosts fileba beírni. Most már egymáson is tudnak a nodeon parancsokat futtatni. Ha ezek megvannak, akkor indítsuk újra a nodeokat, hogy lássuk, felbootolnak-e rendesen. Amint ez megtörtént, az előkészületeken túl is volnánk, megkezdhetjük a cluster valós konfigurációját. Mindenképpen ellenőrizzük le, hogy mindkét noderól tudjuk-e a serviceip kivételével az összes IP-t pingelni, ill. az rsh-val be tudunk e lépni a másik nodere, ha ezt megtesszük, a későbbiekben sok hibakereséstől kímélhetjük meg magunkat.

Cluster initial konfig (cluster létrehozása)

A nodeok újraindulása után elkezdhetjük konfigurálni clusterünket. A HACMP esetében – végre egy jó hír – megtehetjük, hogy mellőzzük a bonyolult és hosszú parancsok shell promptba történő gépelgetését, mivel az AIX ill. a HACMP biztosította nekünk a smitty konzolba történő integrációt; fénycsíkos menükben tudjuk clusterünket testre szabni.

Adjuk ki a ’smitty hacmp’ (vagy rövidebben a ’smit hacmp’) parancsot. A következő menüt fogjuk kapni:

Ez a menü a HACMP verziójától függően picit változhat, de a fő opciók mindegyike megtalálható bennük.

A következő lépést meg kell tennünk mindkét nodeon, ahhoz, hogy egymást cluster tagokként kezeljék.

# smitty hacmp
-> Extended Configuration
   -> Extended Topology Configuration
      -> Configure an HACMP Cluster
         -> Add/Change/Show an HACMP Cluster

                        Add/Change/Show an HACMP Cluster

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

                                               [Entry Fields]
* Cluster Name                                       [aixclus]

  NOTE: HACMP must be RESTARTED
  on all nodes in order for change to take effect

Adjunk egy számunkra beszédes nevet a clusterünknek, majd indítsuk újra a cluster szolgáltatásokat (magát a hostot nem fontos).

# stopsrc -g cluster
# stopsrc -g clcomdES

majd:

# startsrc -g cluster
# startsrc -g clcomdES

A clusterünk létrejött és ’aixclus’ néven figyel. Mivel azonban nem tudják egymásról, hogy ők egymás cluster nodejai, így definiálnunk kell a cluster nodeokat. Ez lesz a következő lépésünk.

Nodeok konfigurálása

Konfiguráljuk a nodeokat! Ezt és a következő lépéseket elegendő a cluster egyik nodeján megtenni, majd látni fogjuk, miért.

test01# smitty hacmp
-> Extended Configuration
   -> Extended Topology Configuration
      -> Configure HACMP Nodes
         -> Add a Node to the HACMP Cluster

                        Add a Node to the HACMP Cluster

Type or select values in entry fields.
Press Enter AFTER making all desired changes.


                                                        [Entry Fields]
* Node Name                                          [test01]
  Communication Path to Node                         [test01conn]

Ugyan ezt ismételjük meg a másik node-n is, vagy amennyi van.

Add a Node to the HACMP Cluster

Type or select values in entry fields.
Press Enter AFTER making all desired changes.
                                                        [Entry Fields]

* Node Name                                          [test02]
  Communication Path to Node                         [test02conn]

A „Node name” egyértelmű, itt adhatjuk meg a node-unk nevét, ennek egyeznie kell a hosts fileban definiáltakkal. A „Communication Path to Node” menünél megfigyelhetjük a „+” jelet, ez azt jelenti, hogy itt választható opciók vannak. F4-re kapunk egy új menüt, ahol kiválaszthatjuk a hozzá tartozó kommunikációs path-t, ami a test01conn lesz a mi esetünkben. Majd tegyük meg ugyanezt a test02-vel is, és természetesen mindkét lépést a másik nodeon is. A nodeok létrehozása készen is van.

Site-ok létrehozása

Következő lépésként a ’siteokat’ definiálhatunk. Ez egy logikai csoportként is felfogható, ahol meghatározhatjuk, hogy pl. soknodeos cluster esetén egy adott magas rendelkezésre állású alkalmazást csak mely nodeok szolgáljanak ki. Tetszőleges számú site létrehozható. Megjegyzendő, hogy ez a lépés ki is hagyható, nem kötelező siteokat definiálnunk (itt azért bemutatjuk). Adhatunk egy sitenevet és kiválaszthatjuk a nodeokat hozzá, egyet vagy többet.

test01# smitty hacmp
-> Extended Configuration
   -> Extended Topology Configuration
      -> Configure HACMP Sites
         -> Add a Site

                                   Add a Site

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

                                                        [Entry Fields]
* Site Name                                   [test1site]
* Site Nodes                                  test01

Hálózatok létrehozása

A hálózat vagy hálózatok létrehozása viszont kötelező lépés, csakúgy, mint nodeok nélkül, enélkül sem lesz működőképes a clusterünk. Mivel a nodejaink egymást már elérik, hozzáférésük van, a hálózat definiálása történhet félautomatikus módon is.

test01# smitty hacmp
-> Extended Configuration
   -> Discover HACMP-related Information from Configured Nodes

Itt a cluster megpróbálja feltérképezni a nodejain az interfacekat és ezek konfigurációját, majd ha sikerül, begyűjti ezek adatait, és később ezek közül választhatunk. Ez nem mindig sikeres, de ez nem probléma, mert kézzel is ki tudjuk választani, ill. létre tudjuk hozni a cluster networkot. Lássuk, hogyan:

test01# smitty hacmp
-> Extended Configuration
	->Extended Topology Configuration
		-> Configure HACMP Networks
			-> Add a Network to the HACMP Cluster

A cluster kommunikációs hálózatunk, függően a használt megoldástól, lehet IP-alapú vagy nem-IP-alapú. Az IP-alapú elég egyértelmű. A nem-IP-alapú, egyebek mellett, lehet pl. serial porton keresztüli, vagy QUORUM disk (itt heartbeat-disknek, vagy diskhb-nak hívják). Mi itt, az egyszerűség kedvéért IP alapút használunk. Válasszuk ki az ’ether’-t, mint „Network type”-ot, adjunk neki egy számunkra beszédes nevet. Adjuk meg az ezen a hálózaton levő logikai címek, azaz az IP-k alhálózati maszkját, és engedélyezzük az „IP address takover via IP Aliases”-t. A többi maradhat default. Majd ’Do’.

Kommunikációs interfacek, eszközök

A clusterünk konfigurálásának egyik legfontosabb pontja, a kommunikációs útvonalak létrehozását nézzük most. Itt fogjuk a clusternek megmondani, hogy mely node felé mely heartbeat linken keresztül „keresgéljen” ill. ellenőrizze folyamatosan az elérhetőséget. 

test01# smitty hacmp
-> Extended Configuration
   -> Extended Topology Configuration
      -> Configure HACMP Communication Interfaces/Devices
         -> Add Communication Interfaces/Devices

Válasszuk a „Add Pre-defined Communication Interfaces and Devices” menüpontot, majd itt kiválasztjuk a a „Communication interfaces”, ezután pedig a már meglevő cluster networkot (előző lépésben hoztuk létre, ld. 6. pont).

Az „IP Label/Address”-nél F4-et nyomva válasszuk ki a nodenak megfelelő heartbeat hostnevet (pl. test01-hez a test01conn-t), a „Node name”-nél pedig szintén F4- és a node nevét. A „Network interface”-nél pedig azt az interfacet, amire a service IP-t szeretnénk majd felhúzni. Majd ’Do’. Ezt tegyük meg mindkét nodera vonatkozólag.

Állandó node-IP hozzárendelések

Hozzuk létre a Persistent Node IP Label/Address hozzárendeléseket.

test01# smitty hacmp
-> Extended Configuration
   -> Extended Topology Configuration
      -> Configure HACMP Persistent Node IP Label/Addresses
         -> Add a Persistent Node IP Label/Address

Válasszuk ki a megfelelő nodeot, majd adjuk meghozzá a node-IP-t (ami valójában a hostnév lesz, hiszen a feloldás a hosts file alapján fog történni, ill. a network nevet.

Majd ’Do’. Ezt is meg kell tennünk mindkét node-ra vonatkozólag. Clusterünk alapkonfigurációja tulajdonképpen kész is van, mielőtt hozzáfognánk az erőforrások ill. erőforrás csoportok (resources ill. resource groupok) létrehozásához, egy nagyon fontos lépés van még hátra, nevezetesen a cluster nodeok ellenőrzése és szinkronizációja. -Ezt egyébként minden fontosabb lépés után erősen ajánlott megtenni, a node-k közötti konzisztencia biztosítása végett.

Ellenőrzés és szinkronizáció

A „Nodeok konfigurálása” pontban, a nodeok konfigurálásánál említettük, hogy minden eddigi lépést elegendő clusterünk egyik nodeján megtenni. Lássuk, miért is. Mivel a nodeok közötti információcsere és szinkron az rsh és rshexec parancsokon keresztül biztosított, így az egyik nodeon létrehozott konfiguráció szinkronizálható a másik nodera. Ehhez van szükség a most következő lépésre. A cluster menüjéből el kell végezni a kiterjesztett ellenőrzést és szinkronizációt. Lássuk, hogyan!

test01# smitty hacmp
-> Extended Configuration
   -> Extended Topology Configuration
	-> Extended Verification and Synchronization

Ez a lépés lesz az, ahol a clusterünk egy mindenre (vagy legalábbis majdnem mindenre) kiterjedő önellenőrzést hajt végre, végignézi a topológia konfigot, a hálózati konfigurációt, ha már van, akkor a resource konfigot, és amennyiben nem talál ellenmondást,szintaktikai és/vagy elvi hibát, akkor a konfigurációt átviszi a másik vagy többi nodera. Ha ez sikeres, innentől lesz a clusterünk egységes egész. Kiválaszthatjuk, hogy a teljes konfigurációt, vagy csak a legutolsó szinkron óta történt változásokat elemezze, ill. a logolás szintjét, ez hibakeresésnél lehet fontos. Ez egy lassúbb gépen 1-2 percig is eltarthat, tehát legyünk türelemmel.

Én most egy kimenetet idevágok, csak hogy tudjuk mire számíthatunk:



No, itt aztán látunk sok mindent!

Nézzük csak a WARNING-okat, amelyektől egyébként a clusterünk teljesen jól működik, azonban esetleg nem az ajánlásoknak megfelelő a megoldás, ill. lehetne jobban is csinálni.

A sárga WARNING az mondja, hogy több IP aliast használva javasolt több hálózati interface használata, így kikerülhető lenne a single point of failure. A zöld WARNING azt mondja, hogy okos dolog lenne az IP-alapú heartbeat mellett egy nem-IP-alapút is használni, pl. diskhb-t, ugyancsak elkerülni a single point of failure-t. A ciánkék WARNING szerinte a force-varyon opció használata felesleg nem-tükrözött volume-groupok esetén. Nem túl lényeges üzenet. A piros WARNING azt mondja, hogy az NFS megosztásnál szerencsésebb lenne ha a megosztás még az serviceip takeover előtt szerencsésebb lenne. Igaza van. A szürke WARNING pedig arra figyelmeztet, hogy nincs monitorozva a cluster által a magas rendelkezésre állású szolgáltatás még. Ezek egyike sem kritikus hiba, így az ellenőrzés végbement, változás nem volt az utolsó szinkron óta, minden rendben, clusterünk szolgáltat. Ha azonban ERROR sor is kerül az ellenőrzésbe, akkor a szinkron nem fog végbemenni, mindenképp korrigálásra szorul a clusterünk konfigurációja.

Resource group hozzáadás, service IP label

Most fogjuk meghatározni azt, hogy pontosan mi és hogyan is lesz itt nekünk magas rendelkezésre állású szolgáltatás. Nézzük! Lépjünk a megfelelő menübe:

test01# smitty hacmp
-> Extended Configuration
   -> Extended Resource Configuration
	-> HACMP Extended Resource Group Configuration
	    -> Add a Resource Group

Adjunk egy nevet a létrehozandó resource groupunknak, és a Participating Nodes (Default Node Priority) sorban válasszuk ki neki a résztvevő nodeokat, az első lesz a prioritásban első node. A következő három opcióban választhatjuk ki, hogy hol induljon el, kiesés esetén mi történjen, ill. helyreállás esetén mi történjen. Majd ’Do’. A resource groupunk el is készült, éppen csak még nem tartalmaz semmilyen resourcet, tehát teljesen üres. Kell is bele rögtön egy IP-resource, amit majd lebegtet a nodeok között.

test01# smitty hacmp
-> Extended Configuration
   -> Extended Resource Configuration
	-> HACMP Extended Resources Configuration
	    -> Configure HACMP Service IP Labels/Addresses
		-> Add a Service IP Label/Address

Ezt kiválasztva kérdést kapunk, hogy ez csak egy nodehoz köthető, vagy több között is lebeghet. Mi most a Configurable on Multiple Nodes opciót választjuk. Majd rákérdez az előzőekben már definiált cluster networkre.

Az IP Label/Address-nél kiválaszthatjuk végre a már a hosts fileban definiált serviceip-t. Opcionálisan megadható hozzá a netmask. A többi maradhat default. Majd ’Do’. Kész, van cluster IP-nk a szolgáltatáshoz.

Megosztott volume groupok hozzáadása (logikai group, majd fájlrendszer)

Hozzuk létre a megosztott kötetet a szolgáltatáshoz. Most először a HACMP egy másik menücsoportját, a C-SPOC-ot fogjuk erre használni. Lássuk, hogyan!

FONTOS: az előkészületeknél is említhettem volna, de itt már mindenképp fontos: a shared LUN-nak kell, hogy legyen PVID-ja.

Mindkét nodeon a parancs (ha feltételezzük, hogy a shared LUN –t hdisk1-ként látja az AIX-unk):

test01# chdev –l hdisk1 –a pv=yes

test02# chdev –l hdisk1 –a pv=yes

Látjuk hogy a PVID egyezik és ez így van jól.

test01# smitty hacmp
-> System Management (C-SPOC)
   -> Storage
	-> Volume Groups
	    -> Create a Volume Group

Válasszuk ki F7-tel mindkét nodeunkat, majd következő lépésben a PVID-t. Enter. A HACMP meg fogja kérdezni:

    – a volume group nevét (tetszőleges)
    – a resource group nevét, amibe szeretnénk ezt tenni (válasszuk a 10. pontban létrehozott nevűt pl.)
    – a típusát (big, scalable, stb., ahogy szeretnénk)
    – aktiválja-e bootoláskor (mondjunk NO-t, mert ezt majd a cluster lekezeli)
    – megadhatjuk a PP size-t (tőlünk függ)
    – és a LV-k maximális számát (ez is)

A többi maradhat default. Majd ’Do’. A HACMP most megkreálja a volume groupot, mindkét nodeon vary-off-ba teszi, és ugyancsak mindkét nodeon az AIX ODM-jébe beírja a megfelelő bejegyzést erről. Ezután:

test01# smitty hacmp
-> System Management (C-SPOC)
   -> Storage
	-> Volume Groups
		-> Synchronize a Volume Group Definition

A volume groupunk kész van. Már csak fájlrendszer kellene rá, vagy LV és arra a fájlrendszer. Nézzük ezt is:

test01# smitty hacmp
-> System Management (C-SPOC)
   -> Storage
	-> Logical Volumes
		-> Add a Logical Volume

A megjelenő menüből válasszuk a VG-t:


Majd pedig:

’Do’.

Itt is sok minden beállíthatunk, az egyetlen kötelező paraméter a Logikai partíciók száma. Ezután ’Do’. Mos tmár csak fájlrendszer kell a létrehozott LV-nkre. Lássuk, hogyan!

test01# smitty hacmp
-> System Management (C-SPOC)
   -> Storage
	-> File systems
		-> Add a File System

A VG kiválasztása után a fájlrendszer típusra vonatkozólag kapunk kérdést:

Válasszuk az Enhanced Journaled típust.

Három kötelező paraméter:

    – node név
    – méret
    – mountpoint (ez a legfontosabb!!!)

Adjunk meg ezeket, a nodenevek már ki vannak töltve, a volume group ezen a két nodeon létezik, tehát az LV ill. az FS is itt lesz. Majd ’Do’. A fájlrendszerünk a megadott mountpointon elkészül (de nem lesz még elérhető, ezt majd a cluster kezeli).

Alkalmazás szerver konfiguráció

Van már IP és storage resource groupunk definiálva, ami még szükséges, az maga az alkalmazás, ami majd magas rendelkezésre állással szolgáltat. Ez a mi esetünkben egy nagyon-nagyon szimpla kis script lesz, ami a shared filesystemen létrehoz egy hostname nevű szövegfilet, és beleírja annak a nodenak a nevét, amin éppen fut, a leállító script pedig törli ezt a filet.

Az „alkalmazás” start és stop scriptjeit ide tettük:

/usr/sbin/cluster/events/ (teststartscript.sh ill. teststopscript.sh néven)

test01# smitty hacmp
-> Extended Configuration
   -> Extended Resource Configuration
	-> HACMP Extended Resources Configuration
		-> Configure HACMP Applications Servers
			-> Configure HACMP Application Servers
				-> Add an Application Server

Kötelező paramétereket adjuk meg!

    – app. szerver neve (tetszőleges)
    – start scriptje (/usr/sbin/cluster/events/teststartscript.sh)
    – stop scriptje (/usr/sbin/cluster/events/teststopscript.sh)

Majd ’Do’.

Resource group végleges konfigurációja

Mindenünk megvan ahhoz, hogy a resource groupunkat készre tudjuk konfigurálni, és clusterünk elkezdjen szolgáltatni, végezzük el az utolsó lépést! Dobáljuk össze most már egy már meglevő, de üres resource groupba a resourceainkat.

test01# smitty hacmp
-> Extended Configuration
   -> Extended Resource Configuration
	-> HACMP Extended Resource Group Configuration
		-> Change/Show Resources for a Resource Group

Válasszuk ki a már meglevő resource groupunkat, és adjuk hozzá a szükséges erőforrásainkat, lásd a képen lejjebb!

Mit adunk meg?

Service IP Labels/Addresses [serviceip]
(F4-gyel kiválasztható a listából ld. 10. pont)

Application Servers [testserv]
(F4-gyel kiválasztható a listából ld. 12. pont)

Volume Groups [vg61 ]
(F4-gyel kiválasztható a listából ld. 11. pont)

Filesystems (empty is ALL for VGs specified) [/shared ]
(F4-gyel kiválasztható a listából ld. 11. pont)

Filesystems/Directories to Export (NFSv2/3) [/shared]
(F4-gyel kiválasztható a listából, ezt fogjuk NFS-en szolgáltatni)

Raw Disk PVIDs [00c8119fe3d2d245]
(amit a nodeokon látunk lspv-vel)

Majd ’Do’ !

A clusterünk már csak egy Ellenőrzés és szinkronizációt kíván, és működni fog!

test01# smitty hacmp
-> Extended Configuration
   -> Extended Topology Configuration
	-> Extended Verification and Synchronization

A cluster tesztelése

Clusterünket illik tesztelni használat előtt. Ellenőrizzük, hogy sikeres lesz-e switch egy másik nodera:

test01# smitty hacmp
-> System Management (C-SPOC)
	-> Resource Groups and Applications 
		-> Move a Resource Group to Another Node / Site
			-> Move Resource Groups to Another Node

Itt kiválasztjuk, mely noderól és melyik resource grouput mozgatjuk, majd azt, hogy hova, és át fogja mozgatni!

Hasznos Tudnivalók

PATH:

Érdemes a PATH-hoz hozzáadni a következő directorykat:

/usr/es/sbin/cluster/utilities:/usr/es/sbin/cluster

Logok:

tail -f /var/hacmp/adm/cluster.log
tail -f /var/hacmp/log/hacmp.out (inkább debug)

Cluster info parancsok:

/usr/es/sbin/cluster/utilities/cltopinfo
(cluster pillanatnyi konfig, nodeok, network, resources)

/usr/es/sbin/cluster/utilities/clRGinfo
(cluster pillanatnyi állapot, futó resource groupok, nodeok)

/usr/es/sbin/cluster/sbin/cl_lsfs
(cluster filesystemek)

/usr/es/sbin/cluster/sbin/cl_lsvg
(cluster volume group status)

/usr/es/sbin/cluster/utilities/cllog –s
(felsorolja a clusterlogokat)

lssrc -ls clstrmgrES; lssrc –g cluster
(cluster processz részletesen, ellenőrizhető a futás)

Illetve mindezek megtehetők smittyvel is.



test01# smitty hacmp
       -> System Management (C-SPOC) alatti menük



Cluster config mentés és visszaállítás (snapshot):


test01# smitty hacmp
-> Extended Configuration
	-> Snapshot Configuration



Összegzés


Az AIX cluster technológiája egy kissé fapadosnak tűnik a már megismert Sun/Oracle Cluster, illetve Veritas Cluster Suite mellett. Kicsit egyedi terminológiát is használ a különböző resourcek kezelésére, viszont a smit használata megkönnyít a kezelésüket. Ha valaki AIX clusterezésre szánja el magát, érdemes rendesen utána olvasni, különben a smit-ben használt különböző keresztbe hivatkozásokon könnyű lesz elakadni. A másik kihívás a komolyabb kihívás a különböző AIX verziók és HACMP/PowerHA kompatibilitások. A teszt során mi is rengeteg buktatóba akadtunk. Hiába állítottunk be mindent jól, a cluster mégse az elvárt módon működött.


A másik nagy megoldás az alkalmazás resourcek teljes hiánya. Aki alkalmazást akar integrálni a clusterébe, annak saját maga kell gondoskodni, és persze karban tartani az indító, leállító, és monitorozó scriptjeit.


A puritán megoldások ellenére a HACMP/PowerHA megoldással könnyen és egyszerűen magas rendelkezésállásúvá tehető egy szolgáltatás.

	


	

			


	

				

						

							

			
			

				

					Published by MiszterX				

			


			

								
			

		

				

			Published
					

	




			
	
			



	
	
	
		

		
Vélemény, hozzászólás? 
Az e-mail címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük