Bestehenden RD Virtualisierungshost einbinden

[CoNtAcT2000 15]

Hallo Leute,

 

ich habe heute eine neue RDS-Farm mit Server 2019 aufgebaut.

Nun bin ich an dem Punkt, dass ich den Virtualisierungshost hinzufügen soll.

 

Hier wurde ich gerne unseren bestehenden Hyper-V 2016 Cluster eingeben.

Dann kommt das Menü "Blah blah...auf Server X wird Rolle Y installiert wollen Sie wirklich, Server wird bei Bedarf neugestartet".

 

Ähhhhhhhh, normal Mut zur Lücke. Aber da auf den Hyper V Maschinen """ein paar""" Server rennen, wärs echt uncool, wenn der da was platt macht und evtl. sogar noch die Server rebootet.

Hat das schonmal jemand gemacht?

 

Ich würde sagen er erkennt, dass da die Rolle schon verfügbar ist und macht nichts, außer dass die RDS Konfiguration dann vollständig ist.

Aber äh, kann ja mal nicht schaden in die Runde zu fragen :)

 

VG

Michael

[Dukel 454]

Möchtest du Desktop Sessions (VDI) oder Session Hosts (Terminalsserver) nutzen?

In beiden Fällen nimmt man keinen vorhandenen Hyper-V Server / Cluster.

[cj_berlin 1.323]

vor 45 Minuten schrieb CoNtAcT2000:

 

Ich würde sagen er erkennt, dass da die Rolle schon verfügbar ist und macht nichts, außer dass die RDS Konfiguration dann vollständig ist.

Aber äh, kann ja mal nicht schaden in die Runde zu fragen :)

Ein neu in die Bereitstellung hinzugefügter Host, ob RDSH oder RDVH, wird in der Regel immer durchgerissen.

Dein Cluster ist danach aber keins mehr. VDI-Workloads und Backend-Workloads auf gleichen Hosts fahren, ist möglich, aber mit sehr viel mehr Planung verbunden.

vor 13 Minuten schrieb Dukel:

Möchtest du Desktop Sessions (VDI) oder Session Hosts (Terminalsserver) nutzen?

Na wenn er Hyper-V hinzufügt...  

[CoNtAcT2000 15]

Es geht um ne VDI Infrastruktur mit der wir mal testen wollen, ob das was für uns ist.

 

vor 2 Stunden schrieb cj_berlin:

Ein neu in die Bereitstellung hinzugefügter Host, ob RDSH oder RDVH, wird in der Regel immer durchgerissen.

Dein Cluster ist danach aber keins mehr. VDI-Workloads und Backend-Workloads auf gleichen Hosts fahren, ist möglich, aber mit sehr viel mehr Planung verbunden.

Na wenn er Hyper-V hinzufügt...  

 

ohhhh  ooookkaaaayyyy.

Dann lasse ich da mal lieber die Finger von dem Cluster. Dann müssen wir doch noch Hardware zusätzlich beschaffen 

Danke für die Info.

 

Aber dann mal die Frage, warum ist der Cluster danach aufgelöst? Ich mein, man will doch auch unter einer VDI Struktur nen hochverfügbaren Hypervisor haben?

[cj_berlin 1.323]

vor 3 Minuten schrieb CoNtAcT2000:

Ich mein, man will doch auch unter einer VDI Struktur nen hochverfügbaren Hypervisor haben?

Nein. Denn wenn ein Host stirbt, sterben alle Desktop-VMs darauf mit, und es sorgt der Connection Broker dafür, dass sie neu aus dem Image geklont werden, auf einem Host, der noch lebt.

Anders ist es, wenn Du Terminalserver hast, die aus Sicht des Connection Brokers ja fix provisioniert sind. Unter solchen VMs möchte man in der Tat eine hochverfügbare Plattform haben - wenn man sie denn virtualisiert. Aber da steuert der Connection Broker auch nicht die Virtualisierung.

Apropos: Denk daran, dass im Microsoft VDI-Szenario jeder User oder Client eine RDS CAL braucht, weil ja der Connection Broker (und evtl. RDWeb und RDG) im Spiel ist. Und ja, es ist so b***d wie es sich anhört:

• Microsoft VDI --> RDS CAL nötig
• XenDesktop oder View --> keine RDS CAL nötig.

Will damit sagen: Wenn man auch das komplett fehlende Image Management in der Microsoft VDI mit ins Kalkül nimmt, ist es vermutlich auf lange Sicht billiger, ein Third Party VDI-Produkt einzusetzen, es sei denn, man hat die RDS CALs bereits. In diesem Fall sollte man aber die Möglichkeit von Terminalservern ausschöpfen, bevor man zu VDI greift, unabhängig vom Technologie-Anbieter.

bearbeitet 22. Dezember 2021 von cj_berlin

[CoNtAcT2000 15]

Wir haben uns bereits vor Jahren mit Citrix rumgeärgert - damals mit XenDesktop 7-7.6. Sorry, aber das Produkt und der Hersteller gehen einfach mal gar nicht. Es war ein sehr teures Projekt für uns und für den Hersteller ein absoluter Imageverlust...Aber da will ich gar nicht weiter drauf eingehen.

 

