Veritas Cluster Suite bemutató

Már esett szó magas rendelkezésre állású rendszerekről, konkrétan a SUN Cluster 3.2-t mutattam be egy írásomban. Most a nagyvállalatoknál sokkal inkább elterjedt Veritas vagy Symantec Cluster technológiával kívánom megismertetni a kedves olvasót.

Milyen különbségek fedezhetőek fel a Veritas és a SUN Cluster között?

Az első legfontosabb talán, hogy míg a Sun Cluster kernel szinten épül be a Solaris rendszerbe, és természetesen csak Solarishoz érhető el, addig a Veritas multiplatformos (Solaris, HP-UX, AIX, Linux, Windows), és a Veritas Cluster Suite (VCS) nem más mint egy user space-ben futó alkalmazás.

Többnyire előnyei vannak ennek a tulajdonságának a VCS-nek. Először is tetszőlegesen lehet installálni majd uninstallálni. A SUN cluster esetében ez elég körülményes az esetek többségében teljes OS reinstallt jelent.

A multiplatformossága miatt tetszőleges OS-en alkalmazható ez a program. Tehát a megszerzett tudás és használat minden platformon hasznosítható, vagy akár közös management-el irányítható.

Azt se fejeltsük el kihangsúlyozni, hogy a VCS csak egy program, ami a programok kezelésével magas rendelkezésre állást biztosít. a VCS viszont csupán egy vezérlő program. Amennyiben a VCS leáll, vagy hiba történik a VCS-el magával, az nem érinti a futatott alkalmazást. Az alkalmazás ugyan úgy futni fog, csupán a magas rendelkezésre állást fogjuk elveszíteni. Tehát ha az alkalmazást költöztetni kell valami hiba folytán, akkor a VCS azt nem fogja megtenni. Amennyiben nincs hiba az alkalmazás tökéletesen fog futni továbbra is.

A SUN Cluster esetében ez nem így van. Ott ha baj van valami a clusterrel, akkor leáll az alkalmazás maga is.

Rendszerkövetelmények és ajánlások a telepítéshez

A VCS mára már része a Symantec Storage Foundation termékének. Ahol azt látjuk, hogy Storage Foundation HA, ott biztosra vehetjük, hogy a HA (High Availability ) a VCS-t jelöli. Cserébe 60 napig akárki letöltheti ezt a terméket is és szabadon kipróbálhatja.

Veritas Storage Foundation and High Availability Solutions, v5.1

Veritas Storage Foundation and High Availability Solutions, v5.0

The Storage Foundation & High Availability Solutions for Windows software supports

Ezeken túl a VCS-nek szüksége van egy Heart Beat dedikált vonalra, amin a cluster információkat fogják a cluster node-k cserélgetni egymás között. Ebből egy is elegendő, de ajánlott inkább a kettő.

A VCS szintén ajánl két (redundáns) hálózati interface-t a plublikus hálózat felé.

A VCS maga a rendszertől körülbelől 256MB RAM-ot (és legalább 360Mb SWAP-et) igényel és számottevő CPU teljesítményt nem igényel.

VCS 5.1 install

Először is le kell tölteni a a Symantec oldaláról a megfelelő installer csomagot. Én most egy Solaris 10-re fogom installálni azt.

node1# cd /tmp
node1# ls -lah

Tömörítsük ki:
node1# gunzip -c VRTS_SF_HA_Solutions_5.1_SP1_Solaris_SPARC.tar.gz | tar -xf –
noce1# ls -lah

A telepítő a következő állományokat fogja tartalmazni:
node1# cd dvd1-sol_sparc/
node1# ls -lah

Az installálás viszonylag adminisztrátor barát lesz. Elég csak az install scriptet elindítani:
node1# # ./installer

A menüben most válasszuk az I menüt azaz „Install a Product”.

A következő menüben választhatunk a felsorolt termékek közül. A mi esetünkben most magára a Storage Foundation és High Availability-re lesz szükségünk, tehát 4.

Ezek után természetesen elkell fogadni, hogy a felhasználási szerződéssel egyetértünk, és annak feltételeit olvastuk és jóváhagyjuk:

A következő pontnál azt kell kiválasztanunk, hogy a Storage Foundation HA csomagon belül mennyi hozzátartozó összetevőt kívánunk használni. Én jelen pillanatban azt javaslom rakjunk fel mindent, aki majd tudja miket tartalmaznak ezek a csomagok, azok majd bátran testre szabhatják akár a minimális lehetőséget is. Tehát 3.

Most meg kell adnunk, a HOSTNEVEIT azon gépeknek, amik tagjai lesznek ennek a clusternek. Én jelen pillanatban egy két node-s clustert akarok építeni, tehát space-el elválasztva fel kell sorolnom a hostneveit. DEBRECEN-01 DEBRECEN-02

