リチャード・ティーズ著

再利用はシステム管理者の方が最も嫌うトピックです。それは、再利用が問題の一因となって表面化することが多いからです。その意味において再利用とは歯医者に行くようなものです。歯医者は有用で必要なサービスを提供してくれますが、大抵は多少の痛みを伴います。幸いなことに再利用は歯痛の原因にはなりません。しかし再利用についてご存知の方ならよくおわかりのように、システム管理者の立場からすると再利用は痛みを伴うことが多く、そこにさらに再利用を必要とする問題が加わります。IBMはこの点に気づき、i5/OS V5R4でIFS再利用機能の強化を始め、解決策を提供すべくリソースを集中させました。本稿では、この機能強化について述べ、「root」(/)、QOpenSys、ユーザー定義ファイル・システム(UDFS)のIFS再利用に関するガイドを提供します。

V5R4でのIFS再利用機能の強化

IFS再利用を行なう最良のタイミングと方法について説明する前に、まずV5R4でのIFS再利用機能の強化について説明しておきます。IBMは過去数回のリリースでIFS再利用機能のユーザビリティを大幅に改善しています。

最初に説明するV5R4での機能強化は、おそらく一番重要な機能強化なのですが、RCLLNKという新しいコマンドです。このコマンドを使用するとシステムがアクティブな状態でしかも多くの場合IFSオブジェクトが使用されている状態でそのオブジェクトをマウントされたファイル・システム中で再利用することができます。またこのコマンドではIFSオブジェクトをより細かいレベルで再利用できます。つまり、RCLLNKコマンドを1つのオブジェクトに対して実行したりSUBTREEパラメータを使用してオブジェクトのグループに対して実行したりすることができます。いずれの場合もRCLSTGコマンドに比べれば大きな改良となっています。というのも、RCLSTGコマンドではIFSオブジェクトを再利用中に「使用中」にすることはできませんし、ASPDEVパラメータで指定された外部記憶プール(ASP: Auxiliary Storage Pool)中のすべてのIFSオブジェクトに対して実行されます。

IFSの観点からみると、RCLLNKコマンドをRCLSTGコマンドの代わりに使用できる状況は多数あります。RCLLNKコマンドもRCLSTGコマンドも「ルート」(/)、QOpenSys、UDFSファイル・システム中で発生する問題を識別して修正することができますが、通常のシステムのアクティビティを中断させることなく識別、修正できるのはRCLLNKコマンドだけです。また、RCLSTGコマンドを使用するときシステムは制限された状態あるいは独立したASP (IASP)に対するアクセスが制限されますが、RCLLNKコマンドの場合はこうした制限がありません。

RCLLNKコマンドのこうした利点を考えると、RCLSTGコマンドは本当に必要なのかとお考えかもしれません。その答えはイエスです。RCLSTGコマンドはRCLLNKコマンドが識別、修正できないようなIFS上の問題を識別して修正することができます。最も有名なのが、RCLSTGコマンドは喪失したIFSオブジェクトおよび記憶域を検出、回復することができるというものです。一般的に言って、RCLLNKコマンドはRCLSTGコマンドの機能の大部分を提供しており、IFSの問題に対する第一線の防御策として使用されるものです。RCLSTGコマンドはRCLLNKコマンドではうまくいかない場合のために備えて使用することができます。

それでもRCLSTGコマンドはIFS再利用というパズルを組み立てるのに必要なピースではあるので、V5R4でRCLSTGコマンドも改良されました。その1つが、SELECTパラメータに新たに*DIRオプションを設けることでディレクトリ(すなわちIFS)部分の再利用だけを行なうことができるようになったことです。この改良により、データベースのクロス参照テーブル(DBXREF)やライブラリ・オブジェクトなどといった再利用のうちのIFS部分ではない箇所を基本的にはスキップすることで、RCLSTGコマンドの実行にかかる時間を削減することができました。RCLSTGコマンドがシステム保守や問題の回復に必要な時間が短縮され、手間もかからなくなることを考えるとこれは大きな改良といえます。

