Exchange Server 2016, távolról rápillantva

Cloud PlatformPetrényi József

Fura átváltozásokkal találkozhat, aki nagyobb időtávlatban figyeli az Exchange Server átalakulásait. Számomra olyan, mint egy videóeffekt, amikor apró kockákra robban egy kép, aztán a kockák lepotyognak és egy teljesen más kép áll össze belőlük.

Eredetileg az Exchange egy monolit alkalmazás volt, aztán kezdett szétesni szerepkörökre, csúcspont a 2007/2010, majd ezek a szerepkörök elkezdtek összeolvadni. És hoppá, itt van az Exchange 2016 architektúra: az utolsó szabadharcos, a CAS szerepkör is eltűnt a palettáról. Beleolvadt a Mailbox szerepkörbe. Kaptunk egy újabb monolit rendszert… csak éppen a tartalma már egészen más.

xch2016

Ne mondd azt, hogy nagyon meglepődtél. Már a 2013-as CAS sem volt az igazi, gyakorlatilag csak egy nagyon vékony webproxy volt a Mailbox szerver előtt. Az általunk megszokott CAS funkcionalitás jelentős részét a Mailbox szerverben lévő vastag CAS végezte. 2016-ban ez a vékony proxy fog eltűnni, a Mailbox szerepkörbe épített CAS funkcionalitás pedig nem lesz névvel megkülönböztetve. MBX, és kész.

Na jó, Edge szerver még lesz külön.

Oké, akkor nézzük meg, mit is jelent ez a változás. Nyilván az elérési protokollok kezelését fogja a leginkább érinteni. Az a pici proxy eddig elintézte, hogy a kliens kérése már a megfelelő Mailbox szerver CAS funkciójához navigáljon. 2016 után proxy nincs, így a Mailbox szerver CAS szolgáltatása (nicsak, service formában fennmarad a neve) fogja ezután intézni a továbbirányítást. Azaz a vékony proxy CAS funkcionalitása gyakorlatilag beleépül a Mailbox szerver vastag CAS funkcionalitásába. Vegyük észre, hogy manapság is hasonló eredményt kaphatunk, ha egy szerverre telepítjük az MBX és CAS funkciókat, csak éppen a 2013-ban azért még gépen belül elkülönül egymástól a két (vékony/vastag) CAS funkció. Értelemszerűen az Exchange szerverek előtti loadbalancer konfigurálását ez a változás nem igazán érinti, olyannyira nem, hogy simán be lehet tenni mögé vegyesen 2013, illetve 2016 szervereket is.

Ha az architektúrát nézzük, ez a leginkább szembeötlő változás. De vannak még mások is, nyilván. A továbbiakban ezekből szemezgetek.

DAG. Két nagyobb változást emelnék ki, egyrészt megszűnik a DAG IP cím (eddig se nagyon használtuk), illetve az adatbázis failover 33%-kal gyorsabb lett. (Higgyük el.) Ide tartozik még a search adatbázisokkal történő variálás is, a 2016-ban a search adatbázisok nem logreplikáción keresztül frissülnek az adatbázis aktív példányáról, hanem minden szerveren helyben készülnek, a passzív adatbázisokról. Ez 40%-kal csökkenti a replikációs sávszélességigényt. (Igen, ezt is tessék elhinni.)

Programozási felület. Habár még ismerek olyan céget, ahol a mai napig event szkripteket (Exchange 4.0 technológia) használnak, de 2016-ban már az EWS megmaradásáért kellett szurkolnunk. Ugyanis bekerült az on-premise Exchange-be az úgynevezett REST API, mely az Office365 mögött dübörög. Szerencsére marad az EWS is, de az MS a jövőbeli és platformcentrikus fejlesztés miatt már inkább a REST-et ajánlja.

OWAS, azaz Outlook Web App Server. Aki esetleg nem ismerné, ez egy külön telepítendő alkalmazás, mely lehetővé teszi, hogy OWA-ból (és egyéb webes hozzáférésekből) ne csak megnézhessünk, hanem szerkeszthessünk is Office-dokumentumokat. A 2016-os verzióban annyi változás lesz, hogy ezt az alkalmazást már telephelyenként más névtér mögé kell telepítenünk.

Logikusan az Exchange 2016 már a 2013-ban is bekapcsolható MAPI over HTTPS protokoll használata felé mozdul el, azaz alaptelepítésben ez az elérés be lesz kapcsolva. Ezzel párhuzamosan ki lesz nyírva a MAPI/CDO. Tudom, a 2103-ban is ezt mondták, de aztán még megmentették az erre épülő alkalmazásokat (Blackberry, Symantec Enterprise Vault, stb.). A 2016-ban az a mondás, hogy álljatok át fiúk vagy az EWS-re, vagy a REST-re.

Nagyjából ennyi. Ez egy nagyon gyors áttekintés volt, akit jobban érdekelnek a mélységek, olvassa át Ross Smith írását az Exchange blogon.

Szólj hozzá!

komment