FONTOS! hogy ezeket előtte vagy bele kell írni az /etc/hosts file-ba, hogy tudja, vagy pedig a DNS serverünknek, amit használnak a gépek tudnia kell.

Ezek után el is indul a telepítés. Először kommunikációs teszt fog jönni, hogy az adott node-ról a többi node-ra lehetséges a kommunikáció. SSH vagy RSH-n kell tudni kommunikálniuk és természetesen root-ként.

Ehhez a node2-n engedélyezni kell a root logint.

node2 # vi /etc/ssh/sshd_config
PermitRootLogin yes
node2# svcadm restart ssh
Ezek után nyomhatunk „y”-t a node1 installációnál.

Adjuk meg a root jelszót a node2-nek:

Válasszuk ki, milyen típusú protokollon akarjuk a kommunikációt az installálás alatt, természetesen mi SSH-t állítottunk be, tehát 1.

Ha minden rendben van, akkor a következőt kell látnunk:

Ezek után az ellenörzés automatikusan elindul, nekünk csak várnunk kell és a VCS telepítő mind időre mind aktivitásra jelezni fogja hol jár:

Engem most figyelmezett, hogy több mint 5 másodperces eltérés van a két server órája között. Ez produktív esetben problémát jelent, tehát szinte kötelező az NTP-t közös idő szerverre állítani, de én most tovább nyomom.

Kapni fogunk egy képernyőt azzal kapcsolatban, hogy milyen csomagok és patchek fognak települni a rendszerünkre, üssünk entert:

Ezek után az installáció automatikusan elindul mindegyik node-n, amit szintén informatívan tudunk követni hála a szöveges telepítőnek:

Amikor a telepítő lefut, akkor mindkét node-n telepítve lesznek a szükséges állományok. A következő feladat a licenselés lesz erre kérdez rá még a telepítő:

Vagy megadjuk a Licens-ünket, vagy pedig license nélkül haladunk tovább. Ilyenkor 60 napig használhatjuk a terméket, minden féle feature korlátozás nélkül.

A továbbiakban választanunk kell a Standard HA és a Enterprise HA opciók között, majd bizonyos külön license opciókat is jóváhagyni:

Ezek után az installer rá fog kérdezni, hogy szerenénk-e konfigurálni a clusterünket. Én most itt nemet fogok nyomni, hogy megmutassam, hogy mi is szükséges ahhoz, aki időt akar nyerni, az nyugottan nyomhat igent is.

Ezek után már a telepítő kilép és elkezdhetjük használni a clusterünket.

A Veritas Cluster Suite részei és konfigurálása

A VCS alapvetően három nagy és főbb részből áll. Az első a HAD. Ez a High Availability Deamon. Ez felelős a folyamatok kezeléséért hiba esetén, a konfigurációért, a különböző user kommunikációkért. A következő a LLT, azaz a Low Latency Transport. Ez felelős magáért az interconnect hálózatért tehát a clusterek egymás közötti kommunikációjáért. A harmadik pedig a GAB, azaz Group membership Services Atomic Broadcast. Ez a service felel azért, hogy az LLT által nyújtott szolgáltatáson ellenőrizze a cluster tagokat, és ezek státuszinformációinak értelmezésében.

Akkor most konfiguráljuk a clustert, ehhez indítsuk el a következő scriptet scriptet:

node1# /opt/VRTS/install/installsfha -configure

Adjuk meg a 2 node nevét amit telepítettünk. Ezek után egy ellenőrzés jön, ami megvizsgálja, hogy a két node mire is lesz alkalmas.

A következő kérdés az I/O fencingre fog utalni. Ugyanis el kell döntenünk be akarjuk-e kapcsolni az I/O fencinget vagy nem. A VCS I/O fencing-nek hívja azt, amit a SUN cluster-ben quorum disk-nek hívunk. Tehát egy teljesen más, disk alapú megoldást, ami a „SPLIT BRAIN”-ek elkerülésére lehet alkalmazni. Nem feltétlenül szükséges, de ajánlott.

Mi egyenlőre hagyjuk ezt ki.

Ezen a képernyőn csak egy rövid magyarázatot kapunk azzal kapcsolatban, hogy használjuk a továbbiakban az installer interaktív menüjét, és, hogy amíg mindenen nem mentünk végig, addig nem íródik ki semmi konfigurációs file-ba. Enter.

Először is egy egyedi nevet kell adni a cluster-nek. Nem a node-knak, azoknak már van neve. Magának a gyűjtő csoportnak, amihez a cluster node-k fognak tartozni. Ennek egy szónak kell lennie.

Azután egy egyedi számot is kell a clusterhoz rendelni.

Ezek után kell az LLT rétegét megadnunk tehát a gépek közötti saját kapcsolatot, heart beatet vagy interconnectet.

Számunkra az ethernet alapú LLT tökéletes lesz, nyomjunk hát „1”-et.

