VERICUT Users' Forum

BillH

VERICUT Specialist

From: Irvine, CA

Registered: 2004-10-08

Posts: 146

Website

Redundant server, license balancing, and license access

WARNING: A long rambling expose' of redundant license servers follows. You may want to get a large mug of coffee before starting.

This is a description of how SentinelLM behaves when using a redundant server configuration. It assumes you have a basic understand of "redundant servers". For much (much, much) more detail, refer to chapter 3 in the SentinelLM System Administrators guide, provided in pdf format in VERICUT's "license" folder. You will need something stronger than coffee to wade through this chapter.

In a redundant license configuration, VERICUT does not specify which of the 3 servers to request a license from. VERICUT only has the ability to request a license the SentinelLM client software built inside VERICUT. The content of the LSHOST environment variable determines which license server will be queried by the SentinelLM client. Keep in mind that VERICUT does not use LSHOST, the SentinelLM client software inside VERICUT uses LSHOST. LSHOST is only on the client side of the license process and has no effect on the license server or redundant server side.

Brief overview ...

In a typical VERICUT redundant license server configuration there are 3 license servers. They are started in order, the "lead" server first, then the 2 follower servers next. A special license file (known as a "redundant" license file) is configured by the site's administrator for these 3 servers. Our install documentation describes configuring the redundant license with all license "tokens" (each count for each license) assigned to the lead server. The 2 followers have no tokens, and are only available as a backup in case the lead server goes down.

On the computers that run VERICUT, the LSHOST environment variable is defined to identify the host names of the 3 servers, and the order in which the SentinelLM client software will search for a running server.

First, the server-side?

The redundant server configuration described in VERICUT's installation document is really a redundant server configuration with ?license balancing? disabled. License balancing is disabled when all license tokens are assigned to the lead server (the first server started). When the leader goes down, the tokens move to the next "follower" server in the list (the server order is set when you create the redundant license file). When the leader comes back up, the tokens do not move back to the leader because license balancing is disabled. Because the leader has no tokens and license balancing is disabled, requesting a license from the leader fails. It cannot ?borrow? licenses from the follower server.

Enabling license balancing allows the redundant servers to borrow license tokens from each other. You enable balancing by assigning at least one token of each license to be borrowed to each server. Thus, when the leader goes down (losing all his tokens), then comes back up, he can borrow tokens back from whichever followers have tokens. This is all fine and good, but ?

License borrowing requires each server have at least one token of each license that will be borrowed, and it cannot give up the last license token of each license. What this effectively does is reduce a user?s access to the total pool of licenses by two, for each license.

See the following scenario:
(V = Verification license, MS = Machines Simulation license, AD = AUTO-DIFF license)

.          You have a total pool of 10 V, 5 MS, 5 AD license tokens.
.          License servers are configured with balancing enabled and tokens distributed as ...

.               Server1: 8 V, 3 MS, 3 AD
.               Server2: 1V, 1MS, 1AD
.               Server3: 1V, 1MS, 1AD

In this scenario, any server can serve a maximum of 8 V tokens, 3 MS?s and 3 AD?s. If licenses are requested of Server 2, it can borrow tokens from either Server1 or Server3. But the last token of each license cannot be borrowed.

However, borrowing is different than redundant backup. When a server goes down, that server's tokens shift to another server. An ironic consequence of balancing is that when a server goes down, one more token of each license in the pool becomes available to the other servers (so 9 V's, 4 MS's, 4 AD's in the above example). When the down server comes back up, it gets its assigned tokens back, and can borrow more available tokens if a client requests them.

Thus, with balancing enabled in the server configuration, LSHOST on the client-side can contain the server names in any order, and licenses will balance between servers depending on requests and servers available. But any given server will always have 2 less license tokens than the total tokens available in the pool.

You could try to balance between only 2 of the 3 servers (lets say only Server1 and Server2 are assigned tokens). Thus you only give up one of each license token. But this creates a strange license pool where Server3 only gets licenses if 1 or 2 go down. I don?t know what kind of strange behavior would ensue from this, but I'm sure it would be strange.

Now, the client-side ?

VERICUT is an application program which uses the SentinelLM client software to request licenses from a SentinelLM license server. Read that sentence carefully. VERICUT requests licenses from the SentineLM client software. The SentinelLM client software then handles server requests.

The order of the server names in LSHOST determines the order in which the SentinelLM client (not VERICUT) looks for a running server to request a license from. When the SentinelLM client (not VERICUT) finds a running server, it asks for a license. If the request is successful, the licenses are granted and SentinelLM client then tells VERICUT what licenses it has. If the request fails (for any reason), VERICUT only knows the request failed. VERICUT is unaware of whether the license configuration is a single server, redundant server, or redundant server with license balancing.

Thus, in VERICUT's documented redundant server setup (no balancing), when the leader goes down and the tokens move to the follower, the leader cannot get them back. If the client's LSHOST list has the leader's hostname first, VERICUT's license request will fail once the leader is back up. Rearranging the server names in LSHOST, so the server with the tokens is first in the list, allows VERICUT to now get a license.

There are three choices to avoid the (hopefully infrequent) problem if the lead server going down and coming back up:

1. Use redundant servers without balancing (current documented method), and invent an external scheme to manipulate the list of servers in LSHOST prior to starting VERICUT.
2. Enable license balancing, giving up access to 2 of each license for any given user.
3. Dump the whole redundant server scheme as overly complex and of limited value.

I like #3 myself.