Categoryhigh availability

CAS Array 03/03 – Exchange 2013

Ez elméletileg a világ legrövidebb cikke lehetne: az Exchange 2013-ban nincs CAS Array. Pont.

De nem ússzuk meg ennyivel. Hiszen a CAS Array funkcionalitása hasznos volt. Valahol kell lennie valami hasonlónak.

Mindenekelőtt vizsgáljuk meg az előző írásban feltett két kérdést.

  1. Ha minden RPC forgalom RPC over HTTPS formában menne, szükségünk lenne-e marha drága loadbalancer készülékekre?
    A válasz egyértelműen az, hogy nem. A loadbalance algoritmus a layer7-ről lecsúszna a layer4-be, ott pedig már elboldogul egy sokkal olcsóbb reverse webproxy is.
  2. Át lehet-e terelni minden RPC forgalmat RPC over HTTPS-re?
    Ez már fogósabb kérdés. Mi dönti el, hogy az Outlook melyik metódussal próbálkozik? Gyakorlatilag a sikertelenség. Ha beállítjuk az Outlook profilunkban a belső szerver/CAS Array elérhetőségét, majd megadunk hozzá egy proxy szervert is, akkor az Outlook először megpróbálja RPC over TCP protokollon keresztül elérni a belső szervert. Ha a belső hálón van, akkor ez valószínűleg sikerül is neki. Ha a külső hálón van, akkor jó eséllyel nem. (Ha csak el nem konfigurálod.) Ilyenkor vált át RPC over HTTPS-re és támadja meg a proxyként megadott címet.
    Látható, hogy ha csak külső felhasználóink vannak, akkor a probléma megoldható. De ha már van belső felhasználónk is, akkor az először a belső címre próbálkozik, RPC over TCP-vel. Nyilván ezt blokkolhatjuk, vagy a CAS Array IP címének beállíthatunk valami marsbéli IP címet is – de ezekért súlyos timeout-tal, közvetve pedig felhasználói elégedetlenséggel fizetünk. Mivel az Outlook elsősorban a sima RPC-t favorizálja, így a belső hálón nem ússzuk meg a loadbalancert.

Itt jön be a képbe az Exchange 2013. Ebből ugyanis kidobták az RPC over TCP protokollt.
Elég markáns megoldása a problémának, nem mondom. Ezzel ugyanis teljesen megváltozott a leányzó fekvése. Mivel az Exchange 2013 CAS nem fogad el RPC over TCP-t, marad az RPC over HTTPS. Ez pedig már webes protokoll, melyet minden további nélkül tudunk loadbalancolni a Linux szerverünkkel. Aztán gondoljuk tovább: szükségünk van-e még az adatbázisok RPCClientAccessServer változójára? Miért lenne? Az Outlook már nem innen fogja megtudni a CAS szerver nevét. Ezért nincs szükség magára a CAS Array objektumra sem.
Ha nem innen, akkor viszont honnét? Hát az Autodiscover szolgáltatástól, mint minden más normális webes elérés az Exchange-ben. Az Outlook Anywhere szolgáltatásnak is lesz internalhostname és externalhostname paramétere, ahol az internalhostname mondja meg, melyik szervert kell támadnia bentről az Outlooknak.
Ismerős?
Na, ebből a névből lehet CAS Array-t faragni. Létrehozunk egy bejegyzést a DNS-ben, a megszokott outlook.cegnev.local névhez. Ez lehet egy kitüntetett CAS szerver IP címe, lehet DNS round robin formában az összes CAS szerver IP címe és természetesen lehet ez a reverse proxy szerverünk “külső” IP címe is. Aztán egyenként átírjuk az összes CAS szerverünkön az internalhostname paramétert erre a névre.

A CAS Array esetében láttuk, hogy kulcsfontosságú volt, mikor hoztuk létre. Jelen esetben ez már nem annyira lényeges. Amint átírtuk az értéket, az Autodiscover véges időn belül észleli a változásokat és szét is küldi.

CAS Array 02/03 – Amikor kezd bonyolódni az élet

Nos, nézzük meg alaposabban, mi is történik a különböző RPC kapcsolatok esetén, ha már van CAS Array objektumunk és rendesen be is lett állítva mind az adatbázisokban, mind az Outlook profilokban.

1. Sima RPC over TCP

From Segédlet

Ez egy viszonylag egyszerű eset. Van egy CAS Array, mondjuk outlook.cegnev.local. (Javasolt best practice.) Ennek az IP címét a DNS-ben úgy állítjuk be, hogy az egyik CAS szerverre, jelen esetben a CASy-ra mutasson. Az Outlook profilban az outlook.cegnev.local név szerepel, így az RPC kérés elmegy a CASy-ra, ott az MSExchangeRPC szolgáltatás a felhasználó MDBHome értéke alapján megkeresi, melyik Mailbox szerveren van éppen az aktív adatbázisa, és már proxyzza is a kérést.

2. Magas rendelkezésreállású RPC over TCP

From Segédlet

Magas rendelkezésreállás. Csináltunk DAG-ot, van több DC-nk, mind a hardverek, mind a network eszközök redundánsak. Most már csak az Exchange elérésének kellene annak lennie. Az RPC kommunikációt kétféleképpen tehetjük azzá:

  • Windows Load Balance Service, magunk között csak WLBS.
    Felejtős. Anyira, hogy a Microsoft sem ajánlja. Ha érdekelnek a részletek, akkor a legnagyobb hiányossága az affinitás. Pontosabban a hiánya. Csak akkor hagy figyelmen kívül egy node-ot, ha az már IP szinten sem érhető el. Exchange esetében van még egy durva hátrány: a failover cluster és a WLBS nem fér el egy gépen, tehát a korrekt megoldás még két Windows és még két Exchange licenszbe kerülne.
  • Hardware loadbalancer
    Ennyi pénzért már korrekt hardveres loadbalancer kapható. Ez ügyes, okos, mindent tud.

Tehát betettük a loadbalancer clustert a belső hálózatunkba. Cluster, mert ugye magas rendelkezésreállás. Belső háló, mert az RPC csak ott van értelmezve. Jól is néznénk ki, ha kintről is jönnének RPC kérések.
A CAS Array IP címe egyben a loadbalancer cluster virtuális IP címe. A kliensről ide érkezik be a kérés, a loadbalancer pedig a beállított konfigurációja alapján továbbítja a kérést valamelyik CAS szerver felé. Jelen esetben ez megint a CASy. Onnantól minden megy ugyanúgy, mint az előző esetben.

3. RPC over HTTPS

From Segédlet

Eddig beszéltünk a belső hálózatról. De mi van azokkal, akik valamilyen okból kifolyólag kívülről szeretnék elérni a postafiókjukat? Outlookból?
Erre találták ki az RPC over HTTPS-t. Az Outlook kliensben megadom az elérendő belső címet (outlook.cegnev.local), de mellette megadjuk a DMZ-ben elrejtett reverse proxy kinti nevét is. (Ez simán lehet egy mezei virtuális Linux egy akármilyen webszerverrel.) A reverse proxy tudja, hogy a kívülről jövő HTTPS kérést – mert ő csak ennyit lát belőle – melyik belső webszerverre kell dobnia. (Megjegyzem, itt már remekül lehet affinitást is konfigurálni – de webproxynál csak webes protokollokra működik.) A fenti ábrán a CASx webszervert választotta. A CASx terminálja a HTTPS csatornát. Itt bújik ki belőle az RPC és nekiáll keresni a CAS Array-t. A DNS vissza fogja dobni neki a beállított IP címet, a kérés továbbpattan, majd onnan megy minden, mint korábban.

4. Magas rendelkezésreállású RPC over HTTPS

From Segédlet

Ha már van egy loadbalancer készülékünk, mely az Exchange szerverek RPC szolgáltatásait proxyzza, simán használhatjuk arra is, hogy ugyanezen szerverek webszolgáltatásaival is megtegye ugyanezt. (Sajnos a Linux szervert nem tudjuk használni RPC proxyzásra, mert az már layer7.) Ettől persze egészen érdekes lesz a táncrend. A loadbalancer VIP címe van kiforgatva a külvilág felé, ide érkezik be a HTTPS forgalom. Az eszköz a HTTPS loadbalance paraméterek szerint dobja tovább a kérést egy tetszőleges CAS szervernek, ez megint a CASx. A CASx terminálja a HTTPS forgalmat, kibújik az RPC, keresi a CAS Array-t – mely jelen esetben megint a loadbalancer VIP címe. Viszont ekkor már RPC forgalomról beszélünk. A forgalom az RPC loadbalance szabályok szerint megy tovább, immár a CASy-ra, ahonnan már ismerjük a mókát.

Hogy tetszik?
Mert nekem nem túlzottan. Az utolsó két ábra olyan, mint egy Klampár-Jónyer pingpongmeccs. Muszáj ekkora adok-kapokba belemennünk?
Nem. Az MSExchangeRPC szolgáltatás képes arra, hogy megtalálja a rövidebb utat az erdőn keresztül.
De ehhez durván le kell szarnia az etikettet.
A valós működés az, hogy abban a pillanatban, amint egy CAS szerver kap egy proxyzandó kérést, mindent félretéve megpróbálkozik maga elérni az illetékes Mailbox szervert. Amennyiben ez sikerül, akkor a kérés már nem pattog tovább.

Tessék ezen egy kicsit elgondolkodni. Az utolsó két ábráról egyből látszik, hogy hülyeség. Valótlan. Már a CASx szerver megpróbálkozik elérni a Mailbox szervert és amennyiben sikerül neki, akkor a többi elem nem játszik.
Konkrétan letojja, hogy van-e CAS Array és mi a konfigurációja. Megpróbálja elérni a Mailbox szervert, és ha sikerül, akkor sínen vagyunk. Sőt, a sima RPC over TCP kapcsolatoknál sem foglalkozik egyik CAS szerver sem a CAS Array objektummal. Tőlük fel is fordulhat.

Fogadok, most összezavarodtál. A cikkek lényege éppen az lett volna, hogy megmutassam, mennyire fontos dolog ez a CAS Array objektum. Aztán kiderül, hogy a kutya sem használja. Írtam két hosszú cikket, ábrákat rajzoltam… majd kinyírtam a főhőst, mintha egy Trónok Harca szereplő lett volna. Ennek mi értelme?

Jó, pihenjünk meg egy kicsit.

Ha már lehiggadtunk, észre fogjuk venni, hogy tulajdonképpen minden rendben van: az MSExchangeRPC szolgáltatás akkor önállóskodik, amikor a kérés már elérte a CAS szervert; a CAS Array pedig arra szolgál, hogy a kliens elérje az első CAS szervert. A CAS Array nem tehet arról, hogy az RPC over HTTPS egy reverse proxyn keresztül jön be és már ez a proxy megmondja, melyik CAS szervert kell elérni. Az RPC over TCP protokoll esetében meg természetes, hogy a CAS szervereket nem érdekli a CAS Array: nem nekik találták ki. A CAS Array objektumot a MAPI kliensek használják.

Viszont ajánlanék a figyelmedbe két töprengenivalót.

  1. Ha minden forgalmat sikerülne RPC over TCP helyett RPC over HTTPS-re terelni, akkor szükség lenne-e a magas rendelkezésreállás biztosításához a drága loadbalancer cuccokra? Nem lenne-e elég helyettük az ingyenes Linux reverse proxy?
  2. Meg lehet-e oldani, hogy minden kliens forgalom RPC over HTTPS-en keresztül menjen?

Internet Database Availability Group

Amikor elkezdtem olvasni Scott cikkét, egyből elcsöppent a nyálam. Épp mostanában van egy olyan munkám, hogy bár az ügyfélnek nincs túl sok pénze, de szeretne egy olyan HA megoldást két telephelyen, melyek még akkor is működnek, ha a Föld megsemmisül. Üzletpolitikailag meg nem mondhatjuk azt, hogy nem.
Szóval olvastam, olvastam, és bár a működését elsőre még nem láttam át teljes mélységében, de nagyon tetszett a dolog. Végülis nem akárki írta a cikket, aki Scott Schnollnál többet tud az Exchange HA területről, az már festi magát. És pont most jöttek ki vele, pont amikor égető szükségünk lenne rá. Remek.

A lelkesedésem egészen addig tartott, amíg észre nem vettem az írás végén a tag-eket.

ps.
Persze, folyamatosan nyüzsgött agyam hátterében a kisördög: mi is van azzal a kritikus round-trip latency-vel, az adatbázisok rpcclientaccessserver paramétereivel, na meg a CAS proxyzásokkal? De olyan jó lett volna hinni benne, hogy ezt mind-mind megoldották.

Jó az öreg a háznál

Takarítottam a sufniban és a kezembe akadt egy 10 mbites HUB. Először elmosolyodtam, aztán elérzékenyültem: Istenem, amikor ilyenekből építettük a hálózatot… a gyerekek alsósok voltak, nekem pedig még volt hajam…
Majd jött a következő gondolat: megőrizzem? Menjen a lomtalanításra szánt cuccok közé?

Nos, kidobásról szó sem lehet. Jó lesz ez még valamire.

1. Belehallgatni a hálózati forgalomba

Képzeld el, hogy van egy router az internet felé, a belső hálón pedig egy NAS. Egyik sincs rootolva (mert egyáltalán nem vagyok olyan vadember, mint amilyennek néha látszom), az utóbbin valami linux klón alapú oprendszer van. A NAS-on beállítható, hogy küldjön emailben riasztást, ha bármi rendkivüli esemény történt. Beállítottam. Van mellette egy ‘teszt’ gomb. Megnyomtam. Szűkszavú üzenet: a levélküldés sikertelen.
?
Ha látnám a hálózati forgalmat, sokkal okosabb lennék. De egyik eszközön sincs sniffer, a switchelt hálózatban meg cseszhetem a promiszkusz módot. Nos, ekkor jön a jó öreg HUB. Beledugom a NAS-t, beledugom a laptopot, beledugom a routert, és már indulhat is a Wireshark.

2. Kici ócó NLB

Nem lesz rövid. Ahhoz, hogy érthető legyen a levezetés, kénytelen leszek alaposan kivesézni ezt az egész NLB katyvaszt, közben persze el is fogok kalandozni jobbra-balra. De nem lesz minden haszon nélkül az írás, legalábbis remélem.
Kezdjük ott, hogy milyen NLB technikák is léteznek?
Multicast és Unicast.
Mindkét módszernél azt kell valahogy megoldanunk, hogy habár egy csomagot csak egy unicast IP címre küldünk el, az mégis több géphez érkezhessen meg. Sőt, az a varázsló, aki ezt elvégzi, gondoskodjon arról is, hogy a célgépek közötti terhelés elosztása konfigurálható legyen. Még sőtebb, tudjuk szabályozni azt is, hogy a szétszórás csak bizonyos portok között történjen meg.
A varázslót hívják NLB-nek, illetve a Windows implementációját WNLB-nek.

From Segédlet

2.1 Multicast

Ebben az esetben az NLB node-ok hálózati kártyái kapnak egy plusz unicast IP címet (VIP) és egy plusz multicast MAC címet (VMACM), a meglévő unicast IP címük (IP1/IP2) és MAC címük (MAC1/MAC2) mellé.

From Segédlet

