Patent Description:
Embodiments of the present invention relate, in general, to software virtualization and more particularly, to virtualization of cluster server applications across multiple nodes in a server cluster.

A server is a physical computer dedicated to run one or more services to serve the needs of the users of other computers on a network. Said differently, any computerized process that shares a resource to one or more client processes is, for all intents and purposes, a server. For example, the mechanism that shares files to clients by the operating systems is a file server. Thus, depending on the computing service that the server offers, the server could be a database server, a file server, a mail server, a print server, a web server, a game server or some other kind of server based on the services it provides. In the hardware sense, the word server typically designates computer models intended for hosting software applications under heavy demand in a network environment. And in some cases, the hardware for these specific functions is specialized. That is, a server computer possesses different capabilities than that of a general purposes personal computer.

A server cluster is a group of at least two independent servers connected by a network and managed as a single system to provide high availability of services for clients. <FIG> is a high level depiction of a server cluster environment as would be known to one of reasonable skill in the relevant art. In the illustrated depiction, four servers comprise a server cluster <NUM>. In this case, server A <NUM>, server B <NUM>, server C <NUM>, and server D <NUM> are linked both directly and via a load balancer/router <NUM>. The router <NUM> further serves as access to the Internet <NUM> and the firewall <NUM>.

Server clusters are designed so that the servers in the cluster work together to protect data, keep applications and services running after the failure of one or more servers in the cluster, and maintain consistency of the cluster configuration. The clustering of servers provides a number of benefits over independent servers. One important benefit is that cluster software, which is run on each of the servers in a cluster, automatically detects application failures or the failure of another server in the cluster. Upon detection of such failures, failed applications and the like can be terminated and restarted on a surviving server. So, when a failure occurs on one computer in a cluster, resources are redirected and the workload redistributed to another computer in the cluster.

<FIG> is a further illustration of the server cluster shown in <FIG> in which server C <NUM> has failed. As would be known by one of reasonable skill in the relevant art, the removal of the server in a server cluster utilizes existing failover technology to terminate and restart the applications associated with server C <NUM> on another server within the server cluster. However, by doing so the applications associated with server C must be re-instantiated with a new host and new Internet protocol address.

Other benefits of server clusters include the ability for administrators to inspect the status of cluster resources, and accordingly balance workloads among different servers in the cluster to improve performance. Such manageability also provides administrators with the ability to update one server in a cluster without taking important data and applications offline. As can be appreciated, server clusters are used in critical database management, file and intranet data sharing, messaging, general business applications and the like.

Server clusters come in all shapes and sizes but they are generally either asymmetric clusters or symmetric clusters. In an asymmetric cluster, a standby server exits only to take over for another server in the event of failure. This type of cluster provides high availability and reliability of services but does so at the cost of having redundant and unused capability. The standby server performs no useful work and is either as capable or less capable than the primary server. In a symmetric server cluster, every server in the cluster preforms some useful work and each server in the cluster is the primary host for a particular set of applications. If a server fails, the remaining servers continued to process the assigned set of applications as well as pick up new applications from the failed server. Symmetric server clusters are more cost effective but, in the event of a failure, the additional load on the working servers can make them fail as well.

On each server exists one or more instantiations of various applications. Underlying these applications is a database engine such as Microsoft Transacted Structured Query Language or T-SQL. T-SQL is a special purpose programming language designed for managing data in relational database management systems. Originally built on relational algebra and tuple relational calculus, its scope includes data insert, query, update and delete functionality, schema creation and modification, and data access control. Other relational alternatives to SQL include. QL, 4D Query Language, Datalog, URL based query method, IBM Business Systems I2, ISBL, JPQL, Object Query Language, UnQL, QBE and the like.

SQL is a popular database engine that servers use as a building block for many larger custom application. Each application built using SQL Server (or the like) typically communicates with a single instance of the database engine using that servers name and Internet Protocol address. Thus, servers with many applications depending on SQL server to access a database must normally run an equal number of instances of SQL server. In most cases, each instance of SQL server runs on a single node within the server cluster, each with its own name and address. If the node (server) fails, the database are unavailable until the system is restored on a new node with a new address and name. If the node becomes heavily loaded by one or more applications, the performance of the database and other applications can be degraded.

