Szabad hely probléma, avagy miért fogy el a hely az Exchange Server 2013-as mailbox szerveren?

12 évvel ezelott amikor Windows NT 4.0 szervereket telepítettem, akkor mindig 8GB-s System partíciót hoztunk létre. Oda került a Windows Server és az összes telepített alkalmazás. Tökéletesen elég volt. Ezt a szokást sokan és sokáig vittük magunkkal a Windows 2000-es korszakban is, ahol tovább muködött ez a módszer. Az elso jelek, hogy a 8GB már szuk lesz, valahol kb. 10 éve érkezett el. Windows Server 2003 esetében már sokszor szukös volt a 8GB. Itt kb. a 16-32GB-s system partíciók voltak használatban. Windows Server 2008 körül pedig a 40-60GB.

Az elmúlt 2-3 évben szinte minden Windows Server amihez közöm volt, legalább 126GB-s system partícióval jött létre. Köszönhetoen annak, hogy a Hyper-V esetében ez a default disk méret. Nincs is ezzel komoly gond, reális méret. A diszk olcsó. Nem is volt mostanában helyhiány sehol sem amerre jártam.

Itt említeném meg, hogy a pagefile a környezetemben szinte mindig egy önálló partíción és lemezen kerül kialakításra. Ennek az oka, az, hogy a pagefile mérete hatalmas. Képzeljünk el egy 96GB memóriával rendelkezo Exchange Server-t. A 126GB-s partíción a pagefile tetemes méretet tölt ki.

Tehát ahogy említettem, nem is volt eddig problémám, mostanáig. Az elso nagyobb Exchange Server 2013-as production környezet kialakításáig. A szabad hely drasztikusan fogyott az Exchange Server 2013-as mailbox szerepköru kiszolgálókon. Minden Exchange üzemelteto rémálma ez a kép:

Hosszas elemzést követoen megértettem, hogy mi áll a helyhiány mögött. Alapvetoen két folyamat felelos érte:

• intenzív protokoll naplózás
• queue mérete

Az intenzív protkoll logolás számlájára írható a helyhiány egy része, de nem az egész. Néhány 10GB naplóról van szó. A C:\Program Files\Microsoft\Exchange Server\v15\Logging könyvtár alatt. Érdemes rendszeres idoközönként törölni ezeket a naplókat.

A protokoll loggingnál viszont lényegesen nagyobb terhet okoz a queue mérete. Ma ~80GB méretu queue-val találkoztam.

De miért ilyen nagy? Esetleg 80GB mennyiségu levél állt a kjúban? Nem. A válasz az architektúrális változás. Az Exchange Server 2007 óta jelenlevo transport dumpster megváltozott. A transport dumpster azt biztosítja, hogy egy DAG környezetben a lossy failover esetében, a hiányzó leveleket a Transport Role kjújában tárolt levelekbol lekérdezhessük. Tehát, ha a DAG-ban nem tudtuk a leveleket átmásolni az aktív node-ról a passzívra, de egy failover történik, akkor a korábban kézbesített levelek a tranposrt dumpster-bol lekérdezhetoek. Nos ez a funkció megváltozott. Új nevet is kapott: Safety Net. A Safety Net legfontosabb újdonságai:

• Safety Net egy queue, ami az adott Mailbox Role-n futó Transport Service-hez van rendelve. Tárolja a korábban kézbesített leveleket.
• Safety Net nem csak DAG környezetben van. DAG vagy DAG nélkül egyaránt funkcionál. A Safety Net tárolja a vele azonos AD telephelyen levo másik standalone Exchange Server 2013 postaláda szerver adatbázisába kézbesített leveleket is.
• Safety Net az Exchange Server 2013 esetében redundáns. Van egy Primary és egy Shadow Safety Net. Ha a Primary Safety Net nem elérheto, akkor a Shadow Safety Net használható a kézbesítésre.

A Safety Net tehát tartalmazza a korábban küldött leveleket. De mennyit? Hogyan lehet szabályozni a Safety Net méretét? Azt lehet szabályozni, hogy a kézbesített elemek meddig legyenek bent a queue-ban. Ez alapértelmezésben 2 nap. A get/set-transportconfig segítségével konfigurálható ez az érték:

Összegzés:

• A Safety Net-nek nagy a helyigénye egy nagyvállalati környezet esetében, mert a 2 napnyi levelezést megorzi és AD telephelyen belül redundáns
• A Safety Net funkciónak köszönhetoen a levélkézbesítés garantált, szélsoséges technikai helyzetekben is
• A 127GB nem biztos, hogy minden környezetben elég, érdemes monitorozni a szabadhely mértékét, illetve tervezni kell a Safety Net méretével (a transport dumpster esetében a tervezés mértéke elhanyagolható volt, ezért ez egy olyan terület amit át kell gondolni az Exchange Server 2013 bevezetések esetén)
• Érdemes megfontolni azt, hogy a Transport queue-t ne a System partíción helyezzük el. Teljesítmény szempontból célszeru egy önálló diszkre áthelyezni

A saját Exchange környeztemben egy nagyon egyszeru idozített feladattal hetente törlöm az IIS logokat, és a protokoll naplókat.

Kellemes ünnepeket mindenkinek. Jövore folytatom.