RDS Farm using NLB on the Session Host Servers, combined with dedicated redirector and gateway?

I'm trying to modify our existing RDS Farm to proved more stability and reliability.  Specifically, I want a Session Host server to be able to drop out of the Farm at any time without new users noticing (crashes for example), or to be able to remove one as needed (for planned maintenance we try to drain the host servers in advance).  Our current implementation has problems when one of the host servers stop responding (rebooting or crash for example) where new sessions will not be able to log in, I think this is due to the use of DNS round robin for load balancing.  I think implementing NLB may be the answer (never used it before so learning as I go).  A contributing factor is that I cannot babysit the Farm every day, I want to be able to"set it and forget it", so to speak.  We typically have between 70 and 100 active sessions (call it 80 on average, with 80% being external users).

Users are configured with RDS Roaming profiles and folder redirection (all redirected folders are hosted by a file server, this keeps the roaming profiles smaller and faster to load).  All the servers have been implemented in Hyper-V, but that should not be significant (just mentioned as courtesy).

Using these articles as a reference:

1. http://technet.microsoft.com/en-us/library/cc771300%28WS.10%29.aspx
2. http://technet.microsoft.com/en-us/library/cc753891.aspx
3. http://technet.microsoft.com/en-us/library/dd834806.aspx
4. http://blogs.msdn.com/b/rds/archive/2009/03/24/improving-ts-gateway-availability-using-nlb.aspx

My proposal is to setup the Farm as follows:

1. public Farm name: farm1.public.com
2. internal Farm name: farm1.domain.local
3. several session host servers in NLB cluster [RDSHOST1.domain.local, RDSHOST2.domain.local, RDSHOST3.domain.local, RDSHOST4.domain.local][192.168.2.24-27] (using article 1 as reference for NLB config)
4. pair of gateway servers NLB'd (ref article 4), which will act as the user entry point (internal and external users) [RDSGW1.domain.local, RDSGW2.domain.local][192.168.1.22-23]
5. one session broker server (ref article 2; for session load balancing)[RDSBROKER.domain.local][192.168.1.21]
6. one dedicated RDS Session redirector (ref article 3) [RDSREDIR.domain.local][192.168.1.20]

Note: I showed the IP's in brackets along with the FQDN host names for reference, hope you can understand my short-hand.  192.168.1.22-23 means a range of two IP's (192.168.1.22 and 192.168.1.23).

If I read the articles correctly I'd create a DNS A record for the internal Farm name and point it at the RDS Redirector.  I would not create any A records for the session host servers.  The Session host servers would be part of a cluster sharing the same IP (say 192.168.1.30; on a dedicated port).  I'd also install the Farm SSL certificate (with the public and internal farm names) on the gateway servers, redirector and session hosts.  I could put the RDS license server role on the broker server too I guess.

If I understand it right this would give me redundancy on the gateway and session host servers (two and four respectively), and NLB should silently handle any single server that drops out unexpectedly (other than dropping the active sessions on the dropped session host server that is).

Questions:

Can anyone tell me if I've misunderstood anything significant to this point?  One of my concerns is that NLB is meant for "stateless" connections, but I must admit to not knowing whether RDS would be the exception.  I'm also concerned if this has the potential to turn into a management nightmare on me (for example: is it difficult to add session host servers down the road?).

What happens to user sessions that were on a server that "died", would the broker know the original host was down and redirect them to another right away?

The documentation I've read thus far seems to use DNS round robin for load balancing (easy to implement), but sometimes they say you can use NLB.  My concern is whether there is a time NLB cannot or should not be used with either gateways of session brokers.

Is managing NLB clusters of this type as simple as it seems?  I'm hoping it will be simple enough I can hand it off to a junior admin to manage and maintain once implemented.