Generally, there are three types of server cluster failures. The first is application or service failure. These failures occur when application software running on a server fails to perform properly. Second is a system or hardware failure. As implied, this type of failure is tied to the hardware components of one or more servers. For example, the failure of one or more CPUs, drives, memory or power supply. Lastly, a site failure can occur when, due to a natural event such as a storm or a power failure, an entire site fails to perform as expected. The ability to handle each of these types of failures is critical to server cluster's reliability.

Thus, the failover of an application from one server (i.e., machine) to another in the cluster may be automatic in response to a software or hardware failure on the first machine, or alternatively, may be manually initiated by an administrator. However, unless an application is "cluster-aware" (i.e., designed with the knowledge that it may be run in a clustering environment), problems arise during failover.

One problem with existing virtual applications that are not cluster-aware, i.e., legacy applications such as SQL server, is that such applications assume that the current machine name is the only computer name. Consequently, if the application exposes the machine name to clients, or writes the machine name into its persistent configuration information, the system will not function correctly when the application fails over and runs on a different machine having a different machine name. By way of example, an electronic mail application program provides its machine name to other machines connected thereto in a network. If the application is running in a cluster and the server is failed over to another machine, this other machine's name will not be the name that was provided to the other network machines, and the electronic mail application will not function correctly.

To address this deficiency, traditional virtualization platforms for applications in the prior art use failover clustering technology. For example, Microsoft Windows® uses Microsoft Failover Clustering ("MSCS")®. MSCS, and products like MSCS, allows one or more computers to join together to form a cluster. An application then can be made to listen and provide data to clients via a cluster host name or Internet Protocol ("IP") address and not individual computer names. If an active node (computer) fails, MSCS would reposition the application over to the next available node in the cluster to maintain functionality of the application. To avoid data corruption and to ensure only one node in the entire cluster can have access to the file system, New Technology File System ("NTFS"), Small Computer System Interface ("SCSI") reservation is employed. What is lacking however, is the ability to virtualize an application, such as SQL server, in a cluster environment without utilizing MSCS and SCSI reservation.

One of reasonable skill in the relevant art will recognize that virtualization, broadly defined, is the simulation of the software and/or hardware upon which other software runs. This simulated environment is often called a virtual machine (VM). A virtual machine is thus a simulation of a machine (abstract or real) that is usually different from the target (real) machine (where it is being simulated on). Virtual machines may be based on specifications of a hypothetical computer or emulate the computer architecture and functions of a real world computer. There are many forms of virtualization, distinguished primarily by the computing architecture layer, and virtualized components, which may include hardware platforms, operating systems (OS), storage devices, network devices or other resources.

Application or process virtualization can be viewed as part of an overall trend in enterprise IT that includes autonomic computing. Autonomic computing is a scenario in which the IT environment is able to manage itself based on perceived activity, and utility computing, in which computer processing power is seen as a utility that clients can pay for only as needed. The usual goal of virtualization is to centralize administrative tasks while improving scalability and overall hardware-resource utilization. This type of parallelism tends to reduce overhead costs and differs from multitasking, which involves running several programs on the same OS (component).

Hardware virtualization or platform virtualization refers to the creation of a virtual machine that acts like a real computer with an operating system. Software executed on these virtual machines is separated from the underlying hardware resources. For example, a computer that is running Microsoft Windows may host a virtual machine that looks like a computer with the Ubuntu Linux operating system; Ubuntu-based software can be run on the virtual machine.

In hardware virtualization, the host machine is the actual machine on which the virtualization takes place, and the guest machine is the virtual machine. The words host and guest are used to distinguish the software that runs on the physical machine from the software that runs on the virtual machine. The software or firmware that creates a virtual machine on the host hardware is sometimes called a hypervisor.

A significant limitation to a server cluster environment is the inability to manage individual applications during a failover. What is needed, therefore, is a method and system to virtualize an application such as SQL server in a cluster environment without the required use of MSCS or the like. There is also a need to establish a shared cluster system in which every node in a cluster possesses continuous full read and write access and thus eliminate the need for MSCS or SCSI reservations. These and other deficiencies of the prior art are addressed by one or more embodiments of the present invention.

Additional advantages and novel features of this invention shall be set forth in part in the description that follows, and in part will become apparent to those skilled in the art upon examination of the following specification or may be learned by the practice of the invention. The advantages of the invention may be realized and attained by means of the instrumentalities, combinations, compositions, and methods particularly pointed out in the appended claims.

Patent application <CIT> discloses a system and a method that can deploy and manage software services in virtualized and non-virtualized environments. The system provides an enterprise application virtualization solution that allows for centralized governance and control over software and Java applications. The system includes a plurality of resource broker agents. Each resource broker agent resides on one of the plurality of virtualized and non-virtualized machines in the computing environment and can be used to manage the software processes and compute resources running in the computing environment. Each resource broker agent is responsible for starting a set of Virtual Machines running on a specific compute resource and performing resource metering control. The system also includes a virtual machine pool that communicates with the plurality of resource broker agents to create and manage the set of virtual machines for each resource broker agent and collect data.

Document <NPL>) discloses an architecture for a secure Virtual Organization Management framework.

Patent application <CIT> discloses a set of system-level high availability services for computer systems, including a service that that functions in general terms like an extension of the operating system. By providing High Availability (HA) at the system-level, modifications to the applications or the operating system kernel are not required.

Patent application <CIT> discloses systems and methods, including computer program products, providing high-availability in server systems. In one implementation, a server system is cluster of two or more autonomous server nodes, each running one or more virtual servers. When a node fails, its virtual servers are migrated to one or more other nodes. Connectivity between nodes and clients is based on virtual IP addresses, where each virtual server has one or more virtual IP addresses. Virtual servers can be assigned failover priorities, and, in failover, higher priority virtual servers can be migrated before lower priority ones. Load balancing can be provided by distributing virtual servers from a failed node to multiple different nodes. When a port within a node fails, the node can reassign virtual IP addresses from the failed port to other ports on the node until no good ports remain and only then migrate virtual servers to another node or nodes.

Disclosed hereafter by way of example is a system and associated methodology that allows application instances to be virtualized and operate in a fault tolerant and load-balanced means across a cluster of servers and yet still have access to a common pool of data. Virtualizing an application across a server cluster allows the system to work seamlessly and transparently regardless of the physical node where it is being hosted. Once virtualized, the application answers and provides its data though a "virtual" endpoint (virtual hostname or internet protocol address that is different than the local host name or internet protocol address). The instantiated virtualized application behaves and functions as if running in a stand-alone mode but is nonetheless one that can be transitioned from node to node in a cluster and continue to seamlessly function.

The invention is defined in the appended independent claim, preferred embodiments are defined in the appended dependent claims.

The features and advantages described in this disclosure and in the following detailed description are not all-inclusive. Many additional features and advantages will be apparent to one of ordinary skill in the relevant art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter; reference to the claims is necessary to determine such inventive subject matter.

The aforementioned and other features and objects of the present invention and the manner of attaining them will become more apparent, and the invention itself will be best understood, by reference to the following description of one or more embodiments taken in conjunction with the accompanying drawings, wherein:.

The Figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the scope of appended claims.

A system and associated methodology for server cluster application virtualization is hereafter described by way of example. A computer or server cluster is a set of loosely connected computers that work together. In many respects, a "cluster" can be viewed as a single machine. Normally, and as shown in <FIG>, the individual components are connected via a local network in which each computer or node runs its own instance of a file system. These file systems and database engines serve as the building blocks for larger custom applications, however, as previously discussed, each application typically communicates with a single instantiation of the underlying file system. Thus, environments having multiple applications must maintain corresponding multiple instantiations of the file system, or, in alternative, limit each instantiated server to a single application. If the server (system) fails, each application and its corresponding instantiation of the underlying file system must be recreated and, until the recovery is complete, the application and its associated data is unavailable. Similarly, a server that is heavily tasked by a single application can result in performance degradation, both for that application and others that reside on parallel instantiations of the underlying file system. The present invention virtualizes or forms one or more virtual hosts to provide a fault-tolerant and load-balanced platform by which to access a common pool of data across the server cluster. Virtual applications working on top of the virtual host enables the application to work seamlessly and transparently across the system, regardless of where the application is actually (physically) hosted. According to the present invention, once an application is virtualized, it communicates through a virtual endpoint (a virtual host name and virtual internet protocol address) that is different from a local host name or physical internet protocol address. The virtualized application behaves and functions as if it is running in a stand-alone mode on a physical server and yet can be transitioned from one node to another and continue to function.

Embodiments of the present invention are hereafter described in detail with reference to the accompanying Figures. Although the invention has been described and illustrated with a certain degree of particularity, it is understood that the present disclosure has been made only by way of example and that those skilled in the art can resort to numerous changes in the combination and arrangement of parts without departing from the scope of appended claims. The disclosure includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope of appended claims. Also, descriptions of well-known functions and constructions are omitted for clarity and conciseness.

