WO2017101997A1

WO2017101997A1 - Monitoring arrangement, network manager and respective methods performed thereby for enabling resource management in a data centre

Info

Publication number: WO2017101997A1
Application number: PCT/EP2015/080057
Authority: WO
Inventors: Farnaz MORADI; Catalin Meirosu; Andreas Johnsson
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-12-16
Filing date: 2015-12-16
Publication date: 2017-06-22

Abstract

A monitoring arrangement, a network manager and respective methods performed thereby for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation are provided. The method of the monitoring arrangement comprises obtaining (120) one or more graphs based on monitored traffic between a first container and one or more second containers, the traffic being generated by respective applications of the first and the one or more second containers; and obtaining (150) a community detection result comprising information about which community or communities the respective application of the first and the one or more second container belong to, based at least on the created graph(s). The method further comprises assigning (160) performance metrics of the monitored traffic to community or communities of the community detection result; and sending (170) the annotated community or communities to a network manager.

Description

MONITORING ARRANGEMENT, NETWORK MANAGER AND RESPECTIVE METHODS PERFORMED THEREBY FOR ENABLING RESOURCE MANAGEMENT IN A DATA CENTRE

Technical field

[0001 ] The present disclosure relates to communication within a communication network and in particular to monitoring and managing such a network.

Background

[0002] Virtual isation is a way of decoupling software applications from the underlying hardware. The most common way of virtualisation is to run a hypervisor either directly on the hardware or on top of a host operating system, OS. A hypervisor allows sharing of hardware resources among many virtual machines, allowing many virtual machines, VMs, to run on the same hardware. Each VM is isolated from the other VMs and runs a full OS. Different VMs on the same hardware may run different OSs.

[0003] In contrast to VMs, containers are "light weight" and have much lower overhead. In container-based virtualisation, also known as Operating System level virtualisation, rather than running a full OS, containers share the same kernel. In Linux containers, the kernel-level namespaces are used for resource isolation and Control groups (cgroups) are used for managing and limiting resources. Cgroups also exposes resource usage metrics such as memory, CPU, and block I/O which can be used for monitoring.

[0004] Container-based virtualisation provides better resource utilisation compared to VMs since idle containers do not use any resources. Moreover, containers are created and destroyed much faster compared to VMs since there is no need to boot and shutdown a full OS. Examples of container-based virtualisation technologies in Linux are OpenVZ, Linux VServer, LXC, and Docker. More recent container virtualisation projects include LXD and Rocket.

[0005] Communication between containers can take place using different methods. As an example, Docker by default creates a virtual Ethernet bridge inside the kernel on the host machine. The traffic on this bridge is forwarded to every interface that is connected to it. When a new container is created, a pair of peer interfaces is created. One of the peers becomes the interface for the container and the other one can be bound to the default Docker Bridge or any other virtual bridge on the host machine. Containers may be connected to the network via a virtual switch.

[0006] An orchestrator can make VM placement decisions to fulfil different high-level goals such as reducing energy consumption, network overhead, latency, etc. Generally, when attempting to e.g. make VM placement decisions, a traffic matrix is created comprising information about the different VMs.

[0007] However, the traffic matrix comprises information which is obtained based on sampling, therefore the matrix needs a certain amount of time to be built and short-lived flows might not be accounted for until the matrix is stable. Therefore, the network manager needs to take decisions based on incomplete information for rather significant amounts of time, depending on the sampling frequency.

[0008] If a VM is migrated and the IP address is changed at the new location, it would appear twice in the traffic matrix because the sFlow or IPFIX collector has no information about IP address allocation. If the old IP address is re-used by another VM (making it not possible to automatically age out the IP address from the matrix, for example), the traffic matrix would contain obsolete information that is difficult to detect, and simple community-detection algorithms executed by the network manager may reach wrong conclusions which in turn would translate onto suboptimal placement decisions.

[0009] While annotations such as bandwidth consumed by a pair of IP addresses are standard for traffic matrices, including other network metrics such as delay, jitter, packet loss require integration of additional tools which increases the complexity and thus the cost of management. Taking into account metrics related to the server utilisation requires an additional integration step between different management systems, which further increases the complexity. [00010] Although cloud and service orchestration engines might know the network connectivity that needs to be provisioned (for example, tunnels or multipoint-to-multipoint connectivity) between resources where sets of Virtual Network Functions, VNFs, are to be executed, the actual traffic pattern experienced in operation is extremely difficult to predict. In many cases, the traffic depends on internal states of particular VNFs (such as the algorithm of a load balancer that might, for certain purposes, attempt to load more some of the web server instances behind it) or on flash crowd effects that suddenly require access of a particular piece of information from a large distributed database. As such, traffic matrices need to be able to quickly account for changes in the infrastructure and in the user-generated traffic.

Summary

[0001 1 ] The object is to obviate at least some of the problems outlined above. In particular, it is an object to provide a monitoring arrangement, a network manager and respective methods performed thereby for enabling resource management in a data centre comprising compute and network resources implementing container- based virtualisation. These objects and others may be obtained by providing a monitoring arrangement and a network manager as well as a method performed by a monitoring arrangement and a network manager according to the

independent claims attached below.

[00012] According to an aspect, a method performed by a monitoring

arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation is provided. The method comprises obtaining one or more graphs based on monitored traffic between a first container and one or more second containers, the traffic being generated by respective applications of the first and the one or more second containers; and obtaining a community detection result comprising information about which community or communities the respective application of the first and the one or more second container belong to based at least on the created graph(s). The method further comprises assigning performance metrics of the monitored traffic to community or communities of the community detection result; and sending the annotated community or communities to a network manager.

[00013] According to an aspect, a method performed by a network manager for managing a communication network implementing container-based virtualisation is provided. The method comprises comprising receiving annotated community or communities from a monitoring arrangement; and performing a managing action with regard to a first container and one or more second containers based on the received annotated community or communities.

[00014] According to an aspect, a monitoring arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation is provided. The monitoring

arrangement is configured for obtaining one or more graphs based on monitored traffic between a first container and one or more second containers, the traffic being generated by respective applications of the first and the one or more second containers; and for obtaining a community detection result comprising information about which community or communities the respective application of the first and the one or more second container belong to, based at least on the created graph(s). The monitoring arrangement further is configured for assigning performance metrics of the monitored traffic to community or communities of the community detection result; and for sending the annotated community or communities to a network manager.

[00015] According to an aspect, a network manager for managing a

communication network implementing container-based virtualisation is provided. The network manager is configured for receiving annotated community or communities from a monitoring arrangement; and for performing a managing action with regard to a first container and one or more second containers based on the received annotated community or communities.

[00016] The monitoring arrangement, the network manager, the method performed by the monitoring arrangement and the method performed by the network manager may have several advantages. One possible advantage is that the solution scales well and may also be used in cloud environments consisting of multiple data centres. A precise traffic matrix of the data centre, i.e. the annotated community or communities, may be made available in a timely manner for the network manager, reducing the time when allocation of resources is suboptimal. Further, IP (Internet Protocol) address changes may be detected locally (for example, by inspecting TCP open and close connection packets, or by rapidly aging out an IP address that saw no traffic addressed to it in a short time interval) and therefore the traffic matrix/matrices and/or the annotated community or communities may better reflect the actual situation in the data centre. This may also reduce the need for integration of the orchestrator or network management system with third-party IP address management tools, thus providing both OPEX (Operational Expenditure) and potentially CAPEX (Capital Expenditure) savings. Still a further possible advantage is that the traffic matrix may be annotated easily with compute resource consumption metrics collected locally, thus removing the need for the network manager to access this data separately and further reducing the integration costs.

Brief description of drawings

[00017] Embodiments will now be described in more detail in relation to the accompanying drawings, in which:

[00018] Figure 1 a is a flowchart of a method performed by a monitoring arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation, according to an exemplifying embodiment.

