7    特殊な操作

この章では,以下の操作について説明します。

7.1    LSM 構成のアップグレード

現在 Tru64 UNIX Version 4.0 が稼働しているシステムで LSM を使用していて,Tru64 UNIX Version 5.0 以降でも現在の LSM 構成を使用したい場合には,以下の操作を行う必要があります。

  1. ブロック変更ログ (BCL) のサイズを増やします。 スタンドアロン・システムの場合は,ボリューム・サイズ 1 GB に対して少なくとも 2 ブロック,TruCluster Server 環境の場合は,ボリューム・サイズ 1 GB に対して少なくとも 65 ブロック,大きくします (7.1.1 項)。

  2. 現在の LSM 構成をバックアップします (7.1.2 項)。

  3. 必要であれば,アップグレードしたくないディスク・グループをデポートします (7.1.3 項)。

  4. LSM ソフトウェアをアップグレードします (7.1.4 項)。

  5. アップグレードを行う前にデポートしたすべての Version 4.0 ディスク・グループを手作業で変換します (7.1.5 項)。

  6. 復元した LSM 構成データベースを最適化します (7.1.6 項)。

7.1.1    BCL のサイズの拡大

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 の構成をバックアップするには,次の手順に従います。

  1. 次のコマンドを入力します。

    # 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 構成を復元するために必要となります。

  2. 必要な場合,LSM 構成が保存されたことを確認します。

    # ls /usr/var/lsm/db/LSM.date.hostname
    dg1.d         newdg.d       volboot
    header        rootdg.d      voldisk.list
    

  3. LSM 構成をテープまたは他のリムーバブル・メディアに保存します。

7.1.3    ディスク・グループのデポート (オプション)

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 に入っています。

アップグレードの前後のオペレーティング・システムのバージョンによっては,アップデート・インストールではなく,フル・インストールが必要な場合や,一連のアップデート・インストール手順が必要になる場合があります。 サポートされているアップデート・パスについては,『インストレーション・ガイド』を参照してください。

アップデート・インストレーション,またはフル・インストレーションが完了すれば,rootdg ディスクは変換され,使用可能な状態になります。 システムに接続されたままでデポートされなかったディスク・グループも変換され使用できる状態になります。

7.1.5    Version 4.0 ディスク・グループの手作業での変換

システムまたはクラスタを Version 4.0 から Version 5.0 以降へアップグレードする前にディスク・グループをデポートした場合には,このディスク・グループを手作業でインポートし,変換することができます。

システムを再起動する前,またはクラスタを作成する前にシステムに接続されていたディスク・グループは,自動的にインポートされます。 ディスク・グループのメタデータ・フォーマットはアップデートされます。 BCL は,vollogcnvt ユーティリティによって,可能な限り DRL に変換されます (詳細は, vollogcnvt(8) を参照してください)。

以下に説明する手順は,オペレーティング・システムをアップグレードする前にデポートし,インポートと変換を行うことに決めていたディスク・グループに対してのみ,適用できます。

この手順では次のことが行われます。

ディスク・グループを手動でインポートして変換するには,以下の手順を実行します。

  1. ストレージをシステムまたはクラスタに物理的に接続します。

    クラスタの場合,すべてのクラスタ・メンバからアクセスできるようにストレージを接続します。

  2. hwmgr コマンドを実行して,システムまたはクラスタを新しいディスク情報でアップデートします。 詳細は, hwmgr(8) を参照してください。

  3. ディスク・グループをインポートし,変換します。

    # 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.
     
    

  4. 各ディスク・グループの BCL を DRL に変換します。

    # vollogcnvt -g disk_group
    

  5. DRL に変換できなかった BCL があり,そのボリュームのロギングを復元したい場合は,次の手順に従います。

    1. 使用不能になっている BCL サブディスクを見つけます。

      # volprint [-g disk_group] volume
      

    2. BCL サブディスクを削除します。

      # volsd [-g disk_group] -o rm dis subdisk
      

    3. ボリュームに新しいログを追加します。

      # volassist [-g disk_group] addlog volume
      

  6. 新しくインポートした各ディスク・グループでボリュームを起動します。

    # 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 ディスク上のプライベート・リージョンに,構成データベースのコピーを 1 つ持たせるように構成します。

構成データベースを使用可能にしても,ディスク上で使用するスペースは増えません。 使用可能にすると,プライベート・リージョン内の使用可能コピー数に 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 を使用しているスタンドアロン・システムを LSM を実行していないクラスタに追加するには,以下の手順を実行します。

  1. 該当する場合,すべてのミラー・ボリュームで省略時の DRL サイズを使用するように,ログ・サブディスクを再構成します。

    1. 省略時のサイズではないログ・プレックスを使用しているミラー・ボリュームを探します。

      #  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
       
      

    2. ボリュームから省略時のサイズではない DRL プレックスを削除します。

      # volplex [-g disk_group] -o rm dis log_plex
      

      たとえば,次のように入力します。

      # volplex -o rm dis vol1-03
      

    3. 新しい DRL プレックスをボリュームに追加します。 このプレックスは,自動的に正しいサイズになります。

      # volassist addlog volume
      

      たとえば,次のように入力します。

      # volassist addlog vol1
      

  2. 各ディスク・グループ内のすべてのボリュームを停止します。

    # volume -g disk_group stopall
    

  3. rootdg 以外の各ディスク・グループをデポートします。

    # voldg deport disk_group
    

  4. rootdgディスク・グループ ID を表示します。

    # voldg list rootdg | grep id
    dgid:      1007697459.1026.hostname
    

  5. ディスク・グループ ID を記録しておいてください。 この情報は,rootdg ディスク・グループをクラスタにインポートするとき必要になります。

  6. システムを停止し,クラスタに追加します。 そのシステムのすべてのストレージがクラスタに接続されたことを確認してください (できれば,共用ストレージにします)。

    この手順では,clu_add_member コマンドを使用します。 また,ハードウェアやクラスタに固有の操作が必要になる可能性があります。 ただし,ここでは説明しません。

  7. hwmgr コマンドを実行し,クラスタを新しいディスク情報でアップデートします。 詳細は, hwmgr(8) を参照してください。

  8. 次のいずれかの方法で,LSM を初期化します。

  9. 手順 8 を実行したメンバ以外のメンバで次のコマンドを入力して,クラスタ全体で LSM を同期化します。

    # volsetup -s
    

7.3    システム間でのディスク・グループの移動

LSM ディスク・グループは,スタンドアロン・システム間,クラスタ間,スタンドアロン・システムからクラスタへ,およびクラスタからスタンドアロン・システムへ移動できます。 このとき,以下の条件のいずれかが満たされていると,これらのディスク上の LSM オブジェクトとデータが保持されます。

システム間でディスク・グループを移動すると,新しいホスト・システムではディスクに新しいディスク・アクセス名を割り当てます。 LSM nopriv ディスク (ディスクやパーティションをカプセル化したときに作成される) の場合,オリジナルのディスク・アクセス名とそのディスク・メディア名の対応が失われたり,誤った名前に付け替えられることがあります。 このような状況を防ぐには,ディスク・メディア名と新しいディスク・アクセス名を手作業で対応付けなければなりません。 LSM スライス・ディスクおよびシンプル・ディスクの場合は,LSM がこの名前の対応付けを管理します。

可能であればディスク・グループを移動する前に,プライベート・リージョンがあり,名前の対応付けが自動的に行われるスライス・ディスクまたはシンプル・ディスクへ,nopriv ディスクのデータを移行してください。 別のディスクへのデータの移動についての詳細は,5.1.5 項を参照してください。

データをスライス・ディスクやシンプル・ディスクに移動できない場合は,7.3.3 項を参照してください。

ディスク・グループを新しいホストに移動する際には,ディスク・グループの名前やホスト ID を変更できます。 たとえば,ディスク・グループの名前が新しいホストのディスク・グループの名前と類似している場合は,混同を避けるために名前を変更します。 ディスク・グループの名前が新しいホストのディスク・グループと同じ場合は,名前を変更しなければなりません。

ディスク・グループのホスト ID は,オリジナル・システムからデポートするときに,移動先のシステムのホスト ID に変更することができます。 これにより,ディスク・グループを受け取るシステムが,起動時にそのディスク・グループを自動的にインポートすることが可能になります。 新しいホストがすでに実行中の場合,そのホストにディスク・グループをインポートしたときに,ディスク・グループのホスト ID が変更されます。

7.3.1    別のシステムへの rootdg ディスク・グループの移動

rootdg ディスク・グループを 1 つのスタンドアロン・システムから別のシステムへ移動することができますが,次の制限があります。

  1. システムのルート・ディスクとスワップ領域が LSM ボリュームにカプセル化されている場合には,それらを LSM の制御から削除してください。 ルート・ファイル・システムは,別のシステムで再利用することはできません。

    システム・ボリュームの削除については,7.4 節を参照してください。

  2. 他のシステム固有のファイル・システムで LSM ボリュームを使用している場合にも,LSM の制御から削除してください。

    1 つのシステムでファイル・システムが重複するのは許されていません。 システム間で移動できるのは,システムの動作上重要ではないか,ターゲット・システムに存在しないファイル・システムとアプリケーションだけです。

    AdvFS ドメインまたは UFS ファイル・システムのカプセル化を解除する方法については,5.4.6.1 項を参照してください。

  3. rootdg に内部システム・ディスクが含まれる場合は,これらのディスクを rootdg から削除します (必要に応じて,LSM の制御からも削除します)。

  4. rootdg はデポートできません。 移動するには,システムをシャットダウンするか,システム上の LSM を停止する必要があります。 これにより,すべてのボリュームが停止し (これらのボリュームを使用するすべてのファイル・システムとアプリケーションからのアクセスも停止します),LSM デーモンも停止します。 rootdg ディスク・グループをシステムから削除すると,新しい rootdg を作成しない限り,システムでは LSM が実行できなくなります。

  5. システムで再び 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
     
    

  6. 必要に応じて,ディレクトリ /dev/vol/ および /etc/vol/ を再帰的に削除します。

7.3.2    別のシステムへのディスク・グループの移動

rootdg 以外のディスク・グループを別のシステムに移動するには,次の手順に従います。

  1. ディスク・グループ内のボリュームに対するすべての動作を停止し,すべてのファイル・システムをアンマウントします。

  2. 元のシステムからディスク・グループをデポートします。

  3. ディスクを新しいホスト・システムに物理的に移動します。

  4. 新しいホスト・システムで次のコマンドを入力し,ディスクを走査します。

    # hwmgr scan scsi
    

    hwmgr コマンドは走査が完了する前にプロンプトを表示します。 処理を続行する前に,新しいディスクの検出が完了したことを確認する必要があります。 たとえば,新しいディスクが表示されるまで,hwmgr show scsi コマンドを何回か実行します。

  5. 新しく追加されたディスクを LSM に認識させます。

    # voldctl enable
    

  6. 新しいホストにディスク・グループをインポートします。

    # voldg [-f] [-o shared|private] [-n new_name] import \
    disk_group
    

  7. 該当する場合は,nopriv ディスクのディスク・メディア名を新しいディスク・アクセス名に対応付けます。

    # voldg -g disk_group -k adddisk \
    disk_media_name=disk_access_name...
    

  8. インポートされたディスク・グループ内のすべての開始可能ボリュームを回復し開始します。 次のコマンドは,ボリュームを開始した後,回復に必要な操作をバックグラウンド・タスクとして実行します。

    # volrecover -g disk_group -sb
    

  9. 必要に応じて,切り離されたプレックスがないかチェックします。

    # volinfo -p
    

    ボリュームが Unstartable としてリストに出力されていたら,対処方法について,6.5.2.2 項を参照してください。

  10. 必要であれば,残りの 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 ディスクを含むディスク・グループを別のシステムまたはクラスタに移動するには,以下の手順を実行します。

  1. 元のホスト上で以下のコマンドを使用して,ディスク・グループ内のすべての nopriv ディスクについて,現在のディスク・アクセス名,ディスク・メディア名,および固有の識別子 (ディスクの SCSI ワールドワイド識別子など) を調べます。 この識別子は,変わることがなく,ディスクが別のシステムに接続されても追跡が可能です。 これらの情報を記入したリストを作成するか,またはこれらの情報を印刷可能なファイルに格納しておきます。

    1. ディスク・グループ内のディスクを表示するには,以下のコマンドを入力します。

      # 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
      

    2. 次のコマンドを入力して,ディスクのハードウェア 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]

    3. 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
      

  2. nopriv ディスクに,ディスク・アクセス名,ディスク・メディア名,および WWID を記入したラベルを貼ります。

  3. 元のホストのディスク・グループをデポートします。

    # voldg deport disk_group 
     
    

  4. ディスク・グループを新しい環境へ物理的に接続します。

    nopriv ディスクをシステム間で移動するとき,移動の前後のバス位置を記録します。 そうすれば,新しいホストでディスクを走査すると,新しいバス位置に対応する新しいディスク・アクセス名が,どのディスク・メディア名に属するかが分かります。 ディスクは個別に移動することができ,確認が必要になるたびに新しいホストで hwmgr コマンドを使用して走査することができます。

  5. 新しいシステムまたはクラスタで,以下のコマンドを入力し,新しく接続されたストレージのデバイス名の検出と割り当てを行います。

    # hwmgr scan scsi
    

  6. ディスク・グループを強制 (-f) オプションを指定してインポートします。 このオプションを指定すると,LSM は,nopriv ディスクをインポートできなくても,強制的にディスク・グループをインポートするようになります。

    # voldg -f [-o shared|private] import disk_group
    

  7. LSM レポートが見つからないディスクを書き留めます。

  8. インポートされたディスク・グループのディスクのリストを表示します。

    # voldisk -g disk_group list
    

    出力には,スライス・ディスクとシンプル・ディスクだけが表示されます。 nopriv ディスクはインポートされていません。

  9. ディスク・アクセス名を,以下のコマンドの出力と比較します。

    # hwmgr show scsi
    

    ステップ 9 の出力には表示され,ステップ 8 では表示されない新しいデバイス名が,nopriv ディスクの可能性があります。

    各デバイスのデバイス特殊ファイル名は DEVICE FILE 欄に表示されます。 この識別子は,ステップ 10 で使用します。

  10. 候補のデバイス名の各々に対し,以下のコマンドを実行します。

    # hwmgr flash light -dsf device_special_filename \
    -seconds duration -nopause
    

  11. ライトが点灯したままのディスクを見つけます。

    そのディスクが別のシステムから移動されたことを示すラベルの付けられた nopriv ディスクの 1 つだった場合,そのディスク・メディア名を記録し,新しいデバイス名と対応付けます。 たとえば,新しいデバイス名を,手順 1 のリストに表示されている古いディスク・メディア名の隣に記入します。

  12. nopriv ディスクをディスク・グループに追加します。 このとき,ディスク・メディア名に新しいデバイス (ディスク・アクセス) 名を関連付けます。

    # voldg -g disk_group -k adddisk media_name=device_name
    

  13. nopriv ディスク上のボリュームを起動し,必要に応じて復旧します。

    # voldg -g disk_group startall
    # volrecover -g disk_group -sb
    

7.4    ブート・ディスクのカプセル化の解除 (スタンドアロン・システムの場合)

スタンドアロン・システムのルート・ファイル・システム (//usr,および /var) とプライマリ・スワップ・パーティションをカプセル化したが,後に LSM ボリュームの使用を止め,元の物理ディスク・パーティションを再び使用することにしたときには,ブート・ディスクとプライマリ・スワップ領域のカプセル化を解除することで,これを行うことができます。 この処理には,システムの再起動が必要となります。

注意

クラスタ単位のルート,/usr,および /var ファイル・システム・ドメインで LSM ボリュームの使用を止めるには,volunmigrate コマンドを使用します。 詳細は,7.5 節volunmigrate(8) を参照してください。

カプセル化解除処理は,次のファイルを変更します。

システム・パーティションのカプセル化を解除するには,以下の手順を実行します。

  1. システム・ボリューム (ルート,スワップ,/usr および /var) がミラー化されている場合,以下の手順を実行します。 ミラー化されていない場合は,ステップ 2 に進んでください。

    1. 次のコマンドを実行して,ブート・ディスク・ボリュームの詳細情報を表示します。

      # 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-01proot02-02p のというサブディスクが含まれていました。 これらは,ファントム・サブディスクで,それぞれが 16 セクタ長です。 これらはブロック 0 に対する書き込み保護の役割を果たし,ブート・ブロックとディスク・ラベルが誤って破壊されるのを防いでいます。 これらのサブディスクは,ここでの手順の実行に伴い,削除されます。

      ルート・ファイル・システムとプライマリ・スワップ領域で異なるディスクを使用していた場合は,カプセル化解除したいプレックスは異なるディスク上にある可能性があります。 たとえば,rootvol-01 プレックスが dsk14 に存在し,swapvol-01 プレックスが dsk16 に存在することがあります。

    2. カプセル化の解除を行うディスクを使用しているプレックス以外のすべてのプレックスを削除します。 残るプレックスは,カプセル化の解除を行うディスクにあります。 これが,カプセル化の解除が完了した後に,システム・パーティションが使用するディスクです。

      # volplex -o rm dis plex-nn
      

      たとえば,ボリューム rootvolswapvol,および 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
      

  2. ブート・ディスク環境変数を変更して,物理ブート・ディスク (この例では,プレックス rootvol-01 のディスク) を指すようにします。

    # consvar -s bootdef_dev boot_disk
    

    たとえば,次のように実行します。

    # consvar -s bootdef_dev dsk14
    set bootdef_dev = dsk14
    

  3. ブート・ディスクのカプセル化を解除します。 ディスクが異なっている場合はプライマリ・スワップ・ディスク のカプセル化も解除します。

    # 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 内や他の目的で再使用するには,以下の手順を実行します。

  1. 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 ディスクのディスク・メディア名は,root02swap02dsk16g-AdvFS,および dsk16h-AdvFS です。 これらのすべての LSM ディスクは同じ物理ディスク dsk16 上にあります。 dsk16 のプライベート・リージョンのディスク・メディア名は,dsk16f です。

  2. これらの LSM ディスクを,次のようにそのディスク・メディア名を使用して,rootdg ディスク・グループから削除します。

    # voldg rmdisk root02 swap02 dsk16g-AdvFS dsk16h-AdvFS dsk16f
    

  3. 次のように「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 ボリュームから物理ストレージに移行するには,以下の手順を実行します。

  1. ドメイン・ボリュームのサイズを表示します。

    # volprint -vt domain_vol
    

  2. ドメインと,ファイル・システムの少なくとも 10% のオーバヘッドを格納するのに十分な大きさを持つ,LSM 制御下にない共用バス上のディスク・パーティションを 1 つ以上探し出します。

    # hwmgr view devices -cluster
    

  3. ターゲット・ディスク・パーティションを指定して,ドメインを移行します。

    # volunmigrate domain_name dsknp [dsknp...]
    

移行後,ドメインは指定したディスクを使用します。 LSM ボリュームは存在しなくなります。

7.6    クラスタ・メンバのスワップ・デバイスのカプセル化の解除

クラスタ・メンバのスワップ・デバイスを LSM ボリュームから削除し,物理ディスク・パーティションを使用する状態に戻すことができます。 この処理はカプセル化の解除と呼ばれ,メンバをリブートする必要があります。

スワップ・デバイスを最初からカプセル化していた場合には,LSM は 2 つの独立した LSM ディスクを作成しています。 スワップ・パーティション自体の nopriv ディスクと,ディスクの別のパーティション上の LSM プライベート・データ用のシンプル・ディスクです。 カプセル化解除処理では,nopriv ディスクだけを削除します。

メンバのスワップ・デバイスのカプセル化を解除するには,以下の手順を実行します。

  1. 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       -       -       -
     
    

    この出力の中で,次のものを探します。

  2. メンバの /cluster/members/member{n}/boot_partition/etc/sysconfigtab ファイルを編集して swapdevice= 行から /dev/vol/rootdg/nodename-swapnn エントリを削除します。

  3. メンバをリブートします。

    # shutdown -r now
    

    メンバが再起動されると,LSM スワップ・ボリュームは不要になります。

  4. 同じメンバにログインし直します。

  5. スワップ・ボリュームを削除します。

    # voledit -rf rm nodename-swapnn
    

  6. カプセル化されたスワップ・デバイスに関連付けられた LSM シンプル・ディスクを探します。 たとえば,次のコマンドを実行します。

    # voldisk -g rootdg list | grep dsk4
    dsk4b        nopriv    dsk4b        rootdg       online
    dsk4f        simple    dsk4f        rootdg       online
    

  7. rootdg ディスク・グループと LSM の制御から,LSM シンプル・ディスクと nopriv ディスクを削除します。 たとえば,次のコマンドを実行します。

    # voldg -g rootdg rmdisk dsk4b dsk4f
    # voldisk rm dsk4b dsk4f
    

  8. オリジナルのディスク・パーティション (以前の nopriv ディスク) でスワップを行うように,クラスタ・メンバを設定します。 たとえば,次のコマンドを実行します。

    # swapon /dev/disk/dsk4b
    

  9. /etc/sysconfigtab ファイルを次のように編集します。

クラスタ・メンバは指定されたディスク・パーティションをスワップ・デバイスとして使用し,LSM スワップ・ボリュームはなくなります。

7.7    LSM ソフトウェアのアンインストール

この節では,LSM ソフトウェアをスタンドアロン・システムまたはクラスタから完全に削除する方法について説明します。 この処理には,次の項目が含まれます。

注意

LSM をアンインストールすると,LSM ボリューム内の現在のデータがすべて失われます。 必要なデータをバックアップしてから,先に進む必要があります。

LSM ソフトウェアをアンインストールするには,以下の手順を実行します。

  1. システム固有のファイル・システムとスワップ領域を再構成して,LSM ボリュームを使用しないようにします。

  2. LSM ボリュームを使用しているその他のすべてのファイル・システムをアンマウントし,すべての LSM ボリュームをクローズできるようにします。

    1. 必要であれば /etc/fstab ファイルをアップデートして,LSM ボリューム上のファイル・システムをマウントしないようにします。

    2. raw LSM ボリュームを使用しているアプリケーションを停止し,これらのアプリケーションが LSM ボリュームを使用しないように再構成します。

  3. LSM 下に現在構成されているディスクを見つけます。

    # voldisk list
    

  4. LSM を使用不能モードで再起動します (クラスタの場合は,1 つのメンバでのみ)。

    # vold -k -r reset -d 
    

    オープンされているボリュームがあると,このコマンドは失敗します。

  5. すべての LSM ボリュームと入出力デーモンを停止させます (クラスタの場合,すべてのメンバで)。

    # voliod -f set 0
    # voldctl stop
    

  6. LSM 制御下のディスク (ステップ 3 の出力を参照) のディスク・ラベルをアップデートします。

  7. LSM ディレクトリを削除します。

    # rm -r /etc/vol /dev/vol /dev/rvol /etc/vol/volboot
    

  8. /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
     
    

  9. インストール済みの LSM サブセットを表示します。

    # setld -i | grep LSM
    

  10. インストール済みの LSM サブセットを削除します。

    # setld -d OSFLSMBASEnnn OSFLSMBINnnn OSFLSMCLSMTOOLSnnn
    

  11. /sys/conf/hostname ファイル内の pseudo-device lsm エントリの値を,1 から 0 に変更します (クラスタの場合,すべてのメンバで)。

    クラスタの場合,hostname はメンバ名であり,クラスタ別名ではありません。

    この変更は,doconfig コマンドを実行する前に行うことも,実行中に行うこともできます。 たとえば,次のコマンドを実行します。

    # doconfig -c hostname
    

  12. 次のコマンドを入力して,新しいカーネルをルート (/) ディレクトリにコピーします (クラスタの場合,すべてのメンバ)。

    # cp /sys/hostname/vmunix /
    

  13. システムまたはクラスタ・メンバを再起動します。

    各メンバを適切に再起動する方法は,『クラスタ管理ガイド』を参照してください。

    システムが再起動した後,またはすべてのクラスタ・メンバが再起動した後は,LSM がインストールされていない状態になります。