I am having a bit of trouble understanding how to configure a Standalone Proxy Node and have it do it's job properly.
Do the users need to go directly to the Proxy Node and then it's load balanced to direct traffic to the Hub? Or do users go directly to the Hub and there are virtual proxies that tie the two together? Or I may be missing the boat all together on this.
Refer to this write-up for an explainer on proxies vs. virtual proxies.
A Virtual Proxy is load balanced to Engines which deliver applications. So users will access the Standalone Proxy using the configured Virtual Proxies then open apps on the Engine(s) which are load balanced.
What is the purpose of a standalone proxy? Generally we see Proxies and Engines configured on the same node. So what is the architectural reason for the standalone installation of the Proxy?
Thanks Levi. I think the theory was to isolate the authentication to it's own node and make a central point of entry for what will be multiple engine nodes. But based on what you've said above and what i've read elsewhere that may not be the best idea. If all the proxy service is doing is authentication then maybe it's not needed.
Initially i was comparing the proxy node to a hardware load balancer like we have in QlikView. We have 4 QVS servers with a F5 load balanced link that directs the traffic across those four. But it sounds like a QS Proxy node would not replace an F5. we would still need an F5 to load balance across the multiple engine nodes and also have the proxy service running on each engine node. does that sound more common?