Cross-datacenter read-write consistency in distributed cloud computing platforms

Abstract

A distributed storage system including servers is configured to accept requests including a consistency indicator marking a desire for cross-datacenter consistency for the server. The server detects that the consistency indicator can be required and, in response, determines a consistency key based at least in part on the request. In example aspects, the consistency key can include a hash value determined by a hash function shared across datacenters, whereby each datacenter can determine the same consistency key for a given resource and datacenter combination. The server can also be configured to determine a preferred datacenter for handling the request based at least in part on the consistency key, and thereafter redirect the request to the preferred datacenter. In embodiments, the consistency indicator can also indicate a range of strong consistency required by the invoking client.

Description

Background Technology

[0001] Cloud computing refers to the on-demand availability of computer system resources on the Internet, particularly data storage and computing power typically provided in geographically dispersed data centers, without direct user management. Modern cloud computing has many characteristics, but perhaps none is more important than high availability. Enterprises, in particular, use cloud computing platforms for many mission-critical applications, including e-commerce and data warehousing. For many applications, any period of system downtime can be extremely costly for system users. Therefore, cloud computing platforms typically utilize extensive redundancy within each data center, as well as geographical redundancy, distributing additional redundant data centers globally. This redundancy involves both hardware and data redundancy, the latter involving the distribution of resource replicas across geographically diverse data centers.

[0002] However, this replication and distribution of resource copies across data centers is not always a fast process. For example, transactional data and other data below the level of business applications can be quite large and / or change rapidly. In such cases, it can be difficult to ensure data consistency across diverse data centers.

[0003] However, business applications may require and assume that a consistent view of data resources is always available, and that data written by one client is always provided to that client or other clients during subsequent reads of that data. Current approaches to this problem are often inadequate. For example, cloud computing platforms can support 'eventual consistency,' where data written is eventually consistent across data centers (i.e., after background replication is complete). Alternatively, a consistent view of the data can be provided to clients connected to the same data center (i.e., the data center where the data was initially written). In another example, where the cloud computing platform provides session consistency, different clients can share sessions. The first solution is not timely, and the second solution is not very useful for clients connected to different data centers. With the last solution, session data is shared among clients that may be widely distributed around the world. Summary of the Invention

[0004] This summary is provided to present a set of concepts in a simplified form, which will be further described in the detailed embodiments below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0005] Methods, systems, and computer program products are provided for providing cross-datacenter consistency in a global system comprising multiple geographically diverse data centers. In an example aspect, a server in a data center may receive a request for a resource. The request contains a consistency indicator. The server detects the consistency indicator in the request and determines a consistency key based at least in part on the request (or information associated with the request, such as, for example, an access or authorization token or authorization context). Based on the consistency key, a preferred datacenter for satisfying the request is determined. The request is redirected to that datacenter.

[0006] In another example, data center servers are configured to determine a consistency key, at least in part, based on the request by determining a hash value related to the request. In one aspect, each data center can use the same hash function to determine the consistency key, and a preferred data center is determined each time a consistency indicator is detected in a request. In another example, a preferred data center is determined at the data center front-end, and requests are redirected to the preferred data center via binding redirection.

[0007] Other features and advantages, as well as the structure and operation of various examples, are described in detail below with reference to the accompanying drawings. It should be noted that these ideas and techniques are not limited to the specific examples described herein. Such examples are presented here for illustrative purposes only. Based on the teachings contained herein, additional examples will be apparent to those skilled in the art(s) related to the subject matter. Attached Figure Description

[0008] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate embodiments of the present application and, together with the specification, further serve to explain the principles of the embodiments and enable those skilled in the art to make and use the embodiments.

[0009] Figure 1 A block diagram of an example distributed storage system comprising multiple data centers is shown according to an embodiment, wherein each data center includes a request server with a strong consistency request handler.

[0010] Figure 2 A detailed schematic diagram of an example strong consistency request handler according to an embodiment is shown.

[0011] Figure 3 The illustration shows a request that satisfies a strong consistency condition, according to an embodiment. Figure 1 A sequence diagram of an example distributed storage system.

[0012] Figure 4 A flowchart of an example method for satisfying resource requests including strong consistency conditions, according to an embodiment, is shown.

[0013] Figure 5The example illustrates the use of a method according to an embodiment. Figure 4 An improved flowchart, the improvements include the use of a shared hash function.

[0014] Figure 6 The example illustrates the use of a method according to an embodiment. Figure 4 and / or Figure 5 An improved flowchart for redirecting requests to a preferred data center via binding redirection.

[0015] Figure 7 This is a block diagram of an example computer system that can implement the embodiments.

[0016] The features and advantages of the embodiments will become more apparent from the detailed description set forth below when taken in conjunction with the accompanying drawings, in which the same reference numerals identify corresponding elements throughout. In the drawings, similar reference numerals generally denote identical, functionally similar, and / or structurally similar elements. The first appearance of an element in the drawings is indicated by the leftmost numeral in the corresponding reference numeral(s). Detailed Implementation

[0017] I. Introduction

[0018] This specification and accompanying drawings disclose one or more embodiments incorporating features of the invention. The scope of the invention is not limited to the disclosed embodiments. The disclosed embodiments are merely illustrative, and modifications of the disclosed embodiments are also included in the invention. The embodiments of the invention are defined by the appended claims.

[0019] In this specification, references to "an embodiment," "embodiment," "example embodiment," etc., indicate that the described embodiment may include a specific feature, structure, or characteristic, but each embodiment does not necessarily include that specific feature, structure, or characteristic. Furthermore, these phrases do not necessarily refer to the same embodiment. Additionally, when a specific feature, structure, or characteristic is described in connection with an embodiment, it is meant that, whether explicitly described or not, implementing such a feature, structure, or characteristic in conjunction with other embodiments is within the knowledge of those skilled in the art.

[0020] Furthermore, it should be understood that the spatial descriptions used in this article (e.g., "above", "below", "over", "left", "right", "below", "top", "bottom", "vertical", "horizontal", etc.) are for illustrative purposes only, and the actual implementation of the structures described in this article can be arranged in space in any direction or manner.

