COMMUNICATION PATHS

BACKGROUND OF THE INVENTION

The present invention, in some embodiments thereof, relates to mapping virtualized network environment data and, more particularly, but not exclusively, to mapping virtualized network by monitoring communication between virtual machines via virtual switches. Virtualization of computing resources is important in current computer environments. A virtual machine or virtualized machine (VM) is a software construct or the like operating on a physical host computing device for the purpose of emulating a hardware system. The host may accommodate multiple deployed VMs, each VM may be performing some predetermined function(s) by way of resources available from the host.

In the world of cloud management systems, affinity rules and anti-affinity rules instruct the management systems to keep virtual entities together or separated. For example, when two VMs communicate frequently and should share a host, the a VM- VM affinity rule is created to keep them together, and when there are two resource- hungry VMs an anti-affinity rule keeps them from sharing a host.

SUMMARY

The object of embodiments of the invention is to map communication paths and data between virtualized machines in a virtualized network environment. The object is solved by the independent claims of this application, and the dependent claims protect further implementation forms.

According to a first aspect, the present invention relates to a system of mapping virtualized network environment data, comprising: at least one interface adapted to receive data from a plurality of virtual switches in a virtualized network environment to detect a plurality of communication requests to establish communication between at least two of a plurality of virtual machines in the virtualized network environment; and at least one processor adapted to: extract from each one of the plurality of communication requests a physical host of each of the at least two virtual machines; and update a topology dataset mapping at least one communication characteristic of data communication between the plurality of virtual machines and a physical host of each one of the plurality of virtual machines.

In a first possible implementation form of the system according to the first aspect, the system further comprises a plurality of switch modules which are installed in the plurality of virtual switches to transmit the data to the at least one interface.

In a second possible implementation form of the system according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the system further comprises an Application Program Interface, API, to allow a remote client to access the topology dataset. In a third possible implementation form of the system according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the virtualized network environment is a software-defined network, SDN.

In a fourth possible implementation form of the system according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the at least one communication characteristic is a communication frequency between each pair of virtual machines from the plurality of virtual machines.

In a fifth possible implementation form of the system according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the at least one communication characteristic is a data capacity of the communication between each pair of virtual machines from the plurality of virtual machines.

In a sixth possible implementation form of the system according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the at least one processor is adapted to identify load fluctuation events in the virtualized network environment based on an analysis of the topology dataset. In a seventh possible implementation form of the system according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the at least one processor is adapted to calculate instructions to allocate a new physical host to at least one of the plurality of virtual machines in the virtualized network environment based on an analysis of the topology dataset.

In an eighth possible implementation form of the system according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the at least one processor is adapted to relocate resources of the virtualized network environment between the plurality of virtual machines based on an analysis of the topology dataset.

According to a second aspect, the present invention relates to a method of mapping virtualized network environment data, comprising: monitoring data in a plurality of virtual switches in a virtualized network environment to detect a plurality of communication requests to establish communication between at least two of a plurality of virtual machines in the virtualized network environment; extracting from each one of the plurality of communication requests a physical host of each of the at least two virtual machines; and updating a topology dataset mapping at least one communication characteristic of data communication between the plurality of virtual machines and a physical host of each one of the plurality of virtual machines. In a first possible implementation form of the method according to the second aspect, the method further comprises, before the updating: extracting the at least one communication characteristic from each one of the plurality of communication requests.

In a second possible implementation form of the method according to the second aspect, the method further comprises: analyzing the topology dataset to identify load fluctuation events in the virtualized network environment.

In a third possible implementation form of the method according to the second aspect, the method further comprises: analyzing the topology dataset to calculate instructions to allocate a new physical host to at least one of the plurality of virtual machines in the virtualized network environment. According to a third aspect, the present invention relates to a system for mapping virtualized network environment data, comprising: a memory for storing a topology dataset mapping at least one communication characteristic of data communication between a plurality of virtual machines and a physical host of each one of the plurality of virtual machines; a code store for storing a code; a processor, connected to the memory and the code store, adapted to implement the code; wherein the code comprises: code to monitor data in a plurality of virtual switches in a virtualized network environment to detect a plurality of communication requests to establish communication between at least two of the plurality of virtual machines in the virtualized network environment; code to extract from each one of the plurality of communication requests a physical host of each of the at least two virtual machines; and code to update the topology dataset based on the extracted data.

Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the invention, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

