Server 2019 Hardware Sizing

[Wolle68 0]

Hallo Zusammen,

 

würde euch gerne mal um eure Meinung/Erfahrung fragen zur Hardwareausstattung von Server 2019

 

Wir haben an einem Standort folgende Hardwareserver, die wir aber jetzt mit Server 2019 virtualisieren möchten. 

 

Windows Server 2016 DC (dieser ist der PDC und macht auch DHCP)

Windows Server 2016 Fileserver (per DFS im Sync mit einem Server an einem anderen Standort)

Windows Server 2012 (Zertifikatsserver, soll aber auch dann Server 2019 werden)

 

Wir haben ca 250 Mitarbeiter, heisst, unsere Serverauslastung ist sehr gering, auch die der Fileserver

 

Wie würdet ihr die VM's ausstatten in Bezug auf RAM und CPU?

 

Reichen 8GB für den DC und den Zertifikatsserver?

und 32 GB für den Fileserver?

 

 

[NilsK 2.939]

Moin,

 

wenn ihr mit Server 2019 virtualisieren wollt, braucht ihr die 2019-Lizenzen in passender Zahl für all eure VMs, egal, was die ausführen.

 

Euer DC ist kein PDC, das gibt es im AD nicht. Allenfalls ist er PDC-Emulator, aber das ist in den meisten Situationen egal. 

Wichtiger ist: Das ist hoffentlich nicht euer einziger DC bei 250 Usern?

 

Für die RAM-Ausstattung kann man per Ferndiagnose wenig Sinnvolles sagen - außer dass in kleinen Umgebungen 8 GB für einen DC oder eine CA meist zu üppig sind, 4 GB reichen da normalerweise völlig aus. Beim Fileserver kommt es auf die Last an. Wenn die wirklich gering ist, wird der keine 32 GB brauchen. 

 

Gruß, Nils

 

[Wolle68 0]

vor 15 Minuten schrieb NilsK:

Moin,

 

wenn ihr mit Server 2019 virtualisieren wollt, braucht ihr die 2019-Lizenzen in passender Zahl für all eure VMs, egal, was die ausführen.

 

Euer DC ist kein PDC, das gibt es im AD nicht. Allenfalls ist er PDC-Emulator, aber das ist in den meisten Situationen egal. 

Wichtiger ist: Das ist hoffentlich nicht euer einziger DC bei 250 Usern?

 

Hi Nils,

 

danke erst einmal

 

Klar, Lizenzen ist klar und kein Problem

Ja, meinte auch den PDC Emulator.

Nein, wir haben 4 DC's, an jedem Standort zwei

 

vor 16 Minuten schrieb NilsK:

 

Für die RAM-Ausstattung kann man per Ferndiagnose wenig Sinnvolles sagen - außer dass in kleinen Umgebungen 8 GB für einen DC oder eine CA meist zu üppig sind, 4 GB reichen da normalerweise völlig aus. Beim Fileserver kommt es auf die Last an. Wenn die wirklich gering ist, wird der keine 32 GB brauchen. 

 

Gruß, Nils

 

Ok, dann würde ich mal mit 8GB für DC und CA rechnen und 16Gb für den Fileserver

 

hast du auch einen Ansatz für die CPU'en?

 

[NilsK 2.939]

Moin,

 

es gibt da ein Buch bei Rheinwerk, zwar für 2016, aber gerade in diesen Basics immer noch zutreffend. Das ist da sehr umfassend beleuchtet. Ist als E-Book oder gebraucht noch erhältlich.*

 

Bei den CPUs: Klein anfangen, dann beobachten. Ein DC und eine CA brauchen in so einer Umgebung mit großer Sicherheit nicht mehr als eine vCPU. Ein Dateiserver vielleicht zwei, vielleicht vier (z.B. für einen Virenscanner).

 

[Hyper-V-Sizing: Virtuelle und echte CPUs | faq-o-matic.net]
https://www.faq-o-matic.net/2011/01/26/hyper-v-sizing-virtuelle-und-echte-cpus/

 

