Vraag Hoe erg is het echt om Linux op één grote partitie te installeren?


CentOS 7 wordt op onze nieuwe server uitgevoerd. We hebben 6 x 300GB-schijven in raid6 intern op de server. (Opslag is grotendeels extern in de vorm van een 40TB-overvalbox.) Het interne volume bedraagt ​​ongeveer 1,3 TB als het wordt geformatteerd als een enkel volume. Onze systeembeheerder denkt dat het een heel slecht idee is om het besturingssysteem op één grote 1.3TB-partitie te installeren.

Ik ben een bioloog. We installeren constant nieuwe software om uit te voeren en te testen, waarvan de meeste landen in / usr / local landen. Omdat we echter ongeveer 12 niet-computergestuurde biologen hebben die het systeem gebruiken, verzamelen we ook veel cruft in / home. Onze laatste server had een partitie van 200 GB voor / en na 2,5 jaar was deze 90% vol. Ik wil niet dat dit opnieuw gebeurt, maar ik wil ook niet tegen deskundig advies ingaan!

Hoe kunnen we de 1.3TB die beschikbaar is optimaal gebruiken om ervoor te zorgen dat de ruimte beschikbaar is waar en wanneer het nodig is, maar geen onderhoudsparcord voor de systeembeheerder te creëren ??


91
2017-09-18 08:12


oorsprong


Gebruik LVM en formaat naar wens - thanasisk
@thanasisk At zal willen dat hergebruik een mythe is, omdat er geen bestandssysteem op Linux is dat online gekrompen kon worden. ext2 had een dergelijke patch in de oudheid. - peterh
@ Peter Horvath - ben je dan blij als ik "vergroten / verkleinen" door "uitbreiden" vervang? - thanasisk
Het is een beetje onrealistisch om te verwachten wat je nu hebt ingesteld om over 2,5 jaar nog steeds optimaal te zijn! En het feit dat niet-slimme gebruikers een zooitje maken, is des te meer reden om OS van gegevens te scheiden. - JamesRyan
@PeterHorvath Ik heb je opmerking meer dan eens gelezen, zodat ik het kon begrijpen. Je schreef dat je blij zou zijn als er een bestandssysteem bestond dat kon uitbreiden en ik wees op een bestandssysteem dat dat wel doet. Dat is alles. - gparent


antwoorden:


