GSLB Virtual Servers Test

A GSLB virtual server has one or more GSLB services bound to it, and load balances traffic among those services. It evaluates the configured GSLB methods (algorithms) to select the appropriate service to which to send a client request. Because the GSLB services can represent either local or remote servers, selecting the optimal GSLB service for a request has the effect of selecting the data center that should serve the client request.

The domain for which global server load balancing is configured must be bound to the GSLB virtual server, because one or more services bound to the virtual server will serve requests made for that domain. Unlike other virtual servers configured on a NetScaler appliance, a GSLB virtual server does not have its own virtual IP address (VIP).

To promptly detect irregularities in load-balancing and accurately point to the bottleneck points, you need to track requests to the sites, services, and virtual servers (that are bound to the services) and observe how every entity handles these requests. While the tests discussed previously monitor traffic to the sites and services, you can use the GSLB Virtual Servers test to figure out how the virtual servers load-balance the requests, responses, and data they receive. In the process, you can quickly identify overloaded virtual servers, and thus detect load-balancing irregularities.

Target of the test : A NetScaler VPX/MPX

Agent deploying the test : A remote agent

Outputs of the test : One set of results for each GSLB virtual server.

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed.

Host

The IP address of the host for which the test is being configured.

NetScaler Username and NetScaler Password

To monitor a NetScaler device, the eG agent should be configured with the credentials of a user with read-only privileges to the target NetScaler device. Specify the credentials of such a user in the NetScaler Username and NetScaler Password text boxes.

SSL

The eG agent collects performance metrics by invoking NITRO (NetScaler Interface Through Restful interfaces and Objects) APIs on the target NetScaler device. Typically, the NITRO APIs can be invoked through the HTTP or the HTTPS mode. By default, the eG agent invokes the NITRO APIs using the HTTPS mode. This is why, the SSL flag is set to Yes by default. If the target NetScaler device is not SSL-enabled, then the NITRO APIs can be accessed through the HTTP mode only. In this case, set the SSL flag to No.

Show Up Server Only

The default setting of this flag is No; this indicates that this test, by default, monitors all the GSLB virtual servers configured on the NetScaler appliance. If you want the test to monitor only those GSLB virtual servers that are up and running currently, then set this value to Yes.

Exclude Server

Provide a comma-separated list of GSLB virtual server names or name patterns that need to be excluded from monitoring. By default, this is set to none, indicating that all GSLB virtual servers are by default monitored

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Server state

Indicates the current state of this virtual server.

 

If the virtual server is up, then the value of this measure is Up. If the virtual server is down, then the value of this measure is Down.

The numeric values that correspond to these measure values have been listed in the table below:

Numeric Value

Measure Value

0

Up

1

Down

2

Out of service

3

Transition out of service

4

Down when going out of service

-1

Unknown

Note:

By default, this measure reports the above-mentioned Measure Values while indicating whether a virtual server is up/down. However, in the graph of this measure, the Measure Values will be represented using their corresponding numeric equivalents only.

You can use the detailed diagnosis of this measure to determine the protocol type of each virtual server being monitored.

Virtual server health

Indicates the current health of this virtual server.

Percent

While a high percentage is indicative of good health, a low percentage indicates otherwise.

Current client connections

Indicates the number of current client connections to this virtual server.

Number

These are good measures of the connection load on a virtual server. By comparing the value of each of these measures across servers, you can instantly identify overloaded servers and promptly detect irregularities in load-balancing.

Current server connections

Indicates the number of connections to the actual servers behind this virtual server.

Number

Client connections in established state

Indicates the number of client connections to this virtual server that are currently in an ESTABLISHED state.

Number

Server connections in established state

Indicates the number of connections to the actual server behind this virtual server that are currently in an ESTABLISHED state.

Number

 

Request data received:

Indicates the amount of request data received by this virtual server during the last measurement period.

MB

These are good measures of the request and response load on a virtual server. By comparing the value of each of these measures across virtual servers, you can instantly identify overloaded servers and promptly detect irregularities in load-balancing.

In the event that such irregularities come to light, you may want to consider fine-tuning the GSLB policies and/or GSLB methods and/or metric exchange policies supported by the system to ensure that the appliance takes intelligent load-balancing decisions.

Response data received

Indicates the amount of response data received by this virtual server during the last measurement period.

MB

Requests received

Indicates the number of requests received by this virtual server during the last measurement period.

Number

Responses received

Indicates the number of responses received by this virtual server during the last measurement period.

Number

Virtual server hits

Indicates the number of times this virtual server has serviced a request during the last measurement period.

Number

If the value of this measure is equal to the number of requests received by this virtual server, then it indicates the virtual server was very busy during the last measurement period. On the contrary, if the value of this measure is less than the number of requests received by this virtual server, it could indicate that the virtual server was well-loaded.