Informatika | Hálózatok » Cluster a gyakorlatban

NetAcademia-tudástár Farkasokkal táncoló I. – Cluster a gyakorlatban Wolfpack annyit tesz: farkasfalka. Wolfpack volt a kódneve annak a szoftvernek, amelyet a Microsoft 1997-ben adott ki, és a világ clusterserverként ismert meg. Az a szándék, hogy minél nagyobb rendelkezésre állást lehessen biztosítani a Windows NT alapú rendszereknek, ebben a szolgáltatásban kristályosodott ki leginkább. Magyarországon még a Windows megbízhatatlanságának van híre, pedig már sok éve másról szól a fáma. Ezzel a cikksorozattal a Windows 2000 Advanced Server cluster (magyarul kiszolgálófürt) szolgáltatását szeretném egy kicsit alaposabban bemutatni. Mivel gyakorló rendszermérnök vagyok, szeretném feltárni az olvasó el tt azokat a motivációkat, amelyek a megvásárlás mellett szólhatnak, a m szaki környezetet, amelyet a szoftver igényel, és mindenekel tt a tapasztalatot, amelyet az elmúlt hónapokban megszereztem. Találónak érzem az egykori

kódnevet: a clusterek nagy, er s és összetett rendszerek, amelyekhez fontos az alapos felkészültség. De aki bátor, az akár a farkasokkal is táncol. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár Mi a szerverfürt? A szerverfürt egy vagy több olyan kiszolgáló, amelyek megfelel hardvereszközök megléte esetén együttm ködnek, hogy a rendszergazdák által definiált szolgáltatásokat a lehet legkisebb kieséssel m ködtessék. Els pillantásra furcsának t nhet az „egy” a meghatározásban, de majd látható, hogy ennek is van értelme. Hogy a továbbiakban a fogalmi rendszer egyértelm legyen, meg kell határoznunk néhány, a kés bbiekben gyakran el forduló kifejezést. Az állomás (node): Ha a cluster azt az együttest jelenti, amely a szolgáltatásokat folyamatosan biztosítja, akkor az állomás a cluster egyik gépe. A Windows NT Server 40 Enterprise

Edition és a Windows 2000 Advanced Server cluster maximálisan két állomásból állhat. A Windows 2000 Datacenter Server segítségével 4 node-ból álló cluster is építhet A fürtszolgáltatás (cluster service): Egy szabványos NT szerviz, amely mindkét állomáson fut, feladata pedig a rábízott er források biztosítása az ügyfelek felé. A szolgáltatás egy megfelel jogosultságú tartományi fiók kontextusában m ködik Az er forrás (resource): Egy olyan hardver, szoftver vagy logikai komponens, amely m ködéséért a clusterszolgáltatás felel. Er forrás lehet egy lemez, egy NetBIOS gépnév, egy szolgáltatás (service) vagy akár egy IP cím is Quorum disk: Az er források között van egy különleges, a quorum disk. Ez egy olyan lemez, amely a két állomás közös „tudását” tartalmazza (egy adatbázis formájában) a cluster konfigurációjáról és állapotáról. Függ ség (dependency): Az er források nem elszigetelt egységek, hanem

egymással kapcsolatban állnak, függnek egymástól. Például egy adatbáziskezel nek szüksége van az adatbázis fájljaira és tranzakciós állományaira ahhoz, hogy elindulhasson. Ezek azonban egy lemezen találhatók Az adatbáziskezel szolgáltatás er forrás tehát függ egy lemezer forrástól. A csoport (group): A logikailag együtt kezelt er források csoportot alkotnak. A fürtszolgáltatás általában er forráscsoportokat és nem egyedi er forrásokat kezel. A csoportokat a rendszergazdák alakítják ki úgy, hogy minden er forrást tartalmazzanak, amely egy alkalmazás üzemeltetéséhez szükséges. Egy SQL Serverhez szükséges például egy gépnév, egy IP cím, egy lemez, és az MSSQLServer er forrás. SQL Server a fürtben Átköltözés (failover): Ha egy állomás nem képes m ködtetni egy adott er forráscsoportot, akkor a fürtszolgáltatás átköltözteti az egészet a másik állomásra. Az átállás tényét a quorum disken található

fürtadatbázisban rögzíti Visszaköltözés (failback): Ha már mindkét állomás képes üzemeltetni az er forráscsoportot, akkor a cluster a visszaköltöztetési szabályok alapján helyreállítja az eredeti feladatmegosztást. A szabályokról a kés bbiekben szó lesz Virtuális kiszolgáló (Virtual server): Az er forráscsoportok beállíthatók úgy, hogy a felhasználók számára mint valóságos kiszolgálógépek jelenjenek meg. Ehhez az szükséges, hogy legyen név- és IP cím er forrásuk Azok a csoportok, amelyek rendelkeznek ilyen er forrásokkal, virtuális kiszolgálók is egyben. Szívhang (Heartbeat): Az állomások folyamatosan figyelik egymás állapotát, pontosabban azt, hogy képesek-e reagálni kérésekre. Ezt a forgalmat nevezzük szívhangnak A cluster Microsoft-féle implementációja az ún. „shared-nothing”, vagyis a „semmi közös” elven épült Ez azt jelenti, hogy a cluster által definiált er források egy adott pillanatban csak az

egyik szerverhez tartoznak, a másik nem férhet hozzájuk. Hiba esetén fordul a kocka, és a másik állomás válik az er források birtokosává. Közös er források, amelyek fölött egyszerre gyakorolnának felügyeletet a node-ok, nincsenek, - vagyis semmi sem közös. Ez az elv azonban nem tévesztend össze azzal a ténnyel, hogy léteznie kell olyan (merevlemez) eszköznek, amelyeket mindkét állomásnak el kell érnie. Ez az eszköz legtöbbször egy merevlemez-alrendszer, amely fizikailag közös. Tehát egy kiépített cluster rendelkezik egy fizikai szinten mindkét állomás számára elérhet lemezrendszerrel, amelyben az egyes lemezek vagy az egyik, vagy a másik node-hoz tartoznak egy id pillanatban. Még néhány általános tudnivaló. A clusterszolgáltatás leginkább kapcsolatorientált szoftverek rendelkezésre állásának növelésére való. Ilyen például az SQL Server vagy az Exchange Ezt a szabályt azonban nem kell k be vésettnek tekinteni, mert a

DHCP, WINS, s t még az IIS is fürtözhet . A kapcsolatmentes technológiák (Például IIS) rendelkezésre állásának növelésére mégis inkább más módszerek használatosak, els sorban a Network Load Balancing Server, mert NLBS-sel akár 32 állomást magában foglaló fürt is építhet . Vannak továbbá olyan szolgáltatások, amelyek állandó elérhet ségére az elosztott architektúrák a megfelel ek. Ilyen az Active Directory vagy a DNS A clusterszolgáltatás a Windows 2000 Advanced Server és a Windows 2000 Datacenter Server része. A Windows 2000 Server nem tartalmazza ezt a komponenst. Az Advanced Server ára jóval magasabb, mint az egyszer Windows 2000 Serveré (kb. háromszorosa), alaposan mérlegelni kell tehát a váltást Windows NT 40 Serverr l Windows 2000 Advanced Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár Serverre frissíteni a szoftvert alig

valamivel kevesebb, mint egy teljesen új licencet vásárolni, Windows NT 4.0 Enterprise Editionr l viszont az átállás jóval barátságosabb. A magasabb árért cserébe az Advanced Server els sorban a rendelkezésre állást növel szolgáltatásokban nyújt többet, s a cikksorozat végére kiderül, hogy b ven „megéri az árát”. Hogyan m ködik a fürt A szerverfürt közös tudása a quorum lemezen található, amelyet leginkább egy dedikált, vagyis csak erre a célra használt, merevlemezen elhelyezked tranzakciós adatbázisként lehet elképzelni. Ez a közös tudás definiálja a csoportokat és bennük az er forrásokat, valamint azt, hogy a csoportokat mely node-ok birtokolhatják. Ha valamilyen oknál fogva az egyik gép nem képes az általa birtokolt csoportok számára a m ködést biztosítani, akkor a másik állomás átveszi a csoportok m ködtetését. A felhasználók, akik ténylegesen a virtuális kiszolgálók szolgáltatásait veszik igénybe, nem

észlelik a hibát, vagy csak rövid kiesést tapasztalnak. Ha ábrázolni kell a szerepl ket, akkor leginkább egy ingaórához hasonló szerkezetet rajzolhatunk Felhasználók Virtuális gép Node 1 Node 2 A virtuális kiszolgálók ingázása Jogos a kérdés, hogy mi történik akkor, amikor az inga épp a két állomás között jár. Akkor is üzemel a szolgáltatás? Nem A cluster nem biztosítja a teljes, 100%-os rendelkezésre állást, nem tükrözi a hálózati kapcsolatokat, és az ügyféloldali szoftver tulajdonságai határozzák meg, hogy a felhasználó észreveszi-e a kimaradást. Ha például kiszolgálóoldalon egy Exchange szoftvert futtatunk egy fürtön, a ügyféloldalon pedig egy Outlook dolgozik, akkor az Outlook az „inga” átbillenése után ott folytatja, ahol korábban abbahagyta. Egy SQL Server kliens, f leg egy felette futó alkalmazás (SAP, JDE stb) viszont igényelheti az ügyfelek újraindítását. Az inga átlendülése tehát kritikus

tényez , szerencsére az állomások ezt nagyon gyorsan elvégzik. (Egy JD Edwards B7331 és egy SQL Server 2000 150 egyidej felhasználó esetén 10 másodperc alatt vándorol át egyik fürttagról a másikra. Ez saját tapasztalat, de ett l lehetnek eltérések, amelyet az er források száma és természetesen a kiszolgálók izmossága is befolyásol.) Szóval 10 másodperc kiesés. Sok? Hasonlítsuk ezt össze azzal a leállással, amit egy nem cluster gép nyújt, amelyiknek meghibásodik a processzora. Mennyi ideig tart azt kicserélni, még ha van is alkatrész? Egy óra? És ha nincs alkatrész? Két nap? Két nap helyett 10 másodperc. Jó csere? De mondhatok más példát is Ha tervszer en karbantartást kell végezni, mikor és mennyi id alatt történik ez meg? Egy éjszaka alatt? Egy hétvégén? Mennyi ennek a költsége? Nem egyszer bb nappal, munkaid ben dolgozni? A cluster ezt lehet vé teszi. Az er források éjszaka átcsoportosíthatók az egyik állomásra,

reggel pedig lehet karbantartani (ütni) a másikat. Erre ideális a szerverfürt A cluster konfigurációja Tekintsük át, mire érdemes ügyelni egy clusterkörnyezet tervezésekor. A Microsoft azt javasolja, hogy egy cluster kevés számú, jól definiált szolgáltatást nyújtson, továbbá minden funkciót a fürtszolgáltatáson keresztül érjenek el a felhasználók. Ezt én egyszer és tiszta konfigurációnak nevezem. Egyszer , mert kevés alkalmazást felügyel a cluster szerviz, és tiszta konfiguráció, mert nincs fürtön kívüli funkció. Az ajánlás mögött az az elgondolás húzódik meg, hogy ilyen rendszer üzemeltetése jóval kiszámíthatóbb és egyszer bb, és várhatóan beváltja a hozzá f zött magas rendelkezésre állás reményét. Egy apró szépséghibája van a fenti gondolatnak: nagyon drága Ha állandóan szeretnénk biztosítani a felhasználók számára a nyomtatás lehet ségét, a levelezést, a vállalatirányítási rendszert, a

felhasználói könyvtárakat, a névfeloldást stb. stb és mindig egy-egy új fürtbe kötött szerverpárt állítanánk be, igencsak megcsapolnánk a vállalatunk beruházásra fordítható pénzeszközeit. Ez nem járható út A hasznos azonban lehet viszonylag olcsó is, csupán annyit kell tenni, hogy a szolgáltatásokat egyetlen clusterre kell költöztetni. Ha egyetlen, jól megtervezett, er forrásokkal ellátott kiszolgálópárra telepítünk mindent, akkor akár már a beruházási költségek is összevethet ek lesznek 5-6 különálló kiszolgáló megvásárlásával. A rendelkezésre állás és az üzemeltetési költségek pedig össze nem hasonlítható módon jobbak lesznek, mivel az egyszer megvásárolt redundancia minden szolgáltatásra kiterjed, míg különálló gépek a tartalékok hiánya miatt nem képesek megbízhatóan kiszolgálni a felhasználókat, legalábbis a fürthöz viszonyítva nem. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás

nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár Mindenképp ajánlatos tehát, hogy minél több szolgáltatást biztosítson egy fürt, mert a kiajánlott szolgáltatásokra jutó fajlagos redundanciaköltség így alacsonyabb lesz. Igen, igen, ez a szerverkonszolidáció Meggy z désem, hogy nem is olyan sokára ez a nézet általánosan elterjedt lesz, és a Windows kiszolgálófürt nem csodabogár ritkaságként gubbaszt egy teremben, hanem általános és olcsó módja lesz a rendelkezésre állás növelésének. Nem tartozik a cikk keretei közé egy kiszolgáló méretezésének elemzése, ezért processzorszámra és memóriaméretre nem tudok javaslatot tenni. Néhány szót azonban érdemes szentelni a közös lemezek kialakítására A legegyszer bb megoldás a közös SCSI busz alkalmazása. Kétségtelenül olcsóbb megoldás, de nem számol a jöv vel A clustert nem egy évig használjuk majd és nem is kett ig. Olyan módszert

érdemes alkalmazni, amely a technológiai életciklusa elején jár, így van esélye annak, hogy pár év múlva nem fogunk b víthet ségi problémákkal küzdeni. Ma a tárolórendszerek terén a jöv be mutató szabványok a Fibre Channel technológia és a Storage Area Network. Nemcsak nagyobb sávszélességet nyújtanak, de rugalmasabb konfigurációt is lehet vé tesznek. Ha tehát ez lehetséges, javaslom a SAN-megoldások alkalmazását A SAN szintén egyfajta konszolidáció, csak épp az adattárolás területén. Ez egy olyan adattároló hálózat, amelyben kiszolgálók, merevlemeztömbök és szalagos könyvtárak kapcsolódnak egymáshoz SAN hálózati eszközökön keresztül, amelyeket (hogy az életet ne bonyolítsuk) éppúgy huboknak, switcheknek és routereknek hívunk, mint a hagyományos hálózati eszközöket és szerepük a nevükhöz hasonlatos. A SAN bels titkait most nem részletezve annyit érdemes elmondani, hogy SAN hubot akkor érdemes használni, ha

az (adat) hálózaton kommunikálók száma viszonylag kevés (pl. egy cluster és egy-két merevlemez alrendszer), a switch viszont alkalmasabb a két vagy több clustert magában foglaló rendszerekhez. Mellesleg a SAN rendszer egyik el nye, hogy elegend egyetlen mentést végz eszközt (pl tape library-t, szalagos könyvtárat) vásárolni, az képes lesz a teljes adattároló hálózat lementésére úgy, hogy a tényleges (pl. Ethernet) hálózatot nem terheli. A mentési eszköz ugyanúgy közös, mint a lemezalrendszerek, tehát bármely gép használhatja A kiszolgálókat egy SAN-hálózathoz ún. gazdaadapterekkel (host adapter) lehet kapcsolni A nagyobb sebesség érdekében érdemes a 66MHz-es PCI buszokat használni erre a célra. Egy egyszer fürt SAN rendszerrel az ábrán látható módon nézne ki. Node 1 Node 2 SAN Hub HS1 HS2 O K1 OK2 PS Disk alrendszer 1 2 3 4 5 6 7 8 9 101112 CO LACT ST A- CON SOLE Data router Tape library Kiszolgálófürt SAN-nal Ez szép

is, jó is, olcsó is, csak egy apró gondja van. A fürtszolgáltatást azért telepítjük, hogy hiba esetén a beépített és felkészített redundancia megakadályozza a szolgáltatás kiesését. Csakhogy a szépen felépített szoftverredundanciánkat tönkretettük azzal, hogy egyetlen hubra bíztuk a teljes adathálózat kommunikációját. Ez bizony hiba A tervezés során módszeresen irtani javallott a „single point of failure”-t, vagyis az egy pontból ered megbízhatatlanságot, költ i fordításban az Achilles-sarkot. A teljes redundanciának persze megint csak ára van, de némi mérlegelés után belátható, hogy ez már nem nagy tétel. Célszer redundáns vezérl vel ellátni a lemezalrendszert is, be kell építeni egy további SAN hubot (vagy switchet). A „mindent a felhasználóért" konfiguráció valahogy így néz ki: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4

NetAcademia-tudástár Node 1 Node 2 SAN Hub SAN Hub disk alrendszer 1 2 34 56 7 8 9101112 HS1 HS2 OK1 OK2 PS COLACTSTA- CON SOLE Data router Tape library Redundáns SAN hálózattal Achilles ellen! Gyakorlati tapasztalatként annyit f zök a fenti ábrához, hogy nem minden gyártó rendelkezik olyan SAN hubbal, amelyhez data router csatlakoztatható, ekkor viszont az általuk kínált switch árfekvése némileg kedvez bb a konkurenciáénál. Vásárlás el tt érdemes leülni a lehetséges szállítókkal, és alaposan végigtárgyalni az igényeket. Meggondolandó továbbá, hogy a data router vajon mindkét hubhoz csatlakozzon-e. Amúgy is csak egy van bel le, ráadásul „csak” a mentést biztosítja, vagyis a rendelkezésre állásával szembeni követelmények – tartalék eszközr l lévén szó - mindenképp alacsonyabbak, mint a kiszolgálók esetén. A lemezalrendszer kontrollere képes hardveres redundancia létrehozására (RAID 1, RAID5, RAID 0+1), melyre

nagy szükség van, a cluster ugyanis nem kezeli a szoftveres merevlemeztömböket. Hogy ez miért van így, arról még értekezünk Látható, hogy a kiszolgálófürtök beszerzése nem a „Józsi-most-van-akció-vegyetek-egy-szervert” alapon történik. Alaposság, megfontoltság, tervezés – ezek a f feltételei annak, hogy az ember nekiugorjon a farkasfalkának. Legközelebb meg is tesszük. Lepenye Tamás (MCSE) lepenyet@mal.hu Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár Farkasokkal táncoló – II. Cluster a gyakorlatban Miután elsajátítottuk az alapfogalmakat és összeállítottunk egy Achilles sarkoktól mentes konfigurációt, megkezdhetjük az el készületeket a telepítésre, majd el is végezhetjük azt. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár El

készületek El kell döntenünk, hogy hány er forráscsoportot, illetve virtuális szervert szeretnénk létrehozni. A számuk id vel persze változhat, de most azért van erre mégis szükség, mert minden egyes csoporthoz külön lemezt kell rendelni. A lemez (physical disk) egy er forrás, az pedig egyszerre csak egy csoporthoz tartozhat. A cluster bizonyára egy lemezalrendszert ér el, amely egy vagy több redundáns lemeztömböt (disk array) tartalmaz. Ezek a lemeztömbök valamilyen hardveres redundanciával kell, hogy rendelkezzenek attól függ en, hogy milyen alkalmazás használja majd ket. A lemeztömbök fölött a diszkalrendszer számára logikai lemezeket lehet definiálni. Ezeket a logikai lemezeket az operációs rendszer fizikai lemezként fogja felismerni. Az alábbi ábra egy lehetséges lemeztömbfelosztást mutat be, a következ pedig azt, miként látja ugyanezt a Windows 2000. A lemeztömbök a lemezvezérl fel l nézve és a Windows 2000 szerint.

Valamennyi általam ismert lemezvezérl képes arra, hogy m ködés közben új lemezeket fogadjon a tömbbe, s azokon újabb logikai (a Windows számára fizikai) lemezeket hozzon létre. Jóval kényesebb kérdés a már meglév logikai lemezek megnövelése. Ez sem lehetetlen, de általában már csak borsos árú kiegészít szoftverekkel lehet elvégezni Ennek hiányában nem kis er feszítés lesz a megtelt lemezt nagyobbra cserélni. Fontos kiegészítés, hogy a definiált diszkek éppúgy viselkednek, mintha tényleges lemezek volnának. Ez többek közt azt is jelenti, hogy rajtuk (els dleges) partíciókat lehet létrehozni. Az er forráscsoportok azonban nem ismernek „partíció” er forrást, tehát ha egy lemezen több partíció van, akkor mindegyik azonos csoportba fog kerülni. A lemezeket NTFS formátumra kell formázni, és tilos átkonvertálni dinamikussá. Mindezen ismeretek alapján azt javaslom, hogy a cluster b ven tartalmazzon szabad merevlemezterületet.

Egyrészt fölös terület szükséges a hardveres redundancia biztosítására. Másrészt minden egyes definiált lemez esetén lehet vé kell tenni az adatok számára a „szaporodást és sokasodást”. Vagyis minél több lemezt definiálunk, annál több szabad hellyel kell számolni, hiszen a szabad hely felaprózódik közöttük. Például: ha a DHCP és a WINS szolgáltatást külön virtuális gépen definiáljuk, akkor külön diszket kell hozzárendelni az er forráscsoportokhoz, tehát mindkét szolgáltatás jöv beli tárkapacitásigényét külön kell megbecsülnünk. Ha egy csoportban helyezzük el ket, akkor lehetséges, hogy a számolt szabad kapacitás kisebb lesz, ezáltal a közös diszk sem lesz akkora, mint az els esetben. Azt kell látni, hogy két, egymásnak ellentmondó igényt kell kielégíteni. Minél több virtuális csoportot kell létrehozni ahhoz, hogy a szolgáltatások egymástól függetlenek legyenek, ugyanakkor ez jóval több er forrást

igényel (memóriát és f leg tárolóhelyet), ez viszont er forrás-, végs soron pedig pénzpazarláshoz vezet. Ha a pénztárca és a konfiguráció igényeit össze akarjuk hangolni, érdemes bizonyos szolgáltatásokat összevonni, és csak néhány, „nagyobb” virtuális szervert Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár létrehozni. Azt javaslom, hogy a virtuális szerverekhez az egyes szolgáltatásokat a karakterisztikájuk alapján soroljuk be Nagyon leegyszer sítve kétféle szerverszolgáltatás létezik: a fájl- és az alkalmazásszolgáltatás. Az el bbi intenzíven veszi igénybe a merevlemezeket, I/O csatornákat és hálózati kártyákat, míg az utóbbi rengeteg memóriát, és magas órajel , gyorsabb processzorokat kíván. A Windows 2000-t – s t már a korábbi NT verziókat is – egyszer en lehet hangolni ezekre a feladatokra. Ha az állomást

inkább fájlszolgáltatás jelleg feladatokra optimalizáltuk – ilyen a fájlmegosztás, a nyomtatás, az IIS – érdemes odaköltöztetni azokat a virtuális gépeket, amelyek er forrásai hasonló feladatokat látnak el. Fordítva hasonlóképp: az alkalmazásjelleg er forrásokat tartalmazó csoportokat az alkalmazás-kiszolgálásra hangolt node fogadja be. Ennyi tudás birtokában már papírra lehet vetni a virtuális szerverek tervét. Szükség van egy névre (15 karakternél nem hosszabb, a NetBIOS nevekre vonatkozó korlátok figyelembe vételével kell megalkotni), IP címre (kizárólag statikus cím lehet), valamint a szükséges szolgáltatásokra és merevlemezterületekre. Az egyes merevlemezeket mindkét állomáson szigorúan azonos bet jellel kell ellátni. Egyes dokumentációk azt javasolják, hogy abc sorrendben visszafelé érdemes bet jeleket adni, de ez nem kötelez . Jómagam el nyben részesítem a funkció szerinti jeleket, pl Q=quorum, E=Exchange stb.

Utolsó lépésként az el készítés során egy megfelel jogosultságokkal rendelkez fiókot kell létrehozni, ennek a kontextusa alatt m ködik majd mindkét állomáson a clusterszolgáltatás. Több forrás is egyértelm en állítja, hogy a fióknak adminisztrátori fióknak kell lennie, ez azonban nem teljesen pontos. Személy szerint nagyon nem szeretem, ha ritkán változó jelszóval rendelkez fiókok (és a szervizek fiókjai általában ilyenek) indokolatlanul nagy hatalomhoz jutnak. Ha valaki el szeretné kerülni, hogy tartományi rendszergazdává léptesse el a clusterfiókot, akkor a következ jogok megadásával elkerülheti ezt: • Lock pages in memory • Log on as a service • Act as part of the operating system • Back up files and directories • Increase quotas • Increase scheduling priority • Load and unload device drivers • Restore files and directories Az els három jogosultsággal alapértelmezetten a tartományi rendszergazdák sem rendelkeznek. A

jogokat vagy tartományi vagy OU (organization unit) szinten, de akár az állomásokon is meg lehet adni. Ez utóbbi a legbiztonságosabb, habár sok munkával jár. Az OU szint egy elfogadható kompromisszum, feltéve, hogy az OU direkt a clusterek adminisztrálásának elkülönítésére jött létre. A fiókot a Windows NT Account tartományban vagy az Active Directory-ban kell létre hozni, s ez logikus is, hiszen mindkét állomáson elérhet nek kell lennie ennek a fióknak – a tartományi felhasználók ilyenek. A fiókot egyébiránt a szervizaccountokhoz hasonlóan érdemes kezelni (a jelszó nem jár le; a felhasználó nem változtathatja meg a jelszót; hosszú, komplex és er s jelszót kell megadni stb.) Az állomásoknak kötelez en tartományi tagoknak kell lenniük, de ezen belül a szerepük nem korlátozott, lehetnek tagkiszolgálók és tartományvezérl k is. A szerepekr l a kés bbiekben még részletesen beszélünk Most annyit érdemes tudni, hogy mindkét

állomásnak azonos szerepet kell adni: vagy mind a kett legyen tagkiszolgáló, vagy tartományvezérl . A szerepeket a clusterszolgáltatás telepítése el tt kell beállítani. A telepítés Elég sokat tudunk már, fogjunk bele a telepítésbe. Feltételezzük, hogy mindkét állomáson m ködik a tartomány tagjaként a Windows 2000 Advanced Server. Vezérl pult Programok hozzáadása Windows komponens telepítés Cluster service. Az els párbeszédpanel arra hívja fel a figyelmünket, hogy a konfigurációnak, amelyre a fürtszolgáltatást telepítjük, szerepelnie kell a Microsoft által kiadott hardver kompatibilitási listának azon sz kített változatán, amely a kiszolgálófürtökre vonatkozik. Ez éles rendszer esetén evidens, a lehetséges szállítókat meg kell kérni, hogy igazolják eszközeik jelenlétét a listán, de ha kell, erre mi is képesek vagyunk. Ha olyan rendszerre telepítjük a clustert, amely nincs rajt a HCL-en, akkor a Microsoft részér l

semmiféle segítséget nem kaphatunk. Tekintve a bekerülési költségeket és a felálló rendszer kritikusságát, ezt nem érdemes kockáztatni. A panelr l az „I understand” (Megértettem) gomb megnyomása után léphetünk csak a következ re. A fürttelepít varázsló következ kérdése, hogy hányadik állomást telepítjük. Értelemszer en kell válaszolni Az els állomás esetén több teend je van a varázslónak, hiszen létre kell hozni a majdani „közös tudást”. Ha az els node-ra telepítjük a fürtöt, akkor meg kell adnunk a cluster nevét. A fürtnév az els virtuális kiszolgáló neve A m velet végén egy olyan er forráscsoport jön létre, amelybe a cluster neve és IP címe, valamint a quorum disk kerül. Ezt a virtuális szervert adminisztrációs célokra kell használni, és bár lehet, én nem javaslom, hogy további er forrásokat hozzunk létre benne. A fürt nevére a NetBIOS korlátok érvényesek. A következ lépés a fürtszolgáltatás

fiókjának és jelszavának megadása. Ha még nem adtuk meg a fiók jogait, akkor ezt a telepít ellen rzi. Figyelem! A varázsló a korábban felsorolt jogokból csak az els hármat adja meg automatikusan, a többit meglév nek feltételezi (vagyis, hogy Domain Admin a fiók). Ha nem akarjuk, hogy rendszergazda legyen, akkor a jogait el re be kell állítani. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár A fiókinformációk után a varázsló a felügyelt lemezekr l érdekl dik. A szakirodalom azt ajánlja, hogy minden lehetséges diszket azonnal rendeljünk a fürt felügyelete alá. Ez rendjén is lenne A telepítés után viszont minden lemez külön csoportba kerül, ami nem biztos, hogy kívánatos. Nosza átdobáljuk majd ket a megfelel helyre Csakhogy a „physical disk” er forrás nem dobálható át úgy, ahogy azt gondoljuk. El bb offline állapotba kell tenni, majd

