Oracle Database on Nutanix with Everpure

Executive Summary

Oracle on Nutanix with Everpure performs best when designed as an Oracle-first platform, not a generic virtualization stack. The strongest results come from combining three disciplines: Oracle architecture (RAC, ASM, HugePages, Data Guard), Nutanix VM and cluster best practices (CVM sizing, anti-affinity, failover headroom), and Everpure external-storage design (NVMe/TCP, FlashArray volumes, snapshots, replication) — all wrapped in clear operational ownership and validated network design.

Native Nutanix storage delivers strong Oracle performance for many estates, but Everpure becomes the preferred design when the goal is high-density consolidation, independent storage scaling, rich storage data services, or very low and predictable write latency.

This guide is intended to help with architecture decisions, design reviews, and operational standardization. It is written primarily for Oracle 19c-era deployments because that is the dominant versioning model in the current Nutanix validation guidance, though most principles also apply to later Oracle releases.

Scope and Assumptions

In Scope

• Oracle Database 19c as the primary design target; most principles also apply to later releases.

• Oracle RAC, single-instance Oracle, and consolidated Oracle estates.

• Backup, snapshot, clone, and DR workflows using Oracle-aware and infrastructure-aware tooling.

• Nutanix Acropolis Hypervisor (AHV) on Nutanix Cloud Platform as the hypervisor layer.

• Everpure FlashArray presented to Nutanix over NVMe/TCP as the external storage layer.

Out of Scope

• Application‑tier sizing, including WebLogic, E‑Business Suite middle tiers, and other non‑database components.

• Formal Oracle licensing or legal advice; always validate license posture with your Oracle account team and your own contracts.

Assumptions

• Oracle ASM or an equally disciplined storage abstraction is in use.

• Guest OS is an Oracle-supported Linux distribution.

• Platform, network, storage, and DBA teams can coordinate operational ownership.

Quick Reference

Use the following as a strong default starting point for production Oracle on Nutanix with Everpure. Each row links to the detailed section that explains the recommendation and its trade-offs.

Design Principles

Start with a documented reference architecture that defines Oracle versions, workload classes, hypervisor choice, SLAs, patching cadence, RPO and RTO, monitoring, and licensing boundaries before implementation begins. The VMware baseline is especially strong on this point and remains relevant because the operational failure modes are the same on Nutanix.

Favor predictable performance over maximum consolidation. That means right-sized VMs, preserved failover headroom, NUMA-aware sizing, and storage layouts that separate conflicting IO patterns rather than forcing everything into one generic build pattern.

Hardware and Platform Topology

Use the Nutanix Cloud Platform with External Storage for serious Oracle production deployments. Nutanix explicitly recommends all-flash storage for Oracle Database instances and points to separate hybrid tiers only for lower-cost backup or archive retention.

CPU selection should favor high clock speed and balanced socket design. Nutanix recommends at least 12 cores per socket on dual-socket servers and at least a 2.9 GHz CPU with strong per-core performance for production Oracle databases, while its reference architecture validation used modern Intel Gold and Platinum processors in 25GbE and 100GbE environments.

Memory should be balanced across channels and aligned to NUMA boundaries where practical. Larger Oracle VMs should be designed with explicit NUMA awareness because Oracle performance is sensitive to remote memory access and oversized VM layouts.

Networking should start at redundant 25GbE and move to 100GbE where RAC, backup windows, high-density consolidation, or NVMe/TCP throughput demand it.

Nutanix Cluster Design

Cluster design should begin with resilience and maintenance assumptions, not just consolidation targets. Fault Tolerance (FT) defines how many simultaneous node failures a cluster can withstand, while traditional Nutanix deployments also require sizing for Replication Factor (RF), which determines how many copies of data are stored across the cluster. However, when attaching an Everpure FlashArray, Nutanix RF configuration is not required.

With Everpure, Nutanix AHV continues to run on bare metal from each node's local boot drive, that does not change. What changes is the storage layer beneath it: the AOS Controller VM (CVM) services, and all the data they manage are backed by volumes provisioned from the Everpure FlashArray rather than from local node disks. Those volumes are presented to the Nutanix compute cluster over NVMe/TCP, bypassing the traditional Nutanix Distributed Storage Fabric (DSF) that would normally require RF configuration.

This disaggregated architecture leverages FlashArray's native data protection capabilities rather than Nutanix's replication mechanisms. While RF is not configured for Everpure deployments, a Fault Tolerance target still applies: FT1 for 3- or 4-node clusters, or FT2 for clusters with 5 or more nodes, ensuring the cluster can withstand node-level failures for compute resources.

