Global metadata service methods and systems

Abstract

Systems and methods utilize a Global Metadata Service (GMS) as a centralized authority for globally unique metadata, supported by Global Metadata Region Agents (GMRAs) within each region to enhance fault tolerance and minimize latency, while ensuring metadata uniqueness in geographically distributed systems. In embodiments, GMRAs maintain a read-only cache of metadata replicated from the GMS to enable local access for regional subsystems, thereby reducing network latency for read operations and ensuring availability during GMS outages. In the event of a permanent GMS failure, metadata may be reconstructed from GMRA's read-only copies. Independent upgrade paths for GMS, GMRAs, and subsystems prevent application programming interface incompatibilities and minimize downtime by removing the need for synchronized upgrades. Depending on deployment needs, GMS may coexist with regions for low latency or adopt a geographically distributed configuration for disaster recovery, with a co-located standby GMS to ensure high availability.

Description

Attorney Docket No. 120179-0590W001GLOBAL METADATA SERVICE METHODS AND SYSTEMSBACKGROUNDField

[0001] The present disclosure is generally directed to metadata management, and more specifically, to systems and methods for maintaining the strict uniqueness of globally unique metadata in geographically distributed systems, while ensuring metadata consistency and availability across distributed regions.Related Art

[0002] Object storage systems are critical for modem distributed architectures in that they enable scalable and reliable data storage across geographically dispersed regions. Ensure strict uniqueness of globally unique metadata is key challenge for operations like replication, retrieval, and updates. Traditional approaches that rely on centralized repositories or quorum¬ based consensus algorithms face numerous limitations, including high latency, inefficiency in multi-region configurations, and vulnerability to outages. Accordingly, it is desirable to have systems that enforce strict global metadata uniqueness, while ensuring availability, fault tolerance, and low latency even in geographically distributed and failure-prone environments.SUMMARY

[0003] In embodiments, a single-source global metadata service (GMS) serves as the single source of unique global metadata (GM) in a geographically distributed system where global metadata is shared across all regions. Each region may comprise a global metadata region agent (GMRA) that is accessed by a subsystem, located in the same region, to retrieve global metadata. The GMRA maintains a read-only copy of the global metadata, which is replicated from GMS to GMRA to provide local access.

[0004] In the event of a GMS failure, the GMRA continues to serve read requests for global metadata from a subsystem, while rejecting write requests to ensure the integrity and uniqueness of the metadata. Conversely, in the event of a permanent GMS failure, global metadata, stored in the GMS may be recovered from the read-only copy maintained by one or more GMRAs. To minimize network latency between a region and the GMS, the GMRA may serve read requests for global metadata directly from its read-only cache. In embodiments, GMS, GMRA and subsystem may use separate installers to allow for independent upgrades.Attorney Docket No. 120I79-0590W001

[0005] In addition, to prevent interface incompatibility, updates to GM may be managed sequentially as follows: the GMS and GMRA are upgraded first, e.g., independently from each other, followed by the subsystem. When changes are isolated to the subsystem, only the subsystem is upgraded, leaving the GMS and GMRA unchanged, e.g., to reduce unnecessary update time and system downtime.

[0006] In embodiments, a GMS may be deployed in various configurations to meet performance and fault tolerance requirements. The GMS can be located in the same geographical location with a region; it can be situated in a geographically separate location from all regions; or it may be distributed and coexist across two or more regions. These deployment options provide increased flexibility and fault tolerance in metadata management, while reducing latency and recovery requirement.

[0007] In some aspects of the present disclosure, a method for managing globally unique metadata in a geographically distributed environment comprises: in response to receiving, at a GMRA comprising a local cache, a read request for metadata from a subsystem located within a same region as the GMRA, providing the subsystem with the metadata that, is globally unique and has been obtained from a GMS, wherein the subsystem requests the metadata from the GMS via the GMRA, which forwards the metadata from the GMS to the subsystem during regular operation and, during a period of GMS unavailability, provides the metadata to the subsystem from a read-only copy of the metadata maintained by one or more GMRAs; in response to receiving a write request for the metadata when the GMS is temporarily unreachable, rejecting the write request to prevent conflicting updates and maintain uniqueness of the metadata by ensuring that write operations are handled by the GMS; in response to detecting a permanent failure of the GMS, providing the read-only copy to enable a recovery of the metadata by a new instance of the GMS; and maintaining compatibility with both older and newer API versions by using separate installers to enable an independent update of the GMRA and the subsystem, without requiring concurrent upgrades to the GMS or the one or more GMRAs, thereby ensuring subsystem availability and reducing system downtime.

