IP Services

The Services —> IP Services page allows you to add, delete and configure IP Services. The settings are organised into the following sections

• Virtual Services

• Real Servers

• Basic

• Advanced

• flightPATH

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 Virtual Service. 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 it will turn 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

Example of a completed Virtual Service with 2 Real Servers:

Create a new Virtual Service using the same VIP

• Highlight a Virtual Service with the IP address you wish to copy
• Click Add Virtual Service to enter row edit mode

• The IP Address and Subnet Mask will be copied automatically
• 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 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

Changing the IP Address your Virtual Services

• Highlight a service with the IP address you would like to change

• Double Click into the IP address column
• Change the IP address and click Update

• This will change the IP address of ALL Virtual Services associated with this VIP

Copy Service

Create a new Virtual Service using the Copy Service button:

• The new Copy button will copy an entire service including all of the real servers, basic settings, advanced settings and flightPATH rules associated with it
• Highlight the service you wish to duplicate and click Copy
• The row editor will appear with the blinking cursor on the IP Address column
• You must change either the IP address to be unique or if you wish to keep the IP address the port must be unique to that IP address
• Don’t forget to edit each tab if you wish to change a setting such as the load balancing policy the real server monitor or  remove a flightPATH rule

Filtering and Sorting:

Filter Columns:

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.

Search IP Services:

The Search box allows you to type in a term that will restrict the view to any services containing that term

You can search for whole or part terms such as three octets of a virtual IP address. The service name column allows you to freely write anything you want. So if you have named these by customer for example you will be able to search for every service associated with that customer.

Example before search term entered:

Example screen shot after search term “10.4.8.191”

Primary/Mode

The Primary/Mode 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/Mode 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

VIP Status – This will provide visual feedback for the status of the Virtual IP address and all asociated virtual services

• 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 licenced or licenced Virtual IPs exceeded

Service Status – This will provide visual feedback for the status of each individual virtual service

• Online
• Failover-Standby. This virtual service is hot-standby
• Indicates a “secondary” is holding off for a “primary”
• Service Needs attention. This may be the result of a real server failing a health monitor or has been changed manually to Offline. Traffic will continue to flow but with reduced real server capacity
• Offline. Content servers are unreachable or no content servers enabled
• Finding status
• Not licenced or licenced 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 or an IPv6 address. This is the Virtual IP address for your service.
Example IPv4 “192.168.1.100”. Example IPv6 “2001:0db8:85a3:0000:0000:8a2e:0370:7334”

Subnet Mask / Prefix

Add in your subnet mask in decimal dotted notation. Example “255.255.255.0″. Or for IPv6 add in your Prefix. For more information about IPv6 please see https://en.wikipedia.org/wiki/IPv6_address

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:

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. Click Add Server
2. A new row will appear with the cursor blinking on the IP Address column

1. 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”.
2. 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.
3. Tab to the Notes section to add in any relevant detail for the server. Example: “IIS Web Server 1”

Real Server Details

Group Name:

Real Server Status Lights

• Connected
• Not monitored
• Draining
• Offline
• Standby
• Not connected
• Finding status
• Not licenced or licenced 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:

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:

Standby:

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.

Weight

This column will become editable when an appropriate Load Balancing Policy has been selected in the Basic tab. Appropriate policy are Least Connections, Round Robin, Fastest.
The
default weight for a real server is 100  and you can enter values
from 1-100. 100 means maximum load and 1 means minimum load.

• Example 1 with 3 servers
• Server 1 Weight = 100
• Server 2 Weight = 50
• Server 3 Weight = 50

If we consider the load balancing policy is least connections and there are 200 total client connections

• Server 1 will get 100 current connections
• Server 2 will get 50 current connections
• Server 3 will get 50 current connections

If we consider Round Robin which servers in turn, altering the weights affect how often servers are chosen.

If we consider Fastest which uses the time taken to get a response, altering the weights alters the bias in a similar way to least connections.

Calculated Weight

The calculated weight of each server can be viewed dynamically and is shown
alongside the weight. This column is calculated automatically and
cannot be edited by a user.
This shows the actual weighting that ALB-X is using when considering manual weighting and load balancing policy.

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.

Fastest:

Round Robin:

Least Connections:

Layer 3 Session Affinity/Persistence:

Layer 7 Session Affinity/Persistence:

RDP Cookie Persistence:

Server Monitoring

Your jetNEXUS ALB-X contains six standard Real Server Monitoring methods listed below. Choose one to apply to the Virtual Service. Please make sure that you apply a relevant monitor to the Virtual Service. If the Real Server is an RDP server then a 200 OK monitor is not relevant. If you are unsure which monitor to choose, the default TCP Connect is a good place to start. New in version 4.2.0 is the ability to select multiple monitors. Simply cick each monitor you wish to apply to the service in turn. They will be executed in the order you select them so it best to start with monitors of the lower layers first. Example Select Ping/ICMP Echo, TCP Connection, 200OK. You can see the results of this monitor in the Dashboard Events and it will  look similar to the image below:

If we look at the top line we can see that layer 3 Ping and layer 4 TCP Connect has succeeded and layer 7 200OK has failed so this provides enough information to indicate that routing is fine and there is a service running on the relevant port but the web site is not responding properly for  the page requested.  It’s now time to look at the web server and the Library — Real Server Monitor section to see the details of the failing monitor.

None:

Ping/ICMP Echo:

TCP Connection:

ICMP Unreachable:

RDP:

200 OK:

DICOM:

User Defined:

Caching Strategy

By default the caching strategy is set to Off. If your service type is HTTP then you can apply two types of caching strategy. Please refer to the Configure Cache page to configure detailed cache settings. Note that when caching is applied to a service with service type “Accelerate HTTP”, objects that are compressed will not be cached.

By Host:

By Virtual Service:

Acceleration

Off:

Compression:

Virtual Service SSL Certificate (Encryption between Client and ALB-X)

By default this is set to No SSL. If your service type is “HTTP” or “Layer4 TCP” you can select a certificate from the drop down box to apply to the Virtual Service. Certificates that have been created or imported will appear in this list. You may now highlight multiple certificates to apply to a service. This will automatically enable the SNI extension to allow the presentation of a certificate based on the “Domain Name” requested by the client.

Server Name Indication:

No SSL:

Default:

UserCertificate1:

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:

UserCertificate1:

UserCertificate2:

Any:

SNI:

Advanced

Connectivity

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

Reverse Proxy:

Direct Server Return:

Gateway:

Cipher Options

As of software version 4.1.1 you can now set the ciphers per service. This is only relevant for services with SSL/TLS enabled. The default cipher will be chosen automatically. You can add different ciphers using jetPACKS available at the following URL Once the jetPACK’s have been added you will be able to set the Cipher options per service. The benefit of this is that you can create a number of services with varying levels of security. Be aware that older clients are not compatible with newer ciphers and so you will be reducing the number of clients the more secure the service.

Client SSL Renegotiation:

Tick this box if you wish to allow client initiated SSL renegotiation. To prevent possible Dos attack against the SSL layer it is advisable to un-tick this box to disable client SSL renegotiation.

Client SSL Resumption:

Tick this box if you wish to enable SSL Resumption Server sessions are added to the session cache. When a client proposes a session to be reused,  if the session is found, the server will try to reuse the session. If Resumption not checked, no session caching for client or server takes place.

SNI Default Certificate:

During an SSL connection with Client side SNI enabled  if the requested domain does not match any of the certificates assign to the service then it will present the SNI Default Certificate. The default setting for this is None which would effectively drop the connection should there be no exact match, Choose any of the certificates installed from the drop down box to present should an exact match fail.

Security Log:

This setting is turned on by default  on a per service basis which means that the service is capable of logging authentication information to the W3C logs. Clicking the Cog icon will take you to the System — Logging page where you can check if  W3C logging is set to anything other than None with the security information turned on.

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.

Monitoring In Count

The default value for this setting is 2. This means that the real server has to pass two successful health monitors before it will be brought online. Increasing this figure will increase the probability the server is capable of serving traffic but will take longer to come into service depending on the Interval. Decreasing this value will bring your server into service sooner.

Monitoring Out Count

The default value for this setting is 3. This means that the real server monitor has to fail 3 times before the ALB-X will stop sending traffic to the server and it is marked RED and “Unreachable”. Increase this figure will result is a more reliable service at the expense of the time it takes the ALB-X to stop sending traffic to this server.

Max. Connections

This limits the number of simultaneous real server connections and can be set per service. For example if you set this to 1000 and have two real servers then the jetNEXUS ALB-X will limit EACH real server to 1000 concurrent connections. You may also choose to present a “Server too busy” page, once this limit is reached on all servers, helping users in this case. Leave this blank for unlimited connections. This will depend on your system resources.

flightPATH

• flightPATH rules are designed to manipulate HTTP(s) traffic. As such, the option for flightPATH is only visible if for Service Type “HTTP”
• The list of available rules is on the left and the current rules applied to the virtual service are on the right
• To add a new rule drag and drop the rule into position or highlight a rule and click the right arrow
• The order for execution is important and will start with the top rule being executed fist. To change the order highlight a rule and use the arrows to move up or down the list.
• To remove a rule simply drag and drop it back to the rule inventory or highlight the rule and click the left arrow
• You can add, remove and edit flightPATH rules in the Configure flightPATH section.