Hey all, Earlier this week, your DII tenant gained the ability to discover Google Cloud NetApp Volumes. The vision of this collector is that we will discover all instances across your entire Google "organization", regardless of where it is - i.e, we don't want DII users to have to manage lots of collectors simply for having these volumes in different projects and/or sites around the world. We are addressing both capacity and performance use cases - we will have performance data at 5 minute granularity Matt
... View more
This is probably a bit overdue, but I was just chatting with a customer who can make this switch: DII has two Brocade FOS Fibre Channel Switch data collector options: "Fibre Channel Switches" - this collector type uses SSH for inventory data, and SNMP for performance. This collector type supports an ABSURD range of FOS firmware (yay!), back to 4.something, but there can be substantial complexities with configuring SNMP (boo!) on FOS. You may be forced into using SNMPv3 for performance by any of: What FOS firmware you are running Whether you actively use Virtual Fabrics (have ports assigned to > 1 VF on a physical asset) "FOS REST" - this collector type uses HTTP(S) REST API calls for both inventory and performance data - this basically means if you get inventory working, performance will magically Just Work So, why are we having this discussion? FOS introduced their REST API with FOS 8.2.... but there are a few gaps that only got filled with 9.0 - XISL visibility, and routing. So, the DII FOS REST collector supports 8.2+, but we are blind to XISLs and routing unless you get to 9+. So: If your entire environment is 9.0+ -> you can switch entirely to FOS REST If your environment is a mix of 8.2+ -> you have to assess if you use XISLs OR routing. If you use either, you should use the CLI+SNMP collector. You can, however, think about the various islands in your environment - if you have no routing/XISLs in your branch offices, you COULD use FOS REST there. Where you could have pain is trying to mix+match collector types inside of an interconnected environment using XISLs or routing - if you are using our FOS REST collector against a 8.2.x device that cannot tell us about the full extent of the logical configuration, sadness may result - DII may not be able to understand in the interrelationships due to the lack of source data inherent with 8.2 FOS 8.1 or earlier - you need to stay with the CLI+SNMP based collector
... View more
https://www.youtube.com/watch?v=l-E0nItaxKY This video shows how to import an external data set into the Data Infrastructure Insights (DII) Cognos environment and combine it with existing DII data. Primary use cases are metrics or attributes that are not collected by DII but can be combined with DII data or run as stand-alone data sets. Other use cases are static-type data sets like rate cards used for financial reporting.
... View more
Attached is the latest Data Infrastructure Insights Report Catalog for Business Intelligence in PDF file format. This document provides a visual repository of storage and compute reporting artifacts available for delivery by NetApp Customer Success professionals at no cost. Report snapshots and detailed definitions are provided by category. The catalog contains a selectable table of contents for easy navigation.
... View more
Hey all, Brocade FOS 8.2.3e and 8.2.3e1 appear to have a bug in their SNMP stack. If you were using our SSH+SNMP based collector, and you upgraded to either of these 2 releases, your SNMP based performance polls will fail with a ....Row Duplicates.... message.... because of duplicative rows in the responses. FOS 8.2.3e2 appears to have a fix for this issue: https://docs.broadcom.com/doc/FOS-823e-RN FOS-859350 - SAN switch monitoring tools via SNMP do not function properly So, if you thinking of consuming a 8.2.3e upgrade, 8.2.3e2 seems to be where you want to land Our alternative Brocade FOS REST API collector type is not impacted. Whether you should switch your Brocade collectors to our FOS REST approach is a topic I should tackle in a future thread, but I have to run.... Matt
... View more