Logical Volume Manager (Linux) - Logical Volume Manager (Linux)

Správce logických svazků
Původní autořiHeinz Mauelshagen[1]
Stabilní uvolnění
2.03.07 / listopad 2019; před 1 rokem (2019-11)[2]
Úložištězdrojový software.org/ git/? p = lvm2.git
NapsánoC
Operační systémLinux, Netbsd
LicenceGPLv2
webová stránkaZdroje.červená čepice.com/ lvm2/

v Linux, Správce logických svazků (LVM) je mapovač zařízení rámec, který poskytuje logická správa svazků pro Linuxové jádro. Nejmodernější Linuxové distribuce jsou si vědomi LVM do té míry, že mohou mít své kořenové souborové systémy na logický svazek.[3][4][5]

Heinz Mauelshagen napsal původní kód LVM v roce 1998, kdy pracoval v Software Sistina, přičemž převezme jeho hlavní směry návrhu z HP-UX správce svazků.[1]

Použití

LVM se používá k následujícím účelům:

  • Vytváření singlu logické svazky několika fyzických svazků nebo celých pevných disků (něco podobného jako RAID 0, ale více podobné JBOD ), což umožňuje dynamickou změnu velikosti svazku.
  • Správa velkých farem pevných disků umožněním přidání a nahrazení disků bez výpadků nebo narušení služeb v kombinaci s hot swapování.
  • Na malých systémech (například na ploše) LVM místo toho, aby v době instalace musel odhadovat, jak velký oddíl může být potřeba, umožňuje LVM snadno měnit velikost souborových systémů podle potřeby.
  • Provádění konzistentních záloh pomocí pořizování snímků logických svazků.
  • Šifrování více fyzických oddílů pomocí jednoho hesla.

LVM lze považovat za tenkou softwarovou vrstvu nad pevnými disky a diskovými oddíly, která vytváří abstrakci kontinuity a snadného použití pro správu výměny pevného disku, jeho opětovného rozdělení a zálohování.

Funkce

Různé prvky LVM

Základní funkce

  • Skupiny svazků (VG) lze změnit online absorbováním nových fyzické objemy (PV) nebo vysunutí stávajících.
  • Logické svazky (LV) lze změnit online zřetězením rozsahy na ně nebo zkrácení jejich rozsahu.
  • NN lze přesouvat mezi PV.
  • Vytvoření pouze pro čtení snímky logických svazků (LVM1) s využitím funkce kopírování při zápisu (CoW)[6]nebo snímky pro čtení / zápis (LVM2)
  • VG lze rozdělit nebo sloučit in situ tak dlouho, dokud žádné LV nedosáhnou rozdělení. To může být užitečné při migraci celých LV do nebo z offline úložiště.
  • Objekty LVM lze označit pro usnadnění správy.[7]
  • VG a LV lze aktivovat, jakmile budou podkladová zařízení dostupná prostřednictvím používání lvmetad démon.[8]

Pokročilé funkce

  • Hybridní svazky lze vytvořit pomocí dm-cache cíl, který umožňuje jednomu nebo více rychlým úložným zařízením, například flashovým SSD, působit jako mezipaměti pro jednu nebo více pomalejší pevné disky.[9]
  • Tenko zřízené LV lze přidělit z fondu.[10]
  • Na novějších verzích mapovač zařízení, LVM je integrován se zbytkem mapovače zařízení natolik, aby ignoroval jednotlivé cesty, které podporují zařízení dm-multipath, pokud devices / multipath_component_detection = 1 je zasazen lvm.conf. To zabrání LVM v aktivaci svazků na jednotlivé cestě namísto vícecestného zařízení.[11]

NÁLET

  • LV lze vytvořit za účelem zahrnutí NÁLET funkčnost, včetně RAID 1, 5 a 6.[12]
  • Celé LV nebo jejich části mohou být pruhovány přes více FV, podobně jako RAID 0.
  • Backendové zařízení RAID 1 (PV) lze konfigurovat jako „většinou pro zápis“, což má za následek zabránění čtení, pokud to není nutné.[13]
  • Míru obnovy lze omezit pomocí lvchange --raidmaxrecoveryrate a lvchange --raidminrecoveryrate k udržení přijatelného výkonu I / O při opětovném sestavení LV, která zahrnuje funkce RAID.

Vysoká dostupnost

LVM funguje také ve sdíleném úložišti shluk ve kterém jsou disky, které drží PV, sdíleny mezi více hostitelskými počítači, ale mohou vyžadovat dalšího démona, který zprostředkuje přístup k metadatům prostřednictvím formy uzamčení.

CLVM
A správce distribuovaného zámku se používá ke zprostředkování souběžných přístupů metadat LVM. Kdykoli uzel clusteru potřebuje upravit metadata LVM, musí zabezpečit povolení od svého místního clvmd, který je v neustálém kontaktu s ostatními clvmd démoni v klastru a mohou komunikovat touhu získat zámek na konkrétní sadě objektů.
HA-LVM
Clusterové povědomí je ponecháno na aplikaci poskytující funkci vysoké dostupnosti. Pokud jde o část LVM, může HA-LVM použít CLVM jako uzamykací mechanismus, nebo může pokračovat v používání výchozího zamykání souborů a omezit „kolize“ omezením přístupu pouze na ty objekty LVM, které mají příslušné značky. Jelikož se toto jednodušší řešení vyhýbá sporu, než aby ho zmírňovalo, nejsou povoleny žádné souběžné přístupy, takže HA-LVM je považován za užitečný pouze v aktivně-pasivních konfiguracích.
lvmlockd
Od roku 2017, stabilní komponenta LVM, která je navržena jako náhrada clvmd tím, že uzamčení objektů LVM bude transparentní vůči zbytku LVM, aniž by se spoléhalo na správce distribuovaného zámku.[14] Během roku 2016 došlo k masivnímu rozvoji.[15]

Výše popsané mechanismy řeší pouze problémy s přístupem LVM k úložišti. Souborový systém vybraný tak, aby byl nad těmito LV, musí buď podporovat klastrování sám o sobě (například GFS2 nebo VxFS ) nebo jej musí kdykoli připojit pouze jeden uzel clusteru (například v aktivně-pasivní konfiguraci).

Zásady přidělování skupin svazků

LVM VGs musí obsahovat výchozí politiku alokace pro nové svazky z ní vytvořené. Toto lze později změnit pro každý LV pomocí lvconvert -A velení nebo na samotném VG pomocí vgchange --alloc. Aby se minimalizovala fragmentace, pokusí se LVM nejdříve o nejpřísnější politiku (souvislou) a poté bude postupovat směrem k nejliberálnější politice definované pro objekt LVM, dokud nebude alokace nakonec úspěšná.

V konfiguracích RAID jsou téměř všechny zásady použity na každou nohu samostatně. Například i když má LV politiku lpět, rozšíření souborového systému nebude mít za následek, že LVM použije PV, pokud je již používán jednou z dalších částí v nastavení RAID. LV s funkcí RAID umístí každou nohu na různé PV, takže ostatní PV nebudou dostupné pro žádnou jinou danou nohu. Pokud by to byla jediná dostupná možnost, rozšíření LV by selhalo. V tomto smyslu logika pozadí lpět bude platit pouze pro rozšíření každé z jednotlivých částí pole.

Dostupné zásady alokace jsou:

  • Souvislé - nutí všechny LE v daném LV sousedit a objednat. To eliminuje fragmentaci, ale výrazně snižuje rozšiřitelnost LV.
  • Lpět - vynutí přidělení nových LE pouze na PV, které již LV používá. To může pomoci zmírnit fragmentaci a snížit zranitelnost konkrétních LV v případě, že zařízení spadne, a to snížením pravděpodobnosti, že i jiné LV budou mít na daném FV rozsah.
  • Normální - znamená téměř nevybíravý výběr PE, ale pokusí se zabránit paralelním nohám (jako jsou například nastavení RAID) ve sdílení fyzického zařízení.
  • Kdekoli - neukládá žádná omezení. Vysoce riskantní v nastavení RAID, protože ignoruje požadavky na izolaci a podkopává většinu výhod RAID. U lineárních objemů to může vést ke zvýšené fragmentaci.

Implementace

Základní příklad hlavy LVM
Vnitřní fungování verze 1 LVM. V tomto diagramu znamená PE fyzický rozsah.

První megabajt každého fyzického svazku obvykle obsahuje většinou ASCII -kódovaná struktura označovaná jako „záhlaví LVM“ nebo „hlava LVM“. Původně byla hlava LVM pro redundanci zapisována do prvního a posledního megabajtu každého PV; v případě částečného selhání hardwaru; toto však bylo později změněno pouze na první megabajt. Záhlaví každého PV je úplnou kopií rozložení celé skupiny svazků, včetně UUID všech ostatních PV a LV a mapy přidělení PE na LE. To zjednodušuje obnovu dat, pokud dojde ke ztrátě PV.

V řadě 2.6 jádra Linuxu je LVM implementován ve smyslu mapovač zařízení, jednoduché schéma na úrovni bloků pro vytváření virtuálních blokových zařízení a mapování jejich obsahu na další bloková zařízení. To minimalizuje množství relativně těžko laditelného kódu jádra potřebného k implementaci LVM. Umožňuje také sdílení jeho služeb přesměrování I / O s dalšími správci svazků (například EVMS ). Libovolný kód specifický pro LVM je vložen do jeho nástrojů uživatelského prostoru, které pouze manipulují s těmito mapováními a rekonstruují jejich stav z metadat na disku při každém vyvolání.