[0008] In some aspects, the read-only copy maintained by the GMRA is used to locally serve the read request to its respective subsystem to reduce a latency that would otherwise result from a network communication with the GMS, and providing the read-only copy comprises recovering the metadata by reinstalling the GMS and repopulating it from the read-only copy by the one or more GMRAs.

[0009] In some aspects, using separate installers comprises providing distinct installers for the GMS, the GMRA, and the subsystem to enable sequential and independent upgrades ofAttorney Docket No. 120179-0590W001components. In some aspects, upgrades to the GMS and GMRAs may be performed before subsystem upgrades when a schema change is made to the metadata or associated APIs, thus reducing downtime and maintaining the subsystem availability. In some aspects, a GMRA may be configured to support the older and newer API versions, thereby enabling communication with a subsystem that has not yet been upgraded.

[0010] In some aspects, rejecting the write request further comprises generating an error message that indicates that the GMS is unavailable and providing the error message to the subsystem. In some aspects, the GMS may comprise a failure detection mechanism that triggers the GMRA to operate in a read-only mode upon detecting that the GMS is unavailable. Some aspects may further comprise periodically synchronizing the read-only copy maintained by the GMRA with the GMS. In some aspects, the subsystem communicates with the GMRA using a standardized API, allowing interoperability with a third-party system and ensuring an architecture extensibility.

[0011] In some aspects, a system for managing globally unique metadata in a geographically distributed environment comprises: a GMS configured to store and manage metadata that is globally unique; a GMRA associated with a region and a local cache, the local cache configured to maintain a read-only copy of the metadata replicated from the GMS; a subsystem located within a region and configured to communicate with the GMRA to access tlie metadata, wherein the GMRA is configured to perform steps comprising: in response to receiving a read request, providing tire subsystem with the metadata from the local cache when the GMS is temporarily unavailable and forwarding the metadata from the GMS to the subsystem during regular operation; in response to receiving a write request for the metadata when the GMS is temporarily unavailable, rejecting the write request to maintain the uniqueness of the metadata by ensuring that write operations are handled by the GMS; in response to detecting a permanent failure of the GMS, enabling recovery of the metadata by providing the read-only copy of the metadata to repopulate a new instance of the GMS, wherein the GMRA and subsystem are configured to maintain compatibility with older and newer API versions; and separate installers for the GMS, the GMRA, and the subsystem to enable independent upgrades of the GMRA and the subsystem without requiring concurrent upgrades to the GMS or other GMRAs, thereby ensuring subsystem availability and reducing system downtime.

[0012] In some aspects, the GMRA may generate an error message that indicates that the GMS is unavailable and provides the error message to the subsystem.Attorney Docket No. 120179-0590W001

[0013] In some aspects, rejecting the write request may further comprise generating an error message that indicates that the GMS is unavailable and providing the error message to the subsystem. In some aspects, the GMS may comprise a failure detection mechanism that triggers the GMRA to operate in a read-only mode upon detecting that the GMS is unavailable. In some aspects, the GMS and the GMRA upgrade before the subsystem when a schema change is made to the metadata or associated APIs, thereby reducing downtime and maintaining the subsystem availability.

[0014] Aspects of the present disclosure can involve a system, which can involve means for, in response to receiving, at a GMRA comprising a local cache, a read request for metadata from a subsystem located within a same region as the GMRA, providing the subsystem with the metadata that is globally unique and has been obtained from a GMS, wherein the subsystem requests the metadata from the GMS via the GMRA, which forwards the metadata from the GMS to the subsystem during regular operation and, during a period of GMS unavailability, provides the metadata to the subsystem from a read-only copy of the metadata maintained by one or more GMRAs; means for, in response to receiving a write request for the metadata when the GMS is temporarily unreachable, rejecting the write request to prevent conflicting updates and maintain uniqueness of the metadata by ensuring that write operations are handled by the GMS; means for, in response to detecting a permanent failure of the GMS, providing the read-only copy to enable a recovery of the metadata by a new instance of the GMS; and means for maintaining compatibility with both older and newer API versions by using separate installers to enable an independent update of the GMRA and the subsystem, without requiring concurrent upgrades to the GMS or the one or more GMRAs, thereby ensuring subsystem availability and reducing system downtime.Attorney Docket No. 120179-0590W001BRIEF DESCRIPTION OF DRAWINGS

[0015] FIG. 1 illustrates a system 100 for managing globally unique metadata in a geographically distributed environment according to various embodiments of the present disclosure.

[0016] FIG. 2 illustrates another system for managing globally unique metadata in a geographically distributed environment according to various embodiments of the present disclosure.

[0017] FIG. 3 illustrates a system in a distributed architecture in which a GMS is distributed to more than one location, according to various embodiments of the present disclosure.

[0018] FIG. 4 is a flowchart illustrating an exemplary process for managing globally unique metadata in a geographically distributed environment, in accordance with various embodiments of the present disclosure.

[0019] FIG. 5A and FIG. 5B are flowcharts illustrating exemplary’ read processes for managing globally unique metadata in a system during respective normal operation and during GMS inaccessibility, in accordance with various embodiments of the present disclosure.

[0020] FIG. 6A and FIG. 6B are flowcharts illustrating exemplary write processes for managing globally unique metadata in a system during respective normal operation and during GMS inaccessibility, in accordance with various embodiments of the present disclosure.

[0021] FIG. 7 illustrates an example computing environment, in accordance with various embodiments of the present disclosure.Attorney Docket No. 120179-0590W001DETAILED DESCRIPTION

[0022] The following detailed description provides details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity'. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term ‘‘automatic’1may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of ordinary skill in the art practicing implementations of the present application. Selection can be conducted by a user through a user interface or other input means, or can be implemented through a desired algorithm. Example implementations as described herein can be utilized either singularly or in combination and the functionality of the example implementations can be implemented through any means according to the desired implementations.

[0023] Geographically replicated systems oftentimes manage unique metadata that must be consistently shared across all replicated regions. For example, Amazon’s AWS S3 storage offers a feature called Cross Region Replication that replicates objects, organized into containers called buckets, across multiple geographic regions. Each bucket comprises files and associated metadata, such as filenames and permissions, which are stored in a metadata database. To preserve metadata integrity, bucket names must be globally unique, thus, prohibiting the assignment of the same bucket name to multiple buckets, whether across regions or within the same region. This strict enforcement of uniqueness is critical for maintaining consistency in operations like replication, retrieval, and updates.

[0024] Challenges arise when geographically distributed systems that comprise multiple regions attempt to maintain the strict uniqueness of globally unique metadata across regions. For example, if the metadata resides in a single centralized location that experiences an outage, all regions will lose access to that metadata. In the event of a permanent outage at the metadata’s location, regions are permanently deprived of access to globally unique metadata. Additionally, when the metadata is stored in a geographically distant location relative to certain regions, accessing it can result in significant network latency.

[0025] GMS management methods and systems described herein overcome such limitations by providing metadata uniqueness for geographically distributed environments. Various embodiments eliminate the dependency on quorum -based algorithms by enabling reliable agreement mechanisms that operate even in configurations with only two regions. ThisAttorney Docket No. 120179-0590W001ensures metadata consistency and synchronization without requiring a majority threshold. Further, GMS-based approaches minimize network latency by enabling efficient local access to metadata for regions, regardless of geographic distance, even in configurations with only a single region. Moreover, by decoupling metadata updates and upgrades, the GMS allows independent updates to either the GMRA’s or subsystems, thereby removing the need for synchronized upgrades, simplifying maintenance tasks, and reducing system downtime. To mitigate risks associated with reliance on a single location, various systems and methods incorporate redundancy and recovery mechanisms, ensuring that globally unique metadata remains accessible and recoverable even in the event of a complete loss of the original metadata location.

[0026] FIG. 1 illustrates a system 100 for managing globally unique metadata in a geographically distributed environment according to various embodiments of the present disclosure. System 100 comprises GMS 102 that may hold a repository of global metadata 104. In embodiments, GMS 102 serves as the single owner of GM 104 that facilitates metadata integrity and synchronization across all regions. Each region 120, 130 may connect to GMS 102 via Wide Area Network (WAN) 110 (e.g., internet). Communication over WAN 110 introduces some degree of network latency, which system 100 addresses by incorporating local caching and replication mechanisms. As depicted, each region 120, 130 may comprise a respective GMRA (GMRA 122 in region 120 and GMRA 132 in region 130) and a subsystem 126 and 136, respectively. Each GMRA may serve as an intermediary between the subsystem in its region and GMS 102, thereby facilitating access to GM 104 while maintaining consistency. GMRAs 122, 132 and subsystems 126, 136 within each respect region 120, 130 may be connected via high-speed local area networks (not shown) to reduce the impact of WAN latency on local operations.

