CloudLinux OS 9: Funktionen und Grenzen im Shared Hosting

CloudLinux OS 9 richtig einordnen

CloudLinux OS 9 ist eine weiterhin dokumentierte Betriebssystemgeneration für Shared Hosting auf AlmaLinux-9-Basis. Sie ist jedoch nicht mit CloudLinux OS 10 gleichzusetzen, das der Hersteller als separaten Major-Zweig behandelt. Die Versionsnummer allein beschreibt weder den Lizenzumfang noch die verfügbaren Shared-Hosting-Komponenten auf einem konkreten Server.

Für die Einordnung ist der AlmaLinux-Kernel wichtig: CloudLinux OS 9 verwendet keinen eigenen CloudLinux-Kernel mehr, sondern den Kernel von AlmaLinux. Deshalb ist ein Namensbestandteil wie „LVE“ in der Kernelversion kein geeignetes Kriterium, um aktive Ressourcenisolation zu beurteilen. LVE muss über die installierten CloudLinux-Komponenten und deren Betriebszustand geprüft werden, nicht über die Zeichenfolge im Kernel-Namen.

Diese Trennung verhindert eine verbreitete Fehlannahme bei einem CloudLinux Update: Ein Upgrade auf OS 9 ersetzt nicht die Prüfung von Limits, CageFS, PHP-Handlern oder Datenbanksteuerung. Der Betriebssystemstand schafft die technische Basis; welche Funktionen für Kunden sichtbar sind, ergibt sich erst aus der Kombination von Lizenz, Paketen und Panel-Integration. Gerade bei gewachsenen Servern können diese Ebenen voneinander abweichen.

Optional ist für CloudLinux OS 9 ein LTS-Kernel verfügbar. Er enthält laut Hersteller Sicherheitskorrekturen und weniger Upstream-Wechsel als der reguläre AlmaLinux-Kernel. Das kann für Umgebungen mit konservativer Änderungsplanung passen, ist aber keine pauschal bessere Wahl. Anbieter müssen Anforderungen an Hardwaretreiber, eingesetzte Software, Wartungsprozesse und die Kernel-Strategie des gesamten Serverbestands abwägen.

Editionen und Lizenzen sauber trennen

Die Versionsnummer CloudLinux OS 9 beschreibt weder eine Edition noch eine Lizenz. Für Shared Hosting ist insbesondere zwischen CloudLinux OS Legacy, früher CloudLinux OS Shared, und CloudLinux OS Shared Pro zu unterscheiden. Legacy unterstützt unbegrenzt viele Hosting-Accounts und umfasst etablierte Bausteine wie LVE, CageFS, MySQL Governor, PHP Selector und Sprach-Selectoren.

Shared Pro ist davon getrennt zu betrachten: Die Editionsübersicht ordnet Funktionen wie PHP X-Ray, Centralized Monitoring und AccelerateWP dieser Edition zu. Ein cloudlinux update von OS 8 auf OS 9 schaltet diese Funktionen daher nicht frei, wenn die passende Pro-Lizenz und die jeweiligen Installations- sowie Panel-Voraussetzungen fehlen.

CloudLinux OS Admin ist ebenfalls keine verkleinerte Bezeichnung für Shared Pro. Diese Edition richtet sich auf einen anderen Umfang; unter anderem ist MySQL Governor dort nicht enthalten. Wer eine Datenbanküberlastung pro Hosting-Konto begrenzen möchte, darf daher nicht allein aus einer vorhandenen CloudLinux-Installation auf die Verfügbarkeit dieses Werkzeugs schließen.

Vor einer Funktionszusage sind drei Fragen getrennt zu beantworten: Welche Edition ist lizenziert, welche Pakete sind installiert und unterstützt das vorhandene Panel die gewünschte Komponente? Zusätzlich können Versionsstände einzelner Pakete Voraussetzungen verändern. Eine erfolgreiche Konvertierung des Betriebssystems belegt lediglich den Konvertierungsschritt; sie bestätigt nicht automatisch die Einsatzbereitschaft aller optionalen Module.