átmozgatni, majd újra online állapotba kell helyezni. Nálam még így is el fordult, hogy rejtélyes hibaüzenetet kaptam A tudásbázis áttanulmányozása után kiderült, hogy a lemezeket úgy kezeltem, mint bármely más er forrást, és ez nem volt helyénvaló. Azt javaslom tehát, hogy csak a quorum disket hagyjuk a felügyelt lemezek között, és csak a telepítés után általunk létrehozott virtuális kiszolgálókhoz adjuk hozzá a többi lemezt. Itt érdemes megemlíteni, hogy a quorum disk legyen feltétlenül dedikált, tehát ne használjuk semmi másra. A mérete legalább 50 MB kell, hogy legyen, a MS ajánlás 500 MB, amelyet érdemes betartani. Nyilvános hálózat PC 1. Állomás Magánhálózat PC Hub/Switch PC Nyilvános hálózat PC 2. Állomás A varázsló ezután sorra veszi a lehetséges hálózati kapcsolatainkat, és arra kér minket, hogy határozzuk meg, milyen szerepet szánunk nekik. Háromféle szerep létezik: magánhálózat (private

network), nyilvános hálózat (public network) és vegyes hálózat (mixed network). A fenti ábra segít eligazodni a fogalmak között Amint az látható, egy normál fürtkonfigurációban minden állomás legalább két hálózati csatolóval rendelkezik. Az els pár csatoló vagy egy hubon keresztül, vagy egy crosslink kábel segítségével közvetlenül van összekötve, míg a másik csatoló az ügyfelekkel tartja a kapcsolatot. A magánhálózaton olyan forgalom zajlik, amelyet a két állomás a folyamatos szolgáltatás érdekében folytat. Ezek: a szerver szívhang, az állapotinformációk replikációja, a clusterparancsok, valamint a cluster m ködésre felkészített alkalmazások állomások közötti kommunikációja. Ha a nyilvános hálózat egyben a magánhálózat forgalmát is bonyolítja, akkor azt vegyes hálózatnak nevezzük. A fentiekb l következik, hogy a két hálózati csatoló nem kötelez , csak nagyon ajánlott. Ajánlott továbbá, hogy ne

nyilvános hálózatot definiáljunk a magán mellé, hanem vegyeset, mert így akkor is zavartalan maradhat a clusterkommunikáció, ha a magánhálózat valamilyen oknál fogva meghibásodik (egy Achilles sarokkal kevesebb). A magánhálózatok konfigurálásának további tudománya is van, amelyet a varázsló leállása után rögtön érdemes is alkalmazni. Javaslom, hogy nevezzük át a kapcsolatot megjegyezhet névre (Pl heartbeat) A hálózatok beállításánál az úgynevezett Binding Ordernél a magánhálózatokat a nyilvános mögé kell sorolni, másodikként. A csatolót olyan címmel kell ellátni, amely nem fordul el a nyilvános hálózaton. (Ha pl 10xxx a hálózati cím, akkor a private network esetén használjuk a 192.1680x címeket, mindegyik állomáson természetesen mást) Alapértelmezett átjáró, DNS és WINS bejegyzések ne legyenek a TCP/IP konfigurációban, továbbá ki kell kapcsolni a NetBIOS-t is erre az adapterre vonatkozóan. (De csak erre!!)

Ha crosslink kábelt használunk a magánhálózatban, akkor állítsuk be a következ regisztrációs értéket: HKLMSystemCurrentcontrolsetServicesTcpip ParametersDisableDHCPMediaSense REG DWORD, értéke: 1 Ennek magyarázatát a Q254651 cikkben lehet megtalálni. Végezetül a TCP/IP beállító panel DNS fülén ki kell kapcsolni a „Register this connecton’s addresses in DNS” kapcsolót. Ha ezt nem tesszük, akkor a cluster regisztrálja a magánhálózat hálózati kártyájának címét is, amelyt l viszont sohasem fog válasz érkezni a küls kérésekre, és vehetjük el a Network Monitort, hogy megállapítsuk, miért nincs néha a cluster a hálózaton, amikor ott van. Térjünk vissza a varázslóhoz. Ha egy magán- és egy vegyes hálózatot adtunk meg, akkor még arra a kérdésre kell válaszolnunk, hogy milyen sorrendben használja a szerviz a hálózatokat a fürtforgalomra. Ezzel befejez dik a kérdez sködés, a varázsló telepíti a szolgáltatást, elvégzi

a regisztrációs bejegyzéseket, és létrehozza a quorum disken a MSCS könyvtárban a quorum adatbázist. Ha mindent elvégzett, megpróbálja elindítani a fürtszolgáltatást Az el készítés Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár precizitásától függ en ez általában sikerül is neki. Ez a néhány tíz másodperc elég arra, hogy észrevegyük, a cluster telepítésének inkább NT4-es formája és érzete van, mint Windows 2000-es. Ez a „gyanú” kés bb igazolódni fog: A Windows 2000-ben nagyon sok mindent átírtak, és nagyon sokat fejlesztettek, beleértve a cluster szolgáltatást is, mégis maradt jócskán tennivaló a következ kiadásig. A varázsló elvégezve feladatát leáll. Nekünk azonban akad további tennivalónk Ellen rizni kell, hogy a szolgáltatás valóban elindult-e, s ha igen, segíthetünk rajta, hogy ne nagyon akarjon többet

állni. Vadonatúj Windows 2000-es szolgáltatás a szervizek m ködésének helyreállítása, és nemcsak a cluster szervizre. Azt ajánlom, hogy még a virtuális szerverek üzembe állítása el tt teszteljük a lehetséges helyreállítási eseteket. A cluster szerviznél a helyreállítás akkor fontos, ha vannak olyan csoportok, amelyek kizárólag egy állomáson futnak (például licencokok miatt), vagy maga a fürt egy állomásból áll (mert a másik csak jöv re érkezik). Az újraindítás lehet ségét csak akkor szabad igénybe venni, ha nincsenek fürtön kívüli szolgáltatások az állomáson, vagy azok más módon redundánsak. (pl. Active Directory) A teljességhez hozzátartozik, hogy két állomás esetén a másikon is le kell futtatnunk a varázslót. Ekkor már egy meglév clusterhez kell csatlakoznunk, a szerviz fióknak egyeznie kell az els állomásnál megadottal. A diszkekre vonatkozó kérés kimarad, mert azt a cluster adatbázis tartalmazza,

válaszolni kell viszont a hálózati csatolók szerepét firtató kérdésekre. A sikeres csatlakozásról a varázsló jelentést tesz. Íme, megszületett a farkasfalka els tagja A következ alkalommal megismerkedünk a Cluster Administratorral és létrehozzuk az els virtuális kiszolgálóinkat. Lepenye Tamás (MCSE) lepenyet@mal.hu Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár Farkasokkal táncoló III. – Cluster a gyakorlatban Lead: Az el z alkalommal sikerült telepítenünk a fürtszolgáltatást, most megismerkedünk az adminisztrálására szolgáló mmc-modullal, a parancssori felülettel, a csoportokkal, a függ ségekkel és az átköltözés rejtelmeivel. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár A Cluster Administrator A telepítés befejezése után a

start menü „Administrative tools” csoportjában megjelenik a „Cluster Administrator” ikon, amely grafikus felületet nyújt a clusterer források kezelésére. Ha a kiszolgáló konzolja helyett el nyben részesítjük a saját munkaállomásunkat a rendszer konfigurálására, akkor telepíthetjük az Advanced Server CD-r l az i386 könyvtárból az Adminpak.msi csomagot Ez a Windows 2000 Server valamennyi szolgáltatásának kezel programját telepíti Windows 2000 munkaállomásunkra. NT4-re a csomag sajnos nem telepíthet Els indításkor meg kell adnunk a cluster nevét, hogy csatlakozhassunk hozzá, de a lehetséges neveket fel is fedezi a modul, ha megkérjük rá. A következ alkalmakkor már automatikusan csatlakozik a megadott cluster névhez Ha ezt nem szeretnénk, akkor a cluadmin -noreconnect vagy cluadmin -norecon kapcsolókkal kerülhetjük el a csatlakozást. El fordulhat például, hogy a cluster – amely ugye virtuális – valamilyen oknál fogva nem

érhet el, ekkor az egyes node-ok nevét is megadhatjuk, így a csatlakozás sikeres lesz. Ha tudni szeretnénk, hogy pontosan hogyan csatlakoztunk, elég ránézni az ablak címsorára: a clusternév(clusternév) azt jelzi, hogy a clustert magát céloztuk meg, a clusternév(nodenév) viszont azt, hogy az egyik állomáson keresztül érjük el a fürtöt. A clusternév() azt jelzi, hogy az egyik állomásról LPC hívásokkal dolgozik a bedolgozó modul. Normális m ködés közben ennek nincs jelent sége, hiba esetén viszont nem árt tisztában lenni a kapcsolódás mikéntjével. A bedolgozómodul bal oldalán a clusternév szerepel a fa gyökereként. Ebb l nyílnak az er forráscsoportok, az összes er forrás gy jt mappája, a cluster konfigurációs mappája, valamint a fürt állomásai. A Cluster Administrator felülete Az ablak jobb oldalán a mindenkori aktív konténer tartalmát láthatjuk, nagyon gyakran állapotinformációkkal f szerezve. Ez fontos momentum. A

rendszergazdai felület precízen, és azonnal megjeleníti a cluster komponenseinek állapotát, ami alapján a teljes cluster állapotára következtethetünk. Nem sok ilyen állapot létezik, érdemes felsorolni ket: Online (m ködik): A clusterer forrás létezik és m ködik. Ezt az állapotot szeretjük leginkább Offline (nem m ködik): Az er forrás nem üzemel. Ez nem biztos, hogy hiba Az er források meghatározott sorrendben vehetnek fel állapotokat, valahogy úgy, ahogy azt az ábra mutatja. online failed online pending online offline pendig offline Az er források lehetséges állapotai Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár Látható, hogy az offline állapot korántsem csak hibát jelent, hanem egy átmenetet is az egyik online állapotból a másikba. Ez történik például akkor, amikor egy csoportot átmozgatunk egyik állomásról a másikra. Online

pending (Élesztés közben): Az el z ekb l következ en ez egy átmeneti állapot. Lehetséges azonban, hogy az er forrás ebben az állapotban beragad, ami komoly hibára utalhat. Offline pending (Lekapcsolás alatt): Az el z állapot tükörképe. Failed (Sérült): Ez a tényleges hiba, a cluster nem képes elindítani a csoportot vagy er forrást. Gyakorlatilag bármely állapotot követheti „sérült” állapot. A cluster administrator elég szigorú, és már akkor is ilyen állapotjelz vel „címkézi” az er forráscsoportokat, ha egyetlen er forrás nem online állapotban van. Ez „ergonómiai hiba”, ha lehet így fogalmazni A cluster parancssori felülete A Cluster Administrator nem az egyetlen kezel felülete a fürtöknek. Ha valamilyen oknál fogva nem áll rendelkezésre a grafikus felület, de a parancssoros igen, a node system32 könyvtárában megtalálható a cluster.exe program, amely a net parancshoz hasonlóan igen gazdag funkciókészletet nyújt, szinte

mindent megtehetünk - ha éppen nem mindent. A szintaxisa roppant egyszer : cluster [cluster név] /option vagy cluster [cluster név] node [node név] /option Így lehet például egy megosztáser forrást létrehozni: X: MD TestShare cluster . res cluster . res cluster . res cluster . res cluster . res cluster . res cluster . res cluster . res cluster . res cluster . res "TestShare" "TestShare" "TestShare" "TestShare" "TestShare" "TestShare" "TestShare" "TestShare" "TestShare" "TestShare" /create /group:"Group1" /type:"File Share" /priv path="X:TestShare" /priv Sharename=TestShare /priv Remark="Teszt megosztas" /prop Description="Teszt megosztás" /priv security=DomainUser,grant,c:security /priv ShareSubDirs=1 /AddDep:"Disk X:" /AddDep:"Network Name" /On Nincs arra mód, hogy az opcióknak akár csak egy

részét is ismertessük. A clusterexe els sorban akkor válik hasznossá, amikor egy rendszeresen ismétl d feladatot kell végrehajtani, és ehhez szükséges a cluster állapotának lekérdezése, esetleg megváltoztatása. A cluster beállításai Miel tt az egyes mappák tartalmában részletesen elmerülünk, érdemes megvizsgálni a cluster tulajdonságait. Kattintsunk a fa gyökerére a jobb oldali egérgombbal, majd a „Properties” menüpontra. A telepít varázsló kérdéseire adott válaszaink nagyobbik része itt található. A négy fülb l igazából kett izgalmas, a Quorum és a Network Priority. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár Az alapérték csak 64K. Írjuk át 4096-ra! A cluster tulajdonságai Ha nem voltunk kell en megfontoltak, és új helyet kell találnunk a quorum adatbázisnak, azt itt tehetjük meg. Ezt azonban csak normál m ködés

esetén lehet elvégezni. Egészen más a teend , ha a quorum lemez megsérül, vagy az adatbázis megy tönkre. Lesz még hely és alkalom, hogy err l értekezzünk A fülön van egy fontos paraméter, ez a quorum log mérete Alapértelmezetten csupán 64K. A Q225081 leírása szerint ez kevés lehet, ha nagyszámú megosztásunk vagy egyéb er forrásunk van, érdemes tehát megnövelni 4096K-ra. Ezt elég egyszer elvégezni és a clustert sem kell újraindítani a változások érvényre jutásához. A „Network Priority” panel pontosan arra való, amire a neve utal. A varázsló kérdésére adott válasz itt módosítható Akkor fordulhat ez el , ha utólag telepítünk egy második kártyát. Ez a fül azonban csak a már illesztett kártyák sorrendjét változtatja meg, a szerepüket nem. Ha ez utóbbit is állítanunk kell, akkor a „Cluster configuration” konténer „Networks” mappájában kell megkeresnünk a hálózati csatolót, és módosítani a szerepét. A

teljesség kedvéért említsük meg a biztonsági lapot is. A fejleszt k nem vitték túlzásba a biztonsági beállítási lehet ségeket. Egy fióknak vagy nincs jogosultsága a cluster kezeléséhez, vagy mindent megtehet Úgy érzem, az a szemlélet érhet itt tetten, miszerint a virtuális szerverek mégsem igazi szerverek (még!). Nem önálló egységek, amelyek külön felel st igényelhetnének, sokkal inkább a teljes fürt az, amely a felel sség határát meghúzza. Hogy ez a kés bbiekben változni fog, az bizonyos. A fent tárgyalt párbeszéd-paneleket ritkán fogjuk használni, hiszen nem naponta változik egy fürtözött konfiguráció. Annál inkább a napi munka része a csoportok és er források kezelése, lássuk tehát, mi mindent tehetünk. Csoportok Ha az el re létrehozott közös lemezeket a varázsló kérdésére mind a cluster kezelésébe utaltuk, akkor már az els induláskor több csoportunk is van, amelyek nemes egyszer séggel a „Disk Group 1.n”

nevet viselik Az els csoport kivétel csak, a „Cluster Group” Ez tartalmazza a cluster név, cluster IP cím és quorum er forrásokat. Amikor munkahelyemen az els clustert üzembe helyezték, a szállítónk el re telepítette a clusterszolgáltatást az általunk megadott er forrásokkal és virtuális kiszolgálókkal együtt. A csoportok neve megegyezett a virtuális szerverek nevével Az els saját telepítésemig azt hittem, hogy a csoportnév és a virtuális szervernév egy és ugyanaz, de ez nem így van. Érhet is: vannak olyan csoportok, amelyek nem virtuális kiszolgálók, tehát nincs NetBIOS, csak csoportnevük. Az utólagos beállítás azonban hasznos, hiszen nem kell folyton a csoportnevek mellé rendelni a szerverneveket. Azt javaslom tehát, hogy minden csoportot, amely egyben virtuális kiszolgáló is, nevezzék át a rendszergazdák a virtuális szerver nevére, beleértve az els csoportot, vagyis a clustert is. Nem kötelez ez, csak egyszer bbé teszi az

életet Az átnevezés nagyon egyszer : jobbklikk a csoporton és „rename” Új csoport felvétele hasonlóan könny : jobbklikk a fa gyökerén: new group. A létrehozott csoport nem tartalmaz er forrásokat, persze tetszés szerint feltölthet újakkal vagy már meglév kkel. Ez úgy végezhet el, hogy offline módba kell tenni az er forrást, majd jobbklikk: „change group group name”. Egy fontos dolgot azonban figyelembe kell venni, ez pedig a függ ség. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár A függ ségek A cikksorozat els részében már definiáltuk, hogy ez mit jelent, most az els er források létrehozásánál a gyakorlatban is alkalmaznunk kell a korábban leírtakat. Nincs olyan KB cikk, amely minden egyes lehetséges er forrást leír és meghatározza, hogy mely más er forrásoktól függhet. Általánosságban a Q171791 foglalkozik a kérdéssel

Néhány ökölszabályt érdemes megfogalmazni, ezek könnyedén megvalósíthatók a gyakorlatban. 1. A lemezer források soha ne függjenek más er forrásoktól 2. Nem függ más er forrásoktól az IP cím és a Time service resource 3. A „Network name” mindig az IP címt l függ 4. A fájlmegosztás a „Network name”-t l és a lemez er forrástól függ 5. A fájl- vagy adatbázism veleteket végz er források mindig függnek a fizikai lemezt l (Pl: WINS) 6. A hálózati szolgáltatások mindig függnek az IP címt l, néha a hálózati névt l is A szabályok nagyobbik része értelemszer , magyarázatra sem szorul. Mindenképp érdemes egy kis id t szentelni a függ ségekre, és akár kis téglalapokkal ábrázolni is lehet. Törekedni kell az egyszer , átlátható ábrára Úgy kell kialakítani a hierarchiát, hogy egy er forrástól ne függjön kétféleképp egy másik er forrás. Például ha a fájlmegosztás már függ a hálózati névt l, akkor nem kell függ

vé tenni az IP címt l, hiszen már a hálózati néven keresztül amúgy is függ t le. Ez nem minden er forrás esetén tartható. A WINS és DHCP er források például követelik mind a hálózati név, mind az IP cím függ séget, nem is lehet definiálni ket másképp. A függ ség a gyakorlatban úgy érvényesül, hogy egy er forrás indítása csak akkor kezd dik el, ha már minden er forrás, amelyt l függ, sikeresen elindult. Minél több tehát a függ ség, és minél hosszabb a függ ségi sor, annál kés bb indulnak el a sor végén álló er források. A jelenlegi ismeretek alapján nem meglep már, hogy az er források függ ségét csak azonos csoporton belül lehet létrehozni. A különböz csoportok ugyanis elkerülhetnek az azonos állomásról, így a függ ség érvényesítését nem lehetne garantálni. Végezetül ajánlom, hogy a triviális függ ségek mellett tárjuk fel a logikai függ ségeket is. Például egy clusterre fel nem készített, de

általános szolgáltatás-er forrásként definiálható vezet i információs rendszer függhet az SQL Servert l, amely az adatokat szolgáltatja neki, jóllehet ezt a függ séget semmi nem követeli meg, csak a rendszergazda ítél képessége. Át- és visszaköltözés, újraindulás Ha már a függ ségeket megemésztettük, ismerkedjünk meg az utolsó fontos fogalmakkal a gyakorlatban: az át- és visszaköltözéssel, valamint az újraindulással. Adódik az eset: egy er forrás abnormális állapotba kerül Mit tegyen ekkor a cluster? Egyáltalán hogyan értesül err l? Elég fontos kérdések ezek, tulajdonképpen a rendszer szíve-gyökere ez a funkció. Mi másért tartanánk egy clustert, ha nem azért, hogy éppen ezt tudja. Az cluster szerviz egyik igen fontos feladata az er források állapotának figyelése, valamint annak ellen rzése, hogy az er forrás valóban ellátja-e a feladatát. A kétféle ellen rzést „Looks alive”-nak („úgy t nik, él”) és

„Is alive”-nak („valóban él”) nevezhetnénk el az er forrás tulajdonságlapja alapján. Az els esetben az ellen rzés abból áll, hogy a szolgáltatás megnézi a regisztrációs adatbázis cluster részét, vajon minden rendben van-e. Kiindulásnak nem rossz ez az ellen rzés, mert az er forrást nem terheli, elég egyszer és gyors, csak az a bökken je, hogy mindig a saját korábbi vizsgálatára támaszkodik, tehát nem igazi ellen rzés. Ezzel a vizsgálattal valóban csak azt lehet mondani: „Úgy t nik, hogy m ködik” Ez az ellen rzés sokáig nem folytatható, ezért néha meg kell vizsgálni azt a futó programszálat (program thread), amely az er forrás maga. Ez az „is alive” vizsgálat. Ez már igazi ellen rzés, cserébe egy icipicit foglalja és fogja a rendszert Ez már csak így szokott lenni. Nos, tegyük fel, hogy egy ilyen „is alive” vizsgálat során azt tapasztalja a cluster szolgáltatás, hogy nem válaszol a programszál. Ekkor válik

igazán fontossá, hogy az er forrás és a csoport, amelyben az er forrás székel, milyen átköltözési szabályokkal rendelkezik. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár Átköltözési szabályok egy er forrásnál A panel alapján akár azt is megtehetjük, hogy hiba esetén nem teszünk, illetve a rendszerrel nem végeztetünk semmit. („Do not restart”), bár még nem sikerült igazán olyan életszer szituációval találkoznom, ahol ez lett volna a helyes választás. Szinte bizonyos, hogy legalábbis újraindítjuk az er forrásunkat. Meg kell adnunk viszont, hogy az er forrás állapota hatással legyen-e a csoport állapotára („Affect group”). Ha azt választjuk, hogy nem, akkor a helyreállítási procedúra a következ kb l áll: 1. Ha még nem fagytak le, akkor a clusterszolgáltatás leállítja a hibás er forrástól közvetve vagy közvetlenül

függ er forrásokat. 2. A „Period” („id köz”) mez ben megadott másodpercen belül maximum a „threshold” („próbaküszöb”) mez ben meghatározott alkalommal megpróbálja újraindítani az er forrást. 3. Ha sikerül az újraindulás, akkor a függ er forrásokat is megpróbálja elindítani 4. Ha nem sikerült a start, akkor az er forrás és minden t le függ más er forrás is „Failed” („Hibás”) állapotban marad 5. Megvizsgálja, hogy a függ er források hibás állapota érinti-e a csoportot Ha nem, akkor a helyreállítási procedúra leáll A legf bb fegyvert, az átköltözést ilyenkor nem használjuk. A költözés ugyanis a csoport joga, mi viszont nem kívántuk eszkalálni a problémát csoportszintig. Jó ez így? Hiszen nem tudhatjuk, hogy mi a hiba oka, s talán „máskor, más helyen” (értsd: a másik állomáson) m ködhetne a szolgáltatásunk. Bármilyen fura, lehetséges, hogy ez jó megoldás Tegyük fel, hogy több száz

megosztást definiáltunk clusterer forrásként. Ha egy könyvtárat véletlenül törlünk, a hozzá tartozó er forráscsoportnak sokáig tartana átköltözni a másik állomásra, ráadásul felesleges lenne az átköltözés, hiszen a többi er forrásnál ez csak kiesés, míg a törölt könyvtárnak úgyis mindegy, ha egyszer törölni akartuk. Fontoljuk meg tehát, hogy érintse-e az er forrás összeomlása a csoportot. Ez néha szükséges, néha nem – egyértelm tanácsot csak konkrét környezetben lehet adni. Bevallom, hogy az el bb kicsit csaltam. Hiszen az 5 pontban az is el fordulhatott volna, hogy a függ er forrás már érinti a csoport átköltözését. Igen, ekkor valóban megkezd dik az átköltözés Ha ezt szeretnénk elkerülni, akkor át kell nézni minden, az er forrástól függ más er forrást és a megfelel jelöl négyzetben elt ntetni a kis pipát. Ha az er forrás magával rántja a csoportját, akkor megindul az átköltözés a hova is pontosan?

Nos, az er forrás által kijelölt másik állomásra. (Tulajdonságok panel, „Possible owner” bejegyzés) Advanced Server esetén ez kissé nagyzolásnak t nik, hisz már csak egy szerverünk maradt, ahová a csoport átgördülhet, Datacenter Servernél viszont három vagy négy állomás is alkothat clustert, turkálni lehet a választékban. Ám ennek az ellenkez je is el fordulhat, hogy nincs is másik szerverünk. Miért? Lehetséges, hogy nincs is második állomás? Igen, lehet A cluster állhat akár egy node-ból is, ekkor nem lehetséges az átköltözés. Akkor fordul ilyesmi el , ha a cluster els állomását el bb állítjuk üzembe, mint a másodikat, de gondolva a jöv re, már az els node-on úgy állítunk be mindent, mintha teljes kiszolgálófürtünk lenne. Az új gép csatlakozásakor a cluster szerencsére elvégzi nekünk, hogy minden er forrásunknak legyen lehetséges tulajdonosa az új állomás is, ennek ellenére fontos a következ szabály: egy

csoportban minden er forrásnak legyenek ugyanazok a node-ok, ugyanolyan sorrendben preferált szerverei! Ez nem zárja ki, hogy egy csoportnak továbbra is csak egy preferált állomása legyen. Lehet, hogy egy szoftvert (pl Exchange) ugyan clusterre telepítettük, clusterer forrásokként m ködnek a szolgáltatásai, de nem rendelkezünk egy második kiszolgálólicenccel ahhoz, hogy a második node-ra is felrakhassuk Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 6 NetAcademia-tudástár szegényt. Ekkor bizony be kell állítanunk, hogy minden Exchange er forrásnak, s t az egész csoportnak csak egyetlen állomás legyen a birtokosa. Hiba esetén újraindítás lehetséges, átköltözés nem Mi történik akkor, ha a csoport nem tud elindulni azon az állomáson, amelyre át szándékozott költözni és megpróbál azonnal visszaköltözni az els állomásra? Az örökciklust azért kivédték a

tervez k. A csoport tulajdonságai között is megadhatók átköltözési szabályok. Jobbklikk: „A csoport neve” Properties Failover A threshold érték szabályozza, hogy hányszor indulhat újra másik állomáson egy csoport egy átköltözési periódusban. Ezután a cluster szerviz offline állapotba teszi a csoportot. A periódus hosszát a Period érték adja meg Vagyis: ha 11-szer indulna újra a csoport, de a küszöbérték 10, akkor a cluster kikapcsolja a csoportot, amíg le nem jár az átköltözési periódus. A cluster szerviz újraindításával új periódust lehet kezdeni. Átköltözési szabályok egy csoportnál És a visszaköltözés? Alapvet en két lehet ségünk van: a kiszolgálókra bízzuk, vagy magunk végezzük el. Ha magunk végezzük el, az biztonságos és a megfelel id ben történik, csak kényelmetlen. Egyrészt kézzel kell megoldani, fejben kell tartani a feladatot, másrészt a visszaköltöztetést szinte bizonyosan egy kevésbé

frekventált id ben, este vagy éjszaka kell végrehajtani, ezt pedig senki sem szereti. Elvégzi a visszaköltöztetést a cluster is, méghozzá pontosan úgy, ahogy azt mi szeretnénk. Választhatjuk azt, hogy a csoport regenerálódás után azonnal röppenjen vissza a helyére, de megadhatjuk azt is, hogy ez a mozgás egy adott napszakban történjék meg. Mérlegelni itt azt kell, hogy az üzemeltetési paraméterek (pl válaszid ) els bbséget élvez-e a rövid kieséssel szemben, amelyet a napközbeni visszaállás okoz. Most már minden tudásunk megvan, hogy er forráscsoportokat és er forrásokat hozzunk létre. A következ alkalommal a fájl- és nyomtatóer forrásokkal kezdünk. Lepenye Tamás, MCSE 2000 lepenyet@mal.hu Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 7 NetAcademia-tudástár Farkasokkal táncoló IV. – Cluster a gyakorlatban Jobbról is, balról is körbejártuk már a

