Vraag LVM-gevaren en kanttekeningen


Ik ben sinds kort LVM gaan gebruiken op sommige servers voor harde schijven die groter zijn dan 1 TB. Ze zijn handig, uitbreidbaar en vrij eenvoudig te installeren. Ik kon echter geen gegevens vinden over de gevaren en voorbehouden van LVM.

Wat zijn de nadelen van het gebruik van LVM?


177
2018-06-12 07:34


oorsprong


Houd bij het lezen van de antwoorden op deze vraag rekening met de datum (jaar) waarop ze zijn geplaatst. Er gebeurt veel in 3 jaar tijd in deze branche. - MattBianco
Ik heb onlangs een aantal updates gedaan (april 2015) nadat ik heb gescand om te zien of er iets is veranderd. De 2.6-kernel is nu verouderd, SSD's komen vaker voor, maar afgezien van enkele kleine LVM-fixes is er niet veel veranderd. Ik heb wel wat nieuwe dingen geschreven over het gebruik van VM / cloud server snapshots in plaats van LVM snapshots. De staat van schrijven caching, het wijzigen van het bestandssysteem en LVM snapshots zijn niet echt zo veel veranderd als ik kan zien. - RichVel
met betrekking tot de opmerking "houd rekening met de datum" - het is waar genoeg, maar bedenk ook dat veel "ondernemingen" nog steeds RHEL 5 en RHEL 6 gebruiken, beide zijn state-of-the-art of ouder dan de datum van het antwoord - JDS


antwoorden:


Samenvatting

Risico's van het gebruik van LVM:

  • Kwetsbaar om cacheproblemen met SSD of VM-hypervisor te schrijven
  • Harder om gegevens te herstellen vanwege complexere structuren op de schijf
  • U moet de grootte van bestandssystemen verbeteren
  • Snapshots zijn moeilijk te gebruiken, traag en met fouten
  • Vereist enige vaardigheid om correct te configureren, gezien deze problemen

De eerste twee LVM-problemen combineren: als write-caching niet correct werkt en u een vermogensverlies hebt (bijvoorbeeld PSU of UPS mislukt), moet u mogelijk herstellen van back-up, wat betekent dat u veel downtime gebruikt. Een belangrijke reden voor het gebruik van LVM is een hogere uptime (bij het toevoegen van schijven, het wijzigen van bestandssystemen, enz.), Maar het is belangrijk om de instelling voor het in cache plaatsen correct te maken om te voorkomen dat LVM de uptime vermindert.

- Bijgewerkt sep 2017: maakte het oude kernelmateriaal minder prominent

Beperking van de risico's

LVM kan nog steeds goed werken als u:

  • Haal je schrijfcache-instellingen rechtstreeks op in hypervisor, kernel en SSD's
  • Vermijd LVM snapshots
  • Gebruik recente LVM-versies om het formaat van bestandssystemen te wijzigen
  • Zorg voor goede back-ups

Details

Ik heb dit in het verleden nogal wat onderzocht, omdat ik wat gegevensverlies heb ervaren dat verband houdt met LVM. De belangrijkste LVM-risico's en -problemen die mij bekend zijn, zijn:

Kwetsbaar voor schrijfcaching op de harde schijf vanwege VM-hypervisors, schijfcaching of oude Linux-kernels, en maakt het moeilijker om gegevens te herstellen vanwege complexere structuren op de schijf - zie hieronder voor meer informatie. Ik heb gezien dat complete LVM-instellingen op verschillende schijven corrupt zijn geworden zonder kans op herstel, en LVM plus schrijfcaching op de harde schijf is een gevaarlijke combinatie.

  • Schrijf caching en schrijf een nieuwe bestelling op de harde schijf is belangrijk voor goede prestaties, maar kan blokken niet correct naar schijf sturen vanwege VM-hypervisors, schrijfcaching op de harde schijf, oude Linux-kernels, enz.
    • Schrijf barrières betekent dat de kernel garandeert dat het bepaalde schrijfbewerkingen zal voltooien voordat de "barrier" -schijf wordt geschreven, om te zorgen dat bestandssystemen en RAID zich kunnen herstellen in geval van plotseling stroomverlies of een crash. Dergelijke barrières kunnen gebruik maken van a FUA (Force Unit Access) -bediening om onmiddellijk bepaalde blokken naar de schijf te schrijven, wat efficiënter is dan een volledige cachevlakking. Belemmeringen kunnen worden gecombineerd met efficiënt gelabeld/inheems opdrachtwachtrij (meerdere I / O-verzoeken tegelijk verzenden) om de harde schijf in staat te stellen een intelligente schrijfherordening uit te voeren zonder het risico van gegevensverlies te vergroten.
  • VM-hypervisors kan vergelijkbare problemen hebben: LVM uitvoeren in een Linux-gast bovenop een VM-hypervisor zoals VMware, Xen, KVM, Hyper-V of VirtualBox kunnen maken soortgelijke problemennaar een kernel zonder schrijfbarrières, als gevolg van write caching en herschrijving van schrijfopdrachten. Controleer de documentatie van uw hypervisor zorgvuldig voor een "flush to disk" of write-through cache-optie (aanwezig in KVM, VMware, Xen, VirtualBox en anderen) - en test het met uw opstelling. Sommige hypervisors zoals VirtualBox hebben een standaardinstelling die negeert elke schijf flushes van de gast.
  • Enterprise-servers met LVM moeten altijd a gebruiken batterij-backed RAID-controller en schakel de schrijfcache van de harde schijf uit (de controller heeft schrijfcache met batterijvoeding die snel en veilig is) - zie deze opmerking door de auteur van deze XFS-veelgestelde vraag. Het kan ook veilig zijn om schrijfbarrières uitschakelen in de kernel, maar testen wordt aanbevolen.
  • Als u geen RAID-controller met een batterij hebt, zal het uitschakelen van de schrijfcaching op de harde schijf het schrijven aanzienlijk vertragen, maar LVM veilig maken. Je zou ook het equivalent van ext3's moeten gebruiken data=ordered optie (of data=journal voor extra veiligheid), plus barrier=1 om ervoor te zorgen dat kernel-caching de integriteit niet beïnvloedt. (Of gebruik ext4 die schakelt standaard barrières in.) Dit is de eenvoudigste optie en biedt goede gegevensintegriteit tegen prestatiekosten. (Linux veranderde de standaard ext3 optie voor de meer gevaarlijke data=writeback een tijdje terug, dus vertrouw niet op de standaardinstellingen voor de FS.)
  • Om schrijfcaching op de harde schijf uit te schakelen: toevoegen hdparm -q -W0 /dev/sdX voor alle stations in /etc/rc.local (voor SATA) of gebruik sdparm voor SCSI / SAS. Echter volgens dit bericht in de XFS FAQ (wat erg goed is in dit onderwerp), kan een SATA-schijf deze instelling vergeten na een herstel van de schijffout - dus je zou SCSI / SAS moeten gebruiken, of als je SATA zou moeten gebruiken, zet dan de hdparm-opdracht in een cron-job ongeveer elke minuut.
  • Om ervoor te zorgen dat schrijfcaching op de SSD / harde schijf is ingeschakeld voor betere prestaties: dit is een complex gebied - zie onderstaande sectie.
  • Als je gebruikt Advanced Format-schijven d.w.z. 4 KB fysieke sectoren, zie hieronder - het uitschakelen van schrijfcache kan andere problemen hebben.
  • UPS is cruciaal voor zowel enterprise als SOHO, maar niet genoeg om LVM veilig te maken: alles dat een harde crash of een stroomverlies veroorzaakt (bijvoorbeeld UPS-storing, PSU-storing of uitputting van de laptop) kan gegevens verliezen in de cache van de harde schijf.
  • Zeer oude Linux-kernels (2.6.x vanaf 2009): Er is onvolledige schrijfbarrièreondersteuning in zeer oude kernelversies, 2.6.32 en eerder (2.6.31 heeft enige ondersteuning, terwijl 2.6.33 werkt voor alle soorten apparaatdoelen) - RHEL 6 gebruikt 2.6.32 met veel patches. Als deze oude 2.6-kernels niet worden gecrawld voor deze problemen, kan een groot aantal FS-metadata (inclusief journals) verloren gaan door een harde crash die gegevens op de schrijfbuffers van de harde schijven achterlaat (bijvoorbeeld 32 MB per schijf voor gewone SATA-schijven). Het verliezen van 32 MB van de meest recent geschreven FS-metagegevens en journaalgegevens, waarvan de kernel denkt dat deze zich al op schijf bevindt, betekent meestal veel FS-corruptie en dus gegevensverlies.
  • Samenvatting: u moet voorzichtig zijn in het bestandssysteem, RAID, VM-hypervisor en de opstelling van de harde schijf / SSD die worden gebruikt met LVM. U moet zeer goede back-ups hebben als u LVM gebruikt en u moet specifiek een back-up maken van de LVM-metadata, fysieke partitie-instellingen, MBR en volume-opstartsectoren. Het is ook raadzaam om SCSI / SAS-schijven te gebruiken, omdat deze minder snel liegen over de manier waarop ze cachegeheugens schrijven - er is meer zorg nodig om SATA-schijven te gebruiken.

Inleescaching ingeschakeld houden voor prestaties (en omgaan met liggende drives)

Een complexere maar meer performante optie is om schrijfcaching op SSD / harde schijf ingeschakeld te houden en te vertrouwen op kernel-schrijfbelemmeringen die werken met LVM op kernel 2.6.33+ (controleer dit door te zoeken naar "barrière" -berichten in de logs).

Je moet er ook voor zorgen dat de RAID-setup, VM-hypervisor-installatie en het bestandssysteem gebruikt schrijfbarrières (d.w.z. vereist dat de drive wachtende schrijfopdrachten doorspoelen vóór en na belangrijke metagegevens / journaal schrijft). XFS gebruikt standaard barrières, maar ext3 niet, dus met ext3 zou je moeten gebruiken barrier=1 in de mount-opties, en nog steeds gebruiken data=ordered of data=journal zoals hierboven.

SSD's zijn problematisch omdat het gebruik van schrijfcache cruciaal is voor de levensduur van de SSD. Het is het beste om een ​​SSD te gebruiken die een supercondensator heeft (om cachespoelen bij stroomuitval in te schakelen en om cachegeheugen dus in te schakelen als niet-doorschrijfprocedure).

Geavanceerd formaat schijfinstellingen - schrijf caching, uitlijning, RAID, GPT

  • Met nieuwer Advanced Format-schijven die 4 KiB fysieke sectoren gebruiken, kan het belangrijk zijn schijfchace-caching ingeschakeld te houden, aangezien de meeste van dergelijke schijven momenteel 512 bytes logische sectoren emuleren ("512-emulatie"), en sommigen beweren zelfs 512-byte fysieke sectoren te hebben terwijl ze echt 4 KiB gebruiken.
  • Het uitschakelen van de schrijfcache van een station met geavanceerde formattering kan een zeer grote invloed hebben op de prestaties als de toepassing / kernel schrijfbewerkingen van 512 bytes uitvoert, omdat dergelijke schijven afhankelijk zijn van de cache om 8 x 512 bytes te schrijven voordat een enkele 4 KiB fysiek wordt uitgevoerd schrijven. Testen wordt aanbevolen om eventuele gevolgen te bevestigen als u de cache uitschakelt.
  • De LV's op een 4 KiB-grens uitlijnen is belangrijk voor de prestaties, maar zou automatisch moeten gebeuren zolang de onderliggende partities voor de PV's zijn uitgelijnd, aangezien LVM Physical Extents (PE's) standaard standaard 4 MiB zijn. RAID moet hier worden bekeken - dit LVM en software-RAID-instellingenpagina stelt voor om het RAID-superblok aan het einde van het volume te plaatsen en (indien nodig) een optie aan te zetten pvcreate om de PV's uit te lijnen. Deze LVM-lijst met e-maillijsten verwijst naar het werk dat in 2011 in kernels is gedaan en de kwestie van gedeeltelijke blokschrijvingen bij het mixen van schijven met 512 bytes en 4 KiB-sectoren in één LV.
  • GPT-partitionering met geavanceerde indeling heeft zorg nodig, vooral voor boot + root-schijven, om te zorgen dat de eerste LVM-partitie (PV) begint op een 4 KiB-grens.

Harder om gegevens te herstellen vanwege complexere structuren op de schijf:

  • Elke terugwinning van LVM-gegevens die vereist zijn na een harde crash of stroomverlies (als gevolg van onjuiste cache in de write-modus) is op zijn best een handmatig proces, omdat er blijkbaar geen geschikt gereedschap is. LVM is goed in het maken van back-ups van zijn metadata /etc/lvm, wat kan helpen de basisstructuur van LV's, VG's en PV's te herstellen, maar niet zal helpen met verloren metadata van het bestandssysteem.
  • Daarom is een volledige terugzetting van de back-up waarschijnlijk vereist. Dit brengt veel meer downtime met zich mee dan een snelle, op tijdschriften gebaseerde fsck wanneer LVM niet wordt gebruikt, en gegevens die sinds de laatste back-up zijn geschreven, gaan verloren.
  • TestDisk, ext3grep, ext3undel en andere hulpmiddelen  kan partities en bestanden van niet-LVM-schijven herstellen, maar ze ondersteunen niet rechtstreeks het LVM-gegevensherstel. TestDisk kan ontdekken dat een verloren fysieke partitie een LVM PV bevat, maar geen van deze tools begrijpt logische volumes van LVM. Bestand snijwerk tools zoals PhotoRec en vele anderen zouden werken als ze het bestandssysteem omzeilen om bestanden opnieuw te assembleren uit datablokken, maar dit is een uiterste, laagwaardige benadering voor waardevolle gegevens en werkt minder goed bij gefragmenteerde bestanden.
  • Handmatig LVM-herstel is in sommige gevallen mogelijk, maar is complex en tijdrovend - zie dit voorbeeld en deze, deze, en deze voor hoe te herstellen.

U moet de grootte van bestandssystemen verbeteren - eenvoudig formaat wijzigen van het bestandssysteem wordt vaak gegeven als een voordeel van LVM, maar je moet een half dozijn shell-commando's uitvoeren om de grootte van een op LVM gebaseerde FS aan te passen - dit kan gedaan worden met de hele server nog steeds omhoog, en in sommige gevallen met de FS gemonteerd, maar ik zou dit laatste nooit riskeren zonder up-to-date back-ups en het gebruik van vooraf geteste commando's op een gelijkwaardige server (bijv. disaster recovery-kloon van productieserver).

  • Bijwerken: Meer recente versies van lvextend steun het -r (--resizefs) optie - als dit beschikbaar is, is het een veiligere en snellere manier om de LV en het bestandssysteem te verkleinen, vooral als je de FS verkleint, en je kunt dit gedeelte meestal overslaan.
  • De meeste handleidingen voor het wijzigen van het formaat van LVM-gebaseerde FS's houden geen rekening met het feit dat de FS iets kleiner moet zijn dan de LV: gedetailleerde uitleg hier. Wanneer u een bestandssysteem verkleint, moet u de nieuwe grootte van het FS-formaat wijzigen, bijvoorbeeld resize2fs voor ext3 en naar lvextend of lvreduce. Zonder grote zorgvuldigheid kunnen de afmetingen enigszins afwijken vanwege het verschil tussen 1 GB (10 ^ 9) en 1 GiB (2 ^ 30), of de manier waarop de verschillende gereedschappen rond de maat omhoog of omlaag gaan.
  • Als je de berekeningen niet precies juist uitvoert (of een paar extra stappen gebruikt die verder gaan dan de meest voor de hand liggende), kun je eindigen met een FS die te groot is voor de LV. Alles zal maanden of jaren prima lijken, totdat je de FS volledig invult, en je zult ernstige corruptie krijgen - en tenzij je op de hoogte bent van dit probleem, is het moeilijk om erachter te komen waarom, omdat je tegen die tijd ook echte schijffouten kunt hebben dat vertroebelt de situatie. (Het is mogelijk dat dit probleem alleen invloed heeft op het verkleinen van de grootte van bestandssystemen - het is echter duidelijk dat het resizen van bestandssystemen in beide richtingen het risico van gegevensverlies vergroot, mogelijk als gevolg van gebruikersfouten.)
  • Het lijkt erop dat de LV-afmeting groter zou zijn dan de FS-afmeting met 2 x de LV-fysieke omvang (PE) -afmeting - maar controleer de bovenstaande link voor details aangezien de bron hiervoor niet bindend is. Vaak is 8 MiB voldoende, maar het kan beter zijn om meer, bijvoorbeeld 100 MiB of 1 GiB, alleen maar om veilig te zijn. Als u de PE-grootte en uw logische volume + FS-grootten wilt controleren, gebruikt u blokken van 4 KiB = 4096 byte:

    Toont de PE-maat in KiB:
    vgdisplay --units k myVGname | grep "PE Size"

    Grootte van alle LV's:
    lvs --units 4096b

    Grootte van (ext3) FS, veronderstelt 4 KiB FS-blokkering:
    tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

  • Daarentegen maakt een niet-LVM-configuratie het wijzigen van de FS zeer betrouwbaar en eenvoudig uit te voeren gparted en verander de grootte van de vereiste FS's, dan zal het alles voor je doen. Op servers kunt u gebruiken parted van de schaal.

    • Het is vaak het beste om het te gebruiken Gparted Live CD of Afgescheiden magie, omdat deze een recente en vaak meer bug-vrije Gparted & kernel hebben dan de distro-versie - ik verloor eens een hele FS omdat Gparted van distro partities niet goed in de werkende kernel bijwerkte. Als je de Gpeded van de distro gebruikt, zorg er dan voor dat je meteen herstart na het veranderen van partities, zodat de kernelweergave correct is.

Snapshots zijn moeilijk te gebruiken, traag en met fouten- als de snapshot de vooraf toegewezen ruimte opraakt, is dit het geval automatisch laten vallen. Elke momentopname van een bepaalde LV is een delta tegen die LV (niet tegen eerdere snapshots) die veel ruimte kan vergen bij het snapshotten van bestandssystemen met aanzienlijke schrijfactiviteit. Het is veilig om een ​​momentopname LV te maken die dezelfde grootte heeft als de originele LV, omdat de momentopname dan nooit de vrije ruimte zal hebben.

Snapshots kunnen ook erg traag zijn (dit betekent 3 tot 6 keer langzamer dan zonder LVM voor deze MySQL-tests) - zien dit antwoord voor verschillende snapshot-problemen. De traagheid is deels omdat snapshots vereisen veel synchrone schrijfbewerkingen.

Snapshots hebben enkele significante bugs, b.v. in sommige gevallen ze kunnen het opstarten erg langzaam maken, of ervoor zorgen dat het opstarten volledig mislukt (omdat het kernel kan time-out  wachten op de root FS als het een LVM-momentopname is [gerepareerd in Debian initramfs-tools update, maart 2015]).

  • Eén statistiek is dat er veel Debian-bugs zijn matching "lvm snapshot 2015", sommigen van hen heel serieus - echter, veel snapshot raceconditie bugs hebben blijkbaar opgelost. LVM zonder snapshots lijkt over het algemeen vrij goed te zijn debugged, misschien omdat snapshots niet zo vaak worden gebruikt als de kernfuncties.

Snapshot-alternatieven - bestandssystemen en VM-hypervisors

VM / cloud snapshots:

  • Als u een VM-hypervisor of een IaaS-cloudprovider gebruikt, zijn hun snapshots (bijvoorbeeld VMware, VirtualBox of EBI-snapshots van Amazon EC2) vaak een veel beter alternatief voor LVM-snapshots. Je kunt vrij eenvoudig een momentopname maken voor back-updoeleinden (maar overweeg het bevriezen van de FS voordat je dit doet).

Snapshots van het bestandssysteem:

  • momentopnamen op bestandssysteemniveau met ZFS of btrfs zijn eenvoudig te gebruiken en over het algemeen beter dan LVM, en hoewel geen van beide bestandssysteem erg volwassen is op Linux, kunnen ze een betere optie zijn voor mensen die echt snapshots nodig hebben zonder de VM / cloudroute te gebruiken:

    • ZFS: er is nu een kernel ZFS-implementatie, dat al enkele jaren in gebruik is en veel sneller zou moeten zijn dan ZFS op FUSE.
    • btrfs is nog niet helemaal klaar voor productiegebruik, en het is fsck en reparatie tools zijn nog in ontwikkeling.

Snapshots voor online back-ups en fsck

Snapshots kunnen worden gebruikt om consistent te zijn bron voor back-ups, zolang u voorzichtig bent met toegewezen ruimte (in het ideale geval is de momentopname even groot als de LV waarvan een back-up wordt gemaakt). Het uitstekende rsnapshot (sinds 1.3.1) beheert zelfs de LVM snapshot creatie / verwijdering voor jou - zie dit HOWTO op rsnapshot met LVM. Houd echter rekening met de algemene problemen met momentopnamen en dat een momentopname op zichzelf niet als een back-up moet worden beschouwd.

U kunt ook LVM snapshots gebruiken om een ​​online fsck te doen: snapshot de LV en fsck de snapshot, terwijl u nog steeds de belangrijkste non-snapshot FS gebruikt - hier beschreven - Het is echter niet helemaal duidelijk dus het is het beste om te gebruiken e2croncheck zoals beschreven door Ted Ts'o, onderhouder van ext3.

Je zou moeten "bevriezen" het bestandssysteem tijdelijk tijdens het maken van de snapshot - sommige bestandssystemen zoals ext3 en XFS zullen dat doen doe dit automatisch wanneer LVM de momentopname maakt.

conclusies

Ondanks dit alles gebruik ik nog steeds LVM op sommige systemen, maar voor een desktop-opstelling geef ik de voorkeur aan onbewerkte partities. Het belangrijkste voordeel dat ik van LVM kan zien, is de flexibiliteit om FS's te verplaatsen en van grootte te veranderen wanneer u een hoge uptime op een server moet hebben - als u dat niet nodig hebt, is gparted eenvoudiger en heeft het minder risico op gegevensverlies.

LVM vereist grote zorgvuldigheid bij het instellen van de schrijfcache door VM-hypervisors, schrijfcaching op de vaste schijf / SSD, enzovoort, maar hetzelfde geldt voor het gebruik van Linux als een DB-server. Het gebrek aan ondersteuning van de meeste tools (gparted inclusief de kritische grootteberekeningen, en testdisk enz.) maakt het moeilijker om te gebruiken dan zou moeten.

Als u LVM gebruikt, wees dan uiterst voorzichtig met momentopnamen: gebruik indien mogelijk VM / cloud snapshots of onderzoek ZFS / btrf's om LVM volledig te vermijden - u zult merken dat ZFS of btr's voldoende volgroeid zijn in vergelijking met LVM met snapshots.

Kort gezegd: als u niet op de hoogte bent van de hierboven genoemde problemen en hoe u deze kunt aanpakken, kunt u best LVM niet gebruiken.


238
2018-06-12 08:19



Online vergroten / verkleinen met xf's werkt perfect, je hoeft niet eens de maat te specificeren. Het zal naar de grootte van de LV groeien lees meer in xfs_grow (5). OTOH Ik raakte +1 voor de samenvatting over schrijfbarrières. - cstamas
KEREL! Waar ben je mijn hele leven al geweest? - songei2f
@TREE: het idee met een RAID-controller met batterijvoeding is dat de cache persistent is bij stroomstoringen en over het algemeen betrouwbaar is om te werken zoals gedocumenteerd, terwijl sommige caches op de harde schijf liegen over de vraag of ze een blok naar schijf hebben geschreven en Natuurlijk zijn deze caches niet persistent. Als u de cache van de harde schijf ingeschakeld laat, bent u kwetsbaar voor een plotselinge stroomstoring (bijvoorbeeld PSU of UPS mislukt), die wordt beschermd tegen de batterijback-up van de RAID-controller. - RichVel
Een van de beste antwoorden die ik ooit heb gezien, elk onderwerp. Alleen verandering die ik zou maken, zet samenvatting naar de TOP van de vraag voor mensen met een Attention Deficit Disorder of niet veel tijd. :-) - Prof. Falken
Toen ik een jaar geleden al de opmerkingen en de laatste update van het antwoord zag, vroeg ik me af of het antwoord kon worden bijgewerkt om rekening te houden met nieuwe wijzigingen in betrouwbaarheid, prestaties en gebruiksgemak. - Luis Alvarado


Ik [+1] die post, en in ieder geval voor mij denk ik dat de meeste problemen bestaan. Ze werden gezien tijdens het uitvoeren van een paar honderd servers en een paar honderdTB aan gegevens. Voor mij voelt de LVM2 in Linux aan als een "slim idee" dat iemand had. Zoals sommige hiervan blijken ze soms "niet slim" te zijn. D.w.z. niet strikt gescheiden kernel en userspace (lvmtab) staten hebben misschien heel slim gevoeld om het weg te doen, omdat er corruptieproblemen kunnen zijn (als je de code niet goed krijgt)

Nou, alleen dat deze scheiding er was voor een reden - de verschillen worden weergegeven met verwerking van PV-verlies en online heractiveren van een VG met bijvoorbeeld ontbrekende PV's om ze weer in het spel te brengen - Wat een koud kunstje is bij "originele LVM's" (AIX, HP-UX) verandert in rotzaligheid op LVM2 sinds de behandeling door de staat is niet goed genoeg. En laat me niet eens praten over Quorum-verliesherkenning (haha) of staatsbehandeling (als ik een schijf verwijder, wordt die niet gemarkeerd als niet beschikbaar. hebben de verdomde statuskolom)

Re: stabiliteit pvmove... waarom is

pvmove gegevensverlies

zo'n topartikel op mijn blog, hmmm? Op dit moment kijk ik naar een schijf waar de phyiscale lvm-gegevens nog steeds van de middenweg worden opgehangen. Er zijn wat memleaks denk ik, en het algemene idee dat het goed is om live-blokgegevens vanuit gebruikersruimte te kopiëren is gewoon triest. Leuk citaat uit de lvm-lijst "lijkt op vgreduce - vermist pvmove niet" Betekent eigenlijk dat als een schijf tijdens pvmove wordt losgemaakt, de lvm-beheertool van lvm in vi verandert. Oh en er is ook een fout opgetreden waarbij pvmove doorgaat na een blok lees / schrijffout en in feite geen gegevens meer naar het doelapparaat schrijft. WTF?

Re: Snapshots De CoW wordt onveilig uitgevoerd door de NIEUWE gegevens bij te werken in het momentopname-gebied en vervolgens weer samen te voegen zodra u de module verwijdert. Dit betekent dat je zware IO-pieken hebt tijdens de laatste samenvoeging van nieuwe gegevens in de originele LV en, veel belangrijker, je hebt natuurlijk ook een veel hoger risico op gegevensbeschadiging, omdat de momentopname niet wordt verbroken zodra je de muur, maar het origineel.

Het voordeel zit hem in de prestaties, het doen van 1 schrijft in plaats van 3. Het picken van het snelle maar onfatsoenlijke algoritme is iets dat je duidelijk van mensen als VMware en MS verwacht, op "Unix" zou ik liever raden dat dingen "goed zouden worden gedaan". Ik heb niet veel prestatieproblemen gezien, zolang ik de snapshot-ondersteuningswinkel op a heb verschillend disk drive dan de primaire data (en back-up naar nog een andere natuurlijk)

Re: Belemmeringen Ik weet niet zeker of dat de schuld is van LVM. Het was een devmapper kwestie, voor zover ik weet. Maar er kan enige schuld zijn voor het niet echt geven om dit probleem van tenminste kernel 2.6 tot 2.6.33 AFAIK Xen is de enige hypervisor die O_DIRECT gebruikt voor de virtuele machines, het probleem was vroeger toen "loop" werd gebruikt omdat de kernel dat nog zou cachen. Virtualbox heeft tenminste een instelling om dit soort dingen uit te schakelen en Qemu / KVM lijkt over het algemeen caching toe te staan. Alle FUSE FS hebben daar ook problemen (geen O_DIRECT)

Re: Maten Ik denk dat LVM het weergegeven formaat "afrondt". Of het maakt gebruik van GiB. Hoe dan ook, je moet de VG Pe-maat gebruiken en het vermenigvuldigen met het LE-nummer van de LV. Dat zou de juiste netgrootte moeten geven, en dat probleem is altijd een gebruikskwestie. Het wordt verergerd door bestandssystemen die zoiets niet opmerken tijdens fsck / mount (hallo, ext3) of die geen werkende online hebben "fsck -n" (hallo, ext3)

Natuurlijk zegt het dat je geen goede bronnen voor dergelijke info kunt vinden. "hoeveel LE voor de VRA?" "wat is de phyiscal-offset voor PVRA, VGDA, ... enz."

