InfoScale™ 9.0 Cluster Server Administrator's Guide - Windows
- Section I. Clustering concepts and terminology
- Introducing Cluster Server
- About Cluster Server
- About cluster control guidelines
- About the physical components of VCS
- Logical components of VCS
- Types of service groups
- Agent classifications
- About cluster control, communications, and membership
- About security services
- About cluster topologies
- VCS configuration concepts
- Introducing Cluster Server
- Section II. Administration - Putting VCS to work
- About the VCS user privilege model
- Getting started with VCS
- Administering the cluster from the command line
- About administering VCS from the command line
- Stopping the VCS engine and related processes
- About managing VCS configuration files
- About managing VCS users from the command line
- About querying VCS
- About administering service groups
- Modifying service group attributes
- About administering resources
- About administering resource types
- About administering clusters
- Configuring resources and applications in VCS
- About configuring resources and applications
- About Virtual Business Services
- About Intelligent Resource Monitoring (IMF)
- About fast failover
- How VCS monitors storage components
- About storage configuration
- About configuring network resources
- About configuring file shares
- About configuring IIS sites
- About configuring services
- Before you configure a service using the GenericService agent
- About configuring processes
- About configuring Microsoft Message Queuing (MSMQ)
- About configuring the infrastructure and support agents
- About configuring applications using the Application Configuration Wizard
- Adding resources to a service group
- About application monitoring on single-node clusters
- Configuring the service group in a non-shared storage environment
- About the VCS Application Manager utility
- About testing resource failover using virtual fire drills
- Modifying the cluster configuration
- Section III. Administration - Beyond the basics
- Controlling VCS behavior
- VCS behavior on resource faults
- About controlling VCS behavior at the service group level
- Customized behavior diagrams
- VCS behavior for resources that support the intentional offline functionality
- About controlling VCS behavior at the resource level
- Service group workload management
- Sample configurations depicting workload management
- The role of service group dependencies
- VCS event notification
- VCS event triggers
- List of event triggers
- Controlling VCS behavior
- Section IV. Cluster configurations for disaster recovery
- Connecting clusters–Creating global clusters
- VCS global clusters: The building blocks
- About global cluster management
- About serialization - The Authority attribute
- Prerequisites for global clusters
- Setting up a global cluster
- Configuring replication resources in VCS
- About IPv6 support with global clusters
- About cluster faults
- About setting up a disaster recovery fire drill
- Test scenario for a multi-tiered environment
- Administering global clusters from Cluster Manager (Java console)
- Administering global clusters from the command line
- About global querying in a global cluster setup
- Administering clusters in global cluster setup
- Setting up replicated data clusters
- Connecting clusters–Creating global clusters
- Section V. Troubleshooting and performance
- VCS performance considerations
- How cluster components affect performance
- How cluster operations affect performance
- VCS performance consideration when a system panics
- VCS agent statistics
- Troubleshooting and recovery for VCS
- VCS message logging
- Handling network failure
- Troubleshooting VCS startup
- Troubleshooting service groups
- Troubleshooting and recovery for global clusters
- VCS utilities
- VCS performance considerations
- Section VI. Appendixes
- Appendix A. VCS user privileges—administration matrices
- Appendix B. Cluster and system states
- Appendix C. VCS attributes
- Appendix D. Configuring LLT over UDP
- Appendix E. Handling concurrency violation in any-to-any configurations
- Appendix F. Accessibility and VCS
- Appendix G. Executive Order logging
Seeding of VCS clusters
To protect your cluster from a pre-existing network partition, VCS employs the concept of a seed. Nodes can be seeded automatically or manually. Only those nodes that have been seeded can run VCS.
By default, when a node comes up, it is not seeded. When the last node in a cluster is booted, the cluster will seed and start VCS on all the nodes. Nodes can then be brought down and restarted in any combination. Seeding is automatic as long as at least one instance of VCS is running in the cluster.
Nodes are seeded automatically in one of the following ways:
When an unseeded node communicates with a seeded node
When all the nodes in the cluster are unseeded but able to communicate with each other
VCS requires that you declare the number of nodes that will participate in the cluster. Before VCS can accept HA commands, the cluster nodes must be seeded. If the nodes are not seeded and you attempt to issue a command, VCS returns the following error:
VCS:11037:Node has not received cluster membership yet, cannot process HA command
The number of nodes participating in a cluster could change. A possible scenario is that one or more nodes are down for maintenance when the cluster comes up. In this scenario, the cluster does not seed automatically and therefore VCS does not start successfully. To overcome this issue, you can manually seed the cluster with the currently available nodes.
Before manually seeding the cluster, make sure of the following:
The nodes participating in the cluster are able to send and receive heartbeats to each other.
There is no possibility of a network partition condition in the cluster.
Warning:
Arctera recommends that you do not seed the cluster manually, unless you are aware of the associated risks and implications.
To manually seed a cluster
- Run the following command from only one of the operational nodes:
gabconfig -x
This command seeds all the nodes that communicate with the node on which you run this command.
Note:
This seeding is not persistent. If you restart the operational cluster nodes, you will need to rerun this command.
You can also seed a cluster by updating the %VCS_ROOT%\comms\gab\gabtab.txt
file. By default, VCS records the total number of nodes in the cluster in this file. If the number of nodes that actually participate in the cluster is lower, modify gabtab.txt
manually.
To manually seed a cluster and make the changes persistent
- Determine the number of nodes that are operational in the cluster.
- For each cluster node, modify the following line in
gabtab.txt
:gabconfig -c -n numberOfNodes
Set numberOfNodes to the number of currently operational nodes.
When you save
gabtab.txt
, these changes are made persistent. However, for this change to take effect, you need to perform the next step. To seed the cluster without any application down time, do one of the following:
Run the following command on any one operational node:
gabconfig -x
Restart the VCS communication stack by running the following commands sequentially on each operational node:
taskkill /f /im hashadow.exe taskkill /f /im had.exe
Ensure that the hashadow and had processes are killed. Then, proceed with the following commands:
net stop vcscomm net stop gab net stop llt
Finally, run the following command on any one operational node:
hastart -all
If some application down time is acceptable, reboot each operational node individually so that the changes to
gabtab.txt
take effect.