Abstract: The present invention extends to methods, systems, and computer program products for sharing volumes between clustered nodes. Embodiments of the invention include a Clustered Shared Volume File System (CsvFs) that appears to clients as a local file system. The CsvFs communicates to a node where a disk is mounted to coordinate access to files on the disks. CsvFs uses Opportunistic Locks (oplocks) to decide when direct access to a volume is safe. CsvFs can be extended with oplock upgrade mechanisms that allow a coordinating node to tell CsvFs when it is safe to attempt to upgrade oplock. CsvFs also uses a transitivity property of oplocks to be able to grant (delegate) oplocks to clients that are on top of CsvFs.

Abstract: Ones of the windows associated with a software process are identified in a screen layout on a local display of a sharer network node. On the sharer network node, an image of the identified windows as they are arranged in the screen layout and free of obscuration by any other windows in the screen layout is generated. The image is transmitted from the sharer network node to a viewer network node. Also, commands derived from input device events on sharer and viewer network nodes are received. The received commands are processed into a command sequence, which is passed to a shared process executing on the sharer network node. Windows associated with the shared process are presented on the sharer network node in accordance with the received command sequence. An image of the presented windows is generated and transmitted from the sharer network node to the viewer network node.

Abstract: Aspects of the subject matter described herein relate to a distributed network name. In aspects, computers of a cluster have components of a distributed network name service. The network name service has a leader and clones that are hosted on the computers of the cluster. The leader is responsible for updating a name server with network names and addresses of the computers. The leader is also responsible for configuring a security server that allows clients to securely access the computers. The network name service provides credentials to local security authorities of the computers so that a client that attempts to access a service of the computers can be authenticated.

Abstract: A cluster based file service may operate on a cluster of two or more independent devices that have access to a common data storage. The file service may have a namespace definition with each device in the cluster, but may be modified by any device operating the file service. Each instance of the file service may identify and capture a command that changes the namespace structure and cause the change to be propagated to the other members of cluster. If one of the devices in the cluster does not successfully perform an update to the namespace structure, that device may be brought offline. The cluster based file service may permit adding or removing devices from the cluster while the file service is operating, and may provide a high throughput and high availability file service.

Abstract: The present invention extends to methods, systems, and computer program products for sharing volumes between clustered nodes. Embodiments of the invention include a Clustered Shared Volume File System (CsvFs) that appears to clients as a local file system. The CsvFs communicates to a node where a disk is mounted to coordinate access to files on the disks. CsvFs uses Opportunistic Locks (oplocks) to decide when direct access to a volume is safe. CsvFs can be extended with oplock upgrade mechanisms that allow a coordinating node to tell CsvFs when it is safe to attempt to upgrade oplock. CsvFs also uses a transitivity property of oplocks to be able to grant (delegate) oplocks to clients that are on top of CsvFs.

Abstract: The present invention extends to methods, systems, and computer program products for synchronizing state among load balancer components. Embodiments of the invention include load balancers using a consistent hashing algorithm to decide how new connections should be load balanced. Use of consistent hashing algorithm permits load balancers to work in a stateless manner in steady state. Load balancers start keeping flow state information (destination address for a given flow) about incoming packets when it is needed, i.e. such as, for example, when a change in destination host configuration is detected. State information is shared across load balancers in a deterministic way, which allows knowing which load balancer is authoritative (e.g., is the owner) for a given flow. Each load balancer can reach the authoritative load balancer to learn about a flow that cannot be determined locally.

Abstract: Aspects of the subject matter described herein relate to client affinity in distributed load balancing systems. In aspects, a request from a requester is sent to each server of a cluster. Each server determines whether it has affinity to the requester. If so, the server responds to the request. Otherwise, if the request would normally be load balanced to the server, the server queries the other servers in the cluster to determine whether any of them have affinity to the requester. If one of them does, the server drops the request and allows the other server to respond to the request; otherwise, the server responds to the request.

Abstract: Described is a technology in a network load balancing system (node cluster), by which client affinity is preserved across cluster configuration changes, including for new connections from a previous client. Each node maintains a list of the clients that are to remain (have affinity, or “stickiness”) with that node, including following bucket redistribution resulting from convergence. Each affinity list is communicated during convergence so that other nodes may build an exception list or lists. Via a node's exception list, the node that owns a bucket corresponding to a client knows of the affinity with another node and thus drops any packets from that client. Affinity may expire, whereby the node having affinity with that client releases it and notifies the node owning the bucket for that client that the client is no longer to be treated as an exception.

Abstract: Described is a technology in a network load balancing system (node cluster), by which client affinity is preserved across cluster configuration changes, including for new connections from a previous client. Each node maintains a list of the clients that are to remain (have affinity, or “stickiness”) with that node, including following bucket redistribution resulting from convergence. Each affinity list is communicated during convergence so that other nodes may build an exception list or lists. Via a node's exception list, the node that owns a bucket corresponding to a client knows of the affinity with another node and thus drops any packets from that client. Affinity may expire, whereby the node having affinity with that client releases it and notifies the node owning the bucket for that client that the client is no longer to be treated as an exception.

Abstract: Aspects of the subject matter described herein relate to client affinity in distributed load balancing systems. In aspects, a request from a requester is sent to each server of a cluster. Each server determines whether it has affinity to the requester. If so, the server responds to the request. Otherwise, if the request would normally be load balanced to the server, the server queries the other servers in the cluster to determine whether any of them have affinity to the requester. If one of them does, the server drops the request and allows the other server to respond to the request; otherwise, the server responds to the request.