[0021] In this discussion, unless otherwise stated, adjectives modifying one or more features of embodiments of this disclosure, such as “substantially” and “approximately”, are understood to mean that the condition or feature is defined within an acceptable tolerance for the operation of the embodiment for its intended application.

[0022] Numerous exemplary embodiments are described below. Please note that any section / subsection headings provided herein are not limiting. Embodiments are described throughout this document, and embodiments of any type may be included under any section / subsection. Furthermore, embodiments disclosed in any section / subsection may be combined in any manner with any other embodiments described in the same section / subsection and / or different sections / subsections.

[0023] II. Example Implementation

[0024] As mentioned above, highly available distributed computing systems typically utilize multiple redundancies within the same data center and geographical redundancy across data centers (i.e., additional data centers in geographically different locations). For example, Microsoft Azure Active Directory (hereinafter referred to as "AAD") is a highly available distributed system that supports secure management of access to Azure cloud computing services and resources. AAD ensures high availability and scalability by replicating data across differentiated data centers. Specifically, writes to AAD are sent to the data center hosting the primary copy of the written data, where these writes are synchronously replicated to a secondary data center hosting a replica of the primary copy. Subsequently, the data is asynchronously replicated to multiple other data centers, each hosting a secondary copy of the data. Subsequent reads of the written AAD data will be served from the data center hosting the secondary copy.

[0025] Because AAD reads and pulls data from secondary replicas, clients may not see a consistent view due to replication latency between the primary and secondary data centers. This problem is partially solved through session consistency mechanisms, where clients are provided with "replica tokens" that can be used for multiple operations within the same logical session, thus maintaining read-write consistency. However, maintaining session consistency between different clients requires clients to pass replica tokens to each other. For example, suppose clients A, B, and C add new users, then client D's application needs to see these three new users. In this scenario, client A creates its own user and passes the replica token to client B, which then passes it to client C, and finally, client D, in turn. While feasible, this consistency mechanism is not very convenient for clients.

[0026] To address these drawbacks, a naive solution for ensuring strong consistency might require synchronously replicating all writes to a specific replica to every other replica. However, it's impossible for a distributed system to simultaneously possess both "strong consistency" and "high availability." This type of synchronous replication is not scalable and will suffer a significant performance impact. However, complex application scenarios may require consistency across data centers.

[0027] Therefore, the embodiments disclosed herein allow clients to implement strong consistency while accepting a trade-off between potentially lower system availability and performance. The embodiments allow users to optionally require strong consistency during a write, making subsequent read calls across regions and identities visible to that write.

[0028] To achieve this goal, the embodiments enable data centers to independently determine which data center should receive writes to resources and any subsequent reads by including an optional strong consistency indicator in read or write requests. When a data center receives a request including a consistency indicator, the data center 1) detects the indicator, 2) determines which data center should handle the request, and 3) redirects the request to that data center.

[0029] Implementations for providing a consistent data view in the manner described above can be implemented in various ways. For example, Figure 1 A block diagram of an example distributed storage system 100 is shown, comprising multiple global data centers 102A-102N and clients 110, which are communicatively coupled via a public network 118. Each data center 102A-102N includes a corresponding request server among request servers 104A-104N, and each request server 104A-104N includes a corresponding strongly consistent request handler among strongly consistent request handlers 106A-106N (also referred to as "consistency request handlers"). Each data center 102A-102N also includes a corresponding data storage device among data storage devices 108A-108N. Based on... Figure 1 The following discussion of the distributed storage system 100, other structural and operational embodiments will be apparent to those skilled in the art(s) related to it.

[0030] Public network 118 is a publicly accessible network through which any number of computing devices (for simplicity) can be used. Figure 1The diagram only shows applications that client 110 can access in data centers 102A-102N. For example, request 112 can be received from client 110 by request server 104A in data center 102A via public network 118. Any number of clients 110 can exist, including several, dozens, hundreds, millions, or even more. In embodiments, distributed storage system 100 may include a networked system of multiple computers and / or processors, including dozens, hundreds, thousands, or even more computers and / or processors.

[0031] Client 110 can be any type of computing device, mobile or stationary, such as a desktop computer, server, video game controller, etc. Examples of client 110 include mobile computing devices (e.g., Devices, personal digital assistants, laptops, notebook computers, such as the Apple iPad TM Tablet computers, netbooks, etc.), mobile phones (e.g., cellular phones, such as Microsoft...) Telephone, Apple iPhone, Achieve Android TM Smartphones with operating systems, such as smartphones, and wearable computing devices (e.g., helmet devices including smart glasses, such as...). Glass TM Oculus VR company's Oculus Fixed computing devices such as desktop computers or PCs (personal computers), game consoles / systems (e.g., Microsoft...), etc. Sony Nintendo or etc.

[0032] Public network 118 may include one or more networks, such as a local area network (LAN), a wide area network (WAN), or an enterprise network, and may include one or more wired and / or wireless portions. In an embodiment, public network 118 includes the Internet.

[0033] Although request servers 104A-104N are shown as monolithic components within each of data centers 102A-102N, request servers 104A-104N can be implemented in any number of computing devices including servers, and can include any type and number of other resources, including resources that facilitate communication with and between computing devices connected via public network 118. In embodiments, the servers implementing request servers 104A-104N in data centers 102A-102N can be organized in any way, including being grouped into server racks (e.g., 8-40 servers per rack, referred to as nodes or "blade servers"), server clusters (e.g., 2-64 servers, 4-8 racks, etc.), or larger collections (e.g., thousands of servers, hundreds of racks, dozens of clusters, etc.). In an embodiment, the server request servers 104A-104N of data centers 102A-102N may be located in a common location (e.g., housed in one or more buildings together with associated components such as backup power, redundant data communication, environmental control, etc.), or may be arranged in other ways.

