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.

9 Comments

  1. Hello,

    egy kérdés: mikor az outlook kliens a belső hálózaton van, akkor az SCP-n keresztül az internalhostname értékeket adja vissza neki a DC?

  2. Az SCP csak azt mondja meg, ki a CAS szervered. Az azon futó autodiscover szolgáltatás adja meg a webszolgáltatások url-jét. Outlook Anywhere esetén megkapod mind az externalhostname, mind az internalhostname paramétert. (Ugyanide jutsz, ha kintről egy DNS bejegyzés mondja meg, milyen IP címre lett kipublikálva a CAS szervered autodiscover szolgáltatása.) Ha az Outlook fel tudja oldani az internalhostname url-t IP címre, akkor RPC over TCP-vel próbálkozik. Ha nem tudja feloldani, vagy nem jön össze az RPC kapcsolat, akkor vált át RPC over HTTPS-re.
    (Őszintén szólva, az még nekem sem világos, hogy az ebből adódó timeout-ot hogyan eliminálták a 2013-as környezetben.)

  3. Igaz, rosszul kérdeztem.
    Szóval, azt mondod, a 2013-ban már nincs RPC over TCP. Így a belső hálózaton lévő outlook kliens kap az autodiscovertől egy internalhostname és externalhostname értéket. Mi alapján dönti el, hogy melyik kell neki? Először rögtön az internal-t próbálja elérni és aztán az externalt?

    Bár lehet, meg is tudom magamnak válaszolni: ha SCP elérés megvan, akkor gondolom tudja, hogy belül van és kapásból az internalhostname-t próbálja feloldani. Ha nincs SCP (külső hálózat) akkor marad az externalhostname. Legalábbis pongyolán fogalmazva, de nagyjából.

  4. Nem így van. A mechanizmus, amit kérdezel, az az Outlook mechanizmusa és független attól, hogy milyen Exchange szerver van mögötte. Az hogy SCP, vagy DNS, az csak arra jó, hogy a CAS szervert megtalálja. Ha pl. belső géped van, amelyik nincs a tartományban, az is DNS alapján fogja megtalálni a CAS-t, mégis belső gép.
    A mechanizmus pedig az, amit korábban is írtam: internal névfeloldás, ha nem sikerült, akkor megy az external-ra. Ha sikerült, akkor megpróbál kapcsolódni. Ha nem sikerült, akkor megy az externalra.

  5. Most már tiszta, köszönöm!

  6. Timeout akkor van, ha nem erkezik valasz (tuzfalban eldobjuk a csomagot, vagy ertelmetlen IP-re megyunk). Van azonban egy harmadik es egy negyedik lehetoseg is. Az egyik a tuzfalon van, es nem csomageldobas a reakcio, hanem egy korrekt ICMP connection refused. Ekkor elvben (ha jo a Windows halozati stackje) nincs timeout, az Outlook rogton kesz tenyek ele van allitva. A negyedik lehetoseg pedig az RPC-n keresztul visszaadni egy olyat, hogy itt kerem ilyen szolgaltatas marpedig nincsen. Mert ne felejtsuk el, az Exchange 2013 nem az RPC over TCP-t magat szuntette meg, hanem onmaga elerhetoseget ezen protokollon keresztul. Maga az RPC meg egy darabig velunk marad sajnos, a Windows ilyen-olyan cuccainak koszonhetoen.
    De persze javits ki, ha tevednek, en nem ertek hozza, csak vegiggondoltam…

  7. A második (negyedik?) verzió egészen elképzelhetőnek tűnik.

  8. Mindig tanul az ember. Az Outlookban van egy kapcsoló, hogy különböző tipusú hálózatokon (slow/fast) melyik kapcsolódási formát válassza. Alapértelmezésben gyors hálózaton RPC over TCP, lassú hálózaton RPC over HTTPS – de beállítható, hogy mindegyik esetben az RPC over HTTPS-t használja, és ebben az esetben gyk. összeállt a szegényember loadbalancer-e.

  9. Viszont cserébe a proxy minden belépésnél autentikáltat egyet.

Leave a Reply