fürtszolgáltatást, szinte minden beállítást ismerünk, csak még er forrásokat nem hoztunk létre egy szálat sem. Ezt a fejezetet kizárólag e témának szenteljük. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár Az er forrásokról általában Minden er forrás létrehozásának hasonló a menete: az els panelen megadjuk a nevét, a leírását, a csoportot, amelyhez tartozni fog, és az er forrás típusát. Igazából ez a legbonyolultabb panel a m velet során A következ lépés, hogy megadjuk, milyen állomások láthatják vendégül az er forrást (Preferred owner). A beállításokat a csoportjától örökli, jobb meghagyni a felajánlott állapotot. Ezután a függ ségek következnek, err l a témáról az el z cikkben b ven volt szó. Az utolsó panel er forrásról er forrásra változik, itt kell ugyanis az egyes típusok speciális, csak rájuk jellemz

adatait megadni. Van azonban olyan er forrás, ahol nincs is ilyen panel, mert egyszer en nem kell megadni speciális beállítást. A legördül listából összesen 15 er forrástípus közül lehet választani, ám ez csalóka szám. A mappa megosztásból van mindjárt három altípus, de csak egy szerepel a listában. Van azután ún „általános szolgáltatás”, meg „általános alkalmazás”, amely nem más, mint olyan szervizek clusteresítése, amelyek fejlesztésekor még nem gondoltak erre a fontos technológiára. Ezekb l annyi lehet, mint égen a csillag. Szóval a 15 senkit ne tévesszen meg A következ kben minden er forrástípusra szánunk néhány mondatot, a fontosabbakat pedig részletesebben is megvizsgáljuk. A fizikai lemez (physical disk) er forrás Nagyon fontos, de nagyon egyszer en létrehozható er forrás. A varázsló utolsó lapján csak annyi dolgunk van, hogy megadjuk a lemezmeghajtó bet jelét, pontosabban kiválasztjuk a lehetséges bet jelet.

A nem közös és a már korábban kiválasztott, ilyen er forrásként megadott lemezek nincsenek a listában. Az is el fordulhat, hogy egy általunk odagondolt lemez nem jelenik meg. Ekkor meg kell gy z dni arról, hogy: 1. Mindkét állomás azonos bet jelet adott-e a lemeznek? 2. A lemezen van-e egyedi jel (disk signature)? 3. Az egyedi jel létér l mindkét állomás biztosan tud-e? 4. A diszk nem dinamikus-e véletlenül? 5. Minden gyártóspecifikus eszközmeghajtót telepítettünk? Az els feltételt könny ellen rizni a lemezkezel vel. A második feltétel automatikusan teljesül, ha legalább egyszer elindítottuk a lemezkezel t az er forrás létrehozása el tt, és hagytuk, hogy a felbukkanó varázsló rátegye a „disk signature”-t az új lemezekre. Ugyanez a varázsló ebben a körben dinamikus lemezekké konvertálná a diszkeket, de ezt ne engedjük! A cluster lemezkezel je (a clusdisk eszközmeghajtó) csak egyszer (basic) lemezeket kezel. Az utolsó feltételt

saját tapasztalataim alapján magam találtam ki. A lemezek – ahogy err l korábban már volt szó – valójában nem igazi lemezek, hanem valamilyen lemeztömb logikai felosztásai. Ez a lemeztömb, különösen ha diszkalrendszerr l van szó, számos gyártóspecifikus eszközmeghajtót is igényelhet, amelyek telepítése nem triviális Alapszabály tehát, hogy a fizikai lemezer források létrehozása el tt gy z djünk meg arról, hogy a fürt alatt dohogó lemezrendszer jól m ködik-e, és semmilyen megmagyarázhatatlan „tulajdonsága” sincs. Olyan ez, mint a házépítés: csak jó alapokon épül jó otthon. Az IP cím (IP address) er forrás A lemezekhez hasonlóan szintén nagyon egyszer és nagyon fontos er forrás. A létrehozásához csak egy pontos címre és egy alhálózati maszkra van szükség. A virtuális gép minden egyéb TCP/IP beállítását az t futtató állomástól veszi – egyszer bb így az élet. Gyakori hiba, hogy az alhálózati maszkot

rosszul adja meg a rendszergazda – a hatása éppen az, mint egy normál szerver esetén. A hálózati név (Network name) er forrás A hálózati név nem kevésbé fontos er forrás, mint az el z kett volt. Ez teszi lehet vé, hogy a virtuális szerverre név szerint hivatkozhassunk. A név – sajnos – NetBIOS név A Windows 2000 ugyan regisztrálja a WINS mellett a DNS Servernél is, ám ez sovány vigasz. Az igazság a Q235529 cikkben van: a Windows 2000 cluster szolgáltatása és a NetBIOS egyel re elválaszthatatlanok egymástól. A közös mappa (file sharing) er forrás Az els három er forrás ahhoz szükséges, hogy egy virtuális kiszolgáló egyáltalán létrejöhessen. A közös mappa viszont már „igazi” szolgáltatás. Három alfaja is van A létrehozás tulajdonképpen nem más, mint egy létez könyvtár kacifántos megosztása. Ez annyiból áll, hogy a könyvtárnak már léteznie kell, a megosztás pedig az er forrás létrehozásával történik. Az

eltávolítást épp fordítva kell elvégezni: el bb meg kell szüntetni az er forrást (ezzel megsz nik a megosztás), majd lehet törölni a mappát. Azért írom le ezt a triviálisnak t n lépéssort, mert kezdetben számtalanszor magam is eltévesztettem, és el bb töröltem a könyvtárat, minthogy megszüntettem volna az er forrást. A következménye az volt, hogy a virtuális szerver, vagyis az er forrás-csoport ész nélkül elkezdett egyik állomásról a másikra vándorolni, hátha ezzel orvosolhatja a „hibás” állapotba került er forrását. Nem sikerült neki A tanulság, hogy kiszolgálófürt esetén meg kell tanulni: a megosztásokat a Cluster Administrator segítségével kell létrehozni és megszüntetni. A varázsló utolsó paneljén van egy „Advanced” jelzés gomb, amellyel el csalogatható a háromféle megosztás létrehozását lehet vé tév ablak. Ez az: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet

 2000-2003, NetAcademia Kft 2 NetAcademia-tudástár A normális megosztás pontosan az, ami a neve. Ugyanilyen megosztást tud minden Windows 2000 termék, ez csupán a rendelkezésre állásában jobb. Mivel semmi különbség nincs, a szabályok sem különböznek: javasolt a megosztás jogosultsági beállításait alapon hagyni, és NTFS jogosultságokkal szabályozni a felhasználók hozzáférését az állományokhoz. Egy fontos tudnivaló azért van: a cluster szolgáltatás fiókjának legalább olvasási jogokkal kell rendelkeznie a közös mappán. Ha ez nincs így, akkor nem képes az er forrást m köd képes állapotba hozni Ez persze nem a létrehozáskor jelent problémát, hanem amikor egy biztonsági felülvizsgálat során megvonják t le a jogokat. Az els változatnál érdekesebb a „share subdirectories” típusú megosztás, különösen akkor, ha az alkönyvtárakat automatikusan elrejtjük. Mire is jó ez? A Windows NT 40 minden verziója küzd azzal

a problémával, hogy csak megosztásokhoz képes csatlakozni, megosztások alatti almappákhoz már nem. Ez pedig probléma a felhasználói könyvtáraknál, mert a szegény felhasználó elveszik a sok könyvtár között, és nem találja a sajátját. Szemfüles rendszergazdák úgy segítettek magukon, hogy megosztották a felhasználók könyvtárait is, és hogy ne sorakozzon több száz megosztott mappa a tallózó szolgáltatásban, ezért a könyvtárak megosztási nevei kaptak egy $ jelet, vagyis rejtve maradtak. No, ez a szolgáltatás pont ezt a funkciót végzi, csak most már automatikusan. Az igazat megvallva kellett is ez Korábban ugyanis az ilyen megosztásokat is er forrásként lettünk volna kénytelenek definiálni, az eredeti fürtkiszolgáló szoftver verzió azonban csak 900, a jelenlegi pedig csak 1600 er forrást kezel, s bizony akadt olyan hely a világon, ahol ez korlátot jelentett. Arról nem is beszélve, hogy ilyen sok er forrás terhelte is a

clustert rendesen, míg most a megosztott alkönyvtárak már nem er források többé, így minden a helyére került. Minden? No, ha majd csak Windows 2000, vagy XP munkaállomások lesznek a hálózaton, akkor lehet faragni a scriptet, amely megszünteti a rengeteg rejtett megosztást, és a normál almappához csatolja a felhasználókat. Egy lehetséges hibára szeretném felhívni még a figyelmet: ha a Windows NT-hez mellékelt „User Manager for Domains” eszközzel hozzuk létre a felhasználó könyvtárát, akkor annak jogosultsági listájában egyedül a felhasználó lesz benn teljes eléréssel, és semmi-senki más. Ezért aztán a fürtkiszolgáló fióknak sem lesz elegend joga a könyvtárat automatikusan megosztani. Ez éppen az n+1-ik ok, hogy ne NT-t használjunk (Épp most vonja ki a piacról a Microsoft az NT4-et – a szerk) Nem esett még szó a DFS-megosztásról. A bet szó annyit tesz, hogy elosztott fájlrendszer, és arra való, hogy a rendszergazdák

egyetlen közös névtérbe rendezhessék a megosztásaikat, egyfajta óriási virtuális megosztásrendszert létrehozva. A technikának az az el nye, hogy a jól megszerkesztett névtér állandó maradhat, míg alatta a megosztások és kiszolgálók tetsz legesen mozoghatnak, változhatnak. Ez a szolgáltatás már a Windows NT 40-ban is jelen volt, igaz, nem a CD-n, hanem webr l letöltve lehetett telepíteni. A gyenge pont pedig az volt, hogy a DFS gyökere (amelyb l csak egy lehetett) kártyavárként döntötte össze a névteret, ha nem volt elérhet - Achilles sarok volt tehát. Emiatt nem is vált igazán népszer vé a DFS. A Windows 2000 azonban változtatott a helyzeten kétféleképpen is. Egyrészt megjelent a tartományalapú DFS-rendszer, amely a névteret az AD-ban tárolja, ami így már redundánssá vált. Másrészt megjelent a fürtszolgáltatásban a DFS megosztás létrehozása. Miért volt szükség erre, amikor ott az AD? Két ok miatt is Egyrészt nem

mindenki akar Active Directory szolgáltatást, másrészt ehhez az AD-val integrált DFS-hez vagy Windows 2000-es ügyfelek kellenek, vagy AD klienst kell telepíteni minden egyes korábbi Windows verzióra. A fürtszolgáltatás rendelkezésre állása pont az Achilles sarkot szünteti meg, de kompatibilis a korábbi NT verziókkal is. Az ilyen DFS gyökérmegosztást „Stand alone” DFS-nek hívják, megkülönböztetve az AD-val integrálttól. Minden szépsége ellenére ennek a szolgáltatásnak is vannak korlátai, nevezetesen: • Csak egyetlen DFS megosztást lehet létrehozni a teljes fürtön. • Nem lehet egyszerre AD-val integrált DFS-t és Stand alone DFS-t létrehozni a kiszolgálófürtön. Ez azt jelenti, hogy bizony a DFS megosztásnak helyet adó virtuális kiszolgáló neve jó id re beleég a rendszerünkbe. Van még két súlyos DFS korlát a fürtszolgáltatásnál. • Az AD-val integrált DFS létrehozásakor a gyökérkönytár nem lehet a fürt közös

lemezein. • A fürt közös lemezein található megosztások, amelyek részei a DFS névtérnek, nem használhatják a Windows 2000 fájlreplikációs szolgáltatását. Az els problémát még csak-csak át lehetne hidalni egy nem túl elegáns megoldással, de a második korlát bizony mellbevágó. Ez ugyanis azt jelenti, hogy a közös névtérbe szervezett, a vállalat eltér telephelyein eltér módon használt könyvtárrendszert nem lehet automatikusan replikálni. (Például ugyanazon elérési utat használva az egyik telephelyen létrehoznák a termelési jelentést, az automatikusan átreplikálódna a központba, ahol a vezet ség a WAN vonalakat nem terhelve nézegethetné azokat.) Jelenleg csak az Exchange 2000 nyújthat megoldást a problémára saját mappáinak replikációjával. No és a Net Server, ha megjelenik A fürtkiszolgáló fizikai lemezeinek és közös mappáinak érdekes problémája a hibajavítás, de err l nem itt, hanem egy másik cikk keretében

szeretnék írni. A hasznos olvasnivalókat a cikk végén soroltam fel Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár A nyomtatási sorkezel (print spooler) er forrás A közös mappáknál nem kevésbé érdekes a közös nyomtatók létrehozásának feladata. Az alapvet tudnivalók: A nyomtatási sorkezel csupán alapja a fürtszolgáltatás hálózati nyomtató megosztásának. Létrehozásával azt tesszük lehet vé, hogy lehessen megosztott, nagy rendelkezésre állású nyomtatónk. Egy virtuális gépen csak egy spooler er forrást hozhatunk létre, de az akármennyi hálózati nyomtatót is kiszolgálhat. A nyomtató csak akkor lehet közös, ha hálózatról (értsd: TCP/IP alapon) el lehet érni, és nem csatlakozhat párhuzamos porton az egyik vagy a másik állomáshoz. A hálózati nyomtatónak szüksége van a TCP/IP nyomtatási szolgáltatásra (esetleg a UNIX vagy

más nyomtatási szolgáltatásra környezett l függ en), ezeket tehát telepíteni kell az er forrás létrehozása el tt mindkét kiszolgálóra. Végezetül hozzunk létre a kiszemelt virtuális gépünk egyik fizikai lemezén egy „Spool” könyvtárat. A továbbiakban feltételezzük, hogy van már egy virtuális szerverünk névvel, IP-címmel és egy fizikai lemezzel. Jöhet az er forrás: az els lapon válasszuk ki a „Print Spooler” er forrástípust, és adjunk nevet neki. A következ lapon hagyjuk változatlanul a lehetséges állomásokat. A függ ségek paneljén tegyük függ vé a sorkezel nket a hálózati névt l és a fizikai lemezt l, végezetül az utolsó lapon adjuk meg a korábban létrehozott Spool könyvtárat, ahol a nyomtatószerver az átmeneti állományait tárolhatja. Ezzel kész a sorkezel , de még csak az út felénél járunk Nincs ugyanis még sem portunk, ahová az adatot küldenénk, sem meghajtónk, sem közös nyomtatónk. De most lesz!

Tallózzunk a hálózaton az egyik fürtállomásunkhoz. Lépjünk be a nyomtatók mappába Válasszuk ki a „Fájl” menü „Server Properties” menüpontját. Nyomtatómeghajtók az egyik állomáson A Driver fülön adjuk hozzá a leend nyomtatónk meghajtóit. Amint az a képen is látható, többféle nyomtató eszközvezérl létezik, ha tehát többféle kliensünk van, mindegyik rendszer meghajtóját hozzá kell adnunk. Ez némely Windows NT 4-es meghajtónál gondot okozhat, ezért egy másik gépen érdemes kísérletezgetni a nyomtatók meghajtóival. Ha valaki végképp nem boldogul, ajánlom figyelmébe a Fixprnsv.exe segédprogramot és a Q247196 cikket Mivel a téma nem igazán clusterspecifikus, ezért az ennél a fázisnál felmerül problémákat most nem tudjuk felsorolni és megoldani. Ha megvannak a meghajtók az els node-on, akkor ugyanezt a m veletet el kell végezni a másik állomáson is. Azért kell ezt megtenni, mert a nyomtatómeghajtók nem a közös

lemezterületen találhatók, hanem az állomások print$ megosztásaiban. Figyelem! A meghajtók, és kés bb a frissítéseik is legyenek azonosak a két állomáson, különben megjósolhatatlan furcsaságokba ütközhetünk a kés bbiekben. Az eszközkezel k után jöhetnek a közös nyomtatók. Tallózzunk ezúttal a virtuális szerverünkhöz Látható, hogy a megosztások között létrejött egy „Nyomtatók” speciális mappa, amelybe belépve pontosan ugyanazokat a feladatokat végezhetjük el, mint egy hétköznapi Windows 2000 nyomtatószerveren. Nosza, adjuk hozzá azt a nyomtatót! Amikor a varázsló a port kiválasztásához ér, adjunk meg nyugodtan új portot, válasszuk a „Standard TCP/IP”-t, vagy azt, amelyik a mi környezetünkben a megfelel . Adjunk egyedi nevet a portnak Visszajutunk az el z ablakhoz, válasszuk ki az újonnan létrehozott kaput, és lépjünk tovább. A Windows 2000 alatt kicsit könnyebb a helyzetünk, mert a port létrehozását csak

egyszer kell elvégezni, a konfigurációs adatokat ugyanis a cluster hive alatt tárolja a fürt, tehát közös részen. A korábbi verzióknál ez még nem így volt, ott el bb helyi nyomtatókat kellett létrehozni mindkét állomáson, hogy létrejöjjenek a portok. No, ez már a múlté. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár A meghajtók között válasszuk ki a már egyszer megadottat, így a következ panelen lehet ségünk lesz megtartani az el zetesen feltett drivereket. Ezután már csak nevet kell adnunk a nyomtatónak, és rendelkeznünk kell, hogy a rendszer ossza meg a felhasználók felé. Ha van AD címtárunk, akkor publikálhatjuk a nyomtatót a címtárba is Ezzel el is készültünk A biztonság kedvéért javaslom, hogy teszteljük a létrehozott nyomtatót, majd mozgassuk át a másik állomásra a virtuális szervert, és végezzük el újra a tesztet.

Így lehetünk csak biztosak, hogy m ködik az átkapcsolás Azt is ellen rizzük le, hogy minden kliensünk képes nyomtatni, valamint, hogy a Windows 2000 és Windows XP ügyfelek látják az Active Directoryban a nyomtatónkat. Ezzel megteremtettük a megbízható, központosított nyomtatás alapjait. Végezetül néhány Knowledge Base cikket sorolok fel, amelyek eligazítást nyújthatnak a cikk által érintett problémák esetén. Q185212 Q186496 Q194831 Q208243 Q224967 Q254219 Q257389 Q229733 Cluster Server Does Not Support More Than 900 Shares Securing a Common Folder SP4 Cluster Shares Must Be Reset to Recognize Added Subdirectories Folder Share-Level Permissions Override Subfolder Permissions How to Create File Shares on a Cluster Security Considerations When Implementing Clustered File Shares Microsoft Cluster Server Does Not Share Folders Automatically During Cluster Failover Print Queue Monitoring May Stop Lepenye Tamás (MCSE 2000) lepenyet@mal.hu Ez a dokumentum a

NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár Farkasokkal táncoló V. – Cluster a gyakorlatban Ezúttal is alapozó munkát végzünk, folytatjuk az ismerkedést az er forrástípusokkal. Nem ígérhetek könny olvasmányt: minden típusnak megvan a maga bogara, és nem árt ezekkel tisztában lenni, miel tt használni akarjuk ket. A Microsoft hozzászoktatott minket a varázslók használatához, most viszont b ven akad majd dolgunk „kézzel” is. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár Olyan infrastrukturális szolgáltatásokról szólunk, mint a DTC és az IIS, az SMTP, az NNTP, a WINS és a DHCP. A Distribution Transaction Coordinator szintén bevallom, nem tartozom a fejleszt k csapatába, ezért nem sok figyelmet szenteltem az MSDTC szolgáltatásnak, a fürtszolgáltatással

való ismerkedésem során pedig sosem gondoltam volna, hogy ezzel az er forrással valaha találkozni fogok. Holott igen fontos dologról van szó A Microsoft meglehet sen sok alkalmazását készítette el úgy, hogy számít az MSDTC meglétére – talán ezért is került be a Windows 2000 operációs rendszerbe. Ilyen alkalmazás az SQL, a BizTalk, az Application Server, a Commerce Server, a Message Queue Server és bizonyos esetekben az IIS is. Olyannyira fontos lehet ez, hogy például az MSDTC-t mindenképp az SQL el tt érdemes fürtösíteni. Akik tehát ilyen alkalmazásokat üzemeltetnek majd fürtkiszolgáló környezetben, azoknak érdemes megismerkedniük az MSDTC er forrással. A Distributed Transaction Coordinator talán az egyik legfurább er forrás. Két érdekes tulajdonsága is van Minden leírás szerint (lásd a cikk végén a KB hivatkozásokat) egyetlen példány elég bel le fürtönként, vagyis úgy viselkedik, mint a quorum lemez vagy a többi

clustercsoportbeli er forrás. A Q294209 szerint a clustercsoportban a helye, én azonban nem osztom ezt a véleményt, mert a saját tapasztalatom az, hogy az MSDTC jó pár más er forrást is magával „ragad”, ami nem kívánatos. A másik érdekes tulajdonsága, szintén minden forrás szerint, hogy nem a szokásos módon és felületr l lehet létrehozni. No, nézzük ezt a csodabogarat! • El ször gy z djünk meg róla, hogy az MSDTC mindkét állomáson fut. (Az biztos, hogy létezik ilyen service, mert a Windows 2000 nem is telepíthet e nélkül). • Válasszuk ki azt a csoportot, ahol az er forrást létre akarjuk hozni. El feltétel, hogy ebben a csoportban legyen egy lemez, egy hálózati név és egy IP cím er forrás. • Hozzuk létre az MSDTC-t az er forrás varázslóval. • Tegyük függ vé a hálózati névt l. • Hagyjuk az MSDTC-t offline állapotban. • Hozzunk létre a csoport fizikai lemezén egy dtclog könyvtárat. • Az egyik állomás

Winntsystem32dtclog könyvtárából másoljuk át a fájlokat a közös meghajtón lév mappába. • Tegyük függ vé attól a fizikai lemez er forrástól, amely az el z könyvtárat tárolja. • Ha minden rendben van, akkor futtassuk a comclust.exe programot parancssorból az els állomáson, majd a másodikon is. A comclust egy clb er forrást is hozzáadna a clusterhez, de ez nem sikerül neki, a figyelmeztetését nem kell komolyan venni. A lényeg, hogy az MSDTC létrejött (Lásd 1 ábra) Az MSDTC er forrást létrehoztuk. A COM+ -ra vonatkozó információkat figyelmen kívül hagyhatjuk. Miért van szükség erre a hókusz-pókuszra? Nos, tapasztalataim alapján azért, mert az er forrás varázsló és az MSDTC nincs összecsiszolva. A varázsló nem mozgatja át a már meglév logokat a közös lemezre Kitalálták tehát a fejleszt k a comclust programot, amely képes egy teljes MSDTC er forrást létrehozni a következ változásokkal: • Létrehozza az er forrást.

• Létrehoz egy közös lemezen egy könyvtárat a tranzakció logoknak. • Átmásolja a regisztrációs adatbázis megfelel részét a cluster hive alá. Csakhogy a comclust az els lehetséges csoportot választja ki, ahol van fizikai lemez, IP cím és hálózati név. Az els csoport általában a cluster er forráscsoport, ide kerülne be az MSDTC, amely egyáltalán nem kívánatos. Ezért kell „rábeszélni” a segédprogramot, hogy a mi elképzeléseinket kövesse, és az általunk preferált csoportba kerüljön az MSDTC. Mindenképpen javaslom, hogy a sikeres létrehozás után teszteljük az át- és visszaköltözést. Az MSDTC-t l függ újabb er források telepítése után (SQL, Biztalk stb.) pedig újra végezzük el a tesztet El fordulhat persze, hogy a kiszolgálófürtöt úgy kaptuk meg, hogy a tranzakció koordinátor a cluster csoportban van. Ha szeretnénk más csoportba áthelyezni, van rá mód, a Q243204 cikkben leírtak szerint. Mondanom sem kell, ahogy

nem használható az egyszer er forrás-varázsló a létrehozáskor, úgy nem lehet egy egérkattintással áthelyezni sem az MSDTCt. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár Nehéz volt? Lehetett volna ennél sokkal bonyolultabb is a létrehozás, akit érdekel a cikk végén talál némi irodalmat. Ha pedig valaki aggódna, hogy minden könyvtár-költöztetés problémát jelent majd, azokat szeretném megnyugtatni: elég, ha továbbolvassa a cikket, a DHCP és a WINS nem szenved ilyen gondoktól. Az Internet Information Server Most, hogy már minden csínját-bínját ismerjük az MS DTC létrehozásának és életben tartásának, nekiugorhatunk az IIS-nek is. Azért kellett a tranzakció-koordinátorral kezdeni, mert a webhelyünk esetleg tranzakciókat használ Ilyenkor az IIS er forrást függ vé kell tenni az MSDTC-t l, egyébként – természetesen – nem. Ahogy

azt korábban is tettük, gy z djünk meg, hogy az IIS mindkét állomáson m ködik. Semmi nem említi ugyan, de célszer ugyanazokat a szoftver-komponenseket telepíteni mindkét szerveren, rejtett hibákat lehet így elkerülni. A továbbiakban feltételezem, hogy már létezik egy er forráscsoport, amelynek van legalább egy lemezer forrása, egy IP címe és egy hálózati neve, továbbá, hogy ebben a csoportban definiáltuk az MSDTC er forrást is. • Hozzunk létre a lemezer forráson egy könyvtárat, amely majd a publikálandó anyagainkat tartalmazza. Lehet ez például N:InetPubWWWRoot. Helyezzünk el a könyvtárban valamilyen tartalmat, hogy kés bb tesztelni tudjuk a m ködését • Hozzunk létre egy IP cím er forrást. Ez lesz majd az IIS szerverünk IP címe Tegyük az IP címet függ vé az MSDTC er forrástól. • Az egyik állomáson, – célszer en azon, amelyik a csoportunkat birtokolja – hozzunk létre az IIS MMC beépül moduljával egy új webhelyet

(Web Site). Az IP cím és az alapértelmezett könyvtár legyenek azok, amelyekr l az el z két pontban szó volt. • A cluster administrator segítségével hozzunk létre az er forráscsoportunkban egy IIS er forrás példányt. A szokásos kérdéseken túl csak arra kell válaszolnunk, hogy melyik Web helyet akarjuk fürtözni, s hogy annak mi a típusa. Az er forrásvarázsló utolsó kérdése az IIS er forrás létrehozásakor Ezzel az els állomoson végeztünk - de csak az els n! Rá kellene venni a másik állomást, hogy az IIS konfigurációja ugyanaz legyen, mint els é. Másképp fogalmazva: a két állomás metabase adatbázisát szinkronizálni kell IIS 40-tól létezik egy segédprogram, amely épp erre hivatott, iissync a neve. Használatának az a feltétele, hogy az anonim felhasználókat megszemélyesít felhasználói fiókok (IUSR kiszolgálónév, IWAM kiszolgálónév) azonosak legyenek mindkét állomáson. Célszer tehát létrehozni egy IUSR cluster és

IWAM cluster felhasználót, majd „Log on locally” felhasználói jogot adni nekik a fürt állomásaira vonatkozóan. Ezt az alábbi lépéseknek kell követnie: • Az Internet Services Managerben ki kell választani a friss, fürtözött webhelyet, és a „Directory security” tulajdonságlapján módosítani kell a névtelen hozzáférések fiókját az új IUSR cluster névre. • A %systemdrive%:inetpubadminscripts könyv-tárból le kell futtatni az alábbi parancsokat: Cscript adsutil.vbs SET W3SVC/WAMUserName domainIWAM cluster Cscript adsutil.vbs SET W3SVC/WAMUserPass "jelszo" • Végezetül kiadhatjuk a régen várt parancsot arról az állomásról, amelyik a helyes IIS beállításokat tartalmazza: iissync masikallomasneve El fordulhat persze, hogy els re nem sikerül a szinkronizálás, ahogy azt az ábra is mutatja. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3

NetAcademia-tudástár Ez a szinkronizálás még nem sikerült A sikertelenség senkit ne keserítsen el. A Q224801 cikk a hibakódokat és a lehetséges okokat fejti vissza A fenti hiba oka valószín leg az, hogy a két állomáson nem azonos javítócsomag van. Ha sikeresen lefutott az IISSYNC, akkor már csak azt kell tesztelni, hogy az át- és visszaköltözés problémamentes-e, s máris készen vagyunk: el állt egy hibat r IIS szerver. Megkérdezheti a Kedves Olvasó, hogy vajon mi értelme van egyáltalán az IIS ilyetén konfigurálásának, hiszen van sokkal jobb módszer is nagy rendelkezésre állású webfarm létrehozására, mégpedig az NLBS. Nos, a válasz az, hogy a Kedves Olvasónak igaza van, amennyiben az IIS a „cél”. Ám nem szabad elfelejteni, hogy az IIS maga lehet „eszköz” is, amelyet egy másik alkalmazás kíván használni. Ha egyenszilárdságot akarunk, és mindkett t azonos szerveren helyezzük el, akkor ésszer mindkett nek azonos