Isolation und Limits im Shared Hosting

Im Shared Hosting erfüllt LVE die Aufgabe, den Ressourcenverbrauch je Account einzugrenzen. Dazu gehören unter anderem CPU, Arbeitsspeicher, Ein- und Ausgabeoperationen, Prozesse und gleichzeitige Webzugriffe. Erreicht ein Projekt seine Grenzen, soll sein Verbrauch andere Konten nicht unverhältnismäßig belasten. Das ist Schutz vor Überverbrauch, aber keine automatische Behebung langsamer Anwendungen oder fehlerhafter Datenbankabfragen.

Bei Reseller-Angeboten ergänzen Reseller Limits die Account-Grenzen. Sie begrenzen den zusammengefassten Verbrauch der Unterkonten eines Wiederverkäufers. Einzelne Tarife können rechnerisch höhere Werte tragen, doch die Unterkonten können gemeinsam die übergeordnete Grenze nicht überschreiten. Das macht Kapazitäten und Tarifversprechen nachvollziehbarer, verlangt aber eine passende Planung der Gesamtgrenze.

CageFS verfolgt ein anderes Ziel als LVE: Die Dateisystem-Isolation beschränkt die sichtbare Systemumgebung eines Benutzers und soll Zugriffe auf Dateien anderer Hosting-Konten verhindern. Sie ersetzt jedoch keine vollständige Sicherheitsarchitektur. Auf cPanel-Servern nennt die Herstellerdokumentation etwa WebDAV, File Manager, Webmail und FTP-Server ohne korrektes Chrooting als Konstellationen, in denen CageFS nicht greift. Symlink-Schutz und eine sichere Dienstkonfiguration bleiben eigenständige Aufgaben.

PHP Selector erlaubt die Auswahl zentral freigegebener PHP-Versionen und Erweiterungen und setzt CageFS voraus. MySQL Governor überwacht die Datenbanknutzung nach Benutzer und kann überlastende Konten begrenzen; mod_lsapi ist dagegen ein PHP-Handler für Apache. Die Bausteine ergänzen sich, sind aber nicht austauschbar. Ihre Verfügbarkeit und sinnvolle Kombination richten sich nach Edition, Webserver und Konfiguration.

Besondere Aufmerksamkeit verlangt die Panel-Integration. Auf cPanel-Systemen sollten Kunden nicht gleichzeitig den PHP Selector und eine konkurrierende MultiPHP-Auswahl als gleichwertige Wege vorfinden, weil daraus widersprüchliche Einstellungen entstehen können. Auch nicht jedes Panel bindet jede Funktion im selben Umfang ein. Für die vertiefte Abgrenzung von Account- und Website-Isolation hilft der Beitrag zu SecureLVE und Prozessisolation im Shared Hosting; maßgeblich bleiben jedoch Lizenz, dokumentierte Panel-Unterstützung und die konkrete Serverkonfiguration.

Komponenten nach Einsatzfall auswählen

Für die Auswahl zählt die konkrete Betriebsaufgabe, nicht allein das Label CloudLinux OS 9. Betriebssystem, Edition, Lizenz, installierte Pakete und Control Panel bilden getrennte Prüfpunkte. Shared-Pro-Erweiterungen sind nicht durch ein OS-Upgrade automatisch verfügbar; die Editionsübersicht und die Anforderungen der jeweiligen Komponente müssen zusammen geprüft werden.

Die Tabelle ist eine Entscheidungshilfe, keine Freigabe für die Installation. Vor einer Zusage prüfst du die unterstützte Panel-Version, den PHP-Handler, die konkrete Lizenz und den Paketstand. CloudLinux dokumentiert für einzelne Komponenten eigene Integrationsbedingungen; deshalb kann eine grundsätzlich vorhandene Funktion in einer bestimmten Panel-Umgebung fehlen oder anders verwaltet werden.

Für die Tarifplanung ist die Trennung besonders wichtig: LVE-Limits schützen die gemeinsame Serverkapazität auf Account-Ebene, während Reseller Limits eine zusätzliche gemeinsame Obergrenze für Unterkonten setzen. CageFS, PHP Selector und MySQL Governor lösen dagegen andere Aufgaben. Eine Komponente sollte daher aus dem beobachteten Engpass oder Schutzbedarf folgen, nicht aus einer pauschalen Funktionsliste.

Limits und PHP-Verwaltung praktisch planen

Erzeugt ein WordPress-Shop Lastspitzen, begrenzen Account-Limits CPU, Arbeitsspeicher, Ein- und Ausgabeoperationen, Prozesse sowie gleichzeitige Webzugriffe. Das hält den Verbrauch des betroffenen Kontos in einem definierten Rahmen und kann andere Accounts vor Überverbrauch schützen. Für die Ursachenanalyse ist entscheidend, welche Grenze tatsächlich erreicht wird, statt nur eine allgemeine Serververlangsamung zu vermuten.

Ein erreichtes Limit ist jedoch keine Diagnose des Shop-Problems. Eine fehlerhafte Erweiterung, kostspielige Datenbankabfragen, ein Import oder fehlendes Caching können die Last auslösen. Höhere Werte verschieben die Grenze, beseitigen aber keine Ursache. Prüfe deshalb zunächst Ressourcendaten und Anwendung; erst danach ist zu entscheiden, ob Optimierung, ein anderer Tarif oder zusätzliche Kapazität angemessen ist.

Bei einem Reseller mit vielen kleinen Tarifen ergänzt eine Reseller-Grenze die Limits der einzelnen Endkunden. Die Unterkonten können jeweils eigene Werte besitzen, ihr gleichzeitiger Gesamtverbrauch darf die übergeordnete Grenze aber nicht überschreiten. Das verhindert, dass ein Reseller durch die Summe vieler aktiver Kunden mehr Ressourcen beansprucht als für sein Angebot vorgesehen sind.

Für PHP sollte pro Kundenkonto genau eine verständliche Auswahloberfläche maßgeblich sein. Der PHP Selector setzt CageFS voraus. Auf cPanel-Systemen kann eine parallele Nutzung mit MultiPHP zu widersprüchlichen Erwartungen führen, wenn Kunden Versionen an verschiedenen Stellen ändern. Lege daher fest, welche Oberfläche sichtbar ist, welche Versionen freigegeben werden und wer Ausnahmen verwaltet.

Wie CPU, PMEM, I/O, IOPS, EP und NPROC in konkrete Tarifprofile übersetzt werden können, erläutert der interne Beitrag CloudLinux LVE Manager im Shared Hosting richtig konfigurieren. Die dortigen Werte sind nicht automatisch auf jede Hardware oder Kundenstruktur übertragbar. Storage-Leistung, Anwendungsmix und die Auswertung tatsächlicher Faults bleiben für jede Konfiguration maßgeblich.

Mehrere Websites pro Account isolieren

Ein einzelnes Hosting-Konto enthält häufig Hauptseite, Shop, Staging-Umgebung und Kundenprojekte. Die Account-Grenze allein trennt diese Anwendungen nicht voneinander. CloudLinux Isolates ist vom Hersteller insgesamt als Beta gekennzeichnet. Die Funktion kann eine Dateisystem-Isolation pro Domain einrichten, sodass Zugriffe einer Website von Dateien anderer Websites desselben Accounts abgegrenzt werden. Sie eignet sich damit als zu prüfende Option für Konten mit Projekten unterschiedlicher Risiken oder Zuständigkeiten.

Davon getrennt sind per-Domain-LVE-Limits. Sie sollen Ressourcen auch je Website statt nur für das gesamte Kundenkonto begrenzen. CloudLinux kennzeichnet auch diese Schicht ausdrücklich als Beta und nennt sie für OS 8 und OS 9. Dateisystemtrennung und Ressourcenlimits pro Domain sind somit zwei getrennte Ebenen mit unterschiedlichen Voraussetzungen.

