Beláncolva

Régen írtam már szakmai témáról. Ez nektek rossz, nekem jó: ugyanis azt jelenti, hogy mostanában nincsenek nagy szívások a munkahelyemen.
Ez a mostani írás is inkább a munka melletti tanulás eredménye. (Érdekes módszer szerint szoktam tanulni. Előveszek egy könyvet, kinézem, mely fejezetet fogom átnézni, majd nem ritkán amíg a teámat kortyolom és átnézem a reggeli feedeket, postokat, elindulok valamelyik íráson és jó másfél-két órán keresztül próbálom letisztázni, mi is van a cikk mögött. Az előkészített könyv meg csak duzzog az asztalon.)

Van egy olyan valami az Active Directoryban, hogy ‘linked value’. Hallani már hallottam róla, különösen akkor, amikor az AD2003 előnyeit tanultam vizsgára – de olyan nagyon nem mélyedtem bele, mi is ez. Pedig elég érdekes.
Először az a bizonyos előny: az AD2003-ban jobb lett az LVR. Ugye, mennyivel könnyebb immár a lelkünk? De tényleg; az LVR rövidítés a linked value értékek replikációját jelenti.
Most már azért jó lenne tudni, mit is takar az a kifejezés. Könnyű lenne azt mondani, hogy kérem, a linked value az objektum egyik tulajdonságának olyan értéke, mely több elemből áll. Látni fogjuk, hogy ez messze nem igaz, de egyelőre maradjunk ennél a meghatározásnál. Az LVR pedig annyival lett jobb, hogy az AD2003-ban, ha az értékeket tartalmazó tömb egyik eleme megváltozott, nem az egész tömb replikálódik, csak a megváltozott elem. Ez különösen akkor lehet izgalmas, ha mélyebben belemegyünk a susnyásba.
És most akkor felejtsük is el gyorsan az előző defíniciót. Az ugyanis egész pontosan a multi-valued fogalmat fedi, melynek ellentéte a single-valued fogalom. A linked value egy egészen más szempontból történő csoportosítás eredménye. Például ellentéte a DN-valued fogalom.
Nos, eleget ködösítettem már és mivel a blogon nem szótagszám alapján fizetnek, épp ideje rendet raknom. Röviden:
DN-valued: amikor Géza írja be valamilyen eszközzel (kőbalta) a tulajdonság értékét.
Linked value: amikor az AD belső mechanizmusa gyűjti össze az értékeket, más objektumok tulajdonságaiból.
Azaz általában igaz, hogy a linked value körbe tartozó értékek tömbök. De tény, hogy vannak egyelemű tömbök is.
Nézzünk egy konkrét példát:
Minden postafióknak van egy homeMDB tulajdonsága. Az értéke lentebb látható. Itt tárolódik, hogy a konkrét postafiók mely szerver mely store-jában virít. Tippeljünk, milyen tulajdonság lehet ez? Akár DN-valued is lehetne… de nem az.

Kényelmi okokból nem az. Ugyanis létezik egy másik tulajdonság, egy másik objektumon. Minden store objektumnak van egy HomeMDBBL tulajdonsága, itt egy tömbben szerepelnek azon felhasználók CN értékei, melyeknek az adott store-ban van a postafiókjuk. Meg se kérdezem, látszik, hogy ez tipikus linked value tipusú tulajdonság. Az AD belső mechanizmusa mazsolázza össze a HomeMDB értékekből a HomeMDBBL (a BL a BackLink rövidítése) tömböt. Az meg csak egyszerű technikai megfontolás, hogy egyszerűbb a mazsolázás, ha a HomeMDB is linked value típusú.

Most gondoljuk el. Van egy Exchange szerverünk, ahol a konkrét store-ban van négyszáz postafiók. Jön az adminisztrátor, felvesz egy újabb felhasználót, postafiókkal. Amíg az LVR úgy működött, hogy mindig ment az egész tömb, ha akár csak egy eleme is megváltozott, addig volt itt nyüzsgés a dróton, rendesen.
De még így is kell trükközni a replikációval. Ilyen trükk, hogy először a DN-valued tulajdonságokat küldik át a replikációs ügynökök a túloldalra (ahol ugye az igazság lakozik) és csak utána jöhetnek a linked value tulajdonságok.

