Hey, did you catch that redirect? The Toad World URL is now community.toadworld.com. Don't worry -- you'll still find all the same great content here (and more on the way). We're just in the process of giving our Toad World site some well-deserved love. Stay tuned for some more updates coming this way.
Meanwhile, enjoy community.toadworld.com.
by Porus Homi Havewala
A new era has dawned in computing. It is the age of self-service, where users create and set up their own accounts on the internet, put in their own service requests, and perform other activities that were previously done by back-end office staff. Likewise, in the area of provisioning servers, databases and applications, users have been expecting similar self-service capabilities.
Traditionally this work was done by the System Administrators and the DBAs – every new server that was required by a project or a customer was provisioned manually by the System Administrators and every new database by the DBA team. The requesting project or the customer was informed only after the successful completion of the task by the Administrator, and the access to the new system handed over.
What if the project team or the customer could themselves go to a self-service page, and request a new server or database, as per a pre-existing quota that has been allocated? The system itself would automatically take care of the provisioning, and start calculating the metering and charge-back without any human administrator intervention (except when things go wrong). The project team or customer would get the results they want in the shortest possible time, thus ensuring full quality of service.
This is the promise of the Cloud, and Oracle provides this functionality in a number of different ways – such as Infrastructure as a Service (IaaS), Database as a Service (DBaaS), Schema as a Service (SCHaaS), Pluggable Database as a Service (PDBaaS), or Middleware as a Service (MWaaS). Each of these ways represents a different type of cloud. IaaS is the basic infrastructure cloud, whereas the latter services are also called Plaftorm as a Service (PaaS) since they supply a made-to-order platform that can be used by the developer or implementor.
These different types of Clouds require either the Oracle Enteprise Manager Cloud Management Pack for Database, or Cloud Management Pack for Fusion Middleware to be licensed. These packs in turn require the pre-requisite license and foundation capabilities of the Database Lifecycle Management (DBLM) Pack and WebLogic Management Pack respectively. For example, you cannot offer a database in self-service mode without the provisioning capabilities of the Database Lifecycle Management Pack being used.
In the case of IaaS, a pool of Oracle Virtual Machine (VM) Servers is used to provision new Guest Virtual Machines via the self-service portal. In DbaaS, a pool of Oracle Database servers with Oracle Homes pre-installed is used to provision new databases on the fly. MWaaS on the other hand, uses WebLogic Server pools to provision Java applications via self-service. In all, Oracle technology provides the broadest range of Cloud services, and Oracle Enterprise Manager Cloud Control is used throughout the Cloud Lifecycle – from planning to setup, followed by the build, testing, and deployment. When the Cloud is functional and in production, Enterprise Manager helps to monitor, manage and optimize the Cloud, and finally to meter and charge the end-user project or customer.
Your company has decided that existing servers and databases are to be moved to the new Cloud Infrastructure, which must be properly sized depending on the systems that are to be moved, the intended workload and future scale factors. Therefore, the first phase of setting up the Cloud Infrastructure is Consolidation Planning.
One of the main goals of this exercise is to identify under-utilized servers and include them in a host consolidation plan, thereby enabling the enterprise to free up as many servers as possible while continuing to maintain or exceed service levels. To achieve this, the configuration, computing capabilities and usage of the existing systems must be clearly understood by the IT department before they can decide on the target systems that are to be used for the Cloud consolidation.
To aid in this purpose of planning, Enterprise Manager Cloud Control offers the twin capabilities of the Host Consolidation Planner and the Database Consolidation Workbench. The latter capability is new in Cloud Control 13c. We will take a look at both of these.
The Host Consolidation Planner uses historical metric data (CPU, memory, storage) from the source servers that is stored by Enterprise Manager in the repository, and allows you to specify the target servers, whether actual or planned, in the form of a consolidation project with multiple scenarios.
Various business and technical constraints can be specified to allow you to guide the consolidation process – such as a constraint which specifies that two RAC instances should not be consolidated to the same target node, or that a development database should not be placed with a production database on the same consolidated server. The planner then performs mathematical calculations to decide which servers are suitable for the consolidation, and offers its recommendations.
To start the Host Consolidation Planner, select Enterprise | Consolidation | Host Consolidation Planner from the Cloud Control menu. Figure 1-1 shows the opening screen.
Figure 1-1: Host Consolidation Manager’s opening screen
We have continued this article series in Part II.
(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.)