Server Clustering

---

A server cluster is a group of independent servers working collectively as a single system. Each server runs a collection of software to manage all aspects of the cluster. The purpose of the cluster is to provide high-availability, scalability, and manageability of resources and applications.

Pervasive.SQL V8 supports Microsoft Cluster Service and NetWare Cluster Services. Both services are similar architecturally. They provide for multiple physical servers to access a common, shared disk subsystem that contains one or more file shares or volumes. The services ensure that only one physical server controls the file shares or volumes at a time. Control of the shared disk subsystem is passed automatically from a failed server to the next surviving server in the cluster.

Members of a cluster are referred to as nodes or systems and the terms are use interchangeably. A resource is an item managed by the cluster service, such as a logical disk volume, application, or database. A resource is said to be online on a node when it provides its service on that node. A group is a collection of resources managed as a single unit.

Failure Behavior

If a cluster server fails, the cluster service automatically transfers ownership of resources such as disk drives and IP addresses from the failed server to a surviving server. Similarly, if an application fails, the cluster service restarts the failed application on a surviving server, or disperses the work from the failed node to the remaining nodes.

The shared disk of a cluster appears as a separate server within the cluster because the network name and IP address differ from those of the other nodes. You can think of a cluster as a group of independent computers working together to share data on an area of physical storage. Although the computers share data, only one computer at a time can control the shared disk subsystem.

---

Note
If a cluster node fails, a Pervasive.SQL client does not automatically reconnect to the Pervasive.SQL engine on the surviving node. Your application must reconnect the client to the Pervasive.SQL database or you must restart the application. This applies even if Enable Auto Reconnect is turned on in the Pervasive Control Center (PCC).

Pervasive.SQL does not maintain the transaction state when a cluster node fails. The transaction states does not transfer to a surviving node. Transactions are automatically rolled back to the state before the transaction began.

---

Modes

A clustering environment provides two modes of operation, active/passive and active/active. The mode indicates on how many cluster nodes a resource is active at the same time.

Running Pervasive.SQL in the Microsoft clustering environment is an example of active/passive. Pervasive.SQL is active on only one node at a time.

Running Pervasive.SQL in the NetWare clustering environment is an example of both active/passive and active/active. Pervasive.SQL is active on all nodes at the same time, which is active/active. However, only one node at a time controls the shared disk, which is active/passive. Only the Pervasive.SQL engine on the node hosting the shared disk has access to the Pervasive.SQL databases on the shared disk.

Note that the modes have nothing to do with load balancing. Pervasive.SQL does no load balancing in a clustered environment.

Licensing

No special licensing is required to use the Pervasive.SQL Server engine in a clustered environment. Refer to the Pervasive.SQL Standard License Agreement (Server Engine) for details.