[0027] In embodiments, each GMRA maintains a database comprising a read-only copy of GM 104, populated via replication from GMS 102. For example, GMRA 122 holds read-only copy 124, and GMRA 132 holds read-only copy 134. In embodiments, replicated copies allow subsystems (e.g., 126) to locally access metadata, significantly reducing WAN latency during read operations. Unlike the co-located system embodiments described further below with reference to FIG. 2, where the GMS and the GMRA share the same physical location, system 100 relies on replication and caching to optimize performance, while maintaining a centralized GMS architecture.

[0028] During operation, system 100 enforces strict uniqueness of globally unique metadata, such as bucket names, across regions. For example, when a bucket is created inAttorney Docket No. 120179-0590W001region 120, GMRA 122 communicates with GMS 102 to ensure the name is unique and does not conflict with existing buckets in other regions (here, region 130). Once verified, the bucket is created, and GMS 102 is updated to reflect the new metadata. GMRA 122 does not store changes locally; instead, it forwards updates to GMS 102 to process metadata changes. After die update is processed, GMRA 122 receives the result asynchronously via the replication mechanism to ensure that its read-only local copy remains consistent with tire global metadata maintained by GMS 102. This is useful to prevent collisions and other unwanted side-effects that may otherwise interfere with proper system operation, even when multiple regions operate independently.

[0029] In embodiments, GMS 102 ensures that updates to GM 104 requested by one region are immediately visible to all other regions to maintain synchronization across the distributed system. Subsystems may access GM 104 via the GMRA’s API, while the GMRA may communicate with GMS 102 using its own API. From the perspective of a subsystem, the GMRA appears to own GM 104. However, GMS 102 remains the single, unique owner of GM 104, ensuring centralized authority over global metadata. Advantageously, this aids in preventing conflicting updates and ensures metadata uniqueness across all regions.0030 In the event of a temporary outage where GMS 102 becomes inaccessible, GMRA 122 in region 120 may serve read requests from its local read-only copy 124 to ensure uninterrupted operation for subsystem 126. During normal operation, GMRA 122 does not store changes locally before forwarding write requests to GMS 102. Contrariwise, in embodiments, write requests are rejected to preserve the integrity of globally unique metadata, as GMRA 122 does not have ownership of GM 104. Advantageously, such fallback mechanisms provide reliability without compromising metadata uniqueness. In embodiments, unlike the distributed GMS architecture described in FIG. 3 that incorporates stand-by instances for disaster recovery, system 100 relies on deploying a new GMS instance in the event of a permanent failure. For example, if GMS 102 is destroyed, a newly deployed instance of GMS can restore GM 104 using the read-only copies maintained by GMRAs, such as GMRA 122. or GMRA 132.

[0031] System 100 also addresses limitations of traditional quorum-based algorithms, which are often used for agreement on updates across nodes in a cluster in traditional distributed systems. Such algorithms require a majority of nodes for consensus and are, thus, infeasible in configurations with only two regions that cannot achieve quorum because a majority is impossible to determine. High network latencies between geographically distant regions further exacerbate the inefficiencies of such algorithms, leading to slower responseAttorney Docket No. 120179-0590W001times and potential inconsistency in metadata agreement. Unlike the stand-by GMS configuration in FIG. 3, which resolves quorum inefficiencies by mirroring metadata, in embodiments, system 100 achieves metadata synchronization using agreement mechanisms suitable for centralized GMS architectures.

[0032] In embodiments, system 100 simplifies maintenance tasks by decoupling updates for its components. GMS 102, GMRA 122, and subsystem 126 each may comprise separate installers to enable independent upgrades. For example, when a schema changes is made to GM 104, both GMS 102 and GMRA API versions should be upgraded prior to upgrading subsystems (e.g., 126) to avoid an incompatibility between them, followed by subsystem upgrades. In embodiments, a newer version of GMRAs may support both older and newer versions of their APIs to enable all subsystems that have yet to be upgraded to communicate with the new GMRA. To reduce system downtime, in embodiments, subsystem 126 may be upgraded independently of GMS 102 and GMRA 122, e.g., when no changes to GM 104 are required but subsystem 126 requires some type of update. It is understood that additional or other installers may be employed to orchestrate, e.g., sequential, upgrades for two or more installations, to ensure a proper order of install operations.