Implementation of the method and/or system of embodiments of the invention can involve performing or completing selected tasks manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of embodiments of the method and/or system of the invention, several selected tasks could be implemented by hardware, by software or by firmware or by a combination thereof using an operating system.

For example, hardware for performing selected tasks according to embodiments of the invention could be implemented as a chip or a circuit. As software, selected tasks according to embodiments of the invention could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In an exemplary embodiment of the invention, one or more tasks according to exemplary embodiments of method and/or system as described herein are performed by a data processor, such as a computing platform for executing a plurality of instructions. Optionally, the data processor includes a volatile memory for storing instructions and/or data and/or a non-volatile storage, for example, a magnetic hard- disk and/or removable media, for storing instructions and/or data. Optionally, a network connection is provided as well. A display and/or a user input device such as a keyboard or mouse are optionally provided as well.

BRIEF DESCRIPTION OF THE DRAWINGS Some embodiments of the invention are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the invention. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the invention may be practiced.

In the drawings:

FIG. 1 is a flowchart schematically representing a method for mapping virtualized network environment data, according to some embodiments of the present invention; FIG. 2 is a schematic illustration of a system of mapping virtualized network environment data, according to some embodiments of the present invention;

FIG. 3 is a schematic illustration of an exemplary implementation of a system of mapping virtualized network environment data based on a Dragonflow mechanism, according to some embodiments of the present invention; and FIGs. 4, 5, 6, and 7 are schematic illustrations of an exemplary implementation of a system of mapping virtualized network environment data and a flow of the method of mapping, according to some embodiments of the present invention.

DETAILLED DESCRIPTION The present invention, in some embodiments thereof, relates to mapping virtualized network environment data and, more particularly, but not exclusively, to mapping virtualized network by monitoring communication between virtual machines via virtual switches. According to some embodiments of the present invention, there is provided a method of mapping communication paths between virtual machines/virtualized machines (VMs) in a cloud network and create a combined real-time physical- virtual network topology that includes the utilization of all the paths. A controller, such as a software defined network (SDN) controller in a SDN application connects to all the virtual access layer components of the cloud system, such as virtual switches and/or virtual routers. Once connected, all new connections (i.e. "first frames") between VMs are directed to the controller. When the controller receives such a new connection, it stores the information in a topology dataset mapping (e.g. a database). The interface may monitor several types of data that may be used for creating a real-time representation of the communication paths. For example, the data may include which VM is communicating with which VM (by intercepting the first packet that establishes the path), what is the amount of data which is running between two connected VMs (by metering the packets and octets on the datapath) and/or how often the path is being used. By following the network routing, it is also possible to match VMs with physical hosts, thus reducing the complexity of correlating data with the cloud management system. This allows simplifying of the pre-deployment design of the application, reacting to scenarios such as load fluctuations, optimizing the physical resource utilization of the cloud system and/or mapping the communication paths without consuming significant additional system resources such as central processing unit (CPU) and/or network.

Optionally, the data is then provided to external applications via an application programming interface (API) and/or via a publish/subscribe mechanism.

Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the Examples. The invention is capable of other embodiments or of being practiced or carried out in various ways. The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention. Referring now to the drawings, FIG. 1 is a flowchart schematically representing a method for mapping virtualized network environment data by monitoring communication between virtual machines via virtual switches, according to some embodiments of the present invention. Reference is also made to FIG. 2, which is a schematic illustration of a system of mapping virtualized network environment data, according to some embodiments of the present invention.

A virtualized network environment includes multiple virtual machines 201, each hosted in a physical host 202, and connected to each other via a network 203. A physical host 202 may include one or more computing devices, for example, a mainframe computer, an enterprise server, a workstation, multiple connected computers and/or a personal computer.

Network 203 may include, for example, local area network (LAN), a wireless network such as mobile network, wireless local area network (WLAN) such as Wireless Fidelity (WiFi™), a wireless personal area network (WPAN) such as Bluetooth™ protocol and/or any other network.

Optionally, the virtualized network environment is a software defined network (SDN). The SDN may be implemented in any way.