De belangrijkste (historische) redenen voor partitionering zijn:

  • naar scheid het besturingssysteem van uw gebruikers- en applicatiegegevens. Tot de release van RHEL 7 was er geen ondersteuning upgrade pad en een belangrijke versie-upgrade zou een herinstallatie vereisen en dan bijvoorbeeld hebben /home en andere (toepassings) gegevens op afzonderlijke partities (of LVM-volumes), kunt u eenvoudig de gebruikersgegevens en toepassingsgegevens behouden en de OS-partitie (s) wissen.

  • Gebruikers kunnen zich niet correct aanmelden en uw systeem begint op interessante manieren te falen wanneer u volledig geen schijfruimte meer hebt. Met meerdere partities kunt u hard-gereserveerde schijfruimte toewijzen aan het besturingssysteem en deze gescheiden houden van de plaatsen waar gebruikers en / of specifieke toepassingen mogen schrijven (bijv. /home /tmp/ /var/tmp/ /var/spool/ /oradata/ enz.) , het verminderen van operationeel risico van slecht opgevoede gebruikers en / of applicaties.

  • Quota. Met schijfquota kan de beheerder voorkomen dat een individuele gebruiker alle beschikbare ruimte opgebruikt, waardoor de service aan alle andere gebruikers van het systeem wordt onderbroken. Individuele schijfquota worden toegewezen per bestandssysteem, dus een enkele partitie en dus een enkel bestandssysteem betekent slechts één schijfquotum. Meerdere (LVM) partities betekent meerdere bestandssystemen die een meer gedetailleerd quotabeheer mogelijk maken. Afhankelijk van uw gebruiksscenario wilt u bijvoorbeeld elke gebruiker 10 GB toestaan ​​in zijn basismap, 2 TB in de map / data op de externe opslagarray en een groot gedeeld scratch-gebied instellen waar iedereen datasets kan dumpen die te groot zijn voor hun basismap en waar het beleid "vol is vol" wordt, maar wanneer dat gebeurt, breekt ook niets.

  • Het verstrekken van specifieke IO-paden. Je hebt misschien een combinatie van SSD's en draaiende schijven en doet er goed aan ze anders aan te pakken. Niet zozeer een probleem in een server voor algemene doeleinden, maar vrij gebruikelijk in database-instellingen is het ook toewijzen van bepaalde spillen (schijven) aan verschillende doeleinden om IO-conflicten te voorkomen, b.v. afzonderlijke schijf voor de transactielogboeken, afzonderlijke schijven voor feitelijke databasegegevens en afzonderlijke schijven voor tijdelijke ruimte. .

  • Bagageruimte Misschien heb je een aparte plek nodig /boot partitie. Historisch gezien om BIOS-problemen aan te pakken met opstarten voorbij de cilinderlimiet van 1024, tegenwoordig vaker een vereiste om gecodeerde volumes te ondersteunen, om bepaalde RAID-controllers te ondersteunen, HBA's die geen ondersteuning bieden voor opstarten vanaf SAN of bestandssystemen die niet onmiddellijk worden ondersteund door het installatieprogramma enz.

  • stemming Je hebt misschien behoefte aan verschillende afstemmingsopties of zelfs volledig verschillende bestandssystemen.

Als je harde partities gebruikt, moet je het min of meer op het juiste moment installeren en dan is een enkele grote partitie niet de ergste, maar deze heeft wel enkele van de bovenstaande beperkingen.

Meestal raad ik aan om je hoofdvolume te partitioneren als een enkele grote Linux LVM fysiek volume en dan maak logische volumes aan die passen bij uw huidige behoeften en voor de rest van uw schijfruimte, laat niet toegewezen totdat het nodig is.

U kunt dan die volumes en hun bestandssystemen naar behoefte uitbreiden (wat een triviale handeling is die op een levend systeem kan worden gedaan), of u kunt ook extra volumes maken.

Krimpende LVM-volumes zijn triviaal maar vaak het verkleinen van de bestandssystemen daarop wordt niet erg goed ondersteund en waarschijnlijk moet worden vermeden.


103
2017-09-18 09:49



Met betrekking tot het prestatie-item, denk ik dat het ook de moeite waard is erop te wijzen dat, in het geval van een bestandssysteem dat een snel antwoord vereist, en 'df' nuttige informatie veel sneller zal teruggeven dan 'du -s $ DIRNAME' - symcbean
Ik weet niet zeker of ik het hiermee eens bentot ... RH7 ... geen ondersteund upgradepad"Ik heb sinds mijn afwezigheid ondersteunde upgrades gedaan, en zeker een upgrade van systemen RH4-> 5 enkel en alleen RH5-> RH6 die een dergelijk pad miste, voor zover ik weet - en ik heb het gevoel dat RH door dat soort gebruikers uitgebreid is afgedroogd. +1 voor de rest van een uitstekend antwoord. - MadHatter
Waarnaar verwijst u met "Tot de release van RHEL 7 was er geen ondersteund upgrade-pad"? Ondersteunt RHEL upgrades tussen de belangrijkste versies van RHEL 7 en forward? - Markus Hallmann
Upgrades werkten wel, maar volgens rode Hoed het algemene beleid is nog steeds: Red Hat ondersteunt geen interne upgrades tussen belangrijke versies van Red Hat Enterprise Linux.  en een beetje nuance verderop Red Hat ondersteunt momenteel alleen upgrades van Red Hat Enterprise Linux 6 naar Red Hat Enterprise Linux 7 voor specifieke / gerichte use-cases en hier is de handleiding controleren - HBruijn


Het concept van het gebruik van meerdere partities is dat een volledig exemplaar op de verkeerde plaats er niet voor zorgt dat het hele systeem onverwacht werkt.

Overweeg een proces op de machine die een logbestand snel opvult tot het punt dat er geen vrije ruimte beschikbaar is. Op een machine met één partitie kan dit bijvoorbeeld voorkomen dat het systeem nieuwe gegevens naar / tmp schrijft. Als er een ander proces is dat naar / tmp zou willen schrijven, zou het waarschijnlijk afsluiten met een fout en onverwacht gedrag veroorzaken.

Dit kan worden voorkomen als u verschillende partities gebruikt voor plaatsen waar gebruikers of processen normaal naar schrijven (/ home, / var, / tmp).

Ik zou aanraden dat u uw oude server controleert welke mappen er groot uitzien. U kunt dat doen op de opdrachtregel met

du -h -d 1 / 2> /dev/null

U ziet waar de meeste gegevens zijn verzameld en ontwerpt uw ​​volgende systeem op de juiste manier. De "-d 1" begrenst de uitvoer tot slechts één niveau van mapdiepte, waardoor deze leesbaarder wordt.


17
2017-09-18 08:38





Het grootste probleem met het hebben van een enkele grote partitie is dat het vullen van het bestandssysteem mogelijk is dat er geen login meer mogelijk is.

De root van de gebruiker heeft zijn basismap (/root) buiten /home vanwege dit. Als het bestandssysteem in sommige omstandigheden is opgevuld, kan zelfs de root niet inloggen en kan het systeem niet worden gerepareerd.

Dit is de reden waarom je normaal aparte bevestigingspunten voor maakt /var, /tmp en /home om minimaal als root in te kunnen loggen om het systeem te herstellen wanneer een van de andere partities is opgevuld.


12
2017-09-18 08:23



op sommige bestandssystemen (ext3 f.e.) kunt u een beetje gereserveerde ruimte hebben voor de rootgebruiker om dat gedrag te voorkomen. je zou quota's moeten gebruiken om dat te voorkomen, hetzelfde voor / tmp dat vaak wordt vergeten. - Dennis Nolte
@DennisNolte Ik ben het vergeten /tmp. Bedankt, ik zal dit toevoegen aan mijn antwoord. - Uwe Plonus
@DennisNolte de gereserveerde ruimte zal helpen, maar ik denk dat het onderhoud moeilijker is dan het gebruik van verschillende partities omdat je de quota correct moet instellen. - Uwe Plonus
Ik denk dat een belangrijkere reden voor /root buiten zijn /home is dat op sommige installaties /home bevindt zich op een netwerkstation. In het geval van problemen met de installatie via het netwerk, blijven root-bestanden toegankelijk. (Dit kan worden vergeleken met hoe er gewoonlijk een teksteditor is /bin, in geval dat /usr zal niet opkomen.) Ik vermoed dat dit in de praktijk tegenwoordig een meer gebruikelijk scenario is dan /home helemaal vullen. - Eliah Kagan


IMHO, met een partitie als / is redelijk.

Maar u kunt lvm gebruiken (logische volumemanager). Gebruik alle schijven als lvm-groep, maar maak kleine logische schijven voor /, / home, / usr en alles wat uw systeembeheerder de voorkeur geeft. Zet dan wat monitoring op, dat weet je, wanneer je systeem vol begint te raken en de schijven uitbreidt die je nodig hebt. lvresize en resize2fs zijn onlinetools en u kunt een uitbreiding uitvoeren zonder de server opnieuw op te starten. U kunt schijven echter niet verminderen, dus u moet redelijk klein beginnen en toenemen waar u behoefte ziet.


10
2017-09-18 08:22





Er zijn minimale problemen rond de grote single-partition setup van linux, maar het heeft grote voordelen.

