Anforderungen an einen On-Premise-Betrieb

Inhalt

1. Architektur im Überblick

VIA wird bei Ihnen in zwei klar getrennten Schichten betrieben:

• Applikations-Cluster (3 Server): Hier laufen VIA, myVIA und alle weiteren Microservices als Container, orchestriert durch Kubernetes (empfohlen) oder Docker Swarm. Die Applikations-Server speichern keine Fachdaten. Fällt einer aus, übernehmen die beiden anderen automatisch.

• Daten-Server (1 Server, empfohlen 2): Hier liegen die MySQL-Datenbank und der Dokumentenspeicher. Er ist ausschließlich aus dem Applikations-Cluster erreichbar und wird nie nach außen freigegeben.

Nutzende (Behördennetz / Internet)
        │  HTTPS (443)
        ▼
Load-Balancer bzw. virtuelle IP
        │
        ▼
Applikations-Cluster (1-3 Nodes)     ──►    Internet, nur ausgehend
  [Ingress] [VIA] [myVIA] [Print]             (Updates, Registry,
  [Assets] [ÖPNV] [weitere Dienste]           GraphHopper/OSM, Bahn)
        │  
        ▼  
{ MySQL (3306) }
 { S3 (HTTPS) }
        │  
        ▼
Daten-Server
  [MySQL 8.4 LTS] 
  [S3-Dokumentenspeicher] 
  [Backup-Jobs]

2. Technische Anforderungen

Server

Gesamtbedarf: 11 bis 19 vCPU / 42 bis 58 GB RAM.

• Die Werte gelten für einen typischen Landkreis oder kreisfreie Stadt inkl. myVIA und Reserve für Lastspitzen (z. B. Serienbriefe). Für sehr große Gebietskörperschaften stimmen wir sie individuell ab.

• Virtuelle Maschinen sind ausdrücklich gewünscht (VMware, Hyper-V, Proxmox o. ä.). Die Applikations-Nodes müssen auf unterschiedlichen physischen Hosts laufen (Anti-Affinity), sonst bringt der Cluster keine Ausfallsicherheit. Dasselbe gilt für Daten-Server und Replikat.

• Das Datenbank-Volume muss auf SSD/NVMe-basiertem Speicher mit niedriger Latenz liegen, nicht auf einer NFS- oder SMB-Freigabe.

• Der Dokumentenspeicher wird nur benötigt, wenn Sie die digitale Akte in VIA nutzen und keinen eigenen S3-kompatiblen Speicher bereitstellen.

• Zusätzlich benötigen wir ein Backup-Ziel außerhalb des Daten-Servers (z. B. NFS-Freigabe oder S3-Bucket Ihres Backup-Systems) mit Platz für mindestens 30 Tage Aufbewahrung.

Clients

• keine Installation nötig

3. Netzwerk und Firewall

• Feste IP-Adressen für alle Server und interne DNS-Auflösung.

• Ein Load-Balancer Ihres Hauses, der Port 443 (und 80 für die Weiterleitung auf HTTPS) auf die drei Applikations-Nodes verteilt. Alternativ richten wir eine virtuelle IP im Cluster ein; dafür brauchen wir eine zusätzliche freie IP im Subnetz der Applikations-Nodes.

• Empfohlen: Daten-Server in einem eigenen Netzsegment (VLAN), getrennt von den Applikations-Nodes.

• TLS-Zertifikate: ein Wildcard- oder SAN-Zertifikat für alle Subdomains aus Ihrer PKI, oder automatisch über Let's Encrypt, sofern die Subdomains aus dem Internet erreichbar sind.

Benötigte Freigaben

Cluster-interne Ports zwischen den Applikations-Nodes (am einfachsten: Kommunikation zwischen den Nodes vollständig erlauben):

• Kubernetes (RKE2): 6443/TCP, 9345/TCP, 10250/TCP, 2379–2380/TCP, 8472/UDP

