A konténerben történő futtatás révén az alkalmazások egyenként is frissíthetők, a konfiguráció „intakt térben” történik, a módosításoknak nincs kihatása más alkalmazásokra.
A nagyvállalati informatikai környezetben a konténerizáció hasonló jelentőségű változást jelent, mint a virtualizáció térnyerése volt a 2000-es évek elejétől, amely a tradicionális (fizikai szerver – operációs rendszer – alkalmazások) rétegződésű környezetekhez képest sokszorosára növelte az üzemeltetési hatékonyságot, lehetővé téve az erőforrások radikálisan jobb kihasználását.
A konténerizáció és a virtualizáció közötti különbség
A környezet nem a fizikai szerver – hypervisor – virtuális számítógép – operációs rendszer – alkalmazások rétegekben épül fel, itt az „absztrakció” egy szinttel feljebb, az operációs rendszer szintjén, illetve afelett valósul meg. Ahogy a virtualizált környezetek erőforráskezelését ellátó hypervisorra, úgy a konténerizált környezetekben is szükség van a környezet menedzsmentjét, az erőforrások folyamatos allokációját biztosító eszközre: azaz konténerizációs ökoszisztémára. Ezek közül a legelterjedtebbek a Docker és a Kubernetes megoldások.
A virtualizáció új megközelítést hozott a szoftverek licencelésében, nincs ez másképp a konténerizációval sem. Valamennyi gyártó kidolgozza, vagy ki fogja dolgozni azokat a felhasználási részletszabályokat, amelyek mentén meghatározható, hogy ha alkalmazásainkat konténerekben futtatjuk, akkor mennyi és milyen licenccel kell rendelkeznünk ahhoz, hogy a felhasználás jogszerű legyen, ugyanakkor kellően gazdaságos maradjon, vagyis elkerüljük a büntetést, de ne költsünk feleslegesen.
A licencelés
|
A gyártó honlapján itt tájékozódhat az új licencelési szabályokról.
A GYIK rovat pedig részletes információt a felhasználóban felmerülő kérdésekre.
|
IBM szoftverek esetében támogatott technológia a Linux konténerek és Kubernetes orchestrator. A licencelésben az alábbi szabályok követendők. Konténerizált környezetben szoftvereink PVU vagy vCPU (virtuális processzormag) alapon licencelődnek, azzal, hogy 1 vCPU minden esetben 70 PVU-nak felel meg (szemben a virtualizált környezetekben irányadó 70, 100, 120 értékekkel). A licencigény meghatározásánál a pod-ok (egy vagy több konténert tartalmazó legkisebb telepíthető egységek) számára kiosztott magszámot kell figyelembe venni, ennek felső határa a Kubernetes cluster service által menedzselt working node-ok (fizikai szerverek) magszáma.
A konténerizált környezetek licencelésének logikája hasonló tehát a virtualizált környezetekre alkalmazott full-capacity – sub-capacity megközelítéséhez, ahol a fizikai kapacitás úgyszintén felső korlátot jelent. Fontos, hogy a konténerizáció esetén megengedett a micro-partitioning, vagyis tört vCPU értékek alkalmazása, amelyeket csak a cluster szintjén kell felfelé kerekíteni.
A felhasználó ugyanakkor a konténerizált kapacitás licencelése esetén sem ússza meg a folyamatos jelentéskészítési kötelezettséget, éppúgy, mint a sub-capacity licencelés esetében az IBM License Metric Tool használatát. A különbség annyi, hogy az ILMT (immár HCL BigFix modul) nem alkalmas a konténerizált környezetekben való futtatásra, ezért itt az IBM License Service megoldásának telepítését és megfelelő használatát követeli meg a gyártó.
Látható, hogy az új licencelési modell hosszú távon jelentős egyszerűsítést jelent a korábbi, sokszor bonyolult, és az automatizált eszközzel is nehezen követhető sub-capacity licenceléshez képest. A következő években ugyanakkor nem valószínű, hogy nagyvállalati szinten a tisztán konténerizált megoldások egyeduralkodóvá váljanak. Sokkal valószínűbb a hybrid környezetek elterjedése, ahol a különböző licencelési modellek és szoftvereszközmenedzsment eszközök inkább növelik a komplexitást, új kihívást és többletfeladatot jelentve a licencmenedzserek, szoftvereszközgazdálkodással foglalkozó szakemberek számára.
