LXC produktiv einsetzen

[ramsys]

LXC hat derzeit für den produktiven Einsatz (im Bereich Hosting) ja den entscheidenden Nachteil, dass quota innerhalb eines Containers nicht zur Verfügung steht.

a) Hat jemand hierzu andere bzw. neuere Informationen? Gibt es evtl. einen funktionierenden Workaround hierzu, ggf. auch mit Einschränkungen?

b) Dieser "Nachteil" betrifft doch eigentlich nur den Webserver. Wenn in einem Multiserver-Setup alle Dienste (Webserver, Mailserver, Datenbank, Nameserver usw.) in einem eigenen Container untergebracht werden, sollte der Einsatz von LXC für die anderen Server doch problemlos möglich sein. Ebenso für Webserver, auf denen nur eigene Anwendungen installiert sind (z.B. ISPConfig-Interface, Webmail usw.) und die daher nicht für Kunden zur Verfügung stehen. Habe ich dabei etwas übersehen?

 

[Till]

a) Ist mir nichts bekannt. Würde mich aber auch interessieren.
b) Ja, nur der Webserver benötigt Quota. Ob man Quota für eigene Seiten benötigt hängt davon ab ob man zur Sicherheit den Platz begrenzen will oder nicht.

 

[ramsys]

zu a)
Evtl. hat es ja nicht nur Nachteile, wenn man gänzlich auf quota auch bei einem Webserver verzichtet. Eine Alternative wäre ein täglicher Cronjob mit entsprechender Warnmeldung beim Überschreiten gewisser Limits. Also ähnlich wie in Version 3.1 bei den Datenbanken. Ich sehe da erstmal keinen großen Unterschied zwischen Webspace, Mailspace und DB-Space.

https://www.howtoforge.de/forum/threads/mysql-quota-limits.9147/

Wenn man quota nicht verwendet sondern die Limits per Script überwacht, was bzw. wo bzw. wie müssten in ISPConfig Dinge angepasst werden?

 

[robotto7831a]

Einen Nachteil hat deine Variante. Wenn ich per FTP mehrere GB auf den Webserver kopiere, dann merkst Du es erst nach dem nächsten Skriptlauf. Währenddessen könnte dein Webserver platt sein.

 

[ramsys]

Einen Nachteil hat deine Variante. Wenn ich per FTP mehrere GB auf den Webserver kopiere, dann merkst Du es erst nach dem nächsten Skriptlauf. Währenddessen könnte dein Webserver platt sein.

Grundsätzlich natürlich richtig. Aber dieses Risiko besteht im Grunde auch bei Datenbanken und auf einem Mailserver, wenn auch nicht ganz so gravierend wie beim Webserver.

Man könnte das Intervall entsprechend anpassen und über die API ist sicherlich auch irgendeine Sperre möglich.

 

[ramsys]

Evtl. hat es ja nicht nur Nachteile, wenn man gänzlich auf quota auch bei einem Webserver verzichtet.

Gerade aktuell und passend zum Thema:

Heute Nacht hat ein Kunde sehr viele auch größere Dateien auf seinen Server geladen, nicht direkt per FTP sondern über eine entsprechende Anwendung. Die Dateien werden über eine Datenbank verwaltet. Das Ergebnis: Sämtliche Datenbankeinträge wurden korrekt angelegt, die Dateien selber aber aufgrund der Limits nicht mehr vollständig übertragen. Das System war inkonsistent und musste aus einem Backup wiederhergestellt werden.

Ein ähnliches Verhalten hatten wir auch schon mal bei einer anderen Anwendung. Hier hat das System über Nacht eine größere Menge temporäre bzw. Cache-Dateien erstellt, was ebenfalls zu Inkonsistenzen und Nichterreichbarkeit führte.

 

[Till]

Grundsätzlich natürlich richtig. Aber dieses Risiko besteht im Grunde auch bei Datenbanken und auf einem Mailserver, wenn auch nicht ganz so gravierend wie beim Webserver.

Bei Datenbanken gebe ich Dir recht, mir ist aber bislang kein Fall unter gekommen in dem bei einem Hack die Datenbank genutzt wurde um hunderte GB an Daten zu speichern, aber das kann ja noch kommen. Außerdem ist es halt bei MySQl nicht anders möglich, denn es gibt einfach keine in MySQL implementierte Quota Sperre. Mail ist da komplett außen vor, denn Mail Quota ist in dovecot / courier implementiert, es ist kein linux quota.

Man könnte das Intervall entsprechend anpassen und über die API ist sicherlich auch irgendeine Sperre möglich.

Gehen tut das, ist nur tödlich für die Performance. Ich hab hier z.B. eine Kundeseite die hat derzeit 380GB an Daten mit einer sehr hohen Anzahl an Dateien, wenn ich die jetzt per "du" Befehl im 5 Minuten Rhytmus auf Größenänderungen scanne dann bricht der Server zusammen.

 

[ramsys]

Bei Datenbanken gebe ich Dir recht, mir ist aber bislang kein Fall unter gekommen in dem bei einem Hack die Datenbank genutzt wurde um hunderte GB an Daten zu speichern

Ich dachte da auch eher an alltägliche Dinge wie Log- und/oder Cache-Tabellen bzw. aktivierten Debug-Modus. Hier kann die Datenbank schnell größer als der eigentliche zugewiesene Webspace werden ("normales" Hosting vorausgesetzt).

Mail ist da komplett außen vor

Ja klar, das hatte ich zu schnell in einen gemeinsamen Topf geworfen. Daher sehe ich auf einem Mailserver erstmal auch kein Problem für den Einsatz von LXC.

wenn ich die jetzt per "du" Befehl im 5 Minuten Rhytmus auf Größenänderungen scanne dann bricht der Server zusammen.

Ich dachte da auch nicht gleich an einen 5-Minuten-Rhytmus

 

[florian030]

Das Intervall für du o.ä. ist rel. egal. Wenn Du genug Dateien hast, dann ist das ein absoluter System-Killer.