IBM AIX MPIO

このドキュメントは、IBM AIX MPIOの2018/12/27時点での内容を翻訳したものです。更新の有無や内容の確認のためには、最新の英語バージョンを参照してください。

IBM Power Systems™ は、業界でトップレベルの高い可用性を、単体で提供できるようにデザインされています。企業は、しばしば新しいITに対する要望を満たすためのインフラ再構成や、計画的な停止（例えばシステムの計画保守）に対応しなければなりません。

これまで、MPIOのベスト・プラクティスは正式には文書化されていませんでした。いくつかのドキュメントやIBM Redbooks® には、特定のシナリオと環境を前提にしたMPIOに関する概念の簡単な記述はありました。しかし、一般的な意味でのMPIOの構成に対する推奨はありませんでした。

それぞれのシステム構成において、変更可能な設定値を十分に検討することで、システムの信頼性と可用性が向上します。この記事は、構成に関するベスト・プラクティスとして、AIX MPIOに関する考慮点を説明します。

この記事の中で述べられている幾つかの機能は、ある特定のAIXテクノロジー・レベルや、AIXで提供されるパス制御モジュール(Path Control Module: PCM)のみに当てはまります。Subsystem Device Driver Path Control Module (SDDPCM) や、ベンダーが提供するオブジェクト・データ・マネージャ(Object Data Manager: ODM)パッケージ（通常、ホスト接続キット 等の名称で参照されます）を使用している場合は、ここで述べられている幾つかのオプションは使えない、あるいは別のオプションが用意されていることがあります。

AIX MPIOインフラは、IBMやサード・パーティのストレージ・ベンダーがODM定義を提供できるようになっています。ディスクの重要な属性に対して、それら固有のデフォルト値がODMに設定されます。例えば、hdiskとして表現されている論理ユニット番号（Logical Unit Number: LUN）のデフォルト属性値は、IBM System Storage® SAN Volume Controller (SVC) とIBM System Storage DS8000® では異なっているかもしれません。このようなデフォルト属性値は、ほとんどの状況においてをそのまま使用することができます。一般的に、hdiskの属性はデフォルト値をそのまま使用すべきです。この記事の中で触れられていない属性では、その傾向が顕著です。

以降のセクションで説明するディスク属性は、lsattr コマンドで表示することができ、chdev コマンドで変更することができます。パス属性、例えば path_priority は lspath と chpath コマンドによって表示や設定ができます。これらのコマンドの詳細については、AIXの資料やAIXのman pageの出力を参照してください。

この記事は、MPIOデバイスの接続に使用するアダプターに関連する属性はとりあげません。これらの属性のうちいくつかは、エラー検出や回復時間に影響を与えることがあります。特に、ファイバー・チャネル・アダプターの fc_err_recov 属性は重要であり、考慮すべきです。

考慮事項 1：MPIOアルゴリズムとpath_priority

MPIOアルゴリズムの設定は、以下を行うかどうかを決めます：

• あるLUNに対して、PCMが全てのパスに渡ってI/Oを分散するように試みる
• 一時点に1パスだけでI/Oを行う
• アルゴリズムの設定とディスク毎の path_priority 設定の組み合わせで、I/Oで使用するパスに重み付けをする

複数のコントローラーを持つデバイスでは、1つのコントローラーをアクティブあるいは優先的コントローラーに指定できます。このようなデバイスでは、アクティブあるいは優先的コントローラーへのパスのうち、少なくとも1つがenabled状態であり、それがfailed状態になっていなければ、PCMはこのパスを使います。したがって、全ての利用可能なパスを使うアルゴリズムでも、このようなデバイスでは一時点で一部のパスだけが使われることがあります。

algorithm = fail_over

AIXに含まれるODM定義を用いるディスクのほとんどは、このアルゴリズムをデフォルト値としています。サードパーティが提供するODMには、異なるデフォルト値を使用するものがあります。

このアルゴリズムでは、一時点で1つのパスを通してのみI/Oが行われます。algorithm=fail_over では、PCMは使用可能なパス(ディスク毎)を順序付きリストで管理します。もしI/Oを行なっているパスに障害が発生したり使用不可になると、リストの中の次のパスが選ばれ、I/Oはそのパスで行われます。リストの中のパス選択順序は、それぞれのパスの優先順位（path priority）属性を変更することでカスタマイズできます。リストはパスの優先順位で昇順にソートされます。

バーチャルI/Oサーバー(VIOS)のクライアント上の仮想SCSI(VSCSI)ディスクでは、fail_over アルゴリズムを常に使用します。これはVIOSインスタンス上の実デバイスが、仮に round_robin を使用している場合でも同様です。SCSI−2予約機能 (reserve_policy=single_path)を使用する場合には、fail_over が唯一使えるアルゴリズムとなるでしょう。

algorithm = round_robin

このアルゴリズムでは、ディスクへの全ての使用可能なパスを利用し、分散してI/Oを行います。各パスに対するI/Oの比率は、各ディスクの各パスに対する path_priority 属性の設定で重み付けられます。もしパスに障害が起きたり、使用不可になった場合、そのパスはI/Oで使用されなくなります。残ったパスを利用するI/Oの比率を決めるために、優先順位が再度計算されます。もし全てのパスが同じ path_priority 値にセットされた場合、PCMは全ての使用可能なパスにI/Oを均等に分配 しようと します。パス障害が発生した時でも最適なパフォーマンスを発揮するには、パスの順序付けに、異なるファブリックのパスを交互にリストするようにしてください。

algorithm = shortest_queue

このアルゴリズムは、最新のAIXテクノロジー・レベルで、いくつかのデバイスに対して利用可能となりました。負荷が小さい時、このアルゴリズムは round_robin と似た動きをします。負荷が増えると、このアルゴリズムはアクティブなI/O処理が最も少ないパスを優先します。このようにして、ストレージ・エリア・ネットワーク(Storage Area Network: SAN)の輻輳によって特定のパスが遅くなったら、より多くのI/O操作ができるように、輻輳が発生していないパスを選択します。 *このアルゴリズムでは、path priority値は無視されます。

（* 訳注：以降の本文中に同様の表現がありますが、これは2019年7月末時点でEnd of Service pack Supportを迎えていないレベルのAIXテクノロジー・レベルを指します）

推奨 : SCSI-2予約機能やvSCSIディスクを使用している場合は、fail_over を使う必要があります。それ以外の場合は、shortest_queue (利用可能な場合)、あるいは round_robin を使うことでSANリソースを最大限に活用できます。

考慮事項 2: パス・ヘルス・チェックの設定

パス・ヘルス・チェック・モード (hcheck_mode)

MPIOのパス・ヘルス・チェック機構は、パスの利用可能性を通常稼働中に確認します。どのパスに対してヘルス・チェックを行うかは、パス・ヘルス・チェック・モードで決まります。ヘルス・チェック機能は Disabled あるいは Missing 状態のパスに対しては、確認を行いません。これら2つ状態のパスは、chpath (Disabled状態のパス)あるいは cfgmgr (Missing状態のパス)を用いて、手動で回復しなければなりません。 ディスクがオープンでも使用中でもない場合、例えばボリューム・グループがvary offされているようなケースでは、そのディスクへのどのパスに対しても、ヘルス・チェックは行われません。

MPIOパス・ヘルス・チェック機能には3つのモードがあります。

hcheck_mode = nonactive : このモードでは、PCMはアクティブなI/Oが無いパスに対してヘルス・チェック用コマンドを送信します。これには、failed状態のパスも含まれます。failoverがアルゴリズムとして選択されていれば、enabled状態でアクティブI/Oの無いパスに対しても、ヘルス・チェック用コマンドが送信されます。もし round_robin あるいは shortest_queue がアルゴリズムとして選択されてれば、failed状態のパスに対してのみヘルス・チェック用コマンドが送られます。これは、round_robin と shortest_queue アルゴリズムでは、ディスクが使用中ならば、全てのenabled状態のパスにアクティブなI/Oがあるからです。もしディスクがアイドルならば、仕掛かり中I/Oが無いどのパスに対しても、ヘルス・チェック間隔毎にコマンドが送られます。

hcheck_mode = enabled : このモードでは、全てのenabled状態になっているパスに対して、PCMはヘルス・チェック用コマンドを送信します。これは、ヘルス・チェックの際に、該当パスにアクティブなI/Oがある場合でも、同様に行われます。

hcheck_mode = failed : このモードでは、failed 状態になっているパスに対してのみ、PCMはヘルス・チェックを行います。

推奨 : 全てのデバイスでデフォルト値はnonactiveです。ビジネスあるいはアプリケーション要件に起因する指定がない限り、この設定を変える必要はほとんどありません。

パス・ヘルス・チェック間隔 (hheck_interval)

パス・ヘルス・チェック間隔は、MPIOパス・ヘルス・チェック機能による確認間隔を秒単位で指定します。MPIOの hcheck_mode 設定に従って、オープン状態のディスクへのパス利用可能性を確認します。

