Information Technology | Networks » NetWare Cluster Services (NCS) for Netware 5

NetWare Cluster Services (NCS) for NetWare 5™ Tartalomjegyzék Bevezető 2 Előnyök 2 Magas rendelkezésre állás 2 Kevesebb meghibásodás 2 Egyetlen rendszerkép 2 Jellemzők 3 Többcsomópontos elosztott helyreállás Átlátszó kliens-újrakapcsolódás 3 3 Nincs szükség leálláshoz a szerver karbantartásához Készen vehető hardver Egyszerű telepítés 3 3 A jogosultságok automatikus átmozgatása Split Brain Detection 3 NSS-kezelés 3 3 3 Egypontos felügyelet 3 Clusterműveletek 4 A Novell Cluster Systems architektúrája 5 Az NDS a clusterrel kapcsolatos objektumai Cluster-konténer 5 Cluster-csomópont 6 A cluster-erőforrások és -sablonok 6 Kötet-erőforrás 6 Clusterkötetek 6 Elnevezési konvenciók 7 Hagyományos kötetek 7 A NetWare Cluster Services NLM-jei Cluster Configuration Library 8 Group Membership Protocols 8 Split Brain Detection 9 Cluster Resource Manager 9 Cluster Management Agent 9 Trustee Migration

10 Frissített NLM-ek 10 Ipari szabványok 10 Storage Area Network 10 Virtual Interface Architecture 11 Az NCS rendszerkövetelményei 11 Hálózati szerverek 11 NetWare-kliens 11 8 5 Megosztott lemez-alrendszerek Összefoglalás 12 11 Bevezető A NetWare Cluster Services™ (NCS) lehetővé teszi, hogy különálló hálózati szerverek együttműködhessenek a célból, hogy magas rendelkezésre állású hozzáférést biztosítsanak a felhasználók számára a kritikus fontosságú hálózati erőforrásokhoz – az adatokhoz, az alkalmazásokhoz és más szolgáltatásokhoz. Ha a cluster egy hálózati szervere (csomópontja) meg is hibásodik, a cluster egy másik csomópontja automatikusan átveszi a meghibásodott csomópont által biztosított erőforrásokkal és szolgáltatásokkal kapcsolatos teendőket, így a clusterbe kötött erőforrások rendkívül magas szintű rendelkezésre állása biztosítható. Az NCS valódi, többcsomópontos

clustermegoldás, amelyik clusterenként nyolc csomópont kezelésére képes. Ennek eredményeképpen az NCS nemcsak, hogy magasabb szintű rendelkezésre állást képes biztosítani, mint más Intel alapú clusterrendszerek, hanem mivel képes a meghibásodott csomópont erőforrásainak szétosztására több csomópont között, a hálózat működése lényeges teljesítménycsökkenés nélkül folytatódik. A clustermegoldások a vásárlók a hálózati erőforrások magas rendelkezésre állási iránti igényére való közvetlen válaszként születtek. A magas rendelkezésre állás biztosításának elsődleges célja, hogy a hálózati felhasználók folyamatosan hozzájuthassanak igényelt adataikhoz, alkalmazásaikhoz és szolgáltatásaikhoz. A magas rendelkezésre állás ellensége minden, ami megakadályozza, hogy a felhasználók elérhessék a hálózati erőforrásokat. A hozzáférés számos okból meghiúsulhat: • A rendszer hardverelemeinek fizikai

meghibásodása • A rendszerszoftver vagy -hardver tervezési hibái • A hálózatfelügyelet és –üzemeltetés során vétett emberi hiba • Környezeti problémák, a hűtőrendszer meghibásodásától kezdve egészen a természeti katasztrófákig • Az előre betervezett karbantartás miatti lekapcsolások Álljanak le bármely okból is a hálózati erőforrások, ez szinte bármely szervezet számára profitveszteséggel jár. Egy szervezet belső rendszereinek leállása általában a termelékenység csökkenését eredményezi. A külső rendszerek – például az ekereskedelmi webhelyek – leállása nemcsak rövidtávú bevételveszteségekkel járhat, hanem hosszú távon is megtépázhatja a vásárlók megelégedettségét. A rendszerleállás elleni harc célja, hogy különféle megoldásokkal csökkentse a rendszermeghibásodásokat, illetve csökkentse a szerverek meghibásodásából vagy a rendszer karbantartásának szükségessége miatti

