Routing Topology
HLB liitetään verkkoon yksi- tai kaksikätisesti, riippuen verkkotopologiasta ja tarpeista sekä HLB:n ominaisuuksista. HLB toimii verkossa viime kädessä liikenteen reitittäjänä, minkä takia asiayhteydessä puhutaan reitityksestä.Reititystekniikoita on muutama ja niillä saattaa olla useita eri nimityksiä, riippuen toteuttajasta. Tiivistäen niitä ovat Direct Routing, SNAT sekä Bridging. Kuten edellä mainittu, termit menevät tässäkin yhteydessä sekaisin. Cisco käyttää nimitystä Routed Mode, vaikka sillä tarkoitetaan SNAT:ia. SNAT:ia saatetaan käyttää NATin yhteydessä, kun todelliselle palvelimille määritellään Masquerade-sääntö. Citrix käyttää SNAT:sta nimitystä USNIP Mode (Use Subnet IP).
(1) Direct Server Routing Mode
Suoraa reititystä kutsutaan nimillä Direct Routing, Direct Server Routing, Direct Server Return ja nPath. Perusidea on se, että HLB on yhdellä verkkoliitynnällä samassa aliverkossa kuin todelliset palvelimet. HLB:lle määritellään VIP ja tämä sama IP-osoite määritellään Windows-palvelimien Loopback Adapterin osoitteeksi.Asenna adapteri kännistämällä hdwwiz-ohjelma. Valitse listasta Microsoft Loopback Adapter. Verkkoliitynnän ominaisuuksista otetaan kaikki muut ominaisuudet pois paitsi TCP/IPv4-osoite. Osoite tulee olla ns. Host-maskilla eli muotoa 10.0.1.100/32. Windows-palvelimien VIP-osoitteet eivät saa vastata ARP-kyselyihin, vaan HLB.
Asiakas ottaa yhteyden HLB:iin, jossa muutetaan kohteen kehyksen MAC-osoite todellisen palvelimen MAC-osoitteeksi. Palvelin vastaa suoraan asiakkaalle paluureitin kautta. IP-pakettien (datagrammi) eheys kuitenkin säilyy, koska alkuperäinen pyyntö kohdistettiin osoitteeseen 10.0.1.100, josta paluupaketit myös tulevat. DRS on ratkaisuna paras suorituskyvyn kannalta. Sovelluskohteita voivat olla esim. palvelut, josta streamataan paljon mediaa. On hyvä huomioida, että ratkaisulla pystytään tekemään ainoastaan Layer 4-tason kuormantasausta. Lisäksi palvelimiin pitää tehdä muutoksia (asentaa Loopback Adapter). Microsoft ei suosittele DRS:n käyttöä Exchangen kanssa.
(2) SNAT Mode
SNAT:lla on useita nimityksiä: Source NAT, Secure NAT ja Stateful NAT. SNAT mahdollistaa useamman sisäisen osoitteen käyttämistä yhden julkisen osoitteen takana. Perusperiaate on, että sekä lähde- että kohdeosoite muutetaan HLB:n toimesta. Asiakas ottaa yhteyttä palvelun virtuaaliosoitteeseen 192.168.5.100. Tämän jälkeen lähdeosoite 192.168.1.123 korvataan HLB:n Server Side-puolen IP-osoitteella (NAT Pool) ja kohdeosoitteeksi määritellään todellinen palvelin. Paluureitityksen yhteydessä osoitteen muutokset tehdään käänteisesti takaisin alkuperäisiksi.
SNAT mahdollistaa todellisten palvelinten liikennöinnin ulkoverkkoon Server Side-osoitteen avulla. Exchangen yhteydessä NAT-poolissa ei voi olla kuin yksi osoite, sillä MAPI RPC edellyttää, että jokaista asiakkaan palvelupyyntöä vasten pitää olla yksi lähdeosoite. Mikäli HLB tukee, voidaan SNAT-poolia käyttää sillä edellytyksellä, että HLB pystyy pitämään yhteyden samalla lähdeosoitteella. Microsoft suosittelee SNAT:n käyttämistä Exchange 2010:n yhteydessä.
Mainittakoon NAT-pohjaisesta reitityksestä, että siinä on myös toteutuseroja valmistajien kesken. Esim. F5:n mukaan NAT on aina One to One-tyyppinen yhteys, eli yhtä julkista osoitetta vastaa vain yksi sisäinen osoite. Tällöin varsinaista kuormanjakoa ei edes tapahdu, joka ei ole luonnollisesti toivottu tilanne.
SNAT on mahdollista toteuttaa myös yksikätisenä (One Armed), jolloin virtuaalipalvelimet kuuluvat samaan aliverkkoon kuin todelliset palvelimet. Tämä malli ei vaadi verkkoon mitään muutoksia ja on sen takia helpoin toteuttaa, mutta samalla se on myös rajoittunut verkkojen suhteen, joten vähänkin suurempiin toteutuksiin, se ei ole varteenotettava vaihtoehto.
(3) Bridged Mode
Bridged Mode muodostaa sillatun (L2) yhteyden kahden eri VLANin välillä, jotka kuuluvat samaan IP-aliverkoon. Reititys tapahtuu varsinaisella reitittimellä eli HLB:llä. HLB:lle määritellään niin kuin SNAT:n yhteydessä sekä Client Side VLAN että Server Side VLAN. Näiden välille määritellään Bridged Group Virtual Interface (osoite samasta aliverkosta), joka yhdistää kaksi eri VLAN:ia yhdeksi Bridge Group-ryhmäksi. Nämä termit ovat Ciscon terminologiasta. Citrix käyttää puolestaan Bridged Modesta nimitystä Transparent Mode.Layer 4 ja layer 7, Transparent
Layer 4-tason kuormanjako perustuu ainoastaan IP-osoitteeseen ja porttiin. Eli liikennettä ohjataan eteenpäin tasapuolisesti todellisille palvelimille ottamatta kantaa itse sisältöön. Perusperiaate on yksinkertainen, mutta siinä ei ole juurikaan älykkyyttä. Perusongelmana on se, että tässä mallissa edellytetään, että kaikki todelliset palvelimet ovat samanlaisia ja niillä ajetaan samoja palveluja. Näin ei aina todellisuudessa ole, eikä kannatakaan olla. Osa palvelimista saattaa sisältää suuria määriä staattista tietoa esim. kuvia tai videoita, kun taas toiset palvelimet keskittyvät asiakkaiden transaktioiden (http) käsittelyyn. Tässä vaiheessa Layer 7-tason kuormantasaus astuu kuvioon, jolloin sovellustasolla pystytään päättelemään, minkälaisia pyyntöjä asiakkailta tulee ja mihin ne kannattaa ohjata. Myös palvelutason perusteella voidaan tehdä kuormantasausta, jolloin erityisasiakkaille voidaan esim. tarjota aina tehopalvelimia käyttöön.URL Parsing on yksi tekniikka Layer 7-tason kuormanjaossa. Tiettyyn virtuaalihakemistoon tehty palvelupyyntö voidaan ohjata halutuille palvelimille. Esimerkkinä vaikka seuraava: pyyntö www.domain.com ohjataan peruspalvelimille kun taas www.domain.com/premiumusers ohjataan tehopalvelimille. Jos asiakaspalvelu on erityisen tärkeää, voidaan samaa periaatetta toteuttaa osoitteeseen www.domain.com/service. Myös päätteen (*.png, *.gif, jne) perusteella voidaan ohjata pyynnöt oikeille palvelimille.
GET /pictures/logo.png HTTP/1.1
HTTP Header interrogation-tekniikkaa voidaan hyödyntää, kun halutaan tunnisteiden perusteella tehdä ohjauspyyntöjä. Hyviä esimerkkejä ovat ”Accept-Language: Header”-otsikko, jolloin kielen perusteella voidaan tehdä ohjaus lähimpänä oleviin palvelimiin tai ”User-Agent: Header”-otsikko, jolloin tunnistetaan selainversio ja sille tarkoitettu käyttöliittymä.
Evästeet (Cookie) on yksi Header-otsikkotietojen erityistapaus ja niitä käytetään hyvin paljon. Evästeen idea on tallentaa tietoa sessiosta asiakkaan päähän, jolloin seuraavalla kerralla tai pyynnöllä sitä voidaan hyödyntää, riippuen evästeen voimassaoloajasta. Evästeen avulla voidaan käyttäjä ohjata samalle palvelimelle uudestaan jatkossakin, jolloin esim. ostoskorin sisältö näkyy seuraavalla kerralla. Eväste voi olla voimassa esim. tietoturvasyistä vain yhden session ajan, jolloin sen aikana tehdyt pyynnöt ohjataan aina samalle palvelimelle. Session jälkeen eväste tuhotaan. Uusi sessio luo taas uuden evästeen.
Layer 7-tason kuormantasausta kutsutaan myös toisinaan nimellä Content Switching. Nimitys on tosin ehkä vähän vanhahtava.
Arkaluontoinen tieto salataan usein SSL-varmenteilla. Jotta Layer 7-tason kuormanjako olisi mahdollista, tulee suojaus purkaa HLB:n toimesta (SSL Offloading). Muuten istunnon pysyvyys (Persistence) voidaan määritellä ainoastaan lähdeosoitteen perusteella. Suojauksen purkamisella päästään sovellustason liikenteeseen (Payload) käsiksi ja tekemään tarvittavat ohjaukset sisällön perusteella. Sisältö voidaan salata uudelleen esim. tietoturvan takia, mikäli liikenne kulkee sellaisessa verkkosegmentissa, että se koetaan uhkana. Suorituskyvyn näkökulmasta uudelleensalaus kannattaa ottaa pois päältä.
Layer 7-tason kuormantasaus ei ole mahdollista toteuttaa kaikissa reititystopologioissa. Perusvaatimuksena on, että HLB on välissä kumpaankin suuntaan asiakkaan ja serverin välisessä yhteydessä (SNAT). Tässä tapauksessa HLB ei ole läpinäkyvä ns. Transparent, koska todellinen palvelin näkee ainoastaan HLB:n asiakkaana, eli alkuperäinen asiakas pysyy piilossa todelliselta palvelimelta. Tätä asetelmaa kutsutaan myös nimellä Full Proxy. Useimmat ratkaisut mahdollistavat alkuperäisen asiakkaan tiedon välittämistä todelliselle palvelimelle. Tällöin HLB:n pitää pystyä välittämään X-Forwarded-For-otsikkotieto todelliselle palvelimelle. IIS:n lokissa se näkyy c-ip-kentässä oikealla ISAPI-suodatuksella.
Valmistajia
Sovellustason Load Balancerin valmistajia on useita. Johtavia (Gartnerin mukaan) valmistajia ovat F5 ja Citrix. Muita ovat Cisco, Radware, A10, Barracuda Networks, Zeus Technology, Brocade jne. Sitten löytyy ratkaisuja, jotka eivät ole aidosti sovellustasolla toimivia. Esimerkkinä tästä on MSExchange.org-sivustollakin paljon esitelty Kemp Technologiesin Load Master-tuotteet. Deployment Guidessa (versio 5.1) ei ole oikeastaan mainintaa mistään L7-tason Persistence-asetuksista. Siellä puhutaan SuperHTTP:stä, josta ei ole mitään kuvausta, mitä se tekee. Ja vielä lainaus ”For Persistence Options, select a Layer 7 organic persistence method as the Mode”. Mikä on “organic persistence method”? Load Masterit ajavat varmasti oman asiansa, kunhan tiedostaa niiden puutteet.Tämä riittää johdatukseksi varsinaiseen asiaan eli Exchange ja Load Balancing. Siitä seuraavassa osassa.
Ei kommentteja:
Lähetä kommentti