| Název: | Content Switching |
| Autor: | Miroslav Jagoš |
| Publikováno: | LANCom 10/2002 |
Provozujete datové centrum, nebo poskytujete informace a služby pomocí portálů (Internetový, intranetový, nebo extranetový), intranetových systémů? Vlastníte Internetový obchod, provozujete Internetový bankovní systém, či prezentujete webovské stránky vaší společnosti na Internetu resp. další síťové aplikace ?
Pokud ano, pak právě vám je určen tento článek. Tím ovšem jeho četbu ostatním čtenářům rozhodně nezakazuji. Budeme se zde totiž zabývat problematikou technologie "content switching" (česky přepínání obsahu), která je určitě zajímavá nejenom pro poskytovatele služeb a informací.
Úvodem
Ve všech případech mají výše zmíněné síťové aplikace společné to, že jejich provoz zajišťuje určitý počet síťových serverů, ke kterým ve většině případů přistupuje relativně velký počet klientů. Píši "velký", protože právě tento parametr je klíčový pro způsob designu celého řešení. To by mělo být provedeno tak, aby i při velkém komunikačním náporu centrum stíhalo odbavit všechny požadavky v přijatelně krátké době. Pojďme se podívat, jak na komunikační nápor reaguje většina síťových serverů. Na následujícím obrázku je uvedena typická křivka závislosti doby odezvy na počtu nově příchozích spojení.
Historie
V počátcích provozu síťových aplikací většinou plně dostačovalo, aby všechny součásti celé aplikace běžely na jednom dostatečně výkonném stroji. Po určitou dobu toto řešení také dostačovalo. S postupným nárůstem počtu klientů a složitosti aplikací se však servery brzy začaly dostávat do "zakázané oblasti" (jestli tak mohu nazvat onen zmíněný zlomový bod uvedené závislosti) a komunikace začala váznout. Tento stav bylo třeba nějak řešit.
Jeden ze způsobů (a také ten nejjednodušší) bylo servery upgradovat. Zvýšit jim výkon výměnou, nebo přidáním procesorů, zvýšit velikost jejich operační paměti a podobně. Tomuto způsobu reakce na danou situaci se říká "vertikální škálování" a toto řešení také po určitou dobu splnilo svůj účel.
Každý server a jeho operační systém však mají své limity (maximální počet procesorů, paměti apod.) a tak když administrátoři těchto limit dosáhli, bylo potřeba zaujmout k situaci jiný postoj - aplikaci distribuovat na více serverů a zátěž mezi ně rozdělovat - tomu se říká "horizontální škálování". Jedním z nejvíce známých způsobů jak toho jednoduše dosáhnout bylo vytvořit naprosto identický server (nebo několik serverů) a zátěž mezi ně nějakým způsobem rozkládat.
Nejdostupnější technikou pro rozklad zátěže bylo použít k tomuto účelu DNS, jednomu doménovému jménu přiřadit několik adres (tolik, kolik je serverů) a je to. Uživateli byla DNS systémem vrácena vždy jedna z adres a s tímto serverem uživatel navázal spojení. Tento systém je velmi jednoduchý, dalo a dá se s jeho využitím provozovat řada jednoduchých aplikací, ale postupem času se začaly objevovat aplikace, kterým tento způsob rozkladu zátěže již nevyhovoval. Jeden z nedostatků tohoto systému je například to, že pokud během komunikace server o uživateli, nebo stavu operace ukládá do své paměti nějaké informace a z nějakého důvodu dojde ke změně, která má za následek změnu serveru, se kterým uživatel komunikuje, dojde i ke ztrátě kontinuity celého spojení a operaci nelze dokončit.
Typickou aplikací je v tomto směru elektronický obchod. Uživatel během nákupu nejdříve vybírá zboží (tuto informaci si server ukládá do paměti) a potom platí. Platba se nejčastěji provádí tak, že uživatel uvede číslo své kreditní karty a provede potvrzení celé operace. Tyto informace jsou však důvěrné a je třeba je přenášet jinak, než pomocí prostého HTTP, kde se informace přenáší v otevřené podobě. V případě HTTP pomocí šifrovaného HTTPS. Během komunikace tedy dochází ke změně komunikačního protokolu z HTTP na HTTPS (z TCP80 na TCP443). Při této změně se může stát, že klientův prohlížeč provádí znovu DNS resolvaci jména na IP adresu (protože se jedná o nové URL) a je mu vrácena adresa jiného serveru. Platba v tomto případě není uskutečněna.
Uvedený nedostatek popsaného způsobu rozkladu zátěže není ani zdaleka jediný. Další z nedostatků je například to, že servery musí mít vždy stejný výkon, protože k rozkladu zátěže dochází vždy rovnoměrně, zvyšuje se spotřeba veřejných adres a podobně. Tyto nedostatky a ještě mnohé další funkce, které je třeba ke spolehlivému provozu aplikace využívat řeší tzv. "content switching", neboli přepínání obsahu. Pojďme se na tuto technologii podívat trochu blíž.
Content Switching pod lupou
Pokud provozovaná aplikace běží na více serverech a je třeba rozklad zátěže nějak inteligentně řídit, je třeba celému systému předřadit zařízení, které bude pravidla rozkladu zátěže řídit. Toto zařízení se jmenuje "Content switch". Jen o rozkladu zátěže však content switching není. Vývoj v tomto směru šel tak daleko, že většina dnešních content switchů dokáže rozeznat jaké informace jsou během komunikace požadovány a podle toho rozhodovat, který server tyto informace poskytne. Content switch umožňuje systém serverů rozdělit tak, že každý server, nebo skupina serverů bude poskytovat jiný obsah a dohromady bude tento celek vystupovat jako jeden server. Servery je možné rozdělit například tak, že jedna skupina serverů poskytuje html stránky, další skupina obrázky a bannery a další například audio stream a z pohledu uživatele se celý systém jeví jako jeden výkonný server. Tato koncepce je vidět na následujícím obrázku.
Spojení klienta s datovým centrem je logicky zakončeno na content switchi. Ten navazuje další spojení s podřízenými reálnými servery, která jsou uživateli skryta. Tato spojení si content switch vytváří dynamicky podle typu informací, které uživatel požaduje a jejich výstup vkládá do spojení, jež má switch navázáno s klientem. Tento způsob "slepování" spojení se nazývá "TCP splicing", nebo také "delayed binding". Mezi jednotlivými reálnými servery v rámci dané skupiny content switch provádí navíc rozklad zátěže tak, aby všechny servery byly optimálně vytíženy. K tomu může využívat celou řadu různých algoritmů od klasického round-robin až po pokročilejší metodu rozkladu zátěže podle doby odezvy reálného serveru. Množství současných spojení na každý reálný server se dá navíc váhovat, takže každý server může mít různý výkon a zpracovávat různě velkou zátěž. Servery tak lze do skupiny (někdy se této skupině říká serverová farma) přidávat postupně a není třeba se zabývat tím, zda jsou od stejného výrobce, nebo mají stejný výkon. Činnost content switche se pokusím přiblížit v následujícím příkladu. Představte si server, který poskytuje následující stránku:
Stránka se jmenuje "world.html" a HTML kód této stránky vypadá následovně:
Aby mohl prohlížeč stránku zobrazit, musí v rámci HTTP spojení se serverem jednak přečíst samotný HTML kód a jednak všechny objekty, na které se tento kód odkazuje. V našem případě je na stránce uveden odkaz na jediný objekt a tím je obrázek obsažený v souboru "world.gif". Klient tedy v rámci HTTP spojení požádá server o samotnou stránku "world.html" a následně o objekt "world.gif". V případě použití content switche však klient ve skutečnosti nežádá přímo server, ale content switch, který podle definovaných pravidel stahuje požadované informace (soubory) z podřízených reálných serverů. Ve skutečnosti se soubory "world.html" a "world.gif" mohou nacházet na různých serverech což je názorně vidět na následujícím obrázku:
Velmi užitečnou funkcí, kterou content switch zvyšuje odolnost datového centra proti výpadku, je kontrola dostupnosti reálných serverů, tzv. "health checking". Pokud switch zjistí, že některý reálný server je z nějakého důvodu mimo provoz, vyřadí jej z dané skupiny reálných serverů a zátěž distribuuje pouze mezi zbylé servery. Toto zjišťování dostupnosti switch může provádět nejrůznějšími metodami od icmp echo, přes kontrolu odezvy na určitém portu až po pokročilé testování pomocí uživatelem definovaného skriptu. Jakmile server opět začne odpovídat, switch jej hned nazahltí množstvím spojení, což by server mohlo opět "shodit", ale pomocí funkce "slow-start" pomalu zvyšuje množství příchozích spojení až se jejich množství vyrovná ostatním serverům v rámci skupiny.
Nedostatek starého způsobu rozkladu zátěže týkající se změny reálného serveru při změně komunikačního protokolu uvedený v části o historii content switch řeší funkcí "sticky". Podle určitých informací o klientovi (například jeho IP adresa, nebo tzv. cookie) může rozhodnout, na který reálný server klienta odkáže. Informaci o tom, na ktererý server switch klientovo spojení odkázal si určitou dobu udržuje v paměti. Pokud během doby expirace tohoto záznamu v paměti content switch identifikuje nové spojení od tohoto klienta, odkáže jej bez ohledu na pravidla rozkladu zátěže na tentýž reálný server. Tím se zajistí, že i během změny komunikačního protokolu klient pracuje na stejném reálném serveru.
Tím, že mezi klientem a reálným serverem leží content switch, zvyšuje se i bezpečnost reálných serverů, neboť některé pokročilé modely switchů mají zabudovánu ochranu před základními typy útoků, jakými je například denial of service pomocí synflood. Bezpečnost switch zvyšuje i prostým faktem, že provádí překlad adres NAT. Stejně jako u směrovačů lze na content switchích definovat a provozovat také paketové filtry.
Nejrůznějších funkcí, které by se zde daly ohledně content switchingu jmenovat je ještě velká spousta a jejich popis by překročil rámec prostoru vymezenému pro tento článek. Doufám, že na jeho základě jste si o této technologii učinili alespoň hrubý obrázek. Pro informaci ještě uvedu některé výrobce a některé jejich content switche:
- Cisco Systems: CSM modul do přepínače Catalyst 6500, CSS 11500, CSS 11800 a další.
- Alteon/Nortel: ACEdirector a přepínače série 700.
- F5 Networks: Big/IP a LAN switch Partners.
- Foundry Networks: ServerIron.
Závěrem
Funkce a principy uvedené v tomto článku jsou základními funkcemi téměř všech dnešních content switchů. Vidíte, že proti prostému rozkladu zátěže pomocí DNS tato technologie umožňuje nejen prostý rozklad, ale umožňuje provozovat velmi sofistikovaný, robustní, snadno škálovatelný a odolný systém, což by mělo v době elektronického obchodování a rostoucím využití Internetu a sítí obecně být samozřejmostí. Pokud se tedy zabýváte obory činnosti uvedenými v úvodu tohoto článku, měli byste se o možnosti, které vám content switching přináší zajímat blíže. Vaše servery budou jistě spokojeny, o klientech nemluvě.