Erre a rendszerünk automatikusan detektálja milyen interfacek elérhetőek, és kéri, hogy az első heartbeat linket adjuk meg a felderített listából. Én így is tettem, egy primary és egy secondary kapcsolatot definiálva:

A következő kérdés az, hogy low-priority heartbeat linket akarunk-e megadni. Ilyenkor általában a meglévő admin hálózatot szoktuk megadni. Ezt a hálózatot csak akkor használja, ha megadott interconnect kapcsolatok már nem működnek. Ez akár lehet nem dedikált csatorna is, a lényeg, hogy a két gép lássa egymást rajta.

Utolsó kérdésként rákérdez a rendszer, hogy mindkét gépen ugyan azokat a hálózati interfacekat használjuk a megadott célra. Az én esetemben igen, tehát „y”. Erre pedig indul is az ellenőrzés:

Amennyiben ez helyesen lement, egy összesítő táblázatot fogunk kapni, amit jóvá kell hagynunk:

Az adminisztráláshoz, egy speciális virtuális IP-t definiálhatunk amennyiben ezt szeretnénk, nekem viszont teljesen jó lesz most a publikus interface.

Külön szolgáltatáskénént bekapcsolhatjuk a Symantec Security Services-t, amivel az interconnecteken folyó kommunikációt is titkosíthatjuk. Kifejezetten ultrabiztonságos helyeken lehet erre igény. Nálam most feleseges, tehát „n”.

Ezek után lehetőségünk van a VCS-hez delegálni virtuális felhasználókat. Alapból egy admin/password páros áll rendelkezésre, ha ezen változtatni akarunk itt megtehetjük, én minden esetre nem. Illetve új felhasználót se akarok hozzáadni.

Lehetőségünk van leveles értesítésre, minden féle eseménynél. Ehhez definiállnunk kell egy SMTP-t. Én ezt most nem kérem tehát „n”.

Ezzel a végére is értünk a konfigurálásnak. A rendszer rá fog kérdezni, hogy leállíthatja-e a clustert, hogy kiírja a konfigurációt file-ba, majd azt betöltse:

Ezzel kész is a konfigurációja a VCS-nek.

# /opt/VRTSvcs/bin/hastatus -sum

Konfigurációs állományok

Most már látjuk,hogy is állt össze a konfiguráció, milyen értékek, információk voltka szükségesek, most nézzük meg, milyen konfigurációs állományokba íródtak ki ezek.

# cat /etc/llthosts
0 DEBRECEN-01
1 DEBRECEN-02

# cat /etc/llttab
set-node DEBRECEN-01
set-cluster 1
link ce2 /dev/ce:2 – ether – –
link ce3 /dev/ce:3 – ether – –
link-lowpri ce0 /dev/ce:0 – ether – –

# cat /etc/gabtab
/sbin/gabconfig -c -n2

# cat /etc/VRTSvcs/conf/config/main.cf
include „OracleASMTypes.cf”
include „types.cf”
include „Db2udbTypes.cf”
include „OracleTypes.cf”
include „SybaseTypes.cf”

cluster DEBRECEN (
UserNames = { admin = ejkCjeJgkFkkIskEjh }
Administrators = { admin }
)

system DEBRECEN-01 (
)

system DEBRECEN-02 (
)

Természetesen ezen konfigurációs állományokat kézzel is szerkeszthetjük, persze csak az tegye, aki tudja is mit és hogy kell.

Solaris alatt a következő servicek fognak a fentebbi konfigurációkhoz tartozni:
# svcs llt
# svcs gab
# svcs vcs

Mivel a legtöbb VCS parancs a /opt/VRTSvcs/bin/ alatt érhető el, érdemes ezt a PATH változóba beletenni:
# export PATH=$PATH:/opt/VRTSvcs/bin/

Készítsünk egy failover NFS Service Groupot

A VCS konfigurációs állományát lehet kézzel szerkeszteni, de nem ajánlott. Erre a célra jó kis vezérlő utasításokat találtak ki. Először is, hogy módosítani tudjuk a következő parancs szükséges:

# haconf -makerw

Természetesen amit ezek után adnuk meg, az csak memóriában fog éllni, hogy file-ba is kiíródjon ahhoz a következő parancs szükséges:

# haconf -dump
Vagy ha egyből le is akarjuk zárni akkor:
# haconf -dum -makero

Mi is kell egy NFS servernek

Akkor nézzük csak, mire is lesz szükségünk, ahhoz, hogy NFS servert tudjunk definiálni clusterba:

– egy network interface amin a kívánt hálózat elérhető
– egy IP cím ami a használt network interface-n működni fog
– egy disk group amibe diskek lesznek
– egy volume ami a fenti disk group-hoz tartozik és azon a kíván NFS server adatai lesznek
– egy mountpoint, ahova a volume fel lesz csatolva
– maga az NFS megosztások

