A Simple Load Balancing Configuration

A Simple Load Balancing Configuration

In the example shown in the diagram, the NetScaler is configured to function as a load balancer. For this configuration, you need to configure virtual entities specific to load balancing and bind them in a specific order. As a load balancer, a NetScaler distributes client requests across several servers and thus optimizes the utilization of resources.

The basic building blocks of a typical load balancing configuration are services and load balancing vservers. The services represent the applications on the servers. The vservers abstract the servers by providing a single IP address to which the clients connect. To ensure that client requests are sent to a server, you need to bind each service to the vserver. That is, you must create services for every server and bind the services to the vserver. Clients use the VIP to connect to a NetScaler. When the NetScaler receives client requests on the VIP, it sends them to a server determined by the load balancing algorithm. Load balancing uses a virtual entity called a monitor to track whether a specific configured service (server plus application) is available to receive requests.

In addition to configuring the load balancing algorithm, you can configure several parameters that affect the behavior and performance of the load balancing configuration. For example, you can configure the vserver to maintain persistence based on source IP address. The NetScaler then directs all requests from any specific client to the same server.

Understanding Virtual Servers

A vserver represents one or more applications in a server farm. The vserver is a named NetScaler entity that external clients can use to access applications hosted on the servers. It is represented by an alphanumeric name, virtual IP address (VIP), port, and protocol. The name of the vserver is only of local significance and is designed to make the vserver easier to identify. When a client attempts to

access applications on a server, it sends a request to the VIP instead of the IP address of the physical server. When the NetScaler receives a request on the VIP, it terminates the connection at the vserver and uses its own connection with the server on behalf of the client. The port and protocol settings of the vserver determine the applications that the vserver represents. For example, a Web server can be represented by a vserver and a service whose port and protocol are set to 80 and HTTP, respectively. Multiple vservers can use the same VIP but different protocols and ports.

Vservers are points for delivering features. Most features, like compression, caching, and SSL offload, are normally enabled on a vserver. When the NetScaler receives a request on a VIP, it chooses the appropriate vserver by the port on which the request was received and its protocol. The NetScaler then processes the request as appropriate for the features configured on the vserver.

In most cases, vservers work in tandem with services. You can bind multiple services to a vserver. These services represent the applications running on physical servers in a server farm. After the NetScaler processes requests received on a VIP, it forwards them to the servers as determined by the load balancing algorithm configured on the vserver. The following diagram illustrates these concepts.

The preceding diagram illustrates a configuration consisting of two vservers with a common VIP but different ports and protocols. Each of these vservers has two services bound to it. The services s1 and s2 are bound to VS_HTTP and represent the HTTP applications on Server 1 and Server 2. The services s3 and s4 are bound to VS_SSL and represent the SSL applications on Server 2 and Server 3 (Server 2 provides both HTTP and SSL applications). When the NetScaler receives an HTTP request on the VIP, it processes the request based on the settings of VS_HTTP and sends it to either Server 1 or Server 2. Similarly, when the NetScaler receives an HTTPS request on the VIP, it processes it based on the settings of VS_SSL and it sends it to either Server 2 or Server 3.

Vservers are not always represented by specific IP address, port numbers, or protocols. They can be represented by wildcards, in which case they are known as wildcard vservers. For example, when you configure a vserver with a wildcard instead of a VIP, but with a specific port number, the NetScaler intercepts and processes all traffic conforming to that protocol and destined for the predefined

port. For vservers with wildcards instead of VIPs and port numbers, the NetScaler intercepts and processes all traffic conforming to the protocol.

Vservers can be grouped into the following categories:

• Load balancing vserver. Receives and redirects requests to an appropriate server. Choice of the appropriate server is based on which of various load balancing methods the user configures.

• Cache redirection virtual server. Redirects client requests for dynamic content to origin servers and static content to cache servers. Cache redirection vservers often work in conjunction with load balancing vservers.

• Content switching virtual server. Directs traffic to a server on the basis of the content that the client has requested. For example, you can create a content switching vserver that directs all client requests for images to a server that serves images only. Content switching vservers often work in

conjunction with load balancing vservers.

• Virtual private network (VPN) virtual server. Decrypts tunneled traffic and sends it to intranet applications.

Note: For more information about features, see the Citrix NetScaler Traffic Management Guide.