こんにちは。IBM Technology Expert Labs 小川です。
本日はIBM Storage Scaleを運用している、または運用者に技術支援を提供している方向けに、障害対応の流れをお伝えします。いざ障害が発生した場合にどう動くべきか？という点を把握しておくことで早期の解決に繋がりますので、是非このブログを一読して頂ければと思います。
1. 障害対応の流れ
障害が発生した際の対応フローはもちろん場合にもよりますが、基本的な流れは以下のとおりです。
本ブログではこのフローをベースにご説明していきます。
2. 各障害対応の内容
① 重要度確認
障害発生時にはまず障害の重要度を確認します。この重要度の決定は非常に大切で、特に障害の数が多い場合に障害を管理する意味があります。
もちろん全ての障害はなるべく早く解決したいというのがお客様の希望なのですが、リソースが限られる現実では障害を適切に管理することが必要となってきます。
(参考：サービスレベル・ガイドライン-重要度)
| 重要度 |
障害内容 |
対応目安 |
| 1 |
システムまたはサービス停止 |
復旧まで |
| 2 |
サービスの使用が大幅に制限 |
2営業日内 |
| 3 |
運用に重大な影響がない |
5営業日内 |
| 4 |
問い合わせ等 |
10営業日内 |
② gpfs.snap / 環境情報取得
ケース作成に必要な以下の情報を取得します。
(参考：Spectrum Scale初期資料収集ガイド)
- gpfs.snap
- NSDノードのOSとそのバージョン
- 事象発生ノードとファイルシステム
- 発生した事象の詳細 (事象の発生時刻、頻度、再現性も含む)
- 問題発生前後で変更作業等を実施している場合はその詳細
③ ケース作成
IBMサポートに障害を解析してもらうため、サポート契約があるお客様のIBM IDでIBM Supportのウェブサイトからケースを作成します。ケースの作成方法はこちらの「ケースを開く方法」を参照下さい。
障害の重要度が1の場合は即対応が必要のため、0120-557-971へ電話(日本語可)します。その際に必要な情報は以下の通りです。
- 7桁のお客様番号
- ソフトウェアの名前、エディション、バージョン
(例：IBM Storage Scale Data Management Edition v5.1.9.1)
- OSの名前、バージョン
(例：Red Hat Enterprise Linux 9.3)
④ gpfs.snapアップロード
ECuRepからgpfs.snapをアップロードします。アップロード方法はこちらの「IBMサポートへHTTPSで資料を送付する手順」を参照下さい。
ひとまずこれでIBMサポートが障害を解析する準備が整いました。ここまでが最低限です。
しかし障害を早期に解決するためには、IBMサポートと情報を連携しながら進める必要があります。
⑤ エラーログ確認
障害のエラーログとその前後のログを確認します。エラーログが不明な場合は障害発生時刻を手掛かりにエラーログを探します。よく対象となるログは以下です。
- OSのシステムログ：/var/log/messages
- Scaleのログ：/var/adm/ras/mmfs.log.latest
- Scaleのシステムモニターログ：/var/adm/ras/mmsysmonitor.log
- NFSのログ：/var/log/ganesha.log
⑥ 対象を絞る
ログや状況から、障害に関連すると思われるコンポーネントを絞ります。コンポーネントには以下のようなものがあります。
- Scaleファイルシステム
- NFS
- SMB
- Object
- AFM
- GUI
- Audit Log
- 認証
- 圧縮
- 暗号化
- ...
⑦ ログと設定確認
対象コンポーネントに関連するログを、障害発生時刻を手掛かりに再調査します。また関連しそうな設定値についても確認します。設定値は以下のコマンドで確認できます。
- Scaleの設定：/usr/lpp/mmfs/bin/mmlscofig
- NFSの設定：/usr/lpp/mmfs/bin/mmnfs config show
- SMBの設定：/usr/lpp/mmfs/bin/mmsmb config show
- OSのシステム設定：sysctl -p
⑧ 関係図の作成
ログ解析やサポートからの回答を元に、対象コンポーネントの関係図を作成します。これにより怪しいポイントやどの資料を追加で取得すべきかが分かりやすくなります。ただしこの関係図はサポートから提供されるわけではないので現場で作成する必要があります。
例えば下図はNFSv3のロック関連の図です。
⑨ 推論作成
これまでの調査とIBMサポートからの回答から推論をいくつか作成します。
⑩ 追加資料取得
推論を裏付けるため、またより詳細な調査のために必要な追加資料を作成します。
また、推論すらできない場合は、ヒントを求めて広範囲で追加資料を取得する場合もあります。
よく取得する追加資料は例えば以下があります。
- tcpdump：ネットワークが関連している場合に取得します。
- Scaleトレース：Scale内部の詳細なデバッグログが必要な場合に取得します。
- プロトコルトレース：SMB、winbind、オブジェクト、ネットワークの詳細なログが必要な場合に取得します。
- NFSログレベル変更：NFSが関連している場合にログレベルを変更して詳細なデバッグログを取得します。
この後はサポートとのやりとりや資料取得を繰り返しながら障害解析を進めていく形となります。
3. まとめ
いかがでしたでしょうか。Scaleは構造が複雑なアプリケーションということもあり、障害対応で苦労された方も多いと思います。本ブログの内容が皆様の障害解決のヒントになれば幸いです。