ローカルディスクセットの管理とは異なり、名前付きディスクセットの場合、状態データベースの複製を手動で作成したり削除したりする必要はありません。 なぜなら、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 とおりの方法があります。
安全取得 - あるホストがあるディスクセットを安全に取得するためには、現在そのディスクセットを取得しているホストがそのディスクセットを解放する必要があります。 ディスクセットの解放前に別のホストがその取得を試みると、解放できなくなり、よって取得もできなくなります。
強制取得 - この方法でディスクセットを取得すると、Solaris ボリュームマネージャは、別のホストがこのディスクセットを取得しているかどうかに関係なく、ディスクセットを取得します。 この方法は、通常、ディスクセットを共有するホストの 1 つが停止したり、他のホストと通信していないときに使用されます。 これによって、そのディスクセットのすべてのディスクが新しいホストに引き継がれます。 そして、この取得を行なったホストが状態データベースを読み込み、このディスクセットの共有ボリュームにアクセスできるようになります。 この時点で他のホストがこのディスクセットをすでに取得していると、そのホストは取得が失われたためにパニックを起こします。
正常な状態においては、ディスクセットを共有している 2 つのホストが協調関係にあるため、ディスクセットのディスクを両者が同時に取得することはありません。 正常な状態とは、両方のホストが動作し、相互に通信している状態のことです。
取得されているはずのディスクが取得されていない状態になると (ディスクセットを共有する別のホストがこのディスクを強制的に取得した場合など)、そのホストはパニックを起こします。 これによって、2 つのホストが同時に同じディスクにアクセスした場合に起こり得るデータの消失が最小限に抑えられます。
ディスクセットの取得または予約の詳細については、「ディスクセットを取得するには」を参照してください。
ディスクセット内の物理ディスクを保守するときには、ディスクセットを解放しておくと便利です。 ディスクセットを解放すると、そのディスクセットはホストからアクセスできなくなります。 ディスクセットを共有しているホストが両方ともディスクセットを解放すると、どちらのホストもそのディスクセットのディスクにアクセスできなくなります。
ディスクセットの解放の詳細については、「ディスクセットを解放するには」を参照してください。
metaimport コマンドを使用すると、ディスクセット内にデバイス ID サポートを持っている既存の Solaris ボリュームマネージャ構成に、ディスクセットをインポートできます。 また、metaimport コマンドを使用すると、インポートに利用できるディスクセットについて報告できます。
ディスクセット内のあるディスクにボリュームまたは状態データベースの複製が含まれていない場合、metaimport コマンドはそのディスクをインポートしません。 あるディスクセットを別のシステムにインポートすると、そのディスクセットからあるディスクがなくなったように見えることがあります。 このような状況は、ボリュームまたは状態データベースの複製がそのディスクに追加されていなかった (あるいは、そのディスクからすでに削除されていた) 場合に発生します。 たとえば、Solaris ボリュームマネージャディスクセットに許可される状態データベースの複製の最大数は 50 です。 あるディスクセットに 60 台のディスクがある場合、10 台のディスクには状態データベースの複製が含まれないため、それらのディスクをインポートするには、それらのディスクにボリュームが含まれている必要があります。
ディスクセットのインポートに関連する作業については、「ディスクセットのインポート 」を参照してください。
ディスクセットに新しいディスクを追加すると、Solaris ボリュームマネージャは、ディスクフォーマットを調べ、必要に応じてディスクのパーティションを再分割して、状態データベースの複製を格納できるように適切に設定されたスライス 7 を作成します。 スライス 7 の厳密なサイズはディスクの幾何学的な構造によって異なりますが、通常は、4M バイトを下回ることなく、おおよそ 6M バイト程度です (シリンダ境界がどこにあるかによって異なります)。
スライス 7 の最小限のサイズは、状態データベースの複製のサイズ、状態データベースの複製に保管する情報など、さまざまな要因によって、将来変わってくる可能性があります。
ディスクセットで使用するディスクには、次の条件を満たしたスライス 7 を与える必要があります。
セクター 0 から始まる
ディスクラベルと状態データベースの複製とを格納できる領域がある
マウントできない
スライス 2 などの他のスライスと重なり合わない
既存のパーティションテーブルがこれらの条件を満たしていない場合、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 ボリュームマネージャの他のコンポーネント名と似ていますが、ディスクセットのコンポーネント名には、その一部としてディスクセット名が含まれます。
ボリュームパス名では、/dev/md/ とパス内の実際のボリューム名の間にディスクセット名が入ります。
次の表に、ディスクセットボリューム名の例を示します。
/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 |
同様に、ホットスペア集合の場合も、その名前の一部にディスクセット名が含まれます。
図 201 に、2 つの共有ディスクセットを使用する構成例を示します。
この構成では、ホスト A とホスト B はディスクセット red と blue を共有します。 各ホストは独自のローカルディスクセットを持っており、これらは共有されません。 ホスト A に障害が発生すると、ホスト B がホスト A の共有ディスクセット (ディスクセット red) の制御を引き継ぎます。 同様に、ホスト B に障害が発生すると、ホスト A がホスト B の共有ディスクセット (ディスクセット blue) の制御を引き継ぎます。