Month: June 2013

Néhány e-prospektus

Most ilyen töltögetős időszak van. Az MS oldalán összeszedtek néhány Visio doksit arról, hogyan is képes együttműködni az Exchange, a Lync és a Sharepoint. A magam részéről erősen hiszek benne, hogy mérnökember rajz alapján ért meg dolgokat, szóval egy pillantást mindenképpen érdemes ezekre az anyagokra vetni.
link

CAS Array 03/03 – Exchange 2013

Ez elméletileg a világ legrövidebb cikke lehetne: az Exchange 2013-ban nincs CAS Array. Pont.

De nem ússzuk meg ennyivel. Hiszen a CAS Array funkcionalitása hasznos volt. Valahol kell lennie valami hasonlónak.

Mindenekelőtt vizsgáljuk meg az előző írásban feltett két kérdést.

  1. Ha minden RPC forgalom RPC over HTTPS formában menne, szükségünk lenne-e marha drága loadbalancer készülékekre?
    A válasz egyértelműen az, hogy nem. A loadbalance algoritmus a layer7-ről lecsúszna a layer4-be, ott pedig már elboldogul egy sokkal olcsóbb reverse webproxy is.
  2. Át lehet-e terelni minden RPC forgalmat RPC over HTTPS-re?
    Ez már fogósabb kérdés. Mi dönti el, hogy az Outlook melyik metódussal próbálkozik? Gyakorlatilag a sikertelenség. Ha beállítjuk az Outlook profilunkban a belső szerver/CAS Array elérhetőségét, majd megadunk hozzá egy proxy szervert is, akkor az Outlook először megpróbálja RPC over TCP protokollon keresztül elérni a belső szervert. Ha a belső hálón van, akkor ez valószínűleg sikerül is neki. Ha a külső hálón van, akkor jó eséllyel nem. (Ha csak el nem konfigurálod.) Ilyenkor vált át RPC over HTTPS-re és támadja meg a proxyként megadott címet.
    Látható, hogy ha csak külső felhasználóink vannak, akkor a probléma megoldható. De ha már van belső felhasználónk is, akkor az először a belső címre próbálkozik, RPC over TCP-vel. Nyilván ezt blokkolhatjuk, vagy a CAS Array IP címének beállíthatunk valami marsbéli IP címet is – de ezekért súlyos timeout-tal, közvetve pedig felhasználói elégedetlenséggel fizetünk. Mivel az Outlook elsősorban a sima RPC-t favorizálja, így a belső hálón nem ússzuk meg a loadbalancert.

Itt jön be a képbe az Exchange 2013. Ebből ugyanis kidobták az RPC over TCP protokollt.
Elég markáns megoldása a problémának, nem mondom. Ezzel ugyanis teljesen megváltozott a leányzó fekvése. Mivel az Exchange 2013 CAS nem fogad el RPC over TCP-t, marad az RPC over HTTPS. Ez pedig már webes protokoll, melyet minden további nélkül tudunk loadbalancolni a Linux szerverünkkel. Aztán gondoljuk tovább: szükségünk van-e még az adatbázisok RPCClientAccessServer változójára? Miért lenne? Az Outlook már nem innen fogja megtudni a CAS szerver nevét. Ezért nincs szükség magára a CAS Array objektumra sem.
Ha nem innen, akkor viszont honnét? Hát az Autodiscover szolgáltatástól, mint minden más normális webes elérés az Exchange-ben. Az Outlook Anywhere szolgáltatásnak is lesz internalhostname és externalhostname paramétere, ahol az internalhostname mondja meg, melyik szervert kell támadnia bentről az Outlooknak.
Ismerős?
Na, ebből a névből lehet CAS Array-t faragni. Létrehozunk egy bejegyzést a DNS-ben, a megszokott outlook.cegnev.local névhez. Ez lehet egy kitüntetett CAS szerver IP címe, lehet DNS round robin formában az összes CAS szerver IP címe és természetesen lehet ez a reverse proxy szerverünk “külső” IP címe is. Aztán egyenként átírjuk az összes CAS szerverünkön az internalhostname paramétert erre a névre.

