LUN Response time is usually my starting point for troubleshooting.  It gives a good indicator of what the host is experiencing.  Usually if your LUN response time (Response time = queue length * service time)is good, then usually the host isn't seeing issues.  High response times don't also mean that the CLARiiON is busy.  It can also indicate that you're having issues with your host or Fabric.

LUN Utilization % is not a good metric to use - It doesn't report accurately.  It tends to say utilization is higher than what it actually is.  It can also be deceptive, as it may say a LUN is 100% utilized when another LUN is causing your problem

64 ms is fairly high, but I don't think a 64ms spike would cause a failover.  That might just be an indicator of the host having issues.  The host could have been having issues and responding slow before it finally dies and initiates a failover, that would also drive LUN response time up (A write isn't a write until the host acknowledges it).  Also LUN response time would probably go up during the failover process.

At least half of your job managing storage is proving that the array/SAN is not the problem.  Provide graphs to people who don't believe you.  If you've laid everything out properly, then most likely it's a host issue (bad code, OS Problems, HBA Drivers, Bad HBA, etc)

Usually if I see high response times on a LUN, I check these things on the array

• How busy is the RAID Group/Disks
  
  • Check each disk in the RAID Group - If total throughput sustains around 180 IOPs for 15k FC (in a perfect world, really sustained should be less than 180 IOPS to give room for spikes - I start to get concerned when I see sustained over 120-130 for long periods of time), then you need more disks
    
  • Check RAID Group Utilization % - Not a terribly good indicator, but gives a decent ball park figure
    

• What else is happening with the LUNs in the same RAID Group
  
  • Check each LUN to see what they are doing, if you have a busy LUN, then move it to another RAID Group
    
  • Check each LUN for Reach/Write Size - If you have a LUN doing large reads or writes, possibly move it to another RAID Group.  Large reads usually mean sequential I/O and sequential reads on the same disks can hurt your random read performance on other LUNs.
    
  • Check average busy queue length.  This is a good indicator of how "bursty" a LUN is.
    

• Check the SPs - Check % Dirty Pages - make sure it isn't at 99%
  

• Other stuff - Sometimes I select every single LUN and look at response times, Read/Write/Total bandwidth, Read/Write/Total Throughput, etc (Not very pretty, but it helps me narrow down what's really busy - You can mouse over data to see what LUN you're looking at)  A poorly placed busy LUN can affect your entire array.
  

• Once I go though the CLARiiON, I'll start looking at switch statistics to look for buffer credit issues, I'll also look at the host for HBA/Driver/Cable issues.