Virtual TapeServer 6.04.03 Operations and Administration Guide
| 155
8. Reboot VTS. If no errors are displayed, it is safe to reboot VTS now that the node has been
removed from the GFS cluster. After reboot, you may need to manually rejoin 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 51% of
the servers up for the cluster to function.
Shutting down the cluster
1. Log in to ALL VTS servers in the cluster and issue the following command to unmount all
GFS vaults:
[root@VTS001 root]# service gfs stop
[root@VTS002 root]# service gfs stop
[root@VTS003 root]# service gfs stop
[root@VTS004 root]# service gfs stop
2. Shut down GFS on each server you wish to reboot by issuing these commands:
service ricci stop
service gfs stop
service clvmd stop
service cman stop
reboot
3. Verify the mounts by entering the following command on all VTS servers. In this example,
the command is shown on VTS001 only:
[root@VTS001 root]# df
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 step
4h on page 40 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