Load balancing Microsoft IAG

(1)

Load balancing Microsoft IAG

(2)

Introduction

This document will show you how to deploy ZXTM with Microsoft ® Intelligent Application Gateway (IAG) server. The Whale Communications IAG server is a SSL VPN technology which was acquired by Microsoft ®in July 2006.

We will discuss using ZXTM to load balance IAG VPN services, to increase the availability and performance of your Microsoft edge services.

In this white paper we will assume you are using ZXTM LB Virtual Appliance (VA) for Windows running on the same hardware as the IAG server. However the content is also relevant to customers using other variants of Zeus ZXTM or ZXTM LB software on different platforms, ZXTM or ZXTM LB Appliances, or ZXTM Virtual Appliances.

What is ZXTM?

ZXTM (Zeus eXtensible Traffic Manager) is an application load balancer and Traffic Manager. It operates at layer 7 (the application layer) of the OSI stack. ZXTM manages your application traffic, by performing deep packet inspection, and making dynamic routing decisions as it load balances traffic across your application infrastructure.

ZXTM also monitors the availability of those applications and ensures that your clients receive the best possible service. ZXTM is fully fault tolerant and will cluster with other ZXTM instances to ensure high availability of your applications even if one of the ZXTM instances should fail.

We often think of ZXTM as a toolkit, which, with our powerful TrafficScript™ language can implement almost any traffic routing logic you could ever require.

ZXTM is available as software, as virtual appliances and as dedicated hardware appliances. It also comes in two main variants, full ZXTM, and ZXTM LB. ZXTM LB is the entry level load balancer and is perfectly suited for managing IAG and simple ISA services.

For more information on ZXTM, please see the following documents:

http://www.zeus.com/documents/en/Wha/What_is_an_Application_Traffic_Manager.pdf http://knowledgehub.zeus.com/internal/2007/02/07/what_is_zxtm

(4)

Installing ZXTM VA for Windows

The ZXTM VA for Windows download is available from Value Added Resellers and OEMs of Zeus Technology. For more information contact Zeus Technology at www.zeus.com. Once you have downloaded the most recent version of the installer you can begin installation by executing the setup.exe application.

The setup application will extract the files required by the installer and then launch the Installation process automatically.

Follow the on-screen instructions to install ZXTM VA for Windows on to your server. The screenshot above shows the “Welcome Screen”, after clicking “Next” on this screen, you will be shown the ZXTM license agreement, which you will need to accept this in order to continue with the installation.

You will then be shown a list of pre-requisite software for running ZXTM VA for Windows. At present, the requirements are a fully working installation of Microsoft Virtual Server 2005.

(5)

Finally, you will be asked to configure the network interfaces on the ZXTM VA for Windows, and bind them to physical interfaces on your host server.

That’s the final configuration option. The next screen will start the installation of the ZXTM VA for Windows. Once complete you can access the ZXTM Administration Interface by clicking the application launcher in the Start menu.

For more information on installing, configuring and using the Windows version of ZXTM, please refer to the following documents:

http://knowledgehub.zeus.com/articles/2007/05/21/zxtm_software_running_on_windows http://knowledgehub.zeus.com/media/4.2/windows_quickstart.pdf

http://knowledgehub.zeus.com/media/4.2/user_manual.pdf

Running the Initial Configuration Wizard

The first time you connect to your newly installed ZXTM, you will be required to run the Initial Configuration Wizard.

(6)

needs to be in the same subnet as one of the addresses assigned to the ZXTM VA for Windows.

In the configuration shown above, we have assigned 10.100.42.11/16 to eth0 and 192.168.50.11/24 to eth1. There are two network interfaces on this Virtual Appliance, but you may only need to use one. The addresses you configure here are to access the ZXTM VA itself. We will configure the HA (high availability) addresses later which will host the IAG service.

Completing the wizard