The terms and words used in the following description and claims are not limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the invention. Accordingly, it should be apparent to those skilled in the art that the following description of exemplary embodiments of the present invention are provided for illustration purposes only and not for the purpose of limiting the invention as defined by the appended claims.

As used herein, any reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment.

It will be also understood that when an element is referred to as being "on," "attached" to, "connected" to, "coupled" with, "contacting", "mounted" etc., another element, it can be directly on, attached to, connected to, coupled with or contacting the other element or intervening elements may also be present. In contrast, when an element is referred to as being, for example, "directly on," "directly attached" to, "directly connected" to, "directly coupled" with or "directly contacting" another element, there are no intervening elements present.

For the purpose of the present invention, the following terms are defined to add clarity and prevent any confusion or misconception.

Internet Protocol (IP) is the principal communications protocol used for relaying datagrams (also known as network packets) across a network using the set of communications protocols. It is generally the most popular protocol stack for wide area networks and is commonly known as TCP/IP, because of its most important protocols. IP is responsible for routing packets across network boundaries and is the primary protocol in the Internet Layer of the Internet Protocol Suite. For this purpose, IP defines datagram structures that encapsulate the data to be delivered. It also defines addressing methods that are used to label the datagram source and destination.

New Technology File System (NTFS) is the standard and proprietary file system developed by Microsoft for the Windows line of operating systems including for example Windows NT, Windows XP and Windows Server.

Small Computer System Interface (SCSI) is a set of standards for physically connecting and transferring data between computers and peripheral devices. The SCSI standards define commands, protocols, and electrical and optical interfaces. SCSI is most commonly used for hard disks and tape drives, but it can connect a wide range of other devices, including scanners and CD drives, although not all controllers can handle all devices. The SCSI standard defines command sets for specific peripheral device types; the presence of "unknown" as one of these types means that in theory it can be used as an interface to almost any device, but the standard is highly pragmatic and addressed toward commercial requirements.

Microsoft Cluster Server Software (MSCS) is software designed to allow servers to work together as a computer cluster and to provide failover and increased availability of applications, or parallel calculating power in case of high-performance computing (HPC) clusters (as in supercomputing), that allows servers working together as a computer cluster.

In object-oriented programming, an instance (or instantiation) is an occurrence or a copy of an object, whether currently executing or not. Instances of a class share the same set of attributes, yet will typically differ in what those attributes contain. For example, a class "Employee" would describe the attributes common to all instances of the Employee class. For the purposes of the task being solved, Employee objects may be generally alike, but vary in such attributes as "name" and "salary. " The description of the class would itemize such attributes and define the operations or actions relevant for the class, such as "increase salary" or "change telephone number. " One could then talk about one instance of the Employee object with name = "Jane Doe" and another instance of the Employee object with name = "John Doe".

Also, in object-oriented programming, a class is a construct that is used as a blueprint to create instances of itself - referred to as class instances, class objects, instance objects or simply objects. A class defines constituent members which enable these class instances to have state and behavior. Data field members (member variables or instance variables) enable a class object to maintain state. Other kinds of members, especially methods, enable a class object's behavior. Class instances are of the type of the associated class.

One aspect of the present invention includes a framework on which an instantiation of an application resident on a node can be virtualized without depending on the use of existing failover cluster techniques or similar products. According to one embodiment of the present invention, a framework is built on top of a shared cluster file system that provides to every node in the cluster full read and write access to data at all times. Moreover, neither MSCS (or similar products) or SCSI reservations are needed to manage access to the file system. Accordingly, applications can be virtualized and quickly brought online on any nodes in the cluster.

<FIG> is a high-level logical diagram of components resident on each node of the server cluster that, according to one embodiment of the present invention, enables cluster aware application virtualization. According to one embodiment of the present invention, each node in a server cluster includes, among other things, a cluster monitor engine <NUM>, a local monitor engine <NUM>, a host engine <NUM>, and an application engine <NUM>. In other embodiments of the present invention, additional components such as a health monitor <NUM>, the registry monitor <NUM>, and an application installer <NUM> are included on each node. Each node further includes failover policies <NUM> and various user interfaces <NUM> or clients by which a solution illustrator can gain the status of the server cluster and make configuration changes. As shown in <FIG>, clients <NUM> communicate with the local monitor engine <NUM> via a wire protocol used for sending commands, responses, and events.