• Docker Swarm: 2377/TCP, 7946/TCP+UDP, 4789/UDP

Ausgehender Verkehr ins Internet darf über einen HTTP(S)-Proxy laufen. Bitte für die Ziele aus Abschnitt 7 kein TLS-Aufbrechen (SSL-Inspection) einsetzen, sonst schlagen Image-Downloads und Zertifikatsprüfungen fehl. Die Verbindung zum SLN-Update-Server (TCP auf eine feste IP) muss direkt freigegeben werden.

4. Anforderungen an die Software

• Server:

  • Linux, aktuelles LTS-Release, einheitlich auf allen Servern: Ubuntu 24.04 LTS, Debian 12/13 oder RHEL-kompatibel

  • root- bzw. sudo-Berechtigung

  • Zugang zu den Paketquellen (direkt oder über Ihren Mirror/Proxy)

  • Zeitsynchronisation (NTP)

  • Applikations-Nodes: Swap deaktiviert. Virenscanner/EDR-Agenten müssen die Container-Verzeichnisse ausnehmen und dürfen die Firewall-Regeln des Hosts (iptables/nftables) nicht überschreiben.

• Fernzugriff:

  • Ideal: VPN (Site-to-Site oder Client-VPN) mit SSH-Zugriff auf alle Server, für Installation und spätere Wartung.

  • Alternativ, nicht ideal: ein Jumphost in Ihrem Netz mit SSH-Zugriff auf alle Server, erreichbar über Ihre Fernwartungslösung (z. B. Teamviewer).

  • Eine reine Bildschirmfreigabe (z. B. eine TeamViewer-Sitzung ohne SSH-Zugriff) reicht für Installation und Betrieb eines Clusters nicht aus.

• Clients:

  • aktueller Webbrowser (Edge, Chrome, Firefox oder Safari in einer aktuellen Version)

5. Installations-Vorgehen

Plattform

Wir installieren eine der beiden Varianten. Die Entscheidung treffen wir gemeinsam beim Kick-off.

Komponenten

• Applikations-Cluster:

  • Ingress-Controller als Reverse-Proxy (z. B. Traefik): nimmt den Traffic auf Port 443 an, terminiert TLS und verteilt ihn anhand der Subdomain an den richtigen Dienst

  • VIA Applikation (die eigentliche VIA-Anwendung)

  • VIA Print Applikation (zum Rendern von PDF-Dateien)

  • myVIA Applikation (Online-Antrag, falls beauftragt)

  • VIA Assets (ein Webdienst, der den Clients Grafiken u. Ä. bereitstellt)

  • VIA-ÖPNV (ein Dienst, der ÖPNV-Fahrplanauskunfts-Funktionen für VIA/myVIA bereitstellt)

  • weitere VIA-Microservices, abhängig vom beauftragten Funktionsumfang (die konkrete Liste erhalten Sie mit dem Installationsplan)

  • Monitoring und Logging (Prometheus, Grafana, Loki), damit wir Auslastung und Fehler früh erkennen

• Daten-Server:

  • MySQL 8.4 LTS. Wir benötigen MySQL, weil andere Datenbanksysteme (wie Oracle und MSSQL) wichtige Funktionalitäten nicht bieten.

  • S3-kompatibler Dokumentenspeicher (digitale Akte, erzeugte PDFs). Entfällt, wenn Sie einen eigenen S3-Speicher oder ein eigenes DMS bereitstellen.

  • Backup-Jobs: tägliche Vollsicherung der Datenbank plus fortlaufende Sicherung der Binlogs. Damit lässt sich die Datenbank auf einen beliebigen Zeitpunkt zurücksetzen, auch teilweise. Dokumente werden getrennt gesichert.

  • Optional ein zweiter Daten-Server als Replikat. Fällt der primäre Daten-Server aus, schwenken wir auf das Replikat um.

Subdomains

Alle Subdomains zeigen auf den Load-Balancer bzw. die virtuelle IP. Der Ingress leitet den Traffic anhand der Subdomain an den richtigen Dienst:

• für die VIA-Applikation
  z. B. app.domain.de

• für die myVIA-Applikation (falls beauftragt)
  z. B. antrag.domain.de

• für die Assets
  z. B. assets.domain.de

• für die Print-Applikation
  z. B. print.domain.de

• für die ÖPNV-Applikation
  z. B. oepnv.domain.de

• für das Monitoring (nur intern)
  z. B. monitoring.domain.de

Ablauf

1. Kick-off: Entscheidung Kubernetes oder Docker Swarm, Netzplan, Subdomains, Zertifikate.

2. Sie stellen Server, Netz, Firewall-Freigaben, DNS und Fernzugriff bereit (siehe Checkliste in Abschnitt 9).

3. Wir installieren Cluster und Daten-Server inkl. Monitoring und Backup-Jobs.

4. Wir installieren VIA, myVIA und die Microservices und übernehmen bei Bedarf Bestandsdaten.

5. Gemeinsame Abnahme inkl. Ausfalltest (ein Applikations-Node wird abgeschaltet) und Test-Wiederherstellung aus einem Backup.

Die Installation dauert ca. eine Woche, sofern die Checkliste vor Beginn vollständig erfüllt ist.

6. Freigabe von VIA nach außen

• VIA muss mindestens aus Ihrer privaten Netzwerkumgebung erreichbar sein. Stadt/Landkreis-Mitarbeitende sollten also auf die Subdomains zugreifen können.

• Wenn auch das Schul-Portal und das Unternehmer-Portal von VIA genutzt werden soll (was wir empfehlen), dann muss die Applikation auch von außerhalb erreichbar sein. VIA bringt hier ein umfangreiches Rechte- und Sicherheitsmanagement mit.

• Punkt 1 und 2 treffen auch auf die Applikationen "Print" und "Assets" zu.

• myVIA sollte insgesamt nach außen freigegeben werden, da diese Applikation den Eltern bereitgestellt wird.

• Die externe Freigabe kann gern über Ihre DMZ bzw. einen vorgeschalteten Reverse-Proxy oder eine WAF erfolgen. Weiterleitung, Header und Zertifikate stimmen wir dann gemeinsam ab.

• VIA und myVIA nutzen dieselbe Datenbank und rufen gegenseitig Funktionen auf. Beide laufen deshalb im selben Applikations-Cluster.

• Der Daten-Server wird nie nach außen freigegeben, sondern ist nur aus dem Applikations-Cluster erreichbar.

7. Zugriff auf externe Ressourcen

VIA und seine Subsysteme greifen auf externe Ressourcen zu, um einen Teil ihres Funktionsumfangs bereitzustellen. Diese Ressourcen müssen von den Applikations-Nodes aus erreichbar sein (nur ausgehend).

1. Update-Server im Rechenzentrum von SLN (auf eine feste IP per TCP, die wir Ihnen nennen)
   Dort stellen wir Informationen zu Updates bereit, damit VIA sich selbst updaten kann.

2. GitLab oder Github Container Registry (gitlab.com, registry.gitlab.com, github.com, ghcr.com)
   Dort stellen wir neue VIA-Versionen in Form von Images bereit. Alternativ kann ein Image-Spiegel in Ihrem Netz (z. B. Harbor) diese Images beziehen; dann braucht nur der Spiegel den Zugriff.

