Library > Products > Pervasive.SQL > Pervasive.SQL 9.1 > Advanced Operations Guide > Server High-Availability Support > NetWare Cluster Services

PreviousAdvanced Operations Guide (9.1 revision 1) Next

NetWare Cluster Services

Show this topic in Library frames

NetWare Cluster Services is supported by the Pervasive.SQL Server engine on NetWare 6.x and NetWare 5.1 SP5.

This section assumes that you are familiar with the installation and configuration of Cluster Services and need only the information required to configure Pervasive.SQL for Cluster Services.

If you are not familiar with Cluster Services technology, please refer to the NetWare documentation for how to install Cluster Services, verify it is working correctly, and perform tasks with it.

How to Proceed

This section is organized in the manner in which you should proceed to add Pervasive.SQL to your cluster. That is, this section gives you the following suggested approach:

Upgrade Database Engine

If you want to upgrade the database engine to the latest version, do so before configuring Pervasive.SQL for Cluster Services. Each cluster server must contain the same version of Pervasive.SQL.

See Installing Pervasive.SQL Server for NetWare in Getting Started with Pervasive.SQL Server Edition for the installation steps.

Note
Upgrading Pervasive.SQL is optional. You may use the version of Pervasive.SQL supplied with NetWare if you choose, provided the NetWare version is supported as listed above.

Verify Cluster Services is Functioning Correctly

Refer to the Novell documentation for how to install Cluster Services and verify it is working correctly. Also consult the NetWare documentation for how to use ConsoleOne and how to perform tasks with Cluster Services.

During installation of Cluster Services, you create a NetWare cluster object. The Novell documentation details the information required when you create a cluster object. This information is required for any cluster object, including an object for the Pervasive.SQL database engines.

At a minimum, ensure that you know the following when you create a cluster object:

After you create a cluster object, you may verify that Cluster Services is functioning correctly.

To verify that Cluster Services is functioning correctly

  1. Connect a drive on a client computer to the shared disk subsystem. (This step assumes that you are using a computer on which a Pervasive.SQL requester is, or will be, running.)

    2. Example:

    From a command prompt on a client workstation, execute the following command:

    net use X: \\nw_cluster_object_server\vol1

    This example connects drive "X" on a workstation to volume 1 of the shared disk.

  2. Verify that you can execute a command on the connected drive. For example, switch to the drive of the shared disk and display a directory with the dir command:

    3. x:
    dir

  3. Verify that you can connect to the IP address of the shared disk subsystem. From a command prompt, execute the following command: ping shared disk subsystem address. For example, ping 192.168.xx.xx.

    4. 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 192.168.xx.xx: bytes=32 time<10ms TTL=128

    Check that the IP address in the reply is the correct address of the shared disk subsystem.

    The next three steps, 4, 5, and 6, require that you have administrator authority.

  4. In ConsoleOne, click on the cluster object in the left pane.

    5. For NetWare 5.1, click on the cluster shared object then click View4Cluster State. Click the Cluster State tab. For NetWare 6.x, right-click on the cluster shared object, click Views 4 Cluster State Views then click the Cluster State View tab.

    You should see something similar to the following.



  5. In the right pane, click on the Location that is controlling the shared resource.



    6. For NetWare 6.x, it is the Location controlling the pool manager for the shared resource.

    The Cluster Resource Manager dialog appears.

  6. Click on a migration target, then click Migrate. For example, the following image shows NW_Cluster_B as the migration target.



    7. The migration target becomes active and assumes control of the shared disk. In the ConsoleOne interface, you will see the location change to the migration target and the number of lives (#Lives) increment by one.

  7. On the client workstation used for step 1, verify that you can still execute a command on the connected drive. For example, display a directory with the dir command.

The cluster is functioning correctly if you can execute a command on the shared disk subsystem from a client workstation before and after a migration. If you cannot, check the setup of Cluster Services.

Failback

Optionally, you may want to enable failback for the cluster object. Failback is a feature of clustering that specifies a preferred 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).

For NetWare 5.1, you specify failback on the properties dialog of the cluster object volume server. Click on the volume server then click View4Console View to see the volume resources in the right pane of ConsoleOne. On the Policies tab, set Failback Mode to Auto.

For NetWare 6.x, you specify failback on the properties dialog of the pool manager for the shared object. Click on the shared resource object. Right-click on the pool manager then click Properties.

On the Policies tab, set Failback Mode to Auto.

Note
When the cluster node fails back to the preferred server, a Pervasive.SQL client loses connection with the database engine. No automatic reconnection occurs. 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 PCC.

If you want the transaction state to transfer to the preferred server, see Enabling Transaction Durability .

Modify Load Script

The creation of a cluster object creates a default load and unload script. These scripts are necessary to dismount and mount the volume of the shared disk during a failover. For Pervasive.SQL, you need to modify the load script only and add the commands mgrstop, bstop, bstart, and mgrstart.

For NetWare 5.1, you specify scripts on the properties dialog of the cluster object volume server. Click on the volume server then click View4Console View to see the volume resources in the right pane of ConsoleOne. On the the Load tab then specify the script.

For NetWare 6.x, you specify failback on the properties dialog of the pool manager for the shared object. Click on the shared resource object. Right-click on the pool manager then click Properties.

On the Scripts tab, select the Cluster Resource Load Script.

Table 9-1 shows an example of a modified load script. You add mgrstop and bstop to the top of the script, and bstart and mgrstart to the bottom.

Table 9-1 Example Modified Load Script for Pervasive.SQL Engines
mgrstop
bstop
nss /activate=VOL1
mount VOL1 VOLID=254
trustmig VOL1 watch
NUDP ADD NW_CLUSTER_
SUBSYSTEM 192.168.xx.xx
add secondary ipaddress 192.168.xx.xx
bstart
mgrstart

Configure Engines and Ensure Identical Configuration Information

Each cluster node must contain identical configurations for the Pervasive.SQL database engines. This includes the server configuration settings made with Pervasive.SQL Control Center (PCC) and information about all databases created through PCC (such as data source names).

The easiest way in which to ensure identical configurations is to establish the configuration on one node and then copy the information to the other nodes.

To do this, first register the shared disk subsystem as a new engine to PCC. (The task To configure an engine shows you how.)

Next, set the following PCC configurations:

Note that these are required. The supported protocol must be set to TCP/IP, and TCP/IP Multihomed must be ON. See To configure an engine for the steps to set these configurations.

Optionally, set transaction durability and transaction logging to OFF. If you require transaction durability or transaction logging, see Enabling Transaction Durability .

From the node that is hosting the shared disk, you then copy the following files to all other cluster nodes:

For example, suppose that node NW_CLUSTER_A is hosting the shared disk, which is named NW_CLUSTER_OBJECT_SERVER. Register NW_CLUSTER_OBJECT_SERVER to PCC and set transaction durability and transaction logging to OFF and supported protocols to TCP/IP. Then copy psrgstry.ini, odbc.ini, and dbnames.cfg from the SYS volume of NW_CLUSTER_A to the other nodes.

You have a couple of alternatives to copying the psrgstry.ini, odbc.ini, and dbnames.cfg files to each node. You may register each cluster node in PCC and set the configuration for each node. Or, you may register the shared disk subsystem, set the configuration, migrate to the next cluster node, set the configuration, and so forth until you have migrated to all cluster nodes.

How you achieve the end result does not matter as long as all nodes are configured identically.

Configuring the Database Engine

The following steps explain how to configure an engine by using PCC.

To configure an engine

  1. In PCC Pervasive.SQL Explorer, right-click on Engines then click New 4 Server.
  2. For server name, type in the Network Name of the cluster shared disk subsystem.

    3. Ensure that you specify the Network Name of the cluster shared disk and not the machine name of a cluster node. For example, if the cluster shared disk is named NW_CLUSTER_OBJECT_SERVER, type NW_CLUSTER_OBJECT_SERVER as the server name.

  3. Click Finish.
  4. In PCC Pervasive.SQL Explorer, right-click on the server name that you just added, then click Properties.
  5. In the Properties tree, click Communication Protocols.
  6. Ensure that TCP/IP Multihomed is ON (check marked). If it is not, click TCP/IP Multihomed then click OK.
  7. Click Yes to restart the engines.
  8. In the Properties tree, click Data Integrity.
  9. Optionally, ensure that Transaction Durability and Transaction Logging are both set to OFF. "Off" means that neither option is check marked. Click the option to remove the check mark.
