Preludium:

Jestem małpą kodową, która coraz częściej przejmuje obowiązki SysAdmin w mojej małej firmie. Mój kod jest naszym produktem i coraz częściej udostępniamy tę samą aplikację co SaaS.

Około 18 miesięcy temu przeniosłem nasze serwery z centralnego dostawcy hostingu premium na pchacz szafy typu barebone w centrum danych IV poziomu. (Dosłownie po drugiej stronie ulicy.) Ten pomysł robi o wiele więcej sami - na przykład sieci, przechowywania i monitorowania.

W ramach wielkiego posunięcia, aby zastąpić naszą dzierżawioną bezpośrednio podłączoną pamięć masową od firmy hostingowej, zbudowałem dwuwęzłowy NAS o pojemności 9 TB w oparciu o podwozia SuperMicro, 3ware karty RAID, Ubuntu 10.04, dwa tuziny dysków SATA, DRBD i. Wszystko zostało pięknie udokumentowane w trzech postach na blogu: Tworzenie i testowanie nowego NAS 9 TB SATA RAID10 NFSv4 NAS: część I , część II i część III .

Konfigurujemy również system monitorowania Cacit. Ostatnio dodajemy coraz więcej punktów danych, takich jak wartości SMART.

Nie mogłem zrobić to wszystko bez niesamowite boffins w ServerFault . To było zabawne i edukacyjne doświadczenie. Mój szef jest szczęśliwy (zaoszczędziliśmy mnóstwo ładunków $$$) , nasi klienci są zadowoleni (koszty magazynowania spadły) , jestem szczęśliwy (zabawa, zabawa, zabawa) .

Do wczoraj.

Awaria i powrót do zdrowia:

Jakiś czas po obiedzie zaczęliśmy otrzymywać raporty o powolnej wydajności z naszej aplikacji, CMS mediów strumieniowych na żądanie. Mniej więcej w tym samym czasie nasz system monitorowania kaktusów wysłał lawinę e-maili. Jednym z bardziej wymownych alarmów był wykres iostatu.

Wydajność uległa tak znacznemu pogorszeniu, że Pingdom zaczął wysyłać powiadomienia „serwer nie działa”. Całkowite obciążenie było umiarkowane, nie wystąpił wzrost natężenia ruchu.

Po zalogowaniu się na serwerach aplikacji, klientach NFS NAS, potwierdziłem, że prawie wszystko przeżywało bardzo nieregularne i niesamowicie długie czasy oczekiwania na IO. A kiedy wskoczyłem na sam główny węzeł NAS, te same opóźnienia były widoczne podczas próby poruszania się po systemie plików tablicy problemów.

Czas na awarię, poszło dobrze. W ciągu 20 minut wszystko potwierdziło, że wszystko działa poprawnie.

Sekcja zwłok:

Po wszystkich awariach systemu wykonuję sekcję zwłok, aby ustalić przyczynę awarii. Pierwszą rzeczą, którą zrobiłem, było ssh z powrotem do pudełka i zacznij przeglądać logi. To było całkowicie offline. Czas na wycieczkę do centrum danych. Resetowanie sprzętu, tworzenie kopii zapasowych i uruchamianie.

W /var/syslogznalazłem ten przerażająco wyglądający wpis:

Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_00], 6 Currently unreadable (pending) sectors
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_07], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 171 to 170
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 16 Currently unreadable (pending) sectors
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 4 Offline uncorrectable sectors
Nov 15 06:49:45 umbilo smartd[2827]: Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
Nov 15 06:49:45 umbilo smartd[2827]: # 1  Short offline       Completed: read failure       90%      6576         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 2  Short offline       Completed: read failure       90%      6087         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 3  Short offline       Completed: read failure       10%      5901         656821791
Nov 15 06:49:45 umbilo smartd[2827]: # 4  Short offline       Completed: read failure       90%      5818         651637856
Nov 15 06:49:45 umbilo smartd[2827]:

Poszedłem więc sprawdzić wykresy kaktusów dla dysków w tablicy. Widzimy tutaj, że tak, dysk 7 wymyka się, tak jak mówi syslog. Ale widzimy również, że Err SMART Read ERR dysku 8 zmienia się.

Brak wiadomości o dysku 8 w syslog. Bardziej interesujące jest to, że zmienne wartości dla dysku 8 bezpośrednio korelują z wysokimi czasami oczekiwania na IO! Moja interpretacja jest taka:

• Na dysku 8 występuje dziwny błąd sprzętowy, który powoduje nieregularne długie czasy działania.
• W jakiś sposób ten stan błędu na dysku blokuje całą macierz

Być może istnieje bardziej dokładny lub poprawny opis, ale wynik netto jest taki, że jeden dysk wpływa na wydajność całej macierzy.

Pytania)

• Jak pojedynczy dysk w sprzętowej macierzy SATA RAID-10 może zatrzymać całą macierz?
• Czy naiwnie myślę, że karta RAID powinna sobie z tym poradzić?
• Jak mogę zapobiec wpływowi pojedynczego źle działającego dysku na całą macierz?
• Czy coś brakuje?

Nienawidzę mówić „nie używaj SATA” w krytycznych środowiskach produkcyjnych, ale dość często widziałem tę sytuację. Dyski SATA nie są generalnie przeznaczone do opisanego cyklu pracy, chociaż w konfiguracji skonfigurowano dyski o parametrach specjalnie przeznaczonych do pracy 24x7 . Z mojego doświadczenia wynika, że ​​dyski SATA mogą ulec awarii w nieprzewidywalny sposób, często wpływając na całą macierz pamięci, nawet jeśli korzystasz z RAID 1 + 0, tak jak to zrobiłeś. Czasami dyski ulegają awarii w sposób, który może zablokować całą magistralę. Należy zwrócić uwagę na to, czy w konfiguracji używasz ekspanderów SAS. Może to mieć wpływ na wpływ pozostałych dysków na awarię napędu.

Jednak bardziej sensowne może być zastosowanie dysków SAS z linii środkowej / bliskiej (7200 obr./min) w porównaniu do SATA. Istnieje niewielka przewaga cenowa nad SATA, ale dyski będą działać / ulegać awarii w bardziej przewidywalny sposób. Korekcja błędów i raportowanie w interfejsie / protokole SAS jest bardziej niezawodne niż zestaw SATA. Tak więc nawet w przypadku dysków, których mechanika jest taka sama , różnica w protokole SAS mogła zapobiec bólowi występującemu podczas awarii dysku.

Jak pojedynczy dysk może sprowadzić macierz? Odpowiedź brzmi: nie powinno, ale w pewnym sensie zależy to od przyczyny awarii. Jeśli dysk miałby umrzeć w sposób, który się zachowywał, nie powinien go zdejmować. Ale możliwe, że zawodzi w „przypadku krawędzi”, którego kontroler nie jest w stanie obsłużyć.

Czy naiwnie myślisz, że to nie powinno się zdarzyć? Nie, nie sądzę. Taka sprzętowa karta RAID powinna była obsłużyć większość problemów.

Jak temu zapobiec? Nie możesz przewidzieć takich dziwnych przypadków na krawędzi. Jest to częścią bycia sysadminem ... ale możesz pracować nad procedurami odzyskiwania, aby nie wpływały na twoją firmę. Jedynym sposobem, aby teraz to naprawić, jest wypróbowanie innej karty sprzętowej (prawdopodobnie nie to, co chcesz zrobić) lub zmiana dysków na dyski SAS zamiast SATA, aby sprawdzić, czy SAS jest bardziej wytrzymały. Możesz także skontaktować się ze sprzedawcą karty RAID i powiedzieć mu, co się stało, i zobaczyć, co mówią; w końcu to firma, która ma się specjalizować w poznawaniu tajników elektroniki napędowej. Mogą mieć więcej porad technicznych na temat działania napędów, a także niezawodności ... jeśli możesz dotrzeć do właściwych osób, z którymi możesz porozmawiać.

Coś przegapiłeś? Jeśli chcesz sprawdzić, czy na dysku występuje awaria krawędzi, wyciągnij go z macierzy. Tablica zostanie zdegradowana, ale nie powinieneś mieć więcej dziwnych spowolnień i błędów (oprócz statusu zdegradowanej tablicy). Mówisz, że teraz wydaje się, że działa dobrze, ale jeśli występują błędy odczytu dysku, należy wymienić dysk, póki to możliwe. Dyski o dużej pojemności mogą czasami zawierać błędy URE (najlepszy powód, aby nie uruchamiać RAID 5, uwaga dodatkowa), które nie pojawiają się, dopóki inny dysk nie ulegnie awarii. A jeśli zachowuje się przypadkowe zachowanie z tego jednego dysku, nie chcesz, aby uszkodzone dane były migrowane na inne dyski w macierzy.

Nie jestem ekspertem, ale zamierzam zrobić niesamowite zdjęcie w ciemności na podstawie moich doświadczeń z kontrolerami RAID i macierzami pamięci.

Dyski ulegają awarii na wiele różnych sposobów. Niestety, dyski mogą ulegać awarii lub być wadliwe w sposób, który poważnie wpływa na ich wydajność, ale kontroler RAID nie widzi awarii.

Jeśli dysk ulegnie awarii w oczywisty sposób, każde oprogramowanie kontrolera RAID powinno być całkiem dobre w wykrywaniu braku odpowiedzi z dysku, usuwaniu go z puli i wysyłaniu powiadomień. Jednak przypuszczam, że dzieje się tutaj to, że dysk cierpi na niezwykłą awarię, która z jakiegoś powodu nie powoduje awarii po stronie kontrolera. Dlatego, gdy kontroler dokonuje operacji zapisu lub odczytu z uszkodzonego dysku, powrót zajmuje dużo czasu, a to z kolei powoduje zawieszenie całego operacji we / wy, a tym samym macierzy. Z jakiegokolwiek powodu to nie wystarczy, aby kontroler RAID przejął „ah, uszkodzony dysk”, prawdopodobnie dlatego, że dane w końcu wracają.

Radzę natychmiast wymienić wadliwy dysk. Następnie przyjrzę się konfiguracji twojej karty RAID (to 3ware, myślałem, że są całkiem dobre) i dowiedzę się, co uważa za uszkodzony dysk.

