3.5.1 Matrix Server Administration Guide

Chapter 12: Configure Virtual Hosts 215

Virtual Hosts and Failover

When you create a virtual host, you specify a list of network interfaces on

which the virtual host can be located. The interfaces are placed in order:

primary, backup #1, backup #2, and so on. The ClusterPulse process

considers the “health” of the servers providing those interfaces when

determining where to place a virtual host. The status and enablement of

the service and device monitors associated with the virtual host also

contribute to a server’s health calculation. When a server is completely

“healthy,” all of the services associated with the virtual host are up and

enabled.

When certain events occur on the server where a virtual host is located,

the ClusterPulse process will attempt to fail over the virtual host to

another server configured for that virtual host. For example, if the server

goes down, ClusterPulse will check the health of the other servers and

then determine the best location for the virtual host.

ClusterPulse uses the following virtual-host activeness policy to

determine the server where it will make a virtual host active. In

conjunction with this policy, the decisions that you make when

configuring a virtual host and the service or device monitors associated

with it help determine whether virtual host failover occurs, the interface

to which the virtual host will fail over, and what happens when

operations are restored on the original server.

Virtual Host Activeness Policy

The policy described here is accurate for this release but it may change in

future releases. The virtual host activeness policy is as follows:

1. If the virtual host is disabled, it is not made active anywhere.

2. ClusterPulse considers the list of servers that are both up and enabled

and that are configured for the virtual host. The network interface that

the virtual host is associated with must also be both up and enabled

for hosting. Note the following:

• A server that has not finished joining the matrix (see “Server

Access to the SAN” on page 283) is not considered up for the

purpose of activating the device monitor.