At first glance... and in simple environments, this is a really cool technology. Imagine only paying a single license fee for (most) programs per-server... and avoid the constant upgrading of workstations... and using your budget to invest in your servers.
In a single-server setup... this works pretty well... baring a few crazy things... which is outside the scope of this particular post... but I promise to bring up sometime. That information is pretty useful when considering Microsoft's Remote Desktop Services... (previously known as Terminal Services).
I'm sure there are many other admins out there who are playing the "Why not use Citrix" card. Well... If we all had bottomless budgets to play with... I would loved to have considered the possibility. Citrix is simply crazy expensive to implement. The majority of the features of Citrix... Microsoft offers in the base setup for Remote Desktop. Everything that citrix offers... requires that you *first* purchase Microsoft's Licenses not only for the OS, but additionally for each client. Strange... isn't it. Admittedly, Citrix has done a lot of additional work for you to make some things easier to setup, configure and deploy.
So... what is this whole terminal services thingie anyway? Long story short... You probably have already seen how users can remotely control your computer... or even able to connect to your home computer through the internet... etc... what if you had 1 computer... that can have multiple "sessions" and basically act like multiple remote computers... on 1 server... configured once. Terminal Services is exactly that. Install Office... Install company programs... etc... on one server... and have multiple users log into it & run whatever programs.
Now for the twist. RemoteApp... (which is only available in Windows Server 2008 and above) does some spiffy "jedi-mind-tricks" and doesn't give you a remote desktop... but instead simply draws the individual programs on YOUR desktop. The program is still running on the remote server... only being displayed locally. Spiffy huh?
So... Lets start a pretty diagram of what's going on...
Seems simple? Well in a small office, this might work... but once you get going in a slightly larger office where you need to consider more than one server, is where you start running into problems. On paper, you simply add another server... riight??? ... reality becomes quite a bit more complicated.
So... what happens behind the scenes? ... according to Microsoft... to do it "correctly" ... you actually need 6 servers... You need 2 gateway servers, 2 broker servers and finally 2 host servers. So, your little project quickly skyrocketed to a HUGE undertaking... which gets rather expensive. Hardware and software both. Seriously? 2x the performance... for 6x the cost? Does that really seem realistic? Of course not.
Well, my goal is to simply expand the operation to 2 servers... to get roughly twice the scalability... and a bit of redundancy. (there's some overhead, so it's not exactly 2x the growth... as the servers will be doing some additional tasks...) We'll still make use of some of the Microsoft model... but put the work on the servers.
First... What does each role do?
1. Gateways:
This is more of a layer of security than anything... The stock security in the RDP protocol is almost non-existent. It's enough to keep honest people out... but won't do much beyond that. The gateway service wraps up the RDP protocol through https... which is significantly more secure. (but can also add some additional headaches) Plus, you can add a nice web portal for users to login and run their applications without having to manually install a million .rdp files or shortcuts to everything.
2. Connection Brokers:
Since we're having multiple servers... if we accidentally get disconnected... what's the chance we will get re-connected to the same server? 50/50. Which means you'll have a 99.99999% chance of getting phone calls... I hate those kinds of phone calls. So... We have connection brokers that help match a disconnected session with the correct user. The connection broker in 2008R2 can also act as a load-balancer... which helps to spread the workload evenly between the session hosts.
3. Session Hosts:
This is where the programs are actually run. All the horsepower needs to be here. Not much else to say.
Well... even if I had 6 servers... I probably still wouldn't divvy them up that way. The gateway service & connection broker service rarely tick at 1% cpu usage & not even enough memory to justify a dedicated server to it. I've seen it suggested that the connection brokers should be thrown onto the domain controllers... but I kinda don't like to put a bunch of unrelated stuff on my domain controller. (yes, I know most DCs sit idle for the most part... it's still not my preference to do that.)
So... my solution... is to-be-continued. It's 12:18AM... and I gotta get to work in the morning.
No comments:
Post a Comment