SSDに関する検証 その12

<緊急特集!!SSDに関する検証 その12>
ペンネーム: ミラニスタ

磁気ディスクの代わりに半導体メモリにデータを記録するストレージ装置
SSD (Solid State Disk) の検証を行っています。

検証製品(富士ゼロックス株式会社様製 GigaExpress)の紹介URL⇒
http://www.fujixerox.co.jp/product/gigaexpress/

▼ 前回のおさらい

mdadm でアレイを組んだ(2台の)SSD(サーバからは /dev/md0 という1つ
のマウント先として認識されます。)に UNDO および REDO を配置し、更新処
理中に片側 SSD の電源を OFF/ON としてみました。

電源瞬断という SSD にとっては、データ損失を伴う致命的な障害が発生し
たにも関わらず、更新処理は無事に終了しました。

ただし、障害が発生した側の SSD は読み書きができない状態となっている
ため、このままでは正常なもう片方に障害が発生してしまうと、データベース
は壊れてしまいます。

▼ リカバリする

1. 状況の確認

  # 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

この状況で、fdisk コマンドで /dev/sdc に対してパーティション操作を行
うことができるかどうか確認してみます。

  # fdisk /dev/sdc
  
  /dev/sdc を読めません

どうやら、サーバがデバイス自体を認識していないようです。
さて、どうやって認識させればよいのでしょうか?

実は GigaExpress は、「ホット・プラグ」あるいは「ホット・スワップ」に対
応していません。

従って、再認識させるためにはサーバのリブートが必要です。

2. インスタンスの停止

しかし、Oracleは今動いている状態ですから、normal か immediate で一旦
停止させましょう。

  SQL> shutdown immediate
  データベースがクローズされました。
  データベースがディスマウントされました。
  ORACLEインスタンスがシャットダウンされました。

3. ファイルのバックアップ

また、念のためアレイに置いてあるファイルのバックアップを取っておきま
しょう。

  $ df -k
  Filesystem  1K-ブロック    使用   使用可 使用% マウント位置
  /dev/md0     16255800   1247708  14182348   9% /oracle/app/oracle/oradata/ssd

  $ cd /oracle/app/oracle/oradata/ssd
  $ ls -l
  合計 1203392
  -rw-r-----  1 oracle oinstall   52429312  9月  x 19:30 redo04.log
  -rw-r-----  1 oracle oinstall   52429312  9月  x 19:30 redo05.log
  -rw-r-----  1 oracle oinstall   52429312  9月  x 19:54 redo06.log
  -rw-r-----  1 oracle oinstall 1073750016  9月  x 19:54 undo_ssd01.dbf

  $ cp -p * /var/backup

4. サーバのリブート

これでやっとサーバのリブートができます。

  # sync
  # sync
  # sync
  # shutdown -r now

このまま、サーバが無事再起動してくるのを待ちましょう。

5. パーティションの作成

リブートによって、/dev/sdc が認識されるようになったので、fdisk コマ
ンドでパーティションを作成します。

  # /sbin/fdisk /dev/sdc

  ......................................
  コマンド (m でヘルプ): n
  コマンドアクション
     e   拡張
     p   基本領域 (1-4)
  p
  領域番号 (1-4): 1
  最初 シリンダ (1-16128, 初期値 1):
  初期値 1 を使います
  終点 シリンダ または +サイズ または +サイズM または +サイズK (1-16128, 初期値 16128):
  初期値 16128 を使います

  コマンド (m でヘルプ): w
  領域テーブルは交換されました!

  ioctl() を呼び出して領域テーブルを再読込みします。
  ディスクを同期させます。

  作成したパーティションの状況を確認します。

  # fdisk -l

  .............................................................
  
  Disk /dev/sdb: 16.9 GB, 16911433728 bytes
  64 heads, 32 sectors/track, 16128 cylinders
  Units = シリンダ数 of 2048 * 512 = 1048576 bytes

   デバイス Boot      Start         End      Blocks   Id  System
  /dev/sdb1               1       16128    16515056   83  Linux
  
  Disk /dev/sdc: 16.9 GB, 16911433728 bytes
  64 heads, 32 sectors/track, 16128 cylinders
  Units = シリンダ数 of 2048 * 512 = 1048576 bytes
  
   デバイス Boot      Start         End      Blocks   Id  System
  /dev/sdc1               1       16128    16515056   83  Linux

6. アレイの再作成

  # mdadm --create /dev/md0 --level=raid1 --raid-devices=2 /dev/sdb1 /dev/sdc1
  mdadm: /dev/sdc1 appears to contain an ext2fs file system
      size=16514944K  mtime=Mon Sep XX 20:58:09 2007
  mdadm: /dev/sdc1 appears to be part of a raid array:
      level=1 devices=2 ctime=Mon Sep XX 20:56:15 2007
  Continue creating array? yes    ←入力
  mdadm: array /dev/md0 started.


  # mdadm -D /dev/md0
  /dev/md0:
          Version : 00.90.01
    Creation Time : Mon Sep xx 20:58:09 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 Sep xx 20:58:09 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

最終的に「State : clean」を確認

7. アレイのマウント

再作成したアレイを元のようにマウントします。

  # mount /dev/md0 /oracle/app/oracle/oradata/ssd

マウントしたら、ファイルが存在しているか確認します。

  # cd /oracle/app/oracle/oradata/ssd
  # ls -l
  合計 1203392
  -rw-r-----  1 oracle oinstall   52429312  9月  x 19:30 redo04.log
  -rw-r-----  1 oracle oinstall   52429312  9月  x 19:30 redo05.log
  -rw-r-----  1 oracle oinstall   52429312  9月  x 19:54 redo06.log
  -rw-r-----  1 oracle oinstall 1073750016  9月  x 19:54 undo_ssd01.dbf

何度も確認をしましたが、片方の SSD が故障しただけの状態では、生き
残ったほうの SSD にはデータはまだ存在しています。(電源が入っていれば)

従って、6. で再度アレイを組むと、復活したデバイス(/dev/sdc)への同
期が始まり、最終的にミラーリングが完成します。

念には念を入れ、3. でバックアップを取得しましたが、実際にファイルが
壊れてしまってバックアップから戻さなければならないようなことは(検証し
ている中では)発生しませんでした。

8. インスタンス再起動

$ sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 – Production on 月 9月 xx 21:04:44 2007

Copyright (c) 1982, 2005, Oracle. All rights reserved.

SQL> conn / as sysdba
アイドル・インスタンスに接続しました。
SQL> startup
ORACLEインスタンスが起動しました。

Total System Global Area 536870912 bytes
Fixed Size 1220408 bytes
Variable Size 113246408 bytes
Database Buffers 415236096 bytes
Redo Buffers 7168000 bytes
データベースがマウントされました。
データベースがオープンされました。
[/bash]

これで、リカバリの完了です!!

▼ まとめ

2台の SSD でアレイを組んでいる状態での、障害発生からのリカバリ要領を
おさらいしておきます。

1. 状況の確認
どちらの SSD に障害が起きているのかを見極めます。間違って正常な方を
操作してしまうと取り返しのつかないことになります。
正常な SSD は電源がある限り、データを保持しています。

2. インスタンスの停止
サーバをリブートする前に、インスタンスを正常に停止させます。

3. ファイルのバックアップ
念のため、アレイ上のファイルのバックアップを取っておきましょう。
(オフラインバックアップ)

4. サーバのリブート
SSD を再認識させるために、サーバのリブートを行います。

5. パーティションの作成
アレイを組む前に、パーティションを作成します。

6. アレイの再作成
アレイを再構成することにより、2台の SSD を同期させます。

7. アレイのマウント
復活させたアレイをマウントし、インスタンスの再起動に備えます。

8. インスタンス再起動
インスタンスの再起動に成功すれば、リカバリは完了です。

いかがでしょうか。万一 SSD が故障したとしても、落ち着いて対応すれば
データを消失することなく、システムを復旧させることができます。

実際は、一連の操作をスクリプト化しておけば、オペレーションミスも防ぐ
ことができるでしょう。

ところで、GigaExpress がホットプラグ対応であれば、上記 2 と 4 の手順
は不要になります。つまり、サービスを停止することなく復旧が可能になりま
す。
富士ゼロックス様にこの点を確認したところ、技術的には可能なので次期リ
リース製品はホットプラグ対応になるとのことでした。

今回で SSD に関する検証を終える予定でしたが、全体のまとめをすること
ができませんでしたので、次回を本当の最終回としたいと思います。

FIFAクラブワールドカップ ジャパン 2007のA.C.ミラン戦、チケット買っ
ちゃいました! ボス、12月13日は休ませていただきます!!

台風は大変でした!の 茅ヶ崎にて