Mennyire gyors a postaláda mozgatás és mi az a Workload Management?

Épp postaládát mozgatok a saját környezetemben a legújabb Exchange Server 2013 szerveremre. A migrációkra való felkészülés során elég gyakori a következo párbeszéd két szakember vagy ügyfél – tanácsadó felosztásban (ahol persze mindkét fél lehet szakember ):

• Milyen gyors a postaláda mozgatás?
• Hmmm. Az attól függ.
• Na jó, de úgy általában. Korábbi tapasztalatok mit mutatnak?

A párbeszéd itt általában vagy másik ösvényre megy, vagy legendák kerülnek elo. Az elso kérdésre a helyes válasz valóban az, hogy az attól függ, de mi az az attól? Néhány példa:

• Diszk sebesség – a forrás és a cél rendszerben 1-1 helytelenül kiválasztott diszkrendszer képes az egész mozgatás sebességét lerontani, méghozzá drasztikusan
• CPU kapacitás – a forrás és a cél rendszerben egyaránt elegendo CPU kapacitással kell rendelkeznünk. Ha a CPU maximálisan kivan terhelve, akkor a mozgatás sem lesz sebes.
• Hálózat – értelemszeruen az adatokat át kell mozgatnunk a két szerver között így a hálózat kritikus ebbol a szempontból. Azonban tipikusan a hálózattal soha nem szokott gond lenni. Nem láttam 10+ éve olyat, hogy a hálózat fogyott volna el a mozgatás alatt.
• Postaláda mérete – nem mindegy, hogy sok kicsi vagy kevés nagy elemet kell átvinnünk. A sok kicsi jóval több munka, mint a kevés nagy, még akkor is ha az össz.mérete azonos. Ilyen ez az informatika.

Gondoltatok már arra, hogy a postaláda mozgatással negatívan befolyásoljátok a szerver teljesítményét? Ha igen akkor mit tettetek annak érdekében, hogy ne legyen negatív hatása? Tipikus válaszok:

• Igen gondoltam és ezért soha nem mozgatunk postaládát napközben, csak offline idoszakban.
• Igen gondoltam és általában nem szoktam vele foglalkozni.
• Nem gondoltam erre még soha.

Bennem a kérdés már többször is felmerült. Exchange Server 2010 elott evidens volt, hogy csak éjszaka mozgatunk postaládákat, nyilvános mappákat stb. Exchange Server 2010 esetében pedig amikor eszembe jutott akkor általában próbáltam a negatív gondolatot elhessegetni magam elol.

Az Exchange fejlesztocsapat is gondolt erre a problémára és megoldotta. Az Exchange Server 2010-ben már megismerkedhettünk egy ThrottlingPolicy-val. Ez arra volt képes, hogy az egyes protokollokhoz tartozóan küszöbértékeket határozhassunk meg. A küszöbérték elérésekor az Exchange lassította / büntette az adott felhasználót. Átlagos adminisztrátor ezzel a BES használatakor találkozott eloször, amikor az összes BES eszköz egy BES Account nevében csatlakozott és a Throttling lefékezte az adott account-t.

A Workload Management ennél lényegesen komplexebb szabályozást tesz lehetové. A legfontosabb eroforrásokhoz tartozóan létrehozhatunk eroforrás házirendeket (ResourcePolicy) amiben részletes küszöbértékeket adhatunk meg. A küszöbérték elérése azt jelenti, hogy az adott eroforrásból kevés van, vagyis a szerver túlterhelt.

A Workload Management-rol késobb még részletesen fogok írni. Azonban tudni kell a postaláda mozgatásokra való felkészülés során, hogy az igazság pillanata elérkezik. Alapértelmezett beállítások mellett ha egy cél vagy forrás kiszolgáló túlterhelt akkor csapnivaló mozgatási sebességet fogunk látni. Ennek elsodleges oka a Workload Management által kidobott horgony, amivel lassítani próbálja a folyamatot. Érdemes ezt számításba venni és alaposan tesztelni a nagytömegu postaláda mozgatások elott.

A saját tesztkörnyezetemben mértem 166MB / perces mozgatási sebességet is:

Mégis a teljes postaláda ami kb. 2,9GB összméretu kb. 49 perc alatt mozgott át a két szerver között:

Ez úgy önmagában egy elég jó eredménynek számít, hiszen kb. 62 MB / perc átlagos mozgatási sebességet eredményez. De a fenti képet nézzük csak meg jobban:

• TotalQueuedDuration: 00:00:09 – világos, a move-request 9 mp-ig állt tétlenül, mire felkapta az MRS és elkezdte a mozgatást
• TotalInProgressduration: 00:48:49 – ez is értheto, összesen kb. 49 percig volt folyamatban a mozgatás
• TotalStalledDueToCIDuration: 00:07:23 – ez magyarázatot igényel. A CI itt a Content Indexing-et jelenti. Összesen kb. 7,5 percig állt a mozgatás mert a Content Indexing-el probléma volt.
• TotalStalledDueToReadUnknown: 00:02:52 – kb. 3 percig állt a mozgatás, mert a forrás szerverrol nem tudtunk olvasni (itt válik elég komplikálttá a helyzet mert történetesen ez a mozgatás Exchange Server 2013 –> Exchange Server 2013 viszonylatban történt, ahol a forrás szerveren büntetett a Workload Management)

Álljon itt egy közel hibátlan mozgatásra is példa, ahol 1,3GB-t mozgattunk meg kb. 16 perc alatt a két szerver között:

Néhány gondolat a végére:

• egy újabb szempontot kell szem elott tartanunk a mozgatások tervezése elott
• ha valami nincs rendben a forrás és a cél kiszolgálón akkor azt duplán fogjuk megfizetni a postaládák mozgatása során
• könnyedén elérheto akár 1 GB / 15 perces átlag sebesség is, ha minden rendben van a környezetünkben
• a Workload Management egy nagyon fontos téma, amirol késobb még írok!