Microsoft Technology Licensing, LLC

Shreshth Singhal

Dharma Kiritkumar Shukla

Pankaj Sharma

Atul Katiyar

Karthik Raman

Momin Mahmoud Al-Ghosien

Ji Huang

Shireesh Kumar Thota

Ankur Savailal Shah

Sujit Vattathil Kuruvilla

Ovidiu Constantin Platon

Madhan Gajendran

Bhalakumaaran Erode Ranganathan

Mikhail Mikhailovich Koltachev

Subramanyam Pattipaka

Digvijaysinh Govindbhai Makwana

Ramachandran Ramjee

Muthian Sivathanu

Arsalan Ahmad

Rimma V Nehme

Nipun Kwatra

Hemant Kumar

Rajeev Sudhakar Bhopi

Padma Priya Aradhyula Bhavani

Junyan Guo

Venkata Sivaramakrishna Ramadugu

Rimma Vladimirovna Nehme

The disclosure herein describes scheduling execution of artificial intelligence (AI) workloads in a cloud infrastructure platform. A global scheduler receives AI workloads associated with resource ticket values. The scheduler distributes the AI workloads to nodes based on balancing resource ticket values. Local schedulers of the nodes schedule AI workloads on resources based on the resource ticket values of the AI workloads. Based on scheduling the AI workloads, coordinator services of the local schedulers execute the distributed AI workloads on the infrastructure resources of the nodes. The disclosure further describes scheduling AI workloads based on priority tiers. A scheduler receives AI workloads, and each AI workload is associated with a priority tier indicative of a preemption priority while being executed. The AI workloads are scheduled for execution on a distributed set of nodes based on the priority tiers and then execute based on the scheduling.

Scheduler for planet-scale computing system

A server set for a data set may designate a subset of 'master' servers that update the data set in order to reduce data version conflicts involving mutually exclusive updates of the data set. Multi-master configurations may fulfill the performance constraints, and the subset of masters may detect and resolve data version conflicts. However, if multiple masters perform conflict resolution for a particular data version conflict, the resolution may produce inefficiency and redundancy (if the masters reach the same outcome) or additional data version conflicts (if the masters reach different outcomes). Instead, among the masters, a merge master may be identified that applies conflict resolution techniques to data version conflicts and forwards the conflict resolution outcome to the other masters for application to the data set to resolve the data version conflict. The other masters may temporarily store updates in a tentative update set until data version conflicts are resolved.

Merging conflict resolution for multi-master distributed databases

Data services for workloads are often provided with a service level agreement specifying various performance guarantees (e.g., latency, availability, scalability, and consistency). Single-master architectures, in which updates to the data set are constrained to a single server, may limit the fulfillment of some performance guarantees. Presented herein are multi-master architectures, in which the server set is partitioned into at least two masters are permitted to update the data set and at least one non-master that is not permitted to update the data set. Non-masters that receive a request to update the data set forward the request to a master server for application to the data set. A master that receives the request applies it to the data set and propagates the update to other master and non-master servers. Conflicting updates may be resolved through a variety of conflict resolution techniques, optionally designating one master server as a conflict resolution server.

Multi-master architectures for distributed databases

Data services are often provided with various performance guarantees. Multi-master architectures, in which multiple master servers are permitted to update a portion of the data set, may facilitate some performance requirements, but may also lead to data version conflicts in which different masters have written different versions of one or more data items. Moreover, conflicts involving different data items may have to be resolved using different conflict resolution techniques. Therefore, various data items of the data set may be associated with a conflict resolution technique selected from a conflict resolution technique set, such as manual conflict resolution; a write order policy, such as last writer wins; a conflict resolution logic; and conflict resolution based on data types. A data version conflict may be resolved by identifying and invoking the selected conflict resolution technique that is associated with the data item, and applying the conflict resolution outcome to the data item.

Conflict resolution for multi-master distributed databases

Distributed transactions are performed over a collection of servers operating as replicas of a data set, where a successful transaction involves meeting a quorum count of replicas that locally commit the transaction. However, performance constraints of data sets and consuming applications may vary (e.g., sensitivity to latency, scalability, and/or consistency), and the performance characteristics of the server set may be partly determined by the transactional commitment and quorum selection. The distributed transaction may be applied by designating the replicas as a set of followers and a leader that initiates the transaction and receives acknowledgments of local commits by each follower. On condition of the acknowledgments meeting a quorum count for the data set according to the performance characteristics of the application, the leader locally commits the transaction and delivers a result. The transaction may also be applied over collections of replica sets using a second-level quorum to achieve nested consensus.

Resource-governed protocol and runtime for distributed databases with consistency models

Growing community of inventors

Seattle, WA, United States of America

Shreshth Singhal