A node-ok személyes adatforgalmát a módosítás nem érinti. Használják az IP1/2 és MAC1/2 címeket, élnek, mint Marci Hevesen. A switchben is a MAC1/2 címek jelennek meg, hiszen ez szerepel a csomagok Ethernet keretében. A VIP címet felvettük a DNS-be, kihirdettük a cégnél. Jön is a kliens és rá akar csatlakozni az NLB szolgáltatására. (Az egyszerűség kedvéért legyen ez egy weblap, de bármi más is lehet, ami egy tcp porton keresztül érhető el.) A felhasználó beírja a böngészőbe a címet, a DNS visszaadja neki a VIP-et, a gép elküld egy ARP kérést a VIP címre. Ez broadcast, tehát mindenki felkapja. Az NLB magára ismer és küld egy ARP választ, benne a VMACM címmel. A kliens örül, megvan a cél MAC address, beteszi az Ethernet keretbe, megy a csomag. A switch érzékeli, hogy a csomag címzettje egy multicast MAC cím, alaphelyzetben ezeket gondolkodás nélkül kitolja mindegyik portra, tehát a csomag megérkezik az NLB-hez is, aki a saját szeszélye alapján továbbtolja valamelyik node-ra.
Okos? Okos. Működik? Háát…
Akadnak bajok.
Például egy másik kliens a router mögül próbálkozik. Ilyenkor a túloldali ARP kérést a router ragadja magához, hogy majd ő küld egy újabb ARP kérést a másik alhálózaton. Elküldi, visszakap egy olyan kombinációt, miszerint a cél node-nak unicast IP címe és multicast MAC címe van. – Ne te, már ne! – hőköl vissza és eldobja a csomagot. Kommunikáció meglőve. Ezt még kilőhetjük úgy, hogy a router ARP táblájába felvesszük statikus bejegyzésként a VIP-VMACM párost, ilyenkor nincs ARP kérdezz/felelek, a router helyből tudja a MAC címet, tehát mehet a csomag. (Hozzáteszem, hogy vannak olyan háklis routerek, melyek nem csak az ARP válaszban nem bírják elviselni a unicast IP – multicast MAC kombinációt, hanem úgy egyáltalán sem. Ekkor elfelejthetjük a Multicast NLB-t, vagy érdemei elismerése mellett nyugdíjazzuk a routert.)
Oké, router rendben. De mi van, ha az NLB akar küldeni egy csomagot a nyúlon routeren túlra? Kezdi azzal, hogy küld egy ARP kérést a router IP címére. Windows 2003-ig bezárólag az NLB csalt, mert az ARP kérést a MAC1/2 címről küldte, de a Windows 2008 már a VMACM címet teszi a kérésbe. Mit csinál ezzel a router? Úgy van, kidobja oda, ahová a szabálytalan csomagokat szokta. A kommunikáció megint meghalt. Kénytelenek leszünk az NLB node-ok ARP tábláját is módosítani, fel kell venni a router IP-MAC párosát statikus bejegyzésként. Ekkor nem kell megvárnunk, hogy a router válaszoljon a szabálytalan kérésünkre, menni fog a feloldás séróból is.
És még nincs vége a galibáknak.
Mit is írtam? A switchre küldött multicast MAC címet tartalmazó csomagot a switch alapból kiküldi minden portjára. Jó ez nekünk? Nem annyira. Gyakorlatilag elárasztjuk a switchre kötött egyéb hostokat tök felesleges csomagokkal. (Úgy is hívják a jelenséget, hogy flood.) Természetesen ez ellen is lehet védekezni, de itt már elgondolkodik a rendszergazda arról, hogy mennyire is igaz a Microsoft azon állítása, hogy az NLB olcsó és egyszerű technika.
Az egyik megoldás úgy néz ki, hogy okos switchünk van, ahol be tudjuk állítani, hogy a multicast csomagok mely portokon jelenhetnek csak meg. A többi port coki. Ez működik, de olyan nem elegáns. Ha figyelmetlenül valamiért átdugom másik portba az NLB lábát, akkor újra floodolok, ráadásul lehet, hogy csak akkor veszem észre, amikor vezig ordítva beront a gépterembe a hálózat lassúsága miatt. (Oké, jobb helyeken a vezig kártyája nem nyitja a gépterem ajtaját, de nem biztos, hogy adott esetben ez a hosszútávú megoldás.)
Sokkal elegánsabb, ha még okosabb switchet használunk, mely már tudja az IGMP snooping technikát. Ekkor persze az NLB-t is konfigurálni kell. Azt mondjuk neki, hogy az ARP válasz csomag mellé tegyen már egy IGMP Host Membership Report csomagot is. Erre a csomagokra általában csak a routerek vevők, de nekünk okos switchünk van, aki bele tud lesni (snoop) az IGMP csomagba, és innentől tudni fogja, hogy mely portok mögött van olyan host, amelyik multicast vevő. A többire nem küldi tovább a multicast MAC címmel rendelkező csomagokat.
Végül természetesen megoldás lehet az is, hogy az NLB két lábát külön VLAN-ba tesszük. Ekkor ugyan a csomagok továbbra is elárasztják a broadcast domaint (a switchnek azokat a portjait, melyek a VLAN-hoz tartoznak), de mivel csak a két NLB láb érintett, így a floodolást az érintett portokra korlátoztuk. Viszont gondoskodnunk kell a VLAN elérhetőségéről.

Nos, ennyi. Látható, hogy a megoldáshoz módosítani kell mind a router, mind a node-ok ARP tábláját és minimum menedzselhető switchekre van szükségünk, akár portot akarunk konfigurálni, akár VLAN-t akarunk kialakítani, az IGMP snoopingról már nem is beszélve. Ez bizony se nem kici, se nem ócó. (A moddolt firmware-es olcsó routereket most hanyagoljuk.)

2.2 Unicast

Ennél az NLB technikánál más a trükk. Az NLB lecseréli a node-ok címeit, egy közös VIP és VMAC címre. Mindkettő unicast, tehát semmi szükség a multicast-os trükközésekre. Mivel mind a két node címei megyegyeznek, a nekik küldött csomagok megérkeznek az NLB-hez, aki már tud velük játszani.

From Segédlet

Nyilván ez sem ennyire egyszerű. Például milyen MAC címet jegyez be a switch a node-ok portjaihoz? A VMAC-et? Azzal gond lesz, mert az elsőt be fogja jegyezni, a másodikat már nem, mivel ugyanaz a MAC nem jelenhet meg más porton is. Ezzel jól ki is heréltük az NLB-t, mert mindig csak egy portra menne a forgalom.
A trükk az, hogy NLB elmaszkolja a VMAC címet. Összedob mindkét node számára egy kamu MAC címet és ezt teszi az Ethernet keretbe. (Az ábrán MACK1 és MACK2.) A switch ezeket a címeket fogja bejegyezni a portokhoz.
Nézzük akkor a folyamatot. VIP-et bejegyeztük, kihirdettük, felhasználónk beírja a böngészőbe, a gépe elküld egy ARP kérést a VIP címre. Az NLB felkapja, belerakja az ARP keretbe a valódi VMAC értéket. (Az Ethernet keretben a kamu MAC cím van, de ez jelenleg senkit nem érdekel.) A kérdező megkapja, boldog. Összedobja a csomagot. Hogyan? Hát belerakja a frissen kapott VMAC értéket az Ethernet keretbe. Elküldi. Mit fog ezzel a csomaggal csinálni a switch? Hát, zavarba jön. Ilyen MAC cím nincs hozzárendelve egyik porthoz sem. Ilyenkor a standard eljárás az, hogy a switch kiküldi a csomagot minden portra és reménykedik abban, hogy valahonnan visszajön egy válasz és akkor majd bejegyzi jól. Hát, ezt most várhatja.
Lássuk a cifrázást.
A router jelen esetben nem háklis. Mind a VIP, mind a VMAC normális unicast címek. Suhannak a csomagok, mint olajos hal a vécélefolyóban.
Ellenben. Tud-e kommunikálni a két node egymással? Nézzük. Node1 küld egy ARP kérést a VIP címre. Az ARP keretben visszakapja a VMAC értéket. Ezt belerakja a küldendő csomag Ethernet keretébe… majd döbbenten észleli, hogy ez az ő MAC címe. Nem küldi sehova.
Legalábbis nem mindig. És nem mindet.
Ott van például az NLB heartbeat. Erről annyit kell tudni, hogy broadcast, az Ethertype értéke 0x886F és csak node szinten működik, azaz azt nem tudja megállapítani, hogy a port szabályokban megadott portokon tényleg fut-e valami szolgáltatás. Na, ez a kommunikáció például megy. Miért is? Hiszen mondtam: broadcast. Csak a célzott kommunikáció nem megy.
És az se mindig döglődik. Windows 2003 Sp1 óta pl van egy érdekes lehetőség. A registry-ben engedélyezhető (UnicastInterHostCommSupport) hálózati kártya szinten, hogy unicast node-ok is tudjanak egymással beszélgetni.
Ettől függetlenül ez a modell nem terjedt el. Gondoljunk bele, mit csinálnánk, ha rendszergazdaként be szeretnénk lépni konkrétan az egyik node-ra? Az NLB meg mindig a másikra dob. Idegbaj. Emiatt is szoktak berakni az NLB kártya mellé egy másik hálózati kártyát.

From Segédlet

Nem mondanám, hogy egyszerűsödik, mi? Számok, szaggatott nyilak, minden, ami szem-szájnak ingere.
Az alapprobléma az, hogy melyik kártyán legyen beállítva a default gateway. Mindkettőn nem javasolt, mint ahogy a Windows erre figyelmeztet is. Na jó, akkor melyik legyen a nagy hatótávolságú, routeren is átlátó kártya és melyik az, amelyik csak a subneten beszélget? Hülye kérdés. Nem így fogjuk rendezni a helyzetet. Egyszerűen beállítjuk a normál kártyát első számú kártyának (erre kerül a default gateway), az NLB kártyát meg második számúnak. Így bármelyik kártyán is jön be csomag, kifelé a normál kártyán fog menni.
Ha hagyják.
A Vista/Windows Server 2008 vonulat óta a hálózati kártyák összelinkelése alaphelyzetben tiltott. Azaz ha az NLB kártyán jön be egy csomag, akkor az nem tud kimenni a másik kártyán. Ehhez netsh segítségével rá kell linkelni az NLB kártya forgalmát a normál kártyára. Ekkor már ki tud menni.
Windows Server 2008 esetén ugyanezt másképpen is el tudjuk érni. Modellváltás. A Windows Server 2008 alaphelyzetben az ún. Strong Host modellt használja. A korábbi szervertermékek a Weak Host modellt alkalmazták, mely azt jelenti, hogy az operációs rendszernek semmi kifogása sincs az ellen, hogy multihomed (több hálókártyás) rendszerben az egyik kártyán keresztül el lehessen érni a másik kártyán futó szolgáltatásokat. A mi esetünkben ez azzal jár, hogy a Windowst át kell váltani a Weak Host modellre. Naná, ezt is netsh-val, méghozzá kártyaszinten, azon belül is külön küldő, illetve külön fogadó irányban.
Zsong már a fejed? Pedig még nincs vége.
Nézzük át, mi is történik ilyenkor. VIP publikálva, felhasználó gépétől jön az ARP kérés a VIP címre. Ez broadcast, kimegy mindenhová, az NLB felkapja. A válaszba belerakja a VIP és a VMAC értékeket. A visszamenő csomag viszont már a konkrét gép valós hálózati kártyáján megy ki, annak a MAC címe kerül bele az Ethernet keretbe… de ez megint senkit nem érdekel. A túloldalon kicsomagolják az ARP keretet, a következő csomag Ethernet keretébe már az onnan jövő MAC (VMAC) kerül, ez kikerül minden switch portra (mert ismeretlen), az NLB felkapja, a válaszcsomag megint a normál kártyáról megy ki… és így tovább.

Akkor most gondoljuk végig, mi a helyzet flood téren?
Hát, ugye, van. Éppen az előbb jártuk körbe.
Védekezési lehetőség? Nos, az IGMP itt nem játszik, hiszen nincs multicast. Emiatt a switch portját sem tudjuk multicastra konfigurálni. Bizony, egyedül a VLAN felosztás segít, azaz megint drága, menedzselhető switch kell.

És ez az a pont, ahol az eddig csendben üldögélő HUB végre szerepet kap.

From Segédlet

Mi az a csoda, amit a HUB tud? Hát az, hogy nagyjából akkor élte a fénykorát, amikor az NLB-t kitalálták. Erősebbet mondok: az NLB-t a HUB-hoz találták ki, ez az eszköz az NLB ideális játszótere. Miért? Mert a HUB abszolút nem foglalkozik a MAC címekkel. Nem azon a szinten dolgozik. Nagy ívben tojik arra, hogy mit bűvészkedünk a keretekben az L2 címzésekkel. Ez majd a később elszaporodó és egyre okosabb switchek problémája lesz.
Nézzük meg, mit is csináltunk. Az NLB hálókártyákat nem közvetlenül dugtuk be a switchbe, hanem beraktunk eléjük egy HUB-ot. Ennek már csak egy uplinkje kerül bele a switchbe. Mennyi? Egy.
Járjuk körbe ismét a folyamatot. A switch portjára két MAC is rákerül, a kamu MACK1 és a MACK2. A kliens elindít egy ARP kérést, ez broadcast, kikerül a HUB-ra, az NLB felkapja. Valamelyik normál hálókártyáról válaszol, az ARP keretben a VMAC. Kliens következő csomagjában az Ethernet keretben a VMAC, beérkezik a switchbe… ahol megint nem lesz ilyen MAC egyik portnál sem, tehát megint floodolunk.
Izé. Nem maradt itt ki valami?
Dehogyisnem.
A switchben most már csak egy helyen jelenne meg a VMAC, tehát nincs szükség maszkolásra. Egyszerűen kikapcsoljuk: MaskSourceMac érték nullára állítása a registryben. Ekkor kapjuk a fenti ábrán látható szituációt. A HUB letojja, hogy két lábán is ugyanaz a MAC – a VMAC – jelenik meg. Hiszen nála meg se jelenik, nem érzékeli. (Ezért piros.) Az uplinken – függetlenül attól, hogy melyik node-tól jött – csak a VMAC jelenik meg, tehát ez kerül rá a portra. A kliens ARP kérésére az NLB válaszol. Maszkolás nincs, tehát mind az Ethernet, mind az ARP keretbe a VMAC kerül. (De az Ethernet keret még mindig nem érdekli a klienst. A switchet annál inkább.) A kliens a VMAC címre küldi az újabb csomagot, a switchen van ilyen MAC a portoknál, tehát flood kilőve, a csomag csak a HUB-ra jut ki.

Nézzük meg, mit csináltunk. Van egy borzasztó gagyi, nem menedzselhető switchünk és egy, a sufniból előkukázott HUB. Mindösszesen egy plusz kábelbe, illetve egy registry állításba került és tökéletesen működő NLB megoldásunk van.
Tényleg jó néha az öreg a háznál.

Ps1.
Felvetődhet, hogy jó-jó, de mi a helyzet a sebességgel? A switch már jó eséllyel gigás. Hogyan lesz ezzel összhangban a 10 mbites HUB? Melyik piacon lehet venni gigás HUB-ot? A helyzet nem ennyire rossz. Nézzük csak meg, hogyan forognak a csomagok. A szerverre – konkrétan az NLB kártyára – küldött csomagok tényleg keresztülmennek a HUB-on, de a szerverről a kliens felé menő forgalom már közvetlenül a switchre megy. Legtöbbször a kliens csak vezérlő utasítást küld a szerver felé, az pedig adathalmazokat tol vissza – azaz a HUB pont ott szűk keresztmetszet, ahol egyébként sem nagyok az igények.

Ps2.
A cikknek ezzel még nincs vége. Az első célt elértük, látjuk, hogy a HUB-ot tényleg tudjuk még mire használni. De a téma még nincs körbejárva: mi a helyzet például a virtuális környezettel?

Nem az idegbetegek sportja

Exchange és backup… nem dúl közöttük a barátság. Pedig a backup látszólag nem túl bonyolult dolog: egy adott állapotról másolatot kell készíteni. Már az Exchange 5.5 is tudta, hogy amikor elindult a mentés, akkor “befagyasztotta” az adatbázisokat, ezeket lementette, a mentés alatti adatforgalmat ideiglenes adatállományban tárolta, majd a mentés végén az ideiglenes állomány tartalmát rámásolta az élesre. Ennyi.
Mi lehet a baj?

A tudományos fejlődés.

