Backup vServer
You can use a backup vServer for when your primary vServer goes offline and you need to provide your users with an alternative access point.
For example, you have a standard HTTP web vServer that users access. The vServer goes down. Users don’t notice because they access the same URL and are directed on to the backup vSever behind the scenes. That backup vServer could be located in a passive datacentre.
To configure, edit an existing vServer. Navigate to Traffic Management -> Load Balancing -> Virtual Servers -> Edit.
Click the edit icon next to Protection.
Specify a Backup Virtual Server. Click OK.
Click Done.
The list of vServers are shown below with the primary and secondary servers online.
When users access the primary vServer VIP they are presented with the correct content as normal. For me to simply show you this working, the primary vServer links back to a StoreFront server named StoreFront1.
The primary vServer MyWebApp has now gone offline. At this stage connecting users should be directed to MyWebAppBackup which is another StoreFront server named StoreFront2.
And you can see the users use the same primary vServer VIP but behind the scenes are directed to the backup vServer. This vServer should obviously serve the same content as the primary.
Looking at the backup vServer statistics, the vServer hits counter has increased as expected.
Spillover
Using the spillover feature, you can spillover connections to a secondary vServer when for example the connection limit or bandwidth limit of the primary vServer has been maxed out.
Navigate to Traffic Management -> Load Balancing -> Virtual Servers and edit your primary vServer. Under the Protection section of the vServer properties specify a Spillover Method.
For this example, I have used the CONNECTION Spillover Method with a Spillover Threshold of one. This means the second concurrent connection to this primary vServer will be spilled over to MyWebAppBackup which is defined under Backup Virtual Server. Click OK. Note you can also spillover persistence if session persistence is important to you.
The HEALTH spillover method allows you to spillover if the threshold drops below 70% for example. Using this method, you specify a percentage threshold.
Click Done.
The first user connection to the primary vServer VIP is directed to the primary vServer StoreFront1.
The second connection is correctly spilled over to the backup vServer StoreFront2 (MyWebAppBackup). The URL does not change so to the user nothing has happened.
URL Redirect
Using URL Redirect, when the primary vServer is down you can redirect users to another URL. The URL Redirect option is frequently used to direct HTTP connection attempts to StoreFront or NetScaler Gateway to HTTPS. I will show you how this can be configured. Since using this method directs HTTP requests to HTTPS the URL is changing and as such users are being directed to a different URL using URL Redirect.
Navigate to Traffic Management -> Load Balancing -> Virtual Servers -> Add.
Specify a name.
Protocol = HTTP.
IP address = Same VIP used for your HTTPS StoreFront vServer.
Click OK.
Click Continue. We don’t want to bind services against this vServer. As a result the vServer will always be marked as down meaning any user connecting to it will always get redirected.
Expand Protection.
Enter the HTTPS FQDN of Receiver for Web. Click OK.
Click Done.
Notice we have two vServers. The first being our Load Balanced StoreFront vServer using HTTPS. The second being the always offline HTTP vServer configured with the same VIP as the HTTPS vServer.
Now when users browse to http://receiverforweburl they hit the HTTP-StoreFront-Redirect vServer.
The vServer is down, so it redirects userrs to the correct HTTPS FQDN of Receiver for Web. This is useful, because it corrects user error. 