Welche Hardware ist für Dynamics NAV 2009 R2 notwendig?

Hallo zusammen,

wir haben aktuell noch das Navision 2.0 im Einsatz. Wollen jetzt dann einen Schnitt machen und auf Dynamics NAV 2009 R2 umsteigen.

Welche zusätzliche Hardware würdet ihr zu unserer vorhandenen Hardware empfehlen?
Aktuell haben wir 30 Navision User, Hardware sollte auch für ca. 40 User ausreichend sein.

Aktuelle Hardware:
2 physikalische Server mit jeweils:

2x Xeon 5650 (6x @2,66Ghz)
64GB RAM

Storage: 16x 450GB SAS 10k @ RAID 6:
1x iSCSI SAN mit noch ca. 1TB freiem Platz.

Die zwei physikalischen Server werden als ESXi betrieben.

Das non plus ultra wäre sicherlich ein High-Speed-Storage (SAS 15k Platten @ RAID 10) mit einem (zwei? wegen Ausfallsicherheit) physikalischen SQL-Server anzuschaffen? Aber wie notwendig ist das?
Danke schon mal für Eure Hilfe,

MfG Fazez

Hallo,

eure Maschine ist schon ganz ordentlich dimensioniert. Den einzigen Flaschenhals den ich im Moment sehe, ist das iSCSI, dass wenn es mit 1Gvit/s- Netzwerkkarten betrieben wird.
Ansonsten kommt es sehr auf die Konfiguration des Systems an, was du in sehr vielen Beiträgen hier im Form nachlesen kannst. Z.B. hier.

Gruß, Fiddi

Hallo Fiddi,

der Controller am Storage ist mit 2x 1Gbit/s (mit LoadBalancing) angebunden. Meine Switches bevorzugen iSCSI-Traffic, und die physikalischen Server haben jeweils 3 Ports mit 1GBit/s nur für iSCSI-Traffic reserviert.

Habe mir mal ein Testsystem aufgesetzt und mit SQLIO.exe ein paar performancetests gemacht. Die höchsten Antwortzeiten hatte ich hierbei:

C:\Program Files (x86)\SQLIO>sqlio -kW -s360 -frandom -o8 -b256 -LS -Fparam.txt

sqlio v1.5.SG
using system counter for latency timings, 14318180 counts per second
parameter file used: param.txt
file c:\testfile.dat with 2 threads (0-1) using mask 0x0 (0)
2 threads writing for 360 secs to file c:\testfile.dat
using 256KB random IOs
enabling multiple I/Os per thread with 8 outstanding
using specified size: 100 MB for file: c:\testfile.dat
initialization done
CUMULATIVE DATA:
throughput metrics:
IOs/sec: 610.80
MBs/sec: 152.70
latency metrics:
Min_Latency(ms): 1
Avg_Latency(ms): 25
Max_Latency(ms): 1812
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 0 0 0 3 8 14 15 12 7 4 3 2 2 2 2 1 1 1 1 1 1 1 1 1 17


1812ms bei 17% sind doch vertretbar bei einem Durchsatz von 152MB/s und 610 IOs/s?? Das bekommen doch 40 Standardanwender kaum hin oder?
Oder versteh ich das Log falsch?

MfG Fazez

Wie groß ist denn der Cache vom SAN?

Dein Test sollte schon dafür sorgen, dass das SAN das ganze nicht aus dem Cache bedienen kann. Außerdem musst du beachten das du später weitere Maschinen hast, die zusätzlich den Bus beanspruchen.

Merken wirst du das ganze erst, wenn du in NAV viele Posten hast, und du darüber Auswertungen oder z.B. die Lagerregulierung fährst, weil diese Aktionen große Datenmengen bewegen, und den Flaschenhals auch tatsächlich provozieren. Deine Maschine sollte dann aber auch die SQL-Server- Dateien richtig auf SAN- Volumes verteilen, die entsprechend angesteuert werden(Stryk hat dazu etwas in dem oben angeführten Beitrag geschrieben.)


Gruß, Fiddi

Hallo Fiddi,

laut technischer Spezifikationen hat das Storage 8GB Cache.
Wie kann ich das Storage zwingen, die Daten nicht aus dem Cache bereit zu stellen?

Wenn Du sagst, dass ich das erst später merke, wenn ich größere Abfragen mache: Gibts irgendwo eine schöne größe Demo-Datenbank oder kann ich die mitgelieferte Demo-Datenbank ohne viel Mühe "aufblasen", dass ich einigermaßer realitätsnahe Daten bekomme?

Von dem was Styrk schreibt sollte es bei mir (meiner Meinung nach) passen:
- 8 CPUs (wenn ich die sqlio.exe ausführe habe ich im Schnitt ca. 18% CPU Auslastung)
- 12GB RAM (Kapazität bis 24GB vorhanden)
- Habe eine LUN am Server eingebunden (LUN bei SAN Systemen sind OK, wenn das SAN richtig dimensioniert und konfiguriert ist)
- "MAX. Degree of Parallelism = 4 (Hälfte der CPUs)

Danke,

MfG Fazez

laut technischer Spezifikationen hat das Storage 8GB Cache.
Wie kann ich das Storage zwingen, die Daten nicht aus dem Cache bereit zu stellen?

Ganz pragmatisch: Einfach so viel Daten durchschaufeln, dass die 8 GB Grenze geknackt wird. Oder aber die Grenze einfach runterdrehen.

Große Demo-Datenbanken gibts nicht. Warum nimmst du nicht eine Sicherung deiner Echt-Datenbank? Wenn du da dann viele Transaktionen automatisiert zu Testzwecken laufen lassen willst, um den Durchsatz zu prüfen könntest du dir ja mal das Navision Benchmark Tool angucken.

Aktuelle Hardware:
2 physikalische Server mit jeweils:

2x Xeon 5650 (6x @2,66Ghz)
64GB RAM

Storage: 16x 450GB SAS 10k @ RAID 6:
1x iSCSI SAN mit noch ca. 1TB freiem Platz.

Ich wollte hierzu nur nochmal nachfragen: Der SQL-Server soll in den freien Platz (1 TB)? Da hätte ich echte Performancebedenken weil da ja offensichtlich jede Menge andere Daten mit vermutlich auch nicht wenigen Zugriffe mit drauf liegen und es bleibt das Problem dass das SQL-Log nicht auf einer eigenen HDD liegt. Oder habe ich das falch verstanden?

Volker

Hallo Sebastian,

das bedeutet dass ich bei der sqlio.exe das .Dat-File von 100MB auf mind 8gb vergrößern soll? Auf dem Storage finde ich keine Einstellung mit der ich den Chache verkleinern könnte. Das ist scheinbar ein fest verbauter flash speicher....

Wir haben aktuell das navision 2.0 im Einsatz. Die Datenbank wird mir nicht viel bringen. Vom Dynamics NAV 2009 R2 hab ich nur den Datenträger mit der Demo-Datenbank.
Das Navision Benchmark Tool werd ich mir mal googlen.

Danke,

MfG Fazez

Hallo Volker,

das will ich ja genau testen, ob ich eine für uns ausreichende Performance über das vorhandene Storage herbekomme (Dort laufen auch andere zugriffe drauf). Wenn nicht wird ein neues Angeschafft :)

Von Stryk:

Eine physikailsche Trennung von Daten und Log ist bei physilkalischen Laufwerken ein "must have".

Ich verwende ja eine LUN, da ist das glaube ich egal? Wenn ich ne extra LUN für die Logs einbinde, wird ja auf das gleiche Storage zugegriffen...

MfG Fazez

Wenn ich ne extra LUN für die Logs einbinde, wird ja auf das gleiche Storage zugegriffen...

Schon richtig, du kannst aber hinter einer LUN eine bestimmte physikalische Konfiguration verbergen, ähnlich einer physikalischen Platte.

Gruß, Fiddi