Abstract: According to examples, an apparatus may include a processor and a memory on which is stored machine readable instructions that are to cause the processor to receive an allocation request from an allocator client, determine a resource allocation for the received job allocation request, store a record of the determined resource allocation in a records store, and send the determined resource allocation to the allocator client, in which an acknowledgement to the sent determined resource allocation is to be received from the allocator client. The instructions may also cause the processor to manage a state of the determined resource allocation using the record stored in the records store based on whether the acknowledgement is received from the allocator client.

Abstract: Embodiments provide workload processing for clustered systems. In an illustrative, non-limiting embodiment, a computer-implemented method may include identifying a server as an active node of a cluster; assigning a workload to the server in response to the identification; determining, after the assignment, that the server is no longer an active node of the cluster; calculating, in response to the determination, a probability that the server is capable of continuing to execute the workload; and deciding, based upon the probability, whether to allow the workload to remain assigned to the server.

Abstract: According to examples, a system may include a plurality of clusters of nodes and a plurality of container manager hardware processors, in which each of the container manager hardware processors may manage the nodes in a respective cluster of nodes. The system may also include at least one service manager hardware processor to manage deployment of customer services across multiple clusters of the plurality of clusters of nodes through the plurality of container manager hardware processors.

Abstract: According to examples, an apparatus may include a processor and a memory on which is stored machine readable instructions that are to cause the processor to receive an allocation request from an allocator client, determine a resource allocation for the received job allocation request, store a record of the determined resource allocation in a records store, and send the determined resource allocation to the allocator client, in which an acknowledgement to the sent determined resource allocation is to be received from the allocator client. The instructions may also cause the processor to manage a state of the determined resource allocation using the record stored in the records store based on whether the acknowledgement is received from the allocator client.

Abstract: Described is a technology by which an owner node in a server cluster maintains ownership of a storage mechanism through a persistent reservation mechanism, while allowing non-owning nodes read and write access to the storage mechanism. An owner node writes a reservation key to a registration table associated with the storage mechanism. Non-owning nodes write a shared key that gives them read and write access. The owner node validates the shared keys against cluster membership data, and preempts (e.g., removes) any key deemed not valid. The owner node also defends ownership against challenges to ownership made by other nodes, so that another node can take over ownership if a (formerly) owning node is unable to defend, e.g., because of a failure.

Abstract: Managing a distributed system. Embodiments may allow for a quorum to dynamically change the quorum vote. One example is illustrated in a method. The method includes determining a change to a voter's level of participation in a cluster. A quorum of voters changes the voter's voting privileges, based on the change in the voter's level of participation.

Abstract: Described is a technology by which an owner node in a server cluster maintains ownership of a storage mechanism through a persistent reservation mechanism, while allowing non-owning nodes read and write access to the storage mechanism. An owner node writes a reservation key to a registration table associated with the storage mechanism. Non-owning nodes write a shared key that gives them read and write access. The owner node validates the shared keys against cluster membership data, and preempts (e.g., removes) any key deemed not valid. The owner node also defends ownership against challenges to ownership made by other nodes, so that another node can take over ownership if a (formerly) owning node is unable to defend, e.g., because of a failure.

Abstract: Described is a technology by which an owner node in a server cluster maintains ownership of a storage mechanism through a persistent reservation mechanism, while allowing non-owning nodes read and write access to the storage mechanism. An owner node writes a reservation key to a registration table associated with the storage mechanism. Non-owning nodes write a shared key that gives them read and write access. The owner node validates the shared keys against cluster membership data, and preempts (e.g., removes) any key deemed not valid. The owner node also defends ownership against challenges to ownership made by other nodes, so that another node can take over ownership if a (formerly) owning node is unable to defend, e.g., because of a failure.

Abstract: Embodiments provide workload processing for clustered systems. In an illustrative, non-limiting embodiment, a computer-implemented method may include identifying a server as an active node of a cluster; assigning a workload to the server in response to the identification; determining, after the assignment, that the server is no longer an active node of the cluster; calculating, in response to the determination, a probability that the server is capable of continuing to execute the workload; and deciding, based upon the probability, whether to allow the workload to remain assigned to the server.

Abstract: Placing an application on a node in a cluster. A method includes detecting an unexpected event indicating that an application should be placed on a node in the cluster. Real time information about resource utilization on one or more nodes in the cluster is received. Based on the real time information, a determination of a node to place the application is made. The application is placed on the determined node.

Abstract: A method of managing a triggerable task in a cluster environment is described. The method includes accessing a definition of a task, wherein the definition includes a triggering event, and an action to be performed when the triggering event occurs. The method further includes, accessing a cluster policy defining how triggering events are interpreted on a node task basis for a plurality of nodes in a cluster. Based on the cluster policy, the method includes determining that the triggering event has occurred. As a result of the determination that the triggering event has occurred, the method further includes attempting to perform the action.

Abstract: A method and system for increasing server cluster availability by requiring at a minimum only one node and a quorum replica set of replica members to form and operate a cluster. Replica members maintain cluster operational data. A cluster operates when one node possesses a majority of replica members, which ensures that any new or surviving cluster includes consistent cluster operational data via at least one replica member from the immediately prior cluster. Arbitration provides exclusive ownership by one node of the replica members, including at cluster formation, and when the owning node fails. Arbitration uses a fast mutual exclusion algorithm and a reservation mechanism to challenge for and defend the exclusive reservation of each member. A quorum replica set algorithm brings members online and offline with data consistency, including updating unreconciled replica members, and ensures consistent read and update operations.

Abstract: A method and system for increasing server cluster availability by requiring at a minimum only one node and a quorum replica set of replica members to form and operate a cluster. Replica members maintain cluster operational data. A cluster operates when one node possesses a majority of replica members, which ensures that any new or surviving cluster includes consistent cluster operational data via at least one replica member from the immediately prior cluster. Arbitration provides exclusive ownership by one node of the replica members, including at cluster formation, and when the owning node fails. Arbitration uses a fast mutual exclusion algorithm and a reservation mechanism to challenge for and defend the exclusive reservation of each member. A quorum replica set algorithm brings members online and offline with data consistency, including updating unreconciled replica members, and ensures consistent read and update operations.

Abstract: Described is a technology by which an owner node in a server cluster maintains ownership of a storage mechanism through a persistent reservation mechanism, while allowing non-owning nodes read and write access to the storage mechanism. An owner node writes a reservation key to a registration table associated with the storage mechanism. Non-owning nodes write a shared key that gives them read and write access. The owner node validates the shared keys against cluster membership data, and preempts (e.g., removes) any key deemed not valid. The owner node also defends ownership against challenges to ownership made by other nodes, so that another node can take over ownership if a (formerly) owning node is unable to defend, e.g., because of a failure.

Abstract: Described is a technology by which an owner node in a server cluster maintains ownership of a storage mechanism through a persistent reservation mechanism, while allowing non-owning nodes read and write access to the storage mechanism. An owner node writes a reservation key to a registration table associated with the storage mechanism. Non-owning nodes write a shared key that gives them read and write access. The owner node validates the shared keys against cluster membership data, and preempts (e.g., removes) any key deemed not valid. The owner node also defends ownership against challenges to ownership made by other nodes, so that another node can take over ownership if a (formerly) owning node is unable to defend, e.g., because of a failure.

Abstract: The present invention extends to methods, systems, and computer program products for automatically transferring configuration of a virtual machine from one cluster to another cluster. The invention enables an administrator to transfer configuration of a virtual machine by simply specifying a virtual machine to be transferred. The invention then inspects the configuration of the virtual machine on the old cluster as well as the configuration of the old cluster, including the storage (e.g. virtual hard disk) used by the cluster, and then configures a new virtual machine on a new cluster accordingly to match the configuration of the old virtual machine. Similar techniques can also be applied to transfer configuration of an SMB file server.

Abstract: Placing an application on a node in a cluster. A method includes determining that a first application cannot be placed on a first node in the first node's current running state. The method further includes determining that the first application may be able to be placed on the first node by shutting down or moving one or more other applications running on the first node. The method further includes attempting to shut down or move the one or more other applications on the first node to place the first application.

Abstract: Managing a distributed system. Embodiments may allow for a quorum to dynamically change the quorum vote. One example is illustrated in a method. The method includes determining a change to a voter's level of participation in a cluster. A quorum of voters changes the voter's voting privileges, based on the change in the voter's level of participation.

Abstract: The movement of a Virtual IP (VIP) address from cluster node to cluster node is coordinated via a load balancer. All or a subset of the nodes in a load balancer cluster may be configured as possible hosts for the VIP. The load balancer directs VIP traffic to the Dedicated IP (DIP) address for the cluster node that responds affirmatively to periodic health probe messages. In this way, a VIP failover is executed when a first node stops responding to probe messages, and a second node starts to respond to the periodic health probe messages. In response to an affirmative probe response from a new node, the load balancer immediately directs the VIP traffic to the new node's DIP. The probe messages may be configured to identify which nodes are currently responding affirmatively to probes to assist the nodes in determining when to execute a failover.

Abstract: Placing an application on a node in a cluster. A method includes determining that a first application cannot be placed on a first node in the first node's current running state. The method further includes determining that the first application may be able to be placed on the first node by shutting down or moving one or more other applications running on the first node. The method further includes attempting to shut down or move the one or more other applications on the first node to place the first application.