Plattenplatz für User beschränken

Plattenplatz für User beschränken (17 Beiträge, 514 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Ich betreibe neben einigen Kundenservern auch einen privaten (Miet)Server, auf dem ich einigen Bekannten und Freunden gratis Platz und Zugang gegeben habe.

Wie es in solchen Situationen so kommt, hat ein Projekt (Linuxdistri) da mit der Zeit 80% des Servers okkupiert, und in den seltenen Situationen wo ich das Ding selber brauche, steh ich an.

Da die Hardware sowieso schon überholt ist, hab ich mich jetzt zu einem Wechsel bei einem neuen Anbieter entschlossen, womit das Problem jetzt vorerst auf jedenfall mal behoben sein wird.

Da ich allerdings weiß, wie sich bei manchen Projekten der Ressourcenverbrauch entwickelt, wenn man nicht rigoros Grenzen setzt, werde ich jetzt am neuen System erstmals Restriktionen setzen.

Bezüglich des Plattenplatzes gibt es da prinzipiell zwei Möglichkeiten.

1.) Quotas
2.) Logical Volumes

Quotas haben den Vorteil urprimitiv einzurichten zu sein. Jederzeit zu ändern. Haben aber den Nachteil, dass sie einen Reboot massiv verzögern, weil da im Bootvorgang immer der Restplatz berechnet werden muss.

LVM hat den Vorteil, dass es beim Reboot keinen Zeitverlust bedeutet. Das Einrichten ist allerdings mühsam, wenn man nicht auf das vorgefertigte Image zurückgreifen kann, sondern über ein "Rettungssystem" per debbootstrap sein System aufsetzen muss. Dazu kommt dann noch, dass ein nachträgliches Vergrößern des LV wohl zu einem wenig performanten Dateisystem führen wird. Bzw. ich jetzt mal einen nicht unwesentlichen Teil des Plattenplatzes ungenutzt lassen, oder damit leben, dass ich später aufwendig resizen muss.

Im Moment weiß ich wirklich nicht, womit ich mir mehr Probleme eintrete.
Meinungen sind gefragt. Ich behalte mir aber selbstverständlich vor, dann genau das Gegenteil umzusetzen oder auch gar nichts.
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Keine direkte Hilfe, aber ist der Quota-Check denn direkt beim Boot nötig? Im Netz finden sich einige Varianten, die ihn täglich über einen Cron-Job laufen lassen.

PS: Wieso wird überhaupt so oft gebootet, dass das ins Gewicht fällt?

PPS: Vielleicht auch hier probieren: http://serverfault.com/ und http://unix.stackexchange.com/

16.06.2012, 20:02 Uhr - Editiert von m3t4tr0n, alte Version: hier

PS: Wieso wird überhaupt so oft gebootet, dass das ins Gewicht fällt?

Wer eine sichere Maschine haben will, spielt jedes Update ein. Und alle 2 bis drei Wochen gibts einen neuen Kernel bei Ubuntu.
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

alle 2 bis drei Wochen gibts einen neuen Kernel bei Ubuntu

also das wage ich zu bezweifeln

Dann schau dir die USN an, und sei vom Zweifel befreit

http://www.ubuntu.com/usn/lucid/ (10.04 ist glaube ich ein recht brauchbares Beispiel - in den anderen Releases schaut es aber auch nicht anders aus.)

da hast schon recht, nur nicht jedes update ist ein neuer kernel.

Ich verwende grundsätzlich LVM.

Bei Quota gab es in Kombination mit SMB früher (2.0.* oder 2.2.*) riesen-Probleme. Wenn ein User eine Datei vom Client auf seinen Share speichern wollte, sah es am Client so aus, als ob das Speichern klappte - obwohl es wegen Quota-Überschreiten nicht klappte.
Das ist zwar laaange her, ich würde es aber unbedingt austesten.

LVM ist bei allen mir bekannten Distris (SLES, Debian) watcheneinfach aufzusetzen.
Ich lege mir jedesmal mindestens 10 LVs an - und halte die LVs klein. Bei Bedarf vergrößere ich eben - geht eh in Sekunden.

LVs bringen bei Vergrößern übrigens _keine_ Performance-Penalty. Wichtig ist nur, dass Du eine brauchbare PE-Size hast (Weil immer nur in PE-Schritten vergrößert wird) - wenn Du auf Fragmentierung der Platte unabhängig vom Filesystem anspielst.

LVs bringen bei Vergrößern übrigens _keine_ Performance-Penalty. Wichtig ist
nur, dass Du eine brauchbare PE-Size hast (Weil immer nur in PE-Schritten
vergrößert wird) - wenn Du auf Fragmentierung der Platte unabhängig vom
Filesystem anspielst.

