Niebezpieczeństwa i zastrzeżenia LVM

Ostatnio zacząłem używać LVM na niektórych serwerach dla dysków twardych większych niż 1 TB. Są przydatne, rozszerzalne i dość łatwe w instalacji. Nie mogłem jednak znaleźć żadnych danych na temat zagrożeń i zastrzeżeń związanych z LVM.

Jakie są wady korzystania z LVM?

Podsumowanie

Ryzyko związane z używaniem LVM:

• Podatne na pisanie problemów z buforowaniem za pomocą SSD lub hypervisor VM
• Trudniej jest odzyskać dane z powodu bardziej złożonych struktur na dysku
• Trudniej poprawnie zmienić rozmiar systemów plików
• Migawki są trudne w użyciu, powolne i zawierają błędy
• Wymaga pewnych umiejętności, aby poprawnie skonfigurować ze względu na te problemy

Dwa pierwsze problemy LVM łączą się: jeśli buforowanie zapisu nie działa poprawnie i występuje utrata zasilania (np. Awaria zasilacza lub zasilacza UPS), być może trzeba będzie zregenerować dane po wykonaniu kopii zapasowej, co oznacza znaczne przestoje. Kluczowym powodem korzystania z LVM jest dłuższy czas pracy (podczas dodawania dysków, zmiany rozmiaru systemów plików itp.), Ale ważne jest, aby ustawić poprawną konfigurację buforowania zapisu, aby uniknąć faktycznego skrócenia czasu pracy LVM.

- Zaktualizowano grudzień 2018: zaktualizowano materiał migawki, w tym stabilność ZFS i btrfs jako alternatywy dla migawek LVM

Łagodzenie ryzyka

LVM może nadal działać dobrze, jeśli:

• Uzyskaj konfigurację buforowania zapisu bezpośrednio w hiperwizorze, jądrze i dyskach SSD
• Unikaj migawek LVM
• Użyj najnowszych wersji LVM, aby zmienić rozmiar systemów plików
• Miej dobre kopie zapasowe

Detale

W przeszłości badałem to dość często, ponieważ doświadczyłem utraty danych związanej z LVM. Główne ryzyka i problemy związane z LVM, o których wiem, to:

Podatne na buforowanie zapisu na dysku twardym ze względu na hiperwizory VM, buforowanie dysku lub stare jądra Linuksa i utrudniają odzyskiwanie danych z powodu bardziej złożonych struktur na dysku - szczegółowe informacje znajdują się poniżej. Widziałem, że kompletne konfiguracje LVM na kilku dyskach ulegają uszkodzeniu bez szansy na odzyskanie, a buforowanie zapisu LVM i dysku twardego jest niebezpieczną kombinacją.

• Buforowanie i zmiana kolejności zapisu na dysku twardym jest ważna dla dobrej wydajności, ale może nie powieść poprawnie bloków na dysku ze względu na hiperwizory VM, buforowanie zapisu na dysku twardym, stare jądra Linuksa itp.
  • Bariery zapisu oznaczają, że jądro gwarantuje, że dokończy zapis niektórych dysków przed zapisem dysku „barierowym”, aby zapewnić odzyskanie systemów plików i RAID w przypadku nagłej utraty zasilania lub awarii. Takie bariery mogą korzystać z operacji FUA (Force Unit Access), aby natychmiast zapisać określone bloki na dysku, co jest bardziej wydajne niż pełne opróżnianie pamięci podręcznej. Bariery można łączyć z wydajnym kolejkowaniem oznaczonych / natywnych poleceń (wysyłanie wielu żądań We / Wy dysku jednocześnie), aby umożliwić dyskowi inteligentnemu ponowne uporządkowanie zapisu bez zwiększania ryzyka utraty danych.
