IP Services
TheSetup —> IP Services page allows you to add, delete and configure IP Services. The settings are organised into the following sections
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 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
- 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
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
- 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
- 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
- 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 licensed or licensed Virtual IPs exceededService 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 serverfailing 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 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
not alter any information in the data stream and will simply
load balance the traffic according to the load balancing policy
simply load balance the traffic according to the load balancing policy
(Layer 7). jetNEXUS ALB-X has the ability to interact, manipulate and modify the data stream using flightPATH
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.
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
- Click Add Server
- A new row will appear with the cursor blinking on the IP Address column
- 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”. - 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. - 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
Real Server Status Lights
Connected 
Not monitored 
Draining Offline Standby Not connected Finding status Not licensed or licensed real servers exceededActivity
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:
whilst draining. Once the existingconnections 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 pageOffline:
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.
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:
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:
Layer 3 Session Affinity/Persistence:
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.
Layer 7 Session Affinity/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.
Server Pages (ASP) is a Microsoft server-side technology. With this
option selected the ALB-X will maintain session persistence to the same
server if an ASP cookie is detected and is found in its list of known
cookies. If a new ASP cookie is detected then it will be load balanced
using the least connections algorithm.
is a Microsoft server-side technology. With this option selected the
ALB-X will maintain session persistence to the same server if an
ASP.NET cookie is detected and is found in its list of known cookies.
If a new ASP.NET cookie is detected then it will be load balanced using
the least connections algorithm.
Server Pages (JSP) is an Oracle server-side technology. With this
option selected the ALB-X will maintain session persistence to the same
server if a JSP cookie is detected and is found in its list of known
cookies. If a new JSP cookie is detected then it will be load balanced
using the least connections algorithm.
web services (JAX-WS) is an Oracle server-side technology. With this
option selected the ALB-X will maintain session persistence to the same
server if a JAX-WS cookie is detected and is found in its list of known
cookies. If a new JAX-WS cookie is detected then it will be load
balanced using the least connections algorithm.
Home Page (PHP) is an open source server-side technology. With this
option selected the ALB-X will maintain session persistence to the same
server if a PHP cookie is detected.
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. None:
this mode, the content server is not monitored at all and is assumed to
be always up and running correctly. This is useful for situations where
monitoring upsets a server and for services that should not join in the
fail-over action of ALB-X. It can be viewed as a way of hosting
unreliable or legacy systems that are not core to H/A operation. This
monitoring method can be used with any service type.
Ping/ICMP Echo:
this mode, ALB-X sends an ICMP echo request to the IP of the content
server. If a valid echo response is received, the content server is
deemed to be up and running and traffic will be sent to it. It will
also then keep the service available on an H/A pair. This monitoring
method can be used with any service type
TCP Connection:
this mode, a TCP connection is made to the content server and
immediately broken without sending any data. If the connection
succeeds, the content server is deemed to be up and running. This
monitoring method can be used with any TCP service type. UDP services
are the only ones currently not appropriate for TCP Connection
monitoring
RDP:
a layer 7 RDP connection is requested. If the connection is confirmed
the content server is deemed to be up and running. This monitoring
method can be used with Microsoft terminal servers
200 OK:
this mode, a TCP connection is made to the content server as above, but
after connection is made, a brief HTTP request is made to the content
server. A HTTP response is waited for and it is checked for the “200
OK” response code. If the “200 OK” response code is received, the
content server is deemed to be up and running. If, for any reason, the
“200 OK” response code is not received, including timeouts, failure to
connect, etc, then the content server is regarded as down. This
monitoring method can only really be used with HTTP and Accelerate HTTP
service types, although if a Layer 4 Service Type is in use for an HTTP
server, it could still be used if SSL is not in use on the content
server, or is handled appropriately by the “Content SSL” facility
DICOM:
this mode, a TCP connection is made to the content server as above, but
after a connection is made, an Echoscu “Associate Request” is
made to the content server. A conversation that includes an “Associate
Accept” from the content server, a transfer of a small amount of data
followed by a “Release Request” then “Release Response” successfully
concludes the monitor. If for any reason the monitor does not complete
successfully then the content
server is regarded as down
User Defined:
Caching Strategy
By
default the caching strategy is set to Off. If your channel
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 channel with service
type “Accelerate HTTP”, objects that are compressed will not be
cached.
By Host:
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:
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:
Compression:
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.
Note:
If the object is cachable we will store a compressed version and
serve this statically (from memory) until the content expires and
it is revalidated.
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
No SSL:
Default:
locally created certificate called “Default” is applied to the browser
side of the channel. This can be used to test SSL when one hasn’t been
created or imported
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:
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:
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:
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:
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:
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.
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:
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:
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:
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.
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 increases 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.
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.
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.
Back to Top