|
This section assumes that you are familiar with the installation and configuration of Cluster Service and need only the information required to add the Pervasive PSQL v9 Service Pack 2 services to a Cluster Service group.
If you are not familiar with Cluster Service technology, please refer to the Microsoft documentation for how to install Cluster Service, verify it is working correctly, and perform tasks with it. You may also find the following links beneficial:
This section is organized in the manner in which you should proceed to add the Pervasive PSQL services to a cluster group. That is, this section gives you the following suggested approach:
It is essential that Cluster Service be functioning correctly before you add the Pervasive.SQL services to a cluster group. Refer to the Microsoft documentation for how to install Cluster Service, verify it is working correctly, and perform tasks with it.
We recommend that you select servers and disk subsystems from the Microsoft hardware compatibility list (HCL) for clusters.
Note
If Cluster Service is not set up properly, you will be unable to get your Pervasive PSQL resources to work properly.
Before you add Pervasive PSQL to a cluster environment, we recommend that you verify network client communication with the cluster shared disk. A network client must be able to communicate with a cluster shared disk before and after a failure of a cluster node (failover). The following task lets you verify this.
To verify network client communication and cluster failover
Example:
From a command prompt on a client computer, execute the following command:
net use X: \\WIN2K-Cluster\Gdrive
This example connects drive "X" on a workstation to the "G" drive on the shared disk subsystem "WIN2K-Cluster." "WIN2K-Cluster" is the Network Name. "Gdrive" is the File Share.
dir command:
x:
dir
If the command returns something like Reply from IP address, then you can connect to the IP address. For example, the following reply shows a successful connection:
Reply from 172.99.99.35: bytes=32 time<10ms TTL=128
Check that the IP address in the reply is the correct address of the shared disk subsystem.


Repeat the Initiate Failure action until a failure occurs. The number of times you must repeat the action depends on the threshold setting.
The Initiate Failure action fails the node currently controlling the shared disk of the cluster. A surviving node in the cluster becomes active and assumes control of the shared disk.
Note
Ensure that the failover occurred and that a surviving node is now controlling the shared disk. If you cannot initiate a failure, then your clustering environment may not be set up correctly and you will be unable to get your Pervasive PSQL resources to work properly.
The cluster is functioning correctly if you can execute a command on the shared disk subsystem from a client computer before and after a failure. If you cannot, check the setup of the Cluster Service and the resources.
Your next task is to create a cluster group to which you will later add the Pervasive PSQL resources. You create a cluster group with Microsoft Cluster Administrator.
Please refer to the Microsoft Cluster Service documentation for how to add a cluster group. The steps to add the Pervasive PSQL resources to a cluster group are explained in Add Pervasive PSQL Services to Cluster Group .
All resources within a cluster group fail together. That is, if one resource within a group fails on a node, the remaining resources are taken offline. All resources within the group are then transferred to a surviving node and brought back online. For this reason, we suggest that you create a separate cluster group for Pervasive PSQL. This is not mandatory, but is a good administrative method.
At a minimum, ensure that a cluster group for Pervasive PSQL contains the following resources.
In addition to the required minimum resources (IP Address, Network Name, Physical Disk, and File Share), you may want to enable failback for the group. Failback is a feature of clustering that specifies a preferred controlling node within the cluster.
For example, suppose your cluster contains two nodes, Server A, the preferred controlling node, and Server B. If Server A fails, Server B assumes control. When Server A comes back online, control passes back to it automatically. This automatic transfer of control is referred to as failback (clustering automatically "fails back" to the preferred node).
You specify failback on the properties dialog of the group name.
Note
When the cluster node fails back to the preferred server, a Pervasive PSQL client loses connection with the database engine. No automatic reconnection occurs. Your application must reconnect the client to the Pervasive PSQL database or you must restart the application. This applies even if Enable Auto Reconnect is turned on in PCC.
Pervasive PSQL does not maintain the transaction state when the failback occurs. The transaction state does not transfer to the preferred server. Transactions are automatically rolled back to the state before the transaction began.
You install Pervasive PSQL v9 Service Pack 2 Server on each cluster node. Choose identical options for each installations. See Installing Pervasive PSQL Server for Windows in Getting Started With Pervasive PSQL (Server edition).
Do not install Pervasive PSQL on the cluster shared disk. The shared disk is where the Pervasive PSQL database(s) reside.
The Pervasive PSQL transactional and relational services typically run under the Local System Account. Depending on the settings for your domain permissions, the Local System Account may lack authority for certain actions pertaining to Pervasive PSQL, such as installing the requesters from a cluster node. Check the domain permissions for your cluster node accounts if you encounter problems installing the Pervasive PSQL products.
After installation, both the transactional and relational services are set to start automatically when the operating system starts. With clustering, however, the Cluster Administrator controls the starting and stopping (bringing online or offline) of the services. Be aware that, once you add the Pervasive.SQL services to a cluster group, the Cluster Administrator changes the service settings from automatic to manual.
If you add both the transactional and relational service to your cluster group, you do not need to take any action concerning the service settings. (Cluster Service sets both to manual.) The transactional service is always required in your cluster. The relational service is optional. If your application(s) requires the relational engine of Pervasive PSQL, you must also add the relational service to the cluster group.
Note, however, that if you add only the transactional service to the cluster then you must change the startup settings for the relational service. (The startup settings established when you installed Pervasive PSQL by running the installation program.) See To change the startup setting for the relational service .
Your next task is to add the Pervasive PSQL services to the cluster group.
To add the Pervasive.SQL transactional service to a cluster group
The transactional service of Pervasive PSQL is always required in a cluster group. Perform this task on only one node in the cluster. All other nodes in your cluster share the information.
The information should look something like the following example:

The information must be the following:

Note
Ensure that you check the option Use Network name for computer name. This option allows the Pervasive PSQL transactional engine to open files directly on the shared disk, which improves performance.


Optionally, you may set the Threshold and Period values to your choice.
If your application(s) require only the transactional engine, you do not need to add the relational service to your cluster group. You may skip to To change the startup setting for the relational service .
To add the Pervasive.SQL relational service to a cluster group
If your application(s) requires the relational engine of Pervasive PSQL, you must also add the relational service to your cluster group. If your application(s) require only the transactional engine, you do not need to add the relational service to your cluster group. You may skip to To change the startup setting for the relational service .
The information should look something like the following example:

You do not need to add the resources IP Address, Network Name, and File Share because they are dependencies of the transactional resource.
The information must be the following:

Note
Ensure that you check the option Use Network name for computer name. This option allows the Pervasive PSQL relational engine to open files directly on the shared disk, which improves performance.
You may specify the key SOFTWARE\ODBC if you want. However, this affects all ODBC data sources and ODBC providers installed on the cluster node. Pervasive PSQL may not be the only ODBC provider installed on the cluster node. If it is the only ODBC provider, this is a fast way to ensure that all Pervasive PSQL data source names (DSNs) identified in your cluster can be used by all cluster nodes.
If you do not want to specify SOFTWARE\ODBC, then you must set up the individual DSNs on each cluster node.
Decide on one of the following as your preferred way to handle DSNs.

Optionally, you may set the Threshold and Period values to your choice.
To change the startup setting for the relational service
This task is required only if you did not add the relational service to your cluster group. (See Install Pervasive PSQL on the Cluster Nodes .) If you added the relational service to your cluster group, skip this task.
Note that the steps to invoke Services may differ depending on which Windows 32-bit platform you use.
Your next task is to configure the engine by using Pervasive PSQL Control Center (PCC). The configuration settings are added to the registry. You need to configure the engine on one node in your cluster, then initiate a failure to migrate the settings to the next node in your cluster.
To configure the engines for clustering
For example, if the shared disk is drive G: and you want the dbnames configuration file to reside in a directory named "config," type in G:\config.

