Architektur-Deep-Dive: Wie wir mit KVM und API-First eine moderne Compute-Plattform gebaut haben

Der Markt für Cloud-Hosting ist voller Buzzwords. Doch in der Praxis zählen für Entwickler, DevOps-Teams und Unternehmen 2024 vor allem drei Dinge: planbare Performance, nahtlose Automatisierung und transparente Kosten.
Foto aus dem Rechenzentrum mit den Icons einer Cloud und Servern.

Genau aus diesem Grund haben wir unsere frühere "Cloud Server"-Plattform von Grund auf neu gedacht und zu einer offenen, API-first "Compute"-Plattform umgebaut. Es war ein Schritt weg von starren monatlichen Kosten, hin zu granularen, greifbaren Ressourcen: vCPU, RAM, Storage und Netzwerk.

In diesem technischen Deep Dive erklären wir, warum dieser Wandel notwendig war, wie die neue Architektur aussieht und was Sie als Nutzer davon haben.

Was erwarten Nutzer heute von einer Cloud?

Der Auslöser für unseren Neustart war klares Kundenfeedback, das sich mit unseren eigenen technischen Zielen deckte. Die Anforderungen an eine moderne Infrastruktur sind:

  • Planbare Performance: Nutzer wollen sich darauf verlassen, dass die gebuchte Leistung (z.B. 4 vCPUs) auch konstant zur Verfügung steht, ohne "noisy neighbors" oder unklare Fair-Use-Policys.

  • Einfache Automatisierung: Infrastruktur muss sich wie Code behandeln lassen (Infrastructure as Code). Ein gutes Web-Panel ist Pflicht, reicht aber allein nicht mehr aus; die Plattform muss vollständig per API (z.B. via Terraform oder Ansible) steuerbar sein.

  • Transparenz & Flexibilität: Statt undurchsichtiger Pakete wünschen sich Nutzer klare Ressourcen (vCPU, RAM, Storage) zu klaren Preisen.

Unsere alte Softwarebasis war für diese Anforderungen zu komplex geworden. Statt weiter Schichten hinzuzufügen, haben wir entschlackt und die Plattform auf ein neues Fundament gestellt.

Ein technischer Deep Dive: Wie ist die neue Plattform aufgebaut?

Um diese Ziele zu erreichen, setzen wir auf offene Standards und eine robuste, entkoppelte Architektur.

Das Fundament: Warum wir auf KVM setzen

Im Compute-Layer (also der Rechenebene) setzen wir konsequent auf den Industriestandard KVM (Kernel-based Virtual Machine). Wir verzichten bewusst auf proprietäre Experimente und nutzen die native Linux-Kernel-Technologie, die auch das Rückgrat der großen Hyperscaler bildet. Die Entscheidung für KVM fiel aus pragmatischen Gründen:

  • Performance: Der "Overhead" durch die Virtualisierung ist minimal.

  • Stabilität: KVM ist technologisch ausgereift, millionenfach erprobt und extrem robust.

  • Kompatibilität: Als offener Standard verhindert KVM einen Vendor-Lock-in.

Orchestriert wird die gesamte Plattform von Apache CloudStack, das wir an entscheidenden Stellen für unsere Anforderungen angepasst haben. Unser Anspruch ist es, robuste Grundbausteine (vCPU, RAM, Netzwerk) bereitzustellen, auf denen unsere Kunden souverän eigene Plattformen – bis hin zu Kubernetes-Clustern – betreiben können.

Netzwerk & Verfügbarkeit: Was passiert bei einer Host-Wartung?

Ein häufiges Problem bei klassischen Servern ist die Downtime bei Wartungsfenstern. Unsere neue Plattform löst dies durch Live-Migration: Virtuelle Maschinen (Ihre Instanzen) können im laufenden Betrieb und ohne spürbare Unterbrechung von einem physischen Host-System auf ein anderes verschoben werden.

Das Netzwerk dahinter ist massiv ausgelegt: Jeder Host-Node ist mit 50 Gbit/s angebunden und standardmäßig durch eine leistungsstarke DDoS-Protection auf Netzwerkebene abgesichert. Sie können Ihre Instanzen in komplett privaten Netzen betreiben (ideal für Backend-Dienste) oder mit öffentlichen IPv4- und IPv6-Adressen ausstatten.

