havcs-410-101 a-2-10-srt-pg_2

VERITAS Cluster Server for
UNIX, Fundamentals
(Appendixes)
HA-VCS-410-101A-2-10-SRT (100-002149-B)

COURSE DEVELOPERS
Bilge Gerrits
Siobhan Seeger
Dawn Walker
LEAD SUBJECT MATTER
EXPERTS
Geoff Bergren
Paul Johnston
Dave Rogers
Jim Senicka
Pete Toemmes
TECHNICAL
CONTRIBUTORS AND
REVIEWERS
Billie Bachra
Barbara Ceran
Bob Lucas
Gene Henriksen
Margy Cassidy
Disclaimer
The information contained in this publication is subject to change without
notice. VERITAS Software Corporation makes no warranty of any kind
with regard to this guide, including, but not limited to, the implied
warranties of merchantability and fitness for a particular purpose.
VERITAS Software Corporation shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the
furnishing, performance, or use of this manual.
Copyright
Copyright © 2005 VERITAS Software Corporation. All rights reserved.
No part of the contents of this training material may be reproduced in any
form or by any means or be used for the purposes of training or education
without the written permission of VERITAS Software Corporation.
Trademark Notice
VERITAS, the VERITAS logo, and VERITAS FirstWatch, VERITAS
Cluster Server, VERITAS File System, VERITAS Volume Manager,
VERITAS NetBackup, and VERITAS HSM are registered trademarks of
VERITAS Software Corporation. Other product names mentioned herein
may be trademarks and/or registered trademarks of their respective
companies.
VERITAS Cluster Server for UNIX, Fundamentals
Participant Guide
April 2005 Release
VERITAS Software Corporation
350 Ellis Street
Mountain View, CA 94043
Phone 650–527–8000
www.veritas.com

Table of Contents i
Appendix A: Lab Synopses
Lab 2 Synopsis: Validating Site Preparation........................................................... A-2
Lab 3 Synopsis: Installing VCS ............................................................................... A-6
Lab 4 Synopsis: Using the VCS Simulator............................................................ A-18
Lab 5 Synopsis: Preparing Application Services................................................... A-24
Lab 6 Synopsis: Starting and Stopping VCS......................................................... A-29
Lab 7 Synopsis: Online Configuration of a Service Group.................................... A-31
Lab 8 Synopsis: Offline Configuration of a Service Group.................................... A-38
Lab 9 Synopsis: Creating a Parallel Service Group.............................................. A-47
Lab 10 Synopsis: Configuring Notification ............................................................ A-52
Lab 11 Synopsis: Configuring Resource Fault Behavior....................................... A-55
Lab 13 Synopsis: Testing Communication Failures .............................................. A-60
Lab 14 Synopsis: Configuring I/O Fencing............................................................ A-66
Appendix B: Lab Details
Lab 2: Validating Site Preparation........................................................................... B-3
Lab 3: Installing VCS............................................................................................. B-11
Lab 4: Using the VCS Simulator ........................................................................... B-21
Lab 5: Preparing Application Services .................................................................. B-29
Lab 6: Starting and Stopping VCS ........................................................................ B-37
Lab 7: Online Configuration of a Service Group ................................................... B-41
Lab 8: Offline Configuration of a Service Group ................................................... B-57
Lab 9: Creating a Parallel Service Group.............................................................. B-73
Lab 10: Configuring Notification............................................................................ B-85
Lab 11: Configuring Resource Fault Behavior ...................................................... B-93
Lab 13 Details: Testing Communication Failures................................................ B-101
Lab 14: Configuring I/O Fencing ......................................................................... B-111
Appendix C: Lab Solutions
Lab 2 Solutions: Validating Site Preparation........................................................... C-3
Lab 3 Solutions: Installing VCS............................................................................. C-13
Lab 4 Solutions: Using the VCS Simulator............................................................ C-35
Lab 5 Solutions: Preparing Application Services .................................................. C-51
Lab 6 Solutions: Starting and Stopping VCS ........................................................ C-63
Lab 7 Solutions: Online Configuration of a Service Group.................................... C-67
Lab 8 Solutions: Offline Configuration of a Service Group.................................... C-89
Lab 9 Solutions: Creating a Parallel Service Group............................................ C-109
Lab 10 Solutions: Configuring Notification .......................................................... C-125
Table of Contents

ii VERITAS Cluster Server for UNIX, Fundamentals
Lab 11 Solutions: Configuring Resource Fault Behavior .................................... C-133
Lab 13 Solutions: Testing Communication Failures............................................ C-149
Lab 14 Solutions: Configuring I/O Fencing ......................................................... C-163
Appendix D: Job Aids
Cluster System States............................................................................................. D-2
Resource States and Transitions............................................................................ D-4
Service Group Configuration Procedure ................................................................. D-5
Resource Configuration Procedure......................................................................... D-6
List of Notifier Events and Traps............................................................................. D-7
Example Bundled Agent Reference Guide Entries ............................................... D-10
SCSI-3 Persistent Reservations............................................................................ D-17
Best Practices ....................................................................................................... D-18
New Features in VCS 4.1...................................................................................... D-22
New Features in VCS 4.0...................................................................................... D-24
Appendix E: Design Worksheet: Template

A–2 VERITAS Cluster Server for UNIX, Fundamentals
Lab 2 Synopsis: Validating Site Preparation
In this lab, work with your partner to prepare the systems for installing VCS.
Step-by-step instructions for this lab are located on the following page:
• “Lab 2: Validating Site Preparation,” page B-3
Solutions for this exercise are located on the following page:
• “Lab 2 Solutions: Validating Site Preparation,” page C-3
Visually inspect the classroom lab site.
Complete and validate the design worksheet.
Use the lab appendix best suited to your
experience level:
experience level:
See the next slide for lab assignments.See the next slide for lab assignments.
Lab 2: Validating Site Preparation
train1
train2
train2
train1
Sample Value
System
System
Your ValueSystem Definition
? Appendix A: Lab Synopses
? Appendix B: Lab Details
? Appendix C: Lab Solutions

Appendix A Lab Synopses A–3
A
Lab Assignments
Use the table to record your cluster values as you work through the lab.
Object Sample Value Your Value
Your system host name
your_sys
train1
Partner system host name
their_sys
train2
name prefix for your
objects
bob
Interconnect link 1 Solaris: qfe0
Sol Mob: dfme0
AIX: en2
HP-UX lan1
Linux: eth2
VA bge2
Sol Mob: dmfe1
AIX: en3
HP-UX lan2
Linux: eth3
VA bge3
Public network interface
interface
Solaris: eri0
Sol Mob: dfme0
AIX: en1
HP-UX lan0
Linux: eth1
VA bge0
Admin IP address for
your_sys
192.168.xx.xxx
their_sys
192.168.xx.xxx

1 Verify that the Ethernet network interfaces for the two cluster interconnect
links are cabled together using crossover cables.
Note: In actual implementations, each link should use a completely separate
infrastructure (separate NIC and separate hub or switch). For simplicity of
configuration in the classroom environment, the two interfaces used for the
cluster interconnect are on the same NIC.
2 Verify that the public interface is cabled and accessible on the classroom public
network.
Virtual Academy
Skip this step.
Verifying the Network Configuration
Four Node—UNIX
Classroom LAN 192.168.XX, where XX=27, 28, or 29
SAN
Disk
Array
SAN
Tape
Library
train1
192.168.XX.101
train2
192.168.XX.102
train3
192.168.XX.103
train4
192.168.XX.104
train12
192.168.XX.112
train11
192.168.XX.111
train10
192.168.XX.110
train9
192.168.XX.109
LANLAN
train5
192.168.XX.105
train6
192.168.XX.106
train8
192.168.XX.108
train7
192.168.XX.107
Hub/Switch
Hub/Switch
Hub/Switch
Hub/Switch
Hub/Switch
Hub/Switch
Software Share
192.168.XX.100

A
1 Check the PATH environment variable. If necessary, add the /sbin, /usr/
sbin, /opt/VRTS/bin, and /opt/VRTSvcs/bin directories to your
PATH environment variable.
2 Check the VERITAS licenses to determine whether a VERITAS Cluster Server
license is installed.
When installing any Storage Foundation product or VERITAS Volume Replicator,
the VRTSalloc package (the VERITAS Volume Manager Intelligent Storage
Provisioning feature) requires that the following Red Hat packages are installed:
• compat-gcc-c++-7.3-2.96.128
• compat-libstdc++-7.3-2.96.128
Version 7.3-2.96.128 is provided with Red Hat Enterprise Linux 3 Update 2 (i686).
Verify that ssh configuration files are set up in order to install VCS on Linux or to
run remote commands without prompts for passwords.
If you do not configure ssh, you are required to type in the root passwords for all
systems for every remote command issued during the following services
preparation lab and the installation procedure.
If you do not want to use ssh with automatic login using saved passphrases on a
regular basis, run the following commands at the command line. This is in effect
only for this session.
exec /usr/bin/ssh-agent $SHELL
ssh-add
Save your passphrase during your GNOME session.
1 Open a console window so you can observe messages during later labs.
2 Open a System Log Display tool.
Other Checks
Checking Packages—Linux Only
Configuring Secure Shell—Linux Only
Setting Up a Console Window—Linux Only

