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

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

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

ディスクセット内のボリューム上にあるファイルシステムが、ブート時に /etc/vfstab ファイルを介して自動的にマウントされることは通常ありません。これは、必要とされる、Solaris ボリュームマネージャ RPC デーモン (rpc.metad と rpc.metamhd) が、ブート時にはまだ実行されていないためです。また、ディスクセットの所有権はリブート時に失われます。/etc/inetd.conf ファイル内で Solaris ボリュームマネージャ RPC デーモンを無効にしないでください。これらのデーモンはデフォルトでブートするように構成されています。これらのデーモンは、Solaris ボリュームマネージャがその機能を完全に使用できるように、有効にしておく必要があります。

metaset コマンドの -A オプションによって、自動取得機能が有効になっている場合は、ブート時にディスクセットが自動的に取得されます。この場合、ディスクセット内のボリューム上にあるファイルシステムは、/etc/vfstab ファイルを使用して自動的にマウントできます。ブート時に自動取得を有効にするには、ディスクセットが 1 つのホストにだけ対応付けられていて、なおかつ自動取得機能が有効になっていなければなりません。ディスクセットは、ディスクセットの作成時でも作成後でも有効にできます。自動取得機能の詳細については、「自動取得ディスクセット」を参照してください。

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

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

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

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

ディスクセットの取得

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

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

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

  正常な状態においては、ディスクセットを共有している 2 つのホストが協調関係にあるため、ディスクセットのディスクを両者が同時に取得することはありません。正常な状態とは、両方のホストが動作し、相互に通信している状態のことです。

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

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

ディスクセットの解放

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

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

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

Solaris 9 9/04 リリースから、metaimport コマンドを使用して、ディスクセットのデバイス ID サポートが設定されている Solaris ボリュームマネージャ構成に、ディスクセット (複製されたディスクセットを含む) をインポートできるようになりました。また、metaimport コマンドを使用すると、インポートに利用できるディスクセットについて報告できます。

複製されたディスクセットを作成するには、リモート複製ソフトウェアを使用します。複製されたディスクセットを metaimport コマンドでインポートするには、ディスクセットの各ディスクの状態データベースの複製を含むスライスも、複製されたディスクセットの同じスライスに複製する必要があります。これは、EFI 以外のディスクではスライス 7 に相当し、EFI ディスクではスライス 6 に相当します。ディスクセットを複製する前に、複製するデータのディスク構成とリモートサイトのディスク構成が一致することを確認します。この手順は、状態データベースの複製とデータの両方が正確に複製されることを保証します。

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

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

Sun Cluster 環境では、metaimport コマンドは使用できません。

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

ディスクセットに新しいディスクが追加されると、Solaris ボリュームマネージャがディスクのフォーマットをチェックします。必要に応じて、Solaris ボリュームマネージャはディスクのパーティションを再分割し、状態データベースの複製が納まるだけの領域を備え、適切に構成されたスライス 7 がディスクに必ずあるようにします。スライス 7 の正確な容量は、ディスクのジオメトリによって決まります。ただし、4M バイトよりは小さくなることはなく、通常は 6M バイト近くになります (シリンダ境界がどこにあるかによる)。

デフォルトでは、Solaris ボリュームマネージャはスライス 7 に状態データベースの複製を 1 つ格納します。複数の状態データベースの複製をスライスに収めるために、スライス 7 のデフォルト容量を増やしたり、状態データベースの複製を小さくしたりできます。

スライス 7 の最小限のサイズは、状態データベースの複製のサイズ、状態データベースの複製に保管する情報など、さまざまな要因によって、将来変わってくる可能性があります。複数所有者ディスクセットの場合、状態データベースの複製のデフォルトサイズは 16M バイトです。

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

• セクター 0 から始まる

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

• マウントできない

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

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

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

この出力から、ディスクにスライス 7 がないことがわかります。したがって、ディスクセットにディスクを追加すると、Solaris ボリュームマネージャがディスクのパーティションを再分割します。以下に、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]$ 

この出力から、ディスクが再分割されてシリンダ 0 から始まるスライス 7 が含まれ、状態データベースの複製を格納できるだけの領域が確保されていることがわかります。ディスクセットに追加した各ディスクに適切なスライス 7 がある場合は、再フォーマットは行なわれません。

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

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

ディスクセットのボリューム名は、Solaris ボリュームマネージャの他のコンポーネント名と同様です。ただし、ディスクセット名が名前の中に含まれます。たとえば、ボリュームパス名では、/dev/md/ とパス内の実際のボリューム名の間にディスクセット名が入ります。

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

同様に、ホットスペア集合の場合も、その名前の一部にディスクセット名が含まれます。

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

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

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

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