Suomessakin on Exchange 2010 Deploymentit päässeet jo vauhtiin! Useammassakin ympäristössä on myös käytetty vikasietoisuuden toteuttamiseen uutta Database Availability Group -teknologiaa ja sen mukanaan tuomaa mahdollisuutta tietokantojen replikointiin. DAG:n käytön yhteydessä kuitenkin usein unohtuu, että tekniikka sinällään tuo klusteroinnin hyödyt ja vikasietoisuuden käyttöön ainostaan Mailbox-roolin osalta. Eli vaikka nyt onkin mahdollista sijoittaa Hub Transport- ja Client Access -roolitkin DAG:ssa jäsenenä olevalle palvelimelle, kuormanjakoa ja vikasietoisuutta DAG ei näiden roolien osalta tarkoita.
Mikä siis avuksi jos myös CAS-rooli halutaan vikasietoiseksi ja mahdollisesti kuormanjaetuksi? Jos CAS-rooli sijoitetaan DAG:n jäsenpalvelimille, ainoa vaihtoehto on käyttää ulkoista kuormanjakoa (esim. F5 tai vastaavat), johtuen siitä että Windowsin Network Load Balancing -toimintoa (NLB) ei voi ajaa palvelimissa jotka ovat Failover Clusterin jäsenenä (kuten kaikki DAGin jäsenet ovat). Jos CAS-rooli sijoitetaan erillisiin palvelimiin, NLB:tä voidaan käyttää, joskin aina huomioiden sen rajoitukset sovellustason monitoroinnin osalta.
Itse kuormanjaon määrittämisestä NLB:llä on muutamiakin hyviä artikkeleita olemassa (mm. täällä http://www.msexchange.org/articles_tutorials/exchange-server-2007/planning-architecture/uncovering-new-rpc-client-access-service-exchange-2010-part3.html ja erityisesti konfiguraation toteuttamiseen Hyper-V:llä keskittyvä artikkeli täällä http://www.shudnow.net/2008/09/12/exchange-2007-unicast-nlb-issue-on-hyper-v/. Kuormanjaon yhteydessä suosittelen, että Exchangen käyttämät kommunikointiportit RPC Client Access- ja Address Book-palveluiden osalta määritetään kiinteäksi, jotta sinun ei tarvitse kuormanjakaa koko porttialuetta 1024-65535.
Kun kuormanjakoa käytetään MAPI-yhteyksien osalta (Client Access -roolin tasolla), on tärkeää määritellä käyttöön Client Access Array. MAPI-clientit kun ovat oletuksena kiinni aina yhteen nimeen, jota käytetään hyväksi myös MAPI-profiilin osoittamisessa. Jos Client Access Array jätetään konfiguroimatta, kuormanjaosta huolimatta MAPI-clientit osoittavat vain yksittäiseen Client Access -palvelimeen. Tämä johtuu siitä, että profiilin luontivaiheessa MAPI-clientin oletuskohde luetaan käyttäjän postilaatikon sisältämän Mailbox-tietokannan RPCClientAccessServer-attribuutin arvosta. Jos mitään muuta ei sanota, tämän attribuutin arvo on yksittäisen ko. saitista löytyvän CAS-serverin nimi.
Kuva 1: RPCClientAccessServer-määritys Mailbox-tietokannan ominaisuuksissa
Mikä siis avuksi?
Kuormanjaon määrittämisen jälkeen, luo Client Access Array -määritys. Client Access Array on käytännössä nimi, joka tarjoaa MAPI-clienteille yhteyskohteen yksittäisen CAS-palvelimen sijaan ja joka kerää yhteen kaikki tietyssä saitissa olevat CAS-roolin omaavat palvelimet. Luo DNS:ään CAS Arrayn nimeä vastaava nimi, joka osoittaa kuormanjaon VIP-osoitteeseen (Virtual IP Address). HUOM! CAS Array kattaa kaikki yksittäisessä saitissa olevat CAS-palvelimet!
Komentorakenne: NEW-CLIENTACCESSARRAY -FQDN %CAS Arraylle tuleva nimi% -site %saitin nimi%
Kuva 2: Client Access Arrayn määrittäminen
Kuva 3: DNS-rekordin määrittäminen Client Access Arrayn nimelle
Mailbox-tietokantojen tasolla muutetaan sitten vielä RPCClientAccessServer-attribuutin arvo osoittamaan yksittäisen palvelimen sijasta Client Access Arrayn nimeen.
Komento: SET-MAILBOXDATABASE -RpcClientAccessServer %Client Access Arrayn nimi%
Lopputulos Outlook-clientin näkökulmasta katsottuna
Kun Client Access Array on määritetty, Outlook-clientin yhteydet (sekä postilaatikon että osoitekirjan käytön osalta) kohdistuvat Client Access Arrayhin. Huomioi kuitenkin, että Public Folder -yhteydet muodostetaan edelleen suoraan mailbox-roolin omaavaan palvelimeen (mistä johtuen RPC Client Access -palvelua ajetaan CAS-roolin lisäksi myös Mailbox-roolin omaavilla palvelimilla).
Huomioi myös Autodiscoverin tarjoamat parametrit Exchange RPC Server -parametri osoittaa suoraan Client Access Arrayhin.