[0034] It should be understood that although request servers 104A-104N are configured to receive and process requests, in other embodiments, request servers 104A-104N may also be configured to host applications, including web applications, and thus can implement websites, web servers, web services, and / or other transaction processing applications. It should also be understood that embodiments of data centers 102A-102N and / or request servers 104A-104N may also include a collection of logical computing resources, which may or may not be physically distributed in the conventional sense.

[0035] like Figure 1 As shown, each of the data centers 102A-102N also includes a corresponding data storage device in the data storage devices 108A-108N. The data storage devices 108A-108N may include one or more of any type of storage mechanism for storing data, including disks (e.g., in hard disk drives), optical disks (e.g., in optical disk drives), magnetic tapes (e.g., in magnetic tape drives), storage devices such as RAM devices, ROM devices, etc., and / or any other suitable type of storage medium.

[0036] The data stored in data stores 108A-108N can be organized in virtually any way, including, for example, in tables within a relational database, as nodes in a graph database, a hierarchical database, or other types of databases. Furthermore, although in Figure 1While shown as a monolithic component, it should be understood that each data storage device in data storage devices 108A-108N may include multiple storage media and accompanying hardware, and may be organized into multiple databases, whether co-located or distributed. The general operation of embodiments of the distributed storage system 100 is further described below.

[0037] As described above, client 110 can send request 112 to a data center, such as data center 102A, etc. Figure 1 As shown below, as described in more detail below, client 110 may first connect to a gateway (not shown), which is responsible for determining which of the data centers 102A-102N the request should be routed to, as is known in the art. If client 110 wishes to be provided with guaranteed data consistency, ensuring the return of a current view of the requested resource, client 110 may include optional consistency indicators (e.g., flags, settings, attributes, or other types of parameters) in request 112. Such indicators may instruct the request server 104A of data center 102A that client 110 not only requests a consistent view of the requested resource, but also, as described in more detail below, may specify other aspects of the consistent data request, such as the scope of the requested consistency.

[0038] In an embodiment, the strongly consistent request handler 106A of the request server 104A can be configured to detect a consistency indicator and subsequently determine a preferred data center for retrieving the requested resource (i.e., a data center that guarantees a current view of the resource) and reroute the request to that data center. For example, as Figure 1 As shown, the strong consistency request handler 106A can determine that the resource requested in request 112 exists in data center 102B, and routes the redirected request 114 to data center 102B via public network 118. Subsequently, the request server 104B of data center 102B retrieves the requested resource from data storage device 108B (or causes it to be retrieved), and returns resource 116 to client 110 via public network 118.

[0039] Implementations of the strong consistency request handler 106 can be carried out in various ways. For example, Figure 2 A detailed schematic diagram 200 of an example strong consistency request handler 106 according to an embodiment is shown. Figure 1 Any one or more of the strong consistency request handlers 106A-106N can, according to Figure 2 This is implemented using a strong consistency request handler 106. The strong consistency request handler 106 includes a consistency indicator detector 202, a key determiner 204, a data center selector 206, and a request redirector 208. Based on... Figure 2 The following discussion of the strong consistency request handler 106 will be apparent to those skilled in the art as to other structural and operational embodiments.

[0040] like Figure 2 As shown, the consistency indicator detector 202 receives an incoming request 112. Request 112 can be configured in various ways. For example, as is known in the art, cloud storage solutions typically expose APIs (Application Programming Interfaces) that can be used by end-user applications, specifying the number and type of parameters that can be passed in read or write calls. Alternatively, request 112 operates via a RESTful web service (i.e., a web service conforming to a Representational State Transfer (REST) ​​architecture), whereby the URI (Uniform Resource Indicator) explicitly refers to the requested resource, and consistency-related parameters (e.g., consistency indicators and / or scope parameters) can be specified as headers. For example, request 112 can take the form of an HTTP (Hypertext Transfer Protocol) GET, where the requested URI refers to the requested resource, and the consistency header is incorporated into the header (or elsewhere).

[0041] As described above, such a consistency indicator can be included in request 112 if the caller desires a consistent view of the resource (i.e., the primary replica). For example, request 112 may include a header representing a ConsistencyLevel, the presence of which can be detected by the consistency indicator detector 202. In embodiments, the ConsistencyLevel header can be set to multiple values ​​to manage the consistency level desired by the caller. For example, the ConsistencyLevel header can be set to any of the application, user, or tenant to achieve different ranges of consistency guarantees.

[0042] In an embodiment, the strong consistency request handler 106 can be configured to implement application-level consistency by providing cross-datacenter consistency to all calls made by instances of the same application. Similarly, user-level consistency provides cross-datacenter consistency for all calls made by the same authenticated user, regardless of which application that user may be using to make the calls. Finally, tenant-level consistency provides cross-datacenter consistency for all calls made from a specific tenant (or equivalently, an organization). Such organization-level consistency calls can include calls from different users and / or applications, so application and / or user-level consistency may not be sufficient in some cases.

[0043] In an embodiment, it might be desirable to provide cross-datacenter consistency only to a subset of all calls scoped to a specific tenant / organization, as this could create unnecessary hotspots. Furthermore, providing global cross-datacenter consistency for all calls from across the entire organization could encounter performance / scalability issues. Therefore, the embodiment can also be configured to detect the ScenarioID header in request 112 whenever the ConsistencyLevel header is set to tenant, and provide cross-datacenter consistency only to calls related to the specific scenario marked by the included ScenarioID. In this way, cross-datacenter consistency can be implemented by multiple users and / or applications that need to share public data.

[0044] Return now Figure 2 The discussion of the strong consistency request handler 106, as described above, suggests that embodiments of the consistency indicator detector 202 can be configured to detect a consistency indicator (e.g., a ConsistencyLevel header) in request 112. If the consistency indicator detector 202 does not detect such a consistency indicator, request 112 can be processed locally within the current data center by the strong consistency request handler 106, without requiring cross-data center consistency guarantees. Alternatively, when the consistency indicator detector 202 detects a consistency indicator, request 112 is passed to both the key determiner 204 and the request redirector 208.

