Das Fundament hinter Nokkela.

nokkela.host bietet beides, weil beide unterschiedliche Aufgaben lösen: Eine virtuelle Maschine liefert ein vollständiges, isoliertes Betriebssystem auf KVM und Proxmox VE mit frei wählbaren CPU-, RAM- und Disk-Ressourcen; ein Container verpackt eine einzelne Anwendung und bleibt so reproduzierbar und portabel über Docker und Kubernetes. Ältere oder zustandsbehaftete Systeme laufen meist als VM, moderne CI/CD-Workloads als Container. Dedizierte VMs und komplette dedizierte Cluster sind beide möglich.

Der CEPH Block Storage von nokkela.host hält jeden Block repliziert über mehrere Knoten, deshalb nimmt der Ausfall einer einzelnen Platte oder eines einzelnen Knotens das Volume nicht offline. Der Cluster erkennt die fehlenden Kopien und stellt sie selbstständig auf den verbleibenden Knoten wieder her – das ist das Self-Healing. Die Kapazität wächst linear mit weiteren Knoten; Thin-Provisioning belegt nur den tatsächlich genutzten Platz.

Nein – Snapshots auf nokkela.host sind ein schneller Rücksetzpunkt innerhalb desselben CEPH-Clusters, kein unabhängiges Backup. Vor einem Update oder einer Migration sind sie ideal, weil ein Volume schnell auf den vorherigen Stand zurückgeht; sie teilen aber das Schicksal des Clusters, in dem sie liegen. Wir kombinieren Snapshots deshalb mit einem separaten Backup, das wir gemeinsam mit Ihnen im Plattform-Design festlegen.

nokkela.host stellt GPUs in beiden Formen bereit. Per PCIe-GPU-Passthrough erhält eine virtuelle Maschine eine physische Karte exklusiv – passend für Trainingsläufe und große Modelle, die die volle Karte samt Speicher brauchen. Per vGPU wird dieselbe Karte auf mehrere VMs oder Container aufgeteilt, was für Inferenz und Entwicklung meist besser passt. Die KI-Workloads von nokkela.ai laufen genau auf dieser Plattform.

nokkela.host nutzt Live-Migration: Eine laufende virtuelle Maschine wandert auf einen anderen Knoten im Cluster, bevor der Host aus dem Betrieb genommen wird. Da die Disks der VM auf dem gemeinsamen CEPH-Storage liegen und nicht auf dem Host, muss dabei nichts kopiert werden. Der Cluster verteilt sich über mehrere Knoten und Standorte in Deutschland und Finnland; fällt ein Knoten unerwartet aus, startet HA die VM auf einem anderen Knoten neu.

Ja – nokkela.host betreibt Docker und Kubernetes als reguläre Workloads; Container-Plattformen liegen dabei meist auf VMs des Clusters, wodurch die Orchestrierung von der Hypervisor-Schicht getrennt bleibt. Die Isolation greift auf zwei Ebenen: Netzsegmentierung und Ressourcen-Limits je Container, damit ein Workload seinen Nachbarn nichts wegnimmt. Die Umgebungen sind CI/CD-fähig und die Agenten-Laufzeiten von nokkela.io nutzen dasselbe Modell.

nokkela.host wird mit Monitoring, Logging und Alerting über den gesamten Storage- und Compute-Stack überwacht, sodass Kapazitätsverläufe und Störungen früh sichtbar werden. Die Hosts sind gehärtet, die Netze segmentiert und der Verkehr verschlüsselt; das CEPH-Cluster meldet seinen Replikationszustand selbst. Eine öffentliche Statusseite für die Nokkela-Services ist von jeder Seite des Verbunds verlinkt und wer auf einen Alarm reagiert, betreibt die Plattform auch.