leállásokat. A NetWare Cluster Services mindkét oldalon hozzájárul a rendszer mennél nagyobb üzemidejéhez, a legjobb választást biztosítva a magas rendelkezésre állású clusterrendszerek között. Előnyök Magas rendelkezésre állás Ha leáll egy hálózati szerver, az NCS átlátszó módon és olyan gyorsan újraindítja a meghibásodott csomópont alkalmazásait és köteteit a túlélő csomópontokon, hogy a legtöbb felhasználó semmit sem fog észrevenni az egészből. A rendszergazdák nyugodtan dolgozhatnak a meghibásodott csomóponton anélkül, hogy a felhasználók elveszítenék a hálózati szolgáltatásokat. Kevesebb meghibásodás Az, hogy az NCS az iparág egyébként is legmegbízhatóbb hálózati platformján, a NetWare™ 5-ön fut, azt jelenti, hogy eleve kevesebb az operációs rendszerből származó hálózati meghibásodás. Emellett az NCS többcsomópontos helyreállási képessége magasabb üzemidőt eredményez a hardver- vagy

szoftvermeghibásodások esetén is, megvédve a felhasználókat a következményektől. Egyetlen rendszerkép Az NCS a hálózati erőforrásokat a clusterhez rendeli, nem pedig az egyedi hálózati szerverekhez. Bár a cluster természetesen hálózati szerverek együtteséből áll, az NCS-en keresztül az egész egyetlen rendszerként mutatkozik a felhasználók és rendszergazdák felé. Az NDS™ a szerverclustert a rendszergazdák felé is egyetlen felügyelhető objektumként jeleníti meg a Console One felületen. Jellemzők Többcsomópontos elosztott helyreállás Egy csomópont leállásakor az elosztott helyreállási (failover) funkciókkal az alkalmazások és szolgáltatások szétoszthatók a túlélő szerverekre, megakadályozva bármelyik csomópont túlterhelődését. A többcsomópontos helyreállási képesség – a Novell terminológiájával a Fan-out Failover™ – biztosítja, hogy a felhasználók még akkor is hozzáférhessenek az erőforrásokhoz,

ha a cluster egynél több csomópontja romlik el. A megosztott tárolórendszereket használó clusterekben a túlélő csomópontok fel fogják kapcsolni a meghibásodott csomópontok köteteit, és aktiválják az összes olyan clustererőforrást – például szerveralkalmazást – amelyeket a meghibásodott csomópontok biztosítottak. Átlátszó kliens-újrakapcsolódás A csomópontok meghibásodása esetén az adott csomópontra bejelentkezett NetWarekliensek automatikusan és a felhasználó számára átlátszó módon újracsatlakoznak a meghibásodott csomópont feladatait átvevő túlélő csomóponthoz. Megmaradnak a felhasználók meghajtó-hozzárendelései, valamint a Win95/98-kliensek nyitott fájljai és fájl-lezárásai. A tranzakciókövetést használó szerveralapú alkalmazások esetén beállítható, hogy meghibásodás esetén a tranzakciók a felhasználó számára láthatatlanul helyreálljanak. Nincs szükség leálláshoz a szerver

karbantartásához A NetWare Cluster Servicesszel a normális karbantartási feladatok elvégzése alatt is folyamatosan hasnzálhatják a felhasználók a cluster hálózati erőforrásait. Az egyes szerverek leállítása előtt a rendszergazdák átadhatják az adott szerver clustererőforrásait a cluster egy másik NetWare-szerverének. Készen vehető hardver A NetWare Cluster Services nem igényel semmilyen speciális, egyedi hardvereszközt. Kizárólag a készen vásárolható Intel-architektúrájú rendszereket igényli, valamint egy sor szabványos – Fibre Channel, Serial Storage Architecture (SSA) vagy SCSItechnológiára épülő – lemez-alrendszert. Az NCS-sel ezek a szabványos tárolóeszközök tárolóterület-hálózatokká (Storage Area Networks, SANS) szervezhetők. Egyszerű telepítés A NetWare Cluster Services egy munkaállomásról telepíthető, amelyik automatikusan felteszi az NCS-szoftvert a cluster összes csomópont-szerverére. A

rendszergazdáknak nem kell ténylegesen kiszállniuk az egyes hálózati szerverekhez. A jogosultságok automatikus átmozgatása Amikor egy clustercsomópont átveszi egy másik, meghibásodott csomópont erőforrásait, ez utóbbi hozzáférési jogai automatikusan átszállnak a túlélő csomópontra. Így a felhasználók továbbra is használhatják a számukra kiosztott adatokat és szolgáltatásokat. Split Brain Detection Az NCS szabadalmaztatott Split Brain Detector („tudathasadás-felismerő”, SBD) nevű technológiája arra ügyel, hogy megakadályozza azon „tudathasadásos” állapotokat, amikor egy cluster több hálózati szervere is megpróbálja felkapcsolni és használni a meghibásodott csomópont ugyanazon kötetét. Tudathasadás akkor következhet be, ha a LAN-kommunikáció megszakadása miatt átmenetileg lehetetlenné válik a csomópontok közötti normális kommunikáció. Ekkor egyes csomópontok elszigetelődhetnek, és úgy vélhetik,

