SLES Thin Pool – brak miejsca: bezpieczne rozszerzenie LVM i przywrócenie zapisów

Gdy wolumin SUSE Linux Enterprise Server z funkcją thin-provisioned zgłasza komunikat „brak miejsca na urządzeniu”, sprawdź najpierw pulę thin-provisioned Data%i . Jeśli obszar danych jest pełny, a grupa woluminów ma wolne zakresy, rozszerz pulę thin-provisioned o — nie tylko wirtualny rozmiar jej cienkiego woluminu logicznego. Całkowicie zapełniony obszar metadanych działa inaczej: może wymagać naprawy offline przed wznowieniem normalnych zapisów.Meta%lvextend

Poniższa procedura wykorzystuje polecenia LVM2 udokumentowane dla systemu Linux i modelu pamięci masowej opisanego w Podręczniku administratora pamięci masowej SUSE Linux Enterprise Server 15 SP7 . Dostępność poleceń i konfiguracja usług mogą się różnić w przypadku innego dodatku Service Pack SLES lub instalacji klastrowej. Przed modyfikacją pamięci masowej produkcyjnej należy wykonać kopię zapasową spójną z aplikacją i ograniczyć duże zapisy.

1. Sprawdź, czy przestrzeń danych lub metadane nie są wyczerpane

Uruchom poniższe polecenie na hoście, który jest właścicielem aktywnego cienkiego puli, zastępując vgdataje nazwą swojej grupy woluminów:

sudo lvs -a -o lv_name,lv_size,segtype,data_percent,metadata_percent,pool_lv vgdata

Poszukaj wiersza z thin-poolwartością poniżej SegType. Data%mierzy przydzielone bloki danych; Meta%mierzy metadane mapowania puli. Są to oddzielne limity pojemności. Jeśli Data%wartość jest bliska 100, ale Meta%znacznie poniżej tej wartości, najbardziej bezpośrednim rozwiązaniem są dodatkowe zakresy danych. Jeśli Meta%wartość wynosi 100, zastosuj środki ostrożności dotyczące odzyskiwania danych opisane w sekcji 4.

Jako hipotetyczny przykład załóżmy, vgdata/pool0że mamy 100 GiB z 98,12% wykorzystaniem danych i 40,26% wykorzystaniem metadanych. Pula jest bezpośrednio zagrożona, nawet jeśli df -hraportuje dużą ilość miejsca w zamontowanym woluminie cienkim. Wirtualny rozmiar woluminu cienkiego może przekraczać fizyczną pojemność puli, jak wyjaśnia dokumentacja Expert Partitioner firmy SUSE .

Sprawdź także ostatnie błędy:

sudo journalctl -k --since "-30 min" | grep -Ei 'thin|no space|I/O error'

Nie interpretuj pustego wyniku polecenia grep jako dowodu, że nie wystąpiły żadne nieudane zapisy. Sprawdź również logi aplikacji, zwłaszcza jeśli baza danych lub maszyna wirtualna zapisywała dane, gdy pula się zapełniła.

2. Sprawdź, czy grupa woluminów ma wolne fizyczne obszary

Przed zmianą rozmiaru puli sprawdź, czy grupa woluminów może sfinansować rozszerzenie:

sudo vgs -o vg_name,vg_size,vg_free vgdata

W hipotetycznym przykładzie grupa woluminów 200 GiB ma 40 GiB wolnego miejsca. Rozszerzenie puli o 20 GiB jest zatem w zasadzie wykonalne, z zastrzeżeniem ograniczeń alokacji i możliwości ewentualnego wzrostu metadanych. Należy zachować część przestrzeni VG w rezerwie, zamiast przypisywać puli każdy wolny zakres.

Jeśli VG_FREEwynosi zero, lvextendnie można wyznaczyć pojemności fizycznej. Dodaj poprawnie zidentyfikowany i przygotowany wolumin fizyczny do grupy woluminów (VG), powiększ odpowiednio pamięć masową i jej wartość LVM PV lub odzyskaj bloki przed ponowną próbą. Dokumenty SUSE zawierają informacje o dodawaniu woluminów fizycznych podczas zmiany rozmiaru grupy woluminów . Nigdy nie uruchamiaj tej funkcji pvcreatena niezweryfikowanym dysku: może to spowodować zniszczenie istniejących metadanych pamięci masowej.

3. Rozszerz raczej cienką pulę niż cienką objętość

Gdy Data%czynnikiem ograniczającym jest nie wyczerpanie metadanych i wystarczająca liczba zakresów VG jest wolna, należy rozszerzyć sam pulę:

sudo lvextend -L +20G vgdata/pool0

Składnia +20Gdodaje 20 GiB do bieżącego rozmiaru puli; nie ustawia rozmiaru końcowego na 20 GiB. W tym przykładzie pula zapasowa zwiększa się ze 100 GiB do 120 GiB. Przy niezmienionych przydzielonych danych, 98,12 GiB w użyciu stanowiłoby około 81,8% powiększonej puli. Rzeczywisty procent może się różnić, jeśli zapisy będą kontynuowane w trakcie operacji.

Nie należy zastępować . lvextend -L +20G vgdata/thin1Powiększenie wirtualnej przestrzeni adresowej woluminu cienkiego niekoniecznie zwiększa fizyczną pojemność puli danych. Ponieważ to polecenie rozszerza pulę zapasową, a nie wirtualne urządzenie blokowe systemu plików, zmiana rozmiaru systemu plików nie jest zazwyczaj wymagana do tej konkretnej operacji. Autorytatywny podręcznik cienkiego provisioningu LVM opisuje mechanizm rozszerzania puli cienkiej i jego ograniczenia.