A mostani példámban én kettő darab Service Group-ot (SG) fogok csinálni. A SG a SUN Clusternél a Resource Groupokkal egyezik meg. Olyan csoport, ami összefogja az egyes működési részeket, és ezzel egy teljes önálló alkalmazást emulál. Nézzük inkább, hogy is fest.

Az egyik SG lesz felelős a hálózatért, ennek a neve lesz ipSG a másik az NFS dolgaiért ennek a neve lesz nfsSG.

# hagrp -add ipSG
# hagrp -add nfsSG

Egyből meg is kell adnunk, hogy ezek a csoportok, mely node-kon lehetnek onlinek, tehát hol lehessen őket elindítani, és persze a sorszámukat, ezzel egy sorrendiséget meghatározva:

# hagrp -modify ipSG SystemList DEBRECEN-01 1 DEBRECEN-02 2
# hagrp -modify nfsSG SystemList DEBRECEN-01 1 DEBRECEN-02 2

Viszont mit is csináltunk most? A VCS minden objektumának, tehát a group-oknak és a resource-knak maguknak is vannak változóik, és értékeik. Ezeket a -display kapcsolóval láthatjuk meg. Például:

# hagrp -display ipSG

Tehát automatikusan, amikor -add kapcsolóval létrehozunk egy objektumot, akkor alapből hozzárendelünk változókat, és értékeket. A további konfigurálás pedig abból áll, hogy a -modify kapcsolóval ezeken az alapértelmezett értékeken változtatunk. Amúgy a /etc/VRTSvcs/conf/config/types.cf file tartalmazza az elérhető objektumokat.

Na, de folytassuk, akkor az ipSG-t. Ahogy mondtam ez csak egy csoport. Beállítottuk, hol tud online lenni, most már csak adnunk kell hozzá resourcekat, amik ténylegesen működtetni fogják. Mit is mondtam mi az első ami kell. Egy network interface ami a megfelelő hálózatba lóg:

# hares -add nfsNIC NIC ipSG

Jól látszik, hogy a parancs struktúrája a következő:

# hares -add ÚJ_RESOURCES_NEVE MILYEN_TIPUSU MILYEN_SERVICE_GROUPBA

Ahhoz, hogy jól működjön ebben be kell állítanunk a használni kívánt network interface nevét:
# hares -modify nfsNIC Device ce0

Mi volt a következő ami kellett? Egy IP cím, ami ezen a hálózati interfacen lehet:

# hares -add nfsIP IP ipSG

És módosítsuk azt, hogy milyen eszközön legyen, milyen cím, és milyen maszkkal.

# hares -modify nfsIP Device ce0
# hares -modify nfsIP Address 192.168.132.19
# hares -modify nfsIP NetMask 255.255.255.128

Ezzel a hálózatért felelő ipSG service group letudva. Nézzük a nfsSG-t.

Én gyorsan most összedobok egy nfsDG nevű Disk Groupot, egy vol01 nevű volumet veritas volume managerrel és vxfs-el. Akit ez részletesebben érdekel az olvassa el a cikkemet róla itt.

# vxdisk list
# /etc/vx/bin/vxdisksetup -i disk_3
# vxdg init nfsDG lemez1=disk_3
# vxassist -g nfsDG -U fsgen make vol01 100m
# mkfs -F vxfs /dev/vx/rdsk/nfsDG/vol01

Először is adjunk egy diskgroup resourcet neki.

# hares -add nfsDG DiskGroup nfsSG

Módosítsuk, hogy a mi nfsDG-nket használja:

# hares -modify nfsDG DiskGroup nfsDG

Adjuk hozzá a volume-t is:

# hares -add nfsVOL01 Volume nfsSG

Változtassuk meg, hogy a vol01 és a nfsDG legyen használva:

# hares -modify nfsVOL01 Volume vol01
# hares -modify nfsVOL01 DiskGroup nfsDG

Ezek után jöhet a mountoló resource:

# hares -add nfsMOUNT01 Mount nfsSG

Állítsuk be a mountolást mondjuk az /export/vol01-ra.

Ehhez először gondoskodjunk mindkét gépen a mountpoint meglétéről:

node1# mkdir /export/vol01
node2# mkdir /export/vol01

Aztán magát a resourcet állítsuk, be, milyen device-t moundoljon, milyen filerendszerrel, milyen FSCK optionnal és persze hova:

# hares -modify nfsMOUNT01 BlockDevice /dev/vx/dsk/nfsDG/vol01
# hares -modify nfsMOUNT01 FSType vxfs
# hares -modify nfsMOUNT01 MountPoint /export/vol01
# hares -modify nfsMOUNT01 FsckOpt ” -y”

!!!Nagyon fontos, hogy a MountPoint esetében a PATH végére ne tegyünk „/” jelet

Most jöhet a tényleges NFS resource, ami az alkalmazás lesz, ami a megosztásokat fogja kezelni:

# hares -add nfsNFS NFS nfsSG

Módosítsuk az instance számát:

# hares -modify nfsNFS Nservers 24

Végül pedig a megosztásokat magukat hozzuk létre:

# hares -add nfsSHARE01 Share nfsSG

Állítsuk be, hogy mit osztunk meg és milyen opciókkal:

# hares -modify nfsSHARE01 PathName /export/vol01
# hares -modify nfsSHARE01 Options „rw”

!!!Nagyon fontos, hogy a PathName esetében a PATH végére ne tegyünk „/” jelet

Dependenciák

Ugyanis nem mindegy ezek a resourcek milyen sorrendben indulnak el. Sőt, annak sincs értelme, hogy a mountolás megtörténjen ha még a volume nem is elérhető.

Tehát egy sorrendiséget kell felállítani. Ezt úgy tudjuk megtenni, hogy összelinkeljük megmondjuk hogy Mi ne induljon el amig EZ a resource nem fut.

# hares -link nfsIP nfsNIC
# hares -link nfsVOL01 nfsDG
# hares -link nfsMOUNT01 nfsVOL01
# hares -link nfsSHARE01 nfsMOUNT01
# hares -link nfsSHARE01 nfsNFS

Viszont nekünk két resource groupunk is van, tehát nem csak egy csoporton belüli függést kell beállítanunk, hanem a két csoport között is. Tehát amíg nincs hálózat tehát ipSG addig ne induljon el az nfsSG.

# hagrp -link nfsSG ipSG online local hard

Mielőtt indítanánk

Minden resource tartalmaz egy „ENABLED” változót. Ami alapértelmezetten 0, tehát nincs aktiválva. Ezt egyesével is bekapcsolhatjuk rajta, vagy a következő paranccsal. Tehát elindíthatóak lesznek:

# hagrp -enableresources ipSG
# hagrp -enableresources nfsSG

A másik, hogy gondoskodnunk kell arról, hogy nincs lokáis NFS service ami fut, és amivel a cluster összeakadhat. Sajnos Solaris 10 alatt ez alapértelmezett. Így törölnünk kell az SMF servicet is:

# svccfg delete -f svc:/network/nfs/server:default
# svccfg delete -f svc:/network/nfs/mapid:default

Indítás

Akkor indítsuk el, mindkét resource groupt, ami persze autómatikusan a megfelelő sorrendben elindítja majd a resource-it is.

# hagrp -online ipSG -sys DEBRECEN-01
# hagrp -online nfsSG -sys DEBRECEN-01

# hastatus -sum

Amennyiben, szeretnénk azt, hogy automatikusan induljanak a resourcek, akkor még a következő módosításokat kell eszközölnünk. Fel kell építenünk egy autostart listát:

# hagrp -modify ipSG AutoStartList DEBRECEN-01 DEBRECEN-02
# hagrp -modify nfsSG AutoStartList DEBRECEN-01 DEBRECEN-02

Készítsünk egy failover Zona resourcet

Aki esetleges nem tudná hogy a Zóna vagy Container mi is, annak ajánlom a Solaris Zónák cikkemet.

Ahhoz, hogy Zónát tudjunk integrálni VCS-be, ahhoz először is készítenünk kell egy zónát. Nem részletezném az ehhez szükséges parancsokat, akit érdekel a Zónás cikkben elolvashatja. Az egyszerűség kedvéért ZFS-t fogok használni a Zónához.

# zpool create zone c2t2d0
# zonecfg -z testzone
testzone: No such zone configured
Use ‘create’ to begin configuring a new zone.
zonecfg:testzone create -b
zonecfg:testzone set zonepath=/zone
zonecfg:testzone add net
zonecfg:testzone:net set physical=ce0
zonecfg:testzone:net set address=192.168.132.18
zonecfg:testzone:net end
zonecfg:testzone verify
zonecfg:testzone commit
zonecfg:testzone exit
# chmod 700 /zone/
# zoneadm -z testzone install
Preparing to install zone testzone.
Creating list of files to copy from the global zone.
Copying <159431> files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize <1261> packages on the zone.
Initialized <1261> packages on zone.
Zone testzone is initialized.
Installation of <2> packages was skipped.
The file contains a log of the zone installation.
# zoneadm -z testzone boot
# zlogin -C testzone
# zoneadm -z testzone halt
# zpool export zone

Most, hogy van egy zónánk, már csak magas rendelkezésreállásuvá kell tennünk. Először is kell nekünk egy Service Group. Ebbe kell, hogy legyen egy interface, amit a zona konfigban definiáltunk. Ennek elérhetőnek kell lenni, különben a zóna az életben nem fogja tudni felhúzni az IP-jét. Aztán kell egy zpool importálás. Szerencsére a zpool önagában tartalmazza a filerendszert önmagát, tehát ezzel több gondunk nem lesz.

Ezek után pedig magát a zónát kell elindítanunk. Nézzük ezt parancsok formájában:

Tegyük írhatóvá a konfigurációt:
# haconf -makerw

Hozzunk létre egy új Service Groupt:
# hagrp -add zoneSG

Módosítsük a SystemList-áját, hogy kik futtathatják:
# hagrp -modify zoneSG SystemList DEBRECEN-01 1 DEBRECEN-02 2

Akkor ahogy az NFSnél is hozzunk létre egy NIC resource-g, ami azért felel, hogy a megfelelő network interface elérhető vagy nem.

# hares -add zoneNIC NIC zoneSG
# hares -modify zoneNIC Device ce0

Adjunk hozzá egy Zpool resourcet. Ez fog gondoskodni, arról, hogy az importálás és exportálás működjön.

# hares -add zoneZPOOL Zpool zoneSG
Adjuk meg a zóna nevét:
# hares -modify zoneZPOOL PoolName zone

Most már csak egy olyan resource-ra van szükségünk, ami a Zónát magát fogja indítani illetve leállítani.
# hares -add zoneZONE Zone zoneSG
A zónák nevét viszont magába a Service Groupba kell megadnunk. Fontos, hogy ezt mindkét node-n meg kell csinálni. Az eddigieket elég volt az egyik node-n megtenni.
node1# hagrp -modify zoneSG ContainerInfo Name testzone Type Zone Enabled 1
node2# hagrp -modify zoneSG ContainerInfo Name testzone Type Zone Enabled 1

Fontos ezen túl, hogy a Zona config mindkét gépen léteznie kell. Mivel az egyik node-ra installáltuk ténylegesen ezért ott ki kell exportálnunk a configot, és létrehozni a másikon:

node1# zonecfg -z testzone export > testzone.cfg
Át kell másolni a testzone.cfg-t a node2-re, majd:
node2 # zonecfg -z testzone < testzone.cfg

Linkeljük őket össze. Konkrétan azt kell megmondanunk két paranccsal, hogy a Zóna maga ne próbáljon meg elindulni, amíg a Zpool és a Network interface nem elérhető.

# hares -link zoneZONE zoneNIC
# hares -link zoneZONE zoneZPOOL

Engedélyezzük az összes resourcest a zonaSG-ben:
# hagrp -enableresources zoneSG

Írjuk ki a konfigot file-ba is:
# haconf -dump

Indítsuk el az egészet az első node-n:
# hagrp -online zoneSG -sys DEBRECEN-01

# hastatus -sum

Ahogy látszik, a zóna nagyszerűen fut. Hogy biztosan meg tudjunk róla győződni:
#zoneadm list -cv

Service Groupok kezelése

Ezek után nézzünk pár olyan utasítást, amivel a már létrehozott Service Groupokat lehet mozgatni. Van két node természetes igény mozgatni tudjuk a Service Groupokat egymás között, tehát switcheljünk:

Először az nfs Service Groupot.

# hastatus -sum
# hagrp -switch nfsSG -to DEBRECEN-02
# hastatus -sum

Jól látszik, hogy a switchelést követve szépen átköltözött az ipSG és az nfsSG is.

Most switcheljük át a zoneSG-t is.

# hastatus -sum
# hagrp -switch zoneSG -to DEBRECEN-02
# hastatus -sum

Ha valamit le akarunk állítani használhatjuk a következő parancsot:

# hagrp -offline zoneSG -sys DEBRECEN-02

Ha ugyan ezt csak egy resource-val szeretnénk megtenni, akkor:

# hares – offline zoneZone -sys DEBRECEN-02

VCS Cheatsheet

Szerintem az alapokat és a felépítését sikerült bemutatni ezzel a cikkel a VCS-nek. Természetesen ennél sokkal többet tud. Most csak a felszínt súroltuk, azt is csak praktikus módon, amit bárki utánam tud csinálni.

A továbbiakhoz, és hogy látszódjon mennyire is komplex a VCS mellékelek egy táblázatot ami összefoglalja a használható parancsokat. Jól fog látszani, hogy egy viszonylag könnyen elsajátítható konvencióra épülnek a parancsok:

LLT and GRAB

VCS uses two components, LLT and GAB to share data over the private networks among systems.
These components provide the performance and reliability required by VCS.

LLT	LLT (Low Latency Transport) provides fast, kernel-to-kernel comms and monitors network connections. The system admin configures the LLT by creating a configuration file (llttab) that describes the systems in the cluster and private network links among them. The LLT runs in layer 2 of the network stack
GAB	GAB (Group membership and Atomic Broadcast) provides the global message order required to maintain a synchronised state among the systems, and monitors disk comms such as that required by the VCS heartbeat utility. The system admin configures GAB driver by creating a configuration file ( gabtab).

