I'm currently in the process of planning any required changes to an RDS infrastructure to cater for an upcoming increase in the number of users due to company expansion.
Currently, the system only has a single RDS Session Host server. The upcoming expansion caused me to wonder what the factors are that influence when you would make the decision to switch to a model with multiple session hosts.
One particular question that I'm struggling with: if you have the ability to easily scale up the existing host rather than deploying another, does it usually make sense to do that and avoid switching to a multiple host model until absolutely necessary? Bearing in mind the added maintenance and complexity that having more than one session host brings, it seemed quite a pertinent question to which I'm not sure I have a solid answer to.
I'll set out my current thinking on the competing factors. I'd appreciate other people's thoughts on these and whether there are other factors that are also important.
Having multiple session hosts introduces a level of redundancy, particularly if you run them with enough headroom to pick up the slack in the event you experience downtime with one of the hosts. However, you must ensure all session hosts have the same configuration. This requires extra work and introduces the possibility of differences between the hosts developing over time. Although I've not done it myself yet, I can appreciate how these concerns can be mostly address by using things like automation, centralised management and configuration control, but the skill level required is higher, and you have to put the initial effort in to implement the tools and processes. You also have the added complexity of load balancing between the hosts (using a connection broker).
Scaling up a single host keeps the complexity down, which I'm a big fan of whenever possible/sensible. You only have a single host to maintain. On the face of it, that makes me think that it's preferable to scale up an existing host as much as possible until redundancy becomes a serious concern. I have a feeling it isn't quite that simple though. Can anyone else offer their thoughts/experience?
To put some constraints on this, my particular situation involves using Windows Server 2012 R2, with the session hosts virtualised using Hyper-V. In this particular scenario, licensing isn't a major concern.
In my opinion, the biggest downside to keeping only a single RDS host is that all of your users are impacted when you have to bring it down for maintenance/patching in addition to any unexpected downtime.
Splitting the load between multiple servers allows you to "drain" stop the service on a server that you need to do maintenance on which effectively eliminates user downtime for all planned maintenance (which also allows you to do maintenance during business hours). And in the event of unexpected downtime, only the portion of users using the downed server would be affected; and only long enough to reconnect to another server in the farm.
If the RDS farm requires any sort of uptime guarantee, scale out. Install the connection broker role on a separate VM, (HA cluster if needed).
The biggest concern in RDS is resource sharing. If one user consumes too much resources, it affects everyone on that server. Scale-Out mitigates this.
I also recommend N+1 (or greater) provisioning of servers for capacity planning. This allows headroom for maintenance while not compromising the health of the farm.
Anecdote:
I ran a 3-node farm serving Great Plains to ~90 concurrent users. I want to say each session host was 8-core, 16GB RAM (Nimble SAN, IOPS were no concern) and offloaded user profiles. This farm could run degraded on 2 hosts with little impact, and the business could function in only one host.
It is up to you and your business to determine what level of service is needed and what cost is acceptable.
If you can get configuration management sorted out (PowerShell DSC or similar), having multiple nodes is an advantage rather than additional complexity.