WO2024102158A1 - Data flow management system - Google Patents

Data flow management system Download PDF

Info

Publication number
WO2024102158A1
WO2024102158A1 PCT/US2022/079555 US2022079555W WO2024102158A1 WO 2024102158 A1 WO2024102158 A1 WO 2024102158A1 US 2022079555 W US2022079555 W US 2022079555W WO 2024102158 A1 WO2024102158 A1 WO 2024102158A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
message
worker
worker nodes
handler
Prior art date
Application number
PCT/US2022/079555
Other languages
French (fr)
Inventor
Tim Chan
Hitoshi Yabusaki
Original Assignee
Hitachi Vantara Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Vantara Llc filed Critical Hitachi Vantara Llc
Priority to PCT/US2022/079555 priority Critical patent/WO2024102158A1/en
Publication of WO2024102158A1 publication Critical patent/WO2024102158A1/en

Links

Definitions

  • the present disclosure is generally directed to data flow management systems, and more specifically, to systems and methods for facilitating scalable data flow management systems.
  • a sense of location is provided for distributed virtual switch components into the service provisioning scheme to reduce latency observed in conducting policy evaluations across a network in a hybrid cloud environment.
  • a management application in a first virtual network subscribes to virtual network services provided by a second virtual network.
  • a first message is sent to the second virtual network, the first message having information configured to start a virtual switch in the second virtual network that switches network traffic for one or more virtual machines in the second virtual network that are configured to extend services provided by the first virtual network into the second virtual network.
  • a second message is sent to the second virtual network, the second message involving information configured to start a virtual service node in the second virtual network that provides network traffic services for the one or more virtual machines.
  • a method is used for application layer message-based load balancing.
  • the network element determines a message classification to which the application layer message belongs. Using a loadbalancing algorithm that is mapped to the message classification, the network element selects a server from among a plurality of servers, and sends the message toward that server.
  • the network element selects the server based on multiple servers’ average historical response times and average outstanding request wait times. The network element continuously maintains these statistics for each server toward which the network element has sent requests. The network element tracks response times by recording how much time passes between the sending of a request to a server and the receiving of a corresponding response from that server.
  • messaging policies can be dynamically updated based on operations, administration, maintenance, and provisioning (OAMP) data generated by data plane entities of a messaging network.
  • OAMP operations, administration, maintenance, and provisioning
  • existing messaging policies may be dynamically modified based on OAMP data generated by message brokers and/or network elements (e.g., queues).
  • new messaging policies may be dynamically created based on the OAMP data.
  • an updated set of messaging policies may be selected from a pool of policies based on the OAMP data.
  • Dynamically updating messaging policies can be achieved using information model processing frameworks, such as the next generation directory enabled networks (DEN-ng) model.
  • DEN-ng next generation directory enabled networks
  • Various events may trigger the creation of new messaging policies and metrics, such as adding new data plane entities and/or network elements to the network, receiving new messaging instructions, and so on.
  • a fourth related art example there is a system and method for concentration and load-balancing of requests in a distributed computing environment.
  • Such related art examples can involve a system and a method for reducing the number of connections in an Internet environment using one or a plurality of connection handlers which handle the connection from the client to the server, and a listener which determines which connection handler to use to handle the connection.
  • prior solutions required a (n - m) number of connections to handle requests
  • the invention allows there to be only m connections which significantly reduces resource requirements and allows scalability.
  • Container cluster network can localize the traffic (e.g. service mesh), however, introducing such virtual switches introduces central processing unit (CPU)/memory load which causes reduction in the end-to-end throughput.
  • CPU central processing unit
  • Related art implementations further allow a load balancer to distribute message based on application information. Such a method may reduce inter worker node traffic. However, it requires the load balancer to parse the payload of each of the TCP/IP packets, which causes CPU/memory load on the load balancer and reduces end-to-end throughput.
  • the example implementations described herein are directed to the scale out of the data flow management system without introducing extra network traffic in container cluster virtual network, without complicating data flow management, without introducing non-standard requirements to sensors for connecting message broker, and without increasing service down time when the message broker fails.
  • Example implementations described herein involve a scalable data flow management system.
  • there is a set of data route stacks (message broker, message handlers) which are deployed in each worker node in a container cluster virtual network.
  • a data route manager configures the same routes to all of the data route stack.
  • Sensors can send sensor data to any message broker.
  • Message handlers subscribe to data from the message broker on the same worker node, thus avoiding inter-worker-node traffic.
  • the data route manager manages a single data route per single source (binding key/queue or topic to which the sensor sends data) regardless of the number of worker nodes by decoupling endpoint information (message broker hostname, port, credentials) from common routing information (queue/topic name, binding key name, and so on).
  • endpoint information messages broker hostname, port, credentials
  • common routing information queue/topic name, binding key name, and so on.
  • the load balancer or reverse proxy keep connections to the message broker once the sensor connects to one of message brokers to minimize the client connection in message brokers. The load balancer or reverse proxy switches the forwarding message broker when connected message broker gets unhealthy.
  • aspects of the present disclosure can involve a system with a plurality of worker nodes, wherein each of the worker node has a first message broker and at least one first message handler, a second message broker and at least one second handler
  • a data route management module manages data routes by associating the first message broker and first message handler in the same worker node, and the second message broker and second message hander in another worker node.
  • the load balancer forwards the data to any one of the message brokers for storing, stored data is sent with the configured data route in each of the worker nodes.
  • aspects of the present disclosure can involve a system, involving a plurality of worker nodes, each of the plurality of worker nodes involving a first message broker and at least one first message handler; a data route management module configured to manage data routes by associating the first message broker and the at least one first message handler of a first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of a second worker node from the plurality of worker nodes; and a load balancer configured to forward received data for storage with a configured data route from the managed data routes to route through ones of the plurality of the worker nodes through the at least one first handler of the ones of the plurality of the worker nodes.
  • aspects of the present disclosure can involve a method for a system involving a plurality of worker nodes, each of the plurality of worker nodes involving a first message broker and at least one first message handler; the method involving managing data routes by associating the first message broker and the at least one first message handler of a first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of a second worker node from the plurality of worker nodes; and forwarding received data for storage with a configured data route from the managed data routes to route through ones of the plurality of the worker nodes through the at least one first handler of the ones of the plurality of the worker nodes.
  • aspects of the present disclosure can involve a system involving a plurality of worker nodes, each of the plurality of worker nodes involving a first message broker and at least one first message handler; the system involving means for managing data routes by associating the first message broker and the at least one first message handler of a first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of a second worker node from the plurality of worker nodes; and means for forwarding received data for storage with a configured data route from the managed data routes to route through ones of the plurality of the worker nodes through the at least one first handler of the ones of the plurality of the worker nodes.
  • aspects of the present disclosure can involve computer instructions for a system involving a plurality of worker nodes, each of the plurality of worker nodes involving a first message broker and at least one first message handler; the computer instructions involving managing data routes by associating the first message broker and the at least one first message handler of a first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of a second worker node from the plurality of worker nodes; and forwarding received data for storage with a configured data route from the managed data routes to route through ones of the plurality of the worker nodes through the at least one first handler of the ones of the plurality of the worker nodes.
  • the computer instructions can be stored in a non- transitory computer readable medium and executed by one or more processors.
  • FIG. 1 illustrates an example system architecture upon which example implementations can be applied.
  • FIG. 2A illustrates an example data flow from sensors to message broker in logical and physical layers, in accordance with an example implementation.
  • FIG. 2B illustrates an example data flow from message broker to ingress in logical and physical layers, in accordance with an example implementation.
  • FIG. 3 illustrates problems with deploying multiple independent message brokers.
  • FIG. 4 illustrates an example of the scalable data flow management system, in accordance with an example implementation.
  • FIG. 5A illustrates data route information, in accordance with an example implementation.
  • FIG. 5B illustrates endpoint information, in accordance with an example implementation.
  • FIG. 6 illustrates a flow chart of creating route and data flow from sensor to first message handler, in accordance with an example implementation.
  • FIG. 7 illustrates the flow chart of creating route and data flow from sensor to first message handler when failure happens, in accordance with an example implementation.
  • FIG. 8 illustrates an example of the scale out involving a sequence of adding a worker node, in accordance with an example implementation.
  • FIG. 9 illustrates a system involving a plurality of physical systems networked to a management apparatus, in accordance with an example implementation.
  • FIG. 10 illustrates an example computing environment with an example computer device suitable for use in some example implementations.
  • FIG. 1 illustrates an example system architecture upon which example implementations can be applied.
  • External message broker can feed into a data route stack of the container cluster.
  • the data route stack can involve a first message handler to handle the ingress from the external message broker, an internal message broker to facilitate messages internally in the data route stack, and a second message handler to handle egress to the data lake.
  • a data route manager can manage inputs from a user interface (UI).
  • UI user interface
  • Data lake can involve a time series data store, a blob store, a NoSQL and/or SQL database, a distributed file system (DFS) such as a Hadoop DFS, and a message broker.
  • the data stored in the data lake can be provided to analytics services in accordance with the desired implementation.
  • DFS distributed file system
  • Variations of the architecture can also be done to facilitate the desired implementation.
  • the first and second message handler as well as the internal message broker can be replaced by a single message handler if desired.
  • the data lake can be outside of container cluster if desired.
  • FIG. 2A and FIG. 2B illustrates data flow from sensors to message broker and from message broker to ingress in logical and physical layers, respectively.
  • load balancer distributes data to one of reverse proxies (i.e., kube proxy) and the reverse proxy forwards the data to one of the broker nodes. If the broker node does not own the bound queue, then the broker node forwards the data to a node that owns the queue. This allows for dumb sensors that send data to the broker nodes without noticing where the queue exists, which makes the footprint of the messaging client smaller. However, this also introduces a lot more inter-worker node traffic.
  • reverse proxies i.e., kube proxy
  • FIG. 2A illustrates data flow from sensors to message broker in logical and physical layers.
  • the data flow from the sensors go to the load balancer (LB) then through a clustered message broker 211 composed of a plurality of message broker nodes that are configured to distribute the data to the intended deseitnation.
  • LB load balancer
  • the load balancer receives sensor data and distributes the traffic to the reverse proxies (e.g. kube-proxy) at 221.
  • the reverse proxy then distributes the traffic to the message broker at 222.
  • the worker nodes e.g., Kubemetes worker nodes
  • a container e.g. calico node, a container cluster virtual network
  • the load balancer sends the data to a worker node.
  • the reverse proxy distributes the traffic at 232, and the traffic is forwarded across different worker nodes 233 until it reaches the destination node, which writes the message in storage at 234.
  • the clustered message broker 241 distributes a message to a message handler that handles ingress.
  • the message handler distributes the message to the appropriate message broker.
  • the reverse proxy receives the message from the message handler and distributes the traffic to the message broker, which will similarly distribute to the reverse proxy.
  • each worker node subscribes to data to another worker node, and can forward received messages to a broker node with a queue.
  • the receiving broker node can read and return messages received.
  • FIG. 3 illustrates problems with deploying multiple independent message brokers. Assume that multiple independent message brokers with identical endpoints are deployed instead of clustered. In this case, sensors need to recognize in which broker node the queue exists, which requires a non-standard messaging client. The sensors need to switch message brokers that it is sending data to depending on the underlying queue/topic to be transmitted. The ingress also needs to switch message brokers that it is subscribing data from depending on the underlying queue/topic to be transmitted. Further, the data route manager will have to manage many data routes (# of message brokers * # queues/topics * # of ingress).
  • Example implementations described herein involve a scalable data flow management system wherein a set of data route stack (message broker and message handlers (ingress and egress) are deployed in each worker node.
  • Data route manager configures the same routes to all of the data route stack, so that sensors can send sensor data to any of the message brokers.
  • Data route manager manages a single data route per single source, regardless of the number of worker nodes, by decoupling endpoint information (message broker hostname, port, credentials) from common routing information (queue name, binding key name, etc.). Endpoint information is created per worker node for ingress and egress. Ingress and egress connect to the message broker endpoint from the worker node running on it, and connects to the same worker node, while getting the binding key and queue name from the data route manager.
  • LB load balancer
  • reverse proxy keep connections with the TCP sticky session to the message broker once the sensor connects to one of message brokers.
  • ingress and egress obtain data from the specific queue that the LB is forwarding data to, although ingress and egress are always listening to all the queues.
  • the ingress and egress on the same worker node handle them.
  • the number of ingress and egress can be changed for improving the performance of flow performance per node, and the number of sets of data route stack can be changed for improving the performance per cluster.
  • FIG. 4 illustrates an example of the scalable data flow management system, in accordance with an example implementation.
  • each of the sensors 401 can be configured to send data through any of the plurality of worker nodes.
  • the data route management information can manage the destination of the data from each sensor by indicating the queue/topic and binding key.
  • the data route management information can also define the routes for the ingress message handlers messages by defining the source (queue/topic, binding key, message broker endpoint) and destination (queue/topic, binding key, message broker endpoint).
  • the data route management information can also define the routes of the egress message handlers by defining the source (queue/topic, binding key, message broker endpoint) and destination (database and table name, database endpoint). All of the ingress nodes and brokers obtain the same routing information by using the same service name label (e.g., a key name for getting data route information).
  • each of the data routes can be defined by a source of sensor data and a destination of the sensor data.
  • each of the plurality of worker nodes are configured with endpoint information EN-1, EN-2, EN-N which can involve a hostname to identify a source of the plurality of worker nodes and a destination to which the data processed by the plurality of worker nodes is to be forwarded.
  • the data route manager management module 404 can be configured to facilitate a single data route per single data source (sensor).
  • the single data route per single data sources can be defined according to the binding key/queue or topic that the sensor sends data to, and can be maintained regardless of the number of worker nodes by decoupling endpoint information (message broker hostname, port, credentials) from common routing information (queue/topic name, binding key name, and so on).
  • the data route stack 410 can have the message broker and handler set manage both ingress and egress.
  • the second internal message broker can be configured to subscribe to data only from the at least one first message handler (ingress).
  • the data route management module 404 is configured to manage and configure data routes by associating the first message broker and the at least one first message handler of the first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of the second worker node from the plurality of worker nodes via the second message broker and the at least one second handler of the first worker node.
  • messages received from the external message broker are forwarded to the ingress message handlers, that distribute to the ingress/internal message broker to forward to the egress message handler.
  • the egress message handler can then forward the message to another worker node in accordance with the route defined by the data route information.
  • Example of data route information and endpoint information are shown in FIGS. 5 A and 5B, respectively.
  • data route information is classified into two: source and destination.
  • Source route information is for each microservice to get data from, and destination is to write data to.
  • query information is defined with protocol.
  • message handler reads j son data with amqp protocol with Quality of Service (QoS) level 1000 by binding ba413 binding key to ba413 topic within hiota-exchange exchange.
  • QoS Quality of Service
  • the data route does not include resolvable hostname, IP address or TCP/UDP port number.
  • endpoint information is created per worker node.
  • endpoint info for worker node 1 hostname and port of message broker running on the worker node 1 are defined.
  • the endpoint information for worker node 1 is mounted by message handler running on the node 1.
  • message broker exists on each worker node, but there is only 1 influxDB, so there is an endpoint information for each worker node, but there is one endpoint for influxDB across all the worker nodes.
  • message handler write data to the same influxDB while getting data from message broker on the same node.
  • FIG. 6 illustrates a flow chart of creating route and data flow from sensor to first message handler, in accordance with an example implementation.
  • the point of this system is that both route A and B are created for sensor 1 and 2 to message handers in both worker node 1 and 2; although only data of sensor 1 is received and handled in worker node 1, and that of sensor 2 is received and handled in worker node 2. Note that message handers in each node can be scaled out.
  • FIG. 7 illustrates the flow chart of creating route and data flow from sensor to first message handler when failure happens, in accordance with an example implementation.
  • the point of this system is that handlers in other containers receives and handle it without any configuration change when other node fails.
  • the load balancer detects a failure 701 occuring on a first (egress/ external) broker of a worker node via noting that the connection is closed, the load balancer will forward the sensor data of the failed message broker to another egress/extemal message broker of another worker node using the same connection.
  • the second message broker of the another worker node will determine the endpoint destination of the forwarded sensor data, and the second message handler forwards the forwarded sensor data to the endpoint destination as illustrated in FIG. 7.
  • FIG. 8 illustrates an example of the scale out involving a sequence of adding a worker node, in accordance with an example implementation.
  • the container cluster scheduler e.g., Kubernetes scheduler
  • the data route manager creates endpoint information and saves the file on the new worker node for message handlers to mount the file and sends route A and B to the message handlers on the new node.
  • the message handlers connects to the brokers on the same node.
  • the container cluster scheduler 800 can be configured to, in response to a trigger to add a new worker node 801 to the plurality of worker nodes for one or more of the data routes, add the new worker node to the plurality of worker nodes; and deploy a container to configure the new worker node with the first message broker and at least one first message handler.
  • the data route management module can be configured to create endpoint information for the new worker node; configure the new worker node with the endpoint information, wherein the at least first message handler of other ones of the plurality of worker nodes connected to the one or more of the data routes are configured to mount the endpoint information; and configure the one or more of the data routes on the at least one first message handler of the new worker node.
  • a reverse proxy can execute similar functions of the load balancer to maintain connections to the first message broker for when a sensor connects to the first message broker of one of the plurality of nodes.
  • the reverse proxy can also handle the same functions as the load balancer so that it is configured to switch the first message broker and the first message handler of the second worker node to another first message broker and another first message handler of another worker node for when the first message broker of the second worker node fails.
  • FIG. 9 illustrates a system involving a plurality of physical systems networked to a management apparatus, in accordance with an example implementation.
  • One or more physical systems 901 integrated with various sensors are communicatively coupled to a network 900 (e.g., local area network (LAN), wide area network (WAN)) through the corresponding network interface of the sensor system installed in the physical systems 901, which is connected to a management apparatus(es) 902 that facilitates the container.
  • the management apparatus 902 manages database(s) 903, which contains historical data collected from the sensor systems from each of the physical systems 901.
  • the data from the sensor systems of the physical systems 901 can be stored to a central repository or central database such as proprietary databases that intake data from the physical systems 901, or systems such as enterprise resource planning systems, and the management apparatus 902 can access or retrieve the data from the central repository or central database.
  • the sensor systems of the physical systems 901 can include any type of sensors to facilitate the desired implementation, such as but not limited to gyroscopes, accelerometers, global positioning satellite (GPS), thermometers, humidity gauges, or any sensors that can measure one or more of temperature, humidity, gas levels (e.g., CO2 gas), and so on.
  • Examples of physical systems can include, but are not limited to, shipping containers, lathes, air compressors, and so on. Further, the physical systems can also be represented as virtual systems, such as in the form of a digital twin.
  • FIG. 10 illustrates an example computing environment with an example computer device suitable for use in some example implementations, such as a management apparatus 902 as illustrated in FIG. 9, to facilitate all of the functions described in FIGS. 1 to 8 or to facilitate any functionality of the data route management module or a worker node.
  • Computer device 1005 in computing environment 1000 can include one or more processing units, cores, or processors 1010, memory 1015 (e.g., RAM, ROM, and/or the like), internal storage 1020 (e.g., magnetic, optical, solid state storage, and/or organic), and/or I/O interface 1025, any of which can be coupled on a communication mechanism or bus 1030 for communicating information or embedded in the computer device 1005.
  • VO interface 1025 is also configured to receive images from cameras or provide images to projectors or displays, depending on the desired implementation.
  • Computer device 1005 can be communicatively coupled to input/user interface 1035 and output device/interface 1040. Either one or both of input/user interface 1035 and output device/interface 1040 can be a wired or wireless interface and can be detachable.
  • Input/user interface 1035 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch-screen interface, keyboard, a pointing/cursor control, microphone, camera, braille, motion sensor, optical reader, and/or the like).
  • Output device/interface 1040 may include a display, television, monitor, printer, speaker, braille, or the like.
  • input/user interface 1035 and output device/interface 1040 can be embedded with or physically coupled to the computer device 1005.
  • other computer devices may function as or provide the functions of input/user interface 1035 and output device/interface 1040 for a computer device 1005.
  • Examples of computer device 1005 may include, but are not limited to, highly mobile devices (e.g., smartphones, devices in vehicles and other machines, devices carried by humans and animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded therein and/or coupled thereto, radios, and the like).
  • highly mobile devices e.g., smartphones, devices in vehicles and other machines, devices carried by humans and animals, and the like
  • mobile devices e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like
  • devices not designed for mobility e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded therein and/or coupled thereto, radios, and the like.
  • Computer device 1005 can be communicatively coupled (e.g., via I/O interface 1025) to external storage 1045 and network 1050 for communicating with any number of networked components, devices, and systems, including one or more computer devices of the same or different configuration.
  • Computer device 1005 or any connected computer device can be functioning as, providing services of, or referred to as a server, client, thin server, general machine, special-purpose machine, or another label.
  • I/O interface 1025 can include, but is not limited to, wired and/or wireless interfaces using any communication or I/O protocols or standards (e.g., Ethernet, 802.1 lx, Universal System Bus, WiMax, modem, a cellular network protocol, and the like) for communicating information to and/or from at least all the connected components, devices, and network in computing environment 1000.
  • Network 1050 can be any network or combination of networks (e.g., the Internet, local area network, wide area network, a telephonic network, a cellular network, satellite network, and the like).
  • Computer device 1005 can use and/or communicate using computer-usable or computer-readable media, including transitory media and non-transitory media.
  • Transitory media include transmission media (e.g., metal cables, fiber optics), signals, carrier waves, and the like.
  • Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.
  • Computer device 1005 can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some example computing environments.
  • Computer-executable instructions can be retrieved from transitory media, and stored on and retrieved from non-transitory media.
  • the executable instructions can originate from one or more of any programming, scripting, and machine languages (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others).
  • Processor(s) 1010 can execute under any operating system (OS) (not shown), in a native or virtual environment.
  • OS operating system
  • One or more applications can be deployed that include logic unit 1060, application programming interface (API) unit 1065, input unit 1070, output unit 1075, and inter-unit communication mechanism 1095 for the different units to communicate with each other, with the OS, and with other applications (not shown).
  • API application programming interface
  • the described units and elements can be varied in design, function, configuration, or implementation and are not limited to the descriptions provided.
  • Processor(s) 1010 can be in the form of hardware processors such as central processing units (CPUs) or in a combination of hardware and software units.
  • API unit 1065 when information or an execution instruction is received by API unit 1065, it may be communicated to one or more other units (e.g., logic unit 1060, input unit 1070, output unit 1075).
  • logic unit 1060 may be configured to control the information flow among the units and direct the services provided by API unit 1065, input unit 1070, output unit 1075, in some example implementations described above.
  • the flow of one or more processes or implementations may be controlled by logic unit 1060 alone or in conjunction with API unit 1065.
  • the input unit 1070 may be configured to obtain input for the calculations described in the example implementations
  • the output unit 1075 may be configured to provide output based on the calculations described in example implementations.
  • each of the worker nodes has a first message broker and at least one first message handler, a second message broker and at least one second handler, and a data route management module that manages data routes by associating first message broker with first message handler in the same worker node, and second message broker with second message hander in the same worker node, and when receiving data, a load balanceer forwards the data to any message broker for storing, wherein stored data is sent with the configured data route in each worker node.
  • Example implementations may also relate to an apparatus for performing the operations herein.
  • This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs.
  • Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium.
  • a computer- readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible or non-transitory media suitable for storing electronic information.
  • a computer readable signal medium may include mediums such as carrier waves.
  • the algorithms and displays presented herein are not inherently related to any particular computer or other apparatus.
  • Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.
  • the operations described above can be performed by hardware, software, or some combination of software and hardware.
  • Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application.
  • some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software.
  • the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways.
  • the methods may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format.

Landscapes

  • Computer And Data Communications (AREA)

Abstract

Example implementations described herein involve systems and methods involving a plurality of worker nodes, each of the plurality of worker nodes involving a first message broker and at least one first message handler; a data route management module configured to manage data routes by associating the first message broker and the at least one first message handler of a first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of a second worker node from the plurality of worker nodes; and a load balancer configured to forward received data for storage with a configured data route from the managed data routes to route through ones of the plurality of the worker nodes through the at least one first handler of the ones of the plurality of the worker nodes.

Description

DATA FLOW MANAGEMENT SYSTEM
BACKGROUND
Field
[0001] The present disclosure is generally directed to data flow management systems, and more specifically, to systems and methods for facilitating scalable data flow management systems.
Related Art
[0002] There are many data flow management systems in the related art.
[0003] In a first related art example, there is a location-aware virtual service provisioning in a hybrid cloud environment. In this first related art example, a sense of location is provided for distributed virtual switch components into the service provisioning scheme to reduce latency observed in conducting policy evaluations across a network in a hybrid cloud environment. A management application in a first virtual network subscribes to virtual network services provided by a second virtual network. A first message is sent to the second virtual network, the first message having information configured to start a virtual switch in the second virtual network that switches network traffic for one or more virtual machines in the second virtual network that are configured to extend services provided by the first virtual network into the second virtual network. A second message is sent to the second virtual network, the second message involving information configured to start a virtual service node in the second virtual network that provides network traffic services for the one or more virtual machines.
[0004] In a second related art example, there is data traffic load balancing based on application layer messages. In such related art implementations, a method is used for application layer message-based load balancing. According to one aspect, when a network element receives one or more data packets that collectively contain an application layer message, the network element determines a message classification to which the application layer message belongs. Using a loadbalancing algorithm that is mapped to the message classification, the network element selects a server from among a plurality of servers, and sends the message toward that server. According to one “adaptive” load-balancing algorithm, the network element selects the server based on multiple servers’ average historical response times and average outstanding request wait times. The network element continuously maintains these statistics for each server toward which the network element has sent requests. The network element tracks response times by recording how much time passes between the sending of a request to a server and the receiving of a corresponding response from that server.
[0005] In a third related art example, there is context-aware dynamic policy selection for messaging behavior. In this related art example, messaging policies can be dynamically updated based on operations, administration, maintenance, and provisioning (OAMP) data generated by data plane entities of a messaging network. For example, existing messaging policies may be dynamically modified based on OAMP data generated by message brokers and/or network elements (e.g., queues). As another example, new messaging policies may be dynamically created based on the OAMP data. As another example, an updated set of messaging policies may be selected from a pool of policies based on the OAMP data. Dynamically updating messaging policies can be achieved using information model processing frameworks, such as the next generation directory enabled networks (DEN-ng) model. Various events may trigger the creation of new messaging policies and metrics, such as adding new data plane entities and/or network elements to the network, receiving new messaging instructions, and so on.
[0006] In a fourth related art example, there is a system and method for concentration and load-balancing of requests in a distributed computing environment. Such related art examples can involve a system and a method for reducing the number of connections in an Internet environment using one or a plurality of connection handlers which handle the connection from the client to the server, and a listener which determines which connection handler to use to handle the connection. Whereas prior solutions required a (n - m) number of connections to handle requests, the invention allows there to be only m connections which significantly reduces resource requirements and allows scalability.
SUMMARY [0007] Related art implementations allow clients to connect to services based on network latency. Applying such techniques in container cluster network can localize the traffic (e.g. service mesh), however, introducing such virtual switches introduces central processing unit (CPU)/memory load which causes reduction in the end-to-end throughput.
[0008] Related art implementations further allow a load balancer to distribute message based on application information. Such a method may reduce inter worker node traffic. However, it requires the load balancer to parse the payload of each of the TCP/IP packets, which causes CPU/memory load on the load balancer and reduces end-to-end throughput.
[0009] Related art implementations also provide a new message broker with a messaging policy. Such implementations require the implementation of a new messaging broker or change the messaging broker itself, which requires significant development costs.
[0010] To address the above issues, the example implementations described herein are directed to the scale out of the data flow management system without introducing extra network traffic in container cluster virtual network, without complicating data flow management, without introducing non-standard requirements to sensors for connecting message broker, and without increasing service down time when the message broker fails.
[0011] Example implementations described herein involve a scalable data flow management system. In example implementations described herein, there is a set of data route stacks (message broker, message handlers) which are deployed in each worker node in a container cluster virtual network. A data route manager configures the same routes to all of the data route stack. Sensors can send sensor data to any message broker. Message handlers subscribe to data from the message broker on the same worker node, thus avoiding inter-worker-node traffic.
[0012] In example implementations described herein, the data route manager manages a single data route per single source (binding key/queue or topic to which the sensor sends data) regardless of the number of worker nodes by decoupling endpoint information (message broker hostname, port, credentials) from common routing information (queue/topic name, binding key name, and so on). [0013] In example implementations described herein, the load balancer or reverse proxy keep connections to the message broker once the sensor connects to one of message brokers to minimize the client connection in message brokers. The load balancer or reverse proxy switches the forwarding message broker when connected message broker gets unhealthy.
[0014] Aspects of the present disclosure can involve a system with a plurality of worker nodes, wherein each of the worker node has a first message broker and at least one first message handler, a second message broker and at least one second handler A data route management module manages data routes by associating the first message broker and first message handler in the same worker node, and the second message broker and second message hander in another worker node. When receiving data, the load balancer forwards the data to any one of the message brokers for storing, stored data is sent with the configured data route in each of the worker nodes.
[0015] Aspects of the present disclosure can involve a system, involving a plurality of worker nodes, each of the plurality of worker nodes involving a first message broker and at least one first message handler; a data route management module configured to manage data routes by associating the first message broker and the at least one first message handler of a first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of a second worker node from the plurality of worker nodes; and a load balancer configured to forward received data for storage with a configured data route from the managed data routes to route through ones of the plurality of the worker nodes through the at least one first handler of the ones of the plurality of the worker nodes.
[0016] Aspects of the present disclosure can involve a method for a system involving a plurality of worker nodes, each of the plurality of worker nodes involving a first message broker and at least one first message handler; the method involving managing data routes by associating the first message broker and the at least one first message handler of a first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of a second worker node from the plurality of worker nodes; and forwarding received data for storage with a configured data route from the managed data routes to route through ones of the plurality of the worker nodes through the at least one first handler of the ones of the plurality of the worker nodes. [0017] Aspects of the present disclosure can involve a system involving a plurality of worker nodes, each of the plurality of worker nodes involving a first message broker and at least one first message handler; the system involving means for managing data routes by associating the first message broker and the at least one first message handler of a first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of a second worker node from the plurality of worker nodes; and means for forwarding received data for storage with a configured data route from the managed data routes to route through ones of the plurality of the worker nodes through the at least one first handler of the ones of the plurality of the worker nodes.
[0018] Aspects of the present disclosure can involve computer instructions for a system involving a plurality of worker nodes, each of the plurality of worker nodes involving a first message broker and at least one first message handler; the computer instructions involving managing data routes by associating the first message broker and the at least one first message handler of a first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of a second worker node from the plurality of worker nodes; and forwarding received data for storage with a configured data route from the managed data routes to route through ones of the plurality of the worker nodes through the at least one first handler of the ones of the plurality of the worker nodes. The computer instructions can be stored in a non- transitory computer readable medium and executed by one or more processors.
BRIEF DESCRIPTION OF DRAWINGS
[0019] FIG. 1 illustrates an example system architecture upon which example implementations can be applied.
[0020] FIG. 2A illustrates an example data flow from sensors to message broker in logical and physical layers, in accordance with an example implementation.
[0021] FIG. 2B illustrates an example data flow from message broker to ingress in logical and physical layers, in accordance with an example implementation.
[0022] FIG. 3 illustrates problems with deploying multiple independent message brokers. [0023] FIG. 4 illustrates an example of the scalable data flow management system, in accordance with an example implementation.
[0024] FIG. 5A illustrates data route information, in accordance with an example implementation.
[0025] FIG. 5B illustrates endpoint information, in accordance with an example implementation.
[0026] FIG. 6 illustrates a flow chart of creating route and data flow from sensor to first message handler, in accordance with an example implementation.
[0027] FIG. 7 illustrates the flow chart of creating route and data flow from sensor to first message handler when failure happens, in accordance with an example implementation.
[0028] FIG. 8 illustrates an example of the scale out involving a sequence of adding a worker node, in accordance with an example implementation.
[0029] FIG. 9 illustrates a system involving a plurality of physical systems networked to a management apparatus, in accordance with an example implementation.
[0030] FIG. 10 illustrates an example computing environment with an example computer device suitable for use in some example implementations.
DETAILED DESCRIPTION
[0031] The following detailed description provides details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term “automatic” may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of ordinary skill in the art practicing implementations of the present application. Selection can be conducted by a user through a user interface or other input means, or can be implemented through a desired algorithm. Example implementations as described herein can be utilized either singularly or in combination and the functionality of the example implementations can be implemented through any means according to the desired implementations.
[0032] FIG. 1 illustrates an example system architecture upon which example implementations can be applied. As illustrated in FIG. 1, there can be a plurality of sensors that are configured to feed into an external message broker, either directly or via an internet of things (loT) gateway. External message broker can feed into a data route stack of the container cluster. The data route stack can involve a first message handler to handle the ingress from the external message broker, an internal message broker to facilitate messages internally in the data route stack, and a second message handler to handle egress to the data lake. Depending on the desired implementation, a data route manager (registry) can manage inputs from a user interface (UI).
[0033] Data lake can involve a time series data store, a blob store, a NoSQL and/or SQL database, a distributed file system (DFS) such as a Hadoop DFS, and a message broker. The data stored in the data lake can be provided to analytics services in accordance with the desired implementation.
[0034] Variations of the architecture can also be done to facilitate the desired implementation. For example, the first and second message handler as well as the internal message broker can be replaced by a single message handler if desired. Further, the data lake can be outside of container cluster if desired.
[0035] General way to scale out (increase the number of messages to published and subscribed per seconds) message broker is to cluster the broker and add message broker nodes. FIG. 2A and FIG. 2B illustrates data flow from sensors to message broker and from message broker to ingress in logical and physical layers, respectively.
[0036] In the example of FIG. 2A, when a sensor sends data bound to queue C, load balancer distributes data to one of reverse proxies (i.e., kube proxy) and the reverse proxy forwards the data to one of the broker nodes. If the broker node does not own the bound queue, then the broker node forwards the data to a node that owns the queue. This allows for dumb sensors that send data to the broker nodes without noticing where the queue exists, which makes the footprint of the messaging client smaller. However, this also introduces a lot more inter-worker node traffic.
[0037] Specifically, FIG. 2A illustrates data flow from sensors to message broker in logical and physical layers. In the logical (application) layer 210, the data flow from the sensors go to the load balancer (LB) then through a clustered message broker 211 composed of a plurality of message broker nodes that are configured to distribute the data to the intended deseitnation.
[0038] In the logical (Container cluster virtual network) layer 220, the load balancer receives sensor data and distributes the traffic to the reverse proxies (e.g. kube-proxy) at 221. The reverse proxy then distributes the traffic to the message broker at 222.
[0039] In the physical layer 230, the worker nodes (e.g., Kubemetes worker nodes) can be instantiated by a container (e.g. calico node, a container cluster virtual network) which is facilitated by virtual routers. At 231, the load balancer sends the data to a worker node. The reverse proxy distributes the traffic at 232, and the traffic is forwarded across different worker nodes 233 until it reaches the destination node, which writes the message in storage at 234.
[0040] Specifically for FIG. 2B, in the logical (application) layer 240, the clustered message broker 241 distributes a message to a message handler that handles ingress. The message handler distributes the message to the appropriate message broker.
[0041] In the logical (Container cluster virtual network) 250, the reverse proxy receives the message from the message handler and distributes the traffic to the message broker, which will similarly distribute to the reverse proxy.
[0042] In the physical layer 260, each worker node subscribes to data to another worker node, and can forward received messages to a broker node with a queue. The receiving broker node can read and return messages received.
[0043] FIG. 3 illustrates problems with deploying multiple independent message brokers. Assume that multiple independent message brokers with identical endpoints are deployed instead of clustered. In this case, sensors need to recognize in which broker node the queue exists, which requires a non-standard messaging client. The sensors need to switch message brokers that it is sending data to depending on the underlying queue/topic to be transmitted. The ingress also needs to switch message brokers that it is subscribing data from depending on the underlying queue/topic to be transmitted. Further, the data route manager will have to manage many data routes (# of message brokers * # queues/topics * # of ingress).
[0044] Also, when the connected message broker node is down, some entity such as the data route manager needs to detect failure, create a queue in an unhealthy node, and then notify the connected clients to switch to healthy message broker endpoints, which increases service down time.
[0045] Example implementations described herein involve a scalable data flow management system wherein a set of data route stack (message broker and message handlers (ingress and egress) are deployed in each worker node. Data route manager configures the same routes to all of the data route stack, so that sensors can send sensor data to any of the message brokers. Data route manager manages a single data route per single source, regardless of the number of worker nodes, by decoupling endpoint information (message broker hostname, port, credentials) from common routing information (queue name, binding key name, etc.). Endpoint information is created per worker node for ingress and egress. Ingress and egress connect to the message broker endpoint from the worker node running on it, and connects to the same worker node, while getting the binding key and queue name from the data route manager.
[0046] Through such example implementations, all the ingress and egress brokers always subscribe to sensor data from all of the queues. However, load balancer (LB) or reverse proxy keep connections with the TCP sticky session to the message broker once the sensor connects to one of message brokers. Thus, ingress and egress obtain data from the specific queue that the LB is forwarding data to, although ingress and egress are always listening to all the queues.
[0047] Further, when one of message broker gets unhealthy and LB stops forwarding sensor data to the unhealthy broker node and forwards the data to another broker, the ingress and egress on the same worker node handle them. Thus, the message inter-worker-node traffic can be reduced without complicating data flow management, requiring a non-standard messaging client, or increasing service down time. The number of ingress and egress (message handler) can be changed for improving the performance of flow performance per node, and the number of sets of data route stack can be changed for improving the performance per cluster.
[0048] FIG. 4 illustrates an example of the scalable data flow management system, in accordance with an example implementation. In the example of FIG. 4, there can be a plurality of worker nodes 403-1, 403-2, ..., 403-N, each of which manages a data route stack 410 that can involve a first message broker such as external brokers 405-1, 405-2, 405-N, at least one first message handler such as ingress message handlers 1 -I, 2-1, N-I, a data route management module 404 configured to manage data routes via data route information by associating the first message broker and the at least one first message handler of a first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of a second worker node from the plurality of worker nodes, and a load balancer 402 configured to forward received data for storage with a configured data route from the managed data routes to route through ones of the plurality of the worker nodes through the at least one first handler of the ones of the plurality of the worker nodes as illustrated in FIG. 4. The load balancer 402 maintain the connection to the same broker with a sticky session.
[0049] In the example of FIG. 4, there can be a plurality of sensors 401, wherein each of the sensors 401 can be configured to send data through any of the plurality of worker nodes.
[0050] In an example implementation, the data route management information can manage the destination of the data from each sensor by indicating the queue/topic and binding key. The data route management information can also define the routes for the ingress message handlers messages by defining the source (queue/topic, binding key, message broker endpoint) and destination (queue/topic, binding key, message broker endpoint). Further, the data route management information can also define the routes of the egress message handlers by defining the source (queue/topic, binding key, message broker endpoint) and destination (database and table name, database endpoint). All of the ingress nodes and brokers obtain the same routing information by using the same service name label (e.g., a key name for getting data route information).
[0051] Accordingly, each of the data routes can be defined by a source of sensor data and a destination of the sensor data. Further, each of the plurality of worker nodes are configured with endpoint information EN-1, EN-2, EN-N which can involve a hostname to identify a source of the plurality of worker nodes and a destination to which the data processed by the plurality of worker nodes is to be forwarded.
[0052] The data route manager management module 404 can be configured to facilitate a single data route per single data source (sensor). The single data route per single data sources can be defined according to the binding key/queue or topic that the sensor sends data to, and can be maintained regardless of the number of worker nodes by decoupling endpoint information (message broker hostname, port, credentials) from common routing information (queue/topic name, binding key name, and so on).
[0053] Depending on the desired implementation, the data route stack 410 can have the message broker and handler set manage both ingress and egress. However, there can also be a dedicated second internal message broker 406-1, 406-2, 406-N to handle internal message transfer within the worker node, and at least one second handler 1-E, 2-E, N-E that acts as the egress message handler. The second internal message broker can be configured to subscribe to data only from the at least one first message handler (ingress). In this manner, the data route management module 404 is configured to manage and configure data routes by associating the first message broker and the at least one first message handler of the first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of the second worker node from the plurality of worker nodes via the second message broker and the at least one second handler of the first worker node. In this manner, messages received from the external message broker are forwarded to the ingress message handlers, that distribute to the ingress/internal message broker to forward to the egress message handler. The egress message handler can then forward the message to another worker node in accordance with the route defined by the data route information.
[0054] Example of data route information and endpoint information are shown in FIGS. 5 A and 5B, respectively. With respect to FIG. 5 A, data route information is classified into two: source and destination. Source route information is for each microservice to get data from, and destination is to write data to. In both data routes, query information is defined with protocol. For example, in this example, message handler reads j son data with amqp protocol with Quality of Service (QoS) level 1000 by binding ba413 binding key to ba413 topic within hiota-exchange exchange. Note that the data route does not include resolvable hostname, IP address or TCP/UDP port number.
[0055] With respect to FIG. 5B, endpoint information is created per worker node. For example, in endpoint info for worker node 1, hostname and port of message broker running on the worker node 1 are defined. The endpoint information for worker node 1 is mounted by message handler running on the node 1. In this example, message broker exists on each worker node, but there is only 1 influxDB, so there is an endpoint information for each worker node, but there is one endpoint for influxDB across all the worker nodes. Thus, message handler write data to the same influxDB while getting data from message broker on the same node.
[0056] FIG. 6 illustrates a flow chart of creating route and data flow from sensor to first message handler, in accordance with an example implementation. The point of this system is that both route A and B are created for sensor 1 and 2 to message handers in both worker node 1 and 2; although only data of sensor 1 is received and handled in worker node 1, and that of sensor 2 is received and handled in worker node 2. Note that message handers in each node can be scaled out.
[0057] FIG. 7 illustrates the flow chart of creating route and data flow from sensor to first message handler when failure happens, in accordance with an example implementation. The point of this system is that handlers in other containers receives and handle it without any configuration change when other node fails. When the load balancer detects a failure 701 occuring on a first (egress/ external) broker of a worker node via noting that the connection is closed, the load balancer will forward the sensor data of the failed message broker to another egress/extemal message broker of another worker node using the same connection. The second message broker of the another worker node will determine the endpoint destination of the forwarded sensor data, and the second message handler forwards the forwarded sensor data to the endpoint destination as illustrated in FIG. 7.
[0058] FIG. 8 illustrates an example of the scale out involving a sequence of adding a worker node, in accordance with an example implementation. When the UI (or any entity) triggers to add a worker node, the container cluster scheduler (e.g., Kubernetes scheduler) adds a new worker node and start containers such as external brokers and message handers on the new node. Then, the data route manager creates endpoint information and saves the file on the new worker node for message handlers to mount the file and sends route A and B to the message handlers on the new node. Then, the message handlers connects to the brokers on the same node.
[0059] As illustrated in FIG. 8, the container cluster scheduler 800 can be configured to, in response to a trigger to add a new worker node 801 to the plurality of worker nodes for one or more of the data routes, add the new worker node to the plurality of worker nodes; and deploy a container to configure the new worker node with the first message broker and at least one first message handler. Accordingly, the data route management module can be configured to create endpoint information for the new worker node; configure the new worker node with the endpoint information, wherein the at least first message handler of other ones of the plurality of worker nodes connected to the one or more of the data routes are configured to mount the endpoint information; and configure the one or more of the data routes on the at least one first message handler of the new worker node.
[0060] Although the example implementations described herein are described with respect to use of a load balancer, a reverse proxy can execute similar functions of the load balancer to maintain connections to the first message broker for when a sensor connects to the first message broker of one of the plurality of nodes. The reverse proxy can also handle the same functions as the load balancer so that it is configured to switch the first message broker and the first message handler of the second worker node to another first message broker and another first message handler of another worker node for when the first message broker of the second worker node fails.
[0061] FIG. 9 illustrates a system involving a plurality of physical systems networked to a management apparatus, in accordance with an example implementation. One or more physical systems 901 integrated with various sensors are communicatively coupled to a network 900 (e.g., local area network (LAN), wide area network (WAN)) through the corresponding network interface of the sensor system installed in the physical systems 901, which is connected to a management apparatus(es) 902 that facilitates the container. The management apparatus 902 manages database(s) 903, which contains historical data collected from the sensor systems from each of the physical systems 901. In alternate example implementations, the data from the sensor systems of the physical systems 901 can be stored to a central repository or central database such as proprietary databases that intake data from the physical systems 901, or systems such as enterprise resource planning systems, and the management apparatus 902 can access or retrieve the data from the central repository or central database. The sensor systems of the physical systems 901 can include any type of sensors to facilitate the desired implementation, such as but not limited to gyroscopes, accelerometers, global positioning satellite (GPS), thermometers, humidity gauges, or any sensors that can measure one or more of temperature, humidity, gas levels (e.g., CO2 gas), and so on. Examples of physical systems can include, but are not limited to, shipping containers, lathes, air compressors, and so on. Further, the physical systems can also be represented as virtual systems, such as in the form of a digital twin.
[0062] FIG. 10 illustrates an example computing environment with an example computer device suitable for use in some example implementations, such as a management apparatus 902 as illustrated in FIG. 9, to facilitate all of the functions described in FIGS. 1 to 8 or to facilitate any functionality of the data route management module or a worker node. Computer device 1005 in computing environment 1000 can include one or more processing units, cores, or processors 1010, memory 1015 (e.g., RAM, ROM, and/or the like), internal storage 1020 (e.g., magnetic, optical, solid state storage, and/or organic), and/or I/O interface 1025, any of which can be coupled on a communication mechanism or bus 1030 for communicating information or embedded in the computer device 1005. VO interface 1025 is also configured to receive images from cameras or provide images to projectors or displays, depending on the desired implementation.
[0063] Computer device 1005 can be communicatively coupled to input/user interface 1035 and output device/interface 1040. Either one or both of input/user interface 1035 and output device/interface 1040 can be a wired or wireless interface and can be detachable. Input/user interface 1035 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch-screen interface, keyboard, a pointing/cursor control, microphone, camera, braille, motion sensor, optical reader, and/or the like). Output device/interface 1040 may include a display, television, monitor, printer, speaker, braille, or the like. In some example implementations, input/user interface 1035 and output device/interface 1040 can be embedded with or physically coupled to the computer device 1005. In other example implementations, other computer devices may function as or provide the functions of input/user interface 1035 and output device/interface 1040 for a computer device 1005. [0064] Examples of computer device 1005 may include, but are not limited to, highly mobile devices (e.g., smartphones, devices in vehicles and other machines, devices carried by humans and animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded therein and/or coupled thereto, radios, and the like).
[0065] Computer device 1005 can be communicatively coupled (e.g., via I/O interface 1025) to external storage 1045 and network 1050 for communicating with any number of networked components, devices, and systems, including one or more computer devices of the same or different configuration. Computer device 1005 or any connected computer device can be functioning as, providing services of, or referred to as a server, client, thin server, general machine, special-purpose machine, or another label.
[0066] I/O interface 1025 can include, but is not limited to, wired and/or wireless interfaces using any communication or I/O protocols or standards (e.g., Ethernet, 802.1 lx, Universal System Bus, WiMax, modem, a cellular network protocol, and the like) for communicating information to and/or from at least all the connected components, devices, and network in computing environment 1000. Network 1050 can be any network or combination of networks (e.g., the Internet, local area network, wide area network, a telephonic network, a cellular network, satellite network, and the like).
[0067] Computer device 1005 can use and/or communicate using computer-usable or computer-readable media, including transitory media and non-transitory media. Transitory media include transmission media (e.g., metal cables, fiber optics), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.
[0068] Computer device 1005 can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some example computing environments. Computer-executable instructions can be retrieved from transitory media, and stored on and retrieved from non-transitory media. The executable instructions can originate from one or more of any programming, scripting, and machine languages (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others).
[0069] Processor(s) 1010 can execute under any operating system (OS) (not shown), in a native or virtual environment. One or more applications can be deployed that include logic unit 1060, application programming interface (API) unit 1065, input unit 1070, output unit 1075, and inter-unit communication mechanism 1095 for the different units to communicate with each other, with the OS, and with other applications (not shown). The described units and elements can be varied in design, function, configuration, or implementation and are not limited to the descriptions provided. Processor(s) 1010 can be in the form of hardware processors such as central processing units (CPUs) or in a combination of hardware and software units.
[0070] In some example implementations, when information or an execution instruction is received by API unit 1065, it may be communicated to one or more other units (e.g., logic unit 1060, input unit 1070, output unit 1075). In some instances, logic unit 1060 may be configured to control the information flow among the units and direct the services provided by API unit 1065, input unit 1070, output unit 1075, in some example implementations described above. For example, the flow of one or more processes or implementations may be controlled by logic unit 1060 alone or in conjunction with API unit 1065. The input unit 1070 may be configured to obtain input for the calculations described in the example implementations, and the output unit 1075 may be configured to provide output based on the calculations described in example implementations.
[0071] Through the example implementations described herein, there can be a system involving a plurality of worker nodes, wherein each of the worker nodes has a first message broker and at least one first message handler, a second message broker and at least one second handler, and a data route management module that manages data routes by associating first message broker with first message handler in the same worker node, and second message broker with second message hander in the same worker node, and when receiving data, a load balanceer forwards the data to any message broker for storing, wherein stored data is sent with the configured data route in each worker node.
[0072] Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result.
[0073] Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system’s registers and memories into other data similarly represented as physical quantities within the computer system’s memories or registers or other information storage, transmission or display devices.
[0074] Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium. A computer- readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.
[0075] Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the techniques of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.
[0076] As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format.
[0077] Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the techniques of the present application. Various aspects and/or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.

Claims

CLAIMS What is claimed is:
1. A system, comprising: a plurality of worker nodes, each of the plurality of worker nodes comprising: a first message broker; and at least one first message handler; a data route management module configured to manage data routes by associating the first message broker and the at least one first message handler of a first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of a second worker node from the plurality of worker nodes; and a load balancer configured to forward received data for storage with a configured data route from the managed data routes to route through ones of the plurality of the worker nodes through the at least one first handler of the ones of the plurality of the worker nodes.
2. The system of claim 1, wherein the each of the plurality of worker nodes further comprises: a second message broker; and at least one second handler; wherein the data route management module is configured to manage data routes by associating the first message broker and the at least one first message handler of the first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of the second worker node from the plurality of worker nodes via the second message broker and the at least one second handler of the first worker node.
3. The system of claim 2, wherein the second message broker subscribes to data only from the at least one first message handler.
4. The system of claim 2, further comprising, for detection by the load balancer of a failure occurring on the first message broker of a worker node from the plurality of worker nodes, the load balancer is configured to forward sensor data of the failed first message broker to another first message broker of another worker node from the plurality of worker nodes; wherein the second message broker determines an endpoint destination of the forwarded sensor data; wherein the at least one second message handler forwards the forwarded sensor data to the endpoint destination.
5. The system of claim 1, wherein the data route manager management module is configured to facilitate a single data route per single data source. The system of claim 1, wherein the load balancer or a reverse proxy is configured to maintain connections to the first message broker for when a sensor connects to the first message broker of one of the plurality of worker nodes. The system of claim 1, wherein the load balancer or a reverse proxy switches the first message broker and the first message handler of the second worker node to another first message broker and another first message handler of another worker node for when the first message broker of the second worker node fails. The system of claim 1, wherein the plurality of worker nodes are instantiated as a container cluster virtual network. The system of claim 1, the system further comprising a plurality of sensors, each of the plurality of sensors configured to send data through any of the plurality of worker nodes. The system of claim 1, further comprising a container cluster scheduler configured to, in response to a trigger to add a new worker node to the plurality of worker nodes for one or more of the data routes: add the new worker node to the plurality of worker nodes; deploy a container to configure the new worker node with the first message broker and at least one first message handler; wherein the data route management module is configured to: create endpoint information for the new worker node; configure the new worker node with the endpoint information, wherein the at least first message handler of other ones of the plurality of worker nodes connected to the one or more of the data routes are configured to mount the endpoint information; and configure the one or more of the data routes on the at least one first message handler of the new worker node. The system of claim 1, wherein the each of the data routes is defined by a source of sensor data and a destination of the sensor data; wherein each of the plurality of worker nodes are configured with endpoint information comprising a hostname to identify a source of the plurality of worker nodes and a destination to which the data processed by the plurality of worker nodes is to be forwarded. A method for a system involving a plurality of worker nodes, each of the plurality of worker nodes involving a first message broker and at least one first message handler; the method comprising: managing data routes by associating the first message broker and the at least one first message handler of a first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of a second worker node from the plurality of worker nodes; and forwarding received data for storage with a configured data route from the managed data routes to route through ones of the plurality of the worker nodes through the at least one first handler of the ones of the plurality of the worker nodes. A computer program storing instructions for a system involving a plurality of worker nodes, each of the plurality of worker nodes involving a first message broker and at least one first message handler; the instructions comprising: managing data routes by associating the first message broker and the at least one first message handler of a first worker node from the plurality of worker nodes with the first message broker and the at least one first handler of a second worker node from the plurality of worker nodes; and forwarding received data for storage with a configured data route from the managed data routes to route through ones of the plurality of the worker nodes through the at least one first handler of the ones of the plurality of the worker nodes.
PCT/US2022/079555 2022-11-09 2022-11-09 Data flow management system WO2024102158A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2022/079555 WO2024102158A1 (en) 2022-11-09 2022-11-09 Data flow management system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2022/079555 WO2024102158A1 (en) 2022-11-09 2022-11-09 Data flow management system

Publications (1)

Publication Number Publication Date
WO2024102158A1 true WO2024102158A1 (en) 2024-05-16

Family

ID=91033111

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/079555 WO2024102158A1 (en) 2022-11-09 2022-11-09 Data flow management system

Country Status (1)

Country Link
WO (1) WO2024102158A1 (en)

Similar Documents

Publication Publication Date Title
US11343356B2 (en) Systems and methods for application specific load balancing
US10824409B2 (en) Auto discovery and configuration of services in a load balancing appliance
CN110249596B (en) QOS-based classification and prioritization learning skills for SAAS applications
US11121968B2 (en) Systems and methods for dynamic routing on a shared IP address
KR102304416B1 (en) Automatic Tuning of Hybrid WAN Links by Adaptive Replication of Packets on Alternate Links
US10686707B2 (en) Method to remap high priority connection with large congestion window to high latency link to achieve better performance
EP3510737B1 (en) System and method for quality of service reprioritization of compressed traffic
US9935829B1 (en) Scalable packet processing service
JP6594540B2 (en) System and method for distributed packet scheduling
US9385912B1 (en) Framework for stateless packet tunneling
US20170124478A1 (en) Anomaly detection with k-means clustering and artificial outlier injection
JP2020515158A (en) Method for DNS response reordering based on path quality and connection priority for better QOS
US11451450B2 (en) Scalable control plane for telemetry data collection within a distributed computing system
CN107426007B (en) Method and system for tracking network device information in a network switch
CN113961303A (en) Data center resource monitoring for managing message load balancing with reordering considerations
US20220210086A1 (en) Managing network state for high flow availability within distributed network platform
WO2024102158A1 (en) Data flow management system
US20230032441A1 (en) Efficient flow management utilizing unified logging
US11196668B2 (en) End user premises device controller
US20240163689A1 (en) Management orchestrator for a content-centric network in a 6g network