この章では,以下の操作について説明します。
LSM 構成を持つシステムまたはクラスタを,Tru64 UNIX の Version 4.0 から Version 5.0 以降にアップグレードする (7.1 節)
LSM を使用しているシステムをクラスタに追加する (7.2 節)
ディスク・グループをシステム間で移動する (7.3 節)
ブート・ディスクのカプセル化を解除する (スタンドアロン・システムの場合)(7.4 節)
AdvFS ドメインを LSM ボリュームから物理ストレージに移行する (7.5 節)
クラスタ・メンバのスワップ・デバイスをカプセル化解除する (7.6 節)
LSM ソフトウェアをアンインストールする (7.7 節)
現在 Tru64 UNIX Version 4.0 が稼働しているシステムで LSM を使用していて,Tru64 UNIX Version 5.0 以降でも現在の LSM 構成を使用したい場合には,以下の操作を行う必要があります。
ブロック変更ログ (BCL) のサイズを増やします。 スタンドアロン・システムの場合は,ボリューム・サイズ 1 GB に対して少なくとも 2 ブロック,TruCluster Server 環境の場合は,ボリューム・サイズ 1 GB に対して少なくとも 65 ブロック,大きくします (7.1.1 項)。
現在の LSM 構成をバックアップします (7.1.2 項)。
必要であれば,アップグレードしたくないディスク・グループをデポートします (7.1.3 項)。
LSM ソフトウェアをアップグレードします (7.1.4 項)。
アップグレードを行う前にデポートしたすべての Version 4.0 ディスク・グループを手作業で変換します (7.1.5 項)。
復元した LSM 構成データベースを最適化します (7.1.6 項)。
Tru64 UNIX Version 4.0 の LSM でサポートされていたブロック変更ロギング (BCL) は,Version 5.0 でダーティ・リージョン・ロギング (DRL) 機能で置き換えられました。
アップグレード・インストレーションの実行時に,BCL サブディスクが少なくとも 2 ブロックある場合,BCL は自動的に DRL に変換されます。 BCL サブディスクが 1 ブロックの場合は,アップグレード・インストレーション後にロギングが使用不能になります。
注意
BCL からDRL への変換を元に戻すことはできません。
アップグレード前に,BCL のサイズを,ボリューム・サイズ 1 GB に対して少なくとも 2 ブロック (スタンドアロン・システムの場合) または少なくとも 65 ブロック (TruCluster 環境の場合) に増やしてください。
アップグレード前に増やすことができない場合は,アップグレード後に
volassist addlog
コマンドを使用すると,ボリュームに新しいログを追加できます。
これにより,デフォルトで適切なサイズの DRL が作成されます。
BCL のサイズを増やす方法の詳細は,使用しているオペレーティング・システムのバージョンに対応した LSM のマニュアルを参照してください。
7.1.2 LSM 構成のバックアップ
LSM 構成をバックアップすると,すべてのディスク・グループ内のすべての LSM オブジェクトについて記述したファイルが作成されます。 大きな障害が発生したときには,LSM はこのファイルを使用して LSM 構成を復元できます。
注意
次の手順ではボリューム・データはバックアップせず,構成だけをバックアップします。 また,アップグレードの実行前に,ボリューム・データをバックアップすることもできます。
LSM の構成をバックアップするには,次の手順に従います。
次のコマンドを入力します。
# volsave [-d dir]
LSM configuration being saved to /usr/var/lsm/db/LSM.20020312143345.hostname volsave does not save configuration for volumes used for root, swap, /usr or /var. LSM configuration for following system disks not saved: dsk3 dsk0a dsk2a dsk0b dsk2b dsk0g dsk0g LSM Configuration saved successfully to /usr/var/lsm/db/LSM.20020312143345.hostname
省略時の設定では,LSM の構成情報は
/usr/var/lsm/db
ディレクトリ内の,記述セットというタイムスタンプ付きファイルに保存されます。
このファイルの位置と名前を記録しておいてください。
この情報は,Tru64 UNIX オペレーティング・システム・ソフトウェアのアップグレード後,LSM 構成を復元するために必要となります。
必要な場合,LSM 構成が保存されたことを確認します。
# ls /usr/var/lsm/db/LSM.date.hostname dg1.d newdg.d volboot header rootdg.d voldisk.list
LSM 構成をテープまたは他のリムーバブル・メディアに保存します。
Tru64 UNIX Version 5.0 以降の LSM の内部メタデータ・フォーマットは,Tru64 UNIX Version 4.0 の LSM のメタデータ・フォーマットとは互換性がありません。 アップグレード手順中に古いメタデータ・フォーマットを検出すると,LSM は自動的に古いフォーマットを新しいフォーマットにアップグレードします。 アップグレードしたくないディスク・グループがある場合は,LSM をアップグレードする前にそのディスク・グループをデポートしなければなりません。
rootdg
ディスク・グループはデポートできません。
rootdg
は新しいフォーマットに変換して,アップグレード後のシステムで LSM 構成を使用できるようにする必要があります。
rootdg
は,一度変換すると,Version 4.0 で運用しているシステムでは使用できなくなります。
ディスク・グループをデポートするには,次のコマンドを入力します。
# voldg deport disk_group
デポートしたディスク・グループを後でインポートすると,LSM がそのメタデータ・フォーマットをアップグレードします。
7.1.4 LSM ソフトウェアのアップグレード
LSM は,3 つのソフトウェア・サブセットからなっています。 これらのサブセットは,Tru64 UNIX プロダクト・キット用のベース・オペレーティング・システム・ソフトウェアが収められた CD-ROM に入っています。
アップグレードの前後のオペレーティング・システムのバージョンによっては,アップデート・インストールではなく,フル・インストールが必要な場合や,一連のアップデート・インストール手順が必要になる場合があります。 サポートされているアップデート・パスについては,『インストレーション・ガイド』を参照してください。
アップデート・インストレーションの際には,アップグレードしているシステムに LSM サブセットがすでにインストールされている場合,LSM サブセットを指定する必要はありません。 アップデート・インストレーション処理は,システムにインストールされているすべてのサブセットを自動的にアップグレードします。
Tru64 UNIX Version 4.0x から Version 5.0x にアップグレードしているシステムに LSM がインストールされていない場合は,アップデート・インストレーションの際に LSM をインストールすることはできません。 LSM をインストールするには,オペレーティング・システムのフル・インストレーションを行う必要があります。
フル・インストレーションの際には,必要に応じて,ベース・システムのルート (/
),/usr
,および
/var
ファイル・システムとスワップ領域を LSM ボリュームにインストールできます。
このシステムをクラスタの作成に使用する場合や,クラスタに追加するために使用する場合は,この手順はスキップしてください。
ベース・システムのルート LSM ボリュームは,クラスタでは使用できません。
注意
現在 LSM 構成の一部として使用されているディスクにオペレーティング・システムをインストールしないように注意してください。 インストレーション処理によってディスク上のすべてが書き換えられるため,構成が失われます。
アップデート・インストレーション,またはフル・インストレーションが完了すれば,rootdg
ディスクは変換され,使用可能な状態になります。
システムに接続されたままでデポートされなかったディスク・グループも変換され使用できる状態になります。
7.1.5 Version 4.0 ディスク・グループの手作業での変換
システムまたはクラスタを Version 4.0 から Version 5.0 以降へアップグレードする前にディスク・グループをデポートした場合には,このディスク・グループを手作業でインポートし,変換することができます。
システムを再起動する前,またはクラスタを作成する前にシステムに接続されていたディスク・グループは,自動的にインポートされます。
ディスク・グループのメタデータ・フォーマットはアップデートされます。
BCL は,vollogcnvt
ユーティリティによって,可能な限り DRL に変換されます
(詳細は,
vollogcnvt
(8)
以下に説明する手順は,オペレーティング・システムをアップグレードする前にデポートし,インポートと変換を行うことに決めていたディスク・グループに対してのみ,適用できます。
この手順では次のことが行われます。
ディスク・グループの内部メタデータ・フォーマットを Version 5.0 以降で使用するフォーマットに変換します。
BCL が少なくとも 2 ブロックあるすべてのボリュームの,BCL ログを DRL ログに変換します。
BCL ログを DRL ログに変換できないボリュームを通知します。
ボリュームは使用できますが,ロギングは行われません。 ロギングを使用可能にするには,BCL サブディスクを手動で削除し,新しい DRL ログを追加する必要があります。
ディスク・グループを手動でインポートして変換するには,以下の手順を実行します。
ストレージをシステムまたはクラスタに物理的に接続します。
クラスタの場合,すべてのクラスタ・メンバからアクセスできるようにストレージを接続します。
hwmgr
コマンドを実行して,システムまたはクラスタを新しいディスク情報でアップデートします。
詳細は,
hwmgr
(8)
ディスク・グループをインポートし,変換します。
# voldg -o convert_old import disk_group
ディスク・グループがインポートされます。 ディスク・グループ内に BCL を使用しているボリュームがある場合,次のようなメッセージが表示されます。
lsm:voldg:WARNING:Logging disabled on volume. Need to convert to DRL. lsm:voldg:WARNING:Run the vollogcnvt command to automatically convert logging.
各ディスク・グループの BCL を DRL に変換します。
# vollogcnvt -g disk_group
DRL に変換できなかった BCL があり,そのボリュームのロギングを復元したい場合は,次の手順に従います。
使用不能になっている BCL サブディスクを見つけます。
# volprint [-g disk_group] volume
BCL サブディスクを削除します。
# volsd [-g disk_group] -o rm dis subdisk
ボリュームに新しいログを追加します。
# volassist [-g disk_group] addlog volume
新しくインポートした各ディスク・グループでボリュームを起動します。
# volrecover -g disk_group
7.1.6 復元した LSM 構成データベースの最適化 (オプション)
Tru64 UNIX Version 4.0 から Tru64 UNIX Version 5.0 以降にアップグレードしたシステム上に LSM 構成を復元した場合,構成データベースを変更して,構成データベースの数と位置を LSM が自動的に管理するようにできます。
注意
この手順は最適化であり,必須ではありません。
Tru64 UNIX Version 4.0 上で LSM を使用するシステムでは,ディスク・グループごとに 4 〜 8 個のディスクとし,使用可能データベースを持つように明示的に構成しなければなりませんでした。 Version 5.0 以降では,特に指定しなくても,すべての LSM ディスクがデータベースのコピーを持つように構成されるため,LSM は自動的に適切な数の使用可能なコピーを維持します。 使用可能状態のコピーと使用不能状態のコピーの違いは,次のとおりです。
使用不能 -- ディスクのプライベート・リージョンが構成データベースのコピーを持つように構成されていますが,そのコピーは休止中 (非アクティブ) です。 LSM は,このコピーを必要に応じて (たとえば,使用可能なコピーを持つディスクが削除されたときや障害の際などに) 使用可能にします。
使用可能 -- ディスクのプライベート・リージョンが構成データベースのコピーを持つように構成されており,そのコピーがアクティブです。 LSM 構成に対するすべての変更は,変更が発生した時に構成データベースのすべての使用可能なコピーに記録されます。
次のような特別な理由がない限り,すべての LSM ディスク上のプライベート・リージョンに,構成データベースのコピーを 1 つ持たせるように構成します。
ディスクが古い,または遅い場合。
ディスクが負荷の高いバス上にある場合。
構成データベースのコピーを持つには,プライベート・リージョンが小さすぎる (4096 ブロック未満) 場合 (初期のリリースの LSM から移行したディスクなど)。
ディスクにコピーを持たせることができない,その他の重要な理由がある場合。
構成データベースを使用可能にしても,ディスク上で使用するスペースは増えません。 使用可能にすると,プライベート・リージョン内の使用可能コピー数に 1 が設定されるだけです。
構成データベースのコピー数に 1 を設定するには,次のコマンドを入力します。
# voldisk moddb disk nconfig=1
ディスクが 3 個以下しかないディスク・グループについては,十分な冗長性を確保するために,各ディスクに構成データベースのコピーを 2 つ含めるように構成しなければなりません。
これは,rootdg
ディスク・グループが小さく,大きなセカンダリ・ディスク・グループが 1 つ以上あるシステムで特に重要です。
LSM 構成データベースの変更についての詳細は,5.3.3 項を参照してください。
7.2 LSM を使用しているシステムの,クラスタへの追加
LSM ボリュームを使用しているスタンドアロン・システムを既存のクラスタへ追加し,クラスタも LSM を使用しているかどうかとは無関係に,クラスタ内の LSM ボリュームと協調させることができます。 または,ディスク・グループだけをシステム間で移動したり,システムからクラスタへ移動することもできます。
注意
スタンドアロン・システムで Version 5.0 より前の Tru64 UNIX を実行している場合は,システムをクラスタに追加する前にシステムと LSM 構成をアップグレードする方法について,7.1 節を参照してください。
作業を開始する前に,スタンドアロン・システムの
rootdg
ディスク・グループをどうするかを決める必要があります。
1 つの LSM 構成には 1 つの
rootdg
ディスク・グループしか存在できません。
クラスタで LSM を実行しているときに,スタンドアロン・システムの
rootdg
ディスク・グループ内のディスクを使用したい場合は,クラスタにインポートするときに前の
rootdg
の名前を変更するか,LSM ディスクを別のディスク・グループに追加する必要があります。
クラスタで LSM を実行していないときに,クラスタ上で
rootdg
を再使用したくない場合には,クラスタ用の
rootdg
を作成するために,1 つ以上の未使用のディスクを探す必要があります。
未使用のディスクを探す方法は,2.3 節を参照してください。
以下の説明と推奨事項を読んで,必要な作業を行ってください。
ベース・システムの LSM ボリュームのルート (/
),/usr
,および
/var
ファイル・システムと,クラスタの
cluster_root
,cluster_usr
,および
cluster_var
ドメインの間には,何の関係もありません。
同様に,スタンドアロン・システム上のプライマリ・スワップ・ボリューム (swapvol
) と,各メンバのプライベート・スワップ領域の間にも関係はありません。
クラスタにはプライマリ・スワップ領域はありません。
各メンバにはそれぞれのスワップ領域があります。
ベース・システム・ボリュームは使用されません。 これらのボリュームを使用するファイル・システムは,明示的にマウントされるまでは利用できません。 メンバを停止し,ベース・オペレーティング・システムを再びブートすると,これらのファイル・システムは使用可能になります。
インポートしたディスク・グループ内のこれ以外のすべての LSM ボリュームは,ストレージにアクセスできる限り,すべてのクラスタ・メンバで使用できます (共有されます)。
クラスタにシステムを追加する前に,ミラー化されているシステム・ボリュームのミラー化を解除して,ディスク・スペースをクラスタ内の別の用途に使用することもできます。
ルート・ファイル・システムは完全にカプセル化を解除する (LSM ボリュームからブート・パーティションを完全に削除する) 必要はありません。 ミラーを削除し,そのディスク・スペースを LSM の空きスペース・プールに戻せば,クラスタを作成できます。
ただし,スタンドアロン・システムを再び使用しない場合には,システムをクラスタに追加する前に,すべてのベース・システム・ボリュームを削除し,スライス
・ディスクまたはシンプル
・ディスクとして,ディスクを LSM 用に再初期化できます。
スタンドアロン・システムの LSM ディスクがローカルに接続されている場合,それらのディスクは,メンバにプライベートとなります。 そのメンバがクラッシュすると,クラスタはそのボリュームにアクセスできなくなります。 そのデータをクラスタの他のメンバにも使用可能にするには,クラスタで共有しているストレージにデータを移動してください。
同様に,スタンドアロン・システムに接続されている外部ストレージについても,クラスタ全体で使用可能にするか,メンバ固有のデータ専用にするかを検討してください。
性能上の理由で,スタンドアロン・システムの LSM 構成に,省略時以外の値と属性を使用することもあります。
たとえば,スタンドアロン・システムのミラー・ボリュームが,ボリューム・サイズ 1 GB 当たり 65 ブロック未満のログ・サブディスクしか持っていない場合には,クラスタ環境への移行をサポートするため,古いログを削除して新しいログ (サイズは省略時の設定で適切に決定されます) を追加します。 このようにしないと,これらのボリュームでのロギングは使用不能になります。 ただし,ボリューム自体は使用可能です。
LSM を使用しているスタンドアロン・システムを LSM を実行していないクラスタに追加するには,以下の手順を実行します。
該当する場合,すべてのミラー・ボリュームで省略時の DRL サイズを使用するように,ログ・サブディスクを再構成します。
省略時のサイズではないログ・プレックスを使用しているミラー・ボリュームを探します。
# volprint -pht | grep -p LOGONLY
以下のようなメッセージが表示されます。
この例では,ログ・プレックス
vol1-03
は 2 ブロック長ですが,ログ・プレックス
vol2-03
は 65 ブロックです。
pl vol1-03 vol1 ENABLED ACTIVE LOGONLY CONCAT - RW sd dsk27a-01 vol1-03 dsk27a 0 2 LOG dsk27a ENA pl vol2-03 vol2 ENABLED ACTIVE LOGONLY CONCAT - RW sd dsk27a-02 vol2-03 dsk27a 2 65 LOG dsk27a ENA
ボリュームから省略時のサイズではない DRL プレックスを削除します。
# volplex [-g disk_group] -o rm dis log_plex
たとえば,次のように入力します。
# volplex -o rm dis vol1-03
新しい DRL プレックスをボリュームに追加します。 このプレックスは,自動的に正しいサイズになります。
# volassist addlog volume
たとえば,次のように入力します。
# volassist addlog vol1
各ディスク・グループ内のすべてのボリュームを停止します。
# volume -g disk_group stopall
rootdg
以外の各ディスク・グループをデポートします。
# voldg deport disk_group
rootdg
のディスク・グループ ID
を表示します。
# voldg list rootdg | grep id dgid: 1007697459.1026.hostname
ディスク・グループ ID を記録しておいてください。
この情報は,rootdg
ディスク・グループをクラスタにインポートするとき必要になります。
システムを停止し,クラスタに追加します。 そのシステムのすべてのストレージがクラスタに接続されたことを確認してください (できれば,共用ストレージにします)。
この手順では,clu_add_member
コマンドを使用します。
また,ハードウェアやクラスタに固有の操作が必要になる可能性があります。
ただし,ここでは説明しません。
hwmgr
コマンドを実行し,クラスタを新しいディスク情報でアップデートします。
詳細は,
hwmgr
(8)
次のいずれかの方法で,LSM を初期化します。
スタンドアロン・システムの
rootdg
をクラスタの
rootdg
として再利用するには,次の手順を実行します。
LSM デバイス特殊ファイルを設定します。
# volinstall
LSM を使用不能モードで起動します。
# vold -m disable
LSM デーモンをソース・システムのホスト名で初期化します。
# voldctl init hostname
ソース・システムの
rootdg
ストレージがクラスタに接続されたことを確認します (できれば,共用ストレージにします)。
ソース・システムの
rootdg
ディスク・グループを初期化し,それをクラスタの
rootdg
ディスク・グループにします。
# voldg init rootdg
これにより,rootdg
ディスク・グループが自動的にインポートされますが,名前はまだソース・システムのホスト名のままです。
LSM を使用可能モードで再起動します。
# vold -k
これにより,その他のすべてのディスク・グループが自動的にインポートされます。 また,必要であれば,メタデータが最新のフォーマットに変換されて,共用として設定されます。
/etc/vol/volboot
ファイル内 (結果的に,新しい
rootdg
ディスク・グループ内のすべてのディスク) のホスト名をクラスタ別名にリセットします。
# voldctl hostid cluster_alias
クラスタの新しい
rootdg
を作成するには,次の手順を実行します。
少なくとも 2 つのディスクまたはディスク・パーティションを指定します。 たとえば,次のように入力します。
# volsetup dsk19 dsk20
古い
rootdg
を,ディスク・グループ ID を使用してインポートし,名前を変更します。
# voldg -o shared -n newname import id=rootdg_dgid
その他のディスク・グループをインポートし,共用として設定します。
# voldg -o shared import disk_group
手順 8 を実行したメンバ以外のメンバで次のコマンドを入力して,クラスタ全体で LSM を同期化します。
# volsetup -s
LSM ディスク・グループは,スタンドアロン・システム間,クラスタ間,スタンドアロン・システムからクラスタへ,およびクラスタからスタンドアロン・システムへ移動できます。 このとき,以下の条件のいずれかが満たされていると,これらのディスク上の LSM オブジェクトとデータが保持されます。
voldg
コマンドを使用してディスク・グループをデポートした。
復旧が必要な (たとえば,システム・クラッシュ時) ディスク・グループは,システム間では移動できません。 ディスク・グループは,最後に使用されていた環境で復旧する必要があります。
ディスク・グループを使用していた元のシステムが,正しくシャットダウンされている (rootdg
はデポートできないため,rootdg
についてはこの条件は必須です)。
システム間でディスク・グループを移動すると,新しいホスト・システムではディスクに新しいディスク・アクセス名を割り当てます。
LSM
nopriv
ディスク (ディスクやパーティションをカプセル化したときに作成される) の場合,オリジナルのディスク・アクセス名とそのディスク・メディア名の対応が失われたり,誤った名前に付け替えられることがあります。
このような状況を防ぐには,ディスク・メディア名と新しいディスク・アクセス名を手作業で対応付けなければなりません。
LSM
スライス
・ディスクおよびシンプル
・ディスクの場合は,LSM がこの名前の対応付けを管理します。
可能であればディスク・グループを移動する前に,プライベート・リージョンがあり,名前の対応付けが自動的に行われるスライス
・ディスクまたはシンプル
・ディスクへ,nopriv
ディスクのデータを移行してください。
別のディスクへのデータの移動についての詳細は,5.1.5 項を参照してください。
データをスライス
・ディスクやシンプル
・ディスクに移動できない場合は,7.3.3 項を参照してください。
ディスク・グループを新しいホストに移動する際には,ディスク・グループの名前やホスト ID を変更できます。 たとえば,ディスク・グループの名前が新しいホストのディスク・グループの名前と類似している場合は,混同を避けるために名前を変更します。 ディスク・グループの名前が新しいホストのディスク・グループと同じ場合は,名前を変更しなければなりません。
ディスク・グループのホスト ID は,オリジナル・システムからデポートするときに,移動先のシステムのホスト ID に変更することができます。
これにより,ディスク・グループを受け取るシステムが,起動時にそのディスク・グループを自動的にインポートすることが可能になります。
新しいホストがすでに実行中の場合,そのホストにディスク・グループをインポートしたときに,ディスク・グループのホスト ID が変更されます。
7.3.1 別のシステムへの rootdg ディスク・グループの移動
rootdg
ディスク・グループを 1 つのスタンドアロン・システムから別のシステムへ移動することができますが,次の制限があります。
システムのルート・ディスクとスワップ領域が LSM ボリュームにカプセル化されている場合には,それらを LSM の制御から削除してください。 ルート・ファイル・システムは,別のシステムで再利用することはできません。
システム・ボリュームの削除については,7.4 節を参照してください。
他のシステム固有のファイル・システムで LSM ボリュームを使用している場合にも,LSM の制御から削除してください。
1 つのシステムでファイル・システムが重複するのは許されていません。 システム間で移動できるのは,システムの動作上重要ではないか,ターゲット・システムに存在しないファイル・システムとアプリケーションだけです。
AdvFS ドメインまたは UFS ファイル・システムのカプセル化を解除する方法については,5.4.6.1 項を参照してください。
rootdg
に内部システム・ディスクが含まれる場合は,これらのディスクを
rootdg
から削除します (必要に応じて,LSM の制御からも削除します)。
rootdg
はデポートできません。
移動するには,システムをシャットダウンするか,システム上の LSM を停止する必要があります。
これにより,すべてのボリュームが停止し (これらのボリュームを使用するすべてのファイル・システムとアプリケーションからのアクセスも停止します),LSM デーモンも停止します。
rootdg
ディスク・グループをシステムから削除すると,新しい
rootdg
を作成しない限り,システムでは LSM が実行できなくなります。
システムで再び LSM を実行する計画がない場合,/etc/inittab
ファイルを編集し,LSM 起動ルーチンを削除します。
lsmr:s:sysinit:/sbin/lsmbstartup -b </dev/console >/dev/console 2>&1 ##LSM lsm:23:wait:/sbin/lsmbstartup </dev/console >/dev/console 2>&1 ##LSM vol:23:wait:/sbin/vol-reconfig -n </dev/console >/dev/console 2>&1 ##LSM
必要に応じて,ディレクトリ
/dev/vol/
および
/etc/vol/
を再帰的に削除します。
rootdg
以外のディスク・グループを別のシステムに移動するには,次の手順に従います。
ディスク・グループ内のボリュームに対するすべての動作を停止し,すべてのファイル・システムをアンマウントします。
元のシステムからディスク・グループをデポートします。
何も変更せずにディスク・グループをデポートするには,次のコマンドを入力します。
# voldg deport disk_group
ディスク・グループをデポートし,新しいホスト ID や新しい名前を割り当てるには,次のコマンドを入力します。
# voldg [-n new_name] [-h new_hostID] deport disk_group
ディスクを新しいホスト・システムに物理的に移動します。
新しいホスト・システムで次のコマンドを入力し,ディスクを走査します。
# hwmgr scan scsi
hwmgr
コマンドは走査が完了する前にプロンプトを表示します。
処理を続行する前に,新しいディスクの検出が完了したことを確認する必要があります。
たとえば,新しいディスクが表示されるまで,hwmgr show scsi
コマンドを何回か実行します。
新しく追加されたディスクを LSM に認識させます。
# voldctl enable
新しいホストにディスク・グループをインポートします。
ディスク・メディア名がオリジナルのディスク・アクセス名に対応していない
nopriv
ディスクがディスク・グループにある場合,強制 (-f) オプションを使用しなければならないことがあります。
ディスク・グループをスタンドアロン・システムからクラスタに移動するときには,-o shared オプションを指定します。
ディスク・グループをクラスタからスタンドアロン・システムに移動するときには,-o private オプションを指定します。
ディスク・グループが,システム上の別のディスク・グループと同じ名前の場合,インポートするときに名前を変更します。
# voldg [-f] [-o shared|private] [-n new_name] import \ disk_group
該当する場合は,nopriv
ディスクのディスク・メディア名を新しいディスク・アクセス名に対応付けます。
# voldg -g disk_group -k adddisk \ disk_media_name=disk_access_name...
インポートされたディスク・グループ内のすべての開始可能ボリュームを回復し開始します。 次のコマンドは,ボリュームを開始した後,回復に必要な操作をバックグラウンド・タスクとして実行します。
# volrecover -g disk_group -sb
必要に応じて,切り離されたプレックスがないかチェックします。
# volinfo -p
ボリュームが
Unstartable
としてリストに出力されていたら,対処方法について,6.5.2.2 項を参照してください。
必要であれば,残りの
Startable
ボリュームを開始します。
# volume -g disk_group start volume1 volume2...
7.3.3 nopriv ディスクを含むディスク・グループの別のシステムへの移動
LSM ディスクを別のシステムに移動するか,クラスタに追加する場合には,オペレーティング・システムによって,以前のデバイス名とは似ていない新しいデバイス名 (LUN) が割り当てられます。
LSM はディスク・アクセス名をデバイス名に基づいて割り当て,ディスク・アクセス名とディスク・メディア名の対応を維持します。
ディスク・メディア名は,big_disk
のように,任意に指定できます。
ディスク・グループを別のシステムに移動する場合には,ディスク・メディア名をスライス
・ディスクまたはシンプル
・ディスクの新しいデバイス名 (ディスク・アクセス名) に再マップするために,LSM によってこの対応 (構成データベースに格納済) が使用されますが,nopriv
ディスクに対しては使用されません。
複数の
nopriv
ディスクを含むディスク・グループを移動するには,時間のかかる注意深い処理が必要です。
この処理には,オリジナル・システムまたはオリジナル・クラスタに接続されている間にディスクを調査し,nopriv
ディスクを新しい環境で識別できるだけの情報を詳細に記録する作業が含まれます。
各
nopriv
ディスクについて,ディスク・アクセス名,ディスク・メディア名,およびディスク・グループ名を記録し,この情報を記入したラベルを (ステッカーや粘着テープなどで) ディスクに貼り付けます。
そして,ディスクを新しい環境に移動し,hwmgr flash light
などのコマンドを実行して,物理的にディスクを配置します。
新しいディスク・アクセス名を決めるときに,ディスク・グループをインポートしてから,古いディスク・メディア名を,nopriv
ディスクの新しいディスク・アクセス名に対応させることができます。
nopriv
ディスクは管理に手間がかかるため,そのディスクには LSM 制御下 (カプセル化による) のデータを配置するためだけに使用し,その後すぐにこれらのボリュームをスライス
・ディスクまたはシンプル
・ディスクに移動することをお勧めします。
作業を始める前に,オンライン・ヘルプを表示して,hwmgr flash
の構文を確認することができます。
# hwmgr -h flash light
Usage: hwmgr flash light [ -dsf <device-special-filename> ] [ -bus <scsi-bus> -target <scsi-target> -lun <scsi-lun> ] [ -seconds <number-of-seconds> ] (default is 30 seconds) [ -nopause ] (do not pause between flashes) The "flash light" operation works only on SCSI disks.
-seconds オプションを -nopause オプションと同時に指定して,指定した時間だけ,ディスクのライトを点灯したままにすることができます。 -nopause オプションを指定しないと,ライトは指定した時間点滅します。 システムがビジーの場合,点滅では,このコマンドによるものか,I/O 動作によるものか判別できない場合があります。
ディスク・グループに
nopriv
ディスクが 1 つしかない場合には,再度対応付けするデバイスは 1 つだけです。
同時に他のデバイスを新しいホストに接続しない限り,この情報は必要ありません。
nopriv
ディスクが複数存在する場合には,前もって正確な識別情報を取得しておくことが重要です。
複数の
nopriv
ディスクを含むディスク・グループを別のシステムまたはクラスタに移動するには,以下の手順を実行します。
元のホスト上で以下のコマンドを使用して,ディスク・グループ内のすべての
nopriv
ディスクについて,現在のディスク・アクセス名,ディスク・メディア名,および固有の識別子 (ディスクの SCSI ワールドワイド識別子など) を調べます。
この識別子は,変わることがなく,ディスクが別のシステムに接続されても追跡が可能です。
これらの情報を記入したリストを作成するか,またはこれらの情報を印刷可能なファイルに格納しておきます。
ディスク・グループ内のディスクを表示するには,以下のコマンドを入力します。
# voldisk -g disk_group list
DEVICE TYPE DISK GROUP STATUS dsk21 sliced dsk21 datadg online dsk22 sliced dsk22 datadg online dsk23c nopriv dsk23c-4.2BSD datadg online dsk24c nopriv dsk24c-database datadg online dsk26c nopriv dsk26c-AdvFS datadg online dsk27g nopriv dsk27g-raw datadg online
次のコマンドを入力して,ディスクのハードウェア ID (HWID) を見つけます。
# hwmgr show scsi
SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH -------------------------------------------------------------------------
.
.
.
88: 22 lsmtemp disk none 2 1 dsk21 [5/3/0] 89: 23 lsmtemp disk none 2 1 dsk22 [5/4/0] 90: 24 lsmtemp disk none 2 1 dsk23 [5/5/0] 91: 25 lsmtemp disk none 2 1 dsk24 [5/6/0] 92: 26 lsmtemp disk none 2 1 dsk25 [6/1/0] 93: 27 lsmtemp disk none 2 1 dsk26 [6/3/0] 94: 28 lsmtemp disk none 2 1 dsk27 [6/5/0]
各
nopriv
ディスクに対して HWID 値を使用して,ワールドワイド ID (WWID) を探します。
# hwmgr show scsi -full -id HWID
たとえば,次のコマンドを入力します。
# hwmgr show scsi -full -id 90
SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH ------------------------------------------------------------------------- 90: 24 lsmtemp disk none 2 1 dsk23 [5/5/0] WWID:04100024:"DEC RZ1CF-CF (C) DEC 50060037" BUS TARGET LUN PATH STATE ------------------------------ 5 5 0 valid
各
nopriv
ディスクに,ディスク・アクセス名,ディスク・メディア名,および WWID を記入したラベルを貼ります。
元のホストのディスク・グループをデポートします。
# voldg deport disk_group
ディスク・グループを新しい環境へ物理的に接続します。
各
nopriv
ディスクをシステム間で移動するとき,移動の前後のバス位置を記録します。
そうすれば,新しいホストでディスクを走査すると,新しいバス位置に対応する新しいディスク・アクセス名が,どのディスク・メディア名に属するかが分かります。
ディスクは個別に移動することができ,確認が必要になるたびに新しいホストで
hwmgr
コマンドを使用して走査することができます。
新しいシステムまたはクラスタで,以下のコマンドを入力し,新しく接続されたストレージのデバイス名の検出と割り当てを行います。
# hwmgr scan scsi
ディスク・グループを強制 (-f) オプションを指定してインポートします。
このオプションを指定すると,LSM は,nopriv
ディスクをインポートできなくても,強制的にディスク・グループをインポートするようになります。
# voldg -f [-o shared|private] import disk_group
ディスク・グループをスタンドアロン・システムからクラスタに移動する場合は,-o shared オプションを指定してクラスタで使用されることを示します。
ディスク・グループをクラスタからスタンドアロン・システムに移動する場合は,-o private オプションを指定してプライベートで使用されることを示します。
LSM レポートが見つからないディスクを書き留めます。
インポートされたディスク・グループのディスクのリストを表示します。
# voldisk -g disk_group list
出力には,スライス
・ディスクとシンプル
・ディスクだけが表示されます。
nopriv
ディスクはインポートされていません。
ディスク・アクセス名を,以下のコマンドの出力と比較します。
# hwmgr show scsi
ステップ 9 の出力には表示され,ステップ 8 では表示されない新しいデバイス名が,nopriv
ディスクの可能性があります。
各デバイスのデバイス特殊ファイル名は
DEVICE FILE
欄に表示されます。
この識別子は,ステップ 10 で使用します。
候補のデバイス名の各々に対し,以下のコマンドを実行します。
# hwmgr flash light -dsf device_special_filename \ -seconds duration -nopause
ライトが点灯したままのディスクを見つけます。
そのディスクが別のシステムから移動されたことを示すラベルの付けられた
nopriv
ディスクの 1 つだった場合,そのディスク・メディア名を記録し,新しいデバイス名と対応付けます。
たとえば,新しいデバイス名を,手順 1 のリストに表示されている古いディスク・メディア名の隣に記入します。
各
nopriv
ディスクをディスク・グループに追加します。
このとき,ディスク・メディア名に新しいデバイス (ディスク・アクセス) 名を関連付けます。
# voldg -g disk_group -k adddisk media_name=device_name
nopriv
ディスク上のボリュームを起動し,必要に応じて復旧します。
# voldg -g disk_group startall # volrecover -g disk_group -sb
7.4 ブート・ディスクのカプセル化の解除 (スタンドアロン・システムの場合)
スタンドアロン・システムのルート・ファイル・システム (/
,/usr
,および
/var
) とプライマリ・スワップ・パーティションをカプセル化したが,後に LSM ボリュームの使用を止め,元の物理ディスク・パーティションを再び使用することにしたときには,ブート・ディスクとプライマリ・スワップ領域のカプセル化を解除することで,これを行うことができます。
この処理には,システムの再起動が必要となります。
注意
クラスタ単位のルート,
/usr
,および/var
ファイル・システム・ドメインで LSM ボリュームの使用を止めるには,volunmigrate
コマンドを使用します。 詳細は,7.5 節とを参照してください。 volunmigrate
(8)
カプセル化解除処理は,次のファイルを変更します。
ルート・ファイル・システムが AdvFS の場合,/etc/fdmns/*
ディレクトリ内の,ブート・ディスクに関連するドメイン用のリンクが,LSM ボリュームではなく,ディスク・パーティションにリンクするように変更されます。
ルート・ファイル・システムが UFS の場合,/etc/fstab
ファイルは LSM ボリュームではなく,ディスク・パーティションを使用するように変更されます。
/etc/sysconfigtab
ファイルでは,swapdevice
エントリが LSM の
swapvol
ボリュームではなく元のスワップ・パーティションを使用するように変更され,lsm_rootdev_is_volume
エントリに 0 が設定されます。
システム・パーティションのカプセル化を解除するには,以下の手順を実行します。
システム・ボリューム (ルート,スワップ,/usr
および
/var
) がミラー化されている場合,以下の手順を実行します。
ミラー化されていない場合は,ステップ 2 に進んでください。
次のコマンドを実行して,ブート・ディスク・ボリュームの詳細情報を表示します。
# volprint -g rootdg -vht
V NAME USETYPE KSTATE STATE LENGTH READPOL PREFPLEX PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE v rootvol root ENABLED ACTIVE 524288 ROUND - pl rootvol-02 rootvol ENABLED ACTIVE 524288 CONCAT - RW sd root02-02p rootvol-02 root02 0 16 0 dsk16a ENA sd root02-02 rootvol-02 root02 16 524272 16 dsk16a ENA pl rootvol-01 rootvol ENABLED ACTIVE 524288 CONCAT - RW sd root01-01p rootvol-01 root01 0 16 0 dsk14a ENA sd root01-01 rootvol-01 root01 16 524272 16 dsk14a ENA v swapvol swap ENABLED ACTIVE 520192 ROUND - pl swapvol-02 swapvol ENABLED ACTIVE 520192 CONCAT - RW sd swap02-02 swapvol-02 swap02 0 520192 0 dsk16b ENA pl swapvol-01 swapvol ENABLED ACTIVE 520192 CONCAT - RW sd swap01-01 swapvol-01 swap01 0 520192 0 dsk14b ENA v vol-dsk14g fsgen ENABLED ACTIVE 2296428 SELECT - pl vol-dsk14g-02 vol-dsk14g ENABLED ACTIVE 2296428 CONCAT - RW sd dsk16g-01 vol-dsk14g-02 dsk16g-AdvFS 0 2296428 0 dsk16g ENA pl vol-dsk14g-01 vol-dsk14g ENABLED ACTIVE 2296428 CONCAT - RW sd dsk14g-01 vol-dsk14g-01 dsk14g-AdvFS 0 2296428 0 dsk14g ENA v vol-dsk14h fsgen ENABLED ACTIVE 765476 SELECT - pl vol-dsk14h-02 vol-dsk14h ENABLED ACTIVE 765476 CONCAT - RW sd dsk16h-01 vol-dsk14h-02 dsk16h-AdvFS 0 765476 0 dsk16h ENA pl vol-dsk14h-01 vol-dsk14h ENABLED ACTIVE 765476 CONCAT - RW sd dsk14h-01 vol-dsk14h-01 dsk14h-AdvFS 0 765476 0 dsk14h ENA
この出力を調べ,各プレックスが使用しているディスクに基づいて,削除するプレックスを決定します。
通常は,-01
サフィックスのついたプレックスがオリジナルのディスクまたはディスク・パーティションを使用しているプレックスであり,カプセル化を解除しようとしているプレックスです。
注意
前の例では,
rootvol
ボリュームには,root01-01p
とroot02-02p
のというサブディスクが含まれていました。 これらは,ファントム・サブディスクで,それぞれが 16 セクタ長です。 これらはブロック 0 に対する書き込み保護の役割を果たし,ブート・ブロックとディスク・ラベルが誤って破壊されるのを防いでいます。 これらのサブディスクは,ここでの手順の実行に伴い,削除されます。
ルート・ファイル・システムとプライマリ・スワップ領域で異なるディスクを使用していた場合は,カプセル化解除したいプレックスは異なるディスク上にある可能性があります。
たとえば,rootvol-01
プレックスが
dsk14
に存在し,swapvol-01
プレックスが
dsk16
に存在することがあります。
カプセル化の解除を行うディスクを使用しているプレックス以外のすべてのプレックスを削除します。 残るプレックスは,カプセル化の解除を行うディスクにあります。 これが,カプセル化の解除が完了した後に,システム・パーティションが使用するディスクです。
# volplex -o rm dis plex-nn
たとえば,ボリューム
rootvol
,swapvol
,および
vol-dsk0g
のセカンダリ・プレックスを削除するには,次のコマンドを入力します。
# volplex -o rm dis rootvol-02 # volplex -o rm dis swapvol-02 # volplex -o rm dis vol-dsk14g-02 # volplex -o rm dis vol-dsk14h-02
ブート・ディスク環境変数を変更して,物理ブート・ディスク (この例では,プレックス
rootvol-01
のディスク) を指すようにします。
# consvar -s bootdef_dev boot_disk
たとえば,次のように実行します。
# consvar -s bootdef_dev dsk14 set bootdef_dev = dsk14
ブート・ディスクのカプセル化を解除します。 ディスクが異なっている場合はプライマリ・スワップ・ディスク のカプセル化も解除します。
# volunroot -a -A
このコマンドはシステム・ディスクから LSM のプライベート・リージョンも削除します。 そして,システムを再起動するように求めてきます。
次のような情報が表示されたら,プロンプトに対して
now
と入力します。
This operation will convert the following file systems on the system/swap disk dsk14 from LSM volumes to regular disk partitions: Replace volume rootvol with dsk14a. Replace volume swapvol with dsk14b. Replace volume vol-dsk14g with dsk14g. Replace volume vol-dsk14h with dsk14h. Remove configuration database on dsk14f. This operation will require a system reboot. If you choose to continue with this operation, your system files will be updated to discontinue the use of the above listed LSM volumes. /sbin/volreconfig should be present in /etc/inittab to remove the named volumes during system reboot. Would you like to either quit and defer volunroot until later or commence system shutdown now? Enter either 'quit' or time to be used with the shutdown(8) command (e.g., quit, now, 1, 5): [quit] now
システムが再起動されたときには,ルート・ファイル・システムとプライマリ・スワップ領域は,オリジナルのカプセル化されていないディスクまたはディスク・パーティションを使用します。
システム・ボリュームがミラー化されていた場合,ミラー・プレックスで使用されていた LSM ディスクは,rootdg
ディスク・グループのメンバとして,LSM 制御下に残ります。
これらの LSM ディスクを LSM 内や他の目的で再使用するには,以下の手順を実行します。
rootdg
ディスク・グループ内の LSM ディスクを表示します。
# voldisk -g rootdg list
DEVICE TYPE DISK GROUP STATUS
.
.
.
dsk16a nopriv root02 rootdg online dsk16b nopriv swap02 rootdg online dsk16f simple dsk16f rootdg online dsk16g nopriv dsk16g-AdvFS rootdg online dsk16h nopriv dsk16h-AdvFS rootdg online
.
.
.
この例では,システム・ボリュームのミラー・プレックス用の LSM ディスクのディスク・メディア名は,root02
,swap02
,dsk16g-AdvFS
,および
dsk16h-AdvFS
です。
これらのすべての LSM ディスクは同じ物理ディスク
dsk16
上にあります。
dsk16
のプライベート・リージョンのディスク・メディア名は,dsk16f
です。
これらの LSM ディスクを,次のようにそのディスク・メディア名を使用して,rootdg
ディスク・グループから削除します。
# voldg rmdisk root02 swap02 dsk16g-AdvFS dsk16h-AdvFS dsk16f
次のように「DEVICE
」欄のディスク・アクセス名を使用して,LSM 制御下からこれのディスクを削除します。
# voldisk rm dsk16a dsk16b dsk16f dsk16g dsk16h
物理ディスク (この例の場合
dsk16
) は,LSM 制御下には置かれなくなり,ディスク・ラベルには,すべてのパーティションに unused と記されているはずです。
7.5 LSM ボリュームから物理ストレージへの AdvFS ドメインの移行
volunmigrate
コマンドを使用して,AdvFS ドメイン用の LSM ボリュームの使用を停止し,物理ディスクまたはディスク・パーティションを使用する状態に戻すことができます。
このコマンドは,スタンドアロン・システムとクラスタのどちらでも使用可能です。
ドメインはマウントされたままで,この処理中も使用できます。
リブートの必要はありません。
移行後に使用するドメイン用に,LSM 制御下にない複数のディスク・パーティション (可能ならば,共用バス上) を指定する必要があります。
これらのパーティションは,ドメインと,ファイル・システムのオーバヘッド用に少なくとも 10% を追加した領域を格納できるだけの十分な大きさでなければなりません。
volunmigrate
コマンドは,指定されたパーティションがこれらの要件を満たしているか調べます。
満たされていない要件がある場合には,エラーが返されます。
詳細は,
volunmigrate
(8)
AdvFS ドメインを LSM ボリュームから物理ストレージに移行するには,以下の手順を実行します。
ドメイン・ボリュームのサイズを表示します。
# volprint -vt domain_vol
ドメインと,ファイル・システムの少なくとも 10% のオーバヘッドを格納するのに十分な大きさを持つ,LSM 制御下にない共用バス上のディスク・パーティションを 1 つ以上探し出します。
# hwmgr view devices -cluster
ターゲット・ディスク・パーティションを指定して,ドメインを移行します。
# volunmigrate domain_name dsknp [dsknp...]
移行後,ドメインは指定したディスクを使用します。
LSM ボリュームは存在しなくなります。
7.6 クラスタ・メンバのスワップ・デバイスのカプセル化の解除
クラスタ・メンバのスワップ・デバイスを LSM ボリュームから削除し,物理ディスク・パーティションを使用する状態に戻すことができます。 この処理はカプセル化の解除と呼ばれ,メンバをリブートする必要があります。
スワップ・デバイスを最初からカプセル化していた場合には,LSM は 2 つの独立した LSM ディスクを作成しています。
スワップ・パーティション自体の
nopriv
ディスクと,ディスクの別のパーティション上の LSM プライベート・データ用のシンプル
・ディスクです。
カプセル化解除処理では,nopriv
ディスクだけを削除します。
メンバのスワップ・デバイスのカプセル化を解除するには,以下の手順を実行します。
rootdg
ディスク・グループ内の LSM ボリュームの名前を表示します (すべてのスワップ・ボリュームは,rootdg
に属する必要があります)。
# volprint -g rootdg -vht
TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0 v hughie-swap01 swap ENABLED 16777216 - ACTIVE - - pl hughie-swap01-01 hughie-swap01 ENABLED 16777216 - ACTIVE - - sd dsk4b-01 hughie-swap01-01 ENABLED 16777216 0 - - -
この出力の中で,次のものを探します。
nodename-swapnn
の形式の,メンバのスワップ・ボリュームの名前。
たとえば,hughie-swap01
です。
dsknp
の形式の,スワップ・ボリュームで使用されているディスク・パーティション (サブディスク)。
たとえば,dsk4b
です。
メンバの
/cluster/members/member{n}/boot_partition/etc/sysconfigtab
ファイルを編集して
swapdevice=
行から
/dev/vol/rootdg/nodename-swapnn
エントリを削除します。
メンバをリブートします。
# shutdown -r now
メンバが再起動されると,LSM スワップ・ボリュームは不要になります。
同じメンバにログインし直します。
スワップ・ボリュームを削除します。
# voledit -rf rm nodename-swapnn
カプセル化されたスワップ・デバイスに関連付けられた LSM
シンプル
・ディスクを探します。
たとえば,次のコマンドを実行します。
# voldisk -g rootdg list | grep dsk4 dsk4b nopriv dsk4b rootdg online dsk4f simple dsk4f rootdg online
rootdg
ディスク・グループと LSM の制御から,LSM
シンプル
・ディスクと
nopriv
ディスクを削除します。
たとえば,次のコマンドを実行します。
# voldg -g rootdg rmdisk dsk4b dsk4f # voldisk rm dsk4b dsk4f
オリジナルのディスク・パーティション (以前の
nopriv
ディスク) でスワップを行うように,クラスタ・メンバを設定します。
たとえば,次のコマンドを実行します。
# swapon /dev/disk/dsk4b
/etc/sysconfigtab
ファイルを次のように編集します。
swapdevice=
行に
/dev/disk/dsknp
エントリを追加して,次のようにします。
swapdevice=/dev/disk/dsknp
この行は,たとえば次のようになります。
swapdevice=/dev/disk/dsk4b
このメンバ用の最後の LSM スワップ・デバイスを削除した場合は,lsm_root_dev_is_volume=
の値に 0 を設定します。
クラスタ・メンバは指定されたディスク・パーティションをスワップ・デバイスとして使用し,LSM スワップ・ボリュームはなくなります。
7.7 LSM ソフトウェアのアンインストール
この節では,LSM ソフトウェアをスタンドアロン・システムまたはクラスタから完全に削除する方法について説明します。 この処理には,次の項目が含まれます。
ユーザ・データのバックアップ
ディスクやデータのカプセル化解除
LSM オブジェクトおよびソフトウェア・サブセットの削除
カーネルの再構成とシステムまたはクラスタ・メンバの再起動
注意
LSM をアンインストールすると,LSM ボリューム内の現在のデータがすべて失われます。 必要なデータをバックアップしてから,先に進む必要があります。
LSM ソフトウェアをアンインストールするには,以下の手順を実行します。
システム固有のファイル・システムとスワップ領域を再構成して,LSM ボリュームを使用しないようにします。
スタンドアロン・システムでは,ルート・ファイル・システムとプライマリ・スワップ・パーティションのカプセル化を解除します (7.4 節)。
追加の (セカンダリ) スワップ領域が LSM ボリュームを使用している場合は,これらのボリュームも削除します (5.4.6 項)。
クラスタでは,cluster_root
,cluster_usr
,および
cluster_var
を含め,LSM ボリュームを使用しているすべての AdvFS ドメインを,LSM ボリュームからディスク・パーティションに移行します (7.5 節)。
すべてのクラスタ・メンバのスワップ・デバイスのカプセル化を解除します (7.6 節)。
LSM ボリュームを使用しているその他のすべてのファイル・システムをアンマウントし,すべての LSM ボリュームをクローズできるようにします。
必要であれば
/etc/fstab
ファイルをアップデートして,LSM ボリューム上のファイル・システムをマウントしないようにします。
raw LSM ボリュームを使用しているアプリケーションを停止し,これらのアプリケーションが LSM ボリュームを使用しないように再構成します。
LSM 下に現在構成されているディスクを見つけます。
# voldisk list
LSM を使用不能モードで再起動します (クラスタの場合は,1 つのメンバでのみ)。
# vold -k -r reset -d
オープンされているボリュームがあると,このコマンドは失敗します。
すべての LSM ボリュームと入出力デーモンを停止させます (クラスタの場合,すべてのメンバで)。
# voliod -f set 0 # voldctl stop
LSM 制御下のディスク (ステップ 3 の出力を参照) のディスク・ラベルをアップデートします。
各 LSM
スライス
・ディスクに対して,省略時のディスク・ラベルをディスク全体に適用します。
# disklabel -rw dskn
各 LSM
シンプル
・ディスクに対して,パーティションの
fstype
フィールドを unused に変更します。
# disklabel -s dsknP unused
各 LSM
nopriv
ディスクに対して,有効なデータがパーティションにまだ含まれているかどうかによって,パーティションの
fstype
フィールドを unused または適切な値に変更します。
たとえば,次のようにします。
有効なデータを含まないパーティション
dsk2h
の
fstype
フィールドを変更するには,次のコマンドを入力します。
# disklabel -s dsk2h unused
有効な UFS ファイル・システムを含むパーティション
dsk2g
の
fstype
フィールドを変更するには,次のコマンドを入力します。
# disklabel -s dsk2g 4.2BSD
LSM ディレクトリを削除します。
# rm -r /etc/vol /dev/vol /dev/rvol /etc/vol/volboot
/etc/inittab
ファイル内の,次の LSM エントリを削除します (クラスタの場合,すべてのメンバで)。
lsmr:s:sysinit:/sbin/lsmbstartup -b </dev/console >/dev/console 2>&1 ##LSM lsm:23:wait:/sbin/lsmbstartup </dev/console >/dev/console 2>&1 ##LSM vol:23:wait:/sbin/vol-reconfig -n </dev/console >/dev/console 2>&1 ##LSM
インストール済みの LSM サブセットを表示します。
# setld -i | grep LSM
インストール済みの LSM サブセットを削除します。
# setld -d OSFLSMBASEnnn OSFLSMBINnnn OSFLSMCLSMTOOLSnnn
/sys/conf/hostname
ファイル内の
pseudo-device lsm
エントリの値を,1 から 0 に変更します (クラスタの場合,すべてのメンバで)。
クラスタの場合,hostname はメンバ名であり,クラスタ別名ではありません。
この変更は,doconfig
コマンドを実行する前に行うことも,実行中に行うこともできます。
たとえば,次のコマンドを実行します。
# doconfig -c hostname
次のコマンドを入力して,新しいカーネルをルート (/
) ディレクトリにコピーします (クラスタの場合,すべてのメンバ)。
# cp /sys/hostname/vmunix /
システムまたはクラスタ・メンバを再起動します。
各メンバを適切に再起動する方法は,『クラスタ管理ガイド』を参照してください。
システムが再起動した後,またはすべてのクラスタ・メンバが再起動した後は,LSM がインストールされていない状態になります。