Category: mailbox

A mentés ronda lelkivilága

Ritkán szoktam az Exchange blogról linkelni, valahogy úgy érzem, hogy aki érdeklődik a téma iránt, az úgyis rajta lóg az rss csatornájukon. Most viszont kitettek egy nagyon-nagyon-nagyon hiánypótló írást, melyet mindenkinek el kell olvasnia, azoknak is, akik csak ezt a blogot követik. (“Ha én valamit szeretek magamban, az a szerénység.”)

Tömörítsek?

Amióta létezik olyan termék, hogy Exchange, állandóan visszatérő kérdés az adminok körében: kell-e tömöríteni az adatbázis, és ha igen, akkor mikor?

Rövid kitérő, ha valaki esetleg nemrég bújt volna még csak ki a tojáshéjból. Az Exchange-ben – eltekintve a régebbi verziók stm fájljaitól – egy adatbázis egy darab edb fájl. Ezen a fájlon belül vannak adattáblák, ahol az összetartozó adatok között pointerek teremtik meg a kapcsolatot. Amikor törlök egy levelet, akkor az egyik adattáblából törlődik a levél tartalma, és emellett törlődnek a rámutató pointerek is. Értelemszerűen hiába csökkennek az egyes adattáblák méretei, az edb fájl mérete nem csökken. A fájlon belül üres hely (whitespace) szabadul fel, de a sok, apró üres hellyel az Exchange nem tud mit kezdeni. Ekkor jön be a képbe az Online Maintenance folyamaton belül az Online Defragmentation, azaz online tömörítés: ez az edb fájlon belül az üres helyeket kimozgatja a fájl végére, így újra hasznosíthatók lesznek. Az online tömörítés, mint a neve is mutatja, online, azaz működés közben is végezhető. Csak éppen erőforrásigényes, emellett Exchange 2010 előtt szégyenlős is, ha túl nagy aktivitást észlel az adatbázison, akkor megáll. Márpedig az online tömörítés hiányában vészesen dagadni kezd az adatbázis. Sőt, ha valaki végiggondolja a folyamatot, akkor láthatja, hogy az online tömörítés mellett is dagadhat az adatbázis. Például kapunk egy tüskeszerű nagy terhelést. Egy nap alatt felhízik az adatbázis (betör egy spam), a felhasználók ugyan törlik a leveleket, de az online tömörítés csak az üres helyekkel tud játszani, az edb fájl méretével már nem. Ahhoz, hogy az utóbbi is csökkenjen, már más módszerekhez kell nyúlni.

Így jutottunk el az offline tömörítéshez. Ekkor lecsatoljuk az adatbázist és az edb fájlt átadjuk egy erre a célra kifejlesztett adatbázismatyizó programnak (eseutil). Ez nyit egy új, ideiglenes adatbázist, elkezdi átmásolni az értelmes tartalmat (nem, a levelekben már nem kutat értelmet), majd ha végzett, akkor az eredeti adatbázist törli, az ideiglenest pedig átnevezi. Visszacsatoljuk és jó esetben mindenki boldog.

Most jön egy újabb kitérő. Olvasdd el Paul Cunningham írását. Nagyon szépen körbejárja a témát, a végeredménnyel pedig csak egyetérteni lehet: az offline defrag nem az az elem, melyet a rendszeres, szabályozott karbantartási folyamatok során végzel. Mivel az offline defrag offline, és emellett kockázatos is, csak akkor van értelme, ha az adatbázis mérete már problémákat okoz. Pontosan miket is? Egyrészt kezd elfogyni a tárterület a diszken. Ekkor el lehet gondolkozni az offline tömörítésen, de ha nem szeretjük a kockázatot, akkor lehet bővíteni is a tárterületet. Másrészt – saját tapasztalataim szerint – az Online Maintenance időigénye az edb fájl fizikai méretével arányos. A nagy edb fájl hosszú Online Maintenance időt jelent és így már lehet, hogy a folyamat nem fér bele a kijelölt időablakba. Nyilván az időablakot ki lehet húzni, de ekkor összecsúsznak az adatbázisműveletek, neadjisten belecsúsznak a produktív időbe, ez persze újabb terhelés – és egész egyszerűen mire végetér egy online tömörítés, már megint töredezett az adatbázis. Értelemszerűen itt is eljárhatunk úgy, hogy bővítünk – több RAM/proci – de ennyire ne legyünk már nyulak. Ezzel ugyanis csak elodázzuk a probléma megoldását.

Ekkor úgy halványan felmerül az offline tömörítés utáni igény az IT csapatban. De biztos, hogy erre van szükségünk? Mi van, ha az adatbázis tényleg ekkora lett? (Jelzem, ha az adatbázis mérete meg lett tervezve, az összes postafiók mérete korlátos, akkor ez a kérdés érdektelen.) Ilyenkor lenne jó tudni, mennyi is a whitespace. Biztosan vannak szofisztikáltabb módszerek is, én egy közepesen bonyolult powershell parancsot szoktam használni:

get-mailboxdatabase | get-mailboxstatistics | measure-object -property itemcount,totalitemsize -sum

Ez a szerveren lévő összes adatbázisra kiírja, hogy mennyi item-et (levelet, kontaktot, naptárbejegyzést) tartalmaznak, illetve ezeknek mekkora az összesített méretük. Ugyanez létezik konkrét adatbázisra is:

get-mailboxstatistics -database name | measure-object -property itemcount,totalitemsize -sum
get-publicfolderstatistics | measure-object -property itemcount,totalitemsize -sum

Az adatbázisok fizikai méretét megtaláljuk a Windows Explorerben, ebből pedig tudni fogjuk, hogy az adatbázisban mennyi az adat jellegű tartalom adattartalma. Igen, nem véletlenül fogalmaztam ennyire körülményesen. A cikk elején is írtam, hogy az edb fájlban vannak olyan adattáblák is, melyek az adatok strukturálását, gyors elérését segítik. Ez az adatbázis overhead. Tervezéskor én 20%-kal szoktam dolgozni – mégem hidat méretezünk, ekkora pontosság bőven elég – azaz ha ennél jóval nagyobb a különbség, akkor tényleg itt van az ideje az offline tömörítésnek.

Vagy mégsem?

Jó hír azoknak, akik Exchange 2010-et üzemeltetnek, hogy ők már használhatják az offline tömörítést online is. Nem, nem golyóztam be, legalábbis még nem nagyon. Olvassuk vissza, mit csinál az eseutil: nem tudnánk ezt mi is elvégezni, az adatbázis lecsatolása nélkül? Létrehozunk egy új adatbázist, felcsatoljuk, a postafiókokat átmozgatjuk (csak az adattartalom megy át, a whitespace nem), a régi adatbázist lecsatoljuk, letöröljük. Kész. A kliensek nem a Mailbox szerverhez kapcsolódnak, hanem a CAS szerverhez, az meg mindig tudja, melyik adatbázisban van a felhasználó. Ezzel ki is húztuk az offline defrag mindkét méregfogát:
– Nem offline. Régebben könnyű volt az élet, ötkor megszólalt a gyárban a sziréna, a portás hatkor lehúzta a redőnyt, a rendszergazda ekkor kezdett ébredezni, majd éjjel lecsatolta az adatbázisokat és reszelgette. Manapság már nincs holtidő. A legtöbb alkalmazottnak van minimum egy emailképes kütyüje, és valami fura perverzióból éjjel is meg akarják nézni a leveleiket. Offline folyamat? Hogy gondolod.
– Bármennyire okos is az eseutil, egyszerűen nem tudjuk olyan alaposan paraméterezni, mit csináljon az értelmetlen adatokkal, mint ahogy egy postafiókmásolás esetében. Már nem kell rettegni attól, hogy az eseutil után kapunk egy annyira tömör adatbázist, hogy gyakorlatilag üres.

Mennyi is az annyi?

Feltehetően mindenki hallott már az Exchange adminok életét megkeserítő a remek stub alapú archiválási technikáról. Arról van szó, hogy egy külső gyártó terméke (pl Symantec Enterprise Vault) MAPI felületen végigszkenneli az Exchange kijelölt adatbázisait, majd a beállított feltételeknek eleget tevő levelekből (méret, időpont) a tartalmat kiveszi, átrakja a saját adatbázisába, az eredeti helyen pedig csak egy pointert hagy ott, mely az átmásolt tartalomra mutat.
Az elv még nem is lenne rossz – bár látjuk, hogy összességében helyet nem nyertünk, viszont az Exchange adatbáziskezelő műveletei felgyorsultak. Persze ennek ára is van, a csonkolt levelek elérése lassabb, egy disaster utáni recovery kész horror (pedig eleve sem egy leányálom), plusz adminisztráció, na meg több zsák pénz.

Most ne menjünk bele, hogy ennek van-e egyáltalán létjogosultsága Exchange 2010 alatt (itt ugye az adatbázisok maximális mérete a tera tartományban mozog). Tételezzük fel, hogy már van ilyen rendszerünk, megörököltük a korábbi Exchange verziónkkal. Jelen cikkben csak egy apróságra hívnám fel a figyelmet: hogyan lehet egy pitiáner tervezési hibával hülyét csinálni magunkból.

De előbb számoljunk. Exchange 2003 alatt a default blokkméret az adatbázisban 4 Kbyte, Exchange 2007 alatt 8 Kbyte. Azaz bármekkora is volt a levél, egy 4/8 Kbyte méretű stub marad a levél helyén. A felszabaduló helyet pedig az Online Maintenance visszadolgozza a szabad területek közé.
Az Exchange 2010 alatt a blokkméret 32 Kbyte lett. Gondoljuk el: akármekkora volt a levél, 32 Kbyte hely mindig foglalt marad a számára. Rólam tudni kell, hogy hajlamos vagyok több képernyő hosszúságú emaileket írni, de még ezek sem érik el a 32K méretet. Gyakorlatilag ezt a határt csak csatolással szokták átlépni – igaz, azzal nagyon.
Akkor mi is az a pitiáner hiba? Az, amikor úgy állítják be a külső rendszert, hogy alaphelyzetben a csatolásokat archiválja, de egy bizonyos idő eltelte (mondjuk egy év) után minden levelet. Ez az utóbbi húzás az, amelynek az égegyadta világon semmi értelme sincsen. A levél után ott marad a 32K hely, igaz, ezen belül a sok szöveg helyett csak egy link lesz benne – de a felszabaduló hellyel az Online Maintenance nem tud mit kezdeni. Foglalt marad. Cserébe megnyerjük, hogy plusz helyet foglalunk el az archiváló rendszerben, a felhasználó lassabban éri el a régi levelét, egyszerre kell gondoskodnunk mind a két rendszer rendelkezésreállásáról és kinlódhatunk mind a backup/restore, mind a DR folyamatainkkal.

Azaz, ha használunk ilyen külső rendszereket, akkor felejtsük el az idő alapon történő archiválást az összes levélre, koncentráljunk csak a csatolásokra. (A magam részéről pedig azt tenném hozzá, hogy gondolkozzunk el a Personal Archive és menedzselt mailbox kombináción, sokkal olcsóbban – és egyszerűbben – is el tudjuk érni ugyanazt, mint a külső cuccokkal.)

Hulljon a férgese

Biztosan sok emberben felmerült már, hogy milyen jó móka lenne rendszergazdaként a szerver konzolból látszólag véletlenül beletörölni a felhasználók postafiókjaiba. Az Exchange 2007-ben, illetve az Exchange 2010 RTM-ben erre a célre az export-mailbox parancs szolgált. Mind exportálni, mind törölni lehetett vele.
Az Exchange 2010 SP1-ben a fenti két funkció kettévált. Exportálásra a New-MailboxExportRequest parancsot kell használnunk.

Minket viszont sokkal jobban érdekel, hogyan tudunk törölni. Nos, bár fura, de logikus: a search-mailbox paranccsal. Tessék megnézni a kapcsolókat. Egyrészt megadjuk a keresési feltételeket, majd jöhet az akció definiálása. Az első lépésnél izgalmas lehet a -searchdumpster kapcsoló, a másodiknál pedig a -deletecontent. Ha mindkettőt alkalmazzuk, akkor a levelet az se menti meg, ha a felhasználó előrelátóan már korábban törölte. (De csak a kukáig.) Az összes paramétert nem fogom felsorolni, a fenti linken részletesen is megtalálható a magyarázatuk.

Habár a Pokoli Operátor sem rossz játék, de azért a parancsnak léteznek értelmes felhasználási területei is. Tudom, hogy nehéz, de képzeljük el, hogy a titkárnő szétküldött hivatalszinten egy államfői levelet, mely tele volt helyesírási hibával. Nyilván ez így blamálja az elnököt, akit nem fog érdekelni, hogyan, de tüntessük el a levelet a rendszerből. Természetesen tágabb értelemben el tudunk vele tüntetni bármilyen, meghatározható paraméterű (pl subject) szpemet, vírust és bármit, ha éppen nincs erre a célra dedikált külső alkalmazásunk.

Megint back pressure

Emailben kaptam egy kérdést és ez ráébresztett arra, hogy talán érdemes lenne ejteni pár szót erről az ‘apróság’-ról.

Megint a back-pressure. Az ezerszer elátkozott. Rengeteget gyaláztam már, könyvben, is, blogban is.
Itt az ideje, hogy meg is védjem. Egy kicsit.

Az Exchange ESE adatbázis-kezelése tranzakciós alapú. Erről most nem akarok túl sokat írni, a lényeg az, hogy a friss, illetve a frissen használt adatok főleg a RAM-ban és a logfájlokban vannak, az adatbázisba csak akkor íródnak ki, ha az alkalmazás éppen ráér. Az elmélet gyenge pontja az, hogy mi történik akkor, ha éppen elfogy a tárterület az adatbázisok alól? A korábbi verziók védelméből létezik még két placeholder fájl a logkönyvtárban, de két lognyi hely… nem tudok olyan gyorsan pislogni, amilyen gyorsan az elfogy.
Ezért találták ki a back-pressure-t. Hogy amikor egy kritikus érték alá esik a szabad tárterület, az Exchange állítsa le tisztán az adatbázisokat (clean shutdown), mielőtt azok inkonzisztens állapotban dőlnének be (dirty shutdown). Megáll a levelezés? Bizony meg. De a tárterület bővítése után simán visszaindul.

Az elv oké. Nem azzal volt a baj. Hanem azzal, hogy a 2007-es RTM-ben – mely közel egy évig volt kint a piacon – ezt a kritikus értéket 4 GB-re tették. Azaz ha egy 10 GB-s partíciódból elfogyott 6, leállt a levelezés, a közepesen tájékozott admin pedig szaladgálhatott, mint pók a falon.
Nem csoda, ha ez a feature az első számú közellenség lett az Exchange rendszergazdák körében. Elméletileg, ha nem is egyszerűen, de lehet hangolgatni, ki is lehet kapcsolni – de ehhez ismerni kell az elvet. Itt követte el a második nagy hibát az MS. Én biztosisten, 40 pontos betűkkel írtam volna ki minden Exchange cikk fejlécébe, hogy vigyázz barátom, errefelé tombol a back-pressure.

Aztán az SP1-ben már finomítottak a gyakorlaton, a leállás már csak 500 MB alatt következik be, ami, valljuk be őszintén, teljesen rendben is van. Ellenben a tájékoztatás… az még mindig tré.

Ezen próbálok most javítani, egy extrém szopási lehetőség bemutatásával.

Ugyan írtam már róla, de talán annyira nem volt hangsúlyos a felvetés. Tudni kell, hogy az Exchange 2007 alatt már a queue is adatbázis! Azaz minden olyasmi elv is vonatkozik rá, mint ami a többi adatbázisra. Spec a back-pressure is!

Gondold el. Kis cég vagytok, nem akarsz túl nagy feneket keríteni a dolognak, az Exchange-t simán feltelepíted a C: meghajtóra. Az adatbázisok természetesen külön diszken vannak, szabad tárhely, mint a pelyva. Hol is van ilyenkor a queue? Hát a C:\Program files\exchrsrv alatt valahol.
Az élet vidáman megy tovább. A pagefile nő, nődögél, a patchek is zabálják a helyet a C:-n, meg ott van az az istentudja mennyi rejtélyes folyamat, melyek mind fogyasztják a rendszerpartíciót. De amíg megy a rendszer, a fene sem veszi észre. Aztán egyszer csak megáll a levelezés.
Az adatbázisoknál bőven van hely. Oké, a C:-n annyira nem, de kit érdekel most a C:?
Hát például a művelt Exchange admint.

When the back pressure limits for hard disk drive space utilization are set to their default levels, the hard disk drive that stores the message queue database on an Edge Transport server or Hub Transport server must always have a fixed amount of free hard disk drive space. In Exchange 2007 RTM, the amount of required free hard disk drive space is 4 GB. In Exchange 2007 SP1, the amount of required free hard disk drive space is 500 MB. If the available free space is less than the required amount of free hard disk drive space, the hard disk drive utilization level is considered high. Therefore, all message flow stops. In that case, you must follow one of these steps:
– Relocate the message queue database to a different hard disk drive that has more free space. For more information, see How to Change the Location of the Queue Database.
– Increase the values of the PercentageDatabaseDiskSpaceUsedHighThreshold, PercentageDatabaseDiskSpaceUsedMediumThreshold, orPercentageDatabaseDiskSpaceUsedNormalThreshold parameters.
http://technet.microsoft.com/en-us/library/bb201658(EXCHG.80).aspx

Durva pofon, nem?

Persze elkerülhető lett volna, ha:

  • Az Exchange alkalmazást nem a C:-re telepíted, hanem egy külön alkalmazáspartícióra, mondjuk D:-re – és ezt a partíciót nem is használod semmi másra. Ekkor a szabad hely csak egy extra nagy levéltömeg bezúdulásakor lenne képes elfogyni.
  • Használsz valamilyen monitorozást. Ne mondd azt, hogy a SCOM baromi drága. Akkor tegyél fel linuxon egy nagios-t, abszolút ingyen van és – többek között – a szabad tárterületet is tudja monitorozni.
  • Legfőképpen pedig ismerd meg az eszközt, amit használsz. Tudod, a törvény nem ismerete nem ment fel a következmények alól.

Mythbuster

Ezt írtam korábban.

Utána egy csajszi Mythbuster stílusban verte a fejünkbe, hogy miket kell mondani, hogyha az Exchange kellemetlen tulajdonságairól faggatnak. Háát… a backup részt továbbra is csak kerülgették, mint macska a forró kását.

Nos, a varázsnak vége, a mítoszrombolás nyilvános lett. Igaz, itt csak éppenhogy érintve (nálunk másfél órás előadás volt), de a lényeg benne van. Pontosabban, a lényeg itt van: Large Mailbox Vision whitepaper.

Éj a szerverszobában – 02

Oké, szorgalmatos rőzseszedegető anyókaként kezdjünk el gyűjtögetni.

Rögtön van egy rossz hírem. Az eventlog nagy. Nem, még annál is nagyobb. És nekünk ebből kell kimazsolázni durván egy hónap Online Maintenance bejegyzéseit.

Akár fel is vehetnénk középső névnek a Hamupipőkét.

Nos, akinek szerencséje van, az Windows Server 2008-ra telepítette az Exchange szerverét. Itt ugyanis már tudunk custom view-t generálni az eventlogon belül. A Windows Server 2003 kedvelői… most így jártak. Hamupipőke.

Nagyítás

A fenti ábrán láthatók a custom view beállításai. Úgy gondolom, a kép magáért beszél.

Nagyítás

Ha beállítottuk, akkor a következő nézethez jutunk. Mekkora öröm, már… csak és kizárólag az OM bejegyzéseket látjuk. Nem mintha ebből nem lenne durva még kinyerni az összetartozó adatokat… de legalább már van némi esélyünk.

A következő event azonosítók vonatkoznak az Online Maintenance folyamatra:

  • 700: Online defragmentation is beginning a full pass on database XY
    Az XY adatbázison elindult az offline defregmentálás.
  • 701: Online defragmentation has completed a full pass on database XY
    Az XY adatbázison befejeződött az offline defregmentálás. Ekkor kiír egy csomó adatot. Az általa jelzett időtartamokkal ( x sec) bánjunk óvatosan, köszönő viszonyban sincsenek a mért értékekkel. Viszont az átmozgatott lapok száma hasznos információ: egy lap 8 KB (Exchange 2003-ban 4K), tehát ebből megtudjuk, mekkora hely (whitespace) szabadult fel az adatbázison belül.
  • 702: Online defragmentation is resuming its pass on database XY
    Korábban lezárt folyamat folytatása. (Egy folyamat lezáródhatott úgy, hogy váratlanul nagy terhelés érte az adatbázist, illetve lezáródhatott úgy, hogy letelt a folyamatra engedélyezett időablak.)
  • 703: Online defragmentation has completed the resumed pass on database XY
    Lezárult egy olyan folyamat, mely menetközben meg lett megszakítva.
  • 704: Online defragmentation of database XY was interrupted and terminated. The next time online defragmentation is started on this database, it will resume from the point of interruption.
    Az XY adatbázis online defregmentálása meg lett szakítva.
  • 717: Database checksumming background task has started.
    Elindult egy Online Checksumming folyamat.
  • 718: Database page zeroing background task has started.
    Elindult egy Page Zeroing folyamat.
  • 721: Database checksumming background task has completed.
    Lezárult egy Database Checksumming folyamat.
  • 722: Database page zeroing background task has completed.
    Lezárult egy Page Zeroing folyamat.
  • 723: Database checksumming background task encounters an error.
    A Database Checksumming folyamat közben hiba történt.
  • 724: Database page zeroing background task encounters an error.
    A Page Zeroing folyamat közben hiba történt.
  • 729: Database page zeroing has been paused.
    A Page Zeroing folyamat félbeszakadt.

Na, kérem, mindent tudunk. Már csak dolgozni kell.

Az első feladat lesz a legkönyebb: ne csináljunk egy hónapig semmit. Hagyjuk az adatbázisokat az alapértelmezett értékeken – és várjuk, hadd gyűljenek a bejegyzések.

Nagyítás

Az eventlogból kigyűjtött adatokat táblázatban összesítjük.

Igen, tudom, hogy erre a feladatra lehetne szkriptet is írni. De most levetkőzöm a rendszergazda mentalitást és azt javaslom neked is, hogy bogarászd ki egyenként az adatokat és szépen gépeld be mindet az Excel táblába. Hidd el, ennek hamarosan meglesz a jelentősége.
Ugyanis ahogy készen van a táblázat, jöhet az optimalizálás. Az egyetlen olyan feladat, amelyre nincs algoritmus. Csak te vagy és a józan ész.
Ezért fontos, hogy mire ide eljutsz, összebarátkozzál az adatbázisokkal. Ha egyenként gyűjtöd be az adatokat, akkor már menetközben össze fognak állni a történetek. Jellemük, viselkedésük lesz az adatbázisoknak. Lesz a lusta disznó. Lesz a lassú behemót. Lesz a szorgalmas cingár. Látod, hogy amíg az egyik nem és nem ér egy folyamat végére, mert mindig megszakad, addig a másik olyan sokszor zajlódik le, hogy rendszerint már nulla, vagy tíznél kevesebb lapot szabadít csak fel. Megtapasztalod, mitől függnek az időértékek.
Mire kitöltöd a táblázatot, előtted lesz az egész bagázs, mint osztályfőnök előtt a diákok az első év végén.

Optimalizáljunk.

Tételezzük fel, hogy CCR rendszerünk van, a backup a paszív node-ról megy, azaz az OM mehet az aktív node-on. Az egyszerűség kedvéért most ne foglalkozzunk a Database Checksumming folyamattal.

A munkaidőt természetesen tiszteletben tartjuk, tehát reggel 7 és este 7 között az üzleté a terep. Hétvégén viszont mi vagyunk, egész nap.
Ez annyi mint 5*12+2*24 = 108 óra.
Mennyi is jött ki a táblázatból?
21+9+9+21=60. Simán beleférünk. Mi itt a probléma?

Hát példul az, hogy az OM folyamatok nem annyira udvariasak, hogy pont az időintervallum elején induljanak el. Akkor általában már egy korábban félszakadt defrag fog folytatódni. Azaz, ha teljesen biztos akarok lenni abban, hogy egy héten belül biztosan lemenjen minden adatbázisra az OM, akkor dupla annyi időt kell kapniuk, mint amennyit mértünk. Ez 120 óra.
Annyi viszont nincs.
Jöhetnek a kompromisszumok.

A DB04 a VIP adatbázis. Itt nincs kompromisszum, sőt, ők inkább 44 órát kapnak, azt is összefüggően. A DB01 adatbázisban is vannak kritikus postafiókok, ők is megkapják a 42 órájukat. Viszont mi lenne, ha a maradék két adatbázis ugyanabban a szegmensben lenne? A szerver elbírja (úgyse dolgozik éjszaka rajta senki), és ha a maradék időt (108-44-42=22) adjuk oda nekik, akkor jó eséllyel mind a kettő le tud futni egyszer.

Nagyítás

Itt is van. A VIP 44 óra és nem szakad meg, a DB01 42 óra, de azért már szakadozik, a többiek meg majd csak ellesznek valahogyan.
De ez már egészen jó kiindulási alap.

Már csak egy lépés van hátra, belőni a backupot. Habár a két folyamat független egymástól, de célszerű a mentést rögtön az OM utánra időzíteni, így gyorsan el is takarítjuk a felesleges logfájlokat.

Nagyítás

És ugye nem felejtettük el, hogy negyedév múlva újra elvégezzük a vizsgálatot, megnézzük, hogy amit kitaláltunk, mennyire működik jól hosszú távon.

Hasznos linkek:

Éj a Szerverszobában – 01

A háttérben tessék elképzelni az Éj a Kopár Hegyen dallamát. (Ugye, a Sátán fellátogat a Földre, az őt imádó boszorkányok szombatjára.)

Nos, azt mi csak hisszük, hogy amikor estefelé végre becsukjuk a szerverszoba ajtaját és hazaindulunk, akkor a szerverek kismacskaként összekucorodnak és békés dorombolás mellett várják, hogy majd reggel megint eléjük borítjuk az ennivalót. Szervereink – ha jól vannak nevelve – akkor bizony éjszaka sem pihennek. Ilyenkor jön el általában a backup ideje – és természetesen a különböző adatbázis-karbantartásoké is.

A mostani írásban az Exchange szerver adatkarbantartási folyamataival fogok foglalkozni.

A backup-pal speciel nem. Meg később se nagyon. Az Exchange-t illetően jelenleg ez a legképlékenyebb terület, ahol éppen nem technikai megoldások, hanem koncepciók rivalizálnak.

Az adatkarbantartás, azaz nevezzük már nevén, az Online Maintenance, mindig is benne volt a termékben, de soha nem került úgy igazán a reflektorfénybe. Olyan félénk fajta a szentem. Pedig nem kellene szégyenkeznie, mert nagyon fontos szerepe van. Viszont egészen a 2010-es verzióig olyannyira visszafogottan viselkedett, hogy amint nagyobb terhelés érte az adatbázist, rögtön leállt. Azaz hiába időzítettük be adatbázisonként, hogy minden este fusson le, ha ráindítottuk közben a backupot is az adatbázisra, akkor az OM kiszállt a partiból. Majd holnap – gondolta. De ha másnap is jött az erőszakos backup… akkor az OM soha nem futott le végig.

Részletesebben a 2007-es verzióval fogok foglalkozni, de azért vetünk majd egy pillantást a 2010-esre is.

Adatkarbantartás. Mit is takar ez a fogalom? Miket kell csinálni azokkal az adatokkal, hogy karbantartva érezzék magukat?

A következő folyamatokról van szó:

  • Purge Indexes
    A törölt pointerek fizikai eltávolítása az indexfájlból.
  • Tombstone Maintenance
    A törölt elemek törölt státuszát jelző sírkövek menedzselése, lejárat esetén törlése.
  • Dumpster Cleanup
    A törölt elemek – egy beállítható ideig – nem kerülnek törlésre, hanem egy átmeneti tárolóba esnek be. Ezt hívjuk Dumpster-nek. Amint letelik az idő, véglegesen törlődnek.
  • Public Folder Expiry
    A nyilvános mappákban beállítható, meddig ‘élhet’ egy elem. Ezek lejártát vizsgálja a folyamat.
  • Age Folder Tombstone for Public Stores
    Hasonló a korábban említett sírkő kezeléshez. A különbség annyi, hogy nyilvános mappa esetén a public folder replikációt is figyelembe kell venni.
  • Folder Conflict Aging for Public Stores
    Azonos időben módosított nyilvános mappák konfliktusfeloldó folyamatának indítása. (Levelek küldése a két módosítónak.)
  • Update Server Versions for Public Stores
    A nyilvánosmappa replikációkhoz kapcsolódó verziószámok frissítése.
  • Site Folder Check for Public Stores
    Annak ellenőrzése, hogy az Administrative Group-on belül ne legyenek duplikált Site Folderek.
  • Cleanup Deleted Mailboxes for Mailbox Stores
    Azoknak a postafiókoknak a kezelése, melyekhez már nem tartozik tulajdonos felhasználó.
  • Check Messages Table
    Azoknak az elemeknek az eltávolítása, melyekre nem mutat pointer.
  • Online Defregmentation
    Tulajdonképpen ez az a folyamat, amellyel nagyon sokan összekeverik az Online Maintenace folyamatot. Tény, hogy ez a leglátványosabb eleme, de azért bőven nem csak ez játszódik le.
    Az Exchange adatbáziskezelésének a módszeréből következik, hogy a törölt elemek után lyukak maradnak az egy nagy fájlként látszó adatbázisban. Ezek a lyukak későbbi adattárolásra alkalmatlanok. Célszerűen az Online Defregmentation folyamat ezeket a lyukakat (whitespace) rendezi egy helyre, elérve azt, hogy az így kialakuló területek újra részt vehessenek az adattárolásban. Ezzel lehet biztosítani azt, hogy ha már az adatbázis mérete nem csökken, akkor ne is nőjön – feltéve, hogy az újonnan létrejövő elemek száma nem haladja meg jelentősen a töröltekét.
  • Database Checksumming
    Normál Exchange szerver esetén mentés során megtörténik a tranzakciós logok rájátszása az adatbázisra, emellett pedig lefut még egy adatbázis-integritás ellenőrzés is. Amennyiben CCR Exchange clusterünk van, amelynél a passzív node-ról mentünk, akkor az aktív node-on lévő adatbázisokra soha nem fog lefutni az integritás ellenőrzés.
    Ezt lehet úgy kivédeni, hogy engedélyezzük az Online Maintenance folyamatnak – mely ennél a felállásnál szigorúan az aktív node-on fut – hogy menetközben végezzen el egy integritás ellenőrzést is.
  • Database Page Zeroing
    Az Exchange adatbázisban egy elem törlése nem jelenti azt, hogy fizikailag is ki lett radírozva az elem tartalma. Pusztán csak az index jelzi, hogy ott már nincs elem.
    Amennyiben ez nekünk nem megfelelő, beállíthatjuk, hogy az Online Maintenance folyamat során a törölt elemek helyét nullával írja felül az Informaton Store szolgáltatás.

Az utolsó két folyamat csak az Exchange 2007 SP1 utáni rendszerekben működik és alapértelmezésben nincs bekapcsolva.

Mielőtt belecsapnánk a lecsóba, nézzük meg, mi a helyzet az Exchange 2010-ben.

A legnagyobb változás az, hogy kiszedték a karbantartási folyamatok közül az online defregmentálást. Ez innentől kezdve _állandóan_ fut, akármilyen terhelés is éri az adatbázist. Természetesen az Online Maintenance ütemezési lehetőségei továbbra is megmaradnak, csak éppen az elvégzendő feladat mennyisége csökkent.

Megváltozott a Database Checksumming is. Nem csak azért, mert átnevezték Database Scanning-re, hanem egy kicsit erőszakosabbá is tették. Na, nem nagyon, de ha egy adatbázis nem lett 3 napon belül egyszer átvizsgálva, akkor warning keletkezik az eventlogban.
Ennél is fontosabb változás az, hogy kétféle módban futtathatjuk:

  • Beállíthatjuk, hogy ez legyen az utolsó lépés az Online Maintenance folyamatban. Ez azért fontos, mert ha korábban olyan ablakot adtunk egy adatbázisnak, melyben szakadás volt, akkor az újraindulásnál nem az esedékes OM folyamat folytatódott, hanem mindig lefutott egy Database Checksumming. A hivatalos doksi szerint ez a mód főleg a kisebb adatbázisok esetében praktikus.
    Jó kérdés, mi számít kisebb adatbázisnak?

    This option works well for smaller databases that are less than 1 terabyte (TB) in size.

    Aha.

  • Beállíthatjuk azt is, hogy az online defregmentáláshoz hasonlóan a Database Scanning is 7/24-ben menjen.

Oké, térjünk vissza az Exchange 2007-hez.

Mit is tanultunk, mekkora lehet maximum egy Exchange 2007 adatbázis? Attól függ. Általában 100 GB a felső határ, de ettől egy speciális esetben eltérhetünk. Ha ugyanis CCR clustert építünk és elválasztjuk egymástól a két éjszakai orgiát, azaz a backup a passzív node-ról fut, az Online Maintenance meg békésen elpöfög az aktív node-on, akkor a felső határ felugrik 200 GB-re. (Nyilván az egésznek az az értelme, hogy záros időn belül esélye legyen az OM-nek lefutni. Ha a backup állandóan megszakítja, akkor nem lehet nagy az adatbázis.) Értelemszerűen ebben a helyzetben kötelező a Database Checksumming is, hiszen a backup elvégzi ugyan a passzív node-on az adatbázis integritásellenőrzősőt, de az aktív node-on ez nem történik meg.

Kitérő:
Érdekes kérdés, hogy CCR esetében hogyan megy át az OM hatása a passzív node-ra? Addig oké, hogy az aktív node-on buzeráljuk az adatbázist, jobbra-balra pakolgatjuk az adattáblákban az adatokat, döntögetjük a sírköveket, meg ilyesmik – de hogyan gondoskodunk arról, hogy mindez megtörténjen a passzív node-on lévő adatbázissal is? A kulcs: minden OM során elvégzett művelet bekerül a tranzakciós logba, az pedig, mint tudjuk átreplikálódik és előbb-utóbb rá is játszódik a passzív példányra.

Hohó, mondhatja ilyenkor a nagy horgász gyanakvó adminisztrátor, de akkor az OM több szekérderéknyi logot fog generálni! Jó az nekünk? Annyira nem… de ha ügyesek vagyunk, akkor úgy állítjuk be a mentést a passzív node-on, hogy az a konkrét adatbázisnál az OM ablak után nem sokkal induljon, így egyből el is tudjuk tüntetni a rengeteg logot. (Természetesen az OM ablak alatt egy másik adatbázis mentése simán futhat.)
Látható, ez igazából egy nagy csiki-csuki, egy kifejezetten embert próbáló optimalizálási feladat.

Mondjuk, egyszer belőttük. Ülhetünk-e nyugodtan a babérjainkon a továbbiakban? Nyilván nem. Az adatbázisok mérete folyamatosan változik. (Nő.) Igazából nem is ez a baj, hanem az, hogy egymáshoz képest máshogyan nő. Azaz lehet, hogy most a DB01 adatbázisnak kell adnunk a rendelkezésre álló idő 15%-át, mert akkora, de lehet, hogy egy fél év múlva a többi beelőzi és már csak 5% járna neki.

Rossz hírem van. Ezt az optimalizálási folyamatot célszerű negyedévente végigjátszani.

Ezért nem árt, ha kidolgozunk rá egy rögzített folyamatot. Erről fogok írni legközelebb.

Die PST, die!

Azt hiszem, egyetérthetünk abban, hogy ez az egész pst cucc már rég megérett a kidobásra. Egy dolog miatt nem tehetjük meg: nincs olcsó alternatívája.

Pontosabban, nem volt.

De előtte nézzük meg, mi is a baj a pst-vel? Leginkább az, hogy kígyó simaságú. Akármennyire is szeretnénk felelősen üzemeltetni a rendszerünket, a pst kisiklik a felügyeletünk alól. Ami addig nem is baj, amíg a felhasználó tudatában van, hogy pst-t használ, tudatában van, hogy rendszeresen mentenie kell, hogy a régi formátumú pst nem lehet 2 GB-nál nagyobb… meg ilyenek. A gyakorlatban ugyanis az van, hogy a felhasználó simán legyártja a pst-t, de nem tudja róla, hogy az egy fájl a vincseszteren, használja az autoarchivot és azt hiszi, hogy az a szerverre mentett. Aztán jön egy gépcsere, újratelepítéssel és jönnek az óriási sírások az elveszett borzalmasan fontos levelekről. A pst sérülésekről már nem is beszélve. Meg arról, hogy nem működik rájuk a Discovery (emlékszünk, a spionkodás), illetve egy notebook ellopása üzleti titkok kiszivárgásához vezethet.
Szükség viszont van rá, hiszen a postafiókok kvótázottak, ott nem tárolhatunk sokáig anyagokat – márpedig levelet nem törlünk, mert soha nem tudhatjuk, mikor lesz rá szükség. És akkor még nem beszéltünk egy kínzó dilemmáról: a pst-ket OWA-n belépve nem látjuk, ergo nagyon alaposan kell mérlegelnünk, mely leveleket húzzuk ki a personal storage-ba.

Ebből a bosszantó körből próbál kilépni az úgynevezett Personal Archive, azaz leánykori nevén Archive Mailbox (AMBX).

Nagyítás

A filozófia viszonylag egyszerű: legyen a felhasználónak a normális postafiókja mellett egy jóval nagyobb arcív postafiókja is. Ugyanabban az adatbázisban. A két postafióknak legyenek különbözőek a kvótái. Engedjük meg a felhasználónak, hogy szabadon áthúzogathasson ide leveleket, engedjük meg neki, hogy autoarchivot állíthasson be rá, sőt, mi magunk is tudunk úgynevezett retension policy-t rátenni, mely idő alapján dobálja ki automatikusan az archív postafiókba a leveleket.

Ennyi. Nem egy Enterprise Vault, de ingyenes eszköznek teljesen jó.

Első körben mondjuk elgondolkoztam, mi értelme is van ennek az egésznek – hiszen nem kellene külön két postafiókot kezelni, egyszerűen a felhasználó kapna egy jó nagy kvótát (normál + archív) és tárolhatna mindent egy postafiókban.
Végül két érvet találtam a Personal Archive mellett:

  • Rákényszeríti a felhasználót arra, hogy archívumban gondolkozzon. Hogy felelősen kezelje az anyagait, illetve vegye észre, hogy valakik felelősen kezelik helyette.
  • Amennyiben az Outlook-ot cached módban használjuk, akkor csak a normál postafiók szinkronizálódik le az ost fájlba.

Akkor nézzük a Personal Archive konkrét tulajdonságait.

  • Csak és kizárólag Outlook 2010-ből, illetve OWA-ból látszik. (Ilyenkor belegondolok, hogy kis hazánkban nem ritka még az Outlook 2000, mint céges sztenderd.)
  • Az előbb leírtam, de leírom még egyszer: látszik OWA-ból. Azaz a világ bármely pontjáról, ha az OWA ki van publikálva.
  • Gyárilag beépítve jön egy Default Retention policy. Ha egy felhasználónál engedélyezem a Personal Archive-ot, akkor ez élből ráesik. A tartalma: a két évnél öregebb leveleket kidobja az archívba.
  • Archív kvótának a Microsoft 30 GB-ot ajánl. (Mondjuk egy ekkora postaládától a 2007-es Exchange esetében biztos infarktust kaptunk volna.)
  • A Personal Archive-ot le lehet csatolni egy felhasználó postafiókjáról és 30 napon belül oda lehet adni más felhasználónak.

Végül néhány sceenshot arról, hogyan is néz ez ki valójában.

Nagyítás

Így kell engedélyezni egy felhasználónál. Nem egy pilótavizsgás eljárás.

Nagyítás

Imhol a konfigurálási lehetőségek: átírhatjuk a nevét.

Nagyítás

Itt pedig a kvótát állíthatjuk be.

Természetesen nem csak egyes postafiókonként tudjuk a személyes arcívumokat menedzselni: shellből teszőleges rugalmassággal állíthatunk elég sok mindent.

Egy kis esti adatbázis-kezelés

Ha már a DAG-gal foglalkozunk, nem mehetünk el egy másik nagyívű változtatás mellett.

Az Exchange 2010-nek igen durván átírták az adatbázisok kezelését végző részét. Illetve magukat az adatbázisokat.

Kezdték ott, hogy megváltoztatták az adatbázisok sémáját. Korábban egy postafiók adatait több adatbázisból kellett összeszedegetni. (Nem, nem több edb-re kell gondolni. Az edb fájl az egy nagy bináris blob, amin belül további kis adatbázisok találhatók.) A sémaváltozás lényege, hogy immár egy postafiók összes adata egy belső adatbázisban található. Ezzel két dolgot értek el: egyrészt kinyírták a SIS-t, másrészt begyorsították az adatbázis-kezelést.
Tudni kell, hogy a SIS (Single Instance Storage) trónja már a 2007-es Exchange szervernél is erősen ingott. Arról van ugye szó, hogy ha küldök egy levelet 10 embernek, akkor a levelet az adatbázisban csak egy példányban tároljuk, ahová az egyes postafiókokból pointerek mutatnak. Exchange 2007 alatt ez már csak a csatolásokra volt igaz – a 2010-nél pedig még azokra sem.
Mit nyertünk vele? Sebességet. Az Exchange fejlesztői már korábban is határozottan jelezték, hogy a sebesség vs tárhely optimalizálás vitában a sebességre szavaznak.

Hogyan lesz ebből sebességnövekedés? Az Exchange 2010 öszes adatbázis-kezelésre vonatkozó átalakítás mögött egy elv húzódott: a sok apró adatművelet helyett kevés, nagyobb adatterületet mozgató műveletek legyenek. A magyarázat roppant egyszerű: a sok kis műveletnél a fej össze-vissza ugrál a lemezen, míg a kevés, nagy műveleteknél sorfolytonosan tudunk dolgozni. Arról nem is beszélve, hogy az IO műveleteket adminisztrálni kell: minél kevesebb van belőlük, annál gyorsabban megy az adatkezelés. Értelemszerűen, ha átalakítjuk a sémát úgy, hogy az összetartozó adatok egymás mellett legyenek, a page méretet 8 KB-ról 32 KB-ra növeljük… ezzel mind-mind gyorsítottunk.

Persze ha ez így van, akkor jogosan kérdezheted, hogy miért nem lépték ezt meg korábban? Nos, a nagy adatbázisdarabokat valahogy kezelni is kellett, mégpedig a memóriában. Mióta vannak nagy memóriaterületeink? A 64-bites váltás óta. Melyik az egyértelműen és szigorúan 64-bites verzió? A 2010-es.

Persze nem csak sebességnövekedésről van szó. Tavasszal olyan értékeket mondtak Redmondban, hogy fel sem írtam: biztos voltam benne, hogy az én angolom béna és félrehallottam. De azóta többször meg lett erősítve írásban is, szóval a számok valószínűleg igazak: egy szerveren 100 vagy 150 adatbázis lehet (remélhetőleg házon belül egyszer majd lefocizzák a végleges számot), egy adatbázisról 16 másolat létezhet és egy adatbázis maximális mérete 2 TB. Nyilván az ajánlott postafiókok mérete is 2-10 GB közé szór, illetve a Personal Archívé 30 GB.

Impozáns, nem?

Természetesen ehhez nem csak gyorsítani kellett az adatbázis-kezelésen, kellett hozzá más is. Például az, hogy az adatbázisok alá mehet nyugodtan az olcsó hardver. Azért egy SAN fajlagos adattárolási költségével kalkulálva ezek a méretek minden IT vezető pulzusát felgyorsítanák. És kellett még egy nagyon fontos dolog: az Online Maintenance felpiszkálása. Még a 2007-es termékben is az Online Maintenance úgy viselkedett, mint egy határozatlan szűzlány. Be kellett időzíteni, hogy mikor dolgozhat az egyes adatbázisokkal, de ha munka közben intenzív tevékenységet észlelt egy adatbázison (pl. backup), akkor szégyenlősen visszavonult. Hogy majd legközelebb. Az Exchange 2010-ben az Online Maintenance _folyamatos_ és határozott.

Sokat lehetne ezeken a számokon agyalni. Én csak egy aspektusra hívnám fel figyelmet. Azért ezek a számok elég nyomós érvek arra nézve, hogy az Exchange fejlesztők miért utálják a backup/restore folyamatokat. Belegondoltál már egy 2 TB-s adatbázis visszatöltési idejébe?

Discovery Search

Az előző írásban létrehoztuk a szorcs nevű MRG-t, belepakoltuk Tudort. Most már csak tesztelni kellene.

De mivel?

Itt bizony komoly filozófiai problémába ütköztünk. Csináltunk egy kicsi admint. A gyakorlatban csinálhattunk volna akár száz különböző szerepkörűt is. Le van szabályozva, mit tehetnek. Oké. De hogyan fognak hozzáférni a rendszerhez? Telepítsünk mindenkinek Exchange admin tools-t? Na ne. Powershell ISE? Egy jogásznak?

Bajban vagyunk. Pontosabban lennénk, ha nem lenne a termék része az Exchange Control Panel, barátainak ECP.

Ez ismét egy webes szolgáltatás, a Powershell ISE cikkben látszik is az ábrán. Egy olyan webes szolgáltatás, melyhez először be kell autentikálnunk(1), aztán az RBAC alapján annyit adminkodhatunk… amennyit engedtek.

(1) Live ID vagy Form-Based Authentication (FBA). Mondjuk megnézném, ki az a Microsofton kívül, aki Live id alapú azonosítást használ.

Van is egy ábra, én ijesztgetésnek szoktam használni. A közepét ne is várd, hogy elmagyarázom. Az maradjon meg a fejlesztőknek.

Nagyítás

A felső blokk a böngésző. Habár a Microsoft ki szokta hangsúlyozni, hogy bármilyen böngészőn elmegy(2), azért az Ajax ismerete feltétel. Lynx-en nem fog futni.

(2) Ez olyannyira így van, hogy tavasszal Redmondban Firefox-szal demózták.

Az a szaggatott vonal a tűzfalat jelképezi. Az ECP áthasít rajta, a 80-as porton.
Alul pedig látjuk, hogy az ECP mögött – minő meglepetés megint a Powershell, pontosabban az Exchange tudással felvértezett Exchange Management Shell áll. (Mivel webszolgáltatás, így nyilván megint WinRM-en keresztül.)

Ennyi elmélet után gépeljük be: https://xch10-xch.xch10.tst/ecp, majd lépjünk be mondjuk Kukával.

Nagyítás

Nézzük, mit látunk. Pontosabban, mit nem látunk. Nincs neki legördülő menüje, szegény csak a saját postafiókjához fér hozzá. Azt nem mondanám, hogy semmi érdekes nincs, hiszen tele van a kép érdekességekkel(3) – de a Discovery Search funkcióval kapcsolatban tényleg nem látunk semmit.

(3) Az ECP pont az az újdonság, melyet írásban nem lehet bemutatni. Semmi kedvem 150 screenshot-ot betolni a blogra – anélkül meg nem megy. Viszont biztos vagyok benne, hogy hamarosan lesz egy csomó screencast a témáról. Ha már eddig nincs.

Menjünk tovább Tudorhoz.

Nagyítás

Hoppá. Van legördülő menüje és van Mailbox Search tabja. Sőt, látható, hogy van is egy bribe11 nevű sikeres keresése. Ha erre kattintunk, láthatjuk a keresés konkrét paramétereit.

Nagyítás

Például a szövegmezőben ott van a kulcsszó. A többi beállítás ablakát nem nyitom ki, a nevekből könnyen elképzelhető, mi rejtőzik mögöttük. Talán a Storage Location beállítás érdemel egy kis külön figyelmet: itt azt adjuk meg, melyik postafiókba kerüljön az eredmény. Ide nem kerülhet ám akármilyen postafiók, gyárilag létezik egy spéci mailbox (Discovery pampam qrvahosszúGUID), csak azt lehet kiválasztani.

Végül nézzük, mi történik, ha Tudor meg is akarja tekinteni a keresés eredményét?

Nagyítás

Pofonvágták. Nincs joga.

Helyes. Pont így is akartuk.

Csakhogy… akkor hogyan tudjuk _mi_ megnézni a keresés eredményét? Azt mondja a net, hogy létezik egy beépített Management Role Group, Discovery Management néven. Csak ennek a tagja tudja megnézni a keresés eredményét. Megnéztem… és a csoport üres volt. Gyorsan beledobtam Hófehérkét, vártam 10 percet, megnéztem – és ő már látta az eredményt.
Remek.

Nagyítás

De azért a kisördög nem hagyott békén. Én is csináltam egy MRG-t, volt egy gyári is… mivel tud többet a gyári?

get-rolegroup -identity “Discovery Management” | fl

Nagyítás

Látszik, hogy két szerepkör van hozzárendelve a csoporthoz: Legal Hold, Mailbox Search. Ezzel bizony nem vagyok kisegítve, a Legal Hold egyfajta cenzúrázásra visszatartási jogot jelent, a másikat meg mi is beállítottuk. Akkor? A megoldás kulcsa a Discovery mailbox jogosultsági tábláján látszik.

Nagyítás

Tehát a Discovery Management MRG csak úgy mellékesen Full Access jogot is kapot a Discovery mailboxra. Így könnyű.

Oké, ennyi mellébeszélés után nézzük meg végül, mi is lett a keresés eredménye.

Nagyítás

Hát, itt látunk is valamit… meg nem is. Egy újabb sorjás eszköz, egy újabb bájos hasraesés.

A helyzet az, hogy ez a csomó minden, amit én most irkálok, egy előadáson alapszik. A konkrét projektor 1024*768-as felbontást tudott, tehát a demózásra használt virtuális gép képernyője 800*600 lett. Ez teljesen kiakasztotta az Exchange 2010 webes szolgáltatásait. Egész egyszerűen erre a képernyőméretre nem készültek fel.
Tessék megnézni alaposan az ábrát. Direkt úgy vágtam ki, hogy teljesen lehessen látni a virtuális gép ablakát. Jobboldalt alul látható, hogy ott lenne még anyag, csak éppen kilóg a képernyőről. Ha kilóg, hát kilóg – mondhatnánk… ha lenne gördítősáv. De nincs. Vagy elfogyott a gyárban, vagy a böngésző gondolja azt, hogy azért még csak kifértünk.
Ernő elszámolta a pixeleket is.
Aztán ha még jobban megnézzük az ábrát, akkor jobb felül, a sárga részen láthatjuk egy fekete téglalap szélét. Megsúgom, az a felhasználó adatait tartalmazná… ott lehetne látni azt, ki van belépve és ott lehetne kilépni is. Azaz nemcsak a függőleges gördítősáv fogyott el, hanem a vízszintes is.

És akkor az ábra. Erről túl sokat nem is lehet mondani. A folder neve a keresés neve lett, alatta pedig felhasználónként folderekre bontva láthatóak az érintett levelek. Jobb oldalon pedig a híres-nevezetes conversation view lenne látható, ha befért volna a képernyőre. (Nyugi, később már nagyobbra állítom a felbontást.)

Ezzel elég jól körbejártuk az MRG, ECP, Discovery témaköröket – nem beszéltem viszont még a házirenden alapuló jogosultságosztásról.

Legközelebb az jön.

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.

Az okos lány

Aki jön is, meg nem is. Meg hoz is, meg nem is.

Jött a bejelentés az ügyféltől: amióta átmigrálták a postafiókját, azóta teljesen meghülyült a postafiókon belüli keresése.

Hmm. Mit tudunk?

Fél füllel hallottam róla, hogy az Exchange 2007-ben már nincs full text indexing, helyette mintha az oprendszer Windows Search szolgáltatását használná. Ennek némileg ellentmond, hogy ott figyel a szolgáltatások között a Microsoft Exchange Search Indexer… és valószínűleg nem csak azért van ott, hogy impozánsabb méretű legyen a szervízlista.
Mit tudunk még? A postafiók cefet nagy (ezért fontos nekik a keresés) – és a bejelentés előtt lett átmigrálva. Lehet, hogy még nem lett leindexelve? De a bejelentő azt állítja, hogy másnál is jelentkezik a hiba. Viszont tudjuk, hogy a bejelentők szeretik kivetíteni a bajukat a világra.
Még mit tudunk? Például azt, hogy a projekt magyar fázisának hajrájában vagyunk, ideges az ügyfél, idegesek vagyunk mi is (én meg aztán pláne) – egész biztosan nem fog beleférni az, hogy most pár napig ezen a jelenségen pörögjek. Végül át lett passzolva a probléma egy kollégának – de úgy, hogy azért követtem, mi történik.

Első körben reprodukálták a hibát. Sikeresen. Az idióta keresés megbízhatóan idióta volt kis postafióknál, nagy postafióknál, XP alatt, Vista alatt, Outlokból és OWÁ-ból, usernél is, atyaúristennél is. Egész pontosan így nézett ki a jelenség:

  • Egy konkrét kifejezés: B123456780. (Nem gépi kódban szoktunk társalogni, de a levelezéseinkben gyakran fordulnak elő case number-ek.)
  • Ha a teljes kifejezésre keresek rá, akkor megtalálja.
  • Ha leveszem az elejéről a ‘B’ betűt, akkor nem.
  • Ha leveszem a végéről a ‘0’-t, akkor megtalálja.
  • Ha köztes darabra keresek, akkor megint nem.

Kolléga sportolt rajta egy napig. Megrángatta a kapcsolati hálóját, feltúrta a netet… de minimális sikerrel. Addig biztosan eljutott, hogy meg tudtuk fogni a jelenséget. Az látszott, hogy a Windows Search került egyre inkább a célkeresztbe. Sikerült fájlnevekkel is reprodukálni az esetet. Kapott olyan visszajelzést, hogy igen, másnál is előfordult már ilyesmi. Aztán kapott olyan visszajelzést, hogy máshol, ahol szintén Exchange 2007 van, nem jelentkezik a hiba. Ergo van megoldás, csak annyira nem triviális.
Mivel az ügyfél kiemelt prioritással jelentette be az esetet, így 1 nap nyomozás után eszkaláltunk. PSS.

Lefutottuk a kötelező köröket, majd jött a határozott válasz: emberek, ez nem bug, hanem feature.
Tudom, ez már közhellyé kopott, de jelen esetben véresen komolyan gondolták a választ.

Exchange 2007 alatt ugyanis kétfajta search metódus is működik:

  • Exchange Search
  • Exchange Store Search

Melyik mit tud?

Exchange Search:

  • Gyors.
  • Szavakon, kifejezéseken, mondatokon alapszik.
  • Full-text indexet használ.
  • Csatolásban is tud kereseni, feltéve, ha van a szerveren megfelelő filter.
  • Érzéketlen a kisbetű/nagybetű különbségre.
  • Csak szöveg keresésére alkalmas.

Exchange Store Search:

  • Lassú.
  • A postafióktartalmat bitfolyamnak észleli, szekvenciálisan keres.
  • Index helyett folytonosan keres.
  • Nem keres a csatolásokban.
  • Érzékeny a kisbetű/nagybetű különbségre.
  • Nem szöveg jellegű tulajdoságokra is képes keresni.

Na, melyiket szeressük? A fejlesztők az elsőt, az Exchange Search keresést tették alapértelmezetté.

Csakhogy. A cikk végén jön a fekete leves.

Exchange Search and Localization

Localization support for Exchange Search is limited to scenarios in which the client locale matches the message locale (which must also match the language that is used in the message body). Exchange Search does not support instances where a single message has multiple languages embedded in the body or where the client locale is different from the message locale.
To get consistent results for localized searches, the following must be true:

  • An e-mail message must be written in a single language and that language must match the locale of the message.
  • The search expression must be in a single language.
  • The language must match the locale of the client computer, as identified by the connection to the server.

Na, kérem. Megérkeztünk. Milyen nyelven íródott az, hogy ‘B123456780’? Hát, izé. Ez bizony értelmetlen szó az Exchange Search számára.

A furcsa az egészben az, hogy valamennyire azért beindexeli, hiszen a teljes szót megtalálja. Ahogy a kolléga magyarázta – akinek a PSS magyarázta – az Exchange Search balról jobbra indexeli le a kifejezéseket. Tehát a fenti esetben megtalálja, ha a teljes szót írom be és megtalálja, ha balról tetszőleges számú karaktert írok be… de nem találja meg, ha hiányzik a szó eleje.
Feltéve, hogy egy nyelvet használunk a teljes levélben.

Mire jó egy ilyen kereső algoritmus?

Semmire.

Nekem egyből a tíz évvel ezelőtti pentiumos vicc jutott eszembe – amikor a procik bizonyos lebegőpontos műveleteket hibásan végeztek el.
– Mennyi 2+2?
– 5!
– Ez hülyeség!
– De milyen gyors voltam!

Szóval, erről ennyit. Úgy látszik, még mindig nem értik, hogy a keresés az alapvetően bizalmi dolog. Az ember azért használ keresőt, mert hatalmas, manuálisan már nem kezelhető kupacból kell előkeresnie egy konkrét elemet. Általánosan is elmondható, hogy ezek a kupacok akkorák, hogy lehetetlen leellenőrizni a keresőt, hogy tényleg megtalált-e minden előfordulást. Ergo elég csak egyszer rajtakapni az algoritmust, hogy hibázott… és onnantól mehet a kukába a keresőgép.

Szerencsére meg lehet változtatni az alapbeállítást, itt van hozzá a manuál.

ps. Számomra azért is volt nehezen értelmezhető ez az egész, mivel létezik korrekt megoldás a problémára. Igaz, kliens oldalon… de nem lehet zavarba hozni törmelék szavakkal sem.

Adatbázis rodeó

Ez egy érdekes alkalom. Tulajdonképpen le kellene írnom egy esetet… de a jelenséget Zoli már leírta, a megoldási lehetőségeket pedig bőségesen kitárgyaltuk a kommentek között.

Akkor mit akarok én itt?

Hát, például összefoglalni. Meg fut éppen egy projektem – és ez a szívás is része volt. Szóval, hajrá.

Karácsony előtt járunk. Az erdő szélén farkasok üvöltenek, a plázákban meg a tolakodó emberek – azaz igazi karácsonyi hangulat van. December 19-én, pénteken az utolsó címlistát is benyeleztem, elégedetten toltam hátra billentyűzetet. Idén is megtettünk mindent, amit ember tehetett. Meg egy kicsivel többet is. Hazamentem. Pihenni. (Mwhaha.)

December 20. Aranyvasárnap szombatja. Az ajándékozási ösztön már a levegőt is kiszorította a plázákból. Mivel mi idén nem vettünk senkinek semmit, angyali békességben készültünk a karácsonyra. Főzőcskéztünk, tettünk-vettünk.

Aztán csörgött a telefon. Kollégám keresett. Hogy mozgatná a postafiókokat, de kardjába dőlt a szerver. Betelt a logpartíció.
– Te, be kellett volna kapcsolni a circular loggingot – korholtam meg enyhén – hiszen mondtam is.
– Bekapcsoltam.
– Igen? Hm… Most is be van kapcsolva?
– Persze.
– És a logok ennek ellenére is kidagadtak a fazékból?
– Ki bizony.
– Hm… ez érdekes. Miaf?
– Ja.
– Oké, elöször rakjunk rendet, nyomozni ráérünk utána is. Csapjatok pár gigát a partícióhoz, mountoljátok fel az adatbázist, kapcsoljátok ki-be a cirkuláris logolást. Ennek meg kell ennie a logokat.

Így is történt.

Kolléga hívott kicsit később.

– Rendben, működik.
– Örülök. Találtál valami nyomot?
– Igen. Az ügyfélnél tesztelnek egy webes ügyfélszolgálati programot. Beismerték, hogy véletlenül ráküldtek 180000 levelet a rendszerre.
– Hogy az a @&xß$…! Hát ezek teljesen meghülyültek? Migráció közben? Úgy, hogy nem is szóltak?
– Azt mondták, véletlen volt.
– Ennél még a fiam is fantáziadúsabb kifogásokat tud! Na, mindegy. A lényeg, hogy túléltük. Akkor most minden oké?
– Ja.
– Akkor hajrá. Migráljatok tovább.