Kiedy nie możesz natychmiast powiększyć puli

Jeśli pliki zostały już usunięte z cienkiego systemu plików i cały stos obsługuje funkcję usuwania, należy rozważyć odzyskanie usuniętych bloków:

sudo fstrim -v /srv/data

Użyj rzeczywistego punktu montowania woluminu cienkiego, a nie urządzenia puli cienkiej. Pomyślne przycięcie może obniżyć wartość Data%, ale samo usunięcie plików zazwyczaj nie przywraca bloków do puli. Migawki cienkie mogą zachowywać współdzielone bloki, a pula skonfigurowana do ignorowania odrzuceń nie przyniesie żadnych korzyści. Nie traktuj przycięcia jako niezawodnego, awaryjnego zamiennika pojemności fizycznej, szczególnie jeśli zapisy zaczęły się nie powieść. Usuń stare migawki dopiero po sprawdzeniu ich właścicieli, zależności i wymagań dotyczących przechowywania; usunięcie migawki jest nieodwracalne.

4. Potraktuj pełny obszar metadanych jako warunek odzyskiwania

Jeśli Meta%osiągnięto 100%, należy zatrzymać zapisy w aplikacji i zaplanować kontrolowaną przerwę. LVM ostrzega, że ​​wyczerpanie metadanych może spowodować niespójność metadanych i systemów plików w puli cienkiej. Samo zwiększenie rozmiaru danych w puli, ponawianie prób zapisu lub wymuszenie aktywacji nie eliminuje tego ryzyka.

Udokumentowana sekwencja odzyskiwania polega na dezaktywacji puli w trybie offline, naprawie jej cienkich metadanych za pomocą lvconvert --repair VG/ThinPool, zwiększeniu pojemności metadanych za pomocą lvextend --poolmetadatasize, a następnie sprawdzeniu każdego systemu plików za pomocą odpowiedniego narzędzia offline. Na przykład pula, której rozmiar metadanych jest mniejszy niż 2 GB, może wymagać zweryfikowanego celu, takiego jak:

sudo lvextend --poolmetadatasize 2G vgdata/pool0

To nie jest polecenie do uruchomienia bezmyślnie w aktywnej, uszkodzonej puli. Jego rozmiar jest przykładem, a nie uniwersalnym wymaganiem. Najpierw sprawdź aktualny rozmiar metadanych, dostępne zakresy, poprawność dezaktywacji, nośniki odzyskiwania i kopie zapasowe. lvconvert --repairNależy je zaplanować z uwzględnieniem doświadczenia w zakresie przestojów i odzyskiwania; podręcznik LVM wskazuje, że może się to nie powieść, a dane mogą być nadal nieodzyskalne. Zachowaj stare metadane LV do czasu weryfikacji puli i systemów plików. Kopia zapasowa konfiguracji LVM vgcfgbackupnie tworzy kopii zapasowej metadanych puli cienkiej. W przypadku danych krytycznych dla firmy, przed podjęciem próby naprawy skontaktuj się ze wsparciem technicznym SUSE lub zespołem ds. odzyskiwania pamięci masowej.

5. Włącz automatyczne rozszerzanie, a następnie sprawdź zapisy

Po ustabilizowaniu systemu skonfiguruj proaktywną politykę wzrostu w activationsekcji /etc/lvm/lvm.conf. W tym przykładzie rozszerzenie rozpoczyna się przy 70% wykorzystaniu i żąda 20% wzrostu; dostosuj te wartości do szybkości zapisu i dostępnej pojemności VG:

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

Upewnij się, że ustawienia zostały zastosowane do prawidłowego zakresu konfiguracji i pula jest monitorowana:

sudo lvchange --monitor y vgdata/pool0

Automatyczny wzrost puli cienkiej zależy od monitorowania zdarzeń LVM ( dmeventd) i wystarczającej liczby wolnych ekstentów. Sprawdź usługę monitorowania udostępnianą przez instalację SLES — na przykład systemctl status lvm2-monitortam, gdzie ta jednostka istnieje — i przejrzyj jej logi. Próg nie gwarantuje ochrony, jeśli zapisy przekraczają rozszerzenie lub VG jest już pełne. Zapoznaj się z instrukcjami dotyczącymi automatycznego rozszerzania i opcji monitorowania lvchange w podręczniku LVM .

Sprawdź, czy poprawka zadziałała

Odczytaj dane dotyczące wykorzystania puli i pozostałej pojemności VG:

sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vgdata/pool0
sudo vgs -o vg_name,vg_free vgdata

Data%Powinien zostać usunięty po rozszerzeniu puli danych, Meta%musi pozostać poniżej stanu wyczerpania, a pula powinna być aktywna bez nowych błędów wejścia/wyjścia. Sprawdź stan systemu plików i logi aplikacji, a następnie przeprowadź niewielki, odpowiedni dla danej aplikacji test zapisu i odczytu przed zwolnieniem zawieszonych obciążeń. Jeśli błędy nadal występują po udostępnieniu wolnego miejsca, utrzymuj obciążenie w trybie offline do czasu oceny integralności systemu plików i aplikacji; większa pojemność nie jest w stanie odwrócić już nieudanych lub utraconych zapisów.