Betriebsmodell „Private Cloud“
Für den Betrieb der Fabasphere im Betriebsmodell „Private Cloud“ gelten die folgenden Voraussetzungen.
Infrastruktur
Es wird die folgende Infrastruktur vorausgesetzt.
Kubernetes-Cluster
- Red Hat OpenShift (mind. Version 4.17) oder
- k3s (mind. Version 1.31.0)
Datenspeicherung über NFS-Fileshare
- 3 x NFS-Fileshares (Version NFSv3 oder NFSv4.1)
Datenbank
- PostgreSQL (Version 17.6)
Container-Registry
- Container-Registry (zum Beispiel Habor oder JFrog Artifactory) zum Synchronisieren der Fabasphere-Images von registry.fabasoft.com
Betrieb
Es gelten die folgenden Voraussetzungen für den Betrieb.
Notwendige Services
- Loadbalancer (Empfehlung nginx)
- OpenLDAP (mind. Version 2.6.10)
Hinweis: Die notwendigen Services sind nicht Teil des Fabasphere-Deployments.
Optionale Services
- KEDA Operator (optional)
- Istio (optional)
- Logging-Stack des Kubernetes-Clusters
- Monitoring-Stack des Kubernetes-Clusters
Hinweis: Die optionalen Services sind nicht Teil des Fabasphere-Deployments.
Konfigurationsmanagement/Deployment
- Git (zum Beispiel GitLab, Gitea)
- Deployment-Werkzeug (zum Beispiel Argo CD)
- Alternativ mit Helm (Version 3)
Hinweis: Die erforderlichen Werkzeuge sind nicht Teil des Fabasphere-Deployments.
External Cluster Access (TCP)
Die Bereitstellung von TCP/IP-Adressen für Services mit dem Servicetyp „LoadBalancer“ ist notwendig (z. B. MetalLB).
Ressourcen und Skalierung
Für den Betrieb der Fabasphere-Services im Betriebsmodell „Private Cloud“ sind mindestens folgende Ressourcen pro Service notwendig (1000 registrierte Benutzer, 10 TB Daten).
Service | CPU (angefordert) | RAM | Persistenter Speicher | Anmerkung |
|---|---|---|---|---|
COO-Service | 4 | 16 GB | 128 MB | DTM-Logs benötigen persistenten Speicher. |
Storage-Service | 4 | 8 GB | 3 x 10 TB | 3 x NFS-Share für redundante Speicherung (kein Replica). |
Webservice | 2 | 16 GB | - | Bei steigender Objektmenge ist eine Erhöhung des RAMs empfohlen. Bei steigender Anfragelast durch Benutzeranfragen ist eine Erhöhung der CPU erforderlich. |
AT-Service | 2 | 16 GB | - | |
IdP | 2 | 6 GB | - | |
EventQ | 2 | 2 GB | 2 GB | |
DTS | 16 | 64 GB | 8 GB | |
MIS | 4 | 12 GB | 50 GB | |
EXTCACHE | 2 | 8 GB | - | |
OData | 2 | 8 GB | - | Optional |
OpenAPI | 2 | 8 GB | - | Optional |
Stateserver | 2 | 4 GB | - | |
COODOTNET | 4 | 16 GB | - | Optional |
Für einen beispielhaften Standard-Betrieb mit 1000 registrierten Benutzern und 10 TB Daten wird pro Service mindestens folgende Anzahl an Replicas benötigt:
Service | Anzahl | Anmerkung zur Skalierung |
|---|---|---|
COO-Service | 3 | Für jedes COO-Service wird eine eigene Datenbank benötigt. Die mindestens benötigten Ressourcen der einzelnen Instanzen der COO-Services können je nach konfigurierter Objektplatzierung abweichen und unterschiedliche Konfigurationen benötigen. |
Storage-Service | 3 | 2 Replicas sind aktiv für die Beantwortung von Anfragen notwendig. Das dritte Replica schreibt ein Online-Backup der Daten und dient als Fallback. |
Webservice | 12 | Jedes Webservice bietet maximal 64 Threads an. Bei steigender Request-Anzahl muss die Anzahl an Instanzen erhöht werden. |
AT-Service | 2 | Je nach Anzahl der abzuarbeitenden automatischen Aufgaben kann eine Erhöhung der Anzahl an AT-Services notwendig sein. |
IdP | 2 | Der IdP wird redundant mit 2 Replicas betrieben. Eine höhere Skalierung ist nicht notwendig. |
EventQ | 3 | Für den Betrieb der EventQ sind 3 Replikas notwendig. Die Anzahl darf weder erhöht noch verringert werden. |
DTS | 1 | DTS besteht aus einzelnen Microservices für die jeweiligen Konvertierungstools. Eine Skalierung ist hier nur auf Tool-Ebene möglich. Es werden automatische Skalierungsmechanismen angeboten um automatisch lastabhängig skalieren zu können. |
MIS | 1 | MIS besteht aus einzelnen Microservices. Eine höhere Skalierung ist nicht notwendig. |
EXTCACHE | 3 | Es wird empfohlen pro Worker-Node der Orchestrierungsplattform ein Replica bereitzustellen. |
OData | 2 | Bei erhöhter Anfragelast kann es notwendig sein, die Replicas zu erhöhen. Werden vorwiegend größere Datenabfragen durchgeführt, ist eine Erhöhung des RAMs erforderlich. |
OpenAPI | 2 | Bei erhöhter Anfragelast kann es notwendig sein, die Replicas zu erhöhen. |
Stateserver | 2 | Bei erhöhter Anfragelast kann es notwendig sein, die Replicas zu erhöhen. |
COODOTNET | 2 | Bei erhöhter Anfragelast über OData oder OpenAPI kann es notwendig sein, die Replicas zu erhöhen. |
Die Angaben zu den Ressourcen und der Skalierung beziehen sich auf unabhängige Erfahrungswerte und stellen die Mindestanforderungen dar. Abhängig von der eingesetzten Hardware, der konkreten Anfragelast und dem Benutzerverhalten kann eine Erhöhung der Ressourcen oder Instanzen notwendig sein.
Mindbreeze AI
Mindbreeze AI wird auf dem gleichen Kubernetes-Cluster betrieben. Das benötigte Sprachmodell muss direkt, zum Beispiel von Hugging Face, bezogen werden. Mindbreeze AI benötigt zur Speicherung der für KI-Anwendungsfälle notwendigen Daten einen „Persistent Volume Claim“.
Empfehlungen:
- Zur Verbesserung der Performance wird der Betrieb von Mindbreeze AI Pods auf Servern mit GPU empfohlen.
- Für den Betrieb von großen Sprachmodellen (LLM) wird die Bereitstellung eigener Server mit Grafikkarte (GPU) im Kubernetes-Cluster empfohlen.
- Zur Ausfallssicherheit wird der Betrieb von zwei Servern je LLM empfohlen.
- Je Server wird eine Grafikkarte empfohlen, die jeweils vollständig dem LLM bereitgestellt wird.
- Das LLM sollte mindestens 7b Parameter aufweisen.
- Für eine allgemeinere Verwendbarkeit sollte das LLM mehrsprachig sein oder zumindest die verwendeten Sprachen gut unterstützen.
- Je nach Anwendungsfall sollte das LLM mindestens 8 bis 10 Token pro Sekunde und Benutzer bereitstellen.
- Das verwendete LLM sollte instruction-tuned oder chat-tuned sein.
Unterstützte GPUs:
Mindbreeze AI unterstützt CUDA-GPUs mit folgenden Compute-Capability-Versionen: 6.0, 6.1, 7.0, 7.5, 8.0, 9.0
Eine Liste an Devices wird unter folgendem externen Link gepflegt: CUDA GPU Compute Capability: neues Fenster