Your system must meet the requirements in this section in addition to the cluster requirements described in Section 4.0, Planning for OES Cluster Services.
OES Cluster Services must be installed, configured, and running when you share devices and when you create manage the shared NSS pools and volumes. The cluster must be active.
Each NSS pool cluster resource requires a unique static IP address. The IP address is used to provide access to and failover capability for the pool cluster resource. Users access the pool by using the resource IP address instead of the server IP address where the pool is active. The IP address you assign to the pool remains assigned to the pool regardless of which server in the cluster is accessing the pool.
IMPORTANT:The IP address for the virtual server must be in the same IP subnet as the server nodes in the cluster where you plan to use it.
OES Cluster Services requires that eDirectory be running and working properly when you cluster-enable a pool and when you manage the pool.
NSS must be installed and running on each server in the cluster. For information about installing NSS and managing NSS pools and volumes, see the OES 2018 SP3: NSS File System Administration Guide for Linux. For information about using NLVM commands, see OES 2018 SP3: NLVM Reference.
In addition, the following requirements must be met:
We recommend that your pool cluster resource be one device, one pool, one volume. You can create a pool up to 8 TB in size on a single device by formatting the device in GPT format.
You can create and cluster-enable a shared NSS pool by using the Storage plug-in for iManager, the server-based NSS Management Utility (nssmu), or the OES Linux Volume Manager (NLVM) command line interface. You can also use these tools to create NSS volumes on the shared pool. These tools interact with OES Cluster Services to create the pool cluster resource.
You can cluster-enable an existing NSS pool by using the Clusters plug-in for iManager.
You must create at least one volume in the shared pool. Typically, you create all volumes for a shared pool when you set up the pool cluster resource and before you need to cluster migrate or fail over the resource to a different node in the cluster.
For information about using antivirus software with NSS volumes, see Antivirus Support for NSS
in the OES 2018 SP3: NSS File System Administration Guide for Linux.
Pool names and volume names must comply with the same naming conventions. Names must be 2 to 15 characters in length. OES Cluster Services supports pool names with characters A to Z, 0 to 9, and underscores (_). The name cannot begin or end with an underscore; it cannot contain multiple adjacent underscores (__). It does not allow the following special characters in a shared pool name:
!@#$%&()
IMPORTANT:Before you cluster-enable an existing NSS pool, you must rename the pool and its volumes to use names that do not contain special characters.
The pool name is used to form the default name of the pool cluster resource and the virtual server (the NCS:NCP Server object). If you modify the resource name, ensure that the name conforms to the resource naming conventions as described in Section 10.1.1, Naming Conventions for Cluster Resources.
|
Storage Object |
Default Name |
|---|---|
|
Resource name |
<cluster_name>_<poolname> |
|
Clustered Volume object name |
<cluster_name>_<volume_name> \\<cluster_name>-<poolname>-SERVER\<volume_name> |
|
Virtual server name |
<cluster_name>-<poolname>-SERVER |
The Server, Pool, Volume, Cluster Resource, and Cluster objects are recommended to be in the same context (such as ou=ncs,o=novell). It is supported for the objects to be in the same context or different contexts. If the objects are in different contexts, you might need to cluster migrate the pool cluster resource back to the context where the pool was created in order to modify the pool or volume, or to perform other tasks like setting up Distributed File Services junctions or home directories. You receive an eDirectory error if the operation cannot find the information that it needs in the same context.
You should carefully plan how you want to configure your shared storage prior to installing OES Cluster Services. Consider the guidelines and requirements in the following sections when planning your NSS storage solution.
NetWare Core Protocol (NCP) is the OES networking protocol used by the Client for Open Enterprise Server. NCP is automatically selected as an advertising protocol when you cluster-enable an NSS pool. This is necessary to provide authenticated access to data using the OES Trustee model.
OES Storage Services requires that the NCP Server for Linux service be installed and running on each node in the server. NCP Server must be running even if users access volumes on the shared NSS pool only via other protocols.
WARNING:Cross-protocol file locking is required when using multiple protocols for data access on the same volume. This helps prevent possible data corruption that might occur from cross-protocol access to files.
The NCP Cross-Protocol File Lock parameter is enabled by default when you install NCP Server. If you modify the Cross-Protocol File Lock parameter, you must modify the setting on all nodes in the cluster.
NCP Server does not support cross-protocol locks across a cluster migration or failover of the resource. If a file is opened with multiple protocols when the migration or failover begins, the file should be closed and reopened after the migration or failover to acquire cross-protocol locks on the new node.
See Configuring Cross-Protocol File Locks for NCP Server
in the OES 2018 SP3: NCP Server for Linux Administration Guide.
NCP Server for Linux is installed by selecting NCP Server and Dynamic Storage Technology from the OES Services menu in the YaST install interface. For information about NCP Server for Linux, see the OES 2018 SP3: NCP Server for Linux Administration Guide.
You must specify an NCP virtual server name for the cluster-enabled pool. By default, the suggested name is in the form of <clusterName>-<poolName>-SERVER. You can accept the suggested name, or specify a custom name for the NCP virtual server name. If you are also enabling CIFS as an advertising protocol, you might want to choose an NCP virtual server name that can also be used as the CIFS virtual server name. For information about using the NCP virtual server name as the CIFS virtual server name, see Section 12.1.7, OES CIFS for Linux.
Common Internet File System (CIFS) is the Windows networking protocol. OES CIFS allows you to give clients access via CIFS to volumes on the shared NSS pool.
WARNING:To prevent possible data corruption, enable the NCP Cross-Protocol File Locks parameter for NCP Server on all nodes in the cluster before you allow users to access the data. See Configuring Cross-Protocol File Locks for NCP Server
in the OES 2018 SP3: NCP Server for Linux Administration Guide.
OES CIFS must be installed, configured, and working properly before you can specify CIFS as an advertising protocol when you cluster-enable an NSS pool. Otherwise, the CIFS option is not available when you configure the resource. OES CIFS for Linux is installed by selecting OES CIFS from the OES Services menu in the YaST install interface. For information about OES CIFS for Linux, see the OES 2018 SP3: OES CIFS for Linux Administration Guide.
You must specify a CIFS virtual server name for the cluster enabled pool. You can accept the suggested name, or specify a custom name for the CIFS virtual server name. The name can be up to 15 characters, which is a restriction of the CIFS protocol.
For users to collaborate effectively, all paths for user access should be identical, independent of the access protocol used. This is possible only if the same name is used for the NCP virtual server name and the CIFS virtual server name, and the name can be only up to 15 characters.
By default, the NCP virtual server name is suggested as the CIFS virtual server name. If the name is more than 15 characters, the CIFS virtual server name uses the rightmost 13 characters and adds -W. For example, an NCP virtual server name of CLUSTER1-P_USERS is modified to STER1-P_USERS-W for the CIFS virtual server name. If a default NCP virtual server name was used in the form of <clusterName>-<poolName>-SERVER and the name exceeds 15 characters, the CIFS virtual server name uses the rightmost 13 characters of the <clusterName>-<poolName> part of the name, and adds -W. For example, an NCP virtual server name of CLUS1-P123-SERVER is modified to CLUS1-P123-W for the CIFS virtual server name.
If an administrator user later changes the NCP virtual server name for a clustered pool, NSSMU automatically modifies the CIFS virtual server name accordingly. To use a custom name for the CIFS virtual server name, you can modify the CIFS virtual server name by using the CIFS management tools. The custom CIFS name will not affect the NCP virtual server name.
Apple Filing Protocol (AFP) is the Macintosh networking protocol. OES AFP is required when you want to give Macintosh clients access via AFP to volumes on the shared NSS pool.
WARNING:To prevent possible data corruption, enable the NCP Cross-Protocol File Locks parameter for NCP Server on all nodes in the cluster before you allow users to access the data. See Configuring Cross-Protocol File Locks for NCP Server
in the OES 2018 SP3: NCP Server for Linux Administration Guide.
OES AFP must be installed, configured, and working properly before you specify AFP as an advertising protocol when you cluster-enable an NSS pool. Otherwise, the resource will be in a comatose state, and cannot be brought online. OES AFP for Linux is installed by selecting OES AFP from the OES Services menu in the YaST install interface. For information about OES AFP for Linux, see the OES 2018 SP3: OES AFP for Linux Administration Guide.
Cluster-enabled NSS volumes can be used in a Domain Services for Windows environment.