[00019] Figure 1 b is a flowchart of a method performed by a monitoring arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation, according to yet an exemplifying embodiment.

[00020] Figure 1 c is a flowchart of a method performed by a monitoring arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation, according to still an exemplifying embodiment.

[00021 ] Figure 1 d is a flowchart of a method performed by a monitoring arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation, according to another exemplifying embodiment.

[00022] Figure 1 e is a flowchart of a method performed by a monitoring arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation, according to a further exemplifying embodiment.

[00023] Figure 1f is a flowchart of a method performed by a monitoring

arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation, according to yet an exemplifying embodiment.

[00024] Figure 2a is a flowchart of a method performed by a network manager for managing a communication network implementing container-based virtualisation, according to an exemplifying embodiment.

[00025] Figure 2b is a flowchart of a method performed by a network manager for managing a communication network implementing container-based virtualisation, according to yet an exemplifying embodiment.

[00026] Figure 2c is a flowchart of a method performed by a network manager for managing a communication network implementing container-based virtualisation, according to still an exemplifying embodiment.

[00027] Figure 3a is an illustration of an architecture for container virtualisation with monitoring functionality.

[00028] Figure 3b is a flowchart of a method performed by local monitoring functions and/or arrangements according to an example. [00029] Figure 3c is a signalling diagram between containers and monitoring arrangements according to an example.

[00030] Figures 3d-3f are an illustration of a community detection algorithm.

[00031 ] Figure 4 is a block diagram of a monitoring arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation, according to an

exemplifying embodiment.

[00032] Figure 5 is a block diagram of a monitoring arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation, according to another exemplifying embodiment.

[00033] Figure 6 is a block diagram of network manager for managing a communication network implementing container-based virtualisation, according to an exemplifying embodiment.

[00034] Figure 7 is a block diagram of network manager for managing a communication network implementing container-based virtualisation, according to another exemplifying embodiment.

[00035] Figure 8 is a block diagram of an arrangement in a monitoring arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation, according to another exemplifying embodiment.

[00036] Figure 9 is a block diagram of an arrangement in network manager for managing a communication network implementing container-based virtualisation, according to an exemplifying embodiment.

Detailed description

[00037] Briefly described, a monitoring arrangement, a network manager and respective methods performed thereby are provided. In order to attempt to optimise network performance with regard to current conditions of the network, a monitoring arrangement implemented in a server node or in one or more of a plurality of containers monitors and collects information pertaining to current conditions in the network and also which applications in which containers communicate with which applications in which containers, or which containers communicate with which containers. By knowing which containers communicate to a large extent with each other, which containers rarely communicate with each other and which containers more or less never communicate with each other, the network manager is enabled to manage the network accordingly, e.g. placing containers which communicate with each other to a large extent on the same physical machine, or on machines located near each other from the perspective of the physical network topology.

[00038] Embodiments herein relate to a method performed by a monitoring arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation. Embodiments of such a method will now be described with reference to figures 1a-1f. Figure 1a illustrates the method 100 comprising obtaining 120 one or more graphs based on monitored traffic between a first container and one or more second containers, the traffic being generated by respective applications of the first and the one or more second containers; and obtaining 150 a community detection result comprising information about which community or communities the respective application of the first and the one or more second container belong to, based at least on the created graph(s). The method further comprises assigning 160 performance metrics of the monitored traffic to community or communities of the community detection result; and sending 170 the annotated community or communities to a network manager.

[00039] The graph(s), which may also be referred to as traffic matrix/matrices, generally indicates which container is communicating with which container, or which application(s) in the first container communicates with applications in the one or more second containers. Any container may comprise one or more applications, but for simplicity reasons, hereinafter a container is described or referred to as comprising just one application, or a process of a multi-tier application. Further, in this disclosure, a container may be described as

communicating with another container meaning that the application within a container communicates with the application of another container. Still further, each container may be associated with its own graph such that a graph of the first container illustrates, or comprises information pertaining to, which one of the one or more second containers the first container communicates with. Further, all graphs may be combined into one or more graphs representing all or a group or cluster of containers. Thus, obtaining one or more graphs comprises obtaining one graph per container, one or more graphs representing all or a group of containers. An example of an application is a Virtual Network Function, VNF. There is a vast amount of different examples of different VNFs, Some non-limiting examples are a Deep Packet Inspection, DPI, function, Firewall, load balancer, virtual EPC etc.

[00040] Once the monitoring arrangement has obtained the one or more graphs, the monitoring arrangement may obtain the community detection result comprising information about which community or communities the respective application of the first and the one or more second container belong to, based at least on the created graph(s). As described above, a community may also be referred to as a group. Thus in other words, the monitoring arrangement may obtain a grouping of the first and the one or more second containers, wherein each group may comprise containers which mainly communicate within themselves. In other words, the containers in a group communicate to a larger extent with other containers in the group than with containers outside the group.

[00041 ] As will be described in more detail below, the monitoring arrangement may be implemented in different nodes or entities, wherein the obtaining of the graph(s) and/or the community detection result depends on in different nodes or entities the monitoring arrangement is implemented. Merely as an example, the obtaining of any of the above may be receiving it/them from another node or entity; or derived, calculated, determined by the node or entity in which the monitoring arrangement is implemented.

[00042] The monitoring arrangement may then further assign performance metrics of the monitored traffic to community or communities of the community detection result. Different examples of performance metrics are given below. The performance metrics adds further information to the community detection result as to e.g. how well, or how bad, a communication between two containers is executed. The connection may be heavily loaded resulting in e.g. delay, errors, failure etc. In other words, the performance metrics may be assigned to the edges of the graph to reflect e.g. delay between two containers. In this manner, the overall situation of the data centre may be illustrated, the situation being

representative of e.g. which containers communicates to a larger or smaller extent with other containers and how well/bad each "path" or "connection" between different containers are performing.

[00043] This information may then be sent to the network manager, i.e. the annotated community or communities are sent to the network manager. As will also be described in more detail below, this will enable the network manager to take different actions in order to manage the data centre.

[00044] The communication network may be a so-called Cloud communication network and in such cases, the network manager may also be referred to as a cloud manager. The network manager in this disclosure handles not only network resources, but also both compute and network (and other types, such as storage) resources. It shall further be pointed out that in this disclosure, the expression "container" as used herein is understood to denote either a "container" or a "virtual machine".

[00045] The method performed by the monitoring arrangement may have several advantages. One possible advantage is that the solution scales well and may also be used in cloud environments consisting of multiple data centres. A precise traffic matrix of the data centre, i.e. the annotated community or communities, may be made available in a timely manner for the network manager, reducing the time when allocation of resources is suboptimal. Further, IP (Internet Protocol) address changes may be detected locally (for example, by inspecting TCP open and close connection packets, or by rapidly aging out an IP address that saw no traffic addressed to it in a short time interval) and therefore the traffic matrix/matrices and/or the annotated community or communities may better reflect the actual situation in the data centre. This may also reduce the need for integration of the orchestrator or network management system with third-party IP address management tools, thus providing both OPEX and potentially CAPEX savings. Still a further possible advantage is that the traffic matrix may be annotated easily with compute resource consumption metrics collected locally, thus removing the need for the network manager to access this data separately and further reducing the integration costs.

[00046] The performance metrics may relate to one or more off latency, packet loss, jitter, level of reordering and current network capacity usage.

[00047] These are some examples of performance metrics that may be used. Different circumstances may give ride to different kinds of characteristics affecting communication between the first container and the one or more second

containers. In case a lot of traffic is to be sent between first container and the one or more second containers, this may give rise to congestion, which in turn may give rise to delay. Jitter may be defined or explained as a variation in data flow, which may be due to congestion somewhere in the path between the first container and the one or more second containers. See also e.g. International Telecommunication Union, ITU, recommendation Y.1540.

