Sun Microsystems, Inc.  Sun System Handbook - ISO 4.1 October 2012 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-71-1004246.1
Update Date:2012-04-04
Keywords:

Solution Type  Technical Instruction Sure

Solution  1004246.1 :   Sun StorageTek [TM] 2500/6000 Array: Change to VXVM DMP restore daemon required for an online firmware upgrade  


Related Items
  • Sun Storage 6540 Array
  •  
  • Sun Storage 6180 Array
  •  
  • Sun Storage 6580 Array
  •  
  • Sun Storage 6780 Array
  •  
  • Sun Storage 2510 Array
  •  
  • Sun Storage 2540 Array
  •  
  • Sun Storage 2540-M2 Array
  •  
  • Sun Storage 6130 Array
  •  
  • Sun Storage 6140 Array
  •  
  • Sun Storage 2530 Array
  •  
  • Sun Storage 2530-M2 Array
  •  
Related Categories
  • PLA-Support>Sun Systems>DISK>Arrays>SN-DK: 6130
  •  
  • .Old GCS Categories>Sun Microsystems>Storage - Disk>Modular Disk - 6xxx Arrays
  •  

PreviouslyPublishedAs
205870


Applies to:

Sun Storage 6130 Array
Sun Storage 6140 Array
Sun Storage 6540 Array
Sun Storage 6180 Array - Version: Not Applicable and later    [Release: N/A and later]
Sun Storage 6580 Array - Version: Not Applicable and later    [Release: N/A and later]
Oracle Solaris on SPARC (64-bit)
Oracle Solaris on x86-64 (64-bit)
OpenSolaris
***Checked for relevance on 04-Apr-2012***

Goal


Sun StorageTek [TM] 6000 and  Sun StorageTek [TM] 2500 arrays perform a controller firmware/NVSRAM upgrade by resetting only one controller at a time. This allows for an online firmware upgrade, as long as every host has multipathing configured and operational, because host access to data can be maintained using volume failovers.

However, when using Veritas Volume Manager (VXVM) Dynamic MultiPathing (DMP) as a host's multipathing solution there is a chance that the host could lose access to data during the controller firmware upgrade. This is because DMP uses a restore daemon which only periodically checks to see if a disabled path has become available again, and the default polling interval for this daemon is 300 seconds (5 minutes). If the daemon does not perform a check in the interval between the two controller resets, then the paths to the first controller won't be re-enabled before the paths to the second controller are disabled, resulting in all paths being disabled. Typically, the interval between the controller resets is much less than 5 minutes, e.g. 30 seconds.

Solution

Before performing a controller firmware and/or NVSRAM upgrade on an Sun StorageTek [TM] 6000 or Sun StorageTek [TM] 2500 array then the polling interval of the DMP restore daemon should be reduced to 20 seconds on every host which is using DMP for multipathing.

Example on a Solaris host :

Firstly, check the settings of the restore daemon, and determine it's current polling interval :

# vxdmpadm stat restored 

Next, stop the restore daemon :

# vxdmpadm stop restore

Then, restart the daemon with a polling interval of 20 seconds :

# vxdmpadm start restore interval=20 

Proceed with the firmware upgrade.

When the firmware upgrade has been completed, then the polling interval of the DMP restore daemon should be returned to it's original setting on every host.

Example on a Solaris host :

Firstly, stop the restore daemon :

# vxdmpadm stop restore

Then, restart the daemon with it's original polling interval, e.g. :

# vxdmpadm start restore interval=300

Based on information in the workaround for the following CR :

Bug ID: 6503902  
Synopsis: Texas Inst. needs a pause upgrading FW in arrays controllers on ST6140. Upgrade pause, upgrade

Also see the following Symantec support document :

"How to modify the DMP restore daemon on Solaris"
http://www.symantec.com/business/support/index?page=content&id=TECH26668


Attachments
This solution has no attachment
  Copyright © 2012 Sun Microsystems, Inc.  All rights reserved.
 Feedback