Follow the on-screen instructions to complete the Initial Configuration Wizard. You will be required to configure your DNS settings, Date and time zone, admin user password, and upload a valid ZXTM license. When complete, your ZXTM VA for Windows will be restarted. Click the link to access the new administration server.

Deployment Architecture

The ZXTM VA for Windows and IAG server will be running on the same physical hardware, but they are logically separate servers. This is because the ZXTM VA for Windows software will be running inside a Microsoft Virtual Server Machine

(7)

To maintain service availability in the event of a physical failure you should deploy ZXTM VA for Windows and IAG servers in pairs. Once you have completed the installation and Initial Configuration Wizard on both ZXTM virtual appliances, you can join them into a cluster by using the “join a cluster” wizard from the ZXTM User Interface.

The following diagram shows a typical ZXTM VA for Windows/IAG deployment. The ZXTM instances on Server One and Server Two are clustered together. ZXTM uses Traffic IP Groups to manage the High Availability of a service. In this example the ZXTM cluster has raised two IP addresses in the TIP Group, 10.100.42.15 and 10.100.42.16. All connections to those addresses are load balanced across the instances of the IAG software.

The service will continue to run in the event of either physical server failing.

Configuring Your ZXTM VA for Windows for IAG Service

Typically, your IAG service will consist of a HTTP connector and a HTTPS connector. The HTTP connector will primarily be used to redirect connections to the HTTPS service. On your ZXTM cluster, you will need to configure these two services.

Manage a new service wizard

We will use a configuration wizard to create your new ZXTM services. From the ZXTM user interface, select the “Manage a new service” wizard from the wizards list on the top right of the home screen.

(8)

Call the service “Whale HTTPS”, the protocol should be SSL, with a sub-protocol of HTTPS. ZXTM will select the default port of 443, but you may change this if you want to run the service on a different port.

After clicking “Next”, you will be asked to add the nodes for this service. You should add the IP addresses that the two IAG servers are listening on. The port will default to the same port you configured in the previous screen, but you can change that if your IAG servers are listening on a non-standard port.

Clicking “Next” will take you to a summary screen, if everything looks correct then click the “Finish” button.

(9)

The ZXTM will now create a Virtual Server (the service listener) and a Pool (a collection of nodes) for your new “Whale HTTPS” service, using the values you supplied to the wizard. You will need to repeat this process to create a “Whale HTTP” service, running on port 80, with a protocol of HTTP.

Creating a Traffic IP Group

ZXTM will have created your service and bound it to all IP addresses on the ZXTM. However if we want this service to be Highly Available, we need to configure a group of floating IP addresses, which ZXTM will always keep running even in the event of a hardware failure. In ZXTM terminology, these IP addresses are called Traffic IPs, and they are grouped together, so that you can have more than one IP active at a time. Groups of Traffic IPs are called Traffic IP Groups. We will now configure one for your Whale service.

Navigate to the Services section and then the “Traffic IP Groups” tab.

If you want the service to be active on both ZXTMs in your cluster you will need to create a group containing 2 Traffic IP addresses. In the example above I have called the group “Whale Group” and I want it to be active on both my ZXTMs. Therefore I have set 2 addresses in the IP Addresses field, 10.100.42.15 and 10.100.42.16. Clicking on “Create Traffic IP Group” will create the configuration and distribute it across the cluster. Next we need to bind our Whale HTTP and HTTPS services to this new TIP group.

Binding a service to a Traffic IP

Navigate to the Services section again, but this time select the Virtual Server tab. For each of your services, “Whale HTTP” and “Whale HTTPS” click the edit button and then under Basic Settings, change “Listening on:” to “Traffic IP Groups”. When you select this setting, you should now see a list of configured Traffic IP Groups to pick from. Select the “Whale Group” you created above.

(10)

ZXTM will now bind your service to the IP addresses in the Traffic IP Group. In the event of one of your ZXTMs failing, the IP that was hosted on that ZXTM will migrate across to the ZXTM which is still running and service will continue.

Session Persistence

Many classes of requests from clients can be load-balanced across a pool of back-end servers. Multiple requests from one client can be shared across the back-ends with no disruption to service. However, there are certain exceptions, such as server applications which depend upon storing information about a client locally, which may not readily be load-balanced in this way (e.g. IAG). If the established connection were to be sent to a different IAG backend server then a server application error would occur and the user would be disconnected. To prevent this from happening, we use Session Persistence.

When ZXTM receives a new connection, it uses its load balancing logic to choose a node for that connection. ZXTM then records the chosen node in a session persistence map. When another connection in the same session is received, ZXTM uses the node that was chosen previously. In this way, all connections in the same ‘session’ are pinned to the same back-end node.

There are many different ways of implementing Session Persistence within ZXTM VA for Windows. The three ways we will be concentrating on in this document are: (1) SSL Session ID (2) IP-Based Session Persistence and (3) SSL Decryption/Re-encryption and Named Node Persistence.

SSL Session ID

In order for the service to function properly the ZXTM cluster needs to ensure that client connections are persisted to the correct IAG backend server. This is achieved with a Session Persistence class. Session Persistence is carried out at the pool level, so you should navigate to the pools tab within the Services section of the UI and edit your “Whale HTTPS” service. Then you should select “Session Persistence”.

Comment [SW1]: I think we need a brief introductory paragraph for 'Persistence' explaining what it is and stating that there are three main ways of implementing persistence: SSL session; IP source address; using the advanced traffic inspection capabilities of ZXTM to persist upon any unique identification value in the traffic stream.

(11)

Because this is a new ZXTM installation we do not yet have any persistence classes to choose from. Therefore, we must create one now. Click on the “Create New Session Persistence Class” option.

Call the class “Whale SSL Session ID” and leave the tick box checked to associate the new class with the “Whale HTTPS” pool. Click on the “Create Class” button.

You will be taken to the Persistence class editing screen where you should change the type of persistence to SSL Session ID. This class uses the SSL Session ID to identify sessions and associate them with the correct backend IAG server. There is an important caveat that the SSL Session ID can change over time, either side of the connection may request that the session be renegotiated. If that occurs then the ZXTM will need to create a new mapping and could result in the session being sent to the other IAG server. If that causes problems you may consider using one of the other persistence methods.

IP Based

When IP-based persistence is selected, ZXTM will track the originating client’s IP address for each request to the IAG pool. If ZXTM has already received traffic from this address, it will map requests to the same IAG backend it used previously

IP session maps are shared by all ZXTM machines in a cluster. Requests received by different ZXTM machines will be directed to the correct IAG back end, and if one ZXTM fails, the other ZXTMs are aware of the IP session maps it was maintaining.

To create an “IP based” session persistence, go the Services => Pools => Whale HTTPS => Session Persistence and create a new session persistence class.

(12)

For the session persistence method, choose “IP-based Persistence”.

Now your “Whale HTTPS” pool will be using IP-based session persistence.

It should be noted that when using IP-based persistence, if you have a lot of clients connecting from behind the same proxy, they will all be presenting the same IP address to

(13)

the ZXTMs and so all of these connections will be sent to the same backend IAG server. One of your IAG servers may therefore be working significantly harder than the others.

SSL Decryption/Re-encryption

ZXTM can be used to decrypt the SSL connection and examine the contents of the SSL traffic. Decrypting the SSL traffic will allow ZXTM to access the http headers and also enable it to use the other Session Persistence methods (such as Transparent Session Affinity or to monitor Application Cookies). Please see the ZXTM User Manual for more information on the other Session Persistence methods supported by ZXTM.

As SSL Session ID and IP-based persistence both have their potential drawbacks (as previously noted), the decryption of SSL allows for more sophisticated session persistence methods to be used.

In our example, we will use the User-Agent to determine which of the two IAG backend servers to route the traffic to. In our example, all our business users use Internet Explorer as their browser while all our technical users (i.e. development and support departments) use either Opera or Firefox. We will configure ZXTM so that it uses the User-Agent to decide which IAG backend the traffic should go to and to persist to that backend node.

In order to allow ZXTM to decrypt the SSL traffic, we need to import the IAG SSL certificate into ZXTM. First, we export (as a .pfx) the certificate and the private key from the IAG backend. Please consult your Microsoft Windows documentation for the procedure to export the certificate and the private key.

Once we have the pfx file, we convert the pfx format into PEM format by either installing OpenSSL on a Windows machine or by using a Linux/Unix machine which has OpenSSL installed.

On Windows the command to run is:

openssl.exe pkcs12 -in <drive:\path\to\cert>.pfx -nodes -out <\path\to\new\cert>.pem

On Linux/Unix, run :

openssl pkcs12 -in </path/to/exported/cert>.pfx -nodes -out </path/to/new/cert>.pem

The resulting file “<cert>.pem” will contain something like the following:

Key Attributes

X509v3 Key Usage: 10 ---BEGIN RSA PRIVATE KEY---

(14)

subject=/C=GB/ST=Cambridgeshire/L=Cambridge/O=Zeus Technology/OU=IT/CN=lb.contoso.com

issuer=/DC=com/DC=contoso/CN=DC ---BEGIN CERTIFICATE---

MIIFaDCCBFCgAwIBAgIKE9aOTQAAAAAAGzANBgkqhkiG9w0BAQUFADA7MRMwEQYK CZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPyLGQBGRYHY29udG9zbzELMAkGA1UE FK+kwETUOqAA3pKRvqE+4HAnIpuUZprofoGZ6q/v/dg/mTCX7tEMeA2SV0g8r1CB cYM43QEKMYVCZEolGlbOxA0qyyYr+jHzlIqcjwJ3KFkEVxMpvLgQvgbLzIs=

---END CERTIFICATE--- [snip]

To create the certificate file, we copy all the lines from – BEGIN CERTIFICATE – to – END CERTIFICATE – to a new file and give the file a name.

To create the private key, we copy all the lines from –-BEGIN RSA PRIVATE KEY— to –-END RSA PRIVATE KEY--

You can now go the ZXTM user interface and import the certificate and private server key. Go to Catalogs => SSL => SSL Certificates Catalog => Import Certificate

Once the certificate file and private key file are exported, we see the newly created certificate, in our case called “lb.contoso.com”.

(15)

(16)

Assign the two IAG IP addresses as backend nodes (note they are still listening on port 443).

Once our “Whale HTTPS Decrypt” virtual server has been created, we need to edit it further to enable the decryption/re-encryption. Edit the SSL Settings for the virtual server (Services => Whale HTTPS Decrypt => SSL Decryption). Set the ssl_decrypt to “yes” and assign our SSL certificate “lb.contoso.com” as the cert to be used by the virtual server.

(17)

Once we have configured the SSL settings for the virtual server, we need to edit the SSL settings for the pool, System => Pools => Whale HTTPS Decrypt => SSL Settings. Now we need to make sure that ZXTM re-encrypts the SSL traffic before handing it over to the IAG backend server. We could, of course, always leave the traffic unencrypted if we were handing http (not https) to the backend servers. For the IAG backend servers, we will use https. Set ssl_encrypt to “yes” to get ZXTM to re-encrypt the traffic before sending to the IAG server.

(18)

Success! We can see the IAG login user interface, everything is working correctly.

TrafficScript Example

Now we can use the User-Agent for our session persistence purposes. As we already mentioned, ZXTM supports a number of different methods for Session Persistence such as application cookies etc. Decrypting the SSL traffic gives us an array of different options when it comes to persistence (see the ZXTM User Manual for more information on Session Persistence). We will be using “Named Node” persistence.