A CAS Array esetében láttuk, hogy kulcsfontosságú volt, mikor hoztuk létre. Jelen esetben ez már nem annyira lényeges. Amint átírtuk az értéket, az Autodiscover véges időn belül észleli a változásokat és szét is küldi.

CAS Array 02/03 – Amikor kezd bonyolódni az élet

Nos, nézzük meg alaposabban, mi is történik a különböző RPC kapcsolatok esetén, ha már van CAS Array objektumunk és rendesen be is lett állítva mind az adatbázisokban, mind az Outlook profilokban.

1. Sima RPC over TCP

From Segédlet

Ez egy viszonylag egyszerű eset. Van egy CAS Array, mondjuk outlook.cegnev.local. (Javasolt best practice.) Ennek az IP címét a DNS-ben úgy állítjuk be, hogy az egyik CAS szerverre, jelen esetben a CASy-ra mutasson. Az Outlook profilban az outlook.cegnev.local név szerepel, így az RPC kérés elmegy a CASy-ra, ott az MSExchangeRPC szolgáltatás a felhasználó MDBHome értéke alapján megkeresi, melyik Mailbox szerveren van éppen az aktív adatbázisa, és már proxyzza is a kérést.

2. Magas rendelkezésreállású RPC over TCP

From Segédlet

Magas rendelkezésreállás. Csináltunk DAG-ot, van több DC-nk, mind a hardverek, mind a network eszközök redundánsak. Most már csak az Exchange elérésének kellene annak lennie. Az RPC kommunikációt kétféleképpen tehetjük azzá:

  • Windows Load Balance Service, magunk között csak WLBS.
    Felejtős. Anyira, hogy a Microsoft sem ajánlja. Ha érdekelnek a részletek, akkor a legnagyobb hiányossága az affinitás. Pontosabban a hiánya. Csak akkor hagy figyelmen kívül egy node-ot, ha az már IP szinten sem érhető el. Exchange esetében van még egy durva hátrány: a failover cluster és a WLBS nem fér el egy gépen, tehát a korrekt megoldás még két Windows és még két Exchange licenszbe kerülne.
  • Hardware loadbalancer
    Ennyi pénzért már korrekt hardveres loadbalancer kapható. Ez ügyes, okos, mindent tud.

Tehát betettük a loadbalancer clustert a belső hálózatunkba. Cluster, mert ugye magas rendelkezésreállás. Belső háló, mert az RPC csak ott van értelmezve. Jól is néznénk ki, ha kintről is jönnének RPC kérések.
A CAS Array IP címe egyben a loadbalancer cluster virtuális IP címe. A kliensről ide érkezik be a kérés, a loadbalancer pedig a beállított konfigurációja alapján továbbítja a kérést valamelyik CAS szerver felé. Jelen esetben ez megint a CASy. Onnantól minden megy ugyanúgy, mint az előző esetben.

3. RPC over HTTPS

From Segédlet

Eddig beszéltünk a belső hálózatról. De mi van azokkal, akik valamilyen okból kifolyólag kívülről szeretnék elérni a postafiókjukat? Outlookból?
Erre találták ki az RPC over HTTPS-t. Az Outlook kliensben megadom az elérendő belső címet (outlook.cegnev.local), de mellette megadjuk a DMZ-ben elrejtett reverse proxy kinti nevét is. (Ez simán lehet egy mezei virtuális Linux egy akármilyen webszerverrel.) A reverse proxy tudja, hogy a kívülről jövő HTTPS kérést – mert ő csak ennyit lát belőle – melyik belső webszerverre kell dobnia. (Megjegyzem, itt már remekül lehet affinitást is konfigurálni – de webproxynál csak webes protokollokra működik.) A fenti ábrán a CASx webszervert választotta. A CASx terminálja a HTTPS csatornát. Itt bújik ki belőle az RPC és nekiáll keresni a CAS Array-t. A DNS vissza fogja dobni neki a beállított IP címet, a kérés továbbpattan, majd onnan megy minden, mint korábban.

4. Magas rendelkezésreállású RPC over HTTPS

From Segédlet

