VCs configuration method (below)

Chapter 6: VCs configuration method (II) Offline configuration Example 1: Create a new cluster
You can create a new cluster configuration by creating a new main. cf file. You can define all cluster attributes, add service groups and resources, define relationships, and specify failover performance-all cluster configuration features by modifying the main. cf file Offline configuration Example 2: Reuse a cluster configuration
You can modify an existing configuration file and apply it to an extended and similar high availability platform.
You can copy the configuration file from the original cluster to modify the configuration file and restart VCs. This method can be effectively used to create each service group and resource by using the clustermanager or VCs command line interface. Offline configuration Example 3: Reuse a service group configuration
Another example of using offline configuration is that when you want to add a service group, there is a similar group of resources on the same cluster.
A part of main. Cf defines a service group. You can copy and modify and define a new service group as needed. (Starting and stopping VCs: how VCs starts up by default)
How does VCs start by default?
For example, assume that no system (S1 and S2) has an active cluster configuration.
1. The hastart command runs on S1 and starts the had and hashadow processes.
2. Had check the. Stale file in the configuration directory
3. Check the validity of the configuration file using had.
4. Had checks that an active cluster configuration file is on cluster interconnect.
5. Because no active cluster configuration file exists on S1, had on S1 reads the local main. cf file and loads the cluster configuration to the local memory.
6. The hastart command runs on S2 and starts the had and hashadow processes on S2.
7. Had check the. Stale file in the configuration directory
8. Had checks the validity of the configuration file on the S2 Disk
9. Had checks the active cluster configuration file on S2 by sending a broadcast message on cluster interconnect, even if the main. cf file on S2 is valid
10. had received a request from S2 on S1 and responded to it
11. Had sends a copy of cluster configuration on S1 over cluster interconnect to S2
12. Had copy the cluster configuration on S2 to the local main. cf file.
If S2 has a valid local configuration file (main. CF and type. CF), then save to the new file and use a name including the date and timestamp. The configuration of these activities is written to the disk main. cf file.
The Startup Program is repeated on each system until all members have the same cluster configuration copied to the memory and matched to the main. cf file on the local disk.
Synchronize data transmission through llT and gab. Use the. Stale file to start VCs (VCS startup with A. Stale file)
For example, if no active cluster configuration file or. Stale file exists
1. The hastart command runs on S1 and starts the had and hashadow processes.
2. Had checks the. Stale file and determines whether the file appears.
3. Determine whether the configuration file is valid through had
4. Had determines that no configuration is activated anywhere in the cluster.
5. Had enters the stale_admin_wait status because no active configuration exists.
The stale_admin_wait status indicates that when your configuration is enabled, you stop VCs on all systems. This also causes a syntax error if you start the VCs and Main. Cf files.
This allows you to check the main. cf file and determine whether you want to use the main. cf file to start VCs. You may have to modify the main. cf file. If you change the file in the running cluster, save it to the disk. Force VCs to start from a wait state (forcing VCs to start from a wait state)
If all systems are waiting, you must force VCs to start with the correct main. cf file on the system.
1. Run hasys-force S1 on S1 and start the local creation process.
Note: You must have a valid main. cf file to force VCs to run. If the main. cf file has a syntax error, running hasys-force leads to admin_wait status. You can run hacf-verify to check the File Syntax.
2. Had Delete. Stale. If it appears
3. Had check the validity of Main. cf
4. The had process reads the local main. cf file on S1, and if it has no Syntax problems, had loads the cluster configuration to the local (S1) memory.
5. When had is running on S1, this status change is broadcast on cluster interconect through gab
6. S2 then execute a remote setup to add the new cluster configuration to its memory.
7. The had process on S2 copies the cluster configuration to the local main. CF and types. Cf files and moves the original files to back up and copy (copy with a timestamp)
8. The had process on S2 deletes the. Stale file from the local configuration directory, if any. Use a special main. cf file to build the configuration
Use a stale flag to start VCs
Start VCs on all other systems by using the-stale flag, and you confirm that VCs builds new configurations in the system memory
1. Run hastart to start had and hashadow processes on S1.
2. Had process check. Stale mark
3. Check the valid main. cf file for the had Process
4. Had process check activated cluster configuration in cluster Interconnect
5. Because no active cluster configuration exists, the had process on S1 reads the local main. cf file and loads the cluster configuration to the local S1.
6. Run hastart-stale on S2.
7. Start had and check the. Stale mark
8. Had checks the active cluster configuration on S2 in cluster Interconnect and waits until S1 has a running cluster configuration
9. When VCs is running on S1, The had process sends a copy of the cluster configuration to S2.
10. S2 executes a remote setup to put the new cluster configuration into the memory.
11. The had process on S2 copies the cluster configuration to the local main. CF and types. Cf files and moves the original files to back up the copy (copy with a timestamp)
12. The had process on S2 deletes the. Stale file from the local configuration directory. Stop VCs
3. Stop the VCs engine (had and hadshadow processes ):
1. Stop VCs and all service groups offline. Stop application services under VCs control.
2. Stop the VCs and evacuate service groups to another cluster system that is running VCs.
3. Stop VCs and leave application services running from: http://hi.baidu.com/nitar/blog/item/827141fcfd038049d6887da8.html