kizárólag ők a túlélő csomópontok. Ez veszélyes helyzetet teremt, hiszen a csomópontok továbbra is hozzáférnek a megosztott adattároló rendszerhez, amely az adatok sérüléséhez vezet. A NetWare Cluster Service SBD e helyzetet oldja meg NSS-kezelés Azáltal, hogy a NetWare Cluster Services kezeli az NSS-köteteket is, lényegesen gyorsabban kapcsolhatják fel a túlélő csomópontok a meghibásodott csomópont köteteit. Egypontos felügyelet A NetWare Cluster Services a Novell-címtárszolgáltatásra™ (NDS™-re) épül, kihasználva annak egypontos felügyeleti képességeit. A clusterek erőforrásaival, a protokollokkal és irányelvekkel kapcsolatos adatok mind az NDS „Cluster”-konténerobjektumaiban találhatók, és felügyelhetők a Console One-on, a Novell javás felügyeleti eszközével. A rendszergazdák webböngészőn keresztül is megtekinthetik a cluster szervereinek és erőforrásainak állapotát. Clusterműveletek Az NCS normális

működése során minden egyes szervercsomópont folyamatosan kommunikál a többi csomóponttal. Az ún szolga (slave) csomópontok ún szívverés (heartbeat) jelzéseket küldenek a master csomópont felé, és a master is hasonló üzenetekkel tudatja, hogy még életben van. Ez a folyamatos kommunikáció szolgál a csomópontok meghibásodásának azonosítására. Az alábbi példa clusterbe kötött, webes szolgáltatásokat biztosító szerverekről szól. Az 1, 2 és 3 jelű webszerverek Internethozzáférést, postát és más szolgáltatásokat biztosítanak, különféle webhelyek számára Jelenleg az 1-es webszerveren csak az A és B jelű webhelyek erőforrásai futnak. Error! Bookmark not defined. ábra: Normális működés Bár e két webhely alapvetően az 1-es webszerveren fut, az erőforrások úgy vannak beállítva, hogy meghibásodás esetén képesek legyenek a cluster más csomópontjain is futni. Ha az 1-es webszerver leáll, akkor ezek az erőforrások

átkerülnek a a cluster más csomópontjaira, a 2. ábrán látható módon: Error! Bookmark not defined. ábra: Az 1 sz szerver kiesése után Az A webhely erőforrásai a 2-es, a B webhelyé pedig a 2-esre. Eközben a szükséges IPcímek, jogosultságok és licencek szintén átkerülnek a megfelelő szerverekre Az NCS-sel ez a helyreállási folyamat igen gyorsan lezajlik – a felhasználók gyakorlatilag másodperceken belül újra használhatják az Internetet és minden mást. A legtöbb esetben fel sem fog tűnni számukra, hogy átmenetileg elveszítették a kapcsolatot az erőforrásokkal. Ugyanezen példánál maradva, ha a probléma megszűnt, az 1-es webszerver újra visszakerülhet a clusterbe. Ekkor – ha úgy állítottuk be az erőforrásokat – az A és B webhelyeek erőforrásai automatikusan visszakerülnek az 1-es webszerverre, pontosan a meghibásodást megelőző állapotba. A NetWare Cluster Services-zel manuálisan is konfigurálható az erőforrások

mozgása. A rendszergazdák akkor is átmozgathatják az alkalmazásokat, webhelyeket és egyéb erőforrásokat a cluster egy másik csomópontjára, ha senki sem romlott még el, például a tervszerű karbantartás, vagy a csomópontok egyenkénti frissítése céljából való lekapcsolás esetén. A Novell Cluster Systems architektúrája Az NCS-architektúra két fő részből áll: • Az NDS Cluster objektumok a cluster-erőforrások, a csomópontok, a kötetek, az attribútumok, az irányelvek és tulajdonságok adatait tartalmazzák. • Az egyes csomópontokon futó NetWare Cluster Services NLM-ek, amelyek a cluster helyes működését biztosítják. Error! Bookmark not defined. ábra: A Novell Cluster Systems architektúrája Az NDS a clusterrel kapcsolatos objektumai A NetWare Cluster Services telepítőprogramja létrehoz egy sor NDS-objektumot a cluster-erőforrások reprezentálására, a cluster tulajdonságainak, konfigurációjának, irányelveinek, a

