This section includes the following topics:

Zen is compatible with numerous solutions that maximize uptime in physical and virtual environments. Such solutions continually evolve but can be classified generally as high availability, fault tolerance, and disaster recovery.

The definition of high availability can differ depending on the software vendor that provides high availability solutions. In general, it refers to a systems design approach for a predictable baseline level of uptime, despite hardware failure, software failure, or required maintenance.

A common approach to ensure high availability in a physical environment is failover clustering. A common approach in a virtual machine (VM) environment is migration.

Zen is designed to function as a resource in a failover cluster environment in which only one server node at a time accesses the shared storage subsystem. If the primary node fails, a failover (or switch) to a secondary node occurs. Failover clustering allows a system to remain available while you perform software upgrades or hardware maintenance.

Zen is compatible with Microsoft Failover Cluster Services and with Linux Heartbeat. Refer to the documentation from those vendors for the specific manner in which they define and implement failover clustering. Zen Enterprise Server and Cloud Server are the recommended editions for failover clustering.

See Failover Clustering.

In general terms, migration allows a running VM or application to be moved between different physical machines without disconnecting the client or application. The memory, storage, and network connectivity of the VM are typically migrated to the destination.

Zen is compatible with the migration capability offered by Microsoft Hyper-V, VMware vSphere, and Citrix XenServer. As long as host names remain the same after the VMs are moved, Zen continues to operate normally. See the documentation from those vendors for the specific manner in which they define and implement migration.

See Migration.

While high availability aims for a predictable baseline level of uptime, fault tolerance is the uninterrupted operation of a system even after the failure of a component. Fault tolerance requires synchronized shared storage. In virtualized environments, the VM that fails must be on a different physical host from the VM that replaces it.

Fault tolerance can be achieved using just physical machines. However, virtual environments lend themselves so readily to maintaining virtual servers in lockstep with each other that exclusively physical environments are increasingly less common. Zen servers are compatible with fault tolerance capabilities in an exclusively physical environment.

For virtual environments, Zen is compatible with the fault tolerance capability offered by VMware vSphere and Citrix XenServer. Refer to the documentation from those vendors for the specific manner in which they define and implement fault tolerance.

See Fault Tolerance.

Disaster recovery involves duplicating computer operations after a catastrophe occurs and typically includes routine off-site data backup as well as a procedure for activating vital information systems in a new location.

Zen is compatible with major hypervisors that support disaster recovery technology that initializes backup physical or virtual machines. As long as all host names remain the same after the VMs are moved, Zen continues to operate normally. This allows rapid server replacement and recovery time.

Refer to the documentation from the hypervisor vendors for the specific manner in which they define and implement disaster recovery.

See Disaster Recovery.

For all of the technologies mentioned in this section, we recommend that you select servers, disk subsystems, and network components from the hardware compatibility list provided by the vendor. We follow this same practice when testing for compatibility with vendor products.

Failover clustering provides a group of independent nodes, each with a server, all of which have access to a shared system of shared data files or volumes. The failover services ensure that only one server at a time controls data files or storage volumes. If the currently active server fails, then control is passed automatically to the next node in the cluster, and the server on that node takes over.

In Zen, only one database engine can service data. In a cluster, because a Zen engine is installed on every node, you must configure these engines so that they appear as a single engine, and not the multiple engines that they actually are.

Each Zen engine must be licensed separately for each cluster node while the node is Active. This is for both physical and virtual machines. The license type used for each node is Enterprise Server - Active-Passive. A standard Enterprise license cannot be authorized on both nodes.

This section covers the following topics:

This topic covers adding a Zen engine service to a Microsoft failover cluster and assumes the following:

Here are the steps for creating a Windows failover cluster with Zen engines.

The following table gives the recommended steps to add Zen to a failover cluster in Windows Server.

The failover cluster is now configured. Remember that when failover occurs, client connections may also fail and require restarting of client applications.

The Heartbeat program is one of the core components of the Linux-HA (High-Availability Linux) project. Heartbeat runs on all Linux platforms and performs death-of-node detection, communications and cluster management in one process.

