Written by Porus Homi Havewala


We introduced the concept of Consolidation Planning in the previous parts of this article series. Part II was here. This is Part III.


In the Aggressive scenario, the Destination Resource Limit can be as high as 90%, which means that more servers will be consolidated on to the target machine. The Conservative scenario on the other hand has a Destination Resource Limit of only 70%, so less servers will be consolidated. The Medium scenario is in between the two other scenarios and uses 80%. You can use what you are comfortable with, or as per your company policy.

This step also allows you to decide if new (non-existing or phantom) servers will be used for the destination, such as Oracle Engineered Systems or Generic Servers. The other option is to use Existing Servers that have already been specified in the project list. Click on Next.


Figure 1-7: Review before submitting.



The Review screen (Figure 1-7) appears. Check the details, and click on the Submit button. A message appears as follows: “Confirmation: Project "P2P_Sainath_Project" has been defined successfully. An EM job has been submitted to perform further operations. Refresh console to view the detailed results”. Click on the Refresh button.


Figure 1-8: Status of Project.



The Status column on the Consolidation Planner page (Figure 1-8) initially displays the status of “Scheduled”. Keep refreshing the page. The status changes to "Collecting over minimum". In the General tab of the Project page, the Data Collection status is shown as “Data collection task in progress”.


Figure 1-9: Analysis Completed.



As seen in Figure 1-9, the job completes within a couple of minutes. This is because 0 days were specified (for test purposes) as the minimum number of days for collection. The data collection status now shows as “Collecting data, required minimum days reached”. The three pre-configured scenarios show as “Analysis completed”.


You can examine the project details on the General tab, then move to the Source Candidates tab.


Figure 1-10: Source Candidates Tab.



The Source Candidates tab (Figure 1-10) displays the Source Servers that were selected, the CPU SPECint that was used, and CPU, Memory and Disk Storage Utilization and other resource and usage details that were collected for these servers.


Move to the Source Workload tab. This is shown in Figure 1-11.


Figure 1-11: Source Workload Heat Map with Color coding.



The Source Workload tab shows a graphical representation of the resource workload for each of the source candidates, mapped against days and hours. This is known as a “Heat Map”. By default, the resource type used is CPU. Color coding (explained at the bottom of Figure 1-11) is used to show at a glance which servers are heavily utilized. For example, the colors either show under-utilization (0 - 20% and 21 - 40%), or higher utilization (41 - 60% and 61 - 80%), or the highest utilization (81 - 100%).


From the “Server Name” drop down box, you can select any particular source server in your project list and examine the associated resource workload. The different “Resource Types” you can select from the drop down menu are CPU, Memory, Disk Storage, and Network I/O Volume. The chart display changes accordingly. In Figure 1-11, we see the CPU resource type workload for this particular server displayed in the chart.

Now, click on the Aggressive pre-configured scenario row, this displays the scenario details as shown in Figure 1-12.


Figure 1-12: Aggressive Scenario.



The consolidation goal is to consolidate to the fewest destination servers. We can also see that in the pre-configured Aggressive scenario, an Exadata X5-2 Full Rack is used by default. Click on the Full Rack to see the configuration details, seen in Figure 1-13.


Figure 1-13: Exadata Full Rack configuration.



There are 8 compute nodes in this machine, and the configuration of one compute node is displayed. Then click on the OK button to continue. We were actually not interested in a full rack, so we will not explore this scenario further. We need to see if we can consolidate the source servers onto a smaller, quarter rack or 1/8th rack. For that purpose, we will need a custom scenario.


Creating a Consolidation Scenario for P2P


We will now create a custom Consolidation Scenario for this project. Scenarios allow us to explore different possibilities for the consolidation project. You simply need to create separate scenarios, which act like What-If situations. This is for the purpose of selecting the scenario that suits your consolidation goals the best.


Select the existing project, and then click on “Create Scenario”. Figure 1-14 displays the Create Scenario screen.


Figure 1-14: Entering Details for a New Scenario.



We are going to look at an Exadata Quarter Rack scenario, so name the scenario appropriately. For estimating the resource requirements in this scenario, select the CPU and Memory Resource Types from the list. In the “Scale Factor” column, you can increase the scale factor for the resources you have chosen. This is to cater for future growth in the systems you are consolidating. Oracle will scale up the resource requirements as per what you have specified.


We continue this article series in Part IV.


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