hcheck_interval = 0 を設定すると、MPIOによるパスのヘルス・チェック機構を無効化します。その結果、failed状態のパスを有効化するためには、マニュアル操作による対応が必要となります。

推奨 : hcheck_interval に対するベスト・プラクティスとしてのガイドは、対象となるディスクの rw_timeout (read/writeタイムアウト)以上の値をセットすることです。また、ヘルス・チェック間隔を短くするために、rw_timeout を短く設定することは推奨 できません。 ODMに設定されているデフォルトの rw_timeout 値は、デバイス製造会社による該当デバイス類の推奨値に基づいています。以下のセクションで、ベスト・プラクティスとしての推奨を技術的に説明します。

障害パスを早く検知し回復できるかもしれないので、もしかすると、ヘルス・チェック間隔を短くする方が良いと考えるかもしれません。しかし、短いヘルス・チェック間隔を設定することの弊害は、その利点をはるかに上回ります。そこにはいくつかの理由があります。

• 全てのオープン状態のディスクへの全てのパスに対して、ヘルス・チェック間隔毎にヘルス・チェックのためにコマンドが送られます(hcheck_mode の設定に依存します) 。このため、大量のディスクがある場合、短いヘルス・チェック間隔を設定すると、SANの帯域幅を容易に使い切ってしまいます。

• ヘルス・チェック用コマンドは、ディスクのqueue_depth (ストレージ・ベンダーの推奨がある時のみ変更すべき値です)に対して負の影響を及ぼします。ヘルス・チェック用コマンドは、通常のI/Oより高い優先順位で受け付けられます。エラー発生時の動作は、パスが正常時の動作よりも、通常長くかかります。したがって、いくつかのパスで障害が発生している状態で短いヘルス・チェック間隔を設定すると、正常なパスでのユーザーI/Oに対して悪い影響を与える可能性があります。ここで、queue_depth はディスク・ドライバーの機能なので、queue_depth はLUN毎の設定であり、パス毎の設定ではないことに注意してください。例えば、あるデバイスの queue_depth が8で、8つのパスがあるとします。仮にこれらのうち4つのパスで障害が発生したとすると、これらのパスに対するヘルス・チェックが失敗するまでに、数秒から最大 rw_timeout 値の時間がかかります。この間、queue_depth 内では、少なくとも8つのコマンドのうち4つがヘルス・チェック用コマンドに使用されます。この結果、queue_depth のうち、4コマンド分だけが、このディスクに対する正常なパスでの通常I/Oに使われます。

• パスの回復は、素早く行われることが常に良いというわけではありません。リンクに対する障害が繰り返し間欠的に発生する状況を想定してみましょう。ヘルス・チェックでリンクが素早く回復すればするほど、より多くのユーザーI/Oが間欠的なエラーのために失敗することになります。より長いヘルス・チェック間隔ならば、頻繁に間欠的な障害が発生するようなリンクの使用を減らせます。

• 必要があれば、AIXは最後の手段としての緊急パス回復のヘルス・チェックを行います。あるデバイスへのパスのうち、failed状態ではないパスが1個しかない場合を想定します。最後のパスでエラーを検知すると、AIX はI/Oリトライの前に、全てのfailed状態のパスに対してヘルス・チェックを行います。これはヘルス・チェック間隔の設定に関係なく行われます。このおかげで、パスを早く回復する目的で、ヘルス・チェック間隔を短く設定する必要は無くなります。もし一つでも正常なパスがあれば、ヘルス・チェック間隔の設定に関係なくAIXはそのパスを検知し、ユーザーI/Oが失敗する前にそのパスを使用します。

最新のAIXテクノロジー・レベルでは、AIXはファイバー・チャネル(Fiber Channel: FC) デバイス・ドライバーからの非同期イベントを活用して、パスの状態を操作します。ファイバー・チャネルを使用している場合は、AIXはパス障害検知やパスの回復におけるヘルス・チェックへの依存度を減らしています。

ほとんどの場合、デフォルトの hcheck_interval 値は適切です。かつては、ストレージ・ベンダーが提供するODM定義で、hcheck_interval が rw_timeout 値より小さく設定されたものがありました。AIX開発部門からの前述の推奨は、このような場合を想定しています。すなわち「hcheck_interval を rw_timeout 以上になるように増やしてください」通常、ヘルス・チェックの間隔は、減らすよりも増やす方が良い結果になります。hcheck_interval が該当ディスクの rw_timeout 値より少しだけ大きい時に、良いパフォーマンスが得られます。

