Opting to employ several servers for high availability is a prudent step in most modern organizations, and thus, UAG includes built in support for arrays and NLB. Some organizations may still prefer using third party hardware, like F5 BigIP or Citrix Netscaler. The common scenario for load balancing would be to have several UAG servers running an identical configuration, and using a load balancer on the "external" side to distribute the load between the servers. Another scenario is when an organization has multiple internal servers, like a SharePoint server farm, and uses a Load-Balancer between it and UAG. Naturally, some organizations have both.
The most important consideration in a high availability scenario is the routing. With multiple virtual and physical IP addresses, the routing on all devices needs to be carefully planned, so that the data will have a clear path all the way from the client, through UAG, to the backend server and back. Stickiness also needs to be considered, as noted before (see Considerations for placing the server).
Another consideration for high availability is the keep-alive mechanism. Load balancers need to discern if the servers they are balancing are alive, and they usually do so by initiating some kind of contact with them. A popular way is by issuing a simple ICMP packet, like PING, but it's usually also possible to configure them to send an HTTP request to the server, or a TCP-SYN request. This needs to be planned carefully, so as to not have the keep-alive check impact the servers' performance, and also so that false-positives will not have bad consequences. We've seen many organizations configure their keep-alive to perform a check every second, which is a significant overkill, and caused the servers' logs to cycle so fast that the administrator was unable to track down real errors.
Another aspect of high availability is session failover, which, unfortunately, is not a part of UAGs functionality. NLB or third party load balancing will provide clients with a response even if one member server comes down, but the session management mechanism of UAG will not allow users with existing sessions to be moved over to another server. If a fail occurs, all users who are connected to the failed server will be redirected, upon their next request, to another array member, but they will be required to login again at that point. If they had SSTP, NC, RDP or SSL-VPN apps running, these sessions will be lost and have to be re-established as well. Some application-level protocols are designed to do this automatically, like RDP, but UAG will not do so on its own.
