docs.intersystems.com
Home  /  Architecture  /  High Availability Guide  /  Using Windows Clusters with InterSystems IRIS


High Availability Guide
Using Windows Clusters with InterSystems IRIS
[Back] 
InterSystems: The power behind what matters   
Search:  


The Microsoft Windows Server platforms allow you to create an OS-level failover cluster on two or more nodes. You can then group and configure a set of shared resources—called a service in Windows Server 2008, a role in Windows Server 2012, and a group in Windows Server 2003—that runs on one cluster node but fails over to another if the original node fails. By grouping shared RAID or SCSI storage devices, IP addresses, and InterSystems IRIS instances in this way, you can create InterSystems IRIS failover clusters. (This chapter uses the term “service” from this point forward.)
Starting with one service, you can configure a single failover InterSystems IRIS™ cluster, in which one or more InterSystems IRIS instances run on the active node, failing over to a standby node if the active node goes down. You can also use multiple services to configure a multiple failover InterSystems IRIS cluster, in which multiple InterSystems IRIS instances run on different nodes, each instance failing over to another node if its host node goes down.
Before you add an InterSystems IRIS instance to a service as a shared resource, the service must include a shared IP address resource that clients will use to connect to InterSystems IRIS and a shared storage resource that will provide access to all storage used by the InterSystems IRIS instance. When you add the InterSystems IRIS instance, it must be dependent on these resources, meaning that InterSystems IRIS cannot run unless the IP address and storage are available.
For an InterSystems IRIS instance to be included in a service as a shared resource, it must be identically installed on all of the cluster’s nodes, so that each node can run InterSystems IRIS using the software, system files and databases on the shared storage. From the perspective of client connections to InterSystems IRIS, there is no change in the instance when it fails over from one node to another; the IP address for the instance—that is, the shared IP address—remains the same.
Important:
Before creating an InterSystems IRIS cluster in Windows Server systems, it is important to thoroughly understand Windows Server clustering technology. Go to http://technet.microsoft.com to obtain information about configuring OS-level failover clusters on the Windows Server version you are using.
This chapter contains the following subsections:
InterSystems IRIS Failover Cluster Examples
This section provides simple examples of a single failover InterSystems IRIS and a multiple failover InterSystems IRIS cluster. Bear in mind that the maximum number of nodes in a Windows Server failover cluster is eight (Windows Server 2003), 16 (Windows Server 2008), or 64 (Windows Server 2012), and that a service can be configured on multiple nodes. This means that InterSystems IRIS clustering topologies much more complex than those shown here can be created.
Single Failover Cluster Example
The following illustration shows a single failover InterSystems IRIS cluster on two nodes.
Single Failover InterSystems IRIS Cluster
InterSystems IRIS instance C runs on node A, accepting client connections to shared IP address I and using storage on shared storage array RAID D. Note that IP address I is not the IP address of the cluster or of either node, but rather one dedicated to the service and shared within it. Note also that InterSystems IRIS instance C is installed on node B but inactive.
If cluster node A fails, the cluster looks like the following after failover has occurred:
Single Failover InterSystems IRIS Cluster After Node Failure
InterSystems IRIS instance C is still accepting client connections to shared IP address I and using storage on shared storage array RAID D, but it is now running on node B.
Multiple Failover Cluster Example
The following illustration shows a multiple failover InterSystems IRIS cluster on two nodes.
Multiple Failover InterSystems IRIS Cluster
In service A, InterSystems IRIS instance C.A runs on node A, accepting client connections to shared IP address I.A and using storage on shared storage array RAID D.A; instance C.A is installed on node B but inactive. In service B, InterSystems IRIS instance C.B runs on node B, accepting client connections to shared IP address I.B and using storage on shared storage array RAID D.B; instance C.B is installed on node A but inactive.
If cluster node A fails, the cluster looks like the following after failover has occurred:
Multiple Failover InterSystems IRIS Cluster After Node Failure
InterSystems IRIS instance C.A is still accepting client connections to shared IP address I.A and using storage on shared storage array RAID D.A, but is now running on node B. InterSystems IRIS instance C.B in service B is unaffected.
Creating an InterSystems IRIS Failover Cluster
This section provides procedures for creating the single failover InterSystems IRIS cluster described in Single Failover Cluster Example. They can be adapted to the multiple failover InterSystems IRIS cluster described in Multiple Failover Cluster Example by adding a second InterSystems IRIS instance to a second service, with the services having different preferred owners; this model can be extended in similar fashion to three or more nodes.
Note:
As noted in the procedure, you can include multiple InterSystems IRIS instances in a single service, whether in a single or multiple failover cluster; if you do so, they will all fail over together.
To create the single failover InterSystems IRIS cluster, you must
Create a Cluster Service with Shared IP Address and Storage
The name of the Windows Server cluster manager and the label it uses for the required cluster service depend on the version of Windows Server you are using. The instructions in the following sections use Windows Server 2008 terminology and labels.
If you are using Windows Server 2008, consult the appropriate Microsoft documentation at http://technet.microsoft.com for information about using the Failover Cluster Manager tool to create a service. If using Windows Server 2012, consult the appropriate documentation for using Failover Cluster Manager to create a role instead; if Windows Server 2003), use Cluster Administrator to create a group.
As previously noted, before InterSystems IRIS is installed, the service (or role, or group) must include a shared IP address resource and a shared storage resource. All storage to be used by the InterSystems IRIS instance to be installed must be on this shared storage resource.
Note:
For various reasons including deployment flexibility, InterSystems recommends that OS-level failover clustering and InterSystems IRIS failover clustering use separate services. For example, a quorum disk should be in an OS-level service, and the shared disk on which InterSystems IRIS is installed should be in a separate service, with similar treatment of shared IP addresses and other shared resources.
Install InterSystems IRIS
Install an instance of InterSystems IRIS on each cluster node, as follows. (For general information about installing InterSystems IRIS the Installing InterSystems IRIS on Microsoft Windows chapter of the Installation Guide.)
  1. Install InterSystems IRIS on the shared disks on the first cluster node on which the cluster service (or role, or group) is running.
  2. To enable the cluster manager to start InterSystems IRIS, you must change the automatic startup setting of the newly installed instance by navigating to the Memory and Startup page (System Administration > Configuration > System Configuration > Memory and Startup) and clearing the Auto-start on System Boot check box. (For information about this and other memory and startup settings see Configuring System Information in the “Configuring InterSystems IRIS” chapter of the System Administration Guide.)
  3. The recommended best practice is to manage the cluster remotely from the launcher on a workstation connecting to the cluster IP address. To ensure that the InterSystems IRIS launcher is not used locally on this cluster node, remove the shortcut that starts the launcher on Windows logon from the Windows Startup folder (C:\Documents and Settings\All Users\Start Menu\Programs\Startup). The shortcut has the same name as the instance.
  4. Stop InterSystems IRIS. (This prevents the instance from being locked to the current node.)
  5. Move the cluster service to the second cluster node.
  6. Install InterSystems IRIS on the second cluster node. The instance must be installed with the same name and in the same directory as the instance on the first cluster node, using all the same install options.
  7. Disable automatic startup and remove the launcher icons from the Startup folder as described in earlier steps for the first cluster node.
  8. Stop InterSystems IRIS.