Caution
By turning Transaction Durability and Transaction Logging off, you cannot guarantee data consistency and transaction atomicity across multiple files.
Note
If you require transaction durability, see Enabling Transaction Durability .
  1. Click OK.
  2. Click Yes to restart the engines.

To configure the engines by migration

This task shows how to configure the engines by migration. Perform this task only if you want to configure the engines by the migration method. As an alternative method, you may prefer to configure the node hosting the shared disk, then copy psrgstry.ini, odbc.ini, and dbnames.cfg to the other nodes.

  1. Complete all of the steps in To configure an engine .

    2. The next two steps require that you have administrator authority.

  2. For NetWare 5.1, click on the cluster shared object then click View4Cluster State. Click the Cluster State tab. For NetWare 6.x, right-click on the cluster shared object, click Views 4 Cluster State Views then click the Cluster State View tab.

    3. In the right pane, click on the Location that is controlling the shared resource.



    For NetWare 6.x, it is the Location controlling the pool manager for the shared resource.

    The Cluster Resource Manager dialog appears.

  3. Click on a migration target, then click Migrate. For example, the following image shows NW_Cluster_B as the migration target.



    4. The migration target becomes active and assumes control of the shared disk. In the ConsoleOne interface, you will see the location change to the migration target and the number of lives (#Lives) increment by one.

  4. For each node in the cluster, repeat the task To configure an engine and steps 1 through 3 of this task.

    5. These actions could become tedious if you have numerous nodes in your cluster. For that reason, you may prefer to configure the node hosting the shared disk, then copy psrgstry.ini, odbc.ini, and dbnames.cfg to the other nodes.

Enabling Transaction Durability

Transaction durability guarantees that all successfully completed transactions are committed to the data files in the event of a system crash. This section explains how to implement transaction durability within a clustered environment on NetWare. (See Transaction Durability for addition information about transaction durability.)

Note
For transaction durability to work correctly, you must change the NetWare configuration as described in this section.

The default directory for the transaction log is sys:\system\mkde\log. The log is directed to the server's local system volume. In a clustered environment, a preferred location for the transaction log is on the shared volume. That way, when one system fails, the other system can find the log and update the tables accordingly.

Simply specifying the shared volume as the location for the transaction log is not sufficient. The reason has to do with the time required to bring the shared volume online. When the database engine initializes, it attempts to locate the directory for the transaction log. If the directory cannot be found at the same time, the engine changes the directory to sys:\system\mkde\log on the local system.

In a cluster environment, bringing the shared volume online for the active server is time consuming. The database engine cannot locate the shared volume until it is online. Therefore, because of the time lag, the database engine changes the directory for the transaction log back to the default. The default location is on the local volume, not the shared volume. (For the passive server, the shared volume is not brought online until the active server fails over.)

By using a NetWare Load Module, PWAITVOL.NLM, the database engine can be delayed from starting until the shared volume is available. Once the shared volume is available, the database engine starts and can locate the transaction log on the shared volume.

Restrictions

Be aware of the following restrictions if you choose to use PWAITVOL.NLM:

Note
On the passive server, no access to any databases can occur until a failover completes and the passive server becomes the active server.
Caution
The use of PWAITVOL.NLM does not guarantee transaction durability if the transactions span files accessed across multiple servers each running a database engine. Transaction durability ensures that the database transaction performed to a specific server is durable. Each server is solely responsible for its own database transactions. If the user or an application spreads a business transaction over multiple servers, transaction durability cannot ensure that the transaction will be completed and durable for all of the servers. This is true in a non-clustered environment too.
Caution
If the active server is failed manually by using Novell's ConsoleOne failover feature, the database engine remains running but does not have access to the shared volume. Therefore, errors occur if clients access the server directly through the server name. The same holds true for applications running locally on the NetWare server.

To configure transaction durability for a shared volume

Caution
All steps to configure transaction durability for a shared volume must be completed on the server before the server is rebooted. If a server is rebooted before all steps have been completed, the configuration can change back to the default.
  1. Bring up one of the servers in the clustered environment.

    2. Allow the server to boot and gain access to the shared volume.

  2. If the Pervasive.SQL database engine started as part of the boot process, enter the following commands in the following order at the NetWare server console command prompt:

    3. MGRSTOP

    BSTOP

  3. Verify that the shared volume can be accessed by the active server.
  4. Once the shared volume can be accessed, enter the following command at the NetWare server console command prompt:

    5. BSTART

    The BSTART command starts the Pervasive.SQL database engine.

  5. Create the desired directory for the transaction log on the shared volume.

    6. For example, from a Windows client, map a drive to the shared volume. Change to that drive and create the directory. If you wanted the transaction log to be located in MKDE\LOG, you would enter commands such as the following:

    md \MKDE

    md \MKDE\LOG

  6. Start Pervasive.SQL Control Center (PCC) from a Windows client. (You start it from the Pervasive program on the Start menu.)
  7. Register the NetWare server to PCC using the cluster name. (Right-click on the node Pervasive.SQL in Pervasive.SQL Explorer, then click New 4 Server.)
  8. In Pervasive.SQL Explorer, expand the nodes (click the expand icon to the left of each node to expand the node).
  9. Under Engines, right-click on the server that you just registered then click Properties.
  10. Click Directories in the Properties tree.
  11. Change the Dictionary Location to the location on the shared drive.
  12. Change the Transaction Log Directory to match the directory that you created on the shared volume. For example, if your shared volume is named SHARED_VOL1:, and the directory you created is MKDE\LOG, specify the following:

    13. SHARED_VOL1:\MKDE\LOG

  13. Click OK.
  14. Click Yes to restart the engines.
  15. Stop and restart the database engine to verify that the setting for Transaction Log Directory is maintained. Enter the following commands in the following order at the NetWare server console command prompt:

    16. BSTOP

    BSTART

    You may also view SYS:ETC\PSRGSTRY.INI to verify that the setting is correct. Check the Transaction Log Directory for the correct name:

    Transaction Log Directory=SHARED_VOL1:\MKDE\LOG

  16. Modify AUTOEXEC.NCF by entering the following command at the NetWare console:

    17. edit autoexec.ncf

    Note
    BSTART.NCF (or MGRSTART.NCF) must be loaded after the cluster modules are started. Otherwise, it will be impossible for the shared volume to be available before the database engine loads.
  17. Find BSTART.NCF and/or MGRSTART.NCF and move them to the end of AUTOEXEC.NCF.

    18. For example, here is an edited AUTOEXEC.NCF:

    SET BINDERY CONTEXT = O=TEST.C=US

    SET TIME ZONE = CST6CDT

    SET DAYLIGHT SAVINGS TIME OFFSET = 1:00:00

    SET START OF DAYLIGHT SAVINGS TIME = (APRIL SUNDAY FIRST 2:00:00 AM)

    SET END OF DAYLIGHT SAVINGS TIME = (OCTOBER SUNDAY LAST 2:00:00 AM)

    # Note: The Time zone information mentioned above

    # should always precede the SERVER name.

    SEARCH ADD SYS:\JAVA\NWGFX

    SEARCH ADD SYS:\JAVA\NJCLV2\BIN

    # WARNING!!

    FILE SERVER NAME NW6_CLUSTER_B

    # WARNING!!

    # If you change the name of this server, you must update

    # all the licenses that are assigned to this server. Using

    # NWAdmin, double-click on a license object and click on

    # the Assignments button. If the old name of

    # this server appears, you must delete it and then add the

    # new server name. Do this for all license objects.

    SERVERID D99B7AF

    load conlog maximum=100

    SEARCH ADD SYS:\JAVA\BIN

    ; Network driver LOADs and BINDs are initiated via

    ; INITSYS.NCF. The actual LOAD and BIND commands

    ; are contained in INITSYS.NCF and NETINFO.CFG.

    ; These files are in SYS:ETC.

    sys:etc\initsys.ncf

    #LOAD IPXRTR

    #LOAD 3C90XC.LAN SLOT=2 FRAME=ETHERNET_802.2 NAME=3C90XC_1_E82

    #BIND IPX 3C90XC_1_E82 NET=FBD43BCB

    #LOAD 3C90XC.LAN SLOT=10008 FRAME=ETHERNET_802.2 NAME=3C90XC_2_E82

    #BIND IPX 3C90XC_2_E82 NET=241BF5BF

    #LOAD IPXRTRNM

    #LOAD TCPIP

    #LOAD 3C90XC.LAN SLOT=2 FRAME=ETHERNET_II NAME=3C90XC_1_EII

    #BIND IP 3C90XC_1_EII addr=192.168.3.137 mask=255.255.255.0

    #LOAD 3C90XC.LAN SLOT=10008 FRAME=ETHERNET_II NAME=3C90XC_2_EII

    #BIND IP 3C90XC_2_EII addr=192.168.5.137 mask=255.255.255.0

    MOUNT ALL

    SYS:\SYSTEM\NMA\NMA5.NCF

    # BSTART.NCF - loaded here shared_vol1 not available, Trans Log Dir defaults

    load nile.nlm

    load httpstk.nlm /SSL /keyfile:"SSL CertificateIP"

    LOAD PORTAL.NLM

    LOAD NDSIMON.NLM

    LOAD NICISDI.XLM s

    LOAD SASDFM.XLM

    LOAD SAS.NLM

    LOAD PKI.NLM

    LOAD NLDAP.NLM

    # Storage Management Services components required for Backup

    SMSSTART.NCF

    UCS.NCF

    #STARTX

    ;COMMENT Cluster Services - start

    LDNCS.NCF

    # Now start Pervasive

    BSTART.NCF

    MGRSTART.NCF

  18. Add PWAITVOL to the beginning of BSTART.NCF. Conversely, PWAITVOL can be placed just before the BSTART.NCF line in AUTOEXEC.NCF.
    19. Note
    If PWAITVOL is added to both AUTOEXEC.NCF and BSTART.NCF, the one in BSTART.NCF exits quickly because the volume is already accessible.

    If the database engine accesses data on other shared volumes, add a separate PWAITVOL command for each volume. This ensures that the database engine can access the other shared volumes if the transaction log contains transactions accessing these other volumes.

  19. Specify the volume name of the shared volume in the -V= option.

    20. For example, if the shared volume is named SHARED_VOL1, add the following line:

    LOAD PWAITVOL -V=SHARED_VOL1

    The following is an example of an edited BSTART.NCF file:

    LOAD PWAITVOL -V=SHARED_VOL1

    LOAD CLIBAUX

    LOAD PSCORE

    LOAD PSCL

    ; PCOM NLM Section - Remove when performed by install.

    LOAD PSCP932

    LOAD PCEUROP

    LOAD PSUTILRB

    LOAD MKDERB

    LOAD NWEXP010

    LOAD LICMGRRB

    LOAD LEGACYLM

    LOAD MKC

    LOAD NWCSM

    LOAD NWCSP

    LOAD DBCSIPXY

    LOAD NWCSI100

    LOAD NWDCM100

    ; Register PCOM objects

    LOAD PSREGSVR -f psregsvr.ini

    LOAD NWAIF103

    LOAD NWENC103

    LOAD DSAPI

    LOAD CLXNLM32

    LOAD ENGINELM

    LOAD NWMKDE

    LOAD BTRIEVE

    BTRV LINK

    LOAD NWBSRVCM

  20. Reboot this server and verify that it keeps the Transaction Log Directory set to the shared volume location.
  21. Down the server that you have just configured.
  22. Repeat steps 1 through 4 and steps 6 through 20 for the other server.
    23. Note
    Skip step 5 since the directory on the shared volume already exists.
  23. Bring up the server that you downed in step 21. That server pauses at PWAITVOL until the active server fails over.

Establish Databases on the Cluster Shared Disk

You may establish a Pervasive.SQL database on a cluster shared disk by copying an existing database or by creating a new database. For example, you may create a database with PCC directly on the cluster shared disk. If you already have an existing Pervasive.SQL database, you may copy it to the cluster shared disk.

A Previously Existing Database

A previously existing database may be copied to the shared disk. You then use PCC to change the location of the dictionary and data files.

Copying an Existing Database to a Shared Disk

  1. Copy the database directory or directories to the shared drive.
  2. In PCC Pervasive.SQL Explorer, expand the list of Databases (click the plus (+) signs in the tree to expand the nodes).
  3. Right-click on the name of the database that you copied then click Properties.
  4. Click Directories in the Properties tree.
  5. Change the Dictionary Location to the location on the shared drive.
  6. Change the Data File Locations to the location(s) on the shared drive.
  7. Click OK.

Creating a Database With PCC

Before using PCC, you need to create a directory on the shared disk. This will be the location of the database files. After you create the directory, complete the steps for To create a new database . Specify the directory on the shared disk as the directory location for the database.

After you create a database, ensure that the DSNs are set for each cluster node. The easiest way to do this is to copy SYS:ODBC\odbc.ini and SYS:SYSTEM\dbnames.cfg from the hosting node to each of the other nodes.

For example, suppose that node NW_CLUSTER_A is hosting the shared disk, which is named NW_CLUSTER_OBJECT_SERVER. You create a directory named CLUSTERDB on VOL1 of the shared disk.

Create a new database named Clustertest following the steps for To create a new database . For Location, specify the volume and directory name, not a mapped drive letter. After the database is created, copy odbc.ini and dbnames.cfg from the SYS volume of NW_CLUSTER_A to the other nodes.

As an alternatives to copying the odbc.ini and dbnames.cfg files to each node, you could manually create the DSNs on the remaining nodes. How you achieve the end result does not matter as long as all nodes contain identical information about the database.

To test the transactional connection from a Pervasive.SQL client

  1. Connect a drive on a client workstation with a Pervasive.SQL client to the shared disk subsystem.

    2. Example:

    From a command prompt on a client workstation, execute the following command:

    net use X: \\nw_cluster_object_server\vol1

    This example connects drive "X" to volume one on the shared disk.

  2. Copy the sample database DEMODATA (the DEMODATA folder) from the controlling cluster node to the cluster shared disk. (This step is not required if you already have a Pervasive.SQL database on the cluster shared disk. These steps assume that you do not.)

    3. By default, DEMODATA is located at SYS:\PVSW\DEMODATA.

  3. At a command prompt on the client workstation, execute the following command (using drive X as an example):

    4. butil -stat x:\demodata\file.ddf

    If the command executes successfully, the Pervasive.SQL 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.

    The next two steps, 4 and 5, require that you have administrator authority.

  4. For NetWare 5.1, click on the cluster shared object then click View4Cluster State. Click the Cluster State tab. For NetWare 6.x, right-click on the cluster shared object, click Views 4 Cluster State Views then click the Cluster State View tab.

    5. In the right pane, click on the Location that is controlling the shared resource.



    For NetWare 6.x, it is the Location controlling the pool manager for the shared resource.

    The Cluster Resource Manager dialog appears.

  5. Click on a migration target, then click Migrate. For example, the following image shows NW_Cluster_B as the migration target.



    6. The migration target becomes active and assumes control of the shared disk. In the ConsoleOne interface, you will see the location change to the migration target and the number of lives (#Lives) increment by one.

  6. After the migration, execute the following command from the client workstation (using drive X as an example):

    7. butil -stat x:\demodata\file.ddf\file.ddf

    If the command executes successfully, the Pervasive.SQL 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.

To test the relational connection from a Pervasive.SQL client

  1. Connect a drive on a client workstation with a Pervasive.SQL client to the shared disk subsystem.

    2. From a command prompt on a client workstation, execute the following command:

    net use X: \\nw_cluster_object_server\vol1

    This example connects drive "X" to volume one on the shared disk.

  2. Create a directory on the cluster shared disk named DEMODATA2.
  3. From the controlling cluster node, copy all of the files from the directory of the sample database DEMODATA to the DEMODATA2 directory. By default, DEMODATA is located at SYS:\PVSW\DEMODATA.
  4. In PCC Pervasive.SQL Explorer, right-click on the Databases node for the server name of the cluster shared disk. Click New then Create Database to start the Create Database dialog.



  5. Type and name and location for the database.

    6. For database name, type in DEMODATA2. For location, type in directory location on the server name and volume for the shared disk. For example, if you have a drive mapped to the shared disk in Windows File Explorer, view the mapped name. The following image shows that the shared disk is mapped to volume Clshared on server Nw5clvirt.



    The directory location, then, would be Nw5clvirt\Clshared\DEMODATA2. Ensure that the Create DSN option is selected (it is by default).



    The dialog creates the engine DSN for the database. You next use the ODBC Administrator to create the client DSN.

  6. Open the ODBC Administrator. For example, click Start4Settings4Control Panel4Administrative Tools, then double-click Data Sources (ODBC).

    7. Note that the steps to invoke the ODBC Administrator may differ depending on which Windows 32-bit platform you use. You may also open the ODBC Administrator from within PCC by clicking Tools 4 ODBC Administrator.

  7. Click the System DSN tab.
  8. Click Add. The Create New Data Source dialog appears.
  9. In the list, click Pervasive ODBC Engine Interface.
  10. Click Finish. The Pervasive ODBC Engine DSN Setup dialog appears.
  11. For Data Source Name, type in DEMODATA2. For Address, type in the server name of the shared disk.

    12. For Address, type in directory location on the server name and volume for the shared disk. For example, if you have a drive mapped to the shared disk in Windows File Explorer, view the mapped name and use that. See Step 5.

  12. Click the Get DSN List button then select DEMODATA2 in the list.

    13. The following example shows that the server name and volume is NW5CLVIRT\CLSHARED.



  13. Click Test. A successful test indicates that the client DSN is communicating with the engine. Click OK to dismiss the Test Connection message box.
  14. Click OK to close the Pervasive ODBC Client DSN Setup dialog.
  15. Click OK to close the ODBC Data Source Administrator dialog.
  16. From the server that is hosting the shared disk, copy SYS:\ODBC\odbc.ini and SYS:\SYSTEM\dbnames.cfg to the other cluster nodes. (Alternatively, you could migrate to each cluster node and create the DEMODATA2 DSN on that node.)

    17. The next two steps, 17 and 18, require that you have administrator authority.

  17. For NetWare 5.1, click on the cluster shared object then click View4Cluster State. Click the Cluster State tab. For NetWare 6.x, right-click on the cluster shared object, click Views 4 Cluster State Views then click the Cluster State View tab.

    18. In the right pane, click on the Location that is controlling the shared resource.



    For NetWare 6.x, it is the Location controlling the pool manager for the shared resource.

    The Cluster Resource Manager dialog appears.

  18. Click on a migration target, then click Migrate. For example, the following image shows NW_Cluster_B as the migration target.



    19. The migration target becomes active and assumes control of the shared disk. In the ConsoleOne interface, you will see the location change to the migration target and the number of lives (#Lives) increment by one.

  19. Open the ODBC Administrator.
  20. Click the System DSN tab.
  21. Double-click the DEMODATA2 DSN. The Pervasive ODBC Client DSN Setup dialog appears.
  22. Click Test. A successful test indicates that the client DSN is communicating with the engine. Click OK to dismiss the Test Connection message box.
  23. Click OK to close the Pervasive ODBC Client DSN Setup dialog.

Chapter contents
Publication contents

Prev topic: Microsoft Cluster Service
Next topic: Workgroup Engine in Depth