PS fajny pomysł na import SMART do kaktusów.

Potrzebujesz funkcji urządzeń pamięci masowej klasy korporacyjnej. W szczególności dyski korporacyjne WD RE 4 mają dwie funkcje potrzebne do zapobiegania takiemu działaniu macierzy RAID. Pierwsza z wymienionych poniżej technologii zapobiega niepotrzebnemu zużyciu wibracyjnych harmonicznych obrotowych na mechanicznych elementach dysku twardego. Druga technologia spowodowała problem, protokół SATA nie ma tej funkcji. Aby uzyskać te funkcje, potrzebujesz SAS, a jeśli nalegasz na dyski SATA, możesz kupić SAS na karty SATA Interposer, takie jak LSISS9252.

Udoskonalona technologia RAFF Zaawansowana elektronika monitoruje napęd i koryguje drgania liniowe i obrotowe w czasie rzeczywistym. Rezultatem jest znaczna poprawa wydajności w środowiskach o wysokiej wibracji w porównaniu do poprzedniej generacji napędów.

Ograniczone czasowo odzyskiwanie po błędzie (TLER) specyficzne dla macierzy RAID Zapobiega awarii dysku spowodowanej przez rozszerzone procesy odzyskiwania po błędzie dysku twardego wspólne dla dysków stacjonarnych.

http://en.wikipedia.org/wiki/Error_recovery_control#Overview

Zobacz także poniższy link:

http://en.wikipedia.org/wiki/Error_recovery_control#Raid_Controllers

Zobacz także: dokument Western Digital TLER szczegółowo wyjaśniający proces odzyskiwania po błędzie. Odzyskiwanie po awarii Zapobieganie opadaniu w dyskach twardych WD Caviar RAID Edition Serial ATA:

http://www.3dfxzone.it/public/files/2579-001098.pdf

Tylko zgadnij: dyski twarde są skonfigurowane tak, aby próbowały powtarzać się po błędach odczytu, a nie zgłaszać błąd. Chociaż jest to pożądane zachowanie w ustawieniach pulpitu, przynosi efekt przeciwny do zamierzonego w macierzy RAID (gdzie kontroler powinien przepisać każdy sektor, który nie może odczytać z innych dysków, aby dysk mógł go odwzorować).

mój strzał w ciemność:

• dysk 7 nie działa. ma pewne okna awarii, w których nie jest dostępne.

• dysk 8 ma również „lżejsze” błędy; poprawione przez ponowienie.

• RAID10 to zazwyczaj „RAID0 kilku par RAID1”, czy dyski 7 i 8 należą do tej samej pary?

jeśli tak, to wygląda na to, że trafiłeś w przypadek awarii dwóch dysków na tej samej parze. prawie jedyna rzecz, która może zabić RAID10. niestety może się tak zdarzyć, jeśli wszystkie dyski pochodzą z tej samej partii wysyłkowej, więc prawdopodobieństwo śmierci jednocześnie jest większe.

Wydaje mi się, że podczas awarii dysku 7 kontroler przekierował wszystkie odczyty na dysk 8, więc każda ponowna próba spowodowała duże opóźnienia, które spowodowały lawinę zamrożonych zadań, powodując chwilową utratę wydajności.

masz szczęście, że dysk 8 nie wydaje się jeszcze martwy, więc powinieneś być w stanie naprawić bez utraty danych.

Zacznę od zmiany obu dysków i nie zapomnij sprawdzić okablowania. może to powodować luźne połączenie, a jeśli nie zostanie pewnie poprowadzone, bardziej prawdopodobne jest to na sąsiednich dyskach. również niektóre karty wieloportowe mają kilka dwuportowych złączy, jeśli dysk 7 i dysk 8 są na tym samym, może to być przyczyną problemów.

Karty SATA Interposer Card to kolejne rozwiązanie.

Niedawno doświadczyłem dokładnie tego samego losu i znalazłem ten wątek. Ogólny tenor jest taki, że protokół SAS lepiej nadaje się do RAID niż SATA, ponieważ SATA nie ma funkcji. Dlatego te same dyski fizyczne są wyposażone w kontrolery SAS, a następnie sprzedawane jako Nearline SAS.

Szukając dalej, znalazłem:

http://www.lsi.com/products/storagecomponents/Pages/LSISS9252.aspx

Badam ulepszenie jednego z moich magazynów za pomocą partii. Obecnie różnica w cenie między 3 TB SATA a SAS wynosi 400% (cena waniliowa, ta sama marka, specyfikacje i sklep, Niemcy). Oczywiście nie wiem, czy ta strategia działa dobrze, ale warto spróbować.

Komentarze bardzo mile widziane :-)

Widziałem dysk SATA z uszkodzoną elektroniką solidnie blokujący inicjację oprogramowania układowego Areca 12, nie było sposobu, aby uzyskać dostęp do BIOS-u, a co dopiero uruchomić komputer z dowolnego nośnika, dopóki nie zostanie znaleziony naruszający dysk twardy poprzez wyciągnięcie dysków w pliku binarnym szukaj mody.