Oracle Database Deployment on Amazon EVS and FSx for NetApp ONTAP: Best Practices

Introduction

Enterprises with existing VMware Cloud Foundation (VCF) investments want to migrate their Oracle databases to AWS without re-architecting applications or retraining operations teams. Deploying Oracle on Amazon EVS requires sub-millisecond storage latency, snapshot-based backup, cross-region DR, and independent storage scaling — all while preserving existing VMware operational workflows.

In this post, we show you how to deploy a complete Oracle database environment on Amazon EVS with Amazon FSx for NetApp ONTAP. You'll provision VMware Cloud Foundation on AWS bare metal instances, mount FSx for ONTAP as NFS datastores for your Oracle volumes, and configure SnapMirror for cross-region disaster recovery. This architecture gives you managed services that scale storage throughput and IOPS independently. This reduces your operational overhead for running Oracle on VMware in the cloud. By the end, you'll have a working Oracle deployment with automated backup, point-in-time recovery, and cross-region DR.

In this post, you'll learn how to:

• Deploy Oracle database VMs on Amazon EVS running VMware Cloud Foundation 5.2.2
• Provision and mount Amazon FSx for NetApp ONTAP as NFS datastores for Oracle data and log volumes
• Configure SnapMirror replication for cross-region disaster recovery
• Set up SnapCenter for Oracle-aware backup, cloning, and point-in-time recovery
• Evaluate migration options for moving existing Oracle workloads from on-premises VMware to EVS, including HCX, SnapMirror, PDB Relocation, and RMAN

Amazon EVS directly runs VMware Cloud Foundation (VCF) environments on Amazon EC2 bare metal instances within an Amazon VPC. Amazon FSx for NetApp ONTAP provides managed ONTAP storage with NFS, SMB, iSCSI, and NVMe over TCP access. For more information, refer to FSx for NetApp ONTAP features. FSx for NetApp ONTAP can deliver sub-millisecond response times, multiple GBps of throughput, and up to 80,000 IOPS per file system (refer to FSx for NetApp ONTAP performance).

---

Solution architecture

This section describes a highly available Oracle database deployment on Amazon EVS with Amazon FSx for NetApp ONTAP storage across two AWS regions. Figure 1 illustrates the numbered data flow from on-premises through hybrid connectivity into the production EVS environment and cross-region disaster recovery (DR).

The architecture consists of eight functional components, described in the Architecture components and Key components sections along with the key AWS and VMware services involved.

Architecture components

These numbered items correspond to the data flow shown in the diagram.

1. Hybrid link – On-premises data center connects to AWS through AWS Direct Connect for dedicated, low-latency bandwidth.
2. Transit routing – AWS Transit Gateway routes traffic between the production VPC, DR region, and on-premises networks.
3. Workload landing – Traffic reaches the EVS Database Cluster running on i7i.metal-24xl Amazon EC2 bare metal instances with VCF 5.2.2.
4. Live migration – VMware HCX migrates Oracle VMs from on-premises VMware to EVS with near-zero downtime using vMotion or bulk migration.
5. NFS data path – Each ESXi host mounts Amazon FSx for NetApp ONTAP as an NFS datastore. Oracle VMs access database volumes as block devices (VMDKs on the NFS datastore) with sub-millisecond latency and up to 80,000 IOPS. Each host has its own independent NFS path to FSx for ONTAP, distributing bandwidth across the cluster.
6. Cross-region DR – SnapMirror asynchronously replicates FSx for ONTAP volumes (data, logs, binaries) to the DR region with configurable RPO.
7. Dynamic routing – NSX Tier-0 gateway peers through BGP with Amazon VPC Route Server. This is one-way BGP. Route Server listens for routes advertised by NSX and writes them to the VPC route table, but does not advertise VPC routes back to NSX.
8. DR failover – On failover, Transit Gateway routes to the DR region where pre-provisioned standby Oracle VMs mount the SnapMirror replica volumes.

Key components

This list describes the primary services and tools in this architecture.

• Amazon EVS – Runs VCF 5.2.2 on Amazon EC2 bare metal instances (i4i.metal or i7i.metal-24xl). Local NVMe drives provide vSAN storage. Supports up to 32 hosts per cluster (minimum 4) with ESXi 8.0U3g.
• Amazon FSx for NetApp ONTAP – Single-AZ deployment that provides NFS datastores for Oracle database volumes. Each ESXi host mounts volumes directly. Oracle VMs access block devices (VMDKs), not NFS. The service can deliver sub-millisecond latency, up to 80,000 IOPS, and 4,096 MB/s throughput. We recommend 100% SSD storage with tiering policy set to none so that cold block retrieval from the capacity tier does not affect Oracle workloads. Important: Read and write throughput are asymmetric. On a 6 GB/s filesystem, read throughput reaches up to 6 GB/s. Write throughput is limited to approximately 1 GB/s. Size throughput capacity based on your write-heavy workload requirements, not just read expectations.
• NSX-T networking – Provides micro-segmentation with Tier-0/Tier-1 gateways. Tier-0 peers through BGP with VPC Route Server. Dedicated Tier-1 isolates DB segments. Distributed Firewall restricts Oracle listener access (TCP 1521). Security groups are not enforced on VLAN interfaces.
• Amazon VPC Route Server – Provides dynamic BGP peering between NSX Tier-0 edge and the AWS VPC. Route Server listens for routes from NSX and programs them into VPC route tables, which can remove the need for manual static route management within the VPC. Note that routes remain static once they reach Transit Gateway because TGW cannot learn routes from VPC Route Server.
• AWS Transit Gateway – Connects production and DR regions through inter-region peering. Provides the routing path for DR failover.
• AWS Direct Connect – Provides dedicated hybrid connectivity between on-premises data center and AWS.
• VMware HCX – Provides live workload mobility from on-premises VMware clusters through vMotion (near-zero downtime) or bulk migration with network extension (L2 stretch).
• SnapMirror – Replicates FSx for ONTAP volumes (data, logs, binaries) between regions for DR. Can remove the need for Oracle Data Guard licensing in many cases.
• SnapCenter – Provides Oracle-aware backup using ONTAP snapshots. Completes in seconds regardless of database size. Supports PITR and FlexClone for dev/test.
• NFS datastore architecture – ESXi hosts mount FSx for ONTAP volumes as NFS datastores (not from within guest VMs). Oracle VMs access block devices (VMDKs) that appear as local disks. Each ESXi host communicates directly with FSx for ONTAP using per-host network bandwidth, with no NSX Edge bottleneck. Refer to Storage architecture for the full design rationale.

---

Factors to consider for Oracle database deployment on EVS

Before you begin deployment, evaluate your Oracle workload requirements against the available infrastructure options. The decisions you make for instance types, VM sizing, and storage architecture directly affect database performance, cost, and operational complexity.

These sections help you make informed choices for each layer of the stack.

EC2 instance type selection for ESXi hosts

Amazon EVS currently supports two bare metal instance types for ESXi hosts. The choice depends on whether you prioritize per-core compute speed (i7i) or per-host memory and storage density (i4i). For most new Oracle deployments, i7i is the better choice because Oracle query performance is sensitive to CPU instruction throughput and storage I/O latency. If you need to consolidate many Oracle instances on fewer hosts to reduce licensing costs, i4i offers more vCPUs and memory per host.

This table compares the two instance types:

Instance Type	Processor	vCPUs	Memory	Local NVMe (vSAN)	Network	Key Advantage
i4i.metal	3rd Gen Intel Xeon (Ice Lake)	128	1,024 GiB	30 TB (AWS Nitro SSD)	75 Gbps	Higher memory/storage density per host
i7i.metal-24xl	5th Gen Intel Xeon (Emerald Rapids)	96	768 GiB	22.5 TB (3rd Gen Nitro SSD)	56.25 Gbps	23% better compute, 50% lower I/O latency, 10%+ better price-performance

Selection guidance for Oracle workloads:

• i7i.metal-24xl (recommended for new deployments): 5th Gen Intel Xeon delivers up to 23% better compute performance, critical for Oracle CPU-bound queries. 3rd Gen AWS Nitro SSDs provide up to 50% better real-time storage performance and up to 50% lower I/O latency for vSAN (based on AWS i7i instance type specifications). These improvements directly benefit Oracle redo log writes and temp tablespace operations. The 56.25 Gbps network bandwidth supports NFS datastore throughput to FSx for ONTAP. Torn write prevention up to 16KB block sizes helps reduce database double-write penalties.

