Exchange 2010 ja Load Balancing, Osa 1

Johdanto

Load Balancing-tekniikka on tullut tutuksi viime aikoina Exchange-asiantuntijoille. Korkean käytettävyyden ratkaisut edellyttävät Client Access Server-roolin osalta jonkin tasoisen kuormantasausratkaisun. Perinteisellä Windowsin omalla NLB-tekniikalla on omat rajoitteensa ja Microsoft suositteleekin tätä nykyä erillistä Load Balancing-ratkaisua Exchange-toteutuksiin. CAS-roolin arkkitehtuurimuutokset on hyvin kuvattu Exchangen Technet-dokumentaatiossa. Niistä ilmenee hyvin, miksi kuormantasaus on välttämätön korkean käytettävyyden ratkaisuissa. Itse Load Balancing-asioista ei ole kovin monta montaa artikkelia Microsoftin toimesta julkaistu. Technetistä niitä löytyy tasan kaksi. Syykin on toisaalta melko luonnollinen, sillä Load Balancing-ratkaisujen toteutukset ovat kolmannen osapuolen tuotteita ja niihin löytyvä dokumentaatio on valmistajakohtaista. Valmistajat saattavat käyttää tuotteistaan nimitystä ”Exchange 2010-yhteensopiva”. Microsoft käsittelee asiaa Exchange-järjestelmän näkökulmasta ja antaa yleisiä suosituksia asioiden toteuttamiselle. Tarkempi perehtyminen yhtäältä Microsoftin dokumentaatioon ja toisaalta valmistajakohtaisiin dokumentaatioihin, tuo esiin sen, että nimityksellä ”Exchange 2010-yhteensopiva” saattaa olla väljempi merkitys.



Tuotteilla on siis eroja ja niistä on hyvä olla Exchange-asiantuntijankin tietoinen. Tämä siinäkin tapauksessa, että organisaatiolla on jo jokin ratkaisu käytössä tai sellaista ollaan hankkimassa. Harmittava tilanne syntyy silloin, jos jo hankittu Load-Balancing-ratkaisu ei täytä esim. Exchangen osalta liiketoimintavaatimuksia.

Terminologia

Eräs asia, joka hämmentää asiaa, on aiheeseen liittyvä kirjava terminologia. Periaatteet ovat kaikilla samat, mutta sanasto eroaa valmistajittain. Itse Load Balancerista jo käytetään eri nimityksiä, kuten esim. Application Delivery Controller (F5, Citrix) tai Application Control Engine (Cisco). Nimet viittaavat siihen, että laitteilla on sovellustason älyä.

Osaan laitteista voidaan määritellä virtuaalisia Load Balancereita, jolloin niistä käytetään esim. nimitystä Virtual Context (Cisco). Tämä ominaisuus erittäin hyvä, jos halutaan eristää järjestelmiä toisistaan tai palvelua tarjotaan moniasiakasympäristöön. Tällöin Virtual Contextit ovat toisistaan riippumattomia: niillä on omat verkkonsa, asetuksena ja hallintansa.

Yhtenä peruskomponenttina Load Balancerissa on rakentaa palvelu, joka ottaa vastaan sille osoitettuja palvelupyyntöjä. Tätä kutsutaan nimellä Virtual Server tai Virtual Service. Palvelulla on IP-osoite, portti ja DNS-nimi. Palvelun IP-osoitetta kutsutaan nimellä VIP (Virtual IP), mutta laitteella on myös todellinen IP-osoite (RIP, Real IP), joka on tarkoitettu esim. hallintaa varten. Kun Load Balancer ottaa vastaan palvelupyynnön ohjataan se jollekin todelliselle palvelimelle. Tästä käytetään nimitystä Real Server, Host, Node, Server. F5 haluaa tehdä eron Serverin ja Servicen välille, Server tarkoittaa palvelinta, jolla on IP-osoite, mutta Service on palvelu, jolla on myös portti ja DNS-tietue. Todellisten palvelimien muodostamaa joukkoa kutsutaan nimellä Farm, Cluster, Pool, Back End. Todellisilla palvelimilla ajettavaa palvelua kutsutaan Serviceksi. Toisinaan Web-pohjaisia palveluja suojataan SSL-varmenteilla. Load Balancerilla tämä salaus yleensä puretaan ja lähetetään eteenpäin todellisille palvelimille suojaamattomana. Tätä kutsutaan nimellä SSL Offloading.

Perus toimintaperiaate