• Hiperwizory VM mogą mieć podobne problemy: uruchamianie LVM w gościu Linux na hiperwizorze VM, takim jak VMware, Xen , KVM, Hyper-V lub VirtualBox, może powodować podobne problemy do jądra bez barier zapisu, z powodu buforowania zapisu i ponownego zapisu zamówienie Dokładnie sprawdź dokumentację hiperwizora pod kątem opcji „opróżnij dysk” lub zapisz pamięć podręczną (obecną w KVM , VMware , Xen , VirtualBox i innych) - i przetestuj ją w konfiguracji. Niektóre hiperwizory, takie jak VirtualBox, mają ustawienie domyślne, które ignoruje wszelkie opróżnienia dysku z gościa.
• Serwery korporacyjne z LVM powinny zawsze korzystać z kontrolera RAID z podtrzymaniem bateryjnym i wyłączać buforowanie zapisu na dysku twardym (kontroler ma bufor zapisu z podtrzymaniem bateryjnym, który jest szybki i bezpieczny) - patrz ten komentarz autora tego wpisu FAQ XFS . Wyłączenie barier zapisu w jądrze może być również bezpieczne , ale zalecane jest przetestowanie.
• Jeśli nie masz kontrolera RAID zasilanego bateryjnie, wyłączenie buforowania zapisu na dysku twardym znacznie spowolni zapis, ale zapewni bezpieczeństwo LVM. Powinieneś także użyć odpowiednika data=orderedopcji ext3 (lub data=journaldla dodatkowego bezpieczeństwa), a także, barrier=1aby upewnić się, że buforowanie jądra nie wpływa na integralność. (Lub użyj ext4, który domyślnie włącza bariery .) Jest to najprostsza opcja i zapewnia dobrą integralność danych kosztem wydajności. (Linux zmienił domyślną opcję ext3 na bardziej niebezpieczną data=writebackjakiś czas temu, więc nie polegaj na domyślnych ustawieniach FS.)
• Aby wyłączyć buforowanie zapisu na dysku twardym : dodaj hdparm -q -W0 /dev/sdXdla wszystkich dysków w /etc/rc.local(dla SATA) lub użyj sdparm dla SCSI / SAS. Jednak zgodnie z tym wpisem w często zadawanych pytaniach dotyczących systemu plików XFS (co jest bardzo dobre w tym temacie) dysk SATA może zapomnieć o tym ustawieniu po odzyskaniu błędu dysku - więc powinieneś użyć SCSI / SAS lub jeśli musisz użyć SATA, to umieść Komenda hdparm w zadaniu cron uruchamianym co około minutę.
• Aby zachować buforowanie zapisu SSD / dysku twardego w celu zwiększenia wydajności: jest to złożony obszar - patrz sekcja poniżej.
• Jeśli używasz dysków Advanced Format, tj. Sektorów fizycznych o wielkości 4 KB, zobacz poniżej - wyłączenie buforowania zapisu może mieć inne problemy.
• UPS ma krytyczne znaczenie zarówno dla przedsiębiorstw, jak i dla SOHO, ale nie wystarcza do zapewnienia bezpieczeństwa LVM: wszystko, co powoduje poważną awarię lub utratę zasilania (np. Awaria UPS, awaria zasilacza lub wyczerpanie baterii laptopa) może utracić dane w pamięci podręcznej dysku twardego.
• Bardzo stare jądra Linuksa (2.6.x od 2009 r.) : Obsługa niepełnej bariery zapisu w bardzo starych wersjach jądra 2.6.32 i wcześniejszych ( 2.6.31 ma pewne wsparcie , a 2.6.33 działa dla wszystkich typów urządzeń docelowych) - RHEL 6 używa 2.6.32 z wieloma łatkami. Jeśli te stare jądra 2.6 nie zostaną załadowane z powodu tych problemów, duża ilość metadanych FS (w tym czasopism) może zostać utracona w wyniku awarii, która pozostawia dane w buforach zapisu dysków twardych (powiedzmy 32 MB na dysk dla popularnych dysków SATA). Utrata 32 MB ostatnio zapisanych metadanych FS i danych z dziennika, które zdaniem jądra znajduje się już na dysku, zwykle oznacza wiele uszkodzeń FS, a tym samym utraty danych.
• Podsumowanie: musisz zadbać o system plików, RAID, hypervisor VM i konfigurację dysku twardego / SSD używaną z LVM. Jeśli używasz LVM, musisz mieć bardzo dobre kopie zapasowe i pamiętaj, aby dokładnie wykonać kopię zapasową metadanych LVM, konfiguracji partycji fizycznej, MBR i sektorów rozruchowych woluminu. Wskazane jest również używanie napędów SCSI / SAS, ponieważ rzadziej kłamią one na temat tego, jak robią buforowanie zapisu - wymaga większej ostrożności przy korzystaniu z napędów SATA.

Włączanie buforowania zapisu w celu zwiększenia wydajności (i radzenia sobie z leżącymi dyskami)

Bardziej złożoną, ale wydajniejszą opcją jest włączenie buforowania zapisu SSD / dysku twardego i poleganie na barierach zapisu jądra pracujących z LVM na jądrze 2.6.33+ (sprawdź dwukrotnie, szukając komunikatów „barier” w logach).

Powinieneś także upewnić się, że konfiguracja RAID, konfiguracja hiperwizora VM i system plików używają barier zapisu (tj. Wymaga, aby dysk wyczyścił oczekujące zapisy przed i po zapisaniu kluczowych metadanych / dziennika). XFS domyślnie używa barier, ale ext3 nie , więc z ext3 powinieneś używać barrier=1opcji montowania i nadal używać data=orderedlub data=journaljak wyżej.

• Niestety niektóre dyski twarde i dyski SSD kłamią na temat tego, czy naprawdę opróżniły pamięć podręczną na dysk (szczególnie dyski starsze, ale w tym niektóre dyski SATA i niektóre dyski SSD dla przedsiębiorstw ) - więcej szczegółów tutaj . Istnieje świetne podsumowanie od programisty XFS .
• Istnieje proste narzędzie do testowania leżących dysków (skrypt Perla) lub zobacz to tło w innym narzędziu testującym kolejność zapisu w wyniku pamięci podręcznej dysku. Ta odpowiedź obejmowała podobne testy dysków SATA, które ujawniły problem z barierą zapisu w programowej macierzy RAID - testy te faktycznie wykorzystują cały stos pamięci.
• Nowsze dyski SATA obsługujące Native Command Queuing (NCQ) mogą rzadziej kłamać - lub być może działają dobrze bez buforowania zapisu z powodu NCQ, a bardzo niewiele dysków nie może wyłączyć buforowania zapisu.
• Dyski SCSI / SAS są ogólnie OK, ponieważ nie wymagają buforowania zapisu, aby zapewnić dobrą wydajność (poprzez kolejkowanie poleceń z tagami SCSI , podobnie jak NCQ SATA).
• Jeśli dyski twarde lub dyski SSD kłamią na temat opróżniania pamięci podręcznej na dysk, naprawdę nie możesz polegać na barierach zapisu i musisz wyłączyć buforowanie zapisu. Jest to problem dla wszystkich systemów plików, baz danych, menedżerów woluminów i programowej macierzy RAID , nie tylko LVM.

Dyski SSD są problematyczne, ponieważ użycie pamięci podręcznej zapisu ma kluczowe znaczenie dla żywotności dysku SSD. Najlepiej jest użyć dysku SSD, który ma superkondensator (aby umożliwić opróżnianie pamięci podręcznej w przypadku awarii zasilania, a tym samym umożliwić buforowaniu zapisywanie z powrotem, a nie zapisywanie).

• Większość korporacyjnych dysków SSD powinna działać poprawnie przy kontroli pamięci podręcznej zapisu, a niektóre zawierają superkondensatory.
• Niektóre tańsze dyski SSD mają problemy, których nie można naprawić przy konfiguracji pamięci podręcznej zapisu - lista mailingowa projektu PostgreSQL i strona wiki Reliable Writes są dobrym źródłem informacji. Dyski SSD dla konsumentów mogą mieć poważne problemy z buforowaniem zapisu , które spowodują utratę danych, i nie obejmują superkondensatorów, więc są podatne na awarie zasilania powodujące uszkodzenie.

Zaawansowana konfiguracja napędu - buforowanie zapisu, wyrównanie, RAID, GPT

