7    ローリング・アップグレード

ローリング・アップグレードは,クラスタの稼働中にソフトウェアをアップグレードする方法です。クラスタ・メンバを一度に 1 つずつアップグレードして運用に戻し,複数のバージョンのベース・オペレーティング・システム,クラスタ,および各国語サポート (WLS) ソフトウェアが混在する環境を透過的に管理します。サービスにアクセスするクライアントからは,ローリング・アップグレードが進行中であることがわかりません。

ローリング・アップグレードでは,一連の手順を順序に沿って実行します。 この手順を段階といいます。ローリング・アップグレードを制御するコマンドはこの順序で実行する必要があります。

この章の前半では,ローリング・アップグレードの実行,ローリング・アップグレードのステータス表示,およびローリング・アップグレードにおける段階の取り消し (複数段階可) について説明します。ローリング・アップグレードがどのように働くかについては,7.6 節およびそれに続く節で説明します。

この章で説明する内容は次のとおりです。

図 7-1 は,バージョン 5.1B クラスタで開始するローリング・アップグレードの実行に必要な作業と段階を簡単なフロー・チャートにまとめたものです。

図 7-1:  ローリング・アップグレード作業の流れ

7.1    ローリング・アップグレードでサポートされている作業

ローリング・アップグレードで行うことができる作業は,クラスタで現在実行しているベース・オペレーティング・システムとクラスタ・ソフトウェアのバージョンによって異なります。この章では主に,TruCluster Server バージョン 5.1B クラスタで開始するローリング・アップグレードについて説明します。ただし,TruCluster Server バージョン 5.1A からバージョン 5.1B へローリング・アップグレードする準備をされている方のために,2 つのバージョンの間にあるローリング・アップグレードの違いについても示していきます。

ローリング・アップグレードで行うことができる基本的な作業は,次のとおりです。

パッチ・キットまたは NHD キットによるローリングでは,ベース・オペレーティング・システムおよびクラスタ・ソフトウェアの新リリースによるローリングと同じ手順を使用します。違いは,インストール段階で実行するコマンドです。

この章では,ローリング・アップグレードという用語を,ソフトウェア・キットのロール手順全体を表す用語として使用しています。

図 7-1 に示すように,1 回のローリング・アップグレードで複数の作業を行うことができます。

クラスタでバージョン 5.1A またはバージョン 5.1B が動作している場合は,ローリング・アップグレードとして,表 7-1 に示す作業を行うことができます。

表 7-1:  バージョン 5.1A および バージョン 5.1B で行えるローリング・アップグレード作業

バージョン 5.1A から バージョン 5.1B へのアップデート・インストレーション

バージョン 5.1B から次のリリースへのアップデート・インストレーション

バージョン 5.1A のパッチ

バージョン 5.1B のパッチ

NHD (New Hardware Delivery) キットの バージョン 5.1A クラスタへのインストール

NHD キットの バージョン 5.1B クラスタへのインストール

ベース・オペレーティング・システムおよびクラスタ・ソフトウェアのバージョン 5.1A から バージョン 5.1B へのアップデート・インストレーションと,その後に行う &W4TCRversion のパッチ

ベース・オペレーティング・システムおよびクラスタ・ソフトウェアの バージョン 5.1B から次のリリースへのアップデート・インストレーションと,その後に行う次のリリースのパッチ [脚注 5]

バージョン 5.1A のクラスタへの NHD インストレーションと,その後に行うバージョン 5.1A のパッチ

バージョン 5.1B のクラスタへの NHD インストレーションと,その後に行う バージョン 5.1B のパッチ

バージョン 5.1A からバージョン 5.1B へのアップデート・インストレーションと,その後に行う &W4TCRversion への NHD キットのインストレーション

ベース・オペレーティング・システムとクラスタ・ソフトウェアのバージョン 5.1B から次のリリースへのアップデート・インストレーションと,その後に行う次のリリースへの NHD キットのインストレーション [脚注 6]

バージョン 5.1A から バージョン 5.1B へのアップデート・インストレーションと,その後に行う バージョン 5.1Bへの NHD キットのインストレーション,およびその後に行うバージョン 5.1B のパッチ

バージョン 5.1B から次のリリースへのアップデート・インストレーションと,その後に行う次のリリースへの NHD キットのインストレーション,およびその後に行う次のリリースへのパッチ [脚注 6]

7.2    ローリング・アップグレードでサポートされていない作業

ローリング・アップグレード中に実行できない作業,または実行しないことを推奨する作業のリストを以下に示します。

7.3    ローリング・アップグレードの手順

この節の手順では,特に明記しない限りコマンドはマルチユーザ・モードで実行します。各段階の手順は,それぞれの対応する項で詳しく説明します。ローリング・アップグレードを実行する場合は,その前に 7.7 節で各段階の詳しい説明を参照されることをお勧めします。

ローリング・アップグレードの段階の中には,他の段階よりも時間のかかるものがあります。表 7-2 に,各段階を完了するまでのおおよその所要時間をまとめています。

表 7-2:  ローリング・アップグレードの各段階における所要時間

段階 所要時間
準備 プログラム制御ではない。
セットアップ 45〜120分。 [脚注 7]
プリ・インストール 15〜30分。 [脚注 7]
インストール 単一システムで installupdatedupatchnhd_install,またはこれらのコマンドの有効な組み合わせを実行する時間。
ポスト・インストール 1 分未満。
ロール (メンバごと)

パッチ : 5 分未満。

アップデート・インストレーション : メンバの追加にかかる時間とほぼ同じ。 [脚注 8]

スイッチ 1 分未満。
クリーンアップ 30〜90 分。 [脚注 7]

以下の手順で,TruCluster Server バージョン 5.1A クラスタをバージョン 5.1B にアップグレードします。すでにバージョン 5.1B になっているクラスタをアップグレードする場合も同じです。

  1. ローリング・アップグレードを実行するために,次のようにクラスタを準備します (7.7.1 項)。

    1. 先行メンバ (最初にロールするメンバ) として使用するクラスタ・メンバを選択します。この手順の例では,memberid2 のメンバを先行メンバとして使用します。メンバのホスト名は,provolone です。

    2. クラスタのバックアップをとります。

    3. インストール段階でアップデート・インストレーションを実行する場合は,クラスタにインストールされている表 7-6 のブロッキング・レイヤード・プロダクトを削除します。

    4. 任意のクラスタ・メンバで次のように clu_upgrade -v check setup lead_memberid コマンドを実行し,クラスタをアップグレードする準備ができているかどうかを確認します。

      clu_upgrade -v check setup 2
       
      

      ファイル・システムでより多くの空き容量が必要な場合は,addvol などの AdvFS Utilities を使用して,必要なボリュームをドメインに追加します。必要なディスク・スペースについては,7.7.1 項を参照してください。AdvFS ドメインの管理方法については,Tru64 UNIX 『AdvFS 管理ガイド』を参照してください。

    5. 各システムのファームウェアが新しいソフトウェアをサポートしていることを確認します。ローリング・アップグレードの前に,必要に応じてファームウェアをアップデートします。

  2. セットアップ段階を実行します (7.7.2 項)。

    注意

    現在のクラスタがバージョン 5.1A 以降である場合に,このインストール段階でベース・オペレーティング・システムとクラスタ・ソフトウェアをアップグレードする予定があれば,新しい TruCluster Server キットの入っているデバイスまたはディレクトリをマウントし,その後で clu_upgrade setup を実行します。setup コマンドを実行すると,そのキットが /var/adm/update/TruClusterKit ディレクトリにコピーされます。

    現在のクラスタがバージョン 5.1A 以降である場合に,インストール段階で NHD キットをインストールする予定があれば,新しい NHD キットの入っているデバイスまたはディレクトリをマウントし,その後で clu_upgrade setup を実行します。setup コマンドを実行すると,そのキットが /var/adm/update/NHDKit ディレクトリにコピーされます。

    次の例のように,任意のメンバで clu_upgrade setup lead_memberid コマンドを実行します。

    clu_upgrade setup 2
     
    

    clu_upgrade コマンドで表示されるメニューを 7.7.2 項 に示します。

    セットアップ段階が完了すると,clu_upgrade はプロンプトを表示して,先行メンバ以外の全クラスタ・メンバのリブートを求めます。

  3. 先行メンバ以外のすべてのクラスタ・メンバを一度に 1 つずつリブートします。これらのメンバがリブートされるか停止されるまで,プリ・インストール段階を開始しないでください。

  4. プリ・インストール段階を実行します (7.7.3 項)。

    先行メンバで,次のコマンドを実行します。

    clu_upgrade preinstall
     
    

    現在のクラスタがバージョン 5.1A 以降である場合は,preinstall コマンドを実行するときに,セットアップ段階で作成されたタグ付きファイルがあるかどうかを,必要に応じて確認することができます。

  5. インストール段階を実行します (7.7.4 項)。

    注意

    インストール段階では,新しいソフトウェアを先行メンバにロードし,実質的にそのメンバをロールします。ロール段階を実行すると,この新しいソフトウェアはクラスタ内の他のメンバに広まります。

    clu_upgrade コマンドは,インストール段階ではソフトウェアをロードしません。ソフトウェアのロードはどのコマンド (installupdatedupatchnhd_install) を実行するかで決まります。

    バージョン 5.1A およびバージョン 5.1B で行えるローリング・アップグレード作業とその組み合わせについては,表 7-1 を参照してください。

    1. installupdate コマンドの使用方法については,Tru64 UNIX の『インストレーション・ガイド』を参照してください。

      dupatch コマンドの使用方法については,パッチ・キットに添付されている Tru64 UNIX と TruCluster Server の『Patch Kit Installation Instructions』を参照してください。

      nhd_install コマンドの使用方法については,NHD キットに添付されている Tru64 UNIX の『New Hardware Delivery Release Notes and Installation Instructions』を参照してください。

    2. インストールするソフトウェアが,シングルユーザ・モードでインストレーション・コマンドを実行しなければならないソフトウェアである場合は,次のようにして,システムを停止した後,シングルユーザ・モードでブートします。

      shutdown -h now
      >>> boot -fl s
       
      

      注意

      システムを停止してリブートすることで,クラスタに提供するサービスを最小限に抑えることができます。その結果,稼働中のクラスタがこのシングルユーザ・モードで動作するメンバに依存する度合も最小限に抑えることができます。特に,サービスのフェイルオーバを完結させるために,クラスタ・メンバを一度は「DOWN」ステータスにしなければならないサービスがあれば,メンバを停止させることで,その要求を満たすこともできます。最初にクラスタ・メンバを停止しないと,サービスが期待どおりにフェイルオーバしません。

      システムがシングルユーザ・モードになったら,次のコマンドを実行します。

      init sbcheckrclmf reset
       
      

    3. installupdatedupatch,または nhd_install を実行します。

      複数のパッチ・キットをロールするには,1 回のインストール段階で dupatch コマンドを複数回実行します。ただし,パッチ処理が完了して,クラスタの使用中に問題が発生した場合,問題を特定することが難しくなる場合がありますので注意してください。

      installupdate コマンドの前に dupatch コマンドを実行することはできません。ローリング・アップグレードを実行する前に現在のソフトウェアにパッチをあてるには,ローリング・アップグレード操作を 2 回 (現在のソフトウェアに対するパッチを 1 回とアップデート・インストレーションを 1 回) 実行する必要があります。

  6. (オプション) 新しいカスタム・カーネルを使用して先行メンバを最終的にリブートしてから他のメンバをロールするまでの間に,次のテストを手動で実行することもできます。

    1. ロール済みの先行メンバから共用ルート (/) ファイル・システムをサービスできることを確認します。

      1. 次のように cfsmgr コマンドを使用し,その時点でルート・ファイル・システムをサービスしているクラスタ・メンバを調べます。

        cfsmgr -v -a server /
         
         Domain or filesystem name = /
         Server Name = polishham
         Server Status : OK
         
        

      2. 次のコマンドを実行して,ルート (/)・ファイル・システムを先行メンバに再配置します。

        cfsmgr -h polishham -r -a SERVER=provolone /
         
        

    2. 先行メンバからクライアントにアプリケーションをサービスできることを確認します。クラスタからクライアントへサービスするすべての重要なアプリケーションを先行メンバからサービスできることも確認します。

      テストする内容と方法を決定します。次の例のように,ロールを続行する前に重要なアプリケーションをすべて検査して,先行メンバからクライアントにこれらのアプリケーションが正しくサービスされることを確認することをお勧めします。

      • CAA サービスを先行メンバに手動で再配置します。たとえば,cluster_lockd というアプリケーション・リソースを provolone 先行メンバに再配置するには,次のコマンドを実行します。

        caa_relocate cluster_lockd -c provolone
         
        

      • 次のように,省略時のクラスタ別名に対する選択優先順位属性 selp を一時的に変更して,先行メンバがその別名宛てに送信された要求をすべてサービスするように強制します。

        cluamgr -a alias=DEFAULTALIAS,selp=100
         
        

        この操作で,省略時のクラスタ別名に宛てられた接続要求とパケットは,先行メンバが最終的にすべて受信するようになります。

        他のメンバまたは他のクライアントから telnetftp などのサービスを使用して,先行メンバで別名宛の通信が処理されることを確認します。クラスタで提供する重要なサービスにクライアントからアクセスできるかどうかを検査します。

        問題がない場合は,先行メンバで別名の属性を元の値に再設定します。

  7. ポスト・インストール段階を実行します (7.7.5 項)。

    先行メンバで次のコマンドを実行します。

    clu_upgrade postinstall
     
    

  8. ロール段階を実行します (7.7.6 項)。

    ロール前のクラスタ・メンバをロールします。 [脚注 9]

    ロールされていないメンバの数 (クォーラム・ディスクが構成されている場合はクォーラム・ディスクも含む) がクラスタ・クォーラムを維持するのに十分な場合,複数のメンバを同時にロールすることができます (並列ロール)。

    メンバをロールするには,以下の手順を実行します。

    1. 次のようにして,メンバ・システムを停止させた後シングルユーザ・モードでブートします。

      shutdown -h now
      >>> boot -fl s
       
      

    2. システムがシングルユーザ・モードになったら,次のコマンドを実行します。

      init sbcheckrclmf reset
       
      

    3. メンバをロールします。

      clu_upgrade roll
       
      

      並列ロールを実行する場合,clu_upgrade roll コマンドの -f オプションを使います。このオプションをつけると,許可の入力を求めることなく自動的にメンバをリブートします。

      clu_upgrade -f roll
       
      

      ロール・コマンドは,メンバをロールすることによってクォーラムが失われないことを確認します。ロールの結果クォーラムが失われると判断した場合,メンバはロールされず,エラー・メッセージが表示されます。現在ロール中のメンバの 1 つがクラスタに戻り,クォーラム・ボートが利用可能になると,メンバをロールすることができます。

      ロールが進むと,メンバはリブート可能になります。-f オプションを使うと,プロンプトが表示されずに自動的にリブートされます。-f オプションを使わない場合,clu_upgrade はプロンプトを表示し,この時点でリブートを行うかどうかについて質問してきます。リブート前に特に調べたいことがなければ,yes と入力します (yes と入力してから実際にリブートが行われるまで 30 秒程度かかることがあります)。

      ロール段階を完了するのに必要な時間を短縮するには,並列ロールを実行します。たとえば,クォーラム・ディスクのある 8 メンバで構成されるクラスタでは,先行メンバをロールした後,4 メンバを同時にロールすることができます。

      1. メンバでロール段階を開始します (先行メンバはインストール段階でロールされているため,先行メンバについてはロール段階は実行しません)。

      2. 以下のようなメッセージが表示されたら,次のメンバについてロール段階を開始します

           *** Info ***
        You may now begin the roll of another cluster member.
        

        以下のような内容で始まるメッセージが表示されたら,メンバ・ボートに占める現在ロール中のメンバ数に起因する可能性があります。

          *** Info ***
        The current quorum conditions indicate that beginning
        a roll of another member at this time may result in
        the loss of quorum.
        
        

        この場合,以下の選択肢があります。

        • メンバがロール段階を完了するまで待ってから次のメンバに対してロールを開始する。

        • メンバ・ボートに含まれないロールされていないメンバが存在する場合は,そのメンバに対してロール段階を開始する。

    4. クラスタのすべてのメンバがロールされるまで,ロールを続けます。それぞれのロール段階について,開始できることを示すメッセージが表示されてから,ロール段階を開始します。

      最後のメンバをロールすると,以下のようなメッセージが表示されます

        *** Info ***
      This is the last member requiring a roll.
      

    注意

    実際のロールは,リブート中に行われます。clu_upgrade roll コマンドは,リブート中に実行する it(8) スクリプトをセットアップします。リブートが始まると,it スクリプトはメンバをロールして,カスタマイズしたカーネルを構築した後,そのメンバを再度リブートして,新しくカスタマイズしたカーネルが実行されるようにします。メンバが新しくカスタマイズしたカーネルをブートすると,ロールは終了し,タグ付きファイルを使用しないで動作するようになります。

  9. スイッチ段階を実行します (7.7.7 項)。

    すべてのメンバをロールした後,任意のメンバで switch コマンドを実行します。

    clu_upgrade switch
     
    

  10. クラスタ・メンバを一度に 1 つずつリブートします。

  11. クリーンアップ段階を実行します (7.7.8 項)。

    任意のメンバで次のコマンドを実行し,クラスタのタグ付きファイル (.Old..) を削除して,アップグレードを完了します。

    clu_upgrade clean
     
    

7.4    ローリング・アップグレードのステータス表示

clu_upgrade コマンドでは,ローリング・アップグレードのステータスを表示するための次のようなオプションを提供しています。ステータス・コマンドは,いつでも実行することができます。

注意

ロール中,クラスタには 2 つのバージョンの clu_upgrade コマンドが存在することがあります。2 つのバージョンとは,ロール前のメンバで使用する旧バージョン,および新バージョン (アップデート配布キットまたはパッチ・キットに含まれる場合) です。status コマンドで表示される情報がロール前のメンバとロール後のメンバでは異なることがあります。そのため,2 つのメンバで status コマンドを実行した場合は,出力表示の形式が異なることがありますので注意してください。

installupdate を実行した後で clu_upgrade status を実行すると,clu_upgrade はメッセージを表示して,インストール段階が完了していることを通知してきます。しかし,実際には,clu_upgrade postinstall コマンドを実行するまでインストール段階は完了していません。

7.5    各段階の取り消し

clu_upgrade undo コマンドでは,スイッチ段階を完了していないローリング・アップグレードを取り消すことができます。スイッチ段階とクリーンアップ段階を除いて,どの段階でも取り消すことができます。段階の取り消しは正しい順序で行わなければなりません。たとえば,プリ・インストール段階を完了した後でローリング・アップグレードを取り消す場合は,プリ・インストール段階を取り消してから,セットアップ段階を取り消します。

注意

段階を取り消す前に,関連するバージョンの 『クラスタ・リリース・ノート』 を読み,段階の取り消しに関連する制約事項があるかどうかを調べておくようお勧めします。

段階を取り消すには,取り消す段階を指定して undo コマンドを実行します。clu_upgrade コマンドでは,指定した段階が取り消し可能であるかどうかを確認します。段階を取り消すための条件については,表 7-3 を参照してください。

表 7-3:  各段階の取り消し

取り消す段階 コマンド 説明
セットアップ clu_upgrade undo setup

このコマンドは,先行メンバで実行する。また,セットアップ段階を取り消す場合は,どのメンバもタグ付きファイルを使用して実行できない。

セットアップ段階を取り消す前に,clu_upgrade -v status コマンドを実行し,タグ付きファイルを使用して実行しているメンバを検索する。次に,clu_upgrade tagged disable memberid コマンドを実行して,これらのメンバのタグ付きファイルを無効にする (タグ付きファイルとその操作に使用するコマンドについては,7.8 節を参照)。

タグ付きファイルを使用して実行中のメンバがない場合は,先行メンバで clu_upgrade undo setup コマンドを実行する。

プリ・インストール clu_upgrade undo preinstall このコマンドは,先行メンバで実行する。
インストール clu_upgrade undo install

このコマンドは,先行メンバ以外のメンバで実行する。

先行メンバを停止し,この先行メンバのブート・ディスクにアクセスできるメンバで clu_upgrade undo install コマンドを実行する。コマンドが完了した後で,先行メンバをブートする。

ポスト・インストール clu_upgrade undo postinstall このコマンドは,先行メンバで実行する。
ロール clu_upgrade undo roll memberid

このコマンドはロール段階を取り消すメンバ以外のメンバで実行できる。

ロール段階を取り消すメンバを停止する。停止したメンバのブート・ディスクにアクセスできる他のメンバで clu_upgrade undo roll memberid コマンドを実行する。コマンドが完了した後で,停止したメンバをブートする。これらの操作により,メンバでタグ付きファイルが使用される。

7.6    ローリング・アップグレードのコマンド

ローリング・アップグレード全体の流れは, clu_upgrade(8) で説明されている clu_upgrade コマンドを使用して制御します。このコマンドを使用すれば,正しい順序で各段階を実行することができます。インストール段階では,installupdatedupatch,および nhd_install のうちの 1 つまたは複数を使用して,ソフトウェアのロードとインストールを実行することができます。これらのコマンドはローリング・アップグレードに対応しています。つまり,ローリング・アップグレードのインストール段階とロール段階でどの動作が許可されているかを判断できるようになっています。

ローリング・アップグレードを開始すると,クラスタは以前のリリースからソフトウェアを実行します。ローリング・アップグレードの最初の部分では,以前からクラスタにインストールされている clu_upgrade コマンドを実行します。ローリング・アップグレード中に新しいバージョンがインストールされた場合,コマンドのバージョンの違いにより画面表示や動作が多少異なることがあります。

インストールするキットにアップグレード・コマンドの新しいバージョンが含まれていた場合にローリング・アップグレードのどの段階でその新バージョンが使用できるようになるかを,以下の 2 つの表に示します。 [脚注 10]

表 7-4:  バージョン 5.1A からローリング・アップグレードする場合の段階と clu_upgrade のバージョンとの対応

段階 バージョン 5.1A 次のリリース [脚注 11] 説明
準備 X   現在インストールされている (旧) バージョンの clu_upgrade が常に実行される。
セットアップ X  

現在インストールされている (旧) バージョンの clu_upgrade が常に実行される。

アップデート・インストレーションを行う場合は clu_upgrade の新バージョンが TruCluster Server キットから読み取られて /usr/sbin/clu_upgrade にインストールされ,旧バージョンと交換される。この交換はタグ付きファイルを作成する前に行われるため,それ以降のローリング・アップグレードでは,どのメンバもすべて新しい clu_upgrade を使用することになる。

プリ・インストール   X ローリング・アップグレードでアップデート・インストレーションを行う場合は,どのメンバも,セットアップ段階の途中でインストールされた新バージョンの clu_upgrade を使用する (それ以外の場合は,どのメンバも現バージョンの clu_upgrade を継続して使用する)。
インストール   X

ローリング・アップグレードでアップデート・インストレーションを行う場合は,どのメンバも,セットアップ段階の途中でインストールされた新バージョンの clu_upgrade を使用する

アップデート・インストレーションの途中で,installupdate が新バージョンのものに置き換えられる。

パッチ・キットを適用すると,常に最新バージョンの dupatch がインストールされる。

パッチ・キットに新しいバージョンの clu_upgrade が含まれている場合にそのパッチを適用すると,新バージョンがインストールされ,どのクラスタ・メンバもすべてポスト・インストール段階で新バージョンを使用する。

ポスト・インストール   X セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。
ロール   X セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。
スイッチ   X セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。
クリーンアップ   X セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。

表 7-5:  バージョン 5.1B からローリング・アップグレードする場合の段階と clu_upgrade のバージョンとの対応

段階 バージョン 5.1B 次のリリース [脚注 12] 説明
準備 X   この段階では,現在インストールされている (旧) バージョンの clu_upgrade が常に実行される。
セットアップ X  

この段階では,現在インストールされている (旧) バージョンの clu_upgrade が常に実行される。

アップデート・インストレーションを実行する場合は,clu_upgrade の新バージョンが TruCluster Server キットから読み取られて /usr/sbin/clu_upgrade にインストールされ,旧バージョンと交換される。この交換はタグ付きファイルを作成する前に行われるため,それ以降のローリング・アップグレードでは,どのメンバもすべて新しい clu_upgrade を使用することになる。

プリ・インストール   X ローリング・アップグレードでアップデート・インストレーションを行う場合は,どのメンバも,セットアップ段階の途中でインストールされた新バージョンの clu_upgrade を使用する (それ以外の場合は,どのメンバも現バージョンの clu_upgrade を継続して使用する)。
インストール   X

ローリング・アップグレードでアップデート・インストレーションを行う場合は,どのメンバも,セットアップ段階の途中でインストールされた新バージョンの clu_upgrade を使用する。

アップデート・インストレーションの途中で,installupdate が新バージョンのものに置き換えられる。

パッチ・キットを適用すると,常に最新バージョンの dupatch がインストールされる。

パッチ・キットに新しいバージョンの clu_upgrade が含まれている場合にそのパッチを適用すると,新バージョンがインストールされ,どのクラスタ・メンバもすべてポスト・インストール段階で新バージョンを使用する。

ポスト・インストール   X セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。
ロール   X セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。
スイッチ   X セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。
クリーンアップ   X セットアップ段階またはインストール段階のいずれかで新しいバージョンの clu_upgrade がインストールされた場合は,どのメンバもすべて新バージョンを使用する。

7.7    ローリング・アップグレードの各段階

この節では,ローリング・アップグレードの各段階について説明します。

注意

以降の各項では,各段階の概要を説明します。ローリング・アップグレードを実行する場合は,7.3 節で示す手順に従ってください。

7.7.1    準備段階

コマンド 実行場所 実行レベル
clu_upgrade -v check setup lead_memberid 任意のメンバ マルチユーザ・モード

準備段階では,クラスタの重要なデータをすべてバックアップし,クラスタをロールする準備ができているかどうかを検査します。ローリング・アップグレードの開始前に,次の操作を行います。

  1. 最初にロールするメンバを,1 つ選択します。このメンバを先行メンバと呼びます。先行メンバは,ルート (/),/usr/var,および i18n (使用されている場合) ファイル・システムに対して直接アクセスできる必要があります。

    先行メンバで重要なアプリケーションを実行できることを確認します。これらのアプリケーションをテストできるのは,インストール段階でこのメンバをアップデートしてから他のメンバをロールするまでの間です。問題が発生した場合は,次へ進む前にこのメンバで問題を解決します。問題を解決できない場合は,ローリング・アップグレードを取り消して,クラスタをロール前の状態に戻します (ローリング・アップグレードの各段階を取り消す方法については,7.5 節を参照)。

  2. クラスタ単位のルート (/),/usr,および /var ファイル・システム,およびこれらのファイル・システムに含まれるメンバ固有のファイルすべてのバックアップをとってください。クラスタに独立した i18n ファイル・システムが含まれている場合は,このファイル・システムのバックアップもとります。また,他にも重要なユーザ・データやアプリケーション・データを格納したファイル・システムがある場合は,そのファイル・システムのバックアップもとってください。

    注意

    ローリング・アップグレード中に実行するクラスタの増分バックアップまたフル・バックアップは,タグ付きファイルで実行しているメンバ以外のメンバだけを対象にしてください。タグ付きファイルを使用しているメンバからバックアップをとると,.Old.. ファイルの内容のみのバックアップをとることになります。先行メンバではタグ付きファイルを使用しないので,ローリング・アップグレード中は,先行メンバ (またはロール済みの他のメンバ) からクラスタのバックアップをとることができます。

    通常のサイトでは,バックアップ手順が自動化されています。クラスタのローリング・アップグレード中に自動バックアップが実行されることがわかっている場合は,そのバックアップが先行メンバまたはロール済みのメンバで実行されることを確認してください。

  3. インストール段階で installupdate コマンドを実行する場合は,表 7-6 に示す,クラスタにインストールされているブロッキング・レイヤード・プロダクトを削除します。

  4. clu_upgrade -v check setup lead_memberid を実行し,次の内容を確認します。

  5. 各システムのファームウェアが新しいソフトウェアをサポートしていることを確認します。必要があれば,ローリング・アップグレードを開始する前にファームウェアをアップデートします。

クラスタにはオペレーティング・システムとクラスタ・ソフトウェアが 2 組あるため,ローリング・アップグレード中でもクラスタを運用することができます (共用構成ファイルは 1 つだけなので,あるメンバで加えられた変更を他のメンバからも確認することができます)。この方法では,同じクラスタで同時に 2 種類のバージョンのベース・オペレーティング・システムを実行することができます。ただし,クラスタ単位のルート (/),/usr,および /var ファイル・システムに,また,各国語サポート (WLS) サブセットの独立したドメインがある場合は i18n ファイル・システムに,それぞれ必要な空きディスク容量があるかどうかをアップグレード前に確認する必要があります。

ローリング・アップグレードを実行するには,次の空きディスク容量が必要です。

ファイル・システムにより多くの空き容量が必要な場合は,addvol などの AdvFS Utilities を使用して,必要に応じてドメインにボリュームを追加します。AdvFS ドメインの管理方法については,Tru64 UNIX 『AdvFS 管理ガイド』を参照してください (AdvFS Utilities は別ライセンスが必要)。クラスタ単位のルート (/) ドメインは拡張することができます。

注意

clu_upgrade コマンドは,ローリング・アップグレードを開始するときにディスク容量を確認します。ただし,ローリング・アップグレード中は,クラスタ・メンバがディスク容量を消費することを防止できないので,後の段階でディスク容量が不足することもあります。

必要なディスク容量は場合に応じて変わってきます。ローリング・アップグレード中にメンバがディスク容量を大量に消費することがわかっている場合には,アップグレードの前に容量を追加しておいてください。

7.7.2    セットアップ段階

コマンド 実行場所 実行レベル
clu_upgrade setup lead_memberid 任意のメンバ マルチユーザ・モード

セットアップ段階では,clu_upgrade check setup コマンドを実行してタグ付きファイルを作成し,クラスタをロールする準備をします。

clu_upgrade setup lead_memberid では,次のタスクが実行されます。

7.7.3    プリ・インストール段階

コマンド 実行場所 実行レベル
clu_upgrade preinstall 先行メンバ マルチユーザ・モード

プリ・インストール段階の目的は,クラスタの先行メンバで installupdatedupatch,および nhd_install コマンドを実行する準備ができているかどうかを確認することです。

clu_upgrade preinstall コマンドでは,次の内容が実行されます。

7.7.4    インストール段階

コマンド 実行場所 実行レベル
installupdate 先行メンバ シングルユーザ・モード
dupatch 先行メンバ シングルユーザ・モードまたはマルチユーザ・モード
nhd_install 先行メンバ シングルユーザ・モード

現在のクラスタが TruCluster Server バージョン 5.1B または バージョン 5.1Aで動作している場合は,表 7-1 に示す作業を単独または組み合わせて実行することがきます。

インストール段階は,clu_upgrade preinstall コマンドが完了してから clu_upgrade postinstall コマンドを実行する直前までを指します。

注意

installupdate を実行した後で clu_upgrade status を実行すると,clu_upgrade はメッセージを表示して,インストール段階が完了していることを通知します。しかし,実際には clu_upgrade postinstall コマンドを実行するまでインストール段階は完了していません。

installupdate コマンドまたは nhd_install コマンドを実行するには,先行メンバをシングルユーザ・モードに設定する必要があります。また,dupatch コマンドを実行する場合もシングルユーザ・モードに設定することをお勧めします。システムをシングルユーザ・モードに設定する場合は,システムを停止してから,シングルユーザ・モードでリブートします。

シングルユーザ・モードに設定されたシステムで,init sbcheckrc,および lmf reset コマンドを実行してから installupdatedupatch,または nhd_install コマンドを実行します。これらのコマンドの使用方法については,Tru64 UNIX 『インストレーション・ガイド』,Tru64 UNIX および TruCluster Server の『Patch Kit Installation Instructions』,および Tru64 UNIX 『New Hardware Delivery Release Notes and Installation Instructions』を参照してください。

注意

複数のパッチをインストールするには,dupatch コマンドを複数回実行します。ただし,パッチ処理が完了してクラスタの使用中に問題が発生した場合,問題の特定が困難になります。

インストール段階では,installupdate コマンドより先に dupatch コマンドを実行することはできません。ローリング・アップグレードを実行する前に現在のソフトウェアにパッチをあてるには,ローリング・アップグレード操作を 2 回 (現在のソフトウェアに対するパッチを 1 回とアップデート・インストレーションを 1 回) 実行する必要があります。

アップデート・インストレーションを含むローリング・アップグレードの一環として NHD インストレーションを行う場合は,nhd_install を手動で実行する必要がありません。installupdate コマンドが NHD キットをインストールします。それ以外の場合は,セットアップ段階で clu_upgrade がコピーした nhd_install コマンドを使用します。このコマンドは /var/adm/update/NHDKit/nhd_install にあります。

7.7.5    ポスト・インストール段階

コマンド 実行場所 実行レベル
clu_upgrade postinstall 先行メンバ マルチユーザ・モード

ポスト・インストール段階では,先行メンバでアップデート・インストレーション,パッチ,または NHD インストレーションが完了したことを確認します。アップデート・インストレーションを実行した場合は,先行メンバが新しいバージョンのベース・オペレーティング・システムにアップグレードされたことを clu_upgrade postinstall コマンドで確認します。

7.7.6    ロール段階

コマンド 実行場所 実行レベル
clu_upgrade roll ロール中のメンバ シングルユーザ・モード

インストール段階では先行メンバをアップグレードしましたが,他のメンバはロール段階でアップグレードします。

多くのクラスタ構成では,複数のメンバを並列でロールし,クラスタ・アップグレードに必要な時間を短縮することができます。並列的にロールできるメンバの数は,ロールされていないメンバ (クォーラム・ディスクが構成されている場合は,クォーラム・ディスクを含む) がクォーラムを維持するのに十分なボートを持つ必要があるという要件によってのみ制限されます。並列ロールは,先行メンバがロールされた後にだけ実行することができます。

clu_upgrade roll コマンドでは,次のタスクが実行されます。

注意

ローリング・アップグレードの途中でクラスタにメンバを追加しなければならない場合は,ロールを完了したメンバからそのメンバを追加してください。

すべてのメンバをロールし終える前にあるメンバがダウンして修復もリブートもできない場合は,クラスタのロールを完了させるために,そのメンバを削除しなければなりません。ただし,1 つのメンバを除いてすべてのメンバのロールが完了しているという状態で,ロールの完了していないそのメンバがロール段階でリブートする前にダウンした場合は,そのメンバを削除してから他のクラスタ・メンバをリブートする必要があります。clu_upgrade はリブート中も動作して,クラスタに現在あるメンバの数に対してロールされたメンバがどれだけあるかを追跡します。clu_upgrade は,それら 2 つの値が同じになると,ロール段階が完了したものとしてマークします。そのため,1 つのメンバを除いてすべてのメンバをロールした場合,ロールされていないメンバを削除して他のメンバをリブートすることにより,ロール段階が完了し,ローリング・アップグレードが継続できます。

7.7.7    スイッチ段階

コマンド 実行場所 実行レベル
clu_upgrade switch 任意のメンバ

マルチユーザ・モード

すべてのメンバが起動している [脚注 13]

スイッチ段階では,ソフトウェアのアクティブ・バージョンを新バージョンに設定します。その結果,ローリング・アップグレード中に無効にしておいた新機能が有効になります (アクティブなバージョンと新バージョンについての説明は,7.9 節を参照してください)。

clu_upgrade switch コマンドでは,次のタスクが実行されます。

注意

スイッチ段階の終了後は,クラスタ・メンバを一度に 1 つずつリブートする必要があります。