• Für Domain-LVE-Limits nennt CloudLinux mindestens lve-stats3 5.1.0-1 und lve-utils 6.6.40-1.
• PHP-Handler und Control Panel müssen die jeweilige Isolates-Konfiguration unterstützen.
• Die Dateisystemtrennung pro Domain kann möglich sein, obwohl die Voraussetzungen für Domain-Limits noch nicht erfüllt sind.

Die Voraussetzungen prüfst du daher getrennt: zuerst, ob die Beta-Funktion Isolates mit dem eingesetzten Panel und Handler für die gewünschte Dateisystemschicht dokumentiert ist, danach die Paketstände und den Beta-Status der Ressourcenlimits. Bei standalone LiteSpeed dokumentiert CloudLinux derzeit Unterstützung nur für cPanel. Andere denkbare Kombinationen dürfen daraus nicht als gleichwertig unterstützt abgeleitet werden.

Isolates kann den Wirkungsbereich innerhalb eines Kontos verringern, ersetzt aber keine Pflege der Anwendungen. Aktualisierte Plugins, getrennte Zugangsdaten, Backups und eine passende Rechteverwaltung bleiben erforderlich. Für ein Konto mit mehreren unabhängigen Kundenprojekten kann die Domain-Isolation nach dokumentierter Kompatibilitätsprüfung dennoch eine passendere zusätzliche Grenze sein als ausschließlich gemeinsame Account-Limits.

Migration auf OS 9 vorbereiten

Die Migration auf CloudLinux OS 9 ist eine geplante Konvertierung und kein gewöhnliches Paketupdate. Sie kann installierte Pakete, Repository-Konfigurationen und die Anbindung des Hosting-Panels berühren. Vor dem Start prüfst du daher Ausgangsbetriebssystem, CPU-Architektur, Virtualisierungsumgebung und die vom jeweiligen Panel unterstützte CloudLinux-Integration.

Lege ein Wartungsfenster fest und arbeite mit vollständigen, getesteten Backups oder konsistenten VM-Snapshots, die sich nach dem jeweils geltenden Wiederherstellungsverfahren zurückspielen lassen. Als administrative Best Practice empfiehlt es sich außerdem, vorab Paketquellen, aktive Dienste und abweichende Konfigurationen zu dokumentieren. So lassen sich Unterschiede nach der Konvertierung gezielt nachvollziehen, ohne die Dokumentation als Ersatz für ein Backup zu behandeln.

Nach der Systemumstellung sollte die Prüfung nicht beim erfolgreichen Abschluss des Konvertierungsvorgangs enden. Kontrolliere die eingebundenen Repositories sowie die Panel-Integration und behandle Zusatzkomponenten separat. PHP Selector, X-Ray oder AccelerateWP haben eigene Installations-, Lizenz- und Panel-Voraussetzungen; eine funktionsfähige OS-9-Basis weist deren Verfügbarkeit nicht automatisch nach.

Eine wesentliche Grenze betrifft den Versionspfad: Die Konvertierung behält die Major-Version der Ausgangsbasis bei. Sie macht aus einem CentOS-7-System folglich nicht direkt ein CloudLinux-OS-9-System. Für einen solchen Generationswechsel brauchst du einen dafür geeigneten Migrationsweg, etwa einen Neuaufbau mit Daten- und Account-Übernahme, statt die Konvertierung als Upgrade über mehrere Major-Versionen zu verstehen.

Pakete, Kernel und Faults prüfen

Nach Installation oder Upgrade beginnt die Betriebsprüfung mit einer Bestandsaufnahme. Prüfe zuerst den laufenden Kernel. CloudLinux OS 9 verwendet den AlmaLinux-Kernel; ein fehlender Namensbestandteil „LVE“ im Ausgabewert ist deshalb kein Nachweis dafür, dass LVE-Funktionen fehlen. Der Befehl liest lediglich die aktuell gestartete Kernelversion aus.

uname -r

