Your Oracle estate is running on 3 “clocks" you don’t control: The hypervisor renewal arrived with a higher cost nobody budgeted for. The database support window has a date on it. And somewhere above you, someone has committed the company to AI that must rely on the critical data that lives in those databases. Each timeline belongs to a different vendor and is being used to force a decision on someone else's schedule.
The work Red Hat and Everpure have done together exists to break that coupling. Every layer of the estate—hypervisor, operating system (OS), storage, and the database itself—should modernize on its own timeline, which you control. Over the past 2 years we’ve built and published the validation to make that real for Oracle workloads specifically. This post covers what we tested, what the results were, and what they mean for how you sequence the next 3 years.
Validating Oracle workloads on Red Hat OpenShift Virtualization and Everpure
Red Hat's engineering team published a complete reference architecture for Oracle Database 19c on Red Hat OpenShift Virtualization, covering single instance and Oracle Real Application Clusters (RAC), with the full test artifacts available on GitHub. The validation ran functionality, performance, scalability, and live migration testing. The storage under those tests included Everpure FlashArray provisioned through the Portworx Enterprise operator.
Two results matter most for anyone planning a migration:
- Live migration of a virtual machine (VM) running a single-instance Oracle Database completed in 1-2 minutes on average, and the result held whether the database was idle or under production-like load, with virtual users generating sustained volumes of concurrent transactions. Live migration is the operation that makes a virtualization platform livable. Node maintenance, rebalancing, and hardware refresh all depend on it, and it works for Oracle on this platform the way you need it to.
- The support posture is the same one you already operate under. Oracle certifies to the OS inside the VM, not to the hypervisor beneath it. Oracle Database on Red Hat Enterprise Linux (RHEL) remains a fully supported OS configuration, and Red Hat has published comprehensive, validated reference architectures for running these workloads—including RAC—on OpenShift Virtualization.
3 postures, 1 platform
Customers come to this work from different starting positions. The platform doesn’t force them into the same path.
- Keeping the estate on premise and exiting the legacy virtualization platform. This is the posture the renewal letter creates. Instead of being locked in to a prohibitive hypervisor renewal, Red Hat’s migration toolkit for virtualization moves Oracle VMs from VMware vSphere to OpenShift Virtualization without needing the administrator to modify the guest. The database administrator's environment on Monday looks like it did on Friday. FlashArray sits underneath both the old platform and the new one, and ActiveCluster can move the storage between arrays without taking the database down, which means the storage layer never blocks the migration window. The database didn’t move. The platform around it did.
- Modernizing on the database's own clock. Oracle's upgrade cycle is its own forcing function, and an upgrade rehearsed badly is the most expensive kind of outage. Array snapshots give you instant, space-efficient clones of production for dev, test, and performance environments, so the rehearsal runs against real data without a 2nd copy of the storage bill. FlashBlade restores at up to 65 TB per hour, so the rollback path is measured in minutes rather than in a weekend. The platform migration and the database upgrade stop competing for the same change window because neither one depends on the other.
- Building around the database. New services land as containers now. The question is whether they land on the same platform as the estate or on a 2nd one with its own storage, backup, and on-call rotation. Everpure serves persistent storage to both the VMs and the containers from 1 plane, on the same arrays. The team that runs the VM estate and the team that’s shipping containerized services stop maintaining parallel infrastructure. And the eventual AI workloads—including the vector and retrieval capabilities arriving in the current generation of Oracle Database—inherit the same substrate rather than demanding a new one.
Value of the storage layer
A platform migration is a sequence of moments where data has to be in 2 places, or has to move without stopping, or has to be recoverable faster than the business notices. Those are storage properties. The Red Hat validation results on RAC made the point empirically: External enterprise array storage outperformed hyperconverged alternatives for the most demanding configurations. The seams in a modernization—between hypervisors, between database versions, and between VM and container—are exactly where the storage platform either decouples the clocks or chains them back together.
Evergreen architecture extends the same logic to the storage itself. The array under your Oracle estate upgrades nondisruptively across controller generations, which removes the 1 clock infrastructure teams traditionally imposed on everyone else: the forklift refresh.
What to do with this
Start with the seam that has a date on it. If that date is a hypervisor renewal, run Red Hat’s migration toolkit for virtualization against a nonproduction Oracle VM and measure the result against the published reference architecture. If that date is a database support window, build the rehearsal environment from snapshots this quarter and time your restore path. Both exercises cost days, and both convert an external deadline into a measured plan.
The estate you run in 2029 will not look like the one you run today. The work above means you get to decide the order in which it changes.
Reference architecture, test artifacts, and configuration guidance:
製品トライアル
Red Hat OpenShift Virtualization Engine | 製品トライアル
執筆者紹介
Chris Janiszewski is a Senior Principal Solutions Architect specializing in OpenShift and modern datacenter infrastructure. He partners with organizations to architect, validate, and scale complex workloads across hybrid cloud environments, focusing on Kubernetes, bare-metal infrastructure, and cloud automation. When he’s not untangling complex enterprise architectures, Chris is usually hanging out with his two kids. Once they’re asleep, he trades his dad hat for his geek hat to build home labs and test out wild edge-case scenarios.
Andrew Sillifant is a Director of Product Management at Everpure specializing in data infrastructure, where he leads solutions built for the demands of modern, AI-driven workloads.
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
仮想化
オンプレミスまたは複数クラウドでのワークロードに対応するエンタープライズ仮想化の将来についてご覧ください