This topic discusses adding the Zen engine service to Linux Heartbeat and assumes the following:

It is essential that Linux Heartbeat be functioning correctly before you add Zen to the cluster. See the documentation from the High-Availability Linux Project (www.linux-ha.org) for how to install Heartbeat, verify that it is working correctly, and perform tasks with it.

Just as you would for any application, set up the essential clustering components before you add Zen.

The following table gives the recommended steps to add Zen to Linux Heartbeat.

After you install Zen in a failover cluster environment, you can manage it as a resource. The following items discuss common management topics:

The normal Zen licensing and machine maintenance procedures also apply to the nodes in a failover cluster environment. Deauthorize the Zen key before you modify the configuration of the physical or virtual machine where the database engine is installed. Reauthorize the key after changes are complete.

See To Deauthorize a Key and To Authorize a Key in Zen User’s Guide.

If a cluster node fails, a Zen client does not automatically reconnect to the Zen engine on the surviving node. Your application must reconnect the client to the Zen database or you must restart the application. This applies even if Enable Auto Reconnect is turned on for the database engine.

If transaction durability is turned off and a failure occurs before a transaction completes, the transaction is automatically rolled back to its state before the transaction began. That is, to the last completed check point. The rollback occurs when the active server requests access to the data file.

If transaction durability was turned on, completed changes can be recovered that occurred between the time of the cluster node failure and the last check point. Transaction durability must be configured the same way on all nodes and the transaction log located on the shared storage. Transactions that had not completed at the time of the cluster failure, however, are lost even if transaction durability was in effect.

A cluster failover occurs from the active node if you manually stop the Zen database engine service through the operating system. If you are performing service node maintenance and want to avoid such a failover, stop the service through the cluster utilities.

Some configuration changes require that you restart the database engine. See Configuration Reference.

Use the following steps in the Windows Cluster Administrator in the order listed:

At some point, you may need to patch Zen or the failover cluster software. To help you do so, Actian Technical Support provides a knowledge base article on this topic.

Migration moves a VM running Zen from one physical host to another. The memory, storage, and network connectivity of the VM are typically migrated to the destination. Depending on the hypervisor, migration is sometimes referred to as "live" migration or "hot" migration.

With a "live" or "hot" migration, client connections to Zen remain intact. This allows changes to hardware or resource balancing. With a "cold" migration, network connectivity is interrupted because the VM must boot. Client connections to Zen must be reestablished.

A migration environment has only one instance of Zen running, which makes the environment somewhat vulnerable if the host machines crashes or must be quickly taken offline. Also, if the shared storage fails, the database engine cannot process reads from or writes to physical storage. Some hypervisors offer a migration solution that does not use shared storage.

As long as host names remain the same after the VM migrates, Zen continues to operate normally. The product key remains in the active state.

No special steps are required to install or configure Zen in a migration environment. Refer to the hypervisor documentation.

A fault tolerant environment is similar to a migration environment but includes additional features to ensure uninterrupted operation even after the failure of a component. A fault tolerant environment ensures network connections, continuous service, and data access through synchronized shared storage. If a component switch occurs, client machines and applications continue to function normally with no database engine interruption.

No special steps are required to install or configure Zen in a fault tolerant environment. Refer to the hypervisor documentation.

Disaster recovery includes data recovery and site recovery. Data recovery is how you protect and restore your data. Site recovery is how you protect and restore your entire site, including your data.

Data recovery is facilitated with the hypervisor shared storage and Zen transaction logging and transaction durability. See Transaction Logging and Durability. You can use transaction logging and transaction durability with Zen Enterprise Server and Cloud Server.

Site recovery can be accomplished with both physical machines and virtual machines. Zen operates normally provided that host names remain the same in the recovered site. This is typically the case for virtual machines. If you are recovering physical machines and the host name at the recovery site is different, the Zen product keys will change to the failed validation state when Zen starts. Zen will continue to operate normally in the failed validation state for several days, during which you can either repair the key or move back to the original site.

No special steps are required to install or configure Zen in a disaster recovery environment. Refer to the hypervisor documentation.