Lab 3 Synopsis: Installing VCS
In this lab, work with your lab partner to install VCS on both systems.
• “Lab 3: Installing VCS,” page B-11
• “Lab 3 Solutions: Installing VCS,” page C-13
Obtaining Classroom Information
Use the following table to collect information you need to install VCS. Your
instructor may also ask you to install VERITAS Volume Manager and VERITAS
File System.
Lab 3: Installing VCS
train1 train2
# ./installer# ./installer
vcs1vcs1
Link 1:______
Link 2:______
Software
location:_______________________________
Subnet:_______
Link 1:______
Link 2:______
Public:______ Public:______
4.x4.x
# ./installvcs# ./installvcsPre-4.0Pre-4.0

A
Cluster Definition These values define cluster properties and are required to install
VCS.
Attributes/Properties Sample Value Your Values
Node names, cluster
name, and cluster ID
train1 train2 vcs1 1
train1
train2
vcs1
1
Cluster interconnect Ethernet interface for
interconnect link #1
Solaris: qfe0
Sol Mob: dmfe0
AIX: en2
HP-UX lan1
Linux: eth1
VA: bge2
Ethernet interface for
Solaris: qfe1
Sol Mob: dmfe1
AIX: en3
HP-UX lan2
Linux: eth2
VA: bge3
Public network
interface
interface
Solaris: eri0
Sol Mob: dmfe0
AIX: en1
HP-UX lan0
Linux: eth1
VA: bge0

Web GUI IP Address:
train1 train2
train3 train4
train5 train6
train7 train8
train9 train10
train11 train12
Subnet Mask
Network interface
NetworkHosts (HP-UX
only)
192.168.xxx.91
192.168.xxx.92
192.168.xxx.93
192.168.xxx.94
192.168.xxx.95
192.168.xxx.96
255.255.255.0
Solaris: eri0
Sol Mob: dmfe0
AIX: en0
HP-UX lan0
Linux: eth0
VA: bge0
see instructor
Installation software
location
install_dir
License
Administrator account Name
Password
admin
password
VCS.

A
1 Obtain the location of the installation software from your instructor.
Installation software location:
_____________________________________________________________
2 This first step is to be performed from only one system in the cluster. The install
script installs and configures all systems in the cluster.
a Change to the install directory.
b Run the installer script (VERITAS Product Installer) located in the
directory specified above. For versions of VCS before 4.0, use
installvcs. Use the information in the previous table or design
worksheet to respond to the installation prompts.
Note: For VCS 4.x, install Storage Foundation (Volume Manager and File
System).
c If a license key is needed, obtain one from your instructor and record it
here.
License Key: ____________________________________________
d Install all optional packages (including Web console and Simulator).
e Accept default of Y to configure VCS.
f Do not configure a third heartbeat link at this time.
g Do not configure a low-priority heartbeat link at this time.
h Do not configure VERITAS Security Services.
i Do not set any user names or passwords.
j Retain the default admin user account and password.
k Configure the Cluster Server Cluster Manager.
l Do not configure SMTP Notification.
Installing VERITAS Cluster Server Software

m Do not configure SNMP Notification.
n Select the option to install all packages simultaneously on all systems.
o Do not set up enclosure-based naming for Volume Manager.
p Start Storage Foundation Enterprise HA processes.
q Do not set up a default disk group.
3 If you did not install the Java GUI package as part of the installer (VPI)
process (or installvcs for earlier versions of VCS), install the VRTScscm
Java GUI package on each system in the cluster. The location of this package is
in the pkgs directory under the install location directory given to you by your
instructor.
1 If your instructor indicates that additional software, such as VCS patches or
updates, is required, obtain the location of the installation software from your
instructor.
Installation software directory:
_____________________________________________________________
2 Install any VCS patches or updates, as directed by your instructor. Use the
operating system-specific command.
3 Install any other software indicated by your instructor. For example, if your
classroom uses VCS 3.5, you may be directed to install VERITAS Volume
Manager and VERITAS File System.
Installing Other Software

A
You can use the worksheet at the end of this lab synopsis to verify and record your
cluster configuration.
1 Verify that VCS is now running using hastatus.
If hastatus -sum shows the cluster systems in a running state and a
ClusterService service group is online on one of your cluster systems, VCS has
been properly installed and configured.
2 Perform additional verification (generally only necessary if there is a problem
displayed by hastatus -sum).
a Verify that all packages are loaded.
b Verify that LLT is running.
c Verify that GAB is running.
View the configuration files set up by the VCS installation procedure.
1 Explore the LLT configuration.
2 Explore the GAB configuration.
3 Explore the VCS configuration files.
Viewing VERITAS Cluster Server Installation Results
Exploring the Default VCS Configuration

Verify GUI connectivity with the Java GUI and the Web GUI. Both GUIs can
connect to the cluster with the default user of admin and password as the default
password.
1 Use a Web browser to connect to the Web GUI.
2 Start the Java GUI and connect to the cluster using these values:
3 Browse the cluster configuration.
Verifying Connectivity with the GUIs

A
First system:
Design Worksheet: Cluster Interconnect Configuration
/etc/VRTSvcs/comms/llttab Sample Value Your Value
set-node
(host name)
train1
set-cluster
(number in host name of odd
system)
1
link Solaris: qfe0
Sol Mob: dfme0
AIX: en2
HP-UX lan1
Linux: eth2
VA: bge2
link Solaris: qfe1
Sol Mob: dmfe1
AIX: en3
HP-UX lan2
Linux: eth3
VA: bge3
/etc/VRTSvcs/comms/llthosts Sample Value Your Value
train1
train2
/etc/VRTSvcs/comms/sysname Sample Value Your Value
train1

Second system:
Cluster Configuration (main.cf)
/etc/VRTSvcs/comms/llttab Sample Value Your Value
set-node train2
set-cluster 1
link Solaris: qfe0
Sol Mob: dfme0
AIX: en2
HP-UX lan1
Linux: eth2
VA: bge2
link Solaris: qfe1
Sol Mob: dmfe1
AIX: en3
HP-UX lan2
Linux: eth3
VA: bge3
/etc/VRTSvcs/comms/llthosts Sample Value Your Value
train1
train2
/etc/VRTSvcs/comms/sysname Sample Value Your Value
train2
Types Definition Sample Value Your Value
Include types.cf

A
Cluster Definition Sample Value Your Value
Cluster vcs1
Required Attributes
UserNames admin=password
ClusterAddress 192.168.xx.91
Administrators admin
Optional Attributes
CounterInterval 5
System Definition Sample Value Your Value
System train1 (odd)
System train2 (even)
Service Group Definition Sample Value Your Value
Group ClusterService
Required Attributes
FailoverPolicy Priority
SystemList train1=0 train2=1
Optional Attributes
AutoStartList train1
OnlineRetryLimit 3
Tag CSG

Resource Definition Sample Value Your Value
Service Group ClusterService
Resource Name webip
Resource Type IP
Required Attributes
Device eri0
Address 192.168.xx.91
Optional Attributes
Netmask 255.255.255.0
Critical? Yes (1)
Enabled? Yes (1)
Resource Name csgnic
Resource Type NIC
Required Attributes
Device <platform specific>
Critical? Yes (1)
Enabled? Yes (1)
Resource Name VCSWeb
Resource Type VRTSWebApp
Required Attributes
AppName vcs
InstallDir /opt/VRTSweb/VERITAS
TimeForOnline 5
Critical? Yes (1)
Enabled? Yes (1)

A
Resource Dependency Definition
Parent Resource Requires Child Resource
VCSWeb webip
webip csgnic

Lab 4 Synopsis: Using the VCS Simulator
This lab uses the VERITAS Cluster Server Simulator and the Cluster Manager
Java Console. You are provided with a preconfigured main.cf file to learn about
managing the cluster.
• “Lab 4: Using the VCS Simulator,” page B-21
• “Lab 4 Solutions: Using the VCS Simulator,” page C-35
Use the following table to record the values for your classroom.
Attribute Sample Value Your Value
Port 15559
VCS user account/
password
oper/oper
Lab 4: Using the VCS Simulator
1. Start the Simulator Java GUI.
hasimgui &
2. Add a cluster.
3. Copy the preconfigured
main.cf file to the new
directory.
4. Start the cluster from the
Simulator GUI.
5. Launch the Cluster Manager
Java Console
6. Log in using the VCS
account oper with password
oper.
This account demonstrates
different privilege levels in
VCS.
See next slide for classroom values
See next slide for lab assignments.See next slide for lab assignments.

A
File Locations
Type of File Location
Lab main.cf file:
cf_files_dir
Simulator
configuration
directory:
sim_config_dir