According to one embodiment of the present invention, the local monitor engine <NUM> is responsible for receiving and forwarding requests from user interfaces <NUM> to the host engine <NUM> and cluster monitor engine <NUM>. The local monitor engine <NUM> further includes a client manager that handles incoming client requests and passes these requests to the processing engine for maintaining client connections. The processing engine parses and carries out client requests by forwarding the requests to the host engine <NUM> and/or the cluster monitor engine <NUM>. The local monitor engine <NUM> also includes a synchronization manager that keeps the state and configuration files synchronized across the entire cluster. Accordingly, when a command is received by the user interface <NUM> to add or form a virtual host, the synchronization manager relays this information to the cluster monitor engine so that the configuration files on other nodes can be updated.

The cluster monitor engine <NUM> is a primary means of communication between other nodes in the server cluster. The cluster monitor engine is responsible for receiving and forwarding requests from other cluster monitors to the local monitor engine at each node. The cluster monitor engine is also responsible for initiating and managing failover and failover policies when a node joins or leaves the server cluster. In one embodiment of the present invention, the cluster monitor engine accomplishes this task by writing a system service daemon. In addition, the cluster monitoring engine is asked to coordinate all the actions between all available nodes in the cluster using the cluster coordinator. The cluster monitor engine also includes a synchronization manager that keeps the state and configuration of files synchronized across the cluster and works along with the synchronization manager of the local monitor engine <NUM>. The storage manager interfaces with the cluster shared file system and maintains a cluster membership list so that each node maintains an up-to-date list of files throughout the server cluster. Lastly, the cluster monitor engine <NUM> includes a policy manager that carries out failover and fail back policies.

Each node of the server cluster further includes a host engine <NUM> that is responsible for establishing and maintaining virtual hosts and virtual Internet protocol addresses. Invoked by the local monitor engine <NUM>, the host engine <NUM> handles specific requests to create virtual hosts and exits when finished. The host engine <NUM> accordingly includes a virtual host manager that maintains and manages a virtual host list as well as an Internet address manager that manages virtual Internet protocol address subscriptions.

The local monitor engine <NUM> is further in communication with an application engine <NUM>. The application engine <NUM> is responsible for establishing and managing an application such as SQL server (or other virtualized application). Like the host engine <NUM>, the application engine <NUM> is invoked by the local monitor engine <NUM> in response to requests. Once an application is instantiated, the application engine <NUM> exits. As shown in <FIG>, the application engine includes a database manager that maintains and manages database files for each instance. A registry manager further maintains and manages the registry values for each virtualized instance, and an instance manager that manages and maintains instance configurations is stored on each disk. Lastly, an integration manager handles instance registration with the registry and health monitor engines.

In another embodiment of the present invention, each node of the server cluster further includes a health monitor <NUM> and a registry monitor <NUM>. The health monitor is responsible for monitoring the health of each instantiation of an application and signaling a failover or failback event. The health monitor runs as a system service daemon and listens on a particular communication protocol for remote procedure requests. The health monitor engine <NUM> includes a process manager that handles incoming requests from the local monitor engine <NUM> and maintains a registration list of such requests. It also includes a service watcher that monitors service health and other events based on a registration policy. When required, the health monitor engine <NUM> invokes a failover tool <NUM> when cluster reconfiguration is required. The failover tool and policies reside in a failover repository <NUM> that is in communication with the local monitor engine <NUM> and accordingly, the cluster monitor engine <NUM>.

The registry monitor <NUM> which, in communication with the application engine <NUM>, monitors registry changes and maintains these changes to nonvolatile storage. The registry monitor also runs as a system service daemon for additional remote procedure requests. The duties of the registry monitor include handling incoming requests and maintaining a registration list, as well as carrying out registry registration requests and events based on established registration policies.