[00048] Due to different reasons, packets may be lost or dropped/discarded. Reasons for that may be congestion, overload, some sort of malfunction etc.

"Reordering" means reordering of packets associated with an application that may happen on the network controlled by the data centre while packets are being send from first container to the one or more second container and vice versa.

[00049] The network, which is controlled by the data centre, generally has a specific capacity. The network may hereinafter also be referred to as the data centre network. When in use, e.g. when containers transmit packets between each other, an amount, or level, of this capacity is used, which is also referred to as the current network capacity usage. The remaining capacity is generally referred to as the available path capacity. Thus, both the current network capacity usage and the available network capacity may be used as measurements of how heavily loaded the network is. The more loaded the network is, the larger the probability for delay, jitter, loss, etc. is.

[00050] In an embodiment, the monitoring arrangement is implemented in a server node.

[00051 ] As will be described in more detail below and briefly mentioned above, there are different options for where, or in which node or entity, the monitoring arrangement may be implemented. In this embodiment, which is also referred to a centralised version or example, the monitoring arrangement is implemented in the server node. This means that the monitoring arrangement may gather information such as e.g. obtaining the graph(s) from local containers and may then compile and process the information in order to obtain the community detection result, to assign performance metrics of the monitored traffic to community or communities of the community detection result, and to send this information to the network manager.

[00052] In another embodiment, the monitoring arrangement is implemented in at least one of the one or more second containers.

[00053] This is also referred to a decentralised version or example. As will be described in more detail, the monitoring arrangement may in this version or example monitor the traffic between the different containers, determine the one or more graphs based on monitored traffic between a first container and one or more second containers, and/or determining community detection result by performing a community detection algorithm, also known as a graph clustering algorithm, and/or assign performance metrics of the monitored traffic to community or communities of the community detection result; and send the annotated community or communities to the network manager.

[00054] Different embodiments relating to the monitoring arrangement being implemented in the server node will now be described.

[00055] For the embodiment when the monitoring arrangement is

implemented in the server node, the obtaining 120 of the graph(s) comprises receiving respective graphs from respective monitoring functions of respective containers.

[00056] This embodiment may also be referred to as the centralised

embodiment/version/example. The monitoring arrangement may thus receive respective graphs from respective monitoring functions of respective containers.

[00057] When the monitoring arrangement is implemented in the server node, one or more of the containers, i.e. the first and the one or more second containers, may still comprise a monitoring function that may monitor traffic being sent between containers and may determine the respective graphs based on the monitored traffic. The monitoring function in the one or more of the containers may then send this result to the monitoring arrangement in the server node. In this manner, the monitoring arrangement obtains the respective graphs.

[00058] In an example, the obtaining 150 of the community detection result comprises executing a community detection algorithm based on the received graphs; or receiving local community detection result from respective monitoring functions in the first container and/or in the one or more second containers and merging (155) the received local communities to obtain a global community detection result.

[00059] By executing the community detection algorithm, the monitoring arrangement obtains the community detection result. There are several possible community detection algorithms that may be used for this purpose. The community detection result provides the monitoring arrangement with information about which containers communicate mostly to which other containers, and which containers communicates rarely with which other containers.

[00060] However, the community detection algorithm may alternatively be executed by the monitoring function(s) in the first container and/or in the one or more second containers. If so, the monitoring arrangement may receive a plurality of community detection results and if so, the monitoring arrangement may merge these community detection results to one global community detection result representing the network being controlled by the data centre.

[00061 ] The community detection algorithm may be a modularity optimisation algorithm, e.g. the Louvain method; or a seed expansion algorithm.

[00062] There are different examples of community detection algorithms. Different algorithms may be more or less suitable depending on whether the monitoring arrangement is implemented in the server node or in the decentralised embodiment/version/example.

[00063] It shall be pointed out that these algorithms are merely examples of suitable algorithms to use. There are many other algorithms that may be suitable, being overlapping or non-overlapping.

[00064] The method may further comprise, as illustrated in figure 1 b,

receiving 1 10 monitoring data from a respective monitoring function of the first and the one or more second containers.

[00065] When the monitoring arrangement is implemented in the server node, the monitoring arrangement need to obtain monitoring data/information from the respective monitoring function of the first and the one or more second containers in the case that the monitoring function is to create the graph(s) illustrating which one of the one or more second containers the first container communicates with, or more generally which containers communicate with which containers.

[00066] It shall be pointed out that in case the monitoring functions in individual containers create the graphs and send the graphs to the monitoring arrangement, there may be no need for the monitoring arrangement in the server node to receive the monitoring data/information based on which the received graphs were created locally by the the monitoring functions in individual containers. However, the monitoring data/information may still be necessary in order for the monitoring arrangement to assign performance metrics of the monitored traffic to community or communities of the community detection result unless the monitoring arrangement obtains the necessary information on order to do so in another way.

[00067] For the embodiment when the monitoring arrangement is

implemented in the at least one of the one or more second containers, the obtaining 120 of the graph may comprise creating the graph based on monitored traffic between the first container and the one or more second containers.

[00068] In the case the monitoring arrangement is implemented in the at least one of the one or more second containers, the monitoring arrangement may also comprise the above described monitoring function. This means that individual monitoring arrangements in containers may monitor traffic to and/or from containers and based on this information create the graph(s). It shall be pointed out that not all containers need to comprise a monitoring arrangement. Merely as an example, assume there are only two containers, the first container and the second container. If so, only one of the containers needs to comprise or have a monitoring arrangement.

[00069] Thus assume for example that there are a plurality of containers and assume further that one second container comprises the monitoring arrangement. Then that monitoring arrangement may obtain information pertaining to all traffic sent from and received by that second container. The monitoring arrangement may further create a graph for that second container comprising information about all the other containers with which that second container communicates with.

[00070] The method may further comprise, as illustrated in figure 1c,

exchanging 140 the created graph with a monitoring arrangement of other container(s).

[00071 ] By exchanging the created graph with other container(s) also having monitored and created a respective graph representative for its/their container, the respective monitoring arrangements in the different containers also comprising the monitoring arrangement, the respective monitoring arrangements may cooperate in order to create a graph representative for the whole or parts of the network controlled by the data centre.

[00072] Thus, some containers comprising the monitoring arrangement may also be referred to as monitoring containers and containers not comprising the monitoring arrangement but at least one application, such as e.g. a Virtual

Network Function, VNF, may be referred to as an application container or a VNF container. With this terminology, monitoring containers may exchange created local graphs with each other in order to create a global graph representative of the whole network controlled by the data centre, or in order to create fewer graphs representative of parts of the whole network controlled by the data centre.

[00073] The obtaining 150 of the community detection result may comprise executing a community detection algorithm based on the graph; or receiving the community detection result from respective monitoring functions of the one or more second containers, or receiving the community detection result from a server node.

[00074] In order to obtain the community detection result, a community detection algorithm should be executed by one or more entities, nodes and/or monitoring functions or arrangements. Either, the monitoring arrangement in question may perform the community detection algorithm based on the graph, or the respective monitoring functions of the one or more second containers

(monitoring containers) may perform the community detection algorithm and send it to the monitoring arrangement in question.

[00075] Thus, each monitoring arrangement in the monitoring containers may perform a local community detection algorithm and then exchange the result with each other among the monitoring containers. In this manner, all monitoring arrangement may obtain a global graph or a graph representing parts of the global graph of the network controlled by the data centre.

[00076] In still an example, the monitoring containers may all send their individual graph to a server node, which will perform a global community detection algorithm based on all the received graphs and then send the result back to the monitoring arrangement.

[00077] In an example, wherein when the obtaining 150 of the community detection result comprises receiving the community detection result from a server node, the method further comprises finding local communities, sending the found local communities to the serving node, wherein the received community detection result from the server node comprises a merging of local communities to a global community detection result.

