第 19 章 ディスクセット (概要)

この章では、ディスクセットの概念について説明します。関連する作業の実行手順については、第 20 章「ディスクセット (作業)」を参照してください。

この章では、次の内容について説明します。

• ディスクセットの機能

• Solaris ボリュームマネージャによるディスクセットの管理

• ディスクセットの背景情報

• ディスクセットの管理

• シナリオ — ディスクセット

ディスクセットの機能

共有ディスクセット (または単に ディスクセット) とは、排他的に共有される (複数のホストが同時に使用することはできない) ボリュームやホットスペアからなるディスクドライブの集まりです。ディスクセットには個別の名前空間が与えられ、Solaris ボリュームマネージャのボリュームはその名前空間内で管理できます。

ディスクセットを使用すると、データの冗長性と可用性が向上します。１つのホストに障害が発生しても、他のホストがそのホストのディスクセットを引き継ぐことができます (このような構成をフェイルオーバー構成と呼びます)。 各ホストはディスクセットを制御できますが、1 度に 1 台のホストだけが排他的にディスクセットを制御します。

ディスクセットは、SPARC ベースのプラットフォームでも x86 ベースのプラットフォームでもサポートされています。

ディスクセットは、Sun Cluster、Solstice HA (High Availability)、またはサポートされる他社製の HA フレームワークと組み合わせて使用することを想定しています。Solaris ボリュームマネージャ単体では、フェイルオーバー構成を実装するのに必要なすべての機能が提供されるとは限りません。

Solaris ボリュームマネージャによるディスクセットの管理

各ホストは、共有ディスクセットの他にローカルディスクセットも備えています。 ローカルディスクセットは、ホスト上のすべてのディスクのうちで共有ディスクセットに含まれないディスクで構成されます。ローカルディスクセットは特定のホストだけに属します。ローカルディスクセットには、そのホストの構成を記録した状態データベースが格納されています。

共有ディスクセット内のボリュームやホットスペア集合は、そのディスクセット内のドライブだけで構成されます。ディスクセットに作成したボリュームは、物理スライスと同じように使用できます。ただし、ディスクセットでは、/etc/vfstab ファイルを介したファイルシステムのマウントはサポートされません。

ディスクセット内のボリューム上にあるファイルシステムを、起動時に /etc/vfstab ファイルを介して自動的にマウントすることはできません。これは、ディスクセットのマウント操作に必要な RPC デーモン (rpc.metad と rpc.metamhd) が、起動時にはまだ実行されていないためです。また、ディスクセットの所有権は再起動時に失われます。

共有ディスクセットの場合と同様に、ローカルディスクセット内のボリュームやホットスペア集合は、ローカルディスクセットのドライブだけで構成されます。

ディスクセットにディスクを追加すると、Solaris ボリュームマネージャはディスクセット上に状態データベースの複製を自動的に作成します。Solaris ボリュームマネージャは、ディスクセットの状態データベースの複製をそのディスクに配置できるように、ディスクのパーティションを再分割することがあります (ディスクの自動パーティション分割を参照)。

ローカルディスクセットを管理する場合とは異なり、ディスクセットの状態データベースを手動で作成したり削除したりする必要はありません。Solaris ボリュームマネージャは、ディスクセット内のすべてのドライブに、1 つの状態データベースの複製 (スライス 7 に常駐する) を分散させて配置します (ディスクセット当たり最大 50 の複製を作成できる)。

ディスクセットはシングルホスト構成でもサポートされますが、通常、「ローカル」な (二重に接続されていない) 使用形態には適していません。例外的な使用形態として、ディスクセットを使って論理ボリュームの名前空間を管理しやすくする場合と、Storage Area Network (SAN) 構成においての記憶領域の管理を容易にする場合が挙げられます (シナリオ — ディスクセットを参照)。

ディスクの自動パーティション分割

ディスクセットに新しいディスクを追加すると、Solaris ボリュームマネージャは、ディスクフォーマットを調べ、必要に応じてディスクのパーティションを再分割して、状態データベースの複製を格納できるように適切に設定されたスライス 7 を作成します。スライス 7 の厳密なサイズはディスクの幾何学的な構造によって異なりますが、通常は、4M バイトを下回ることなく、おおよそ 6M バイト程度です (シリンダ境界がどこにあるかによって異なります)。

スライス 7 の最小限のサイズは、状態データベースの複製のサイズ、状態データベースの複製に保管する情報など、さまざまな要因によって、将来変わってくる可能性があります。

ディスクセットで使用するディスクには、次の条件を満たしたスライス 7 を与える必要があります。

• セクター 0 から始まる

• ディスクラベルと状態データベースの複製とを格納できる領域がある

• マウントできない

• スライス 2 などの他のスライスと重なり合わない

ディスクセットにドライブを追加した、ドライブのパーティションは必要に応じて再分割ができますが、スライス 7 を変更することはできません。

