SSDに関する検証 その11
<緊急特集!!SSDに関する検証 その11>
ペンネーム: ミラニスタ
磁気ディスクの代わりに半導体メモリにデータを記録するストレージ装置
SSD (Solid State Disk) の検証を行っています。
検証製品(富士ゼロックス株式会社様製 GigaExpress)の紹介URL⇒
http://www.fujixerox.co.jp/product/gigaexpress/
▼ 前回のおさらい
前回は、Linux のソフトウェア RAID である「mdadm」というツールを使っ
て SSD のミラーリングを行ってみました。
1. パーティションの準備
2. 新規アレイの作成(mdadm –create)
3. パーティションのフォーマット
4. パーティションのマウント
前回より詳細なステータス確認の方法がありましたので紹介します。
「mdadm -D 」
(例:アレイ作成直後) # mdadm -D /dev/md0 /dev/md0: Version : 00.90.01 Creation Time : Mon Aug xx 19:23:37 2007 Raid Level : raid1 Array Size : 16514944 (15.75 GiB 16.91 GB) Device Size : 16514944 (15.75 GiB 16.91 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Mon Aug xx 19:23:37 2007 State : clean, recovering ←注:(再)構成処理実施中 Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Rebuild Status : 48% complete ←注:処理の進行状況 Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 1 8 33 1 active sync /dev/sdc1 UUID : e6ce2ba3:c8b4edfc:5b6bcf3d:0498d181 Events : 0.1
2つのデバイスが完全に同期されると。。。
———————————————-
Update Time : Mon Aug xx 19:25:01 2007
State : clean
———————————————-
のようになります。
(Update Time – Creation Time)が、再構成の所要時間となります。
▼ UNDO 表領域と REDO ログファイルを SSD 上に置いてみる。
まず、検証用の UNDO 表領域(UNDO_SSD, 1024MB)を作成します。
SQL> CREATE UNDO TABLESPACE UNDO_SSD DATAFILE '/.../ssd/undo_ssd01.dbf' SIZE 1024M REUSE EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT MANUAL;
次に、作成した表領域をインスタンス起動時に使用する UNDO 表領域に指定
します。
SQL> ALTER SYSTEM SET UNDO_TABLESPACE=UNDO_SSD; システムが変更されました。
念のため、インスタンスを再起動しておきましょう。
SQL> shutdown immediate データベースがクローズされました。 データベースがディスマウントされました。 ORACLEインスタンスがシャットダウンされました。 SQL> startup ORACLEインスタンスが起動しました。 SQL> show parameter undo_tablespace NAME TYPE VALUE -------------------- ----------- ----------- undo_tablespace string UNDO_SSD
REDO ログファイルを SSD 上に配置する手順は割愛します。
(「SSDに関する検証 その2」
https://old.insight-tec.com/mailmagazine/ora3/vol344.html
を参照してください。)
▼ 時間がかかる Update 文の途中で電源障害を模擬してみる!
それでは、
SQL> select count(*) from emp; COUNT(*) ---------- 1835008 ←emp 表の件数を増やした。 SQL> update emp set sal=sal*2; ←全員の給料を倍にしてみる!! ===== SSD(/dev/sdc) のスイッチを OFF & ON(電源瞬断を模擬) ===== 1835008行が更新されました。 ←処理は正常に終了!! 経過: 00:02:05.57
どうでしょう。ミラーリングのおかげで、更新処理は電源瞬断の影響を受け
ることなく終了しました!!
障害も恐れるに足りません。
▼ 実際にどんな状態になっていたのか?
更新処理は無事に終わりましたが、SSD にとっては重大な電源瞬断が起きて
いるので、何らかの事象は起きていたはずです。
それでは、/var/log/messeges にどんなメッセージが現れていたかを確認し
てみましょう。
..................................................................................................... Aug xx 20:17:34 fxserver1 kernel: fxssdduo: TERR-interrupt occured. (host1: IR=0xFFFFFFFF, intr_terr=1) Aug xx 20:17:34 fxserver1 kernel: fxssdduo: error: fxssd_notice_hw_status: OOB-link timedout. Aug xx 20:17:34 fxserver1 kernel: fxssdduo: error: do_fxssd_intr: host1: FATAL ERROR. Aug xx 20:17:34 fxserver1 kernel: fxssdduo: error: fatal_error occured. ignore WRTIE_10-cmd. Aug xx 20:17:34 fxserver1 last message repeated 4 times Aug xx 20:17:34 fxserver1 kernel: SCSI error : <2 0 0 0> return code = 0x70002 Aug xx 20:17:34 fxserver1 kernel: end_request: I/O error, dev sdc, sector 33029920 Aug xx 20:17:34 fxserver1 kernel: md: write_disk_sb failed for device sdc1 Aug xx 20:17:34 fxserver1 kernel: fxssdduo: TERR-interrupt occured. (host1: IR=0xFFFFFFFF, intr_terr=2) Aug xx 20:17:34 fxserver1 kernel: fxssdduo: error: fxssd_notice_hw_status: OOB-link timedout. Aug xx 20:17:35 fxserver1 kernel: fxssdduo: error: do_fxssd_intr: host1: FATAL ERROR. Aug xx 20:17:35 fxserver1 kernel: md: errors occurred during superblock update, repeating Aug xx 20:17:35 fxserver1 kernel: fxssdduo: error: fatal_error occured. ignore WRTIE_10-cmd. Aug xx 20:17:35 fxserver1 last message repeated 4 times Aug xx 20:17:35 fxserver1 kernel: SCSI error : <2 0 0 0> return code = 0x70002 Aug xx 20:17:35 fxserver1 kernel: end_request: I/O error, dev sdc, sector 33029920 Aug xx 20:17:35 fxserver1 kernel: md: write_disk_sb failed for device sdc1 Aug xx 20:17:35 fxserver1 kernel: fxssdduo: TERR-interrupt occured. (host1: IR=0xFFFFFFFF, intr_terr=3) Aug xx 20:17:35 fxserver1 kernel: fxssdduo: error: fxssd_notice_hw_status: OOB-link timedout. Aug xx 20:17:35 fxserver1 kernel: fxssdduo: error: do_fxssd_intr: host1: FATAL ERROR. Aug xx 20:17:35 fxserver1 kernel: md: errors occurred during superblock update, repeating Aug xx 20:17:35 fxserver1 kernel: fxssdduo: error: fatal_error occured. ignore WRTIE_10-cmd. Aug xx 20:17:35 fxserver1 last message repeated 4 times Aug xx 20:17:35 fxserver1 kernel: SCSI error : <2 0 0 0> return code = 0x70002 Aug xx 20:17:35 fxserver1 kernel: end_request: I/O error, dev sdc, sector 33029920 Aug xx 20:17:35 fxserver1 kernel: md: write_disk_sb failed for device sdc1 .....................................................................................................
20:17:34 以降に、
「fxssd_notice_hw_status: OOB-link timedout.」というメッセージを含む大
量のアラートが発生しています。
「I/O error, dev sdc, sector …」というようなメッセージも確認できま
す。
これらは、サーバから SSD(/dev/sdc)が見えなくなったということを意味して
います。
もし、SSD の異常を監視するのであれば、これらの文字列を監視対象とすれば
よさそうです。
次に、アレイの状況も確認しておきましょう。
# mdadm -D /dev/md0 /dev/md0: Version : 00.90.01 Creation Time : Mon Aug xx 19:47:57 2007 Raid Level : raid1 ....................................................... Update Time : Mon Aug xx 20:21:03 2007 State : clean, degraded ....................................................... Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 1 0 0 -1 removed 2 8 33 -1 faulty /dev/sdc1 UUID : 8e4a1ad0:0c3dfcc2:e99566ab:6c8684d2 Events : 0.2624
やはり、/dev/sdc1 に異常が起きていることが確認できます。
ついでに、iostat の状況も見ておきましょう。
....................................................... 時間: 20時17分34秒 CPU平均: %user %nice %sys %iowait %idle 0.14 0.00 0.14 6.42 93.30 デバイス: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 0.00 2.29 23.43 20.57 704.00 3076.57 352.00 1538.29 85.92 0.29 6.56 5.60 24.63 sdb 0.00 0.00 0.57 267.43 4.57 4235.43 2.29 2117.71 15.82 0.04 0.16 0.03 0.69 sdc 0.00 0.00 1.14 267.43 9.14 4235.43 4.57 2117.71 15.80 0.05 0.18 0.03 0.69 md0 0.00 0.00 1.71 264.00 13.71 4208.00 6.86 2104.00 15.89 0.00 0.00 0.00 0.00 時間: 20時17分36秒 CPU平均: %user %nice %sys %iowait %idle 18.18 0.00 2.53 29.92 49.37 デバイス: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 0.00 21.21 6.57 113.64 210.10 9656.57 105.05 4828.28 82.08 2.12 17.46 8.19 98.43 sdb 0.00 28.28 1.01 2572.22 1.01 40403.54 0.51 20201.77 15.70 1.53 0.60 0.02 6.31 sdc 0.00 0.00 0.00 51.01 0.00 404.55 0.00 202.27 7.93 0.00 0.02 0.02 0.10 md0 0.00 0.00 1.01 2512.63 1.01 39700.51 0.51 19850.25 15.79 0.00 0.00 0.00 0.00 時間: 20時17分38秒 CPU平均: %user %nice %sys %iowait %idle 2.81 0.00 0.51 25.54 71.14 デバイス: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 0.00 19.90 7.14 125.00 228.57 1726.53 114.29 863.27 14.80 2.11 16.07 7.73 102.09 sdb 0.00 2.55 0.00 467.35 0.00 7373.47 0.00 3686.73 15.78 0.24 0.52 0.03 1.33 sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 md0 0.00 0.00 0.00 462.76 0.00 7316.33 0.00 3658.16 15.81 0.00 0.00 0.00 0.00 .......................................................
20:17:38 以降 sdc の値がすべて 0 になっています。
大事なのは、冗長化が崩れたとはいえ、Oracleは動き続けているということ
です。落ち着いて対処しましょう。
さあ、この状況でどのようにリカバリをすればよいのでしょうか?
次回(多分最終回)に期待してください!!
ユベントス、セリエA復帰後いきなり首位。A.C.ミランは3位です。
ちょっと涼しくなった 茅ヶ崎にて