[00078] The monitoring containers find communities in the distributed way and these communities may be referred to as "local communities". Then these local communities are sent to a centralised node or the network manager, where the local communities are combined or merged to find larger "global communities".

[00079] Merely as an illustrative example, if one local graph says that A is connected to B, and a second local graph states that B is connected to C, then the global graph is A->B->C.

[00080] The method may further comprise, as illustrated in figure 1d,

monitoring 105 traffic between the first container and the one or more second containers.

[00081 ] The monitoring arrangement may, as described above, monitor traffic between containers. Thus, the monitoring arrangement, e.g. being implemented in the first container may monitor all traffic being transmitted and/or received from the first container.

[00082] The method may further comprise, as illustrated in figure 1e,

receiving 101 a request for annotated community or communities with respect to the network performance metrics that requires to be monitored from a server node.

[00083] The method performed by the monitoring arrangement may be performed regularly, at random points in time or upon request. Consequently, in one example, the method comprises receiving, from the server nod, the request for annotated community or communities with respect to the network performance metrics that requires to be monitored.

[00084] The server node, when the monitoring arrangement is implemented in monitoring containers, may be in control of e.g. when monitoring is needed in order for a network manager to either perform an update on the network or to ascertain that no update is needed. Thus the monitoring arrangement may not need to be constantly monitoring traffic and created graphs etc., but only upon request or at regular or irregular time intervals.

[00085] Irrespective of whether the monitoring arrangement is implemented in the server node or in the at least one of the one or more second containers, the method may further comprise, as illustrated in figure 1f, receiving 102 a request for annotated community or communities with respect to the network performance metrics that requires to be monitored from an Operation, Administration and Maintenance, OAM, node.

[00086] The OAM node is generally responsible for ascertaining that the network/cloud/data centre is performing optimally given the current circumstances. Typically, circumstances change over time and then the network may need to adopt to the changing circumstances.

[00087] Thus, the OAM node may request an annotated community or communities with respect to the network performance metrics that requires to be monitored in order to optimise network performance.

[00088] Embodiments herein also relate to a method performed by a network manager for managing a communication network implementing container-based virtualisation. Embodiments of such a method will now be described with reference to figures 2a-2c. Figure 2a illustrates the method 200 comprising receiving 220 annotated community or communities from a monitoring arrangement; and performing 230 a managing action with regard to a first container and one or more second containers based on the received annotated community or communities. [00089] The annotated community or communities comprise the community or communities having performance metrics of the monitored traffic assigned to edges of the graph representing the current traffic situation of the network controlled by the data centre as described above.

[00090] Using this information, the network manager is enabled to ascertain if the network is operating optimally or at least satisfactorily with regards to the current conditions of the network. If this is not the case, the network manager may perform one or more managing actions with regard to the containers comprised in the received annotated community or communities.

[00091 ] The method performed by the network manager has the same possible advantages as the method performed by the monitoring arrangement as they interact with each other. One possible advantage is that the solution scales well and may also be used in cloud environments consisting of multiple data centres. A precise traffic matrix of the data centre, i.e. the annotated community or communities, may be made available in a timely manner for the network manager, reducing the time when allocation of resources is suboptimal. Further, IP (Internet Protocol) address changes may be detected locally (for example, by inspecting TCP open and close connection packets, or by rapidly aging out an IP address that saw no traffic addressed to it in a short time interval) and therefore the traffic matrix/matrices and/or the annotated community or communities may better reflect the actual situation in the data centre. This may also reduce the need for integration of the orchestrator or network management system with third-party IP address management tools, thus providing both OPEX and potentially CAPEX savings. Still a further possible advantage is that the traffic matrix may be annotated easily with compute resource consumption metrics collected locally, thus removing the need for the network manager to access this data separately and further reducing the integration costs.

[00092] The method may further comprise evaluating 225 the received annotated community or communities against a performance metric, e.g.

comparing the received annotated community or communities to a predefined threshold associated with the performance metric, wherein the managing action is performed if the received annotated community or communities do/does not meet the predefined threshold.

[00093] Different performance metrics may be associated with different thresholds, wherein one, a plurality or all performance metrics may need to meet their respective threshold in order for the network manager not to perform any managing actions.

[00094] Thus the network manager may e.g. compare a performance metric to a threshold for that performance metric. And if the performance metric does not meet the threshold for that performance metric, the network manager may take appropriate action(s). Examples of managing actions will be given and described in more detail below.

[00095] The method may further comprise requesting 210 the annotated community or communities with respect to the network performance metric that requires to be monitored.

[00096] In order for the network manager to receive 220 the annotated community or communities from the monitoring arrangement, the network manager may need to request the information from the monitoring arrangement.

[00097] As described above, the monitoring arrangement may provide the information at regular or irregular time intervals or upon direct request from e.g. the network manager. As also described above the monitoring arrangement may be implemented in a server node or in one or more containers.

[00098] The managing action may be at least one of migrating containers on one community to another community to reduce latency, or scaling out containers that belong to multiple communities to ensure computational capabilities.

[00099] In an example, a container that was previously comprised in a first community and also then located on a first physical machine may have changed such that it belongs to a second community which runs on a second physical machine. The network manager may then migrate that container to the second physical machine, thereby optimising communication and resource usage with regard to the second container.

[000100] In another example, a container contained in a first community may communicate to the same extent or degree with containers of a first community and with containers of a second community. Consequently, that container could be placed in either the first or the second community, wherein both alternatives result in substantial communication between the first and second community. As a solution, that container may be scaled, or duplicated such that it is places in both communities, that is increase its attainable resource consumption.

[000101 ] With the methods performed above by the monitoring arrangement and the network manager, a container management framework is enabled to execute a traffic-aware monitoring function in a monitoring container associated with an application container, e.g. a VNF container. The monitoring function may passively observe traffic generated within or destined to a application/VNF container, create and dynamically update a local graph in which nodes

(containers on a physical machine) correspond to VNF identifiers (e.g. IP address) and edges correspond to transmitted traffic between VNFs. Each monitoring function may identify its neighbouring monitoring functions using a monitor discovery method provided by a monitoring framework and may exchange its local graph with neighbouring monitoring functions. Alternatively, a monitoring function sends its local graph to a central monitoring entity. A designated monitoring function within a neighbourhood may then run a

community detection algorithm to identify the communities of nodes in the graph. The identified communities may then be sent to a network manager to be used for traffic-aware managing (or orchestration) decisions such as scaling or migrating application/VNF containers.

[000102] Figure 3a is an illustration of an architecture for container

virtualisation with monitoring functionality. The architecture may implement an automatic setup and configuring of monitoring functions to passively monitor traffic originated within or destined to an application, e.g. a VNF for, measuring network performance metrics. The monitoring framework also provides the means for discovering neighbouring monitoring functions. The monitoring framework covers the interaction between monitoring functions and network manager in order to make network-/traffic-aware decisions.

[000103] Figure 3b is a flowchart of a method performed by local monitoring functions and/or arrangements according to an example. Each monitoring function in this example (1 ) passively observes application traffic, e.g. VNF traffic, and creates a local graph/traffic matrix in addition to calculating network performance metrics; (2) exchanges its local graph with its neighbouring monitors; and (3) runs a local community detection algorithm (only one node in a neighbourhood needs to do this). Further, each monitoring function in this example (4) assigns or annotates the communities identified by the community detection algorithm with network performance metrics (which were requested by the orchestrator) and populates a data structure. The annotations can be added per edge or in an aggregated way (e.g., average or maximum delay). The aggregated annotations can be added for internal (inside community) and external (between

communities) communications; and (5) provides the data structure to the orchestrator, i.e. the network manager.

