Informační systém MU: architektura a implementace v rozsáhlém prostředí velké organizace

Michal Brandejs, Miroslav Křipač

článek na konferenci Datakon 2007 (20. – 23. 10. 2007)

Abstrakt: Masarykova univerzita již devátým rokem provozuje vlastní jednotný systém na evidenci a celkovou elektronickou podporu studia. Jedná se o striktně webový on-line informační systém s přímým přístupem přibližně 40.000 aktivních uživatelů a bezprostřední propagací změn v datech na všech úrovních. Cílem této přednášky je seznámit posluchače s hlavními principy architektury systému. Během prezentace budou rovněž diskutovány výhody, úskalí a získané praktické zkušenosti s principem distribuovaného ukládání dat, které se stává v poslední době populárním. Představeno tak bude několik produkčně používaných metod ukládání dat včetně využití databázových clusterů, plně distribuovaných datových úložišť a technologií z oblasti tzv. High-Performance Databases.
Klíčová slova: Informační systém Masarykovy univerzity, databázové systémy, databázove clustery, webové systémy.

1. Úvod a motivace

Informační technologie podporující základní chod velkých organizací nebo podniků se postupem času staly běžnou a zejména nezbytnou součástí našeho života. Bez snadno dostupných elektronicky evidovaných údajů se neobejdeme. Ne vždy je však implementace složitých procesů tak úspěšně použitelná v malém prostředí snadno rozšiřitelná do heterogenních prostředí rozsáhlých organizací. Jeden z prvních přirozených požadavků na takový systém je přístupnost údajů pro kohokoliv. Počítačový systém, který eviduje důležité údaje není již v praxi dostačující ve chvíli, kdy tyto údaje jsou přístupné (byť plně elektronicky) pouze jednomu nebo několika málo vybraným pracovníkům, kteří se pak stávají nutnými prostředníky pro ostatní uživatele, kteří data skutečně využívají. Například finanční účtárna se může stát úzkým místem pro efektivní správu finančních toků ve chvíli, kdy bude jako jediná schopna zadávat do elektronického systému data a číst z něj výstupy. Ve skutečnosti je potřeba, aby každý člen organizace mohl zadávat finanční operace na které má právo a číst výstupy, které z nich plynou. Tento přirozený a snad dnes již úsměvný požadavek však není jednoduché ve skutečnosti implementovat takto doslova. Jak navrhnout systém, který bude umožňovat plný přístup k úplně všem kritickým údajům nejen pro deset ale i pro tisíc nebo deset tisíc lidí? Jak takový systém nasadit a jak jej udržet v chodu? Jak pružně a nejlépe obratem reagovat na závažné softwarové chyby? Druhým kritickým požadavkem je rychlost zpracování dat. Jaký čas je ještě akceptovatelný pro zpracování transakce nad daty, které potřebujeme evidovat, abychom se dozvěděli výsledek? Stačí pro naše interní procesy tři dny, které stačí bankám pro plně elektronicky zadaný přenos peněz z jednoho běžného účtu na druhý? V případě velkých organizací se pak setkáváme s dalšími problémy, které musí informační technologie podchytit a podporovat. Tím je například organizační struktura, řízení a vůbec celková vnitřní provázanost. Stačí zmínit přínos, který přináší jednotné informační prostředí bez ohledu na to, ve které části (oddělení, pobočce, závodu) k údajům přistupujeme. Propojování dat (a s nimi souvisejících znalostí) napříč různými (a v principu dost odlišnými) částmi rozsáhlé heterogenní organizace vede k usnadnění nejen vnitřních procesů, ale zejména k jednotnému a transparentnímu fungování navenek a tím i k výraznému zkvalitnění poskytovaných služeb pro koncové zákazníky nebo uživatele. Toto jsou jen některé z problémů, které stojí také za motivacemi pro zavedení plně elektronizované podpory výuky na Masarykově univerzitě. Ta je v současné době realizovaná pomocí tzv. Informačního systému Masarykovy univerzity (IS MU). Konkrétně tedy každý uchazeč, student, absolvent, učitel či zaměstnanec administrativy (studijní referent, ekonom ale i vedoucí na všech úrovních) má přímý přístup do systému s možností plného ovlivnění (ale také plné zodpovědnosti) všech dat, které souvisí s jeho posláním na univerzitě. Samozřejmostí tak jsou nejen plně elektronizované výkazy známek (dříve známé jako indexy) a další evidence (seznamy studentů v daném kurzu, přihlášených ke zkoušce), které jsou už dávno evidovány výhradně elektronicky, ale i jejich naprostá vzájemná provázanost. Evidence těchto dat je pak prováděna striktně on-line. To znamená, že pokud například student v určenou dobu projeví zájem o studium konkrétního předmětu, systém sám vyhodnotí celou řadu obecně složitých předpokladů a v případě úspěchu zaeviduje studenta jako řádně zapsaného k danému předmětu. Student se tak ihned dozví případné důvody, proč si daný předmět právě on zapsat nemůže, neboť důvody jsou zcela individuální. Vzniká tak rychlá a přesná evidence, která navíc podporuje zmiňovanou integraci napříč velmi různorodých součástí. Není administrativně složité, aby si například student specializující se na mezinárodní obchod navštěvoval oficiálně v rámci svého studia kurz japonštiny, který je vyučován v jiné části města apod. Toto jsou pouze některé základní principy, na kterých IS MU dnes funguje. Samozřejmostí jsou i další služby jako je elektronická podpora samotné výuky (on-line testování na počítači přímo v IS MU včetně udělení známky, scanování a rozpoznání písemných testů, systém pro odhalování plagiátů ve studentských pracích, multimediální výukové materiály), bezpečná správa a vyhledávání v dokumentech, správa identifikačních karet a přístupů, komunikace (e-mail, akademické i volné diskuse, elektronické nástěnky) a v poslední době také podpora pro on-line prodej vzdělávacích aktivit široké veřejnosti. Všechny tyto a mnohé další služby těží z jednotného plně sdíleného prostředí, které přináší zmiňované vlastnosti včetně široké dostupnosti a rychlé propagace změn. Na druhé straně však implementace takového systému včetně dosažení vysoké stability systému a nezbytné reakce na různé formy přetížení vyžaduje řadu různých implementačních rozhodnutí, které budou diskutovány v následujících kapitolách.

