Egy valós helyzet: egy 4 node-os cluster, 5 éves lifecycle végén. A SAN még stabil, de support vége 14 hónapon belül. A CPU-k 2×14 core-osak, a workload kihasználtság 45–50%. A terv egyszerű: új szerverek, modernebb CPU, nagyobb NVMe, minden megy tovább.
Papíron ez egy klasszikus infrastructure refresh.
Aztán a sizing során kiderül, hogy az új generáció már 2×32 core-os node-okat jelent. A cluster 112 core-ról 256-ra ugrik. A workload nem nőtt, de a core-szám igen. A licencmodell viszont per-core alapú. A hároméves TCO kalkulációban hirtelen nem a hardware a legnagyobb tétel, hanem a szoftver OPEX.
És itt válik láthatóvá a különbség infrastructure refresh és platform refresh között.
Infrastructure refresh esetén az alapfeltevés az, hogy a modell jó, csak gyorsabb hardver kell alá. A hypervisor marad, a data path marad, a DR struktúra marad. A cél a lifecycle stabilizálása, nem az architektúra újragondolása. Rövid távon ez kiszámítható, jól ütemezhető, alacsony szervezeti ellenállást vált ki.
Platform refresh esetén viszont a kiinduló kérdés más. Nem az, hogy milyen CPU kell, hanem az, hogy a jelenlegi modell a következő ciklusban is optimális-e. A VMware környezetekben a Broadcom utáni csomagolási és licencelési változások ezt a kérdést még élesebbé tették. Egy egyszerű szervercsere így könnyen platform-elköteleződéssé válhat, még akkor is, ha nem ez volt a szándék.
A legtöbb szervezet nem azért marad ugyanabban az architektúrában, mert az a legjobb. Hanem mert refreshkor nem akar kockázatot vállalni. A klasszikus 3-tier modell bevált, a SAN stabil, a működés ismert. De amikor a compute réteg frissül, a data path, a storage lifecycle és a hálózati topológia is új kontextusba kerül. Ha a SAN support kifut, a refresh valójában két projektet jelent, csak az egyik nincs kimondva. A 3-tier és az integrált HCI modell közti különbség ilyenkor nem ideológia kérdése, hanem adatútvonal- és üzemeltetési modell.
Egy platform refresh azt jelenti, hogy a data plane-t is újragondoljuk. Lehet, hogy a compute és a storage integrált, szoftveralapú modellben egyszerűbben üzemeltethető. Lehet, hogy workload-szinten érdemes kettéválasztani a környezetet. Itt jelennek meg természetes opcióként az olyan integrált HCI platformok, mint például a Nutanix, ahol a hangsúly nem csak a hypervisoron, hanem az egységes adat- és menedzsmentrétegen van. A döntés azonban nem a márkanévről szól, hanem arról, hogy a jelenlegi többkomponensű modell mennyire illeszkedik a következő ciklus igényeihez.
A platform refresh kérdése szinte mindig akkor válik sürgetővé, amikor több tényező egyszerre jelentkezik. ELA lejárat a következő évben. SAN lifecycle kifutás. DR redesign igény. Új típusú workload, például containeres vagy AI-jellegű feladatok megjelenése. Ilyenkor az infrastructure refresh már csak a felszín, a valós döntés a platformról szól.
A legnagyobb költség nem a váltás kockázata, hanem a változatlan modell öt évre történő bebetonozása. Egy infrastruktúra refresh látszólag biztonságos, mert nem változtat radikálisan. De ha a licencelési struktúra, az adatútvonal és a workload-mix már nem ugyanaz, mint öt éve, akkor a valódi kockázat a nem döntésben van.
Ha most szervercsere előtt állsz, érdemes nem csak a hardware listát véglegesíteni, hanem három dolgot őszintén végiggondolni. Hogyan változik a hároméves TCO a core-növekedéssel. A jelenlegi architektúra valóban optimális-e, vagy csak megszokott. És ha ma nulláról építenéd újra a környezetet, ugyanígy terveznéd-e meg.
Ez a pont, ahol az infrastructure refresh és a platform refresh útjai elválnak. Az egyik gyorsabb szervert ad. A másik hosszabb távú mozgásteret.