[000104] The network manager then (1 ) specifies the network performance metrics that require to be monitored for a given set of VNFs; (2) receives communities and annotations from the monitoring framework (i.e. monitoring arrangement(s)/function(s), and performs managing actions if necessary, e.g. if performance metrics associated with a community crosses or no longer meets a threshold value.

[000105] Each monitoring function or arrangement may create a local graph from the passively observed traffic, where each node is a VNF identifier (e.g. its IP address) and each edge corresponds to an observed flow between two VNFs. The generated graph may be undirected or directed and un-weighted or weighted. The weights may be assigned to edges based on the number of transmitted packets/bytes or any other network performance metric such as delay. These metrics may also be used for filtering and reducing the density of the graphs (e.g. only edges that have number of packets higher than a threshold value are kept in the graph). The graphs may incrementally be updated and edges/nodes that correspond to expired flows may be removed from the graphs.

[000106] The monitoring functions may periodically exchange their local graph information with their neighbouring monitors or send them to a centralised monitoring entity, e.g. the server node described above.

[000107] If the information is sent to neighbouring monitors, each monitoring function may update its local graph with the received information. If the

information is sent to a centralised monitoring entity, the central monitor may create a graph from the global information.

[000108] The monitoring functions (local or central) may run community detection aka a graph clustering algorithms (local or global) on the generated graph. The community detection algorithm may find non-overlapping or overlapping communities. A community is generally defined as a set of nodes which are densely connected to each other and have spare connections with the rest of the nodes in the graph. There are a vast variety of different types of community detection algorithms that may be used for this purpose. Moreover, dynamic community detection algorithms, which can adaptively update the identified communities in dynamically changing and evolving graphs, may be very useful.

[000109] The output of community detection algorithm may be a set of application/VNF IP addresses or physical server identifiers (or similar). This output may be used to create a data structure containing these IP addresses as well as container/Virtual-Machine/server identifiers which may be added by the local/central monitoring function. Moreover, obtained performance metrics from the monitoring functions may be used to annotate the data structure, for example the average latency values experienced in communications between VNFs inside the community. This data structure is then provided to the network manager, e.g. by transmitting it to the network manager. [0001 10] The network manager may use the information in the data structure to make traffic-aware decisions. The nodes (containers or Virtual Machines, VMs) that are placed in the same community by a community detection algorithm are the ones that communicate more with each other and less with the rest of the nodes, so they should be placed closer to each other in order to reduce network overhead and/or latency. Therefore, the network manager may place the nodes (containers or VMs) that belong to the same community closer to each other (traffic-aware VM placement). Moreover, if an overlapping community detection algorithm is used, the nodes that belong to more than one community may be scaled out so that one instance is placed close to the other nodes in each community. Moreover, if monitoring network performance reveals network bottlenecks, the network manager may use this information to migrate a single node or the whole community of nodes in order to address the problem.

[0001 1 1 ] The network manager may also combine the input communities with other inputs such as resource utilisation, energy consumption, high availability requirements, etc. to perform orchestration actions such as migration and scaling.

[0001 12] Community detection may be performed "globally" or centrally if every node/container sends its local neighbourhood information to a centralised monitoring entity, e.g. the above described server node, or locally if the monitoring functions/arrangements exchange graph information with each other. If a local algorithm is used, there is no need for all the monitors to run community detection algorithm. This may be done by a small subset of monitors, e.g. one monitor in each neighbourhood. Alternatively, a "seed selection" algorithm may be used for selecting the monitoring functions/arrangements which should run the community detection algorithm. Moreover, the locally identified communities may be sent to the central monitoring entity, where they may be merged.

[0001 13] Migrating the nodes/containers or VMs in order to reduce latency: The communities show the group of nodes that communicate more with each other. The communities provided to the network manager may also be annotated with network performance metrics such as latency, jitter, packet loss, etc. The network manager may use this information to make traffic-aware placement decisions. If the placement decision is performed only based on the amount of traffic exchanged between two nodes/containers and ignoring other metrics may lead to increased latency for a service associated with the application/VNF. There might be a few flows between two containers/nodes so these

containers/nodes will not be placed in the same community, and might end up in geographically distributed datacentres, but the containers/nodes may have strict latency requirements. The network manager which is aware of the service chain, i.e. a path between a set of applicationsA/NFs, may consider the annotated information together with the community information in order to make migration decisions.

[0001 14] Scaling out the nodes that belong to multiple communities:

Overlapping community detection algorithms enables identification of the containers/nodes that naturally belong to multiple communities. The network manager may try to place the overlapping communities close to each other. However, this might not be possible due to resource limitations of the servers in a datacentre. Alternatively, the network manager may scale out the

containers/nodes that belong to multiple communities and place an instance of those containers/nodes close to each of the communities to which they belong. In this case, two communities that overlap in for example one container/node do not need to be placed close to each other.

[0001 15] Embodiments herein also relate to a monitoring arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation. The monitoring

arrangement has the same technical features, objects and advantages as the method performed by the monitoring arrangement. Hence, the monitoring arrangement will only be described in brief in order to avoid unnecessary repetition.

[0001 16] Embodiments of such a monitoring arrangement will now be described with reference to figures 4 and 5. Figures 4 and 5 illustrate the monitoring arrangement 400, 500 being configured for obtaining one or more graphs based on monitored traffic between a first container and one or more second containers, the traffic being generated by respective applications of the first and the one or more second containers; and for obtaining a community detection result comprising information about which community or communities the respective application of the first and the one or more second container belong to based at least on the created graph(s). Figures 4 and 5 further illustrate the monitoring arrangement 400, 500 being configured for assigning performance metrics of the monitored traffic to community or communities of the community detection result; and sending the annotated community or communities to a network manager.

[0001 17] The monitoring arrangement may be realised on implemented in various ways. A first exemplifying realisation or implementation is illustrated in figure 4. Figure 4 illustrates the monitoring arrangement 400 comprising a processor 421 and memory 422, the memory comprising instructions, e.g. by means of a computer program 423, which when executed by the processor 421 causes the monitoring arrangement 400 to obtain one or more graphs based on monitored traffic between a first container and one or more second containers, the traffic being generated by respective applications of the first and the one or more second containers; and to obtain a community detection result comprising information about which community or communities the respective application of the first and the one or more second container belong to, based at least on the created graph(s). The memory further comprises instructions, e.g. by means of a computer program 423, which when executed by the processor 421 causes the monitoring arrangement 400 to assign performance metrics of the monitored traffic to community or communities of the community detection result; and to send the annotated community or communities to a network manager.

[0001 18] Figure 4 also illustrates the monitoring arrangement 400 comprising a memory 410. It shall be pointed out that figure 4 is merely an exemplifying illustration and memory 410 may be optional, be a part of the memory 422 or be a further memory of the monitoring arrangement 400. The memory may for example comprise information relating to the monitoring arrangement 400, to statistics of operation of the monitoring arrangement 400, just to give a couple of illustrating examples. Figure 4 further illustrates the monitoring arrangement 400 comprising processing means 420, which comprises the memory 422 and the processor 421 . Still further, figure 4 illustrates the monitoring arrangement comprising a communication unit 430. The communication unit 430 may comprise an interface through which the monitoring arrangement 400 communicates with other nodes or entities of or outside the network as well as other communication units. Figure 4 also illustrates the monitoring arrangement 400 comprising further functionality 440. The further functionality 440 may comprise hardware of software necessary for the monitoring arrangement 400 to perform different tasks that are not disclosed herein.

[0001 19] An alternative exemplifying realisation, or implementation, of the monitoring arrangement 400, 500 is illustrated in figure 5. Figure 5 illustrates the monitoring arrangement 500 comprising an obtaining unit 503 for obtaining one or more graphs based on monitored traffic between a first container and one or more second containers, the traffic being generated by respective applications of the first and the one or more second containers; and for obtaining a community detection result comprising information about which community or communities the respective application of the first and the one or more second container belong to, based at least on the created graph(s). Figure 5 illustrates the monitoring arrangement 500 comprising as assigning unit 504 for assigning performance metrics of the monitored traffic to community or communities of the community detection result; and a sending unit 505 for sending the annotated community or communities to a network manager.

[000120] In figure 5, the monitoring arrangement 500 is also illustrated comprising a communication unit 501 . Through this unit, the monitoring

arrangement 500 is adapted to communicate with other nodes and/or entities in or outside the network. The communication unit 501 may comprise more than one receiving arrangement. For example, the communication unit 501 may be connected to both a wire and an antenna, by means of which the monitoring arrangement 500 is enabled to communicate with other nodes and/or entities in the . Similarly, the communication unit 501 may comprise more than one transmitting arrangement, which in turn is connected to both a wire and an antenna, by means of which the monitoring arrangement 500 is enabled to communicate with other nodes and/or entities in the network. The monitoring arrangement 500 further comprises a memory 502 for storing data. Further, the monitoring arrangement 500 may comprise a control or processing unit (not shown) which in turn is connected to the different units 503-505. It shall be pointed out that this is merely an illustrative example and the monitoring arrangement 500 may comprise more, less or other units or modules which execute the functions of the monitoring arrangement 500 in the same manner as the units illustrated in figure 5.

[000121 ] It should be noted that figure 5 merely illustrates various functional units in the monitoring arrangement 500 in a logical sense. The functions in practice may be implemented using any suitable software and hardware

means/circuits etc. Thus, the embodiments are generally not limited to the shown structures of the monitoring arrangement 500 and the functional units. Hence, the previously described exemplary embodiments may be realised in many ways. For example, one embodiment includes a computer-readable medium having instructions stored thereon that are executable by the control or processing unit for executing the method steps in the monitoring arrangement 500. The instructions executable by the computing system and stored on the computer-readable medium perform the method steps of the monitoring arrangement 500 as set forth in the claims.

[000122] The monitoring arrangement has the same advantages as the method performed by the monitoring arrangement. One possible advantage is that the solution scales well and may also be used in cloud environments consisting of multiple data centres. A precise traffic matrix of the data centre, i.e. the

annotated community or communities, may be made available in a timely manner for the network manager, reducing the time when allocation of resources is suboptimal. Further, IP (Internet Protocol) address changes may be detected locally (for example, by inspecting TCP open and close connection packets, or by rapidly aging out an IP address that saw no traffic addressed to it in a short time interval) and therefore the traffic matrix/matrices and/or the annotated community or communities may better reflect the actual situation in the data centre. This may also reduce the need for integration of the orchestrator or network management system with third-party IP address management tools, thus providing both OPEX and potentially CAPEX savings. Still a further possible advantage is that the traffic matrix may be annotated easily with compute resource consumption metrics collected locally, thus removing the need for the network manager to access this data separately and further reducing the integration costs.

[000123] According to an embodiment, performance metrics relate to one or more off latency, packet loss, jitter, level of reordering and current network capacity usage.

[000124] According to yet an embodiment, the monitoring arrangement is implemented in a server node.

[000125] According to still an embodiment, wherein the monitoring arrangement is implemented in at least one of the one or more second containers.

[000126] According to another embodiment, the monitoring arrangement (400, 500) is further configured for obtaining the graph(s) by receiving respective graphs from respective monitoring functions of respective containers.

[000127] According to a further embodiment, the monitoring arrangement 400, 500 is further configured for obtaining the community detection result by executing a community detection algorithm based on the received graphs; or receiving local community detection result from respective monitoring functions in the first container and/or in the one or more second containers and merging the received local communities to obtain a global community detection result.

[000128] According to an embodiment, the community detection algorithm is a modularity optimisation algorithm, e.g. the Louvain method; or a seed expansion algorithm [000129] According to yet an embodiment, the monitoring arrangement 400, 500 is further configured for receiving monitoring data from a respective monitoring function of the first and the one or more second containers.

[000130] According to still an embodiment, the monitoring arrangement 400, 500 is further configured for obtaining the graph by creating the graph based on monitored traffic between the first container and the one or more second containers

[000131 ] According to another embodiment, the monitoring arrangement 400, 500 is configured for exchanging the created graph with a monitoring arrangement of other container(s).

[000132] According to a further embodiment, the monitoring arrangement 400, 500 is configured for obtaining the community detection result by executing a community detection algorithm based on the graph; or receiving the community detection result from respective monitoring functions of the one or more second containers, or receiving the community detection result from a server node.

[000133] According to an embodiment, the monitoring arrangement 400, 500 is configured for when the obtaining of the community detection result comprises receiving the community detection result from a server node, the monitoring arrangement is further configured for finding local communities, sending the found local communities to the serving node, wherein the received community detection result from the server node comprises a merging of local communities to a global community detection result.

[000134] According to yet an embodiment, the monitoring arrangement 400, 500 is configured for monitoring traffic between the first container and the one or more second containers.

[000135] According to still an embodiment, the monitoring arrangement 400, 500 is configured for receiving a request for annotated community or communities with respect to the network performance metrics that requires to be monitored from a server node. [000136] According to another embodiment, the monitoring arrangement 400, 500 is configured for receiving a request for annotated community or communities with respect to the network performance metrics that requires to be monitored from an OAM node.

[000137] Embodiments herein also relate to a network manager for managing a communication network implementing container-based virtualisation. The network manager has the same technical features, objects and advantages as the method performed by the network manager. Hence, the network manager will only be described in brief in order to avoid unnecessary repetition.

[000138] Embodiments of such a network manager will now be described with reference to figures 6 and 7. Figures 6 and 7 illustrate the network manager 600, 700 being configured for receiving annotated community or communities from a monitoring arrangement; and performing a managing action with regard to a first container and one or more second containers based on the received annotated community or communities.

[000139] The network manager may be realised on implemented in various ways. A first exemplifying realisation or implementation is illustrated in figure 6. Figure 6 illustrates the network manager 600comprising a processor 621 and memory 622, the memory comprising instructions, e.g. by means of a computer program 623, which when executed by the processor 621 causes the network manager 600 to receive annotated community or communities from a monitoring arrangement; and to perform a managing action with regard to a first container and one or more second containers based on the received annotated community or communities.

[000140] Figure 6 also illustrates the network manager 600 comprising a memory 610. It shall be pointed out that figure 6 is merely an exemplifying illustration and memory 610 may be optional, be a part of the memory 622 or be a further memory of the network manager 600. The memory may for example comprise information relating to the network manager 600, to statistics of operation of the network manager 600, just to give a couple of illustrating examples. Figure 6 further illustrates the network manager 600 comprising processing means 620, which comprises the memory 622 and the processor 621 . Still further, figure 6 illustrates the network manager 600 comprising a

communication unit 630. The communication unit 630 may comprise an interface through which the network manager 600 communicates with other nodes or entities of the network as well as other communication units. Figure 6 also illustrates the network manager 600 comprising further functionality 640. The further functionality 640 may comprise hardware of software necessary for the network manager 600 to perform different tasks that are not disclosed herein.

[000141 ] An alternative exemplifying realisation, or implementation, of the network manager is illustrated in figure 7. Figure 7 illustrates the network manager 700 comprising a receiving unit 703 for receiving annotated community or communities from a monitoring arrangement. Figure 7 also illustrates the network manager 700 comprising a performing unit 704 for performing a managing action with regard to a first container and one or more second containers based on the received annotated community or communities.

[000142] In figure 7, the network manager 700 is also illustrated comprising a communication unit 701 . Through this unit, the network manager 700 is adapted to communicate with other nodes and/or entities in the network. The communication unit 701 may comprise more than one receiving arrangement. For example, the communication unit 701 may be connected to both a wire and an antenna, by means of which the network manager 700 is enabled to communicate with other nodes and/or entities in the network. Similarly, the communication unit 701 may comprise more than one transmitting arrangement, which in turn is connected to both a wire and an antenna, by means of which the network manager 700 is enabled to communicate with other nodes and/or entities in the network. The network manager 700 further comprises a memory 702 for storing data. Further, the network manager 700 may comprise a control or processing unit (not shown) which in turn is connected to the different units 703-704. It shall be pointed out that this is merely an illustrative example and the network manager 700 may comprise more, less or other units or modules which execute the functions of the network manager 700 in the same manner as the units illustrated in figure 7. [000143] It should be noted that figure 7 merely illustrates various functional units in the network manager 700 in a logical sense. The functions in practice may be implemented using any suitable software and hardware means/circuits etc. Thus, the embodiments are generally not limited to the shown structures of the network manager 700 and the functional units. Hence, the previously described exemplary embodiments may be realised in many ways. For example, one embodiment includes a computer-readable medium having instructions stored thereon that are executable by the control or processing unit for executing the method steps in the network manager 700. The instructions executable by the computing system and stored on the computer-readable medium perform the method steps of the network manager 700 as set forth in the claims.

[000144] The network manager has the same possible advantages as the method performed by the network manager. One possible advantage is that.

[000145] According to an embodiment, the network manager 600, 700 is further configured for evaluating the received annotated community or communities against a performance metric, e.g. comparing the received annotated community or communities to a predefined threshold associated with the performance metric, wherein the managing action is performed if the received annotated community or communities do/does not meet the predefined threshold.

[000146] According to yet an embodiment, the network manager 600, 700 is further configured for requesting the annotated community or communities with respect to the network performance metric that requires to be monitored.

[000147] According to yet an embodiment, the managing action is at least one of migrating containers on one community to another community to reduce latency, or scaling out containers that belong to multiple communities to ensure

computational capabilities.

[000148] Figure 8 schematically shows an embodiment of an arrangement 800 in a monitoring arrangement 500 for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation. Comprised in the arrangement 800 in the monitoring arrangement 500 are here a processing unit 806, e.g. with a Digital Signal Processor, DSP. The processing unit 806 may be a single unit or a plurality of units to perform different actions of procedures described herein. The arrangement 800 of, or in, the monitoring arrangement 500 may also comprise an input unit 802 for receiving signals from other entities, and an output unit 804 for providing signal(s) to other entities. The input unit and the output unit may be arranged as an integrated entity or as illustrated in the example of figure 5, as one or more interfaces 501 .

[000149] Furthermore, the arrangement in the monitoring arrangement 500 comprises at least one computer program product 808 in the form of a non-volatile memory, e.g. an Electrically Erasable Programmable Read-Only Memory, EEPROM, a flash memory and a hard drive. The computer program product 808 comprises a computer program 810, which comprises code means, which when executed in the processing unit 806 in the arrangement 800 in the monitoring arrangement 500 causes the monitoring arrangement 500 to perform the actions e.g. of the procedure described earlier in conjunction with figures 1a-1f.

[000150] The computer program 810 may be configured as a computer program code structured in computer program modules 810a-810e. Hence, in an exemplifying embodiment, the code means in the computer program of the arrangement 800 in the monitoring arrangement comprises an obtaining unit, or module, for obtaining one or more graphs based on monitored traffic between a first container and one or more second containers, the traffic being generated by respective applications of the first and the one or more second containers; and for obtaining a community detection result comprising information about which community or communities the respective application of the first and the one or more second container belong to, based at least on the created graph. The code means in the computer program of the arrangement 800 in the monitoring arrangement 500 further comprises an assigning unit, or module, for assigning performance metrics of the monitored traffic to community or communities of the community detection result, and; and a sending unit, or module, for sending ) the annotated community or communities to a network manager. [000151 ] The computer program modules could essentially perform the actions of the flow illustrated in figures 1a-1f, to emulate the monitoring arrangement 500. In other words, when the different computer program modules are executed in the processing unit 806, they may correspond to the units 503-505 of figure 5.

