Storage Foundation for Sybase ASE CE 7.4 Administrator's Guide - Linux
- Overview of Storage Foundation for Sybase ASE CE
- About Storage Foundation for Sybase ASE CE
- About SF Sybase CE components
- About optional features in SF Sybase CE
- Administering SF Sybase CE and its components
- Administering SF Sybase CE
- Starting or stopping SF Sybase CE on each node
- Administering VCS
- Administering I/O fencing
- About the vxfentsthdw utility
- Testing the coordinator disk group using the -c option of vxfentsthdw
- About the vxfenadm utility
- About the vxfenclearpre utility
- About the vxfenswap utility
- Administering CVM
- Changing the CVM master manually
- Administering CFS
- Administering the Sybase agent
- Administering SF Sybase CE
- Troubleshooting SF Sybase CE
- About troubleshooting SF Sybase CE
- Troubleshooting I/O fencing
- Fencing startup reports preexisting split-brain
- Troubleshooting Cluster Volume Manager in SF Sybase CE clusters
- Troubleshooting interconnects
- Troubleshooting Sybase ASE CE
- Prevention and recovery strategies
- Prevention and recovery strategies
- Managing SCSI-3 PR keys in SF Sybase CE cluster
- Prevention and recovery strategies
- Tunable parameters
- Appendix A. Error messages
About the I/O fencing registration key format
The keys that the vxfen driver registers on the data disks and the coordinator disks consist of eight bytes. The key format is different for the coordinator disks and data disks.
The key format of the coordinator disks is as follows:
Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
Value | V | F | cID 0x | cID 0x | cID 0x | cID 0x | nID 0x | nID 0x |
where:
VF is the unique identifier that carves out a namespace for the keys (consumes two bytes)
cID 0x is the LLT cluster ID in hexadecimal (consumes four bytes)
nID 0x is the LLT node ID in hexadecimal (consumes two bytes)
The vxfen driver uses this key format in both sybase mode of I/O fencing.
The key format of the data disks that are configured as failover disk groups under VCS is as follows:
Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
Value | A+nID | V | C | S |
|
where nID is the LLT node ID
For example: If the node ID is 1, then the first byte has the value as B ('A' + 1 = B).
The key format of the data disks configured as parallel disk groups under Cluster Volume Manager (CVM) is as follows:
Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
Value | A+nID | P | G | R | DGcount | DGcount | DGcount | DGcount |
where DGcount is the count of disk groups in the configuration (consumes four bytes).
By default, CVM uses a unique fencing key for each disk group. However, some arrays have a restriction on the total number of unique keys that can be registered. In such cases, you can use the same_key_for_alldgs tunable parameter to change the default behavior. The default value of the parameter is off. If your configuration hits the storage array limit on total number of unique keys, you can change the value to on using the vxdefault command as follows:
# vxdefault set same_key_for_alldgs on # vxdefault list KEYWORD CURRENT-VALUE DEFAULT-VALUE ... same_key_for_alldgs on off ...
If the tunable is changed to on, all subsequent keys that the CVM generates on disk group imports or creates have '0000' as their last four bytes (DGcount is 0). You must deport and re-import all the disk groups that are already imported for the changed value of the same_key_for_alldgs tunable to take effect.