2023.1.19
ジョブの投入、削除、実行順序などの管理を行なっている「ジョブスケジューラ」に障害が発生しました。
2023.1.10
以下の通りOmni-Pathネットワークに障害が発生し復旧しました。
１．期間
2023年1月7日(土) 16:00頃 から 1月10日(火) 11:00頃
２．対象
影響の確認された計算ノードは r2i1n[0-8], r1i0n3, r5i5n5 の11台
３．詳細
Omini-Path ネットワークの障害が原因と推測されるLustreError(ファイルシステムのエラー)が発生し、対象ノード上におい、ジョブスケジューラの応答不能、ユーザプロセスの残留等の問題が発生しました。1/10 10:53に通信異常の原因と推測される経路を無効にしたところ、LustreErrorが解消し始め、残留していたプロセスやジョブが順次終了されました。
４．影響があった可能性のあるジョブ(障害期間中に対象ノードで実行中だったジョブ)
下記の通り障害が発生し仮復旧しました。
１．概要
/gs/hs0の一部の領域へのアクセスが滞る。失敗する。
２．期間
2022年11月23日(水、祝日)13:00頃 から 24:00頃
３．詳細
11/23 13:00頃にLustreファイルシステム/gs/hs0の領域を構成するサーバの一つのOmniPathネットワークに障害が発生し、そのサーバで管理される領域にアクセス出来なくなりました。24:00頃にサービスのテイクオーバーが完了し、復旧しました。
４．影響があったジョブ
障害が影響した可能性の高いジョブは以下の通りです。以下の2628件のジョブの内、/gs/hs0領域を使用していたジョブに影響があったと推測されます。
2022.8.25
下記の通り障害が発生し復旧しました。
１．概要
・有償ジョブの投入に失敗する
・TSUBAMEポータルの操作が出来ない
２．期間
2022年8月21日(日)00:03頃 から 17:04頃
３．詳細
00:03頃にTSUBAMEポータルのデータベースサーバが応答しなくなり、ポータル・課金処理に関係する動作が行えなくなりました。データベースサーバの再起動により、17:04頃に暫定的な構成で復旧いたしました。本来の冗長構成に戻すため、9/7(水)にサービス停止を伴うメンテナンスを行います。
４．影響があったジョブ
下記の通り障害が発生し復旧しました。
１．概要
インタラクティブ専用キューが利用できない
２．期間
2021年10月21日(木)13:05頃 から 14:12頃
３．詳細
10/21 13:05頃に2台あるジョブ管理サーバのうちの1台(jobcon1)が応答不能になる障害が発生しました。本障害により、インタラクティブ専用キューが一時的に利用不可となりました。同13:31にサーバ本体のパワーサイクルを実施し、正常に起動した事を確認しました。HWチェック等を実施後、同14:12にインタラクティブ専用キューのジョブスケジューラを起動しサービスを再開しました。
４．影響があったジョブ
1005333, 1005345, 1005338 が期間中に実行されていましたが、各ジョブとも実行時間終了まで動作していた事を確認しました。
下記の通り障害が発生し復旧しました。
１．概要
/gs/hs1へのアクセスが滞る。失敗する。
２．期間
2021年5月22日(土)10:00頃 から 17:10頃 その後縮退中
３．詳細 (5/25追記)
5/22 10:00頃に/gs/hs1の領域を構成する、LustreファイルシステムにおけるOSSの一つであるossb0にて障害が発生しました。休日だったため16:35頃にossb0がハングしたような状況に至っていることを確認しました。障害が発生すると自動で検知しフェイルオーバー処理が行われますが、ossb0が完全にダウンとならず、かろうじて稼働しているような状態となっていたため、フェイルオーバーが作動しておりませんでした。
2020.9.10
下記の通り障害が発生し復旧しました
１．概要
/gs/hs0へのアクセスが滞る。失敗する。
２．期間
2020年9月8日(火)11:15頃 から 14:00頃、 ログインノード は17:25頃、 一部の計算ノードは9/9 13:15頃
３．詳細(9/18掲載)
9/8 11:15頃に /gs/hs0 へのアクセスができなくなりました。調査したところ、lustre thread処理の滞留が確認されました。
復旧のため、LustreファイルシステムにおけるMDSの一つであるmdsa0、OSSの一つであるossa1を強制再起動しました。その際に実行中だったI/Oは通常、再起動後のrecovery処理で再実行されますが、今度はrecoveryが完了しない事象が発生しました。
recoveryが進まないため、手動で処理をabortし、14:00頃にストレージが復旧しました。abortした結果、実行中のI/Oには全てI/Oエラーが返されました。
2020.2.20
以下の通り、ジョブの投入、削除、実行順序などの管理を行なっている「ジョブスケジューラ」に障害が発生しました。ジョブスケジューラは復旧しておりますが、再発防止のための修正は年度末メンテナンス頃となる見通しです。
１．期間
2020年2月15日(土) 7:03頃 から 11:50頃
2020年2月20日(木) 10:16頃 から 10:22頃
２．影響
上記時間帯にログインノードからジョブの投入・確認ができなくなりました。なお、既に実行されていたジョブに関しましては影響はなく、未使用のポイントについても順次返却が行われました。
３．原因と回避策
ジョブスケジューラが動作する、2台で冗長化されたホスト jobcon0, jobcon1 で、そのマスターデーモンである sge_qmaster が複数回クラッシュしました。クラッシュ後、スケジューラはフェイルオーバーされ、自動復帰致しました。
2020.2.7
一部のジョブにおいて、実行後に仮押さえ(*1)られたTSUBAMEポイントの精算処理(*2)が正しく行われずに、ポイントが全て返却される不具合が利用者からの報告で発覚しました。
（実行時間にかかわらずジョブのポイント消費量が0ポイントとして処理されるケースがありました)
*1…ポイント消費量はジョブの終了後、その実行時間によって最終的に確定しますが、ジョブ投入時にその指定したパラメータから起こりうる最大のポイント消費量分をあらかじめポイント残高から差し引きます。
*2…仮押さえポイントと実際に消費したポイントの差額を返却します。この処理は場合により最大3日程度かかる場合があります。
■影響範囲
履歴を調査したところ、同様の問題があった可能性のあるジョブが2020年1月においては約27,000件 (当月の全ジョブの15%程度) 存在することがわかり、それ以前(前年度までを含む)にも同様のケースが少数ながら存在することが分かりました。
2019.10.17
以下の通りLDAPサーバに障害が発生し各サービスに影響が発生し復旧しました。
１．期間
2019年10月17日(木) 13:20頃 から 14:40 頃
２．内容
loginノードにアクセスできないアラートを元に不具合の調査を開始したところ、13:21頃にLDAPへの通信がタイムアウトしていることが確認れました。login1を再起動するも症状が改善されないため、LDAPサーバを確認したところslapdの負荷が異常に上がっていることが確認されました。同14:39にslapdのサービスを再起動し、状況が改善したことを確認しました。
３．影響
ログインノード ：login0, login1にログインできませんでした。また復旧作業の中でlogin0を再起動しました。
計算ノード：認証に失敗し計算に失敗した可能性があります。影響があった可能性のあるジョブIDは最下部に掲載します。
TSUBAMEポータル：確認中
その他のシステム：確認中
４．原因と対策
調査中