Content switching is the ability to direct requests sent to the same URL to different servers with different content. Consider the scenario where, when you type the URL http://url1.com, you are redirected to one backend service and, if you type another URL http://url1.com/videos, you are redirected to another backend service even though it shares the same URL. There are also other ways besides looking at the URL to do content switching. Some examples are:

This feature is commonly used when, for instance, delivering web services for mobile devices. If we think about accessing a website with a mobile device, we often use the same URL as we normally do but are being redirected to a mobile-friendly website on another backend resource. This is of course more user-friendly but gives us a lot of flexibility as well to split mobile traffic with regular desktop-based traffic. This also allows us to do TCP optimization based upon device connections, which will be covered in the next chapter.

In essence, content switching consists of a vServer, policies, and actions. The policies define expressions that are then evaluated to see if they trigger an action. The actions always point to a target load-balanced vServer. So let's look at this from a design perspective.

We have a website called url1.com that is accessed by two types of device: mobiles and regular computers. We therefore created a content-switching vServer that has two policies. The first policy checks if the user-agent is a mobile device; if so, it redirects the request to a vServer that is load-balancing the mobile device front-end for that service. The other policy is there to handle all other traffic, which is redirected to another load-balanced vServer that has the regular website traffic.

So let's set up a content switching vServer for the first scenario. First we need to enable the content switching feature; this is done by going into the management console, right-clicking on the feature, and choosing Enable feature.

We can also use CLI by typing the command:

enable feature contentswitching

Next we need our two load-balanced vServers in place before setting up content switching. In this scenario we just set up some vServers by using CLI.

Add server hostname 192.168.60.20
Add server hostname 192.168.60.21
Add server hostname 192.168.60.22
Add server hostname 192.168.60.23

Then we create two different services, one for mobile and another for regular HTTP traffic:

Add service mobile-http-1 192.168.60.20 http 80
Add service mobile-http-2 192.168.60.21 http 80
Add service http-1 192.168.60.22 http 80
Add service http-2 192.168.60.23 http 80

Next we need to load-balance the vServer:

add lb vserver HTTP-mobile-lb http 192.168.60.24 80
add lb vserver HTTP-lb http 192.168.60.25 80

It is important to note that we do not need to add IP addresses to the load balanced vServers if we intend to use them with content switching, since the communication between the content switching vServer and the lb vServer is only internal. In order to add a lb vServer without an IP address you need to do it using the CLI, by using the earlier example but without the IP address.

Lastly we need to bind the services to the load-balanced vServers:

bind lb vserver HTTP-mobile-lb mobile-http1
bind lb vserver HTTP-mobile-lb mobile-http2
bind lb vserver HTTP-lb http-1
bind lb vserver HTTP-lb http-2

Now that we have the load-balanced vServers in place we can create a content switching vServer:

Add cs vserver HTTP-CS HTTP 192.168.60.26

It is important to note that by default the content switching server does not check whether the backend load-balanced resources are up or not. This is because if we enable the status check this means that, for instance, if one of four load-balanced vServers is down, the content switching vServer goes down. We can enable a state check by using the command:

Set cs parameter –stateupdate ENABLED

Now we need to define the policies. Now policies, as I mentioned earlier, consist of different expressions to do an evaluation of the request. This can also be done using CLI but in this case I am going do to it using the Web GUI.

Go into Traffic Management | Content Switching and choose Create new policy.

There are many ways to do it this. A simple way is to create an expression that checks the user-agent string and then redirects the users to the connected backend service.

Therefore we can use the expression:

HTTP.REQ.HEADER("User-Agent").CONTAINS("Android")

Note also that instead of using expressions we can switch to using URLs; this allows us to redirect requests based upon what kind of URL the endpoint is trying to access. For instance, we can define here that a request to http://url/resources should be redirected to another load-balanced vServer. When we choose URL-based content switching we are also given the option to enter a domain name; this allows for NetScaler to correctly redirect content for multiple domain names.

So, all clients connecting using Android will be redirected to the server that is specified under actions.

If we want to combine multiple expressions—for instance, a policy that binds all mobile user-agents in one expression—we can use logical operators to combine multiple expressions. We can for instance use the logical operator && that is the equivalent of AND or we can use the logical operator || that is the equivalent of OR—for instance, a compound expression containing all mobile user-agents where we want a mobile user who connects with one OR the other device redirected to a load-balanced vServer.

Now, after we have created a policy and action we have to bind it to the vServer. Go into the Content Switching pane. Choose Create a new vServer. Fill in the required information: Name, Protocol, Port, and IP Address. Click OK.

Under CS Policy Binding choose Select policy and add our newly created policy.

It is important to note that the priority here defines what policy runs first. If we have multiple policies with use the same expression for evaluation, the one with the lower priority wins. If you want to see how many are being redirected by the different content switching policies, you can use the following command:

Stat cs vserver

We can also use the command to see which policies are being used by the different connections:

nsconmsg -d current | egrep -i CSPOL

This allows us to see in real time which policies are triggered.

We can also define a default load balanced vServer that all other requests not caught by a policy are sent to. This is easily done by going into the content switching vServer …. CS Policy Binding, and choosing Default Load Balancing Virtual Server.

Now we have successfully created a content switching vServer that does a redirect of our users that are connecting using an Android-based device.

Set cs vServer nameofvServer –casesensitive OFF

Another important aspect of content switching is setting up protective features. Even though content switching has monitors in place to check if the backend services are up or not, we can define a redirect URL or backup virtual server in case the CS vServer should go down or has too many connections. These settings can be defined in the vServer settings, Protection. Here we have a Redirect URL or a Backup Virtual Server. The redirect URL can only use HTTP or SSL because of protocol restrictions when handling redirection properly. We can also define the spillover here; spillover can be used to redirect excessive traffic to the backup vServer. It can also be specified to drop or accept excessive traffic. In order to use spillover with redirect we need to define a backup vServer and we also need to specify a threshold. For instance, let's say that our vServer can handle 10,000 connections; excessive traffic is going to be redirected to a backup vServer that is another lb vServer. If that vServer hits its limits or if both the primary vServer and the backup vServer go down, users will be redirected to the Redirect URL.

We have also specified a Spillover Persistence Timeout (mins), meaning that users that are diverted to the backup vServer have persisted connections for 2 minutes.