Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.

Jak radzić sobie z przebiciami (uszkodzonymi blokami) na dyskach wirtualnych serwerów PowerEdge

Summary: Instrukcje rozwiązywania problemów dotyczących (przebicia) uszkodzonych bloków na dyskach twardych w serwerach PowerEdge z kontrolerami PERC. W szczególności w przypadku braku możliwości utworzenia kopii zapasowych poniższe informacje mogą przyczynić się do przywrócenia optymalnego stanu dysku wirtualnego. ...

This article may have been automatically translated. If you have any feedback regarding its quality, please let us know using the form at the bottom of this page.

Article Content


Symptoms

-

Cause

-

Resolution

Ten artykuł zawiera instrukcje rozwiązywania problemów dotyczących (przebicia) uszkodzonych bloków na dyskach twardych w serwerach PowerEdge z kontrolerami PERC. W szczególności w przypadku braku możliwości utworzenia kopii zapasowych poniższe informacje mogą przyczynić się do przywrócenia optymalnego stanu dysku wirtualnego.



Spis treści:

  1. Opisy usterek

  2. Co jest przyczyną problemu

  3. Kroki niezbędne do rozwiązania problemu

  4. Informacje dodatkowe


 



1. Opisy usterek

 

Usterka nr 1:


Oprogramowanie OpenManage Server Administrator (OMSA) wyświetla czerwony krzyżyk przy dysku wirtualnym (Rysunek 1).  

SLN111146_en_US__11343098652871.1
Rysunek 1: Dysk wirtualny z czerwonym krzyżykiem w stanie (przykład H800)

SLN111146_en_US__2icon Uwaga: Narzędzie Dell OpenManage Server Administrator (OMSA) zapewnia kompletne rozwiązanie do zarządzania systemami. Narzędzie OMSA można podzielić na dwie aplikacje:
- Zintegrowana — graficzny interfejs użytkownika oparty na przeglądarce internetowej (GUI)
- Wiersz poleceń (CLI) — z poziomu systemu operacyjnego


 


Usterka nr 2:


Dziennik systemu Windows zawiera błędy dotyczące uszkodzonych bloków (Rysunek 2).  

SLN111146_en_US__31343098674763.2 
Rysunek 2: Wyświetlony komunikat o błędzie dotyczącym uszkodzonych bloków w dzienniku systemu Windows
 


 


Usterka nr 3:


Dziennik kontrolera RAID (TTYLOG) zawiera błędy takie jak:  

02/26/15 13:43:39: EVT#131878-02/26/15 13:43:39: 97=Puncturing bad block on PD XX(e0x20/s2) at 180ca4a1f

Ostrzeżenie: dziennik kontrolera (TTYLOG) może nie zawierać błędów.

Więcej informacji na temat otrzymywania tych dzienników znajduje się w artykule o zbieraniu dzienników.
 



2. Co jest przyczyną problemu:


Macierze RAID nie są odporne na błędy danych.  Oprogramowanie wewnętrzne kontrolera RAID i dysków twardych zawiera funkcje wykrywania i naprawy wielu typów błędów danych, zanim zostaną one zapisane na macierzy/napędzie.  Korzystanie z przestarzałego oprogramowania wewnętrznego może spowodować zapisywanie nieprawidłowych danych na macierzy/dysku, ponieważ brakuje mu funkcji obsługi błędów / korekcji błędów dostępnych w najnowszych wersjach oprogramowania wewnętrznego.
Błędy danych mogą być również spowodowane przez fizyczne uszkodzone bloki.  Może to na przykład wystąpić w przypadku, gdy głowica odczytu/zapisu uderzy w obracające się talerze (sytuacja ta jest określana jako „zderzenie czołowe”).  Bloki mogą także ulec uszkodzeniu na skutek utraty przez talerze zdolności do magnetycznego zapisywania bitów w określonej lokalizacji.  Uszkodzone bloki spowodowane degradacją talerzy można często z powodzeniem odczytać.  Taki uszkodzony blok może zostać rozpoznany tylko sporadycznie lub przy użyciu rozszerzonej diagnostyki dysków.  

Uszkodzenie bloku znane jest też pod nazwą nieprawidłowego adresu bloku logicznego (LBA) i może być spowodowane przez logiczne błędy danych.  Dzieje się tak w przypadku nieprawidłowego zapisania danych na dysku, które zostało zgłoszone jako prawidłowe.  Dane zapisane prawidłowo na dysku mogą również zostać przypadkowo zmienione.  Przykładem może być „odwrócenie bitu”, które może wystąpić, gdy głowica odczytu/zapisu przechodzi nad lub zapisuje dane w pobliskiej pozycji i powoduje zmianę zapisu danych w postaci zer i jedynek na inną wartość.  Taki stan powoduje utracenie „spójności” danych.  Wartość danych w określonym bloku jest inna niż oryginalne dane i nie jest już zgodna z sumą kontrolną dla tych danych.  Fizyczny adres LBA jest w dobrym stanie i można na nim pomyślnie dokonywać zapisów, ale obecnie zawiera nieprawidłowe dane i może być interpretowany jako uszkodzony blok.