Ha már van egy loadbalancer készülékünk, mely az Exchange szerverek RPC szolgáltatásait proxyzza, simán használhatjuk arra is, hogy ugyanezen szerverek webszolgáltatásaival is megtegye ugyanezt. (Sajnos a Linux szervert nem tudjuk használni RPC proxyzásra, mert az már layer7.) Ettől persze egészen érdekes lesz a táncrend. A loadbalancer VIP címe van kiforgatva a külvilág felé, ide érkezik be a HTTPS forgalom. Az eszköz a HTTPS loadbalance paraméterek szerint dobja tovább a kérést egy tetszőleges CAS szervernek, ez megint a CASx. A CASx terminálja a HTTPS forgalmat, kibújik az RPC, keresi a CAS Array-t – mely jelen esetben megint a loadbalancer VIP címe. Viszont ekkor már RPC forgalomról beszélünk. A forgalom az RPC loadbalance szabályok szerint megy tovább, immár a CASy-ra, ahonnan már ismerjük a mókát.

Hogy tetszik?
Mert nekem nem túlzottan. Az utolsó két ábra olyan, mint egy Klampár-Jónyer pingpongmeccs. Muszáj ekkora adok-kapokba belemennünk?
Nem. Az MSExchangeRPC szolgáltatás képes arra, hogy megtalálja a rövidebb utat az erdőn keresztül.
De ehhez durván le kell szarnia az etikettet.
A valós működés az, hogy abban a pillanatban, amint egy CAS szerver kap egy proxyzandó kérést, mindent félretéve megpróbálkozik maga elérni az illetékes Mailbox szervert. Amennyiben ez sikerül, akkor a kérés már nem pattog tovább.

Tessék ezen egy kicsit elgondolkodni. Az utolsó két ábráról egyből látszik, hogy hülyeség. Valótlan. Már a CASx szerver megpróbálkozik elérni a Mailbox szervert és amennyiben sikerül neki, akkor a többi elem nem játszik.
Konkrétan letojja, hogy van-e CAS Array és mi a konfigurációja. Megpróbálja elérni a Mailbox szervert, és ha sikerül, akkor sínen vagyunk. Sőt, a sima RPC over TCP kapcsolatoknál sem foglalkozik egyik CAS szerver sem a CAS Array objektummal. Tőlük fel is fordulhat.

Fogadok, most összezavarodtál. A cikkek lényege éppen az lett volna, hogy megmutassam, mennyire fontos dolog ez a CAS Array objektum. Aztán kiderül, hogy a kutya sem használja. Írtam két hosszú cikket, ábrákat rajzoltam… majd kinyírtam a főhőst, mintha egy Trónok Harca szereplő lett volna. Ennek mi értelme?

Jó, pihenjünk meg egy kicsit.

Ha már lehiggadtunk, észre fogjuk venni, hogy tulajdonképpen minden rendben van: az MSExchangeRPC szolgáltatás akkor önállóskodik, amikor a kérés már elérte a CAS szervert; a CAS Array pedig arra szolgál, hogy a kliens elérje az első CAS szervert. A CAS Array nem tehet arról, hogy az RPC over HTTPS egy reverse proxyn keresztül jön be és már ez a proxy megmondja, melyik CAS szervert kell elérni. Az RPC over TCP protokoll esetében meg természetes, hogy a CAS szervereket nem érdekli a CAS Array: nem nekik találták ki. A CAS Array objektumot a MAPI kliensek használják.

Viszont ajánlanék a figyelmedbe két töprengenivalót.

  1. Ha minden forgalmat sikerülne RPC over TCP helyett RPC over HTTPS-re terelni, akkor szükség lenne-e a magas rendelkezésreállás biztosításához a drága loadbalancer cuccokra? Nem lenne-e elég helyettük az ingyenes Linux reverse proxy?
  2. Meg lehet-e oldani, hogy minden kliens forgalom RPC over HTTPS-en keresztül menjen?

Teched 2013

Ha nem tudtál elmenni, és fura módon az előadások is érdekeltek volna, nem csak New Orleans, akkor jó hírem van: az Ask the Core team összeszedett egy tonna videót az érdekesebb előadásokról. Nézhetők, letölthetők.