• W przypadku nowszych dysków Advanced Format korzystających z 4 sektorów fizycznych KiB może być ważne, aby zachować buforowanie zapisu na dysku, ponieważ większość takich dysków obecnie emuluje sektory logiczne 512 bajtów ( „emulacja 512” ), a niektóre nawet twierdzą, że mają 512-bajtową pamięć fizyczną sektory, podczas gdy naprawdę używają 4 KiB.
• Wyłączenie pamięci podręcznej zapisu napędu w formacie zaawansowanym może mieć bardzo duży wpływ na wydajność, jeśli aplikacja / jądro zapisuje 512 bajtów, ponieważ takie dyski polegają na pamięci podręcznej, aby zgromadzić 8 x 512 bajtów zapisu przed wykonaniem pojedynczego fizycznego zapisu 4 KiB pisać. Zaleca się przetestowanie w celu potwierdzenia wpływu, jeśli wyłączysz pamięć podręczną.
• Wyrównanie LV na granicy 4 KiB jest ważne dla wydajności, ale powinno się to odbywać automatycznie, o ile podstawowe partycje dla PV są wyrównane, ponieważ zakresy fizyczne LVM (PE) są domyślnie 4 MiB. RAID należy wziąć pod uwagę tutaj - ta strona konfiguracji LVM i oprogramowania RAID sugeruje umieszczenie superbloku RAID na końcu wolumenu i (w razie potrzeby) użycie opcji włączenia, pvcreateaby wyrównać PV. Ten wątek listy e-mail LVM wskazuje na pracę wykonaną w jądrach w 2011 r. I problem z częściowymi zapisami blokowymi podczas mieszania dysków z 512 bajtami i 4 sektorami KiB w jednym LV.
• Partycjonowanie GPT za pomocą Advanced Format wymaga szczególnej uwagi, szczególnie w przypadku dysków rozruchowych + root, aby pierwsza partycja LVM (PV) zaczęła się na granicy 4 KiB.

Trudniejsze do odzyskania dane z powodu bardziej złożonych struktur na dysku :

• Wszelkie odzyskiwanie danych LVM wymagane po awarii lub utracie zasilania (z powodu nieprawidłowego buforowania zapisu) jest w najlepszym przypadku procesem ręcznym, ponieważ najwyraźniej nie ma odpowiednich narzędzi. LVM jest dobry w tworzeniu kopii zapasowych swoich metadanych /etc/lvm, co może pomóc przywrócić podstawową strukturę LV, VG i PV, ale nie pomoże w utraconych metadanych systemu plików.
• Dlatego prawdopodobnie konieczne będzie pełne przywrócenie z kopii zapasowej. Wymaga to znacznie więcej przestojów niż szybki fsck oparty na dzienniku, gdy nie używa się LVM, a dane zapisane od czasu ostatniej kopii zapasowej zostaną utracone.
• TestDisk , ext3grep , ext3undel i inne narzędzia mogą odzyskiwać partycje i pliki z dysków innych niż LVM, ale nie obsługują bezpośrednio odzyskiwania danych LVM. TestDisk może wykryć, że utracona partycja fizyczna zawiera PV LVM, ale żadne z tych narzędzi nie rozumie woluminów logicznych LVM. Narzędzia do rzeźbienia plików , takie jak PhotoRec i wiele innych, działałyby, gdy omijają system plików w celu ponownego złożenia plików z bloków danych, ale jest to ostateczne podejście na niskim poziomie dla cennych danych i działa gorzej z fragmentami plików.
• Ręczne odzyskiwanie LVM jest możliwe w niektórych przypadkach, ale jest skomplikowane i czasochłonne - zobacz ten przykład i to , to i to, jak odzyskać.

Trudniejsze do prawidłowej zmiany rozmiaru systemów plików - łatwa zmiana rozmiaru systemu plików jest często podawana jako zaleta LVM, ale musisz wykonać pół tuzina poleceń powłoki, aby zmienić rozmiar FS opartego na LVM - można to zrobić, gdy cały serwer jest włączony, aw niektórych przypadkach z zainstalowanym FS, ale nigdy nie zaryzykowałbym tego ostatniego bez aktualnych kopii zapasowych i korzystania z poleceń wstępnie przetestowanych na równoważnym serwerze (np. klon odzyskiwania po awarii serwera produkcyjnego).

• Aktualizacja: Nowsze wersje lvextendobsługują opcję -r( --resizefs) - jeśli jest dostępna, jest to bezpieczniejszy i szybszy sposób zmiany rozmiaru LV i systemu plików, szczególnie jeśli zmniejszasz FS, i możesz w większości pominąć tę sekcję.
• Większość poradników dotyczących zmiany rozmiaru FS opartych na LVM nie bierze pod uwagę faktu, że FS musi być nieco mniejszy niż rozmiar LV: szczegółowe wyjaśnienie tutaj . Podczas zmniejszania systemu plików konieczne będzie określenie nowego rozmiaru w narzędziu zmiany rozmiaru FS, np. resize2fsDla ext3 i do lvextendlub lvreduce. Bez szczególnej uwagi rozmiary mogą się nieznacznie różnić ze względu na różnicę między 1 GB (10 ^ 9) a 1 GiB (2 ^ 30) lub sposób, w jaki różne narzędzia zaokrąglają rozmiary w górę lub w dół.
• Jeśli nie wykonasz obliczeń dokładnie we właściwy sposób (lub wykonasz kilka dodatkowych kroków poza najbardziej oczywistymi), możesz skończyć z FS, który jest zbyt duży dla LV. Wszystko będzie wyglądało dobrze przez miesiące lub lata, aż do całkowitego wypełnienia FS, w którym to momencie dojdzie do poważnej korupcji - i chyba, że ​​jesteś świadomy tego problemu, trudno jest dowiedzieć się, dlaczego, ponieważ do tego czasu możesz również mieć prawdziwe błędy dysku które zaciemniają sytuację. (Możliwe, że ten problem wpływa tylko na zmniejszenie rozmiaru systemów plików - jednak jasne jest, że zmiana rozmiaru systemów plików w obu kierunkach zwiększa ryzyko utraty danych, prawdopodobnie z powodu błędu użytkownika).

• Wygląda na to, że rozmiar LV powinien być większy niż rozmiar FS o 2 x rozmiar LVM fizycznego zasięgu (PE) - ale sprawdź link powyżej, aby uzyskać szczegółowe informacje, ponieważ źródło tego nie jest wiarygodne. Często wystarczające jest zezwolenie na 8 MiB, ale może być lepiej pozwolić na więcej, np. 100 MiB lub 1 GiB, dla bezpieczeństwa. Aby sprawdzić rozmiar PE i wolumin logiczny + rozmiary FS, używając 4 bloków KiB = 4096 bajtów:

  Pokazuje rozmiar PE w KiB:
  vgdisplay --units k myVGname | grep "PE Size"
  
  Rozmiar wszystkich LV:
  lvs --units 4096b
  
  Rozmiar (ext3) FS, zakłada rozmiar bloku 4 KiB FS:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• Natomiast konfiguracja bez LVM sprawia, że ​​zmiana rozmiaru FS jest bardzo niezawodna i łatwa - uruchom Gparted i zmień rozmiar wymaganych FS, wtedy zrobi wszystko za Ciebie. Na serwerach możesz używać partedz powłoki.

  • Często najlepiej jest używać Gparted Live CD lub Parted Magic , ponieważ mają one najnowsze i często bardziej wolne od błędów Gparted i jądro niż wersja dystrybucyjna - kiedyś straciłem całe FS z powodu niepoprawnego aktualizowania partycji przez Gparted jądro. Jeśli używasz Gparted dystrybucji, koniecznie zrestartuj komputer zaraz po zmianie partycji, aby widok jądra był poprawny.

Migawki są trudne w użyciu, powolne i zawierają błędy - jeśli migawka zabraknie wstępnie przydzielonego miejsca, zostanie automatycznie upuszczona . Każda migawka danego LV jest różnicą w stosunku do tej LV (nie w porównaniu z poprzednimi migawkami), która może wymagać dużo miejsca podczas migawek systemów plików ze znaczną aktywnością zapisu (każda migawka jest większa niż poprzednia). Można bezpiecznie utworzyć migawkę LV o takim samym rozmiarze jak oryginalna LV, ponieważ migawka nigdy nie zabraknie wolnego miejsca.

