Olen työskennellyt yritysverkkojen parissa pitkään, ja viime vuosina yksi ristiriita on tullut yhä selvemmäksi: WAN-teknologia on kehittynyt paljon nopeammin kuin tapa, jolla operaattoripalveluita ostetaan, mitataan ja suojataan SLA:lla. Onko perinteisen WAN SLA:n aika ohi? Private WAN (MPLS)-aikana malli oli suhteellisen selkeä. Yritys osti operaattorilta private WANin, määritteli kapasiteetit, rakensi tarvittaessa kahdennukset ja sopi esimerkiksi 99,9 % tai 99,99 % availability-SLA:n sekä vikojen korjausajat. Taustalla eli samalla on vahva oletus ja uskomus: ”Private MPLS on laadukkaampi kuin Internet”.

WAN SLA ei  todista oletettua laatueron väitettä

Oletukselle oli teknisiä perusteita. Operaattori hallitsi runkoverkkoa, kapasiteettia, reititystä ja liikenneluokkia. Internet taas oli best effort -verkko, jonka päästä päähän -laatua kukaan yksittäinen toimija ei kontrolloinut. Mutta asiakkaan näkökulmasta tässä oli aina yksi ongelma: SLA ei  todistanut oletettua laatueron väitettä.

Tyypillinen SLA kertoi ensinnäkin, oliko yhteys käytettävissä ja kuinka nopeasti se korjattiin. Packet loss, jitter ja latency eivät yleensä olleet samalla tavalla asiakkaan todellisen päästä päähän -palvelupolun laatutakuita.

Saatavuus (availability) ei ole sama asia kuin laatu.  99,99 %:n availability voi silti tarkoittaa huonoa WAN-yhteyttä. Yhteys voi olla ”vihreä” (up), mutta silti käytännössä huono. Ethernet toimii. IP toimii. BGP toimii. Operaattorin valvonta näyttää vihreää, MUTTA samaan aikaan packet loss voi olla useita prosentteja, jitter suuri tai liikenne ruuhkautunut. Teams-puhelu pätkii, SaaS-palvelu hidastuu ja käyttäjä kokee yhteyden epävakaaksi. Operaattorin raportissa availability voi silti olla käytännössä 100 %. Tällaisessa tapauksessa on turha kysyä ”onko perinteisen WAN SLA:n aika ohi?”

Vanha vs moderni WAN

Tästä syntyy mielestäni yksi keskeinen ero vanhan ja modernin WAN-ajattelun välillä. Availability kertoo, kuinka paljon yhteys oli poikki. Se ei kerro, kuinka paljon aikaa yhteyttä ei olisi pitänyt käyttää laadusta johtuen. Moderni WAN pystyy näkemään tämän eron.

Entä jos BGP (reititys) on down, mutta circuit on up? Jo yksinkertainen reititysvika osoittaa availability-ajattelun ongelman. Fyysinen kuituyhteys voi olla kunnossa. Operaattorin access-palvelu on ylhäällä. Ethernet toimii. Mutta BGP-sessio katoaa, ja sen mukana katoavat tarvittavat reitit. Onko palvelu silloin käytettävissä? Operaattorin access circuit voi edelleen olla up. Asiakkaan näkökulmasta yhteydellä ei välttämättä ole mitään käyttöarvoa.

Mitä availability siis oikeastaan mittaa?

Fyysistä linkkiä? CPE:tä? BGP-session tilaa? IP-reititettävyyttä? Vai sitä, pystyykö käyttäjä käyttämään liiketoimintasovellustaan? Mitä lähemmäs viimeistä kysymystä mennään, sitä heikommin SLA-sopimuksen yksi availability-prosentti kuvaa todellisuutta.

Moderni WAN muuttaa kysymyksen

Modernin WANin keskeisin uudistus ei mielestäni ole AI. Paljon perustavanlaatuisempi muutos on siirtyminen ”availability-based networking –> quality-based networking” ajatteluun. Nykyinen WAN pystyy seuraamaan eri polkujen pakettikatoa, viivettä, jitteriä ja saavutettavuutta jatkuvasti. Jos polku ei enää täytä liikenteelle (sovellukselle) asetettuja vaatimuksia, sitä ei tarvitse käyttää. Liikenne voidaan siirtää toiselle Internet-yhteydelle, mobiiliyhteydelle tai esimerkiksi satelliittiin.

Verkon ei siis tarvitse ensin todeta ”Yhteys kuoli” , vaan älykäs verkko voi todeta ”Yhteys on edelleen olemassa, mutta se ei ole riittävän hyvä käytettäväksi.” Tämä on paljon suurempi muutos kuin pelkkä uuden reitittimen hankinta.

MPLS:n laatulupaus muuttuu oletuksesta mitattavaksi väitteeksi

MPLS:n paremmasta laadusta puhuttiin vuosia lähes itsestäänselvyytenä. Silti jo Skype osoitti noin 20 vuotta sitten jotain kiinnostavaa: reaaliaikainen puhe pystyi toimimaan best effort -Internetin yli Suomesta Yhdysvaltoihin ilman päästä päähän tarjottua operaattori-QoS:ää. Internet ei ollut täydellinen. Sovellus oppii elämään vain epätäydellisessä verkossa. Codecit, jitter bufferit, packet-loss concealment ja muu sovellustason logiikka tekivät sen mahdolliseksi.

Moderni WAN vie saman ajatuksen verkon tasolle. Se hyväksyy lähtökohdaksi, etteivät kaikki polut ole koko ajan täydellisiä, mittaa niiden laatua ja valitsee käyttökelpoisimman. Tämän vuoksi vanha jako Private = laadukas ja Internet = best effort ja epäluotettava on nykyään liian karkea. Moderni WAN pystyy testaamaan väitteen.

Entä MPLS:n oletettu latency-etu? Tätäkin on nykyään mahdollista mitata eikä vain olettaa. Omissa käytännön mittauksissamme Suomen sisällä toimipiste-Data Center -polun ja suoremman polun latenssin ero on ollut vain noin 2 ms. Se on kiinnostava havainto. Mitä merkittävää latency-etua private WAN (MPLS) enää voisi tarjota? Valokuidun etenemisviive asettaa joka tapauksessa fyysisen alarajan, ja se on jo lähellä teoreettista maksimia.

Paljon kiinnostavampia kysymyksiä ovat

  • Esiintyykö packet lossia?
  • Kuinka paljon latency vaihtelee?
  • Kuinka suuri jitter on?
  • Kuinka usein polun laatu on ollut alitettu hyväksyttävän tason?
  • Kuinka nopeasti WAN reagoi siihen?
  • Näkyykö häiriö lopulta käyttäjälle?

Modernissa WAN-arkkitehtuurissa vaikutusta ei tarvitse arvailla. Se voidaan mitata ja se tapahtuu jatkuvasti ja automaattisesti.

SaaS rikkoi vanhan palvelurajan

Vanhassa Private WAN (MPLS) maailmassa tilanne oli helpompi, jos operaattori yhdisti toimiston yrityksen omaan konesaliin. Nyt liikennepolku näyttää usein tältä: Office → ISP access → ISP core → Internet egress → peering/transit → SaaS provider → application

Jos käyttäjä näkee packet lossia Microsoft 365:n, Salesforce- tai ServiceNow-palveluiden, SAP-pilvipalveluiden tai Azure-, AWS- ja Google Cloud -ympäristöissä toimivien sovellusten suuntaan, missä vika oikeastaan on?

Olemme käytännössä törmänneet tilanteeseen, jossa tietyn globaalin pilvipalvelun suuntaan hävisi runsaasti paketteja, vaikka operaattorin liittymä ja runkoverkko näyttivät normaaleilta. Tästä syntyi erittäin yksinkertaiselta kuulostava kysymys:

Voimmeko sopia operaattorin kanssa mittauspisteestä (packet loss, jitter, latency), johon asti voidaan todeta, että operaattorin palvelu toimii sovitulla laadulla? – Voimmeko yhdessä sopia, milloin laatu ei ole riittävää kriittisille sovelluksille?

Käytännössä tämä on yllättävän vaikea kysymys suurimmalle osalle operaattoreista. Jos mittauspiste sijaitsee operaattorin omassa coren sisällä, voidaan todistaa lähinnä, että operaattorin core toimii. (Sekin tosin on jo parannus.) Jos taas mitataan suoraan SaaS-palveluun, saadaan hyvä kuva käyttäjäkokemuksesta, mutta ei enää voida automaattisesti sanoa, että mahdollinen ongelma kuuluu ISP:lle. Oleellista asiakkaana on kuitenkin varmistaa, että edes yhden ISP:n sisäinen verkko ja sen reititys ovat kunnossa.

Internetissä tekninen palvelupolku ja kaupallinen vastuuraja eivät enää osu nätisti yhteen, joten kannattaa mitata useita palvelurajoja. Modernissa WANissa voisi siksi olla järkevää tarkastella ainakin kolmea tasoa:

  1. Customer edge → ISP network
  2. Customer edge → ISP Internet egress
  3. Customer edge → SaaS service

Ensimmäinen kertoo access-palvelusta. Toinen kertoo enemmän operaattorin runkoverkosta ja Internet-ulostulosta. Kolmas kertoo lopulta, mistä liiketoiminta välittää. Täydellistä juridista vastuunjakoa tällä ei ratkaista, mutta vian sijaintia voidaan rajata nykyistä paljon paremmin. Modernin WANin näkökulmasta kaikkein tärkeintä ei edes ensimmäiseksi ole tietää, kuka on syyllinen. Ensimmäinen tehtävä on löytää toimivin ja paras polku.

