A misztikus public folder replikáció II.

Tulajdonképpen nem is az a kérdés, hogy mi történik – sokkal inkább az, hogy hogyan derül ez ki? Mint korábban írtam, a replikáció nem időbélyeg alapú. A kulcsszereplő jelen esetben a Message State információk közül a predecessor change lista. Ebben van az összes olyan CN, mely valaha is hozzá volt rendelve az adott objektumhoz.

Nézzünk egy példát.

Legyen az objektum predecessor change listája a következő:

Értelemszerűen ez mindegyik replikánál egyforma. Jön Béla és módosítja a Clack1 gépen lévő objektum nevét. Ekkor Clack1 predecessor change listája így fog kinézni:

Ezt a PFRA belecsomagolja a replikációs csomagba és elküldi Clack2-nek. Ő kicsomagolja és az összehasonlítás után észreveszi, hogy az őnála lévő predecessor lista részhalmaza az újonnan küldött listának, tehát az új lista a király.
Ha valamilyen baleset következtében régebbi módosítást kap meg, akkor azt fogja találni, hogy az új lista részhalmaza a nála lévő listának – kacag egy jóízűt és ignorálja a replikációs csomagot.

2. Mi történik ha egyszerre módosítják ugyanazt a – különböző replikákban létező – objektumot?

Jön Béla és kegyetlenül megint módosítja az előző objektumot. Igenám, de színre lép Jenő is, akit szintén ellenállhatatlan kényszer gyötör, hogy módosítsa ugyanazt az objektumot. Sajnálatosan Jenő postafiókja Clack2-n van. Ráadásul mindez azonos replikációs intervallumon belül történik meg.
Nézzük a példát:

Kiindulási állapot:

Béla módosít:

Jenő módosít:

Megtörténik a replikációs csomagok elküldése. Ezeket a predecessor change listákat kell összehasonlítaniuk a szervereknek:

Látható, hogy egyik sem részhalmaza a másiknak. Replikációs konfliktus keletkezett.
Mi alapján döntik el a PFRA-k, hogy melyik módosítás nyert? Aki azt mondja, hogy majd az időbélyeg dönt, azzal közlöm, hogy ugyan logikusan tetszik gondolkozni, de jelen esetben nincs szivar. A konfliktusnak ugyanis kifejezetten csalafinta feloldását fundálták ki az Exchange fejlesztők.
Maga a PFRA lép akcióba és küld egy ún. conflict message üzenetet Bélának és Jenőnek. Mindemellett a konkrét folder összes tulajdonosánál is bemószerolja őket. Sőt, az üzenetet bemásolja a public folderbe, ahol persze szétreplikálódik az összes szerverre, ahol létezik replikája. Majd ezek után angyali mosollyal kisétál a szobából és hagyja, hogy az érintettek ököljog alapján rendezzék a helyzetet.
(Hierarchia replikációs ütközésnél egy kicsit visszafogottabb a PFRA, ekkor csak a folder tulajdonosait értesíti.)

3 Mi történik, ha el lett lazsálva egy replikáció?

Eddig egy ideális világról beszéltünk. Clack1 észlelte a változást, elküldte a csomagot Clack2-nek, aki lelkesen frissítette is az objektumot. De mi van, ha pont arra jár a levélelkapó manó és a replikációs csomag nem érkezik meg? Ugye, tudjuk, Clack1 a csomag elküldésének pillanatában el is könyvelte, hogy Clack2 is módosított. Ő ugyan több értesítést nem fog küldeni. Clack2 meg elégedetten üldögél a fenekén, fogalma sincs, hogy neki módosítania kellett volna.
Pánikra nincs ok. (Az Exchange egyébként is a türelmes adminisztrátorok platformja.) Létezik egy mechanizmus, mely ezeket a lyukakat hivatott felderíteni. Az egyes szerverek PFRA szolgáltatásai időnként státusz információkkal bombázzák egymást – márpedig a státusz információk CNset-ekből állnak, azok meg CN értékekből. Ebből mindegyik PFRA ki tudja bogarászni, hogy megvan-e nála az összes módosítás, amely egy objektumot érintett. Ha talál olyat, amelyik nála nincs, akkor azt a módosítást felveszi a kívánságlistájára. Ez utóbbit backfill array-nek hívják.
De ne rohanjunk ennyire. Először járjuk körül, milyen esetekben is cserélnek státusz információkat az egyes szerverek?
Mikor kér egy public folder státusz információkat? (0x20, status request)

• Egy folderhez hozzáadunk egy replikát… vagy ellenkezőleg, elveszünk tőle egyet.
• Elindul egy új public folder store.
• Visszatöltöttünk egy store-t backupból és felcsatoltuk.
• Újraindítunk egy store-t, úgy, hogy bekattintjuk az ún Replication Flag értékeket a registry-ben. Ekkor a PFRA kéri az összes hierarchia státusz információkat és a nyilvántartása szerint hiányzó tartalom státusz információkat. (Részletesen lásd a 813629 KB cikkben.)
• Újraindítunk egy store-t, úgy, hogy bekattintjuk az ún Enable Replication Messages On Startup értékeket a registry-ben. Ekkor a PFRA kéri az összes hierarchia státusz információkat és az összes tartalom státusz információkat. (Részletesen lásd a 321082 KB cikkben.)

És vajon mikor küld egy PFRA státusz információkat? (0x10, status message)

• Minő meglepetés: ha valamelyik szervertől status request (0x20) kérést kapott.
• Ha már huszonnégy órája nem érkezett frissítés egy folderhez. Ekkor az összes olyan szerver felé elmegy a státusz üzenet, amelyiken van replikája az adott foldernek.

Végül ne felejtsük el, hogy mindegyik replikációs csomagba bele van csomagolva a frissítésben érintett folder státusz információja.

Oké. Státusz információk jönnek-mennek, Clack2 fejéhez kap: Úristen, hiányzik egy konkrét CN számú frissítés!. Fel is veszi egyből a frissítést a kívánságlistájára. Mivel az Exchange programozók is ismerik azt a dalszöveget, hogy “sokkal jobb, ha úgy szerzed, hogy vágyol utána”, ezért nem elégítik ki egyből Clack2 kívánságát. Várnak. Nem is kispályások, a timeout értékek viszonylag magasak. Ha a megkívánt update olyan Exchange szerveren van, mely azonos site-on van az ígénylő Exchange szerverrel, akkor a timeout értékek sorban: 6/12/24 óra – ellenkező esetben 12/24/48 óra.
Nem mondom, hagytak időt bőven arra, hogy a hiányzó értékek esetleg maguktól is odataláljanak.

Kis kitérő. Háromfajta Exchange adminisztrátor van:

• A legrosszabb típus, a türelmetlen versenyző. Össze-vissza kattogtat és dühöng, hogy miért nem történik semmi. Képtelen felfogni, hogy az Exchange időnként kifejezetten nagy holtidőkkel működő rendszer.
• Egy fokkal jobb, aki üveges szemekkel bámul apatikusan a képernyőre, de legalább nem kattogtat. Neki ugyanis már van esélye arra, hogy eszébe is jut valami értelmes, nagyjából addigra, amikorra a változások is végighullámoznak a rendszeren.
• A legérdekesebb az, hogy külső szemlélő számára az előző adminisztrátor és a profi között nem látszik semmi különbség. A profi is ugyanúgy üveges szemekkel ül a monitor előtt – de közben tudja, mi zajlik a háttérben: tisztában van vele, mire vár.

Vissza a száraz elmélethez. Clack2 tehát tudja, melyik CN számú upgrade hiányzik, felvette a kívánságlistára és letelt az első timeout (6/12 óra). A PFRA fogja magát és küld egy backfill request-et (0x8). Kinek? Ez bizony jó kérdés.
Imhol az algoritmus.

• Clack2 készít egy listát azokról a szerverekről, ahol megtalálható az a replika, mely a kérdéses változáshoz tartozik.
• A lista elemeit sorba rendezi, a következő szempontok szerint:
  • Működik-e a szerver?
  • Ki a preferred backfill server? (Nem szokott lenni.)
  • Mennyi a transzport költsége?
  • Milyen verziójú az illető Exchange szerver?
  • Hány igényelt változáshoz tartozó csomag található a szerveren?

Nem minden szempont bír azonos súllyal. Általában elmondható, hogy a transzport költsége mindent visz. Logikus, hiszen ha van frissítés az azonos site-on lévő Exchange szervereken, akkor először azoktól kell begyűjteni, még akkor is, ha azok csotrogány 5.5 szerverek.
Most már tulajdonképpen készen is vagyunk. Tudjuk, melyik csomag hiányzik. Tudjuk, melyik szerverről szerezhetjük be optimálisan. Elküldjük neki a backfill request-et (0x8) és meg is kapjuk a csomagot (0x80000002 v. 0x80000004).
Vagy nem. Ha nincs válasz, akkor a szervert úgy veszi a PFRA, hogy nem működik és újra összeállítja a listát. Persze közben a timeout értékek próbálkozásonként szépen nőnek – hasonlóan az Exchange admin ősz szakállához.

