Serverdimensionierung für ERP: So machen Sie es richtig

Die Serverdimensionierung für ERP ist eine dieser Entscheidungen, die zwar technisch wirken, aber erhebliche geschäftliche Konsequenzen haben. Wenn Sie Ihren Server zu klein dimensionieren, bekommen Sie vom ersten Tag an Leistungsbeschwerden – langsame Seitenladevorgänge, Zeitüberschreitungen bei Spitzenauslastung und Datenbank-Deadlocks bei gleichzeitiger Belastung. Wenn Sie es überdimensionieren, geben Sie deutlich mehr als nötig für die Infrastruktur aus, die größtenteils ungenutzt bleibt.

Bei den meisten ERP-Implementierungen gibt es zwei Gründe für die falsche Serverdimensionierung: IT-Teams sind zu selbstbewusst und orientieren sich bei der Dimensionierung an der Intuition, dass es sich nur um eine Web-App handelt, ohne die Datenbankintensität von ERP zu berücksichtigen. Oder sie empfehlen Anbieterempfehlungen, die auf maximale Leistung um jeden Preis ausgerichtet sind, statt auf angemessene Leistung zu angemessenen Kosten.

Dieser Leitfaden bietet Ihnen einen strukturierten Ansatz zur Serverdimensionierung für ERP-Bereitstellungen: die Schlüsselvariablen, die den Ressourcenbedarf bestimmen, die spezifischen Dimensionierungsrichtlinien für wichtige ERP-Plattformen bei unterschiedlichen Benutzerzahlen und wie Sie den kostenlosen Serverdimensionierungsrechner von ECOSIRE verwenden, um Ihre spezifische Situation zu modellieren.

Wichtige Erkenntnisse

• ERP ist deutlich datenbankintensiver als typische Webanwendungen – Standardregeln zur Webservergröße gelten nicht
• CPU ist selten die Einschränkung; RAM und Festplatten-I/O sind fast immer der Engpass bei ERP-Workloads – Odoo benötigt 2–4 GB RAM pro gleichzeitigem Arbeitsprozess; mindestens 16 GB für Produktionsinstanzen mit mehr als 50 Benutzern – Die IOPS-Anforderungen an den Datenbankspeicher werden bei den meisten Serverdimensionierungsstudien drastisch unterschätzt – Cloud-Instanzen, die auf dem Papier gleich aussehen (gleiche vCPU, gleicher RAM), können eine sehr unterschiedliche E/A-Leistung aufweisen – Immer für gleichzeitige Spitzenlast (nicht durchschnittliche Last) mit 30–40 % Spielraum dimensionieren
• Verwenden Sie den kostenlosen Server-Sizing-Rechner von ECOSIRE, um eine Spezifikation für Ihre spezifische Benutzerzahl und ERP-Plattform zu erstellen

---

Warum die Dimensionierung von ERP-Servern unterschiedlich ist

Bevor wir auf konkrete Empfehlungen eingehen, lohnt es sich zu verstehen, warum die Dimensionierung eines ERP-Servers eine sorgfältigere Analyse erfordert als die Dimensionierung einer typischen Webanwendung.

Datenbankintensität: ERP-Systeme sind grundsätzlich transaktionsverarbeitende Systeme. Jede Benutzeraktion – das Erstellen einer Bestellung, das Buchen einer Rechnung, das Verschieben von Lagerbeständen – generiert mehrere Datenbankschreibvorgänge, die atomar festgeschrieben werden müssen. Die Datenbankschicht verarbeitet komplexe relationale Abfragen über große, normalisierte Schemata hinweg, oft mit mehreren Tabellenverknüpfungen und Aggregatberechnungen. Dies unterscheidet sich stark von einem Content-Management-System oder einer Marketing-Website, die pro Seitenaufruf möglicherweise aus einigen denormalisierten Tabellen liest.

Muster zur gleichzeitigen Benutzerauslastung: Das Verhalten von ERP-Benutzern ist gleichzeitiger als bei typischen Webanwendungen. Auf einer Verbraucherwebsite surfen Benutzer selbstständig und interagieren nur selten. In einem ERP-System können mehrere Benutzer in derselben Abteilung während Spitzenzeiten (Monatsende, Tagesende, Schichtschluss) gleichzeitig Aufträge bearbeiten. Dieses gleichzeitige Schreibmuster führt zu Datenbanksperrenkonflikten, auf die eine typische Webanwendung nie stößt.

Arbeitsaufwand für die Berichtserstellung: ERP-Berichte – insbesondere Finanzberichte, Bestandsalterung und Bedarfsprognosen – führen komplexe Abfragen mit mehreren Tabellen aus, die 30–120 Sekunden lang ausgeführt werden können und während der Ausführung viel CPU und I/O verbrauchen. Wenn drei Finanzmitarbeiter gleichzeitig die Monatsabschlussberichte ausführen, kann die daraus resultierende Belastungsspitze schwerwiegend sein.

Sitzungsstatus und Arbeitsprozesse: Odoo führt speziell Python-Arbeitsprozesse aus, die den Sitzungsstatus für jede aktive Benutzerverbindung aufrechterhalten. Jeder Arbeitsprozess verbraucht im stabilen Zustand etwa 200–400 MB RAM und bei intensiver Berichtsausführung bis zu 1 GB. Der Server benötigt genügend RAM, um alle aktiven Worker gleichzeitig auszuführen, ohne auf die Festplatte auszulagern – das Auslagern auf einem ERP-Datenbankserver führt zu katastrophalen Leistungseinbußen.

---

Schlüsselvariablen bei der ERP-Serverdimensionierung

Vier Variablen bestimmen den Ressourcenbedarf des ERP-Servers mehr als alle anderen:

1. Anzahl gleichzeitiger Benutzer (nicht Gesamtbenutzeranzahl)

Die Gesamtbenutzerzahl ist ein schlechter Indikator für den Ressourcenbedarf. Die richtige Messgröße ist der Spitzenwert gleichzeitiger Benutzer: die Anzahl der Benutzer, die während der geschäftigsten Zeit des Tages gleichzeitig aktiv Anfragen an das System stellen.

Schätzung des Spitzenwerts gleichzeitiger Benutzer anhand der Gesamtbenutzerzahl:

• Bürobasiertes ERP mit normalen Geschäftszeiten: 15–25 % aller Benutzer sind zu Spitzenzeiten gleichzeitig
• Produktion mit mehreren Schichten: 25–35 % aller Benutzer gleichzeitig (Spitzenwerte bei Schichtwechsel)
• Verteilte Vorgänge über Zeitzonen hinweg: geringere Spitzengleichzeitigkeit, aber längere Spitzendauer
• Finanzintensive Nutzung am Monatsende: vorübergehender Anstieg auf 40–50 % gleichzeitig während der Schließzeiten

Planen Sie für eine Odoo-Bereitstellung mit 100 Benutzern und normaler Büronutzung 15–25 gleichzeitige Benutzer zu typischen Spitzenzeiten ein, wobei am Monatsende 40–50 gleichzeitige Benutzer vorgesehen sind. Dies sollte Ihre Größenberechnung bestimmen, nicht die Gesamtzahl von 100 Benutzern.

2. Transaktionsvolumen und Transaktionskomplexität

Hohe Transaktionsvolumina erhöhen die Schreiblast der Datenbank unabhängig von gleichzeitigen Benutzern. Ein Vertriebsunternehmen, das 2.000 Bestellungen pro Tag verarbeitet, generiert deutlich mehr Datenbank-Schreib-E/A als ein professionelles Dienstleistungsunternehmen mit 100 Benutzern, aber geringem Transaktionsvolumen. Ebenso generieren komplexe Transaktionen (Fertigungsaufträge, die Stücklistenverbrauch, Lagerbestand, Kostenrechnung und Qualitätsaufzeichnungen gleichzeitig aktualisieren) mehr E/A als einfache Transaktionen (eine Journalbuchung, die zwei Sachkonten aktualisiert).

Schätzen Sie die Komplexität Ihrer Transaktionen ab, indem Sie über die verwendeten Module nachdenken: Fertigung und Lagerbestand in mehreren Lagern erzeugen die komplexesten Transaktionen; Einfache Buchhaltungs- und HR-Module generieren die einfachsten.

3. Datenbankgröße und Wachstumsrate

Die Datenbankgröße wirkt sich auf zwei Arten auf die Abfrageleistung aus: direkt (das Scannen größerer Tabellen dauert länger) und indirekt (Arbeitssätze, die den verfügbaren RAM überschreiten, führen zu Cache-Fehlern und mehr E/A).

ERP-Datenbanken wachsen schneller, als die meisten IT-Teams erwarten. Eine anfängliche Datenbank von 20 GB kann in zwei bis drei Jahren bei normalem Wachstum durch Transaktionsverlauf, Dokumentanhänge und Prüfprotokolle auf 100 GB anwachsen. Dimensionieren Sie Ihren Speicher für drei Jahre des erwarteten Wachstums, nicht nur für den aktuellen Bedarf.

