| Oracle® Enterprise Manager Cloud Control Administrator's Guide 12c Release 1 (12.1.0.2) Part Number E24473-16 |
|
|
PDF · Mobi · ePub |
| Oracle® Enterprise Manager Cloud Control Administrator's Guide 12c Release 1 (12.1.0.2) Part Number E24473-16 |
|
|
PDF · Mobi · ePub |
This chapter discusses best practices for installation and configuration of each Cloud Control component and covers the following topics:
Installation Best Practices for Enterprise Manager High Availability
Configuring a Standby Database for the Management Repository
Configuring Management Service to RAC Management Repository Communication
Configuring the First Management Service for High Availability
The following sections document best practices for installation and configuration of each Cloud Control component.
The Management Agent is started manually. It is important that the Management Agent be automatically started when the host is booted to insure monitoring of critical resources on the administered host. To that end, use any and all operating system mechanisms to automatically start the Management Agent. For example, on UNIX systems this is done by placing an entry in the UNIX /etc/init.d that calls the Management Agent on boot or by setting the Windows service to start automatically.
Once the Management Agent is started, the watchdog process monitors the Management Agent and attempts to restart it in the event of a failure. The behavior of the watchdog is controlled by environment variables set before the Management Agent process starts. The environment variables that control this behavior follow. All testing discussed here was done with the default settings.
EM_MAX_RETRIES – This is the maximum number of times the watchdog will attempt to restart the Management Agent within the EM_RETRY_WINDOW. The default is to attempt restart of the Management Agent three times.
EM_RETRY_WINDOW - This is the time interval in seconds that is used together with the EM_MAX_RETRIES environmental variable to determine whether the Management Agent is to be restarted. The default is 600 seconds.
The watchdog will not restart the Management Agent if the watchdog detects that the Management Agent has required restart more than EM_MAX_RETRIES within the EM_RETRY_WINDOW time period.
The Management Agent persists its configuration, intermediate state and collected information using local files in the agent_inst directory.
In the event that these files are lost or corrupted before being uploaded to the Management Repository, a loss of monitoring data and any pending alerts not yet uploaded to the Management Repository occurs.
To protect from such losses, configure these sub-directories on striped redundant or mirrored storage. The Management Agent agent_inst directory is shown by entering the command 'emctl getemhome' on the command line, or from the Management Services and Repository > Agents tab in the Cloud Control console.
Before installing Enterprise Manager, you should prepare the database, which will be used for setting up Management Repository. Install the database using Database Configuration Assistant (DBCA) to make sure that you inherit all Oracle install best practices.
Note:
The Management Repository should be installed as a dedicated database when setting up a highly available Enterprise Manager environment. Deploying the repository as a dedicated database allows repository failover to take place without affecting other applications.For both high availability and scalability, you should configure the Management Repository in the latest certified database version, with the RAC option enabled. Check for the latest version of database certified for Enterprise Manager from the Certify tab on the My Oracle Support Web site.
Choose Automatic Storage Management (ASM) as the underlying storage technology.
When the database installation is complete:
Go to $ORACLE_HOME/rbdms/admin directory of the database home and execute the 'dbmspool.sql'
This installs the DBMS_SHARED_POOL package, which will help in improving throughput of the Management Repository.
Management Repository Configuration to perform after installing the Management Service
There are some parameters that should be configured during the Management Repository database install (as previously mentioned) and some parameters that should be set after the Management Service has been installed.
Start by installing Management Agents on each Management Repository node. Once the Management Agents are installed and the Management Repository database is discovered as a target, the Enterprise Manager console can be used to configure these best practices in the Management Repository.
Enable ARCHIVELOG Mode
Enable Block Checksums
Configure the Size of Redo Log Files and Groups Appropriately
Use a Flash Recovery Area
Enable Flashback Database
Use Fast-Start Fault Recovery to Control Instance Recovery Time
Enable Database Block Checking
Set DISK_ASYNCH_IO
The details of these settings are available in Oracle Database High Availability Best Practices.
Use the MAA Advisor for additional high availability recommendations that should be applied to the Management Repository. To access the MAA Advisor:
On the Database Target Home page, locate the High Availability section.
Click Details next to the Console item.
In the Availability Summary section of the High Availability Console page, click Details located next to the MAA Advisor item.
Prerequisites
The standby site must be similar to the primary site in terms of hardware and network resources to ensure there is no loss of performance when failover happens.
There must be sufficient network bandwidth between the primary and standby sites to handle peak redo data generation.
Configuration Steps
The following steps describe the procedure for setting up a standby Management Repository database.
Prepare Standby Management Repository hosts for Data Guard
Install a Management Agent on each of the standby Management Repository hosts. Configure the Management Agents to upload by the SLB on the primary site. Install Grid infrastructure and RAC Database software on the standby Management Repository hosts. The version used must be the same as that on the primary site.
Prepare the primary Management Repository database for Data Guard
If the primary Management Repository database is not already configured, enable archive log mode, setup flash recovery area and enable flashback database on the primary Management Repository database.
Create the Physical Standby Database
Use the Enterprise Manager console to set up a physical standby database in the standby environment. The Standby Management Repository database must be a Physical Standby. Logical standby Management Repository databases are not supported.
The Enterprise Manager Console does not support creating a standby RAC database. If the standby database has to be RAC, configure the standby database using a single instance and then use the 'Convert to RAC' option from the Enterprise Manager Console to convert the single instance standby database to RAC. Note that the Convert to RAC option is available for Oracle Database releases 10.2.0.5, 11.1.0.7, and above. Oracle Database release 11.1.0.7 requires patch 8824966 for the Convert to RAC option to work.
During single instance standby creation, best practice is to create the database files on shared storage, ideally ASM, to facilitate conversion to RAC later.
Add Static Service to the Listener.
To enable Data Guard to restart instances during the course of broker operations, a service with a specific name must be statically registered with the local listener of each instance. The value for the GLOBAL_DBNAME attribute must be set to a concatenation of <db_unique_name>_DGMGRL.<db_domain>. For example, in the LISTENER.ORA file:
SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SID_NAME=sid_name)
(GLOBAL_DBNAME=db_unique_name_DGMGRL.db_domain)
(ORACLE_HOME=oracle_home)))
Enable Flashback Database on the Standby Database.
To allow re-instate of an old primary database as a standby database after a failover, flashback database must be enabled. Hence do so for both the primary and the standby databases.
To allow Enterprise Manager to monitor a Physical Standby database (which is typically in a mounted state), specify sysdba monitoring privileges. This can be specified either during the Standby creation wizard itself or post creation by modifying the Monitoring Configuration for the standby database target.
Verify the Physical Standby
Verify the Physical Standby database through the Enterprise Manager Console. Click the Log Switch button on the Data Guard page to switch log and verify that it is received and applied to the standby database.
If the Management Repository is a Real Application Cluster (RAC) database, the Management Service processes need to be configured to communicate with each node of the RAC database in a redundant fashion.
Note that RAC nodes are referred to by their virtual IP (vip) names. The service_name parameter is used instead of the system identifier (SID) in connect_data mode and failover is turned on. Refer to the Oracle Database Net Services Administrator's Guide for details.
Configure the repository connect descriptor by running the emctl command from any Management Service:
emctl config oms -store_repos_details -repos_conndesc '(DESCRIPTION= (ADDRESS_LIST=(FAILOVER=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=node1-vip.example.com)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=node2-vip.example.com)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=EMREP)))' -repos_user sysman
After making the previous change, run the following command from any one OMS to make the same change to the monitoring configuration used for the Management Services and Repository target:
emctl config emrep -conn_desc <repository_connect descrptor as above>
The Management Service itself has a built-in restart mechanism based on the Oracle Weblogic Node Manager and the Oracle Process Management and Notification Service (OPMN). These services will attempt to restart a Management Service that is down. It is advisable to run OPMN and Node Manager as operating system services, so that they restart automatically if their host machine is restarted.
If you are managing a large environment with multiple Management Services and Management Repository nodes, then consider installing the Management Services on hardware nodes that are different from Management Repository nodes (Figure 27-1). This allows you to scale out the Management Services in the future.
Also consider the network latency between the Oracle Management Service and the Management Repository while determining the Management Service install location. The distance between the Management Service and the Management Repository may be one of the factors that affect network latency and hence determine Enterprise Manager performance.
If the network latency between the Oracle Management Service and Management Repository tiers is high or the hardware available for running Enterprise Manager is limited, then the Management Service can be installed on the same hardware as the Management Repository (Figure 27-2). This allows for Enterprise Manager high availability, as well as keep the costs down.
If you plan ahead, you can configure your Enterprise Manager deployment for high availability by choosing the correct options during the first Management Service install. You can also retrofit the MAA best practices into an existing Enterprise Manager deployment configured initially using the default install options.
This section provides a general reference for Cloud Control administrators who want to configure Enterprise Manager Cloud Control in Cold Failover Cluster (CFC) environments.
The following conditions must be met for Cloud Control to fail over to a different host:
The installation must be done using a Virtual Host Name and an associated unique IP address.
Install on a shared disk/volume which holds the binaries and the gc_inst directory.
The Inventory location must failover to the surviving node.
The software owner and time zone parameters must be the same on all cluster member nodes that will host this Oracle Management Service (OMS).
To override the physical host name of the cluster member with a virtual host name, software must be installed using the parameter ORACLE_HOSTNAME.
The software must be installed using the command line parameter -invPtrLoc to point to the shared inventory location file, which includes the path to the shared inventory location.
If you are using an NFS mounted volume for the installation, please ensure that you specify rsize and wsize in your mount command to prevent running into I/O issues.
For example:
oms.example.com:/u01/app/share1 /u01/app/share1 nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noac,vers=3,timeo=600 0 0
Note:
Any reference to shared failover volumes could also be true for non-shared failover volumes which can be mounted on active hosts after failover.You can set up the virtual host name and virtual IP address by either allowing the clusterware to set it up, or manually setting it up yourself before installation and startup of Oracle services. The virtual host name must be static and resolvable consistently on the network. All nodes participating in the setup must resolve the virtual IP address to the same host name. Standard TCP tools such as nslookup and traceroute can be used to verify the host name. Validate using the following commands:
nslookup <virtual hostname>
This command returns the virtual IP address and full qualified host name.
nslookup <virtual IP>
This command returns the virtual IP address and fully qualified host name.
Be sure to try these commands on every node of the cluster and verify that the correct information is returned.
Storage can be managed by the clusterware that is in use or you can use any shared file system (FS) volume, such as NFS, as long as it is not an unsupported type, such as OCFS V1.
Note:
Only OCFS V1 is not supported. All other versions of OCFS are suppored.If the OHS directory is on a shared storage, the LockFile directive in the httpd.conf file should be modified to point to a local disk, otherwise there is a potential for locking issues.
Some operating system versions require specific operating system patches be applied prior to installing 12c. The user installing and using the 12c software must also have sufficient kernel resources available. Refer to the operating system's installation guide for more details. Before you launch the installer, certain environment variables need to be verified. Each of these variables must be identically set for the account installing the software on ALL machines participating in the cluster:
OS variable TZ
Time zone setting. You should unset this variable prior to installation.
PERL variables
Variables such as PERL5LIB should also be unset to avoid association to the incorrect set of PERL libraries
The user and group of the software owner should be defined identically on all nodes of the cluster. This can be verified using the 'id' command:
$ id -a
uid=550(oracle) gid=50(oinstall) groups=501(dba)
Use the following steps to set up shared inventory:
Create your new ORACLE_HOME directory.
Create the Oracle Inventory directory under the new ORACLE_HOME:
$ cd <shared oracle home>
$ mkdir oraInventory
Create the oraInst.loc file. This file contains the Oracle Inventory directory path information needed by the Universal Installer.
vi oraInst.loc
Enter the path information to the Oracle Inventory directory and specify the group of the software owner as the oinstall user. For example:
inventory_loc=/app/oracle/share1/oraInventory
inst_group=oinstall
Refer to the following steps when installing the software:
Create the shared disk location on both the nodes for the software binaries.
Point to the inventory location file oraInst.loc (under the ORACLE_BASE in this case), as well as specifying the host name of the virtual group. For example:
$ runInstaller -invPtrloc /app/oracle/share1/oraInst.loc ORACLE_HOSTNAME=lxdb.example.com -debug
Install Oracle Management Services on cluster member Host1.
Continue the remainder of the installation normally.
Once completed, copy the files oraInst.loc and oratab to /etc on all cluster member hosts (Host2, Host3, ...)
Windows Specific Configuration Steps
On Windows environments, an additional step is required to copy over service and keys required by the Oracle software. Note that these steps are required if your clustering software does not provide a shared windows registry.
Using regedit on the first host, export each Oracle service from under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.
Using regedit on the first host, export HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE.
Use regedit to import the files created in step 1 and 2 to the failover host.
Ensure that you start your services in the proper order. Use the order listed below:
Establish the IP address on the active node.
Start the TNS listener (if it is part of the same failover group).
Start the database (if it is part of the same failover group).
Start Cloud Control using emctl start oms
Test functionality.
In case of failover, refer to Chapter 29, "Managing Switchover and Failover Operations".
The software library location must be accessible by all active Management Services. The configuration of software library is not performed during installation and needs to be configured post-install using the Enterprise Manager Console:
On the Enterprise Manager home page, from the Setup menu, select Provisioning and Patching, and then select Software Library.
Click the Provisioning subtab.
On the Provisioning page, click the Administration subtab.
In the Software Library Configuration section, click Add to set the Software Library Directory Location to a shared storage that can be accessed by any host running the Management Service.
This section describes the guidelines for setting up a Server Load Balancer (SLB) to balance the agent and browser traffic to multiple Management Services.
Server Load Balancer Requirements
In order to configure your OMS's in an active/active configuration behind an SLB, your SLB must meet the following requirements:
The SLB must provide support for multiple virtual server ports.
Enterprise Manager typically requires that up to 4 ports are configured on the SLB (Secure Upload, Agent Registration, Secure Console, Unsecure Console)
Support for persistence.
HTTP and HTTPS traffic between the browser and the OMS requires persistence.
Support for application monitoring.
The SLB must be capable of monitoring the health of the OMSs and detecting failures, so that requests will not be routed to OMSs that are not available.
SLB configuration is a two-step process:
Configure the SLB
Make requisite changes on the Management Services.
Use the following table as reference for setting up the SLB with Cloud Control Management Services.
Table 27-1 Management Service Ports
| Cloud Control Service | TCP Port | Monitor Name | Persistence | Pool Name | Load Balancing | Virtual Server Name | Virtual Server Port |
|---|---|---|---|---|---|---|---|
|
Secure Upload |
4900 |
mon_gcsu4900 |
None |
pool_gcsu4900 |
Round Robin |
vs_gcsu4900 |
4900 |
|
Agent Registration |
4889 |
mon_gcar4889 |
Active Cookie Insert |
pool_gcar4889 |
Round Robin |
vs_gcar4889 |
4889 |
|
Secure Console |
7799 |
mon_gcsc7799 |
Source IP |
pool_gcsc7799 |
Round Robin |
vs_gcsc443 |
443 |
|
Unsecure Console (optional) |
7788 |
mon_gcuc7788 |
Source IP |
pool_gcuc7788 |
Round Robin |
vs_gcuc80 |
80 |
Use the administration tools that are packaged with your SLB. A sample configuration follows. This example assumes that you have two Management Services running on host A and host B using the default ports as listed in Table 33–1.
Create Pools
A pool is a set of servers grouped together to receive traffic on a specific TCP port using a load balancing method. Each pool can have its own unique characteristic for a persistence definition and the load-balancing algorithm used.
Table 27-2 Pools
| Pool Name | Usage | Members | Persistence | Load Balancing |
|---|---|---|---|---|
|
pool_gcsu4900 |
Secure upload |
HostA:4900 HostB:4900 |
None |
Round Robin |
|
pool_gcar4889 |
Agent registration |
HostA:4889 HostB:4889 |
Active cookie insert; expiration 60 minutes |
Round Robin |
|
pool_gcsc7799 |
Secured console access |
HostA:7799 HostB:7799 |
Source IP; expiration 60 minutes |
Round Robin |
|
pool_gcuc7788 (optional) |
Unsecured console access |
HostA:7788 HostB:7788 |
Source IP; expiration 60 minutes |
Round Robin |
Create Virtual Servers
A virtual server, with its virtual IP Address and port number, is the client addressable hostname or IP address through which members of a load balancing pool are made available to a client. After a virtual server receives a request, it directs the request to a member of the pool based on a chosen load balancing method.
Create Monitors
Monitors are used to verify the operational state of pool members. Monitors verify connections and services on nodes that are members of load-balancing pools. A monitor is designed to check the status of a service on an ongoing basis, at a set interval. If the service being checked does not respond within a specified timeout period, the load balancer automatically takes it out of the pool and will choose the other members of the pool. When the node or service becomes available again, the monitor detects this and the member is automatically accessible to the pool and able to handle traffic.
Table 27-4 Monitors
| Monitor Name | Configuration | Associate With |
|---|---|---|
|
mon_gcsu4900 |
Type: https Interval: 60 Timeout: 181 Send String: GET /empbs/upload Receive String: Http Receiver Servlet active! |
HostA:4900 HostB:4900 |
|
mon_gcar4889 |
Type: http Interval: 60 Timeout: 181 Send String: GET /empbs/genwallet Receive String: GenWallet Servlet activated |
HostA:4889 HostB:4889 |
|
mon_gcsc7799 |
Type: https Interval: 5 Timeout: 16 Send String: GET /em/console/home HTTP/1.0\n Receive String: /em/login.jsp |
HostA:7799 HostB:7788 |
|
mon_gcuc7788 (optional) |
Type: https Interval: 5 Timeout: 16 Send String: GET /em/console/home HTTP/1.0\n Receive String: /em/login.jsp |
HostA:7788 HostB:7788 |
Note: If you have SSO configured, use the following alternate definitions for the mon_gcsc7799 and mon_gcuc7788 monitors.
Table 27-5 Monitors for SSO Configuration
| Monitor Name | Configuration | Associate With |
|---|---|---|
|
mon_gcsc7799 |
Type: https Interval: 5 Timeout: 16 Send String: GET /empbs/genwallet Receive String: GenWallet Servlet activated |
HostA:7799 HostB:7788 |
|
mon_gcuc7788 (optional) |
Type: https Interval: 5 Timeout: 16 Send String: GET /empbs/genwallet Receive String: GenWallet Servlet activated |
HostA:7788 HostB:7788 |
Note:
F5 SLB monitors expect the "Receive String" within the first 5120 characters of a response. For SSO environments, the "Receive String" may be returned at some point beyond the 5120 limit. The monitor will not function in this situation.Perform the following steps:
Resecure the Oracle Management Service
By default, the service name on the Management Service-side certificate uses the name of the Management Service host. Management Agents do not accept this certificate when they communicate with the Oracle Management Service through a load balancer. You must run the following command to regenerate the certificate on each Management Service:
emctl secure oms -host slb.example.com -secure_port 4900 -slb_port 4900 -slb_console_port 443 -console [-lock] [-lock_console]
Output:
Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.1.0 Copyright (c) 1996, 2012 Oracle Corporation. All rights reserved. Securing OMS... Started. @ Enter Enterprise Manager Root (SYSMAN) Password : @ Enter Agent Registration Password : Securing OMS... Successful Restart OMS
Resecure all Management Agents
Management Agents that were installed prior to SLB setup, including the Management Agent that comes with the Management Service install, would be uploading directly to the Management Service. These Management Agents will not be able to upload after SLB is setup. Resecure these Management Agents to upload to the SLB by running the following command on each Management Agent:
emctl secure agent –emdWalletSrcUrl https://slb.example.com:<upload port>/em
There are two ways to install an additional Management Services:
Using the Add Additional OMS Deployment Procedure (preferred method). For more information about using this deployment procedure, see the chapter on Adding Additional Oracle Management Service in the Oracle® Enterprise Manager Cloud Control Basic Installation Guide.
Installing Additional Oracle Management Service in Silent Mode (alternative method). For more information about silent mode installation, see the Oracle® Enterprise Manager Cloud Control Advanced Installation and Configuration guide.
Consider the following before installing the standby Management Services.
Oracle recommends that this activity be done during a lean period or during a planned maintenance window. When new Oracle Management Service instances are installed on the standby site, they are initially configured to connect to the Management Repository database on the primary site. Some workload will be taken up by the new Management Service. This could result in temporary loss in performance if the standby site Management Services are located far away from the primary site Management Repository database. However there would be no data loss and the performance would recover once the standby Management Services are shutdown post configuration.
Prerequisites
The primary site must be configured as per Cloud Control MAA guidelines described in previous sections. This includes Management Services fronted by an SLB and all Management Agents configured to upload to Management Services by the SLB.
The standby site must be similar to the primary site in terms of hardware and network resources to ensure there is no loss of performance when failover happens.
Configure storage used by the software library to be replicated at the primary and standby site. In the event of a site outage, the contents of this storage must be made available on the standby site using hardware vendor disk level replication technologies.
The shared storage used for the software library must be made available on the standby site using the same paths as the primary site.
For complete redundancy in a disaster recovery environment, a second load balancer must be installed at the standby site. The secondary SLB must be configured in the same fashion as the primary. Some SLB vendors (such as F5 Networks) offer additional services that can be used to pass control of the Virtual IP presented by the SLB on the primary site to the SLB on the standby site in the event of a site outage. This can be used to facilitate automatic switching of Management Agent traffic from the primary site to the standby site.
Install the first standby Management Service using the following steps:
Copy the emkey to the Management Repository by running the following command on the first Management Service on the primary site:
emctl config emkey -copy_to_repos
Export the configuration from the first Management Service on the primary site using:
emctl exportconfig oms -dir <location for the export file>
After the configuration is exported, do not make any configuration changes to the primary site still the standby management service is configured.
Install a Management Agent on the standby host if one does not already exist.
Perform a software-only install of the Enterprise Manager software using a modified version of the “Add Management Service” Deployment Procedure.
From the Enterprise menu, select Provisioning and Patching, then select Procedure Library.
Select Add Management Service procedure and click Create Like.
Go to the Procedure Steps tab and select and disable the steps - “Configure Management Service”, “Targets Discovery” and “Post Configuration Tasks”.
Save the modified deployment procedure and use it to install the Enterprise Manager software on the standby OMS host.
After the Deployment Procedure completes, delete the file emInstanceMapping.properties from <OMS Oracle Home>/sysman/config on the standby OMS host.
Delete the emInstanceMapping.properties file from the following location
$ORACLE_HOME/sysman/config
Configure the Management Service by running omsca in standby mode. Choose a different domain name for the standby. For example, if the primary WebLogic domain is GCDomain, choose GCDomainStby.
omsca standby –EM_DOMAIN_NAME GCDomainStby –NM_USER nodemanager -AS_USERNAME weblogic –nostart
When prompted for the Administration Server host and EM Instance host, enter the standby OMS hostname (or accept the default).
When prompted for the passwords, provide the same passwords as the primary site.
When prompted for Management Repository details, provide the primary database details.
Configure the required plug-ins by running the following command:
pluginca -action deploy -isFirstOMS true -plugins <plugin-list> -oracleHome <oms oracle home> -middlewareHome <wls middleware home>
where plugin-list is the list of plug-ins returned by the SQL query
SELECT epv.plugin_id, epv.version FROM em_plugin_version epv, em_current_deployed_plugin ecp WHERE epv.plugin_type NOT IN ( 'BUILT_IN_TARGET_TYPE' , 'INSTALL_HOME') AND ecp.dest_type='2' AND epv.plugin_version_id = ecp.plugin_version_id;
and is a comma separate list in the following format: <plugin-id>=<plugin-version>,<plugin-id>=<plugin-version>,…
Example: "oracle.sysman.empa=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.db=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0"
Copy over the configuration exported from the primary Management Service in step 2 above to the standby Management Service host. Import the exported configuration on the standby Management Service using:
emctl importconfig oms -file <full path of the export file>
Note this command emits a warning about a failed export and prompts for confirmation to proceed. The warning can be ignored by entering "y" to proceed.
Note this command will start the Management Service.
Stop the Management Service but leave the Administration Server running using:
emctl stop oms
Add the standby Weblogic Domain and associated targets:
The standby Weblogic Domain and associated targets can be added using the Guided Discovery process.
From the Setup menu, select Add Target , then select Add Targets Manually. Select Oracle Fusion Middleware from the Target Types menu. Use the secure port (typically 7101) and, under Advanced, set the JMX Protocol to t3s.
Note that the WebLogic targets, except the Administration Server, will be shown as down as the standby OMS is down at this stage.
If you have Single Sign On configured on the primary site, follow the same steps to configure SSO on the standby OMS.
If you have Real User Experience Insight, AD4J Manager or BI Publisher configured on the primary site, follow the same steps to configure them on the standby OMS.
Copy the emkey to the Management Repository by running the following command on the first OMS on the primary site:
emctl config emkey -copy_to_repos
Export the configuration from the first OMS on the primary site.
emctl exportconfig oms -dir <location for the export file>
After the configuration is exported, do not make any configuration changes to the primary site until the standby OMS is configured.
On the remote host, perform a software-only installation of the standby OMS as described in the Oracle® Enterprise Manager Cloud Control Advanced Installation and Configuration Guide chapter "Installing Enterprise Manager Software Now and Configuring Later" (Installing in Graphical Mode). Ensure that you install the software binaries in the same middleware location as that of the primary OMS.
Note:
Make sure you select same set of plug-ins as the primary OMS.If you have installed extra plug-ins which are not part of the installation, then complete the following steps.
Connect to repository and execute the following query to obtain the list of installed plug-ins:
SELECT epv.plugin_id, epv.version, epv.rev_version FROM em_plugin_version epv, em_current_deployed_plugin ecp WHERE epv.plugin_type NOT IN ('BUILT_IN_TARGET_TYPE', 'INSTALL_HOME') AND ecp.dest_type='2' AND epv.plugin_version_id = ecp.plugin_version_id
Write down the returned list of plug-ins installed.
Extract the plug-in archives from the primary site.
Go to the Self Update Home, click on Plug-ins, select the required plug-in and select export from the Action table menu. Note the EM CLI command from the popup that gets displayed.
emcli export_update -id=<update id> -host=<standby OMS host> -dir=<directory to export archives> <host credential options>
Note that this command generates a file with a .zip extension. Rename the file from <file_name>.zip to <file_name>.opar .
Repeat above steps for all plugins. In standby OMS host, place all .opar file in one directory <plugin dir >
Invoke runInstaller with an option specifying the location of downloaded plug-ins.
<DVD/Disk1/runInstaller -pluginLocation <plugin dir>
On the software-only installation, apply all the patches you applied on the primary OMS so that both the primary and standby OMSs are identical and are in sync.
Configure the OMS by running omsca in standby mode. Choose a different domain name for the standby. For example, if the primary WebLogic domain is GCDomain, choose GCDomainStby.
omsca standby -EM_DOMAIN_NAME GCDomainStby -NM_USER nodemanager -AS_USERNAME weblogic -nostart
When prompted for the Administration Server host and Enterprise Manager Instance host, enter the standby OMS hostname (or accept the default).
When prompted for the passwords, provide the same passwords as the primary site.
When prompted for Management Repository details, provide the primary database details.
Configure the required plug-ins by running the following command:
pluginca -action deploy -isFirstOMS true -plugins <plug-in list> -oracleHome <oms oracle home> -middlewareHome <wls middleware home>
where plug-in list is the list of plug-ins returned by the SQL query.
SELECT epv.plugin_id, epv.version FROM em_plugin_version epv, em_current_deployed_plugin ecp WHERE epv.plugin_type NOT IN ( 'BUILT_IN_TARGET_TYPE' , 'INSTALL_HOME') AND ecp.dest_type='2' AND epv.plugin_version_id = ecp.plugin_version_id;
The plug-in list must be a comma separate list in the following format:
<plugin-id>=<plugin-version>,<plugin-id>=<plugin-version>,…
Example:
"oracle.sysman.empa=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.db=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0"
Copy over the configuration exported from the primary OMS in step 2 above to the standby OMS host. Import the exported configuration on the standby OMS:
emctl importconfig oms -file <full path of the export file>
Note that this command generates a warning about a failed export and prompts for confirmation in order to proceed. The warning can be ignored by entering "y" to proceed.
This command will automatically start the OMS.
Stop the Management Service but leave the Administration Server running using:
emctl stop oms
Configure the Management Agent on the second OMS host by running the following command from the OMS home:
$<AGENT_HOME>/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<middleware_home>/agent OMS_HOST=<oms_host_name> EM_UPLOAD_PORT=<oms_port> AGENT_REGISTRATION_PASSWORD=<password> -configOnly
Note: If you have an SLB configured, then directly specify the host and port of the primary load balancer.If no SLB is configured, then use the secure upload port of primary OMS.
Example:
./agentDeploy.sh AGENT_BASE_DIR=$MIDDLEWARE_BASE/agent OMS_HOST=prim_oms_hhost.domain.com EM_UPLOAD_PORT=4900 AGENT_REGISTRATION_PASSWORD=password -configOnly
Deploy the required plug-ins on the Management Agent.
For information about deploying plug-ins, refer to the section Deploying and Updating Plug-ins in the Chapter 21, "Updating Cloud Control".
Add the standby WebLogic Domain and associated targets:
The standby WebLogic Domain and associated targets can be added using the Guided Discovery process.
From the Setup menu, select Add Target , then select Add Targets Manually. Select Oracle Fusion Middleware from the Target Types menu. Use the secure port (typically 7101) and, under Advanced, set the JMX Protocol to t3s.Note that the WebLogic targets, except the Administration Server, will be shown as "down" since the standby OMS is down at this stage.
If you have Single Sign-On configured on the primary site, follow the same steps to configure SSO on the standby OMS.
If you have Real User Experience Insight, AD4J Manager or BI Publisher configured on the primary site, follow the same steps to configure them on the standby OMS.
It is recommended that your standby site be similar in configuration as your primary site. This means configuring multiple OMS on your standby site, similar to your primary site. Install additional standby Management Services as per the procedure listed below under “Additional Standby Management Services”.
Start the standby Administration Server by running the following command on the first standby Management Service:
emctl start oms –admin_only
Export the configuration from the first Management Service on the primary site using:
emctl exportconfig oms -dir <location for the export file>
After the configuration is exported, do not make any configuration changes to the primary site still the standby management service is configured.
Install a Management Agent on the standby host.
Perform a software-only install of the Enterprise Manager software using a modified version of “Add Management Service” Deployment Procedure.
From the Enterprise menu, select Provisioning and Patching, then select Procedure Library.Select Add Management Service procedure and then click Create Like.Go to the Procedure Steps tab and select and disable the steps - “Configure Management Service”, “Targets Discovery” and “Post Configuration Tasks”.Save the modified deployment procedure and use it to install the Enterprise Manager software on the standby OMS host.After the Deployment Procedure completes, delete the file emInstanceMapping.properties from <OMS Oracle Home>/sysman/config on the standby OMS host.
Delete the emInstanceMapping.properties file from the following location
$ORACLE_HOME/sysman/config
Configure the Management Service by running omsca.
omsca add –nostart
When prompted for Management Repository details, provide the primary database details.When prompted for Administration Server details, provide the standby administration server details.
Configure the required plug-ins by running the following command:
pluginca -action deploy –isFirstOMS false -plugins <plugin-list> -oracleHome <oms oracle home> -middlewareHome <wls middleware home>
where plugin-list is the list of plug-ins returned by the SQL query above and is a comma separate list in the following format: <plugin-id>=<plugin-version>,<plugin-id>=<plugin-version>,…
Example "oracle.sysman.empa=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.db=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0"
Copy over the configuration exported from the primary Management Service in step 1 above to the standby Management Service host. Import the exported configuration on the standby Management Service using:
emctl importconfig oms -file <full path of the export file>
Note this command emits a warning about a failed export and prompts for confirmation to proceed. The warning can be ignored by entering "y" to proceed.
Note this command will start the Management Service.
Stop the Management Service using:
emctl stop oms
Refresh the standby domain target from the console. This will present a guided workflow to discover and add the new managed server and associated targets.
If you have Single Sign On configured on the primary site, follow the same steps to configure SSO on the standby OMS.
If you have Real User Experience Insight, AD4J Manager or BI Publisher configured on the primary site, follow the same steps to configure them on the standby OMS.
Start the standby Administration Server by running the following command on the first standby Management Service:
emctl start oms –admin_only
Export the configuration from the first Management Service on the primary site using:
emctl exportconfig oms -dir <location for the export file>
After the configuration is exported, do not make any configuration changes to the primary site still the standby management service is configured.
On the remote host, perform a software-only installation of the standby OMS as described in the Oracle® Enterprise Manager Cloud Control Advanced Installation and Configuration Guide chapter "Installing Enterprise Manager Software Now and Configuring Later" (Installing in Graphical Mode). Ensure that you install the software binaries in the same middleware location as that of the primary OMS.
Note:
Make sure you select same set of plug-ins as the primary OMS.If you have installed extra plug-ins which are not part of the installation, then complete the following steps.
Connect to repository and execute the following query to obtain the list of installed plug-ins:
SELECT epv.plugin_id, epv.version, epv.rev_version FROM em_plugin_version epv, em_current_deployed_plugin ecp WHERE epv.plugin_type NOT IN ('BUILT_IN_TARGET_TYPE', 'INSTALL_HOME') AND ecp.dest_type='2' AND epv.plugin_version_id = ecp.plugin_version_id
Write down the returned list of plug-ins installed.
Extract the plug-in archives from the primary site.
Go to the Self Update Home, click on Plug-ins, select the required plug-in and select export from the Action table menu. Note the EM CLI command from the popup that gets displayed.
emcli export_update -id=<update id> -host=<standby OMS host> -dir=<directory to export archives> <host credential options>
Note that this command generates a file with the .zip extension. Rename the file from <file_name>.zip to <file_name>.opar .Repeat above steps for all plugins. In standby OMS host, place all .opar file in one directory <plugin dir >
Invoke runInstaller with an option specifying the location of downloaded plug-ins.
<DVD/Disk1/runInstaller -pluginLocation <plugin dir>
On the software-only installation, apply all the patches you applied on the primary OMS so that both the primary and standby OMSs are identical and are in sync.
Configure the Management Service by running omsca.
omsca add –nostart
When prompted for Management Repository details, provide the primary database details. When prompted for Administration Server details, provide the standby Administration Server details.To keep the ports consistent with your primary site, provide all the ports on the command line itself. For example:
omsca add -MSPORT 7202 -MS_HTTPS_PORT 7301 -EM_NODEMGR_PORT 7403 -EM_UPLOAD_PORT 4889 -EM_UPLOAD_HTTPS_PORT 4900 -EM_CONSOLE_PORT 7788 -EM_CONSOLE_HTTPS_PORT 7799 -nostart
Configure the required plug-ins by running the following command:
pluginca -action deploy –isFirstOMS false -plugins <plugin-list> -oracleHome <oms oracle home> -middlewareHome <wls middleware home>
where the plugin-list is the list of plug-ins returned by the SQL query above and is a comma separated list in the following format: <plugin-id>=<plugin-version>,<plugin-id>=<plugin-version>,…
Example "oracle.sysman.empa=12.1.0.1.0,oracle.sysman.mos=12.1.0.1.0,oracle.sysman.emas=12.1.0.1.0,oracle.sysman.emfa=12.1.0.1.0,oracle.sysman.db=12.1.0.1.0,oracle.sysman.emct=12.1.0.1.0,oracle.sysman.vt=12.1.0.1.0,oracle.sysman.ssa=12.1.0.1.0"
Copy over the configuration exported from the primary Management Service in step 1 above to the standby Management Service host. Import the exported configuration on the standby Management Service using:
emctl importconfig oms -file <full path of the export file>
Note this command emits a warning about a failed export and prompts for confirmation to proceed. The warning can be ignored by entering "y" to proceed.
Note this command will automatically start the OMS.
Stop the OMS using:
emctl stop oms
Configure the Management Agent on the second OMS host by running the following command from the OMS home:
$<AGENT_HOME>/sysman/install/agentDeploy.sh AGENT_BASE_DIR=<middleware_home>/agent OMS_HOST=<second_oms_host_name>EM_UPLOAD_PORT=<second_oms_port> AGENT_REGISTRATION_PASSWORD=<password> -configOnly
Note: If you have an SLB configured, then directly specify the host and port of the primary load balancer.If no SLB is configured, then use secure upload port of primary OMS.
Deploy the required plug-ins on the Management Agent.
For information about deploying plug-ins, refer to the section Deploying and Updating Plug-ins in the Chapter 21, "Updating Cloud Control".
Refresh the standby domain target from the console. This will present a guided workflow to discover and add the new managed server and associated targets.
If you have Single Sign On configured on the primary site, follow the same steps to configure SSO on the standby OMS.
If you have Real User Experience Insight, AD4J Manager or BI Publisher configured on the primary site, follow the same steps to configure them on the standby OMS.
Update the standby SLB configuration by adding the standby Management Service(s) to the different pools on the SLB. Setup monitors for the new Management Service.
After the initial setup of the standby site, the standby site has to be kept in sync with the changes done on primary site. Transactions on the primary Management Repository get propagated to the Standby Management Repository automatically through Data Guard but the OMS side changes have to be redone manually on the standby site. The following sections describe this procedure for typical activities.
Applying patches
When patches are applied on the primary site Management Services, they have to be applied on the standby site Management Services too. Note that patches typically update the Oracle Homes (via the Opatch apply command) and optionally might require scripts to be run against the Management Repository. On the standby site, it is sufficient to update the Oracle Homes (via the opatch apply command) and skip the running of scripts on the Management Repository because database changes are automatically propagated to the standby site using Data Guard.
Managing Plug-ins
When new plug-ins are deployed on the primary site or existing plug-ins upgraded or un-deployed on the primary site, the following procedures needs to be run on the standby site too to keep the Standby Management Services in sync. Note if the Standby Management Services are not kept in sync, they would fail to start when a switchover or failover operation is attempted.
The procedure below assumes that the standby site was setup as per the documented process and the standby management services are currently down and point to the primary repository. The plug-in(s) deployment on the primary site has been completed successfully.
Deploying a New Plug-in or Upgrading a Plug-in on Standby Site
Extract the plug-in archives from the primary site
Go to the Self Update Home, click on Plug-ins, select the required plug-in and select export from the Action table menu. Note the EM CLI command from the popup that gets displayed.
emcli export_update -id=<update id> -deep -host=<standby OMS host> -dir=<directory to export archives> <host credential options>
Note that an additional option “-deep” is required. This command would create 4 files on the destination directory specified. The filename <version>_OMS_<platform>_<revision>.zip is the one to be used in next step.
Start the Standby Administration Server, if it is down.
emctl start oms -admin_only
Install the OMS archive to First Standby OMS Oracle Home
pluginia –archives <path to plugin archive>
Configure the Plug-in on First Standby OMS Oracle Home
pluginca -action deploy -isFirstOMS true -plugins <plugin-list> -oracleHome <oms oracle home> -middlewareHome <wls middleware home>
where <plugin-list> is the plug-in name in the format <plugin-id>=<plugin-version>
Repeat steps 3 and 4 for each Standby additional OMS
pluginia –archives <path to plugin archive>
pluginca -action deploy -isFirstOMS false -plugins <plugin-list> -oracleHome <oms oracle home> -middlewareHome <wls middleware home>
This completes the plugin deployment on Standby site.
Sync up Sysman Credentials
When administrators modify sysman credentials on the primary site, the following procedure must be run on the standby site in order to keep the standby management service in sync with respect to sysman credentials.
If the sysman credentials for the primary and standby sites are not kept in sync, they will fail to start when switchover or failover opertations are attempted. In addition, the administratator will not be able to log into the standby OMS once the switchover operation is complete.
The procedure below assumes that the standby site was set up according to the documented process and the standby management services are currently down and point to the primary repository. The plug-in(s) deployment on the primary site has been completed successfully.
Perform following steps on standby management service
Start the standby Administration Server, if it is down
emctl start oms –admin_only
Change password for the sysman user. You must also provide the SYS password.
emctl config oms -change_repos_pwd -use_sys_pwd -sys_pwd <sys_pwd>
Stop the standby Administration Server,
emctl stop oms –all
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|