Aktuelles Thema:

OSL im Wettbewerb

November 2025

“Der Vergleich ist das Ende des Glücks und der Anfang der Unzufriedenheit.”
(Søren Kierkegaard)

Prinzipiell genügen das Verständnis eines technischen Konzepts, das Können der beteiligten Akteure und eine vertrauensvolle Zusammenarbeit für die erfolgreiche Bewältigung einer Aufgabe. Dass dies funktioniert, hat OSL zusammen mit seinen Partnern in etlichen erfolgreichen Projekten - von klein bis wirklich sehr groß - unter Beweis gestellt. Dennoch werden wir oft nach Vergleichen und Abgrenzungen gefragt - ein heißes Eisen, denn naturgemäß sind wir nicht die Spezialisten für die Lösungsangebote anderer. Wir wollen also nachfolgend keine direkten Vergleiche anstellen, sondern denen, die es tun wollen, einige Informationen oder auch Sichtweisen an die Hand geben.

Die Konstellation

Wir bieten mit dem OSL Storage Cluster und dem OSL Unified Virtualisation Environment zwei Lösungen an, die wir als "Infrastruktursoftware für das softwaredefinierte Rechenzentrum" bezeichnen, Software also, die es ermöglicht, mit RZ-Hardware die gesteckten Ziele zu erreichen. Dabei geht es um übliche Aufgaben und RZ-Prozesse wie grundlegende Systemadministration, Backup/Recovery, Hochverfügbarkeit, Vernetzung, Virtualisierung, Ressourcenmanagement, Provisionierung, Dokumentation usw. Entsprechend breit wäre das Spektrum der Lösungen, die für etwaige Vergleiche in Frage kämen. Auf der Ebene der Infrastrukturlösungen sind es die Klassiker (über die heute kaum mehr gesprochen wird) wie Veritas Cluster Server (InfoScale) oder Sun Cluster, mit Blick auf die Servervirtualisierung und oder HCI-Lösungen VMware, Nutanix, Open-Source-Lösungen wie OpenStack, Proxmox, Docker, Kubernetes, bei der Speichervirtualisierung DataCore, linux-basierte Technologien wie LVM, Ceph und so weiter. Das Problem ist also weniger ein Mangel an Optionen als vielmehr die enorme Menge und damit die Qual der Wahl.

OSL fokussiert sich darauf, in der Tradition guter deutscher Ingenieurskunst geradlinig und emanzipiert von den Hype-Themen der IT-Metropolen eigenständig vom Problem zur Lösung zu denken und damit möglichst einfache, leistungsfähige und robuste Angebote zu schaffen.

Proxmox und OSL - Historie

Am häufigsten werden wir nach Vergleichen mit Proxmox gefragt. Beide Unternehmen betonen das Thema Einfachheit, sind in Europa ansässig, in etwa gleich alt, unterscheiden sich aber in der Historie und in der Ausrichtung. Nach unserem Verständnis setzt Proxmox ganz klar und seit Anbeginn auf Open Source und in diesem sehr umfangreichen Pool verfügbare Technologien, wobei es am Ende praktisch auf Linux hinausläuft (vgl. www.proxmox.com/de/ueber-uns/ueberuns/unternehmen).

OSL widmete sich von Anfang der Idee der Integration von Speichervirtualisierung und Clustering. Kundschaft dafür gab es nur im kommerziellen Rechenzentrum, speziell für große, unternehmenskritische Anwendungen (OLTP, Datenbanken, Oracle, SAP ...) und auf kommerziellen Plattformen wie Reliant Unix und Sun Solaris (heute Oracle). So waren unsere Ideen eben nicht auf der Basis verfügbarer Open-Source-Software, sondern nur als Eigenentwicklungen umsetzbar. Daraus folgen Unterschiede in grundlegenden technischen Ansätzen, aber auch in den Geschäfts- und Lizenzmodellen, die bis heute fortbestehen. Und: Die grundlegende Erfahrung, dass sich Innovation und neue Ideen (die im Austausch mit Partnern und Anwendern entstehen) mit eigener Entwicklungsarbeit zielgenau umsetzen lassen und dies am Ende wesentliche Faktoren für eine reduzierte Komplexität und schließlich auch für die gemeinsame Autonomie von Anwender und OSL sind, prägt uns bis heute.

OSL hat also von Anfang an Schlüsseltechnologien selbst entwickelt, vorrangig die integrierte Speichervirtualisierungs- und Clusterengine. Weil man das damals so machte (und oft auch heute noch macht), wurde die zentralen Funktionen als Solaris-Kernel-Modul implementiert. Der Firmengründer Bert Miemietz war aber schon frühzeitig davon überzeugt, dass der bessere Weg einer Umsetzung über den Userspace führt und begann bereits 2007 mit einer ersten Umsetzung, damals im Rahmen des RSIO-Projektes. Inzwischen gab es ein komplettes Redesign und heute besitzt OSL mit den Virtual Storage Domains (VSD) eine einzigartige, fortgeschrittene Speichervirtualisierungstechnologie, die partitionierbar, dynamisch ladbar, flexibel und vor allen Dingen portabel ist. So können OSL SC und OSL UVE heute auf Solaris, Linux, SPARC, Intel, AMD (bei Bedarf sind auch andere Plattformen vorstellbar) jeweils gemischt betrieben werden. OSL bietet also keine Linux-Lösungen an, sondern integrierte, eigene Technologien, die auf verschiedenen Plattformen lauffähig sind. Für die Anwender heißt das: Extreme Vereinfachung und langfristige Stabilität, selbst bei einem Wechsel der Plattform.

Open-Source und Nicht-Open-Source

Hier wird nicht selten leidenschaftlich diskutiert, oft mit einem Überschuss an Meinung und einem Mangel an Pragmatismus. Wir sehen beide Modelle als berechtigt und durchaus miteinander vereinbar an. Glaubensgrundsätze wie "nur Open Source garantiert Stabilität, Zuverlässigkeit und Sicherheit" erweisen sich unter technischen, rechtlichen und praktischen Aspekten mitunter genauso schnell als problematisch wie gegenteilige Behauptungen aus dem Lager der kommerziellen Anbieter mit proprietären Lizenzbestimmungen. Die von OSL selbst entwickelte Software wird (zumeist gegen ein moderates Entgelt) unter einer eigenen, fairen, liberalen und konsequent am deutschen bzw. europäischen Recht orientierten Lizenz zur Nutzung angeboten. Das bietet - auch im Vergleich zu Open-Source-Lizenzen - ein hohes Maß an Rechts- und Investitionssicherheit ohne Grauzonen, zumal man auch ohne Subskriptionen die Software unbefristet weiter nutzen darf. Daneben kann das Nutzungsrecht (im Rahmen der Lizenzbestimmungen) weiterveräußert werden. Zusätzlich bietet OSL eine jährlich kündbare Software-Maintenance an, die neben Updates auch Support im Störungsfall beinhaltet.

Mit diesem Modell finanziert OSL seine Entwicklungsarbeit und den Support und kann zugleich ein breites Spektrum in der offenen Systemwelt (Unix/Linux) bedienen. Ethische Leitlinien, Fairness, Nachhaltigkeit, die Einheit von Autonomie und Kooperation im Verhältnis zu den Anwendern sind uns wichtiger als Gewinnmaximierung. Unser wichtigstes Gut: Die Kooperation mit OSL ist erlebbar - wir pflegen den direkten Draht zu Partnern und Anwendern!

Portabilität und Flexibilität

Die OSL-Lösungen werden möglichst plattformneutral entwickelt und laufen heute auf verschiedensten Linux-Distributionen und Solaris-Versionen, auf verschiedensten CPU-Architekturen (auch gemischt). Wesentliche Bestandteile der integrierten Softwarepakete zeigt die nachfolgende Grafik am Beispiel des OSL Storage Clusters.

Storage Cluster

Die erwähnte Plattformneutralität erspart dem Anwender zumeist eine tiefe Einarbeitung in die Besonderheiten des jeweiligen Betriebssystems und größere Aufwände beim Wechsel desselben. Man beachte: Auch Linux ist nicht gleich Linux und nichts ist in der Linux-Welt so beständig, wie die Veränderung. Was auf den ersten Blick vielleicht als nebensächlich erscheint, wie z. B. die Virtual Runtime Environments für generische Applikationen oder das vereinheitlichte VM-Framework mit seinem Support z. B. für Solaris-Zonen, Solaris Kernel-Zones (auch LDoms waren schon einmal enthalten), VirtualBox, KVM/qemu erweist sich am Ende als praktisch: Komplexität wird reduziert und ein - je nach Situation ggf. vorteilhafter - Umstieg auf andere Lösungen erleichtert. So ist es z. B. möglich, mit geeigneten Setups VMs ohne weiteren Eingriff zwischen KVM und VirtualBox, zwischen Linux und Solaris zu verschieben.

Die Virtualisierungs- und Clusterengine des OSL Storage Clusters eignet sich für generische Workloads, Bare-Metal-Applikationen (Datenbanken, SAP-HANA) genauso, wie für virtuelle Maschinen.

Storage Cluster Applikationen

Auch virtuelle Maschinen können sich in die Clusterengine des OSL SC integrieren - wir sprechen dann von "Virtual Nodes".

Speichervirtualisierung

