| Red Hat Docs > Manuals > Cluster Suite/GFS Manuals > |
| Red Hat GFS: Installing and Configuring Oracle9i RAC with GFS 6.0 | ||
|---|---|---|
| Prev | Chapter 2. Installing and Configuring GFS | Next |
Setting up the GFS configuration consists of creating the GFS CCS configuration files, creating a CCA from the configuration files, and starting the CCS daemon, ccsd, for each node. This section describes how to create the configuration files, create the CCA for each node, and how to start ccsd. The files to be created and placed into a CCA are cluster.ccs, fence.ccs, and nodes.ccs.
![]() | Note |
|---|---|
When saving the configuration files, use the file name extension, .ccs. Keywords, case, and quotation marks are significant in the configuration files. Refer to the Red Hat GFS Administrator's Guide for GFS 6.0 for syntax rules. |
For the sample cluster in this manual (refer to Section 1.1 Sample Cluster), the configuration files are archived into a CCA that is either on shared storage or local storage, depending on whether a node is a GFS node or a lock-server node. For the GFS nodes (rac1, rac2, rac3, and rac4) the CCA is located in ccs_archive.pool on the shared storage. For the lock-server nodes (lock1, lock2, and lock3) the CCA is located in local.cca on the local storage of each lock-server node. (The lock-server nodes are not attached to the shared storage, and therefore cannot access the CCA on shared storage.)
This configuration has the following key characteristics:
Number of GFS nodes — 4, nodes rac1, rac2, rac3, and rac4
Number of lock server nodes — 3, nodes lock1, lock2, and lock3
Locking protocol — RLM, using LOCK_GULM
Fencing devices — 3 network power switches, each a WTI NPS
Cluster name — gfsrac
For more information about the cluster components, refer to Section 1.1 Sample Cluster.
To set up the GFS configuration, follow these steps:
Set up a temporary directory (for example, /root/GFS/ccstemp/) for the configuration files.
Create the following cluster.ccs file (refer to Example 2-11) and save it to the temporary directory.
Create the following fence.ccs file (refer to Example 2-12) and save it to the temporary directory.
### fence.ccs ########################################
fence_devices {
wti1 {
agent = "fence_wti"
ipaddr = "192.168.100.211"
login = "root"
passwd = "password"
}
wti2 {
agent = "fence_wti"
ipaddr = "192.168.100.212"
login = "root"
passwd = "password"
}
wti3 {
agent = "fence_wti"
ipaddr = "192.168.100.213"
login = "root"
passwd = "password"
}
}
|
Example 2-12. fence.ccs File
Create the following nodes.ccs file (refer to Example 2-13) and save it to the temporary directory.
#### nodes.ccs ######################################
nodes {
rac1.example.com {
ip_interfaces {
eth0 = "192.168.100.101"
}
fence {
power {
wti1 {
port = 1
}
}
}
}
rac2.example.com {
ip_interfaces {
eth0 = "192.168.100.102"
}
fence {
power {
wti1 {
port = 9
}
}
}
}
rac3.example.com {
ip_interfaces {
eth0 = "192.168.100.103"
}
fence {
power {
wti1 {
port = 10
}
}
}
}
rac4.example.com {
ip_interfaces {
eth0 = "192.168.100.104"
}
fence {
power {
wti1 {
port = 2
}
}
}
}
lock1.example.com {
ip_interfaces {
eth0 = "192.168.100.201"
}
fence {
power {
wti2 {
port = 1
}
}
}
}
lock2.example.com {
ip_interfaces {
eth0 = "192.168.100.202"
}
fence {
power {
wti2 {
port = 5
}
}
}
}
lock3.example.com {
ip_interfaces {
eth0 = "192.168.100.203"
}
fence {
power {
wti3 {
port = 4
}
}
}
}
} |
Example 2-13. nodes.ccs File
For the GFS nodes (rac1, rac2, rac3, and rac4), create a CCA on shared storage. At any GFS node, run the ccs_tool create command with the source as the configuration files in the temporary directory (for example, /root/GFS/ccstemp/) and the destination as /dev/pool/ccs_archive on the shared storage. For example:
rac1 # ccs_tool create /root/GFS/ccstemp/ /dev/pool/ccs_archive |
Start the CCS daemon, ccsd, on the GFS nodes as follows:
rac1 # ccsd -d /dev/pool/ccs_archive |
rac2 # ccsd -d /dev/pool/ccs_archive |
rac3 # ccsd -d /dev/pool/ccs_archive |
rac4 # ccsd -d /dev/pool/ccs_archive |
To store the CCA on the lock-server nodes, perform the following steps:
At each lock-server node, make a /root/GFS/ directory. For example:
# mkdir /root/GFS/ |
Using the scp command (or rsync), transfer cluster.ccs, fence.ccs, and nodes.ccs to /root/GFS/ in each lock-server node.
At each lock-server node, make a CCS build directory as follows:
# mkdir -p /etc/sistina/ccs-build/ |
At each lock-server node, create a local CCA file, local.cca, from the configuration files in /root/GFS as follows:
# ccs_tool create /root/GFS/ /etc/sistina/ccs-build/local.cca |
At each lock-server node, start ccsd using the CCA file, /etc/sistina/ccs-build/local.cca, as follows:
# ccsd -f /etc/sistina/ccs-build/local.cca |
![]() | Note |
|---|---|
If the CCA device on shared storage is updated, you must update the local CCA files in the lock-server nodes, and restart the lock-server nodes. |
![]() | Note |
|---|---|
This example configuration uses local CCA files for the lock-server nodes because those nodes do not have access to shared storage, where the CCA is maintained for the GFS nodes. As an alternative to using the local archive files in the lock-server nodes, you can export the CCA from the shared-storage CCA to the lock-server nodes. For additional information about configuring the CCA for external lock-server nodes that do not have access to shared storage, refer to the Red Hat GFS Administrator's Guide for GFS 6.0 and the ccsd(8) man page for Red Hat GFS 6.0. |
Proceed to Section 2.5 Starting the Lock Servers.