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

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


（ケース３）ローリングアップグレードは計画的に


前回
（ケース１）内蔵RAIDボードの障害
（ケース２）共有ストレージのコントローラ障害


想定する環境は前回同様共有ストレージタイプのActive－Standbyクラスタ。


クラスタの利点でよく取り上げられるのが可用性と、ローリングアップグレードによる停止時間を最小限にしたアップグレード。ローリングアップグレードとは、


Standby側へパッチを当てやメンテナンス
↓
手動フェイルオーバー
↓
元Active側へパッチ or メンテナンス
↓
再度フェイルオーバー（しなくてもよい）


という手順を踏み、メンテナンスによる停止時間を最小限に抑える手法になる。


しかしローリングアップグレードは使えるケースが限られているので注意が必要。
その原因を考えるため、クラスタのレイヤを下記のように想像してみる。

１．アプリケーション（ミドルウェア）
２．クラスタソフト
３．OS（ファイルシステム）
４．マルチパス
５．共有ストレージ


このうち、３，４は二つのノードで独立しているが、２，５は二つのノードで共有されている。
当然、１のデータは共有ストレージに入っているわけだからリソースは二つのノード間で共有されていることになる。


例としてOracleのActive-Standbyクラスタを考えてみる。


１．へパッチ適用（Oracleへのパッチ）を当てようとすると、
Oracleのパッチは アプリケーションへのパッチ適用 → DBFのアップグレード という手順になるため、実質ローリングアップグレードはできない。
パッチを当てるためには共有ディスクへアクセスできる必要があるため、Activeなノードで無ければパッチが適用できないためだ。


２．へのパッチ適用（クラスタソフトのアップグレード）も注意が必要だ。
クラスタソフトはノード間の整合性を取るためにハートビート通信で互いの状態を常時やり取りしている。
パッチでこの通信の仕様が変わってしまう場合がある。
そうなってしまうと、パッチを当てた後にクラスタソフトを再起動してもハートビートが復帰できず、互いに相手が障害を起こしていると誤認ししてしまう。
これはかなりよろしくない仕様だが、こういう動作をしてしまうクラスタソフトを存在する。
またパッチの種別により、ローリングアップグレード可能か不可能かという情報をくれるメーカもあるので、作業前に必ず確認しておこう。


３．４については独立しているので基本的にはローリングアップグレード可能だ。
ただし、Windows MSCSは OSとクラスタが一体化しているので、パッチ適用前にMSへローリングアップグレード可能かどうかを確認しておこう。


パッチを当てるというのは本番運用後に発生する作業で、当然本番環境での作業に失敗は許されない。
必ずメーカサポートに確認したうえで、検証環境でのテストを行った後に作業をするように心がけよう。