MSysObjects: Exchange 2010 ja Load Balancing, Osa 3

Exchangen palvelut

Microsoftilla on Technetissä aiheesta kaksi artikkelia. Aiheesta on pidetty myös esityksiä viime ja tämän vuoden TechEdissä. Artikkelit sisältävät suosituksia, miten eri applikaatioissa tulisi pysyvyysmääritykset tehdä. Alla oleva taulukko on yhteenveto näistä. Taulukko on peräisin Andrew Ehrensingin TechEd 2011:ssä pidetystä esityksestä. Sitä on hieman muokattu. RPC Endpoint Mapperille en ole löytänyt Persistence-suosituksia. Mutta loogisesti päätellen, sitä ei tarvita. Sillä asiakasohjelma tekee yhteyden alussa kyselyn RPC End Point Mapperin porttiin TCP 135 ja pyytää tietoa, missä portissa MAPI-pohjaiset palvelut ovat saatavilla. Exchange-palvelin palauttaa tiedon asiakasohjelmalle, jonka jälkeen liikennöinti tapahtuu määriteltyjä portteja pitkin. Oletusarvoisesti Exchange käyttää dynaamisia portteja TCP 1024-65535, mutta palvelut on kuitenkin hyvä määritellä staattisiksi Load Balanceria varten. Porttien arvot tulee olla välillä 59531-60554.

Exchangen palvelut voidaan jakaa karkeasti kahtia: http-pohjaiset (Layer 7) ja TCP Socket-pohjaiset (Layer 4). Jälkimmäinen liittyy Outlookin MAPI-yhteyksiin (pois lukien POP3 ja IMAP4) ja RPC Client Access Server-objektiin. Objekti luodaan seuraavasti:

New-ClientAccessArray –Name ”UC Demo Array” –Fqdn outlook.uc.demo -Site HQ

Tämä on siis se osoite, johon Outlook ottaa yhteyttä.

MAPI RPC:n staattinen määritys tehdään REGEDIT-ohjelmalla sekä CAS että Mailbox-palvelmelle:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\

ParametersSystem

DWORD: ”TCP/IP Port”

Value: ”59596”

Osoitteistoyhteyttä (Exchange Address Book service) varten määritellään myös kiinteä portti CAS-palvelimen REGEDIT-ohjelmalla:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ MSExchange-AB\Parameters

STRING: ”RpcTcpPort”

Value: ”59595”

Tämä portti käsittelee sekä Address Book referral (ABREF) - että Name Service Provider Interface (NSPI) -yhteyksiä.

CAS Arraylla voi olla sama nimi, kuin http-pohjaisilla palveluilla, mutta selvyyden vuoksi ne voidaan erottaa. Jos MAPI-yhteyttä kutsutaan nimellä ”Outlook”, voidaan http-pohjaisia palveluita kutsua vaikka nimellä ”OutlookWS”.

Nimet ja osoitteet

Nimistä päästään loogisesti seuraavaan asiaan, eli miten palvelut tulisi jaotella Load Balancerin näkökulmasta. Vaihtoehtoja on monia. Periaatteessa kaikki palvelut voivat olla yhden IP-osoitteen ja DNS-nimen takana, jolloin TCP Socket-pohjaiset palvelupyynnöt tunnistetaan portin perusteella ja http-pohjaiset palvelupyynnöt virtuaalihakemiston avulla. Tällöin Load Balancerilla tulee olla jokin mekanismi erottaa nämä palvelupyynnöt toisistaan. Palvelupyyntöjen erottaminen toisistaan on tärkeää Load Balancing Persistence-asetuksen takia. Tällöin tiettyihin palvelupyyntöihin sovelletaan tiettyä pysyvyysasetusta. F5 käyttää ns. iRules-tekniikkaa erottamaan palvelupyynnöt toisistaan ja HAProxy (jota tulevissa esimerkeissä käytetään) käyttää ACL-tekniikkaa. Tästä myöhemmin lisää. Mikäli Load Balancerissa ei ole tällaisia mahdollisuuksia tai muuten vaan halutaan, niin jokaiselle palvelulle voidaan määritellä oma DNS-nimi ja IP-osoite. Usean nimen käyttäminen täytyy huomioida myös varmenteessa. SAN-kentässä tulee olla kaikki ne nimet, joilla palvelua kutsutaan. MAPI-yhteyden nimeä ei tarvita varmenteessa. Yksi vaihtoehto on niputtaa Persistence-tyypin perusteella palvelut toisiinsa, jolloin jokaisella Peristence-tyypillä on oma DNS-nimi ja IP-osoite. Tämän artikkelin esimerkeissä on käytetty kahta DNS-nimeä ja yhtä IP-osoitetta seuraavasti:

