Patent Application
20120159234
It is becoming more common for information and software applications to be stored in the cloud and provided to users as a service. One example in which this is becoming common is in communications services, which include instant messaging, presence, collaborative applications, voice over IP (VoIP), and other types of unified communication applications. As a result of the growing reliance on cloud computing, the services provided to users must be resilient, i.e., provide reliable failover systems, so that users will not be affected by outages that may affect servers hosting applications or information for users.
The cloud computing architectures that are used to provide cloud services should therefore be able to handle failure on a number of levels. For example, if a single server hosting IM or conference services fails, the architecture should be able to provide a failover for the failed server. As another example, if an entire data center with a large number of servers hosting different services fails, the architecture should also be able to provide adequate failover for the entire data center.
It is with respect to these and other considerations that embodiments of the present invention have been made. Also, although relatively specific problems have been discussed, it should be understood that embodiments of the present invention should not be limited to solving the specific problems identified in the background.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detail Description section. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Described are embodiments directed to providing resilient services using architectures that have a number of failover features including the ability to handle failover of an entire data center. Embodiments include a first server pool at a first data center that provides client communication services that may include instant messaging, presence applications, collaborative applications, voice over IP (VoIP) applications, and unified communication applications to a number of clients. The first server pool is backed up by a second server pool that is located in a different data center. Additionally, the first server pool serves as a backup for the second server pool. The two server pools thus engage in replication of user information that allows each of them to serve as a backup for the other. In the event that one of the data centers fails, requests are rerouted to the backup server pool.
Embodiments may be implemented as a computer process, a computing system or as an article of manufacture such as a computer program product or computer readable media. The computer program product may be a computer storage media readable by a computer system and encoding a computer program of instructions for executing a computer process. The computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process.
Non-limiting and non-exhaustive embodiments are described with reference to the following figures.
Various embodiments are described more fully below with reference to the accompanying drawings, which form a part hereof, and which show specific exemplary embodiments for practicing the invention. However, embodiments may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Embodiments may be practiced as methods, systems or devices. Accordingly, embodiments may take the form of a hardware implementation, an entirely software implementation or an implementation combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.
As shown in
System 100 includes various features that allow server pools (102A, 102B, 104A, and 104B) to provide resilience services when components of system 100 are inoperable. The inoperability may be caused by on routine maintenance performed by an administrator, such as for example the addition of new servers to a server pool or upgrading of hardware or software within system 100. In other cases the inoperability may be caused by the failure of one or more components within system 100. As described in greater detail below, system 100 includes a number of backups that provide resilient services to users on clients (106, 108, 110, 112, 114, and 116).
One feature that provides resiliency within system 100 is the topology configuration of the server pools within system 100. The topology is configured so that a server pool in data center 102 is backed up by a server pool located in data center 104. For example, server pool 102A within data center 102, is configured to be backed up by server pool 104A in data center 104. In addition, server pool 104A uses server 102A as a backup for user information on server 104A. Accordingly, at regular intervals server pool 102A and server pool 104A engage in a mutual replication to exchange information so that each contains up to date user information from the other. This allows server pool 102A to be used to service requests directed to server pool 104A should server pool 104A become inoperable. Similarly, server pool 104A is used to service requests directed to server pool 102A should server pool 102A become inoperable. An embodiment of mutual replication is illustrated in
As indicated above, server pool 102A is in data center 102 which is different than the data center of its backup, namely server pool 104A, which is in data center 104. In embodiments, data center 102 is located in a different geographical location than data center 104. This provides an additional level of resiliency. As those with skill in the art will appreciate, locating a backup server pool in a different geographical location reduces the likelihood that the backup server pool will be unavailable at the same time as the primary server pool. For example, data center 102 may be located in California while data center 104 may be located in Colorado. If for some reason there is a power outage that affects data center 102 it is located far enough away from data center 104 that it is unlikely that the same issues will affect data center 104. As those with skill in the art will appreciate, even if data center 102 and data center 104 are not separated by long distances, such as located in different states, having them in different locations reduces the risk that they will be unavailable at the same time. The data centers in embodiments are further designed be connected by a relatively large bandwidth and stable connection.
In some embodiments, each data center 102 and 104 may include a specially configured server pool referred to herein as a director pool. In the embodiment shown in
There may be various ways in which a director server pool in a data center determines whether a server pool is inoperable. One way may be for each server pool within a data center to send out a periodic heartbeat message. If a long period of time has passed since a heartbeat messages has been received from a server pool, then it may be considered inoperable. In some embodiments, the determination that a pool is down is not made by the director server pool but rather requires a quorum of pools within a data center to decide that a server pool is inoperable and that requests to that pool should be rerouted to its backup.
Additional resilience is provided by the backup of databases (118, 120, 122, and 124). As shown in
In embodiments, the backup databases (118A, 120A, 122A, and 124A) mirror their respective databases and therefore can be used in situations in which databases (118, 120, 122, and 124) are inoperable because of routine maintenance or because of some failure. If any of the databases (118, 120, 122, and 124) fail, server pools (102A, 102B, 104A, and 104B) access the respective backup databases (118A, 120A, 122A, and 124A) to retrieve any necessary information.
As indicated above, system 100 provides a resilient communication services to users on clients (106, 108, 110, 112, 114, and 116). As one example, a user on client 114 may request to be part of an audio/video conference that is being provided through system 100. The user would send a request through network 118A to log into the conference. The request would be transmitted to intermediate server 120 which may include logic for load-balancing between data centers 102 and 104. In this example, the request is transmitted to director server pool 105. The director server pool 105 may determine that server pool 104B should handle the request.
Server pool 104B includes a server that provides services for the user to participate in the audio/video conference. If the server providing the audio/video conference services fails, then server pool 104B can failover to another server within server pool 104B. This provides a level of resiliency. This failover occurs automatically and transparent to the user. Also, the failure may create some interruption as the client used by the user re-joins the conference but there will not be any loss of data. In other embodiments, the user may not see any interruption in the audio/video conference service.
As shown in
As this example illustrates, system 100 provides a number of features that allow services to be provided to users without interruption even if there are a number of components that are unavailable within system 100. As those with skill in the art will appreciate, the example above is not intended to be limiting and is provided only for purposes of description. Any type of communication service, such as instant messaging, presence applications, collaborative applications, VoIP applications, and unified communication applications may be provided as a resilient service using system 100.
Embodiments of system 100 provide a number of availability and recovery features that are useful for users of the system 100. For example, in a disaster recovery scenario, i.e., a pool or entire data center fails, any requests for data are re-routed to the backup pool/data center and service occurs uninterrupted. Also, embodiments of system 100 provide for high availability. For example, if a server in a pool is unavailable because of a large number of requests or a failure, other servers in the pool start handling the requests also the backup (e.g., mirrored) databases become active in servicing requests.
As shown in
As noted above, in embodiments, server pool 202 serves as a backup to server pool 204 and vice versa (i.e., server pool 204 serves as a backup to server pool 202). As a result, as shown in
As those with skill in the art will appreciate, the information that is replicated between server 202 and 204 is any information that is necessary for the server pools to serve as backups in providing communication services. For example, the information that is exchanged during the mutual replication may include user's contact information, user's permission information, conferencing data, and conferencing metadata.
Furthermore, although operational flows 300, 400, and 500 are illustrated and described sequentially in a particular order, in other embodiments, the operations may be performed in different orders, multiple times, and/or in parallel. Further, one or more operations may be omitted or combined in some embodiments.
Operational flow 300 begins at operation 302 where a first server pool provides client communication services to a first plurality of clients. In embodiments, the first server pool is in a first data center such as server pools 102A and 102B (
In some embodiments, the communication services provided to the plurality of clients may be preceded by the establishment of a session with each of the plurality of clients. In one embodiment, the session initiation protocol (SIP) is used in establishing the session. As those with skill in the art will appreciate, use of SIP allows for more easily implementing failover mechanisms to provide resilient services to clients. That is, when a client sends a request to a particular server pool, if the server pool is unavailable, information may be provided to the client to reroute its future requests to a backup server pool.
After operation 302, an identification is made at operation 304 that a server in the first server pool has failed. In embodiments, the server that has failed is actively providing services to clients.
The first server pool includes a plurality of servers each of which may act as a failover to carry the load of the failed server. This provides a level of resiliency that allows the services being provided to the plurality of clients to continue without interruption despite a server in the first server pool having failed. Accordingly, at operation 306 services were being provided by the failed server are provided using another server in the first server pool.
At a later point in time, flow passes to operation 308 where the first server pool is identified as inoperable. This operation may be performed in some embodiments by a director server pool, or some other administrative application that manages the first data center. The inoperability may be based on some type of failure (e.g., hardware failure, software failure, or even complete failure of the first data center) of the first server pool. In other embodiments, the inoperability may be merely an administrative event for example updating software or hardware within the first server pool.
After operation 308 flow passes to operation 310 where requests are rerouted to the backup server pool configured to back up the first server pool. In embodiments, the backup server pool is located at a different data center that may be at a geographically distant location from the first data center. The location of the different data center provides an additional level of resiliency that makes it unlikely that the backup server pool will be unavailable when the first server pool is unavailable.
After operation 310, flow passes to operation 312 where the backup server pool is used to provide services to the plurality of clients. Operations 310 and 312 in embodiments occur automatically and transparently to the plurality of clients. In this way, the services being provided to the clients are provided without interruption and are resilient to a server failure and also a complete data center failure. Flow 300 ends at 314.
Flow 400 shown in
As part of the mutual authentication, flow passes to operation 406 where the first server pool will receive a token from the second server pool indicating a last change received by the second server pool. In response, the first server pool will determine what changes must be sent to the second server pool to ensure that the second server pool includes the necessary information should it have to act in a failover capacity. At operation 408 any changes that have been made on the first server pool are sent to the second server pool. Flow 400 ends at 410.
Referring now to
After operation 504, flow 500 passes to operation 506 where the request is rerouted to a backup server pool at a second data center. In embodiments, the second data center is located at a different geographic location as the first server pool to reduce the risk that the backup server pool is unavailable. Flow end at 508.
In its most basic configuration, system 600 typically includes at least one processing unit 602 and memory 604. Depending on the exact configuration and type of computing device, memory 604 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. This most basic configuration is illustrated in
The term computer readable media as used herein may include computer storage media. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory 604, removable storage, and non-removable storage 608 are all computer storage media examples (i.e. memory storage.) Computer storage media may include, but is not limited to, RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store information and which can be accessed by computing device 600. Any such computer storage media may be part of device 600. Computing device 600 may also have input device(s) 614 such as a keyboard, a mouse, a pen, a sound input device, a touch input device, etc. Output device(s) 616 such as a display, speakers, a printer, etc. may also be included. The aforementioned devices are examples and others may be used.
The term computer readable media as used herein may also include communication media. Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.
Reference has been made throughout this specification to “one embodiment” or “an embodiment,” meaning that a particular described feature, structure, or characteristic is included in at least one embodiment. Thus, usage of such phrases may refer to more than just one embodiment. Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
One skilled in the relevant art may recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, resources, materials, etc. In other instances, well known structures, resources, or operations have not been shown or described in detail merely to avoid obscuring aspects of the invention.
While example embodiments and applications have been illustrated and described, it is to be understood that the invention is not limited to the precise configuration and resources described above. Various modifications, changes, and variations apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and systems disclosed herein without departing from the scope of the claimed invention.