Az hagyján, hogy a tervezők rájöttek arra, hogy a logfájlokkal rengeteg kunsztot lehet bemutatni: full/copy/inkrementális/differenciális backup… ezek régi dolgok. De a cluster koncepció megváltozása, a tranzakciós logokkal bűvészkedő replikációs fürtök már belecsaptak rendesen a lecsóba. Nem is beszélve a fájlmegfogást megkerülő shadow copy-ról, melynél már nem kell vacakolni ideiglenes állományokkal, a VSS writer tud írni akkor is, ha meg van kötve a keze.
Csak éppen maga a folyamat annyira bonyolult lett, annyira sérülékeny, hogy bármilyen kis rendellenesség hetekig tartó kilengéseket képes produkálni. Gondoljunk bele: egyrészt a Windows 2008-ból eltűnt az Exchange mentés lehetősége, később persze visszajött, de bénán: csak egész kötetet enged menteni. Ha ennél finomabb eljárásra van szükségünk, akkor jöhetnek a külső gyártók. Figyeltél? Külső gyártók. Na, innen indul el a totális káosz. Van egy érzékeny, ráadásul a Rollup Packokkal sűrűn változó rendszer, meg a tipikusan lomha és ügyfélérzéketlen külső gyártó. Pusztán csak idő kérdése, hogy jöjjön az a bizonyos apró rendellenesség, melytől hetekig leng a rendszered.
Mi is az, hogy leng? Ha nem megy a mentés, nem törlődnek a logok, ha betelik a logpartíció, megáll a levelezés, ha törlöd a logokat, megáll a cluster replikáció. Egyáltalán nem véletlen, hogy az Exchange team már évek óta azért küzd népnevelésügyileg, hogy felejtsük már el azt a nyűves backupot, próbáljuk meg kiváltani más technológiákkal.

Csak éppen ebben a népművelésben kicsit sok még a köd. Oké, csinálj clustert (CCR, DAG). Ezzel kivédted a katasztrófát. Ha geoclustert csinálsz, akkor elviseled még a telephelyed megsemmisülését is. Great. De mi van a törölt adatokkal? Használd a dumpstert. Remek számítások vannak arra nézve, hogy akár egy évnyi(!) dumpster mennyivel növeli meg az adattárolási kapacitást. Igaz, az Exchange 2010 alá már közértben vásárolható vinyók is jók, de a hosszútávú dumpster egy átlagos felhasználónál durván évi 1,5 GB növekményt jelent. Oké, természetesen lehet trükközni még az archiv postafiókkal is, de azért itt már komolyan neki kell állni számolgatni, mi is az olcsóbb. Azt ugyanis nem szabad elfelejteni, hogy értelmes összegből akkor lesz egy rendszer backupless, ha eleve annak is tervezik. A legtöbbször már van egy SAN, benne egy vagy két rohadt drága storage, azt mondani, hogy ezt innentől tessék nyugodtan kidobni… elég necces. Brutálisan felbővíteni… szintén.

Itt eredetileg egy eszmefuttatás lett volna arról, hogy és akkor mit csinálunk a módosított adatokkal? Ehelyett meaculpa van. Utánaolvastam, és most már tudom, hogy a dumpster 2.0 verziózni is tud. Persze ekkor megint visszajutottunk oda, hogy tárterület, lapátszámra. Különösen, ha egy cégnek mondjuk 5 évre visszamenőleg kell megőriznie a levelezését.

Illetve gondoljunk át még egy szempontot. Ha nincs backup, mi takarítja el a logokat? A Köztisztasági Vállalat nem fogja. Mi is volt a logika a mentés utáni logtörlésekben? Az adatoknak minimum két helyen meg kell lenniük. Eredetileg ez az adatbázis (RAM+HDD) és a log, a mentés után az adatbázis (HDD) és a szalag. Azaz lehet törölni a logot. Ha nincs backup, nincs törlés. Nyilván utánaolvasol, azt találod – de nem túl hangosan reklámozva – hogy használj 3 node-ból álló DAG-ot (mert ekkor nem kell RAID sem, jó a JBOD), ha van rá pénzed, legyen egy lagged copy is, és ha nem akarsz menteni, akkor kapcsold be a cirkuláris logolást. Az Exchange adminok itt kapnak a szívükhöz: 13 éve azt hallják, hogy négy láb jó, két láb rossz, cirkuláris logolás meg a legrosszabb. Elfogadom, tudnunk kell kigondolkozni a dobozból, de valahogy még mindig meglehetősen el vannak rejtve az infók.

Egyáltalán nem meglepő, hogy egy átlagos informatikus – nem beszélve az átlagos IT vezetőről – sokkal inkább azt mondja, hogy backup.

Akit esetleg mélyebben érdekel a dolog, itt talál egy nagyon részletes négyrészes írást Henrik Walthertől. Kötelező darab a tisztánlátáshoz. De a végén tessenek elgondolkodni, mi is a feltétele a 4. részben leírt visszaállításnak.

Na, a hosszú bevezetés után jöjjön a sztori.

Előzmény. Az egyik adatbázis – kampányszerű üzleti tevékenység miatt – bevadult. A logfájlok kihízták a logpartíciót, adatbázis megállt. (Olyan gyors volt a feltelés, hogy bár a figyelő rendszer beriasztott, de mire beavatkozhattunk volna, már fejre is állt minden.) Oké, a logkönyvtárat a már ismert módon áttettük máshová, adatbázis visszaindult.

Nem sokkal később a CCR/SCR rendszerben volt egy failover, majd valamivel később egy failback. A backup külső gyártó szoftverével volt megoldva, méghozzá úgy, hogy a passzív node-ról – és csak arról – ment VSS backup-pal. Egy bibi volt, a szoftver képtelen lekövetni, melyik node a passzív, így azt tudtuk csak beállítani, hogy arról a node-ról mentsen, amelyik az idő nagyobb részében a passzív node. Ez borult fel a pár napos csere miatt és a backup szoftver teljesen bele is zavarodott.

Közben a szerelők felpumpálták a korábbi adatbázis logpartícióját, lehetett visszarakni a logokat. A művelet teljesen hasonlóan zajlott, az eredmény viszont lesújtó lett: az adatbázist ugyan fel lehetett csatolni, de a replikáció failed állapotba került.

Több évnyi tapasztalat után határozottan ki merem jelenteni, hogy az esetek 90%-ában ilyenkor semmi más nem segít, csak a reseed. Nos, most belefutottunk abba a bizonyos 10%-ba: a reseed sem segített. Fejvakarás. Az eventlog szerint hiányzik egy csomó tranzakciós log, és mindenki az anyja életére esküdött, hogy nem ő dugta el. Ekkor derült ki, hogy nem megy a backup, azaz folyamatosan telik fel az összes logpartíció. Miközben reménytelenül nem megy az egyik adatbázisra a logreplikáció. Nem túl biztató a helyzet.

Kipróbáltunk ezt-azt, ahogy az ilyenkor szokás. Nyilván volt közte néhány failover/failback is. Az egyik különösen izgalmasra sikerült, hosszú percekig nem történt semmi, aztán egyszer csak beröffent a cluster. Aznap nem is mertünk hozzányúlni többet.
Másnap összegyűlt a válságstáb. A partíciók monoton teltek befelé, ötlete meg senkinek sem volt. Pontosabban, nekem volt még egy, de azt mondtuk, hogy ha ez sem jön be, akkor eszkalálunk az MS felé.
De mielőtt nekiállhattunk volna, jött az SMS az üzemeltetőtől, hogy reggel ránézett a rendszerre és teljesen váratlanul megjavult a backup. Magától.
Pár hajam azért égnek állt. Megnéztem, és tényleg. Az összes logpartíció tiszta volt… kivéve a replikálatlan adatbázisét.
Huh. Ezt megúsztuk. Bár a fene tudja, hogyan. Én összeraktam ugyan egy elméletet, miszerint a hosszú failoverbe belehülyült a backup szoftver és nem vette észre a failback-et. Emiatt próbálkozott folyamatosan az akkor már aktív node-on, de ez a backup szoftver meg arra képtelen. (Ezeknek a próbálkozásoknak a nyomait láthattuk is.) Ez ment addig, amíg az egyik failback után hirtelen nem realizálta, hogy jé, failback történt. (Ez lett volna az az idegesítően hosszú failback.)
Hülye elmélet, de nem találtunk jobbat.

Kihasználva a lendületet, aznap délután ráküldtem a renitens adatbázisra is egy reseed-et. Hátha ma olyan nap van, hogy minden sikerül. Nem jött be. Másfél óra szuttyogás, aztán a suspend után ugyanúgy ott vigyorgott a failed.

Másnap éppen nagy paláver volt, a sok futó ügy mellett rátértünk erre az esetre is. Sok jót nem tudtam mondani. A logok replikációja a CCR vérkeringése, ha kiesik belőle egy logdarab, azt a replikációt az életben nem rázzuk gatyába. Legegyszerűbb javításnak azt javasoltam, hogy hozzunk létre egy új adatbázist, mozgassunk át mindenkit, majd töröljük a sérült replikációjút. Erre mindenki rá is bólintott, az üzemeltetők elkezdtek teszt postafiókokat mozgatni. (Mert ekkor éppen nem jutott eszembe a disable-storagegroupcopy parancs.)

Délután két üzenetet is kaptam. Az egyik az volt, hogy nincs semmi gond a postafiók-mozgatással. A másik az, hogy nézzek már rá a storage groupra, mert gyanúsan és makacsul úgy néz ki, mint aki egészséges. Ránéztem… és tényleg.
Na, ilyen nincs. Ekkor kerültek bele a fognyomaim az asztallapba. A többi mellé. Ugyanaz a történet, és már másodszor fordul elő, hogy miután fekete színekkel ecseteltem a jövőt, váratlanul megjavult a rendszer. Magától.
Szerencsére elméletgyártásból borzasztó jó vagyok, egy kis idő után itt is találtam valószínűnek tűnő magyarázatot.

Kapkodtam. Amikor ráküldtem a reseed-et, nem vártam eleget. Ha csináltál már ilyesmit, akkor tudod, hogy egy suspend/resume páros után a replikáció mindig healthy állapotot mutat, majd 1-2 perc várakozás és egy refresh után mondja csak meg az igazi értéket. Na, én éppen fordítva jártam, failed értéket mutatott a reseed után, aztán pár perc múlva váltott át healthy-be. Csakhogy akkor én már éppen hazafelé utaztam. (Hogy ne hidd azt, hogy én a fantáziámból élek. A passzív node-on lévő logok dátum értékéből ki tudtam olvasni, mikor röffent be a replikáció. Ebből tudtam, hogy pár perccel később, mint ahogy előző nap bezártam a terminálablakot.)

Na, mindegy, vészforgatókönyv lefújva. Tulajdonképpen minden rendben. Megy a backup, megy a replikáció, madarak ülnek vérebekhez. Eltekintve attól a szépséghibától, hogy a passzív node-on 1 napnyi log volt, az aktívon meg egy heti. De mivel mind a replikáció, mind a backup ment, meg voltam győződve róla, hogy ez a baki hamarosan rendeződni fog.

Nem így történt.

Eltelt két nap, a backup ment, a replikáció szintén… de a logok csak gyűltek. Alapvetően egy Exchange admin élete nem túl bonyolult, csináltam egy újabb reseed-et. Simán lepucolta a logokat a passzív node-ról. Alakul. Az aktív node-ról elmozgattam máshová a replikáció beindulása előtti logokat (ezek biztosan nem játszanak a replikációban), majd trükköztem egyet. Failover. Ekkor az aktívból lett passzív node. Újabb reseed. Innen is lepucolódtak a logok. Failback.

Elégedetten dőltem hátra. Kifogtam a rendszeren… és végre valamit én javítottam meg, a saját agyammal. Replikáció szépen megy, mindkét node-on üres a logpartíció, copyquelength, replayqueuelength értékek masszívan nullák. Tökély.
Persze az abszolút megnyugvás akkor következik be, ha este lemegy a backup és törli is a logfájlokat.

Nem törölte.

Ha láttál már gyilkos tekintetet… akkor szorozd be kettővel. A jelek szerint minden tökéletesen működik… csak éppen a backup nem törli a logokat. Mivel a szituáció egyfelől nagyon általános, másfelől nagyon speciális, esély sincs megoldást találni a guglin.
Marad a szörfözés az eventlogban. Jegyzetfüzet, plajbász, göngyölítsük fel, mi is történik a mentés során. Semmi rendkivüli. A VSS writer megkapja a kérést, összekészíti az adatbázist, a mentő szoftver elviszi, majd jelzi az ESE-nek, hogy a részéről mehet a log file truncation. Az ESE visszaszól, hogy oké, ahogy születik az új loggeneráció, törli a régit. Majd pár órával később egy replikációs lépés során megemlíti az aktuális generáció számát, mely jóval magasabb, mint amit korábban jelzett. Azaz megtörtént a generációváltás – és minden igérete ellenére, az ESE nem törölte a logokat. Őrület.
Gondolkodósarok. Mikor nem törlődnek a logok? Amikor a replikációnak még szüksége van rá. (Emiatt van az, hogy hiába állítod cirkulárisra a logolást egy CCR rendszerben, amíg nem történik meg a logok replikációja, addig nem harap saját farkába a kígyó.) Jó… de ezzel beljebb vagyunk? A replikáció tökéletesen megy. Két ablakban egymás mellé téve a könyvtárakat, akár még animációnak is elmegy, ahogy keletkeznek, vándorolnak.

Kész, itt adtam fel. Egyrészt volt mellette más, igen sürgős munkám, másrészt meg elfogyott a puskapor. Látszólag minden tökéletes, gyakorlatilag meg nem. Hogyan keressek hibát, ha nincs semmilyen nyom?

Hiba volt feladni. Légyszives olvasd el alaposan az eddig írtakat. Minden információ ott van benne, ami a megoldáshoz szükségeltetik. Lehet, én is megtaláltam volna(1), ha nem azon a bizonyos másik munkán járt volna már nagyobbrészt az agyam.

Mindenesetre a beavatkozás nem tűrt halasztást, a logfájlok megint gyarapodtak, a logpartíció szépen telt, telegetett. Microsoft PSS. Leírtam szépen mindent, amit az esettel kapcsolatban tudtam, az üzemeltető kolléga lett a kontakt, én maradtam cc-ben.

Rögtön az első felvetés beletalált a tizes körbe. Ez ugyanis nem szimplán CCR, hanem SCR rendszer is. Csak éppen azzal a szerencsétlen SCR szerverrel soha nem foglalkozik a kutya sem. Azaz ha egyszer, csak úgy véletlenül, beírtam volna a get-storagegroupcopystatus parancs paraméterei közé a -standbyserver kapcsolót, rögtön kiugrott volna, hogy az SCR replikáció még failed állapotban van azon a bizonyos adatbázison. Emiatt volt még szükség a régi tranzakciós logokra, emiatt nem törölte azokat az ESE. Természetesen rögtön nekiugrottunk annak is egy reseed-del, majd amint helyreállt a replikáció, az esti mentés törölte is a logfájlokat. Ahogy kellett.

(1) Különösen úgy, hogy egyszer már ki is írtam magamnak figyelmeztetésként. Azóta egy másik ügyfélnél csináltunk egy katasztrófa utáni visszaállítás-tesztet, és amikor elővettem a korábbi jegyzeteimet, ott vigyorgott az egyikben a kiemelés:

If the SCR source is a clustered mailbox server (CMS) in a CCR environment, the log truncation logic includes successfully copying and inspecting the log files by all SCR targets. This means that if an SCR target is not available, log truncation does not occur on the SCR source even if backups are taken.
http://technet.microsoft.com/en-us/library/bb676465(EXCHG.80).aspx

2010 CAS NLB

Véleményem szerint Exchange 2010 HA témakörben a legforróbb terület jelenleg a CAS NLB: egyszerűen szükség van rá, nem lehet megkerülni – viszont igazán optimális megoldás nem létezik.

Ezt írtam itt. És szemmel láthatóan nem csak engem zavar a dolog. Egy MVP kolléga ki is fakadt a blogján – segítve rajtam, mert így nem nekem kellett megírnom a cikket.

Lehet egy node-dal több?

Scott Schnoll Exchange 2010 High Availability (HA) előadása után gondolkodtam el néhány dolgon. Van ugyanis egy olyan HA matek, amellyel eddig egy Exchange mérnök még nemigen találkozott.

Történelmileg volt ugye az SCC, azaz a Single Copy Cluster. Ez viszonylag egyszerűen nézett ki, volt egy közös diszk – rajta a quorummal – aztán voltak a node-ok, ha jól emlékszem, maximum négy. (Nem néztem utána, annyira nem is lényeges most a pontos szám. A gyakorlatban én eddig maximum 3 node-ra épülő clusterrel találkoztam.) Hogyan nézett itt ki a HA?

  • Ha kidőlt a közös diszk, vagy akár csak a közös diszken lévő quorum, akkor összedőlt a cluster is. (Hányszor hallottam már olyanról, hogy valaki megörült, hogy milyen sok hely van a Q: meghajtón és elkezdett fájlokat másolni rá. Aztán amikor megtelt és lehalt a cluster, akkor meg volt csodálkozás.)
  • Ha node dőlt ki, akkor amíg volt másik node, addig nem volt baj. A cluster működéséhez elég a diszk (quorum+adat) és egy node.

A Windows Server 2003 SP1 után kijött egy patch, mellyel a termék már ismerte a File Share Witness technikát. Ez volt az első lépés a demokrácia irányába. A Windows 2008 Server ezt már helyből tudja, sőt ki is bővítette – de erről majd később.

Az Exchange természetesen igyekezett kihasználni az új játékszert. Az FSW megteremtette a lehetőséget a logshipping elven működő clusterezési technikák előtt. Pontosabban, a logshipping lokális és standby módban megy mindenféle clusterezés nélkül, csak a CCR-hez kell az FSW. De ahhoz nagyon.
Igaz, ez azért elég korlátozott rendszer. Például maximálisan két node lehet. Azaz ha van egy FSW és a két node, akkor kapunk egy három komponensből álló rendszert, ahol kettőnek mindig működnie kell, hogy a rendszer egésze is működjön.
Vegyük észre, hogy mekkora különbség ez az SCC-hez képest. Ott ugyanis a qourumnak mindenképpen működnie kellett. Itt már csak egy szavazásra egyszerűsödött le a helyzet: a játékosok felénél többnek (min. 50.000000001%) élnie kell ahhoz, hogy a cluster működjön.

Exchange 2010-et már csak Windows Server 2008-ra telepíthetünk. Csakhogy itt már nem csak egy szimpla FSW van a spájzban, hanem jóval több alapanyagból főzhetünk.

  1. Node Majority
    Csak a node-ok játszanak, más nem. Ha a felénél több él, akkor működik a cluster.
  2. Node and Disk Majority
    Bejön a képbe egy ún. witness disk. Ez az a merevlemez, amelyiken a quorum található. Innentől kezdve a játékosok száma megnő eggyel.
  3. Node and File Share Majority
    Ez a korábbi FSW. A quorum nem diszken lakik, hanem kikerül egy megosztásba és ez a megosztás (witness share) is belép a játékosok közé.
  4. No Majority
    Gyakorlatilag a korábbi SCC modell. A quorum diszk az adu ász, mely mindent visz.

És mindemellett a node-ok száma maximum 16 lehet.

Lássuk, mi jön ki ezekből az alapanyagokból.

Az Exchange 2010-ben a quorum diszket, mint olyat, kidobták. Így a négy lehetőségből rögtön kiesik kettő, marad az 1 és a 3.
Nagy kérdés, hogy ezek közül mikor és melyiket alkalmazzuk? A válasz az, hogy felejtsük el. Egész egyszerűen ezt nem mi fogjuk eldönteni.

Miért?
Elmagyarázom.

Legyünk egy izgága Exchange rendszergazdák. Éppen most döntötte el a cég, hogy a magas rendelkezésreállású Exchange 2007 CCR rendszert lecseréli egy szintén magas – sőt, ha lehet, akkor még magasabb – rendelkezésreállású Exchange 2010 rendszerre. Rutinból elkezdünk rajzolni: akkor lesz egy FSW a Hub Transport szerveren és – mivel itt már lehet – legyen akkor 3 node. Mert minél több node, annál nagyobb a biztonság. Megtervezzük. Megcsináljuk. Üzemel.
Aztán egyik nap kidől az egyik node. A szempillánk sem rebben. Éppen a darabokra szerelt gépben turkálunk, amikor valaki véletlenül kirúgja a másik node 220-as csatlakozóját a falból. Csak kacagunk rajta. Egészen addig, míg egy óra múlva munkakönyvvel a zsebünkben repülünk kifelé az ablakon.

Mi is történt?

Van négy játékos: 3 node és 1 FSW. Kidől egy node. Megvan a többség? 3:1, azaz igen. Kidől még egy. Most megvan? 2:2. Mennyinek kell lennie a többségnek? Min. 50.000000001%-nak. Ez bizony nincs meg.
Azaz vetettünk a céggel még egy plusz vasat súlyos milliókért és egy fikarcnyival sem lett megbízhatóbb a rendszerünk – hiszen ha belegondolunk, a 2 node + 1 FSW rendszer is pont egy node kiesést bírt el. Mindezt wálság idején. Nyilván kirúgtak.

Következő munkahelyünkön egyszer csak azt a feladatot kapjuk, hogy bíráljuk el egy külső konzulens ajánlatát. Átfutjuk és egyből kiszúrjuk, hogy az illető úgy képzelte el a magas rendelkezésre állású Exchange 2010 rendszert, hogy abban 3 node van.
– Hah! – rontunk be Vezérigazgató Bálinthoz – Ez a konzulens egy idióta sarlatán! Abszolút felesleges pazarlás 3 node-ból álló clustert tenni az Exchange 2010 alá!

Ezzel rögtön két hibát követtünk el. Egyrészt nem tudtuk, hogy a konzulens a vezérigazgató unokaöccse. Másrészt szembesítés után a konzulens higgadtan, okosan elmagyarázza, hogy ő úgy képzelte, miszerint az Exchange cluster Node Majority quorum modellt használna, azaz a négy játékos közül az FSW-t hagyná el. A plusz node-nak pedig nem a node szintű redundancianövelés a célja, hanem az adatbázis szintű redundanciáé. Ráadásul ha 3 node-ot használ, akkor nem kell méregdrága (DAS) diszktömb a node-ok mellé, hanem egyszerű, RAID vezérlő nélküli vincseszterek is megteszik, melyeket itt lent a Közértben lehet venni kilóra. Ezzel nem csak ezt érik el, hogy a 3 node olcsóbb lesz, mint a kettő(1), hanem sokkal olcsóbbak lesznek a későbbi bővítési lehetőségek is, feltéve, hogy a Közértben nem fogy el a lemez.

Ezek után Bálint bólint – és már megint repülünk.

Nos, pont azért, hogy ne rúgjanak ki olyan sok Exchange rendszergazdát, a fejlesztők úgy döntöttek, hogy kiveszik a döntést a humanoidok kezéből. Amikor összerakunk egy DAG-ot, akkor páratlan számú node esetén automatikusan Node Majority tipusú cluster jön létre, páros számú node esetén pedig Node and File Share Majority tipusú. Természetesen a váltás dinamikus, ahogy bővítem vagy szűkítem a DAG-ot, úgy változik automatikusan a modell is.

(1) Természetesen ez csak nagy adatbázisok esetében igaz. De mikor nem nagy egy Exchange adatbázis? Különösen akkor, ha az Exchange 2010-ben levették róluk a féket és azt mondták a postafiókoknak, hogy szaporodjatok, sokasodjatok és töltsétek be a Földet?

Megyen a log vándorútra

Nagyjából éppen a bokáig érő lószarban sárban cuppogtam Moritzburg környékén, amikor egyik ügyfelünk nem kicsit bonyolult Exchange mailbox szervere úgy döntött, hogy torkonszúrja magát. No nem nagyon, de két mailbox adatbázis és a public folder adatbázis leállt. Kolléga rávetődött az incidensre. Hamar rájött, hogy a leállást az okozta, hogy betelt egy log partíció. Egy olyan partíció, ahová ez a 3 adatbázis dolgozott.

Kitérő:

Igen, ilyet teljesítményproblémák miatt nem szoktak csinálni. Csakhogy egész egyszerűen az ügyfélnél annyi adatbázis van, hogy nincs annyi betű az angol ABC-ben, hogy minden log könyvtárhoz külön partíciót rendeljünk. Így a 3 legritkábban használt, legkisebb adatbázis log fájljait egy partícióra tettük.

Nos, a két pici mailbox adatbázisból az egyik bevadult. Nem, nem a korábbi bevadulás, ennek üzleti okai voltak. A vadulás miatt elszabadultak a logfájlok, betelt a partíció, méghozzá olyan gyorsan, hogy a riasztás után már cselekedni sem maradt időnk – aztán leállt mindhárom adatbázis.

Kitérő:

Maga az Exchange mailbox rendszer a következőképpen nézett ki: CCR rendszer egy aktív és egy passzív node-dal, melyhez kapcsolódott egy SCR rendszer egy passzív node-dal.

Tehát ez volt a játszótér és adott volt a feladat. Az ügyfél nyilván ki volt kattanva, hiszen mi az, hogy egy ilyen bonyolult cluster elérhetetlenné válik – és természetesen azt várta el, hogy minél hamarabb megint elérhetőek legyenek az adatbázisok. Kolléga fogta, és a CCR mindkét node-ján elmásolta ugyanazt a nagy kupac régi – ergo már biztosan rájátszott – logot mind a public folder, mind a bevadult adatbázis logkönyvtárából, felmountolta az adatbázisokat és minden be is indult szépen. Az adatbázisok működtek, sőt, a konzol alapján a log replikáció is egészséges volt. Problem solved.

Egészen addig mindenki nyugodt volt, amíg el nem érkezett a mentés ideje. De elérkezett. Le is ment – majdnem minden adatbázisra. Egy, csak egy szaladt hibára, az a bizonyos vad adatbázis. Mely ugye nem véletlenül vadult be, a hirtelen megnövekedett üzleti igények okozták a hízást – azaz meglehetősen fontos adatok kerültek az adatbázisba.

Kolléga még megnézte az eseutil /mh paranccsal, hogy konkrétan milyen log fájlok hiányoznak a passzív node-on – de a válasz az volt, hogy semmi. Rá lett küldve egy reseed (update-storagegroupcopy), de csak annyit csinált, hogy a passzív node-on kiürült a logkönyvtár.

Ekkor érkeztem vissza szabadságról és rögtön meg is kaptam a feladatot.

Helyzetfelmérés:

  • Az adatbázis megy, ránézésre a log replikáció egészséges, az ügyfél nyugodt.
  • Ezzel szemben az aktív node-on rengeteg log van, a passzív node-on egy sem. Az adatbázisok azonos méretűek, azaz a reseeding sikerült.
  • Az SCR node-on az a bizonyos partíció fullon volt, a replikáció az említett adatbázisokon állt. Szemmel láthatóan az SCR-rel senki sem foglalkozott.
  • Viszont mivel nem sikerült a mentés, az aktív node-on pár óra múlva megint elfogy a hely, szóval nagyon gyorsan ki kell találni valamit.

Ergo egyfelől meg kellett akadályoznom az újabb leállást, másfelől össze kellett kötözgetnem a szálakat, mert itt valami nagyon félrement.

A feladat első része volt az egyszerűbb. Kerestem egy üres partíciót (későbbi fejlesztésekre volt is félrerakva egy, de a későbbi szó pont azt jelenti ugye, hogy nem mostani), majd átirányítottam ide a logolást.
Ránézésre olyan egyszerűnek és logikusnak tűnik – de nem az. Nem véletlen, hogy a kollégám sem így próbálkozott. Neki ugyanis sietnie kellett.
Első lépésben ugyanis suspendbe kell rakni a log replikációt. Ez még nem is fáj.
Második lépésben dismountolni kell az adatbázist, ráadásul bizonytalan ideig. Ez már fájt az ügyfélnek, nem is mentek bele szó nélkül. Amikor közöltem velük, hogy ez van, törődjenek bele, nincs más lehetőség, rögtön jöttek, hogy bezzeg a kollégám meg tudta oldani máshogyan. Na, ez a szakma kellemetlen része. Elmagyarázni az ügyfélnek a szakmai finomságokat, úgy, hogy közben a mundér becsületét is megvédjük. Végül azért sikerült tisztáznom, hogy a múltkori az egy gyors, ideiglenes megoldás volt, én viszont már a végleges megoldáson dolgozom.
Ha ezzel megvagyunk, akkor jön a move-storagegrouppath parancs, valahogy így:

move-StorageGroupPath -Identity ‘adatbázis‘ -LogFolderPath ‘ujlogkonyvtar‘ -SystemFolderPath ‘ujsystemkonyvtar‘ -configurationonly

Vagy hogy érthetőbb legyen, konkrét példával:

move-StorageGroupPath -Identity ‘server\vad-adatbazis’ -LogFolderPath ‘Z:\exchsrvr\log’ -SystemFolderPath ‘Z:\exchsrvr\log’ -configurationonly

Határozottan felhívom a figyelmet a configurationonly paraméterre! CCR környezetben a logkönyvtárt ugyanis nem lehet csak úgy átrakni. A parancs hatására a következők történnek:

  • Az AD konfigurációs névterében az érintett storage group tulajdonságainál átíródnak a log, illetve system könyvtárak útvonalai.
  • Emellett az új könyvtár (z:\exchsrvr\log) meg lesz osztva, méghozzá egy GUID névvel. Ha visszanézzük, akkor ez a GUID a storage group azonosítója. A megfelelő jogosultságokat szintén beállítja a parancs.

Végül ha ezen túlvagyunk, akkor manuálisan átmásoljuk a lecsatolt adatbázis log és system fájljait a régi helyről az újra, majd felmountoljuk az adatbázist. Ha nem rontottunk semmit el, akkor el is indul.
Látjuk, az időbeli bizonytalanságot a logfájlok másolása jelenti. Viszont amíg a másolás folyik, addig szét is tud replikálódni a címtárban a változás.

Ezzel a sürgős résszel meg is volnánk, jöhet a kötözgetés.

A biztonság kedvéért ráküldtem én is egy reseedet. Hátha apucitól jobban elfogadja. De semmi. Vágjunk mélyebbre. Újraindítottam a passzív node-on a replikációs szolgáltatást.
És végre történt valami. A replikáció státusza elmozdult az egészséges állapotból. Initializing. A végtelenségig. Vártam rá egy kicsit, aztán eluntam. Ennél még a kamu egészséges visszajelzés is jobb volt. Újabb reseed.

Jobb híján nézelődtem, gondolkodtam. A log könyvtár átmozgatása rendberakta az SCR-t, tökéletesen működik. Azért ez is valami: van egy aktív CCR node-om és egy passzív SCR node-om.
Aztán egy kellemetlen gondolat. Eddig azt mondtam, hogy a logfájlok másolása sértett meg valami ismeretlen dolgot az Exchange rejtett mélységeinek szövetében. De akkor a public folder adatbázisok logshipping folyamatának sem kellene működnie. Aztán mégis működik.
Hjaj. De bonyolult az élet.

Get-storagegroupcopystatus. Mindenki healthy. Egészségükre. Aztán hoppá. A CopyQueueLength értéke a vad adatbázisnál 14234. Mit ír erről a manuál? Azt, hogy ha az értéke nagyobb 3-nál, akkor baj van. Hmm. Ide azért most nem kell fejszámolóművész, itt baj van.

Test-replicationhealth. Minden passed – kivéve a vad adatbázis copy queue értéke. Az viszont nagyon nem.

További nézegetés. Hoppá. Nincs a passzív node-on edb.chk. Ezt azért volt nehéz észrevenni, mert abszolút nincs semmi más sem a könyvtárban. Ez azért magyarázza, miért nem ment le a mentés. (Akinek újdonság lenne: az Exchange az edb.chk fájlba írja, melyik lognál indult a mentés, azaz a mentés után meddig kell törölni a logokat.) Lehetséges, hogy nem csak a backup használja ezt, hanem a log replikáció is? Nagyon lehet, hiszen egy normális reseed úgy indul, hogy törli az edb.chk-t és az adatbázist.
Akkor lehet, hogy nem is jó a látszólag jó reseed?

Mint az ínyenc, aki a legfinomabb falatokat a végére hagyja, én is elővettem végül az event logot. Volt is benne érdekesség.

Nagyítás

