Exchange 2010 és az olcsó adattárolás

Tanácsadóként az Exchange termékkel nagyon egyszeru a feladatom. A termék és a szolgáltatás szükségességét általában nem kérdojelezik meg. Viszonylag ritka az a helyzet, amikor az Exchange valamelyik új verziójának a funkcióit nem szeretnék használni az ügyfeleim (bár elofordul). Legalább egy ilyen funkció mégis akad amit kevesen szeretnének használni. Ez pedig nem más, mint a tabukat döntögeto olcsó Storage. A mai bejegyzésemben errol írok.

Hosszasan elemezhetnénk azt, hogy miért tabukérdés ez a legtöbb ügyfélnél. De ettol most eltekintek, mert az objektivitás terén szeretnék maradni. Az olcsó Storage használatának lehetosége mérnöki szemmel nézve jelentos. Üzleti szemmel nézve ugyanúgy jelentos, ha nem tartanak a szemünk elé egy prizmát. Igyekszem a muszaki érvekre koncentrálni, hogy egy esetleges döntési helyzetben az olvasónak elég muszaki információja legyen és fel se merüljön benne a kérdés, hogy valóban tudja-e az Exchange azt amit állítunk róla.

Háttér

Minden a régmúltban kezdodött, ahogy az általában lenni szokott. Vegyük kiindulásként az Exchange Server 5.0-t, ami 1997 márciusában jelent meg (Build numbers and release dates for Exchange Server). 14-15 évvel ezelott kiszolgáló oldalon a kis kapacitású, magas fordulatszámon pörgo, drága SCSI diszkek voltak jellemzoek a piacra. A létezo legnagyobb érték a diszkek esetében a tárkapacitás volt. Így teljesen logikus döntés volt az Exchange Server termékfejlesztoktol az, hogy a terméket ezekhez a jellemzokhöz igazították. Az Exchange Server az adatok tárolásánál a tervezo utasítására ezt vette figyelembe és a leheto legkisebb adatbázis méretre törekedett.

A gyakorlatban ezt az adatbázis Schema diktálja. Az adatbázis Schema-ban az Active Directory címtárhoz hasonló módon az adatbázisunk belso szerkezetét írjuk le. A Schema megváltoztatásával az adatbázis belso karakterisztikája módosítható. Ellenben az Active Directory-val, az Exchange esetében az adminisztrátorok nem módosíthatják az Exchange adatbázis belso szerkezetét, azt csak a termékfejleszto csapat tudja elvégezni. Tehát nincs olyan opció a kezünkben, hogy a belso karakterisztikát állítsuk, tunningoljuk. Az adatbázis Schema a diszkek szempontjából nézve, közel 10 évig jelentos módosításon nem változott. Tehát az Exchange 5.0 után, az 5.5, a 2000 és a 2003 is az adatbázis méretének optimalizálásához volt igazítva. A változtatás azonban lassan de biztosan az Exchange Server 2007-el elindult, majd jelentos mértékben folytatódott az Exchange Server 2010-ben és a sornak nincs vége…

De mi indokolta a módosítást? –> A merevlemezek fejlodési iránya. Az látható a piacon, hogy a merevlemezek tárolókapacitása és sebessége nem azonos görbe mentén növekszik. Míg jelentos eredményeket sikerült elérni a tárolókapacitás növelése esetén, addig az adatok elérésének sebessége esetén lényegesen nagyobb a lemaradás. Az egyik legjobb méroszám a sebesség kifejezésére a másodpercenkénti IO muveletek száma. Ebbol mindjárt ketto is van – hogy egyszeru legyen a világ -:

• Random (véletlen) – a merevlemezben a fejnek mozognia kell az adatok eléréséhez
• Sequential (szekvenciális) – a merevlemezben a fejnek nem kell mozognia az adatok eléréséhez, a tányér pörgése elégséges

A fej mozdítása magas IO késleltetést eredményez, míg a mozdulatlan fej alacsony IO késleltetést eredményez. Ezt komoly merevlemez geometriai elemzések nélkül is egyszeruen beláthatjuk. A mérések alapján egy 7200-es fordulatszámú 20 ms-es késleltetésu SATA lemez kb. 50 Random IO muveletre és kb. 300 Sequential IO muveletre képes. Az adatsuruség növelésével lineárisan növekszik a Sequential IO sávszélessége, ez egy újabb érv ami miatt a Sequential IO muveleteket az informatikában lényegesen jobban szeretjük.

