My personal thoughts.....
How is performance?
Between Session Assurance in R12.52 and R12.6 / R12.7; the performance in the feature itself is improved quite drastically. The reason is the light weight solution minus the Risk Manager is no longer running alongside the Policy Server. Also good improvements in CA Directory as a Session Store functional logic.
Between a none Session Assurance setup and enabling Session Assurance, there will be some added latencies. This is mainly due to the fact we are introducing an additional 302 redirect to the Session Assurance App on CA Access Gateway and also addition of Session Store. However this is not a valid performance comparison use case i.e. comparing non SA setup performance and SA setup performance.
How did you handle load balancing? With Sticky Sessions?
Mark has explained this beautifully in the blog reply and I do agree with the thoughts. However I do carry a certain level of caution if we do go down the route of sticky session it needs to tested appropriately. The name sticky is because it really sticks, therefore we shouldn't be in a scenario wherein one CA Access Gateway is getting blasted away by all User request because of stickiness. What cautions me is CA Access Gateway not only serves the Session Assurance content but also a variety of other functions (WAOP / AuthAz WebServices / Proxy functions). If the same CA Access Gateway is being used for all these functions, then I'll be concerned on enabling Sticky Sessions unless we could segregate sticky based on VH / functions.
Alternatively, I would probably categorize clusters of CA Access Gateway based on Job functions. E.g. I'd keep a cluster primarily for Session Assurance, AuthAz WebServices, WAOP (In a way this is similar to the concept of Centralized Authentication Server which does purely the login / Auth) and I'd keep another cluster for Proxy functions. Though this is primary categorization, I'd also make sure if & when needed, I can added capacity by routing traffic across cluster for temporary surges. To be able to do this, even though there is categorization, we need to ensure we build all CA Access Gateways across the cluster at the same configuration level.
How easy is it to remove on SA server from rotation for maintenance? Does that cause user interruptions?
If we have a load balancer in front of a pool of CA Access Gateway server, taking a single CA Access Gateway outside the Load Balancer pool for maintenance should have no impact. The load balancer has to be smart to re-route the traffic to the active CA Access Gateway servers. This is same rule for anything that is served off the CA Access Gateway (e.g. WAOP). What we define in the Session Assurance end point configuration on the Policy Server is a end point URL. The Web Server name can also be the Load Balancer VIP FQDN.
What did you use as an accurate Health Check?
You can use keep alives. There are various tech-notes on how to deploy pages on CA Access Gateway.