csomópontok címeinek és a bekapcsolt erőforrások rögzítésére. Az alábbi objektumok jönnek létre: Error! Bookmark not defined. ábra: Az NDS a clusterrel kapcsolatos objektumai • Cluster-konténer (Cluster Container) • Cluster-csomópont (Cluster Node) • Cluster-erőforrás (Cluster Resource) • Erőforrás-sablon (Resource Template) • Kötet-erőforrás (Volume Resource) Cluster-konténer Az NDS Cluster-konténer objektuma a cluster csomópontjait reprezentálja, a cluster konfigurációs paramétereit tárolja. Ezeket az egész clusterre kiterjedő beállításokat jellemzően csak egyszer kell beállítani. A cluster-konténer objektumok legfontosabb tulajdonságai az alábbiak: • Quorum Trigger (határozatképességi határ) – A Quorum Trigger paraméter azt határozza meg, hány csomópontnak kell aktívnak lennie, mielőtt a cluster-erőforrások elkezdenének betöltődni. Célszerű és szokásos ezt az értéket egynél nagyobbra

állítani, hogy egy szervertől még ne induljon be a cluster. Megadható egy kivárási idő is a Quorum Triggernél. Ha ez letelik a teljes „határozatképesség” (a megadott szám) elérése előtt, akkor a cluster-erőforrások mégiscsak elkezdenek betöltődni a cluster már élő csomópontjain. • Szívverés-beállítások – A cluster minden egyes csomópontja folyamatosan jeleket küld a master csomópont felé – ezt hívjuk szívverésnek (heartbeat). A szívverés beállításai határozzák meg, hogy a csomópontok milyen gyakran küldjék ezt a jelet. A Tolerance (tűrés) beállítása azt határozza meg, hogy a master mennyi hiábavaló várakozás után döntsön úgy, hogy a csomópont meghalt, és kezdje meg annak ellenőrzését. Hasonló beállítások, a Master Watchdog és Slave Watchdog szolgál arra, hogy a master csomópont milyen sűrűn jelezze a saját létezését a többi csomópont felé, és hogy azok mennyi idő után döntsenek úgy és

ellenőrizzék, hogy a master leállt. • Cluster Management Port (clusterfelügyeleti port) – A clusterfelügyeleti port paraméterben adhatjuk meg azt a TCP/IP-portszámot, amelyen keresztül a felügyeleti eszközök a clusterhez csatlakoznak. A cluster létrehozásakor automatikusan kap egy portszámot, amelyet nem is muszáj megváltoztatni, csak probléma (ütközés) esetén. Cluster-csomópont A Cluster-csomópont objektum a cluster egyes csomópontjainak azonosítószámát és fizikai TCP/IP-címét tárolja. Ezen objektum alapján az NCS létrehoz egy aliast (hivatkozást) a reprezentált NCP-szerverre. A cluster-erőforrások és -sablonok Minden egyes erőforráshoz és alkalmazáshoz, amelyeket a cluster csomópontjai használnak vagy futtatnak, Cluster-erőforrás objektumot kell létrehozni. Clustererőforrás lehet például egy webszerver, egy e-mail szerver, egy adatbázis-kezelő, vagy bármilyen más szerveralkalmazás és –szolgáltatás, amelynek

állandóan a felhasználók rendelkezésére kell állnia. A Cluster-erőforrás objektum tárolja ezen alkalmazások és szolgáltatások beállításait, például a preferált csomópontját, vagy azt, hogy mely csomópontokra állhat át az erőforrás meghibásodás esetén. Néhány mutatóban a clustererőforrások legfontosabb (átállítható) tulajdonságai közül: • Betöltési paranccsorozatok (Load Scripts) – A Load Scripts határozza meg azokat a parancsokat, amelyekkel a cluster-erőforrás aktiválható, például egy alkalmazást betöltő parancsokat, vagy egy kötet felkapcsolásához szükséges utasítást. E fájlok formátuma a megszokott .NCF-fájlformátum Minden cluster-erőforrásnak kell, hogy legyen betöltési paranccsorozata. • Kivételi parancssorozatok (Unload Scripts) – Az Unload Scripts tulajdonság a fordítottját határozza meg, azt, hogy milyen parancs kell egy cluster-erőforrás leállításához. A kivételi parancssorozatok

használata nem kötelező, de célszerű • Át-és visszaállási módok (Failover és Failback Modes) – A clustererőforrások át- és visszaállása történhet kézzel vagy automatikusan. Az automatikus visszaállás azt jelenti, hogy az erőforrás automatikusan visszakerül az eredeti csomópontra, ha az visszatér a hálózatba, míg a kézi beállítás emberi beavatkozást igényel. A hasonló cluster-erőforrások ismételt konfigurálásának fárasztó és unalmas folyamata leegyszerűsíthető különféle sablonok használatával. Kötet-erőforrás Az NCS megosztott tárolórendszerre épülő környezetében az NSS-köteteket lehetnek cluster- és hagyományos kötetek. Mindkét kötettípus képes átállni egy másik csomópontra, de a módszer eltér. Clusterkötetek Ha a felhasználók meg akarják őrizni az egyes kötetek meghajtó-hozzárendeléseit a csomópont meghibásodása esetén is, akkor ezt a kötetet speciálisan fel kell készíteni az