DNS Name	VIP	Port	App
outlookrpc.uc.demo	192.168.221.250	135, 59595, 59596	-
outlook.uc.demo	192.168.221.250	443	/owa /ecp /EWS /Rpc /Microsoft-Server-ActiveSync /OAB /Autodiscover

Helpoin tapa lähteä liikkeelle on käyttää Load Balancering omaa Template-pohjaa, jos sellainen on saatavilla. Näin ainakin suurimmilla valmistajilla on. Silloin saa asetukset helposti suurin piirtein niin kuin ne on tarkoitettu olevan.

Exchangen CAS-palveluiden sisältö on kaikilla palvelimilla sama ts. jokainen CAS-palvelin on samanarvoinen. Kuormantasauksen näkökulmasta tämä yksinkertaistaa asioita. CAS-palvelimen sisäisiä palveluja voidaan kuitenkin hajauttaa juurikin palvelupyynnön perusteella. Pilvipalveluja tarjoa organisaatio voisi esimerkiksi määritellä kaikki */oab-pyynnöt tietyille CAS-palvelimille, jotka huolehtivat niiden jakeluista. Osoitteistojen koko saattaa jo kasvaa merkittävän kokoisiksi isoilla tarjoajilla, jolloin tätä kautta saadaan CAS-roolin sisäistä kuormaa hajautettua. Samaa voidaan soveltaa mobiilipäätteisiin ja sielläkin voitaisiin erotella vielä, millä päätelaitteella palvelua käytetään ja sen pohjalta ohjata palvelupyynnöt niitä vastaaville todellisille palvelimille.

URL-asetukset

Exchangessa on http-pohjaisissa applikaatioissa on vielä URL-asetukset, jotka liittyvät tähän aiheeseen. URL-asetukset jakautuvat kahtia: InternalURL ja ExternalURL. Mikäli käytössä on vain yksi Site ja ulkoisista yhteyksistä Outlook Anywhere ei ole otettu käyttöön, voi URL-asetukset oikeastaan olla oletusarvoisesti. Asetukset on kuitenkin hyvä laittaa oikein jo alusta lähtien, vaikka kaikkia palveluja ei olisikaan käytössä. Alla olevista taulukoista selviää asetukset. Kuten edellä mainittu, nimet voidaan määritellä, miten vain halutaan ja jokaisella palvelulla voi olla vaikka oma nimensä. Tässä esimerkissä on tarkoituksella käytetty muuttujaa ”WS_Array”, joka viittaa nimenomaan http-pohjaisiin palveluihin, eikä CAS Array-objektiin.

Virtual Directory	InternalURL (Internet facing site)
OWA	https://WS_Array.domain.com/OWA
ECP	https://WS_Array.domain.com/ECP
EWS	https://WS_Array.domain.com/EWS/Exchange.asmx
ActiveSync	https://WS_Array.domain.com/Microsoft-Server-ActiveSync
OAB	https://WS_Array.domain.com/OAB
Autodiscover	https://WS_Array.domain.com/Autodiscover/Autodiscover.xml

Virtual Directory	ExternalURL (Internet facing site)
OWA	https://MAIL.domain.com/OWA
ECP	https://MAIL.domain.com/ECP
EWS	https://MAIL.domain.com/EWS/Exchange.asmx
ActiveSync	https://MAIL.domain.com/Microsoft-Server-ActiveSync
OAB	https://MAIL.domain.com/OAB
Autodiscover	https://MAIL.domain.com/Autodiscover/Autodiscover.xml

SSL Offloading-asetukset

SSL-suojauksen purku on olennainen osa sovellustason kuormantasauksessa, kuten aiemmissa artikkeleissa on tullut jo ilmi. Asetukset tehdään seuraavasti:

Outlook Web Access