この章では、Solaris ボリュームマネージャの全体的な構造について説明します。この章の内容は次のとおりです。
Solaris ボリュームマネージャは、多数のディスクとそれらのディスク上のデータを管理するためのソフトウェア製品です。 Solaris ボリュームマネージャにはいろいろな用途がありますが、ほとんどの場合、次の目的で使用されます。
記憶容量を増加する
データ可用性を向上する
大規模な記憶デバイスの管理を容易にする
状況によっては、Solaris ボリュームマネージャを使用すると、入出力性能が向上することもあります。
Solaris ボリュームマネージャは、仮想ディスクを使用して、物理ディスクとその関連データの管理を行います。 Solaris ボリュームマネージャでは、仮想ディスクをボリュームと呼びます。 ただし、従来からの慣習により、コマンド行ユーティリティではボリュームを「メタデバイス」と呼ぶこともあります。
アプリケーションやファイルシステムから見ると、ボリュームは物理ディスクと同じように機能します。 Solaris ボリュームマネージャは、ボリュームに対する入出力要求を、そのボリュームを構成するメンバーディスクに対する入出力要求に変換します。
Solaris ボリュームマネージャのボリュームは、ディスクスライスまたはほかの Solaris ボリュームマネージャボリュームから作成されます。 Solaris 管理コンソールに組み込まれているグラフィカルユーザーインタフェースを使えば、ボリュームを簡単に作成できます。 Solaris 管理コンソール内の「拡張ストレージ」を使用することで、存在しているすべてのボリュームの情報を表示できます。 管理者は、ウィザードのステップに従うだけで、Solaris ボリュームマネージャのあらゆる種類のボリュームとコンポーネントを簡単に作成できます。 また、Solaris ボリュームマネージャのコマンド行ユーティリティを使用しても、ボリュームの作成や変更が行えます。
たとえば、大きな記憶領域を 1 つのボリュームとして作成したい場合、Solaris ボリュームマネージャを使用すると、複数のスライスの集まりを単一の大容量ボリュームとして扱うように、システムを設定できます。 このような複数のスライスから作成した単一のボリュームは、ただちに、「実」スライスまたは「実」デバイスと同じように使用できます。
ボリュームの詳細については、「ボリューム」を参照してください。
Solaris ボリュームマネージャでは、RAID 1 (ミラー) ボリュームや RAID 5 ボリュームを使ってデータの信頼性と可用性を高めることができます。 Solaris ボリュームマネージャのホットスペアを使用すれば、ミラーや RAID 5 ボリュームのデータ可用性をさらに向上できます。
構成の設定が完了したら、Solaris 管理コンソール内の「拡張ストレージ」を使って動作状況を検査できます。
Solaris ボリュームマネージャと対話するには、次のどちらかの方法を使用します。
Solaris 管理コンソール このツールは、ボリューム管理機能とのグラフィカルユーザーインタフェースとして機能します。 図 31 に、Solaris 管理コンソール内の「拡張ストレージ」の使用例を示します。 このインタフェースは、ボリュームや、ホットスペア、状態データベースの複製など、Solaris ボリュームマネージャのコンポーネントをグラフィカルに表示します。 このインタフェースではウィザードを使って Solaris ボリュームマネージャコンポーネントを操作できるため、ディスクの構成や既存の構成を簡単に変更できます。
コマンド行インタフェース ボリューム管理機能を実行するためのコマンドが用意されています。 Solaris ボリュームマネージャのコアコマンドは、metainit や metastat のように meta で始まります。 Solaris ボリュームマネージャのコマンドの一覧については、付録B「Solaris ボリュームマネージャのコマンド行リファレンス」を参照してください。
Solaris ボリュームマネージャを管理するときには、コマンド行インタフェースとグラフィカルユーザーインタフェースを同時に使用してはなりません。 構成に対して矛盾した変更が加えられ、予測していない動作が生じることがあります。 どちらのツールを使っても、Solaris ボリュームマネージャを管理することは可能ですが、両方のツールを同時に使用することはできません。
Solaris ボリュームマネージャのグラフィカルユーザーインタフェース (拡張ストレージ) は Solaris 管理コンソールの一部です。 このグラフィカルユーザーインタフェースにアクセスするには、次の手順に従います。
次のコマンドを使って、ホストシステム上で Solaris 管理コンソールを起動します。
% /usr/sbin/smc |
「このコンピュータ (This Computer)」をダブルクリックします。
「Storage」をダブルクリックします。
「拡張ストレージ (Enhanced Storage)」をダブルクリックして、 Solaris ボリュームマネージャツールを起動します。
ログインを促すプロンプトが表示されたら、root または同等のアクセス権をもつユーザーとしてログインします。
適切なアイコンをダブルクリックして、ボリュームや、ホットスペア集合、状態データベースの複製、ディスクセットを管理します。
Solaris 管理コンソールの各ツールは、ページの下部またはウィンドウパネル左側に情報を表示します。 このインタフェースでの作業について情報が必要な場合は、いつでも「ヘルプ (Help)」を選択できます。
Solaris ボリュームマネージャを使用するための要件は、次のとおりです。
Solaris ボリュームマネージャを管理するためにはルート権限が必要です。 Solaris 管理コンソールの User Profile 機能によって同等の権限が与えられていれば、Solaris 管理コンソールを使って管理を行うことができます。 ただし、Solaris ボリュームマネージャのコマンド行インタフェースを使用できるのは、スーパーユーザーだけです。
Solaris ボリュームマネージャを使ってボリュームを作成するためには、少なくとも 3 つの状態データベースの複製が、 Solaris ボリュームマネージャを稼働するシステム上に存在していなければなりません。 最大限の信頼性を確保するためには、これらの複製を異なるコントローラと異なるディスクに配置するようにします。 状態データベースの複製の詳細については、「Solaris ボリュームマネージャの状態データベースと状態データベースの複製について」を、状態データベースの複製を作成する手順については、「状態データベースの複製の作成 」を参照してください。
Solaris ボリュームマネージャで作成できるコンポーネントの基本的なタイプは、ボリューム、ディスクセット、状態データベースの複製、ホットスペア集合の 4 つです。 次の表に、Solaris ボリュームマネージャのコンポーネントの概要を示します。
表 31 Solaris ボリュームマネージャのコンポーネントの要約
「ボリューム」とは、物理的には複数のスライスの集合であるが、論理的には単一の論理デバイスとしてシステムに認識される概念の名前です。 実際には、ボリュームは標準 UNIX の擬似または仮想デバイスと同義です。
これまで、Solstice DiskSuiteTM 製品ではこのような論理デバイスを「メタデバイス」と呼んでいましたが、 このマニュアルでは、簡潔性と標準化のために「ボリューム」と呼びます。
ボリュームには、RAID 0 (連結方式およびストライプ方式) ボリューム、RAID 1 (ミラー) ボリューム、RAID 5 ボリューム、ソフトパーティション、トランザクションロギングボリュームがあります。
ボリュームの作成や管理には、Solaris 管理コンソール内の「拡張ストレージ」かコマンド行ユーティリティを使用します。
表 32 ボリュームクラス
ボリューム |
説明 |
---|---|
そのまま使用することもでき、また、ミラーおよびトランザクションデバイスの基本的な構築ブロックとして使用することもできます。 RAID 0 ボリューム自体にはデータの冗長性はありません。 |
|
複数のコピーを保持することによってデータを複製します。 RAID 1 ボリュームは、サブミラーと呼ばれる 1 つまたは複数の RAID 0 ボリュームから構成されます。 |
|
パリティ情報を使ってデータを複製します。 ディスクに障害が発生すると、利用可能なデータとパリティ情報から失われたデータが復元されます。 RAID 5 ボリュームは、通常、複数のスライスで構成されています。 1 スライスに相当する領域がパリティ情報に割り当てられますが、パリティは RAID 5 ボリュームのすべてのスライスに分散されます。 |
|
UFS ファイルシステムのログとして使用されます (ただし、この目的のためには UFS ロギングを推奨します)。 トランザクションボリュームは、マスターデバイスとロギングデバイスから構成されています。 これらのデバイスには、スライス、RAID 0 ボリューム、RAID 1 ボリューム、または RAID 5 ボリュームを使用できます。 マスターデバイスには、UFS ファイルシステムが含まれています。 |
|
ソフトパーティション |
スライスまたは論理ボリュームをより小さい 1 つまたは複数の拡張可能ボリュームに分割します。 |
ボリュームを使用すると、記憶領域を拡張したり、性能やデータの可用性を高めたりできます。 状況によっては、ボリュームを使用すると、入出力性能が向上することもあります。 機能的には、ボリュームとスライスは同じように動作します。 エンドユーザーや、アプリケーション、ファイルシステムからは、ボリュームとスライスは同じように見えます。 物理デバイスと同じように、ボリュームはブロックまたは raw デバイス名を使ってアクセスされます。 ボリューム名は、ブロックデバイスを使用するか raw デバイスを使用するかによって異なります。 ボリューム名の詳細については、「ボリューム名」を参照してください。
ボリューム上では、mkfs、mount、 umount、ufsdump、ufsrestore など、ファイルシステムのほとんどのコマンドを使用できます。 ただし、format コマンドは使用できません。 ボリューム上にマウント済みのファイルシステムが存在すれば、ボリュームとの間でファイルの読み取り、書き込み、コピーを行うことができます。
図 32 に、Disk A の 1 つのスライスと Disk B の 1 つのスライスから構成されるボリュームを示します。アプリケーションや UFS は、このボリュームを 1 つの物理ディスクとして扱います。 ボリュームにさらに多くのスライスを追加すれば、容量を増やすことができます。
Solaris ボリュームマネージャでは、ボリュームにスライスを追加することによってボリュームを拡張できます。 既存のボリュームにスライスを追加するには、Solaris 管理コンソール内の「拡張ストレージ」かコマンド行インタフェースを使用します。
ボリュームに含まれているUFS ファイルシステムは、マウントされているかどうかに関係なく、システムを停止したりバックアップをとらなくても拡張できます。 ただし、どのような場合でも、データのバックアップを取ることを推奨します。 ボリュームを拡張したあとは、growfs コマンドを使用してファイルシステムを拡張します。
いったん拡張したファイルシステムを縮小することはできません。 これは UFS の制約です。 同じように、いったん拡張した Solaris ボリュームマネージャのパーティションを縮小することはできません。
raw ボリュームを使用するアプリケーションやデータベースは、独自の方法で領域を拡張し、それを認識できなければなりません。 Solaris ボリュームマネージャには、この機能はありません。
ボリュームのディスク領域を拡張するには、次の方法を利用できます。
RAID 0 ボリュームに 1 つまたは複数のスライスを追加する
RAID 1 ボリュームのすべてのサブミラーに 1 つまたは複数のスライスを追加する
growfs コマンドは、サービスの中断やデータを失うことなく、UFS ファイルシステムを拡張します。 ただし、growfs コマンドが実行している間は、ボリュームへの書き込みアクセスはできません。 ファイルシステムは、それを格納しているスライスまたはボリュームのサイズまで拡張できます。
追加ディスク領域の一部だけを使ってファイルシステムを拡張する場合は、growfs コマンドに -s size オプションを指定します。
ミラーを拡張すると、ミラーを構成しているすべてのサブミラーに領域が追加されます。 同じように、トランザクションボリュームを拡張すると、マスターデバイスに領域が追加されます。 その後で RAID 1 ボリュームまたはトランザクションボリュームに対してgrowfs コマンドを実行します。 一般的な規則としては、ボリュームを構成するデバイスに領域を追加してから、トップレベルのデバイスに対して growfs コマンドを実行します。
ボリュームに名前を付けるときは、次の規則に従います。
ボリューム名は d で始まり、その後に 1 つの数が続きます (たとえば、d0)。
meta* コマンドでは、/dev/md/dsk/d1 のように完全なボリューム名を指定する代わりに、d1 のように省略形のボリューム名を指定できます。
物理スライスと同じように、ボリュームにも、ファイルシステムで使用される論理名があります。 論理ボリューム名は、/dev/md/dsk ディレクトリ (ブロックデバイスの場合) または /dev/md/rdsk ディレクトリ (raw デバイスの場合) に作成されます。
名前を変更しようとするボリュームが現在使用されておらず、かつ、新しい名前がほかのボリュームで使用されていなければ、ボリューム名はいつでも変更できます。 詳細については、「ボリューム名の交換 」を参照してください。
Solaris ボリュームマネージャでは、0 から 127 までの 128 個のデフォルトボリューム名を使用できます。次の表に、ボリューム名の例を示します。
/dev/md/dsk/d0 |
ブロック型ボリューム d0 |
/dev/md/dsk/d1 |
ブロック型ボリューム d1 |
/dev/md/rdsk/d126 |
raw ボリューム d126 |
/dev/md/rdsk/d127 |
raw ボリューム d127 |
ボリューム名を標準化すると、管理が容易になるだけでなく、ボリュームタイプが一目でわかるようになります。 次の推奨事項を考慮してください。
特定のボリュームタイプごとに範囲を指定します。 たとえば、RAID 1 ボリュームには 0 から 20、RAID 0 ボリュームには 21 から 40 を割り当てます。
ミラーの名前を相互に関連付けます。 たとえば、ミラーの名前を 0 で終わる数字にし、サブミラーの名前を 1 や 2 で終わる数字にします。 これに従えば、 最初のミラーは d10 、そのサブミラーは d11 と d12 になります。さらに、次のミラーは d20、そのサブミラーは d21 と d22 になります。
スライス番号とディスク番号がボリューム番号に対応するような命名方法を使用します。
「状態データベース 」は、Solaris ボリュームマネージャの構成の状態に関する情報を格納するデータベースです。 状態データベースは、構成に対して加えられた変更を記録および管理します。 Solaris ボリュームマネージャは、構成や状態に変化があると、状態データベースを自動的に更新します。 たとえば、新しいボリュームの作成は構成の変更であり、 サブミラーの障害は状態の変化を意味します。
状態データベースは、実際には、複製された複数のデータベースコピーの集まりです。 各コピーは、状態データベースの複製と呼ばれ、データベース内のデータが常に有効であることを保証します。 状態データベースのコピーを複数持つことにより、単一点障害からデータを保護することができます。 状態データベースは、既知の状態データベースの複製の格納場所と状態をすべて記録しています。
状態データベースとその状態データベースの複製が作成されるまで、Solaris ボリュームマネージャは動作できません。 Solaris ボリュームマネージャの構成には、必ず有効な状態データベースが必要です。
構成を設定するときは、状態データベースの複製を次のどちらかに配置できます。
専用のスライス上
後でボリュームの一部となるスライス上
Solaris ボリュームマネージャは、状態データベースの複製が割り当てられているスライスを認識し、そのスライスがボリューム内で使用されている場合には、その複製部分を自動的にスキップします。 状態データベースの複製用に予約されているスライスの部分を、他の目的に使用することはできません。
複数の状態データベースのコピーを 1 つのスライス上に置くこともできますが、 そのようにすると、システムは単一点障害に対して脆弱になります。
すべての状態データベースの複製が削除された場合でも、システムは正常に動作します。 しかし、状態データベースの複製がディスク上にまったくない状態でシステムを再起動すると、すべての Solaris ボリュームマネージャの構成データが失われます。
「ホットスペア集合」は、障害のあるコンポーネントと自動的に交換できるように、Solaris ボリュームマネージャが予約しているスライス (「ホットスペア」) の集合です。 ホットスペアは、サブミラーまたは RAID 5 ボリュームのどちらでも使用できます。 RAID 1 と RAID 5 ボリュームでは、ホットスペアを使用することによってデータの可用性が向上します。 ホットスペア集合は、Solaris 管理コンソール内の「拡張ストレージ」とコマンド行インタフェースのどちらでも作成できます。
エラーが発生すると、Solaris ボリュームマネージャは、障害のあるスライスと同じかそれより大きいサイズのホットスペアを探します。 該当するホットスペアが見つかると、Solaris ボリュームマネージャは自動的にそのコンポーネントを交換して、データの再同期をとります。 適切なサイズのスライスがホットスペア集合にないと、サブミラーまたは RAID 5 ボリュームは使用不能とみなされます。 詳細については、 第16章「ホットスペア集合 (概要)」を参照してください。
ディスクセットとは、論理ボリュームとホットスペアを含む物理的な記憶領域ボリュームの集まりのことです。 ボリュームやホットスペア集合は、そのディスクセット内のドライブだけで構成される必要があります。 ディスクセットに作成したボリュームは、物理スライスと同じように使用できます。
クラスタ環境では、ディスクセットの使用によってデータの可用性が向上します。 一方のホストに障害が発生しても、そのディスクセットを他方のホストが引き継ぐことができます (このタイプの構成は「フェイルオーバー構成」と呼ばれます)。 さらに、ディスクセットを使用することにより、Solaris ボリュームマネージャの名前空間の管理や、ネットワーク接続されている記憶装置へのアクセスが容易になります。
詳細については、第20章「ディスクセット (概要)」を参照してください。
Solaris ボリュームマネージャの構成が適切に設定されていないと、性能が低下することがあります。 この節では、Solaris ボリュームマネージャの性能を最適に保つためのヒントについて説明します。
ディスクとコントローラ 1 つのボリュームに複数のドライブがある場合は、それらを別々のドライブパスに配置します。 SCSI ドライブの場合は、別のホストアダプタに置くようにします。 入出力負荷をいくつかのコントローラに分散することによって、ボリュームの性能と可用性が向上します。
システムファイル /etc/lvm/mddb.cf や /etc/lvm/md.cf ファイルは変更したり削除したりしないでください。
これらのファイルは、定期的にバックアップしてください。
ボリュームの整合性 スライスをボリュームとして定義したら、その元となるスライスをダンプデバイスなどの別の目的に使用してはなりません。
ボリュームの最大数 1 つのディスクセットでサポートされる最大ボリューム数は 8192 (デフォルトでは 128) です。 デフォルトの最大ボリューム数を増やすには、/kernel/drv/md.conf ファイルを編集する必要があります。 このファイルの詳細については、「システムファイルと始動ファイル 」を参照してください。
ディスクとパーティションに関する情報 不良ディスクを再フォーマットしたり、Solaris ボリュームマネージャの構成を作成し直したりしなければならない場合に備えて、prtvtoc と metastat -p コマンドの出力コピーを保管してください。
ボリュームを構成しているスライス上にファイルシステムをマウントしないでください。 スライスがボリュームを構成するために使用されている場合は、そのスライスをファイルシステムとしてマウントしてはなりません。 可能であれば、ボリュームとして使用する予定の物理デバイスは、アクティブにする前にマウント解除してください。 たとえば、UFS 用のトランザクションボリュームを /etc/vfstab ファイルに作成する場合は、トランザクションボリューム名を、マウントおよび fsck を実行するデバイスとして指定します。
Solaris ボリュームマネージャのコンポーネントを作成するときは、物理スライスを Solaris ボリュームマネージャの論理名に割り当てます。 作成できる Solaris ボリュームマネージャ要素には、次のものがあります。
状態データベースの複製
ボリューム (RAID 0 (ストライプ方式および連結方式)、RAID 1 (ミラー)、RAID 5、ソフトパーティション、トランザクションボリューム)
ホットスペア集合
ディスクセット
ボリューム名の付け方のヒントについては、「ボリューム名」を参照してください。
Solaris ボリュームマネージャ要素を作成するための前提条件は、次のとおりです。
初期状態データベースの複製を作成します。 作成手順については、「状態データベースの複製の作成 」を参照してください。
Solaris ボリュームマネージャで使用できるスライスを特定します。 必要に応じて、format コマンド、 fmthard コマンド、または Solaris 管理コンソールを使って、既存ディスクのパーティションを再分割します。
ルート権限を持っていることを確認します。
すべてのデータの最新バックアップを取ります。
グラフィカルユーザーインタフェースを使用する場合は、Solaris 管理コンソールを起動し、GUI から Solaris ボリュームマネージャ機能を使用します。 詳細については、「Solaris ボリュームマネージャグラフィカルユーザーインタフェースを使用するには」を参照してください。
Solaris 9 4/03 リリース以降、Solaris ボリュームマネージャは、64 ビットカーネルが動作しているシステム上で、1 テラバイト (T バイト) より大きな記憶装置や論理ボリュームをサポートします。
64 ビットカーネルがシステムで動作しているかどうかを知るには、isainfo -v を使用します。 「64bit」という文字列が表示された場合、64 ビットカーネルが動作しています。
Solaris ボリュームマネージャを使用すると、システム管理者は次のことができます。
1T バイトを超えるサイズの論理記憶装置ユニット (LUN) で (あるいは、LUN から) 構築された論理ボリュームを、作成、変更、および削除できます。
1T バイトを超えるサイズの論理ボリュームを、作成、変更、および削除できます。
大容量ボリュームは自動的にサポートされます。つまり、1T バイトを超えるデバイスを作成すると、Solaris ボリュームマネージャによって適切に構成されるため、ユーザーは何もする必要がありません。
Solaris ボリュームマネージャが大容量ボリューム (1T バイト超) をサポートするのは、Solaris 9 4/03 以降の 64 ビットカーネルが動作しているシステムでのみです。 これより前の Solaris 9 リリースの 32 ビットカーネルが動作しているシステムで大容量ボリュームを扱うと、Solaris ボリュームマネージャの機能に影響が出ます。 特に、次の点に注意してください。
大容量ボリュームを持つシステムを Solaris 9 4/03 以降の 32 ビットカーネルでリブートした場合、大容量ボリュームは metastat の出力では見えますが、その大容量ボリュームにアクセス、変更、または削除することはできず、新しい大容量ボリュームを作成することもできません。 この状況では、大容量ボリューム上のボリュームまたはファイルシステムも利用できません。
大容量ボリュームを持つシステムを Solaris 9 4/03 より前のリリースでリブートした場合、Solaris ボリュームマネージャは起動しません。 大容量ボリュームに対応していない Solaris プラットフォームで Solaris ボリュームマネージャを実行する前には、すべての大容量ボリュームを削除する必要があります。
Solaris ボリュームマネージャのトランザクションボリュームは大容量ボリュームをサポートしません。 どのような場合でも、UFS ロギングを使用する必要があります。 詳細については、mount_ufs(1M) のマニュアルページを参照してください。
32 ビットの Solaris ソフトウェアを実行する予定がある場合、あるいは、Solaris 9 4/03 より前の Solaris OS を使用する予定がある場合は、大容量ボリュームを作成しないでください。
Solaris ボリュームマネージャのすべてのコマンドは大容量ボリュームで機能します。 大容量ボリュームのサポートを活用するために特別な構文や作業は必要ないため、Solaris ボリュームマネージャを使い慣れているシステム管理者であれば、すぐに Solaris ボリュームマネージャの大容量ボリュームを使用できます。
大容量ボリュームを作成したあとで、Solaris 9 4/03 より前のリリースまたは Solaris 9 4/03 以降の 32 ビットカーネルで Solaris ボリュームマネージャを使用する必要ができた場合、大容量ボリュームを削除する必要があります。 Solaris 9 4/03 より前のリリースまたは 32 ビットカーネルでリブートする前に、64 ビットカーネルで metaclear コマンドを使用して、Solaris ボリュームマネージャ構成から大容量ボリュームを削除してください。
Solstice DiskSuite バージョン 4.1、4.2、および 4.2.1 から Solaris ボリュームマネージャへは、シームレスなアップグレードが可能です。ただし、すべてのボリュームが「正常 (Okay)」状態である (「保守が必要 (Needs Maintenance)」や「最後にエラー (Last Erred)」の状態でない) ことが必要です。さらに、ホットスペアが使用されていてはなりません。 アップグレードのために Solaris ボリュームマネージャに対してこれ以外に特に行うことはありません (構成の変更やルートミラーの解除は不要)。 システムをアップグレードすると、Solstice DiskSuite の構成が繰り越され、Solaris ボリュームマネージャの各種ツールを通してアクセスできるようになります。