Microsoft Technology Licensing, LLC

Atul Katiyar

Dharma Kiritkumar Shukla

Karthik Raman

Shireesh Kumar Thota

Madhan Gajendran

Pankaj Sharma

Momin Mahmoud Al-Ghosien

Ankur Savailal Shah

Shreshth Singhal

Ji Huang

Sujit Vattathil Kuruvilla

Ovidiu Constantin Platon

Quetzalcoatl Bradley

Constantin Dulu

John MacIntyre

Mark Connolly Benvenuto

Bhalakumaaran Erode Ranganathan

Mikhail Mikhailovich Koltachev

Elisa Marie Flasko

Nemanja Matkovic

Rajeev Sudhakar Bhopi

Digvijaysinh Govindbhai Makwana

Subramanyam Pattipaka

Hari Sudan Sundar

Liang Li

Ramachandran Ramjee

Chinna Babu Polinati

Purushottam Shridhar Amradkar

Muthian Sivathanu

Arsalan Ahmad

Rimma V Nehme

Nipun Kwatra

Hemant Kumar

Samer Boshra

Krishnan Sundaram

Padma Priya Aradhyula Bhavani

Nitin Gupta

Junyan Guo

Venkata Sivaramakrishna Ramadugu

Artavazd Ginosian

Lalitha Manjapara Viswanathan

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

A data service may be distributed over a set of servers in order to provide a database with properties such as low latency, high availability, and support for various consistency levels. Presented herein is a particular architecture that promotes rapid provisioning to promote scalability and failover; adaptive load-balancing to accommodate fluctuations in demand; and resiliency in the event of various types of failure, such as network partitions or regional outages. For a service comprising a resource set, a container is provided that hosts a set of replicas of a partition, and that is assigned an allocation of computing capabilities of one or more servers. The resource set of the service may be distributed over the replicas of the container. Scalability is achieved by adding replicas to the container, and load-balancing may be provided by splitting, merging, or otherwise refactoring the partition to accommodate anticipated and unanticipated fluctuations in service demand.

Containerization for elastic and scalable databases

Workloads are often performed by a server set according to a service level agreement, and are often provisioned and load-balanced by dedicating selected computational resources (e.g., servers and bandwidth) for application to the workload. However, resource-based provisioning may not accurately reflect the computational resource expenditure of the workload, leading to overprovisioning or underprovisioning of servers for the workload. Instead, the workload may be evaluated according to a service unit as a measurement of a volume of computational resources consumed by a workload unit, including performance dimensions specified in the service level agreement. The service level agreement may indicate a service unit rate for the workload. The workload may therefore be allocated to a subset of servers in portions according to a service unit rate, where the sum of the service unit rates for the portions allocated to the servers satisfies the service unit rate specified in the service level agreement.

Data service provisioning, metering, and load-balancing via service units

A server set may provide a document service to various clients in view of considerations such as availability, fault tolerance, flexibility, and performance. Presented herein are document service architectures that involve partitioning the document set into at least two document ranges, and assigning the respective document ranges to an agent that is deployed to at least one assigned server. A request to apply an operation to a selected document may be fulfilled by identifying the document range of the document; identifying a selected server of the server set that hosts the agent to which the range is assigned; and forwarding the request to the selected server. In some variations, servers may retain detailed information about neighboring servers (e.g., according to logical and/or physical proximity) and scant information about distant servers, thereby avoiding both the extensive information exchange of highly informed network architectures and the inefficiency of uninformed routing algorithms.

Elastically scalable document-oriented storage services

A server set may provide a document service to one or more clients, and may be configured to do so in view of various considerations such as availability, fault tolerance, flexibility, and performance. Presented herein are document service architectures that involve partitioning the document set into at least two document ranges, and configuring respective servers of the server set to host one or more agents to which are respectively assigned one or more document ranges. A request for an operation involving at least one document may be routed to a server hosting an agent managing the document ranges of the documents involved in the operation. Moreover, respective servers may retain detailed information about neighboring servers (e.g., according to a logical or physical proximity) and scant information about distant servers, thereby avoiding both the extensive information exchange of highly informed network architectures and the inefficiency of uninformed routing algorithms.

An analytic system may have a number of processing stages. One or more data sources may provide data to a first processing stage. The first processing stage may specify one or more data contracts having a schema describing a layout and types of data provided by the one or more data sources. Each of the processing stages may specify a respective data contract having a schema such that the processing stages may understand a layout and types of data provided as input to the processing stages. The data contracts me further specify a valid range of values for various items of data described by schemas. Data not conforming to a data contract may be automatically filtered out such that a corresponding processing stage may not be provided with the non-conforming data.

Large scale real-time multistaged analytic system using data contracts

The monitoring by a monitoring node of a process performed by a monitored node is often devised as a tightly coupled interaction, but such coupling may reduce the re-use of monitoring resources and processes and increase the administrative complexity of the monitoring scenario. Instead, fault detection and recovery may be designed as a non-proprietary service, wherein a set of monitored nodes, together performing a set of processes, may register for monitoring by a set of monitoring nodes. In the event of a failure of a process, or of an entire monitored node, the monitoring nodes may collaborate to initiate a restart of the processes on the same or a substitute monitored node (possibly in the state last reported by the respective processes). Additionally, failure of a monitoring node may be detected, and all monitored nodes assigned to the failed monitoring node may be reassigned to a substitute monitoring node.

Fault detection and recovery as a service

Growing community of inventors

Sammamish, WA, United States of America

Atul Katiyar