Donedávna se provozování ERP aplikací (SAP, Oracle Financials apod.) trend konsolidace a virtualizace tak trochu vyhýbal a pro každý modul byl využíván vyhrazený, správně „dimenzovaný“ server, tj. připravený na maximální plánovanou zátěž. Ta se však většinou plně využívá jen po zlomek provozní doby.
V lepším případě jsou s využitím hypervizorů, jako např. VMware, odděleny aplikace běžící na operačním systému od fyzických serverů. Správa většího počtu takto virtualizovaných, či chcete-li logických, serverů současně se správou serverů fyzických, však pracovníkům IT každodenní práci neubírá, spíše naopak. Stále více začíná být zřejmé, že virtualizace sice ušetří investiční výdaje, protože se efektivněji využije pořízený hardware, ovšem nároky na provoz a správu takových systémů jsou díky rychlému nárůstu virtuálních serverů podstatně vyšší. Vytvoření každého dalšího logického serveru totiž znamená starost o nový operační systém, instalovanou aplikaci, event. databázi – s četností záplat, aktualizací či nových verzí pak může být provoz celého systému noční můrou svých správců.
Existují však i řešení, která k provozu podnikových aplikací přistupují z pohledu dostupnosti aplikace a zároveň berou ohled na náklady při provozu. Co je k tomu potřeba? Základem pružné infrastruktury pro běh ERP aplikací je několik poměrně jednoduchých myšlenek:
výkon jednotlivého aplikačního modulu lze díky současným vlastnostem databází zvýšit spuštěním stejného modulu (další instance) na dalším serveru, ať už fyzickém či logickém;
virtualizovat – tedy oddělit aplikaci od vyhrazeného hardwaru – lze také na úrovni aplikace, kdy s pomocí virtuálních IP adres, virtuálních hostname a virtuálních proměnných lze aplikace přesouvat z virtuálního prostředí jednoho sdíleného operačního systému do virtuálního prostředí identicky vypadající jiné instance stejného operačního systému (tato forma virtualizace je známa např. z oblasti clusterových služeb);
pokud jsou sdílený operační systém, databáze i aplikační moduly – přesněji jejich „image“ – uloženy na externím úložišti, redukuje se jejich správa (aktualizace, záplaty apod.) na jednu jedinou verzi jejich obrazů a zároveň pro účely jejich zavádění na jednotlivé servery mohou být v režimu „jen pro čtení“, což dále zvyšuje bezpečnost;
obnova běhu aplikace, tj. zavedení operačního systému, databáze i aplikace z NAS úložiště na libovolném dostupném serveru (síťové zavedení) v rámci takto virtualizovaného síťového prostředí je otázkou několika minut.
Pokud jsou obraz operačního systému, databáze, spustitelné soubory aplikačních modulů i data aplikací uložena na externím úložišti a na serveru kromě dočasných souborů žádná data uchovávána nejsou, je prostředí pro běh aplikace na serveru vytvářeno pokaždé znovu od začátku a bude vždy identické bez ohledu na to, na kterém serveru bylo vytvořeno. Stačí pouze připravit potřebný souborový systém a vzhledem k tomu, že na stejném rozhraní může být více IP adres a rovněž protože různé aplikace mohou běžet pod více uživatelskými účty, lze paralelně vytvářet různá prostředí v rámci jednoho operačního systému. Takto lze spouštět různé aplikační služby současně na stejném serveru.
Je-li tedy aplikace napsána tak, že jednotlivé aplikační služby mohou být rozděleny do jednotlivých instancí, lze pak při zátěži aplikace pružně přidávat výkon jednoduchým spouštěním další instance jednotlivé služby — samozřejmě pokud jsou ještě dostupné volné výpočetní zdroje ve sdíleném serverovém prostoru. Vzhledem k tomu, že požadavky na výkon jednotlivých aplikačních služeb, nebo chcete-li modulů, se v průběhu dne většinou mění, lze přidávat či ubírat jejich výkon prostým spouštěním či zastavováním příslušných instancí podle okamžité zátěže.
Příprava nového virtuálního prostředí na libovolném serveru je otázkou jednotek minut, není proto v takto vytvořené dynamické infrastruktuře třeba budovat plně redundantní hardware, a přesto je reálná dostupnost aplikace srovnatelná s clusterovými řešeními již při konceptu N+l výpočetních zdrojů. Pořizovací cena redundantního hardwaru samozřejmě není zanedbatelná. Ovšem především odpadají náklady na testování při jakékoli změně konfigurace, protože pokud je uložené prostředí jednou na libovolném standardním serveru spuštěno, je na rozdíl od clusteru zaručeno, že poběží i na serveru jiném. Posílení výpočetní kapacity sdíleného serverového prostoru v takovém prostředí pak prakticky nemá nic společného s aplikací samotnou a jde jen o rutinní kabelování a síťovou konfiguraci — takto přidaný server lze pak okamžitě začít používat.
Pokud k výše popsané architektuře přidáte systém automatických pravidel, která určí, na kolika výpočetních zdrojích se má který modul v daném čase spustit, nadefinujete další pravidla pro případ výpadku libovolného serveru – např. přesun aplikace na volné zdroje či krátkodobé zastavení testovacích a vývojových prostředí a spuštění produktivních modulů na jejich úkor – dostanete adaptivní systém, ve kterém je zkrácen čas na implementaci celého systému z týdnů na dny a běžná údržba ze dní na hodiny. Bezpečnost a vysokou dostupnost (High Avaibility, Disaster Recovery) přitom lze dosáhnout např. zrcadlením úložiště a řídicí konzole s uloženými skripty a nastavením virtuálního prostředí (pravidly) na oddělených místech. Kromě úspor při správě systému nabízí takovéto řešení mnohem flexibilnější možnosti pro rekonfiguraci a díky tomu schopnost rychle přizpůsobit firemní procesy potřebám trhu, což je v současnosti jedna z největších konkurenčních výhod, kterou podnik může mít.
Řešení v rámci výše uvedeného konceptu již řadu let úspěšně provozuje několik stovek firem, a to nejen koncových zákazníků, ale díky možnosti snadného oddělení jednotlivých virtuálních prostředí, zabudovanému monitoringu a transparentnímu účtování za skutečné využití výpočetních zdrojů pro běh ERP aplikací (např. podle využití CPU či spotřeby SAPS) jsou hojně využívány rovněž v hostovacích centrech IT poskytovatelů, kteří takto mohou nabídnout levnější služby svým klientům. Jedna infrastruktura totiž může být současně využívána více zákazníky. Úspory při provozu se průměrně pohybují na úrovni 30 procent, návratnost investice je proti tradiční architektuře vyšší o 20 až 50 procent, podle konkrétních podmínek dané implementace.
PŘEDPLATNÉ
ČLÁNKY DO MAILU