|
Oracle® Process Manager and Notification Server Administrator's Guide
10g Release 3 (10.1.3) B15976-01 |
|
 Previous |
 Next |
|
Oracle® Process Manager and Notification Server Administrator's Guide
10g Release 3 (10.1.3) B15976-01 |
|
|
Previous |
Next |
This chapter provides an overview of the opmn.xml file for Oracle Application Server. It features the following topics:
The ORACLE_HOME/opmn/conf/opmn.xml file is the main configuration file for OPMN. The opmn.xml file contains information for PM and Oracle Application Server component specific configuration. The opmn.xml file shows you which Oracle Application Server components OPMN is managing on your system.
The opmn.xml file does not contain component-specific element names. Component specific management code is located in the PM modules which get loaded by OPMN at startup according to what has been specified in the modules section of the opmn.xml file.
Each level has a specific set of configurations. In addition, there are several configuration elements that are accepted at more than one level to provide the flexibility of applying a configuration across an entire Oracle Application Server component or just part of a component.
<ias-component> <process-type> <process-set>
<ias-component>: This entry represents the Oracle Application Server component. It enables management of the component for processes such as starting and stopping.
<process-type>: This subcomponent of the <ias-component> entry declares the type of process to run by association with a specific PM module.
<process-set>: This sub-subcomponent of the <ias-component> entry enables you to declare different sets of optional runtime arguments and environments for the Oracle Application Server component.
The opmn.xml file contains Oracle Application Server component entries arranged in the hierarchical structure shown in Example 3-1.
Example 3-1 Element Entries in opmn.xml File
<ias-component id="OC4J"> <process-type id="home"> <process-set id="default_group">....
You can edit the opmn.xml file using Application Server Control Console. Click the Process Management link at the bottom of the Oracle Application Server instance home page. Do not stop the OPMN server after you edit the opmn.xml file. Application Server Control Console automatically reloads the updated opmn.xml file after you edit the file.
ONS can be configured from the opmn.xml file. Example 3-2 is an example of the ons.conf element in the opmn.xml file:
OPMN uses dynamic discovery to contact other ONS servers in a cluster environment. The opmn.xml file contains a multicast address or list of discovery servers that is used by OPMN. ONS uses the discovery mechanism to announce new servers to a cluster and join them into the ONS topology dynamically.
The ONS network topology includes all of the Oracle Application Server instances that have been configured with the same discovery information.
The information is configured under the notification-server element in the opmn.xml file. Example 3-3 shows the notification-server element in the opmn.xml file:
Example 3-3 Notification Server element
<notification-server interface="type"> <ipaddr remote="ip" request="ip"/> <port local="port" remote="port" request="port"/> <ssl enabled="boolean" wallet-file="path" wallet-password="password" openssl-certfile="path" openssl-keyfile="path" openssl-password="password" openssl-lib="path"/> <tune io-timeout="timeout" io-idle="interval" timeout="timeout"/> <topology> <nodes list="nodes"/> <discover list="nodes"/> <gateway list="nodes"/> </topology> </notification-server>
The following sections describe the three configuration types for dynamic discovery:
For multi-cast configuration of dynamic discovery, you configure a multi-cast address for all ONS servers in the opmn.xml file. ONS uses this address to discover all other Oracle Application Server instances in the cluster.
Figure 3-1, "Multi-cast Configuration" shows diagrammatically what occurs in the multi-cast configuration.
Any new Oracle Application Server instance in the cluster is announced using the configured multi-cast address. ONS then automatically manages the connection topology as instances are added or removed.
More than one multi-cast address may be configured, but typically these would be used to isolate subnets from one another, and then gateways configured to connect them.
Refer to Chapter 6, "opmn.xml Common Configuration" for information on how to implement multi-cast configuration.
For the discovery server configuration of dynamic discovery one Oracle Application Server instance acts as a discovery server for all instances. ONS uses the discovery server to discover all of the other Oracle Application Server instances in the cluster.
Figure 3-2, "Discovery Server Configuration" shows diagrammatically what occurs in the discover server configuration.
A new Oracle Application Server instance in the cluster contacts the configured discover server to announce itself. ONS then automatically manages the connection topology as instances are added or removed. More than one discovery server may be configured.
Figure 3-2 Discovery Server Configuration
For more information on discovery server configuration refer to Chapter 6, "opmn.xml Common Configuration".
For the gateway configuration of dynamic discovery, a gateway is used to interconnect multiple discovered topology rings.
Figure 3-3, "Gateway Configuration" shows diagrammatically what occurs in the gateway server configuration.
Gateway is used to interconnect multiple discovered topology rings.
The gateway configuration is used when a network topology has nodes in different subnets or physical locations.
For more information on gateway configuration refer to Chapter 6, "opmn.xml Common Configuration"
Dynamic Resource Management (DRM) is an OPMN capability designed to describe a set of desired behaviors and take actions to achieve the desired results. DRM functionality provides a way for you to customize the management of your processes through configuration changes only. The DRM enables you to have process management commands issued based on system conditions according to a set of user-configured directives.
DRM is designed to operate on an Oracle Application Server instance. In a cluster environment, DRM functionality is available on each separate local instance.
The system conditions that can be taken into account include Dynamic Monitoring Service (DMS) metrics that are recognized by OPMN. During runtime DMS collects performance information, DMS metrics, that you can use to analyze system performance or monitor system status. This includes preset metrics that are always present as well as metrics that you define and implement. For more information about DMS refer to the Oracle Application Server Performance Guide.
DRM enables you to specify a set of conditions that will trigger process management commands to be automatically issued. This is accomplished using Resource Management Directives (RMDs). RMDs are a set of conditions that specify:
A set of information that should be examined prior to performing an action
The values of the set information that trigger an action
The action that should be performed after the set of information is examined and analyzed.
RMDs enable you to configure OPMN to monitor the state of your system on a periodic basis and take action if conditions exceed the scope specified in the RMD.
For example, in the DRM graphic shown in Figure 3-4, the RMDs might be:
At 17:00 hours every day, start two OC4J processes in anticipation of a peak load.
If the Java Virtual Machine (JVM) heap size grow beyond 500 MB, start a second OC4J process.
If the average response time rises above 500 milliseconds, then start an OC4J instance.
For more information about RMDs, refer to Section 3.3.1, "Resource Management Directives"
A RMD describes a set of information that should be examined, a description of the values of this information that should trigger an action, and an action that should be performed. RMDs are comprised of seven features:
Metrics: what information should be used to decide what action to take?
For example:
memory usage
CPU utilization
average response time
request queue length
availability of database connections
Frequency: how often should the metric values specified be examined?
This setting enables you to control the evaluation of the RMD to be fast acting enough to react to changing system conditions but not so frequent that it will cause needless oscillation in system performance or unnecessary polling of metric values.
Conditional: what rules should be applied to the metrics being examined?
For example:
a comparison of a single metric with a fixed value. For example, checking if CPU utilization is above 75%.
a combination of values. For example, if CPU utilization is above 75%, memory usage is above 50 MB, and average response time is above 0.1 seconds.
Duration: how many times or over what time period a condition must be met in order to trigger an action?
This is used to avoid unnecessary actions when conditions are marginal. For example, the administrator may only want to take an action if CPU utilization is above 75% for more than 2 minutes to avoid allocating more resources due to a small spike in activity
Action: what action should be performed when the state described by the first four items (metrics, frequency, conditional, and duration) are met?
The action could include starting, stopping, or restarting a component. The action could also include requesting additional resources such as starting additional processes, or requesting the starting of an application on another node.
Exception: what should be done if execution of the desired action fails?
The exception could include alternative actions to perform or a message to be sent to a monitor such as Oracle Enterprise Manager 10g.
Interval: how often should each a process-set, configured for the ias-component, be evaluated?
The DRM evaluates and performs the actions described by the RMDs.
Figure 3-5 shows DRM management on two hosts with two applications on each host, App1 and App2. Each host is sharing the application load. Each host has the capacity to run a maximum of five processes. Figure 3-5 shows that the demand for App1 is more than the demand for App2 so more processes have been started for App1 to handle the load.
Figure 3-6 shows that as the demand for App2 increases and the demand for App1 decreases, processes servicing App1 are automatically shutdown and more processes are automatically started to service App2. Resource demand determination is made independently on each computer without coordination. Both computers detect the change in demand independently and take similar action to accommodate the change, with the overall effect of the total system adjusting to demand.
The total demand across both computers for each application varies between two and eight processes. The traditional way to provision hardware is to have enough system resources available to handle the peak demand for each application. Such a strategy would indicate having adequate system hardware to run sixteen processes.
Even with three computers capable of each running five processes, the demand on system resources for processing of the applications would not be sufficient. By adjusting the available resources dynamically between App1 and App2 using DRM, peak load times for each application can be accommodated using only two computers.
Example 3-4 shows the RMD syntax.
Example 3-4 RMD syntax
<rmd name="rmd name"> <conditional> <!CDATA[conditional]> </conditional> <action value="action 1"/> <action value="action 2"/> ... <action value="action N"/> <exception value="exception 1"/> <exception value="exception 2"/> ... <exception value="exception N"/> </rmd>
In Example 3-5, the RMD checks if the average request response time for its processes exceeds a maximum threshold for more than a minute, and if so it attempts to start another process if the configuration allows it.
Example 3-5 RMD Response Time Syntax
<rmd name="rampUp">
<conditional>
<![CDATA[([process-set].responseTime > 5000) {duration(60)} &
([process-set].numProcs <[process-set].maxProcs)]]>
</conditional>
<action value="exec $ORACLE_HOME/scripts/logevent {ias-component} {process}
slow response"/>
<action value="start {process-set}"/>
<exception value="exec $ORACLE_HOME/scripts/mailadmin {ias-component}
{process-type} {process-set} could not start"/>
</rmd>
Figure 3-7, Figure 3-8, Figure 3-9, and Figure 3-10 diagram the actions of an RMD when configured parameters are surpassed.
In Figure 3-7, the average request response time has exceeded the upper threshold, and the number of OC4J processes for the process-set is less than the configured maximum.
In Figure 3-8, the RMD executes the actions, which entail starting another OC4J process for the ShopCart process-set.
Figure 3-8 Starting of Additional Process
The directive in Figure 3-8 has a complementary RMD (Example 3-6) to remove excess OC4J processes when the average request response time drops below a minimum threshold for at least five minutes.
Example 3-6 Complimentary RMD
<rmd name="rampDown">
<conditional>
<![(CDATA[([process-set].responseTime < 2000) {duration(500)} &
([process-set].numProcs > [process-set].minProcs)]]>
</conditional>
<action value="exec $ORACLE_HOME/scripts/logevent {ias-component} {process}
fast response"/>
<action value="stop {process-set}"/>
<exception value="exec $ORACLE_HOME/scripts/mailadmin {ias-component}
{process-type} {process-set} could not stop"/>
</rmd>
In Figure 3-9, the average request response time has been less than the lower threshold for at least five minutes, and the number of OC4J processes for the ShopCart process-set is more than the configured minimum.
Figure 3-9 Number of Processes exceeds Configured Minimum
In Figure 3-10, the RMD executes the actions, which stop an OC4J process for the ShopCart process-set.
Figure 3-10 RMD Stops a Process to Complete Request
RMDs can be configured in two ways. They can either be:
associated with a specific hierarchy level in the components that are managed by OPMN (for example, a specific ias-component or process-set)
global entities
RMDs associated with a specific place in the hierarchy can only specify metrics and actions that are associated with the RMD relative to their location in the hierarchy. Each RMD has an evaluation level, which specifies the lowest OPMN component level referenced by the directive, and RMDs which are defined at a higher level (ias-component, for example) will be inherited by any lower level components (process-set, for example) they reference. For example, an RMD defined at the ias-component level that references process-set will be inherited by all process-sets for the ias-component under which it was defined.
Global RMDs are configured in an independent section of the opmn.xml file. They can use metrics from anywhere in the DMS tree and can take action on any components managed by OPMN. For more information about DMS refer to the Oracle Application Server Performance Guide.
The RMD conditional describes a state of the system that will trigger an action. The conditional consists of a logical combination of comparisons between values. Like all other aspects of OPMN, conditionals are case sensitive. The values that may be used can be:
DMS metrics available from the OPMN DMS tree
For more information about DMS refer to the Oracle Application Server Performance Guide.
Constant values (for example, 500000)
Temporal values (for example, 5 PM)
DMS metrics are described based on their location in the OPMN DMS tree. This description can be:
a fully qualified path
a hierarchical relative reference
a global absolute reference
A fully qualified path to the metric desired such begins with a "/ " and includes the full path from the OPMN instance, /pm/host_statistics/freePhysicalMem. The OPMN instance prefix is automatically added to these paths.
Metrics with fully qualified paths can be referenced by both hierarchical and global RMD conditionals.
If the RMD is hierarchical the metric can take a relative path form such as [process-set].numProcs which specifies the numProcs metric for any process-set in the hierarchy to which this RMD belongs.
The following component specifications are allowed for hierarchical RMD conditionals:
[ias-component]: refers to the ias-component element within the hierarchy of the opmn.xml file.
[process-type]: refers to the process-type within the hierarchy of the opmn.xml file.
[process-set]: refers to the process-set within the hierarchy of the opmn.xml file.
[process]: refers to the process within the run time hierarchy.
[application]: refers to the application within the run time hierarchy. Unlike all other hierarchical specifications, a specific application can be named.
If the RMD is global the metric can be an absolute description of a starting point followed by a relative path. For example:
[ias-component=WebCache][process-set=WebCache].numProcs
which specifies the metric numProcs for the process-set Webcache that belongs to the ias-component WebCache.
The following component specifications are allowed for global RMD conditionals:
[ias-component=<comp>]: refers to the ias-component <comp> in the opmn.xml file.
[process-type=<ptype>]: refers to the process-type <ptype> in the opmn.xml file.
[process-set=<pset>]: refers to the process-set <pset> in the opmn.xml file.
[process]: refers to the process.
[application]: refers to the application.
[application=<app>]: refers to the application <app> running in the process.
As with OPMN process requests, components not specified in the directive are assumed to be wildcards; thus a global RMD referencing [process-set=home] would be evaluated for every process-set with the id home configured in the opmn.xml file.
No conditional is allowed to reference more than one OPMN component. For example, the same conditional cannot reference [ias-component=Webcache] and [ias-component=HTTP_Server]. Similarly, references to lower configuration components must belong to any referenced higher component within the same conditional.
With the exception of process, the sections surrounded by square brackets must match a DMS tree type as shown in a dump of the OPMN DMS tree.
For both hierarchical and global RMDs multiple bracketed sections can be specified but each subsequent section must further narrow the tree. The order must progress from the top of the tree toward the leaf. A process cannot appear before an ias-component.
Constant values must be simple, numeric values, including decimal values. When comparing a constant value with a DMS metric, the constant must have the same units as the DMS metric it is being compared to. The DRM will convert the numeric value on the right hand of an operator to the same type (decimal or integer) on the left, but no other unit conversions will be performed by the DRM.
Temporal values consist of a 24 hour format (hh:mm) time combined optionally with a day of the week indicator. The allowed day of the week abbreviations are mon, tue, wed, thu, fri, sat, sun. Day of the week indicators can be a single value, a comma separated list, or a dashed inclusive list. For example:
17:00 Daily at 5 PM
[mon-fri].21:45 weekdays at 9:45 PM
[mon,wed,fri].5:00 Monday, Wednesday, Friday at 5 AM
The current time is represented by the key word {time}. A time comparison is evaluated false if the day of the week specified on the left of the operator does not include a day of the week specified on the right; by default the day of the week is only evaluated as equals and only if this is true is the time value itself evaluated for the specified operator. You can force the comparison to be made against a single day of the week by appending the @ character after the day, with Sunday (sun) having the value 0 and Saturday (sat) 6.
{time} < [wed].12:00: evaluates true only on Wednesday until noon
{time} < [wed@].12:00: evaluates true from Sunday at 00:00 until Wednesday at noon
Comparisons between values include the following: less than (<), less than or equal to (<=), greater than (>), greater than or equal to (>=), equals (=), or not equals (!=).
String values may also be specified between quotes (using the single quote character ("), but the only allowable operators are equals (=) and not equals (!=).
Comparisons may be logically combined using the operators and (&), or (|), not (!), and grouping (( )). The logical not unary operator (!) can be placed before any logical group of comparisons to logically negate the result of the outcome.
The key word {duration(value)} may also be used to indicate that a conditional should only trigger if it has evaluated as true over the specified time interval expressed in seconds. It is important to note that the conditional is only evaluated on a periodic basis. Specifying the duration value will force the conditional to only trigger if all evaluations over the time period meet the conditional. This is an approximation of ensuring that the condition holds true over the entire time period. The accuracy of this approximation depends on the ratio of the duration value to the evaluation period. When a conditional is evaluated as true, all durations for that evaluation are reset. When a conditional evaluates false, any duration that was not encountered during the evaluation is reset.
The following RMD conditional examples detect specific states:
If the heap size of a JVM has exceeded 500 Megabytes (global RMD):
[process-set=home][process].heapSize > 500000
If the time is 5 PM on a weekday
{time} = [MonFri].1700
If the average request time is greater than 500 ms for at least 60 seconds and there are less then 4 processes running for the for the process-set at which this hierarchical RMD was configured (OC4J):
([process].avgReqTime > 500 {duration(60)})&([process-set].numProcs <4)
If there has been less than 50 megabytes of free system memory for the last 3 minutes:
/pm/host_statistics.freePhysicalMemory < 50000 {duration(180)}
The Action section of an RMD is a list of action elements, each of which specifies a process management command that describes an action that should be performed if the conditional of the RMD is satisfied. The syntax of these commands is similar to that of opmnctl without the scope.
The possible actions for an RMD are:
start: perform a start request with the given argument list
restart: perform a restart request with the given argument list
stop: perform a stop request with the given argument list
exec: execute the given program or script with the listed arguments
The targets for the start, restart, and stop requests is assumed to be relative to the OPMN components referenced in the RMD conditional. Key words representing these components should be used to narrow the scope of the request.
The following set of key words are available:
{ias-component} ias-component=<comp>
{process-type} process-type=<ptype>
{process-set} process-set=<pset>
{process} uniqueid=<uid>
{application} application=<app>
For start, restart, and stop actions, the key word {process} should not be used with the other keywords.
In addition the exec action can use the {pid} key word, which equates to pid=<pid> if the conditional refers to a process-set or process.
Note that an action cannot reference a key word for an OPMN component at a level below the lowest OPMN component referenced in the conditional (if the conditional only references an ias-component, then the action can only use the {ias-component} key word, for example). The exception to this rule is that an action may reference {process} if the conditional references a process-set, but this will force the RMD to be evaluated at the process level and not the process-set level.
If the start, restart, and stop request returns a non successful status (200 is success) or an exec exits with any code other than 0, then the remaining actions are skipped and any exceptions configured for the RMD are executed.
A timeout value can be configured for each action. The default timeout for start, restart, and stop actions is the configured (or default) timeout for the OPMN request. The default timeout for exec actions is 30 seconds.
The results of the RMD requests are logged in the OPMN process manager log (the beginning and completion of the request with completion status at level 4, and full results at level 5). The stdout and stderr of exec programs or scripts is sent to $ORACLE_HOME/opmn/logs/rmd.out. Note that there is no rotation performed on the rmd.out file. Therefore, programs and scripts should maintain and use their own log files. Programs and scripts should not print output to either of the stdout and stderr file descriptors.
The following are RMD Action Examples:
Start another JVM in the home OC4J instance within a hierarchical RMD defined within the home instance (note this process-set must be configured with minprocs/maxprocs):
start {ias-component}{process-type}{process-set} numprocs=1
Restart a JVM in the home instance within a hierarchical RMD defined within the home instance:
restart {process}
Stop the entire ias-component referred to by the RMD conditional:
stop {ias-component}
Execute the given program and pass in the referenced process UID and pid:
exec $ORACLE_HOME/mybin/report.sh "RMD triggered" {process} {pid}
The Exception section of an RMD is a list of process management commands that are to be performed in the case that any of the process management commands in the action section of the RMD fail to execute normally. The format of the exception section is identical to that of the action section.
opmn.xml file
RMDs are configured in the opmn.xml file in a section entitled rmd-defintions. The conditional, action, and exception portions of each RMD are attributes in the .xml definition. Example 3-7 shows how an RMD would be defined as a hierarchical RMD in the opmn.xml file and Example 3-8 shows how an RMD would be defined as a global RMD.
Example 3-7 Hierarchal RMD Example
<process-type id="home" moduleid="OC4J" status="enabled">
.
.
.
<rmd-defintions>
<rmd name="requesttime" description="Start another OC4J (if possible) when the
response time of any exiting OC4J in home exceeds 500msecs for a minute"
interval="30">
<conditional>
<![CDATA[([process].avgReqTime > 500 {duration(60)})&([process-set].numProcs
< 4)]]>
</conditional>
<action value="start {ias-component}{process-type}{process-set} numprocs=1"/>
<exception value="exec $ORACLE_HOME/mybin/mailer.sh {ias-component}
{process-type}{ process-set} failed to start on RMD request"/>
</rmd>
</rmd-defintions>
</process-type>
Example 3-8 Global RMD Example
<process-manager>
.
.
.
<rmd-defintions>
<rmd name="requesttime" description="Start another OC4J (if possible) when the
response time of any exiting OC4J in home exceeds 500msecs for a minute"
interval="30">
<conditional>
<![CDATA[([process].avgReqTime > 500 {duration(60)})&([ias-component=OC4J]
[process-set=home].numProcs < 4)]]>
</conditional>
<action value="start {ias-component}{process-type}
{process-set}.numprocs=1"/>
<exception value="exec $ORACLE_HOME/mybin/mailer.sh {ias-component}
{process-type}{process-set}failed to start on RMD request"/>
</rmd>
</rmd-defintions>
</process-manager>
RMDs will be evaluated periodically based upon their configured interval or the default value of 30 seconds. Note that there is a trade off between CPU cycles consumed evaluating RMDs and the sensitivity of the execution of RMDs. The evaluation period and the time value defined by the {duration()} key word should relate in a reasonable ratio.
RMDs are evaluated based upon where they are configured and what their conditionals reference. A global RMD that only references full paths to metrics or the internal temporal value is truly global and only a single evaluation is performed for each configured interval. A hierarchical RMD that is defined under an ias-component, but references a process-set will be evaluated once for each interval for each process-set configured for the ias-component. Any RMD that references a process in either its conditional, actions or exceptions will be evaluated once for each interval for each process that exists under the components referenced by the RMD. Note that RMDs that reference a process will only be evaluated if a process exists and is in the Alive state.
DMS metrics are retrieved at evaluation time. If a referenced DMS metric cannot be found, that part of the conditional will evaluate as false.
Invalid type comparisons for metrics are discovered at evaluation time. When the invalid type comparisons are encountered, the current evaluation is aborted, the RMD is disabled, and all other evaluations based upon this RMD are aborted. An error is logged in the OPMN process manager log.
Service failover is mechanism to specify a critical process that must be run somewhere in an Oracle Application Server cluster if service is disrupted on a processing server. This enables you to preferentially select which processes must be kept running.
Any process-type opmn.xml file element may be configured as a service fail-over such that, once started, OPMN will ensure that the configured number of processes for the service are running on Oracle Application Server instances somewhere in the cluster.
You can configure which Oracle Application Server instances will participate in the service fail-over on an instance by instance basis. You can configure each instance for preferential selection of running the process on available instances.
Only one process-set may be defined for each process-type configured as a service fail-over. Only one process will be run for each service fail-over instance.
In the following Figure 3-11, a service fail-over process has been started in a cluster where all instances are configured to participate in the service fail-over.
As shown in Figure 3-12, if the instance on which the service fail-over process is running goes down, such as for maintenance or an unprotected power outage or network failure, OPMN will select another participating Oracle Application Server instance on which to run the process. All of the instances shown in Figure 3-12 are participating in the service fail-over.
OPMN gives the user control over automatic death detection and restart of components; you can configure the parameters by which OPMN determines a process has died and disable automatic restart for individual components.
OPMN monitors the operation of its managed processes by the following methods:
Operating system level detection of Oracle Application Server process death
Periodic ping requests to Oracle Application Server processes
Periodic status notification from Oracle Application Server processes (reverse-ping)
The ping and notification functionality is only used where appropriate according to the functionality of the Oracle Application Server component.
OPMN automatically restarts Oracle Application Server components that terminate unexpectedly. OPMN will also restart processes that are unresponsive according to the result of notification and ping operations.
You can configure OPMN to execute your own custom event scripts whenever a particular component starts, stops, or crashes. You can select from one or more of the following event types:
pre-start: OPMN runs the pre-start script after any configured dependency checks have been performed and passed, and before the Oracle Application Server component starts. For example, the pre-start script can be used for site-specific initialization of external components.
pre-stop: OPMN runs the pre-stop script before stopping a designated Oracle Application Server component. For example, the pre-stop script can be used for collecting Java Virtual Machine stack traces prior to stopping OC4J processes.
post-crash: OPMN runs the post-crash script after the Oracle Application Server component has terminated unexpectedly. For example, a user could learn of component crashes by supplying a script or program to be executed at post-crash events which sends a notification to the administrator's pager.
Some Oracle Application Server components and services require that other components and services are up and running before starting. OPMN is configured at installation with default start order dependencies, which enables you to start all of the components in an instance in the proper order with a single command. Refer to the Oracle Application Server Administrator's Guide for more information on Oracle Application Server dependencies.
OPMN is configured with a set of dependencies but you can configure additional dependencies according to the environment
The log files generated by OPMN provide important information that can help you identify and diagnose performance and configuration issues. The Application Server Control Console makes reviewing these log files easier by helping you locate and view Oracle Application Server component log files.
The OPMN local listener port used by ONS clients and PM administrative processes do not use Secure Socket Layer (SSL) encryption for security, but rely on two other mechanisms to ensure authorized access to the OPMN server:
OPMN binds the local listener port to the local host. Users on the local system can connect to this port and issue OPMN process control requests. Information requests are allowed on the OPMN request port, which is bound to the system IP. The request port does not have SSL encryption.
When the OPMN server process first starts up and successfully binds to the local port, it creates a string of printable ASCII characters which it uses as a key for local connections. All connection attempts on the local port must include this key or the connection is closed by the OPMN server. The ASCII character string is written into the ORACLE_HOME/opmn/conf/.formfactor file. Processes that cannot access the .formfactor file are not permitted to interact with the OPMN server.
For security reasons, the OPMN server logs any attempts to connect to its local port with an invalid form factor key (a key that does not match the value written by this OPMN process into the .formfactor file).
In addition to attempted security violations, there are four common user errors that can cause this error to occur:
The user attempts to run the OPMN client manually with the wrong user identification. Only the application server user can read the value from the .formfactor file, and so requests or processes run as the wrong user will not be able to provide the correct key to the OPMN server.
The user is attempting to run an OPMN client from the wrong ORACLE_HOME. It is possible to have multiple ORACLE_HOME instances set up on the same system. If the other ORACLE_HOME instances have OPMN configured to use the same local port then the Oracle Application Server process request from the wrong ORACLE_HOME will read the wrong .formfactor file.
The user has manually changed the local port configuration in the opmn.xml file and started a new OPMN server without first stopping the previous OPMN server. The new OPMN server will run, bind to the new port, and overwrite the .formfactor file. The previous OPMN server is now unreachable through the local port, and can only be shutdown through remote OPMN requests (if SSL and authentication are configured) or by manually stopping the previous OPMN server.
The Oracle Application Server and the Oracle Database both use ONS. When these two products are installed onto the same host, an ONS port conflict arises since the default port values (local="6100" remote="6200") for ONS are the same for both the Oracle Database and Oracle Application Server.
ONS with the Oracle Database is only used for special configurations and therefore is typically never started. However, the database listener will attempt to connect to the Database ONS server but will end up connecting to the ONS server that was installed with Oracle Application Server. ONS (as part of OPMN) is always started whenever Oracle Application Server is started.
Because the Oracle Database is installed in a different ORACLE_HOME than that of Oracle Application Server, the Database ONS does not have access to the .formfactor file that was created when OPMN started up with the Oracle Application Server. As a result, the database listener attempts to connect to OPMN; the DB listener interprets it as a its standalone ONS) without a form factor string. Oracle Application Server OPMN logs an error similar to the following in the ons.log file:
04/11/15 18:43:32 [4] Local connection 0,127.0.0.1,6100 invalid form factor
This is expected OPMN behavior Oracle Application Server; preventing client access to the ONS server unless they possess the correct formfactor string.
To avoid having the Oracle Database listener contact the Oracle Application Server OPMN server, change the default local and remote port values for the ONS server that was installed with the Oracle Database. Alternatively, you can apply the latest Oracle Database patchset available on OTN:
http://www.oracle.com/technology/products/
OPMN supports remote requests to other OPMN servers in the same cluster, but for security reasons all process control requests (start, restart and stop) are only enabled if SSL is enabled in the opmn.xml file and a wallet file is configured. If neither SSL nor a wallet file are configured, OPMN will reject any remote process control request with HTTP code 403.
The remote port used for remote administration must be SSL-enabled. The remote port should only be used for communication between multiple OPMN servers. Oracle Application Server components and Application Server Control Console transmit through the local port which is inaccessible to remote administration. All access control and authentication is controlled by going through Application Server Control Console.
During Oracle Application Server installation, OPMN will be configured to use a wallet that contains a default certificate. For secure operation, the certificate used must be replaced with a secure, unique certificate. Refer to the Oracle Application Server Security Guide for information on how to configure certificates within an Oracle Wallet.
The orapki script, which is documented in the Oracle Application Server Security Guide, can be used to generate a random, self-signed certificate that is sufficient to provide the appropriate level of security for OPMN.
Note that use of OPMN in a cluster requires configuration with certificates that are trusted by all other members of the cluster. This can be accomplished by either using the same wallet in all OPMN instances in the cluster or using certificates created by a common certificate authority.
|
See Also: Oracle Application Server Security Guide |
In 10.1.3, ONS is able to concurrently support the IPv4 and IPv6 network interfaces.
IPv4 is version 4 of the Internet Protocol (IP). It was the first version of the Internet Protocol to be widely deployed, and forms the basis for most of the current Internet (as of 2004).
IPv4 uses 32-bit addresses, limiting it to 4,294,967,296 unique addresses, many of which are reserved for special purposes such as local networks or multicast addresses, reducing the number of addresses that can be allocated as public Internet addresses.
IPv6 is intended to address the concern that there are too few IP addresses available for the future demand of device connectivity (especially cell phones and mobile devices). IPv6 supports 340 undecillion (3.4 × 1038) addresses.
As shown in Figure 3-13, for output, such as debug or log records, each IPv4 identifier will be displayed as four, eight bit fields for the address (each a three digit decimal format) and a single 16 bit field for the port (a five digit decimal format).
Each IPv6 identifier will be displayed as eight 16 bit fields for the address (each a four digit hexidecimal format) and a single 16 bit field for the port (the five digit decimal format).
Figure 3-13 IPv4 and IPv6 Host Identifier
