add additional features for gateway farms (multiple farms, more LB options)

Hi,

Devolutions Gateway Farms were loosely inspired from RD Gateway farms. The weight can be used to make it such that a given farm member receives more connection than others, which makes sense if you have farm members with more resources. If your farm members all mostly the same amount of resources, I would recommend just using the same weight value to distribute the load equally between them.

Now, for the architecture you described, Gateway1 is in Phoenix, and Gateway2 is in Tokyo, but they are both members of the same Gateway Farm. Of course, the weight doesn't make much sense, and this kind of load balancing is not really appropriate when you want to geo-distribute the load and pick the member which is the closest to you. More importantly, why would you want to create a farm with members that are distributed across the globe? Why not create a Gateway Farm closer to where the resources are located (Phoenix and Tokyo, separately)? Members of the same Gateway Farm are expected to be able to reach the same network resources - is it really the case here? Can the Gateway in Phoenix access the same internal network resources as the Gateway in Tokyo, and vice versa?

Even if it is the case, performance-wise, is there a problem with creating two separate farms, one for Phoenix, and one for Tokyo, and have all your users connect to Phoenix to access resources located in Phoenix, and connect to Tokyo to access resources in Tokyo?

We don't have a way to do geo-distributed load balancing with Devolutions Gateway right now. If you can elaborate on why this would be better than just deploying a Gateway Farm closer to where the network resources are located, we can think of something to improve this in the future.

Best regards,

We have a globally distributed IT support force. We have many global factories with local IT support, but also operate a corporate shared IT services for engineering support.
Our server environment is very segmented where you can only RDP/SSH to servers via jump hosts.

So right now, if an IT support engineer in Japan must first RDP to their local jump server onsite, then from there they RDP to the whatever server they need to connect to.
Our corporate IT staff are based in various locations in the US, and we have local US based jump servers which they would use to connect to that same server in Japan rather than using the Japan jump host.
It also protects the corporate IT staff to still be able to connect to the servers even if Japan's jump host is down for whatever reason.

If we followed your above suggestion where we have a farm in Japan, and a farm in the US .. and if the US user wants to connect to a server in Japan we would just have them use the Japan gateway farm, and the Japan farm is not working .. we don't want to lock our engineers out of still being able to connect to the server they need to support.

I think the best scenario would be the ability to have gateways part of multiple farms. And also allow a concept of 'gateway of last resort' such that regardless of how many gateways are in the farm, and regardless of the weights of each gateway, you can designate one as the last resort, such that only use that gateway if ALL other gateways in the farm are unavailable.

That way, we would create a Japan farm, and a Europe farm, etc. and then have a single gateway in our datacenter that can be in all the farm groups .. and only use that datacenter gateway if all the other gateways in a particular farm are down. That way, if we point an RDP connection to the Japan farm, it can have consistent settings on the RDP entry regardless of who connects to it (the Japan engineer or the US based engineer), but then if Japan's farm is having a problem, it will fallback to the US based gateway without us having to change any settings on the RDP entry in the vault.

Hi,

I think I'm close to understanding the full picture here, but some parts are still not clear to me. If we could have geo-distributed load balancing such that we'd automatically select a Devolutions Gateway server to the client, it would solve your issue. At the current time, the load balancing decision is taken server-side in DVLS, making it harder to factor in client-side factors.

If we followed your above suggestion where we have a farm in Japan, and a farm in the US .. and if the US user wants to connect to a server in Japan we would just have them use the Japan gateway farm, and the Japan farm is not working .. we don't want to lock our engineers out of still being able to connect to the server they need to support.

Here's what I'm having trouble with: in your scenario, the entire Gateway Farm in Japan could be down, but you would still have a way to connect through a different Gateway Farm located elsewhere? Does that mean you have some kind of site-to-site connectivity that makes it possible to have Japan inaccessible from the Internet, but accessible through a different network path you have between your different sites? Or are you worried that while the entire site may be reachable remotely, there's still a possibility of downtime for your Gateway Farm deployment, in a case where your other Gateway Farm deployments would still be able to reach the network resources in Japan?

I think the best scenario would be the ability to have gateways part of multiple farms. And also allow a concept of 'gateway of last resort' such that regardless of how many gateways are in the farm, and regardless of the weights of each gateway, you can designate one as the last resort, such that only use that gateway if ALL other gateways in the farm are unavailable.

Actually, we factor in the Gateway health into the load balancing decision, such that an unhealthy Gateway will be skipped entirely. If there is only one "healthy" Gateway standing in a Gateway Farm, it will receive all the new connections. This should give you the "Gateway of last resort" feature, with the exception that we don't have the ability to factor in the client geolocation into the load balancing decision right now.

I'm trying to think how we could potentially factor in the client geolocation in the load balancing decision. Normally this is done using DNS load balancing, but here the decision would still need to be taken server-side to include all of the other factors. Maybe we could push the DNS name to the client and have it resolve it to return the result back to the server. Is configuring geo-distributed DNS load balancing in front of your Gateway Farm something you can do? Otherwise I'll need to think of other ways we could find the Gateway closest to the client, maybe you have suggestions.

Best regards,

Here's what I'm having trouble with: in your scenario, the entire Gateway Farm in Japan could be down, but you would still have a way to connect through a different Gateway Farm located elsewhere? Does that mean you have some kind of site-to-site connectivity that makes it possible to have Japan inaccessible from the Internet, but accessible through a different network path you have between your different sites? Or are you worried that while the entire site may be reachable remotely, there's still a possibility of downtime for your Gateway Farm deployment, in a case where your other Gateway Farm deployments would still be able to reach the network resources in Japan?

The latter. The site's WAN circuits wouldn't be down, but the gateway farm might be. As such, without the US based farm, IT users would be unable to connect to any servers in Japan until the Japan farm was accessible again. This would delay troubleshooting and potentially cause more downtime while we focus on getting farms back up before we even jump into the servers we need to get into to correct whatever error is happening.
The likelihood of Japan's farm being down 100% is very low, but I must be able to answer that scenario in my presentation to implement this solution.

Actually, we factor in the Gateway health into the load balancing decision, such that an unhealthy Gateway will be skipped entirely. If there is only one "healthy" Gateway standing in a Gateway Farm, it will receive all the new connections. This should give you the "Gateway of last resort" feature, with the exception that we don't have the ability to factor in the client geolocation into the load balancing decision right now.

Not necessarily. Imagine 3 servers in a farm. 2 of them are in Japan, one of them is in the US. The 2 JP gateways might have a weight of 200, while the US gateway only has a weight of 50. Although the percentage chance the US gateway has an incoming connection might be low, it's not 0. It still participates in the connection rotation.

With a true gateway of last resort let's suppose we have a gateway with a weight of 0. This way, it will never accept connections unless all other gateways in the farm are unavailable. Perhaps a weight of 0 is already possible and would achieve the above?

With the ability to have a gateway be part of multiple farms, and a weight a 0 to act as a gateway of last resort, you wouldn't really need to factor in geolocation anymore. Even if you only had 2 gateways in a farm. 1 gateway in Japan, 1 in the US. You assign the JP gateway with a default weight of 100 and the US gateway with a weight of 0. You have basically accomplished the scenario from the first post.

And with the ability to have gateways in multiple farms, you can build another farm with 1 gateway in Europe, and the second gateway to be the same US based gateway that is in the first farm (also with a weight of 0). This way, even if the geographically closer gateway is down, you can always use that US based gateway to connect as a back up.

Having Gateway instances become members of multiple Gateway Farms at the same time would introduce new problems, namely competing load balancing algorithms. The load would be distributed according to two separate Farms, so it wouldn't really provide a reliable load distribution.

However, I just had a potentially much simpler solution: in your case, the US Gateway Farm should always be preferred to access resources in the US, and the Japan Gateway Farm should always be preferred to access resources in Japan. Only in the case where the US Gateway Farm is completely down should the Japan Gateway Farm be used to access resources in the US, and vice versa.

What if we could set an alternative Gateway Farm on a connection? Basically you would be able to set US Gateway Farm for US resources, but set the Japan Gateway Farm as a fallback if the one in the US is completely down. If DVLS cannot pick a Gateway in the first farm because they're all down, it would look into the fallback farm if there's one.

Would this be an acceptable solution?

That would absolutely be an acceptable solution. I think it would also help people that might want to have a failback gateway but don't want to set up farms.
You can point to either gateway primary, gateway secondary .. or gateway farm primary, gateway farm secondary.