Az Exchange Server 2010 elotti verziókban használt Store Schema azt eredményezte, hogy leginkább Random IO muveleteket kellett a merevlemezeknek végezniük. A Store Schema-t az Exchange Server 2010-el úgy módosítottuk, hogy a Store muveletek leginkább Sequential IO muveleteket eredményeznek. Ennek elso és legfontosabb hatását elég könnyu belátni. Kevésbé gyors merevlemezeken is képesek vagyunk ugyanazt a terhelést kiszolgálni az új Exchange segítségével.

Megvan hát a ténymondatunk. Módosítottuk a Store Schema-t ami azt eredményezte, hogy elméletileg lassabb diszkeken is képes az Exchange megfeleloen muködni.

Módosítások az Exchange-ben

Nézzük szép sorban azokat a módosításokat amik mindezt lehetové tették. Ebben a fejezetben muszaki felsorolás és azok értelmezése következik.

Az Exchange Server 2010 tervezése során az adatbázis szempontjából nézve a következo négy alap tervezési pillér volt szem elott:

1. IO igény csökkentése, Random IO : Szekvenciális IO arányának javítása a szekvenciális javára
2. SATA lemezekre való optimalizáció
3. RAID nélküli környezetek építésének lehetosége – errol egy késobbi bejegyzésben írok
4. Storage rugalmasság

Szekvenciális IO kontra Random IO

Ahhoz hogy maradéktalanul megérthessük az Exchange Server 2010 Store Schema-t és a módosításokat értékelni tudjuk, meg kell néznünk eloször az Exchange Server 2007 Store Schema-t. A következo ábra egy Exchange Server 2007 adatbázist szemléltet:

A kialakítás legfontosabb jellemzoi:

• Adatbázisonként egy táblát használunk a postaláda információk tárolására. Ennek a táblának a mérete az adatbázisonkénti postaládák számától jelentos mértékben függ. Általában a mérete nagy. Az ábrán ez a “Mailbox Table”. Itt tároljuk a postaládák adatait (a tartalmát nem). Tehát ha egy adatbázisban 500 postaládánk van, akkor a “Mailbox Table” táblában az 500 postaláda szerepel.
• Adatbázisonként egy táblát használunk az összes postaláda, összes mappájának tárolására. Tehát ha adott 500 postaláda az adatbázisban, akkor az 500 postaláda, összes mappáját ebben a táblában tároljuk. Vagyis legalább 500 Inbox nevu mappa információ szerepel ebben a táblában (csak hogy egyszeru legyen elképzelni). Másik szemléltetés: ha minden postaláda tulajdonosnak 50 mappája van a postaládájában akkor 500*50 = 25.000 mappa van ebben a táblában. Az ábrán ez a “Folders Table”.
• Adatbázisonként egy táblát használunk minden az adatbázisban szereplo postaládában elérheto üzenetek tárolására. Vagyis az elozo példánál maradva, ha 500 postaláda van az adatbázisban, akkor az összes postaláda, minden üzenete egy adatbázis táblában szerepel. Az ábrán ez a “Message Table”.
• Adatbázisonként egy táblát használunk az összes melléklet tárolására. Tehát az összes postaládában levo összes levélmelléklet válogatás nélkül egy táblában van tárolva az adatbázisban. Elméleti síkon ez az a funkció ami lehetové teszi, hogy egy mellékletet az adatbázisban egyszer és csak is egyszer tároljunk le. Ezt a funkciót hívjuk Single Instance Store-nak. Az ábrán ez a tábla az “Attachments Table”.

A fenti architektúrán ha egy kicsit elgondolkodunk, akkor arra a következtetésre juthatunk, hogy kiváló. Jól láthatóan valóban arra termett, hogy a leheto legkisebb helyet foglaljanak el az adatok az adatbázisban. Azonban ha tovább gondolkodunk, akkor azt is láthatjuk, hogy az adatok az adatbázisban logikailag egymástól “elszórva” vannak letárolva. Ezt az adatbázison belüli fizikai tárolás természetesen követi. Ennek pedig egyenes következménye az, hogy az adatok olvasásához vagy írásához Random IO szükséges. Csaba postaládájában levo melléklettel rendelkezo levél megnyitásához több táblából kell az adatokat az adatbázisnak kiszolgálnia. Ha ezek az adatbázisban nem egymás mellett (szekvenciálisan) kapnak helyet, akkor ez bizony Random IO muveletet fog a végén eredményezni. Abból pedig kevés van a raktárban napjainkban.

Az új, Exchange Server 2010 Store Schema-t a következo ábra szemlélteti:

A változás jelentos léptéku. A postaládákat továbbra is egy nagy táblában tároljuk az adatbázison belül. Azonban a postaládában tárolt információkat az Exchange Server 2010 óta, postaládánként szervezett táblákban tároljuk. Tehát minden postaládához tartozik egy-egy külön tábla ami a mappákat, üzenetfejléceket, levéltörzseket tartalmazza. Ennek két jelentos következménye van:

• A mellékletek egyszeri letárolásának lehetosége végleg megszunt az Exchange Server 2010-ben. Ez jelentos veszteségnek tunhet, de errol késobb még írok, hogy miért nem az valójában.
• A logikailag egymáshoz tartozó adatok az adatbázisban logikailag egymás mellett vannak eltárolva. Így a felhasználói aktivitásokhoz tartozó IO muveletek a korábbi Random IO helyett Szekvenciális IO muveletek.

Ami a mellékletek egyszeri letárolásának elvesztését illeti:

• a tapasztalataink alapján az egyszeri letárolás átlagosan 0-20% közötti hely megtakarítást jelentett. Ez elso ránézésre kevésnek tunik. Azonban gondoljuk csak végig, hogy valóban hány dologtól függ ez (azonos adatbázisban kell hogy a címzettek legyenek, ha valaki módosítja a mellékletet az már új lesz stb.). Van egy közelíto becslést adó teljesítmény számláló, amivel egy arányt láthatunk az összes referencia és a Single Instance referenciák között. Nem érdemes túl elemezni, de azt könnyen leolvashatjuk a segítségével, hogy kb. milyen arányban profitálunk a Single Instance Store-ból
• az Exchange Server 2010 esetében van adatbázis tömörítés, amiért nem kell semmit sem tennünk, automatikusan elvégzi az Exchange. Ami a hatékonyságát illeti, kb. 20%-s tömörítésre képes (természetesen ez tartalomfüggo). Használt algoritmus: 7bit/XPRESS
• tegyük bátran a mérlegre azt, hogy olcsó SATA diszkbol hányszor nagyobb tárolókapacitást tudunk felépíteni kevesebb költséggel, ami boven ellensúlyozza a legfeljebb 20%-os adatbázis növekedést (az eddigi tapasztalataim ezt a növekményt megerosíti, de a megjegyzésekben szívesen veszem az észrevételeket, egyéb tapasztalatokat)

Jelentos IO csökkentés

Jelentos IO csökkenést eredményezett a nézetek kezelése. Az elozo két ábrámon látható az, hogy a nézeteket külön tároljuk (verziótól függoen másként) az Exchange adatbázisban. De mit is jelent ez és milyen nézetekrol van szó? Az Exchange kliensei különbözo nézeteket generálhatnak a mappákon belül, ezeket kiszolgáló oldalon tároljuk (ez ettol sokkal komplikáltabb, de a lényeg megértéséhez ez most itt elégséges). Az Exchange Server 2007-ig egy levél érkezésekor, vagy annak módosításakor az *összes* az adatbázisban tárolt nézetet frissítettük, aktualizáltuk. Ez hatalmas mennyiségu Random IO muveletet okozott! Az Exchange Server 2010 esetében ettol eltéroen járunk el. A nézeteket akkor és csak akkor frissítjük, amikor a felhasználó azt használni szeretné. A sok Random IO itt automatikusan kevés, nagy méretu szekvenciális IO muveletet eredményez. És mint tudjuk, ez a diszkek szempontjából lényegesen hatékonyabb. Ez a változtatás az egyik legjelentosebb az Exchange Server 2010 esetében, ami a drasztikusan csökkenti az IO muveletek számát (korábban amit tárgyaltunk, az a Random kontra Szekvenciális IO-ról szólt).

Page méret növelése

Az adatbázisban az adatokat úgynevezett adatbázis lapokra (page) írjuk. Az adatok olvasásakor ezeket az adatbázis lapokat olvassuk vissza. Egy adatbázis életében jelentos szerepe van annak, hogy mekkora egy page mérete. Exchange Server 2007 esetében egy lap mérete 8kb. Az Exchange Server 2010 esetében ez az érték 32kb. Elso ránézésre ez nem túl jelentos változás. Azonban ahogy mindig is lenni szokott ez csak a felszín. Ez egy jelentos változtatás. A következo példán keresztül ezt mindenki egyszeruen beláthatja: adott egy 64kb méretu levél, amit szeretnénk megnyitni. Elméletileg ez az Exchange Server 2007 adatbázist feltételezve ideális esetben 8 adatbázis lap olvasásával érheto el (ez 8 db IO muveletet jelent). Exchange Server 2010 adatbázist feltételezve ideális esetben ez 2 adatbázis lap olvasásával érheto el (ez 2 db IO muveletet jelent).

Jól láthatóan így az olvasások és írások IO igénye drasztikusan csökken. Ez minden adatbázis muveletre automatikusan jótékony hatással van.

Checkpoint depth

A checkpoint depth értéke adatbázisonként azt határozza meg, hogy a dirty adatbázis lapok mérete legfeljebb mennyi lehet a memóriában. Ez az érték Exchange Server 2007 esetében 20MB volt. Az érték Exchange Server 2010 esetében HA használunk adatbázis másolatot, akkor 100MB. A hatása ennek a változtatásnak szintén jelentos, a page méret növeléséhez hasonló módon. Ideális esetben az Exchange Server 2010 ennek a módosításnak a hatására ritkábban nagyobb adatmennyiséget szeretne az adatbázisba írni. Tehát egy újabb rétegben biztosítjuk azt, hogy a merevlemezeket hatékonyabban használjuk. A ritkább de nagyobb méretu írás vagy olvasás nagyobb hatékonysággal végezheto el a diszkeknek.

A mérési tapasztalataink alapján kb. 40%-al hatékonyabb írási és olvasási eredményt érhetünk el a 100MB-s checkpoint depth érték használatával. De mint tudjuk, semmi sincs ingyen. A nagyobb checkpoint depth értéknek a következo negatív hatása lehet:

• lassabb leállítás – nyílván a dirty page-ket mielott az adatbázist leállítjuk ki kell írnunk az adatbázisba. Ez nagyobb adatmennyiség esetén több idot vehet igénybe. Még akkor is összességében nézve hatékonyabb az adatbázis muködése. Hogy ez ne okozzon jelentos idoveszteséget az Exchange Server 2010 esetében az adatbázisokat párhuzamosan állítjuk le. Ezzel jelentos idot takaríthatunk meg, pontosabban az ido növekedés nem adódik össze.

Adatbázis cache prioritás

Minden adatbázis muvelet amit az Exchange kiszolgálónak a memóriában kel elvégeznie, lényegesen hatékonyabb mintha azt közvetlenül a merevlemezen tárolt adatbázis fájlban kellene elvégeznie. Ennek oka a memória és a merevlemez sebességkülönbsége. Ezt egyszeru belátni. Az adatbázis cache egyfelol tartalmazza a dirty page elemeket, amik arra várnak, hogy az adatbázisba írjuk. Illetve tartalmazza a korábban beolvasott adatbázis lapokat is. Ennek oka az, hogy így kevesebb alkalommal kell a merevlemezen tárolt adatbázis fájlhoz nyúlnunk, vagyis a kéréseket hatékonyabban és gyorsabban tudjuk kiszolgálni. Azonban semmi sem véges. Így az adatbázis cache sem. Ha az adatbázis cache a memóriában betelik, akkor a szoftvernek döntenie kell, hogy a cache tartalmából mit töröljön. Az informatikában erre több lehetséges algoritmust is kidolgoztak már. Az Exchange Server az úgynevezett LRU (Least Recently Used) algoritmust használja. Vagyis a legrégebben nem használt elemeket fogja a gyorsító tárból törölni. Csak érdekességként ehhez az kell, hogy a gyorsító tárban rögzítsük azt az információt is, hogy az adott elemet mikor használtuk utoljára.

