Kundenlogin

CloudLinux & Plesk

Ressourcen? Limits? Accounts isolieren? Worum geht es hier?

tl;dr
Mit den LVE Limits von CloudLinux lässt sich sehr granular sicherstellen, dass einzelne gehostete Webseiten die Server-Ressourcen nicht überanspruchen. CageFS isoliert Kunden-Accounts voneinander. Server mit einer hohen Anzahl an Accounts profitieren stark.

Limits (LVE)

Wer als Anbieter im Webhostingmarkt eigene Infrastruktur betreibt, wird sich früher oder später mit dem Thema der Ressourcenlimitierung befassen müssen. In erster Linie geht es dabei meist um eine Art Selbstschutz. Die Idee ist: Eine einzelne gehostete Webseite sollte nie in der Lage sein, die Ressourcen des Servers so zu beanspruchen, dass Webseiten anderer Kunden (z.B. durch höhere Ladezeiten) zu leiden hätten – oder der Server komplett seinen Dienst einstellt. Ebenfalls möchte man die vom Kunden gekauften und bezahlten Ressourcen ja auch stets abrufbereit halten, um einen sinnvollen Betrieb der gehosteten Webseiten oder Shops zu ermöglichen. Also muss man Vorkehrungen treffen, um ein passendes Gleichgewicht zu finden. So landet man bei dem Thema der Ressourcenlimitierung.
Im Rahmen unserer Überlegungen zur neuen Hosting-Plattform bei Power-Netz.de in 2017 haben wir uns (unter Anderem) mit diversen möglichen Lösungen für dieses Thema befasst.

  • FastCGI Limits
  • uLimits
  • Apache RLimit
  • CloudLinux LVE
  • Diverse andere wie z.B. dedizierter Wrapper, usw.

In der „guten alten Zeit“ wurden solche Ressourcenlimits oft über uLimits oder Apache RLimit gelöst. uLimits sind sehr grob, Apache RLimit ist schon geeigneter. Aber: ein RLimit von 256MB zählt immer pro Prozess. Da aber keine Webseite mit nur einem Prozess auskommt, können z.B. 100 Prozesse am Ende das Hundertfache des definierten Limits für sich beanspruchen. Üblicherweise ist dies nicht die Lösung, die man als Anbieter im Webhostingmarkt möchte.
Was man (aus unserer Perspektive) möchte, ist eine Limitierung pro Account, nicht pro Prozess. Ein Account kann mehrere Webseiten haben, solange er seine Ressourcen nicht überschreitet. Eine sehr gute Lösung bieten hier die LVE Limits von CloudLinux.

Die wichtigsten Limits

CPU Limit – Angabe in Prozent.
Summe der CPU Belastung, die alle Prozesse unterhalb dieses Accounts erreichen können. Einschließlich interaktiver Prozesse, z.B. PHP, ImageMagick, SSH, usw. Auch wenn der Account über SSH abstruse Prozesse startet, können diese das eingestellte CPU Limit nie überschreiten.
RAM Speicher – Angabe in MB/GB.
Summe des für alle Prozesse dieses Accounts möglichen Speicherverbrauchs.
IOPS – Angabe in IO/Sekunde.
Maximale Anzahl von IOPS die alle Prozesse dieses Accounts auf dem Storage erzeugen können.
Anzahl Prozesse – Angabe als natürliche Zahl. Bei Erreichen des Limits kann der Account keine neuen/zusätzlichen Prozesse starten. Schützt z.B. gegen „fork Bomben“.

Kunden-Accounts voneinander isolieren (CageFS)

Bereits durch die normale Implementierung des Rechte-Systems von Linux/Plesk und die Verwendung der üblichen Bordmittel sind Kunden-Accounts eines Plesk-Servers von einander ordentlich getrennt. Kunde-1 kann die Daten und Inhalte von Kunde-2 nicht einsehen usw. Kunde-1 könnte aber (u.U.) wohl feststellen, dass ein Account mit Namen Kunde-2 auf dem System existiert. Durch die Nutzung von CageFS wird für jeden Kunden-Account eine Art eigene kleine „virtuelle Umgebung“ erzeugt. In dieser virtuellen Umgebung kann er frei schalten und walten. Er kann jedoch keine anderen Benutzer im System ausmachen. Aus unserer Sicht eine sinnvolle und positiv zu bewertende Sache.

Unser Fazit

Heute (Ende 2019) haben wir CloudLinux seit ca 2 Jahren im Einsatz. Die Integration von CloudLinux und Plesk hat sich in den letzten Jahren stetig verbessert. War CloudLinux in 2017 noch sehr stark auf cPanel fokussiert, so sind heute alle „Triple-A Panels“ (cPanel & Plesk) gleichwertig gut unterstützt und getestet. Für Plesk-Nutzer mit verschiedenen End-Kunden auf demselben System eine sinnvolle und nützliche Ergänzung.
Bei Interesse, sprechen Sie uns an. Wir beraten Sie gerne.