We create a TrafficScript request rule (please note that ZXTM’s Trafficscript scripting language is only supported in the full ZXTM licenses and not in the ZXTM LB license) to capture the User-Agent and, on the basis of which browser is being used, route the traffic to a particular IAG backend server. This kind of scenario would allow you to have a pool of IAG backend servers from which you can then allocate a particular IAG backend for a particular group (or group) of users etc

(19)

(20)

log.info("User Agent: ".$user_agent);

#Business Users

if (string.contains($user_agent,"MSIE")) {

connection.setPersistenceNode ( "10.10.10.10:80" ); }

# Technical users - Development and Support if (string.contains($user_agent,"Firefox")|| string.contains($user_agent,"Opera") ) {

connection.setPersistenceNode ( "10.10.10.20:80" ); }

Now we add this rule as a request rule to our virtual server:

Now that we have the rule in place, our connection should persist on the relevant IAG backend server using the User-Agent to decide which IAG backend server to use.

(21)

We turn on “Access Logging” on our virtual server “Whale HTTPS Decrypt” so we can log the connections from the different browsers to the IAG backend nodes and check that our rule is directing traffic to the correct backend IAG node on the basis of which browser is being used.

The macros for the log format are as follows:

%F = The 'favored' node that ZXTM would like to use for this connection

%n = Node that was used for the connection

%N = Node required to handle this connection (because of session persistence) %{User-Agent} = user-agent header ie the browser used

After performing tests with various browsers, we can examine the “Access Logs” for this virtual server. What we should see is that any connections to https://lb.contoso.com/ using IE get sent to 10.10.10.10 and any connections from Opera or Firefox get sent to 10.10.10.20. Looking at the log entries below, we can see this is the case.

- 10.10.10.10:443 10.10.10.10:443 Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1)

(22)

- 10.10.10.20:443 10.10.10.20:443 Opera/9.24 (Windows NT 5.1; U; en)

- 10.10.10.20:443 10.10.10.20:443 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

Other rules could be applied to our traffic to take into account other factors such as day of week/time of day etc so we could on the basis of the time refuse a connection to the IAG backend servers. While SSL Session ID and IP-based session persistence are easier to setup than SSL decryption/re-encryption, these methods are not as sophisticated and are not as customisable. One of the great things about ZXTM VA for Windows is that it is very flexible and customisable.

RuleBuilder Example

We can, of course, also achieve the same functionality using RuleBuilder. RuleBuilder is supported in both ZXTM LB and full ZXTM installations. To do this we need to create 2 pools – IAG1 containing 10.10.10.10:443 and IAG2 containing 10.10.10.20:443.

(23)

We need to modify both these pools to enable the SSL re-encryption before the traffic is sent to the IAG backend node.

(24)

Now that we have created our two pools, we will now create the RuleBuilder rule that will examine the User-Agent and use this value to direct the traffic to the relevant IAG backend server.

(25)

We also create another rule called “user-agent-IAG2” but this time we set the User-Agent to contain Opera and the choose pool to be “IAG2”.

(26)

Our “Whale HTTPS Server” will now use multiple pools. Although the default pool is set for “Whale HTTPS Decrypt”, the RuleBuilder rules will run first and so if the browser is MSIE or Opera the appropriate pool (IAG1 or IAG2) will be used instead of “Whale HTTPS Decrypt”.

(27)

If Firefox is used then none of the RuleBuilder rules will run and so “Whale HTTPS Decrypt” will be used. We need to apply Session Persistence to “Whale HTTPS Decrypt” so that the traffic will stick to an IAG backend node. As pool IAG1 and IAG2 only contain 1 IAG backend node, then we don’t need to set Session Persistence on these pools. However if we were to add more IAG backend nodes and split them amongst the two pools we would need to apply Session Persistence to make sure that the traffic sticks to the correct IAG backend node.

Firstly, we create the Session Persistence class. In this case we are using “Transparent Session Affinity”. In this persistence class, ZXTM adds a cookie to the response and uses this cookie to direct traffic to the correct IAG backend node. IAG server itself uses ASP session cookies so you could also use “Monitor Application Cookies”.

(28)

Now we are ready to test our RuleBuilder rules to make sure they are working as they should and sending traffic to the correct IAG backend node depending on whether the browser is MSIE or Opera. In our case, MSIE browser should be using 10.10.10.10:443 and Opera should be using 10.10.10.20:433.

Looking at the access logs again, we can see that the correct IAG backend node is receiving the traffic:

10.10.10.10:443 10.10.10.10:443 Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1)

- 10.10.10.20:443 - Opera/9.24 (Windows NT 5.1; U; en)

10.10.10.20:443 10.10.10.20:443 - Opera/9.24 (Windows NT 5.1; U; en) 10.10.10.20:443 10.10.10.20:443 - Opera/9.24 (Windows NT 5.1; U; en) - 10.10.10.20:443 - Opera/9.24 (Windows NT 5.1; U; en)

- 10.10.10.20:443 - Opera/9.24 (Windows NT 5.1; U; en) - 10.10.10.20:443 - Opera/9.24 (Windows NT 5.1; U; en)

(29)

- 10.10.10.20:443 - Opera/9.24 (Windows NT 5.1; U; en) - 10.10.10.20:443 - Opera/9.24 (Windows NT 5.1; U; en)

10.10.10.20:443 10.10.10.20:443 - Opera/9.24 (Windows NT 5.1; U; en)

So both our TrafficScript and RuleBuilder rules direct traffic correctly. Again, an important point to note is that Session Persistence is required when you have more than one IAG backend node in a pool. Otherwise you can use multiple pools with one IAG backend node and a rule to direct the traffic according to the decision making process you wish to use.

Summary

ZXTM can be used to both load balance and provide fault tolerance for your IAG servers. The high availability features of ZXTM can ensure that a user can always connect to an IAG server despite the loss of one or more of your IAG servers. The load balancing algorithms of ZXTM can be used to distribute traffic amongst the IAG servers on a simple round robin basis to a more complicated “perceptive” algorithm which takes into account the performance of each IAG backend node. A range of session persistence methods ensures that a connection sticks to a given IAG node while the use of SSL decryption by ZXTM offers a more powerful and customised way to make backend node choices.

(30)

Copyright

Trademarks

Zeus Technology, the Zeus logo, Zeus Web Server, Zeus Load Balancer, Zeus Extensible Traffic Manager, ZXTM and associated logos and abbreviations, TrafficScript, TrafficCluster and RuleBuilder are trademarks of Zeus Technology Limited. Other trademarks may be owned by third parties.

Contact Information

If you would like to learn more about any of the topics covered by this white paper, please feel free to contact us for more information. You can reach us in a variety of ways:

By Email

For general enquiries: [email protected] For commercial and technical enquiries: [email protected] For reseller information: [email protected] For press and public relations information: [email protected]

By Telephone

Zeus Technology UK: +44 (0)1223 525000

Zeus Technology US: +1 650 965 4627

Fax: +44 (0)1223 525100

By Post or in Person

Zeus Technology Limited Zeus Technology The Jeffreys Building 1955 Landings Drive

Cowley Road Mountain View

Cambridge CB4 0WS CA 94043

United Kingdom United States

www.zeus.com

Our web site contains a wealth of information on our products, services and solutions, as well as customer case studies and press information. For more information, please visit http://www.zeus.com/.

(31)

knowledgehub.zeus.com

The ZXTM KnowledgeHub is a key resource for developers and system administrators wishing to learn about ZXTM and Zeus’ Traffic Management solutions. It is located at http://knowledgehub.zeus.com/.

Load balancing Microsoft IAG