【ワレコのIT講座】京都大学スーパーコンピュータの77TBファイル消失事故 原因と対策【ワテは失敗しないので】

その理由は、ワテはIT界の大門未知子と呼ばれているからだ。

「ワテは失敗しないので！」

当記事では、IT界の世界的達人、いや変人のワテが京大スーパーコンピュータLustreファイルシステムのファイル消失の詳細を調査すると同時に、根本原因やその対策を説明してみたい。

では、本題に入ろう。

京大スーパーコンピュータLustreファイルシステムのファイル消失の詳細調査

今回の77TBファイルの消失事故に対して、日本ヒューレット・パッカード合同会社が発表している説明文章を見てみよう。

PDFファイル　file_loss_insident_20211228

引用元　https://www.iimc.kyoto-u.ac.jp/ja/whatsnew/information/detail/211228056999.html

全部で２ページだ。案外簡素だな。

10ページくらいあるのかと思ったが。

どんなファイルを消したのか？

さて、上に引用した説明文を少しずつ見て行こう。

1 　ファイル消失の影響範囲
対象ファイルシステム: 　/LARGE0
ファイル削除期間: 　　2021 年 12 月 14 日 17 時 32 分～2021 年 12 月 16 日 12 時 43 分
消失対象ファイル: 　　2021 年 12 月 3 日 17 時 32 分以降、更新がなかったファイル
消失ファイル容量: 　　約 77TB
消失ファイル数: 　　　34,011,293 ファイル
影響を受けたグループ: 　14 グループ(4 グループが復元不能)
10 グループについては、バックアップ先の /LARGE1 に 49TB のバックアップファイルが残存しています。

この説明から推測するなら、/LARGE0 がバックアップ対象のファイルシステムで、/LARGE1 がバックアップ先のファイルシステムのようだ。

本来、/LARGE0 のファイルは /LARGE1 に全てバックアップすべきところを、何らかのミスで /LARGE0 の中の日付が10日以上古いファイルは削除してしまったようだ。

その理由は以下の原因説明文にある。

3 　ファイル消失が発生した原因
バックアップスクリプトには、find コマンドにより 10 日以上古いログファイルを削除する処理が含まれています。スクリプトの機能改善と合わせて、find コマンドの削除処理に渡す変数名を視認性・可読性を高めるため変更いたしましたが、この修正したスクリプトのリリース手順に考慮不足がありました。

bash は、シェルスクリプトの実行中に適時シェルスクリプトを読み込みます。この挙動による副作用を認識できておらず、実行中のスクリプトが存在している状態でスクリプトの上書きによりリリースしてしまったことで、途中から修正したシェルスクリプトの再読み込みが発生し、結果的に未定義の変数を含む find コマンドが実行されてしまいました。この結果、本来のログディレクトリに保存されたファイルの削除をする処理ではなく、/LARGE0 のファイルを削除してしまいました。

この説明から推測するなら、バックアップ用シェルスクリプトファイルには /LARGE0内のログファイル保管フォルダに対して findコマンドを使って10日以上古いログファイルを一括で削除するコマンドが入っていたようだ。

その削除作業の後に、/LARGE0から/LARGE1へフルバックアップを実行する手順になってたと思われる。

まあ要するにバックアップする前に不要なログファイルを削除したかったんだな。

そのシェルスクリプトを編集して変数名などを分かり易い名前に変えたようだ。

そもそも今まで何の問題も無く使えていたシェルスクリプトを安易に編集するからこんな問題が起こる訳だが。

ワテの場合、昔はUNIXの達人と呼ばれていたが今ではfindコマンドの使い方なんてすっかり忘れてしまったがな。

でGoogle検索すると、簡単に見つかった。

Linux findコマンドを使ってn日前のファイルを削除する 3つの記述方法
　
「/var/www/html/」フォルダの中にあるファイルのうち、タイムスタンプが 6日以上前のファイルを削除するコマンドの記述方法は、下記の 3つの記述方法があります。
　

-execオプションを使う方法

$ find /var/www/html/ -mtime +5 -exec rm -f {} \;　

xargsコマンドを使う方法

$ find /var/www/html/ -mtime +5 | xargs rm　

-deleteオプションを使う方法

$ find /var/www/html/ -mtime +5 -delete　

引用元　https://blog.s-giken.net/400.html

