Database Reference
In-Depth Information
At this point in the process, we have deployed the ODA_BASE VM, and a small number of steps remain to actually get
a database up and running. The ODA_BASE template can only be accessed via a vncserver through the dom0. The first
VM can be accessed via port 5900 using VNC. This can be done via dom0 or via an external VNC client. The only difference
in the deployment is the access to the VM. The rest of the deployment process is similar to a bare-metal deployment.
#vncsession dom0:5900
The VNC session now established allows access to ODA_BASE host. Once access is established, log in to the host
and execute the deployment command with the file that was created with the offline configuration tool.
# /opt/oracle/oak/bin/oakcli deploy -conf /tmp/offlineconfig.param
The deployment process will complete the process of making the ODA_BASE accessible via the public network,
as well as complete the install of the Clusterware and the Database Appliance Kit software.
Deployment of a User VM
The purpose of virtualizing the ODA is to allow using the resources on the appliance to build a complete environment.
This can be accomplished by building various Application/User virtual machines on the appliance and making it one
box that can host the database, as well as an app, on the same hardware.
Due to the nature of customization in the VM layer to accommodate the Database appliance,
a VM can only be imported into the ODA using dom0. A variety of general-purpose VM templates are available
at http://edelivery.oracle.com . This section will walk through the importing and configuring of the User VM
template onto the ODA.
Virtual Image Repository
When the Virtualization option was first introduced on the ODA platform, there were specific limitations on what a
User-defined VM could do. Some of the limitations included:
No High Availability
Local Repository Access only
The local repository limited VM sizes significantly, with only 250GB available in ODA V1 and 350GB available in
ODA X3-2 for User VMs. Because each physical node was not aware of the others' repositories, VM failover was not
possible and thus High Availability was not an option.
The newest version of the ODA software 2.8, among other enhancements, has added the ability to access the
shared disk via an ASM Cluster File System (ACFS) mount and create a shared repository. This option not only allows
the local space to be used for other uses, but also provides the option of High Availability for the VM itself.
The ODA_BASE is required for the shared repository because the ODA_BASE has access to the shared storage
on the ODA. The process of creating the shared repository includes the process of creating the ACFS mount points, as
well as the NFS export via the private network to dom0. All of this is accomplished via oakcli commands. Depending
on the design, you can create one or many shared repositories at the cost of space in the DATA or RECO diskgroups.
While local repository access is available, using a shared repository is the recommended method in ODA 2.8
and going forward. The local repository is always created by default. Listing 10-4 shows how to create the shared
repository and how to check the status.
Listing 10-4. Shared Repository Creation and Status
# oakcli create repo repo1 -dg data -size 20
# oakcli show repo
 
Search WWH ::




Custom Search