WO2017107018A1 - 应用拓扑关系发现的方法、装置和系统 - Google Patents

应用拓扑关系发现的方法、装置和系统 Download PDF

Info

Publication number
WO2017107018A1
WO2017107018A1 PCT/CN2015/098125 CN2015098125W WO2017107018A1 WO 2017107018 A1 WO2017107018 A1 WO 2017107018A1 CN 2015098125 W CN2015098125 W CN 2015098125W WO 2017107018 A1 WO2017107018 A1 WO 2017107018A1
Authority
WO
WIPO (PCT)
Prior art keywords
api call
call information
virtual machine
api
virtual
Prior art date
Application number
PCT/CN2015/098125
Other languages
English (en)
French (fr)
Inventor
刘挺
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to JP2017505627A priority Critical patent/JP6571161B2/ja
Priority to CN201580031988.0A priority patent/CN106489251B/zh
Priority to EP15908488.8A priority patent/EP3226493B1/en
Priority to KR1020177001923A priority patent/KR101979363B1/ko
Priority to PCT/CN2015/098125 priority patent/WO2017107018A1/zh
Priority to CN201910940823.5A priority patent/CN110865867B/zh
Priority to BR112017000458-5A priority patent/BR112017000458B1/pt
Publication of WO2017107018A1 publication Critical patent/WO2017107018A1/zh
Priority to US15/786,159 priority patent/US10459754B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/18—Protocol analysers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • the present invention relates to the field of IT technologies, and in particular, to a method, an apparatus, and a system for applying a topology relationship discovery.
  • network management mainly includes five functional domains: fault management, configuration management, performance management, security management, and billing management.
  • Configuration management is the foundation in the five functional domains. Its main functions include discovering the topology of the network, and monitoring and managing the configuration of network devices. All other functions are based on the topology of the network.
  • the network topology discovery is aimed at the end-to-end connection relationship in the network. The main purpose is to acquire and maintain the existence information of the network nodes and the connection relationship information between them, and draw the entire network topology diagram based on this.
  • an applied topology in an IT system is a network communication relationship between virtual machines, and network communication between virtual machines is generated based on an application running by a virtual machine.
  • the application topology is the deployment relationship between the components of the application (such as programs, services, components, virtual machines running the application, etc.) on the hosts (such as servers) of the IT system and the components of the deployed applications. Interactions (such as service requests and responses).
  • the discovery of existing application topologies is the active detection discovery. Active probing is to study the structure of the application and the behavior of the application user by sending relevant probe packets to the network target, observing and recording the returned results. Due to the need to send a large amount of data to the network, the load on the network is increased, and the accuracy of topology discovery is not high. There is a lack of prior art methods for application topology discovery that does not employ probe packets in a virtualized environment.
  • the present application describes a method, an apparatus, and a system for applying topological relationship discovery, and provides an application topology discovery solution for a virtualized environment, which reduces the complexity of establishing an application topology relationship between virtual machines.
  • the present application provides a method for applying topology relationship discovery, and collects at least two sets of API call information, where each group of API call information corresponds to one API call, and each set of API call information includes an identifier of a virtual machine corresponding to the API call.
  • the calling information and the second API call information satisfying the first condition include: the flow of the message in the first API call information flows in the opposite direction to the flow in the second API call information, and The API tune in the first API call information
  • the difference between the occurrence time of the use and the occurrence time of the API call in the second API call information is less than or equal to a preset threshold; satisfying the first condition above means the first API call information and the second API
  • a second condition if the frequency of the interaction between the first virtual machine and the second virtual machine meets the second condition, determining that an application topology relationship exists between the first virtual machine and the second virtual machine.
  • the method for applying the topology relationship discovery in the present application collects the API call information in the message transmission process, and determines whether the two virtual machines corresponding to the two sets of API call information exist by matching whether the two sets of API call information meet the first condition.
  • the topology discovery server can determine the interaction frequency between the virtual machines involved in the collected API call information, and determine the application topology relationship between the virtual machines according to the interaction frequency between the virtual machines.
  • the above solution provides a method for discovering the application topology relationship between virtual machines in a virtualization scenario.
  • the application topology information between virtual machines is determined by analyzing the API call information generated during the packet transmission process, and the solution complexity is low.
  • each group of API call information further includes a communication protocol; correspondingly, the first API call information and the second API call information satisfying the first condition further includes: the communication in the first API call information
  • the protocol is the same as the communication protocol in the second API call information.
  • the two virtual machines corresponding to the two sets of API call information may have an application topology relationship; when the communication protocols in the two sets of API call information are different, even if the message is satisfied
  • the requirement of the difference between the flow direction and the occurrence time of the API call cannot be considered as interaction between the two virtual machines corresponding to the two sets of API call information.
  • the determining whether the frequency of interaction between the first virtual machine and the second virtual machine meets the second condition comprises: analyzing at least two sets of API calls of the first virtual machine Information and at least two sets of API call information of the second virtual machine, determining an interaction frequency between the first virtual machine and the second virtual machine, comparing the interaction frequency and a preset frequency, when the interaction frequency More than the preset frequency, determining that the interaction frequency satisfies the second condition.
  • the preset frequency as a criterion for determining whether the application topology relationship exists between the virtual machines, those skilled in the art can adjust the preset frequency to control the strictness of the application topology relationship determination.
  • the preset frequency can also be set as needed. This embodiment of the present invention does not limit this.
  • the method before comparing the interaction frequency and the preset frequency, further includes: determining whether the first virtual machine and the second virtual machine belong to the same network segment, when the first When the virtual machine and the second virtual machine belong to the same network segment, the interaction frequency or one of the preset frequencies is modified according to a preset weighting coefficient;
  • the comparing the interaction frequency and the preset frequency comprises: comparing the corrected interaction frequency with the preset frequency; or comparing the interaction frequency with the corrected preset frequency.
  • the topology discovery server can determine whether the first virtual machine and the second virtual machine belong to the same network segment by using at least the following two methods:
  • the method may be as follows: determining whether the IP address of the first virtual machine and the IP address of the second virtual machine belong to the same network segment;
  • the second method is to determine whether the VXLAN (Virtual Extensible Local Area Network) identifier of the first virtual machine is the same as the VXLAN identifier of the second virtual machine, and if the same, the first virtual machine is The second virtual machine belongs to the same network segment.
  • VXLAN Virtual Extensible Local Area Network
  • the probability of applying the topology relationship between the virtual machines on the same network segment is larger than that of the virtual machines on different network segments. Therefore, in the embodiment of the present invention, the frequency of interaction between virtual machines on the same network segment is weighted or the preset frequency is decreased. To increase the accuracy of the application topology relationship discovery.
  • the API call information may be saved in a log file on the deployment host of the first virtual machine and the second virtual machine,
  • the topology discovery server reads the API call information from the log file.
  • a proxy module is installed on each host, and the topology discovery server receives the API call information reported by the proxy module of the host.
  • the API call information is written to the log file, and the following methods may be used:
  • the virtual machine invokes the API to send a message to the VMM where the virtual machine is located, the virtual machine, the virtual switch in the VMM, or the VMM writes the API call information to the log on the deployment host of the virtual machine.
  • the proxy module on the deployment host of the virtual machine monitors the transmission process of the packet on the host, and writes the API call information corresponding to the API call in the transmission process to the log file on the deployment host of the virtual machine;
  • the proxy module on the deployment host of the virtual machine receives the API call information corresponding to the API call in the message transmission process of the virtual machine, the virtual switch, or the VMM, and writes the received API call information to the In the log file on the deployment host of the virtual machine; or,
  • any one of the virtual machine, the virtual switch in the VMM, or the VMM may write the API call information to the deployment host of the virtual machine. In the log file.
  • any one of the virtual machine, the virtual switch, or the VMM on the host may report the API call information to the proxy module by calling a topology reporting API function.
  • a proxy module is installed on each host to collect API call information on the host, and the proxy module can monitor the virtual machine, the virtual switch, and the VMM on the host to obtain API call information. And the obtained API call information is written to the log file; or, after the proxy module obtains the API call information, it is reported to the topology discovery server.
  • the API call includes an input API function call and an output API function call.
  • the VMM in which the virtual machine is located calls the output API function to send a message to the virtual machine; the virtual machine invokes the input API function to send a message to the VMM where the virtual machine is located.
  • the API call information may further include a source virtual machine identifier and a destination virtual machine identifier. At this time, according to a set of API call information, it may be known that the source virtual machine and the destination virtual machine have one interaction.
  • the topology discovery server determines an application topology relationship between the virtual machines in the virtual machine cluster, and generates an application topology view of the virtual machine cluster.
  • the topology discovery server is an independent physical server; or the topology discovery server is combined with other physical servers in the system in the form of functional modules.
  • a virtual machine that specifically applies a topology relationship may run on the same host or on a different host.
  • the two hosts transmit the message over an external physical network.
  • the specific transmission method may adopt various existing network transmission protocols and transmission settings, and the network structure corresponding to the transmission in this application is not limited.
  • the embodiment of the present invention provides another method for applying the topology relationship discovery, which is different from the foregoing method for applying the topology relationship discovery.
  • the identifier of the virtual machine in each group of API information recorded in this embodiment includes The identifier of the source virtual machine at the sending end of the packet also includes the identifier of the destination virtual machine at the receiving end of the packet.
  • the API call information is obtained, where the API call information includes an identifier of the source virtual machine and an identifier of the destination virtual machine, where the API call information corresponds to one API call; and it is determined that the source virtual machine and the destination virtual machine exist once.
  • the interaction is performed; the collected API call information is analyzed, and according to the frequency of interaction between the first virtual machine and the second virtual machine, an application topology relationship exists between the first virtual machine and the second virtual machine.
  • an embodiment of the present invention provides a topology discovery server, where the topology discovery server specifically implements the functions in the foregoing method.
  • the functions may be implemented by hardware or by corresponding software implemented by hardware.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the topology discovery server includes a processor and a memory configured to support the topology discovery server to perform the corresponding functions in the above methods.
  • the topology discovery server can also include a memory for coupling with the processor that holds program instructions and data necessary for the topology discovery server to perform the functions described above.
  • the embodiment of the present invention provides a system for applying topology discovery, including a topology discovery server and at least one host, where the at least one host runs multiple virtual machines, and the topology discovery server obtains a packet transmission process.
  • the API call information generated by the API is used to determine whether there is an application topology relationship between the two virtual machines.
  • the topology discovery server, the virtual machine, the proxy module, and the like perform the functions in the method for applying the topology relationship discovery in the first aspect.
  • the functions may be implemented by hardware or by corresponding software implemented by hardware.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the system for performing the method for applying the topology relationship discovery may further include a database, configured to store the application topology relationship and apply the topology view.
  • the system may further include a management node, and the management root node manages the virtual machine according to an application topology relationship between the virtual machines, thereby providing management efficiency.
  • the host includes a processor and a memory configured to support the host in performing the corresponding functions in the system described above.
  • the host can also include a memory for coupling with the processor that holds program instructions and data necessary for the processor to perform the functions described above.
  • an embodiment of the present invention provides a computer storage medium for storing computer software instructions used by the topology discovery server, which includes a program designed to perform the above aspects.
  • an embodiment of the present invention provides a computer storage medium for storing computer software instructions for use by the host, including a program designed to perform the above aspects.
  • the method, device and system for applying topological relationship discovery collect API call information during message transmission, and determine two virtual machines corresponding to two sets of API call information by matching whether two sets of API call information meet the first condition.
  • the topology discovery server can determine the interaction frequency between the virtual machines involved in the collected API call information, and determine the application topology relationship between the virtual machines according to the interaction frequency between the virtual machines.
  • the above solution provides a method for discovering the application topology relationship between virtual machines in a virtualization scenario.
  • the application topology information between virtual machines is determined by analyzing the API call information generated during the packet transmission process, and the solution complexity is low.
  • FIG. 1A is a schematic structural diagram of a possible virtualization system according to an embodiment of the present invention.
  • FIG. 1B is a schematic structural diagram of still another virtualization system according to an embodiment of the present disclosure.
  • FIG. 1C is a schematic structural diagram of still another virtualization system according to an embodiment of the present invention.
  • FIG. 2 is a schematic diagram of a computer device according to an embodiment of the present invention.
  • 3A is a schematic diagram of a virtualization structure on a host according to an embodiment of the present invention.
  • FIG. 3B is a schematic diagram of a virtualization structure on a host in a NIC passthrough scenario according to an embodiment of the present disclosure
  • FIG. 3C is a schematic diagram of a virtualization structure on a host in another NIC passthrough scenario according to an embodiment of the present disclosure
  • FIG. 4 is a schematic diagram of an acquisition proxy obtaining API call information by means of active discovery according to an embodiment of the present invention
  • FIG. 5 is a schematic diagram of an acquisition proxy obtaining API call information by means of passive discovery according to an embodiment of the present invention
  • FIG. 6 is a schematic flowchart of acquiring API call information by an acquisition agent when communicating between two virtual machines on the same host according to an embodiment of the present invention
  • FIG. 7 is a schematic flowchart of acquiring API call information by an acquisition agent when communicating between two virtual machines on different hosts according to an embodiment of the present disclosure
  • FIG. 8 is a schematic structural diagram of an application topology relationship discovery system according to an embodiment of the present disclosure.
  • FIG. 9 is a schematic structural diagram of a topology discovery server according to an embodiment of the present invention.
  • the network architecture and the service scenario described in the embodiments of the present invention are used to more clearly illustrate the technical solutions of the embodiments of the present invention, and do not constitute a limitation of the technical solutions provided by the embodiments of the present invention.
  • the technical solutions provided by the embodiments of the present invention are equally applicable to similar technical problems.
  • the method for discovering application topology relationships between virtual machines in a virtualized environment is provided, and the method and device for discovering application topology relationships between virtual machines in a virtualized environment are provided.
  • the system can accurately identify the application topology relationship among VMs in a VM cluster.
  • the embodiment of the present invention provides a topology discovery server, which is used to collect call information of an API (Application Programming Interface) when communicating between virtual machines on each host.
  • the topology discovery server analyzes the API call information collected from each host to generate an application topology relationship between the virtual machines.
  • FIG. 1A a schematic diagram of a virtualization system architecture is provided.
  • the topology discovery server is connected to each host to collect API call information on each host, and the topology discovery server can also connect the virtual machine.
  • the application topology relationship is stored in the database.
  • the management node needs to perform the management operation according to the application topology relationship between the virtual machines, the management node acquires the application topology relationship between the virtual machines.
  • the functions of the various components shown in FIG. 1A are as follows:
  • Each host is a physical server running on a number of virtual machines.
  • the Collect Agent is deployed on the host to collect API call information generated when each virtual machine, virtual machine switch, or virtual machine monitor (VMM) on the host delivers packets.
  • the collection agent sends the collected API call information to the topology discovery server (Topology Discovery Server), and the topology discovery server analyzes the collected API information, and finally obtains the application topology relationship between the virtual machines.
  • the collection agent can monitor the virtual machine, the virtual switch, or the VMM (Virtual Machine Monitor) on the host.
  • the API call information is recorded; or, by the virtual machine or the virtual machine.
  • the switch or VMM sends or receives a packet, it reports the API call information to the collection agent.
  • the collected API call information may be sent to the topology discovery server periodically or at other suitable times (eg, when the host or the network is idle).
  • the collection agent may actively push the API call information to the topology discovery server, or passively receive the request of the topology discovery server and then push the API call information to the topology discovery server; or the collection agent stores the API call information.
  • the storage space shared with the topology discovery server is read autonomously by the topology discovery server.
  • the embodiment of the present invention does not limit the specific manner of API call information transmission between the collection agent and the topology discovery server, as long as the topology discovery server can obtain the API call information on each host.
  • the foregoing collection agent is optional.
  • the virtual machine, the virtual switch, or the VMM may report the API call information to the topology discovery server in a manner similar to the collection agent.
  • the topology discovery server collects API call information from each host connected to it, analyzes the collected API call information, and obtains the application topology relationship between the virtual machines and stores them in the database. Further, the topology discovery server may generate an application topology view according to the applied topology relationship between the obtained virtual machines.
  • Each group of API call information includes: the virtual machine ID, the time when the API call occurs, and the flow of the packet.
  • the virtual machine identifier is the identifier of the virtual machine that receives or sends the packet.
  • the time of the API call is the time when the API call is executed.
  • the packet flow direction includes input or output.
  • the input means that the packet is sent by the virtual machine to the VMM.
  • the output means that the message is output to the virtual machine by the VMM.
  • the time of the API call can also be the time of logging, the duration of the entire call, or the time when the call was detected.
  • Each set of API call information may further include a communication protocol, which is a communication protocol used by the virtual machine to communicate, and the communication protocol may be a HyperText Transfer Protocol (HTTP) or a User Datagram protocol (User Datagram). Protocol, UDP protocol, Transmission Control Protocol/Internet Protocol (TCP/IP), etc.; the virtual machine identifier can be the IP address of the virtual machine.
  • the API call information is (VM1, t1, P1, In), indicating that VM1 invokes the input function to transfer the message to the virtual switch VSwitch or VMM by using the protocol P1 at time t1; the API call information is (VM2, t2, P2). , Out), indicating that the virtual switch or VMM invokes the output function to send a message to VM2 at protocol t2 at time t2.
  • the packet transmission does not pass through the virtual switch, but is transmitted to the physical network card through the VMM.
  • the topology discovery server analyzes the API call information collected from each host, identifies the frequency of interaction between the virtual machines, and determines the application topology relationship between the virtual machines.
  • the API for the API call information is an input API function and an output API function.
  • the source virtual machine sends a packet to the destination virtual machine.
  • the same protocol is used, and the source virtual machine invokes the API to send the packet with the time Ts and the destination virtual.
  • the time Te of the API call of the machine receiving the message is within an acceptable custom preset threshold, and the source virtual machine and the destination virtual machine are considered to have one interaction. Further, if the frequency of interaction between the two virtual machines is greater than the preset frequency within a certain period of time, it is determined that there is an application topology relationship between the two virtual machines.
  • API call information collected by the topology discovery server is as follows:
  • VMn Timen, protocol, In
  • VMn' Timen', protocol, Out
  • the topology discovery server analyzes the foregoing API call information, and determines first API call information and second API call information that meet the first condition, where the first API call information and the second API call information satisfy the first condition
  • the method includes: the flow of the message in the first API call information flows in the opposite direction to the flow in the second API call information, and the occurrence time of the API call in the first API call information is The difference between the occurrence time of the API call in the second API call information is less than or equal to a preset threshold; and satisfying the foregoing first condition means that two of the first API call information and the second API call information
  • the virtual machine has an interaction, and determining whether the frequency of interaction between the first virtual machine indicated by the first API call information and the second virtual machine indicated by the second API call information satisfies the second condition; The frequency of the interaction between the first virtual machine and the second virtual machine meets the second condition, and the application topological relationship exists between the first virtual machine and the second virtual machine.
  • the above analysis process gives a method for the topology discovery server to determine the application topology relationship between the virtual machines according to the API call information. Specifically, when considering the communication protocol, the analysis process can be summarized into the following three judgment processes:
  • Judgment 1 The flow of messages in the two sets of API call information is input and output respectively;
  • Judgment 3 The difference between the occurrence times of the API calls in the two sets of API call information is less than or equal to a preset threshold (that is, the second condition described above).
  • VM1 and VM1' have an interaction.
  • the embodiment of the present invention does not limit the topology discovery server to perform the above three determination processes at the same time, and the topology discovery server may perform the foregoing three determination processes in different orders according to requirements.
  • the topology discovery server may first filter the API call information according to the occurrence time of the API call, select the API call information that meets the judgment 3, and further The API call information of the judgment one is filtered out, and the frequency of interaction between the virtual machines in which the interaction relationship is finally selected in the API call information is determined, thereby The application topology relationship between virtual machines.
  • the API call information may not include the communication protocol, and accordingly, The topology discovery server also does not need to determine whether the communication protocols in the two sets of API call information are the same. At this time, the efficiency of applying the topology relationship discovery is improved, and the accuracy may be lowered.
  • the threshold value in the third determination may be set according to the requirements.
  • the actual network load situation may be considered, which is not limited by the embodiment of the present invention.
  • the topology discovery server traverses the collected API call information to obtain the interaction frequency between any two virtual machines. When the interaction frequency is greater than the preset frequency, the application topology relationship is considered between the two virtual machines.
  • the topology discovery server stores the application topology relationship between the virtual machines in the database. It should be noted that the topology discovery server can traverse the API call information of the API call occurring in a certain period of time, and the number of interactions between the obtained virtual machines is used as the interaction frequency, and the duration of the time period can be set according to requirements.
  • the preset frequency can also be set according to needs. This embodiment of the present invention does not limit this.
  • the virtual machine identifier in the API call information may include both the source virtual machine identifier and the destination virtual machine identifier.
  • a set of API call information records may be determined. There is an interaction between the source virtual machine and the destination virtual machine.
  • the present application in order to ensure the calculation efficiency, whether the API call information includes the identifier of the communication party or only the identifier of the communication party, the present application can determine whether there is interaction between the virtual machines according to the above analysis method, that is, the flow of the message is input.
  • API call information using only the API of the source virtual machine in the API call information
  • the three judgment processes are used to determine whether there is interaction between the virtual machines, and the format of the two API call information is not separately calculated, which can effectively improve the efficiency of the analysis.
  • Management node A functional entity that needs to obtain the network topology of a virtual machine for VMware Vcenter, FusionManager, and so on.
  • the management node reads the application topology relationship from the topology discovery server or the above database.
  • the topology discovery server can be a separate physical server, or the topology discovery server can be combined as a functional module with other physical servers such as management nodes.
  • FIG. 1B is a schematic diagram of another virtualization system architecture provided by an embodiment of the present invention. The difference from FIG. 1A is that the host does not include a collection proxy, but the VM, the virtual machine switch, or the VMM invokes the API. Stored in a log file or sent directly to the topology discovery server.
  • FIG. 1C is a schematic diagram of another virtualization system architecture provided by an embodiment of the present invention.
  • the topology discovery server and the management node are combined, and the function of the foregoing topology discovery server is implemented by a topology discovery module in the management node. .
  • the virtualization architecture shown in FIG. 1B and FIG. 1C is an improvement on the basis of FIG. 1A.
  • the functions of the components in the virtualization architecture are similar to those of FIG. 1A, and the API call information can also be implemented according to the adaptability of the architecture change.
  • the functions of the components in FIG. 1B and FIG. 1C will not be described again in the embodiments of the present invention.
  • the application of topology relationships has a wide range of uses. For example, virtual machines belonging to the same application topology cluster should be placed in the network covered by the same switch or in a similar network to save interaction time. If you need to upgrade the virtual machine clusters in the system in batches, The virtual machines of the same application topology cluster should be upgraded in the same batch as possible; the virtual machine clusters with application topology should be placed on the same server or the nearest server; the virtual machine cluster with application topology relationship and the corresponding backup The cluster should be on different servers; when migrating, you should try to migrate the virtual machines corresponding to the entire application topology cluster. When the management node performing the above functions needs to use the application topology of the virtual machine, it can be obtained from the topology discovery server.
  • the collection agent and the topology discovery server may be implemented by hardware/software.
  • FIG. 2 it is a schematic diagram of a computer device provided by an embodiment of the present invention.
  • the computer device 200 includes at least one processor 201, a communication bus 202, a memory 203, and at least one communication interface 204.
  • the processor 201 can be a general purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present invention.
  • CPU central processing unit
  • ASIC application-specific integrated circuit
  • Communication bus 202 can include a path for communicating information between the components described above.
  • the communication interface 304 using any A device such as a transceiver for communicating with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Networks (WLAN), and the like.
  • a device such as a transceiver for communicating with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Networks (WLAN), and the like.
  • RAN Radio Access Network
  • WLAN Wireless Local Area Networks
  • the memory 203 can be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type that can store information and instructions.
  • the dynamic storage device can also be an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Compact Disc Read-Only Memory (CD-ROM) or other optical disc storage, and a disc storage device. (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or can be used to carry or store desired program code in the form of instructions or data structures and can be Any other media accessed, but not limited to this.
  • the memory can exist independently and be connected to the processor via a bus.
  • the memory can also be integrated with the processor.
  • the memory 203 is used to store application code for executing the solution of the present invention, and is controlled by the processor 201 for execution.
  • the processor 201 is configured to execute application code stored in the memory 203.
  • processor 201 may include one or more CPUs, such as CPU0 and CPU1 in FIG.
  • computer device 200 can include multiple processors, such as processor 201 and processor 208 in FIG. Each of these processors can be a single-CPU processor or a multi-core processor.
  • a processor herein may refer to one or more devices, circuits, and/or processing cores for processing data, such as computer program instructions.
  • computer device 200 may also include an output device 205 and an input device 206.
  • Output device 205 is in communication with processor 201 and can display information in a variety of ways.
  • the output device 205 can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector.
  • Input device 206 is in communication with processor 201 and can accept user input in a variety of ways.
  • input device 206 can be a mouse, keyboard, touch screen device or sensing device, and the like.
  • the computer device 200 described above can be a general purpose computer device or a special purpose computer device.
  • the computer device 200 can be a desktop computer, a portable computer, a network server, a personal digital assistant (PDA), a mobile phone, a tablet, a wireless terminal device, a communication device, an embedded device, or have FIG. A device of similar structure.
  • Embodiments of the invention do not limit the type of computer device 200.
  • the collection agent, host and topology discovery server in Figures 1A, 1B and 1C can be the device shown in Figure 2, storing One or more software modules are stored in the device for implementing functions of the collection agent, host, and topology discovery server (for example, API call information analysis function in the topology discovery server, etc.).
  • the collection agent, host, and topology discovery server can implement the method of application topology discovery between virtual machines through the processor and the program code in the memory.
  • the computer device shown in FIG. 2 only gives possible hardware implementation manners of various parts in the application topology discovery system, and may add or delete hardware components of the computer device according to different functions or changes of various parts of the system. To match the functionality of the various parts of the system.
  • FIG. 3A is a schematic diagram of a virtualization structure on a host provided by an embodiment of the present invention.
  • the host is a physical server.
  • the bottom layer of the physical server is the hardware layer.
  • the hardware layer mainly includes hardware resources such as a central processing unit (CPU), memory, hard disk, and network card.
  • Server virtualization is a virtualized operating environment for multiple virtual machines (VMs) on a physical server with virtualization software such as VMWare ESX and Citrix XEN.
  • the software layer that is installed on the server to implement the virtualized environment is called VMM.
  • the VMM running on top of the hardware layer assumes the scheduling, allocation, and management of hardware resources in the hardware layer. Multiple virtual machine VMs are run on the VMM.
  • the VMM provides virtualized CPU, memory, storage, IO devices (such as network cards) and Ethernet switches for each virtual machine to ensure that multiple virtual machines run in isolation.
  • the VMM creates a virtual network interface card (vNIC) for each virtual machine.
  • the virtual switch VSwitch provides communication between virtual machines and between virtual machines and external networks.
  • the virtual NIC of each virtual machine corresponds to a logical port of the VSwitch.
  • the physical NIC of the host corresponds to the port that the VSwitch connects to the external physical switch.
  • the process of receiving the virtual machine packet is as follows: The VSwitch receives the Ethernet packet from the physical NIC, and then the virtual machine media access control (MAC) address and the VSwitch logical port mapping table (that is, the static MAC table). To forward the message.
  • MAC virtual machine media access control
  • VPON packet sending process When the MAC address of the packet is on the external network, the VSwitch sends the packet directly from the physical NIC to the external network. When the destination MAC address of the packet is connected to the VM on the same VSwitch, the VSwitch is used. The packet is forwarded through a static MAC table.
  • FIG. 3B a schematic diagram of a virtualization structure on a host in a NIC pass-through scenario is provided.
  • the physical NIC does not perform a virtual machine, and each egress port of the physical NIC is assigned to a virtual machine.
  • FIG. 3C is a schematic diagram of a virtualization structure on a host in another NIC passthrough scenario according to an embodiment of the present invention.
  • the difference between FIG. 3B and the physical NIC is virtualized by the virtual machine as multiple virtual function devices.
  • Virtual Function (VF) the above NIC virtualization technology can be Single-Root I/O Virtualization (SR-IOV) and multiple roots.
  • IO Virtualization Multi-Root I/O Virtualization, MR-IOV).
  • Each virtual function device can share physical resources (such as a network card port) of the physical network card, and each virtual function device can also be associated with the virtual machine system on the host.
  • the method for discovering the application topology relationship is also applicable to the scenario shown in FIG. 3B and FIG. 3C.
  • the virtual machine can directly invoke the outgoing interface of the physical network card to deliver the packet, thereby bypassing the virtual in the VMM. switch.
  • the proxy module can obtain API call information from the virtual machine or VMM.
  • the virtual machine or the VMM may record the API call information into the log file or directly to the collection agent;
  • the collection agent monitors the transmission of packets between the virtual machine, the VMM, and the physical network card, and records the API call information into the log file.
  • the collection agent can use active discovery or passive discovery of two acquisition API call information.
  • FIG. 4 it is a schematic diagram of an acquisition proxy that obtains API call information in the form of active discovery according to an embodiment of the present invention.
  • FIG. 5 a schematic diagram of obtaining, by a collection agent, API call information by means of passive discovery according to an embodiment of the present invention.
  • the active discovery means that when the virtual machine calls the input API function (Port_Input API), the virtual machine, the virtual switch or the VMM writes the API call information to the log log file, or when the virtual switch calls the output API function (Port_Output API).
  • the virtual machine, the virtual switch, or the VMM writes the API call information to the log file.
  • the collection agent can obtain the API call information by scanning the log file.
  • the passive discovery means that the topology information of the API information reported to the collection agent is newly reported.
  • API function Topic_Info_API
  • the virtual machine calls the input API function (Port_Input API) to transmit the message through the VMM
  • the virtual machine, virtual switch or VMM calls the topology information report API function, and sends the API call information of the call to the collection agent.
  • the virtual switch invokes the output API function (Port_Output API)
  • the virtual machine, the virtual switch, or the VMM invokes the topology information reporting API function, and sends the API call information of the current call to the collection agent.
  • API functions can be found through the API function tool list.
  • the "Windows API Function Reference Manual” published by People's Posts and Telecommunications Press is a reference manual for Microsoft Win32 API functions.
  • Other versions and other types of operating systems can also be related. Find the corresponding input API function and output API function in the tool book.
  • API call information in the log file is only an example, and the API call information can be stored in other files or other locations, and the collection agent can acquire it.
  • the topology discovery server collects API call information from each host, and each set of API call information corresponds to one API call.
  • the API call specifically includes an input API function call and an output API function call, wherein the report
  • the source virtual machine of the text sending end calls the input API function to deliver the message to the VMM.
  • the VMM transmits the packet to the VMM of the receiving end of the packet through the network, and the VMM of the receiving end of the packet calls the output API function to send the packet to the destination virtual machine.
  • the host at the sending end of the message and the host at the receiving end of the message record a set of API call information, and each set of API call information includes the identifier of the virtual machine corresponding to the API call, the time when the API call occurs, and the API call.
  • the flow of the message may also include a communication protocol.
  • the topology discovery server analyzes the collected API call information, when the difference between the occurrence times of the API calls in the two sets of API call information is less than a preset threshold, and the flow of the packets in the two sets of API call information is opposite to each other (a If there is an input, the other one is the output), there is an interaction relationship between the two virtual machines corresponding to the two virtual machine identifiers in the two sets of API call information, thereby determining the frequency of interaction between the two virtual machines.
  • the interaction frequency between the first virtual machine and the second virtual machine meets the second condition, and the application topological relationship exists between the first virtual machine and the second virtual machine.
  • determining an interaction frequency between the first virtual machine and the second virtual machine comparing the interaction frequency and a preset frequency, and when the interaction frequency is greater than a preset frequency, determining that the interaction frequency meets the Second condition.
  • the two virtual machines corresponding to the two virtual machine identifiers in the two sets of API call information are different.
  • the above solution provides a method for discovering the application topology relationship between virtual machines in a virtualization scenario.
  • the application topology information between virtual machines is determined by analyzing the API call information generated during the packet transmission process, and the solution complexity is low.
  • FIG. 6 is a schematic diagram of a process of acquiring an API call information by a collection agent when communicating between two virtual machines on the same host according to the embodiment of the present invention.
  • the collection agent runs in the host as a function module of the host.
  • the host runs VM1 and VM2 (in the embodiment of the present invention, two VMs are taken as an example), the virtual network card of VM1 is vNIC1, and the virtual network card of VM2 is vNIC2.
  • the port on the virtual switch corresponding to vNIC1 is Port1, and the port on the VM switch corresponding to vNIC2 is Port2.
  • the virtual network card is allocated to the virtual machine, and the corresponding relationship between the virtual network card and the virtual switch port is not mentioned in detail in the embodiment of the present invention.
  • the method shown in Figure 6 includes:
  • Step 601 When VM1 needs to send a message to VM2, VM1 invokes the input API function (Port_Input API) of the VMM, and sends the message to Port1 of the virtual switch through vNIC1;
  • VM1 invokes the input API function (Port_Input API) of the VMM, and sends the message to Port1 of the virtual switch through vNIC1;
  • Step 602 The virtual switch determines the destination MAC address of the packet to determine the port of the virtual switch corresponding to VM2 as Port2 by searching the static MAC address table.
  • the virtual switch broadcasts the message of VM1, and sends the message of VM1 to all VMs under the virtual machine switch by means of broadcast.
  • VM2 can receive the message of VM1 and return a response.
  • Step 603 The virtual switch invokes an output API function (Port_Output API), and sends the packet to the virtual network card vNIC2 of the VM2 through the port 2, and the VM2 receives the packet sent by the VM1.
  • an output API function (Port_Output API)
  • step 601 in view of the VM1 calling the input API function, an API call occurs, so the API call information needs to be recorded, and VM1 can record the API call information in two ways:
  • Method 1 The interface between the VM1 and the collection agent is reported, and the API call information is reported. Specifically, the VM1 invokes the topology report API function (Topo_Info API) of the collection agent, and sends the API call information to the collection agent. It should be noted that the embodiment of the present invention does not limit the timing at which the VM1 sends the API call information to the collection proxy. Alternatively, the VM1 may send the API call information when the network is under load.
  • Topo_Info API topology report API function
  • VM1 writes the API call information to a log file, which is read by the collection agent. It should be noted that, in the embodiment of the present invention, the timing for obtaining the API call information from the log file by the collection agent is not limited. Alternatively, the collection agent may periodically read from the log file or the VM1 is in the API call information. Notify the collection agent to read after writing the log file.
  • the virtual machine switch or the VMM may also record the API call information. Specifically, when the virtual switch or the VMM receives the message sent by the VM1, the API call information is written to The log file is either sent to the collection agent.
  • the API call information includes a virtual machine identifier, an occurrence time of an API call, a communication protocol, and a packet flow direction.
  • the virtual machine identifier in the API call information may include the source virtual machine identifier and the destination virtual machine identifier.
  • the source virtual machine and the destination virtual machine may be directly identified according to only one API call information.
  • An interaction It should be noted that when the VM1 knows the address of the communication peer VM2, the source virtual machine identifier and the destination virtual machine identifier may be included in the recorded API call information.
  • the above communication protocol may be an HTTP protocol, a TCP/IP protocol, a UDP protocol, or the like.
  • step 603 since the virtual switch invokes the output API function (Port_Output API), an API call occurs, and therefore, the API call information needs to be recorded. Similar to VM1, a virtual switch can also record API call information in two ways:
  • Manner 1 The virtual switch invokes an interface between the virtual agent and the collection agent, and reports the API call information. Specifically, the virtual switch invokes the topology report API function (Topo_Info API) of the collection agent, and sends the API call information to the collection agent. It should be noted that the embodiment of the present invention does not limit the timing at which the virtual switch sends the API call information to the collection agent.
  • the implementation of the topology reporting API function may use a HOOK function or modify the code as long as the API call information can be provided.
  • Manner 2 The virtual switch writes the API call information to a log file, and is read by the collection agent. It should be noted that the timing of obtaining the API call information from the log file by the collection agent is not limited in the embodiment of the present invention.
  • the API call information may be recorded by the virtual machine (VM2) or the VMM, which is not described in the embodiment of the present invention.
  • FIG. 6 shows a process in which the acquisition agent acquires API call information when two virtual machines on the same host communicate.
  • FIG. 7 a schematic diagram of a process of acquiring API call information by a collection agent when communicating between two virtual machines on different hosts according to an embodiment of the present invention is shown in FIG. 7 .
  • the two hosts can adopt the virtualization structure shown in Figure 3A, and the hosts are connected by physical switches.
  • VM1 and virtual switch 1 are running on the host 1
  • VM2 and virtual switch 2 are running on the host 2.
  • the virtual network card of VM1 is vNIC1
  • the virtual network card of VM2 is vNIC2.
  • the port on virtual switch 1 is Port1
  • the port on VM switch 2 corresponding to vNIC2 is Port2.
  • the virtual network card is allocated to the virtual machine, and the corresponding relationship between the virtual network card and the virtual switch port is not mentioned in detail in the embodiment of the present invention.
  • the method shown in Figure 7 includes:
  • Step 701 When VM1 needs to send a message to VM2, VM1 invokes the input API function (Port_Input API) of VMM, and sends the message to Port1 of virtual switch 1 through vNIC1;
  • VM1 invokes the input API function (Port_Input API) of VMM, and sends the message to Port1 of virtual switch 1 through vNIC1;
  • Step 702 The virtual switch 1 receives the packet on the port 1 and determines the destination MAC address of the packet.
  • the virtual switch 1 sends the packet to the external network through the physical network card of the host 1;
  • Step 703 The packet is routed to the physical network card of the host where the VM2 is located according to the existing packet forwarding rule.
  • Step 704 The host 2 receives the packet by using its own physical network card.
  • Step 705 The virtual switch 2 determines that the port corresponding to the VM2 is Port2, and the virtual switch 2 sends the packet to the virtual network card vNIC2 of the VM2 through the port Port2.
  • VM2 receives the message sent by VM1.
  • the packet may be encapsulated and decapsulated according to the existing rules, which is not repeatedly described in the embodiment of the present invention.
  • VM1 records the API call information in a manner similar to that defined in step 601.
  • the collection agent of host 1 acquires API call information.
  • step 705 the virtual switch 2 records the API call information in the manner defined in step 603.
  • the collection agent of host 2 obtains API call information.
  • the embodiment of the present invention may adopt a distributed virtual machine switch.
  • the distributed virtual switch may span multiple hosts, so that the virtual machines on multiple hosts are connected to the same virtual machine switch.
  • the virtual machine may be in the above manner. Multiple hosts can be migrated, or multiple distributed virtual switches can exist on a single host.
  • distribution In the case of a virtual switch, the manner in which the collection agent obtains the API call information is similar to the foregoing, and is not described herein again.
  • the virtual machine or the virtual switch can directly report the API call information to the topology discovery server in the manner defined in FIG. 6 and FIG. 7 .
  • the method for applying the topology relationship discovery in the present application records the API call information in the message transmission process, and determines whether the two virtual machines corresponding to the two sets of API call information are determined by matching whether the two sets of API call information meet the first condition.
  • the topology discovery server may further determine the interaction frequency between the virtual machines involved in the collected API call information, and determine the application topology relationship between the virtual machines according to the interaction frequency between the virtual machines.
  • the system 80 includes a topology discovery server 81 and at least one host 82.
  • the at least one host 82 runs multiple virtual machines.
  • An application programming interface is generated when one of the plurality of virtual machines 822 sends a message or the VMM on the at least one host 82 forwards a message to one of the plurality of virtual machines 822 API call information;
  • the topology discovery server 81 is configured to collect at least two sets of application programming interface API call information, where each set of API call information corresponds to one API call, and each set of API call information includes an identifier of a virtual machine corresponding to the API call, and an occurrence of an API call. Time and message flow of the API call;
  • the topology discovery server 81 is further configured to analyze the at least API call information, determine first API call information and second API call information that meet the first condition, where the first API call information and the second API call
  • the information satisfying the first condition includes: the flow of the message in the first API call information flows in the opposite direction to the flow in the second API call information, and the first API call information
  • the difference between the occurrence time of the API call and the occurrence time of the API call in the second API call information is less than or equal to a preset threshold;
  • the topology discovery server 81 is further configured to determine whether the frequency of interaction between the first virtual machine 822 indicated by the first API call information and the second virtual machine 822 indicated by the second API call information satisfies And determining, if it is determined that the frequency of interaction between the first virtual machine 822 and the second virtual machine 822 meets the second condition, determining that the first virtual machine 822 and the second virtual machine 822 are present Apply topology relationships.
  • each group of API call information further includes a communication protocol; correspondingly, the first API call information and the second API call information satisfying the first condition further includes: the communication in the first API call information
  • the protocol is the same as the communication protocol in the second API call information.
  • the topology discovery server 81 is configured to analyze at least two sets of API call information of the first virtual machine 822 and at least two sets of API call information of the second virtual machine 822, and determine the first virtual machine 822 and Second virtual machine The frequency of interaction between the 822, comparing the interaction frequency and the preset frequency, and when the interaction frequency is greater than the preset frequency, determining that the interaction frequency satisfies the second condition.
  • the topology discovery server 81 is specifically configured to determine whether the first virtual machine 822 and the second virtual machine 822 belong to the same network segment, when the first virtual machine 822 and the second virtual machine 822 belong to When the same network segment is used, the interaction frequency or one of the preset frequencies is corrected according to a preset weighting coefficient, and the corrected interaction frequency is compared with the preset frequency; or the interaction frequency and the corrected pre-comparison are compared. Set the frequency.
  • the topology discovery server 81 is configured to separately read the at least two sets of API call information from log files on the deployment host 82 of the multiple virtual machines; or
  • the topology discovery server 81 is configured to receive the at least two sets of API call information reported by the proxy module on the deployment host of the multiple virtual machines.
  • the API call includes an input API function call and an output API function call.
  • the system 80 for applying topology discovery further includes:
  • the virtual machine 822 is further configured to write the API call information to the deployment host 82 of the virtual machine 822 when the calling API sends a message to the VMM where the virtual machine 822 is located or receives the message forwarded by the VMM.
  • the proxy file on the deployment host of the virtual machine 822 is used to write the API call information corresponding to the API call in the message transmission process to the log file on the deployment host 82 of the virtual machine 822. in.
  • a topology discovery server includes: an obtaining unit 91, configured to collect at least two sets of application programming interface API call information, and each group of API call information Corresponding to an API call, each set of API call information includes an identifier of a virtual machine corresponding to the API call, an occurrence time of the API call, and a packet flow direction of the API call;
  • the analyzing unit 92 is configured to analyze the at least two sets of application programming interface API call information, and determine first API call information and second API call information that meet the first condition, where the first API call information and the second
  • the first condition of the API call information is: the flow of the message in the first API call information flows in the opposite direction to the flow in the second API call information, and the first API call
  • the difference between the occurrence time of the API call in the information and the occurrence time of the API call in the second API call information is less than or equal to a preset threshold;
  • the analyzing unit 92 is further configured to determine whether an interaction frequency between the first virtual machine indicated by the first API call information and the second virtual machine indicated by the second API call information satisfies a second condition, If the frequency of the interaction between the first virtual machine and the second virtual machine meets the second condition, determining that an application topology relationship exists between the first virtual machine and the second virtual machine.
  • each group of API call information further includes a communication protocol; correspondingly, the first API call information and the second The API call information satisfying the first condition further includes: the communication protocol in the first API call information is the same as the communication protocol in the second API call information.
  • the analyzing unit 92 is configured to analyze at least two sets of API call information of the first virtual machine and at least two sets of API call information of the second virtual machine, to determine the first virtual machine and the second virtual
  • the frequency of the interaction between the machines compares the interaction frequency with the preset frequency. When the interaction frequency is greater than the preset frequency, it is determined that the interaction frequency satisfies the second condition.
  • the analyzing unit 92 is specifically configured to determine whether the first virtual machine and the second virtual machine belong to the same network segment, when the first virtual machine and the second virtual machine belong to the same network segment, Correcting the interaction frequency or one of the preset frequencies according to a preset weighting coefficient;
  • the analyzing unit 92 is specifically configured to compare the corrected interaction frequency with the preset frequency; or compare the interaction frequency with the corrected preset frequency.
  • the obtaining unit 91 is specifically configured to separately read the at least two sets of API call information from log files on the deployment host of the multiple virtual machines; or
  • the obtaining unit 91 is configured to receive the at least two sets of API call information reported by the proxy module on the deployment host of the multiple virtual machines.
  • the API call includes an input API function call and an output API function call.
  • the method, device and system for applying topological relationship discovery collect API call information during packet transmission, and determine two sets of API call information corresponding by matching two sets of API call information to meet the first condition.
  • the topology discovery server can determine the interaction frequency between the virtual machines involved in the collected API call information, and determine the application topology relationship between the virtual machines according to the interaction frequency between the virtual machines. .
  • the above solution provides a method for discovering the application topology relationship between virtual machines in a virtualization scenario.
  • the application topology information between virtual machines is determined by analyzing the API call information generated during the packet transmission process, and the solution complexity is low.
  • the virtual machine, the collection agent, the virtual switch, and the topology discovery server are presented in the form of functional units/function modules.
  • a "unit/module” herein may refer to an application-specific integrated circuit (ASIC), a circuit, a processor and memory that executes one or more software or firmware programs, integrated logic circuits, and/or the like.
  • ASIC application-specific integrated circuit
  • the device for the above functions may take the form shown in FIG.
  • the acquisition unit 901 and the processing unit 902 can be implemented by the processor and memory of FIG.
  • An embodiment of the present invention further provides a computer storage medium for storing computer software instructions for use in the apparatus shown in Figures 8 and 9 above, including a program designed to execute the above method embodiments. By executing the stored program, A method for applying topology relationship discovery can be implemented.
  • embodiments of the present invention can be provided as a method, apparatus (device), or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • the computer program is stored/distributed in a suitable medium, provided with other hardware or as part of the hardware, or in other distributed forms, such as over the Internet or other wired or wireless telecommunication systems.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.