Hardware Load Balancer on laite, joka toimii asiakkaan ja palvelimen välissä eräänlaisen Proxyna. Se ottaa vastaan sille osoitettuja palvelupyyntöjä ja ohjaa liikenteen takana oleville todellisille palvelimille. Palvelimilla olevien palvelujen tilaa tarkkaillaan. Mikäli jonkin palvelimen palvelu ei ole saatavilla, ei sinne yritetä tarjota uusia yhteyksiä. Load Balancer pitää myös huolta siitä, että session aikana tehdyt palvelupyynnöt ohjataan aina samalle palvelimelle. HLB:n ominaisuuksiin kuuluu lisäksi usein myös välimuisti (Cache) esim. OWA-liikenteessä ja pakkaaminen (Compression).

Monitorointi

Yksi tärkeimmistä HLB:n ominaisuuksista on todellisten palvelimien palvelujen tilan valvonta. Käänteisesti voidaan kysyä, mitä hyötyä on Load Balancing-ratkaisusta, joka tarjoaa yhteyksiä palvelimille, joiden palvelu ei saatavilla. Ei kovinkaan paljon. DNS Round Robin on hyvä esimerkki tällaisesta ratkaisusta. Windowsin Network Load Balancing-tekniikka toimii verkkotasolla (L3), jolloin niin kauan kuin palvelin vastaa IP-osoitteseen, tarjotaan sille asiakasyhteyksiä. Tämä tarkoittaa sitä, että jos CAS-palvelimella on WWW-palvelu alhaalla, NLB ei ole mitenkään tietoinen siitä. Kuljetustason (L4) monitorointi huomaa palvelun olevan alhaalla, mutta sekään ei takaa sitä, että sovellus vastaa. Paras tapa valvoa palvelua, on sovellustasolla (L7). Tällöin HLB voi tarkistaa, että esim. Outlook Web App-sovelluksen kirjautumislomake vastaa palvelupyyntöön.

GET /owa/auth/logon.aspx?url=https://mail.domain.com/owa/&reason=0 HTTP/1.1\r\n
User-Agent: Mozilla/4.0\r\nHost: mail.domain.com\r\n\r\n

Mikäli autentikointitapaa muutetaan perustodennukseen (Basic Authentication), tulee monitorointiin määritellä validi käyttäjätunnus ja salasana.

Yleensä näitä eri tason (L3, L4 ja L7) monitorointeja voidaan vielä yhdistää. Eräs näppärä L7-tason monitorointi on tehdä oma Custom-tiedosto, jota seurataan esim.

request method get url /is_alive.html

CAS-palvelimen ylläpitotoimenpiteiden aikana tiedosto voidaan nimetä toiseen muotoon ”not_is_alive.html”, jolloin HLB huomaa automaattisesti, että palvelin on poissa, eikä yritä ohjata palvelupyyntöjä kyseiselle palvelimelle. Huoltotoimenpiteiden jälkeen tiedosto nimetään taas alkuperäiseen muotoon. Näistä on toki hyvä informoida HLB:n ylläpitäjiä.

Monitoroinnista käytetään nimitystä Health Monitoring, Real Server Check tai Health Probe.

Load Balancing-algoritmit

HLB pitää monitoroinnin perusteella listaa saatavilla olevista palvelimista. Palvelupyyntöjen ohjaus todellisille palvelimille perustuu johonkin algoritmiin. Yleisin näistä on Round Robin (Microsoftin suositus Exchange 2010:ssa). HLB jakaa asiakasyhteyksiä tasaisesti vuorotellen listan mukaan.

Server1, Server2, Server3, Server1, Server2, Server3, ...

Round Robinin mukaan yhteyksiä jaetaan tasaisesti kullekin palvelimelle. Tämä ei kuitenkaan pysty tarkistamaan, miten tilanne todellisuudessa on. Palvelinten kuorma saattaa olla hyvinkin eri tasolla, riippuen yhteyden Persistence-asetuksista. Jos esim. kaikki ulkoiset palvelun käyttäjät tulevat NAT:n takaa (esim. TMG/UAG), näkyvät ne HLB:lle yhtenä osoitteena, jolloin kaikki sieltä tulevat yhteyspyynnöt ohjataan yhdelle CAS-palvelimelle. Eri valmistajilla on erilaisia Load Balancing-algoritmeja, joita voidaan käyttää tarpeen mukaan. Näitä ovat esim.

F5: Round Robin, Weighted Round Robin (Ratio), Dynamic Round Robin (Dynamic Ratio), Fastest, Least Connections, Observed ja Predictive

Cisco: Application response, Hash address, Hash content, Hash cookie, Hash header, Hash URL, Least bandwidth, Least connections, Least loaded ja Round-robin

Cisco käyttää algoritmista nimitystä Predictor.

Älykkäimmissä toteutuksissa HLB pystyy dynaamisesti tarkkailemaan palvelimien todellista kuormitusta ja vasteaikaa ja sen perusteella päättämään optimaalisen palvelimen, johon liikenne tulee ohjata.

Pysyvyys

Ennen http-protokollan versiota 1.1, jokaista pyyntöä ja vastausta varten aukaistaan oma yhteys, joka suljetaan vastauksen jälkeen. Tätä kutsutaan nimellä http close mode. Malli nähtiin huonona resurssien kannalta, jolloin versiossa 1.1 päädyttiin pysyvään yhteysmalliin.

Pysyvässä yhteysmallissa saman TCP-session aikana tehdään useita transaktioita (Request-Respond). Näitä pysyviä yhteysmalleja on useita: Keep Alive, Pipelining, Tunnel-like.

Alla esimerkki OWA-liikenteen ensimmäisestä yhteydestä ja sen otsikkotiedoista. Yhteyden pysyvyys ilmoitetaan tiedolla ”Connection: Keep-Alive”.

GET /owa/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: fi-FI
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Accept-Encoding: gzip, deflate
Host: outlook.uc.demo
Connection: Keep-Alive

Keep Alive-mallin mukaan asiakas odottaa vastausta jokaisen pyynnön jälkeen ennen seuraavaa pyyntöä. Asiakkaan pitää kuitenkin tietää Header-tietojen perusteella jokaisen pyynnön sisällön pituus (Content-length), jotta asiakas ei joudu odottamaan loputtomiin. Transaktioiden päätteeksi palvelin katkaisee yhteyden.

Pipelining-malli noudattaa Keep-alive-mallia, mutta pyyntöjä voidaan muodostaa useita peräkkäin ennen palvelimen vastausta. Malli on tehokas suorituskyvyn kannalta, mutta kaikki HTTP-agentit eivät välttämättä pysty tukemaan tätä. Mallin mukaan palvelimen pitää vastata täsmälleen samassa järjestyksessä, kun pyynnöt ovat tulleet.

Tunnel-like-malli toimii siten, että se muodostaa pysyvän yhteyden palvelimelle ensimmäisen pyynnön perusteella. Kaikki seuraavat pyynnöt ohjataan samalle palvelimelle. Yhteys on siis pysyvä sekä asiakkaan että palvelimen päästä. Tämä on oletusarvo esim. HAProxy:ssa.

Joissakin HLB-ratkaisuissa voidaan http-liikenne pakottaa takaisin http close-malliin.

Asiakkaan ja palvelimen välisessä liikenteessä on siis tärkeää, että session aikaiset transaktiot kohdistuvat samalle palvelimelle. Tätä ominaisuutta kutsutaan nimellä Persitence, Stickiness ja Affinity. Exchange 2010:ssa on kolmenlaisia sovelluksia pysyvyyden suhteen:

• Sovellukset, jotka vaativat Persistence-määrityksen.
• Sovellukset, jotka hyötyvät siitä.
• Sovellukset, jotka eivät tarvitse Persistence-määrityksiä ollenkaan.

Yleisin tapa määritellä yhteyden pysyvyys on asiakkaan lähdeosoite (Source IP). Session aikana IP-osoite saattaa vaihtua, jolloin yhteys palvelimelle katkeaa.

Mikäli liikenne on suojattua ja asiakasyhteydet terminoidaan HLB:lle, voidaan käyttää istunnon pysyvyyden varmistamiseksi SSL Session ID-tunnistetta. Tunniste luodaan ennen kuin HLB tekee ohjauksen taustalla olevalle todelliselle palvelimelle. Ongelmana saattaa olla, että asiakas yrittää uudistaa tunnistetta kesken istunnon, jolloin pysyvyys ei tällöin toimi.

Web-pohjaisissa sovelluksissa voidaan hyödyntää helposti evästeitä (Cookie) pysyvyyden varmistamiseksi. Exchange 2010 muodostaa itse evästeitä yhteyden pysyvyyden takaamiseksi. Lisäksi voidaan käyttää HLB:n omia evästeitä, mutta tämä ei ole pakko. Näitä evästeitä on ainakin 15 kpl:

1. UserContext
2. sessionid
3. cadata
4. PBack
5. OutlookSession
6. logondata
7. cookieTest
8. owacsdc
9. ASP.NET_SessionId
10. msExchEcpCanary
11. ecpCookieTest
12. tzid
13. EcpUpdatedUserSettings
14. MstrPgLd1
15. MstrPgLd2

ActiveSync ei voi hyödyntää evästeitä, mutta siinä voidaan käyttää Authorization Header-tietoa pysyvyyden varmistamikseksi.

Useimmat ratkaisut mahdollistavat useamman yhtäaikaisen pysyvyysmäärityksen, jolloin voidaan määritellä ensisijaiseksi vaikka SSL ID, toissijaiseksi Cookie ja kolmanneksi Source IP.