A mai informatika törekszik arra, hogy az üzemeltetés és a felhasználás sok éve fennálló egyik problémakörét megoldja: hogyan lehet agilis informatikai szolgáltatásokat nyújtani és igénybe venni úgy, hogy ne függjünk adott technológiáktól, illetve konkrét erőforrásoktól, mivel a túlzott függés nemcsak hogy csökkenti a szabadságfokainkat, de a pénztárcánkra sincsen túl jó hatással.
Feltehetjük a kérdést, hogy miért nem jó a szoros függés adott technológiáktól és erőforrásoktól, hiszen a klasszikus gyártók átfogó szoftvermegoldásokat kínálnak, és borsos árért ugyan, de minden problémára házon belüli és teljes körű megoldást nyújtanak. Azonban ha végiggondoljuk a minket körülvevő vállalati informatika elmúlt harminc évét, akkor rájövünk, hogy ez eddig még senkinek sem sikerült. Ha sikerült volna, akkor egyre homogénebb rendszerekkel dolgoznánk, a valóságban azonban inkább a heterogén rendszerek terjednek, és minden célra az éppen legmegfelelőbb eszközt választjuk. Mi lehet ennek az oka?
Együtt az igényekkel
Az okok többrétűek, azonban magától értetődők is. Egy vállalat informatikája egy állandóan változó igényeket kiszolgáló, szervesen formálódó, folyamatosan alakuló rendszer. Ehhez a működésmódhoz jobban illeszkedik egy agilis, kisebb, autonóm részekből álló megoldás, amely ben az egyes elemeket a változó külső vagy belső igények függvényében könynyen lehet cserélni, bővíteni. Hektikusan hullámzó világunkban nem lehet megmondani, hogy a változásokra, bővítésekre pontosan mikor és milyen terjedelemben lesz szükség, azonban az informatikai rendszer agilitása, azaz gyors reakcióképessége ma is az egyik legkívánatosabb tulajdonsága. A hosszú távú előretervezés helyett ezért arra kell felkészülnünk, hogy amikor az igény fellép, az akkor legkedvezőbb árú és az adott igényt a legjobban kiszolgáló elemet szerezzük be, majd azt a legrövidebb idő alatt integráljuk, az üzleti folytonosság megszakadása nélkül. Ezt egy teljesen homogenizált rendszer sem agilitásban, sem költséghatékonysággal nem képes kiszolgálni, sőt a rendszer homogenizálásához elengedhetetlen generációváltások sem tehetők meg könnyen és olcsón a mai komplex és küldetéskritikus környezetekben. Az agilis rendszer viszont kisebb lépésekben fejlődik, nem tervez túl, elasztikusan együtt él és formálódik az igényekkel, valamint a meglévő rendszerekre is nagyban épít. Azonban az, hogy egy rendszer heterogén, magában még nem biztosítja az agilitását, az elaszticitását, a költséghatékonyságát és az interoperabilitást sem. A modern informatika több eszközt kínál az agilis heterogén rendszerek fenti kihívásoknak való megfeleltetéséhez. kínálja elsősorban a nyílt szabványokat, amelyek biztosítják az interoperabilitást, azaz hogy olyan rendszerek, amelyeket egymástól függetlenül fejlesztettek, együtt tudjanak működni további fejlesztések, valamint anyagi és egyéb természetű ráfordítások nélkül. Mivel rendszereink heterogének és folyamatosan változnak, az üzletmenet folytonosságának fenntartásához nagyban hozzájárulnak a nyílt szabványok.
Privát és publikus felhők
A nyílt szabványok használata biztos alapot nyújt a nyílt, interoperábilis és rugalmas heterogén rendszerek felépítéséhez, azonban ahhoz, hogy ezek a rendszerek elasztikusak, agilisak és költséghatékonyak legyenek, egy olyan modern architektúrába kell belehelyezni őket, ami a szükséges erőforrások kezelését is rugalmasan oldja meg. A jelenkor informatikai világában ez az architektúra a felhő. Felhőkről sok szó esik manapság. Legtöbbször publikus alkalmazásszintű felhőkről hallunk, mert a felhasználók számára ez a legkézzelfoghatóbb (pl. Facebook, Google). A nagyobb vállalatok és intézmények informatikájának agilitási, költséghatékonysági és elaszticitási problémáit azonban elsősorban nem az alkalmazásszintű felhők oldják meg. Egy megalapozott informatikai architektúra az infrastruktúra szintjénél kezdődik. Sokan idegenkednek a felhőmegoldásoktól, mivel a feladatok végrehajtása és az adatok tárolása egy ismeretlen, kontrollálatlan helyen történik. Ez a publikus felhőkre igaz, és ott is csak részben. Felmerül a kérdés, hogy akkor most privát vagy publikus felhőkről beszélünk? Ami egy vállalat belső működése számára privát felhő, az a vállalat által kifelé nyújtott szolgáltatás tekintetében az ügyfelek számára már publikus. Ugyanez a helyzet a vállalatcsoporton belüli megosztott erőforrásokat illetôen, főleg, ha azok több országon, kontinensen átívelnek. A kormányzat által az intézmények számára nyújtott felhőszolgáltatás egyben privát és publikus is, a biztonságos elhatárolásokat minden esetben meg kell oldani. A technológia szintjén nincs különbség, a különbséget a hozzáférések, a szerződéses feltételek és a működési garanciák jelentik.
| Zsákutcákba kényszerítve Ugye milyen kényelmet, egyszerűséget jelent az tény, hogy egy autós úthoz két pont között bármilyen márkájú gépkocsit igénybe vehetünk, függetlenül attól, hogy az autó kicsi vagy nagy, gyors vagy lassú, kényelmes vagy kényelmetlen? Hatalmasat. Ráadásul vezetési biztonságunkat is megalapozza, hogy mindegyik gépkocsiban ugyanott van a fék, a kormány és a gázpedál. Meglepő módon az informatika világában ez sokszor nem így van. Gondoljunk csak bele, hogy például a HTML5 szabvány használata nélkül minden mobiltelefon-márkára külön-külön ki kell fejleszteni a szoftvert, vagy az ODF szabvány használata nélkül nem tudunk szövegszerkesztők között kényelmesen és tartalomhűen átvinni dokumentumokat: szoftvermegoldásaink nem mindig ezeket a szabványokat implementálják, bekényszerítve a felhasználókat olyan „zsákutcákba”, amelyekből igen nehéz kijönni. Ezek a problémák az elmúlt évtizedekben még nem jelentettek túl nagy gondot, mivel vállalati környezetben főképp egyetlen gyártó rendszereivel volt dolgunk, azonban a modern informatika már nem erről szól: visszatért a verseny és az innováció, nagyrészt a nyílt forráskód és az internet széles körű elterjedésének köszönhetően |
Nyílt forráskódú felhőmegoldások
Ha az infrastruktúra-szintű felhőket vizsgáljuk, több oldalról is a nyílt forráskódú felhőmegoldásokat kell górcső alá vennünk. Egyrészt költséghatékonyság szempontjából kiemelkedő potenciállal rendelkeznek a korábban már említett tulajdonságok révén, másrészt szinte az összes létező megoldás nyílt alapokon nyugszik, elég ha a CloudForms, Cloud Foundry, openstack, openNebula, Eucalyptus stb. projektekre gondolunk. Ha vállalati szinten is támogatott kész megoldást keresünk ezek között, és megnézzük közelebbről például a Red Hat által készített CloudForms rendszert, akkor láthatjuk, hogy egy teljes informatikai infrastruktúrát lefedő felhőarchitektúráról van szó, olyan rétegekre osztva, hogy megvalósulhasson benne a kívánt rugalmasság. Milyen főbb feladatai vannak tehát egy nyílt felhőrendszernek? legfontosabb az infrastruktúra-háttérrendszerek kezelése, beleértve a számítási erőforrásokat (CPU), az üzenetküldést vagy a tárkapacitást. Mindenképpen kezelnie kell számos, már meglévő virtualizációs megoldást, legyen az RHEV (Red Hat Enterprise Virtualization), Xen vagy VMware, valamint biztosítania kell a képmások konvertálhatóságát a virtualizációs környezetek között. képesnek kell lennie a virtualizációs környezetek vendégrendszerein kívül fizikai szervereket közvetlenül is munkára fogni. Ezen kívül, ha a meglévő számítási kapacitás a saját felhőnkben nem lenne elegendő, akkor átmenetileg vagy hosszabb távra bármilyen külső felhőszolgáltatót is be kell tudni kapcsolni az infrastruktúrába.
A második réteg
El is érkeztünk a második réteghez: az erőforrás-kezeléshez. Egy nyílt alapokon nyugvó felhőrendszerrel biztosíthatjuk, hogy meglévő heterogén virtuális és fizikai infrastruktúránkat maradéktalanul újrahasznosíthatjuk és folyamatosan bővíthetjük, de – az erőforrás-kezelés szempontjából – a helyi és a távoli heterogén elemeket is egységesen használhatjuk fel. Ugyanez igaz a privátfelhő nyújtotta tárkapacitásra is, a ma létező nyílt megoldások (pl. GlusterFs) akár egységes fájlrendszerszinten is képesek korlátlanul bővíthető, nagysebességű tárkapacitást nyújtani heterogén tárolóelemek felhasználásával. Az erőforrások kezeléséhez felületeket kell biztosítani a felhasználóknak és az adminisztrátoroknak, meg kell oldani a különböző felhasználók, felhasználói csoportok biztonságos elkülönítését, akár privát, akár publikus felhasználási módról van szó. Ezen kívül pontosan szabályozni kell, hogy ki, hogyan és milyen erőforrásokhoz férhet hozzá az egységesített készletből. A felhőrendszer harmadik szintje az alkalmazás-életciklus kezelése köré épül. Egy infrastruktúra-szintű felhő alapvetően rendszerképmásokat kezel és futtat a hozzákapcsolt erőforrásokon. Egy alkalmazás azonban több, mint egyetlen rendszerképmás, mivel egy modern, többrétegű, skálázható rendszer rétegenként is több futtatandó rendszerelemből áll, amelyek konfigurációját, kapcsolatait, frissítését rendszerszinten is össze kell hangolni. Ehhez definiálni kell az alkalmazásrendszert, hogy az az alatta lévő erőforráskészletből pontosan fel tudjon épülni, és az életciklusa is kezelhető legyen.
A bal oldali ábra jól mutatja egy háromrétegű alkalmazásrendszer elemeit és annak viszonyait a felhőben. Red Hat CloudForms Most, hogy a Red Hat CloudForms példáján végignéztük egy tipikus nyílt nyílt infrastruktúra-szintű felhő elemeit, valamint azt, hogy miként tud megfelni a vele szemben támasztott követelményeknek, nincs más hátra, mint hogy belevágjunk és kipróbáljuk!