[0045] In an embodiment, key determiner 204 is configured to determine consensus key 212 at least in part based on request 112. As will be discussed in further detail below, the embodiment may then use consensus key 212 at data center selector 206 to determine the appropriate data center to receive the redirection request. In an embodiment, consensus key 212 may include a hash function value generated by a hash function shared across all data centers and common to all data centers. In an embodiment, key determiner 204 may be configured to perform rendezvous hashing (i.e., highest random weight hashing). More specifically, key determiner 204 may be configured to compute a hash value (i.e., consensus key 212) for each data center based on the identity of the resource requested in request 112 (e.g., resource URI). In an embodiment, each consensus key among the determined consensus keys may be weighted according to the weight associated with each data center, thereby allowing resources to be allocated to data centers based on their respective capacities.

[0046] In one embodiment, the consistency key 212 is then provided to the data center selector 206 to determine the preferred data center 214 for fulfilling the request. For example, the data center selector 206 may be configured to select the consistency key with the highest weighted value among the consistency keys 212, wherein the data center associated with the selected value is the preferred data center 214. For example, the data center selector 206 may maintain or access a data structure (e.g., an array, table, list, etc.) containing the association between data centers and consistency keys. In one embodiment, each data center may have a corresponding consistency key in the data structure. The data center selector 206 may search the data structure based on the consistency key selected in the consistency key 212 to determine the associated data center, which is the preferred data center 214. In other embodiments, the data center selector 206 may determine the preferred data center 214 in other ways based on the selected constant key. The preferred data center 214 is then passed to the request redirector 208.

[0047] In an embodiment, the request redirector 208 may be configured to accept a request 112 received by the strong consistency request handler 106 and a preferred data center 214 determined by the key determiner 204 and the data center selector 206. The request redirector 208 may then generate a redirected request 114, which is sent to the preferred data center 214 for processing. For example, the request redirector 208 may maintain or access a data structure indicating the communication addresses (e.g., IP addresses, domain names, etc.) of data centers that can send redirected requests to it.

[0048] In this embodiment, the redirected request 114 is a modified version of request 112, wherein the consistency indicator and any associated headers have been removed. When the redirected request 114 is subsequently received by the preferred data center 214, the request will be processed in a normal manner without strong consistency processing at that data center. However, by definition, the preferred data center 214 owns the primary copy of the requested resource, and the redirected request 114 implemented by the preferred data center 214 will satisfy the strong consistency requirement requested by client 110 in its original request 112.

[0049] Alternatively, the redirected request 114 may be a copy of request 112, including all the original headers but directed to preferred data center 214 for implementation. When the redirected request 114 is subsequently received by preferred data center 214, an instance of the strong consistency request handler 106 present in that data center can operate as described above, detecting the presence of a consistency indicator in the request, and subsequently determining the preferred data center via a rendezvous hash algorithm. Of course, since each instance of key determiner 204 uses the same hash function (i.e., because the hash function is shared across all data centers), the preferred data center is determined to be the current data center, and the request can be handled locally without redirection. In another embodiment, preferred data center 214 may be configured to detect that the redirected request 114 is actually a previously redirected request, and therefore handle the request locally. Although the examples and embodiments discussed herein generally refer to read operations (e.g., HTTP GET), it should be understood that embodiments are also configured to operate on write operations.

[0050] For example, suppose two clients, referred to as Client 1 and Client 2, have different authentication identities and use different applications to perform related tasks. For instance, suppose Client 1's application is creating a new user or login identity, while Client 2 needs to subsequently use the data associated with it. Further suppose Client 1 is very close to and connected to data center 1, while Client 2 is very close to and connected to data center 2, and each corresponding read and write request goes to the respective data center. In these cases, when Client 1 creates a new user with cross-data center requirements (i.e., by including a strong consistency indicator in the write request), the embodiment operates in the general manner described above and determines the preferred data center for the write operation.

[0051] For example, if the preferred data center is determined to be data center 3, write requests(s) to associated new user / login resources executed by user 1 will be redirected to data center 3, where these resources are ultimately stored, and subsequent reads by client 2 at data center 2 will similarly be redirected to data center 3, in order to achieve this in the general manner described above and in more detail below. Reference will now be made to... Figure 3 Further descriptions are provided in... Figure 1 and Figure 2 An embodiment of the distributed storage system 100 and the strong consistency request handler 106 is shown in the figure.

[0052] Figure 3 The illustration shows a request 112 that satisfies the strong consistency requirement according to an embodiment. Figure 1 Sequence diagram 300 of the distributed storage system 100. (Reference) Figure 1 and Figure 2 Sequence diagram 300 is described. However, based on the following text regarding... Figure 3 The discussion of sequence diagram 300, other structural and operational embodiments will be apparent to those skilled in the art(s).

[0053] Sequence diagram 300 satisfies read requests that require consistency across data centers. Therefore, it is assumed that the requested data was previously written. Sequence diagram 300 begins at the top left corner, where request 112 is delivered to gateway 302. In an embodiment, request 112 may include an HTTP GET and a Request-URI resolution pointing to gateway 302. Gateway 302 determines which data center in the global data centers 102A-102N should handle request 112.

[0054] In one embodiment, gateway 302 may be configured to forward request 112 to the data center geographically closest to client 110. Such a proximity-based approach may be appropriate if data centers are properly distributed to achieve good load balancing. However, in an alternative embodiment, gateway 302 may forward request 112 to another data center based on other criteria known in the art.

[0055] In the example shown in sequence diagram 300, gateway 302 forwards request 112 to Figure 1 Data Center 1 102A. (Example) Figure 3 As shown, the front end at data center 304 receives request 112. In an embodiment, the front end 304 itself may include, for example, Figure 1 The request server 104A is shown. Alternatively, frontend 304 can forward the request to another backend server. Assuming the former case, strong consistency request handler 106A receives request 112 and determines the preferred data center 210 in the general manner described above. After determining the preferred data center, frontend 304 can send the redirected request 114 back to gateway 302. In this embodiment, bound redirection is used to route the redirected request 114 back to gateway 302.

[0056] Upon receiving redirection request 114, gateway 302 forwards the request to the preferred data center (i.e., a data center known to hold a consistently consistent copy of the requested resource). In this example, redirection request 114 lands at frontend 306 of data center_2.

[0057] As mentioned above, a frontend 306 can be configured to handle the request itself, or more typically, to switch the request to a backend server for implementation. Figure 3Sequence diagram 300 illustrates the former, where the resource requested in redirected request 114 is retrieved from replica 308 (i.e., storage device) and returned to frontend 306 as resource 116. Resource 116 is then bubbled up in the hierarchy until it is delivered to client 110.

[0058] The following text combines Figure 4 describe Figure 1 Distributed storage system 100 and such Figure 2 Other operational aspects of the strong consistency request handler 106 shown. Figure 4 According to an embodiment, a flowchart 400 is shown as an example method for satisfying resource requests that include strong consistency requirements. Flowchart 400 continues to be referenced. Figure 1 and Figure 2 To describe it. However, based on the following about Figure 4 Flowchart 400 and Figure 1 The discussion of the distributed storage system 100, other structures and operational embodiments will be apparent to those skilled in the art(s).

[0059] Flowchart 400 begins at step 402. In step 402, a request for resources is received at the server, which is located in the first data center out of multiple data centers. The request includes a consistency indicator. For example, and referring to... Figure 1 In the distributed storage system 100 shown and described above, the request server 104A of data center_1 102A is configured to accept request 112 from client 110, wherein request 112 includes a consistency indicator as described above. Figure 4 Flowchart 400 continues in step 404.

[0060] In step 404, a preferred data center among multiple data centers for fulfilling the request is determined at least in part based on the request. For example, and continuing to refer to the distributed storage system 100 and the strong consistency request handler 106, the key determiner 204 of the strong consistency request handler 106 may be configured to determine the consistency key in part based on the request. Specifically, the key determiner 204 may be configured to compute a hash value (i.e., consistency key 212) for each data center based on the identity of the resource requested in request 112 (e.g., resource URI). Alternatively, the key determiner 204 may be configured to compute the consistency key 212 based on some other part of request 112 or other information accompanying request 112 (such as, for example, access tokens or other authorization information).

[0061] Data center selector 206 can be configured to subsequently select the consensus key with the highest weighted value among the consensus keys 212, wherein the data center associated with the selected value is the preferred data center 214. Alternatively, data center selector 206 can accept unweighted consensus keys 212 from key determiner 204, apply a predetermined data center weighting factor to each consensus key in consensus keys 212, and subsequently select the weighted consensus key with the highest weighted value, wherein the data center associated with the selected value is the preferred data center 214. Figure 4 Flowchart 400 ends in step 406.

[0062] In step 406, the request is redirected to the preferred data center. For example, and continuing to refer to the distributed storage system 100 and the strong consistency request handler 106, the request redirector 208 can be configured to accept the request 112 received by the strong consistency request handler 106 and the preferred data center 214 determined by the key determiner 204 and the data center selector 206. Thereafter, the request redirector 208 can generate a redirected request 114, which is sent to the preferred data center 214 for processing.

[0063] In the foregoing discussion of steps 402-406 of flowchart 400, it should be understood that these steps may sometimes be performed in a different order or even simultaneously with other steps. Other embodiments of operation will be apparent to those skilled in the art. It should also be noted that the foregoing general description of the operation of the distributed storage system 100 is provided for illustrative purposes only, and embodiments of the distributed storage system 100 may include different hardware and / or software and may operate in a different manner than described above. In fact, the steps of flowchart 400 can be performed in various ways.

[0064] For example, Figure 5 A flowchart 500 according to an embodiment is shown, which is a... Figure 4 The improved flowchart of flowchart 400 includes the use of a shared hash function. Therefore, please refer to [link / reference]. Figure 1 Distributed storage system 100 and Figure 2 The strong consistency request handler 106 is used to describe Figure 5 Flowchart 500. However, based on the following discussion of flowchart 500, other structural and operational embodiments will be apparent to those skilled in the art(s).

[0065] Flowchart 500 begins at step 502. In step 502, a hash value is determined from a hash function based at least in part on a consistency indicator, with each of the multiple data centers using the same hash function to determine the consistency key. For example, and continuing to refer to distributed storage system 100 and strong consistency request handler 106, the key determiner 204 of strong consistency request handler 106 can be configured to perform converged hashing (i.e., highest random weight hashing), wherein the hash function used by this algorithm is shared and identical among each instance of strong consistency request handler 106 in each of the global data centers 102A-102N. In an embodiment, the consistency key 212 determined by key determiner 204 is based entirely or partially on the hash value generated by the converged hash function described above. In an embodiment, key determiner 204 can be configured to determine the consistency key 212 only for data centers that can actually handle such requests. In other words, for example, local laws may require data residency, so the data itself may not be allowed to be stored outside the local area (e.g., the General Data Protection Regulation (“GDPR”) of the European Union (“EU”) requires that personal data of EU subjects not be stored in countries without data protection regulations equivalent to the GDPR, nor transferred through those countries). In such cases, implementations may exclude certain data centers for hashing purposes.

[0066] The steps in flowcharts 400 and / or 500 can be performed in an additional manner. For example, according to an embodiment, Figure 6 A flowchart 600 is shown for redirecting a request to a preferred data center via binding redirection, and wherein the flowchart 600 includes respectively... Figure 4 and Figure 5 The method steps in flowcharts 400 and / or 500 shown are modified or supplemented. Therefore, please refer to [link / reference needed]. Figure 1 Distributed storage system 100 and Figure 2 The strong consistency request handler 106 is used to describe Figure 6 Flowchart 600. However, based on the following discussion of flowchart 600, other structural and operational embodiments will be apparent to those skilled in the art(s).

