"Server" nur für MS SQL

[decepterX]

Hallo zusammen,
geplant ist ein neuer MS SQL 2012 der lediglich die Aufgabe hat eine ~ 7-8GB große DB zu verwalten.
64-128GB ecc Ram, SSDs (Intel 750 (nvme), ist dort ein Raid schon möglich?) und ein Xeon 8-Kerner sind ins Augabe gefasst. Es kam die Frage auf ob es überhaupt sinnvoll ist das dafür "Windows Server 2012" o.a aufgesetzt werden sollte. Die unzähligen Dienste die mitstarten und Ressourcen fressen werden auf der Maschine eh nicht benötigt. Hat jemand Erfahrung gemacht MS SQL einfach nur auf Windwos 10 zu betreiben? Oder besser gesagt: Was würde dagegen sprechen?

 

[Nachtwind]

Hallo zusammen,
geplant ist ein neuer MS SQL 2012 der lediglich die Aufgabe hat eine ~ 7-8GB große DB zu verwalten.
64-128GB ecc Ram, SSDs (Intel 750 (nvme), ist dort ein Raid schon möglich?) und ein Xeon 8-Kerner sind ins Augabe gefasst...

Respekt für die Ausstattung... da frage ich mich, wie viele User darauf zugreifen sollen und wie viele Schreib- und Lesezugriffe da so eine Ausstattung benötigen...

...Es kam die Frage auf ob es überhaupt sinnvoll ist das dafür "Windows Server 2012" o.a aufgesetzt werden sollte. Die unzähligen Dienste die mitstarten und Ressourcen fressen werden auf der Maschine eh nicht benötigt. Hat jemand Erfahrung gemacht MS SQL einfach nur auf Windwos 10 zu betreiben? Oder besser gesagt: Was würde dagegen sprechen?

...und dann frage ich mich erst recht, wie kommt man bei einer (vermuteten) Last, die eine solche Ausstattung benötigt, auf die Idee, ein Desktop-Betriebssystem einzusetzen?
Server-Software unterscheidet sich ja nicht umsonst von den Desktop-Systemen. Angefangen von Routinen zur "Säuberung" des Arbeitsspeichers über durchaus sinnvolle Integration einiger Dienste bis hin zur Härtbarkeit eines Servers im Gegensatz zu einem Desktop-OS...
Und beim nochmaligen Lesen frage ich mich wirklich erst recht - wer konzipiert sowas und denkt dann an Win 10?

 

[Eye-Q]

Serverhardware mit ECC und Enterprise-SSDs und ein Desktop-Betriebssystem zu kombinieren ist Blödsinn. Wie schon geschrieben gibt es nicht umsonst Server-Betriebssysteme. Wenn man keine Rollen (z.B. Hyper-V, DNS, DHCP, wasauchimmer) installiert, sind die entsprechenden Dienste auch nicht installiert und können deswegen natürlich auch nicht gestartet werden.

Des weiteren denke ich bei so einer Datenbankgröße eher an ein Firmen-System, und da mit selbstgebastelten Systemen ohne Support anzukommen ist fahrlässig - was ist, wenn das Mainboard kaputt geht? Bei einem Markensystem bekommst Du garantiert ein baugleiches als Ersatz, bei selbstgebastelten Systemen kann es sein, dass das Board oder den RAID-Controller in ein, zwei Jahren nicht mehr erhältlich ist und man dann 'ne lange Nase macht.

 

[fax668]

Nur so nebenbei, auf RAID kann man eigentlich verzichten, wenn man die Verfügbarkeit nicht braucht. Und die Verfügbarkeit kann man bei NVMe sowieso vergessen, weil sich die "Laufwerke" nicht im laufenden Betrieb tauschen lassen. Jedenfalls sollte die Maschine ja keine Probleme haben, die komplette DB mit Indexen im RAM vorzuhalten.

Und Windows 10 nimmt man schon allein deshalb nicht, weil man haufenweise CALs braucht.

 

[fdsonne]

Es geht doch hier primär um Einsparen der Lizenzkosten?? Oder worauf zielt die Frage genau ab?

was liegen denn zwischen 2012 R2 und Win10 Prof oder Enterprise an Kosten? Das dürften um dei 400€ sein... Gemessen am Rest für die Lizenzen von einem SQL Standard + Hardware fällt das doch gar nicht wirklich ins gewicht.

https://support.microsoft.com/en-us/kb/2681562
-> grundsätzlich laufen wird es wohl, wenn man den Artikel folgt. Min. 2012 SP2 vom SQL läuft unter Win10.
Sinnvoll ist das aber nicht...

Jetzt noch auf SQL 2012 zu setzen, ist aus meiner Sicht auch nicht mehr sooo sinnvoll. Gerade bei einer Neuanschaffung von Hardware und Software. (oder ist die SQL Lizenz vorhanden??)
Mit SQL 2014 bspw. läuft nun auch das neuere ReFS Dateisystem der Server Betriebssysteme -> man bekommt also dort auch einen Vorteil ggü. dem Client OS ala Win10.

Weitere Dinge sind bspw. Connection Limits (dürfte doch bei Win10 effektiv auch bei 10 liegen??) und natürlich der unnütze Balast, den gerade Win10 als Client OS mitbringt (ne Aero GUI -> braucht man das im Server??) -> der SQL läuft auf auf der Core Installation (wenn der RS nicht notwendig ist)

Wenn man noch etwas wartet, wäre der 2016er mit der Nano Version noch eine Idee wert. Das spart nochmal massivst Ressourcen und auch Platz sowie Wartungsaufwand (Patch Installation, Reboots danach usw.) -> allerdings weis ich nicht, ob SQL 2014 SP2, also die neueste Version schon 2016 als Nano Install supportet!

Nur so nebenbei, auf RAID kann man eigentlich verzichten, wenn man die Verfügbarkeit nicht braucht. Und die Verfügbarkeit kann man bei NVMe sowieso vergessen, weil sich die "Laufwerke" nicht im laufenden Betrieb tauschen lassen. Jedenfalls sollte die Maschine ja keine Probleme haben, die komplette DB mit Indexen im RAM vorzuhalten.

Wieso sollte das nicht funktionieren?
http://www.intel.com/content/www/us/en/solid-state-drives/hot-plug-capability-nvme-ssds-paper.html
Intel schreibt zumindest, dass es supportet wird. Was spricht also dagegen? Auch unter Windows?
Die 750er ist allerdings nicht Datacenter Klasse -> die wird auch nicht im Dokument erwähnt

Und was meinst du was passiert, wenn man dem OS während der Fahrt das Storage für die DBs "klaut"? -> da nutzt dir die DB im RAM gar nix mehr... Das ding schmiert ab und dann ist Ende...

 

[fax668]

Wieso sollte das nicht funktionieren?
Hot-Plug Platform Capabilities for NVMe* and PCIe*-based SSDs
Intel schreibt zumindest, dass es supportet wird. Was spricht also dagegen? Auch unter Windows?
Die 750er ist allerdings nicht Datacenter Klasse -> die wird auch nicht im Dokument erwähnt

Ah, kannte ich nicht. Die Auswahl an Windows Versionen ist da aber auch auf 2012 Server auf extrem wenigen Hardwaresystemen beschränkt.

Und was meinst du was passiert, wenn man dem OS während der Fahrt das Storage für die DBs "klaut"? -> da nutzt dir die DB im RAM gar nix mehr... Das ding schmiert ab und dann ist Ende...

Ja, damit muss man sowieso rechnen und einen Backup und Disaster Recovery Plan haben, wenn das wirklich wichtige Daten sind, egal ob mit oder ohne RAID. Bei uns werden alle Daten in (quasi) Echtzeit repliziert und gespeichert wird sowieso nur auf physisch getrennt stehenden SANs, die laufen dann natürlich auch mit RAID.

 

[soulreaver]

erklärt mir mal kurz einer für Blöde, wozu ich bei ner 6-8GB großen DB 64-128GB RAM brauche? Bisschen overkill, wenn da nur diese eine "MiniDB" drauf läuft?

 

[fdsonne]

Jain... Kommt eher drauf an, was da für Durchsatz stattfindet.
Rein was Read angeht, dürfte die sinnvolle RAM Menge in etwa dem sein, wie groß die DB sein soll + Hintergrundsachen für das OS. Also keine Ahnung, 10-12GB, dazu kommen dann noch Mengenbedarf für die System DBs des SQL.

Bei Write sieht das unter Umständen anders aus... Je nachdem, wie das Ding konfiguriert ist bzw. wie viel Schreiblast da drauf kommt. Viele Write-Abfragen werden im RAM natürlich klar schnell(er) behandelt, als direkt in das Storage zu schreiben. RAM für Storage Caching ist dazu weit weit schneller als ne Enterprise SSD. -> kostet aber auch anständig RAM usw.
32-64GB RAM kann man da schon sinnvoll voll bekommen. 128GB? Neja, weis nicht so recht. Aber was man hat, das hat man (ich würde aber heute klar auch zu 32GB Riegeln gehen)

Ah, kannte ich nicht. Die Auswahl an Windows Versionen ist da aber auch auf 2012 Server auf extrem wenigen Hardwaresystemen beschränkt.

Jupp, hab das auch nur auf die schnelle gefunden. Keine Ahnung, ob da bei näherem Suchen noch andere Systeme im Support sind und wie das generell mit Stangen-Servern und NVMe Storage Support ausschaut. Müsste man sich halt direkt dann raussuchen...

Ja, damit muss man sowieso rechnen und einen Backup und Disaster Recovery Plan haben, wenn das wirklich wichtige Daten sind, egal ob mit oder ohne RAID. Bei uns werden alle Daten in (quasi) Echtzeit repliziert und gespeichert wird sowieso nur auf physisch getrennt stehenden SANs, die laufen dann natürlich auch mit RAID.

Das ist halt dann immer die Frage, ob man das in Echtzeit schafft oder nicht?
Möglicherweise sind andere Mittel zur Verfügbarkeitserhöhung sinnvoller als eine Storage Replizierung? Bspw. ein Clustering auf der Serviceebene + voll-redundantes (dann idR) externes Storage?
Das Problem bei Datenbankservern ist ja oftmals, dass eben schon unmittelbar nach dem Backup dieses wieder veraltet ist. Die Frage ist dann nur, wie dramatisch das wäre? Ne WaWi wo auf einmal ein paar Minuten oder Stunden von einem Tag fehlen weil außerhalb des Backup Zyklus? -> ne ziemlich beschissene Sache

Ich verfolge bei derartigen Themen, wenn möglich eher den Ansatz, das Konstrukt effektiv unkaputtbar zu machen. Zumindest ggü. höheren Einflüssen wie Hardwaredefekte oder dergleichem. Allerdings wirds dann schnell auch ziemlich teuer. (und so ne Frage nach Win Client vs. Win Server fällt so gar nicht mehr ins Gewicht)

 

[sandreas]

Vergiss nicht, dass Menge der physischen Datenträger eine entscheidende Rolle spielen kann. Wenn du nur einen Datenträger hast (Partitionen bringen auch nix), ist das, egal wie schnell der ist, für einen Datenbankserver nicht optimal, da er die Daten der TEMPDB, LOG und Daten selbst nicht parallel wegschreiben kann.

Ich empfehle mindestens 4 Datenträger, 1 für OS, 1 für LOG, 1 für Daten, 1 für TempDB
Wenn noch Kohle übrig ist, nimm noch einen für eine Secondary Filegroup, in der du die Index-Daten parkst

 

[sashXP]

Vergiss nicht, dass Menge der physischen Datenträger eine entscheidende Rolle spielen kann. Wenn du nur einen Datenträger hast (Partitionen bringen auch nix), ist das, egal wie schnell der ist, für einen Datenbankserver nicht optimal, da er die Daten der TEMPDB, LOG und Daten selbst nicht parallel wegschreiben kann.

Ich empfehle mindestens 4 Datenträger, 1 für OS, 1 für LOG, 1 für Daten, 1 für TempDB
Wenn noch Kohle übrig ist, nimm noch einen für eine Secondary Filegroup, in der du die Index-Daten parkst

Der Tipp ist goldrichtig! Unabhängig davon läuft der SQL Server nicht auf Windows 10 (nur die Developer Edt.) - alle anderen Edt. benötigt ein Server OS.

 

[Luckysh0t]

Der Tipp ist goldrichtig! Unabhängig davon läuft der SQL Server nicht auf Windows 10 (nur die Developer Edt.) - alle anderen Edt. benötigt ein Server OS.

Also mein 2014 Express läuft zu Testzwecken auch auf meiner Windows 10 Maschine auf der Arbeit. Oder funktioniert das nur mit den Express Versionen ?

 

[testm]

@Luckysh0t: MS SQL Server 2014 Standard läuft ebenfalls auf normalen Client-OS's (siehe hier) wenn es den gewünscht ist. Nur sinnvoll ist es eben nur bedingt, wie es schon erläutert wurde.

 

[sashXP]

@Luckysh0t: MS SQL Server 2014 Standard läuft ebenfalls auf normalen Client-OS's (siehe hier) wenn es den gewünscht ist. Nur sinnvoll ist es eben nur bedingt, wie es schon erläutert wurde.

Danke! Das wusste ich tatsächlich nicht - wieder etwas dazu gelernt!

 

[ThomasH]

Schon merkwüdig, dass hier niemand die Frage stellt, ob ein OLTP, DWH oder OLAP System geplant ist.
Welches Middleware eingesetzt wird usw ..
Wie ist die temp-DB Nutzung
Wieviele Transkationen/Sek. ablaufen ..
usw.

Wie auch immer, für eine 8GB DB (selbige würde ich nicht unbedingt als klein bezeichen), sollten 4GB für das OS und 16GB RAM für den SQL Server komplett ausreichen. Da kann man die Tabellen ab MSSQL2k14 komplett in den RAM pinnen.
Bei einfachen Systemen legt man die DBs auf ein RAID10 und das Transaktionslog auf RAID1.
Dort reichen normale SAS HDDs mit 10 bis 15Tsd RPM.

Der MSSQL kommt auf einen normalen Memberserver (da laufen nur die notwendigen Dienste). DC ist nicht supportet.
Und wenn Du weniger Dienste benötigst, nimm eine Server Core Version oder evtl klappt auch schon der Nano Server ..

HV erfordert dann schon wenigstens 2 Server mittels Clustering, AlwaysOn, Mirroring oder Logshipping und am besten ein gespiegeltes SAN.

Ich habe beruflich als Programmierer mit Ora/MSSQL-Systemen zu tun und muss sagen, ein so prall ausgestattetes System ist mir für eine 8GB DB noch nicht unter die Augen gekommen

Übrigens konnte man schon seit MSSQL Server 4.21 alles auf einer NT Workstation (so hießen die Dinger in den 90ern) installieren.



Wenn man kostenneutral testen möchte, kann man dass mittels MSSQL Developer Edition tun, die seit 2k14 kostenlos ist. Die 2k12 kostete so um die 70€. Diese Versionen haben die Funktionalitäten der Enterprise Version dürfen aber nicht in der Produktion verwendet werden.

Es gibt auch noch die Express-Versionen. Die 2014er ist glaube ich auf 10GB DB max festgelegt und kann nur 1GB RAM je Instanz und es gibt keinen MSSQL Agent, was sich aber alles per TSQL und Aufgabenplanung erledigen läßt ...