2. Architektura systému

Základem architektury systému je plně webové prostředí pro všechny uživatele bez rozdílu. Pokud odhlédneme od komunikace s ostatními systémy univerzity, není do systémy možný jiný přístup, než pomocí webového prohlížeče. Bez ohledu, zda se připojuje student z mobilního telefonu na prázdninovém pobytu, nebo referentka provádějící různorodé datové operace po celou pracovní dobu z vlastní kanceláře, vždy je přistupováno pomocí webového prohlížeče. Základní výhoda tohoto přístupu spočívá ve velmi snadné správě a údržbě aplikací. Na straně koncového klienta je nutná pouze běžná podpora pro standardní prohlížeč, která často nepřináší další náklady oproti běžné správě výpočetní techniky. V prostředí, kdy i zmíněných referentů jsou řádově stovky nebo tisíce, Jakákoliv změna v aplikaci je pak propagována všem a ihned, což přináší v podstatě největší možnou flexibilitu vůči reakcím na chyby všeho druhu a tím i požadovanou stabilitu. Druhou výhodou je samozřejmě přístup z libovolného místa připojeného do Internetu, kterou stále častěji využívají nejen uživatelé pro prezentační část, ale i ti, kteří se systémem pracují velmi intenzivně (například práce z domova apod. ). Naopak tento přístup přináší také řadu úskalí. Ve chvíli, kdy podnikový informační systém stavíme primárně na klasických aplikacích a webové rozhraní použijeme pouze pro prezentaci nebo sběr základních údajů nezpracovaných on-line, je možné mnohem přesněji určovat požadovaný výkon a optimalizovat chování aplikací při zátěži. Obecně otevřený webový systém jakým je IS MU se tak mnohem snadněji stane terčem problémů souvisejících s přetížením a nebo naopak většinu doby jeho hardwarové kapacity nejsou využity. V takovém případě je nutné využít další sofistikovaná řešení pro řízení přetížení, která jsou nad rámec této přednášky. Nespornou nevýhodou webových řešení je pak složitější přizpůsobení uživatelských rozhraní pro snadné zadávání velkého množství údajů a podpora dalších periferií (jako například kvalitní grafické výstupy a tisk obecně), které jsou v tomto případě složitější, než s využitím standardizovaných rozhraní operačních systémů. Jiný je rovněž náhled na zajištění bezpečnosti systému, se kterou je také nutné počítat.

