This demo showcases the ability to manage health, performance and capacity of a modern Software Defined Datacenter (SDDC) using vRealize Operations Manager. It contains individual demo sections covering the vROps management pack solutions listed below:

• Management Pack for Storage Devices (MPSD)
• Management Pack for Network Devices (MPND)
• NSX-vSphere Management Pack (includes MPND)
• vCloud Air Management Pack

To access the sections use the menu on the left, or click on the appropriate steps.

The Management pack for Network Devices (MPND) provides visibility and analysis of the pyhysical network infrastructure in your vSphere environment. Using discovery protocols such as LLDP or CDP, MPND can detect leaf switches connected to vSphere hosts as well as upstream spine switches connected to the leafs.

The topology tree on the left shows parent / child relationships of physical switches, hosts and distributed switches along with their health status. Active alerts are displayed at the top of the middle column. The topology graph on the far right renders the physical map of resources connected to objects selected in the Network Device Overview tree. Scrolling to the bottom of this dashboard reveals additional metrics for the selected object as well as other network traffic information.

The physical network path between the two hosts is rendered in the Path widget. Any displayed item or interface can be hovered over to get property and health information.

MPND is a powerful tool for mapping out the physical network devices in the SDDC and displaying the connectivity chain up through leaf and spine switches. MPND plays a key part in the correlation of logical networks to physical network devices, which we will explore further in the NSX portion of this demo.

(End of this section)

The Management Pack for Storage Devices (MPSD) provides insight and troubleshooting tools for managing traditional datacenter storage fabrics such as Fibre Channel, ISCS and NFS. MPSD also provides deep analysis into Virtual SAN environments which is covered in a separate section.

In this section we will briefly look at a Fibre Channel fabric and its associated components, then dive deeper into a NFS storage environment. Start by selecting a host object in the topology tree, taking note as the other dashboard widgets display data related to the selected host.

As we scroll down we see components in the topology tree that make up the Fibre Channel storage fabric. Host w2-mgmtpm-1 is currently selected, so its child components are highlighted in the tree. Storage throughput statistics for the host are displayed in the metric charts on the right.

The bottom section of the topology tree shows the fibre channel swich ports, array target ports and storage array mounts which are child resources of the currently selected host. The tree provides a correlation and relationship chain of the fibre channel fabric components to which this host is directly related.

In each of the MPSD dashboard groups, notice the same 3 dashboard types are available for each storage protocol - Component Heatmap, Component Usage, and general Troubleshooting.

In the NFS Volume Throughput and Latency heatmap, the box sizes are determined by the amount of current throughput. The bigger the box, the more throughput the volume is experiencing relative to the other volumes in the map. The color red indicates latency is high at the moment, while the sparkline shows the latency spike for this volume began relatively recently.

At the summary tab for this NFS volume we see that even though the heatmap indicated high throughput and latency compared to the other volumes, there are no immediate health, risk or efficiency issues with the volume.

Note that current throughput is just under 75 MBps vs. the historical max of 200 MBps. Even though the heatmap showed this volume was working harder than the other NFS volumes, it is still well under max throughput capabilities.

Similar to what we observed in the FC Troubleshooting dashboard, here we see the familiar topology tree plus other widgets showing active Issues and Alerts for our NFS storage fabric.

As we scroll down the topology tree we see NFS storage fabric components highlighted that are directly related to the selected host. The dark green EsxPnics are child resources of the host, as are the darker IP switchports to which the Pnics are connected. The metric charts on the right reflect storage throughput statistics for the selected host.

At the very bottom of the topology tree we see a highlighted NFS volume that is mounted by this host. Notice there is nothing highlighted at the IPSwitch, NFS Server and Storage Array levels. That is because none of those objects are direct child resouces of a host. Highlighted items in the topology tree only reflect direct parent and child related resources of the selected object.

The virtual machines listed on the left all have VMDKs on this datastore. If the datastore was experiencing critical issues, the VMs listed would potentially be negatively impacted.

Let's dig a little deeper to see if we can tell how long this datastore has been running hot.

