Sun Cluster 3.0 5/02 Supplement

Configuring the Cluster

The following information applies to this update release and all subsequent updates.

How to Add Cluster File Systems (5/02)

The following changes to Step 2, Step 4, and Step 8 were introduced in the Sun Cluster 3.0 5/02 update release and apply to this update and all subsequent updates to Sun Cluster 3.0 software.

Perform this procedure for each cluster file system you add.


Caution - Caution -

Any data on the disks is destroyed when you create a file system. Be sure you specify the correct disk device name. If you specify the wrong device name, you will erase data that you might not intend to delete.


If you used SunPlex Manager to install data services, one or more cluster file systems already exist if there were sufficient shared disks on which to create the cluster file systems.

  1. Ensure that volume manager software is installed and configured.

    For volume manager installation procedures, see "Installing and Configuring Solstice DiskSuite Software" or "Installing and Configuring VxVM Software" in the Sun Cluster 3.0 12/01 Software Installation Guide.

  2. Do you intend to install VERITAS File System (VxFS) software?

    • If no, go to Step 3.

    • If yes, perform the following steps.

    1. Follow the procedures in your VxFS installation documentation to install VxFS software on each node of the cluster.

    2. In the /etc/system file on each node, change the setting value for the following entry from 0x4000 to 0x6000.


      set rpcmod:svc_default_stksize=0x6000

      Sun Cluster software requires a minimum default stack size setting of 0x6000. Because VxFS installation changes this setting to 0x4000, you must manually change it back to 0x6000 after VxFS installation is complete.

  3. Become superuser on any node in the cluster.


    Tip ( only) -

    For faster file system creation, become superuser on the current primary of the global device you create a file system for.


  4. Create a file system.

    • For a VxFS file system, follow procedures provided in your VxFS documentation.

    • For a UFS file system, use the newfs(1M) command.


      # newfs raw-disk-device
      

    The following table shows examples of names for the raw-disk-device argument. Note that naming conventions differ for each volume manager.

    Table 4-3 Sample Raw Disk Device Names

    Volume Manager 

    Sample Disk Device Name 

    Description 

    Solstice DiskSuite 

    /dev/md/oracle/rdsk/d1

    Raw disk device d1 within the oracle diskset

    VERITAS Volume Manager 

    /dev/vx/rdsk/oradg/vol01

    Raw disk device vol01 within the oradg disk group

    None 

    /dev/global/rdsk/d1s3

    Raw disk device d1s3

  5. On each node in the cluster, create a mount-point directory for the cluster file system.

    A mount point is required on each node, even if the cluster file system will not be accessed on that node.


    Tip ( only) -

    For ease of administration, create the mount point in the /global/device-group directory. This location enables you to easily distinguish cluster file systems, which are globally available, from local file systems.



    # mkdir -p /global/device-group/mountpoint
    
    device-group

    Name of the directory that corresponds to the name of the device group that contains the device

    mountpoint

    Name of the directory on which to mount the cluster file system

  6. On each node in the cluster, add an entry to the /etc/vfstab file for the mount point.

    1. Use the following required mount options.

      Logging is required for all cluster file systems.

      • Solaris UFS logging - Use the global,logging mount options. See the mount_ufs(1M) man page for more information about UFS mount options.


        only -

        The syncdir mount option is not required for UFS cluster file systems. If you specify syncdir, you are guaranteed POSIX-compliant file system behavior for the write() system call, in the sense that if a write() succeeds you are guaranteed that there is space on disk. If you do not specify syncdir, you will have the same behavior that is seen with UFS file systems. When you do not specify syncdir, performance of writes that allocate disk blocks, such as when appending data to a file, can significantly improve. However, in some cases, without syncdir you would not discover an out-of-space condition (ENOSPC) until you close a file. The case in which you will see ENOSPC on close is only during a very short time period after a failover. With syncdir (and POSIX behavior), the out-of-space condition would be discovered before the close.


      • Solstice DiskSuite trans metadevice - Use the global mount option (do not use the logging mount option). See your Solstice DiskSuite documentation for information about setting up trans metadevices.

      • VxFS logging - Use the global, log mount options. See the mount_vxfs(1M) man page for more information about VxFS mount options.

    2. To automatically mount the cluster file system, set the mount at boot field to yes.

    3. Ensure that, for each cluster file system, the information in its /etc/vfstab entry is identical on each node.

    4. Ensure that the entries in each node's /etc/vfstab file list devices in the same order.

    5. Check the boot order dependencies of the file systems.

      For example, consider the scenario where phys-schost-1 mounts disk device d0 on /global/oracle, and phys-schost-2 mounts disk device d1 on /global/oracle/logs. With this configuration, phys-schost-2 can boot and mount /global/oracle/logs only after phys-schost-1 boots and mounts /global/oracle.

    See the vfstab(4) man page for details.

  7. On any node in the cluster, verify that mount points exist and /etc/vfstab file entries are correct on all nodes of the cluster.


    # sccheck
    

    If no errors occur, nothing is returned.

  8. From any node in the cluster, mount the cluster file system.


    # mount /global/device-group/mountpoint
    


    only -

    For VERITAS File System (VxFS), mount the file system from the current master of device-group to ensure that the file system mounts successfully. In addition, unmount a VxFS file system from the current master of device-group to ensure that the file system unmounts successfully.


  9. On each node of the cluster, verify that the cluster file system is mounted.

    You can use either the df(1M) or mount(1M) command to list mounted file systems.

    To manage a VxFS cluster file system in a Sun Cluster environment, run administrative commands only from the primary node on which the VxFS cluster file system is mounted.

  10. Are your cluster nodes connected to more than one public subnet?

    • If yes, go to "How to Configure Additional Public Network Adapters" in the Sun Cluster 3.0 12/01 Software Installation Guide to configure additional public network adapters.

    • If no, go to "How to Configure Public Network Management (PNM)" in the Sun Cluster 3.0 12/01 Software Installation Guideto configure PNM and set up NAFO groups.

