This article is written to provide you a high-level overview of how to run Oracle DB (database) on Azure. There are some significant differences for Oracle Architectures when it comes to Azure and there are some additional opportunities as well. This article specifically talks about how to map on-premise Oracle architectures on Azure.
IaaS vs PaaS
Customers had two options originally for running Oracle database on azure namely IaaS and PaaS. Microsoft does not provide Oracle DB as a PaaS service anymore and Oracle on Azure is only possible under IaaS model.
Licensing
Azure offers only BYOL options for running Oracle on Azure. As per Oracle’s published licensing document, a core factor of 0.5 should be when calculating the licenses needed on Azure for Oracle Enterprise Edition choice. In evaluating the licenses needed for Oracle careful analysis of the CPU performance mapping has to be performed. Almost all the times, the hardware on-premises are legacy and not with an upgraded chipset. However, on Azure the CPU capabilities are constantly evolving and moving to the next generation. 2GHz CPU with a previous generation is lesser power than a 2GHz CPU of the next generation on Azure. Please see the table below with CPU capability matrix which could be handy when comparing on-premises to Azure capacity analysis for Intel servers. Also for a variety of reasons and situations hardware on-premises could potentially be oversized and underutilized. Moving to Azure cloud gives the opportunity optimize workloads and licenses. In a nutshell, you might potentially need lesser licenses on Azure than on-premises.
Storage
Storage on Azure is triple replicated by default. The SAN like redundancy is built-in a different way. The choice of storage is often-times one of the critical components for the performance of the DB. In the on-premise world, SAN from top vendors like EMC/Hitachi could handle the IOPS requirement very well. However, the world has changed and for the cloud, the primary choices are Standard storage(SATA) and Premium Storage(SSD).
Disks & IOPS
If your DB is on running on filesystem, the general recommendation and good practice are to have the OS disks on Standard Storage which certainly can be placed in SSD for even better performance, and for the data disks, the recommendation is to have it on Premium SSD disks. By default, you will get about 500 IOPS of 1KB payload on a given disk on a Standard Tier VM or 5000 IOPS on a premium storage disk. To increase throughput, you could certainly opt for RAID 0 to do stripping on disks similar-to on-premises. https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-linux-configure-raid?toc=%2fazure%2fvirtual-machines%2flinux%2ftoc.json
This is to scale IOPS requirements. The choice of premium storage also provides better stability and availability. Since Azure retains 3 copies of data for any kind of storage, RAID 10 is not necessary and RAID 0 should be sufficient.
Oracle ASM
Don’t get confused with Oracle ASM and Azure ASM. Oracle ASM is Automatic Storage Management which is a volume manager and filesystem for Oracle databases. Azure ASM is Azure Service Management which is the old-style way of working with Azure. Oracle recommends the databases to be on Oracle ASM for better performance and manageability. Oracle databases can be built on Oracle ASM on Azure on both Linux and Windows. Standard Oracle installation procedure is recommended.
Scalability
Scaling RDBMS systems have always been expensive and complicated and Azure no different. Horizontal scalability on Azure is not feasible primarily due to two reasons 1. Multicasting of IP and 2. Shared storage. Azure Oracle VMs follow a shared-nothing architecture. This means that running clusters using Oracle RAC is not possible but however vertical scalability is feasible. RAC enables fault tolerance, the capability of capacity, shared workloads, etc., Oracle RAC is a 10-year-old legacy technology when hardware failure, limited vertical scalability, single-core sockets, etc., were common. In current world, the CPUs are lot more powerful, vertical scalability has far increased, multi-core socks available. Oracle RAC workloads with proper planning can be quiet easily moved to Azure on standalone VMs.
High availability
Oracle Maximum Availability Architecture(MAA) suggests having Oracle RAC and Oracle physical standby using Oracle Dataguard for local HA and a DR with another Oracle standby. Automation of failover can be achieved using an Oracle node with Oracle data guard broker with the Fast Start Fail Over configuration. Similar architectures can be built on Azure with the assistance of Availability Sets.
Availability sets
Availability Sets is an Azure capability and virtual abstraction layer which enables fault tolerance for Azure VMs. When multiple virtual machines are created within an Availability Set each of the VM is placed under separate fault and update domains and separate hardware. However, disks on different storage accounts could potentially be under the same storage cluster. With the introduction of managed disks, which is currently under private preview, this will be changed and storage and compute together will have fault tolerance.
Oracle HA architecture
The recommended approach of HA would be to have the 2 VMs in an Availability Set. With the primary running on VM1, a physical standby should be built on VM2 using Oracle data guard. This will enable active-passive architecture in a given region. However active-active architectures can be achieved using replication tools such as Oracle GoldenGate, Attunity, etc., DR with an Active-passive or Active-Active architecture can be achieved across geographically distributed locations using Oracle physical standby or Oracle Goldengate. Alternatively, there are new systems that seem to provide real-time HA automation and failover capabilities. ScaleArc seems to potentially provide this ability with some customizations of the product.
Alternatively one of our customers is looking at dynamically detaching Azure page blob disks in a VM down scenario, spin-off a new VM dynamically using PowerShell script, and attach the blobs to the new VM. This is something unthinkable in an on-premise scenario but Azure cloud gives you a new method of providing HA for Oracle DBs. The link gives you the high-level steps of this approach https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-linux-classic-detach-disk
Backups
Standard backup to disk using RMAN can be on Azure Vms which includes full and incremental options. Azure currently provides the capability to configure a Windows or Linux VMS for backups using Azure Backups. Daily, weekly, monthly and yearly retention configurations are possible. However, Oracle backups on Windows are file system consistent but Linux VMS are currently only crash-consistent. There are several capabilities that will be available in the near future for faster and higher throughput backups.
Further to Azure backups, common backup software like Netbackup and CommVault are commonly chosen by customers to provide enterprise-wide backup services using Azure blobg storage underneath.
Are you ready to run Oracle DB on Azure? We are here to help you. Please find more information at our Azure Management Consulting Section.
Azure Consulting
For official guidelines and detailed information on running Oracle databases on Azure, refer to Microsoft Azure Documentation for Oracle Databases.
To explore best practices and performance considerations for Oracle databases on Azure, visit Best Practices for Running Oracle Database on Azure.