[000152] Figure 9 schematically shows an embodiment of an arrangement 900 in a network manager 700. Comprised in the arrangement 900 are here a processing unit 906, e.g. with a Digital Signal Processor. The processing unit 906 may be a single unit or a plurality of units to perform different actions of

procedures described herein. The arrangement 900 may also comprise an input unit 902 for receiving signals from other entities, and an output unit 904 for providing signal(s) to other entities. The input unit and the output unit may be arranged as an integrated entity or as illustrated in the example of figure 7, as one or more interfaces 701 .

[000153] Furthermore, the arrangement 900 in the network manager 700 comprises at least one computer program product 908 in the form of a non-volatile memory, e.g. an Electrically Erasable Programmable Read-Only Memory,

EEPROM, a flash memory and a hard drive. The computer program product 908 comprises a computer program 910, which comprises code means, which when executed in the processing unit 906 in the arrangement 900 in the network manager 700 causes the network manager 700to perform the actions e.g. of the procedure described earlier in conjunction with figures 2a-2c.

[000154] The computer program 910 may be configured as a computer program code structured in computer program modules 910a-910e. Hence, in an

exemplifying embodiment, the code means in the computer program of the arrangement 900 in the network manager 700 comprises a receiving unit, or module, for receiving annotated community or communities from a monitoring arrangement; and a performing unit, or module, for a managing action with regard to a first container and one or more second containers based on the received annotated community or communities . [000155] The computer program modules could essentially perform the actions of the flow illustrated in figures 2a-2c, to emulate the network manager 700. In other words, when the different computer program modules are executed in the processing unit 906, they may correspond to the units 703-704 of figure 7.

[000156] Although the code means in the respective embodiments disclosed above in conjunction with figures 5 and 7 are implemented as computer program modules which when executed in the respective processing unit causes the monitoring arrangement and the network manager respectively to perform the actions described above in the conjunction with figures mentioned above, at least one of the code means may in alternative embodiments be implemented at least partly as hardware circuits.

[000157] The processor may be a single Central Processing Unit, CPU, but could also comprise two or more processing units. For example, the processor may include general purpose microprocessors; instruction set processors and/or related chips sets and/or special purpose microprocessors such as Application Specific Integrated Circuits, ASICs. The processor may also comprise board memory for caching purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may comprise a computer readable medium on which the computer program is stored. For example, the computer program product may be a flash memory, a Random-Access Memory RAM, Read-Only Memory, ROM, or an EEPROM, and the computer program modules described above could in alternative embodiments be distributed on different computer program products in the form of memories within the monitoring arrangement and the network manager respectively.

[000158] It is to be understood that the choice of interacting units, as well as the naming of the units within this disclosure are only for exemplifying purpose, and nodes suitable to execute any of the methods described above may be configured in a plurality of alternative ways in order to be able to execute the suggested procedure actions. [000159] It should also be noted that the units described in this disclosure are to be regarded as logical entities and not with necessity as separate physical entities.

[000160] While the embodiments have been described in terms of several embodiments, it is contemplated that alternatives, modifications, permutations and equivalents thereof will become apparent upon reading of the specifications and study of the drawings. It is therefore intended that the following appended claims include such alternatives, modifications, permutations and equivalents as fall within the scope of the embodiments and defined by the pending claims.

Claims

1 . A method (100) performed by a monitoring arrangement for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation, the method comprising:

- obtaining (120) one or more graphs based on monitored traffic between a first container and one or more second containers, the traffic being generated by respective applications of the first and the one or more second containers,

- obtaining (150) a community detection result comprising information about which community or communities the respective application of the first and the one or more second container belong to, based at least on the created graph,

- assigning (160) performance metrics of the monitored traffic to community or communities of the community detection result, and

- sending (170) the annotated community or communities to a network

manager.

2. The method (100) according to claim 1 , wherein performance metrics relate to one or more off latency, packet loss, jitter, level of reordering and current network capacity usage.

