a
Node Manager Restarts an Administration Server
The
diagram in the slide illustrates the flow of a Node Manager restarting an
administration server.
1. The
Node Manager determines from the administration server process exit code that
it requires a restart. Note that no user is involved.
2. The
Node Manager obtains the username and password for starting the administration
server from the boot.properties
file, and the server startup properties from the server/security/startup.properties
file. These server-specific files are located in the server
directory for the administration server.
3. The
Node Manager starts the administration server.
4. The
administration server reads its configuration data and starts up.
Node
Manager Restarts a Managed Server
The
diagram in the slide illustrates the flow of a Node Manager restarting a
managed server.
1. The
Node Manager determines from Managed Server 1’s last known state that it
requires a restart. Note that no user is involved.
2. The
Node Manager obtains the username and password for starting Managed Server 1
from the boot.properties
file, and the server startup properties from the startup.properties
file. These server-specific files are located in the server
directory for Managed Server 1.
3. The
Node Manager starts the managed server.
Note: The Node Manager waits RestartDelaySeconds after a server instance fails before attempting to restart it.
Note: The Node Manager waits RestartDelaySeconds after a server instance fails before attempting to restart it.
4. Managed
Server 1 attempts to contact the administration server to check for updates to
its configuration data. If it contacts the administration server and obtains
updated configuration data, it updates its local cache in the config
directory.
5. If Managed Server 1 fails to contact the
administration server, and if Managed Server Independence mode (MSI) is
enabled, Managed Server 1 uses its locally cached configuration data.
Node
Manager Shuts Down a Server Instance
The
diagram in the slide illustrates the flow of a Node Manager shutting down a
server.
1. Through
the Administration Console, an authorized user issues a shutdown command for
Managed Server 1.
2. The
administration server issues the shutdown command directly to Managed Server 1.
If it successfully contacts Managed Server 1, Managed Server 1 performs the
graceful shutdown sequence.
3. If
in the previous step, the administration server fails to contact Managed Server
1, it issues a shutdown command for Managed Server 1 to the Node Manager on
Machine B.
4. The
Node Manager issues a request to the operating system to stop Managed Server 1.
5. The
operating system ends the Managed Server 1 process.
Versions
of Node Managers
Oracle
WebLogic Server provides two versions of Node Managers: Java-based and
script-based, with similar functionality. However, each version has a different
configuration and security considerations.
The
Java-based Node Managers run within Java Virtual Machine (JVM) processes. It is
recommended that you run Node Managers as Windows services on Windows platforms
and as operating system services on UNIX platforms, allowing the Node Managers
to restart automatically when the system is rebooted.
Oracle
provides native Node Manager libraries for Windows, Solaris, HP-UX, Linux on
Intel, Linux on Z-Series, and the AIX operating systems.
Note: Node Managers are not supported on Open
VMS, OS/390, AS400, UnixWare, or Tru64 UNIX.
This
version of the Node Manager determines its configuration from the nodemanager.properties
file.
For
UNIX systems, Oracle WebLogic Server provides a script-based version of the
Node Manager. This script is based on UNIX shell scripts, but uses Secure Shell
(SSH) for increased security. SSH uses user-ID based security.
The
script-based version does not provide as much security as the Java-based
version. However, the advantage of script-based Node Managers is that they can
remotely manage servers over a network that has been configured to use SSH. No
additional server installation is required. The scripts merely have to be
copied to the remote machine. Although scripted, the Node Manager can be easy
to configure in some cases, and its feature set does not contain some of the
capabilities of a Java Node Manager. For those more familiar with configuring
Java SSL than RSH or SSH, a Java-based Node Manager can be just as easy to
configure.
Determining Which Node Manager Version to Use
•Automatic
Server Migration is supported by both the scripted version of Node Managers and
the Java version of Node Managers. In previous releases of WLS, only the
scripted version supported automatic server migration.
•If
you are installing Oracle WebLogic Server on a Windows system, you must use a
Java version of Node Manager. The scripted version of a Node Manager is not
supported on Windows.
•The
script-based Node Manager requires a much simpler security configuration than
the Java version. Remote Shell (RSH) and SSH are easier to configure than
Secure Sockets Layer (SSL), which is the method of security used by a Java
version of Node Manager. The script version of a Node Manager also requires a
smaller footprint than the Java version.
•The
Java version of a Node Manager can be used with inetd
on supported UNIX systems. inetd
allows a Node Manager to be automatically restarted upon receiving a request on
the configured port. The Java Node Manager is a running process that can also
recover on its own in case of a full-machine shutdown. In the case where the Java Node Manager is
restarted (automatically or manually), it will scan the domain directories for
the servers it had previously managed or started and will automatically attempt
to restart them. The scripted Node Manager is a passive process and is unable
to do this.
Node
Manager Default Behaviors
The
Node Manager is ready to run after Oracle WebLogic Server is installed if you
run the Node Manager and the administration server on the same machine, and use
the demonstration’s Secure Sockets Layer (SSL) configuration. By default, the
following behaviors are configured:
•You
can start a managed server using the Node Manager through the Administration
Console.
•The
Node Manager monitors the managed servers that it has started.
Automatic
restart of managed servers is enabled. The Node Manager restarts the server
instances that it killed or that were killed by another method.
Configuring
a Java-Based Node Manager
Except
where noted, the configuration files apply to both Java-based and script-based
Node Manager. The following files are located in <WL_HOME>/common/nodemanager.
•nodemanager.properties:
This is the configuration file that is used by the Java-based version of the
Node Manager.
•nodemanager.domains:
This file contains mappings between the names of the domains managed by the
Node Manager and their corresponding directories.
•nm_data.properties:
This file stores the encryption data that the Node Manager uses as a symmetric
encryption key. The data is stored in
an encrypted form.
These
files are located in other directories:
•nm_password.properties:
This file stores a username/password pair that is specific to the Node Manager
server that manages this domain. This is known as the Node Manager secret. The
username and password are appended to a salt value (obtained from SerializedSystemIni.dat
of the domain) and Secure Hash Algorithm (SHA) hashed. This file is located in DOMAIN_HOME/config/nodemanager.
•boot.properties:
The Node Manager uses this file to specify a boot identity when starting a
server. This file is located in
domain-name/servers/server_name/data/nodemanager.
domain-name/servers/server_name/data/nodemanager.
The
following file has been deprecated but you may still see it around:
•nodemanager.hosts:
This file contained a list of all the trusted hosts that could issue commands
to the Node Manager. It was located in <WL_HOME>/common/nodemanager.
Reconfiguring
the Startup Service for a Windows Installation
The
<WL_HOME>/server/bin
directory (where <WL_HOME>
is the top-level directory for the Oracle WebLogic Server installation)
contains uninstallNodeMgrSvc.cmd,
a script for uninstalling the Node Manager service, and installNodeMgrSvc.cmd,
a script for installing the Node Manager as a service.
1. Delete
the Node Manager service using uninstallNodeMgrSvc.cmd.
2. Edit
installNodeMgrSvc.cmd
to specify the listen address and the listen port of the Node Manager. Make the
same edits to uninstallNodeMgrSvc.cmd
as you make to installNodeMgrSvc.cmd,
so that you can successfully uninstall the service in the future.
3. Run
installNodeMgrSvc.cmd
to reinstall the Node Manager as a service, listening on the updated address
and port.
Node
Manager as a UNIX Daemon
Oracle
WebLogic Server does not provide a command script for uninstalling and
reinstalling the Node Manager daemon process. Refer to your operating system
documentation for instructions on uninstalling existing daemons and setting up
new ones.
1. Remove
the Node Manager daemon process that the Oracle WebLogic Server installation
process sets up.
2. At
the command line, or in a script, reinstall the Node Manager daemon. You may
want to view the contents of the installNodeMgrSvc.cmd
file before setting up the new daemon. This cmd file is not installed on
UNIX-based systems. Although this command file is Windows-specific, it
illustrates the following:
-The
key environment and local variables that must be defined
-The
validation steps that you might want to include in a script that installs the
Node Manager as a daemon
-The
logic for setting default values for the listen address and port
Node
Manager as a UNIX Daemon
Oracle
WebLogic Server does not provide a command script for uninstalling and
reinstalling the Node Manager daemon process. Refer to your operating system
documentation for instructions on uninstalling existing daemons and setting up
new ones.
1. Remove
the Node Manager daemon process that the Oracle WebLogic Server installation
process sets up.
2. At
the command line, or in a script, reinstall the Node Manager daemon. You may
want to view the contents of the installNodeMgrSvc.cmd
file before setting up the new daemon. This cmd file is not installed on
UNIX-based systems. Although this command file is Windows-specific, it
illustrates the following:
-The
key environment and local variables that must be defined
-The
validation steps that you might want to include in a script that installs the
Node Manager as a daemon
-The
logic for setting default values for the listen address and port
Reviewing
nodemanager.properties
The
Node Manager properties define a variety of configuration settings for a
Java-based Node Manager process. You can specify the Node Manager properties on
the command line or define them in the nodemanager.properties
file, which is created in the <WL_HOME>/common/nodemanager
directory the first time that Node Manager starts up after the installation of
Oracle WebLogic Server. Values supplied on the command line override the values
in nodemanager.properties.
nodemanager.properties
is created in the directory specified in NodeManagerHome,
where NodeManagerHome
is <WL_HOME>/common/nodemanager.
If NodeManagerHome
is not defined, nodemanager.properties
is created in the current directory.
Each
time you start a Node Manager, it looks for nodemanager.properties
in the current directory, and creates the file if it does not exist in that
directory. However, you cannot access the file until the Node Manager has
started up once.
In
many environments, the SSL-related properties in nodemanager.properties
may be the only Node Manager properties that you must explicitly define.
However, nodemanager.properties
also contains non-SSL properties that you might need to specify, depending on
your environment and preferences. For example:
•For
a non-Windows installation, it might be appropriate to specify the StartScriptEnabled
and NativeVersionEnabled
properties.
•If
a Node Manager runs on a multihomed system, and you want to control the address
and port that it uses, define ListenAddress
and ListenPort.
Configuring
a Script-Based Node Manager
The
SSH Node Manager is a shell script, wlscontrol.sh,
located in <WL_HOME>/common/bin/.
The wlscontrol.sh
file must exist on each machine that hosts the server instances that you want
to control with the Node Manager. This script can be customized to meet
site-specific requirements.
You
must have an SSH client executable on each machine where the Node Manager or a
Node Manager client runs. This script must also be in the path of the user ID
that is running it. Typically, an SSH client is a standard part of a UNIX or
Linux installation.
Configuring
the nodemanager.domains File
The
nodemanager.domains
file specifies the domains that a Node Manager instance controls. Thus,
stand-alone clients do not need to specify the domain directory explicitly.
This
file must contain an entry specifying the domain directory for each domain the
Node Manager instance controls, in this form:
<domain-name>=<domain-directory>
Example:
MedRecDomain=/u01/app/oracle/user_projects/domains/MedRecDomain
When
a user issues a command for a domain, the Node Manager looks up the domain
directory from nodemanager.domains.
This
file provides additional security by restricting the Node Manager client access
to the domains listed in the file. The client can execute commands only for the
domains listed in nodemanager.domains.
If
you create your domain with the Configuration Wizard, the nodemanager.domains
file is automatically created in <WL_HOME>/common/nodemanager.
If necessary, you can manually edit nodemanager.domains
to add a domain.
Defining
the Administration Server Address
If
the listen address for an administration server is not defined, when a Node
Manager starts a managed server, the managed server contacts the localhost for
its configuration information.
Set
the listen address using the Servers > Configuration > General page in
the Administration Console.
Either
the listen port or the SSL listen port, or both must be enabled. This is
necessary for Java-SSL Node Managers only to ensure the correct SSL handshake
between the Node Manager and the administration server. If using SSL, remember
that x.x.x.x is different from localhost,
which is different from wls-sysadm when
it comes to the certificates.
Node
Manager Configuration and Log Files
#
cd /u01/app/oracle/user_projects/domains
#
cd testDomain/servers/testSvr1/data/nodemanager
[root@wls-sysadm]#
ll
total
24
-rw-r--r--
1 oracle oinstall 174 Feb 5 15:56 boot.properties
-rw-r--r--
1 oracle oinstall 6 Feb 5 15:56 testSvr1.lck
-rw-r--r--
1 oracle oinstall 6 Feb 5 15:56 testSvr1.pid
-rw-r--r--
1 oracle oinstall 12 Feb 5 15:56 testSvr1.state
-rw-r--r--
1 oracle oinstall 22 Feb 5 15:56 testSvr1.url
-rw-r--r--
1 oracle oinstall 1052 Feb 5 15:56 startup.properties
#
cd
/u01/app/oracle/product/fmw/11.1.0/wlserver_10.3/common/nodemanager/
#
ll
total
116
-rw-r--r--
1 oracle oinstall 130 Feb 5 15:28 nm_data.properties
-rw-r-----
1 oracle oinstall 166 Feb 5 15:35 nodemanager.domains
-rw-r--r--
1 oracle oinstall 69352 Feb 5 15:56 nodemanager.log
-rw-r--r--
1 oracle oinstall 0 Feb 5 15:55 nodemanager.log.lck
-rw-r--r--
1 oracle oinstall 900 Feb 5 15:55 nodemanager.properties
#
In
managing multiple servers, a Node Manager uses multiple configuration files and
outputs log files to multiple directories.
Configuration Files
Except
where noted, the configuration files apply to both Java-based and script-based
Node Managers.
•nodemanager.properties: This is the configuration file used by
Java-based versions of the Node Manager. This file is located in <WL_HOME>/common/nodemanager,
where <WL_HOME>
is the location in which you installed Oracle WebLogic Server. This file needs
to be updated manually for the lab.
•nodemanager.domains: This file contains mappings between the
names of the domains managed by the Node Manager and their corresponding
directories. This file is located in <WL_HOME>/common/nodemanager.
•nm_data.properties: This file stores the encryption data
that the Node Manager uses as a symmetric encryption key. The data is stored in
an encrypted form. This file is located in <WL_HOME>/common/nodemanager.
•nm_password.properties: This file stores the Node Manager
username and password. This file is located in DOMAIN_HOME/config/nodemanager.
•boot.properties: A Node Manager uses this file to specify
the user credentials when starting a server. This file is located in DOMAIN_HOME/servers/server_name/data/nodemanager.
•startup.properties: Each managed server instance has its own startup.properties
file with properties that control how the Node Manager starts up and controls
the server.
A Node Manager automatically creates this file by using the properties passed to it when the administration server was last used to start the server. This allows a Node Manager client or startup scripts to restart a managed server using the same properties that were last used by the administration server.
These properties correspond to the server startup attributes that are contained in ServerStartMBean and the health-monitoring attributes in ServerStartMBean. This file is located in DOMAIN_HOME/servers/server_name/data/nodemanager.
A Node Manager automatically creates this file by using the properties passed to it when the administration server was last used to start the server. This allows a Node Manager client or startup scripts to restart a managed server using the same properties that were last used by the administration server.
These properties correspond to the server startup attributes that are contained in ServerStartMBean and the health-monitoring attributes in ServerStartMBean. This file is located in DOMAIN_HOME/servers/server_name/data/nodemanager.
•server_name.addr:
server_name.addr
stores the IP address that is added when a server starts or is migrated. This
file is generated after the server IP address is successfully brought online
during migration. server_name.addr
is deleted when the IP address is brought offline.
The server IP address is used to validate remove requests to prevent addresses from being erroneously removed while shutting down the server.
This file is located in DOMAIN_HOME/servers/server_name/data/nodemanager.
The server IP address is used to validate remove requests to prevent addresses from being erroneously removed while shutting down the server.
This file is located in DOMAIN_HOME/servers/server_name/data/nodemanager.
•server_name.lck:
server_name.lck is
generated by each server and contains an internally used lock ID. This file is
located in DOMAIN_HOME/servers/server_name/data/nodemanager.
•server_name.pid:
server_name.pid
is generated by each server and contains the process ID of the server. The Node
Manager checks the process ID generated by the server during crash recovery.
This file is located in DOMAIN_HOME/servers/server_name/data/nodemanager.
•server_name.state: server_name.state
is generated by the server and contains the server’s current state. The Node
Manager monitors the contents of this file to determine the current state of
the server.
Note: Do not delete or alter this file. Without this file, the Node Manager cannot determine the current state of the server.
This file is located in DOMAIN_HOME/servers/server_name/data/nodemanager.
Note: Do not delete or alter this file. Without this file, the Node Manager cannot determine the current state of the server.
This file is located in DOMAIN_HOME/servers/server_name/data/nodemanager.
Log Files
Use
the Node Manager and Oracle WebLogic Server log files to help troubleshoot
problems in starting or stopping individual managed servers.
•nodemanager.log: A Node Manager creates a log file that
is located in NodeManagerHome/nodemanager.log.
This log file stores data about all the domains administered by Node
Manager.
This log file is generated by a Node Manager and contains data for all the domains that are controlled by a Node Manager on a given physical machine. This file is located in <WL_HOME>/common/nodemanager.
The log output is appended to the current nodemanager.log. Log rotation is disabled by default, but can be enabled by setting LogCount in nodemanager.properties.
You can view the Node Manager log file by:
This log file is generated by a Node Manager and contains data for all the domains that are controlled by a Node Manager on a given physical machine. This file is located in <WL_HOME>/common/nodemanager.
The log output is appended to the current nodemanager.log. Log rotation is disabled by default, but can be enabled by setting LogCount in nodemanager.properties.
You can view the Node Manager log file by:
-Opening
the Machines Monitoring Node Manager Log page in the Administration Console
-Using
the WLST nmLog
command
•server_name.out: For each server instance that it
controls, a Node Manager maintains a log file that contains the stdout
and stderr
messages generated by the server instance. If the remote start debug property
is enabled as a remote start property for the server instance, or if the Node
Manager debug
property is enabled, the Node Manager includes additional debug information in
the server output log information.
Note: You cannot limit the size of the log files that a Node Manager creates. Logging to stdout is disabled by default. This file is located in domain_name/servers/<server_name>/logs.
A Node Manager creates the server output log for a server instance in the server instance’s logs directory, with the name, server_name.out, where server_name is the name of the server instance.
You can view the Node Manager log file for a particular server instance by:
Note: You cannot limit the size of the log files that a Node Manager creates. Logging to stdout is disabled by default. This file is located in domain_name/servers/<server_name>/logs.
A Node Manager creates the server output log for a server instance in the server instance’s logs directory, with the name, server_name.out, where server_name is the name of the server instance.
You can view the Node Manager log file for a particular server instance by:
-Selecting
Diagnostics Log Files
-Using
the WLST nmServerLog
command
There is no limit to the number of server
output logs that a Node Manager can create.
Oracle WebLogic Server Log Files
A
server instance that is under the control of a Node Manager has its own log
file, in addition to the log file created by the Node Manager.
You
can view the log file for a server instance by selecting Diagnostics Log Files,
selecting the server log file, and clicking View.