Client applications issue administrative commands to backend components by connecting to the monitor engine and specifically the monitor daemon and send specifically formatted commands to other components of each node and other nodes within the server cluster. Such client applications can also receive command replies and asynchronous status messages through the same connection commands are transmitted, typically, as binary data streams similar to the XDR format described in Internet RFC <NUM>. Another feature of the present invention is the ability to send and receive state-ful alerts of the cluster environment. State-ful alerts represent an ongoing condition somewhere in the cluster, for example, and accessible or non-operative nodes. Alerts can be raised, modified, or lowered, by sending a single status message to the cluster. Because components (node) can connect and disconnect, it is possible for several alerts to be outstanding as a new node connects to the cluster. For example, if a node crashes, an inaccessible node alert is raised. If a new node connects a few seconds later, it will not receive a status message from the inaccessible node alert, and will be unable to display the message on the screen or to convey that message to user. To resolve this issue, each component in the status relay network must retain the most recent state-ful raised alerts in the form of a small, in memory, alert database. When a new computer connects to the status relay network, the complete alert database is relayed to the new peer, as if the alerts were just generated. One function of the health monitor is to receive and analyze alerts. Based on the alerts received, the health monitor can be configured to carry out specific actions. These actions are configured through policies, and policies are generally specific to each type of alert. Generally, specific details include a set of predetermined actions that are established to take place when an alert is raised.

The present invention (referring generally to <FIG>) establishes a system for application virtualization. On each node of a server cluster a local monitor engine communicates with, among other things, a cluster monitor engine and a host engine to form one or more environments on which a virtual version of an application can be formed. Each virtual application resides on a virtual host that possesses a unique host name and IP address. Upon the occurrence of a failover or failback condition, the virtual host and its associated virtual application is relocated to a new node based on the established failover policies. Once relocated, the new instantiation of the virtual host possesses the same name and IP address as the prior version, thus, from the Application's perspective, access to the system is seamless.

The present invention utilizes a cluster shared file system where every server in the cluster can read/write to the same blocks of disk. Without the constraint imposed by SCSI reservation, a virtualized application can quickly, easily and efficiently be brought online on any server in the cluster. Moreover, for any applications that support a "Shared Everything" architecture, the invention can be extended to provide a cheaper and more efficient load-balanced platform for the applications.

To better understand the intricacies of the present invention, consider the following example. In one example (referring generally to <FIG>), the Local Monitor Engine <NUM> communicates with the Host Engine <NUM> to establish and bind a virtual host and virtual IP address to the local server. The Local Monitor Engine <NUM> then communicates with the Application Engine <NUM> to process and transform an instance of an application of choice (in this example) into a cluster application that binds to the virtual host. In the context of the present invention, a cluster application is one that is cluster aware as opposed to an application that is solely aware of its underlying host. Returning to the example, the Local Monitor Engine <NUM> also communicates with the Cluster Monitor Engine <NUM> to ensure all servers in the cluster are aware of the new cluster application so that they can correctly participate in the cluster quorum. Similarly, the Cluster Monitor <NUM> monitors other applications instantiated at other nodes within the cluster. To provide high availability for the application, the Application Engine <NUM> registers the application with the Registry Monitor <NUM> and the Health Monitor <NUM>.

When there is a change in the local registry key of the application, the Registry Monitor <NUM> persists the change to a shared disk. This ensures the cluster as a whole will always have the latest image of the registry hive. If an application service fails or goes offline on one of the active servers in the cluster (ie. the node fails), the Health Monitor <NUM> will signal a failover with the Local Monitor Engine <NUM> in conjunction with the failover policy repository <NUM>. According to one embodiment of the present invention, the failover polices designate where a particular instantiation of an application will reside in the event of a node failure. Once the target node is identified, a request is initiated.

The Local Monitor Engine <NUM> communicates with the Cluster Monitor Engine <NUM> to forward the request to other remote Cluster Monitor Engines. Each remote Cluster Monitor Engine, in turn, forward the request to their respective Local Monitor Engines. The remote Local Monitor Engines then pass the request down to the Host Engine and Application Engine. If the remote server is the next available server (as designated by the failover policy) of the virtual host, the remote Host Engine starts binding the prior virtual host and virtual IP to its new network interface, and the remote Application Engine starts processing the application and registering it with the remote Registry and Health Monitor.

Virtualizing an application according to one or more embodiments of the present invention allows an application to work seamlessly and transparently, regardless of where or on what system the application is actually hosted (i.e. on physical or virtual server). A virtualized application such as SQL Server behaves and functions as if it is running in a stand-alone mode. With a proper failover engine built on cluster shared file system, a virtualized application can, according to the present invention, be transitioned from node to node in a cluster/cloud infrastructure seamlessly and continue to function. In addition, multiple applications share a single pool of storage, eliminating the need to pre-allocate individual storage quorums for each clustered application. The present invention provides for an application consolidation platform in which multiple instances of an application can be stacked on a single server.

