Help

Table Of Contents
Check for bandwidth or IOPS over-provisioned metro node front-end ports. Be sure to balance hosts and LUNs across
the available directors and front-end ports presented from metro node. Check the front-end fabric for saturation or over-
capacity.
Verify that front-end Fibre Channel ports, HBAs, and switch ports are configured to the proper port speeds.
For your host multipathing software, configure them based on metro node best practices, and make sure the installed
software versions are compatible with metro node (see the Simple Support Matrix for metro node document, available on
Dell EMC Online Support.)
Corrective actions (metro node Metro only)
For metro node Metro configurations, check the inter-cluster link health and maximum performance capabilities. From the
metro node Management GUI, check the observed inter-cluster WAN bandwidth. If your application throughput appears low
to you, and only seems to achieve something similar to what the WAN bandwidth reports, then chances are you are limited
by the WAN. Therefore:
Ensure you have provisioned enough inter-cluster bandwidth for the desired application workload. Verify that your WAN
configuration is supported by metro node (minimum supported bandwidth, supported inter-cluster latency, compatible
WAN hardware and software).
If using Fibre Channel devices over dark fibre or DWDM, confirm that you have allocated enough buffer credits or
configured the Fibre Channel WAN ports properly on your switches. Check for buffer credit starvation, c3 discards, and
CRC errors. Some vendors may require extended fabric licenses to enable WAN features.
Validate your WAN performance before going live in production. Create multiple test distributed-devices and force them
to rebuild. Observe the performance of the rebuilds.
When troubleshooting distributed device performance, if feasible, check local device performance. Export a test LUN
from your storage array to metro node, then to the host, and then run a test I/O workload.
Check for any unexpected local or distributed rebuilds or data migrations. There will be some amount of performance
impact to host application traffic that relies on the same virtual volumes and storage volumes. Tune the rebuild transfer-
size setting using the CLI to limit rebuild/migration performance impact. Consider scheduling migrations during off-peak
hours.
Changing the view
Use the following appropriate selection criteria to filter the data:
Director Allows you to select all directors or a specific director in the cluster.
Read and Write check boxes Allows you to select one or both check boxes to filter bandwidth for Reads and Writes.
Viewing the Front-end Bandwidth chart
1. From the GUI main menu, click Performance.
2. In the Performance Dashboard, select the tab in which you want to display the Front-end Bandwidth chart (or create a
custom tab).
3. Click +Add Content.
4. Click the Front-end Bandwidth icon.
Front-end Latency chart
The Front-end Latency chart on the Performance Dashboard provides details of the front-end I/O latency statistics for your
metro node system.
Front-end latency is defined as the amount of time an I/O spends within metro node. The reported metro node front-end
latency should match closely to the host or application reported latency, unless there is significant added delay in the front-end
fabric, HBA, multi-pathing software, or host operating system software.
It is important to distinguish how front-end latency write operations behave in the two metro node configurations:
For metro node Local write operations, it includes the time spent protecting the disk blocks to one or more local storage-
arrays.
For metro node Metro write operations, it includes the time spent protecting the disk blocks to the storage-array at BOTH
clusters. When writing to the remote cluster, the round-trip time on the WAN links adds to the front-end latency, depending
upon the observed network delay between clusters.
40
Monitoring the system