Skip Headers
Oracle® Fusion Applications Cloning and Content Movement Administrator's Guide
11g Release 8 Refresh 8 (11.1.8)

Part Number E38322-19
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

1 Introduction to Cloning

This chapter contains the following high-level sections:

1.1 Understanding Oracle Fusion Applications Cloning

The cloning discussed in this book refers to the complete duplication of an Oracle Fusion Applications source environment which was initially installed using the standard provisioning tools. Cloning creates a matching destination Fusion Applications environment with its own unique set of access URLs.

Note:

The procedures in this book are NOT designed for Oracle Fusion Applications systems that were installed using OVM templates. If your source system was installed in this way, contact Oracle Support for the correct cloning documentation and procedures.

If you used virtualization technology, such as Oracle Virtual Machines, to host an operating system, but performed full standard provisioning into that virtualization layer, then the procedures in this book CAN be used.

1.1.1 What Is Cloning?

In the simplest terms, the cloning solution involves creating master image copies of the Oracle Fusion Applications components, mounting them to a matching array of destination hardware, and running the cloning tools (faclone.sh) to "rewire" the destination environment. The cloning tools also make the following necessary changes in the destination environment:

  • Password changes

  • Rewiring for new database configuration

  • Cleanup of in-flight processes

  • Rewiring for new Fusion Applications external URLs

In more detail, cloning is the process of duplicating the Fusion Applications file system structure (comprised of servers, storage, and optional load balancer/reverse proxy) onto a fresh destination environment, while making the changes necessary to the software and server configurations to accommodate a new set of URLs for access by end users. Simultaneously, the destination environment must keep all the internal wiring intact, allowing the various Fusion Applications components communicate just as they did on the source.

Technically, this feat is accomplished using virtualized or abstract internal endpoints. This keeps the internal wiring intact on the destination. External endpoints for the destination (the user-accessed URLs) can be defined by the user and will be modified during the cloning process.

Note:

Cloning, as described in this document, relies on local name resolution using /etc/hosts, and details the steps needed for that type of name resolution.

1.1.1.1 Understanding Internal Wiring and Abstract Endpoints

What exactly is meant by "internal wiring"?
When Fusion Applications is installed, the Provisioning Wizard collects information, such as: host names for Fusion Applications, Identity Management, and databases, port numbers, load balancer information, internal virtual hosts and ports, etc. These details, along with system path information, metadata file names, and more, are used by the Provisioning Framework, and the Fusion Applications components themselves, to establish intercommunication. This collection of configurations equals the "internal wiring."

To keep this wiring intact on a new and different environment, the cloning tools rely on internal endpoint abstraction (abstract endpoints). (Clearly, if the endpoints were non-abstract but had a fixed 1:1 relationship with a physical server, they could not be used on multiple environments.) These abstract endpoints have the same name for all clones, but are defined individually, each pointing to its own environment.

During the clone phase (see Section 2.7), the clone tool also validates that the internal endpoints exist in /etc/hosts only.

If, in your existing source environment, you have placed internal names in DNS, they need to be removed. You then must add them to /etc/hosts on each node of the source, where they take over the name resolution activity that was formerly handled on DNS. You should also replace any abstract hostname entries in the source DNS. This is described in Section 2.3.1.

For more information on this topic, see Appendix C, "Abstract Hostnames in Detail".

1.1.1.2 What Does Cloning Include?

The destination environment clone will be an exact replica of the source, including:

  • Complete topology

  • Transactional and setup data

  • Oracle Identity Management components and data

  • Directory structures will be identical between source and destination

  • Internal host names will be the same between source and destination

Cloning relies upon some fundamental design principles that are worth discussing. The basic assumptions that go into cloning are below:

  • The Fusion Applications topology and release version will be identical between source and destination

  • Relies on using /etc/host files for mapping

  • The destination hardware must be capable of having everything brought up before any post clone activities are done. For example, the destination hardware can't be so much smaller that you can't start all JVM processes, without any load.

1.1.1.2.1 Component Review

Reviewing the high-level components of a Fusion Applications instance can help you frame and understand how the terms are used in this guide. A Fusion Applications instance has two basic parts: 1) Identity Management, and 2) Oracle Fusion Applications itself (including the transaction database). The two images below show this in a simplified way:

2IDM databases
FA db with domains and web server

The two fundamental components are broken down as follows:

Oracle Identity Management for Fusion Applications

  • Oracle HTTP Server (OHS): comprises the web tier for Identity Management

  • Oracle Access Manager (OAM): located in the application tier for Identity Management

  • Oracle Identity Manager (OIM): located in the application tier for Identity Management

  • Oracle Virtual Directory (OVD): located in the application tier for Identity Management

  • Identity and Policy Store Oracle Internet Directory (OID) instance: located in the application tier for Identity Management

  • Identity and Access database: located in the data tier for Identity Management

  • Identity and Policy Store database: located in the data tier for Identity Management (may or may not share the same database as Identity and Access database)

Fusion Applications Components:

  • Oracle HTTP Server (OHS): comprises the web tier for Fusion Applications

  • Common Domain, HCM Domain, BI Domain...: sit in the application tier for Fusion Applications.
    These domains represent the various product domains that are installed as a part of the normal provisioning process. Each domain contains the necessary and appropriate administration, WebLogic, and/or SOA servers as described in the installation documentation.

  • Oracle Fusion Applications database: also called the transaction database; located in the data tier of Fusion Applications

1.1.1.3 What Changes are Permitted in Cloning?

The components listed in the Component Review are the only parts handled by the cloning process. If your environment contains additional components or extensions, any re-wiring of those must be done manually during the post-clone phase of the process.

Examples of things that the cloning process will NOT take into consideration are:

  • OIF configuration (commonly used in solutions involving federation/SAML)

  • Single-sign-on integrations

  • HR2HR integration/co-existence

  • Any code that invokes a URL external to Oracle Fusion Applications (also known as outbound messaging)

The following table describes the configurations that may change between the source and destination during cloning:

Component Configuration Can be changed during cloning?

Database
(Identity Management and Fusion Applications)

SID

Yes

Service Name

Yes

Abstract Host Name

Yes

Listener Port Number

Yes

Install Paths

Yes

Passwords

Yes

Schema Names

No

Non-RAC to RAC and vice-versa

No

Oracle Identity Management

SSO External (login) URL and Port Number

Yes

SMTP Email Server/Port

Yes

Admin passwords

Yes

Internal HTTP Endpoints

No

Install Paths

No

Abstract hostnames

No

LDAP User, Group and jpsroot bases

No

Admin usernames

No

Fusion Applications

External HTTP Endpoints (URLs/Ports)

Yes

SMTP Email Server/Port

Yes

Admin and APPID passwords

Yes

Internal HTTP Endpoints

No

Install Paths

No

Topology must be the same as source, no consolidation

No

Abstract hostnames

No

Admin usernames

No

Changes to installed product families, offerings or languages

No

Obfuscation of transactional data

No


1.1.1.4 Terminology

Common terminology used in cloning includes:

Source Environment - An existing Fusion Applications environment that is already installed (and therefore contains the pre-requisite Identity Management for Fusion Applications) against which a copy or clone is to be made. Source environments can be in one of two states; 1) with transactional data or 2) without transactional data.
An example of an environment with transactional data is one in which functional setup has been done and functional scenarios have been executed. (For example, orders were processed or an employee review cycle was completed). An example of an environment without transactional data is one in which the installation of Oracle Identity Management and the provisioning of Oracle Fusion Applications has been completed and validated, but no functional setup has been done and therefore no functional scenarios executed. The cloning process is the same in both cases.

Target Environment - The new environment that will be created as a result of the clone activity. Also called the destination environment.

Content Movement - Refers to the task of moving Fusion Applications components and/or data from one environment to another environment.

Production to Test - A type of content movement that refers to refreshing all the transactional data in a destination environment by copying all the transactional data from a source environment

Physical Host Name -- Refers to the "internal name" of the current computer. On UNIX, this is the name returned by the hostname command.
Physical host name is used by Oracle Fusion Middleware to reference the local host. During installation, the installer automatically retrieves the physical host name from the current computer and stores it in the Oracle Fusion Middleware configuration metadata on disk.

Virtual Host Name -- Virtual host name is a network-addressable host name that maps to one or more physical computers via a load balancer or a hardware cluster. For load balancers, "virtual server name" is used interchangeably with virtual host name in this book. A load balancer can hold a virtual host name on behalf of a set of servers, and clients communicate indirectly with the computers using the virtual host name. A virtual host name in a hardware cluster is a network host name assigned to a cluster virtual IP. Because the cluster virtual IP is not permanently attached to any particular node of a cluster, the virtual host name is not permanently attached to any particular node either.

Abstract Host Name -- An abstract host name is an alias given to represent a physical node. It has a one-to-one relationship with a virtual host name. If your environment was installed before the release of cloning and done without the use of abstract host names, the virtual host names in your source environment will become abstract names in the destination environment. If your source environment did not make use of virtual host names, then physical host names will be used.

HTTP Endpoint - The entity on one end of an HTTP transport. An HTTP endpoint can be represented by an HTTP URL in the form of http(s)://<hostname>:<port>.

External HTTP Endpoint - In Fusion Applications, external HTTP endpoint define a set of URLs used by: 1) end users, to access Fusion Applications pages, and 2) by external systems and tools, to integrate with Fusion Applications.

Depending how the environment is configured, the endpoints may be located at the web tier (Oracle HTTP Server/OHS), or at a load balancer/reverse proxy (LB/RP). (In that case, the LB/RP are configured to forward the requests to the Oracle HTTP Server.)

Internal HTTP Endpoint - In Fusion Applications, internal HTTP endpoints define a set of URLs used by Fusion Applications itself for internal invocations and services. They are not used externally.

Depending how the environment is configured, the endpoints may be located at the web tier (Oracle HTTP Server/OHS), or at a load balancer/reverse proxy (LB/RP). (In that case, the LB/RP are configured to forward the requests to the Oracle HTTP Server.)

1.1.2 Use Cases: When Is Cloning Useful?

Cloning enables the copying of an existing Fusion Applications environment to a new set of servers and has many applications:

  • Standing up a new environment that is a copy of the existing one for testing or development purposes

  • Refreshing non-production systems with production data and production configurations/ binaries

  • Using the gold-image source files as "templates" for creating multiple new environments

1.1.2.1 Other Content Movement Options and How They Differ

Standard database duplication is another kind of content movement, which is a subsection of cloning (duplicating the database structure and contents), but does not include the rest of the Fusion Applications instance.

Production-to-test content movement involves a data refresh from a production system back to a test environment. See Part II, "Production-to-Test Data Movement".

1.1.3 Roadmap: What Does the Cloning Process Entail?

Chapter 2 gives complete details on how to replicate a working Fusion Applications instance onto one or more additional environments. The process involves the following high-level steps:

  • Understanding your source environment and the basic system requirements (Section 1.2 and Section 1.3)

  • Performing an in-depth Discovery process regarding all aspects of the source and destination systems, collated into the detailed workbook provided (Section 2.2)

  • Creating a "master image" of the source Oracle Fusion Applications components, using .tar or other tools (Section 2.3)

  • Preparing the destination environment to receive the .tar copies (Section 2.4)

  • Making the master images accessible to the destination (Section 2.5)

  • Duplicating the databases from source to destination (Section 2.6)

  • Running faclone.sh to extract and rewire components on the destination (Section 2.7)

  • Performing validation steps (Section 2.8)

  • Performing post-clone cleanup (Section 2.9).

  • There are also two appendices: One on optional data masking steps (Appendix A) and one on how to install a new source environment so that the cloning process will be easier later (Appendix B)

1.2 Understanding Your Source Environment

Cloning presumes that you have a working version of Oracle Fusion Applications-- including the Fusion Applications database and Oracle Identity Management components-- installed, configured, and running on a source environment. Consider the following:

1.2.1 If Your Source Environment Has Already Been Installed

If your source environment was already installed before the cloning tools became available, then you likely did not make use of abstract host names. If no abstract names were used then the virtual host names in your source environment will become the abstract names in the destination environment. If the source environment did not make use of virtual host names, then physical host names will be used.

1.2.2 If Your Source Environment Was Installed and Virtualized

If your source environment was installed into a guest operating system, then the cloning process described in this guide still applies.

If the installation did not make use of abstract names, then the virtual host names in the source environment will become the abstract names in the destination environment. If the source environment did not make use of virtual host names, then physical host names will be used. Additionally, how .tar files of the source environment are created may differ, if you wish to clone the entire VM. This is a supported methodology, but details on copying the VMs are not provided in this guide. When you have the copied VMs, the remainder of the process has only minor differences, detailed below:

  • Copying VM images does not follow the .tar process described in this guide, and creation of the clone image files may not be necessary, as the VM image files may already include all the storage used in the environment.

  • You must copy any shared storage to the destination environment separately.

  • Since storage will be copied (either automatically, by copying the VM images, or manually) before the clone phase starts, the cloning response file must include the property:

    IMAGEFILE_EXTRACT=false.

    This disables automatic image file extraction during the clone phase. The clone tool will still perform all extraction verifications normally, so the response file entries for Storage (STORAGE_*) must still be completed; all other IMAGEFILE_* properties should be left blank.

1.2.3 If You Are Installing Your Source Environment Now

If you are installing your source Oracle Fusion Applications instance for the first time, you have the opportunity to plan ahead and follow best-practices during installation that will simplify cloning later. See Appendix B, for tips on how to optimize your installation process for cloning, using abstract host names and generic internal/external HTTP endpoints and LDAP endpoints.

