Egyidejű kapcsolatok száma max. 25000

Exchange Server 2010 / 2007 kiszolgálói architektúrához tartozóan a legfontosabb skálázási korlátokat tartalmazó dokumentáció. Az anyag itt elérheto: Exchange Scale Limitations Spreadsheet. Ebbol a dokumentumból szeretnék most kiemelni egy sort (25-s sor):

Ez pontosan azt jelenti, hogy legfeljebb 25000 egyideju kapcsolat mehet a CAS szerverhez Exchange Server 2010 esetében. Ezt érdemes fejben tartani, mert ennek kellemetlen mellékhatása lehet. Ez a beállítás az Exchange Server 2013 RTM kódban is így van, még pontosabban ez nem az Exchange kód, hanem IIS configuration file. Az Exchange kód itt csak azért fontos, mert a setup módosítja ezt az értéket 25000-re.

Tehát ez a beállítás az Exchange Server 2013-ra is igaz. De miért fontos ez? Nos, mint tudjuk, az Exchange Server 2013 esetében a MAPI over TCP kapcsolat megszunt. Azt felváltja a MAPI over HTTP, vagy hivatalos nevén az Outlook Anywhere. Ez kulcsfontosságú, ugyanis az Exchange Server 2013 átállást követoen minden Outlook kapcsolat immár a CAS-on keresztüli Outlook Anywhere kapcsolat lesz, amire a fenti korlát érvényes!

Egy pillanatra gondolkodjunk el, közösen egy elképzelt architektúrán. Az architektúra legfontosabb tulajdonságait:

• két darab Exchange Server 2013 CAS kiszolgálónk van
• a két CAS között “valamilyen” terheléselosztás van
• az Outlook felhasználók a terheléselosztásnak köszönhetoen a két CAS kiszolgálót egyenlo arányban terheli, ezt jelöli az ábrán a folytonos nyíl
• két darab Exchange Server 2013 Mailbox kiszolgálónk van
• a két Mailbox kiszolgáló egy Database Availability Group-ban van
• az összes postaláda adatbázis a két kiszolgáló között replikálva van
• az adatbázisokat alapértelmezésben az egyes postaláda szerver szolgálja ki, ha az meghibásodik, akkor az összes adatbázis kiszolgálása átkerül a kettes kiszolgálóra

A fenti kialakítás vagy annak bármilyen klónja nem ritka, kifejezetten a postaláda kiszolgálókra gondolok.

Az Exchange Server 2013 esetében az elodöktol eltéroen a postaláda kiszolgálói szerepkör valójában, az összes korábban ismert szerepkör egyvelege. Tehát az Exchange Server 2013 CAS és Mailbox szerver között is, RPC over HTTP kapcsolat van, elodjeitol eltéro módon. Miért fontos ez? Gondoljuk végig azt, hogy a bevezetoben említett 25000-es kapcsolati korlát az architektúra melyik pontján jelentkezik:

• A CAS kiszolgálói rétegben természetesen jelentkezhet, hiszen az Outlook kliens és a CAS kiszolgálók között RPC over HTTP típusú kapcsolat van. A fenti elképzelt architektúra esetében a terheléselosztásnak köszönhetoen a kapcsolatok 50%-a jelenik meg egyszerre bármely kiszolgálón, akkor ha mindkét kiszolgálónk muködik.
• A Mailbox kiszolgálói rétegben szintén jelentkezhet, hiszen a CAS és a Mailbox kiszolgálók között szintén RPC over HTTP típusú kapcsolat van. Az ábrán jelzett kialakításnak köszönhetoen minden kapcsolat csak az 1-es Mailbox kiszolgálót terheli, ezért az összes kapcsolatok száma azon az egy kiszolgálón jelenik meg, ellentétben a CAS kiszolgálóval, ahol kiszolgálónként elosztott módon jelenik meg a terhelés.

