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

Asset ID: 1-71-1008962.1
Update Date:2010-04-19
Keywords:

Solution Type  Technical Instruction Sure

Solution  1008962.1 :   Sun StorageTek[TM] 99XX :Clearing Orphaned Persistent Group Reservations.  


Related Items
  • Sun Storage 9970 System
  •  
  • Sun Storage 9910 System
  •  
Related Categories
  • GCS>Sun Microsystems>Storage - Disk>Datacenter Disk
  •  

PreviouslyPublishedAs
212368


Description
This document identifies a method for identifying and clearing SCSI-3 persistent group reservations that were not properly cleared ("orphaned" persistent group reservations).
Orphaned persistent group reservations typically occur when a cluster is taken out of service without clearing reservations first.  They can be difficult to clear as they will normally survive even power cycling of the storage array.  They are persistent.


Steps to Follow
Occasionally a customer will disconnect a cluster from the SE9900 without first clearing any outstanding reservations.

If persistent group reservations were in use they will likely survive most attempts to clear them via port resets, power cycling the array, and deleting the parity group.

Typically this occurs when the cluster is shutdown and the last node leaves the reservation. The orphaned reservation occurs if the administrator fails to clear the reservation prior to removing this last host from the cluster (i.e. reinstall or physical detachment).

NOTE: If the administrator plans on removing a node from the cluster and it involves a shutdown of all nodes, they should follow technical instruction <Document: 1011961.1> prior to node removal as described above. This will prevent needing to use this document.

NOTE: SCSI-3 reservations are not limited to SE9900 arrays. This can occur on ANY disk storage device that supports the SCSI-3 protocol, which means that any storage vendor may show this problem.

If using HDLM (Hitachi Dynamic Link Manager), the dlmpr utility may be used to
attempt to clear the reservation. Note - this utility is not included in the
HDLM installation. It is an executable file located on the HDLM installation CD
in the DLMTools directory (i.e. e:\DLMTools\dlmpr.exe)

Display the HDLM managed paths and their persistent reserve information:

  1. dlmpr -d

Clear the persistent reserve information interactively:

  1. dlmpr - c

The above displays a list of the paths for HDLM managed LUs and persistent
reserve information. Clear the persistent reserve specifying the path ID.



Product
Sun StorageTek 9980 System
Sun StorageTek 9970 System
Sun StorageTek 9960 System
Sun StorageTek 9910 System

Internal Comments
For the internal use of Sun Employee's.

The procedure below is necessary only if the reservations can not be scrubbed using the methods detailed in troubleshooting document <Document: 1011076.1>.


There is a set of utilities, used for testing clusters, that can be used to determine if a reserve is orphaned. The utilities are part of the SCATE package and the first step is to get copies of the following utilities from the package.


do_mhiocgrp_inkeys

do_mhiocgrp_inresv

do_mhiocgrp_register

do_mhiocgrp_preemptandabort

do_mhiocgrp_clear


1. Check for any inkeys:


do_mhiocgrp_inkeys /dev/rdsk/cxxxxxxxx
No keys are expected to show.

2. Determine what key was used in the original reserve:


do_mhiocgrp_inresv /dev/rdsk/cxxxxxxxx
One reservation is expected to show

Example output:


># ./do_mhiocgrp_inresv /dev/rdsk/c9t50060E8003760D10d0s2

>File do_mhiocgrp_inresv.c, line 151 : ioctl() MHIOCGRP_INRESV on >/dev/rd

sk/c9t50060E8003760D10d0s2 succeeded: return value = 0

>Number of reservation key = 1

>Key: index = 0, value = 10001, type = 5, scope = 0, scope_addr = 0


3. Register a new inkey:


do_mhiocgrp_register -n 2222 /dev/rdsk/cxxxxxxxx
Registers the key 2222

4. Use preemptandabort to replace the previous inkey with the new.


do_mhiocgrp_preemptandabort -r 2222 -v <VALUE> /dev/rdsk/cxxxxxxxx

preempts the previous key <VALUE> and reserves LUN for key 2222


Note: This <VALUE> comes from output of inresv. The value=10001 in the example above.


5. Clear the reservation and keys:


do_mhiocgrp_clear /dev/rdsk/cxxxxxxxx
clears reservation and keys

The above procedure should be performed ONLY by System Support Engineers at the local or regional level.


This requires an escalation to the PTS-CLUSTER group to get the SCATE package (specifically SUNWtscsi) to release to the onsite engineer. The package is to be used for this purpose only, and removed after completion.


Alternatively, SCATE Software can be request through,


email: [email protected] for approval with the following details:

1. Name

2. Organization

3. Intended use of SCATE

-- Ongoing QA testing

-- Specific customer request

-- Field quals

Note: You must agree not to share SCATE software with any other party. You must also agree not to use SCATE software against any competitor clustering product.


reserve, reservation, scsi3 pgr, pgr
Previously Published As
74251

Change History
Date: 2010-04-16
User Name: eh47940
Action: Modify Tittle.

Version: 7
Date: 2006-10-26
User Name: 7058
Action: Modify Creator
Comment: Original author left Sun. - Admin Modify of Creator to Richard Ostberg (116819)
Version: 0
Product_uuid
2a918ae2-0a18-11d6-834a-c679537eebe7 | Sun StorageTek 9910 System
2a94fb3c-0a18-11d6-90a8-c9c08656284f | Sun StorageTek 9960 System
4ea4b951-9fc9-4f1f-b64e-69572a400fb4 | Sun StorageTek 9970 System


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