In the 'Info' column, we see that several values are above historical maximums or defined thresholds. The time bars show when the anomalies began to appear. The first latency spike was around 10:38am, then a more sustained peak began at 11:08am. This information can assist in correlating other anomalous behavior that showed up in the environment around the same time.

Expanding the Disk Space item gives us a more detailed view of the Usage and Allocation details. This provides a better sense of whether disk space usage is truly being exhausted, or rather that we've been overallocating the storage on this datastore. Note this volume has 30% of its capacity currently being consumed, but 40% of the capacity has been allocated.

This dashboard provides a detailed look at throughput, latency and errors for each individual NFS storage component including the EsxPnics, IP switchports, and NFS volumes.

In the lower middle chart, notice that the latency for 'ntp_east_sata_1000_01_nfs' is very high compared to the other NFS volumes. What we can't tell is how long this condition has existed. The default chart setting is to display statistics from the last hour. Let's see how the volumes compare over the last week.

Here we see a different picture. During the last 7 days, the latency for 'ntp_east_sata_1000_01_nfs' was much lower (8.46 ms compared to 160.17 during the last hour), and the latency relativity amongst the other volumes was more balanced. To confirm, let's go back to look at the stats for the last hour.

We clearly see there is higher relative latency for this volume compared to the others during the last hour, however it has not been a chronic issue over the last 7 days. The previous dashboards indicated that although the volume is working hard, it is experiencing no immediate health, risk, or efficiency issues that require further investigation. If any of the virtual machines we saw on the datastore relationship list happen to be experiencing performance issues, we can confidently rule out the NFS fabric and volume as the culprit based on the MPSD data.

This section of the MPSD demo will focus on Virtual SAN storage environments. We will look at troubleshooting VSAN alerts and also analyze VSAN performance and capacity information.

Notice there are several active alerts in the environment. We will drill into the first VSAN alert.

The alert indicates there are VSAN components for this VM that are not in an active state on disk. The Device Description indicates the inactive components are on host w2-sm-c3b1. The Recommendations text suggests the host may be unavailable.

Return to the Home screen to look for correlating issues.

Host w2-sm-c3b1 is disconnected from vCenter. This is the same host which held the VSAN missing disk objects for the LiveAuction App2 VM that we were investigating. Reconnect the host to vCenter to restore the missing VSAN objects.

Scrolling down allows us to see the other items in the topology tree along with metric charts. The topology items in dark green are direct child resources of the selected host. The metric charts are showing throughput statistics for the host.

Let's change the dashboard context to a SSD.

This heatmap shows throughput and workload for host storage controllers in the VSAN environment. The boxes are sized by the amount of throughput, while the color is driven by the workload %. Red indicates a high workload. The sparkline for this host controller indicates this is a recent workload spike on host w2-sm-c3b4. Let's get more detail.

In Workload Breakdown note the highest observed throughput previously seen on this controller was about 278 MBps. The current throughput is running about 271 MBps which is approachng 98% of the max observed capacity. That doesn't mean there is a problem - it simply means the controller is working hard. Most likely the VSAN cluster is attempting to create another copy of the missing VM components caused by one of the VSAN hosts going offline.

At the bottom of the dashboard are the throughput and latency charts for the magnetic spinning disks in the VSAN environment. We can drill into any items in these charts to further analyze workload imbalance or higher than expected latency numbers.

The previous dashboard displayed entity usage information from the perspective of throughput and latency. The Device Insights dashboard is focused on capacity and error information. The top row refers to the magnetic disks - how much capacity has been consumed on each disk, and whether a disk has errors or reallocated sectors. The middle row focuses on the SSDs - cache hit rate, wearout indicators and SSD errors.

The bottom section of the dashboard has CPU and Memory consumption information for the VSAN hosts. There is also a widget for listing IP switchport errors. Use this dashboard to identify VSAN devices that are approaching capacity limits or throwing an abnormal amount of errors compared to other VSAN devices.

The remaining VSAN dashboard displays statistics from the perspective of the entire VSAN cluster vs. individual components. These four charts show Disk Group consumption, latency and errors. The default time range for the data being displayed is the previous hour. However we can modity the range to a value of our choosing.