Yksi operaattori vai monta?

Perinteinen malli on pyrkiä ostamaan mahdollisimman suuri osa verkosta yhdeltä operaattorilta. Esimerkiksi eurooppalainen yritys voi yrittää pitää accessit ja runkoverkon yhden operaattorin hallussa. Etuna on yksi vastuutaho ja mahdollisuus hallita suurempaa osaa kokonaisreitistä.

Vaihtoehtona on ostaa eri toimipisteisiin useita Internet-yhteyksiä eri operaattoreilta ja antaa modernin WANin arvioida niiden laatua jatkuvasti. Tässä jälkimmäisessä mallissa tapahtuu jotain olennaista. Operaattorin laatua ei enää tarvitse olettaa. Sitä voidaan mitata. Jos ISP A:n kautta tiettyyn SaaS-palveluun esiintyy packet lossia ja ISP B:n kautta ei, WAN voi käyttää B:tä. Kun mittaustietoa kertyy kuukausien ajan, voidaan nähdä:

  • Kuinka usein yhteys oli kokonaan poissa käytöstä?
  • Kuinka usein se oli up mutta laadullisesti huono?
  • Mihin kohteisiin ongelmat liittyivät?
  • Kuinka usein liikenne jouduttiin siirtämään pois operaattorin polulta?
  • Esiintyivätkö eri ISP:iden ongelmat samaan aikaan?
  • Kuinka usein käyttäjä lopulta huomasi mitään?

Tämä voi olla paljon arvokkaampaa tietoa kuin vuosittainen raportti, jossa lukee 99,99 % availability. Silti kaksi ISP:tä ei välttämättä tarkoita kahta riippumatonta polkua. Kahden operaattorilogon taustalla voi silti olla sama:

  • katuun kaivettu kuitureitti
  • kaapelikanava
  • paikallinen wholesale-operaattori
  • runkoverkon solmu
  • transit-toimittaja
  • Internet Exchange tai peering-riippuvuus.

Todellinen tavoite ei siis ole kaksi eri ISP, vaan independent failure domains. Modernin WANin mittausdata voi myös auttaa paljastamaan, kuinka riippumattomia polut todella ovat. Jos kaksi näennäisesti erillistä yhteyttä kärsivät jatkuvasti samoista ongelmista täsmälleen samaan aikaan ja samoihin kohteisiin, kannattaa kysyä, kuinka erillisiä ne todellisuudessa ovat. Itämeren kaapelivaurioissa tämä konkretisoitui.

Satelliitti tuo aidosti erilaisen failure domainin

LEO-satelliitti tekee redundanssista vielä kiinnostavamman. Satelliitti ei ole vain “kolmas ISP”. Paikallisen access-verkon näkökulmasta se voi muodostaa täysin erilaisen failure domainin. Kuitukatko, katujakamon vika tai paikallisen teleoperaattorin access-häiriö eivät samalla tavalla vaikuta satelliittiyhteyteen. Satelliittipalvelulla on toki omat maa-asemansa, runkoverkkonsa ja riippuvuutensa internetistä. Täydellistä end-to-end-riippumattomuutta ei ole.

Mutta toimipisteen viimeisen kilometrin sekä core-verkon operoinnin näkökulmasta ero on merkittävä. Moderni WAN voi siis yhdistää esimerkiksi: kuitu ISP A + kuitu ISP B + 5G + LEO-satelliitti ja valita transportin toteutuneen laadun perusteella. Tällöin kysymys ei enää ole siitä, kuinka täydellinen yksittäinen yhteys on, vaan siitä, kuinka todennäköisesti kaikki riippumattomat polut epäonnistuvat samanaikaisesti.

Hallittu backbone on kolmas vaihtoehto

SASE-ratkaisu, jolla on oma tai hallittu globaali backbone, tuo kokonaisuuteen vielä yhden vaihtoehdon. Ero ei ole ”last mile” vaan ”middle mile”. Arkkitehtuuri voi näyttää tältä: Site → local ISP → lähin PoP → hallittu Backbone → egress lähellä SaaSia”. Tällöin last mile on edelleen paikallisen ISP:n vastuulla, mutta suuri osa pitkästä Internet-polusta siirtyy yhden toimijan hallintaan. Tämä muistuttaa tietyllä tavalla vanhaa private WAN -ajatusta: pyritään saamaan mahdollisimman suuri osa polusta yhden toimijan kontrolliin.

Nykyään haastetta ei enää ole pakko ratkaista ideologisesti. Ratkaisujen todellista laatua voidaan vertailla datalla, jossa yksittäisen kalliin yhteyden kova SLA ei ole enää tärkein tekijä.

