This disclosure relates to the field of diagnostics data collection in a data network of ISCSI devices capable of reporting diagnostic data like temperature, power etc (hereafter simply referred as data network) and the paper discusses a method of delegating decision of event generation to the reporting device, upon which meaningful diagnostic data is ready to be collected by a data collecting system

Agarwal, Vivek

Mohan, Rupin T.

Puttagunta, Krishna

Seetharaman, Loganathakumar

English

Technical Disclosure Common

Technical Disclosure CommonsDefensive Publications SeriesAugust 16, 2017Configurable events to enable efficient diagnosticsdata collection in ISNS based ISCSI networkLoganathakumar SeetharamanHewlett Packard EnterpriseRupin T. MohanHewlett Packard EnterpriseVivek AgarwalHewlett Packard EnterpriseKrishna PuttaguntaHewlett Packard EnterpriseFollow this and additional works at: http://www.tdcommons.org/dpubs_seriesThis work is licensed under a Creative Commons Attribution 4.0 License.This Article is brought to you for free and open access by Technical Disclosure Commons. It has been accepted for inclusion in Defensive PublicationsSeries by an authorized administrator of Technical Disclosure Commons.Recommended CitationSeetharaman, Loganathakumar; Mohan, Rupin T.; Agarwal, Vivek; and Puttagunta, Krishna, "Configurable events to enable efficientdiagnostics data collection in ISNS based ISCSI network", Technical Disclosure Commons, (August 16, 2017)http://www.tdcommons.org/dpubs_series/627  Configurable events to enable efficient diagnostics data collection in ISNS based ISCSI network   This disclosure relates to the field of diagnostics data collection in a data network of ISCSI devices capable of reporting diagnostic data like temperature, power etc (hereafter simply referred as data network) and the paper discusses a method of delegating decision of event generation to the reporting device, upon which meaningful diagnostic data is ready to be collected by a data collecting system.  In data networks, there usually is a big majority of normally behaving Diagnostic Reporting Devices (DRD) and a small minority of DRDs showing abnormal behavior trend. The DRDs (for example an SFP device) data is collected by a data collecting system (DCS) by the way of traditional periodic polling and is used to analyze potential failures of the link. The data type is either of the two major types – one, range type data or two, counter type of data. SFP device temperature, power, bias current etc. are the range type and SFP link failure counter, Loss-of-sync counter etc. are the counter type.   Most of the range type data collected from a healthy SFP device typically falls within a small range of a minimum and a maximum values. Most of the counter type data in a healthy SFP device typically don’t increment for months if not for years. Any range type of data falling within the min and max values and   any counter type data which has not changed from its previous sample values for long can be safely omitted for meaningful data analysis – we can term them as ‘data noise’.  To reduce such data noise,  rather than traditional periodic polling the DRDs for this data and then analyzing at the DCS end for abnormalities, a better approach would be to delegate the data criteria checking logic followed by an event notification logic at the DRD end itself.   The paper presents an intelligent method by which a DRD can be ‘instructed’ to trigger an ISNS protocol event on an abnormality, a condition to watch out for on the DRD, the condition itself being configurable on the DRD by an ISNS server running on a Data Collecting System (DCS) by means of an ISNS vendor specific message, post which the DCS can use an appropriate polling frequency to collect the data from the DRD.  Traditional diagnostics data collection in an ISNS enabled ISCSI SAN Taking an example of SFP temperature which is a ‘range’ type of data, a typical data sample collected over time is depicted in figure 1. As can be seen, the safe range of an SFP temperature is between 25 and 35 degrees. Any new and normal DRD would report a value within this range almost throughout its normal life span (samples 1 to 15 in the x-axis). When the SFP begins to degrade it might show a value of, say 37 degrees as shown in sample 16. This is the event from when the DRD requires more frequent polling for early recovery from a complete failure. Until the sample 15, the data can be safely omitted from data analysis since those data are in the safe range between a minimum of 25 degrees and a maximum of 35 degrees.  2Seetharaman et al.: Configurable events to enable efficient diagnostics data collectiPublished by Technical Disclosure Commons, 2017  Figure 1SFP Temperature: Month vs Celsius Figure 2 details the sequence of a traditional polling approach. As the polling frequency increases, the number of message frames and the associated response frames increase and hence the CPU, storage and the network bandwidth needs for the increased frequency. As can be seen, the number of operations involved  in the whole system in a span of 1 year, assuming a polling frequency of 30 minutes M,  M = 365 * (24 *2) * [(1 * http request) + (1 * http json payload) + (n * (isns requestMsg +isns response Msg)) + (1*data store)]  The CPU, memory, storage and network bandwidth required for the polling system is a factor of M.  The diagram below shows the sequence and the number of message frames exchanged. The messages are termed as ISCSI_RDP (which stands for ‘Report ISCSI diagnostic data for Ports) and ISCSI_RDP_RSP (which stands for the ‘reported RDP data frames’ themselves. Through the rest of the document the term RDP is synonymous to Diagnostics data generally.  0153045601 3 5 7 9 11 13 15 17SFP Temperature3Defensive Publications Series, Art. 627 [2017]http://www.tdcommons.org/dpubs_series/627ISNS ServerData Store (DCS)DRD 1DRD 2DRD 3DRD nISCSI_RDPISCSI_RDP_RSPISCSI_RDPISCSI_RDP_RSPISCSI_RDPISCSI_RDP_RSPISCSI_RDPISCSI_RDP_RSPStore DataStore DataPoll duration. . .Poll duration Figure 2 Traditional polling approach sequence  Proposed diagnostics data collection method with an ISNS enabled ISCSI SAN  The proposed approach delegates certain data analytic responsibility to the ISNS end points (DRDs) through one time initialization of diagnostic data (RDP) conditions which specify what to look for in the SFPAttributes. It then leverages the SCNEvent capability of an ISNS client to notify the ISNS Server of any change in normal behavior. The process is then followed by the traditional ISCSI_RDP and ISCSI_RDP_Response sequence shown in Figure 4.  Step1: One time initialization of RDP conditions The proposed approach has one extra step during initialization of the ISNS subsystem as compared to traditional polling approach, that is to configure the ISNS end points (DRD) on what attributes the approach are concerned about and the associated conditions to be observed on those attributes, for the end point (DRD) to trigger an event to the ISNS server.   This approach requires a new vendor specific ISNS message named as ‘RDPConditionSet’ sent by the ISNS server to an ISNS end point (DRD) and the associated ‘RSPConditionSetResponse’ sent by the receiving ISNS end point(DRD) to the ISNS server on acknowledging the set condition. Three forms of conditions are proposed in this paper for a SFPAttribute to be initialized. Any SFPAttribute can be initialized to fall within any of the following three types: RANGE, COUNTER and AGE. 4Seetharaman et al.: Configurable events to enable efficient diagnostics data collectiPublished by Technical Disclosure Commons, 2017RANGE condition: This condition applies to a SFPAttribute where the values falling within a range of minimum and maximum value can be safely ignored from reading (and be safely assumed to have a midpoint value). SFPTemperature is an example.  The primary TLV for this condition has a Tag = 1. The Value part of this TLV has two sub-TLVs, one for minimum of the SFPAttribute conditional value range, with tag =1 and a second TLV for the maximum of the SFPAttribute conditional value range with tag =2. Each value part of the sub TLV would be the SFPAttribute value for the minimum and the maximum condition respectively.   COUNTER condition: This condition applies to a SFPAttribute where the value can be safely ignored if it has not increased from its previously read value. SFPLinkFailureCount is one such example. This condition has only one primary TLV associated with with a tag value of 2, and a length of 2 and a value of an ‘addend’ integer. The DRD will raise event on the SFPAttribute reaching a value of previouslyReportedValue + addend.  AGE condition: This condition applies to a SFPAttribute which needs to be read at least once within a specific duration.  SFPPortOperatingSpeed, SFPPortSpeedCapabilities are examples of SFPAttributes where this condition is applicable. Assuming a software requirement which requires to monitor operating speed of a port, irrespective of whether the operating speed has changed or not, and assuming it is safe to read the value once in a day, a condition TLV be set with a tag = hours, length = 2 bytes and Value =24 on the SFPPortOperatingSpeed, the DRD will raise an event every 24 hours. The duration is specified in as a factor of any of minutes, hours or days in this proposal. Other time units like seconds, months and years are extensions to the proposal if found necessary at a later research.   ORType = RDPAttributeLengthValueType = ConditionType=COUNTERLengthValueType = ConditionType=RANGELengthValueType = RangeType=MINLengthValue =minValueType = RangeType=MAXLengthValue=maxValueORType = ConditionType=AGE_SINCE_LASTLengthValue=TimeUnitTypeORType = TimeUnitType=MINUTESLengthValue =minutesCountType = TimeUnitType=HOURSLengthValue =hoursCountType = TimeUnitType=DAYSLengthValue =daysCountOROROR   Figure 3 RDP Condition message and payload TLV Step2: Event driven data collection sequence with ISNS enabled ISCSI SAN Figure 4 shows the SCNEvent driven sequence post the one-time initialization of the RDP conditions on the DRDs. As can be seen the number of message packets (E) 5Defensive Publications Series, Art. 627 [2017]http://www.tdcommons.org/dpubs_series/627exchanged between the ISNS server and the DRD ISNS end points over the same period of comparison with a traditional polling method, is far less than the value of M described in section “Traditional diagnostics data collection in an ISNS enabled ISCSI SAN”  E = C * (1*SCNEvent + 1*SCNEventResponse +1*ISCSI_ RDP + 1*RDP_RESP), where E is the number of condition violations happening in the DSD multiplied by the number of DSDs. In a practical ISNS network, it can be proved that E << M.  ISNS ServerData Store(DCS)DRD 1DRD 2DRD 3DRD nSCNEventSCNEventResponse. . .Mgmt nodeSCNEventSCNEventResponseStore DataSCNISCSI_RDPISCSI_RDP_RESPSCNISCSI_RDPISCSI_RDP_RESPStore Data Figure 4 SCNEvent driven data collection sequence  Advantages  The proposed approach also offer the following advantages: 1. Significant reduction of message and response packets within the network  between a DCS and DRD thereby relieving the CPU cycles of the involved  DRDs such as ISNS end points 2. Facilitates subscription to meaningful data change events by a DCS such as data analysis application and the associated event notification by the ISNS server based broker subsystems which do poll-and-forward diagnostic data from a DRD to DCS 3. In the absence of this approach for any given DRD , the traditional polling approach can still continue to coexist 4. The proposed approach can be enhanced to address additional conditional logic in future proposals 5. This approach is protocol agnostic and in future, can be easily extended to protocols with similar event notification infrastructure.  Disclosed by Loganathakumar Seetharaman, Rupin T Mohan, Vivek Agarwal and Krishna Puttagunta, Hewlett Packard Enterprise 6Seetharaman et al.: Configurable events to enable efficient diagnostics data collectiPublished by Technical Disclosure Commons, 2017

Configurable events to enable efficient diagnostics data collection in ISNS based ISCSI network

https://www.tdcommons.org/cgi/viewcontent.cgi?article=1686&amp;context=dpubs_series

Configurable events to enable efficient diagnostics data collection in ISNS based ISCSI network

Abstract

Similar works

Full text

Available Versions

Technical Disclosure Common