| Oracle® Fusion Applications Installation Guide for Oracle VM 11g Release 1 (11.1.4) Part Number E26570-07 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Installation Guide for Oracle VM 11g Release 1 (11.1.4) Part Number E26570-07 |
|
|
PDF · Mobi · ePub |
This chapter describes the prerequisites for the deployment of Oracle VM templates.
This chapter includes the following sections:
Section 2.5, "Provide Access to NetApp or Sun Storage Server"
Section 2.8, "Prepare an Oracle Enterprise Manager Instance"
Section 2.9, "Configure Standalone Oracle Identity Management"
Section 2.10, "Confirm the Oracle Virtual Assembly Builder Home is Accessible"
The High Availability (HA) topologies require creation of the following Oracle VMs by default. You must have one or more Oracle VM servers that can host the following Oracle VMs.
Node 1: (FA) Contains Administration Servers from all of the Oracle Fusion Applications domains.
Node 2: (Primary) Contains all Managed Servers from Oracle Fusion Applications domains that need to scale out.
Node 3: (Secondary) Contains the remaining Managed Servers from Oracle Fusion Applications domains.
Node 4: Contains the Oracle Business Intelligence domain.
Node 5: Contains the base Oracle HTTP Server (OHS) instance.
Node 6: Contains the High Availability OHS instance and is optional.
Node 7: Contains the primary Managed Servers and is a replica of Node 2. This node is optional.
Node 8: Contains the secondary Managed Servers and is a replica of Node 3. This node is optional.
Node 9: Contains the WebChat and Oracle Beehive instance. This is required only for topologies that support WebChat.
Node 10: Contains the standalone Oracle Identity Management.
Ensure that you allocate virtual host names and virtual IP addresses (static IPs) for each of these nodes. The Domain Name System (DNS) server used in the subnet where the Hypervisors and Oracle VMs reside must resolve the virtual host names and virtual IP addresses. During deployment you specify the values of virtual host names and virtual IP addresses in deployment properties. For more information, see Section 3.1, "Prepare Deployment Properties."
Table 2-1 displays suggested values for memory and number of virtual CPUs (vCPUs) for each topology.
Table 2-1 Suggested Memory (in GB) and Number of vCPUs
| Node Type/Topology | CRM HA | HCM HA | GSI HA |
|---|---|---|---|
|
Node 1 - FA |
20 G 6 vCPU |
15 G 4 vCPU |
23 G 6 vCPU |
|
Node 2 - Primary |
17 G 6 vCPU |
14 G 4 vCPU |
20 G 8 vCPU |
|
Node 3 - Secondary |
50 G 24 vCPU |
43 G 24 vCPU |
68 G 24 vCPU |
|
Node 4 - BI |
6 G 4 vCPU |
6 G 4 vCPU |
6 G 4 vCPU |
|
Node 5 - OHS |
1 G 2 vCPU |
1 G 2 vCPU |
1 G 2 vCPU |
|
Node 9 - WebChat |
5 G 4 vCPU |
Not applicable |
5 G 4 vCPU |
|
Node 10 - Single Tenant IDM |
22 G 4 vCPU |
22 G 4 vCPU |
22 G 4 vCPU |
The memory settings provided are a minimum number to successfully complete deployment and rehydration. Both the memory number and the number of vCPUs on an Oracle VM may be changed during deployment, according to requirements based on a formal sizing exercise.
At the end of deployment, the Administration Servers on the Node 1 are shut down and the memory allocated to this Oracle VM is reduced to only 1.5 GB after rehydration completes successfully. The memory is returned to the pool. This behavior is controlled by the following deployment properties.
faovm.ha.adminserver.shutdown=true faovm.ha.fa.post.rehydrate.memory=1536
If you do not want the Node 1 Administration Servers to shutdown at the end of deployment, you can modify the properties as follows. For information about how to modify these properties, see Section 3.1, "Prepare Deployment Properties."
faovm.ha.adminserver.shutdown=false
faovm.ha.fa.post.rehydrate.memory=value_in_MB
If you set the property, faovm.ha.adminserver.shutdown=false, the Administration Servers stay up and the memory is not changed. If you leave this property set to true but increase the post.rehydrate.memory from 1536, then you are specifying the quantity of memory allocated to the Oracle VM after shutting down the servers.
If you leave the settings at their original values, true and 1536, to get enough memory returned to the Oracle VM to start the Administration Servers, you need to perform the following on the Oracle VM:
login as root echo 30000MB > /proc/xen/balloon
After this step, you can start the Administration Servers. Note that when you use the previous method to increase the memory of the Oracle VM, you can increase the memory only up to the value that was initially allocated for the Oracle VM during rehydration.
Allocate one server host, which can be a smaller machine, as a deployer host. You can use this host to run Oracle VM Manager, mount the Oracle Virtual Assembly Builder home with the templates, and run the deployment. The deployment uses network and disk resources, so two vCPUs and 4 GB of RAM are sufficient.
Do not use one of your Oracle VM servers (Hypervisors) as the deployer host because Hypervisors are not suited for heavy I/O processing and may lock up.
Certain operations that run from the deployer host require root privilege. There are four deployment properties that control how root privileges are obtained, as shown in the following examples. Note that lines beginning with a pound sign, '#', are comments.
# Deploy-only privilege escalation properties, supported methods: run_as_root, sudo, pbrun faovm.privilege.escalation.method=run_as_root # If escalating via run_as_root, path to properly configured run_as_root binary relative to deployfw faovm.privilege.escalation.run_as_root.path=bin/run_as_root #faovm.privilege.escalation.run_as_root.path=/usr/local/packages/aime/ias/run_as_root # If escalating via sudo, path to sudo binary faovm.privilege.escalation.sudo.path=/usr/bin/sudo # If escalating via pbrun, path to pbrun binary faovm.privilege.escalation.pbrun.path=/path/to/pbrun
The property, faovm.privilege.escalation.method, takes a value of run_as_root, sudo, or pbrun, as the method to obtain root privilege. The corresponding properties, faovm.privilege.escalation.x.path where x is run_as_root, sudo or pbrun, specify where the corresponding root privilege utility is located.
The property, faovm.privilege.escalation.run_as_root.path specifies where the run_as_root utility is located. The Oracle VM Automation Utility, described in Section 2.12, "Install the Oracle VM Automation Utility", includes the run_as_root utility in the FAOVM/deokitfw/bin directory. You can prepare the FAOVM/deployfw/bin/run_as_root utility by following these steps before starting the deployment:
Become the root user on the deployer host.
Run these commands:
chown root deployfw/bin/run_as_root chmod u+s deployfw/bin/run_as_root
If the /usr/local/packages utility provided by the Network File System (NFS) is available, then you can use it instead of using the FAOVM/deployfw/bin/run_as_root utility. This can be achieved by:
Comment out this line: #faovm.privilege.escalation.run_as_root.path=bin/run_as_root
Remove the comment from this line: faovm.privilege.escalation.run_as_root.path=/usr/local/packages/aime/ias/run_as_root
If you want to use sudo or pbrun instead, then set the faovm.privilege.escalation.method property to sudo or pbrun, and update the location of the utilities as shown in the following example:
# If escalating via sudo, path to sudo binary faovm.privilege.escalation.sudo.path=/usr/bin/sudo # If escalating via pbrun, path to pbrun binary faovm.privilege.escalation.pbrun.path=/path/to/pbrun
Oracle VM Manager orchestrates the deployment. Follow the steps in the Oracle VM Manager Installation Guide to install Oracle VM Manager on your deployer host.
http://download.oracle.com/docs/cd/E15458_01/doc.22/e15439/toc.htm
After you install Oracle VM Manager, register your Oracle VM server pools with the Oracle VM Manager. For more information, see Section 2.11, "Register Templates with Oracle VM Manager."
Access to a NetApp or a Sun Storage Server is required so that Oracle Fusion Applications Oracle VM automation can create volumes required for deployment. For each deployment instance, the following volumes are created on the storage server during the deployment process if you are using NetApp or Sun Storage Server. If you are using generic Network File System (NFS), then the following volumes must be created and must exist before the deployment process begins. During deployment, the file volumes are mounted in the respective Oracle VMs. To configure the storage server, see Step 5 of Section 3.1, "Prepare Deployment Properties."
Volume 1: Shared by the FA, Primary, Secondary, and BI nodes (120 GB)
Volume 2: Used by the OHS nodes (12 GB)
Volume 3: Used by the WebChat nodes and is optional (12 GB)
Volume 4: Used by the single-tenant IDM node (50 GB)
The volume sizes specified are based on the assumption that Volume 1 consumes approximately 90 GB after rehydration and that OHS and WebChat use approximately 8 GB. These volume sizes can be adjusted during deployment.
Allocate BIG IP end points, both external and internal, for the Oracle VM topology deployment. Table 2-2 and Table 2-3 illustrate examples of BIG IP end points and their mappings to OHS virtual host end points. Replace OHS_VM_IP_ADDR with the IP address of your OHS Oracle VM. The port values for internal end points and the mapped OHS virtual host end points, both internal and external, are fixed and should have the exact values listed. Note that not all end points may be required for all topologies. For example, the end point for ICDomain will not be required for any of the published topologies, but Oracle reserves these ports for future use.
Table 2-2 Internal BIG IP End Points (HTTP - Non-SSL)
| Domain | Internal End Point (host:port) | Mapped to OHS Virtual Host End Point (host:port) |
|---|---|---|
|
CommonDomain |
gsi-elha-fs-int.us.oracle.com:10613 |
OHS_VM_IP_ADDR:10613 |
|
HCMDomain |
gsi-elha-hcm-int.us.oracle.com:10619 |
OHS_VM_IP_ADDR:10619 |
|
CRMDomain |
gsi-elha-crm-int.us.oracle.com:10615 |
OHS_VM_IP_ADDR:10615 |
|
FinancialDomain |
gsi-elha-fin-int.us.oracle.com:10603 |
OHS_VM_IP_ADDR:10603 |
|
ProjectsDomain |
gsi-elha-prj-int.us.oracle.com:10605 |
OHS_VM_IP_ADDR:10605 |
|
ProcurementDomain |
gsi-elha-prc-int.us.oracle.com:10607 |
OHS_VM_IP_ADDR:10607 |
|
ProcurementDomain (Supplier Portal) |
gsi-elha-prc-sp-int.us.oracle.com:10609 |
OHS_VM_IP_ADDR:10609 |
|
SCMDomain |
gsi-elha-scm-int.us.oracle.com:10617 |
OHS_VM_IP_ADDR:10617 |
|
BIDomain |
gsi-elha-bi-int.us.oracle.com:10621 |
OHS_VM_IP_ADDR:10621 |
|
ICDomain |
gsi-elha-ic-int.us.oracle.com:10611 |
OHS_VM_IP_ADDR:10611 |
|
IDMDomain |
gsi-cln-ha-ldap-int.us.oracle.com:7777 |
OHS_VM_IP_ADDR:7777 |
|
IDM Admin |
gsi-cln-ha-ldap-admin.us.oracle.com:443 |
OHS_VM_IP_ADDR:7777 |
Table 2-3 External BIG IP End Points (HTTPS - SSL enabled)
| Domain | External End Point (host:port) | Mapped to OHS Virtual Host End Point (host:port) |
|---|---|---|
|
CommonDomain |
gsi-elha-fs-ext.us.oracle.com:10614 |
OHS_VM_IP_ADDR:10614 |
|
HCMDomain |
gsi-elha-hcm-ext.us.oracle.com:10620 |
OHS_VM_IP_ADDR:10620 |
|
CRMDomain |
gsi-elha-crm-ext.us.oracle.com:10616 |
OHS_VM_IP_ADDR:10616 |
|
FinancialDomain |
gsi-elha-fin-ext.us.oracle.com:10604 |
OHS_VM_IP_ADDR:10604 |
|
ProjectsDomain |
gsi-elha-prj-ext.us.oracle.com:10606 |
OHS_VM_IP_ADDR:10606 |
|
ProcurementDomain |
gsi-elha-prc-ext.us.oracle.com:10608 |
OHS_VM_IP_ADDR:10608 |
|
ProcurementDomain (Supplier Portal) |
gsi-elha-prc-sp-ext.us.oracle.com:10610 |
OHS_VM_IP_ADDR:10610 |
|
SCMDomain |
gsi-elha-scm-ext.us.oracle.com:10618 |
OHS_VM_IP_ADDR:10618 |
|
BIDomain |
gsi-elha-bi-ext.us.oracle.com:10622 |
OHS_VM_IP_ADDR:10622 |
|
ICDomain |
gsi-elha-ic-ext.us.oracle.com:10612 |
OHS_VM_IP_ADDR:10612 |
|
IDMDomain |
gsi-cln-ha-login.us.oracle.com:443 |
OHS_VM_IP_ADDR:7777 |
The Oracle Fusion Applications database that is delivered as part of the Oracle VM template was created by an RMAN backup. The Oracle VM process restores this backup to an already existing database, called the target database. The target database can be either a two-node Oracle Real Application Cluster (Oracle RAC) or a single instance database and must be on a physical machine, not an Oracle VM. For this release, the supported database version is Oracle Database 11.2.0.3.
Review these sections to prepare your database:
The RMAN restore procedure relies on the target database being configured with an spfile. Follow these steps to add an spfile file to the database:
Log in as the sys user.
For the following command:
create spfile from pfile = 'ORACLE_HOME/dbs/initORACLE_SID.ora';
replace ORACLE_HOME and ORACLE_SID with the value of the database that you created and run the command.
If an spfile does not exist for the target database before running the RMAN restore, an error occurs, related to not being unable to find /dbs/spfile.
The following is the setup for a two-node Oracle RAC database for Oracle VM deployment. See Section 2.7.3, "Set Up a Single-Instance Database" for the setup of a single instance database.
Table 2-4 describes the recommended database parameters that should be set prior to database cloning.
Table 2-4 Recommended Database Parameters for Oracle 11.2.0.3
| Parameter | Recommended Value for Starter | Recommended Value for Production |
|---|---|---|
|
|
6708183:ON |
6708183:ON |
|
|
FALSE |
FALSE |
|
|
NONE |
NONE |
|
|
BINARY |
BINARY |
|
|
500 |
500 |
|
|
4 GB |
8 GB |
|
|
NATIVE |
NATIVE |
|
|
5000 |
5000 |
|
|
500 |
500 |
|
|
9 GB |
18 GB |
|
|
12 GB |
12 GB |
|
|
9 GB |
9 GB |
|
|
3 groups; each 2 GB |
3 groups; each 2 GB |
When changing Oracle RAC database parameters to conform with Performance, Scalability and Reliability (PSR) requirements, use and update the spfile in Oracle Automatic Storage Management. Do not save the parameters to a local spfile. The Oracle VM database restore process uses and updates only the Oracle Automatic Storage Management spfile. Oracle VM assumes that the location of the Oracle Automatic Storage Management spfile is:
spfile='+DATADISCGROUP/RACDBNAME/spfileRACDBNAME.ora'
For example:
spfile='+DATA_SLCC10/dbm/spfiledbm.ora'
In this example, DATA_SLCC10 is the Data Disc Group name and dbm is the Oracle RAC database name.
Collect the following information about your Oracle RAC database, which is required when you specify input property values in the deploy.properties file prior to deployment:
Oracle RAC service name
Physical host names for the two-node Oracle RAC database
SID values for the two-node Oracle RAC database
Listener port for the two-node Oracle RAC database, where the ports must be the same on each instance
Oracle home
Operating system user credentials that own the Oracle RAC instance, generally for the oracle user
SYS schema credentials
Oracle Automatic Storage Management DATA disc and REDO disc names
Path to the folders where datafiles, temporary files and redo logs will be restored. You may want to query the Oracle RACs Oracle Automatic Storage Management to get these values.
Path to the spfile in Oracle Automatic Storage Management.
Specify a stage location that is not in the Oracle Automatic Storage Management, to which the contents of the Recovery Manager (RMAN) database backup tar.gz file can be unpacked in preparation for the RMAN restore. The deployment process will restore the RMAN backup of the reference environment database to the target Oracle RAC database using the first node of the two-node Oracle RAC.
Restoring to a single-instance database is similar to restoring to a Oracle RAC database, with the following exceptions:
Set the faovm.ha.fusiondb.new.is.rac property to false. Leave the faovm.ha.fusiondb.src.is.rac property set to true.
If the single instance database (SIDB) is not configured to use Oracle Automatic Storage Management, then you must provide database data file paths to these properties: faovm.ha.fusiondb.new.datafile.path, faovm.ha.fusiondb.new.tempfile.path, and faovm.ha.fusiondb.new.recolog.path. These must be set to the absolute path of the folder where the target database stores data/temp files.
Run show parameter control_files; in SQL*Plus before cloning, to find this path.
Leave the properties for Oracle RAC, faovm.ha.fusiondb.clone.spfile, faovm.ha.fusiondb.clone.datadisc, and faovm.ha.fusiondb.clone.recodisc as they are, but do not leave them empty.
Set the service name to be the same as the SID.
If the single instance database is configured to use Oracle Automatic Storage Management, the following properties should be filled with the correct Oracle Automatic Storage Management disc group names: faovm.ha.fusiondb.new.datafile.path, faovm.ha.fusiondb.newtempfile.path, faovm.ha.fusiondb.new.recolog.path, faovm.ha.fusiondb.new.spfile, fusiondb.new.datadisc, and fusiondb.new.recodisc. You may want to query the Oracle Automatic Storage Management to get these values.
Set the listener port in fusiondb.new.port.
Set both faovm.ha.HOST_DB and faovm.ha.HOST_DB2 equal to the database host.
To create an Oracle Fusion Applications database, several DBA directories must be set accordingly and manually created on the file system. The paths of the DBA directories are defined in the deployment properties file using the following properties. For more information, see Section 3.1, "Prepare Deployment Properties".
# dba_directories configuration (can add as many as needed)
faovm.ha.fusiondb.new.oracle.base=/u01/app/oracle/product/11.2.0_CHANGEME
faovm.ha.fusiondb.new.dba.dir.name0=APPLCP_FILE_DIR
faovm.ha.fusiondb.new.dba.dir.path0=${fusiondb.new.oracle.home}/incident_logs
faovm.ha.fusiondb.new.dba.dir.name1=APPLLOG_DIR
faovm.ha.fusiondb.new.dba.dir.path1=${fusiondb.new.oracle.home}/appllog_dir
faovm.ha.fusiondb.new.dba.dir.name2=ADMIN_DIR
faovm.ha.fusiondb.new.dba.dir.path2=${fusiondb.new.oracle.home}/rdbms/admin
faovm.ha.fusiondb.new.dba.dir.name3=EQ_CONFIG_DIR
faovm.ha.fusiondb.new.dba.dir.path3=${fusiondb.new.oracle.home}/search/webapp/config
faovm.ha.fusiondb.new.dba.dir.name4=XMLDIR
faovm.ha.fusiondb.new.dba.dir.path4=${fusiondb.new.oracle.home}/rdbms/xml
faovm.ha.fusiondb.new.dba.dir.name5=EQ_LANG_DIR
faovm.ha.fusiondb.new.dba.dir.path5=${fusiondb.new.oracle.home}/search/data/language
faovm.ha.fusiondb.new.dba.dir.name6=ORACLE_OCM_CONFIG_DIR
faovm.ha.fusiondb.new.dba.dir.path6=${fusiondb.new.oracle.home}/ccr/state
faovm.ha.fusiondb.new.dba.dir.name7=DATA_PUMP_DIR
faovm.ha.fusiondb.new.dba.dir.path7=${fusiondb.new.oracle.base}/admin/${fusiondb.new.service.name}/dpdump
faovm.ha.fusiondb.new.dba.dir.name8=EQ_CACHE_DIR
faovm.ha.fusiondb.new.dba.dir.path8=${fusiondb.new.oracle.base}/oradata/${fusiondb.new.service.name}/cache
If you do not change these properties in the deployment property file, then manually create the following directories on the database server where ORACLE_HOME is the Oracle Database home directory:
/u01/app/oracle/product/11.2.0_CHANGEME ORACLE_HOME/incident_logs ORACLE_HOME/appllog_dir ORACLE_HOME/rdbms/admi ORACLE_HOME/search/webapp/config ORACLE_HOME/rdbms/xml ORACLE_HOME/search/data/language ORACLE_HOME/ccr/state ORACLE_HOME/admin/fusion_apps_database_service_name/dpdump ORACLE_HOME/oradata/fusion_apps_database_service_name/cache
The Oracle VM deployment process installs an Oracle Enterprise Manager agent into each of the Oracle VMs in the topology. You must prepare an Oracle Enterprise Manager 12c Cloud Control instance (Cloud Control) for the wiring of these agents.
Perform the following steps to prepare a Cloud Control instance.
Refer to the Oracle Enterprise Manager Cloud Control Basic Installation Guide to install this product.
Download and deploy the Oracle Fusion Applications plug-in in your Cloud Control. This is required for the discovery of the deployed Oracle Fusion Applications OVM topology into Cloud Control. For more information, follow the steps in "Deploying and Updating Plug-ins" in the Oracle Enterprise Manager Cloud Control Administrator's Guide.
Ensure that you can deploy the Java VM Diagnostics (JVMD) Manager on your Oracle Enterprise Manager 12c Oracle Management Service. This is required for the JVMD agent deployment that occurs as part of the Oracle Fusion Applications Oracle VM rehydration. For more information, see "Installing JVM Diagnostics" in the Oracle Enterprise Manager Cloud Control Basic Installation Guide.
Apply patch 13258023 for the Oracle Fusion Applications discovery to occur during the Oracle Fusion Applications Oracle VM rehydration process. Follow the steps in the patch README file to patch your Oracle Management Service.
If you use the single-tenant or standalone templates, a standalone 11g Oracle Identity Management Oracle VM is rehydrated as part of the deployment process. This Oracle VM can be deployed in one of two ways: using a single host or using three hosts.
When using single-tenant templates, the default in the properties file is to implement a single-host IDM. This is specified by the idm1 at the beginning of the property:
faovm.topo.ovms=idm1,ohs,fa,secondary,primary,bi,webchat
In this scenario, the following properties must all reference the same host name:
faovm.ha.HOST_IDMDB=server01.oracle.com_CHANGEME
faovm.ha.HOST_LDAP=${HOST_IDMDB}
faovm.ha.HOST_PSTORE=${HOST_LDAP}
faovm.ha.HOST_OIM=${HOST_LDAP}
faovm.ha.HOST_OAM=${HOST_LDAP}
faovm.ha.HOST_WEBGATE=${HOST_IDMDB}
Properties beginning with the prefix faovm.ha.idm1.* must be configured. Properties beginning with faovm.ha.idm3.* can be ignored.
When using single-tenant templates, you have the option of deploying the IDM in an EDG-compliant three-host configuration where the IDM is split as follows:
Host 1: OID DB, OIM DB, OID
Host 2: OIM
Host 3: AuthOHS
These components cannot be rearranged. To tell the deployer to create these three hosts, the faovm.topo.ovms property must look like this:
foavm.topo.ovms=idm3db,idm3mw,idm3ohs,fa,secondary,primary,bi,webchat
In this scenario, the following properties must be set:
faovm.ha.HOST_IDMDB=idm3db_hostname faovm.ha.HOST_LDAP=${HOST_IDMDB} faovm.ha.HOST_PSTORE=${HOST_IDMDB} faovm.ha.HOST_OIM=idm3mw_hostname faovm.ha.HOST_OAM=${HOST_OIM} faovm.ha.HOST_WEBGATE=idm3ohs_hostname
Properties beginning with the prefix faovm.ha.idm3.* must be configured. Properties beginning with faovm.ha.idm1.* can be ignored.
Note that you must leave the property #faom.ha.idm3db.faappsadmin=<FAAdmin>commented (with a "#" at the start of the line).This means that the Oracle Fusion Applications administration user cannot be seeded into LDAP during deployment steps. You must create this user after deployment. For more information on creating and managing users, see "Provisioning Identities" in Oracle Fusion Applications Administrator's Guide
Note also that when using a shared Oracle Identity Management, the property faovm.topo.ovms should not contain an entry for any Identity Management related nodes.
If you use an Oracle VM template that does not contain Oracle Fusion Customer Relationship Management, then do not include webchat in the faovm.topo.ovms property. If WebChat is enabled in a single-instance IDM non-Oracle Fusion Customer Relationship Management topology, users are redirected to the OAM Logon page after any cursor movement in the Manage User page of the Function Setup Manager application.
To prevent WebChat from being deployed in a single-instance IDM non-Oracle Fusion Customer Relationship Management topology, ensure that the following line in the deployment property file does not contain webchat:
faovm.topo.ovms=idm1,ohs,fa,secondary,primary,bi (if 1-host standalone IDM) foavm.topo.ovms=idm3db,idm3mw,idm3ohs,fa,secondary,primary,bi (if 3-host standalone IDM)
Confirm that the Oracle Virtual Assembly Builder software, OVAB_HOME, is accessible from the deployer host. Table 2-5 describes the file location.
Table 2-5 Home Directories
| Home Directory | Description | Variable Representation |
|---|---|---|
|
Oracle Virtual Assembly Builder Home |
This directory is the top-level directory for the Oracle Virtual Assembly Builder that contains all of the software needed to deploy Oracle Fusion Applications as an Oracle VM instance. |
OVAB_HOME |
|
Oracle VM Automation Utility |
This directory is the top-level directory where you install the Oracle VM Automation Utility, as described in Section 2.12, "Install the Oracle VM Automation Utility". Confirm that this directory is accessible from the deployer host. |
FAOVM |
Follow these one-time setup steps to register the topology templates in the appropriate server pools in Oracle VM Manager.
Determine template paths for each node (ohs, fa, bi, webchat) inside the Oracle Virtual Assembly Builder catalog:
setenv ORACLE_HOME OAVB_HOME
setenv AB_INSTANCE $ORACLE_HOME/ab_instance
setenv JAVA_HOME $ORACLE_HOME/jre (or to a valid JDK 1.6 location)
cd $AB_INSTANCE/bin
Run the following command to print information about the following assemblies: component_wls_fa (for the FA node), component_wls_bi (for the BI node), composite_ohs (for the OHS node), and wls_webchat (for the WebChat node, if applicable.)
./abctl edit <<! ? open component_wls_fs ? print !
The output of this command contains the location of the template *.img and *.cfg files inside the catalog for the respective assembly. For example:
template UCMCluster /ovab/small_20110510/ab_instance/catalog/shared/cid_8B6Qd53dUBj2PE3/templates/tid_m1K0GgbdUBj2PE3/templateFiles
There may be multiple template entries in the output, but all of them contain the same directory path for a given assembly. Under the directory there are multiple *.img files and one vm.cfg file. Usually there are System.img, AB.img and vm.cfg files.
Repeat this step to locate the template directories for Oracle Business Intelligence, OHS, and WebChat by using assembly names component_wls_bi, composite_ohs, component_wls_webchat, respectively, in the abctl edit command. Note that for OHS there is an additional ORACLE_INSTANCE.img file, which you must also copy.
Log in to each of your Oracle VM servers and create directories for the fa, bi, ohs, and webchat templates under /OVS/seed_pool. An example for FSCMH V1 MT templates from 20111013 follows:
cd /OVS/seed_pool mkdir ha-fscmh-v1-mt_20111013_ohs (for ohs) mkdir ha-fscmh-v1-mt_20111013_fa (for fa) mkdir ha-fscmh-v1-mt_20111013_bi (for bi) mkdir ha-fscmh-v1-mt_20111013_webchat (for webchat) - Cl.
Copy the *.img files and vm.cfg file, which are located inside the catalog, for the OHS, FA and BI templates into the directories you just created, making sure to copy the correct.img file for the given node type, such as bi. If the wrong.img files are copied, rehydration will fail.
Log in to Oracle VM Manager for example, http://server01.com:8888/OVS. Go to Resources, then Import, and choose Select from Server Pool (Discover and register) to register the templates in Oracle VM manager.
Now the templates are registered in Oracle VM Manager and they correspond to the latest packaged bits stored in your OVAB home.
Register the IDM Oracle VM template in Oracle VM Manager. The IDM template's System.img file and vm.cfg files are located under the OVAB_HOME/idm directory. When copying the IDM template files to the Hypervisor's /OVS/seed_pool, ensure that they are renamed to System.img and vm.cfg.
Perform the following steps to install the Oracle VM Automation Utility on your deployer host.
Create a faovm directory, for example, mkdir /scratch/faovm.
Copy OVAB_HOME/faovm/oracle-ovmautomation-all.zip to /scratch/faovm and unzip.
setenv FAOVM /scratch/faovm
During deployment steps, the deployer host must be able to establish secured shell (SSH) with all the database hosts (Oracle Fusion Applications and IDM), and all of the OVM hosts to be created during the deployment steps. The SSH session uses the OS user credentials specified in the deployment properties.
The default SSH port is port 22. This port must be open for bi-directional communication if you place a firewall between the hosts.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|