![]() | Sun System Handbook - ISO 4.1 October 2012 Internal/Partner Edition | ||
|
|
![]() |
||||||||||||
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
PreviouslyPublishedAs 205870
Applies to:Sun Storage 6130 ArraySun 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*** GoalSun 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. SolutionBefore 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 "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 |
||||||||||||
|