Virtual TapeServer 8.0 Configuration Guide

| 159
Shutting down the cluster
The following steps describe how to shut down your entire cluster. If you shut down half of the
servers, you need to shut down the entire cluster down. GFS requires that you have a quorum
of the servers up for the cluster to function.
1. Make sure that tape devices are stopped on the host server.
2. On each server you want to shutdown, perform these steps:
a. Log in as root.
b. Stop GFS and the supporting services:
service gfs stop
service ricci stop
service cman stop
service clvmd stop
reboot
Configuring GFS
To configure GFS, contact your authorized service and support representative to request
assistance. To configure VTS to use GFS, you must enable and configure intersystem
communication. See the EMS online help for more information. An Ethernet connection is
required between each Linux server (VTS servers and fencing resources). All servers must be
connected by Fibre Channel to a disk array. The switch and network cables do not need to be
Gigabit Ethernet. Refer to the Linux server documentation for more information about
configuring GFS.
Maintaining the file system
As with any file system, events may occur that result in incomplete or structurally incorrect
files. A possible root cause for such file damage is powering off the server while it is in use.
Therefore, it is a good idea to run a file system check on your GFS partitions every six to eight
months. The presence of damaged files can cause an issue, such as a kernel panic on the VTS
server. If the system message log (/var/log/messages) includes “kernel: Kernel panic”
messages, you should perform a file-system check as a recovery procedure. (The system
message log cannot be viewed using the VTS web interface. Use the less or more utility to
review this file.) Here is an example of the system message log; VAULT10 indicates an issue.
Jun 29 23:44:48 vts001 kernel: kjournald starting. Commit interval 5 seconds
Jun 29 23:44:48 vts001 kernel: EXT3-fs: mounted filesystem with ordered data
mode.
Jun 29 23:45:53 vts001 kernel: e20edb68 e20edba8 f8e887c7 f8e6e68c 00001000
00001000 e9166348 f8fbc000
Jun 29 23:45:53 vts001 kernel: e20edba0 f8e889c0 00000246 00000000 5566af80
e7ef76d8 00000005 00000002
Jun 29 23:45:53 vts001 kernel: e20edbe0 f8ea1786 f8ea8b2f f8ea8a64 000004cb
00000016 e7a73200 00000006
Jun 29 23:45:53 vts001 kernel: Call Trace: [<c010cc7a>] show_stack [kernel] 0x6a
Jun 29 23:45:53 vts001 kernel: [<c010cca2>] dump_stack [kernel] 0x12
Jun 29 23:45:53 vts001 kernel: [<f8e887c7>] gfs_asserti [gfs] 0x27
Jun 29 23:45:53 vts001 kernel: [<f8ea1786>] blkalloc_internal [gfs] 0x116
Jun 29 23:45:53 vts001 kernel: [<f8ea1bfe>] gfs_blkalloc [gfs] 0x7e
Jun 29 23:45:53 vts001 kernel: [<f8e7cec2>] get_datablock [gfs] 0xf2
Jun 29 23:45:53 vts001 kernel: [<f8e76abb>] get_block [gfs] 0xab