Bist du sicher? Wenn ich mir anschaue, wie so eine Platte von innen nach aussen in der Lesegeschwindigkeit eingeht. Sollte man sich wirklich mal im palimpsest anschauen, ob man da nicht den Knick sieht.
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Genau da könnten dir LVs helfen. Unter AIX vergab man bei den LVs eine Policy, wo sie liegen sollen. Die schnellsten Sachen gab man in die mittlere Spur, damit nie beim positionieren der Arm über die ganze Platte muss (die Platten bekommen ja i.d.R. den Stress mit den IOPS und nicht mit der sustained read rate).

Du könntest LVs voll anlegen vorher - und schnell benötigtes in die mittleren LVs legen. De facto glaube ich aber, dass journalling, ... Dir eh den Strich durch die Rechnung macht. LVs sind nur ein Container für FS - die FS kann man IMHO sinnvoll tunen, bei den LVs sehe ich keinen möglichen Nachteil.

Weitere Möglichkeit: disk images für die User (per loopback als homedir mounten). Ist zwar primitiv, kostet aber heutzutage kaum mehr Performance und ist auch nachträglich gut umsetzbar / im Grunde so flexibel wie lvm.

XFS hat m.E. auch eine bessere quota-Implementierung, vielleicht ist das beim Booten schneller.

ACTA wird Menschen töten | wikileaks.geizhals.org

„Ich habe den Verdacht, dass sich alle Terrorismen, egal, ob die deutsche RAF, die italienischen Brigate Rosse, die Franzosen, Iren, Spanier oder Araber, in ihrer Menschenverachtung wenig nehmen. Sie werden übertroffen von bestimmten Formen von Staatsterrorismus“ (Helmut Schmidt)

"Ermittlungen in großen Wirtschaftsstrafsachen unterliegen wegen der Berichtspflichten der Ermittler zum Innen- und Justizministerium vollends dem politischen Würgegriff" (N. Haslhofer, ehem. StA)

Weitere Möglichkeit: disk images für die User (per loopback als homedir
mounten).

Ist zwar auch eine Möglichkleit, macht aber das Backup umständlicher. Weil da muss ich dann die Container seperat behandeln.
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

da muss ich dann die Container seperat behandeln.

Können ja ruhig alle in einem Verzeichnis sein?

Verstehe ich nicht ganz - welche Art von Sonderbehandlung schwebt dir denn da vor, bzw. ist aus deiner Sicht zwingend?

Normalerweise tare ich einfach /home /var /srv in je ein Archiv. Wenn ich da jetzt irgendwo die Imagefiles der home-Verzeichnisse rumliegen habe, muss ich die ausschließen.
Natürlich kein großes Ding. Aber irgendwie unschön, wenn ich auf der eigenen Kiste anders vorgehen muss als auf den anderen, die ich betreue.

Das birgt immer die Gefahr, dass man besinnungslos die falsche Version des Scripts kopiert... .
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Was sind denn deine Bedenken dabei - dass du, wenn du die Loopback-Filesystem-Images auch unterhalb dieser Dateisysteme gemountet hast, die Daten darin doppelt im Backup haettest? Oder dass, wenn du die Image-Files im Backup haben willst, da durch Schreibvorgaenge innerhalb des "Containers", die waehrend dem Erstellen des Backups passieren, inkonsistente Daten eingepackt werden koennten? Oder etwas ganz Anderes?

Einfach, wenn die Container ins Backup gehen, dauert das endlos, ist sinnlos und stört die Performance. Und da ich meine Scripte relativ häufig einfach auf alle von mir betreuten Server verteile, stört mich ein Ausnahmehandling.

Bringt jedenfalls gegenüber lvm keinen Vorteil. Eher Nachteile, wenn man das Image im nachhinein vergrößern will. Es ist sogar so, dass ich überlege das kvm Image des Windows-Guest nicht auch auf ein lvm über ein iscsi-target zu bringen. Dass das nicht immer voll ins Backup läuft. Prinzipiell halte ich viel von lvm. Allerdings sind in den meisten angebotenen Rootservern, Platten von Schlaftablettentempo verbaut. Und jede zusätzliche Komplexitätsebene des FS tut weh.

Eine Möglichkeit ist es mit den Images natürlich. Und wahrscheinlich sogar eine schlauere als sich das gesamte FS durch Quotas ausbremsen zu lassen.
--
Der einzige Weg, wahre Liebe für Geld zu kaufen, ist, sich einen Hund anzuschaffen.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung