You are here

ROAD for Oracle VM Availability Protection

ROAD for Oracle VMOracle VM Manager is the centralized management and operations application for Oracle VM. Without Oracle VM Manager operations will quickly screech to a halt resulting in the loss of all management capabilities, and visibility for the Oracle VM Server Pools, Oracle VM servers, and virtual machines.
 
ROAD™ for Oracle® VM delivers unparalleled availability protection for Oracle VM Manager. ROAD for Oracle VM was designed to quickly and efficiently recover Oracle VM Manager on the same host, or a different host without disrupting running Oracle VM servers, or virtual machines. ROAD for Oracle VM improves your availability strategy, and allows you to comfortably meet service level agreements, RPOs and RTOs for business critical Oracle workloads.
 
 
Oracle's recommended Oracle VM Manager availability solution is Oracle Clusterware. Clustering Oracle VM Manager introduces complexity, and operational overhead without the ability to prevent the root cause of the majority of Oracle VM Manager outages, database corruption. Oracle’s recommendation for database corruption is to recover the Oracle VM Manager database from a clean backup. Unfortunately the Oracle VM Manager database recovery process is time consuming, error-prone, and often results in prolonged outages and total cluster rebuilds. ROAD for Oracle VM takes a fundamentally different approach to Oracle VM Manager availability protection that minimizes business disruption by quickly and efficiently recovering the running Oracle VM configuration on the same host, or a different host without the complexity, and operational overhead of clustering, or database recoveries.
 

Understanding Oracle VM Manager and Availability Protection

Oracle VM Manager is a traditional Oracle Fusion Middleware application with a MySQL Database, WebLogic Server, with an Oracle Application Development Framework (ADF) administrative portal. Oracle VM Manager can be installed using the default all-in-one setup, or in a two node cluster, on Oracle Linux and Red Hat Enterprise Linux 6+.
 
Oracle VM Manager manages the objects and meta-data under its management via the ADF administrative portal, the Oracle VM Manager CLI, and Web Services API. The Oracle VM Server Pool meta-data and configurations are not all stored in the MySQL database. In fact the server pool meta-data and configurations are distributed across an Oracle VM environment:
a) in the Oracle Manager MySQL Database
b) in each Oracle VM server’s Berkeley Database
c) in each Oracle VM server’s configuration files
d) in each Oracle VM storage repository
 
The Oracle VM Manager MySQL database contains any changes made to the default names of objects at the time of discovery, tags, and some, but not all of the Oracle VM Server Pool, Oracle VM server, and virtual machine meta-data and configurations. Each Oracle VM Server has a local Berkeley database with cluster meta-data, and local configurations files. Each clustered Oracle VM server pool also has centralized Berkeley database with cluster meta-data. Each storage repository contains its meta-data, and the virtual machine meta-data in vm.cfg files.
 
The ability to quickly restore Oracle VM Manager is an essential Oracle VM lifecycle operation. There are multiple Oracle VM Manager recovery options.
 

The Oracle VM Administration Guide & The Oracle Backup and Recovery Best Practices Guide:

The Oracle VM Administration Guide, and the Oracle Backup and Recovery Best Practices Guide  provides basic information required to manually backup and restore Oracle VM Manager, and the MySQL database. There are two options:
  1. If you have the backups of critical Oracle VM Manager files, and a good database backup you can start working through an Oracle VM Manager database recovery. In our experience which dates back to the first Oracle VM release, and hundreds of completed Oracle VM Manager database recoveries, Oracle VM Manager database recoveries are time consuming, and error-prone, often resulting in prolonged outages and total cluster rebuilds. By the time most users detect database corruption most if not all of the MySQL backups are corrupt resulting in prolonged outages, and in most cases Oracle support will recommend a total cluster rebuild.
  2. If you do not have backups of critical Oracle VM Manager files, and the database you can start working through the 16 step Oracle VM Manager UUID restore process. If you're successful there are still several objects that are not restored. For example, the changes made to the default objects names, also referred to as user-friendly names, such as physical and virtual disks along with object descriptions, and tags are not restored. As with the previous recovery option, Oracle VM Manager UUID restores are time consuming, and without experience can result in prolonged outages and total cluster rebuilds.
Note: Many customers open Oracle Service Requests to help recover Oracle VM Manager. The majority of Oracle Service Requests end with total cluster rebuilds.
 
There is a better Oracle VM Manager Backup and Recovery option...

ROAD for Oracle VM Availability Protection

ROAD for Oracle VM was designed to quickly and efficiently recover Oracle VM Manager on the same host, or a different host with return to normal operations (RTO) in minutes, not hours, without disrupting running Oracle VM servers, or virtual machines. ROAD for Oracle VM uses automation to completely recover Oracle VM Manager on the same host with three commands, or on a new host with only two commands.
 

Use Case: Recover Oracle VM Manager from Database Corruption using ROAD

On an Oracle VM Manager host with database corruption first run the ROAD ovm_wipe command with your pre-configured recover Runbook. The ovm_wipe command wipes the corrupt Oracle VM Manager MySQL database to a clean first login state. Next run the restore_manager command with your pre-configured recover Runbook to automates the entire 16 step Oracle VM Manager UUID restore process. To complete the process run the restore_nice_names command with your pre-configured recover Runbook to restore the user-friendly names, such as physical and virtual disk names, descriptions, and tags.
 
The next image shows the ROAD workflow to recover Oracle VM Manager from a corrupt database.  
How to recover Oracle VM Manager from a corrupt database
 
 

Use Case: Catastrophic Oracle VM Manager Failure & Recovery to Different Host using ROAD

To fully recover Oracle VM Manager on a new host there are two ROAD prerequisites.

  1. Oracle VM Manager must be installed with the UUID of the failed Oracle VM Manager.
  2. The recovery Runbook and save_nice_names out files from primary Oracle VM Manager must be in /opt/mokum on the new Oracle VM manager host.
On the new Oracle VM Manager host first run the restore_manager command with your pre-configured recover Runbook to automates the entire 16 step Oracle VM Manager UUID restore process. To complete the process run the restore_nice_names command with your pre-configured recover Runbook to restore the user-friendly names, such as physical and virtual disk names, descriptions, and tags.
 
The next image shows the ROAD workflow to recover Oracle VM Manager on a different host.
Catastrophic Oracle VM Manager Failure & Recovery to Different Host using ROAD
 
ROAD for Oracle VM was designed to quickly and efficiently recover Oracle VM Manager on the same host, or a different host with return to normal operations (RTO) in minutes, not hours. Save time, and reduce risks with ROAD™ for Oracle® VM, the leading productivity suite for Oracle VM for x86. With ROAD you'll improve system performance, and uptime, optimize Oracle licensing, while comfortably meeting service level agreements, RPOs and RTOs for business critical Oracle workloads. ROAD is unrivaled for ensuring the greatest possible Oracle license optimizations, system performance, operations automation, availability, and disaster recovery protection for Oracle VM and its business critical Oracle workloads. 
 
 
The next example shows the Runbook used to fully recover a Production, and Test Oracle VM Pool with over 30 virtual machines running business critical Oracle workloads on the same or a different Oracle VM Manager host.

mokum.log.loc = /opt/mokum/tmp/mokum_utils.
mokum.util.otypes = ServerPool,Tag
mokum.nicenames.path = /opt/mokum/tmp/mokum_nice_names.txt
ovm.config.path = /u01/app/oracle/ovm-manager-3/.config
ovm.pw = mypassword
cli.host = localhost  
cli.port = 10000
cli.user = admin
ovs.agent.port = 8899
ovs.agent.user = oracle
ovs.agent.pw = mypassword
ovs.servers = 192.168.20.103,192.168.20.104,192.168.20.105,192.168.20.106,192.168.20.107,192.168.20.108
ovs.server.names = ovs623,ovs624,ovs625,ovs626,ovs627,ovs628
ovs.nfsadmin.servers = ovs623,ovs624,ovs625,ovs626,ovs627,ovs628
ovs.fcsanadmin.servers = ovs623,ovs624,ovs625,ovs626,ovs627,ovs628
ovs.iscsisanadmin.servers = ovs623,ovs624,ovs625,ovs626,ovs627,ovs628
ovs.storage.type = iSCSIStorageArray
ovs.storage.type = FibreChannelStorageArray
ovs.storage.plugin = Oracle Generic SCSI Plugin
ovs.nfs.plugin = Oracle Generic Network File System
ovs.nfsstorage.name = nas510,ovs627
ovs.scsistorage.name = nas510
ovs.nfsstoragename.accessHosts = nas510,192.168.2.100
ovs.nfsstoragename.accessHosts = ovs627,192.168.2.107
ovs.scsistoragename.accessHosts = nas510,192.168.2.100:3260
ovm.ntp.servers = 192.168.20.201
ovm.yum.serverupdategroup = serverUpdateConfiguration_0004fb0000020000f7e6003cd92fce71:0004fb0000020000f7e6003cd92fce71,serverUpdateConfiguration_0004fb00000200003d03d38f43761ba1:0004fb00000200003d03d38f43761ba1 
ovm.yum.reposname = 05252016,3.4_Latest
ovm.yum.rname = ovm611,OraclePublic
ovm.yum.baseURL = http://192.168.20.201/yum/public/3.4/05252016/ovm3.4_latest/getPackage/,...
ovm.yum.repoenabled = yes,yes
ovm.yum.pkgSignatureType = GPG,GPG
ovm.yum.gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle,http://public-yum.oracle.com/RPM-GPG-KEY-oracle-ol6
ovm.yum.serverupdategroupId = serverUpdateConfiguration_0004fb0000020000f7e6003cd92fce71,serverUpdateConfiguration_0004fb00000200003d03d38f43761ba1
ovm.repo.server = ocfs2prod1,ovs626,ovs627,ovs628
ovm.repo.server = nfsprod1,ovs626,ovs627,ovs628
ovm.repo.server = ocfs2test1,ovs623,ovs624,ovs625
ovm.repo.server = nfstest1,ovs623,ovs624,ovs625
ovm.repo.server = nfstest2,ovs623,ovs624,ovs625

 

Only ROAD for Oracle VM gives you the power to:

  • Quickly and efficiently recover Oracle VM Manager on the same host, or a different host with return to normal operations (RTO) in minutes, not hours.
  • Implement consistent and repeatable processes.
  • Perform Oracle VM maintenance tasks programmatically.
  • Perform CPU reporting, vCPU pinning.
  • Pinpoint & resolve CPU performance and Oracle licensing inefficiencies.
  • Oracle VM Manager availability protection.
  • Business readiness reports.
  • Bulk import/export VMs to and from VMware.