Patent Application
20170180231
The invention relates in general to the field of computer-implemented methods for monitoring queues at switches of a network.
Today's clouds are based on large aggregations of hardware (servers, storage, networks) and software (software-defined networking [SDN], hypervisors, operating systems [OSs], applications). Distributed scale out systems, i.e., in datacenters (DCs), are typically virtualized in order to serve multiple tenants and their users. The orchestration, management, load balancing, protection and isolation of such virtualized systems depend on timely access to the DCs internal states (load, occupancy, utilization, etc.), including all the layers of the physical and virtual components.
However, it can be realized that current systems make it difficult, if not impossible to simultaneously observe (and a fortiori control) the state of two or more queues of data queuing at switches of a network, at packet resolution. Hence the direct observation of multitude of queues is not (or hardly) possible inside a datacenter's network, be it a physical fabric or a virtualized SDN overlay, particularly at the temporal granularity of a few packets (nanosecond to microsecond scale). Therefore, schemes for building a space-time correlated global sampling system for a multitude of queues, as suggested in A. S. Anghel, R. Birke, and M. Gusat (“Scalable High Resolution Traffic Heatmaps: Coherent Queue Visualization for Datacenters”), TMA 2014: [26-37], remain of limited theoretical relevance.
According to a first aspect, the present invention is embodied as a computer-implemented method for monitoring a computerized network. Said network comprises several switches that are, each, configured for processing data queuing thereat. The method comprises monitoring queues of data at switches of the network, from an entity external to and in communication with the network. Monitoring is carried out by first sending, via a data path of the network, an execution data packet to each of the switches. The execution data packet comprises contents interpretable by each switch so as for the latter to start and/or stop an execution of a sampling mechanism for sampling a queue of data and returning sampled data to the external entity. Eventually, data sampled according to this sampling mechanism are received at the external entity (from each of the switches, and via said data path).
Preferably, the execution data packet sent comprises contents interpretable so as for said each of the switches to start the execution of the sampling mechanism for sampling said queue during a defined time period. The time period may possibly be defined according to contents of the execution data packet sent, and may further he adjusted over time according to previously sampled data, as collected from the switches.
A prior configuration of the switches may be advantageous. I.e., in embodiments, a configuration data packet is sent (prior to sending the execution data packet) to each of the switches, via a control path of the network. This configuration data packet is interpretable so as for each of the switches to set configuration parameters for the subsequent sampling mechanism. Such parameters may include conditions, which, if met, will trigger the subsequent sampling mechanism.
According to another aspect, the invention is embodied as a computer-implemented method for enabling an entity external to and in communication with a computerized network to monitor queues of data at switches of a network such as evoked above. This method basically comprises, at each of the switches of the network: receiving, via a data path of the network, an execution data packet; starting and/or stopping an execution of a sampling mechanism for sampling a queue of data at said each of the switches, according to contents of the execution data packet received; and returning, via said data path, data sampled according to said sampling mechanism to the external entity. The data sampled are preferably timestamped.
As evoked above, the switches may, during a configuration phase, set configuration parameters for the subsequent sampling mechanism and this, based on contents of configuration data packets sent to that aim by the external entity.
Preferably, the starting and/or stopping the execution of the sampling mechanism is performed at each of the switches according to a finite-state machine.
According to a final aspect, the invention can be embodied as a computer program product, comprising program instructions executable so as to cause an external entity to monitor queues of data, by performing steps such as described above.
Computerized devices, systems, methods and computer program products embodying or implementing steps according to the present invention will now be described, by way of non-limiting examples, and in reference to the accompanying drawings.
The accompanying drawings show simplified representations of systems (or parts thereof) and computerized methods, as involved in embodiments. Similar or functionally similar elements in the figures have been allocated the same numeral references, unless otherwise indicated.
In reference to
More in detail, present methods, as implemented at an entity 101 external to and in communication with the network 100, aim at monitoring queues 20 (and or 20a) of data 22, 23 and/or 19, see
First, an execution data packet 21 is sent (step S40, see
Second, the external entity will accordingly receive S82, from each of the switches, and via said data path 40, data sampled according to said sampling mechanism.
Execution data packets are sent to the target switches, via a data path, which allows for both scalability and speed, as opposed to using a control path of the network. This way, the sampling mechanism can be globally started and/or stopped from the external entity 101. The external entity may for instance be hardware, i.e., a physical machine (e.g., a server, running the monitoring process), or software (e.g., a user application, implementing this monitoring process), or more generally, a set of machines (physical and/or virtual), interacting so as to implement the monitoring process. The external entity may for instance comprise one or more of: an operator, a user application, a monitoring entity, etc. The monitoring entity may also use the sampled data returned to perform specific operations or analyses thereon, as discussed later.
An execution data packet as defined above may be regarded as a global start signal (in which case sampling is started upon receiving the packet), and/or a global stop (in which case sampling is started beforehand but stopped upon receiving the packet). In all cases, using data packets sent along the data path of the network enable a global, scalable and fast sampling mechanism. The present monitoring scheme may accordingly find useful applications in the orchestration, management, load balancing, protection and isolation of clouds, distributed scale out systems and virtualized systems.
As noted above, the execution data packets may he used for triggering a global start and/or a global stop. Preferably yet, the execution data packets are designed to cause the switches to start sampling and include instructions for a programmable stop (the “stop” is automatic, as per instructions included in the execution packets). For example, the sampling S60 is limited to a given time period (as assumed in
In (less preferred) variants, the execution data packets received may trigger a global stop signal. l.e., sampling would, in that case, be started prior to receiving an execution packet, e.g., based on previously received information. The sampling will accordingly cease upon receiving the data packet (or based on instructions included in this packet), such that a global mechanism can here again be implemented. However, a global stop mechanism will typically add complexity in terms of time synchronization.
In other (less preferred) variants, two data packets are sent, to respectively define the start and stop for the sampling mechanism. The sampling may start upon interpreting a first execution data packet received and finish upon interpreting a second execution data packet received. Such variants are nevertheless more complex to implement and consume more bandwidth.
As explained later in detail, an execution data packet may further include additional parameters, to cause the switches, upon reception and interpretation of the execution data packet, to set and/or update sampling configuration parameters. For instance, an execution data packet may include time data (beyond a mere time period for sampling) utilizable for synchronizing the sampling at the various switches, to enable a space-time correlated global sampling mechanism for a multitude of queues. This further makes it possible to subsequently synchronize the monitored data, at the external entity.
Moreover, different types of data packets may be used, which have distinct aims. The execution data packets aim at starting and/or stopping sampling of data queues at the switches and, if necessary, modifying a previously set sampling configuration (i.e., sampling parameters). In that respect, configuration data packets may be sent beforehand to the switches (steps S10, S15, prior to sending the execution data packets), e.g., using the control path instead of the data path, to pre-configure the switches. This way, default parameters for the sampling configuration (which may include sampling parameters and sampling conditions [as to what and when to sample]) may be set S22, S24 at the switches, prior to the execution phase S35-S60,
The steps S40 and S82 (at the external entity), and consistently the steps S45 and S80 (at the switches) are preferably repeatedly performed, to ensure a continuous or intermittent monitoring, while allowing changes intervening in the network to be taken into account. Indeed, the execution data packets sent during a subsequent execution phase may include new sampling configuration parameters, which take into account changes that have occurred since the last execution phase.
In variants, instructions for repeated sampling operations may already be included in a single execution packet (e.g., a one-time multicast packet) or in concomitantly sent unicast packets. Namely, a single execution packet may include instructions for the switch to perform repeated sampling operations, e.g., at given times or at regular time intervals, or, still, each time given conditions (e.g., as specified in the same packet or during a previous configuration phase S24) are met, where a conditional sampling mechanism is contemplated.
In all cases, a multicast or a unicast mechanism may be involved. For example, in a multicast scenario, the external entity may use a single IP address that identifies a group of switches. In a unicast scenario, distinct packets are sent to individual IP addresses of the switches.
The switches preferably implement a quantized congestion notification (QCN) protocol, or a related protocol, whereby components of the sampling mechanism obey such a protocol to perform the sampling. A switch that implements a QCN protocol or a similar protocol monitors its queues' sizes and rates of change of sizes. After starting the sampling process, a switch may “decide” (e.g., in a probabilistic manner and if deemed necessary, by way of some algorithm) to create a feedback notification packet containing data relevant to the queue and send the created packet to a suitable destination. The created feedback notification packets may be used as sampled data for implementing the present schemes. In embodiments, a feedback packet can be sent to the actual sources of the data packets in the monitored queue, which sources act as a distributed external entity. In other embodiments, the feedback data packet can be sent to a single, predefined physical external entity.
More generally though, the data sampled may, in particular, relate to queues of data to be processed (i.e., data queuing at the switches in view of being processed by them, like data packets 22, 23 in
Note that not all the switches of an actual network may be targeted by the present monitoring methods. Instead, present methods may be implemented for a restricted set of switches (which would nonetheless form a network as defined above). In particular, the present principles are preferably applied to monitor queues at switches that are networking nodes (sometimes referred to as nodes, switches or routers, that is, entities that contribute to forward data traffic from a source to a destination), rather than end nodes that generate the data traffic (especially if input queues of switches are systematically and consistently sampled, as illustrated in
The collection of the samples may be performed in a distributed manner (e.g., the switches return the samples according to an IP address of the external entity [e.g., as included in the received execution packets or according to instruction specified in such a packet]) or in a centralized way (the switches systematically return samples to a same recipient).
Referring now more specifically to
In the above scenario, sampling is typically started upon receiving the execution packets or based on instructions therein (e.g., if given conditions are met). By default, the time period may be set according to default parameters already provided to the switches, e.g., during the configuration phase S10-S26. Still, this time period may be overruled S52 by parameters included in the contents of the execution data packets 21 sent by the external entity 101.
If necessary, this time period can be dynamically adapted, e.g., according to a most recent state of the network traffic, as monitored from the external entity 101. Indeed, and prior to sending S40 an execution data packet, the external entity may determine (or update) S110 the time period according to data received S82 from one or more switches of the network, during a previous execution phase.
At present, the configuration phase is discussed in more detail, in reference to
The sampling phase may start upon completion of the configuration phase, e.g., upon receiving the execution data packet triggering the global start for the sampling. However, switches are preferably configured as finite-state machines, whereby the completion of step S20 (where the configuration parameters are set) causes to shift S26 each switch in a state where it awaits S35 reception S45 of an execution data packet 21. As further illustrated in
As discussed earlier, previous configuration parameters may be overruled at each new sampling phase S35-S60, as illustrated in
Practical monitoring applications are now discussed in reference to
In particular, and as illustrated in
In the representation of
The mapping proposed in
Analysis S90 may precede a change in the configuration parameters for subsequent sampling phases. For instance, referring back to
Referring again to
Essentially, such methods echo steps S40 and S82 as described earlier. Namely, each of the switches (or a subset thereof) receives S45, via the data path 40 of the network, an execution data packet 21 and subsequently start S60 and/or stop S65 executing a sampling mechanism, according to contents of the execution data packet 21 received. Eventually, sampled data are returned S80 (still via the data path) to the external entity 101.
The sampling mechanism may rely on a quantized congestion notification protocol, or a related protocol, as noted earlier. For synchronization purposes, the switches preferably proceed to timestamp the data sampled. In fact, timestamping and routing/sending back data is typically performed continuously, for all data, including those data that get sampled as sampling starts. Also, and as described earlier, data are preferably sampled during a defined time period, which may be read or computed from contents of the execution data packet, or even set by default during the previous configuration phase.
In that respect, the switches may, in embodiments, be configured to set S20, during the configuration phase, configuration parameters for the subsequent sampling S60 (again according to contents of configuration data packets 21 received S45).
For completeness, and according to a final aspect, the invention may be embodied as a computer program product. This computer program product typically comprises a computer readable storage medium having program instructions embodied therewith, the program instructions being executable by one or more processors of an external (computerized) entity 101 to monitor queues of data at switches of the network, by performing steps S40 and S82 as discussed earlier in reference to
Computerized devices can be suitably designed for implementing embodiments of the present invention as described herein. In that respect, it can be appreciated that the methods described herein are largely non-interactive and automated. In exemplary embodiments, the methods described herein can be implemented either in an interactive, partly-interactive or non-interactive system. The methods described herein can be implemented in software (e.g., firmware), hardware, or a combination thereof. In exemplary embodiments, the methods described herein are implemented in software, as an executable program, the latter executed by suitable digital processing devices. More generally, embodiments of the present invention can be implemented wherein general-purpose digital computers, such as personal computers, workstations, etc., are used.
For instance, the computerized unit 101 depicted in
The processor 105 is a hardware device for executing software, particularly that stored in memory 110. The processor 105 can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the computer 101, a semiconductor based microprocessor (in the form of a microchip or chip set), or generally any device for executing software instructions.
The memory 110 can include any one or combination of volatile memory elements (e.g., random access memory) and nonvolatile memory elements. Moreover, the memory 110 may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory 110 can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processor 105.
The software in memory 110 may include one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. In the example of
The methods described herein may be in the form of a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When in a source program form, then the program needs to be translated via a compiler, assembler, interpreter, or the like, as known per se, which may or may not be included within the memory 110, so as to operate properly in connection with the OS. Furthermore, the methods can be written as an object oriented programming language, which has classes of data and methods, or a procedure programming language, which has routines, subroutines, and/or functions.
Possibly, a conventional keyboard 150 and mouse 155 can be coupled to the input/output controller 135. Other I/O devices 145-155 may include other hardware devices.
In addition, the I/O devices 145-155 may further include devices that communicate both inputs and outputs. The unit 101 can further include a display controller 125 coupled to a display 130. In exemplary embodiments, the unit 101 can further include a network interface or transceiver 160 for coupling directly to the network 100 or (as assumed in
The network 165 transmits and receives data between the unit 101 and the network 100. Each of the networks 100 and 165 may possibly implemented in a wireless fashion, e.g., using wireless protocols and technologies, such as WiFi, WiMax, etc. The network 100 or 165 may be a fixed wireless network, a wireless local area network (LAN), a wireless wide area network (WAN) a personal area network (PAN), a virtual private network (VPN), intranet or other suitable network system and includes equipment for receiving and transmitting signals. The network 100 or 165 can also be an IP-based network for communication between the unit 101 and any external server, client and the like via a broadband connection. In exemplary embodiments, the network 100 or 165 can be a managed IP network administered by a service provider. Besides, the network 100 is packet-switched network such as a LAN, WAN, Internet network, etc. The network 165 is preferably a packet-switched network too.
If the unit 101 is a PC, workstation, intelligent device or the like, the software in the memory 110 may further include a basic input output system (BIOS). The BIOS is stored in ROM so that the BIOS can be executed when the computer 101 is activated.
When the unit 101 is in operation, the processor 105 is configured to execute software stored within the memory 110, to communicate data to and from the memory 110, and to generally control operations of the computer 101 pursuant to the software. The methods described herein (in respect of the entity 101) and the OS, in whole or in part are read by the processor 105, typically buffered within the processor 105, and then executed. When the entity methods described herein (in respect of the entity 101) are implemented in software, the methods can be stored on any computer readable medium, such as storage 120, for use by or in connection with any computer related system or method.
In addition, the present invention may be embodied as a computer program product, as evoked above. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present invention may he assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the C programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In sonic alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
While the present invention has been described with reference to a limited number of embodiments, variants and the accompanying drawings, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the present invention. In particular, a feature (device-like or method-like) recited in a given embodiment, variant or shown in a drawing may be combined with or replace another feature in another embodiment, variant or drawing, without departing from the scope of the present invention. Various combinations of the features described in respect of any of the above embodiments or variants may accordingly be contemplated, that remain within the scope of the appended claims. In addition, many minor modifications may be made to adapt a particular situation or material to the teachings of the present invention without departing from its scope. Therefore, it is intended that the present invention not be limited to the particular embodiments disclosed, but that the present invention will include all embodiments falling within the scope of the appended claims. In addition, many other variants than explicitly touched above can be contemplated.