Tässä päästään mielestäni koko aiheen kiinnostavimpaan kysymykseen. Perinteisen WANin ajatus oli, että yhteyden pitää olla erittäin luotettava, koska kun se vikaantuu, käyttäjän palvelu katkeaa. Moderni WAN voi rikkoa tämän oletuksen.

Kun ensisijaisen polun laatu heikkenee, liikenne siirtyy nopeasti toiseen polkuun. Toteutuksesta riippuen olemassa olevia sessioita voidaan säilyttää niin, ettei käyttäjä välttämättä huomaa tapahtumaa. Joissakin käyttötapauksissa kriittistä liikennettä voidaan suojata myös lähettämällä sama data useampaa polkua pitkin ja poistamalla ylimääräinen data vastaanottavassa päässä.

  • Vanha ajatus: Tee yksittäisestä yhteydestä mahdollisimman luotettava
  • Moderni ajatus: Oleta, että yksittäiset yhteydet joskus epäonnistuvat, ja varmista, ettei käyttäjä huomaa sitä

Jos tämä onnistuu, joudutaan kysymään, kannattaako erittäin kovasta yksittäisen circuitin SLA:sta aina maksaa paljon? Joissakin ympäristöissä varmasti kannattaa. Toisissa tapauksissa voi olla taloudellisesti järkevämpää sijoittaa kahteen tai kolmeen aidosti riippumattomaan transporttiin kuin yrittää tehdä yhdestä yhteydestä lähes täydellisen.

SLA ei silti katoa

Jos ensisijainen yhteys rikkoutuu eikä sitä korjata viikkoon, yritys toimii pitkään ilman redundanssia. Siksi erityisesti korjausaika säilyy tärkeänä, mutta SLA:n rooli voi muuttua. SLA ei välttämättä enää takaa käyttäjän palvelun jatkuvuutta.WAN-arkkitehtuuri tekee sen. SLA kertoo enemmän yksittäisen underlay-palvelun laadusta, vastuusta ja siitä, kuinka nopeasti toimittajan on palautettava redundanssi.

Tässä myös nykyinen tikettikäytäntö alkaa näyttää vanhentuneelta. Moderni WAN voi todeta esimerkiksi:

  • 10:03:17 – packet loss ylittää hyväksytyn rajan
  • 10:03:18 – polku poistetaan käytöstä
  • 10:03:19 – liikenne jatkuu toisella polulla

Operaattorin SLA-kello voi silti alkaa vasta: 10:47 kun asiakas avasi vikatiketin. Tiketti on kuitenkin hallinnollinen tapahtuma. Se ei ole verkon laadun vikaantumishetki. Jos laatuhäiriö pystytään todentamaan ennalta sovitulla mittarilla ja aikaleimatulla telemetrialla, olisi luontevaa, että ainakin tulevaisuudessa myös SLA voisi käyttää samaa tietoa.

Ehkä tarvitsemme kolme eri mittaria. Itse erottaisin ainakin kolme tasoa.

  • Circuit availability – Kuinka suuren osan ajasta yksittäinen yhteys oli teknisesti up?
  • Quality-qualified availability-  Kuinka suuren osan ajasta kyseinen polku täytti määritellyt packet loss-, latency- ja jitter-kriteerit niin hyvin, että WAN oli valmis käyttämään sitä?
  • End-user service availability – Kuinka suuren osan ajasta käyttäjän palvelu todella toimi?

Onko SLA lopulta laadun tae

Ei automaattisesti. SLA takaa sen, mitä sopimukseen on määritelty, niissä mittauspisteissä, sillä laskentatavalla ja niillä raja-arvoilla, jotka on sovittu. 99,99 % availability ei tarkoita 99,99 % laadukasta WAN-palvelua. Se, mitä voi tarkoittaa, on vain se, että yhteyttä ei sopimuksen määritelmän mukaan ole laskettu kovin usein kokonaan poikki luokkaan.

Moderni WAN tekee tämän eron selväksi ja tässä on ehkä koko asian tärkein muutos. MPLS-aikana verkon laatua ostettiin osittain lupauksena ja arkkitehtuurina. Modernissa WANissa sitä voidaan mitata jatkuvasti polkukohtaisesti. Silloin myös operaattorin 99,99 % availability-SLA:n merkitys muuttuu. Tärkein kysymys ei enää ehkä ole, kuinka monta ysiä tämän circuitin SLA:ssa on, vaan se, mitä käyttäjälle tai OT-prosessille tapahtuu, kun tämä polku muuttuu huonoksi tai katoaa kokonaan? Jos vastaus on ”ei juuri mitään”, olemme jo aika kaukana siitä maailmasta, jota varten perinteinen WAN-SLA aikanaan rakennettiin.

 

Hannu Rokka, Senior Advisor

5Feet Networks Oy