4 Add /opt/VRTScssim/bin to your PATH environment variable after any
/opt/VRTSvcs/bin entries, if it is not already present.
5 Set the VCS_SIMULATOR_HOME environment variable to /opt/
VRTScssim, if it is not already set.
6 Start the Simulator GUI.
7 Add a cluster.
8 Use these values to define the new simulated cluster:
– Cluster Name: vcs_operations
– System Name: S1
– Port: 15559
– Platform: Solaris
– WAC Port: -1
9 In a terminal window, change to the simulator configuration directory for the
new simulated cluster named vcs_operations.
10 Copy the main.cf, types.cf, and OracleTypes.cf files provided by
your instructor into the vcs_operations simulation configuration directory.
11 From the Simulator GUI, start the vcs_operations cluster, launch the VCS Java
Console for the vcs_operations simulated cluster, and log in as oper with
password oper.
Note: While you may use admin/password to log in, the point of using oper is to
demonstrate the differences in privileges between VCS user accounts.
Starting the Simulator on UNIX

A
1 How many systems are members of the cluster?
2 Determine the status of all service groups.
3 Which service groups have service group operator privileges set for the oper
account?
4 Which resources in the AppSG service group have the Critical resource
attribute enabled?
5 Which resource is the top-most parent in the OracleSG service group?
6 Which immediate child resources does the Oracle resource in the OracleSG
service group depend on?
Viewing Status and Attributes
Service Group Status on S1 Status on S2 Status on S3
AppSG
OracleSG
ClusterService

1 Attempt to take the ClusterService group offline on S1.
What happens?
2 Attempt to take the AppSG service group offline on S1.
What happens?
3 Attempt to take the Oracle service group offline on S1.
What happens?
4 Take all service groups that you have privileges for offline everywhere.
5 Bring the AppSG service group online on S2.
6 Bring the OracleSG service group online on S1.
7 Switch service group AppSG to S1.
8 Switch the OracleSG service group to S2.
9 Bring all service groups that you have privileges for online on S3.
Manipulating Service Groups

A
1 Attempt to take the OraListener resource in OracleSG offline on S3.
What happens to the OracleSG service group?
2 Bring the OraListener resource online on S3.
3 Attempt to take the OraMount resource offline on system S3.
What happens?
4 Attempt to bring only the OraListener resource online on S1.
What happens?
5 Fault the Oracle (oracle) resource in the OracleSG service group.
6 What happens to the service group and resource?
7 View the log entries to see the sequence of events.
8 Attempt to switch the OracleSG service group back to S3.
What happens?
9 Clear the fault on the Oracle resource in the OracleSG service group.
10 Switch the OracleSG service group back to S3.
11 Save and close the configuration, log off from the GUI, and stop the simulator.
Manipulating Resources

Lab 5 Synopsis: Preparing Application Services
The purpose of this lab is to prepare the loopy process service for high availability.
• “Lab 5: Preparing Application Services,” page B-29
• “Lab 5 Solutions: Preparing Application Services,” page C-51
Lab Assignments
Use the design worksheet to gather and record the values needed to complete the
preparation steps.
disk1
bobDG1
/bob1 bobVol1
Lab 5: Preparing Application Services
disk2
sueDG1
sueVol1 /sue1
NIC
IP Address
while true
do
echo “…”
done
/bob1/loopy
Disk/Lun Disk/Lun
NIC
IP Address
while true
do
echo “…”
done
/sue1/loopy
See next slide for classroom values.See next slide for classroom values.

A
Service Group nameSG1
Resource Name nameNIC1
Resource Type NIC
Required Attributes
Device Solaris: eri0
Sol Mob: dmfe0
AIX: en1
HP-UX: lan0
Linux: eth0
VA: bge0
NetworkHosts* 192.168.xx.1 (HP-UX
only)
Critical? No (0)
Enabled? Yes (1)
Resource Name nameIP1
Resource Type IP
Required Attributes
Sol Mob: dmfe0
AIX: en1
HP-UX: lan0
Linux: eth1
VA: bge0
Address 192.168.xx.5* see table
Optional Attributes
Netmask 255.255.255.0
Critical? No (0)
Enabled? Yes (1)

1 Create a disk group using the convention specified in the worksheet.
2 Create a 2 GB volume and a vxfs file system.
3 Create a mount points, mount the file system on your cluster system, and verify
that it is mounted.
1 Verify that an IP address exists on the base interface for the public network.
2 Configure a virtual IP address on the public network interface using the IP
address from the design worksheet.
System IP Address
train1 192.168.xx.51
train2 192.168.xx.52
train3 192.168.xx.53
train4 192.168.xx.54
train5 192.168.xx.55
train6 192.168.xx.56
train7 192.168.xx.57
train8 192.168.xx.58
train9 192.168.xx.59
train10 192.168.xx.60
train11 192.168.xx.61
train12 192.168.xx.62
Configuring Storage for an Application
Configuring Networking for an Application

A
A script named loopy is used as the example application for this lab exercise.
1 Obtain the location of the loopy script from your instructor.
loopy script location:
__________________________________________________________
2 Copy this file to a file named loopy on the file system you created.
3 Start the loopy application in the background.
4 Verify that the loopy application is working correctly.
Setting up the Application

Complete the following steps to migrate the application to the other system.
1 Stop all resources used in this service to prepare to manually migrate the
service.
a Stop your loopy process.
b Stop all storage resources.
c Unconfigure the virtual IP address.
2 On the other cluster system, import your disk group and bring up the remaining
storage resources and the virtual IP address.
3 Start the loopy application and verify that it is running.
4 After you have verified that all resources are working properly on the second
system, stop all resources.
Manually Migrating the Application

A
Lab 6 Synopsis: Starting and Stopping VCS
The following procedure demonstrate how the cluster configuration changes states
during startup and shutdown, and shows how the .stale file works.
• “Lab 6: Starting and Stopping VCS,” page B-37
• “Lab 6 Solutions: Starting and Stopping VCS,” page C-63
Note: Complete this section with your lab partner.
1 Verify that there is no .stale file in the configuration directory.
2 Open the cluster configuration and verify that the .stale file has been
created.
3 Try to stop VCS.
4 Stop VCS forcibly and leave the applications running.
Lab 6: Starting and Stopping VCS
train1 train2
# hastop –all -force# hastop –all -force
vcs1vcs1

5 Start VCS on each system in the cluster and check the cluster status.
Why are all systems in the STALE_ADMIN_WAIT state?
6 Verify that the .stale file is present.
7 Return all systems to a running state (from one system in the cluster). View the
build process to see the LOCAL_BUILD and REMOTE_BUILD system
states.
8 Verify that there is no .stale file.

A
Lab 7 Synopsis: Online Configuration of a Service Group
The purpose of this lab is to create a service group while VCS is running using
either the Cluster Manager graphical user interface or the command-line interface.
• “Lab 7: Online Configuration of a Service Group,” page B-41
• “Lab 7 Solutions: Online Configuration of a Service Group,” page C-67
Lab 7: Online Configuration of a Service Group
Use the Java GUI to:
Create a service
group.
Add resources to
the service group
from the bottom of
the dependency
tree.
Substitute the
name you used to
create the disk
group and volume.

Fill in the design worksheet with values appropriate for your cluster and use the
information to create a service group.
1 Create the service group using the values in the table.
2 Save the cluster configuration and view the configuration file to verify your
changes.
Creating a Service Group
Group nameSG1
Required Attributes
FailOverPolicy Priority
Optional Attributes

A
Add NIC, IP, DiskGroup, Volume, and Process resources to the service group
using the information from the design worksheets.
After each resource is added:
• Bring each resource online.
• Save the cluster configuration.
Adding Resources to a Service Group
Resource Type NIC
Required Attributes
Sol Mob: dmfe0
AIX: en1
HP-UX: lan0
Linux: eth0
VA: bge0
only)
Critical? No (0)
Enabled? Yes (1)

Resource Type IP
Required Attributes
Sol Mob: dmfe0
AIX: en1
HP-UX: lan0
Linux: eth0
VA: bge0
Address 192.168.xx.** see table
Optional Attributes
Netmask 255.255.255.0
Critical? No (0)
Enabled? Yes (1)
System IP Address
train1 192.168.xx.51
train2 192.168.xx.52
train3 192.168.xx.53
train4 192.168.xx.54
train5 192.168.xx.55
train6 192.168.xx.56
train7 192.168.xx.57
train8 192.168.xx.58
train9 192.168.xx.59
train10 192.168.xx.60
train11 192.168.xx.61
train12 192.168.xx.62

A
Resource Name nameDG1
Resource Type DiskGroup
Required Attributes
DiskGroup nameDG1
Optional Attributes
StartVolumes 1
StopVolumes 1
Critical? No (0)
Enabled? Yes (1)
Resource Name nameVol1
Resource Type Volume
Required Attributes
Volume nameVol1
DiskGroup nameDG1
Critical? No (0)
Enabled? Yes (1)

