Setting up Access Connect Clustering

Clustering provides fast failover and quick restart of the services provided by a failed server node. You set up an Access Connect cluster using Microsoft Cluster Servers (MSCS)—specially linked servers running the Microsoft Cluster Service. If one server fails or is taken offline, the other server or servers in the cluster immediately take over the failed server’s operations. Applications running on the cluster are always available. Resources running on multiple servers appear to connected clients as a single system, referred to as an Access Connect virtual server. When a successful failover occurs because of a problem, the connected user sometimes cannot tell that service was interrupted. Access Connect is a cluster-aware application that you can use on active/active clustered configurations. Multiple instances of Access Connect can run on a single server node. Each instance has its own IP address and can be assigned its own shared volume. The configuration of multiple virtual servers provides server consolidation and load management benefits. Running multiple instances of Access Connect on a server node provides high reliability because each instance runs in isolation from the others. For help in configuring a cluster, see the following Cluster Worksheet. Access Connect supports the following services in clustered configurations:

• active-active clustering
• multiple virtual servers per node in a cluster
• improved reliability and availability
• eight node clusters in Windows 2003 & 2008
• possible server consolidation

When you are running Access Connect in a clustered environment, the Access Connect Administrator window shows the following in
the title bar:

• the name of the server in upper case characters
• the name of the service in upper or lower case as you typed it when you set up the service.

MSCS uses the following terms to describe the component parts of a cluster configuration. Do not confuse these terms as you proceed with installing Access Connect.

• Node - A single member server in a cluster.
• Resource - A hardware or software component that runs in a cluster, such as a disk, an IP address, a network name, or an instance of the Access Connect service.
• Group - A combination of resources that are managed as a unit of failover. Groups are also known as resource groups or failover groups. A typical Access Connect failover group consists of a disk, an IP address, a network name, and an instance of Access Connect.
• Dependency - A service or other resource that must be available first in order for the dependant service to start.
• Failover - The process of moving resources or resource groups from one server to another. Failover can occur when one server experiences a failure of some sort or when you, the administrator, initiate the failover. This term is equivalent to the Microsoft Cluster Administrator action of moving a Cluster Group to another node.
• Quorum Resource - A disk resource containing the failover information that is shared between nodes in a cluster.
• Heartbeat - The communication between Cluster nodes tells the other nodes that the service is still running.
• Virtual Server - A virtual server is a combination of configuration information and cluster resources, such as an IP address, network name and an application resource. An Access Connect Virtual Server (EVS) is defined by its unique IP address.
• Active/Active - This term describes a configuration in which multiple nodes are Access Connect file servers running in production.
• Active/Passive - This term describes a configuration in which one node is active in production and another node sits idle until a failover occurs.
• Shared Storage - This term refers to the external SCSI or fibre channel storage system. Shared storage is a requirement for multi-node clusters. Although this storage is shared, only one node can access an external storage resource at any given time.

  
  This diagram shows an example of a cluster setup.

Note: Each server has its own IP address. You can configure multiple shares for each virtual server.