Solstice DiskSuite の構成

この章のガイドラインおよび第 2 章「構成の計画」の情報に基づいて、Solstice DiskSuite 用にローカルディスクおよび多重ホストディスクを構成してください。次に、この章のガイドラインと例に基づいて md.tab ファイルを作成してください。md.tab ファイルについては、Solstice DiskSuite のマニュアルにさらに詳しい説明があります。md.tab ファイルは、メタデバイスの構成を設計しながら作成するのが最も簡単です。Sun Cluster および Solstice DiskSuite ソフトウェアをインストールした後、各 Sun Cluster ノードに md.tab ファイルをコピーしてください。

この付録で説明する手順は次のとおりです。

• 「Sun Cluster 用 Solstice DiskSuite の構成の概要」

• 「Sun Cluster 用に Solstice DiskSuite を構成する」

• 「Solstice DiskSuite の構成例」

Sun Cluster 用 Solstice DiskSuite の構成の概要

表 B-1 に、Sun Cluster で動作するように共有ディスクを構成するための主な作業を示します。示されている順序に従って作業を行なってください。

以下の節では、Sun Cluster 用に Solstice DiskSuite を構成するために必要なすべての手順を説明します。

クラスタにディスク記憶装置が 2 つ (2 つのドライブ列) しかない場合は、Solstice DiskSuite メディエータを構成する必要があります。メディエータの構成と管理についての詳細は、『Sun Cluster 2.2 のシステム管理』の説明を参照してください。

Sun Cluster 用に Solstice DiskSuite を構成する

この節の手順に従って、次の項目を設定または構成してください。

• (省略可能) メタデバイス名の個数

• ディスク ID

• ローカルのメタデバイス状態データベースの複製

• (省略可能) ミラー化ルート (/) ファイルシステム

• ディスクセット

• ディスクセット内のドライブ

• (省略可能) ドライブのパーティション

• md.tab ファイル

• ファイルシステム

便宜上、PATH 変数に /usr/opt/SUNWmd/sbin (Solstice DiskSuite 4.2 の場合) または /usr/sbin (Solstice DiskSuite 4.2.1 の場合) を追加してください。

メタデバイス名の個数の算出

構成を設定する前に、構成に必要な Solstice DiskSuite のメタデバイス名の個数を算出する必要があります。メタデバイス名のデフォルトの数は 128 です。多くの構成でデフォルト以上の数が必要になります。構成を実装する前にこの数を増やしておくと、後で管理時間の節約になります。

メタデバイスの個数を算出するには

1. 各ディスクセットで使用するメタデバイス名の最高数を求めることによって、必要なメタデバイス名の個数を算出します。

   この個数は、実際の量ではなく、メタデバイス名に基づいています。たとえば、メタデバイス名が d950 から d1000 の場合、Solstice DiskSuite は、50 ではなく、1000 個の名前を必要とします。

2. 算出した値が 128 より大きい場合は、/kernel/drv/md.conf ファイルを編集します。

   /kernel/drv/md.conf の nmd フィールドにディスクセットが使用するメタデバイス名の最高数を設定してください。

   /kernel/drv/md.conf ファイルに対する変更は、再起動してはじめて有効になります。各クラスタノード上の md.conf ファイルは、同じ内容である必要があります。

   付録 A 「構成ワークシートと構成例」 のワークシートを参照して、メタデバイスの構成計画に役立ててください。

   ---

   注 -

   Solstice DiskSuite のマニュアルには、/kernel/drv/md.confファイル内で唯一変更可能なフィールドは nmd フィールドであると説明されています。実際には、ディスクセットを追加構成する場合は、md_nsets フィールドも変更することができます。

   ---

ディスク ID ドライバの使用

新たに Solstice DiskSuite を実行する環境でディスク ID (DID) を利用するには、ディスク ID 疑似ドライバが必要です。ディスク ID を使用して、メタデバイスは、実際のディスクのデバイス名からは独立してデータを検出することができます。データがデバイス名ではなくディスク ID によって検出されるため、構成変更やハードウェアの更新は問題ではなくなります。

ディスク ID とディスクパス間のマッピングを作成するには、ノード 0 から scdidadm(1M) コマンドを実行します。scdidadm(1M) コマンドは、次の 3 つのコンポーネントを設定します。

• ディスク ID (DID) - 物理ホストに割り当てられる「1」などの短縮番号

• DID インスタンス番号 - phys-hahost3:/dev/rdsk/c0t0d0 などの、raw ディスクデバイスへの完全パス

• DID 完全名 - /dev/did/rdsk/d1 などの DID の完全パス

Solstice HA 1.3 は、2 ノードのクラスタのみサポートしていました。この 2 ノードの構成では、両方のノードを同じプラットフォーム上で同一の構成にする必要があったため、Solstice DiskSuite デバイスドライバが使用するメジャー/マイナーデバイス番号は、両方のシステムで同じでした。3 ノード以上の構成では、ディスクのマイナー番号をクラスタ内の全ノード上で同じにすることは困難です。同じディスクであっても、ノードによってメジャー/マイナー番号が異なることがあります。DID ドライバは、生成された DID デバイス名を使用して、異なるノード上の、メジャー/マイナー番号が異なる可能性があるディスクにアクセスします。

Solstice DiskSuite を使用する、3 ノード以上のクラスタでは、DID ドライバを使用する必要がありますが、このことは、Solstice DiskSuite の新しい導入先のすべてに適用される一般化された条件になっています。DID ドライバを使用することにより、将来的に 2 ノードの Solstice DiskSuite 構成を 3 ノード以上の構成に移行できます。

Solstice HA 1.3 を Sun Cluster 2.2 にアップグレードする場合、scdidadm(1M) コマンドを実行する必要はありません。

DID ドライバを使用できるようにするには

DID ドライバを使用する Solstice DiskSuite 構成を実現するには、次の手順を使用します。

ディスク ID を使用するために変換する md.tab ファイルをすでに作成している場合は、「DID 変換スクリプト」に含まれているスクリプトを利用できます。

1. scdidadm(1M) コマンドを使用して、ディスク ID インスタンス番号とディスクへのローカルおよびリモートパス間の対応付けを作成します。

   この手順は、scinstall(1M) コマンドを実行した後、クラスタが動作している状態で行なってください。DID 構成ファイルの信頼できるコピーを維持するには、すべてのノードが動作している状態でノード 0 からのスクリプトを実行します。このようにしなかった場合、スクリプトの実行は失敗します。get_node_status(1M) コマンドの出力には、ノード ID 番号が含まれます。詳細は、scdidadm(1M) のマニュアルページを参照してください。

   phys-hahost1# scdidadm -r

   ---

   注 -

   scdidadm(1M) コマンドは、クラスタノード 0 から実行する必要があります。

   ---

   scdidadm(1M) コマンドが他のクラスタノードのプライベートリンクを検出できない場合は、ノード 0 から次の形式の scdidadm(1M) コマンドを実行してください。

   phys-hahost1# scdidadm -r -H hostname1,hostname2,...

   このオプションを使用するときは、他のクラスタノード上の /.rhosts ファイルにノード 0 の適切なホスト名が登録されていることを確認してください。コマンドを実行するクラスタノードのホスト名を hostname 一覧に含めないでください。

2. DID マッピングを使用して、md.tab ファイルを更新します。

   以下のエラーメッセージが返された場合は、「DID ドライバの障害追跡」を参照してください。

   The did entries in name_to_major must be the same on all nodes.

   問題を解決して、scdidadm(1M) コマンドを再実行してください。

   DID インスタンス番号とディスク ID 間のマッピングが作成されたら、ディスクセットにドライブを追加するとき、または md.tab ファイルにおいて、下位デバイス名 (cXtXdX) の代わりに完全な DID 名を使用してください。scdidadm(1M) に -l オプションを指定すると、md.tab ファイルの作成に役立つマッピングの一覧が表示されます。次の出力例では、1 列目が DID インスタンス番号、2 列目が完全パス (物理パス)、3 列目が完全な名前 (疑似パス) です。

   phys-hahost1# scdidadm -l 60 phys-hahost3:/dev/rdsk/c4t5d2 /dev/did/rdsk/d60 59 phys-hahost3:/dev/rdsk/c4t5d1 /dev/did/rdsk/d59 58 phys-hahost3:/dev/rdsk/c4t5d0 /dev/did/rdsk/d58 57 phys-hahost3:/dev/rdsk/c4t4d2 /dev/did/rdsk/d57 56 phys-hahost3:/dev/rdsk/c4t4d1 /dev/did/rdsk/d56 55 phys-hahost3:/dev/rdsk/c4t4d0 /dev/did/rdsk/d55 ... 6 phys-hahost3:/dev/rdsk/c0t1d2 /dev/did/rdsk/d6 5 phys-hahost3:/dev/rdsk/c0t1d1 /dev/did/rdsk/d5 4 phys-hahost3:/dev/rdsk/c0t1d0 /dev/did/rdsk/d4 3 phys-hahost3:/dev/rdsk/c0t0d2 /dev/did/rdsk/d3 2 phys-hahost3:/dev/rdsk/c0t0d1 /dev/did/rdsk/d2 1 phys-hahost3:/dev/rdsk/c0t0d0 /dev/did/rdsk/d1

   「ローカルのメタデバイス状態データベースの複製の作成」に進んで、ローカルの複製を作成してください。

   DID ドライバで問題が発生した場合は、「DID ドライバの障害追跡」を参照してください。

DID ドライバの障害追跡

