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.)
Recent Comments