US20220407818A1 - Container-aware application dependency identification - Google Patents
Container-aware application dependency identification Download PDFInfo
- Publication number
- US20220407818A1 US20220407818A1 US17/821,509 US202217821509A US2022407818A1 US 20220407818 A1 US20220407818 A1 US 20220407818A1 US 202217821509 A US202217821509 A US 202217821509A US 2022407818 A1 US2022407818 A1 US 2022407818A1
- Authority
- US
- United States
- Prior art keywords
- host computer
- computer systems
- application
- dependencies
- network traffic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 claims abstract description 57
- 238000012544 monitoring process Methods 0.000 claims abstract description 22
- 230000008569 process Effects 0.000 claims description 26
- 238000013459 approach Methods 0.000 abstract description 3
- 239000003795 chemical substances by application Substances 0.000 description 60
- 230000004044 response Effects 0.000 description 7
- 238000004590 computer program Methods 0.000 description 5
- 230000000977 initiatory effect Effects 0.000 description 5
- 238000013508 migration Methods 0.000 description 4
- 230000005012 migration Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000006855 networking Effects 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 3
- 238000007792 addition Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 241001388118 Anisotremus taeniatus Species 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/803—Application aware
-
- 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
- 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
-
- 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
-
- 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
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
- H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
-
- 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/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0876—Network utilisation, e.g. volume of load or congestion level
Definitions
- OS-less containers implement operating system—level virtualization, where an abstraction layer is provided on top of the kernel of an operating system on a host computer and the abstraction layer supports multiple OS-less containers each including an application.
- Each OS-less container runs as an isolated process in userspace on the host operating system and shares the kernel with other containers, and the OS-less containers rely on the kernel's functionality to make use of resource isolation (CPU, memory, block I/O, network, etc.) and separate namespaces and to completely isolate the application's view of the operating environments.
- resource isolation CPU, memory, block I/O, network, etc.
- IP internet protocol
- One embodiment provides a computer-implemented method of identifying application dependencies in a hybrid environment in which one or more applications run in operating system (OS)-less containers.
- the method generally includes monitoring network traffic at one or more host computer systems, where OS-less containers run in at least one of the host computer systems.
- the method further includes monitoring network traffic at virtual bridges to which the OS-less containers are attached, and identifying network dependencies based on the monitored network traffic at the host computer systems and the monitored network traffic at the virtual bridges.
- the method includes determining the application dependencies based on the identified network dependencies.
- FIG. 1 illustrates an approach for identifying application dependencies and generating an application dependency graph, according to an embodiment.
- FIG. 2 illustrates a method for determining application dependencies in a hybrid environment, according to an embodiment.
- FIG. 3 illustrates components of a system in which an embodiment may be implemented.
- Embodiments presented herein provide techniques for determining application dependencies in a hybrid environment in which applications run in virtual machines (VMs) and physical servers, as well as in operating system (OS)-less containers.
- agents running inside OS-less container host systems which may be VMs or physical machines, monitor both network traffic at the host systems and network traffic at virtual bridges to which the OS-less containers are attached.
- the agents then identify network dependencies based on the two types of monitored network traffic and transmit the network dependency information to a central server.
- network dependency refers to dependency of an application on a remote service at a certain internet protocol (IP) address and port, or vice versa.
- IP internet protocol
- the agents are able to identify network dependencies involving applications running in physical machines, VMs, and distinct OS-less containers. It should be understood that such network dependencies each indicate that an application is initiating or serving a request for/from a certain IP address and port number, but this is only half of an application dependency as the other application which is serving or initiating the same request, respectively, is not explicitly indicated.
- network dependencies from multiple agents in different machines are collected in a central server and analyzed to identify, based on the network dependencies, the applications that depend on each other.
- network data obtained from a Transmission Control Protocol (TCP) dump of one virtual bridge that is connected to OS-less containers and similar data obtained from another virtual bridge may be collected at the central server to identify dependencies between applications running in the containers.
- the identified application dependencies may then be displayed to a user via a user interface to, e.g., assist in datacenter migration.
- TCP Transmission Control Protocol
- FIG. 1 illustrates an approach for identifying network dependencies of applications and generating an application dependency graph, according to an embodiment.
- applications 111 - 113 and 114 - 115 run in VMs 101 2 and 101 3 , respectively, while OS-less containers 121 - 124 run in VM 101 1 .
- Each of the VMs 101 1-3 is a virtualization of a complete computer system—with processors, memory, networking, storage, and/or BIOS.
- VMs 101 1-3 run on a virtualization layer (also referred to as a “hypervisor”) that abstracts processor, memory, storage, and/or networking resources into multiple virtual machines (e.g., VMs 101 1-3 ) that run side-by-side on the same physical host computer.
- a virtualization layer also referred to as a “hypervisor”
- the virtualization software partitions the physical host computer into multiple secure and portable virtual machines that run on the same physical computer.
- virtualization software may be installed directly on the server hardware and inserts a virtualization layer between the hardware and the operating system.
- the virtualization software may run on top of a conventional operating system in the server.
- OS-less containers 121 - 124 implement operating system—level virtualization in which an abstraction layer is provided on top of the kernel of an operating system.
- the abstraction layer supports multiple OS-less containers 121 - 124 , each including an application and running as an isolated process in userspace on the operating system of VM 101 1 while sharing the kernel with other containers.
- OS-less containers resources can be isolated, services restricted, and processes provisioned to have a private view of the operating system with their own process ID space, file system structure, and network interfaces.
- Multiple containers may share the same kernel, but each container can be constrained to only use a defined amount of resources such as CPU, memory and I/O.
- applications 111 - 112 depend on each other, as do applications 112 and 114 .
- Application 115 and an application running inside OS-less container 121 depend on each other as well.
- applications running in OS-less containers 123 - 124 also depend on each other.
- an application network monitoring agent 120 1-3 is registered to each of the VMs 101 1-3 (e.g., whenever a new VM is deployed or a VM without a monitoring agent is identified).
- Application network monitoring agent 120 1-3 is responsible for identifying network dependencies of applications by monitoring network packets.
- agents 120 1-3 first discover the list of services running in VMs 101 1-3 and network dependencies of the same. Then, if any of the services are OS-less container daemons that manage containers, which is the case for VM 101 1 , agent 120 1 further identifies OS-less container services that are running and the external ports used by the container services to accept requests, the internal ports used by the container services to process requests, and the local IP addresses of the container services. Using a TCP dump from virtual Ethernet bridge 126 to which containers 121 - 124 are connected, agent 120 1 captures network packet details from virtual bridge 126 , which is used to identify network dependencies involving applications in OS-less containers. Such network dependencies, as well as network dependencies identified by agent 120 1 , are sent to application dependency generator server 130 , which stores and analyzes the network dependencies to determine application dependencies.
- application dependency generator server 130 is a web application which includes a data collection service 132 responsible for receiving network dependency information from agents 120 1-3 and storing such information in a database, as well as an application dependency generator service 134 responsible for determining application dependencies using the stored network dependency information.
- the stored information may include a list of registered agents 120 1-3 , a list of VMs in the datacenter, a list of the VMs running OS-less containers, a list of the containers present inside the VMs running OS-less containers and their mappings to the corresponding VMs, a list of applications running inside the VMs or OS-less containers or physical machines, and network communication details from one application to another.
- dependency generator service 134 may determine application dependencies by generating a hash map which has from interne protocol (IP) address, to IP address, and port number as keys and application names as values, and identifying each pair of applications associated with the same key in the hash map as being dependent on each other, as discussed in greater detail below.
- Dependency generator service 134 may further create an application dependency graph that indicates all application dependencies in the datacenter.
- agent 120 3 discovers applications running in VM 101 3 by executing the Linux® command “netstat-nlpt,” example output of which is shown in Table 1, and agent 120 3 identifies from such output a list of processes, which will serve client requests, and their listening port numbers.
- Agent 120 3 may also check for a Docker OS-less container daemon service that manages contaires using, e.g., the command “ps-aux
- Agent 120 3 further obtains the process descriptions for the processes using the command “ps-aux
- agent 120 3 can identify network dependencies involving this process. For example, agent 120 3 may use the command “netstat-ntupc
- the response to such a command an example of which is shown in Table 3, will include connections opened by this process.
- agent 120 3 can identify that the TomcatTM process has a dependency on a service running on 10.112.73.157 and listening at port 49153. It should be understood that, at this point, agent 120 3 is unaware what the other service is. However, once a network dependency is identified, agent 120 3 pushes this information to dependency generator server 130 in, e.g., the XML format shown in Table 4.
- agent 120 1 running therein identifies services running in VM 101 1 in a similar manner as that discussed above with respect to agent 120 3 .
- agent 120 1 may check for network services running in VM 101 1 using the netstat command “netstat-nlpt.” As the Python web application is running in OS-less container 121 , agent 120 1 will not identify any network services with the netstat command.
- Agent 120 1 further checks for a Docker OS-less container daemon service using the command “ps-aux
- agent 120 1 can identify OS-less container services and ports assigned to the same.
- agent 120 1 may identify the external and internal ports used by the OS-less container process, which in this example are 49153 and 5000, respectively.
- agent 120 1 may obtain the IP address of the OS-less container services using the command “Docker inspect-format ‘ ⁇ .NetworkSettings.IPAddress ⁇ ’ container_id,” an example response to which may be “171.17.0.2.” Thereafter, agent 120 1 may capture, from virtual bridge 126 , the network packets for each such OS-less container service using the TCP dump command “Tcpdump-I docker0
- Agent 120 1 is able to identify incoming and outgoing requests from the service by examining the port number in the packets.
- the port number used by the packets is a listening port number, indicating an incoming request which originated from 10.112.73.92 at port 51995.
- Agent 120 1 then reports to server 130 the public address of the machine (physical or virtual) in which the OS-less containers are running and the public port that the OS-container service is using.
- the report may be made in the XML, format shown in Table 6.
- FIG. 2 illustrates a method 200 for determining application dependency in a hybrid environment, according to an embodiment.
- method 200 begins at step 210 , where agents 120 1-3 monitor network traffic at host computer systems, at least one of which runs OS-less containers. It should be understood that the host computer systems may be virtual or physical machines.
- agents 120 1-3 first identify services running on the hosts using, e.g., the “netstat-nlpt” command. Agents 120 1-3 then identify, for each service, the corresponding listening port and process ID, using which agents 120 1-3 may obtain the process descriptions of the services using, e.g., the “ps-aux
- Agents 120 1-3 then monitor network traffic by continuously monitoring each service using, e.g., the command “netstat-ntupc
- grep pid” to identify incoming and outgoing connections. Agents 120 1-3 will be able to differentiate incoming and outgoing connections by examining the port numbers used. If the port numbers are the same as listening port numbers, then the connections are incoming connections. Otherwise, the connections are outgoing connections from the service.
- agents 120 1-3 identify network dependencies based on the monitored network traffic at the host computer systems. As discussed, agents 120 1-3 are able to identify network dependencies of services and other systems which are dependent on the services using the network traffic information collected at step 210 . For example, agents 120 1-3 may identify network dependencies by examining connections opened by the services.
- agents 120 1-3 monitor network traffic at virtual bridges to which the OS-less containers are attached.
- agents 120 1-3 first identify OS-less container daemon processes that manage OS-less containers using, e.g., the “ps-aux
- agents 120 1-3 obtain the assigned local IP address for each container service using, e.g., the command “Docker inspect-format ‘ ⁇ .NetworkSettings.IPAddress ⁇ ’ container_id.” Agents 120 1-3 then capture network packet details from virtual bridges using, e.g., the TCP dump command “tcpdump-i docker0.”
- agents 120 1-3 identify network dependencies based on the monitored network traffic at the virtual bridges.
- the captured TCP dump discussed above provides incoming and outgoing packet details, using which agents 120 1-3 may identify the list of network dependencies for each OS-less container service.
- Agents 120 1-3 may also be able to distinguish between incoming and outgoing connections by examining the port numbers used by the network packets. If a packet has a listening port number, then the packet is associated with an incoming connection request. Otherwise, the packet is associated with an outgoing connection request from the service. Agents 120 1-3 are thus able to identify systems which are dependent on the OS-less container services and dependencies of the same services.
- agents 120 1-3 transmit the identified network dependencies to application dependency generator server 130 .
- the identified network dependencies may be transmitted and stored in any format. Further, it should be understood that the transmitting of network dependencies may occur on a continual basis as new network dependencies are identified, rather than as one of a sequence of linear steps as shown in method 300 .
- the following XML format may be used to transmit newly identified dependencies in one embodiment:
- a database table with “from IP,” “to IP,” “port,” “application name,” and “is initiator” fields may then be updated with the transmitted values.
- application dependency generator service 134 determines application dependencies based on the identified network dependencies. After identified network dependencies are received by application dependency generator server 130 , dependency generator service 134 is responsible for analyzing the network dependencies and determining application dependencies. As discussed, the network dependencies records each indicate that an application is initiating or serving a request for/from a certain IP address and port number, but this is only half of an application dependency as the other application which is serving or initiating the same request, respectively, is not explicitly specified. Accordingly, dependency generator service 134 matches network dependency records indicating applications initiating requests with corresponding network dependency records indicating other applications serving the same requests to determine that those applications have dependency relationships with each other.
- dependency generator service 134 generates an application dependency graph based on a hash map constructed with the network dependency information.
- dependency generator service 134 may construct the hash map with the key being the “from IP,” “to IP,” and “port number” of the network dependencies that are stored by application dependency generator server 130 , and the value being the corresponding applications. Doing so essentially groups the applications by the key “from IP,” “to IP,” and “port number.” After such processing, each key should be associated with two values: one is a service provider application and the other a service requestor application.
- one key-value pairing may be ⁇ ([VM1 IP, VM2 IP, Port], [Web_app, Post-gres_db]) ⁇ , which indicates that the “Web_app” and “Post-gres_db” have a dependency.
- Dependency generator service 134 is thus able to generate the application dependency graph that indicates all application dependencies based on such hash map entries.
- the dependencies may further be displayed to a user via, e.g., a graphical user interface.
- FIG. 3 illustrates components of a system 300 in which an embodiment may be implemented.
- the system 300 includes a host computers 100 1-N and 100 M in communication with a server 128 .
- Host computers 100 1-N are configured to deliver virtualization-based distributed services to information technology environments.
- Host computers 100 1-N may be constructed on conventional hardware platforms that include one or more central processing units, memory, and physical network interface cards (e.g., PNICs 161 - 162 ).
- host computer 100 M is a physical server which may also include conventional hardware platforms, as it should be understood that techniques disclosed herein may be employed with physical computer systems that do not host virtual machines.
- the physical computer system embodiment which works in a similar manner as the VM embodiment, will not be described in detail.
- host computers 100 1-N each provides a virtualization layer (e.g., hypervisor 140 ) that abstracts processor, memory, storage, and/or networking resources into multiple virtual machines (e.g., VMs 101 1-N ) that run side-by-side on the same physical host computer 100 1-N . That is, the virtualization software partitions physical host computers 100 1-N into multiple secure and portable virtual machines that run on the same physical servers.
- a virtualization layer e.g., hypervisor 140
- VMs 101 1-N virtual machines that run side-by-side on the same physical host computer 100 1-N . That is, the virtualization software partitions physical host computers 100 1-N into multiple secure and portable virtual machines that run on the same physical servers.
- each of the VMs e.g., VMs 101 1-N
- each of the VMs 101 1-N further includes a software-based virtual network adapter (e.g., VNIC 141 ) that is logically connected to a physical network adapter (e.g., PNIC 161 ) included in the host computer, which provides network access for the virtual machine, via a virtual switch 150 , which as shown is a distributed virtual switch spanning multiple host computers 100 1-N .
- VNIC 141 software-based virtual network adapter
- PNIC 161 physical network adapter
- virtual switch 150 which as shown is a distributed virtual switch spanning multiple host computers 100 1-N .
- a guest OS runs in VMs 101 N and applications run on the guest OS.
- OS-less containers e.g., container 121
- OS-less containers such as container 121 implement operating system-level virtualization, where an abstraction layer is provided on top of the kernel of an operating system (not shown).
- the abstraction layer supports multiple OS-less containers each including an application, and each OS-less container runs as an isolated process in userspace on the host operating system and shares the kernel with other containers.
- a virtual Ethernet bridge 180 connected to VNIC 141 and the OS-less containers is responsible for forwarding packets between the network interfaces attached to bridge 180 .
- the abstraction layer that supports the OS-less containers also creates a pair of virtual Ethernet (vEth) interfaces, one of which is assigned to the new OS-less container's network namespace and the other of which is connected to bridge 180 .
- the pair of vEths are tunnel drivers that act as a bidirectional pipe, with traffic entering one vEth in the pair exiting the other vEth.
- an application network monitoring agent (e.g., agent 120 1 ) runs in each of VMs 101 1-N .
- these agents are configured to monitor network traffic at host computer systems (which would be VMs 101 1-N in this case), identify network dependencies based on the monitored network traffic at the host computer systems, further monitor network traffic at virtual bridges to which OS-less containers are attached, identify network dependencies based on the monitored network traffic at the virtual bridges, and transmit the identified network dependencies to application dependency generator server 130 , according to method 200 discussed above with respect to FIG. 2 .
- application dependency generator service 134 determines application dependencies based on the identified network dependencies by, e.g., constructing a hash map with the network dependency information and identifying pairs of applications which have a dependency relationship, as discussed above.
- techniques disclosed herein permit application dependencies to be identified in a hybrid environment in which applications run in virtual machines (VMs) and physical servers, as well as in operating system (OS)-less containers.
- VMs virtual machines
- OS operating system
- cloud administrators can better plan for datacenter work load migrations.
- application downtime due to partial datacenter migrations in which applications that are depended upon are not migrated can be avoided.
- the maintenance period for a datacenter can be determined in advance and the user alerted to the application downtime.
- disaster recovery of applications can be planned earlier while accounting for application dependencies.
- the various embodiments described herein may employ various computer-implemented operations involving data stored in computer systems. For example, these operations may require physical manipulation of physical quantities usually, though not necessarily, these quantities may take the form of electrical or magnetic signals where they, or representations of them, are capable of being stored, transferred, combined, compared, or otherwise manipulated. Further, such manipulations are often referred to in terms, such as producing, identifying, determining, or comparing. Any operations described herein that form part of one or more embodiments of the invention may be useful machine operations.
- one or more embodiments of the invention also relate to a device or an apparatus for performing these operations. The apparatus may be specially constructed for specific required purposes, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer.
- various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.
- One or more embodiments of the present invention may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media.
- the term computer readable medium refers to any data storage device that can store data which can thereafter be input to a computer system computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer.
- Examples of a computer readable medium include a hard drive, network attached storage (NAS), read-only memory, random-access memory (e.g., a flash memory device), a CD (Compact Discs), CD-ROM, a CD-R, or a CD-RW, a DVD (Digital Versatile Disc), a magnetic tape, and other optical and non-optical data storage devices.
- the computer readable medium can also be distributed over a network coupled computer system so that the computer readable code is stored and executed in a distributed fashion.
- the virtualization software can therefore include components of a host, console, or guest operating system that performs virtualization functions.
- Plural instances may be provided for components, operations or structures described herein as a single instance.
- boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the invention(s).
- structures and functionality presented as separate components in exemplary configurations may be implemented as a combined structure or component.
- structures and functionality presented as a single component may be implemented as separate components.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Stored Programmes (AREA)
- Computer And Data Communications (AREA)
- Debugging And Monitoring (AREA)
Abstract
Description
- The present patent application is a continuation of, and hereby claims priority under 35 U.S.C § 120 to pending U.S. patent application Ser. No. 14/841,737, entitled “Container-Aware Application Dependency Identification,” by the same inventors, filed on 1 Sep. 2015, the contents of which are herein incorporated in their entirety by reference for all purposes.
- The importance of understanding application dependency in virtualized environments has been recognized. For example, datacenter migration preplanning typically includes considering application dependency to ensure applications that depend on each other are migrated together. VMware® Application Dependency Planner is a commercially available tool providing application discovery and dependency mapping for virtual environments.
- Applications may also be deployed in hybrid environments in which some applications run in VMs, other applications run in physical servers, and still other applications run in operating system (OS)-less containers. OS-less containers implement operating system—level virtualization, where an abstraction layer is provided on top of the kernel of an operating system on a host computer and the abstraction layer supports multiple OS-less containers each including an application. Each OS-less container runs as an isolated process in userspace on the host operating system and shares the kernel with other containers, and the OS-less containers rely on the kernel's functionality to make use of resource isolation (CPU, memory, block I/O, network, etc.) and separate namespaces and to completely isolate the application's view of the operating environments. Traditional techniques for determining application dependency based on network traffic are unable to identify application dependencies involving OS-less containers. The internal container network and private internet protocol (IP) addresses for each of the OS-less containers is typically hidden, while network traffic from the containers all use the same public IP address and port number associated with the virtual Ethernet bridge to which the containers are connected. As a result, traditional techniques are unable distinguish between multiple OS-less containers and the applications running therein.
- One embodiment provides a computer-implemented method of identifying application dependencies in a hybrid environment in which one or more applications run in operating system (OS)-less containers. The method generally includes monitoring network traffic at one or more host computer systems, where OS-less containers run in at least one of the host computer systems. The method further includes monitoring network traffic at virtual bridges to which the OS-less containers are attached, and identifying network dependencies based on the monitored network traffic at the host computer systems and the monitored network traffic at the virtual bridges. In addition, the method includes determining the application dependencies based on the identified network dependencies.
- Further embodiments include a non-transitory computer-readable storage medium storing instructions that when executed by a computer system cause the computer system to perform the method set forth above, and a computer system programmed to carry out the method set forth above.
-
FIG. 1 illustrates an approach for identifying application dependencies and generating an application dependency graph, according to an embodiment. -
FIG. 2 illustrates a method for determining application dependencies in a hybrid environment, according to an embodiment. -
FIG. 3 illustrates components of a system in which an embodiment may be implemented. - Embodiments presented herein provide techniques for determining application dependencies in a hybrid environment in which applications run in virtual machines (VMs) and physical servers, as well as in operating system (OS)-less containers. In one embodiment, agents running inside OS-less container host systems, which may be VMs or physical machines, monitor both network traffic at the host systems and network traffic at virtual bridges to which the OS-less containers are attached. The agents then identify network dependencies based on the two types of monitored network traffic and transmit the network dependency information to a central server. As used herein, network dependency refers to dependency of an application on a remote service at a certain internet protocol (IP) address and port, or vice versa. By considering both the network traffic at the host system level and the network traffic at the virtual bridge level, which indicates incoming and outgoing connections to/from particular OS-less containers connected to the bridge, the agents are able to identify network dependencies involving applications running in physical machines, VMs, and distinct OS-less containers. It should be understood that such network dependencies each indicate that an application is initiating or serving a request for/from a certain IP address and port number, but this is only half of an application dependency as the other application which is serving or initiating the same request, respectively, is not explicitly indicated. In order to determine application dependencies, network dependencies from multiple agents in different machines (physical and/or virtual) are collected in a central server and analyzed to identify, based on the network dependencies, the applications that depend on each other. For example, network data obtained from a Transmission Control Protocol (TCP) dump of one virtual bridge that is connected to OS-less containers and similar data obtained from another virtual bridge may be collected at the central server to identify dependencies between applications running in the containers. The identified application dependencies may then be displayed to a user via a user interface to, e.g., assist in datacenter migration.
- Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying figures. It is noted that wherever practicable similar or like reference numbers may be used in the figures and may indicate similar or like functionality. The figures depict embodiments for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and method illustrated herein may be employed without departing from the principles described herein.
-
FIG. 1 illustrates an approach for identifying network dependencies of applications and generating an application dependency graph, according to an embodiment. As shown, applications 111-113 and 114-115 run in VMs 101 2 and 101 3, respectively, while OS-less containers 121-124 run in VM 101 1. Each of the VMs 101 1-3 is a virtualization of a complete computer system—with processors, memory, networking, storage, and/or BIOS. VMs 101 1-3 run on a virtualization layer (also referred to as a “hypervisor”) that abstracts processor, memory, storage, and/or networking resources into multiple virtual machines (e.g., VMs 101 1-3) that run side-by-side on the same physical host computer. That is, the virtualization software partitions the physical host computer into multiple secure and portable virtual machines that run on the same physical computer. In one embodiment, virtualization software may be installed directly on the server hardware and inserts a virtualization layer between the hardware and the operating system. Alternatively, the virtualization software may run on top of a conventional operating system in the server. Although depicted as VMs 101 1-3 inFIG. 1 , it should be understood that techniques disclosed herein are applicable to physical machines as well, i.e., that any of VMs 101 1-3 could instead be a physical machine. - In contrast to VMs, OS-less containers 121-124 implement operating system—level virtualization in which an abstraction layer is provided on top of the kernel of an operating system. As discussed, the abstraction layer supports multiple OS-less containers 121-124, each including an application and running as an isolated process in userspace on the operating system of VM 101 1 while sharing the kernel with other containers. By using OS-less containers, resources can be isolated, services restricted, and processes provisioned to have a private view of the operating system with their own process ID space, file system structure, and network interfaces. Multiple containers may share the same kernel, but each container can be constrained to only use a defined amount of resources such as CPU, memory and I/O.
- Illustratively, applications 111-112 depend on each other, as do
applications Application 115 and an application running insideOS-less container 121 depend on each other as well. Further, applications running in OS-less containers 123-124 also depend on each other. In order to identify dependencies of the applications, and in particular dependencies involving applications running in OS-less containers 121-124, an application network monitoring agent 120 1-3 is registered to each of the VMs 101 1-3 (e.g., whenever a new VM is deployed or a VM without a monitoring agent is identified). Application network monitoring agent 120 1-3 is responsible for identifying network dependencies of applications by monitoring network packets. In one embodiment, agents 120 1-3 first discover the list of services running in VMs 101 1-3 and network dependencies of the same. Then, if any of the services are OS-less container daemons that manage containers, which is the case for VM 101 1, agent 120 1 further identifies OS-less container services that are running and the external ports used by the container services to accept requests, the internal ports used by the container services to process requests, and the local IP addresses of the container services. Using a TCP dump fromvirtual Ethernet bridge 126 to which containers 121-124 are connected, agent 120 1 captures network packet details fromvirtual bridge 126, which is used to identify network dependencies involving applications in OS-less containers. Such network dependencies, as well as network dependencies identified by agent 120 1, are sent to applicationdependency generator server 130, which stores and analyzes the network dependencies to determine application dependencies. - As shown, application
dependency generator server 130 is a web application which includes adata collection service 132 responsible for receiving network dependency information from agents 120 1-3 and storing such information in a database, as well as an applicationdependency generator service 134 responsible for determining application dependencies using the stored network dependency information. In one embodiment, the stored information may include a list of registered agents 120 1-3, a list of VMs in the datacenter, a list of the VMs running OS-less containers, a list of the containers present inside the VMs running OS-less containers and their mappings to the corresponding VMs, a list of applications running inside the VMs or OS-less containers or physical machines, and network communication details from one application to another. In another embodiment,dependency generator service 134 may determine application dependencies by generating a hash map which has from interne protocol (IP) address, to IP address, and port number as keys and application names as values, and identifying each pair of applications associated with the same key in the hash map as being dependent on each other, as discussed in greater detail below.Dependency generator service 134 may further create an application dependency graph that indicates all application dependencies in the datacenter. - For example, assume that
application 115 is an Apache Tomcat™ web server application that depends on a Python web application running inOS-less container 121. Then, the dependency between theTomcat™ application 115 and the Python webapplication running container 121 may be determined in one embodiment as follows. Agent 120 3 discovers applications running in VM 101 3 by executing the Linux® command “netstat-nlpt,” example output of which is shown in Table 1, and agent 120 3 identifies from such output a list of processes, which will serve client requests, and their listening port numbers. Agent 120 3 may also check for a Docker OS-less container daemon service that manages contaires using, e.g., the command “ps-aux|grep docker.” However, no such service will be identified because no such service is running in VM 101 2. -
TABLE 1 PID/ Proto Recv-Q Send-Q Local Address Foreign Address State Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 15020/sshd tcp6 0 0 :::8080 :::* LISTEN 15191/java
Agent 120 3 further obtains the process descriptions for the processes using the command “ps-aux|grep pid.” An example response to such a command is shown in Table 2. -
TABLE 2 smannam 15191 0.2 8.3 1393336 85140 ? Sl 22:35 0:05 /usr/bin/java - Djava.util.logging.config.file=/home/smannam/apache- tomcat-7.0.57/conf/logging.properties - Djava.util.logging.manager=org.apache.juli.ClassLoaderL ogManager Djava.endorsed.dirs=/home/smannam/apache-tomcat- 7.0.57/endorsed -classpath /home/smannam/apache- tomcat- 7.0.57/bin/bootstrap.jar:/home/smannam/apache-tomcat- 7.0.57/bin/tomcat-juli.jar Dcatalina.base=/home/smannam/apache-tomcat-7.0.57 -Dcatalina.home=/home/smannam/apache-tomcat- 7.0.57 - Djava.io.tmpdir=/home/smannam/apache- tomcat-7.0.57/temp org.apache.catalina.startup.Bootstrap start
By parsing the information in Tables 1 and 2, agent 120 3 is able to identify that VM 101 2 has a Tomcat™ process running at port 8080. By continuously monitoring all network connections opened by the Tomcat™ process, agent 120 3 can identify network dependencies involving this process. For example, agent 120 3 may use the command “netstat-ntupc|grep pid|prep-v listeningport” for this purpose, with pid being the process ID of the Tomcat™ process. The response to such a command, an example of which is shown in Table 3, will include connections opened by this process. -
TABLE 3 Local Address Foreign Address State PID/Program name 10.112.73.92:51969 10.112.73.157:49153 ESTABLISHED 15191/java
From such a response, agent 120 3 can identify that the Tomcat™ process has a dependency on a service running on 10.112.73.157 and listening at port 49153. It should be understood that, at this point, agent 120 3 is unaware what the other service is. However, once a network dependency is identified, agent 120 3 pushes this information todependency generator server 130 in, e.g., the XML format shown in Table 4. -
TABLE 4 <dependency> <from-ip>10.112.73.92</from-ip> <to-ip>10.112.73.157</to-ip> <port>49153</port> <app-name>tomcat</app-name> <isRequestInitator>true</isRequestInitiator> </dependency> - Turning to VM 101 1, agent 120 1 running therein identifies services running in VM 101 1 in a similar manner as that discussed above with respect to agent 120 3. In particular, agent 120 1 may check for network services running in VM 101 1 using the netstat command “netstat-nlpt.” As the Python web application is running in
OS-less container 121, agent 120 1 will not identify any network services with the netstat command. Agent 120 1 further checks for a Docker OS-less container daemon service using the command “ps-aux|grep docker.” Onceagent 1203 identifies that such a service is running in VM 101 1, agent 120 1 further identifies all container processes and their ports using the command “docker ps.” The response to this command, an example of which is shown in Table 5, will list Docker container processes running and the port numbers at which requests are expected. -
TABLE 5 CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7e8eb5fa447a python webapp python app.py 4 hours ago Up 4 hours 0.0.0.0:49153−>5000/tcp condescending_mccarthy
By parsing such a response, agent 120 1 can identify OS-less container services and ports assigned to the same. In particular, agent 120 1 may identify the external and internal ports used by the OS-less container process, which in this example are 49153 and 5000, respectively. Then, agent 120 1 may obtain the IP address of the OS-less container services using the command “Docker inspect-format ‘{{.NetworkSettings.IPAddress}}’ container_id,” an example response to which may be “171.17.0.2.” Thereafter, agent 120 1 may capture, fromvirtual bridge 126, the network packets for each such OS-less container service using the TCP dump command “Tcpdump-I docker0|grep container_ip,” an example response to which may be: - 02:10:25.814181 IP 10.112.73.92.51969>
- 172.17.0.2.5000: Flags [F.], seq 202
- 02:10:25.814206 IP 172.17.0.2.5000>
- 10.112.73.92.51969: Flags [.], ack 203
- Agent 120 1 is able to identify incoming and outgoing requests from the service by examining the port number in the packets. In this case, the port number used by the packets is a listening port number, indicating an incoming request which originated from 10.112.73.92 at port 51995. Agent 120 1 then reports to
server 130 the public address of the machine (physical or virtual) in which the OS-less containers are running and the public port that the OS-container service is using. For example, the report may be made in the XML, format shown in Table 6. -
TABLE 6 <dependency> <from-ip>10.112.73.92</from-ip> <to-ip>10.112.73.157</to-ip> <port>49153</port> <app-name>python webapp</app-name> <isRequestInitator>false</isRequestInitiator> </dependency>
Using both this information and the information obtained from VM 101 3, illustrated in Table 4, applicationdependency generator service 134 can identify that the Tomcat™ service running in VM 101 3 depends on the Python webapp service running in the OS-less container in VM 101 1. It will be understood that agent 120 1 can also identify network dependencies of OS-less container services in a similar manner by examining outgoing network packet details fromvirtual bridge 126. -
FIG. 2 illustrates amethod 200 for determining application dependency in a hybrid environment, according to an embodiment. As shown,method 200 begins atstep 210, where agents 120 1-3 monitor network traffic at host computer systems, at least one of which runs OS-less containers. It should be understood that the host computer systems may be virtual or physical machines. In one embodiment, agents 120 1-3 first identify services running on the hosts using, e.g., the “netstat-nlpt” command. Agents 120 1-3 then identify, for each service, the corresponding listening port and process ID, using which agents 120 1-3 may obtain the process descriptions of the services using, e.g., the “ps-aux|grep pid” command and name the service accordingly. Agents 120 1-3 then monitor network traffic by continuously monitoring each service using, e.g., the command “netstat-ntupc|grep pid” to identify incoming and outgoing connections. Agents 120 1-3 will be able to differentiate incoming and outgoing connections by examining the port numbers used. If the port numbers are the same as listening port numbers, then the connections are incoming connections. Otherwise, the connections are outgoing connections from the service. - At
step 220, agents 120 1-3 identify network dependencies based on the monitored network traffic at the host computer systems. As discussed, agents 120 1-3 are able to identify network dependencies of services and other systems which are dependent on the services using the network traffic information collected atstep 210. For example, agents 120 1-3 may identify network dependencies by examining connections opened by the services. - At
step 230, agents 120 1-3 monitor network traffic at virtual bridges to which the OS-less containers are attached. In one embodiment, agents 120 1-3 first identify OS-less container daemon processes that manage OS-less containers using, e.g., the “ps-aux|grep daemon” command. If an OS-less container daemon is running, agents 120 1-3 then identify a list of container services using, e.g., the “docker ps” command in the case of Docker containers. Assuming such container services are running, agents 120 1-3 further identify, for each container service, the external port used on the host system to accept service requests and the internal port used by the container service to process the same. In addition, agents 120 1-3 obtain the assigned local IP address for each container service using, e.g., the command “Docker inspect-format ‘{{.NetworkSettings.IPAddress}}’ container_id.” Agents 120 1-3 then capture network packet details from virtual bridges using, e.g., the TCP dump command “tcpdump-i docker0.” - At
step 240, agents 120 1-3 identify network dependencies based on the monitored network traffic at the virtual bridges. The captured TCP dump discussed above provides incoming and outgoing packet details, using which agents 120 1-3 may identify the list of network dependencies for each OS-less container service. Agents 120 1-3 may also be able to distinguish between incoming and outgoing connections by examining the port numbers used by the network packets. If a packet has a listening port number, then the packet is associated with an incoming connection request. Otherwise, the packet is associated with an outgoing connection request from the service. Agents 120 1-3 are thus able to identify systems which are dependent on the OS-less container services and dependencies of the same services. - At
step 250, agents 120 1-3 transmit the identified network dependencies to applicationdependency generator server 130. The identified network dependencies may be transmitted and stored in any format. Further, it should be understood that the transmitting of network dependencies may occur on a continual basis as new network dependencies are identified, rather than as one of a sequence of linear steps as shown inmethod 300. The following XML format may be used to transmit newly identified dependencies in one embodiment: - <dependency>
-
- <from-ip>address 1</from-ip>
- <to-ip>address 2</to-ip>
- <port>port number</port>
- <app-name>application name</app-name>
- <isRequestInitator>Boolean value</isRequestInitiator>
- </dependency>
- In such a case, a database table with “from IP,” “to IP,” “port,” “application name,” and “is initiator” fields may then be updated with the transmitted values.
- At
step 260, applicationdependency generator service 134 determines application dependencies based on the identified network dependencies. After identified network dependencies are received by applicationdependency generator server 130,dependency generator service 134 is responsible for analyzing the network dependencies and determining application dependencies. As discussed, the network dependencies records each indicate that an application is initiating or serving a request for/from a certain IP address and port number, but this is only half of an application dependency as the other application which is serving or initiating the same request, respectively, is not explicitly specified. Accordingly,dependency generator service 134 matches network dependency records indicating applications initiating requests with corresponding network dependency records indicating other applications serving the same requests to determine that those applications have dependency relationships with each other. - In one embodiment,
dependency generator service 134 generates an application dependency graph based on a hash map constructed with the network dependency information. In such a case,dependency generator service 134 may construct the hash map with the key being the “from IP,” “to IP,” and “port number” of the network dependencies that are stored by applicationdependency generator server 130, and the value being the corresponding applications. Doing so essentially groups the applications by the key “from IP,” “to IP,” and “port number.” After such processing, each key should be associated with two values: one is a service provider application and the other a service requestor application. For example, one key-value pairing may be {([VM1 IP, VM2 IP, Port], [Web_app, Post-gres_db])}, which indicates that the “Web_app” and “Post-gres_db” have a dependency.Dependency generator service 134 is thus able to generate the application dependency graph that indicates all application dependencies based on such hash map entries. The dependencies may further be displayed to a user via, e.g., a graphical user interface. -
FIG. 3 illustrates components of asystem 300 in which an embodiment may be implemented. As shown, thesystem 300 includes a host computers 100 1-N and 100 M in communication with aserver 128. Host computers 100 1-N are configured to deliver virtualization-based distributed services to information technology environments. Host computers 100 1-N may be constructed on conventional hardware platforms that include one or more central processing units, memory, and physical network interface cards (e.g., PNICs 161-162). As shown host computer 100 M is a physical server which may also include conventional hardware platforms, as it should be understood that techniques disclosed herein may be employed with physical computer systems that do not host virtual machines. For conciseness, the physical computer system embodiment, which works in a similar manner as the VM embodiment, will not be described in detail. - Illustratively, host computers 100 1-N each provides a virtualization layer (e.g., hypervisor 140) that abstracts processor, memory, storage, and/or networking resources into multiple virtual machines (e.g., VMs 101 1-N) that run side-by-side on the same physical host computer 100 1-N. That is, the virtualization software partitions physical host computers 100 1-N into multiple secure and portable virtual machines that run on the same physical servers. As discussed, each of the VMs (e.g., VMs 101 1-N) represents a complete system—with processors, memory, networking, storage, and/or BIOS. As shown, each of the VMs 101 1-N further includes a software-based virtual network adapter (e.g., VNIC 141) that is logically connected to a physical network adapter (e.g., PNIC 161) included in the host computer, which provides network access for the virtual machine, via a
virtual switch 150, which as shown is a distributed virtual switch spanning multiple host computers 100 1-N. - Illustratively, a guest OS runs in VMs 101 N and applications run on the guest OS. In contrast, OS-less containers (e.g., container 121) run in VMs 101 1 and applications run in the OS-less containers. As discussed, OS-less containers such as
container 121 implement operating system-level virtualization, where an abstraction layer is provided on top of the kernel of an operating system (not shown). The abstraction layer supports multiple OS-less containers each including an application, and each OS-less container runs as an isolated process in userspace on the host operating system and shares the kernel with other containers. Illustratively, avirtual Ethernet bridge 180 connected toVNIC 141 and the OS-less containers is responsible for forwarding packets between the network interfaces attached to bridge 180. When an OS-less container (e.g., container 121) is created, the abstraction layer that supports the OS-less containers also creates a pair of virtual Ethernet (vEth) interfaces, one of which is assigned to the new OS-less container's network namespace and the other of which is connected to bridge 180. The pair of vEths are tunnel drivers that act as a bidirectional pipe, with traffic entering one vEth in the pair exiting the other vEth. - As also shown, an application network monitoring agent (e.g., agent 120 1) runs in each of VMs 101 1-N. In one embodiment, these agents are configured to monitor network traffic at host computer systems (which would be VMs 101 1-N in this case), identify network dependencies based on the monitored network traffic at the host computer systems, further monitor network traffic at virtual bridges to which OS-less containers are attached, identify network dependencies based on the monitored network traffic at the virtual bridges, and transmit the identified network dependencies to application
dependency generator server 130, according tomethod 200 discussed above with respect toFIG. 2 . In turn, applicationdependency generator service 134 determines application dependencies based on the identified network dependencies by, e.g., constructing a hash map with the network dependency information and identifying pairs of applications which have a dependency relationship, as discussed above. - Advantageously, techniques disclosed herein permit application dependencies to be identified in a hybrid environment in which applications run in virtual machines (VMs) and physical servers, as well as in operating system (OS)-less containers. By knowing such application dependencies, cloud administrators can better plan for datacenter work load migrations. At the same time, application downtime due to partial datacenter migrations in which applications that are depended upon are not migrated can be avoided. Further, the maintenance period for a datacenter can be determined in advance and the user alerted to the application downtime. In addition, disaster recovery of applications can be planned earlier while accounting for application dependencies.
- The various embodiments described herein may employ various computer-implemented operations involving data stored in computer systems. For example, these operations may require physical manipulation of physical quantities usually, though not necessarily, these quantities may take the form of electrical or magnetic signals where they, or representations of them, are capable of being stored, transferred, combined, compared, or otherwise manipulated. Further, such manipulations are often referred to in terms, such as producing, identifying, determining, or comparing. Any operations described herein that form part of one or more embodiments of the invention may be useful machine operations. In addition, one or more embodiments of the invention also relate to a device or an apparatus for performing these operations. The apparatus may be specially constructed for specific required purposes, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.
- The various embodiments described herein may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like.
- One or more embodiments of the present invention may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media. The term computer readable medium refers to any data storage device that can store data which can thereafter be input to a computer system computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer. Examples of a computer readable medium include a hard drive, network attached storage (NAS), read-only memory, random-access memory (e.g., a flash memory device), a CD (Compact Discs), CD-ROM, a CD-R, or a CD-RW, a DVD (Digital Versatile Disc), a magnetic tape, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer system so that the computer readable code is stored and executed in a distributed fashion.
- Although one or more embodiments of the present invention have been described in some detail for clarity of understanding, it will be apparent that certain changes and modifications may be made within the scope of the claims. Accordingly, the described embodiments are to be considered as illustrative and not restrictive, and the scope of the claims is not to be limited to details given herein, but may be modified within the scope and equivalents of the claims. In the claims, elements and/or steps do not imply any particular order of operation, unless explicitly stated in the claims.
- In addition, while described virtualization methods have generally assumed that virtual machines present interfaces consistent with a particular hardware system, persons of ordinary skill in the art will recognize that the methods described may be used in conjunction with virtualizations that do not correspond directly to any particular hardware system. Virtualization systems in accordance with the various embodiments, implemented as hosted embodiments, non-hosted embodiments, or as embodiments that tend to blur distinctions between the two, are all envisioned. Furthermore, various virtualization operations may be wholly or partially implemented in hardware. For example, a hardware implementation may employ a look-up table for modification of storage access requests to secure non-disk data.
- Many variations, modifications, additions, and improvements are possible, regardless the degree of virtualization. The virtualization software can therefore include components of a host, console, or guest operating system that performs virtualization functions. Plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the invention(s). In general, structures and functionality presented as separate components in exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the appended claims(s).
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/821,509 US20220407818A1 (en) | 2015-06-29 | 2022-08-23 | Container-aware application dependency identification |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
IN3291CH2015 | 2015-06-29 | ||
IN3291/CHE/2015 | 2015-06-29 | ||
US14/841,737 US11438278B2 (en) | 2015-06-29 | 2015-09-01 | Container-aware application dependency identification |
US17/821,509 US20220407818A1 (en) | 2015-06-29 | 2022-08-23 | Container-aware application dependency identification |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/841,737 Continuation US11438278B2 (en) | 2015-06-29 | 2015-09-01 | Container-aware application dependency identification |
Publications (1)
Publication Number | Publication Date |
---|---|
US20220407818A1 true US20220407818A1 (en) | 2022-12-22 |
Family
ID=57603153
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/841,737 Active 2038-03-06 US11438278B2 (en) | 2015-06-29 | 2015-09-01 | Container-aware application dependency identification |
US17/821,509 Pending US20220407818A1 (en) | 2015-06-29 | 2022-08-23 | Container-aware application dependency identification |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/841,737 Active 2038-03-06 US11438278B2 (en) | 2015-06-29 | 2015-09-01 | Container-aware application dependency identification |
Country Status (1)
Country | Link |
---|---|
US (2) | US11438278B2 (en) |
Families Citing this family (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10257123B2 (en) * | 2015-05-05 | 2019-04-09 | Dell Products Lp | Software-defined-networking (SDN) enabling operating-system containers for real-time application traffic flow improvement |
US10353726B2 (en) | 2015-09-29 | 2019-07-16 | NeuVector, Inc. | Transparent network security for application containers |
US20170180308A1 (en) * | 2015-12-18 | 2017-06-22 | Bluedata Software, Inc. | Allocation of port addresses in a large-scale processing environment |
CN107566150B (en) * | 2016-07-01 | 2020-04-28 | 华为技术有限公司 | Method for processing cloud resources and physical node |
US11314546B2 (en) * | 2016-11-18 | 2022-04-26 | Data Accelerator Ltd | Method and system for executing a containerized stateful application on a stateless computing platform using machine learning |
CN107797845B (en) * | 2016-09-07 | 2021-06-15 | 华为技术有限公司 | Method and apparatus for accessing containers |
US10489275B2 (en) | 2016-10-20 | 2019-11-26 | Cisco Technology, Inc. | Agentless distributed monitoring of microservices through a virtual switch |
US10419394B2 (en) * | 2016-10-24 | 2019-09-17 | Nubeva, Inc. | Providing scalable cloud-based security services |
US10455004B2 (en) * | 2016-11-01 | 2019-10-22 | Microsoft Technology Licensing, Llc | Controlling an application dependency identifier |
US10645020B1 (en) * | 2017-01-30 | 2020-05-05 | Amazon Technologies, Inc. | Virtual networking for compute instances |
US10318314B2 (en) * | 2017-02-24 | 2019-06-11 | International Business Machines Corporation | Techniques for managing software container dependencies |
US10268837B2 (en) | 2017-04-14 | 2019-04-23 | Ca, Inc. | Validation of containers |
US10268565B2 (en) | 2017-04-14 | 2019-04-23 | Ca, Inc. | Validation of containers |
US10445120B2 (en) | 2017-05-03 | 2019-10-15 | Nicira, Inc. | Tiered application discovery |
US11558364B2 (en) * | 2017-07-18 | 2023-01-17 | Nicira, Inc. | Authentication offload in virtualized computing environments |
US10528403B2 (en) * | 2017-10-30 | 2020-01-07 | MuleSoft, Inc. | Adaptive event aggregation |
US10673716B1 (en) * | 2017-10-31 | 2020-06-02 | Amazon Technologies, Inc. | Graph-based generation of dependency-adherent execution plans for data center migrations |
CN108228318B (en) * | 2017-12-29 | 2021-08-06 | 优刻得科技股份有限公司 | Method, host, system and storage medium for communication between cloud container and management device |
US10977066B2 (en) | 2018-04-06 | 2021-04-13 | Red Hat, Inc. | Virtual machine to container conversion and optimization |
US10915349B2 (en) | 2018-04-23 | 2021-02-09 | Hewlett Packard Enterprise Development Lp | Containerized application deployment |
US10778646B2 (en) * | 2018-05-07 | 2020-09-15 | Cisco Technology, Inc. | Globally deployable context aware VPN headends in scale through namespaces |
US20190347127A1 (en) * | 2018-05-09 | 2019-11-14 | Red Hat, Inc. | Service provisioning and orchestration for virtual machine to container migration |
US10944654B2 (en) | 2018-06-06 | 2021-03-09 | Servicenow, Inc. | Discovery and mapping of containerized software applications |
US11416274B2 (en) | 2018-12-07 | 2022-08-16 | International Business Machines Corporation | Bridging a connection to a service by way of a container to virtually provide the service |
US11483384B2 (en) | 2019-03-19 | 2022-10-25 | Hewlett Packard Enterprise Development Lp | Application migrations |
CN112068924A (en) * | 2019-06-11 | 2020-12-11 | 中国电信股份有限公司 | Network virtualization system and method |
CN112532668B (en) * | 2019-09-19 | 2022-08-02 | 贵州白山云科技股份有限公司 | Network edge computing method, device and medium |
WO2021105905A1 (en) * | 2019-11-27 | 2021-06-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Microservice profiling in containerized environments for data driven approaches |
EP4009160A1 (en) * | 2020-12-07 | 2022-06-08 | F5, Inc. | Methods for application deployment across multiple computing domains and devices thereof |
CN113746692A (en) * | 2021-07-21 | 2021-12-03 | 网宿科技股份有限公司 | Network flow statistical method, electronic equipment and storage medium |
CN113905105B (en) * | 2021-09-30 | 2024-03-15 | 阿里巴巴(中国)有限公司 | Method and device for establishing application dependency relationship |
US11556351B1 (en) | 2021-10-13 | 2023-01-17 | International Business Machines Corporation | Facilitation of application containerization |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010522370A (en) * | 2007-03-20 | 2010-07-01 | サンギュ イ | Mobile virtual machine image |
US8650562B2 (en) * | 2009-06-12 | 2014-02-11 | International Business Machines Corporation | Method and apparatus for scalable monitoring of virtual machine environments combining base virtual machine and single monitoring agent for measuring common characteristics and individual virtual machines measuring individualized characteristics |
US8752047B2 (en) * | 2010-05-28 | 2014-06-10 | Bromium, Inc. | Automated management of virtual machines to process untrusted data based on client policy information |
US8312138B2 (en) * | 2010-09-22 | 2012-11-13 | Blue Stripe Software, Inc. | Methods and computer program products for identifying and monitoring related business application processes |
US9354852B2 (en) * | 2010-12-23 | 2016-05-31 | Microsoft Technology Licensing, Llc | Satisfying application dependencies |
US9575781B1 (en) * | 2011-05-23 | 2017-02-21 | Open Invention Network Llc | Automatic determination of a virtual machine's dependencies on storage virtualization |
US8881145B2 (en) * | 2011-12-15 | 2014-11-04 | Industrial Technology Research Institute | System and method for generating application-level dependencies in one or more virtual machines |
WO2015138498A1 (en) * | 2014-03-11 | 2015-09-17 | Citrix Systems, Inc. | Computer-implemented methods and systems for determining application matching status |
US9781004B2 (en) * | 2014-10-16 | 2017-10-03 | Cisco Technology, Inc. | Discovering and grouping application endpoints in a network environment |
US10411966B2 (en) * | 2015-02-26 | 2019-09-10 | Red Hat, Inc. | Host network analyzer |
US10536357B2 (en) * | 2015-06-05 | 2020-01-14 | Cisco Technology, Inc. | Late data detection in data center |
-
2015
- 2015-09-01 US US14/841,737 patent/US11438278B2/en active Active
-
2022
- 2022-08-23 US US17/821,509 patent/US20220407818A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
US11438278B2 (en) | 2022-09-06 |
US20160380916A1 (en) | 2016-12-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20220407818A1 (en) | Container-aware application dependency identification | |
US10608908B2 (en) | On-demand connection ping | |
US11296960B2 (en) | Monitoring distributed applications | |
US10135726B2 (en) | Virtualization port layer including physical switch port and logical switch port | |
US9712538B1 (en) | Secure packet management for bare metal access | |
US10514937B2 (en) | Auto-discovery service and method of discovering applications within a virtual network | |
US11182185B2 (en) | Network-based signaling to control virtual machine placement | |
US8640220B1 (en) | Co-operative secure packet management | |
WO2017107018A1 (en) | Method, device, and system for discovering the relationship of applied topology | |
US10868883B2 (en) | Upgrading a proxy that decouples network connections from an application during application's downtime | |
US20150150007A1 (en) | Session monitoring of virtual desktops in a virtual machine farm | |
US9135050B2 (en) | Extensible network configuration management | |
US20140032753A1 (en) | Computer system and node search method | |
US10846120B2 (en) | Configuration tracking in virtualized computing environments | |
US20180152417A1 (en) | Security policy analysis based on detecting new network port connections | |
CN116348841A (en) | NIC supported distributed storage services | |
US10437621B2 (en) | Monitoring and managing applications on virtual machines using a proxy agent | |
US10050874B2 (en) | Media access control address learning for packets | |
US10691310B2 (en) | Copying/pasting items in a virtual desktop infrastructure (VDI) environment | |
US11531564B2 (en) | Executing multi-stage distributed computing operations with independent rollback workflow | |
CN112422357A (en) | Method and device for detecting state of network communication path | |
US20200034191A1 (en) | Reprogramming network infrastructure in response to vm mobility | |
US11190577B2 (en) | Single data transmission using a data management server | |
US20180006958A1 (en) | Decoupling network connections from an application while the application is temporarily down | |
US11588721B2 (en) | Measuring performance of virtual desktop event redirection |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: VMWARE, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GNANESWARAN, DINESH BABU THIRUKONDAN;MANNAM, SUBRAHMANYAM;GUPTA, GAURAV;AND OTHERS;REEL/FRAME:061301/0353 Effective date: 20150831 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
AS | Assignment |
Owner name: VMWARE LLC, CALIFORNIA Free format text: CHANGE OF NAME;ASSIGNOR:VMWARE, INC.;REEL/FRAME:067102/0242 Effective date: 20231121 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |