Virtual Services

A Virtual Service is a combination of a Virtual IP (VIP) and a TCP/UDP port that the jetNEXUS ALB-X will listen on

• Traffic arriving at the Virtual Service is directed to one of the Real Servers that are associated with that service
• The Virtual Service IP address cannot be the same as the management address of the jetNEXUS ALB-X. i.e. eth0, eth1 etc…
• The jetNEXUS ALB-X determines how the traffic is distributed to the Real Servers based on a load balancing policy set within the Basic tab

Create a new Virtual Service using a new VIP

• Click Add IP. You will then enter row edit mode. The 4 boxes highlighted in red must be completed before you can update

  

• The IP Address box should contain a blinking cursor so just start typing your Virtual IP address and then TAB to the next box
• Enter the Subnet Mask and TAB to the next box
• Enter the Port Number for your service and TAB to the next box
• Enter an optional Service Name and TAB to the next box
• Use the down arrows on your keyboard or select a Service Type using your mouse
• You can now press the Update button to save this section and jump automatically to the Real Server section below

  

• Leave the server in the Online Activity – this means it will be load balanced if it passes the default health monitor of TCP Connect
• Enter an IP address for the real server and TAB to the next box
• Enter a Port Number for the real server and TAB to the next box
• Enter an optional name for the Real Server
• Click Update or press Enter to save your changes
• The Status light will first turn Grey then Green Server Heath Check succeeds. It will turn Red if the Real Server Monitor fails
• A server that has a Red Status light will not be load balanced

Example of a completed Virtual Service with 2 Real Servers

Create a new Virtual Service using the same VIP

• Click Add Port to enter row edit mode

  

• The IP Address and Subnet Mask will be duplicated automatically, this is the only way to add another service to an existing Virtual IP address
• Enter the Port Number for your service and TAB to the next box
• Use the down arrows on your keyboard or select a Service Type using your mouse
• You can now press the Update button to save this section and jump automatically to the Real Server section below

  

• Leave the server in the Online Activity – this means it will be load balanced if it passes the default health monitor of TCP Connect which can be changed later
• Enter an IP address of the real server and TAB to the next box
• Enter a Port Number for the real server and TAB to the next box
• Enter an optional name for the Real Server
• Click Update to save your changes
• The Status light will first turn grey then green if the Server Health Check succeeds. It will turn Red if the Real Server Monitor fails
• A server that has a Red Status light will not be load balanced

Filtering and Sorting

To the far right of each column is small down arrow (see the red box below). Clicking on this will reveal an extra submenu that allows you to “Sort Ascending”, “Sort Descending” and “Columns”. Add and remove the tick to show/hide the columns listed below.

Primary

The Primary column contains different information depending on the high availability role that has been selected from the Cluster page

High Availability Role

1.Cluster

This is the default role for a new ALB-X and as such the Primary column will indicate whether the ALB-X is either Active or Passive

2.Manual

In this role the ALB-X can be Active Active for different Virtual IP addresses and as such the Primary column will contain a box next to each unique Virtual IP that can be ticked for Active or left un-ticked for Passive

3.Stand-Alone

The ALB-X is acting alone and is not in High Availability mode and as such the Primary column will say Stand-alone

Status

• Online
• Failover-Standby. This virtual service is hot-standby
• Indicates a “secondary” is holding off for a “primary”
• Offline. Content servers are unreachable or no content servers enabled
• Finding status
• Not licensed or licensed Virtual IPs exceeded

Enabled

By default the box is ticked to enable the Virtual Service. Double click on the row to edit and remove the tick to disable the Virtual Service

IP Address

Add in your IPv4 address in decimal dotted notation. This is the Virtual IP address for your service. Example “192.168.1.100”

Subnet Mask

Add in your subnet mask in decimal dotted notation. Example “255.255.255.0”

Port

Add in the port number associated with your service. This may be TCP or UDP port number. Example “80” for Web Traffic

Service Name

Add in a friendly name to identify your service. Example “Production Web Servers”.

Service Type

Please note that with all “Layer 4” service types, edgeNEXUS will not interact or modify the data stream so flightPATH will not work with these service types. It will simply load balance the traffic according to the load balancing policy

Layer 4 TCP:
Any TCP port (Layer 4). edgeNEXUS will not alter any information in the data stream and will simply load balance the traffic according to the load balancing policy

Layer 4 UDP:
Any UDP port (Layer 4) This will change the connectivity to Basic and is only available in this mode. edgeNEXUS will not alter any information in the data stream and will simply load balance the traffic according to the load balancing policy

Layer TCP/UDP:
Any TCP or UDP port (Layer 4) This will change the connectivity to Basic and is only available in this mode. This is ideal if your service has a primary protocol such as UDP but will fall back to TCP

HTTP:
HTTP(s) Protocol (Layer 7). jetNEXUS ALB-X has the ability to interact, manipulate and modify the data stream using flightPATH

FTP:
File Transfer Protocol Protocol (Layer 7). Using separate control and data connections between client and server

SMTP:
Simple Mail Transfer Protocol (Layer 4)

POP3:
Post Office Protocol (Layer 4)

IMAP:
Internet Message Access Protocol (Layer 4)

RDP:
Remote Desktop Protocol (Layer 4)

RPC:
Remote Procedure Call (Layer 4)

RPC/ADS:
Exchange 2010 Static RPC for Address Book Service (Layer 4)

RPC/CA/PF:
Exchange 2010 Static RPC for Client Access & Public Folders (Layer 4)

DICOM:
Digital Imaging and Communications in Medicine (Layer 4)

Real Servers

The Server tab contains the Real Server details associated with the highlighted Virtual Service. You will be prompted to add at least one Real Server when setting up a Virtual Service.

Add a new Real Server to a Virtual Service

1. 1.Click Add Server
2. 2.A new row will appear with the cursor blinking on the IP Address column
3. 3.
4. 4.Enter the IPv4 address of your server in dotted decimal notation. The Real Server can be on the same network as your Virtual Service, any directly attached local network or any network that your edgeNEXUS can route to. Example “10.1.1.1”.
5. 5.Tab to the Port column and enter the TCP/UDP port number for your server. This can be the same as the Virtual Service port number or another port number for Reverse Proxy Connectivity. The jetNEXUS ALB-X will automatically translate to this number.
6. 6.Tab to the Notes section to add in any relevant detail for the server. Example: “IIS Web Server 1”

Real Server Details

Group Name:

• This is the name you can associate with a particular group of servers. For Example “Exchange 2010 CAS Array”
• This name will be automatically saved once edited
• In this version of software there is no additional functionality, however in future releases we will include the ability to add or link server groups once they have been configured

Content Server Status Lights

• Connected
• Not monitored
• Draining
• Offline
• Standby
• Not connected
• Finding status
• Not licensed or licensed real servers exceeded

Activity

If you wish to change the Activity of a Real Sever, click on a row to highlight then click again to enter row edit mode. You can now select an Activity from the drop down menu

Online:

All Real Servers assigned as Online will receive traffic according to the load balancing policy set within the Basic tab

Drain:

All Real Servers assigned as Drain will continue to serve existing connections but will not accept any new connections. The Status light will flash green / blue whilst draining. Once the existing connections have closed naturally the Real Servers will be taken offline and the Status light will be solid blue . You can also view these connections on the Navigation–Monitor–Status page

Offline:

All Real Servers assigned as Offline will immediately be taken offline and will not receive any traffic

Standby:

All Real Servers assigned as Standby will remain offline until ALL of the Online group fail their Server Health Montior, at which point members of the Standby group will be sent traffic according to the load balancing policy. If one of the Online group passes the Server Health Monitor this Online server will receive all of the traffic and the Standby group will be no longer receive traffic.

IP Address

This is the IP address for your Real Server. Example “192.168.1.200”.

Port

This is a TCP or UDP port number that the Real Server is listening on for a particular service. Example “80” for Web Traffic.

Notes

Add in some useful notes about the particular server. Example “IIS Server1 – London DC”.

Basic

Load Balancing Policy

Select from the drop down list how you would like the traffic to be load balanced.

Round Robin:

This is the simplest method. Each Real Server receives a new request in sequence. This method is useful to load balance evenly however it does not take in to account how busy each server is and can add to the burden of busy servers.

Least Connections:

The load balancer will keep track of the number of current connections to each Real Server. The Real Server with the least amount of connections will be sent the next new request.

Layer 3 Session Affinity/Persistence:

IP Bound:
In this situation the client’s IP address is used to select which back end server will receive the request. This provides persistence. It can be used with HTTP or layer 4 protocols. This method is useful for internal networks where the network topology is known and you can be confident that there are no “super proxies” upstream. With layer 4 and proxies, all the requests can look as if they are coming from one client, and as such the load would not be even. With HTTP, X-Forwarded-For information is used, if present, to cope with proxies.

IP List Based:
The initial connection to the Real Server is made using “Least connections” then session affinity is achieved based on Clients IP. A list is maintained for 2 hours by default but this can be changed using a jetPACk

Layer 7 Session Affinity/Persistence:

ALB Session Cookie:
This is the one of the most popular persistence method for HTTP. In this situation, IP list based load balancing is used for each first request. A cookie is inserted into the headers of the first http response. Thereafter, jetNEXUS ALB-X uses the client cookie to route traffic to the same back end server. Again this is used for persistence, when the client must go to the same back end server each time. The cookie will expire after the session is closed.

ALB Persistent Cookie:
In this situation, IP list based load balancing is used for each first request. A cookie is inserted into the headers of the first http response. Thereafter, jetNEXUS ALB-X uses the client cookie to route traffic to the same back end server. Again this is used for persistence, when the client must go to the same back end server each time. The cookie will expire after 2 hours and the connection will be load balanced according to IP List Based algorithm This is a configurable time that can be changed using a jetPACK.

By Host:

Caching is applied on a per host name basis. A separate Cache will exist for each domain/host name. Ideal for web servers that can serve multiple websites depending on the domain.

By Virtual Service:

Caching is applied per virtual service. Only one Cache will exist for all domain/host names that pass through the virtual service. This is a specialist setting for use with multiple clones of a single site.

Acceleration

Off:

Turn compression off for the Virtual Service

Compression:

Turn compression on for the Virtual Service. Traffic from the ALB-X to the client will be dynamically compressed upon request. This only applies to objects that contain the content-encoding: gzip header. Example html css or javascript. You can also exclude certain content types from the Global Exclusions section.

Real Server SSL Certificate (Encryption between ALB-X and Real Server)

By default this is set to No SSL. If your server requires an encrypted connection then this must be set to anything other than No SSL. Certificates that have been created or imported will appear in this list.

No SSL:

Traffic from the ALB-X to the content server will not be encrypted.
If a certificate has been selected – on the browser side, “No SSL” can be selected client-side to provide what is known as “SSL Offload”.

UserCertificate1:

Traffic from the ALB-X to the content server will be encrypted provided the named certificate is presented by the real server.
If a certificate has been selected – on the Virtual Service side, “UserCertificate1” can be selected to provide what is known as “SSL Bridging” or “SSL Re-Encryption”.

Any:

The ALB-X acts as a client and will accept any certificate the content server presents. Traffic from the ALB-X to the content server will be encrypted if this is selected.
If a certificate has been selected – on the Virtual Service side, “Any” can be selected to provide what is known as “SSL Bridging” or “SSL Re-Encryption”.

Advanced

Connectivity

Your Virtual Service can be configured with four different types of connectivity. Please select one to apply to the channel.

Reverse Proxy:

This is the default setting for jetNEXUS ALB-X and works at layer7 with compression and caching and also at layer4 without caching and compression. In this mode your jetNEXUS ALB-X acts as a reverse proxy and becomes the source address seen on the content servers.

Direct Server Return:

Direct Server Return or DSR as it’s widely known (DR – Direct Routing in some circles) allows the server behind the load balancer to respond directly to the client bypassing the edgeNEXUS on the response. DSR is suitable for using with Layer 4 load balancing only. Therefore Caching and Compression are not available when enabled.
Layer 7 load balancing with this method will not work therefore there is no persistence support other than IP List Based. SSL/TLS load balancing with this method is not ideal as there is only source IP persistence support. This method requires content server changes. Please refer to the real server changes section.

Transparency:

Transparency is suitable for Service Type Layer 4 load balancing only. Caching and Compression are not available when transparency is enabled. Transparency is used when you need the source address of the client making the request and X-Forwarded-For techniques are not sufficient. Layer 7 load balancing with this method will not work therefore there is no persistence support other than IP List Based. This method requires content server changes. Please refer to the real server changes section.

Gateway:

Gateway mode allows you to route all traffic through the jetNEXUS, this allows traffic from the content servers to be routed via the edgeNEXUS to other networks via the interfaces on the edgeNEXUS unit. Using the device as a gateway device for content servers should be used when running in multi interface mode. Layer 7 load balancing with this method will not work therefore there is no persistence support other than IP List Based. This method requires that the content server sets its default gateway to the local interface address (eth0, eth1, etc….) of the jetNEXUS ALB-X. Please refer to the real server changes section.

Basic:

Basic mode is a very low latency low CPU mode that will provide simple load balancing. The load balancing policy is restricted to Round Robin or if you require session persistence IP List Based. This mode is only available with the 64bit platform which is available from here.

Enable Connection Pooling

When this is ticked the ALB-X maintains connections to the content server so they can be reused when future requests to the real servers are requested. This is a great way to reduce the number connections open on the real servers. This setting is only valid for Service Type “HTTP” and should be used for stateless web connections only.

Connection Pool Size

Set the number of connections to maintain

Connection Timeout

The default setting for this is 600 seconds or 10 minutes. This setting will adjust the time for the connection to timeout out upon no activity. Reduce this for short lived stateless web traffic which is typically 90s or less. Increase this figure for stateful connections such as RDP to something like 7200 seconds (2 hours) or more depending on your infrastructure. This means that if a user has a period of inactivity of 2 hours or less the connections will still remain open.

Monitoring Settings

These settings are tied to the Real Server Monitors in the Basic tab. There are global entries in the configuration to count the number of successful or failed monitors before a server is allowed online or marked as failed.

Interval

The interval is the time in seconds between monitors. The default interval is 1s. Whilst 1s is acceptable for most applications it may be beneficial to increase this for other applications or during to testing.

Monitoring Timeout

The timeout value is the amount of time the ALB-X will wait for a server to respond to a connection request. The default value is 2s. This value may need to be increased for busy servers.