High Availability for IAG

After four hours on the train today, I spent a fair chunk of today configuring a pair of Celestix Load Balancers for an IAG deployment.

The only way to create IAG in a highly available configuration, is to put the IAG solution behind a front end load balancer. A common question I get asked is why do I recommend a pair of load balancers... well why would specify a solution with multiple application servers, only to place them behind a single load balancer and risk moving your single of failure from the application server, to the load balancing solution.

There are some simple instructions on how to configure the Celestix Load Balancers (CLB) and well documented in the manuals, but here are some headline points when configuring the solution for Direct Server Return (DSR), where the load balancer coming into the IAG solution, but outbound (as the name suggests) the IAG solution will go directly back to the client, rather than through the load balancer.

1. Configure the IAG external IP address to the be the virtual server IP address
2. Ensure DSR is selected in the advanced settings
3. Under the Healthcheck option for the target, ensure PING is off, but check TCPOpen ais enabled for 443,2,10
4. Ensure all IP addresses are unique, including gateways, servers, engines, etc.
5. Create an ISA rule to allow access from the CLB range to the Local Host, for port 443.
6. Create loopback adapters for the WSA appliance, ensuring that there is no gateway, and within advanced ssettings, the Interface Metric is set to 254
7. Ensure VRRP is enable, where both appliances have the same VRID, ensure the Master has a priority of 1 and the backup of 254, on a different network
8. Ensure the local host files that the server name points to the VIP

I had a pretty unique situation today, where four portals were configured on two IAG appliances, with virtual IPs and load balancers.

We ended up using 14 external IP addresses, VIP for each portal (4 external IPs), an external IP for each portal on each appliance (8 external IPs), and a unique IP for each load balancer (2 external IPs). It's very rare to have this many real IPs to play with, but the same principle would apply, if these IPs were internal ones behind a NAT'ing device, which would only have required 4 external IPs (one for each portal)

Ensure you understand the customer requirements and follow the manual.

Good luck with maaking your IAG solutions highly available! :)

HA deployment of IAG, using CLB

I spent the last couple of days in Wakefield, helping out a reseller with a high available deployment of Celestix WSA appliances using Celestix Load Balancers. Thanks for the company David!! :)

We started by configuring the Celestix Load Balancer (also known as CLB), after configuring the solution we were informed that the internet lines would be a number of weeks away, and we would not know whether the IPs that would be provided would be either external internet facing IP addresses, or NAT'd internal addresses. Why would this be an issue?

Well the customer wanted four IAG portals to be created, and as each portal would have to be created on both appliances. With the CLB in front of the IAG appliances, the way the IP addresses are presented will impact on how to deploy the solution.

If the addresses are external facing, we would need 12 external IP address, three for each portal (one on each appliance, and one for the virtual IP). If the addresses are NAT'd, then there would only be a need for one external address as the virtual IP on each portal.

We only configured one IAG appliance, and then backed up and restored the configuration on the second IAG appliance. Obviously the IP addressing needs to be changed, and the certificate information to be modified, but that was pretty much it.

We were deploying OWA, Sharepoint, Citrix, Mapped Drives, File Access, RDP and an IIS based intranet site.

From an authentication perspective, we looked at AD, AD & HOTPin, AD & Vasco Middleware (RADIUS) and just HOTPin. As expected the authentication methods were straight forward and I got a chance to use HOTPin a bit more. We configured HOTPin on the primary box, and had the secondary box referencing the primary box. You only have to allow port 10000 access between the appliances, and using local administration credentials is fine. The only pain was HOTPin not scanning AD correctly in subtrees, which means each OU would need to be defined when importing users, but I'll let Celestix know about that.

We also encoutered the Java issue, so that was resolved using the fix from one of my previous blog posts.

We can only complete the deployment, once we know how the IPs will be presented.... which will also impact the way we can balance the load (do we use DSR or not, VRRP, Loopback adapter configuration, etc, etc).... Let's see!