3. Deutsche Bahn oder Delfi (bahn.de / https://www.delfi.de/de/leistungen-produkte/ihre-fahrplanauskunft/)
   Von dort bezieht VIA per Cron die Sollfahrplandaten Ihrer Region und kann Fahrplanauskünfte verarbeiten.

4. GraphHopper & OpenStreetMap
   Routen-Berechnung bspw. für die Distanz und Zeit von Schulwegen und Taxi-Touren. Ohne diesen Zugang funktionieren Routen- und Entfernungsberechnungen nicht.

5. Paketquellen des Betriebssystems und der Container-Plattform
   Für Sicherheitsupdates, alternativ über Ihren internen Mirror. Das gilt auch für den Daten-Server; weiteren Internetzugriff braucht er nicht.

6. Optional: Let's Encrypt (automatische Zertifikate) und Alarmierung an SLN (nur technische Metriken wie Auslastung und Fehlerraten)

8. Betrieb und Verantwortlichkeiten

9. Weiteres

Warum Kubernetes oder Docker Swarm?

Beide Plattformen machen das Verwalten von komplexer Software, die aus mehreren Microservices besteht, einfacher. Läuft ein Dienst auf mehreren Servern, führt der Ausfall eines Servers nicht zum Ausfall von VIA. Kubernetes kann zusätzlich anhand der Last skalieren: Wird bspw. VIA sehr intensiv genutzt, fährt Kubernetes eine weitere VIA-Instanz hoch und verteilt die Last auf mehrere Container. Auch Updates sind deutlich einfacher, weil die Plattform die neuen Images von unserem Update-Server zieht und sie ohne Unterbrechung ausrollt. Die Installation ist etwas aufwändig, darum übernehmen wir diesen Teil. Der Betrieb ist später nahezu wartungsfrei.

Warum die Trennung von Datenbank und Applikation?

• Ausfallsicherheit: Die Applikations-Server halten keine Daten. Einer kann ausfallen, gewartet oder ersetzt werden, ohne dass Daten betroffen sind.

• Sicherheit: Die Datenbank liegt in einer eigenen Netzzone und ist weder aus dem Internet noch aus Ihrem Büronetz erreichbar.

• Planbare Leistung: Die Datenbank hat eigene, garantierte Ressourcen. Lastspitzen, etwa beim Rendern eines Serienbriefs, bremsen sie nicht aus.

• Einfache Backups: Gesichert werden muss nur der Daten-Server, und zwar gezielt (Datenbank und Dokumente getrennt) statt als Snapshot ganzer Server.

• Risikoarme Updates: Anwendungs-Updates verändern die Datenbank-Infrastruktur nicht.

Wünschenswertes

Aus Erfahrung wissen wir, dass die Installation solch komplexer Systeme über eine Fernwartung aufwändig ist. Unsere Entwickler müssen während der Installation mehrmals täglich auf die Server zugreifen. Darum ist eine dauerhafte VPN-Verbindung ideal, auch für spätere Wartungen.

Die Wartung der Datenbank ist im Wartungspaket von VIA inbegriffen und obliegt somit uns. VIA bringt umfangreiche Tools zur Datenbank-Administration mit, jedoch wäre zusätzlich ein Datenbank-Verwaltungsprogramm wünschenswert, bspw. phpMyAdmin über eine eigene, passwortgeschützte und nur intern erreichbare Subdomain. Alternativ wäre ein auf dem Jumphost installiertes DB-Verwaltungsprogramm wünschenswert.

Checkliste vor Installationsbeginn

• ☐ 3 Applikations-Nodes und Daten-Server (ggf. Replikat) gemäß Abschnitt 2 bereitgestellt, Applikations-Nodes auf unterschiedlichen physischen Hosts

• ☐ Betriebssystem installiert, root/sudo-Zugang für SLN eingerichtet

• ☐ Backup-Ziel bereitgestellt

• ☐ Firewall-Freigaben gemäß Abschnitt 3 und 7 eingerichtet

• ☐ Load-Balancer oder freie IP für die virtuelle IP vorhanden

• ☐ Subdomains im DNS angelegt, TLS-Zertifikat vorhanden (oder Let's Encrypt möglich)

• ☐ SMTP-Relay benannt (falls E-Mail-Versand genutzt wird)

• ☐ VPN oder Jumphost mit SSH-Zugriff für SLN eingerichtet und getestet

Warum Sie ein Hosting durch SLN erwägen sollten

Lastverteilung

VIA ist eine komplexe Software, bestehend aus mehreren Modulen (Microservices “MS”). Jeder MS hat eine dedizierte Aufgabe und braucht zu unterschiedlichen Zeiten unterschiedliche Ressourcen.

Unsere eigene Plattform wurde speziell für die Architektur von VIA entwickelt. Jeder MS kann so optimal betrieben werden und bspw. sich Leistung nehmen, wenn er es braucht. Die Plattform hat dabei Zugriff auf einen Pool von Servern, die dynamisch hinzugefügt und wieder abgeschaltet werden können.

Ein Beispiel:
Unsere Print-Applikation rendert PDF-Dateien, bspw. Bescheide. Die meiste Zeit des Tages wird sie nicht verwendet. Wenn Sie allerdings einen Serienbrief erstellen, bspw. mit 1.500 Empfangenden, braucht die Print-Applikation für kurze Zeit sehr viel Leistung.

Unsere Plattform ist in der Lage nicht nur der einzelnen Applikation mehr Leistung zuzuteilen, sondern gleichzeitig auch zusätzliche Applikationen bereitzustellen und so horizontal zu skalieren. Wird diese Leistung nicht mehr benötigt, werden die Ressourcen automatisch wieder reduziert.

Auch wenn sich mit Kubernetes bzw. Docker Swarm auf den von Ihnen bereitgestellten Servern eine Form der Lastverteilung umsetzen lässt, wird dies nicht in dem Umfang möglich sein, wie wir es in unserer eigenen Plattform durchführen können.

Optimierte Komponenten

Wir haben unsere eigene Plattform so weit optimiert, dass wir letztlich sogar die einzelnen Hardwarekomponenten “handverlesen” haben; für Routenberechnung setzen wir bspw. andere CPU ein, als für unsere Datenbanken.

Georedundante Verteilung

Die ganze Plattform läuft verteilt auf drei Rechenzentren. Fällt ein Rechenzentrum aus, führt das weder zu einem Systemausfall, noch zu Datenverlusten. Auch die Datenbanken haben stets einen betriebsbereiten Spiegel in allen Rechenzentren, der automatisch einspringt, wenn es eine Störung gibt.

Backups und Wiederherstellung

Bei einem Hosting sind wir für die Datensicherung verantwortlich. Wir erstellen Datenbank-Backups, die auch eine partielle Wiederherstellung ermöglichen. Außerdem sind die einzelnen Datenbereiche voneinander getrennt: Datenbanken und hochgeladene Dateien werden bspw. getrennt gesichert.

Bei einem Betrieb in Ihrer eigenen Infrastruktur hängt die Qualität der Backups davon ab, wie Ihr Backup-System eingerichtet ist und gepflegt wird. Werden, wie häufig, nur Snapshots ganzer Server gesichert, können Sie nur den kompletten Server auf ein Backup zurücksetzen. Damit können Sie bspw. nicht einzelne Änderungen in den Datenbanken wiederherstellen und verlieren, je nach Einrichtung, auch zwischenzeitlich hochgeladene Dateien.

Einfacher und kostengünstigerer Support

Melden Sie uns Fehler oder benötigen Sie Änderungen, brauchen wir i. d. R. Zugriff auf Ihre VIA-Instanz und nicht selten auch Zugriff auf die Datenbank. Oft müssen wir bei On-Premises-Kunden erst einen Zugriff beantragen, was den Support aufwändiger und langsamer macht. Gleichzeitig bindet es Ressourcen in Ihrem eigenen Haus.

DSGVO-konformes und zertifiziertes Hosting

Unsere Plattform läuft in Rechenzentren der Telekom und damit ausschließlich in Deutschland. Die Telekom ist u. A. ISO 27001 zertifiziert und betreibt viele Services für öffentliche Auftraggeber.

Informationen zum Datenschutz und den Zertifizierungen der Telekom finden Sie hier.