Storage: Wann brauche ich HA-Storage und wann High-IOPS?

Keine Anwendung ist wie die andere. Eine Web-App braucht ausfallsicheren Speicher, eine Datenbank hingegen braucht maximale I/O-Leistung. Wir lösen dies mit einem klaren Zwei-Tier-Modell:

  1. HA-Storage (Hochverfügbar):

    • Technologie: Basiert auf Ceph, einem verteilten Storage-System.

    • Funktion: Die Daten werden über das Netz auf mehrere physische Systeme repliziert. Fällt ein Speicher-Node aus, läuft Ihre Instanz weiter.

    • Einsatz: In der Praxis erreichen wir rund 2.000 IOPS – ideal für Webserver, Standardanwendungen und Systeme, bei denen Verfügbarkeit wichtiger ist als rohe I/O-Leistung.

  2. HI-Storage (High-IOPS):

    • Technologie: Lokal angebundene NVMe-SSDs.

    • Funktion: Der Speicher befindet sich direkt im Host-System der Instanz, was die Latenz drastisch reduziert.

    • Einsatz: Hier erreichen wir typische Werte von bis zu 8.000 IOPS. Perfekt für rechenintensive Datenbanken, Caching-Server oder Big-Data-Workloads.

Ergänzend können Sie flexiblen Block-Storage (bis zu 10 TB pro Volume) an Ihre Instanzen anbinden, um den Speicherplatz bedarfsgerecht zu erweitern.

Die wichtigste Frage: Was kostet Flexibilität?

Ein zentraler Punkt der neuen Plattform ist die Abrechnung. Statt fester Monatspreise für starre Pakete rechnen wir stundengenau ab. Dieser Wechsel macht völlig neue Szenarien wirtschaftlich:

  • Saisonale Peaks: Betreiben Sie zusätzliche Webserver nur während des Weihnachtsgeschäfts.

  • CI/CD-Pipelines: Starten Sie Runner nur für die Dauer eines Release-Fensters.

  • Test- & Staging: Klonen Sie Ihre Produktion für einen zweistündigen Test und löschen Sie die Instanz wieder.

Der entscheidende Vorteil: Abgeschaltete Instanzen erzeugen keine Compute-Kosten (nur noch minimale Speicherkosten für den belegten Speicherplatz). Sie zahlen ausschließlich die tatsächliche Nutzung.

Wie automatisiere ich meine Infrastruktur?

Unsere Plattform folgt dem API-First-Ansatz. Das bedeutet technisch: Das komfortable Web-Panel, das Sie im Browser nutzen, ist selbst nur ein Client unserer API. Daraus ergibt sich für Sie die Garantie, dass jede Funktion, die per Klick verfügbar ist, auch per Code gesteuert werden kann. Dies ermöglicht echte "Infrastructure as Code" (IaC) Workflows:

  • Terraform: Beschreiben Sie Ihre gesamte Infrastruktur (Server, Netzwerke, Firewalls) deklarativ in Code.

  • Ansible: Konfigurieren Sie Ihre Systeme automatisiert und wiederholbar.

Für das Monitoring der Kernplattform setzen wir auf Zabbix (lokal) und iLert (Alarmierung), um den Betrieb DSGVO-konform innerhalb der EU sicherzustellen. Wir überwachen Traffic, CPU-Auslastung, Plattenzustände und Temperaturen, damit Sie sich auf Ihre Anwendungen konzentrieren können.

Transparenz: Was waren die größten technischen Hürden?

Ein Neuaufbau dieser Größenordnung verläuft nie reibungslos. Unsere größte Herausforderung waren komplexe VXLAN-Effekte in Kombination mit White-Box-Switches unter SONiC (Software for Open Networking in the Cloud).

Fehlerhafte Flags im Netzwerk-Stack führten initial zu sporadischen Paketverlusten im Overlay-Netzwerk. Bis ein Hersteller-Patch verfügbar war, mussten unsere Engineers tief im Linux-Netzwerk-Stack ansetzen und gezielte Filter im Kernel implementieren. Das hat funktioniert – allerdings um den Preis eines verschobenen Go-Lives. Auch Edge-Case-Bugs in CloudStack sowie Treiber-Abhängigkeiten haben uns gefordert. Der positive Effekt für Sie: Unsere Test- und Staging-Pipelines sind heute deutlich ausgereifter, was die Stabilität der Plattform spürbar erhöht.

Ihr Vorteil: Was bringt Ihnen die neue Compute-Plattform?

Für Ihren Betriebsalltag bedeutet das:

  • Planbare Performance durch klare Ressourcenzuteilung und dedizierte Ressourcen je nach "Flavor".

  • Kein Vendor-Lock-in dank offener Standards (KVM, CloudStack, Ceph).

  • Echte Automatisierung (IaC) über eine durchdachte API, Terraform und Ansible.

  • DSGVO-Konformität durch Betrieb und Monitoring in Deutschland/EU.

  • Weniger Wartungsaufwand für Ihre Teams dank Live-Migration und robuster Basiskomponenten.

Typische Einsatzszenarien unserer Kunden:

  • E-Commerce: Kurzfristiges Abfangen von Lastspitzen (z.B. Black Friday).

  • DevOps: Schnelles Aufsetzen von Test-Umgebungen in CI/CD-Pipelines.

  • Analytics: Zeitweises Buchen von High-IOPS-Instanzen für ETL-Jobs.

  • SaaS: Strikte Mandanten-Trennung über Private Networks.

  • Kubernetes: Aufbau von Clustern auf standardisierter Compute-Basis ohne "Sonderlocken".

Fazit

Der Schritt von einer klassischen "Cloud Server"-Struktur zu einer offenen "Compute"-Plattform war für uns kein bloßes Rebranding, sondern ein technischer Neustart auf Basis bewährter Standards. Heute steht eine offene, leistungsfähige und skalierbare Plattform auf eigener Hardware bereit – mit transparenter Abrechnung, einer belastbaren Architektur und einem klaren Fahrplan für zukünftige Anforderungen.

Wenn Sie eine Migration planen, ein neues Projekt starten oder sich unabhängiger von den Hyperscalern aufstellen wollen, sprechen Sie uns an: Unser Tech-Team denkt die Lösung gern mit Ihnen durch.

FAQ

Sind meine Daten DSGVO-konform geschützt?

Ja. Als deutscher Anbieter betreiben wir unsere eigene Hardware ausschließlich in zertifizierten Rechenzentren in Deutschland (oder der EU). Auch das Monitoring und die Alarmierung erfolgen über EU-Dienste, sodass die Datenhoheit zu jeder Zeit gewahrt bleibt.

Wie funktioniert die stundengenaue Abrechnung?

Sie zahlen nur für die Ressourcen, die Sie tatsächlich nutzen. Wenn Sie eine Instanz stoppen (herunterfahren), fallen keine Kosten für CPU und RAM an – Sie zahlen lediglich eine minimale Gebühr für den belegten Speicherplatz. Das macht kurzfristige Testumgebungen oder Skalierung bei Lastspitzen sehr kosteneffizient.

Wann sollte ich HA-Storage und wann High-IOPS (NVMe) wählen?

Nutzen Sie HA-Storage (Ceph) für Webserver und kritische Dienste, die eine hohe Verfügbarkeit benötigen, da Daten hier mehrfach repliziert werden. Greifen Sie zu HI-Storage (lokale NVMe) für Datenbanken oder Caching-Dienste, die maximale Schreib-/Lesegeschwindigkeit (bis zu 8.000 IOPS) und geringste Latenzen erfordern.

Kann ich die Cloud-Infrastruktur mit Terraform oder Ansible steuern?

Ja. Da unsere Plattform dem API-First-Ansatz folgt, lassen sich alle Funktionen automatisieren. Wir unterstützen gängige "Infrastructure as Code"-Tools wie Terraform und Ansible, damit Sie Deployments wiederholbar und skalierbar gestalten können.

Nach oben