• i4i.metal: Higher per-host density (128 vCPUs / 1,024 GiB RAM / 30 TB NVMe) suits environments requiring fewer, larger hosts. For example, consolidating many Oracle instances on fewer ESXi hosts can reduce VMware licensing costs.

VCF compatibility:

Both instance types support VCF 5.2.2 with ESXi 8.0U3g. An EVS environment supports 4–32 hosts per cluster. You can mix instance types across clusters within the same SDDC, allowing a cost-optimized App cluster (i7i) alongside a memory-dense DB cluster (i4i). Alternatively, you can standardize on i7i for the latency benefits.

VM sizing for Oracle database guests

Size Oracle database VMs based on these workload characteristics:

• Allocate vCPU count matching Oracle CPU_COUNT parameter or licensing entitlement
• Size memory for SGA + PGA + OS overhead (typically 75-85% of allocated VM memory for SGA)
• Configure VM swap on vSAN datastore (not NFS). vSAN uses local NVMe with single-digit millisecond latency, far lower than FSx for ONTAP network storage.
• Use NUMA-aware VM placement for VMs exceeding single-socket core count
• Place OS swap and Oracle temp tablespace on the vSAN datastore. Both host types include local NVMe drives that form the vSAN, providing single-digit ms latency at no additional cost. Anything that does not require DR replication (swap, temp, staging) benefits from vSAN's lower latency.

Storage architecture: vSAN + FSx for NetApp ONTAP

The recommended approach splits storage responsibilities between two tiers. vSAN (backed by the local NVMe drives on each ESXi host) handles low-latency, non-replicated workloads such as VM boot disks, OS swap, and Oracle temp tablespace. Amazon FSx for NetApp ONTAP handles Oracle data files and redo logs that require snapshot-based backup and cross-region replication. ESXi hosts mount FSx for ONTAP volumes as NFS datastores, and Oracle VMs access standard block devices (VMDKs), not NFS mounts.

This separation gives you the lowest possible latency for transient I/O (swap, temp) while adding snapshot, clone, and SnapMirror capabilities for your persistent database files.

Why NFS datastore (host-level) instead of in-guest NFS (dNFS)? With in-guest NFS, all Oracle NFS traffic routes through the NSX overlay and an NSX Edge node before reaching FSx for ONTAP. This creates a single Edge chokepoint and adds an NSX router hop of latency. With NFS datastores, each ESXi host talks NFS directly to FSx for ONTAP using its own network bandwidth. There is no Edge bottleneck and no extra latency hop. Oracle VMs get block devices on the datastore that look like local drives.

This table shows the recommended volume placement for each Oracle component:

Volume	Storage Tier	Presentation to VM	Rationale
VM OS + Oracle Binary	vSAN (local NVMe)	VMDK (vSAN datastore)	Low-latency boot, local to host
OS Swap + Oracle Temp	vSAN (local NVMe)	VMDK (vSAN datastore)	Single-digit ms latency, no DR replication needed, included with host
Oracle Data Files	FSx for ONTAP NFS Datastore	VMDK (FSx for ONTAP datastore)	Scalable capacity, snapshots, replication
Oracle Redo + Archive Logs	FSx for ONTAP NFS Datastore	VMDK (FSx for ONTAP datastore)	Consistent backup, SnapMirror DR
Oracle Control Files	FSx for ONTAP NFS Datastore	VMDK (FSx for ONTAP datastore)	Duplicated across data + log datastores

FSx for NetApp ONTAP sizing:

Parameter	Minimum	Recommended for Oracle	Maximum
SSD Storage Capacity	1,024 GiB	Size for 1.5× current data + 20% growth (100% SSD, no capacity pool)	192 TiB
Provisioned SSD IOPS	3 per GiB (auto)	Workload-dependent	80,000
Throughput Capacity	128 MB/s	512 MB/s minimum; 1,024–2,048 MB/s for production Oracle	4,096 MB/s
NVMe Read Cache	Included	Up to 2 TiB (delivers higher effective IOPS)	2 TiB

Important: use 100% SSD for Oracle. We recommend against using capacity pool tiering for Oracle database volumes. You do not want to risk hitting a cold block that has migrated to the capacity tier because the latency penalty for retrieving tiered data is unacceptable for production Oracle I/O. Keep tiering policy set to none for all Oracle volumes and size SSD capacity for your full dataset.