rendelkezésre állást biztosítani. Ezért van értelme az IIS er forrás létrehozásának Az SMTP és az NNTP er forrás Az Internet Information Serverhez hasonlóan fürtözhet az IIS-hez járó SMTP és NNTP szolgáltatás is, méghozzá az IIS-hez egészen hasonló módon. Ezeknél a szolgáltatásoknál csupán az a fontos, hogy a fürtökre feltett SMTP más porton „figyeljen”, mint a virtuális szerveren definiált. A szolgáltatásokhoz el feltétel az IIS fürtösítése, vagyis mindaz, amit eddig leírtunk. Lássuk, hogyan m ködik az SMTP fürt a gyakorlatban: • Gy z djünk meg róla, hogy mindkét állomáson telepítve van az SMTP. (Ha az IIS-nél precízen dolgoztunk, akkor ez nem gond.) • Gy z djünk meg arról, hogy mindkét állomáson kézi indítású az SMTP szolgáltatás, és Localsystem fiók alatt fut. • Indítsuk el az adminisztrációs eszközök közül a Computer Managert, és az Internet Information Services modulban válasszuk ki az

alap-értelmezett SMTP virtuális szerver tulaj-donságait. Az els lapon látható „Advanced” gombra kattintva átállíthatjuk az állomás SMTP szerverének alapértelmezett portját. Erre azért van szükség, hogy a node képes legyen fogadni egy olyan virtuális SMTP kiszolgálót, amelyik majd a 25-ös, tehát a normál portot használja. A fürtkiszolgáló felkészítése nagy rendelkezésre állású SMTP kiszolgáló fogadására • • Ezután – akárcsak az IIS esetében – hozzunk létre egy új virtuális SMTP kiszolgálót, amelyet majd fürtözni fogunk. Miután ezzel is végeztünk, a cluster administrator segítségével létrehozhatjuk az SMTP er forrást, amelyet függ vé kell tenni az IIS IP címét l, magától az IIS er forrástól, és a fizikai lemezt l, amely a mailroot könyvtárat tartalmazza. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár •

Az utolsó el tti lépés az IISSYNC futtatása, valamint a másik node alapértelmezett SMTP virtuális szervere portjának átállítása. • Végezetül tesztelni kell, hogy az át- és visszaköltözés problémamentesen m ködik. Tekintve, hogy a NNTP szolgáltatás ikertestvére az SMTP-nek, nem válok felületessé, ha azt mondom: csak ugyanúgy, mint az SMTP protokollnál. A Windows Internet Name Service és a Dynamic Host Configuration Protocol er források A cikk elején már említettem, hogy a WINS és DHCP er források korántsem olyan problémásak, mint például az MSDTC. Valóságos felüdülés a telepítés az el z khöz képest. A clusterszolgáltatáshoz képest a telepítés bármilyen sorrendben történhet, vagyis akár utólag is dönthetünk úgy, hogy WINS-t, vagy DHCP-t fürtözünk. Arra persze ügyelni kell, hogy mindkét állomáson telepítsük a szolgáltatásokat. A varázsló rákérdez a függ ségekre (fizikai lemez, hálózati név, IP cím),

továbbá definiálnunk kell az adatbázisok helyét, amelyeknek természetesen egy fizikai lemez fürter forráson kell elhelyezkedniük. Néhány apróságot azért még érdemes megjegyezni. A DHCP-t szolgáltatást hitelesítenünk kell, amennyiben Active Directoryt használunk. Figyeljünk, hogy a hitelesítés alatt ne az aktuális állomás, hanem a virtuális kiszolgáló IP címét jegyezze be a DHCP Administrator, különben az átköltözésnél gondok lesznek. A WINS szolgáltatásnál ügyelni kell, hogy a fürtkiszolgáló általában „multihomed” számítógép. A legegyszer bb, ha a privát hálózaton letiltjuk a NetBios interface-t, ahogy azt a Q193890 is írja. A WINS beállítható úgy, hogy másolatot készítsen a saját adatbázisáról. Az adatbázis megsérülése, vagy elvesztése esetén ez hasznos lehet. Csakhogy a fürtnél a másolatnak is közös lemezen kell elhelyezkednie, amelyet mindkét állomás elér, vagyis a másolat együtt veszne az

eredetivel. A Q283290 választ ad a problémára – de err l még szó esik majd a következ cikkekben. A két szolgáltatással kapcsolatban jogosan vet dik fel a kérdés: miért vesz dött a Microsoft a fürtözéssel, hisz mindkett nél létezik jól m köd , nem cluster alapú redundáns konfiguráció is? A válasz egyszer : a két szolgáltatás tranzakcióalapú adatbáziskezelést végez. Íme, itt a példa, hogyan lehet fürtkompatibilis alkalmazást írni. Persze nem csak ez volt az egyetlen érv A WINS és a DHCP, bár kicsi és láthatatlan szolgáltatások, mégis az IP alapú Windows hálózatok alappillérei. Azok pedig legyenek nagyon megbízhatóak Nos, a Windows 2000 megjelenésével azok lettek. Lepenye Tamás, MCSE 2000 lepenyet@mal.hu Q243204 MSDTC Disaster Recovery Techniques Q248025 Configure Clustered IIS Virtual Servers on Win2000 Adv Server Q290624 HOWTO: Configure MSDTC in a Windows 2000 Cluster Environment Q294209 INF: Rebuilding or Moving MSDTC Used with

a Failover Clustered SQL Server Q249603 Using IISSYNC to Synchronize Clustered Web Sites on Windows 2000 Q248025 Configure Clustered IIS Virtual Servers on Win2000 Adv Server Q280400 Configuring SMTP Resource on a Windows 2000-Based Server Cluster Q258693 CLUSTER: IIS Server Instance Resources Offline After NNTP Install Q283290 Backing Up a WINS Database on a Windows 2000 Cluster Q193890 Recommend WINS Configuration for Microsoft Cluster Server Q226796 Using WINS and DHCP with the Windows 2000 Cluster Service Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár Farkasokkal táncoló VI. – Cluster a gyakorlatban Elkanyarodunk a különböz típusú er források taglalásától – az a néhány, ami még hátra van, megvár minket, amikor a nagyobb alkalmazások fürtösítését vizsgáljuk. Most azt vesszük górcs alá, miként viselkedik a fürt, ha a feladata a hálózati

infrastruktúra ellátása, címtárszolgáltatás, globális katalógus és egyéb, a Windows 2000 számára kritikus szolgáltatás biztosítása. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár A farkasfalkára egy nagyvállalatot is rá lehet bízni – és ilyen majdnem tisztán fürtökb l álló rendszer már van Magyarországon. A feladat Nem sokkal a Windows 2000 megjelenése el tt azt a feladatot kaptam, hogy készítsek egy tervet szerverparkunk megújítására. Több telephelyes vállalat a miénk, 5 városban, hat helyszínen vagyunk jelen Három üzemünkben egyenként 120-160 felhasználónk dolgozik, a kisebb irodaépületekben 10-40 munkatárs végzi napi tevékenységét – az egyik kis telephely ezek közül az informatikai központ. Olyan kiszolgálókat kellett lecserélni, amelyek már majdnem négy éve üzemeltek, nem voltak b víthet k, s mivel a

felhasználók számának növekedését nem tudták követni, itt is, ott is egy-egy újabb, PC-b l avanzsált társuk kerekedett. A „szerves” fejl dés eredményeképp az egyik tartományvezérl volt, a másik nem, az egyik nyomtató-kiszolgálóként és Exchange levelez ként egyaránt funkcionált, a másikon csak egy SQL Server árválkodott – elég vegyes volt a kép, nem kell ezt ragozni. A feladat minket érdekl része két egyszer , egymásnak teljesen ellentmondó cél elérése volt: • legyen kevesebb kiszolgáló, és • legyen nagyobb a rendelkezésre állás Miért ellentmondó célok ezek? Ha az állománymegosztások három kiszolgálón, szétszórva m ködnek, még ha kiesik is az egyik, az állományelérés mint funkció mégsem sz nik meg teljesen – nem mondhatjuk, hogy nincs semmi, legfeljebb, hogy nem m ködik minden. Ellenben ha valamennyi közös mappát egyetlen vasra koncentráljuk, annak kiesése a teljes funkció elvesztését jelenti – ez

botrány lenne. A kiszolgálók számának csökkentése viszont nemcsak azt jelenti, hogy kevesebb lesz bel lük, hanem azt is, hogy tervezetten ugyan, de eleve több funkciót látnak majd el. Ez még rosszabb helyzetet teremt: a megosztásokkal együtt az összes hálózati nyomtató is elt nik! A megoldás a fürtszolgáltatás után kiált. Elkezdtem tehát a cluster után kutatni – ám leginkább olyan esettanulmányokat találtam, amelyek a sorozat els részében emlegetett tiszta konfigurációt tartalmaztak, vagyis amikor a fürtöt egyetlen feladatra, például egy ERP rendszer üzemeltetésére használták. Ez nem jó hír, ugyanis telephelyenként legalább két Windows 2000 tartományvezérl , két DNSés két globális katalógus kiszolgáló dukál, nem is beszélve a DHCP és a WINS infrastruktúráról Úgy t nt, hogy a fürtszolgáltatás nem visz el re, mert ugyan nagyobb megbízhatóságot nyújt, de több szervert követel. Vagy mégsem? Technet – kimerít

mélységekig Elhatároztam, hogy mindent összegy jtök a fürtökr l, és ha lehet, akkor erre a szolgáltatásra építve készítem el a tervet. El ször néhány alapvet problémát kellett tisztázni. Világossá vált, hogy a fürtszolgáltatás csak egy szolgáltatás a szerveren, az tehát nem lenne újdonság, hogy emellett más szolgáltatások is megjelennének. A kérdés csak az, hogy hogyan viszonyulnak a fürthöz Irodalmazással kiderült, hogy sokféle lehet ez a viszony: • A fürtözésre felkészített (angolul: cluster-aware) szolgáltatások szeretik és várják a rendelkezésre állás növelését. Számos ilyen létezik: az állomány-megosztások, a nyomtatósor, a WINS, a DHCP, az IIS, illetve a külön megvásárolható termékek, mint az Exchange, az SQL, a Biztalk stb. Az ilyen funkciók elkészítésekor a programtervez k számoltak azzal, hogy az alkalmazás fürtre kerül, ezért beépítették a fürt támogatását. • Vannak fürtözésre fel nem

készített, de fürtözhet alkalmazások. Ezek általában nem Microsoft termékek, de szerkezetükben olyanok, hogy fürtözésük lehetséges. A nálunk m köd JD Edwards vállalatirányítási rendszer is ilyen, de gyakorlatilag a legtöbb, szabványos NT szolgáltatást létrehozó alkalmazás fürtözhet . • Vannak nem fürtözhet alkalmazások, amelyek azonban m ködhetnek a fürtszolgáltatás mellett. A Windows 2000 önmaga is tartalmaz ilyeneket, például a DNS-t és a címtárszolgáltatást. Önálló termékként megemlíthetjük a SharePoint Portal Servert. • Végezetül vannak olyan alkalmazások, amelyek ütköznek a fürtszolgáltatással, és nem telepíthet k Windows 2000-re, amennyiben a cluster m ködik. Ilyen a Systems Management Server minden verziója vagy harmadik félt l származó programok közül a Sotfware Metrics „Print Accounting Server” nev terméke, amely a nyomtatási költségeket képes nagyon precízen költséghelyekre lebontani. Nos, a

történetünk szempontjából az a fontos, hogy minden, az operációs rendszerrel kapott Windows 2000 szolgáltatás képes m ködni a fürt mellett, még ha a fürtbe nem is lehet bevonni. Ezek után nincs más teend , mint megtervezni a teljes hálózatot. Fürtökre alapozott infrastruktúra Vállalatunk az alábbi alapvet informatikai szolgáltatásokat nyújtja minden telephelyen a felhasználóknak: • Egységes címtár (beléptetés, hitelesítés) • Állományok központi elérése • Központi (kiszolgálón definiált) nyomtatók • Levelezés, kiszolgálón tárolt postaládákkal • Internet, központi kijárattal • Antivírus-rendszer, automatikus vírusadatbázis-frissítéssel Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár • Intranetoldalak (nem túl sok) Mindezek mellett vannak a felhasználók által nem ismert, de létez szolgáltatások, mint a

névfeloldás és a tallózás (DNS, WINS), az IP cím adminisztráció (DHCP) és persze a mentés. Természetesen nálunk is van vállalatirányítási rendszer, de a mi szemszögünkb l az nem infrastrukturális szolgáltatás, hanem alkalmazás – tehát most nem tárgyaljuk. (Egyébként persze az is fürtön fut.) A cluster nem olcsó, tehát csak bizonyos számú felhasználó esetén érdemes alkalmazni. Ökölszabályként azt mondhatjuk, hogy ha egy szolgáltatást 100 felhasználó igényel, akkor azt érdemes fürtösíteni. Nálunk négy ilyen telephely van, vagyis legalább négy egyforma fürt kellene, a következ feladatokkal: 1-es állomás, nem fürtözött szolgáltatások: • Tartományvezérl • DNS, GC • Antivírus szoftver 1-es állomás, fürtözött szolgáltatások: • Állománymegosztások • Webszolgáltatások • Nyomtatómegosztások • DHCP, WINS • Mentés 2-es állomás, nem fürtözött szolgáltatások: • Tartományvezérl • DNS, GC •

Antivírus szoftver 2-es állomás, fürtözött szolgáltatás: • Levelezés (Exchange 2000) Egyszer bb ezt egy ábrán megmutatni: Fájl- és nyomtató szolgáltatás Adatbázis alkalmazás Er forrás-tartalék az adatbázis alkalmazáshoz Er forrás-tartalék a fájl- és nyomtató szolgáltatáshoz DC,GC DC, GC DNS DNS Antivírus Antivírus Fürt LAN Rendszergazda Ügyfelek Egy infrastruktúrafürt felépítése és funkciói Az adatbázisalkalmazás jelen esetben az Exchange 2000. (Tényleg az! Ha valaki nem hiszi, járjon utána!) Minek nevezzük ezt a konfigurációt? Aktív-passzívnak, vagy aktív-aktívnak? Tulajdonképpen mindkét állomás aktív, olyan feladatokat lát el normál esetben, amilyeneket a másik nem. A szolgáltatások fel l nézve azonban ez aktív-passzív szerkezet, mert egy szolgáltatás (a fürtözhet k persze) egy id pillanatban csak az egyik kiszolgálón érhet el. Nevezzük el tehát a fenti alkotást hibrid konfigurációnak, ezzel

mindenki elégedett lehet. Persze néhány apróságot még meg kell oldani. Ezek a problémák nem a fürt meglétéb l fakadnak, hanem abból, hogy a funkciókat rázsúfoljuk egy-két vasra. Ekkor is m ködik minden – csak egy picit oda kell figyelni a tervezéskor DNS és globális katalógus Tiszta Windows 2000 környezetet tervezve nem kétséges, hogy a címtárral integrált DNS zónáknak több el nye is van, legyen tehát a névfeloldás ilyen. A GC funkció viszont bizonyos esetekben ütközik az így konfigurált DNS szolgáltatással A Q252695 számú cikk részletesen leírja a jelenséget, melynek lényege a következ . Ha AD-integrált DNS zónákkal dolgozunk, és a tartományvezérl nk TCP/IP beállításai a vezérl DNS-ére mutatnak, akkor újrainduláskor a globális katalógus szolgáltatás nem képes rekordokat regisztrálni a DNS Serverbe, mivel az csak kés bb indul el. A leírás már adja is a megoldást: a tartományvezérl nk abban az esetben nyújthat

GC és címtárral egyesített DNS szolgáltatást, ha a TCP/IP beállításai nem a saját DNS-ére mutatnak. Azt ajánlom, hogy a fürtkiszolgálók DNS beállításait a következ képp adjuk meg: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár 1. DNS kiszolgáló – a fürt másik tagja 2. DNS kiszolgáló – a központban egy DNS szerver 3. DNS kiszolgáló – önmaga Azért célszer egy nem fürtbeli DNS kiszolgálót is megadni, mert el fordulhat, hogy a fürt másik tagja nem érhet el. Végs esetben jobb, ha önmagához fordul a vezérl , minthogy feladja a próbálkozást. DNS 2 2 DNS DNS 3 3 1 TCP/IP 1 TCP/IP Fürt LAN Rendszergazda Ügyfelek A fürt TCP/IP beállításaiban a helyes DNS kiszolgáló sorrend Az FSMO szerepek Kezdünk felépíteni egy szép, szimmetrikus világot, csakhogy a valóság ennél egy kicsit bonyolultabb. A Windows 2000 Serverek

címtárszolgáltatásánál létezik öt olyan funkció, amelyet egy erd ben csak egyetlen kiszolgáló nyújthat. Ezeket angolul „Flexible Single Master Operation”-nek, magyarul „rugalmasan állítható egyedi szerepkör”-nek fordíthatnánk. Ismertnek tekintve a fenti funkciókat, a következ ket érdemes tudni, ha fürtözött környezetben dolgozunk. Az FSMO szerepköröket tetsz legesen tehetjük bármelyik fürtállomásra, amely egyben tartományvezérl is - egyetlen kivételszabály van csupán: az a kiszolgáló, amely globális katalógus szerver, nem lehet egyben az „Infrastructure Master” szerepkör tulajdonosa. A szabálynak nincs köze a fürtökhöz, egyébként is érvényes, de a lassan formálódó szimmetriánkat tönkreteszi. Ha van olyan fürtállomásunk, amelyik ezt a szerepet viseli, akkor csak a társa lehet GC hordozó, önmaga nem Amit még feltétlenül ajánlok az az, hogy nagybet kkel véssük fel, hova tettük az egyedi FSMO szerepeket. Az

FSMO funkciónál nem a m ködésük a gond, hanem a hiányuk és a helyreállításuk. Fürtök tervezésekor mindenképp ki kell dolgozni egy tervet arra az estre, ha az egyik vagy másik állomás véglegesen felmondja a szolgálatot, és ki kell cserélni. A katasztrófa-elhárítási tervben kiemelt helyet kell kapnia az FSMO szerepeknek. El nyök és hátrányok Bevallom, hogy a cikkben felvázolt infrastruktúráról még sehol sem hallottam. Egyes elemei megtalálhatók a tudásbázis cikkeiben, egészében azonban nincs publikált esettanulmány. Mindeddig Mostantól azonban van A leírt koncepció m ködik, méghozzá egy magyar nagyvállalatnál – lényegében háromnegyed éve problémamentesen. Joggal teszi fel a Kedves Olvasó a kérdést: milyen el nyei és hátrányai vannak egy ilyen szerkezet hálózatnak? Nos, el nyként jelentkezik az egyszer megvásárolt, de többszörösen élvezhet redundancia. Kett , azaz kett kiszolgálóval a fenti szolgáltatások magas

rendelkezésre állásúvá váltak. A legalapvet bb szolgáltatások is betonbiztosak – csak a beállításokra kell egy kicsit ügyelni. Fontos, hogy a tartományvezérl k mindig kéznél vannak – így nem fordulhat el , hogy a fürtszolgáltatás nem indul el, vagy a felhasználók hitelesítése nem történik meg. Ne felejtsük: a fürt rendelkezésre állása kisebb vagy egyenl a tartományvezérl szolgáltatás rendelkezésre állásánál. Esetünkben ez nem probléma, míg ha a vezérl külön kiszolgálón üzemel, és elérhetetlenné válik, akkor a felhasználók nem lesznek képesek hozzáférni a szolgáltatásokhoz, mert nincs hitelesítés. Hátrányként emlegetik tudásbázis cikkek, hogy a tartományvezérl k többleter forrást igényelnek. Erre az a válaszom, hogy Magyarországon semmiképp. Egy ilyen fürt amúgy is rengeteg tartalékkal rendelkezik – nem tapasztaltam problémát vagy lassulást emiatt. Ha valaki nagyon aggódó alkat, akkor ajánlom neki

a „tartományocskák” szakasz elolvasását Sokkal inkább érdekes az alkalmazások (az Exchange, az SQL) és a tartományvezérl k egy állomáson való elhelyezése, de a Q298570-es cikkben leírtakon kívül nem tudok gondokról. A cikkek nem sorolnak viszont néhány olyan hátrányt, amelyek mégis csak léteznek. A kisebbik probléma, hogy olyan szolgáltatások, mint a betárcsázás, nem fürtözhet k, biztonsági okokból pedig nem ajánlott tartományvezérl kre telepíteni Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár ket – tehát kilógnak a sorból. A nagyobbik probléma, hogy több memóriaéhes alkalmazás azonos kiszolgálóra telepítése (pl. SQL és Exchange) méretezési- és válaszid problémákhoz vezethet Absztrakt szabályt úgy fogalmazok a fentiekb l, hogy az infrastruktúra kialakítása a fenti módon megoldja a rendelkezésre állás és a

felfelé történ méretezhet ség problémáját, sz kíti azonban a funkciób vítés lehet ségét. Az el re megtervezett szolgáltatásokon felül nehéz újakkal kiegészíteni a fürtöt. Mindezen korlátok ellenére úgy gondolom, hogy az egyik legstabilabb rendszert sikerült létrehozni Azt azonban nem szeretném állítani, hogy ez a tökéletes megoldás. Ha valakinek kiegészítenivalója, esetleg kritikai megjegyzése van, szívesen válaszolok a Netacademia tech.net levelezési listáján Függelék: „Tartományocskák” Nem árt eléggé hangsúlyozni: ha egy nagy rendelkezésre állású szolgáltatás egy küls er forrástól függ, akkor annak is nagy rendelkezésre állásúnak kell lennie, különben a teljes rendszerben Achilles sarkot hagyunk. Ez a helyzet a tartományvezérl kkel is. Ha valaki aggódik amiatt, hogy egy tartományvezérl funkció további terheket jelent a fürt számára, de szeretné biztosnak tudni a fürt indulását, kés bb pedig a

hitelesítést, annak a „tartományocska”, (angolul: domainlet) megoldást ajánlom. Ennek lényege a következ : létrehozunk az AD erd ben egy új tartományt, és minden fürtállomást ebbe a tartományba telepítünk tartományvezérl ként. Ha a tartományban nem hozunk létre felhasználókat és egyéb AD objektumokat, akkor jelent sen csökken a címtárszolgáltatás er forrásigénye. Csak a globális katalógusok okoznak problémát – hiszen azok továbbra is méretesek maradhatnak. Ezen azonban segíthetünk: helyezzük el az alábbi kulcsot minden vezérl regisztrációs adatbázisában. Nem kell értéket adni – a Windows 2000 csak a kulcs meglétét vagy hiányát ellen rzi. HKLMSYSTEMCurrentControlSetControlLsaIgnoreGCFailures Ha a kulcsok már léteznek, akkor kikapcsolhatjuk a globális katalógus funkciót az „AD Sites and Services” mmc modul segítségével az alábbi párbeszédpanelen. Ha nincs pipa, nincs globális katalógus sem Így minimális

lesz a tartományvezérl k er forrásigénye, és mindig elérhet k lesznek. Több fürtnek elég egyetlen tartományt létrehozni. A megoldásnak ugyanazok a hátrányai, mint egy közönséges újabb tartománynak: többletadminisztráció Lepenye Tamás MCSE 2000 lepenyet@mal.hu Ajánlott tudásbázis cikkek: Q237366 SMS: Microsoft SMS and Clustered Server Environments Q174837 Microsoft BackOffice Applications Supported by MSCS Q266650 BackOffice Program Support on Windows 2000 Datacenter Server Q252695 DNS Server Generates Event 4011 Q223346 FSMO Placement and Optimization on Windows 2000 Domains Q281662 Windows 2000 Cluster Nodes as Domain Controllers Q298570 BUG: Virtual SQL Server 2000 Installations May Fail if Installed to Windows 2000 Domain Controllers Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár Farkasokkal táncoló VII. – Cluster a gyakorlatban Az infrastruktúra

területén tett kirándulásunk után visszatérünk az er források világába, és megnézzünk, hogyan lehet fontos alkalmazásszoftvereknek magas rendelkezésre állást biztosítani. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár Látni kell, hogy itt már nem pusztán egy szolgáltatást hozunk létre, hanem egy teljes alkalmazást helyezünk el fürtözött környezetben, ez pedig minden eddiginél nagyobb figyelmet követel t lünk. A következ kben két Microsoft-terméket és egy harmadik, más gyártótól származó szoftvert vizsgálunk meg. A Microsoft Exchange fürtkörnyezetben Az Exchange Server az 5.5-ös verzió óta támogatja a clustertechnológiát, mi azonban most csak a Windows 2000 – Exchange 2000 párost vizsgáljuk. Ebb l sem valamennyi verziót: csak az Exchange 2000 Enterprise Edition változat képes együttm ködni a fürtszolgáltatással, vagyis

ezen változat megléte követelmény a telepítéshez. A Microsoft üzenetkezel -alkalmazása natív módon támogatja a fürtkörnyezetet. Ez azt jelenti, hogy saját er forrás DLLekkel rendelkezik, amelyek az Exchange-komponensek és a fürt közötti kommunikációt biztosítják Pontosan ismeri azokat a fogalmakat, amelyekre a Microsoft fürtrendszer épül –a csoport, az er forrás, a függ ség és a quorum fogalmát. Többféle konfigurációt is létrehozhatunk (aktív-aktív, aktív-passzív), s t datacenter környezetben négy állomáson akár 3 aktív-1 passzív felállást is építhetünk. A négy aktív állomás egyel re nem támogatott Az alkalmazás tervez mérnökei az „Exchange Virtual Server” fogalmát úgy valósították meg, hogy az egybeesik a fürt „csoport”-objektumával, ha a következ feltételek teljesülnek: a csoportnak van fizikai lemez, IP-cím és hálózati név er forrása, továbbá a teljes fürtre vonatkozóan már létezik a

„System Attendant” nev , az Exchange 2000 részeként szállított er forrás. Az Exchange egyes komponensei pontos függ ségi viszonyban vannak egymással, ahogy ezt az alábbi ábra mutatja: Az Exchange-komponensek függ ségi rendszere A levelez t jól ismer Olvasónak felt nhet, hogy korántsem teljes ez a lista. Valóban Sajnos az Exchange 2000 bizonyos komponensei nem fürtözhet k. Íme a lista: Microsoft Active Directory™ Connector (ADC) Chat Service Microsoft® Exchange 2000 Conferencing Server Instant Messaging Key Management Service Exchange Calendar Connector Exchange Connector for Lotus cc:Mail Exchange Connector for Lotus Notes Exchange Connector for Microsoft Mail Exchange Connector for Novell GroupWise Event Service Network News Transfer Protocol (NNTP) Site Replication Service (SRS) Eltér en a korábbi verziótól, akkor sincs mód a komponenst önállóan az állomásra telepíteni, ha maga esetleg önálló alkalmazás lenne (csevegés, azonnali

üzenetküldés, konferenciaszerver), mert a protokollinformációk a fürtben találhatók. Ha tehát szükség van ezekre az alkalmazásokra, akkor újabb, önálló Exchange Servert kell telepítenünk. Azért nem olyan vészes a helyzet: az ADC és az SRS csak átmenetileg szükséges (amíg 5.5-ös rendszerünkkel kell együttélnünk), a konnektorok pedig nem fürtözött szolgáltatáshoz kapcsolódnak – így valószín leg nem keletkezik Achilles sarok attól, hogy a csatolószoftver nem fürtözhet . Nem korlát, de jó, ha tudjuk: az MTA er forrás mindig aktív-passzív, másképp fogalmazva, egy fürtben egyszerre csak egy MTA er forrás lehet aktív, még datacenter esetében is. Az MTA mindig az els virtuális szerveren jön létre, és ha kés bb törölnénk, új csoportba költözik mindaddig, amíg legalább egy Exchange virtuális kiszolgáló létezik a fürtön. Az Exchange 2000 telepítés el készületei Járjuk körül egy kicsit pontosabban, mit is jelent az

aktív-aktív, illetve az aktív-passzív konfiguráció! Azt a korábbi cikkekb l már tudjuk, hogy a Microsoft fürt-implementációja nem nyújt terhelésmegosztást, nem erre tervezték. Minden egyes Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár létrehozott er forrás számára a rendelkezésre állás növelését kínálja. Aktív-passzív beállításnál ez egyértelm Az egyik állomás helyet ad az Exchange virtuális kiszolgálónak, vagyis a fürt egy csoportjának, ha pedig valamilyen hiba lép fel, ez a csoport átköltözik a másik szerverre, amely eddig csak magában dohogott. Aktív-aktív rendszernél sincs ez másképp, a különbség az, hogy a második állomáson is van egy virtuális Exchange kiszolgáló. Milyen funkciót lát el? Bármi mást, mint az els . Ha például az egyik fürtcsoport a felhasználók postaládáit kezeli, a másik állomáson a

