Bevezetés

Nem is tudom, hogy mikor volt utoljára valós hosszú hétvégém. Ezek nekem mindig kapóra jönnek és alibit szolgáltatnak arra, hogy nagyobb átalakításokat végezhessek az ügyfeleimnél. Ilyenkor több időnk van, mint egy átlagos éjszaka vagy hétvégén, így nagyobb feladatokba is belevághatunk. Nem történt ez másként most sem. A hosszú hétvégére a következő feladatokat terveztük be az egyik ügyfelemnél:

• ~1500 postaláda mozgatása Exchange Server 2010-es környezetből Exchange Server 2013-as környezetbe
• ~1100 postaláda mozgatása Exchange Server 2013-as környezetből egy újabb verziójú Exchange Server 2013-as környezetbe (mivel ez az eset nem jellemző, ezért erről nem közlök adatokat)

Azon túl, hogy a mozgatást elvégezzük, pótolhatatlan “telemetria” adatok gyűjtésére is alkalom nyílt. Ebből viszont mindenkinek profitálnia kell, így a legfontosabb adatokat anonimizálva természetesen itt megosztom. Mai bejegyzésem legfontosabb célja az, hogy a mozgatás sebességére vonatkozóan mindenki pontos referencia adatokkal rendelkezzen. Ezek az adatok tájékoztató jellegűek, nem hivatalos mérőszámok. Továbbá ezt ne próbálja ki senki otthon. Speciális helyzetben vagyunk, ebben a környezetben támogatjuk az Exchange Server 2013 és 2010 együttélést. Minden más környezetben jelenleg ez nem támogatott! Bővebb információ erről később.

Ahhoz, hogy a számokat ne csak számoknak lássuk és összehasonlíthatóvá tegyük későbbi mérésekkel, a környezetet definiálni kell. A mérést adó környezet legfontosabb jellemzői:

• végfelhasználói terhelés a mozgatás ideje alatt közelít a nullához (hétvége, ráadásul hosszúhétvége)
• a forrás rendszer SATA lemezeken, SAN-on
• a célrendszer SATA lemezeken iSCSI interfészen keresztül DAS-on
• a forrás rendszerek CPU és RAM tekintetében túlterheltek
• a célrendszer CPU és RAM tekintetében ideálisan méretezve
• a forrás és a cél rendszerek között Gbps-es kapcsolat van, ami nem dedikált, a felhasználói kérések kiszolgálásával konkurál
• a forrás rendszerben és a célrendszerben 1-1 adatbázis-másolat replikációja folyamatos
• a forrás rendszerből a törlést replikálni kell a másik node-ra
• a célrendszerben az új adatokat replikálni kell
• a cél és a forrás rendszerben is az adatbázisok replikációjára dedikált Gbps-es kapcsolat áll rendelkezésre
• a forrás gépek fizikai szerver, Windows Server 2008 R2 OS-el
• a cél gépek virtuális szerverek
• a host Windows Server 2012
• a guest Windows Server 2012

A korábbi tesztjeink alapján a Mailbox Replication Service konfigurációját a következő értékekkel állítottuk be:

• MaxActiveMovesPerSourceMDB=5
• MaxActiveMovesPerTargetMDB=4
• MaxActiveMovesPerTargetServer=8

Postaládák jellemzője

A mozgatás sebességét a szerverek kapacitásán túl jelentősen befolyásolja a mozgatandó postaládák mérete és a postaládában tárolt elemek száma. Ez egyszerűen lekérdezhető a get-mailboxstatistics parancs segítségével amiből később statisztikát készíthetünk. Ezt a mozgatandó ~1500 postaládáról elkészítettem. Az érintett környezetben a következő adatokat mértem:

Mért eredmények

A hétvégi “kirándulásunkat” a következő ábra szemlélteti leginkább. Ezen az ábrán az látható, hogy milyen ütemben kerültek át a célrendszerbe a postaládák. A vízszintes tengelyen az idő, a függőleges tengelyen az átmozgatott postaládák száma látható.

A grafikonról könnyen leolvasható, hogy a mozgatás sebessége egyenletes. Ez óránkénti bontásban a következő grafikonon látható:

A következő ábrán a Mailbox Replication Service (MRS) mozgatási sebessége látható. Az MRS végzi a tényleges mozgatást. Az MRS nézőpontjából mérhető az, hogy milyen adatátviteli sebességgel dolgozik. A grafikon vízszintes tengelyén az idő, a függőleges tengelyén az MRS szolgáltatás mozgatásának sebessége látható KB/sec-ben.

Egy korábbi posztomban már foglalkoztam egy jelentős területtel, ami a postaláda mozgatás sebességét befolyásolhatja. Érdemes átolvasni az akkori posztot itt: Mennyire gyors a postaláda mozgatás és mi az a Workload Management?

Az a tapasztalatom, hogy az RTM kódban nagyon sokat javítottunk ezen a területen. A vizsgált környezetben a Workload Management összesen a Content Indexing állapota miatt lassította néhány alkalommal a postaláda mozgatást. Könnyű azt belátni, hogy akkor, amikor mozgatjuk az adatokat és öntjük bele a cél adatbázisba az adatokat, akkor a Content Indexing jelentős terhelés alatt van. Ha valamiért kicsit lemarad, akkor annak a keresésre negatív hatása lehet. Ezért ez is egy olyan pont amire a Workload Management figyel. Ha sokszor lemarad az indexelésben a szerver, akkor automatikus válaszlépésként lassítja a mozgatást. Okos dolog ez. A méréseim alapján ez volt az egyetlen ok, ami miatt a Workload Management közbeszólt. A következő ábrán ezeknek az eseményeknek a számát rögzítettem. A vízszintes tengelyen az idő, a függőleges tengelyen a megállított mozgatások számát ábrázoltam:

A cél kiszolgálón a processzor terhelés meglehetősen magas volt. A vízszintes tengelyen az idő, a függőleges tengelyen a CPU terhelése %-ban látható:

Végszó

Óránként kb. 50 postaláda átmozgatását mértem. Ez az átlagos 375MB-s postaládamérettel számolva, óránként kb. 19GB adat és kb. 92000 elem átmozgatását jelenti. A kb. 1500 postaládát így kb. 30 óra alatt mozgattuk át. Ez az eredmény feltétlenül bíztató a további több ezer postaláda mozgatás előtt.

Ha megnézitek a júliusi adatokat a korábban linkelt bejegyzésemben, akkor azt láthatjátok, hogy a bétával kb. 1GB/15 perces mozgatási sebességet mértem. Ahhoz képest az elmozdulás jelentős még akkor is, ha az ott nem egy 30 órás és nem több ezer postaláda mozgatás során lett kiszámítva.

A fenti adatokat kérlek kezeljétek tájékoztató jellegűnek, azok jó kiindulási alapot adhatnak arra, hogy tervezzetek. Azonban összehasonlító méréseket feltétlenül végezzetek!

Adatvesztés okán a perfmon adatok csak 12 órát fednek le. Az átmozgatott postaládák száma (az első két grafikon) viszont a teljes folyamatot lefedi.