Benutzer mit den meisten Antworten
Remote Desktop Dienste auf verschiedenen virtuellen Servern

Frage
-
Hallo zusammen,
Wir sind aktuell dabei eine Remote Desktop Umgebung für 30-40 Mitarbeitern unter Windows Server 2012R2 und Hyper-V zu planen. Was definitiv schon fest steht, ist die Realisierung über Session Host, nicht über virtuelle Desktops, da dies aus administrativer Sicht einen erheblichen Mehraufwand darstellt.
Nun stellt sich die Frage, ob und wie wir die Remote Desktop Dienste (Rollen) verteilen, da eine Ein-Server-Farm aus Leistungsgründen wohl eher nicht zielführend ist. Welche Rollen machen Sinn auf dem gleichen Server zu realisieren, ist ein zweiter Connection Broker für Hochverfügbarkeit sinnvoll.
Klar kann für jede Rolle auch eine eigene virtuelle Maschine konfiguriert werden, jedoch ist dies ebenso mit höheren Lizenzkosten verbunden.
Der Vollständigkeit halber: In der Umgebung soll noch ein DC Telefonanlage als VM laufen.
Über Eure Ideen würde ich mich sehr freuen!
Viele Grüße
Alfred Webber
Antworten
-
Moin,
bei 30-40 Usern würde ich pauschal zwei Session Hosts vorsehen. Das ist natürlich nur so ins Blaue geraten und hängt zum Großteil von den Anwendungen und deren Verhalten ab.
Als Infrastruktur würde vermutlich ein Server mit den Rollen Broker und WebAccess ausreichen. Soll über's Internet zugegriffen werden, würde ich noch einen weiteren Server in der DMZ als RDS Gateway bereitstellen.
Wenn Du Hochverfügbarkeit benötigst, brauchst Du deutlich mehr ... angefangen mit einem Hyper-V Cluster und einem SQL-Cluster für die Connection Broker im HA Modus. Das WebAccess Portal müsste natürlich auch per NLB hochverfügbar gemacht werden ... usw. usf. Hochverfügbarkeit bedeutet nunmal kein Single Point of Failure in der Bereitstellung.
Als Einstieg könntest Du mal das TLG zum Thema nachbauen:
https://technet.microsoft.com/de-de/library/hh831610.aspx
This posting is provided AS IS with no warranties.
- Als Antwort markiert Mihaela ParedesMicrosoft contingent staff, Moderator Montag, 29. Februar 2016 13:32
-
Die Session Hosts sollten grundsätzlich von den Infrastruktursystemen (Broker etc) getrennt werden. Ich fomuliere es mal so: Ich möchte unter keinen Umständen, dass sich Anwender auf meinen Infrastruktursystemen tummeln ;-)
Nebenbei lässt sich so die Umgebung viel einfacher erweitern und migrieren.Wenn später mal HA ins SPiel kommen soll, würde ich gleich alle Rolle auf eigene Server verteilen. Besonders mit Broker und WebAccess kann es "frickelig" werden. Beide Rollen nutzen NLB für hohe Verfügbarkeit. Das Ganze wieder aufzudröseln macht mehr Arbeit und verursacht mehr Downtime als mal eben zwei neue VMs hochzuziehen und einzubinden.
Der Lizenzserver kann in einem kleinen Setup mit auf dem Broker laufen. Das kann ggf. bei HA problematisch werden ... wenn Dir der Broker mit dem Lizenzdienst abraucht sind gleich zwei kritische Komponenten down und das Recovery wird u.U. deutlich aufwändiger.
Ein RDS Gateway empfängt Verbindungen aus dem "bösen" Internet. Damit ist es für mich ein Fall für die DMZ. Ob und wie eine Trennung realisiert werden soll (physisch, per VLAN oder gar nicht) muss individuell bewertet weren.
This posting is provided AS IS with no warranties.
- Als Antwort markiert Mihaela ParedesMicrosoft contingent staff, Moderator Montag, 29. Februar 2016 13:32
-
Hallo Alfred,
zum Thema Hochverfügbarkeit: Stelle Dir selbst mal die Frage oder dem Management, wie lange die RD Umgebung ausfallen darf und ob 40 Mitarbeiter einen halben bis ganzen Tag ohne Office Apps, ERP, etc. (Leider hast Du nichts zum Workload mitgeteilt) auskommen können. Handelt die Firma mit Waren die früh-morgens auf den Weg gebracht werden müssen usw. Das Gleiche gilt für die Verteilung der Workloads, auch hier ist ein Workload Diagramm/Tabelle wichtig um einen Überblick über die Sessions/Mitarbeiter zu erhalten. In einer HA Umgebung kommen zusätzlich Kosten für ein SAN samt Shared Storage zum Tragen, unter anderem spielt bei mehreren Sessions die Storage Performance eine große Rolle.
Gruß,
Marcel
http://www.windowspro.de/marcel-kueppers
- Bearbeitet Marcel Küppers Dienstag, 16. Februar 2016 14:34
- Als Antwort markiert Mihaela ParedesMicrosoft contingent staff, Moderator Montag, 29. Februar 2016 13:32
Alle Antworten
-
Moin,
bei 30-40 Usern würde ich pauschal zwei Session Hosts vorsehen. Das ist natürlich nur so ins Blaue geraten und hängt zum Großteil von den Anwendungen und deren Verhalten ab.
Als Infrastruktur würde vermutlich ein Server mit den Rollen Broker und WebAccess ausreichen. Soll über's Internet zugegriffen werden, würde ich noch einen weiteren Server in der DMZ als RDS Gateway bereitstellen.
Wenn Du Hochverfügbarkeit benötigst, brauchst Du deutlich mehr ... angefangen mit einem Hyper-V Cluster und einem SQL-Cluster für die Connection Broker im HA Modus. Das WebAccess Portal müsste natürlich auch per NLB hochverfügbar gemacht werden ... usw. usf. Hochverfügbarkeit bedeutet nunmal kein Single Point of Failure in der Bereitstellung.
Als Einstieg könntest Du mal das TLG zum Thema nachbauen:
https://technet.microsoft.com/de-de/library/hh831610.aspx
This posting is provided AS IS with no warranties.
- Als Antwort markiert Mihaela ParedesMicrosoft contingent staff, Moderator Montag, 29. Februar 2016 13:32
-
Hallo Alfred,
zum Thema Hochverfügbarkeit: Stelle Dir selbst mal die Frage oder dem Management, wie lange die RD Umgebung ausfallen darf und ob 40 Mitarbeiter einen halben bis ganzen Tag ohne Office Apps, ERP, etc. (Leider hast Du nichts zum Workload mitgeteilt) auskommen können. Handelt die Firma mit Waren die früh-morgens auf den Weg gebracht werden müssen usw. Das Gleiche gilt für die Verteilung der Workloads, auch hier ist ein Workload Diagramm/Tabelle wichtig um einen Überblick über die Sessions/Mitarbeiter zu erhalten. In einer HA Umgebung kommen zusätzlich Kosten für ein SAN samt Shared Storage zum Tragen, unter anderem spielt bei mehreren Sessions die Storage Performance eine große Rolle.
Gruß,
Marcel
http://www.windowspro.de/marcel-kueppers
- Bearbeitet Marcel Küppers Dienstag, 16. Februar 2016 14:34
- Als Antwort markiert Mihaela ParedesMicrosoft contingent staff, Moderator Montag, 29. Februar 2016 13:32
-
Hallo,
das ging jetzt doch recht schnell mit den Antworten.
HA sollte erst mal in den Hintergrund gestellt werden und Gottseidank kann das im Nachgang ja immer noch erweitert werden.
Das System wird auf 2 Nodes geclustert, die derzeitigen Workloads werden vorerst Office und ein CRM beinhalten, welches als Webapplikation über das Internet bei einem anderen Hoster aufgerufen wird. Derzeit sind keine Datenbankanwendungen geplant, Backup wird von einer anderen physikalischen Maschine aus durchgeführt.
Das Hauptaugenmerk sollten wir daher auf die nötigen Rollen wie Sessionhost, Licensing und Connectionbroker setzen, sowie Gateway und WebAcces.
Ich persönlich würde den Sessionhost (da der letztendlich die meiste Last abbekommt) als eigenständige VM realisieren und aufgrund der I/Os bei 40 Mitarbeitern auf einen eigenen Node setzen. Zusätzlich Licensing, WebAcces und CB als eine eigenständige Maschine und das Gateway in näherer Zukunft ebenfalls als eigenständige Maschine.
Macht das soweit Sinn, oder könnte das Gateway auch auf die Maschine. Weitere Anwendungen ließen sich ja auch problemlos auf einen weiteren SH realisieren.
Gruß Alfred
-
Die Session Hosts sollten grundsätzlich von den Infrastruktursystemen (Broker etc) getrennt werden. Ich fomuliere es mal so: Ich möchte unter keinen Umständen, dass sich Anwender auf meinen Infrastruktursystemen tummeln ;-)
Nebenbei lässt sich so die Umgebung viel einfacher erweitern und migrieren.Wenn später mal HA ins SPiel kommen soll, würde ich gleich alle Rolle auf eigene Server verteilen. Besonders mit Broker und WebAccess kann es "frickelig" werden. Beide Rollen nutzen NLB für hohe Verfügbarkeit. Das Ganze wieder aufzudröseln macht mehr Arbeit und verursacht mehr Downtime als mal eben zwei neue VMs hochzuziehen und einzubinden.
Der Lizenzserver kann in einem kleinen Setup mit auf dem Broker laufen. Das kann ggf. bei HA problematisch werden ... wenn Dir der Broker mit dem Lizenzdienst abraucht sind gleich zwei kritische Komponenten down und das Recovery wird u.U. deutlich aufwändiger.
Ein RDS Gateway empfängt Verbindungen aus dem "bösen" Internet. Damit ist es für mich ein Fall für die DMZ. Ob und wie eine Trennung realisiert werden soll (physisch, per VLAN oder gar nicht) muss individuell bewertet weren.
This posting is provided AS IS with no warranties.
- Als Antwort markiert Mihaela ParedesMicrosoft contingent staff, Moderator Montag, 29. Februar 2016 13:32
-
Habe mir gleich mal eine kleine Testumgebung aufgebaut, funktioniert alles wunderbar, vielen dank euch allen für die schnelle Unterstützung! Falls weitere Fragen aufkommen sollten, werde ich mich nicht scheuen diese zu stellen!
Viele Grüße
Alfred