Oracle Enterprise Manager Ops Center 12c – Building a Virtual Data Center

One of the great new features in Ops Center 12c is the ability to create a virtual data center which abstracts the compute, storage and networking resources you have managed and allows you to segment those resources into accounts. You can then make those physical resources available to distinct audiences who can self-provision virtual resources as needed within the resource constraints or quotas you defined. I'll walk you through a simple scenario to create a virtual data center (vDC) that consists of a pair of Oracle Solaris 10 servers, a NAS share and a group of VLAN tagged networks. We will then set aside a portion of those resources for a QA Testing group and show how a user within that group can create a virtual server connected on a virtual private network. There are of course many different ways that a vDC could be constructed but hopefully this example will give you a jump start on implementing your own. For more details on these topics, please be sure to check out the documentation, especially the chapter on Virtual Datacenters in the Feature Reference Guide.

Learn more about this in the Ops Center expert call on May 10 at 9:30AM PST.

Gather the Resources

Before we can construct the vDC we need to first pull together the server, storage and networking resources that we plan to provide. If you haven't already, discover and manage your target servers using an Ops Center agent. This will allow creation and management of virtualized compute resources on those servers, in our case, non-global zones. You should also have created one or more libraries which will be available to the consumers of the vDC. In this example we'll use a library built on a NAS share exported by a ZFS Storage Appliance. We'll ultimately pull all of these together within a server pool but we'll first start by defining a network domain containing the networks and fabrics we intend to use. A network domain is just a collection networks and fabrics that can be specified for various uses in Ops Center. Initially there is only a default network domain which contains all of the networks and fabrics associated with all of the assets you have discovered. A vDC requires a separate network domain to be associated with the server pool so we'll create one. We'll open the Networks accordion on the left hand side and then choose the Create Network Domain action on the right hand side. In the first step of the wizard we'll provide a name and optional description and tags for the network domain. In the second step of the wizard we will choose the desired switched fabrics to include. If you have managed the network switches that provide the fabrics then you will see those listed as Fully Managed. Alternatively, if you have defined VLAN ranges on existing fabrics then those will appear as Host Managed. In either of the above cases, you will be able to specify configuration details on how the network domain should allow dynamic private virtual networks to be created. In this example shown below, we'll use an Unmanaged fabric which requires us to select public and private networks from among the existing networks.

In the next step we choose which networks of the unmanaged fabric will be private to this network domain and thus which will be available to consumers of the vDC to create private virtual networks. As shown in the next image, we'll choose two of our three available networks as private.

Finally we'll associate the remaining network from the fabric to the network domain which will allow us to use it later as a public network within the vDC.

While still in the Networks accordion we need to specify the IP address ranges that can be used (or excluded) for our networks so that users of the vDC have addresses to use for their vServers. We select the action Edit Managed IP Ranges and provide ranges to either include or exclude as shown below.

We are now ready to pull all of these resources together into a server pool which will be the basis of our vDC. From the Assets accordion on the left hand side we will use the pull down menu to chose Server Pools under the Resource Management Views and then select the action Create Server Pool. In the first step of the wizard we provide the name and virtualization type for the server pool as well as any optional description and tags. Next we select the members to include in the pool from those that match our chosen virtualization type. We select the previously created network domain in step 3 as shown here.

In the Associate Networks step we add all the networks from the network domain that we wish to use in the server pool. As shown below, I added all three networks from the domain.

If the chosen networks were not already configured on all the server pool members, we would use the Configure Interfaces step to do so. Next we select from the available libraries to provide storage to the server pool as shown.

Finally we choose placement, balancing and auto-recovery policies for the pool and submit the job to create the server pool including mounting libraries and plumbing interfaces as needed.

Create the Virtual Datacenter

With the server pool created we're now ready to create the vDC. We'll open up the vDC Management accordion on the left hand side and select the Create Virtual Datacenter action. In the first step of the wizard we supply the name and any optional description and tags. Next we select the server pool we created above. It is also possible to add additional pools as long as they all share the same virtualization type and network domain associations.

Next we select the storage library where we wish to store volumes and templates (templates are applicable only to vDC's based on Oracle VM for x86 server pools).

Finally we specify how virtual CPUs should relate to physical CPUs. For the zone scenario, the top slider sets the minimum share of a physical CPU that should be allocated for a virtual CPU. Setting this value to it's minimum of 10% would thus provide ten times as many vCPU's as there are pCPU threads in the server pool. In this simple scenario we'll leave the defaults of 100%.

In order to now create an account within the new vDC we must first create at least one user with a Cloud User or Cloud Administrator role who we can assign as a user of the account. Navigate to the Administration accordion to manage users and roles.

Segment the Resources into Accounts

With a Cloud User available we can now go back to the vDC Management accordion, select our newly created vDC and select the Create Account action. As expected, in the first step of the wizard we supply a name for our account and can also provide a description and tags if desired.

The second step of the wizard is where we establish our resource limits from those available within the vDC. We allocate vCPU, memory and storage from the remaining available capacity of the vDC. We also select the number of private vNets that can be created by the account. In this case we only allowed a single private vNet since we have only two private networks that we made available within the network domain. Finally we select the checkbox for the single public network which we provided and we set a limit of addresses which can be allocated from the available total which we defined previously in the the Edit Managed IP Ranges action.

In the final step of the wizard we assign at least one cloud user to the account and then submit the job to create the account. Once the account has been created we can select it under the vDC and review the account dashboard to see the quotas we just established, the list of allocated IP addresses and other details pertinent to the account. This is the level of visibility provided to the Cloud User (minus the Users tab which is only available to a Cloud Administrator).

Cloud Users Create Virtual Resources

With the physical resources now available to users of the account we can proceed to creating some virtual resources. First we'll create a private virtual network or vNet which can be used to connect virtual servers or vServers. We will select the Create Private vNet action from the right hand panel to launch the wizard. After supplying a name and description in the first step we select the size of the vNet we wish to create. The value entered or selected represents the desired number of available addresses and will result in creating a network in CIDR format. The effect of this is that the resulting address size may be adjusted upward to accommodate the next binary value which provides that number of addresses plus two. It may be easier illustrated using the default setting as an example. The default value shown below of 14 would create a /28 network with a netmask of, allowing 16 values with two being reserved.

In our case we can't create dynamic private networks since we have only unmanaged networks in our network domain so instead we simply allocate an existing private network that is large enough to accommodate the requested vNet size. We can now see from the Networks tab of the account that we have created the private vNet with 14 reserved addresses even though the network we used to do so could have allowed a larger vNet since it provides 254 usable addresses (/24). We also see the reservation of the 16 addresses on the public network that we defined when we created the account.

To wrap up this quick tour we'll now proceed to create a vServer within the account. The Create vServer action on the right hand panel launches the wizard where we'll define the characteristics of the desired vServer. In the initial step we specify the name of the vServer and define the number to create. The name will be appended with a digit for each vServer instance. It is also possible to enable High Availability support, providing that the underlying server pool was configured for Automatic Recovery.

In the second step, we choose the template we wish to use for the vServer. In our scenario of a Solaris zone-based vDC we only have a default template but in vDC's based on Oracle VM for x86 it is possible to import templates and assemblies for use in creating vServers.

Shown below are the vServer types that are default options for sizing the vServer. Additional vServer types can be created and maintained by a Cloud Administrator at the vDC level and then used by Cloud Users to create custom sized vServers.

In step four we select the networks we wish to attach to the vServer and I've selected both the public and private networks that we've previously made available to this account.

Since we have reserved IP addresses for use by this account we can choose automatic IP address assignment and Ops Center will choose addresses on each network from among those available. If we wished to provide specific addresses we could have pre-allocated some of the already reserved addresses on one or more of the networks and then those allocated addresses would appear as choices to pick in the IP Address column. The wizard to allocate or deallocate addresses is available on the account's Networks tab. For this example we will simply use automatic allocation for both networks as shown below.

A final step in the wizard allows the option of providing the public key of an ssh key pair in order for the user to access the new vServer without specifying a password. Upon completion of the wizard a job will launch to create the specified vServers using the placement and balancing policies that were defined on the underlying server pool. Once the job has completed we can see the running vServer in the account's vServers tab.

From there we can stop, start, pause and resume the vServer. It is also possible to add additional storage by creating or importing existing storage volumes and attaching them to the vServer. In addition, the Infrastructure-as-a-Service (IaaS) API and CLI come bundled with Ops Center 12c, making an EC2-like interface available for cloud management, but that is the subject for a future blog article....


Hopefully this guided tour of the cloud management features of Oracle Enterprise Manager Ops Center 12c will give you the information you need get started building your own cloud infrastructure.

To learn more, please go to Oracle Enterprise Manager  web page and stay connected with us at  :

Twitter | Facebook | YouTube | Linkedin | Newsletter


Post a Comment:
  • HTML Syntax: NOT allowed

Latest information and perspectives on Oracle Enterprise Manager.

Related Blogs


« April 2014