Hello,
I am currently working on making our internal VMware Horizon setup more redundant with the use of HAProxy, Keepalived, and 2 internal connection servers. I am currently able to connect to my horizon VDI with the web browser and use the machine. The issue is when I disconnect the network card from the connection server I am connected to I am unable to immediately reconnect to my VDI. I get 2 errors that I have been disconnected and that I am unable to reconnect. The solution is to refresh and then sign back in. Ideally I would be able to take down a server and have clients automatically connect to the backup server and not have to resign in and not even notice downtime. Here is the configuration of HAproxy, Logs of me disconnect the network interface of INTCONNECT2 and connecting to the backup of INTCONNECT1, and what I see on the web browser. Is there a way to make the fail over seamless?
I don’t see how you’d ever be able to seamlessly failover from one RDP server to another. Even if those RDP servers would synchronize state (which I assume they don’t), you’d still need to have synchronization with the client.
I don’t think any of this is possible with RDP.
The connection servers that I am connecting to are called replication servers and they are exact copies of each other made for fail over. I am using VMware’s own remote desktop protocol called VMware Blast to access these servers. I asked on the VMware forums as well and I will post if I figure out how to do it.
Exact copies of what? storage or storage and RAM? Even if it storage and ram are replicated, it doesn’t mean the an application session can simply be resumed on another server. RAM is likely to change faster than you can replicate even on a 100 gbit/s network … and the client can’t know what has been replicated to the new server and what hasn’t. And then we are not even talking about the TCP connection and the actual authentication yet.
I believe what you expect is pretty much impossible and it certainly has a lot more to do with your VMware deployment than it has to do with haproxy, which is acting as a simple TCP proxy here.
It’s impossible to keep a TCP connection on the frontend open, while the backend TCP connection fails over to a backup server, unless haproxy understands the application protocol (which is only the case with HTTP), and that application protocol supports transaction on different servers.
