ADOIT 21.0 Hardware-/Software-Anforderungen

Kurzbeschreibung

ADOIT Web-Client	Webbrowser zum Zugriff auf die ADOIT Web-Applikation. ADOIT unterstützt die Desktop-Browser Microsoft Edge, Mozilla Firefox und Google Chrome unter Windows sowie Safari unter macOS und auf dem iPad.
ADOIT Web-Server	Containerisierte Web-Server-Komponente, die die ADOIT Web-Applikation bereitstellt und den HTTP(S)-Datenverkehr von Web-Clients verarbeitet. Der Web-Server wird als OCI-konformer Container betrieben und ist typischerweise in externe Komponenten wie einen Ingress-Controller, die Gateway API oder einen Reverse Proxy zur HTTPS-Terminierung integriert.
ADOIT Applikations-Server	Containerisierte Backend-Komponente, die die zentrale ADOIT-Anwendungslogik beinhaltet und den Zugriff auf die ADOIT-Datenbank bereitstellt. Der Applikations-Server wird als OCI-konformer Container betrieben und kommuniziert über das interne Deployment-Netzwerk mit dem Web-Server.
ADOIT Datenbank	Externer Datenbankserver zur Speicherung sämtlicher persistenter ADOIT-Repository-Daten. ADOIT unterstützt Microsoft SQL Server und PostgreSQL. Die Datenbank wird unabhängig von den ADOIT-Containern betrieben und nicht als Teil der ADOIT-Runtime bereitgestellt.

Architektur

Die Architektur von ADOIT basiert auf einem containerisierten Anwendungsmodell.

Die Anwendung wird als Set von OCI‑konformen Container‑Images ausgeliefert und besteht aus zwei zentralen Server‑Komponenten:

• dem ADOIT Web‑Server
• dem ADOIT Applikations‑Server

Beide Komponenten werden in jeweils eigenen Containern betrieben und kommunizieren über ein internes Deployment‑Netzwerk miteinander. Der Web‑Server stellt die Web‑Applikation für Endbenutzer bereit und verarbeitet eingehende HTTP‑Anfragen. Der Applikations‑Server enthält die zentrale Anwendungslogik und übernimmt den Zugriff auf die ADOIT‑Datenbank.

Die ADOIT‑Datenbank ist nicht Bestandteil der containerisierten Laufzeitumgebung, sondern wird als externer Datenbankserver betrieben. Sie speichert sämtliche persistenten Repository‑Daten und wird unabhängig vom ADOIT‑Deployment administriert.

ADOIT bietet zwei Optionen für das containerbasierte Deployment:

• Kubernetes, unter Verwendung des mitgelieferten Helm-Charts
• Docker-Compose, unter Verwendung der mitgelieferten Compose-Konfiguration

Die grundlegende Anwendungsarchitektur bleibt dabei identisch; Unterschiede ergeben sich ausschließlich im Bereich der Orchestrierung und Infrastrukturintegration.

Software-Anforderungen

ADOIT Web-Client

Der Zugriff auf ADOIT erfolgt ausschließlich über einen Webbrowser. Zusätzliche clientseitige Software oder Plugins sind nicht erforderlich.

Untertstützte Browser

Desktop-Browser: Microsoft Edge (neueste Version) unter Windows Mozilla Firefox (neueste Version) unter Windows Google Chrome (neueste Version) unter Windows Safari (neueste Version) auf dem Mac Mobile-Browser: Safari auf dem iPad (neueste Version; grafische Modellierung wird auf dem iPad nicht unterstützt)

Server‑Komponenten

ADOIT wird in einer containerbasierten Server-Umgebung betrieben. Sämtliche serverseitigen Komponenten werden als OCI‑konforme Container‑Images ausgeliefert und mithilfe einer unterstützten Container-Runtime ausgeführt.

Die folgenden Abschnitte beschreiben die erforderliche serverseitige Software-Umgebung sowie die Infrastrukturkomponenten, die für den Betrieb von ADOIT bereitzustellen sind.