Ez legalább világos beszéd, végre. Habár az eseutil /mh szerint nem hiányzik neki logfájl, de az eventlog szerint mégis hiányzik a 84679-es számú. (Azért ezen ne lepődjünk meg. Az eseutil csak az adatbázis épségével foglalkozik – és az adatbázisok tökéletesen jók. Itt a logshipping szakadt össze, de ahhoz az eseutil meg nem ért.) Természetesen ilyen nevű logfájl nincsen. De ennyi szívás után az ember már csak legyint és átszámol hexába: 14AC7. Ilyen nevű log már lehet. De hol? Hát például a kolléga által félrementett logok között, melyeket szerencsére nem töröltünk.
Mi lenne, ha bemásolnám az aktív node logkönyvtárába?
Bemásoltam. Egy perc focilabda rugdosás (az új irodámban nincs darts tábla) – és ott van a log a passzív node-on is. Vérszem. Az az, amit kaptam. Bemásoltam a sorban következő 10 logot az aktív node-ra. Egy percen belül megjelentek a passzív node-on is. Ujjé. Elkezdtem név alapján bogarászni az éles log könyvtárat és a mentett logok könyvtárát. Úgy tűnik, hogy az egyik a zsák, a másik meg a foltja. Ha a félremásolt logokat átmásolnám az éles logkönyvtárba, akkor zárt lenne a sor.

Persze ehhez több hely kell.

Újabb telefon az ügyfélnek. Leállnánk pár percre, ugye nem baj? Ügyfél füle egy kicsit rángatózik.

Átmásoltam a logokat egy nagyobb partícióra. (Igen, ez már adatbázispartíció volt. De csak a mentésig lesznek itt a logok, addig meg kibírják.)

Utána pedig megtörtént a nagy családegyesítés. Elvonultam gyakorolni a külső csavarást a nyomtató asztalának lábai közé. 20 perc műlva néztem vissza – és a logok szorgalmasan másolódtak át a passzív node-ra. Remek.

Legyen teljes a győzelem: újabb get-storagegroupcopystatus. A CopyQueueLength értéke szépen le is csökkent… de miaf… elkezdett növekedni a ReplayQueueLength értéke. Ugyan – hessegettem el a kellemetlen gondolatot – ez most kapott hirtelen 14000 logot, persze, hogy nem tudja ilyen tempóban rájátszani. Hagyjuk békén, holnap reggel majd meglátjuk, mi lesz a vége.

Eljött a holnap reggel. A győzelem érzésével gépeltem be a jó öreg get-storagegroupcopystaus parancsot – és a ReplayQueueLength értéke 500 körül volt. Az első gondolatom rögtön az volt: miért? A nullát el tudtam volna fogadni. A 14000 körüli értéket szintén. De miért pont 500?
A magyarázat gyorsan jött. Konzol, gyors vizuális pásztázás: a vad adatbázisnál a logshipping státusza failed. Aha. 500-nál besokkalt, aztán azóta coki.

Hát. Tulajdonképpen előrébb vagyunk. De a beteg még mindig kómában fekszik.

Most már nem álltam neki ködöt rágni, mentem egyből az eventlogba.

Nagyítás

Nagyítás

Keressünk rá a hibakódra. Azt írja, hogy a 1216 azt jelenti, hiányzik néhány tranzakciós log. Kérdezzem le az eseutil /mh paranccsal, mely logok hiányoznak. Lekérdeztem. Semmilyen log sem hiányzik.

Bakker. Mégis köd. Azért ez már kezd bizarrá válni: egyfelől azt mondja, hiányzik neki x darab log, ahhoz, hogy rájátssza végre az összes logot arra az adatbázisra, amelyikre már jó egy hete rá van játszva az összes log – másfelől pedig konkrét kérdésre azt mondja, hogy nem is hiányzik neki egy log sem.
Csak éppen nem indul el a rájátszás.

Ekkor már teli csőrrel gyakoroltam a védhetetlen bombákat a szerverszoba ajtajára.

Végül visszadaráltam az elejére. Emberek, végülis… már van edb.chk fájlunk a passzív node-on. Ez jó hír.
Töröljük gyorsan le. Azaz küldjünk rá egy reseed-et. Mert mi van, ha az a baj, hogy az adatbázis – amelyikre már rá van játszva minden log – nincs szinkronban a logkönyvtárban lévő edb.chk-val, mely még csak nemrég jött létre, a replikáció befejeztével. A reseed ugyanis törli mindkettőt, majd újra létrehozza, immár szinkronban.

És tényleg.

A ReplayQueueLength értéke egyből lenullázódott, a logshipping meggyógyult. A pezsgőbontással vártam még tíz percet, mert ez a nyomorult replikáció képes megint elromlani – de nem.

Tanulság:

  • Amíg elő nem varázsolom valahonnan a hiányzó logokat, addig felesleges a reseed. Nincs értelme. Nincs edb.chk.
  • Ha megvannak a logfájlok, akkor vissza kell másolni az aktívra, a logshipping beindul, legyártódik az edb.chk. Ekkor viszont kötelező a reseed, mert ez hozza összhangba a két node-ot.

Végül egy kényelmetlen gondolat:

És akkor mi van, ha közben töröltem a logokat?
Nos, végső esetben az SCR-en ott kellett lenniük.
De mi van, ha onnan is töröltük? Gáz.
Szóval óvatosan azzal a közvetlen logpiszkálással.

ps.
Elkiabáltam. Utólag derült ki, hogy az SCR node-on sem megy a rájátszás, ott is újra kellett seedelni az adatbázist és a logokat.

DAG a kkv/soho szegmensnek is

Most már hivatalosan is lehet róla beszélni, meg egyébként is pont illik a sorozatba. Szóval, itt van egy link Henrik Walther blogjára: a DAG benne lesz az Exchange 2010 Standard verziójában is. (Bár gyanakvóbb olvasók már sejthették, ha máskor nem, akkor biztosan, amikor azt írtam, hogy kinyírták az LCR-t is.)

ps.
Kicsit hülye a cím, a magam részéről meglepődnék, ha egy soho cég egyáltalán birtokolna saját Exchange szervert és nem hosztolt email szolgáltatást használna.

Magas rendelkezésreállás

Az előző írásban ész nélkül beleszaladtunk a DAG-ba, pedig a magas rendelkezésreállással kapcsolatban nem csak erről van szó.

Nagyítás

Nézzük meg ezt a képet. Érdekes módon mindkét középső panelen az adatbáziskezelés a téma. A jobb szélső akciópanalen láthatjuk is, hogy melyik panelen, miket lehet csinálni.

Vajon miért lett két panelre szétbontva a munka?

Azért, mert a felső panel az organizáció szinten egyedi adatbázisokat mutatja és itt az adatbázis paramétereit lehet állítgatni. Az alsó panelen viszont a másolat adatbázisok szerepelnek – itt a replikáció paramétereit láthatjuk, ha lekérjük a tulajdonságlapot.

És ami a legszebb az egészben, az az, hogy a felső panelen láthatjuk, most éppen a Database Management tabon belül vagyunk, a DAG… az egy egészen másik tab.
?
A helyzet az, hogy adatbázisokat tükrözni, log shippinget megvalósítani tudunk DAG nélkül is. Ezt a 2007-es verzióban úgy hívták, hogy Standby Cluster Replication: egy adatbázisról tetszőlegesen sok másolat létezhetett – és ha az aktív adatbázis megsérült, vagy a szervert líbiai terroristák felrobbantották, a rendszergazda aktivizálta az egyik passzív adatbázist és az élet ment tovább.

A DAG ennél több. A DAG a Cluster Continuous Replication örököse(1). A DAG az, aki tudja az automatikus átállást.

(1) Mind a Local Continuous Replication, mind a Single Copy Cluster némán kimúltak. Nem fértek bele a koncepcióba.

Nagyítás

A képen egy csomó ismerős dolgot láthatunk: member servers, witness server, witness directory, network jellegű erőforrások. Mind-mind mutatja, hogy itt a háttérben – miután egy varázslóval gyorsan végigrohantunk a telepítésen – tulajdonképpen egy NFS tipusú failover cluster jött létre.

Nagyítás

Olyannyira, hogy a DAG látszik a Failover Cluster Management konzolból is. Bár sasszemű kollégák kiszúrhatják, hogy ez nem az igazi CCR clusterre jellemző minta, sokkal inkább az ún. standby clusterre hasonlít. (A Services and Applications folder alatt nincs semmi, pedig ott kellene vigyorognia a CMS névnek, azaz a DAG nevének. Mely azért a DNS-be bekerült.)

Nézzünk végre konkrétumokat.

Nagyítás

Az első képen egy viszonylag egyszerű DAG megvalósítást láthatunk. Két szerver – és minden megy rajta. Nem csak a Mailbox szerepkör fut rajtuk, hanem a CAS és HTS is. Korábban mi minden kellett a magas rendelkezésreállású szolgáltatáshoz? Két MBX szerver a CCR-hez, legalább egy CAS/HTS szerver a maradék Exchange funkciókhoz. 2 enterprise licensz, 1 standard. DAG esetében egy vas – licenszestől – kipottyant.

Nézzük meg jobban az ábrát. Vészcsengő kinél jelzett be? Fent a kliens, el akarja érni az adatbázis szervert… egy load balanceren keresztül?! Adatbázisszerver… NLBS mögött? Ordítóan durva hiba lenne… ha a kliens közvetlenül érné el az MBX szervereket. De az Exchange 2010 struktújában nem így megy. Stay Tuned.

Nagyítás

Ez már egy komolyabb DAG. Látható, hogy itt már leszedtük az MBX szerverekről a többi szerepkört, azok külön tömbben feszítenek az MBX szerverek előtt.
Két dolgot kell nagyon észrevenni az ábrán. Az egyik az MBX szerverek száma. Emlékszünk, CCR esetén két node volt. Snitt. SCR szervert akármennyit tehettünk mellé, de CCR-t nem. Ez a korlát immár a múlté – jelenleg 16 szerver a limit. A DAG-ban – hasonlóan a CCR-hez – nem feltétel, hogy a node-ok egy telephelyen legyenek. (Az egy Exchange organizáció viszont igen.) Egy hardverkövetelményt viszont kegyetlenül be kell tartani: a telephelyek közötti késleltetés nem lehet nagyobb 250 miliszekundumnál.
A másik: az aktív és passzív adatbázisok mellett feltűntek a Lagged adatbázisok is. Ez meg mi? Aki játszott már komolyabban SCR rendszerekkel, annak számára nem ismeretlen a fogalom. Ott ugyanis külön szabályozhatjuk, hogy a passzív adatbázisra mennyi kivárással (lag) játszódjon rá a log, illetve a rájátszás után mennyi idő múlva törlődjön fizikailag.
Mire is jó ez? Nos, nem árulok el nagy titkot, ha azt mondom, hogy az Exchange fiúk határozottan utálják a backup/restore eszközöket. Igyekeznek is bedobni minden trükköt, hogy kiváltsák ezeket. (Szvsz nem fog sikerülni.) A lagged adatbázis az egyik ilyen trükk. Amíg nem játszatom rá a logokat az adatbázisra, addig az az adatbázis a múltat mutatja. A maximális kivárás 14 nap. Tudom, most azt kérdezed, hogy és akkor mi van a dumpsterrel? Az is van. De. A dumpster a kuka. Ahová a törölt elemek kerülnek – és ahonnan azok egy bizonyos ideig még előbányászhatóak. (Jut eszembe, kuka ügyben is történtek komoly előrelépések.) De mi van, ha nem törlés jellegű adatmódosítás történt? Teszem azt, Vezérigazgató Árpád vett a lengyel piacon egy kínai e-book readert és amikor összeszinkronizálta az Exchange szerverrel, akkor felülírta az összes kontakját mandarin karakterekkel? Törlés nem történt, kritikus adatmódosítás igen. Ilyenkor jöhet a talonban őrizgetett lagged adatbázis.

Foglaljuk össze, akkor HA téren mik is a fejlemények:

  • Nem kell drága hardver. Nincs szükség közös háttértárolóra, nincs szükség SAN-ra. Bele kell lapátolni egy jó nagy kupac merevlemezt a gépbe (JBOD) vagy hozzákapcsolni egy diszktornyot (DAS), oszt jól van. Sima SATA2-es lemezek is bőven megteszik.
  • Olcsó elemekből, a mennyiség növelésével érünk el nagy megbízhatóságot. Ez az álmoskönyv szerint is jó skálázhatóságot jelent.
  • A redundancia adatbázis szinten szabályozható.
  • Tulajdonképpen az SCR/CCR rendszerek kombinációit használjuk, úgy, hogy a részletekkel nem kell foglalkoznunk(2).

(2) Tudom, te is olyan vagy, aki szeret a részletekkel foglalkozni. De nem mindenki ilyen.

DAG

_Nem_ csak azért ez a kedvenc témaköröm, mert a kajakomnak is ugyanez a neve. 🙂
A magam részéről tényleg ezt tartom az egyik legjelentősebb architekturális változásnak.

DAG: Database Availability Group. Azaz magas rendelkezésreállás, Exchange módra.

De beszéljünk előbb egy kicsit az Exchange 4.0-ról.
Abban ugyanis olyasmi van, ami az Exchange 2010-ben már nincs.
Storage Group.

Hogyan lett ez a szegény SG kegyvesztett? Bár pontosabb lenne a kérdés, hogy hogyan is lett ez ennyire kegyelt?

Tények jönnek.

  • Egy merevlemezre a folyamatos írás sokkal-sokkal gyorsabb, mint a kevert írás/olvasás. Az írás ugyanis sorfolytonos, míg az olvasás véletlenszerű fejmozgással jár.
  • A tranzakció alapú adatbáziskezelés során a logfájlokba gyakorlatilag folyamatos írás történik, minimális olvasással.

Tehát olyan helyeken, ahol alaposan megtervezték az Exchange környezetet és fektettek hangsúlyt a sebességoptimalizálásra is, ott célszerűen az adatbázisokat egy magas rendelkezésreállású diszktömbre tették, a tranzakciós logokat pedig – logonként – külön vincseszterre, illetve tükörre.
Hogyan is nézett volna ki ez konkrétan? Ahány adatbázis, annyi tranzakciós log, azaz annyi merevlemez. Annyi kártya vagy annyi LUN. Ráadásul ezek a logok nem igényeltek ám olyan nagy helyeket, miközben a vásárolható merevlemezek alsó kapacitása folyamatosan kúszott felfelé. És – bármennyire pitiánernek is tűnik első látásra – de az angol ABC betűinek a száma véges. 20 használható betűm van. (Ez mondjuk a 2007-esig még nem okozott gondot.)

A fentiek miatt találták ki a Storage Group fogalmát. Gyakorlatilag az történt, hogy több adatbázis kezelését vonták úgy össze, hogy egy tranzakciós log tartozzon hozzájuk. Ez már mehetett külön vincseszterre.

Az elv működött is szépen, egészen a 2007-es Exchange feltűnéséig. Ebben a termékben jelentek meg a különböző szines-szagos CR technológiák és kavarták meg rendesen az állóvizet. Mindegyik szép is jó is, hasznosak, praktikusak… csak éppen van egy apró hátulütőjük: csak akkor működnek, ha egy Storage Groupban egy, azaz maximum egy adatbázis található.
Az Exchange 2007-ben még volt annyi játékterünk, hogy eldönthettük, használunk-e CR-t, vagy sem. Bár sok érv nem szólt amellett, hogy ne használjunk, de még választhattunk.
Ezt a lehetőséget műtötték ki a 2010-ből. Függetlenül attól, hogy kell-e CR technológia – aka logshipping -vagy sem. Innentől már csak egy adatbázis lehet egy Storage Groupban. Így viszont nincs értelme magának az SG-nek sem… azaz kikukázták.

De nem csak ennyi történt. A hierarchia csökkenhetett volna úgyis egy szintet, hogy az adatbázisok továbbra is szerverekhez kötődnek – de ha már vágtak, akkor rendeset vágtak. Az adatbázisok a továbbiakban az organizációhoz kötődnek – azaz organizáció szinten kell egyedi névvel bírniuk -, a szervereken immár csak tartózkodási preferenciájuk lesz. Azaz amennyiben létrehozunk egy DAG-ot, akkor az abban szereplő adatbázisoknál adhatjuk meg, hogy a körbe bevont szerverek közül melyiken milyen preferenciával tartózkodjanak. (Értelemszerűen a DAG-on belül mindegyik adatbázis példányai között log shipping kapcsolat alakul ki.)

Anélkül, hogy elmerülnénk – egyelőre – a technikai mélységekbe, az elv megértése végett nézzünk most végig egy sorozatot.

Nagyítás