1.3 System Requirements for Cloning

The source and the destination environments must meet the following system requirements.

Note:

The use of symbolic links is not supported in any tier (data-, middle-, or web tier) in either the source or the destination installation.

1.3.1 Source Requirements

Ensure that your source environment meets the following installation, storage, database, and component requirements, before beginning the cloning process. There are also requirements for the destination environment, below.

These requirements refer to the current version of the faclone.sh cloning scripts and tools.

1.3.1.1 Installation and Patch Requirements

Oracle Fusion Applications, in the correct release, was installed and configured, following the procedures in the Basic and/or Enterprise installation guides. (Check the title of this document for the relevant version number of the software. To use this guide, the software and document versions must match.)

Important: Check the Release Notes for any required patches.

Additional installation requirements:

  • Operating system: In this version of cloning, the source and destination environments must be installed on one of the following operating systems:

    - Linux (versions certified for Oracle Fusion Applications).
    - AIX version 7.1
    - Solaris 10

    (This requirement excludes the database, which can run on all supported OSs.)

  • Shells: Ensure the following packages are installed on all host environments before starting the cloning procedure:
    -sh
    -bash
    -korn
    -gawk.

  • Local storage NOT supported: The core Fusion Applications components must have been installed using shared storage. Using the local domain/storage option is not supported for Cloning.

    Note:

    The inventory must use shared storage or the environment cannot be cloned.
    To check how the source environment was configured, open the provisioning.rsp file and search for INSTALL_LOCALCONFIG_ENABLE. If it is set to =true, then the system cannot be cloned.
    For more information on finding and using the provisioning.rsp file, see Section 2.2.1.1, "Where to Find provisioning.rsp and provisioning.plan"

  • Oracle Identity Management: The Identity Management stack must be fully contained on a single domain, and the application tier for Identity Management must be fully contained in a single node.

1.3.1.2 Source Storage Requirements

Table 1-1 shows the mandatory and optional requirements for both shared and local storage. Reminder: Provisioning of core Fusion Applications components must have been done without utilizing the local domain/storage option.

Table 1-1

Component Shared Local DMZ

Database

*Database duplication is currently manual, so storage options can be freely chosen.

Yes

yes

N/A

Identity Management

Yes

Mandatory

One root directory for Identity Management