Persze a 25000-es kapcsolati korlát meglehetosen soknak tunik. De ez csak meglehetosen sok. Elég könnyu elérni már hazai méretekben is. Azt kell feltétlenül tudni, hogy egy Outlook felhasználó nem egy kapcsolatot jelent. Átlagosan 4-6 kapcsolat / felhasználó. Jó mutató az, ha az Outlook Connection Status ablakot elemezzük. Ott pontosan látszik, hogy az adott felhasználó, hány kapcsolatot jelent valójában. A jobbra látható képen a postaládám kapcsolatait látjuk, ahol egy postaláda, egy megosztott postaláda van nyitva és nincs Nyilvános Mappa a környezetemben. Ez így összesen 7 kapcsolat. Gyors fejszámolás: 25000/7 = 3571 felhasználó / szerver. Ez így rögtön nem is olyan sok!

Ezen a ponton meg kell még arról emlékezni, hogy eddig csak az Outlook Anywhere kapcsolatokkal foglalkoztam az elozo sorokban. Azonban ebbe a 25000-es korlátba az összes HTTP forgalom beleszámolandó, úgy mint Autodiscover, Exchange ActiveSync, OAB letöltés, OWA. Ha így nézzük, akkor még rosszabb a helyzet.

Amennyiben a korlátot elérjük, vagy túllépjük, akkor az IIS, 503-as HTTP hibakódot fog visszaküldeni. Ez azért lesz problémás, mert az Exchange saját monitorozó rendszere (Health Manager) ezen az ellenorzési ponton elbukhat. A Health Manager komponens rendszeres idoközönként megpróbál a saját teszt postaládáiba bejelentkezni. Ha ezt olyankor próbálja megtenni amikor a 25000-es limit elfogyott, akkor sikertelen lesz a próba. Ilyenkor a Health Manager újraindítja az IIS application poolt, majd a Microsoft Exchange RPC Client Access szolgáltatást. Ennek a végeredménye az lesz, hogy az Outlook kliensek leszakadnak az Exchange kiszolgálóról.

A következoket lehet tenni a hibaelkerülésére:

• Monitorozás
  • perfmon segítségével az érték mérheto, naplózható.

• Adatbázis elosztás
  • gyakorlatból mondom, hogy a CAS kiszolgálókon nem várható a 25000-es korlát elérése, a terheléselosztás miatt. Azonban érdemes megfontolni azt, hogy az adatbázisokat miként osztjuk el a Mailbox kiszolgálók között. Könnyu belátni, hogy a korábbi példán alkalmazott elosztási módszer a jelenséget felnagyítja. Ezért érdemes az aktív adatbázisokat elosztani a Mailbox kiszolgálók között. Erre kiválóan alkalmas a Scripts könyvtárban található RedistributeActiveDatabases.ps1 powershell script. A Script segítségével az adatbázisok ActivationPreference értéket módosíthatjuk, valamint az érték alapján a script az adatbázisokat elosztja a kiszolgálók között.
• Érték módosítása
  • az érték a C:\Windows\Microsoft.NET\Framework64\v4.0…..\Config mappában található machine.config fájlban kell módosítani a requestQueueLimit értékét
  •  
  • a módosítás után IISRESET szükséges
  • a módosítás elott érdemes a kiszolgáló eroforrásait (memória, diszk, CPU) monitorozni, abból egy alapértéket (baseline) meghatározni, amit a módosítás utáni mérésekkel össze kell vetni. A connection limit módosítása a kiszolgáló eroforrásaira hatással lehet.
• Méretezések során figyelembe kell venni
  • nincs is attól rosszabb helyzet amikor nem tudunk valamirol és az hatással van ránk. Ezért talán mindentol fontosabb, hogy a környezet tervezésekor ezt is figyelembe vegyük.

A legjobb módszer az, ha a tervezés során tudjuk ezt, gondolkodunk az adatbázis elosztáson és nem a megszokásokhoz huen egy kiszolgálóra rakunk minden aktív adatbázist, az implementáció után mérünk és ha kell értéket módosítunk, vagy oldalra skálázunk. Az új környezetek, vagy a frissítések során vegyétek ezt is számításba.