3.6.0 MxDB for SQL Server Installation and Administration Guide (5697-7088, December 2007)

Chapter 2: Introduction 4

Active-Passive Architecture

MxDB for SQL Server uses an Active-Passive architecture for

high-availability. For example, when you virtualize a SQL server instance

in a two-node cluster, you declare one node to be the active, or primary,

node for the instance and the second node to be the backup. The

high-availability engine provided with MxDB for SQL Server then creates

the appropriate profiles for the virtualized instance.

A profile is a container consisting of the SQL data (that is, databases and

logs) and the corresponding registry setting necessary for starting an

instance of SQL Server. The Active-Passive architecture uses an “N+1”

model in which there is a local profile (an “N” profile”) for each node

participating in the Virtual SQL Server plus a cluster profile (the “+”

profile) that runs on the active node for the Virtual SQL Server.

For example, in a two-node cluster there are three profiles: the two local

profiles (N) and a clustered profile (+1). The clustered profile can move

around the cluster, and when mounted on a node, it turns the state of the

node from passive to active. At any one point in time, the node running

with the clustered profile (the “+1” profile) is the active node and all other

nodes are passive (that is, running with their local “N” profiles).

On the PolyServe Management Console, the active node is specified as

the primary node and the passive nodes are specified as backup nodes.

Throughout this guide, the primary and backup designations are used to

refer to the active and passive nodes.

Plan Your SQL Configuration

Before installing SQL Server, it is important to determine how the SQL

Server instances should be configured across the matrix. First determine

the number of SQL instances that you will need. These instances can be

installed on any node in the matrix.

Next, determine how you want to associate the instances with Virtual

SQL Servers. You could use a separate Virtual SQL Server for each

instance, you could assign all of the instances on a node to a single virtual

server, or you could use some other scheme.