Hardwareanforderung für Navision-Server

Hallo Community,

ich habe folgendes Problem: Ein Kunde von mir setzt momentan noch Navision 3.70.A mit einer Native-Datenbank ein.
Aufgrund eines fehlenden Wartungsvertrages wurde das ganze nie gewartet. Anfang nächsten Jahres soll nun endlich
ein Update auf die akutelle Version 2009 vom Microsoft Partner durchgeführt werden.

Jetzt ist die Frage, was sollte ich in Bezug auf einen neuen Server beachten?

Der momentane IST-Zustand beläuft sich auf folgende Konfiguration:

Intel QuadCore XEON E5520
4GB RAM
Microsoft Windows Server 2003 R2 Standard
1x RAID-1 Intel SSD-SLC (für System und Oracle Datenbank)
1x RAID-1 Intel SSD-SLC (eigene Partition für NAVISION)
1x SSD als Hotspare
Navision User: ca. 70 Personen

So wie das System jetzt aufgebaut ist, läuft auch alles rund und mit guter Performance.

Für den neuen Server ist soweit geplant:
Intel SixCore XEON E5670
3x8GB RAM
Microsoft Windows 2008 Server x64 Standard
bei der Festplattenkonfiguration bin ich nun nach langem Hin- und Her aber überfragt.
Ein Angebot von einer anderen Firma will die Konfiguration der SSD's übernehmen,
aber nachdem ich mir schon das Buch von Hrn. Stryk mal angeschaut habe, bin ich da etwas skeptisch
geworden. Grundsätzlich hätte ich Platz für 8x 2,5" Festplatten.

Ich hoffe Ihr könnt mir etwas helfen und mich ein wenig unterstützen, da ich auf dem Gebiet
noch Newbie bin...

Vielen Dank schon mal!

Zuletzt geändert von rose82 am 19. Oktober 2010 15:01, insgesamt 1-mal geändert.

Hallo Rose82,

herzlich Willkommen im Forum.

Zu deiner Frage eine Gegenfrage. Wie groß ist die NAV 3.7- Datenbank den gerade?
Ich gehe mal davon aus, das du das ganze auf SQL-Server umstellen willst. Eine andere Konfiguration macht auf Dauer keinen Sinn mehr. Solltest du doch weiter native verwenden wollen, reicht der jetzige Server aus.
Zu der Plattenkonfiguration ist Jörg sicherlich der richtige Ansprechpartner.
Ich persönlich würde eine Konfiguration aus RAID1 Platten empfehlen:

• 1 x RAID1 System >=146GB SAS ( bei dem Speicher gehen schon 24GB als Auslagerungsdatei weg, eine 73 GB ist dann schon fast voll)
• 1 x RAID1 SAS für Temp-DB (als SSD!?)
• 1 x RAID1 SAS für SQL-log
• 1 x RAID1 SAS für SQL- Daten

Das alles an einen SAS-Cache-Controller mit 512 MB-Cache angebunden.

Wenn es möglich ist, würde ich den Server lieber mit einem zweiten 8er- Käfig und einem zweiten Controller nur für die SQL-DB ausstatten.

Nicht empfehlen würde ich eine SAN- Anbindung, die nur über einen Kanal läuft. Man bedenke: moderne SAS- Platten werden mit bis zu 6GB/s an den Controller angebunden, und wenn man SSDs einsetzt, dann können die auch einen großen Teil dieser Bandbreite nutzen. Hat man nun nur einen Kanal zum SAN begrenzt dieser als Flaschenhals die Leistung des Plattensystems.

Vielen Dank schon mal für das Feedback.

Problem ist, das ich dann ja keine Platte mehr als Hotspare einsetzen kann,
falls wirklich mal ne SSD abschmiert...Dadurch das der Server auch nur 2HE's hat,
passt auch kein zweiter Kafig rein...

Hättte denn ein RAID dann noch etwas Performance übrig, für die Oracle Datenbank?

Bzw. macht sich bei SQL-Server die Geschwindigkeit durch SSD's auch bemerkbar, wie bei
der alten NATIV-Datenbank?

Nur zur Info: NAV 2009 setzt zwingend einen MS SQL-Server voraus.

Was die SSD bringt, hängt ein bisschen von der Konfiguration des SQL-Servers und der gewählten Server Edition ab, und natürlich von den Nutzern ab. Welchen Einfluss das tatsächlich hat, kannst du wahrscheinlich nur im Versuch heraus finden.

Ob man die TEMP-DB evtl. ohne RAID laufen lässt hängt davon ab, ob man auch hier die Redundanz haben möchte (Crash- Absicherung). Ansonsten kann man das freie Laufwerk als Hotspare laufen lassen.

Gruß, Fiddi

Guten Morgen erstmal,

Das ich den SQL Server brauche ist klar, nur lief die alte NATIV-Datenbank ca. 10x schneller auf SSD-Platten als auf SAS-Platten.
Die jetzige Datenbank ist knapp 15GB gross.
Ist es denn unkritisch SSD's zu nutzen für SQL? So wie ich das gelesen habe, sollte für die TEMP-DB lieber SAS genutzt werden, zwecks
den Schreib-Lese-Zyklen?!

Einen guten Start in den Tag

Also das grundsätzliche Problem im Bezug auf SSD mit NAV/SQL Server ist, dass es kaum Praxis-Erfahrungen gibt.
Das die Performance von SSD deutlich (!) besser ist, als die herkömmlicher HDD ist außer Frage!
Siehe dazu auch:
http://blogs.msdn.com/b/freddyk/archive/2008/11/02/running-microsoft-dynamics-nav-on-ssd-s-solid-state-drives.aspx
http://blogs.msdn.com/b/freddyk/archive/2009/02/09/more-ssd-testing.aspx

Wie Du ja ansprichst, ist das "Risiko" die begrenzte Anzahl an Schreibzyklen, die es - je nach Nutzung - erforderlich machen, die SSD auszutauschen, was das Ganze etwas teuer macht ...

Aber da ihr ja schon SSD habt:
Das herkömmliche Szenario der DB/Datei Verteilung geht ja stets von normalen HDD aus, bei den die mechanische Komponente das Problem ist, d.g. das Bewegen der Spindel und des Schreib/Lesekopfes. Das fällt mit SSD weg und macht das ganze somit schneller.
D.h. es ist unter Umständen gar nicht mehr nötig, die NAV DB vom Log zu trennen, da die SSD vielleicht gar kein Problem mit dem Wechsel von "Random Access" auf "Sequential Access" haben?!?
In so einem Fall könnte as Setup vielleicht so aus sehen:
C:\ 2 x SSD RAID1 System, OS, Programme, etc.
D:\ 2 x SSD RAID1 NAV DB (mdf, ndf, ldf)
E:\ 2 x SSD RAID1 tempdb
F:\ 1 x SSD lokale Backups & Misc.
1 x SSD HotSpare

Wie gesagt, das ist ein reines Gedankenspiel, nicht aus der Praxis gegriffen. Vielleicht kannst Du so ein Setup ja mal testen? AUf die Ergebnisse wäre ich sehr gespannt ...

Hallo zusammen,

möchte mich hier gerne mal kurz anschließen....

Wir stellen demnächst bei einer unserer kleinen Firmen (max. 10 User) auf NAV um. Den Server würde ich gerne virtualisieren & weiterhin eine native DB einsetzen.

Meine Frage ist nun, woraus sich eig. die Performance ergibt? Aus dem Splitten der Datenbank in z.B. 4 Teile und jeder Datenbankteil auf einer eigenen HDD oder jedoch nur aus dem Splitten auf mehrere HDDs? Oder aus beidem zusammen?

MfG S.

Hallo,

vom Einsetzen der Native-DB kann ich nur abraten, NAV2009 wird definitiv die letzte NAV- Version sein, die die Native-DB und Classic-Client unterstützt. Daher kann ich nur empfehlen sich mit dem RTC und dem SQL-Server auseinander zu setzen. Wenn du den Server virtualisieren möchtest, sorge bitte dafür das der SQL-Server genügend Ressourcen (Speicher,Prozessor) zu seiner Verfügung hat. Je nach Hardware- Konfiguration sorge bitte auch dafür das der SQL-Server dedizierte Platten für Log und Daten zur Verfügung hat (das gilt auch für die Datenbankdateien der Native-DB, die auf dedizierten Platten laufen sollten). Ein VM-Server auf dem x VMs laufen wird mit einem RAID5 aus 3x600GB SATA nie einen schnellen DB-Server ergeben )

Gruß, Fiddi

Also wir werden def. eine native DB zum Einsatz bringen. Auch der RTC fällt für uns vorerst flach, da wir eine Branchenlösung im Einsatz haben, die den RTC noch nicht forciert.

Fakt ist, dass die DB auf einem eigenen Plattenshelf niedergelegt wird. In unserer jetzigen Firma haben wir die DB in 4 Teile gesplittet und jeder DB-Teil liegt auf einer eigenen HDD in einem RAID 1. Aber gleiche Performance müsste ich doch erreichen, wenn ich nur eine DB am Stück hätte diese via RAID 5 auf mehrere Platten stückele, oder?

Also wir werden def. eine native DB zum Einsatz bringen.
Aber gleiche Performance müsste ich doch erreichen, wenn ich nur eine DB am Stück hätte diese via RAID 5 auf mehrere Platten stückele, oder?

Von der Kombination Native und RAID 5 wurde schon immer abgeraten, weil die DB-Teile dann nicht mehr richtig verwaltet werden. Hier ist auch etwas Info dazu.

Sorry, ich korrigiere - hab mich vertan:

Unsere jetzige DB ist in 4 Teile gesplittet, wobei jeder DB-Teil auf einer eigenen HDD liegt. Gleiche Performance kann ich doch auch erreichen, wenn ich ein RAID 0 fahre und nur eine komplette Datenbank habe. Oder gibt es noch andere Gründe, warum man die DB stückelt?

Vielen Dank!

Hallo,

das ist natürlich Schade, dass eure Branchenlösung kein RTC unterstützt, aber das könnte dir in Zukunft Probleme bereiten, wenn MS neue Betriebssysteme herausbringt, auf denen der NAV2009-CC nicht mehr läuft (siehe NAV4 und Windows Vista/7).

Aber eine DB auf einem RAID5 ist keine gute Idee, da gerade beim Schreiben der DB mehr Plattenzugriffe nötig sind, als bei einem RAID1, da für die Prüfsummenbrechnung die Daten aller Platten benötigt werden. Ein RAID0 bietet zwar eine höhere Performance, aber keinerlei Sicherheit. Fällt eine Platte aus, ist das komplette RAID hin, und alle Daten verloren. Bei den heutigen Plattengrößen und vor allem Plattencontrollern mit Cache sollte es kein Problem sein, ein RAID1 mit 146GB Platten für die Datenbank zu spendieren, das sollte eigentlich reichen. Ob du mehrere Datenbankteile benötigst hängt natürlich von eurem Datenvolumen ab. Aber bei 10 Benutzern ist das wohl eher kein Problem.

Gruß, Fiddi

Raid 5 fällt def. flach - war ein Versehen von mir!

Mom. bin ich nur am überlegen ob:

a) 4 DB-Teile auf je einer HDD (Raid 1)

oder

b) 1 DB-Teil auf einem Verbund von 4 HDD (Raid 0)

Bei Variante b) würde ich aus technischer Sicht einen besseren Datendurchsatz erreichen. Ob ich dann bei Variante b) einen DB-Teil oder wieder vier DB-Teile mache kann ich ja dann noch entscheiden....

b) 1 DB-Teil auf einem Verbund von 4 HDD (Raid 0)

Bei Variante b) würde ich aus technischer Sicht einen besseren Datendurchsatz erreichen. Ob ich dann bei Variante b) einen DB-Teil oder wieder vier DB-Teile mache kann ich ja dann noch entscheiden....

Wie schon gesagt ein RAID0 ist definitiv eine noch schlechtere Idee als RAID5, da bei dem Ausfall einer Platte alle Daten verloren sind. Wenn du was tun willst, kannst du ein RAID10 benutzen, das aus gespiegelten RAID0 besteht.
Aber über welche DB- Größe reden wir denn 10GB, 20GB? Bei den Platten, die du heute bekommst, fängt das aktuell bei 146GB SAS an (evtl. auch noch vereinzelt 73GB). Was willst du mit dem ganzen verschenkten Plattenplatz?
Investiere lieber in eine guten Plattencontroller mit Cache und BBU (Batteriebackup), schnelle SAS- Platten, eine USV (sollte sowieso vorhanden sein) und aktiviere auf dem Plattencontroller den Write-Cache. Das bringt, glaube ich, mehr als eine Unmenge an fast leeren Platten.

Gruß, Fiddi

Sorry, eigentlich wollte ich RAID10 schreiben! Bin heute etwas durcheinander Cache, BBU, 15er SAS-Platten sind natürlich Pflicht!

Letztendlich würde ich nun nur noch gerne wissen, was die Performance ausmacht......das splitten der DB und damit das verteilen auf mehrere HDDs oder lediglich das aufteilen auf mehrere HDDs?

Gibt es noch andere Gründe, wieso man die DB splittet?

S.

Gibt es noch andere Gründe, wieso man die DB splittet?

früher waren Platten langsam und klein, Speicher teuer, und Betriebssysteme nicht auf so große Datenmengen ausgelegt. Da machte es durchaus Sinn, sich Gedanken über die Hardware zu machen. Mit aktueller Hardware muss man sich da nicht so viele Gedanken machen.
Ob ein RAID10 noch Sinn macht, hängt von deiner kompletten Infrastruktur (PCs,Netzwerk,Datenaufkommen) ab. Wenn du einen 6 Jahre alten XP-Rechner mit 512 MB Arbeitsspeicher auf eine aktuellen Server mit 100Mbit- Netzwerk loslässt, dann ist der Server nicht das Performance-Problem, sondern der Client, der durch seine langsame Arbeitsweise alle anderen ausbremst. Hast du 10 Arbeitsplätze, von denen 8 meistens auf ihren Anwender warten, ist der Server auch nicht das Problem. Ist deine DB nur 3 oder 4GB groß, lacht jeder aktuelle Server darüber. Läuft der Server auf einem VM-Server, auf dem eine VM den ganzen Tag Videos konvertiert, ist das eher ein Performance- Problem.

Welche Konfiguration bei dir schneller ist, kannst du nur in deiner ganz konkreten Anwendung und Umgebung probieren. Ich würde erst einmal mit einem RAID1 für die DB anfangen, das nur für den DB-Server verwendet wird. Wenn es dann zu langsam wird, muss man prüfen, ob die DB-Dateien zu langsam arbeiten (Form auf "Database File" erstellen, und die Warteschlangen prüfen). Sind die Platten das Problem, kannst du immer noch welche nach stecken.

Gruß. Fiddi