CN112379971B - Application container management method, device and equipment - Google Patents

Application container management method, device and equipment Download PDF

Info

Publication number
CN112379971B
CN112379971B CN202011290836.1A CN202011290836A CN112379971B CN 112379971 B CN112379971 B CN 112379971B CN 202011290836 A CN202011290836 A CN 202011290836A CN 112379971 B CN112379971 B CN 112379971B
Authority
CN
China
Prior art keywords
server
servers
determining
specified
rule
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
Application number
CN202011290836.1A
Other languages
Chinese (zh)
Other versions
CN112379971A (en
Inventor
胡仲臣
卢道和
杨军
周杰
程志峰
李勋棋
罗海湾
陈鉴镔
陈刚
周佳振
朱嘉伟
汪晓雪
郭英亚
李兴龙
文玉茹
周琪
陈广镇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
WeBank Co Ltd
Original Assignee
WeBank Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by WeBank Co Ltd filed Critical WeBank Co Ltd
Priority to CN202011290836.1A priority Critical patent/CN112379971B/en
Publication of CN112379971A publication Critical patent/CN112379971A/en
Application granted granted Critical
Publication of CN112379971B publication Critical patent/CN112379971B/en
Priority to PCT/CN2021/129917 priority patent/WO2022105659A1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The embodiment of the application container management method, device and equipment. The method comprises the following steps: and receiving distribution requirement information of the application container, wherein the distribution requirement information is used for expressing the requirement of the application container for deploying the target server. Related information of each of a plurality of servers is obtained, and the plurality of servers belong to different clusters. And determining one server in the plurality of servers as a target server according to a preset rule related to the distribution demand information based on the related information of each server in the plurality of servers. The application container is notified to run on the target server. Therefore, virtual resources of a plurality of servers belonging to different clusters are regarded as a large resource pool, deployment of the application container on the plurality of servers belonging to different clusters is achieved, a preset rule replaces a place where a large number of label labels and rule making are needed, making and maintaining cost of the rule is reduced, and the preset rule has good expansibility.

Description

Application container management method, device and equipment
Technical Field
The present application relates to the field of financial technology (Fintech), and in particular, to a method, an apparatus, and a device for managing an application container.
Background
A container is the basic unit of physical compute node resource allocation and scheduling. With the continuous development of container technology, the new virtualization technology provides an efficient operation environment for services, and unification of virtual resources on different servers is realized. The basic principle is that virtual resources corresponding to a plurality of servers are divided into a plurality of application containers, so that a developer can package and apply the virtual resources to a portable container and distribute the virtual resources to any computer, and containerization of the application is realized.
Currently, in the field of financial technology, a kubernets container scheduling platform may manage application containers on multiple servers in a single cluster, and implement deployment, planning, updating, and maintenance of applications. However, the Kubernetes container scheduling platform cannot realize cross-cluster management of application containers, and can complete deployment of application containers with large traffic volume only by requiring a large number of label labels and rule formulation, which causes great difficulty in rule formulation and maintenance, and a failure in flexible rule extension, and also increases deployment cost of application containers.
Disclosure of Invention
The embodiment of the application container management method, device and equipment achieves the process that the application container is deployed on a server to run across a cluster, and reduces the cost of rule making in the early stage and rule maintenance in the later stage.
In a first aspect, an embodiment of the present application provides an application container management method, including:
receiving distribution demand information of the application container, wherein the distribution demand information is used for expressing the demand of the application container for deploying the target server;
acquiring relevant information of each server in a plurality of servers, wherein the plurality of servers belong to different clusters;
determining one server of the plurality of servers as a target server according to a preset rule related to the distribution demand information based on the related information of each server of the plurality of servers;
the application container is notified to run on the target server.
By the method provided by the first aspect, the virtual resources of all the servers can be regarded as a large resource pool by acquiring the relevant information of the plurality of servers belonging to different clusters. Therefore, based on the relevant information of the plurality of servers, one server can be selected from the plurality of servers as a target server for the application container according to the rule corresponding to the distribution demand information of the application container, and the business personnel can be informed that the application container runs on the target server. Therefore, deployment of the application container on a plurality of servers belonging to different clusters is achieved, the problem that the clusters cannot be spanned is solved, the preset rule is related to deployment of the application container, the rule making process is simplified, places where a large number of label labels and rule making are needed are replaced, follow-up maintenance of the rule is facilitated, the rule making and maintenance cost is reduced, the preset rule can be adjusted in time, business personnel are allowed to increase and decrease the rule and adjust the priority of the rule, and the preset rule has good expansibility.
In one possible design, the allocation requirement information includes: a specified system name, a specified deployment scope, a specified hardware resource requirement, and a specified affinity attribute;
determining one of the plurality of servers as a target server according to a preset rule related to the distribution demand information based on the related information of each of the plurality of servers, including:
determining a server meeting the mandatory distribution rule in the plurality of servers as a first server set based on the relevant information of each server in the plurality of servers; wherein the mandatory allocation rule is associated with a specified deployment scope, a specified hardware resource requirement, and a specified affinity attribute; determining the servers in the first server set, which meet the high availability rule, as a second server set; wherein the high availability rule is associated with a specified deployment scope and a specified system name; one server in the second set of servers is determined to be the target server.
Therefore, the multiple servers belonging to different clusters are screened based on mandatory distribution rules, high availability rules and other rules which must be met, the application containers can be deployed on the servers matched with the affinity and are far away from the servers matched with the anti-affinity based on the distribution demand information of the application containers, and the corresponding instances of the system to which the application containers belong can be dispersed, so that the application containers can run well, and the deployment of the application containers is convenient for later maintenance.
In one possible design, determining a server of the plurality of servers that meets the mandatory allocation rule as the first set of servers includes:
and aiming at any one of the plurality of servers, when the physical position of the server accords with the specified deployment range, the hardware information of the server accords with the specified hardware resource requirement and the affinity attribute of the server accords with the specified affinity attribute, determining that the server belongs to the first server set.
Therefore, the management platform can eliminate the servers which do not meet the mandatory distribution rule from the servers, so that the servers can be rapidly distributed to the application container, and the deployment speed is improved.
In one possible design, determining a server of the first set of servers that meets the high availability rule as the second set of servers includes:
for any server in the first server set, when s +1 is less than a preset minimum number of instances, or s +1 is more than or equal to the preset minimum number of instances and (n +1)/(s +1) is less than or equal to a preset maximum proportion, determining that the server belongs to a second server set; wherein n is the number of instances of the system corresponding to the specified system name contained in the specified deployment scope, s is the number of instances of the system corresponding to the specified system name contained in the first server set, and n and s are natural numbers.
Therefore, the management platform can dispersedly deploy a plurality of instances of the same type as the instances of the system corresponding to the application container based on the high availability rule, so that under the scenes that a server fails, a network fails or a deployment area is powered off, the rest servers which normally operate and have the same type as the instances can bear all the instances, the application container can smoothly operate on the server, the corresponding service can be smoothly realized, and the multi-instance and high-availability redundancy requirements are met.
In one possible design, determining one server in the second set of servers as the target server includes:
when only one server exists in the second server set, determining the server as a target server; when a plurality of servers exist in the second server set, determining the servers meeting the step scoring rule in the second server set as a third server set; wherein the step scoring rule is related to the allocation requirement information; one server in the third set of servers is determined to be the target server.
Therefore, the server output by the rule which needs to be met is scored based on the rule which is met as much as possible such as the step scoring rule, so that the server which is more suitable for the operation of the application container is obtained, the resource residual proportion of the resource pool tends to be average, and the excessive pressure or resource waste of the server is avoided.
In one possible design, determining a server in the second set of servers that meets the step scoring rule as a third set of servers includes:
based on the specified deployment range, the specified system name and the specified affinity attribute, scoring each server in the second server set, and determining the server with the highest score as a fifth server set; and determining the servers meeting the preset conditions in the fifth server set as a third server set.
Therefore, the management platform can accurately match the server for the application container based on the requirement of the application container.
In one possible design, scoring each server in the second set of servers based on a specified deployment scope, a specified system name, and a specified affinity attribute, and determining the server with the highest score as a fifth set of servers includes:
for any server in the second server set, when the physical position of the server belongs to the lower i level of the specified deployment range, determining the score of the server as the current score-n, and updating i-i +1 until i-m; determining the server with the highest score in the second server set as a fourth server set; wherein n is the number of instances of the system corresponding to the specified system name contained in the server, the initial value of i is 1, m is the total number of levels below the specified deployment range, and n, i and m are natural numbers;
for any one server in the fourth server set, when the affinity attribute of the server meets the specified affinity attribute, determining that the score of the server is the current score + 1; and determining the server with the highest score in the fourth server set as the fifth server set.
Therefore, the servers are scored based on the deployment range, the system name and the affinity attribute in the distribution demand information of the application container, and the servers which are more suitable for the demands of the application container can be determined.
In one possible design, the deployment context levels include, in order from high to low, a data center, a logical partition, a fleet, a rack, and a server.
In one possible design, determining a server in the fifth set of servers that meets a preset condition as the third set of servers includes:
when a > c, determining the server with the minimum bj in the fifth server set as a third server set; when a < c, determining the server with the largest bj in the fifth server set as a third server set; when a is equal to c, determining the server with the minimum difference between bj and a in the fifth server set as a third server set; wherein a is the ratio of the total CPU and the total memory of all the servers in the fifth server set, bj is the ratio of the remaining CPU and the remaining memory of the jth server in the fifth server set, the initial value of j is 1, j takes a positive integer which is greater than or equal to 1 and less than or equal to p, p is the total number of the servers in the fifth server set, j and p are positive integers, and c is the ratio of the CPU and the memory in the specified hardware resource requirement.
Therefore, based on the hardware resource requirement in the distribution requirement information of the application container, the server which is more in accordance with the requirement of the application container can be determined, the residual resources of all the servers can be balanced to tend to be average, and the excessive pressure or resource waste of the server is avoided.
In one possible design, the information about any one server includes: the physical location of the server, hardware information, remaining available resources, the included instance manifest corresponding to each system name, and affinity attributes.
In a second aspect, an embodiment of the present application provides an application container management apparatus, including: the system comprises a receiving module, a processing module and a processing module, wherein the receiving module is used for receiving distribution demand information of an application container, and the distribution demand information is used for expressing the demand of the application container for deploying a target server; the system comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for acquiring relevant information of each server in a plurality of servers, and the servers belong to different clusters; the determining module is used for determining one server in the plurality of servers as a target server according to a preset rule related to the distribution demand information based on the related information of each server in the plurality of servers; and the notification module is used for notifying the application container to run on the target server.
In one possible design, the allocation requirement information includes: a specified system name, a specified deployment scope, a specified hardware resource requirement, and a specified affinity attribute; the determining module is used for determining a server meeting the mandatory distribution rule in the plurality of servers as a first server set based on the relevant information of each server in the plurality of servers; wherein the mandatory allocation rule is associated with a specified deployment scope, a specified hardware resource requirement, and a specified affinity attribute; determining the servers in the first server set, which meet the high availability rule, as a second server set; wherein the high availability rule is associated with a specified deployment scope and a specified system name; one server in the second set of servers is determined to be the target server.
In one possible design, the determining module is specifically configured to determine, for any one of the plurality of servers, that the server belongs to the first set of servers when the physical location of the server meets a specified deployment range, the hardware information of the server meets a specified hardware resource requirement, and the affinity attribute of the server meets a specified affinity attribute.
In one possible design, the determining module is specifically configured to determine, for any one server in the first server set, that the server belongs to the second server set when s +1 is smaller than a preset minimum number of instances, or s +1 is greater than or equal to the preset minimum number of instances and (n +1)/(s +1) is smaller than or equal to a preset maximum occupancy ratio; wherein n is the number of instances of the system corresponding to the specified system name contained in the specified deployment scope, s is the number of instances of the system corresponding to the specified system name contained in the first server set, and n and s are natural numbers.
In one possible design, the determining module is specifically configured to determine the server as the target server when only one server exists in the second server set; when a plurality of servers exist in the second server set, determining the servers meeting the step scoring rule in the second server set as a third server set; wherein the step scoring rule is related to the allocation requirement information; one server in the third set of servers is determined to be the target server.
In one possible design, the determining module is specifically configured to score each server in the second set of servers based on a specified deployment range, a specified system name, and a specified affinity attribute, and determine a server with a highest score as a fifth set of servers; and determining the servers meeting the preset conditions in the fifth server set as a third server set.
In one possible design, the determining module is specifically configured to, for any one server in the second server set, determine that the score of the server is the current score-n when the physical location of the server belongs to a lower i level of the specified deployment range, and update i ═ i +1 until i ═ m; determining the server with the highest score in the second server set as a fourth server set; wherein n is the number of instances of the system corresponding to the specified system name contained in the server, the initial value of i is 1, m is the total number of levels below the specified deployment range, and n, i and m are natural numbers; for any one server in the fourth server set, when the affinity attribute of the server meets the specified affinity attribute, determining that the score of the server is the current score + 1; and determining the server with the highest score in the fourth server set as the fifth server set.
In one possible design, the deployment context levels include, in order from high to low, a data center, a logical partition, a fleet, a rack, and a server.
In one possible design, the determining module is specifically configured to determine, when a > c, a server with a smallest bj in the fifth server set as the third server set; when a < c, determining the server with the largest bj in the fifth server set as a third server set; when a is equal to c, determining the server with the minimum difference between bj and a in the fifth server set as a third server set; wherein a is the ratio of the total CPU and the total memory of all the servers in the fifth server set, bj is the ratio of the remaining CPU and the remaining memory of the jth server in the fifth server set, the initial value of j is 1, j takes a positive integer which is greater than or equal to 1 and less than or equal to p, p is the total number of the servers in the fifth server set, j and p are positive integers, and c is the ratio of the CPU and the memory in the specified hardware resource requirement.
In one possible design, the information about any one server includes: the physical location of the server, hardware information, remaining available resources, the included instance manifest corresponding to each system name, and affinity attributes.
The beneficial effects of the application container management apparatus provided in the second aspect and in each possible design of the second aspect may refer to the beneficial effects brought by each possible implementation manner of the first aspect, and are not described herein again.
In a third aspect, an embodiment of the present application provides an electronic device, including: a memory and a processor; the memory is used for storing program instructions; the processor is configured to invoke the program instructions in the memory to cause the electronic device to perform the method for application container management in the first aspect and in any one of the possible designs of the first aspect.
In a fourth aspect, an embodiment of the present application provides a computer storage medium, which includes computer instructions, and when the computer instructions are executed on an electronic device, the electronic device executes the application container management method in any one of the possible designs of the first aspect and the first aspect.
In a fifth aspect, embodiments of the present application provide a computer program product, which when run on a computer, causes the computer to execute the application container management method in the first aspect and any one of the possible designs of the first aspect.
In a sixth aspect, an embodiment of the present application provides a chip system, where the chip system includes: a processor; the electronic device performs the application container management method of the first aspect and any one of the possible designs of the first aspect when the processor executes the computer instructions stored in the memory.
Drawings
Fig. 1 is a flowchart of an application container management method according to an embodiment of the present application;
FIGS. 2A-2B are schematic diagrams of human-computer interaction interfaces provided by an embodiment of the present application;
fig. 3 is a schematic structural diagram of an application container management apparatus according to an embodiment of the present application.
Detailed Description
The method for distributing the application containers in the Kubernetes (K8 s for short) container scheduling platform comprises the following steps: the affinity mechanism in the kubernets container scheduling platform may manage the deployment process of application containers on servers. The management rule of the affinity mechanism includes the following contents:
1. management rules can be divided into two dimensions: the rules that must be satisfied and the rules that are as satisfied as possible.
2. In the management rule, the server is scored according to whether the server of a certain label is compatible or not in the distribution requirement information of the application container.
3. In the management rule, the server is scored based on the deployed application containers in the server according to whether the application containers of a certain label in the distribution demand information of the application containers are affinity or anti-affinity.
4. And (4) based on the final scores of the servers obtained in the step 2 and the step 3, allocating the application containers to the servers with the highest scores.
Based on the above process, the kubernets container scheduling platform can allocate servers for application containers, but has the following disadvantages:
1. one Kubernets container scheduling platform corresponds to servers in one cluster, the number of the servers and the resource capacity managed by the single Kubernets container scheduling platform are limited, and the affinity mechanism in the single Kubernets container scheduling platform cannot be used across the cluster.
2. The Kubernetes container scheduling platform requires a service person to manually perform a large amount of label labeling and rule making on a server. When the deployment of the application container with large traffic is finished, the establishment and maintenance of the management rule are difficult.
3. The affinity mechanism in the kubernets container scheduling platform lacks extensibility.
4. An affinity mechanism in a Kubernets container scheduling platform cannot sense the physical position of a server, cannot meet the requirement of a system on multi-instance and high-availability redundancy, and cannot deal with the problems of server failure, physical environment failure and the like.
5. The affinity mechanism in the kubernets container scheduling platform has the problem that it may cause processing stress or resource waste on individual servers.
In order to solve the above problem, embodiments of the present application provide an application container management method, apparatus, device, electronic device, computer storage medium, computer program product, and chip system, which are applied to the field of financial technology, and can obtain relevant information of each server in a plurality of servers belonging to different clusters, and view virtual resources of all servers as a large resource pool. Based on the relevant information of each server in the plurality of servers, according to the rule corresponding to the distribution demand information of the application container, one server can be selected from the plurality of servers as a target server for the application container, and business personnel are informed that the application container runs on the target server. Therefore, deployment of the application container on a plurality of servers belonging to different clusters is achieved, the problem that the clusters cannot be spanned is solved, the preset rule is related to deployment of the application container, the rule making process is simplified, places where a large number of label labels and rule making are needed are replaced, follow-up maintenance of the rule is facilitated, the rule making and maintenance cost is reduced, the preset rule can be adjusted in time, business personnel are allowed to increase and decrease the rule and adjust the priority of the rule, and the preset rule has good expansibility. In addition, by using the high-availability rule in the preset rules, under the scenes of server failure and physical environment failure such as power failure or network failure, the rest servers which normally operate and operate in the same type as the instance can bear all the instances, so that the application container can smoothly operate on the servers, and the corresponding service can be ensured to be smoothly realized. In addition, by utilizing the step scoring rule in the preset rule, the residual resources in the resource pool tend to be average, and the excessive pressure or resource waste of the server is avoided.
Referring to fig. 1, fig. 1 is a schematic flowchart illustrating an application container management method according to an embodiment of the present application. As shown in fig. 1, with a management platform as an execution subject, the application container management method according to the embodiment of the present application may include:
s101, receiving distribution demand information of the application container.
When the management platform detects that a certain application container is abnormal or detects that a business person manually triggers an instruction for deploying the application container, the management platform can receive the distribution demand information of the application container.
The application container may be configured to deploy a new service, or may be configured to increase the service volume of an old service, and the service type is not limited in this embodiment of the present application. For example, no transfer service exists in the bank system in the area A, but the transfer service is expanded in the area A, and the management platform can add an application container for the transfer service in the area A to realize the transfer service in the area A. For another example, in the banking system in the area a, the application container corresponding to the existing transfer service may support 100 transactions per day, but considering that the current transfer service in the area a is added to 200 transactions per day actually, the service person may add an application container to the transfer service in the area a through the management platform, support 100 transactions that are added each day, and satisfy the current transfer service in the area a.
The allocation requirement information is used for requesting to allocate a new server (i.e. a target server) to the application container, so that the application container can run on the server, and the allocation requirement information also represents requirements of the server for deploying the application container, such as information of a physical location of the target server, hardware information, remaining available resources, an included instance list corresponding to each system name, and an affinity attribute. The allocation requirement information may include, but is not limited to: a specified system name, a specified deployment scope, a specified hardware resource requirement, and a specified affinity attribute.
The system name is used for uniquely representing a certain system, such as a transfer instruction receiving system, a transfer result notification system and a transfer logic control system related to the transfer service. Usually, a plurality of systems can realize one service, and the related combination of the plurality of systems can realize the transfer service.
The deployment scope is used for representing the structure of a specific construction server, and the level of the deployment scope can include the following steps from high to low: data centers, logical partitions (equivalent to rooms), machine ranks, racks, servers, etc., for example, the specified deployment range may be any one or more of the foregoing levels. The deployment range may further include other manners of hierarchical division, which may be specifically determined by a construction structure of an actual data center, and the embodiment of the present application is not limited thereto.
Hardware resource requirements may include, but are not limited to, Central Processing Units (CPUs), memory, hard disks, Graphics Processing Units (GPUs), and the like.
The affinity attribute is used to indicate the resource characteristics of the system corresponding to the application container, such as a CPU type, a memory type, an IO type (i.e., an IO of a hard disk, which mainly implements a data read-write function), and is also used to indicate with which type of system the system corresponding to the application container desires to be deployed and/or with which type of system the system desires not to be deployed, and if the system a can use the function of the system B, the management platform can deploy the server corresponding to the system a with the server corresponding to the system B, which is beneficial to reducing network delay. In the embodiments of the present application, the number of application containers is not limited. For convenience of explanation, the embodiment of the present application is illustrated by taking an application container as an example.
S102, obtaining relevant information of each server in a plurality of servers. Wherein the plurality of servers belong to different clusters.
After receiving the distribution demand information of the application container in step S101, the management platform may obtain the relevant information of each server in the plurality of servers belonging to different clusters, and view the plurality of servers belonging to different clusters as a resource pool to be arranged comprehensively.
The management platform may use a database, such as a Configuration Management Database (CMDB), to store a server list in advance, and record related information of each server in detail. The related information of any one server may include but is not limited to: the physical location of the server, hardware information, remaining available resources, the included instance manifest corresponding to each system name, and affinity attributes. In addition, the management platform may also obtain, in other devices, related information of each server in the multiple servers belonging to different clusters, which is not limited in this embodiment of the present application.
S103, based on the relevant information of each server in the plurality of servers, one server in the plurality of servers is determined as a target server according to a preset rule relevant to the distribution demand information.
The management platform selects one server from the plurality of servers belonging to different clusters as a target server according to the relevant information of each server in the plurality of servers and the preset rule relevant to the distribution demand information of the application container, and distributes the application container to the target server for running. Therefore, the method is beneficial to comprehensively considering factors such as virtual resources, physical environments and the like of all the servers, and realizes the process of distributing the servers for the application containers across the clusters.
The preset rules are preset in the management platform and are related to the distribution demand information, so that the management platform automatically distributes the servers for the application containers based on the distribution demand information of the application containers, actual demands of the application containers are practically met, rule expansion and later maintenance are facilitated, and the rule making and maintenance cost is reduced.
And S104, informing the application container to run on the target server.
After determining the target server based on step S103, the management platform may notify the service personnel that the application container may be operated on the target server, so that the service personnel can deploy the application container on the target server in time to complete the process of operating the application container on the target server.
The method for notifying the service personnel of the target server by the management platform is not limited in the embodiment of the application. For example, the management platform may display a notification interface with the relevant information of the target server to the service staff, or the management platform may notify the service staff of the relevant information of the target server in the form of mail, short message, or the like, or the management platform calls the notification interface defined in advance to perform the notification. In addition, the embodiment of the present application is not limited to the foregoing notification manner.
It should be noted that, when the management platform does not find a suitable server for the application container, the management platform may also notify the business personnel of the unsuccessful server allocation for the application container and the relevant reason of the allocation failure, so that the business personnel can adjust the allocation requirement information of the application container in time.
In a specific embodiment, a specific implementation process of the management platform allocating the target server to the application container is described with reference to fig. 2A to 2B.
Referring to fig. 2A-2B, fig. 2A-2B are schematic diagrams of a human-machine interface according to an embodiment of the present disclosure.
The service person may log on the user interface 11 of the management platform exemplarily shown in fig. 2A, and the user interface 11 is used for showing the user the allocation requirement information of the application container required to be provided to the management platform. The user interface 11 includes option 1, option 2, option 3, and option 4, where option 1 is used to provide a system name of the application container, option 2 is used to provide a deployment scope of the application container, option 3 is used to provide a hardware resource requirement of the application container, and option 4 is used to provide an affinity attribute of the application container.
The service person may specify the distribution requirement information of the application container in the user interface 11, for example, the service person selects the system name of the application container, the resource type of the system, the CPU, the memory, the deployment range, and the anti-affinity attribute, or may default the distribution requirement information of the application container in the user interface 11, for example, the service person defaults the affinity attribute, which is not limited in this embodiment of the present application.
After the service person has specified the distribution requirement information of the application container, after receiving an operation of adding the distribution requirement information of the application container by the service person (for example, clicking a text "submit" control in the user interface 11), the management platform may obtain that the distribution requirement information of the application container is: the system a is deployed in a data center n, a logical partition 1, a machine column x, a 3-core CPU +6G memory, the resource type of the system corresponding to the system a is an IO type, and the system a does not have to be deployed in a mixed manner with the IO type system, so that the management platform executes step S103, and allocates one server to the application container from the plurality of servers based on the related information of each server in the plurality of servers.
After the management platform determines the target server according to the preset rule related to the distribution demand information of the application container, an exemplary user interface 12 in fig. 2B may be displayed, where the user interface 12 is used to prompt the service staff to operate the application container on the target server, for example, to display prompt information (i.e., an exemplary interface shown in the user interface 12) or display related information of the target server, so that the service staff may know the target server in time, and the service staff may conveniently deploy the application container in the target server, so that the application container may operate on the target server.
It should be noted that the user interface 11/12 may include, but is not limited to, the foregoing content, and the embodiment of the present application does not limit the specific implementation manner of the user interface 11/12.
According to the application container management method provided by the embodiment of the application container management method, the relevant information of the plurality of servers belonging to different clusters is obtained, and the virtual resources of all the servers can be regarded as a large resource pool. Therefore, based on the relevant information of the plurality of servers, one server can be selected from the plurality of servers as a target server for the application container according to the rule corresponding to the distribution demand information of the application container, and the business personnel can be informed that the application container runs on the target server. Therefore, deployment of the application container on a plurality of servers belonging to different clusters is achieved, the problem that the clusters cannot be spanned is solved, the preset rule is related to deployment of the application container, the rule making process is simplified, places where a large number of label labels and rule making are needed are replaced, follow-up maintenance of the rule is facilitated, the rule making and maintenance cost is reduced, the preset rule can be adjusted in time, business personnel are allowed to increase and decrease the rule and adjust the priority of the rule, and the preset rule has good expansibility. In some embodiments, the preset rules may include rules that must be satisfied, such as mandatory allocation rules and high availability rules. The mandatory allocation rule refers to a rule that hard indexes of a server must meet, and is generally related to a deployment range, hardware resource requirements and affinity attributes. The high availability rule refers to the degree to which server failures can be tolerated, which may correspond to multi-instance, high availability requirements, and is typically related to deployment scope and system name.
In a possible implementation manner of step S103, the management platform may select a server meeting the mandatory allocation rule from the plurality of servers based on the relevant information of each server in the plurality of servers, and determine the server meeting the mandatory allocation rule as the first server set. And the management platform selects a server meeting the high availability rule from the first server set, and determines the server meeting the high availability rule as a second server set. Thus, the management platform may determine one server in the second set of servers as the target server.
The number, the type and other parameters of the servers in the first server set and the second server set are not limited in the application.
It should be noted that, in addition to the above manner, the management platform may also perform the step of determining whether the server meets the high availability rule, then perform the step of determining whether the server meets the mandatory allocation rule, and may also perform the step of determining whether the server meets the mandatory allocation rule and the high availability rule at the same time, which is not limited in this embodiment of the present application.
The embodiment of the present application does not limit a specific implementation manner of the mandatory allocation rule. In some embodiments, the mandatory allocation rule may preset three filtering rules, which are:
1. and selecting a server list meeting the specified deployment range from the plurality of servers according to the deployment range specified in the distribution demand information.
For example, the deployment range specified in the allocation demand information is: and the data center n, the logical partition 1 and the machine column x, the server list selected by the management platform needs to be located in the specified deployment range.
2. And according to the hardware resource requirement specified in the distribution requirement information, removing the servers which cannot meet the hardware resource requirement from the plurality of servers.
For example, the hardware resource requirements specified in the allocation requirement information are: and if the 3-core CPU +6G memory exists, the management platform rejects the server with the residual resource smaller than that of the 3-core CPU or the 6G memory.
3. And selecting a server with matching affinity from the plurality of servers according to an affinity rule specified in the distribution demand information, and removing the server with matching anti-affinity.
For example, the affinity rule specified in the allocation requirement information is: if the management platform is not required to be deployed in a mixed manner with the IO type system, all the servers corresponding to the IO type system are removed by the management platform.
It should be noted that, the three screening rules do not have a sequential order in time sequence, and may be executed simultaneously or sequentially according to actual needs. In addition, the management platform can add an additional screening rule at any position.
Therefore, for any one of the plurality of servers, when the physical position of the server meets the specified deployment range, the hardware information of the server meets the specified hardware resource requirement, and the affinity attribute of the server meets the specified affinity attribute, the management platform can determine that the server belongs to the first server set.
It should be noted that other parameters may be added or deleted in the mandatory allocation rule, and a service person is allowed to delete the rule and adjust the priority of the rule, so that the mandatory allocation rule has good extensibility.
The embodiment of the present application does not limit the specific implementation manner of the high availability rule. In some embodiments, three parameters are included in the high availability rule: high available computational units, highest fractional percentage within a unit, least number of instances.
1. A highly available computing unit: corresponding to the specified deployment scope. For example, a highly available computing unit may include: at least one level of data center, logical partition, machine column, rack, server, etc. performs the computation, i.e., the management platform may set one or more highly available computing units.
2. Highest proportion in unit: the ratio of the number of the corresponding instances of the system in any one high-availability computing unit to the number of the corresponding instances of the system in the currently checked server cannot exceed the preset highest ratio.
3. Minimum number of instances: when the number of the instances corresponding to the system in the plurality of servers does not exceed the preset minimum number of the instances, the verification of the high availability rule may not be performed. Wherein the preset minimum number of examples is more than or equal to (1/preset maximum ratio).
In some embodiments, the screening of the mandatory allocation rule, the checking of the high availability rule for the servers in the first set of servers comprises the following steps:
1. the management platform judges whether the number of the instances corresponding to the system in the first server set is smaller than a preset minimum number of the instances.
2. If not, the high availability rule is not needed to be checked, and the server in the first server set can be determined to meet the high availability rule. If yes, judging whether the ratio of the number of the instances corresponding to the system in any one high-availability computing unit to the number of the instances corresponding to the system in the first server set is smaller than or equal to a preset highest ratio.
3. If so, it may be determined that the servers in the first set of servers meet the high availability rule. If not, the server in the first set of servers can be determined not to meet the high availability rule, and the corresponding server can be removed.
Therefore, for any server in the first server set, when s +1 is less than the preset minimum number of instances, or s +1 is greater than or equal to the preset minimum number of instances and (n +1)/(s +1) is less than or equal to the preset maximum proportion, the management platform can determine that the server belongs to the second server set.
Wherein n is the number of instances of the system corresponding to the specified system name contained in the specified deployment scope, s is the number of instances of the system corresponding to the specified system name contained in the first server set, and n and s are natural numbers.
In a specific embodiment, if the management platform sets two high-availability computing units, the management platform sets two high-availability rules, which are:
rule one is as follows: a highly available computing unit: a data center; presetting a highest proportion: 50 percent; preset minimum number of instances: 2. therein, note that 2 ≧ 1/50%.
Rule two: a highly available computing unit: a frame; presetting a highest proportion: 33%; preset minimum number of instances: 3. therein, note that 3 ≧ 1/33%.
1. Assume that the distribution demand information x from an application container a1 at this time belongs to a completely new system a. Since there is no instance of system a corresponding to the current environment in the plurality of servers, 1 < 2, 1 < 3. Therefore, the management platform does not need to check the rule I and the rule II.
2. Next, the distribution demand information y from the application container a2 still belongs to the system a. Then for rule one, 2-2, the management platform requests that application container a2 be allocated to a different data center than application container a1, otherwise rule one cannot be satisfied. Then for rule one, 2 < 3, the management platform does not need to check for rule two.
3. Next, the distribution demand information z from the application container a3 still belongs to the system a. Then for rule one, 3 > 2, the management platform would require that application container A3 be allocated to a different data center than both application container a1 and application container a2, otherwise rule one would not be satisfied.
In some embodiments, the preset rules may also include rules that are best satisfied, such as a step scoring rule. The step scoring rule is a rule for scoring the server screened by the rule which needs to be met so as to obtain the server which is most suitable for deploying the application container, and the step scoring rule is related to the distribution requirement information.
The embodiment of the present application does not limit the specific implementation manner of the ladder scoring rule. In some embodiments, the step scoring rules include the following:
1. and according to the rule of each level, scoring the available servers to obtain the server with the highest score. If the server is a server, the management platform determines the server as a target server. If the server is a plurality of servers, the management platform takes the plurality of servers as available servers for carrying out the next-level rule. In addition, when the management platform calculates the last-level rule, a plurality of servers with the highest scores still exist, and then the management platform can randomly select one server from the servers as a target server.
2. In each level of rules, the management platform may set one or more scored rules. If the rule A is prior to the rule B, the management platform can set the rule A at an earlier step than the rule B; if the priority of the A rule is the same as that of the B rule, the management platform can set the A rule to be at the same ladder as that of the B rule, but the management platform can set the scoring weight of the A rule and the B rule based on the factors of resources of a plurality of servers and the like.
3. The step scoring rules can include the following three-level rules, which are as follows:
first step-best-dispersion rule: starting from the next level of the deployment range specified in the distribution demand information of the application container, calculating the number of instances corresponding to the existing system in the next level of the specified deployment range, and subtracting 1 point from the server in the next level of the specified deployment range every time when one instance exists; after the next level of the assigned deployment range is calculated, the server with the highest score is selected, and the same calculation is carried out on the next two levels of the assigned deployment range until the lowest level of the assigned deployment range.
For example, the deployment context includes a data center, a logical partition, a fleet, a rack, and a server. The allocation requirement information is assigned to the rank of the machine column, then the management platform may first calculate the number of instances corresponding to the systems already in the same rack from this rank of the rack, subtract 1 point from the servers in the rack each time there is an instance, and select the server with the highest score. The management platform then starts with each server in the rack, counts the number of instances corresponding to the systems already present in the same server, decrements the server by 1 each time there is an instance, and selects the server with the highest score.
Second step-affinity rule: for any one server, adding 1 point to the server every time one affinity in the specified affinity attributes is matched; each time an anti-affinity of one of the specified affinity attributes is matched, the server decrements the score of 1; and the management platform outputs the server with the highest score.
Third step-high usage rule: the management platform calculates the ratio a of the CPU sum and the memory sum of all the servers in the batch of servers. Wherein, the meaning of the value a is the standard specification of the ratio of CPU and memory which is most suitable to be distributed to the batch of servers. Then, the management platform calculates the ratio b of the remaining CPU occupation ratio and the remaining memory occupation ratio of each server in the batch of servers. Then, the management platform compares a with the ratio c of the CPU to the memory of the hardware resource requirement specified in the allocation requirement information.
If a is larger than c, the management platform selects a server with the minimum b value; if a is less than c, the management platform selects the server with the maximum b value; and if a is equal to c, the management platform selects the server with the b value closest to a.
Thus, when there is only one server in the second set of servers, the management platform may determine the server as the target server. When a plurality of servers exist in the second server set, the management platform can determine a server in the second server set, which meets the step scoring rule, as a third server set, and determine one server in the third server set as a target server.
It should be noted that any level of rule can be added or deleted in the ladder scoring rule, and business personnel is allowed to delete the rule and adjust the priority of the rule, so that the ladder scoring rule has good expansibility.
In some embodiments, the management platform may score each server in the second set of servers based on the specified deployment scope, the specified system name, and the specified affinity attribute, and determine the server with the highest score as the fifth set of servers.
Specifically, for any one server in the second server set, when the physical location of the server belongs to the lower i level of the specified deployment range, the management platform may determine that the score of the server is the current score-n, update i ═ i +1 until i ═ m, and determine the server with the highest score in the second server set as the fourth server set.
Wherein n is the number of instances of the system corresponding to the specified system name contained in the server, the initial value of i is 1, m is the total number of levels below the specified deployment range, and n, i and m are natural numbers.
For any one server in the fourth server set, when the affinity attribute of the server meets the specified affinity attribute, the management platform may determine that the score of the server is the current score +1, and determine the server with the highest score in the fourth server set as the fifth server set.
Then, the management platform may determine, as the third server set, a server in the fifth server set that meets a preset condition.
When a > c, the management platform may determine that the server with the smallest bj in the fifth set of servers is the third set of servers. At a < c, the management platform may determine that the server with the largest bj in the fifth set of servers is the third set of servers. When a is equal to c, the management platform may determine that the server with the smallest difference between bj and a in the fifth server set is the third server set.
Wherein a is the ratio of the total CPU and the total memory of all the servers in the fifth server set, bj is the ratio of the remaining CPU and the remaining memory of the jth server in the fifth server set, the initial value of j is 1, j takes a positive integer which is greater than or equal to 1 and less than or equal to p, p is the total number of the servers in the fifth server set, j and p are positive integers, and c is the ratio of the CPU and the memory in the specified hardware resource requirement.
In the embodiment of the present application, parameters such as the number and the type of the servers in the third server set, the fourth server set, and the fifth server set are not limited.
In one specific embodiment, as shown in table 1, the fifth server set includes server 1, server 2 and server 3, and the management platform can calculate a as 0.458, that is, for the servers in the fifth server set, the standard specification is 0.458 core CPU +1G memory (and its scaled-up specification).
TABLE 1 servers in the fifth set of servers
Server General CPU Remaining CPU Total memory Residual memory bj (j takes 1, 2 and 3)
1 32 16 64 32 0.5
2 32 16 64 24 0.666
3 24 16 64 40 0.4
Based on the contents of table 1, the relative averages of CPU and memory allocation are for server 1. For the server 2, the memory allocation speed is faster than that of the CPU. For the server 3, the CPU is allocated faster than the memory.
1. If there is allocation demand information of an application container requiring 1-core CPU +1G memory, the management platform may calculate that c of the allocation demand information of the application container is 1, and a < c, so that the management platform may select the server (i.e., server 2) with the largest b value, so as to alleviate the phenomenon that the memory allocation speed of the server 2 is faster.
2. If there is allocation demand information of an application container requiring 1-core CPU +3G memory, the management platform may calculate c as 0.33, a > c of the allocation demand, and therefore, the management platform may select the server (i.e., server 1) with the smallest b value, so as to alleviate the phenomenon that the CPU allocation speed of server 1 is fast.
Exemplarily, the embodiment of the present application further provides an application container management apparatus.
Referring to fig. 3, fig. 3 is a schematic structural diagram of an application container management device according to an embodiment of the present application.
The application container management device in the embodiment of the application can be arranged in a server, and the operation of the embodiment of the application container management method corresponding to the management platform can be realized. As shown in fig. 3, the application container management apparatus according to the embodiment of the present application may include: a receiving module 101, an obtaining module 102, a determining module 103 and a notifying module 104.
The receiving module 101 is configured to receive allocation requirement information of the application container, where the allocation requirement information is used to represent a requirement for deploying the target server for the application container.
The obtaining module 102 is configured to obtain relevant information of each of a plurality of servers, where the plurality of servers belong to different clusters.
The determining module 103 is configured to determine, based on the relevant information of each of the plurality of servers, one of the plurality of servers as a target server according to a preset rule related to the distribution demand information.
A notification module 104 for notifying the application container to run on the target server.
In some embodiments, the allocation requirement information comprises: a specified system name, a specified deployment scope, a specified hardware resource requirement, and a specified affinity attribute.
A determining module 103, configured to determine, as a first server set, a server in the plurality of servers that meets the mandatory allocation rule based on the relevant information of each server in the plurality of servers; wherein the mandatory allocation rule is associated with a specified deployment scope, a specified hardware resource requirement, and a specified affinity attribute; determining the servers in the first server set, which meet the high availability rule, as a second server set; wherein the high availability rule is associated with a specified deployment scope and a specified system name; one server in the second set of servers is determined to be the target server.
In some embodiments, the determining module 103 is specifically configured to determine, for any one of the plurality of servers, that the server belongs to the first set of servers when the physical location of the server meets a specified deployment range, the hardware information of the server meets a specified hardware resource requirement, and the affinity attribute of the server meets a specified affinity attribute.
In some embodiments, the determining module 103 is specifically configured to, for any one server in the first server set, determine that the server belongs to the second server set when s +1 is less than a preset minimum number of instances, or s +1 is greater than or equal to the preset minimum number of instances and (n +1)/(s +1) is less than or equal to a preset maximum share ratio; wherein n is the number of instances of the system corresponding to the specified system name contained in the specified deployment scope, s is the number of instances of the system corresponding to the specified system name contained in the first server set, and n and s are natural numbers.
In some embodiments, the determining module 103 is specifically configured to determine the server as the target server when only one server exists in the second server set; when a plurality of servers exist in the second server set, determining the servers meeting the step scoring rule in the second server set as a third server set; wherein the step scoring rule is related to the allocation requirement information; one server in the third set of servers is determined to be the target server.
In some embodiments, the determining module 103 is specifically configured to score each server in the second set of servers based on the specified deployment scope, the specified system name, and the specified affinity attribute, and determine the server with the highest score as the fifth set of servers; and determining the servers meeting the preset conditions in the fifth server set as a third server set.
In some embodiments, the determining module 103 is specifically configured to, for any server in the second server set, determine that the score of the server is the current score-n when the physical location of the server belongs to the lower i level of the specified deployment range, and update i ═ i +1 until i ═ m; determining the server with the highest score in the second server set as a fourth server set; wherein n is the number of instances of the system corresponding to the specified system name contained in the server, the initial value of i is 1, m is the total number of levels below the specified deployment range, and n, i and m are natural numbers; for any one server in the fourth server set, when the affinity attribute of the server meets the specified affinity attribute, determining that the score of the server is the current score + 1; and determining the server with the highest score in the fourth server set as the fifth server set.
In some embodiments, the deployment context hierarchy comprises, in order from high to low, a data center, a logical partition, a fleet, a rack, and a server.
In some embodiments, the determining module 103 is specifically configured to determine, when a > c, that a server with the smallest bj in the fifth server set is a third server set; when a < c, determining the server with the largest bj in the fifth server set as a third server set; when a is equal to c, determining the server with the minimum difference between bj and a in the fifth server set as a third server set; wherein a is the ratio of the total CPU and the total memory of all the servers in the fifth server set, bj is the ratio of the remaining CPU and the remaining memory of the jth server in the fifth server set, the initial value of j is 1, j takes a positive integer which is greater than or equal to 1 and less than or equal to p, p is the total number of the servers in the fifth server set, j and p are positive integers, and c is the ratio of the CPU and the memory in the specified hardware resource requirement.
In some embodiments, the information related to any one of the servers includes: the physical location of the server, hardware information, remaining available resources, the included instance manifest corresponding to each system name, and affinity attributes.
In the embodiment of the present application, the application container management apparatus may be divided into the functional modules according to the method example, for example, each functional module may be divided according to each function, or two or more functions may be integrated into one processing module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. It should be noted that the division of the modules in the embodiments of the present application is schematic, and is only one division of logic functions, and there may be another division manner in actual implementation.
The application container management apparatus in this embodiment of the present application may be configured to execute the aforementioned technical solution of the management platform in the application container management method, and the implementation principle and the technical effect of the application container management apparatus are similar, where the implementation operation of each module may further refer to the relevant description of the method embodiment, and details are not described here. The modules herein may also be replaced with components or circuits.
Illustratively, an embodiment of the present application further provides an electronic device, including: a memory and a processor; the memory is used for storing program instructions; the processor is configured to invoke the program instructions in the memory to cause the electronic device to perform the application container management method of the foregoing embodiments.
Illustratively, the embodiment of the present application further provides a computer storage medium, which includes computer instructions, when the computer instructions are run on an electronic device, the electronic device is caused to execute the application container management method in the foregoing embodiment.
Illustratively, the embodiment of the present application further provides a computer program product, which when running on a computer, causes the computer to execute the application container management method in the foregoing embodiment.
Illustratively, an embodiment of the present application provides a chip system, which includes: a processor; when the processor executes the computer instructions stored in the memory, the electronic device performs the application container management method in the previous embodiments.
In the above-described embodiments, all or part of the functions may be implemented by software, hardware, or a combination of software and hardware. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. The procedures or functions according to the embodiments of the present application are all or partially generated when the computer program instructions are loaded and executed on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a Solid State Disk (SSD)), among others.
One of ordinary skill in the art will appreciate that all or part of the processes in the methods of the above embodiments may be implemented by hardware related to instructions of a computer program, which may be stored in a computer-readable storage medium, and when executed, may include the processes of the above method embodiments. And the aforementioned storage medium includes: various media capable of storing program codes, such as ROM or RAM, magnetic or optical disks, etc.

