Intelligent Service Verificator

What is an Intelligent Service Verificator (ISV)?

An ISV is a mechanism that you can use alongside the IDNS module to check the availability of your services before answering to DNS requests. For example, if you have two web servers providing the same content, you could load balance the charge between your multiple links and between you multiple servers at the same time, on top of the load balancing the ISVs will permit failover between your multiple servers in case one of them stops answering to the ISV tests.

Which tests can an ISV perform?

An ISV can perform two kind of tests, a L7 exchange or a L4 connection. The difference between those tests is that a L7 exchange will replicate a real user request for a web page (for example), get the result from a web server and locate a keyword in the returned page to confirm that everything is in order. A L4 connection on the other hand will attempt to connect to the defined service on the specified TCP port and if the connection is successful the service is considered to be available.

You will need to define one ISV per server you wish to check. For one given application you might want to check several servers that work together. For example, an online store application might need a web server, an email server and a database server. An intranet application might need a radius server, a ldap server, a web server and a database server. You can regroup those ISV tests together using ISV groups and this way you can stop the Link LB from answering with the web server from a group if this group's database server is crashed.

Now that you know about the grouping feature you might be curious about how we tests those different servers. The servers in a group might be in a multi-tiered model, meaning that the database server is not necessarily available from the internet because the web server and the database server are in different security zones. The Link LB has two methods to send those polling packets: inline or from the management interface. ISV Inline means that you can test both the end-server and the network infrastructure leading to it because polling packets are sent "inline" (from the inside port) with the normal flow. For any servers not available directly from the internet you can still send your polling packets from the management interface.

What is an ISV alias?

ISVs give you the possibility of load balancing requests on multiple servers. On top of that, the Link Load balancer can also load balance the requests onto multiple links. Naturally, all those servers have their own primary IP address, but when the requests come in on alternate links, those sessions have an associated destination IP that belongs to those alternate links. This is easily understandable when looking at the IDNS RR entries. ISV alias entries reflect those alternate IPs belonging to alternate links. They don't represent real servers, only a different IP that belongs to the same server once NATed. Therefore, ISV alias will not poll the servers, they will replicate the results obtained by the ISV they reference.

What is an ISV API test?

If the provided ISV L7 exchange and L4 connection tests are not sufficient to test your service, your service or a monitoring server can do the required tests and send periodically the result via the API. This heartbeat to the Elfiq inform the ISV API that the service is alive or not. If this heartbeat stops, this service will be considered as unavilable.

Are ISVs exchanged through a Geolink?

Yes, ISVs can be exchanged trough a Geolink with the export command. For configuration information please refer to the configuration guide.

How should I configure them?

Multiple commands are needed to configure this feature.

ISV command syntax

[id]: A numeral identifier that can be used in other parts of the configuration to refer to this ISV. ISV numbers should always be unique. 

[dest ip]: The service or server IP address, this can be the primary IP or an alternate IP.

[url|alias]: In case of a L7 test on a web or ftp server enter http://www.example.com:80/full/path/to/test.html or ftp://ftp.example.com:21/testfile.txt url here. In case of a L4 test on a TCP network port enter tcp://194.204.1.3:110 here. If you are declaring an alias ISV then simply put the "alias" keyword here.

[verification string|isv:id]: In case of a L7 test, choose one keyword that the Link LB can find in the downloaded web page or text document. In case of a ISV alias, put the ISV ID of the ISV checking the primary IP of the service.

[interval (ms)]: Interval at which the required test is done.

[timeout (ms)]: Lenght of time after which the testing is considered automatically failed.

[failure threshold]: Number of failures before declaring the ISV down.

[weight]: Metric value to choose between multiple ISVs when deciding between servers. 

Examples:

## Mail server 1
  isv 1 194.204.1.3 tcp://194.204.1.3:25/ none 5000 3000 3 1
  isv 2 24.201.1.3 alias isv:1 1
## Mail server 2
  isv 3 194.204.1.4 tcp://194.204.1.4:25/ none 5000 3000 3 5
  isv 4 24.201.1.4 alias isv:3 5
## Web server 1
  isv 5 194.204.1.5 http://www.elfiq.com:80/ Elfiq 3000 3000 3 1
  isv 6 24.201.1.5 alias isv:5 1
## Web server 2
  isv 7 194.204.1.6 http://www.elfiq.com:80/ Elfiq 3000 3000 3 5
  isv 8 24.201.1.6 alias isv:6 5

ISV groups

You can regroup ISVs checking different servers or services together. A typical example is a web server frontend and a database backend, you can test both and regroup them in an ISV group. If any of both is unavailable, then the whole group is down.  

ISV groups should be used to bind together ISVs on the primary IP address and ISV alias. They should also bind multiple servers required for a given service. 

ISV group command syntax

[id]: A numeral identifier that can be used in other parts of the configuration to refer to this ISV. ISV group numbers for dispersed services should match in a geographic deployment in order for group contents to merge. This group ID should be used in an IDNS RR entry to bind the results of the testing with the service name and IDNS RR configuration.

isv:[id,...]: ISV IDs to be part of the group. The state of the ISVs dictate the state of the ISV GROUP. If any single ISV in the group is down, then the whole ISV GROUP is declared as down.

[description]: Text identifier for identification purposes.

[group metric selector]: The group metric selector is used to balance the traffic across the different servers offering a given service. The metric is bound to each available RRA, you should always use the same GMS (Group metric selector) across all groups for a given service. 

NOTE: Group metric selectors RRA metrics are only effective for IDNS RR resolution when you use the "etfa-isv" and "wfa-isv". 

Examples:

  isv group 1 isv:1,2 Mail_server_1 
  isv group 2 isv:3,4 Mail_server_2
  isv group 3 isv:5,6 Web_server_1 gms-rtt
  isv group 4 isv:7,8 Web_server_2 gms-rtt