Ein technologischer Exkurs in unseren elevait Software Stack

‍

Die elevait Suite ist auf Skalierbarkeit ausgelegt - sowohl im Hinblick auf neue KI-getriebene Features als auch darauf, dass elevait Kunden & Partner je nach Bedarf mit kleinen sowie großen Datenmengen (Volumen und Geschwindigkeit) arbeiten können. Welche Herausforderungen sich daraus ergeben und wie wir diese bei elevait lösen, wird nachstehend verdeutlicht.

‍

Beispiel

Aktuell benötigen Kunden für die Analyse einer Dokumentenseite innerhalb der elevait Suite maximal 10 Sekunden. Dafür sind ca. 400 Schritte in der ETL (Extraction,Transformation, Laden)-Pipeline inklusive der Inferenz von bis zu 10 Machine-Learning-Modellen erforderlich.

‍

Unser elevait Software-Stack

Ein wesentliches Paradigma für das Design der Softwarearchitektur ist das der Microservices. Es werden alle wesentlichen Funktionen in einzeln nutz- und skalierbaren Webservices gekapselt und als Container bereitgestellt. Die Orchestrierung auf Anwendungsebene und damit die Definition der ETL-Pipelines erfolgt mit dem Werkzeug AI Studio. Nach anfänglichen Tests mit Docker-Swarm erfolgt das Deployment und die Orchestrierung der elevait Suite mittels Kubernetes (K8s).

Da der Betrieb von mehreren K8s-Clustern nicht im Zentrum der eigenen Wertschöpfung liegt, haben wir zusammen mit unserem Partner und Cloud-Provider, der Cloud&Heat Technologies GmbH, eine Lösung gesucht und gefunden. Was uns dabei besonders wichtig war: Das Cluster muss hochverfügbar, gegen Angriffe von außen geschützt, gut in den Block- und Objektspeicher integriert sein, der von Cloud&Heat eigener OpenStack-Distribution bereitgestellt wird, sowie Möglichkeiten zum Monitoring und Senden von Benachrichtigungen anbieten.

Hochverfügbare Cluster durch Master-Knoten

Der Cluster selbst wird mit kubeadm bereitgestellt und ist nur innerhalb eines privaten Netzwerks erreichbar. Drei Master-Knoten ("Multi-Master") sorgen dafür, dass der Cluster hochverfügbar (HA) ist und den Ausfall eines Knotens verkraften kann. Weitere drei VMs fungieren als Gateways und Endpunkt des Clusters. Sie hosten HAProxy als Load-Balancer und keepalived, um den virtuellen öffentlichen Endpunkt zu verwalten. Das private Netzwerk kann über einen wireguard VPN-Tunnel erreicht werden.

Der Cloud Controller Manager bildet die Schnittstelle zur OpenStack-Umgebung. Durch die Verwendung bestimmter Speicherklassen kann ein Blockspeicher dynamisch zugewiesen werden, um einen persistent Volume Claim (PVC) zu erfüllen. Eine PVC ist die Anforderung, persistenten Speicher mit einem bestimmten Typ und einer bestimmten Konfiguration bereitzustellen. Er ist für den Zugriff auf Objektspeicher und die Bereitstellung einer dynamischen Load-Balancer-Ressource (K8s-Servicetyp) verantwortlich. Die Anforderung eines gemeinsam genutzten Dateisystems wurde zunächst durch einen NFS-Provider innerhalb des Clusters erfüllt. Ein großes Blockvolumen wurde mit einem Pod verbunden, der bei Bedarf NFS-Freigaben erstellt. Alle NFS-Freigaben befanden sich somit auf demselben Volume. Probleme wie Performance, fehlende Quotas und keine HA-Fähigkeit führten zur Einführung von Rook, das einen Ceph-Cluster innerhalb des K8s-Clusters erzeugt. Effektiv handelt es sich dabei um einen Ceph-inside-Ceph-Cluster, da der Speicher von Cloud&Heat Ceph einen Replikatzähler für 3 verwendet. Um den Speicher-Overhead zu verringern, wurde die Anzahl der Replikate im Ceph-Cluster von K8s auf 1 gesetzt.