[0033] FIG. 2 illustrates another system for managing globally unique metadata in a geographically distributed environment according to various embodiments of the present disclosure. Unlike the system in FIG. 1, region 120 in system 200 is co-located in a same location 240 with GMS 202 holding GM 204, GMRA 222, and subsystem 226. In such embodiments, location 240, which may represent a customer data center m a geographic location associated with region 120 configured to create buckets for data storage, may serve as a centralized hub for metadata operations within region 120. Region 130 associated with another location may represent another customer data center in a different geographic region, here location 250.

[0034] As depicted, location 240, which comprises GMRA 222, read-only copy 224, and subsystem 226, is coupled, via WAN 110, to location 250, which comprises GMRA 232, read¬ only copy 234, and subsystem 236. In the example in FIG. 2, GMS 202, GMRA 222, and subsystem 226 in location 240 share the same high-speed local area network (not shown), minimizing latency among these components. As a result, network latency and WAN latency between GMS 202 and its local GMRA 2.22 or subsystem 226 are negligible during normal operation.

[0035] Similar to FIG. 1, the architecture of system 200 ensures metadata consistency across regions 120 and 130, while providing a certain degree of fault tolerance. The centralizedAttorney Docket No. 120179-0590W001co-location of GMS 202 with GMRA 222 and subsystem 226. advantageously, reduces communication overhead within location 240.

[0036] Further, in various embodiments, to maintain metadata uniqueness in the event of a failure scenario, such as an earthquake that could compromise operations if the only GMS 202, region, or location is destroyed as a whole, it would be beneficial to have a system with built- in redundancies. Such redundancies, as further illustrated in the distributed architecture discussed next with reference to FIG. 3, may help to protect against potential catastrophic failure modes.