Claims (9)

1. An application container management method, comprising:
receiving distribution demand information of an application container, wherein the distribution demand information is used for expressing the demand of the application container for deploying a target server;
acquiring relevant information of each server in a plurality of servers, wherein the plurality of servers belong to different clusters;
determining one of the plurality of servers as the target server according to a preset rule related to the distribution demand information based on the related information of each of the plurality of servers;
notifying the application container to run on the target server;
the allocation requirement information includes: a specified system name, a specified deployment scope, a specified hardware resource requirement, and a specified affinity attribute;
the determining, based on the related information of each of the plurality of servers, one of the plurality of servers as the target server according to a preset rule related to the distribution demand information includes:
determining a server meeting a mandatory distribution rule in the plurality of servers as a first server set based on the relevant information of each server in the plurality of servers; wherein the mandatory allocation rule is associated with the specified deployment scope, the specified hardware resource requirement, and the specified affinity attribute;
determining a server in the first server set, which meets a high availability rule, as a second server set; wherein the high availability rule is associated with the specified deployment scope and the specified system name;
determining one server in the second set of servers as the target server;
the determining one server of the second set of servers as the target server comprises:
when only one server exists in the second server set, determining the server as the target server;
when a plurality of servers exist in the second server set, determining the servers meeting the step scoring rule in the second server set as a third server set; wherein the step scoring rule is associated with the allocation requirement information; determining one server in the third set of servers as the target server;
the determining, as a third server set, a server in the second server set that meets the step scoring rule includes:
based on the designated deployment scope, the designated system name and the designated affinity attribute, scoring each server in the second set of servers, and determining a server with a highest score as a fifth set of servers;
determining the servers meeting preset conditions in the fifth server set as the third server set;
the determining, as the third server set, a server that meets a preset condition in the fifth server set includes: when a > c, determining the server with the minimum bj in the fifth server set as the third server set;
when a < c, determining the server with the largest bj in the fifth server set as the third server set;
when a is equal to c, determining the server with the minimum difference between bj and a in the fifth server set as the third server set;
wherein a is a ratio of the total sum of the CPUs and the total sum of the memories of all the servers in the fifth server set, bj is a ratio of the remaining CPUs and the remaining memories of the jth server in the fifth server set, an initial value of j is 1, j is a positive integer which is greater than or equal to 1 and less than or equal to p, p is the total number of the servers in the fifth server set, j and p are positive integers, and c is a ratio of the CPUs and the memories in the specified hardware resource requirement.
2. The method of claim 1, wherein determining a server of the plurality of servers that meets a mandatory allocation rule as a first set of servers comprises:
and for any one of the plurality of servers, determining that the server belongs to the first server set when the physical location of the server conforms to the specified deployment range, the hardware information of the server conforms to the specified hardware resource requirement, and the affinity attribute of the server conforms to the specified affinity attribute.
3. The method of claim 1, wherein determining the server in the first set of servers that meets the high availability rule as the second set of servers comprises:
for any server in the first server set, when s +1 is less than a preset minimum number of instances, or s +1 is more than or equal to the preset minimum number of instances and (n +1)/(s +1) is less than or equal to a preset maximum proportion, determining that the server belongs to the second server set;
wherein n is the number of instances of the system corresponding to the specified system name contained in any high-availability computing unit corresponding to any one of the servers, s is the number of instances of the system corresponding to the specified system name contained in the first server set, and n and s are natural numbers.
4. The method of claim 1, wherein scoring each server in the second set of servers based on the specified deployment scope, the specified system name, and the specified affinity attribute, and determining a server with a highest score as a fifth set of servers comprises: for any server in the second server set, when the physical location of the server belongs to the lower i level of the specified deployment range, determining that the score of the server is the current score-n, and updating i-i +1 until i-m; determining the server with the highest score in the second server set as a fourth server set; wherein n is the number of instances of the system corresponding to the specified system name contained in the server, the initial value of i is 1, m is the total number of levels below the specified deployment range, and n, i and m are natural numbers; the current initial value of the score is a preset score;
for any server in the fourth server set, when the affinity attribute of the server meets the specified affinity attribute, determining that the score of the server is the current score + 1; determining a server with the highest score in the fourth server set as the fifth server set;
the deployment context level comprises, in order from high to low, a data center, a logical partition, a fleet, a rack, and a server.
5. The method according to any one of claims 1 to 4, wherein the related information of any one server comprises: the physical location of the server, hardware information, remaining available resources, included instance manifests corresponding to various system names, and affinity attributes.
6. An application container management apparatus, comprising:
the system comprises a receiving module, a processing module and a processing module, wherein the receiving module is used for receiving distribution demand information of an application container, and the distribution demand information is used for expressing the demand of the application container on a target server for deployment;
the system comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for acquiring relevant information of each server in a plurality of servers, and the servers belong to different clusters;
a determining module, configured to determine, based on relevant information of each of the plurality of servers, one of the plurality of servers as the target server according to a preset rule related to the distribution demand information;
a notification module for notifying the application container to run on the target server;
the allocation requirement information includes: a specified system name, a specified deployment scope, a specified hardware resource requirement, and a specified affinity attribute;
the determining module is specifically configured to: determining a server meeting a mandatory distribution rule in the plurality of servers as a first server set based on the relevant information of each server in the plurality of servers; wherein the mandatory allocation rule is associated with the specified deployment scope, the specified hardware resource requirement, and the specified affinity attribute; determining a server in the first server set, which meets a high availability rule, as a second server set; wherein the high availability rule is associated with the specified deployment scope and the specified system name; determining one server in the second set of servers as the target server;
the determining module is specifically configured to: when only one server exists in the second server set, determining the server as the target server; when a plurality of servers exist in the second server set, determining the servers meeting the step scoring rule in the second server set as a third server set; wherein the step scoring rule is associated with the allocation requirement information; determining one server in the third set of servers as the target server;
the determining module is specifically configured to: based on the designated deployment scope, the designated system name and the designated affinity attribute, scoring each server in the second set of servers, and determining a server with a highest score as a fifth set of servers; determining the servers meeting preset conditions in the fifth server set as the third server set;
the determining module is specifically configured to: when a > c, determining the server with the minimum bj in the fifth server set as the third server set; when a < c, determining the server with the largest bj in the fifth server set as the third server set; when a is equal to c, determining the server with the minimum difference between bj and a in the fifth server set as the third server set; wherein a is a ratio of the total sum of the CPUs and the total sum of the memories of all the servers in the fifth server set, bj is a ratio of the remaining CPUs and the remaining memories of the jth server in the fifth server set, an initial value of j is 1, j is a positive integer which is greater than or equal to 1 and less than or equal to p, p is the total number of the servers in the fifth server set, j and p are positive integers, and c is a ratio of the CPUs and the memories in the specified hardware resource requirement.
7. An electronic device, comprising: a display screen; one or more processors; a memory; and one or more computer programs; wherein the one or more computer programs are stored in the memory; wherein the one or more processors, when executing the one or more computer programs, cause the electronic device to implement the method of any of claims 1-5.
8. A computer storage medium comprising computer instructions that, when executed on an electronic device, cause the electronic device to perform the method of any of claims 1-5.
9. A computer program product, which, when run on a computer, causes the computer to perform the method according to any one of claims 1-5.
CN202011290836.1A 2020-11-17 2020-11-17 Application container management method, device and equipment Active CN112379971B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202011290836.1A CN112379971B (en) 2020-11-17 2020-11-17 Application container management method, device and equipment
PCT/CN2021/129917 WO2022105659A1 (en) 2020-11-17 2021-11-10 Application container management method and apparatus, and device.

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011290836.1A CN112379971B (en) 2020-11-17 2020-11-17 Application container management method, device and equipment

