Deploying Oracle Database on Amazon EVS with FSx for ONTAP: A Detailed Guide

Deploying an Oracle Database on Amazon Elastic VMware Service (EVS) with Amazon FSx for NetApp ONTAP can be a smart move if you're looking to level up your cloud strategy. Why? Because it pulls in enterprise-grade storage capabilities. This guide is here to walk you through every step of that deployment process. We’ll focus on storage volumes, NFS datastore configuration, Oracle installation, and using SnapMirror for disaster recovery.

Why This Matters

Enterprises commonly run Oracle databases in VMware environments. A shift to AWS needs to happen without throwing a wrench in your workflows. This deployment model lets you take advantage of AWS’s scalable infrastructure while keeping things running smoothly. Teams can boost performance and reliability without a massive training effort or big architectural overhauls.

Deployment Overview

Here's a quick look at the steps involved:

• Provisioning Oracle VM on Amazon EVS.
• Creating FSx for ONTAP storage volumes.
• Mounting NFS datastores in vSphere.
• Installing and configuring Oracle 19c.
• Setting up SnapMirror for disaster recovery.
• Configuring SnapCenter for backup and recovery.

Step 1: Provision Oracle VM on EVS

First off, log into the vSphere Client that's hooked up to your EVS vCenter. Spin up a new virtual machine in the Production DB Cluster. You'll choose either Red Hat Enterprise Linux 8 or Oracle Linux 8 as your guest OS. Configure the vCPU and memory to suit your workload, and set aside disk space on the vSAN datastore for the OS, Oracle Home, swap, and temp tablespace.

Network: Attach to the DB segment on the prod-trusted Tier-1 gateway.

If high availability is on your mind, consider VM replication instead of a separate licensed instance in the disaster recovery (DR) cluster. This can streamline DR management and cut down on Oracle licensing costs, which can get pretty steep.

Step 2: Provision FSx for NetApp ONTAP

Head over to the Amazon FSx console to create a file system. Go with Amazon FSx for NetApp ONTAP in a Single-AZ deployment, as required for EVS. Match your storage and throughput capacity to your Oracle data and logs needs. Set up the fsxadminpassword for ONTAP CLI automation and create an SVM with a vsadminpassword.

Skip the automatic daily backups; SnapCenter's Oracle-aware scheduling is more on target for what you need. Once everything's set up, grab the NFS DNS name from the SVM endpoint. You'll need that in the upcoming steps.

Step 3: Create Oracle Database Volumes

SSH into the FSx for ONTAP cluster and make some storage volumes. Set your -tiering-policy to 'none' to keep all data on the SSD tier. This is how you maintain those high IOPS and low latency that Oracle databases love.

Step 4: Mount NFS Datastore in vSphere

Use the vSphere Client to add new NFS datastores for the DB Cluster. You'll need the NFS DNS name plus the right folder paths for data, binaries, and logs. Double-check that all datastores are correctly showing up in the cluster storage view to avoid any nasty data access issues.

Step 5: Create Oracle VMDKs

Once your NFS datastores are in place, create virtual disks for Oracle data, logs, and binaries. Opt for thick provisioning with Eager Zeroed for top performance. Inside the Oracle VM, partition and mount these as local XFS block devices. This setup hides the NFS layer, letting Oracle think it's dealing with local storage, which makes for easier management and better performance.

Step 6: Install and Configure Oracle 19c

Set up Oracle 19c with data on /u02 and logs on /u03. Thanks to the ESXi hypervisor, the NFS layer stays hidden, so you can stick with standard Oracle storage management. No need for any NFS-specific Oracle tweaks, which keeps things straightforward and less prone to errors.

Step 7: Set Up SnapMirror for Disaster Recovery

Get SnapMirror going for cross-region disaster recovery. You'll need to peer your production and DR clusters, create DP volumes, and initiate SnapMirror. While you’re planning out DR, keep an eye on Oracle licensing to dodge unwanted costs. Oracle's licensing can be pretty tricky, and mistakes here can get expensive.

Step 8: Configure SnapCenter Backup

Install SnapCenter Server and add the FSx for ONTAP storage system. Set up the SnapCenter Plugin for Oracle and craft backup policies tailored to Oracle databases. You can then schedule backups and manage recovery efficiently. The centralized management SnapCenter offers can save your bacon during data protection tasks.

Migrating Existing Workloads

There are four paths for moving on-premises Oracle workloads to EVS:

• VMware HCX Live Migration: Best suited for enterprises already using VMware. It allows for a smooth transition with minimal downtime, using VMware's HCX tech for effective workload migration.
• SnapMirror ONTAP-to-ONTAP: Ideal for setups already using NetApp ONTAP storage. It leverages existing SnapMirror relationships for a smooth transfer, keeping disruptions to a minimum.
• Oracle PDB Relocation: Perfect for multitenant model databases, enabling seamless database moves within Oracle's architecture.
• RMAN Backup/Restore: Useful for setups not using ONTAP, this method backs up databases to S3 and restores them on AWS, making it versatile for various environments.

Day-2 Operations: Backup and Recovery

Once Oracle Database is up and running on EVS, handling day-2 operations becomes key. SnapCenter helps with full database snapshot backups, point-in-time recovery, and cloning. Each of these operations aims to maximize storage efficiency and simplify management. Reliable, regular backups and swift recovery capabilities are crucial for keeping your database running without a hitch.

What This Does Not Solve

Though this deployment strategy offers solid solutions for Oracle Database on AWS, it doesn’t wipe out Oracle licensing issues. Careful planning and working with AWS Optimization and Licensing Assessment (AWS OLA) can help manage costs effectively. Also, network setup and handling complex cross-region replications need ongoing monitoring and tweaking. This plan assumes you have a decent grasp of VMware and AWS, which might mean some extra training for some teams.

For developers and system admins, getting to know the ins and outs of both VMware and AWS is essential. Even though the deployment process is streamlined, understanding cloud infrastructure and database management principles is vital. That know-how is crucial for troubleshooting and optimizing the setup to meet specific organizational needs.

Closing Thoughts

Deploying Oracle Database on Amazon EVS with FSx for NetApp ONTAP gives enterprises a strong path to leverage AWS cloud benefits while keeping current workflows intact. The step-by-step procedures here aim to make the transition seamless and the setup solid. For more insights into cloud setups, check out my earlier posts on Docker Cloud Sandboxes and AWS MCP Update.

If you're curious about the architecture decisions in this deployment, head over to the related AWS Architecture Blog post. I'd love to hear your thoughts and questions in the comments section.