4. Integrations- und API-Arbeitsaufwand

Wenn Ihr ERP über API eine Verbindung zu externen Systemen herstellt (E-Commerce-Plattform, 3PL-System, Bank-APIs, Marktplatz-Konnektoren), erzeugen diese Integrationen zusätzliche Serverlast, die sich nicht in den Benutzerzahlen widerspiegelt. Jeder API-Aufruf durchläuft die Anwendungsschicht und Datenbank des ERP – eine hochvolumige Integration (Verarbeitung von 1.000 Bestellsynchronisierungsanfragen pro Stunde) kann der Last von 10–20 gleichzeitigen Benutzern gerecht werden.

---

Größenrichtlinien nach Plattform und Benutzeranzahl

Odoo 19 Enterprise

Die Architektur von Odoo verwendet Arbeitsprozesse (Odoo-Worker), die jeweils Benutzeranfragen bearbeiten. Die Anzahl der Worker und die erforderlichen Serverressourcen skalieren mit der Anzahl der gleichzeitigen Benutzer.

Odoo-Worker-Berechnung: – Empfohlene Worker = (gleichzeitige Benutzer / 6) + 1, aufgerundet

• Jeder Mitarbeiter benötigt im Dauerbetrieb etwa 300–500 MB RAM, bei umfangreichen Berichten bis zu 1 GB
• Cron-Worker (für Hintergrundprozesse) fügen 2–4 zusätzliche Worker hinzu

Empfohlene Mindestspezifikationen nach Benutzeranzahl:

Wichtige Hinweise zur Odoo-Größe:

• Die Datenbank (PostgreSQL) und die Anwendung (Odoo-Worker-Prozesse) laufen idealerweise auf separaten Servern ab 100 Benutzern. Zusammen auf einem einzigen Server konkurrieren Datenbank und Anwendung um RAM. – Der gemeinsam genutzte PostgreSQL-Speicher (effektive_cache_size) sollte auf 50–75 % des RAM des Datenbankservers eingestellt werden.
• SSD-Speicher ist für das PostgreSQL-Datenverzeichnis obligatorisch – rotierende Festplatten führen zu einer katastrophalen Leistung in jeder ERP-Datenbank. – Für Bereitstellungen mit mehr als 50 Benutzern wird ein separater Redis-Server für die Odoo-Sitzungsspeicherung empfohlen.

Microsoft Dynamics 365 Business Central

Bei Verwendung des SaaS-Bereitstellungsmodells wird Business Central in der Microsoft Azure-Infrastruktur in der Cloud gehostet – in diesem Fall wird die Servergröße von Microsoft verwaltet. Für lokale Bereitstellungen:

Business Central vor Ort verwendet SQL Server als Datenbank, das über ein separates Speicherverwaltungsmodell von PostgreSQL verfügt. Weisen Sie dem Pufferpool von SQL Server dedizierten RAM zu (über die Einstellung max server memory) – etwa 75 % des RAM des Datenbankservers.

SAP Business One

SAP Business One wird lokal (Windows oder HANA) oder in der SAP Business One Cloud bereitgestellt:

SAP HANA (die In-Memory-Datenbank, die mit der SAP Business One HANA-Edition verwendet wird) hat viel höhere RAM-Anforderungen als herkömmliche festplattenbasierte Datenbanken, da der Arbeitssatz in den Speicher passen muss. Die RAM-Anforderungen für HANA sind nicht verhandelbar – HANA, dem der Speicher ausgeht, stürzt ab und verschlechtert sich nicht.

---

Empfehlungen für Cloud-Instanzen

Beim Selbsthosting von ERP auf AWS, Azure oder GCP ist die Auswahl des richtigen Instanztyps von entscheidender Bedeutung. Nicht alle Instanzen mit der gleichen vCPU- und RAM-Anzahl erbringen bei Datenbank-Workloads die gleiche Leistung.

AWS-Empfehlungen für Odoo (kombinierte App+Datenbank, unter 100 Benutzer):

• t3.xlarge (4 vCPU, 16 GB): Entwicklung und kleine Produktion (unter 25 Benutzer)
• r6i.xlarge (4 vCPU, 32 GB): Kleine bis mittlere Produktion (25–50 Benutzer)
• r6i.2xlarge (8 vCPU, 64 GB): Mittlere Produktion (50–100 Benutzer)
• r6i.4xlarge (16 vCPU, 128 GB): Große Produktion (100–200 Benutzer, zusammen)