[0037] FIG. 3 illustrates a system in a distributed architecture in which a GMS is distributed to more than one location, according to various embodiments of die present disclosure. Similar to FIG. 2, location 240 represents a customer data center in the geographic locations associated with region 120; and location 250 represents another customer data center in a geographic location associated with region 130. GMS 352 (depicted with dotted lines in FIG. 3 and comprising GM 354) represents a stand-by GMS that, in embodiments, normally remains inactive as long as GMS 302 remains active and in location 240.[0038 During operation, GM 304 may be synchronously mirrored and updated from active GMS 302. to stand-by GMS 352. In embodiments, in the event that location 240, and thus active GMS 302, is destroyed, stand-by GMS 352 may become active. Such distributed GMS embodiments, where GMS 302 is distributed to more than one location from which global metadata can be restored from a read-only copy maintained by an GMRA by utilizing the nearest available GMS instance, are characterized by high overall GMS availability and low- latency access to metadata. By distributing GMS across multiple locations, system 300 reduces reliance on single points of failure and that ensures metadata remains consistent and available even in multi-region failure scenarios, thus enhancing the robustness of disaster recovery.

[0039] FIG. 4 is a flowchart illustrating an exemplary’ process for managing globally unique metadata in a geographically distributed environment, in accordance with various embodiments of the present disclosure. In embodiments, process 400 may start when, at step 402, at GMRA that comprises a local cache receives a read request for metadata, which is globally unique and has been obtained from a GMS, from a subsystem that is located within the same region as the GMRA. During regular operation, the GMRA may forward the metadata from the GMS to the subsystem and, during a period of GMS unavailability, provides the metadata to the subsystem from a read-only’ copy of the metadata it maintains in the local cache.

[0040] At step 404, in response to receiving a write request for the metadata when the GMS is temporarily unreachable, the GMRA may reject the write request to prevent conflictingAttorney Docket No. 120179-0590W001updates and maintain uniqueness of the metadata by ensuring that write operations are exclusively handled by the GMS.

[0041] At step 406, in response to detecting a permanent failure of the GMS, the GMRA may provide the read-only copy to the subsystem such as to enable a recovery of the metadata by a new instance of the GMS.

[0042] Finally, at step 408, to maintaining compatibility with both older and newer API versions, separate installers may be utilized to enable an independent update of the GMRA and the subsystem, without requiring concurrent upgrades to the GMS or the one or more GMRAs, thereby ensuring subsystem availability and reducing system downtime.

[0043] It is noted that although the invention is generally described in the context of active-active replication scenario, it is understood that this is not intended to limit the scope of the present disclosure to such embodiments as the systems and methods for managing globally unique metadata described herein may be used in any other scenario not involving active-active replications.

[0001] One skilled in the art shall recognize that: (1) certain steps may optionally be performed; (2) steps may not be limited to the specific order set forth herein; (3) certain steps may be performed in different orders; and (4) certain steps may be done concurrently.

[0044] FIG. 5A and FIG. 5B are flowcharts illustrating exemplary read processes for managing globally unique metadata in a system during respective normal operation and during GMS inaccessibility, in accordance with various embodiments of the present disclosure.

[0045] In embodiments, process 500 for a regular read operation may' start at step 502, when a subsystem such as those shown, for example, in FIG. 1, requests global metadata from a corresponding GMRA.

[0046] At step 504, upon receipt of the request, the GMRA may then request the global metadata from a GMS to which the GMRA is communicatively coupled, e.g., via the internet.

[0047] At step 506, the GMS reads the global metadata, e.g., from its own database and communicates the result back to the GMRA.

[0048] Finally, at step 10 the GMRA makes the received global metadata available to the inquiring subsystem.

[0049] In embodiments, process 550 for read operations when GMS is inaccessible starts at step 552, w'hen the subsystem requests global metadata from the GMRA.

[0050] At step 554, the GMRA determines that the GMS is inaccessible, e.g., for a predetermined period of time.Attorney Docket No. 120179-0590W001

[0051] At step 556, the GMRA reads the global metadata from its own local database and communicate that metadata to the subsystem.

[0052] FIG. 6A and FIG. 6B are flowcharts illustrating exemplary’ write processes for managing globally unique metadata in a system during respective normal operation and during GMS inaccessibility, in accordance with various embodiments of the present disclosure.

[0053] In embodiments, process 600 for a regular write operation may start at step 602, when the subsystem writes global metadata to a corresponding GMRA.

[0054] At step 604, the GMRA communicates global metadata to the GMS.

[0055] At step 606, the GMS uses the global metadata to update its database accordingly.

[0056] At step 608, the GMS returns an acknowledgement signal to the GMRA,

[0057] Finally, at step 610, the GMS recei ves an acknowledgement signal from the GMRA.

[0058] In embodiments, process 650 for write operations when GMS is inaccessible starts at step 652, when the subsystem receives a write request to write global metadata to the GMRA.

[0059] At step 654, it the GMRA determines that the GMS is unavailable to handle a write operation, the GMRA determines that the GMS returns an error message to the subsystem to prevent conflicting updates, thereby maintain uniqueness of the metadata.

[0060] FIG. 7 illustrates an example computing environment with an example computer device suitable for use in some example implementations, in accordance with various embodiments of the present disclosure. Computer device 705 in computing environment 700 can include one or more processing units, cores, or processors 710, memory 715 (e.g., RAM, ROM, and / or the like), internal storage 720 (e.g., magnetic, optical, solid-state storage, and / or organic), and / or I / O interface 725, any of which can be coupled on a communication mechanism or bus 730 for communicating information or embedded in the computer device 705. I / O interface 725 is also configured to receive images from cameras or provide images to projectors or displays, depending on the desired implementation.

[0061] Computer device 705 can be communicatively coupled to input / user interface 735 and output device / interface 740. Either one or both of input / user interface 735 and output device / interface 740 can be a wired or wireless interface and can be detachable. Input / user interface 735 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch-screen interface, keyboard, a pointing / cursor control, microphone, camera, braille, motion sensor, optical reader, and / or the like). Output device / interface 740 may include a display, television, monitor, printer, speaker, braille, or the like. In some example implementations, input / user interface 735 and output device / interface 740 can be embedded with or physically coupled to the computer device 705. In other exampleAttorney Docket No. 120179-0590W001implementations, other computer devices may function as or provide the functions of input / user interface 735 and output device / interface 740 for a computer device 705.

[0062] Examples of computer device 705 may include highly mobile devices (e.g., smartphones, devices in vehicles and other machines, devices carried by humans and animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded therein and / or coupled thereto, radios, and the like).0063 Computer device 705 can be communicatively coupled (e.g., via I / O interface 725) to external storage 745 and network 750 for communicating with any number of networked components, devices, and systems, including one or more computer devices of the same or different configurations. Computer device 705 or any connected computer device can be functioning as, providing services of, or referred to as a server, client, thin server, general machine, special-purpose machine, or another label.