Érdekes dolgok sülhetnek ki ebből.
Vizsgáljuk meg a fenti példát.
Létezik olyan az Exchange-ben, hogy system policy. Ezen belül van olyan, hogy Mailbox Enable User Policy. Ő a felelős a postafiókokhoz tartozó mailnickname, homeMDB, homeMTA és msExchHomeServerName tulajdonságok kezeléséért. Felvettünk egy új felhasználót (igen, leesett az asztalról), az adatai feliratkoztak a replikációra. Most már tudjuk, hogy a homeMDB tulajdonság linked value típusú, tehát egy konkrét replikációs csomag rájátszásakor csak akkor kerül sorra, ha a többi érték már a helyére került. Leterhelt DC esetén ez akár 10-20 másodperc is lehet. Eközben viszont aktivizálódhat a Mailbox Enable User Policiy. Mit lát? A postafióknak már van mailnickname, homeMTA és msExchHomeServerName értéke (mert ezek már megjöttek), de nincs homeMDB értéke. Nosza, ad neki egyet. A helyi szerver default store értékét. Azaz lazán áthelyezte a postafiókot egy másik store-ba. Jó esetben akár még egy másik szerverre is. A legszebb az egészben, hogy mivel ez a módosítás történt később, így ez az érték fog szétreplikálódni a továbbiakban. Aranyos.
Itt található egy KB cikk, amelyikben leírják, hogyan kell módosítani a Mailbox Enable User Policiy szűrőparaméterét, hogy csak akkor induljon be, ha a postafióknak már van homeMDB értéke.
De nem csak ezt a policyt lehet behülyíteni. Gondolkozzunk el, mi történik, ha a recipient policyt például a homeMDB értékhez kötjük? (Ez egyáltalán nem nagy ügy: amikor kiválasztjuk azon postafiókok körét, amelyekre a megadott emailcímnek rá kell esnie, össze lehet kattogtatni olyan szűrőfeltételt, amelyikben szerepel, hogy mely szerver mely store-jára vonatkozzon a policy.)

Itt állítható be a szűrőfeltétel.

És itt látható a konkrét ldap filter – benne gyönyörűen a homeMDB vizsgálat.

Nos, vegyük elő a korábban felvázolt esetet. A replikáció még nem fejeződött be, a postafiók még nem kapta meg a linked value homeMDB értéket. Közben viszont beköszön a recipient policy – melyet ugye a homeMDB-hez kötöttünk. A feltétel nem teljesül, tehát a postafiók a default recipient policyben megadott címeket fogja első körben megkapni. A következő körben, amikor már meglesz a homeMDB értéke, megkapja a jó emailcímeket is, de a korábbi emailcímek nem törlődnek.
Mit lehet itt tenni? Egyszerű: barátaim, ne kössünk recipient policyt linked value értékhez.

Nos, ennyi. A bevezetőben említettem, hogy imádok elcsatangolni egy-egy cikk nyomán. Ez a mostani írás is így született, az ihletője pedig Bill Long szaki kíváló cikke.

5 Comments

  1. Íme, egy újabb példája annak, hogy az AD-ben dolgozni csak körültekintően szabad, mert nem mappákat meg fájlokat hozunk létre hanem igenis élő önálló valamiket, amelyeknek saját lelkiviláguk van… :)
    Én igyexem is körültekintő lenni amikor csak lehet.
    Köszönjük ezt a hasznos és érdekes fejtágító cikket!

    Hron György

  2. A cikk nagyon érdekes volt és olvasmányos :), de unixos szemmel nézve ez valami hihetetlen gányolás. :o KISS principle, ugye, hát ez szöges ellentétben áll azzal.

  3. Az a baj ezekkel a multimaster replikációjú címtárakkal, hogy egy idő után maguktól is meg tudnak bonyolódni – különösen ha elkezdik mindenre ezt használni, a programoló ember meg nekiáll optimálni.:)
    Egyébként én nem érzem annyira gányolásnak – elég nehéz elképzelni, hogyan lehetne egy ennyi funkcióval és elvárással rendelkező rendszert egyszerű állapotban tartani.

  4. De valóban szükség van ilyen bonyolult rendszerre?…

  5. Ma már nem igazán vannak egyszerű rendszerek. Ha lemész forráskód szintig, ott a legtöbb alkalmazás – különösen az ilyen AD/Exchange-félék nagyon meg tudnak bonyolódni.
    Egy rendszer szvsz akkor van jól megtervezve, ha ez a bonyolultság nem jelenik meg az üzemeltetés szintjén. Itt annak lehetünk tanúi, hogy időnként mégis.

Leave a Reply to JoeP Cancel reply

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

Discover more from MiVanVelem

Subscribe now to keep reading and get access to the full archive.

Continue reading