Understanding the Waveset High-Availability Feature Set

Waveset is designed to leverage HA infrastructure if it is available. For example, Waveset does not require an application server cluster to achieve high availability, but it can utilize a cluster if it exists.

The following diagram shows the major Waveset components deployed in a non-redundant architecture. The sections that follow will describe how the Waveset repository, application server, and gateway can be made highly-available.

Figure 3–1 Waveset Standard System Architecture

See Understanding the System Separation and Physical Proximity Guidelines for information on which components should be physically sited near one another in order to minimize performance issues that could arise due to latency and network congestion.

Making the Repository Highly-Available

Waveset stores all of its provisioning and state information in the Waveset repository.

The availability of the database instance storing the Waveset repository is the most critical piece to achieving a highly available Waveset deployment. The repository is the representation of the entire Waveset installation and the data within it must be protected as with other important database applications. At minimum, regular backups must be performed.

Do not host the Waveset repository on a virtual platform such as a VMware virtual machine because performance (transactions per second) will be hindered significantly.

There can only be one image of the repository. It is not possible to have two separate databases for Waveset and attempt to synchronize them nightly. Oracle recommends using your database's clustering or mirroring capabilities to provide fault tolerance.

Making the Application Server Highly Available

Waveset can run within an application server cluster and take advantage of the added availability and load balancing that a cluster provides. Waveset does not use any J2EE features that require clustering, however.

Waveset uses the HTTP Session object that is available through the Servlet API. This session object tracks a user's visit as the user logs in and performs actions. In a cluster, you can optionally have multiple nodes handle a user's requests during a given session. This is usually not recommended, however, and most installations are configured to send a user's entire request for a given session to the same server.

It is possible to add additional availability and capacity to the application server running Waveset even if you do not set up a cluster. This is achieved by installing multiple application servers with Waveset, connecting them to the same repository, and putting a load balancer with session affinity in front of all the application servers.

For more information on session affinity, see Frequently Asked Questions Regarding Session Affinity and Session Persistence.

Waveset runs certain tasks in the background—for example, scheduled reconciliation tasks. These tasks are stored in the database and can be picked up by any Waveset server to run. Waveset uses the database to ensure that these tasks are always run to completion, even if it has to fail over to another node.

Configuring Active Sync Clustering on Application Server Nodes

The sources.hosts setting in the Waveset.properties file controls which hosts in a multi instance environment are used for executing Active Sync requests. This setting provides a list of hosts that source adapters can run on. Setting this to localhost or null will allow source adapters to execute on any host in the web farm. (This is the default behavior.) By listing one or more hosts, you can restrict execution to that list. If you have inbound updates from another system that go to a particular host, use the sources.hosts setting to record the host names.

In addition, you can define a property named sources.resourceName.hosts, which controls where the resource's Active Sync task will run. Replace resourceName with the name of the resource object you wish to specify.

Making the Gateway Highly Available

Waveset requires a lightweight gateway to manage resources that cannot be directly accessed from the server. These include systems that require client-side API calls that are platform specific. For example, if Waveset is running on a UNIX-based application server, the ability to make NTLM or ADSI calls to managed NT or Active Directory domains is not possible. Because Waveset requires a gateway to manage these resources, it is important to ensure that the Waveset Gateway is made highly available.

To prevent the Gateway from becoming a single point of failure, Oracle recommends having multiple machines running a Gateway instance. A network routing device or load balancer should be configured to provide failover if the main Gateway instance dies. The failover device should be configured to use sticky sessions. A failover device without sticky sessions is not a supported configuration and will cause certain Waveset functions to fail.

All Windows domains managed by a Gateway must be part of the same forest. Managing domains across forest boundaries is unsupported. If you have multiple forests, install at least one Gateway in each forest.

Win32 monitoring tools can be configured to watch the gateway.exe process on the Win32 host. In the event that gateway.exe fails, the process can be automatically restarted.