この章では、DiskSuite を使用するためのヒントについて説明します。
必要な情報を提供する節に直接進むためには、次の目次を使用してください。
トランスメタデバイス (UFS ロギング) を作成すれば、UFS の可用性を簡単に高めることができます。トランスメタデバイスを使用する際に、スライスを効果的に使用するためのヒントを次に示します。
新しいシステムで、各ディスク上に 2 〜 3 個の小さなスライス (それぞれ 8 〜 10M バイト) を作成します。これらのスライスを使用して、状態データベースの複製とロギングデバイスの両方を保管します。経験的には、新しいディスクをシステムに追加するときに、この方法を使用して、状態データベースの複製とトランスメタデバイスを構成します。このようにして、1 つのスライスで 2 つの DiskSuite オブジェクトを管理できます。
状態データベースの複製の追加、およびトランスメタデバイスの作成については、第 2 章「DiskSuite オブジェクトの作成」を参照してください。
PrestoserveTM は、ディスク書き込みの多いアプリケーションにおける応答時間の短縮のためのハードウェア / ソフトウェア製品です。この製品では、ディスクブロックデバイスの書き込み操作を選択的に不揮発性メモリーにキャッシュすることによって、パフォーマンスを加速し、ディスクの入出力ボトルネックを減少させます。
Prestoserve を使用すれば、NFSTM サーバー、ディスク入出力の多いアプリケーション、およびファイルシステムのパフォーマンスが向上します。
DiskSuite は、次の制約のもとで、Prestoserve と完全に互換性があります。
ストライプ / 連結
トップレベルのメタデバイス (ミラーは好ましくない。「Prestoserve をミラーと使用することが好ましくない理由」を参照)
配下のコンポーネント (つまり、サブミラー)
状態データベースの複製
トランスメタデバイス (および配下のマスターデバイスとロギングデバイス)
簡単な理由として、Prestoserve でミラーを使用すると、入出力サブシステムにシステムのアキレス腱となる部分が生じます。これこそ、ミラーの設計目的に反するものです。Prestoserve を使用すると、ミラーの MTBF はおよそ単体ディスクと同じレベルまで低下します。
Prestoserve は、トランスメタデバイス上では使用できません。ロギング UFS 上で Prestoserve を使用すると、システムがハングアップしたりパニック状態になることがあります。Prestoserve は、デバイスからの入出力を NVRAM にリダイレクトすることによって動作します。このリダイレクションは、ロギング UFS とメタデバイス間の通信プロトコルを妨害します。
次の手順では、DiskSuite と一緒に使用する Prestoserve をロードし、有効にする方法について説明します。基本的には、DiskSuite ドライバの後から Prestoserve をロードするよう、/etc/system ファイルを編集します。
exclude: drv/pr |
/etc/init.d/SUNWmd.init ファイルを編集し、start 節の最後に次の行を追加する。
'start') rm -f /tmp/.mdlock if [ -x "$METAINIT" -a -c "$METADEV" ]; then #echo "$METAINIT -r" $METAINIT -r error=$? #echo "$error" case "$error" in 0|1) ;; 66) echo "Insufficient metadevice database replicas located." echo "" echo "Use metadb to delete databases which are broken." echo "Ignore any ¥"Read-only file system¥" error messages." echo "Reboot the system when finished to reload the metadevice database." echo "After reboot, repair any broken database replicas which were deleted." /sbin/sulogin < /dev/console echo "Resuming system initialization. Metadevice database will remain stale." ;; *) echo "Unknown $METAINIT -r failure $error." ;; esac modload /kernel/drv/pr presto -p >/dev/null fi ;; |
/etc/init.d/prestoserve ファイルを編集する。
次の行を、
presto -u |
次のように変更します。
presto -u /<ファイルシステム>... |
このコマンドで、<ファイルシステム>... は、Prestoserve により加速されるすべてのファイルシステムのリストです。次の項目は除外してください。
DiskSuite 構成に不備があると、パフォーマンスが低下することがあります。この節では、DiskSuite を使用して高いパフォーマンスを得るためのヒントを紹介します。
ディスクとコントローラ - ドライブは、別のドライブパス上のメタデバイスに置きます。SCSI ドライブの場合、これは別のホストアダプタを意味します。IPI ドライブの場合、これは別のコントローラを意味します。入出力の負荷を複数のコントローラに分散すれば、メタデバイスのパフォーマンスと可用性が向上します。
SPARCstorage Array の場合、可能ならば、異なるシャーシ上のミラーに含まれるドライブを使用してください。このような構成では、すべてのミラーデータが SPARCstorage Array のシャーシ障害に耐えることができます。ドライブを異なるシャーシに分散できない場合、異なるトレイに含まれるドライブを使用します。これによって、ミラーをオンライン状態に保ったままで、サブミラーをオフラインにし、保守のためにトレイを停止したり除去することができます。
たとえば、2 面のミラーで、各サブミラーが 3 つの SPARCstorage Array ディスクの連結によって構成されるものとします。一方のサブミラーは、トレイ 1 に含まれる 3 つのディスクから構成され、他方のサブミラーは、トレイ 2 に含まれるドライブから構成されます。この構成を初期化するためのコマンド行インタフェースは、次のようになります。
# metainit d1 3 1 c0t0d0s2 1 c0t0d1s2 c0t0d2s2 d1: Concat/Stripe is setup # metainit d2 3 1 c0t2d0s2 1 c0t2d1s2 c0t2d2s2 d2: Concat/Stripe is setup # metainit d0 -m d1 d0: Mirror is setup # metattach d0 d2 d0: Component d2 is attached |
文字列 t0 と t1 はトレイ 1 に含まれ、t2 と t3 はトレイ 2 に含まれ、t4 と t5 はトレイ 3 に含まれます。したがって、上述のコマンドでは、異なるトレイにサブミラーを作成するため、最初のサブミラーに文字列 t0 を使用し、2 番目のサブミラーに文字列 t2 を使用します。
システムファイル - /etc/lvm/mddb.cf ファイルや /etc/lvm/mdo.cf ファイルについては、編集も除去も行わないでください。
これらのファイルは、定期的にバックアップしてください。
スライスがメタデバイスとして定義および起動されたら、これを他の目的に使用しないでください。
不良ディスクの再フォーマットが必要となる場合に備えて、prtvtoc(1M) コマンドの出力のハードコピーを保存しておきます。
メタデバイスの一部となるスライス上に状態データベースの複製が置かれた場合、メタデバイスの容量は、複製によって占有される領域分だけ減少します。複製によって使用される領域は次のシリンダ境界まで切り上げられ、この領域はメタデバイスによってスキップされます。しかし、状態データベースの複製のデフォルトサイズは 1034 ブロックにすぎないため、複製とメタデバイスをこのように結合することは、実際に DiskSuite のきわめて効果的な使用法となります。
ストライプは、(他のメタデバイスではなく) スライスからのみ作成されます。
ディスクジオメトリ (幾何学的配置) の異なるディスクのスライスを使用しません。
スライスは、同じコントローラ上でもかまいませんが、別のディスクのものを使用します。それぞれ別のコントローラ上に置かれたストライプを使用する場合、同時に実行できる読み書きの数が増大します。
システムやアプリケーションからの入出力要求に適合するように、ストライプの飛び越し値を設定します。
単一のディスク上にあるパーティションを使用したストライプ化を行いません。これは、同時アクセスができなくなり、パフォーマンス上の障害となるからです。
同じサイズのディスクコンポーネントを使用します。異なるサイズのディスクコンポーネントでストライプ化すると、ディスク領域に使用不可能な部分が生まれます。
ストライプ化する際に異なるサイズのスライスを使用した場合、ディスク容量は最小サイズのスライスの倍数に制限されます。
連結は、(他のメタデバイスではなく) スライスからのみ作成されます。
ディスクジオメトリ (幾何学的配置) の異なるスライスを使用しません。
可能ならば、連結方式メタデバイスのコンポーネントを、異なるコントローラとバス上に分散配置します。
連結では、ストライプ化よりも CPU サイクルが短いので、小さなランダム入出力や均一な入出力分布の場合でも、うまく機能します。
上記のストライプと連結のガイドラインを参照してください。
ディスクとコントローラ - サブミラーのスライスは、サブミラーごとに異なるディスクとコントローラ上に保持します。同じミラー中の複数のサブミラーのスライスが、同じディスクに置かれている場合、データの保護能力は著しく低下します。同様に、コントローラとそれに接続しているケーブルは、ディスクよりも故障する傾向が高いため、サブミラーは異なるコントローラにまたがって構成します。これによってミラーのパフォーマンスも改善されます。
同じディスク - 同じディスク上にはミラーを定義しません。同じドライブへの書き込みは同じ資源をめぐって競合し、1 つのドライブに障害が発生すると、すべてのデータが失われることになります。
読み書きパフォーマンス - ミラー化により、読み取りパフォーマンスは向上することがありますが、書き込みパフォーマンスは必ず低下します。ミラー化によって読み取りパフォーマンスが向上するのは、スレッド化された入出力や非同期入出力の場合に限られます。メタデバイスからシングルスレッド読み出しだけが行われる場合、パフォーマンスの向上は得られません。
同じサイズのサブミラー - 同じサイズのサブミラーを使用します。異なるサイズのサブミラーでは、ディスク領域に使用不可能な部分が生まれます。
同じタイプのディスクとコントローラ - 1 つのミラーでは同じタイプのディスクとコントローラを使用します。特に、古い SCSI や SMD の記憶装置の場合、モデルやブランドの異なるディスクやコントローラ間で、パフォーマンスが大幅に異なることがあります。1 つのミラーに異なるパフォーマンスレベルの製品が混在すると、パフォーマンスが著しく低下することがあります。
サブミラーに対する読み書きオプションの設定 - ミラーの読み取りオプションを試してみると、パフォーマンスが向上することがあります。たとえば、デフォルトの読み取りモードでは、ディスク間の読み取りをラウンドロビン方式 (巡回式) で切り替えます。この方法は、UFS のマルチユーザー・マルチプロセスアクティビティでは最適なことが多いため、デフォルトとなっています。
場合によっては、ジオメトリック (幾何学的配置) オプションを使用すると、ヘッドの移動時間とアクセス時間を最小限に抑えることによって、パフォーマンスが向上することもあります。このオプションが最も有効なのは、ディスクあたり 1 つのスライスしかない場合、一度に 1 つのプロセスだけがスライス / ファイルのシステムを使用する場合、入出力パターンがきわめて連続的に行われる場合、すべてのアクセスが読み取りである場合です。
ミラーオプションを変更するには、「ミラーのオプションの変更方法 (DiskSuite ツール)」を参照してください。
ミラーのマウント - 必ずミラーデバイスを直接マウントしてください。オフラインであって読み取り専用でマウントされている場合を除いて、サブミラーを直接マウントしてはなりません。サブミラーの一部であるスライスも直接マウントしてはなりません。これを行うと、データの破壊やシステムクラッシュが発生することがあります。
swap のミラー化 - すべての swap デバイスをチェックするには、swap -l を使用します。swap と指定されたスライスは、別々にミラー化しなければなりません。
20% 書き込みのルールに従う - パリティ計算が複雑であるため、書き込みがおよそ 20% を超えるメタデバイスは、RAID5 メタデバイスのデバイスとはなりません。データの冗長性が必要な場合は、ミラー化を検討してください。
「スライス消費型」RAID5 メタデバイスの欠点 - RAID5 メタデバイスに含まれるスライスが増大するほど、コンポーネントが故障した場合に読み書き操作の時間が長くなります。
RAID5 メタデバイスはミラー化できません。
RAID5 メタデバイスとストライプ化のガイドライン - ストライプ化のガイドラインは、RAID5 メタデバイスの構成にも適用されます。「ストライプ化のガイドライン」を参照してください。
異なるコントローラを使用する - RAID5 デバイスを作成する場合、コントローラとそれに接続しているケーブルはディスクに比べて故障する可能性が高いため、個々のコントローラにまたがってスライスを使用します。これにより、ミラーのパフォーマンスも向上します。
同じサイズのスライスを使用する - 同じサイズのディスクスライスを使用します。異なるサイズのスライスから成る RAID5 メタデバイスを作成すると、ディスク領域に使用不可能な部分が生まれます。
飛び越し値 - これはメタデバイスの作成時に設定できます。その後では、値を変更することはできません。デフォルトの飛び越し値は 16K バイトです。これは多くのアプリケーションに対して適当な値です。RAID5 メタデバイス内のさまざまなスライスがさまざまなコントローラに置かれており、メタデバイスに対するアクセスが主に多量の順次アクセスである場合、32K バイトの飛び越し値を指定するとパフォーマンスが向上することがあります。
RAID5 メタデバイスへの連結 - 既存の RAID5 に新しいスライスを連結すると、連結によるデータは連続しているため、メタデバイス全体のパフォーマンスに影響を与えます。データは、すべてのコンポーネントを通じてストライプ化されません。メタデバイスの元のスライスでは、すべてのスライスを通じてデータとパリティがストライプ化されます。連結方式スライスではこのストライプが失われるが、コンポーネントの入出力中にはパリティが使用されるため、データはエラーから回復することができます。
連結方式スライスの場合、どの領域でもパリティをストライプ化しないという意味で、事情が異なります。したがって、スライスの内容全体をデータに使用できます。
スライスが連結されると、多量の書き込みや順次書き込みに対するパフォーマンス上のメリットが失われます。
ロギングデバイスとマスターデバイスの場合 - 同じトランスメタデバイスに属するロギングデバイスとマスターデバイスを、異なるドライブとコントローラに置きます。
トランスメタデバイスと共有ロギングデバイスの場合 - トランスメタデバイスは、メタデバイスのロギングデバイスを共有できます。しかし、きわめて負荷の重いファイルシステムには、別のログをもたせてください。
小規模なファイルシステム - 読み取り操作が大部分の小規模なファイルシステムでは、おそらくログに記録する必要はありません。
ロギングデバイスのミラー化 - 可能な限り、すべてのロギングデバイスをミラー化します。デバイスエラーによってログ中のデータが失われると、ファイルシステムが不整合な状態となり、fsck(1M) を使用しても、ユーザーの介入なしでは修復できない可能性があります。
大きなロギングデバイスを使用すると、大きな多重度 (concurrency) が得られます。
一時的な修復手段としてのホットスペア - ホットスペアは、そのまま永続的に構成中に組み込まれて使用されるように設計されていません。修復が済んだスライスや新しいスライスと交換する必要があります。
ホットスペアと状態データベースの複製 - ホットスペアには状態データベースの複製を置くことができません。
コントローラをまたがった割り当て - 理想的には、ホットスペア集合に追加するスライスは、異なるコントローラに接続します。これによって、コントローラのエラーや障害に対するデータの可用性を保証します。
不適切なサイズのホットスペア - 不適切なサイズのホットスペアを、サブミラーや RAID5 メタデバイスに関連付けしないでください。
使用中とマークされたホットスペア - ホットスペア集合内のすべてのホットスペアに「使用中」のマークがないことを確認してください。
1 面のミラーとホットスペア - 1 面ミラーに含まれるサブミラーには、ホットスペア集合を割り当てないでください。
ホットスペアは適合した順に使用される - 異なるサイズのホットスペアをホットスペア集合に追加する場合は、小さなスライスから追加していきます。
メタデバイスの配下にあるスライスには、ファイルシステムをマウントしないでください。任意のメタデバイスにスライスが使用された場合、そのスライスをファイルシステムとしてマウントしてはなりません。可能ならば、メタデバイスとして使用する予定の物理デバイスは、起動する前にマウント解除します。たとえば、UFS 用のトランスメタデバイスを /etc/vfstab ファイルに作成した場合、そのトランスメタデバイス名はマウントおよび fsck を行うデバイスとして指定します。
すべての物理デバイスにはディスクラベルが必要であり、通常は install、format、fmthard などのプログラムによって作成されます。このラベルは、ラベルに定義された複数の論理パーティションに表示できます。ラベルを含んだ物理パーティションは、ラベルを含んだブロックに対するユーザーの書き込みを許してはなりません。通常、これはブロック 0 である。UNIX のデバイスドライバでは、ユーザーがこのラベルに上書きできます。
DiskSuite は、システム上で実行できるメタデバイスの再構成に対しては、監査トレールを提供しません。つまり、DiskSuite は C2 セキュリティをサポートしません。
Solstice DiskSuite 4.2.1 を実行するシステムは、Solaris 2.4, Solaris 2.5, Solaris 2.5.1, Solaris 7 あるいは Solaris 8 を実行している必要があります。
UFS ロギングとディスクセットの場合、Solaris 7 あるいは Solaris 8 を実行する必要があります。
DiskSuite は、Solstice BackupTM 5.5.1 製品と互換性があります。
たとえば、ディスクを交換した後で、ディスクドライブのパーティションを再分割する必要がある場合、fmthard(1M) コマンドを使用してスクリプトを作成し、ディスク上に VTOC(ボリューム目録) 情報をすばやく再作成することができます。
prtvtoc(1M) コマンドを使用して、ディスクに関するパーティション情報の一覧を取得する。
# prtvtoc /dev/rdsk/c2t0d0s0 > /tmp/vtoc |
この例では、ディスク c2t0d0 の情報は、ディスク上のファイルにリダイレクトされます。
fmthard(1M) コマンドを使用して、次に示すようなスクリプトを作成して実行する。
for i in 1 2 3 5 do fmthard -s /tmp/vtoc /dev/rdsk/c2t${i}d0s2 done |
ディスク領域のサイズやユーザーが使用できる i ノードの数 (ファイルの数にほぼ等しい) を制限することができます (これは DiskSuite の機能ではなく、Solaris の機能です)。これらの制限は、ファイルシステムがマウントされるたびに自動的に起動されます。
ファイルシステムがロギング用にも設定されている場合、制限用のファイルシステムの設定は、quotacheck を使用して高速にチェックできます。このような設定により、quotacheck の実行に必要な時間を減らすことができます。
トランスメタデバイスを作成するには、第 2 章「DiskSuite オブジェクトの作成」を参照してください。制限の詳細は、『Solaris のシステム管理 (第 2 巻)』を参照してください。
この節では、DiskSuite ツールの高度な使用法 (および制約) について説明します。
カラーマップ - DiskSuite ツールは、アプリケーションを終了するときに、「ディスク表示」ウィンドウのカラーマップを保存できません。DiskSuite ツールの使用を終了すれば、そのカラーマップは無効になり、保存することはできません。
メタデバイスの論理名 - 現在、DiskSuite ツールには table1 や log1 などの論理名をメタデバイスに割り当てる機能が存在しません。
スライスブラウザウィンドウの「使用状況」カラム - スライスが raw デバイスとして使用されている場合、スライスブラウザウィンドウの「使用状況」カラムは「未割り当て」から変化しません。現在、raw デバイスとして使用されるメタデバイスに限らず、すべての raw デバイスがこの問題を共有しています。使用するデバイスは、ファイルシステムや swap として登録するしか方法がありません。DiskSuite ツールには、このための独自の方法がありません。
メタデバイスエディタのキャンバスにおいて、画面の表示領域の管理に役立つ 3 つのヒントを紹介します。
オブジェクトのポップアップメニューから「拡大表示解除」を選択すると、より多くのオブジェクトをキャンバスに収容できます。
キャンバスに多数のオブジェクトがあり、マウスを使ってオブジェクトの再配置を行なったり、そのうちのいくつかを片付けたりする場合、「編集」メニューから「キャンバスを整理」を選択すると便利です。「キャンバスを整理」オプションは、キャンバス上のオブジェクトをグリッド単位に再配列し、表示を見やすくします。
キャンバスのサイズ変更にはサッシ (枠) を使用します。キャンバス領域を広げるには、「メタデバイスエディタ」ウィンドウの下部にあるサッシ上でマウスの SELECT ボタン (通常は左ボタン) を押し、右方向にドラッグします。
「スライス表示」ウィンドウと「ディスク表示」ウィンドウの内部でフィルタを設定すると、当面の作業に対して適当なスライスをすばやく探索するのに役立ちます。
多数のディスク (とスライス) を備えたシステムの場合、特定のサイズで使用できるスライスを探すことは面倒な仕事です。「スライスフィルタ」ウィンドウを使用すれば、この作業に要する時間を節約できます。
この作業では、200M バイトを超える使用可能なスライスに対して「スライスブラウザ」ウィンドウにフィルタを作成し、これらのスライスを「ディスク表示」ウィンドウにドラッグ&ドロップして、その位置を調べる方法について説明します。
「スライス」をクリックして「スライスブラウザ」ウィンドウを表示する。
「スライスブラウザ」ウィンドウが表示されます。
「スライスブラウザ」ウィンドウの「フィルタ」メニューから、「フィルタの設定」を選択する。
「スライスフィルタ」ウィンドウが表示されます。
使用可能なスライスを検索するには、「使用可能な種類」ラジオボタンがチェックされており、プルダウンメニューで「任意」が選択されていることを確認する。
200M バイトを超えるスライスを選別するには、「サイズ」ラジオボタンをチェックし、最初のプルダウンで「指定数値より大きい」を選択し、テキストボックスに 200 を入力し、2 番目のプルダウンメニューで「M バイト」を選択する。
「適用」をクリックし、「スライスブラウザ」ウィンドウで結果を見る。
必要ならば、「スライスフィルタ」ウィンドウの値を変更し、「適用」をクリックしてフィルタ方式を変更します。
希望に合わせてフィルタ方式を調節してから、「了解」をクリックして「スライスフィルタ」ウィンドウを閉じる。
「ディスク表示」をクリックして、「ディスク表示」ウィンドウを表示する。
「ディスク表示」ウィンドウが表示されます。
「スライスブラウザ」ウィンドウで「すべてを選択」をクリックする。
選択したスライスを「ディスク表示」ウィンドウのドロップ領域の色の部分にドラッグする。
「ディスク表示」ウィンドウで結果を見る。
DiskSuite ツールは、「ディスク表示」ウィンドウにドラッグされたすべてのスライスに対して、選択したドロップ領域の色を使用します。これで、「一般的なガイドライン」で概説した内容に従って、(たとえばサブミラーを作成するために) スライスを選択できます。
この作業では、DiskSuite ツールを使用することによって、サブミラー内のエラーの発生したスライスに対して、適切なサイズの交換用スライスを見つける方法を示します。
この手法はミラーだけに限定されません。この作業を使用すれば、どのタイプのメタデバイスに対しても、交換スライスを見つけることができます。
「ディスク表示」をクリックして「ディスク表示」ウィンドウを表示する。
「ディスク表示」ウィンドウが表示されます。
エラーの発生したミラーオブジェクトを、オブジェクトリストからキャンバスにドラッグする。
ミラーの内部で 1 つのサブミラー (連結方式オブジェクト) を選択し、「ディスク表示」ウィンドウにドラッグする。さらに、2 番目のサブミラーについても同じ操作を行う (3 面ミラーの場合は、3 番目のサブミラーについても同様)。
「ディスク表示」ウィンドウでは、ミラーオブジェクト内のサブミラーに対応する別のカラーでスライスが着色されます。このため、たとえばコントローラが異なっても、スライスの位置を探すために役立ちます。
「スライス」をクリックして「スライスブラウザ」ウィンドウを表示する。
「スライスブラウザ」ウィンドウが表示されます。
「スライスブラウザ」ウィンドウで「フィルタの設定」をクリックする。
「スライスフィルタ」ウィンドウが表示されます。
使用可能なスライスを検索するには、「使用可能な種類」ラジオボタンがチェックされており、プルダウンで「メタバイスコンポーネント」が選択されていることを確認する。
エラーの発生したスライスを交換するためのスライスを選別する。
これを行う 1 つの方法としては、エラーの発生したスライスよりも少しだけ小さいサイズを基準にして、それより大きなスライスを見つけるフィルタを設定します。この方法では、エラーの発生したスライスと同じサイズのスライスを検索するフィルタを設定する場合に比べて、広範囲なスライスが表示されます。
サイズを設定する。「サイズ」ラジオボタンをチェックし、最初のプルダウンで「指定数値より大きい」を選択する。テキストボックスにスライスのサイズ (M バイト単位で、エラーの発生したスライスより少しだけ小さなサイズ) を入力する。2 番目のプルダウンで「M バイト」を選択する。
「適用」をクリックし、「スライスブラウザ」ウィンドウで結果を見る。
必要ならば、「スライスフィルタ」ウィンドウの値を変更し、「適用」をクリックしてフィルタ方式を変更します。
「スライスブラウザ」ウィンドウで、「すべてを選択」をクリックする。選択したスライスを「ディスク表示」ウィンドウのドロップ領域の色の部分にドラッグする。
「ディスク表示」ウィンドウで結果を見る。
DiskSuite ツールは、「ディスク表示」ウィンドウにドラッグされたすべてのスライスに対して、この色を使用します。
交換用のスライスを選択する。
これで、「一般的なガイドライン」で概説したガイドラインに従って、DiskSuite オブジェクトに対するスライスを選択できます。十分な大きさのある交換スライスを選び、(別のコントローラ上で、あるいは少なくとも別のディスク上で) ミラーのガイドラインに従います。
交換用のスライスを、「ディスク表示」ウィンドウからエラーの発生したスライスをもつ連結方式オブジェクトの矩形までドラッグする。
ミラーを確定する。
デフォルトでは、DiskSuite ツールは、OpenWindowsTM のデスクトップアプリケーションと互換性のある色とフォントを使用します。この節では、これらの色とフォントの変更方法について説明します。
DiskSuite ツールでは多数の色を使用します。
標準のフォアグラウンドカラー - アプリケーション要素のほとんどすべてを表示するために使用する主要な色。標準では、ウィンドウ、ボタン、その他のコントロール用のデフォルトカラーを提供します。
標準のバックグラウンドカラー - ウィンドウ、ボタン、その他のコントロールで提示される情報の表示に使用される色。
キャンバスのバックグラウンドカラー - データ領域のバックグラウンドカラー。たとえば、エディタ、「ディスク表示」ウィンドウ、スクロールリストの表示領域は、すべてキャンバスのバックグラウンドカラーを使用します。
マッピングカラー - 論理デバイスから「ディスク表示」ウィンドウ内のスライスへのマッピングを表示する色。それぞれのディスク表示マッピングごとに 1 つずつ、全部で 8 つのマッピングカラーがあります。
状態カラー - 注意を必要とするオブジェクトの状態情報を強調する色。独自の色によって注意、緊急、重大な障害の 3 つの状態を表示します。
X ウィンドウシステムの RGB (赤、緑、青) 色指定機能を使用すれば、ほとんど無限に多彩な色を指定できます。もちろん、これらの色の多くは似ており、シェード (影の部分) や輝度がほんの少しずつ異なるだけです。
色の選択と指定に役立つよう、X ウィンドウシステムでは、RGB 値の代わりに名前で指定できる、標準のデフォルトカラーセットを提供します。このカラー名のデータベースを調べるには、標準の X ユーティリティ showrgb を使用します。このユーティリティは、RGB 値と対応する記述エイリアスを表示します。たとえば、次のようになります。
# showrgb 199 21 133 medium violet red 176 196 222 light steel blue 102 139 139 paleturquoise4 159 121 238 mediumpurple2 141 182 205 lightskyblue3 0 238 118 springgreen2 255 160 122 light salmon 154 205 50 yellowgreen 178 58 238 darkorchid2 69 139 116 aquamarine4 ... 107 107 107 gray42 71 71 71 gray28 61 61 61 gray24 255 255 255 white 0 205 205 cyan3 0 0 0 black |
/usr/openwin/lib/X11/rgb.txt ファイルを見ても、デフォルトのカラー名データベースを調べることができます。
残念ながら、色をブラウズするための標準アプリケーションは存在しません。パブリックドメインのカラーブラウザを入手できない場合、試行錯誤しながら希望の色を探してください。
DiskSuite ツールのデフォルトカラーを表 8-1に示します。
表 8-1 DiskSuite ツールのデフォルトカラー
カラータイプ |
色 |
---|---|
標準のフォアグラウンド |
black (黒) |
標準のバックグラウンド |
gray (グレー) |
キャンバスのバックグラウンド |
gray66 (グレー 66) |
マッピングカラー : |
|
mappingColor1 |
blue (青) |
mappingColor2 |
green (緑) |
mappingColor3 |
magenta (マゼンタ) |
mappingColor4 |
cyan (シアン) |
mappingColor5 |
purple (紫) |
mappingColor6 |
mediumseagreen (中間海緑色) |
mappingColor7 |
firebrick (耐火レンガ) |
mappingColor8 |
tan (黄褐色) |
mappingColor9 |
white (白) |
状態色 : |
|
重大な障害 |
red (赤) |
緊急 |
orange (オレンジ) |
注意 |
yellow (黄) |
DiskSuite ツールでは、4 つのフォントを使用します。
標準フォント - ツール (たとえば、ボタンラベル、メニュー、ダイアログボックス) 内の大部分のテキストを表示します。
モノスペース (固定幅) フォント - 一貫したカラム調整を可能にします (たとえば、さまざまなブラウザとスクロールリストで)。これは何回か指定する必要があります。
ボールドフォント - 属性名とラベルを実際の属性値から特定します。「情報」ウィンドウの名前 / ラベルは標準フォントで表示され、対応する値がボールドフォントで表示される。このフォントは控え目に使用されます。
スモールフォント -「ディスク表示」ウィンドウで 50% のスケーリングレベルにある物理デバイスを示します。
使用可能なフォントは、アプリケーションの表示に使用する X ウィンドウシステムのサーバーによって異なります。標準の X ユーティリティである xlsfonts(1) では、サーバーで使用可能なフォントを表示します。たとえば、次のようになります。
# xlsfonts --courier-bold-o-normal--0-0-0-0-m-0-iso8859-1 --courier-bold-r-normal--0-0-0-0-m-0-iso8859-1 --courier-medium-o-normal--0-0-0-0-m-0-iso8859-1 --courier-medium-r-normal--0-0-0-0-m-0-iso8859-1 --symbol-medium-r-normal--0-0-0-0-p-0--symbol -symbol-medium-r-normal--0-0-0-0-p-0-sun-fontspecific -adobe-courier-bold-i-normal--0-0-0-0-m-0-iso8859-1 ... utopia-bolditalic utopia-italic utopia-regular variable vshd vtbold vtsingle zapfchancery-mediumitalic zapfdingbats |
使用可能なフォントを表示するために便利なもう1つのユーティリティは xftonsel(1) です。詳細は、これらのユーティリティのマニュアルページを参照してください。
DiskSuite ツールのデフォルトフォントは、すべて Lucida フォントファミリーを基準にしています。
表 8-2 DiskSuite ツールのデフォルトフォント
フォントタイプ |
フォント |
---|---|
標準フォント |
lucidasans12 |
モノスペースフォント |
lucidasans-typewriter12 |
ボールドフォント |
lucidasans-bold12 |
スモールフォント |
lucidasans8 |
DiskSuite ツールでは、X ウィンドウシステムの資源データベース機能を使用して、どのフォントを使用するかを決定します。デフォルトの資源指定を次に示します。
表 8-3 DiskSuite ツールのデフォルトのフォント資源指定
資源 |
フォント |
---|---|
Metatool*fontList: |
Lucidasans12 |
Metatool*smallFontList: |
Lucidasans8 |
Metatool*boldFontList: |
Lucidasans-bold12 |
Metatool*fixedFontList: |
Lucidasans-typewriter12 |
Metatool*XmList.fontList: |
Lucidasans-typewriter12 |
Metatool*Help*helpsubjs.fontlist: |
Lucidasans-typewriter12 |
Metatool*Help*helptext.fontlist: |
Lucidasans-typewriter12 |
ja ロケールでは、Lucida フォントファミリーではなく、次のフォントをデフォルトに指定して使用しています。
-sun-gothic-medium-r-normal--14-120-75-75-c-120-jisx0208.1983-0
-sun-gothic-medium-r-normal--14-120-75-75-c-60-jisx0201.1976-0
DiskSuite ツールのデフォルトカラーとフォントを変更するには、次の 4 つの方法のいずれかを使用します。
DiskSuite ツールの 1 つの呼び出しに対しては、xrm ユーティリティを使用して、代わりのフォント資源やカラー資源を指定する。
# metatool -xrm '<資源名>' |
DiskSuite ツールのすべての呼び出しに対しては、自分の .Xdefaults ファイルを編集し、代わりのカラー資源やフォント資源を指定する。
.Xdefaults ファイルは、一般にデスクトップセッションの起動時にロードされます。このファイルを編集したら、次にデスクトップセッションを起動したときに、新しい資源または変更された資源が使用されます。
現在のセッションに対しては、再起動することなく、xrdb ユーティリティを使用する。
# xrdb -merge <.Xdefaults のパス名> |
DiskSuite ツールのすべてのユーザーに対しては、次のファイルを参照する。
ja ロケールの場合:
/usr/opt/sadm/lib/lvm/X11/ja/app-defaults/Metatool
C ロケールの場合:
/usr/opt/sadm/lib/lvm/X11/app-defaults/Metatool
このファイルに対する変更は、DiskSuite ツールが次に起動されたときに認識されます。
この例では、DiskSuite ツールの 1 つの呼び出しに対して、標準フォントを lucidasans16 に変更します。
# metatool -xrm 'Metatool*fontList: lucidasans16' |
メタデバイスに対する命名規則を使用すると、DiskSuite の管理に役立ち、メタデバイスの種類を一目で簡単に特定できます。次に、いくつかの提案を示します。
メタデバイスの種類ごとに範囲を指定する。
たとえば、ミラーには番号 0 〜 20、ストライプと連結には 21 〜 40 を割り当てます。
ミラーの命名関係を使用する。
たとえば、ミラーにはゼロ (0) で終わる名前を付け、サブミラーには 1 と 2 で終わる名前を付けたり、ミラー d10 にはサブミラー d11 と d12、ミラー d20 にはサブミラー d21 と d22 などとします。
スライス番号とディスク番号をメタデバイス番号にマップする命名方式を使用する。
metarename コマンドを使用すれば、メタデバイス名を再編成できます。詳細については、metarename(1M) のマニュアルページを参照してください。
DiskSuite の metarename コマンドは、メタデバイスのリネーム機能に加えて、「階層化」メタデバイスの切り替え機能を提供します。metarename に -x オプションを付けて使用すると、既存の階層化メタデバイスとそのサブデバイスの 1 つの名前を切り替え (交換) ます。この操作には、ミラーとそのサブミラーの 1 つ、またはトランスメタデバイスとそのマスターデバイスを含みます。
メタデバイスを交換するにはコマンド行を使用しなければなりません。この機能は DiskSuite ツールでは現在使用できませんが、コマンド行や DiskSuite ツールを使用して、メタデバイスをリネームすることはできます。
メタデバイス名の切り替えをいつ行うか - metarename -x コマンドを使用すれば、既存のストライプや連結を簡単にミラー化およびミラー化解除したり、既存のメタデバイスのトランスメタデバイスを簡単に作成および除去することができます。
メタデバイス名の切り替えを行うメリット - メタデバイス名の切り替えは、メタデバイス名を管理する上で好都合です。たとえば、ファイルシステムのマウント先をすべて希望の数値範囲内で定めることができます。
切り替えできるメタデバイスの組み合わせ - metarename -x コマンドは、次のものの切り替えに使用できます。
ミラーとサブミラー (連結またはストライプ)
トランスメタデバイスとマスターデバイス。ここで、マスターデバイスは、連結、ストライプ、ミラー、または RAID5 メタデバイスのいずれか。
メタデバイス名の切り替えは、いずれの方向にも行えます。
ミラー化されたマスターデバイスのあるトランスメタデバイス - マスターデバイスがミラーである場合、ミラーのサブミラーの 1 つをトランスメタデバイスと直接切り替えることはできません。ミラーとトランスメタデバイスの名前、あるいはミラーとそのサブミラーの 1 つを切り替えることはできます。切り替えの関係は、常に親子です。本質的には、次に紹介する 2 手順のプロセスを使用すれば、サブミラーとトランスメタデバイスとの交換と同じ結果が得られます。まず、サブミラーとミラーとを切り替え、さらにミラーとトランスメタデバイスとを切り替えます。
トランスメタデバイスのコンポーネントを切り替えるときに「Rename busy」メッセージが表示された - このメッセージは、次の 1 つ以上の状況を意味します。
i. 最初にロギングデバイスを切断しなかった。
ii. トランスメタデバイスを使用してファイルシステムをマウント解除しなかった。
現在使用中のメタデバイスは切り替え (またはリネーム) できません。
これには、マウントされたファイルシステム、swap、またはアプリケーションやデータベースの有効な記憶領域として使用されるメタデバイスが含まれます。したがって、metarename コマンドを使用する前に、リネームされるメタデバイスに対するすべてのアクセスを停止します。たとえば、メタデバイスを使用してマウントされたファイルシステムをマウント解除します。アプリケーションやデータベースには、アクセスを停止するために指定された方法で行うことが必要です。
エラー状態のメタデバイスを切り替えたり、ホットスペア交換を使用してメタデバイスを切り替えることはできません。
切り替えは、直接的な親と子の関係にあるメタデバイス間でのみ行えます。
たとえば、マスターデバイスであるミラー内のストライプとトランスメタデバイスを直接に交換することはできません。
トランスデバイスのメンバーを切り替える場合は、-f (強制) フラグを使用する必要があります。
ロギングデバイスを切り替える (またはリネームする) ことはできません。
この回避策としては、ロギングデバイスを切断してリネームしてからトランスデバイスに再接続するか、またはロギングデバイスを切断して、希望する名前をもつ別のロギングデバイスを接続します。
既存のストライプがある場合、metarename -x コマンドを使用して複合メタデバイスを作成することができます。これには、マスターデバイスとしてメタデバイスをもつトランスデバイス、または連結方式からのミラー作成が含まれます。
この例は、マウントされたファイルシステムをもつ連結 d1 で始まり、d1 という名前の 2 面のミラーにマウントされたファイルシステムで終わります。
# metastat d1 d1: Concat/Stripe Size: 5600 blocks Stripe 0: Device Start Block Dbase c0t0d0s1 0 No # metainit d2 1 1 c1t3d0s1 d2: Concat/Stripe is setup # metainit -f d20 -m d1 d20: Mirror is setup # umount /fs2 # metarename -x d20 d1 d20 and d1 have exchanged identities # metastat d1 d1: Mirror Submirror 0: d20 State: Okay ... d20: Submirror of d1 State: Okay ... # metattach d1 d2 d1: submirror d2 is attached # metastat d1 d1: Mirror Submirror 0: d20 State: Okay Submirror 1: d2 State: Okay ... # mount /fs2 |
metastat コマンドは、連結 d1 が「Okay (正常)」状態であることを確認します。metainit コマンドを使用して 2 番目の連結 (d2) を作成し、さらに d1 からミラー d20 を強制的に (-f) 作成します。metarename -x を使用して d20 と d1 を切り替える前に、ファイルシステムをマウント解除しなければなりません。d1 はトップレベルのデバイス (ミラー) となり、metastat がそのことを確認します。d2 を 2 番目のサブミラーとして接続し、metastat でミラーの状態を確認してから、ファイルシステムを再マウントします。なお、/fs2 用のマウントデバイスは変化していないため、/etc/vfstab ファイルを編集する必要はありません。
この例は、マウントされたファイルシステムをもつミラー d1 から始まり、d1 という名前のトランスデバイスにマウントされたファイルシステムで終わります。
# metastat d1 d1: Mirror Submirror 0: d20 State: Okay Submirror 1: d2 State: Okay ... # umount /fs2 # metainit d21 -t d1 d21: Trans is setup # metarename -f -x d21 d1 d21 and d1 have exchanged identities # metastat d1 d1: Trans State: Detached Size: 5600 blocks Master Device: d21 ... # metattach d1 d0 d1: logging device d0 is attached # mount /fs2 |
metastat コマンドは、ミラー d1 が「Okay (正常)」状態であることを確認します。metainit コマンドを使用して、マスターとして d1 をもつトランスデバイス d21 を作成する前に、ファイルシステムをマウント解除しなければなりません。metarename -f -x コマンドは、d21 と d1 を強制的に切り替えます。d1 は現在トップレベルのトランスメタデバイスであり、そのことは metastat コマンドによって確認されます。ロギングデバイス d0 は、metattach コマンドによって接続されます。それから /fs2 を再マウントします。なお、/fs2 用のマウントデバイスは変化していないため (まだ d1 です)、/etc/vfstab ファイルを編集する必要はありません。
既存のミラーやトランスメタデバイスがある場合、metarename -x コマンドを使用してミラーやトランスメタデバイスを除去し、配下のメタデバイスにデータを保持できます。トランスメタデバイスの場合、マスターデバイスがメタデバイス (ストライプ / 連結、ミラー、または RAID5 メタデバイス) である限り、そのメタデバイス上にデータを保持できます。
このプロセスの一部として metarename -x を使用する場合、ファイルシステムのマウント先には変化がありません。
この例は、マウントされたファイルシステムを含むミラー d1 で始まり、d1 という名前のストライプにマウントされたファイルシステムで終わります。
# metastat d1 d1: Mirror Submirror 0: d20 State: Okay Submirror 1: d2 State: Okay Pass: 1 ... # umount /fs2 # metarename -x d1 d20 d1 and d20 have exchanged identities # metastat d20 d20: Mirror Submirror 0: d1 State: Okay Submirror 1: d2 State: Okay ... # metadetach d20 d1 d20: submirror d1 is detached # metaclear -r d20 d20: Mirror is cleared d2: Concat/Stripe is cleared # mount /fs2 |
metastat コマンドは、ミラー d1 が「Okay (正常)」状態であることを確認します。このファイルシステムは、ミラー d1 とそのサブミラー d20 を交換する前に、マウント解除されます。これによってミラーは d20 となり、そのことは metastat で確認されます。次に、d1 が d20 から切断され、ミラー d20 ともう一方のサブミラー d2 が削除されます。最後に、/fs2 が再マウントされます。なお、/fs2 用のマウントデバイスは変化していないため、/etc/vfstab ファイルを編集する必要はありません。
この例は、マウントされたファイルシステムを含むトランスメタデバイス d1 で始まり、トランスメタデバイスの配下のマスターデバイス (d1 となる) 上にマウントされたファイルシステムで終わります。
# metastat d1 d1: Trans State: Okay Size: 5600 blocks Master Device: d21 Logging Device: d0 d21: Mirror Submirror 0: d20 State: Okay Submirror 1: d2 State: Okay ... d0: Logging device for d1 State: Okay Size: 5350 blocks # umount /fs2 # metadetach d1 d1: logging device d0 is detached # metarename -f -x d1 d21 d1 and d21 have exchanged identities # metastat d21 d21: Trans State: Detached Size: 5600 blocks Master Device: d1 d1: Mirror Submirror 0: d20 State: Okay Submirror 1: d2 State: Okay # metaclear 21 # fsck /dev/md/dsk/d1 ** /dev/md/dsk/d1 ** Last Mounted on /fs2 ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FILE SYSTEM STATE IN SUPERBLOCK IS WRONG; FIX? y 3 files, 10 used, 2493 free (13 frags, 310 blocks, 0.5% fragmentation) # mount /fs2 |
metastat コマンドは、トランスメタデバイス d1 が「Okay (正常)」状態にあることを確認します。ファイルシステムは、トランスメタデバイスのロギングデバイスを切断する前に、マウント解除されます。トランスメタデバイスとそのミラー化されたマスターデバイスは、-f (強制) フラグを使用して交換されます。metastat を再実行すると、交換が行われたことを確認できます。必要ならば、トランスメタデバイスとロギングデバイス (この場合は、それぞれ d21 と d0) が除去されます。次に、ミラー d1 上で fsck コマンドを実行し、入力要求に対して y と応答します。fsck コマンドが終了すると、ファイルシステムが再マウントされます。なお、/fs2 用のマウントデバイスは変化していないため、/etc/vfstab ファイルを編集する必要はありません。
この節では、障害の発生したコントローラ上に定義され、散発的なシステムパニックを引き起こすメタデバイスへのアクセスを取り戻す手法について説明します。システムに別の使用可能なコントローラがある場合、コントローラにディスクを移動してメタデバイスを再定義することによって、メタデバイスを新しいコントローラに事実上「移動する」ことができます。この手法では、データをバックアップしメタデバイスに戻す必要がなくなります。
この例は、2 つのスライスをもつ 1 つのディスクから構成されます。この 2 つのスライスは、それぞれ 2 つの別のストライプ方式メタデバイスである d100 と d101 の一部です。d100 と d101 は、それぞれファイルシステム /user6 と /maplib1 を含みます。影響を受けたコントローラは c5 でした。ディスクは空きコントローラ (c4) に移動されます。この例では md.tab ファイルも使用します。
影響を受けるストライプへのアクセスを停止する。
たとえば、ストライプ方式メタデバイスに関連付けられたファイルシステムをマウント解除します。
# umount /user6 # umount /maplib1 |
metaclear を使用して、ストライプ方式メタデバイスを除去する。
# metaclear d100 d100: Concat/Stripe is cleared # metaclear d101 d101: Concat/Stripe is cleared |
サーバーをシャットダウンし、ディスクを新しいコントローラに移動する。
md.tab ファイルを編集して、メタデバイス名の中に新しいコントローラを指示する。
この例では、ディスクをコントローラ 4 に移動したので、ディスクに対しては c5 ではなく c4 を使用します。
(md.tab ファイルの変更前) # Stripe /user6 /dev/md/dsk/d100 1 2 /dev/dsk/c5t0d0s3 /dev/dsk/c2t2d0s3 # Stripe /maplib1 /dev/md/dsk/d101 1 2 /dev/dsk/c5t0d0s0 /dev/dsk/c2t2d0s0 (md.tab ファイルの変更後) # Stripe /user6 /dev/md/dsk/d100 1 2 /dev/dsk/c4t0d0s3 /dev/dsk/c2t2d0s3 # Stripe /maplib1 /dev/md/dsk/d101 1 2 /dev/dsk/c4t0d0s0 /dev/dsk/c2t2d0s0 |
metainit を使用してそのストライプ方式メタデバイスを初期化し、newfs でファイルシステムを再初期化せずにマウントする。
# metainit d100 d100: Concat/Stripe is setup # metainit d101 d101: Concat/Stripe is setup |
metastat を実行して、メタデバイスがオンラインであることを確認する。
メタデバイスまたはその関連付けられたファイルシステム上では、newfs コマンドを実行しないでください。さもなければ大量のデータが失われ、テープから復元しなければなりません。
この節では、ミラーとその操作についていくつかのヒントを提供します。
次に示す 2 つの作業では、ミラーを破壊せずにサブミラーの飛び越し値を変更する方法、およびオンラインバックアップ用にミラーを使用する方法を示します。
この作業では、ストライプ方式メタデバイスで構成される、ミラーの配下のサブミラーの飛び越し値を変更します。この方法を使用すれば、ミラーとサブミラーを再作成してデータを復元する必要がありません。
コマンド行を使用してこの作業を実行するには、 metadetach(1M)、metainit(1M)、および metattach(1M) のマニュアルページを参照してください。
この作業に含まれる手順の概要を次に示します。
サブミラー 1 の切断
サブミラー 1 の除去
サブミラー 1 として使用される、新しい飛び越し値をもつ新しいストライプを作成
サブミラー 1 をミラーに接続
ミラー再同期の終了を待つ
サブミラー 2 に対して、上述の手順を繰り返す
DiskSuite ツールが起動されていることを確認する。
オブジェクトリストからミラーオブジェクトをダブルクリックする。
オブジェクトがキャンバスに表示されます。
切断されるサブミラーの内部をクリックする。
サブミラーをミラーオブジェクトからキャンバスにドラッグする。
これが 2 面のミラーである場合、ミラーの状態は「緊急」に変化します。
ミラーオブジェクトの先頭の矩形をクリックし、「確定」をクリックする。
希望する飛び越し値をもつ新しいサブミラーを作成する。
「ストライプ方式メタデバイスの作成方法 (DiskSuite ツール)」を参照してください。
新しいサブミラーオブジェクトをミラーオブジェクトにドラッグする。さらに「確定」をクリックしてミラーを確定する。
ミラーの再同期が始まります。
コンフィグレーションログを表示して、ミラーが確定されたことを確認する。
DiskSuite は「バックアップ製品」ではありませんが、ミラーをマウント解除したりミラー全体をオフラインにすることなく、またシステムを停止したりデータへのユーザーアクセスを拒否することなく、ミラー化されたデータをバックアップするための手段を提供します。これは次のように行われます。サブミラーの 1 つをオフラインにして (一時的にミラーの機能を失います)、バックアップを実行します。バックアップが終了すると、すぐにそのサブミラーをオンラインに戻し、再同期を行います。
この作業は、ルート (/) を除いて、どのファイルシステムでも使用できます。この種のバックアップでは、動作中のファイルシステムの「スナップショット」を取得していることに留意してください。ファイルシステムが書き込みロックされたときの使用方法に応じて、バックアップ上の一部のファイルとファイル内容が、ディスク上の実際のファイルと一致しないことがあります。
この作業を 2 面ミラーで行う場合、1 つのサブミラーがバックアップ用にオフラインになっているとき、データの冗長性が失われることに注意してください。3 面ミラーでは、この問題は発生しません。
バックアップが終了してから、オフラインにされていたサブミラーがオンラインに復帰するとき、システムには若干の負荷が発生します。
これらの作業を定期的に使用する場合、スクリプトにすると使いやすくなります。
この作業の手順を次に示します。
ファイルシステムの書き込みロック (UFS のみ)。ルート (/) はロックしない。
metaoffline(1M) コマンドを使用して、1 つのサブミラーをミラーからオフラインにする。
ファイルシステムのロック解除。
オフラインにしたサブミラー上のデータのバックアップ。
metaonline(1M) コマンドを使用して、オフラインにされたサブミラーをオンラインに戻す。
作業を開始する前に、metastat(1M) コマンドを実行して、ミラーが「Okay (正常)」状態にあることを確認する。
「Maintenance (保守状態)」のミラーは、最初に修復してください。
ルート (/) を除くすべてのファイルシステムで、ファイルシステムを書き込みからロックする。
# /usr/sbin/lockfs -w <マウント先> |
UFS だけを書き込みロックする必要があります。メタデバイスが、データベース管理ソフトウェアやその他の特定アプリケーション用の raw デバイスとして設定された場合、lockfs(1M) の実行は必要ありません (しかし、他社提供の適切なユーティリティを実行して、バッファをフラッシュしたりアクセスをロックすることもできます)。
ルート (/) を書き込みロックすると、システムがハングアップすることがあります。したがって、これを行なってはいけません。
1 つのサブミラーをミラーからオフラインにする。
# metaoffline <ミラー> <サブミラー> |
このコマンドでは、
ミラー |
ミラーのメタデバイス名。 |
サブミラー |
オフラインにされるサブミラー (メタデバイス) の メタデバイス名。 |
読み取りは、他のサブミラーから続行されます。最初の書き込みが行われると、ミラーはすぐに同期外れとなります。この不一致は、オフラインにされたサブミラーが手順6 でオンラインに戻ると訂正されます。
オフラインにされたファイルシステムでは、fsck(1M) を実行する必要はありません。
ファイルシステムのロックを解除し、書き込みを継続させる。
# /usr/sbin/lockfs -u <マウント先> |
上の 手順 2 で使用された他社提供のユーティリティにもとづいて、必要なロック解除作業を実行する必要があります。
オフラインにされたサブミラーのバックアップを実行する。ufsdump(1M)、または通常使用しているバックアップユーティリティを使用する。
適切なバックアップを行うには、/dev/md/rdsk/d4 などの raw メタデバイスを使用します。「rdsk」を使用すると、2G バイトを超えるアクセスが可能となります。
ミラーをオンラインに戻す。
# metaonline <ミラー> <サブミラー> |
DiskSuite は、サブミラーとミラーの再同期を自動的に開始します。
この例では、サブミラー d2 と d3 から成る、d1 という名前のミラーを使用します。d3 はオフラインにされ、d2 がオンラインである間にバックアップされます。ミラー上のファイルシステムは /home1 です。
# /usr/sbin/lockfs -w /home1 # metaoffline d1 d3 d1: submirror d3 is offlined # /usr/sbin/lockfs -u /home1 (/dev/md/rdsk/d3 を使用してバックアップを実行する) # metaonline d1 d3 d1: submirror d3 is onlined |
ルート (/)、/usr、および swap 用のミラーを備えたシステム (いわゆる「ブート」ファイルシステム) がシングルユーザーモードでブートされる (boot -s) と、これらのミラーだけではなく、おそらくシステム上のすべてのミラーが、metastat コマンドで見ると「Needing Maintenance」状態として表示されます。その上、これらのスライスに書き込みが行われた場合、metastat はミラー上にダーティリージョンが増えることを明らかにします。
これは危険なように見えるかもしれませんが、心配する必要はありません。metasync -r コマンドは、通常はミラーを再同期するためにブート処理時に実行されますが、システムがシングルユーザーモードでブートされたときには、実行を中断します。システムがリブートされると、metasync -r が実行されて、すべてのミラーを再同期します。
これが心配な場合、metasync -r を手動で実行します。
ホットスペア集合には、0 〜 n 個のホットスペアを含むことができます。1 つのホットスペア集合は、複数のサブミラーや RAID5 メタデバイスと関連付けることができます。さまざまなサイズのスライスをもつホットスペア集合を 1 つ定義し、すべてのサブミラーや RAID5 メタデバイスと関連付けることができます。DiskSuite は、必要ならば正しいサイズのホットスペアの使用法を判断します。
コントローラ系統の障害に耐えるために、コントローラ全体にまたがったホットスペアをホットスペア集合に置きます。この点では、サブミラーを作成する場合と同じガイドラインに従ってください。
この節では、ディスクセットを構成するためのヒントを紹介します。
現在、DiskSuite は、SPARCstorage Array ディスク上のディスクセットだけをサポートしています。
ディスクセット構成で使用するハードウェアを構成するのは少々やっかいな場合があります。ディスクドライブは対称的でなければなりません。つまり、共有ドライブには同じデバイス番号が必要であるため、同じデバイス名と番号 (コントローラ / ターゲット / ドライブ) が必要になります。この作業では、この設定の構成方法について説明します。
ハードウェアがあらかじめ構成されている新しいマシンセットでは、必要な対称性はデフォルトで実現されています。この作業を実行する必要はありません。
ディスクセット内にメタデバイスを作成する前に、デバイス名の設定を終了しなければなりません。非組み込みコントローラに置かれている他のドライブも、影響を受けることになります。
ディスクコントローラは、同じ順序で見つかるスロットに置かれていることを確認する。
このための最も良い方法は、特定の SPARCstorage Array に対するコントローラを、同一プロセッサモデルの同じスロットに置くことです。これが不可能な場合、スロットの順序が両方のプロセッサで同一になることを確認する必要があります。Sbus のプローブは規則正しく実施されるので、こうすることは可能ですが簡単ではありません。また、スロットは小さな番号のスロットから順に使用し、未使用のスロットはすべてハイエンド側に残すことをお勧めします。
構成システムは、同じ種類のコントローラ順に番号を付けます。この場合、「ディスクドライブ」がその種類にあたるため、ディスクドライブ用のすべてのコントローラは、デバイスが見つけ出される順序に影響を与えます。このため、共有されるすべてのデバイスは、システム内の他のディスクコントローラより前に置かれることになるため、正しい順序で検出されます。
これが終了すると、両方のホストマシンでインストールを完了するか、またはこの作業を続行することができます。後者の方がはるかに速くなります。
1 つずつ、各ホスト上でスーパーユーザーになり、次の操作を実行します。
# rm /etc/path_to_inst* # reboot -- '-rav' reboot: rebooted by root syncing file systems... [1] done rebooting... Resetting ... Rebooting with command: -rav Boot device: /iommu/sbus/espdma@f,400000/esp@f,800000/sd@3,0 File and args: -rav Enter filename [kernel/unix]: Size: 253976+126566+39566 Bytes Enter default directory for modules [/kernel /usr/kernel]: SunOS Release 5.4 Generic [UNIX(R) System V Release 4.0] Copyright (c) 1983-1995, Sun Microsystems, Inc. Name of system file [etc/system]: The /etc/path_to_inst on your system does not exist or is empty. Do you want to rebuild this file [n]? y Using default device instance data root filesystem type [ufs]: Enter physical name of root device [/iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000/esp@f,800000 /sd@3,0:a]: ... The system is ready. console login: root Password:<パスワードを入力> # /usr/bin/rm -r /dev/*dsk/* # /usr/sbin/disks # ^D |
ハードウェアが正しく設定されているものと仮定すると、これによってソフトウェアがその設定を反映します。/etc/path_to_inst ファイルは、ものがスライドする (コントローラの移動によってスライドしやすくなる) ことのないように使用されているため、コントローラが正しい位置にスライドするように除去されます。-rav オプション付きの reboot コマンドによって、カーネルはブート中にユーザーと対話処理を行い、再構成リブートを行います。/dev/*dsk/* の除去は、/usr/sbin/disks プログラムが実行されたときにシボリックリンクが正しく作成されるために使用されます。
SPARCstorage Array コントローラには、Solaris への識別情報となる一意な World Wide Name が収められているため、SPARCstorage Array コントローラの交換には特別な作業が適用されます。詳細については、製品のご購入先にお問い合わせください。
ディスクセット内で状態データベースの複製のサイズを変更したい場合、基本的な手順としては、2 つのディスクをディスクセットに追加し、新しいディスクの状態データベースの複製の 1 つを削除し、さらに他のディスクをディスクセットから削除します。その後、ディスクセットに追加したい他のディスクと一緒に、削除されたディスクをディスクセットに追加して戻します。状態データベースの複製は、新しいサイズに合わせて自分自身を自動的にサイズ変更します。
# metadb -s rimtic -d c1t0d0s7 # metadb -s rimtic -a -l 2068 c1t0d0s7 # metaset -s rimtic -d c1t1d0 # metaset -s rimtic -a c1t1d0 # metadb -s rimtic |
この例では、ディスクセット rimtic に 2 つのディスクがすでに追加されており、複製が追加されるディスクの残りの部分にはデータが存在しないものと想定します。状態データベースの複製の新しいサイズは、-l 2068 オプションで指定されるように、2068 ブロックとなります。metadb コマンドは、状態データベースの複製の新しいサイズを確認します。