Container-Runtime

ADOIT erfordert eine OCI‑konforme Container-Runtime auf einer x86_64‑ (AMD64‑)Architektur. Folgende Container-Plattformen sind vollständig validiert und werden unterstützt:

Plattform	Status
Kubernetes (x86_64)	Unterstützt
Docker und Docker Compose (x86_64)	Unterstützt

Andere OCI‑konforme Container-Runtimes oder Kubernetes‑kompatible Plattformen sind voraussichtlich kompatibel, sofern sie den jeweiligen Standards entsprechen. Solche Plattformen werden jedoch nicht einzeln getestet.

Benutzer für die Container-Ausführung und Pod-Sicherheitsbeschränkungen

ADONIS-Images werden mit der Anforderung ausgeliefert, dass die in den Containern ausgeführten Prozesse dem Benutzer 1100 gehören. In Container-Orchestrierungsumgebungen mit Einschränkungen bezüglich der runAsUser-Einstellungen kann dies dazu führen, dass die Container nicht gestartet werden können. Die Deployment-Einstellungen müssen so angepasst werden, dass die Ausführung als Benutzer 1100 erlaubt ist. In OpenShift kann dies beispielsweise erreicht werden, indem das Security Context Constraint (SCC) für das zugehörige Service-Konto auf nonroot gesetzt wird (siehe die Red Hat OpenShift-Dokumentation. Mit dieser Einstellung wird weiterhin sichergestellt, dass der tatsächliche Benutzer nicht root ist, wobei berücksichtigt wird, dass bei Vorhandensein mehrerer Instanzen von BOC Group-Produkten auf einem Node diese mit derselben UID ausgeführt werden.

Betriebssystem (Host-Ebene)

ADOIT ist für den Betrieb auf modernen Linux-basierten Betriebssystemen ausgelegt, welche die Ausführung der erforderlichen Container-Runtime unterstützen.

Beispiele für geeignete Host-Betriebssysteme sind:

• Ubuntu
• Debian
• Red Hat Enterprise Linux (RHEL)
• SUSE Linux Enterprise Server (SLES)

Grundsätzlich kann jede aktuelle Linux-Distribution eingesetzt werden, die vom gewählten Container-Runtime- und Deployment-Stack unterstützt wird.

Kubernetes und Deployment-Tooling

Beim Betrieb von ADOIT in einer Kubernetes‑Umgebung gelten folgende Anforderungen:

Komponente	Anforderung
Kubernetes	Kubernetes-Version 1.32 oder höher
Helm	Helm 3.x für Deployment und Lifecycle-Management
Zugriff auf Container-Registry	HTTPS-Zugriff auf OCI-Registry (Port 443)

Der Kubernetes‑Cluster muss Standard‑Ressourcentypen wie Services, Ingress‑ oder Gateway‑API‑Ressourcen sowie Persistent Volume Claims unterstützen, wie sie für das ADOIT‑Deployment erforderlich sind.

Persistenter Speicher

Persistenter Speicher wird für den Volltext-Suchindex sowie für die Logdateien der Anwendung benötigt. Die Bereitstellung des Speichers erfolgt in der Regel über Kubernetes Persistent Volumes (PV) und Persistent Volume Claims (PVC), die über das bereitgestellte Helm-Chart konfiguriert werden.

Speicherkomponente	PVC erforderlich	Backup erforderlich	Zweck	Hinweise
Volltext-Suchindex	Ja	Nein	Speicherung des vom Applikations-Server-Pod verwendeten Volltext-Suchindex.	Erfordert ein dediziertes PVC, das am Applikationsserver-Pod gemountet ist. Der Speicher kann durch Block-Storage wie Ceph RBD bereitgestellt werden. Der Index kann jederzeit neu erstellt werden.
Applikations-Logs	Ja	Optional	Speicherung von Logdateien und Erzeugung des ADOIT Support Information Package (SIP)	Logdateien können zusätzlich oder alternativ zum Standard-Container-Logstream (stdout/stderr) auf dieses Volume geschrieben werden.

Serverseitiger Softwareumfang

Die ADOIT‑Container‑Images enthalten alle erforderlichen applikationsspezifischen Abhängigkeiten. Insbesondere gilt:

• Auf dem Host-System ist keine separate Java‑Installation erforderlich.
• Es muss keine Web‑ oder Applikationsserver-Software außerhalb der Container installiert werden.
• Die Konfiguration erfolgt ausschließlich über Umgebungsvariablen, die beim Deployment bereitgestellt werden.

Abhängig von der gewählten Deployment‑Umgebung können zusätzliche Infrastrukturkomponenten erforderlich sein (z. B. Reverse Proxies, Ingress‑Controller oder Zertifikatsmanagement‑Lösungen). Diese sind nicht Bestandteil der ADOIT‑Runtime selbst und werden in der zugehörigen technischen Dokumentation beschrieben.

Datenbank-Server

ADOIT erfordert ein extern betriebenes Datenbanksystem zur Speicherung aller persistenten Repository‑ und Anwendungsdaten. Die Datenbank ist nicht Bestandteil der ADOIT‑Container‑Runtime und muss unabhängig bereitgestellt und betrieben werden.

Unterstützte Datenbankmanagementsysteme

ADOIT unterstützt folgende Datenbankmanagementsysteme:

Unterstützte Datenbanksysteme

Microsoft SQL Server: SQL Server 2016 SQL Server 2017 SQL Server 2019 SQL Server 2022 SQL Server 2025 (Enterprise Edition, Standard Edition, Workgroup Edition, Express Edition) Hinweis: Die SQL Server Express Edition wird nicht für den produktiven Einsatz empfohlen. Hinweis: ADOIT unterstützt kein SQL Server Multi-Subnet-Failover. Jeder Abbruch der Datenbankverbindung führt zu einem Neustart der datenbankabhängigen Backend-Komponenten. PostgreSQL PostgreSQL 12 bis 17

Datenbankanbindung

• Die Datenbank muss vom ADOIT Applikations‑Server‑Container aus über das Netzwerk erreichbar sein.
• Erforderliche Datenbanktreiber sind Bestandteil der ADOIT‑Container‑Images; zusätzliche Client‑Installationen auf dem Host-System sind nicht notwendig.
• Die Datenbankverbindung (Host, Port, Datenbankname, Zugangsdaten) wird über Umgebungsvariablen im Deployment konfiguriert.

Datenbankbetrieb

• Die Datenbank kann auf physischen oder virtuellen Servern oder als Managed Database Service betrieben werden, sofern die Netzwerkanbindung gewährleistet ist.
• Backup, Wiederherstellung, Hochverfügbarkeit und Wartung der Datenbank liegen in der Verantwortung des Kunden.
• ADOIT stellt keine zusätzlichen Anforderungen an Datenbank‑Cluster‑ oder Failover‑Mechanismen über die Standardfunktionen des jeweiligen DBMS hinaus.

Zusätzliche optionale Server-Komponenten

SMTP-Server

ADOIT unterstützt Szenarien, bei denen E-Mail-Benachrichtigungen versendet werden können. Um diese Funktionalität nutzen zu können, wird ein SMTP-Server benötigt, welcher vom ADOIT Web-Server erreichbar sein muss. Die Adresse sowie der Port des SMTP Servers sind in der ADOIT Administration konfigurierbar. Es werden sowohl SMTP-Authentifizierung als auch Transport Layer Security (TLS) unterstützt.

Netzwerk-Anforderungen

Der Betrieb von ADOIT erfordert eine zuverlässige Netzwerkanbindung zwischen den beteiligten Komponenten sowie zu notwendigen Infrastrukturservices.

Erforderliche Netzwerkverbindungen

Folgende Netzwerkverbindungen müssen verfügbar sein:

ADOIT Web-Client – ADOIT Web-Server	Zugriff durch Endbenutzer über HTTP oder HTTPS. Mindestens: 2 Mbit/s Empfohlen: 10 Mbit/s
ADOIT Web-Server – ADOIT Applikations-Server	Interne Kommunikation innerhalb der Deployment‑Umgebung.
ADOIT Applikations-Server – Datenbankserver	Persistente Verbindung zur externen Datenbank. Mindestens: 100 Mbit/s Empfohlen: 1 Gbit/s LAN-ähnliche Latenzzeiten
Deployment‑Umgebung → Container‑Registry	HTTPS‑Zugriff (in der Regel TCP‑Port 443) zum Abruf der Container‑Images.

Ports und Protokolle

Folgende Ports und Protokolle werden benötigt:

Port	Zweck
443	Zugriff auf die Container-Registry
80 / 443	HTTP / HTTPS für den Web-Zugriff auf ADOIT
Datenbankspezifische Ports	Verbindung zur externen Datenbank; abhängig vom eingesetzten DBMS

Die TLS‑Terminierung erfolgt nicht innerhalb der ADOIT‑Container. Für verschlüsselten Zugriff muss die HTTPS‑Terminierung durch externe Komponenten wie Ingress‑Controller, Gateways oder Reverse Proxies erfolgen.

Hardware-Anforderungen

ADOIT Web-Client

Die Hardware-Anforderungen für den ADOIT Web‑Client richten sich in erster Linie nach den Anforderungen des eingesetzten Betriebssystems und Webbrowsers.

Als allgemeine Richtwerte gelten:

• Mindestens 4 GB RAM und eine Bildschirmauflösung von 1366 x 768 oder höher werden für eine akzeptable Performance empfohlen.
• Höhere Bildschirmauflösungen verbessern die Bedienbarkeit bei der Arbeit mit Modellen und Reports.

Server‑Komponenten

• Der Umfang der Nutzung (Anzahl gleichzeitiger Benutzer, Größe des Repositorys, Modellierungs‑ und Reporting‑Aktivität) ist der maßgebliche Faktor für die Skalierung der Server-Hardware.
• Es sollte ausreichende Ressourcenreserve eingeplant werden, um Lastspitzen, Hintergrundverarbeitung und betrieblichen Overhead abzufangen.
• Beim Betrieb von ADOIT in Kubernetes müssen Ressourcen-Requests und -Limits mit der verfügbaren Node‑Kapazität abgestimmt sein.

Typische Ressourcenanforderungen

Die folgenden Werte stellen typische Anforderungen an CPU und Speicher für die einzelnen ADOIT-Container dar.

Komponente	CPU	Speicher
Web-Server-Container	2 CPUs oder mehr	2 GB oder höher (Minimum) 4 GB oder höher (empfohlen)
Applikations-Server-Container	3 CPUs oder mehr	4 GB oder höher (Minimum) - 2 GB für den ADOIT Applikations-Server-Prozess, und zusätzlich 1 GB für jeden konfigurierten aworker-Prozess 8 GB oder höher (empfohlen) - 4 GB für den ADOIT Applikations-Server-Prozess, und zusätzlich 2 GB für jeden konfigurierten aworker-Prozess Zusätzliche 6 GB RAM sind erforderlich, wenn mindestens 10 GB an externen Dokumenten in die Datenbank hochgeladen wurden.

Beispielhafte Ressourcen-Konfiguration

Die folgenden Werte zeigen, wie typische ADOIT-Sizing-Empfehlungen auf Kubernetes-Ressourceneinstellungen abgebildet werden können. Sie basieren auf den oben genannten empfohlenen Werten und sollten an die tatsächliche Last angepasst werden.

Web-Server-Container

Parameter	Beispielwert
CPU-Request	2 CPUs
CPU-Limit	4 CPUs
Memory-Request	4 GB
Memory-Limit	8 GB

Applikations-Server-Container

Parameter	Beispielwert
CPU-Request	3 CPUs
CPU-Limit	6 CPUs
Memory-Request	8 GB
Memory-Limit	16 GB

Hinweise zu Skalierung und Verfügbarkeit

• ADOIT unterstützt den Betrieb mehrerer Applikations‑Server‑Instanzen zu Verfügbarkeitszwecken, unter Berücksichtigung der dokumentierten architektonischen Einschränkungen.
• Eine horizontale automatische Skalierung wird nicht unterstützt; die Skalierung erfolgt primär durch vertikale Skalierung der verfügbaren Ressourcen.
• Bei Nutzung mehrerer Nodes muss die insgesamt verfügbare Ressourcenmenge den Anforderungen des jeweiligen Workloads entsprechen.

Datenbank-Server

Festplattenspeicher	Mindestens: Entsprechend den Angaben des DBMS-Herstellers Empfohlen: 2 GB pro ADOIT Datenbankinstanz. Dieser Wert ist abhängig vom Umfang der abgelegten Daten, und kann somit auch höher angesetzt werden.
CPU	Entsprechend den Angaben des DBMS-Herstellers
Speicher	Mindestens: 500 MB für die erste ADOIT Datenbankinstanz und weitere 500 MB für jede zusätzliche Datenbankinstanz; Empfohlen: Abhängig vom Umfang der abgelegten Daten, kann es sinnvoll sein, für die Datenbankinstanz mehr Speicher zu reservieren.

Authentifizierungsmechanismen

Dieser Abschnitt beschreibt die Authentifizierungsmechanismen für ADOIT. Die Authentifizierungsmechanismen können separat oder in Kombination verwendet werden. Abhängig von den verwendeten Authentifizierungsmechanismen können installationsspezifische Konfigurationsschritte notwendig sein. Bei weiterführenden Fragen zur Authentifizierung wenden Sie sich bitte an Ihren ADOIT-Kundenbetreuer.

Authentifizierungsmechanismen

Standard ADOIT Benutzer	ADOIT Benutzer werden in der ADOIT Administration erzeugt. Die Anmeldung an ADOIT erfordert die Eingabe von Benutzername und Passwort. Mit diesen Zugangsdaten wird der Benutzer gegen die verfügbaren Daten in der ADOIT-Datenbank authentifiziert. Die Zuordnung von Benutzerattributen, Rechten und System-Rollen wird in der ADOIT Administration gesteuert.
LDAP-Authentifizierung	Benutzer können entweder aus einem Verzeichnisdienst importiert oder auf ADOIT Benutzer gemappt werden. Die Anmeldung an ADOIT erfordert die Eingabe von Benutzername und Passwort. Mit diesen Zugangsdaten wird der Benutzer gegen den konfigurierten Verzeichnisdienst authentifiziert. Voraussetzung für dieses Szenario ist die Anbindung von ADOIT an den verwendeten Directory Service (z.B. Active Directory) in der ADOIT Administration. Die Zuordnung von Benutzerattributen, Rechten und System-Rollen kann in der ADOIT Administration gesteuert werden oder mit einem externen Verzeichnisdienst synchronisiert werden. Spezifische Konfigurationsschritte sind notwendig, um ADOIT für diesen Authentifizierungsmechanismus einzurichten. Bei weiterführenden Fragen zu diesem Authentifizierungsmechanismus wenden Sie sich bitte an Ihren ADOIT-Kundenbetreuer.
IDM-Authentifizierung	Benutzer können entweder aus einem externen Benutzerverwaltungssystem importiert oder auf ADOIT Benutzer gemappt werden. Eine Anmeldung an ADOIT mittels Single sign-on ist über ein Identity Management System (IDM) möglich. Voraussetzung für dieses Szenario ist die Anbindung an einen in der Zielumgebung verfügbaren Authentifizierungs-Server, über den die Authentifizierung mit einer externen Benutzerverwaltung erfolgt. Die Zuordnung von Benutzerattributen, Rechten und System-Rollen kann in der ADOIT Administration gesteuert werden oder mit einem externen Benutzerverwaltungssystem synchronisiert werden. Spezifische Konfigurationsschritte sind notwendig, um ADOIT für diesen Authentifizierungsmechanismus einzurichten. Bei weiterführenden Fragen zu diesem Authentifizierungsmechanismus wenden Sie sich bitte an Ihren ADOIT-Kundenbetreuer.
SAML-Authentifizierung	Benutzer können entweder aus einem externen Benutzerverwaltungssystem importiert oder auf ADOIT Benutzer gemappt werden. Das externe Benutzerverwaltungssystem muss einen Identitäts-Provider (IdP) für SAML 2.0 zur Verfügung stellen (z.B. Active Directory Federation Services [AD FS] oder Shibboleth). Um sich an ADOIT anzumelden, wird der Benutzer zum IdP umgeleitet. Je nach Konfiguration des IdP erfolgt die Authentifizierung mittels Single sign-on oder durch die Eingabe von Zugangsdaten (Benutzername und Passwort, Zertifikate etc.). Für diese Authentifizierungsmethode ist keine Server-to-Server-Kommunikation notwendig, da alle Daten über den Browser übertragen werden. Die Zuordnung von Benutzerattributen, Rechten und System-Rollen kann in der ADOIT Administration gesteuert werden oder mit einem externen Benutzerverwaltungssystem synchronisiert werden. Spezifische Konfigurationsschritte sind notwendig, um ADOIT für diesen Authentifizierungsmechanismus einzurichten. Bei weiterführenden Fragen zu diesem Authentifizierungsmechanismus wenden Sie sich bitte an Ihren ADOIT-Kundenbetreuer.
OIDC-Authentifizierung	Benutzer können entweder aus einem externen Benutzerverwaltungssystem importiert oder auf ADOIT Benutzer gemappt werden. Voraussetzung für die Nutzung von OpenID Connect (OIDC) ist die Anbindung an einen OpenID Connect-Provider (OP), der die Identität des Anwenders überprüft und grundlegende Profilinformationen zum Anwender bereitstellt. Um sich an ADOIT anzumelden, wird der Benutzer zum OP umgeleitet. Eine Anmeldung an ADOIT mittels Single sign-on ist über OIDC-Authentifizierung möglich. Die Zuordnung von Benutzerattributen, Rechten und System-Rollen kann in der ADOIT Administration gesteuert werden oder mit einem externen Benutzerverwaltungssystem synchronisiert werden. Spezifische Konfigurationsschritte sind notwendig, um ADOIT für diesen Authentifizierungsmechanismus einzurichten. Bei weiterführenden Fragen zu diesem Authentifizierungsmechanismus wenden Sie sich bitte an Ihren ADOIT-Kundenbetreuer.

LDAP-Support

LDAP/LDAPS-Unterstützung für die Provider AD (Active Directory) und eDirectory und vergleichbare LDAP-Provider. Andere LDAP-Provider sind nicht getestet. Eine entsprechende Evaluierung kann auf Anfrage durchgeführt werden.

Funktionsübersicht

Diese Tabelle enthält eine Zusammenfassung der Funktionen der verschiedenen Authentifizierungsmechanismen.

	Standard ADOIT Benutzer	LDAP-Authentifizierung	IDM-Authentifizierung	SAML-Authentifizierung	OIDC-Authentifizierung
Anmeldung mit Benutzername und Passwort	Ja	Ja	Ja (abhängig von der IDM-Lösung)	Ja (abhängig vom SAML-IdP)	Ja (abhängig vom OP)
SSO	Nein	Nein	Ja (abhängig von der IDM-Lösung)	Ja (abhängig vom SAML-IdP)	Ja (abhängig vom OP)
Bei der Anmeldung Attribute, Rollen- und Gruppenzuordnung mit externem Benutzerverwaltungssystem abgleichen	Nein	Ja	Ja	Ja	Ja
Periodisch Attribute, Rollen- und Gruppenzuordnung mit externem Benutzerverwaltungssystem abgleichen	Nein	Ja	Ja (mit LDAP-Kopplung)	Ja (mit LDAP-Kopplung)	Ja (mit LDAP-Kopplung)
Benutzer automatisch anlegen	Nein	Ja	Ja	Ja	Ja