Moin,
wie haltet Ihr es heutzutage mit dem Partitionslayout? Ist Eurer Meinung nach bei den heutigen Plattengrössen eine Aufteilung des Systems in mehrere Partitionen überhaupt noch nötig/sinnvoll, oder sind die Zeiten des langen Planens des Partitionslayout endlich vorüber?
Ich persönlich verzichte bei meinen Systemen nun schon seit circa 2003 auf ein komplexes Partiitionslayout und begnüge mich unter Linux mit drei (/boot, /, swap) und unter FreeBSD mit zwei (/, swap) Partitionen.
Das Einzige was ich bei Bedarf auf eine eigene Partition auslagern würde, wäre /home beziehungsweise /data um Backups und Quotas leichter verwalten zu können.
Wie sehen Eure Partitionslayouts aus und warum?
Gruss,
Joe User
Partitionslayout
-
- Project Manager
- Posts: 11183
- Joined: 2003-02-27 01:00
- Location: Hamburg
Partitionslayout
PayPal.Me/JoeUser ● FreeBSD Remote Installation
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
-
- Moderator
- Posts: 1235
- Joined: 2011-07-04 10:56
Re: Partitionslayout
System 1 Mailserver
Dazu gehört theoretisch /var/log Bei mir unter /srv/logs zusammen gefasst,
/var/vmail, was per drbd gesynct wird und das Maildir ist.
Dann noch / und /srv/temp was dem tempdir für alle Webanwendungen dient.
Das System wird als Proxy / Loadbalancer betrieben.
Bei Datenbanken wird das datadir separat abgelegt, damit ein ggf. Amok laufender Dienst nicht mit Logfiles, die Datenbankfiles zerstört. Unter Postgresql einmal passiert. Eine unsauber arbeitende Webanwendung hat innerhalb 4 Stunden über 200GB Logs erzeugt.
Dito Webserver, hier werden die Webdirs per drbd gesynct.
Teilweise ist die Trennung dank drbd physisch geschuldet, der rest wird über LVM verwaltet und wurde zur Absicherung aufgetrennt, so dass z.B. Logfiles oder ein Amok laufendes Webscript, ein upload wütiger Kunde etc. etc. keinen Betriebsunfall verursachen kann. Max. ein FS voll läuft.
Ich habe bei mir alle "unvorhersehbare und ggf. Systembeeinflussende Filesysteme abgeschottet.Dateisystem Größe Benut Verf Ben%% Eingehängt auf
rootfs 50G 24G 24G 51% /
devtmpfs 1,9G 252K 1,9G 1% /dev
tmpfs 2,0G 4,0K 2,0G 1% /dev/shm
devpts 0 0 0 - /dev/pts
/dev/mapper/SYSTEM-ROOT
50G 24G 24G 51% /
proc 0 0 0 - /proc
sysfs 0 0 0 - /sys
debugfs 0 0 0 - /sys/kernel/debug
/dev/sda1 250M 20M 218M 9% /boot
/dev/mapper/SYSTEM-LOGS
9,9G 151M 9,2G 2% /srv/logs
/dev/mapper/SYSTEM-TEMP
9,9G 151M 9,2G 2% /srv/temp
configfs 0 0 0 - /sys/kernel/config
ocfs2_dlmfs 0 0 0 - /dlm
/dev/drbd1 125G 6,6G 119G 6% /var/vmail
Dazu gehört theoretisch /var/log Bei mir unter /srv/logs zusammen gefasst,
/var/vmail, was per drbd gesynct wird und das Maildir ist.
Dann noch / und /srv/temp was dem tempdir für alle Webanwendungen dient.
Das System wird als Proxy / Loadbalancer betrieben.
Bei Datenbanken wird das datadir separat abgelegt, damit ein ggf. Amok laufender Dienst nicht mit Logfiles, die Datenbankfiles zerstört. Unter Postgresql einmal passiert. Eine unsauber arbeitende Webanwendung hat innerhalb 4 Stunden über 200GB Logs erzeugt.
Dito Webserver, hier werden die Webdirs per drbd gesynct.
Teilweise ist die Trennung dank drbd physisch geschuldet, der rest wird über LVM verwaltet und wurde zur Absicherung aufgetrennt, so dass z.B. Logfiles oder ein Amok laufendes Webscript, ein upload wütiger Kunde etc. etc. keinen Betriebsunfall verursachen kann. Max. ein FS voll läuft.
Last edited by ddm3ve on 2012-02-10 15:09, edited 1 time in total.
02:32:12 21.12.2012 und dann sind Deine Probleme alle unwichtig.
-
- Administrator
- Posts: 2641
- Joined: 2004-01-21 17:44
Re: Partitionslayout
Bei mir hängt das Partitionslayout davon ab, wofür ich die Maschine einsetze, und welche Dateisysteme zum Einsatz kommen sollen.
Für Linux Desktop Installationen gilt bei mir normalerweise, wobei das LVM Volume bei Bedarf mit dm-crypt (AES-XTS) verschlüsselt wird (wenn es sich um ein Laptop handelt, das gerne mal die Wohnung oder den Arbeitsplatz verlässt). Auf dem LVM gibt's i.d.R. nur / und pro User ein eigenes /home/<user> Volume.
Für Server hängt es natürlich vom Einsatzzweck ab, aber grundsätzlich sieht bei mir ein Partitionslayout in etwa so aus:
Zur Erläuterung:
/usr nimmt den Ports Tree mit auf. Auf Systemen, die zusätzlich einen zpool besitzen, wird der Ports Tree i. d. R. dort mit untergebracht, so dass /usr kleiner ausfallen kann (i. d. R. dann 4GB). /var halte ich grundsätzlich getrennt, da dort die Accounting- und Audit-Daten landen. Mithilfe entsprechender Mount-Flags kann man diese gegen allzu leichte Manipulierbarkeit sichern; außerdem können das bei einem intensiveren Angriff schnell viele GB Daten werden - ein gewisser DoS-Schutz wird so also ebenfalls realisiert.
/tmp halte ich auf Servern ebenfalls grundsätzlich getrennt (noexec und nosuid), auf Systemen mit entsprechend viel RAM wird dafür ein md-Device mit mfs angelegt.
Jails oder andere Subsysteme, die dynamisch wachsen können müssen, wandern bei mir i. d. R. auf ZFS; normalerweise auch alle Nutzdaten - so kann ich die Snapshot-Funktion für unterbrechungsarme Backups nutzen.
Für Linux Desktop Installationen gilt bei mir normalerweise
Code: Select all
256MB /boot ext2
1-2 x RAM swap (abhängig von der RAM-Größe)
Rest LVM
Für Server hängt es natürlich vom Einsatzzweck ab, aber grundsätzlich sieht bei mir ein Partitionslayout in etwa so aus:
Code: Select all
s1a 4GB / ufs2
s1b 2x RAM swap sw
s1d 8GB /var ufs2
s1e 16GB /usr ufs2
s1f 2GB /tmp ufs2
s2..x zpool zfs
/usr nimmt den Ports Tree mit auf. Auf Systemen, die zusätzlich einen zpool besitzen, wird der Ports Tree i. d. R. dort mit untergebracht, so dass /usr kleiner ausfallen kann (i. d. R. dann 4GB). /var halte ich grundsätzlich getrennt, da dort die Accounting- und Audit-Daten landen. Mithilfe entsprechender Mount-Flags kann man diese gegen allzu leichte Manipulierbarkeit sichern; außerdem können das bei einem intensiveren Angriff schnell viele GB Daten werden - ein gewisser DoS-Schutz wird so also ebenfalls realisiert.
/tmp halte ich auf Servern ebenfalls grundsätzlich getrennt (noexec und nosuid), auf Systemen mit entsprechend viel RAM wird dafür ein md-Device mit mfs angelegt.
Jails oder andere Subsysteme, die dynamisch wachsen können müssen, wandern bei mir i. d. R. auf ZFS; normalerweise auch alle Nutzdaten - so kann ich die Snapshot-Funktion für unterbrechungsarme Backups nutzen.
“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH', the paint wouldn't even have time to dry.” — Terry Pratchett, Thief of Time
-
- Posts: 11
- Joined: 2012-01-23 11:18
- Location: Rheine
Re: Partitionslayout
Ich hab inzwischen grundsätzlich immer alles auf LVM und lasse in der VG noch Platz, damit man schnell eingreifen kann wenn man sich doch mal verschätzt hat.
/tmp, /var, /var/log und Mailspool sind bei mir fast immer eigene Partitionen.
ZFS und (teilweise, zum Testen) btrfs nutze ich inzwischen aber auch mehr und mehr
/tmp, /var, /var/log und Mailspool sind bei mir fast immer eigene Partitionen.
ZFS und (teilweise, zum Testen) btrfs nutze ich inzwischen aber auch mehr und mehr
-
- Posts: 128
- Joined: 2010-04-20 12:50
Re: Partitionslayout
Ich halte es mittlerweile ähnlich wie Joe User:
Fast alle Server (reines Debian/Ubuntu Umfeld) haben ausschließlich /, /boot und swap. LVM wird überall eingesetzt.
Dank Monitoring mit E-Mail- und ggf. SMS-Alarmierung spare ich mir das separieren von z.B. /var. Meine Limits sind so gesetzt, dass ich noch genug Luft habe, wenn wirklich mal was droht vollzulaufen.
In Zukunft möchte ich aber bei den DB-Servern das Datadir von MySQL auf eine ramdisk auslagern.
Zwecks Sicherheit überlege ich noch, bestimmte Bereiche zu separieren und read-only zu mounten, dazu fehlt mir aber die Erfahrung / best-practices.
Fast alle Server (reines Debian/Ubuntu Umfeld) haben ausschließlich /, /boot und swap. LVM wird überall eingesetzt.
Dank Monitoring mit E-Mail- und ggf. SMS-Alarmierung spare ich mir das separieren von z.B. /var. Meine Limits sind so gesetzt, dass ich noch genug Luft habe, wenn wirklich mal was droht vollzulaufen.
In Zukunft möchte ich aber bei den DB-Servern das Datadir von MySQL auf eine ramdisk auslagern.
Zwecks Sicherheit überlege ich noch, bestimmte Bereiche zu separieren und read-only zu mounten, dazu fehlt mir aber die Erfahrung / best-practices.
ZWNobyAiSGVsbCB5ZWFoLCBiYXNlNjQiIHwgYmFzZTY0ClNHVnNiQ0I1WldGb0xDQmlZWE5sTmpRSw==
-
- Moderator
- Posts: 1235
- Joined: 2011-07-04 10:56
Re: Partitionslayout
Das mit der RAM disk hat Du Dir hoffentlich gut überlegt.dante wrote: In Zukunft möchte ich aber bei den DB-Servern das Datadir von MySQL auf eine ramdisk auslagern.
Wie sicherst du die Daten weg?
DRBD auf eine lokale Platte oder gar Replikation aufn ein externes System?
Beides bringt Dir im wesentlichen wenig.
Wenn es nur um Leseoptimerung geht, dann solltest Du über innodb und einen ordentlichen Cache nach denken. Ansonsten ist mit einem RAMFS der Einsatz einer Datenbank ziemlicher Overhead, denn du gar nicht benötigst.
Last edited by ddm3ve on 2012-03-28 14:53, edited 1 time in total.
02:32:12 21.12.2012 und dann sind Deine Probleme alle unwichtig.
-
- Project Manager
- Posts: 11183
- Joined: 2003-02-27 01:00
- Location: Hamburg
Re: Partitionslayout
Davon rate ich dringend ab, denn wenn der Strom ausfällt, oder ein RAM-Riegel kaputt geht, oder die Kiste rebootet wird, dann sind die Daten der DB futsch. Und kostbarer RAM geht auch noch unnötig flöten.dante wrote:In Zukunft möchte ich aber bei den DB-Servern das Datadir von MySQL auf eine ramdisk auslagern.
Vernünftige Caches/Buffer setzen und die DB-Zugriffe werden trotzdem im RAM durchgeführt, da die Datenbanken ohnehin von MySQL im RAM gecached werden.
PayPal.Me/JoeUser ● FreeBSD Remote Installation
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
-
- Posts: 128
- Joined: 2010-04-20 12:50
Re: Partitionslayout
/OT
Danke, dann wird diese Idee verworfen. Ich sage ja, die Erfahrung fehlt noch.
Danke, dann wird diese Idee verworfen. Ich sage ja, die Erfahrung fehlt noch.
ZWNobyAiSGVsbCB5ZWFoLCBiYXNlNjQiIHwgYmFzZTY0ClNHVnNiQ0I1WldGb0xDQmlZWE5sTmpRSw==
-
- Posts: 55
- Joined: 2004-06-13 11:59
- Location: Hamburg
Re: Partitionslayout
Moin moin,
ich halte es ebenfalls wie Joe User: Auf der Workstation /boot, swap und / für den Rest. Auf dem "läuft nebenher"-Server ist /home noch eine eigene Partition. Faulheit sieht dort ;)
Auf Produktionsmaschinen sieht es da aber weiterhin anders aus. Für den professionellen Einsatz birgt die einfache Partitionierung meiner Meinung nach Nachteile, die man durch Partitionierung umgehen kann. Insbesondere amoklaufende Prozesse, die permanent in Logfiles schreiben, müllen so wenigstens nicht die gesamte Festplatte zu.
So long
M.C.S.
ich halte es ebenfalls wie Joe User: Auf der Workstation /boot, swap und / für den Rest. Auf dem "läuft nebenher"-Server ist /home noch eine eigene Partition. Faulheit sieht dort ;)
Auf Produktionsmaschinen sieht es da aber weiterhin anders aus. Für den professionellen Einsatz birgt die einfache Partitionierung meiner Meinung nach Nachteile, die man durch Partitionierung umgehen kann. Insbesondere amoklaufende Prozesse, die permanent in Logfiles schreiben, müllen so wenigstens nicht die gesamte Festplatte zu.
So long
M.C.S.