Written by Porus Homi Havewala

We introduced the concept of Consolidation Planning in the previous parts of this article series. In Part III, we started to look at an Exadata Quarter Rack scenario. This is Part IV.

Keep the Applicable Days as the default value, which is "All Days" (other options are Weekdays or Weekends). 

The consolidation algorithm is decided by the Resource Allocation that is selected. You can select this as "Conservative” – in this case, the resource usage will be aggregated to a 24 hour pattern by gathering the Maximum number of corresponding hours in the data range that has been specified.

If Aggressive is selected, an Average number of corresponding hours is used, or 80% if Medium is specified. The maximum number, average number, or 80% of the hours therefore decides how the consolidation algorithm is calculated.

You can also specify a date range for the data that will be used for the estimation of the resource requirements, or leave this unselected.

Next, click on the “Estimate Requirements” button. This will allow you to view the updated resource requirements, based on the options you have selected previously.

After the estimation is completed, the details for each server appear at the bottom of the page. Click on the Next button to proceed. Figure 1-15 displays the Constraints screen.

(Note: Please click on each image for a larger, clearer image).

Figure 1-15: Constraints for Scenario.

On this screen, we define the constraints which will control the consolidation of multiple source servers to one destination server. At this stage, we can decide that only compatible servers should be consolidated together.

Compatible servers can be defined as having the same Server Property, or the same Server Configuration. For example, you can select the Lifecycle Status, Department, or Location as the server property. You can also select different server configurations such as System Vendor, System Configuration, CPU Vendor, CPU Name, Operating System, and Network Domain.

In our case, we have specified Lifecycle status as the server property, and Operating system as the server configuration. This means that development servers will be consolidated separately from test or production servers, and linux or windows servers will also be consolidated separately.

In the Condition field, we can also define Mutually Exclusive Servers that should not be consolidated together, such as the Nodes of a RAC Database or the Nodes of an Oracle Cluster. This is as per Oracle best practices.  

If any of the constraints on this page are selected, the "Preview Effect of Constraints" button is activated and you are able to view a list of incompatible servers. The reason for the incompatibility will also be shown.

Click on Next to proceed. Figure 1-16 shows the Destinations Planning page.

Figure 1-16: Destinations Planning.

For the 9 Source Candidates we have selected, the Minimum Required CPU SPECint rate is displayed as 517, and the Minimum Required Memory is 449 GB.

In the Maximum Allowed Resource Utilization section for the Destination Servers, specify the CPU % as 75 and Memory % as 90. This means the consolidation will not allow any more servers to be included on the destination machine , if the calculated resource utilization goes beyond these limits on that machine.

As the Destination Candidates, we will use New (Phantom or non-existent) Servers. An Oracle Exadata Database Machine X5-2 with a Quarter Rack configuration is selected from the list. The list of Exadata configurations is seen in Figure 1-17.

If required, Exalogic machine configurations are also available if you had selected “Oracle Exalogic Elastic Cloud System” as the Server Type.

Figure 1-17: Exadata Configurations to choose from.

Click on Next. The Destination Mapping page appears as seen in Figure 1-18.

Figure 1-18: Destination Mapping.

On this page, source servers are mapped to destination servers. This is done automatically. If existing servers were selected for the destination, it is possible to override the destination server for each source server.

In our case, since we have selected a phantom Exadata database machine as the destination, no override is possible. Click Next to continue.

The Review screen appears as seen in Figure 1-19.

Figure 1-19: Review Screen.

This is the Review screen for the scenario creation. It is possible to save the scenario as a template at this stage, so that it can be used again. Verify the details and click on Submit.

An Enterprise Manager job is submitted to perform further analysis. On the Consolidation Planner console, the status for the newly created custom scenario shows as "Analysis in progress". Keep refreshing the console. In a few minutes, the status changes to "Analysis completed". The Confidence is also shown as 100%.


Reviewing Scenario Analysis Results

Select the customized scenario to display the details in the lower half of the screen. A number of tabs are displayed as seen in Figure 1-20.

Figure 1-20: Custom Scenario Details – General Tab.

The General tab shows information such as the resource types used, the applicable days, the allocation algorithm (Conservative), any specified constraints, and so on. A Quarter Rack is shown as the Destination Server type.

We continue this article series in Part V here.

(This article is an excerpt from Chapter I of the new book by the author titled “Oracle Database Cloud Cookbook with Oracle Enterprise Manager 13c Cloud Control” published by Oracle Press in August 2016. For more information on the book, see here.)