3. Základní komponenty systému

Kromě běžných webových prohlížečů, které se také nemalou měrou podílejí na chodu systému a zpracování aplikací jsou všechny součásti systému plně pod kontrolou Vývojového týmu IS MU, který zajišťuje také samotný provoz systému. Ten je pak umístěn na několika základních místech v budovách univerzity po městě Brně. Základní jádro systému je pak připojeno do sítě CESNET a tím i do Internetu dvěma obecně nezávislými linkami. Ty jsou obsluhovány nezávislými routery, které se starají také o primární ochranu vnitřní sítě IS MU například na paketové úrovni. Další sada strojů, tzv. brány, slouží při vzájemné zástupnosti pro distribuci požadavků klasického HTTPS spojení na aplikační servery. Cluster aplikačních serverů pak provádí jak zpracování HTTPS komunikace (včetně šifrování a reakcí na nestandardní stavy), tak běh aplikací, které jsou přímo navázány na jednotlivé fáze zpracování HTTPS požadavků. Kromě mechanismu lokálních vyrovnávacích pamětí jsou data, se kterými aplikace pracují, přístupná na další vrstvě, databázovém serveru. Ten je realizován jako jeden systém se sdílenou pamětí a jeho princip je popsán dále. Kromě těchto základních součástí jsou v rámci provozu IS MU k dispozici další servery například pro automatický převod různých formátů dokumentů (formáty Microsoft Office, OpenOffice, PDF, běžný text), fulltextové vyhledávání, generování sestav, přesné a bezpečné vyhledávání podobností v dokumentech, zálohování a zabezpečení včetně automatické antivirové ochrany nad uloženými dokumenty. Základním a v současné době téměř jediným využitým operačním systémem na všech serverech je Linux ve dvou různých distribucích. Jako webový server je použit Apache HTTP Server a aplikace využívají vlastní aplikační prostředí v jazyce Perl. Databáze je spravována pomocí produktu Oracle Database ve verzi Enterprise Edition.

4. Distribuce dat

Základním předpokladem pro zpracování dat uvnitř IS MU je sdílení všech potřebných údajů napříč všemi součástmi. Tím dochází k bezprostřední propagaci změn a jednodušší správě jednotlivých údajů. Na druhou stranu sdílení údajů může vést ke snížení spolehlivosti v případě chyby (výpadku) v některé z kritických částí sdíleného systému a zároveň ne vždy lze snadno navýšit potřebné zdroje (ať už disky pro samotné uložení dat nebo výpočetní součásti jako procesory a paměti pro jejich zpracování). Z pohledu zpracování dat využívá IS MU dvou základních přístupů. První z nich slouží pro zpracování velice strukturovaných dat s velmi častou frekvencí změn. Tato data jsou všechna plně spravována pomocí databázového systému Oracle Database s využitím vlastního mechanismu vyrovnávací paměti na straně aplikačních serverů pro data, která jsou velmi často čtena, ale málo měněna. Příkladem takových dat je seznam studentů navštěvujících daný kurz nebo samotné údaje o kurzu. Druhý typ údajů představují rozsáhlé dokumenty a jiná objemná data, které je potřeba ukládat jako celek (nejsou vnitřně strukturovaná z pohledu systému), neprovádí se v nich změny přímo, ale systém slouží pouze jako prostředník pro jejich uchování a sdílení. Pro tento typ údajů slouží v IS MU speciální distribuované úložiště, které pomocí vlastní infrastruktury ukládá tyto dokumenty na disky jednotlivých aplikačních serverů, které by jinak zůstaly téměř nevyužity. Tímto způsobem dochází jednak k velmi efektivnímu využití (a případnému nárůstu) diskové kapacity a jednak k optimální distribuci zátěže při masivní práci s těmito dokumenty. Každý dokument pro případ výpadku je pak uložen na nejméně dvou uzlech. Příkladem dat v distribuovaném úložišti jsou studentské práce (obecně textové, tabulkové a další dokumenty), multimediální výukové materiály či celé obrazy kompaktních disků používaných ve výuce. Výhody, které skýtá interní distribuce dat uvnitř navenek integrovaného systému se sdílením všech dat, je možné využít také pro data relačního typu. Zejména v poslední době k tomuto účelu vznikají různá řešení databázových systémů obecně označované jako databázové clustery. Nabízí se tedy otázka, proč IS MU v současné době nevyužívá toto řešení také pro ostatní typy dat. Prvním cílem pro nasazení databázového clusteru pro zpracování dat je zvýšení dostupnosti v případě chyby uvnitř datového systému. Tato myšlenka předpokládá, že v případě chyby například v hardware databázového serveru je k dispozici druhý server, který je okamžitě schopen převzít provoz a obsluhu aplikačních serverů. Za tímto účelem je však nutné použít tzv. databázové clustery se sdíleným diskem, který předpokládá, že data z chybného uzlu budou dostupná i z dalších uzlů. Omezení, které toto řešení ale nabízí, je v případě rozsáhlých systémů dáno celkovým objemem zpracovaných dat, které je nutné při „překlopení“ načíst na náhradní uzel. V případě systémů typu IS MU, a tyto zkušenosti potvrzuje i řada autorů dalších rozsáhlých databázových řešení, je celková doba na načtení všech potřebných dat natolik velká, že systém fakticky během této doby není schopen zajistit rozumné fungování stejně, jako je tomu v případě hardwarové rekonfigurace (restartu) vadného uzlu. Při zvažování zvýšení dostupnosti je také nutné brát v úvahu velké navýšení složitosti databázového clusteru oproti systému s jednou instancí a dále pak celkové vysoké vnitřní propojení všech uzlů v clusteru, které může vést k propagaci naopak softwarové chyby na všechny uzly clusteru. Teoretická výhoda „nezávislosti“ clusterů se tak v praktickém provozu stává naopak zdrojem dalších chyb a výpadků. V neposlední řadě pak do uvažování o skutečném nasazení databázových clusterů pro zvýšení dostupnosti vstupuje celková cena za takové řešení daná nejen cenou za databázové licence. V případě clusterů s vysokým výkonem je totiž nezřídká výhodnější použít „nekomoditní“ hardwarové řešení, které obsahuje řadu vlastností pro zvýšení výkonu včetně on-line výměny vadných komponent bez nutnosti výpadku celého systému, fyzického oddělení základních částí apod. Druhou výhodou pro obecné použití databázových clusterů je navýšení výkonu. V případě, že výkon stávajícího počtu uzlů nedostačuje, je velmi jednoduché přidat další uzel do clusteru. Toto řešení, které úspěšně funguje na aplikační úrovni (a zde to i IS MU hojně využívá), je však velmi závislé na nutnosti zajištění konzistence mezi masivně paralelním čtením a zápisem dat na různých uzlech současně. Toto softwarové zajištění konzistence, které musí nutně provádět databázový server, výrazně zvyšuje režii potřebnou pro běžný chod aplikace. U on-line přepočítávaných dat je pak tento způsob zpracování při masivním přístupu uživatelů přirozeně výrazně méně výkonný, než přístup do sdílené paměti realizovatelný hardwarově. Z tohoto důvodu IS MU opustil v minulém roce koncepci databázových clusterů a soustředí se plně na tzv. „vertikální distribuci dat“ v rámci jednoho „single system image“ řešení. Za tímto účelem byla využita technologie SGI Altix z oblasti tzv. High Performance Databases, která umožňuje, podobně jako databázové clusteru, jednoduchým přidáním uzlu do systémové infrastruktury navyšovat a případně přesouvat výkon mezi různými částmi systému a to transparentně vůči databázovému software. Zároveň umožňuje vícenásobné zařazení všech komponent nutných pro běh systému tak, aby i v případě výpadku jakékoliv komponenty byl zajištěn provoz poskytovaných služeb pouze s minimálním omezením výkonu.

5. Závěr

V tomto příspěvku jsme se pokusili ilustrovat aktuální praktické zkušenosti s provozem velkého systému pro desítky tisíc uživatelů. Jistě není možné obsáhnout všechny aspekty celého řešení. Vedle principů zvolené architektury a jejich motivací jsme se proto zaměřili na klíčovou oblast z hlediska správného a efektivního fungování, čímž je správa dat. Podle našich aktuálních znalostí se ukazuje, že oproti všeobecně prosazovanému trendu zavádění databázových clusterů a podnikových gridů, není v řadě zejména rozsáhlých integrovaných systémů distribuce dat tímto horizontálním způsobem přínosná. Naopak existují alternativy, které přináší pro praktický provoz více možností.