Nutanix Cloud Platform with Everpure FlashArray requires a minimum of 16 logical vCPUs and 32 GB of vRAM per Controller VM (CVM) on Nutanix Cloud Infrastructure (NCI) compute clusters. For storage‑intensive Oracle clusters, we recommend increasing the CVM to 16 vCPUs and 64 GB vRAM on high‑performance nodes and ensuring the CVM vCPUs are contained within a single socket/NUMA boundary as well as size to the physical core count instead of the hyperthreaded count wherever practical to minimize remote memory access and CVM CPU contention.

Separate management services from Oracle workload clusters wherever practical. Nutanix reference guidance places Prism Central, and shared services such as DNS or monitoring on management infrastructure rather than on the same cluster as critical Oracle workloads.

VM and Workload Strategy

The default production pattern should be one major Oracle workload per VM. This autonomous workload model offers better isolation, easier maintenance planning, clearer ownership, and easier rightsizing.

Hypervisor Guidance

For Oracle on Nutanix AHV, do not overcommit memory. Nutanix explicitly states that Oracle Database VMs on Nutanix AHV should not use memory overcommitment and should be configured with HugePages sized for the combined SGA requirements in the VM.

CPU overcommitment should be conservative for production Oracle, especially where performance consistency or license efficiency matters. Nutanix’s broader recommendations describe lower vCPU-to-pCPU ratios for business-critical applications and reserve higher overcommit for lower-value workloads.

Reference: Nutanix Oracle on Nutanix Best Practices guide – “Oracle Guest VM Configuration” section, which documents the memory overcommitment guidance for Oracle Database VMs on AHV.

Memory

Do not enable Oracle Automatic Memory Management (AMM, MEMORY_TARGET) on VMs using HugePages. AMM and HugePages are mutually exclusive. Use Automatic Shared Memory Management (ASMM, SGA_TARGET + PGA_AGGREGATE_TARGET) instead. It is the supported pattern with HugePages.

Paging

Defend against paging at every layer: no AHV overcommit for Oracle, conservative guest swappiness, and enough cluster headroom to survive a node loss without reclaiming Oracle memory.

NUMA Alignment

Larger Oracle VMs should align to physical NUMA topology where possible. When a VM must span NUMA nodes, expose or preserve an appropriate NUMA-aware topology rather than hiding the physical layout from the guest.

Storage Design

Everpure External Storage Architecture

Design Everpure FlashArray with Nutanix as a disaggregated architecture: Nutanix Acropolis Hypervisor (AHV) provides the compute layer, while FlashArray provides external storage over NVMe/TCP. This allows compute and storage to scale independently while keeping day-to-day provisioning and operations integrated through Prism.

This changes sizing responsibilities: Nutanix compute clusters are sized for CPU, memory, and HA capacity, while FlashArray is sized for IO throughput, latency, snapshots, replication, and clone density.

NVMe/TCP Design

Use a dedicated NVMe/TCP storage network between the Nutanix compute nodes and the FlashArray. Isolate storage traffic from management, live migration, DR replication, and guest or application traffic by using a dedicated storage vSwitch with at least two physical NICs per node, redundant cabling, and dedicated storage VLANs or subnets for FlashArray NVMe/TCP target paths.

In larger designs, segregate storage traffic across two independent fabrics wherever practical so that each fabric presents distinct uplinks, VLANs, and storage interfaces to AHV. This helps preserve independent data paths and reduces the chance that a single switch, NIC, or cabling fault will affect Oracle storage access across the cluster.

Use 25GbE as the minimum production baseline. Nutanix supports 10GbE for NCI compute connectivity, but the Everpure FlashArray deployment guidance calls for 25GbE or 100GbE connectivity depending on the design and throughput target.

Configure jumbo frames on the dedicated Everpure NVMe/TCP storage fabric as the standard storage-network setting. Nutanix recommends MTU 9000 on the new storage vSwitch used for Everpure FlashArray data traffic, and Everpure guidance recommends MTU 9000 on both hosts and storage ports even though 1500 is also supported.

Path redundancy is mandatory. Each Nutanix compute node should maintain multiple independent NVMe/TCP paths to FlashArray target interfaces across redundant switches or failure domains so that the loss of a NIC, cable, switch, or array port does not interrupt database storage access.

The design objective is to isolate NVMe/TCP traffic, provide redundant paths, size the Ethernet fabric to meet workload demand, validate MTU end to end, and confirm FlashArray front-end NIC capacity before deployment.

Volume Groups and RAC on Nutanix AHV

Nutanix Volume Groups are the cleanest way to present shared storage to Oracle RAC on Nutanix AHV because they avoid the complexity of VMware multi-writer VMDK patterns. Two ownership modes are available:

• Default Volume Group — single-CVM ownership; maximizes IO locality. Good fit for moderate workloads.

• Volume Group Load Balancer (VGLB) — distributes vDisk ownership across CVMs for greater aggregate performance. Use when single-CVM throughput becomes the bottleneck.