3. The method (100) according to claim 1 or 2, wherein the monitoring arrangement is implemented in a server node.

4. The method (100) according to any of claims 1 -3, wherein the monitoring arrangement is implemented in at least one of the one or more second containers.

5. The method (100) according to any of claims 1 -3, wherein obtaining (120) the graph(s) comprises receiving respective graphs from respective monitoring functions of respective containers.

6. The method (100) according to claim 5, wherein the obtaining (150) of the community detection result comprises executing a community detection algorithm based on the received graphs; or receiving local community detection result from respective monitoring functions in the first container and/or in the one or more second containers and merging (155) the received local communities to obtain a global community detection result.

7. The method (100) according to claim 6, wherein the community detection algorithm is a modularity optimisation algorithm, e.g. the Louvain method; or a seed expansion algorithm.

8. The method (100) according to claim 6 or 7, further comprising receiving (1 10) monitoring data from a respective monitoring function of the first and the one or more second containers.

9. The method (100) according to claim 1 , 2 or 4, wherein obtaining (120) the graph comprises creating the graph based on monitored traffic between the first container and the one or more second containers.

10. The method (100) according to claim 8, further comprising exchanging (140) the created graph with a monitoring arrangement of other container(s).

1 1 . The method (100) according to claim 8 or 9, wherein the obtaining (150) of the community detection result comprises executing a community detection algorithm based on the graph; or receiving the community detection result from respective monitoring functions of the one or more second containers, or receiving the community detection result from a server node.

12. The method (100) according to claim 1 1 , wherein when the obtaining (150) of the community detection result comprises receiving the community detection result from a server node, the method further comprises finding local communities, sending the found local communities to the serving node, wherein the received community detection result from the server node comprises a merging of local communities to a global community detection result.

13. The method (100) according to any of claims 9-12, further comprising monitoring (105) traffic between the first container and the one or more second containers.

14. The method (100) according to any of claims 1 , 2, 4 or 9-13, further comprising receiving (101 ) a request for annotated community or communities with respect to the network performance metrics that requires to be monitored from a server node.

15. The method (100) according to any of claims 1 -14, further comprising receiving (102) a request for annotated community or communities with respect to the network performance metrics that requires to be monitored from an Operation, Administration and Maintenance, OAM, node.

16. A method (200) performed by a network manager for managing a communication network implementing container-based virtualisation, the method comprising:

- receiving (220) annotated community or communities from a monitoring arrangement, and

- performing (230) a managing action with regard to a first container and one or more second containers based on the received annotated community or communities.

17. The method (200) according to claim 16, further comprising (225) evaluating the received annotated community or communities against a

performance metric, e.g. comparing the received annotated community or communities to a predefined threshold associated with the performance metric, wherein the managing action is performed if the received annotated community or communities do/does not meet the predefined threshold.

18. The method (200) according to claim 16 or 17, further comprising requesting (210) the annotated community or communities with respect to the network performance metric that requires to be monitored.

19. The method (200) according to any of claims 16-18, wherein the managing action is at least one of migrating containers on one community to another community to reduce latency, or scaling out containers that belong to multiple communities to ensure computational capabilities.

20. A monitoring arrangement (400, 500) for enabling resource management in a data centre comprising compute and network resources implementing container-based virtualisation, the monitoring arrangement being configured for:

- obtaining one or more graphs based on monitored traffic between a first container and one or more second containers, the traffic being generated by respective applications of the first and the one or more second

containers,

- obtaining a community detection result comprising information about which community or communities the respective application of the first and the one or more second container belong to, based at least on the created graph,

- assigning performance metrics of the monitored traffic to community or communities of the community detection result, and

- sending the annotated community or communities to a network manager.

21 . The monitoring arrangement (400, 500) according to claim 20, wherein performance metrics relate to one or more off latency, packet loss, jitter, level of reordering and current network capacity usage.

22. The monitoring arrangement (400, 500) according to claim 20 or 21 , wherein the monitoring arrangement is implemented in a server node.

23. The monitoring arrangement (400, 500) according to any of claims 20-23, wherein the monitoring arrangement is implemented in at least one of the one or more second containers.

24. The monitoring arrangement (400, 500) according to any of claims 20-33, configured for obtaining the graph(s) by receiving respective graphs from

respective monitoring functions of respective containers.

25. The monitoring arrangement (400, 500) according to claim 24, configured for obtaining the community detection result by executing a community detection algorithm based on the received graphs; or receiving local community detection result from respective monitoring functions in the first container and/or in the one or more second containers and merging the received local communities to obtain a global community detection result.

26. The monitoring arrangement (400, 500) according to claim 25, wherein the community detection algorithm is a modularity optimisation algorithm, e.g. the Louvain method; or a seed expansion algorithm.

27. The monitoring arrangement (400, 500) according to claim 25 or 26, further being configured for receiving monitoring data from a respective monitoring function of the first and the one or more second containers.

28. The monitoring arrangement (400, 500) according to claim 20, 21 or 23, configured for obtaining the graph by creating the graph based on monitored traffic between the first container and the one or more second containers.

29. The monitoring arrangement (400, 500) according to claim 27, further being configured for exchanging the created graph with a monitoring arrangement of other container(s).

30. The monitoring arrangement (400, 500) according to claim 27 or 28, configured for obtaining the community detection result by executing a community detection algorithm based on the graph; or receiving the community detection result from respective monitoring functions of the one or more second containers, or receiving the community detection result from a server node.

31 . The monitoring arrangement (400, 500) according to claim 30, configured for when the obtaining of the community detection result comprises receiving the community detection result from a server node, the monitoring arrangement is further configured for finding local communities, sending the found local communities to the serving node, wherein the received community detection result from the server node comprises a merging of local communities to a global community detection result.

32. The monitoring arrangement (400, 500) according to any of claims 28-31 , further being configured for monitoring traffic between the first container and the one or more second containers.

33. The monitoring arrangement (400, 500) according to any of claims 20, 21 , 23 or 28-32, further being configured for receiving a request for annotated community or communities with respect to the network performance metrics that requires to be monitored from a server node.

34. The monitoring arrangement (400, 500) according to any of claims 20-33, further being configured for receiving a request for annotated community or communities with respect to the network performance metrics that requires to be monitored from an Operation, Administration and Maintenance, OAM, node.

35. A network manager (600, 700) for managing a communication network implementing container-based virtualisation, the network manager being

configured for:

- receiving annotated community or communities from a monitoring

arrangement, and

- performing a managing action with regard to a first container and one or more second containers based on the received annotated community or communities.

36. The network manager (600, 700) according to claim 35, further being configured for evaluating the received annotated community or communities against a performance metric, e.g. comparing the received annotated community or communities to a predefined threshold associated with the performance metric, wherein the managing action is performed if the received annotated community or communities do/does not meet the predefined threshold.

37. The network manager (600, 700) according to claim 35 or 36, further being configured for requesting the annotated community or communities with respect to the network performance metric that requires to be monitored.

38. The network manager (600, 700) according to any of claims 35-37, wherein the managing action is at least one of migrating containers on one community to another community to reduce latency, or scaling out containers that belong to multiple communities to ensure computational capabilities.

39. A Computer program (810), comprising computer readable code means, which when run in a processing unit (806) comprised in an arrangement (800) in a monitoring arrangement (500) according to claims 20-34 causes the monitoring arrangement (500) to perform the corresponding method according to any of claims 1 -15.

40. A Computer program product (808) comprising the computer program (810) according to claim 39.

41 . A Computer program (910), comprising computer readable code means, which when run in a processing unit (906) comprised in an arrangement (900) in a network manager (700) according to claims 35-38 causes the network manager (700) to perform the corresponding method according to any of claims 16-19.

42. A Computer program product (908) comprising the computer program (910) according to claim 41 .