Resource Name nameMount1
Resource Type Mount
Required Attributes
MountPoint /name1
BlockDevice /dev/vx/dsk/nameDG1/
nameVol1 (no spaces)
FSType vxfs
FsckOpt -y
Critical? No (0)
Enabled? Yes (1)
Resource Name nameProcess1
Resource Type Process
Required Attributes
PathName /bin/sh
Optional Attributes
Arguments /name1/loopy name 1
Critical? No (0)
Enabled? Yes (1)

A
After you have verified that all resources are online, link the resources as shown in
worksheet.
1 Test the service group by switching it between systems.
2 Set each resource to critical.
changes.
4 Close the cluster configuration after all students working in your cluster are
finished.
Linking Resources in the Service Group
nameVol1 nameDG1
nameMount1 nameVol1
nameIP1 nameNIC1
nameProcess1 nameMount1
nameProcess1 nameIP1
Testing the Service Group

Lab 8 Synopsis: Offline Configuration of a Service Group
The purpose of this lab is to add a service group by copying and editing the
definition in main.cf for nameSG1.
• “Lab 8: Offline Configuration of a Service Group,” page B-57
• “Lab 8 Solutions: Offline Configuration of a Service Group,” page C-89
Lab Assignments
Complete the following worksheet for the resources managed by the service
groups you create in this lab. Then follow the procedure to configure the resources.
Lab 8: Offline Configuration of a Service Group
name
Process2
AppVol
App
DG
name
NIC2
name
IP2
name
DG2
name
Vol2
name
Mount2
name
Process1
name
DG1
name
Vol1
name
Mount1
name
NIC1
name
IP1
nameSG1nameSG1 nameSG2nameSG2
Working together, follow the offline
configuration procedure.
Alternately, work alone and use the
GUI to create a new service group.
Working together, follow the offline
configuration procedure.
Alternately, work alone and use the
GUI to create a new service group.

A
your_sys
Use the same system as
previous labs
their_sys
Use the same system as
previous labs
Name prefix for your
objects
name
Disk assignment for disk
group
Solaris: c#t#d#
AIX: hdisk##
HP-UX: c#t#d#
Linux: sd##
Disk group name nameDG2
Volume name nameVol2 (2Gb)
Mount point /name2
Application script location

Use the values in the table to prepare resources for VCS.
1 Create a disk group using the convention specified in the worksheet.
2 Create a 2 GB volume and a vxfs file system.
3 Create a mount points, mount the file system on your cluster system, and verify
it is mounted.
4 Copy the loopy script to this file system.
5 Start the loopy and verify that the application is working correctly.
6 Stop the resources to prepare to place them under VCS control in the next
section of the lab.
Prepare Resources

A
In the design worksheet, record information needed to create a new service group
using the offline process described in the next section.
Completing the Design Worksheet
Group nameSG2
Required Attributes
Optional Attributes
Resource Type NIC
Required Attributes
Sol Mob: dmfe0
AIX: en1
HP-UX: lan0
Linux: eth0
VA: bge0
only)
Critical? No (0)
Enabled? Yes (1)

Resource Type IP
Required Attributes
Sol Mob: dmfe0
AIX: en1
HP-UX: lan0
Linux: eth0
VA: bge0
Optional Attributes
Netmask 255.255.255.0
Critical? No (0)
Enabled? Yes (1)
System IP Address
train1 192.168.xx.71
train2 192.168.xx.72
train3 192.168.xx.73
train4 192.168.xx.74
train5 192.168.xx.75
train6 192.168.xx.76
train7 192.168.xx.77
train8 192.168.xx.78
train9 192.168.xx.79
train10 192.168.xx.80
train11 192.168.xx.81
train12 192.168.xx.82

A
Required Attributes
DiskGroup nameDG2
Optional Attributes
StartVolumes 1
StopVolumes 1
Critical? No (0)
Enabled? Yes (1)
Required Attributes
Volume nameVol2
DiskGroup nameDG2
Critical? No (0)
Enabled? Yes (1)

Resource Type Mount
Required Attributes
MountPoint /name2
FSType vxfs
FsckOpt -y
Critical? No (0)
Enabled? Yes (1)
Required Attributes
PathName /bin/sh
Optional Attributes
Critical? No (0)
Enabled? Yes (1)

A
1 Working with your lab partner, verify that the cluster configuration is saved
and closed.
2 Make a test subdirectory of the configuration directory.
3 Create copies of the main.cf and types.cf files in the test subdirectory.
Linux
Also copy the vcsApacheTypes.cf file.
4 One student at a time, modify the main.cf file in the test directory on one
system in the cluster.
a Copy the first student’s nameSG1 service group structure to a nameSG2
and rename all of the resources within the nameSG1 service group to end
with 2 instead of 1, as shown in the following table.
nameVol2 nameDG2
nameMount2 nameVol2
nameIP2 nameNIC2
Modifying a VCS Configuration File

b Copy and modify the dependency section.
c Repeat this for the other student’s service group.
5 Edit the attributes of each copied resource to match the design worksheet
values shown earlier in this section.
6 Verify the cluster configuration and fix any errors found.
7 Stop VCS on all systems, but leave the applications still running.
8 Copy the main.cf file from the test subdirectory into the configuration
directory.
9 Start the cluster from the system where you edited the configuration file and
start the other system in the stale state.
10 Bring the new service group online on your system. Students can bring their
own service groups online.
11 Verify the status of the cluster.
Existing Name Change To New Name
nameProcess1 nameProcess2
nameIP1 nameIP2
nameNIC1 nameNIC2
nameMount1 nameMount2
nameVol1 nameVol2
nameDG1 nameDG2

A
Lab 9 Synopsis: Creating a Parallel Service Group
The purpose of this lab is to add a parallel service group to monitor the NIC
resource and replace the NIC resources in the failover service groups with Proxy
resources.
• “Lab 9: Creating a Parallel Service Group,” page B-73
• “Lab 9 Solutions: Creating a Parallel Service Group,” page C-109
Lab 9: Creating a Parallel Service Group
name
Process2
DBVol
DB
DG
name
Proxy2
name
IP2
name
DG2
name
Vol2
name
Mount2
name
Process1
name
DG1
name
Vol1
name
Mount1
name
Proxy1
name
IP1
Network
NIC
Network
Phantom
nameSG1nameSG1 nameSG2nameSG2
NetworkSGNetworkSG

Work with your lab partner to create a parallel service group containing network
resources using the information in the design worksheet.
Creating a Parallel Network Service Group
Group NetworkSG
Required Attributes
Parallel 1
Optional Attributes
AutoStartList train1 train2

A
Use the values in the following tables to create NIC and Phantom resources and
then bring them online. Remember to save the cluster configuration.
Adding Resources
Service Group NetworkSG
Resource Name NetworkNIC
Resource Type NIC
Required Attributes
Sol Mob: dmfe0
AIX: en1
HP-UX: lan0
Linux: eth0
VA: bge0
Critical? No (0)
Enabled? Yes (1)
Service Group NetworkSG
Resource Name NetworkPhantom
Resource Type Phantom
Required Attributes
Critical? No (0)
Enabled? Yes (1)

Working on your own, use the values in the tables to replace the NIC resources
with Proxy resources and create new links.
Replacing NIC Resources with Proxy Resources
Resource Name nameProxy1
Resource Type Proxy
Required Attributes
TargetResName NetworkNIC
Critical? No (0)
Enabled? Yes (1)
Resource Name nameProxy2
Resource Type Proxy
Required Attributes
Critical? No (0)
Enabled? Yes (1)
Resource Name csgProxy
Resource Type Proxy
Required Attributes
Critical? No (0)
Enabled? Yes (1)

A
1 Use the values in the tables to replace the NIC resources with Proxy resources
and create new links.
2 Switch each service group (nameSG1, nameSG2, ClusterService) to ensure
that they can run on each system.
3 Set all resources to critical.
4 Save and close the cluster configuration.
Linking Resources and Testing the Service Group
nameIP1 nameProxy1
nameIP2 nameProxy2
webip csgProxy

Lab 10 Synopsis: Configuring Notification
The purpose of this lab is to configure notification.
• “Lab 10: Configuring Notification,” page B-85
• “Lab 10 Solutions: Configuring Notification,” page C-125
Lab 10: Configuring Notification
nameSG1
ClusterService
nameSG2
NotifierMngr
TriggersTriggers
resfault
nofailover
resadminwait
resfault
nofailover
resadminwait
Optional Lab
SMTP Server:
___________________________________
SMTP Server:
___________________________________

A
1 Work with your lab partner to add a NotifierMngr type resource to the
ClusterService service group using the information in the design worksheet.
2 Bring the resource online and test the service group by switching it between
systems.
3 Set the notifier resource to critical.
4 Save and close the cluster configuration and view the configuration file to
verify your changes.
Note: In the next lab, you will see the effects of configuring notification and
triggers when you test various resource fault scenarios.
Configuring the NotifierMngr Resource
Resource Name notifier
Resource Type NotifierMngr
Required Attributes
SmtpServer localhost
SmtpRecipients root Warning
PathName /xxx/xxx (AIX only)
Critical? No (0)
Enabled? Yes (1)

Use the following procedure to configure triggers for notification. In this lab, each
student creates a local copy of the trigger script on their own system. If you are
working alone in the cluster, copy your completed triggers to the other system.
1 Create a text file in the /opt/VRTSvcs/bin/triggers directory named
resfault. Add the following lines to the file:
#!/bin/sh
echo `date` > /tmp/resfault.msg
echo message from the resfault trigger >> /tmp/
resfault.msg
echo Resource $2 has faulted on System $1 >> /tmp/
resfault.msg
echo Please check the problem. >> /tmp/resfault.msg
/usr/lib/sendmail root </tmp/resfault.msg
rm /tmp/resfault.msg
2 Create a nofailover trigger using the same script, replacing resfault
with nofailover.
3 Create a resadminwait trigger using the same script, replacing resfault
with resadminwait.
4 Ensure that all trigger files are executable.
5 If you are working alone, copy all triggers to the other system.
Optional Lab: Configuring Triggers

A
Lab 11 Synopsis: Configuring Resource Fault Behavior
The purpose of this lab is to observe how VCS responds to faults in a variety of
scenarios.
• “Lab 11: Configuring Resource Fault Behavior,” page B-93
• “Lab 11 Solutions: Configuring Resource Fault Behavior,” page C-133
This part of the lab exercise explores the default behavior of VCS. Each student
works independently in this lab.
1 Verify that all resources in the nameSG1 service group are currently set to
critical; if not, set them to critical.
2 Set the IP and Process resources to not critical in the nameSG1 service group.
Non-Critical Resource Faults
Lab 11: Configuring Resource Fault Behavior
nameSG1 nameSG2
Critical=0
Critical=1
FaultPropagation=0
FaultPropagation=1
ManageFaults=NONE
ManageFaults=ALL
RestartLimit=1
Note: Network interfaces for virtual IP addresses
are unconfigured to force the IP resource to fault.
In your classroom, the interface you specify is:______
Replace the variable interface in the lab steps with this
value.
Note: Network interfaces for virtual IP addresses
are unconfigured to force the IP resource to fault.
In your classroom, the interface you specify is:______
Replace the variable interface in the lab steps with this
value.

3 Change the monitor interval for the IP resource type to 10 seconds and the
offline monitor interval for the IP resource type to 30 seconds.
4 Verify that your nameSG1 service group is currently online on your system.
5 Unconfigure the interface corresponding to the virtual IP address—outside of
VCS.
What happens?
6 Clear any faults.
7 Bring the IP and Process resources back online on your system.
8 Set the IP and process resource to critical in the nameSG1 service group.
critical.
2 Verify that your nameSG1 service group is currently online on your system.
VCS.
What happens?
4 Without clearing faults from the last failover, unconfigure the virtual IP
address on their system.
What happens?
5 Clear the nameIP1 resource on all systems and bring the nameSG1 service
group online on your system.
Critical Resource Faults

A
critical.
2 Verify that your nameSG1 Service group is currently online on your system.
3 Freeze the nameSG1 service group.
VCS.
What happens?
5 Bring up the virtual IP address outside of VCS.
What happens?
6 Unconfigure the virtual IP address outside of VCS to fault the IP resource
again. While the resource is faulted, unfreeze the service group.
7 Did unfreezing the service group cause a failover or any resources to come
offline? Explain why or why not.
8 Clear the fault and bring the resource online.
Faults within Frozen Service Groups

critical.
2 Set the FaultPropagation attribute for the nameSG1 service group to off (0).
VCS.
What happens?
4 Clear the faulted resource and bring the resource back online.
5 Set the ManageFaults attribute for the nameSG1 service group to NONE and
set the FaultPropagation attribute back to one (1).
VCS.
What happens?
7 Recover the resource from the ADMIN_WAIT state.
VCS.
What happens?
9 Recover the resource from the ADMIN_WAIT state by faulting the service
group.
10 Clear the faulted nameIP1 resource and switch the nameSG1 service group
back to your system.
11 Set ManageFaults back to ALL for the nameSG1 service group and save the
cluster configuration.
Effects of ManageFaults and FaultPropagation

A
This section illustrates failover behavior of a resource type using restart limits.
1 Verify that all resources in the nameSG1 service group are set to critical.
2 Set the RestartLimit Attribute for the Process resource type to 1.
3 Stop the loopy process running in the nameSG1 service group by sending a
kill signal.
What happens?
4 Stop the loopy process running in the nameSG1 service group by sending a
kill signal.
Note: The effects of stopping loopy can take up to 60 seconds to be detected.
What happens?
5 Clear the faulted resource and switch the nameSG1 service group back to your
system.
6 When all students have completed the lab, save and close the configuration.
RestartLimit Behavior

Lab 13 Synopsis: Testing Communication Failures
The purpose of this lab is to configure a low-priority link and then pull network
cables and observe how VCS responds.
• “Lab 13 Details: Testing Communication Failures,” page B-101
• “Lab 13 Solutions: Testing Communication Failures,” page C-149
Lab 13: Testing Communication Failures
TriggerTrigger injeopardyinjeopardy
Optional Lab
1. Configure the InJeopardy trigger (optional).
2. Configure a low-priority link.
3. Test failures.
trainxxtrainxx
trainxxtrainxx

A
Use the following procedure to configure triggers for jeopardy notification. In this
lab, students create a local copy of the trigger script on their own systems.
1 Create a text file in the /opt/VRTSvcs/bin/triggers directory named
injeopardy. Add the following lines to the file:
#!/bin/sh
echo `date` > /tmp/injeopardy.msg
echo message from the injeopardy trigger >> /tmp/
injeopardy.msg
echo System $1 is in Jeopardy >> /tmp/injeopardy.msg
echo Please check the problem. >> /tmp/injeopardy.msg
/usr/lib/sendmail root </tmp/injeopardy.msg
rm /tmp/injeopardy.msg
2 Make the trigger file executable.
3 If you are working alone, copy the trigger to the other system.
4 Continue with the next lab sections. The “Multiple LLT Link Failures—
Jeopardy” section of this lab shows the effects of configuring the InJeopardy
trigger.
Optional Lab: Configuring the InJeopardy Trigger

Working with your lab partner, use the procedures to create a low-priority link and
then fault communication links and observe what occurs in a cluster environment
when fencing is not configured.
1 Save and close the cluster configuration.
2 Shut down VCS, leaving the applications running on all systems in the cluster.
3 Unconfigure GAB and LLT on each system in the cluster.
Adding a Low-Priority Link
Public Ethernet interface
for link low-pri
Solaris: eri0
Sol Mob: dmfe0
AIX: en1
HP-UX lan0
Linux: eth0
VA: bge0
Cluster interconnect link 1 Solaris: qfe0
Sol Mob: dmfe0
AIX: en2
HP-UX lan1
Linux: eth1
VA: bge2
Cluster interconnect link 2 Solaris: qfe1
Sol Mob: dmfe1
AIX: en3
HP-UX lan2
Linux: eth2
VA: bge3
Host name for sysname file
for your_sys
train1
Host name for sysname file
for their_sys
train2

A
4 Edit the /etc/llttab LLT configuration file on each system to add a
directive for a low-priority LLT link on the public network.
Solaris Mobile
Skip this step for mobile classrooms. There is only one public interface and it
is already configured as a low-priority link.
5 Start LLT and GAB on each system.
6 Verify GAB membership.
7 Start VCS on each system.
Note: For Solaris mobile classrooms, skip this section.
1 Copy the lltlink_enable and lltlink_disable utilities from the
location provided by your instructor into the /tmp directory.
_____________________________________________________________
2 Change the NIC resource type MonitorInterval attribute to 3600 seconds
temporarily for communications testing. This prevents the NetworkNIC
resource from faulting during this lab when the low-priority LLT link is pulled.
3 Throughout this lab, use the lltlink_disable command to simulate
failure of an LLT link where you are instructed to remove a link.
Notes:
– Use lltlink_enable to restore the LLT link.
– The utilities prompt you to select an interface.
– These classroom utilities are provided to enable you to simulate
disconnecting and reconnecting Ethernet cables without risk of damaging
connectors.
– Run the utility from one system only, unless otherwise specified.
Single LLT Link Failure

4 Using the lltlink_disable utility, remove one LLT link and watch for
the link to expire in the console or system log file.
5 Restore communications using lltlink_enable.
1 Verify the status of GAB.
2 Remove all but one LLT link and watch for the link to expire in the console.
Solaris Mobile
Remove only the one high-priority LLT link (dmfe1).
4 Restore communications by replacing the LLT link cables.
1 Verify the status of GAB from each system.
2 Remove all but one LLT link and watch for the link to expire in the console.
Solaris Mobile
Remove only the one high-priority LLT link (dmfe1).
3 From each system, verify that the links are down by checking the status of
GAB.
4 Remove the last LLT link and watch for the link to expire in the console.
Multiple LLT Link Failures—Jeopardy
Multiple LLT Link Failures—Network Partition

