Autor: Vedran Vujasinović

Iako su QOS i tehnike upravljanja propusnošću na mrežnom nivou (layer 3) poznate većini mrežnih administratora, rast Web 2.0 i ostalih aplikacija koje koriste web protokole (streaming media, Youtube, Webex, P2P over HTTP, HTTP tunneling, itd.) zahtijeva inteligentno upravljanje propusnošću na razini same aplikacije odnosno sadržaja. Kontrola prema kriterijima dostupnim na mrežnom sloju (npr. TCP port) više nije dovoljna.
Blue Coat i Packeteer rješenja među ostalim nude upravo takvu granularnu kontrolu i upravljanje propusnošću (bandwidth management).

U današnjem svijetu gdje klijenti, serveri i podaci dolaze u različitim oblicima, shvaćanje svih mrežnih konekcija kao jedinstveni tok podataka ne pruža administratorima fleksibilnost kojom bi mogli osigurati da „za posao kritične“ aplikacije rade prema očekivanjima.

Bez upravljanja bandwidthom, administratori su prisiljeni blokirati „bandwidtha-gladne“ aplikacije kao što su streaming i video. Ukoliko se koriste mogućnosti upravljanja bandwidthom na razini sadržaja odnosno aplikacije, može se dozvoliti pristup tim „za posao nebitnim“ aplikacijama, ali na kontrolirani način kako ne bi utjecale na „za posao važne“ aplikacije.

Upravljanje bandwidthom omogućava kontrolu mrežnog toka podataka na način da korisnici, grupe ili aplikacije dobiju potrebne resurse. Kontrolirati bandwidth možemo na sljedeće načine:

• onemogućiti „resursa gladnim aplikacijama“ – kao što su peer-to-peer (P2P) i streaming video – da utječu na druge, važne programe kao što su e-mail i poslovne klijent-server aplikacije
• osigurati kvalitetan rad aplikacijama koje zahtjevaju određenu količinu bandwidtha po sesiji. Takve aplikacije mogu zahtjevati određenu količinu bandwidth-a kako bi iskoristile sve svoje mogućnosti.
• omogućiti administratorima odabir odgovarajuće propusnosti za važne „bandwidtha gladne“ protokole i aplikacije, kao što su HTTP i IM.

Cilj upravljanja bandwidthom putem Blue Coat rješenja je klasificirati, kontrolirati i ako je potrebno ograničavati količinu bandwidtha koju koristi određena klasa mrežnog prometa, a koji teče u smjeru Blue Coat uređaja ili iz njega prema van. Mrežno dijeljenje resursa (ili dijeljenje linka) se izvodi na hijerarhijski način tako da različiti protokoli i/ili klase prometa dijele slobodan bandwidth na kontrolirani način.
Promet će biti razvrstan u nekoliko bandwidth klasa, koje pripadaju hijerarhiji klasa upravljanja bandwidthom. Administrator može podesiti količinu bandwidtha koju može koristiti svaka pojedinačna klasa u hijerarhiji. Također će morati napraviti politiku koristeći VPM (vizualno sučelje za stvaranje politike) kako bi razvrstao promet.

Upravljanje bandwidthom može biti korišteno za kontroliranje većine prometa koji prolazi kroz Blue Coat uređaj. Tipovi prometa na kojima se može provoditi upravljanje bandwidthom su: HTTP/HTTPS, FTP, Streaming, P2P, IM, SOCKS, TCP Tunnel, Bridging.

Klase bandwidtha
Klasa bandwidtha je osnovna jedinica upravljanja bandwidthom koja se koristi za grupiranje prometa u razičite particije za upravljanje. Pruža mogućnost podešavanja garantiranog minimalnog bandwitha, ograničenja maximalnog bandwidtha i prioriteta za određeni tip prometa. Klase bandwidtha mogu biti organizirane u hijerarhiju (stablo) kako bi omogućile dijeljenje bandwidtha među sobom. Dvije klase bandwidtha sa istom roditeljskom klasom mogu dijeliti neiskorišeni bandwidth između sebe. Klase bandwidtha mogu biti stvorene kroz MC (management konzolu) ili korištenjem CLI naredbi.

Povezivanje sa politikom – klasifikacija prometa
Stvaranjem klase bandwidtha nije završen posao upravljanja bandwidthom. Dodatno, ProxySG mora znati koji promet pripada kojoj od mnoštva klasa konfiguriranih na uređaju. Ovo se radi „pisanjem“ politike. 

Koristeći VPM ili direktno pisanjem CPL-a, administrator može klasificirati promet u klase prometa. Okidači politike koji se koriste da izvode ovu klasifikaciju ovise o prirodi bandwidth politike koja se implementira.

a) Okidači politike
Okidače politke dijelimo na:

• Source (izvorišni okidači kao što su IP adresa, korisnik, grupa kojoj korisnik pripada u AD/LDAP...)
• Destination (odredišni okidači kao što su URL, IP adresa ili file extenzija)
• Service(okidači vezani sa detekcijom servisa kao što su protokoli, protokol metode)
• Action (akcija koju provodimo, kada je pravilo pogođeno)

