У последњих неколико година, ИТ индустрија пролази кроз значајну трансформацију на више нивоа. Са једне стране, све је израженији тренд модернизације апликација, односно прелазак са монолитних и традиционалних модела развоја ка cloud-native архитектури и микросервисима, који данас представљају нови стандард.
Са друге стране, аквизиција компаније VMware од стране Broadcom-а донела је не само промену власничке структуре, већ и фундаменталне промене у моделу лиценцирања кроз консолидацију лиценцних пакета, увођење subscription-only модела, као и значајно повећање цена.
Ове промене су имале директан утицај на организације које су годинама градиле своје инфрастуктуре и пословање ослањајући се на VMware екосистем, подстичући их да преиспитају своју ИТ стратегију, не само из угла трошкова, већ и у контексту управљања ризицима, дугорочне флексибилности и смањења зависности од једног произвођача (vendor lock-in).
У том контексту, организације су усмериле своју стратегију у следећим правцима:
Стратешки правац | Оперативни модел | Предности | Ризици и ограничења |
|---|---|---|---|
Задржавање VMware инфраструктуре | Наставак коришћења постојеће VMware платформе уз оптимизацију трошкова (консолидација, rightsizing) без промене архитектуре |
|
|
Миграција на алтернативне VM платформе | Прелазак на друге hypervisor-based платформе уз задржавање постојећег VM модела |
|
|
Миграција на KubeVirt платформу | Извршавање виртуелних машина унутар Kubernetes/OpenShift окружења кроз KubeVirt-а |
|
|
Миграција на KubeVirt + cloud-native апликације | Комбинација VM-ова у KubeVirt-у и постепене модернизације апликација ка микро-сервисима и cloud-native архитектури |
|
|
Миграција и потпуна cloud-native трансформација | Трансформација апликација ка cloud-native моделу |
|
|
У пракси, ови правци се ретко примењују изоловано. Организације најчешће усвајају хибридну стратегију кроз фазни roadmap, прилагођен типу и карактеристикама workload-a, нивоу зрелости тимова и стратешким циљевима.
Истраживање Voice of Kubernetes Experts 2025 показује да 57% организација планира да управљање виртуелним машинама пребаци на Kubernetes платформе, док 59% ради на модернизацији постојећих VM workload-ова кроз њихову трансформацију ка cloude-native моделу.
Зашто је хибридна стратегија доминантна:
- Различити workload-ови различит приступ – нпр. core базе података остају на VM-овима, док нове апликације настају као cloud-native
- Ризик и континуитет пословања – миграције се изводе фазно (pilot → миграција → оптимизација), без „big bang“ приступа
- Регулаторни и технички захтеви – поједине апликације не могу одмах бити трансформисане (compliance, latency, vendor support)
- Организациона реалност – транзиција захтева нова знања и траје типично 2–5 година
Због свега наведеног, хибридни и фазни приступ је de facto стандард, а не изузетак.
У том контексту, поставља се питање – која платформа може да подржи овакав приступ, без потребе за радикалним „big bang“ миграцијама?
Управо ту се OpenShift Virtualization (KubeVirt) издваја као један од кључних играча када је у питању алтернатива ѕа VMware и почетак еволуциje са традиционалног VM модела на cloude-native.
Према доступним истраживањима, Red Hat OpenShift Virtualization данас представља најчешћи избор у enterprise окружењима (≈58%), док се SUSE Virtualization (познат и под називом Harvester) позиционира као релевантан и све присутнији избор (≈24%).
Док OpenShift Virtualization решава питање compute слоја, омогућавајући да VM и контејнери раде на истој Kubernetes платформи, стварне могућности платформе у великој мери одређује storage слој. Управо storage и data services дефинишу да ли Kubernetes окружење остаје на нивоу основне оркестрације workload-ова или прераста у enterprise-ready инфраструктуру.
Управо зато је за enterprise виртуализацију на Kubernetes‑у потребан додатни data‑management слој који доноси „VMware‑класе“ могућности на Kubernetes‑native начин. Ту на сцену ступа Portworx by Pure Storage, који у комбинацији са KubeVirt‑ом попуњава празнине између „чистог“ Kubernetes‑а и очекивања инфраструктурниx тимовa на које их је VMware навикао.
Portworx се позиционира као data platform layer унутар OpenShift/Kubernetes окружења, који надограђује основни CSI модел и уводи напредне storage и data management функционалности.
Шта се „откључава“ са OCP + Pure + Portworx?
Комбинацијом OpenShift Virtualization, Portworx-а и enterprise storage система какав је Pure, Kubernetes платформа добија функционалности које су традиционално биле везане за VMware екосистем:
- HA и data availability на нивоу storage-а
- Snapshot и backup механизми
- Disaster recovery
- Live migration
- Storage performance control (QoS)
- Thin provisioning и capacity management
Другим речима Kubernetes + KubeVirt + Portworx ≈ VMware stack:
Benefit/Feature | VMware Capability | Kubernetes + KubeVirt Capability | Kubernetes + KubeVirt + Portworx Capability |
|---|---|---|---|
Application Availability | VMware vSphere HA | Deployments / Services | Deployments / Services |
Application Deployment | VMware Templates | Container Images | Container Images |
Application Resource Utilization | VMware DRS, SIOC, NIOC | Kube Scheduler, Requests / Limits | Requests / Limits |
Application Portability | vMotion | Delete/Redeploy with Load Balanced Apps | Live Migration and Delete/Redeploy with Load Balanced Apps |
Storage Infrastructure | VASA/VAAI/SPBM/vVols | StorageClasses, CSI Provisioner | StorageClasses, CSI Provisioner |
Data Availability | Shared Storage or vSAN FTT | X | Portworx Enterprise StorageCluster |
Async Disaster Recovery | VMware Site Recovery Manager | X | Async PX-DR |
Sync Disaster Recovery | VMware Metro Storage Cluster | X | Sync PX-DR |
Encryption | Security Abstraction / Volume Encryption | X | PX-Security |
Data Protection | VM Aware Backups (Partner) | Partner Solutions | Container Aware Portworx Backup |
Storage Performance | SIOC | X | Portworx Enterprise Application I/O Control |
Data Portability | Storage vMotion | X | Portworx Backup / PX-Migrate |
Capacity Management | Thin Provisioning | X | Thin Provisioning / PX-Autopilot |
За разлику од стандардних CSI драјвера, који углавном обезбеђују основне функционалности попут provisioninga, управљања волуменима и основног snapshot менаџмента, Portworx додаје комплетан скуп enterprise data сервиса:
- Data availability кроз репликацију persistent волумена — HA на нивоу storage-a
- Disaster recovery — DR Sync (zero RPO) и DR Async (мин 15-минута RPO)
- Backup и Restore — PX Backup (application-aware приступ, конзистентни snapshot и clone-ови, подршка за S3 object-lock)
- Енкрипција и безбедносни механизми — PX Secure (encryption at rest, RBAC, BYOK)
- Контрола перформанси и капацитета (PX Autopilot за аутоматско проширење и ребаланс storage-а, class of service, I/O tuning)
Једна од кључних предности Portworx-а у односу на класичан CSI слој је то што не везује Kubernetes кластер за одређени тип storage-а или једног vendor-а. Такође треба узети у обзир шта је и како заправо CSI driver функционише, односно која су његова ограничења (латенције услед великог броја API call-ova ка екстерном storage-u, host connection limits, ограничене 2-day storage операције…). Више детаља о свему наведеном можете пронаћи на следећим линковима:
Portworx са друге стране може да се ослони на локалне дискове, постојећи SAN или cloud block storage, као и на enterprise системе попут Pure FlashArray/FlashBlade-а — при чему се избор своди на баланс између флексибилности и перформанси, а не на техничка ограничења платформе.
Модел интеграције | Како ради | Када има највише смисла |
|---|---|---|
Portworx CSI | Интегрише Kubernetes са Pure Storage платформама (FlashArray, FlashBlade, Cloud Block Store) преко CSI-а. | Enterprise окружења која већ користе Pure Storage као примарни storage и желе директну Kubernetes интеграцију са пуним Pure capability‑има, уз прихватљив vendor lock‑in и без потребе за одређеним Portworx Enterprise функционалностима (multi‑cloud кластер, уграђена репликација, DR и аутоматизација капацитета…) |
Интегрише Kubernetes са Pure Storage платформама (FlashArray/FlashBlade) тако што директно provisioning-ује и мапира волумене или фајл системе на Kubernetes PVC-ове, без сопственог storage pool-а. | Код Workload где су критични најнижа латенција и пуне Pure функционалности (QoS, ActiveCluster, multi-tenancy), уз свесно прихватање јаче зависности од конкретног storage vendor-а, као и одређених лимита када су у питању Portworx Enterprise функционалности | |
Локални дискови (hyperconverged) | Portworx користи локалне дискове на сваком чвору (нпр. NVMe/SSD/HDD) и од њих гради distributed storage кластер са сопственим storage pool‑ом и репликацијом података између чворова. | За организације које желе да комбинују перформансе и потпуну независност од storage вендора – од мањих lab и edge окружења до великих scale‑out production кластера уз откључавање full Portworx Enterprise функционалности |
Portworx управља блок волуменима са постојећег storage-а (SAN, cloud block storage и сл.) и презентује их као Portworx pool-ове и Kubernetes StorageClass-ове. | Када већ имаш инвестицију у enterprise storage или cloud block storage и желиш да на њега додаш Kubernetes-native слој са full Portworx функционалностима. |
Portworx Direct Access vs Cloud Drives (Pure интеграција)
У интеграцији Portworx‑а са Pure FlashArray/FlashBlade системима, архитектура се у пракси своди на два доминантна модела. Један наглашава флексибилност Portworx слоја, а други дубоку интеграцију са Pure платформом.
Модел | Кључне карактеристике | Примарни бенефит |
|---|---|---|
Direct Access | Portworx директно презентује FlashArray/FlashBlade volume‑e или filesystem‑e и мапира их на PVC‑e; I/O иде директно на Pure систем, без Portworx storage pool‑а | Дубока интеграција са Pure Storage платформом и коришћење њених enterprise перформанси и data сервиса, уз одређена ограничења када су Portworx Enterprise функционалности у питању. |
Cloud Drives | Portworx управља FlashArray/FlashBlade ресурсима као cloud drive‑овима (LUN‑ови/volume‑и), од њих креира своје storage pool‑ове и примењује све Portworx функције (репликација, DR, Autopilot, multi‑cloud) | Дубока интеграција са Pure Storage платформом и коришћење њених enterprise перформанси и data сервиса, уз додавање Kubernetes‑native Portworx слоја односно потпун спектар Enterprise функционалности |
Лиценцирање и трошкови: шта је заиста потребно и да ли има смисла?
Када се говори о преласку са традиционалних виртуелизационих платформи на Kubernetes базирана решења попут OpenShift Virtualization (KubeVirt), једна од кључних тема за организације постаје модел лиценцирања и укупни трошак платформе, јер управо ту већина пројеката разликује „nice to have“ од онога што је заиста одрживо на дуже стазе.
За разлику од традиционалних виртуелизационих stack-ова, где је већина функционалности интегрисана у саму платформу, Kubernetes екосистем је по својој природи модуларан. То значи да различите компоненте – compute, storage и data services могу долазити из различитих пројеката и производа, уз различите моделе лиценцирања.
У пракси, то организацијама даје већу флексибилност, али истовремено отвара и питање: које компоненте су заиста потребне, а које представљају додатне enterprise могућности?
Компонента | Oбавезна (Да/Не) | Модел лиценцирања | Напомена |
|---|---|---|---|
OpenShift Virtualization | Да, уколико се користи само за VM management (VM‑only сценарио) | Core‑pair или Node subscription (VM‑only SKU, per core / per socket) | Купује се као посебан subscription искључиво за VM workload – нижи трошкови |
OpenShift Container Platform | Да, уколико се користи за container и VM management | Core‑pair или Node subscription (per core / per socket, нпр. 1–2 socket, до 128 core‑а) | Лиценца обухвата OCP (K8s) + OpenShift Virtualization + RHEL guest/host + App platform features + Developer Application Catalog |
OpenShift Platform Plus | Да, уколико се користи за container и VM management | Core‑pair или Node subscription (per core / per socket, нпр. 1–2 socket, до 128 core‑а) | Лиценца обухвата OpenShift Container Platform + RHACM, RHACS, ODF Essentials и Quay – један bundle за container + security + storage + registry |
SUSE Rancher Prime + SUSE Virtualization | Да, ако желиш платформу за container и VM management на SUSE страни | Per Unit (cores/vCPU за виртуализоване deployment‑е; sockets/cores за bare‑metal) | Rancher Prime обухвата multi‑cluster K8s management (RKE/K3s + external K8s), + SUSE Virtualization (Harvester HCI). Комбиновано добијаш unified VM + container management из истог UI‑ја. |
SUSE Rancher Suite | Да, ако желиш full SUSE stack (K8s + VM + storage + security + registry) | Per Unit (cores/vCPU за виртуализоване deployment‑е; sockets/cores за bare‑metal) | Овом лиценцом је обухваћен SUSE Linux Micro или SUSE Virtualization, RKE/K3s, Elemental, Rancher Management Server, SUSE Observability, SUSE Storage, SUSE Security, SUSE Private Registry и делови Application Collection‑а. Практично: један bundle за VM + container + storage + security |
CSI driver | Не – већинa enterprise storage vendora не захтева додатну лиценцу | – | Треба имати у виду све горе поменуте лимите и функционална ограничења. |
Portworx Enterprise | Да | По ноде-y/worker-у | Enterprise data services |
Portworx for Modern Virtualization | Да | По ноде-y/worker-у (bare-metal) | Оптимизована лиценца када се Portworx користи само за VM workload – нижи трошкови |
Portworx DR (PX-DR) | Не | Add-on – по ноде-y/worker-у | Sync/Async disaster recovery |
Portworx Backup (PX-Backup) | Не | По node-у (worker-y) на којем се извршавају workload-и који се бекапују | Application + VM backup – нема одвојеног лиценцирања у односу на тип workload-а који се бекапује |
Compute Layer |  |
Storage Layer |  |
Како би то могло да изгледа у пракси?
Да би све било мање апстрактно, може да нам помогне неколико типичних сценарија. Наравно, свака организација има своје специфичности, али оквирно се могу раздвојити у три шаблона:
1. Мање окружење – фокус на замену VМ платформе:
Мањи или средњи тим са ограниченим ресурсима, који пре свега жели да смањи трошкове и избегне vendor lock-in ситуацију, конкретно VMware, а да при том не отвара одмах тему модернизације апликација. У овом сценарију, типичан избор је:
- OpenShift кластер + OpenShift Virtualization,
- Portworx као distributed storage,
- без PX‑DR у првој фази, ослањање на основни PX‑Backup тамо где је потребно.
Циљ је да се обезбеди стабилна, технички и трошковно одржива замена за VMware, која задржава VM модел и омогућава постепено увођење тимова у Kubernetes свет.
2. Средње окружење – консолидација и централизован backup
Организација са више критичних апликација, комплекснијим захтевима и већи бројем тимова, која жели да консолидује виртуелизацију и начин на који штити податке. Ту се често бира:
- OpenShift + OpenShift Virtualization за VM‑ове и cloud‑native workload‑е,
- Portworx као заједничка data платформа,
- PX‑Backup као централно решење за backup и restore за више кластерa, са policy‑based заштитом по апликацијама.
Ово је ниво на којем Kubernetes заиста постаје „нова стандардна платформа“ унутар организације, а не само још једна изолована платформа који живи изван главне инфраструктуре.
3. Велико или регулаторно окружење – пуна data платформа и DR
Велике компаније, финансијски сектор, енергетика или било који сегмент где је непрекидно пословања критичнo и где DR није „пожељно имати“ већ обавеза. У том случају, цела прича се подиже за један степеник:
- OpenShift кластери у различитим дата центрима/region-има,
- Portworx као data слој свих кластера,
- PX‑Backup за VM и апликативни backup/restore,
- PX‑DR за sync/async disaster recovery сценарије, са јасно дефинисаним RPO/RTO метрикама за кључне workload‑е.
Овде OpenShift + Portworx + Pure Storage не само да замењују постојећи VMware, већ фактички постају нова, cloud‑native data платформа на којој ће живети и VM‑ови и будуће cloude-native апликације.
Миграција и подржани оперативни системи – шта је могуће?
Замена виртуелне платформе не почиње од инфраструктуре, већ од workload-ова.
Кључно питање није само шта је нова платформа способна да покрене, већ шта из постојећег окружења можемо мигрирати без компромиса по питању стабилности, подршке и дугорочне одрживости. Управо ту почиње реална процена миграције.
Прави изазов су наслеђени legacy системи – старе верзије Windows‑а и Linux‑а или специфични vendor appliance-и. Технички, неке од њих је могуће покренути и на OpenShift Virtualization‑у, али уз ограничења и „best effort“ приступ, што их често чини лошим кандидатом за платформу на којој треба да живе наредних неколико година. У пракси је рационалније такав workload планирано заменити, upgrade-овати, изоловати у посебан сегмент или привремено задржати на постојећем хипервизору, уместо да се по сваку цену мигрира.
Сам процес миграције ослања се на употребу Red Hat алата Migration Toolkit for Virtualization (MTV), који омогућава контролисан и делимично аутоматизован прелазак виртуелних машина са VMware окружења на OpenShift Virtualization.
Шта нам све омогућава MTV алат:
- анализу постојећих виртуелних машина и процену погодности за миграцију,
- дефинисање, односно мапирање мреже и storage-а између платформи,
- креирање миграционих планова и груписање VM-ова у логичке целине,
- извршавање и контролу саме миграције (warm/cold тип миграције).
На овај начин, процес миграције постаје предвидив и оперативно једноставнији, посебно у окружењима са већим бројем виртуелних машина.
Списак подржаних guest оперативних система као и подршке за миграцију са MTV алатом можете погледати у званичној RedHat документацији: Certified Guest Operating Systems in OpenShift Virtualization
Све горе наведено отвара и практично питање: да ли је ваша постојећа VMware инфраструктура уопште спремна за нову виртуелну платформу и у којој мери?
Уместо да се ослањате на одокативне и грубе процене, можемо заједничким снагама спровести комплетну техничку процену и анализу на основу које ћете добити јасну слику:
- који workload-ови су већ данас спремни за миграцију,
- који захтевају додатне кораке и корекције пре миграције,
- које workload-ове је рационалније привремено задржати на постојећој платформи.
Направите први корак у доношењу одлуке да ли и како да уђете у следећу фазу модернизације.
Једна ствар је данас прилично јасна – VMware није крај приче.
Алтернативе постоје, али избор правог пута не зависи само од технологије. Зависи од стратегије организације, постојеће инфраструктуре, расположивих знања у тимовима, буџета, као и од спремности да се прихвате изазови модернизације.
За организације које желе постепен прелаз из традиционалног VMware света ка модернијој инфраструктури, OpenShift Virtualization у комбинацији са Portworx Enterprise представља један од логичних путева. Такав приступ омогућава да се најпре адресира виртуелизациони слој и обезбеди функционалан еквивалент постојећем VM окружењу, а да се у наредним фазама постепено уводе cloud-native принципи, напредни data services и модернизација апликација
С друге стране, SUSE Virtualization такође представља веома интересантну алтернативу, у комбинацији са Portworx-ом може понудити велики део enterprise функционалности које се очекују од модерне инфраструктуре, уз одређена ограничења која се временом развијају.
Питања која свака организација данас треба да постави су следећа:
- да ли нам је потребна директна замена за постојећи VMware stack или платформа која омогућава постепену еволуцију инфраструктуре?
- да ли смо спремни да изађемо из зоне комфора, усвојимо нове технологије и прихватимо изазове модернизације или нам је приоритет стабилност и предвидљивост постојећег модела?
- да ли желимо већу технолошку флексибилност и потенцијално ниже трошкове или нам више одговара познато окружење, чак и по цену већих лиценци?
- и можда најважније: да ли доносимо одлуку која решава проблеме које имамо данас или ону која ће подржати инфраструктуру наредних неколико година?
На крају, не постоји једно „универзално“ решење које је исправно за све.
Најбољи приступ је да организације пажљиво анализирају своје окружење – инфраструктуру, апликације, тимове и стратешке циљевe, трошкове и на основу тога изаберу платформу која најбоље подржава њихов развојни пут.
Добра вест је да данас постоји више зрелиx решења која могу да покрију различите сценарије, од чисте виртуелизације до потпуно cloud-native инфраструктуре.
А пут од једног ка другом више не мора да буде нагли „big bang“ пројекат — може бити постепена еволуција платформе.
Да бисте разумели где се ваше окружење данас налази и који су наредни кораци, техничка процена је кључан први корак. Кроз такав приступ добија се јасна слика стања, доносе се одлуке засноване на чињеницама уместо претпоставкама и на тај начин значајно смањује ризик целокупног процеса — а ми вам у томе можемо помоћи.