[0067] Flowchart 600 begins at step 602. In step 602, a preferred data center is determined in the front end of the first data center. For example, and referring to... Figure 3 The sequence diagram 300 and its description, and further references Figure 1 Distributed storage system 100 and Figure 2The strongly consistent request handler 106, and the request server 104A of data center_1 102A can themselves include the front end of the data center. Therefore, an instance of the strongly consistent request handler 106 within request server 104A can determine, as Figure 2 The preferred data center 214 is shown, and a binding redirect is performed to redirect the request to the location as described above. Figure 3 The preferred data center is shown in sequence diagram 300.

[0068] III. Example Computer System Implementation

[0069] Each of the strong consistency request handlers 106A-106N, consistency indicator detector 202, key determiner 204, data center selector 206 and / or request redirector 208, and flowcharts 400, 500, and / or 600 can be implemented in hardware or in hardware combined with software and / or firmware. For example, the strong consistency request handlers 106A-106N, consistency indicator detector 202, key determiner 204, data center selector 206 and / or request redirector 208, and flowcharts 400, 500, and / or 600 can be implemented as computer program code / instructions configured to execute in one or more processors and stored in a computer-readable storage medium. Alternatively, the strong consistency request handlers 106A-106N, consistency indicator detector 202, key determiner 204, data center selector 206 and / or request redirector 208, and flowcharts 400, 500, and / or 600 can be implemented as hardware logic / electrical circuits.