Vergeleken met het origineel is LVM2 het beste voorbeeld van "Degenen die UNIX niet begrijpen, zijn veroordeeld om het opnieuw uit te vinden, slecht".

Update een paar maanden later: ik heb nu het "volledige snapshot" -scenario voor een test bereikt. Als ze vol raken, blokkeert de snapshot, niet de originele LV. Ik had het mis toen ik dit voor het eerst had gepost. Ik heb verkeerde informatie van een of andere doc opgepikt, of misschien had ik het begrepen. In mijn setups was ik altijd erg paranoïde geweest om ze niet te laten vollopen en dus ben ik nooit gecorrigeerd. Het is ook mogelijk om snapshots uit te breiden / te verkleinen, wat een feest is.

Wat ik nog steeds niet heb kunnen oplossen, is hoe ik de leeftijd van een momentopname kan identificeren. Wat hun uitvoering betreft, staat er een opmerking op de Fedora-projectpagina "thinp", waarin staat dat de snapshot-techniek wordt herzien, zodat ze niet langzamer worden bij elke momentopname. Ik weet niet hoe ze het implementeren.


15
2017-12-11 14:03



Goede punten, vooral met betrekking tot het verlies van de pvmove-gegevens (realiseerden niet dat dit kon crashen bij een laag geheugen) en snapshot-ontwerp. Over schrijfbarrières / caching: ik verwende LVM en de mappler van de kernel-apparaten omdat ze vanuit het oogpunt van de gebruiker samenwerken om te leveren wat LVM biedt. Upvoted. Vond ook uw blogposting leuk op pvmove dataverlies: deranfangvomende.wordpress.com/2009/12/28/... - RichVel
Over snapshots: ze zijn notoir traag in LVM, dus het was duidelijk geen goede ontwerpbeslissing om te kiezen voor prestaties ten opzichte van betrouwbaarheid. Met 'de muur inslaan', bedoelde u dat de momentopname opviel en kan dit echt de corruptie van de originele LV-gegevens veroorzaken? De LVM HOWTO zegt dat de snapshot in dit geval is weggelaten: tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html - RichVel
"De CoW wordt onveilig uitgevoerd door de NIEUWE gegevens bij te werken in het momentopname-gedeelte van lv en vervolgens weer samen te voegen zodra u de module verwijdert." Dit is gewoon fout. Wanneer nieuwe gegevens naar het oorspronkelijke apparaat worden geschreven, wordt de oud versie wordt geschreven in het COW-gebied met snapshots. Er worden nooit gegevens teruggevoegd (behalve als u dat wilt). Zien kernel.org/doc/Documentation/device-mapper/snapshot.txt voor alle bloederige technische details. - Damien Tournoud
Hallo Damien, de volgende keer net doorlezen tot het punt waarop ik mijn bericht heb gecorrigeerd? - Florian Heigl


