Issue #9 July 2005

Features

From the Inside

In each Issue

Feedback

Tips & tricks

Red Hat's customer service team receives technical support questions from users all over the world. As they are received, Red Hat technicians add the questions and answers to the Red Hat Knowledgebase on a daily basis. Individuals with a redhat.com login are granted access. Every month, Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries.

Tips from RHCEs

Avoiding user shutdown and reboot

by Masatake Yamato, RHCE

To avoid user shutdown and reboot from the Action menu, the gdm screen, or from consoles, follow these three tips:

To prevent these actions from occurring through the Action menu, run the gconf-editor program on the GNOME desktop, and check off the entry for /apps/gnome-session/options/logout_prompt.
To prevent these actions from occurring at the gdm screen, edit the /etc/X11/gdm/gdm.conf file, and set the SystemMenu directive to false.
To prevent these actions from occurring at the console, rename the reboot, poweroff, and halt files under the /etc/security/console.apps/ directory.

Why am I getting the message `lock_gulm: ERROR Got a -111 trying to login to lock_gulmd` in my `/var/log/messages` file of in one of our GFS cluster node?

by Michael Napolis

The error message corresponds to the GFS cluster node being unnecessarily fenced due to heavy network traffic load. To resolve this issue, increase the GFS heartbeat_rate and allowed_misses values in the cluster.ccs and set it closer to the defaults.

Example cluster.ccs:

cluster { 
         name = "alpha" 
         lock_gulm { 
             servers = ["n01", "n02", "n03"] 
             heartbeat_rate = 15
             allowed_misses = 2
         } 
}

heartbeat_rate is the rate, in seconds, at which a lock server checks heartbeats. The default value is 15.

allowed_misses is how many consecutive heartbeats can be missed before a node is marked as expired. The default value is 2.

For more information, refer to the Red Hat GFS documentation.

Does Red Hat Cluster Suite support software RAID (like Veritas and HP)?

by John Berninger

At the present time, software RAID drivers are not supported in the Red Hat Cluster Suite (RHCS) due to state maintenance issues between nodes.

The present versions of mdadm and RHCS are unable to transfer state information from one node to another in a cluster, so the node not actively using the file system is unable to determine the status of the RAID in case of a fence or STONITH operation. This inability could lead to file system corruption if a state is calculated incorrectly, which would likely be worse than not having the RAID in place in the beginning.

Red Hat engineers are working on a new volume manager, the Cluster Logical Volume Manager (CLVM), which will enable the use of LVM on shared storage. Once this work is complete, finalized testing and quality assurance will begin on making multi-pathed CLVM available for production use, which will act in place of software RAID in a cluster environment, providing similar functionality through different means.

Does Oracle support using Red Hat Global File System (GFS) with Oracle RAC (Real Application Clusters) software?

Yes! Oracle now officially supports customers who want to deploy Oracle® RAC with Red Hat GFS on Red Hat Enterprise Linux. Currently, the supported configuration is: Oracle 9i RAC, Red Hat GFS 6.0, and Red Hat Enterprise Linux 3. Visit Oracle's RAC Technologies Matrix for Linux Clusters for confirmation of this supported configuration.

Supported Configuration Details for Oracle 9i RAC and Red Hat GFS 6.0 (with Red Hat Enterprise Linux 3)

Red Hat Global File System (GFS) can be configured in several ways to support different levels of redundancy. GFS uses a centralized lock server daemon that can be configured as a single primary and multiple secondary server daemons on separate nodes (two or four secondary lock nodes). If the primary lock server fails, one of the secondary lock servers that has been keeping an updated copy of the lock state becomes the primary lock server. In this manner single node lock server failures can be tolerated.

For mission-critical Oracle RAC environments, Oracle supports an external lock server configuration with dedicated lock server nodes. The external lock server configuration allows you to reboot, remove, or add Oracle RAC server nodes without affecting lock manager availability and hence the operation of other nodes in the Oracle RAC cluster. Optionally, for higher levels of redundancy, networking redundancy can also be introduced to allow networking failures (both partial and complete) to happen without halting Oracle grid operations completely. Networking redundancy can take the form of Ethernet channel bonding (tolerates Ethernet HBA, cable and network failures) or virtual IP addressing which will tolerate failures at the router level.

Note:: Red Hat does not charge for Red Hat GFS nodes that are used only for the external lock server configuration (both primary and secondary nodes) and therefore do not read/write to the Red Hat GFS file system.

Red Hat GFS also supports an embedded lock server configuration, which allows the lock server daemons (both primary and secondary) to be run directly on nodes that mount and access (read/write) the GFS file system. Embedded lock server configurations are NOT currently supported by Oracle for use with Oracle RAC.

More information about Red Hat GFS and lock server configurations can be found at:

For details on configuring Red Hat GFS with Oracle 9i RAC, refer to this month's article Red Hat Global File System now supported with Oracle RAC.

Does a dedicated lock server require access to the shared storage?

by Chris Vanhoof

No. A dedicated server does not require access to the shared storage. The lock server would coordinate the lock traffic with the storage cluster nodes over the IP network.

If your dedicated lock server does have access to the shared storage, ccsd can be started using the path to the cca archive stored locally rather than to a assembled pool device.

How do I tell what hard drives are part of the volume group that makes up my logical volume?

by Sean Boyd

Using Logical Volume Management (LVM) adds an extra layer of administrative overhead to system administration. Generally, once a volume group is created you do not have to worry about it again. However, what if you now find yourself needing to resize a volume group or have just taken over administering a machine you did not configure. You will need to determine what physical devices are a part of a volume group and how much size is remaining.

Use the steps below to determine what physical devices are a part of a volume group.

Find out what file systems are mounted with LVM. Running the command mount in a terminal will show output similar to below:

/dev/hda2 on / type ext3 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
/dev/hda1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)
/dev/VolGroup/LVM on /data type ext3 (rw)

From the above output you can determine what the volume group name is, VolGroup. Now go to the directory /proc/lvm/VGs/<volume group name>/PVs. In this particular case the directory would be /proc/lvm/VGs/VolGroup/PVs. Once in the directory run ls to view the hard drives that are apart of that particular volume group.
```
ls /proc/lvm/VGs/VolGroup/PVs
hda12
```
From the output above hda12 is the only partition used for this volume group

This can be confirmed by running the pvscan command. Running pvscan will provide output similar to below:

pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE   PV "/dev/hda12" of VG "SeanVolGroup" [64 MB / 0 free]
pvscan -- total: 1 [101.94 MB] / in use: 1 [101.94 MB] / in no VG: 0 [0]