The Four Dimensions of IT Infrastructure Topology

Understanding how all of your technical assets are interconnected and related has a multitude of uses beyond troubleshooting issues.  However, if you really think about it, there’s more than one dimension to infrastructure topology, which is why FireScope has not one, but 4 different topology mapping capabilities.  In this post, we’re going to explore each of them, what they are useful for and how they are automatically generated.  Be sure to click on any of the screencaps below to see the full-size image.

 

Service Topology

As you define your services (or synchronize from ServiceNow), FireScope dynamically generates a service topology view as you can see to the left.  The focus here is on helping users explore the various dependencies of a service, but without requiring any effort.  Most of our topology mapping visualizations leverage HTML5/Canvas to offer a rich, interactive experience.  For example, as you can see in the screencap, the Service Groups with a red background are in a failed state, which I can then drill down to quickly trace the source of the problem.  Service topology maps can be dropped into any dashboard in FireScope, or you can access it directly by going to Service Management > Service Explorer.

 

Network Topology

With all of the hype around cloud and virtualization and software-defined everything, it’s easy to forget that the physical infrastructure is still important.  One failing switch can bring down hundreds of servers and virtual machines.  Unfortunately, maintaining documentation about what’s connected to what is time consuming and almost certainly out of date within days.  That’s why FireScope has the capability to scan your network and use nearest neighbor to map the network topology of any environment.  Configuration is easy, simply define a topology discovery scan by going to Configuration > Topology Discovery and provide a starting IP, network constraints and a frequency for how often FireScope should rescan to update the map.  Once the first scan is completed, go to Service Management > Network > Topology to access your maps, or add them to your custom dashboards.

From each network topology map, you can drill down from your routers and switches to the networks they support or view the individual ports identified by discovery, with lots of rich information conveyed along the way.  In either case, from here you can drill down to the connected servers and other network devices, and even drill into their health and performance without leaving the topology map.  This makes it easy to quickly identify what assets and services are impacted by physical failures, or to visualize the load across the network.

As an added bonus, the network topology capability also generates a handy port visualizer.  From here, administrators can explore the load and error rate of the individual ports on a switch or router.

 

Virtualization Topology

Virtualization offers a challenge with regard to mapping topology due to its constant state of change.  Using VMware’s engineering APIs, FireScope starts at the vCenter or vCloud and maps the physical hosts and virtual machines associated.  But wait, there’s more! (Sorry, couldn’t resist)  The discovery also maps out virtual data stores, virtual networks and down to the vSwitch and vNic level.  And using the same HTML5 visualization capabilities, users can quickly explore their environment and drill into performance and health details for any asset.  Once again, configuration is easy.  First provide credentials for your VMware environment, then go to Configuration > Discovery > Virtual Discovery and complete four fields and FireScope does the rest automatically.

  


Storage Topology

There are numerous storage management solutions that can leverage NetApp’s, EMC’s and other storage vendors’ APIs to map out the physical filers and controllers and their associated vfilers, LUNs and volumes.  But we felt there was an aspect to storage topology that’s been lacking.  What about the servers and vms that have mounted volumes on storage arrays?  Furthermore, how can we communicate these mount points in a useful way, since storage labels these mount points differently than on the OS side.

This required a dual-pronged approach to storage mapping.  On the storage side, Storage discovery is configured very similarly to VMware discovery by going to Configuration > Discovery > Storage Discovery.  This capability can connect with DFM or the filers directly to discovery their configuration.  On the server side, FireScope agents have been modified to identify mount points, and the central FireScope Stratis cloud correlates these two sets of data to connect the dots between a volume and the servers utilizing it.  Nothing has to be done in terms of configuration to get this to work, its just automatically done behind the scenes.

From an operational perspective, this enables administrators to quickly see which IT services have been impacted by a storage failure, identify volumes that can be reclaimed due to projects ending, and plan major projects in a way that minimizes impact on user experiences.

As an added bonus, FireScope also does some trend analysis for each volume to predict, at current rate of growth, how many days you have until the volume is full.  Events can be defined against this to provide proactive notifications to help avoid application issues caused by a lack of capacity (e.g. Exchange server logs are notorious for consuming free space and bringing the entire service down when the last byte has been written).

 

While there are tools out there that provide some of these topology mapping capabilities, what makes FireScope particularly powerful is that all four are part of a single solution.  This enables data collected from each to be married in complex event analysis, better dependency mapping to prevent event storms and a whole host of capabilities.  The only limit is your imagination.