スライス 7 の最小限のサイズは、ディスクの幾何学的な構造によって異なりますが、つねに 4M バイト以上です。

以下に、prtvtoc コマンドで表示した、ディスクセットに追加する前のディスク情報の出力例を示します。

[root@lexicon:apps]$ prtvtoc /dev/rdsk/c1t6d0s0
* /dev/rdsk/c1t6d0s0 partition map
*
* Dimensions:
*     512 bytes/sector
*     133 sectors/track
*      27 tracks/cylinder
*    3591 sectors/cylinder
*    4926 cylinders
*    4924 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      2    00          0   4111695   4111694
       1      3    01    4111695   1235304   5346998
       2      5    01          0  17682084  17682083
       3      0    00    5346999   4197879   9544877
       4      0    00    9544878   4197879  13742756
       5      0    00   13742757   3939327  17682083

Solstice DiskSuite ソフトウェアで使用していたディスクセットが存在する場合、それらのディスクセット上の状態データベースの複製のデフォルトサイズは 1034 ブロックです。一方、Solaris ボリュームマネージャで使用されるデフォルトサイズは 8192 ブロックです。 そのため、Solstice DiskSuite で追加されたディスクのスライス 7 は、Solaris ボリュームマネージャで追加されたディスクのスライス 7 よりも小さくなっています。

このディスクをディスクセットに追加すると、prtvtoc の出力は次のようになります。

[root@lexicon:apps]$ prtvtoc /dev/rdsk/c1t6d0s0
* /dev/rdsk/c1t6d0s0 partition map
*
* Dimensions:
*     512 bytes/sector
*     133 sectors/track
*      27 tracks/cylinder
*    3591 sectors/cylinder
*    4926 cylinders
*    4924 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      0    00      10773  17671311  17682083
       7      0    01          0     10773     10772
[root@lexicon:apps]$ 

ディスクセットの命名規則

ディスクセットのコンポーネント名は Solaris ボリュームマネージャの他のコンポーネント名と似ていますが、ディスクセットのコンポーネント名には、その一部としてディスクセット名が含まれます。

• ボリュームパス名では、/dev/md/ とパス内の実際のボリューム名の間にディスクセット名が入ります。

• 次の表に、ディスクセットボリューム名の例を示します。

  表 19–1 ボリューム名の例

  /dev/md/blue/dsk/d0	ディスクセット blue 内のブロック型ボリューム d0
  /dev/md/blue/dsk/d1	ディスクセット blue 内のブロック型ボリューム d1
  /dev/md/blue/rdsk/d126	ディスクセット blue 内の raw ボリューム d126
  /dev/md/blue/rdsk/d127	ディスクセット blue 内の raw ボリューム d127

例 — 2 つの共有ディスクセット

図 19–1 に、2 つの共有ディスクセットを使用する構成例を示します。

この構成では、ホスト A とホスト B がディスクセット A と B を共有しています。また、それぞれのホストには、共有されていないローカルディスクセットがあります。ホスト A に障害が発生すると、ホスト B がホスト A の共有ディスクセット (ディスクセット A) の制御を引き継ぎます。同じように、ホスト B に障害が発生すると、ホスト A がホスト B の共有ディスクセット (ディスクセット B) の制御を引き継ぎます。

図 19–1 ディスクセットの例

ディスクセットの背景情報

ディスクセットを使用するときには、ディスクセットの背景情報と ディスクセットの管理を参照してください。

ディスクセットの要件

• ディスクセットに接続されるホストごとに Solaris ボリュームマネージャを構成する必要があります。

• ディスクセットを作成するためには、各ホスト上にローカルの状態データベースが設定されていなければなりません。

• クラスタ環境でディスクセットを作成および使用する場合は、root がグループ (Group) 14 のメンバーでなければなりません。あるいは、各ホストの /.rhosts ファイルに、他のホスト名のエントリが含まれていなければなりません。

• ディスクセットの保守を行う場合は、ホストがディスクセットの所有者であるか、ディスクセットを予約していなければなりません。 (ホストは、ディスクセットに最初のドライブを置くことによって、暗黙的にディスクセットの所有者となります)。

• 使用中のドライブをディスクセットに追加することはできません。ドライブを追加する前に、それがファイルシステムやデータベースなどのアプリケーションによって使用されていないことを確認します。

• 保存したいデータが格納されているドライブをディスクセットに追加しないようにします。ドライブをディスクセットに追加すると、パーティションが再分割され、データが破壊されます。

• ホスト間で共有しようとする、ディスクセット内のすべてのディスクは各ホストに接続されており、各ホスト上でまったく同じパス、ドライバ、名前を持っていなければなりません。特に、共有ディスクドライブは、両方のホスト上で同じデバイス番号 (c#t#d#) を持っていなければなりません。 両方のホスト上で番号が異なると、ドライブをディスクセットに追加するときに、「drive c#t#d# is not common with host xxx」というメッセージが返されます。共有ディスクでは、同じドライバ名 (ssd) を使用する必要があります。 ディスクセット内に共有ディスクドライブを設定する手順については、ディスクセットにドライブを追加するにはを参照してください。

ディスクセットの指針

• システムに設定できるデフォルトのディスクセット数は 4 です。 /kernel/drv/md.conf ファイルを編集すれば、この数を 32 に増やすことができます。これについては、デフォルトのディスクセット数を増やすにはを参照してください。共有ディスクセットの数は常に md_nsets の値から 1 を引いた数です。これは、md_nsets に、ローカルディスクセットが含まれているためです。

• ローカルボリュームの管理と異なり、ディスクセット上の状態データベースの複製を手動で作成したり削除したりする必要はありません。Solaris ボリュームマネージャがディスクセットの各ディスクに適切な数の状態データベースの複製を配置します。

• ディスクセットにドライブを追加すると、Solaris ボリュームマネージャは、既存のドライブにある状態データベースの複製の配置を再調整します。必要であれば、後で metadb コマンドを使って複製の配置を変更できます。

ディスクセットの管理

ディスクセットの作成と構成は、Solaris ボリュームマネージャのコマンド行インタフェース (metaset コマンド) または Solaris 管理コンソール内の「拡張ディスク」を使って行います。

ディスクセットにドライブを追加したら、そのディスクセットを共有するホストは、ディスクセットを予約 (確保) したり解放したりすることができます。他のホストは、予約されたディスクセットのデータにアクセスすることはできません。 ディスクセットの保守を行うためには、そのホストがディスクセットを所有しているか予約していなければなりません。ホストは、ディスクセットに最初のドライブを設定することによって、暗黙的にディスクセットの所有者になります。

ディスクセットの取得

ホストは、ディスクセットのドライブを使用する前にディスクセットを取得する必要があります。ディスクセットを取得するには、次の 2 とおりの方法があります。

• 安全取得 - この方法でディスクセットを取得すると、Solaris ボリュームマネージャはこのディスクセットを確保しようとし、他のホストはこのディスクセットを解放しようとします。この解放 (つまり、取得) は失敗することもあります。

• 強制取得 - この方法でディスクセットを取得すると、Solaris ボリュームマネージャは、別のホストがこのディスクセットを取得しているかどうかに関係なく、ディスクセットを取得します。この方法は、通常、ディスクセットを共有するホストの 1 つが停止したり、他のホストと通信していないときに使用されます。これによって、そのディスクセットのすべてのディスクが新しいホストに引き継がれます。そして、この取得を行なったホストが状態データベースを読み込み、このディスクセットの共有ボリュームにアクセスできるようになります。この時点で他のホストがこのディスクセットをすでに取得していると、そのホストは取得が失われたためにパニックを起こします。

  ディスクセットを共有する 2 つのホストは相互に協調しているため、一般には、ディスクセットのドライブが同時に 2 つのホストによって取得されることはありません。正常な状態とは、両方のホストが動作し、相互に通信している状態のことです。

取得されているはずのドライブが取得されていない状態になると (おそらく、このディスクセットを共有する別のホストがこのドライブを強制的に確保したことが原因)、そのホストはパニックを起こします。これによって、2 つのホストが同時に同じドライブにアクセスした場合に起こり得るデータの消失が最小限に抑えられます。

ディスクセットの取得については、ディスクセットを取得するにはを参照してください。

ディスクセットの解放

ディスクセットの物理ドライブを保守する場合には、ディスクセットをあらかじめ解放しておくと便利です。ディスクセットを解放すると、そのディスクセットはホストからアクセスできなくなります。ディスクセットを共有しているホストが両方ともディスクセットを解放すると、どちらのホストもそのディスクセットのドライブにアクセスできなくなります。

ディスクセットの解放については、ディスクセットを解放するにはを参照してください。

シナリオ — ディスクセット

第 4 章「Solaris ボリュームマネージャの構成と使用」のサンプルシステムに基づく構成例は、ディスクセットを使って SAN (Storage Area Network) 構成上に存在する記憶領域をどのように管理するかを示しています。

サンプルシステムには、ファイバスイッチと SAN 記憶領域に接続されたもう 1 つのコントローラがあるものとします。SAN 構成の記憶領域は、SCSI や IDE ディスクなどの他のデバイスと同様に起動処理の初期段階では使用できないため、Solaris ボリュームマネージャは起動時に SAN 構成上の論理ボリュームを使用不能とみなします。 ただし、この記憶領域をディスクセットに追加し、ディスクセットツールを使って管理すれば、起動時の使用不能の問題は回避できます。また、SAN 構成上に接続されている記憶領域は、ディスクセットで制御された別個の名前空間内でローカル記憶領域から容易に管理できます。