サーバクラスタ設計における盲点（２）

前回の続き。
http://aikotobaha.blogspot.com/2010/06/blog-post.html

＊この記事は著者の経験則に基づく内容であり、一般的に公開されている内容とは異なる可能性があります＊

（ケース２）共有ストレージのコントローラ障害

前回同様の共有ディスクタイプのクラスタを想定します。基本的にこの構成であればほぼ全ての対して対応する事が出来る。

しかし障害からのリカバリ時に問題が発生するケースがある。クラスタでは障害発生時の事はしっかり想定するが、そこからリカバリする時に盲点が発生しやすいので注意しよう。

それが共有ディスクのコントローラが壊れた場合だ。稼動部が無く壊れにくいパーツな上、いくつかの要素が重ならないと発生しないので遭遇した事がある人はあまり多くないかもしれない。
しかし発生すると非常に厄介な障害となる。

当然、共有ディスクのコントローラが壊れても、大抵のストレージではコントローラは冗長化されているので問題無いはずだ。
しかしこの問題は壊れたコントローラを交換した後に発生する。

ストレージの中にはコントローラを交換するとWWNが変わってしまうストレージがある。

WWNが変わってしまうとどんな問題が発生するするのか？

まずOSが変更されたWWNを新しいドライブと認識してしまう可能性。これは特にマルチパスを構成していない場合に発生しやすい(ストレージにサーバを直結している場合等)
こうなるとディスクがクラスタ制御下から外れてしまいフェイルオーバー時のマウント/アンマウントの処理が出来なくなってしまう。

二つ目としてクラスタソフトやマルチパスソフトがリソースの制御に直接WWNを使っている場合、パーツを交換したのにいつまでも古いパスをチェックしてしまい、障害状態のままになってしまい。フェイルバック出来なくなってしまう。

この現象が発生してしまうと、状態を元に戻すの様々なオペレーションが必要になる上、構築テスト段階でこんなテストはやらない(できない)ので、復旧には時間がかかってしまう事が容易に想像できると思う（未経験のオペレーションなため）
また復旧するために変更を行えば当然ながら、簡易的なテストが必要になり、クラスタ環境なのにある程度の時間、システムが停止してしまう可能性もある。

こういったクラスタを組むという事はそれなりに重要度が高いシステムの可能性が高く、顧客への説明も一苦労となってしまう。

この現象は事前にいくつかの確認を行っておく事で回避出来るので事前チェックを怠らない様にしよう。

1. コントローラ交換時にWWNは変わるか？
これは完全にストレージの仕様になる。ある程度高価なストレージはWWNを自由に設定でき、保守員が交換後に元のWWNに設定してくれたり、このWWN設定を対向のコントローラが保持しており交換すると自動で元に設定されるモノもある。
こういったストレージあれば何も心配する必要は無い。
しかし世の中にはコントローラがを交換すればWWNが変わってしまうストレージも残念ながら存在する。その場合はに備えて2番目の確認。

2.クラスタ配下のディスクのWWNが変わってしまった場合の対処
これはOS/クラスタソフトによって状況が変わるので、つど必ずソフト提供元に確認をとっておこう。

　代表的な例を示すと、

ストレージを Veritas Storage Foundation（旧VxVM） や、dm-multipath配下に置いている場合はWWNの変更はほとんど影響しない。
この場合、VxVMやdm-multipathがデバイスを抽象化（/dev/vx/xxxxx, /dev/mpath/mpathXX）し、その配下のパスコントロールはWWNの変更を自動で検知し、動的にパスを組み替えてくれる。
そして上位のクラスタはこの抽象化されたデバイスに対して操作を行うため問題が発生しない。


しかし、マルチパスソフト無しでクラスタが直接 /dev/sdb 等を制御している場合はや、Windows で マルチパスソフトを使っていない環境でWWNが変わると、別のドライブとして認識してしまうので、対処が必要となる。
またマルチパスソフトの制御の仕方によってはNGなものも存在する。HP-UXのPV-LinkはWWNの変更には対処できない。これはOSが認識したデバイスファイル名を直接使って、マルチパスを指定するためだ（デバイスは抽象化されているのでクラスタの動作には問題は無いが、そのままだとマルチパスが復旧しない）

1番簡単なのは１の対処だ。これが一番安心で、夜間に障害が起きてもオペレーションのために呼び出される心配もない。
2の場合は、回復にオペレーションを必要とする場合が多く、大抵の場合はオペレータレベルでは対処できないことが多い。

可能な限り１で対処し、安眠できるシステムを構築しよう。

　またこのWWN変更問題はMACアドレスの変更（マザーを交換した場合にオンボードNICが影響を受ける）でも同じような現象が起きる可能性があるので注意しておこう。