The four charts at the bottom of the dashboard reflect capacity, throughput and latency from the perpective of the VSAN datastore. There is also a chart indicating VSAN component counts for each host in the cluster. Use this dashboard to analyze performance and capacity of the VSAN disk groups and datastore as opposed to the VSAN devices and individual components shown in the previous dashboards.

This section of the demo will focus on management of vCloud Air resources and workloads.

Similar to other SDDC management packs, the vCA Troubleshooting dashboard offers a topology tree to display the relationship chain of all the objects in the environment. Clicking on an item in the tree will highlight the corresponding parent and child resources related to the selected object. The Interesting Metrics chart will change to display statistics for the selected object.

The Troubleshooting dashboard is the place to start if vCA workloads or resources are experiencing problems. At a quick glance we will see items that have degraded health status, or open alerts and events, and can drill into either for further investigation.

Let's move to the next dashboard to see capacity usage information.

The heatmaps dashboard enables us to quickly see which VMs are the highest resource consumers in four separate categories - CPU, Memory, Disk and Network. The CPU and Memory heatmaps have multiple selections for grouping the VMs. Clicking on items in the heatmaps will display the history of their resource consumption in the charts below the heatmaps of each respective resource category.

Notice the historical graph of CPU Usage % for the two selected VMs in the CPU Load History chart below the heatmap. We can also change the heatmap to show CPU Ready % for the workload VMs by choosing that category in the Configurations drop down list.

The Edge Services dashboard provides a single view into the status and performance of all services running on Edge devices in your vCloud environment. The vCloud Air management pack provides a comprehensive view into your cloud performance, capacity and resource consumption. It also helps quickly identify issues and offers recommendations for resolution.

This section of the SDDC demo will focus on NSX for vSphere components in the SDDC. The NSX-vSphere management pack also contains the Management Pack for Network Devices (MPND) to aid in the correlation of physical to logical network constructs. However, MPND has no requirement for NSX, and can be run independently as a standalone vROps management pack. MPND is covered in a separate section of this demo.

The NSX Main dashboard displays several operational aspects of virtualized networks including overall health, performance and availability. We can select between multiple NSX environments from this single dashboard by choosing the desired NSX implementation in the Environments widget.

The dashboard has rendered the logical and physical topology underpinning the selected NSX Logical Switch. On the left we see the logical switch in the center, the VMs connected to the switch, and the upstream NSX Logical Router. On the right we see the physical hosts, network interfaces, switch interfaces, and the leaf and spine switches this Logical Switch is using for communication. At the bottom of the dashboard are alert lists and metric charts for the selected object.

The logical router 'univ-dlr-1' has not been configured to use the MD5 authentication protocol, hence the triggered alert. Expanding the 'OSPF is enabled...' symptom shows the date and time when OSPF was enabled on the logical router (3/17/16 at 1:53pm). The recommendation is to use MD5 authentication for all OSPF areas.

Selecting the NSX Manager East reveals related Health, Risk and Efficiency alerts as well as three associated Controllers as child resources. We could select any of the sub-tabs on the right, i.e. Alerts, Analysis, Troubleshooting, etc., for further information on nsx-mgr-east. Notice the Risk alert indicating less than 3 controllers are active. Clicking on the alert would identify which controller is offline.

Next let's look at the other NSX inventory trees.

Selecting the NAT service for this edge device reveals an open alert indicating NAT rules with no destination. We could click that alert to identify the rules in question, but for this demo let's switch to the Analysis tab and look at Capacity information.

Moving to the Faults tab for the VPN service we quickly see that the L2 VPN tunnel is down.

The inventory trees are useful for viewing performance, alerts and capacity for all NSX components and services.

As mentioned at the beginning, the Management Pack for Network Devices (MPND) is included in the NSX-vSphere management pack. MPND discovers and maps the physical network infrastructure underpinning the virtualized environment. It also installs an inventory tree which enables analysis of the physical infrastructure of switches and ports.

In summary, the NSX-vSphere management pack provides comprehensive physical to virtual network correlation, troubleshooting, configuration assurance and capacity modeling for NSX environments. It is a Must Have tool for every NSX implementation!

(End of this section)