AWS-Empfehlungen für Odoo (geteilte App/Datenbank, 100+ Benutzer): – Anwendungsserver: c6i.2xlarge (8 vCPU, 16 GB) – rechenoptimiert

• Datenbankserver: r6i.4xlarge (16 vCPU, 128 GB) – speicheroptimiert – Datenbankspeicher: io2 EBS-Volumes (bereitgestellte IOPS) – 3.000–6.000 IOPS bereitgestellt

Azure-Äquivalente:

• Anwendungsserver: Standard_F8s_v2 (8 vCPU, 16 GB)
• Datenbankserver: Standard_E16s_v5 (16 vCPU, 128 GB)

GCP-Äquivalente:

• Anwendungsserver: c2-standard-8 (8 vCPU, 32 GB)
• Datenbankserver: n2-highmem-16 (16 vCPU, 128 GB)

Die I/O-Leistungsfalle: Standard-EBS-gp3-Volumes auf AWS bieten standardmäßig 3.000 IOPS. Für eine Produktions-ERP-Datenbank mit mehr als 50 gleichzeitigen Benutzern reicht dies oft nicht aus – insbesondere beim Monatsabschluss, wenn mehrere komplexe Berichte gleichzeitig ausgeführt werden. Verwenden Sie io2 bereitgestellte IOPS-Volumes für den Datenbankspeicher, wobei mindestens 3.000 IOPS bereitgestellt werden müssen. Der Kostenunterschied ist erheblich (0,065 USD/GB/Monat für gp3 gegenüber 0,125 USD/GB/Monat für io2 plus 0,065 USD/IOPS/Monat für bereitgestellte IOPS), aber auch der Leistungsunterschied ist erheblich.

---

Hochverfügbarkeitsarchitektur

Für Produktions-ERP-Systeme, bei denen Ausfallzeiten erhebliche Auswirkungen auf das Geschäft haben, sollten Sie eine Hochverfügbarkeitsarchitektur in Betracht ziehen, die Widerstandsfähigkeit gegen Ausfälle einzelner Server bietet.

Mindest-HA-Architektur für Odoo (100+ Benutzer):

• Zwei Anwendungsserver hinter einem Load Balancer (Round-Robin oder Sticky Sessions)
• PostgreSQL-Primärdatenbank mit einem Standby-Replikat (mittels Streaming-Replikation oder AWS RDS Multi-AZ) – Redis-Cluster (zwei Knoten) für die Sitzungsspeicherung
• Gemeinsamer Dateispeicher (AWS EFS oder gleichwertig) für die Dateianhangsdaten von Odoo

Diese Architektur bietet Widerstandsfähigkeit gegen den Ausfall einzelner Server, ohne dass ein manueller Eingriff erforderlich ist. Der Failover vom primären PostgreSQL zum Standby erfolgt automatisch (mit Patroni oder AWS RDS) und ist normalerweise in 30–60 Sekunden abgeschlossen.

RPO- und RTO-Ziele für typisches ERP:

• Wiederherstellungspunktziel (maximaler Datenverlust): 5 Minuten (mit synchroner Replikation) bis 30 Minuten (mit asynchroner Replikation)
• Wiederherstellungszeitziel (maximale Ausfallzeit): 30–60 Sekunden für automatisches Failover, 15–30 Minuten für manuelle Wiederherstellung

---

Verwendung des ECOSIRE Server-Dimensionierungsrechners

Der kostenlose Server-Sizing-Rechner von ECOSIRE unter /tools/server-sizing-calculator automatisiert den oben beschriebenen Berechnungsprozess. Eingaben:

1. Auswahl der ERP-Plattform
2. Gesamtzahl der Benutzer
3. Spitzenprozentsatz gleichzeitiger Benutzer (oder automatische Schätzung basierend auf dem Anwendungsfall)
4. Transaktionsvolumen (niedrig, mittel, hoch, sehr hoch)
5. Integrationsanzahl und -volumen (keine, einfach, mäßig, intensiv)
6. Verfügbarkeitsanforderungen (Einzelserver, HA, Notfallwiederherstellung)
7. Präferenz des Cloud-Anbieters (AWS, Azure, GCP oder lokal)

Ausgänge: – Empfohlene Serverspezifikationen für Anwendungs- und Datenbankebenen

• Spezifische Cloud-Instanz-Empfehlungen für Ihren bevorzugten Anbieter
• Monatliche Schätzung der Infrastrukturkosten
• Drei-Jahres-Wachstumsprognose, die zeigt, wann ein Upgrade erforderlich ist – Speicher-IOPS-Anforderungen und empfohlene Speicherebene

Der Rechner ist anhand der ECOSIRE-eigenen Produktionsbereitstellungsdaten für Dutzende von Kundenimplementierungen kalibriert, wodurch die Schätzungen zuverlässiger sind als die alleinige Dokumentation des Anbieters.

---

Häufig gestellte Fragen

Wie schätze ich den Spitzenwert gleichzeitiger Benutzer, wenn wir noch nie ERP verwendet haben?

Für Greenfield-Implementierungen ohne historische Daten verwenden Sie 20 % der Gesamtbenutzer als anfängliche Schätzung für eine normale bürobasierte Bereitstellung. Wenn Sie mehrere Schichten haben oder über mehrere Zeitzonen hinweg arbeiten, verwenden Sie 25–30 %. Fügen Sie dann in den ersten zwei Jahren 50 % Spielraum für Wachstum hinzu. Planen Sie für ein 100-Benutzer-ERP mit normalen Bürozeiten 20 gleichzeitige Benutzer zu typischen Spitzenzeiten ein, stellen Sie 30 bereit und bauen Sie Kapazität auf, um 40 ohne Änderungen an der Infrastruktur zu erreichen. Dieser Headroom-Ansatz vermeidet Leistungsprobleme, da sich die Akzeptanz in den Monaten nach dem Go-Live verbessert.

Sollten wir die Odoo-Anwendung und die Datenbank auf demselben Server oder auf separaten Servern ausführen?

Für Bereitstellungen mit weniger als 50 Benutzern reicht normalerweise ein einzelner kombinierter Server aus – die Anwendungs- und Datenbank-Workloads dieser Größenordnung stehen normalerweise nicht im Konflikt. Bei 50–100 Benutzern hängt die Entscheidung von den Nutzungsmustern ab: Wenn die Benutzerbasis gleichmäßig über den Tag verteilt ist und es keine nennenswerten Spitzenzeiten gibt, funktioniert ein kombinierter Server möglicherweise immer noch. Bei starken Spitzen (Monatsende, Schichtschluss) sorgen separate Anwendungs- und Datenbankserver für eine bessere Isolierung. Bei über 100 Benutzern werden separate Server dringend empfohlen.

Welchen Speichertyp sollten wir für die Odoo-Datenbank verwenden?

SSD-Speicher ist für das PostgreSQL-Datenverzeichnis obligatorisch – eine rotierende Festplatte (HDD) führt bei jeder Produktions-ERP-Datenbank zu einer inakzeptablen Leistung. Verwenden Sie auf Cloud-Plattformen bereitgestellte IOPS-SSDs (AWS io2, Azure Premium SSD v2, GCP Extreme Persistent Disk) für den Datenbankspeicher, wenn Sie mehr als 50 gleichzeitige Benutzer haben. Allzweck-SSD (AWS gp3, Azure Standard SSD) ist für Entwicklungs- und kleine Produktionsbereitstellungen mit weniger als 25 gleichzeitigen Benutzern geeignet.

Wie viel Spielraum sollten wir in unsere Serverdimensionierung einbauen?

Planen Sie 30–40 % Headroom über Ihrer erwarteten Spitzenlast für den Normalbetrieb und 100 % Headroom (effektiv das Doppelte der Spitzenkapazität) für außergewöhnliche Zeiten wie Monatsende oder Hauptverkaufszeiten ein. Cloud-Bereitstellungen können mithilfe der automatischen Skalierung außergewöhnliche Zeiträume bewältigen, ohne dauerhaft für diese Kapazität zu zahlen – ein erheblicher Kostenvorteil gegenüber einer festen Infrastruktur vor Ort.

---

Nächste Schritte

Verwenden Sie den kostenlosen Server-Sizing-Rechner von ECOSIRE unter /tools/server-sizing-calculator, um eine Spezifikation für Ihre spezifische Bereitstellung zu erstellen. Der Rechner gibt eine AWS/Azure/GCP-Instanzempfehlung und eine monatliche Schätzung der Infrastrukturkosten aus, die Sie für die Budgetplanung verwenden können.

Wenn Sie eine Odoo-Implementierung planen und möchten, dass ECOSIRE neben der Implementierung auch die Dimensionierung und Einrichtung der Infrastruktur übernimmt, ist die Infrastrukturplanung in jedem ECOSIRE-Implementierungsauftrag enthalten.