Neki od okidača, povezanih sa upravljanjem bandwidthom navedeni su u sljedećoj tablici.

 b) Predefinirana klasifikacija bazirana na aplikacijama
Na temelju tipa aplikacije (koje se podudaraju sa tipom servisa na Proxy SG-u), promet se automatski klasificira u defaultnu klasu bandwidtha za određeni tip servisa. SG dolazi predkonfiguriran sa kompletom predefiniranih klasa bandwidtha, s po jednom za svki tip servisa. Povezivanje tipa servisa sa klasom bandwidtha može se mijenjati kroz GUI ili CLI.

c) Klasifikacija prema smjeru prometa
Promet za bilo koju aplikaciju može se klasificirati prema smjeru toka podataka.

• client inbound
• client outbound
• server inbound
• server outbound

Za bilo koju aplikaciju može se napisati politika koja će klasificirati svaki od gore navedenih smjerova u zasebnu klasu bandwidtha. Za predefinirane klase, politika automatski klasificira sva 4 smjera u istu defaultnu klasu. Ovo možda nije dovoljno za određene tipove prometa. Npr. sav HTTP promet biti će klasificiran u defaultnu HTTP klasu. Ako je potrebno ograničiti HTTP WAN bandwidth (što je najčešće slučaj), podešavanje ograničenja na defaultnu HTTP klasu neće postići dobar rezultat jer će ograničiti promet sa klijentske strane (čak i onaj koji je već u cache-u), što nije poželjno.

d) Klasifikacija korištenjem politike
Promet može biti klasificiran korištenjem većine okidača politike. Ovakav tip klasifikacije može biti korišten za granularnu kontrolu bandwidtha. Npr. umjesto da klasificiramo sav P2P promet u jednu P2P klasu, možemo klasificirati prema P2P prtokolu koji se koristi, subnetu u koji korisnik pripada ili pak po korisničkom imenu s kojim je autentificiran u mreži. Koristeći punu snagu politike moguće je napraviti granuliranu i fleksibilnu klasifikaciju prometa.

Strategija upravljanja bandwidthom

Općenito, postoje 4 razloga zašto bi trebali upravljati bandwidthom:

1. Kako bi zaštitili performanse aplikacija ključnih za rad tvrtke ili organizacije (npr. SAP);
2. Kako bi spriječili 'bandwidtha-gladne' aplikacije (npr. P2P) od utjecaja na ostale;
3. Kako bi zaštitili bandwidth za aplikacije koje trebaju određeni bandwidth po sesiji (npr. Streaming);
4. Kako bi odredili prioritete između više potrebnih odnosno za poslovanje važnih aplikacija koje troše značajan bandwidth (npr. HTTP, IM, itd.).

Kako bi ispunili zahtjeve, sljedeća strategija bi trebala biti korištena kao temeljnji vodič:
a) Kategoriziranje svih aplikacija na mreži u sljedeća 4 popisa
- Aplikacije koje su kritične za poslovanje (npr. SAP, Oracle). One su kritične za normalno poslovanje tvrtke.
- Aplikacije koje utječu na performanse ostalih (npr. P2P). One obično imaju velike tokove podataka i gladne su bandwidtha, te se mogu proširiti toliko da zauzmu kompletan bandwidth.
- Aplikacije koje zauzimaju malo bandwidtha, ali su osjetljive na latenciju (npr. Telnet)
- Aplikacije koje su osjetljive na „jitter“. One trebaju imati jednoličan i konstantan dostupan bandwidth kako bi funkcionirale (npr. Streaming)

b) Izrada bandwidth klase za svaku aplikaciju na tim popisima. Treba imati na umu da se promet svake aplikacije može povezati sa višestrukim bandwidth klasama, u ovisnosti od kontrole koja se traži. Uobičajeno je potrebno za svaku aplikaciju imati klasu za serversku stranu i klasu za klijentsku stranu komunikacije. Također, možda će biti potrebno imati i odvojene klase za dolazni i za odlazni promet na klijetnskoj i serverskoj strani.

c) Pisanje politike koja će izvesti točnu klasifikaciju za svaku aplikaciju prema korisnički definiranim bandwidth klasama.

d) U ovom trenutku, ako je upravljanje bandwidthom uključeno, može se pustiti uređaj da radi bez konfiguriranih limita i skuplja statistike o bandwidthu. Ovo će pomoći otkriti uzorak i način na koji aplikacije troše bandwidth na mreži.

e) Podešavanje ograničenja na bandwidth za aplikacije koje su kritične za poslovanje na način da odgovaraju vašim zahtjevima. Za ovaj tip aplikacija najvjerojatnije će se podesiti minimalni zagarantirani bandwidth. Ovime se osigurava da te aplikacije dobiju zahtjevani dio bandwidtha kako bi adekvatno funkcionirale. Ukoliko su te aplikacije u isto vrijeme i „gladne-bandwidtha“ (npr. HTTP), onda se može podesiti i maximalno ograničenje bandwidtha kako ni one ne bi kompletno zauzele link, te na taj način onesposobile sve ostale aplikacije.

