Cluster Server 7.4 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 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
- Configuring the service group in a non-shared storage environment
- About the VCS Application Manager utility
- About testing resource failover using virtual fire drills
- HA and DR configurations using InfoScale in AWS
- HA and DR configurations in Azure environment
- 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
Failover across subnets using overlay IP
InfoScale clusters let you fail over IPs - and thereby, the application configured for HA - between different subnets in the same AZ or in different AZs.
The following information is required:
The overlay IP address to be used for failover
The device to which the IP should be plumbed
The directory in which the AWS CLI is installed; this input is not required if it is provided in the PATH environment variable
AWS does not allow the private IP of one subnet to be failed over to a different subnet. To overcome this limitation, InfoScale Enterprise provides an overlay IP, which is defined at the VPC level, so that it can be used across subnets.
The following graphic depicts a sample failover configuration across subnets within the same AZ using an overlay IP:
The sample configuration includes the following elements:
A virtual private cloud (VPC) is configured in Region A of the AWS cloud.
An application is configured for HA using an InfoScale cluster that comprises two nodes, Node 1 and Node 2, which are EC2 instances.
Node 1 exists in Subnet 1 and Node 2 exists in Subnet 2.
An overlay IP is configured, which allows the private IP of a node to be failed over from one subnet to another in an AZ as part of the failover or the failback operations.
The following snippet is a service group configuration from a sample VCS configuration file (main.cf):
group AWSIPGrp ( SystemList = { WIN-38PNEVJSR2K = 0 , WIN-39PNEVJSR2K = 1 } AutoStartList = { WIN-38PNEVJSR2K, WIN-39PNEVJSR2K } ) AWSIP overlay ( OverlayIP = "172.16.8.55/32" Device @WIN-38PNEVJSR2K = 12-7F-CE-5B-E2-6E Device@WIN-39PNEVJSR2K = 12-7F-CE-5B-E2-6F RouteTableIds = { rtb-c5272ca3, rtb-fb97ac9d } ) IP ipres ( Address= "172.16.8.55" SubNetMask = "255.255.254.0" MACAddress @WIN-38PNEVJSR2K = "12:7F:CE:5B:E2:6E" MACAddress @WIN-39PNEVJSR2K = "12:7F:CE:5B:E2:6F" ) NIC nicres ( MACAddress @WIN-38PNEVJSR2K = "12:7F:CE:5B:E2:6E" MACAddress @WIN-39PNEVJSR2K = "12:7F:CE:5B:E2:6F" ) ipres requires nicres overlayip requires ipres
The following graphic depicts a sample failover configuration across subnets in different AZs using an overlay IP:
The following snippet is a service group configuration from a sample VCS configuration file (main.cf):
group AWSIPGrp ( SystemList = { WIN-38PNEVJSR2K = 0 , WIN-39PNEVJSR2K = 1 } AutoStartList = { WIN-38PNEVJSR2K, WIN-39PNEVJSR2K } ) AWSIP overlay ( OverlayIP = "172.16.8.55/32" Device @WIN-38PNEVJSR2K = 12-7F-CE-5B-E2-6E Device@WIN-39PNEVJSR2K = 12-7F-CE-5B-E2-6F RouteTableIds = { rtb-c5272ca3, rtb-fb97ac9d } ) IP ipres ( Address = "172.16.8.55" SubNetMask = "255.255.254.0" MACAddress @WIN-38PNEVJSR2K = "12:7F:CE:5B:E2:6E" MACAddress @WIN-39PNEVJSR2K = "12:7F:CE:5B:E2:6F" ) NIC nicres ( MACAddress @WIN-38PNEVJSR2K = "12:7F:CE:5B:E2:6E" MACAddress @WIN-39PNEVJSR2K = "12:7F:CE:5B:E2:6F" ) ipres requires nicres overlayip requires ipres