Het veranderen van een partitie-indeling is een beetje moeilijk en riskant, wat je vaak niet kunt doen zonder lange stilstandtijden.

Het enige voordeel is dat je enige bescherming hebt tegen problemen met de schijf. Maar je zult deze problemen vinden veel vaak. Stel je de situatie voor als een van je partities vol is, en je kunt de ruimte op de andere partities niet gebruiken, zelfs als ze bijna leeg zijn!

Sommige professionele systeembeheerders hebben hier een totaal verschillende mening over. Ze zeggen dat het hebben van meerdere partities je systeem betrouwbaarder kan maken en je moet voor je partitionering weten hoe groot je partities zullen zijn. Naar mijn mening kan dit simpelweg niet gezegd worden, het is een verschrikkelijk nadeel van de flexibiliteit van het systeem, en hun echte motivatie is dat ze eenvoudigweg Graag spelen met de partitiekaarten.

Er is een eenvoudig systeem met de naam lvm, waarmee het on-the-fly verplaatsen / vergroten of verkleinen van "partities" mogelijk is (in de terminologie, volumes). Maar op een enkele lokale afdelingsserver, IMHO, is dit normaal gesproken niet nodig.


9
2017-09-18 08:43



Wat voor soort masochistische admin sympathieën om met partitiekaarten te spelen ??? Het leuke is het bouwen van de kernel, kan ik een amen??? - bishop
amen! Nu over het argument dat admins graag met partities spelen, zou ik dat gewoon willen tegengaan met het feit dat linux waarschijnlijk 100 verschillende bestandssysteemtypes heeft en afhankelijk van de gebruikspatronen kan het kiezen van het juiste bestandssysteem voor een bepaalde taak betekenen het verschil tussen een optimaal systeem en een niet-functioneel systeem. En misschien heb je dat bestandssysteem alleen in een paar mappen nodig. Er. - Lennart Rolland


Er zijn twee hoofdredenen voor partitionering:

  1. Om statische gegevens uit de buurt van niet-statische gegevens te houden
  2. Om openbare gegevens uit de buurt van privégegevens te houden

De eerste reden is de meest voor de hand liggende: u moet gebieden isoleren die worden opgevuld met bestanden van bestanden die dat niet doen en die u vooral wilt beschermen / om een ​​niet-opstartbaar systeem te vermijden. De / var-directory is bijvoorbeeld meestal waar logbestanden worden opgeslagen (var staat voor "variable") en dit is de reden waarom / var de neiging heeft om op een aparte partitie te worden gemount vanaf /.

De tweede reden hierboven is minder geciteerd (ik heb het voor het laatst gehoord op een cursus Veritas Volume Manager ongeveer 15 jaar geleden) en het is echt alleen relevant voor systemen waar veel mensen inloggen en werk uitvoeren.

Er is iets van een kunst voor effectieve paritionering, en dit is misschien waarom Sys-admins het een beetje te ver voeren (IMO). U moet niet alleen het bestandssysteem van binnen en van buiten kennen, maar u moet ook het bedoelde gebruik weten. Ik vind persoonlijk dat het een nogal ouderwetse benadering is die steeds minder relevant wordt voor de manier waarop servers tegenwoordig worden gebruikt.

Als softwareontwikkelaar heb ik vooral genoeg van het Ops-afdelingsgebouw met virtuele machines met gedachteloze partitioneringsschema's die de grootte van / tmp, / home, / var en / beperken, ongeacht de totale schijfruimte die beschikbaar is, maar dan geen voor de hand liggende keuzes zoals / usr of / opt afzonderlijk. Deze machines zullen gewoonlijk alles wat overblijft van de schijfruimte die je hebt gevraagd overbrengen in een "/ stuff" -volume waarvan je onvermijdelijk uiteindelijk alles installeert en symboliseert, maar dat is nauwelijks een troost. Het netto resultaat is dat we vaak meer tijd besteden aan het door elkaar gooien van bestanden en het versturen van waarschuwings-e-mails dan het doen van enig echt werk.

