Mennyi memóriát tegyek az Exchange Server 2013-as mailbox szerverbe?
Sokat. De tényleg. De kezdjük az elejérol. Minden az Exchange szerverhez beérkezo kérést ami az adatbázisban elemi muveletet eredményezne eloször a memóriában hajtunk végre. Az adatbázis lapok
(database page) a memóriában vannak, azon hajtjuk végre a változtatásokat. Az elvégzett muveleteket (transaction) lenaplózzuk. Erre szólgál a transaction log. Ha lenaplóztuk, akkor megvan a változtatás a memóriában és adatbiztonsági szempontok okán a transaction log-ban. A következo lépés ezután az, hogy a memóriából az adatbázisba írjuk a változtatást. Így már az adatbázisban az aktuális állapot lesz.
Mi történik akkor ha nem tudjuk az adatbázisba kiírni a változtatásokat, mert a szerver menetközben áramszünet miatt leáll? Semmi pánik, a változtatásokat naplóztuk és a transaction log-ból a következo indítás alkalmával az adatbázisba bekerülnek a változtatások.
A fo ok amiért így muködik az Exchange az a teljesítmény és az adatbiztonság.
- Teljesítmény: gyorsabb a memóriában elvégezni bármilyen módosítást mint a diszken
- Biztonság: minden naplózzunk le egy szekvenciálisan írható és olvasható kisméretu fájlba, mert onnan gyorsan reprodukálható újra az adott tranzakció
Azonban vegyük észre, hogy az adatbázisból a memóriába az adatbázislapoknak valamilyen módon át kell kerülni. Ez pedig a lemezhez történo hozzáférést jelenti a memória töltésekor. Továbbá a memóriából újra a lemezre kell kerüljön az adat ami szinten a lemezhez történo hozzáférést jelenti a memória ürítésekor.
Alapvetoen tehát felismerheto az az összefüggés, hogy ha minél több a memória a szerverben, akkor annál ritkábban kell a lemezt olvasni, vagy írni.
Kis kitéro a cold memory kérdéskörre. Ha egy szervert újraindítasz akkor az indulás pillanatában (t) a memóriában nincsenek bent a gyakran használt adatbázislapok. Azonban ilyenkor is jönnek tranzakciók, a felhasználók szeretnék elérni a leveleiket, szeretnének módosítani stb. Ebben az esetben úgynevezett cold memory állapot van. Töltjük a memóriát folyamatosan az adatbázislapokkal és viszonylag kisarányban tudunk lemezmuvelet nélkül kiszolgálni. Tehát egy újraindítás esetén számoljunk azzal, hogy amíg a memóriába az adatbázislapok nem kerülnek be, átmenetileg szignifikánsan nagyobb diszk terhelést láthatunk. Igazán érdekes az, hogy ehhez nem szükség az újraindítás sem. Egy failover esetén a korábban passzív node memóriája szintén hideg, amit fel kell tölteni, illetve egyszeruen az MS Exchange Information Service újraindítása is ezt idézi elo.
Tehát minél több memóriát teszünk az Exchange mailbox szerverbe annál jobb lesz a teljesítmény, mert nem függünk akkora mértékben a diszkek sebességétol. Ezért is volt fontos lépés az, hogy az Exchange Server 2007 már csak 64 bites változatban volt elérheto (emlékszünk még rá, hogy volt belole tesztelési célra 32 bites verzió?). 32 bites környezetben a /3GB kapcsoló használatával 1GB memória jutott a kernelnek, 3GB memória jutott minden user mode-ban futó processznek. Ebbol kellett gazdálkodjon az Exchange, hiszen a 32bit okozta korlát a legfeljebb 4GB memória (PAE-tól most tekintsük el).
Tételezzük fel, hogy sok memóriát teszünk az Exchange Server 2013-ba. De mennyit fog abból az Exchange felhasználni az adatbázislapok tárolására? Könnyu azt belátni, hogy ez nem a fizikai memória 100%-a. Azért nem, mert szüksége van memóriára a Windows kernelnek és az összes többi user módban futó processznek, beleértve az Exchange egyéb komponenseit is.
A képlet a következo: az összes fizikai memória 25%-a mehet el az adatbázislapok tárolására, vagyis az Exchange store cache-re.
Ezen a 25%-on osztozik ezután minden adatbázis egyenlo mértékben a következo szabályszeruséget figyelembe véve:
- Minden aktív adatbázis megkapja a 25%-ból ráeso rész 100%-t.
- Minden passzív adatbázis (DAG esetében egy aktív és legfeljebb 15 passzív adatbázis lehet) megkapja a 25%-ból ráeso rész 20%-t, a 80% nincs felhasználva
A memóriagazdálkodás az egyes adatbázisok között az Exchange Server 2013 esetében elég egyszeru. Az architektúra megváltozott a korábbi Exchange verziókhoz képest. Korábban, az Exchange Server 2013 esetében egy Store.exe futott, egy process volt. Ez a process az összes felcsatolt, aktív adatbázist kezelte és hozzátartozott az adatbázislapok kezelésére használt memóriaterület. Ez memory management szempontból sem volt ideális, mert a Windows számára ez csak egy process,továbbá nem volt szerencsés hibaturés szempontjából sem. Ha ez az egy process bármilyen okból kifolyólag megállt, akkor az összes felcsatolt adatbázis megállt.
Az Exchange Server 2013-ban a minden adatbázishoz tartozik egy process. Ezt hívjuk worker processnek, a processek között ez a Microsoft.Exchange.Store.Worker.exe. Az összes worker process felett pedig orködik a Microsoft.Exchange.Store.Service.exe aminek a feladat a worker processek indítása, leállítása, felügyelete stb. Így az adatbázisaink memory management szempontból partícionálva vannak és adatbiztonság szempontjából is ideális a kialakítás, mivel bármely worker process megállása nem befolyásolja a többi worker process muködését.
Nézzünk egy példát:
- 96GB fizikai memória van a kiszolgálóban
- 16 adatbázisunk van
- 1 aktív és 1 passzív kiszolgálónk van
Az egyes worker processzek mennyi memóriát kapnak az aktív és a passzív oldalon? A képlet a következo:
- Aktív node:
- Passzív node:
A 96GB negyede 24GB. Ezen osztozik az összes adatbázis, ami esetünkben 16GB, vagyis 1,5GB adatbázisonként. Az aktív node esetében a 1,5GB 100%-t megkapja, a passzív pedig ennek a 20%-t vagyis ~300MB-t. Tehát a válasz:
- Aktive node: 1,5GB
- Passzív node: 300MB
A következo két képernyokép a fenti adatoknak megfelelo tesztlaborban készült. Itt látható, hogy a passzív és az aktív is a számításainknak megfeleloen fogyasztja a memóriát (“kis” overhead van minden process életciklusában, tehát lehetnek átmeneti idoszakok amikor kicsit többet, vagy éppen kicsit kevesebb memóriát fogyaszt, ez látható a képeken is)
