Skip to content

AWS 2026-10-02

Read original ↗

Deploy Oracle Database step by step on Amazon EVS with FSx for ONTAP

Summary

The operational companion to AWS's reference architecture Architect highly available Oracle Database on Amazon EVS and FSx for ONTAP. Where the architecture post justified the design, this post is the runbook: the concrete ssh fsxadmin@… ONTAP CLI commands, vSphere datastore-mount clicks, Oracle 19c runInstaller / CREATE DATABASE steps, SnapMirror peering and data-protection-volume creation, and SnapCenter backup-policy configuration that stand up the full stack. It then covers four migration paths for moving existing on-premises Oracle into EVS, and day-2 operations — snapshot backup, point-in-time recovery, and database cloning — all executed as storage-layer (FSx ONTAP) operations rather than Oracle-native ones. The durable system-design content is operational, not new architecture: the key reusable insight is that the Oracle guest sees only local XFS block devices on VMDKs — the NFS/FSx-ONTAP layer is fully abstracted by the ESXi hypervisor, so standard Oracle filesystem storage management applies with no NFS-specific Oracle configuration, while the storage team still gets snapshot/clone/replicate semantics underneath.

Key takeaways

  1. The Oracle guest never sees NFS — the hypervisor abstracts it. The deployment mounts FSx ONTAP volumes as NFS datastores at the ESXi host level (Step 4), then creates VMDKs on those datastores (Step 5) that the Oracle VM formats as local XFS block devices (/u01 Oracle Home, /u02 data files, /u03 redo + archive logs). "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." → No NFS-specific Oracle config (no dNFS tuning), standard ASM-or-filesystem storage management applies, and each host uses its own NFS network path. (Source: sources/2026-10-02-aws-deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-ontap)

  2. ONTAP volume layout + pin-to-SSD is explicit CLI. Three volumes per DB — oradb1bin (50G), oradb1data (500G), oradb1log (250G, sized for 24h of archive logs) — created via vol create … -tiering-policy none over SSH to the FSx fsxadmin management endpoint. -tiering-policy none pins all data to the SSD tier (no capacity-pool tiering), the operational form of the architecture post's 100%-SSD rule. (Source: sources/2026-10-02-aws-deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-ontap)

  3. Storage security-group opens NFS ports 2049 / 111 / 635; backups handed to SnapCenter, not FSx. The FSx ONTAP file system is Single-AZ (required for EVS), its security group allows NFS from the EVS management VLAN, and automatic daily FSx backups are disabled in favour of SnapCenter's Oracle-aware scheduling. An SVM (storage virtual machine) with a vsadmin password is the NFS serving endpoint. (Source: sources/2026-10-02-aws-deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-ontap)

  4. **SnapMirror DR = peer clusters → peer SVMs → create DP volumes → create

  5. initialize mirror. The runbook: cluster peer create (intercluster IPs), vserver peer create … -applications snapmirror, create -type DP (data-protection) volumes** on the DR FSx ONTAP, then snapmirror create -policy MirrorAllSnapshots -type DP + snapmirror initialize per volume (data, log, binary). This is the command-level form of the async-cross-region + pilot-light DR shape. (Source: sources/2026-10-02-aws-deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-ontap)

  6. DR-licensing mount constraint restated as a hard runbook rule. DR replicated volumes stay as DP volumes NOT mounted as NFS datastores until a failover is declared; pre-mounting (even with no VM powered on) exposes Oracle binaries and may require Oracle licenses across the entire DR cluster. Failover procedure: break SnapMirror → mount NFS datastore on DR host → power on VM → recover to last archive log → update DNS/connection strings. (Source: sources/2026-10-02-aws-deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-ontap)

  7. SnapCenter is the Oracle-aware backup/PITR/clone control plane. Deploy SnapCenter Server (or SaaS), add the FSx ONTAP system by cluster management IP, install the SnapCenter Plugin for Oracle on each Oracle VM, and create two backup policies: Full DB (data + control + archive, every 4–6h, with SnapMirror update) and Archive Log (archive-only, every 10–15 min, with SnapMirror update). Backups are storage-layer snapshots, so "recovery in seconds regardless of DB size." (Source: sources/2026-10-02-aws-deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-ontap)

  8. Day-2 ops are storage operations, not Oracle operations. PITR: in SnapCenter pick an SCN or timestamp → mount the log snapshot → restore the data snapshot → apply archive logs → open with RESETLOGS. Cloning: SnapCenter FlexClone makes space-efficient copies that share unchanged blocks with the source and consume storage only for deltas — for dev/test, patch validation, reporting. This is a classical (non-compute-storage- separated) instance of PITR and copy-on-write forking at the storage-array layer. (Source: sources/2026-10-02-aws-deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-ontap)

  9. Four migration paths from on-prem VMware/Oracle, chosen by source storage + downtime budget. (1) VMware HCX live migration (vMotion zero-downtime or bulk), then storage-vMotion VMDKs from vSAN onto FSx ONTAP NFS datastores post-cutover to gain snapshot/replication; (2) SnapMirror ONTAP-to-ONTAP if on-prem is already NetApp (incremental replicate → quiesce → flush archive logs → final sync → break); (3) Oracle PDB relocation for multitenant (hot-clone PDBs, brief final switchover); (4) RMAN backup/restore for non-ONTAP on-prem — stage the RMAN backup to Amazon S3 via AWS DataSync or Direct Connect, then restore + apply logs on the EVS VM. (Source: sources/2026-10-02-aws-deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-ontap)