automatikus, átlátszó kliens-újrakapcsolódásra. Szintén clusterköteteket kell használnunk, ha a szerveralkalmazás egy bizonyos szervernevet használnak működésük során. Ilyen alkalmazás lehet bármi, amelyik az adatokra hivatkozáskor beleírja a szerver nevét az elérési útba. A hagyományos kötetekkel szemben a clusterkötetek nincsenek állandóan hozzákötve egy fizikai szerverhez, hanem egy virtuális NCP-szerverhez csatlakoznak. A virtuális NCPszerver proxyként (helyettesítőként) működik közben A csomópont meghibásodása esetén a clusterkötet automatikusan a cluster egy másik csomópontjára csatlakozik, és a virtuális NCP-szerver e szerver proxyjaként működik tovább.Mivel a felhasználók és az alkalmazások kizárólag a clusterkötet és a virtuális NCP-szerver (és nem a fizikai szerver) közötti kapcsolatot látják, számukra láthatatlanok maradnak a csomópontok meghibásodásai. A kötet „clusteresítésekor” három

NDS-objektum mindig létrejön: • Clusterkötet –A clusterkötetet reprezentáló NDS-objektum. • Clusterkötet-erőforrás – Ez tartalmazza a clusterkötet betöltési és kivételi parancssorozatát. Jellegében hasonlít a szerveralkalmazásokat reprezentáló clustererőforrás-objektumokra. • Cluster virtuális szerver (Cluster Virtual Server) – A clusterkötet virtuális NCP-szerverét reprezentáló NDS-objektum A clusterkötetek tulajdonságai hasonlóak a többi clustererőforráséhoz. A rendszergazdák beállíthatják a clusterkötet felkapcsolására jogosult csomópontokat, valamint a preferált csomópontot. A clusterkötetnek meg kell adni a betöltéséhez és kivételéhez szükséges parancssorozatokat is, valamint a helyreállási és visszaállási paramétereket. Minden egyes clusterkötet kap egy saját, egyedi IP-címet a virtuális NCP-szerveréhez. A kliensek nem a fizikai szerver IP-címéhez, hanem a virtuális NCP-szerverhez kapcsolódnak.

Így akkor is megmaradhat a kapcsolat a virtuális NCP-szerver és a clusterkötet felé, ha az átáll az egyik csomópontról egy másikra. A clusterköteteket a felhasználók a clusterkötet és a virtuális NCP-szerver nevén keresztül képezhetik le (így ezek sem vesznek el a kötet átállásakor). Elnevezési konvenciók Mivel a clusterkötet nem kötődik a cluster egyik fizikai csomópontjához sem, a kötet a nevét sem a fizikai szerverekről kapja, hanem a clusterről. A clusterkötet neve a clusternév és a fizikai kötetnév együtteséből fog állni (például a CLUSTER2 cluster VOL1 kötetének CLUSTER2 VOL1 lesz a neve). A célből, hogy a nevek ne ütközhessenek, a cluster minden kötetének külön, egyedi névvel kell rendelkeznie. (Vagyis ha az egyik fizikai szerveren van már egy VOL1 nevű clusterkötet, akkor a cluster más szerverén már nem lehet ugyanilyen nevű kötet.) A kötethez tartozó virtuális NCP-szerver neve kötetnév SERVER lesz, azaz az

előző esetben például CLUSTER2 VOL1 SERVER. Egy meghajtóleképezés tehát az alábbi formát ölti: F:=CLUSTER2 VOL1 SERVER/CLUSTER2 VOL1: Error! Bookmark not defined. ábra: A clusterkötet átkapcsolása Hagyományos kötetek Nincs szükség clusterkötetekre, ha a kliens nem igényel átlátszó átkapcsolást vagy a kötet szerveralkalmazásai nem használnak abszolút szerverneveket. Egy csomópont meghibásodása esetén a cluster-erőforrás (szerveralkalmazás) egyszerűen felkapcsolja a kötetet egy másik szerveren a megadott parancsorozattal. A NetWare Cluster Services NLMjei A telepítőprogram az alábbi NetWare Cluster Services NLM-eket telepíti a cluster mindegyik hálózati szerverére: Error! Bookmark not defined. ábra: A NetWare Cluster Services NLM-jei • CLSTRIB - Cluster Configuration Library (clusterkonfigurációs könyvtár) • GIPC- Group Membership Protocols (csoporttagság-protokollok) • SBD/SBDLIB - Split Brain Detector