Important: SSD capacity planning. If the SSD tier fills to capacity, FSx for ONTAP blocks writes. Customers have experienced this in production. Monitor SSD utilization and provision headroom (minimum 20% free) to reduce the risk of write stalls during peak load.

Important: read/write throughput asymmetry. Amazon FSx for NetApp ONTAP throughput capacity is not symmetric. On a 6 GB/s filesystem, read throughput can reach the full 6 GB/s, but write throughput is limited to approximately 1 GB/s. Size your throughput capacity based on your Oracle write workload requirements (redo log writes, bulk inserts, RMAN backups) rather than read-only benchmarks. Many customers are surprised by this asymmetry during production load testing.

Critical configuration:

• Deployment type: Single-AZ only (required for EVS NFS datastore)
• Tiering policy: Set to none for all Oracle volumes (data, logs, and binaries). We recommend against using capacity pool tier for any Oracle workload component.
• SSD capacity: Provision 100% SSD for your full dataset with 20% headroom. Monitor utilization because writes are blocked if SSD fills.
• Storage efficiency: Enable (deduplication + compression) for non-production; evaluate for production based on data reducibility
• Throughput and IOPS can be adjusted on-the-fly without downtime as workload changes

NFS datastore configuration

ESXi hosts mount Amazon FSx for NetApp ONTAP volumes as NFS datastores. The Oracle VM does not interact with NFS; it accesses standard VMDK block devices on the datastore. This approach provides:

• Per-host bandwidth: Each ESXi host has its own NFS connection to FSx for ONTAP, using the full host network bandwidth (56.25 Gbps on i7i / 75 Gbps on i4i)
• No Edge bottleneck: In-guest NFS would funnel all Oracle I/O through a single NSX Edge node
• No extra latency: Datastore access removes the NSX router hop that in-guest NFS would add
• Operational simplicity: Oracle accesses local block devices. No NFS tuning, no dNFS configuration, and no /etc/oranfstab required.

ESXi NFS datastore mount settings (configured in vSphere when adding the datastore):

Setting	Value
NFS Version	NFSv3
Max NFS Volumes	256 (ESXi default)
Read/Write buffer	65536 (ESXi default for NFSv3)

Note on Oracle dNFS: Oracle Direct NFS (dNFS) is a valid technology for direct NFS access from within the guest OS. However, for this EVS architecture it is not recommended because in-guest NFS traffic funnels through a single NSX Edge node, creating a bandwidth bottleneck. The NFS datastore approach gives each host its own direct path to FSx for ONTAP.

Network architecture

Amazon EVS uses VLAN subnets (you define these at environment creation; they cannot be changed later) to segment traffic:

VLAN Subnet	Purpose
Management	ESXi management, vCenter, NSX Manager
vMotion	Live VM migration between hosts
vSAN	Inter-host vSAN replication traffic
Host VTEP Overlay	NSX overlay tunnel endpoints (hosts)
Edge VTEP Overlay	NSX overlay tunnel endpoints (edge nodes)
HCX	VMware HCX migration traffic

VPC Route Server replaces static routes within the VPC. NSX Tier-0 gateways peer through BGP with Route Server endpoints, which allows dynamic route advertisement from the VCF overlay into VPC route tables. This is one-way BGP: Route Server listens for routes from NSX and programs them into the VPC route table, but does not advertise VPC routes back to NSX. Note that beyond the VPC, routes remain static at Transit Gateway. TGW cannot learn routes from VPC Route Server.

NSX-T segmentation for Oracle:

• Dedicated Tier-1 gateway for production database segments (DB subnets)
• Separate Tier-1 for application tier (App subnets) and DMZ
• Distributed firewall rules restrict Oracle listener access (TCP 1521) to authorized application segments only
• Micro-segmentation between Oracle instances prevents lateral movement

Important: Security group rules are not enforced on VLAN subnet interfaces. Use network ACLs and NSX distributed firewall for traffic control.

High availability and disaster recovery

Layer	Mechanism	RPO	RTO
VM Compute	vSphere HA (automatic restart on surviving hosts)	0	Minutes
Storage (same region)	FSx for ONTAP HA pairs (automatic failover)	0	Transparent
Cross-region DR	SnapMirror replication	Configurable (minutes)	Manual failover
Oracle Application	Data Guard (optional, on top of SnapMirror)	0 (sync) or seconds (async)	Minutes

