wikiZalecana procedura przy awarii dysku twardego w systemie z kontrolerem RAID Adaptec i ARCCONF
Artykuł ten opisuje zalecaną procedurę przy awarii dysku HDD w systemie z kontrolerem RAID Adaptec i zainstalowanym ARCCONF (Command Line Interface dla kontrolerów RAID firmy Adaptec).
Problem
W serwerze z kontrolerem RAID firmy Adaptec i zainstalowanym ARCCONF uszkodzeniu uległ jeden dysk. Następstwem tego jest przejście odpowiedniego Logical Device w stan degraded. Możliwą przyczyną awarii dysku może np. być:
- Dysk posiada większą liczbę niesprawnych sektorów. (media errors)
- Dysk nie reaguje na polecenia w czasie określonym przez kontroler. (timeout)
Uwaga: Kontroler RAID i dyski posiadają mechanizmy, które wykluczają uszkodzone sektory i zastępują je sektorami z spare area dysku. Jeśli ilość uszkodzonych sektorów przekroczy określoną granicę to kontroler nie akceptuje dysku i musi on zostać wymieniony.
Instrukcja
Krok 1: Rescan
Może się zdarzyć, że dyski, które są wprawdzie w pełni sprawne nie reagują w określonym czasie na polecenia kontrolera (timeout). W takich przypadkach dysk nie musi koniecznie być wymieniony. Dlatego powinien najpierw zostać przeprowadzony rescan w kontrolerze:
ARCCONF RESCAN <Controller#>
Przykład:
ARCCONF RESCAN 1
Jeżeli dysk jest jeszcze sprawny lub nie jest uszkodzony elektrycznie lub mechanicznie to kontroler go wykryje i zostanie wymieniony w Physical Devices:
ARCCONF GETCONFIG <Controller#> PD
Przykład:
ARCCONF GETCONFIG 1 PD
Uwaga:
Powyższy parametr przy dużej ilości dysków zwraca długi wynik, dlatego pod Linuksem może zostać skrócony do najważniejszych informacji:
arcconf getconfig 1 pd|egrep "Device #|State\>|Reported Location|Reported Channel|S.M.A.R.T. warnings"
Jeśli obszar dysku z danymi meta jest w porządku to, w większości przypadków, dysk jest wyświetlany jako członek odpowiedniego logical device. Status tego logical device jest nadal degraded, gdyż najprawdopodobniej dane nie są już zgodne. Dlatego musi zostać przeprowadzony manualnie rebuild tego logical device.
Jeśli dysk nie jest po rescanie rozpoznawany to może to mieć następujące przyczyny:
- Dysk jest uszkodzony.
- Kabel z kontrolera do dysku lub backplane'u jest uszkodzony.
- Backplane jest uszkodzony.
- Kontroler jest uszkodzony.
Krok 2: Clear i Verify
Jeśli po rescanie dysk jest znów rozpoznawany to rebuild musi zostać ręcznie zainicjalizowany. Przy czym obszar meta danych dysku musi zostać usunięty:
ARCCONF TASK START <Controller#> DEVICE <Channel#> <ID#> CLEAR
Przykład:
ARCCONF TASK START 1 DEVICE 0 0 CLEAR
Jeśli został przeprowadzony Clear-Task to następnie jest zalecane przeprowadzenie verify dysku, w celu rozpoznania potencjalnych uszkodzonych sektorów:
ARCCONF TASK START <Controller#> DEVICE <Channel#> <ID#> VERIFY
Rrzykład:
ARCCONF TASK START 1 DEVICE 0 0 VERIFY
Aby przy okazji naprawić potencjalne uszkodzone sektory zamiast opcji VERIFY może zostać wykorzystana VERIFY_FIX.
Krok 3: ponowny rescan
Teraz przy ponownym rescanie dysk powinien zostać pokazany jako dostępny i rebuild automatycznie rozpoczęty - pod warunkiem, że funkcja Automatic Failover jest włączona. Czy ta funkcja jest włączona, może zostać skontrolowane następującym poleceniem:
ARCCONF GETCONFIG <Controller#> AD
Przykład:
ARCCONF GETCONFIG 1 AD
Włączenie lub wyłączenie funkcji automatic failover:
ARCCONF FAILOVER <Controller#> <on|off>
Przykład:
ARCCONF FAILOVER 1 on
Krok 4: designated Hotspare
W przypadku, gdy funkcja Automatic Failover nie jest włączona i nie ma być włączona, to istnieje jeszcze możliwość zdefiniowania dostępnego dysku jako designated Hotspare. W ten sposób dostępny dysk może zostać przyporządkowany odpowiedniemu logical fevice i rebuild następnie rozpoczyna się automatycznie:
ARCCONF SETSTATE <Controller#> DEVICE <Channel#> <ID#> HSP LOGICALDRIVE <LD#>
Przykład:
ARCCONF SETSTATE 1 DEVICE 0 0 HSP LOGICALDRIVE 1
Linki
Adaptec RAID Controller Command Line Utility User's Guide (v6.10)