Létrehoztunk egy DAG-ot. Van hozzá öt szerverem, öt adatbázisom. Szerverenként három adatbázist kezelek. A prioritásokat a sorok jelentik, nyilván az első sor jelenti az aktív adatbázis példányokat.

Nagyítás

Patch kedd. Lekapcsoljuk a 2-es szervert, és vadul nekiállunk foltozni. Látható, hogy a DB4, mely korábban ezen a szerveren volt aktív, most az 5-ös szerverre mászott át. A DB5, DB1 adatbázisokkal nincs semmi dolgunk, azoknak továbbra is működik az aktív példányuk.

Nagyítás

A takarítónő bevonul a szerverszobába és porszívózni akar. Kihúzza az egyik rack-et a konnektorból – és leáll a 3-as szerver is. Mit veszünk észre ebből? A DB2 immár az 1-es szerveren lett aktív, a DB3-nak és a DB4-nek még van aktív példánya. Igaz, a DB4-nek viszont már nincs passzív példánya.
A takarítónő pedig fütyürészve tolja a porszívó csövét.

Nagyítás

Befejeztük a hotfixek felrakását, visszaindítottuk a szervert. Az adatbázisok soványmalacvágtában tolják vissza a menetközben keletkezett logokat, majd ha ez megtörténik, a 2-es szerveren lévő DB4 aktívvá válik.

Nagyítás

A takker is befejezte a munkát, visszadugja a rack konnektorát, a helyi emberünk megkapta a riasztást, kisétál, visszakapcsolja a szervert. Az előző fázishoz hasonlóan itt is beindul a logok másolása, egészen addig, amíg ki nem alakul a kavarások előtti helyzet.

Mit vettek ebből észre a felhasználók? Gyakorlatilag semmit. Mindig volt valahol aktív adatbázisuk. (Hogy a váltásokat hogyan vészelték át szakadás nélkül? Erre később fogok kitérni.)

Bizonytalan vagyok. Vagy nem?

Van egy CCR rendszerem, rengeteg adatbázissal. A hiba: az egyik adatbázis nem mountolható. A copy status: initalizing.
Vizuális vizsgálat: az adatbázis is, a logfájlok is szépen a helyükön vannak. Átnéztem a passzív node-ra… ott is.

Oké, mountoljuk fel. Nem megy, kiírja, hogy hiányzik neki egy logfájl. Nem mondom, hogy a popsimat vertem földhöz örömömben, de éreztem egy kis kellemes bizsergést. Itt van, végre élesben is ki lehet próbálni, mit ér a CCR. Az update-storagegroupcopy parancsot használtam már annyit a passzív node-on, hogy unom – ezzel szemben most van lehetőségem először alkalmazni a restore-storagegroupcopy parancsot az aktív node-on.

Azt írta ki, hogy ‘database was already marked as available for a mount, no action was taken‘. Azaz szerinte minden frankó, ez egy mountolható adatbázis.
Még egyszer megnéztem a passzív node-ot, megvolt az adatbázisról és a logfájlokról a replika. Oké. Fogtam, kitöröltem az aktív node-on az adatbázist.
Na, erre legyen bőr a képeden azt mondani, hogy mountolható!

Azt mondta.

Letöröltem az összes logfájlt is. Újabb restore. Megint azt mondta, hogy minden rendben, ez egy mountolható adatbázis. Miközben se adatbázis nem volt a partíción, se egy nyomoronc logfájl.
Irígyeltem az optimizmusát.

Futottam még egy bátortalan kört, hogyan lehetne _mindenképpen_ ráfuttatni a restore parancsot… de nem lehet. A -force kapcsoló sajnos nem ezt jelenti.
Törődjünk bele, ha az Exchange úgy gondolja, hogy minden rendben, akkor nincs visszaállítási lehetőséged. Még akkor sem, ha tokkal-vonóval hiányzik az egész adatbázis.

Nyilván a körbedolgozás működött. Elindítottam egy failovert, a korábbi passzív node-on ezután már felállt a problémás adatbázis, fel is lehetett mountolni. Ekkor a korábbi aktív node-on, mely most ugye már passzív lett, ki lehetett adni az update-storagegroupcopy parancsot, melynek van egy bűvös -deletexistingfiles kapcsolója. Na, ez képes gyökeresen elrendezni a terepet, csak a sávszélesség bírja.
Aztán jöhetett egy failback, és újra minden rendben.

Database Availability Group

Egy kicsit felpezsdült az élet, ahogy kijött az Exchange 2010 béta. Szép lassan körbe is lehet járni az újdonságait.

Kezdem a DAG-gal, mert számomra ez jelenti a legnagyobb strukturális változást.

Régebben voltak ugye az adatbázisok, ezek storage groupokban helyezkedtek el, a tranzakciós logok pedig SG-khez voltak rendelve. Az adatbázisok és a storage group-ok nevei szerverszinten kellett, hogy egyediek legyenek. (Ugye, a sok Mailbox Database a First Storage Group-ban.)
A magas rendelkezésre állást SG, illetve szerverszinten valósítottuk meg, attól függően, hogy melyik technológiát használtuk. Az adatbázisok ettől még konkrétan szerverekhez tartoztak, ha egy SCR failover miatt váltanunk kellett, akkor át kellett ‘home’-olni a felhasználókat a másik szerverre. (Ez az aktív-aktív jellegű SCR-re vonatkozik.)

Exchange 2010-ben némileg megváltoztak a dolgok. Például tokkal-vonóval ki lett dobva a Storage Group fogalom. Az adatbázisok pőrén léteznek a szervereken. A tranzakciós logok szerverekhez rendeltek, de adatbázis szintűek. (Igen, ez nekem is zavaros egy kicsit, de egyelőre a részletekről nincs túl sok infó.)
Értelemszerűen a redundancia is adatbázis szintű. Ez a DAG.

Kezdjük ott, hogy feltelepítünk egy Exchange 2010 szervert, értelemszerűen – a DAG miatt – Windows Server 2008 Enterprise szerverre. Magát a Failover Cluster szolgáltatást nem is kell telepíteni. Később feltelepítünk egy másik szervert, hasonló felállásban. Az első alkalommal, amikor azt mondjuk, hogy és most szeretnénk egy DAG-ot erre a két szerverre, akkor a Failover Cluster szolgáltatás automatikusan települ, anélkül, hogy külön értesítene minket. Nincs lehetőségünk, hogy nekiálljunk válogatni, CCR vagy SCR technikát szeretnénk. Maga a technológia bekerült a motortérbe, a vezetőülésből már nem látjuk.

A mi dolgunk az lesz, hogy meghatározzuk, hogyan oszoljanak el az adatbázisaink a DAG-ban. Melyikből legyen másolat a másik szerveren? (Több szerver esetén nyilván ennél bonyolultabb figurákat is össze tudunk rakni.) Illetve azt is meg tudjuk adni, hogy a felhasználók mely adatbázisokat milyen prioritással használjanak.

Kíváncsi vagyok, kinél csengetett a vészcsengő? Több szerver? Hiszen eddig a CCR két szerverre korlátozódott? Immár nem.

Folytassuk. Az gondolom látszik, hogy ebbe a struktúrába a hagyományos SCC cluster nem fog beleférni. Béke poraira. Az Exchange 2010 már nem fogja támogatni.

Jó hír a kisebb cégeknek. Immár a magas rendelkezésre állás nem zárja ki azt, hogy más szerepkör is rákerüljön a Mailbox szerverre. Szabad a pálya – így gyakorlatilag két szerverrel megoldható minden.

Logikus következmény, hogy DAG esetén az adatbázisokat már nem szerverhez kell rendelnünk, hanem organizációhoz. Hiszen már több szerveren is előfordulhat. Ebből következően az adatbázis nevének organizáció szinten kell egyedinek lennie.

Létezik egy olyan tendencia az Exchange fejlesztői csapatban, melyet úgy neveznek: Backupless Configuration. Azaz az Exchange szabadulni akar a backup/restore mocsárból. A DAG ebben is nagyot segít, hiszen azzal, hogy több szerveren is megtalálható ugyanannak az adatbázisnak ugyanolyan változatú példánya, az adatvesztés meglehetős nagy eséllyel kizárható. Oké, mondhatnád, de mi van akkor, ha valaki töröl egy elemet, majd később azt kell visszaállítani? Nos, lehetőségünk van késleltetésre is. Ez azt jelenti, hogy megadhatjuk egy DAG-on belül, hogy egy istenhátamögötti, alacsony prioritású adatbázisra a logok csak bizonyos késéssel játszódjanak rá. A késleltetés maximális értéke 14 nap. (Ehhez kell még hozzáadni azt az időt, melyet a Dumpster nyújt.)

Megjegyzés:
Maradjunk annyiban, hogy ezen a téren szkeptikus vagyok. Nagyon. Sok cégnél éveken átnyúló archiválási előírások vannak. Oké, hogy az Archive Mailbox (AMBX) ezen sokat fog segíteni (persze merevlemezterület beáldozásával, szalagra ugye nem tud dolgozni), de mi van, hogyha valaki ebből az AMBX postaládából töröl ki mondjuk egy egyéves levelet? Nem mondhatjuk azt, hogy ‘márpedig ilyen nálunk nem fog előfordulni’. Érzem az Exchange csapat erőfeszítéseit, a lehetőségek 90-95%-át már le is tudták fedni – de a levelek visszakereshetőségének a megadott intervallumra kötelezően 100%-osnak kell lennie. Más nem fogadható el, még a kis cégeknél sem.

Vissza a DAG-hoz. Van-e valamilyen megkötés a két szerver elérhetőségére nézve?
Van. Mindkettőnek azonos címtárban kell lennie. (Nyilván az azonos organizáció a fő követelmény.) Ezen belül a szerverek tetszőleges AD site-on, tetszőleges alhálózaton lehetnek – egy követelmény létezik csak: a szerverek közti késleltetés nem lehet nagyobb, mint 250 ms.

Az írás végére néhány link:

Adide, nemadom

Na, kérem, itt van a magyarázat ahhoz, ami miatt pár nappal ezelőtt csak kapkodtam a levegőt.

Nemrégiben jött ki az Exchange 2007 SP1 termékhez a Rollup Pack 5. (Csak gondoljunk bele… az SP1 előtt volt megint 5 Rollup Pack… és mindegyik megváltoztatta a termék viselkedését… nem könnyű ám Exchange adminnak lenni.)

Nos, az egyik hiba, melyet a csomag javított, így szólt: CCR vagy SCC clusterben megvalósított Mailbox szerveren nem működött a GAL disztribúció, amennyiben Outlook 2007 kliensről próbálkoztunk.
Ránézésre nem olyan vészes, pedig de. Összeraksz kemény munkával egy clustert, jön egy felhasználó Outlook 2007-tel – annyira azért már nem ritka jószág – és nem lát címlistát.

Eddig nem lehetett sokat tudni arról, mi is okozta a hibát – de Dave Goldmann nemrég írt egy cikket. Most már tudjuk. Most már verjük a fejünket a falba. Velük együtt. Annyira idióta hibáról van szó, hogy tényleg nem értem, hogyan kerülhetett bele a rendszerbe.

Nem húzom tovább az időt, itt a magyarázat: az OABGen process a \\gepnev\ExchangeOAB könyvtárba tette le a legenerált xml fájlt, mint ahogy mindig is szokta. A CAS szerver viszont nem ott kereste, mert ő hogyan is látja a clustert? A virtuális Exchange szerver nevén keresztül. Azaz a CAS a \\CMS\ExchangeOAB megosztást kereste, nem találta, tehát az OAB weblapon nem is tudott publikálni semmit.

Függöny.

Vazze

Tudod, én igazán szeretem az Exchange szervert, mint terméket. De időnként komolyan fel tud bosszantani.

Nem, ezek nem az én szavaim. Nekem sokkal durvábbak csúsztak ki a számon, amikor hasonló problémába futottam bele, mint Jim McBee.

Már a W2k8 NFSM cluster is megdolgoztatott, mire minden stimmelt. Hol ez nem volt, hol az viselkedett teljesen máshogy… és persze örök kedvencem, az a nyomorult Internet Explorer a nyomorult fokozott biztonságával. De végül összeállt minden, jöhetett az Exchange cluster. CAS és HTS szerver már duruzsolt a hálózatban, tehát megágyazva már meg volt rendesen. Kell is, mert a legtöbb baj mindig a Mailbox szerverrel van – érdemes előtte az összes egyéb szerepkört pöpecül belőni.

Kíváncsi vagyok, ha feltenném a kérdést, vajon szerintetek egy Exchange 2003 – Exchange 2007 átállásnak mi a legkritikusabb része, mit válaszolnátok? Én már a másodikat csinálom élesben, nagy ügyfélnél – és van egy pont, ahol mindig elhasalunk, ahol garantáltan behal a telepítés és mely után lehet a félbehagyott telepítés szutykait kivakarni és reménykedni, hogy a következő telepítést nem fogják a romok bezavarni. A címtárról nem is beszélve.

Mik ezek a félelmetes, bonyolult dolgok? A címlisták és a recipient policy-k. Nem gondoltad volna, mi? Hiszen nem is néznek ki olyan veszélyesen. De annak az embernek a kezét, aki ezt a setup darabot leprogramozta, beledugnám könyékig annak a seggébe, aki ezt a folyamatot megtervezte, és vica-versa – majd kiakasztanám őket a Nagykörútra karácsonyi dísznek, egy szál mikulássapkában.

Ugye, leírtam, hogy a múltkor hogyan jártunk. (Egyik, másik.) Tanultam belőle, most időben átvizsgáltam az összes címlistát, recpolt. Nem volt bennük névbe ágyazott zárójel, nem volt bennük felesleges ‘&’. Meg hát azért ez már SP1, az meg csak RTM volt.
A magam részéről mondjuk nem bántam volna, ha van előzetes validálási lehetőség, de hát ugye… Külön nehezítés, hogy itt az első MBX szerver rögtön egy CCR cluster aktív lába lesz…. ezt nem kellene elrontani, mert utána kivakarni a koszt… brrrr… nem kellemes.

No mindegy, még egyszer átfutottam az ldap lekérdezéseket… jóknak tűntek.
Hajrá.

Húzza a csíkot… húzza a csíkot… majd megáll. Hogy van egy policy, amelyikben szerinte nem stimmelnek a zárójelek. Szerencsére még nem történt semmi visszavonhatatlan, aktív a retry gomb a varázslóban, ráadásul megadja a policy nevét is. Megvizsgálom, ránézésre teljesen jó. De ami még durvább, az az, hogy ez az ldap feltétel nem valami egyedi dolog, hanem varázslóval lett összekattogtatva. Mi az, hogy az egyik varázsló nem eszi meg azt, amit a másik állított össze?
Néztem pár percig, végül felhívtam a rendszergazdát, mi is ez a recpol? Nem fontos, törölheted – jött a megnyugtató válasz. Huss.
Ez az egy policy akadt csak meg a torkán, nyugodtan nyomtam rá a retry gombra pár perc várakozás után. Be is fejezte a Mailbox szerepkör telepítését, belevágott az utolsó fordulóba, az MBX clusterezésbe.
És belehalt. Közölte, hogy

Summary: 4 item(s). 3 succeeded, 1 failed.
Elapsed time: 00:08:56

Copy Exchange Files
Completed
Elapsed Time: 00:01:13

Management Tools
Completed
Elapsed Time: 00:00:07

Mailbox Role
Completed
Elapsed Time: 00:06:34

Clustered Mailbox Server
Failed
Error:
The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error.
Elapsed Time: 00:01:01

Érted??? Ennyit mondott csak, és itt már nem volt retry. Meghalt a telepítés. Kaptam egy nem clusterezett MBX szerepkört egy clusteren. Sokáig nem is tértem magamhoz. Úristen, hogyan fogom én ezt úgy egyenesbe tenni, hogy később ugyanezen a néven és ugyanezen az IP-n működő CCR szervereim legyenek?
És mi a büdös istenharagja nem tetszett már megint neki a listákon vagy recpolokon? És egyáltalán, melyiken? Hiszen az ügyfélnél volt belőlük épp elég.

