test

Solaris ボリュームマネージャの管理

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

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

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

ディスクセットの紹介

「ディスクセット 」は、論理ボリュームやホットスペアを含む物理的な記憶領域ボリュームの集まりです。 ボリュームやホットスペア集合は、そのディスクセット内のドライブだけで構成される必要があります。 ディスクセット内で作成したボリュームは、物理スライスと同じように使用できます。 このボリュームを使用して、ファイルシステムの作成やマウント、およびデータの格納が可能です。

注

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

ディスクセットのタイプ

この節では、 Solaris ボリュームマネージャで利用できるディスクセットのタイプについて説明します。

ローカルディスクセット

どのホストにも 1 つのローカルディスクセットがあります。 「ローカルディスクセット」は、ホスト上のすべてのディスクのうち、名前付きディスクセットに含まれないディスクで構成されます。 ローカルディスクセットは特定のホストだけに属します。 ローカルディスクセットには、そのホストの構成を記録した状態データベースが格納されています。 ローカルディスクセット内のボリュームやホットスペア集合は、ローカルディスクセット内のドライブだけで構成されます。

名前付きディスクセット

ローカルディスクセットに加えて、ホストは名前付きディスクセットにも参加できます。 「名前付きディスクセット」は、ローカルディスクセットではない任意のディスクセットです。 以下にあげるタイプの名前付きディスクセットを実装して、ボリュームを管理できます。どのタイプを実装するかは、システムの構成によって異なります。

共有ディスクセット

「共有ディスクセット」は、複数のホストで共有できるディスクセットです。 共有ディスクセットは参加しているすべてのホストから認識できますが、アクセスできるのはそのディスクセットの所有者だけです。 各ホストは共有ディスクセットを制御できますが、1 度に 1 つのホストだけが制御できます。 さらに、共有ディスクセットは独自の名前空間を提供します。ボリュームはこの名前空間内で管理されます。

共有ディスクセットを使用すると、データの冗長性と可用性が向上します。 一方のホストに障害が発生しても、そのディスクセットを他方のホストが引き継ぐことができます。 このタイプの構成は「フェイルオーバー構成」と呼ばれます。

注

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

自動取得ディスクセット

Solaris 9 4/04 リリースで自動取得機能が利用できるようになるまで、Solaris ボリュームマネージャは、/etc/vfstab ファイル経由による、ディスクセット上のファイルシステムの自動マウントをサポートしていませんでした。 Solaris ボリュームマネージャでディスクセット上のファイルシステムにアクセスするには、このディスクセットを取得するコマンド、つまり、metaset -s setname -t コマンドを、システム管理者が手動で実行する必要がありました。

自動取得機能が利用可能になった現在は、ディスクセットがホスト起動時に自動的に取得されるよう、設定できるようになりました。 この機能を使用すると、有効なディスクセット内のボリューム上にあるファイルシステム用のマウントオプションを、/etc/vfstab ファイルに定義できます。

自動取得機能をサポートするのは、シングルホストのディスクセットだけです。 自動取得機能を使用するには、ディスクセットがほかのホストによって共有されていないことが条件となります。 共有ディスクセットは、自動取得機能を使用するようには設定できません。 共有ディスクセット上で自動取得機能を有効にすると、metaset -A コマンドが失敗します。 しかし、共有ディスクセットからほかのホストを削除して、シングルホストディスクセットにすると、自動取得機能は有効にできます。 同様に、自動取得ディスクセットにはほかのホストを追加できません。 しかし、自動取得機能を無効にすると、そのディスクセットにほかのホストを追加できるようになります。

注

Sun Cluster 環境では、自動取得機能は無効になります。 Sun Cluster 自身がディスクセットを取得または解放するためです。

自動取得機能の詳細については、metaset(1M) のマニュアルページの -A オプションの説明を参照してください。

マルチオーナーディスクセット

Solaris 9 9/04 リリース以降、Solaris ボリュームマネージャは Sun Cluster 環境の記憶装置をマルチオーナーディスクセットで管理できるようになりました。 「マルチオーナーディスクセット」を使用すると、クラスタ内の複数のノードが、ディスクセットの所有権を共有したり共有ディスクに同時にアクセスしたりできます。 マルチオーナーディスクセット内のすべてのディスクとボリュームは、クラスタ内のすべてのノードから直接アクセスできます。 各マルチオーナーディスクセットは、そのディスクセットに追加されたノードリストを持っています。 結果として、同じクラスタ構成内の各マルチオーナーディスクセットは、異なる (ときには、重複する) ノードセットを持つことができます。

各マルチオーナーディスクセットはマスターノードを持っています。 マスターノードの機能は、状態データベースの複製の変更を管理および更新することです。 ディスクセットごとにマスターノードが存在するため、複数のマスターが共存することもあります。 マスターの選ばれ方には、2 とおりあります。 まず、ディスクセットに最初のディスクを追加したときには、そのノードがマスターになります。 もうひとつは、マスターノードがパニックになり、失敗したときです。 この場合は、最も低いノード ID を持つノードがマスターノードになります。

マルチオーナーディスクセットは Sun Cluster および Oracle9i Real Application Clusters などのアプリケーションの組み合わせで機能します。 Sun Cluster の互換性のあるリリースについては、http://wwws.sun.com/software/clusterを参照してください。 Solaris Volume Manager for Sun Cluster の詳細については、第4章「Solaris Volume Manager for Sun Cluster (概要)」を参照してください。

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

ローカルディスクセットの管理とは異なり、名前付きディスクセットの場合、状態データベースの複製を手動で作成したり削除したりする必要はありません。 なぜなら、Solaris ボリュームマネージャが自動的に、ディスクセット内の各ディスク (のスライス 7) に状態データベースの複製を 1 つずつ配置するためです。 ディスクセット当たり最大 50 の複製を作成できます。

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

自動取得が有効になっていない場合、名前付きディスクセット内のボリューム上にあるファイルシステムは、起動時に /etc/vfstab ファイル経由で自動的にマウントされません。 これは、必要な Solaris ボリュームマネージャRPC デーモン (rpc.metad rpc.metamedd と rpc.metamhd) が起動プロセス中のより早い時点に起動されていないためです。

注

/etc/inetd.conf ファイル内で Solaris ボリュームマネージャRPC デーモンを無効にしてはなりません。 これらのデーモンはデフォルトで起動するように構成されています。 これらのデーモンは、Solaris ボリュームマネージャがその機能を完全に使用できるように、有効にしておく必要があります。

さらに、自動取得が有効になっていない場合、名前付きディスクセットの所有権はシステムの再起動時に失われます。自動取得機能の詳細については、 「自動取得ディスクセット」を参照してください。

注

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

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

共有ディスクセットにディスクを追加したら、そのディスクセットを共有するホストは、ディスクセットを「予約」(または「取得」) したり、「解放」したりできます。 あるホストがあるディスクセットを予約している場合、ほかのホストはそのディスクセットのディスクを読み取ることはできますが、書き込むことはできません。 ディスクセットの保守を行うためには、そのホストがディスクセットを所有しているか予約していなければなりません。 ディスクセットに最初のディスクを設定したホストは、暗黙的にディスクセットの所有者になります。

metaimport コマンドを使用すると、ディスクセット (ほかのシステム上で作成されたディスクセットを含む) を既存の Solaris ボリュームマネージャ構成にインポートできます。

ディスクセットの取得

あるホストがあるディスクセット内のディスクを使用したい場合、そのホストはそのディスクセットを取得する必要があります。 ディスクセットを取得するには、次の 2 とおりの方法があります。

注

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

ディスクセットの取得または予約の詳細については、「ディスクセットを取得するには」を参照してください。

ディスクセットの解放

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

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

ディスクセットのインポート

metaimport コマンドを使用すると、ディスクセット内にデバイス ID サポートを持っている既存の Solaris ボリュームマネージャ構成に、ディスクセットをインポートできます。 また、metaimport コマンドを使用すると、インポートに利用できるディスクセットについて報告できます。

ディスクセット内のあるディスクにボリュームまたは状態データベースの複製が含まれていない場合、metaimport コマンドはそのディスクをインポートしません。 あるディスクセットを別のシステムにインポートすると、そのディスクセットからあるディスクがなくなったように見えることがあります。 このような状況は、ボリュームまたは状態データベースの複製がそのディスクに追加されていなかった (あるいは、そのディスクからすでに削除されていた) 場合に発生します。 たとえば、Solaris ボリュームマネージャディスクセットに許可される状態データベースの複製の最大数は 50 です。 あるディスクセットに 60 台のディスクがある場合、10 台のディスクには状態データベースの複製が含まれないため、それらのディスクをインポートするには、それらのディスクにボリュームが含まれている必要があります。

ディスクセットのインポートに関連する作業については、「ディスクセットのインポート 」を参照してください。

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

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

注

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

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

既存のパーティションテーブルがこれらの条件を満たしていない場合、Solaris ボリュームマネージャはディスクを再分割します。 各ディスク上で、Solaris ボリュームマネージャによって使用される小さい領域が、スライス 7 として確保されます。 各ディスク上の残りの領域は、スライス 0 に割り当てられます。パーティションが再分割されると、ディスク上のすべてのデータが失われます。

ヒント

ディスクセットにディスクを追加した後、ディスクのパーティションは必要に応じて再分割できますが、スライス 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]$

ディスクセットに追加するディスク上に適切なスライス 7 (シリンダ 0 から開始し、状態データベースの複製を格納できる十分な領域がある) がある場合は、ディスクのパーティション分割は行われません。

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

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

表 201 ボリューム名の例

/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 つの共有ディスクセット

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

この構成では、ホスト A とホスト B はディスクセット red と blue を共有します。 各ホストは独自のローカルディスクセットを持っており、これらは共有されません。 ホスト A に障害が発生すると、ホスト B がホスト A の共有ディスクセット (ディスクセット red) の制御を引き継ぎます。 同様に、ホスト B に障害が発生すると、ホスト A がホスト B の共有ディスクセット (ディスクセット blue) の制御を引き継ぎます。

図 201 ディスクセットの例

2 つのホストが、共有ディスクセットによって 3 つのディスクを共有しながら、それぞれのローカルディスクセット内の 3 つのディスクは独占的に使用しています。

ディスクセットを使用するときの指針

ディスクセットを使用するときには、次の指針を考慮してください。

ディスクセット内で非同期的に共有される記憶領域

Solaris ボリュームマネージャの以前のバージョンでは、ディスクセット内のホスト間で共有しようとしているすべてのディスクは、各ホストに接続する必要がありました。 また、このようなディスクは各ホストに対して、まったく同じパス、ドライバ、および名前を持つ必要がありました。 特に、共有ディスクドライブは、同じ場所 (/dev/rdsk/c#t#d#) にある両方のホストから見ることができる必要がありました。 さらに、共有されるディスクは同じドライバ名 (ssd) を使用する必要がありました。

現在の Solaris OS リリースでは、共通にアクセスできる記憶領域に対して異なるパスを持っているシステム同士は、あるディスクセットに対して同時にアクセスできません。 ディスクセットのデバイス ID サポートの導入により、Solaris ボリュームマネージャは、名前付きディスクセット内におけるディスクの移動を自動的に追跡できます。

注

Sun Cluster 環境では、ディスクセットのデバイス ID サポートはありません。

最新の Solaris OS にアップグレードしたとき、ディスクの追跡を有効にするには、一度、ディスクセットを取得する必要があります。 ディスクセットの取得の詳細については、「ディスクセットを取得するには」を参照してください。

自動取得機能が有効でない場合、各ディスクセットを手動で取得する必要があります。 自動取得機能が有効である場合、各ディスクセットはシステムの再起動時に自動的に取得されます。 自動取得機能の詳細については、「自動取得ディスクセット」を参照してください。

この拡張されたデバイス ID サポートを使用すると、ディスクセット (異なるシステム上で作成されたディスクセットを含む) をインポートできます。 ディスクセットのインポートの詳細については、「ディスクセットのインポート 」を参照してください。

シナリオ ディスクセット

次の例では、第5章「Solaris ボリュームマネージャの構成と使用」のサンプルシステムを使用して、SAN (Storage Area Network) ファブリック上にある記憶領域をディスクセットを使用して管理する方法を示します。

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