Von Cloud zu Compute: Wie wir bei 23M unsere Plattform neu gedacht haben [Anzeige]

Viele von euch haben den Trend weg von US-Cloud-Anbietern hin zu europäischen Alternativen in den letzten Monaten mitverfolgt. Vor diesem Hintergrund stellen wir unsere neu aufgesetzte Plattform vor und verraten, welche Ziele wir verfolgt haben, welche Hürden wir nehmen mussten und warum sich der Aufwand gelohnt hat.

Too long, did not read!?

Vorweg ein kleines TL;DR, falls euch nur ein Überblick interessiert.

• Neuaufbau 2024: Architektur entschlackt, auf Open Source Software gesetzt, Fokus auf Performance und einfache Bedienung.
• Stundengenaue Abrechnung: Ideal für Tests & Staging, zeitlich begrenzte Projekte oder variable Auslastung – bezahlt wird nur die tatsächliche Laufzeit.
• Technik: KVM-Hypervisor, modifiziertes Apache CloudStack, 50 Gbit/s je Node, Live-Migration, IPv6, Private Networks, DDoS-Protection.
• Storage-Tiers: HA-Storage (Ceph, bis ~2.000 IOPS) und HI-Storage (lokal, bis ~8.000 IOPS) plus Block-Storage bis 10 TB.
• Automatisierung: Einfach lösbar via API zum Beispiel mit Terraform oder Ansible.
• Monitoring: Zabbix + iLert, DSGVO-konform.
• Roadmap: GPU-Nodes, Dedicated Cores.

Warum der Neustart?

Der Impuls kam aus zwei Richtungen: Kundenfeedback und eigene Anforderungen. Viele Bestandskunden nutzten die alte Cloud bereits intensiv und wünschten sich mehr Flexibilität, planbare Performance und eine einfache Automatisierung. Gleichzeitig waren wir mit der damaligen Softwarebasis unzufrieden.

Also haben wir 2024 die komplette Plattform neu gedacht – mit dem Ziel, heute mehr Anwendungsfälle abzudecken und morgen sauber skalieren zu können.

Aus “Cloud” wurde Compute: weniger Buzzwords, mehr klare Ressourcen (vCPU, RAM, Storage, Netzwerk) und volle Transparenz bei Technik und Abrechnung.

Leitplanken aus der Praxis

Aus Workshops mit unserem Technik-Team und Power-Usern entstanden fünf Kernpunkte, die das Projekt geprägt haben:

1. Bestmögliche Performance
2. Nutzerfreundliche Instanzverwaltung
3. Einfache Automatisierungen
4. Hohe Skalierbarkeit
5. Vollständige Inhouse-Hardware

Ein großer Umbruch: der Wechsel vom Pauschalpreis auf stundengenaue Abrechnung. Das ermöglicht es, Instanzen kurzfristig zuzuschalten (zum Beispiel für saisonale Peaks) und später wieder kostenfrei zu deaktivieren. Da hatten wir lange noch auf feste monatliche Preise gesetzt und hier einen neuen Weg eingeschlagen.

Architektur im Überblick

Kerntechnologie: KVM

Im Kern unserer neuen Compute-Plattform arbeitet KVM (Kernel-based Virtual Machine) – ein Kernel-Modul des Linux-Kernels.

Vorteile:

• geringe Latenzen
• hohe Stabilität & Performance
• breite Unterstützung in der Community
• unabhängig von proprietären Lizenzen
• ideal automatisierbar

Plattformsteuerung: Apache CloudStack

Für die Steuerung setzen wir auf Apache CloudStack, das wir leicht modifiziert haben.

• seit Jahren etabliert
• durch eigene Patches/Fixes an unsere Anforderungen angepasst
• bewusst schlank gehalten, um maximale Stabilität und geringen Overhead bei der VM-Verwaltung zu garantieren.
• User können eigene Stacks (zum Beispiel Kubernetes) flexibel aufsetzen

Netzwerk

• 50 Gbit/s Anbindung je Node
• Moderne Architektur: VXLAN-Overlay und BGP-Routing bis zum Host (BGP to the host) für maximale Redundanz.
• Standard: DDoS-Protection
• Wahlweise Private Networks oder öffentliche IPv4/IPv6
• Live-Migration: VMs verschiebbar ohne spürbare Downtime

Storage

• HA-Storage (Ceph): bis ~2.000 IOPS, hochverfügbar, über Netzwerk repliziert
• HI-Storage (lokal): bis ~8.000 IOPS, maximale I/O-Leistung
• Block-Storage-Volumes: bis 10 TB Größe

Automatisierung & Monitoring

• REST-API, Unterstützung zum Beispiel für Terraform & Ansible
• Monitoring mit Zabbix
• Alarmierung/Eskalation via iLert (EU-Anbieter)
• Überwachung: Traffic, CPU-Last, Festplattenzustände, Temperaturen

Herausforderungen? Gab es.

Ein Großprojekt wie der Neuaufbau unserer Compute-Plattform läuft nie komplett reibungslos. Die wohl größte technische Hürde waren VXLAN-Probleme in Kombination mit unseren White-Box-Switches, auf denen SONiC als Switch-Betriebssystem lief. VXLAN ist ein Tunnelprotokoll, das es erlaubt, Netzwerke über bestehende Layer-3-Infrastrukturen zu spannen – essenziell für flexible Cloud-Topologien. In unserem Fall setzten defekte Flags in der Switch-Software falsche Signale, was zu unvorhersehbarem Verhalten im Overlay-Netz führte.

Solche Fehler sind besonders knifflig, weil sie nicht sofort als klarer “Defekt” sichtbar werden, sondern sich in Form von sporadischen Paketverlusten oder unerklärlichen Latenzspitzen zeigen. Bis ein Hersteller-Patch verfügbar war, mussten wir tief ins Linux-Netzwerk-Stack eintauchen und gezielte Filter-Regeln im Kernel implementieren, um die fehlerhaften Pakete abzufangen. Das hat funktioniert – bedeutete aber auch, dass wir den Go-Live um mehrere Monate verschieben mussten.

Neben den Netzwerkproblemen gab es weitere Baustellen:

• Bugs in der CloudStack-Software, die in unserer speziellen Konfiguration auffielen
• Abhängigkeiten von Drittherstellern, etwa bei Treibern und Firmware, die wir in unseren Rollout-Zeitplan einarbeiten mussten

Diese Verzögerungen waren zwar ärgerlich, hatten aber einen positiven Nebeneffekt: Wir konnten unsere Test- und Staging-Pipelines deutlich ausbauen. So haben wir nicht nur die Plattform stabil live gebracht, sondern auch eine solide Basis für zukünftige Erweiterungen geschaffen.

Vorteile auf einen Blick

• Planbare Performance durch klare Ressourcen-Zuteilung
• Dedizierte Ressourcen je nach Flavor
• Kein Vendor-Lock-in dank Open Source (KVM, CloudStack, Ceph)
• Einfache Automatisierung via Terraform/Ansible/API
• DSGVO-konformer Betrieb
• Weniger Wartungsaufwand auf Kundenseite – Plattform läuft größtenteils ausfallfrei

Roadmap

Der aktuelle Stand ist für uns kein Endpunkt, sondern der Ausgangspunkt für den nächsten Entwicklungsschub. Wir sehen die Compute-Plattform als lebendiges Produkt, das kontinuierlich wächst und sich an neue Anforderungen anpasst.

Ein wichtiger Meilenstein wird die Einführung von GPU-Nodes sein. Damit richten wir uns gezielt an Unternehmen, die rechenintensive Workloads wie Machine Learning, KI-Modelle, Video-Rendering oder wissenschaftliche Simulationen betreiben. Diese Instanzen sollen – wie unsere CPU-Flavors – transparent abrechenbar und einfach über Panel oder API buchbar sein.

Ebenfalls auf der Agenda stehen Dedicated Cores. Hier geht es um Szenarien, in denen nicht nur die Anzahl der vCPUs, sondern auch deren garantierte Exklusivität entscheidend ist, beispielsweise bei latenzkritischen Anwendungen, Echtzeit-Verarbeitung oder besonders sensiblen Datenpipelines.

Auf Netzwerkebene planen wir zusätzliche Anbindungen und höhere Bandbreitenoptionen, um auch für Kunden mit extremem Traffic-Aufkommen oder speziellen Peering-Anforderungen interessant zu bleiben.

Und nicht zuletzt wollen wir das Webpanel weiterentwickeln: von einer klaren Übersicht aller Ressourcen bis hin zu Self-Service-Tools, die fortgeschrittene Konfigurationen ermöglichen, ohne in die API einsteigen zu müssen. Parallel dazu fließt kontinuierlich Kundenfeedback in neue Features und Optimierungen ein – genau dieser Dialog war der Schlüssel zum jetzigen Stand und wird auch den nächsten Schritten die Richtung geben.

Schlusswort

Der Schritt von “Cloud” zu Compute war für uns kein Rebranding, sondern ein technischer Neustart. Wir haben die Plattform von Grund auf so gestaltet, dass sie offen, leistungsfähig und langfristig skalierbar ist – auf vollständig eigener Hardware, mit offenen Standards und einer klaren, nachvollziehbaren Architektur.

Wir wissen: Jedes Unternehmen hat individuelle Anforderungen. Genau hier liegt unsere Stärke: Wir liefern keine Einheitslösungen, sondern entwickeln mit unseren Kunden die passende Compute-Architektur – ob für Migrationen, neue Projekte oder den Ausbau bestehender Umgebungen.

Mehr Einblicke gewünscht?

23M möchte der ComputerBase-Community auch in Zukunft gerne mehr Einblicke in das Unternehmen und den Alltag eines Hosters geben! Was interessiert euch besonders, welche Fragen habt ihr? Wünsche, Wissenslücken und Ideen sind in den Kommentaren gerne gesehen.

Und wer mehr erfahren möchte oder konkrete Szenarien besprechen will, für den steht unser Technik-Team jederzeit für ein Gespräch bereit.

• Inhouse Entwickler: Kreativität trifft technische Präzision [Anzeige]
• Techniker im Rechenzentrum: Viel mehr als nur Server schrauben tagein, tagaus [Anzeige]
• 23M: Das ist der Server-Hoster hinter ComputerBase.de [Anzeige]