以前のリリースでは、Solstice DiskSuite は、ディスクに接続されている 2 つのノード上で、下位ディスクデバイスのメジャー番号とインスタンス番号が同じであることに依存していました。今回のリリースの Sun Cluster では、Solstice DiskSuite は、DID メジャー番号が全ノードで同じであり、DID デバイスのインスタンス番号もまた全ノードで同じである必要があります。scdidadm(1M) コマンドは、全ノード上の DID メジャー番号を調べます。/etc/name_to_major ファイル内に記録されている値が、全ノードで同じである必要があります。

メジャー番号が異なることが検出された場合、scdidadm(1M) コマンドはそのことを報告し、問題を解決して、scdidadm(1M) コマンドを再実行するよう求めます。DID ドライバはメジャー番号 149 を使用します。番号付けで衝突がある場合は、DID ドライバに別の番号を選択する必要があります。次の手順によって、必要な変更を行うことができます。

DID メジャー番号の衝突を解決するには

1. /etc/name_to_major ファイル内のほかのエントリと衝突しない番号を選択します。

2. 各ノードの /etc/name_to_major ファイルを編集して、問題の DID エントリを選択した番号に変更します。

3. /etc/name_to_major ファイルを更新したそれぞれのノードから、次のコマンドを実行します。

   phys-hahost1# rm -rf /devices/pseudo/did* /dev/did phys-hahost1# reboot -- -r ...

4. scdidadm(1M) コマンドの実行に使用したノードから次のコマンドを実行します。

   phys-hahost3# rm -f /etc/did.conf phys-hahost3# scdidadm -r

   この手順によって、マッピングの衝突が解決され、新しいマッピングでクラスタが再構成されます。

DID 変換スクリプト

ディスク ID を使用するために変換する md.tab ファイルをすでに作成している場合は、下のスクリプトを変換に役立てることができます。このスクリプトは、/dev/dsk/c0t0d0 または c0t0d0 などの物理デバイス名が md.tab ファイルに含まれているかどうかを調べて、物理デバイス名を、/dev/did/rdsk/d60 などの完全な DID 名に変換します。

more phys_to_did
#! /bin/sh
#
# ident "@(#)phys_to_did        1.1     98/05/07 SMI"
#
# Copyright (c) 1997-1998 by Sun Microsystems, Inc.
# All rights reserved.
#
# Usage: phys_to_did <md.tab filename> 
# Converts $1 to did-style md.tab file.
# Writes new style file to stdout.

MDTAB=$1
TMPMD1=/tmp/md.tab.1.$$
TMPMD2=/tmp/md.tab.2.$$
TMPDID=/tmp/didout.$$

# Determine whether we have a "physical device" md.tab or a "did" md.tab.
# If "physical device", convert to "did".
grep "¥/dev¥/did" $MDTAB > /dev/null 2>&1
if [ $? -eq 0 ]; then
        # no conversion needed
        lmsg=`gettext "no conversion needed"`
        printf "${lmsg}¥n"
        exit 0
fi

scdidadm -l > $TMPDID
if [ $? -ne 0 ]; then
        lmsg=`gettext "scdidadm -l failed"`
        printf "${lmsg}¥n"
        exit 1
fi

cp $MDTAB $TMPMD1

...

...
# Devices can be specified in md.tab as /dev/rdsk/c?t?d? or simply c?t?d?
# There can be multiple device names on a line.
# We know all the possible c.t.d. names from the scdidadm -l output.

# First strip all /dev/*dsk/ prefixes.
sed -e "s:/dev/rdsk/::g" -e "s:/dev/dsk/::g" $TMPMD1 > $TMPMD2

# Next replace the resulting physical disk names "c.t.d." with
# /dev/did/rdsk/<instance>
exec < $TMPDID
while read in6stance fullpath fullname
do
        old=`basename $fullpath`
        new=`basename $fullnam竪
        sed -e "s:"$old":/dev/did/rdsk/"$new":g" $TMPMD2 > $TMPMD1
        mv $TMPMD1 $TMPMD2
done

cat $TMPMD2
rm -f $TMPDID $TMPMD1 $TMPMD2

exit 0

ローカルのメタデバイス状態データベースの複製の作成

多重ホストディスクへのディスクセットの作成や、ルート (/) ファイルシステムのミラー化などの Solstice DiskSuite の構成作業を行うには、各クラスタノード上のローカル (プライベート) ディスクにメタデバイス状態データベースの複製を作成しておく必要があります。ローカルディスクは、多重ホストディスクから分離されます。Solstice DiskSuite が動作するには、ローカルディスク上に状態データベースが必要です。

ローカルのメタデバイス状態データベースの複製を作成するには

クラスタ内の各ノード上で次の手順を実行してください。

1. スーパーユーザーで metadb(1M) コマンドを使用し、各クラスタノードのシステムディスクにローカルの複製を作成します。

   たとえば、次のコマンドは、ローカルディスクのスライス 7 に 3 つのメタデバイス状態データベースの複製を作成します。

   # metadb -afc 3 c0t0d0s7

   -c オプションは、同じスライスに複製を作成します。この例では、スライス 7 を使用していますが、実際には、使用されていない任意のスライスを使用できます。

2. metadb(1M) コマンドを使用して、複製の妥当性を検査します。

   # metadb flags first blk block count a u 16 1034 /dev/dsk/c0t0d0s7 a u 1050 1034 /dev/dsk/c0t0d0s7 a u 2084 1034 /dev/dsk/c0t0d0s7

ルート (/) ファイルシステムのミラー化

ルート (/) ファイルシステムをミラー化して、システムディスク障害のためにクラスタノードそのものが停止するのを防止することができます。詳細は、第 2 章「構成の計画」を参照してください。

ルート (/) ファイルシステムをミラー化するための主な作業は、以下のとおりです。

• metainit(1M) -f コマンドによるルートスライスの単一スライス (1 方向) 連結化 (サブミラー1)

• 2 つ目の連結 (サブミラー2) の作成

• metainit(1M) コマンドによる、サブミラーでの 1 方向ミラーの作成

• metaroot(1M) コマンドの実行

• lockfs(1M) コマンドの実行

• 再起動

• metattach(1M) コマンドによるサブミラー2 の接続

• 代替起動パスの記録

詳細は、metainit(1M)、metaroot(1M)、metattach(1M) のマニュアルページと Solstice DiskSuite のマニュアルを参照してください。

ディスクセットの作成

ディスクセットは、複数のホストが同時にではなく、排他的にアクセスできる Solstice DiskSuite を含む多重ホストディスクドライブの集まりです。ディスクセットを作成するには、スーパーユーザーで、グループ 14 のメンバーである必要があります。

ディスクセットの作成にあたっては、次の規則に従い、ディスク格納装置に障害が発生した場合でもクラスタが正しく動作するようにしてください。

1. 正確に 2 つの列を使用する場合は、2 つの列それぞれの、ディスクセットに含まれる物理ディスク数を同じにしてください。

注 - 列 2 つの構成の場合は、メディエータが必要です。メディエータの設定についての詳細は、『Sun Cluster 2.2 のシステム管理』を参照してください。

1. 3 つ以上の列、たとえば 3 つの列を使用する場合は、必ず、任意の 2 つの列 (S1 と S2) のディスク数の合計を 3 つ目の列 (S3) のディスク数より多くします。この関係を式で表すと、「S1 のディスク数 + S2 のディスク数 > S3 のディスク数」になります。

ディスクセットを作成するには

クラスタ内に作成するディスクセットごとに、次の手順を実行してください。クラスタ内のすべてのノードが動作している必要があります。ディスクセットの作成では、ディスクセットにホストとディスクドライブを割り当てます。

1. ローカルのメタデバイス状態データベースの複製が存在することを確認します。

   必要に応じて、「ローカルのメタデバイス状態データベースの複製を作成するには」の手順を参照してください。

2. クラスタノードの 1 つからスーパーユーザーで metaset(1M) コマンドを実行することによって、ディスクセットを作成します。

   たとえば、次のコマンドは、ノード phys-hahost1 と phys-hahost2 で構成される 2 つのディスクセット (hahost1 と hahost2) を 2 つ作成します。

   phys-hahost1# metaset -s hahost1 -a -h phys-hahost1 phys-hahost2 phys-hahost1# metaset -s hahost2 -a -h phys-hahost1 phys-hahost2

3. metaset(1M) コマンドを実行することによって新しいディスクセットの状態を確認します。

   phys-hahost1# metaset

   これで、「ディスクセットにドライブを追加するには」の手順に従い、ディスクセットにドライブを追加できます。

ディスクセットにドライブを追加するには

ディスクセットにドライブを追加すると、Solstice DiskSuite は次のようにドライブのパーティションを再分割して、ディスクセット用のメタデバイス状態データベースをドライブに配置できるようにします。

• 各ドライブの小さな領域をスライス 7 として Solstice DiskSuite 用に予約します。各ライブの残り領域はスライス 0 に組み込まれます。

• ディスクセットにドライブが追加されると、スライス 7 が正しく構成されていない場合にのみ、ドライブのパーティションが再分割されます。

• パーティションを再分割することによって、ディスク上の既存のデータはすべて失われます。

• スライス 7 がシリンダ 0 から始まり、ディスクに状態データベースの複製の格納するための十分な領域がある場合、ディスクの再分割は行われません。

スライス 7 の変更を行えないことを除けば、ディスクセットにドライブを追加した後も、ドライブのパーティションは必要に応じて再分割することができます。推奨する多重ホストディスクのパーティション構成方法については、「ディスクセット内のドライブのパーティションを再分割するには」および第 2 章「構成の計画」を参照してください。

ディスクのパーティションを手動で再分割する場合は、状態データベースの複製を格納するのに十分な大きさ (約 2 M バイト) の、シリンダ 0 から始まるパーティション 7 を作成してください。このとき、スライス 7 の Flag フィールドには、V_UNMT (マウント不可) を設定する必要があります。読み取り専用には設定しないでください。スライス 7 が、ディスク上の他のスライスとオーバーラップしてはいけません。これは、metaset(1M) コマンドによってディスクのパーティションが再分割されないようにするためです。

次の手順に従って、ディスクセットにドライブを追加してください。

1. 構成で DID ドライバを使用する準備がすでに整っていること、またディスクセットをすでに作成していることを確認します。

   必要ならば、「DID ドライバを使用できるようにするには」および 「ディスクセットを作成するには」を参照してください。

2. スーパーユーザーで metaset(1M) コマンドを使用して、ディスクセットにドライブを追加します。

   ディスクドライブのキャラクタ型デバイス名ではなく、DID ドライバ名を使用してください。

   phys-hahost1# metaset -s hahost1 -a /dev/did/dsk/d1 /dev/did/dsk/d2 phys-hahost1# metaset -s hahost2 -a /dev/did/dsk/d3 /dev/did/dsk/d4

3. metaset(1M) コマンドを使用して、ディスクセットとドライブの状態を確認します。

   phys-hahost1# metaset -s hahost1 phys-hahost1# metaset -s hahost2

4. (省略可能) 「ディスクの計画と配置」を参照して、多重ホストディスクのスライスを最適化します。

ディスクの計画と配置

metaset(1M) コマンドは、ディスクセット内のドライブのパーティションを再分割して、各ドライブの小さな領域をスライス 7 として Solstice DiskSuite 用に予約します。各ドライブの残り領域はスライス 0 に組み込まれます。ディスクをより効果的に利用するには、この節の手順に従ってディスクの配置を変更してください。

ディスクセット内のドライブのパーティションを再分割するには

1. format(1M) コマンドを使用して、表 B-2 に示すように大部分のドライブのディスクパーティションを変更します。

   表 B-2 大部分のドライブに対する多重ホストディスクのパーティション

   スライス	説明
   7	2 M バイト (Solstice DiskSuite 用に予約)
   6	UFS ログ
   0	ディスクの残り領域
   2	スライス 6 と 0 のオーバーラップ部分

   一般に、UFS ログを作成した場合は、スライス 6 のデフォルトサイズは、システム上で最も大きい多重ホストディスクサイズの 1% にします。

   ---

   注 -

   スライス 2 によるスライス 6 と 0 のオーバーラップ部分は、UFS ログが存在しない raw デバイス用に使用されます。

   ---

2. 各ディスクセットの最初の 2 つのコントローラ上の各ドライブを、表 B-3 に示すように分割します。

   次の表は、最初の 2 つのコントローラの最初のドライブを分割する例です。2 つより多い場合、最初のドライブまたは最初の 2 つのコントローラを使用する必要はありません。

   表 B-3 多重ホストディスクのパーティション分割 - 最初の 2 つのコントローラ上の最初のドライブ

   スライス	説明
   7	2 M バイト (Solstice DiskSuite 用に予約)
   5	2 M バイト (HA 管理ファイルシステム用の UFS ログ)
   4	9 M バイト (HA 管理ファイルシステム用の UFS マスター)
   6	UFS ログ
   0	ディスクの残り領域
   2	スライス 6 と 0 のオーバーラップ部分

   各多重ホストディスクの先頭の 2 M バイトは、パーティション 7 として Solstice DiskSuite 用に予約します。

md.tab ファイルを使用したディスクセット内のメタデバイスの作成

この節では、md.tab ファイルを使用して、メタデバイスおよびホットスペアの集合を構成する方法を説明します。なお、Solstice DiskSuite 4.2 の場合、md.tab ファイルは /etc/opt/SUNWmd 内にあります。Solstice DiskSuite 4.2.1 の場合、md.tab ファイルは /etc/lvm 内にあります。

ディスク ID を使用するために変換する md.tab ファイルをすでに作成している場合は、「DID 変換スクリプト」を変換に役立てることができます

md.tab ファイルの作成

metainit(1M) コマンドは、md.tab ファイルを使用して、バッチに似たモードでメタデバイスおよびホットスペアの集合を構成することができます。Solstice DiskSuite は、この md.tab ファイル内に構成情報を格納しません。md.tab ファイルには、手動で編集することによってのみ情報を入力することができます。

md.tab ファイル内では、各メタデバイスあるいはホットスペアの集合のエントリが重複してはいけません。エントリには、単純メタデバイス (ストライプ、結合、ストライプ連結)、ミラー、トランスメタデバイス、RAID5 メタデバイス、ホットスペアの集合を指定することができます。

md.tab ファイルには、手動で入力されたエントリだけが含まれます。この md.tab ファイルから、システム上のメタデバイス、ホットスペアの集合、複製に関する現在の構成情報が得られるわけではありません。

md.tab ファイルでは、タブ、空白、コメント (ハッシュ記号で始まる)、継続行 (バックスラッシュ改行で始まる) を使用できます。

なお、Solstice DiskSuite 4.2 の場合、md.tab ファイルは /etc/opt/SUNWmd 内にあります。Solstice DiskSuite 4.2.1 の場合、md.tab ファイルは /etc/lvm 内にあります。

md.tab ファイル作成のガイドライン

ディスク構成の設定と関係する md.tab ファイルの設定にあたっては、次のガイドラインに従ってください。

• 管理しやすいよう、クラスタ内のすべてのノードに同じ内容の md.tab ファイルを保持することを推奨します。

• 多重ホストディスクおよびそのディスク上のパーティションを、複数のディスクセットに含めることはできません。

• ディスクセットが使用するすべてのメタデバイスを完全にミラー化する必要があります。2 方向ミラーを推奨しますが、3 方向ミラーも使用できます。

• ミラー用のサブミラーのコンポーネントが、そのミラーの定義に使用されている別のサブミラーの別のコンポーネントと同じコントローラ上に存在していてはいけません。

• 3 つ以上のディスク列を使用する場合、各ディスクセットは、少なくとも 3 つの異なるコントローラのディスクで構成する必要があります。ディスク 2 つだけの列を使用する場合は、ディスクセットをその 2 つのコントローラのディスクで構成して、メディエータを設定します。二重列メディエータの使用についての詳細は、『Sun Cluster 2.2 のシステム管理』を参照してください。

• ホットスペアの使用を推奨しますが、必須ではありません。ホットスペアを使用する場合は、ホットスペアドライブを起動することによって、メタミラー用のサブミラーのコンポーネントがそのメタミラーの定義に使用されている別のサブミラーの別のコンポーネントとコントローラを共有しないようにホットスペアを構成してください。

• SolsticeDiskSuite の UFS ロギングを使用する場合は、md.tab ファイルにミラー化メタデバイスを設定する必要があるだけです。トランスデバイスを設定する必要はありません。

• Solstice DiskSuite ロギングを使用する場合は、トランスメタデバイス上にのみ多重ホストファイルシステムを作成してください。すべてのトランスメタデバイスのロギングとマスターデバイスコンポーネントの両方をミラー化する必要があります。

• Solstice DiskSuite ロギングを使用する場合は、複数のドライブにまたがってロギングおよびマスターデバイスをストライプ化していない場合は、同じトランスメタデバイスのロギングデバイスとマスターデバイス間でスピンドルを共有しないでください。そうしなければ、システムの性能が落ちます。

• 各ディスクセットには、小さな管理ファイルシステムが関係付けられます。このファイルシステムは、NFS 共有されません。このファイルシステムは、データサービスに固有の状態または構成情報用に使用されます。管理ファイルシステムの名前は、ディスクセットのデフォルトのマスターである論理ホストと同じである必要があります。この方法は、DBMS 障害モニターの起動を有効にするために必要です。

md.tab のサンプルファイル

md.tab ファイル内の行の順序は重要ではありませんが、後述するような順でファイルを作成してください。次の md.tab のサンプルファイルでは、green というディスクセット用のメタデバイスを定義しています。# を使用して、ファイルにコメントを付けることができます。この例では、論理ホスト名も green です。

# administrative file system for logical host mounted under /green
 green/d0 -t green/d1 green/d4
 	green/d1 -m green/d2 green/d3
 	    green/d2 1 1 /dev/did/rdsk/d1s4
 	    green/d3 1 1 /dev/did/rdsk/d2s4
 	green/d4 -m green/d5 green/d6
 	    green/d5 1 1 /dev/did/rdsk/d3s5
 	    green/d6 1 1 /dev/did/rdsk/d4s5
 
 # /green/web
 green/d10 -t green/d11 green/d14
 	green/d11 -m green/d12 green/d13
 	    green/d12 1 1 /dev/did/rdsk/d1s0
 	    green/d13 1 1 /dev/did/rdsk/d2s0
 	green/d14 -m green/d15 green/d16
 	    green/d15 1 1 /dev/did/rdsk/d3s6
 	    green/d16 1 1 /dev/did/rdsk/d4s6
 
 #/green/home to be NFS-shared
 green/d20 -t green/d21 green/d24
 	green/d21 -m green/d22 green/d23
 	    green/d22 1 1 /dev/did/rdsk/d3s0
 	    green/d23 1 1 /dev/did/rdsk/d4s0
 	green/d24 -m green/d25 green/d26
 	    green/d25 1 1 /dev/did/rdsk/d1s6
 	    green/d26 1 1 /dev/did/rdsk/d2s6

先頭行では、管理ファイルシステムを、マスター(UFS) メタデバイス d1 とログデバイス d4 で構成されるトランスメタデバイス d0 と定義しています。-t は、このデバイスがトランスメタデバイスであることを意味します。マスターデバイスとログデバイスであることは、-t フラグの後の位置で示されます。

2 行目では、マスターデバイスをメタデバイスのミラーと定義しています。この定義中の -m は、ミラーデバイスであることを意味します。

green/d1 -m green/d2 green/d3

同様に 5 行目では、ログデバイスの d4 をメタデバイスのミラーと定義しています。

green/d4 -m green/d5 green/d6

3 行目では、マスターデバイスの 1 つ目のサブミラーを 1 方向ストライプと定義しています。

green/d2 1 1 /dev/did/rdsk/d1s4

次の 4 行目では、もう 1 つのマスターサブミラーを定義しています。

green/d3 1 1 /dev/did/rdsk/d2s4

最後は、ログデバイスのサブミラーの定義です。この例では、それぞれのサブミラー用に単純メタデバイスを作成します。

green/d5 1 1 /dev/did/rdsk/d3s5
green/d6 1 1 /dev/did/rdsk/d4s5

同様に、別の 2 つのアプリケーション用のミラーが作成されています。d10 には、web サーバーとファイルが含まれ、d20 には NFS 共有ファイルシステムが含まれます。

サブミラーに使用するディスクにデータがすでに存在している場合は、メタデバイスを構成する前にそのデータのバックアップを取り、ミラーに復元する必要があります。

md.tab ファイルを初期化するには

この手順では、metainit(1M) コマンドを実行するノード上のディスクセットの所有権を持っていることが前提になります。また、Solstice DiskSuite 4.2 ではクラスタ内のすべてのノード上に同じ内容の md.tab ファイルが存在する必要もあります。md.tab ファイルは、/etc/opt/SUNWmd ディレクトリに存在している必要があります。Solstice DiskSuite 4.2.1 の場合、md.tab ファイルは /etc/lvm 内に存在している必要があります。

1. スーパーユーザーで metainit(1M) コマンドを実行することによって、md.tab ファイルを初期化します。

   1. ディスクセットの制御権を取得します。

      phys-hahost1# metaset -s hahost1 -t

   2. md.tab ファイルを初期化します。-a オプションは、md.tab ファイルに定義されている全メタデバイスを起動します。たとえば、次のコマンドは、md.tab ファイルをディスクセット hahost1 用に初期化します。

      phys-hahost1# metainit -s hahost1 -a

   3. クラスタ内の各ディスクセットに対して上記の手順を繰り返します。

      必要ならば、ディスクに接続できる別のノードから metainit(1M) コマンドを実行してください。すべてのノードがディスクにアクセスできるわけではないクラスタ化ペアおよびリングトポロジでは、この操作が必要になります。

2. metastat(1M) コマンドを使用して、メタデバイスの状態を確認します。

   phys-hahost1# metastat -s hahost1

ディスクセットでのファイルシステムの作成

Sun Cluster と Solstice DiskSuite を組み合わせた環境では、次のいずれかの方法でロギング UFS 多重ホストファイルシステムを作成できます。

• マスターデバイスとロギングデバイスで構成したメタトランスデバイスを作成する

• Solaris 7 または Solaris 8 オペレーティング環境のロギング機能を使用する

多重ホスト UFS ファイルシステムを作成するには

ここでは、各ディスクセットに必須の管理ファイルシステムなどの多重ホスト UFS ファイルシステムを作成する方法を説明します。

1. すべてのディスクセットについて、ファイルシステムを含めるメタデバイスを特定または作成します。

   管理ファイルシステム用に、次のコンポーネントで構成されるトランスメタデバイスを作成することを推奨します。

   • マスターデバイス: 最初の 2 つのコントローラ上のドライブ 1 に含まれるスライス 4 上の 2 つの 2 M バイトスライスを使用するミラー

   • ロギングデバイス: 最初の 2 つのコントローラ上のドライブ 1 に含まれるスライス 6 上の 2 つの 2 M バイトスライスを使用するミラー

2. ディスクセットの所有権を持っていることを確認します。

   初期構成の一環として多重ホストファイルシステムを作成する場合は、すでにディスクセットの所有権を持っています。ディスクセットの所有権の取得については、metaset(1M) のマニュアルページを参照してください。

3. HA 管理ファイルシステムを作成します。

   1. newfs(1M) コマンドを実行します。

      この例では、トランスメタデバイス d11 にファイルシステムを作成します。

      phys-hahost1# newfs /dev/md/hahost1/rdsk/d11

      ---

      注意 -

      ファイルシステムを作成する過程で、ディスク上のすべてのデータが破壊されます。

      ---

   2. HA 管理ファイルシステム用のマウントポイントを作成します。

      この例では、マウントポイントとして論理ホスト名を使用します。この方法は、DBMS 障害モニターの起動を有効にするために必要です。

      phys-hahost1# mkdir /hahost1

   3. HA 管理ファイルシステムをマウントします。

      phys-hahost1# mount /dev/md/hahost1/dsk/d11 /hahost1

4. 多重ホスト UFS ファイルシステムを作成します。

   1. newfs(1M) コマンドを実行します。

      この例では、トランスメタデバイスの d1、d2、d3、d4 にファイルシステムを作成します。

      phys-hahost1# newfs /dev/md/hahost1/rdsk/d1 phys-hahost1# newfs /dev/md/hahost1/rdsk/d2 phys-hahost1# newfs /dev/md/hahost1/rdsk/d3 phys-hahost1# newfs /dev/md/hahost1/rdsk/d4

      ---

      注意 -

      ファイルシステムを作成する過程で、ディスク上のすべてのデータが破壊されます。

      ---

   2. 多重ホスト UFS ファイルシステム用のマウントポイントを作成します。

      phys-hahost1# mkdir /hahost1/1 phys-hahost1# mkdir /hahost1/2 phys-hahost1# mkdir /hahost1/3 phys-hahost1# mkdir /hahost1/4

5. /etc/opt/SUNWcluster/conf/hanfs ディレクトリを作成します。

6. /etc/opt/SUNWcluster/conf/hanfs/vfstab.logicalhost ファイルを編集して、管理ファイルシステムおよび多重ホスト UFS ファイルシステム情報を更新します。

   全クラスタノードの vfstab.logicalhost ファイルに同じ情報が含まれていることを確認します。cconsole(1) 機能を使用することによって、クラスタ内の全ノード上の vfstab.logicalhost ファイルを同時に編集できます。

   下記は、vfstab.logicalhost ファイルの例です。管理ファイルシステムと別の 4 つの UFS ファイルシステムを示しています。

   #device device mount FS fsck mount mount #to mount to fsck point type pass all options# /dev/md/hahost1/dsk/d11 /dev/md/hahost1/rdsk/d11 /hahost1 ufs 1 no - /dev/md/hahost1/dsk/d1 /dev/md/hahost1/rdsk/d1 /hahost1/1 ufs 1 no - /dev/md/hahost1/dsk/d2 /dev/md/hahost1/rdsk/d2 /hahost1/2 ufs 1 no - /dev/md/hahost1/dsk/d3 /dev/md/hahostt1/rdsk/d3 /hahost1/3 ufs 1 no - /dev/md/hahost1/dsk/d4 /dev/md/hahost1/rdsk/d4 /hahost1/4 ufs 1 no -

7. ディスクセットの所有権を放棄します。

   必要ならば、最初にファイルシステムをマウント解除します。

   ディスクセットに対して上記の作業を行うノードは暗黙でディスクセットの所有権を取得するため、作業が終了したら、所有権を放棄する必要があります。

   phys-hahost1# metaset -s hahost1 -r

8. (省略可能) ファイルシステムを NFS で共有可能にする場合は、第 11 章「Sun Cluster HA for NFS のインストールと構成」を参照します。

Solstice DiskSuite の構成例

ここで紹介する例は、Solstice DiskSuite を使用して各ディスクセットに含めるディスク数を決定するプロセスを明らかにするのに役立ちます。この例では、ディスク拡張装置として 3 つの SPARCstorage Array を使用していると仮定します。また、既存のアプリケーションが NFS (それぞれ 5 G バイトの 2 つのファイルシステム) 上で動作し、2 つの Oracle データベース (1 つは 5 G バイト、もう 1 つは 10 G バイト) を実行しています。

この構成例に必要なドライブ数は、表 B-4 に示す計算式に基づいて決定されます。3 つの SPARCstorage Array の構成の場合は、28 個のドライブが必要であり、それらドライブを 3 つのアレイ間にできるかぎり等配分します。必要なディスクの容量は必要なバイト数よりも多くなるため、5 G バイトのファイルシステムには、1 G バイトのディスク空間が追加されていることに注意してください。

表 B-5 は、2 つの論理ホストと 4 つのディスクセット間のドライブ割り当てを示しています。

当初 hahost1 には、それぞれの SPARCstorage Array から 4 つのディスク (合計で 12 のディスク) が割り当てられ、hahost2 にはそれぞれの SPARCstorage Array から 5 つまたは 6 つのディスク (合計で 16 のディスク) が割り当てられます。図 B-1 は、このディスク割り当てを表しています。ディスクには、hahost1 ならば 1、hahost2 ならば 2 というようにディスクセット名を使用したラベルを付けています。

図 B-1 ディスクセットの割り当て例

どちらのディスクセットにも、ホットスペアは割り当てられていません。1 つの SPARCstorage Array につき、少なくとも 1 つのホットスペアを各ディスクセットに割り当てることによって、ドライブをホットスペアし、完全な 2 方向のミラー化を復元することができます。