A
5 What is the status of service groups running on each system?
6 Recover from the network partition.
7 Change the NIC resource type MonitorInterval attribute back to 60 seconds.

Lab 14 Synopsis: Configuring I/O Fencing
Use the lab instructions in one of the following appendixes.
• “Lab 14: Configuring I/O Fencing,” page B-111
• “Lab 14 Solutions: Configuring I/O Fencing,” page C-163
Lab 14: Configuring I/O Fencing
Work with your lab partner to configure fencing.
trainxxtrainxx
Coordinator Disks
nameDG1, nameDG2
Disk 1:___________________
Disk 2:___________________
Disk 3:___________________

B–2 VERITAS Cluster Server for UNIX, Fundamentals

Lab 2: Validating Site Preparation B–3
B

In this lab, you work with your partner to prepare the systems for installing VCS.
Brief instructions for this lab are located on the following page:
• “Lab 2 Synopsis: Validating Site Preparation,” page A-2
• “Lab 2 Solutions: Validating Site Preparation,” page C-3
Lab Assignments
Fill in the table with the applicable values for your lab cluster.
your_sys
train1
their_sys
train2
name prefix for your
objects
bob
Sol Mob: dfme0
AIX: en2
HP-UX lan1
Linux: eth2
VA bge2
experience level:
experience level:
See the next slide for lab assignments.See the next slide for lab assignments.
train1
train2
train2
train1
Sample Value
System
System
Your ValueSystem Definition

B
Sol Mob: dmfe1
AIX: en3
HP-UX lan2
Linux: eth3
VA bge3
Public network interface
interface
Solaris: eri0
Sol Mob: dfme0
AIX: en1
HP-UX lan0
Linux: eth1
VA bge0
your_sys
192.168.xx.xxx
their_sys
192.168.xx.xxx

1 Verify that the Ethernet network interfaces for the two cluster interconnect
links are cabled together using crossover cables.
Note: In actual implementations, each link should use a completely separate
infrastructure (separate NIC and separate hub or switch). For simplicity of
configuration in the classroom environment, the two interfaces used for the
cluster interconnect are on the same NIC.
2 Verify that the public interface is cabled, as shown in the diagram.
Virtual Academy
Skip this step.
3 Determine the host name of the local system.
4 Determine the base IP address configured on the public network interface for
both your system and your partner’s system.
5 Verify that the public IP address of each system in your cluster is listed in the
/etc/hosts file.
Verifying the Network Configuration
Four Node—UNIX
Classroom LAN 192.168.XX, where XX=27, 28, or 29
SAN
Disk
Array
SAN
Tape
Library
train1
192.168.XX.101
train2
192.168.XX.102
train3
192.168.XX.103
train4
192.168.XX.104
train12
192.168.XX.112
train11
192.168.XX.111
train10
192.168.XX.110
train9
192.168.XX.109
LANLAN
train5
192.168.XX.105
train6
192.168.XX.106
train8
192.168.XX.108
train7
192.168.XX.107
Hub/Switch
Hub/Switch
Hub/Switch
Hub/Switch
Hub/Switch
Hub/Switch
Software Share
192.168.XX.100

B
6 Test connectivity to your partner’s system on the public network.
1 Check the PATH environment variable. If necessary, add the /sbin, /usr/
sbin, /opt/VRTS/bin, and /opt/VRTSvcs/bin directories to your
PATH environment variable.
2 Check the VERITAS licenses to determine whether a VERITAS Cluster Server
license is installed.
When you install any Storage Foundation product or VERITAS Volume
Replicator, the VRTSalloc package (the VERITAS Volume Manager Intelligent
Storage Provisioning feature) requires that the following Red Hat packages are
installed:
• compat-gcc-c++-7.3-2.96.128
• compat-libstdc++-7.3-2.96.128
Version 7.3-2.96.128 is provided with Red Hat Enterprise Linux 3 Update 2 (i686).
To determine whether these library versions are installed, type:
# rpm -qi compat-gcc-c++
# rpm -qi compat-libstdc++
Other Checks
Checking Packages—Linux Only

Verify that ssh configuration files are set up in order to install VCS on Linux or to
run remote commands without prompts for passwords.
If you do not configure ssh, you are required to type in the root passwords for all
systems for every remote command issued during the following services
preparation lab and the installation procedure.
To configure ssh:
1 Log on to your system.
2 Generate a DSA key pair on this system by running the following command:
ssh-keygen -t dsa
3 Accept the default location of ~/.ssh/id_dsa.
4 When prompted, do not enter a passphrase.
5 Change the permissions of the .ssh directory by typing:
# chmod 755 ~/.ssh
6 The file ~/.ssh/id_dsa.pub contains a line beginning with ssh_dss and
ending with the name of the system on which it was created.
a Copy this line to the /root/.ssh/authorized_keys2 file on all
systems where VCS is to be installed.
b Ensure that you copy the line to the other systems in your cluster.
c To ensure easy accessibility, include all of the ssh_dss lines in the
authorized_keys2 file on each system in the cluster. This allows
commands to be run from any system to any system.
Configuring Secure Shell—Linux Only

B
If you do not want to use ssh with automatic login using saved passphrases on a
regular basis, run the following commands at the command line. This is in effect
only for this session.
exec /usr/bin/ssh-agent $SHELL
ssh-add
To save your passphrase during your GNOME session, follow these steps:
1 The openssh-askpass-gnome package should be loaded on your system.
To confirm this, type:
rpm -q openssh-askpass-gnome
If it is not installed, see your instructor.
2 If you do not have a $HOME/.Xclients file (you should not have one after
installation), run switchdesk to create it. In your $HOME/.Xclients file,
edit the following:
exec $HOME/.Xclients-default
Change the line so that it reads:
exec /usr/bin/ssh-agent $HOME/.Xclients-default
3 From the Red Hat icon, select Preferences—>More Preferences—>Sessions.
a Click the Startup Programs Tab and Add and enter /usr/bin/ssh-add
in the Startup Command text area.
b Set the priority to a number higher than any existing commands to ensure
that it is executed last. A good priority number for ssh-add is 70 or
higher. The higher the priority number, the lower the priority. If you have
other programs listed, this one should have the lowest priority.
c Click OK to save your settings, and exit the GNOME Control Center.
4 Log out and then log back into GNOME; in other words, restart X.
After GNOME is started, a dialog box is displayed, prompting for your
passphrases. Enter the passphrase requested. If you have both DSA and RSA
key pairs configured, you are prompted for both. From this point on, you
should not be prompted for a password by ssh, scp, or sftp.
For more information, see the Linux Customization Guide.

1 Open a console window so you can observe messages during later labs.
a Select Run from the main menu or Gnome foot icon.
b Type this command:
xterm -C -fg white -bg black -sl 2000 &
This opens a console window with a white foreground, a black background,
and a scroll line buffer of 2000 lines.
2 Open a System Log Display tool.
From the RedHat icon, select System Tools—>System Logs.
Setting Up a Console Window—Linux Only

Lab 3: Installing VCS B–11
B

In this lab, you work with your lab partner to install VCS on both systems.
• “Lab 3 Synopsis: Installing VCS,” page A-6
• “Lab 3 Solutions: Installing VCS,” page C-13
Use the following table to collect information you need to install VCS. Your
instructor may also ask you to install VERITAS Volume Manager and VERITAS
File System.
train1 train2
# ./installer# ./installer
vcs1vcs1
Link 1:______
Link 2:______
Software
location:_______________________________
Subnet:_______
Link 1:______
Link 2:______
Public:______ Public:______
4.x4.x
# ./installvcs# ./installvcsPre-4.0Pre-4.0

B
VCS.
Node names, cluster
name, and cluster ID
train1
train2
vcs1
1
Cluster interconnect Ethernet interface for
Solaris: qfe0
Sol Mob: dmfe0
AIX: en2
HP-UX lan1
Linux: eth1
VA: bge2
Ethernet interface for
Solaris: qfe1
Sol Mob: dmfe1
AIX: en3
HP-UX lan2
Linux: eth2
VA: bge3
Public network
interface
interface
Solaris: eri0
Sol Mob: dmfe0
AIX: en1
HP-UX lan0
Linux: eth0
VA: bge0

Web GUI IP Address:
train1 train2
train3 train4
train5 train6
train7 train8
train9 train10
train11 train12
Subnet Mask
Network interface
NetworkHosts (HP-UX
only)
192.168.xxx.91
192.168.xxx.92
192.168.xxx.93
192.168.xxx.94
192.168.xxx.95
192.168.xxx.96
255.255.255.0
Solaris: eri0
Sol Mob: dmfe0
AIX: en0
HP-UX lan0
Linux: eth0
VA: bge0
see instructor
Installation software
location
install_dir
License
Administrator account Name
Password
admin
password
VCS.