Abstract

一种应用拓扑关系发现的方法，涉及IT技术领域，尤其涉及虚拟机间的应用拓扑关系发现的方法、装置和系统。该方法在报文传输过程中，记录下API调用信息，拓扑发现服务器通过分析收集到的API调用信息，确定虚拟机集群中的虚拟机之间是否存在交互，采用上述分析方式，拓扑发现服务器进而可以确定收集到的API调用信息所涉及的各虚拟机间的交互频率，根据各虚拟机间的交互频率确定虚拟机间的应用拓扑关系。上述方法给出了虚拟化场景下发现虚拟机间的应用拓扑关系的方法，通过分析报文传输过程中产生的API调用信息确定虚拟机间的应用拓扑关系，方案复杂度较低。

Description

应用拓扑关系发现的方法、装置和系统 技术领域
本发明涉及IT技术领域，尤其涉及应用拓扑关系发现方法、装置和系统。
背景技术
随着信息时代的到来，对计算机网络的依赖使得计算机网络本身运行的可靠性变得至关重要，对网络管理也就有了更高的要求。按照开放式系统互联(Open System Interconnection，OSI)的定义，网络管理主要包括五个功能域：故障管理、配置管理、性能管理、安全管理和计费管理。在五大功能域中，配置管理是基础，它的主要功能包括发现网络的拓扑结构、监视和管理网络设备的配置情况。其它的各项功能都以网络的拓扑结构为基础。网络拓扑发现针对的是网络中端到端之间的连接关系，主要目的是获取和维护网络节点的存在信息和它们之间的连接关系信息，并在此基础上绘制出整个网络拓扑图。
作为网络拓扑的一种具体形式，IT系统中的应用拓扑(Applied Topology)为虚拟机间的网络通信关系，虚拟机间的网络通信是基于虚拟机运行的应用产生的。更具体的来说，应用拓扑即为应用的部件(例如程序、服务、组件，运行该应用的虚拟机等)在IT系统各主机(例如服务器)上的部署关系以及所部署的应用的部件间的交互关系(例如服务请求与响应)。
现有的应用拓扑的发现为主动探测发现。主动探测是通过向网络目标发送相关探测数据包，观察并记录返回结果，以此来研究应用的结构和应用用户的行为。由于需要向网络发送大量的数据，会增加网络的负载，并且拓扑发现的准确性不高。现有技术中缺乏针对虚拟化环境下不采用探测数据包的应用拓扑发现的方法。
发明内容
本申请描述了一种应用拓扑关系发现的方法、装置和系统，提供了针对虚拟化环境的应用拓扑发现方案，降低了建立虚拟机间的应用拓扑关系的复杂度。
一方面，本申请提供了一种应用拓扑关系发现的方法，收集至少两组API调用信息，每组API调用信息对应一次API调用，所述每组API调用信息包括API调用对应的虚拟机的标识、API调用的发生时间以及API调用的报文流向；对上述收集到的API调用信息进行分析，确定满足第一条件的第一API调用信息与第二API调用信息，其中，所述第一API调用信息与第二API调用信息满足所述第一条件包括：所述第一API调用信息中的报文流向与所述第二API调用信息中的报文流向为互为相反的流向，且所述第一API调用信息中的API调 用的发生时间与所述第二API调用信息中的API调用的发生时间的差值小于或等于预设阈值；满足上述第一条件即意味着所述第一API调用信息和所述第二API调用信息中的两个虚拟机存在一次交互，进而确定所述第一API调用信息所指示的第一虚拟机和所述第二API调用信息所指示的第二虚拟机之间的交互频率是否满足第二条件；若所述第一虚拟机和所述第二虚拟机之间的交互频率满足所述第二条件，确定所述第一虚拟机和所第二虚拟机之间存在应用拓扑关系。
本申请给出的应用拓扑关系发现的方法，收集报文传输过程中API调用信息，通过匹配两组API调用信息是否满足第一条件确定两组API调用信息对应的两个虚拟机之间是否存在交互，采用上述方式，拓扑发现服务器可以确定收集到的API调用信息所涉及的各虚拟机间的交互频率，根据各虚拟机间的交互频率确定虚拟机间的应用拓扑关系。上述方案给出了虚拟化场景下发现虚拟机间的应用拓扑关系的方法，通过分析报文传输过程中产生的API调用信息确定虚拟机间的应用拓扑关系，方案复杂度较低。
在一种可能的实施方式中，除前述的报文流向和API调用的发生时间的差值外，还需要考虑API调用所涉及到的通信协议。具体的，所述每组API调用信息还包括通信协议；相应地，所述第一API调用信息与第二API调用信息满足所述第一条件还包括：所述第一API调用信息中的通信协议与所述第二API调用信息中的通信协议相同。即只有当两组API调用信息中的通信协议相同时，两组API调用信息对应的两个虚拟机才可能存在应用拓扑关系；当两组API调用信息中的通信协议不同时，即使满足报文流向和API调用的发生时间的差值的要求，也不能认为两组API调用信息对应的两个虚拟机存在交互。通过限定报文发送端和接收端的通信协议，提高了识别虚拟机间交互的准确度。
在一种可能的实施方式中，所述确定所述第一虚拟机和所述第二虚拟机之间的交互频率是否满足第二条件包括：分析所述第一虚拟机的至少两组API调用信息和所述第二虚拟机的至少两组API调用信息，确定所述第一虚拟机和所第二虚拟机之间的交互频率，比较所述交互频率和预设频率，当所述交互频率大于预设频率，确定所述交互频率满足所述第二条件。通过将预设频率作为虚拟机间是否存在应用拓扑关系的判断基准，本领域技术人员可以调整上述预设频率来控制应用拓扑关系认定的严格程度。所述预设频率也可以根据需要自行设定。本发明实施例对此并不进行限定。
在一种可能的实施方式中，在比较所述交互频率和预设频率之前，还包括：确定所述第一虚拟机与所述第二虚拟机是否属于相同的网段，当所述第一虚拟机与所述第二虚拟机属于相同网段时，根据预设的加权系数修正所述交互频率或所述预设频率之一；
所述比较所述交互频率和预设频率包括：比较修正后的交互频率与所述预设频率；或者，比较所述交互频率与修正后的预设频率。
在一种可能的实施方式中，拓扑发现服务器至少可以使用以下两种方式判断所述第一虚拟机与所述第二虚拟机是否属于相同的网段：
方式一、可以通过确定所述第一虚拟机的IP地址与所述第二虚拟机的IP地址是否属于同一网段；
方式二、确定所述第一虚拟机的VXLAN(Virtual eXtensible Local Area Network，虚拟可扩展局域网)标识与所述第二虚拟机的VXLAN标识是否相同，如果相同，则表示所述第一虚拟机与所述第二虚拟机属于同一网段。
同网段的虚拟机之间具备应用拓扑关系的概率较不同网段的虚拟机更大，因此，本发明实施例通过对同一网段的虚拟机间的交互频率进行加权或者降低预设频率，来增加应用拓扑关系发现的准确度。
在一种可能的实施方式中，报文从第一虚拟机发送到第二虚拟机的过程中，API调用信息可以保存在第一虚拟机和第二虚拟机的部署主机上的日志文件中，拓扑发现服务器从日志文件中读取API调用信息。或者，每个主机上安装有代理模块，拓扑发现服务器接收主机的代理模块上报的API调用信息。
在一种可能的实施方式中，在报文的传输过程中，API调用信息被写入到日志文件，可以采用以下几种方式：
在虚拟机调用API向所述虚拟机所在的VMM发送报文时，所述虚拟机、所述VMM中的虚拟交换机或所述VMM将API调用信息写入所述虚拟机的部署主机上的日志文件中；；
虚拟机的部署主机上的代理模块监控报文在所述主机上的传输过程，将所述传输过程中的API调用对应的API调用信息写入所述虚拟机的部署主机上的日志文件中；
虚拟机的部署主机上的代理模块接收所述虚拟机、虚拟交换机或者VMM在所述主机上的报文传输过程中的API调用对应的API调用信息，并将接收到的API调用信息写入所述虚拟机的部署主机上的日志文件中；或，
在虚拟机的VMM调用API向所述虚拟机发送报文时，所述虚拟机、所述VMM中的虚拟交换机或所述VMM任意之一可以将API调用信息写入所述虚拟机的部署主机上的日志文件中。
具体的，主机上的虚拟机、虚拟交换机或者VMM任意之一可以通过调用拓扑上报API函数向所述代理模块上报API调用信息。
在一种可能的实施方式中，每个主机上安装有代理模块，用于收集本主机上的API调用信息，代理模块可以监控本主机上的虚拟机、虚拟交换机以及VMM，获取API调用信息，并将获取的API调用信息写入日志文件；或者,在代理模块获取API调用信息后，上报给拓扑发现服务器。
在一种可能的实施方式中，所述API调用包括输入API函数调用和输出API函数调用。具体的，虚拟机所在的VMM调用输出API函数向虚拟机发送报文；虚拟机调用输入API函数向虚拟机所在的VMM发送报文。
在一种可能的实施方式中，API调用信息中还可以包括源虚拟机标识和目的虚拟机标识，此时，根据一组API调用信息即可获知源虚拟机和目的虚拟机存在一次交互。
进一步的，针对系统中的虚拟机集群，所述拓扑发现服务器确定虚拟机集群中各虚拟机间的应用拓扑关系，生成所述虚拟机集群的应用拓扑视图。
所述拓扑发现服务器为独立的物理服务器；或者，所述拓扑发现服务器以功能模块的形式与所述系统中其他物理服务器合设。
在一种可能的实施方式中，具体应用拓扑关系的虚拟机可以运行在同一主机上或不同主机上。当在不同主机上时，两个主机通过外部的物理网络传输所述报文。具体的传输方法可以采用现有的各种网络传输协议和传输设置，本申请对应传输的网络结构并不进行限定。
另一方面，本发明实施例提供了另一种应用拓扑关系发现的方法，与前述应用拓扑关系发现的方法不同的是，本实施例中记录的每组API信息中的虚拟机的标识既包括报文发送端的源虚拟机的标识，也包括报文接收端的目的虚拟机的标识，此时，根据一组API信息即可确定两个虚拟机之间存在一次交互。具体的，获取API调用信息，所述API调用信息包括源虚拟机标识和目的虚拟机的标识，所述API调用信息对应于一次API调用；确定所述源虚拟机和目的虚拟机之间存在一次交互；分析收集到的API调用信息，根据所述第一虚拟机和所述第二虚拟机之间的交互频率，确定所述第一虚拟机和所第二虚拟机之间存在应用拓扑关系。
再一方面，本发明实施例提供了一种拓扑发现服务器，该拓扑发现服务器具体实现上述方法中的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。
在一个可能的设计中，拓扑发现服务器的结构中包括处理器和存储器，所述处理器被配置为支持拓扑发现服务器执行上述方法中相应的功能。所述拓扑发现服务器还可以包括存储器，所述存储器用于与处理器耦合，其保存拓扑发现服务器执行上述功能所必要的程序指令和数据。
又一方面，本发明实施例提供了一种应用拓扑关系发现的系统，包括拓扑发现服务器以及至少一个主机，所述至少一个主机上运行有多台虚拟机，拓扑发现服务器通过获取报文传输过程中调用API产生的API调用信息判断两个虚拟机间是否存在应用拓扑关系。具体的，拓扑发现服务器、虚拟机、代理模块等等执行第一方面中应用拓扑关系发现的方法中的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或软件包括一个或多个与上述功能相对应的模块。
可选的，执行该应用拓扑关系发现的方法的系统还可以包括数据库，用于存储所述应用拓扑关系以及应用拓扑视图。所述系统还可以包括管理节点，所述管理根节点根据虚拟机间的应用拓扑关系对虚拟机进行管理，从而可以提供管理的效率。
在一个可能的设计中，主机包括处理器和存储器，所述处理器被配置为支持主机执行上述系统中相应的功能。所述主机还可以包括存储器，所述存储器用于与处理器耦合，其保存处理器执行上述功能所必要的程序指令和数据。
再一方面，本发明实施例提供了一种计算机存储介质，用于储存为上述拓扑发现服务器所用的计算机软件指令，其包含用于执行上述方面所设计的程序。
再一方面，本发明实施例提供了一种计算机存储介质，用于储存为上述主机所用的计算机软件指令，其包含用于执行上述方面所设计的程序。
本申请给出的应用拓扑关系发现的方法、装置和系统，收集报文传输过程中API调用信息，通过匹配两组API调用信息是否满足第一条件确定两组API调用信息对应的两个虚拟机之间是否存在交互，采用上述方式，拓扑发现服务器可以确定收集到的API调用信息所涉及的各虚拟机间的交互频率，根据各虚拟机间的交互频率确定虚拟机间的应用拓扑关系。上述方案给出了虚拟化场景下发现虚拟机间的应用拓扑关系的方法，通过分析报文传输过程中产生的API调用信息确定虚拟机间的应用拓扑关系，方案复杂度较低。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技 术描述中所需要使用的附图作简单地介绍。显而易见地，下面附图中反映的仅仅是本发明的一部分实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得本发明的其他实施方式。而所有这些实施例或实施方式都在本发明的保护范围之内。
图1A为本发明实施例提供的一种可能的虚拟化系统架构示意图；
图1B为本发明实施例提供的又一种虚拟化系统架构示意图；
图1C为本发明实施例提供的再一种虚拟化系统架构示意图；
图2为所示为本发明实施例提供的计算机设备示意图；
图3A为本发明实施例提供的一种主机上的虚拟化结构示意图；
图3B为本发明实施例提供的一种网卡直通场景下主机上的虚拟化结构示意图；
图3C为本发明实施例提供的另一种网卡直通场景下主机上的虚拟化结构示意图；
图4为本发明实施例提供的一种采集代理通过主动发现的形式获取API调用信息的示意图；
图5为本发明实施例提供的一种采集代理通过被动发现的形式获取API调用信息的示意图；
图6为本发明实施例提供的一种在同一主机上的两个虚拟机之间通信时，采集代理获取API调用信息的流程示意图；
图7为本发明实施例提供的一种在不同主机上的两个虚拟机之间通信时，采集代理获取API调用信息的流程示意图；
图8为本发明实施例提供的一种应用拓扑关系发现系统的结构示意图；
图9为本发明实施例提供的一种拓扑发现服务器的结构示意图。
具体实施方式
下面将结合附图，对本发明实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有付出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明实施例描述的网络架构以及业务场景是为了更加清楚的说明本发明实施例的技术方案，并不构成对于本发明实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本发明实施例提供的技术方案对于类似的技术问题，同样适用。
鉴于现有技术中缺乏在虚拟化层面专门针对虚拟化环境的应用拓扑关系发现的方法，本发明实施例提供了一种针对虚拟化环境下的虚拟机间的应用拓扑关系的发现方法、装置和系统，可以准确识别虚拟机集群中各虚拟机间的应用拓扑关系。具体的，本发明实施例提供了拓扑发现服务器，用于收集各主机上的虚拟机间通信时的API(Application Programming Interface,应用程序编程接口)的调用信息。拓扑发现服务器分析从各个主机收集的API调用信息，生成虚拟机间的应用拓扑关系。
如图1A所示，为本发明实施例提供的一种虚拟化系统架构示意图，拓扑发现服务器与各个主机相连，用于收集各个主机上的API的调用信息，拓扑发现服务器还可以将虚拟机间的应用拓扑关系存储在数据库中。当管理节点需要根据虚拟机间的应用拓扑关系执行管理操作时，管理节点获取上述虚拟机间的应用拓扑关系。具体的，图1A所示的各个组件的功能如下所述：
每台主机为一台物理服务器，主机上运行有若干个虚拟机。
采集代理：采集代理(Collect Agent)部署在主机上，用来收集本主机上的各虚拟机、虚拟机交换机或虚拟机监视器(Virtual Machine Monitor，VMM)传递报文时产生的API调用信息。采集代理把收集来的API调用信息发送给拓扑发现服务器(Topology Discovery Server)，由拓扑发现服务器对收集到的API信息进行分析，最终获得虚拟机间的应用拓扑关系。采集代理可以监控本主机上的虚拟机、虚拟交换机或VMM(Virtual Machine Monitor，虚拟机监视器)，当发现有报文被发送或接收时，记录下API调用信息；或者，由虚拟机、虚拟交换机或VMM在发送或接收报文后，向采集代理上报API调用信息。
在一个示例中，采集代理收集API调用信息后，可以周期性的或者在其他合适的时间(比如，在主机或者网络空闲的时候)将采集的API调用信息发送给拓扑发现服务器。
在另一个示例中，采集代理可以主动将API调用信息推送给拓扑发现服务器，或者被动的接收拓扑发现服务器的请求后再将API调用信息推送给拓扑发现服务器；或者，采集代理将API调用信息存放在某个与拓扑发现服务器共享的存储空间，由拓扑发现服务器自主读取。
需要说明的是，本发明实施例并不限定采集代理与拓扑发现服务器之间的API调用信息传递的具体方式，只要拓扑发现服务器可以获取各个主机上的API调用信息即可。
还需要说明的是，上述采集代理为可选，当主机上不存在采集代理时，可以由虚拟机、虚拟交换机或VMM采用与采集代理类似的方式向拓扑发现服务器上报API调用信息。
拓扑发现服务器：从与之相连的各个主机上收集API调用信息，并对收集到的API调用信息进行分析，得到虚拟机间的应用拓扑关系，并储存到数据库中。进一步的，拓扑发现服务器可以根据得到的虚拟机间的应用拓扑关系生成应用拓扑视图。
每组API调用信息包括：虚拟机标识、API调用的发生时间以及报文流向。其中，虚拟机标识为接收或发送报文的虚拟机的标识，API调用的发生时间是API调用被执行的时间，报文流向包括输入或输出，其中输入是指报文由虚拟机发送到VMM，输出是指报文由VMM输出到虚拟机。在一个示例中，API调用的发生时间还可以为记录日志的时间、整个调用持续的时间或者监控到该调用发生时的时间等等。每组API调用信息还可以包括通信协议，通信协议为虚拟机进行通信时所使用的通信协议，所述通信协议可以为超文本传输协议(HTTP，HyperText Transfer Protocol)、用户数据报协议(User Datagram Protocol，UDP协议)、传输控制协议/因特网互联协议(Transmission Control Protocol/Internet Protocol，TCP/IP协议)等等；虚拟机标识可以为虚拟机的IP地址。举例来说，API调用信息为(VM1、t1、P1、In)，表示VM1在时刻t1采用协议P1调用了输入函数向虚拟交换机VSwitch或VMM传递报文；API调用信息为(VM2、t2、P2、Out)，表示虚拟交换机或VMM在时刻t2采用协议P2调用了输出函数向VM2发送报文。
需要说明的是，当主机采用网卡直通的方案时，报文的传输不经过虚拟交换机，而是经过VMM传递到物理网卡。
拓扑发现服务器分析从各个主机收集API调用信息，识别虚拟机间的交互频率，确定虚拟机间的应用拓扑关系。
在一个示例中，所述API调用信息针对的API为输入API函数和输出API函数。
在一个示例中，源虚拟机向目的虚拟机发送报文，当源虚拟机发送报文及目的虚拟机接收报文采用相同的协议，且源虚拟机调用API发送报文的时间Ts和目的虚拟机接收报文的API调用的时间Te在可接受的自定义的预设阈值内，则认为源虚拟机和目的虚拟机发生一次交互。进一步的，在某段时长内，如果两个虚拟机发生的交互频率大于预设频率，则确定这两个虚拟机之间存在应用拓扑关系。
示例性的，如下所示，为本申请给出的拓扑发现服务器收集到的API调用信息的举例：
VM1,Time1,protocol,In；      VM1’,Time1’,protocol,Out；
VM2,Time2,protocol,In；      VM2’,Time2’,protocol,Out；
……                         ……
VMn,Timen,protocol,In；      VMn’,Timen’,protocol,Out；
拓扑发现服务器对上述API调用信息进行分析，确定满足第一条件的第一API调用信息与第二API调用信息，其中，所述第一API调用信息与第二API调用信息满足所述第一条件包括：所述第一API调用信息中的报文流向与所述第二API调用信息中的报文流向为互为相反的流向，且所述第一API调用信息中的API调用的发生时间与所述第二API调用信息中的API调用的发生时间的差值小于或等于预设阈值；满足上述第一条件即意味着所述第一API调用信息和所述第二API调用信息中的两个虚拟机存在一次交互，进而确定所述第一API调用信息所指示的第一虚拟机和所述第二API调用信息所指示的第二虚拟机之间的交互频率是否满足第二条件；若所述第一虚拟机和所述第二虚拟机之间的交互频率满足所述第二条件，确定所述第一虚拟机和所第二虚拟机之间存在应用拓扑关系。
上述分析过程给出了拓扑发现服务器根据API调用信息确定虚拟机间的应用拓扑关系的方法，具体的，当考虑通信协议时，分析过程可以归纳为下述三种判断过程：
判断一：两组API调用信息中的报文流向分别为输入和输出；
判断二：两组API调用信息中的通信协议相同；
判断三：两组API调用信息中的API调用的发生时间的差值小于或等于预设阈值(即为上述第二条件)。
上述三种判断采用编程语言表示为：
If(Protocol＝＝Protocol&&|(Time1–Time1’)|<T&&In
Figure PCTCN2015098125-appb-000001
Out)
Then VM1和VM1’发生一次交互。
需要说明的是，本发明实施例并不限定拓扑发现服务器同时执行上述三种判断过程，拓扑发现服务器可以根据需要以不同的顺序执行上述三种判断过程。示例性的，当不考虑通信协议时，针对收集到的API调用信息，拓扑发现服务器可以先根据API调用的发生时间对API调用信息进行筛选，选出符合判断三的API调用信息，再进一步的筛选出判断一的API调用信息，确定最终筛选出的API调用信息中存在交互关系的虚拟机间的交互频率，从而确 定虚拟机之间的应用拓扑关系。
更进一步的，当某个虚拟机集群中均采用相同的通信协议或者某个虚拟机集群中大部分虚拟机使用相同的通信协议进行通信时，上述API调用信息可以不包括通信协议，相应地，拓扑发现服务器也无需判断两组API调用信息中的通信协议是否相同。此时，应用拓扑关系发现的效率提高，准确度可能会降低。
在一个示例中，判断三中的阈值可以根据需要自行设定，具体的，可以考虑实际的网络负载情况，本发明实施例对此并不进行限定。
拓扑发现服务器遍历收集到的API调用信息，得到任意两个虚拟机之间的交互频率，当交互频率大于预设频率时，则认为两个虚拟机之间存在应用拓扑关系。拓扑发现服务器将虚拟机间的应用拓扑关系存储到数据库中。需要说明的是，拓扑发现服务器可以遍历某个时间段内发生的API调用的API调用信息，将得到的虚拟机间的交互次数作为交互频率，时间段的时长大小可以根据需要自行设定，相对应的，所述预设频率也可以根据需要自行设定。本发明实施例对此并不进行限定。
需要说明的是，可以预见，采用上述方式，计算虚拟机间的交互将会产生误差。例如，在不考虑协议的情况下，如果虚拟机a在时刻t1调用输入API函数向VMM发送一个报文，该报文的目的虚拟机是虚拟机b，记录的API调用信息为(a，t1，in)；虚拟机b在时刻t2收到VMM转发的来自虚拟机a的报文，记录的API调用信息为(b，t2，out)；虚拟机c在时刻t2收到VMM转发的来自虚拟机X发的报文，记录的API调用信息为(b，t2，out)，当t1和t2的差值小于预设间隔时，根据上述规则，会得出虚拟机a和虚拟机b存在一次交互；虚拟机a与虚拟机c存在一次交互。显然的，此时由于虚拟机c的报文来自虚拟机X，虚拟机a与虚拟机c之间不存在交互。
需要说明的是，在实际的产品实现场景中，当虚拟机间存在大量的报文交互时，上述误差相对较小，且不会对海量虚拟机间的应用拓扑关系产生明显影响，因此，上述误差是可以接受的。
还需要说明的是，在某些情况下，所述API调用信息中的虚拟机标识可以同时包括源虚拟机标识和目的虚拟机标识，此时，理论上，一组API调用信息记录就可以确定源虚拟机和目的虚拟机之间存在一次交互。在本申请中，为了保证计算效率，无论API调用信息包括通信双方的标识还是只有通信一方的标识，本申请均可以按照上述分析方法判断虚拟机间是否存在交互，即对于报文流向为输入的API调用信息，仅使用API调用信息中源虚拟机的标 识，对于报文流向为输出的API调用信息，仅使用API调用信息中的目的虚拟机的标识。针对两种API调用信息格式，均按照上述三种判断过程判断虚拟机间是否存在交互，而不需要针对两种API调用信息的格式进行分别计算，可以有效提高分析的效率。
管理节点：可以为VMware Vcenter，FusionManager等等需要获取虚拟机的网络拓扑的功能实体。管理节点从拓扑发现服务器或者上述数据库中读取应用拓扑关系。
在一个示例中，拓扑发现服务器可以为一台独立的物理服务器，或者拓扑发现服务器作为一个功能模块与管理节点等其他物理服务器合设。
如图1B所示，为本发明实施例提供的另一种虚拟化系统架构示意图，与图1A不同的是，主机上不包含采集代理，而是由VM、虚拟机交换机或者VMM将API调用信息存储到日志文件中或者直接发送给拓扑发现服务器。
如图1C所示，为本发明实施例提供的再一种虚拟化系统架构示意图，此时，拓扑发现服务器与管理节点合设，上述的拓扑发现服务器的功能由管理节点中的拓扑发现模块实现。
在图1B和图1C给出的虚拟化架构是在图1A基础上的改进，虚拟化架构中各部件的功能与图1A类似，可以根据架构的变化适应性的修改，同样可以实现API调用信息的上报和分析功能，本发明实施例对图1B和图1C中各部件的功能不再赘述。
应用拓扑关系有着广泛的用途：比如，属于同一应用拓扑集群的虚拟机应该尽量放在同一交换机覆盖的网络中或者相近网络中，以节省交互时间；如果需要分批升级系统中的虚拟机集群，应该尽量将同一应用拓扑集群的虚拟机放在同一批次升级；有着应用拓扑关系的虚拟机集群应该尽量放在同一个服务器或者就近的服务器中；有着应用拓扑关系的虚拟机集群跟相应的备份集群应该在不同的服务器上；在迁移的时候也应该尽量将整个应用拓扑集群对应的虚拟机一起迁移等等。当执行上述功能的管理节点需要使用虚拟机的应用拓扑时，即可从拓扑发现服务器获取。
采集代理和拓扑发现服务器可以采用硬件/软件实现，示例性的，如图2所示，为本发明实施例提供的计算机设备示意图。计算机设备200包括至少一个处理器201，通信总线202，存储器203以及至少一个通信接口204。
处理器201可以是一个通用中央处理器(CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本发明方案程序执行的集成电路。
通信总线202可包括一通路，在上述组件之间传送信息。所述通信接口304，使用任何 收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线接入网(RAN)，无线局域网(Wireless Local Area Networks，WLAN)等。
存储器203可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
其中，所述存储器203用于存储执行本发明方案的应用程序代码，并由处理器201来控制执行。所述处理器201用于执行所述存储器203中存储的应用程序代码。
在具体实现中，作为一种实施例，处理器201可以包括一个或多个CPU，例如图2中的CPU0和CPU1。
在具体实现中，作为一种实施例，计算机设备200可以包括多个处理器，例如图2中的处理器201和处理器208。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
在具体实现中，作为一种实施例，计算机设备200还可以包括输出设备205和输入设备206。输出设备205和处理器201通信，可以以多种方式来显示信息。例如，输出设备205可以是液晶显示器(liquid crystal display，LCD),发光二级管(light emitting diode，LED)显示设备，阴极射线管(cathode ray tube，CRT)显示设备，或投影仪(projector)等。输入设备206和处理器201通信，可以以多种方式接受用户的输入。例如，输入设备206可以是鼠标、键盘、触摸屏设备或传感设备等。
上述的计算机设备200可以是一个通用计算机设备或者是一个专用计算机设备。在具体实现中，计算机设备200可以是台式机、便携式电脑、网络服务器、掌上电脑(Personal Digital Assistant，PDA)、移动手机、平板电脑、无线终端设备、通信设备、嵌入式设备或有图2中类似结构的设备。本发明实施例不限定计算机设备200的类型。
图1A、1B和1C中的采集代理、主机和拓扑发现服务器可以为图2所示的设备，存储 器中存储了一个或多个软件模块，用于实现采集代理、主机和拓扑发现服务器的功能(例如：拓扑发现服务器中的API调用信息分析功能等)。采集代理、主机和拓扑发现服务器可以通过处理器以及存储器中的程序代码来实现虚拟机间的应用拓扑发现的方法。
需要说明的是，图2所示的计算机设备仅仅是给出了应用拓扑发现系统中各部分的可能的硬件实现方式，根据系统各部分功能的不同或者变化，可以对计算机设备的硬件组件进行增删，以使得与系统各部分的功能进行匹配。
如图3A所述，为本发明实施例提供的主机上的虚拟化结构示意图。主机为一台物理服务器，该物理服务器的底层为硬件层，硬件层主要包括中央处理器(CPU，Central Processing Unit)、内存、硬盘以及网卡等硬件资源。服务器虚拟化是在物理服务器上借助虚拟化软件(如VMWare ESX、Citrix XEN)实现多个虚拟机(Virtual Machine，VM)的虚拟化运行环境。安装在服务器上实现虚拟化环境的软件层被称为VMM。运行在硬件层之上的VMM承担对硬件层中的硬件资源进行调度、分配和管理工作。VMM之上运行多个虚拟机VM，VMM为每个虚拟机提供虚拟化的CPU、内存、存储、IO设备(如网卡)以及以太网交换机等硬件环境，保证多个虚拟机相互隔离运行。
在虚拟化运行环境中，VMM为每个虚拟机创建一个虚拟网卡(Virtual Network Interface Card，vNIC)，虚拟交换机VSwitch提供了虚拟机之间，以及虚拟机与外部网络之间的通讯能力。对于在VMM中运行的VSwitch，每个虚拟机的虚拟网卡对应到VSwitch的一个逻辑端口上，主机的物理网卡对应于VSwitch与外部物理交换机相连的端口。
虚拟机报文接收流程为：VSwitch从物理网卡接收以太网报文，之后根据VMM下发的虚拟机媒体访问控制(Media Access Control，MAC)地址与VSwitch逻辑端口对应关系表(即静态MAC表)来转发报文。
虚拟机报文发送流程：当报文的MAC地址在外部网络时，VSwitch直接将报文从物理网卡发向外部网络；当报文目的MAC地址是连接在相同VSwitch上的虚拟机时，则VSwitch通过静态MAC表来转发报文。
如图3B所示，为本发明实施例提供的一种网卡直通场景下主机上的虚拟化结构示意图，此时，物理网卡未进行虚拟机，物理网卡的每个出端口分配给一个虚拟机。如图3C所示，为本发明实施例提供的另一种网卡直通场景下主机上的虚拟化结构示意图，与图3B不同的是，物理网卡经过虚拟化被虚拟机为多个虚拟功能设备(Virtual Function，VF)，上述网卡虚拟化技术可以为单根IO虚拟化(Single-Root I/O Virtualization，SR-IOV)以及多根 IO虚拟化(Multi-Root I/O Virtualization，MR-IOV)。各虚拟功能设备能共享物理网卡的物理资源(例如网卡端口)，各虚拟功能设备还可以与主机上的虚拟机系统进行关联。
本发明实施例提供的应用拓扑关系的发现方法同样适用于图3B和图3C所示的场景，此时，虚拟机可以直接调用物理网卡的出接口来传递报文，从而绕过VMM中的虚拟交换机。代理模块可以从虚拟机或VMM获取API调用信息。举例来说，在网卡直通的场景下，当虚拟机调用输入API函数将报文通过VMM传递到物理网卡时，虚拟机或VMM可以将API调用信息记录到日志文件中或者直接传递给采集代理；或者，采集代理监控报文在虚拟机、VMM以及物理网卡之间的传输，将API调用信息记录到日志文件中。
采集代理可以采用主动发现或者被动发现两种采集API调用信息。如图4所示，为本发明实施例提供的采集代理通过主动发现的形式获取API调用信息的示意图。如图5所示，为本发明实施例提供的采集代理通过被动发现的形式获取API调用信息的示意图。其中，主动发现是指，虚拟机调用输入API函数(Port_Input API)时，虚拟机、虚拟交换机或VMM会将API调用信息写入日志log文件，或者，虚拟交换机调用输出API函数(Port_Output API)时，虚拟机、虚拟交换机或VMM会将API调用信息写入日志文件，采集代理可以通过扫描日志文件，从中获取API调用信息；被动发现是指，新增向采集代理进行API信息上报的拓扑信息上报API函数(Topo_Info_API)，当虚拟机调用输入API函数(Port_Input API)通过VMM传输报文时，虚拟机、虚拟交换机或VMM调用拓扑信息上报API函数，将本次调用的API调用信息发送给采集代理，或者，当虚拟交换机调用输出API函数(Port_Output API)时，虚拟机、虚拟交换机或VMM调用拓扑信息上报API函数，将本次调用的API调用信息发送给采集代理。
需要说明的是，对于不同的操作系统，上述输入API函数、输出API函数以及拓扑上报API函数可能会有不同的格式，本发明实施例对此并不进行限定，本领域技术人员可以理解的是，上述函数可以分别实现输入、输出及上报功能即可。可以通过API函数的工具书查找API函数，示例性的，人民邮电出版社出版的《Windows API函数参考手册》是关于Microsoft Win32API函数的参考手册，其他版本和其他类型的操作系统也可以从相关的工具书中查找对应的输入API函数和输出API函数。
还需要说明的是，将API调用信息存储在日志文件中仅为一个举例，API调用信息可以存储在其他文件或其他位置，采集代理可以获取即可。
拓扑发现服务器从各主机上收集API调用信息，每组API调用信息对应一次API调用，在本发明各实施例中，API调用具体包括输入API函数调用和输出API函数调用，其中，报 文发送端的源虚拟机调用输入API函数将报文传递到VMM，由VMM将报文经过网络传递到报文接收端的VMM，报文接收端的VMM调用输出API函数将报文发送给目的虚拟机，在上述过程中，在报文发送端的主机和报文接收端的主机均会记录一组API调用信息，每组API调用信息包括API调用对应的虚拟机的标识、API调用的发生时间以及API调用的报文流向；更进一步的，还可能包括通信协议。拓扑发现服务器对收集到的API调用信息进行分析，当两组API调用信息中的API调用的发生时间的差值小于预设阈值，且两组API调用信息中的报文流向互为相反(一个是输入，另外一个是输出)时，则两组API调用信息中的两个虚拟机标识对应的两个虚拟机之间存在一次交互关系，从而确定两个虚拟机之间的交互频率，若所述第一虚拟机和所述第二虚拟机之间的交互频率满足所述第二条件，确定所述第一虚拟机和所第二虚拟机之间存在应用拓扑关系。具体的，确定所述第一虚拟机和所第二虚拟机之间的交互频率，比较所述交互频率和预设频率，当所述交互频率大于预设频率，确定所述交互频率满足所述第二条件。显然的，上述两组API调用信息中的两个虚拟机标识对应的两个虚拟机不同。上述方案给出了虚拟化场景下发现虚拟机间的应用拓扑关系的方法，通过分析报文传输过程中产生的API调用信息确定虚拟机间的应用拓扑关系，方案复杂度较低。
结合图3A所示的主机上的虚拟化结构示意图，如图6所示，为本发明实施例提供的在同一主机上的两个虚拟机之间通信时，采集代理获取API调用信息的流程示意图。采集代理运行在主机中，作为主机的一个功能模块，主机上运行有VM1和VM2(本发明实施例以2个VM为例进行说明)，VM1的虚拟网卡为vNIC1，VM2的虚拟网卡为vNIC2，与vNIC1对应虚拟交换机上的端口为Port1，与vNIC2对应的虚拟机交换机上的端口为Port2。需要说明的是，为虚拟机分配虚拟网卡以及建立虚拟网卡与虚拟交换机端口之间的对应关系为本领域常用技术手段，本发明实施例对具体流程不再赘述。图6所示的方法包括：
步骤601：当VM1需要向VM2发送报文时，VM1调用VMM的输入API函数(Port_Input API)，通过vNIC1将所述报文发送到虚拟交换机的Port1；
步骤602：虚拟交换机通过查找静态MAC表，确定所述报文的目的MAC确定VM2对应的虚拟交换机的端口为Port2；
在一种可能的方式中，如果VM1不知道VM2的地址，则VM1发送给VM2的所述报文中不携带VM2的地址。此时，虚拟交换机将VM1的报文进行广播，通过广播的方式，将VM1的报文发送到该虚拟机交换机下的所有VM，VM2即可收到VM1的报文并返回响应。
步骤603：虚拟交换机调用输出API函数(Port_Output API)，通过Port2将所述报文发送到VM2的虚拟网卡vNIC2，VM2即接收到了VM1发送的报文。
在步骤601中，鉴于VM1要调用输入API函数，发生了一次API调用，因此，需要记录API调用信息，VM1可以通过两种方式记录API调用信息：
方式一：VM1调用与采集代理之间的接口，上报API调用信息，具体的，VM1调用所述采集代理的拓扑上报API函数(Topo_Info API),将API调用信息发送给所述采集代理。需要说明的是，本发明实施例并不对VM1向采集代理发送API调用信息的时机进行限制，可选的，VM1可以在网络负荷小时发送所述API调用信息。
方式二：VM1将所述API调用信息写入日志文件，由采集代理进行读取。需要说明的是，本发明实施例对采集代理从日志文件中获取API调用信息的时机并不进行限定，可选的，采集代理可以周期性的从日志文件中读取或者VM1在将API调用信息写入日志文件后通知采集代理读取。
更进一步的，除了由VM记录API调用信息外，也可以由虚拟机交换机或VMM记录API调用信息，具体的，当虚拟交换机或VMM接收到VM1发送的报文时，将API调用信息写入到日志文件或者发送给采集代理。
所述API调用信息包括虚拟机标识、API调用的发生时间、通信协议以及报文流向。可选的，所述API调用信息中的虚拟机标识可以包括源虚拟机标识以及目的虚拟机标识，此时，仅根据一条API调用信息即可直接识别出源虚拟机和目的虚拟机之间发生了一次交互。需要说明的是，当VM1知道通信对端VM2的地址时，则可以在记录的API调用信息中包括源虚拟机标识和目的虚拟机标识。上述通信协议可以为HTTP协议、TCP/IP协议，以及UDP协议等等。
在步骤603中，鉴于虚拟交换机调用了输出API函数(Port_Output API)，发生了一次API调用，因此，需要记录API调用信息。与VM1类似，虚拟交换机也可以通过两种方式记录API调用信息：
方式一：虚拟交换机调用与采集代理之间的接口，上报API调用信息，具体的，虚拟交换机调用所述采集代理的拓扑上报API函数(Topo_Info API),将API调用信息发送给所述采集代理。需要说明的是，本发明实施例并不对虚拟交换机向采集代理发送API调用信息的时机进行限制。所述拓扑上报API函数的实现可以用HOOK函数或者修改代码，只要能够提供API调用信息的传递即可。
方式二：虚拟交换机将所述API调用信息写入日志文件，由采集代理进行读取。需要说明的是，本发明实施例对采集代理从日志文件中获取API调用信息的时机并不进行限定。
更进一步的，在步骤603中，除了虚拟交换机外，也可以由虚拟机(VM2)或者VMM记录API调用信息，本发明实施例不再赘述。
图6所示的方法给出了同一主机上两个虚拟机进行通信时采集代理获取API调用信息的流程。结合图3A所示的虚拟化结构示意图，如图7所示，为本发明实施例提供的在不同主机上的两个虚拟机之间通信时，采集代理获取API调用信息的流程示意图。两个主机可以采用如图3A所示的虚拟化结构，主机间通过物理交换机相连。主机1上运行有VM1和虚拟交换机1，主机2上运行有VM2和虚拟交换机2(本发明实施例以2个VM为例进行说明)，VM1的虚拟网卡为vNIC1，VM2的虚拟网卡为vNIC2，与vNIC1对应虚拟交换机1上的端口为Port1，与vNIC2对应的虚拟机交换机2上的端口为Port2。需要说明的是，为虚拟机分配虚拟网卡以及建立虚拟网卡与虚拟交换机端口之间的对应关系为本领域常用技术手段，本发明实施例对具体流程不再赘述。图7所示的方法包括：
步骤701：当VM1需要向VM2发送报文时，VM1调用VMM的输入API函数(Port_Input API)，通过vNIC1将所述报文发送到虚拟交换机1的Port1；
步骤702：虚拟交换机1在port1上接收所述报文，确定所述报文的目的MAC地址外部网络，则所述虚拟交换机1通过主机1的物理网卡将所述报文发送到外部网络；
步骤703：依据现有的报文转发规则，所述报文被路由到VM2所在的主机的物理网卡；
步骤704：主机2通过自身的物理网卡接收到所述报文；
步骤705：虚拟交换机2确定与VM2对应的端口为Port2，虚拟交换机2通过端口Port2将报文发送到VM2的虚拟网卡vNIC2。VM2即接收到了VM1发送的报文。
需要说明的是，在上述报文传输流程中，依据现有规则，报文可能被封装和解封装，本发明实施例不再赘述。
在步骤701中，VM1采用与步骤601中定义的类似的方式记录API调用信息。主机1的采集代理获取API调用信息。
在步骤705中，虚拟交换机2采用与步骤603中定义的方式记录API调用信息。主机2的采集代理获取API调用信息。
需要说明的是，本发明实施例可以采用分布式虚拟机交换机，分布式虚拟交换机可以跨多个主机从而使得多个主机上的虚拟机如同连接在同一虚拟机交换机上一样，虚拟机可以在上述多个主机之间迁移，或者，一个主机上可以存在多个分布式虚拟交换机。当采用分布 式虚拟交换机时，采集代理获取API调用信息的方式与前述类似，本申请不再赘述。
针对图6和图7所示的方法流程，当主机上不包含采集代理时，虚拟机或虚拟交换机可以采用图6和图7定义的方式将API调用信息直接上报给拓扑发现服务器。
本申请给出的应用拓扑关系发现的方法，在报文传输过程中，记录下API调用信息，通过匹配两组API调用信息是否满足第一条件确定两组API调用信息对应的两个虚拟机之间是否存在交互，采用上述方式，拓扑发现服务器进而可以确定收集到的API调用信息所涉及的各虚拟机间的交互频率，根据各虚拟机间的交互频率确定虚拟机间的应用拓扑关系。上述方案给出了虚拟化场景下发现虚拟机间的应用拓扑关系的方法，只需要由存在报文传输的两端进行API调用信息的记录，方案复杂度较低。
如图8所示，为本发明实施例提供的一种应用拓扑关系发现系统，所述系统80包括拓扑发现服务器81以及至少一个主机82，所述至少一个主机82上运行有多台虚拟机，
所述多台虚拟机中的一台虚拟机822发送报文或者所述至少一个主机82上的VMM向所述多台虚拟机中的一台虚拟机822转发报文时，产生应用程序编程接口API调用信息；
拓扑发现服务器81，用于收集至少两组应用程序编程接口API调用信息，每组API调用信息对应一次API调用，所述每组API调用信息包括API调用对应的虚拟机的标识、API调用的发生时间以及API调用的报文流向；
所述拓扑发现服务器81，还用于分析所述至少API调用信息，确定满足第一条件的第一API调用信息与第二API调用信息，其中，所述第一API调用信息与第二API调用信息满足所述第一条件包括：所述第一API调用信息中的报文流向与所述第二API调用信息中的报文流向为互为相反的流向，且所述第一API调用信息中的API调用的发生时间与所述第二API调用信息中的API调用的发生时间的差值小于或等于预设阈值；
所述拓扑发现服务器81，还用于确定所述第一API调用信息所指示的第一虚拟机822和所述第二API调用信息所指示的第二虚拟机822之间的交互频率是否满足第二条件，若确定所述第一虚拟机822和所述第二虚拟机822之间的交互频率满足所述第二条件，确定所述第一虚拟机822和所第二虚拟机822之间存在应用拓扑关系。
进一步的，所述每组API调用信息还包括通信协议；相应地，所述第一API调用信息与第二API调用信息满足所述第一条件还包括：所述第一API调用信息中的通信协议与所述第二API调用信息中的通信协议相同。
所述拓扑发现服务器81，具体用于分析所述第一虚拟机822的至少两组API调用信息和所述第二虚拟机822的至少两组API调用信息，确定所述第一虚拟机822和所第二虚拟机 822之间的交互频率，比较所述交互频率和预设频率，当所述交互频率大于预设频率，确定所述交互频率满足所述第二条件。
所述拓扑发现服务器81，具体用于确定所述第一虚拟机822与所述第二虚拟机822是否属于相同的网段，当所述第一虚拟机822与所述第二虚拟机822属于相同网段时，根据预设的加权系数修正所述交互频率或所述预设频率之一，比较修正后的交互频率与所述预设频率；或者，比较所述交互频率与修正后的预设频率。
所述拓扑发现服务器81，具体用于从所述多台虚拟机的部署主机82上的日志文件中分别读取所述至少两组API调用信息；或者，
所述拓扑发现服务器81，具体用于接收所述多台虚拟机的部署主机上的代理模块上报的所述至少两组API调用信息。
进一步的，所述API调用包括输入API函数调用和输出API函数调用。
所述应用拓扑发现的系统80还包括：
所述虚拟机822，还用于在调用API向所述虚拟机822所在的VMM发送报文或者接收所述VMM转发的报文时，将API调用信息写入所述虚拟机822的部署主机82上的日志文件中；或，虚拟机822的部署主机上的代理模块，用于将报文传输过程中的API调用对应的API调用信息写入所述虚拟机822的部署主机82上的日志文件中。
与前述系统相对应，如图9所示，为本发明实施例提供的一种拓扑发现服务器,包括：获取单元91，用于收集至少两组应用程序编程接口API调用信息，每组API调用信息对应一次API调用，所述每组API调用信息包括API调用对应的虚拟机的标识、API调用的发生时间以及API调用的报文流向；
分析单元92，用于分析所述至少两组应用程序编程接口API调用信息，确定满足第一条件的第一API调用信息与第二API调用信息，其中，所述第一API调用信息与第二API调用信息满足所述第一条件包括：所述第一API调用信息中的报文流向与所述第二API调用信息中的报文流向为互为相反的流向，且所述第一API调用信息中的API调用的发生时间与所述第二API调用信息中的API调用的发生时间的差值小于或等于预设阈值；
所述分析单元92，还用于确定所述第一API调用信息所指示的第一虚拟机和所述第二API调用信息所指示的第二虚拟机之间的交互频率是否满足第二条件，若所述第一虚拟机和所述第二虚拟机之间的交互频率满足所述第二条件，确定所述第一虚拟机和所第二虚拟机之间存在应用拓扑关系。
进一步的，所述每组API调用信息还包括通信协议；相应地，所述第一API调用信息与第二 API调用信息满足所述第一条件还包括：所述第一API调用信息中的通信协议与所述第二API调用信息中的通信协议相同。
所述分析单元92，具体用于分析所述第一虚拟机的至少两组API调用信息和所述第二虚拟机的至少两组API调用信息，确定所述第一虚拟机和所第二虚拟机之间的交互频率，比较所述交互频率和预设频率，当所述交互频率大于预设频率，确定所述交互频率满足所述第二条件。所述分析单元92，具体用于确定所述第一虚拟机与所述第二虚拟机是否属于相同的网段，当所述第一虚拟机与所述第二虚拟机属于相同网段时，根据预设的加权系数修正所述交互频率或所述预设频率之一；
所述分析单元92，具体用于比较修正后的交互频率与所述预设频率；或者，比较所述交互频率与修正后的预设频率。
所述获取单元91，具体用于从所述多台虚拟机的部署主机上的日志文件中分别读取所述至少两组API调用信息；或者，
所述获取单元91，具体用于接收所述多台虚拟机的部署主机上的代理模块上报的所述至少两组API调用信息。
所述API调用包括输入API函数调用和输出API函数调用。
本发明实施例给出的应用拓扑关系发现的方法、装置和系统，收集报文传输过程中API调用信息，通过匹配两组API调用信息是否满足第一条件确定两组API调用信息对应的两个虚拟机之间是否存在交互，采用上述方式，拓扑发现服务器可以确定收集到的API调用信息所涉及的各虚拟机间的交互频率，根据各虚拟机间的交互频率确定虚拟机间的应用拓扑关系。上述方案给出了虚拟化场景下发现虚拟机间的应用拓扑关系的方法，通过分析报文传输过程中产生的API调用信息确定虚拟机间的应用拓扑关系，方案复杂度较低。
在图8和9对应的实施例中，虚拟机、采集代理、虚拟交换机，以及拓扑发现服务器是以功能单元/功能模块的形式来呈现。这里的“单元/模块”可以指特定应用集成电路(application-specific integrated circuit，ASIC)，电路，执行一个或多个软件或固件程序的处理器和存储器，集成逻辑电路，和/或其他可以提供上述功能的器件。在一个简单的实施例中，本领域的技术人员可以想到虚拟机、采集代理、虚拟交换机，以及拓扑发现服务器可以采用图2所示的形式。例如，获取单元901和处理单元902可以通过图2的处理器和存储器来实现。
本发明实施例还提供了一种计算机存储介质，用于储存为上述图8和9所示的设备所用的计算机软件指令，其包含用于执行上述方法实施例所设计的程序。通过执行存储的程序， 可以实现应用拓扑关系发现的方法。
尽管在此结合各实施例对本发明进行了描述，然而，在实施所要求保护的本发明过程中，本领域技术人员通过查看所述附图、公开内容、以及所附权利要求书，可理解并实现所述公开实施例的其他变化。在权利要求中，“包括”(comprising)一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其他单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能组合起来产生良好的效果。
本领域技术人员应明白，本发明的实施例可提供为方法、装置(设备)、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。计算机程序存储/分布在合适的介质中，与其它硬件一起提供或作为硬件的一部分，也可以采用其他分布形式，如通过Internet或其它有线或无线电信系统。
本发明是参照本发明实施例的方法、装置(设备)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管结合具体特征及其实施例对本发明进行了描述，显而易见的，在不脱离本发明的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利 要求所界定的本发明的示例性说明，且视为已覆盖本发明范围内的任意和所有修改、变化、组合或等同物。显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (21)

  1. 一种应用拓扑关系发现的方法，其特征在于，所述方法包括：
    收集至少两组应用程序编程接口API调用信息，每组API调用信息对应一次API调用，所述每组API调用信息包括API调用对应的虚拟机的标识、API调用的发生时间以及API调用的报文流向；
    分析所述至少两组API调用信息，确定满足第一条件的第一API调用信息与第二API调用信息，其中，所述第一API调用信息与第二API调用信息满足所述第一条件包括：所述第一API调用信息中的报文流向与所述第二API调用信息中的报文流向为互为相反的流向，且所述第一API调用信息中的API调用的发生时间与所述第二API调用信息中的API调用的发生时间的差值小于或等于预设阈值；
    确定所述第一API调用信息所指示的第一虚拟机和所述第二API调用信息所指示的第二虚拟机之间的交互频率是否满足第二条件；
    若所述第一虚拟机和所述第二虚拟机之间的交互频率满足所述第二条件，确定所述第一虚拟机和所第二虚拟机之间存在应用拓扑关系。
  2. 如权利要求1所述的方法，其特征在于，所述每组API调用信息还包括通信协议；相应地，所述第一API调用信息与第二API调用信息满足所述第一条件还包括：所述第一API调用信息中的通信协议与所述第二API调用信息中的通信协议相同。
  3. 如权利要求1或2所述的方法，其特征在于，所述确定所述第一虚拟机和所述第二虚拟机之间的交互频率是否满足第二条件包括：
    分析所述第一虚拟机的至少两组API调用信息和所述第二虚拟机的至少两组API调用信息，确定所述第一虚拟机和所第二虚拟机之间的交互频率，比较所述交互频率和预设频率，当所述交互频率大于所述预设频率，确定所述交互频率满足所述第二条件。
  4. 如权利要求3所述的方法，其特征在于，所述比较所述交互频率和预设频率之前，还包括：
    确定所述第一虚拟机与所述第二虚拟机是否属于相同的网段，当所述第一虚拟机与所述第二虚拟机属于相同网段时，根据预设的加权系数修正所述交互频率或所述预设频率之一；
    所述比较所述交互频率和预设频率包括：
    比较修正后的交互频率与所述预设频率；或者，比较所述交互频率与修正后的预设频率。
  5. 如权利要求1-4任一所述的方法，其特征在于，所述收集至少两组API调用信息包括：
    从所述多台虚拟机的部署主机上的日志文件中分别读取所述至少两组API调用信息；或 者，
    接收所述多台虚拟机的部署主机上的代理模块上报的所述至少两组API调用信息。
  6. 如权利要求5所述的方法，其特征在于，在从所述多台虚拟机的部署主机上的日志文件中分别读取所述至少两组API调用信息之前，所述方法还包括以下至少一种：
    第一种、在虚拟机调用API向所述虚拟机所在的VMM发送报文时，所述虚拟机、所述VMM中的虚拟交换机或所述VMM任意之一将API调用信息写入所述虚拟机的部署主机上的日志文件中；
    第二种、虚拟机的部署主机上的代理模块将报文传输过程中的API调用对应的API调用信息写入所述虚拟机的部署主机上的日志文件中；
    第三种、在虚拟机的VMM调用API向所述虚拟机发送报文时，所述虚拟机、所述VMM中的虚拟交换机或所述VMM任意之一将API调用信息写入所述虚拟机的部署主机上的日志文件中。
  7. 如权利要求5所述的方法，其特征在于，在接收所述多台虚拟机的部署主机上的代理模块上报的所述至少两组API调用信息之前，所述方法还包括：
    虚拟机的部署主机上的代理模块监控报文在所述主机上的传输过程，记录所述传输过程中的API调用对应的API调用信息；或，
    虚拟机的部署主机上的代理模块接收所述虚拟机、虚拟交换机或者VMM发送的在所述主机上的报文传输过程中的API调用对应的API调用信息。
  8. 如权利要求1所述的方法，其特征在于，所述API调用包括输入API函数调用和输出API函数调用。
  9. 一种拓扑发现服务器，其特征在于，包括：
    获取单元，用于收集至少两组应用程序编程接口API调用信息，每组API调用信息对应一次API调用，所述每组API调用信息包括API调用对应的虚拟机的标识、API调用的发生时间以及API调用的报文流向；
    分析单元，用于分析所述至少两组API调用信息，确定满足第一条件的第一API调用信息与第二API调用信息，其中，所述第一API调用信息与第二API调用信息满足所述第一条件包括：所述第一API调用信息中的报文流向与所述第二API调用信息中的报文流向为互为相反的流向，且所述第一API调用信息中的API调用的发生时间与所述第二API调用信息中的API调用的发生时间的差值小于或等于预设阈值；
    所述分析单元，还用于确定所述第一API调用信息所指示的第一虚拟机和所述第二API调用信息所指示的第二虚拟机之间的交互频率是否满足第二条件，若所述第一虚拟机和所述 第二虚拟机之间的交互频率满足所述第二条件，确定所述第一虚拟机和所第二虚拟机之间存在应用拓扑关系。
  10. 如权利要求9所述的拓扑发现服务器，其特征在于，所述每组API调用信息还包括通信协议；相应地，所述第一API调用信息与第二API调用信息满足所述第一条件还包括：所述第一API调用信息中的通信协议与所述第二API调用信息中的通信协议相同。
  11. 如权利要求9或10所述的拓扑发现服务器，其特征在于，
    所述分析单元，具体用于分析所述第一虚拟机的至少两组API调用信息和所述第二虚拟机的至少两组API调用信息，确定所述第一虚拟机和所第二虚拟机之间的交互频率，比较所述交互频率和预设频率，当所述交互频率大于所述预设频率，确定所述交互频率满足所述第二条件。
  12. 如权利要求9-11任一所述的拓扑发现服务器，其特征在于，
    所述分析单元，具体用于确定所述第一虚拟机与所述第二虚拟机是否属于相同的网段，当所述第一虚拟机与所述第二虚拟机属于相同网段时，根据预设的加权系数修正所述交互频率或所述预设频率之一；
    所述分析单元，具体用于比较修正后的交互频率与所述预设频率；或者，比较所述交互频率与修正后的预设频率。
  13. 如权利要求9-12任一所述的拓扑发现服务器，其特征在于，
    所述获取单元，具体用于从所述多台虚拟机的部署主机上的日志文件中分别读取所述至少两组API调用信息；或者，
    所述获取单元，具体用于接收所述多台虚拟机的部署主机上的代理模块上报的所述至少两组API调用信息。
  14. 如权利要求9所述的拓扑发现服务器，其特征在于，
    所述API调用包括输入API函数调用和输出API函数调用。
  15. 一种应用拓扑关系发现的系统，其特征在于，所述系统包括拓扑发现服务器以及至少一个主机，所述至少一个主机上运行有多台虚拟机，
    所述多台虚拟机中的一台虚拟机发送报文或者所述至少一个主机上的VMM向所述多台虚拟机中的一台虚拟机转发报文时，产生应用程序编程接口API调用信息；
    拓扑发现服务器，用于收集至少两组API调用信息，每组API调用信息对应一次API调用，所述每组API调用信息包括API调用对应的虚拟机的标识、API调用的发生时间以及API调用的报文流向；
    所述拓扑发现服务器，还用于分析所述至少API调用信息，确定满足第一条件的第一API 调用信息与第二API调用信息，其中，所述第一API调用信息与第二API调用信息满足所述第一条件包括：所述第一API调用信息中的报文流向与所述第二API调用信息中的报文流向为互为相反的流向，且所述第一API调用信息中的API调用的发生时间与所述第二API调用信息中的API调用的发生时间的差值小于或等于预设阈值；
    所述拓扑发现服务器，还用于确定所述第一API调用信息所指示的第一虚拟机和所述第二API调用信息所指示的第二虚拟机之间的交互频率是否满足第二条件，若所述第一虚拟机和所述第二虚拟机之间的交互频率满足所述第二条件，确定所述第一虚拟机和所第二虚拟机之间存在应用拓扑关系。
  16. 如权利要求15所述的系统，其特征在于，所述每组API调用信息还包括通信协议；相应地，所述第一API调用信息与第二API调用信息满足所述第一条件还包括：所述第一API调用信息中的通信协议与所述第二API调用信息中的通信协议相同。
  17. 如权利要求15或16所述的系统，其特征在于，
    所述拓扑发现服务器，具体用于分析所述第一虚拟机的至少两组API调用信息和所述第二虚拟机的至少两组API调用信息，确定所述第一虚拟机和所第二虚拟机之间的交互频率，比较所述交互频率和预设频率，当所述交互频率大于所述预设频率，确定所述交互频率满足所述第二条件。
  18. 如权利要求15-17任一所述的系统，其特征在于，
    所述拓扑发现服务器，具体用于确定所述第一虚拟机与所述第二虚拟机是否属于相同的网段，当所述第一虚拟机与所述第二虚拟机属于相同网段时，根据预设的加权系数修正所述交互频率或所述预设频率之一，比较修正后的交互频率与所述预设频率；或者，比较所述交互频率与修正后的预设频率。
  19. 如权利要求15-18任一所述的系统，其特征在于，
    所述拓扑发现服务器，具体用于从所述多台虚拟机的部署主机上的日志文件中分别读取所述至少两组API调用信息；或者，
    所述拓扑发现服务器，具体用于接收所述多台虚拟机的部署主机上的代理模块上报的所述至少两组API调用信息。
  20. 如权利要求15所述的系统，其特征在于，所述API调用包括输入API函数调用和输出API函数调用。
  21. 如权利要求19所述的系统，其特征在于，还包括：
    所述虚拟机，还用于在调用API向所述虚拟机所在的VMM发送报文或者接收所述VMM转发的报文时，将API调用信息写入所述虚拟机的部署主机上的日志文件中；或，
    虚拟机的部署主机上的代理模块，用于将报文传输过程中的API调用对应的API调用信息写入所述虚拟机的部署主机上的日志文件中。
PCT/CN2015/098125 2015-12-21 2015-12-21 应用拓扑关系发现的方法、装置和系统 WO2017107018A1 (zh)

Priority Applications (8)

Application Number Priority Date Filing Date Title
JP2017505627A JP6571161B2 (ja) 2015-12-21 2015-12-21 アプリケーショントポロジ関係を探索するための方法、装置、およびシステム
CN201580031988.0A CN106489251B (zh) 2015-12-21 2015-12-21 应用拓扑关系发现的方法、装置和系统
EP15908488.8A EP3226493B1 (en) 2015-12-21 2015-12-21 Method, device, and system for discovering the relationship of applied topology
KR1020177001923A KR101979363B1 (ko) 2015-12-21 2015-12-21 애플리케이션 토폴로지 관계의 발견 방법, 장치, 및 시스템
PCT/CN2015/098125 WO2017107018A1 (zh) 2015-12-21 2015-12-21 应用拓扑关系发现的方法、装置和系统
CN201910940823.5A CN110865867B (zh) 2015-12-21 2015-12-21 应用拓扑关系发现的方法、装置和系统
BR112017000458-5A BR112017000458B1 (pt) 2015-12-21 Método, aparelho e sistema para descobrir uma relação de topologia de aplicativo
US15/786,159 US10459754B2 (en) 2015-12-21 2017-10-17 Method, apparatus, and system for discovering application topology relationship

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2015/098125 WO2017107018A1 (zh) 2015-12-21 2015-12-21 应用拓扑关系发现的方法、装置和系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/786,159 Continuation US10459754B2 (en) 2015-12-21 2017-10-17 Method, apparatus, and system for discovering application topology relationship

Publications (1)

Publication Number Publication Date
WO2017107018A1 true WO2017107018A1 (zh) 2017-06-29

Family

ID=58238289

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/098125 WO2017107018A1 (zh) 2015-12-21 2015-12-21 应用拓扑关系发现的方法、装置和系统

Country Status (6)

Country Link
US (1) US10459754B2 (zh)
EP (1) EP3226493B1 (zh)
JP (1) JP6571161B2 (zh)
KR (1) KR101979363B1 (zh)
CN (2) CN110865867B (zh)
WO (1) WO2017107018A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115333966A (zh) * 2022-08-11 2022-11-11 天翼数字生活科技有限公司 一种基于拓扑的Nginx日志分析方法、系统及设备

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9912739B1 (en) * 2017-01-12 2018-03-06 Red Hat Israel, Ltd. Open virtualized multitenant network scheme servicing virtual machine and container based connectivity
CN108964959B (zh) * 2017-05-27 2022-02-25 阿里巴巴集团控股有限公司 一种用于虚拟化平台的网卡直通系统及数据包监管方法
CN109428824B (zh) * 2017-08-28 2021-09-17 中国电信股份有限公司 主机拓扑生成方法和系统
CN107861821B (zh) * 2017-10-26 2022-02-25 北京百度网讯科技有限公司 模块调用关系的挖掘方法、装置及计算机可读介质
CN109802842B (zh) * 2017-11-16 2021-12-03 华为技术有限公司 应用拓扑的生成方法及相关设备
CN109905436A (zh) * 2017-12-08 2019-06-18 华为软件技术有限公司 根因事件的确定方法、装置及存储介质
US10698664B2 (en) * 2017-12-21 2020-06-30 Fujitsu Limited API mashup generation
CN108038236A (zh) * 2017-12-27 2018-05-15 深信服科技股份有限公司 文件共享方法、装置、系统及可读存储介质
CN108388501B (zh) * 2018-01-10 2021-09-17 贝壳找房(北京)科技有限公司 一种系统间集成测试方法
CN110196750B (zh) * 2018-02-26 2023-02-24 华为技术有限公司 一种设备的分配方法及其相关设备
EP3841397A4 (en) 2018-08-26 2022-06-08 Celeno Communications (Israel) Ltd. WI-FI RADAR DETECTION USING A SYNCHRONIZED WIRELESS ACCESS POINT
CN109525515B (zh) * 2018-10-23 2021-04-30 郑州云海信息技术有限公司 一种云平台中网卡的管理方法和装置
US11240160B2 (en) * 2018-12-28 2022-02-01 Alibaba Group Holding Limited Method, apparatus, and computer-readable storage medium for network control
WO2020141417A1 (en) 2018-12-31 2020-07-09 Celeno Communications (Israel) Ltd. Coherent wi-fi radar using wireless access point
US11102750B2 (en) * 2019-01-01 2021-08-24 Celeno Communications (Israel) Ltd. Positioning system based on distributed transmission and reception of Wi-Fi signals
US11108642B2 (en) 2019-04-22 2021-08-31 Vmware, Inc. Method and apparatus for non-intrusive agentless platform-agnostic application topology discovery
US11055191B2 (en) * 2019-05-17 2021-07-06 Citrix Systems, Inc. Service graph highlights missing nodes and links
US11262990B2 (en) 2020-05-26 2022-03-01 International Business Machines Corporation Application topology discovery
CN113722020A (zh) * 2020-05-26 2021-11-30 腾讯科技（深圳）有限公司 接口调用方法、装置和计算机可读存储介质
CN114157931A (zh) * 2020-09-07 2022-03-08 中兴通讯股份有限公司 波分设备的拓扑关系确定方法、系统、设备及存储介质
CN114697319B (zh) * 2020-12-30 2023-06-16 华为云计算技术有限公司 一种公有云的租户业务管理方法及装置
US20220286939A1 (en) * 2021-03-05 2022-09-08 Vmware, Inc. Sdl cache for o-ran
CN113778423B (zh) * 2021-09-10 2024-03-01 上海幻电信息科技有限公司 接口文档生成方法及系统
CN114327748B (zh) * 2021-11-29 2022-10-18 北京志凌海纳科技有限公司 虚拟机交互方法、装置、非易失性存储介质及处理器
CN113992428B (zh) * 2021-11-29 2024-02-09 天融信雄安网络安全技术有限公司 容器环境下的入侵防御方法及装置、电子设备、存储介质
US20230171303A1 (en) * 2021-12-01 2023-06-01 X Development Llc Dynamic allocation of platform-independent machine learning state machines between edge-based and cloud-based computing resources
KR102486087B1 (ko) * 2022-09-16 2023-01-09 오픈나루 주식회사 Msa에서의 호출관계 추적 및 이에 따른 로그정보 디스플레이 방법
US11838176B1 (en) 2022-12-19 2023-12-05 Vmware, Inc. Provisioning and deploying RAN applications in a RAN system

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102137007A (zh) * 2011-01-17 2011-07-27 华为技术有限公司 网络拓扑生成方法、系统、协调者
CN103281248A (zh) * 2013-06-09 2013-09-04 北京星网锐捷网络技术有限公司 网络拓扑的发现方法、装置和系统
CN104468219A (zh) * 2014-12-11 2015-03-25 杭州华三通信技术有限公司 虚拟组网网络拓扑发现方法和设备
CN104618246A (zh) * 2015-02-12 2015-05-13 浪潮电子信息产业股份有限公司 一种面向xen虚拟化环境的网络拓扑发现方法
CN104639406A (zh) * 2013-11-07 2015-05-20 国际商业机器公司 基于动态使用关系建模计算机网络拓扑
US20150358235A1 (en) * 2014-06-05 2015-12-10 Futurewei Technologies, Inc. Service Chain Topology Map Construction

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7099580B1 (en) * 2001-11-02 2006-08-29 Ciena Corporation Method and system for communicating network topology in an optical communications network
US8255546B2 (en) * 2005-09-30 2012-08-28 Microsoft Corporation Peer name resolution protocol simple application program interface
US7774446B2 (en) * 2005-12-30 2010-08-10 Microsoft Corporation Discovering, defining, and implementing computer application topologies
JP5458308B2 (ja) * 2010-06-11 2014-04-02 株式会社日立製作所 仮想計算機システム、仮想計算機システムの監視方法及びネットワーク装置
CN102082692B (zh) 2011-01-24 2012-10-17 华为技术有限公司 基于网络数据流向的虚拟机迁移方法、设备和集群系统
CN102306156A (zh) * 2011-07-05 2012-01-04 成都智汇科技有限公司 用于交互式地编辑gis拓扑数据集的方法
US8943499B2 (en) * 2012-04-30 2015-01-27 Hewlett-Packard Development Company, L.P. Providing a virtual network topology in a data center
US9898317B2 (en) * 2012-06-06 2018-02-20 Juniper Networks, Inc. Physical path determination for virtual network packet flows
US9183033B2 (en) * 2012-12-06 2015-11-10 Industrial Technology Research Institute Method and system for analyzing root causes of relating performance issues among virtual machines to physical machines
EP2943880A4 (en) * 2013-01-12 2016-10-19 F5 Networks Inc USER INTERFACE FOR VISUALIZING RESOURCE PERFORMANCE AND MANAGING RESOURCES IN CLOUD OR DISTRIBUTED SYSTEMS
US9665474B2 (en) * 2013-03-15 2017-05-30 Microsoft Technology Licensing, Llc Relationships derived from trace data
US10069677B2 (en) * 2013-04-06 2018-09-04 Citrix Systems, Inc. Systems and methods to collect logs from multiple nodes in a cluster of load balancers
CN104363159B (zh) * 2014-07-02 2018-04-06 北京邮电大学 一种基于软件定义网络的开放虚拟网络构建系统和方法
CN105446792B (zh) * 2014-08-27 2019-09-24 联想(北京)有限公司 一种虚拟机的部署方法、部署装置和管理节点

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102137007A (zh) * 2011-01-17 2011-07-27 华为技术有限公司 网络拓扑生成方法、系统、协调者
CN103281248A (zh) * 2013-06-09 2013-09-04 北京星网锐捷网络技术有限公司 网络拓扑的发现方法、装置和系统
CN104639406A (zh) * 2013-11-07 2015-05-20 国际商业机器公司 基于动态使用关系建模计算机网络拓扑
US20150358235A1 (en) * 2014-06-05 2015-12-10 Futurewei Technologies, Inc. Service Chain Topology Map Construction
CN104468219A (zh) * 2014-12-11 2015-03-25 杭州华三通信技术有限公司 虚拟组网网络拓扑发现方法和设备
CN104618246A (zh) * 2015-02-12 2015-05-13 浪潮电子信息产业股份有限公司 一种面向xen虚拟化环境的网络拓扑发现方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Windows API Function Reference Manual", POST & TELCOM

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115333966A (zh) * 2022-08-11 2022-11-11 天翼数字生活科技有限公司 一种基于拓扑的Nginx日志分析方法、系统及设备
CN115333966B (zh) * 2022-08-11 2023-05-12 天翼数字生活科技有限公司 一种基于拓扑的Nginx日志分析方法、系统及设备

Also Published As

Publication number Publication date
BR112017000458A2 (pt) 2017-11-07
EP3226493B1 (en) 2020-03-25
US20180121226A1 (en) 2018-05-03
KR20180088577A (ko) 2018-08-06
CN110865867B (zh) 2023-08-25
KR101979363B1 (ko) 2019-05-16
EP3226493A4 (en) 2018-01-03
BR112017000458A8 (pt) 2022-08-23
CN110865867A (zh) 2020-03-06
US10459754B2 (en) 2019-10-29
EP3226493A1 (en) 2017-10-04
CN106489251A (zh) 2017-03-08
CN106489251B (zh) 2019-10-18
JP6571161B2 (ja) 2019-09-04
JP2018503275A (ja) 2018-02-01

Similar Documents

Publication Publication Date Title
WO2017107018A1 (zh) 应用拓扑关系发现的方法、装置和系统
US11870702B1 (en) Dynamic resource allocation of cloud instances and enterprise application migration to cloud architecture
US11296960B2 (en) Monitoring distributed applications
US9600319B2 (en) Computer-readable medium, apparatus, and method for offloading processing from a virtual switch to a physical switch
US11829797B1 (en) Dynamic configuration of virtual machines
JP5458308B2 (ja) 仮想計算機システム、仮想計算機システムの監視方法及びネットワーク装置
EP3281360B1 (en) Virtualized network function monitoring
EP3606008A1 (en) Method and device for realizing resource scheduling
US20130227566A1 (en) Data collection method and information processing system
WO2018072612A1 (zh) 一种切片实例的管理方法及装置
US10592266B1 (en) Dynamic consolidation of virtual machines
US10089128B2 (en) Application aware service policy enforcement and autonomous feedback-based remediation
US20140032753A1 (en) Computer system and node search method
US20190334776A1 (en) Creating and Using Service Control Functions
US10423439B1 (en) Automatic determination of a virtual machine&#39;s dependencies on storage virtualization
US20140337471A1 (en) Migration assist system and migration assist method
US7966394B1 (en) Information model registry and brokering in virtualized environments
US20220224586A1 (en) Intent-based distributed alarm service
KR20190114495A (ko) 네트워크 기능 가상화 환경에서 네트워크 자원 관리를 위한 장치 및 방법
JP2022087808A (ja) ストレージ・エリア・ネットワーク輻輳のエンドポイント通知を行う方法、システム、およびコンピュータ・プログラム
WO2016000430A1 (zh) 虚拟机对之间流量速率的估算方法和相关设备
WO2020000409A1 (en) Managing quality of storage service in virtual network
TWI767427B (zh) 監控伺服器及其設備資源監控方法
BR112017000458B1 (pt) Método, aparelho e sistema para descobrir uma relação de topologia de aplicativo

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 20177001923

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2017505627

Country of ref document: JP

Kind code of ref document: A

REEP Request for entry into the european phase

Ref document number: 2015908488

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15908488

Country of ref document: EP

Kind code of ref document: A1

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112017000458

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112017000458

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20170109

NENP Non-entry into the national phase

Ref country code: DE