Migawki mogą być również bardzo wolne (co oznacza 3 do 6 razy wolniejsze niż bez LVM dla tych testów MySQL ) - zobacz tę odpowiedź dotyczącą różnych problemów z migawkami . Powolność jest częściowo spowodowana tym, że migawki wymagają wielu zapisów synchronicznych .

Migawki miały kilka istotnych błędów, np. W niektórych przypadkach mogą spowalniać uruchamianie bardzo wolno lub powodować całkowite niepowodzenie rozruchu (ponieważ jądro może przekroczyć limit czasu oczekiwania na root FS, gdy jest to migawka LVM [naprawione w initramfs-toolsaktualizacji Debiana , marzec 2015] ).

• Jednak wiele błędów stanu migawkowego wyścigu zostało najwyraźniej naprawionych do 2015 roku.
• LVM bez migawek ogólnie wydaje się całkiem dobrze debugowany, być może dlatego, że migawki nie są używane tak często, jak podstawowe funkcje.

Alternatywne migawki - systemy plików i hiperwizory maszyn wirtualnych

Migawki maszyny wirtualnej / chmury:

• Jeśli korzystasz z hypervisora ​​VM lub dostawcy chmury IaaS (np. VMware, VirtualBox lub Amazon EC2 / EBS), ich migawki są często znacznie lepszą alternatywą dla migawek LVM. Możesz dość łatwo zrobić migawkę w celu wykonania kopii zapasowej (ale zanim to zrobisz, rozważ zamrożenie FS).

Migawki systemu plików:

• migawki na poziomie systemu plików z ZFS lub btrfs są łatwe w użyciu i ogólnie lepsze niż LVM, jeśli używasz goły komputer (ale ZFS wydaje się o wiele bardziej dojrzały, po prostu więcej problemów z instalacją):

  • ZFS: istnieje teraz implementacja ZFS jądra , która jest używana od kilku lat
  • btrfs : wciąż nie jest gotowy do użytku produkcyjnego ( nawet na openSUSE, który domyślnie dostarcza go i ma zespół dedykowany do btrfs), podczas gdy RHEL przestał go obsługiwać), a jego narzędzia fsck i naprawy są wciąż w fazie rozwoju.

Migawki dla kopii zapasowych online i fsck

Migawek można użyć w celu zapewnienia spójnego źródła kopii zapasowych, o ile zachowasz ostrożność przy przydzielaniu miejsca (najlepiej, że migawka ma taki sam rozmiar jak kopia zapasowa LV). Doskonały rsnapshot (od 1.3.1) nawet zarządza tworzeniem / usuwaniem migawek LVM - zobacz to HOWTO na rsnapshot przy użyciu LVM . Należy jednak pamiętać o ogólnych problemach z migawkami i że migawki nie należy uważać za kopię zapasową samą w sobie.

Możesz także użyć migawek LVM, aby wykonać fsck online: migawkę LV i fsck migawkę, przy jednoczesnym użyciu głównego nie-migawkowego FS - opisanego tutaj - jednak nie jest to całkowicie proste, więc najlepiej użyć e2croncheck zgodnie z opisem Ted Ts „o , opiekun ext3.

Powinieneś tymczasowo „zamrozić” system plików podczas robienia migawki - niektóre systemy plików, takie jak ext3 i XFS, zrobią to automatycznie, gdy LVM utworzy migawkę.

Wnioski

Mimo to nadal używam LVM na niektórych systemach, ale dla konfiguracji pulpitu wolę partycje raw. Główną korzyścią, którą widzę z LVM, jest elastyczność przenoszenia i zmiany rozmiaru FS, kiedy musisz mieć długi czas pracy na serwerze - jeśli nie potrzebujesz tego, gparted jest łatwiejszy i ma mniejsze ryzyko utraty danych.

LVM wymaga dużej ostrożności przy konfiguracji buforowania zapisu ze względu na hiperwizory VM, buforowanie zapisu na dysku twardym / SSD itd. - ale to samo dotyczy używania Linuksa jako serwera DB. Brak wsparcia ze strony większości narzędzi (w gpartedtym obliczeń wielkości krytycznych testdiskitp.) Sprawia, że ​​korzystanie z niego jest trudniejsze niż powinno.