[Wie viele Cores braucht mein VM-Host? | faq-o-matic.net]
https://www.faq-o-matic.net/2019/10/22/wie-viele-cores-braucht-mein-vm-host/

 

Gruß, Nils

* Disclaimer: Ja, ich bin einer der Autoren, aber da das Buch nicht mehr regulär erhältlich ist, verdiene ich an der Empfehlung nichts mehr.

[v-rtc 88]

Völlig wurscht, davon profitieren wir alle ✌️ Danke 

[Wolle68 0]

@NilsK

Danke für die Info 

[Weingeist 159]

Fileserver RAM-Bedarf kann man pauschal nicht beantworten. Mit Spielereien wie Dedupe, Kompression, Read Cache etc. kann der Bedarf doch auch etwas grösser ausfallen als man annehmen würde. Bzw. hilft es der Performance ungemein wenn mehr vorhanden ist. Im Grunde gebe ich abe Recht, normal sind 8GB mehr als genug.

 

Bezüglich CPU ist es beim Fileserver vor allem eine Frage des darunterliegenden Storage. Ist das Storage potent genug und die Netzwerkanbindung ebenfalls in Richtung 10Gbit, dann wird auch eine vCPU von 3.5GHZ problemlos ausgelastet wenn man die User die Performance abrufen lässt. Die Performance skaliert dann 1:1 mit der CPU-Leistung. Gleiches gilt bei Dedupe und anderen Storage-Funktionen.

 

Ansonsten muss man mittlerweile schon ziemlich viel Telemetrie abdrehen wenn man möchte, dass das OS easy durchgängig bedienbar bleit mir nur einer vCPU. Trifft bei Core-Versionen möglicherweise nicht gleichermassen zu, aber bei der Mitinstallation der GUI tut man sich bei >2012R2 eigentlich keinen Gefallen mehr. Spätestens wenn Updates eingespielt werden *schulterzuck*

Aber eben, ist alles Geschmacksache. Ich persönlich teile bei jedem OS über 2012R2 zwei zu. Auch mit grosszügig abgedrehter Telemetrie. Insbesondere wegen der Updaterei die viel schneller abläuft. Aber meine Hosts sind CPU technisch meistens auch nicht wirklich ausgelastet.

 

 

Hach und das mit dem PDC, eigentlich ist der DC mit der PDC-Emulator Rolle doch immer noch PDC. Zwar nicht auf die Datenbank bezogen, sondern nur auf seine Funktion, aber ohne ihn läuft doch eine beachtliche Menge wichtiger Kram einfach mal nicht oder nicht mehr korrekt bevor die Rolle nicht manuell weitergegeben wird bei einem Ausfall. Insofern ist er funktionell gesehen immer noch PDC und nur im Sinne der DB nicht mehr. Aber ist nur meine Meinung...

 

Genau das Denken, dass PDC doch heute nicht mehr relevant ist bzw. er nicht mehr existiert (en soll), ist der Konfigurations-Fehler Nummer 1 für z.Bsp. DFS-Ziele. Also der DC mit PDC-Emulator Rolle auf dem gleichen physischen Host wie der Filer mit dem ersten, zwecks möglichen Replikationsproblemen möglicherweise einzigen aktiven DFS-Ordner-Ziel. Die Änderungen an DFS laufen auch heute noch ausschliesslich über den PDC oder von mir aus den DC mit der aktiven PDC-Emulator-rolle. Sprich ein simples Wechsel eines aktiven Ordnerziels ist essig. Das vorhandensein mehrere DC's und mehrere DFS-Ziele bringt dann nix, weil das DFS-Ziel nicht mit ein paar Mausklicks umgeschaltet werden kann. Es braucht einen User mit sehr hohen Berechtigungen um erstmal die DC-Rolle zu verschieben. Was man möglicherweise auch nicht unbedingt möchte bevor nicht sicher ist, ob der erste zurück kommt.