Defining Lines and Failover Association

Redundancy is a common way to improve resilience. By deploying Nevis components multiple times, it is easier to handle peak load and availability may be increased.

The line setup can be applied in this context.

note

The following applies to Instance patterns only. When Connector patterns are used the host names must be configured using variables. In this case you can use host or group variables to achieve the same result.

The following figures show example setups of Nevis with two lines, ideally hosted in separate data centers. Each line has one nevisProxy Instance and one nevisAuth Instance.

Setup 1: Active / passive setup

This is the default behavior when there are no lines declared in the inventory. This setup is appropriate when no remote session store for nevisAuth has been configured.

Inventory

groups:
- proxy:
 members: [ proxy1, proxy2 ]

- auth:
 members: [ auth1, auth2 ]

Setup 2: Multi-line setup with line preference

If possible, nevisProxy instances prefer to connect to endpoints in the same line. However, fail-over to the other line is allowed in case of failure.

Inventory

groups:
- proxy:
 members: [ proxy1, proxy2 ]

- auth:
 members: [ auth1, auth2 ]

- line1:
 members: [ proxy1, auth1 ]

- line2:
 members: [ proxy2, auth2 ]

Setup 3: Multi-line setup with hard separation

A nevisProxy instance should only connect to the nevisAuth instance in the same line. This setup may be used when data centers are isolated.

Inventory

groups:
- proxy:
 members: [ proxy1, proxy2 ]

- auth:
 members: [ auth1, auth2 ]

- line1:
 isolating: true
 members: [ proxy1, auth1 ]

- line2:
 isolating: true
 members: [ proxy2, auth2 ]

In the following text, it is assumed that there is a project with the following characteristics:

• The project contains 1 nevisProxy Instance pattern and 1 nevisAuth Instance pattern. The Deployment Target property of these patterns is set as follows:
  • nevisProxy Instance: proxy
  • nevisAuth Instance: auth
• There are other patterns in this project, which connect the nevisProxy Instance pattern with the nevisAuth Instance pattern, such as a Virtual Host pattern, an Application pattern and a Realm pattern.
• When deploying to proxy hosts, the configuration files for the nevisProxy Instance will be generated for each host in the group proxy.
  • The generated configuration files will specify the nevisAuth instance(s) that nevisProxy will connect to.
  • In the above example inventories, the proxy group always has two members. Thus two nevisProxy configurations will be generated: one for proxy1 and one for proxy2.
• Each generated configuration contains the nevisAuth instances to connect. For this purpose, the hosts in group auth are resolved.

There are two aspects to consider when defining lines and failover association:

• Sorting: When nevisAdmin 4 configures connections, for example from nevisProxy to nevisAuth, it sorts the target hosts by the number of common groups in the inventory. See Setup 2 below for an example.
• Isolation: Isolation is applied when the deployment target host is member of a group that has the setting isolating: true. This means that only members of this group are considered when nevisAdmin 4 configures connections between hosts. Hosts not in this group are skipped.

Setup 1

In setup 1, there are no common groups. nevisAdmin 4 uses the order of the members in the auth group when configuring both proxy hosts.

• proxy1 > auth1 first and auth2 as fall-back
• proxy2 > auth1 first and auth2 as fall-back

Setup 2

In setup 2, additional groups have been introduced to represent lines. Thus, the order is affected.

The nevisProxy instance on host proxy1 has one group, line1, in common with the nevisAuth instance on host auth1. It has no groups in common with auth2. Thus, nevisProxy on proxy1 will prefer to connect to auth1. The connections are:

• proxy1 > auth1 first and auth2 as fall-back
• proxy2 > auth2 first and auth1 as fall-back

Setup 3

In setup 3, both line groups have the isolating flag set. Therefore, after sorting the hosts, the hosts are filtered. The connections are:

• proxy1 > auth1 only
• proxy2 > auth2 only