Included in the description are flowcharts depicting examples of the methodology which may be used to form a server cluster application virtualization. In the following description, it will be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by computer program instructions. These computer program instructions may be loaded onto a computer or other programmable apparatus to produce a machine such that the instructions that execute on the computer or other programmable apparatus create means for implementing the functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable apparatus to function in a particular manner such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operational steps to be performed in the computer or on the other programmable apparatus to produce a computer implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

Accordingly, blocks of the flowchart illustrations support combinations of means for performing the specified functions and combinations of steps for performing the specified functions. It will also be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.

Turning attention now in addition to <FIG>, a flowchart for application virtualization in a server cluster according to one embodiment of the present invention can be seen. The process begins <NUM> with a request for the virtualization of an instance of an application <NUM>. This request is conveyed not only amongst the components of the receiving node but forwarded <NUM> to each other cluster monitor / node within the server cluster. The request to virtualize instantiation of an application is sent to both the application engine and the host engine. Upon arrival at the host engine, the request results in the addition of the virtual host <NUM> and the addition of a virtual Internet protocol address <NUM>. Correspondingly, the application engine adds an instance of the application <NUM> and issues a query <NUM> whether or not this node is the primary node of application instantiation.

If the node receiving the request is a primary node <NUM>, databases associated with the application are copied to the storage area network <NUM>. Thereafter, the registry of instantiation is updated <NUM> and the instant service is updated throughout the cluster environment <NUM>. The instance server name is updated <NUM> to align with the name of the virtual host as is the Internet protocol address associated with the instantiation. An alias for the instantiation is created <NUM> and that alias is registered with the Health Monitor <NUM>. The registration is also registered with the Registry Monitor <NUM> and the application instantiation is initiated <NUM> and, with the instantiation complete, the application configuration is updated <NUM> and the existence of a new application is communicated to the rest server cluster, ending <NUM> the process.

One skilled in the relevant art will recognize that some portions of this specification are presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals within a machine memory (e.g., a computer memory). As used herein, an "algorithm" or "process" is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, algorithms and operations involve the manipulation of information elements. Typically, but not necessarily, such elements may take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is convenient at times, principally for reasons of common usage, to refer to such signals using words such as "data," "content," "bits," "values," "elements," "symbols," "characters," "terms," "numbers," "numerals," "words," or the like. These specific words, however, are merely convenient labels and are to be associated with appropriate information elements.

Likewise, the particular naming and division of the modules, managers, functions, systems, engines, layers, features, attributes, methodologies, and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions, and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the modules, managers, functions, systems, engines, layers, features, attributes, methodologies, and other aspects of the invention can be implemented as software, hardware, firmware, or any combination of the three. Of course, wherever a component of the present invention is implemented as software, the component can be implemented as a script, as a standalone program, as part of a larger program, as a plurality of separate scripts and/or programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment.

To better understand the concepts presented in the present disclosure and to appreciate the applications of the present invention in a server cluster, consider the following example. <FIG> presents a series of the depictions of a server cluster environment in which virtualized applications reside on one or more servers in accordance with embodiments of the present invention. Turning attention now to <FIG>, a cluster server environment is presented that comprises a plurality of servers <NUM> that are communicatively coupled together and in further communication with a consolidated shared file system <NUM>. The server cluster <NUM> is managed by a cluster manager <NUM> and is in turn in communication with a plurality of clients or user interfaces <NUM>. In the present depiction, the shared data or consolidated shared file system <NUM> is comprised of a series of storage media <NUM> such as a storage area network or similar system. Indeed, the storage pool can be a single storage array or made up of a combination of storage area network arrays from various third-party vendors. Each server with ending server cluster <NUM> can be either a virtualized server or physical server. In the present depiction <NUM> servers are depicted, <NUM><NUM>-<NUM><NUM>. Note that the present invention is equally applicable to a variety of different server sizes and types in that a heterogeneous server cluster is supported by the present invention.

<FIG> shows the same server cluster environment in which at least one application is associated with each server within the server cluster. For example server <NUM><NUM> is associated with a SQL <NUM> application <NUM><NUM>. Similarly, server <NUM><NUM> is associated with an exchange application <NUM><NUM>. Similar correspondence of application servers throughout the server cluster can be seen. <FIG> represents a typical server cluster environment in which each application resides on a single instance of an application per server.