(tudathasadás-érzékelő – csak a SAN-t használó clustereken) • CRM – Cluster Resource Manager (clustererőforrás-kezelő) • CMA - Cluster Management Agent (clusterfelügyeleti ügynökprogram) • TRUSTMIG – NDS-fájljogok mozgatója • NCPIP – Módosított NCP-protokollmag • CMON - Cluster Monitor Utility (clusterfigyelő segédprogram) Cluster Configuration Library A Cluster Configuration Library (CLSTRIB.NLM) biztosítja a NetWare Cluster Services és az NDS közötti kapcsolatot. A master csomóponton futó Cluster Configuration Library az NDS-ből kérdezi le a cluster összes konfigurációs adatát (attribútumok, protokollok stb.) A master csomópont ezután eltárolja ezeket az adatokat a helyi belső memóriájában. Szintén a master csomópont az, amelyik a clustertagok felé továbbítja ezeket az adatokat. Ha módosítjuk a cluster beállításait az NDS-ben, a Cluster Configuration Library letölti a módosításokat, kijavítja a helyi

adatokat, valamint továbbküldi a frissítéseket. Group Membership Protocols A Group Interprocess Protocol (GIPC) NLM követi figyelemmel a clustertagság változásait – lényegében a GIPC futtatja a cluster csoporttagsági protokolljait. A csoporttagságot érintő változások a csomópont belépése a clusterbe és a csomópontok kilépése a clusterből (akár meghibásodás, akár tervezett leállítás miatt). A GIPC az alábbi mikroprotokollokat futtatja a master csomóponton: • Panning – Az üzenetek szűrése „korszakokként” (epoch) • Heartbeat – Pont-pont szívverés-üzenetek készítése • Sequencer – Sorrendezi a multicastokat és a tagsági változásokat • Membership – Tárolja a „stabil” tagság adatait • Censustaker – Az instabil tagságot állapítja meg a szívverés-üzenetek alapján • Group Anchor – A csoporttagsági adatokat továbbítja a cluster slavecsomópontjai felé A cluster aktivizálódása után a

cluster master csomópontja a GIPC-protokollok segítségével tartja nyilván, hogy a cluster mely tagjai vannak éppen életben. Időről időre a Censustaker jelentést készít arról, hogy szerinte mely tagok vannak életben. Ha például nem kap szívverés-üzenetet a Tolerance beállítással meghatározott időn keresztül, a Censustaker kiad egy jelentést arról, hogy a csomópont elhagyta a clustert. A jelentés mindaddig „instabilnak” számít, amíg a cluster összes csomópontja el nem fogadta. A tagsági protokoll a Group Anchor és a Sequencer segítségével biztosítja a csomópontok egyetértését. A Group Anchor továbbküldi a jelentéseket, míg a Sequencer biztosítja, hogy mindegyik csomópont meg is kapja ezeket, és hogy ugyanolyan sorrendben kapja meg őket. Ennek eredményeképpen a cluster minden tagja ugyanazt a képet látja Ha a csomópontok megegyeznek a javasolt tagsági állapotban, akkor az ténylegessé (stabillá) válik. Ha valamiért e

folyamat közben leáll a master csomópont, akkor úgy mastert választanak, és ismét csak elérik a stabil állapotot. Split Brain Detection A megosztott tárolórendszereket használó clusterek esetében probléma származhat abból, ha a csomópontok úgy esnek ki, hogy megszűnik közöttük a normális kommunikáció (például egy Ethernet-kapcsoló romlik el a két rész között), és az izolált darabok szerverei közül kettő úgy gondolja, hogy kizárólag ő (vagy az ő csoportja) maradt életben. Mindkét oldal tehát meg fogja próbálni felkapcsolni a kiesett köteteket, elindítani a másik oldal alkalmazásait, stb. Ennek megakadályozására a NetWare Cluster Services a szabadalmaztatott Split-Brain Detector (SBD) protokollt használja. Az SBD a megosztott lemezekkel való kapcsolatot használja alternatív kommunikációs csatornaként. Az NCS létrehoz egy speciális partíciót a megosztott lemezen, amely az egyes csomópontok a clustertagságról látott

képét tartalmazza. A cluster minden egyes csomópontjának saját területe van ezen a partíción, ahová a szerinte pontos tagsági adatokat írja. A csomópont a saját részét írhatja és olvashatja, de a másokét csak olvashatja. Tagságváltozáskor az SBD megvizsgálja ezt a partíciót, hogy talál-e következetlenséget a különböző csomópontok által felírt adatokban. Következzen egy példa, hogy hogyan oldja fel az SBD egy négycsomópontos cluster tudathasadását: 1. Amikor a négy csomópont először lép be a clusterbe, felírják a területükre, hogy az 1. korszakban (Epoch 1) vannak, A, B, C és D tag-csomópontokkal 2. A LAN meghibásodása miatt a C csomópont kommunikációja megszakad A-val és B-vel. 3. Az SBD megvizsgálja a megosztott partíciót, és azt találja, hogy A és B mindketten azt jegyezték fel, hogy a 2. korszakba léptek, A és B tagokkal, míg a C azt, hogy szintén a 2. korszakba lépett, de csak saját magával (C), mint taggal Az