V5R4におけるRCLSTGコマンドの強化のもう1つはESTIMATEという新しいパラメータです。その名前から想像できる通り、このパラメータを使用すると特定のRCLSTGコマンドの実行にかかると思われる時間を予想することができます。たとえば、RCLSTG ESTIMATE(*YES) SELECT(*DIR) ASPDEV(*SYSBAS)と入力すると、システムと基本的なASP(図1)の*DIRタイプのRCLSTGコマンドを実行するのに必要と思われる時間を予想してくれます。この予想時間はシステムの可用性に影響しません(つまりシステムを制限された状態にする必要はありません)し、実際に再利用を実行するわけでもありません。唯一の問題点は今まで同じパラメータで実行されたRCLSTGリクエストの統計情報を使用してこの予想時間を決定しているという点です。つまり、ESTIMATEパラメータを使用するにはそれ以前に少なくとも1回はRCLSTGコマンドを実行していなければならないということになります。また、使用されているシステム記憶域が、今までのRCLSTGコマンドの予想に使用されたときの記憶域に似ていれば似ているほどこの予想時間の精度が高まります。使用されている記憶域に大きな変更があった場合は予測時間の精度が低下する場合があります。

またRCLSTGコマンドの新しい実行画面(図2)は、時間予想の一部としてではなく、実際にRCLSTGコマンドを実行したときに表示されます。この画面には既に完了した再利用のステップと未完了のステップおよびその完了までの各ステップの進行状況が一覧で表示されます。表示される情報はRCLSTGリクエストの進行状況をトラッキングするのに有用で、再利用処理が完了するまでに非常に時間がかかる場合に特にこの情報は貴重です。

IFS再利用の詳細についてはV5R4情報センターのサイト(publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp)をご参照ください。このサイトにはRCLLNKコマンドとRCLSTGコマンドの詳細な比較やRCLLNKコマンドの使用例が記載されています。このサイトアクセスするには、[Files and file systems]-[Integrated file system]-[Reclaim operation of the "root" (/), QOpenSys, and user-defined file systems]を選択してください。

IFS再利用の使用方法

IFSの再利用といえば、予防策に優る薬はありません。つまり、IFS再利用を必要とするような問題の予防および回復を図るには、定期的にバックアップを取ったり、常に最新のPTFを適用したり、古くなったあるいは動作が怪しいハードウェア(特にハードディスク)を交換するなどの措置を取っておくのが賢明ということです。こうした手段を取っておけばIFS再利用を必要としないシステムにできるという保証があるわけではありませんが、役には立ちます。ではIFS再利用を実行すべき時とはどんな時なのでしょうか。IFS再利用を検討すべき状況の例を以下にいくつかご紹介します。

・ 定期的なシステム保守の一部として: システムを制限された状態にする必要がないため、月次のシステム保守の際にRCLLNKコマンドを使用して問題を早期に発見して修正することができます。また、RCLSTGコマンドをシステム保守の一部に取り入れることもできます。このアプローチは必ずしも必要ではありませんが、RCLSTGコマンドを使用するのであればRCLLNKコマンドを使用する頻度よりは少なくて(年に1度程度)良いでしょう。

・ i5/OSをアップグレードする前: i5/OSの新しいリリースにアップグレードする前にRCLSTGコマンドを実行しておくのは賢明です。こうすることでアップグレード前にシステムをクリーンな状態にしておくことができます。

