Zum Inhalt wechseln


Foto

Hardware für virtualisierten ERP-SQL-Server 2014 mit ~150 GB


  • Bitte melde dich an um zu Antworten
4 Antworten in diesem Thema

#1 basstscho

basstscho

    Member

  • 310 Beiträge

 

Geschrieben 12. September 2016 - 18:07

Hallo zusammen,

 

wir benötigen für unser neues ERP einen Microsoft SQL Server 2014 Standard. Da ich sowieso gerade plane einen alten Server zu tauschen, würde ich diesen u.U. schon ideal für den SQL-Server ausstatten.

 

Folgendes ist geplant:

- Der Windows Server 2012 R2 soll (wie auch alle anderen) über ESXi virtualisiert werden.

- Es wird entweder eine Core-Lizenzierung (2x2) oder eine per CAL (ist noch nicht entschieden).

- Datenbank aktuell ~50 GB (kein SQL), bis zum Ende der Serverlaufzeit vermutlich ~150 GB

- Der Server wird bis auf zwei kleine Nebenapplikationen unter Linux (2 zusätzliche VMs) ausschließlich für die SQL-Datenbank verwendet.

 

Für folgende Fragen zur Ausstattung würde ich gerne eure Meinung hören:

- CPU: Ist es sinnvoller eine CPU mit 6x3.6 Ghz (E5-1650V4) oder eine mit 10x 2.2 Ghz (E5-2630V4) zu verwenden? Macht es speziell vor dem Hintergrund einer Core-Lizenzierung sinn möglichst viel "Rechenleistung" in einem Core zu haben? Laut CPU Benchmark liegen die CPUs in etwa gleich auf und kosten auch ähnlich; stromsparender ist die 10x2.2 Ghz-Variante (140 vs. 85 W).

- Arbeitsspeicher: Nach meinen Recherchen würden für die SQL Server VM ca. 20-30 GB ausreichen - bringt mehr etwas? Arbeitsspeicher kostet ja fast nichts mehr. Der Host ist aktuell mit 64GB geplant.

- Speicher: Hardware-Raid-Controller mit 1GB Cache und BBU. Nun die große Frage: SSDs im Raid 1 oder HDDs im Raid 10? Hierzu gibt es im Internet jede Menge unterschiedliche Aussagen und Tests. Was ist eure Erfahrung? Gleicht viel RAM und Cache die Unterschiede zwischen SSD und HDD aus? Auf Grund der kleinen Datenbankgröße würde ich lediglich 2x 480 GB SSDs verbauen - die Kosten der bei meinem Ausstatter wählbaren Toshiba HK4R halten sich somit in Grenzen. OS würde dann auf einem weiteren HDD Raid 1 liegen. Ich gehe nicht davon aus, dass die Lebenszeit (wie vielfach geschrieben wird) bei Server SSDs wesentlich kürzer ist.

 

Natürlich werde ich alles nochmals mit dem Techniker des Softwarehauses unseres ERPs durchgehen. Aber etwas Vorahnung schadet nie.

 

Besten Dank für die Unterstützung,

Johannes



#2 Jim di Griz

Jim di Griz

    Board Veteran

  • 810 Beiträge

 

Geschrieben 12. September 2016 - 20:13

Hallo,

der cpu-interne cache ist bei der 10-Kerner CPU wohl kleiner, erfuhr ich als ich muendlich dazu mal mit einem systemhaeusler sprach.

Bin nicht sicher inwieweit das sql beeinflusst.

Seine Aussage war auch, das die Kerne bei Virtualisierung kaum interessieren, Speicher und Netz sind interessanter. Abhängig vom Virtualisierer.

ich wuerde heute nur noch ssds nutzen, sowohl fürs OS als auch für Daten.

Platten sind mechanisch und belasten strom und Ventilation.

Ob viel RAM und Cache die IOPS jemals wird ausgleichen können? ich habe Zweifel.

Inzwischen ist doch die naechste Stufe am Horizont, nicht-flüchtiger Speicher.


2152 MCP 2000 Server, 70-410, 70-411, 70-412, 70-413, 70-414, 70-

Lizenzen : vse msdn abo


#3 Dunkelmann

Dunkelmann

    Expert Member

  • 1.860 Beiträge

 

Geschrieben 13. September 2016 - 06:37

Moin,

 

zur CPU: Hier hängt es von der Datenbank bzw. den Prozeduren ab. Einige profitieren von hoher Taktung andere benötigen mehr Threads. Das sollte der Softwarehersteller / -lieferant beantworten können.

Hier würde ich auch eine künftige Migration auf Server 2016 berücksichtigen. Da wird (voraussichtlich) das OS auch nach Kernen lizenziert.

 

RAM: Bei SQL ist ausreichend RAM selten verkehrt.

 

HDD/SSD: Bei kleinen Datenbanken würde ich zu SSD raten. Du hast ja schon festgestellt, dass es sich beim Preis nicht viel nimmt.

Die Lebensdauer der SSD sollte egal sein, wenn man den Server mit entsprechenden Supportlevel betreibt. Bei Ausfall bzw. predicted failure gibt es eine neue und fertig.

 

Generell würde ich beim Sizing auf eine Reserve für künftige Migrationen achten.


Keep It Small - Keep It Simple


#4 NilsK

NilsK

    Expert Member

  • 11.665 Beiträge

 

Geschrieben 13. September 2016 - 06:51

Moin,

 

bei einem SQL Server kann man solche Fragen ohne aussagefähige Testergebnisse nicht sinnvoll beantworten. Erfahrungsgemäß wird eine Nachfrage beim Herstelelr der ERP-Software nicht viel bringen - die raten meist zu "viel hilft viel". Trotzdem würde ich eine solche Abfrage machen, ggf. auch parallel bei dem Beratungshaus, das Implementierung und Customizing macht.

 

Dass Cores bei Virtualisierung egal seien, ist so nicht richtig. Richtig ist, dass moderne CPUs ausgesprochen selten den Flaschenhals darstellen. In deinem Szenario dürftest du mit der CPU-Leistung in der Tat kaum ein Problem haben. Viel wichtiger ist, dass der SQL Server sinnvoll konfiguriert wird und die Datenbank und die Applikation sinnvoll arbeiten.

 

Die Frage nach dem Storage ist ebenso ohne Messergebnisse nicht sinnvoll zu beantworten. Es kann ein langsames HDD-System ausreichen, ebenso kann es sein, dass eine SSD an ihre Grenzen gerät. Für den Hypervisor selbst lohnt sich i.d.R. keine SSD, da reicht ein einfaches RAID-1 völlig aus. Gerade bei einem SQL Server sollte aber ein Blick auf die sinnvolle Storage-Konfig auch aus Sicht eines möglichen Recovery erfolgen. Stichwort: Trennung von Datenbank und Logs, das kann je nach Recovery-Szenario von Interesse sein.

 

EIne Betrachtung der geforderten Verfügbarkeit gab es schon? Ein Einzelhost reicht also aus?

 

Gruß, Nils


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#5 monstermania

monstermania

    Board Veteran

  • 1.134 Beiträge

 

Geschrieben 13. September 2016 - 13:12

Hallo zusammen,

 

wir benötigen für unser neues ERP einen Microsoft SQL Server 2014 Standard. Da ich sowieso gerade plane einen alten Server zu tauschen, würde ich diesen u.U. schon ideal für den SQL-Server ausstatten.

Evtl. wäre es sinnvoll die Bezeichnung des ERP zu nennen. Dann könnte ggf. Jemand der zufällig das gleiche System nutzt Erfahrungen aus der Praxis beisteuern!

 

Ich habe schon ERP gesehen, die fast die gesamte Workload auf dem Client erzeugt haben. Da nutzt es dann wenig einen möglichst fetten SQL hinzustellen...