When dealing with the Citrix NetScalers there is a lot to get your head around, especially when you are still relatively new to the product / technology. The different licensing models, all of the ADC (Application Delivery Controller) features (and there are a lot) the secure remote access gateway functionality and a whole bunch of abbreviations like NSIP, SNIP, MIP, VIP and so on and so forth, which will have your head spinning in no time. You have to know about monitors, static routes, load balancing, HA and more. A very interesting, powerful but potentially confusing product when starting out.
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 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 six. Content Switching!
- Citrix NetScaler… The basics continued, part seven. Split Tunneling!
It’s important to understand the basics and work your way up from there. Walk before you run, or something to that extend. That’s why I have put together a series of ‘getting started’ articles, starting with this one. I will assume that the information described in this and this article is known and take it from there while discussing, static routes, monitors, basic load balancing, HA, using multiple subnets and more… in this and some of the other blogs still to come.
The objective for today
In this article I covered some of the basic NetScaler terminology, today I’d like to take it one step further and talk about the virtual server object in some more detail, including the service and server objects and the so called monitors that come with it.
Virtual servers
Virtual servers come in several different tastes; for example, you can have a virtual server for gateway purposes, handling secure remote access for your users. You can have a virtual server to load balance traffic, one to handle content switching or VPN access etc. Needles to say that you can, and sometimes will, have multiple virtual servers on your NetScaler. It is what they call a logical object.
However, for the purposes of this article it doesn’t really matter what kind or type of virtual server we want to implement, there are a few basic steps, which will (almost) always need to be taken care of. Before getting visual I’ll first try and explain textually what is needed, and what does what, from a NetScaler configuration perspective.
Think of the NetScaler virtual server as the first point of contact (though a firewall will probably sit in front) from an external user perspective when trying to access resources from your internal network, it is where the external connection terminates and where the NetScaler takes over. A virtual server will have a VIP, or virtual IP address, which will be ‘known’ on the outside. Besides a VIP, it will also have a name (primarily used for administration purposes) including a definition of the protocol and port it will support.
Service and server objects
Once a virtual server has been configured one of the next steps will include the set up and configuration of a so-called service object. A service object basically represents an application running on one of your back-end systems, like HTTP for example, when dealing with webserver requests.
This is how it would work. First we create a service object and give it a name, again primarily for administration purposes, then within the service object we tell it to what type of protocol and port number it should apply its magic and last but not least, to which physical or virtual back-end server it should forward the actual requests, HTTP in this case. Once done, the service object and the virtual server will be bound together, a process which is referred to as binding, see the image below.
To help the service object in actually finding the physical or virtual back-end system, as mentioned above, we will also need to create and configure a server object (don’t get confused, yes, we have server and service objects) which we will then need to bind to the earlier created service object.
The server object will also have a name within the NetScaler configuration, just like the virtual server and service object, and it will point to the IP address or FQDN of the actual back-end system handling the HTTP requests. One server object per back-end web server.
Resume
Ok, let’s do a quick resume. We have our virtual server, which has a VIP or virtual IP address, a name, protocol and port number. The virtual server is then bound to a service object, while the service object is bound to a server object, which points to the actual physical or virtual back-end server handling the HTTP requests. Are you still with me?
Time to monitor
In the visual representation below, hopefully, you’ll notice that load balancing, when implemented / configured, will take place at a virtual server / service object level. Obviously there will need to be a way for the virtual server to monitor the service objects on the back-end system it is load balancing to.
Otherwise, if one or multiple of those services become unavailable (down), because the accompanying back-end system has crashed for example, and the virtual server doesn’t know about it, it will keep load balancing requests to those service objects resulting in 404 errors, the requested resource is not available. Enter monitors…
Let’s get visual
A monitor is another logical object that sits in between the service and the server object (note that it is bound to the service object) and constantly monitors the overall health and availability of the physical or virtual back-end systems (the services on it) handling the actual HTTP requests.
As soon as a monitor notices that a back-end system, or the services on it, becomes unresponsive it will show the accompanying service, that it has been bound to, as down within the NetScaler management console, and it will stop sending traffic its way. Ok, so here is the visual representation of it all, hopefully it makes sense, I tired to keep it as simple as possible.
This should give you a high level overview on some of the NetScalers basic functionality with regards to traffic flow and the some of the terminology used, there will be a bit more to it when you actually start building and configuring, but hey, you have got to start somewhere right?! In some of my future posts I’d also like to highlight HA, adding in multiple subnets, static routes etc… Hopefully you have found this one of some use. Will keep you posted.
2 responses to “Citrix NetScaler… The basics continued, part one. VIP’s, Monitors and other objects!”
Nice explanation. I appreciate the breakdown and flow.
Thanks for that very helpful article. I visited an official CTX NetScaler Course few weeks ago and I would have been happy, the trainer could explain in that way…