In accordance with the present invention, each node within the server cluster includes various components, including a cluster monitor engine, a local monitor engine, and a host engine. These components work with additional components such as the Health Monitor and Registry Monitor to assess the overall health of, not only that particular node, but other nodes within the cluster environment. By establishing a virtual host, as well as a virtual Internet address for that host, multiple application instances can be placed on a single physical server rather than the typical situation in which a single instance must reside on a single server. The ability of the virtual host to possess its own Internet protocol address and to be server cluster aware so as to freely access data from the consolidated shared file system enables a virtual host to be relocated from one physical node to another should the health of that particular node be in question.

<FIG> is an example of the failure of one or more nodes in a server cluster environment. In this particular example, two servers have been identified as failing. The first server <NUM><NUM> has been deliberately taken down for maintenance, as is illustrated by the wrench <NUM> overlaying the image of the server. Similarly, the second server, server <NUM><NUM> has been identified by the Health Monitor as failing <NUM>. In both situations, the instantiation of the applications on each server can no longer function. According to one embodiment of the present invention, failover policies exist in which in the event of a server failure, the instantiation of a particular application is designated to be relocated to another node. Consider for the present example that the SQL <NUM> application and the SP <NUM> application resident on the first server <NUM><NUM> possesses a failover policy relocation to server <NUM><NUM>. Similarly, the application EXCH <NUM> that is instantiated on the failed server <NUM><NUM> possesses a failover policy relocation to server <NUM><NUM>.

<FIG> illustrates that the application instantiations located on the server that was undergoing maintenance, and on the server that was failing, has been relocated according to predetermined failover policies. In a similar manner, an IT professional can designate certain servers with and the server cluster as being idle or as being artificially failed resulting in the application, which may be instantiated on that server to follow its predetermined failover policy. By doing so, the application instantiations can be relocated to other servers to more efficiently utilize the server capability. This is accomplished, according to one embodiment of the present invention, by instantiating the application on top of a virtual host and, with its own unique virtual Internet protocol address. By doing so, the instantiation of the application maintains a seamless conductivity to the consolidated shared file system, regardless of which physical server to which it may reside. Thus, <FIG> illustrates that the application instantiations associated with many of the physical servers have been relocated so as to stack multiple applications on one or more servers. By doing so, and as by seen in <FIG>, the server cluster that originally comprised <NUM>, physical servers, each within a single in potentiation of an application, can be consolidated into seven physical servers in which multiple instantiations of applications are stacked on one or more servers. Thus, this server cluster application virtualization provides the IT professional the ability to more efficiently and cost-effectively manage a server cluster and to prevent or minimize costly downtime of the re-instantiation of applications as a move from one server to another due to either maintenance or computer failure.

Claim 1:
A system for server cluster application virtualization, comprising:
a plurality of servers (<NUM><NUM>-<NUM><NUM>) configured into a server cluster (<NUM>), the plurality of servers being communicatively coupled together and in further communication with a consolidated shared file system (<NUM>) where every server in the cluster can read and write to the same blocks of disk, wherein each server (<NUM><NUM>-<NUM><NUM>) within the server cluster is associated with a node Internet Protocol, IP, address and includes:
a local monitor engine (<NUM>),
a cluster monitor engine (<NUM>),
a host engine (<NUM>), and
an application engine (<NUM>)
wherein the host engine is operable to form a plurality of virtual hosts and establish a virtual IP address for each virtual host, each virtual host having a unique virtual host name, having knowledge it is operating in a clustering environment, and being able to freely access data from the consolidated shared file system; and
the system further comprising at least one instantiation of an application configured to operate on top of one of the plurality of virtual hosts at each server, wherein the application is associated with the virtual IP address of the virtual host that is distinct from the node IP address, the application being configured to communicate through a virtual endpoint, the virtual endpoint comprising the virtual host name and the virtual IP address of the virtual host, such that the instantiation of the application maintains seamless conductivity to the consolidated shared file system (<NUM>) regardless of which server to which it resides; and wherein the host engine (<NUM>) is operable to transfer the one of the plurality of virtual hosts, the instantiation of the application on top of the one of the plurality virtual hosts, and the virtual IP address of the virtual host from one server within the server cluster to another server within the server cluster and maintain the virtual IP address of the virtual host.