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
System states
Whenever the VCS engine is running on a system, it is in one of the states described in the table below. States indicate a system's current mode of operation. When the engine is started on a new system, it identifies the other systems available in the cluster and their states of operation. If a cluster system is in the state of RUNNING, the new system retrieves the configuration information from that system. Changes made to the configuration while it is being retrieved are applied to the new system before it enters the RUNNING state.
If no other systems are up and in the state of RUNNING or ADMIN_WAIT, and the new system has a configuration that is not invalid, the engine transitions to the state LOCAL_BUILD, and builds the configuration from disk. If the configuration is invalid, the system transitions to the state of STALE_ADMIN_WAIT.
Table: VCS system states provides a list of VCS system states and their descriptions.
Table: VCS system states
State | Definition |
---|---|
ADMIN_WAIT | The running configuration was lost. A system transitions into this state for the following reasons:
|
CURRENT_DISCOVER_WAIT | The system has joined the cluster and its configuration file is valid. The system is waiting for information from other systems before it determines how to transition to another state. |
CURRENT_PEER_WAIT | The system has a valid configuration file and another system is doing a build from disk (LOCAL_BUILD). When its peer finishes the build, this system transitions to the state REMOTE_BUILD. |
EXITING | The system is leaving the cluster. |
EXITED | The system has left the cluster. |
EXITING_FORCIBLY | An hastop -force command has forced the system to leave the cluster. |
FAULTED | The system has left the cluster unexpectedly. |
INITING | The system has joined the cluster. This is the initial state for all systems. |
LEAVING | The system is leaving the cluster gracefully. When the agents have been stopped, and when the current configuration is written to disk, the system transitions to EXITING. |
LOCAL_BUILD | The system is building the running configuration from the disk configuration. |
REMOTE_BUILD | The system is building a running configuration that it obtained from a peer in a RUNNING state. |
RUNNING | The system is an active member of the cluster. |
STALE_ADMIN_WAIT | The system has an invalid configuration and there is no other system in the state of RUNNING from which to retrieve a configuration. If a system with a valid configuration is started, that system enters the LOCAL_BUILD state. Systems in STALE_ADMIN_WAIT transition to STALE_PEER_WAIT. |
STALE_DISCOVER_WAIT | The system has joined the cluster with an invalid configuration file. It is waiting for information from any of its peers before determining how to transition to another state. |
STALE_PEER_WAIT | The system has an invalid configuration file and another system is doing a build from disk (LOCAL_BUILD). When its peer finishes the build, this system transitions to the state REMOTE_BUILD. |
UNKNOWN | The system has not joined the cluster because it does not have a system entry in the configuration. |
More Information