Vissza a karácsonyi hangulatba. Finom ebéd, Nej remekelt. Szieszta.

A telefon csörgése ébresztett.

– Te, megint betelt a log partíció.
– Mfmvmf?
– Megállt az Exchange cluster. Betelt az egyik log partíció.
– Asztakurva.
– Mit csináljunk?
– Amit délelőtt is. Meg hívd fel a tesztelőket és helyezz kilátásba egy élvekibelezést, ha nem mennek legalább két méter távolságba a billentyűzettől. Mondjuk, egy évig.
– Oké.

Innentől nem is volt baj, egészen január 5-ig. Az új év első munkahelyi hívása útközben ért. (De még mindig jobb volt, mint tavaly.)

– Megint betelt a log partíció.
– Micsoda? Mi az, hogy log? Meg partíció?
– Exchange szerver. Tranzakciós log. Kaput. Finito. Konyec.
– Ja, már rémlik. Tudjátok, mit kell csinálni. Hamarosan bent leszek. Ja, és le kell ordítani a hajat a tesztelőkről. Egyáltalán, tesztelnek most?
– A service fut.
– Leállítani!
– Oké.

Cifrázta a helyzetet, hogy mind december 20-án, mind január 5-én mentés teszt is volt. Nem is akármilyen téttel. Nem is akármilyen mentésé.
CCR rendszerről van szó és én VSS alapú mentést álmodtam a passzív node-ra. Mert így egyfelől meg lehet növelni az adatbázisméretet (el se hiszed, milyen kevés betű van az angol ABC-ben), másfelől így az a rövid éjszaka is elég lesz mindenre. Egy valamivel nem számoltam: ez a mentési mód teljesen új volt az ügyfél rendszerében, hiányoztak a tapasztalatok, hiányoztak a kliens szoftverek. Rengeteget kellett volna tesztelnünk. Csakhogy akárhányszor elindítottunk egy mentést, annyiszor vadult be a legelső adatbázis. És ekkor már két hete ment a rendszer, kezdtek üzemszerűen is feltelni a log partíciók.
Csak nem a mentés lenne az, ami behülyíti a rendszert?

Ebben az állapotban olvastam újra Zoli írását. Nem-e lehet-e? Tudom, ezzel már hárman ülnek a gyanúsítottak padján… de mind a három eléggé esélyes.

Az első kettővel túl sokat nem tudtam kezdeni. Maradt a harmadik.

Eleve itt van a Snefi által linkelt KB cikk. Elolvastam. Hajjaj, de hányszor olvastam el. És folyamatosan úgy éreztem, ez a recept arra, hogyan lehet birkavesével földrengést előídézni. Mi köze lehet egy operációs rendszer hibájának ahhoz, hogy bizonyos nyelvi beállítások esetén elhasal rajta az Exchange 2007 adatbázis-motorja?
És mi az a másik, rejtélyes patch, melyet Snefi említett?
Oké, hívjuk a PSS-t.

Rövid idő alatt ki lettem kupálva. (Bigup for Madaras Gábor.) Tehát tényleg van egy operációs rendszer szintjén előbukkanó hiba. Ez egy olyan hiba, mely – bizonyos nyelvi beállításoknál – az Exchange ESE motorját végtelen ciklusba zavarja. Meg lehet figyelni, amikor bevadul a log, igazából nincs is levelezési tevékenység. (Check the Message Tracking Log.) A patch javítja a hibát… de nem javítja az adatbázist. Ez ugyanis olyan, mint egy vírus: ha egy adatbázis bekapja, akkor vége. Hiába gyógyul meg a szerver, az adatbázis élete végéig köhögni fog.
Két megoldás létezik rá:

  • Gyógyszert adunk az adatbázisnak.
  • Megöljük az adatbázist.

Én, személy szerint, az utóbbi megoldást favorizálom. Valahogy… olyan véglegesebb.

De nézzük először az első megoldást. A gyógyszert úgy hívják, hogy interim fix. Azért interim, mert menetközben lett rajtakapva. Tudni kell, hogy a csomag, amelyből majd a rollup pack lesz, az idők során folyamatosan gyűlik. Amíg nem lesz belőle végleges Rollup Pack, addig interimnek hívják.
Azaz az a javítás, mely kikúrálná az adatbázisunkat, jelenleg még csak interim formában létezik. Ráadásul RU7 formában, azaz saccra csak nagyon sok hónap múlva lesz véglegessé. Miközben az interim patch nem egy barátságos jószág, de nem ám. Például nem lehet Rollup Pack-ot telepíteni rá. Ha feltennéd, akkor – mivel ez egy RU7 interim, eleve le is mondhatsz a RU6-ról. Hadd ne részletezzem, mennyi balhé lehet ebből, akár csak a legegyszerűbb PSS eszkaláció esetén is.

Szóval inkább akasszuk fel.

Ehhez bizony neki kell gyürkőzni. A felakasztás ugyanis egész konkrétan offline defregmentálást jelent. Miért is? Mitől gyógyíthat egy tömörítés? Attól, ahogyan tömörít. Az offline defrag ugyanis nyit egy új, temporary adatbázist, ebbe elkezdi átmásolni a még értelmezhető leveleket. Amelyeket nem tud értelmezni, azokat kihagyja. Kihagyásra kerül minden szemét, minden sérült ezmegaz. Csak azok az itemek kerülnek át, amelyek teljesen jók. (Ez a folyamat időnként meglepően pici új adatbázist eredményez. Ezért kell feltétlenül menteni is előtte.) A legvégén pedig törli az adatbázist, a temporary-t pedig átnevezi. Ezzel a módszerrel a fertőzés tuti kiesik, hiszen azt a másoló folyamat sem képes átvinni.
Miért nem vadul be offline defrag közben az adatbázis? Azért, mert ekkor az adatbázsi le van mountolva. Az Information Store service nyüsszögve kussol a sarokban.

Frissítsük csak fel, hogyan is van ez?

Az Exchange adatbázis-kezelésének legmélyén van egy ESE motor. Ez egy nagyon primitív motor, kifejezetten egyszerű utasításokat képes megérteni. Ez fölött van egy database layer – tulajdonképpen címfordítási céllal – majd jön a DSA, mely képes minden hozzáfordulóval megtalálni a közös hangot… és képes a kéréseket lefordítani az ESE hótprimitív nyelvére.

Nagyítás

Tudom, ez nem Exchange. Ez Active Directory. De ne felejtsd el, hogy az utóbbi az előbbiből nőtt ki.

Tehát, a lényeg az, hogy az ESE szempontjából az Information Store is csak egy ügyfél a sok közül. És amikor lemountolod az adatbázist, akkor az IS elveszíti fölötte a hatalmát.
Jöhetnek a többiek, az offline adatbázis-matyizók. Mint például az eseutl. Ez ugyanúgy a DSA-t keresi meg, konkrét kérdésekkel, mint az IS. De mégsem IS.

Tehát ha offline tömörítesz, akkor menetközben védve leszel ettől a misztikus hibától. Ráadásul a végső adatbázis is tiszta lesz. Nem kell vacakolnod az interim fix okozta megkötésekkel.

Ql.

Akkor mi a probléma?

Az idő. Az ügyfelünk magyar viszonylatban a felső-közép kategóriába tartozik, összességében 500 GB adatbázissal. A Microsoft szerint az offline defrag 5-10 GB/óra sebességgel tép. Ez testvérek között is 50-100 óra leállást jelent az ügyfélnél. Ha esetleg nem lennél jó fejszámolásban, akkor ez 2-4 nap. Levelezés nélkül.

El tudod képzelni?

Muszáj lesz. Ez az egyedüli értelmes kiút. Telepíteni kell a patch-et, majd offline defrag-gal gyógyítani az összes adatbázist. Az interim fix… több megkötést hoz, mint amennyi előnyt a leállás nélküli javítás jelentene.

Tesztelve.

Kliens trotyli, avagy hátrébb az agarakkal

Valljuk be, az embernek ritkán van lehetősége ipari környezetben pontos kisérleteket végezni. Meg lehet tervezni a kísérletet virtuális gépen… de köztudott, hogy a méretkülönbségek miatt nem számíthatunk arra, hogy az éles környezetben minden ugyanúgy fog menni, mint a laborban.
Amikor nemrég átállítottuk egyik ügyfelünk levelezési rendszerét Exchange2007-re, volt egy olyan időszak, amikor enyém volt a pálya. Rendes, ipari erősségű szerver dübörgött a gépteremben, 1 teszt user postafiókja volt csak rajta. Remek lehetőségem nyílt arra, hogy kimonitorozzam, 1 átlagos felhasználó mekkora terhelést okoz egy valós szervernek. Vannak rá ügyes perfmon counterek, ezek közül ez érdekelt engem konkrétan: ‘RPC operations per second per user’. (Természetesen nem a perfmon-ból vizsgálódtam, vannak az EMC-ben erre a célra felingerelt varázslók bőségesen a Tools menüpont alatt.) Nagyjából annyit illik erről az értékről tudni, hogy ha az értéke 0,25 fölé megy, az már gáz.
Ekkortájt hülyült meg a laptopom, időnként be-bevillantott egy-egy kékhalált. Mivel az Outlook-om cached módban ment, ilyenkor nyilván jönnie kellett egy ost adatbázis reparációnak is az újraindítás után. Nos, ezt is lemonitoroztam… és kikerekedett rendesen a szám: a mutató 0.41-re lendült ki.
Próbáljuk meg értelmezni:

  • Nyilván ahhoz, hogy a szerveren tárolt adatokat össze tudja vetni az ost-ben tárolt adatokkal, rengeteg információt kellett MAPI-n keresztül lerántania a szerverről. Márpedig a MAPI az RPC.
  • Valószínűleg az “extrém nagy” terhelés meg se kottyant a szervernek, hiszen egyedüli felhasználó voltam, azaz a “per second per user” érték lehetett nagy, de az abszolút terhelés bőven normálison belül maradt.

Ennek ellenére mégis érdemes elgondolkodni a számon. Sok felhasználó esetén nem tudhatjuk, ki milyen kérésekel bombázza a szervert: az ost reparálás mellett bejátszik a desktop search is, amennyiben beállítottuk, hogy az legyen a keresőnk az Outlook alatt, de ugyanígy bejátszik, ha alternatív keresőt – pl. lookout – használunk, bejátszhatnak archiváló szoftverek, bejátszhat egy CRM… bejátszhat minden, ami a postafiókot piszkálja. Ja, és bejátszhat a felhasználó is, pusztán azzal, hogy használja az Outlook-ját: levelez, megbeszélést szervez, kontaktok között keres.
A kérdés: mi történik, ha túlterheljük a szervert? Ha túl sok RPC kérést kap?

Alapvetően három viselkedési mód képzelhető el:

  • A szerver megpróbálja kiszolgálni az ígényeket, csak gyűjti, gyűjti… aztán halk sóhajtással összeszakad. A levelezés megáll.
  • A szerver, amikor észreveszi, hogy baj van, nem bír többet, nemes egyszerűséggel nem foglalkozik a bejövő kérésekkel, amíg nem lesz rájuk erőforrása. Ekkor néhány kliens fogja úgy érezni, hogy a szerver nem működik – dea többiek makacsul nyomulnak.
  • A szerver, amikor észreveszi, hogy baj van, akkor visszaszól. Egész pontosan azt fogja mondani a nagy terhelést okozó klienseknek, hogy lassítsatok be, nem bírom feldolgozni a kéréseiteket.

Nyilván az első mentalitás halálos. Nem szeretjük. A másodikat se túlzottan, de már megszoktuk: az Exchange szerver eddig ugyanis így működött. Eddig. Az Exchange 2007 SP1 viszont átváltott a harmadik módszerre. Ezt hívják úgy, hogy client throttling, azaz kliens fojtogatás.