ワテの場合は、上の三つの例の最初の -exec を使うやつを良く使っていたなあ。

でも実は小心者のワテの場合、findで見付けたファイルを行き成り -exec rm なんてするのは怖いので、例えば以下のようなスクリプトを良く書いていた記憶がある。

ls | grep ".txt" | awk '{ print "rm " $1 }' | sh

これなら、以下のようにまずは ls | grep “.txt” で削除したいファイルを見付ける。

ls | grep ".txt"

そして awkで削除コマンド rm とそのファイル名を印字して確認。

ls | grep ".txt" | awk '{ print "rm " $1 }' 

最後に、sh に渡して削除を実行する。

ls | grep ".txt" | awk '{ print "rm " $1 }' | sh

つまり画面に表示して目で確認する超慎重派だ。

この場合でも rm ではなくて rm -i として削除前に確認メッセージを表示すると同時に、指差し確認（指差喚呼　しさかんこ）しならがファイルを一つずつ削除する場合も有った。

超超慎重派だ。

単なるビビリともいえる。

 

さて、日本ヒューレットパッカードの説明では、「find コマンドにより 10 日以上古いログファイルを削除する処理が含まれています。」となっているので、例えば以下のようなコマンドがシェルスクリプトファイルの中の一行にあったのかも知れない。

find /LARGE0/LOG -name '*.log' -mtime +10 -exec rm -f {} \;　

ところが、そのシェルスクリプトを実行中に、そのシェルスクリプトファイルをエディタで編集してファイルを上書きしたようだ。

つまりまあ、推測するなら、シェルスクリプトを編集する為に vi エディタか何かのエディタで開いていたんだろう。

で、シェルスクリプトの変数名の変更作業などが完了したので、よっしゃ！完成したぞ！と言う事で、シェルスクリプトを実行した。

でも、viエディタの画面で、さらにちょっとしたマイナーな修正をしたんだろう。そして :w! で強制上書きしたのかな？

その結果、実行中のシェルスクリプトが保持している変数の中身が破壊されて、空文字列とかが入ったのかな？

で、消す予定の/LOGフォルダ内の10日以上古いログファイルだけでなく、/LARGE0以下の日付が10日以上前のファイルが全て削除されのかな。たぶん。

まあ、十分有り得る事故だな。

京大スーパーコンピュータLustreファイルシステムのファイル消失の根本原因は何か？

まず、人間は必ず失敗する。機械は必ず故障したり誤動作したりする。

この事を十分に意識しておく必要があるだろう。

今回の事故で言えば、テラバイトものデータのバックアップを取得するシェルスクリプトを安易に編集した事が事故の発端だ。

単純にファイルのコピー処理だけなら今回のような致命的な問題は起こりにくいが、今回はファイルの削除コマンドが有った事が根本原因と言えるだろう。

安易にファイルを削除しない

まあUNIXでもLinuxでもroot権限で