7.7.8    クリーンアップ段階

コマンド 実行場所 実行レベル
clu_upgrade clean 任意のメンバ マルチユーザ・モード

クリーンアップ段階では,タグ付き (.Old..) ファイルをクラスタから削除して,アップグレードを完了します。

clu_upgrade clean コマンドでは,次のタスクが実行されます。

7.8    タグ付きファイル

ローリング・アップグレードでは,一度に 1 つのクラスタ・メンバのソフトウェアがアップデートされます。ロール中にクラスタで 2 つのバージョンのソフトウェアを動作させるには,セットアップ段階で clu_upgrade を実行し,タグ付きファイルを作成します。

タグ付きファイルは,現在のファイルをコピーして,元のファイル名の先頭に .Old.. を追加してその名前にするとともに,AdvFS プロパティ (DEC_VERSION_TAG) を設定したファイルです。たとえば,vdump コマンドのタグ付きファイルの名前は,/sbin/.Old..vdump となります。タグ付きファイルは,元のファイルと同じファイル・システムに作成されるため,ローリング・アップグレードを開始する前に,十分なディスク容量があることを確認する必要があります。

メンバがタグ付きファイルを使用して実行されるかどうかは,そのメンバの sysconfigtab rolls_ver_lookup 変数によって制御されます。アップグレード・コマンドは,メンバをタグ付きファイルを使用して実行する必要があれば,その値を 1 に,また,メンバをタグ付きファイルを使用して実行してはならない場合は,その値を 0 にそれぞれ設定します。

メンバの sysconfigtab rolls_ver_lookup 属性を 1 に設定すると,パス名を特定する場合に,指定したファイルと対応する .Old..filename というファイル名のコピーがあるかどうか,およびこのコピーに DEC_VERSION_TAG プロパティが設定されているかどうかを調べます。両方の条件が満たされると,要求したファイル操作が透過的に変更され,.Old..filename ファイルが使用されます。たとえば,ロールが完了していないメンバで vdump コマンドを実行すると,/sbin/.Old..vdump が実行され,ロール済みのメンバで実行すると,/sbin/vdump が実行されます。先行メンバ (最初にロールするメンバ) だけは,タグ付きファイルを使用して実行されません。

注意

ディレクトリに対するファイル・システム操作では,このタグ付きファイルの制約を受けることはありません。たとえば,ローリング・アップグレード中にクラスタ・メンバのディレクトリで ls を実行すると,両方のバージョンのファイルがリストされます。ただし,ローリング・アップグレードを完了する前のメンバと完了した後のメンバでは,ls -ail コマンドを実行した場合の出力が異なります。以下の例は,ls -ail コマンドを,ロールされていないメンバで最初に実行した後,ロールされたメンバで実行した例です (awk ユーティリティは,各ファイルの i ノード,サイズ,タイム・スタンプ (月日),およびファイル名だけを出力するために使用しています)。

次に示す出力は,タグ付きファイルを使用して動作しているロール前のクラスタ・メンバで ls コマンドを実行した場合のものです。タグ付きファイルとタグの付いていないファイルは同一です (i ノード,サイズ,タイム・スタンプが同じ)。このメンバで hostname コマンドを実行すると,タグの付いている方 (i ノード 3643) が実行されます。

# cd /sbin
# ls -ail hostname .Old..hostname ls .Old..ls init .Old..init |\
awk '{printf("%d\t%d\t%s %s\t%s\n",$1,$6,$7,$8,$10)}`
 
 3643   16416    Aug 24   .Old..hostname
 3648   395600   Aug 24   .Old..init
 3756   624320   Aug 24   .Old..ls
 3643   16416    Aug 24   hostname
 3648   395600   Aug 24   init
 3756   624320   Aug 24   ls
 

次に示す出力は,ロールした後にタグ付きファイルを使用しないで動作しているクラスタ・メンバで ls コマンドを実行した場合のものです。タグ付きファイルとタグの付いていないファイルは異なります (i ノード,サイズ,タイム・スタンプが異なる)。このメンバで hostname コマンドを実行すると,タグの付いていない方 (i ノード 1370) が実行されます。

# cd /sbin
# ls -ail hostname .Old..hostname ls .Old..ls init .Old..init |\
awk '{printf("%d\t%d\t%s %s\t%s\n",$1,$6,$7,$8,$10)}`
 
 3643   16416    Aug 24   .Old..hostname
 3648   395600   Aug 24   .Old..init
 3756   624320   Aug 24   .Old..ls
 1187   16528    Mar 12   hostname
 1370   429280   Mar 12   init
 1273   792640   Mar 12   ls
 

セットアップ段階でタグ付きファイルを作成した後は,ロールしたメンバから tar のような管理タスクを実行することをお勧めします。先行メンバでは,タグ付きファイルを実行しないので常にコマンドを実行できます。

セットアップ段階で自動的にタグ付きファイルが作成されるファイルを判断する規則は,次のとおりです。

clu_upgrade コマンドには,タグ付きファイルを操作するためのさまざまな tagged コマンド・オプション (checkaddremoveenable,および disable) を指定することができます。タグ付きファイルを操作する場合は,次の点に注意してください。

7.9    バージョン・スイッチ

バージョン・スイッチは,アクティブ・バージョンのオペレーティング・システムから新しいバージョンのオペレーティング・システムへの移行を管理する場合に使用します。アクティブ・バージョンとは,現在使用中のバージョンを指します。クラスタでバージョン・スイッチを使用する目的は,すべてのメンバがアップデートされるまで,本質的に互換性がない新機能を導入しないようにするためです。たとえば,新バージョンでカーネル構造が変更されており,現在の構造と互換性がない場合,通常は,すべてのクラスタ・メンバがその新構造をサポートするバージョンにアップデートされるまで,クラスタ・メンバで新構造を使用しません。

ローリング・アップグレードの開始時には,どのメンバでもアクティブ・バージョンは新バージョンと同じです。ローリング・アップグレードが進むにつれて各メンバで新バージョンがアップデートされます。すべてのメンバでローリング・アップグレードが終了した後のスイッチ段階で,すべてのメンバのアクティブ・バージョンが新バージョンに設定されます。アップグレードが完了すると,再びすべてのメンバのアクティブ・バージョンが新バージョンと同じになります。次の簡単な例に,アクティブ・バージョン 1 と新バージョン 2 を使用して,ローリング・アップグレードの過程でバージョンが変わる様子を示します。

