この章では、ディスクセットの概念について説明します。関連する作業の実行手順については、第 19 章「ディスクセット (作業)」を参照してください。
この章では、次の内容について説明します。
この節では、今回の Solaris リリースで導入された、ディスクセットの新機能について説明します。
Solaris の新機能の一覧と Solaris のリリースの説明については、『Solaris 10 の概要』を参照してください。
ディスクセットとは、論理ボリュームとホットスペアを含む物理的な記憶領域ボリュームの集まりのことです。ボリュームやホットスペア集合は、そのディスクセット内のドライブだけで構成される必要があります。ディスクセット内で作成したボリュームは、物理スライスと同じように使用できます。このボリュームを使用して、ファイルシステムの作成やマウント、およびデータの格納が可能です。
ディスクセットは、SPARC ベースのプラットフォームでも x86 ベースのプラットフォームでもサポートされています。
この節では、 Solaris ボリュームマネージャで利用できるディスクセットのタイプについて説明します。
どのホストにも 1 つのローカルディスクセットがあります。ローカルディスクセットは、ホスト上のすべてのディスクのうち、名前付きディスクセットに含まれないディスクで構成されます。ローカルディスクセットは特定のホストだけに属します。ローカルディスクセットには、そのホストの構成を記録した状態データベースが格納されています。ローカルディスクセット内のボリュームやホットスペア集合は、ローカルディスクセット内のドライブだけで構成されます。
ローカルディスクセットに加えて、ホストは名前付きディスクセットにも参加できます。名前付きディスクセットは、ローカルディスクセットではない任意のディスクセットです。以下にあげるタイプの名前付きディスクセットを実装して、ボリュームを管理できます。どのタイプを実装するかは、システムの構成によって異なります。
「共有ディスクセット」は、複数のホストで共有できるディスクセットです。共有ディスクセットは参加しているすべてのホストから認識できますが、アクセスできるのはそのディスクセットの所有者だけです。各ホストは共有ディスクセットを制御できますが、1 度に 1 つのホストだけが制御できます。さらに、共有ディスクセットは独自の名前空間を提供します。ボリュームはこの名前空間内で管理されます。
共有ディスクセットを使用すると、データの冗長性と可用性が向上します。あるホストで障害が発生すると、そのホストのディスクセットを別のホストで引き継ぐことができます (この種の構成を「フェイルオーバー構成」と呼ぶ)。
共有ディスクセットは、Sun Cluster、Solstice HA (High Availability)、またはサポートされる他社製の HA フレームワークと組み合わせて使用することを想定しています。Solaris ボリュームマネージャ単体では、フェイルオーバー構成を実装するのに必要なすべての機能が提供されるとは限りません。
各ホストでディスクセットを制御できますが、1 つのホストが 1 時点で制御できるディスクセットは 1 つだけです。
Solaris 9 4/04 リリースで自動取得機能が利用できるようになるまで、Solaris ボリュームマネージャは、/etc/vfstab ファイル経由による、ディスクセット上のファイルシステムの自動マウントをサポートしていませんでした。Solaris ボリュームマネージャでディスクセット上のファイルシステムにアクセスするには、このディスクセットを取得するコマンド、つまり、metaset -s setname -t コマンドを、システム管理者が手動で実行する必要がありました。
自動取得機能を使用すると、ブート時にディスクセットが自動的にアクセスされるように設定できます。この設定には、metaset -s setname -A enable コマンドを使用します。自動取得機能によって、ブート時に /etc/vfstab ファイル内のファイルシステムに対して、マウントオプションを定義できます。この機能を使用すると、有効なディスクセット内のボリューム上にあるファイルシステム用のマウントオプションを、/etc/vfstab ファイルに定義できます。
自動取得機能をサポートするのは、シングルホストのディスクセットだけです。自動取得機能を使用するには、ディスクセットがほかのシステムによって共有されていないことが条件となります。共有ディスクセットは、自動取得機能を使用するように設定できません。 metaset -A コマンドは失敗します。ただし、ディスクセットから他のホストを削除すれば、自動取得するように設定できます。同様に、自動取得ディスクセットにはほかのホストを追加できません。しかし、自動取得機能を無効にすると、そのディスクセットにほかのホストを追加できるようになります。
Sun Cluster 環境では、自動取得機能は無効になります。Sun Cluster 自身がディスクセットを取得または解放するためです。
自動取得機能の詳細については、metaset(1M) の -A オプションを参照してください。
Sun Cluster 環境で作成された名前付きディスクセットのことを複数所有者ディスクセットといいます。複数所有者ディスクセットを使用すると、複数のノードがディスクセットの所有権を共有したり、共有ディスクに同時にアクセスしたりできます。複数所有者ディスクセット内のすべてのディスクとボリュームは、クラスタ内のすべてのノードから直接アクセスできます。各複数所有者ディスクセットは、そのディスクセットに追加されたホストリストを持っています。結果として、同じクラスタ構成内の各複数所有者ディスクセットは、異なる (ときには、重複する) ホストセットを持つことができます。
各複数所有者ディスクセットはマスターノードを持っています。マスターノードの機能は、状態データベースの複製の変更を管理および更新することです。ディスクセットごとにマスターノードが存在するため、複数のマスターが共存することもあります。マスターの選ばれ方には、2 とおりあります。まず、ディスクセットに最初のディスクを追加したときには、そのノードがマスターになります。もうひとつは、マスターノードがパニックになり、失敗したときです。この場合は、最も低いノード ID を持つノードがマスターノードになります。
複数所有者ディスクセットの機能が有効なのは、複数所有者ディスクセット記憶領域を管理する Sun Cluster 環境に限られます。Solaris Volume Manager for Sun Cluster機能は、Sun Cluster 10/04 ソフトウェアコレクション以降の Sun Cluster リリースと Oracle Real Applications Clusters などのアプリケーションで使用できます。Solaris Volume Manager for Sun Clusterの詳細については、第 4 章「Solaris Volume Manager for Sun Cluster (概要)」を参照してください。
複数所有者ディスクセットを構成するには、Solaris OS とともに次のソフトウェアをインストールしておく必要があります。
Sun Cluster 初期クラスタフレームワーク
Sun Cluster Support for Oracle Real Application Clusters ソフトウェア
Oracle Real Application Clusters ソフトウェア
Sun Cluster と Oracle Real Application Clusters ソフトウェアの設定については、『Sun Cluster ソフトウェアのインストールガイド (Solaris OS 版)』、および『Sun Cluster Data Service for Oracle Real Application Clusters ガイド (Solaris OS 版)』を参照してください。
ローカルディスクセットを管理する場合とは異なり、ディスクセットの状態データベースを手動で作成したり削除したりする必要はありません。なぜなら、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/ とパス内の実際のボリューム名の間にディスクセット名が入ります。
次の表に、ディスクセットボリューム名の例を示します。
表 18–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 |
同様に、ホットスペア集合の場合も、その名前の一部にディスクセット名が含まれます。
図 18–1 に、2 つのディスクセットを使用する構成例を示します。
この構成では、ホスト A とホスト B はディスクセット red と blue を共有します。各ホストは独自のローカルディスクセットを持っており、これらは共有されません。ホスト A に障害が発生すると、ホスト B がホスト A の共有ディスクセットであるディスクセット red の制御を引き継ぎます。同様に、ホスト B に障害が発生すると、ホスト A がホスト B の共有ディスクセットであるディスクセット blue の制御を引き継ぎます。
ディスクセットを使用するときには、次の指針を考慮してください。
ディスクセットに接続されるホストごとに Solaris ボリュームマネージャを構成する必要があります。
ディスクセットを作成するためには、各ホスト上にローカルの状態データベースが設定されていなければなりません。
ディスクセットを作成して、そのディスクセットのボリュームを作成する手順では、まず最初に、ディスクセットを作成します。次に、そのディスクセットにディスクを追加します。最後に、そのディスクセットにボリュームを作成します。
クラスタ環境内でディスクセットを作成および使用する場合、root はシステム管理グループ (Group 14) のメンバーである必要があります。あるいは、各ホスト上にある /.rhosts ファイルに、そのディスクセットに関連付けられたほかのホスト名のエントリがなければなりません。
この手順は、SunCluster 3.x 環境では不要です。
ディスクセットの保守を行うためには、そのホストがディスクセットを所有しているか予約していなければなりません。ディスクセットに最初のドライブを設定したホストは、暗黙的にディスクセットの所有者になります。
ファイルシステム、データベース、またはほかのアプリケーションに使用されているドライブは、ディスクセットに追加できません。ドライブを追加する前に、そのディスクが使用中でないことを確認してください。
保存しておく必要のある既存のデータが入っているドライブをディスクセットに追加してはなりません。ディスクセットにディスクを追加すると、パーティションが再分割され、データが破壊されます。
ローカルボリュームの管理と異なり、ディスクセット上の状態データベースの複製を手動で作成したり削除したりする必要はありません。Solaris ボリュームマネージャは、ディスクセットの各ドライブに適切な数の状態データベースの複製を配置しようとします。
ディスクセットにドライブを追加すると、Solaris ボリュームマネージャは、既存のドライブにある状態データベースの複製の配置を再調整します。必要であれば、後で metadb コマンドを使って複製の配置を変更できます。
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 つのコントローラがあるものとします。ブートプロセスの段階では、システムは SCSI ディスクや IDE ディスクの場合と同様、SAN ファブリック上の記憶領域を使用できません。Solaris ボリュームマネージャは、ブート時にファブリック上の論理ボリュームについて、使用不可であると伝えます。しかし、ディスクセットに記憶領域を追加し、さらにディスクセットツールで記憶領域を管理することによって、ブート時の可用性に関する問題を回避できます。また、ファブリックに接続された記憶領域は、ローカルな記憶領域からディスクセットが制御する独立した名前空間内で容易に管理できます。