Is een Terminal Server Session Broker meervoudig mogelijk?

[Guvner]

De situatie is als volgt:

Er komt een aantal Terminal Server Gateway Farm, welke is opgezet door een 8-tal Terminal Server Gateway servers via NLB in een cluster te zetten.

Achter deze Gateway Farm komt een Terminal Server Farm met een groot aantal (hoe groot is nog te bepalen) Terminal servers. Omdat we hier praten over een groot aantal servers vind ik het erg belangrijk dat de achterliggende Session Broker server niet enkelvoudig maar meervoudig is uitgevoerd.

De configuratie mag geen single-point-of-failure hebben vanwege de omvang van het project. Hierom heb ik zitten kijken of ik de Session Broker server meervoudig kan uitvoeren, maar kan hier eigenlijk weinig over vinden.

Is het dan echt zo dat zo'n session broker hier een single point of failure gaat worden of zijn er nog andere mogelijkheden?

[Zwelgje]

http://technet.microsoft....rary/cc772418(WS.10).aspx

session broker suxx in grote omgevingen, uberhaubt is TS zonder citrix in enterprise omgeving een grote hell kwa beheer imho

[Guvner]

Dit is niet helemaal wat ik bedoelde.

De gegeven link beschrijft hoe de session broker de load balancing regelt. Maar ik wil juist meerdere session brokers, zodat de load hierop verdeeld kan worden maar daarnaast ook nog als extra voordeel heeft dat we geen single-point-of-failure meer hebben.

Maar hoezo is een session broker hell in een grote omgeving?

[Question Mark]

Guvner schreef op woensdag 29 december 2010 @ 14:14:
Is het dan echt zo dat zo'n session broker hier een single point of failure gaat worden of zijn er nog andere mogelijkheden?

Je kunt de session broker als "generic service" door een failovercluster laten hosten. Andere optie is om deze op een virtuele omgeving te laten hosten die HA uitgevoerd is.

Hoe groot gaat je omgeving ongeveer worden? MS zegt nl. zelf nog steeds dat voor echt grote omgeving beter gebruik gemaakt kan worden van Xenapp.

[Crazius]

Zet al je terminal servers in NLB dit is al automatisch load balancing. Session broker zorgt er alleen maar voor dat de gebruiker naar zijn oorspronkelijke sessie word herleid. Als die bak het niet doet maakt het niks uit daar merken de gebruikers niks van. NLB is daarin tegen super en werkt altijd. Verdeelt netjes de load over de 8 servers en als je er 1 in onderhoud trekt word alles omgeleid.

[Gert]

Als een gebruiker disconnect en opnieuw inlogt merkt hij het wel zeker als hij niet op z'n oude sessie terecht komt, allerlei documenten zullen gelocked zijn omdat ze in de andere sessie open staan.
Elke dure load balancer praat ook met de TS session directory dus beetje vreemd om dat af te doen als een nutteloos iets.

't Kan inderdaad alleen met cluster service, je kan het niet load balancen aangezien er één database is die gebruikt wordt. Een HA VM is geen oplossing want als je virtuele Windows installatie corrupt is, heb je nog niks.

[Zwelgje]

Gert schreef op vrijdag 31 december 2010 @ 11:19:
Als een gebruiker disconnect en opnieuw inlogt merkt hij het wel zeker als hij niet op z'n oude sessie terecht komt, allerlei documenten zullen gelocked zijn omdat ze in de andere sessie open staan.
Elke dure load balancer praat ook met de TS session directory dus beetje vreemd om dat af te doen als een nutteloos iets.

't Kan inderdaad alleen met cluster service, je kan het niet load balancen aangezien er één database is die gebruikt wordt. Een HA VM is geen oplossing want als je virtuele Windows installatie corrupt is, heb je nog niks.

Op 2008 r2 kan je de sessionbroker gewoon clusteren hoor

http://technet.microsoft....rary/dd443539(WS.10).aspx

Support for additional clustered services. In addition to the services and applications you could previously configure in a cluster, you can now cluster Distributed File System (DFS) Replication member servers and a Remote Desktop Connection Broker (formerly Terminal Services Session Broker).

as for die database die settings staan in de registry en worden door de cluster service automagisch gerepliceerd naar de andere nodes

http://technet.microsoft....rary/ff686148(WS.10).aspx

Although it is not called out in the previous illustration, the clustered instance of RD Connection Broker stores important state information in registry keys that the Cluster service monitors and replicates between the cluster nodes. (This differs from some other clustered services or applications, which typically store such information in cluster storage.) Because the information is automatically replicated between nodes, when Node 2 begins running the clustered instance of RD Connection Broker, the state information it needs is already stored in the local registry on the node.

[Verwijderd]

Je kunt inderdaad clusteren maar als je toch al over een 8 server farm praat dan zie ik eigenlijk niet waarom je over MS Terminalserver praat. Het is bijna niet te doen (zonder 3rd party tools) om de farm goed onderhouden te krijgen. Ik ken mensen die het geprobeerd hebben (icm 3rd party tools) en die test opstellingen zijn allemaal gefaald. Enkele redenen zijn:

Servers uit loadbalancing halen is slecht uitgevoerd en te ingewikkeld.
Alle published apps die je aanmaakt moet je apart exporteren en importeren op alle TS servers.
Sessie management en remote support is te ingewikkeld.

Het is geen wonder dat MS het aanraad om Citrix te gebruiken. En ze willen het ook nooit anders maken want Citrix en MS zijn enorm goede maatjes..