Die VSD-basierte Speichervirtualisierung kann sowohl autonom, als auch in hybriden Setups mit RAID-Systemen genutzt werden und auch an andere Welten wie etwa Ceph andocken. Somit hat der Anwender einen enormen Gestaltungsspielraum, kann die für seine Welt passende Kombination auswählen, Performance und Kosten optimieren.

Im OSL-Storage-Cluster stehen für klassische Konstellationen u. a. folgende Möglichkeiten zur Verfügung:

Storage Cluster mit SAN

Die Nutzung der OSL-Speichervirtualisierung entfaltet auch in Verbindung mit zentralen RAID-Systemen vielfachen Nutzen: Live-Datenmigration, kostengünstige und performante Datenspiegelung, atomare Splits, Backup- Restore-Szenarien, hostseitige, einfache Administration in alltäglichen Belangen wie der Bereitstellung oder Vergrößerung von Volumes, Bandbreitensteuerung u.v.m

Es zeichnet sich aber ab, dass heutige schnelle Speichertechnologien einen "kurzen Weg" zur CPU brauchen. Das wird mindestens mittelfristig die Bedeutung einer geeigneten Speichervirtualisierungssoftware erhöhen, weil nur so die Geräte vergleichsweise direkt angesprochen werden können und gleichzeitig eine einfache und flexible Administration und Hochverfügbarkeit darstellbar sind. Zentrale RAID-Systeme bedeuten hier - gleich welche Anbindung gewählt wird - einen Nachteil. Fazit: Die OSL Frameworks kommen prinzipiell ohne RAID-Systeme aus, dennoch können sie vorteilhaft mit diesen zusammenarbeiten - je nach Anwendungsfall.

Linuxbasierte Lösungen / Frameworks ohne eine eigene Speichervirtualisierung greifen an dieser Stelle auf Technologien des Betriebssystems bzw. verfügbare Add-Ons zurück. Bei Proxmox sind das neben dem Linux-LVM:

ZFS bietet viele beeindruckende Funktionen speziell für Dateisysteme oder Fileserver. ZFS besitzt keine Clusterfähigkeiten, Block-I/O wird im Backend analog zu Dateien behandelt. Wer in Clusterumgebungen allein auf eine Replikation per ZFS setzt, wird Kompromisse eingehen müssen, z. B. bei der Absicherung gegen Transaktionsverluste, die über Snapshots und "Send/Receive" allein nicht lückenlos möglich ist.
Ceph ist eine skalierbare, verteilte Speicherlösung. Designschwerpunkt ist verteilter Objekt-Speicher. Das, die notwendigen Voraussetzungen, sowie eine "unter der Haube" nicht geringe Komplexität sind im Auge zu behalten. Ob der Versuch, was anderenorts im großen Maßstab Erfolg hat, im kleinen umzusetzen, für die eigenen Nutzungsszenarien eher Chance oder Risiko ist, ist sorgfältig abzuwägen.

Am Ende bleibt festzuhalten, dass man auch ohne weitere komplexe Technologien mit der OSL-Speichervirtualisierung viele Aufgaben bewältigen kann, dass sowohl OSL SC als auch OSL UVE aber auch mit anderen Technologien (z. B. RAID-Systeme, Dateisysteme, ZFS, Ceph) kooperieren und deren Einsatzspektrum bisweilen vergrößern können.

OSL RSIO - Remote Storage I/O

Kurz gesagt handelt es sich um ein für moderne Netzwerke und Clusterumgebungen entwickeltes Block-I/O-Protokoll mit Cross-Plattform-Fähigkeiten. Der erste Anwendungsfall war es, sich von der Notwendigkeit eines FC-Netzwerkes zu befreien und stattdessen preiswertere (heute schnellere) Netzwerke zu setzen. Damit sind alternativ zu den obigen Skizzen z. B. folgende Setups möglich:

Storage Cluter mit RSIO

Seit gut 15 Jahren verfügt OSL damit über die Fähigkeiten, verteilte Block-I/O-Lösungen über Standardnetzwerke zu implementieren und natürlich über die entsprechenden Erfahrungen.

OSL Unified Virtualisation Environment

Mit dem OSL Unified Virtualisation Environment setzte sich OSL das Ziel, speziell für den Betrieb von VMInfrastrukturen eine hochintegrierte Lösung zu schaffen, die wie ein einziges System zu administrieren ist und eine extrem vereinfachte Hardwarearchitektur aufweist. Heute bezeichnet man so etwas als hyperkonvergente Infrastruktur (HCI). Zu diesem Zweck wurde von dem vollsymmetrischen Konzept des Storage Clusters abgewichen und eine hybride Architektur nach einem Client-Server-Modell entworfen, die sowohl eine vertikale wie auch horizontale Skalierbarkeit erlaubt. Unter der Haube werkelt dabei eine entsprechend modifizierte Clusterengine, die allerdings eine gemeinsame technologische Basis mit dem OSL Storage Cluster hat.

