4.30 Using Dynamic File Services in a Windows Cluster

Dynamic File Services supports using pairs and policies in a Windows failover cluster. However, the software is not cluster aware.

This section describes known issues for using Dynamic File Services in a Windows cluster. For information about installing Dynamic File Services in a cluster, see the Dynamic File Services 2.1 Installation Guide.

4.30.1 Management Console

When you use the Management Console to manage the Dynamic File Service in a cluster, use the cluster resource IP address of the Service to connect to the cluster instead of the server node’s IP address.

When you create pairs and policies, ensure that the primary path and secondary path of each pair reside on shared storage that can be failed over together between the cluster nodes.

4.30.2 Service Controller

The Service Controller starts automatically at the beginning of each session when you log in to the active node where the disk that contains the Novell Dynamic File Services software is currently mounted. The controller does not start if you log in to the failover node because the shared disk is not mounted there.

4.30.3 Merged View

In a Windows cluster, always use the Windows cluster management tool and not Windows Explorer to manage file shares to folders on shared drives. Otherwise, changes to share information made by using Windows Explorer are lost when these file shares fail over to other nodes in the cluster. Workstations should be in an Active Directory domain to access the cluster-managed file shares.

4.30.4 Executable Files

The Dynamic File Service is started automatically by the Windows cluster management tool when it brings the Dynamic File Service cluster resource online. The Service is stopped when the Windows cluster management tool brings the resource offline. Ensure that you use the Windows cluster management tool to start and stop the Service, and not the Dynamic File Service Controller.

Other DynamicFS executable files are called from the Service, or can be started manually when you are logged in on the active nodes as user in the Dynamic File Services group (or as the Administrator user on that node). Conversely, you cannot start the executable files on the failover node because the cluster drive resource that contains the files is not attached to it.

4.30.5 Standard Policy Engine and Registry Information

Policy moves and previews should work correctly on the active node, regardless of which node is active, if the installation location is correct in the registry. If policy runs and preview runs do not work after you set up your DynamicFS cluster resource group, ensure that the node’s registry contains the right installation location.

4.30.6 Moving the Service Cluster Resource Between Nodes

Before initiating a non-failover move of the Dynamic File Service cluster resource from the active node to a failover node, ensure that you have quiesced the Service as described in Prerequisites for Stopping or Restarting the Service.

If a policy is running when the move is initiated, the resource enters an Offline Pending state until DynamicFS can gracefully complete the in-progress file copies, shut down the policy run, and go offline for the move. This process can take up to 10 minutes. During this time, the failover cluster File Server and IP address for the Service are unavailable, and users are unable to access the files.

If the active node crashes when a policy run is in progress, the Service also crashes. The Service cluster resource immediately goes offline and fails over to the failover node. The following issues must be addressed after the Service cluster resource is back online:

  • The policy run does not automatically resume or start over after the failover.

  • There is no ability to gracefully complete any file copies that are in progress for the policy run.

    There is no data loss, but duplicate files might exist, where the original file is good but the instance of the file in the target location is only a sparse file.

    To resolve this problem:

    1. Check for duplicate files in the pairs where the policy was running by running the Pair Check utility on each pair. For information, see Section 8.12, Reporting Conflicts for Duplicate Files.

    2. For each reported duplicate file conflict, delete the instance of the file in the target location of the policy move.

    3. After all duplicate file conflicts have been resolved, the policy run can be started manually, or the policy runs at its next scheduled time.