másik Exchange a nyilvános mappákat. Az aktív-aktív jelz tehát a teljes fürtre értend , nem az egyes virtuális szerverekre, azok ugyanis mindig csak az egyik node-on futnak. A tervezésnek más fontos momentuma is van. Egy Exchange 2000 kiszolgálónak legfeljebb négy ún adattárcsoportja (storage group) lehet. (Ez nem keverend össze a fürtcsoporttal Az adattárcsoport olyan, mint egy adatbázis az 55-ös verzióban, persze számos új tulajdonsággal.) Itt szándékosan nem virtuális kiszolgálóról beszélünk, hanem valódiról Tehát egy fürtállomáson is legfeljebb négy adattárcsoport lehet. Ebb l viszont következik, hogy a teljes fürtben nem érdemes négynél több adattárat definiálni. Ha az alábbi ábrán a második virtuális kiszolgálónak át kellene költöznie az els állomásra, a három adattárcsoportjából csak kett indulna el: Exchange Virtuális szerver 1 Exchange Virtuális szerver 2 Adattár1 Adattár1 Adattár2 Adattár2 Adattár3

Fürt LAN Rendszergazda Ügyfelek Az adattárak száma nem lehet több négynél egy Advanced Server fürtben A telepítésnek vannak olyan feltételei, amelyek nemcsak a fürtökre, hanem minden Exchange kiszolgálóra érvényesek, (pl.: DNS, AD, GC telephelyek stb.) Ez azonban nem témája vizsgálódásunknak Vannak viszont a fürttel kapcsolatos egyedi feltételek is, amelyeket be kell tartani. Ezek: • Egyszerre nem szabad telepítést végezni mindkét állomáson. Az id vel nem így kell takarékoskodni Különösen igaz ez, ha tartományvezérl kre telepítjük a rendszerünket. • A fürtszolgáltatás fiókja legyen tagja az „Exchange Full Administrator” csoportnak! Figyelem! Ezt mindkét állomáson érvényre is kell juttatni, vagyis a fürtszolgáltatást legalább egyszer újra kell indítani, vagy meg kell várni, amíg a Kerberos jegyet megújítja a szolgáltatás (8 órán belül). • A telepítést a két állomáson szimmetrikusan kell elvégezni –

ugyanazokat a meghajtókat kell használni. Az alkalmazást nem kell közös lemezre tenni, használható a „C:Program filesExchgsrv” mappa. • Kötelez felrakni legalább a „Messaging and Collaboration” és a „Microsoft Exchange System Management Tools” komponenseket. A továbbiakban feltételezem, hogy az erd - és tartományel készítés már megtörtént. A fürtre telepítés a következ lépésekb l áll: 1. Az els állomáson az Exchange 2000-et telepítsük az operációs rendszert tartalmazó lemezre! Ide kerülhetnek az adatbázisok is. 2. Végezzük el a telepítést az els vel azonos módon a második állomáson is! 3. Hozzunk létre egy csoportot a Cluster Administrator segítségével! Adjuk meg azokat az állomásokat, amelyekre a csoport átköltözhet! A csoport neve legyen a majdani Exchange 2000 virtuális szerver neve. 4. Hozzunk létre IP-címet, hálózati nevet és lemezer forrásokat! A hálózati név lesz az Exchange 2000 szerverünk neve 5.

Afenti csoportban hozzunk létre az er forrás-varázsló segítségével egy Exchange System Attendant er forrást! Tegyük függ vé a hálózati névt l és a fizikai lemezt l! 6. Ellen rizzük le, hogy a „Data Directory” párbeszédpanelen a fizikai lemez er forrást adtuk-e meg! 7. Indítsuk el a „System Attendant” er forrást! Ha mindent jól végeztünk, akkor a „System Attendant” elkezd dolgozni, és az er forráscsoportot további er forrásokkal népesíti be. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár A System Attendant elvégezte a munkáját Az Exchange 2000 fürt immár munkára kész. Ha aktív-aktív rendszert szeretnénk építeni, akkor a másik állomáson ugyanezeket a lépéseket végrehajtva új virtuális szervert hozhatunk létre. A telepítéskor még egy fontos dolgot kell tudni. Ha már létezik Exchange 55 rendszerünk, akkor a fürt nem

lehet az els Exchange 2000 szerver az adott telephelyen. A telepítés ugyan hiba nélkül lezajlik, de az Exchange konfigurációs információk másolása az Exchange 5.5 kiszolgálóról nem történik meg Ezért ugyanis a „Site Replication Service” szolgáltatás a felel s – az viszont nem m ködik fürtön. Azt javaslom, hogy ilyen esetben el ször egy nem fürtözött Exchange 2000 kiszolgálót keltsünk életre, azon automatikusan létrejön az SRS szolgáltatás. Az Exchange 55 elt nésével a SRS szerepe megsz nik – így nem lesz akadálya az azonnali fürtre telepítésnek sem. A Microsoft SQL 2000 fürtkiszolgálókon Az SQL Servernél több szempontból is szerencsénk van az Exchange 2000-hez képest. A termék, jellegénél fogva, nem els sorban szerverszolgáltatások elosztott hálózata (habár a szerverek közti replikáció képességével rendelkezik), sokkal inkább beszélhetünk önmagában álló kiszolgálókról, amelyek mindenekel tt a

felhasználókkal kommunikálnak, esetleg más – nem SQL – szolgáltatások adatkezelését támogatják. Ráadásul a termék címtárszimbiózisa sem olyan mérték , mint az Exchange 2000-nél, inkább lehet ség, mint kötelesség. Így aztán nem kell csodálkozni, hogy m szaki értelemben jóval egyszer bb feladat a fürtözése, mint a levelez -kiszolgálóé volt. Ha még azt is hozzátesszük, hogy egy SQL Server általában el bb válik üzletileg kritikus alkalmazássá, mint egy Exchange, akkor már szinte dupla a haszon. Nézzük tehát, mit kell tudni a fürtbe állításhoz. Az SQL fürtözési technikával való együttm ködése sokat fejl dött, mára már természetes a fürt natív támogatása (saját er forrás DLL állományokkal rendelkezik). Olyan szép ez a házasság, hogy nincs is szükség külön beállítgatásokra, az adatbáziskezel fürtre települ, ha azt mondják neki, és a fürtb l való eltávolítása is csak a telepít „Eltávolítás”

funkciójával valósítható meg. Akár 16 er forráscsoportban 16 SQL szervert futtathatunk - ennek persze nincs sok értelme, viszont az aktív-aktív rendszer jól jöhet. Itt az aktivitást ugyanúgy kell értelmezni, mint az Exchange 2000 esetén Az SQL további simulékonyságát bizonyítja, hogy az egyállomásos fürtt l a négyállomásos adatközpontig mindenütt otthon érzi magát a clusteren. Nemcsak a fogalmak azonosak, hanem a szolgáltatások igénybevétele is szabványos Az SQL fürt pontosan úgy vizsgálja önmaga egészségét, ahogy az elvárható: „looks alive” és „is alive” vizsgálatokat végez rendszeresen, ez utóbbit SELECT @@VERSIONSQL lekérdezéssel. Egy szó mint száz, ezt a két alkalmazást egymásnak teremtették Tiszta haszon, hogy a fürt és az adatbáziskezel így ismerik egymást. Az SQL szerver tulajdonképpen egy er forráscsoport lesz, ahogy azt vártuk. Az adatbázisok majd a közös lemezer forráson helyezkednek el, és újra

szükségünk lesz egy hálózati név meg egy IP-cím er forrásra. No meg egy Distributed Transaction Coordinatorra is (a cikksorozat ötödik részében már megismerkedtünk vele), fürtönként egy dukál ebb l. Ugyancsak egyetlen példány lesz fürtönként a Microsoft Message Queuing (MSMQ) és a „Full Text Search” komponensekb l. Talán sehol sem olyan fontos a kiszolgáló méretezése, mint az adatbáziskezel nél, ezért javaslom, hogy nagyon körültekint en becsüljük meg a felhasználók számát, a tranzakciók és a tárolt adatok mennyiségét, a szükséges memória méretét. Ebben a vonatkozásban egy fürt éppúgy viselkedik, mint egy hétköznapi kiszolgáló, annyi kiegészítéssel, hogy állomásonként egynél több aktív SQL kiszolgáló példány megnehezíti a dolgunkat, mert a rendszer memóriáját mindkét szerver magánál szeretné tudni. Egy alkalmazás egyszer esetben Windows 2000 alatt legfeljebb 2 GB memóriához juthat 32 hozzá, ami a 32

bites memóriacímzésb l fakad. 2 =4294967296 vagyis 4 GB, ám ebb l 2 GB az operációs rendszeré NT4 alatt ugyan megjelent a BOOT.INI-ben egy /3GB kapcsoló, ám ez nem oldotta meg a problémát, csupán az operációs rendszert korlátozta 1 GB-os címtartományba, így engedve az alkalmazásoknak 3 GB-ot. A Windows 2000 ennél sokkal elegánsabb megoldást is hozott, ez pedig az AWE, azaz Address Windowing Extensions. A funkciót alkalmazás-hozzáférési csatolókkal (API) lehet elérni, vagyis az alkalmazásnak ismernie kell a lehet séget és a csatolófelületet. Szerencsére az SQL 2000 ezt ismeri, így Advanced Server fürtkörnyezetben hozzávet legesen 8 GB memóriát használhat, datacenter környezetben ez 64 GB is lehet. Fontos, hogy az AWE-támogatást be kell kapcsolni, mert az adatbáziskezel kezdetben nem használja. Az AWE-támogatás példányonként értend , vagyis ha több Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon

terjeszthet  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár er forráscsoportban több virtuális SQL kiszolgálót hozunk létre, akkor mindegyiknél külön-külön el kell végezni a bekapcsolást. Mindenképpen azt tanácsolom, hogy az AWE használatát alapos teszt el zze meg Az SQL többi hardverrel kapcsolatos követelményéhez már nem a fürt, hanem az adatbáziskezel kézikönyveit kell bújni. Az SQL telepítése fürtre Az ismétlés elkerülése érdekében a telepítést úgy kezdjük, hogy már feltételezzük az MSDTC meglétét (lásd: Farkasokkal táncoló V.) 1. Indítsuk el a telepít t! 2. Az „Installation options” képerny n válasszuk az „Advanced option”-t! 3. A következ képerny n válasszuk a „Maintain a virtual server for failover clustering” lehet séget! 4. Itt adhatjuk meg a fürtb l már ismert fogalmak tartalmát: virtuális kiszolgáló nevet választhatunk, IP-címet és alhálózatot adhatunk meg. 5. A „Cluster

Management” képerny n megtekinthetjük a fürt konfigurációját Telepítéskor a szerver mindkét állomásra fel fogja másolni az SQL állományokat. (Ezen a ponton lényeges eltérés tapasztalható az SQL Server és az Exchange között: az SQL mindkét állomást „megdolgozza”, az Exchange Server viszont nem.) 6. Végezetül meg kell adnunk a lemezer forrásokat, amelyeket használni szeretnénk Ha véletlenül a Quorum lemezét adjuk meg, akkor az SQL er teljesen tiltakozik. Ez érthet , többször említettük a Quorum és a clustercsoport sérthetetlenségének elvét. Ne telepítsünk semmit a Quorumba! Ezzel végeztünk is. Aktív-aktív konfigurációnál hasonló módon hozhatunk létre újabb virtuális szervereket Már a tervezés során igen fontos, a használat közben pedig kritikus lehet a házirend arról, hogyan költözzön az SQL virtuális szerver az egyik állomásról a másikra, s éppilyen fontos, hogyan költözzön vissza. Az át- és

visszaköltözés ugyanis megszakítja a meglév kapcsolatokat, azokat tehát újra fel kell építeni. Mivel az ügyfelek oldalán általában egy üzleti alkalmazás fut, nem mindegy, hogy miként valósították meg a fejleszt k a kiszolgálótól való elszakadást. Ha a kapcsolat nem épül fel automatikusan, esetleg újra kell indítani az ügyfélprogramokat. Ilyenkor érdemes a kevésbé terhelt id szakra id zíteni az er forráscsoport visszatérését eredeti helyére, hogy ne okozzon újabb szolgáltatástkiesést a normális üzemre történ visszaállás. Ennek a megoldásnak is lehet hátránya, ahogy azt mindjárt látni fogjuk Az átköltözési szabályokat befolyásolhatja az eltér memóriamennyiség vagy memóriaigény a különböz állomásokon. Rosszul tervezett memóriahasználat SQL fürtözésnél A bal oldali ábrán azt látjuk, hogy az egyik állomáson bekapcsolták a 3 GB támogatást, a másikon nem. Az átköltözéssel er teljesen vissza fog esni a

teljesítmény, mert a második állomáson nem „fér el” az SQL Server. A jobb oldali ábrán mindkét állomáson bekapcsolták a 3 GB kapcsolót, ám az aktív-aktív konfiguráció állomásainak teljes fizikai memóriája csak 4-4 GB, tehát egy átköltözés ismét teljesítménycsökkenést okoz majd. A tisztánlátás kedvéért: nem arról van szó, hogy az átköltözés nem történik meg, hanem arról, hogy visszaesik a teljesítmény, a rendszer intenzív lapozásba kezd. Még több virtuális SQL Servernél a probléma hatványozottan jelentkezik. Ez arra sarkallhatja a rendszergazdákat, hogy minél el bb állítsák helyre az eredeti állapotot, még az ügyfelek ismételt leszakadása árán is. Hosszú távon persze csak az alapos tervezés és el regondolkodás segíthet. Túlzás lenne azt állítani, hogy kimerítettük az összes tudnivalót az SQL és a fürt kapcsolatáról, de egy jó alapozást végeztünk. Befejezésül egy olyan alkalmazást veszünk

górcs alá, amelyet nem is a Microsoft gyártott, mégis fürtre kész, és bizonyos helyzetekben nélkülözhetetlen. Az ArcServe 2000 fürtözött környezetben Az ArcServe 2000 a Computer Associates által gyártott mentési rendszer. Azt mondhatjuk, hogy az ArcServe 2000 ma (majdnem) mindent tud, amit Windows környezetben egyáltalán tudni lehet, beleértve az olyan nyalánkságokat is, mint a szalagos könyvtárak, a RAID szalagok és a fürtök támogatása. Ez utóbbi nemcsak azt jelenti, hogy a szoftver lementi a fürthöz tartozó beállítások halmazát (a Quorum lemezt és a regisztrációs adatbázis cluster ágát), hanem azt is, hogy az ArcServe maga is fürtözhet , így a mentési feladatok minden körülmények között lefutnak, függetlenül attól, hogy épp melyik állomáson aktív egy er forráscsoport. Ez a rövid leírás nem lesz elegend ahhoz, hogy az ArcServe 2000 minden tulajdonságát megismerjük, amelyet fürtözött környezetben magáról mutat.

Annyit teszünk csupán, hogy a szoftvert a fürtre telepítjük, illetve megvizsgáljuk, milyen el nyök származnak a szolgáltatás megvalósításából. Az ArcServe 2000 fürtözése alapvet en három célt szolgál: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár 1. A hálózaton található ArcServe ügynökök számára nagy rendelkezésre állású ArcServe kiszolgálót biztosít 2. Sz k keresztmetszet esetén egy második ArcServe 2000 szervert lehet üzembe helyezni (aktív-aktív fürt) 3. Meghibásodás miatt félbeszakadt mentési munkafolyamatokat automatikusan újra lehet indítani Az ArcServe 2000-nek saját er forrás DLL-je van, ám valami oknál fogva azt nem regisztrálja magától, tehát nekünk kell megtenni ezt a lépést. Ezen kívül végképp nincs segítségünk, az alapszoftver telepítése után ránk vár a fürtbe állítás feladata. A munka menete a

következ : 1. Telepítsük az ArcServe 2000-et az els állomáson a közös lemezre! 2. Telepítsük a Tape Library opciót! 3. Állítsuk be a közös mentési eszközt az állomáson! 4. Telepítsük az ArcServe 2000-et a második node-on a közös lemezre! 5. Ide is telepítsük a Tape Library opciót! 6. Állítsuk be a közös mentési eszközt az állomáson! 7. Ha Fibre channel környezetben dolgozunk, akkor mindkét állomáson állítsuk be az alábbi regisztrációs kulcsot: HKLMSoftware.TapeengineConfig Érték: EnableSharedDevices: DWORD: 1 8. Adjuk ki a következ parancsot mindkét állomáson: cluster resourcetype "ARCserve" /create /dllname:ascluster.dll 9. Hozzunk létre egy er forráscsoportot, vagy jelöljünk ki egyet, és készítsünk egy ArcServe er forrást például így: cluster resource "My ARCserve" /create /group:"Csoportneve" /type:"ARCserve" 10. Tegyük függ vé az er forrást a fizikai lemezt l! 11. Hozzunk

létre egy általános szolgáltatást: cluster resource "My ARCserve Registry" /create /group:"Csoportneve" /type:"Generic Service" 12. Adjuk meg a szolgáltatás nevét: astapeengine! 13. Adjuk meg az alábbi regisztrációs kulcsot: “SOFTWAREComputerAssociatesARCserveITBase”. 14. Hozzunk létre egy megosztáser forrást az alábbi paraméterekkel: Megosztásnév “ARCserve$”! Elérési út: “S:Program FilesComputerAssociatesARCserve”. Ezzel elkészült a fürtözött ArcServe szolgáltatás. Az ArcServe 2000 fürtkörnyezetben Véget ért az er forrásokkal való ismerkedés. Legközelebb hibaelhárítással és egyéb kacifántos helyzetekkel foglalkozunk majd. Lepenye Tamás, MCSE 2000 lepenyet@mal.hu Q292757 Exchange 2000 Setup and Installation Top Support Issues Q239758 SRS Cant Run in Native Exchange 2000 Environment Q192708 Installation Order, Cluster Server Support for SQL or MSMQ Q260758 Frequently Asked Questions - SQL 2000 -

Failover Clustering Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 6 NetAcademia-tudástár Q225092 Evicting a Node in a Cluster Can Cause Problems in SQL Q239885 How to Change Service Accounts on a SQL Virtual Server Q243218 Installation Order for SQL 2000 Enterprise Edition Q254321 Clustered SQL Server Dos, Donts and Basic Warnings Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 7 NetAcademia-tudástár Farkasokkal táncoló VIII. Cluster a gyakorlatban A fürtök általában jól megtervezett, redundáns eszközökkel ellátott, hibat r rendszerek. Mégis, a leggondosabb el készítés ellenére is elfordulhat, hogy valami mégsem úgy m ködik, ahogyan kellene. Sorozatunk most következ részében megvizsgáljuk, milyen hibák fordulhatnak el , és azokat hogyan orvosolhatjuk. Ez a dokumentum a NetAcademia Kft. tulajdona

Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár Vissza a tervekhez A hibák és leállások megértéséhez a legfontosabb fürtkiszolgálónk felépítésének és m ködésének nagyon pontos ismerete. Nézzük át még egyszer a cikksorozat elején felvázolt rendszerünket! Az állomásokból két hálózati kártya lép ki a helyi hálózat felé, egy direkt kábelkapcsolat pedig a „szívhang”-forgalomhoz szükséges csatornát biztosítja. Lent állomásonként két adathálózati csatolókártya (host bus adapter) biztosítja az összeköttetést adathálózati hubokon keresztül a lemeztömbökkel. (Szaggatott vonallal jelöltem a másodlagos, tartalék útvonalakat) LAN Node 1 Node 2 SAN Hub SAN Hub HS1 HS2 OK1 OK2 PS Data router 1 2 3 4 5 6 7 8 9101112 COLACTSTA- CONSOLE disk alrendszer Tape library Bombabiztosnak t n fürtrendszer Eléggé biztosnak látszik a felépítés. Most képzeljük el, hogy az

egyik hub – mondjuk a jobb oldali – ventilátora leáll, és a bels vezérlés lekapcsolja az eszközt! Ekkor a szerverek adatcsatoló kártyái észlelik, hogy elveszítették a kapcsolatot a lemezekkel. Az eszközök gyártója által megírt szoftvernek (a Compaq-nál ez a SecurePath) fel kell építenie egy másik kapcsolatot a lemezek felé, méghozzá olyan gyorsan, hogy a fürtszolgáltatás ebb l semmit se észleljen. Mélyen, a hardver közelében járunk, ez a szoftverkomponens kernel üzemmódban fut. Szerencsés esetben a folyamat pillanatok alatt lezajlik, rosszabb esetben viszont a cluster szerviz is észleli a problémát, és megpróbálja átvinni az er forráscsoportokat a másik állomásra. Ha az id közben már át tudott állni az új adatútvonalra, az átmozgatás sikerül, míg ellenkez esetben bizony a cluster „beragadhat”. Az újraindítás persze segíteni fog, csak azon fogunk csodálkozni, hogy a szalagos egységet nem érjük el, mert az egy nem m

köd eszközhöz csatlakozik. Ha nem ismerjük a kapcsolatokat, nem fogjuk tudni, mi a probléma Az els szabály tehát: ismerd meg a rendszert, készíts róla áttekint ábrát, dokumentációt, és frissítsd azt rendszeresen. A hibák behatárolása A fenti példából nagyon jól látható, hogy a fürt hibáinak jókora része nem a Windows 2000-ben, sokkal inkább az alatta dohogó hardverben és az azokat kiszolgáló eszközmeghajtókban keresend . Mi persze a fürt meghibásodását fogjuk észlelni, szükség lenne tehát egy olyan általános megközelítésre, amelynek a segítségével a hibajelenségt l eljuthatunk a tényleges hibáig, majd a hiba okát is felderítve elháríthatjuk azt. A tapasztalatok azt mondatják velem, hogy azt a réteges felépítést kell követni, ahogyan az eszközeink felépülnek. Ezen rétegek tetején a fürtszolgáltatás található, ahogy az alábbi ábra mutatja: Hibadiagnosztika és elhárítás iránya A szolgáltatások igénybe

vétele A szolgáltatások biztosítása Fürtszolgáltatás Hálózati szolgáltatások Operációs rendszer szolgátatások A fürtállomás hardverének szolgátatásai A teljes fürt hardvereszközeinek szolgáltatásai A hiba terjedése Szolgáltatási rétegek fürtöt tartalmazó hálózatban A hálózati szolgáltatások körébe sorolható névfeloldás nélkül a fürt elérhetetlen, címtárszolgáltatás nélkül m ködésképtelen – pedig ezek nem biztos, hogy a fürtön futnak! Az operációs rendszer rétegébe soroltam a fájlrendszereket, a TCP/IPszolgáltatást és az arra épül többi fontos funkciót, mint a RPC-szervizt, a nyomtatósort, a szerverszolgáltatást és a NetBIOS-t. Ide tartozik még minden bels alapszolgáltatás, például a memória- és prioritáskezelés, a szálak felügyelete stb Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár E réteg

alatt már a hardverszinthez közeledünk. Ezen a szinten dolgoznak a hálózati és adatcsatoló kártyák, a merevlemezek, valamint az állomásban található hardveralapú lemezredundanciát biztosító folyamatok (RAID 0, esetleg RAID 0+1). A legalsó rétegbe az állomáson kívüli, de a fürt kialakítását biztosító hardverelemeket soroltam. Ilyenek a Fibre Channel kábelek, a SAN hubok, a data routerek, a szalagos könyvtárak, a tároló alrendszerek és vezérl ik. Nem nehéz elképzelni, hogy akár egyetlen fürtfunkció létrejöttéhez több mint száz, a fenti rétegek valamelyikébe sorolható komponensre is szükség lehet. Márpedig akkor ennyi komponens mehet tönkre Persze bizonyos hibák ellen jó tervezéssel védekezhetünk, másokra viszont fel kell készülni, mégpedig azon eszközök megismerésével, amelyek a hiba felderítését megkönnyítik. Nézzük, milyen arzenállal rendelkezünk A hibabehatárolás eszközei Az eseménynaplók: A Windows 2000

számos, fürttel kapcsolatos eseményt jegyez be az eseménynaplókba. Attól függ en, hogy a bejegyzést hol találjuk, már megbecsülhetjük, hogy a hiba melyik rétegben keletkezett. Az alkalmazásnapló leginkább logikai hibát jelez. A biztonsági napló bejegyzései hitelesítési és névfeloldási hibákat tárhatnak fel Ha a fürt nem tartományvezérl , ajánlatos bekapcsolni ezt a naplót, mert értékes információkat nyerhetünk vele. A rendszernapló általában az operációs rendszerben vagy az alatta lév hardverben keletkezett problémákat jelezheti. Mindez nem jelenti azt, hogy egyetlen hibához ne keletkezhetne akár mindhárom naplóban bejegyzés. Mindenképp azt ajánlom, hogy legel ször az alkalmazásnaplót vizsgáljuk, ezt kövesse a biztonsági, végül a rendszernapló áttanulmányozása. A cluster log: El fordulhat, hogy a Windows 2000 eseménynaplói nem nyújtanak elegend információt a hiba körülhatárolásához. Ekkor segítségünkre lehet a

mindkét állomáson megtalálható clusterlog állomány, amely a %systemroot%cluster mappában lakik. Ennek a naplónak saját szintaxisa van, a Windows 2000 Resource Kitben egy egész fejezetet szenteltek a kiértékelés el segítésére. Nekünk most annyit kell tudnunk, hogy a naplózás mértékét környezeti változók segítségével szabályozhatjuk. A változót (ClusterLogLevel) úgy kell megadni, mint egy hétköznapi környezeti változót, tehát a rendszerpanelt használva. Értéke 0 és 3 között változhat, amelyek az alábbiakat jelentik: 0 – Nincs naplózás 1 – Csak a hibák naplózása 2 – Hibák és figyelmeztetések naplózása 3 – Minden esemény rögzítése A napló mérete nem n 8MB-nál nagyobbra. Ha eléri ezt a méretet, 64K-s részenként felülírja a régi bejegyzéseket Amennyiben ennél több információt szeretnénk rögzíteni, egy másik környezeti változó (ClusterLogSize) segítségével ezt is megadhatjuk. A ClusterLogSize=12

például azt jelenti, hogy 12MB-os naplóméretet akarunk használni A hardvergyártó saját naplói: A beépített Windows 2000 naplók mellett nagyon fontosak a gyártó által létrehozott logok, az alacsonyabb rétegekben m köd eszközök naplóbejegyzései is. Ilyen például egy DMI log, egy lemezalrendszer napló stb A bejegyzések helyér l és azok értelmezési lehet ségér l a gyártónál kell érdekl dni (még az éles üzemet megel z en!). A legfontosabbak bizonyosan a lemezalrendszer eseményei lesznek, de meg kell tanulni a SAN kapcsolók naplóinak elérését és alapszint értelmezését is. Egy IBM lemezalrendszer bels naplója A lemezkezel (Disk administrator): A naplók mellett nem szabad lebecsülni azokat az eszközöket sem, amelyeket nem a fürtök figyelésére készítettek. A lemezkezel azért is érdemel különös figyelmet, mert a fürt közös elemeir l, a lemezekr l nyújthat információkat. A diszkek megjelenése vagy hiánya, eltér bet jelei

mind ennek az eszköznek a segítségével állapíthatók meg. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár A teljesítményfigyel : A Windows 2000 nem tartalmaz fürttel kapcsolatos mérend objektumot, ami, ha meggondoljuk, érthet , hiszen a fürt normál m ködése szerint egy statikus, alig változó és transzparensen létez valami. A teljesítményfigyel inkább a fürt egyéb objektumainak (memória, processzor) vizsgálatára való, ám ezek az információk hasznosak lehetnek a fürt vizsgálatakor is. Ha például egy processz oly mértékben megterheli a fürtöt, hogy az nem képes válaszolni, a másik állomás esetleg átveheti az er forrásokat. Az ilyen jelleg hibák elhárításának egyik fontos eszköze a teljesítményfigyel . A feladatkezel (Task manager): A feladatkezel a Windows 2000 svájci bicskája. Villámgyors áttekintést ad a rendszerr l, annak