Więcej informacji można znaleźć w artykule Podwójne błędy i przebicia w macierzach RAID.
 



3. Kroki niezbędne do rozwiązania problemu:
 

SLN111146_en_US__2icon Uwaga: bieżące dane na dysku wirtualnym są uszkodzone i będą musiały zostać usunięte.
  1. Utwórz zweryfikowaną kopię zapasową danych na poziomie plików
     

    • Kopia zapasowa oparta na blokach spowoduje przeniesienie problemu
    • Kopia zapasowa na poziomie plików wskazuje uszkodzone pliki (tworzenie kopii zapasowej tych plików nie powiedzie się)
    • Nie ma 100% gwarancji zachowania wszystkich danych, jeśli istnieje już pasek przebicia
     

     

  2. Upewnij się, że wszystkie uszkodzone dyski, które wykazują stan przewidywanej awarii, zostaną wymienione
     

  3. Usuń i utwórz ponownie dysk wirtualny
     

    • Ten krok spowoduje usunięcie wszystkich danych z dysku wirtualnego
    • Usuń macierz
    • Odtwórz macierz w wymagany sposób
     

     

  4. Wykonaj pełną inicjalizację dysku wirtualnego
     

    • Upewnij się, że nie wybrano szybkiej inicjalizacji
    • Tylko pełna (= powolna) inicjalizacja rozwiązuje problem
     

     

  5. Wykonaj sprawdzanie spójności na nowym utworzonym dysku wirtualnym
     

    • Jeśli sprawdzanie spójności nie wykaże błędów, macierz jest sprawna i przebicie zostało usunięte
     

     

  6. Można przywrócić dane na sprawny dysk wirtualny
     

  7. Zalecenie: zaktualizuj oprogramowanie wewnętrzne wszystkich dysków twardych do najnowszej wersji
     



4. Informacje dodatkowe

Oprogramowanie OMSA zapewnia możliwość wyczyszczenia ostrzeżeń o uszkodzonych blokach. Aby usunąć uszkodzone bloki, zaleca się wykonanie następującej procedury:

  • Podczas wykonywania kopii zapasowej dysku wirtualnego z wybraną opcją Verify (Weryfikuj) mogą wystąpić dwa scenariusze:

    • Operacja tworzenia kopii zapasowej nie powiedzie się w przypadku jednego lub więcej plików. W takim przypadku przywróć plik z poprzedniej kopii zapasowej. Po przywróceniu pliku przejdź do następnego kroku.
    • Operacja tworzenia kopii zapasowych zakończy się bez błędów. Oznacza to, że nie ma uszkodzonych bloków na zapisywanej części dysku wirtualnego.
    SLN111146_en_US__2icon Uwaga: jeśli nadal otrzymujesz ostrzeżenia o nieprawidłowych blokach, takie bloki znajdują się w obszarze bez danych.

     
  • Uruchom funkcję Patrol Read (w obszarze Virtual Disk Tasks w oprogramowaniu OMSA) i sprawdź dziennik zdarzeń systemowych, aby upewnić się, że nie znaleziono żadnych nowych uszkodzonych bloków. Jeśli nadal istnieją uszkodzone bloki, przejdź do następnego kroku. Jeśli nie, warunek został usunięty.

    SLN111146_en_US__2icon Uwaga: automatyczna funkcja Patrol Read musi zostać dezaktywowana, zanim opcja ręcznego uruchomienia tego działania zostanie wyświetlona w oprogramowaniu OMSA.

     
  • Aby usunąć te uszkodzone bloki, wykonaj zadanie Clear Virtual Disk Bad Blocks (Wyczyść uszkodzone bloki dysku wirtualnego). Można to zrobić w graficznym interfejsie użytkownika oprogramowania OMSA lub użyć polecenia CLI:
    omconfig storage vdisk action=clearvdbadblocks controller=id vdisk=id

    SLN111146_en_US__2icon Uwaga: aby uzyskać wartości identyfikatora kontrolera i identyfikatora dysku wirtualnego, wpisz omreport storage controller, aby wyświetlić identyfikatory kontrolera, a następnie wpisz omreport storage vdisk controller=ID, aby wyświetlić identyfikatory dysków wirtualnych.

     

Article Properties


Affected Product

Servers

Last Published Date

01 Oct 2021

Version

3

Article Type

Solution