Danach fragst du die installierten Kernpakete ab. Die Ausgabe zeigt Paketnamen und Versionsstände oder meldet, falls ein Paket nicht installiert ist. Sie ersetzt weder einen Lizenzcheck noch die Prüfung, ob das eingesetzte Control Panel die jeweilige Oberfläche und Funktion korrekt integriert.

rpm -q lve lvemanager cagefs lve-utils

Falls du per-Domain-Limits mit CloudLinux Isolates bewerten willst, prüfst du zusätzlich die dafür dokumentierten Paketstände. Die Abfrage verändert keine Konfiguration. Domain-LVEs sind als Beta gekennzeichnet; ein passender Paketstand allein bestätigt daher weder die praktische Kompatibilität des PHP-Handlers noch die Unterstützung durch das Panel.

rpm -q lve-stats3 lve-utils

Für die Ursachenanalyse sind Faults und Ressourcendaten aussagekräftiger als eine pauschale Erhöhung aller Grenzwerte. Erreicht ein Account ein Limit, ordnest du zunächst ein, ob CPU, Arbeitsspeicher, I/O, Prozesse oder gleichzeitige Zugriffe betroffen sind. Anschließend prüfst du Anwendung und Datenbankabfragen, bewertest Caching und planst bei dauerhaftem Bedarf Kapazität oder Tarifgröße neu.

Typische Fehlannahmen vermeiden

Die wichtigste Einordnung lautet: CloudLinux OS 9 beschreibt die Betriebssystemgeneration, nicht den vollständigen Funktionsumfang einer Hosting-Lizenz. CloudLinux OS 10 ist ein getrennter Major-Zweig; Aussagen zu OS 9 lassen sich deshalb nicht automatisch auf OS 10 übertragen. Shared Pro bleibt zudem eine eigene Edition mit zusätzlichen Funktionen wie PHP X-Ray, Centralized Monitoring und AccelerateWP.

Ebenso sollte eine erfolgreiche Konvertierung nicht als Gesamtfreigabe aller Module gelten. Nach der Migration müssen Panel-Anbindung, Paketstände, Lizenzumfang und die Voraussetzungen jeder Zusatzfunktion getrennt kontrolliert werden. Das verhindert, dass Kunden Funktionen zugesagt werden, die zwar zur gewählten Edition gehören können, auf dem konkreten Server aber noch nicht eingerichtet oder unterstützt sind.

Bei CloudLinux Isolates ist besondere Genauigkeit nötig. Die Herstellerdokumentation kennzeichnet Isolates insgesamt als Beta. Die Dateisystemtrennung von Websites innerhalb eines Accounts und die optionalen per-Domain-LVE-Limits sind außerdem nicht gleichzusetzen; auch die Domain-Limits sind ausdrücklich Beta. Vor einem Einsatz sind PHP-Handler, Panel und die dokumentierten Paketvoraussetzungen zu prüfen.

Auch Ressourcenlimits lösen keine Ursachen in einer Anwendung. Für die Betriebsanalyse ist es sinnvoll, zuerst Faults und die betroffene Ressourcenart auszuwerten: CloudLinux kann Grenzverletzungen für CPU, Speicher, I/O, IOPS, gleichzeitige Verbindungen und Prozesse ausweisen. Erst danach bewertest du Anwendung, Datenbankabfragen, Cronjobs und Caching sowie die Frage, ob tatsächlich mehr Kapazität benötigt wird.

Für die Betriebsentscheidung reichen Account-Limits aus, wenn Kundenprojekte vor allem voneinander getrennt und Lastspitzen begrenzt werden sollen. Reseller-Grenzen passen zusätzlich, wenn ein Wiederverkäufer die gemeinsame Kapazität seiner Unterkonten einhegen muss. Website-Isolation ist als Beta-Option für mehrere unterschiedlich riskante Projekte in einem Account zu bewerten, jedoch erst nach dokumentierter Kompatibilitätsprüfung und mit klarer Kennzeichnung ihres Status.