The ClusterIT utility -- Background
In the past, installing IDS in a Microsoft Cluster Environment tended to be a complicated and error-prone process because there was no tool supporting it. You had to create the required cluster resources manually by issuing several cluster commands. According to the documentation, there was no process for converting an already initialized and running IDS instance into a clustered instance capable of failing over to a second node in a MSCS configuration.
As a response to the need for an easier method for setting up IDS in a clustered environment, the ClusterIT utility was designed and developed. The overall purpose is to provide an automated process for the conversion of a running IDS instance to a cluster.
Microsoft Cluster Environment -- An overview
Figure 1 shows an example of a two-node MSCS cluster, where the cluster services have been already installed. There are a number of shared disks that can be moved from node A to node B.
Figure 1. MSCS cluster with two nodes having local and shared disks
Figure 2 shows the view from the Cluster Administrator. You see a cluster group for the whole cluster itself, containing a virtual IP address for the cluster and a virtual host name. Also a quorum resource, which is mandatory for a MSCS cluster, is located there.
Figure 2. Cluster administrator with shared disks an image
Principle of installing IDS on a MSCS cluster
The installation and configuration of IDS in a MSCS environment using the ClusterIT utility consists of two major steps:
- Install the IDS product, configure your instance, and create your database and tables normally, as if there were no cluster at all.
- At the very beginning, move all resources of the cluster to node A.
- Perform all your installation and configuration steps as if node A would be a non-clustered host.
- Convert the existing IDS instance to be used in the clustered environment
- Run the ClusterIT_A executable on node A to create all cluster resources automatically
- Run the ClusterIT_B executable on node B (which has no Informix software installed at that time) to complete the configuration of the cluster and make failover possible
Prerequisites and general architecture
As you can see in Figure 1, there are two types of disks available: local and shared. The described cluster solution is based on the following distribution of resources:
- Informix is installed on a local drive (INFORMIXDIR on a local drive)
- The chunks of the dbspaces are located on the shared disks
Showcase: Example of a step-by-step procedure
Install IDS and create an instance
- Install IDS with INFORMIXDIR on a local drive on node A.
- This procedure is not explained in detail here.
- Create the instance
- Call Instance Manager from the Start menu.
- Create a new instance with type typical.
- Specify a server number, and name your instance: example "ol_test".
- Leave the suggested defaults for service name and port number.
- Specify the password for the Informix user.
- On the last screen, keep the default, and click Finish.
- When you are asked for initialization of the instance, click No.
- When you are asked to skip the initialization, click Yes.
Now you have completed the first step of preparing your instance.
- Adapt the onconfig file and initialize your server:
- Change the path of the root chunk specified with the ROOTPATH parameter to a location on a shared disk
- Open an Informix command window with the correct environment for your instance from the Start menu.
- Make sure that the specified path for the root chunk exists and the file itself exists.
- Initialize the server manually by calling starts ol_test -iy.
- Verify that your instance is up and running with onstat -.
- Optionally, you can create a test database and some test tables (they are located in your rootdbs), for later test purposes.
In the steps so far, you have installed IDS on node A, created and configured an instance according to the requirements, initialized that instance and probably also created a database with some test tables.
Install and call ClusterIT_A on node A
After IDS is up and running on node A, install clusterIT on node A by calling setup.exe from the clusterIT subdirectory on the Informix RDBMS CD. You just need to specify a target directory for clusterIT, you can leave the default.
Then you call clusterIT_A.exe from the directory where it was installed. When the GUI is coming up for the first time, all fields are blank. You can see in Figure 3 an example of a filled in ClusterIT_A dialog, the meaning of all parameters is explained later in this article.
Figure 3. ClusterIT_A dialog (example)
Explanation of parameters -- ClusterIT_A
Some of the parameters are self-explanatory. In these cases, the explanation is not very detailed.
Table 1. Parameters for ClusterIT_A and their meaning
|DBSERVERNAME to be clustered||Specify the DBSERVERNAME of the instance you want to convert to a clustered instance here. In this example, ol_test|
|DBSERVERNAME when clustered||During the process of conversion to a cluster, the existing unclustered instance is renamed. Specify the name for the new clustered instance|
|Physical hostname primary node||Specify the physical hostname of node A|
|Informix password||Specify the password of the Informix user. The cluster setup requires you to have Informix installed in a domain, so make sure you have the correct domain password for the Informix user|
|Full path to the IDS directory on the Informix RDBMS CD||Specify the full path to the IDS subdirectory. This is required to find the compressed Informix Cluster DLL (ifxdb920.dl_) and extract it. (This might be also a subdirectory called IIF, depending on the compilation you have)|
|Informixdir||Specify the INFORMIXDIR directory where IDS is installed on node A. This directory must be on a local drive, that also exists on node B.|
|New virtual hostname for database host||During the cluster conversion process, a new virtual database host is created. Specify the NETBIOS hostname for that host.|
|Virtual IP address for the database host||Also, a new virtual IP address is created. The virtual hostname described in the previous field and this virtual IP address must match. So the DNS name resolution should map the hostname to the IP address. To check this, ping the virtual hostname and see which IP address is resolved|
|Subnetmask||This is a subnetmask to define the subnet where the new virtual IP address is located. While the IP address should be a free address within your network segment, the subnet mask should also be that one, that defines your segment|
|Network||Specify the name of network adapter where the IP address should be bound to. Often there is a distinction between a private network for a heartbeat connection only between the two nodes and a public network for the client access|
|Number of shared disks||Specify here the number of shared disks you have used to distribute your chunks|
|Shared disks for database||Specify the name of the shared disks. The names have to be specified exactly like they are displayed in the cluster administrator. To make this easier, you can choose them from a drop-down box. During the cluster conversion process, a new cluster group "INFORMIX" is created, and all specified shared disks are moved to that new group.|
When all entries are made, click Convert to Cluster !.
At the very beginning, some checks take place and then the cluster conversion takes place. A new cluster group INFORMIX, which must not exist at the beginning, is created together with new cluster resources, like a new virtual IP address and a new virtual database host name. The shared disks are moved to the INFORMIX group, and finally, a new resource of a virtual database server based on an Informix specific resource type is created.
After the successful conversion to cluster, the INFORMIX resource group and all of its resources should be online. This process completes very fast.
Install and call ClusterIT_B on node B
At the very beginning, node B does not have any Informix software installed. Only the operating system and the Microsoft Windows cluster services are installed, and even before starting on node A, it has been verified, that the shared disks can be moved to node B and are accessible from there.
You can either install ClusterIT on node B by calling setup.exe from the CD on node B, like on node A, or you can copy the directory where clusterIT has been installed on node A to node B. During the clusterIT run on node A, a file called clusterIT.ini is created containing the parameters specified on the GUI on node A.
Many of them are also required parameters for node B. There are two additional parameters that have to be specified, and the configuration of note B is complete.
Figure 4 shows the GUI from clusterIT_B.exe:
Figure 4. ClusterIT_B dialog (example)
Explanation of parameters - ClusterIT_B
Table 2. Parameters for ClusterIT_B and their meaning
|Physical hostname primary node||Specify the physical hostname of node A.|
|New virtual hostname for database host||This value has already been defined by the configuration of node A, and for node B you have to specify the identical value|
|Full Path to the IDS directory on the Informix RDBMS CD||Specify the full path to the IDS subdirectory. When you want to leave it the same as on node A, make sure that your CD is mounted on the same drive. This parameter is required for the clusterIT utility to be able to perform a silent installation of IDS.|
|Instance number||During the run of clusterIT_B on node B, IDS is installed silently. You have to specify which instance number the created IDS instance should get. Of course, it is preferred to use the same number as the instance on node A has.|
|Informixdir||Specify the identical INFORMIXDIR directory where IDS is installed on node A. This directory must be on a local drive, that exists on both nodes.|
|Informix password||Specify the password of the Informix user. The cluster set up requires you to have Informix installed in a domain, so make sure you have the correct domain password for the Informix user.|
|DBSERVERNAME when clustered||Specify the name for the new clustered instance on node A. This information is used to create an identical instance on node B.|
|Role separation||If you want to have your IDS installed on node B with role separation switched on, select this check box.|
After you have specified everything, click Convert to Cluster !.
The main tasks that are executed now, are the silent installation of IDS, the copy of the onconfig file from node A to node B as well as the installation of the Informix resource DLL on node B.
The conversion to cluster takes some time on node B, because of the execution of the silent installation. When it is finished, you get a dialog "Conversion to cluster finished successfully." Then you should be able to move the Informix group between the nodes A and B. To do this, open the Cluster Administrator, right-click the group INFORMIX and select Move Group.
At the end, you have an Informix Cluster Group containing a virtual IP address and hostname, a virtual database server, and a set of shared disks. That group can be moved from node A to node B and back. Clients connect to the virtual database server on the virtual host, so they don't care on which of the physical hosts (host A or host B) the Informix server is running.
This article explained the architecture of an Informix cluster solution on a two-node failover cluster using MCS. In addition, you should now know how to use the ClusterIT utility that is shipped together with IDS to easily set up all required cluster resources. After the ClusterIT utility has been successfully executed on node A as well as on node B, your Informix instance is ready for failover.
- developerWorks Information Management zone: Learn more about DB2. Find technical documentation, how-to articles, education, downloads, product information, and more.
- Stay current with developerWorks technical events and webcasts.
Get products and technologies
- Build your next development project with IBM trial software, available for download directly from developerWorks.
- Participate in the discussion forum.
- Check out developerWorks blogs and get involved in the developerWorks community.