Source: http://www.google.com/patents/US7152185?dq=5960409
Timestamp: 2014-03-14 02:52:14
Document Index: 264250376

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'art 200']

Patent US7152185 - Method for event triggered monitoring of managed server health - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA Node Manager monitors the status of multiple servers. The Node Manager detects server failures, periodically monitors server health status, and performs server maintenance. When the Node Manager detects a server failure, it determines whether or not the server should be restarted. While periodically...http://www.google.com/patents/US7152185?utm_source=gb-gplus-sharePatent US7152185 - Method for event triggered monitoring of managed server healthAdvanced Patent SearchPublication numberUS7152185 B2Publication typeGrantApplication numberUS 10/338,981Publication dateDec 19, 2006Filing dateJan 9, 2003Priority dateFeb 22, 2002Fee statusPaidAlso published asUS20030236880, US20060149993Publication number10338981, 338981, US 7152185 B2, US 7152185B2, US-B2-7152185, US7152185 B2, US7152185B2InventorsRahul Srivastava, Ananthan Bala Srinivasan, Eric M. Halpern, Dean Bernard JacobsOriginal AssigneeBea Systems, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (17), Non-Patent Citations (2), Referenced by (8), Classifications (7), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetMethod for event triggered monitoring of managed server healthUS 7152185 B2Abstract A Node Manager monitors the status of multiple servers. The Node Manager detects server failures, periodically monitors server health status, and performs server maintenance. When the Node Manager detects a server failure, it determines whether or not the server should be restarted. While periodically monitoring servers, the Node Manager may determine how often to trigger a health check, how long to wait for a response, and how to proceed if the server is deemed failed. The Node Manager may be controlled by an Administrative Server directly or by an external administrative agent. An administrative agent may control the Node Manager by interfacing with the Administrative Server. The Node Manager and AS may authenticate each other and encode their communications to each other for increased security.
1. A method for monitoring a server comprising:
providing a monitoring instance to monitor at least one server;
providing a triggering event that causes the monitoring instance to monitor the at least one server;
determining the health status of the at least one server by invoking a servlet located on the server, the servlet configured to return a health status of the server to the monitoring instance;
detecting degenerate health status of the at least one server and determining whether to restart the at least one server upon the detection of the degenerate health;
determining for a server having a health status of degenerated whether any conditions exist that may limit the at least one server from being restarted; and
performing treatment on the server, the treatment corresponding with the health status of the server, by determining a value of an auto-kill parameter, the value specified in the auto-kill parameter corresponding to whether the monitoring instance will automatically kill a server if the server is deemed failed.
2. The method of claim 1 wherein providing a triggering event includes determining a period of time has elapsed.
3. The method of claim 1 wherein providing a triggering event includes receiving a signal from an entity external to the monitoring object.
4. The method of claim 1 wherein determining the health status of a server further comprises:
transmitting a query signal to the server to determine the serve's health status; and
determining whether the server responds to the query signal.
5. The method of claim 4 wherein determining whether the server responds to the query signal includes waiting a specified period of time before determining the server has not responded to the query signal.
6. The method of claim 1 wherein determining the health status of a server further comprises:
transmitting a query signal to the server to determine the server's health status; and
receiving the server's response to the query signal; and
determining the server's health status based upon the server's response.
7. The method of claim 1 wherein performing treatment includes terminating the server if the server is deemed failed.
8. The method of claim 1 further comprising controlling the functionality of the monitoring instance by an administration server.
9. The method of claim 8 further comprising communicating between the monitoring instance and administration server using encoding.
10. The method of claim 1 wherein determining the health status of the at least one server is implemented using java language programming.
11. The method of claim 10 wherein the java language programming includes a java method instance.
12. The method of claim 1 wherein performing treatment on the server is implemented using java language programming.
13. The method of claim 12 wherein the java language programming includes a java method instance.
14. The method of claim 1 wherein the java servlet includes an asynchronous servlet configured to return the health status to the monitoring instance upon the occurrence of an event.
15. The method of claim 1 wherein providing a triggering event includes:
determining whether an interval period has elapsed, the interval period corresponding to a time between successive health checks performed on a server, wherein a value specified in a health check interval parameter corresponds to the interval period.
16. The method of claim 15 wherein the health check interval parameter may be accessed and set.
17. The method of claim 1 wherein providing a triggering event includes:
determining whether a timeout period has elapsed, the timeout period corresponding to a time the monitoring instance will wait for a response to a health check query performed by the monitoring instance to the server, wherein a value specified in a health check timeout parameter corresponds to the timeout period.
18. The method of claim 17 wherein the health check timeout parameter may be accessed and set.
19. The method of claim 15 wherein the health check interval parameter may be accessed and set.
continuing operations with the server in a degenerated health status, if it is determined not to restart the server.
restarting the server if it is determined to do so. Description
CLAIM TO PRIORITY The present application claims the benefit of priority under 35 U.S.C. � 119(e) to U.S. Provisional Patent Application entitled �ECS NODE MANAGER FOR ENSURING HIGH AVAILABILITY SERVER AND APPLICATION�, Patent Application No. 60/359,009, filed on Feb. 22, 2002, which application is incorporated herein by reference.
U.S. patent application Ser. No. 10/339,469, entitled �METHOD FOR AUTOMATIC MONITORING OF MANAGED SERVER HEALTH�, filed on Jan. 09, 2003, currently pending, which claims priority to provisional United States Patent Application entitled �ECS NODE MANAGER FOR ENSURING HIGH AVAILABILITY SERVER AND APPLICATION�, Patent Application No. 60/359,009, filed on Feb. 22, 2002;
U.S. patent application Ser. No. 10/339,144, entitled �SYSTEM FOR MONITORING MANAGED SERVER HEALTH�, filed on Jan. 09, 2003 currently pending, which claims priority to provisional U.S. Patent Application entitled �ECS NODE MANAGER FOR ENSURING HIGH AVAILABILITY SERVER AND APPLICATION�, Patent Application No. 60/359,009, filed on Feb. 22, 2002;
U.S. patent application Ser. No. 10/340,496, entitled �METHOD FOR INITIATING A SUB-SYSTEM HEALTH CHECK�, filed on Jan. 10, 2003 currently pending, which claims priority to provisional U.S. Patent Application entitled �Server Self-Health Monitor�, Patent Application No. 60/359,010, filed on Feb. 22, 2002;
U.S. patent application Ser. No. 10/340,227, entitled �METHOD FOR MONITORING A SUB-SYSTEM HEALTH�, filed on Jan. 10, 2003, currently pending, which claims priority to provisional U.S. Patent Application entitled �Server Self-Health Monitor�, Patent Application No. 60/359,010, filed on Feb. 22, 2002; and
U.S. patent application Ser. No. 10/340,002, entitled �SYSTEM FOR MONITORING A SUBSYSTEM HEALTH�, filed on Jan. 10, 2003, currently pending, which claims priority to provisional U.S. Patent Application entitled �Server Self-Health Monitor�, Patent Application No. 60/359,010, filed on Feb. 22, 2002.
FIELD OF INVENTION The present invention relates generally to managing a network of servers, and more particularly to monitoring the health of a network of servers.
BACKGROUND OF THE INVENTION As computer and computer systems have evolved over the years, the processes they implement have evolved in their complexity. One approach to implementing computer processes to solve more complex problems is to assign a number of computers to handle different parts of a process. Each part or task may be handled by different computers, computer objects, applications, or servers, hereafter referred to collectively as servers. These servers make up a distributed network. Within the network, different servers may handle functions such as management, data base maintenance, accessibility, server boot-up, shut-down, and so forth.
SUMMARY OF THE INVENTION In one embodiment of the present invention, a Node Manager (NM) monitors the status of multiple servers. The NM detects server failures, periodically monitors server health status, and performs server maintenance. When the NM detects a server failure, it determines whether or not the server is restartable. If the server is restartable, the NM checks to see if any other conditions exist that limit the server from being restarted. If no other conditions exist, the server is restarted. If the failed server is not restartable or other conditions exist preventing the server from being restarted, the failed server is not restarted.
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram of several nodes having servers in a self health monitoring system in accordance with one embodiment of the present invention.
DETAILED DESCRIPTION A self health monitoring system may be composed of several nodes. A node may be a single physical machine or take some other form. In one embodiment of the present invention, each node has a Node Manager (NM), an Administration Server (AS), and several other managed servers or server instances. The AS and NM may send and transmit messages to each other. The NM may also send and transmit messages with the other servers located on the node.
FIG. 1 depicts a self health monitoring system 100 in accordance with one embodiment of the present invention. As shown, system 100 includes a first node 10, a second 20, and a third node 30. Each node may contain an AS 11, 21, and 31, and an NM 12, 22, and 32, respectively. In each node, the AS communicates with the NM. In one embodiment of the present invention, the AS and the NM communicate through a (SSL) secure socket layer connection. Each node also contains at least one managed server. In one embodiment, these managed servers may be composed of server instance processors or logic servers all located on one hardware machine. Hereinafter, the term �server� shall be understood to include server instance processors, server instance logic, and other managed servers. A node may be one physical machine with servers that communicate with other servers on the same machine. As shown in FIG. 1, node 10 includes servers 13�15, node 20 includes servers 23�25, and node 30 includes servers 33�35. An NM may communicate with the servers within the particular NM's node. For example, NM 12 can communicate with servers 13, 14, 15, all within node 10. In one embodiment, the NM communicates with the servers within its node through a secure socket layer connection.
In accordance with one embodiment of the present invention, the operation of an automatic monitoring system for detecting failed servers in the self health monitoring system of FIG. 1 is shown in flow chart 200 of FIG. 2 and described as follows. The operation of an NM starts at step 205. Next, the NM undergoes start-up and configuration operations in step 210. In one embodiment of the present invention, the NM receives instructions from an AS at start-up. The AS may instruct the NM to start an instance on a local machine. The AS may also instruct the NM to provide information to the AS regarding servers previously monitored during previous monitoring periods by the NM. The NM may assume that all of the monitored servers are alive upon NM startup and sets each server state to �unknown�. In step 220, the NM begins monitoring a server. In one embodiment, the server is monitored over an SSL connection established with the server. In another embodiment, the server is monitored over a plain text protocol connection or some other type of connection.
This parameter specifies whether the servers are restartable or not. In one embodiment, the default is true.
Certain methods implemented in java may be used to access or modify the parameter examples listed above. Examples of these methods include boolean getAutoRestartEnabled( ), void setAutoRestartEnabled(boolean), int getRestartlntervalSeconds( ), void setRestartlntervalSeconds(int), int getRestartMax( ), and void setRestartMax(int).
In addition to detecting the failure of a server, the NM may monitor the health of a server or perform maintenance on a server. The NM may monitor server health or perform server maintenance without detecting a change or degradation in the health status of the server. Server maintenance and monitoring may be performed simultaneously on multiple servers at any time. The simultaneous monitoring and maintenance may be synchronous or asynchronous. The operation of a system for monitoring the health of a server with a NM in accordance with one embodiment of the present invention is shown in diagram 300 of FIG. 3 and described as follows. Health monitoring system operation 300 starts off with a start step 310. Next, the system determines whether the NM should begin monitoring a server in step 320. If the system determines the NM should monitor the particular server, operation continues to step 330. If the system determines the particular server should not be monitored at the current time, the NM will not monitor the current server. In one embodiment, a server will not be monitored until a period of time has passed since the server has been restarted. In this case, a monitor delay parameter will determine the period of time the NM shall wait before monitoring the restarted server. The delay parameter maybe stored by the AS, NM, or the server itself. The delay parameter may correspond to a particular server or several servers. In one embodiment of the present invention, the value of the delay parameter may be modified at server runtime.
In step 340, the NM queries a server for it's health status. In one embodiment of the present invention, the NM invokes a java servlet located on the server to return the server's health status to the NM. This java servlet is an asynchronous servlet that will return the server's health information upon the occurrence of a particular event. In one embodiment, the event is the elapse of a period of time. The NM may inquire about the server's health status by communicating with the server itself or a server self health monitor application running on the server. The query may be transmitted over a TCP connection established between the NM and server or in some other manner. After querying the server for it's health status, the NM determines if a response is received from the server in step 350. In one embodiment, there are at least three possible response scenarios between the NM and the server subject to the NM's inquiry. In the first scenario, the server may be unable to receive the NM's query. The server may be too busy to accept a connection from the NM. In another scenario, the server may have failed and be unable to accept an NM connection request. In either case, the NM may throw an IOException and consider the server as �failed�. The NM would then set an internal value of the server state to �failed�. In the final scenario, no response is received from the server although the NM and server have established an initial connection. In this case, the NM will wait for a response from the server for a specified period of time. In one embodiment, a timeout parameter may specify the period of time the NM will wait for a response from the server. Until the length of time specified in the timeout parameter has transpired, the NM will continue to wait for a response as indicated in the loop of steps 350 and 360. If the NM has not received a response from the server in step 350 and the NM has determined not to wait any longer to receive a response in operation 360, operation continues to step 370 where the server is deemed failed. In one embodiment, the NM may attempt to inquire about the delay of the response or resend a health inquiry to the server before proceeding from to 370. In this embodiment, the NM may proceed to step 350, 360, or 380 depending on the result of the delay inquiry or the health inquiry.
If the NM does receive a response in step 350, operation flows to step 380 where the NM interprets the server's response. The NM interprets the server's response to determine if the server is healthy. If the NM determines the server is healthy from the response received by the server, operation flows to step 330 where the NM waits for another health check to be triggered. If the NM determines that the server is not healthy in step 380, operation continues to step 370. In step 370, the NM deems the server has failed. In one embodiment, the NM sets a parameter indicating the state of the particular server to �failed�. The parameter may be stored internally within the NM, in the AS, or at some other memory location. Once deemed failed, operation continues to step 390 where the NM determines whether to terminate the server. In one embodiment, the NM contains an auto-terminate parameter. The auto-terminate parameter may relate to a single server or multiple servers at once. A user may set a value for the auto-terminate parameter or the parameter may be preset by the system. If the auto-terminate parameter indicates the server should not be terminated upon server failure, then operation continues to step 396. In one embodiment of the present invention, the system enters a message in a log indicating the failed status of the server and that the server is not to be restarted. After step 396, system operation proceeds to step 330. If the auto-terminate parameter indicates the server should be terminated upon server failure in step 390, then operation continues to step 392. The failed server is terminated in step 392. In one embodiment of the present invention, an entry is made to a log indicating the server is deemed failed and that the server was terminated. Monitoring of the terminated server ends in step 394. Once the server is terminated, the automatic detection system of FIG. 1 may detect the terminated server at step 230. The NM may then proceed to determine whether to restart the server as shown in FIG. 1.
HealthChecklntervalSeconds=<number of seconds>
This parameter specifies the interval of time (in seconds) between which periodic scans are done by NM to check if Servers are Failed. In one embodiment, the default is 180 seconds.
This parameter specifies the length of time (in seconds) the Node Manager will wait for a response to the health check query after which it will deem the monitored server Failed. In one embodiment, the default is 60 seconds.
This parameter specifies if a Server is deemed Failed, this parameter will control whether NM will kill the Server or not. In one embodiment, the default is false.
The time that a server takes to startup depends upon the applications being deployed on it. The NM will wait for a server to complete its startup before the NM starts monitoring the server. This parameter specifies the length of time (in seconds) the NM will wait before starting its monitoring of the server. In one embodiment, the default is 120 seconds.
The HealthChecklntervalSeconds and HealthCheckTimeoutSeconds and parameters can be defined per NM and on the NM command line. The AutoKillIfFailedEnabled and HealthCheckStartDelaySeconds parameters can be defined per server instance and can be modified at runtime via the Admin Console. These new parameters for the Server will be modifiable at runtime via the Admin Console. In conjunction with the parameter examples above, methods implemented in java code can be added to the server MBean and may be used to access or modify the parameters. Examples of these java methods include boolean getAutoKillIfFailedEnabled( ), void setAutoKillIfFailedEnabled(boolean), int getHealthCheckStartDelaySeconds( ), and void setHealthCheckStartDelaySeconds (int secs).
java.io.Reader getlogs(Server MBean server, String type) throws NodeManagerException; This method get logs from the NM for the specified server. The type is either �WL_output� or �WL_Error�. It then returns the reader to local log file containing output of executed command. The method throws NodeManagerException if any error occurs.
string get state (ServerMBean server) throws NodeManagerException; This method queries the NM for its view of the specified server state. It is used when the server does not respond to queries to its ServerRuntimeMBean. The method will return �unknown� if NM is either not monitoring the server or does not have any knowledge of the server. It then returns the reader to local log file containing output of executed command. The method throws NodeManagerException if any error occurs.
In another embodiment, MBeans may provide an interface for JMX clients to access the functionality of the NM. In this case, the MBeans for JMX client interfacing may have a different interface than the Server configuration MBeans. Operations such as �start� and �shutdown� may return precise information on their success or failure. They will throw an exception if the operation fails. All operations on the Node Manager Runtime MBeans may be blocking. A TaskMBean interface may be provided around the Server Lifecycle MBeans to provide an asynchronous interface to JMX clients. JMX clients can make use of the NM functionality to perform a wide variety of Server lifecycle and health monitoring control operations. Detailed below are the interactions between these two entities during each of the Server Lifecycle state transitions. Admin console, weblogic.Admin command line utility and other Admin Clients will be effecting these state transitions by invoking methods on the ServerLifecycleRuntimeMBean.
start( )[SHUTDOWN→RUNNING]startInStandby( )[SHUTDOWN→STANDBY]
shutdown( )[STANDBY→SHUTDOWN]
Once the session keys are generated in step 530, the NM and AS may engage in an authentication process at step 540. In one embodiment, both the NM and AS are authenticated using a shared secret. One method of authenticating both the NM and AS in accordance with the present invention is as follows. First, both the NM and AS will generate a fingerprint. In one embodiment, the fingerprint maybe a 128 bit MD5 message digest created using the send and receive session keys already negotiated. Next, the AS will generate a challenge, encrypt the challenge and fingerprint, and send the encrypted challenge and fingerprint to the NM. In one embodiment, the challenge may be a 64 bit random number. Next, the NM will receive and decrypt the challenge and fingerprint from the AS. The information may be encrypted and decrypted using the AS's password. If the information received by the NM is decrypted and does not match the NM's fingerprint, the NM will reject the authentication request by the AS. Next, the NM will encrypt the challenge received from the server, the session key generated by the NM, and the fingerprint generated by the NM. The NM will then send the encrypted challenge, session key, and fingerprint to the AS. The AS will receive and decrypt the information received from the NM. Upon decrypting the received information, the AS will compare the received challenge and fingerprint to it's own challenge and fingerprint. If either the fingerprints or the challenges do not match, the AS will reject the authentication request from the NM. If the comparisons performed by the AS and NM reveal matching information, then the authentication requests will be accepted. The encryption and authentication process then ends at step 550. The encryption by the AS and NM may be done using a DES encryption method or some other method suitable for the particular requirements of the system.
This argument specifies the minimum encryption level the process will accept. Possible values are 0, 40, 128. In one embodiment, the default value is 0.
This argument specifies the maximum encryption level the process will accept. Possible values are 0, 40, 128. In one embodiment, the default value is 128.
This argument sets an Authentication Protocol. In one embodiment, the a value of 1 enables the Authentication Protocol and the default is 0.
This argument specifies the key to be used to decrypt the encrypted NM passwords stored in the configuration file. The key must be specified if WebLogic.management.enableChannelBinding is set to 1.
This argument sets an Authentication Protocol enable. In one embodiment, a value of 1 enables the Authentication Protocol and the default is 0.
This argument specifies the NM password. The NM password must be specified if WebLogic.nodemanager.enableChannelBinding is set to 1.
This argument specifies the Admin Server password. Must be specified if WebLogic.nodemanager.enableChannelBinding is set to 1.
In one embodiment, certain services are required by the administrator for the alternate NM to operate properly. One such service is a ProcessControl (�PC�) service. The PC service operates to start, kill and restart managed servers on the local node. The service can be hosted by the AS and by the NM on the other nodes. Restart capability is provided to internal and external clients via Runtime MBeans. Another service is the HealthMonitoring (�HM�) service. The HS service monitors state and other runtime attributes of managed servers on local or remote nodes. Either the AS or an individual NM can host the HM service. Server health information is provided to internal and external clients via Runtime MBeans.
The alternate NM may include a �watchdog� service. The watchdog service operates to monitor the NM on platforms where operating system monitoring is not available, such as non-NT and Solaris platforms. The watchdog service may be configured to spawn the NM when it performs startup, thereby allowing administrators to manually start just one process. In one embodiment, a system could use a watchdog service to bootstrap the NM service on a local node upon command of an AS. This watchdog service configuration would eliminate manual configuration of the NM on each remote node and allow runtime configuration through configuration MBeans implemented in java. For Solaris and NT systems, the NM maybe used as the operating system in one embodiment of the present invention. In this case, the NM may be installed on a node in conjunction with other software and can be started manually.
APPENDIX 1 Product Perspective (O)
NM will periodically monitor Servers running on the local machine and will automatically detect and restart Failed Servers. This detectionand restart will occur as soon as possible after the Server is deemed to be Failed.
External administrative clients (3rd party application monitors, HA frameworks, etc.) need to be able to start and kill Servers using the NM. They should be able to do this progranimatically without using the admin console.
public interface NodeManagerRuntimeMBean extends WebLogic management.runtime.RuntimeMBean
java.io.Reader start (ServerMBean server) throws NodeManagerException;
Instruct NM to stop monitoring the specified server. Returns Reader to local log file containing output of executed command. Throws NodeManagerException if any error occurs. java.io.Reader getLogs(ServerMBean server, String type) throws NodeManagerException;
Get logs from the NM for the specified server. The type is either �WL_output� or �WL_error�. Returns Reader to log retrieved. Throws NodeManagerException if any error occurs. String getState(ServerMBean server) throws NodeManagerException; Query the NM for its view of specified server's state. Used when server does not respond to queries to its ServerRuntimeMBean. Will return �Unknown� if NM is either not monitoring or does not have any knowledge of the server. Throws NodeManagerException if any error occurs. 5.1 Node Manager-Managed Server communication
It assumes that all of the monitored Servers are alive when it starts up. It assumes no knowledge of their current States (i.e., it sets its view of their State to �Unknown�). 2. NM invokes the NMCommandServlet deployed on the Server. This is an asynchronous Servlet that will return the Server's health information after HealthCheckIntervalSeconds have elapsed.
3. One of the following happens when NM invokes the Servlet:
Server has crashed or is not running Server too busy to accept TCP connection Server has Failed, unable to accept TCP connection Transient IO exception All cases are treated as if Server has Failed. NM sets its internal value of Server state to �Failed�. To handle �false negatives�, NM kills the Server. If the Server's AutoKillIfFailedEnabled parameter is �true�, NM sets its internal value of Server state to �Failed� and kills the Server. If AutoKillIfFailedEnabled is false, NM sets it internal value of Server state to �Failed Not Restartable�, logs a warning and continues. 3.3 Server returns its State value after HealthCheckIntervalSeconds.
No action. 3.3.2 Server State is Failed
If the Server's AutoKillIfFailedEnabled parameter is �true�, NM sets its internal value of Server state to �Failed� and kills the Server. If AutoKillIfFailedEnabled is false, NM sets it internal value of Server state to �Failed Not Restartable�, logs a warning and continues. 4. In the next iteration, if NM sees that its interval value of Server state is �Failed�, it will try to restart the Server.
NM checks the Server's AutoRestartEnabled parameter. If it is true and less than RestartMax restarts have been done in the current RestartIntervalSeconds window, NM will restart the Server. If Server has already been restarted RestartMax times in the current RestartIntervalSeconds window, NM will wait till the next RestartIntervalSeconds window begins before doing another restart. If AutoRestartEnabled is false, NM will not restart the Server. 5.2.1 Server State transition notifications
When the NM starts a Server, there is currently no mechanism to determine if the Server started successfully or not. Now, the Server will inform the NM once it has entered a Standby State. If a Server fails, NM will discover this only in the next iteration of its health-monitoring query. Now, the Server will inform the NM as soon as it has entered a Failed State. Passing the NM's listening address to the Server when the latter is starting up will facilitate this communication. Impact on JMX clients p1 In WLS 6.1, JMX clients (like the Admin Console) performed Server lifecycle operations by invoking methods on the Server configuration MBeans. In Acadia, these clients will be accessing the new Server Lifecycle MBeans for this purpose. These new MBeans have a different interface than the Server configuration MBeans. Detailed below are the changed semantics: Operations such as �start� and �shutdown� will now return precise information on their success or failure. They will throw an exception if the operation fails. Look at [SLC] for details. All operations on the Node Manager Runtime MBeans are now blocking. A TaskMBean interface is being provided around the Server Lifecycle MBeans to provide an asynchronous interface to JMX clients. The new Server Lifecycle and Node Manager Runtime MBeans provide a rich set of functionality. JMX clients can make use of these to perform a wide variety of Server lifecycle and health monitoring control operations. Look at [SLC] and section 5.2.3 above for details on this. 5.3 NM-Server Lifecycle Interactions Detailed below are the interactions between these two entities during each of the Server Lifecycle state transitions. Admin console, weblogic.Admin command line utility and other Admin Clients will be effecting these state transitions by invoking methods on the ServerLifecycleRuntimeMBean. 1. start( ) [SHUTDOWN->RUNNING]startInStandby( ) [SHUTDOWN->STANDBY]ServerLifecycleRuntimeMBean hosted on the Admin Server will invoke the start( ) or startInStandby() methods on the corresponding NodeManagerRuntimeMBean.
2. shutdown( ) [STANDBY->SHUTDOWN]
ServerLifecycleRuntimeMBean hosted on the Managed Server will return the State attribute of the Server. ServerLifecycleRuntimeMBean hosted on the Admin Server will invoke the getState( ) method on the ServerLifecycleRuntimeMBean hosted on the Managed Server. If this operation times out, it will then invoke the getState( ) method on the NodeManagerRuntimeMBean. 6. Diffie-Hellman based Authentication/Encryption scheme
Admin Server begins the communication session. A NM receives the initial connection. Both processes are aware of the encryption feature, and have two configuration parameters. The first configuration parameter is the Minimum encryption level a process will accept. It is expressed as a key length: 0, 40, or 128 bits. The second configuration parameter is the Maximum encryption level a process is willing to support. It also is expressed as a 0, 40, or 128 bit key size. For convenience, this document will denote the two parameters as (mm, max). So (40, 128) means a process will accept at least 40-bit encryption but desires 128-bit if possible. Encryption parameters negotiated are for the lifetime of the communication session. 6.2.2 Encryption Key Size Negotiation
Next the two processes jointly agree on the largest key size acceptable to both. It maybe that there is no overlap, in which case network link establishment fails (with an appropriate log error message). This table shows the outcome for all possible combinations of mm/max parameters:
6.2.3 Session Key Agreement
The actual Diffie-Hellman parameters to bum-in for the first release of this feature are shown in Appendix A.
The actual bits disclosed in the clear must be used by the Admin Server. If they do not agree with the locally computed Diffie-Hellman session key, or are not supplied as expected, Admin Server will generate a log error message and terminate the connection. Both the processes implicitly agree to permute their Diffie-Hellman session key when 40-bit encryption is negotiated, as shown below. This prevents a network attacker from tampering with messages and tricking the Admin Server into a 128-bit session when 40-bit was the NM s negotiation result. 6.2.7 Authentication Protocol
Both processes will generate a 128-bit MD5 message digest (fingerprint) using the send and receive session keys negotiated (see Section 6.2.3 above) Admin Server will generate a 64-bit random number (challenge). It will then DES-encrypt the challenge and the fingerprint using its password as the key and send this to the NM. NM will decrypt the received message with the Admin Server s password. If the fingerprints don t match, it will reject the authentication request. NM will generate a 64-bit session key. NM will then DES-encrypt the previously-received challenge, the generated session key and the fingerprint using its password as the key and send this to the Admin Server. Admin Server will decrypt the received message with the NM s password. It will check the received challenge and fingerprint with its local values. If either doesn'tt match, it will reject the authentication request. If the above sequence is completed successfully, Admin Server and NM will be considered authenticated with each other.
WebLogic.management.minEncryptionBits=<number>the Minimum encryption level the process will accept. Possible values are 0, 40, 128. Default value is 0. WebLogic.management.maxEncryptionBits=<number>the Maximum encryption level the process will accept. Possible values are 0, 40, 128. Default value is 128. WebLogic.management.enableChannelBinding=0|1 a value of 1 enables the Authentication Protocol (Section 5.2.7). Default is 0. WebLogic.management.passwordKey=<string>key to be used to decrypt the encrypted NM passwords stored in the configuration file. It must be specified if WebLogic.management.enableChannelBinding is set to 1. The utility WebLogic.wtc.gwt.genpasswd will be used to encrypt NM passwords to be stored in the configuration file.
WebLogic.nodemanager.minEncryptionBits=<number>the Minimum encryption level the process will accept. Possible values are 0, 40, 128. Default value is 0. WebLogic. nodemanager.maxEncryptionBits=<number>the Maximum encryption level the process will accept. Possible values are 0, 40, 128. Default value is 128. WebLogic.nodemanager.enableChannelBinding=0|1 a value of 1 enables the Authentication Protocol (Section 5.2.7). Default is 0. WebLogic. nodemanager.password=<string>the NM s password. Must be specified if WebLogic.nodemanager.enableChannelBinding is set to 1. WebLogic.nodemanager.adminServerPassword <string>the Admin Server s password. Must be specified if WebLogic.nodemanager.enableChannelBinding is set to 1. These new arguments will be modifiable at runtime via the Admin Console.
7.5 Alternate Node Manager
In one embodiment of the invention, an alternate type of node manager architecture is used. The alternate node manager may be operable to achieve at least the following functions:
Aggregation of administrative actions and information in NM for access by 3rd party application monitors and HA frameworks using standard JMX interfaces Internal interactions with admin console, cluster group leader, etc. using standard JMX interfaces Described below are some of the design points of the new NM architecture.
Summary of New NM Architecture
Services required by Administrator/App Monitor
1. ProcessControl (�PC�) service
start, kill and restart Managed Svrs (�MS�) on local node will be hosted by Admin Svr (�AS�) will be hosted by NM on other nodes provide restart capability to internal and external clients via Runtime MBeans 2. HealthMonitoring (�HM�) service
monitor State and other runtime attributes of MS on local or remote node can be hosted either by AS or individual NMs provide this info to internal and external clients via Runtime MBeans New NM charactertistics
0. hosted on stripped-down MS
registered as a MS with the AS (in config.xml) 1. Configuration
all config passed as command line args (like for today's NM) startup independent of AS no Config MBeans for runtime configuration changes (like for today's NM) 2. WatchDog (�WD�)
reqd to mon NM on platforms where OS monitoring not avl (non NT and Solaris platforms) 1 WD per NM can spawn the NM when started so Admins will have to manually start just 1 process 3. NM may be the OS service on NT and Solaris
installed when installing WLS on node can also be started manually 4. Interoperability
could have 1 NM per Domain
(Security) won't have to manage multiple Certificates NM must be of highest release wrt all MSs on node 5. If NM is not used:
won't get PC svc on remote nodes HM svc will won't be able to restart remote MSs better scalability if HM svc hosted on NMs 6. Additional Enhancements
make NM highly preferable (advantages listed in #5) use WD to bootstrap NM on local node upon AS's command (will eliminate manual config of NM on each remote node and allow runtime config via Config MBeans) use NM to aggregate Cluster heartbeats for all cluster members on local node (broader implications-Eric/Mesut/Dean) make NM a surrogate AS? (broader implications) Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5432715Jun 29, 1993Jul 11, 1995Hitachi Process Computer Engineering, Inc.Computer system and monitoring methodUS5500940Apr 25, 1994Mar 19, 1996Hewlett-Packard CompanyMethod for evaluating failure in an electronic data storage system and preemptive notification thereof, and system with component failure evaluationUS5638514Aug 30, 1993Jun 10, 1997Fujitsu LimitedCentralized supervisory system for supervising network equipments based on data indicating operation states thereofUS5819028Apr 16, 1997Oct 6, 1998Bay Networks, Inc.Method and apparatus for determining the health of a networkUS6085243Dec 13, 1996Jul 4, 20003Com CorporationDistributed remote management (dRMON) for networksUS6170067Oct 1, 1997Jan 2, 2001Micron Technology, Inc.System for automatically reporting a system failure in a serverUS6182157Sep 19, 1996Jan 30, 2001Compaq Computer CorporationFlexible SNMP trap mechanismUS6349335Jan 8, 1999Feb 19, 2002International Business Machines CorporationComputer system, program product and method for monitoring the operational status of a computerUS6553515Sep 10, 1999Apr 22, 2003Comdial CorporationSystem, method and computer program product for diagnostic supervision of internet connectionsUS6631409Dec 23, 1998Oct 7, 2003Worldcom, Inc.Method and apparatus for monitoring a communications systemUS6681342Jul 23, 2001Jan 20, 2004Micron Technology, Inc.Diagnostic and managing distributed processor systemUS6738811Mar 31, 2000May 18, 2004Supermicro Computer, Inc.Method and architecture for monitoring the health of servers across data networksUS6785840 *Aug 31, 2000Aug 31, 2004Nortel Networks LimitedCall processor system and methodsUS20020016911Jul 9, 2001Feb 7, 2002Rajeev ChawlaMethod and system for caching secure web contentUS20030037289 *Aug 8, 2001Feb 20, 2003Navjot SinghFault tolerance software system with periodic external self-test failure detectionUS20030061340Sep 25, 2001Mar 27, 2003Mingqiu SunNetwork health monitoring through real-time analysis of heartbeat patterns from distributed agentsUS20030069953 *Sep 28, 2001Apr 10, 2003Bottom David A.Modular server architecture with high-availability management capability* Cited by examinerNon-Patent CitationsReference1Java Management Extensions (JMX) 1999, Sun Microsystems.2M.H. Guiagoussou, A Java API for Advanced Faults Management, 2001, IEEE.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7509413 *Nov 24, 2003Mar 24, 2009International Business Machines CorporationTool for displaying JMX monitoring informationUS7532577 *Feb 8, 2005May 12, 2009Samsung Electronics Co., Ltd.Managing transmission control protocol (TCP) connectionsUS7543058 *Jun 30, 2008Jun 2, 2009International Business Machines CorporationDefining and implementing configuration standards for facilitating compliance testing in an environmentUS8082553 *Jun 25, 2007Dec 20, 2011International Business Machines CorporationClient management of java management extensions (JMX) Mbean stateUS8392496 *Dec 21, 2009Mar 5, 2013Watchguard Technologies, Inc.Cluster architecture for network security processingUS8484213 *Aug 31, 2005Jul 9, 2013International Business Machines CorporationHeterogenous high availability cluster managerUS8582447 *Jul 28, 2009Nov 12, 2013Fujitsu LimitedLoopback device and mirroring methodUS20100162383 *Dec 21, 2009Jun 24, 2010Watchguard Technologies, Inc.Cluster Architecture for Network Security Processing* Cited by examinerClassifications U.S. Classification714/24, 714/E11.186, 714/25International ClassificationG06F11/32, G06F17/30Cooperative ClassificationG06F11/326European ClassificationG06F11/32S2ELegal EventsDateCodeEventDescriptionOct 15, 2010ASAssignmentFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BEA SYSTEMS, INC.;REEL/FRAME:025192/0244Effective date: 20101008Owner name: ORACLE INTERNATIONAL CORPORATION, CALIFORNIADec 22, 2009FPAYFee paymentYear of fee payment: 4Jun 5, 2007CCCertificate of correctionJan 16, 2004ASAssignmentOwner name: BEA SYSTEMS, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SRIVASTAVA, RAHUL;SRINIVASAN, ANANTHAN BALA;HALPERN, ERIC M.;AND OTHERS;REEL/FRAME:014890/0157;SIGNING DATES FROM 20030404 TO 20031213RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google