SSDに関する検証　その１１

＜緊急特集！！SSDに関する検証　その１１＞
ペンネーム：ミラニスタ

磁気ディスクの代わりに半導体メモリにデータを記録するストレージ装置
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

２つのデバイスが完全に同期されると。。。

———————————————-
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に関する検証　その２」
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は動き続けているということ
です。落ち着いて対処しましょう。

さあ、この状況でどのようにリカバリをすればよいのでしょうか？

次回（多分最終回）に期待してください！！

ユベントス、セリエＡ復帰後いきなり首位。Ａ．Ｃ．ミランは３位です。

ちょっと涼しくなった　茅ヶ崎にて

SSDに関する検証 その１１