Question: Does NetScalers XML Broker health monitoring and load balancing protect intra-zone IMA communication?
Protection for Web Interface
When a user launches web applications from a XenApp Web Interface (WI) server, the WI connects to a member server in order to retrieve a list of available applications and to find the least loaded server for the user to use. It uses an XML Broker query for this communication. Getting this information is critical for application launch success and if the member server has a process failure of the XML or IMA service, this communication will fail.
Since the WI can be given a list of member servers to try to reach (and it can move to other servers if no response is received) a member server process failure may result in just a delayed WI response as it tries to communication with another member server. Which could take several seconds or minutes depending on how many servers are afflicted. And in the worst cases, where just the IMA service fails, a null list of information is returned to WI and the application launch process fails completely. This is the dreaded "black hole" which is nasty because it's so hard to diagnose. Users may experience any of 3 different symptoms, most of which make administrators think they're dealing with a permissions issue.
If the “black hole” occurs on the first server (or the only server listed in the WI’s list of Brokers) the application availability will be 0.0%. This problem gets particularly nasty when it occurs on another server and results in intermittent failures which can be almost impossible to diagnose. Or when a process monitor is constantly restarting the IMA service. (out of desperation, administrators who experience this tend to resort to rebooting every server in the zone) These are the reasons we need the NetScaler; which acts as a 3rd party manager (“traffic cop”) of this communication. By using the built-in XenApp monitors, the NetScaler can detect XML and IMA process failures, alert administrators, and automatically direct the WI servers to working member servers.
Protection for the Zone Data Collector
The XenApp server which receives the WI’s request will contact the Zone Data Collector (ZDC). It does this because only the ZDC knows which member servers in the zone has the least resource utilization and can support the next application launch request. This intra-zone communication also needs to be protected, and it is, through heartbeats and scheduled events which occur on the ZDC. If a ZDC does not receive an IMA based update from a member server every 1 minute (tunable) it becomes concerned and sends a ping (IMAPing) to the member server in question. Should the ping fail, the “lost” member server will not be ping’d again for 5 minutes (tunable) and will not be included in the load distribution response sent to the XenApp server that posed the question on behalf of the WI. Likewise, the ZDC’s communication itself is protected though an election process which operates based on the same mechanism as the member server reporting.
Both the NetScaler and ZDC health monitoring are needed to achieve five nines (99.999%) uptime for XenApp delivery. With these monitors in place, XML and IMA process failures can be detected, alerted on, and automatically healed around within 60 seconds.
Microsoft Virtualization, Citrix, XENServer, Storage, iscsi, Exchange, Virtual Desktops, XENDesktop, APPSense, Netscaler, Virtual Storage, VM, Unified Comminications, Cisco, Server Virtualization, Thin client, Server Based Computing, SBC, Application Delivery controllers, System Center, SCCM, SCVMM, SCOM, VMware, VSphere, Virtual Storage, Cloud Computing, Provisioning Server, Hypervisor, Client Hypervisor.