・ ハードウェア障害の発生後: ハードウェア障害(特にハードディスクの障害)が発生するのは稀ですが、発生するとIFSオブジェクトの破損の原因となります。ハードウェア障害を識別するにはQSYSOPRメッセージ・キューを表示してCPP1604 (*Attention* Impending DASD failure)などといったメッセージが出ていないか確認したり、専用サービス・ツール(DST: Dedicated Service Tools)やシステム・サービス・ツール(SST: System Service Tools)で製品アクティビティ・ログ(PAL)を表示したりして同様の障害の兆候がないかを確認します。ハードウェア障害の疑いが見つかった場合は、IBMのサービス担当者に連絡してください。さらに慎重にしておきたいのであれば、ハードウェア障害回復の一部としてIFS再利用を実行しておくのも良いでしょう。まずRCLLNKコマンドを実行すれば大抵の問題は修正できます。RCLLNKコマンドだけでは修正できない問題がある場合、IFSオブジェクトが喪失した恐れがある場合、他のシステム全体にわたる問題がある場合は、RCLLNKコマンドに続いてRCLSTGコマンドを実行することもできます。

・ 特定のソフトウェア障害の発生後: ハードウェア障害と同様に、ソフトウェア障害やバグもIFSオブジェクト破損の原因となります。オブジェクトの破損も頻繁に発生するものではありませんが、PTFの表紙にバグ修正により破損の恐れがあるような記述があれば、そしてその破損によりシステムが影響を受けるようであれば、IFS再利用を実行する必要があるでしょう。ハードウェア障害の場合と同様にこのような状況に対処してください。

RCLLNKコマンドを使用する

RCLLNKコマンドはあらゆるIFS再利用の基点です(図3)。ただしRCLLNKコマンドを実行する前に問題となっているオブジェクト、スコープ、破損したオブジェクトの処理方法を決定しておかなければなりません。

IFS内で問題となっているオブジェクトは通常どのオブジェクトかわかっていることが多いでしょう。たとえば、特定のディレクトリにアクセスするためにアプリケーションがAPIを呼び出したところ、例外を起こしたり疑わしいエラー番号(たとえば3484 [EDAMAGE])に当たったりしたら、そのディレクトリのパス名(たとえば/MyOkDir/MyProblemDir)で問題となっているオブジェクトが識別できます。このパス名を次にOBJパラメータに指定します。ただし、問題となっているオブジェクトを識別できなかったり、RCLLNKコマンド全体を実行したいだけの場合は、汎用的なRCLLNK ('/') SUBTREE(*ALL)を実行してマウントされているすべてのファイル･システムに対してIFSオブジェクトを再利用することができます。

問題となっているオブジェクトを識別できたら、SUBTREEパラメータを使用して問題のスコープを識別してください。*DIRオプションを使用するとRCLLNKコマンドに対して問題となっているオブジェクトとそのコンテンツにスコープを当てるように指定でき、1つのディレクトリにまで特定できた問題を修正するのに役立ちます。*NONEオプションを使用するとRCLLNKコマンドに対して問題となっているオブジェクトそのものにスコープを当てるように指定でき、1つのファイル(つまりディレクトリではない)にまで特定できた問題を修正するのに役立ちます。最後に、*ALLオプションを使用すると、サブツリー全体の中で見つかったすべてのオブジェクトの問題をRCLLNKコマンドで修正することができ、1つのディレクトリやファイルに特定できなかった問題を修正するのに役立ちます。

これでオブジェクトとそのスコープが識別できたので、最後のステップでは破損したオブジェクトをどのように処理するかを決めます。RCLLNKコマンドを使用すると、DMGOBJOPTパラメータを使ってオブジェクトを削除したり(*DELETEオプション)、削除されたオブジェクトを保持したり(*KEEPオプション)することができます。デフォルトでは、使用可能な破損オブジェクトは保持され、使用不能な破損オブジェクトは削除されます。通常はデフォルト通りに処理するのがよいでしょう。ただしハードディスクの障害によりある程度の数のIFSオブジェクトが破損した場合、RCLLNK OBJ('/') SUBTREE(*ALL) DMGOBJOPT(*KEEP *KEEP)を実行して破損したすべてのIFSオブジェクトを削除せずに識別することができます。このオプションは破損をどのようにして回復するべきかを決める際に貴重な情報を提供できる場合もあります。破損したオブジェクトのバックアップ・コピーをメディアから回復する方法を取る場合、RCLLNK OBJ('/') SUBTREE(*ALL) DMGOBJOPT(*DELETE *DELETE)を使用して破損したオブジェクトを削除し、うまく回復させることができます。

これで再利用を実行する準備ができました。ところで再利用はすべてのオブジェクト(*ALLOBJ)に対して特別な権限を持っているユーザーだけが実行できます。RCLLNKコマンドが実行されている間に、ステータス・メッセージが画面の一番下に表示されコマンドの実行状況が確認できます(図4)。このステータス・メッセージは現在までに再利用されたオブジェクト・リンクの数、発見された問題の数、処理中のオブジェクトを示しています。一般的なパフォーマンスの目安として、RCLLNKコマンドは毎分6,000から17,000個のオブジェクト・リンクを再利用することができます。ただしこの個数はシステムのプロセッサの速度や利用可能な主記憶(つまりメモリ)によって変わります。また、RCLLNKはシステムが制限された状態にあることを必ずしも前提としていないので、システムのアクティビティのレベルによっても上記の個数は変わります。

RCLLNKコマンドが完了すると、再利用されたオブジェクト・リンク、再利用されなかったオブジェクト・リンク、発見されて修正された問題の数、が最終的に表示されるメッセージに表示されます。再利用できないオブジェクトがあった場合は、CPDA0B6 (オブジェクトの再利用不可)というメッセージがジョブ・ログに送信されます。これは通常オブジェクトが現在保存または回復されている途中、または再利用ができない状況で使用されている場合だけに発生します。修正できない問題を抱えているオブジェクトがある場合は、CPDA0B5 (問題修正不可)というメッセージがジョブ・ログに送信されます。メッセージに一覧されている回復の実行により問題の修正ができない場合は、通常はRCLSTGコマンドを実行する必要があります。そして最終的には見つかった問題が修正されれば、問題の内容と取られた措置を示す1つ以上のメッセージがジョブ・ログに送信されます。

RCLSTGコマンドを使用する

さてRCLSTGコマンドの話をする番になりました。RCLSTGコマンドはRCLLNKコマンドではうまくいかなかった場合に限ってIFS再利用をしなければならないとき(i5/OS V5R4以降)に必要となります。RCLSTGコマンドを実行する前にしておかなければならないことがいくつかあります。まずはRCLSTGコマンドのスコープを識別してください。RCLSTGコマンドはSELECT(*DIR)でIFSだけを処理すべきなのか、またはOMIT(*DIR)でIFS処理をスキップするべきなのでしょうか。あるいはSELECT(*ALL)としてすべてを対象とすべきなのでしょうか。RCLSTGコマンドの完全処理をしたい場合は、RCLSTG SELECT(*ALL) OMIT(*NONE) ASPDEV(*SYSBAS)とすればOKです。

次に、再処理の対象となるASPを識別する必要があります。対象となるのはシステムASPと基本ASPとASPDEV(*SYSBAS)であるのがほとんどです。ただしIASPオプションも利用可能です。

最後に、RCLSTGコマンドを実行するのに必要な処理時間を予想してダウンタイムを計算しておくのがよいでしょう。予想処理時間を使用してRCLSTGコマンドを使用する必要に迫られた問題を考慮することで、RCLSTGコマンドをすぐに処理すべきか、もう少し待ってユーザーへの影響を低減させるかを決めることができます。

さてRCLSTGコマンドを実行する段になりました。システムASPおよび基本ASP中のIFSオブジェクトのRCLSTGコマンドについての一般的な規則として、システムをIPLし、IPL直後にRCLSTGを実行し、再度システムをIPLするのが賢明です。この処理は必須ではありませんが、他のシステム・アクティビティがRCLSTGコマンドの処理と干渉しないことを確実にするためには役に立ちます。

