Vybrané technické aspekty elektronické podpory univerzitní výuky

S postupným zaváděním jednotlivých funkcí pro elektronickou podporu výuky do běžného provozu v prostředí velkých univerzit nabývá na významu problematika správné volby technické infrastruktury. Ukazuje se, že aplikace, které mohou výborně plnit svoji funkci v měřítku jedné fakulty či katedry, vyžadují v masivním nasazení pro desítky tisíc denně přistupujících uživatelů zvláštní pozornost a to jak z hlediska hardwarového zázemí tak z hlediska systémového software. Tento příspěvek má za cíl seznámit zájemce spíše s některými obecnými principy, které byly úspěšně využity při provozu Informačního systému Masarykovy univerzity v Brně(1), bez ohledu na úplnost popisu technického řešení.

1. Architektura systému

Většina současných systémů využívá výhod celosvětové sítě Internet a její služby World Wide Web, kdy klientský počítač provozuje pouze jednoduchý webový prohlížeč, který všechny uživatelské akce odesílá webovému serveru. Serverová část zpracovává požadavky jednotlivých klientů a integruje v sobě (obvykle formou dalšího, tzv. aplikačního serveru) veškerou aplikační logiku. Data udržovaná v systému jsou pak dostupná pomocí další vrstvy - databázového systému. Tento princip je běžně známý a hojně využívaný také v řadě dostupných systémů pro řízení výuky. Přesto se nezřídka můžeme setkat s přístupem, který touto metodou pouze doplňuje stávající aplikace, přímo instalované na klientské počítače dle architektury klient-server. Tento přístup má však značné nevýhody, z nichž zmíníme pouze dvě:

1. specifické aplikace typu klient-server nemohou zajistit takovou rozšiřitelnost, jakou poskytují obecně podporované webové prohlížeče, jež jsou přímo součástí operačního prostředí dnešních počítačů a ostatních zařízení. Právě přístup z různých druhů prostředí, ať už jsou to různé sítě typu internetové kavárny či mobilní zařízení rozličných typů, jsou již běžným prostředkem pro zajištění komfortu uživatelů.
2. distribuce a podpora aplikací na klientské straně ať už z důvodu opravy chyb nebo neustálé inovace je v rozsáhlém prostředí značně nákladná. V prostředí desítek tisíc aktivních uživatelů, kteří využívají stovky různých programových platforem v podstatě nemožná.

Striktní podpora webových aplikací však přináší i problémy. Tam, kde se klientská aplikace může spolehnout na další služby počítače, na kterém je uživatelem spuštěna, musí webové servery zajišťovat veškerou podporu na své straně. Příkladem může být tisk grafických sestav, které není možné realizovat pomocí webového prohlížeče. Zpracování sestavy včetně komunikace s tiskárnou, na kterou si uživatel přeje tisknout tak na straně systému vyžaduje vyšší podporu. Výhodou ovšem zůstává skutečnost, že celý proces zpracování takovéto sestavy je pod kontrolou správce systému pro případ chyby.

Implementace systému založeného na webovém přístupu, který je určen pro masivní použití, však vyžaduje oproti běžným webovým aplikacím vyšší důraz na použité technologie. Ukazuje se jako nezbytné použít takovou platformu, která dokáže zajistit minimálně zdvojení každé komponenty systému pro případ výpadku. Násobením jednotlivých součástí systému (například vytvořením farmy fyzicky oddělených webových serverů) navíc můžeme efektivně zvyšovat propustnost a tím snížit odezvu na požadavky v případě rostoucí zátěže.

Násobení zdrojů a využití technologie klastrů v případě přístupu ke stejným údajům v systému vyžaduje sofistikované nástroje pro sdílení dat. Vzhledem k tomu, že současné databázové systémy běžně podporují transparentní násobný přístup ke stejným datům, mohla by být veškerá správa sdílených zdrojů přesunuta do této vrstvy. To značně usnadňuje zapojení klastrů na této úrovni, neboť v nejjednodušším případě lze pouze zajistit distribuci aplikací a systémového software (včetně distribuce aktuální konfigurace) na jednotlivé uzly klastru pomocí tzv. clusterware a nechat (opět nezávisle na více strojích) rozdělovat uživatelské požadavky mezi ně. Přesto se v případě masivního použití takového systému neobejdeme bez pokročilých funkcí. Zejména implementace vyrovnávací paměti na úrovni aplikačních serverů, která částečně přebírá funkci databázového subsystému, může v řadě případů velice zefektivnit celý proces zpracování uživatelských dotazů.

Posledním důrazem, který lze zmínit při úvahách o architektuře a praktickém nasazování základní platformy pro nástroje elektronické podpory výuky v organizaci většího typu, je metodika zpracování dat na úrovni aplikačních serverů. Ukazuje se, že pro dlouhodobější provoz a to jak z hlediska vývoje a správy aplikací, tak z hlediska efektivního zpracování při provozu, je důsledné oddělení aplikační a prezentační vrstvy. Řada projektů, které na tento problém nekladou dostatečný důraz, není prakticky škálovatelná a nelze je efektivně provozovat ve větším než lokálním měřítku.

2. Metody uložení a správy dat

Jak již bylo zmíněno, při zaváděný systému elektronické podpory výuky do skutečného provozu je třeba klást mimořádný důraz mimo jiné na způsob uložení a správy dat. Oproti jiným informačním systémům můžeme ve struktuře údajů evidovaných v rámci LMS specifikovat dvě základní třídy dat. První tvoří vysoce strukturované údaje a metadata běžné povahy, jako jsou informace o kurzech, vyučujících a posluchačích, různé učební záznamy, testy a informace o jejich průběhu. Druhou částí pak jsou samotné studijní materiály, které stále častěji obsahují objemná data, jako například video prezentace, fotografie s vysokým rozlišením, zvukové záznamy a podobně.

Pro uložení první zmiňované třídy dat lze z výhodou využít relačního modelu a nástrojů, které poskytují relační databázové systémy. Na trhu je v současné době dostupná široká škála těchto produktů. Přesto ne všechny databázové systémy jsou vhodné pro využití v jádře velkých systémů. Na rozdíl od aplikačních a webových serverů jsou zde i vlivem zmíněných vyšších nároků na tuto vrstvu velké rozdíly a výběr proto musí zohledňovat celkové potřeby organizace. Problematice databázového systému a tedy i této třídy spravovaných údajů se věnuje následující část našeho příspěvku.

Některé ze zmiňovaných databázových systémů poskytují velmi dobrou podporu bez ohledu na to, jakou třídu dat v nich uchováváme. Lze je proto nasadit a při správném užití běžně provozovat i například ve velkých systémech pro správu velkého množství materiálů pro výuku. Navzdory tomu tato cesta nemusí být vždy nejefektivnější. Samotný databázový software a příslušná nezbytná infrastruktura je z hlediska nákladů na pořízení a provoz velice drahá. V tomto případě však hraje roli struktura druhé třídy dat. Narozdíl od běžných údajů relačního schématu se jedná o statické objekty. To znamená, že drtivá většina přístupů k těmto údajům je pouze pro čtení. Navíc, a to je podstatné, jakákoliv změna v rámci takových souborů dat obvykle znamená náhradu celé jednotky (souboru).

Struktura dat druhé třídy tedy umožňuje jejich vyjmutí z hlavního subsystému správy dat a poskytnout k nim přístup jiným mechanismem, který nebude běžný datový provoz ovlivňovat. Jako vhodné se v tomto případě ukazuje nasadit některou z forem distribuovaného souborového systému, který umožňuje uložení v rámci skupiny nezávislých strojů spojených do jedné sítě. V prostředí třívrstvé architektury má tento přístup ještě jeden aspekt: servery aplikační vrstvy již samy o sobě tvoří takovouto skupinu počítačů, které však využívají pro práci s daty databázový server. Lokální data spravovaná v rámci jednoho uzlu se tedy při normálním provozu omezuje pouze na samotné aplikace a jejich vyrovnávací data. Posílením diskové kapacity těchto uzlů může dojít k velmi efektivní realizaci distribuovaného souborového systému. Lokální výpočetní kapacita, tak důležitá pro rychlý běh aplikací, však nebude výrazně omezena, neboť manipulace s daty tohoto typu není výpočetně náročná.

Konkrétní implementace distribuovaného úložiště dat tohoto typu však musí rovněž splňovat základní aspekty systému zmíněné v úvodu článku. Zejména je tedy nutné implementovat mechanismus replikace jednotlivých údajů pro případ, že by jeden z uzlů distribuovaného úložiště přestal z důvodu havárie svá data a volné kapacity poskytovat. Správná realizace zahrnující rovnoměrné rozložení všech dostupných zdrojů tedy vyžaduje sofistikovanější metody. Výsledkem však je efektivnější uložení velkého množství dat.

V praxi to znamená, že i v prostředí několika tisíců vyučujících, kteří chtějí ukládat svá stále objemnější data, může distribuované úložiště poskytnout rychlý přístup k velkému množství dat, který je prakticky limitován pouze rychlostí síťového spojení mezi klientským počítačem a LMS. Náklady na samotnou hardwarovou infrastrukturu ale zahrnují pouze příslušné pevné disky, neboť ostatní infrastruktura je plně sdílená s jinými částmi systému.

3. Databázový subsystém

Poslední součást architektury systému, které se chceme věnovat, je databázový subsystém. Jeho úkolem je uchovávat a poskytovat data ukládaná jednotlivými aplikacemi. Bez ohledu na distribuované úložiště zmíněné v minulé části systému je správná volba a nastavení této vrstvy doslova kritická pro bezproblémový nepřetržitý chod LMS. Ne každé dostupné řešení je však vhodné.

Prvním kritériem výběru je škálovatelnost výpočetního výkonu. Zdaleka ne všechny databázové platformy jsou schopny uspokojivě zvyšovat svůj výkon při zvýšení počtu procesorů. Některé dokonce běh na víceprocesorových architekturách přímo nepodporují. Zkušenost z různých nasazení ukazuje, že právě nedostatek výpočetní kapacity pro zpracování dat vede k výrazně nepříjemnému zpomalení činnosti celé aplikace.

Databázový software je rovněž obecně více náročný na robustnost. V praxi se často setkáme s řešením, které při větší zátěži nejenže přestává vyhovovat výkonově, ale není schopno velké množství změn v údajů zpracovávat konzistentně v případě výpadku a mnohdy ani v případě běžného provozu.

Hlavním kamenem úrazu je nicméně opět deklarované zdvojení všech částí systému. Tak jako ostatní komponenty obsahovaly mechanismus přebírání požadavků v případě výpadku, rovněž služby databázové vrstvy musí zůstat poskytovány pokud možno nepřetržitě. V případě sdílení dat mezi jednotlivými uzly případného databázového klastru je zajištění současného přístupu z několika strojů řádově náročnější. Většina databázových produktů proto tuto funkcionalitu nepodporuje. Alespoň částečně je tak nutné se spokojit se záložními servery, které disponují transparentním přístupem k samotné databázi (sdílenému diskovému subsystému) dokáží spustit svoje služby v případě chyby v rámci produkční instance(2). Taková operace se však neobejde bez výpadku a nevyužívá plně kapacitu záložní instance.

Samotné nasazení databázového klastru však ještě neřeší všechny nároky kladené na tuto vrstvu. Podobně jako přechodem z jednoho webového serveru na farmu aplikačních uzlů získáváme navýšení výkonu, některé architektury umožňují prostým přidáním další databázové instance rozložit zátěž mezi více (typicky levnějších) strojů. Tato moderní dosud nepříliš široce využívaná technologie však nemusí být optimální pro jakoukoliv aplikaci. Zejména systém podpory výuky, který zpracovává často velice různorodé požadavky uživatelů striktně v reálném čase, může při použití v konfiguraci s databázovým klastrem vykazovat velikou komunikační režii, která způsobuje snížení odezvy celého systému.

Pro řešení tohoto problému se ukazuje jako nejvhodnější využít techniky tzv. víceúrovňových klastrů, kdy je databáze obsluhována ze dvou (případně více) instancí, přičemž hlavní (nikoliv však veškerý) provoz je směřován vždy na jednu z nich. Každá instance je pak tvořena klastrem fyzicky oddělených uzlů nižší (hardwarové) úrovně. Tento klastr je transparentní vůči operačnímu systému a tedy i samotné instanci. Lze jej realizovat prostředky poskytujícími dostatečnou propustnost pro sdílení dat mezi procesy v rámci jedné instance, čímž nedochází ke komunikačním prodlevám jako v případě běžných klastrů. Výkon primární instance může být navíc optimalizován pouhým přidáním (odebráním) jednotlivých uzlů klastru nižší úrovně.

Posledním aspektem výběru databázové platformy resp. jejího začlenění v rámci celé architektury je její odolnost vůči dočasným přetížením. V systémech poskytujících služby prostřednictvím sítě Internet potenciálně velkému množství uživatelů nastávají chvíle, kdy současný přístup mnoha klientů typicky k jedné aplikaci nejenže sníží odezvu této aplikace, ale i zbytku systému. Správné nastavení databázového prostředí hraje pak klíčovou roli při zvyšování propustnosti celého systému, neboť optimalizace na tyto špičky formou navýšení výpočetního výkonu jednotlivých počítačů je obvykle neefektivní.

4. Shrnutí

Cílem tohoto příspěvku bylo upozornit na některé technické aspekty procesu zavádění elektronické podpory výuky v rozsáhlých heterogenních organizacích. Vedle ostatních problémů je to jeden z důležitých prvků, jehož podcenění může být dle zkušeností autorů pro úspěch celého řešení velmi nebezpečné. Záměrem nebylo přednést řešení konkrétních technických realizací, ale spíše upozornit na některé nepříjemné důsledky, které mohou ze špatných koncepčních rozhodnutí v této oblasti vzniknout.

1) Informační systém Masarykovy univerzity v Brně (IS MU) je studijní systém, který slouží mimo jiné také jako centrální systém pro elektronickou podporu výuky (LMS). Je vyvíjen Masarykovou univerzitou a provozován také na několika dalších školách v České republice. Denně se systémem pracuje přibližně 15 000 uživatelů.

2) Termínem databázová instance značíme množinu procesů v rámci jednoho běhu operačního systému, které slouží k obsluze jedné databáze.