Unified Virtualisation Environment

Das Bild zeigt einige mögliche Implementierungsvarianten. Allen gemein sind:

- Verzicht auf die klassische Zweiteilung von generischem Netzwerk und Speichernetzwerk (Unified Networking)
- In der Regelung arbeiten beide Netzwerke autonom und erfordern keine gemanagten Switches
- Alle Infrastrukturdienste (Storage, Virtual Networking, HA, Admin) erfolgen über die UVS (die "Köpfe")
- UVC (Unified Virtualisation Clients) führen die VMs aus, benötigen aber keine lokalen Storage-Ressourcen
- Speichervirtualisierung, Storage-Replikationen usw. erfolgen ohne Beteiligung der UVC, damit kurze und definierte Wege der VMs zum Storage, das Netz wird deutlich entlastet, Latenzen reduziert
- Isolation der Netzwerke (auch vom Hausnetz), Mandantentrennung, sichere Übergabe via UVS

Die Unified Virtualisation Server (UVS) nehmen also eine ähnlich zentrale Position im Gesamtsystem ein, wie zentrale Speichersysteme in konventionellen Setups, nur, daß noch weitere Funktionsbereiche abgedeckt werden. Das bietet folgende Vorteile:

- Entlastung der VMs und der Hypervisorknoten von Aufgaben wie Storage-Replikation usw.
- Verzicht auf RAID-Systeme ebenso möglich wie deren Weiterverwendung, aber: Offenheit für die direkte Ansprache von schnellem Massenspeicher im UVS via PCIe
- Die Storage-Zentralisierung erfordert wenig externe Kommunikation bei Virtualisierungs- und Replikationsvorgängen und vereinfacht die Nutzung von Dedup-Technologien u. ä.
- Einfachheit und Klarheit, vor allem ein Vorteil in Problemsituationen
- Im beabsichtigten Skalierungsrahmen (bis zu 120 UVC) überwiegen die Vorteile dieses Modells, insbesondere auch wegen des Wegfalls einer aufwendigen Inter-Node-Kommunikation. UVCs skalieren horizontal, UVS primär vertikal.

Kann ich einen Umstieg von VMware auf eine Linux-/KVM-basierte Lösung selbst bewerkstelligen?

Prinzipiell ja. Aber: Nach unserer Erfahrung ist es eben kein Pappenstiel und mit jeder neuen OS-Version, technologischen Neuerung, Hardwareänderung usw. lauern neue "Herausforderungen". Was immer die Community oder die KI zu bieten haben: Ein Partner mit gebündelter Erfahrung aus mehreren Projekten ist im professionellen Betrieb wohl eher doch ein großer Vorteil. Sowohl OSL als auch Partern wie CosiFan haben hier einiges an Erfahrung "auf der Uhr".
Eine Besonderheit bei OSL: Wir bemühen uns darum, die gemeinsamen Erfahrungen in Software zu gießen, so dass die potentiellen Einsparungen durch vermeintlich kostenlose Softwarekomponenten nicht durch eine dauerhafte Abhängigkeit von überbordenden Beratungsleistungen aufgefressen werden. Daneben profitieren Sie natürlich auch von der aufwendigen QA und den gebündelten Erfahrungen im Support.

Für erste Schritte: Warum bietet OSL kein Download der Software für jedermann an?

Auch aufgrund unserer Historie ist unsere Zielgruppe das professionelle RZ im Eigenbetrieb. Die extreme Offenheit bzw. Portabilität unserer Lösung stellt im Vergleich zu einer geschlossenen Distribution eine zusätzliche Herausforderung dar. Wir möchten gemeinsam mit unseren Partnern sicherstellen, dass der Anwender auf kürzestem Wege und ohne unnötige Risiken zum gewünschten Ergebnis gelangt. Das beginnt bei der Systemplanung, der Auswahl geeigneter Hardware und setzt sich über die Systeminstallation und -konfiguration fort. Wenn Sie ein eigenes Engineering und die entsprechenden Möglichkeiten haben, dann ist alles gut. Ansonsten aber geht man zum Fachmann und wird am Ende feststellen, dass man mit Versuch und Irrtum in Eigenregie wesentlich mehr hätte aufwenden müssen. Sprechen Sie uns und unsere Partner an. Auch eine lizenzkostenfreie Evaluierungsphase, Tests im RZ der OSL und vieles mehr sind möglich. Wir wollen Ihren Erfolg: Von Anfang an und auf Dauer!


Wir freuen uns auf Ihre Aufgaben!