The Netscaler (now Citrix) load balancer has pretty clear conceptual, logical, and work flow. That is, well, to a system/network engineer like me anyway. To touch it off visually by a GUI, all this is neatly grouped under the 'load balancing' leaf node and the 'content switching' leaf node on the left pane of the Applet or Web Start GUI.
- define servers. A server is created by a pair of server name and its physical IP address: node8/192.168.88.8 node9/192.168.88.9 ... node100/192.168.88.100.
- define services. A service is created by binding the server IP address with a service port (port number and protocol, e.g. TCP/80, UDP/53, UDP/123).
- Take web service for example, a service named "prod_web_node1" can be created by binding TCP/80 with node1's IP address.
- Custom and default health monitored can be applied to the service.
- Multiple monitors can be applied a service with different weight and such.
- Web service is the most popular for an application switch or a load balancer. In fact, it is the only protocol rendered capable of content-switching by the Citrix Netscaler series.
- create a load-balancing "virtual server" (From CLI, it is 'add lb vserver'.) to front a group of services to be load-balanced.
- weight can be applied to each LB member service.
- load balancing algorithm can be chosen (many variations of round-robin, least connection, LTRM, etc.)
- advanced setting can be adjusted here, such as timeout values for an idle server or an idle client.
Any 'lb
vserver' can be utilized in two different ways:
- As a public service by itself. It can be exposed to clients as a service by assigning a virtual IP:Port. In other words, the load balanced service group becomes a service usable by the clients (directly). If load balancing is all you need, your work is done here.
- As a private service to a Content Switching (CS) virtual server (vserver). No IP:port is assigned to it. In other words, the load balanced service group won't be a service usable by the clients (directly). It can only be accessed/referenced by its name, as an internal object, from within the Netscaler running context (aka, by the the content switching engine we'll discuss in Part II of this post) in the latter case. That's right, it is more like a call-by-reference.
Post a Comment