[0070] For example, in an embodiment, strong consistency request handlers 106A-106N, consistency indicator detector 202, key determiner 204, data center selector 206 and / or request redirector 208, and one or more of flowcharts 400, 500 and / or 600, in any combination, can be implemented together in a SoC. The SoC may include an integrated circuit chip that includes a processor (e.g., a central processing unit (CPU), microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces and / or other circuitry, and may optionally execute received program code and / or include embedded firmware for performing functions.

[0071] Figure 7An exemplary implementation of the computing device 700 that can implement the embodiments is shown. For example, one or more of the client 110 and / or request servers 104A-104N can be implemented in one or more computing devices similar to the computing device 700 in the fixed or mobile computer embodiments, including one or more features and / or alternative features of the computing device 700. The description of the computing device 700 provided herein is for illustrative purposes and is not intended to be limiting. Embodiments can be implemented in other types of computer systems, as are known to those skilled in the art.

[0072] like Figure 7 As shown, computing device 700 includes one or more processors, referred to as processor circuitry 702, system memory 704, and a bus 706 coupling various system components, including system memory 704, to processor circuitry 702. Processor circuitry 702 is electrical and / or optical circuitry implemented in one or more physical hardware circuitry device elements and / or integrated circuit devices (semiconductor material chips or chips) as a central processing unit (CPU), microcontroller, microprocessor, and / or other physical hardware processor circuitry. Processor circuitry 702 can execute program code stored in a computer-readable medium, such as program code for operating system 730, application program 732, other programs 734, etc. Bus 706 represents any one or more of several types of bus architectures, including memory bus or memory controller, peripheral bus, accelerated graphics port, and processor or local bus using any of various bus architectures. System memory 704 includes read-only memory (ROM) 708 and random access memory (RAM) 710. Basic input / output system 712 (BIOS) is stored in ROM 708.

[0073] The computing device 700 also includes one or more of the following drives: a hard disk drive 714 for reading and writing to a hard disk, a disk drive 716 for reading or writing to a removable disk 718, and an optical disk drive 720 for reading or writing to a removable optical disk 722 (such as a CD-ROM, DVD-ROM, or other optical media). The hard disk drive 714, disk drive 716, and optical disk drive 720 are connected to the bus 706 via a hard disk drive interface 724, a disk drive interface 726, and an optical disk drive interface 728, respectively. The drives and their associated computer-readable media provide the computer with non-volatile storage of computer-readable instructions, data structures, program modules, and other data. While hard disks, removable disks, and removable optical disks have been described, other types of hardware-based computer-readable storage media, such as flash memory cards, digital video disks, RAM, ROM, and other hardware storage media, may also be used to store data.

[0074] Multiple program modules may be stored on a hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include an operating system 730, one or more application programs 732, other programs 734, and program data 736. Application programs 732 or other programs 734 may include, for example, computer program logic (e.g., computer program code or instructions) and / or other embodiments described herein for implementing strong consistency request handlers 106A-106N, consistency indicator detector 202, key determiner 204, data center selector 206 and / or request redirector 208, and flowcharts 400, 500, and / or 600 (including any appropriate steps of flowcharts 400, 500, and / or 600).

[0075] Users can input commands and information into computing device 700 through input devices such as keyboard 738 and pointing device 740. Other input devices (not shown) may include microphone, joystick, gamepad, satellite antenna, scanner, touch screen and / or touchpad, voice recognition system for receiving voice input, gesture recognition system for receiving gesture input, etc. These and other input devices are typically connected to processor circuitry 702 via serial port interface 742 coupled to bus 706, but may also be connected via other interfaces such as parallel port, game port, or Universal Serial Bus (USB).

[0076] The display screen 744 is also connected to the bus 706 via an interface such as the video adapter 746. The display screen 744 can be external to or incorporated into the computing device 700. The display screen 744 can display information or serve as a user interface for receiving user commands and / or other information (e.g., via touch, finger gestures, a virtual keyboard, etc.). In addition to the display screen 744, the computing device 700 may also include other peripheral output devices (not shown), such as speakers and printers.

[0077] Computing device 700 is connected to network 748 (e.g., the Internet) via an adapter or network interface 750, modem 752, or other means for establishing communication on the network. Figure 7 As shown, the modem 752, which can be built-in or external, can be connected to the bus 706 via the serial port interface 742, or it can be connected to the bus 706 using another interface type that includes a parallel interface.

[0078] As used herein, the terms “computer program medium,” “computer-readable medium,” and “computer-readable storage medium” are used to refer to physical hardware media such as a hard disk associated with hard disk drive 714, removable disk 718, removable optical disk 722, other physical hardware media such as RAM, ROM, flash memory cards, digital video disks, zip disks, MEM, nanotechnology-based storage devices, and other types of physical / tangible hardware storage media. Such computer-readable storage media are distinct from and do not overlap with communication media (excluding communication media). Communication media implement computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves. The term “modulated data signal” refers to a signal whose one or more characteristics are set or altered in a manner that encodes information in a signal. By way of example and not limitation, communication media include wireless media such as acoustic, RF, infrared, and other wireless media, as well as wired media. Embodiments also relate to such communication media that are separate from and do not overlap with embodiments relating to computer-readable storage media.

[0079] As described above, computer programs and modules (including application program 732 and other programs 734) can be stored on a hard disk, magnetic disk, optical disk, ROM, RAM, or other hardware storage media. Such computer programs can also be received via network interface 750, serial port interface 742, or any other interface type. When executed or loaded by an application, such computer programs enable the computing device 700 to implement the features of the embodiments described herein. Therefore, such computer programs represent the controller of the computing device 700.

[0080] The embodiments also relate to computer program products that include computer code or instructions stored on any computer-readable medium. Such computer program products include hard disk drives, optical disk drives, storage device packages, portable memory sticks, memory cards, and other types of physical storage hardware.

[0081] IV. Additional Example Implementations

[0082] This document provides a distributed storage system in a server, configured to provide a consistent view of resources stored in at least one of a plurality of data centers. In an embodiment, the system includes: a data center selector configured to determine, at least in part, a preferred data center among the plurality of data centers for fulfilling a request based on a request for a resource, the request being received at a first data center and including a consistency indicator; and a request redirector configured to redirect the request to the preferred data center.

[0083] In another embodiment of the aforementioned system, the system further includes: a consistency indicator detector configured to receive a request and detect a consistency indicator in the request; a key determiner configured to determine a consistency key based at least in part on the request; and a data center selector further configured to determine a preferred data center among a plurality of data centers for fulfilling the request based at least in part on the consistency key.

[0084] In one embodiment of the aforementioned system, the key determiner is configured to determine a hash value from a hash function based at least in part on a request, with each of the multiple data centers using the same hash function to determine a consistent key.

[0085] In an embodiment of the aforementioned system, the data center selector is configured to determine the preferred data center each time a request includes a consistency indicator.

[0086] In one embodiment of the above system, the data center selector is configured to determine a preferred data center in front of the first data center; and the request redirector is configured to redirect the request to the preferred data center using binding redirection.

[0087] In another embodiment of the aforementioned system, the scope of the consistency indicator is limited to at least one of the application, user, or organization.

[0088] In the aforementioned system embodiments, the scope of the consistency indicator is limited to the organization, and the consistency indicator also includes a scenario identifier.

[0089] This document provides a method for providing a consistent view of resources stored in at least one of a plurality of data centers. The method includes: receiving a request for a resource at a server located in a first data center of the plurality of data centers, the request including a consistency indicator; determining, at least in part, a preferred data center among the plurality of data centers for fulfilling the request based on the request; and redirecting the request to the preferred data center.

[0090] In an embodiment of the foregoing method, determining the preferred data center among a plurality of data centers for fulfilling the request, at least in part, based on the request includes: determining a consistency key at least in part based on the request; and determining the preferred data center based on the consistency key.

[0091] In another embodiment of the aforementioned method, determining the consistency key at least in part based on the request includes: determining a hash value from a hash function at least in part based on the request, wherein each of the multiple data centers uses the same hash function to determine the consistency key.

[0092] In one embodiment of the aforementioned method, the preferred data center is determined for each request, including the consistency indicator.

[0093] In embodiments of the foregoing method, the scope of the consistency indicator is limited to at least one of the application, user, or organization.

[0094] In another embodiment of the aforementioned method, determining the preferred data center includes: determining the preferred data center in the front end of the first data center; and wherein redirecting the request to the preferred data center includes: redirecting the request to the preferred data center using binding redirection.

[0095] In one embodiment of the aforementioned method, the scope of the consistency indicator is limited to the organization, and the consistency indicator also includes a scenario identifier.

[0096] This document provides a computer-readable storage device having computer program logic recorded thereon, which, when executed by at least one processor of a computing device, causes the at least one processor to perform operations to provide a consistent view of resources stored in at least one of a plurality of data centers, the operations including: receiving a request for resources in a first data center of the plurality of data centers, the request including a consistency indicator; determining, at least in part, a preferred data center among the plurality of data centers for fulfilling the request based on the request; and redirecting the request to the preferred data center.

[0097] In the aforementioned embodiments of the computer-readable storage device, determining a preferred data center among a plurality of data centers for fulfilling a request, at least in part based on a request, includes: determining a consistency key at least in part based on the request; and determining a preferred data center based on the consistency key.

[0098] In the aforementioned embodiments of the computer-readable storage device, determining the consistency key at least in part based on a request includes: determining a hash value from a hash function at least in part based on a request, wherein each of the multiple data centers uses the same hash function to determine the consistency key.

[0099] In the aforementioned embodiments of the computer-readable storage device, a preferred data center is determined for each request, including a consistency indicator.

[0100] In the aforementioned embodiments of the computer-readable storage device, determining the preferred data center includes: determining the preferred data center in front of the first data center; and wherein redirecting the request to the preferred data center includes: redirecting the request to the preferred data center using binding redirection.

[0101] In the aforementioned embodiments of the computer-readable storage device, the scope of the consistency indicator is limited to one of the application, user, or organization.

[0102] In the aforementioned embodiments of the computer-readable storage device, the scope of the consistency indicator is limited to the organization, and the consistency indicator also includes a scenario identifier.

[0103] V. Conclusion

[0104] While various embodiments of the disclosed subject matter have been described above, it should be understood that they are presented by way of example only and not as a limitation. Those skilled in the art will understand that various changes in form and detail may be made therein without departing from the spirit and scope of the embodiments as defined in the appended claims. Therefore, the breadth and scope of the disclosed subject matter should not be limited to any of the foregoing exemplary embodiments, but should be defined solely by the appended claims and their equivalents.

Claims

1. A method in a server for providing a consistent view of resources stored in at least one of multiple data centers, the method comprising: A request for the resource is received at the server, the server being a first data center among the plurality of data centers, the request including a consistency indicator; The presence of the consistency indicator in the request is detected. The consistency indicator includes identifying one of a plurality of cross-datacenter consistency ranges for the requested resource, each cross-datacenter consistency range indicating the level of consistency of the requested resource across the plurality of datacenters. as well as In response to the detection of the presence of the consistency indicator: The consensus key is determined at least in part based on the request; The preferred data center among the plurality of data centers for fulfilling the request is determined at least in part based on the consensus key; and The request is redirected to the preferred data center.

2. The method according to claim 1, wherein determining the preferred data center comprises: The preferred data center is determined in the front end of the first data center; and The redirection of the request to the preferred data center includes: Use binding redirection to redirect the request to the preferred data center.

3. The method of claim 1, wherein the scope of the consistency indicator is limited to at least one of an application, a user, or an organization.

4. The method of claim 1, wherein the scope of the consistency indicator is limited to the organization, and the consistency indicator further includes a scenario identifier.

5. A method in a server for providing a consistent view of resources stored in at least one of multiple data centers, the method comprising: A request for the resource is received at the server, the server being a first data center among the plurality of data centers, the request including a consistency indicator; Detect the presence of the consistency indicator in the request; as well as In response to the detection of the presence of the consistency indicator: The consistency key is determined at least in part based on the request, the determination including determining a hash value from a hash function at least in part based on the request, each of the plurality of data centers using the same hash function to determine the consistency key; The preferred data center among the plurality of data centers for fulfilling the request is determined at least in part based on the consensus key; and The request is redirected to the preferred data center.

6. The method of claim 5, wherein the preferred data center is determined for each request including a consistency indicator.

7. The method of claim 5, wherein the hash function comprises a highest random weight hash function.

8. A distributed storage system in a server, the distributed storage system being configured to provide a consistent view of resources stored in at least one of multiple data centers, the distributed storage system comprising: One or more processors; as well as One or more memory devices accessible by the one or more processors, the one or more memory devices storing program code configured to be executed by the one or more processors to perform operations, the operations including: The server receives a request for the resource, the request including a consistency indicator; The presence of the consistency indicator in the request is detected, the consistency indicator comprising identifying one of a plurality of cross-datacenter consistency ranges for the requested resource, each cross-datacenter consistency range indicating the level of consistency of the requested resource across the plurality of datacenters; and In response to the detection of the presence of the consistency indicator: The consensus key is determined at least in part based on the request; The preferred data center among the plurality of data centers for fulfilling the request is determined at least in part based on the consensus key; and The request is redirected to the preferred data center.

9. The distributed storage system according to claim 8, wherein the operation further comprises: The preferred data center is determined in the front end of the first data center among the plurality of data centers; as well as Use binding redirection to redirect the request to the preferred data center.

10. The distributed storage system of claim 8, wherein the scope of the consistency indicator is limited to at least one of an application, a user, or an organization.

11. The distributed storage system of claim 8, wherein the scope of the consistency indicator is limited to the organization, and the consistency indicator further includes a scenario identifier.

12. A distributed storage system in a server, the distributed storage system being configured to provide a consistent view of resources stored in at least one of multiple data centers, the distributed storage system comprising: One or more processors; as well as One or more memory devices accessible by the one or more processors, the one or more memory devices storing program code configured to be executed by the one or more processors to perform operations, the operations including: The server receives a request for the resource, the request including a consistency indicator; Detect the presence of the consistency indicator in the request; and In response to the detection of the presence of the consistency indicator: The consistency key is determined at least in part based on the request, the determination including determining a hash value from a hash function at least in part based on the request, each of the plurality of data centers using the same hash function to determine the consistency key; The preferred data center among the plurality of data centers for fulfilling the request is determined at least in part based on the consensus key; and The request is redirected to the preferred data center.

13. The distributed storage system of claim 12, wherein the hash function comprises a highest random weight hash function.

14. A computer-readable storage device having computer program logic recorded on it, the computer program logic, when executed by at least one processor of a computing device, causing the at least one processor to perform operations to provide a consistent view of resources stored in at least one of a plurality of data centers, the operations including: A request for the resource is received in a first data center among the plurality of data centers, the request including a consistency indicator; The presence of the consistency indicator in the request is detected. The consistency indicator includes identifying one of a plurality of cross-datacenter consistency ranges for the requested resource, each cross-datacenter consistency range indicating the level of consistency of the requested resource across the plurality of datacenters. In response to the detection of the presence of the consistency indicator: The consensus key is determined at least in part based on the request; The preferred data center among the plurality of data centers for fulfilling the request is determined at least in part based on the consensus key; and The request is redirected to the preferred data center.

15. The computer-readable storage device of claim 14, wherein the preferred data center is determined for each request including a consistency indicator.

16. The computer-readable storage device of claim 14, wherein determining the preferred data center comprises: The preferred data center is determined in the front end of the first data center; and The redirection of the request to the preferred data center includes: Use binding redirection to redirect the request to the preferred data center.

17. The computer-readable storage device of claim 14, wherein the scope of the consistency indicator is limited to at least one of an application, a user, or an organization.

18. The computer-readable storage device of claim 14, wherein the scope of the consistency indicator is limited to the organization, and the consistency indicator further includes a scenario identifier.

19. A computer-readable storage device having computer program logic recorded thereon, the computer program logic, when executed by at least one processor of a computing device, causing the at least one processor to perform operations to provide a consistent view of resources stored in at least one of a plurality of data centers, the operations including: A request for the resource is received in a first data center among the plurality of data centers, the request including a consistency indicator; Detect the presence of the consistency indicator in the request; as well as In response to the detection of the presence of the consistency indicator: The consistency key is determined at least in part based on the request, the determination including determining a hash value from a hash function at least in part based on the request, each of the plurality of data centers using the same hash function to determine the consistency key; The preferred data center among the plurality of data centers for fulfilling the request is determined at least in part based on the consensus key; and The request is redirected to the preferred data center.

20. The computer-readable storage device of claim 19, wherein the hash function comprises a highest random weight hash function.

Images