Each of virtual machines 201 is connected to a virtual switch 204, which may also be, for example, a virtual router and/or any other type of virtual access layer component. Each virtual switch 204 is also hosted in a physical host 202.

When a VM requires communication with another VM, a communication request is sent by the first VM to the second VM, to establish communication between them. Such communication request may include, for example, first data packet that establishes the path between the VMs. The system includes an interface, such as a controller (or multiple controllers)

205, which receives data from virtual switches 204 and monitors them to detect the communication requests, as shown at 101.

The data from virtual switches 204 may be received by switch modules 206 which are forwarding elements installed in each of virtual switches 204 to transmit the data. Switch modules 206 may be, for example, an application and/or a program. Alternatively, the data from virtual switches 204 may be received by physical switches connected to physical hosts 202, such as switches supporting connection to an SDN controller.

Then, as shown at 102, the physical host 202 of each of virtual machines 201 is extracted, by a processor 207, from each of the communication requests between these virtual machines. After monitoring for a sufficient period of time, the physical host of each of virtual machines 201 may be extracted.

Processor 207 may be used directly by controller 206 and/or by an application, such as an SDN application. Also, as shown at 103, at least one communication characteristic of data communication between virtual machines 201 and each physical host 202 is extracted from the communication requests.

Optionally, the communication characteristic is a communication frequency between each pair of virtual machines 201. This characteristic is measured, for example, by counting the communication requests transmitted between the two virtual machines per a unit of time, such as a second.

Optionally, the communication characteristic is a data capacity of the communication between each pair of virtual machines 201. This characteristic is measured, for example, by metering the packets and octets on the datapath between the two virtual machines.

Then, as shown at 104, a topology dataset 208 which maps the communication characteristic s) is updated. Topology dataset 208 may include any kind of structured data collection that allows access to stored data. Topology dataset 208 may be stored, for example, in a digital data storage unit such as a magnetic drive and/or a solid state drive and/or in a distributed memory such as a content delivery network or content distribution network (CDN) that is a large distributed system of servers deployed in multiple data centers across the internet.

Optionally, as shown at 105, topology dataset mapping is analyzed by processor 206 to provide information that may be used for virtualized network environment management. Optionally, processor 207 identifies load fluctuation events in the virtualized network environment based on the analysis. For example, extreme load, such as CPU and/or memory overload, in one of the virtual machines 201 may be detected according to the data capacity communicated to that virtual machine from other virtual machines 201.

Optionally, processor 207 relocate resources of the virtualized network environment, such as storage resources and/or processing resources, between the virtual machines 201 based on the analysis. For example, when extreme load in one of the virtual machines 201 is detected, data and/or applications are transferred from that virtual machine to other virtual machines 201. The allocation may be dynamic allocation constantly performed in the virtualized network environment base on realtime information updated in topology dataset 208.

Optionally, the system includes an application program interface (API) 209, to allow a remote client 210 to access topology dataset 208. Remote client 210 may include, for example, VM placement optimization algorithm, reporting component, analytics algorithm, planning application, charging application and/or any other program.

Optionally, the system includes a publish/subscribe mechanism, to which remote client 210 may subscribe. Remote client 210 then continuously receives data, such as creation, deletion and update events on pertinent entities in the virtualized network environment. For example, an update may include new communication path establishment and/or changes in utilization level of a path.

Reference is now made to FIG. 3, which is a schematic illustration of an exemplary implementation of a system of mapping virtualized network environment data based on a Dragonflow mechanism, according to some embodiments of the present invention.

A possible baseline implementation to the presented concept may be found in the Dragonflow open-source project (by Huawei), which is an SDN based distributed virtual router. The Dragonflow project implements the layer 3 routing in a virtual network in Openstack cloud management software (Dragonflow L3App). This implementation is responding to first packets sent from VM1 to VM2 and installs the forwarding flows on the (typically two) virtual switch(es) to which the two VMs are connected. According to some embodiments of the present invention the Dragonflow mechanism is enhanced to store all these VM-to-VM connections in a dataset. This may also provide ongoing behavioral metrics, such as how many packets or octets have moved on the path, how often is the path being utilized, what are the physical computer nodes that host the VMs and what physical network is used to communicate.

