Lobster Cloud ist in mehreren Editionen verfügbar, die jeweils auf einen bestimmten Geschäftsumfang und Verfügbarkeitsanspruch ausgelegt sind. Diese Seite bietet Ihnen einen vollständigen Überblick über alle Editionen, deren technische Spezifikationen, verfügbare Dimensionierungsoptionen und Upgrade-Pfade.
Cloud-Sizing
Jede Edition ist in einer oder mehreren Sizing Optionen verfügbar. Das Sizing legt die Rechenressourcen (vCPU, RAM) und die Speicherkapazität fest, die Ihrem System zugewiesen werden.
Lobster DATA Platform Server
Das Basissystem ist die Standard-Deploymentvariante der Lobster Cloud und richtet sich an Umgebungen mit standardmäßigen Verfügbarkeitsanforderungen. Es basiert auf einem Single-Node-Setup ohne komponentenübergreifende Redundanz und garantiert eine monatliche Verfügbarkeit von 99,0 %. Für Umgebungen mit höheren Verfügbarkeitsanforderungen empfehlen wir die High-Availability-Architektur (99,9%)
Basissystem
Cloud-Sizing | Server (vCPU / RAM) | Java Heap Zuweisung | Server Festplatte | Datenbank (vCPU / RAM) | Datenbank Festplatte | Anwendungsfall |
|---|---|---|---|---|---|---|
S | 1 vCPU / 8 GB | 75 % | 200 GB SSD | 2 vCPU / 4 GB | 100 GB SSD | Kosteneffizient und leichtgewichtige Workloads |
M | 4 vCPU / 16 GB | 75 % | 300 GB SSD | 4 vCPU / 16 GB | 250 GB SSD | Standard-Workloads |
L | 8 vCPU / 32 GB | 75 % | 400 GB SSD | 8 vCPU / 32 GB | 250 GB SSD | Hohe Workloads |
DMZ- und DEV-Server
Cloud-Größe | DMZ- / DEV-Server (vCPU / RAM) | Java Heap Allocation | Server Festplatte | DEV-Datenbank (vCPU / RAM) | DEV-Datenbank-Festplatte |
|---|---|---|---|---|---|
S | 1 vCPU / 8 GB | 75 % | 200 GB SSD | 2 vCPU / 4 GB | 100 GB SSD |
M | 2 vCPU / 8 GB | 75 % | 200 GB SSD | 2 vCPU / 8 GB | 250 GB SSD |
L | 4 vCPU / 16 GB | 75 % | 300 GB SSD | 4 vCPU / 16 GB | 250 GB SSD |
Java Heap Zuweisung
Der angegebene Prozentwert definiert den maximalen Anteil des Server-RAM, der der Java Virtual Machine (JVM) als Heap-Speicher zur Verfügung gestellt wird. Bei einer Instanz der Größe M mit 16 GB RAM und einer Allokation von 75 % stehen der JVM somit bis zu 12 GB Heap zur Verfügung. Der verbleibende Arbeitsspeicher wird vom Betriebssystem sowie systemnahen Prozessen genutzt und ist nicht für die JVM reserviert.
Eignung nach Anwendungsfall
Anwendungsfall | S | M | L |
|---|---|---|---|
Datentransfer A nach B | Ideal für kleine Volumina | Hohe Workloads unterstützt | Hohe Workloads unterstützt |
Mappings | Kleine Mapping-Bäume | Mittlere bis große Mapping-Bäume | Große Mapping-Bäume |
Lokale Datenbankabfragen (via VPN) | Nur nicht zeitkritische | Mittlerer Datentransfer | Hoher Datentransfer |
SAP-Anbindung (via VPN) | Nur nicht zeitkritische | Mittlerer Datentransfer | Hoher Datentransfer |
Zeitkritische Aufgaben | Nicht empfohlen | Gelegentlich | Vollständig unterstützt |
Hohe Parallelisierung | Nicht empfohlen | Teilweise | Vollständig unterstützt |
Wichtig:
Die hier dargestellten Szenarien und Sizing-Spezifikationen sind ausschließlich Richtwerte zur Orientierung. Die Lobster DATA Platform ist hochflexibel und kann an eine Vielzahl von Anforderungen angepasst werden. Da jeder Kunde individuelle Workloads und Rahmenbedingungen hat, können diese Werte nicht jeden Anwendungsfall universell abdecken.
Upgrade-Pfade
Lobster Cloud bietet einen klaren Upgrade-Pfad, damit Ihre Umgebung mit Ihrem Unternehmen wachsen kann. Alle Upgrades werden vom Lobster nach Erteilung des Auftrags durchgeführt.
Größen-Upgrades
Aktuelle Größe | Verfügbares Upgrade | Hinweise |
|---|---|---|
S | auf M | Erfordert zunächst ein Editions-Upgrade auf SCALE oder höher |
M | auf L | Verfügbar für alle Editionen ab SCALE |
L | Kein weiteres Größen-Upgrade | Maximale Dimensionierungsstufe |
Hinweis:
DMZ- und DEV-Server können nicht unabhängig skaliert werden. Das Sizing ist auf Größe S oder M festgelegt.
Architekturmigration zu High Availability
Kunden mit Standardsystemen können gegen Aufpreis auf eine Hochverfügbarkeitsarchitektur umsteigen.
Von | Nach | Voraussetzungen |
|---|---|---|
Standard | High-Availability-Architektur | Vollständige Architekturmigration erforderlich. Dies ist eine komplette Transformation Ihrer Umgebung, kein einfaches Upgrade. Gegen Aufpreis verfügbar. |
Storage-Erweiterungspakete
Sollte Ihre Standard-Speicherkapazität nicht ausreichen, können Sie diese mit den folgenden Paketen erweitern. Storage-Erweiterungen gelten immer für Ihre Produktions- und Testumgebung.
Systemtyp | Erweiterungsgröße | Gilt für | Max. Erweiterungen |
|---|---|---|---|
VM-Speicher | +500 GB | Produktion + Test | Unbegrenzt |
Datenbank-Speicher | +250 GB | Produktion + Test | Unbegrenzt |
HA FileShare Produktion (EFS) | +500 GB | Nur Produktion | Unbegrenzt |
HA FileShare Test (EFS) | +500 GB | Nur Test | Unbegrenzt |
High Volume (FSx) | +1 TB | Produktion + Test | Unbegrenzt |
High-Availability-Architektur
Die High Availability (HA) Architektur ist ein redundantes Multi-Node-Setup, das den Ausfall einzelner Komponenten abfängt, ohne den laufenden Betrieb zu unterbrechen. Durch die Redundanz auf allen kritischen Ebenen – von den DMZ-Servern über die Datenbank bis hin zum Shared File System – wird eine monatliche Verfügbarkeit von 99,9 % garantiert.
Produktionssystem-Komponenten
Komponente | Anzahl | Dimensionierung M | Dimensionierung L |
|---|---|---|---|
DMZ-Server | 2x | 2 vCPU / 8 GB / 200 GB SSD | 4 vCPU / 16 GB / 300 GB SSD |
Node Controller | 1x | 4 vCPU / 16 GB / 100 GB SSD | 8 vCPU / 32 GB / 100 GB SSD |
Working Node | 1x | 4 vCPU / 16 GB / 100 GB SSD | 8 vCPU / 32 GB / 100 GB SSD |
Redis Cache Cluster | 2x | managed size | managed size |
Shared File System (EFS) | 1x | 500 GB (erweiterbar) | 500 GB (erweiterbar) |
Aurora PostgreSQL Datenbank | 2x | 2 vCPU / 16 GB / 250 GB SSD | 4 vCPU / 32 GB / 250 GB SSD |
Hinweis:
Eine HA-Setup kann insgesamt zwei Working Nodes haben.
Testsystem-Komponenten
Komponente | Anzahl | Dimensionierung M | Dimensionierung L |
|---|---|---|---|
DMZ-Server | 1x | 2 vCPU / 8 GB / 200 GB SSD | 4 vCPU / 16 GB / 300 GB SSD |
Node Controller | 1x | 4 vCPU / 16 GB / 100 GB SSD | 8 vCPU / 32 GB / 100 GB SSD |
Redis Cache Cluster | 2x | managed size | managed size |
Shared File System (EFS) | 1x | 500 GB (erweiterbar) | 500 GB (erweiterbar) |
Aurora PostgreSQL Datenbank | 2x | 2 vCPU / 16 GB / 250 GB SSD | 4 vCPU / 32 GB / 250 GB SSD |
Hinweis:
Das Testsystem kann durch Hinzufügen eines zweiten DMZ-Servers und eines Working Node zu einer vollständigen HA-Konfiguration erweitert werden.
High-Volume-Dateisystem (FSx)
Für Kunden, die große Mengen kleiner Dateien (unter 100 KB) verarbeiten, kann das Standard-EFS-Dateisystem durch FSx for NetApp ONTAP ersetzt werden. Dieses Upgrade bietet Sub-Millisekunden-Latenzen, provisionierte IOPS und deutlich schnellere Einzeldateioperationen. Das High-Volume-Upgrade erfordert Cloud-Dimensionierung L und umfasst 1 TB für jede Test- und Produktionsumgebung.
Spezifikation | Standard Volume (EFS) | High Volume (FSx) |
|---|---|---|
Datenlatenz | 1 bis 3 ms | Sub-Millisekunde |
Metadaten-Latenz | 3 bis 10 ms | Sub-Millisekunde |
Realistische IOPS | ca. 3.500 | Skalierbar bis Millionen |
Optimiert für kleine Dateien | Nein | Ja |
In-Memory- und NVMe-Caching | Nein | Ja |
Multi-AZ-Deployment | Ja | Ja |
Empfehlung:
Wenn Ihr Workload häufige Verarbeitung von Dateien unter 100 KB umfasst oder Sie Sub-Millisekunden-Antwortzeiten benötigen, wird die High-Volume-Option empfohlen. Für Workloads, die vorwiegend größere Dateien verarbeiten, bietet das Standard Volume ausreichende Leistung.