Patent Application
20190034477
This disclosure relates in general to monitoring transactions in a network fabric and, more particularly, to generating a transparent software-seamed and augmented view of the fabric.
Asynchronous switch systems can have over 200 intercommunicating applications. Cookies are generally used for storing and tracking of transient states of transactions within an application. This may not be helpful in an environment hosting asynchronous applications, as each application processes messages on a best effort basis. Moreover, when this is extrapolated to a network fabric, the existing approach will not hold true.
Many aspects of the disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.
Methods and systems for tracking transactions in a network fabric are provided. The method includes: receiving a message generated by a node in the network fabric; assigning a uniform fabric identifier (“UFID”) to the node; assigning a uniform transaction identifier (“UTID”) to the message”; appending the UFID and the UTID to the message; and storing the message in a database.
Additional embodiments include a system of nodes arranged in a fabric. The system includes: a first node associated with a first unique-to-the-fabric fabric identifier (“UFID”) and a counter providing a first unique-to-the-node transaction identifier (“UTID”), the first node operable to generate a first message with a header including the first UFID and the first UTID; a second node associated with a second unique-to-the-fabric fabric identifier (“UFID”) and a counter providing a second unique-to-the-node transaction identifier (“UTID”), the second node operable to generate a second message with a header including the second UFID and the second UTID; and a data aggregator in communication with the first node and the second node and operable to receive and store the first message and the second message.
Also disclosed is another system. The system includes a processor in communications with memory and a database. The memory stores instructions for: receiving a message generated by a node in a network fabric; assigning a uniform fabric identifier (“UFID”) to the node; assigning a uniform transaction identifier (“UTID”) to the message”; appending the UFID and the UTID to the message; and storing the message in the database.
Presently disclosed is an apparatus and method to generate a transparent software-seamed and augmented view of the fabric, along with the ability to magnify and view each cross-section of the fabric when needed. It is realized by characterizing the events into network or configuration driven triggers by identifying and tagging control plane packets (message and transaction service packets or “MTS” packets) to yield an aggregated and sequenced view of the fabric.
A common resource across application in asynchronous systems is the interprocess communications (“IPC”). In this disclosure, the focus is upon the MTS type of IPC, but those of skill in the art upon reading this disclosure will understand that other message formats may be captured. Each node in the fabric is assigned a UTID which is an identifier unique to a particular node in the fabric, for example a switch, and will be assigned to a transaction. This UTID may be injected by the source application. In the case of command line interface (“CLI”) triggers, it is populated by the virtual shell (“VSH”), and for other internal triggers the source application processing bridge protocol data units (“BPDU's”) the BPDU's insert the UTID. The UFID is a unique identifier to the fabric for each node in a network fabric. In an exemplary embodiment, where existing solutions uses intermediate system-to-intermediate system (“ISIS”) protocol, the disclosure contemplates reusing the ISIS unique identifier as the UFID.
While UTID tagging is sufficient for tracking transactions across applications in a single node, there are events in a fabric that occur due to a change in state of an application on a different node. These protocol packets do not carry this information in prior art systems; however, this disclosure contemplates using UFID and UTID tagging in the header to track these triggers.
For each transaction received by a node, if the UFID is the same UFID of the node then this is a CLI which is an internal trigger to the node. If the trigger is a VSH trigger, the system can identify the CLI trigger by looking up the UTID issued for the CLI to VSH.
If the UFID is not equal to the UFID of the node, the transaction is due to an event generated by a control packet received from another node. If the issue is due to an event in another node of the fabric, the system knows the UFID of the transaction and the timestamp when the packet was received on the node. A search may now be performed for the packet that was sent around that timestamp on the node with the UFID of the transaction. The system can find out the UTID of the transaction by looking at the header to the transaction or message, and by repeating this process the system can find the root cause of the failure and provide relevant logs for detailed debugging.
Examining fabric 100 under the following scenario yields the following results. A VLAN 12 is created by a user on all three nodes 110, 120, and 130. Then, the user does a shutdown of VLAN 12 on node 2120.
The request is propagated by the back end of a user function, such as VSH to the VLAN Manager. The VLAN Manager shuts down VLAN 12 on node 2120 and generates a message with a header including UTID: 101; UFID 12. All messages, or transactions, will be tagged with the [101,12] in the header. Due to this transaction, spanning tree protocol (“STP”) will put VLAN 12 to disabled on port 1/3 and 1/1. It will send control packets with that information to node 1110 and node 3130. The time and the application that sent that control packet is tracked on that port.
The BPDU packet, or control packet, is received on port 1/3. Node 3130 knows that the BPDU packet was received on a port connected with node 1110 with UFID 13; therefore, the UFID for this packet is 13. The MTS header detail will be UTID 100; UFID 13. All transactions relating to node 3 will be tagged [100, 13].
The BPDU packet, or control packet, is received on port 1/2. Node 2120 knows that the BPDU packet was received on a port connected with node 1110 with UFID 11; therefore, the UFID for this packet is 11. The MTS header detail will be UTID 100; UFID 11. All transactions relating to node 1 will be tagged [100, 11].
For the system to work in the best possible fashion, the timestamps between all nodes should be in sync.
The data collector(s) 210 are in communication with a Regex Engine 220. The RegEx Engine 220 may take messages in a diverse array of formats and place them into a common format, such as by using key-value pairs. The Regex Engine 220 may be a list of regex. Each regex may extract useful and necessary data to support various data models. The datalogs in the form of file or byte stream data is given as input to the regex engine. The input is made to run against each of the regex and the output obtained has results that populate the various data-models. The output may be a key-value pair pertaining to the data model corresponding to the regex. Users can define custom regex based on the data/log given as input and the data model. The custom regex may then be installed into the RegEx Engine 220 along with the data model.
The RegEx Engine 220 is in communication with a Storage Database 230, for example, a columnar database, for storing the output of the RegEx Engine 220 which is simply the messages placed into a common format. A data gatherer sits on top of the regex engines and does the writes to the Storage Database 230 and to a Data Collector 240 that may serve to provide notifications to users of certain user-defined changes of state of the Storage Database 230.
An Applications and Data Extractor 250 is in communication with the Storage Database 230. The Data Extractor is a query engine to extract datasets and transform, modify, aggregate, and/or process queries to feed as input for user-defined queries. The Applications are for user-customizable queries that are created with well-defined templates.
Any process, descriptions or blocks in flow charts or flow diagrams should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process, and alternate implementations are included within the scope of the present disclosure in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved. In some embodiments, steps of processes identified in
It should be emphasized that the above-described embodiments of the present disclosure are merely possible examples of implementations, merely set forth for a clear understanding of the principles of the switching systems and methods. Many variations and modifications may be made to the above-described embodiment(s) without departing substantially from the spirit and principles of the disclosure. Although all such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims, the following claims are not necessarily limited to the particular embodiments set out in the description.
