Rozkládání zátěže a zajištění dostupnosti systémů a služeb v počítačových sítích Ing. Pustka, Martin Katedra ATŘ-352, VŠB-TU Ostrava, 17. listopadu, Ostrava - Poruba, 708 33
[email protected] http://home.vsb.cz/puma Abstrakt: V praxi se mnohdy setkáváme s problémy, jak zajistit v co největší míře dostupnost systému a služeb a také jak zvládnout velkou zátěž, která klade nároky na výkon počítačového systému i kvalitu sítě. Protože řešení problémů zálohy a rozložení zátěže se ve velké míře shoduje, je vhodné mnohdy řešit tyto problémy společně. V tomto příspěvku chci podat jakýsi obecnější pohled na problematiku. Pro praktickou realizaci uvedených postupů je nezbytná znalost problematiky, zejména pak síťových a aplikačních protokolů.
Úvod V praxi se rozkládání zátěže a záloha nasazují u velmi zatížených aplikačních serverů, které poskytují výkonnostně náročné služby (např. WWW, FTP, DNS, velké poštovní servery apod.). Použít je však můžeme u téměř jakékoliv jiné zatížené služby, např. v počítačové síti, ve které se nachází velké množství sond, které předávají získané informace centrálnímu počítači. V případě výpadku tohoto systému pak může dojít k nežádoucím komplikacím. Tato problematika je o to aktuálnější, že v současné době jsou počítačové sítě součástí všech trochu rozsáhlejších řídicích a monitorovacích systémů. Výpadek nebo nedostupnost systému, který poskytuje poskytuje významné služby dalším počítačovým systémům v jakémkoliv logickém celku, může nepříznivě ovlivnit stabilitu celku. Problematiku výpadku fyzického systému je třeba řešit fyzickou zálohou systému nebo důležitých kompoment a obvykle bývá způsobena chybou nebo únavou komponent. Nedostupnost systému však může být způsobena příliš velkou zátěží procesoru, sítě, nedostatkem fyzické paměti apod. Řešením často bývá "hrubá síla", tj. posílení slabých míst (např. výměna CPU, přidání paměti, posílení připojení do sítě, optimalizace počítačové sítě atd.). Je však možné, že přetížení se může opakovat a častější nákup nových spolehlivých komponent se může prodražit. Vhodným řešením je mnohdy také rozložení zátěže na více systémů. Výhod je zde hned několik. Zejména tímto krokem řešíme také problém zálohy, protože v případě výpadku jednoho systému jsou služby poskytovány i nadále, byť za cenu větší zátěže zbývajících systémů (tato zátěž je však jen dočasná do doby opravy). Mezi další výhody lze zařadit poměrně jednoduchou možnost posílení celého systému prostým přidáním
dalších počítačových systémů, přičemž starší (a méně výkonné systémy) můžeme v clusteru ponechat. Další výhodou je možnost dočasného odstavení jednotlivých systémů pro možnou technickou údržbu, aniž by došlo k vyřazení služby. Klíčová slova: load balancing, záloha, rozkládání, zátěž, počítačové sítě, cluster, aplikační farma
Záloha systémů a služeb Zálohy můžeme rozdělit na dva druhy: •ι pasivní záloha •ι aktivní záloha (rozkládání zátěže) a) Pasivní záloha - záložní systém hlídá dostupnost primárního systému
System 1
System 2
Záložní systém (system 2) periodicky sleduje, zda je primární systém (system 1) dostupný. Jestliže není, okamžitě se začne v síti propagovat jako primární systém, čímž převezme jeho funkci. Je otázkou strategie provozovatele, jestli po obnovení funkce primárního systému předá funkci primárního systému systému 1 nebo si ji nechá a systém 1 převezme funkci záložního systému. b) Pasivní záloha - směrování na primární nebo záložní systém provádí redirect system
Redirector
System 1
System 2
Služby poskytuje systém system 1. V případě výpadku redirect system směruje definovanou službu na záložní systém system 2. Opět záleží na strategii provozovatele služby, zda po obnovení funkčnosti systému 1 je provoz směrován na tento systém nebo zda systém 1 převezme funkci záložního systému.
Rozkládání zátěže Při pasivní záloze je nevýhodou nevyužití druhého systému, který nevykonává žádnou činnost a přesto musí být v systému zapojen. Proto se jako vhodná jeví "aktivní záloha", tj. rozkládání zátěže mezi všechny systémy. V praxi vypadá situace následovně: nově příchozí spojení je směrováno na systém, který je podle konkrétního algoritmu označen za vhodný. Kritérií je spousta: počet spojení, počet klientů, zatížení systému, cyklické směrování, statické směrování apod. Často se tedy využívá prvek označený Load-Balance system (Load-Balance server, LBS), který podle definovaného algoritmu rozděluje provoz mezi více aplikačních systémů. Load balancing může být realizován na síťové, transportní či aplikační vrstvě OSI modelu.
Skupinu aplikačních systémů nazýváme cluster, můžeme se také setkat s pojmem aplikační farma. Celý systém (tedy včetně systému LBS) pak nazýváme virtuální server. Navenek se nám jeví jako jeden systém a také k němu jako k jednomu systému z klientských stanic přistupujeme. K dispozici máme tyto algoritmy rozkládání zátěže: •ι •ι •ι •ι
round-robin scheduling weighted round-robin scheduling least-connection scheduling weighted least-connection scheduling
round-robin scheduling Rozdělování probíhá bez ohledu na počet spojení nebo odezvu systému. Cyklicky se směrují požadavky na všechny systémy: ABCABCABC. Vhodné tam, kde je předpoklad, že výkon systémů a jejich zátěž budou vyrovnány. Nevýhodou je to, že jednotlivá spojení se mohou lišit v náročnosti na serverový čas, tedy že některé ze systémů mohou být mnohem více zatíženější než ostatní, protože není zohledňováno zatížení jednotlivých systémů. weighted round-robin scheduling Podobně jako round-robin scheduling, ale navíc máme možnost stanovit si váhy jednotlivých systémů. Vhodné tam, kde jsou nasazeny různě výkonné systémy. Váhy jednotlivých systémů: WA= 4 WB= 3 WC=2 Potom budou požadavky směrovány takto: ABC ABC ABA, tj. systém A by měl být nejvýkonnějším systémem ze všech tří systémů. Nevýhody jsou stejné jako u round-robin scheduling - opět zde není zohledňováno zatížení jednotlivých systémů.
least-connection scheduling Spojení bude směrováno na server s nejmenším počtem právě probíhajících spojení. Tento algoritmus je dynamický, protože je potřeba počítat spojení každého serveru dynamicky. U celků, kde je relativně malý provoz dává velmi dobré výsledky. Dobré výsledky dává také u systémů s různým výkonem, protože rychlejší systém vyřídí spojení rychleji než pomalejší a je možno na něj tedy směrovat další spojení. Nevýhodou je, že každý síťový protokol má definovaný čas, po který čeká na další data. Až po uplynutí této doby je spojení opravdu ukončeno. V tomto algoritmu je však i takovéto neaktivní spojení spojením, byť klade minimální nároky na zátěž systému. Předpokládejme však, že tyto neaktivní spojení jsou rovnoměrně rozložena mezi všechny systémy. weighted least-connection scheduling Princip je stejný jako u least-connection scheduling (a také mnoho výhod i nevýhod). Navíc má ale každý ze systémů váhu - ohodnocení - kolik procent spojení z celkového počtu bude vyřizovat. Vzorce jsou přebrány z [LinuxVirtualServer 1999]:
Wi (i = 1 ... n) ........ váha n
ALL _ CONNECTION = å ci 0
Následující spojení bude směrováno na systém j, který získáme z následujících rovnic:
cj
é ù ci = min ê ú ALL _ CONNECTION ⋅ W j ë ALL _ CONNECTION ⋅ Wi û cj
éc ù = min ê i ú wj ë wi û Tento algoritmus bývá nejčastěji používán v praxi. Parametr C může být nejen počet spojení, ale také např. zatížení systému.
Praktické prostředky V praxi můžeme použít pro Load-Balance System (LBS) například tyto prostředky: 1. LinuxVirtualServer - řešení postavené na OS Linux 2. WSD Radware 3. Cisco Local Director Linux Virtual Server
Linux Virtual Server je projekt, se kterým se lze blíže seznámit na Internetu - viz [LinuxVirtualServer 1999]. Celý systém je založen na OS Linux. Pro běh je potřebná malá úprava jádra Linuxu (tzv. patch). V současnosti jsou k dispozici patche pro stabilní jádra (řady 2.0.X a 2.2.X). Dále se dodávají programy, pomocí kterých definujeme pravidla a algoritmy. Systém se dodává ve formě zdrojových textů a je šířen zdarma pod licencí GPL. Virtuální server lze u tohoto projektu realizovat pomocí IP tunnelingu, pomocí direct routingu nebo s využitím NAT (Network Address Translation). IP tunneling - virtuální server směruje pakety na aplikační systémy, odpovědi zasílají aplikační systémy přímo klientským systémům Direct routing - podobné jako IP tunneling, ale není zde režie s tunelováním provozu, nejrychlejší řešení. NAT (Network Address Translation) - tzv. překlad adres, IP adresy jsou mapovány z jedné skupiny na druhou, odpovědi systémů jsou předávány LBS, ten opět provede překlad adresy a data pošle klientskému systému - větší náročnost na výkon LBS, univerzální řešení, žádné požadavky na aplikační systémy.
V ceně toto řešení jednoznačně vede. Výkon také postačuje - udává se, že na procesorech Pentium je možno při použití nejnáročnější metody NAT zařadit do clusteru až 20 systémů. Nevýhodou by se mohla jevit spolehlivost počítačového systému, která by se nepochybně dala některými zásahy zvýšit. Zájemce o podrobné řešení odkazuji např. na domácí strántu tohoto projektu. Výhodou může být řešení šité na míru, protože i zde platí heslo „Linux je takový, jaký si ho uděláte“. Můžeme ho nakonfigurovat tak, aby podporoval dynamické routování (vlastnost, která se občas hodí; jsou podporovány všechny běžné routovací protokoly), realizovat virtuální privátní síť, firewall mechanismy atd.
WSD, WSD-Pro, WSD-Pro+
WSD (Web Server Director) je jednoúčelové zařízení Izraelské firmy RadWare. Dokumentace k tomuto zařízení je k dispozici na Internetu - viz [Radware 2000]. Ze všech zde uvedených řešení je nejvýkonnější. Přestože má v názvu slovo "Web", tak jej lze bez problémů použít na rozkládání zátěže snad všech protokolů nad protokolem IP. Zařízení má také spoustu možností, které se netýkají jen rozkládání zátěže v rámci clusteru. Konfigurace je možná pomocí grafického rozhraní z prostředí (speciální obslužný program dodávaný se zařízením) nebo z příkazového řádku. Konfigurovat lze přes SNMP (Simple Network Management Protocol) - při konfiguraci pomocí příkazové řádky je nutno se připojit přes sériový port. Z vlastní zkušenosti mohu říci, že konfigurace z příkazové řádky by mohla být více user-friendly, oproti konfiguraci systémů firmy CISCO má toto zařízení ještě co dohánět. Vhodným prvkem (který ovšem ne vždy najde uplatnění) je možnost routování, zdalost routovacích protokolů (RIP, OSPF). Toto zařízení je vhodné pro svou stabilitu a rozšiřitelnost. Lze sdružovat několik těchto zařízení, které mohou pracovat zvlášť, ale zároveň se také navzájem zálohovat. Díky absenci některých k poruchám náchylnějších zařízení (např. harddisky) je toto zařízení vhodné použít u velmi důležitých a zatížených systémů. Jeho nevýhodou je snad jen cena (ceníky udávají cenu okolo 15.000 USD). Z firemních testů firmy Radware, kdy byla porovnávána zařízení WSD a Cisco LocalDirector vyplývá, že CiscoLD má maximální datovou propustnost jen 45Mbps oproti 100 Mbps WSD. Mezi další fakt, který mluví pro zařízení WSD patří podpora až 10.000 serverových farem a až 50.000 serverů (oproti 8.000 u Cisco LocalDirector). Je otázkou jsme-li schopni dát dohromady opravdu takové množství serverů.
Cisco Local Director
I u vedoucí firmy v oblasti aktivních síťových prvků lze nalézt řešení pro rozkládání zátěže. Popis zařízení je k dispozici na firemním serveru firmy Cisco - viz [CiscoLocalDirector 2000]. Tuto problematiku firma Cisco nazývá MultiNode Load Balancing. Řešení spočívá v
instalaci nového prvku - Local Directoru - do blízkosti routeru. V routeru musí být spuštěn tzv. Forwarding Agent, což je paketový redirector založený na Cisco IOS a který směruje paketu na základě instrukcí systému nazvaného Services Manager. Dále musí být nainstalován Workload agent, což je program, který běží na aplikačním systému a informuje Service manager systém o zatížení systému. Na základě informací, která Service Manager obdrží od Workload agentů, doporučuje Forwarding Agentovi, kam má směrovat pakety. Je myšleno také na zálohu a můžeme zde nalézt také Backup Services Manager, který čeká na výpadek hlavního Service Manageru, aby ho ihned nahradil. Výhodou může být trochu větší rychlost oproti řešení se zařízením WSD, protože odpadá jeden mezičlánek (router-WSD-server oproti router-server). Nevýhodou (a v mých očích ne bezvýznamnou) by mohl být fakt, že zde máme více prvků (byť s možností zálohy). Přeci jen komunikace ForwardingAgent - ServiceManager - WorkLoad Agent mi připadá k chybám náchylnější než když veškeré rozhodování je v jednom zařízení. Závažnější nevýhodou pak je omezený počet podporovaných protokolů. Firma Cisco však svůj systém vyvíjí a je možné, že se vbrzku dočkáme kvalitního systému.
Principy a problémy Zajištění směrování klienského systému na stejný server
Když se klient připojí k virtuálnímu serveru, je jeho spojení přesměrováno na jeden z aplikačních serverů. Aplikační systém může odpovědět a spojení se uzavře. Je však docela dobře možné, že server si poznamená nějaké informace, které jsou potřebné při dalším spojení. Proto je třeba mít možnost přesměrovat při dalším přístupu spojení na stejný aplikační server. Z tohoto důvodu si musí LBS udržovat tabulku připojených klientských systémů včetně času, kdy naposledy bylo provedeno přesměrovaní klienta. Při dalším přístupu je pak klient směrován ne na základě zatížení systému (resp. podle definovaného algoritmu), ale na stejný serverový systém. Až po určité definované době nečinnosti klienta je záznam vymazán a při dalším přístupu je směrován podle zvoleného algoritmu. Pokud například rozkládáme zátěž služby DNS (Domain Name System), kdy každý dotaz může vyřídit kterýkoliv serverový systém, nemusíme tyto tabulky udržovat vůbec. Pokud však použijeme protokol HTTP, bývá často žádoucí směrovat jednoho klienta na stejný systém. Zde však nastává problém WWW proxy cache serverů (například tento problém lze poměrně jednoduše, byť za cenu větší zátěže LBS, řešit). Z těchto jednoduchých příkladů by mělo být jasné, jak velmi důležitá je znalost aplikačních protokolů a principů počítačových sítí. Synchronizace obsahu a služeb
Dalším problémem, který je třeba řešít je problematika synchronizace obsahu či služeb. Je jisté, že každý serverový systém buď data poskytuje nebo sbírá, často koná obě činnosti najednou. Proto vzniká problém, jak vhodně ukládat data, která zapisuje jeden systém, aby byla k dispozici dalším systémům. Tento problém je relativně rozsáhlý a musí se řešit s ohledem na typ služby, technické a programové možnosti.
Bezpečnost
Statistiky říkají, že 90% útoků proti systémům pochází z vnitřního prostředí. Teď ovšem nemám na mysli bezpečnost před získáním nepřidělených práv, ale ochranu před tzv. DOS útoky (Denial of service attacks). Tyto útoky mají za cíl zabránit poskytování služby. Obvykle jsou realizovány tak, že z jednoho systému jsou neustále iniciována spojení se serverovým systémem. Útočníkovi nejde o to získat odpovědi, ale svými spojeními zatížit systém natolik, že nebude schopen odpovědi ostatním klientským systémům. Při volbě správné strategie (např. podle zatížení aplikačních serverů) se nám tyto spojení "rozptýlí" mezí všechny servery, které budou zatíženější, nicméně stále schopné funkce. Dalším řešením by bylo směrovat dotazy z jednoho klienta vždy na jeden aplikační server - ten sice nebude téměř schopen funkce, ale ostatních systémů se tento útok nedotkne. Horší situace nastává při DDOS - distribuovaném DOS útoku. Spojení jsou inicializována z mnoha různých systémů. Útěchou nám může být fakt, že tyto útoky nejsou realizovány pro svou technickou náročnost příliš často. Zde pomůže jedině LBS s podporou pro zabránění těmto útokům nebo je potřeba před LBS zařadit systém, který se s tímto útokem dokáže vypořádat. Z tohoto hlediska je na tom dobře řešení firmy Cisco, která poskytuje speciální firewall software. Do jisté míry se s tímto problémem dokáže vyrovnat i OS Linux i WSD.
Závěr Není jednoduché na několika málo stranách naznačit tuto rozsáhlou problematiku. Mou snahou bylo alespoň poodhrnout roušku na první pohled jednoduchého problému, který však může být někdy velmi komplikovaný. Představme si rozsáhlejší hierarchickou monitorovací a řídicí strukturu složenou z jednoduchých sond, které prostřednictvím počítačové sítě (myšleny jsou současné sítě s protokolem IPv4) zasílají naměřené údaje centrálním počítačům. Ty potřebujeme zálohovat, je potřeba je i také předimenzovat, aby nebyly příliš zatíženy síťovým provozem ani netrpěly nedostatkem výkonu. Mějme však na paměti také systémovou bezpečnost, protože lze mnohé z útoků odstranit použitím vhodné strategie na LBS.
Literatura [LinuxVirtualServer 1999] Linux Virtual Server Project [online]. Wensong Zhang, Shiyao Jin, Quanyuan Wu (National Laboratory for Parallel & Distributed Processing Changsha), 1999, Dostupný z:
[CiscoLocalDirector 2000] LocalDirector Documentation [online]. Cisco Systems Inc., 2000, Dostupný z URL: [Radware 2000] Radware WSD, WSD-Pro, WSD-Pro+ [online]. Radware, 2000. Dostupný z URL:
