If you have been following this series up till now, meaning you actually have read part one through five, then Content Switching should be a relatively easy concept to grasp. If you understand what a vServer is, how a service and server object are bound to each other and that we use monitors to constantly check if all is up and running then you are basically good to go. All we need now is a content switch vServer and a basic load balance setup and take it from there.
Other (related) articles from these series include:
- Citrix NetScaler Gateway, the basics!
- Citrix NetScaler (10.5) licensing. What’s new with Access Gateway!
- Citrix NetScaler… The basics continued, part one. VIP’s, Monitors and other objects!
- Citrix NetScaler… The basics continued, part two. Static routes, SNIP and MIP!
- Citrix NetScaler… The basics continued, part three. High Availability!
- Citrix NetScaler… The basics continued, Part four. What about SSL?
- Citrix NetScaler… The basics continued, Part five. Global Server Load Balancing!
- Citrix NetScaler… The basics continued, part seven. Split Tunneling!
In simple terms…
Content switching allows us to have one single point of entry (one IP address, potentially using multiple domains / URL’s) to access various types of back-end services like, XenApp, XenDesktop, specific web services like (management) portals, webmail and so on, but also mobile (management) platforms, ShareFile, content in different languages… and the list goes on.
For each type of service as mentioned above, an accompanying content switching policy will be created. Based on its configuration incoming traffic will then be forwarded to a corresponding load balance vServer directing them to the content or service as initially requested by the user, or explicitly stated in the policy.
For example, all traffic coming from a specific URL/ domain, port number, IP range or browser version must be send that way, but all traffic send from mobile devices (incepting the HTTP header) must be send this way. But don’t worry I’ll elaborate a bit more on this in just a minute.
What it is made of
Let me start by listing which components and services are needed to come to a complete content switching setup from a NetScaler perspective.
- Before anything else we start by enabling the content switching feature.
- Create / configure a content switching vServer, including a VIP accepting external / internal requests.
- Next we need to set up and configure multiple (minimum of two) load balance vServers to which the content switching vServer can forward traffic / requests.
- Once we have that set up we need to configure at least two or more content switching policies, one for each type of service or the type of content you want to offer, and bind them to the content switching vServer.
- Last but not least we’ll create multiple services and server objects, monitors (load balance vServers) and bound them together.
Step one through four is what we refer to as a Content Group.
Some more…
To make use of content switching you will at least need to have a NetScaler standard license or up, a NetScaler Gateway license for example, won’t be sufficient. Once enabled we configure and set up our content switching and load balance virtual servers (vServers), the service and server objects and monitors that go with it, as explained in part one of this series.
When load balance servers are used together with content switching they don’t need to have a VIP configured.
As we’ve (sort of) highlighted earlier, the real magic happens within the content switching policies, which get bound to the content switching vServer. Let’s break it down real quick and easy…
1. A request / traffic comes in on the content switching vServer 2. The policies get evaluated in a certain order based on priorities or in the order that they are created (more on this in a minute) 3. The first one (policy) that matches your request will get applied. 4. Your request / traffic will be forwarded to one of the configured load balancing servers, which will take over from there.
When you bind a policy to a content switching vServer you also tell it to which load balance vServer the associated traffic needs to be forwarded.
Depending on the type of policy you use, there are two, classic policies and expressions and default syntax policies and expressions, you can choose to prioritize your policies or apply them in the order that they were created as mentioned earlier. With default syntax policies you must assign a priority, when using classic policies / expressions you can apply a priority but you are not required to.
Content switching virtual servers can only send requests to other virtual servers. If you are using an external load balancer, you must create a load balancing virtual server for it and bind its virtual server as a service to the content switching virtual server.
Content switching policies can be…
Domain-based policies. The NetScaler appliance compares the domain of an incoming URL with the domains specified in the policies. The appliance then returns the most appropriate content. Domain-based policies must be classic policies; default syntax policies are not supported for this type of content switching policy.
URL-based policies. The appliance compares an incoming URL with the URLs specified in the policies. The appliance then returns the most appropriate URL-based content, which is usually the longest matching configured URL. URL-based policies must be classic policies; default syntax policies are not supported for this type of content switching policy.
Rule-based policies. The appliance compares incoming data to expressions specified in the policies. You create rule-based policies by using either a classic expression or a default syntax expression. Both classic and default syntax policies are supported for rule-based content switching policies.
Default syntax policies, formerly known as ‘Advanced policies’ can perform the same evaluations as classic NetScaler policies, but are able to evaluate more data and to configure more operations in the policy rule.
HTTP headers…
Content switching can also be applied by reading the contents of the HTTP header coming from the client. A few examples. By inspecting the HTTP header the NetScaler is able to redirect content based on a cookie, language or device type. Also, the HTTP methods that are used like GET or POST for example can be used to direct traffic to a certain web server.
And last but not least, layer 3/4 information like the source or destination IP address; source and/or destination ports and any other information that can be found within the UDP and TCP headers can be used. In one of the upcoming parts I’ll spend some more time on the different policies and expressions available when configuring so-called rule-based policies, policy labels included.
The NetScaler Gateway and content switching
As of Gateway version 10.5 we can also bind content switching policies directly to our NetScaler Gateway vServers. This is how it works, all connection / requests for the NetScaler Gateway vServer will be handled and processed as normal. The only difference is that the policy engine will first check to see if any content switching policies have been defined and if any will match. If so, then those will be processed first and the traffic will be send over to the load balance vServer as configured in the content switching policy. All other traffic will be routed to and through the NetScaler Gateway vServer, business as usual.
Unified Gateway Server
The unified gateway server functionality which was added as part of the NetScaler version 11 release, also makes it possible to receive traffic on one external IP address and direct that traffic to a virtual load balance vServer bound to the Unified Gateway vServer. This allows administrators to free up external IP addresses without making any compromises with regards to the desired functionalities. Can you see the similarity with Content Switching?
The content switching virtual server is the primary component of the Unified Gateway feature. See one of the NetScaler config wizard screenshots below as well.
A Unified gateway vServer can be fronted by a NetScaler Gateway vServer (all features supported) handling external authentication before directing traffic to any of the additional configured load balance vServers bound to the Unified Gateway vServer, as shown it uses the content switching functionality build into the appliance / software for this to work. For some more information on the Unified Gateway functionalities have a look at the FAQ here.
Content switching visual
I’ll let the graphic do the talking here…
Again, and as always, thank you for reading. To be continued…
