Skip Navigation Links | |
Exit Print View | |
Using Sun QFS and Sun Storage Archive Manager With Oracle Solaris Cluster Sun QFS and Sun Storage Archive Manager 5.3 Information Library |
1. Using SAM-QFS With Oracle Solaris Cluster
2. Requirements for Using SAM-QFS With Oracle Solaris Cluster
3. Configuring Sun QFS Local Failover File Systems With Oracle Solaris Cluster
4. Configuring Sun QFS Shared File Systems With Oracle Solaris Cluster
5. Configuring SAM-QFS Archiving in an Oracle Solaris Cluster Environment (HA-SAM)
6. Configuring Clients Outside of the Cluster
How to Configure the Metadata Server
How to Configure the File System Clients
Sample Configuration Files for Metadata Server
SPARC Oracle Solaris Client Network Configuration
AMD-64 RedHat Linux Client Network Configuration
/etc/nsswitch.conf File (SPARC and Linux Clients)
/etc/hostname.qfe1 File (SPARC Clients Only)
/etc/sysconfig/network-scripts/ifcfg-eth1 File (Linux Clients Only)
The following example configuration uses shared and local file system host files for this Sun QFS shared file system setup. To communicate with metadata clients that are outside the Oracle Solaris Cluster, you must establish the Sun QFS metadata traffic over the Sun QFS network. Because the metadata client is not a member of the Oracle Solaris Cluster configuration, use a logical host for this traffic. In the example configuration, sc-qfs1 is this host name.
The following example configuration files show a tested configuration that consists of four SPARC nodes and one AMD x64 node. These nodes are identified as follows:
|
Sample /etc/hosts File for All Nodes
Prepare /etc/hosts file on all nodes to append settings to existing /etc/hosts table.
### SC Cluster Nodes ### 129.152.4.57 ctelab30 # Cluster Node 129.152.4.58 ctelab31 # Cluster Node 129.152.4.59 ctelab32 # QFS Client Node 129.152.4.60 ctelab33 # QFS Client Node 129.152.4.55 ctelab28 # QFS Client Node ### SC Logical ### 192.168.4.100 sc-qfs1 ### QFS NET ### ## ctelab30 192.168.4.20 ctelab30-4 192.168.4.160 ctelab30-qfe1-test 192.168.4.210 ctelab30-qfe2-test 192.168.4.60 ctelab30-qfs ## ctelab31 192.168.4.21 ctelab31-4 192.168.4.161 ctelab31-qfe1-test 192.168.4.211 ctelab31-qfe2-test 192.168.4.61 ctelab31-qfs ## ctelab32 192.168.4.22 ctelab32-qfs ## ctelab33 192.168.4.23 ctelab33-qfs ## ctelab28 192.168.4.18 ctelab28-qfs
Ensure that the /etc/nsswitch.conf includes cluster. For example:
hosts: cluster files dns nis
Add the subnet used in your /etc/hosts file to the /etc/netmasks file. For example:
192.168.4.0 255.255.255.0
Identify the NIC port for qfe1 in the /etc/hostname.qfe1 file. For example:
ctelab30-4 netmask + broadcast + group qfs_ipmp1 up addif ctelab30-qfe1-test deprecated -failover netmask + broadcast + up
Identify the NIC port for qfe2 in the /etc/hostname.qfe2 file. For example:
ctelab30-qfe2-test netmask + broadcast + deprecated group qfs_ipmp1 -failover standby up
In this example, both SPARC and AMD-64 clients are used. SPARC clients run the Oracle Solaris OS and AMD-64 clients use the Linux OS.
qfe0 used for Public network (129.152.4.0)
qfe1 used for Sun QFS private network. (192.168.4.0)
bge0 used for Public network (129.152.4.0)
bge1 used for Sun QFS private network. (192.168.4.0)
Note - On the Linux OS, the NIC ports identified above are hardware address IDs and the OS identifies these as eth0,eth1 at the OS layer.
For the clients, make sure that cluster is not listed in the /etc/nsswitch.conf file. For example:
hosts: files dns nis
This file should contain the following:
ctelab32-4
This file should contain the following:
DEVICE=eth1 BOOTPROTO=static IPADDR=192.168.4.18 NETMASK=255.255.255.0 ONBOOT=yes TYPE=Ethernet