Example-Creating a Cluster File System

The following example creates a UFS cluster file system on the Solstice DiskSuite metadevice /dev/md/oracle/rdsk/d1.


# newfs /dev/md/oracle/rdsk/d1
...
 
(on each node)
# mkdir -p /global/oracle/d1
# vi /etc/vfstab
#device           device        mount   FS      fsck    mount   mount
#to mount         to fsck       point   type    pass    at boot options
#                       
/dev/md/oracle/dsk/d1 /dev/md/oracle/rdsk/d1 /global/oracle/d1 ufs 2 yes global,logging
(save and exit)
 
(on one node)
# sccheck
# mount /global/oracle/d1
# mount
...
/global/oracle/d1 on /dev/md/oracle/dsk/d1 read/write/setuid/global/logging/
largefiles on Sun Oct 3 08:56:16 2000

How to Update Network Time Protocol (NTP) (5/02)

The following change was introduced in the Sun Cluster 3.0 5/02 update release and applies to this update and all subsequent updates to Sun Cluster 3.0 software.

Perform this task to create or modify the NTP configuration file after you install Sun Cluster software. You must also modify the NTP configuration file when you add a node to an existing cluster and when you change the private hostname of a node in the cluster.


only -

The primary requirement when you configure NTP, or any time synchronization facility within the cluster, is that all cluster nodes must be synchronized to the same time. Consider accuracy of time on individual nodes to be of secondary importance to the synchronization of time among nodes. You are free to configure NTP as best meets your individual needs, as long as this basic requirement for synchronization is met. See Sun Cluster 3.0 12/01 Concepts for further information about cluster time. See the /etc/inet/ntp.cluster template file for additional guidelines on how to configure NTP for a Sun Cluster configuration.


  1. Did you install your own /etc/inet/ntp.conf file before you installed Sun Cluster software?

    • If yes, you do not need to modify your ntp.conf file. Skip to Step 8.

    • If no, go to Step 2.

  2. Become superuser on a cluster node.

  3. Do you have your own /etc/inet/ntp.conf file to install on the cluster nodes?

    • If yes, copy your /etc/inet/ntp.conf file to each node of the cluster, then skip to Step 6.


      only -

      All cluster nodes must be synchronized to the same time.


    • If no, go to Step 4 to edit the /etc/inet/ntp.conf.cluster file. Sun Cluster software creates this file as the NTP configuration file if an /etc/inet/ntp.conf file is not found during Sun Cluster installation. Do not rename the ntp.conf.cluster file as ntp.conf.

  4. On one node of the cluster, edit the private hostnames in the /etc/inet/ntp.conf.cluster file.

    If /etc/inet/ntp.conf.cluster does not exist on the node, you might have an /etc/inet/ntp.conf file from an earlier installation of Sun Cluster software. If so, perform the following edits on that ntp.conf file.

    1. Ensure that an entry exists for the private hostname of each cluster node.

    2. Remove any unused private hostnames.

      If the ntp.conf.cluster file contains non-existent private hostnames, when a node is rebooted the system will generate error messages when the node attempts to contact those non-existent private hostnames.

    3. If you changed a node's private hostname, ensure that the NTP configuration file contains the new private hostname.

    4. If necessary, make other modifications to meet your NTP requirements.

  5. Copy the NTP configuration file to all nodes in the cluster.

    The contents of the ntp.conf.cluster file must be identical on all cluster nodes.

  6. Stop the NTP daemon on each node.

    Wait for the stop command to complete successfully on each node before you proceed to Step 7.


    # /etc/init.d/xntpd stop
    

  7. Restart the NTP daemon on each node.

    • For ntp.conf.cluster, run the following command.


      # /etc/init.d/xntpd.cluster start
      

      The xntpd.cluster startup script first looks for the /etc/inet/ntp.conf file. If that file exists, the script exits immediately without starting the NTP daemon. If ntp.conf does not exist but ntp.conf.cluster does exist, the NTP daemon is started using ntp.conf.cluster as the NTP configuration file.

    • For ntp.conf, run the following command.


      # /etc/init.d/xntpd start
      

  8. Do you intend to use Sun Management Center to configure resource groups or monitor the cluster?

    • If yes, go to "Installing the Sun Cluster Module for Sun Management Center" in the Sun Cluster 3.0 12/01 Software Installation Guide.

    • If no, install third-party applications, register resource types, set up resource groups, and configure data services. See the documentation supplied with the application software and the Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide.

How to Start Sun Management Center (5/02)

The following change was introduced in the Sun Cluster 3.0 5/02 update release and applies to this update and all subsequent updates to Sun Cluster 3.0 software.

After Step 2 - Perform the following step after Step 2, as the new Step 3. The original Step 3 becomes the new Step 4.

    On each Sun Management Center agent machine (cluster node), ensure that the scsymon_srv daemon is running.


    # ps -ef | grep scsymon_srv
    

    If any cluster node is not already running the scsymon_srv daemon, start the daemon on that node.


    # /usr/cluster/lib/scsymon/scsymon_srv