Analyzing a performance event on a cluster in a MetroCluster configuration

You can use Unified Manager to analyze the cluster in a MetroCluster configuration on which a performance event was detected. You can identify the cluster name, event detection time, and the bully and victim workloads involved.

Before you begin

Steps

  1. Display the Dynamic Threshold Event Details page to view information about the event.
  2. Review the event description to see the names of the workloads involved and the number of workloads involved.
    Example

    In this example, the MetroCluster Resources icon is red, indicating that the MetroCluster resources are in contention. You position your cursor over the icon to display a description of the icon. At the top of the page in the event ID, the cluster name identifies the name of the cluster on which the event was detected.


    Summary of performance event for MetroCluster configuration

  3. Make a note of the cluster name and the event detection time, which you can use to analyze performance events on the partner cluster.
  4. In the Workload Details table, review the victim workloads to confirm that their response times are higher than the performance threshold.
    Example

    In this example, the victim workloads are displayed at the top of the table. The Latency charts display, at a high-level, a consistent latency pattern for the victim workloads involved. Even though the abnormal latency of the victim workloads triggered the event, a consistent latency pattern might indicate that the workloads are performing within their expected range, but that a spike in I/O increased the latency and triggered the event. By default, the workloads are sorted by victims.


    Victim workloads in performance event for MetroCluster configuration

    If you recently installed an application on a client that accesses these volume workloads and that application sends a high amount of I/O to them, you might be anticipating their latencies to increase. If the latency for the workloads returns within the expected range, the event state changes to obsolete, and remains in this state for more than 30 minutes, you can probably ignore the event. If the event is ongoing, and remains in the new state, you can investigate it further to determine whether other issues caused the event.

  5. In the Workload Details table, select Bullies - Peak Deviation in Write MBps to display the bully workloads at the top of the table.
    Example

    In this example, one bully workload is displayed at the top of the table. The presence of bully workloads indicates that the event might have been caused by one or more workloads on the local cluster overutilizing the MetroCluster resources. The bully workloads have a high deviation in write throughput (MBps).


    Workload Details table listing bully workloads involved in MetroCluster configuration event

    The Total Write MBps charts display, at a high-level, the write throughput (MBps) pattern for the workloads. You can review the write MBps pattern to identify abnormal throughput, which might indicate that a workload is over-utilizing the MetroCluster resources.

    If no bully workloads are involved in the event, the event might have been caused by a health issue with the link between the clusters or a performance issue on the partner cluster. You can use Unified Manager to check the health of both clusters in a MetroCluster configuration. You can also use Unified Manager to check for and analyze performance events on the partner cluster.