CN108664324B - Update log for cloud service instance allocation - Google Patents
Update log for cloud service instance allocation Download PDFInfo
- Publication number
- CN108664324B CN108664324B CN201710202625.XA CN201710202625A CN108664324B CN 108664324 B CN108664324 B CN 108664324B CN 201710202625 A CN201710202625 A CN 201710202625A CN 108664324 B CN108664324 B CN 108664324B
- Authority
- CN
- China
- Prior art keywords
- node
- request
- sequence number
- nodes
- modified
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The computing device assigns instances to a cloud network. An allocation application stored in the memory and executed by the processor is configured to receive a request to allocate an instance to a node in the cloud network. The instance is defined by a set of properties. The allocation application is configured to create a request equivalence class based on the set of characteristics; caching one or more node equivalence classes for the request equivalence class; maintaining a node update log comprising a list of modified nodes of a plurality of nodes; in response to a request to allocate a new instance that includes the set of properties, selecting the request equivalence class; and communicating with the node update log to identify and update modified nodes in the one or more node equivalence classes prior to selecting an assigned node in the one or more node equivalence classes.
Description
Technical Field
The present disclosure relates to cloud networks, and in particular, to allocating virtual machines and container instances to servers in a cloud network.
Background
The background description provided herein is for the purpose of summarizing the context of the present disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
Cloud service providers support the ability to use infrastructure as a service (IaaS) and platform as a service (PaaS) of Virtual Machines (VMs) and/or container instances. The data center includes servers or nodes that host VM and/or container instances, and each server may host many VM and/or container instances. The VM instances run on a host Operating System (OS), run a guest OS and interface with a hypervisor that shares and manages server hardware and isolates the VM instances.
Unlike a VM instance, a container instance does not require a complete OS to be installed or a virtual copy of the host server hardware. The container instance may include one or more software modules and libraries and require the use of some portion of the operating system and hardware. As a result of the reduced footprint, more container instances may be deployed on the server compared to the VM.
Deployment time of VMs and container instances is an important performance metric for any large-scale cloud service provider. The allocation decision with where (e.g., at which node) the new VM and/or container instance should be located is in the critical path during deployment, and thus should be as fast as possible.
The allocation of VMs and/or container instances is typically optimized to achieve allocation metrics such as good resource packing across different resource utilizations, low failure rates, high fault tolerance, low master-OS update times, good anti-hosting (anti-collocation) rules, etc. In some systems, allocation is performed using a pipelined set of rules. During allocation, many of these rules are recalculated for each new VM or container instance. Many of these rules also require evaluation of each existing node within the corresponding cluster or other distribution unit. Thus, allocation of VM and/or container instances may be fast enough to operate in small clusters or for several deployment instances. However, allocation causes bottlenecks when scaled to the datacenter hierarchy and/or when a large number of VMs or container instances are deployed in a short period of time.
SUMMARY
A computing device for distributing instances including virtual machines or containers to a cloud network includes a processor and a memory. An allocation application stored in the memory and executed by the processor configured to: a request to allocate an instance comprising one of a virtual machine or a container to a plurality of nodes in a cloud network is received. The instance is defined by a set of properties. The allocation application is configured to create a request equivalence class based on the set of characteristics; caching one or more node equivalence classes for the request equivalence class; maintaining a node update log comprising a list of modified nodes of the plurality of nodes; in response to a request to allocate a new instance that includes the set of properties, selecting the request equivalence class; and communicating with the node update log to identify and update modified nodes in the one or more node equivalence classes prior to selecting an assigned node in the one or more node equivalence classes.
In other features, the assignment application is further configured to remove the modified node and reinsert the modified node into the ranked list of the selected one of the one or more node equivalence classes. The allocation application is further configured to select one of the one or more node equivalence classes for the modified node based on the dynamic rule. The assignment application is further configured to rank the modified nodes within a selected one of the one or more node equivalence classes based on static rules.
In other features, the node update log maintains a linked list including a plurality of entries, each of the entries including a sequence number and a node Identification (ID). When a first node ID corresponding to a modified node is in the linked list, the update log is configured to remove the first node ID from the linked list and add the first node ID to the tail of the linked list along with a new sequence number. When the first node ID corresponding to the modified node is not in the linked list, the update log is configured to add the first node ID to the end of the linked list along with a new sequence number.
In other features, the assignment application is configured to send the sequence number when the request equivalence class is most recently updated to the update log and the most recent sequence number is received from the update log.
In other features, the distribution application updates the modified node identified by: a next sequence number after the sequence number when the request equivalence class was most recently updated, a most recent sequence number, and a modified node identified by a sequence number between the next sequence number and the most recent sequence number.
An allocator component for allocating an instance comprising a virtual machine and a container to a cloud network comprises: a receiver for receiving a request to allocate an instance comprising one of a virtual machine or a container to one of a plurality of nodes in a cloud network. The instance is defined by a set of properties. The rule evaluator is configured to create a request equivalence class based on the set of characteristics and cache one or more node equivalence classes for the request equivalence class. The node update log is configured to maintain a list of modified nodes of the plurality of nodes. The rule evaluator is configured to select the request equivalence class in response to a request to allocate a new instance that includes the set of properties. Prior to selecting a node in the one or more node equivalence classes, the rule evaluator communicates with the node update log to identify a modified node in the one or more node equivalence classes and update the modified node.
In other features, the rule evaluator is further configured to remove the modified node and reinsert the modified node into the ranked list of one of the one or more node equivalence classes. The rule evaluator is further configured to select one of the one or more node equivalence classes for the modified node based on the dynamic rule. The rule evaluator is further configured to rank the modified nodes within a selected one of the one or more node equivalence classes based on static rules.
In other features, the node update log maintains a linked list comprising a plurality of entries including a sequence number and a node Identification (ID). When a first node ID corresponding to a modified node is in the linked list, the update log is configured to remove the first node ID from the linked list and add the first node ID to the tail of the linked list along with a new sequence number. When the first node ID corresponding to the modified node is not in the linked list, the update log is configured to add the first node ID to the end of the linked list along with a new sequence number.
In other features, the rule evaluator is configured to send a sequence number corresponding to a state of the update log when the request equivalence class is newly updated to the update log. The rule evaluator receives the latest sequence number from the update log. The rule evaluator updates the modified node identified by: a next sequence number following the sequence number corresponding to the update log state when the request equivalence class was most recently updated, a most recent sequence number, and a modified node identified by a sequence number between the next sequence number and the most recent sequence number.
A computing device for distributing instances including virtual machines or containers to a cloud network includes a processor and a memory. An allocation application stored in the memory and executed by the processor, configured to: a request to allocate an instance including one of a virtual machine or a container to one of a plurality of nodes in a cloud network is received. The instance is defined by a set of properties. The allocation is configured to create a request equivalence class based on the set of characteristics, cache at least one node equivalence class comprising a list of selected nodes of the plurality of nodes, sample nodes in the list to create a sampled list, and select a node from the sampled list.
In other features, the allocation application is further configured to identify a selected node of the plurality of nodes in the list based on a dynamic rule and rank the nodes in the sampled list based on a static rule.
Further areas of applicability of the present disclosure will become apparent from the detailed description, claims, and drawings. The detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.
Drawings
Fig. 1 is a functional block diagram of an example of a network including a cloud service provider having an allocation component to allocate VMs and/or container instances in accordance with the present disclosure.
Fig. 2A and 2B are functional block diagrams of examples of servers hosting VMs and/or container instances according to the present disclosure.
Fig. 3 is a functional block diagram of an example of a distribution component according to the present disclosure.
FIG. 4 illustrates an example of allocation of VM or container instances using request equivalence classes and node equivalence classes stored in a cache.
Fig. 5A and 5B are flow diagrams illustrating examples of methods for allocating VM and/or container instances according to the present disclosure.
Fig. 6 illustrates an example of a linked list for managing sequence numbers in a node update log according to this disclosure.
Fig. 7 is a flow chart illustrating an example of a method of operating a node update log according to the present disclosure.
FIG. 8 is a client/server diagram illustrating an example of the operation of a node to update a log.
Fig. 9 is a flow chart illustrating an example of updating a modified node to accommodate a failure domain in accordance with the present disclosure.
Fig. 10 is a flow chart illustrating an example of node identification when an availability zone is used in accordance with the present disclosure.
In the drawings, reference numbers may be reused to identify similar and/or identical elements.
Detailed Description
The placement of VMs and container instances (i.e., the physical allocation of VMs or container instances to physical computing resources, such as servers or nodes in the racks of a cluster) is one of the core functions of a cloud service provider. The allocation decision is made when a request arrives for a VM or container instance, an existing service is out of range, a configuration or migration is changed, and/or an instance on a failed node or chassis needs to be redeployed. In some examples, each allocator component manages a cluster or group of clusters.
The VM or container instance request specifies the characteristics of the VM or container instance to be allocated. A Front End (FE) server of the cloud service provider exposes an Application Protocol Interface (API) to the outside to allow a user to access the cloud service provider and receive requests for VM or container instance assignments. The FE server queries one or more allocator components associated with the one or more clusters. The allocator component performs hypothetical allocations. In some examples, the results from each of the allocator components are transmitted back to the FE server as node Identifications (IDs) and scores. The FE server selects a node from one of the clusters and instructs a corresponding one of the allocator components to allocate a VM or container instance to the selected node.
Systems and methods according to the present disclosure use a score-based system instead of a pipeline-based scheme. As will be described further below, the allocator component receives a request to allocate a VM or container instance defined by a set of characteristics. Different request equivalence classes are defined for different sets of properties.
For each request equivalence class, the allocator component populates one or more node equivalence classes using dynamic rules, ranks nodes in the node equivalence classes using static rules, and evaluates the best node from each node equivalence class using static and dynamic rules. The request equivalence classes and node equivalence classes are cached to reduce computational complexity and increase efficiency.
Static rules determine pass/fail by examining one node and express a preference between two nodes by examining the two nodes. In contrast, dynamic rules rely on the state or characteristics of more than one node. Static rules may include pass/fail decisions and/or preferences. Similarly, dynamic rules may include pass/fail decisions and/or preferences.
Examples of pass/fail decisions include rules related to processor requirements; rules related to availability regions (e.g., requests with different logical availability regions cannot be loaded on the same physical availability region); rules related to update domains or failure domains; rules regarding whether a node can host a virtual machine or container instance (which may be temporary or permanent); rules regarding whether the VM or container instance to be allocated requires special storage requirements (cache or hard disk space); and so on.
Examples of preferences include evaluation of packaging considerations; a cost of recovery; the node is healthy; a preferred failure domain; saving the nodes with more hard disk drives; load balancing an availability domain and a failure domain; co-located nodes performing similar services; reducing update domain fragmentation; and the like.
The distribution system and method according to the present disclosure provides a scalable implementation of score-based distribution. In some examples, cache requests for equivalence classes and node equivalence classes for reuse according to the allocation systems and methods of the present disclosure. In some examples, sampling nodes in a node equivalence class is used. Using these techniques allows the distribution system and method according to the present disclosure to become more efficient and scalable.
For example, for a service request of N instances to be allocated on a cluster of M machines, the allocation system and method according to the present disclosure has a complexity of O (M + NS), where S is the sample size. This is a significant improvement over current complexity. For example, for a cluster of about 1000 nodes, sampling around 30-50 nodes (e.g., 40 nodes) may be sufficient samples.
In addition to meeting the requirements of the current VM or container instance, the allocator component may evaluate other considerations. The VM and/or container instance stick to the node where they are placed until a hardware failure or the consumer deletes the VM or container instance. Moving running VMs between nodes using live migration is extremely expensive. The availability guarantees are typically broken by the period of a black-out during the redeployment of a VM or container instance. Thus, each VM and/or container instance should be placed in an efficient manner. Bad decisions can cause clusters to split. Moving to larger clusters reduces reserve capacity requirements, supports larger deployments and improves machine usage. However, larger clusters will have a larger number of VMs and/or container instance requests/memos (minutes). Thus, the allocation will need to occur very quickly to achieve the performance goal.
When a new VM or container instance request is received, the allocator component attempts to use one of the cached request equivalence classes, if possible. The cached request equivalence class may be used if the set of properties of the requested VM or container instance matches the set of properties of one of the existing request equivalence classes. If a match is not identified, a new request equivalence class is created.
One or more node equivalence classes are created for the new request equivalence based on dynamic rules. In particular, each node equivalence class includes one or more nodes that evaluate the same way against dynamic rules. In other words, each node in the node equivalence class is the same for one or more dynamic rules. In some examples, each node in the cluster occurs in one of the node equivalence classes.
One or more static rules are applied to rank the nodes in each node equivalence class. When applying the pass/fail decision of the static rule, some of the nodes will be invalid nodes and may be moved to the bottom of the ranked list or ignored. Subsequently, static rule preferences are applied to rank the nodes. At this point, each node equivalence class includes a preferred or highest ranked node. The highest ranked node from each node equivalence class is then evaluated against static and dynamic rules, and the best node is selected.
When the set of properties of the VM or container instance matches one of the request equivalence classes, one or more node equivalence classes corresponding to the matched request equivalence class are identified. Before using the cached node equivalence classes, the node update log is used to identify one or more modified nodes in the corresponding node equivalence classes. The modified node is removed and reinserted into the ranked list of one of the node equivalence classes for the requesting equivalence class. The process is repeated for all modified nodes. When all modified nodes have been reevaluated, the cached node equivalence classes are up-to-date, further evaluations may be made and the best node may be selected as described above.
The VM or container instance is characterized by the set of characteristics, including key-value pairs that embed information about the requested VM or container instance. For example, the set of characteristics may include requirements related to update domains, fail domains, processor cores, system memory, non-volatile storage, and/or other characteristics. The nodes are arranged by static and dynamic rules in the allocator component according to the relevant characteristics of the arrival request to the VM or container instance. For each allocation rule, two VMs or container instances with the same associated characteristics trigger a similar filtering process and scoring.
Request equivalence classes and caches may be used because request equivalence classes may be defined for a set of rules and the number of equivalence classes is limited. Two VM or container instances are equivalent for a set of rules if the two VM or container instances are equal in view of the properties referenced by the set of rules. In addition, for a set of rules, the result of each node equivalence class is a set of nodes that pass all of the rules. However, when maintaining a cache corresponding to a set of rules, all possible changes related to the updated node are considered. That is, all static and dynamic rules are re-evaluated. In addition, the number of equivalence classes is limited. There are only a limited number of VM or container instance types. Even when service-related characteristics are considered (e.g., update domain and failure domain), the number of request equivalence classes is relatively small when large cloud service requests are considered.
Referring now to FIG. 1, network 100 includes cloud service provider 130 and one or more consumer networks 140-1, 140-2, 140-C (collectively consumer networks 140), where C is an integer greater than zero. In some examples, consumer network 140 is connected to cloud service provider 130 through a distributed communication system, such as the internet. However, consumer network 140 may be connected to cloud service provider 130 using a dedicated communication link or in any other suitable manner.
In some examples, the consumer network 140 may include an on-premise enterprise network, individual computing devices, and the like. The cloud service provider 130 includes a Front End (FE) server 132 that provides an external API that receives requests to assign VM or container instances to one or more clusters 136-1, 136-2, … … 136-Z (collectively clusters 136), where C is an integer greater than zero. Each cluster 136 includes a distribution component 138 and one or more racks 142-1, 142-2, …, and 142-R (collectively racks 142), where R is an integer greater than zero. The distribution component 138 may include a service computing device. Each rack 142-1, 142-2, …, and 142-R includes one or more routers 144-1, 144-2, …, and 144-R (collectively routers 144), and one or more servers 148-1, 148-2, …, and 148-R (collectively servers or nodes 148), respectively. In FIG. 1, assignment component 138 is associated with a single cluster, such as cluster 136-1.
In use, the FE server 132 receives a request to allocate a VM or container instance. The FE server 132 queries the allocator component 138 associated with the cluster 136. The results from the allocator component 138 are returned to the FE server 132 as node IDs and scores for each cluster 136. The FE server 132 selects a node from a cluster and instructs a corresponding one of the allocator components 138 to allocate a VM or container instance to the selected node.
Referring now to fig. 2A and 2B, examples of a server 148 for hosting VMs and/or container instances are shown. In FIG. 2A, a server using a native hypervisor is shown. The server 148 includes hardware 170, such as a wired or wireless interface 174, one or more processors 178, volatile and non-volatile memory 180, and mass storage 182, such as a hard disk drive or flash drive. Hypervisor 186 runs directly on hardware 170 to control hardware 170 and manage virtual machines 190-1, 190-2, …, 190-V (collectively virtual machines 190) and corresponding guest operating systems 192-1, 192-2, …, 192-V (collectively guest operating systems 192), where V is an integer greater than 1.
In this example, hypervisor 186 runs on a conventional operating system. The guest operating system 192 runs as a process on the host operating system. Examples of hypervisors include Microsoft's Hyper-V, Xen, Oracle's VM Server for SPARC (VM Server for SPARC), Oracle's VM Server for x86 (VM Server for x 86), Citrix's XenServer, and VMware's ESX/ESxi, but other hypervisors may be used.
Referring now to FIG. 2B, a second type of hypervisor can be used. The server 148 includes hardware 170, such as a wired or wireless interface 174, one or more processors 178, volatile and non-volatile memory 180, and mass storage 182, such as a hard disk drive or flash drive. Hypervisor 204 runs on host operating system 200. Virtual machines 190-1, 190-2, …, 190-V (collectively referred to as virtual machines 190) and corresponding guest operating systems 192-1, 192-2, …, 192-V (collectively referred to as guest operating systems 192). Guest operating system 192 is abstracted from host operating system 200. Examples of this second type include VMware work station, VMware Player, VirtualBox, Parallels Desktop for Mac and QEMU (Parallels Desktop for Mac and QEMU). Although two examples of hypervisors are shown, other types of hypervisors can be used.
Referring now to fig. 3 and 4, an example of a server implementation of the distribution component 138 is shown in further detail and includes a computing device that includes a wired or wireless interface 250, one or more processors 252, and memory 258. An operating system 260 and an allocation application 264 are located in the memory 258. The assignment application 264 includes a request receiver 266, a sequencer 268, a node update log 270, and a rule evaluator 274.
The assignment application 264 also includes a set of rules 276 that include static rules 277 and dynamic rules 278. The equivalence cache 280 stores cached and reused request equivalence classes 284 and node equivalence classes 286. In some examples, the equivalent cache 280 is stored in a Least Recently Used (LRU) cache. Rule cache 287 includes instances of static or dynamic rules 288 that are cached and reused. In some examples, rule cache 287 is stored in an LRU cache. The assignment application 264 also includes a node placement module 290 and a candidate node list 292.
If the set of properties of the new VM and/or container instance does not match the set of properties of one of the existing request equivalence classes, rule evaluator 274 creates a new request equivalence class and populates one or more node equivalence classes corresponding to the new request equivalence class. If the set of characteristics of the new VM and/or container matches the set of characteristics of the existing request equivalence class, then rule evaluator 274 determines whether the node in the corresponding node equivalence class has been modified by communicating with node update log 270.
When an existing request equivalence class can be used, the rule evaluator 274 identifies modified nodes and removes the modified nodes from the node equivalence class. The modified nodes are inserted into one of the node equivalence classes based on dynamic rules, and the ranking of the modified nodes is determined by static rules, as described further below.
When a new request equivalence class is created, rule evaluator 274 creates a node equivalence class by evaluating all nodes. In some examples, all nodes are arranged in one or more node equivalence classes based on dynamic rules and arranged at a ranking determined by static rules. In some examples, each node in the node equivalence class is compared to other nodes in the list. In some examples, the following formula is used:
if Compare (request, mX, mY) <0, then node mX is preferred over mY. If Compare (request, mX, mY) >0, then node mY is preferred over mX. If Compare (request, mX, mY) ═ 0, then either mX or mY may be selected. The rule evaluator applies static and dynamic rules to each node's preferred node of the equivalence class to select one of the nodes as an allocating node or a node to send to the FE servers of the cluster.
The equivalence cache 280 stores request equivalence classes 284 for VM and/or container instance requests that are received and evaluated. For example, in FIG. 4, request equivalence classes 284-1, 284-2, … 284-E have been established based on a common set of characteristics of the VM or container instance. Once established, the request equivalence class 284 is associated with one or more node equivalence classes 286 that are determined based on dynamic rules and ranked based on static rules. For example, in FIG. 4, request equivalence class 284-1 is associated with node equivalence classes 286-1, 286-2, …, and 286-C, request equivalence class 284-2 is associated with node equivalence classes 286-11 and 286-12, and request equivalence class 284-3 is associated with node equivalence class 286-21.
As can be appreciated, the nodes may be modified after the node equivalence classes are established, ranked, and cached. Node update log 270 tracks changes to nodes over time. In some examples, node update log 270 creates a new node update log version in response to changes, updates, and/or modifications of each node.
For example, in FIG. 4, a new VM or container instance request arrives and is a match for request equivalence class 284-1. Node update log 270 identifies three nodes in request equivalence class 284-1 that have been changed. The first node is removed, evaluated, and reinserted at a lower position in the ranked list due to the lower score, as identified by arrow 290. After the pass/fail decision fails, the second node is no longer a valid node and is moved to the bottom of the node equivalence class, as identified by arrow 291. The third node is removed, evaluated and inserted into the node equivalence class 286-C at the location identified by 293.
As all nodes are updated, evaluated, and re-inserted, the allocator component 138 has identified a set 294 containing preferred nodes from each of the node equivalence classes of the corresponding node equivalence classes (e.g., 295-1, 295-2, …, and 295-C). The rule evaluator applies static and dynamic rules to the preferred node and selects the highest ranked node (e.g., 295-1) from the set. In some examples, a VM or container instance is assigned to a selected node or identified to an FE server.
Referring now to FIG. 5A, a method 350 for assigning VM or container instances to nodes is illustrated. At 352, the method determines whether a request to allocate a VM or container instance has been received. When 352 is true, the method continues at 356 and determines whether the characteristics of the requested VM or container instance match the existing request equivalence class.
If 356 is true, the rule evaluator optionally updates a cached instance of the one or more rules using a node update log at 357, as will be further described in conjunction with FIG. 5B. The method continues at 358 and determines a current sequence number of the node update log at 358. At 362, the method determines the sequence number stored when the matching request equivalence class was last updated. At 363, the method determines whether the sequence numbers match. If 363 is false, the method continues at 364 and identifies nodes that were modified between the node update log sequence numbers. At 368, the method removes the modified node from the node equivalence class corresponding to the matched request equivalence class. At 370, the node is evaluated and reinserted into the ranked list of one of the node equivalence classes. The node equivalence class of each modified node is selected based on dynamic rules and the ranking of the modified nodes is selected based on static rules.
The method continues from 363 (if true) or 370 to 371. At 371, the highest ranked node is selected from each node equivalence class. At 372, the selected nodes are ranked based on static and dynamic rules. At 374, the highest ranked node is selected. At 376, a VM or container instance is installed on the selected node or the selected node is identified to the FE server.
If 356 is false, the rule evaluator optionally updates the cached instance of the one or more rules using the node update log at 357 (in some examples related to rules associated with the new request equivalence class), as further described below in connection with FIG. 5B. At 376, a new request equivalence class is created. At 378, nodes are identified for the new one or more node equivalence classes requesting equivalence classes based on at least one dynamic rule. At 382, each node in the node equivalence class is ranked based on static rules to create a ranked list of each corresponding node equivalence class.
Referring now to FIG. 5B, an example of a method 385 for an instance of a cache rule is shown. At 386, the method continues at 388 when a new Request Equivalence Class (REC) is to be created or an existing REC is to be used. At 388, the method identifies a rule instance (static or dynamic) associated with the new or existing request equivalence class in a rule cache. At 390, the method determines the latest sequence number of the node update log. At 392, the method determines that the sequence number of the cached rule instance is to be updated. At 393, the method determines whether the sequence numbers match. If 393 is false, the method determines the nodes that are modified between the sequence numbers. At 396, the method updates the rule instance based on the modified node. The method proceeds from 393 (if true) or 396 to 398. At 398, the method determines whether there are additional rule instances to update for the new or existing REC. If 398 is true, the method returns to 388. If 398 is false, the method returns.
For example, a rule instance stored in a rule cache may relate to a failure domain with the highest number of empty nodes. The rule instance may track the number of empty nodes in each failure domain. When a new request equivalence class is created or an existing request equivalence class associated with the dynamic rule is used, the rule instance is updated by determining the modified nodes and then updating the rule instance based thereon.
Referring now to fig. 6-8, the operation of the node update log 270 is shown. In fig. 6, each time a node is updated or modified, the node update log 270 generates a new version or sequence number. The node update log 270 either a) adds a new Log Sequence Number (LSN) and node ID to the tail if the node ID was not previously in the linked list, or b) removes the node ID and adds a new Log Sequence Number (LSN) and node ID to the tail if the node ID was previously in the linked list. In some examples, the linked list includes T entries, where T is equal to the number of nodes in the cluster.
In fig. 7, a method 400 for operating a node update log 270 is shown. At 402, the node update log determines whether the node ID has been modified. When 402 is true, the node update log moves the node ID to the tail of the linked list. At 412, the node update log sets the Log Sequence Number (LSN) equal to LSN +1 and stores the LSN with the node ID in a linked list. When the node update log receives a request to identify a change in node ID at 416, the node update log identifies the node ID of the node with a sequence number greater than N as a modified node to the LSN at 422.
In fig. 8, a client-server model is shown. The server side monitors changes and updates to the node and modifies the list of links in the node update log as needed. In response to a request from a client for whether there is a change after a Sequence Number (SN), a server responds with nodes that have changed since the SN. The client updates the changed node (remove, evaluate, and reinsert) and stores the LSN.
Referring now to fig. 9-10, there are some subtleties when considering a failure domain or multiple availability areas. This is due to the nature of the rules associated with the failure domain and the availability domain.
As described above, when the characteristics of an arriving VM and/or container instance match one of the existing request equivalence classes, the corresponding node equivalence class needs to be updated based on the information tracked by the node update log before being used for the arriving VM and/or container instance. To perform this task, the node update log records the modified nodes since the most recent update of the cache. If a particular node is updated, the static and dynamic rules are evaluated and reinserted into the same or different node equivalence classes depending on the modified node.
The cached candidate set in the node equivalence class is the result of all rules. For static rules, the modified node may only affect the results of the node itself, and it is sufficient to reevaluate the modified node alone. However, the dynamic rules need to be further considered to determine whether other nodes are likely to be affected by the modified node. In some examples, nodes other than the modified node identified by the update log are removed, evaluated, and reinserted.
For dynamic rules associated with the failure domain, whether a node can pass the dynamic rules may be affected by nodes on the same chassis. Thus, when a node on a chassis is modified, all other nodes on the same chassis are checked to determine if they pass the failure domain rule and the cached candidate set is updated accordingly.
In fig. 9, a method 500 for further updating a node is shown. At 510, in response to a query to the node update log, the distribution application determines whether there are nodes that need to be updated. If 510 is true, the distribution application further determines whether there is a rule associated with the failed domain at 514. If 514 is true, the assignment application updates other nodes in the same chassis to modified nodes.
For dynamic rules related to availability areas, although an availability area may affect a large number of nodes, the logical availability area and the physical availability area have a one-to-one mapping, which simplifies the problem. When the dynamic rules relating to the availability area of the first instance of an instance class are complete, the resulting cached set is built and then further filtered to retain only the node to which the instance is allocated in the physical availability area.
In fig. 10, a method 550 for processing rules related to availability regions is shown. At 560, in response to the query to the node update log, the distribution application determines whether there is a node that needs to be updated. If 560 is true, the assignment application determines if the characteristics of the new VM or container instance are related to rules related to availability areas at 564. If 564 is true, after the node identified by the node update log is updated and reinserted, the results in the node equivalence class are filtered 568 to an availability zone identified by the properties of the new VM or container instance.
The foregoing description is merely illustrative in nature and is not intended to limit the present disclosure, application, or uses. The broad teachings of the disclosure can be implemented in a variety of ways. Therefore, while this disclosure includes particular examples, the true scope of the disclosure should not be so limited since other modifications will become apparent to the skilled practitioner upon a study of the drawings, the specification, and the following claims. It should be understood that one or more steps in a method may be performed in a different order (or simultaneously) without altering the principles of the present disclosure. Moreover, although each embodiment is described above as having certain features, any one or more of the other features described with reference to any embodiment of the disclosure may be implemented in and/or in connection with any other embodiment, even if the combination is not explicitly described. In other words, the described embodiments are not mutually exclusive and permutations of one or more embodiments with each other are still within the scope of the present disclosure.
Spatial and functional relationships between elements (e.g., between modules, circuit elements, semiconductor layers, etc.) are described using various terms, including "connected," engaged, "" coupled, "" adjacent, "" beside, "" on top, "" above, "" below, "and" disposed. Unless explicitly described as "direct," when a relationship between first and second elements is described in the above disclosure, the relationship may be a direct relationship, where there are no other intervening elements between the first and second elements, but may also be an indirect relationship, where there are one or more intervening elements (spatially or functionally) between the first and second elements. As used herein, the phrase at least one of A, B and C should be interpreted to mean one logic (a OR B OR C), using a non-exclusive logical OR, and should not be interpreted to mean "at least one a, at least one B, and at least one C".
In the drawings, the arrow-like direction, as indicated by the arrow, generally indicates the flow of information (e.g., data or instructions) of interest to the diagram. For example, when element a and element B exchange various information, but the information transmitted from element a to element B is related to a diagram, an arrow may point from element a to element B. This undirected arrow shape does not imply that no other information is transferred from element B to element a. Also, for information sent from element a to element B, element B may send a request for information to element a, or send an acknowledgement of receipt of the information to element a.
In this application, including the following definitions, the term "module" or the term "controller" may be replaced by the term "circuit". The term "module" may refer to or include portions of: an Application Specific Integrated Circuit (ASIC); digital, analog, or hybrid analog/digital discrete circuits; digital, analog, or hybrid analog/digital integrated circuits; a combinational logic circuit; a Field Programmable Gate Array (FPGA); processor circuitry (shared, dedicated, or group) that executes code; memory circuitry (shared, dedicated, or group) that stores code executed by the processor circuitry; other suitable hardware components that provide the desired functionality; or a combination of some or all of the above, for example in a system on a chip.
The module may include one or more interface circuits. In some examples, the interface circuit may include a wired or wireless interface connected to a Local Area Network (LAN), the internet, a Wide Area Network (WAN), or a combination thereof. The functionality of any given module of the present disclosure may be distributed among multiple modules connected by interface circuits. For example, multiple modules may allow load balancing. In further examples, a server (also referred to as remote or cloud) module may perform certain functionality on behalf of a client module.
The term code, as described above, may include software, firmware, and/or microcode, and may refer to programs, routines, functions, classes, data structures, and/or objects. The term shared processor circuit includes a single processor circuit that executes some or all code from multiple modules. The term packet processor circuit includes a processor circuit that is combined with additional processor circuits to execute some or all code from one or more modules. References to multiple processor circuits include multiple processor circuits on separate dies, multiple processor circuits on a single die, multiple cores on a single processor circuit, multiple threads of a single processor circuit, or a combination of the above. The term shared memory circuit includes a single memory circuit that stores some or all code from multiple modules. The term packet memory circuit includes a memory circuit combined with additional memory to store some or all of the code from one or more modules.
The term memory circuit is a subset of the term computer readable medium. As used herein, the term computer-readable medium does not include transitory electronic or electromagnetic signals propagating through a medium (e.g., on a carrier wave); thus, the term computer readable medium may be considered tangible and non-transitory. Non-limiting examples of a non-transitory, tangible computer-readable medium are non-volatile memory circuits (e.g., flash memory circuits, erasable programmable read-only memory circuits, or mask read-only memory), volatile memory circuits (e.g., static random access memory circuits or dynamic random access memory circuits), magnetic memory media (e.g., analog or digital tape or hard drives), and optical storage media (e.g., CD, DVD, or blu-ray disc).
In the present application, an apparatus element described as having particular attributes or performing particular operations is specifically configured to have those particular attributes and perform those particular operations. In particular, a description of an element performing an action means that the element is configured to perform the action. The configuration of an element may include programming of the element, for example, by encoding instructions on a non-transitory, tangible computer-readable medium associated with the element.
The apparatus and methods described in this application may be partially or wholly implemented by a special purpose computer created by configuring a general purpose computer to perform one or more specific functions implemented in a computer program. The functional blocks, flowchart components, and other elements described above serve as software specifications, which can be converted into a computer program by routine work of a person skilled in the art or a programmer.
The computer program includes processor-executable instructions stored on at least one non-transitory, tangible computer-readable medium. The computer program may also comprise or rely on stored data. The computer programs may include a basic input/output system (BIOS) that interacts with the hardware of the special purpose computer, device drivers that interact with specific devices of the special purpose computer, one or more operating systems, user applications, background services, background applications, and the like.
The computer program may include: (i) descriptive text to be parsed, such as JavaScript Object notification (JSON), hypertext markup language (HTML), or extensible markup language (XML), (ii) assembly code, (iii) Object code generated by a compiler from source code, (iv) source code for execution by an interpreter, (v) source code for compilation and execution by a just-in-time compiler, and so forth. For example only, the source code may be written using syntax from languages including C, C + +, C #, Objective C, Haskell, Go, SQL, R, Lisp,
Fortran、Perl、Pascal、Curl、OCaml、
HTML5, Ada, ASP (active Server Page), PHP, Scala, Eiffel, Smalltalk, Erlang, Ruby, HawIth, and,
Visual
Lua and
no element recited in the claims is intended to be a means + function element in 35u.s.c. § 112(f), unless the element is explicitly recited using the term "means for …," or where the method claim uses the phrases "operation for …" or "step for ….
Claims (16)
1. A computing device for allocating an instance comprising a virtual machine or container to a cloud network, comprising:
a processor;
a memory; and
an allocation application stored in the memory and executed by the processor and configured to:
receiving a request to allocate an instance comprising one of a virtual machine or a container to one of a plurality of nodes in a cloud network, the instance defined by a set of characteristics;
creating a request equivalence class based on the set of properties;
caching one or more node equivalence classes for the request equivalence class;
maintaining a node update log comprising a list of modified nodes of the plurality of nodes, the node update log maintaining a linked list comprising a plurality of entries, each of the entries comprising a sequence number and a node identification;
in response to a request to allocate a new instance that includes the set of properties, selecting the request equivalence class;
prior to selecting an assigned node from the one or more node equivalence classes, communicating with the node update log to identify a modified node in the one or more node equivalence classes and update the modified node;
sending a sequence number when the request equivalence class is most recently updated to the update log; and
receiving a latest sequence number from the update log.
2. The computing device of claim 1, wherein the assignment application is further configured to remove the modified node and reinsert the modified node into the ranked list of the selected one of the one or more node equivalence classes.
3. The computing device of claim 1, wherein the allocation application is further configured to select one of the one or more node equivalence classes for the modified node based on a dynamic rule.
4. The computing device of claim 3, wherein the assignment application is further configured to rank the modified nodes within the selected one of the one or more node equivalence classes based on a static rule.
5. The computing device of claim 1, wherein when a first node ID corresponding to the modified node is in the linked list, the update log is configured to remove the first node ID from the linked list and add the first node ID to the tail of the linked list along with a new sequence number.
6. The computing device of claim 1, wherein when a first node ID corresponding to the modified node is not in the linked list, the update log is configured to add the first node ID to the end of the linked list along with a new sequence number.
7. The computing device of claim 1, wherein the allocation application updates the modified node identified by:
a next sequence number after a sequence number when the request equivalence class is most recently updated;
the latest sequence number; and
a modified node identified by a sequence number between the next sequence number and the latest sequence number.
8. An allocator component for allocating an instance comprising a virtual machine or container to a cloud network, comprising:
a receiver for receiving a request to allocate an instance comprising one of a virtual machine or a container to one of a plurality of nodes in a cloud network, the instance defined by a set of characteristics;
a rule evaluator configured to:
creating a request equivalence class based on the set of properties; and
caching one or more node equivalence classes for the request equivalence class; and
a node update log configured to maintain a list of modified nodes of the plurality of nodes, the node update log maintaining a linked list comprising a plurality of entries, each of the entries comprising a sequence number and a node identification ID;
wherein the rule evaluator is configured to:
in response to a request to allocate a new instance that includes the set of properties, selecting the request equivalence class;
prior to selecting a node from the one or more node equivalence classes, communicating with the node update log to identify a modified node in the one or more node equivalence classes and update the modified node;
sending a sequence number when the request equivalence class is most recently updated to the update log; and
receiving a latest sequence number from the update log.
9. The assignor component according to claim 8, wherein the rule evaluator is further configured to remove the modified node and reinsert the modified node into the ranked list of one of the one or more node equivalence classes.
10. The distributor assembly of claim 8, wherein the rule evaluator is further configured to: selecting one of the one or more node equivalence classes for the modified node based on a dynamic rule.
11. The assignor component according to claim 10, wherein the rule evaluator is further configured to rank the modified nodes within a selected one of the one or more node equivalence classes based on a static rule.
12. The allocator component of claim 8, wherein when a first node ID corresponding to the modified node is in the linked list, the update log is configured to remove the first node ID from the linked list and add the first node ID to the tail of the linked list along with a new sequence number.
13. The allocator component of claim 8, wherein when a first node ID corresponding to the modified node is not in the linked list, the update log is configured to add the first node ID along with a new sequence number to the tail of the linked list.
14. The distributor component of claim 8, wherein the rule evaluator updates the modified node identified by:
a next sequence number after a sequence number corresponding to the update log state when the request equivalence class is most recently updated;
the latest sequence number; and
a modified node identified by a sequence number between the next sequence number and the latest sequence number.
15. A computing device for allocating an instance comprising a virtual machine or container to a cloud network, comprising:
a processor;
a memory; and
an allocation application stored in the memory and executed by the processor and configured to:
receiving a request to allocate an instance comprising one of a virtual machine or a container to one of a plurality of nodes in a cloud network, wherein the instance is defined by a set of properties;
creating a request equivalence class based on the set of properties;
caching at least one node equivalence class comprising a list of selected nodes of the plurality of nodes;
sampling nodes in the list to create a sampled list; and
a node is selected from the sampled list.
16. The computing device of claim 15, wherein the allocation application is further configured to:
identifying a selected node of the plurality of nodes in the list based on a dynamic rule; and
ranking nodes in the sampled list based on a static rule.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710202625.XA CN108664324B (en) | 2017-03-30 | 2017-03-30 | Update log for cloud service instance allocation |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710202625.XA CN108664324B (en) | 2017-03-30 | 2017-03-30 | Update log for cloud service instance allocation |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108664324A CN108664324A (en) | 2018-10-16 |
| CN108664324B true CN108664324B (en) | 2022-02-01 |
Family
ID=63786605
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710202625.XA Active CN108664324B (en) | 2017-03-30 | 2017-03-30 | Update log for cloud service instance allocation |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108664324B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108667874A (en) * | 2017-03-31 | 2018-10-16 | 微软技术许可有限责任公司 | Use effective cloud service example of cache and sampling |
| US11316947B2 (en) | 2020-03-30 | 2022-04-26 | International Business Machines Corporation | Multi-level cache-mesh-system for multi-tenant serverless environments |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103634330A (en) * | 2012-08-20 | 2014-03-12 | 曙光信息产业(北京)有限公司 | Automatic resource distribution method in cloud calculation environment |
| CN103914313A (en) * | 2012-12-31 | 2014-07-09 | 北京新媒传信科技有限公司 | Paxos example updating method, device and system |
| CN103970607A (en) * | 2013-01-28 | 2014-08-06 | 国际商业机器公司 | Computing Optimized Virtual Machine Allocations Using Equivalence Combinations |
| CN105610636A (en) * | 2016-03-15 | 2016-05-25 | 中国交通通信信息中心 | Security log generation method for cloud computing environment |
| WO2016128049A1 (en) * | 2015-02-12 | 2016-08-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for running a virtual machine |
| CN105978875A (en) * | 2016-05-11 | 2016-09-28 | 中国人民解放军国防信息学院 | Dynamic service realization method and system base on service hopping and intelligent cleaning |
| CN106453457A (en) * | 2015-08-10 | 2017-02-22 | 微软技术许可有限责任公司 | Multi-priority service instance distribution in cloud computing platform |
-
2017
- 2017-03-30 CN CN201710202625.XA patent/CN108664324B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103634330A (en) * | 2012-08-20 | 2014-03-12 | 曙光信息产业(北京)有限公司 | Automatic resource distribution method in cloud calculation environment |
| CN103914313A (en) * | 2012-12-31 | 2014-07-09 | 北京新媒传信科技有限公司 | Paxos example updating method, device and system |
| CN103970607A (en) * | 2013-01-28 | 2014-08-06 | 国际商业机器公司 | Computing Optimized Virtual Machine Allocations Using Equivalence Combinations |
| WO2016128049A1 (en) * | 2015-02-12 | 2016-08-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for running a virtual machine |
| CN106453457A (en) * | 2015-08-10 | 2017-02-22 | 微软技术许可有限责任公司 | Multi-priority service instance distribution in cloud computing platform |
| CN105610636A (en) * | 2016-03-15 | 2016-05-25 | 中国交通通信信息中心 | Security log generation method for cloud computing environment |
| CN105978875A (en) * | 2016-05-11 | 2016-09-28 | 中国人民解放军国防信息学院 | Dynamic service realization method and system base on service hopping and intelligent cleaning |
Non-Patent Citations (2)
| Title |
|---|
| Optimal Multiserver Configuration for Profit Maximization in Cloud Computing;Junwei Cao;Kai Hwang Keqin Li;《IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS》;20120626;第24卷(第6期);第1087-1096页 * |
| 一种面向云服务提供商的资源分配机制;殷波，王颖，邱雪松，孟洛明;《电子与信息学报》;20140131;第36卷(第1期);第15-21页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108664324A (en) | 2018-10-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11936731B2 (en) | Traffic priority based creation of a storage volume within a cluster of storage nodes | |
| US11461149B1 (en) | Capacity management in provider networks using dynamic host device instance model reconfigurations | |
| US10025503B2 (en) | Autonomous dynamic optimization of platform resources | |
| US11882184B2 (en) | Reuse of execution environments while guaranteeing isolation in serverless computing | |
| US9336038B2 (en) | Refreshing memory topology in virtual machine operating systems | |
| US11397622B2 (en) | Managed computing resource placement as a service for dedicated hosts | |
| US11093288B2 (en) | Systems and methods for cluster resource balancing in a hyper-converged infrastructure | |
| CN108664324B (en) | Update log for cloud service instance allocation | |
| US20220147260A1 (en) | Method, device and computer program product for managing storage system | |
| US20160124774A1 (en) | Cluster resource management in a virtualized computing environment | |
| CN108667874A (en) | Use effective cloud service example of cache and sampling | |
| WO2017166205A1 (en) | High density virtual machine container with copy-on-dma-write | |
| US11855908B2 (en) | Resource allocation in cloud computing systems | |
| US11663127B2 (en) | Method, electronic device and computer program product for managing storage system | |
| US20230244528A1 (en) | Service update management | |
| CN113590018A (en) | Method, electronic device and computer program product for storage management |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |