NAV-Serverumgebung

Wir planen NAV2018 einzuführen. Wir haben ca. 300 User und rechnen mit ca. bis zu einem Auftragsvolumen von 10.000 Aufträge pro Tag.

Unsere aktuellen Server sind alle in einer ESX-Farm mit 4 Servern virtualisiert. Wir planen ein Entwicklungssystem, ein Test/Staging-System sowie ein Produktivsystem.
Gibt es hier Erfahrungswerte wie man das System aufsetzen sollte? 1-n SQL-Server, 1-n Tiers, ... ?
Wie viel Hauptspeichern benötigt man für den SQL-Server? Wie viel zu ein Tier?
Und wie viel User sollte man max. ein Tier zuweisen?

300 User und rechnen mit ca. bis zu einem Auftragsvolumen von 10.000 Aufträge pro Tag.

Die Hauptlast wird, soviel ich weiss, erzeugt durch die Buchung der Aufträge, nicht durch deren Erfassung.

Wenn das 10 000 Verkaufsauftragsköpfe sind mit je 1 Verkaufszeile, in welcher Artikelnummer, Menge, Preis, Rabatt etc. steht, dann ist das Erfassen und Buchen für NAV 2018 (SQL-Server 2016 als Backend) ein Kinderspiel.

Wenn das aber Aufträge sind, die selber mehrere Tausend Verkaufszeilen haben und auch noch ständig aus anderen Modulen gebucht wird, zB Fibuposten aus Fibubuchblatt, kann es wichtig sein, sich zu überlegen, worauf der ServiceTier Dienst installiert wird und welche Hardware zur Verfügung steht.

10K Aufträge pro Tag ist ein ganz schöner Batzen. Wahnsinn.
Hier stehen ein paar Werte.

[PDF]Dieses Dokument ist schon ein bisschen älter, sollte dennoch aussagekräftig genug sein, weil die Performance des Service Tier seitdem besser geworden ist.

Hallo,

Die Hauptlast wird, soviel ich weiss, erzeugt durch die Buchung der Aufträge, nicht durch deren Erfassung.

JEIN. bei 10000 Aufträgen pro Tag, werden die wohl nicht aller per Telefon oder Mail, sondern auch auf elektronischem Wege ins System kommen. Da passiert dann auch schon bei der Erfassung einiges.

Wie man das ganze organisiert, hängt von der Organisation des Betriebes ab.

Welche Programme man wo installiert, hängt auch von eurer Hardware ab. Eine schnell angebundene Storage (würde ich hier empfehlen), erfordert eine andere Konfiguration als eine Konfiguration aus normalen "Blechkisten". Außerdem musst du dir bei dem Datenvolumen sehr viel Gedanken über das Thema Ausfallsicherheit machen, und wie externe Systeme unter diesem Gesichtspunkt angebunden werden müssen/können.

Ich persönlich bevorzuge eine ein- Machinen- Lösung. D.h. alle Dienste SQL-Server und zumindest die Servicetiers laufen auf einem System. Das hat den Vorteil, dass man bei einem Neustart nicht auf irgendwelche Abhängigkeiten (Wenn SQL- Server neu gestartet wird, müssen auch Servicetiers neu gestartet werden) achten muss. Das erfordert aber eine Maschine mit ausreichend Cores, was wiederum eine Kostenfrage mit den SQL-Server- Lizenzen ist. Ist das kein Problem, kann man nach einem halben Jahr anfangen, diese Maschine auszutarieren. D.h. evtl. Cores dediziert einzelnen Prozessen zuweisen, Speicher zu optimieren,und vor allem die Anwendung zu optimieren. Letzteres wird bei dem Datenvolumen einiges an Zeit kosten, denn mit der Standardkonfiguration wirst du schon nach 3 Monaten Probleme bekommen.
Wenn du mehrere VMs für die Konfiguration einsetzen willst, bedenke das diese nicht auf dem gleichen physischen Server laufen sollten. Denn sonst hast du neben den zwei Betriebssystemen, die für sich Rechenzeit kosten, auch die Verwaltungsebene des Hypervisors und die (virtuelle) Netzwerkverbindung, die zusätzliche physische Rechenzeit benötigen, die NAV dann fehlt.

Zur Anzahl der Serivcetiers:
Auch hier muss man sich anschauen, was wird benötigt: Wenn deine 300 User aus Terminals bestehen, die meist nur warten (z.B. Thekengeschäft im Baumarkt), dann kannst du natürlich mehr User auf einen Servicetier legen, als bei einem Call-Center, wo jede unnütze Sekunde Wartezeit Geld kostet.
Generell würde ich die Servicetiers zunächst nach den Aufgaben sortieren, denn jeder Servicetier hat einen eigenen Cache, der synchronisiert werden müsste, wenn gleiche Daten in mehreren Diensten benutzen werden.
Daher sollte man es mit der Anzahl der Servicetiers nicht unbedingt übertreiben. Generell würde ich die Servicetiers nach Aufgaben sortieren: z.B. Auftragserfassung, Logistik, Buchhaltung, Jobqueue,... Speziell die Jobqueue würde ich auf einen eigenen Dienst legen, da man die häufiger mal neu startet, was keine gute Idee ist, wenn auf dem Servicetier noch 100 Anwender Belege erfassen.
Außerdem benötigt man für bestimmte Dienste u.U. speziell konfigurierte Servicetiers (Webservices, Webclient,..), die man auch separat einrichten muss.

Gruß Fiddi