valóságos, pillanatnyi állapotáról. A nem fürt eredet , de a fürtszolgáltatásra is átterjedt hibák felderítését segítheti Szervizindítási paraméterek: Kevéssé ismert, hogy a fürtszolgáltatás maga, tehát a clussvc.exe is rendelkezik beépített diagnosztikai eszközökkel. Ha ugyanis már a szolgáltatás indítása sem sikerül, akkor a clusterlog nem tud segítséget nyújtani, a Windows 2000 eseménynapló pedig talán csak semmitmondó bejegyzésekkel van tele. Ekkor vehetjük igazán hasznát a /debug kapcsolónak, amely az indítással kapcsolatos eseményeket képes egy külön állományban összegy jteni. A használata igen egyszer : a %systemroot%cluster könyvtárból a következ parancsot kell kiadni: Clussvc /debug > C:clusdebug.log Figyelem! Ezt a kapcsolót kizárólag hibafelderítésre szabad használni. Ha a hiba megsz nt, a kapcsoló nélkül kell újraindítani a fürtszolgáltatást! A clussvc-nek vannak más kapcsolói is, ezekr l

azonban majd a hibaelhárításnál szólunk. Net helpmsg xxxx: Gyakran el fordul mind a Windows 2000 naplókban, mind pedig a cluster.log állományban, hogy csak egy lakonikus számot kapunk arról, hogy mi a hiba. Ekkor tehet jó szolgálatot a parancssorból kiadható net helpmsg <keresett szám> varázsformula, amely egy csapásra b beszéd vé teszi a hibaüzenetet. Például a 000005c8.000004c0::1999/12/12-03:53:20843 Physical Disk <Disk G:>: [DiskArb] Failed to read (sector 12), error 170. bejegyzést feloldhatjuk a net helpmsg 170 paranccsal, és ezt kapjuk: „The requested resource is in use.” Nem állítom, hogy ez már Kánaán, de egy kicsit el rébb jutottunk. Regedit és regedt32: A fürtszolgáltatás rendelkezik egy „cluster” ággal, amely megtalálható mindkét állomáson. Különösen a lemezekhez kapcsolódó hibák esetén juthatunk hasznos információkhoz a két segédprogrammal. Net View, Ping, Network Monitor: A hálózathoz köthet hibák

elhárításához a szokásos eszközöket vethetjük be. Saját dokumentáció és ellen rzési lista: A cikk elején már javasoltuk ennek létrehozását. Csak aki már javított dokumentálatlan fürtöt, az tudja, mennyire fontos a precíz leírás. Talán egyszer több teret szentelünk majd annak, hogy mi mindent tartalmazhat egy ilyen dokumentáció, de a legfontosabb részeit most is felsorolom: • Az eszközök kapcsolási rajza. • A lemezalrendszer redundáns tömbjeinek jelölése (esetleg szerepének leírása). • A hálózati kártyák jelölése, IP-címe, MAC-címe, szerepe. • Az er forráscsoportok funkcióinak leírása. • A telepített javítócsomagok, hotfixek felsorolása. • Speciális beállítások feljegyzése (pl. Regedit használatával a DisableDHCPMediaSense paraméter) • A fürt fiókjának adatai. • A nem fürtözött szolgáltatások leírása. Miel tt a konkrét hibaelhárításba belekezdenénk, néhány adatot szeretnék megosztani a

Kedves Olvasóval. A TechNet CD keres szolgáltatásában a „cluster NEAR (troubleshooting OR problem OR error OR failure)” feltételt írva 837 találatot kapunk. A Windows 2000-hez és NT4-hez köt d cikkek száma is 276 (Azért érdemes együtt számolni a két csoportot, mert a Windows 2000 hibák gyakran még az NT4 eredeti fürtszolgáltatásában jelentek meg.) Esély sincs tehát arra, hogy kimerít hibaelhárítási útmutatót tudjunk adni. Amit tehetünk, az a legfontosabb és leggyakoribb hibák leírása és értelmezése Aki nem találja ebben a cikkben a saját problémáját, az kénytelen lesz bújni a TechNetet, bombázni a levelezési listát, vagy ha szerencséje van, igénybe venni a Microsoft támogatási szerz dése nyújtotta lehet ségeket. Ez utóbbi csak szerencsés (premier support szerz déssel rendelkez ) munkahelyen dolgozó halandóknak adatik meg. A hibákat a következ k szerint csoportosítottam: 1. Telepítéssel kapcsolatos gondok 2.

Indítással kapcsolatos problémák 3. Nemkívánatos átköltözési jelenségek 4. Lemezekhez köt d hibák 5. Hálózati rendellenességek Hibák a telepítés során Az els állomáson nem sikerül a telepítés: A jelenség általában három okra vezethet vissza: hálózati hibákra, a fürtszolgáltatás fiókjával kapcsolatos problémákra vagy a közös lemezekkel összefügg hibákra. Ellen rizzük le, hogy a fürt sikeresen bejegyezte-e a nevét a WINS adatbázisba! Ha ez sikerült, akkor a hálózat és a névfeloldás nem okolható. Ellen rizzük, hogy a fiók megfelel jogokkal rendelkezik-e (például van-e joga szolgáltatást futtatni)! Nézzük meg, nincs-e beállítva, hogy szegény fürtünknek az els alkalommal meg kell változtatnia a fiók jelszavát! Végezetül ellen rizzük, hogy Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár minden majdani közös lemez

látható-e a lemezkezel b l: NTFS formátumúak, „basic” típusúak és hibátlan kötetek! A fejezet végén a Q176970 számú tudásbázis cikk segíthet ebben. A második állomáson nem sikerül a telepítés: Ellen rizzük, hogy a nyilvános hálózat elérhet -e a második állomás számára, helyesen állítottuk-e be az alhálózati maszkot és az alapértelmezett átjárót! Vizsgáljuk meg azt is, hogy eltér hálózati címet használunk-e a vegyes illetve a magán hálózati kártyánál! Nézzük meg egy egyszer ping paranccsal, hogy a magánhálózat jól m ködik-e! Indítással kapcsolatos problémák Az els állomás nem indul: Szinte ugyanazok a hibák léphetnek fel itt is, mint a telepítéskor. A fiók jogosultságait, a hálózat helyes m ködését, a névütközés elkerülését és a lemezek m ködését kell ellen rizni. A quorum lemez elérhetetlen, vagy hibás: Ugyan a lemezhibák között is szerepelhetne, de ezt célszer bb itt felsorolni, mivel a

jelenség, amit a hiba okoz, a fürt elindíthatatlansága. A cikk elején ajánlott rétegeket figyelembe véve gy z djünk meg arról, hogy a quorum lemez fizikailag nem sérült-e (az NTFS fájlrendszer ép?)! Ha így van, és a quorum mégsem érhet el, akkor a helyzett l függ en használjuk a cluster szolgáltatás „-fixquorum” vagy „-resetquorumlog” kapcsolóinak egyikét. Mindkét esetben csupán egyetlen állomáson fusson a fürt! A -fixquorum kapcsolóval elindul ugyan a fürt, de az er források kikapcsolt állapotban maradnak. Ekkor meg lehet próbálni csak a quorum er forrásait elindítani, és a clusterlog bejegyzései alapján megállapítható, mi a hiba. Ha a quorum log vagy a hozzá tartozó checkpoint-állomány sérült meg, akkor a –resetquorumlog kapcsoló lehet a megoldás. A fürtszolgáltatás ekkor egy ellen rzést végez a quorumon, és ha hibát talál, újra felépíti az adatbázist a %SystemRoot%ClusterCLUSDB regisztrációs adatbázis ág

segítségével. A fürtszolgáltatás nem indul: Az eseménynapló és a cluster.log áttanulmányozása mellett mindenképpen javaslom a tartományvezérl k elérhet ségének ellen rzését. Ha nincsenek a fürt számára elérhet tartományvezérl k, a szolgáltatás fiókjának hitelesítése nem lesz sikeres, tehát nem illetik meg azok a jogosultságok sem, amelyek a szolgáltatás elindításához szükségesek. A legbiztosabban úgy gy z dhetünk meg arról, hogy a fürt eléri a hitelesít kiszolgálókat, ha Network monitorral figyelemmel kísérjük a fürtszolgáltatás indulását. Nemkívánatos átköltözési jelenségek Az er forrás hibás státusba került, és nem indul újra: Ha az er forrás meghibásodik és leáll, a fürtszolgáltatás megpróbálja néhányszor újraindítani. Ám ha az er forrás elérte a saját meghibásodási limitjét, akkor a fürt többé nem indítja újra. Ekkor - minden bizonnyal alapos hibafelderítés és elhárítás után –

kézzel kell elindítanunk Nem indul egy er forrás akkor sem, ha úgy állítottuk be, hogy ne induljon. Rém egyszer , azért olyan nehéz erre rájönni A következ ábra segít a beállítások között eligazodni: Ami az újraindítást befolyásolja Lemezekhez köt d hibák A lemezek átköltözése sikertelen: Ez az egyik leggyakoribb hiba, amikor a Microsoft fürtöt káromolják, holott általában nem tehet a problémáról. A jelenséget szokták „beragadásnak” is nevezni Ténylegesen az történik, hogy a fürt mindkét állomása elveszíti a kapcsolatot a közös lemezekkel, gyakran valamennyivel. Ilyenkor szinte mindig hardverhibáról van szó Ellen riztessük le a szállítóval a host bus adaptereket, az adathálózat aktív elemeit (storage hubokat illetve switcheket) és végül a lemezalrendszer vezérl jét! Gondoskodjunk arról, hogy mindenütt a legfrissebb eszközmeghajtó és firmware verzió legyen! Végezzünk el teszteket, hogy hogyan történik az

átköltözés: szimuláljuk a SCSI vagy más kábelek szakadását! A szimuláció során vessük össze a cluster.log és az eszközök bels naplóit a hiba jelentkezésekor keletkezett bejegyzésekkel! Ha sikerül hasonló bejegyzéseket találni, akkor magát a hibát szimuláltuk, tehát megtudhatjuk, melyik eszköz hibázik. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár A tesztet nem olyan nehéz elvégezni. Az igazi gondot az jelenti, hogy a fürt már általában éles környezetben dolgozik, és nincs tartalék. Mindenki szeretné már használni az eszközt, egyre n a kiesett órák száma, miközben a hiba újra és újra el jön. Az erkölcsi veszteség még nagyobb, hiszen a drágán megvett fürtr l kiderül, hogy nem váltja be a hozzá f zött reményeket. Nagy jelent sége van tehát a szállító nyújtotta támogatásnak, és f leg annak, milyen prioritással

kezeli a hibákat. A levelezési fórumokon érdemes érdekl dni, kinek milyen tapasztalatai voltak kritikus hibák esetén a nagyobb gyártók reakcióképességeir l. A lemezek sikertelen átköltözésének más oka is lehet. Meg kell vizsgálni, hogy a lemezek bet jele lemezr l lemezre megegyezik-e mindkét állomáson. Ha nem, azt sürg sen javítani kell Mivel egy ilyen hibának még a tesztid szakban el kell jönnie, a súlyossága jóval kisebb, mint a fenti meghibásodásnak. Hálózati rendellenességek Az ügyfelek „nem látják” a virtuális kiszolgálókat: Ha meggy z dtünk arról, hogy az er források futnak, pingeljük meg a virtuális kiszolgálót. Ha nem érhet el, fizikai hálózati hibára, esetleg útválasztási problémára kell gyanakodni Ha IP-címmel megy a ping, a névfeloldással van baj. Ellen rizni kell, hogy a fürt névregisztrációja megtörténik-e Az ügyfelek nem tudják használni egy csoport szolgáltatását: Ez a jelenség f leg akkor

fordul el , amikor egy er forráscsoport átköltözött az egyik állomásról a másikra. Ilyenkor minden TCP-csatorna megszakad, hiszen azok valójában egy állomáshoz köt dnek, nem pedig a virtuális kiszolgálóhoz. A csatornákat újra fel kell építeni Err l a metódusról azonban az ügyfél- illetve szerverszoftver készít jének kell gondoskodnia. Exchange-Outlook esetén biztosak lehetünk abban, hogy az újrapróbálkozás elegend a kapcsolat újbóli létrejöttéhez. Egy SAP, Baan vagy JDE esetén az eredmény már nem ilyen bíztató, gyakran csak az ügyfél újraindításával lehet a hibát elhárítani. A fürt adminisztrátorprogramja nem indul: Ha az els , ún. cluster csoport nem érhet el, gyakran az adminisztrációs program sem nem hajlandó elindulni. Ilyenkor meg kell gy z dni arról, hogy a fürt valamelyik állomása más módon elérhet e Ha nem, hálózati hibára gyanakodjunk Ha elérhet (például be tudunk jelentkezni egy Windows terminálon

keresztül), van esély a cluster admin elindítására úgy is, hogy azt a m köd állomáshoz csatlakoztatjuk: cluadmin . Tessék figyelni a „.” kapcsolóra! Ez jelzi, hogy a helyi állomáshoz kell csatlakozni A fürt elt nik, majd megjelenik a hálózaton, a fürt hálózati beállításai „elállítódnak”: Ezt a hibát egy egész cikkben tárgyalta Fóti Marcell kollégám, a „Farkasokkal Netmonozó” cikkében, így itt csak a hibát említem meg. Ajánlom a korábbi számok áttanulmányozását is. Igazán csak belecsippentettünk a hibakeresés rejtelmeibe. A fürt áldás – ha jól m ködik Ha nem, akkor van igazán szükség a farkasszelídítési tudományunkra és gyakorlatunkra. Mint mindig, most is csak módszeres olvasást, tanulást ajánlhatok az Olvasónak. Remélem, még a baj bekövetkezése el tt teszem Lepenye Tamás, MCSE 2000 lepenyet@mal.hu Q258078 Cluster Service Startup Options Q168801 How to Enable Cluster Logging in Microsoft Cluster Server

Q266274 How to Troubleshoot Cluster Service Startup Issues Q245762 Recovering from a Lost or Corrupted Quorum Log Q176970 How to Run the CHKDSK /F Command on a Shared Cluster Disk Q265533 Explanation of Chkdsk Status Codes in Cluster Log Q295091 Hisecdc Causes Problems with Cluster Domain Controllers Q276457 Event Success Messages 4201 and 1122 Using Windows Clustering Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 6 NetAcademia-tudástár Farkasokkal táncoló IX. Cluster a gyakorlatban Az el z alkalommal a hibabehatárolás és hibaelhárítás tudományába kóstoltunk bele. Ezúttal olyan helyzeteket próbálunk megoldani, amikor a fürtöt olyan alapvet behatás éri, ami nem feltétlenül hiba, de akár az is lehet. Olyasmi szituációkat elemzünk, amikor „a Föld fog sarkából kid lni” Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003,

NetAcademia Kft 1 NetAcademia-tudástár Lemezcsere – földrengés Kaliforniában Többször vadásztunk már olyan pontokra, amelyek meghibásodása a teljes fürtöt használhatatlanná teszi. Találtunk is ilyeneket, és ha tudtuk, megszüntettük ket. Vannak azonban olyan összetev k, amelyekb l nem lehet több példányt használni – ezek a lemezek. Persze replikázhat az Olvasó, hogy azokat lemeztömbökbe lehet szervezni, így biztosítható az állandóságuk. Nem tudok teljesen egyetérteni Az állandóság biztosításáról nem érdemes beszélni, ha például t zvész pusztítja el a tömböt, de ennél kevésbé tragikus események hatására is elt nhetnek. Egy lemez ugyanis összetett dolog: nemcsak a lemezterületb l áll, hanem az t azonosító bet jelb l is, s t egy lemeznek szignatúrája, vagyis bels azonosítója is van a Windows NT – Windows 2000 világban. Ha bármelyik változik, a fürtszolgáltatásunk bizony azt gondolja, hogy a régi lemez elt nt,

és van itt valami új, amir l fogalma sincs, hogyan került ide. Err l úgy tájékoztat minket, hogy az adott lemezer forrás „hibás” állapotba kerül (quorum disk esetén a fürt el sem indul), az eseménynaplóban pedig az alábbi bejegyzést találjuk: Event ID: 1034 Source: ClusDisk Description: The disk associated with cluster disk resource <DriveLetter> could not be found. The expected signature of the disk was <DiskSignature>. Magyarán az adott bet jellel jelölt lemezt a fürt nem találta. Azt a lemezt egy <DiskSignature> kód azonosította volna A hiba beszédes, és messzemen következtetéseket lehet levonni bel le. 1. A fürt a lemezer forrásokat a bet jelük alapján tárolja, a fizikai lemezekhez pedig a lemezek szignatúrájának segítségével kapcsolja. Vagyis: egy lemez mindaddig „önmaga”, amíg szignatúrája és/vagy bet jele nem változik 2. A lemezek szignatúrája nem ismeretlen fogalom A Windows NT a dinamikus lemezekig

bezárólag ezt a módszert alkalmazta a diszkek azonosítására. Tulajdonképpen egy regisztrációs kulcsról van szó, ami egyúttal a rendszerr l rendszerre való hordozhatatlanságát is mutatja. Megérdemelten váltotta le a módszert a dinamikus lemez Mindebb l azonban az is következik, hogy a fürtszolgáltatás egy kicsit elmaradt a korától és környezetét l. Mivel a szignatúrát használja, a dinamikus lemezeknek pedig ilyen nincs, ezért a fürt és a dinamikus lemez nem fér meg egymással. 3. A szignatúrák ismeretével és használatával könnyedén túljárhatunk a fürtszolgáltatás eszén Ha viszont a lemezek ezen fontos adatai elvesznek, nagy bajban vagyunk! Lássuk tehát, hogy a megszerzett ismeretekkel hogyan lehet szakszer en elvégezni a lemezek cseréjét. Legyen életszagú a példa: egy lemezterületet kin tt egy alkalmazás. Az alatta lév hardver lemeztömböt már sikerült b víteni, most azt kell elérnünk, hogy az „L:” meghajtó által

meghatározott lemez mérete megnövekedjék. A feladatlista a következ : 1. Teljes mentés minden meghajtóról 2. A fürt leállítása 3. A lemez szignatúrájának megjegyzése 4. A lemez törlése a RAID alrendszer szintjén 5. Egy új, már megnövelt terület lemez definiálása 6. A lemez formázása és bet jellel való ellátása 7. A lemez szignatúrájának megváltoztatása az eredeti jelsorra 8. Adatvisszatöltés 9. A fürt indítása A teljes mentés világos feladat, minden beavatkozás els lépése. Cluster esetén ez annyit jelent, hogy a mappák és állományok mentése mellett a rendszerállapotot (system state) is menteni kell. A fürt leállítása már egy kicsit összetettebb A menete a következ : 1. Állítsuk át az egyik állomáson a clustdisk és a cluster szolgáltatás indulását „kézi” vagy „tiltott” módra 2. Kapcsoljuk le az imént konfigurált állomást 3. Végezzük el az els m veletet a másik állomáson is 4. Indítsuk újra a

második állomást Ezzel elértük, hogy a fürtszolgáltatás nem indult el, így a lemezeket sem fogja. A szignatúrát a Windows 2000 Resource Kit dumpcfg.exe segédprogramjával nyerhetjük ki Futtatásához rendszergazdai jogokkal kell rendelkeznünk Kapcsoló nélkül indítva, két partíciót tartalmazó lemeznél a következ eredményt kapjuk: C:dumpcfg [System Information] Computer Name: TESTSERVER Cluster name (DNS): TESTSERVER.falatraxhu Cluster name (NetBIOS): TESTVSERV System Root (install directory): C:WINNT OS: Windows 2000 Server Service Pack: [DISKS] Disk Number: 0 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár Signature: 3137382D [Volumes] Volume #1: Drive letter: C: Volume Label: File System: NTFS Volume Type: Simple Volume Logical Drive Number of members: 1 Member #1: Partition - Disk: 0, StartingOffset: 32255 bytes, Length: 2047 MB Volume #2: Drive letter:

D: Volume Label: File System: NTFS BootBoot.iniSystem Volume: BOOT SYSTEM Volume Type: Simple Volume Logical Drive Number of members: 1 Member #1: Partition - Disk: 0, StartingOffset: 2146830336 bytes, Length: 2047 MB Miután a szignatúrát lejegyeztük, törölhetjük a RAID vezérl ben a logikai lemezt, és létrehozhatjuk az újat megnövelt területtel. A Windows 2000 szintjén ez azt jelenti, mintha egy új fizikai lemez került volna a rendszerbe A lemezkezel beépül modult elindítva az operációs rendszer fel is fedezi majd az „új” lemezt, új szignatúrát helyez el rajta és felajánlja, hogy konvertáljuk dinamikus lemezzé. Ez utóbbi m veletet ne engedélyezzük Elegend a régi bet jellel ellátni az új er forrásunkat. Most már van egy új, nagyobb területtel rendelkez lemezünk, csakhogy eltér szignatúrával, így a fürtünk bizonyosan nem fog indulni. A dumpcfg azonban újra a segítségünkre lesz Újra futtassuk le kapcsolók nélkül és hasonlítsuk

össze a kapott eredményt az eredeti futtatás kimenetével. Könnyedén meg lehet állapítani, hogy mi volt az eredeti és mi a jelenlegi szignatúra ugyanannál a meghajtónál. Egy újabb parancs kiadásával máris el lehet tüntetni a különbséget: C:dumpcfg /s <eredetiszignatúra> <új lemez száma> A lényeggel megvolnánk. Most már az eredetivel azonos bet jellel és szignatúrával rendelkezik az új lemezünk, tehát definíció szerint „azonos” is azzal. Nincs más dolgunk, csak a mentés visszaállítása, majd a fürt elindítása a leállításkor alkalmazott módszer visszafelé alkalmazásával. A fenti módszer egyébként akkor is m ködik, ha nem tervszer a lemez cseréje. Meghibásodás után ugyanis a cikk elején említett eseménynapló-bejegyzés pontosan megadja, hogy az eredeti lemez milyen bet jellel és szignatúrával rendelkezett, tulajdonképpen elvégzi helyettünk utólag az adatgy jtést. A mentést persze semmi sem pótolja!

Mivel a módszer bármely, a fürt által használt lemezre érvényes, akár a quorum-lemezt is cserélhetjük így. Van azonban ennél egyszer bb módszer is. Íme: 1. Definiáljuk az új lemezt a RAID vezérl ben 2. Ismertessük meg a diszket a Windows 2000 lemezkezel jével 3. Formázzuk meg és adjuk neki bet jelet 4. Definiáljuk lemezer forrásként a cluster er forráscsoportban 5. Jelenítsük meg a fürtkiszolgáló tulajdonságait (Jobbklikk a fürt nevén Tulajdonságok) 6. Adjuk meg az új er forrást az ábrán 1-gyel jelölt legördül listában 7. Adjuk meg a megfelel partíciót a 2-vel jelölt listában, ha több része van a lemeznek A fürt elvégzi a megfelel másolásokat. Ha végzett, próbáljuk ki az er források át- és visszaköltöztetését Ha nem tapasztalunk hibát, törölhetjük az eredeti quorum-lemezer forrást. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3

NetAcademia-tudástár 1 2 A quorum áthelyezése nem is bonyolult A fürt IP címeinek változása A lemezcserénél nem kisebb változás egy fürt életében, ha az állomások hálózati kártyája, vagy azok IP címe változik meg. Körültekint eljárással azonban ez a feladat is megoldható. A módosulás természetét két részre bonthatjuk: a küls , nyilvános hálózati csatolók vagy IP-címek, és a bels , szívhang forgalomra fenntartott kártyák vagy IP-címek változására. Kezdjük a nyilvános IP-címekkel. Fontos megjegyzés, hogy a változás közben gondoskodni kell arról, hogy a fürt képes legyen kommunikálni legalább egy tartományvezérl vel. Erre azért van szükség, hogy a fürtszolgáltatás fiókját a tartományvezérl képes legyen hitelesíteni. Mozgassuk át valamennyi csoportot a második állomásra, majd az els állomáson változtassuk meg az IP-címet. Indítsuk újra a node-ot. Újraindulás után err l az állomásról indítsuk el a

fürtadminisztrátort Csatlakozzunk újra a „” kapcsolóval az állomáson keresztül a fürthöz. Ellen rizzük az IP-er forrásoknál, hogy az új hálózati cím látható-e Ha igen, mozgassunk át minden er forrást erre az állomásra, és hajtsuk végre az IP-cím átállítást a másik állomáson is. Újraindítás után gy z djünk meg arról, hogy a régi hálózati címek elt ntek. IP címek a fürtben – Itt ellen rizhet , hogy elt ntek-e a régi címek a váltás után Ha az IP-cím mellett a hálózati alcímet is meg kell változtatni (vagy éppenséggel csak azt kell), sajnos nem úszhatjuk meg a virtuális szerverek teljes leállása nélkül. Ennek az az oka, hogy a fürtszolgáltatás jelenleg nem támogatja, hogy a fürtöt alkotó állomások külön hálózatban legyenek. (Ezt egyébként azonos alhálózati maszkkal sem támogatja!) A megoldás menete tehát a következ : 1. Valamennyi er forráscsoportban le kell állítani az IP-er forrásokat és a t

lük függ többi er forrást is Ezután lekapcsolható maga a fürtszolgáltatás is. Erre azért van szükség, hogy a fürtszolgáltatás indulásakor az IP-címek és a t lük függ er források még ne induljanak el. 2. Át kell állítani az állomások IP-címeit a fent leírt módon Az átmozgatást nem kell végrehajtani (nem is lehet) 3. Mindkét állomás átállítása után az álló IP-er források paramétereit (IP-cím, alhálózati maszk) át lehet állítani, majd egyesével elindíthatók. Szintén kieséshez vezet, ha a bels IP-cím vagy hálózati kártya változik. Míg az IP-cím változására itt minimális az esély, a bels kártya tönkremehet. Ha egy új kártyát teszünk be (amelynek új neve van), a fürt nem fogja automatikusan bels forgalomra használni, err l fel kell t világosítani. A változtatás menete röviden a következ : Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4

NetAcademia-tudástár 1. 2. 3. 4. 5. 6. Le kell kapcsolni a második állomást. Az els állomáson definiáljuk az új kártyát mint bels használatra szánt hálózatot. A változások mentése után kapcsoljuk le ezt az állomást is. Indítsuk el a második állomást. Gy z djünk meg arról, hogy a fürtszolgáltatás elindult, és a változásokat a futó állomás átvette. Az els node-ot újra indítsuk el. Gy z djünk meg arról, hogy a fürtszolgáltatás hiba nélkül m ködik Hálózati csatolók szerepe – tanítani kell a fürtöt Tartományváltás Még ritkábban, de el fordulhat, hogy a fürtöt egy másik tartományba kell áthelyezni. Sajnos itt nagyon kevés jó hírem van Habár egy fürt áthelyezése nem lehetetlen, a felette futó fürtözött alkalmazások korlátait figyelembe kell venni. Ha Exchange 2000 vagy SQL Servert fürtöztünk, az egyetlen járható út a fürt újraépítése. Más alkalmazások el tt tanulmányozzuk alaposan a gyártó

által biztosított dokumentációt. Tegyük fel azonban, hogy csak a Windows 2000 szolgáltatásaiból építettük fel a magas rendelkezésre állású szolgáltatásainkat, és tartományt kell váltanunk. Ekkor a következ tevékenységeket kell elvégezni: 1. Az új fürtszolgáltatás-fiók létrehozása az új tartományban A cikksorozat második részében leírtak szerint kell eljárni 2. Le kell kapcsolni a fürtszolgáltatást mindkét állomáson Az indítási paramétert „kézire” kell állítani 3. A fürtöt meg kell szabadítani a tartományvezérl funkciótól (Ez csak Windows 2000 alatt lehetséges Ha NT4-es fürtünk van, és azok tartományvezérl k, a tartományváltás nem lehetséges.) 4. El kell végezni az els állomás átmozgatását 5. Le kell cserélni a clusterszolgáltatás fiókját az új fiókra 6. El kell indítani a fürtszolgáltatást, és ellen rizni kell, hogy minden m köd képes Ha minden rendben, újra le kell állítani a szolgáltatást.

7. Át kell mozgatni a másik állomást is 8. Végre kell hajtani a fiókcserét itt is Visszaállítható a szolgáltatás indítása automatikusra 9. Indítható a fürtszolgáltatás Ha a DNS szolgáltatásunkat úgy konfiguráltuk, hogy csak biztonságos frissítést engedélyezünk, még egy problémába ütközhetünk. A virtuális szerverek névregisztrációját a korábbi fiók végezte, tehát az új fiók regisztrációs kérelmét a DNS kiszolgáló visszautasítaná. A legegyszer bb megoldás, hogy a DNS zónaállományból töröljük a virtuális szerverek neveit, majd a hálózati néver forrásokat újra kell indítani. Ekkor már sikeres lesz a regisztráció Lepenye Tamás, MCSE 2000 lepenyet@mal.hu Q251284 Cluster Server Cannot Start If the Quorum Disk Space Is Full Q280345 Quorum Drive Configuration Information Q280425 Recovering from an Event ID 1034 on a Server Cluster Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet 

