Currently, the ThinLinc installer allows all roles to be installed on a single server, or the deployment to be split between Master/Broker servers and VDAs. Are there any plans to add an option for dedicated Web Access servers, allowing the Master servers to focus on session brokering, licensing and core ThinLinc services?
For comparison, a typical Citrix CVAD deployment separates the main roles:
Netscaler ADCs gateways for secure remote access (reverse proxy/VPN,LB)
StoreFront provides user access (internal/external - web and native client)
Delivery Controllers handle brokering
Director provides monitoring and session management
There is no dedicated Web Access role today, and it is worth explaining why, because it is not simply a missing option in the installer.
Web Access is not a single service that sits in front of the cluster. It is split across the nodes and each half needs local access to something:
On the master, tlwebaccess serves the login page and authenticates the user by talking to the vsmserver process on the same machine. A node with no vsmserver running cannot log anyone in.
Once the master has picked an agent, the browser is redirected to tlwebaccess on that agent. That instance proxies the websocket straight into the Xvnc process for the session, which is by definition local to the agent.
That is why the documentation says tlwebaccess must run on every machine in a cluster. Moving it to a separate tier would mean redesigning both halves, not just repackaging them.
What you can build today gets reasonably close to the CVAD layout:
A reverse proxy in front of the cluster covers the Netscaler/StoreFront role: single public entry point, TLS termination, and routing of both the login page and the per-agent redirects. This is documented, including a pattern where a main proxy handles login and hands clients off to per-region proxies for the agents, which is useful if you do not want all session traffic funnelled through one box: Reverse proxy — ThinLinc Administrator's Guide and Distributed agents — ThinLinc Administrator's Guide. Set /webaccess/trusted_proxies so the real client IPs are preserved.
The Delivery Controller separation you describe already exists. A master only hosts sessions because it lists itself (127.0.0.1) in a subcluster’s agent list. Remove it there and leave vsmagent off, and the master does brokering, load balancing and licensing only, plus serving the login page. See Cluster installation — ThinLinc Administrator's Guide
For redundancy at the master tier, there is a two-node HA configuration.
ThinLinc Web Administration is the closest thing to Director: service status, session management and cluster configuration, served from the master.
I cannot point at a committed plan or a timeline for a separate Web Access role. What I can say is that the web client’s architecture is under internal discussion, in the direction of a more JavaScript-centric design where the handoff to the agent happens in the client rather than as a browser redirect between two servers. Nothing is scheduled, but the arguments for that change keep accumulating, and it would clean up exactly the coupling that makes the current split awkward. It would not by itself turn Web Access into a standalone tier, since the session traffic still has to terminate on the agent holding the Xvnc process, but it is the kind of groundwork that a clearer role separation would need.
Knowing what you are actually after would help when this is discussed internally: taking web traffic load off the master, placing the web front-end in a DMZ away from the brokers, or scaling the web front-end independently of brokering.
Thanks for the detailed explanation. It helps clarify why the Web Access role is currently integrated with the Master/Broker role and why it can’t simply be deployed as a separate tier.
My thoughts around dedicated Web Access servers were more along the lines of the separation between Citrix CVAD Delivery Controllers and StoreFront:
Improve scalability of the Web Access and Master/Broker tiers
Reduce the load on the Master servers, allowing them to focus primarily on session brokering, desktop/session assignment, licensing, administration and core services.
Provide a dedicated user access layer for the web portal, while the actual session traffic continues to terminate at the VDA.
Reduce the attack surface of the brokers.
Personally, I wouldn’t put either StoreFront or ThinLinc Web Access directly in a DMZ. I’d normally put a reverse proxy or NS ADC/gateway layer in DMZ, with the Web portal servers remaining on the internal network.
So, from my viewpoint, the main requirement is to improve broker and web server scalability and reduce the attack surface of the brokers.