DE102019211908A1 - Method and apparatus for distributing an application - Google Patents

Abstract

Method (20) for distributing an application (21), characterized by the following features: - Runtime requirements (22) of the application (21) are fed (23) to an application management (24), - the application management (24) provides a semantic description ( 26) is generated (25) and - the description (26) is transferred (27) to a runtime environment (28) and - according to the description (26), the application (21) is optionally within the runtime environment (28) based on its runtime requirements (22) Distributed on cloud computing platforms (10), data centers (11, 12, 13), servers (14) or terminals.

Description

The present invention relates to a method for distributing an application. The present invention also relates to a corresponding device, a corresponding computer program and a corresponding storage medium.

In the field of IT management, a wide variety of processes for installing software applications on computers and in data centers are commonly summarized under the term software deployment.

Edge computing refers to - based on the well-known cloud computing - the decentralized data processing at the topological edge of a computer network. For this purpose, data streams are partially saved on the spot - e. B. directly on the end device or within a factory - but partially processed in the cloud.

WO 2018/206502 A1 describes a method for allocating digital resources of a local, modular computer network, the modules of which are each assigned a resource value for a resource, as a function of an input data record which has a resource request with a requirement value. To this end, the input data set is first read in, then the resource value from each computing module, which represents the availability of the respective module. The requirement value is then compared with the retrieved resource values. Depending on the result, the resources are allocated to the request.

US 9,336,060 B2 describes a framework for middleware services that is based on a similar approach.

CN 107357241 A discloses a relevant solution from the industrial loT environment.

CN 109144659 A discusses techniques for the live migration of edge computing functions based on their requirements and utilization of the nodes.

State of the art

Disclosure of the invention

The invention provides a method for distributing an application, a corresponding device, a corresponding computer program and a corresponding machine-readable storage medium according to the independent claims.

The proposed solution is based on the knowledge that in modern corporate infrastructure, the workload cannot be distributed across the entire organization. The generic corporate infrastructure does not currently have a fully networked architecture insofar as it does not support a distributed service layer and associated administrative functions for your organization. In addition, the application functions are currently generally not executed in virtualized environments such as containers and virtual machines or as independent function modules. In addition, the requirements of the application functions as well as the conditions of the topology and the respective resources of the infrastructure are usually not machine-readable system-wide, which currently makes automatic placement or dynamic automated relocation of functions impossible.

Against this background, a basic idea of the approach according to the invention is to carry out an automatic and dynamic assignment or reassignment of application functions to the most favorable position for their execution within an infrastructure depending on the requirements of the respective function.

The infrastructure here consists of a number of topologically distributed nodes. These nodes are linked to resources such as data processing units, memories, and so on. They are also connected directly or indirectly to one another and directly or indirectly to end devices.

When the system is started, at least one central node in the topology is identified and equipped with a service layer (platform as a service, PaaS; function as a service, FaaS). Starting from this central nodes, the remaining nodes of the topology are also equipped with a corresponding layer, so that a layer is created that is distributed over the entire topology. If a terminal is suitable for this, it can also be equipped with a corresponding layer.

A logic matches the requirements of the application function with the available resources. This logic is available within the infrastructure within the framework of the central or local edge management function of the central or local PaaS or FaaS layers.

In addition, another logic of the system monitors the current resource availability in order to support the fulfillment of the requirements for the application function as well as the dynamic and automated assignment and reassignment of application functions. This logic should also be available in every PaaS or FaaS layer of the topology.

As already mentioned, these application functions can also be assigned depending on the performance of the end devices. If an end device is equipped with a PaaS or FaaS layer, it can also trigger the reassignment of application functions to another node. If the end device itself does not have a PaaS or FaaS layer, the reallocation is carried out by another PaaS or FaaS node within the infrastructure.

One advantage of this solution is that it is based on a generic system model compared to some of the solutions mentioned above. In particular, the methods outlined are not limited to mobile communication systems. Furthermore, general end devices and not necessarily mobile devices or sensor devices are supported as end devices. These terminals provide various types of data and are not limited to sensor data.

The concept takes into account general infrastructure units and resources such as virtualized or non-virtualized computing power, storage, connection and communication resources and application functions that are used in the management of the resources mentioned.

A publish-subscribe process and a configurable message can be used to coordinate the distribution of information about resources such as computing power, storage, connectivity, etc. A similar method can be applied to the requirements of the application function. Semantic methods should also be used to describe the resources available in the computer network and their relationships as well as the requirements of the application functions.

The measures listed in the dependent claims enable advantageous developments and improvements of the basic idea specified in the independent claim. Thus, a company infrastructure according to the invention consists, for example, of a global data center, several regional data centers and, at the regional level, further local data centers that offer infrastructure services for remote locations. Other resources can e.g. B. from public clouds such as Microsoft Azure or Amazon Web Services (AWS). Within or in the vicinity of the local data center, for example, additional network nodes such as servers could be available in the factory environment in order to fulfill application functions.

According to a further aspect, it can be provided that the application management is distributed over the runtime environment. The data centers, servers and public cloud resources are equipped with the distributed PaaS or FaaS layer, hereinafter also referred to as Edge Runtime (ERT). An ERT includes so-called edge services, locally required management and other PaaS and FaaS-typical functions

Figure list

• 1 eine erfindungsgemäße Infrastruktur.
• 2 das Flussdiagramm eines erfindungsgemäßen Verfahrens.
• 3 beispielhaft die Anwendungsfunktionen maschinelles Lernen, Fernüberwachung und Qualitätsvorhersagen.

Exemplary embodiments of the invention are shown in the drawings and explained in more detail in the description below. It shows:

• 1 an infrastructure according to the invention.
• 2 the flow chart of a method according to the invention.
• 3 for example the application functions machine learning, remote monitoring and quality predictions.

Embodiments of the invention

An application management according to the invention should be able to operate completely centrally or in a hybrid manner as in 1 to work: as a partly central, partly decentralized application management ( 24 ). In the following, the last-mentioned hybrid solution is explained using the 2 described in more detail. In this case, the topology of the infrastructure is assigned to the decentralized ERTs ( 28 ) and updated regularly.

Applications have different functions. The requirements for these application functions are described semantically in terms of application programming interface (API), priority, latency, bandwidth, computing power, resource costs, performance, etc. These semantic descriptions are used as input to the central application administration ( 24 ) fed ( 23 ). The latter generates ( 25th ) in turn a configuration description (edge compute as code), which is sent to each local ERT ( 28 ) or with the ERT ( 28 ) the infrastructure nodes that the application ( 21st ) or assigned to certain application functions. The distribution of the edge compute as code can also be topologically limited in large infrastructures. A change in the requirements for the application function leads to a change in the semantic description ( 26th ), which in turn leads to a change in the edge compute as code description of the ERTs ( 28 ) leads.

In addition, the application management ( 24 ) of the ERTs ( 28 ) semantic descriptions of the resources, regarding the current memory status, computing power, bandwidth, latency, resource costs, etc.

The updating of topology, resource and application information can be restricted - for example to a certain geographical area - in order to avoid excessive updates and to reduce the communication effort. A self-learning logic can be provided for this purpose, for example. A publish-subscribe mechanism can also be used to transfer the updates to ERTs ( 28 ) who have previously expressed their interest with a subscribe message with a specific configuration. The available resource relationships should always be known, especially under high loads. Infrastructure facilities that have not been used for assignment or reallocation during a specified period of time can be excluded from regular and timely updates. The topology information should then be updated at longer intervals when the network load is low.

The central application management ( 24 ) evaluates the configuration file and distributes the application functions based on their runtime requirements ( 22nd ), the topology and the properties of the infrastructure nodes.

3 shows an example of the central application functions of machine learning (machine learning, ML, 31), remote monitoring (RM, 32) and quality predictions (quality prediction, QP, 33).

The ERTs ( 28 ) of the regional data center ( 12 ) and the local data centers ( 13 ), either the respective application ( 21st ) or from the application management ( 24 ) of the global data center ( 11 ) have been selected, the semantic description ( 26th ) of the application functions. The ERTs ( 28 ) also have the latest topology information and resource capabilities. Based on this topological information, current resource capabilities and the coded description ( 26th ) selects the global data center ( 11 ) a local data center ( 13 ) to fulfill the application functions. The placement by the global data center takes place as part of the initial placement or in connection with a cyclically recurring optimization process.

By changing the code, topology or resource situation, the ERT ( 28 ) of the local data center concerned ( 13 ) the reassignment of the application functions. The ERT ( 28 ) then assigns ML ( 31 ), RM ( 32 ) and QP ( 33 ) depending on the configuration, topology and resource situation of the global data center ( 11 ), the local data centers ( 13 ) and the server ( 14th ) again on site.

A number n of infrastructure nodes InfNode _i defines the topology of the infrastructure. The central and local ERTs ( 28 ) create and maintain resource lists on the basis of the current resource ratios of all nodes InfNode _{i of} the topology. Furthermore every ERT knows ( 28 ) of an infrared node _i die Application function requirements, e.g. B. the latency requirement latency requirement _{k of} the application function k, from the relevant function lists.

The following table uses an example to illustrate the current latency values and the costs of resources between the node and the end device: node latency Resource costs S. Infr node ₂₂ 100 100 250 Infr node ₉ 110 80 245

In this example, if latency is set as the critical requirement, InfrNode _{22 is} selected because latency _{22 represents} the lowest latency between the requesting terminal and InfrNode ₂₂ . Conversely, if the cost is defined as the critical requirement, then InfrNode _{9 is} selected. A combination of several criteria, if necessary with a weighting that reflects the ranking of the requirements, can be used as a basis for decision-making. For example, based on the calculations 1.5 * 100 + 1 * 100 = 250 and 1.5 * 110 + 1 * 80 = 245, the decision could be made that InfrNode _{9 is} selected.

An initial placement is carried out by the central application administration ( 24 ). If the relationship between latency requirement _k ≥ latency _{i '} applies, the application management selects ( 24 ) if only the latency InfrNode _{i 'is} considered as the node with the lowest latency in the resource list.

In this example, a replacement is structured as follows: Ideally, the replacement process is carried out by the local ERT ( 28 ) triggered by infrared node _{i '} . Alternatively, the replacement process can also be carried out by the central application administration ( 24 ). A hysteresis is recommended in order to delay the replacement and to avoid an otherwise threatening ping-pong effect.

As soon as the connection latency requirement _k + h ≤ latency _{i 'is} met, the current resource list is checked. Since this is updated frequently, the application management chooses ( 24 ) select another node InfrNode _{i ''} as a replacement.

A relocation of other applications is ideally also supported by the local ERT ( 28 ) triggered by infrared node _{i '} . Alternatively, the relocation can also be carried out by the central application management ( 24 ), especially in the context of cyclical optimization processes.

The following table takes into account the functions function ₃ and function _{7 of} the node InfrNode ₂₂ . The other function, function _8, has to be moved to the same node because of stringent latency requirements. Application function Computing power Latency requirement Function ₃ 100 100 Function ₇ 120 500 Function ₈ 100 50

However, current measurements indicate a decrease in the computing power available on node InfrNode ₂₂ when function _{8 is assigned} to node InfrNode ₂₂ ; In this case the required computing power is 320 and thus exceeds the available computing power of 20: node Computing power Terminal latency for function ₃ Terminal latency for function ₇ Infr node ₂₂ 300 90 150 Infr node ₉ 300 200 260

If - as in this case - the sum of the computing power requirements exceeds the available computing power by at least one hysteresis value h, the current resource list is checked. Since no alternative node InfrNode _i can be identified that could meet the latency requirements of function ₈ , the relocation of another function is initiated.

In the present example, node InfrNode _{9 is} selected for function ₇ because this function has lower latency requirements.

QUOTES INCLUDED IN THE DESCRIPTION

This list of the documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent literature cited

• WO 2018/206502 A1 [0004]
• US 9336060 B2 [0005]
• CN 107357241 A [0006]
• CN 109144659 A [0007]

Claims (10)

Method (20) for distributing an application (21), characterized by the following features: - Runtime requirements (22) of the application (21) are fed (23) to an application management (24), - the application management (24) provides a semantic description ( 26) is generated (25) and - the description (26) is transferred (27) to a runtime environment (28) and - according to the description (26), the application (21) is optionally within the runtime environment (28) based on its runtime requirements (22) Distributed on cloud computing platforms (10), data centers (11, 12, 13), servers (14) or end devices. Method (20) according to Claim 1 , characterized in that the application (21) fulfills at least one of the following functions: - machine learning (31), - remote monitoring (32) or - quality predictions (33). Method (20) according to Claim 1 or 2 , characterized in that the computing centers (11, 12, 13) comprise at least one of the following: - a global computing center (11), - a regional computing center (11) or - a local computing center (11). Method (20) according to one of the Claims 1 to 3 , characterized in that the runtime requirements (22) relate to at least one of the following services: - a developer and deployment programming interface - an operator interface - a network application programming interface or - a container virtualization programming interface. Method (20) according to one of the Claims 1 to 4th , characterized in that the runtime requirements (22) are fed to the application management (24) as a manifest file which comprises at least one of the following: - a data load, - a delay or - a bandwidth. Method (20) according to one of the Claims 1 to 5 , characterized by the following features: - after the distribution, the application (21) and the current resource situation are continuously monitored and compared with one another and the application (21) is redistributed within the runtime environment (28) if necessary. Method (20) according to one of the Claims 1 to 6th , characterized by the following feature: the application management (24) takes place centrally and / or distributed over the runtime environment (28). Computer program which is set up, the method (20) according to one of the Claims 1 to 7th execute. Machine-readable storage medium on which the computer program is based Claim 8 is stored. Device (10, 11, 12, 13, 14) which is set up, the method (20) according to one of the Claims 1 to 7th execute.

Images