Chcete-li uvést skupinu svazků online, použijte nástroj „vgchange“:

  1. Vyhledá PV ve všech dostupných blokových zařízeních.
  2. Analyzuje hlavičku metadat v každém nalezeném PV.
  3. Vypočítá rozložení všech viditelných skupin svazků.
  4. Smyčky přes každý logický svazek ve skupině svazků, které mají být uvedeny online, a:
    1. Zkontroluje, zda logický svazek, který má být uveden do režimu online, má viditelné všechny jeho PV.
    2. Vytvoří nové, prázdné mapování zařízení.
    3. Mapuje jej (s „lineárním“ cílem) na datové oblasti PV, ke kterým logický svazek patří.

Chcete-li přesunout online logický svazek mezi PV ve stejné skupině svazků, použijte nástroj „pvmove“:

  1. Vytvoří nové, prázdné mapování zařízení pro cíl.
  2. Aplikuje cíl „zrcadlení“ na původní a cílové mapy. Jádro spustí zrcadlo v „degradovaném“ režimu a začne kopírovat data z originálu do cíle, aby se synchronizovala.
  3. Nahradí původní mapování cílem, když se zrcadlo synchronizuje, poté zničí originál.

Tyto operace mapovače zařízení probíhají transparentně, aniž by si aplikace nebo souborové systémy byly vědomy toho, že se jejich základní úložiště pohybuje.

Upozornění

  • Až do linuxového jádra 2.6.31,[16] psát bariéry nebyly podporovány (plně podporovány v 2.6.33). To znamená, že záruku proti poškození souborového systému nabízí žurnálované souborové systémy jako ext3 a XFS byla za určitých okolností vyvrácena.[17]
  • Od roku 2015, pro LVM neexistuje žádný online ani offline defragmentační program. To je poněkud zmírněno fragmentací, ke které dochází pouze v případě, že je svazek rozšířen, a uplatněním výše uvedených zásad přidělování. K fragmentaci však stále dochází, a pokud má být omezena, musí být identifikovány nesouvislé oblasti a ručně přeskupeny pomocí pvmove příkaz.[18]
  • Ve většině instalací LVM je do každého PV uložena pouze jedna kopie hlavy LVM, což může zvýšit náchylnost svazků k neúspěšným sektorům disku. Toto chování lze přepsat pomocí vgconvert --pvmetadatacopies. Pokud LVM pomocí první kopie nedokáže přečíst správné záhlaví, zkontroluje na konci svazku záložní záhlaví. Většina linuxových distribucí udržuje běžící zálohu / etc / lvm / backup, který umožňuje ruční přepisování poškozené hlavy LVM pomocí vgcfgrestore příkaz.

Viz také

Reference

  1. ^ A b „LVM README“. 2003-11-17. Citováno 2014-06-25.
  2. ^ Kergon, Alasdair (03.11.2017). „[lvm-devel] v2_02_176 anotovaná značka byla vytvořena“. lvm-devel. červená čepice. Citováno 2017-11-03.
  3. ^ „7.1.2 Konfigurace LVM pomocí YaST“. SUSE. 12. července 2011. Archivovány od originál dne 25. července 2015. Citováno 2015-05-22.
  4. ^ „HowTo: Set Ubuntu Desktop with LVM Partitions“. Ubuntu. 1. června 2014. Archivovány od originál dne 4. března 2016. Citováno 2015-05-22.
  5. ^ „9.15.4 Vytvořit logický svazek LVM“. Červená čepice. 8. října 2014. Citováno 2015-05-22.
  6. ^ https://blog.pythian.com/btrfs-performance-compared-lvmext4-regards-database-workloads/
  7. ^ "Označování objektů úložiště LVM2". Micro Focus International. Citováno 21. května 2015.
  8. ^ „Démon metadat“. Red Hat Inc.. Citováno 22. května 2015.
  9. ^ „Používání nové funkce mezipaměti LVM“. Citováno 2014-07-11.
  10. ^ „2.3.5. Tenkostěnné logické svazky (tenké svazky)“. Access.redhat.com. Citováno 2014-06-20.
  11. ^ "4.101.3. RHBA-2012: 0161 - oprava a vylepšení chyby lvm2". Citováno 2014-06-08.
  12. ^ „5.4.16. Logické svazky RAID“. Access.redhat.com. Citováno 2017-02-07.
  13. ^ "Řízení I / O operací na logickém svazku RAID1". redhat.com. Citováno 16. června 2014.
  14. ^ „Re: LVM snapshot with Clustered VG [SOLVED]“. 15. března 2013. Citováno 2015-06-08.
  15. ^ https://sourceware.org/git/?p=lvm2.git;a=history;f=lib/locking/lvmlockd.c;h=master;hb=HEAD
  16. ^ „Chyba 9554 - bariéry zápisu přes mapovač zařízení nejsou podporovány“. 2009-07-01. Citováno 2010-01-24.
  17. ^ „Bariéry a žurnálovací souborové systémy“. LWN. 2008-05-22. Citováno 2008-05-28.
  18. ^ "bude pvmove'ing (LV najednou) defragmentovat?". 2010-04-29. Citováno 2015-05-22.
  19. ^ Gotchas, btrfs Wiki, vyvoláno 2017-04-24

Další čtení