Oracle® Fusion Applications Cloning and Content Movement Administrator's Guide 11g Release 6 Refresh 9 (11.1.6) Part Number E38322-13 |
|
|
PDF · Mobi · ePub |
The instructions below should be followed during the Discover phase of Cloning process to help obtain the correct abstract hostnames for Fusion Applications, Identity Management and Databases.
Abstract hostnames are the source hostnames (whether physical or virtual) that are present in Oracle Fusion Applications directory paths, configuration files and metadata, and which will be maintained across clones. They must be added to the /etc/hosts
file in each one of the target environment nodes so that those references resolve to the destination environment itself, not to the source.
For example: When MyCompany provisioned their source environment, the hostname used in the Provisioning wizard was fahost.mycompany.com. Thus, their environment will contain fahost.mycompany.com in many places, such as directory paths, configuration files, and metadata. When they clone this environment, the clones will also contain fahost.mycompany.com in the same places, as the cloning script does not edit these settings. In the destination environment, fahost.mycompany.com is an abstract hostname and must be added to the /etc/hosts
file in each one of the target environment nodes.
Note: abstract hostnames are not the only hostnames that must be added to /etc/hosts
on the target environment. This requirement also exists for internal HTTP endpoints and VIPs used for failover, which are also discussed in this document.
This chapter includes the following aspects of how to discover abstract hostnames for cloning:
There are separate processes for the Fusion Applications components and the Identity Management components.
In Fusion Applications nodes, the easiest way to determine the abstract hostname is to check the provisioning.rsp
file in the source environment. The hostnames used in the Provisioning wizard (Domain Topology Configuration and Web Tier Configuration screens) are saved to the response file in the #Domain Topology
and #Webtier Configuration
sections. These are the abstract names used in the Discovery Workbook for their respective nodes. During the Clone phase, the cloning script uses Fusion Applications abstract hostnames to determine the path to each node's nodemanager startup script, when run in the famt
mode.
Table C-1 Fusion Applications Example: Simple
Fusion Applications installed on host with hostname |
fahost.mycompany.com |
Hostname provided on the Provisioning wizard (Domain Topology) |
fahost.mycompany.com |
Hostname provided on the Provisioning wizard (Web Tier) |
fahost.mycompany.com |
Abstract hostname for node (must be added to |
fahost.mycompany.com |
If the web tier is installed on the same node as the rest of Fusion Applications, the entry for the web tier hostname in the provisioning response file (WEBTIER_HOST
) is normally the same as for the Fusion Applications node. If for any reason it's different (yet they are in the same node), use the Fusion Applications hostname as the abstract name for that node and add the web tier hostname to the "Additional /etc/hosts
File Entries" table in the "Virtual Hosts" tab of the Discovery Workbook. Both hostnames will have to be added to the /etc/hosts
file before running the cloning scripts.
Table C-2 Single Node Install with Two Hostnames Special Case
Hostname as returned by the |
fahost.mycompany.com |
Hostname provided on the Provisioning wizard (Domain Topology) |
fahost.mycompany.com |
Hostname provided on the Provisioning wizard (Web Tier) |
fawebtiervirtual.mycompany.com |
Abstract hostname for node (must be added to |
fahost.mycompany.com |
Additional |
fawebtiervirtual.mycompany.com |
Normally, the hostname in the provisioning response file will match the physical hostname, as returned by the UNIX "hostname"
command. If a source environment setup was done so that the hostname as returned by the UNIX hostname
command and the hostname provided to the Provisioning Wizard were not the same, then there are two abstract names and both must be added to the /etc/hosts
file.
In this case, the hostname provided to the Provisioning Wizard (and found in the provisioning.rsp
file) is used in the Discovery Workbook as the Abstract Hostname of the respective node. The hostname as returned by the Unix hostname
command should be added to the "Additional /etc/hosts File Entries" table in the "Virtual Hosts" tab.
Table C-3 Single Node Install with Web Tier All Using Different Names
Hostname as returned by the |
fahost.mycompany.com |
Hostname provided on the Provisioning wizard (Domain Topology) |
favirtual.mycompany.com |
Hostname provided on the Provisioning wizard (Web Tier) |
fawebtiervirtual.mycompany.com |
Abstract hostname for node (must be added to |
favirtual.mycompany.com |
Additional |
fahost.mycompany.com fawebtiervirtual.mycompany.com |
For Identity Management (as installed in the Oracle Identity Management Enterprise Deployment Guide), abstract hostnames may vary depending on the topology and the hostnames/VIPs provided during the installation and configuration. As a rule of thumb, abstract hostnames for Identity Management nodes match the hostnames as returned by the Unix hostname
command.
Identity Management abstract hostnames are not used by the cloning scripts; however they are used by the clone tool during validation, when "idm" mode is used. The tool will use the abstract hostname of the OAM and OVD nodes to validate the environment's OAM settings. Thus it is important to match the instructions below.
In any case, all Identity Management hostnames, as returned by the UNIX hostname
command, and all virtual hostnames used during the Identity management installation must be added to the /etc/hosts
file. Therefore, if any are not listed in the Abstract Hostname column of the Topology tab of the Discovery Workbook, ensure that they are added to the "Additional /etc/hosts
file entries" table in the "Virtual Hosts" tab.
Note:
if the servers where IDM and Fusion Applications were installed have more than one network card, and the additional network cards are registered in DNS with a different name, these additional names may have ended up in some of the configuration files, even if the 'hostname' command returned the correct one.
More specifically, this has happened with the EMAGENT component and the unexpected hostname turned up on targets.xml.
These additional hostnames must also be added to /etc/hosts on the target.
Ensure the abstract hostname of the node containing OAM is the same as displayed on the OAM Console (System Configuration tab/ Common Configuration/ Server Instances area) in the field labeled "Host". If they don't match, running the cloning tool in validate idm mode may fail. However, it does not affect the actual clone creation.
Ensure the abstract hostname of the node containing OVD is the same as displayed on the OAM Console (System Configuration tab/ Common Configuration/ Data Sources/User Identity Stores/ OIMIDStore page), in the field labeled "Location". If they don't match, running the cloning tool in validate idm mode may fail. However, it does not affect the actual clone creation.
In this case, use the OAM abstract hostname (Section C.1.2.1) as the Abstract Hostname of the respective node in the Discovery Workbook. Add the OVD abstract hostname (Section C.1.2.2) to the "Additional /etc/hosts file entries" table in the "Virtual Hosts" tab of the Discovery Workbook. In this case, running the cloning tool in validate idm mode may fail since the OVD abstract hostname does not exactly match the entry in the OAM configuration.However, it does not affect the actual clone creation.
If any other components share the same node with OVD or OAM, follow the notes above to ensure the abstract hostnames match the appropriate hostname for OAM or OVD. For all other cases, simply use the hostnames as returned by the UNIX hostname command.
Table C-4 Single Node Install Identity Management Install
Hostname as returned by the |
idmhost.mycompany.com |
Hostnames provided during install and configuration |
idstore.mycompany.com policystore.mycompany.comldaphost1.mycompany.comwebhost1.mycompany.comidmhost.mycompany.comidmhost |
Hostname as displayed on the OAM Console |
idmhost.mycompany.com |
Abstract hostname for node (must be added to |
idmhost.mycompany.com (matches the hostname displayed on the OAM Console) |
Additional |
idstore.mycompany.compolicystore.mycompany.comldaphost1.mycompany.comwebhost1.mycompany.comidmhost |
Table C-5 Two-Node Identity Management Install
Node 1 (OVD and OID) |
Hostname as returned by the |
idmhost1.mycompany.com |
Hostnames provided during install and configuration |
idstore.mycompany.com policystore.mycompany.com ldaphost.mycompany.com idmhost1.mycompany.com idmhost1 |
|
Hostname as displayed on the OAM Console |
idstore.mycompany.com |
|
Abstract hostname for node (must be added to |
idstore.mycompany.com(matches the hostname displayed on the OAM Console |
|
Additional |
idmhost1.mycompany.compolicystore.mycompany.comldaphost.mycompany.comwebhost.mycompany.comidmhost1 |
|
Hostname as returned by the |
idmhost2.mycompany.com |
|
Node 2 (WLS and OHS) |
Hostnames provided during install and configuration |
webhost.mycompany.com idmhost2.mycompany.com idmhost2 |
Hostname as displayed on the OAM Console |
idmhost2.mycompany.com |
|
Abstract hostname for node (must be added to |
idmhost2.mycompany.com (matches the hostname displayed on the OAM Console) |
|
Additional |
webhost.mycompany.comidmhost2 |
Database abstract hostnames are the ones used during Identity Management and Fusion Applications installation. Database abstract hostnames are the only ones that will be changed by the clone tool.
When the cloning scripts are run, the tool uses the entries on the tables (located in the Databases tab of the Discovery Workbook) to rewire all database connections. Database information (hostname, port, SID, Service Name) from the source environment is replaced with the destination entries provided, so it's important that the source information you enter on the Discovery Workbook match what's in your source environment.
The OID Database abstract hostname (or multiples, in the case of RAC databases) is the one used during OID installation. On an existing environment it can be identified by inspecting the tnsnames.ora
file located in $OID_INSTANCE/config
.
The Identity Management database abstract hostname (or multiples, in the case of RAC databases) is the one used during installation of Oracle Identity and Access Management (OIM/OAM), as well as Fusion Applications provisioning.
It can be obtained by inspecting the provisioning.rsp
file, or checking the WLS Console for the IDMDomain data sources (all data sources) and Fusion Applications domains data sources (OWSM data sources only).
The Fusion Applications Database abstract hostname (or multiples, in the case of RAC databases) is the one used during Fusion Applications provisioning and can be obtained by inspecting the provisioning.rsp
file.
It can be identified on an existing environment by inspecting the FA domain data sources (with the exception of the OWSM and BI data sources, which instead point at the IDM Database and BI server respectively).
These abstract hostnames should be added to the respective node's Abstract Hostname column in the Topology tab as well as the Source DB Instances row for each database type (OID, IDM, FA) in the Databases tab of the Discovery Workbook.