‍

Die phasenweise Clusterkonfiguration

Die Bereitstellung eines neuen Clusters erfolgt in vier Phasen. Phase 1 wird von terraform ausgeführt und erstellt die notwendigen VMs, Sicherheitsregeln und das Netzwerk. In Phase 2 werden die Gateways gebootstrapped, Phase 3 ist das Deployment des Clusters mit kubeadm und Phase 4 einige rudimentäre Smoke-Tests. Die Phasen 2-4 werden von Ansible orchestriert. Die gesamte Clusterkonfiguration ist deklarativ. kube-prometheus schafft eine erstaunlich ausgefeilte Überwachungsumgebung auf der Basis von Prometheus, Grafana und Alertmanager, die auch vom Betriebsteam genutzt wird.

Benutzerspezifische Verschlüsselung durch Secustack

‍

Wir arbeiten mit einem dediziertem Team kontinuierlich an der Sicherheit der Plattform, da die elevait Suite in "Kritischen Infrastruktur" (KRITIS) Umgebungen eingesetzt wird. Managed K8s wird auf SecuStack, einer von secustack entwickelten, sicherheitsgehärteten OpenStack-Version, betrieben. secustack ist eine Kooperation von Cloud&Heat und dem IT-Sicherheitsspezialisten secunet.

So können unsere Kunden und wir von einer Reihe zusätzlicher Sicherheitsfunktionen profitieren:

SecuStack ist Open-Source-basiert und damit auf Quellcode-Ebene auditierbar.
Der Intra-Cloud-Netzwerkverkehr zwischen den Servern innerhalb des Domain Controllers (DCs), auf denen die VMs laufen, ist standardmäßig verschlüsselt. In zukünftigen Versionen werden feinere Stufen der Trennung von Mandanten, die vom Kunden ausgewählt werden, zur Verfügung gestellt werden. So kann sich der Kunde beispielsweise für einen dedizierten Netzwerkverkehr zwischen allen seinen VM entscheiden.
Bei Bedarf können sowohl der Kunde als auch der Betreiber mit der BSI-zertifizierten SINA L3 Box auf den Cluster zugreifen. Diese Funktion ist in "VPN as a Service" (VPNaaS) gekapselt.
Alle Betriebssystem-Images sind kryptografisch validiert. Damit wird die Integrität der K8s-Knoten im Einsatz sichergestellt.

Besonders sensible Benutzerdaten können in verschlüsselten OpenStack-Blockspeicher-Volumes gespeichert werden. Secustack bietet einen ausgeklügelten Umgang mit dem Schlüsselmaterial. Diese benutzerspezifische Verschlüsselung kommt zur allgemeinen Volume-Verschlüsselung aller Geräte im Ceph-Cluster von Cloud&Heat hinzu.
Die Verwendung von Hardware-Unterstützung wie Hardware Security Module (HSM), Intel® Software Guard Extensions (Intel® SGX) und Secure Boot gewährleisten die Integrität des gesamten Hardware- und Software-Stacks. Dies wird in einer der nächsten Versionen berücksichtigt und dem Kunden als Konfigurationsoption angeboten.

Das elevait k8s-Cluster läuft auf dedizierter Hardware in einem Co-Location-Spot im großen Rechenzentrum von Cloud&Heat in Frankfurt am Main. Für die Worker Nodes wurden verschiedene virtuelle Maschinengrößen (Flavors) getestet, um die Hardware-Ressourcen (CP, RAM, GPU) für Datenbank- und Service-Anwendungen optimal zu nutzen.

Nach dem Erreichen des initiales Release läuft die elevait Suite seit nun mehr als 2 Jahren stabil mit minimaler Downtime trotz kontinuierlichen Release-Updates während des Betriebs im Managed K8s Cluster - für eine wachsende Anzahl von Kunden.