Managing server processes with proxy files

Computer-implemented methods and systems are provided for detecting a failed server. The computer-implemented method includes creating a proxy file for each server of a plurality of servers in an active state and assigning a timestamp to each proxy file of each server of the plurality of servers. The computer-implemented method further includes permitting each server to inspect each timestamp of each proxy file of each server of the plurality of servers and determining whether the timestamp assigned to each proxy file of each server of the plurality of servers exceeds a predetermined threshold. The computer-implemented method further includes, in response to a timestamp of a proxy file of a failed server exceeding the predetermined threshold, allowing another server of the plurality of servers to complete remaining work of the failed server.

BACKGROUND

Technical Field

The present invention relates generally to computing systems, and more specifically, to systems and methods for managing server processes with proxy files.

Description of the Related Art

The client/server model of distributed computing operates to fulfill user needs by splitting functions between “client” tasks and “server” tasks performed by computer hardware and software resources that are organized into a “network” for communication with each other. Using this model, a “client” program sends message requests to a “server” program to obtain data and/or processing action according to a communication “protocol” and the server completes the processing transaction by carrying out the request or deferring it to another time or by indicating that it cannot be fulfilled. This model allows clients and servers to be operated independently of each other in a computer network by using different hardware and operating systems.

A “proxy server” is often used in handling client requests for transactions to be completed by other network “application servers” which are capable of performing the data processing actions required for the transaction but are not accessed directly by the client. If a processing transaction is not successfully completed upon initial transmission of a message, the client can send retransmissions of the message to an application server using an “arrayed cluster” of proxy servers.

SUMMARY

In accordance with one or more embodiments, a computer-implemented method for detecting a failed server is provided. The computer-implemented method includes creating a proxy file for each server of a plurality of servers in an active state, assigning a timestamp to each proxy file of each server of the plurality of servers, and permitting each server to inspect each timestamp of each proxy file of each server of the plurality of servers. The computer-implemented method further includes determining whether the timestamp assigned to each proxy file of each server of the plurality of servers exceeds a predetermined threshold, and in response to a timestamp of a proxy file of a failed server exceeding the predetermined threshold, allowing another server of the plurality of servers to complete remaining work of the failed server.

In accordance with one or more embodiments, a system for detecting a failed server is provided. The system includes a memory and a processor in communication with the memory, wherein the computer system is configured to create a proxy file for each server of a plurality of servers in an active state, assign a timestamp to each proxy file of each server of the plurality of servers, permit each server to inspect each timestamp of each proxy file of each server of the plurality of servers, determine whether the timestamp assigned to each proxy file of each server of the plurality of servers exceeds a predetermined threshold, and in response to a timestamp of a proxy file of a failed server exceeding the predetermined threshold, allow another server of the plurality of servers to complete remaining work of the failed server.

DETAILED DESCRIPTION

The present embodiments are directed to systems and methods for detecting a failed server within a network. Application servers monitor the state of their peer application servers in case they fail, thus leaving incomplete work. When an application server detects a peer application server to have failed, the failed application server is taken over by another application server configured to complete the remaining work or tasks of the failed application server.

In one or more embodiments, systems and methods are presented for detecting a failed application server based on management of a set of files in a dedicated file-system directory. The state of an application server is represented by the presence of a file that represents that application server. The file can act as a proxy for its server.

In one or more embodiments, systems and methods are presented for creating proxy files for each application server of a plurality of application servers. The proxy files of each application server can be stored in a common file system directory. Each application server that is part of a group of application servers owns a proxy file in the file system directory. The proxy file is deleted or removed when the application server it represents is shut down or deactivated.

In one or more embodiments, each application server periodically updates the timestamp on its proxy file. Additionally each application server periodically inspects the timestamps on the proxy files that belong to the other application servers, i.e., the peers in the group of application servers. If the timestamp of a proxy file is determined to be too “old” or “out-of-date,” then the application server represented by the proxy file is considered to have failed. At this point, a peer application server (within the group of application servers) can take ownership of the proxy file and complete any necessary work or tasks for the failed application server. Once the work has been completed, the proxy file for the failed application server can be deleted or removed. Moreover, the process of coordinating access to proxy files can be managed through exclusive file locks to prevent more than one peer application server from attempting to complete work belonging to a failed application server. Thus, each proxy file created or generated can be associated with or assigned to a file lock.

In one or more embodiments, systems and methods for detecting a failure of an application server are presented and fault tolerance among peer servers is enabled by permitting each server to periodically update its own proxy file and check the timestamp of other application servers within a group of application servers. Additionally, if a failure is detected in the absence of a recent timestamp in the file, a takeover can be enabled by a peer application server.

Referring now to the drawings in which like numerals represent the same or similar elements and initially toFIG. 1, a block/flow diagram of an exemplary computing system for detecting a failed application server is presented, in accordance with an embodiment of the present invention.

An exemplary server processing system100for detecting a failed application server to which the present invention may be applied is shown in accordance with one embodiment. The server processing system100includes at least one processor (CPU)104operatively coupled to other components via a system bus102. A cache106, a Read Only Memory (ROM)108, a Random Access Memory (RAM)110, an input/output (I/O) adapter130, a user interface adapter150, and a display adapter160, are operatively coupled to the system bus102.

A first storage device122and a second storage device124are operatively coupled to system bus102by the I/O adapter120. The storage devices122and124can be any of a disk storage device (e.g., a magnetic or optical disk storage device), a solid state magnetic device, and so forth. The storage devices122and124can be the same type of storage device or different types of storage devices. The I/O adapter120further communicates with application servers170and a file system directory172.

The application servers170and the file system directory172may be associated with the storage device122. Such servers/directories170,172need not be incorporated within the storage device122. Such servers/directories170,172may be external to the storage device122. One skilled in the art may contemplate different system and networking configurations for incorporating the servers/directories170,172therein.

A speaker132is operatively coupled to system bus102by the sound adapter130. A display device162is operatively coupled to system bus102by display adapter160.

FIG. 2is a block/flow diagram of an exemplary server failure detection system where each server in an active state creates a respective proxy file including a timestamp assigned thereto, in accordance with an embodiment of the present invention.

The system200includes a group of servers220. The group of servers220can include, e.g., three application servers222,224,226. The group of servers220can communicate with a file system directory240. One skilled in the art may contemplate a number of different application servers within the server group.

When application servers222,224,226within the group of servers220are activated, a proxy file is created for each application server222,224,226. In the instant case, all three application servers222,224,226are in an active state at first point in time (t=1). The proxy file of each application server is stored in the file system directory240. For example, the first application server222has a first proxy file242with a first timestamp241. The second application server224has a second proxy file244with a second timestamp243. The third application server226has a third proxy file246with a third timestamp245. Therefore, each active application server creates its own proxy file with a timestamp included therein.

FIG. 3is a block/flow diagram of an exemplary server failure detection system where proxy files of servers that are shut down cleanly are deleted, in accordance with an embodiment of the present invention.

The system200includes a group of servers220. The group of servers220can include, e.g., three application servers222,224,226. The group of servers220can communicate with a file system directory240. When application servers222,224,226within the group of servers220are activated, a proxy file is created for each application server222,224,226. In the instant case, the first application server222is in an active state, whereas the second and third application servers224,226have been shut down (clean shut down). As such, the proxy files of the second and third application servers224,226are deleted in the file system directory240. Therefore, each application server deletes its proxy file from the file system directory upon clean shutdown.

FIG. 4is a block/flow diagram of an exemplary server failure detection system where each active server periodically updates its own timestamp, in accordance with an embodiment of the present invention.

The system200includes a group of servers220. The group of servers220can include, e.g., three application servers222,224,226. The group of servers220can communicate with a file system directory240. When application servers222,224,226within the group of servers220are activated, a proxy file is created for each application server222,224,226. In the instant case, all three servers222,224,226are active and thus a proxy file242,244,246is associated with each server222,224,226, respectively, where each proxy file242,244,246is associated with a respective or corresponding timestamp.FIG. 4illustrates that each application server222,224,226has the capability to update its own timestamp at predetermined or predefined or pre-established time periods or intervals. For example, at time (t=2), the first application server222updated its timestamp (251) in proxy file242, the second application server224updated its timestamp (253) in proxy file244, and third application server226updated its timestamp (255) in proxy file246. Therefore, each server can regularly update its timestamps while it is alive or active.

FIG. 5is a block/flow diagram of an exemplary server failure detection system where each server inspects the timestamps of the proxy files belonging to other servers in the group of servers, in accordance with an embodiment of the present invention.

Referring back toFIG. 2, the first application server222can inspect its own timestamp241of proxy file242to determine if the timestamp241is up-to-date or current. Additionally, the first application server222can inspect the timestamps243,245of the second and third proxy files244,246, respectively to determine if the timestamps243,245are up-to-date or current. Similarly, the second application server224can inspect the timestamps241,245of the first and third proxy files242,246, respectively to determine if the timestamps241,245are up-to-date or current. Similarly, the third application server226can inspect the timestamps241,243of the first and second proxy files242,244, respectively to determine if the timestamps241,243are up-to-date or current. Therefore, the application servers222,224,226of the group of servers220can check or inspect each other's timestamps, in addition to checking and updating their own timestamps.

InFIG. 5, one of the application servers222,224,226detected that the timestamp245(FIG. 2) is “old,” thus making the proxy file246associated with the third application server226“old” or “out-of-date.” The timestamp245(FIG. 2) can now be designated as old timestamp265(FIG. 5) and the proxy file246can be designated as an old file. As a result, the third application server226is designated as a failed application server. When the third application server226is a failed application server, one of application servers222,224can take ownership of the third application server226of the group of servers220. In other words, one of application servers222,224can attempt to complete the remaining work that was not finished by the third application server226. Thus, all tasks assigned to the third application server226that have not been completed are reassigned either to or taken over by the first or second application servers222,224. The application servers222,224that take over the remaining work can also establish a communication path260with the file system directory240to access the old proxy file of the third application server226.

FIG. 6is a block/flow diagram of an exemplary server failure detection system where the first server completes the remaining work of the third server and then deletes the proxy file of the third server, in accordance with an embodiment of the present invention.

Once one of the application servers222,224has completed all the remaining work or tasks not completed by the third application server226, the old proxy file is deleted or removed from the file system directory240. In one example, the one of the application servers222,224can then send a notification to the third application server226, which is still in a state of failure that all the remaining work or tasks have been completed. The third application server226is then deactivated (inactive state).

FIG. 7is a block/flow diagram of an exemplary server failure detection system where the deactivated server is reactivated as a new server and creates a new proxy file within the file directory of the group of servers, in accordance with an embodiment of the present invention.

The failed application server226may never restart. However, if the failed application server226does restart or is reactivated, it starts or reactivates as a new server at a point in time (t=3). Therefore, when an application server fails as a result of an “old” or “out-of-date” timestamp associated with its proxy file, the application server can be deactivated, and an application server within the group of application servers can take its place by taking over ownership. Taking over ownership entails completing any and all remaining tasks or work not completed by the third application server. When all the remaining tasks or work have been completed by the takeover server, the old proxy file is deleted, the third application server can be reactivated as a new application server226′ of the group of servers220, and a new proxy file276with a new timestamp275can be created in the file directory associated with the new application server226′.

FIG. 8is a block/flow diagram of an exemplary server failure detection system where each proxy file of each active server includes a file lock, in accordance with an embodiment of the present invention.

Each of the proxy files associated with each application server can include a file lock. For example, the first proxy file242includes a file lock282, the second proxy file244includes a file lock284, and the third proxy file246includes a file lock286. The file locks282,284,286prevent more than one application server222,224,226from accessing a single failed application server. For instance, if the first application server222fails, then one of the peer servers224,226needs to jump in and take over ownership of the remaining work or tasks to be completed by the first application server222. If the second224application server takes over the first application server222, then the file lock282associated with the first proxy file242of the first application server222prevents the third application server226from taking over ownership the remaining work or tasks of the first application server222. Therefore, it is assured that only one application or peer server takes over the remaining tasks or work of only one failed application server. Therefore, one peer application server per one failed application server is desired.

FIG. 9is a block/flow diagram of an exemplary method for detecting a failed server, in accordance with an embodiment of the present invention.

At block910, a proxy file is created for each server of a plurality of servers in an active state.

At block920, a timestamp is assigned to each proxy file of each server of the plurality of servers.

At block930, each server is permitted to inspect each timestamp of each proxy file of each server of the plurality of servers.

At block940, it is determined whether the timestamp assigned to each proxy file of each server of the plurality of servers exceeds a predetermined threshold.

At block950, in response to a timestamp of a proxy file of a failed server exceeding the predetermined threshold, another server of the plurality of servers is allowed to complete the remaining work or tasks of the failed application server.

In one or more embodiments, the application or peer servers within the group of servers can be ranked or weighed or classified based on different factors or parameters or variables. For instance, a relationship can be established between the remaining work of the failed application server and, e.g., the processing capabilities of the available application servers. If the failed application server has several heavy or intense or time-consuming tasks to complete, then an application server having the processing capability to process heavy or intense or time-consuming tasks can be assigned to the failed application server. Therefore, e.g., the processing power of the application server can be taken into account when takeover of a failed application server is triggered. Thus, each of the application servers within a group of servers can be ranked based on, e.g., processing power or processing capabilities. Each application server within a group of application servers can be ranked based on other factors, such as previous uses, specialized functionality, number of processors, processor speed, location of peer server, etc. As a result, assignments to failed application servers can be influenced or affected or determined by analyzing operations or functions or capabilities of available application servers within the group of servers.

In one or more embodiments, the time it takes to complete the remaining tasks or work of each application server can be taken into account when assigning an application server to the failed application server. For instance, if a first application server has, e.g., 3 remaining tasks and it is calculated that it would take, e.g., 5-10 minutes to complete such tasks, then a simple application server with relatively low processing capabilities can be assigned to take over ownership of such failed application server. In contrast, if a second application server has, e.g., 150 remaining tasks and it is calculated that it would take, e.g., 3-4 hours to complete such tasks, then a hard-core application server with relatively high processing capabilities can be assigned to take over ownership of such failed application server. Therefore, the time it would take remaining tasks or work to be completed can be factored into application server assignments. Application servers with very high processing power can be saved for “special” processing tasks or work that needs to be completed.

In one or more embodiments, an application server within a group of application servers can monitor or track each timestamp of each application server within that group of application servers. However, it is also contemplated that an application server within a group of application servers monitors a subset of the other application servers. For instance, if the server group includes 100 application servers, then the group of servers can be subdivided or split into several sub-groups or subsets (e.g., 4 subsets). Each subset can be monitored by one application server, and each subset can monitor itself. One skilled in the art may contemplate different self-regulating or self-inspecting strategies depending on the number of application servers within the group of servers.

FIG. 10is a block/flow diagram of an exemplary cloud computing environment, in accordance with an embodiment of the present invention.

Characteristics are as Follows:

Service Models are as follows:

Deployment Models are as follows:

Referring now toFIG. 10, illustrative cloud computing environment1050is depicted for managing server processes with proxy files. As shown, cloud computing environment1050includes one or more cloud computing nodes1010with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone1054A, desktop computer1054B, laptop computer1054C, and/or automobile computer system1054N may communicate. Nodes1010may communicate with one another. They may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. The network may also be a network for managing server processes with proxy files. The This allows cloud computing environment1050to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device. It is understood that the types of computing devices1054A-N shown inFIG. 10are intended to be illustrative only and that computing nodes1010and cloud computing environment1050can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

FIG. 11is a schematic diagram of exemplary abstraction model layers, in accordance with an embodiment of the present invention. It should be understood in advance that the components, layers, and functions shown inFIG. 11are intended to be illustrative only and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

Hardware and software layer1160includes hardware and software components. Examples of hardware components include: mainframes1161; RISC (Reduced Instruction Set Computer) architecture based servers1162; servers1163; blade servers1164; storage devices1165; and networks and networking components1166. In some embodiments, software components include network application server software1167and database software1168.

Virtualization layer1170provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers1171; virtual storage1172; virtual networks1173, including virtual private networks; virtual applications and operating systems1174; and virtual clients1175.

Workloads layer1190provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation1191; software development and lifecycle management1192; virtual classroom education delivery1193; data analytics processing1194; transaction processing1195; and managing server processes with proxy files1196.

Still yet, any of the components of the present invention could be created, integrated, hosted, maintained, deployed, managed, serviced, etc. by a service supplier who offers to provide a method for detecting a failed server. Thus, the present invention discloses a process for deploying, creating, integrating, hosting, maintaining, and/or integrating computing infrastructure, including integrating computer-readable code into the server procesing system100(FIG. 1), wherein the code in combination with the server processing system100is capable of detecting a failed server. In another embodiment, the invention provides a business method that performs the process blocks/steps of the invention on a subscription, advertising, and/or fee basis. That is, a service supplier, such as a Solution Integrator, could offer to provide a method for detecting a failed server. In this case, the service supplier can create, maintain, support, etc. a computer infrastructure that performs the process blocks/steps of the invention for one or more customers. In return, the service supplier can receive payment from the customer(s) under a subscription and/or fee agreement and/or the service supplier can receive payment from the sale of advertising content to one or more third parties.