Volume Groups can be used for business-critical Oracle RAC workloads, including snapshots and clones. This makes them especially attractive in an Everpure-integrated architecture where Nutanix AHV VMs still need clean shared-storage constructs.

ASM and Filesystem Standards

Keep ASM as the Oracle storage abstraction and use external redundancy for DATA and FRA where the platform or array already provides storage resilience. Then apply Nutanix RAC guidance for CSS misscount, persistent disk timeouts, anti-affinity, and dedicated interconnect design.

If file systems are used instead of ASM:

• Mount with filesystemio_options=SETALL.

• Use LVM-striped ext4 or XFS with physical extent size of 1,024 KB.

Oracle Storage Layout

Storage layout should reflect IO behavior, not just administrative convenience. Data, redo, archive logs, backups, and CRS or OCR should not all be mixed into one generic storage pool because their latency sensitivity and write patterns differ materially.

Networking and RAC

Interconnect Separation

Oracle RAC requires disciplined network separation. Use a dedicated VLAN — and where possible, dedicated physical NICs — for RAC heartbeat and Cache Fusion traffic. Do not let RAC interconnect share a path with general application or backup traffic.

Linux guest tuning

• Increase UDP buffer sizes per Oracle-supported kernel networking settings.

• Set NOZEROCONF=yes to /etc/sysconfig/network in RAC configurations.

• Apply persistent disk timeout rules (typically 60 seconds for SCSI) via UDEV rules — not temporary sysfs writes.

NVMe/TCP Network Considerations

For Oracle workloads, treat the NVMe/TCP storage network as a production database I/O path, not as best‑effort infrastructure traffic. Apply QoS, path redundancy, monitoring, and capacity planning with the same rigor used for other latency‑sensitive Oracle data paths, because storage network instability translates directly into higher database response times and greater RAC sensitivity to congestion.

Use jumbo frames (MTU 9000) end‑to‑end as the baseline design standard for Oracle deployments rather than as an optional tuning step. This provides measurable efficiency benefits for Oracle traffic over the NVMe/TCP storage fabric and RAC interconnect, reduces packet processing overhead, and supports the latency and throughput assumptions behind a consolidated Oracle platform; if the switching layer cannot support jumbo frames consistently across all required paths, upgrade the network before deploying the platform.

Availability and Resilience

The recommended availability design is layered and built on a disaggregated Nutanix and Everpure FlashArray architecture. In this model, Nutanix Acropolis Hypervisor (AHV) provides the compute layer, while Everpure FlashArray provides the external storage layer. Use Nutanix HA and anti-affinity for local infrastructure resilience, Oracle RAC for clustered instance resilience, Data Guard for database-aware replication, and RMAN, snapshots, and clones for operational recovery from logical, administrative, or procedural failure.

For RAC, ensure no two nodes of the same cluster land on the same physical host and tune interconnect and storage timeouts to survive realistic node and path failover events. For single-instance systems, prefer Data Guard over relying solely on Nutanix HA restart behavior.

Disaster Recovery

Choose DR mechanisms by business RPO and RTO, not by vendor preference. With regards to resilience, Nutanix Acropolis Hypervisor (AHV) provides the compute layer, while Everpure FlashArray provides the external storage layer, so DR can be implemented at three layers - Nutanix (VM/container), FlashArray (LUN/volume), or the database itself — and these layers can be combined.

For site-level resilience of the external storage layer, FlashArray-native replication and protection policies are a good fit. For Oracle workloads, pair storage replication with Oracle-aware protection such as Data Guard or GoldenGate, where database consistency, role transition, and application-level recovery semantics are required.

Nutanix Synchronous Replication

Both Nutanix SyncRep and Metro Availability are supported with Everpure FlashArray starting in Nutanix AOS 7.5.1, providing complementary zero‑RPO protection options at different scopes.

• SyncRep: Protects selected VMs or consistency groups through Nutanix Disaster Recovery, which is useful when only a subset of workloads on a cluster needs synchronous protection.

• Metro Availability: Provides synchronous replication at the storage container or Volume Group level, protecting everything in scope as a single unit.

In both modes, replication is implemented at the Nutanix layer: guest writes are acknowledged only after both sites commit, preserving the zero‑RPO guarantees that define metro‑class protection. Because this is synchronous replication, the design must meet standard metro prerequisites, including a low‑latency intersite path, typically 5ms round trip or less, so commit latency remains within an acceptable range for tier‑1 workloads.

Without a correctly placed witness, Metro and SyncRep configurations depend on manual intervention and are more exposed to mis‑coordinated failover decisions. The witness arbitrates failover, prevents split‑brain, and automates pause/failover behavior in common fault scenarios. To do this reliably, the Witness Service must run in a third site or cluster separate from the two synchronous‑replication sites, so it has an independent view of site and link health.

