Sun Cluster 2.2 ソフトウェアのインストール

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 の構成の概要

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

表 B-1 Solstice DiskSuite 構成するための主な作業

作業 

説明箇所 

  1. Solstice DiskSuite 構成の計画

第 2 章「構成の計画」

  1. 必要なメタデバイス名の個数の算出

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

  1. scdidadm(1M) コマンドによるディスク ID の作成

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

  1. metadb(1M) コマンドによるローカル (プライベート) ディスク上でのメタデバイス状態データベースの複製の作成

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

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

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

  1. metaset(1M) コマンドによるディスクセットの作成

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

  1. metaset(1M) コマンドによるディスクセットへのドライブの追加

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

  1. (省略可能) ディスクセット内のドライブのパーティションの再分割

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

  1. ディスクセットにメタデバイスを作成するための md.tab ファイルの設定

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

  1. metainit(1M) コマンドによる md.tab ファイルの「実行」

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

  1. 各論理ホスト用のファイルシステムの構成

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

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


注 -

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


Sun Cluster 用に Solstice DiskSuite を構成する

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


注 -

PATH 変数に /usr/opt/SUNWmd/sbin を設定してください。


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

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

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

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

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

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

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

    /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 つのコンポーネントを設定します。

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 ファイルをすでに作成している場合は、例 B-1 のスクリプトを変換に役立てることができます。このスクリプトは、/dev/dsk/c0t0d0 または c0t0d0 などの物理デバイス名が md.tab ファイルに含まれているかどうかを調べて、物理デバイス名を、/dev/did/rdsk/d60 などの完全な DID 名に変換します。


例 B-1 md.tab 変換スクリプト

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 instance fullpath fullname
 do
         old=`basename $fullpath`
         new=`basename $fullname`
         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)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-hahost1phys-hahost2 で構成される 2 つのディスクセット (hahost1hahost2) を 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 の変更を行えないことを除けば、ディスクセットにドライブを追加した後も、ドライブのパーティションは必要に応じて再分割することができます。推奨する多重ホストディスクのパーティション構成方法については、「ディスクセット内のドライブのパーティションを再分割するには」および第 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 大部分のドライブに対する多重ホストディスクのパーティション

    スライス 

    説明 

    2 M バイト (Solstice DiskSuite 用に予約) 

    UFS ログ 

    ディスクの残り領域 

    スライス 6 と 0 のオーバーラップ部分 

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


    注 -

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


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

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

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

    スライス 

    説明 

    2 M バイト (Solstice DiskSuite 用に予約) 

    2 M バイト (HA 管理ファイルシステム用の UFS ログ) 

    9 M バイト (HA 管理ファイルシステム用の UFS マスター) 

    UFS ログ 

    ディスクの残り領域 

    スライス 6 と 0 のオーバーラップ部分 

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

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

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


注 -

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


md.tab ファイルの作成

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

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


注 -

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


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

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

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

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

md.tab ファイル内の行の順序は重要ではありませんが、後述するような順でファイルを作成してください。次の md.tab のサンプルファイルでは、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/d3s
 green/d6 1 1 /dev/did/rdsk/d4s5

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

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

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

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

  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 多重ホストファイルシステムを作成できます。

多重ホスト 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 管理ファイルシステム用のマウントポイントを作成します。

      この例では、マウントポイントとして論理ホスト名を使用します。

      phys-hahost1# mkdir /hahost1
      
    3. HA 管理ファイルシステムをマウントします。

      phys-hahost1# mount /dev/md/hahost1/dsk/d11 /hahost1
      
  4. 多重ホスト UFS ファイルシステムを作成します。

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

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

      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-4 構成に必要なドライブ数

用途 

データ 

必要なディスク記憶装置 

必要なドライブ数 

nfs1 

5 G バイト 

3x2.1 G バイトディスク*2 (ミラー) 

nfs2 

5 G バイト 

3x2.1 G バイトディスク*2 (ミラー) 

oracle1 

5 G バイト 

3x2.1 G バイトディスク*2 (ミラー) 

oracle2 

10 G バイト 

5x2.1 G バイトディスク*2 (ミラー) 

10 

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

表 B-5 ディスクセットの分配

論理ホスト 

(ディスクセット) 

データサービス 

ディスク 

SPARCstorage Array 1 

SPARCstorage Array 2 

SPARCstorage Array 3 

hahost1

nfs1/oracle1 

12 

hahost2

nfs2/oracle2 

16 

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

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

Graphic

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