rm -rf /*

なんてやれば、えらい事になるのは言うまでもない。

つまり、削除rmコマンドに -r で再帰的にディレクトリ階層全て、-fで 強制的に削除となるので、まあ要するに消せるファイルは全部消してしまう。かつ、復元不可能だ。Windowsのゴミ箱みたいな機構はUNIX・Linuxには基本的には存在しないので。

百歩譲って rm コマンドを使うとしても、

rm *

では無くて、例えば

rm *.log
rm 2021*.log

くらいにしておけば今回のような壊滅的な事故は避けられたはずだ。

つまりまあ、もし今回の事故でrmコマンドの引数にワイルドカード * が指定されていたとすると、UNIX/Linuxシステム管理者としては失格だ。

もしそうなら、それは個人の問題と言うよりも日本ヒューレットパッカード合同会社の業務上の問題だと思う。その程度の社員教育がされていないのか！？

 

と言う訳で、京大の何十億円もすると思われるスパコンシステムのファイルのバックアップを、素人が書いたようなシェルスクリプトでやっている事がまず問題だろう。

ちゃんとしたバックアップ製品を使えよｗ

バックアップ専用の優秀なソフトウェア製品なんて世の中に沢山あるだろう。何十億円もすると思われるシステムに安全性を求めるなら例えば数百万円程度のバックアップソフトを使えばいいと思うんだが。

ワテが邪推するなら、京大は日本ヒューレットパッカードにぼったくられているんじゃ無いのか？！と思ってしまう。

あかんで。

削除するなら事前にバックアップを取得する

でもまあ、コンピュータを使っていればハードディスクにはどんどんデータが溜まって行く。

なので、必要に応じて不要なファイルを削除しなくてはならない状況は良くある。

そんな時には、削除対象のファイルが少なければ手作業で消せば良いが、数百個のファイルを削除したいとか、あるいは、いろんなフォルダに分散しているファイルを削除したいなどの場合には、手作業なら時間が掛かる。

今回の京大システムの場合なら、ログフォルダの中のログファイルを削除しようとしたようだが、もしログフォルダが一つならわざわざfindコマンドなどは使わないと思うので、恐らく

みたいに複数のフォルダに分かれていたのかな？

でもそうだとしたら、10日以上前のファイルを消すなら簡単だと思うんだが。

実際は、もっと複雑なフォルダ構造なのかも知れない。

さて、大量のファイルを削除する必要があるなら、その前にバックアップを取得するのが鉄則だろう。

今の時代、14テラバイトクラスのハードディスクも6万円前後で売っている。

あるいは8TBクラスのSSDも十万円以下で買える。

これらの大容量記憶装置をバックアップ用に10台くらい買えば、100TBくらいのバックアップが可能だ。費用も100万円も有れば足りる。

二重にバックアップするとしても、200万円くらい。

まあ、もっとちゃんとしたメーカー製の外部ストレージを買ったとしても数百万円も有れば足りるだろう。

あるいはテープ装置にバックアップをとっても良い。

京大スパコンシステムのデータ消失事故ではバックアップ元の /LARGE0 バックアップを /LARGE1  に取得する時に起こったようだが、なんでバックアップ前に /LARGE0 の中のログファイルを消すのか？

消すんならバックアップ取得後に /LARGE1 のログファイルを消せば良いだろう。

そうすれば今回のようなうっかりミスをしても /LARGE0 のデータが消え去る事故は回避できる。

消え去るのは /LARGE1 だからだ。

もちろん /LARGE1に対して大量のファイル削除コマンドを実行する場合には、事前に/LARGE1をメインCPUから分離して別のCPU環境で作業すればどんな失敗をしても/LARGE0には影響はないし。

要するに危険な作業を行う環境は、メインのファイルシステムが絶対に破壊されないようにハードウェア的に分離しておけば良いのだ。

普通はそれくらいの安全対策を取ると思うんだが。

つまりまあ、アホな管理者が酔っ払って rm -rf / を実行したとしても、前日までのフルバックアップが安全な場所に取得されているくらいのシステム運用をするのが普通だと思うんだが。

あかんがな。京大、いや日本ヒューレットパッカード合同会社なのか？！

バックアップはお客さんにとってもらう

余談になるが、ワテの体験談を紹介しよう。

ワテの場合も、少しではあるがシステムエンジニア的な作業をした事がある。

お客さんのコンピュータを触る場合は、最大の安全策を講じておく必要がある。

自分は正しく作業していても、たまたまワテが作業している最中にそのパソコンが壊れる可能性もある。ハードディスクがクラッシュするなど。

ワテが悪く無くても、壊れた時にパソコンを触っていたのがワテならワテの責任になるかもしれないし。

なので、お客さんのコンピュータを触る前には、事前にメールなどでお客さんに「重要なデータは必ずバックアップを取っておいて下さい。」と念を押しておくのだ。

そうしておけばもし作業当日に事故が起こっても、ワテは無罪。

「ワレコ式お客さんに責任転嫁作戦」だ！

まとめ

京都大学スパコンデータ消失事件が起こったそもそもの原因はワテの見解では以下の通り。

• 人間は必ず失敗する事が考慮されていない（ヒューマンエラー対策）
• 高額なスパコンシステムのバックアップ取得にシェルスクリプトを使うなんて馬鹿げている

などか。

ワテお勧めの改善案としては以下の通り。

• シェルスクリプトなんて使わずに有料のバックアップソフトウェア製品を採用すべき
• どんな事故が起こっても復活出来るように前日までのフルバックアップを取得するくらいの安全策を講じるべき

などか。

もし京大が事故調査委員会でも作るなら、一声かけて頂ければシステム開発の世界的変人のワテも参加させて頂きますが。

無いかｗ

（完）