A hangulatom…. képzelheted. Dühöngtem. Hogy nem igaz, hogy ezekkel a szar ldap konvertálásokkal ekkorát kell szopni. Hogy nem lehet előre lefuttatni egy próbát, megvizsgálni, hogy végigmenne-e a telepítés. Vagy belerakni a telepítésbe, hogy ha ilyet talál, írja ki egy logba, hagyja ki… és _fejezze be rendesen a telepítést_. Nem hiszem, hogy egy filter ekkor stopper kell legyen a telepítésben. Illetve ha az, akkor meg ne lehessen addig telepíteni, amíg nincsenek rendberakva.
És akkor ott van még, hogy csesznek megmondani, konkrétan melyik filter volt és mi is volt a baj vele. Ha szándékosan akarták volna szívatni a jónépet, akkor sem csinálhatták volna meg ennél aljasabbul.

Tea. Utána nekiálltam feltúrni az eventlogot. És hoppá, ott egy hibaüzenet, benne a bűnös policy neve: Akármi Teszt. Micsoda? Egy teszt policy? Huss. (Későbbi elemzésre persze elmentettem az ldap filtert.)

Most már csak a takarítás volt hátra. Először halványan reménykedtem, hogy talán végigment a telepítés, csak a szervíz nem indult el, de a törlés után majd el fog indulni… és már készen is vagyunk. De megnéztem jobban, ez nem telepített public folder adatbázist… márpedig akkor ez más gazságra is képes lehetett. Radír. (Csak az érdekesség kedvéért jegyzem meg, hogy ez a befejezetlen torzó, ez a nem clusterezett MBX szerepkörű virtuális szerver olyan szépen failoverezett, hogy öröm volt nézni.)
Nem részletezem. Levakartam. Újra telepítettem. Gyönyörűen működött.
Egészen a Rollup Pack 5 telepítéséig. A csomag ugyan nem kért újraindítást… csak éppen mindkét gépen kinyírta a clustert. Egész konkrétan a cluster szolgáltatást. Baromi rondán nézett ki az MMC konzol, tök üresen. De egy bűvös újraindítás megoldotta ezt a problémát is.

Maradt az ldap filter megvizsgálása. Elhiheted, láttam már néhányat… de ebben tényleg voltak meglepő dolgok. Már az is érdekes volt, hogy SID-re szűrt. De a végén volt egy olyan feltétel, hogy (anr=nev*). Ez meg mi a fene lehet? ‘Anr’ nevű tulajdonság nincsen. Gugli.

Hát… itt van a megoldás. Érteni most már értettem… de ki ír ilyen szűrőket egy éles rendszerben? Még akkor is, ha teszt? Ebbe a rendszerbe ilyen szinten csak én szoktam belenyúlkálni, én meg nem emlékszem erre a szürőre. A varázsló…?
Most sajnáltam, hogy egyből kitöröltem. Soha nem fogjuk megtudni.

Tétova cluster

Exchange 2007 CCR cluster Windows 2008 NFSM cluster alapokon… izgalmas dolgok ezek. Nyilván össze is dobtam egy tesztrendszert, hogy nézegessem, simogassam, babusgassam. Na meg időnként agyon is vágjam.
A cluster, mint egy hiperaktív kisbaba, szépen felállt minden fejberúgás után, működött rendesen. Ide-oda terelgettem az aktív node-ot, tette a dolgát. (Már ahogy.)

Aztán eltelt egy hét, úgy, hogy nem nyúltam hozzá. Volt dolgom épp elég, máshol.

A hosszú álldogálás után újra beléptem, barátságosan hátbaszúrtam az aktív node-ot, figyeltem a failovert… mely nem következett be. Közölte, hogy az egyik Storage Group nem állt vissza online-ba, tehát a virtuális szervernek is Sándor. Néztem, mint Rozi a moziban. Oké, failback. Az működött.
Eljátszottam néhányszor ezt a failover/failback testcselt, de az eredmény mindig ugyanaz volt. Remek. Még jó, hogy a tesztrendszeren jött elő. Meg hát az amerikaiak úgyis azon aggódtak, hogy nem fogunk érteni a clusterhez…. nos, akkor itt a lehetőség, hogy kipróbáljam magam: rendbe tudom-e rakni ezt a rakoncátlankodó clustert. Mondjuk elsőre séróból, google nélkül.

Event viewer. Semmi. Annyit mond csak, hogy nem működött a failover – de ezt nélküle is tudtuk. Cluster.log… nos, az már nincs. (Illetve van, de egyelőre ugye google nélkül nyomjuk.) Nézzük, mi a helyzet az EMC-ből. Azt mondja, hogy a storage group adatbázisa (ugye, csak egy lehet) mountolva van, viszont a replikáció státusza: suspended. Hoppá… ez ledőlt pihenni. De miért? Resume, az anyád mindenit. És egyből healthy is lett. Kábé 10 másodpercig, mert utána megint elfáradt.
Nézzük a node-okat: látszólag minden rendben. Megvannak a könyvtárak, hely van bőven a vinyón… akkor mi a francért nem éled fel a passzív node adatbázisa?

Ismételjük át a tananyagot. Hogyan lehet életre lehelni egy hibás adatbázist CCR clusteren?

  • Ha az aktív node-on sérült az adatbázis, akkor eleve nem lehet felmountolni. Ilyenkor a ‘Recover database’ segít, az aktív node-on kiadva: ekkor a passzív node-ról történik egy visszamásolás. Jelen esetben ugye nem ez a helyzet, a Recover menüpontot választva az Exchange csak visszamorog, hogy ‘hülye vagy Ödön’.
  • Amennyiben a passzív node-on lévő példány sérül meg, akkor jön az ‘Update database’, de a passzív node-on kiadva. (Egyébként el sem ronthatjuk, az aktív node grafikus felületén nincs update opció és vica-versa.) De ha már durvulunk, legyünk extra durvák: jelöjük be, hogy mindent töröljön, ami az adatbázishoz tartozik. Ez a tuti. Ilyenkor a passzív node-ról törli a hibás adatbázist, törli a hozzátartozó checkfile-t és a logokat, majd újraseed-eli az adatbázist.

Naná, hogy az utóbbi segített.

Ami a jó hír a történetben, hogy el tudtam bánni a hibával, szolgáltatás nem esett ki. A rossz hír, hogy nem tudom, mi történt. Egy hétig hozzá sem nyúltam a rendszerhez, ment minden… és csak az EMC konzolban lehetett volna észrevenni – ha valaki rendszeresen rá-ránézett volna – hogy az egyik adatbázisra nem megy a háttérben a replikáció. Természetesen ez egész addig nem tűnik fel senkinek, amíg nem történik valami, mely failovert indikálna. Mely ugye ebben az esetben előre nem látott körülmény miatt elmarad. És ekkor már a reseed sem segít, hiszen pont az aktív node dőlt le.

Erre bizony hamarosan megoldást kell találnunk.

Halálra replikálva

Furcsa ez a szakmai blogolás. Van, amikor hónapokig nem történik semmi érdekes, nincs miről írni. Aztán van, amikor teljesen bevadul az élet, hirtelen rengeteg minden történik – de ekkor meg idő nincs megírni.

Ez utóbbi van most.

Így mindenféle körítés, mindenféle hangulatkeltés, mindenféle érzelemfelcsigázás és feloldás, azaz katarzis nélkül most egyszerűen csak leírom, mibe futottam bele a napokban.

Egy ügyfelünknél Windows Server 2008 alapon rakunk össze egy Node and File Share Majority clustert, melyre majd egy Exchange 2007 CCR cluster kerül. (És ez csak apró része a projektnek… nem mondhatnám, hogy mostanában szénné unatkozom magam.)

Nos, tesztrendszer. Minden frankó, rángatom a clustert, mint Floki a lábtörlőt, failover, failback az MMC konzolból … minden működik. Kisördög belémbúj: mit csinál igazi lehalás esetén? Fogtam, lekapcsoltam az aktív node-ot. Erőforrásék szépen el is haltak, majd elindultak vissza online-ba… kivéve a public folder adatbázist. Az nem. Ugocsa non coronat. Persze emiatt a virtuális szerver sem állt fel. Ráböktem a public folderre: bring online. És visszajött. Szép kis cluster: működik a failover, de csak egy kattintás után. Mint a viccben a Microsoft légzsák. Mi lehet ez: tesztelésnél minden remek, éles hibánál meg halál?
Az eventlogban nyilván nem volt semmi.

RTFM.

De tényleg. Elő kellett túrni a Technet Library-ból azt a cikket, hogyan tervezzünk CCR clustert – és ott szépen le is volt írva. Ez kérem, by design.
Mit is takar az a név, hogy CCR? Cluster Continuous Replication. És hogyan is néznek ki a public folderek? Van egy organizáció szintű hierarchia, melynek tartalma több Exchange szerver adatbázisaiból áll össze. Hogyan disztributálódik a public folderek tartalma? Replikációval. Replikáció itt, replikáció ott. Márpedig két dudás nem fér meg egy csárdában.
Azaz a következő választási lehetőségeink vannak:

  1. Ha CCR clusteren akarjuk tárolni a public foldereinket, akkor azok más szervereken nem lehetnek. Ez működhet centralizált felállás esetén.
  2. Ha intenzíven használjuk a public foldereinket és több telephelyen is el szeretnénk érni azokat, akkor nincs CCR. Pontosabban van, de akkor nem lehet public folder replika a clusteren.
  3. Tojunk az alkotmányra. Ekkor kapjuk a fenti viselkedést: a clusterünk valódi hiba esetén nem fog automatikusan átvándorolni a másik node-ra.

Nos… ez van. Mondhatni, ez egy szimpla tervezési probléma.

Hát… nem egészen. Gondoljuk csak el: egyszerűen nem létezik olyan szituáció, hogy valamilyen/akármilyen rendszer upgrade-jével állítjuk elő a CCR clustert. Az bizony ott helyben születik. tehát a public folder adatbázist is rá kell varázsolni valahogyan. Erre pedig jelenleg csak egyetlen szóbajöhető módszer létezik: replikációval. Azaz teljesen szabályosan járunk el, mégis beleütközünk a 3-as megoldásba. Oké, nyilván nem egy világrengető tragédia… de jobb ha felkészülünk rá, hogy arra a pár napra (ritka lusta jószág ám ez a public folder), amíg a teljes public folder tartalom fel nem másolódik a CCR-re, addig a cluster megszűnik cluster lenni.

[Update]
Asztakurva. Most olvasom egy teljesen harmatos blogbejegyzésben a hamarosan kijövő SP1 Rollup5-ről:

While we will have a full list of issues fixed when the Rollup releases, some of major issues are:

Exchange 2007 CAS cannot copy the OAB from the OAB share on Windows Server 2008-based Exchange 2007 CCR clusters

Tehát, ha teljesen logikusan, az egyébként szintén teljesen logikus Windows 2008 alapú CCR clusteren futtatjuk az OABGEN processzt, akkor a – megint teljesen logikusan – cached módba kapcsolt Outlook 2007 userek nem kapnak címlistát. Se rosszat, se jót.
Téphettem volna megint a hajam. Mintha olyan sok lenne.

Megyen a log vándorútra

Az már önmagában jó ötlet volt, hogy SCC helyett LCR meg CCR lett, de az igazi nagy dobássá az SCR vált.

Nem, nem golyóztam be, legalábbis nem szignifikánsan. A fenti mondat Exchange adminok folyosói beszélgetésében teljesen természetesnek számít. (Ha jót akarsz magadnak, kerülöd az Exchange adminokat folyosói beszélgetés közben.)

Hogy érthető legyen, amiről beszélni fogok, tisztázzuk le, mi is történik a levelekkel, miközben bekerülnek az adatbázisba. Most azzal nem akarok foglalkozni, hogy mi is az az ESE, jelen esetben nem lényeges. Sokkal fontosabb, hogy tudjuk, hogyan működik a tranzakció alapú adatbáziskezelés. Az alapelv az, hogy van egy napló, egy úgynevezett tranzakciós log, melybe vezetjük, hogy tulajdonképpen mit is szeretnénk tenni az adatbázissal. Az első félreértés már rögtön itt adódik: melyik adatbázissal? És jön is visszakézből: miért, hány adatbázis van? A válasz egyszerű: kétszer annyi. Mindig. Ugyanis minden megnyitott adatbázisnak van egy példánya, mely a merevlemezen van és van egy példánya/szelete a memóriában. Értelemszerűen sokkal gyorsabb azzal a példánnyal dolgozni, mely a memóriában van – csakhogy az a példány olyan, mint az élet: ha lekapcsolják a főkapcsolót, elillan. Amelyik megmarad, az a merevlemezen lévő. Melynek kezelése lassú, mint idő múlása a fogorvosi váróban. Jó lenne, ha egybe tudnánk gyúrni az előnyöket, anélkül, hogy a buliról a hátrányokat értesítenénk.
Nos, jön az a tranzakció. Tokkal vonóval beírjuk a logba, hogy pl. Kis Piroska törölte a ‘Ph@nt@st1c V I A G R A buy n0w’ tárgyú levelét. Ki is töröljük, a memóriában lévő példányból. A levelezőkliensek a memóriában lévő példányt látják, tehát azt hiszik, tényleg ki lett törölve a levél. Pedig nem, a lemezen lévő példányban ott van. Onnan akkor fog eltűnni, ha éppen ráér a szerver. Vagy hátbavágja egy backup. Akkor, amikor ténylegesen kitörlődik a lemezen lévő példányból, akkor lesz lezárva a tranzakció a logban. Nézzük, mi történik, ha a takarítónő elemet akar tölteni és emiatt a porszívó mellett a másik konnektorra is lecsap, kihúzva a redundáns tápunk mindkét madzagját? Az Exchange szerver leállt, a memóriában lévő adatbázispéldány füstté vált… de ott van a merevlemezen lévő adatbázis és a tranzakciós logok. Látjuk, hogy mely tranzakciókhoz tartozik lezárás – azok már kikerültek a vinyóra. De a lezáratlanok még nem – nosza, írjuk ki. Ezt hívják úgy, hogy rájátsszuk a logokat az adatbázisra.
Igen, jogos a kérdés… mit nyertünk ezzel? Hiszen írunk a lemezre… Írni ugyan írunk, de nem mindegy, hogyan. Ugye mindenki tudja, hogy a tranzakciós lognak külön merevlemeze van, ahová a fej folyamatosan ír, olvasni gyakorlatilag nem olvas? Ég és Föld különbség van eközött az írás és egy többszáz gigás adatbázisba illesztő írás között.

A hosszú bevezetésnek annyi volt az összes értelme, hogy tudjuk: aktuális adatbázis = merevlemezen lévő adatbázis + tranzakciós logok. A sok CR végű akronim pont ezzel a képlettel trükközik.

És akkor oldjuk is fel őket:

  1. SCC – Single Copy Cluster
  2. LCR – Local Continuous Replication
  3. CCR – Cluster Continuous Replication
  4. SCR – Standby Continuous Replication

Az első a sima cluster. Exchange2003-ban csak és kizárólag erre hivatkozhattunk, ha magas rendelkezésreállásról faggattak az ügyfeleink.
Exchange 2007-ben viszont már megjelentek az ún. log shipping technikával dolgozó eljárások is. Ezek a *CR-ek.

LCR: A konkrét Exchange gépen egy megadott könyvtárba ‘elülteti’ (seeding) az adatbázist – azaz másolatot készít róla. Innentől miközben dübörög az Exchange szerver, pörögnek a logok, mindegyikről másolat is készül az előző könyvtárba. Mit védtünk ki ezzel? Azt, hogy ha például megsérül az adatbázisfájl. Ha felrobban az adatbázist tartalmazó merevlemez. Ekkor ugyanis a másik merevlemezről – mert annyi eszünk gondolom volt, hogy az LCR könyvtár másik merevlemezre került – manuális beavatkozással beröffentjük az adatbázist. (Ugye van minden: log és adatbázis.) Ez a legegyszerűbb log shipping, nem kell hozzá semmi se, igaz, csak merevlemezhiba ellen véd.

CCR: Ez már komolyabb. Kell hozzá a cluster szolgáltatás. És kell hozzá a Microsoft Exchange Replication szolgáltatás. A forgatókönyv az, hogy van egy cluster, két node, ahogy kell… de nincs közös adatterület! Nincs quorum. Kell a francnak, csak baj volt vele. Ehelyett van egy file share valahol, oda irkál mindkét node. (Igen, van egy kicsi ‘Majority Node Set’ áthallás.) Az adatok naprakészségét pedig úgy biztosítja az előbb említett szép hosszú nevű szolgáltatás, hogy a logokat másolgatja folyamatosan mindkét node-ra. Látható, hogy ez már komolyabb dolog: automatikus failover/failback, komoly rendelkezésreállás, de böszme hardverköltség nélkül. Viszont vannak hátrányai is: a cluster két node-ja nem lehet külön alhálózaton. Ezzel gyakorlatilag nem tudunk védekezni az épület lebombázása ellen.

SCR: Egyfajta arany középút. De tényleg arany. Mit is tud? Van egy éles Exchange szerverem és van egy standby Exchange szerverem. Mindkettő működik, a magvetés után mindkettőn ott van az adatbázis, de a felhasználók az éles szervert érik el. A logmásolás folyamatos. Ha kidől az éles szerver, a standby szerveren lévő adatbázist előléptetjük – és megy minden tovább. Nézzük az előnyöket: kitörtünk a szerverszobából. Nincs alhálózatra vonatkozó megkötés, ha jó a vonalunk, akár Balatonfőkajárra is lerakhatjuk a standby szervert. Nem kell hozzá cluster szolgáltatás. Egyszerre több standby gépet is használhatunk, maximum négy lehet. A forrás gép lehet egyszerű Exchange szerver, de lehet LCR, CCR, SCC is. Hoppácska. Azaz mezei szerverekkel össze tudok hozni egy olyan figurát, hogy a szerveren belül LCR-t használok, telephelyen kívül pedig SCR-t. (Viszont SCC/CCR esetében él az alhálózati korlát, hiszen ezt végül is a cluster szolgáltatás kényszeríti ki. Kivéve persze az MNS-t.) Hátrány: nincs automatikus átállás, össze kell piszkolnunk a kezünket. Másik hátrány: majd az SP2-ben jelenik meg végleges formában; viszont a béta2-ben már tesztelhető.

Majdnem-Herkules

Igen, ő a Muszáj-Herkules testvére.

Felteszem, mindenki tudásában vannak fehér foltok. Olyan területekre gondolok, melyeket ha máskor nem is, de vizsgára megtanultunk – aztán utána el is felejtettük, mert soha nem volt rá szükségünk. Nekem ilyen terület a biztonsági sablonok molesztálása.

Adott volt a következő feladat: telepítsünk egy egyszerű failover clustert multi ügyfél magyar leányvállalatához. A vasak egyszerű pengeszerverek, oprendszer, IIS (erőforrás lesz belőle az ügyfél alkalmazásában). A gép tartományba beléptetve, lokál admin jogunk van, tartományi admin jog nincs. Jól is néznénk ki.
Mielőtt még felhajigálnánk a clustert (pontosabban beizzítanánk, hiszen a WIndows2003 Enterprise változatban helyből települ), még le kell futtatnunk egy helyi specifikus alkalmazást: ez bekeményíti az operációs rendszert, bekonfigurál egy csomó mindent, felrak ezt-azt. Céges standard, kötelező.
Jöhet végre a cluster. Gyönyörűen fel is települ, majd amikor leokézom az utolsó ablakot, jön egy kövér error. Hogy access denied.
Első alkalommal ijedtemben eltávolítottam a node-ot. (Ami persze nem igazán egyszerű dolog, hiszen grafikus felületről nem látszik semmi. A megoldás: ‘cluster node <nodename> /forcecleanup’) De az újabb, alaposabb konfigurálásnál ugyanezt kaptam. Ráadásul a kollégák szóltak, hogy a cluster tulajdonképpen működik, kívülről elérhető. Csak éppen nem menedzselhető. Zorró, a fantomklászter. Jöttek a szokásos ráolvasások éjfélkor keresztútnál (filemon, regmon, user jogosultságok, gpresult), de nem sok sikerrel. Aztán az ügyfél ötletére ráhúztuk a rendszerre a ’setup security’ biztonsági sablont – és onnantól már a cluster szolgáltatás sem indult el. Viszont amint visszaállítottuk a cluster service account user jogosultságait a setup security sablonban, egyből menedzselhetővé vált a cluster.
Azaz a hardening csinált valamit, amitől elérhetetlenné vált a cluster management GUI – amint visszatettem egy gyengébb sablont, minden ment simán.
Azt hihetnéd, hogy örültünk ennek a megoldásnak. Óriási tévedés. A leánycégnek az égegyadtavilágon semmi ráhatása sincs arra, hogy a magasságos multi anyacégnél a biztonsági részlegen milyen hardening eljárást dolgoznak ki. Sőt, még tájékoztatást sem kapnak, hogy tkp. mi is történik a folyamat során. A maximum, amit ki tudtunk csikarni, az egy mérsékelt érdeklődés volt, és egy igéret, hogy ha kiderítjük, melyik beállítás okozza a hibát, akkor az eredményt felveszik a céges knowledge base-be.

Azaz identifikálni kell, ezerrel.

És itt jön be a képbe a Security Configuration & Analysis segédprogram. A Majdnem-Herkules.

Mielőtt tovább haladnánk a megoldási folyamatban, nézzük át részeletesen, hogyan is működik ez az eszköz.

Először is, az eszköz grafikus felülete csak MMC konzolból érhető el – azaz megfuttatjuk az mmc.exe progit, majd a snap-in-ek közé felvesszük a Security Configuration & Analysis konzolt. És ha már ott járunk, kapjuk fel a Security Templates konzolt is.

Nagyítás

Ha magunktól próbálunk rájönni az eszköz működésére, akkor gondban leszünk. Ugyanis ha nem ismerjük a logikáját, magunktól soha nem fogjuk kitalálni.
Az elv az, hogy van egy működő rendszer. Ez az, amely éppen dübörög a gépen, amelyen vizsgálódunk. És van egy munkaterület, ahová boncolási célzattal betölthetünk biztonsági sablonokat. Egyszerre mindig csak egyet. Ezt a munkaterületet adatbázisnak nevezték el. Az összes műveletnek ez a két terület az alanya.

  • Össze lehet hasonlítani a munkaterületen lévő sablont a jelenlegi beállításokkal. (Analysis.)
  • Tetszőlegesen módosíthatjuk a munkaterületen lévő sablont, majd elmenthetjük.
  • A munkaterületen lévő sablont ráhúzhatjuk a működő gépre. (Configuration.)

Nézzük részletesen.

Mielőtt bármit csinálnánk, munkaasztalt – adatbázist – kell definiálnunk. Jobbklatty, open database.

Nagyítás

Itt beírjuk a létrehozandó adatbázis (.sdb) nevét. Ezzel létre is jön. De mielőtt még kiérnénk a kuruzslóból, megkérdezi, hogy vajh melyik sablont szeretnénk betölteni? Válasszuk ki valamelyiket.

Nagyítás

Amivel egész biztosan nem okozunk galibát, az az összehasonlítás. Csapjunk bele.

Nagyítás

Rögtön az elején megkérdezi, hová mentse az összehasonlítás során keletkező log fájlt. Ezt jegyezzük fel, mert később szükségünk lehet rá. (Persze ha konzolból nyomjuk, az meg fogja jeleníteni a jobb oldali ablakban.)

Nagyítás

Aztán dolgozik az analízis. (Menj analízisbe, Ofélia.)

Nagyítás

Imhol a végeredmény. Látható, hogy a security fa melyik ágán vizsgálódunk és mely tulajdonság egyezik, mely pedig nem. Az eltérést a mismatch jelzi.

Nagyítás

A konkrét ábrán például láthatjuk, hogy a User Rights ágon belül a System Time állítgatási jog beállításai eltérnek az adatbázisban és az éles rendszeren. Nézzük meg, hogy hogy is néz ez ki a grafikus felületen:

Nagyítás

Igen, láthatjuk, hogy a munkaasztalon lévő sablonban a megfelelő beállítás előtt egy ikon jelzi, hogy ott valami nem stimmel.
Egész pontosan az ikon a következőket jelezheti:

  • Piros körben fehér iksz: a beállítás eltér a valós rendszer és a vizsgált sablon között.
  • Fehér körben zöld pipa: a beállítás megegyezik a valós rendszerben és a sablonban.
  • Kérdőjel: A beállítás nem létezik az adatbázisban, ergo nem is került kiértékelésre.
  • Felkiáltójel: Pont fordítva: a beállítás nem létezik a valós rendszerben.
  • Nincs semmilyen jel: A beállítás egyik helyen sincs definiálva.

Például a korábban a szövegfájlban látott mismatch így jelenik meg a grafikus felületen.

Nagyítás

Természetesen a munkaterületre betöltött sablont nem csak boncolhatjuk, hanem műthetjük is. Bármelyik beállítást módosíthatjuk, majd az így létrejövő sablont exportáljuk valamilyen új néven.
Értelemszerűen ahhoz, hogy ez a menüpont megjelenjen, előtte be kell tölteni egy sablont a munkaterületre, majd összahasonlítani az aktuális beállításokkal. Utána lehet menteni.

Nagyítás

Új sablont nem csak létezőből kiindulva hozhatunk létre – igaz, ehhez már egy másik konzolra lesz szükségünk. A Security Templates snap-in-ben jobbkattintás, majd New Template…

Nagyítás

Látható, hogy ez egy teljesen üres sablont hoz létre. Miénk a terep, tetszőlegesen perverz kombinációk létrehozása előtt nyilik meg a lehetőség. Csak arra vigyázzunk, hogy magunkat ne zárjuk ki a módosítási engedéllyel rendelkező személyek közül. Onnantól ugyanis unalmas hétköznapunk egy kicsit pörgősebbre fog változni.

Nagyítás

Itt pedig azt láthatjuk, hogy a Security Templates konzolban létrehozott MacskaRugjaMeg sablont mentés után már a Security Configuration and Analysis konzol munkaterületére is betölthetjük, további fazonírozás céljából.

Nagyítás

Amennyiben a megfelelően módosított sablont rá akarjuk húzni, akkor az Analysis menüpont helyett a Configuration menüpontot válasszuk – ekkor a munkaterületen lévő beállítások rámásolódnak az aktuális számítógépre.

Nos, nagyjából ennyi. Egész jó kis segédprogram.
Lenne.
Ha a program tervezése során figyelembe vettek volna egy átkozottul reális igényt: azt, hogy a meglévő gép biztonsági beállításaiból sablont gyárthassunk. De nincs. Tessék ilyen szemmel végigolvasni az eszköz működését: mindenhol a munkaterületet exportálhatjuk, oda meg már létező sablont tudunk csak betölteni. Ez egy akkora öngól, hogy még ma sem tudom igazán elhinni. Programozástechnikailag semmibe nem került volna összedobni, a sablongyártásban pedig óriási segítség lett volna.

Érted már, hogy miért Majdnem-Herkules?

Térjünk vissza a megoldandó problémához. Van egy gép, induláskor a setup security sablonnal. Ezen begerjesztem a cluster szolgáltatást, felkonfigurálom a clustert. Innentől már eltértünk a sablontól, tekintve, hogy a telepítés/konfigurálás belerondít rendesen. Aztán jön a multi cég hardening folyamata, mely aztán végképp összezavarja a szálakat.
Nekem arra lenne szükségem, hogy mielőtt ráengedném a hardeninget, le tudjam menteni sablon formában az épp aktuális beállításokat, majd a bekeményítés után visszatölthessem a munkaterületre és ki tudjam analizálni közöttük a különbséget. Nyilván még ez sem lenne túl egyszerű, kicsit ‘tű a szénakazalban’ jellegű a munka… de valahogy így lehetne nekiállni.
Ehelyett… kinlódunk. Nem tudom lementeni a sablont, tehát maximum a setup security kiindulási pont és a hardening végső pont között tudok különbséget képezni – azaz a feladat jellege megmaradt, csak a szénakazal lett jóval nagyobb.
Illetve… trükközhetek. Felkonfigurálom a clustert, majd összehasonlítom a valós rendszert a setup security sablonnal. Ekkor megkapom azokat a beállításokat, melyeket a cluster telepítés érintett. Gyújtok egy gyertyát Szent Antalnál és reménykedek, hogy ez a halmaz nem lesz nagy – és tartalmazni fogja azt a beállítást, melynek átállítása okozza a galibát.
Most jöhet a hardening, majd ezt összehasonlítom a setup security sablonnal – de csak a korábban manuálisan kiszűrt beállításokkal fogok foglalkozni.

A megoldás kicsit olyan ’szarva között a tőgyét’ jellegű – de akár működhet is. Talán.
Ha nem, akkor kénytelen leszek felvenni a csempetépkedő kesztyűt.

ps.
Amikor az ember először morog, utána gondolkodik. A ‘secedit /export /mergedpolicy /db /cfg’ mintha pont ezt csinálná.

Mentális erő

A napokban kihelyezett okítás van nálunk, cluster témakörben. Nyilván az egészet nem fogom beírni, de a tegnapi napból egy levezetés megragadta a fantáziámat.
Előre jelzem, hogy erősen egyszerűsíteni fogok. Most egy konkrét erőforrásról lesz szó. Feltételezem, hogy ez egy fontos erőforrás, melynek ledőlése átmozgatja az erőforrás csoportot a másik node-ra – azaz failover következik be. Az erőforrás tulajdonságlapjának Advanced fülén lehet beállítani az advanced paramétereket. Ilyeneket:

  • Threshold / Period [sec]: a period időtartam alatt az erőforrás hányszor halhat meg, ahhoz, hogy kikényszerítsen egy node váltást.
  • Pending time out [sec]: mennyi ideig várjunk az erőforrásra ahhoz, hogy döglöttnek nyilvánítsuk.

Ránézésre semmi különös. De ha jobban belegondolunk, mégis van itt egy kis rafinéria.
Mondjuk legyen az erőforrás egy service. A küszöbérték legyen 3, a period 900 sec, a timeout 180 sec. (Ezek a default értékek.) A szerencsétlen szolgáltatás beragad – azaz az ‘Is alive’ hibásnak jelzi. Kivárják a 180 másodpercet, küszöbérték számláló 1-re áll. Megpróbálják újraindítani a szolgáltatást, de az ostoba vigyorral a képén továbbra is csak áll, újabb 180 sec múlva lép a küszöbérték kettőre és még 3 perc kell ahhoz, hogy az erőforráscsoport áttegye a seggét a másik node-ra. Átteszi? Igen, mert összesen 3*180 sec telt el, azaz benne vagyunk a 900 sec perióduson belül.
Igenám, de mi van akkor, ha az adminisztrátor azt mondja, hogy ez egy Exchange szolgáltatás, itt a timeout érték igen magas: vegyük fel 350 másodpercre. Tessék végiggondolni.
Pusztán szellemi erővel sikerült hazavágnunk a clustert, legalábbis a szolgáltatásra nézve. A hiba biztos megállapítása 1050 sec lesz, miközben az erőforráscsoport csak akkor fog vándorolni, ha a hibára jellemző mintázat 900 másodpercen belül történik meg. Ez a cluster a büdös életben nem fog clusztogni. (Mellékes folyomány, hogy emiatt nem lehet Exchange szerveren kiemelkedően magas rendelkezésre állást bevállalni – hiszen egy beragadt IS service biztos detektálása 15-20 percet is igénybe vehet.)
És a minta nem egyedi. Van egy másik beállító panel. Ez arra vonatkozik, hogy ha egy bizonyos intervallumon belül (period) volt x darab failover, akkor hagyja abba, mert ez az erőforráscsoport már a boldog vadászmezőkön nyargal és nem illik rugdosni a döglött oroszlánt. Namost, minden failovernek van egy jellemző ideje: ki kell nyírni a döglött erőforrásokat (szolgáltatás, egyebek) és el kell indítani a másik node-on. Exchange esetén ez megint nem kis idő. Ugyanaz a hibalehetőség: ha az x, megszorozva a failover idejével, több, mint a period érték, akkor ez a cluster még a harmadik világháború után is failoverezni fog az embernélküli sártekén.
Szép, mi? Ismerek egy csomó Microsoft terméket, de egyiknél sem emlékszem olyan GUI beállítási lehetőségre, amelyikkel ki lehet nyírni magát a terméket. (Uninstall nem játszik.)
Megint valami, amihez kevés a next-next-finish admin hozzáállás.