Shared Storage can be used for all IDM components (or at a minimum for the IDM Oracle_Homes, IDMDomain AdminServer and oraInventory

No

Not supported

If your source environment used local storage for Identity Management, the cloning tools cannot be used

Yes

Optional

One root directory for Identity Management DMZ

Fusion Applications

Yes

Mandatory

One root directory for Fusion Applications

Shared Storage can be used for all FA components (or at a minimum for the components that Provisioning installs on shared storage, in addition to the oraInventory

No

Not supported

If your source environment used local storage for Fusion Applications, the cloning tools cannot be used.

Yes

Optional

One root directory for Fusion Applications DMZ

DMZ storage can contain the OHS Oracle_Home (and may also contain the OHS instance


1.3.1.3 Database Requirements

Database cloning involves two major categories of database: the Oracle Fusion Applications transaction database, and the Oracle Identity Management databases. Database duplication is done using RMAN or other duplication mechanisms. This is an independent process from copying the core Fusion Applications components, and has the following restrictions: 1) it must be done before the cloning scripts have been run to reconfigure the destination environment, and 2) no patching or other modifications are allowed after the environment has been frozen, to ensure that the database and Fusion Applications components remain synchronized. See Section 2.6 for details.

Note that it is not possible to selectively move data from source to destination; all data is moved. Also, during the Clone phase, in-flight transactional data, business process instances, queues, home page pop-up notifications, and jobs will be deleted. This is not optional, as the goal is to guarantee that no leftover processes access the source environment.

Successful database duplication requires the following conditions:

  • Source and destination operating systems must be identical.

  • Each database must be a physical copy of the source, not a logical copy created using data pump or other tools.

  • Oracle Fusion Applications installation version and patch set must match requirements, and have been duplicated exactly on the destination, before database copying begins.

  • Oracle Home must be registered in the destination environment's inventory.

  • If RMAN is the preferred method, then the RMAN DUPLICATE command should be used.

  • When the source database is a RAC database with multiple instances and the target is a non-RAC database or a single node RAC, specify the same database host name and port. The number of entries specified should match the number of instances that existed in the source database.

  • If RAC is used, ensure that the Grid infrastructure is installed on the destination environment.

  • The backup of the Fusion Applications database and the Oracle Identity Management database(s) must be a cold backup, with the source application down. (A backup taken while Oracle Fusion Applications is running could leave the destination environment inoperable.)

  • Steps must be taken to fence off the destination server(s) and set the job_queue processes to 0 before starting RMAN duplication, to ensure that when the duplicate database is started it will not process jobs, and that the duplicate is isolated from the production systems.

1.3.1.4 Oracle Identity Management Component Requirements

  • Oracle Internet Directory (OID): In a scaled-out/high-availability environment, the port numbers for all instances must be the same.

  • Oracle Virtual Directory (OVD): In a scaled-out/high-availability environment, the port numbers for all instances must be the same, and only one OVD component is allowed per instance. (The component name is configurable, but must be the same for all instances.)

  • Endpoints: For the Identity Management component, the internal endpoints (such as admin.mycompany.com) must use a different port from the external endpoints (such as sso.mycompany.com).

  • If the source environment was created using IDM scripts, check the following:

    1. Check jpsroot in Identity Management for the CSF entry. If the CSF entry is not present, then:

    2. Go to the Enterprise Manager Cloud Control UI, and set the OVD Enterprise Manager user and password.

    3. Go to the $OVD_INSTANCEHOME/bin and call opmnctl deregisterinstance with the correct options.

    4. In Enterprise Manager, confirm the setting for OVD.

    5. In LDAP, confirm the CSF entry.

  • Policy and Credential Store Entries: Check your source environment; the entry cn=OVD,cn=CredentialStore,cn=IDMDomain,cn=JPSContext,cn=idm_jpsroot must be present in the Policy Store. If it is not, then do the following:

    $OVD_INSTANCE/bin/opmnctl unregisterinstance
     
    $OVD_INSTANCE/bin/opmnctl registerinstance -adminHost
    adminvhn.mycompany.com -adminPort 7001 -adminUser weblogic 
    

    The entry cn=OVD should also be present in the Credential Store.

1.3.1.5 Port Requirements

The clone environment will use the same ports as the source; therefore all ports used in the source environment must also be available on the destination.

Note:

If any component is using privileged ports (< 1024), it becomes necessary to maintain root permissions, so the extraction of the master images on the destination environment must be performed manually by the customer as root.

In this case, you must set IMAGEFILE_EXTRACT=false on the faclone.rsp, so the clone tool will skip image file extraction. All other preparation and clone activities remain the same.

1.3.2 Destination Requirements

When planning the destination environment, keep the following requirements in mind:

1.3.2.1 Destination Server Requirements

  • Topology: There is a direct mapping between source and destination environment topologies. The destination environment will have the same number of hosts/nodes and the same number of managed servers as existed in the source environment prior to any scale-out activities. For example, if the target environment distributed Fusion Applications across two hosts (meaning a portion of the WebLogic domains reside on one server and a portion on the other) then the target environment will also require two hosts to distribute the cloned Fusion Application across in matching fashion.

    The destination hardware cannot be so much smaller than the source so as to require a change in the topology of the primary server(s) in the source system. For example the RAM in the target environment cannot be so much smaller than the source's primary server that all of the managed servers defined in the target's primary servers cannot start up or run effectively.

  • Operating system: Target and source nodes have the same operating system and version number.

  • Users: The "Oracle" Operating System User that will own the destination Fusion Applications install is configured on all nodes with the same ID and Groups as the source.

  • Random Number Generator (rdng): Because cloning does a great deal of encryption, it requires a large pool of random numbers. If this pool is depleted, the cloning process runs very slowly and appears to hang. To avoid this, rndg must be running on the destination environment before the cloning scripts are run.

  • SUDO password requirements (Linux only): If the source environment is scaled-out, the destination environment must have SUDO set up so that passwords are not required. For information on how to do this, see the section on "Setting Environment and Superuser Privileges for the wlsifconfig.sh Script" in the Oracle Fusion Applications Installation Guide.

1.3.2.2 Have JDK Installed on Destination So Clone Package Can be Extracted

This is a chicken-egg issue; the JDK resides on the source and is included in the source clone, yet it must be pre-installed on the destination to extract the clone. To manage this:

  1. On the source environment, locate the repository and the JDK (usually located in repository_location/jdk6).

  2. On the destination environment, create the Clone_Home directory and copy this JDK from the source into the Clone_Home directory.

    Note:

    If the GCC Linux Java implementation is already installed on the destination, it should not be used. Use the JDK as described above instead.

1.3.2.3 Target Storage Requirements

The storage setup on the destination environment must mirror the source, having:

  • Same size requirements

  • Same mount point

  • Shared storage must be mounted to equivalent nodes