The following hardware requirements for installing Novell Cluster Services represent the minimum hardware configuration. Additional hardware might be necessary depending on how you intend to use Novell Cluster Services.
A minimum of two Linux servers, and not more than 32 servers in a cluster
At least 512 MB of memory on each server in the cluster
One non-shared device on each server to be used for the operating system
At least one network card per server in the same IP subnet
In addition, each server must meet the requirements for Novell Open Enterprise Server 2 Linux. For information, see Meeting All Server Software and Hardware Requirements
in the OES 2 SP2: Installation Guide.
NOTE:Although identical hardware for each cluster server is not required, having servers with the same or similar processors and memory can reduce differences in performance between cluster nodes and make it easier to manage your cluster. There are fewer variables to consider when designing your cluster and failover rules if each cluster node has the same processor and amount of memory.
If you have a Fibre Channel SAN, the host bus adapters (HBAs) for each cluster node should be identical.
Ensure that your system meets the following software requirements for installing and managing Novell Cluster Services:
Novell Cluster Services 1.8.5 (or later) for Linux supports Novell Open Enterprise Server 2 Linux or later. OES 2 Linux must be installed and running on each cluster server in the cluster. Novell Cluster Services is a component of the OES 2 services for OES 2 Linux.
You cannot mix two versions of OES 2 Linux in a single cluster except to support a rolling cluster upgrade. For OES 2 Linux cluster upgrade information, see Section 4.0, Upgrading OES 2 Linux Clusters.
You cannot mix OES 2 Linux and OES 1 Linux in a single cluster except to support a rolling cluster upgrade. For OES 1 Linux to OES 2 Linux upgrades, see Section 5.0, Upgrading OES 1 Linux Clusters to OES 2 Linux.
You cannot mix OES 2 Linux and NetWare 6.5 SP7 (or later) in a single cluster except to support a rolling cluster conversion. For cluster conversion information, see Section 6.0, Converting NetWare 6.5 Clusters to OES 2 Linux.
Novell eDirectory 8.8 or later is required for managing the Cluster object and Cluster Node objects for Novell Cluster Services. eDirectory must be installed somewhere in the same tree as the cluster. eDirectory can be installed on any node in the cluster, on a separate server, or in a separate cluster. You can install an eDirectory master replica or replica in the cluster, but it is not required to do so for Novell Cluster Services.
For eDirectory configuration requirements, see eDirectory Configuration.
Novell iManager 2.7.3 or later is required for configuring and managing clusters for OES 2 SP2. iManager must be installed on at least one server in your tree.
NOTE:A February 3, 2009 update to the Clusters plug-in for OES 2 SP1 Linux is available that can be used to manage the Novell Business Continuity Clustering (BCC) 1.2 for OES 2 SP1 Linux. You can download the update from the Novell Downloads Web site. For information about BCC 1.2, see BCC 1.2: Administration Guide for OES 2 SP1 Linux
The OES 2 SP2 Linux release contains a Clusters plug-in that is required when using Novell Business Continuity Clustering 1.2.1 for OES 2 SP2 Linux. For information about BCC 1.2.1, see BCC 1.2.1: Administration Guide for OES 2 SP2 Linux.
To use the Clusters role in iManager, the following storage-related plug-ins must be installed:
Clusters (ncsmgmt.npm)
Common code for storage-related plug-ins (storagemgmt.npm)
The storagemgmt.npm contains code in common with other storage-related plug-ins for OES 2 SP1:
These additional plug-ins are needed when working with the NSS file system. Make sure that you include the common storagemgmt.npm plug-in module when installing any of these storage-related plug-ins.
IMPORTANT:If you use more than one of these plug-ins, you should install, update, or remove them all at the same time to make sure the common code works for all plug-ins.
Make sure to uninstall the old version of the plug-ins before you attempt to install the new versions of the plug-in files.
These iManager plug-ins support iManager 2.7.2 and later on all operating systems supported by iManager and iManager Workstation.
The latest Novell storage-related plug-ins can be downloaded as a single zipped download file from the Novell Downloads Web site. For information about installing plug-ins in iManager, see Downloading and Installing Plug-in Modules
in the Novell iManager 2.7.3 Administration Guide.
To update storage-related plug-ins:
In iManager, uninstall the currently installed storage-related plug-ins.
Copy the new .npm files into the iManager plug-ins location, manually overwriting the older version of the plug-in in the packages folder with the newer version of the plug-in.
In iManager, install all of the storage-related plug-ins, or install the plug-ins you need, plus the common code.
For information about working with storage-related plug-ins for iManager, see Understanding Storage-Related Plug-Ins
in the OES 2 SP2: NSS File System Administration Guide.
For browser configuration requirements, see Web Browser.
EVMS (Enterprise Volume Management System) 2.5.5-24.54.5 or later is automatically installed on the server when you install Novell Cluster Services. It provides the Cluster Segment Manager (CSM) for shared cluster resources.
Updates to EVMS are received through the update channel for SUSE Linux Enterprise Server 10 SP 2 or later. Make sure that you install the latest patches for EVMS before you create any cluster resources for this server.
WARNING:EVMS administration utilities (evms, evmsgui, and evmsn) should not be running when they are not being used. EVMS utilities lock the EVMS engine, which prevents other EVMS-related actions from being performed. This affects both NSS and Linux POSIX volume actions.
NSS and Linux POSIX volume cluster resources should not be migrated while any of the EVMS administration utilities are running.
Novell Cluster Services supports creating shared cluster resources on Linux POSIX file systems, such as Ext3, XFS, and ReiserFS. Linux POSIX file systems are automatically installed as part of the OES 2 Linux installation.
Novell Cluster Services supports creating shared cluster resources by using Novell Storage Services file system on Linux. NSS is not a required component for Novell Cluster Services on Linux unless you want to create and cluster-enable NSS pools and volumes. You can also use NSS for the SBD partition. The option is not automatically selected when you select option during the install.
NSS on Linux supports the following advertising protocols in concurrent use for a given cluster-enabled NSS pool:
NetWare Core Protocol (NCP), which is selected by default and is mandatory for NSS. For information, see NCP Server for Linux.
Novell Apple Filing Protocol (AFP), which is available for NSS only in OES 2 SP1 Linux and later. For information, see Novell AFP for Linux.
Novell CIFS, which is available for NSS only in OES 2 SP1 Linux and later. For information, see Novell CIFS for Linux.
Novell Cluster Services supports clustering for Novell Dynamic Storage Technology (DST) shadow volume pairs on OES 2 Linux. DST is installed automatically when you install NCP Server for Linux. The option is not automatically selected when you select option during the install.
For information about creating and cluster-enabling Dynamic Storage Technology volumes on Linux, see Configuring DST Shadow Volumes with Novell Cluster Services for Linux
in the OES 2 SP2: Dynamic Storage Technology Administration Guide.
NCP Server for Linux is required to be installed and running before you can cluster-enable NCP volumes on Linux POSIX file systems, NSS volumes, or Dynamic Storage Technology shadow volume pairs. This applies to physical servers and Xen-based virtual machine (VM) guest servers (DomU). NCP Server is required in order to create virtual cluster server objects for cluster resources for these volume types. The option is not automatically selected when you select option during the install.
NCP Server for Linux is required to be installed and running for NSS volumes, even if users access the volume only with other protocols such as Novell AFP for Linux, Novell CIFS for Linux, or Samba.
NCP Server for Linux is not required when you are cluster-enabling only Linux POSIX volumes where you plan to use only native Linux protocols for user access, such as Samba.
NCP Server for Linux is not required when running Novell Cluster Services on a Xen-based VM host server (Dom0) for the purpose of cluster-enabling the configuration files for Xen-based VMs. Users do not access these VM files.
For information about installing and configuring NCP Server for Linux, see the OES 2 SP2: NCP Server for Linux Administration Guide.
For information about creating and cluster-enabling NCP volumes on Linux POSIX file systems, see Configuring NCP Volumes with Novell Cluster Services
in the OES 2 SP2: NCP Server for Linux Administration Guide.
Novell Cluster Services supports using Novell AFP for Linux as an advertising protocol for cluster-enabled NSS pools and volumes on OES 2 SP1 Linux and later. Novell AFP is not required to be installed when you install Novell Cluster Services, but it must be installed and running when you create and cluster-enable the shared NSS pool in order for the option to be available as an advertising protocol for the cluster resource.
For information about installing and configuring the Novell AFP service, see the OES 2 SP2: Novell AFP For Linux Administration Guide.
Novell Cluster Services supports using Novell CIFS for Linux as an advertising protocol for cluster-enabled NSS pools and volumes on OES 2 SP1 Linux and later. Novell CIFS is not required to be installed when you install Novell Cluster Services, but it must be installed and running when you cluster-enable the shared NSS pool in order for the and option to be available as an advertising protocol for the cluster resource.
For information about installing and configuring the Novell CIFS service, see the OES 2 SP2: Novell CIFS for Linux Administration Guide.
Novell Cluster Services supports using clusters in Domain Services for Windows (DSfW) contexts for OES 2 SP1 Linux and later. If Domain Services for Windows is installed in the eDirectory tree, the nodes in a given cluster can be in the same or different DSfW subdomains. Port 1636 is used for DSfW communications. This port must be opened in the firewall.
For information using Domain Services for Windows, see the OES 2 SP2: Domain Services for Windows Administration Guide.
OpenWBEM must be configured to start with chkconfig, and be running when you manage the cluster with Novell iManager. For information on setup and configuration, see the OES 2 SP2: OpenWBEM Services Administration Guide.
Port 5989 is the default setting for secure HTTP (HTTPS) communications. If you are using a firewall, the port must be opened for CIMOM communications.
For OES 2 and later, the Clusters plug-in (and all other storage-related plug-ins) for iManager require CIMOM connections for tasks that transmit sensitive information (such as a username and password) between iManager and the _admin volume on the OES 2 Linux that server you are managing. Typically, CIMOM is running, so this should be the normal condition when using the server. CIMOM connections use Secure HTTP (HTTPS) for transferring data, and this ensures that sensitive data is not exposed.
If CIMOM is not currently running when you click or for the task that sends the sensitive information, you get an error message explaining that the connection is not secure and that CIMOM must be running before you can perform the task.
IMPORTANT:If you receive file protocol errors, it might be because WBEM is not running.
To check the status of WBEM:
As root in a console shell, enter
rcowcimomd status
To start WBEM:
As root in a console shell, enter
rcowcimomd start
SLP (Service Location Protocol) is a required component for Novell Cluster Services on Linux when you are using NCP to access file systems on cluster resources. NCP requires SLP for the ncpcon bind and ncpcon unbind commands in the cluster load and unload scripts. For example, NCP is needed for NSS volumes and for NCP volumes on Linux POSIX file systems.
SLP is not automatically installed when you select Novell Cluster Services. SLP is installed as part of the Novell eDirectory configuration during the OES 2 Linux install. You can enable and configure SLP on the eDirectory Configuration - NTP & SLP page. For information, see Specifying SLP Configuration Options
in the OES 2 SP2: Installation Guide.
When the SLP daemon (slpd) is not installed and running on a cluster node, any cluster resource that contains the ncpcon bind command goes comatose when it is migrated or failed over to the node because the bind cannot be executed without SLP.
For more information, see Implementing the Service Location Protocol
in the Novell eDirectory 8.8 Administration Guide.
Xen virtualization software is included with SUSE Linux Enterprise Server. Novell Cluster Services supports using Xen virtual machine (VM) guest servers as nodes in a cluster. You can install Novell Cluster Services on the guest server just as you would a physical server. All templates except the Xen and XenLive templates can be used on a VM guest server. For examples, see Section 12.0, Configuring Novell Cluster Services in a Xen Virtualization Environment.
Novell Cluster Services is supported to run on a Xen host server where it can be used to cluster the virtual machine configuration files on Linux POSIX file systems. Only the Xen and XenLive templates are supported for use in the XEN host environment. For information about setting up Xen and XenLive cluster resources, see Section 12.2, Virtual Machines as Cluster Resources.
Ensure that configuration requirements are met for these components:
All IP addresses used by the master cluster IP address, its cluster servers, and its cluster resources must be on the same IP subnet.They do not need to be contiguous addresses.
Each server in the cluster must be configured with a unique static IP address.
You need additional unique static IP addresses for the cluster and for each cluster resource and cluster-enabled pool.
All servers in the cluster must be in the same Novell eDirectory tree.
If the servers in the cluster are in separate eDirectory containers, the user who administers the cluster must have rights to the cluster server containers and to the containers where any cluster-enabled pool objects are stored. You can do this by adding trustee assignments for the cluster administrator to a parent container of the containers where the cluster server objects reside. See eDirectory Rights
in the eDirectory 8.8 Administration Guide for more information.
If you are creating a new cluster, the eDirectory context where the new Cluster object will reside must be an existing context. Specifying a new context during the Novell Cluster Services install configuration does not create a new context.
Multiple clusters can co-exist in the same eDirectory container.
A tree administrator user with credentials to do so can extend the eDirectory schema before a cluster is installed anywhere in a tree. Extending the schema separately allows a container administrator (or non-administrator user) to install a cluster in a container in that same tree without needing full administrator rights for the tree. For instructions, see Section 3.3, Extending the eDirectory Schema to Add Cluster Objects.
IMPORTANT:It is not necessary to extend the schema separately if the installer of the first cluster server in the tree has the eDirectory rights necessary to extend the schema.
After the schema has been extended, the container administrator (or non-administrator user) needs the following eDirectory rights to install Novell Cluster Services:
Attribute Modify rights on the NCP Server object of each node in the cluster.
To set the Attribute Modify rights for the user on the nodes’ NCP Server objects:
In iManager, select > .
Select the NCP server object for the node, then click .
For , set the right.
For , set the , , and rights.
Click to save and apply your changes.
Repeat Step 1 to Step 5 for the NCP Server object of each server that you plan to add to the cluster.
Object Create rights on the container where the NCP Server objects are.
To set the Object Create rights for the user on the container where the NCP Server objects are:
In iManager, select > .
Select the Container object, then click .
For , set the , , and rights.
For , set the , , and rights.
Click to save and apply your changes.
Object Create rights where the cluster container will be.
This step is needed if the container for the Cluster object is different than the container for the NCP Server objects.
To set the Object Create rights for the user on the container where the Cluster objects will be:
In iManager, select > .
Select the Container object, then click .
For , set the , , and rights.
For , set the , , and rights.
Click to save and apply your changes.
NOTE:If the eDirectory administrator username or password contains special characters (such as $, #, and so on), some interfaces in iManager and YaST might not handle the special characters. If you encounter problems, try escaping each special character by preceding it with a backslash (\) when you enter credentials.
The administrator credentials entered during the install are automatically configured to allow that user to manage the cluster. You can modify this default administrator username or password after the install by following the procedure in Section 8.13, Moving a Cluster, or Changing IP Addresses, LDAP Server, or Administrator Credentials for a Cluster.
After the install, you can add other users (such as the tree administrator) as administrator equivalent accounts for the cluster by configuring the following for the user account:
Give the user the Supervisor right to the Server object of each of the servers in the cluster.
Linux-enable the user account with Linux User Management.
Make the user a member of a LUM-enabled administrator group that is associated with the servers in the cluster.
The browser that will be used to manage Novell Cluster Services must be set to a supported language. For information about supported languages, see the Novell iManager documentation.
The Cluster plug-in for iManager might not operate properly if the highest priority Language setting for your Web browser is set to a language other than one of the supported languages. To avoid problems, in your Web browser, click > > , and then set the first language preference in the list to a supported language.
Supported language codes are Unicode (UTF-8) compliant. To avoid display problems, make sure the Character Encoding setting for the browser is set to Unicode (UTF-8) or ISO 8859-1 (Western, Western European, West European). In a Mozilla browser, click View > Character Encoding, then select the supported character encoding setting. In an Internet Explorer browser, click View > Encoding, then select the supported character encoding setting.
For a information about supported browsers, see Using a Supported Web Browser
in the Novell iManager 2.7.3 Administration Guide.
A shared disk subsystem is required for each cluster in order to make data highly available. Make sure your shared storage devices meet the following requirements:
Novell Cluster Services supports the following shared disks:
Fibre Channel LUN (logical unit number) devices in a storage array
iSCSI LUN devices
SCSI disks (shared external drive arrays)
Before installing Novell Cluster Services, the shared disk system must be properly set up and functional according to the manufacturer's instructions.
Prior to installation, verify that all the drives in your shared disk system are recognized by Linux by viewing a list of the devices on each server that you intend to add to your cluster. If any of the drives in the shared disk system do not show up in the list, consult the OES 2 documentation or the shared disk system documentation for troubleshooting information.
Devices where you plan to create shared file systems (such as NSS pools and Linux POSIX file systems) must be unpartitioned devices that can be managed by EVMS. NSS automatically partitions the device and lays down a Cluster Segment Manager on the partition when you use NSS tools to create a pool. You use the EVMS GUI to partition and create shared Linux POSIX file systems.
If this is a new cluster, the shared disk system must be connected to the first server so that the cluster partition can be created during the Novell Cluster Services install.
If your cluster shares storage resources, you need to create a shared device that can be used to store a special cluster partition for the split-brain detector (SBD). It must have at least 20 MB of free disk space available for creating a special cluster partition for the SBD.
IMPORTANT:The cluster SBD partition is not required unless you have shared storage in the cluster.
The Novell Cluster Services installation automatically allocates one cylinder on one drive of the shared disk system for the special cluster partition. Depending on the location of the cylinder, the actual amount of space used by the cluster partition might be less than 20 MB.
When you mark a device as the share information is added to the disk and consumes about 4 MB. This space is used in addition to the space needed for the SBD. For example, if you create a 1 GB (1024 MB) device for the SBD, 4 MB are used for the share information, leaving 1020 MB as available free space for the SBD partition.
If you want to mirror the SBD partition for greater fault tolerance, you need at least 20 MB of free disk space on a second shared disk where you want to create the mirror.
Before installing Novell Cluster Services or creating a new SBD partition, you must initialize the partition, and mark its device as . If you plan to mirror the SBD, you must also initialize the partition you want to use as the mirrored SBD, and mark its device as . This allows the installation software to recognize available partitions and present them for use during the install. You can initialize the device by using NSSMU or the Storage plug-in to iManager. Beginning in OES 2 SP2, the NSS utility called ncsinit is also available for initializing a device and setting it to a shared state.
For information about how SBD partitions work and how to create one after installing the first node, see Section 8.16, Creating or Deleting Cluster SBD Partitions.
If you are using iSCSI for shared disk system access, ensure that you have configured iSCSI initiators and targets (LUNs) prior to installing Novell Cluster Services.
We recommend that you use hardware RAID in the shared disk subsystem to add fault tolerance to the shared disk system.
Consider the following when using software RAIDs:
NSS software RAID is supported for shared disks.
Linux software RAID can be used in shared disk configurations that do not require the RAID to be concurrently active on multiple nodes. Linux software RAID cannot be used underneath clustered file systems (such as OCFS2, GFS, and CXFS) because it does not support concurrent activation.
WARNING:Activating Linux software RAID devices concurrently on multiple nodes can result in data corruption or inconsistencies.
When you create a Novell Cluster Services system that uses shared storage space, it is important to remember that all of the servers that you grant access to the shared device, whether in the cluster or not, have access to all of the volumes on the shared storage space unless you specifically prevent such access. Novell Cluster Services arbitrates access to shared volumes for all cluster nodes, but cannot protect shared volumes from being corrupted by non-cluster servers.
LUN masking is the ability to exclusively assign each LUN to one or more host connections. With it you can assign appropriately sized pieces of storage from a common storage pool to various servers. See your storage system vendor documentation for more information on configuring LUN masking.
Software included with your storage system can be used to mask LUNs or to provide zoning configuration of the SAN fabric to prevent shared volumes from being corrupted by non-cluster servers.
IMPORTANT:We recommend that you implement LUN masking in your cluster for data protection. LUN masking is provided by your storage system vendor.
When you use Device Mapper Multipath (DM-MP) with Novell Cluster Services, make sure to set the path failover settings so that the paths fail when path I/O errors occur.
The default setting in DM-MP is to queue I/O if one or more HBA paths is lost. Novell Cluster Services does not migrate resources from a node set to the Queue mode because of data corruption issues that can be caused by double mounts if the HBA path is recovered before a reboot.
IMPORTANT:The HBAs must be set to Failed mode so that Novell Cluster Services can auto failover storage resources if a disk paths go down.
Change the setting in the modprobe.conf.local and multipath.conf files so that Novell Cluster Services works correctly with DM-MP. Also consider changes as needed for the retry settings in the HBA BIOS.
Use the following setting in the /etc/modprobe.conf.local file:
options qla2xxx qlport_down_retry=1
There was a change in the latest kernel and qla-driver that influences the time-out. Without the latest patch, an extra five seconds is automatically added to the port_down_retry variable to determine the time-out value for option 1 (dev_loss_tmo=port_down_retry_count+5), and option 1 is the best choice. In the patch, the extra 5 seconds are no longer added to the port_down_retry variable to determine the time-out value for option 1 (dev_loss_tmo=port_down_retry_count). If you have installed the latest qla-driver, option 2 is the best choice.
For OES 2 SP2 and later, or if you have installed the latest kernel and qla-driver, use the following setting in the /etc/modprobe.conf.local file:
options qla2xxx qlport_down_retry=2
Use the following settings for the device settings in the /etc/multipath.conf file:
failback "immediate" no_path_retry fail
The value fail is the same as a setting value of 0.
For example:
defaults
{
polling_interval 1
# no_path_retry 0
user_friendly_names yes
features 0
}
devices {
device {
vendor "DGC"
product ".*"
product_blacklist "LUNZ"
path_grouping_policy "group_by_prio"
path_checker "emc_clariion"
features "0"
hardware_handler "1 emc"
prio "emc"
failback "immediate"
no_path_retry fail #Set MP for failed I/O mode, any other non-zero values sets the HBAs for Blocked I/O mode
}
}
For the QLogic HBA BIOS, the default settings for the and values are typically set too high for a cluster environment. For example, there might be a delay of more than 30 seconds after a fault occurs before I/O resumes on the remaining HBAs. Change these settings to 5 seconds in the HBA BIOS. For example:
Port Down Retry=5 Link Down Retry=5