2000-2003, NetAcademia Kft 5 NetAcademia-tudástár Q243195 Event ID 1034 for MSCS Shared Disk After Disk Replacement Q267548 Cluster IP Resource Fails After Network Change Q230356 Changing the IP Address of Network Adapters in Cluster Server Q279119 Unable to Fail Over the Cluster if Nodes Have Different Subnets Q269196 How to Move a Cluster Server from One Domain to Another Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 6 NetAcademia-tudástár Farkasokkal táncoló X. – Cluster a gyakorlatban Amikor a hibakeresést ismertettem, futólag említettem a cluster.log állományt is Akkor nem tudtam kell figyelmet szentelni ennek az eszköznek, csupán néhány fontos tudnivalót írtam le. Most újabb alapozásba fogunk, elmélyedünk a fürt bels világában és szerkezetében, hogy azután kés bb megismerhessük a fürt speciális eseménynaplóját is. Ez a dokumentum a NetAcademia Kft. tulajdona

Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár Egy állomás bels architektúrája A cluster.log elemzését csak akkor lehet elkezdeni, ha tisztában vagyunk a fürt és állomásainak bels architektúrájával Mindeddig nem beszéltünk err l, mert nem volt érdekes. Most azonban nem kerülhetjük meg, mert különben a clusterlog érthetetlen zagyvaság marad a számunkra. A cluster egyik állomásának fürtszolgáltatását (cluster service) vázolja az 1. ábra A clusterszolgáltatás architektúrája Vegyük sorra az egyes komponenseket: A cluster management alkalmazás nem más, mint a fürtadminisztrátor (cluadmin.exe) Ez a program a speciális fürtalkalmazás API-n keresztül tartja a kapcsolatot a clusterszolgáltatással. (clusterexe) A fürt egy állomáson három f alkotóelemb l áll: a fürtszolgáltatásból, az er forrás-ellen rb l (Resource Monitor) és az er forráskönyvtárakból. A cluster.exe több

bels komponensb l épül fel, amelyek együttesen valamennyi fürtspecifikus tevékenységet ellátják Már tudjuk, hogy minden állomáson fut egy-egy fürtszolgáltatás, de a bels komponensekr l és azok funkcióiról még nem volt szó. Vegyük ket sorra: • Checkpoint Manager [CP] A komponens feladata az alkalmazások regisztrációs kulcsainak mentése a quorum lemez MSCS könyvtárába. Ez teszi lehet vé, hogy egy fürtre fel nem készített alkalmazás átköltözés esetén újra tudjon indulni. A CP ellen rzi a regisztrációs kulcsokat az er forrás indulásakor és ellen rz pontot (checkpont) ír a quorumba, amikor az er forrás leáll. A fürtre felkészített alkalmazások a konfigurációs adatbázist, a fürtre fel nem készítettek pedig a helyi szerver regisztrációs adatbázisát használják a helyreállításhoz szükséges információk tárolására. Ezt az információt „vezeti át” a quorumba a CP, ezért csak a fürtre fel nem készített

alkalmazásoknál van rá szükség. • Log Manager [LM] A chekpoint managerrel együtt azt biztosítja, hogy a quorum-er forrás a legfrissebb, helyreállításhoz szükséges adatokat tartalmazza. Nem szabad összekeverni az esemény-feldolgozó [EP] szállal (Lásd kés bb) • Communications Manager [CIMsg] A fürtállomások közötti kommunikációért felel s programkód. Az RPC-t használó komponens biztosítja, hogy minden fürtön belüli üzenet eljusson a többi állomásra, méghozzá pontosan egy alkalommal. Ha egy üzenet egy olyan állomásról érkezik, amely a konfigurációs adatbázis szerint már nem tagja a fürtnek, a szolgáltatás az üzenetet eldobja. • Configuration Database Manager [DM] Ez a fürtkonfigurációt, vagyis egy speciális adatbázist kezel szál. Ez az adatbázis tárolja a fürt fizikai és logikai entitásait. Ilyen entitás maga a fürt, a fürttagság, az er forráscsoportok és er források (például IP-címek vagy fizikai lemezek).

Az állandó és ideiglenes adatok, amelyek az adatbázisban találhatók, arra szolgálnak, hogy érzékelni lehessen a fürt állapotát és állapotváltozásait. Minden állomás DM-e Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár • • • • • • együttm ködik más állomások hasonló komponenseivel, hogy a konfigurációs információk megegyezzenek valamennyi node-on. A DM ezen kívül még egy registryhez hasonló felületet is nyújt a többi clusterkomponens számára Ezen a felületen érkeznek be a változtatási kérelmek az adatbázisba. Global Update Manager [GUM] Ezt a komponenst a Configuration Database Manager használja arra, hogy minden konfigurációs változás valamennyi állomáson érvényre jusson. A GUM biztosítja, hogy a változásokról minden állomás értesül. Ha valamelyik állomás nem végzi el a frissítéseket, „el kell

hagynia” a fürtöt, mert az különben nem tudna konzisztens állapotba kerülni. A leggyakrabban úgy találkozunk majd a GUM bejegyzéssel, hogy a DM utasítására egy meghatározott lépésekb l álló tranzakciót végez a quorumon. Lefoglalja az adatbázist, elvégzi a módosítást, majd feloldja a foglalást. Event Processor [EP] Ez a részegység fogadja az eseményeket a fürter forrásoktól. Egyfajta elektronikus kapcsolótábla, amely a fürtszolgáltatás és a fürtözött alkalmazások között küldözgeti az eseményeket. Az eseményeket minden olyan komponens megkapja, amelyik támogatja a fürt API eseményfogadás mechanizmusát. Event Log Manager [ELM] A fürtszolgáltatás e szál segítségével másolja oda-vissza az eseménynapló bejegyzéseit az állomások között. Itt nem a clusterlog-ról, hanem a Windows 2000 saját eseménynaplójáról van szó Ez jelent sen megkönnyíti a hibakeresést, mert akkor is láthatjuk a másik állomás eseményeit

(vagy legalább egy részüket), ha a node egyáltalán nem elérhet . Failover Manager [FM] A részegység feladata az er források kezelése, valamint különböz tevékenységek indítása, például egy csoport átköltöztetése vagy újraindítása. A függ ségek kezelése is itt történik Az FM folyamatosan állapotinformációkat kap az er forrás-ellen rökt l és az állomásoktól. Ez a komponens dönti el, hogy melyik er forráscsoportot melyik állomás birtokolja. Amikor az er forráscsoportok kezdeti leosztása (arbitration) megtörtént, az egyes állomások „birtokba veszik” az er forrásokat. Ha egy er forrás meghibásodik egy csoporton belül, és a szabályok szerint a meghibásodást egy állomás nem tudja lekezelni, az FM menedzserek mindkét állomáson együttesen újraosztják az er forráscsoportokat. Membership Manager [MM] [RGP] Ellen rzi a fürttagokat, és figyeli, hogy más állomások megfelel en m ködnek-e. Leginkább a node-ok indulásakor,

leállásakor vagy rendellenes „elt nésekor” találkozhatunk vele. Node Manager [NM] Mindegyik állomáson fut, és helyi listát vezet arról, hogy mely állomások tartoznak a fürthöz. A Node Manager rendszeres id közönként szívhang-üzenetet küld a másik állomásnak, hogy adott esetben felfedezze annak meghibásodását. Alapvet , hogy minden állomás egy fürtön belül azonos módon lássa a fürttagságra vonatkozó információkat. Ha egy állomás kommunikációs hibát észlel egy másik állomással, szórt üzenetet küld minden fürttagnak, hogy ellen rizzék a fürttagsági információikat. (A folyamatnak két állomás esetén nincs sok értelme, de három vagy négy állomásnál már fontos lehet.) Ezt az ellen rzést újracsoportosításnak (regroup event) hívják A fürtszolgáltatás mindaddig tiltja a közös lemezekre való írást, amíg a tagság nem tisztázódik. Ha egy Node Manager egy állomáson nem válaszol, a többiek eltávolítják a

fürttagságát, és az aktív er forráscsoportjait átmozgatják a megfelel állomásokra attól függ en, hogy melyek a csoport preferált és lehetséges állomásai. Két állomás esetén ez megint egyszer , háromilletve négy node-nál viszont eléggé bonyolult er forráscsoport-elosztás is lehetséges • Object Manager [OM] Ahogy a neve is mutatja, ez a szál a fürt objektumait kezeli, különböz (bels ) objektumok létrehozását, keresését, kiértékelését végzi el. Még egyszer tehát: a fenti objektumok mind a fürtszolgáltatás részei. A nevek mellett feltüntettem azokat a rövidítéseket is, ahogyan az egyes komponensekre a cluster.log hivatkozni fog Az els ábrát tovább szemlélve láthatjuk, hogy a Failover Manageren keresztül tartja egymással a kapcsolatot a cluster.exe és az er forrás-ellen r, amely a második épít kocka a fürtünkben. Az er forrás ellen r (Resource Monitor) [RM] Ez a komponens egy különálló processz, amely egységes

felületet nyújt a fürtszolgáltatás és az er források összekapcsolásához. A clusterszolgáltatás valójában az er forráskönyvtárakkal (DLL-ekkel) kommunikál Az er forrásellen r tehát egyfajta pajzs is, amely megvédi a fürtszolgáltatást egy hibásan m köd er forrástól Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár A fürtszolgáltatást több réteggel elválasztották a tényleges er forrásoktól Az ellen r több példányban is futhat. Ez azért fontos, mert ha van egy bizonytalanul m köd er forrás, az elszigetelhet a többit l egy saját er forrás-ellen rrel. Saját ellen rt úgy rendelhetünk az er forráshoz, ha a létrehozásakor vagy a tulajdonságai lapján bejelöljük a „Run the resource in a separate Resource Monitor” választónégyzetet. Az ellen r a fürtszolgáltatással a kapcsolatot RPC hívásokon keresztül tartja. Az er

forráskönyvtárak (Resource DLL) A fürtöt alkotó harmadik épít elem-csoport az er forráskönyvtáraké. A Windows 2000 Advanced Server önmagában is számos ilyen könyvtárral rendelkezik a különböz típusú er forrásokhoz, ezek köre az alkalmazások telepítésével kib vül. Ha egy alkalmazásnak van saját er forráskönyvtára, továbbá a fürtszolgáltatással a fürt API-n keresztül kommunikál, azt mondhatjuk, hogy az egy fürtre felkészített (cluster-aware) alkalmazás. A saját er forráskönyvtárral nem rendelkez alkalmazásokat a fürt ún. általános alkalmazásokként (generic application) vagy általános szolgáltatásokként (generic service) kezeli. Az ehhez tartozó könyvtárállomány (clusresdll) a fürt beépített er forrásállománya. A fürtre felkészített er forrásokat természetesen jobban kezeli a cluster. Egy ilyen alkalmazás például: • képes leírni a saját állapotát az er forrás-ellen r kérésére, • teljesen

szabályosan, az adatintegritásra ügyelve képes leállni és újraindulni, valamint • precízebben válaszol a „valóban él” (IsAlive) és az „úgy t nik él” (LooksAlive) vizsgálatokra. Egy er forráskönyvtár több er forrástípushoz is tartozhat. Ha egy ilyen DLL megsérül, mindazon er források nem indulnak majd, amelyek használják a könyvtár függvényeit, és persze a velük függ ségi viszonyban lév k sem. Az els ábrát majdnem teljes egészében értelmeztük. Csupán egyetlen kapcsolatot, a fürtre felkészített alkalmazások és a cluster API közötti összefüggést kell tisztázni. Ez a kapcsolat úgy jön létre, hogy a fürtre kész alkalmazások a fürtadminisztrátort kiegészít állományokkal látják el – ezzel lehet vé téve, hogy az er forrás egyedi paramétereit a kezel felületen keresztül állíthassuk. Amikor egy Exchange 2000 er forrás egyedi paramétereinek „fülére” kattintunk, tulajdonképpen ezeket a kiegészít

állományokat használjuk. Az állomások együttm ködése Egy állomás nem állomás. Nézzük meg, hogyan dolgozik együtt két Windows 2000 Server A fürtszolgáltatás egyik nagy problémája, hogy pontos információval kell rendelkeznie azokról a más állomásokon található fürtszolgáltatásokról, amelyek társak lehetnek az er források üzemeltetésében. Ha bármilyen állapotváltozás történik, egy megfelel mechanizmusnak gondoskodnia kell arról, hogy a teljes fürt érzékelje az állapotváltozást. A Windows 2000 Server ehhez több példányban és több helyen adatbázisokat tárol, frissít és szinkronizál. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár A fürtszolgáltatás telepítésekor egy közös lemezen, a quorumon létrejön egy quorum.log nev állomány Szerkezetét tekintve ez regisztrációs adatbázis ág (registry hive) – elegend , ha mi

most „adatbázis”-ként definiáljuk. Ezek az adatok azonban nemcsak itt érhet k el. Mindegyik állomás tartalmaz egy-egy saját példányt is a C:WINNTcluster mappában clusdb néven. A szolgáltatás indulásakor ez a fájl kerül el ször a memóriába, ebb l lesz a cluster ág a regisztrációs adatbázisban. Két állomás esetén összesen öt példányban létezik az a „tudás”, amit a node-oknak birtokolniuk kell. Ezek az adatbázis-példányok nem tökéletesen egyformák (nem konzisztensek), de ha mindkét állomáson szabályosan leállítanánk a clusterszolgáltatást, a lemezeken tárolt példányok azonos állapotba kerülnének. (Ha tehát a quorumlog megsérül, nem nehéz kitalálni, honnan pótolhatjuk.) A sok adatbázispéldány ugyanakkor megnehezíti a változások átvezetését. A kés bbi logelemezésnél láthatjuk majd, hogy a legtöbbet a Global Update Manager (GUM), a Database Manager (DM) és a Failover Manager (FM) kezdeményez frissítési m

veletet. Az alábbi ábra ezeket a komponenseket mutatja Természetesen a többi bels komponens is ide tartozik, de azok megjelenítése zavarólag hatott volna. Ezt a képet fejben tartva jobban megérthet a fürtök bels m ködése. Két állomás együttm ködése A m ködési folyamat leegyszer sítve a következ : Az FM az er forrás-ellen r segítségével folyamatosan figyeli a rábízott er források állapotát. Ha bármilyen okból állapotváltozás történik, a GUM komponens segítségével értesíti a „túloldali” FM-et, és frissíti a memóriában található adatbázispéldányt. A DM szintén a GUM segítségét veszi igénybe, amikor a helyi adatbázist (clusdb), vagy a közös adatbázist (quorum.log) írja A GUM egyik legfontosabb feladata a különböz adatbázispéldányok zárolása az írási m veletek számára. A cluster.log alapjai Az alapvet tudást megszereztük a fürt saját eseménynaplójának értelmezéséhez. Most nézzük meg, hogyan néz ki

egy bejegyzés az állományban. 00000dd8.00000c6c::2002/06/23-11:37:56089 [CS] Cluster Service started - Cluster Node Version 32195 00000dd8.00000c6c::2002/06/23-11:37:56089 OS Version 5.02195 - Service Pack 2 (AS) A naplóbejegyzés mindig annak a processznek és szálnak az azonosításával kezd dik, amely a bejegyzést végezte. A két azonosítót egy pont (.) választja el egymástól A mi esetünkben a processz ID dd8, míg a szálazonosító c6c Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár Ezután következik az id pont bejegyzése, méghozzá minden id zónában a greenwichi id szerint. Ez nálunk két óra id eltolódást jelent, els re ijeszt , hogy „rosszul jár” a cluster.log órája Az id bélyeg formátuma éééé/hh/nn-óó:pp:mp:emp, vagyis ezredmásodpercre pontos bejegyzés készül. Végezetül jön az esemény leírása – itt épp elindul a

fürtszolgáltatás A cluster.log-ban tulajdonképpen kétféle bejegyzés található: a fürtszolgáltatás komponenseit l és az er forráskönyvtáraktól származó. Ha egy komponens rögzít egy eseményt, egyúttal elhelyezi a saját rövidítését is – ezeket tüntettem fel a szögletes zárójelek között a nevek után. A felsoroltakon kívül azonban még van néhány rövidítés, amellyel meg kell ismerkednünk: • API – A fürt API felületet nyújtó komponenst l érkez bejegyzések rövidítése. • CINet – A fürt hálózati motorja. • CS – A fürtszolgáltatás. A bejegyzés egy része nem a komponensekhez köt dik, ekkor kapja az általános CS jelzést A fenti bejegyzés jó példa, a fürtszolgáltatás indulásakor keletkezett. • INIT – Ez nem egy komponens, hanem egy státusz jelzése. Akkor kapja ezt egy bejegyzés, ha clusterszolgáltatás még nem csatlakozott egy másikhoz, vagy önmaga nem alakított ki saját fürtöt. • JOIN – Az INIT

állapot utáni státusz. Ha a kapcsolódás sikeres, az állomás fürttag lesz • EVT – Nem dokumentált a pontos jelentése, az „esemény” szó rövidítése. • CPROXY – A rövidítés annyit tesz: cluster proxy, vagyis fürthelyettesít . Egy nagyon kicsi alkalmazásról van szó, amely a Windows NT 4.0 egyik fogyatékosságát, a szervizellen r (Service Control Manager) hiányát segít orvosolni A fürt indításakor technikai értelemben a CPROXY-t indítjuk el, amely rögtön betölti a valódi fürtszolgáltatást. Emellett érzékeli, ha a valódi cluster összeomlik, és megpróbálja újraindítani. A Windows 2000-ben a CPROXY trükkre már nincs szükség, a fejleszt k azonban nem végeztek teljes átalakítást a fürtszolgáltatás szerkezetében, ezért a módszer maradt. A következ verziókban vélhet en már nem találkozunk vele. A rövidítésekhez további két apróságot kell ismerni. A Membership Manager [MM] néha [RGP] néven is megjelenik –

ezért mindkét rövidítést szerepeltettem a leírásánál. Az INIT és a JOIN rövidítésekr l azt kell tudni, hogy hozzákapcsolódhat más rövidítésekhez is, egyszerre jelezve egy komponenst és egy állapotot. Például NMJOIN A komponensek bejegyzései mellett az er forráskönyvtárak írnak az eseménynaplóba. Egy lemezer forrás-bejegyzés például így néz ki: 15c.458::1999/06/09-18:00:47897 Physical Disk <Disk D:>: [DISKARB] Arbitration Parameters (1 9999) Az alapvet különbség a két bejegyzés között az, hogy az er forráskönyvtárak nem helyeznek el rövidítéseket, legalábbis nem az id bélyeg után. A napló olvasásánál ezért jól el lehet különíteni, hogy honnan származik az esemény A cluster.log olvasása nem azért nehéz, mert bonyolult a szintaxisa Igaz, talán lehetne egy kissé dokumentáltabb az eszköz – némi gyakorlás után azonban ez nem jelent gondot. A probléma abból fakad, hogy a bejegyzések száma óriási Egy

csoport átköltöztetése csupán hat másodpercig tart, a fürt ezalatt 3500 (!!) eseményt talál méltónak arra, hogy a saját naplójába bejegyezzen. És ez csak az érem (vagyis a fürt) egyik oldala, mert az eseményekr l a másik állomás is értesül, és azokat aztán is szorgosan jegyzeteli. Azt gondolom, hogy az elemzés elkezdését a következ alkalomra hagyjuk. Lesz b ven tenni- és megértenivalónk Lepenye Tamás, MCSE 2000 lepenyet@mal.hu Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 6 NetAcademia-tudástár Farkasokkal táncoló XI. – Cluster a gyakorlatban A fürtszolgáltatással ismerked k számára kezdetben nagyon kellemes, hogy a fürt „mindent elintéz”. F leg, ha esetleg a rendszert készen kaptuk, vagyis a szolgáltatások már m ködtek, amikor az eszköz a kezünkben került. Aztán jön az els saját telepítés, az els er forráshiba, és a rendszergazdának meg

kell tanulnia alámerülni a fürtszolgáltatás mélységeibe. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár Ezt a mélységet a cluster.log jelenti Érteni a naplót annyit tesz, tudni, mi történik a háttérben A háttér pedig feltárja a hibákat, amelyeket kergetünk hét határon át. Ez alkalommal a fürt bels eseménynaplóját elemezzük példákon, helyzeteken keresztül. Munkamódszer A cluster.log elemzésekor konkrét szituációkon keresztül vizsgáljuk meg, hogy mi kerül a naplókba Terjedelmi okokból nem tudjuk elemezni a bejegyzéseket sorról sorra, ezért a már megismert, ismétl d , és könnyen értelmezhet eseményeket az írás közben csak említem, de nem idézem. A cikk végén található hivatkozásokról letölthet k a teljes naplók, hogy akik szeretnék még alaposabban boncolgatni a helyzet szülte bejegyzéseket, azok megtehessék. (Bevallom,

e nélkül eléggé bonyodalmas olvasmány lesz a cikk.) A fürt mindkét állomásának naplóit érdemes végigböngészni, így láthatóvá válik, miként érzékeli ugyanazt az eseményt az egyik, illetve a másik node. A felesleges információk elkerülése érdekében kihagyom a naplóbejegyzések elején található processz- és szálazonosítókat, valamint az id bélyeget is, hacsak nincs különös jelent ségük. A naplók letölthet változatában ezek természetesen jelen vannak Végezetül feltételezem, hogy az el z hónapban tisztázott fogalmakat az Olvasó elsajátította. Kezdjük az elemzést azzal, amivel a fürt is kezdi: a szolgáltatás indulásával. Egy állomás indulása A napló egy olyan helyzetben készült, amikor a két állomásból álló fürt els kiszolgálója indult el, a másik még áll. A teljes napló az [1] címr l tölthet le. Az els két sort már ismerjük, a naplóbejegyzés a fürtszolgáltatás indulását jelzi. Ezután az

esemény-feldolgozó komponens [EP] indul, hogy rögtön elkezdhesse a bejegyzések rögzítését. [EP] Initialization. [DM]: Initialization Az esemény-feldolgozót az adatbáziskezel szál követi. fürtszolgáltatásnak, a naplóból láthatjuk, hogy ezt meg is teszi. Tulajdonképpen minden szálat inicializálnia kell a [DM]: Loading cluster database from C:WINNTclusterCLUSDB [DM] DmpStartFlusher: Entry [DM] DmpStartFlusher: thread created Az adatbáziskezel els dolga, hogy beolvassa az adatbázist. Az el z részben már tárgyaltuk a szolgáltatás indulását, és tudjuk, hogy a fürt ebben az állapotban még nem tudja, hol van a Quorum er forrás, így a %systemroot%cluster mappában található clusdb állományt olvassa be, amely a quorumer forráson található adatbázis egy másolata. Nem biztos, hogy tökéletes másolat, arra azonban elegend , hogy a szolgáltatás információkat szerezzen a quorum hollétér l és az er forrásokról. (Igazság szerint még

ezek az információk is elavultak, de létezik egy mechanizmus, amely az ilyen komplikációkat kiküszöböli.) A többszálúság el nyeit kihasználva azonnal indul a többi szál is, nem várva meg más szálak munkájának befejezését. El bb a node manager, aztán a failover manager, az API és a log manager komponensek inicializálódnak. A node manager azonnal munkához lát, és a beolvasott adatbázisból azonosítja az állomást és annak számát. [NM] Local node name = MALSERVER3. [NM] Local node ID = 1. [NM] Creating object for node 1 (MALSERVER3) Egy külön komponenshez nem köthet szál megállapítja, hogy milyen fiókkal indult a szolgáltatást, majd az adatbázisból kiolvasott fürtnevet felhasználva megpróbál csatlakozni a másik állomáshoz. A szolgáltatás azt feltételezi, hogy a másik állomás – és így a fürt maga – m ködik. [CS] Service Domain Account = MALclustuser [CS] Initializing RPC server. [INIT] Attempting to join cluster

MAL-CORPSERV3 A napló elemzése közben többször is felt nik majd, hogy a szoftver minden része „ideges” és „siet”, vagyis a feladatát minden lehetséges módon és minél el bb szeretné elvégezni. A következ sorokból látszik, hogy a másik állomáshoz való csatlakozást a fürtszolgáltatás a létez összes hálózati csatoló nevével és IP címével megpróbálja. [INIT] [JOIN] [JOIN] [JOIN] [JOIN] Attempting to join cluster MAL-CORPSERV3 Spawning thread to connect to sponsor 192.1681121 Asking 192.1681121 to sponsor us Spawning thread to connect to sponsor 10.0021 Spawning thread to connect to sponsor MALSERVER4 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár [JOIN] Asking 10.0021 to sponsor us [JOIN] Asking MALSERVER4 to sponsor us. Érdemes megfigyelni a rendszer állapotváltozásait. El bb INIT állapotba kerül a szolgáltatás, amit a JOIN követ Ez

utóbbi mindaddig fennáll, amíg a csatlakozási folyamat sikeresen vagy sikertelenül be nem fejez dik. A leírt szituációból tudjuk, hogy ezúttal a csatlakozás nem sikerülhet, a következ bejegyzés tehát nem váratlan: 2002/07/19-19:38:35.654 [JOIN] Sponsor 100021 is not available (JoinVersion), status=1753 A sikertelenség oka a státuskódban rejlik. A korábban ismertetett módszerrel pontosabb információhoz juthatunk C:>net helpmsg 1753 There are no more endpoints available from the endpoint mapper. Ez az utasítás még sokszor a segítségünkre lesz, tartsuk szárazon a parancssorunkat. A próbálkozás egy id után abbamarad. Figyeljük meg, hogy az utolsó próba épp harminc másodpercig tart 19:38:36.654 19:39:08.669 19:39:08.669 19:39:08.669 19:39:08.669 19:39:08.669 19:39:08.669 [JOIN] [JOIN] [JOIN] [JOIN] [JOIN] [INIT] [INIT] Waiting for all connect threads to terminate. Sponsor 10.0026 is not available (JoinVersion), status=1722 JoinVersion data for

sponsor 10.0026 is invalid, status 1722 All connect threads have terminated. Unable to connect to any sponsor node. Failed to join cluster, status 53 Attempting to form cluster MAL-CORPSERV3 Az 53-as kód azt jelzi, hogy a hálózaton keresztül a másik állomás nem elérhet . A szolgáltatás visszakerül INIT állapotba, és megpróbál egyedül fürtszolgáltatást kialakítani. Vessünk egy pillantást az id pontra: 19:39:08669! A napló végén láthatjuk majd, hogy az üzemszer m ködés eléréséhez csupán 12 másodpercre lesz szükség. Az állomás a korábban beolvasott adatbázis alapján felépíti a fürtöt, megkeresi a quorum logot, és a chekpointállományokat, azok segítségével pedig helyreállítja a fürt legutolsó állapotát. Ezt a folyamatot követjük végig A fürt kialakítása a helyi adatbázissal Az els lépés, amelyet meg kell tennie a clusternek, az er forrás-ellen r (resrcmon.exe) indítása Az el z cikkb l tudjuk, hogy a fürtszolgáltatás

az ellen r segítségével tartja a kapcsolatot az er forrásokkal. Mivel a végs feladat az er források elindítása, a m veletet meg kell el znie az ellen r üzembehelyezésének. A helyi adatbázis – ahogy az már korábban kiderült – nem más, mint egy ág a regisztrációs adatbázisban. A következ bejegyzések ezt jól mutatják. A failover manager [FM] sorra az er forrásokat reprezentáló regisztrációs értékeket olvas be, majd inicializálja azokat. 19:39:08.669 [API] Online read only [RM] Main: Initializing. [FM] Creating group 9b26a6cb-a791-4807-9c17-bfc83050cd13 [FM] Initializing group 9b26a6cb-a791-4807-9c17-bfc83050cd13 from the registry. [FM] Name for Group 9b26a6cb-a791-4807-9c17-bfc83050cd13 is MAL-CORPSERV3. [FM] Group 9b26a6cb-a791-4807-9c17-bfc83050cd13 preferred owner 1. [FM] Group 9b26a6cb-a791-4807-9c17-bfc83050cd13 contains Resource 54235f9f-3789-442a-98f1-e22bd2f73b66. [FM] Creating resource 54235f9f-3789-442a-98f1-e22bd2f73b66 [FM] Initializing

resource 54235f9f-3789-442a-98f1-e22bd2f73b66 from the registry. [FM] Name for Resource 54235f9f-3789-442a-98f1-e22bd2f73b66 is Cluster IP Address. [FM] FmpAddPossibleEntry: adding node 1 as possible host for resource 54235f9f-3789-442a-98f1-e22bd2f73b66. [FM] FmpQueryResTypeInfo: Calling FmpAddPossibleNodeToList for restype IP Address [FM] FmpAddPossibleNodeToList: adding node 1 to resource types possible node list [FM] FmpAddPossibleNodeToList: Warning, node 2 not found [FM] All dependencies for resource 54235f9f-3789-442a-98f1-e22bd2f73b66 created. A koreográfia felismerhet : 1. Az FM létrehozza a memóriában az er forráscsoportot 2. Beolvassa a csoporthoz tartozó regisztrációs értékeket 3. Megállapítja az er forráscsoport nevét 4. Meghatározza, hogy a csoportot melyik állomás fogadhatja 5. Megvizsgálja, hogy a csoport milyen er forrásokat tartalmaz, és sorra veszi azokat is a. Létrehozza az er forrást a memóriában b. Beolvassa a regisztrációs értékeket

c. Megállapítja az er forrás nevét d. Meghatározza a lehetséges állomásokat, amelyek birtokolhatják az er forrást e. Meghatározza az er forrás függ ségeit Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár f. Megnyit minden er forrást, amelyt l az aktuális er forrás függ, vagy ellen rzi, hogy már megnyitotta-e azokat. A látottak alapján néhány fontos felismerést tehetünk. A fürt minden egyes er forrást egy egyedi azonosítóval jelöl, egy meglehet sen „ronda” jelsorral, mint például 9b26a6cb-a791-4807-9c17-bfc83050cd13. Ezt a jelet GUID-nak hívják, ami a „globális, egyedi azonosító kód” angol rövidítése. A GUID-ok meglehet sen nehézkessé teszik a napló olvasását, mivel hosszúak és nehezen azonosíthatók. Segítségünkre lehet, ha a regedit (regedt32) program segítségével el re feljegyezzük az er források nevét és

azonosítóját. Ha a fürtnapló másolatával dolgozunk, érdemes írni egy rövid scriptet, amely sorra kicseréli a GUID-okat az er források neveivel. A regedit.exe segíthet az er források azonosításában Az er források beolvasása mindaddig tart, amíg az FM meg nem találja a quorumot. 19:39:08.778 [FMX] Found the quorum resource f21ba2a4-62dd-4883-bf69-aa6c69f96320 Az FMX a failover manager tranzakciós részét jelöli. Miután az er forrás-kiértékelés befejez dött, az FM megkezdi a quorum „birtokba vételét”. Az er forrásellen r felveszi a quorumot a felügyelt er források listájába. Az FmpRm pontos feloldására nem találtam hiteles információt, de könny azt feltételezni, hogy a „Failover Manager process Resource Monitor” helyett használja a fürt. 19:39:08.778 [FM] FmpRmCreateResource: creating resource f21ba2a4-62dd-4883-bf69-aa6c69f96320 in shared resource monitor 19:39:08.857 Physical Disk: PnP window created successfully [FM]

FmpRmCreateResource: created resource f21ba2a4-62dd-4883-bf69-aa6c69f96320, resid 651760 [MM] MmSetQuorumOwner(1,1), old owner 0. A következ bejegyzés azért fontos, mert ez az els , amely nem a fürtkomponenst l, hanem az er forrás-ellen rt l származik: a Windows 2000 felkészül egy lemez fogadására. A sorban olvasható resid tulajdonképpen egy mutató az er forrás-ellen r processzben. Az RM-en kívüli világban a resid nem más, mint hivatkozás egy konkrét er forrásobjektumra. Végezetül a membership manager beállítja, hogy a quorumnak melyik állomás lesz a tulajdonosa. Persze ezt egyel re még csak a memóriában található adatbázisváltozatban teheti meg, hiszen a quorumhoz még nem nyúlt hozzá a fürt. A következ sorok egy tesztr l tudósítanak, amelyet az RM végez el, és célja a lemez írhatóságának és olvashatóságának ellen rzése. A teszt sikere után az ellen r kiadja a lefoglalási (reserve) parancsot, az FM pedig bejegyzi, hogy sikeresen

megszerezte az er forrást. Physical Disk <Disk Q:>: [DiskArb]Arbitrate returned status 0. Physical Disk <Disk Q:>: [DiskArb] * IO PENDING . [FM] FmGetQuorumResource successful Az ellen r újabb sorai tanúsítják, hogy a lemezt sikerült m köd (online) állapotba állítani. Figyelem! Ez még csak a lemezre vonatkozik, nem a lemezt reprezentáló er forrásra. A különbség mindjárt kiderül A most következ pár sorral gyakran lehet találkozni a cluster.log elemzése közben A m velet azt jelzi, hogy a Global Updated Manager (GUM) változtat a fürtadatbázis tartalmán. Az els ilyen tranzakció a naplóban így néz ki: [GUM] GumSendUpdate: Locker waiting type 0 context 8 [GUM] Thread 0x7e8 UpdateLock wait on Type 0 [GUM] DoLockingUpdate successful, lock granted to 1 [GUM] GumSendUpdate: Locker dispatching seq 35714364 type 0 context 8 [GUM] GumpDoUnlockingUpdate releasing lock ownership Physical Disk <Disk Q:>: [DiskArb] DisksOpenResourceFileHandle: Attach

successful. [GUM] GumSendUpdate: completed update seq 35714364 type 0 context 8 [FM] FmpPropagateResourceState: resource f21ba2a4-62dd-4883-bf69-aa6c69f96320 pending event. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár [FM] FmpRmOnlineResource: Resource f21ba2a4-62dd-4883-bf69-aa6c69f96320 pending Physical Disk <Disk Q:>: [DiskArb] DisksOpenResourceFileHandle: CreateFile successful. [FM] FmpRmOnlineResource: Returning. Resource f21ba2a4-62dd-4883-bf69-aa6c69f96320, state 129, status 997 A sikeres értelmezéshez ismerni kell a GUM frissítési m veleteinek három típusát, valamint a kontextus kódok jelentését. A táblázat a frissítési típusokat azonosítja. GUM type0 GumUpdateFailoverManager GUM type1 GUM type2 GumUpdateRegistry GumUpdateMembership A kontextusszám értéke a frissítés típusától függ. Esetünkben a 8 er forrásállapot-változást

(ResourceState) jelent A [2] helyr l letölthet egy táblázat, amely a típusokat, a kontextus-számok jelentését és a kés bb tárgyalandó állapotkódokat is tartalmazza. A fürtszolgáltatásban kialakítottak egy mechanizmust, amely megakadályozza, hogy egy id ben több szál végezzen módosítást az adatbázis adatain. A GUM kiad egy zárolási kérelmet, hogy a változtatást elvégezhesse, (GumSendUpdate: Locker waiting) megadva azt is, hogy milyen típusú adatmódosítás várható (type 0 context 8). Azt az állomást, amely a módosítást végzi, zárolónak (locker) nevezik. A sikeres zárolásról bejegyzés készül (DoLockingUpdate successful, lock granted to 1). Ezt követ en végzi el a GUM a tényleges írást, amelyet egy folyton növekv tranzakciós számmal jelöl meg (GumSendUpdate: Locker dispatching seq 35714364 type 0 context 8), végül feloldja a zárolást ([GUM] GumpDoUnlockingUpdate releasing lock ownership). Az FM értesíti a többi állomást

az állapotváltozásról (jelen esetben ennek nincs értelme, hiszen nincs másik állomás). A többi bejegyzés érthet , egyedül a „state 129, status 997” kódokat kell feloldani, amit szintén az el bbi excel táblázattal tehetünk meg. A 129 annyit tesz ClusterResourceOnlinePending, vagyis az er forrás épp indul, a státus pedig a net helpmsg parancs segítségével lesz érthet : „Overlapped I/O operation is in progress”. Most már érthet , hogy mi a különbség a tényleges er forrás és a hozzá tartozó bejegyzés között Miközben az ellen r szerint a lemez már m ködik, addig a fürtadminisztrátor programban az er forrás még csak indul! A következ lépés a partícióhoz tartozó jelölés (Q:) egységességének ellen rzése: Physical Physical Physical Physical Physical Physical Physical Physical Disk Disk Disk Disk Disk Disk Disk Disk <Disk <Disk <Disk <Disk <Disk <Disk <Disk <Disk Q:>: Q:>: Q:>: Q:>: Q:>:

Q:>: Q:>: Q:>: Mountie[0]: 1, let=?, start=7E00, len=1EE28000. Online MountieVerify: Registry-SystemDISK.GetInfo returned 0 [0:0] MountieVerify: ClusReg-DiskInfo selected. MountieVerify: DriveLetters mask is now 00010000. MountieVerify: Update needed for 08. FtInfo Set: Update successful. MountieUpdate: Update needed for 00. A hatodik sor jelzi, hogy a HKLMSYSTEMDisk bejegyzés nem friss. („Update needed for 08” Sajnos, az esetleges további kódszámokról nincs információ. Itt valószín leg arról van szó, hogy a lemez becsatolása után a regisztrációs adatbázist a Windows 2000 még nem frissítette.) A változtatást az er forrás-ellen r elvégzi, hogy aztán már azt írhassa ki „Update needed for 00”. Újabb lemezellen rzéseket végez az ellen r, végül jelenti a fürtszolgáltatásnak, hogy az er forrás állapota „m köd ”-re (online) állítható. [RM] RmpSetResourceStatus, Posting state 2 notification for resource <Disk Q:> Egy újabb

érdekességre figyelhetünk fel. Ahelyett, hogy a GUM módosítaná az er forrás állapotát „indul”-ról „m köd ”-re, valami más kezd dik. A fürtadminisztrátorban még nem történt állapotváltozás A helyi adatbázis feladata lassan véget ér Mindent el készített a fürt a valódi quorum beolvasására. Ez az a hiányzó m velet, ami a GUM munkáját késlelteti A valódi quorum betöltése [FM] [FM] [FM] [FM] [DM] [DM] [DM] [LM] [LM] [LM] [LM] [LM] [LM] NotifyCallBackRoutine: enqueuing event FmpCreateResStateChangeHandler: Entry FmpCreateResStateChangeHandler: Exit, status 0 FmpHandleResStateChangeProc: Entry. DmpQuoObjNotifyCb: Quorum resource is online DmpQuoObjNotifyCb: Own quorum resource, try open the quorum log DmpQuoObjNotifyCb: the name of the quorum file is Q:MSCSquolog.log LogCreate : Entry FileName=Q:MSCSquolog.log MaxFileSize=0x00010000 LogpCreate : Entry LogpMountLog : Entry pLog=0x00098498 LogpMountLog::Quorumlog File size=0x00008000

LogpMountLog::reading 1024 bytes at offset 0x00000400 LogpMountLog::checking LSN 0x00000408 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár A quorumot a DM és az LM együttes munkával nyitja meg. Sajnos, a naplónak ez a szakasza nem pontosan dokumentált, a folyamat csak hozzávet legesen követhet . Nem ismert az „Entry pLog=0x00098498” jelentése, sem az, hogy miért épp 1024 bájtonként történik a beolvasás, mit rejt az LSN rövidítés (logical sequence number?). Az alábbi pár sor is teljes rejtély: [LM] AddTimerActivity:: hTimer = 0x000003b8 pfnTimerCb=0x0107fb50 dwInterval(in msec)=120000 [LM] AddTimerActivity:: Interval(high)=0xffffffff Interval(low)=0xb8797400 [LM] AddTimerActivity:: returns 0x00000000 Mindeközben egyéb – szintén nem ismert folyamatok is zajlanak. A 0x768 szál a sorok közt elszórva a következ bejegyzéseket írta: 00000768: 00000768:

00000768: 00000768: [LM] [LM] [LM] [LM] :ReSyncTimerHandles :ReSyncTimerHandles :ReSyncTimerHandles :ReSyncTimerHandles Entry. Exit gdwNumHandles=2 Entry. Exit gdwNumHandles=3 A gdwNumHandles egy változó, akárcsak a gdwQuoBlockingResources, de a szerepe, ellentétben az utóbbival, egyel re nem dokumentált. A sok ismeretlen jelentés sor között van néhány, amely fontos a számunkra: [FM] HandleResourceTransition: Resource Name = f21ba2a4-62dd-4883-bf69-aa6c69f96320 old state=129 new state=2 A GUID, az állapot- és a státuskódok megfejtése után látható, hogy a „Disk Q:” er forrás „indul” állapota „m ködik”-re váltott. Ezt egy adatbázis frissítésnek kell követnie, ami pár sorral lejjebb be is következik. Egy másik fontos bejegyzés az alábbi: 0000096c.000007e8::2002/07/19-19:39:09185 [DM] DmpChkQuoTombStone – Entry 0000096c.000007e8::2002/07/19-19:39:09185 [DM] DmpChkQuoTombStone: Exit, returning 0x00000000 Arról értesít minket a napló,

hogy nem talált „quorum sírkövet”. El fordulhatott volna ugyanis, hogy miközben az épp most induló állomás állt, a másik állomás megváltoztatta a quorum helyét. Ekkor a mi állomásunk csak a h lt helyét, vagyis egy „sírk állományt” talált volna. Mivel azonban a sírk nem mutat a quorum új helyére, az állomásunk nem tudta volna betölteni azt. Ebb l az következik, hogy az állomás nem lett volna képes egyedül fürtszolgáltatást nyújtani, csupán csatlakozhatott volna egy másik, már m köd node-hoz. A sírk megléte esetén a szolgáltatásunknak haladéktalanul le kellett volna állnia A bejegyzés szerint azonban ez nem következett be. [DM] DmpApplyChanges: The current registry sequence number 35714363 [LM] LogGetLastChkPoint:: Entry [LM] LogGetLastChkPoint: ChkPt File Q:MSCSchkF432.tmp ChkPtSeq=35714098 ChkPtLsn=0x00000708 Checksum=176054 [LM] LogGetLastChkPoint exit, returning 0x00000000 [DM] DmpLogFindStartLsn: LogGetLastChkPt rets,

Seq#=35714098 ChkPtLsn=0x00000708 [DM] DmpLogFindStartLsn: ChkPt not applied, search for next seq [LM]:LogScan::Entry Lsn=0x00000708 ScanForward=1 CallbackRoutine=0x0106c056 [LM]:LogScan::Calling the scancb for Lsn=0x000010e0 Trid=35714231 RecordSize=216 [LM]:LogScan::Exit - Returning 0x00000000 [DM] DmpLogFindStartLsn: LSN=0x00000000, returning 0x00000000 [DM] DmpApplyChanges: Exit, returning 0x00000000 [FM] FmFormNewClusterPhase1, Entry. Quorum quorum will be deleted A napló szerint az LM megkeresi az utolsó checkpoint állományt, majd egy rutin segítségével ellen rzi, hogy az adott tranzakciók bekerültek-e az adatbázisba. A bejegyzés kicsit csalóka, az állományt ténylegesen nem kell még egyszer alkalmazni, mert különben olyasmit is látnunk kellene, hogy „[DM] DmpLogFindStartLsn: chkpt uploaded from quorum log”. Az utolsó sor arról tájékoztat, hogy egy új fürtszolgáltatás kialakításának els fázisa úgy kezd dik, hogy a quroumot rögtön

töröljük. A magyarázatot azonban már csak a következ számban adjuk meg A cikkben szerepl URL-ek: [1] Eseménynapló http://technet.netacademianet/download/cluster/nodestartlog [2] Excel tábla http://technet.netacademianet/download/cluster/farkasokkal XIxls Lepenye Tamás, MCSE 2000 lepenyet@mal.hu Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 6 NetAcademia-tudástár Ki mivel ♥? Farkasokkal táncoló ráadás Ha elkezdünk valamit, akkor azt tegyük tisztességesen – mindig ezt vallottam. Készüljünk fel a legjobb tudásunk szerint, és csak azután vágjunk bele a dologba. Akik követik a „Farkasokkal táncoló” cikksorozatot, azok tudják, hogy igyekszem alaposan körbejárni egy témát, miel tt valóban cselekednék. Nos, az alábbi történet arról szól, hogy ez nem mindig elég. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet 

2000-2003, NetAcademia Kft 1 NetAcademia-tudástár és legyen biztonság! A vállalatunknál 1997 februárja óta a Windows NT 4.0 a munkaállomások standard operációs rendszere Ismerve a szoftver megjelenési dátumát (1996. november), meglehet sen bátor tett volt a szabvány bevezetése Nem is jutott érvényre rögtön Kompatibilitási okokból még jó ideig találkoztunk Windows 95 rendszerekkel is, és nem kevés hadakozásban vettünk részt, amikor egy-egy szállító a lehet legnagyobb természetességgel hozott Win9x rendszert, és nyafogott, ha ez nekünk nem tetszett. (Nyafogásnak azt nevezem, ha valaki tesztek nélkül esküszik arra, hogy NT4 alatt nem fut valami, ezért Win9x-re van szükség.) Lényeg a lényeg: a Windows NT alap lehet séget ad egy biztonságosabb rendszer kialakítására Tudjuk, mert ennek a magazinnak a hasábjain is b ven olvashattunk róla, a Windows 2000 egy sor újdonságot hozott a biztonság területén. Alapértelmezett

hitelesítési protokollja a Kerberos lett, a tartományokat csoportházirendek és biztonsági sablonok segítségével lehet gyorsan, szabványosan felügyelni. Igaz, a csoportházirendek csak Windows 2000 vagy magasabb verziójú kiszolgálók és ügyfelek esetén jutnak érvényre, de sebaj, ha tisztán W2K hálózatunk van (vagy lesz), kisebb fajta Kánaánba juthatunk, - már ami a felügyelhet séget illeti. Az ISA log Történt aztán, hogy ISA szerverre cseréltük a t zfalunkat, megújítva a korábbi MS Proxy 2.0-át Az ISA egyik új szolgáltatása a jelentések készítése. Kissé korlátozottak a képességei az alapterméknek, mégis el relépés a Proxyhoz képest Az ISA telepítése után egy-két nappal nézegettem a kimutatásokat, és a használt operációs rendszerek megoszlásakor csodálkozva fedeztem fel, hogy bizony Win9x rendszerek is vígan töltögetik le a maguk kis weblapjait. Ez nekem nem tetszett. Öt évvel egy szabvány bevezetése után még

létezik olyan eldugott sarka a hálózatunknak, ahol Windows 95 garázdálkodik? Vagy kalózgépek kerültek a céghez? Nem hagytam annyiban a dolgot, és úgy határoztam, hogy lehetetlenné teszem a Win9x rendszerek életét a vállalatnál. Hogyan lehetséges ez? Nem is olyan nehéz, mindjárt kiderül Legyen (nagyobb) biztonság! Aki ismeri a két rendszer felépítését, az tudja, hogy alapvet en a biztonság kérdésköre az, ahol az NT-alapú rendszerek lekörözik a Win9x vonalat. Felhasználók, privilégium-szintek, jogosultságok, hitelesítés, ha egyáltalán léteznek, mind-mind nyögvenyel s funkció a hagyományos Windows világban. Nem vállalati környezetbe tervezték a terméket, no Ha van tehát gyenge pont, ahol meg lehet távolról és ismeretlenül fogni egy Win9x gépet, akkor ez a biztonság lesz. És valóban: egy egyszer en telepített Windows 95/98 nem ismeri például az NTLMv2 hitelesítést. Igaz, a Windows 2000-hez adott Active Directory kliens

segédprogram telepítésével ez a korlát már nem korlát, de joggal feltételeztem, hogy a Windows 95 rendszer használója nem ismeri az így keletkez járulékos el nyöket, és az AD klienst nem telepítette. Az ötlet egyszer : tiltsuk le csoportházirend segítségével a LANMAN és az NTLM hitelesítést. Mi értelme van ennek a beállításnak, ha az ügyfelek 99%-a NT4 munkaállomás? Látszólag nem sok. Csakhogy: mi végzi el a hitelesítéseket? A tartományvezérl . Abból viszont nálunk már csak Windows 2000-es létezik Nosza, adjuk meg tartományszinten azt a szabályt, hogy DC-k csak NTLMv2 hitelesítést fogadjanak el. Okozhat ez problémát? Az NT4-es gépeknek nem, ha van rajtuk 4-es javítócsomag, azt pedig még 1999 decemberéig (a dátumváltási mizéria idején) mindegyik megkapta. S t, a gépek 90%-a SP6-os csomaggal fut A Windows 2000-es szervereknek sem lesz semmi bajuk, hiszen egymás között Kerberost használnak, az NTLMv2 pedig a kisujjukban van.

Egyedül a kósza Win9x-es gépeknek lesz problémájuk. Épp ezt szeretném: telefonáljon nekem az a felhasználó, akinek gondja van. Egy beállítás – kicsit pontatlanul Beállítottam, amit be kell, és vártam. Ha ránéz a képre az Olvasó, rögtön láthatja, hogy a dolog egy picit sántít Ez a beállítás arról szól, hogy a szerverek (hiszen csak rájuk érvényes még a házirend, mert csak k tudják alkalmazni) csak NTLMv2 csomagot küldenek ami azonban nem zárja ki, hogy LM vagy NTLM csomagot fogadjanak. Ez egy tévedés volt a részemr l, és a tényleges kísérletemet meghiúsította volna, de a történetünk szempontjából ez most kevésbé érdekes. Sokkal fontosabb az, hogy nem történt semmi. Eltelt egy-két nap, és egyetlen telefonos bejelentés sem érkezett, amelyb l azt lehetett volna kihámozni, hogy itt hitelesítési problémába ütközött a felhasználó. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet

 2000-2003, NetAcademia Kft 2 NetAcademia-tudástár A dolog annyiban maradt. A beállítást, - lévén, hogy ártalmatlan - nem piszkáltam a továbbiakban Kell neked biztonság? Nesze! Ahogy a mesében, eltelt egy hét, elkelt kett s t lehet, hogy tizenkett . Az egész dologról megfeledkeztem Egyik nap látom ám, hogy a vállalatirányítási rendszerünk cluster kiszolgálói közül az egyiken nem indul a fürtszolgáltatás. Sajnos nincs szép képem, amelyet megmutathatnék, de az esemény pontos leírásával szolgálhatok. Event ID 9 The device, DeviceScsiCpqfcalm2 did not respond within the timeout period. Szép, csupa piros eseménynaplónk volt. A Cpqfcalm2 megnevezés a host bus adatpereket rejti, amelyek a lemezalrendszerrel biztosítják a kapcsolatot Mivel az adapterek nem válaszoltak, nincsenek lemezek Ha pedig nincsenek lemezek, akkor nem csoda, hogy a fürtszolgáltatás nem indul. Event ID 1009 The Clustering Service could not join an existing cluster

and could not form a new cluster. The Clustering Service has terminated. Event ID 7031 The Cluster Service service terminated unexpectedly. It has done this 2 time(s) The following corrective action will be taken in <100000> milliseconds. Restart the service Ez bizony csúnya hardverhiba. Van ugyan egy kis bökken , nevezetesen, hogy egyszerre két HBA ment tönkre, de legalább van fürtszolgáltatásunk, és az ERP rendszerünk nem áll meg. Be kell jelenteni a szállítónak, az majd jön, kicseréli a hibás alkatrészeket, aztán helyreáll a rend és a béke. Mivel sima ügyr l van szó, „végrendelkeztem” a kollégámnak, és elmentem tanulmányi szabadságra, ahogy azt már jóval korábban elterveztem. Pár nap múlva megérkezett a segítség. A gyártó szakmérnöke megnézegette a hardver eseménynaplóit, de semmi hibát nem talált. Azért az mégiscsak furcsa, hogy két eszköz is hibás, de a diagnosztika szerint hibátlan A szokásos „indítsuk újra”,

meg „próbáljuk csak a fürtszolgáltatást” ötletek után következett az „indítsuk újra a hibátlan másik fürtöt” is. Ekkor jött az igazi meglepetés: a mindaddig hibás HBA kártyák hirtelen feléledtek, „meglátták” a közös lemezeket, a fürtszolgáltatás pedig elindult. Az újraindítást követ en viszont a másik állomás kezdett az els höz hasonló tüneteket produkálni Hmm Ekkor kaptam az els telefont, mint felkent fürtszakért . Bámultam, mint borjú az új kapura Olvastam én már mindenfélét, de ilyen hibáról meg nem hallottam. Egyre csak azon gondolkodtam, hogy ez hardver- vagy eszközvezérl hiba lehet, hiszen mi másról lenne szó, ha abból a rétegb l jön a jelzés, és jelzi: a „HBA nem válaszol”. A kollégák azonban kevésbé voltak betokosodva. Az volt a sejtésük, hogy ez fürthiba, ha pedig fürthiba, akkor a TechNet CD, vagy a frissebb weblap segíteni fog, legalábbis ötletet ad. Nem tévedtek, mert a következ ket

találták: Q272129 A hiba leírása rövidítve a következ : Vagyis: a probléma akkor jelentkezhet, ha szigorú biztonsági sablont alkalmazunk, vagy kézzel állítjuk át a hitelesítési szintet bármi másra, mint „LM és NTLM” a Windows 2000 alapú fürtökön. A fürt nem m ködik helyesen, ha NTLMv2-t használ Minden hitelesítés bels eljárásokkal történik, miután a fürtszolgáltatás RPC csomagokkal létrejön. Csak a fürthöz való csatlakozáskor fordul a cluster a tartományvezérl khöz, hogy a cluster fiókot hitelesítse. Minden állomást, amely csatlakozni akar a fürthöz, a magánhálózaton keresztül hitelesíti a quorum tulajdonosa. Ekkor csak LM és NTLM módszert használ a kiszolgáló. Még egy mozdulat a kollégák részér l, és megtalálták a hibás beállítást. De ki állította be? Újabb hívást kaptam „Nem tudom, válaszoltam, de nem köszöni meg t lem, amit kapni fog” - feleltem. Aztán rövid id múlva derengeni kezdett a

dolog, visszahívtam a fiúkat, és töredelmesen bevallottam, hogy az a valaki valószín leg én voltam. Ez bizony égés Ráadásul nem kevés pénz is. Az els munkanapomon megnéztem a fürt naplóit: [CS] Service Domain Account = MALclustuser [CS] Initializing RPC server. [INIT] Attempting to join cluster MAL-ENTERP1 [JOIN] Spawning thread to connect to sponsor 192.1681112 [JOIN] Asking 192.1681112 to sponsor us [JOIN] Unable to get join version data from sponsor 192.1681112 using NTLM package, status 1825 [JOIN] JoinVersion data for sponsor 192.1681112 is invalid, status 1825 [JOIN] All connect threads have terminated. [JOIN] Unable to connect to any sponsor node. [INIT] Failed to join cluster, status 53 Az 1825-ös hiba hitelesít csomaghoz kapcsolódó problémát jelöl. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár Tanulságok 1. A munkánk során tele vagyunk hibás

következtetésekkel Különösen igaz ez akkor, ha egy összetett, minden részletében nem ismert alrendszerr l (GPO, cluster) van szó. A házirend például nem érvényesült a tartományvezérl kön, mert azokra egy hozzájuk közelebbi GPO felülírta az én beállításomat. Ez egyébként hátráltatta a problémamegoldást, mert ha több fürtön hasonló hiba jelentkezik, az ember el bb kezd központi hibaforrásra gyanakodni. 2. Lehetséges olyan globális beállítás, amely funkcióban t le távoli rendszereket érint Ez a szomorú valóság 3. Nem elég sokat olvasni – még többet kell 4. Hasznos elemezni a fürt naplóját, sokat segíthet Ha ezt a szabadságom el tt megteszem, megtakarítottam volna egy hétvégi munkát a kollégáimnak. Mindehhez hozzá kell tenni, hogy a sokat emlegetett biztonság kontra használhatóság vonalat le kellene cserélni a biztonság-használhatóság-kompatiblitás háromszögre, amikor a rendszereinket tervezzük. A fenti hiba

ugyanis azt jelenti, hogy amíg a gyártó (jelen esetben a Microsoft) ki nem javítja a fürtszolgáltatás hitelesít alrendszerét, addig együtt kell élnünk régi, kevésbé biztonságos szabványokkal. Ha van igazán szomorú következtetés, akkor azt hiszem, hogy ez az Szép dolog a Windows 2000 sok új biztonsági újítása, de akik a magas rendelkezésre állás útját választják, azoknak egyel re várni kell az új világra. A következ javítócsomagig? A következ verzióig? Vagy még tovább? Lepenye Tamás, MCSE 2000 lepenyet@mal.hu Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthet  2000-2003, NetAcademia Kft 4