SBD megállapítja, hogy ez tudathasadás, hiszen A, B, és C egyaránt a 2. korszakba lépett, de nem értenek egyet. Tudathasadás felderítésekor az SBD lezárja a hasadás egyik felét. Ez muszáj az adatok sérülésének megakadályozásához. A SBD igyekszik a kevesebb csomópontot tartalmazó oldalt lezárni; ha egyforma nagyok, akkor a master csomópontot tartalmazó marad aktív. Cluster Resource Manager A Cluster Resource Manager a csoporttagsági protokollok tetején ülve biztosítja, hogy a clustererőforrások a cluster megfelelő csomópontjain futnak. A master csomóponton futó CRM értesítést kap minden egyes tagságváltozásról, és ennek alapján határozza meg, hogy mely clustererőforrásokat melyik csomópontra töltse be. A clustererőforrások állapotát a master csomópont továbbítja a cluster többi csomópontja felé. Ha a master csomópont leáll, egy túlélő csomópont lesz az új master. A Cluster Resource Manager az erőforrásokról

nyilvántartott állapotát az alábbi táblázat foglalja össze: Erőforrás állapota Unassigned Offline Loading Unloading Comatose Running Alert NDS Sync Quorum Wait Leírás Nem képes futtatni a clustererőforrást, mivel az erőforrások preferált csomópontjai éppen nem tagjai a clusternek. Nyugvó; az erőforrás tulajdonságai szerkeszthetők. Jelenleg fut az erőforrás betöltési parancssorozata. Jelenleg fut az erőforrás kivételi parancssorozata. Nem sikerült a teljes parancssorozatot végrehajtani a timeout előtt. Azonosítva; fut. Az erőforrás emberi beavatkozást igényel. Az erőforrás az NDS-tulajdonságokkal való szinkronizálásra vár. Az erőforrás arra vár, hogy elegendő csomópont csatlakozzon a clusterhez. Cluster Management Agent A Cluster Management Agent (CMA) a ConsoleOne proxyjaként működik. Aszinkron, egyedi protokoll, amelyik a cluster a ConsoleOne-t futtató kliens munkaállomás között foglal helyet. A CMA a ConsoleOne-nal

együtt vezérli a cluster aktuális állapotát, képes módosítani a cluster beállításait az NDS-ben, illetve kijelezni a cluster állapotát. A CMA a CRM-mel együtt meghatározza, mely csomópontok aktívak, és vezérli azok állapotát. +Error! Bookmark not defined. ábra: Trustee Migration A TRUSTMIG NLM mozgatja át a meghibásodott csomópont clusterkötetéhez kapcsolódó NDS-jogokat a kötetet felkapcsoló túlélő csomópontra. Enélkül a felhasználók nem lennének képesek hozzáférni az adatokhoz és szolgáltatásokhoz. Frissített NLM-ek Az NCS telepítőprogramja két NLM-et frissít fel a cluster csomópontjain. Az NCPIP NLM-et azért, hogy a clusterkötetek a virtuális NCP-szerverekhez köthetők legyenek, illetve az átlátszó, automatikus kliens-újrakapcsolódás érdekében. A Cluster Monitor (CMON) pedig egy konzolprogram, amellyel a csomópontok állapota kérdezhető le. Ipari szabványok Storage Area Network Egy tipikus

NCS-konfigurációban a csomópontok egy Storage Area Network (SAN) vagy valamilyen más megosztott lemez-alrendszeren osztozkodnak, hogy ha a cluster bármelyik csomópontja le is áll, a szolgáltatások és az adatok simán átvihetők legyenek egy másik csomópontra. Az NCS és a Storage Area Network-ök (SAN-ok) kombinációja vonzó megoldás lehet minden olyan szervezet számára, akik extrém magas rendelkezésre állást várnak el a hálózati szolgáltatásoktól és az adat-erőforrásoktól. A SAN-ok intézik az adat-erőforrások a hálózati szerverek közötti megosztását – nélkülük a tárolóeszközök nem köthetők egyetlen szerverhez, hanem fizikailag kapcsolódniuk kell több hálózati szerverhez. A hálózati szerverek és a SAN közötti kapcsolat jellemzően optikai kábelen keresztül történik – így akár 10 kilométer távolság is lehet a SAN és a hálózati szerverek között. Mindez nem eredményez lassabb adathozzáférést, mintha helyben