B
1 Obtain the location of the installation software from your instructor.
____________________________________________________________
2 This step is to be performed from only one system in the cluster. The install
script installs and configures all systems in the cluster.
a Change to the install directory.
b Run the installer script (VERITAS Product Installer) located in the
directory specified above.
Notes:
› For VCS 4.x, install Storage Foundation HA (which includes VCS,
Volume Manager, and File System).
› Use the information in the previous table or design worksheet to
respond to the installation prompts.
› Sample prompts and input are provided at the end of the lab solution in
Appendix C.
› For versions of VCS before 4.0, use installvcs.
c If a license key is needed, obtain one from your instructor and record it
here.
License Key: _________________________________
d Install all optional packages (including Web console and Simulator).
e Accept the default of Y to configure VCS.
f Do not configure a third heartbeat link at this time.
g Do not configure a low-priority heartbeat link at this time.
h Do not configure VERITAS Security Services.
i Do not set any user names or passwords.
j Retain the default admin user account and password.
Installing VERITAS Cluster Server Software

k Configure the Cluster Server Cluster Manager.
l Do not configure SMTP Notification.
m Do not configure SNMP Notification.
n Select the option to install all packages simultaneously on all systems.
o Do not set up enclosure-based naming for Volume Manager.
p Start Storage Foundation Enterprise HA processes.
q Do not set up a default disk group.
3 If you did not install the Java GUI package as part of the installer (CPI)
process (or installvcs for earlier versions of VCS), install the VRTScscm
Java GUI package on each system in the cluster. The location of this package is
in the pkgs directory under the install location directory given to you by your
instructor.

B
1 If your instructor indicates that additional software, such as VCS patches or
updates, is required, obtain the location of the installation software from your
instructor.
_______________________________________
install_dir
2 Install any VCS patches or updates, as directed by your instructor. Use the
operating system-specific command, as shown in the following examples.
Solaris
pkgadd -d /install_dir/pkgs VRTSxxxx
HP
swinstall -s /install_dir/pkgs VRTSxxxx
AIX
installp -a -d /install_dir/pkgs/VRTSxxxx.rte.bff
VRTSxxxx.rte
Linux
rpm -ihv VRTSxxxx-x.x.xx.xx-GA_RHEL.i686.rpm
3 Install any other software indicated by your instructor. For example, if your
classroom uses VCS 3.5, you may be directed to install VERITAS Volume
Manager and VERITAS File System.
Installing Other Software

1 Verify that VCS is now running using hastatus.
If hastatus -sum shows the cluster systems in a running state and a
ClusterService service group is online on one of your cluster systems, VCS has
been properly installed and configured.
2 Perform additional verification (generally only necessary if there is a problem
displayed by hastatus -sum).
a Verify that all packages are loaded.
b Verify that LLT is running.
c Verify that GAB is running.
Viewing VERITAS Cluster Server Installation Results

B
View the configuration files set up by the VCS installation procedure.
1 Explore the LLT configuration.
a Verify that the cluster ID, system names, and network interfaces specified
during install are present in the /etc/llttab file.
b Verify the system names in the /etc/llthosts file.
2 Explore the GAB configuration.
Verify that the number of systems in the cluster matches the value for the
-n flag set in the /etc/gabtab file.
3 Explore the VCS configuration files.
Verify the cluster name, system names, and IP address for the Cluster Manager
in the /etc/VRTSvcs/conf/config/main.cf file.
Exploring the Default VCS Configuration

Verify GUI connectivity with the Java GUI and the Web GUI. Both GUIs can
connect to the cluster with the default user of admin and password as the default
password.
1 Use a Web browser to connect to the Web GUI.
– The URL is http://ipaddress:8181/vcs.
– The IP address is given in the design worksheet and was entered during
installation to configure the Cluster Manager.
2 Start the Java GUI and connect to the cluster using these values:
– Cluster alias: nameCluster
– Host name: ip_address (used during installation)
– Failover retries: 12 (retain default)
3 Browse the cluster configuration.
Verifying Connectivity with the GUIs

Lab 4: Using the VCS Simulator B–21
B

This lab uses the VERITAS Cluster Server Simulator and the Cluster Manager
Java Console. You are provided with a preconfigured main.cf file to learn about
managing the cluster.
• “Lab 4 Synopsis: Using the VCS Simulator,” page A-18
• “Lab 4 Solutions: Using the VCS Simulator,” page C-35
Use the following table to record the values for your classroom.
Attribute Sample Value Your Value
Port 15559
VCS user account/
password
oper/oper
1. Start the Simulator Java GUI.
hasimgui &
2. Add a cluster.
3. Copy the preconfigured
main.cf file to the new
directory.
4. Start the cluster from the
Simulator GUI.
5. Launch the Cluster Manager
Java Console
6. Log in using the VCS
account oper with password
oper.
This account demonstrates
different privilege levels in
VCS.
See next slide for classroom values
See next slide for lab assignments.See next slide for lab assignments.

B
File Locations
Type of File Location
Lab main.cf file
cf_files_dir
Local Simulator
config directory
sim_config_dir

1 Add /opt/VRTScssim/bin to your PATH environment variable after any
/opt/VRTSvcs/bin entries, if it is not already present.
2 Set the VCS_SIMULATOR_HOME environment variable to /opt/
VRTScssim, if it is not already set.
3 Start the Simulator GUI.
4 Add a cluster.
5 Use these values to define the new simulated cluster:
– Cluster Name: vcs_operations
– System Name: S1
– Port: 15559
– Platform: Solaris
– WAC Port: -1
6 In a terminal window, change to the simulator configuration directory for the
new simulated cluster named vcs_operations.
Specify this directory in place of sim_config_dir variable elsewhere in
the lab.
7 Copy the main.cf, types.cf, and OracleTypes.cf files provided by
your instructor into the vcs_operations simulation configuration directory.
Source location of main.cf, types.cf, and OracleTypes.cf files:
___________________________________________
cf_files_dir
8 From the Simulator GUI, start the vcs_operations cluster.
9 Launch the VCS Java Console for the vcs_operations simulated cluster.
Starting the Simulator on UNIX

B
10 Log in as oper with password oper.
Note: While you may use admin/password to log in, the point of using oper is to
demonstrate the differences in privileges between VCS user accounts.

1 How many systems are members of the cluster?
2 Determine the status of all service groups.
3 Which service groups have service group operator privileges set for the oper
account?
4 Which resources in the AppSG service group have the Critical resource
attribute enabled?
5 Which resource is the top-most parent in the OracleSG service group?
6 Which immediate child resources does the Oracle resource in the OracleSG
service group depend on?
Viewing Status and Attributes
Service Group Status on S1 Status on S2 Status on S3
AppSG
OracleSG
ClusterService

B
1 Attempt to take the ClusterService group offline on S1.
What happens?
2 Attempt to take the AppSG service group offline on S1.
What happens?
3 Attempt to take the Oracle service group offline on S1.
What happens?
4 Take all service groups that you have privileges for offline everywhere.
5 Bring the AppSG service group online on S2.
6 Bring the OracleSG service group online on S1.
7 Switch service group AppSG to S1.
8 Switch the OracleSG service group to S2.
9 Bring all service groups that you have privileges for online on S3.
Manipulating Service Groups

1 Attempt to take the OraListener resource in OracleSG offline on S3.
What happens to the OracleSG service group?
2 Bring the OraListener resource online on S3.
3 Attempt to take the OraMount resource offline on system S3.
What happens?
4 Attempt to bring only the OraListener resource online on S1.
What happens?
5 Fault the Oracle (oracle) resource in the OracleSG service group.
6 What happens to the service group and resource?
7 View the log entries to see the sequence of events.
8 Attempt to switch the OracleSG service group back to S3.
What happens?
9 Clear the fault on the Oracle resource in the OracleSG service group.
10 Switch the OracleSG service group back to S3.
11 Save and close the configuration.
12 Log off from the GUI.
13 Stop the simulator.
Manipulating Resources

Lab 5: Preparing Application Services B–29
B

The purpose of this lab is to prepare the loopy process service for high availability.
• “Lab 5 Synopsis: Preparing Application Services,” page A-24
• “Lab 5 Solutions: Preparing Application Services,” page C-51
Lab Assignments
Fill in the table with the applicable values for your lab cluster.
your_sys
train1
their_sys
train2
Name prefix for your
objects
name
Disk assignment for disk
group: disk_dev
Solaris: c#t#d#
AIX: hdisk##
HP-UX: c#t#d#
Linux: sd##
Disk group name nameDG1
disk1
bobDG1
/bob1 bobVol1
disk2
sueDG1
sueVol1 /sue1
NIC
IP Address
while true
do
echo “…”
done
/bob1/loopy
Disk/Lun Disk/Lun
NIC
IP Address
while true
do
echo “…”
done
/sue1/loopy
See next slide for classroom values.See next slide for classroom values.

