Postaláda mozgatás sebessége Exchange Server 2010-ről, Exchange Server 2013-ra

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 idonk 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övetkezo feladatokat terveztük be az egyik ügyfelemnél:

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

Azon túl, hogy a mozgatást elvégezzük, pótolhatatlan “telemetria” adatok gyujtésére is alkalom nyílt. Ebbol 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ó jelleguek, nem hivatalos méroszá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! Bovebb információ errol késobb.

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

• 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 rendszerbol 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övetkezo értékekkel állítottuk be:

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

Postaládák jellemzoje

A mozgatás sebességét a szerverek kapacitásán túl jelentosen befolyásolja a mozgatandó postaládák mérete és a postaládában tárolt elemek száma. Ez egyszeruen lekérdezheto a get-mailboxstatistics parancs segítségével amibol késobb statisztikát készíthetünk. Ezt a mozgatandó ~1500 postaládáról elkészítettem. Az érintett környezetben a következo adatokat mértem:

Mért eredmények

A hétvégi “kirándulásunkat” a következo á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 ido, a függoleges 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övetkezo grafikonon látható:

A következo á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ézopontjából mérheto az, hogy milyen adatátviteli sebességgel dolgozik. A grafikon vízszintes tengelyén az ido, a függoleges 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 jelentos 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önnyu azt belátni, hogy akkor, amikor mozgatjuk az adatokat és öntjük bele a cél adatbázisba az adatokat, akkor a Content Indexing jelentos 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övetkezo ábrán ezeknek az eseményeknek a számát rögzítettem. A vízszintes tengelyen az ido, a függoleges tengelyen a megállított mozgatások számát ábrázoltam:

A cél kiszolgálón a processzor terhelés meglehetosen magas volt. A vízszintes tengelyen az ido, a függoleges 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 elott.

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 jelentos 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ó jellegunek, 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 elso két grafikon) viszont a teljes folyamatot lefedi.