This also takes the SRDE service offline.




Repeat the Initiate Failure action until a failure occurs. The number of times you must repeat the action depends on the threshold setting.
The next surviving node becomes the new controlling node of the cluster.
Repeat this step until you have initiated failure to each cluster node. If you prefer, when finished, initiate failure back to the cluster node from which you started. This is not required unless you want that cluster node to be the controlling node.
Note
Ensure that failure occurs or the registry settings will not migrate to the surviving node(s).
To specify DSNs on each cluster node
This task is required only if you did not specify the registry key SOFTWARE\ODBC in step 17 of the task To add the Pervasive.SQL relational service to a cluster group . If you added the registry key SOFTWARE\ODBC, skip this task.
Note that DSNs are stored in the registry as key entries. Cluster Administrator works only with registry keys, not with the individual entries.
You need to create the DSNs on one cluster node, initiate failure, and create the same DSNs on the surviving node. You repeat this until all cluster nodes contain the DSNs.
Note
You must configure the engines by using PCC before performing this task. See To configure the engines for clustering .


Repeat the Initiate Failure action until a failure occurs. The number of times you must repeat the action depends on the threshold setting.
The next surviving node becomes the new controlling node of the cluster. Initiating failure is required because the engine must be running for you to create the DSNs.
The list contains all of the names that you added with steps 1 through 12 because those steps updated dbnames.cfg on the shared disk.
You may establish a Pervasive PSQL database on a cluster shared disk by creating a new database or by copying an existing database.
To create a new database on a shared disk.
Use PCC to create a database directly on the cluster shared drive. See To create a new database .
Creating the database also sets up the DSN. All cluster nodes are aware of the new DSN if you specified the registry key SOFTWARE\ODBC in step 17 of the task To add the Pervasive.SQL relational service to a cluster group . If you did not add that registry key, then you need to create the DSN on each cluster node. See To specify DSNs on each cluster node .
To copy an existing database to a shared disk
A previously existing database must be copied to the shared drive. You then use PCC to change the location of the dictionary and data files.
To test the transactional connection from a Pervasive PSQL client
Example:
From a command prompt on a client computer, execute the following command:
net use X: \\WIN2K-Cluster\Gdrive
This example connects drive "X" on a computer to the "G" drive on shared disk subsystem "WIN2K-Cluster." "WIN2K-Cluster" is the Network Name. "Gdrive" is the File Share.
By default, DEMODATA is located at C:\PVSW\DEMODATA.
butil -stat x:\demodata\file.ddf
If the command executes successfully, the Pervasive PSQL client is communicating with the database on the cluster shared disk. A successful execution returns information such as file version, page size, total number of records, and so forth.


Repeat the Initiate Failure action until a failure occurs. The number of times you must repeat the action depends on the threshold setting.
This fails the node currently controlling the shared disk of the cluster. A surviving node in the cluster becomes active and assumes control of the shared disk.
butil -stat x:\demodata\file.ddf
If the command executes successfully, the Pervasive PSQL client is communicating with the database on the cluster shared drive. A successful execution returns information such as file version, page size, total number of records, and so forth.
To test the relational connection from a Pervasive PSQL client
This test is required only if you added the relational service to your cluster group.
Example: net use X: \\WIN2K-Cluster\Gdrive
This example connects drive "X" on a computer to the "G" drive on shared disk subsystem "WIN2K-Cluster." "WIN2K-Cluster" is the Network Name. "Gdrive" is the File Share.
Note that the steps to invoke the ODBC Administrator may differ depending on which Windows 32-bit platform you use.



Repeat the Initiate Failure action until a failure occurs. The number of times you must repeat the action depends on the threshold setting.
This fails the node currently controlling the shared disk of the cluster. A surviving node in the cluster becomes active and assumes control of the shared disk.
|
Chapter contents
Prev topic: Server Clustering
|