Zadanie do wykonania: zautomatyzować wykonywanie migawki na macierzy Fujitsu Eternus DX80. Dostęp przez SSH do urządzenia jest, więc zacząłem od zaimportowania klucza, by ‘przeskoczyć’ logowanie. Niestety wykonanie komendy przez SSH kończy się niepowodzeniem. Wygląda to mniej więcej tak:
[...]
debug1: Entering interactive session.
debug1: Sending command: show advanced-copy-sessions
debug1: channel 0: free: client-session, nchannels 1
Connection to dx80 closed by remote host.
Próbowałem allokować pseudo-tty (-t), ale to też nic nie daje. Czekam na informację, jeśli ktoś zna rozwiązanie tego problemu. Serwer SSH na urządzeniu przedstawia się tak: SSH-1.99-IPSSH-6.5.0. Potrzebnych więcej szczegółów?
Tymczasem postanowiłem obejść problem za pomocą oprogramowania expect. Narzędzie to stworzone jest do automatyzacji interaktywnych aplikacji takich jak telnet, ftp, passwd, itp. Najprostsze użycie (tak jak w moim przypadku) to wysłanie ‘odpowiedzi’ w zależności od tego, co dostaniemy (np. Login:, passwd:, CLI>, itp.).
Mój wspomniany plik z komendami wygląda tak:
spawn ssh dx80
expect "CLI>"
send "start advanced-copy -source-volume-name backup -destination-volume-name snapshot\r"
# expect "CLI>"
# send "show advanced-copy-sessions\r"
expect "CLI>"
send "exit"
Uruchamiając migawkę na DX80 przy podaniu źródłowego i docelowego wolumenu takiego jak wcześniejsza sesja, automatycznie tamta sesja jest zatrzymywana. Stąd uproszczenie skryptu do jednej komendy start advanced-copy. Oczywiście taki zasób należy odmontować i zamontować ponownie, by ‘odświeżyć’ jego zawartość.
Zauważyłem jeszcze dziwny objaw tej macierzy. Przy przepełnieniu migawki staje się ona bezużyteczna, co jest dość normalne i oczywiste, ale źródłowy wolumen zgłasza błędy i serwer przemontowuje go w trybie tylko do odczytu!
May 10 01:42:58 localhost kernel: sd 6:0:1:30: SCSI error: return code = 0x08000002
May 10 01:42:58 localhost kernel: sdo: Current: sense key: Hardware Error
May 10 01:42:58 localhost kernel: ASC=0x26 <> ASCQ=0xc0
May 10 01:42:58 localhost kernel:
May 10 01:42:58 localhost kernel: Info fld=0x6a0ebd81
May 10 01:42:58 localhost kernel: end_request: I/O error, dev sdo, sector 2176650858
May 10 01:42:58 localhost kernel: printk: 4 messages suppressed.
May 10 01:42:58 localhost kernel: Buffer I/O error on device sdo1, logical block 272081353
May 10 01:42:58 localhost kernel: lost page write due to I/O error on sdo1
May 10 01:42:58 localhost kernel: Buffer I/O error on device sdo1, logical block 272081354
May 10 01:42:58 localhost kernel: lost page write due to I/O error on sdo1
May 10 01:42:58 localhost kernel: Buffer I/O error on device sdo1, logical block 272081355
May 10 01:42:58 localhost kernel: lost page write due to I/O error on sdo1
May 10 01:42:58 localhost kernel: Buffer I/O error on device sdo1, logical block 272081356
May 10 01:42:58 localhost kernel: lost page write due to I/O error on sdo1
May 10 01:42:58 localhost kernel: Buffer I/O error on device sdo1, logical block 272081357
May 10 01:42:58 localhost kernel: lost page write due to I/O error on sdo1
May 10 01:42:58 localhost kernel: Buffer I/O error on device sdo1, logical block 272081358
May 10 01:42:58 localhost kernel: lost page write due to I/O error on sdo1
May 10 01:42:58 localhost kernel: Buffer I/O error on device sdo1, logical block 272081359
May 10 01:42:58 localhost kernel: lost page write due to I/O error on sdo1
May 10 01:42:58 localhost kernel: Buffer I/O error on device sdo1, logical block 272081360
May 10 01:42:58 localhost kernel: lost page write due to I/O error on sdo1
May 10 01:42:58 localhost kernel: Buffer I/O error on device sdo1, logical block 272081361
May 10 01:42:58 localhost kernel: lost page write due to I/O error on sdo1
May 10 01:42:58 localhost kernel: Buffer I/O error on device sdo1, logical block 272081362
May 10 01:42:58 localhost kernel: lost page write due to I/O error on sdo1
May 10 01:44:34 localhost kernel: Aborting journal on device sdo1.
May 10 01:44:34 localhost kernel: ext3_abort called.
May 10 01:44:34 localhost kernel: EXT3-fs error (device sdo1): ext3_journal_start_sb: Detected aborted journal
May 10 01:44:34 localhost kernel: Remounting filesystem read-only
May 10 01:44:34 localhost kernel: __journal_remove_journal_head: freeing b_committed_data
May 10 01:46:14 localhost last message repeated 62 times
May 10 01:46:14 localhost last message repeated 51 times
May 10 01:46:14 localhost kernel: __journal_remove_journal_head: freeing b_frozen_data
May 10 01:46:14 localhost last message repeated 2 times
May 10 01:46:14 localhost kernel: __journal_remove_journal_head: freeing b_committed_data
May 10 01:46:14 localhost kernel: __journal_remove_journal_head: freeing b_frozen_data
Po tym zwykły remount w trybie RW się nie udał:
May 10 06:52:39 localhost kernel: ext3_abort called.
May 10 06:52:39 localhost kernel: EXT3-fs error (device sdo1): ext3_remount: Abort forced by user
I skończyło się na odłączeniu, usunięciu migawki i ponownym podłączeniu zasobu:
May 10 07:50:08 localhost kernel: ext3_abort called.
May 10 07:50:08 localhost kernel: EXT3-fs error (device sdo1): ext3_put_super: Couldn't clean up the journal
May 10 07:50:26 localhost kernel: kjournald starting. Commit interval 5 seconds
May 10 07:50:26 localhost kernel: EXT3-fs warning (device sdo1): ext3_clear_journal_err: Filesystem error recorded from previous mount: IO failure
May 10 07:50:26 localhost kernel: EXT3-fs warning (device sdo1): ext3_clear_journal_err: Marking fs in need of filesystem check.
May 10 07:50:26 localhost kernel: EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
May 10 07:50:26 localhost kernel: EXT3 FS on sdo1, internal journal
May 10 07:50:26 localhost kernel: EXT3-fs: recovery complete.
May 10 07:50:26 localhost kernel: EXT3-fs: mounted filesystem with ordered data mode.
Przytrafiło mi się to dwa razy i to na jednej z dwóch maszyn, więc nie wiem czy podany powód jest dobry. Ciągle to testuję.
Tagi: expect, Fujitsu Eternus DX80
Sytuacja z przemontowaniem zasobów dzieje się na:
Red Hat Enterprise Linux Server release 5.5 (Tikanga) 2.6.18-194.el5
ale na:
Red Hat Enterprise Linux Server release 5.3 (Tikanga) 2.6.18-128.el5
już nie. I jest powtarzalna.
Na razie tyle, szukam dalej.
Witam,
Panie Bartłomieju jak długo Pan posiada tą macierz i jak się ona u Pana sprawuje? Przymierzamy się w firmie do zakupu tej macierzy i podłączenia jej do XenServera jako storage. Podobno w czerwcu ma wyjść jakiś zaktualizowana wersja tej macierzy…
Rzeczywiście w czerwcu ma być dostępna w sprzedaży linia S2 (premiera jeszcze w Dzień Matki, ale Fujitsu nie zaleca kupna na prezent) – w zeszłym tygodniu brałem udział w spotkaniu organizowanym przez jednego z polskich dystrybutorów i producenta, gdzie wspominano o tym.
Podobno S1 ma zejść w dół jeśli chodzi o cenę, S2 będą na pewno droższe niż S1 teraz. Jeśli ma się kontakty w Fujitsu lub u któregoś dystrybutora, można zapytać o wyprzedaże z lab’ów – zawsze to parę PLN w dół, choć z drugiej strony to sprzęt intensywnie używany.
S2 to głównie SAS 2.0, stąd dyski (i prawdopodobnie półki) nie będą kompatybilne.
Jeśli chodzi o użytkowanie, to problemów nie napotkałem jakichś szczególnych. Na plus na pewno to, że w standardzie można zrobić do 8 migawek (ale pewnie pod XenServer będzie LVM, więc to nie jest istotne). A’propos migawek, to boli mnie to, że nie da się zrobić powiadomienia o przepełnieniu – wykonalne tylko dla puli via snmptrap. W ogóle akcje z ‘Advanced Copy’ (tworzenie, usuwanie) nie zapisują się w ogóle w logach!
Nie mam własnych porównań wydajnościowych, bo używałem ledwie kilkunastu różnych urządzeń i to na przestrzeni czasu, a jak jednocześnie, to z różnych półek. Ta działa. Osobiście mam dostęp do niej od początku roku, ale chyba ma rok (pracuje z dodatkowymi półkami SAS i SATA).
Mam jeszcze jakiś problem z migawkami na DX80 jeśli migawki są robione z tego samego wolumenu źródłowego. Nie doszedłem jeszcze do żadnej prawidłowości, drążę dalej temat.
[...] Jeśli myślimy o skryptach, które to zautomatyzują, możemy wybrać również expect. [...]
[...] jakiegoś czasu używam macierzy Hitachi AMS2100 i Fujitsu DX80 (pisałem wcześniej o niej w kontekście automatyzacji migawek). Obie połączone są wieloma ścieżkami FC do serwerów. Na [...]