Der Hintergrund warum wir aktuell nach weiterer Virtualisierung schauen ist ganz einfach, dass Homeoffice und flexibles Arbeiten immer mehr benötigt/gefordert wird.

Aktuell schalten sich unsere User über das RDWeb - RD-Gateway auf ihren Arbeitsplatzrechner per RDP auf. Dazu muss aber dann der Computer auch laufen - was unter anderem Ärger mit dem Brandschutz gibt etc.

Allerdings ist ein einfacher Hardwareclient halt immer noch die preislich günstigste Bereitstellung eines Arbeitsplatzes.

 

Mit der TSFarm2016 haben wir jetzt schon einige Jahre Erfahrung sammeln können. zum Bereitstellen von Applikationen sehr gut. Funktioniert super.

Haben dann versucht den Benutzern mal nen shared Desktop zur Verfügung zu stellen, aber das ist nicht praktikabel..... zu viele Dinge die einfach nicht so gut funktionieren wie auf nem vollwertigen Client Desktop.

(Auch vor dem Hintergrund, dass die meisten unserer User sind NICHT wirklich IT erfahren sind, auch wenn sie schon 30 Jahre mit nem Computer arbeiten)

 

Da Citrix nicht mehr in die Tüte kommt, haben uns aktuell noch VMWare Horizon und Microsoft angeschaut.

 

Microsoft ist für uns aktuell das Produkt mit dem wir testen möchten. Da man unter anderem in Lizenzangelegenheiten, Patches etc. nur nach einem Hersteller schauen muss. Auch haben wir für uns festgestellt, dass wir die tollen Features von Citrix oder VMware eigentlich überhaupt nicht brauchen. Wir haben nicht die Situation, dass wir 3 Images mit 10 Anwendungen pflegen und zur Verfügung stellen und warten können. Wir haben SEHR viele unterschiedliche Bereiche und XXX Anwendungen. Für uns ist eine vollwertige virtuelle Maschine für jeden User die beste und die einfachste Lösung (auch die technisch teuerste). Diese können unsere Techniker problemlos mit dem SCCM weiterhin in Eigenregie verwalten. Von daher wäre für uns ein hochverfügbarer Hypervisor schon gewünscht.

 

Alles andere bekommen wir auch mit dem zur Verfügung stehenden Personal nicht gehandelt.

 

Im Prinzip könnten wir auch einfach hingehen und unsere VM´s auf HyperV oder VMWare einfach mit nem Skript und ner vorgefertigten Installation erstellen, dann wäre der Drops auch gelutscht.

Aber da fehlt mir in diesem Bereich die Erfahrung ob VDI noch entscheidende Vorteile für unseren Zweck bietet - oder ob wir/ich für unser Vorhaben da komplett falsch denken.

 

 

 

 

[cj_berlin 1.323]

Moin,

Microsoft VDI ist ein sehr starres Produkt und kann euren Fall vermutlich nicht abbilden, weil es keine persistenten Desktops realisieren kann. Es ist genau für den Fall gedacht, den ihr nach Deinen Angaben nicht habt - einige wenige Images für relativ viele Sessions. Mit Microsoft-Bordmitteln seid ihr bei 1x Session Collection pro Benutzer, die jeweils eine einzige Maschine enthält. Gebt einfach jedem User eine statische VM mit einer fixen IP, dann habt ihr eure Client-Landschaft noch einmal virtuell nachgebildet, aber mehr scheint ja nicht gefordert zu sein. Der Connection Broker bringt euch dabei exakt Null, da er ja jedem User jeden Tag immer die gleiche VM zuweisen müsste.

 

Warum ausgerechnet in eurer Firma ein Shared Desktop "nicht praktikabel" sein soll, gehört vermutlich in den Bereich des Anforderungsmanagements und nicht in den der technischen Umsetzbarkeit  

bearbeitet 22. Dezember 2021 von cj_berlin

[CoNtAcT2000 15]

Gefordert/gewünscht ist ein vollwertiger Windows Desktop. So wie ihn der User gewohnt ist - UND vor allem, dass wir ihn mit wenig Aufwand mit unserer kleinen Mannschaft betreiben und verwalten können - ohne viel zu großen Aufwand noch zusätzlich auf die wenigen halbwegs versierten Admins im Backend zu ziehen - und unsere normalen Techniker kaum noch mithelfen können.

 

Okay, dann scheint das also eigentlich für uns auch nicht von Nutzen zu sein. Wird es wohl am besten sein, wie ich es mir von Anfang an gedacht habe - VMs aufsetzen mit Software vom SCCM versorgen, aus de Maus.

 

Zum Shared Desktop - Wenn man 5 Programme nutzt und nichts anderes darf der User starten etc. dann mag das wunderbar funktionieren. Ist bei uns aber nicht so. Klar könnte man machen, aber das ist nicht gewünscht!

Und teilweise auch nicht praktikabel weil wir X unterschiedliche Anforderungen haben. Von technischen Zeichner, Mediengestalter, Werkstattmechaniker, Sachbearbeiter.........

Software nicht TS fähig, nutzt keinen normalen Speichern Dialog und die Leute speichern sinnlos auf den Server............. da gibt es soooooo unendlich viele Baustellen mit dem Shared Desktop.
Mit genügend Manpower und Aufwand evtl. natürlich betreibbar, aber für uns ist das leider völlig unpraktikabel.