[0064] I / O interface 725 can include wired and / or wireless interfaces using any communication or I / O protocols or standards (e.g., Ethernet, 802.1 lx. Universal System Bus, WiMax, modem, a cellular network protocol, and the like) for communicating information to and / or from at least all the connected components, devices, and network in computing environment 700. Network 750 can be any network or combination of networks (e.g., the Internet, local area network, wide area network, a telephonic network, a cellular network, a satellite network, and the like).

[0065] Computer device 705 can use and / or communicate using computer-usable or computer-readable media, including transitory media and non-transitory media. Transitory media include transmission media (e.g., metal cables, fiber optics), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid-state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.

[0066] Computer device 705 can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some example computing environments. Computer-executable instructions can be retrieved from transitory media, and stored on and retrieved from non-transitory media. The executable instructions can originate from one or more of any programming, scripting, and machine languages (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others).Attorney Docket No. 120179-0590W001

[0067] Processor(s) 710 can execute under any operating system (OS) (not shown), in a native or virtual environment. One or more applications can be deployed that include logic unit 760, application programming interface (API) unit 765, input unit 770, output unit 775, and inter-unit communication mechanism 795 for the different units to communicate with each other, with the OS, and with other applications (not shown). The described units and elements can be varied in design, function, configuration, or implementation and are not limited to the descriptions provided. Processor! s) 710 can be in the form of hardware processors such as central processing units (CPUs) or a combination of hardware and software units.

[0068] In some example implementations, when information or an execution instruction is received by API unit 765, it may be communicated to one or more other units (e.g,, logic unit 760, input unit 770, output unit 775). In some instances, logic unit 760 may be configured to control the information flow' among the units and direct the services provided by API unit 765, input unit 770, and output unit 775, in some example implementations described above. For example, the flow of one or more processes or implementations may be controlled by logic unit 760 alone or in conjunction with API unit 765. The input unit 770 may be configured to obtain input for the calculations described in the example implementations, and the output unit 775 may be configured to provide output based on the calculations described in example implementations.

[0069] Processor(s) 710 can be configured to execute a method or computer instructions which can involve, in response to receiving, at a GMRA comprising a local cache, a read request for metadata from a subsystem located within a same region as the GMRA, providing the subsystem with the metadata that is globally unique and has been obtained from a GMS, wherein the subsystem requests the metadata from the GMS via the GMRA, which forwards the metadata from the GMS to the subsystem during regular operation and, during a period of GMS unavailability, provides the metadata to the subsystem from a read-only copy of the metadata maintained by one or more GMRAs, as described, for example, with respect to FIG.1 and FIG. 4.

[0070] Processor(s) 710 can be configured to execute a method or computer instructions which can involve, in response to receiving a write request for the metadata when the GMS is temporarily unreachable, rejecting the write request to prevent conflicting updates and maintain uniqueness of the metadata by ensuring that write operations are handled by the GMS; and, in response to detecting a permanent failure of the GMS, providing the read-only copy to enable a recovery of the metadata by a new instance of the GMS, as described, for example, with respect to FIG. 4 and FIG. 6B.Attorney Docket No. 120179-0590W001

[0071] Processor(s) 710 can be configured to execute a method or computer instructions which can involve maintaining compatibility with both older and newer API versions by using separate installers to enable an independent update of the GMRA and the subsystem, without requiring concurrent upgrades to the GMS or the one or more GMRAs, thereby ensuring subsystem availability and reducing system downtime, as described, for example, with respect to FIG. 1 and FIG. 4.

[0072] Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities to achieve a tangible result.

[0002] Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities wdthin the computer system’s registers and memories into other data similarly represented as physical quantities within tlie computer system’s memories or registers or other information storage, transmission or display devices.

[0073] Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer- readable medium, such as a computer-readable storage medium or a computer-readable signal medium. A computer-readable storage medium may involve tangible mediums such as optical disks, magnetic disks, read-only memories, random access memories, solid-state devices, drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer-readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.

[0074] Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a moreAttorney Docket No. 120179-0590W001specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the techniques of the example implementations as described herein. Tire instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.0075] As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine -readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general-purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and / or encrypted format.

[0076] Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the techniques of the present application. Various aspects and / or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.

Claims

Attorney Docket No. 120179-0590W001CLAIMSWhat is claimed is:

1. A method for managing globally unique metadata in a geographically distributed environment, the method comprising:in response to receiving, at a Global Metadata Region Agent (GMRA) comprising a local cache, a read request for metadata from a subsystem located within a same region as the GMRA, providing the subsystem with the metadata that is globally unique and has been obtained from a Global Metadata Service (GMS), wherein the subsystem requests the metadata from the GMS via the GMRA, which forwards the metadata from the GMS to the subsystem during regular operation and, during a period of GMS unavailability, provides the metadata to the subsystem from a read-only copy of the metadata maintained by one or more GMRAs;in response to receiving a write request for the metadata when the GMS is temporarily unreachable, rejecting the write request to prevent conflicting updates and maintain uniqueness of the metadata by ensuring that write operations are handled by the GMS;in response to detecting a permanent failure of the GMS, providing the read-only copy to enable a recovery of the metadata by a new instance of the GMS; and maintaining compatibility with both older and newer API versions by using separate installers to enable an independent update of the GMRA and the subsystem, without requiring concurrent upgrades to the GMS or the one or more GMRAs, thereby ensuring subsystem availability and reducing system downtime.

2. The method of claim 1, wherein the read-only copy maintained by the GMRA is used to locally serve the read request to its respective subsystem to reduce a latency that would otherwise result from a network communication with the GMS.

3. The method of claim 1, wherein providing the read-only copy comprises recovering the metadata by reinstalling the GMS and repopulating it from the read-only copy by the one or more GMRAs.

4. The method of claim 1, wherein using separate installers comprises providing distinct installers for the GMS, the GMRA, and the subsystem to enable sequential and independent upgrades of components.

5. The method of claim 1, wherein upgrades to the GMS and GMRAs are performed before subsystem upgrades when a schema change is made to the metadataAttorney Docket No. 120179-0590W001or associated APIs, thereby reducing downtime and maintaining the subsystem availability.

6. The method of claim 1, wherein a GMRA is configured to support the older and newer API versions, thereby enabling communication with a subsystem that has not yet been upgraded.

7. The method of claim 1, wherein rejecting the write request further comprises generating an error message that indicates that the GMS is unavailable and providing the error message to the subsystem.

8. The method of claim 7, wherein the GMS comprises a failure detection mechanism that triggers the GMRA to operate in a read-only mode upon detecting that the GMS is unavailable.

9. The method of claim 1, further comprising periodically synchronizing the read¬ only copy maintained by the GMRA with the GMS.

10. The method of claim 1, wherein the subsystem communicates with the GMRA using a standardized API, allowing interoperability with a third-party system and ensuring an architecture extensibility.

11. A system for managing globally unique metadata in a geographically distributed environment, the system comprising:a Global Metadata Service (GMS) configured to store and manage metadata that is globally unique:a Global Metadata Region Agent (GMRA) associated with a region and a local cache, the local cache configured to maintain a read-only copy of the metadata replicated from the GMS:a subsystem located within a region and configured to communicate with the GMRA to access the metadata, wherein the GMRA is configured to perform steps comprising:in response to receiving a read request, providing the subsystem with the metadata from the local cache when the GMS is temporarily unavailable and forwarding the metadata from the GMS to the subsystem during regular operation;in response to receiving a write request for the metadata when the GMS is temporarily unavailable, rejecting the write request to maintain the uniqueness of the metadata by ensuring that write operations are handled by the GMS;Attorney Docket No. 120179-0590W001in response to detecting a permanent failure of the GMS, enabling recovery of the metadata by providing the read-only copy of the metadata to repopulate a new instance of the GMS, wherein the GMRA and subsystem are configured to maintain compatibility with older and newer API versions; andseparate installers for the GMS, the GMRA, and the subsystem to enable independent upgrades of the GMRA and the subsystem without requiring concurrent upgrades to the GMS or other GMRAs, thereby ensuring subsystem availability' and reducing system downtime.

12. The system of claim 10, wherein the GMRA generates an error message that indicates that the GMS is unavailable and provides the error message to the subsystem.

13. The system of claim 10, wherein rejecting the write request further comprises generating an error message that indicates that the GMS is unavailable and providing the error message to the subsystem.

14. The system of claim 13, wherein the GMS comprises a failure detection mechanism that triggers the GMRA to operate in a read-only mode upon detecting that the GMS is unavailable.

15. The system of claim 14, wherein the GMS and the GMRA upgrade before the subsystem when a schema change is made to the metadata or associated APIs, thereby- reducing downtime and maintaining the subsystem availability.

Images