Managing Oracle Enterprise Manager Cloud Control 12c with Oracle Clusterware

Editor's Notes

• #5: Each component within the Enterprise Manager architecture should be made highly available to enable a complete High Availability configuration. The main components to be considered are (see Figure 13-1): Enterprise Manager Agent - Communicates with and sends metrics to the OMS Management Server - the heart of the Enterprise Manager Repository -Stores persistent data from the monitored targets. Software library - Stores files for patching, provisioning and agent and plug-in deployment
• #6: Different levels of high availability can be configured for each component with varying levels of complexity and cost. When considering your high availability requirements, there should be minimal trade-offs in cost, complexity, performance and data loss. Generally, the complexity and level of high availability are proportional to each other.
• #7: Also called a cold-failover cluster (CFC) In order to reduce OMS downtime during planned or unplanned outage, some redundancy should be introduced into the configuration. A level 2 configuration uses a shared filesystem for the management service to achieve an active/passive or cold failover cluster solution. The filesystem is shared between two or more hosts and is only active on one host at a time. The shared filesystem for the OMS can be installed on a general-purpose cluster file system including NFS, Oracle Cluster File System (OCFS2), and Oracle Automatic Storage Management (ASM) Cluster File System (ACFS). If NFS is used as the shared storage, then ensure the correct mount options are set in /etc/fstab (/etc/filesystems on AIX) to prevent potential I/O issues. Specifically, the rsize and wsize should be set. The example below shows and entry in the /etc/fstab file on a Linux server where the NFS share is mounted on a filer named filer1 under the /vol1/oms_share directory. filer:/vol1/oms_share /u01/app/oms_share nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noac,vers=3,timeo=600 0 0 Binaries for the OMS along with the inventory should be installed on the shared filesystem. Setup the virtual hostname and IP address (VIP) using Oracle Clusterware or third-party software and hardware. Failover is achieved by using the virtual hostname for the OMS along with a unique IP address which resolves to the hostname.
• #8: Also called a cold-failover cluster (CFC) In order to reduce OMS downtime during planned or unplanned outage, some redundancy should be introduced into the configuration. A level 2 configuration uses a shared filesystem for the management service to achieve an active/passive or cold failover cluster solution. The filesystem is shared between two or more hosts and is only active on one host at a time. The shared filesystem for the OMS can be installed on a general-purpose cluster file system including NFS, Oracle Cluster File System (OCFS2), and Oracle Automatic Storage Management (ASM) Cluster File System (ACFS). If NFS is used as the shared storage, then ensure the correct mount options are set in /etc/fstab (/etc/filesystems on AIX) to prevent potential I/O issues. Specifically, the rsize and wsize should be set. The example below shows and entry in the /etc/fstab file on a Linux server where the NFS share is mounted on a filer named filer1 under the /vol1/oms_share directory. filer:/vol1/oms_share /u01/app/oms_share nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noac,vers=3,timeo=600 0 0 Binaries for the OMS along with the inventory should be installed on the shared filesystem. Setup the virtual hostname and IP address (VIP) using Oracle Clusterware or third-party software and hardware. Failover is achieved by using the virtual hostname for the OMS along with a unique IP address which resolves to the hostname.
• #9: Also called a cold-failover cluster (CFC) In order to reduce OMS downtime during planned or unplanned outage, some redundancy should be introduced into the configuration. A level 2 configuration uses a shared filesystem for the management service to achieve an active/passive or cold failover cluster solution. The filesystem is shared between two or more hosts and is only active on one host at a time. The shared filesystem for the OMS can be installed on a general-purpose cluster file system including NFS, Oracle Cluster File System (OCFS2), and Oracle Automatic Storage Management (ASM) Cluster File System (ACFS). If NFS is used as the shared storage, then ensure the correct mount options are set in /etc/fstab (/etc/filesystems on AIX) to prevent potential I/O issues. Specifically, the rsize and wsize should be set. The example below shows and entry in the /etc/fstab file on a Linux server where the NFS share is mounted on a filer named filer1 under the /vol1/oms_share directory. filer:/vol1/oms_share /u01/app/oms_share nfs rw,bg,rsize=32768,wsize=32768,hard,nointr,tcp,noac,vers=3,timeo=600 0 0 Binaries for the OMS along with the inventory should be installed on the shared filesystem. Failover is achieved by using the virtual hostname for the OMS along with a unique IP address which resolves to the hostname.
• #10: It’s recommended to use the appvipcfg utility in Oracle Clusterware 11gR2 to create application VIPs. The VIP is created with a set of pre-defined settings suitable for an application VIP such placement policy and the failback option. The default value of the failback is set to 0, which means that the VIP and its dependent resources will not automatically fail back to the original node once it becomes available again. VIP can be created on the non-default network (default ora.net1.network) Non-default network should be created with srvctl add network command
• #11: A VIP can be created in the same was any other Clusterware resource. However, it is recommended to use the appvipcfg utility in Oracle Clusterware 11gR2 to create application VIPs. The VIP is created with a set of pre-defined settings suitable for an application VIP such placement policy and the failback option. The default value of the failback is set to 0, which means that the VIP and its dependent resources will not automatically fail back to the original node once it becomes available again.
• #12: The   virtual hostname is defined in DNS, and should resolve to the application VIP address created using the steps above. Check if the virtual hostname and VIP are resolvable using nslookup or the dig command. $ nslookup omsvip This should resolve to a unique IP address of the virtual hostname on every node in the cluster. Also do a reverse lookup of the IP address. $nslookup <virtual IP address> Verify that the IP address returned from the nslookup output is running on the OMS host. ifconfig –a|grep <virtual IP address>
• #13: Install the OMS on the first host by following the installation steps as described in the Oracle Enterprise Manager Cloud Control 12c Basic Installation Guide. You only need to complete the installation once. Since the location is shared, the binaries will be accessible from another host that shares the filesystem.
• #14: The ORACLE_HOSTNAME should be also set when starting the OEM on each node in the cluster. This should be the same as the Virtual Hostname defined in DNS for the VIP.
• #15: Once the OMS has been successfully installed and is up and running, if the host were to go down then the VIP will be automatically relocated to another node. The management service can then be manually started on any remaining node in the cluster on which the VIP is running.
• #16: Oracle Clusterware can be configured to fully manage the OMS by creating start, check, stop, clean and abort routines that tell it how to operate on the OMS.
• #17: You must decide whether to use administrator or policy management for the application. Use administrator management for smaller, two-node configurations, where your cluster configuration is not likely to change. Use policy management for more dynamic configurations when your cluster consists of more than two nodes. For example, if a resource only runs on node 1 and node 2 because only those nodes have the necessary files, then administrator management is probably more appropriate. An action script is a shell script (a batch script in Windows) that a generic script agent provided by Oracle Clusterware calls. An application-specific agent is usually a C or C++ program that calls Oracle Clusterware-provided APIs directly.
• #18: To add the OEM server as a resource that uses a named server deployment, assume that you add the resource to a server pool that is, by definition, a sub-pool of the Generic server pool. You create server pools that are sub-pools of Generic using the crsctl add serverpool command. These server pools define the Generic server pool as their parent in the server pool attribute PARENT_POOLS. In addition, they include a list of server names in the SERVER_NAMES parameter to specify the servers that should be assigned to the respective pool.
• #19: generic_application cluster type can model any application requiring high availability without specifying action scripts
• #25: If you like what you heard today, you should come see me speak at COLLABORATE 14 – IOUG Forum 1,000 customer sessions, very similar to what you see on User Group Sunday at OpenWorld Includes complimentary hands on labs and pre-conference workshops for IOUG attendees COLLABORATE 14 is April 7-11 in Las Vegas!
• #26: IOUG Master Class brings the best content from COLLABORATE 13 to a city near you Use these one-day training events to train your entire team at an affordable price! Group discounts available, visit the IOUG kiosk for more information
• #27: Visit IOUG in the User Group Pavilion, on the 2 nd floor of Moscone West to pick up your poker chip and win a prize Don’t forget to drop off your speaker card from this session to help me win a prize!