All members at start of roll:   active (1)  = new (1)
Each member after its roll:     active (1) != new (2)
All members after switch stage: active (2)  = new (2)
 

バージョンの移行を管理するには,clu_upgrade コマンドに versw コマンド ( versw(8) を参照) を指定します。clu_upgrade コマンドを使用して,各メンバをロールするときにバージョン・スイッチのすべてのアクティビティを管理します。すべてのメンバをロールした後のスイッチ段階で,次のコマンドを実行して新しいソフトウェアへの移行を完了させます。

clu_upgrade switch
 

7.10    ローリング・アップグレードとレイヤード・プロダクト

ここでは,レイヤード・プロダクトとローリング・アップグレードの相互作用を次の項に分けて説明します。

7.10.1    一般的なガイドライン

clu_upgrade setup コマンドは,クラスタでオペレーティング・システムをローリング・アップグレードするための準備を行います。clu_upgrade setup コマンドを実行してから最初のメンバを新しいバージョンにロールするまでの間は,setld コマンドを用いてクラスタにソフトウェアをロードしないでください。clu_upgrade setup コマンドを実行してからクラスタ・メンバを新しいバージョンにロールするまでの間にソフトウェアをインストールすると,新しいファイルは clu_upgrade setup で処理されなくなります。その結果,最初のクラスタ・メンバをロールする際に,その新しいファイルが上書きされてしまいます。

ソフトウェアをロードしなければならない場合は,次のような方法で行ってください。

7.10.2    ブロッキング・レイヤード・プロダクト

ブロッキング・レイヤード・プロダクトは,installupdate コマンドによるアップデート操作を妨げる製品です。installupdate コマンドを実行するローリング・アップグレードの開始前にクラスタからブロッキング・レイヤード・プロダクトを削除する必要があります。クラスタにパッチをあてるため,または NHD キットをインストールするためだけにローリング・アップグレードを実行する場合は,ブロッキング・レイヤード・プロダクトを削除する必要はありません。

表 7-6 は,このリリースのブロッキング・レイヤード・プロダクトをまとめたものです。

表 7-6:  ブロッキング・レイヤード・プロダクト

製品コード 説明
3X0 Open3D
4DT Open3D
ATM Atom Advanced Developers Kit
DCE Distributed Computing Environment
DNA DECnet
DTA Developer's Toolkit (プログラム分析ツール)
DTC Developer's Toolkit (C コンパイラ)
MME マルチメディア・サービス
O3D Open 3D
PRX PanoramiX Advanced Developers Kit

注意

3 文字の製品コードは,サブセット名の最初の 3 文字です。たとえば,ATMBASExxx という名前のサブセットは,ブロッキング・レイヤード・プロダクトの 1 つである ATM 製品 (Atom Advanced Developers Kit) の一部です。OSFATMBINxxx というサブセットは名前に ATM を含みますが,このサブセットはブロッキング・レイヤード・プロダクトの一部ではありません。これは OSF 製品 (ベース・オペレーティング・システム) のサブセットです。

ブロッキング・レイヤード・プロダクトをローリング・アップグレードの一環として削除すると,すべてのメンバからブロッキング・レイヤード・プロダクトが削除されます。ブロッキング・プロダクトに依存するサービスは,ロールが完了し,ブロッキング・レイヤード・プロダクトが再インストールされた後で使用できるようになります。

7.11    ローリング・アップグレードと RIS

ローリング・アップグレードのインストール段階を実行する場合,CD-ROM またはリモート・インストレーション・サービス (RIS) サーバからベース・オペレーティング・システムのサブセットをロードすることができます。

注意

RIS は,ベース・オペレーティング・システムのサブセットをロードする場合だけに使用できます。

RIS を使用するには,先行メンバおよび省略時のクラスタ別名の両方を RIS サーバに登録する必要があります。オペレーティング・システム・ソフトウェアの登録では,各ホスト名のハードウェア・アドレスが必要です。そのため,省略時のクラスタ別名を RIS サーバに登録するには,省略時のクラスタ別名に対するハードウェア・アドレスを生成する必要があります (RIS サーバの /etc/bootptab ファイルまたは /var/adm/ris/clients/risdb ファイルにすでに登録されているアドレスは受け付けられません)。

クラスタでクラスタ別名の仮想 MAC (vMAC) 機能を使用する場合は,省略時のクラスタ別名のハードウェア・アドレスとしてその仮想ハードウェア・アドレスを RIS サーバに登録します。クラスタで vMAC 機能を使用しない場合は,『クラスタ管理ガイド』の「vMAC」の節で説明するアルゴリズムを使用し,省略時のクラスタ別名に対するハードウェア・アドレスを手動で生成することもできます。

vMAC アドレスは,接頭文字 (省略時では AA:01) と,別名に対する 16 進数形式の IP アドレスで構成されます。たとえば,省略時のクラスタ別名が deli で,この IP アドレスが 16.140.112.209 である場合,省略時のクラスタ別名に対する vMAC アドレスは AA:01:10:8C:70:D1 で表されます。アドレスの作成方法は,次のとおりです。

        省略時の vMAC 接頭文字:      AA:01
        クラスタ別名の IP アドレス:   16.140.112.209
        16 進数形式の IP アドレス:   10.8C.70.D1
        この別名の vMAC :           AA:01:10:8C:70:D1
 

8 つの 16 進数で構成される任意の文字列を vMAC の省略時の接頭文字 (AA:01) に追加して,ハードウェア・アドレスを作成することもできます (例 AA:01:00:00:00:00)。このアドレスが RIS サーバからサービスされる領域内で一意であることを確認してください。クラスタが複数ある場合に次の別名を追加するには,16 進数の任意の文字列の値を大きくしてください (vMAC アルゴリズムを使用すると,ネットワーク内で一意のアドレスを作成できる可能性が高いので便利です)。