5.2  Optimalizace provozu WWW cache

Řešení v roce 1999 se zaměřilo na

Provoz sítě vyrovnávacích WWW serverů

Provoz sítě HTTP proxy serverů zahrnuje zejména testování nových verzí operačního systému a programového vybavení (Squid) a jejich implementaci na produkční síť, reakce na požadavky a dotazy uživatelů.

V souladu s vývojem jak provozovaného operačního systému tak programového vybavení byly implementovány postupně novější verze tak, že vyrovnávací servery na konci roku 1999 používají tuto konfiguraci:

Ověřovali jsme zejména stabilitu operačního systému a aplikačního programového vybavení v souvislosti se změnami glib.c knihovny, změnami v implementaci asynchronního přístupu k souborům u Squidu a nové implementace rozhraní do souborového systému a služby DNS u vývojové verze Squidu.

V průběhu řešení již nebyl striktně dodržován požadavek na přísnou jednotu verzí instalovaného programového vybavení, který si řešitelé sami uložili v předchozím období. Dodržování tohoto přístupu, který sice zjednodušuje průběžnou správu systému, by komplikovalo vývojové práce na úrovni operačního systému a Squidu, které byly v tomto období nejdůležitější činností skupiny.

Synchronizace konfigurací serverů

V souvislosti s rutinním provozem sítě vyrovnávacích serverů byla řešena potřeba synchronizace úprav v jejich konfiguracích. K těmto úpravám v rámci celé sítě dochází tehdy, pokud se přidávají nové spolupracující servery (spravované administrátory jiných připojených institucí) či je-li zapotřebí změnit vzájemné vztahy serverů v síti - např. při ladění zatížení daného požadavky sousedních vyrovnávacích serverů. Pro tento úkol jsme navrhli a uvedli do života schéma distribuce konfigurací.

Stanovili jsme pro ně tyto základní požadavky:

Princip řešení

Celý konfigurační systém vychází z centrální databáze vyrovnávacích WWW serverů. Do ní jsou zařazeny všechny zúčastněné stroje - jak centrální, tak spolupracující servery. Dělí se do tří kategorií:

páteřní
Cílem systému je vyrobit konfigurační soubory pro všechny páteřní servery.
partnerské
Servery jiných institucí, které jsou však natolik kvalitní (z hlediska diskového prostoru a rychlosti připojení), že má smysl oboustranná spolupráce s nimi - dokumenty se jim poskytují a také se po nich požadují.
klientské
Zde je spolupráce jednostranná. Klientský server využívá servery páteřní, ale sám nic neposkytuje.

Vždy po provedení změny v databázi musí správce spustit program make, který na základě jejího obsahu vytvoří konfigurační soubory pro jednotlivé páteřní servery a následně je serverům rozešle.

Akceptování konfiguračních změn není prováděno on-line. Předpokládá se, že rekonfigurace není natolik urgentní, aby bylo třeba implementovat odpovídající synchronizační mechanismy. Postačí, když se v pravidelných intervalech (v současné konfiguraci jednou denně v nočních hodinách, v případě potřeby lze frekvenci zvýšit) na každém z páteřních serverů vyvolá kontrolní program. Ten zjistí, zda server neobdržel novou konfiguraci. Pokud ano, aktivuje ji.

[obrázek]

Obrázek 5.3: Schéma uspořádání systému

Datový soubor

Data o vyrovnávacích serverech jsou uložena na centrálním konfiguračním počítači v textovém souboru ve formátu, kde každá položka je umístěna na samostatném řádku a má tvar:

název<tabulátor>hodnota

Soubor řádků pro jeden vyrovnávací server je od ostatních oddělen prázdným řádkem. V současné době se pracuje s položkami uvedenými v tabulce 5.1. Některé slouží ke generování konfigurací, ostatní jsou pro potřeby správce databáze (např. kontaktní informace či poznámky).
name doménové jméno vyrovnávacího serveru
IP IP adresa vyrovnávacího serveru
type kategorie serveru (core, partner, client)
cont jméno správce serveru
mail elektronická adresa správce
phone telefonní číslo správce
desc poznámky, doprovodné údaje a podobně

Tabulka 5.1: Položky databáze vyrovnávacích serverů

Generované konfigurace

Konfigurace je rozdělena do dvou částí - automaticky generované a lokální, která je udržována ručně správcem daného serveru. Automaticky generovaná část obsahuje jen ty prvky konfigurace, které mají globální charakter. Konkrétně se jedná o tyto konstrukce:

Tyto konfigurační soubory jsou prostřednictvím scp distribuovány odpovídajícím serverům.

Uvedení konfigurace do provozu má na starosti program makecfg. Spouští se v pravidelných intervalech prostřednictvím standardního programu cron. Kromě toho jej správce po provedení změn může spustit ručně.

Transparentní vyrovnávací server (WCCP)

Na počátku roku byla možnost transparentního přesměrování WWW provozu na vyrovnávací servery založené na programu Squid omezena jen na metodu podmíněného přesměrování provozu (policy routing). Tato metoda byla v předchozím projektu vyzkoušena a provozována na několika lokalitách sítě TEN-34 CZ. Použité řešení s sebou neslo vysoké nároky na kontrolu korektní funkce vyrovnávacího serveru a implementaci mechanismu řešícího jeho sehání. Nebylo jednoduché rozkládat zátěž na několik vyrovnávacích serverů a navíc neúměrně stouplo zatížení směrovače. Tyto nevýhody omezují použití metody podmíněného přesměrování provozu pouze na menší lokality.

WCCP protokol

WCCP (Web Cache Coordination Protocol) je protokol navržený firmou Cisco Systems pro spolupráci vyrovnávacího serveru se směrovačem. Původně byl vyvinut jako firemní protokol pro spolupráci s Cisco Cache Engine. Později byla verze 1.0 licencována i jinými společnostmi (Inktomi, Network Appliance a NLANR-Squid).

WCCP protokol má dvě hlavní funkce

Svým chováním je WCCP velice podobný transparentnímu přesměrování na přepínačích čtvrté vrstvy.
[obrázek]

Obrázek 5.4: Vyrovnávací servery s WCCP protokolem

Vzhledem k výše uvedeným vlastnostem a díky tomu, že páteř sítě TEN-155 CZ je provozována na zařízeních Cisco, se WCCP protokol jeví jako optimální pro širší nasazení transparentních vyrovnávacích WWW serverů.

V polovině roku byla do vývojové verze Squidu 2.3 implementována podpora WCCP. Vzhledem k tomu, že je tato verze nestabilní, implementovali jsme WCCP do poslední dosud uvolněné stabilní verze Squidu 2.2STABLE5 - viz
http://www.vsb.cz/~hal01/cache/wccp/

V době prvních pokusů s nasazením Squidu s WCCP jsme museli řešit otázky samotné funkčnosti WCCP u programového vybavení Squid a následně posoudit otázky výkonnostní.

Podpora WCCP protokolu v operačním systému Linux

Stávající implementace GRE v jádru Linuxu neumožňuje bez předchozích úprav nasazení Squidu s protokolem WCCP.

Přesměrované WWW pakety jsou směrovačem zapouzdřeny do GRE paketů a typ protokolu je označen jako 0x883e. Označení tímto protokolem, který není Linuxu znám (firemní označení), zabrání operačnímu systému v dalším zpracování zapouzdřeného paketu. Vzhledem k tomu, že struktura zapouzdřeného paketu odpovídá standardnímu IP, je možné přepsat pole typu protokolu v paketu na 0x0800 (IP protokol).

Tato úprava ve zdrojových souborech jádra se v případě Linuxu uskuteční v souboru /usr/src/linux/net/ipv4/ip_gre.c

Do funkce ipgre_rcv je třeba přidat

int ipgre_rcv(struct sk_buff *skb, unsigned short len){
...
if (skb->protocol == __constant_htons(0x883e))
        skb->protocol = __constant_htons(ETH_P_IP);
...
}

Opravná dávka (patch) je uložena na
http://www.vsb.cz/~hal01/cache/wccp/ip_gre.patch.

Toto řešení je původní. Ohlásili jsme je autorům Squidu, kteří odkaz na úpravu zahrnuli do doprovodné dokumentace programu
http://squid.nlanr.net/Doc/FAQ/FAQ-17.html#ss17.10.

Podrobný technický popis transparentních vyrovnávacích serverů a jejich nasazení v rámci sítě TEN-155 CZ je dostupný na http://www.vsb.cz/~hal01/cache/doc ve formě článků pro další provozovatele transparentních vyrovnávacích serverů.

Výkonnostní parametry vyrovnávacího serveru Squid s WCCP

Při provozu vyrovnávacího serveru Squid s podporou WCCP docházelo u Squidu k uváznutí ve zpracování událostí, které mělo za následek odpojení serveru od směrovače. Tento stav jsme napravili zásahem do zdrojového kódu Squidu a implementací prioritního zpracování událostí.

V souvislosti s předpokládaným dalším nasazením Squidu s WCCP protokolem jsme testovali výkonnostní parametry Squidu na stávajícím technickém vybavení, abychom mohli stanovit kvalifikovaný odhad potřebného počtu vyrovnávacích serverů pro větší lokality.

Při stávající konfiguraci vyrovnávacího serveru (Pentium Pro, 200 MHz, 256 MB operační paměti, 10 GB diskového prostoru pro cache) se daří provozovat stabilní vyrovnávací server do zatížení cca 3200 HTTP požadavků za minutu při současně otevřených 1200 deskriptorech souborů, zatížení procesoru se pohybuje v rozmezí 55-60 %.

Vyšli jsme ze zkušeností s provozováním vyrovnávacího WWW serveru s WCCP ve středně velké lokalitě (oblast Ostravy a Opavy) a na základě velikosti datových toků do jednotlivých metropolitních sítí stanovili počty potřebných strojů, jak je uvedeno v tabulce 5.2. V souladu s touto rozvahou jsme vznesli požadavek na nákup nových strojů. Byly dodány v prosinci 1999 a k jejich zprovoznění dojde během ledna 2000.

lokalita počet
Brno 6-7
Ostrava 2
Plzeň 2
Liberec 1
České Budějovice 1

Tabulka 5.2: Počty WCCP serverů

Stávající servery budu použity v nových lokalitách a pro některé podpůrné úlohy, jako je zpracování a zpřístupnění protokolů o činnosti jednotlivých serverů. Není vhodné kombinovat v jedné farmě stroje různých výkonnostních parametrů, aby vykazovaly shodné parametry při přístupu k libovolnému WWW serveru v Internetu.

V současné době je Squid s WCCP provozován v Brně, Českých Budějovicích, Liberci a Ostravě, připravuje se zprovoznění v Plzni. Lokalita Brna a Ostravy je do zprovoznění plánovaného technického vybavení vykryta pouze částečně (v mezích možností stávající techniky).

Pro posuzování výkonnostních parametrů jsme odladili jednoduché nástroje pro sběr provozních dat. Slouží správci vyrovnávacího serveru pro vyhodnocení práce serveru, srovnání s jinými konfiguracemi a lokalitami a posuzování vlivu změn na výkonnost systému. Vzhledem k tomu, že vyrovnávací server ovlivňuje celá řada vnějších vlivů a okamžitých situací, nelze jednotlivé závislosti vybraných proměnných popsat jednoduchou funkcí. Z tohoto důvodu jsou opakovaně po delší dobu shromažďovány provozní hodnoty serveru, které v grafickém znázornění vymezují oblast práce vyrovnávacího serveru.

[obrázek]

Obrázek 5.5: Závislost úspěšnosti na počtu požadavků

[obrázek]

Obrázek 5.6: Zatížení procesoru v závislosti na počtu otevřených deskriptorů

[obrázek]

Obrázek 5.7: Zatížení procesoru v závislosti na počtu požadavků

Pro ilustraci předkládáme tři z charakteristik provozovaných vyrovnávacích serverů. Z grafu na obrázku 5.5 je zřejmé že v provozovaném systému je úspěšnost vyrovnávacího serveru nezávislá na zatížení serveru. Graf na obrázku 5.6 znázorňuje závislost zatížení procesoru na počtu otevřených deskriptorů souborů. Z charakteristiky je zřejmé, že od cca 300 otevřených deskriptorů již zatížení procesoru dále nevzrůstá a je zapotřebí lokalizovat část kódu vyrovnávacího serveru způsobující nasycení. Na obrázku 5.7 je zřejmá lineární závislost zatížení procesoru na počtu HTTP požadavků klientů. Od cca 3000 požadavků za minutu dochází ke ztrátě linearity závislosti.

Cisco Cache Engine

Na začátku roku jsme zprovoznili farmu tří strojů Cisco Cache Engine pracujících jako transparentní vyrovnávací servery. Tato farma je připojena k hraničnímu směrovači TEN-155 CZ a má zachytit WWW provoz od klientů, kteří nejsou obsluhováni některým z vyrovnávacích serverů v rámci sítě TEN-155 CZ.

Při reálném provozu jsme však zaznamenali nemalé problémy jak se spolehlivostí techniky, tak s funkčností při vyšším zatížení. Konkrétně docházelo k následujícím situacím:

Na základě těchto zjištění byly Cisco Cache Engine u dodavatele reklamovány a byl dohodnut postup pro nápravu: stávající zařízení budou bezplatně vyměněna za nový model a firma Cisco Systems navíc dodá další tři exempláře. Nová verze Cisco Cache Engine byla testována během srpna a září na mezinárodní lince sítě TEN-155 CZ, tedy pod plnou zátěží, a vykazovala bezproblémové chování.

Společně se dvěma nově zakoupenými exempláři tak vznikne farma osmi Cisco Cache Engine. Bude zpracovávat dotazy od uživatelů, kteří nejsou obsluhováni lokálními vyrovnávacími servery (především Prahu a některé menší lokality).

Díky problémům s Cisco Cache Engine nemohla být ve větší míře testována služba SkyCache využívající předběžného přenosu objektů do vyrovnávacího serveru přes satelitní spoj. Tato služba je (podle smlouvy se společností SkyCache) do doby nasazení nových Cisco Cache Engine ve stavu testování.

Úkoly pro příští období

předchozí
obsah		 následující
další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz