ASMLibに関する検証　その３

＜ASMLibに関する検証　その３＞
ペンネーム：ソラ

今回も引き続き、ASMLib Kernel Driver(以下、ASMLib)に関する検証を行いま
す。

■前回までのおさらい
ASMLibには以下2つのメリットがあります。
[メリット]
1.ASMディスクの管理・検出が簡単になる
2.I/O処理の効率がよくなる

前回はメリット1の検証のために、ASMLibとRAWデバイスを使用した際のイン
ストール手順の違いを確認しました。

確認の結果、ASMLibは設定するディスク・パーティションが多い環境でこそ、
より効果を発揮する(手順数、正確性、管理性が向上する)ことがわかりまし
た。

今回も引き続きメリット1についての検証です。
実際に運用をしていく上でASMLibを使用しているとどのような場面で効果があ
るのでしょうか？
それでは、運用中の管理性のメリットについて検証します。

■■■■■概要■■■■■
１.運用中の管理性とは
２.ASMディスクの追加手順の確認
３.まとめ

■環境
Red Hat Enterprise Linux Server release 4
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0

１.運用中の管理性とは
まず、運用中にASMディスクに対して行う可能性がある作業を確認します。
[運用中にASMディスクに対して行う作業]
(1) ASMディスク・グループの追加
(2) ASMディスク・グループの削除
(3) 既存のASMディスク・グループに対する、ASMディスクの追加
(4) 既存のASMディスク・グループに対する、ASMディスクの削除

(1)については、前回、ASMLibを使用した場合とRAWデバイスを使用している場
合のOracleインストール手順の違いを確認した際にDBCAでASMディスク・グ
ループの作成を行っているため、ほぼ確認はできています。
また、削除自体はあまり実際の業務では行わないため、メリットとして
感じる場面は少ないでしょう。

そのため、今回は(3)の手順を前回と同様にRAWデバイスを使用している場
合と、ASMLibを使用している場合の手順を比較しながら確認します。

２.ASMディスクの追加手順の確認
それでは、(3)の手順でASMLibを使用している場合と、RAWデバイスを使用して
いる場合でASMディスクの追加手順にどのような違いがあるか確認します。

以下、ASMLibとRAWデバイスの場合で、ディスク・パーティションをASMディス
クとして使用するために必要になる手順です。

[必要な作業(RAWデバイス)]
1．RAWデバイスファイルの編集
2．RAWデバイスサービスへのマッピング
3．RAWデバイスの初期化
4．RAWデバイスのオーナー変更
5．RAWデバイスの権限変更
6．RAWデバイスのパーティション権限設定
7．ASMディスクの追加

[必要な作業(ASMLib)]
1．ASMディスク・パーティションのマーキング
2．ASMディスクの追加

RAWデバイスの場合で必要になる作業は、ASMディスクの追加の手順以外はイン
ストール時の手順とほぼ同じです。
しかし、ASMLibの場合はASMLibのインストール手順がなくなります。
ASMLibのインストール作業は前回の検証で確認したように、非常に面倒な作業
でした。そのため、この時点で既にASMLibのほうが作業が簡単になりそうなこ
とがわかります。それでは、実際にどれくらいの違いがあるのか、手順を追い
ながら確認します。

▼RAWデバイスを使用している場合の手順(/dev/raw/raw2を追加)
1．RAWデバイスファイルの編集
まず、前回と同様にRAWデバイスとディスク・パーティションのマッピング
から行います。

  # vi /etc/sysconfig/rawdevices
   /dev/raw/raw2   /dev/sdb2                                ##編集内容

2．RAWデバイスサービスへのマッピング
次に、RAWデバイスサービスへのマッピングです。
インストール時はRAWデバイスサービスの起動で行いましたが、今回は運用
中でサービスの停止を行えない場合であれば、RAWデバイスサービスの再起
動は行えません。

そのため、RAWコマンドを使用してディスク・パーティションを実際にRAWデ
バイスサービスへマッピングします。

  # raw /dev/raw/raw2 /dev/sdb2

マッピングが終了したら、前回と同様にRAWデバイスのマッピング正常に行
われているか確認します。

major番号, minor番号を確認することで、バインドされているブロックデバ
イスを確認できます。

  # raw -qa
   /dev/raw/raw1:  bound to major 8, minor 17
   /dev/raw/raw2:  bound to major 8, minor 18

以下のコマンドでmajor番号, minor番号を調べられます。

  # ls -l /dev/sdb*
   brw-r----- 1 root disk 8, 16 Dec 30 13:25 /dev/sdb
   brw-r----- 1 root disk 8, 17 Dec 30 13:29 /dev/sdb1
   brw-r----- 1 root disk 8, 18 Dec 30 13:29 /dev/sdb2

「/dev/sdb2」はmajor番号8, minor番号18なので、無事にマッピングは成功
しています。

3～6の手順はOracleインストール時の手順と全く同じため、コマンドだけ記
載します。

3．RAWデバイスの初期化

   # dd if=/dev/zero of=/dev/raw/raw2 bs=1024k count=100

4．RAWデバイスのオーナー変更

   # chown oracle:dba /dev/raw/raw2

5．RAWデバイスの権限変更

   # chmod 600 /dev/raw/raw2

6．RAWデバイスの権限設定

   # vi /etc/udev/permissions.d/oracle.permissions
    raw/raw2:oracle:dba:0600                                ##編集内容

7.ASMディスクの追加
それでは、ASMディスク・グループにASMディスクを追加します。
まず、ASMインスタンスにSQL*Plusを使用してログインします。

   $ export ORACLE_SID=+ASM
   $ sqlplus "/ as sysdba"

次に、実際にASMディスクの追加を行います。
以下のような、ALTER文でASMディスクを追加できます。

SQL? alter diskgroup DATA1 add disk '/dev/raw/raw2';
Diskgroup altered.

ASMディスクの追加が完了したら、確認をします。

SQL> select name,path from v$asm_disk;
NAME     PATH
-------- -------------
DG1_0001 /dev/raw/raw2
DG1_0000 /dev/raw/raw1

SQL文の結果から「/dev/raw/raw2」が追加されていることがわかります。

ただ、インストール時もそうでしたが、「/dev/raw/raw*」という表記は、
環境定義書のような資料なしでは、何に使用するものか少しわかりづらいで
す。

以上でRAWデバイスを使用している場合の、ASMディスクの追加手順は終了で
す。

やや手順数は減りましたが、インストール時の手順とほぼ変わりありませ
ん。

それでは、次にASMLibを使用している場合はどのような手順になるか確認し
ます。

▼ASMLibを使用している場合の手順(DATA2を追加)
1．ASMディスク・パーティションのマーキング
まず、前回の手順と同様にOracleがディスクをASM用のディスクとして使用
できるようにASMディスク・パーティションのマーキングをします。

# /etc/init.d/oracleasm createdisk DATA /dev/sdb2
Marking disk "DATA" as an ASM disk:                        [  OK  ]

2.ASMディスクの追加
次に、ASMディスク・グループにASMディスクを追加します。
まず、RAWデバイスの時と同様にASMインスタンスにSQL*Plusを使用してログ
インします。

$ export ORACLE_SID=+ASM
$ sqlplus "/ as sysdba"

次に、ASMディスク・グループにASMディスクを追加します。

SQL> alter diskgroup DISKGROUP1 add disk 'ORCL:DATA2';
Diskgroup altered.

追加が完了したら、RAWデバイスの時と同様に追加したASMディスクを確認
します。

SQL> select name,path from v$asm_disk;
NAME  PATH
----- ----------
DATA1 ORCL:DATA1
DATA2 ORCL:DATA2

Oracleのインストール時もそうでしたが、「DATA2」のようにラベルを付け
られるほうがASMディスク・グループやASMディスクの数が多い場合ではラ
ベルの付け方の工夫次第で運用者からもわかりやすくなるため、ASMディス
クを管理しやすくなります。

以上でASMディスクの追加手順は終了です。
単純に実行したコマンド数だけで比較しても、RAWデバイスを使用している場
合は12回、ASMLibを使用している場合では5回とASMLibを使用している場合の
ほうが、明らかに手順が簡単になっています。

３.まとめ
それでは、前回と同様に以下3点について考察します。
1.手順数
2.正確性
3.管理性

1.手順数
既にASMLibやRAWデバイスを使用している環境では、ASMLibの場合はインス
トール時にネックとなっていたASMLibのインストールに関連する作業が
必要なくなるため、ディスク・パーティションを一つだけ追加するような
場面においてもASMLibのほうが手順数が少なくなります。

2.正確性
これは、前回のインストール時の手順の違いでも触れていますが、ASMLib
の場合、ディスク・パーティションの所有者、権限、再起動時の設定など
を一つのシェルで行えるため、手順の間違いが起こりにくくなります。
RAWデバイスの場合もシェルを作成することで、同様の効果は実現できます
が、実際にはシェルを作成する工数を考えると難しい場合もあります。
したがって、ASMLibを使用したほうが正確性が向上すると言えます。

3.管理性
「ASMディスクの追加」の手順でASMLibの場合はラベルを使用した指定をで
きるため、工夫次第で前回のDBCAでのディスク・パーティションの追加と同
様に追加時のSQL文を作成する際にどのディスク・パーティションを追加す
るか非常にわかりやすくできます。
また、ALETER文でNAME句を指定しなかった場合、RAWデバイスではデフォル
トの名前(_)が使用されます。
ASMディスクを削除するような場面ではASMディスク名を指定する必要があり
ます。そのため、わかりにくい名前を使用していると、誤って別のASMディ
スクを削除してしまう可能性が高くなります。
しかし、ASMLibの場合はラベル名がそのままASMディスク名となるため、追
加した人がNAME句を入れていないような状況でも削除対象が見分けやすくな
ります。

以上の結果から、やはりASMLibは運用者の負荷を軽減してくれることに間違い
なさそうです。

運用中の管理性についての検証が一段落したところで、今回はここまで！！

次回は、ディスク検出の問題について検証します。

フェブラリーS、４歳馬のワンツーで世代交代！！
恵比寿より

ASMLibに関する検証 その３