Er is niets inherent "slecht" aan het hebben van een enkele partitie. Op elk systeem moet u proactief uw schijfgebruik monitoren en verstandige huishoudstrategieën gebruiken (bijvoorbeeld logboekrotatie, quota's op homedirectory's), dus de enige echte vraag is: op hoeveel afzonderlijke bestandssystemen wilt u zich zorgen maken?

Ik zou daarom zeggen: tenzij u 100% zeker bent van uw vermogen om het systeem effectief te partitioneren voor uw specifieke gebruik, hoeft u helemaal niet te partitioneren.


3
2017-09-18 09:41



Precies. Ok, misschien moet de publiek-private scheiding van gegevens worden gedaan door de machtigingen in het bestandssysteem en in uw services. - peterh


IMHO het is helemaal aan jou. Overweeg eerst een paar dingen, hoewel het geheel enigszins relatief is.

  • zal dit systeem vaak worden toegediend?
  • wordt dit systeem gebruikt door een of meer gebruikers?
  • zal dit systeem dienen als een desktop of een server, of beide?

Aangezien men (bijna) elke directory als een mountpoint kan beschouwen, moet men ook overwegen wat enigszins groeiende data bevat en wat groeiende data bevat.

Je zou er versteld van staan ​​hoe weinig een linux-systeem (enigszins groeiende gegevens) nodig heeft om te draaien en hoeveel wordt verbruikt door groeiende gegevens (meestal / var / opt / home / srv)

Het hangt ook af van hoe u het gebruik voor dit systeem definieert, dat de partitioneringsvereisten schetst. Het gebruik voor LVM inbegrepen.

Een typisch desktopsysteem vereist ongeveer 20 GB voor het installeren van veel software, en als de rest is toegewezen aan een dedicated / home, doet dat prima. LVM veroorzaakt een kleine overhead op uw systeem en is in dit geval niet zo'n groot voordeel. Hoewel meningen kunnen verschillen.

Op een server is het minder waarschijnlijk dat geïnstalleerde software even dynamisch is als voor een desktopsysteem. Het is ook verstandiger om actuele mountpoints voor typische bestandssysteemcomponenten zoals / tmp / var / usr / home / opt / srv te gebruiken. Het gebruik van LVM hier wordt aanbevolen om niet te zeggen verplicht.

Dit biedt een uitstekende modulariteit van je systeem, maar het laat ook toe om gekke dingen te doen, zoals bijvoorbeeld het klonen van die partitie in een VM. Of maak een back-up op blokniveau met behulp van dd.

Gebaseerd op wat ervaring, hier zijn een paar opmerkingen. Overweeg ook dat meerdere mount-punten een grotere controle toestaan, en een snel of langzaam schijfapparaat aan een mountpoint toewijzen, kan een wereld van verschil maken en de kostenefficiëntie aanzienlijk verhogen.

Mounpoint /

  • 1 GB (bij gebruik van afzonderlijke mountpoints voor / var / usr / opt / home / tmp)
  • +10 of zelfs +20 GB bij gebruik als een desktopsysteem met een afzonderlijk / thuisadres

bij gebruik van mountpoint / home

  • wijs alle vrije ruimte toe indien gebruikt, / home ne

bij gebruik van mountpoint / opt

bij gebruik van mountpoint / usr

  • dit is een lastige en enorm afhankelijk van de geïnstalleerde software

bij gebruik van mountpoint / var

  • dit is een lastige en enorm afhankelijk van de geïnstalleerde software
  • databases schrijven hun gegevens bijvoorbeeld hier op op Debian gebaseerde systemen, zo niet alle Linux
  • met een aparte / var / tmp is niet onredelijk

bij gebruik van koppelpunt / tmp

  • overweeg tmpfs bestaat en toegewezen / tmp aan RAM
  • overweeg dat sommige applicaties hier veel gegevens kunnen schrijven

2
2017-09-18 14:18