Virtual Servers

This chapter describes the concept of a virtual server, a configuration object used to represent the interface between a Traffic Manager and the Internet.

Introduction

A virtual server manages all the traffic for a specified port and protocol. It can apply rules to decide which pool should handle a request, and can decrypt SSL traffic if required.

The Traffic Manager supports a wide range of protocols. Specialized handlers are provided for complex protocols such as HTTP, RTSP and SIP, and the software can load-balance TCP connections and UDP sessions using the “Generic” protocol versions. Details about the protocol support available can be found in Protocol Support

To view a list of your virtual servers, click Services > Virtual Servers. Click the name of an existing virtual server to modify its settings, or create a new virtual server using the “Create a new Virtual Server” section.

Using Virtual Servers

Generally, you should plan to run one virtual server for each distinct service you are running. That is, each TCP or UDP port you are accepting traffic on.

For example, you should run one virtual server for HTTP, irrespective of how many distinct Web sites you are running on port 80. This differs from the way you might configure a Web server, where you configure one virtual server for each distinct Web site. If you need subtly different traffic management configurations for each Web site, these can be implemented using TrafficScript to control how the traffic is managed.

A typical Traffic Manager installation might only have 5 or 10 virtual servers configured. If you anticipate having more than 100 virtual servers, you should plan to manage your Traffic Manager system using the programmatic Control API (see The Traffic Manager Control API) or REST API (see the Pulse Secure Virtual Traffic Manager: REST API Guide) rather than the Web-based Admin UI.

Selecting a Protocol

When you configure a virtual server, you need to specify the protocol of the traffic it is handling. The protocol value is the internal protocol used within the Traffic Manager to parse and interpret the traffic. Choose the most appropriate protocol setting for the traffic you are managing.

The “Generic Server First”, “Generic Client First” and “Generic Streaming” protocols are simple TCP protocol handlers that process TCP connections, forwarding data between clients and servers. The three protocols differ as follows:

•When the Traffic Manager receives a connection on a ‘Generic Server First’ virtual server, it immediately runs any TrafficScript rules, makes a load-balancing decision and connects to a back-end server. It then relays data bi-directionally between the client and the server.

This selection is appropriate for protocols where the server application writes a “handshake” or “banner” message when the client application connects, before the client writes any data to the server.

•When the Traffic Manager receives a connection on a “Generic Client First” virtual server, it does not process the connection until some data has been received from the client. The Traffic Manager then runs TrafficScript rules, makes the load-balancing decision, connects to the selected back-end server and writes the data previously received from the client. The Traffic Manager then relays data bi-directionally between the client and the server.

This selection is appropriate for protocols where the server expects the client to initiate the dialog by writing data first.

•The “Generic Streaming” protocol resembles Generic Server First, however is an appropriate choice where the virtual server is expected to handle non-request/response data originating from either the client or the back-end server. The Traffic Manager runs associated TrafficScript rules each time, makes a load-balancing decision and then relays data bi-directionally between the client and the server.

This selection is appropriate for protocols where the server or client may initiate the dialog, but not automatically expect a response to any data received.

These generic protocols are the foundation that other TCP protocol handlers are built upon. The generic protocols allow you to inspect and rewrite request and response data and synchronize the communications between the client and the server, but only at a very low level.

The other TCP protocol handlers in the software are specialized for particular protocols – FTP, HTTP, and so on. When you select a more specialized protocol such as HTTP, the following conditions are true:

•Additional protocol-specific options are made available in the configuration of the virtual server and pool, such as “keepalive” settings for HTTP or security settings for FTP.

•The Traffic Manager parses messages in that protocol and allows you to use additional TrafficScript functions to manage the request and response data more easily; helper functions to read and set Cookies in an HTTP transaction, for example.

You can use the appropriate basic “Generic” protocol handler when you are processing a high-level protocol such as HTTP. If you do so, you will be unable to use the specialized handling for that protocol.

A virtual server also supports traffic over UDP. You can select either basic UDP (for a simple UDP request-response protocol such as DNS) or UDP streaming (where the server may send a limitless number of UDP packets in response to a request).

Refer to Protocol Support for more details about specific protocol support.

If the Traffic Manager decrypts SSL-encrypted traffic, references to protocol refer to the protocol of the decrypted traffic. For example, if the Traffic Manager is receiving HTTPS traffic on port 443 and uses SSL decryption to decrypt it, then the protocol in use within the Traffic Manager is HTTP.