Az Oracle Database 21c verziójának megjelenésével az Oracle véglegesen átállt a konténer-adatbázisos multitenant architektúrára. Bár maga a multitenant feláras opcióként régóta elérhető, nem mondható elterjedtnek. A 12.1 és 12.2 verziók alatt ugyan adatbáziskezelő-példányonként egy saját konténeres adatbázissal használható az architektúra licencelés nélkül is, ez önmagában nem volt elég a konténeres modell terjedéséhez.

A 2020 decemberében kiadott 21c verzióban a multitenant architektúrának adott kizárólagosság azt jelenti, hogy előbb-utóbb az adatbázis minden felhasználójának érdemes lesz áttérnie erre a modellre. Annak ellenére írom ezt, hogy a már üzemben levő adatbázisok a bevett gyakorlatnak megfelelően gyakran sokéves lemaradásban vannak a gyártó legfrissebb verziójától. A 21c ráadásul átmeneti verzió, hiszen az aktuális hosszú támogatási ciklusú verzió a 19c, így nincsen semmilyen lépéskényszer.

Hogy miért hozom fel mégis a multitenantet? Elsősorban azért, mert az elmúlt egy évben bizonyosan nem csökkent a felhasználó vállalkozások költségérzékenysége. A legszerencsésebbeknél csak egy szokásos célról van szó (No. 1: 'cost cutting'), addig vannak olyan társaságok, amelyeknél kritikus lehet az optimalizáció, a költségek csökkentése. De lehet-e csökkenteni a multitenanttel a költségeket, és ha igen, hogyan?

Közvetlen és közvetett hatások

A 19c kiadású Database-től az Oracle megemelte az ingyenesen létrehozható konténeres adatbázisok számát egyről háromra, amivel már érdemes foglalkozni. Minden cég környezete és üzemeltetési kultúrája más, és messze nem minden konszolidálható, de lehet, hogy találunk néhány olyan adatbázis, amelyet összehúzhatunk egy adatbáziskezelő-példány alá, amellyel elindulva már érhetünk el megtakarításokat, elkerülhetjük a klaszterek bővítését, vagy esetleg kevesebb processzormaggal és memóriával is kiszolgálhatjuk az adatbázisainkat.

Repkényi Balázs

A szerző az IPR-Insights Oracle-licencelési szakértője. (Fotó: IPR-Insights)

Ez ugyan papíron szép, de a gyakorlatból mindannyian tudjuk, hogy az Oracle-költségeket kifejezetten nehéz, sokszor lehetetlen csökkenteni. Tehát mi értelme van erről beszélni? Az Oracle Database szervereken számos más fizetős szoftver is jelen van, és ha a közvetlen költségcsökkentés nem is lehetséges, a kapcsolódó költségek faragásán érdemes lehet elgondolkodni.

Mivel a szoftverlicencelési szabályrendszerek bonyolultak, és mindegyikben máshol vannak a problémás pontok, kivételek, más a stílus, erős a kényszer, hogy ne holisztikusan, hanem silókban, egyszerre egy szabályrendszert a fejünkben tartva gondolkodjunk. Ennek eredményeként előfordulhatnak kihasználatlan optimalizációs lehetőségek. Nézzünk például egy egyszerűsített esetet! Ha a klaszter méretét tudjuk csökkenteni egy szerverrel, azzal fel tudunk szabadítani VMware-licenceket. Vagy: ha tudjuk csökkenteni a VM-ek számát, azzal csökkenhet az operációsrendszer-támogatási igény.

Nem tudok általános szabályt mondani, ami garantálná, hogy bármely környezeteben el lehet érni érdemi megtakarítást; azt viszont mindenképpen javasolnám, hogy lépjünk eggyel hátrébb a gondolati silóktól, és nézzük meg, van-e egy-két azonosítható kölcsönhatás a különböző szoftvergyártók között, amely az egyik – akár licencsemleges – módosításával pozitívan hat egy másik licencigényére – legyen az közvetlen vagy az infrastruktúra módosításán keresztül érvényesülő, közvetett hatás.

Itt a nullához tartó növekedés is jó eredmény

És ha az Oracle-költségeinket nem is tudjuk csökkenteni, arra feladatunk figyelni, hogy az esetleges növekményeket minimalizáljuk. Ilyen terület például az Extended Support.

A 11.2-es verziónál kényelmes volt, hogy az Oracle négy évvel kitolta az Extended Support-díjak behajtását; egy ilyen lépésre azonban ma már nem építhetünk: a 12-es verzióknál ez az időszak szűkült, majd eltűnt. Akinek biztonsági szempontból, törvényi vagy felettes hatóság általi előírás miatt szükséges a kiterjesztett támogatás, annak elő kell fizetnie a szolgáltatásra. Annak ellenére, hogy ezt a díjat nem az összes licencünkre, hanem csak az érintett régi verziót használó rendszerek licencigényére kell megvásárolni, még mindig jelentős tétel lehet a 10-20 százalékos felár a licencvagyon töredéke esetében is. Emiatt érdemes megnézni, hogy tudunk-e konszolidációval viszonylag fájdalommentesen többletköltséget elkerülni.

Ha néhány év múlva egyébként is át kell térni a konténeres architektúrára, érdemes megnézni, hogy előrébb hozva vagy elnyújtottabban, de hamarabb elkezdve az átállást tudunk-e megtakarítást elérni, vagy legalább el tudjuk-e kerülni a költségnövekedést.