上記2と3番目で述べた状況の極端なケースが起きると、もしヘルス・チェック間隔を小さい値にセットした場合、I/Oパフォーマンスの重大な低下を招く恐れがあります。

考慮事項 3: タイムアウト・ポリシー

最新のAIXテクノロジー・レベルでは、いくつかのデバイスに対して timeout_policy 属性が使えます。この属性は、コマンド・タイムアウトの発生時にPCMが取るべきアクションを指定します。該当ディスクの rw_timeout に指定されている時間内に、I/Oが完了しなければ、コマンドはタイムアウトします。timeout_policy には3つの設定が可能です。

timeout_policy = retry_path : これは旧来の動作を指定します。つまり、コマンド・タイムアウトが起きた同じパスで、コマンドのリトライを行います。この場合、高い可能性でI/Oの回復で遅延が発生します。なぜなら、このパス上でコマンドは失敗し続ける可能性が高いからです。数回の連続した失敗を経て初めて、AIXはパスを障害と見なし、別のパスでI/Oを試行します。

timeout_policy = fail_path : この設定では、一回のコマンド・タイムアウトだけで、AIXはパスを障害と見なします。ただし、デバイスに対して、failed状態ではないパスが少なくとも1つ存在していることが前提です。パスの障害によって、I/Oは異なるパスで再試行されます。これは、コマンド・タイムアウトからのいち早い回復や、デバイスへの全パスがfailed状態である状況のいち早い検知を可能にします。タイムアウト・ポリシーによって障害と見なされたパスは、AIXが後で行うヘルス・チェックで回復可能です。ただし、パスが回復した後でも、AIXはユーザーI/Oを一定期間行いません。これは、該当パスで継続的な障害が発生していないことを確実にするためです（他のPCMでは、このようなグレース期間を実装していないかもしれません）。

timeout_policy = disable_path : この設定では、コマンド・タイムアウトが起きたパスはdisabled状態になります。disabled状態のパスは chpath コマンドによってのみ回復します。

推奨 : デバイスにおいて fail_path が利用可能ならば、fail_path が推奨の設定です。

考慮事項 4: AIX MPIOで構成すべきパスの数

MPIO構成においては、多ければ多い ほど 良い ということは、必ずしも当てはまりません。 実際、MPIO構成であまりにも多くのパスがあると、SAN、ストレージ、あるいはファイバー・チャネル・ファブリックの問題や障害が発生した時に、システムやアプリケーションのパフォーマンス低下につながる可能性があります。

MPIO環境でパスを構成する時の一般的な推奨値は、LUNあたり4から8です。多くても16パスですが、これは特殊なケースでのみ使用されるものです。MPIOで8や16以上のパスが使えるという事実は重要ですが、デザインと機能の観点で言えば、4から8パスが最も効果的です。

LUNあたりのパスを8より多く設定しなければならない要件がある場合、以下のような点を慎重に考慮する必要があります:

1. MPIOディスクでエラーが発生すると、構成されている全てのパスに対してエラー回復処理が行われます。ディスクやSANのエラーが起きると、失敗したI/O毎にそれぞれのパスで 複数回のリトライを試行します。 ”N”個のパスがあると仮定します。1つのディスクでエラーが発生し、それが各パスに対して5回のリトライを行うという状況は、普通に起こりえます。そこに、該当ディスクの rw_timeout が掛け合わせられます。I/Oあたり の合計回復時間は、以下のようになる可能性があります: (N ∗ rw_timeout 値 ∗ 5) もし複数のディスクで同様の事象が同時に起きると、アプリケーションにとって影響は甚大になるでしょう。例えば、不安定なSANファブリックがあるとすると、このようなタイプのエラー回復処理になるかもしれず、その場合は、深刻なパフォーマンス低下が発生します。 この状況は timeout_policy 属性を fail_path に設定することで緩和できます。もちろん、使用しているデバイスのタイプでこの属性が利用可能であることが前提です。ただし、timeout_policy 属性で全ての起こりうるエラーのシナリオをカバーできるわけではありません。
2. round_robin アルゴリズムの場合、PCMが沢山のパスの中でロードバランスを行おうとするので、パスが多すぎるとオーバーヘッドを引き起こします。
3. fail_over アルゴリズムの場合、パス障害時の動作としてフェイルオーバー先のパスを決めるために、PCMにさらなるオーバーヘッドが発生します。
4. パスを構成すると、MPIOデバイス・ドライバーに該当パスのデータ構造を保持するため、メモリー領域が必要となります。大量のディスクに対して過剰なパスを定義すると、アプリケーションが稼働するシステムで利用できるメモリー量が少なくなる可能性があります。
5. 前述のように、ヘルス・チェック用コマンドは、デバイスのqueueに対して負の影響があります。このように、大量のパスがあるデバイスでは、ヘルス・チェック処理による影響が大きくなります。queue depth値が小さいデバイスで、 failed 状態のパスがある場合に、特に顕著になります。

