Dell EMC Metro node 7.0.1 Online Help

Guidelines

• The desired level of bandwidth performance depends heavily on the host applications and their requested load. Therefore, it is not possible to provide a threshold of good or bad bandwidth performance.
• Metro node front-end performance depends heavily on the available back-end storage array performance, and in metro node Metro configurations, the WAN performance for distributed devices.
• There is no absolute recommendation on what is good or bad for IOPS and KB/s. It is typically what the application requests of the volume.
• If values for these metrics are unsatisfactory, be aware of resource bottlenecks.
• Any running distributed rebuilds or data migrations might negatively affect available host bandwidth.
• Since the metro node Local and Metro implement write through caching, a small amount of write latency overhead (typically <1msec) is expected. This latency may affect applications that serialize their I/O and do not take advantage of multiple outstanding operations. These types of applications may see a throughput and IOPS drop with metro node in the data path.
• In a metro node Metro you will incur extra WAN round-trip time on your write latency since writes need to be successfully written to both cluster's storage before the host is acknowledged. This extra latency may impact the throughput and IOPS of serialized-type applications.

Corrective actions

• Check for bandwidth/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.
• Check CPU utilization. If unusually busy, metro node will be limited in the amount of bandwidth it can provide.
• Check back-end latency. If on average the back-end latency is large, or there are large spikes, there could be a poorly performing back-end fabric or an unhealthy, un-optimized, or over-loaded storage array. Perform a back-end fabric analysis and a performance analysis of all storage arrays in question.
• Check front-end aborts. Their presence indicate that metro node is taking too long to respond to the host. These might indicate problems with the front-end fabric or slow SCSI reservations.
• Check back-end errors. If the metro node back-end is required to retry an operation because of errors, then this will add to the delay in completing the operation to the host.
• Check front-end operations count (queue depth). If this counter is large, this may explain larger than normal front-end latency.
• Check for high metro node write delta time. Refer to the Corrective actions section in the Write Latency Delta chart topic.
• Check the front-end average iosize. For writes, iosizes larger than 128KB become serialized into 128KB requests. This can extend the time to complete large block transfers, or in extreme examples, cause the operation to timeout and fail.
• Verify that front-end Fibre Channel ports, HBAs and switch ports are configured to the correct port speeds.
• Configure your host multipathing software based on metro node best practices, and ensure the installed software versions are compatible with metro node. For more information on compatibility, refer to the Simple Support Matrix for metro node document, available on EMC Online Support and in the SolVe Desktop.

For metro node Metro configurations

• Check the health of the inter-cluster link and maximum performance capabilities. From the GUI, check the inter-cluster WAN bandwidth. If your application throughput appears low and is similar to what the WAN bandwidth reports, then you are probably limited by the WAN. In this case:
  • Make sure 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).
  • For Metro-FC, if the inter-cluster WAN is over a FC fabric, confirm that you have allocated enough buffer credits or configured the FC 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 run a test I/O workload.
• Check for any unexpected local or distributed rebuilds or data migrations. There will be some performance impact to host application traffic that relies on the same virtual volumes and storage volumes. Tune the rebuild transfer-size setting to limit the performance impact of rebuild and migrations. Consider scheduling migrations during off-peak hours.

Changing the view

To view the bandwidth of a single director in your metro node system, select the director name from the Director drop-down.

Viewing the Virtual Volume Bandwidth chart

1. From the GUI main menu, click Performance.
2. Click + and select Add Virtual Volumes Dashboard.