Fontos megjegyezni azt, hogy az Online Maintanence, Online Defragment folyamatok által használt adatbázis lapok is bekerülnek az adatbázis cache-be. Gyors helyzetfelismeréssel észrevehetjük azt, hogy ezeket a muveletek az adatbázis cache-ben “feleslegesen” foglalják a helyet és várják a sorsukat, hogy elévüljenek. Az Exchange Server 2007 esetében megvártuk azt, hogy elévüljenek és csak utána dobtuk ki az adatbázis cache-bol. Az Exchange Server 2010 esetében más a prioritása ezeknek a muveleteknek így az adatbázis cache-ben az általuk foglalt területet hamarabb felszabadítjuk, ezzel a cache hatékonyságát tudjuk növelni. A cache hatékonysága pedig ismét kihatással van a diszkek terhelésére, ugyanis kevesebb alkalommal kell merevlemezhez nyúlni, vagyis csökken az IO muveletek száma.

Zárszó

Itt a Microsoft-ban büszkék vagyunk arra a mérnöki munkára amit az Exchange Server 2010 esetében elvégeztünk. A fenti módosításokat átnézve, megértve ezek hatását egyszeruen látható, hogy a diszkek hatékonyabb használatára törekedtünk és ez sikerült is. A méréseink alapján a szükséges IO igény drasztikusan csökkent. Míg az Exchange Server 2003 esetében a méretezés során felhasználónként átlagosan 1 IO muvelettel kellett másodpercenként számolnunk, addig ez az érték Exchange Server 2007 esetében 0,33, Exchange Server 2010 esetében 0,1.

Ez a mérnöki munka lehetové tette azt, hogy az Exchange Server 2010-hez a háttértároló tervezésekor nagyobb választásunk lehessen. Továbbra is használható marad a gyors és egyben drága diszk alrendszer. Ezzel egy idoben azonban muszakilag lehetséges a lassabb tárolók irányába történo elmozdulás, ami nem kötelezo, de jelentos elonyt biztosíthat bárkinek. A nagy postaláda biztosítása alacsonyabb fajlagos tárolási költség mellett olyan elony amit minden informatikai szervezetnek érdemes mérlegelnie.

Muszakilag érdemes legvégül azt megjegyezni, hogy a lassabb diszkek csatoló felülettol függetlenül használhatóak és jelentos költség csökkentés érheto el velük. Tehát amikor SATA lemezekrol beszélünk, akkor nem feltétlenül úgy kell azokat elképzelnünk, hogy egy alaplapi SATA csatoló felületen keresztül kapcsolódnak a kiszolgálóhoz. A használható csatoló felületek széles skálája alkalmazható a DAS-tól a SAN hálózatok használatáig. Ezzel kapcsolatban kérdezze hardware beszállítóját.

A Microsoft elkötelezett partnere az ügyfeleknek az informatikai költségek csökkentésében. Ne feledje, az Exchange Server 2010 erre egy kiváló eszköz.

Comments

• Anonymous
  January 01, 2003
  Nagyon jó cikk, elsősorban azért, mert  é r t h e t ő. Egy apró kérdés: tulajdonképpen mi szab korlátot a page méret növelésének?
• Anonymous
  September 11, 2011
  Nagyon hasznosnak találtam az írást - ritka az ilyen részletes szakmai igényességgel megírt cikk. Köszönöm!
• Anonymous
  September 15, 2011
  Eddig ez a post volt a legjobb - számomra persze, DBA szemmel.. :)Csak így tovább!
• Anonymous
  September 15, 2011
  Nem szoktam véleményt nyilvánítani fórumokon, de most nem állom meg szó nélkül: ez a cikk nagyon ütős!!!
• Anonymous
  September 27, 2011
  Kiváló kérdés. Miért nincs 1MB-s page méret?A legfontosabb határt itt a memória szabja. A dirty page-k a memóriában vannak. A legkisebb alapegység a page, vagy szépen lefordítva az adatbázis lap. Az elérhető, megfizethető, beszerelhető memória függvényében folyamatosan növeljük az adatbázis lapok méretét.A másik irány az, hogy meg kell találni az egyensúlyt az átlagosan az adatbázisodban tárolt adat mérete és a lapméret között. Ha azt látod, hogy az átlagos (!!) levélméret kisebb vagy egyenlő mint 24kb, akkor egy 1MB page méret túlzás.Szóval ahogy nővekszik az áltagos levélméret, nő az elérhető fizikai memória mérete, úgy húzzuk utánna a lapok méretét.Bővebb információ egy későbbi blog bejegyzésben. Régi nagy álmom az, hogy érthető módon leírjam az Exchange adatbázis belső működésének alapjait. Ez elég nagy kihívás de dolgozom rajta!