LLT and GAB files

/etc/llthosts	The file is a database, containing one entry per system, that links the LLT system ID with the hosts name. The file is identical on each server in the cluster.
/etc/llttab	The file contains information that is derived during installation and is used by the utility lltconfig.
/etc/gabtab	The file contains the information needed to configure the GAB driver. This file is used by the gabconfig utility.
/etc/VRTSvcs/conf/config/main.cf	The VCS configuration file. The file contains the information that defines the cluster and its systems.

Gabtab Entries

/sbin/gabdiskconf – i /dev/dsk/c1t2d0s2 -s 16 -S 1123
/sbin/gabdiskconf – i /dev/dsk/c1t2d0s2 -s 144 -S 1124

/sbin/gabdiskhb -a /dev/dsk/c1t2d0s2 -s 16 -p a -s 1123
/sbin/gabdiskhb -a /dev/dsk/c1t2d0s2 -s 144 -p h -s 1124
/sbin/gabconfig -c -n2

gabdiskconf

-i Initialises the disk region
-s Start Block
-S Signature

gabdiskhb (heartbeat disks)

-a Add a gab disk heartbeat resource
-s Start Block

-p Port
-S Signature

gabconfig

-c Configure the driver for use
-n Number of systems in the cluster.

LLT and GAB Commands

Verifying that links are active for LLT	lltstat -n
verbose output of the lltstat command	lltstat -nvv \| more
open ports for LLT	lltstat -p
display the values of LLT configuration directives	lltstat -c
lists information about each configured LLT link	lltstat -l
List all MAC addresses in the cluster	lltconfig -a list
stop the LLT running	lltconfig -U
start the LLT	lltconfig -c
verify that GAB is operating	gabconfig -a Note: port a indicates that GAB is communicating, port h indicates that VCS is started
stop GAB running	gabconfig -U
start the GAB	gabconfig -c -n <number of nodes>
override the seed values in the gabtab file	gabconfig -c -x

GAB Port Memberbership

List Membership

gabconfig -a

Unregister port f

/opt/VRTS/bin/fsclustadm cfsdeinit

Port Function

a   gab driver
b   I/O fencing (designed to guarantee data integrity)
d   ODM (Oracle Disk Manager)
f   CFS (Cluster File System)
h   VCS (VERITAS Cluster Server: high availability daemon)

o   VCSMM driver (kernel module needed for Oracle and VCS interface)
q   QuickLog daemon
v   CVM (Cluster Volume Manager)
w   vxconfigd (module for cvm)

Cluster daemons

High Availability Daemon	had
Companion Daemon	hashadow
Resource Agent daemon	<resource>Agent
Web Console cluster managerment daemon	CmdServer

Cluster Log Files

Log Directory	/var/VRTSvcs/log
primary log file (engine log file)	/var/VRTSvcs/log/engine_A.log

Starting and Stopping the cluster

"-stale" instructs the engine to treat the local config as stale "-force" instructs the engine to treat a stale config as a valid one	hastart [-stale\|-force]
Bring the cluster into running mode from a stale state using the configuration file from a particular server	hasys -force <server_name>
stop the cluster on the local server but leave the application/s running, do not failover the application/s	hastop -local
stop cluster on local server but evacuate (failover) the application/s to another node within the cluster	hastop -local -evacuate
stop the cluster on all nodes but leave the application/s running	hastop -all -force

Cluster Status

display cluster summary	hastatus -summary
continually monitor cluster	hastatus
verify the cluster is operating	hasys -display

Cluster Details

information about a cluster	haclus -display
value for a specific cluster attribute	haclus -value <attribute>
modify a cluster attribute	haclus -modify <attribute name> <new>
Enable LinkMonitoring	haclus -enable LinkMonitoring
Disable LinkMonitoring	haclus -disable LinkMonitoring

Users

add a user	hauser -add <username>
modify a user	hauser -update <username>
delete a user	hauser -delete <username>
display all users	hauser -display

System Operations

add a system to the cluster	hasys -add <sys>
delete a system from the cluster	hasys -delete <sys>
Modify a system attributes	hasys -modify <sys> <modify options>
list a system state	hasys -state
Force a system to start	hasys -force
Display the systems attributes	hasys -display [-sys]
List all the systems in the cluster	hasys -list
Change the load attribute of a system	hasys -load <system> <value>
Display the value of a systems nodeid (/etc/llthosts)	hasys -nodeid
Freeze a system (No offlining system, No groups onlining)	hasys -freeze [-persistent][-evacuate] Note: main.cf must be in write mode
Unfreeze a system ( reenable groups and resource back online)	hasys -unfreeze [-persistent] Note: main.cf must be in write mode

Dynamic Configuration

The VCS configuration must be in read/write mode in order to make changes. When in read/write mode the
configuration becomes stale, a .stale file is created in $VCS_CONF/conf/config. When the configuration is put
back into read only mode the .stale file is removed.

Change configuration to read/write mode	haconf -makerw
Change configuration to read-only mode	haconf -dump -makero
Check what mode cluster is running in	haclus -display \|grep -i ‘readonly’ 0 = write mode 1 = read only mode
Check the configuration file	hacf -verify /etc/VRTS/conf/config Note: you can point to any directory as long as it has main.cf and types.cf
convert a main.cf file into cluster commands	hacf -cftocmd /etc/VRTS/conf/config -dest /tmp
convert a command file into a main.cf file	hacf -cmdtocf /tmp -dest /etc/VRTS/conf/config

Service Groups

add a service group	haconf -makerw hagrp -add groupw hagrp -modify groupw SystemList sun1 1 sun2 2 hagrp -autoenable groupw -sys sun1 haconf -dump -makero
delete a service group	haconf -makerw hagrp -delete groupw haconf -dump -makero
change a service group	haconf -makerw hagrp -modify groupw SystemList sun1 1 sun2 2 sun3 3 haconf -dump -makero Note: use the "hagrp -display <group>" to list attributes
list the service groups	hagrp -list
list the groups dependencies	hagrp -dep <group>
list the parameters of a group	hagrp -display <group>
display a service group’s resource	hagrp -resources <group>
display the current state of the service group	hagrp -state <group>
clear a faulted non-persistent resource in a specific grp	hagrp -clear <group> [-sys] <host> <sys>
Change the system list in a cluster	# remove the host hagrp -modify grp_zlnrssd SystemList -delete <hostname> # add the new host (don’t forget to state its position) hagrp -modify grp_zlnrssd SystemList -add <hostname> 1 # update the autostart list hagrp -modify grp_zlnrssd AutoStartList <host> <host>

Service Group Operations

Start a service group and bring its resources online	hagrp -online <group> -sys <sys>
Stop a service group and takes its resources offline	hagrp -offline <group> -sys <sys>
Switch a service group from system to another	hagrp -switch <group> to <sys>
Enable all the resources in a group	hagrp -enableresources <group>
Disable all the resources in a group	hagrp -disableresources <group>
Freeze a service group (disable onlining and offlining)	hagrp -freeze <group> [-persistent] note: use the following to check "hagrp -display <group> \| grep TFrozen"
Unfreeze a service group (enable onlining and offlining)	hagrp -unfreeze <group> [-persistent] note: use the following to check "hagrp -display <group> \| grep TFrozen"
Enable a service group. Enabled groups can only be brought online	haconf -makerw hagrp -enable <group> [-sys] haconf -dump -makero Note to check run the following command "hagrp -display \| grep Enabled"
Disable a service group. Stop from bringing online	haconf -makerw hagrp -disable <group> [-sys] haconf -dump -makero Note to check run the following command "hagrp -display \| grep Enabled"
Flush a service group and enable corrective action.	hagrp -flush <group> -sys <system>

Resources

add a resource	haconf -makerw hares -add appDG DiskGroup groupw hares -modify appDG Enabled 1 hares -modify appDG DiskGroup appdg hares -modify appDG StartVolumes 0 haconf -dump -makero
delete a resource	haconf -makerw hares -delete <resource> haconf -dump -makero
change a resource	haconf -makerw hares -modify appDG Enabled 1 haconf -dump -makero Note: list parameters "hares -display <resource>"
change a resource attribute to be globally wide	hares -global <resource> <attribute> <value>
change a resource attribute to be locally wide	hares -local <resource> <attribute> <value>
list the parameters of a resource	hares -display <resource>
list the resources	hares -list
list the resource dependencies	hares -dep

Resource Operations

Online a resource	hares -online <resource> [-sys]
Offline a resource	hares -offline <resource> [-sys]
display the state of a resource( offline, online, etc)	hares -state
display the parameters of a resource	hares -display <resource>
Offline a resource and propagate the command to its children	hares -offprop <resource> -sys <sys>
Cause a resource agent to immediately monitor the resource	hares -probe <resource> -sys <sys>
Clearing a resource (automatically initiates the onlining)	hares -clear <resource> [-sys]

Resource Types

Add a resource type	hatype -add <type>
Remove a resource type	hatype -delete <type>
List all resource types	hatype -list
Display a resource type	hatype -display <type>
List a partitcular resource type	hatype -resources <type>
Change a particular resource types attributes	hatype -value <type> <attr>

Resource Agents

add a agent	pkgadd -d . <agent package>
remove a agent	pkgrm <agent package>
change a agent	n/a
list all ha agents	haagent -list
Display agents run-time information i.e has it started, is it running ?	haagent -display <agent_name>
Display agents faults	haagent -display \|grep Faults

Resource Agent Operations

Start an agent	haagent -start <agent_name>[-sys]
Stop an agent	haagent -stop <agent_name>[-sys]