Publications (2)

Publication Number Publication Date
CN112379971A CN112379971A (en) 2021-02-19
CN112379971B true CN112379971B (en) 2021-09-14

Family

ID=74584062

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011290836.1A Active CN112379971B (en) 2020-11-17 2020-11-17 Application container management method, device and equipment

Country Status (2)

Country Link
CN (1) CN112379971B (en)
WO (1) WO2022105659A1 (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112379971B (en) * 2020-11-17 2021-09-14 深圳前海微众银行股份有限公司 Application container management method, device and equipment
CN112995335B (en) * 2021-04-07 2022-09-23 上海道客网络科技有限公司 Position-aware container scheduling optimization system and method
CN114583838A (en) * 2022-05-05 2022-06-03 北京智芯微电子科技有限公司 Management method, terminal and system of power distribution network
CN116389324B (en) * 2023-06-07 2023-09-29 深圳市东信时代信息技术有限公司 Cloud server management method, device, equipment and storage medium
CN116680091B (en) * 2023-08-03 2023-10-03 北京交通大学 Server deployment method and device, electronic equipment and storage medium

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105871580A (en) * 2015-11-02 2016-08-17 乐视致新电子科技(天津)有限公司 Cross-cluster automation dispatching operation system and method
CN110389836A (en) * 2019-07-17 2019-10-29 腾讯科技(深圳)有限公司 A kind of more cluster management methods, device, server and storage medium
CN111045821A (en) * 2019-12-06 2020-04-21 北京浪潮数据技术有限公司 Container scheduling method and device, container scheduler and readable storage medium
CN111522639A (en) * 2020-04-16 2020-08-11 南京邮电大学 Multidimensional resource scheduling method under Kubernetes cluster architecture system
CN111831450A (en) * 2020-07-20 2020-10-27 北京百度网讯科技有限公司 Method, device, electronic equipment and storage medium for allocating server resources

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10581705B2 (en) * 2017-07-04 2020-03-03 Vmware, Inc. Smart service catalogs based deployment of applications
CN109032755B (en) * 2018-06-29 2020-12-01 优刻得科技股份有限公司 Container service hosting system and method for providing container service
CN111190696A (en) * 2019-12-28 2020-05-22 浪潮电子信息产业股份有限公司 Docker container deployment method, system, device and storage medium
CN111176697B (en) * 2020-01-02 2024-02-13 广州虎牙科技有限公司 Service instance deployment method, data processing method and cluster federation
CN112379971B (en) * 2020-11-17 2021-09-14 深圳前海微众银行股份有限公司 Application container management method, device and equipment

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105871580A (en) * 2015-11-02 2016-08-17 乐视致新电子科技(天津)有限公司 Cross-cluster automation dispatching operation system and method
CN110389836A (en) * 2019-07-17 2019-10-29 腾讯科技(深圳)有限公司 A kind of more cluster management methods, device, server and storage medium
CN111045821A (en) * 2019-12-06 2020-04-21 北京浪潮数据技术有限公司 Container scheduling method and device, container scheduler and readable storage medium
CN111522639A (en) * 2020-04-16 2020-08-11 南京邮电大学 Multidimensional resource scheduling method under Kubernetes cluster architecture system
CN111831450A (en) * 2020-07-20 2020-10-27 北京百度网讯科技有限公司 Method, device, electronic equipment and storage medium for allocating server resources

Also Published As

Publication number Publication date
WO2022105659A1 (en) 2022-05-27
CN112379971A (en) 2021-02-19

Similar Documents

Publication Publication Date Title
CN112379971B (en) Application container management method, device and equipment
US8230434B2 (en) Entitlement management system, method and program product for resource allocation among micro-partitions
CN107548549B (en) Resource balancing in a distributed computing environment
CN109565515B (en) System, apparatus, and process for dynamic tenant fabric adjustment in a distributed resource management system
US8135751B2 (en) Distributed computing system having hierarchical organization
US11520506B2 (en) Techniques for implementing fault domain sets
EP2532145B1 (en) Load and backup assignment balancing in high availability systems
CN111966500A (en) Resource scheduling method and device, electronic equipment and storage medium
US20140130057A1 (en) Scheduling jobs in a cluster
US8549533B2 (en) Ranking service units to provide and protect highly available services using N+M redundancy models
CN113886089B (en) Task processing method, device, system, equipment and medium
US20120317437A1 (en) Ranking Service Units to Provide and Protect Highly Available Services Using the Nway Redundancy Model
CN111464583B (en) Computing resource allocation method, device, server and storage medium
US7627662B2 (en) Transaction request processing system and method
CN111078369B (en) Virtual machine distribution method and device under cloud computer and server
CN113342477B (en) Container group deployment method, device, equipment and storage medium
US10102267B2 (en) Method and apparatus for access control
CN114174993A (en) Optimizing cluster applications in a cluster infrastructure
JP2017138895A (en) Virtualization environment management system and virtualization environment management method
CN112559130B (en) Container distribution method, device, electronic equipment and storage medium
CN112424765A (en) Container framework for user-defined functions
CN107992351B (en) Hardware resource allocation method and device and electronic equipment
JPH05257908A (en) Highly reliable distributed processing system
CN115964176A (en) Cloud computing cluster scheduling method, electronic device and storage medium
CN112083892B (en) Data storage method, device, equipment and medium

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