Note:
If any InterSystems IRIS instance that is part of a failover cluster is to be added to an InterSystems IRIS mirror, the ISCAgent, which is installed with InterSystems IRIS, must be properly configured; see Configuring the ISCAgent in the “Mirroring” chapter of this guide for more information.
For information about upgrading InterSystems IRIS in an existing failover cluster, see Upgrading a Cluster in the “Upgrading InterSystems IRIS” chapter of the Installation Guide.
Create an InterSystems IRIS Resource
When you install InterSystems IRIS on an active cluster node, a new shared resource type, ISCCres2003, is added to Failover Cluster Management (or Cluster Administrator). Add a resource of this type to the service (or role, or group), and ensure that its properties reflect the following:
  1. On the General tab of Failover Cluster Management, enter an appropriate name for the resource.
  2. On the Dependencies tab, create dependencies on the shared physical disk resource and the shared IP address resource.
  3. On the Policies tab:
  4. On the Advanced Policies tab:
    Important:
    When adding multiple InterSystems IRIS cluster resources to a service, select Run this resource in a separate Resource Monitor on the Advanced Policies tab for the second resource you add and every subsequent resource. If multiple InterSystems IRIS instances within a service do not run in separate resource monitors, failover does not function properly.
  5. On the Parameters tab, in the Instance text box, enter the name of the InterSystems IRIS instance you installed on the cluster nodes.
Important:
Once you have created an InterSystems IRIS failover cluster, as a precaution, always shut down an InterSystems IRIS instance by using Failover Cluster Manager or Cluster Administrator to take the resource representing it offline, rather than stopping InterSystems IRIS using the InterSystems IRIS launcher (cube) or a command-line operation. For example, if you are upgrading InterSystems IRIS, do not begin the upgrade procedure and allow the installer to stop InterSystems IRIS; instead, take the cluster resource offline, which stops InterSystems IRIS, then install the upgrade. While the cluster resource is offline, you can start and stop InterSystems IRIS as your needs dictate. When you are ready to resume operation of the cluster, bring the cluster resource back online.
Web Gateway Considerations
For high availability solutions running over CSP, InterSystems recommends that you use a hardware load balancer for load balancing and failover. InterSystems requires that you enable sticky session support in the load balancer (see your load balancer documentation for directions on how to enable sticky session support); this guarantees that — once a session has been established between a given instance of the gateway and a given application server — all subsequent requests from that user run on the same pair. This configuration assures that the session ID and server-side session context are always in sync; otherwise, it is possible that a session is created on one server but the next request from that user runs on a different system where the session is not present, which results in runtime errors (especially with hyperevents, which require the session key to decrypt the request).
Note:
It is possible to configure a system to work without sticky sessions but this requires that the CSP session global be mapped across all systems in the enterprise and can result in significant lock contention so it is not recommended.
InterSystems IRIS protects server passwords in the Web Gateway configuration file (CSP.ini) using Windows DPAPI encryption. The encryption functions work with either the machine store or user store. The web server hosting the Web Gateway operates within a protected environment where there is no available user profile on which to base the encryption; therefore, it must use the machine store. Consequently, it is not possible to decrypt a Web Gateway password that was encrypted on another computer.
This creates a situation for clustered environments in which the CSP.ini file is on a shared drive and shared among multiple participating computers. Only the computer that actually performs the password encryption can decrypt it. It is not possible to move a CSP.ini file containing encrypted passwords to another computer; the password must be reentered and re-encrypted on the new machine.
Here are some possible approaches to this issue:
See the Web Gateway Configuration Guide for more information.