Image courtesy of Shutterstock.
Virtualized Oracle databases, just like all virtual machines, share physical server resources with other virtual machines running on the same hypervisor. We’ll call virtual machines that reside on the same hypervisor “siblings.”
Sibling Rivalry
VM sibling rivalries occur due to resource shortages caused by improper virtual machine placement. Databases generally have more severe ramifications when resource shortages occur than other virtualized applications, making good sibling behavior crucial for your Oracle databases.
VMware vRealize Operations (vROps) makes sibling selection an easy process. While there are many ways of using vROps to identify good siblings, ranging from custom dashboards to custom reports, the simplest way is using the built in metric selector view.
Using vROps to Avoid Sibling Rivalry
The solution to sibling rivalry is quite simply: select good siblings. There are a few prerequisites to the solution outlined below. First, you need a vRealize Operations installation that’s been running for at least a few weeks, ideally longer. This provides solid historical performance data of your VMs. Second, you need a login with read access to the VMs and hypervisors you want to optimize. Finally, you need a list of the VM names that your Oracle databases reside on. Optionally, you can use a vRealize Management Pack for Oracle to simplify this step, though it’s not required.
First, log into vRealize Operations.
Next, navigate to “Environment” > “All Objects.” Expand “vCenter Adapter,” then expand “Virtual Machine.” You will have a view similar to below, listing out the VM’s in your environment.
Depending on your environment setup, you may have your Oracle on VMware VMs isolated to a single cluster for Oracle licensing purposes. In this case, you would want to navigate to the cluster dedicated to Oracle workloads and view the VMs and hypervisors from there.
Select your Oracle Database from the list and let the dashboard on the right update. Once it populates, select “Troubleshooting” > “All Metrics” from the tabs at the top.
In the lower left portion of the dashboard, expand and double click the key metrics you want to find a good sibling fit for. Likely this will be some combination of memory, CPU, or network metrics. If you already know your most constrained resource (the one most likely to cause problems for your database), stick to that for simplicity.
You now have a screen similar to above with your key metric chart displayed in the lower right section for the VM your Oracle database is on (em-oel6-d2). Now it’s time to find ideal siblings.
For this step, knowledge on other VM workloads may help to identify ideal sibling candidates quickly. If you have background on certain VMs you can use vRealize Operations to verify whether or not it would be a good sibling. For example, if your subject database backs an internal application used by employees, it’s likely going to need a lot of resources during the workday. If you know there is another Virtual Machine running nightly backups or reports, this would be a good candidate due to the limited overlap of resource needs.
To find ideal siblings, select another VM from the list on the left and repeat the process of double clicking the same metric as you did for your first VM. In the below screenshot you can see a second VM, oradb-d2, has been selected and the same metric chosen. Repeat this process to select as many siblings as needed.
In vRealize Operations, the graph section will stack the charts and match the same time period. This makes it easy see how VMs compare over time for the chosen metric. Keep an eye out for VMs that do not share peak hours or compete for resources simultaneously as these make excellent siblings!
To make this process even easier you can disable “split charts,” which merges the graphs into one. Below is what the default graph section looks like.
Note the top left corner has a red and green line icon selected. When you hover over this, it says “Split Charts.” Click this to merge the charts so that you can compare each VM’s value for the selected metric while they share the same X and Y axis, as illustrated below.
We can see here that oradb-d2 has a consistently low and stable memory footprint compared to our first database, em-oel6-d2. We’ve found a possible match, so we’ll remember this pairing for sibling optimization.
Another view that vRealize Operations provides is a stacked view. Click the solid red and green icon in the upper left, one to the right of the “Split Charts” icon. Your resulting view is below.
This view is a great way to identify your hypothetical peak usage if your selected VMs had been running on the same hypervisor. In this example, we can see our peak usage would have been about 6,000,000KB of Guest Active Memory. With a 20% resource buffer, we can now estimate that we need the Hypervisor to have at least 7,200,000KB of memory available to the VMs.
Optimizing the sibling VMs of your virtualized Oracle databases is a simple process with vRealize Operations. Done properly, it creates a balance of server consolidation and server performance, providing IT cost savings while maintaining or improving database performance standards and SLAs. Keep the kids from fighting and give your virtualized Oracle databases the siblings they need today.