als u van plan bent snapshots voor back-ups te gebruiken - wees voorbereid op grote prestatieshits wanneer momentopname aanwezig is. Lees verder hier. anders is het allemaal goed. ik gebruik lvm al enkele jaren in productie op tientallen servers, hoewel mijn belangrijkste reden om het te gebruiken de atomaire snapshot is, en niet de mogelijkheid om volumes eenvoudig uit te breiden.

trouwens, als je 1TB-schijf gaat gebruiken, onthoud dan de uitlijning van de partitie - deze schijf heeft hoogstwaarschijnlijk 4kB fysieke sectoren.


12
2018-06-12 09:44



+1 voor uitvoeringswaarschuwing voor open momentopnamen. - Prof. Falken
mijn ervaring is dat 1TB-schijven meestal 512 byte sectoren gebruiken, maar de meeste 2TB-drives gebruiken 4Kb. - Dan Pritts
@DanPritts er is geen kwaad om aan te nemen dat de sectorgrootte 4 kB of zelfs 128 kB is - voor het geval dat er tussendoor raid wordt. je verliest zo weinig - misschien dat 128 kB en je kunt veel winnen. ook bij het weergeven van de oude schijf naar een nieuwe schijf. - pQd
Er is een klein nadeel aan het "te groot" maken van de grootte van het bestandssysteem; elk bestand is opgenomen in niet minder dan een enkel blok. Als je veel kleine bestanden en 128 KB blokken hebt, zal het oplopen. Ik ben het er echter mee eens dat 4K redelijk is, en als je een bestandssysteem naar nieuwe hardware verplaatst, zul je uiteindelijk uiteindelijk uitkomen op 4k-sectoren. - Dan Pritts
(laat me mijn vorige opmerking niet bewerken) ... Een verspilling van ruimte maakt misschien niet uit, maar het zal uiteindelijk resulteren in het verhogen van je gemiddelde zoektijd op draaiende schijven. Het kan mogelijk worden omgezet in schrijfamplificatie (het invullen van de sector met nullen) op SSD's. - Dan Pritts


Adam,

Nog een voordeel: u kunt een nieuw fysiek volume (PV) toevoegen, alle gegevens naar die PV verplaatsen en vervolgens de oude PV verwijderen zonder onderbrekingen van de service. Ik heb die mogelijkheid in de afgelopen vijf jaar minstens vier keer gebruikt.

Een nadeel dat ik nog niet duidelijk heb gezien: er is een enigszins steile leercurve voor LVM2. Meestal in de abstractie maakt het tussen uw bestanden en de onderliggende media. Als je met slechts een paar mensen werkt die klusjes op een aantal servers delen, vind je de extra complexiteit misschien overweldigend voor je team als geheel. Grotere teams die zich toeleggen op het IT-werk zullen over het algemeen niet zo'n probleem hebben.

We gebruiken het bijvoorbeeld hier veel op mijn werk en hebben de tijd genomen om het hele team de basics, de taal en de essentiële benodigdheden te leren over het herstellen van systemen die niet correct opstarten.

Eén waarschuwing is specifiek om erop te wijzen: als je opstart van een LVM2 logisch volume, heb je hersteloperaties moeilijk gevonden wanneer de server crasht. Knoppix en vrienden hebben daar niet altijd de juiste dingen voor over. Dus besloten we dat onze / boot directory op zijn eigen partitie zou staan ​​en altijd klein en native zou zijn.

Over het algemeen ben ik een fan van LVM2.


5
2018-06-22 21:03



bewaring /boot scheiden is altijd een goed idee - Hubert Kario
GRUB2 ondersteunt het opstarten vanuit een logisch LVM-volume (zie wiki.archlinux.org/index.php/GRUB2#LVM) maar GRUB1 doet dat niet. Ik zou altijd een aparte non-LVM / boot gebruiken om ervoor te zorgen dat deze gemakkelijk te herstellen is. De meeste reddingsschijven ondersteunen tegenwoordig LVM - sommige vereisen een handleiding vgchange -ayom de LVM-volumes te vinden. - RichVel
op pvmove: zie het punt over pvmove dataverlies gemaakt in Florian Heigl's antwoord. - RichVel