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
CVM communication
CVM communication involves various GAB ports for different types of communication. For an illustration of these ports:
See Figure: Low-level communication.
CVM communication involves the following GAB ports:
Port w
Most CVM communication uses port w for vxconfigd communications. During any change in volume configuration, such as volume creation, plex attachment or detachment, and volume resizing, vxconfigd on the master node uses port w to share this information with slave nodes.
When all slaves use port w to acknowledge the new configuration as the next active configuration, the master updates this record to the disk headers in the VxVM private region for the disk group as the next configuration.
Port m
CVM uses port m for SmartIO VxVM cache coherency using Group Lock Manager (GLM).
Port v
CVM uses port v for kernel-to-kernel communication. During specific configuration events, certain actions require coordination across all nodes. An example of synchronizing events is a resize operation. CVM must ensure all nodes see the new or old size, but never a mix of size among members.
CVM also uses this port to obtain cluster membership from GAB and determine the status of other CVM members in the cluster.
Port u
CVM uses the group atomic broadcast (GAB) port u to ship the commands from the slave node to the master node.
Port y
CVM uses port y for kernel-to-kernel communication required while shipping I/Os from nodes that might have lost local access to storage to other nodes in the cluster.