Operationally, this extends the disaggregated compute-and-storage model into a metro-scale business-continuity solution, making it suitable for tier-1 workloads that demand zero RPO and near-zero RTO.

Backup. Cloning, and Recovery

for speed, density, and operational recovery. RMAN provides the recovery semantics Oracle Support expects, but Everpure snapshots should be the preferred operational recovery mechanism for fast rollback, rapid cloning, and frequent recovery points.

Managed Snapshots

Managed snapshots are initiated from Nutanix Prism, either on demand or via protection policies. When a managed snapshot is taken, Nutanix uses the FlashArray snapshot API to create native FlashArray volume snapshots for the VM disks and/or Nutanix Volume Groups and records the associated VM and volume metadata so that these snapshots can be used safely for recovery and cloning workflows.

During this process, Nutanix maintains a metadata view of the recovery point, while Everpure FlashArray provides the underlying storage‑level snapshot. This allows Prism to present VM‑ and application‑level snapshot awareness while FlashArray supplies the actual point‑in‑time volume images.

Changed Block Tracking (CBT) for Nutanix AHV is used by backup and replication workflows that compare snapshots to identify changed regions, enabling more efficient incremental data transfer. CBT does not change the fact that FlashArray snapshots are volume‑level, pointer‑based, thin snapshots; each snapshot represents a complete point‑in‑time view of the volume rather than a standalone incremental or differential backup.

• Do: Treat Nutanix-managed snapshots on Everpure FlashArray as fast, storage-based point-in-time recovery copies that Prism can coordinate for VM and volume recovery workflows.

• Do: Use CBT-aware backup or replication tools when you want efficient incremental data movement between recovery points, because CBT identifies changed regions between snapshots for transfer optimization.

• Do: Validate whether the snapshot is crash-consistent or application-consistent before relying on it for database recovery objectives, because volume snapshots alone do not automatically guarantee application-aware recovery state.

• Don’t: Assume CBT changes how the array snapshot is created; CBT is used to detect the changed meta-data regions of the virtual disks by comparing snapshots to optimize backup or replication workflows, not to make the snapshot itself incremental.

• Don’t: Treat storage snapshots alone as a substitute for a full database protection strategy, especially for long-term retention, logical corruption recovery, or compliance use cases.

FlashArray snapshots are excellent for rapid point-in-time recovery, but they are not the same thing as database-native incremental backup sets.

Monitoring and Analytics

Monitoring must be end-to-end, not hypervisor-only. Prism provides VM and cluster visibility, while Pure1 adds array performance, capacity forecasting, data reduction, and workload behavior for FlashArray.

Together, those tools let teams correlate Oracle guest behavior, Nutanix cluster events, and array-side performance characteristics. That cross-layer visibility is essential in a disaggregated design where compute and storage scale differently.

Licensing and Boundaries

Common Pitfalls

These are the recurring design and operational mistakes seen during reviews and post-incident analysis. Each pitfall lists what tends to go wrong and how to avoid it.

Implementation Checklist

Use this as the checklist before any production go-live.

Design

• Reference architecture is documented: Oracle version, hypervisor, SLAs, RPO/RTO, patch windows, workload classes, licensing boundaries.

• Workload classes are mapped to template sizes.

• Storage decision (native vs. Everpure) is made and justified.

Hardware and Platform

• All-flash Nutanix nodes specified.

• Redundant 25GbE minimum, 100GbE where required.

• CPU clock speed, core count, and NUMA balance verified.

• Cluster size supports required FT level with explicit headroom.

• CVM sized appropriately (16 vCPU / 64GB for heavy Oracle).

• Management vs. workload separation in place.

VM and OS

• One major Oracle workload per VM (autonomous model).

• Standard VM templates used.

• HugePages configured; AMM disabled.

• Nutanix AHV: no memory overcommit.

• Persistent UDEV, storage timeout, and network settings deployed.

Storage

• Dedicated Oracle storage container (or FlashArray volumes/host group).

• ASM in use; allocation unit 4 MB.

• Separate vDisks/volumes for DATA, REDO, ARCH, BACKUP, CRS.

• NVMe/TCP NQNs, host groups, and timeouts standardized across all nodes.

RAC

• Anti-affinity rules enforced — no two RAC nodes on the same host.

• Dedicated interconnect VLAN.

• Persistent 60-second SCSI disk timeout where applicable.

• Validated CSS misscount setting.

• Shared storage presentation consistent across all nodes.

Operations

• RMAN-first backup with snapshot/clone augmentation.

• DR pattern matches RPO/RTO targets.

• End-to-end observability: Prism + Pure1 + AWR.

• Hardening, patching, and management isolation in place.