Differentiating connectivity issues from server failures

• US 7,987,392 B2
• Filed: 06/08/2009
• Issued: 07/26/2011
• Est. Priority Date: 06/08/2009
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Boctor, Victor, Luttinen, Todd
• Primary Examiner(s): Baderman; Scott T
• Assistant Examiner(s): PATEL, KAMINI B
• Application Number:
  US12/479,971
• Publication Number:
  US 20100313064A1
• Time in Patent Office: 778 Days
• Field of Search: 714/43
• US Class Current: 714/43
• CPC Class Codes: H04L 41/0893 Assignment of logical groups to network elements
• CPC Class Codes: H04L 43/0811 by checking connectivity
• CPC Class Codes: H04L 43/0817 by checking functioning
• CPC Class Codes: H04L 51/00 User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
• CPC Class Codes: H04L 51/222 using geographical location information, e.g. messages transmitted or received in proximity of a certain spot or area

Abstract

A status of connectivity between servers of different sites (locations) is used to infer whether a network or a server failure has occurred such that data between the servers can be routed more efficiently reducing unnecessary network traffic due to duplicate messages. Servers may be grouped based on location or other characteristics and connectivity status determined based on the communication status of individual servers and their respective groups.

Claims

1. A method to be executed at least in part in a computing device for differentiating connectivity issues from server failures, the method comprising:

determining an interruption in a connectivity status of a server of a server group;

determining connectivity status of at least one other server within the same server group;

inferring one of a server failure and a network failure based on the connectivity statuses of the servers in the server group; and

routing messages to the server based on the inference by

suppressing resubmission of redundant messages until a decision is made whether the inference is one of a server failure and a network failure;

re-routing messages intended for the server to the at least one other server if the inference is server failure; and

queuing the messages for later delivery if the inference is network failure.

2. The method of claim 1, further comprising:

determining whether the server is reconnected; and

if the server is reconnected, continuing to route the messages intended for the server to the server.

3. The method of claim 1, wherein determining whether the server is reconnected includes determining at least one of:

whether the server is powering up, whether the server has lost its state, and whether the server is ready to receive data.

4. The method of claim 1, wherein the connectivity status of the server and of the at least one other server is determined based on a heartbeat network connection.

5. The method of claim 1, wherein the connectivity status of the server and of the at least one other server is determined based on one of:

a number of heartbeat checks and a period of no-response.

6. The method of claim 5, wherein the number of heartbeat checks and the period of no-response are dynamically adjusted based on one from a set of:

a network condition and a data amount to be transferred.

7. The method of claim 1, wherein the group of servers is grouped based on one of:

a location of the servers and a function of the servers.

8. The method of claim 7, wherein the system is a high availability redundancy system for managing one of:

a critical database, a file sharing network, a business application, and customer service.

9. The method of claim 1, wherein the connectivity status of the server is determined based on knowledge from at least one server in another group of servers attempting to communicate with the server.

10. The method of claim 1, wherein the network failure includes one of:

a power failure and a network communication failure.

11. A computing system for differentiating connectivity issues from server failures, the system comprising:

a first site comprising a plurality of servers grouped based on one of;

a location of the servers and a function of the servers;

a first server part of a second site comprising a plurality of servers coupled to the servers of the first site via a network, the first server configured to;

detect an interruption in a connectivity status of a server of the first site based on a heartbeat network connection;

determine connectivity status of remaining servers of the first site;

infer one of a server failure and a network failure based on the connectivity statuses of the servers of the first site;

suppress resubmission of redundant messages until a decision is made whether the inference is one of a server failure and a network failure;

re-route messages intended for the server to at least one the remaining servers of the first site if the inference is server failure; and

queue the messages at the first server for later delivery if the inference is network failure.

12. The system of claim 11, wherein the inference is made based on knowledge associated with the first site received by the first server from remaining servers of the second site.

13. The system of claim 11, wherein the system is a high availability redundancy system exchanging redundancy messages and the first server is further configured to:

the redundancy messages are not resubmitted from redundancy queues maintained by the first server if a next hop solution for delivery of a primary message does not involve multiple servers and a state change has not been detected for the server.

14. The system of claim 13, wherein the redundancy messages are resubmitted from the redundancy queues maintained by the first server if a next hop solution for delivery of the primary message does involve multiple servers and at least one of the multiple servers has not failed a heartbeat check.

15. The system of claim 11, wherein another one of the plurality of servers of the second site is delegated tasks and operations of the first server in response to the first server becoming disconnected.

16. A computer-readable storage medium with instructions stored thereon for differentiating connectivity issues from server failures, the instructions comprising:

detecting an interruption in a connectivity status of a primary server of a site comprising a plurality of high availability servers based on one of;

a number of heartbeat checks and a period of no-response;

determining connectivity status of remaining servers of the site;

inferring one of a server failure and a network failure based on the connectivity statuses of the servers of the site;

re-routing the messages intended for the primary server to at least one the remaining servers of the site if the inference is server failure;

queuing the messages for later delivery if the inference is network failure;

checking to determine whether the primary server is reconnected; and

if the primary server is reconnected, continuing to route the messages intended for the primary server to the primary server.

17. The computer-readable medium of claim 16, wherein a single server exists in a next hop solution and the instructions further comprise:

resubmitting the messages in response to one of;

the primary server recovering with a new queue identity and a new server being added to the next hop solution before a next explicit heartbeat failure occurs.

18. The computer-readable medium of claim 16, wherein a plurality of servers exists in a next hop solution and the instructions further comprise:

resubmitting the messages in response to one of;

the primary server recovering with a new queue identity prior to an explicit heartbeat retry count exceeding a predefined heartbeat retry value and one of the servers in the next hop solution being considered active.

19. The computer-readable medium of claim 18, wherein the instructions further comprise:

suppressing the messages when all servers in the next hop solution are considered down following the explicit heartbeat retry count exceeding the predefined heartbeat retry value.