AIX上に定義されたデバイスで4パスがある場合の最適な構成は、ストレージへの4つの物理パスに対して、ホスト側のホスト・バス・アダプター(HBA)ポートとストレージ側のポートを1：1の関係にすることです。AIXホスト側に複数ポートのアダプターを用いている場合は、冗長性を最適に保つため、少なくとも半分を異なる物理アダプターに分散させます。AIXとデバイス間は、1つのFCスイッチあるいは同一ファブリック内の2つの異なるスイッチに接続することが出来ます。2つのスイッチを使用している場合は、単一障害点はありません。しかし、ある種のスイッチやポートの障害は、SAN全体に影響を与え、4つのパス全部に影響を及ぼすことがあります。

8パス構成があるとすれば、2つの別個のSANファブリックを使って完全な冗長性を実現するケースです。AIXノードとストレージ・デバイスで各2ポートずつを2つのSANファブリックに接続します。合計するとAIXに4ポート、ストレージ・デバイスに4ポートが使用され、全体で8パスとなります。このようにして、どちらのSANファブリックにも単一障害点が無く、さらにSANファブリックそのものも冗長化されます。（注意：これは単なる例です。2つのファブリックとLUN毎に4パスを使用しても、完全な冗長化を実現できます。）

8を超えるパスを用いる唯一のケースは、コントローラーがクラスター化されている特別なストレージ装置や、ピア・ツー・ピア リモートコピー(PPRC)を行う装置を使用する場合です。 例えば、2つのDS8000装置上にIBM HyperSwap® ペアのLUNがhdiskとして見えているとします。それぞれのDS8000システムを用いてHyperSwapペアを作り、上述の8パス構成が行われると、16パスになります。2つの8パスhdiskが1つのHyperSwap化されたhdiskとして構成された場合、全体では16パスとなります。

ここで説明したケース以外でも、構成として可能なものはあります。しかし、上述のように、8パスを超えると、役立つよりも問題が内在する可能性が高くなるので、慎重に考慮すべきです。

推奨 : ディスクあたり4あるいは8パス、あるいは稀なケースとして最大16パスで構成します。パスを増やす前に、必要以上の冗長性が起こす影響を慎重に検討する必要があります。

考慮事項 5: 運用上の考慮点

計画保守: AIX MPIOには強力なエラー検知と回復機能があります。しかし、このエラー検知と回復にはそれなりの時間がかかることがあり、そこで生じる遅延はアプリケーションに影響を与える可能性があります。SANやストレージ装置に対して計画保守が予定されているならば、まず保守によって影響を受けるディスクへのパスを特定します。そして、保守が始まる前に、rmpath コマンドでそれらのパスを使用不可にしておくことを考慮してください。こうすると、AIX MPIOは使用不可あるいは Defined 状態のパスは使用しないので、計画保守によって生じるエラー検知や回復は行われません。これにより、計画保守作業によって発生しうる不必要なエラー回復処理を、AIXは行わずに済みます。保守が完了したら、パスは cfgmgr によって再び使用可能となります（注意：複数LUNに対する複数パスを使用不可にする場合は、ディスク単位で実行する必要がないため、rmpath の方が chpath より簡単に利用できます）。

lspath コマンド(あるいは、最新のAIXテクノロジー・レベルでは lsmpio コマンド)を使うことで、SANポートに関連付けられているMPIOパスを特定することが出来ます。

属性値の変更: これまで、ほとんどのAIXレベルにおける大多数の属性の変更は、使用中でないデバイスに対してのみ可能でした。ディスクならば、クローズされていなければ属性を変更でききないということを意味しました（例えば、ボリューム・グループならばvary off）。rootvgを含むディスクのように、クローズすることができないディスクならば、-P フラグを chdev に付けて、属性の変更をODMに書き込み、変更を有効にするためにAIXを再起動しなければなりませんでした。

最新のAIXテクノロジー・レベルでは、ディスク属性は、 -U フラグが chdev コマンドでサポートされているものがあります。このフラグにより、chdev コマンドが属性値を動的に更新するので、ディスクをクローズすることなく属性値を変更でき、その変更は即時に有効になります。