Key factors:

• SnapMirror replication frequency determines RPO. Configure based on business requirements.
• Pre-provision standby Oracle VMs in the DR cluster to reduce RTO
• Replicate binary volumes so that Oracle installation is not required during recovery
• Automate failover with Ansible/SnapCenter to reduce human error

DR licensing consideration: If you run a separate Oracle VM in the DR site that is actively running (even idle, waiting for failover), Oracle considers this a licensed instance. This effectively doubles your Oracle license cost. An alternative approach is to replicate the entire Oracle VM through SnapMirror or vSAN replication. Power it on only during an actual failover event. This can remove the second license cost. Either approach is valid. Choose based on your RTO requirements versus licensing budget.

---

Step-by-step deployment procedures

This section walks through the end-to-end deployment workflow: provisioning the Oracle VM, creating FSx for ONTAP storage volumes, mounting NFS datastores in vSphere, installing Oracle 19c, and configuring SnapMirror for cross-region DR. Complete the prerequisites first, then follow Steps 1 through 8 in order.

Prerequisites

• Amazon EVS environment deployed (VCF 5.2.2, ESXi 8.0U3g)
• Minimum 4 hosts per cluster; dedicated DB cluster recommended for Oracle
• VPC with Route Server endpoints, Transit Gateway, and Direct Connect configured
• IAM permissions for FSx for ONTAP provisioning
• VCF license entitlement (BYOL from Broadcom)

Step 1: Deploy Oracle VM on EVS

1. Log into the vSphere Client connected to your EVS vCenter.

2. Create a new Virtual Machine in the Production DB Cluster:

   • Guest OS: Red Hat Enterprise Linux 8 (64-bit) or Oracle Linux 8
   • vCPU: Size per Oracle workload (8–32 vCPU typical)
   • Memory: 32–256 GiB based on SGA/PGA requirements
   • Disk: 100 GiB on vSAN datastore (OS + Oracle Home + swap + temp tablespace)
   • Network: Attach to DB segment on the prod-trusted Tier-1 gateway

3. Power on the VM and configure the guest OS:

# Set hostname
hostnamectl set-hostname ora-db1

# Create swap on vSAN-backed disk (local NVMe, single-digit ms latency)
# The vSAN datastore is already available as the VM's primary disk
# Allocate a dedicated partition or LV for swap
lvcreate -L 16G -n swap vg_os
mkswap /dev/vg_os/swap
swapon /dev/vg_os/swap
echo '/dev/vg_os/swap swap swap defaults 0 0' >> /etc/fstab

# Install Oracle prerequisites
sudo yum install -y oracle-database-preinstall-19c python3

4. For HA/DR, consider replicating the entire Oracle VM rather than maintaining a separate licensed instance in the DR cluster (see DR Licensing Consideration above).

Step 2: Provision FSx for NetApp ONTAP

1. Open the Amazon FSx console, select Create file system, then select Amazon FSx for NetApp ONTAP.

2. Select Standard create and configure:

Setting	Value
Deployment type	Single-AZ (required for EVS)
SSD storage capacity	Size for Oracle data + logs + 20% headroom
Throughput capacity	512–2,048 MB/s (size for write workload; see asymmetry note)
IOPS	Automatic (3/GiB) or user-provisioned up to 80,000
VPC	Same VPC as EVS environment
Subnet	EVS service access subnet, same AZ as DB cluster
Security group	Allow NFS (TCP 2049, 111, 635) from EVS management VLAN

3. Set the fsxadmin password (required for ONTAP CLI automation).

4. Create an SVM (Storage Virtual Machine) with vsadmin password.

5. Disable automatic daily backups. Use SnapCenter for Oracle-aware scheduling instead.

6. After creation, select SVM, select Endpoints, and copy the NFS DNS name.

Step 3: Create Oracle Database Volumes

Connect to the FSx for ONTAP cluster using SSH (ssh fsxadmin@<management-endpoint>) and create volumes:

# Oracle binary volume
vol create -volume ora_db1_bin -aggregate aggr1 -size 50G \
  -state online -policy default -tiering-policy none \
  -junction-path /ora_db1_bin

# Oracle data volume
vol create -volume ora_db1_data -aggregate aggr1 -size 500G \
  -state online -policy default -tiering-policy none \
  -junction-path /ora_db1_data

# Oracle log volume (redo + archive)
vol create -volume ora_db1_log -aggregate aggr1 -size 250G \
  -state online -policy default -tiering-policy none \
  -junction-path /ora_db1_log

Set -tiering-policy none to pin all data to SSD tier. Size the log volume for 24+ hours of archive logs.

Step 4: Mount FSx for ONTAP as NFS Datastore in vSphere

1. In vSphere Client, select the DB Cluster, then select Configure, Storage, New Datastore.

2. Select NFS, then select NFS 3.

3. Enter:

   • Server: svm-<id>.fs-<id>.fsx.<region>.amazonaws.com
   • Folder: /ora_db1_data
   • Datastore name: fsx-ora-db1-data

4. Repeat for binary (/ora_db1_bin) and log (/ora_db1_log) volumes.

5. Verify all three datastores show correct capacity in the cluster storage view.

Step 5: Create Oracle VMDKs on FSx for ONTAP Datastores

With the NFS datastores mounted at the ESXi host level (Step 4), create virtual disks for Oracle on these datastores:

1. In vSphere Client, select the Oracle VM, select Edit Settings, then select Add New Device, Hard Disk.

2. Create these VMDKs:

VMDK	Datastore	Size	Guest Mount	Purpose
Hard Disk 2	fsx-ora-db1-data	500 GiB	/u02	Oracle data files
Hard Disk 3	fsx-ora-db1-log	250 GiB	/u03	Oracle redo + archive logs
Hard Disk 4	fsx-ora-db1-bin	50 GiB	/u01	Oracle Home binaries

3. Select Thick Provision, Eager Zeroed for data and log VMDKs (best Oracle performance).

4. Inside the Oracle VM guest OS, partition and mount the new disks:

# Identify new disks
lsblk

# Create filesystem on each disk (example: /dev/sdb for data)
mkfs.xfs /dev/sdb
mkfs.xfs /dev/sdc
mkfs.xfs /dev/sdd

# Create mount points
mkdir -p /u01 /u02 /u03

# Mount
mount /dev/sdd /u01   # Oracle Home (binaries)
mount /dev/sdb /u02   # Oracle data files
mount /dev/sdc /u03   # Oracle redo + archive logs

# Persist in /etc/fstab
cat >> /etc/fstab << EOF
/dev/sdb  /u02  xfs  defaults,noatime  0 0
/dev/sdc  /u03  xfs  defaults,noatime  0 0
/dev/sdd  /u01  xfs  defaults,noatime  0 0
EOF

# Set ownership
chown -R oracle:oinstall /u01 /u02 /u03

Key insight: The Oracle VM accesses /u02 and /u03 as local XFS block devices. It has no awareness that the underlying storage is an NFS datastore backed by FSx for ONTAP. All NFS communication happens at the ESXi host level, where each host uses its own network path to FSx for ONTAP.

Step 6: Install and Configure Oracle 19c

# As oracle user
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
cd $ORACLE_HOME
./runInstaller -silent -responseFile /path/to/db_install.rsp

Create the database with data on /u02 and logs on /u03:

CREATE DATABASE orcl
  DATAFILE '/u02/oradata/orcl/system01.dbf' SIZE 1G
  LOGFILE GROUP 1 '/u03/oralogs/orcl/redo01.log' SIZE 512M,
          GROUP 2 '/u03/oralogs/orcl/redo02.log' SIZE 512M,
          GROUP 3 '/u03/oralogs/orcl/redo03.log' SIZE 512M;

Oracle accesses /u02 and /u03 as local XFS filesystems. Standard Oracle ASM or filesystem-based storage management applies. No NFS-specific Oracle configuration is needed because the NFS layer is abstracted by the ESXi hypervisor.

Step 7: Set Up SnapMirror for Cross-Region DR

1. Peer clusters (production → DR):

cluster peer create -peer-addrs <dr-cluster-intercluster-ip> \
  -username fsxadmin -initial-allowed-vserver-peers *

2. Peer SVMs:

vserver peer create -vserver svm-prod -peer-vserver svm-dr \
  -peer-cluster FSxDR -applications snapmirror

3. Create DP volumes on DR FSx for ONTAP:

vol create -volume ora_db1_bin  -aggregate aggr1 -size 50G  -state online -type DP
vol create -volume ora_db1_data -aggregate aggr1 -size 500G -state online -type DP
vol create -volume ora_db1_log  -aggregate aggr1 -size 250G -state online -type DP

4. Create and initialize SnapMirror:

snapmirror create -source-path svm-prod:ora_db1_data \
  -destination-path svm-dr:ora_db1_data \
  -throttle unlimited -policy MirrorAllSnapshots -type DP

snapmirror create -source-path svm-prod:ora_db1_log \
  -destination-path svm-dr:ora_db1_log \
  -throttle unlimited -policy MirrorAllSnapshots -type DP

snapmirror create -source-path svm-prod:ora_db1_bin \
  -destination-path svm-dr:ora_db1_bin \
  -throttle unlimited -policy MirrorAllSnapshots -type DP

# Initialize
snapmirror initialize -destination-path svm-dr:ora_db1_data
snapmirror initialize -destination-path svm-dr:ora_db1_log
snapmirror initialize -destination-path svm-dr:ora_db1_bin

Step 8: Configure SnapCenter Backup

1. Deploy SnapCenter Server or use SnapCenter SaaS.

2. Add FSx for ONTAP storage system using the cluster management IP.

3. Install SnapCenter Plugin for Oracle on each Oracle VM.

4. Create backup policies:

Policy	Scope	Frequency	SnapMirror Update
Full DB Backup	Data + Control + Archive	Every 4–6 hours	Yes
Archive Log	Archive logs only	Every 10–15 minutes	Yes

5. Create resource groups, assign policies, and schedule.

---

Database migration from on-premises VMware to EVS

Option 1: VMware HCX (Live Migration)

For enterprises with existing VMware on-premises:

1. Deploy HCX Connector on-premises, HCX Cloud Manager on EVS.
2. Create site pairing and network extensions (L2 stretch).
3. Migrate Oracle VMs using HCX vMotion (zero downtime) or Bulk Migration.
4. Post-migration: storage vMotion Oracle VMDKs from vSAN to FSx for ONTAP NFS datastores for snapshot/replication capabilities.

Option 2: SnapMirror (ONTAP-to-ONTAP)

If on-premises Oracle already uses NetApp ONTAP storage:

1. Establish SnapMirror between on-prem ONTAP and AWS FSx for ONTAP.
2. Incrementally replicate until cutover.
3. At switchover: quiesce Oracle, flush archive logs, final SnapMirror sync, break mirror.
4. Mount FSx for ONTAP volumes on EVS Oracle VM, recover database, open for service.

Option 3: Oracle PDB Relocation (Multitenant)

For Oracle databases already in PDB/CDB multitenant model:

1. Create target CDB on EVS with FSx for ONTAP storage.
2. Use PDB hot clone to relocate PDBs from on-premises CDB to AWS CDB.
3. Minimal service interruption. Only final switchover requires brief outage.

Option 4: RMAN Backup/Restore (Non-ONTAP On-Prem)

If Oracle runs on non-ONTAP storage on-premises:

1. Create RMAN backup, stage to Amazon S3 using AWS DataSync or Direct Connect.
2. Provision Oracle VM on EVS, mount FSx for ONTAP volumes.
3. Restore from RMAN backup, apply archive logs.
4. Open database and redirect applications.

---

Day-2 operations

Snapshot backup

Full database snapshots complete in seconds regardless of database size. This is a storage-layer operation managed by SnapCenter.

Point-in-time recovery

In SnapCenter, select the SCN or timestamp, mount the log snapshot, restore the data snapshot, apply archive logs, and open with RESETLOGS.

Database cloning

SnapCenter FlexClone creates space-efficient database copies in minutes. Clones share unchanged blocks with the source and consume storage only for deltas. Use for dev/test, patch validation, and reporting.

HA failover procedure

1. Break SnapMirror on DR volumes.
2. Mount volumes on DR Oracle VM.
3. Recover to last available archive log.
4. Open database; update DNS/connection strings.

---

Security