Nézzük a részleteket. A szerver kezd lemerülni. Ekkor gyorsan beazonosítja, kik azok a kliensek, akik a legnagyobb terheléseket okozzák, majd küld nekik egy-egy pofabe üzenetet. Ezt úgy hívják, hogy back-off. Aztán mit mond erre a kliens? A nevelésétől függ.

  • Az Outlook 2007 kliensek úgynevezett ropBackoff üzenetet kapnak. Ebben benne van az az információ, hogy mennyi ideig ne próbálkozzanak új RPC kéréssel. De mi van, ha a kliens csak azért is próbálkozik? A szerver türelmesen küld neki egy újabb ropBackoff üzenetet, módosított időlimittel.
  • A korábbi kliensek nem értenék ezt az üzenetet, ezért nem is ezt kapják. Helyette a szerver a képükbe tol egy RPC_S_SERVER_TOO_BUSY üzenetet. Ilyenkor a kliens beállításától függ a várakozási idő. Alapban 1 másodperc. Aztán ha túl sűrűn kapja vissza ezt az üzenetet, akkor bontja a kapcsolatot és kiírja, hogy az RPC szerver nem elérhető.

Aki komolyabban is kíváncsi a jelenségre, perfmonból meg lehet tekinteni. A countert úgy hívják, hogy RPC Client Backoff/sec. Vigyázat, más nagyságrendeket fogunk látni, attól függően, hogy milyen klienseink vannak: ropBackoff üzenetek sokkal sűrűbben keletkeznek, pont a finomabb szabályozás érdekében. A normál értékek: Outlook 2007: 50/kliens, korábbi Outlook kliensek: 1/kliens. Azaz a korábbi kliensek csak 1 pofont kapnak, de az jó nagy.

Mi van még? Igen, lehet állítani azt a küszöbértéket, amikortól a szerver úgy érzi, hogy baj van. Természetesen registry varázslással. A magam részéről úgy vélem, átlagos környezetben erre nincs túl nagy szükség. Bízzunk a szerverben, csak tudja, mikor fárad el. Amennyiben valaki mégis állítgatni akarja, akkor ebben a cikkben megtalálja a szükséges matekozást.

Kinyírják SIS-t?

A szemetek.

De tényleg. Egy kicsit nem figyelek oda és majdnem lemaradtam egy érdekes fejtegetésről. Arról van ugyanis szó, hogy létezik az Exchange adatbáziskezelésében egy metódus, az a neve, hogy Single Instance Storage, azaz SIS. Vén, mint az országút, már az Exchange 4.0-ában is létezett. Az elv lényege az, hogy ha egy levelet több embernek is elküldtek, akkor adatbázison belül csak egy példány létezett belőle, a felhasználók postafiókjaiból pedig pointer mutatott erre az egy példányra.

Nos, az Exchange2007 esetében úgy döntöttek, hogy nem igazán van szükség SIS-re. Miért is? Először is a – maximálisan lehetséges – 50 adatbázis miatt. Ha ugyanis kellően nagy postafiókokat szeretnénk adni a felhasználóinknak, azt úgy tudjuk csak elérni, ha sok adatbázist hozunk létre. Mennyi értelme van ilyenkor a SIS-nek? Elég halvány, tekintve, hogy lecsökken annak az esélye, hogy a címzettek ugyanabban az adatbázisban lesznek. Ráadásul nézzük csak meg, mit nyerünk, mit vesztünk? Nyerünk merevlemezterületet, vesztünk adatkezelési sebességet. Mennyibe kerül a merevlemezterület? Bagó. Mennyire fontos a levélkezelés sebessége? Baromira.
Nem jó üzlet.

Ezért a fiúk nemes egyszerűséggel úgy döntöttek, hogy az Exchange2007-ben a levelek törzsére megszüntetik a SIS-t, egyesül a csatolásokra hagyják meg. És erősen gondolkodnak, mi legyen vele a következő verzióban.

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ő.

Az a bizonyos postafiókméret

Megéri néha visszanézni régi írásokhoz, mert időnként a komment rovatban érdekesebb dolgokról olvashatni, mint magában az írásban.
Különösen, ha a téma az Exchange IGCs(1), az adminisztrátorok örök vesszőparipája, a méretkorlátozás.

Nézzük először a cikket.
Röviden összefoglalva, arról szól, hogy kvótázatlan mailbox rossz, maibox kvóta jó.

Ha korlátlan postafiókot használsz, a következőkre számíthatsz:

  • Egy DOS támadás lebéníthatja a levelezőrendszeredet.
  • Nem tudsz rendszerkapacitást méretezni.
  • A hálózati forgalmad várhatóan növekedni fog.
  • Mindez persze pénzbe kerül.
  • Na meg teljesítménybe.

Persze figyelned kell arra, hogy a kvóta nem megoldás, hanem csak a megoldás része, Mellette szükséged lesz még a következőkre:

  • Felhasználói oktatás – a postaláda nem fájlszerver.
  • Alternatív megoldás biztosítása: pl. Sharepoint.
  • Megfelelően méretezett mentési megoldások. (Stub otthagyása levél helyett.)

Ha ki akarsz mászni ebből a lehetetlen helyzetből, akkor a következő teendőid lesznek:

  • Csoportosítsd a felhasználóidat levelezési szokásaik, igényeik, erőszakosságuk (VIP) szerint.
  • Határozzál meg számukra postafiók limitet.
  • Határozzál meg melléjük különböző erősségű figyelmeztetési limiteket (irgumburgum, dupla irgumburgum).
  • Az IT és a többiek között legyen szerződés. (SLA, ha külső IT van, OLA, ha belső.)
  • Csoportosítsd át a felhasználókat a megfelelő mailbox store-okba.
  • Biztosíts időt a levelek archiválására, törlésére.
  • Állítsd be a korlátokat.

És ha már ennyire belejöttünk a korlátozásba, gondolkodjunk el a maximális levélméret szabályozásán is.

Mi történik velünk, ha nem szabályozzuk a maximális levélméretet?

  • Már megint kaphatunk egy DOS-t.
  • Nem fogunk tudni kapacitást tervezni.
  • Nem fogunk beleférni a mentési időablakba.
  • Lehal a vírusellenőrzésünk.
  • Na meg a spam ellenőrzésünk is.
  • Végül a hálózat is megy velük.

Kimászási metódus:

  • Monitorozzuk a levélforgalmat, hogy egyáltalán lássuk, mi folyik a szervezetben.
  • Határozzuk meg a maximális levélméretet.
  • Keressünk alternatív megoldásokat attachment továbbításra: Sharepoint, file szerver.
  • Állítsuk be a korlátozást – de soha ne a virtuális SMTP szerveren, mindig csak konnektoron. (Hacsak nem akarjuk agyonvágni a Public Folder replikációt.)
  • És persze egyáltalán nem utolsó sorban, erre is terjedjen ki az SLA/OLA, melynek teljesülését monitorozzuk.

Végül Russ mentegetődzik, hogy ezek szép elvek, de az Exchange2003 még nem ad meg minden segítséget. De bezzeg az Exchange2007 / Outlook2007 páros maga lesz a tejjel-mézzel folyó kánaán.

Durván ennyi a cikk. És utána jönnek a hozzászólások, a pici apró csörtékkel. Nyilván semmi értelme nem lenne nekiállni lefordítgatni ezeket, inkább csak kiemelnék néhány szálat, hozzáfűzve a saját gondolataimat.

Először is vizsgáljuk meg, mitől is ilyen komoly ez a probléma. Hiszen felnőtt emberek vagyunk, ha találkozunk egy problémával, először szénné elemezzük majd közösen megoldjuk. Miért nem működik ez a módszer a jelen esetben?
Nos, azért mert a mélyben egy nem könnyen feloldható dilemma húzódik meg, nevezetesen: a felhasználó parancsol és az IT kiszolgál, vagy az IT a sarkára áll és diktálja, hogy mit, hogyan lehet?
Nem, ne vágja rá senki a választ. Hibázik az, aki ITIL-lel mélyen impregnálva rávágja, hogy „csak a felhasználó létezik és az IT-nek kutya kötelessége mindenben támogatnia” – és hibázik az a racionális lelkű rendszergazda is, aki helyből elküld mindenkit a sunyiba, azzal, hogy „értsétek már meg, a fizika törvényei alól nincs felmentés”.
Ugyanis a kettő együtt kell, hogy érvényes legyen – de ehhez mindkét félnek engedményeket kell tennie. A felhasználó nem lehet szűk látókörűen akaratos, a rendszergazda pedig nem lehet beképzelt technokrata.
Amennyiben ez a kölcsönös közeledés nincs meg, akkor jönnek a csempetépkedős esetek. Volt olyan ügyfelünk, ahol nagyon sokáig kitartottak amellett, hogy márpedig náluk nem lesz postafiók méretkorlátozás, mert ezzel a felhasználók jogait sértenénk. A csúcs közelében durván 280 GB volt az adatbázisuk mérete, nem volt ritka a 10-20 GB közötti postafiók, a 40-60e levél folderenként. Az Exchange becsületére legyen mondva, elketyegett, de egyfelől nem győztük tolni alá a merevlemezeket illetve később a SAN területeket. Az online maintenance lefutásának körülbelül annyi esélye volt, mint hintalónak Epsonban. Végül az egyre sűrűbb rendellenességek, belassulások, illetve a Microsoft kihívása és a felmérés eredménye meggyőzte őket, hogy ez így tényleg nem mehet tovább.
Ez a történet heppienddel zárult. De le merném fogadni, az olvasók közül sokan tudnának mesélni hasonló történeteket, ahol pénzhiány, rossz priorizálás miatt a mai napig vagy hagyják a dolgokat, hagy menjenek csak úgy maguktól vagy beavatkoznak ugyan, de a józan ész legcsekélyebb szikrája nélkül. Mire gondolok? Például amikor túl alacsony postafiók korlátozásokat vezetnek be, a fájlszerverek szintén szigorúan kvótázva vannak, pst-t meg tilos használni – hogy csak egy eszetlen konfigurációt vázoljak. Emlékezzünk, fentebb már meg lett említve, hogy menekülési útvonalat márpedig biztosítani kell. (A legszebb persze, hogy ilyenkor a felhasználók az IT-t szidják, nem pedig azt a farkot, aki az ilyen szabályozást kitalálja.)

Elemezzük még egy kicsit, hogyan is juthattunk ilyen helyzetbe? Igaza lehet-e annak, aki azt mondja, hogy az Exchange olyan problémakörbe keveredett, melyet éppen nagy sikere indukált? (És most egy kicsit gondolkodhatunk bővebben is, hiszen nyugodtan gondolhatunk az email sikerére is. Az már más lapra tartozik, hogy munkahelyen milyen levelezőrendszer testesíti meg az email szolgáltatást.)
Miért használunk mindenre emailt? Egyrészt, mert kéznél van – másrészt, mert nincs más. Ha üzenni kell, evidens. Ha küldeni kell egy word alapú jelentést? Sajnos, akkor is. Ez a mai IT infrastruktúrák egyik gyenge pontja, hogy nincs megoldva bennük tisztességesen, _ügyfélcentrikusan_ a fájltranszfer.
Mi lenne az optimális? Küldenék egy linket a kollégának, benne egy linkkel a gépemen lévő dokumentumra. Ő rákattint a jobb gombbal, kiválasztja a ’save as’ lehetőséget és már húzza is az állományt. A fájl csak egyszer ment át a dróton, a tranzakció végén két helyen létezik, a készítőnél és a felhasználónál.
Ezt egy felhasználó nem tudja megcsinálni. Fennáll a lehetősége, hogy fájlszerverre pakol, de akkor már fel kell másolnia, visszajelzést kell kapnia, hogy leszedték, majd törölnie kell. Arról nem beszélve, hogy ez csak intraneten működik. Interneten keresztül külső tárolóhely kell, feltöltés, letöltés, tűzfalak… nem barátságos.
A probléma érdekessége, hogy erre az egészre létezik ugyan megoldás, de valahogy a céges informatikába csak nem akar betörni az elv: peer-to-peer hálózatok. Most gondold el, küldeni akarsz az üzleti partnereiteknek egy ajánlatot: kiteszed a gépeden egy megosztott könyvtárba, majd szólsz a partnernek, hogy megtalál a DC++-on, darthfather658 néven, ha érdekli az ajánlat.
Mi marad még? Sharepoint? Jelentkezzen, aki már látott működő megoldást fájlcsatolásra, beleértve a megoldásba a külső partnereinkkel történő kapcsolattartást is.
Valahogy nem az igazi egyik sem. Ezzel szemben becsatolni bármit egy levélbe, elküldeni – két mozdulat. Rátenni CC-ben a fél kollektívát, maximum egy mozdulattal több.
Térjünk vissza az Exchange-hez. Vegyünk két ideális felhasználót. Az egyszerűség kedvéért a postafiókjuk legyen különböző adatbázisban. Géza el akar küldeni egy nagyon fontos doksit Bélának. Becsatolja egy emailbe, elküldi – majd a sent mail könyvtárból törli a levelet. Géza megkapja, lementi a csatolást, majd ő is törli a levelet. Látszólag minden rendben, a fájlok csak a lokális vinyókon foglalnak helyet.
Igenám, de marad utánuk két lyuk az Exchange adatbázisban. Két akkora lyuk, mint a csatolás volt.
Az Exchange ESE(JET) adatbázisokat használ, melyeknél a tárolás lényege az, hogy van egy nagy adatbázis (kenyér), amelybe beleömlesztjük ész nélkül az adatokat. Az adatbázishoz tartozik egy indexfájl, mely tele van pointerekkel – ezek mutatnak az egyes adatok kezdőpontjaira. Ha bekerül egy levél, akkor a kenyérfájl mérete megnövekszik. Ha kitöröljük a levelet, a fájl mérete nem csökken – csak egy lyuk keletkezik benne. Mondhatod, hogy azért még a későbbi adatok kitölthetnék ezt a lyukat… és van is valami ilyesmi, de ehhez le kell futnia az online maintenance műveletnek.
Költői kérdés: ki szokta reggelenként megnézni az eventlogot, hogy leellenőrizze, lement-e rendesen az online maintenance az éjjel? Egyáltalán, ki foglalkozott azzal, hogy megnézze, belefér-e az online maintenance az általunk biztosított – magyarul default értéken hagyott – időkeretbe? Elgondolkodott-e már valaki azon, hogy ne egyidőben biztosítsa az összes adatbázisnak az online maintenance időablakot? Hogy beillesszük a backup időablakai mellé az online maintenance időablakait? Márpedig ha nem fejeződik be rendesen a folyamat, akkor gyakorlatilag nem csináltunk semmit. Az adatbázisunk monoton nő, a lyukak szaporodnak ugyan benne – mi meg őrizzük rendületlenül a semmit. Nyilván az offline tömörítés majd segít, de annak meg szolgáltatáskiesés az ára.
A legszebb az egészben az, hogy mikor nem fut le az online maintenance? Ha túl nagy az adatbázisunk. Mikor nagy? Ha nem korlátozunk. Mi lesz a vége? Még nagyobb lesz az adatbázisunk.
Szép sport Exchange adminnak lenni.

Oké. Korlátozzunk. Mennyi legyen a maximális méret? Nyilván ahány cég, annyiféle limit jöhet létre. (Emlékezzünk, csoportosítani kell a felhasználóinkat.) A gyakorlatban a 250/500/1024 MB határok fordulnak elő a leggyakrabban. (Értelemszerűen a felső határ csak nagyon indokolt esetben jöhet szóba.)
Csakhogy… valahol jogos lehet a felvetés a felhasználó részéről, hogy „feleim, kedves IT-s barátaim, hogy a szöszbe létezik az, hogy ti, akikkel egy kenyeret rágunk, akikkel egy hajóban evezünk, ti csak 250 MB méretű postafiókot adtok nekünk, ezzel szemben a Google, aki se kutyánk, se macskánk, szó nélkül ad 2 gigát?”
A kérdés jó. Többféleképpen is neki lehet futni a válasznak:

  • A gmail ‘best effort’ alapú. Neked, mint felhasználónak nincs velük se SLA-d, se OLA-d. Ha egyszer azt mondják, mostantól az informatikánál jobban érdekli őket a szilikonalapú életformák vizsgálata, ezért beolvasztják az összes processzorukat – egy szavad sem lehet. Nekem viszont konkrét számok írják elő, milyen levelezőrendszert kell üzemeltetnem, mennyi pénzből – ez pedig csak ekkora limittel mehet. A Google alapozhat arra, hogy hiába a 2 GB limit, az átlagos postafiókméret 25 MB – mi nem. Ha mi így gondolkodnánk és időközben a megugró igények miatt bővíteni kellene, legalább tíz embernek kellene aláírnia az állóeszköz beszerzési papírt, nem beszélve arról, hogy mennyire kínos lenne ez az ISO9001-es költségbecslési eljárás szempontjából. (Most azt hiszed, gúnyolódok. A francokat. Egyszerűen ez a ‘bővítünk, ha szükség lesz rá’ nem illeszthető bele egy nagy cég IT részlegének viselkedésébe.)
  • A másik – határozottan szimpatikusabb – válasz az a Microsoft ajánlás, hogy akkor legyen a felhasználói postafiókok felső határa 2 GB. Persze csak Exchange2007 / Outlook 2007 páros alatt.

Nyilván ez nem csak annyiból fog állni, hogy katt, 2 GB, OK. (Gondolhatod, a Google-nél sem ennyi.) Mi is kell mindehhez?

  • Először is tudnunk kell, hogy egy adatbázis elfogadható felső határa 100 GB. Tehát ha 2 GB maximális postafiók méretet szeretnénk biztosítani, akkor szét kell szedni a felhasználókat, maximum ötvenet rakva egy adatbázisba. Hogy egy Exchange szerveren tokkal-vonóval maximum 20 adatbázis férhet el? Ja, az Exchange2003-ban. A 2007-es termékben ez a szám 50-re ugrott. Ez 2500 felhasználót jelent, 2 GB postafiókkal, egy szerveren belül. Úgy vélem, nem rossz. (Az más kérdés, hogy ehhez tényleg kell a 64 bit, meg több lapát memória, processzor, a merevlemezekről nem is beszélve. De a garantált végtelent soha nem adják ingyen.)
  • Mi lesz itt az online maintenance folyamattal? Hiszen a rendszeres backup maga ki fogja tömni a nem üzleti időintervallumot.
    Kitömné. Ha hagynánk. De inkább kidobjuk a backup-ot.
    Meredek volt? Ne feledd el, ez egy új termék.
    Gondoljuk végig, mire is való a backup? Hogy legyen egy viszonylag naprakész példányunk az adatbázisból, ha az éppen aktív feldobná a talpát. De miért ne lehetne egy teljesen naprakész példányunk a viszonylag naprakész helyett? Mi lenne, ha minden tranzakciót nem csak az éles adatbázis logjaiba rögzítenénk, hanem ezzel párhuzamosan egy árnyék adatbázis logjaiba is? Ha bedőlt az éles adatbázis, akkor van helyette egy teljesen naprakész másik. Ezt a technikát úgy hívják, hogy Cluster Continous Replication, illetve Local Continous Replication – attól függően, hogy lokális gépen keletkezik a tükör adatbázis vagy távolin. Tulajdonképpen egyfajta átmenet a szóló és a clusterezett Exchange szolgáltatás között. Például oprendszer szinten kell neki a cluster szolgáltatás. (Miért más ez mégis, mint a cluster? Azért, mert nem kell közösen használt adattároló -> el lehet tenni a másik gépet Böhönyére.)
    (Megjegyzem, ez szép és jó, de azért van olyan aspektusa a backupnak, melyet a CCR/LCR nem old meg. Jön Vezérigazgató Béla, töröl egy levelet, majd egy hónap után mégis csak kellene neki. Ennyi ideig a dumpster sem tart ki – csak az egy hónappal korábbi mentésből tudjuk neki elővarázsolni a levelet.)
    De akárhogy is nézzük, le tudjuk csökkenteni a backup időablakát, így a szabad időablakok nagy részét az online maintenance folyamathoz tudjuk rendelni.
  • A bűvös 64 bit. A sokkal nagyobb címezhető memória. Mellyel lekerül a béklyó az Exchange-ről, bátran habzsolhatja a szabad memóriablokkokat.
  • Records Management: menedzselt foldereket vezethetünk be, melyekben házirendekkel szabályozhatjuk a levéltömeg kezelését.
  • Keresés a nagyméretű postafiókokban: az Outlook2007 – cached módban – a jóval hatékonyabb Windows Desktop Search szolgáltatást fogja keresésre használni.

Ha már a cached módnál járunk, volt egy érdekes pengevillantás. Russ megjegyezte, hogy a a cached módba kapcsolt Outlook bizonyos esetekben nagyobb forgalmat generálhat, mint az online módban használt. Erre azért nem kevesen kapták fel a fejüket.
Imhol a magyarázat:

  • Az Offline Address Book letöltögetése. Ez verziótól függően meglehetősen frekventált is lehet.
  • Azért azt az OST-t is szinkronizálgatni kell.
  • Ha n felhasználónak küldünk egy levelet, az egy idő után mindegyikhez leszinkronizálódik, akár kíváncsi rá, akár nem. Ugyanez online módban nem feltétlenül történik meg – a levelet törölhetem olvasás nélkül is.
  • A hétfő reggeli csúcs. Amikor mindenki belép és egyszerre szinkronizál a szerverrel.

Magunk között legyen mondva, engem nem győzött meg. Ezek tényleg bizonyos esetek – de azért az online mód masszívan hozza magával a nagyobb adatforgalmat.

Nézzünk még egy hozzászólást: itt a másik klasszikus IGCs séma: miért nem teszitek már át ezt az egészet SQL alá?
Erre mondta Russ azt, hogy a jelen szituációban tökmindegy, hogyan tároljuk az adatokat, ESE v. SQL v. Sharepoint adatbázisban vagy akár kopasz fejekre tetoválva. Az email, mint forma generálja a nagy adatbázisokat.

Végül még egy utolsó érdekesség a kommentekből.
Egy hozzászóló reklamálta, hogy ő akár a feje tetejére is állhat, a MAPI jellegéből adódóan a felhasználói bármikor ledosolhatják a levelezőszerverét: ugyanis a nagy üzenet, függetlenül attól, hogy postafiók méretkorlátozás miatt megérkezik-e vagy sem, a tranzakciós logba mindenképpen bekerül. Russ válaszként belinkelt egy korábbi írást.
A cikk rögtön aranyos történettel indít: egy felhasználó kapott egy 6 gigás levelet. Egy olyan rendszerben, ahol korlátozva volt a levélméret. Az történt ugyanis, hogy Béla elküldte a szerény hatgigás levelét, melyre természetesen egy NDR-t kapott vissza a szervertől. Benne csatolásként az eredeti levelével.
Nem áll szándékomban lefordítani az egész cikket, röviden arról van benne szó, hogy kielemezték, hogyan működhet ilyen nonszensz módon egy Exchange szerver, miért nem lehet már a levél elküldése előtt leellenőrizni, hogy méret – mind levélméret, mint postafiókméret – tekintetében minden rendben van-e? Organizáción belül egy MAPI kliens elvileg képes lenne erre.
Nos, a nagy elemzésnek az lett a vége, hogy ma már képes erre mind az Exchange, mind az Outlook. Egész pontosan Exchange-ből a 2003Sp2, Outlookból szintén a 2003Sp2.

No, szép hosszú írás lett – és IGCs-hez méltóan, nem oldottam meg vele semmit. A probléma továbbra is itt lebeg körülöttünk, az alternatív megoldásokról látszik, hogy még nem igazán jók, az Exchange2007 pedig még a – nem túl távoli – jövő zenéje. Egyelőre túl sok mindent azon kívül nem tehetünk, hogy jól kipanaszkodjuk magunkat. Hátha azzal, hogy hangosan gondolkodunk, csak tudunk segíteni azokon, akik még csak most szembesültek a problémakörrel.

Megjegyzés:
(1) IGCs: A rövidítést én találtam ki. Internetes fórumok olyan toposzaira használom, ahol mindenkinek van egy kis igaza, így a téma rendszeresen előkerül és a vitában résztvevők az unalomig ismert érveket Irgalmatlan GumiCsontként rágják újra meg újra. (Kerékpáros, abortusz, kutyaszar, sebességkorlátozás… meg hasonlók.)