TIE can be installed on a Windows 2008 cluster. Before installing TIE, ensure that the cluster is fully installed and set up, and set up the database that TIE will use. TIE can use a database server either on the same cluster, or another server somewhere else that may also be (would usually be) a cluster.
In addition to the database, TIE requires a cluster storage. This storage is used for
-
configuration information
-
LOINC and Snomed-CT caches
-
log files
-
Temporary storage for file processing
-
Script storage
In TIE, the location of logs and scripts is configurable; on a cluster, you must choose to store these on the cluster storage assigned to TIE when you are configuring it.
The base storage requirement - excluding logs and file processing requirements - is around 150MB. The overall size depends on configuration, how many log files and what their sizes are, and how many file interfaces, and how much information flows through them. Given the cost of setting up a cluster, and the importance of keeping TIE running, we recommend allocating at least 1GB more than the highest expected requirement.
Installing on a cluster
TIE must be installed on each node in the cluster. The first install is special: this "initial install" is responsible for creating or upgrading the TIE database and populating the TIE storage. All the following installs simply install the program files to each node and configure TIE to use the cluster storage. You must select the initial task in the installer ("Perform Initial Cluster Install" on the tasks page), or only a add-node install will be performed.
Note: if the task "Perform Initial Cluster Install" does not appear on the tasks page even though you are installing on a cluster, please consult TIE.com support.
The TIE Storage must be on-line on the node where the install is happening for the initial install. For the add-node installs, the storage does not need to be on-line. As additional nodes are added to the cluster, TIE must be installed on the node.
During the install, TIE will create a cluster application definition for TIE. This may fail for reasons related to network configuration. If it does, creating the TIE application definition is very straight forward. It is a Generic Service with the following properties:
-
The service "TIE"
-
The storage selected during the install
-
a virtual name and address.
The installation program will not bring TIE on line at the end of the install. The cluster administrator will need to at least configure the details of the ip address assigned to TIE.
If you are installing TIE to run on the same Cluster as Microsoft SQL Server:
By default, the installation configures the TIE service to run under the default account. On Windows Server, this is "Local System" or some equivalent. This local system account will be able to login to the SQL Server databases when both TIE and SQLServer are running on the same node, but not when they are on different nodes (assuming SQL Server is configured Active/Passive). If you want to be able to run TIE in a different node to SQLServer on the cluster, you will either need to configure SQLServer to used mixed-mode authentication, and give TIE a native SQL Server login when configuring the database connection, or configure the service to run under a correctly configured account
Uninstalling on a cluster
Because of the way the installation process works, the node from which the first install was done must be the last to be uninstalled, as it will remove the contents of the TIE storage. If you need to uninstall TIE from this node before removing it from the cluster, do the uninstall while the storage is off-line.
Development Environment
The Development Environment uses the cluster managed resources - you can only use it on the node that is active for TIE. Be sure to store any files you work with on the TIE storage to avoid confusing the Development Environment as it moves between nodes.
Fail Over Notes
TIE starts and stops fairly quickly - generally within a few seconds. SQL Server tends to do so a whole lot slower. If a node fails, and both SQL Server and TIE are transferred to a backup node, TIE must wait for the database. The standard approach to handling this - with service dependencies - isn't applicable. And cluster dependencies have additional side effects that means that these mightn't be an appropriate solution to this problem. As a consequence, when the TIE service is starting on a cluster, it will wait up to 90seconds for a database to be available, instead of 30 seconds like normal. If start up is slow, consult the TIE log too see why.