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.

Leave a Reply

Your email address will not be published. Required fields are marked *