Dragonflow L3App is extended with a Collector (301) that writes the data to the virtual topology database (V-TOPO DB) (302). An API (303) enables access to the data in V-TOPO DB (302). External application (e.g. "VM Placement") (304) uses the API (303) to access the data. SDN Controller (301) is connected to all virtual access layer components of the cloud system.

Reference is now made to FIGs. 4, 5, 6, and 7, which are schematic illustrations of an exemplary implementation of a system of mapping virtualized network environment data and a flow of the method of mapping, according to some embodiments of the present invention.

First, as shown in 401 on FIG. 4, the first frame from VM1 to VM2 is intercepted in the SDN Controller.

Then, as shown in 402 on FIG. 4, the first frame from VM1 to VM2 is passed to the SDN Application. Then, as shown in 403 on FIG. 4, the record of the first frame from VM1 to

VM2 is updated in the Virtual topology.

Then, as shown in 404 on FIG. 5, the SDN Controller installs switch modules in virtual switch 1 (vSwitchl) which is bound to VM2 and in virtual switch X (vSwitchX) which is bound to VM1. Then, as shown in 405 on FIG. 6, communication between VM1 and VM2 is offloaded to vSwitchl and vSwitchX, bypassing the SDN Controller.

Then, as shown in 406 on FIG. 7, the SDN Application queries performance metrics about the communication between VM1 and VM2. Then, as shown in 407 on FIG. 7, the SDN Application updates the Virtual topology with the data of the performance metrics.

Then, as shown in 408 on FIG. 7, A Client calls the API to read data from the Virtual topology. Alternatively, as shown in 409 on FIG. 7, the SDN Application publishes the updated data to a subscribed client.

An exemplary utilization of some embodiments of the present invention relates to affinity and anti-affinity of VMs. In the world of cloud management systems, there exist numerous optimization problems that revolve around the affinity and anti-affinity of virtualized machines. For instance, two VMs must reside in the same network (due to high level of intercommunication) but on different physical computer hosts (due to high CPU utilization). Such optimization problems take different shapes and tactics to resolve, often leading to point-solutions or very complicated deployment designs that attempt to mitigate future problems. The widely accepted approach to date is attempting to apply affinity and anti- affinity policies during the deployment phase of a cloud-resident system. This approach is similar to trying to anticipate all the problems and behavior of all communicating pairs in the system at the deployment time. To a point, it invalidates some of the most compelling advantages of cloud computing, which include elastic scalability (grow and shrink to meet demand), as well as self-healing (automatically replace malfunctioning components). In addition, it is not feasible to optimize a given topology or to accurately score it to compare to other possible permutations (which also meet the affmity/anti- affmity policies), since piecing together a model that reflects the actual communication and placement is complex and prone to inconsistencies. A possible theoretical runtime alternative implementation that attempts to provide such information could, potentially, connect to all the networking elements in the system (virtual, logical and physical), and subscribe to their individual northbound APIs (e.g. NetFlow, sFlow, IPFix), then correlate the data with metadata that may be retrieved from the cloud management system via its own APIs. This implementation may be highly complex and its results never truly consistent with the real world, due to inherent latencies. There exist methods and algorithms that, given a live connection graph that reflects the actual communication and placement of all VMs in the system, could potentially optimize the behavioral performance and cost of operation of the system. However, to date, no method has been proposed to provide a consistent, reliable view of the connected VMs and the level of utilization of the communication paths between VMs, i.e. how much do they truly converse with each other at any given time. Methods and systems according to some embodiments of the present invention may provide such view within the topology dataset mapping.

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

It is expected that during the life of a patent maturing from this application many relevant virtualized network environments will be developed and the scope of the term virtualized network environment is intended to include all such new technologies a priori.

The terms "comprises", "comprising", "includes", "including", "having" and their conjugates mean "including but not limited to". This term encompasses the terms "consisting of and "consisting essentially of.

The phrase "consisting essentially of means that the composition or method may include additional ingredients and/or steps, but only if the additional ingredients and/or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds, including mixtures thereof. The word "exemplary" is used herein to mean "serving as an example, instance or illustration". Any embodiment described as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments. The word "optionally" is used herein to mean "is provided in some embodiments and not provided in other embodiments". Any particular embodiment of the invention may include a plurality of "optional" features unless such features conflict.

It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention. To the extent that section headings are used, they should not be construed as necessarily limiting.