Layer	Control
Network segmentation	NSX-T Tier-1 gateways isolate DB/App/DMZ segments
East-west traffic	NSX Distributed Firewall: restrict TCP 1521 to authorized app segments
North-south traffic	FortiGate or equivalent inspection VPC (FTG) for ingress/egress filtering
Encryption at rest	FSx for ONTAP volumes encrypted with AWS Key Management Service (AWS KMS)
Encryption in transit	VPC encryption for NFS traffic; IPsec for SnapMirror cross-region
Database encryption	Oracle TDE (Transparent Data Encryption) for additional protection
Administrative access	Zero-trust access (e.g., Banyan, Zscaler) for VMware admin consoles
VLAN subnet security	Network ACLs (security groups not enforced on VLAN interfaces)

---

Cost optimization

Component	Strategy
EC2 bare metal hosts	Compute Savings Plans or Reserved Instances (up to 54% savings)
Instance type selection	i7i.metal-24xl delivers 10%+ price-performance over i4i.metal
FSx for ONTAP throughput	Right-size for write workload (read/write asymmetry); adjust on-the-fly
FSx for ONTAP storage	100% SSD for Oracle (no capacity pool tiering); use storage efficiency for non-prod
Data transfer	Place FSx for ONTAP in same AZ as EVS cluster; use Direct Connect for hybrid
SnapMirror replication	Schedule frequency based on RPO (less frequent = lower transfer cost)
Oracle DR licensing	Replicate Oracle VMs instead of running hot standby to reduce double licensing
Non-production	Use fewer hosts with smaller i7i instances; tiering for dev/test data

---

Summary

Deploying Oracle databases on Amazon EVS with Amazon FSx for NetApp ONTAP provides high availability, cross-region DR, and sub-millisecond storage latency while combining VMware operational consistency with AWS cloud economics:

• Performance: The i7i.metal-24xl instance type provides up to 23% better compute and up to 50% lower storage I/O latency (based on AWS Nitro SSD benchmarks). FSx for ONTAP NFS datastores deliver sub-millisecond latency with up to 80,000 IOPS and per-host bandwidth distribution.
• Availability: vSphere HA, SnapMirror cross-region replication, and optional Oracle Data Guard
• Manageability: SnapCenter for backup, clone, and recovery, completing in seconds regardless of database size
• Migration flexibility: HCX (live), SnapMirror (ONTAP-to-ONTAP), PDB Relocation (multitenant), RMAN (universal)
• Security: NSX micro-segmentation, AWS KMS encryption, and zero-trust access
• Cost efficiency: Up to 10% better price-performance with i7i; on-the-fly throughput/IOPS adjustment; Savings Plans

This architecture provides you with high availability, cross-region DR, and storage-based backup and cloning similar to Oracle RAC and Data Guard functions while maintaining your familiar VMware operational tooling and procedures.

Next steps

To get started with this deployment:

1. Provision an Amazon EVS environment in your target region. Refer to the Amazon EVS User Guide for setup instructions.
2. Deploy an Amazon FSx for NetApp ONTAP file system in the same VPC and Availability Zone as your EVS cluster.
3. Follow the step-by-step procedures in this post to mount NFS datastores, create Oracle VMDKs, and configure SnapMirror DR.
4. Test in a non-production environment first, then migrate production Oracle workloads using one of the migration options described in this post.

---

Clean up

To stop incurring charges after testing this deployment, remove the following resources in this order:

1. Oracle VMs – Power off and delete Oracle database VMs from the vSphere inventory.
2. NFS datastores – Unmount FSx for ONTAP datastores from ESXi hosts in vSphere.
3. SnapMirror relationships – Delete SnapMirror relationships and DP volumes on the DR FSx for ONTAP file system.
4. FSx for ONTAP file systems – Delete both production and DR file systems from the Amazon FSx console. This action deletes all volumes and data on those file systems.
5. Amazon EVS environment – Delete the EVS environment from the Amazon EVS console. This terminates the underlying EC2 bare metal instances.
6. Networking – Remove Transit Gateway attachments, VPC Route Server configurations, and Direct Connect connections if they were created solely for this deployment.

Important: Deleting an FSx for ONTAP file system permanently removes all data. Confirm that you have backed up any data you need before proceeding.

---

Additional resources

• Amazon EVS User Guide
• EVS Supported VCF Versions and Instance Types
• Configure FSx for ONTAP as NFS Datastore for EVS
• FSx for NetApp ONTAP with EVS
• Amazon EVS Pricing
• Introducing Amazon EVS — AWS Blog
• NetApp Automation Toolkit for Oracle