B
Volume name nameVol1
Mount point /name1
Public network interface:
interface
Solaris: eri0
Sol Mob: dmfe0
AIX: en1
HP-UX lan0
Linux: eth0
VA bge0
IP Address
ipaddress
train1 192.168.xxx.51
train2 192.168.xxx.52
train3 192.168.xxx.53
train4 192.168.xxx.54
train5 192.168.xxx.55
train6 192.168.xxx.56
train7 192.168.xxx.57
train8 192.168.xxx.58
train9 192.168.xxx.59
train10 192.168.xxx.60
train11 192.168.xxx.61
train12 192.168.xxx.62
Application script location
class_sw_dir

1 Verify disk availability for Volume Manager.
2 Determine whether any disks are already in use in disk groups.
3 Initialize a disk for Volume Manager using the disk device from the worksheet.
4 Create a disk group with the name from the worksheet using the initialized
disk.
5 Create a 2 GB volume in the disk group.
6 Create a vxfs file system on the volume.
7 Create a mount point on each system in the cluster.
8 Mount the file system on your cluster system.
9 Verify that the file system is mounted on your system.
Configuring Storage for an Application

B
Complete the following steps to set up a virtual IP address for the application.
1 Verify that an IP address exists on the base interface for the public network.
2 Configure a virtual IP address on the public network interface. Use the IP
address from the design worksheet.
3 Verify that the virtual IP address is configured.
Configuring Networking for an Application

A script named loopy is used as the example application for this lab exercise.
1 Obtain the location of the loopy script from your instructor.
loopy script location:
__________________________________________________________
2 Copy or type this code to a file named loopy on the file system you created
previously in this lab.
3 Verify that you have a console window open to see the display from the script.
4 Start the loopy application in the background.
5 Verify that the loopy application is working correctly.
Setting up the Application

B
Complete the following steps to migrate the application to the other system.
1 Stop your loopy process by sending a kill signal. Verify that the process is
stopped.
2 Remove the virtual IP address configured earlier in this lab. Verify that the IP
address is no longer configured.
3 Unmount your file system and verify that it is no longer mounted.
4 Stop the volume and verify that it is disabled.
5 Deport your disk group and verify that it is deported.
6 Log in to the other system.
7 Update VxVM so that the disk group is visible.
8 Import your disk group and verify that it imported.
9 Start your volume and verify that it is enabled.
10 Verify that your mount point directory exists. Create it if it does not exist.
11 Mount your file system and verify that it is mounted.
12 Configure your virtual IP address and verify that it is configured.
13 Start the loopy application and verify that it is running.
Manually Migrating the Application

Complete the following steps to bring the application offline on the other system
so that it is ready to be placed under VCS control.
1 While still logged into the other system, stop your loopy process by sending a
kill signal. Verify that the process is stopped.
2 Remove the virtual IP address configured earlier in this lab. Verify that the IP
address is no longer configured.
3 Unmount your file system and verify that it is no longer mounted.
4 Stop the volume and verify that it is disabled.
5 Deport your disk group and verify that it is deported.
Bringing the Services Offline

Lab 6: Starting and Stopping VCS B–37
B

The following procedure demonstrate how the cluster configuration changes states
during startup and shutdown, and shows how the .stale file works.
• “Lab 6 Synopsis: Starting and Stopping VCS,” page A-29
• “Lab 6 Solutions: Starting and Stopping VCS,” page C-63
Note: Complete this section with your lab partner.
1 Change to the /etc/VRTSvcs/conf/config directory.
2 Verify that there is no .stale file in the /etc/VRTSvcs/conf/config
directory. This file should not exist yet.
3 Open the cluster configuration.
4 Verify that the .stale file has been created in the directory,
/etc/VRTSvcs/conf/config.
5 Attempt to stop VCS using the hastop -all command.
train1 train2
# hastop –all -force# hastop –all -force
vcs1vcs1

Lab 6: Starting and Stopping VCS B–39
B
6 Stop the cluster using the hastop -all -force command from one system
only to stop VCS forcibly and leave the applications running.
7 Start VCS on each system in the cluster.
8 Verify the status of the cluster.
9 Why are all systems in the STALE_ADMIN_WAIT state?
10 Verify that the .stale file is present in the /etc/VRTSvcs/conf/config
directory. This file should exist.
11 Return all systems to a running state (from one system in the cluster).
12 Watch the console during the build process to see the LOCAL_BUILD and
REMOTE_BUILD system states.
13 Check the status of the cluster.
14 Verify that there is no .stale file in the /etc/VRTSvcs/conf/config
directory. This file should have been removed.

Lab 7: Online Configuration of a Service Group B–41
B
Lab 7: Online Configuration of a Service
Group

The purpose of this lab is to create a service group while VCS is running using
either the Cluster Manager graphical user interface or the command-line interface.
• “Lab 7 Synopsis: Online Configuration of a Service Group,” page A-31
• “Lab 7 Solutions: Online Configuration of a Service Group,” page C-67
Classroom-Specific Values
Fill in this table with the applicable values for your lab cluster.
Service group prefix
name
name
your_sys
train1
their_sys
train2
Lab 7: Online Configuration of a Service Group
Use the Java GUI to:
Create a service
group.
Add resources to
the service group
from the bottom of
the dependency
tree.
Substitute the
name you used to
create the disk
group and volume.

B
Fill in the design worksheet with values appropriate for your cluster and use the
information to create a service group.
1 If you are using the GUI, start Cluster Manager and log in to the cluster.
2 Open the cluster configuration.
3 Create the service group.
4 Modify the SystemList to allow the service group to run on the two systems
specified in the design worksheet.
5 Modify the AutoStartList attribute to allow the service group to start on your
system.
6 Verify that the service group can autostart and that it is a failover service group.
changes.
Creating a Service Group
Group nameSG1
Required Attributes
Optional Attributes

Complete the following steps to add NIC, IP, DiskGroup, Volume, and Process
resources to the service group using the information from the design worksheet.
1 Add the resource to the service group.
2 Set the resource to not critical.
3 Set the required attributes for this resource, and any optional attributes, if
needed.
4 Enable the resource.
Adding Resources to a Service Group
Adding an NIC Resource
Resource Type NIC
Required Attributes
Sol Mob: dmfe0
AIX: en1
HP-UX: lan0
Linux: eth0
VA: bge0
only)
Critical? No (0)
Enabled? Yes (1)

B
5 Verify that the resource is online. Because this is a persistent resource, you do
not need to bring it online.
changes.

Adding an IP Resource
Resource Type IP
Required Attributes
Sol Mob: dmfe0
AIX: en1
HP-UX: lan0
Linux: eth1
VA: bge0
Optional Attributes
Netmask 255.255.255.0
Critical? No (0)
Enabled? Yes (1)
System IP Address
train1 192.168.xx.51
train2 192.168.xx.52
train3 192.168.xx.53
train4 192.168.xx.54
train5 192.168.xx.55
train6 192.168.xx.56
train7 192.168.xx.57
train8 192.168.xx.58
train9 192.168.xx.59
train10 192.168.xx.60
train11 192.168.xx.61
train12 192.168.xx.62

B
1 Add the resource to the service group.
needed.
5 Bring the resource online on your system.
6 Verify that the resource is online.
changes.

1 Add the resource to the service group using either the GUI or CLI.
needed.
6 Verify that the resource is online in VCS and at the O/S level.
changes.
Adding a DiskGroup Resource
Required Attributes
DiskGroup nameDG1
Optional Attributes
StartVolumes 1
StopVolumes 1
Critical? No (0)
Enabled? Yes (1)

B
needed.
6 Verify that the resource is online in VCS and at the operating system level.
changes.
Adding a Volume Resource
Required Attributes
Volume nameVol1
DiskGroup nameDG1
Critical? No (0)
Enabled? Yes (1)

needed.
changes.
Adding a Mount Resource
Resource Type Mount
Required Attributes
MountPoint /name1
FSType vxfs
FsckOpt -y
Critical? No (0)
Enabled? Yes (1)

B
needed.
5 Ensure that you have the console or a terminal window open for loopy output.
changes.
Adding a Process Resource
Required Attributes
PathName /bin/sh
Optional Attributes
Critical? No (0)
Enabled? Yes (1)

1 Link resource pairs together based on the design worksheet.
2 Verify that the resources are linked properly.
changes.
Linking Resources in the Service Group
nameVol1 nameDG1
nameMount1 nameVol1
nameIP1 nameNIC1

B
Complete the following steps to test the service group on each system in the
service group SystemList.
1 Test the service group by switching away from your system in the cluster.
2 Verify that the service group came online properly on their system.
3 Test the service group by switching it back to your system in the cluster.
4 Verify that the service group came online properly on your system.
Testing the Service Group

havcs-410-101 a-2-10-srt-pg_2

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à havcs-410-101 a-2-10-srt-pg_2

Similaire à havcs-410-101 a-2-10-srt-pg_2 (20)

Dernier

Dernier (20)

havcs-410-101 a-2-10-srt-pg_2