4 Mi történik replika hozzáadásakor, elvételekor?

Ez:

1. Egy konkrét folderből csak egy példány létezik, Clack2 gépen.
2. Clack1-n dolgozva az adminisztrátor hozzáadja Clack1-t a folder replika listájához.
3. Clack1 küld egy hierarchia üzenetet Clack2-nek, aki szintén felveszi a replika listára Clack1-t.
4. Clack1 küld egy status request-et (0x20) Clack2-nek.
5. Clack2 visszaküld egy status üzenetet (0x10) Clack1-nak, benne a folderre vonatkozó státusz információkkal. (Full CNset.)
6. Clack1 észreveszi, hogy egyik CN sincs meg nála. Felveszi az egész bagázst a kívánságlistájára.
7. Letelik az első backfill timeout. Ha még mindig hiányzik a tartalom, Clack1 elkezdi küldözgetni a backfill igényeket (0x8).
8. Clack2 szorgalmasan küldözgeti vissza a backfill válaszokat (0x80000002 v. 0x80000004).
9. Clack1 kicsomagolja és lejátssza a módosításokat. Ezzel párhuzamosan törli a megadott számú változást a kívánságlistájáról.
10. Amennyiben letelik a következő backfill timeout, Clack1 újra elküldi a backfill igényeket.
11. Előbb-utóbb átkerül a kérdéses folder összes tartalma Clack1-re is.

Mint látható, ilyenkor a szerverek státusz információk segítségével derítik ki, hogy az új szerveren olyannyira hiányoznak a változtatások, hogy tulajdonképpen nincs is rajta semmi. Az összes tartalom átlapátolása ilyeténképp a backfill folyamat segítségével történik. Meg lehet saccolni a dinamikát.
Ebből következik egy gyakorlati tanács is. Ha egy konkrét foldert át szeretnénk migrálni egyik szerverről egy másikra, akkor először fel kell venni a folder replika listájára az új szervert, majd megvárni, amíg az új szerveren a Public Folder Instance listában megtalálható lesz a folder. Utána érdemes csak levenni a régi szervert a replika listáról.

5 Mi történik, ha úgy rakok át egy public folder tartalmat egyik szerverről a másikra, hogy a folder replika ablakában hozzáadom a listához az új szervert, leveszem a régit, majd törlöm a régi szerverről a komplett store-t?

Balhé.
Vizsgáljuk meg alaposabban, mi is játszódik le ilyenkor.
Egyáltalán nem meglepő módon, ha letörlök egy szervert a replika listáról, akkor a szerver nem szabadul meg pánikszerűen a tartalomtól. Ehelyett küld egy speciálisan preparált 0x20 status request-et az összes többi replikának. Ennek van böcsületes neve is, Replica Delete Pending Status Request-nek hívják és RDPSR-nek becézik. Ebben a csomagban van egy flag, amely jelzi, hogy a replika függőben lévő törlésben szenved. Ha a többiek megkapják ezt az üzenetet, akkor egy szintén speciális csomaggal válaszolnak. Ez egy különleges 0x10 csomag, melyet Replica Delete Pending Ack-nek hívnak. (A becenév kitalálása házi feladat.) Azt jelzi, hogy a megszűntetni kívánt replika által birtokolt CN változtatások megtalálhatók egy másik replikán is. (Nyilván csak akkor jön ilyen válasz, ha a változás tényleg létezik máshol.) Nna, ekkor törli csak a PFRA a tényleges tartalmat.
Tegyük fel, rossz napunk volt, türelmetlenek vagyunk, mint egy bespeedezett gepárd. Ahogy módosítottuk a replika listát, egyből megyünk is a megfelelő szerver public folderéhez és töröljük a store-t.
Nos, hacsak nem Exchange2003 Sp2 szerverünk van, akkor nagy valószínűséggel ezzel el is veszítettünk valamennyi nyilvános mappa tartalmat. A korábbi verziók ugyanis nem foglalkoznak azzal, hogy üres-e a Public Folder Instances lista a store törlése előtt. (Az Sp2-t is meg lehet erőszakolni, de az legalább figyelmeztet.)
(Van még egy másik különbség is. Az Sp2 előtti szerverek csak egyszer küldik ki az RDPSR-t, aztán várnak, akár az örökkévalóságig az RDPÁ-ra – persze közben a konkrét szerverről nem tűnnek el a folder példányok. Ilyenkor annyit lehetett tenni, hogy újra felvettük a szervert a replikák közé, majd ismét töröltük, ezzel generálva újabb RDPSR-t. Sp2 után gyakorlatilag óránként generálódik újabb RDPSR.)