Temat: zmienic RAID na Serwerze bez utraty danych?
Jakub Głębicki:
Wojciech Ogórek:
A gorsza od rebootu czy nawet niewstania serwera , jest sieczka na dyskach i utrata tego co na nich mamy.
Nieee, od tego to się ma tasiemki. Najgorsze to jak się kawa skończy ;)
1. Wgranie backupu z taśmy trwa dłużej , niż reboot serwera.
2. Przy taśmach mamy zwykle kopię danych sprzed kilku , kilkunastu godzin. Po rebocie serwera mamy na nim sytuację taka była przed i możemy reagować. Po naprawieniu problemu , ruszamy dalej bez cofania się o kilkanaście godzin.
3. Jeżeli serwer pójdzie w dół z powodu wykrycia jakiś problemów , to po jego uruchomieniu mamy masę informacji co się stało ( "crash dumpy" , "panic stringi" itd...) możemy zbadać co jest źródłem kłopotu. Jeżeli odtwarzamy się z taśmy to po pierwsze nie mamy żadnych danych o tym jak/kiedy i dlaczego rozpoczął się proces "rozkładu" naszych danych , po drugie nie mamy żadnej pewności, że to się nie powtórzy.
4. Koniec kawy/herbaty to jest totalny kataklizm. Tu się zgadzam w 100% ;)
I jeszcze w odpowiedzi do posta Marcina:
Marcin Bojko:
Jeżeli odnosisz się do ASR - akurat w tym modelu, to on nie działa tak jak mówisz. ASR zadziała w przypadku gdy watchdog i jego softwareowy reseter się zawieszą lub w przypadku przekroczenia temperatury następuje 'thermal shutdown'.
Nie odnoszę się do ASR, bo nie wiem co to jest :D
Kojarzy mi się RAS ale to chyba nie to...
Bazowałem na tym co wiem o serwerach SUNa (Sparcowych) + Solaris , bo z takimi miałem najwięcej do czynienia.
Ale że zajmowałem się tym jakiś czas temu + to nie była moja główna specjalizacja, więc dyskusji większej się nie podejmuję bo dam plamę ;)
System nie ma pojęcia o ilości dysków i poziomie hardware'u kontrolera - po to własnie wymyślono idęę wolumenów logicznych macierzy widocznych jako jeden hw dysk dla OS.
System widzi symptom i na niego reaguje, nawet jeżeli samo źródło jest dla niego niewidoczne.
Konkretny przykład:
Serwer ( V880 Sunowski + Solaris )w tzw "panic loopie" - czyli ciągle się resetuje.
Panic string - "Freeing free block" - system próbował zwolnić jakiś blok danych na FSie i odkrył że tam już nic nie ma. Stwierdził, że stan rzeczywisty nie odpowiada temu co on widzi, więc aby uniknąć dalszemu uszkadzaniu FSa robi reboot ( z którego potem nie umie wyjść ).
Rozwiązanie - załadowanie systemu do Single User Mode ( wchodzi ) i zrobienie fsck na kłopotliwym file systemie. Potem standardowe sprawdzenie systemu i bingo , duża ilość hard i soft błędów na jednym z dysków w RAIDie z którego wystawiony był dany LUN ( to był bodajże dysk wewnętrzny , ale już nie pamiętam czy na pewno ).
Konkluzja - System reagował na błędy FSa , mimo iż źródło było dla niego niewidoczne ( dysk w strukturze RAID )
Wiem że są rzeczy o których nie śniło się filizofom i informatykom, ale cóż, obstanę chwilowo przy swoim - padający serwer przy wypadzie dysku jest raczej wynikiem uszkodzonego backplane/mobo/power supply backplane niż regułą dotyczącą komunikacji serwera z OS.
A co do kary za 'delikatny' shutdown - prawie zawsze shutdown w przypadku kontrolera z BBWC/pamięcią write cache/ źle się kończy dla dysków, jak nie zdąży wyflushować.
Anyway - teoretyzujemy ;)
Jasne :D
Padający dysk w 99,99% powoduje potrzebę wymiany dysku twardego bez żadnych fajerwerków w stylu rebootu serwera czy rozwalenia całego RAIDa.
Ja od początku trochę teoretyzowałem ;) ( choć nie znaczy to, że nie widziałem kilku podobnych spraw "na żywo")
Wojciech Ogórek edytował(a) ten post dnia 05.08.10 o godzinie 21:08
пропозиції роботи
