| Oracle® Fusion Applications Cloning and Content Movement Administrator's Guide 11g Release 5 Refresh 8 (11.1.5) Part Number E38322-12 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Cloning and Content Movement Administrator's Guide 11g Release 5 Refresh 8 (11.1.5) Part Number E38322-12 |
|
|
PDF · Mobi · ePub |
This chapter contains the following high-level sections:
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.
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.
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".
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.
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:
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
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 |
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 |
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 |
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
Test to Production - A type of content movement that refers to the creating a new environment from a source environment which contains transactional data. In this case the environment created will NOT include any transactional data, however the destination will contain the same configurations as the 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.)
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
The Oracle Fusion Applications Administrator's Guide provides instructions on performing test-to-production content movement. This differs from cloning in that the transaction data is not duplicated. Thus, test users and transactions are not ported into the production system.
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. Standardized tools for this process are planned for upcoming Oracle Fusion Applications releases.
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)
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:
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.
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.
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.
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.
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.
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 Linux only (versions certified for Oracle Fusion Applications). (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.
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 |
Yes Optional One root directory per Identity Management node, including DMZ |
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 |
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 |
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.
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:
Check jpsroot in Identity Management for the CSF entry. If the CSF entry is not present, then:
Go to the Enterprise Manager Cloud Control UI, and set the OVD Enterprise Manager user and password.
Go to the $OVD_INSTANCEHOME/bin and call opmnctl deregisterinstance with the correct options.
In Enterprise Manager, confirm the setting for OVD.
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.
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.
When planning the destination environment, keep the following requirements in mind:
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 Oracle Fusion Applications Financials Enterprise Deployment Guide.
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:
On the source environment, locate the repository and the JDK (usually located in repository_location/jdk6).
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.
|
 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
