If you currently run a production environment using high availability (HA) capabilities, replace those currently provided by Sybase Failover in either active-passive (standby) or active-active (companion) configurations, or the operating system–provided clusterware (for example, Sun Cluster and Veritas Cluster) with one of the Cluster Edition scenarios described below.
Choose and configure a failover scenario that best represents what your company would want given the service-level agreement requirements of the application and financial constraints.
1:1 active-passive
Cluster nodes and instances are set up in pairs with an idle (passive) node and instance that wait for the corresponding active node to fail. This scenario is cost effective only in extreme environments where requirements do not tolerate service degradation in any failover scenario—including multiple failures.
1:1 active-active
Cluster nodes and instances are set up in pairs, and each pair services a separate application and database (instance) while monitoring each other in “companion mode” in case the other fails. Although this scenario mimics the current Sybase HA option and provides full utilization of resources, service levels during failed-over processing degrades unless you maintain resource capacity during normal processing that is low enough (less than 50%) to provide sufficient capacity for a single instance to run the workload of both.
N:1 (N active nodes covered by a single passive standby node)
This scenario provides a single passive standby node and instance to monitor an arbitrary number of active instances. This is the most cost-effective scenario; multiple node failures that fail instances over to a single node can lead to a level of service degradation that can make this scenario unacceptable. Configure the passive node with addition capacity (for example, CPUs and memory) to mitigate the degradation in the most likely failover scenarios.
N:M (N active nodes and instances covered by M passive standby nodes)
This model provides an arbitrary number (M) of passive standby instances to monitor an arbitrary number (N) of active instances. This option reduces costs while covering most typical failure scenarios. The choice of the number of passive standby nodes is typically driven by cost, system-level mean time between failures (MTBF) statistics, and the business impact of running at degraded service levels in a multiple-node failure scenario. In most failure scenarios, you can configure passive nodes with additional capacity to mitigate this degradation.
