It is possible to overdo HA to the point of introducing fragility to a system.
Too many moving pieces for not enough benefit. *ASB **http://XeeMe.com/AndrewBaker* <http://xeeme.com/AndrewBaker>* **Providing Virtual CIO Services (IT Operations & Information Security) for the SMB market…*** On Thu, Mar 21, 2013 at 4:42 PM, Ken Cornetet <[email protected]>wrote: > With VMWare HA, your web server and broker will only be down for a minute > or two - even if one physical host crashes. > > -----Original Message----- > From: Michael Leone [mailto:[email protected]] > Sent: Thursday, March 21, 2013 4:18 PM > To: NT System Admin Issues > Subject: Re: Advice on setting up a Win2012 RDS environment - Progress! > > On Thu, Mar 21, 2013 at 3:59 PM, Ken Cornetet <[email protected]> > wrote: > > The web server and broker are out of the picture after the RDP client > session is established with the session host. > > > > If something goes wrong with a session host, the users have lost their > sessions anyway - no way to prevent that. > > Right. Another reason why we will have 3-4 session hosts (also the vendor > recommends approx 35 sessions per host, of their published app, and I will > have somewhere around 100 users total possible users, altho probably not > that many concurrently). > > But if the session hosts stay up and available, without the connection > broker and web server, no one who doesn't already have an active connected > session can connect. That would be the reason for multiple brokers/web > servers. > (because even if we push an RDP to the client desktops, it points to a > connection broker, right, which then re-directs to a session host, as you > pointed out? So even clicking on the RDP link would fail, if the connect > broker wasn't there) > > > > > -----Original Message----- > > From: Michael Leone [mailto:[email protected]] > > Sent: Thursday, March 21, 2013 3:19 PM > > To: NT System Admin Issues > > Subject: Re: Advice on setting up a Win2012 RDS environment - Progress! > > > > On Thu, Mar 21, 2013 at 2:26 PM, Ken Cornetet <[email protected]> > wrote: > >> I don't think you can have two connection brokers without complicating > things (clustering and SQL server involved). > >> > >> If you have ESX clustering, you have your redundancy covered. No need > for two web servers (or two brokers). ESX does HA with fewer headaches than > any other way - use it. > > > > Yes, ESXi provides for HA, but with only 1 web server (or connection > broker), what happens if something goes wrong with that machine? If I have > to restart it for whatever reason (say it locks up, errors out, whatever), > all users get kicked off the published app, don't they?. > > That's what I am trying to avoid. Would that not be best practice? > > Avoid a single point of failure at the various points - broker, web > server, session host? > > > >> Here's the general traffic flow (I think...): > >> > >> 1. Client hits web server. > >> 2. Web server shows available apps > >> 3. User clicks on app > >> 4. Web server downloads .RDP file for app. The .RDP file points to the > broker as the server address. > >> 5. User's RDP app attempts to launch app from broker. > >> 6. The broker sends the client a RDP "redirect" to the appropriate > session host. > >> 7. The user's RDP then opens a connection to the session host and > launches the app. > >> > >> It has been a while, but I think this is how it worked in 2008 R2 and > RDP versions up through 7. I've just started looking at 2012. I think RDP > version 8 changes this up a bit. > > > > Thanks > > > > So the web server only really is a hand off to connection broker. Once > the client gets and opens the RDP file, the web server becomes unimportant > to the situation. So I guess having multiple web servers would be just for > redundancy - if the web server goes down, currently connected users > shouldn't even notice anything. But it means new users wouldn't be able to > connect, until the web server becomes available again. > > > > Similarly for connection brokers, if I understand correctly. I'm not > sure how multiple connection brokers would coordinate between themselves, > or load balance. > > > > > >> > >> -----Original Message----- > >> From: Michael Leone [mailto:[email protected]] > >> Sent: Thursday, March 21, 2013 2:04 PM > >> To: NT System Admin Issues > >> Subject: Re: Advice on setting up a Win2012 RDS environment - Progress! > >> > >> On Thu, Mar 21, 2013 at 1:24 PM, Ken Cornetet <[email protected]> > wrote: > >>> For traffic handling, you don't need two web servers for 4 session > hosts. You don't need 2 web servers for 40 session hosts. > >> > >> Well, it's more for redundancy, than actual traffic balancing. > >> Speaking of which ... does that mean for my situation I would want 2 > connection brokers, rather than 2 web servers? > >> > >> Am I correct in assuming that the user actually hits the connection > broker, which then passes to the web server (since we would want our users > to be able to access via web browser), which then communicates back and > forth with the session host? So I would want 2 connection brokers (which > would be tied to my Cisco ACE appliance), so that if one goes down, > complete access to the application itself does not. > >> Similarly, I would want 2 web servers, and then the 3-4 session hosts > >> (altho only the connection brokers would be connected to the ACE > >> appliance) > >> > >> (also: in my case, the application being published is really just a > front end itself; it communicates with SQL servers for it's data. > >> There is no data in the application itself) > >> > >>> For HA, I presume you are using an ESX cluster. > >> > >> Yep. ESXi 5.0 Update 2 cluster (hopefully soon be 5.1). > >> > >>> > >>> > >>> -----Original Message----- > >>> From: Michael Leone [mailto:[email protected]] > >>> Sent: Thursday, March 21, 2013 1:07 PM > >>> To: NT System Admin Issues > >>> Subject: Re: Advice on setting up a Win2012 RDS environment - Progress! > >>> > >>> On Wed, Mar 20, 2013 at 7:53 PM, James Hill <[email protected]> wrote: > >>>> Get a cert from a public CA. Far less hassle and they are very > inexpensive. > >>> > >>> These are internals apps, so they won't be accessed by the public, or > over a public Internet (well, perhaps over VPN). And being a government > agency, we can get certs for free from another agency. > >>> > >>>> Why do you want to separate the web front end? > >>> > >>> Load balancing by our hardware Cisco ACE appliance. Also it then > enables use to send the session to any available session host. > >>> Separating out the web front end from the back end RDSH servers (aka > the server farm) is also the current configuration we have with our Citrix > environment, and is I believe the recommended design for something like > this. (I am told). > >>> > >>> What we want, or will have, is 2 web front ends and 3-4 back end > session hosts. > >>> > >>>> > >>>> James. > >>>> > >>>> -----Original Message----- > >>>> From: Michael Leone [mailto:[email protected]] > >>>> Sent: Thursday, 21 March 2013 4:40 AM > >>>> To: NT System Admin Issues > >>>> Subject: Re: Advice on setting up a Win2012 RDS environment - > Progress! > >>>> > >>>> SO I am making progress! I had already installed the RDS as a role, > >>>> but that didn't configure the deployment. So I went to Server > >>>> Manager, clicked on RDS, and clicked on Deploy. It then went into > >>>> what seemed like an install of RDS as a service (which had failed > >>>> before). This time, however, the deploy step went through without > >>>> error. I rebooted at the end, and after I logged back in, I was > >>>> able to install an app (Notepad++), and then I was able to add it > >>>> to a Quick Session Collection, publish it as a RemoteApp, and I was > able to access it remotely. > >>>> > >>>> w00t! > >>>> > >>>> Definite progress. So now I need to make my own collection, add an > >>>> app to it. Then investigate how to use a separate web server front > >>>> end for it (to separate the RDS hosts from the web access). > >>>> > >>>> And probably give it our self-signed internal certificate, to stop > >>>> it complaining about untrusted publishers of the app. > >>>> > >>>> So I am definitely further along than I was. > >>>> > >>>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > >>>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > >>>> > >>>> --- > >>>> To manage subscriptions click here: > >>>> http://lyris.sunbelt-software.com/read/my_forums/ > >>>> or send an email to [email protected] > >>>> with the body: unsubscribe ntsysadmin > >>>> > >>>> > >>>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > >>>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > >>>> > >>>> --- > >>>> To manage subscriptions click here: > >>>> http://lyris.sunbelt-software.com/read/my_forums/ > >>>> or send an email to [email protected] > >>>> with the body: unsubscribe ntsysadmin > >>> > >>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > >>> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > >>> > >>> --- > >>> To manage subscriptions click here: > >>> http://lyris.sunbelt-software.com/read/my_forums/ > >>> or send an email to [email protected] > >>> with the body: unsubscribe ntsysadmin > >>> > >>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > >>> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > >>> > >>> --- > >>> To manage subscriptions click here: > >>> http://lyris.sunbelt-software.com/read/my_forums/ > >>> or send an email to [email protected] > >>> with the body: unsubscribe ntsysadmin > >>> > >> > >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > >> > >> --- > >> To manage subscriptions click here: > >> http://lyris.sunbelt-software.com/read/my_forums/ > >> or send an email to [email protected] > >> with the body: unsubscribe ntsysadmin > >> > >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > >> > >> --- > >> To manage subscriptions click here: > >> http://lyris.sunbelt-software.com/read/my_forums/ > >> or send an email to [email protected] > >> with the body: unsubscribe ntsysadmin > >> > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > --- > > To manage subscriptions click here: > > http://lyris.sunbelt-software.com/read/my_forums/ > > or send an email to [email protected] > > with the body: unsubscribe ntsysadmin > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > --- > > To manage subscriptions click here: > > http://lyris.sunbelt-software.com/read/my_forums/ > > or send an email to [email protected] > > with the body: unsubscribe ntsysadmin > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ < > http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
