Hardwareanforderungen Navision System

Hallo,

meine Firma plant die Einführung eines Navision ERP Systems. Verwendet werden soll dabei Dynamics NAV 2013. Wir besitzen einen Webshop (Magento) mit folgenden Stammdaten:

500.000 Bestellungen (insgesamt)
350.000 Kunden
200.000 Produkte (50.000 davon sind konfigurierbar)

Das System wird später von max. 20 Mitarbeitern gleichzeitig benutzt. Unsere Idee ist jeweils eine VM mit dem AppServer und eine mit dem Datenbankserver aufzusetzen. Meine Frage ist jetzt, welche Hardwarevoraussetzungen würdet ihr empfehlen für ein System in einer solchen Dimension bzw. ist der Ansatz mit der Virtualisierung und der Trennung des App- und DB-Servers der richtige. Vielen Dank schon mal im Voraus.

Hallo,

wie viele Bewegungen (neue Belege, neue Kunden) habt bzw. plant ihr denn in einem definierten Zeitraum (Tag/Woche/Monat/Jahr)?

500000 Bestellungen in 10 Jahren sind nicht viel, in einem Jahr schon.
350000 Kunden sind in einem Webshop nicht unbedingt das Problem, wenn sie, wie oft üblich, nur Einmal- Kunden sind (Enden als Karteileiche, oder werden gleich als diverser Kunde abgehandelt. Je nachdem, was man mit dem Thema "Kundenbindung" {CRM, Mailings,...} anfangen will).

Handelt es sich hier um eine reine Magento- Anbindung oder auch Ebay und/oder Amazon u. andere.

Gruß, Fiddi

Es handelt sich ca. um 1000 Bestellungen am Tag.
Die Anbindung soll akutell erstmal nur zu Magento stattfinden.
Weiterhin soll auch die gesamte Buchhaltung über das Navision-System durchgeführt werden.

1000 Bestellungen pro Tag

Das sollte sich mit NAV bewerkstelligen lassen.

Wo läuft denn die Logistik/Einkauf ab, bei euch (in NAV) oder bei einem Dienstleister?

Mit dem richtigen Addon kann man den Magento auch direkt aus NAV heraus ansteuern. Was unbedingt zu empfehlen ist, damit Automatismen besser greifen können. Denn nur einer kann der Chef im Ring sein. Wird Nav und Magento getrennt gepflegt, läuft das ganze irgendwann auseinander. D.h. Die Preise stimmen nicht zwischen Magento und NAV, Artikel fehlen auf der einen oder anderen Seite oder die Auftragsabwicklung läuft nicht sauber (Zahlungsabwicklung, Lieferadressen,...).

Zu deiner Hardware:
Eine virtuelle Lösung hätte den Vorteil auf Hardwareausfälle u.U. besser(automatisch) reagieren zu können. Denn das ist bei der Größenordnung, die du hier angibst ein Thema über das du dir zu aller erst Gedanken machen solltest. Aber für das Thema gibt es auch andere Ansätze (SQL-Logshipping,...).
Die Virtualisierung einzusetzen um Serversysteme länger nutzen zu können, sollte erst in zweiter Linie in die Überlegung einfließen. Denn neue Software(updates) erfordern auch eine aktuelle Systemumgebung (Windows,SQL), die eine neue Installation erfordern.
Danach kommen wir zur Dimensionierung der (virtuellen) Hardware. Hier ist sicherlich eine dedizierte (virtuelle?) Maschine für den SQL-Server mit viel Speicher(>32GB) und ausreichend Platte(>300GB, besser mehr) (physikalisch im Server oder Storage) zu empfehlen.
Der Servicetier ist hier genügsamer, den kann man in 2013 sicherlich auf einer dedizierten (virtuellen?) Maschine laufen lassen sollte. Der kommt aber mit wenig Platte aus, und ein Arbeitsspeicher mit 16GB ist sicherlich eine Größenordnung mit der man arbeiten kann. (Das ganze natürlich nur für NAV, wird der Server noch für andere Dinge benutzt, muss das natürlich zusätzlich berücksichtigt werden).

Gruß, Fiddi

Hallo Fiddi,

erstmal vielen Dank für deine ausführliche Antwort. Ist es jetzt besser die Maschinen auf dedizierten Servern laufen zu lassen oder sind 2 VMs auf einem dedizierten Host ok. Ist bei den Festplatten noch irgendetwas zu beachten bzgl. Anzahl und Art der Platten bzw. welches RAID-Level und welche Partionierung man vornehmen sollte. Vllt. kannst du mir auch kurz ein Beispiel geben oder kurze eigene Erfahrungen schildern. Vielen Dank.

Hallo,

Du solltest zunächst ein Mengengerüst klären (was willst du wie oft mit dem System tun (Einkauf/Verkauf/Lager,... und Anzahl Bewegungen). Danach musst du die Laufzeit deiner Server klären (Anzahl Jahre). Dann kann man in etwa über ein Datenvolumen reden, das verarbeitet und gespeichert werden muss. Danach sollte man das System wählen. Dies sollte ausreichend dimensioniert sein, und Reserven haben. Welches System du konkret wählst, hängt auch von eurem Hardwarepartner ab.
Die Hardware, die er euch anbietet, von der er und ihr meint, dieses System ist leistungsfähig und ausfallsicher genug, und ganz wichtig: die der HW-Partner beherrscht, solltet ihr einsetzen.

Gruß, Fiddi

Hallo Fiddi,

mir geht es nicht wirklich um die Größe der Daten sondern um die Geschwindigkeit der späteren Schreibvorgänge. Sollte man da bestimmte Sachen trennen oder kann auch alles auf einem physischen Datenträger liegen, sei es eine Festplatten oder ein RAID-Array.

jede datendatei des sql-servers auf eine physikalische platte - ebenfalls die system & tempdb auf je eine platte.
wenn das budget das nicht zulässt, dann wenigsten die logfile auf eine physik. platte

jede datendatei des sql-servers auf eine physikalische platte - ebenfalls die system & tempdb auf je eine platte.
wenn das budget das nicht zulässt, dann wenigsten die logfile auf eine physik. platte

Wenn er das mit der dedizierten Hardware bei dem Datenvolumen macht, würde ich für die Daten auch schon mal ein wenig mehr Platten vorsehen (Ob als 1 X RAID10 oder n x RAID1) hängt von der Hardware ab. Und wenn du mit einer Storage arbeitest, ist das ganze mit den Platten eh hinfällig. Dann fängt man wieder von vorne an.

Gruß, Fiddi

Unser voraussichtlicher Plan ist es einen dedizierten Server zu mieten auf dem ein VMware ESXi System läuft und darauf jeweils 1 VM für den Application- und Datenbankserver. Dabei ist im Moment folgende Dimensionierung für den VM-Host vorgesehen:

2x Intel Xeon E5-2643
64 GB RAM
4x600GB SAS (15K) Festplatten im RAID 10

Hältst du diese Konfiguration für ausreichen oder siehst du da eventuelle Engpässe für die Performance des Systems.

Hallo,

2x Intel Xeon E5-2643
64 GB RAM
4x600GB SAS (15K) Festplatten im RAID 10

Hältst du diese Konfiguration für ausreichen oder siehst du da eventuelle Engpässe für die Performance des Systems.

Diese Konfiguration scheint mir bei eurem Datenvolumen (1000 Aufträge pro Tag und 20 Nutzer) für ein ESX- System ein wenig sparsam zu sein.

Das würde ich für den physikalischen SQL- Server alleine verwenden, und den noch um 4 (2x Raid1) weitere Platten für Betriebssystem und anderes spendieren. Außerdem gehören die SQL- Datenbank und dessen LOG aus Gründen der Ausfallsicherheit auf getrennte physikalische Laufwerke.
Ob man die Datenbank besser noch auf mehrere Laufwerke verteilt, kann euch nur ein Spezialist klären, der sich mit MS-SQL auf eurer Hardware auskennt.
Außerdem hättet ihr dabei keinerlei Ausfallsicherheit (Server platt- >Firma arbeitsunfähig). D.h. du benötigst für euer Datenvolumen eine zweiten Server mit ähnlicher Leistungsfähigkeit.

Ein Datenbankserver benötigt Arbeitsspeicher, Arbeitsspeicher und.... . Danach Platten, Platten,...

Der Servicetier ist für heutige Hardware eher harmlos (8-16GB, Plattenplatz 300GB Raid1), der muss nur mit möglichst schnellem Netzwerk mit dem SQL-Server verbunden werden.

Gruß, Fiddi

Salve,

da ihr bereits auf 7 seid, ist Vitalisierung ohnehin die bessere Lösung. Trennung der 3-Tier-Architektur besagt quasi ja schon der Name. Wenn ihr allerdings keine Ahnung von ESX/Hyper-V habt und auch keine Storage Guru's, dann lieber das Paket jemandem aufdrücken, der was davon versteht und weg von on Premise. Da ihr ohnehin hohe Webintegration haben wollt, könntet ihr die Nummer auch gleich auf AZURE deployen. Mit R2 kann man auch den AZURE SQL Service nutzen. Vorteil darin ist, alles unterhalb der VM Haube ist nicht euer Problem .