Neu Datenbank Vorbereitung

[garifulin]

Guten Tag beisammen,

aus diversen Gründen muss ich den SQL Server bei uns in der Firma neu aufsetzen.
Da wollte ich um Empfehlungen bitten.
Voraussichtlich wird ein ESXi Client mit 8 bzw 10 CPU Kerne ( da ich irgendwo gelesen hatte dass die WAWI nicht mehr wie 8 Kerne nutzt)
32 GB RAM (hier bin ich nicht sicher ob das nicht zu viel ist)
1x SSD RAID für Windows 2016 & SQL-Server 2017 Standard [120GB?]
1x SSD RAID für Datenbank (64k Formatierung) [300GB]
1x 1GB Nic (für WAWI und co Verbindungen)
8x 1GB Große tempdb´s (pro CPU 1 tempdb)
1x Täglich Vollbackup
alle 15 min ein DiffBackup
1x Täglich DiffBackups aufräumen
1x Wöchentlich Vollbackup´s Aufräumen

das einzige was auf dem Server mit laufen soll ist der Worker als Dienst.

Im Einsatz haben wir die JTL Wawi 1.5.55.6 und Packtisch+
Onlineshops sind Shopware und Woocommerce

so habe ich noch etwas vergessen?
und
Habt ihr schon empfehlungen?
Vor allem im Hinblick auf die 1.7 version, hat sich da etwas geändert?


Grüsse euer gari

 

[SebastianB]

Hi,

die Anzahl der Kerne, die der SQL-Server nutzt hat nichts mit der Wawi zu tun. Wir haben auch Händler, die SQL-Server mit 32 Kernen betreiben.

Davon abgesehen kann man wenig Empfehlungen geben, wenn man den Anwendungszweck nicht kennt. Das bleiben halt nur grundsätzliche Gedanken:
* Zu viel RAM gibt es nicht. Erst Recht nicht wenn Worker und SQL-Server auf einer Kiste laufen sollen (was eine Herausforderung ist wenn man das sauber konfigurieren möchte): Alleine der Worker kann sich, es schlecht läuft, 10 GB RAM ziehen. Der SQL-Server hätte am liebsten gerne DB-Größe mal 2.5 - sprich: Bei einer 20GB Datenbank würde ich überschlagen: 10 GB für den Worker + 50GB für den SQL-Server - also 64GB RAM. Je mehr der SQL-Server im RAM halten kann, desto weniger braucht er die (im Vergleich zum RAM langsame) SSD.
* Ich würde heute keinen SQL Standard 2017 mehr aufsetzen - für den gibt es keine Bugfixes mehr von Microsoft, und nein, deshalb ist das Ding nicht magisch bug-frei. 2019 oder 2022 ist hier the-way-to-go
* Die Backup-Strategie passt in meinen Augen nicht zum Rest - wenn man so groß plant, kommt man in meinen Augen am Logbackup nicht vorbei
* Der Worker kann out-of-the-box in der 1.5 nicht als Dienst laufen, das kann erst der Worker 2.0 ab JTL-Wawi 1.6

 

[garifulin]

@SebastianB wow danke schon mal für die ausführliche Aufstellung.
arbeite mich mal kurz rückwerts durch.
*Den Worker haben wir derzeit mit nssm als Dienst laufen (1.7 ist die Ziel version 1.6 wollen wir überspringen)
*Logbackup habe ich derzeit noch nicht implementiert (erst nur angeschaut, umsetznung steht noch aus )
*SQL Standard 2017 Lizenzen habe ich da, 2022 nicht und bekomme ich derzeit auch noch nicht genehmigt (versuche es nächstes Jahr durchzuboxen)
* Thema RAM ist bei mir halt eben das Schmerzthema denn derzeit frisst der SQL ziemlich genau das vierfache was das Backup an größe hat und deswegen möchte ich das ein Stückweit begrenzen.

der Grund für mein handling ist in der tat der dass ich den derzeitigen (physikalischen) Server einer anderen Aufgabe zuführen möchte und da nicht unendlich Ressourcen vorhanden sind, möchte ich die "Neue Kiste" explizit der Aufgabe SQL-Server für die Wawi zuordnen und nicht all zu überdimensioniert gestalten. Höchsten mit reserven für die nächsten 2 bis 3 Jahre 😆.

aber so wie ich es Verstehe ist die zusammenstellung an sich nicht ganz verkehrt?

 

[mh1]

10 Kerne? 64 GB? ... gibt also was Größeres vermute ich mal. Da ist dann wahrscheinlich auch viel Last auf dem SQL-Server. Da würde ich von den Diff Backups im 15 min. Intervall abraten. Besser wäre meiner Ansicht: Ein mal wöchentlich (nachts) Full, einmal täglich (nachts) Differentiell. Stündlich Log Backup.

* Thema RAM ist bei mir halt eben das Schmerzthema denn derzeit frisst der SQL ziemlich genau das vierfache was das Backup an größe hat und deswegen möchte ich das ein Stückweit begrenzen.

Was meinst du mit "er frisst"?
Grundsätzlich soll er doch möglichst den gesamten RAM nutzen, den du ihm zur Verfügung stellst. Also wenn du ihm 64 GB gibst, soll er ja auch 64G nutzen. Ist es das, was du dann mit fressen bezeichnest?

In dem genannten 64 GB Beispiel musst du aber auch noch zusätzlich an dein Betriebssystem denken.
Gerade Windows Server freut sich ja auch über das ein oder andere GB...