This is divided into four parts description of installation process of TIBCO domain on Windows 2008 R2 Failover Cluster. The aim of this is to get running on two hosts fault-tolerant TIBCO domain which contain two TIBCO EMS servers. Each TIBCO EMS server is running as cluster application and use cluster disk for data store. This solution helps to get fault-tolerant TIBCO EMS design and there is no need to have shared volumes, which is expensive solution and not available on the Windows platform yet (CSV is recently appeared exclusion made for Hyper-V). The final configuration shown in the TIBCO Administrator screenshot on the right, where is S-TST01-TIB01 is the first node and S-TST02-TIB01 is the second node. TIBCO Administrator is running on each node as master/secondary pair. Test application is running on the same hosts as fault-tolerant group in active/standby mode. But the most interesting part of domain is TST00-TIB01 – cluster service which acting as virtual host where both EMS servers live in TIBCO domain. I will explain from the beginning.

First of all I’m going to prepare two nodes cluster. Base software is MS Windows Server 2008 R2 Enterprise Edition. Here are two disk connected to both cluster nodes. In my case storage system connected to servers via iSCSI interface. Two volumes were prepared: one small 5G will be act as cluster quorum disk, second large 50G will be used for clustered application data store. Both are raw volumes at this time.

I’m going to put both volumes online and initialize it. If you will do it like me, do it only on one node! After this step I can create NTFS file system on quorum disk. Start “New Simple Volume Wizard”, let it to use whole disk, assign drive letter, I prefer “Q” for quorum, then perform a quick format with default settings.

I suppose that both my nodes are ready for failover cluster. But the best practice to check it before. So, I will start cluster validation process. Here a lot of steps for testing cluster core resources availability such as network and storages. During testing, access to shared volumes will be checked from both nodes. After completion of testing, validation report will be generated. In my case warning message was received as my network adapter has no redundancy: between my servers only one network path and it will be a single point of failure. In production cluster it is better to avoid things like this, I will correct this before going to production.

As all other things were good, I’m ready to create failover cluster. I just start “Create Cluster Wizard” and add the names of all the servers that I want to have in the cluster. Then type the cluster name. After confirmation, cluster creation and configuration process will be running. When cluster will be formed, summary message and final report will be generated. Everything looks very good in my case, so I’m ready to prepare storage for cluster data disk. In future, it will be used as storage for TIBCO EMS and TIBCO Hawk. The steps are the same as for quorum disk: “New Simple Volume Wizard”, drive letter assign, let it be “T” for TIBCO, NTFS quick format.

After that my storage is available as cluster resource and I’m prepared to create cluster resources that will be used for TIBCO services. I will start with “Create Empty Service or Application” action, then rename this new service to TST00-TIB01 and add client access point with the same name: TST00-TIB01. IP address will be assigned automatically by DHCP. Then it’s time to add storage to this service. I will select my available Cluster Disk 1.

Last step is bring this service group online. At this point of time both nodes are ready for TIBCO software installation. I will continue from this point in the part 2.

tags: cluster, installation, tibco, windows

For training on TIBCO EMS mail us at [email protected]

On the Process Server, you can deploy the snapshot of a process application. The process application snapshot acronym is used to uniquely identify the version.
For process application snapshot deployments, the version context is a combination of the following items:

• Process application name acronym
• Process application snapshot acronym

Resources should be uniquely named and identified externally using the version context. The following table shows an example of names that are uniquely identified:

A resource, such as a module or library, has the version context as part of its identify.
The following table shows an example of two modules and how the associated EAR files include the version context:

The following table shows an example of two process-application-scoped libraries and how the associated JAR files include the version context:

On the IBM Process Center server, you can deploy a snapshot of a process application as well as a snapshot of a toolkit. In addition, you can deploy the tip of a process application or the tip of a toolkit. (A tip is the current working version of your process application or toolkit.) The version context varies, depending on the type of deployment.

For process applications, the process application tip or the specific process application snapshot is used to uniquely identify the version.

Toolkits can be deployed with one or more process applications, but the lifecycle of each toolkit is bound to the lifecycle of the process application. Each process application has its own copy of the dependent toolkit or toolkits deployed to the server. A deployed toolkit is not shared between process applications.

If the track associated with the process application is named something other than the default of Main, the track acronym is also part of the version context.

For more information, see the Examples section, later in this topic.

Process application snapshots
For process application snapshot deployments, the version context is a combination of the following items:

• Process application name acronym
• Process application track acronym (if a track other than Main is used)
• Process application snapshot acronym

Stand-alone toolkits
For toolkit snapshot deployments, the version context is a combination of the following items:

• Toolkit name acronym
• Toolkit track acronym (if a track other than Main is used)
• Toolkit snapshot acronym

Tips
Process application tips are used during iterative testing in Process Designer. They can be deployed to Process Center servers only.
For process application tip deployments, the version context is a combination of the following items:

• Process application name acronym
• Process application track acronym (if a track other than Main is used)
• "Tip"

Toolkit tips are also used during iterative testing in Process Designer. They are not deployed to a production server.
For toolkit tip deployments, the version context is a combination of the following items:

• Toolkit name acronym
• Toolkit track acronym (if a track other than Main is used)
• "Tip"

Examples
Resources should be uniquely named and identified externally using the version context.

• The following table shows an example of names that are uniquely identified. In this example, a process application tip uses the default track name (Main):

Any SCA modules associated with this process application tip include the version context, as shown in the following table:

Any SCA modules associated with this process application tip include the version context, as shown in the following table:

Similar naming conventions apply to advanced Toolkit tip and snapshot deployments. They also apply to advanced snapshots installed to Process Server.

• The following table shows an example of names that are uniquely identified. In this example, a process application snapshot uses the default track name (Main):

Any SCA modules associated with this process application snapshot include the version context, as shown in the following table:

Any SCA modules associated with this process application snapshot include the version context, as shown in the following table: