24 Enterprise Manager High Availability
This chapter discusses best practices for installation and configuration of each Enterprise Manager component and covers the following topics:
Agent High Availability
The following sections discuss best practices for installation and configuration of the Management Agent.
Configuring the Management Agent to Automatically Start on Boot and Restart on Failure
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.
Configuring Restart for the Management Agent
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.
Installing the Management Agent Software on Redundant Storage
The Management Agent persists its configuration, intermediate state and collected information using local files in the Agent State 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 the Agent State Directory on redundant storage. The Agent State Directory can be determined by entering the command '$AGENT_HOME/agent_inst/bin/emctl getemhome', or from the Agent Homepage in the Enterprise Manager Console.
Repository High Availability
The following sections document best practices for repository configuration.
General Best Practice for Repository High Availability
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.
-
Choose Automatic Storage Management (ASM) as the underlying storage technology.
-
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
Use the MAA Advisor for additional high availability recommendations that should be applied to the Management Repository. MAA Advisor can be accessed by selecting Availability > MAA Advisor from the Homepage of the Repository Database.
See Overview of High Availability for more information on these and other best practices to ensure the database that hosts the Management Repository is configured to provide required availability.
Configuring RAC for the Management Repository
If the Management Repository is a Real Application Cluster (RAC) database, the Management Services should be configured with the appropriate connect strings. SCAN connect strings are recommended to avoid reconfiguration of the Repository connect descriptor following addition or removal of nodes in the Repository tier. SERVICE_NAME should always be used in connect strings instead of SID_NAME
Refer to the Oracle Database Net Services Administrator's Guide for details.
The following example shows a connect string for Repository
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=primary-cluster-scan.example.com)(PORT=1521)) (CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=PDB.example.com)))
The Repository connect descriptor is configured by running the emctl command from Management Service. If you have multiple Management Services configured, this command must be run on each 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 updating the Repository connect descriptor, 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 descriptor as above>
Oracle Management Service High Availability
The following sections document configuring the OMS for high availability.
OMS high availability begins with ensuring there is at least one OMS available at any given time. Depending upon your Recovery Time Objective (RTO), this can be accomplished without downtime from loss of a node in an active/active configuration by adding at least one additional OMS, or with limited downtime from loss of a node in an active/passive configuration by ensuring that the OMS can be run with the same address on a different server if the primary server fails. See High Availability Solutions for more details on architectural options for achieving high availability.
Regardless of the manner selected to provide high availability, and the level of availability selected for initial installation, there are a number of steps that can be taken to best prepare the environment for a future move to higher levels of availability including disaster recovery. See "Best Practices for Configuring the Enterprise Manager OMS to be Compatible with Disaster Recovery using Alias Host Names and Storage Replication" for details on these steps.
To ensure OMS high availability, there also must be a sufficient number of OMSs to support the size and scope of the environment managed by Enterprise Manager as well as the scale and complexity of the usage of Enterprise Manager including the number of administrators and the breadth of capability employed.
Once an environment requires more than one active OMS, whether to ensure sufficient capacity for the environment or to prevent the downtime associated with failover to a passive OMS, a Server Load Balancer (SLB) is required. A SLB provides a single address for Management Agents and administrators to communicate with the set of OMS servers, monitors the OMSs to know which OMSs are available, and routes the communication to an available OMS.
It can be expensive to implement a SLB. If the environment does not need more than one OMS to handle the processing requirements, and if the minutes of downtime associated with an active/passive failover of the OMS meets RTO requirements, a SLB is not required to provide high availability. The instructions in "Configuring the Enterprise Manager OMS in an Active/Passive Environment for HA Failover Using Virtual Host Names" provide an example of how to configure for high availability using a virtual IP address and shared storage.
If you need to add one or more additional OMSs to support your RTO and/or the processing needs of the environment, see "Installing Additional Management Services". Once you've added additional OMS(s), see "Configuring Multiple Management Services Behind a Server Load Balancer (SLB)" for information on how to configure multiple OMSs behind a SLB.
Best Practices for Configuring the Enterprise Manager OMS to be Compatible with Disaster Recovery using Alias Host Names and Storage Replication
This section provides best practices for Enterprise Manager administrators who want to install the Enterprise Manager OMS in a manner that will ensure compatibility with Disaster Recovery using Alias Host Names and Storage Replication. This will reduce the steps required to implement a Disaster Recovery configuration should it be required at a future date. These best practices are applicable for every MAA high availability level installation. Installing even a standalone OMS in a manner that considers the needs of the highest MAA high availability level will provide the greatest flexibility and easiest migration to higher MAA high availability levels in the future.
Overview and Requirements
The following installation conditions must be met in order for a Enterprise Manager OMS installation to support Disaster Recovery using alias host names and storage replication:
-
The Middleware Home, OMS Instance Base, Agent Base, and Oracle Inventory directories must be installed on storage that can be replicated to the standby site.
-
The installation of the OMS must be performed in a manner that maintains an Alias Host Name that is the same for the primary and standby site hosts for the OMS. This Alias Host Name allows the software to be configured such that the same binaries and configuration can be used either on the OMS host at the primary or standby site without changes.
-
The Middleware Home, OMS Instance Base, and Agent Base must be installed using the Oracle Inventory location on the storage that can be replicated to the standby site.
-
The software owner and time zone parameters must be the same on all nodes that will host this Oracle Management Service (OMS).
-
The path to the Middleware, Instance, OMS Agent, and Oracle Inventory directories must be the same on all nodes that will host this OMS.
Create an OMS installation base directory under ORACLE_BASE
To support disaster recovery, the Middleware Home, OMS Instance Base, Agent Base, and Oracle Inventory directories must be installed on storage that can be replicated to the standby site. Each of these directories is traditionally located directly underneath ORACLE_BASE. Once an OMS is installed, its directory path cannot be changed. Transitioning an installation with each of these directories located directly underneath ORACLE_BASE to replicated storage later can add complications such as requiring the ORACLE_BASE to be relocated to replicated storage to maintain the original directory paths for the installed software, which would require any locally installed software under that path to be uninstalled and reinstalled in an alternate local storage directory.
To provide the greatest flexibility for future storage migrations, create a directory under ORACLE_BASE that will be the base directory for all OMS software, including the Middleware Home, OMS Instance Base, Agent Base, and Oracle Inventory directories. For example, if the ORACLE_BASE is /u01/app/oracle, create a new OMS installation base directory, such as /u01/app/oracle/OMS. This directory will serve as the mount point for the replicated storage. If the software is installed locally under this directory, this directory can become a single mount point to the replicated storage enabling a simple migration. When providing and reviewing directory locations while installing the OMS, ensure the Middleware Home, OMS Instance Base, Agent Base, and Oracle Inventory are installed under this directory.
Configure an Alias Host Name
To support disaster recovery, a host at the primary site and a host at the standby site must be capable of running with the same host name used in the OMS installation. This can be accomplished using an alias host name.
Configure an alias host name to use in the installation using the guidance in "Planning Host Names." Option 2: Alias host names on both sites in this section provides the greatest flexibility and is recommended as a best practice for new installations.
To implement Option 2, specify the alias host name when installing the OMS, either by using the ORACLE_HOSTNAME=<ALIAS_HOST_NAME> parameter or by specifying the alias host name in the Host Name field in the OUI installation. For example, include the following parameter on the installation wizard command line:
ORACLE_HOSTNAME=oms1.example.com
Configure an Oracle Inventory located under OMS installation base directory
To support disaster recovery, a single OMS installation is shared by a host at the primary site and a host at the standby site using replicated storage. Only the active OMS mounts the replicated storage. Software maintenance activities may need to be performed when either the primary or standby site is the active site. As such, it is important to ensure that the Oracle Inventory containing the details of the installation is available from either location.
To prevent the need to perform manual migration activities to move the OMS installation from a local Oracle Inventory to a replicated storage Oracle Inventory, create the Oracle Inventory under the OMS installation base directory.
Use the following steps to prepare the installer to set up an inventory located under the OMS installation base directory:
Specify the Oracle Inventory under the OMS installation base directory when installing the OMS by providing the -invPtrloc <oraInst.loc file with path> parameter on the installation wizard command line, for example:
-invPtrloc /u01/app/oracle/OMS/oraInventory/oraInst.loc
The installer will create the inventory in the specified location. Use this inventory for all installation, patching, and upgrade activities for this OMS and OMS agent.
Configure a Software Owner and Group that can be configured identically on all nodes
Just as the OMSs at the primary site are installed using the same software owner and group, to support disaster recovery, the software owner and group need to be configured identically on the standby site OMS hosts. Ensure that both the owner name and ID and the group name and ID selected for use at the primary site will also be available for use at the standby site.
Verification that the user and group of the software owner are configured identically on all OMS nodes can be performed using the 'id' command as in the example below:
$ id -a
uid=550(oracle) gid=50(oinstall) groups=501(dba)
Select a time zone that can be configured identically on all nodes
Just as the OMSs at the primary site are installed using the same time zone, to support disaster recovery, the time zone should be configured identically on the standby site OMS hosts. Select a time zone that can be used at both sites and ensure that the time zone is the same on all OMS hosts.
Installation and Configuration
The following are high level installation steps that reinforce the best practices listed in this section. Reference the detailed instructions in the Enterprise Manager Basic Installation Guide for details on the installation steps, including required pre-requisites and additional post installation operations.
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:
nas.example.com:/export/share1 /u01/app/oracle/OMS nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noacl,vers=3,timeo=600 0 0
Note:
Review the NFS Mount Point Location Requirements for additional important NFS-related requirements. See Prerequisites for Installing an Enterprise Manager System in the Oracle Enterprise Manager Basic Installation Guide.
Refer to the following steps when installing the software:
-
Create an OMS installation base directory under ORACLE_BASE. If installing on replicated storage now, ensure that the replicated storage is mounted to this directory.
-
Configure the Alias Host Names for all OMSs being installed on each of the OMS hosts.
-
Configure a Software Owner and Group that will be consistently defined on all OMS hosts.
-
Configure the time zone that will be consistently set on all OMS hosts.
-
Follow the detailed preparation and installation instructions in Installing Oracle Enterprise Manager" in the Enterprise Manager Basic Installation Guide, specifying the following information as part of the installation process:
-
Ensure that the Middleware Home, OMS Instance Base, and Agent Base are located under the OMS installation base directory.
-
Specify the inventory location file and the Alias Host Name of the OMS. These can be specified on the command line as in the following example:
$ <Software_Location>/em_<platform>.bin -invPtrloc /u01/app/oracle/OMS/oraInventory/oraInst.loc ORACLE_HOSTNAME=oms1.example.com
You can also provide the ORACLE_HOSTNAME when prompted for this information from within the Enterprise Manager installation wizard UI.
-
-
Continue the remainder of the installation.
Configuring the Enterprise Manager OMS in an Active/Passive Environment for HA Failover Using Virtual Host Names
This section provides a general reference for Enterprise Manager administrators who want to configure Enterprise Manager in Cold Failover Cluster (CFC) environments.
Overview and Requirements
The following conditions must be met for Enterprise Manager 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).
Installation and Configuration
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:
nas.example.com:/export/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.
Setting Up the Virtual Host Name/Virtual IP Address
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.
Setting Up Shared Storage
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 supported.
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.
Setting Up the Environment
Some operating system versions require specific operating system patches be applied prior to installing Enterprise Manager 24ai. The user installing and using the Enterprise Manager 24ai 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
Synchronizing Operating System IDs
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)
Starting Up Services
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 Enterprise Manager using
emctl start oms
- Test functionality.
In case of failover, refer to Performing Switchover and Failover Operations.
Installing Additional Management Services
There are two ways to install additional Management Services:
-
Using the Add Oracle Management Service Deployment Procedure (preferred method). For more information about using this Deployment Procedure, see Adding Additional Oracle Management Services in the Oracle Enterprise Manager Basic Installation Guide.
-
Installing Additional Oracle Management Service in Silent Mode (alternative method). For more information about silent mode installation, see the chapter on Installing Additional OMSs in Silent Mode in the Oracle Enterprise Manager Advanced Installation and Configuration Guide.
Configuring Multiple Management Services Behind a Server Load Balancer (SLB)
The following sections discuss how to configure the OMS for high availability in an Active/Active configuration using a Server Load Balancer.
Configuring the Software Library
The Software Library location must be accessible by all active Management Services. If the Software Library is not configured during installation, it 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.
- On the Software Library: Administration page, select OMS Shared File system.
- To add a new OMS Shared File System, click +Add.
- In the Add OMS Shared File System location dialog box, provide a unique name for the location and set the location to the shared storage that can be accessed by any Management Service hosts.
Configuring a Load Balancer
This section describes the guidelines for setting up a Server Load Balancer (SLB) to distribute the Agent and Browser traffic to available 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 have configured public-facing ports that provide access to the various services provided by the OMS’s that are part of the SLB load balancer configuration.
Depending on your configuration, you may require up to 4 ports on the SLB (Secure Upload, Agent Registration, Secure Console, Unsecure Console)
-
Support for persistence.
HTTP and HTTPS traffic between the user-interactive browser and the OMS requires persistence settings to ensure that navigation between OMS pages occur to the same pool member throughout the interactive session.
-
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.
- Understand the SSL configuration for your SLB environment.
The following are the SSL configurations available:
-
Layer 3 Load Balancing: The load balancer tunnels incoming SSL connections to your OMS servers on the back end. This SSL configuration is also known as SSL Tunneling.
-
SSL Proxy: The load balancer terminates the client SSL connection and acts as a proxy to initiate an SSL connection to the backend OMS servers. This permits the Load Balancer to utilize Layer 7 inspection which enables modifications to the session, such as applying rules, perform virtual server authentication, or cookie/session persistence. This SSL configuration is also known as SSL End-To-End.
-
SSL Termination: The client browser session to the Load Balancer is encrypted using SSL, decrypted at the Load Balancer, then the traffic is sent unencrypted to the back end OMS. This SSL configuration is not supported for OMS.
-
SLB configuration is a two-step process:
- Configure the SLB.
- Make requisite changes on the Management Services.
SLB Side Setup
Use the following table as reference for setting up the SLB with Enterprise Manager Management Services.
Various configuration items listed in the below table will be described in subsequent sections of this document.
Table 24-1 Management Service Ports
Enterprise Manager Service | OMS TCP Port | Monitor Name | TCP Profile Name | Persistence Profile | Pool Name | Virtual Server Name | SLB Virtual Server Port |
---|---|---|---|---|---|---|---|
Secure Console |
7799 |
mon_ccsc |
tcp_ccsc |
sourceip_ccsc |
pool_ccsc |
vs_ccsc443 |
443 |
Unsecure Console |
7788 |
mon_ccuc |
tcp_ccuc |
sourceip_ccuc |
pool_ccuc |
vs_ccuc80 |
80 |
Secure Upload |
4900 |
mon_ccsu |
tcp_ccsu |
None |
pool_ccsu |
vs_ccsu4900 |
4900 |
Agent Registration |
4889 |
mon_ccar |
tcp_ccar |
cookie_ccar |
pool_ccar |
vs_ccar4889 |
4889 |
Always-On Monitoring Secure Upload |
8081 |
mon_ccaom |
tcp_ccaom |
None |
pool_ccaom |
vs_ccaom8081 |
8081 |
Secure JVMD |
7301 |
mon_ccsjvmd |
tcp_ccsjvmd |
sourceip_ccsjvmd |
pool_ccsjvmd |
vs_ccsjvmd7301 |
7301 |
Unsecure JVMD |
7202 |
mon_ccujvmd |
tcp_ccujvmd |
sourceip_ccujvmd |
pool_ccujvmd |
vs_ccujvmd7202 |
7202 |
Cipher profiles are used to define the security, compatibility and speed of the HTTPS traffic. Ciphers are supported by Enterprise Manager and they are used by the SLB administrator to determine which ciphers may be used or which must be excluded to connect to the Enterprise Manager.
Note:
If the Always-On Monitoring service is installed on a host other than the OMS host in the HA configuration, you need to specify the host on which the Always-On Monitoring service is installed instead of the OMS host-
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 24-2 Monitors
Enterprise Manager Service OMS TCP Port Monitor Name Type Interval Timeout Send String Receive String Secure Console (when not using SSL)
7799
mon_ccsc
HTTPS
5
16
GET /em/consoleStatus.jsp HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close
Enterprise Manager Console is UP
Unsecure Console (when not using SSL)
7788
mon_ccuc
HTTP
5
16
GET /em/consoleStatus.jsp HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close
Enterprise Manager Console is UP
Secure Upload
4900
mon_ccsu
HTTPS
60
181
GET /empbs/upload HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close
Http Receiver Servlet active!
Agent Registration
4889
mon_ccar
HTTP
60
181
GET /empbs/genwallet HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close
GenWallet Servlet activated
Always-On Monitoring Secure Upload
8081
mon_ccaom
HTTPS
60
181
GET /upload HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close
Always On Monitoring is active
Secure JVMD
7301
mon_ccsjvmd
HTTPS
60
181
GET /jamservlet/comm HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close
Reply to empty request
Unsecure JVMD
7202
mon_ccujvmd
HTTPS
60
181
GET /jamservlet/comm HTTP/1.1\r\nHost: slb.example.com\r\nConnection: Close
Reply to empty request
Note:
Some Load Balancers require <CR><LF> characters to be added explicitly to the Send String using literal "\r\n". This is vendor-specific. Refer to your SLB documentation for details.
-
Create Pools
A pool is a set of servers configured behind the Load Balancer and grouped together to receive traffic over a specific TCP port for each OMS service.
Load balancing methods vary depending on the SLB vendor; with several of most common methods being round-robin, least connection, and source-IP hashing. Refer to your specific SLB documentation for available methods and to determine the most suitable for your SLB and operating environment.
Each pool can have its own unique characteristic for a persistence definition and the load-balancing algorithm used.
Table 24-3 Pools
Enterprise Manager Services Pool Name Associated Health Monitor Load Balancing OMS Host:OMS Service Port Secure Console
pool_ccsc
mon_ccsc
Least Connections (member)
OMS Host A:7799
OMS Host B:7799
Unsecure Console
pool_ccuc
mon_ccuc
Least Connections (member)
OMS Host A:7788
OMS Host B:7788
Secure Upload
pool_ccsu
mon_ccsu
Least Connections (member)
OMS Host A:4900
OMS Host B:4900
Agent Registration
pool_ccar
mon_ccar
Least Connections (member)
OMS Host A:4889
OMS Host B:4889
Always-On Monitoring Secure Upload
pool_ccaom
mon_ccaom
Least Connections (member)
OMS Host A:8081
OMS Host B:8081
Secure JVMD pool_ccsjvmd mon_ccsjvmd Least Connections (member) OMS Host A:7301
OMS Host B:7301
Unsecure JVMD
pool_ccujvmd
mon_ccujvmd
Least Connections (member) OMS Host A:7202
OMS Host B:7202
-
Create TCP Profiles
TCP profiles are collections of TCP settings that are configurable settings for controlling the behavior of a particular type (e.g. TCP, HTTP) of network traffic. These profiles enhance control over network traffic and allow the user to control different characteristics for specific clients or applications (e.g. differing browsers).
Separate TCP profiles can then be associated with different services or virtual servers as required for your operating environment.
TCP profile values can have serious impacts on the network performance and should be used carefully and with careful consideration of your network and operational requirements.
TCP profile settings are site and SLB-specific therefore there are no specific OMS requirements for TCP profile settings. Refer to your SLB documentation and network administrator for required TCP profile configuration settings.
Table 24-4 TCP Profiles
Enterprise Manager Service TCP Profile Name Secure Console
tcp_ccsc
Unsecure Console
tcp_ccuc
Secure Upload
tcp_ccsu
Agent Registration
tcp_ccar
Always-On Monitoring Secure Upload
tcp_ccaom
Secure JVMD tcp_ccsjvmd Unsecure JVMD tcp_ccujvmd -
Create Persistence Profiles
Certain types of applications may require the same client returning to the same pool member, this is called persistence or “stickiness". It can be configured using a persistence profile, and applied to the virtual server. For Oracle Enterprise Manager services, persistence needs to be configured for every service, except for the Secure Upload service.
Some products offer session persistence support without cookies. These products depend on the IP address of the incoming request. In some circumstances, the originating IP address can change, resulting in session persistence being lost or the request redirected to the wrong backend server. If these cases occur, the service would be better defined to use cookies for persistence instead of source address affinity. Cookie persistence is only applicable when implementing SSL proxying architecture. For Layer 3 Load Balancing (formerly known as SSL Tunneling) the only Persistence Type alternative is Source Address Affinity.
Table 24-5 Persistence Profiles
Enterprise Manager Service Persistence Profile Name Type Timeout Expiration Secure Console
sourceip_ccsc
Source Address Affinity or Cookie
3600
Not Applicable
Unsecure Console
sourceip_ccuc
Source Address Affinity or Cookie
3600
Not Applicable
Agent Registration
cookie_ccar
Cookie
Not Applicable
3600
Secure JVMD
sourceip_ccsjvmd
Source Address Affinity
3600
Not Applicable
Unsecure JVMD
sourceip_ccujvmd
Source Address Affinity or Cookie
3600
Not Applicable
-
Create Rules
Rules are scripts that run against network traffic passing through your load balancer device. Rules give you the ability to influence network traffic in a variety of ways according to your functional needs.
Some of the following are types of rules that may be configured, depending on your local Load Balancer:- Access control rules which provide access to application resources based upon the source of the request.
- Access method rules which specify the permitted HTTP methods.
- URL redirect rules which route incoming HTTP requests to a different destination URL.
- Request and response header rules which add, alter or remove HTTP request or response headers.
- HTTP header rules which specify the size of the HTTP header and whether period and underscore characters are permitted within the headers.
Rule capabilities and rule definition syntax vary according to your Load Balancer vendor. Refer to the vendor documentation for information about these capabilities and syntactic guidance.
In the examples provided within this document, our virtual servers for Unsecure Console and Unsecure BI Publisher use notional rules for the purpose of redirecting requests to the Unsecure Console service (port 80) and Unsecure BI Publisher (port 8080) and sending them to the secure Console Service (port 443) and Secure BI Publisher (Port 5443) on the Load Balancer.
-
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.
Table 24-6 Required Virtual Servers
Enterprise Manager Service Virtual Server Name Virtual IP and Port Protocol Profile (Client) Rule Name Defaut Pool Default Persistence Profile Secure Console
vs_ccsc443
VIP:443
tcp_ccsc
None
pool_ccsc
sourceip_ccsc
Unsecure Console *
vs_ccuc80
VIP:80
tcp_ccuc
ccuc_httptohttps
pool_ccuc
sourceip_ccuc
Secure Upload
vs_ccsu4900
VIP:4900
tcp_ccsu
None
pool_ccsu
None
Agent Registration
vs_ccar4889
VIP:4889
tcp_ccar
None
pool_ccar
cookie_ccar
Always-On Monitoring Secure Upload
vs_ccaom8081
VIP:8081
tcp_ccaom
None
pool_ccaom
sourceip_aom
Secure JVMD
vs_ccsjvmd7301
VIP:7301
tcp_ccsjvmd
None
pool_ccsjvmd
sourceip_ccsjvmd
Unsecure JVMD
vs_ccujvmd7202
VIP:7202
tcp_ccujvmd
None
pool_ccujvmd
sourceip_ccujvmd
* These entries are not considered best practice and are not recommended as they provide unsecured and unencrypted access to Enterprise Manager.
Configuring SSL on Enterprise Manager and the SLB
If the SLB is configured to use Third-Party/Custom SSL certificates, you must ensure that the CA certificates are properly configured in order for the trust relationship to be maintained between the Agent, SLB, and the OMS. Specifically, the following must be carried out:
-
Import the CA certificates of the SLB into the OMS trust store.
-
Copy the Enterprise Manager CA certificates to the trust store of the SLB
Enterprise Manager uses the default Enterprise Manager certificates and not the custom certificates. In order for Agents to upload information successfully to the OMS through the SLB, these custom trusted certificates need to be copied/imported to the trust store of the OMS and Agents. The following procedures illustrate the process used to secure the OMS and Agent when an SLB is configured with Third Party/Custom SSL certificates.
Verifying the SSL Certificate used at the SLB
Perform the following steps to determine whether the SLB is using different certificates than the OMS:
-
To check the certificate chain used by any URL, run the following command:
<OMS_HOME>/bin/emctl secdiag openurl -url <HTTPS URL>
To check the certificates used by the SLB URL, run the following command:
<OMS_HOME>/bin/emctl secdiag openurl -url https://<SLB Hostname>:<HTTPS Upload port>/empbs/upload
To check the certificates used by the OMS URL, run the following command:
<OMS_HOME>/bin/emctl secdiag openurl -url https://<OMS Hostname>:<HTTPS Upload port>/empbs/upload
-
If the default Enterprise Manager self-signed certificates are used in the SLB, the output of both the commands will appear as follows:
Issuer : CN=<OMS Hostname>, C=US, ST=CA, L=EnterpriseManager on <OMS Hostname>, OU=EnterpriseManager on <OMS Hostname>, O=EnterpriseManager on <OMS Hostname>
-
If a custom or self-signed SSL certificate is used in the SLB, then output of the command executed with the SLB Name will provide details shown here:
Issuer : CN=Entrust Certification Authority - L1C, OU="(c) 2024 Entrust, Inc.", OU=www.entrust.net/rpa is incorporated by reference, O="Entrust, Inc.", C=US
In this example, the SLB is using the custom certificate (CN=Entrust Certification Authority - L1C, OU="(c) 2024 Entrust, Inc."), which needs to be imported as trusted certificate into the OMS.
-
If OpenSSL is available on the OS, you can also check the value of CN by running the following command:
openssl s_client -connect <HOSTNAME>:<PORT>
Importing the SSL Certificate of the SLB to the Trust Store of the OMS and Agent
For more information about configuring multiple OMS High Availability behind a SLB,
refer to Oracle Maximum Availability Architecture Best Practices
for Enterprise Manager
.