f) Podešavanje ograničenja na bandwidth za nebitne bandwidth klase tako da odgovaraju zahtjevima. Za ovakve aplikacije se najčešće podešava samo maksimalno ograničenje bandwidtha. Tako se osigurava da je nevažan promet ograničen samo na svoj dio bandwidtha.

g) Podešavanje ograničenja na bandwidth za promet koji je osjetljiv na latenciju. Ovo se postiže na način da se stvara hijerarhija klasa na 2 nivoa sa zajedničkom roditeljskom klasom za sve klase u vašim popisima, te podešavanjem maximalnog bandwidtha na manje nego što je stvarna propusnost linka. Sada se koriste prioriteti. Aplikacijama osjetljivim na latenciju može se dati veći prioritet nego drugim klasama. Ovime se osigurava da ukoliko postoji neiskorišten bandwidth, prve do njega mogu aplikacije osjetljive na latenciju.

h) Podešavanje ograničenja na bandwidth za „jitter“ osjetljive aplikacije. To su najčešće streaming aplikacije. SG već ima mogućnost da radi „admission control“ za streaming aplikacije, te se ovaj način preporuča za upravljanje bandwidthom ovog tipa prometa.
Admission control mehanizam poboljšava iskustvo krajnjeg korisnika za streaming aplikacije na način da spriječava sužavanje već započetih streamova. Na ovaj način ukoliko nema dosta bandwidtha za nove streamove oni neće niti početi, dok će postojeći (već pokrenuti) raditi bez prekida. Ali, ukoliko želite postići da svaki klijent može gledati streaming u svakom trenutku, pa makar i uz prekide, onda se može ograničiti maksimalni bandwidth na klasičan način za te klase kako bi im se ograničilo korištenje.

i) Grupirajte sve gore navedene klase u hijerarhije ukoliko imate potrebu za dijeljenjem neiskorištenog bandwidtha između grupe klasa. Npr. ako želite ograničiti ukupan HTTP dolazni promet , ali u isto vrijeme želite postaviti zasebna ograničenja za svaki odjel ili npr. Active Directory grupu, možete kreirati hijerarhiju na 2 nivoa sa klasom imena „HTTP dolazni promet“ i podklasa za svaki odjel. Tada se može ograničavati bandwidth za svaki odjel posebno, ali i za ukupan promet.
 

Tehnički detalji: kako radi ograničavanje bandwidtha?

Blue Coat uređaj odgađa dostavu paketa u svoj TCP stack, na taj način odgađajući slanje TCP ACK paketa natrag pošiljatelju. Rezultat ovoga je ono što pošiljatelju ozgleda kao duži RTT (round trip time). U ekstremnim slučajevima, može rezultirati popunjavanjem pošiljateljevog TCP prozora, na taj način ograničavajući brzinu po kojoj pošiljatelj može slati više podataka kako bi pratio brzinu po kojoj mu se vraćaju ACK paketi, a što odgovara brzini koja je podešena u upravljanju bandwidthom. Blue Coat NE radi nikakvu manipulaciju na TCP nivou. TCP je već dizajniran da radi ono što je potrebno za upravljanje bandwidthom, pa ProxySG koristi postojeće mogućnosti.

Sa Blue coat načinom upravljanja bandwidthom, od TCP-a se očekuje da se ponaša baš onako kako bi se ponašao u slučaju prave mreže koja ima uzak link (tzv. Usko grlo). Npr. kod „server inbound“ upravljanja bandwidthom, činiti će se kao da je „usko grlo“ onaj link koji se nalazi između web servera i Blue Coat uređaja.

Priroda TCP-a uključuje određeni broj retransmisija, čak i na mreži bez ikakvog upravljanja bandwidthom, jer pošiljatelj uvijek pokušava povećati brzinu na kojoj se šalju paketi sve dok se ne prevrši kapacitet linka i prepuni red za čekanje (queue), te se paket odbaci. Blue Coat upravljanje bandwidthom se ponaša na isti način kao što bi se ponašao router posrednik iste funkcije, punjenjem reda za čekanje, te na kraju odbacivanjem paketa kada je taj red predugačak. Ipak, TCP posjeduje algoritme koji pokušavaju minimizairati količinu odbacivanja paketa i prilagoditi se dostupnom bandwidthu na mreži čak i prije nego što dođe do gubitka paketa. Iz razloga što Blue Coat-ova tehnika izgleda kao da je u pitanju stvarni link sa smanjenim bandwidthom, mehanizmi koji već funkcioniraju u TCP-u raditi će ispravno, te će usporiti brzinu po kojoj se šalju paketi čak i prije nego što dođe do bilo kakvih gubitaka. Retransmisije će se svejedno događati (ne jako često) u trenucima kada TCP testira može li slati pakete većom brzinom nego što je trenutna. Međutim ovo će se događati neovisno o prisutnosti Blue Coat upravljanja bandwidthom.