Terminalserver Farm 2008R2 EE Konfiguration

[Login]

Hallo liebe Leute,

vielleicht hat jemand bereits Erfahrung und kann mir bei der Entscheidung helfen:

Die Anforderung ist eine Terminaldienstelösung mit +- 120 Clients.

Zur Verfügung steht eine neue Serverhardware und eine 2008R2 Enterprise Edition.

Das Ganze wird in eine Bestehende Serverstruktur integriert:

Zwei dicke Intelserver an einem iSCSI Storage (2x ESX über 2-Wege Multipathing, insgesamt 8 Win2003 Server)

Nun gehts los. Terminalserver: physikalisch oder virtuell?

Ich tendiere, wegen der bestehenden Serverstruktur stark zum virtuellen. Also fällt die Installation des 2008R2 EE direkt auf der neuen Hardware flach, aber wie sieht das Leistungstechnisch im virtuellen aus? Reicht das im Zweifelsfall? +-120 User in einem Krankenhaus (SAP, Office, Timebase, etc.).

Virtuell würde ich den Server2008R2 EE gleich zwei mal virtuell aufsetzen (geht virtuell mit einer Lizenz 4 mal), um einen NLB-Cluster daraus zu machen, habe gehört das skaliert am Ende besser als nur eine VM, berichtigt mich, wenn das anders ist!

Evtl. könnte ich im neuen Server ein Raid10 für die beiden VMs basteln, die Hardware wäre da. Und wenn empfehlenswert würde ich auf dem Raid10 2 logische Laufwerke als RDMs für die beiden Terminalserver bereit stellen - macht das Sinn? Optional den ESX noch zur Redundanz ans SAN anbinden.

Fertig wäre die Basis

Wie siehts aus? Würdet ihr etwas anders machen?

LG
Conne

[Login]

hm, habe ich mit meiner Beschreibung der Ist-Situation die Poster vergrault?

Wo bleibt der Senf?

[mschoen]

Wieviele von den 120 Usern arbeiten denn gleichzeitig? Ich tendiere viele daher würde ich sagen Echt-Blech!
System-Laufwerk zur Not lokal und die Daten aufs SAN verbannen.

gruß Marcus

[irix]

Mehrere virtuelle TS mit 2vCPUs. Wenn die User den TS nicht festzugeordnet werden koennen must du evtl. eine TS Farm machen. Das was Microsoft da bietet ist aber im Vergleich zu Citrix sehr "sparsam".

Die Userdaten liegen nie auf dem TS sondern der hat nur die Anwendungen installiert oder in Teilen als ThinAPP falls diese nicht TS geeignet sind.

Sofern das SAN genug Leistung hat koennte man die TS dorthin legen... aber ich wuerde fuer den Einsatz von Lokalstorage plädieren. Die User bemerken schnell wenn es Leistungsprobleme gibt und diese koennen nur vom Storage kommen.

Geht mal nen TS kaputt deployest du aus einem Template einen neuen.

Gruss
Joerg

[Login]

hallo!

@mschoen: die 120 User nutzen das System im Zweifelsfall alle! Was meinst du mit Echt-Blech?

@irix: Ja, natürlich ist die M$ TS-Farm im NLB-Cluster kein Citrix. Das Übelste ist es in 2008 Zeiten aber auch nicht. Ich habe mit der TS-Farm und einem Sitzungsbroker, RDP over http, bis jetzt ganz gute Erfahrungen gesammelt.

Die virtuellen Terminalserver werden auch gar keine Nutzdaten hosten. Es handelt sich lediglich um eine C-Partition mit den ganzen Applikationen pro Terminalserver.

- Servergespeicherte, z.T. obligatorische TS-Profile
- Ordnerumleitungen für die profilbasierenden Userdaten

TS-Profile und alle Ordnerumeitungen landen auf einem Fileserver im SAN.

Somit hatte ich angedacht, aus performancegründen die Terminalserver auf dem neuen ESX lokal zu hosten, da ich den TS-VMs mehr zumute, wenn sie auf dem lokalen Raid10, evtl. eben RAW und nicht auf einer VMDK Virtualisierungsschicht aufgesetzt sind.

Das war aber eben eine Frage in meinem Post. Ist das Sinnvoll, erfahre ich Nachteile dadurch?

Klar, die User werden meckern wenns träge wird. Habe als Flaschenhals der VMware jedoch bis jetzt meistens den Storage-Stack heraugefunden.

Das iSCSI Storage hat zwar auch ordentlich Dampf (12x SAS im Raid5, 2-Wege Multipathing mit J-Frames), in Anbetracht des Traffics der anderen Server ist es im Zweifelsfall ok, wenn das laden der TS-Profile aus dem SAN, etc. etwas länger dauert, hauptsache, die Applikationen innerhalb der TS-Farm sind möglichst performant.

Zweite Frage war: Vieviele VMs wären in dem Fall am sinnvollsten. Reichen 2 oder besser doch gleich 4?

Die iSCSI-Anbindung des neuen ESX wäre lediglich zu redundanz Zwecken, um im Notfall auch die VMs innerhalb des SANs auf dem neuen ESX betreiben zu können, wenn z.B. Hardwareprobleme o.Ä. vorliegen würden.

Die neue ESX Hardware weißt auch ordentlich Dampf auf. Intelserver Dual Xeon mit 24 oder 32 pKernen, 48GB RAM und min 6 SAS-Platten an einem ordentlichen externen Kontroller. Genug Hardware für die TS-Farm!?

Gruß,
Conne

[irix]

Die Verwendung von RDM bringen dir hier keinen Vorteil und das wuerde auch nur funktionieren wenn die Daten aus dem SAN kommen. Bei Verwendung von Localstorage gibts keine RDMs.

3-4 TS a 2vCPUs verteilt auf 2 ESX Hosts. Bisschen komisch finde ich die geringe Anzahl von Speicher. Wieviel verbrauchen denn deine 120 User so?

Gruss
Joerg

[Login]

Bei Verwendung von Localstorage gibts keine RDMs.

Achja, da war doch was, mir dämmert es dunkel...

OK, RDMs sind vergessen

3-4 TS a 2vCPUs verteilt auf 2 ESX Hosts

Naja, auf den zweiten ESX für die TS-Farm warte ich, falls der eine überfordert sein sollte...
Auch im Hinblick auf diese Problematik ist die irtuelle TS-Farm später dementsprechend leichter erweiterbar...

Bisschen komisch finde ich die geringe Anzahl von Speicher. Wieviel verbrauchen denn deine 120 User so?

Meinst du die 48GB Speicher? Aktuell kann ich nur sehr schwer abschätzen, wieviel Speicher die 120 User oder deren Applikationen belegen werden. Wie gesagt, Office2010, SAP Frontend, und andere aus dem Gesundheitswesen bekannte Programme. Auch Röntgenbilderbetrachtungs-Software und diverse Frontends von Med. Geräten sind Anspruch. Jedoch bin ich mir hier bereits ziehmlich sicher, dass ich für die Röngenbilderbetrachtungssache sepparate Fat-Clients hinstellen muss, da das nunmal sehr Grafisch ist. Aber das sind auch nur ein bis 2 Hände voll.

Wären hier pausch 72GB Speicher/ESX angesagter?

Ich denke, ich werde dann 3 TS-VMs auf den ersten ESX legen und bei Engpass Ende des JAhres noch einen weiteren ESX mit weiteren 3 TS-VMs dem Cluster bereit stellen. ...Insofern mich der Klinikchef zu dem Zeitpunkt noch nicht gelüncht hat (dieses Jahr wird ein Investitionsjahr sein )

Etwas traurig stimmt mich, dass ich von der RDM Konfiguration absehen muss und ums vmdk nicht herum komme...

Gruß,
Conne

[irix]

..
Etwas traurig stimmt mich, dass ich von der RDM Konfiguration absehen muss und ums vmdk nicht herum komme...

Gruß,
Conne

Was hattest du dir versprochen das du meinst trautig sein zumuessen?

Gruss
Joerg

[Login]

Was hattest du dir versprochen das du meinst trautig sein zumuessen?

Leistungssteigerung im Dateisystem?

[irix]

Was hattest du dir versprochen das du meinst trautig sein zumuessen?

Leistungssteigerung im Dateisystem?

Welche schon zu VI3.5 Zeiten kaum existent waren und nur fuer Sequentiellen 4KB Read Workload einen Vorteil fuer phy. RDM aufzeigten.
Schau mal in http://www.vmware.com/files/pdf/perform ... fs_rdm.pdf nach. Obs noch eine Neuauflage mit vSphere gibt weis ich aber leider nicht.

Gruss
Joerg

[mangold]

Grundsätzlich spricht absolut nichts gegen virtualisierten Terminal Servern. Bevor du loslegst, solltest du den möglichen Speicherverbrauch (RAM) aber wirklich ermitteln, denn DAS ist genau der problematische Part. Sowohl Terminal Server als auch Virtualisierung sind i.d.R. nicht dazu gedacht, CPU intensive Aufgaben zu konsolidieren, erhöhter Ramverbrauch lässt sich aber selten vermeiden.

Der Einsatz von x64 Windows erleichtert das Aufrüsten ungemein, aber eine TS Lösung ist unangebracht, wenn du nur 10 User pro TS hinbekommst (als Beispiel).

20-30 User pro TS sind ok, aber das ist pauschalisiert, und bedarf einer genaueren Analyse. Bei dieser Größenordnung ist - wir Irix schon geschrieben hat - der Einsatz von Citrix zu bedenken.

Der Storage ist für den Betrieb der TS selbst nicht unbedingt ausschlaggebend, denn diese arbeiten mit genügend Speicher weitgehend im RAM, die lokale Plattenperfomance eines TS war selten Ursachen für Probleme. Für das Backend (insbesondere Fileserver) sieht das schon wieder anders aus, ein schleichender FS der sowohl Profile als auch Datenlaufwerke bereitstellt, hat so mancher Farm das Genick gebrochen.

ich betreibe hier ca. 50 virtuelle TS, sowohl auf ESX als auch XEN.

[Login]

danke für den Link, ich habs mir gestern Abend mal reingezogen. Ich hätte wirklich nicht gedacht, dass die Unterschiede so marginal sind. Es lebe das VMFS

Also, so wie ihr schreibt, könnte das mit nur einer Hardware wirklich knapp werden, auch wenn diese relativ dick ausfallen wird.

Ich habe den direkten Vergleich im Moment leider nur bei einer physikalischen TS-Farm in einer anderen Klinik. Hier sind so ca 60 User auf einer Hardware, bei gerade mal 20-30GB Ramauslastung. Aber wie gesagt, das ist physikalisch!

Daher habe ich aber auch ehrlich gesagt geschlussfolgert, dass mir in der aktuellen Planung 48 GB RAM für einen Server ausreichen. Was ich aber nicht berücksichtigt habe, ist dass die VM immer mehr RAM nutzt/will als der äquivalente pServer...

Natürlich kommt das Backend jetzt auch zum tragen, ich hoffe, das die SAN Anbindung das hergibt, was die Farm auch braucht.

ich betreibe hier ca. 50 virtuelle TS, sowohl auf ESX als auch XEN.

Mit TS-Diensten oder Citrix?

LG
Conne

[mangold]

mit Citrix, was aber für das Sizing erst mal nicht so wichtig ist. Citrix fügt einige Funktionalitäten hinzu und erleichtert das Management, ändert aber nichts am Ressourcen Verbrauch.

Dazu noch ein paar Infos; auf einem XenServer (ich unterscheide jetzt mal die Hypervisoren nicht) mit 16 Cores und 72 GB Ram, laufen 8 XenApps (TS) mit je 4 GB Ram und je 20 user. Also 160 User pro Host. Der Ram ist doppelt ausgelegt, weil der Host im Notfall auch meht VMs aufnehmen muss. Dies wurde auch schon unter Last getestet, ist aber nichts, was ich für den Regelbetrieb empfehlen würde.

Bei x64 Windows kannst du den Ramverbrauch dementsprechend umrechnen. Ich denke aber 8 VMs mit je 8 GB ram sind vollkommen ok.

[shuter]

Hallo zusammen
Eine sehr hilfreich Diskussion hier. Was mich noch interessieren würde.
Wie macht ihr das mit den diversen Terminalsetver, die müssen ja identisch sein. Kann ich die bestehende Vm einfach klonen? Und schon ist der 2. Ts da?
Wie ist das mit der SId? Brauche ich hier nichts zu mach .

Thx für die Hilfe

Gruß Sa

[bla!zilla]

Na ja, Template und Bereitstellungsrichtlinie ist schon okay. Fertige Maschinen clonen bin ich nicht so ein Freund von. Wenn es große Farmen sind: Citrix XenApp und Citrix Provisioning Services.

[shuter]

hi
Danke für deine Antwort. Also du würdest keine fertig installierte Terminalserver klonen und die Dinger via eine Vorlage bei ESX installieren. Wann machst Du die Vorlage? Gibt es einen guten Zeitpunkt?
Wie stellt man am Besten sicher, dass alle Terminalserver genau gleich installiert und konfiguriert sind?
Ist das mit der klonerei bei Server2008r2 immer noch ein Problem wie früher mit dieser SID? Einen SID Changer brauche ich ja mit 2008 nicht mehr, richtig?


Gruss Sascha

[mangold]

Also bei so einer Lösung klont man keine Terminal Server. Mittel der Wahl ist bei Citrix in der tat die "Provisioning Services". Dabei werden die VMs nicht als vmdk abgelegt. Die VMs erhalten eben keine vmdk sondern booten vom Netzwerk, das C Laufwerk ist ein getreamtes Laufwerk. Man hat also ein zentrales Image auf dem Provisioning server, welches autoamtisch beim Booten der VMs genutzt wird.

Diese Image lässt sich kopieren und anpassen und dann als neue Version deployen.

SIDs sind generell kein Problem mehr, das ist auch so ein "Urban Legend". Um alles andere kümmert sich der "provisioning services" Dienst, der verändert Computernamen usw. beim Booten der VM.

Einen neuen Terminal Server erstellt man also, in dem man eine neue VM (ohne vdisk) anlegt, diese VM ebenfalls im PVS registriert (mit MAC Adresse) und die VM dann bootet. Citrix Xenapp erkennt automatisch diesen Terminal Server und fertig.

Das ist jetz ein wenig vereinfacht ausgedrückt, weitere Erläuterungen würden aber den Rahmen hier sprengen. Inzwischen gibt es Powershell APIs für fast alle Citrix Produkte und so wie es von VMware Orchestra gibt, gibt es bei Citrix auch eine Workflow Engine (Name ist mir entfallen). mit dem man das weiter automatisieren kann.

[bla!zilla]

Wenn man mit Templates arbeitet, dann nutzt man Sysprep oder die Guest Customization von vSphere.

btw: Auch per PVS bereitgestellte XenApp Server sollten eine VMDK haben - diese dient als Write Cache. Sonst wird der Write Cache auf den PVS Server gelegt und das ist nicht so der Hit.

[mangold]

Wenn man mit Templates arbeitet, dann nutzt man Sysprep oder die Guest Customization von vSphere.

btw: Auch per PVS bereitgestellte XenApp Server sollten eine VMDK haben - diese dient als Write Cache. Sonst wird der Write Cache auf den PVS Server gelegt und das ist nicht so der Hit.

ja, das sind aber Details die hier den Rahmen sprengen. Habe ich auch geschrieben Bei provisionierten Terminal Servern braucht man eben kein Sysprep weil das der PVS Dienst übernimmt. Mein Kommentar zur SID bezieht sich auch darauf, das man früher immer NEWSID von Sysinternals hat laufen lassen. Die SID ist aber mitnichten das große Problem, habe vor nicht so langer Zeit einen Text vom Entwickler von NEWSID gelesen, der diesen Mythos aufklärt. Anonsten hast du natürlich recht, SYSPREP ist das Mittel der Wahl um VM Templates zu deployen, reicht für Citrix Xenapp aber nicht aus.

EDIT; Hier der Link zum Artikel
http://easytopia.de/newsid-war-von-anfang-an-nutzlos/
bzw. der eigentlich Artikel
http://blogs.technet.com/b/markrussinov ... 91024.aspx