一方、システムASPと基本ASP中のIFSオブジェクトのRCLSTGコマンドを実行する前に、システムを制限された状態にする必要があります。これにはENDSBSコマンドのSBSパラメータに*ALLを指定してENDSBSコマンドを実行することですべてのサブシステムを非アクティブな状態にする必要があります。ENDSBSコマンドは制御サブシステムの対話ジョブから実行しなければなりません。それは、システムが一旦制限された状態になるとほとんどのアクティビティが終了してしまうからです。さらに、すべてのネットワーク・サーバー記述(NWSD)とIASPもVARIED OFFの状態になっていないといけません。RCLSTGコマンドのセットアップに関するその他の要件や制限についてはRCLSTGコマンドのマニュアルを参照してください。

システムを制限された状態にすることについての詳細は、V5R4情報センターのサイトで[Systems management]-[Work management]-[Manage work]-[Manage subsystems]-[Placing the system in a restricted state]を選択してください。IASP中のIFSオブジェクトのRCLSTGコマンドを実行する場合は、そのIASPが「使用中」でないこと、利用可能または失敗のステータスになっていることが必須ですが、必ずしも制限された状態になっている必要はないこと、に注意してください。

RCLSTGコマンドを実行した後の重要な点についていくつか述べます。まず、RCLSTGコマンドはジョブ・ログ、またはQSYSOPRおよびQHSTメッセージ・キュー、あるいはその両方にメッセージを送信し、問題を発見して措置をとったことを知らせます。つまり、ジョブ・ログとQYSOPRおよびQHSTメッセージ・キューの両方をみて結果を判断することが重要です。次に、ある種の複雑な問題の場合、完全に修復するまでにもう一度RCLSTGコマンドを実行する必要があることがあります。別の言い方をすれば、最初のRCLSTGコマンドで問題が解決できそうにない場合、システムが既に制限された状態にあるうちにもう一度RCLSTGコマンドを実行しておく方が賢明でしょう。2回目のRCLSTGでも問題が解決しない場合は、IBMのサービス担当者に連絡をする必要があります。

必要なときにそこにある

幸いなことに、IFS再利用を必要とするイベントはほとんど発生しませんし、発生したとしてもごく稀です。歯医者の場合と同様で、行く回数が少ないに越したことはないので、ほとんど発生しないのは良いことです。ただし、IFS再利用をする必要が発生した場合は、本稿を参照していただくことでシステムの安定稼働を直ちに実現するのにお役に立てると思います。幸運をお祈りします。


免責条項: 本稿でご紹介したパフォーマンス・データは制御された環境下で特定のパフォーマンス・ベンチマークおよびツールを使用して計測したものです。パフォーマンスに関する情報は一般的な推奨事項と共に提供されているものであり、それによって読者の方がIFS再利用のパフォーマンスに関する理解を容易にするためのものです。上記以外の環境で得られたパフォーマンス結果は大きく異なる可能性があり、特定のお客様の環境を予測するためのものではありません。

本稿に述べられている情報は、IBMのいかなる正式なテストを受けたものでもなく、そのままの状態で配布されたものです。本稿でご紹介した情報を使用したりテクニックを実装したりすることはお客様の責任下で行なわれるもので、お客様の運用環境にこれらの情報やテクニックを評価、統合するのに必要なお客様の能力に依存します。IBMはそれぞれの状況における各項目に対する正確性を評価しているかもしれませんが、その結果が他の環境、状況下でも同じあるいは類似した結果となることを保証するものではありません。本稿で紹介したテクニックをお客様が試用される際には、お客様自身のリスクにおいて行なってください。

リチャード・ティーズ氏はIBMのソフトウェア・エンジニアで、i5/OSの統合ファイル・システム(IFS)の開発、テスト、サポートを担当しています。