lennének a meghajtók, hiszen az üvegszál több száz megabit/másodperces átviteli sebességre képes. Error! Bookmark not defined. ábra: NCS és SAN Azért, hogy a hibatűrést a lemezek szintjén biztosítsák, a SAN-konfigurációk jellemzően RAID Level 5 lemez-alrendszereket használnak. Mindez nem jelenti azt, hogy más tárolási megoldások nem használhatók. Egy kétcsomópontos cluster helyi lemezei például tükrözhetők. Ebből egy SFT III-szerű funkcionalitás jön létre, a megosztott lemez-alrendszer igénye nélkül. Ahol a cluster nem igényel „szoros” (azonnali) szinkronizációt, a Novell Replication Services™ (NRS™) is használható a szerverek közötti adatok replikálására. Tremészetesen ebben az esetben nem garantálható, hogy a túlélő csomópont hajszálpontosan meg fog egyezni a meghibásodott csomóponttal. Virtual Interface Architecture A Virtual Interface Architecture (VIA) egy, az Intel, a Microsoft és más vezető

technológiagyártók által javasolt kapcsolatiprotokoll-szabvány, kifejezetten clusterrendszerek belső, nagy teljesítményű, kevés felesleges átvitellel járó, pont-pont üzenettovábbításához. A VIA programozási felülete Virtual Interface Provider Library (VIPL) névre hallgat. Az NCS a VIPL egyes API-jait használja a clusteresemények közvetítésére a csomópontok között. A VIPL API-k kezelésével az NCS a külső fejlesztők clustereredményeit – például az Oracle Parallel Serverét (OPS) – is képes hasznosítani. Ezenfelül egy sor külső fejlesztő már bejelentette, hogy felkarolta a VIA-t, és hamarosan a VIA-ra és a VIPL-re épülő meghajtóprogramokat szállít. Ilyen cég például a Compaq, a Dolphin ICS, a Myricom, a Giganet, a Fujitsu és a Sarnoff. Az NCS rendszerkövetelményei Hálózati szerverek A NetWare Connect Services Support Pack 3-mal (vagy frissebbel) ellátott NetWare 5-öt igényel minden egyes clusterszerveren. A szervereknek

ezenfelül az alábbi követelményeknek kell megfelelniük: • Clusterenként legalább két és legfeljebb nyolc NetWare 5 szerver. • A cluster összes szerverét IP-re kell konfigurálni, és ugyanazon alhálón kell lenniük. • Legalább 64 MB memória kell, hogy legyen a cluster mindegyik szerverében, de 128 MB vagy több ajánlott. • A cluster mindegyik szerverének ugyanazon NDS-címtárfában kell lennie. • Minden egyes szervernek kell, hogy legyen legalább egy saját, helyi, nem megosztott eszköze a SYS: kötet számára NetWare-kliens Az NCS az összes NetWare 5 klienst kezeli, de célszerű a NetWare 5 kliens legfrissebb változatát (vagy az NCS-sel kapottat) használni. Ezek a NetWare 5 kliensek kifejezetten az NCS-környezettel való együttműködéshez lettek hangolva. Mindenképpen kell telepíteni ezeket a klienseket a cluster felügyeletére szolgáló munkaállomásokon, csakúgy, mint a Console One-t. Szintén ajánlott, hogy a felügyeleti

munkaállomások legalább 300 megahertzes vagy gyorsabb processzorral, és legalább 90 MB memóriával legyenek felszerelve. Megosztott lemez-alrendszerek Ajánlatos minden clusterben megosztott lemez-alrendszert telepíteni. Ha így teszünk, biztosítsuk, hogy: • Legalább 10 MB szabad lemezterület található a lemez-alrendszer a speciális clusterpartíció számára. Az NCS telepítőprogramja automatikusan lefoglalja erre a lemezalrendszer első sávját Ha a lemez-alrendszer összesen 10 gigabájtnál nagyobb, akkor még több szabad helyre lehet szükség. • kell. A lemez-alrendszert helyesen, a gyártó előírásai szerint telepíteni és konfigurálni • Minden megosztott lemezköteten be kell kapcsolni a Novell Storage Servicest. • A lemez-alrendszer köteteit tükrözött vagy RAID 5 konfigurációban használjuk a hibatűrés megnövelésére. Ha nem így teszünk, egyetlen eszköz képes lesz leállítani a teljes rendszert – ez ellen pedig nem véd a

NetWare Cluster Services szoftver. Összefoglalás A NetWare Cluster Services magasabb rendelkezésre állást biztosít a hálózati alkalmazások, adatok és más erőforrások számára, mint bármelyik másik vetélytárs Intel-alapú clusterrendszer. Automatikusan képes helyreállítani az erőforrásokat, több csomóponton is elosztva, és a felhasználók számára láthatatlan újrakapcsolódási funkciók biztosítják, hogy a felhasználók folyamatosan hozzáférhessenek a hálózati erőforrásokhoz, teljesítményveszteség nélkül. S mivel az iparág vezető címtárszolgáltatására épül, a rendszergazdák a cluster felügyelete során kihasználhatják az NDS kényelmét és biztonságát. Az NetWare Cluster Services kiváló méretezhetőséget, felügyeletet és rendelkezésre állást kínál