下記の通り障害が発生し復旧しました。
１．概要
インタラクティブ専用キューが利用できない
２．期間
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ポータル：確認中
その他のシステム：確認中
４．原因と対策
調査中
2019.9.20
以下の通り計算ノードが停止し復旧しました。
１．期間
2019年9月19日(木) 14:08 から 翌9月20日(金) 10:00 頃
２．内容
9/9の障害から停止中だった冷却塔の2番機の復旧作業を進めたところ、全ての冷却塔が異常停止しました。その結果、同様に全ての計算ノードが停止し、合わせてTSUBAMEポータルも手動で停止しました。
その後、2番機の散水ポンプのリレー回路に損傷があることがわかり、2番機だけではなく3台全てのリレーを交換した上で、1番と3番機を再稼働し、冷却が安定したと確認できた、翌2019年9月20日 10:00に計算ノードの運用を再開しました。
2番機についてももう問題はないものと思われますが、再稼働は11月実施予定の計画メンテナンス時に行う予定です。
３．影響があったジョブ
2019.9.20
以下の通り計算ノードが停止し復旧しました。お知らせへの掲載が遅くなり大変申し訳ございません。
１．期間
2019年9月9日(月) 4:56 から 翌9月10日(火) 9:00 頃
２．内容
2019年9月9日の4時56分頃、台風の影響により屋上冷却塔に漏電が発生し冷却が停止しました。その結果、計算ノードが温度上昇からシステムを保護するため順次停止し、実行中のジョブは全て停止しました。また計算ノードが全て停止したことにより、その操作がエラーにならないようにTSUBAMEポータルも手動で停止しました。
状況から雨による漏電と判断し、漏電、絶縁、機器破損の有無などのチェックを行いました。水分の拭き取りなどにより、3台ある冷却塔の内の2台が再稼働し冷却が始まりましたが、夜間に再度停止した場合の被害を考慮し、冷却が安定したと確認できた、翌2019年9月10日 9:00に計算ノードの運用を再開しました。
問題のある2番機は詳細な調査を行い原因究明と再発防止の検討をしています。
３．影響があったジョブ
2019.6.12
下記の通り障害が発生し復旧しました。
１．概要
学内ネットワークとlogin0間の通信障害
２．期間
2019年6月11日(火)14:10頃 から 19:00頃
３．詳細
2019/06/11 14:10頃から、ログインノード( login0 )にインターネット上からログインができない障害が発生しました。18:49にlogin0の再起動し復旧しました。なお、TSUBAME内部からはlogin0へアクセスが可能で発見が遅れたため、以後、監視体制を見直し早期に発見、復旧できるよう改善いたします。
2018.12.25
下記の通り障害が発生し復旧しました。
１．概要
/gs/hs1の応答が極端に悪くなる
２．期間
2018年12月17日(月)17:20頃 から 23:16頃
３．詳細
hs1の応答が極端に悪くなっておりました。同期間に特定のユーザのinode(≒ファイル数)がquota値に達している事がわかり、ファイル数が減少したところ応答が正常に戻ったことから、Lustreファイルシステムのquota処理に何らかの不具合があった可能性を調査しています。