Jeśli używasz LVM, zachowaj szczególną ostrożność przy tworzeniu migawek: w miarę możliwości używaj migawek VM / chmury lub zbadaj ZFS / btrfs, aby całkowicie uniknąć LVM - możesz stwierdzić, że ZFS lub btrs są wystarczająco dojrzałe w porównaniu do LVM z migawkami.

Konkluzja: Jeśli nie wiesz o powyższych problemach i jak je rozwiązać, najlepiej nie używać LVM.

Daję +1 temu postowi i przynajmniej dla mnie myślę, że większość problemów istnieje. Widziałem je podczas uruchamiania kilku 100 serwerów i kilku 100 TB danych. Dla mnie LVM2 w Linuksie wydaje się być „sprytnym pomysłem”, jaki ktoś miał. Jak niektóre z nich okazują się czasami „nie sprytne”. Tzn., Że nie ma ściśle oddzielonych stanów jądra i przestrzeni użytkownika (lvmtab), mogłem poczuć się naprawdę mądry, aby zlikwidować, ponieważ mogą wystąpić problemy z korupcją (jeśli nie uda się poprawnie uzyskać kodu)

Cóż, po prostu ten podział był z jakiegoś powodu - różnice pokazują, jak radzić sobie z utratą PV, i ponowną aktywację online VG z np. Brakującymi PV, aby przywrócić je do gry - Co to jest proste na „oryginalnych LVM” (AIX , HP-UX) zamienia się w bzdury na LVM2, ponieważ obsługa stanu nie jest wystarczająco dobra. I nawet nie zrozumcie mnie mówisz wykrywania strat Quorum (haha) lub stan obsługi (jeśli usunąć dysku, który nie zostanie oznaczony jako niedostępny. To nawet nie mieć kolumnę stanu cholerną)

Re: stabilność pvmove ... dlaczego jest

pvmove utrata danych

taki artykuł na najwyższym blogu na moim blogu, hmmm? Właśnie teraz patrzę na dysk, na którym fiskalne dane lvm są nadal zawieszone na stanie od połowy pvmove. Myślę, że były pewne memleaki, a ogólny pomysł, że dobrze jest kopiować dane z bloków na żywo z przestrzeni użytkownika, jest po prostu smutny. Ładny cytat z listy lvm „wydaje się, że vgreduce - brak obsługi nie obsługuje pvmove” Oznacza to, że jeśli dysk zostanie odłączony podczas pvmove, to narzędzie do zarządzania lvm zmienia się z lvm na vi. Aha, wystąpił również błąd, w którym pvmove kontynuuje działanie po błędzie odczytu / zapisu bloku i w rzeczywistości nie zapisuje już danych do urządzenia docelowego. WTF?

Re: Migawki CoW odbywa się niepewnie, poprzez aktualizację NOWYCH danych w obszarze lv migawki, a następnie scalanie z powrotem po usunięciu migawki. Oznacza to, że masz duże skoki we / wy podczas ostatecznego scalania nowych danych do pierwotnej LV i, co ważniejsze, oczywiście masz również znacznie większe ryzyko uszkodzenia danych, ponieważ migawka nie zostanie przerwana, gdy trafisz na ściana, ale oryginał.

Zaletą jest wydajność, wykonanie 1 zapisu zamiast 3. Wybranie szybkiego, ale nieprzejrzystego algorytmu jest czymś, czego oczywiście oczekuje się od ludzi takich jak VMware i MS, na „Unixie” raczej bym pomyślał, że wszystko byłoby zrobione „dobrze”. Nie widziałem wielu problemów z wydajnością, o ile mam magazyn kopii zapasowych migawek na innym dysku niż dane podstawowe (i oczywiście kopię zapasową na innym dysku)

Re: Bariery Nie jestem pewien, czy można winić LVM. O ile mi wiadomo, była to sprawa devmapper. Ale może być wina, że ​​tak naprawdę nie przejmujemy się tym problemem, przynajmniej od jądra 2.6 aż do 2.6.33 AFAIK Xen jest jedynym hypervisorem używającym O_DIRECT dla maszyn wirtualnych. nadal będzie buforować przy użyciu tego. Virtualbox ma przynajmniej pewne ustawienia, aby wyłączyć takie rzeczy, a Qemu / KVM ogólnie wydaje się zezwalać na buforowanie. Wszystkie FUSE FS również mają tam problemy (brak O_DIRECT)

