RDS oder VDI Server, Dimensionierung
Hallo zusammen,
ich befinde mich aktuell in der Machbarkeitsstudie zu einer Lösung mit RDS oder VDI.
Ich habe diesen Thread dazu gelesen, aber zur eigentlichen Frage nicht wirklich viele Informationen daraus ziehen können .
Benötigte Hardware für schnelle VDI Lösung
Folgende Situation : CRM/ERP System, auf Basis von alter Access Version, soll nicht ersetzt werden (bitte respektiert das einfach). Aufgrund von Performanceproblemen die sich
mit Windows 10 1803 eigeschlichen haben (SMB Caching Probleme bei Netzwerkbetrieb, ) soll nun das Netzwerk als limitierender Faktor beseitigt werden.
Da Access mit lokalem Backend recht zügig unterwegs ist, gilt es nun "DIE" Lösung zu finden.
Generell würde ich eher zu einem RDS tendieren, da ich im Grunde nur das CRM/ERP darüber "virtualisieren" möchte. Am Client-PC nutzt die Access Runtime grundsätzlich nur 1 Kern, und das recht intensiv. Nun habe ich Sorge, dass dies auf dem Server nicht anders wäre, was ja bei ~ 50 Nutzern einen GAU bedeutetn würde.
1.) Habt Ihr da Erfahrungen mit bockigen Anwendungen? Ist der Threadhandler von WindowsServer in der Lage, dass vernünftig zu verteilen?
Die nächste Frage betrifft dann ja die Dimensionierung des Systems. Da habe ich keine Erfahrungen drin, habe mich nur etwas belesen. Ich gehe also von 50 Clients mit je 4 Kernen und 4 GB RAM aus. RAM kann ich somit ganz gut selber berechnen, wenns um den VDI geht, aber wie ist es bei RDS?
2.) Wie berechne ich den CPU Bedarf korrekt bei RDS/VDI? Stichwort overprovisioning
Als Platten dachte ich an SSDs im RAID 10 und ein RAID1 NVMe Verbund als "Backend-Pool". Prinzipiell wird sicher eher ein Workstation/Enthusiastensystem als Grundlage dienen müssen, da KMUs i.d.R. kein Geld für IT ausgeben. Auch das spiegelt nicht meine Überzeugung, sondern nur den Rahmen meiner Möglichkeiten, Bonbons zu drehen. Fix ist das aber noch nicht, da es noch zu früh dafür ist.
Die Grundfrage bleibt die Bedarfserrechnung, wie skaliere ich echte Kerne auf vCPUs, bzw. RDS, gerne nehme ich hier auch einen Link zu einer guten Quelle. Achja...
3.) Wie sieht es denn mit Netzwerk aus? Reicht ein Bonding aus mehreren (aktuell 3) 1 Gbit NICs überhaupt noch aus? RDP waren ca. 128kbit/s, wenn ich recht in Erinnerung habe, oder?
Ich werde parallel dazu eine unserer Workstations testweise mit der Evaluationsversion von Server 2019 ausstatten und einfach mal testen, so könnte ich zumindest die Frage zum Access 1 Kern
Problem beantworten - tja manches kommt einem erst beim Schreiben in den Kopf .
Gruß Sascha
ich befinde mich aktuell in der Machbarkeitsstudie zu einer Lösung mit RDS oder VDI.
Ich habe diesen Thread dazu gelesen, aber zur eigentlichen Frage nicht wirklich viele Informationen daraus ziehen können .
Benötigte Hardware für schnelle VDI Lösung
Folgende Situation : CRM/ERP System, auf Basis von alter Access Version, soll nicht ersetzt werden (bitte respektiert das einfach). Aufgrund von Performanceproblemen die sich
mit Windows 10 1803 eigeschlichen haben (SMB Caching Probleme bei Netzwerkbetrieb, ) soll nun das Netzwerk als limitierender Faktor beseitigt werden.
Da Access mit lokalem Backend recht zügig unterwegs ist, gilt es nun "DIE" Lösung zu finden.
Generell würde ich eher zu einem RDS tendieren, da ich im Grunde nur das CRM/ERP darüber "virtualisieren" möchte. Am Client-PC nutzt die Access Runtime grundsätzlich nur 1 Kern, und das recht intensiv. Nun habe ich Sorge, dass dies auf dem Server nicht anders wäre, was ja bei ~ 50 Nutzern einen GAU bedeutetn würde.
1.) Habt Ihr da Erfahrungen mit bockigen Anwendungen? Ist der Threadhandler von WindowsServer in der Lage, dass vernünftig zu verteilen?
Die nächste Frage betrifft dann ja die Dimensionierung des Systems. Da habe ich keine Erfahrungen drin, habe mich nur etwas belesen. Ich gehe also von 50 Clients mit je 4 Kernen und 4 GB RAM aus. RAM kann ich somit ganz gut selber berechnen, wenns um den VDI geht, aber wie ist es bei RDS?
2.) Wie berechne ich den CPU Bedarf korrekt bei RDS/VDI? Stichwort overprovisioning
Als Platten dachte ich an SSDs im RAID 10 und ein RAID1 NVMe Verbund als "Backend-Pool". Prinzipiell wird sicher eher ein Workstation/Enthusiastensystem als Grundlage dienen müssen, da KMUs i.d.R. kein Geld für IT ausgeben. Auch das spiegelt nicht meine Überzeugung, sondern nur den Rahmen meiner Möglichkeiten, Bonbons zu drehen. Fix ist das aber noch nicht, da es noch zu früh dafür ist.
Die Grundfrage bleibt die Bedarfserrechnung, wie skaliere ich echte Kerne auf vCPUs, bzw. RDS, gerne nehme ich hier auch einen Link zu einer guten Quelle. Achja...
3.) Wie sieht es denn mit Netzwerk aus? Reicht ein Bonding aus mehreren (aktuell 3) 1 Gbit NICs überhaupt noch aus? RDP waren ca. 128kbit/s, wenn ich recht in Erinnerung habe, oder?
Ich werde parallel dazu eine unserer Workstations testweise mit der Evaluationsversion von Server 2019 ausstatten und einfach mal testen, so könnte ich zumindest die Frage zum Access 1 Kern
Problem beantworten - tja manches kommt einem erst beim Schreiben in den Kopf .
Gruß Sascha
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 591686
Url: https://administrator.de/contentid/591686
Ausgedruckt am: 22.11.2024 um 07:11 Uhr
3 Kommentare
Neuester Kommentar
1.) Habt Ihr da Erfahrungen mit bockigen Anwendungen? Ist der Threadhandler von WindowsServer in der Lage, dass vernünftig zu verteilen?
jaDie nächste Frage betrifft dann ja die Dimensionierung des Systems. Da habe ich keine Erfahrungen drin, habe mich nur etwas belesen. Ich gehe also von 50 Clients mit je 4 Kernen und 4 GB RAM aus. RAM kann ich somit ganz gut selber berechnen, wenns um den VDI geht, aber wie ist es bei RDS?
Ich habe hier jeweils 2 RDS Cluster mit 6 VM. Ein Cluster mit 60 Usern, Ein Cluster mit 140 Usern.2.) Wie berechne ich den CPU Bedarf korrekt bei RDS/VDI? Stichwort overprovisioning
Merke: Viel bringt nicht immer viel (bei VM). Es es besser du machst 4 RDS Host statt 2 Hosts. Denn wenn die Anwendung schlecht und in 32bit ist und immer nur 1 Kern nutzt, dann schißet deine CPU Last beim RDS Host ganz schnell nach oben. Wenn du aber 4 RDS Host virtualisierst, übernimmt der Hypervisor die Core Verteilung.Als Platten dachte ich an SSDs im RAID 10 und ein RAID1 NVMe Verbund als "Backend-Pool". Prinzipiell wird sicher eher ein Workstation/Enthusiastensystem als Grundlage dienen müssen, da KMUs i.d.R. kein Geld für IT ausgeben. Auch das spiegelt nicht meine Überzeugung, sondern nur den Rahmen meiner Möglichkeiten, Bonbons zu drehen. Fix ist das aber noch nicht, da es noch zu früh dafür ist.
Das Raid ist wofür? Für ein RDS Blech oder für einen Hypervisor?Muss es physisch sein? Nutzt ihr VM?
Die Grundfrage bleibt die Bedarfserrechnung, wie skaliere ich echte Kerne auf vCPUs, bzw. RDS, gerne nehme ich hier auch einen Link zu einer guten Quelle. Achja...
3.) Wie sieht es denn mit Netzwerk aus? Reicht ein Bonding aus mehreren (aktuell 3) 1 Gbit NICs überhaupt noch aus? RDP waren ca. 128kbit/s, wenn ich recht in Erinnerung habe, oder?
ich würd mir mal den Rest der Anwendung anschauen. Viele Anwendungen früher waren MS Access Runtimes mit einer VB GUI. Hab selbst so'n Ding betreut, nannte sich Sage KHK Officeline. Effektiv ging das schon auf NT4 und später Windows 2000 Termianlservern, aber von Microsoft gabs keine Freigabe für Access auf Termianlservern (ich meine bis heute nicht) und sollte die Anwendung da instabil werden oder jemand Bedenken hat, dann immer VDI. Einfach weil dort jeder Benutzer ein komplettes OS im Einzelbenutzer für sich hat und man sich da sicher sein kann, daß alle Applikationen da so weiterlaufen.
Im AWS ist VDI (in dem Fall würde ich Workspaces nehmen) auch bei kleinen Anwenderzahlen die deutlich günstigere Variante. Lokal im Rechenzentrum installiert gibt sich das nicht viel, weil z.B. Horizonview nicht ganz billig ist und seine eigenen Clientaccess-Lizenzen braucht.
ÜBrigens die Gschichte mit dem Fileshare ist seit einem halben Jahr gelöst, das war ein Bug für den es anfänglich einen Workaround gab in dem man irgendeinen "Share mode" verändert damit er wieder wie vorher geht. Der "new style" Share mode vom Server als auch Windows 10 hatte bei uns zu korrupten MDB Dateien geführt.
Im AWS ist VDI (in dem Fall würde ich Workspaces nehmen) auch bei kleinen Anwenderzahlen die deutlich günstigere Variante. Lokal im Rechenzentrum installiert gibt sich das nicht viel, weil z.B. Horizonview nicht ganz billig ist und seine eigenen Clientaccess-Lizenzen braucht.
ÜBrigens die Gschichte mit dem Fileshare ist seit einem halben Jahr gelöst, das war ein Bug für den es anfänglich einen Workaround gab in dem man irgendeinen "Share mode" verändert damit er wieder wie vorher geht. Der "new style" Share mode vom Server als auch Windows 10 hatte bei uns zu korrupten MDB Dateien geführt.