The eight deployment steps (runbook skeleton)

Step Action Key detail
Pre Prerequisites EVS cluster + VPC + networking in place
1 Deploy Oracle VM on EVS RHEL 8 / Oracle Linux 8; 8–32 vCPU, 32–256 GiB; 100 GiB OS disk on vSAN; swap on vSAN NVMe; oracle-database-preinstall-19c
2 Provision FSx ONTAP Single-AZ (required for EVS); SSD = data+logs+20% headroom; throughput 512–2,048 MB/s sized on write workload; SG allows NFS 2049/111/635; disable auto daily backups; set fsxadmin + SVM vsadmin
3 Create DB volumes vol create over SSH: oradb1bin 50G / oradb1data 500G / oradb1log 250G, -tiering-policy none (pin SSD)
4 Mount NFS datastores in vSphere NFS 3; server = svm-id.fs-id.fsx.region.amazonaws.com; one datastore per volume
5 Create Oracle VMDKs Thick-provision eager-zeroed data/log VMDKs on FSx datastores; guest mkfs.xfs → /u01 /u02 /u03; guest sees local XFS, not NFS
6 Install + configure Oracle 19c silent runInstaller; CREATE DATABASE with datafiles on /u02, redo on /u03; no NFS-specific Oracle config
7 SnapMirror cross-region DR peer clusters → peer SVMs → -type DP volumes on DR → snapmirror create -policy MirrorAllSnapshots + initialize
8 SnapCenter backup SnapCenter Server + Oracle plugin per VM; Full DB (4–6h) + Archive Log (10–15 min) policies, both with SnapMirror update

Day-2 operations

  • Snapshot backup — SnapCenter manages full DB snapshots as storage-layer operations.
  • Point-in-time recovery — SnapCenter: pick SCN/timestamp → mount log snapshot → restore data snapshot → apply archive logs → open RESETLOGS.
  • Database cloning — SnapCenter FlexClone: space-efficient copies sharing unchanged blocks (dev/test, patch validation, reporting).
  • HA failover — break SnapMirror → mount SnapMirror volumes as NFS datastores on DR hosts → power on Oracle VM → recover to last archive log → open → update DNS/connection strings.

Clean-up ordering (dependency-aware teardown)

The post calls out an explicit deletion order to avoid dangling references: (1) power off + delete Oracle VMs; (2) unmount FSx datastores from ESXi; (3) delete SnapMirror relationships + DP volumes on DR; (4) delete both FSx ONTAP file systems (permanently removes all data); (5) delete the EVS environment (terminates the EC2 bare-metal instances); (6) remove Transit Gateway attachments / VPC Route Server config / Direct Connect if created solely for this deployment.

Operational numbers

  • Oracle VM: 8–32 vCPU typical, 32–256 GiB RAM, 100 GiB vSAN OS disk, 16 GiB swap (example).
  • FSx ONTAP: throughput 512–2,048 MB/s (size on write), IOPS auto (3/GiB) or up to 80,000 user-provisioned, SSD + 20% headroom.
  • Volumes: bin 50G / data 500G / log 250G (log sized for 24h archive logs).
  • Backup cadence: Full DB every 4–6h; Archive Log every 10–15 min; both trigger SnapMirror update.
  • Guest OS: RHEL 8 / Oracle Linux 8 (64-bit); Oracle 19c.

Caveats

  • How-to/runbook post, not a production retrospective. No named customer, no measured production numbers; the volume sizes, cadences, and instance specs are illustrative defaults. "Recovery in seconds regardless of DB size" is an AWS claim about storage-snapshot restore, not a measured figure.
  • Oracle licensing is repeatedly hedged with "request an AWS Optimization and Licensing Assessment (AWS OLA)" — the DR-mount guidance is operational caution, not authoritative licensing advice.
  • Architecture rationale (instance selection, storage design, HA planning) is deferred to the companion architecture post (sources/2026-10-02-aws-architect-highly-available-oracle-database-on-amazon-evs-and-fsx-ontap).

Source

Last updated · 771 distilled / 2,233 read