Re: Rozmiary Myślę, że LVM „zaokrągla” wyświetlany rozmiar. Lub używa GiB. W każdym razie musisz użyć rozmiaru Pe VG i pomnożyć go przez numer LE LV. To powinno dać prawidłowy rozmiar sieci, a ten problem jest zawsze problemem użytkowania. Sytuację pogarszają systemy plików, które nie zauważają czegoś takiego podczas fsck / mount (hello, ext3) lub nie mają działającego online „fsck -n” (hello, ext3)

Oczywiście mówi to, że nie można znaleźć dobrych źródeł takich informacji. „ile LE dla VRA?” „jaka jest kompensacja fiskalna dla PVRA, VGDA, ... itd.”

W porównaniu z oryginalnym LVM2 jest doskonałym przykładem: „Ci, którzy nie rozumieją UNIX, skazani są na jego ponowne wynalezienie, słabo”.

Zaktualizuj kilka miesięcy później: do tej pory testowałem scenariusz „pełnej migawki”. Jeśli się zapełni, migawka blokuje, a nie oryginalna LV. Myliłem się, kiedy pierwszy raz to opublikowałem. Wybrałem złe informacje od jakiegoś doktora, a może to zrozumiałem. W moich ustawieniach zawsze byłem bardzo paranoikiem, aby nie pozwolić im się zapełnić, więc nigdy nie skończyłem. Możliwe jest również przedłużanie / zmniejszanie migawek, co jest przyjemnością.

Wciąż nie jestem w stanie rozwiązać, jak rozpoznać wiek migawki. Jeśli chodzi o ich wydajność, na stronie projektu „cienki” fedora znajduje się informacja, że ​​technika migawki jest modyfikowana, aby nie ulegała spowolnieniu z każdą migawką. Nie wiem, jak to wdrażają.

jeśli planujesz używać migawek do tworzenia kopii zapasowych - przygotuj się na poważny spadek wydajności, gdy migawka jest obecna. czytaj więcej tutaj . inaczej wszystko będzie dobrze. Używam lvm w produkcji od kilku lat na kilkudziesięciu serwerach, chociaż moim głównym powodem, dla którego go używam, jest migawka atomowa, a nie możliwość łatwego powiększania woluminów.

btw, jeśli zamierzasz używać dysku 1 TB, pamiętaj o wyrównaniu partycji - ten dysk najprawdopodobniej ma sektory fizyczne 4kB.

Adam,

Kolejna zaleta: możesz dodać nowy wolumin fizyczny (PV), przenieść wszystkie dane do tego PV, a następnie usunąć stare PV bez zakłóceń usługi. Korzystałem z tej możliwości co najmniej cztery razy w ciągu ostatnich pięciu lat.

Wada, której jeszcze nie zauważyłem, wyraźnie wskazała: LVM2 ma dość stromą krzywą uczenia się. Głównie w abstrakcji tworzy się między twoimi plikami a mediami. Jeśli pracujesz tylko z kilkoma osobami, które dzielą się obowiązkami na zestawie serwerów, dodatkowa złożoność może być przytłaczająca dla całego zespołu. Większe zespoły zajmujące się pracą IT zazwyczaj nie będą miały takiego problemu.

Na przykład, używamy go szeroko tutaj w mojej pracy i poświęciliśmy czas na nauczenie całego zespołu podstaw, języka i podstawowych zasad odzyskiwania systemów, które nie uruchamiają się poprawnie.

Należy zwrócić uwagę na jedną ostrożność: jeśli uruchamiasz system z woluminu logicznego LVM2, utrudniasz odzyskiwanie po awarii serwera. Knoppix i przyjaciele nie zawsze mają do tego odpowiednie rzeczy. Zdecydowaliśmy więc, że nasz katalog / boot będzie na własnej partycji i zawsze będzie mały i natywny.

Ogólnie jestem fanem LVM2.