Jó böngészést

CAS Array 01/03 – Alapozás

Már régóta terveztem írni egy részletesebb cikket az Exchange 2010 CAS Array működéséről, mert úgy tapasztaltam, hogy még a legprofibbak fejében sem tiszta teljesen a kép.

Kezdjük rögtön a fogalom tisztázásával. Sokan az ‘array’ névből egyből magas rendelkezésreállásra gondolnak, és összekeverik a loadbalance megoldásokkal. Hiba. Nagyon pongyola megfogalmazással a loadbalance feladata a kliens kérését egy adekvát szerveren futó szolgáltatás felé irányítani, míg a CAS Array feladata… tulajdonképpen ugyanez, de nagyon nem mindegy, mit értünk adekvát szerver kifejezés alatt, hol történik meg az irányítás… és természetesen terheléselosztásról szó sincs.

Mielőtt teljesen belebonyolódnék, kezdjük el boncolgatni az Exchange 2010 kliens oldali hozzáféréseit.
Vannak a tiszta webes hozzáférések. Ezekről túl sokat nem kell magyarázni, mindenki látott már webszervert, webes szolgáltatást. Aztán van az RPC over TCP, azaz a klasszikus MAPI. Ezt használja a vastag kliens – Outlook – de léteznek más külső alkalmazások is, mint például a Blackberry szerver. Ez nagyon nem webes hozzáférés: alaphelyzetben több tízezer port közül választhat kapcsolatonként egyet, illetve kell neki a 135-ös, ahol az endpoint mapper azt mondja meg, melyik is lett kiválasztva. (Szerencsére ez az egész konfigurálható, de jelen sorozatban ezzel nem foglalkozok.) Az Exchange-ben létezik az RPC-nek webre erőszakolt verziója is, az RPC over HTTPS, azaz az Outlook Anywhere. Itt az RPC forgalmat HTTPS csatornába gyömöszölték, így lett belőle webes adatforgalom.

Foglalkozzunk most egy kicsit részletesebben ezzel az RPC-vel. A 2010-es verzióban az RPC over TCP elérésben nagy változás történt: az Outlook kliensek immár nem közvetlenül a Mailbox szerverre kapcsolódnak, hanem egy baráti CAS szerverre, mely proxyzza az RPC kérést a Mailbox szerver felé. Innentől lesz érdekes a dolog. Honnét tudja az Outlook, hogy ki az a baráti CAS szerver, aki valószínűleg el fogja tudni érni a Mailbox szervert?

Amikor létrehozunk egy adatbázist, akkor annak az RPCClientAccessServer változójába beleíródik egy név. Ha magán a szerveren fut CAS szerepkör is, akkor a saját neve, ha nem, akkor az Exchange keres egy közeli, RPC-n elérhető CAS szervert és annak a nevét írja bele. Ez lesz az a CAS szerver, aki proxyzza a kérést az adott adatbázis felé.
Amikor a felhasználó létrehoz egy Outlook profilt a gépén, akkor az történik, hogy az Outlook kiolvassa, melyik adatbázisban van a felhasználó postafiókja, majd megkeresi ennek az adatbázisnak az RPCClientAccessServer értékét – és erre a szerverre állítja be a profilban a kapcsolódást.
Ez szépen működik is addig, amíg az a bizonyos CAS szerver elérhető. De mi van akkor, ha ledől? Az Outlook továbbra is a profilban lévő CAS szervert fogja ostromolni – sikertelenül. Hiába létezik másik CAS szerver és hiába tökéletesen egészséges az adatbázis, a felhasználó nem fér hozzá a postafiókjához.

Akár külön cikkben is lehetne részletezni, hogy mikor, mi történik. A pontos forgatókönyv csak a következőktől függ: az Exchange verziója, service pack száma, rollup pack száma, hány AD site-on vannak Exchange szerverek, használunk-e DAG-ot, loadbalancer-t, reverse proxy-t, vannak-e public foldereink és nem utolsósorban, milyen verziójú Outlook-ok vannak a cégnél.

Maradjunk annyiban, hogy ilyen esetben kisebb-nagyobb kényelmetlenségek történhetnek, melyek között szerepel az elérhetetlenség is.

Ennek a szituációnak az elegáns kezelésére találták ki a CAS Array-t.

A CAS Array egy meglehetősen absztrakt objektum az Active Directoryban. Van neki neve, FQDN értéke és egy listája, hogy mely CAS szerverek tartoznak bele. Ez egy AD site szintű objektum, azaz automatikusan a site-on belüli összes CAS szerver tagja lesz. A létrehozását nem fogom leírni, tele van ilyesmivel a net. Arról, hogy az FQDN értelmezhető legyen, nekünk kell gondoskodnunk, azaz létre kell hozni hozzá egy DNS bejegyzést.

Innentől kezdve ha kreálunk egy új adatbázist, akkor annak az RPCClientAccessServer értéke a CAS Array neve lesz. A MAPI kliensek a CAS Array nevét kapják meg. Itt jön be a képbe a DNS. A CAS Array IP címe magas rendelkezésreállású környezetben lehet a loadbalancer IP címe, egyébként pedig lehet egy általunk kiválasztott CAS szerver IP címe.
Nézzük, mi történik most a korábban vázolt példában. Azt mondtuk, hogy a Mailbox szerveren nincs CAS funkció, ezzel szemben van több különálló CAS szerverünk. Ha kidől az egyik, akkor semmi gond sincs, a DNS-ben átírjuk a CAS Array IP címét a másikra. Életszagúbb példa, hogy teszem azt, lecseréljük a CAS szerverünket. Megint csak elég átírni az IP címet a DNS-ben. A kliensek mindkét esetben gond nélkül veszik az akadályt, hiszen nem kell módosítani a profiljukban semmit. (Természetesen ezek a szituációk kezelhetőek CAS Array nélkül is, de sokkal nyögvenyelősebben. Természetesen a korábbi kiemelés megjegyzései most is érvényesek.)

Még egy apróság: a régi, azaz a CAS Array létrehozása előtti adatbázisokban az RPCClientAccessServer értéke nem változik meg magától, itt manuálisan kell módosítanunk. Hasonlóképpen a már létrejött Outlook profilokban sem történik meg magától az átállás, ehhez különféle varázslások kellenek. (Nem mindig, és nem minden varázslás működik minden esetben, de ebbe most megint ne menjünk bele.) Ezért szokták azt mondani, hogy Exchange 2010-es környezetben az első dolgunk legyen létrehozni a CAS Array-t, még azelőtt, hogy a kliensek hozzákapcsolódnának. (És persze a default adatbázisban írjuk át manuálisan az értéket.) Ezt célszerű megtenni még akkor is, ha nem foglalkozunk magas rendelkezésreállással, hiszen nem tudhatjuk, mit hoz a jövő, és a legótvarabb munka egy Exchange organizáció átvariálásakor a kilensek átkonfigurálása.

Mit fogunk ekkor látni? Ha megnézzük az Outlookban, akkor azt, hogy a kliensünk mind a webes kapcsolódásokban, mind az RPC-ben immár a CAS Array nevet használja, azaz azt az IP címet fogja támadni, amit mögé tettünk. Innentől bármikor nagyon könyen tudjuk terelni a forgalmat.

Két megjegyzés:

  • A fenti állítás nem teljesen igaz. A Public Folderek RPC elérése nincs proxyzva, tehát ott, ha mandinerből is, de a Mailbox szervert támadja a kliens.
  • Bárkiben felmerülhet az ötlet, hogy hoppá, itt olcsón lehet magas rendelkezésreállást létrehozni: a DNS-ben round robin módon felveszem ugyanarra a névre az összes CAS szervert. Ez jó addig, amíg mindegyik CAS szerver működik, de ha bármelyik ledől, arról a DNS nem fog tudni és simán kiadja a nem elérhető címeket is a hozzá fordulóknak.

Ennyi volt az alapozás. A következő írásban némileg mélyebben beleásunk a különböző RPC kapcsolódásokba, megvizsgáljuk, hogyan befolyásolja mindezt a loadbalancer, illetve a HTTPS csatornázás.