A vállalati, kutatásfejlesztési és oktatási környezetekben egyaránt nagy kihívást jelent az információs követelményeknek megfelelő szoftverpark kialakítása. Ezen a téren jelent óriási előrelépést a felhőalapú információtechnológiai környezet létrehozása. A felhőalapú információtechnológiai környezetek több szinten kínálnak virtualizációs és dinamikusan skálázható informatikai megoldásokat: IaaS, PaaS, SaaS. Ezek rendre az infrastruktúra-, a platform- illetve a szoftverhozzáférést biztosítják a felhőben.
Mostanra a kínált termékpaletta kiszélesedett egy olyan szintre, hogy több választási alternatívánk van egy adott felhasználási célra. Esetemben egy olyan több kurzust együttesen kezelő, dinamikusan igényelhető kurzuskörnyezeti példányokat kezelő oktatási infrastruktúra kiszolgálását kellett megoldani, ahol a megoldásra szánt büdzsé erősen korlátozott volt. A kurzusok között találhatunk számítógépes tervezés (CAD), vállalatirányítási rendszerek (ERP), elektronikai technológia kísérletek, vállalati alkalmazások integrációjának (EAI) és vállalati jelentéskészítés oktatását segítő környezeteket is. Szintén fontos szempont volt, hogy a felhőalapú virtualizáció és a lokális virtualizáció között szabad átjárást biztosítsunk és több futtató szoftveren is elindítható legyen a virtualizált környezet.
Nyilván a sok lehetőség és a sok környezeti feltétel együttesen rengeteg megvalósítási és eszközkombinációs lehetőséget hordoz magával. Az ezzel kapcsolatos vizsgálódásaim ezen korai fázisában ezért az alapvető megközelítés kiválasztására koncentrálok és az ehhez kapcsolódó konfigurációs és fejlesztési feladatok megfogalmazására.
A felhőalapú környezet kiválasztása és felépítése
A dinamikusan konfigurálható és az oktatási infrastruktúra által megkövetelt laborkörnyezet kiválasztásának első döntési tényezője a nyilvános vagy privát felhőmegoldás választása. A nyilvános felhőmegoldás talán a jobban ismert, amikor is a virtualizált környezet kikerül a közrebocsátó vállalat falain kívül és egy külső szerverinfrastruktúrán fognak majd a virtualizált környezet példányai futni. Ez a kényelmesebb megoldás, hiszen a futtató környezet karbantartása és a szükséges konfiguráció egy jelentős része áthárul a szolgáltatóra. Nyilván ezen áthárított teher felvállalása nem térítésmentesen történik a szolgáltató részéről. A virtualizált környezeteknek biztosítják azt a lehetőséget, hogy nagyon pontosan nyomon követhessük erőforráshasználatukat. Ez lesz a szolgáltató számlázásának alapja.
A nyilvános felhőmegoldással szemben a privát éppen az imént tárgyalt területen tér el elsősorban: nekünk kell futtatni és konfigurálni, viszont a szolgáltató sem küld számlát. Ez persze korántsem jelenti azt, hogy ilyen környezetek üzemeltetése ingyen lenne, hiszen az energiafelhasználást és az eszközamortizációt nekünk kell finanszírozni. A nyilvános esetben ezek a költségek beépülnek a szolgáltatás árazásába. A célkörnyezetemben, a limitált büdzsé és az időszakos terhelés miatt, privát felhőépítési megoldás felépítésére került sor.
A második fontos döntés a virtualizálás szintje, a felhőszolgáltatás típusa. A legkényelmesebb megoldás, ha az összes szoftvert elérhetnénk felhőben, így az összes kurzusrésztvevő dinamikusan férhetne hozzá az adott foglalkozáson szükséges programokhoz. Sajnos ennek az ideális helyzetnek több feltétele sem biztosított. Először is az asztali szoftverek jelentős rész nem elérhető ebben a formában, ráadásul sokszor a virtualizált környezet elemeihez is hozzá kell férni egy-egy foglalkozás alkalmával. Lehetne még a platformot virtualizálni, azonban itt egy másik probléma merül fel: a használt szoftverek nem képesek a platform által megkövetelt interfészeket használni, jelentős részük pedig kifejezetten normál operációs rendszerre történő telepítést igényel. Ráadásul a PaaS nem is lenne szerencsés választás, mert jellegénél fogva elsősorban a nyilvános felhőt célozza, holott esetünkben a privát megoldásra esett a választás. Maradt tehát az infrastruktúra-alapú felhőszolgáltatás, amely maradéktalanul eleget is tesz az oktatási környezet által támasztott követelményeknek: a külön kezelt, operációsrendszer-szinten konfigurálható környezet lehetővé teszi tetszőleges szoftver telepítését, ráadásul a virtualizált környezet elemeihez is könnyen hozzáférhet a kurzusrésztvevő. Az elérhető termékek közül az Apache CloudStack adta a legköltséghatékonyabb alternatívát, amely a földrajzilag elkülönült helyszínek mindegyikén gond nélkül telepítésre került.
A megvalósítandó esetben ugyanis a privát felhőszolgáltatást több helyszínről kell biztosítani, azonban az egyes partnerintézmények felhőtelepítései között a kollaborációt szintén biztosítani kell. Ebben a felállásban, magukat a helyszíneket azonosítjuk a felhő csomópontokkal, amelyeket integrálni szükséges. Azonban az integráció csak úgy mehetett végbe, hogy az eredményül kapott rendszer ugyanúgy skálázható, robosztus, nagy teljesítményű és magas rendelkezésre állású legyen, mint az azt felépítő felhőtelepítések. Ilyen integrációra többféle lehetőség is adódott.
Egyrészt, ha minden konfigurációs beállítás és munkaadat szinkronizálható az egyes felhő csomópontok között, akkor a felhő csomópontok összességére úgy tekinthetünk, mint egy egységes felhőalapú rendszerre: hardvererőforrások és virtuális gépek transzparensen és átjárható módon allokálható egészére. Ez a megoldás tökéletes mind hibatűrőképesség, mind terheléskiegyenlítés, mind pedig a központi menedzselhetőség szempontjaiból. Sajnos ezt a felállást az Apache CloudStack nem támogatja. Bár az előzetes felmérés során azonosításra kerültek azok az egyedi fejlesztések, amelyek lehetővé tennék a szükséges adatok és beállítások hozzáférhetőségét és valós idejű migrációját, a fejlesztés és az eredmény komplexitása nem megtérülő befektetésként jelentkezett.
Ezért második megoldásként egy olyan integrációs megközelítés került megvalósításra, amely fokozottan épít az Apache CloudStack szolgáltatásaira. A rendszer által támogatott régióelv ugyanis lehetővé teszi a CloudStack zónák alapvető vezérlőadatainak megosztását egymás közt. Ebben a felállásban nyílik lehetőség a felhő csomópontokat, mint CloudStack zónák megvalósítására. Így az egyes zónák felhasználó- és jogosultságkezelése egységes lesz a megosztás által és az egyes partner csomópontoknak könnyen hozzáférés biztosítható más csomópontokon tárolt állományokhoz.
Eredmények
Összességében elmondható, hogy sikerült egy olyan felhőmegoldást kiválasztani és létrehozni, amely támogatja az oktatási infrastruktúrákat és a földrajzilag elkülönült felhő csomópontok integrációját. Ez a megoldás működik, de a koncepció finomhangolására még szükség van: egyrészt a szükséges adattranszfert lehetne jobban automatizálni, másrészt a nyilvános hálózaton közlekedő adatok biztonságát kellene megoldani, harmadrészt a kellő időben történő rendelkezésre állást biztosítani szükséges. Az egyes kurzusgyakorlatokon mért szerverterhelés kielégítőnek mondható, azonban a virtualizált környezet erőforrásigényes folyamatainak elindítása több gépről egyszerre látványos terhelésnövekedést von maga után.
Készítette: Villányi Balázs
Kelt: Budapest, 2017. szeptember 28.